MENU

【初心者向け】ローカルLLM+RAGで自分専用の資料検索AIを作る|CodexでPDF・画像・テキストを検索

本サイトではAmazonアソシエイトを含むアフィリエイト広告を利用しています。

           ┌─────────────────────────────┐
                🛒 Amazonで最新ガジェットをチェック

             PC・タブレット・ゲーミングデバイス・周辺機器を探す

           └─────────────────────────────┘

自分のWindows PCでローカルLLMを動かせるようになった。

Wi-Fiを切ってもAIが返事をする。

ここまで来ると、次に試したくなることがあります。

「自分の資料について答えてくれるAIを作れない?」

例えば、自分のPCにはこんなファイルが増えていきます。

  • PDF
  • 過去のメモ
  • ブログ原稿
  • 製品マニュアル
  • 調べた資料
  • スキャンした書類
  • スクリーンショットや画像

資料が10個なら、人間でも探せます。

しかし100個、500個、1000個と増えたらどうでしょう。

「あの情報、どこに書いてあったっけ?」

を探すだけで時間がかかります。

そこで作ってみたいのが、

自分のPCに保存した資料だけを検索できる、自分専用AI

です。

例えば検索画面へ、

「Astra 2のバッテリーについて書いた資料を探して」

と入力する。

するとAIが、

「Astra 2では8,300mAhバッテリーについて、○○の記事と○○のメモで触れています」

と答え、さらに、

参照:astra2-review.pdf / 8ページ

まで表示する。

これを実現する代表的な仕組みが、

RAG(Retrieval-Augmented Generation)

です。

今回は、Codexにアプリ開発を手伝ってもらいながら、

ローカルLLM+RAG+Embedding+OCR

を組み合わせ、自分専用の資料検索AIを作る流れを初心者向けに解説します。


目次

この記事でわかること

  • RAGとは何か
  • ローカルLLMだけでは何が足りないのか
  • PDFをAI検索する仕組み
  • Embeddingとは何か
  • Vector Databaseとは何か
  • 画像・スキャンPDFをOCRする理由
  • Codexを使ってRAGアプリを作る流れ
  • GPUなしPCでも作れるのか
  • LM StudioやOllamaとの違い
  • 完成したアプリをローカルだけで動かす方法

LM StudioでもPDFを読ませられるよね。それとは何が違うの?

PDFが数個ならLM Studioだけでも十分。でも資料が大量になってきたら、“全部を検索できる仕組み”を自分で作る意味が出てくる


まずRAGって何?

RAGは、

Retrieval-Augmented Generation

の略です。

日本語では「検索拡張生成」などと呼ばれます。

言葉だけ見ると難しそうですが、考え方は単純です。

通常のLLMは、

質問

LLMが持っている知識

回答

です。

RAGでは途中に「検索」が入ります。

質問

自分の資料を検索

関係する文章を取り出す

その文章をLLMへ渡す

回答

となります。

LM Studioにも長い文書から関連箇所を取り出してモデルへ渡すRAG機能があり、ダウンロード済みモデルとのチャットや文書処理をローカルで実行できます。

つまりRAGは、

AIに資料を全部覚えさせる仕組みではなく、必要になったときに探して読ませる仕組み

と考えると分かりやすいでしょう。


1000個のPDFを全部LLMに読ませる必要はない

例えばPCの中に1000個の資料があるとします。

ユーザーが、

「契約更新について書かれている資料を探して」

と質問。

RAGは概念的には次のように動きます。

  1. 質問の意味を数値化
  2. 保存してある文章と比較
  3. 意味の近い文章を検索
  4. 上位3~5件を取得
  5. その文章だけLLMへ渡す
  6. LLMが整理して回答
  7. 元ファイル・ページを表示

最終的には、

契約更新については「運用手順書.pdf」の12ページと「契約メモ.txt」に記載されています。

と答えられる状態を目指します。

ここで重要なのが、

回答だけでなく出典も表示すること

です。

この点は後ほど詳しく説明します。


今回作る「自分専用AI」の全体像

今回作りたいのは、こんな仕組みです。

【自分の資料】
PDF / txt / PNG / JPEG

【文字を取り出す】
PDF解析 / OCR

【文章を小さく分割】
Chunking

【意味を数値にする】
Embedding

【検索用DB】
Vector Database

【ユーザーが質問】

【意味が近い文章を検索】

【ローカルLLMへ渡す】

【回答+出典】

いきなり全部理解する必要はありません。

順番に組み立てます。

そして、今回の最大のポイントは、

最初からPDF・画像・OCR全部入りを作らない

ことです。

まずテキストファイル3個。

それが動いたらPDF。

最後に画像。

この順番で進めます。


Codexは何を担当する?

今回はアプリ開発にCodexを使います。

Codexアプリは2026年3月からWindowsにも対応しており、プロジェクト内のコードを確認し、ファイルを編集し、コマンドを実行しながら開発作業を進められます。

つまり、

  • Python環境を確認
  • 必要なライブラリを選ぶ
  • コードを書く
  • エラーを確認
  • 修正する
  • テストする

といった部分をCodexと一緒に進められます。

ただし、ここは非常に重要です。

Codexで作る=完成したAIもクラウド、ではない

この記事では、

Codex

アプリを作る担当

Ollama / LM Studio

完成後にローカルLLMを動かす担当

Chroma

検索用データを保存

PaddleOCR

画像の文字を読み取る担当

という役割分担にします。

したがって完成後は、Codexを起動していなくてもRAGアプリを動かせる構成を目指します。


CodexにPC全部を触らせる必要はない

CodexにはSandboxとApprovalの考え方があります。

Sandboxは、

Codexが技術的にどこまでファイルやネットワークへアクセスできるか

を制御。

Approvalは、

その操作をする前に人間へ確認するか

を制御します。

Windows版でも、Sandboxを利用して作業範囲外への書き込みやネットワークアクセスを制御する仕組みがあります。

今回なら、

C:\LocalRAG\

というプロジェクトフォルダを一つ作り、

基本的にはこの中だけで作業させる

構成がおすすめです。


今回おすすめする基本構成

初心者なら、まずこんな構成で十分です。

役割使用候補
開発Codex
LLM実行Ollama
EmbeddingOllamaのEmbeddingモデル
Vector DBChroma
PDFPythonでローカル解析
OCRPaddleOCR
UIブラウザ画面
保存場所PCローカル

LM Studioでもできる?

できます。

LM Studioはローカルサーバーとして起動でき、REST APIやOpenAI互換のエンドポイントから自作アプリへモデルを接続できます。

すでにLM Studioを使っているなら、

LLM部分だけLM Studio

でも構いません。

ただ、今回Ollamaを基本にする理由は、

LLMとEmbeddingの両方をローカルAPIから扱いやすい

ためです。


STEP1:まずPCスペックをCodexに確認してもらう

いきなりモデルをインストールしません。

まず、

このPCなら何が現実的なのか

を確認します。

Codexへ次のように依頼します。

Codexへの指示例

このWindows PCで、完全ローカルで動作する個人用RAG資料検索アプリを作りたいです。まず環境を変更せず、確認できる範囲で以下を調べてください。・Windowsのバージョン・CPU・システムメモリ・GPU・GPUのVRAM・ストレージ空き容量・Python環境・Git環境・Ollamaの有無・LM Studioの有無その結果から、このPCで現実的に動かせる・ローカルLLM・Embeddingモデル・Vector Database・OCRの構成を提案してください。この段階ではインストール、設定変更、ファイル作成は行わず、調査結果と提案だけを出してください。

なぜ最初は変更させない?

例えば、

  • GPUなし
  • RAM 16GB

のPCと、

  • VRAM 12GB
  • RAM 32GB

では最適なモデルが違います。

いきなりネットの記事を見て、

「このモデルが最強らしい!」

と入れるのではなく、

自分のPCで快適に動くものを選ぶ

ことが重要です。


STEP2:まずローカルLLM単体を動かす

RAGを作る前に、

AIそのものが快適に動くか

を確認します。

ここを飛ばすと、

RAGが遅いのか。

LLMが遅いのか。

Embeddingが遅いのか。

原因が分からなくなります。

Ollamaは起動するとローカルAPIをlocalhost:11434で提供します。ローカルAPIへのアクセスでは認証も不要です。

まず、

質問↓Ollama↓ローカルLLM↓回答

だけを作ります。

確認する項目

  • 日本語が理解できるか
  • 回答速度
  • メモリ使用量
  • CPU/GPU使用率
  • 1回答何秒かかるか

です。

仮に1回の回答に5分かかるなら、

「動く」

けれど、

「実用的ではない」

かもしれません。

この段階でモデルを変えます。


STEP3:最初のRAGはtxtファイル3個だけ

ここがこの記事で一番伝えたいところです。

最初から、

  • PDF
  • Word
  • PNG
  • JPEG
  • OCR

を全部入れないでください。

まず、

data/
├─ tablet.txt
├─ local_llm.txt
└─ minimax_h3.txt

くらいで十分です。

この3つを検索できれば、

RAGそのものはほぼ完成

です。


STEP4:文章を小さく分割する「Chunking」

文書をそのまま巨大な1個の文章として保存すると、検索しにくくなります。

そこで文章を小分けにします。

これを、

Chunking

といいます。

例えば、

ローカルLLMとは?
—————–
ローカルLLMに必要なメモリ
—————–
GPUとVRAMの違い
—————–
LM Studioの使い方
—————–

と分けます。

質問が、

「VRAMって何?」

なら、

GPUとVRAMの部分だけ検索

できるわけです。


STEP5:Embeddingって何?

RAGで最初につまずきやすいのが、

Embedding

です。

Embeddingは簡単に言えば、

文章の意味を数字へ変換する技術

です。

OllamaもEmbeddingを、Semantic SearchやRAGのためにテキストを数値ベクトルへ変換する仕組みとして提供しています。

例えば、

「契約更新の手続き」

と、

「契約期間終了後の延長方法」

は文字がかなり違います。

しかし意味は似ています。

通常のキーワード検索だけなら見つけにくい場合があります。

Embeddingなら、

意味が近い

ことを検出できます。


検索用AIと回答用AIは別でいい

ここも重要です。

例えば、

Embedding担当

軽量なEmbedding専用モデル。

回答担当

GemmaやQwen。

と分けられます。

OllamaはEmbedding向けモデルとしてembeddinggemmaqwen3-embeddingなどを案内しています。

Qwen3-Embeddingシリーズ自体も、検索・Retrieval・Reranking用途向けに開発されています。

つまり、

一つの巨大AIに全部やらせる必要はない

のです。


STEP6:Chromaへ保存する

Embeddingした文章を保存して、検索可能にします。

今回使う候補が、

Chroma

です。

Chromaは文書・Metadata・Embeddingを保存し、ベクトル検索できます。

例えば、

文章:「Astra 2は8,300mAhのバッテリーを搭載」↓Embedding↓[0.327, -0.119, 0.844, ...]↓Chromaへ保存

というイメージです。

質問、

「Astra 2の電池について教えて」

もEmbedding。

意味の近いベクトルを探す。

「8,300mAh」の文章が見つかる。

という流れです。

Chromaにはデータをローカルに永続保存するPersistent Clientも用意されています。


STEP7:Codexに最小RAGアプリを作ってもらう

ここまで決まったら実装です。

Codexへの指示例

先ほど決めた構成を使って、最小構成のローカルRAGアプリを作成してください。最初はtxtファイルだけに対応します。要件:・Windowsで動作・プロジェクトフォルダ内だけで作業・OllamaのローカルLLMを使用・EmbeddingもOllamaのローカルモデル・Vector DatabaseはChroma・dataフォルダ内のtxtを読み込む・文章を適切なサイズにChunkingする・EmbeddingしてChromaへ保存・ブラウザから日本語で質問できる・関連するチャンクを検索・検索結果をLLMへ渡して回答・回答には参照元ファイル名を表示するテスト用の架空txtファイルを3つ作成してください。実装後、「検索 → RAG → LLM → 出典付き回答」まで動作確認してください。外部のAI APIは使用しないでください。

ここまで動けば、大成功です。

まだPDFは必要ありません。


STEP8:実際に質問してみる

例えば、

tablet.txt

に、

REDMAGIC Astra 2は8,300mAhバッテリーを搭載している。

と書いておきます。

そして、

「Astra 2のバッテリー容量を教えて」

と質問。

結果が、

Astra 2のバッテリー容量は8,300mAhです。

参照:tablet.txt

となれば成功です。

次に、

「Astra 2の電池はどのくらい?」

と表現を変えます。

同じ資料が検索されれば、

キーワード検索ではなく意味検索が機能している

ことを実感できます。


STEP9:txtが動いたらPDF対応

ここで初めてPDFを追加します。

Codexへ、

現在のRAGアプリへPDF読み込み機能を追加してください。要件:・テキスト情報を持つPDFに対応・ページ単位または適切な単位で文章を抽出・ファイル名をMetadataとして保存・ページ番号もMetadataとして保存・検索結果に  「ファイル名 / ページ番号」  を表示・既存txt機能は維持・ローカル処理のみ使用・テスト用PDFで動作確認

と依頼します。

ここでかなり重要なのが、

ページ番号

です。

例えば、

「Astra 2は8,300mAhです」

だけではなく、

参照:astra2-spec.pdf / P.6

まで出したい。

これでRAGの信頼性が一気に上がります。


RAGは「正解を出すAI」ではなく「原文を探すAI」と考える

これはかなり重要です。

悪い検索AIは、

契約終了日は9月30日です。

だけ回答。

良い検索AIは、

契約終了日は9月30日と記載されています。

参照:契約書.pdf / P.12

と回答。

人間がクリックして原文を確認できる。

RAGでは、

AIを100%信用できるようにする

より、

1000ページから確認すべき3ページを見つける

と考えた方が実用的です。


STEP10:スキャンPDF・画像はOCR

PDFには2種類あります。

普通のPDF

文字情報が入っている。

スキャンPDF

紙を撮影した画像。

後者では、そのままでは文字を取り出せない場合があります。

そこで、

OCR

を使います。

OCRは画像の文字をテキストへ変換する技術です。

PaddleOCRには画像から文字情報を抽出するローカルOCRパイプラインがあり、現在のPP-OCR系では日本語認識にも対応しています。

処理は、

PNG / JPEG↓PaddleOCR↓テキスト↓Chunking↓Embedding↓Chroma

です。


CodexにOCR対応を追加してもらう

現在のRAGアプリへOCR機能を追加してください。対象:・PNG・JPEG・スキャンPDF条件:・OCR処理はローカル・外部OCR APIは禁止・PaddleOCRを第一候補とする・日本語を含む文書を想定・抽出した文字を画面で確認可能にする・元ファイル名をMetadataとして保持・PDFの場合はページ番号も保持・OCR結果をEmbeddingして既存RAGへ統合

ここまで来れば、

PDF・テキスト・画像を検索できるAI

になります。


GPUがないPCでもできる?

可能です。

ただし、

快適さはPC性能に左右されます。

重要なのは、RAGでは必ずしも巨大LLMを使う必要がないことです。

質問、

Embedding検索。

関係する文章を3~5個に絞る。

小型LLMへ渡す。

という処理だからです。

つまり、

検索側を賢くして、LLMを小さくする

という設計ができます。

これは低スペックPCほど重要です。


軽いモデルでまず配線を確認する

いきなり最高性能モデルを入れる必要はありません。

まず、

  • 質問できる
  • 検索できる
  • Chromaから取得できる
  • LLMへ渡せる
  • 出典が出る

ことを確認。

そのあと、

回答モデルだけ交換

します。

GoogleのGemmaは利用可能な計算資源や用途に合わせて複数サイズから選べる設計で、現在はGemma 4などのローカル実行可能なオープンウェイトモデルも提供されています。

モデルを固定しない設計にしておけば、

もっと軽くて賢いモデルが出た

モデルだけ交換

できます。


LM Studioを使い続けたい場合は?

もちろん構いません。

以前の記事でLM Studioを導入済みなら、

RAGアプリ

LM Studio Local Server

ローカルLLM

という構成にもできます。

LM Studioはモデルを完全ローカルで実行でき、Developer機能からローカルサーバーとして利用できます。

例えば、

LLM

LM Studio。

Embedding

Ollama。

Vector DB

Chroma。

でも構いません。

あるいは両方をOllamaへまとめてもよい。

目的はツールを統一することではなく、完全ローカルで必要な性能を出すこと

です。


完成したら「本当にローカル?」を確認する

ここは必ずやりましょう。

① Wi-FiをOFF

ネットワークを切ります。

② アプリを起動

正常に開く?

③ 質問する

回答できる?

④ PDFを検索

検索できる?

⑤ OCR

画像の文字を処理できる?

全部動けば、

実行時にはかなり明確なローカル構成

になっています。


Codexにもコード監査を頼む

完成したら、次のように依頼してもいいでしょう。

このRAGアプリが実行時に完全ローカルで動作するか監査してください。以下を確認してください。・LLM・Embedding・Vector Database・PDF解析・OCR・ブラウザUIコード全体から、・OpenAI API・Google API・Anthropic API・クラウドOCR・その他の外部AI API・外部送信処理が残っていないか確認してください。変更はせず、外部通信する可能性がある箇所だけ一覧化してください。

ただし最終確認は、

ネットを切って自分で動かす

ことです。


重要:「Ollamaだから全部ローカル」とも限らない

現在のOllamaにはローカルモデルに加えてクラウドサービスと連携する機能もあります。

一方、PC上で起動したローカルAPIはlocalhost:11434から利用できます。

今回の目的では、

ローカルに取得したモデルを使う

ことを明示します。

「Ollamaを使っているから大丈夫」ではなく、

どのモデルがどこで実行されているのか

まで確認します。


会社の機密資料をいきなり入れない

ここも重要です。

RAGを完全ローカルにできたからといって、

「会社の資料を私物PCへコピーしていい」

とはなりません。

これは別問題です。

確認すべきなのは、

  • 会社の情報管理規程
  • 個人情報
  • 守秘義務
  • データ持ち出し
  • クラウド同期
  • バックアップ
  • PC暗号化

などです。

例えばRAG自体はローカルでも、

C:\Users\...\OneDrive\RAG_DATA\

へ資料を保存したら、OneDrive設定によってはクラウド同期される可能性があります。

つまり、

AIがローカル=データ全体もローカル

とは限りません。

最初は、

  • 自分で作った文章
  • 自分のブログ
  • 公開資料
  • 架空データ

で試しましょう。


開発中のCodexにも実データを見せる必要はない

今回の設計では、

開発中

ダミー資料。

完成

RAGアプリ。

完成後

自分が利用してよい資料を投入。

と分けます。

これなら、

RAGを作るために機密資料を開発AIへ見せる

必要がありません。

またCodexのローカル操作自体も、SandboxとApprovalを使い、必要以上の権限を渡さない方が安全です。


エラーが出たら、そのままCodexへ渡す

初心者でも作りやすくなった最大の理由がここです。

例えば、

ModuleNotFoundError: No module named 'chromadb'

と出た。

無理に検索し回らず、

「このエラーが出ています。原因を確認し、現在の構成を壊さない範囲で修正してください」

とCodexへ依頼します。

あるいは、

PDFは検索できるけど日本語の検索精度が低い。

なら、

「現在のEmbeddingモデル・Chunkサイズ・検索件数を確認し、日本語RAGの精度改善案を提示してください。いきなり変更せず原因候補を順位付けしてください」

と頼む。

この、

作る → 試す → エラー → AIと直す

を繰り返します。


RAGで検索精度が悪いときはLLMだけを疑わない

例えば、

「資料には書いてあるのに検索できない」

ということがあります。

そこで、

「もっと大きなAIにしよう!」

と考えがちです。

しかしRAGでは先に別の場所を確認します。

OCR

そもそも正しく文字認識できている?

Chunking

文章を細かく切りすぎていない?

Embedding

日本語を十分理解できている?

検索件数

Top 3では少なすぎない?

Metadata

ファイル名やページ番号が保存されている?

文書

古い資料と新しい資料が混ざっていない?

RAGでは、

検索性能

と、

回答性能

を分けて考える必要があります。

ここが面白いところです。


何を検索させる?

この仕組みを作るなら、かなり使い道があります。

例えば、

REDMAGIC Astra 2

  • 公式仕様
  • 海外レビューのメモ
  • 公開済み記事
  • 実機購入後の検証メモ

を保存。

そして、

「Astra 2のバッテリーについて過去に何を書いた?」

と検索。


ローカルLLM

  • LM Studio記事
  • PCスペック記事
  • RAG記事
  • モデル検証記録

を保存。

「VRAM 12GBについて説明した記事を探して」


MiniMax H3

  • 公式情報
  • ライセンス
  • GPU検証メモ
  • 日本語動画記事

を保存。

「Apache 2.0について過去の記事ではどう説明した?」


商品レビュー

自分の使用メモを蓄積。

「Shokz OpenComm2の気になった点を全部まとめて」

こうなると、

Webを検索するAI

ではなく、

自分が積み上げてきた情報を検索するAI

になります。

ここまで来ると“ローカルLLMを動かした”ではなく、“自分の知識を検索できるAIを作った”と言えるようになる


最初から1000PDFを入れない方がいい

RAGを知ると、

「よし!持っているPDF全部入れよう!」

となりがちです。

おすすめしません。

まず、

STEP1

txt × 3個。

STEP2

PDF × 3個。

STEP3

PDF × 30個。

STEP4

画像OCR。

STEP5

100~1000資料。

と増やします。

少ない状態で、

  • 検索精度
  • 速度
  • 出典
  • Chunking

を確認した方が、問題を見つけやすいからです。


初心者が目指す最初の完成形

豪華なAIアプリは必要ありません。

最初はこれで十分です。

これでいいのです。

────────────────────────

   MY LOCAL AI

────────────────────────

質問:

[ ローカルLLMのVRAMについて教えて ]

    [ 検索 ]

────────────────────────

回答:

VRAM 8GBでは小~中型モデルが
利用しやすいと記載されています……

【参照資料】

・local-llm-pc-spec.pdf / P.8
・lmstudio-notes.txt
・gpu-memo.txt

────────────────────────

必要なのは、

  • 日本語で聞ける
  • 意味検索できる
  • 回答が出る
  • 元資料が分かる
  • オフラインでも動く

ことです。


ローカルLLMの本当の面白さは「ここから」

ローカルLLMを導入しただけなら、

ChatGPTのようなAIがPCで動いた。

という段階です。

そこへ、

自分のPDF

を入れる。

自分の資料全部

を検索する。

RAG

になる。

さらに、

自動化

する。

最終的には、

AIエージェント

へ発展する。

ローカルLLM 

自分の資料

RAG

自分専用検索AI

自動化

AIエージェント

ローカルAIは、

ChatGPTの無料版をPCで作る

ためだけのものではありません。

自分の環境に合わせたAIを作れる。

そこが面白いのです。


ただし、AIにPCを触らせるほど安全対策も必要になる

RAG検索だけなら、

AIが必要とする権限はかなり限定できます。

例えば、

読んでいい

C:\LocalRAG\data\

書いていい

C:\LocalRAG\db\

読んではいけない

Documents全体。

OneDrive全体。

ブラウザProfile。

パスワード。

その他の個人ファイル。

というように分けられます。

Codex自体も、Sandbox・Approval・Network Controlによってエージェントの操作範囲を制御する設計になっています。

自分専用AIだからこそ、

何を読めるAIなのか

も自分で決めましょう。


まとめ:ローカルLLMを動かせたら、次は「自分の資料を検索させる」

今回作るのは、

自分のPCに保存しているPDF・画像・テキストを検索し、ローカルLLMが出典付きで回答するAI

です。

構成は、

資料

PDF解析 / OCR

Chunking

Embedding

Chroma

検索

ローカルLLM

回答+出典

です。

最初から全部作る必要はありません。

まず、

txtを3個検索する。

ここからです。

それが動いたらPDF。

その次に画像。

最後に検索精度を改善する。

Codexを使えば、環境確認、設計、コード作成、テスト、エラー修正をAIと相談しながら進められます。Windows版でもSandboxやApprovalによって作業範囲を制御できます。

そして完成後は、

Wi-Fiを切る。

質問する。

自分のPDFから回答が返る。

元ファイルまで表示される。

ここまでできれば、ローカルLLMは、

「PCで動くAI」

から、

「自分の知識を探してくれるAI」

へ変わります。

ローカルLLMを入れることがゴールじゃないんだね

むしろ入口。自分の資料、自分の検索、自分の自動化へつないでいくところから“自分専用AI”になっていく

まずは1000個のPDFではありません。

txtファイル3個。

そこから、自分専用AIを作ってみましょう。

この記事が気に入ったら
フォローしてね!

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

AI Motion Lab編集部のローカルLLM・技術担当。Ollama、LM Studio、llama.cpp、ComfyUIなど、自宅のパソコンでAIを動かす方法を解説します。プライバシー、必要なPC性能、導入手順まで実践的に検証します。

目次