生成AIの話題にはプロンプト・RAG・ファインチューニング・エージェントといった用語が次々に出てきます。難しそうに見えますが、4つとも「AIにどう働いてもらうか」を表す手段の名前です。本記事では、それぞれを「ひとことの定義」「具体例」「使いどころ」の順で、初めての人でも読めるように整理します。最後に、現場で迷ったときの選び方もまとめます。
How They Fit Together
まず全体像です。この4つは対立する選択肢ではなく、下の段から順に積み上げる関係にあります。多くのチームは「まずプロンプトで試す → 足りなければ社内データをRAGで足す → 出力の型を固めたいときだけファインチューニング → 複数手順を自動実行したいときにエージェント」という順で進みます。
FIG.1 下ほど基本・上ほど高機能。上の段は下の段を土台にして成り立つ
01プロンプト ― AIへの「お願い文」
プロンプトとは、生成AIに「何をどうしてほしいか」を伝える指示文のことです。AIにとっての入力（input）であり、書き方しだいで成果物の質が大きく変わります。2026年の実務では、単発の指示文を磨く狭い意味の「プロンプトエンジニアリング」から、参照資料・履歴・ツール情報まで含めてAIに渡す情報全体を設計する「コンテキストエンジニアリング」へと関心が移っています。
具体例：3つの要素で指示は強くなる
よく効く定番の型は「役割・制約・例」の3点セットです。
- 役割：「あなたはBtoB SaaSのプロダクトマネージャーです」
- 制約：文字数・トーン・出力形式（箇条書き／表／JSON）を指定する
- 例：期待する出力サンプルや、良い例・悪い例を見せる
プロンプト例：「あなたはBtoB SaaSのPMです。新機能案を3つ、各案に〈狙い／対象ユーザー／測る指標〉を付けて箇条書きで出してください。専門用語には短い補足を付けて。」
使いどころ
文章を書く
メール、企画書、要約、議事録の整形など。最も手軽で、まず試すべき入口。
コードを書く
関数の作成、バグ修正、レビュー。意図と制約を具体的に書くほど精度が上がる。
整理・分類する
表の整形、データの分類・抽出。出力形式を指定すると後工程がラクになる。
注意点
「いい感じにして」のような曖昧な指示は、曖昧な回答を返します。前提（目的・対象読者・禁止事項）を具体的に書くのがコツです。また、プロンプトに入れた内容は処理のために送信されるため、機密情報を不用意に含めない運用配慮も必要です。長文を渡すときは、関連情報を前後に置くと精度が上がりやすいことも知られています（情報が真ん中に埋もれると見落とされやすい、いわゆる「迷子問題」）。
02RAG ― 検索で「根拠」を足す仕組み
RAG（Retrieval-Augmented Generation／検索拡張生成）は、AIが回答を作る前に社内文書やデータベースから関連情報を検索（Retrieval）し、その内容を根拠にして回答を生成（Generation）する仕組みです。たとえるなら「AIに社内ナレッジをカンニングさせてから答えさせる」イメージです。モデル自体を作り直さずに、自社固有の知識や最新情報を扱えるのが利点です。
FIG.2 RAG ＝「検索（Retrieval）」して根拠を渡し「生成（Generation）」させる2段構え
仕組みのざっくり4ステップ
- 文書を扱いやすい長さに分割する（チャンク化）
- 各チャンクを埋め込み（Embeddings）でベクトル＝数値の並びに変換して保存する
- 質問を同じくベクトル化し、意味の近い文書片を検索する（ベクトル検索）
- 検索で得た文書片をプロンプトに添えて、AIに回答させる
2026年時点では、検索の精度を「意味の近さで拾うベクトル検索」と「型番・条文番号などを確実に拾うキーワード検索」を合わせるハイブリッド検索が標準的になり、さらに広く拾った候補（例：上位20〜50件）を関連度で並べ直す再ランキング（reranking）で上位数件に絞ってからAIに渡す構成が、品質改善の定番として広く使われています。
使いどころと具体例
- 社内規程・手順書・FAQ・議事録を参照する社内チャットボット
- 製品マニュアルを引きながら答えるサポート窓口
- 過去事例を参照しながらの提案書ドラフト作成
具体的なツール（2026年の代表例）
小規模なら、いま使っているPostgreSQLにpgvector拡張を入れる構成が手軽で、OpenAIやSupabaseなど多くの本番システムで使われています。専用のベクトルDBとしてはPinecone・Weaviate・Qdrant・Milvusなどがあり、規模が大きくなったら移行する流れが一般的です。埋め込みモデルはOpenAIのtext-embedding-3（small / large）、多言語ならCohereのembed v4、GoogleのGemini Embeddingなどが代表的です。実装をまとめるフレームワークとしてLangChain・LlamaIndexがよく使われます。
注意点
「RAGを入れれば全部解決」ではありません。検索がズレると、AIはズレた根拠でもっともらしく間違えます。実際、素朴に作っただけのRAGは検索段階でかなりの頻度（おおむね3〜4割）で失敗するとも報告されており、2026年の現場ではボトルネックは生成よりも検索だと認識されています。チャンクの切り方、メタデータ（部署・製品名・改訂日など）の設計、権限管理が品質を左右します。
03ファインチューニング ― モデルに「型・癖」を覚えさせる
ファインチューニングは、既存の大規模言語モデル（LLM）に追加データで再学習させ、特定の文体・出力形式・タスクに最適化する方法です。2026年の整理では、ファインチューニングは「知識（facts）を入れるためではなく、振る舞い（form）＝文体・形式・トーンを固めるため」に使うもの、という理解が定着しています。頻繁に変わる知識はRAGで、安定させたい型はファインチューニングで、という役割分担です。
具体的なやり方とコスト感
モデル全体を学習し直す代わりに、ごく一部のパラメータだけを軽く調整するPEFT（効率的な部分学習）が主流で、なかでもLoRA／QLoRAという手法が標準的に使われます。提供面では、OpenAIはGPT系モデルでファインチューニングAPIを提供する一方、AnthropicのClaudeは一般向けには再学習を開放しておらず、長いコンテキストと詳細なシステムプロンプトで代替するのが現実的、という違いもあります。
使いどころ
- 出力フォーマットを厳密に固定したい（例：必ず決まったJSONや手順で返す）
- 業界特有の言い回し・用語を統一したい（医療・金融・製造など）
- 分類・抽出などの定型タスクを高精度・低コストにしたい
注意点
よくある誤解が「社内文書を全部ファインチューニングすればいい」というものですが、頻繁に更新される情報の取り込みはRAGの方が向いています（更新が簡単で、引用元も示せる）。また、学習データの質が低いとモデルもそのまま学ぶため、データ整備（ラベルの一貫性、誤りの除去）がコストの中心になりがちです。
| RAG が向く | ファインチューニングが向く |
|---|---|
| 頻繁に更新される知識・事実を扱いたい | 出力の型・文体・判断の癖を固定したい |
| 引用元を示して説明責任を持たせたい | 毎回の長いプロンプトを短く・安定させたい |
| 更新が簡単（文書を差し替えるだけ） | 更新のたびに再学習が要る |
実務では両方を組み合わせるのが定番で、「軽いLoRAアダプタで型を整え、知識はRAGで足す」構成がよく採られます。
04エージェント ― AIに「段取りと実行」まで任せる
エージェントは、AIが単発で答えるだけでなく、目標に向けて手順を考え、外部ツールを使い、必要なら繰り返し実行する仕組みです。人でいえば「作業者」や「秘書」に近い役割です。2026年には、ブラウザ操作・コード実行・ファイル管理までこなす実行型のエージェント（Claudeのエージェントモードや、ターミナル上で動くClaude Codeなど）が実務で広く使われるようになりました。
FIG.3 計画 → ツール実行 → 結果の観察 → 必要なら再計画、というループで動く
エージェントを支える要素
- ツール呼び出し（Tool use / Function calling）：検索、DB参照、カレンダー、メール送信などの外部機能を呼ぶ
- メモリ（Memory）：会話履歴やユーザー設定を保持する
- プランニング：目標をタスクに分解して順に実行する
- ガードレール：権限・確認フロー・実行制限（勝手に送信しない等）
具体例：MCP という共通規格
エージェントが外部ツールやデータにつながる方法は、以前は提供元ごとにバラバラでしたが、Anthropicが2024年に提案したMCP（Model Context Protocol）が共通規格として急速に普及しました。「AIの世界のUSB-C」とも呼ばれ、2026年にはOpenAI・Google・Microsoft・Amazonなど主要各社が採用し、月間のSDKダウンロードは数千万規模に達しています。ツールの定義を特定のAI提供元に縛られず、使い回せるのが利点です。
注意点：実行できるぶん、事故も起きやすい
エージェントは「実行」までできるため、設計を誤ると誤った宛先へのメール送信、権限外データへのアクセス、誤情報の自動登録などが起こり得ます。実務では、重要操作は人間の承認を挟む（Human-in-the-loop）、実行ログを残す、最小権限でツールを渡す、といった基本が効きます。
05一緒に覚えたい関連用語
LLM（大規模言語モデル）
大量のテキストから学習した「文章を作るのが得意なモデル」。生成AIの中心です。2026年の代表例として、OpenAIのGPT-5系、AnthropicのClaude（Opus/Sonnet）、GoogleのGeminiなどがあります。
トークン（Token）
AIが文章を処理する単位。「1文字＝1トークン」ではなく、語や記号のまとまりで区切られます。料金や入力上限はトークン数で決まることが多いです。
コンテキストウィンドウ（Context Window）
モデルが一度に読める情報量の上限。2026年は20万トークン級（Claude Opus）から、100万〜200万トークン級（Gemini系）まで広がりました。ただし広ければ良いわけではなく、情報が真ん中に埋もれると精度が落ちるため、RAGで関連箇所だけを絞って渡す使い方が今も有効です。
埋め込み（Embeddings）
文章をベクトル（数値の並び）に変換し、「意味の近さ」で検索できるようにする技術。RAGの検索部分の心臓です。
ハルシネーション（Hallucination）
AIがもっともらしく事実と異なることを言う現象。RAGで根拠を与える、「不明なら不明と言う」と制約する、引用元を必須にする、といった対策で抑えやすくなります。
プロンプトキャッシュ（Prompt Caching）
毎回同じ前置き（システムプロンプトや参照資料）を送るとき、サーバー側に保存して再利用する仕組み。ClaudeやGeminiが対応し、繰り返し部分のコストを大きく下げられます。
06迷ったときの選び方
現場の判断は、次の順に考えるとスッキリします。過剰設計を避け、安く速い手段から試すのが鉄則です。
まずプロンプトで解く
安い・速い・すぐ試せる。役割・制約・例を整えるだけで多くの用途は足りる。
社内情報が必要ならRAG
更新される知識・固有情報を、引用つきで扱える。ハイブリッド検索＋再ランキングで精度を上げる。
出力を安定させたいならファインチューニング
型・文体・判断の癖を定着させる。知識はRAGに任せ、振る舞いだけを固めるのがコツ。
複数手順を自動実行したいならエージェント
計画・ツール実行・観察のループ。重要操作は承認・ログ・最小権限を必ず添える。
プロンプトは伝え方、RAGは根拠の持たせ方、ファインチューニングは癖付け、エージェントは段取りと実行。
07おわりに
この4つの違いが腹落ちすると、AI導入の議論が「なんとなくAI」から「目的に合う仕組みを選ぶ」方向へ変わります。次に社内でAI施策の話が出たら、ぜひ「それはRAGが必要な話？それともプロンプトでいける？」と問いかけてみてください。会話の解像度がぐっと上がるはずです。用語は壁ではなく、設計を語るための共通語です。
