PAP-40-Layer Framework 第14層のアイキャッチ

普通のプロンプト・RAG・Fine-tuning・Agentをどう使い分けるか

  • URLをコピーしました!

方式を選ぶときは、足りないものが指示、参照情報、応答の一貫性、実行手順のどれかを先に分けます。手元の情報を整えるならプロンプト、必要な資料を探して渡すならRAG、繰り返す応答の振る舞いを学習で調整するならFine-tuningが候補です。状況に応じて次の操作を選ばせる必要があるときはAgentを検討します。

これらは一つだけを選ぶ排他的な方式ではありません。RAGで得た規程をプロンプトへ渡し、追加学習したモデルで回答を整え、必要なら操作につなぐ構成も考えられます。ただし、機能を増やすほど、更新、権限、評価、障害対応の対象も増えます。まず業務を満たせる小さな構成を置き、足りない部分に対応する方式を追加します。

目次

社内FAQで求める仕事を四つに分ける

以下は架空の社用タブレット貸出FAQです。社員から「展示会に持ち出したいです。最長何日借りられますか。申請方法も教えてください」と質問されます。参照する架空規程は2026年10月1日適用の版で、「社員が対象、貸出上限は7暦日、利用開始の3営業日前までに申請、係長の承認が必要」と記載されているものとします。

回答では四つの条件を落とさず、簡潔なです・ます調に整えます。回答だけの段階で申請はしません。実際に申請する依頼が追加された場合は、利用日、返却予定日、機器、申請者を確定してから扱います。回答内容の確認と、申請が正しく処理されたかの確認を分けるためです。

解決したいこと 最初に比べる構成 増える確認事項
渡された規程を分かりやすく整える 指示と規程を渡す通常のプロンプト 原文の条件を保つか、不足を推測しないか
多数の規程から適用する版を探す 検索して資料を渡すRAG 検索対象、版、閲覧権限、取得失敗
多様な質問でも語調や構成を揃える 指示・少数の見本とFine-tuningを比較 学習例の品質・許諾、独立した評価、更新負担
申請まで進める 定型ワークフロー、必要に応じてAgent 操作権限、確認対象、停止条件、実行結果

規程が大量にあり人手で選べないなど、必要性が既に分かっている部分は初めから含めます。小さな構成とは、確認や権限制御を省くことではなく、その業務に必要な機能を選んだ構成です。

情報が渡せるなら、まずプロンプトで確かめる

通常のプロンプトでは、対象の仕事、参照資料、守る条件、出力の形を指定します。例えば「添付の貸出規程だけを使い、対象者、上限、申請期限、承認者を順に説明してください。資料にない条件は確認が必要と示してください」という依頼です。規程と項目は業務に合わせて差し替えます。

この方法は、必要な資料が分かっていて入力へ収まり、担当者が適用版を選べる場面の出発点になります。回答後は規程と四条件を照合し、7暦日を7営業日に変えていないか、承認条件を省いていないかを確認します。指示があるだけで正確性が保証されるとは考えません。

語調が揃わない場合は、まず望ましい回答の見本を少数添える方法も比べます。これはFew-shotと呼ばれ、学習ジョブを行わずに入力内の例で振る舞いを示す方法です。見本を足して要件を満たせるなら、その段階で追加学習の必要性は小さくなります。一方、入力の長さや見本の選び方の管理は残ります。

RAGは「どの資料を渡すか」を引き受ける

RAGはRetrieval-Augmented Generation、検索拡張生成の略で、質問に関係する資料を検索し、その内容を生成に利用する構成です。LewisらのRetrieval-Augmented Generation for Knowledge-Intensive NLP Tasksは、モデル内の学習済み情報と検索で取得する情報を組み合わせる発想を示しました。同論文の研究条件を、そのまま全社内検索の性能保証へ広げることはできません。

FAQでは、質問と社員の閲覧権限に応じて貸出規程を取得し、版と該当箇所を回答生成へ渡す構成が候補になります。規程が更新されたときは、元文書だけでなく検索側にも反映されているかを確認します。「RAGを使う」と宣言しただけで、最新の文書を取得できたことにはなりません。

権限のある資料を正しく取れたかと、その資料から正しく答えたかも別の点検です。検索結果が空なら、それを根拠に「申請期限はない」とは答えず、資料を確認できないと伝えて担当部署への確認に回します。権限外の資料は、取得後に回答文から隠すだけの設計にしません。OWASPのRAG Security Cheat Sheetが扱う取得時の認可や来歴を踏まえ、誰にどの資料を渡せるかを検索側でも管理します。

Fine-tuningは、繰り返す応答の調整候補にする

Fine-tuningは、既存モデルを追加のデータで学習して調整することです。望ましい入力と応答の組を用いる教師あり追加学習では、語調や出力の形を揃えることが目的になり得ます。AWSのPreparing data for supervised fine-tuning Part 1: Formatting and qualityも、応答の振る舞いと学習例の品質、未調整モデルとの比較を扱っています。

貸出FAQなら、規程の内容を保持しながら「回答→条件→次の手順」の順に整える応答例を学習候補にします。ただし、丁寧な語調になったことから、貸出日数や最新規程まで正しいと推定してはいけません。規程を更新する経路と、語調を調整する経路を分けて管理します。

採用を考えるのは、プロンプトと見本を整えても業務上必要な一貫性が得られず、利用を許可された質のよい学習例を継続して管理できる場合です。追加学習したモデルと元モデルを学習や調整に使っていない同じ入力で比べ、文体と事実性を分けて評価します。学習、保管、評価、モデル更新の負担が増えるため、少数の返信を整えるだけの業務へ一律に勧めるものではありません。

申請操作があっても、Agentが必要とは限らない

入力欄の確認、利用者の承認、申請APIの呼出しという経路が決まっているなら、通常のプログラムによるワークフローで実装できる場合があります。APIは他のシステムの機能を呼び出す窓口です。文章生成を組み込むことと、モデルに次の操作を選ばせることは区別します。

AnthropicのBuilding effective agentsは、あらかじめ決めた経路のワークフローと、モデルが手順やツール利用を動的に決めるAgentを区別し、単純な構成から効果を確かめる方法を勧めています。2024年公開の設計上の整理であり、唯一の公式定義や現行SDKの仕様ではありません。

例えば申請先が条件で変わり、不足情報の照会と複数システムの確認を状況に応じて選ぶ必要があるなら、Agentを候補にできます。その場合も、閲覧可能な規程と申請可能な操作を分け、利用者の権限を越えないようにします。OWASPのExcessive Agencyは、機能、権限、自律性の過剰さを別々に扱い、必要範囲への制限や下流での認可を勧めています。

この架空業務では、提出前に申請内容を利用者へ示す設計を置きます。この確認は規程が求める係長の承認とは別で、申請の受付を貸出承認の完了とは扱いません。必要項目が足りない、権限がない、応答が返らず提出結果が分からない場合は、そのまま次の操作へ進めません。特に結果不明の申請を直ちに再提出せず、申請先で状態を照会します。Agentにする場合は、反復回数や費用の上限、担当者へ戻す条件も設定します。

同じ要件で比べ、追加した仕組みの効果を確かめる

比較では、社員の質問、適用規程、利用者の権限、四条件の正解、回答の合格基準を固定します。まず人が選んだ同じ規程を通常のプロンプトへ渡し、文章生成の基準を作ります。RAGを加える比較では、検索対象を定めたうえで、その規程を正しく選べるかも評価対象にします。異なる資料を取得した結果を、モデルだけの差と解釈しないようにします。

語調の比較には学習に使っていない質問を共通に使います。申請の比較では、回答の正しさに加え、未承認の提出を止めるか、権限不足や結果不明から担当者へ戻せるかを確かめる計画にします。これらは確認方法の設計例であり、実行して合格を得た報告ではありません。

併用するなら、規程の更新担当、学習例の管理担当、申請連携の管理担当を明らかにします。検索や反復で増える待ち時間、処理費、保守作業も測り、障害が起きた箇所を追える記録を残します。方式を増やしても基準を満たさないときは、さらに機能を足す前に、資料の不足、指示の曖昧さ、検索の誤り、権限の不備のどこに原因があるかを調べます。解く問題が特定できれば、残す構成と外す構成を判断できます。

RAGを文書投入から回答までの工程として管理する基本は「RAGを工程の連なりとして管理する:文書投入から回答までの基本」で解説しています。

出力スタイルの安定化にFine-tuningを使うケースは「出力スタイルの安定化にFine-tuningを使うケース」で解説しています。

出典・参考資料

  1. Patrick Lewisほか「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」(確認日:2026年10月19日)
  2. OWASP「Retrieval-Augmented Generation (RAG) Security Cheat Sheet」(確認日:2026年10月19日)
  3. AWS「Preparing data for supervised fine-tuning Part 1: Formatting and quality」(確認日:2026年10月19日)
  4. Anthropic「Building effective agents」(確認日:2026年10月12日)
  5. OWASP「LLM06:2025 Excessive Agency」(確認日:2026年10月11日)
よかったらシェアしてね!
  • URLをコピーしました!

この記事を書いた人

さかっぺのアバター さかっぺ PAP Research運営 / AIガバナンス・アーキテクト / プロンプトデザイナー

ITインフラの実務経験をもとに、AIの安全性と実用性を両立する仕組みを研究。PAP Researchでは、AIモデルの継続観測と、プロンプト・AI技術の実務解説を発信しています。

経歴や研究方法、発信方針は運営者プロフィールで紹介しています。

目次