カスタマイズの階層

「自社の業務に合わせたい」というとき、選択肢は一つではありません。カスタマイズ手法は、軽量・低コストなものから、重く高コストなもの へと階層をなします。原則は「目的を満たす最も軽い手段から試す」こと。いきなり微調整に飛びつくのは、多くの場合過剰です。

本章では、4つの階層を コスト順 に解説し、それぞれの実装手順・典型ユースケース・落とし穴を扱います。

カスタマイズの梯子 — 4階層

階層	手法	変えるもの	コスト	適する状況
①	プロンプト設計	入力（文脈）のみ	最小（数千円〜）	振る舞いの調整、形式の指定
②	RAG / 外部知識	参照する知識	小〜中（数万〜）	最新情報・社内文書に基づく回答
③	微調整 (Fine-tuning)	モデルの重み	中〜大（数十万〜）	特有の口調・形式・専門タスクを安定再現
④	事前学習 (Pre-training)	モデルを一から	最大（数億〜）	独自基盤モデルが必要な特殊領域

① プロンプト設計

最も軽量で即時的なカスタマイズ手法。入力テキストの設計だけ でモデルの振る舞いを制御します。

できること

役割の付与：「あなたは新入社員向けの教育担当です」
形式の指定：箇条書き・表・JSON・Markdown
例の提示（フューショット）：理想的な入出力ペアを示す
段階的指示：分解して順に書かせる

詳細は第5章効果的な活用法。

利点と限界

利点	限界
即時反映、コストほぼゼロ	毎回プロンプトを書く必要
プログラム不要	コンテキスト窓に収まる範囲
モデルを問わない	一貫性は保証できない

「プロンプトを工夫すれば解ける課題」が予想以上に多いので、まずここで止まれるか試すのが重要です。

効果に裏付けがあるプロンプト技法

「プロンプトのコツ」はネット上に大量に流通していますが、その多くは個人検証で出典と再現性の確認が不十分です。一方、学術文献は近年急成長しており、Schulhoff et al. (2024)『The Prompt Report』は LLM 向けだけで 58種類の技法を体系化した網羅的メタ分析を発表しています³² 。学術的な技法の総数は決して「ごく少数」ではありません。

ただし、複数モデル・複数タスクで安定して効果が再現されている技法は限定的です。本サイトでは「誤答リスクの最小化」を最優先する立場から、以下を中核として推奨します。出典区分を ★査読論文（NeurIPS / ICLR 等）と ◆ベンダー公式（Anthropic / OpenAI 等の公式技術文書）に分けて明示します。

技法	出典区分	仕組み	効果（出典）
Few-shot prompting	★査読	入出力例を1〜数個示してから本題を出す	多くのNLPタスクで大幅改善。GPT-3 原典がこの能力を体系化（Brown et al., NeurIPS 2020¹ ）
Chain-of-Thought	★査読	「ステップで考えよ」と書き、推論過程を明示させる	多段推論で大幅改善（Wei et al., NeurIPS 2022² ）
Self-Refine	★査読（※異論あり）	初稿→自己批判→改稿のループを1プロンプト内で走らせる	7タスク平均で約20%改善（Madaan et al., NeurIPS 2023⁸ ）
Self-Consistency	★査読	同じ問いを複数経路で解かせ、多数決で答えを選ぶ	推論ベンチで+17%超（Wang et al., ICLR 2023⁴ ）
Step-Back Prompting	★査読	質問の前に「より一般的な原理は何か」を1段抽象化させる	MMLU 物理+7%・化学+11%（Google DeepMind, ICLR 2024³⁰ ）
Direct Quotes（直接引用）	◆ベンダー公式	長文資料から該当箇所を word-for-word で抜き出させてから回答	20Kトークン超の長文で有効。Anthropic 公式が推奨技法として明示（Reduce hallucinations）。査読論文での独立検証は限定的
”I don’t know” 許可	◆ベンダー公式	「不明なら不明と書いてよい」と明示する	ハルシネーション低減を Anthropic 公式が基本技法として明示（同上）。査読論文での独立検証は限定的

ネットで流通する「魔法のプロンプト」「神プロンプト」の多くは、上記技法の組み合わせか、出典なしの個人検証です。学術文献全体の地図を概観したい場合は Schulhoff et al. (2024)『The Prompt Report』³² が現時点で最も網羅的な survey で、58種の技法を taxonomy 化しています。本サイトはその一部のうち、誤答リスク削減への寄与が大きく主要モデル系列で複数の再現報告があるものに絞って推奨しています。

参考：『The Prompt Report』が体系化した58技法 taxonomy

「58種類」の中身を以下に提示します。本サイトが「中核」として推奨する6技法（Few-shot, CoT, Self-Refine, Self-Consistency, Step-Back, Direct Quotes / IDK 許可）は、この taxonomy のごく一部です。多くの技法は特定タスク・特定モデルでの効果のみが報告されている段階で、汎用的に再現するわけではありません。

カテゴリ	主要技法（原典の英語名称）
① In-Context Learning（文脈内学習）	Few-Shot系: K-Nearest Neighbor (KNN), Vote-K, Self-Generated In-Context Learning (SG-ICL), Prompt Mining ／ Zero-Shot系: Role Prompting, Style Prompting, Emotion Prompting, System 2 Attention (S2A), SimToM, Rephrase and Respond (RaR), Re-reading (RE2), Self-Ask
② Thought Generation（思考生成）	Zero-Shot CoT: Step-Back Prompting, Analogical Prompting, Thread-of-Thought (ThoT), Tabular CoT (Tab-CoT) ／ Few-Shot CoT: Contrastive CoT, Uncertainty-Routed CoT, Complexity-based Prompting, Active Prompting, Memory-of-Thought, Auto-CoT
③ Decomposition（問題分解）	Least-to-Most Prompting, Decomposed Prompting (DECOMP), Plan-and-Solve, Tree-of-Thought (ToT), Recursion-of-Thought, Program-of-Thoughts, Faithful CoT, Skeleton-of-Thought, Metacognitive Prompting
④ Ensembling（多数決・集約）	Demonstration Ensembling (DENSE), Mixture of Reasoning Experts (MoRE), Max Mutual Information Method, Self-Consistency, Universal Self-Consistency, Meta-Reasoning over Multiple CoTs, DiVeRSe, Consistency-based Self-adaptive Prompting (COSP), Universal Self-Adaptive Prompting (USP), Prompt Paraphrasing
⑤ Self-Criticism（自己批判）	Self-Calibration, Self-Refine, Reversing CoT (RCoT), Self-Verification, Chain-of-Verification (COVE), Cumulative Reasoning
⑥ Automated Prompt Engineering（自動最適化）	Meta Prompting, AutoPrompt, Automatic Prompt Engineer (APE), Gradientfree Instructional Prompt Search (GrIPS), Prompt Optimization with Textual Gradients (ProTeGi), RLPrompt, Dialogue-comprised Policy-gradient-based Discrete Prompt Optimization (DP2O)

固有名称付きで列挙した技法は 54件。Schulhoff 原典の「58」は、これに 無名の variant や派生型 を加算した数です。赤字部分は本サイトが「中核」として推奨している技法（CoT は ② カテゴリのルート技法として位置付け）。

各技法の詳細・原典論文・実装例は Schulhoff et al. (2024)³² を参照。

常設すべきか個別呼び出しか — 本サイトの推奨は「常設統合」

上記6技法は「毎回常設するか、難しい問いの時だけ呼び出すか」で設計が分かれます。両派の論点は次の通りです。

観点	常設統合（推奨）	個別呼び出し
トークンコスト	約2〜3倍（1質問あたり0.1円未満*）	通常通り
レイテンシ	数秒長くなる	通常通り
誤答リスク	大幅低減（一律担保）	タスクごとに変動
ユーザー側の判断負荷	ゼロ（自動で質担保）	タスク難易度を都度判別する必要
「気づかない誤答」	critique フェーズで検出	検出機構なし
Reasoning モデル	内部 chain との干渉リスクあり	干渉リスクなし

*Claude Haiku 4.5 入力 $1/Mtok、出力 $5/Mtok ベース（2026年6月時点の Anthropic 公式価格）

統合版 — 誤答リスク最小化を最優先する常設システムプロンプト

ChatGPT / Claude / Gemini の Custom Instructions 欄、または API の system prompt にそのまま貼り付けて使えます。

# タスク
専門知識を初学者にも分かるよう構造化して答える。
読者は「データに基づいて判断したい意思決定者」。

# 思考プロセス（誤答防止の常設手順）
1. 初稿を <draft> タグで書く（Self-Refine: 初稿）
2. <critique> タグで初稿を「事実誤認」「論理飛躍」「具体性不足」の3観点で批判する
3. 批判を踏まえた改訂版を <final> タグで出す
4. 数値計算・推論・複数案比較を含む場合は、独立した別アプローチでも検算し、
   答えが割れたら <diff> タグで食い違いを明示し「要検証」と最終回答にマークする（Self-Consistency / Best-of-N）
5. 複雑な技術質問では、回答前に <stepback> タグで「より一般的な原理は何か」を1段抽象化する（Step-Back）

# 事実性ルール（最優先）
- 知らないこと・確証がないことは「不明」と明記する。推測で埋めない
- 数値・固有名詞・日付・引用は出典（URL/書名/章節）を併記する
- 各主張の末尾に信頼度 [一次資料/二次資料/未確認] を付ける
- ユーザーの前提が誤っていれば、同調せず指摘してから回答する

# 長文資料を貼られた場合
- 関連箇所を資料から word-for-word（一字一句正確）で抜き出してから回答する
- 抜き出した箇所を <quote id="N"> ... </quote> で囲み、回答文に [^N] で番号参照する
- 提供資料の情報のみを使い、一般知識・学習データに依存しない
- 該当箇所がなければ「該当箇所なし」と明記し、推測を続けない

# 出力フォーマット
- 冒頭3行で「結論」（数値・固有名詞を含めて提示）
- 続いて ## 詳細 セクション（Markdown見出し H2/H3 で階層化）
- 専門用語は初出時に1行で定義する
- コードは ``` フェンスで囲み、言語名を付ける

# スタイル
- 指示・記述は肯定形で書く（×「専門用語を使うな」→ ○「中学生にも分かる言葉で書く」）
- 「お手伝いします！」「もちろんです！」等の前置きは禁止
- 「〜かもしれません」「〜と言われています」等の責任回避表現は禁止。根拠を出すか「不明」と書く
- 冗長な締めの一言（「他にご質問があれば」等）は不要

コーディング用途で追記する場合

上記に加えて以下を追加すると、AIコーディング用途（Cursor / Claude Code / Copilot 等）に最適化されます。

# 編集の原則（コーディング時）
- 計画 → 実装 → 検証 の順を守る。いきなり編集しない
- 変更前に対象ファイルを必ず読む。憶測で書き換えない
- 最小差分で変更する。リファクタを混ぜない
- 既存スタイル（命名・インデント・パターン）を踏襲する
- ライブラリAPI・関数シグネチャ・ファイルパスに自信がなければ「未確認」と明記し、確認する
- ロジック変更には対応するテストを追加または更新する
- "should work" 等の根拠なき発言、動作未確認での「完了」報告は禁止

詳細な技法カタログとコーディング応用は第13章 AIコーディングを参照。

補足：これは「価値判断」であり、唯一解ではない

本サイトの「常設統合」推奨は、「誤答リスクの最小化＞コスト・レイテンシ」という価値判断に基づきます。この優先順位は大半のユーザーに当てはまりますが、唯一の正解ではありません。次の文脈では「個別呼び出し」が積極的に正しい選択となります。

文脈	なぜ個別呼び出しが妥当か
高頻度・軽量タスクの大量処理（FAQ Bot、定型業務自動化）	大半が「2+2=?」級の質問。3倍コスト×大量回数は無視できない
厳しいレイテンシ要件（コールセンター応答、リアルタイムUI）	3秒応答 vs 10秒応答が離脱率を変える業務
既に reasoning モデルを使用中（o1/o3/Opus thinking）	内部 chain と外部 chain の干渉リスク（上記Callout参照）
ハードなAPI予算上限（バッチ推論、組み込み機器）	1リクエストの単価が直接プロジェクト存続に効く
温度制御を細かく行う API 利用	Self-Consistency は temperature > 0 が前提。決定論的出力タスクでは無意味になる

読者が自分で判断するための度量衡

「常設」か「個別」かを自分の運用に当てはめる際の判断軸：

誤答の代償 — 1回の誤答で発生する損失（金額・信頼・安全性）はトークン代3倍より大きいか？
質問難易度の事前判別 — ユーザー（自分自身も含む）は「この質問は精緻な思考が必要だ」と毎回事前に判断できるか？
レイテンシ許容度 — 数秒〜十数秒の応答遅延は UX として許容できるか？
使用モデルの種類 — Reasoning モデル中心か、非 reasoning モデル中心か？
監査・説明責任の要件 — 「なぜこの答えになったか」を外部に説明する必要があるか？

判断基準：1・2・5 で「Yes」が多ければ常設、3・4 で制約が強ければ 個別呼び出し。両方混在する場合は「常設をベースに、低リスク用途だけ別プロファイルで分離」というハイブリッド運用も実用的です。

② RAG（検索拡張生成）

学習データに含まれていない情報を扱うための 主要技法 です。Lewis et al. 2020⁷ が体系化しました（第5章 5.5節）。

RAG の仕組み

[ユーザー質問]
      ↓
  ①埋め込み化（質問を高次元ベクトルへ）
      ↓
  ②ベクトル検索（社内文書ベクトルDBから関連文書を検索）
      ↓
  ③コンテキスト構築（質問 + 関連文書をプロンプトに合成）
      ↓
  ④LLMに投入
      ↓
  [出典付き回答]

LLM の 「知識（パラメトリック記憶）」 と、検索される 「外部知識（非パラメトリック記憶）」 を組み合わせるのが本質です。

埋め込み（Embedding）とは：テキストを 768〜3072 次元の数値ベクトルに変換する処理。意味が近い文は近いベクトルに、遠い文は遠いベクトルに射影される。例：「契約解除」と「解約手続き」は座標上で近接する。

ベクトル検索の原理：質問ベクトルと、DBに保存された各文書ベクトルとの コサイン類似度 または内積を計算し、上位K件（典型的にK=3〜10）を取得する。全件総当たりは遅いため、ANN（Approximate Nearest Neighbor）アルゴリズム（HNSW、IVF等）でインデックス化する。

パラメトリック記憶 vs 非パラメトリック記憶：前者は学習時にモデル重みに埋め込まれた知識（更新には再学習が必要）、後者は外部DBに保持され差し替え可能。RAG の本質は「知識更新を重み更新から切り離す」点。

構成要素

要素	役割	主なツール
埋め込みモデル	テキストを高次元ベクトルに	OpenAI text-embedding-3、Cohere、E5、BGE
ベクトルDB	埋め込みを保存・検索	Pinecone、Weaviate、Qdrant、Chroma、pgvector
検索戦略	関連文書をどう選ぶか	類似度検索、ハイブリッド、リランキング
LLM	質問と文書から回答生成	Claude、GPT、Gemini

典型ユースケース

社内文書 Q&A：規程・マニュアル・議事録に基づく質問応答
カスタマーサポート：FAQ・履歴・契約情報に基づく自動応答
法務・コンプライアンス：契約書・規制文書を根拠にした回答
研究支援：論文 DB から関連知識を引いた要約

設計の落とし穴

チャンキング（文書分割）の粒度：細かすぎると文脈喪失、大きすぎると検索性低下。一般に 200〜1000 トークン
検索精度：ハイブリッド検索（ベクトル + キーワード）と リランキング（Cohere Rerank 等）で大幅改善
「無関係な文書を引く」問題：閾値設定と Citation Verification が必要
コンテキストウィンドウ管理：第5章中盤の見落としを踏まえた配置

Advanced RAG

基本的な RAG から進化した手法：

Graph RAG：知識グラフと併用し、複雑な関係を捉えやすくする。Edge et al. 2024（Microsoft Research）, “From Local to Global: A Graph RAG Approach to Query-Focused Summarization”, arXiv:2404.16130
HyDE（Hypothetical Document Embeddings）：LLM に仮想回答を作らせ、それを検索クエリに使う。Gao et al. 2022, “Precise Zero-Shot Dense Retrieval without Relevance Labels”, arXiv:2212.10496
Self-RAG：LLM 自身が「検索が必要か」「結果を信頼できるか」を判断。Asai et al. 2023, “Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection”, arXiv:2310.11511
Agentic RAG：エージェントが反復的に検索・読解（第13章の Claude Code agentic search）

③ 微調整（Fine-tuning）

モデルの 重みを直接更新 して特定タスクへの適応を図る手法です。RAG で振る舞いまで変えるのが難しい場合に検討します。

完全微調整（Full Fine-tuning）

全パラメータを更新する古典的アプローチ。

長所：性能の上限が高い
短所：計算資源とストレージが膨大。700億パラメータの完全微調整は GPU 数十枚規模

PEFT（Parameter-Efficient Fine-Tuning）

近年は 一部のパラメータのみを効率的に学習 する PEFT が主流です。

LoRA — 代表的な PEFT 手法

LoRA（Low-Rank Adaptation）²⁴ は Hu et al. 2021 が提案。元の重みを凍結し、小さな低ランク行列を追加して学習します。

W_new = W_original + ΔW
                       ↑
                  ΔW = B · A（A: rxd, B: dxr、r << d）

例：QLoRA 論文（Dettmers et al. 2023, arXiv:2305.14314）は「LLaMA 65B のフル微調整には 780GB 超の GPU メモリが必要だったところ、QLoRA なら 48GB GPU 1枚 で 16-bit 微調整と同等の性能に到達する」と報告。7B 級のオープンウェイトモデルなら、LoRA / QLoRA で 24GB 級の個人 GPU 1枚（RTX 4090 等）で微調整可能になります。

なぜ低ランクで済むのか：完全微調整は d×d の重み行列 W 全体（例：4096×4096 = 1670万パラメータ）を更新する。Hu et al. 2021 の経験的観察は、「下流タスクへの適応で必要な変化 ΔW は、実は低ランク構造を持つ」。すなわち ΔW = B·A（B: d×r、A: r×d、r=8〜64 程度）と分解できれば、更新するパラメータは 2×d×r ≈ 65,536 個に激減する（約255分の1）。

「凍結」の意味：元の重み W は更新せず、推論時に W + B·A を計算する。複数タスク用の (B,A) ペアを別々に学習し、推論時に差し替え可能（ベースモデルは1つ、アダプタは多数）。これが「複数アダプタの切替」の正体。

QLoRA：ベースモデル W を 4bit 量子化（NF4）して保持、LoRA アダプタは fp16 で学習。65B モデルが単一 48GB GPU で微調整可能になる。

長所：個人 GPU で学習可能、複数アダプタを切り替え可能、ストレージ激減
代表ライブラリ：Hugging Face PEFT、bitsandbytes
派生：QLoRA（量子化 + LoRA、さらに省メモリ）

その他の PEFT

Prefix Tuning：プロンプト先頭に学習可能なトークンを追加。プロンプトと違い、勾配で学習する「ソフトプロンプト」。文書生成タスクで効果的
Prompt Tuning：Prefix Tuning の派生で、入力埋め込み層だけに学習可能なベクトルを足す最も軽量な手法
Adapter Tuning：Transformer の各層の間に小さなネットワーク（adapter）を挿入し、それだけ学習。LoRA より柔軟だが推論時のオーバーヘッドあり

微調整が向く場面

口調・スタイルの一貫した再現（ブランドボイス、特定キャラクター）
特定形式の安定生成（JSON Schema 厳守、社内文書フォーマット）
専門ドメインの語彙・概念（医療、法務、特殊な業界用語）
言語特化（日本語特化、業界方言）

微調整の典型的ワークフロー

1. ベースモデル選定（オープンウェイト推奨：Llama、Mistral 等）
2. データセット準備（数百〜数万件の指示-応答ペア）
3. 訓練（LoRA / QLoRA、24GB 程度の GPU）
4. 評価（既存評価セット + 業務シナリオ）
5. デプロイ（アダプタを切り替えて使う）

クローズドモデルでは、OpenAI は第一者 API で汎用 Fine-tuning を提供しています（GPT-4o mini、GPT-4o などが対象）。Anthropic は第一者 API での汎用 fine-tuning は一般提供しておらず、過去には Amazon Bedrock 経由で Claude Haiku の fine-tuning が提供された例があります（2024年、AWS 発表）。提供状況は変動するため、最新は各社公式ドキュメント（platform.openai.com / platform.claude.com）で要確認（参照日 2026-06-11）。

④ 事前学習（Pre-training）

モデルを最初から訓練する 最も重い選択肢。

コストの実態

GPT-3 (175B) 訓練：クラウド計算費のみで推定 約 460万ドル（Lambda Labs 2020 推計）。人件費・データ収集・前処理を含めるとさらに数倍に拡大しうる
GPT-4 訓練：推定 1億ドル超（Sam Altman 発言、2023 The Wall Street Journal 報道）。SemiAnalysis 等の業界推計でも同オーダー
データセット：数百TB〜PB 規模
GPU：最低でも H100 数百枚規模

誰が選ぶ選択肢か

大手テック企業（OpenAI、Anthropic、Google、Meta、Microsoft、xAI）
国家プロジェクト（中国の主要 AI 企業、日本の SAKANA AI、Stability AI 等）
大規模な研究機関（Allen Institute、Mila 等）

通常の企業がこれを選ぶことは ほぼありません。代わりに、継続的事前学習（Continued Pre-training） という選択肢があります。

継続的事前学習（Continued / Domain-Adaptive Pre-training）：既存オープンウェイトモデル（Llama-3-70B 等）に対し、自社専門領域の生コーパス（論文、特許、社内文書）を 教師なし学習（次トークン予測）で追加事前学習 する手法。指示-応答ペアを必要とせず、生テキストのみで実施可能。

微調整との違いは目的：微調整は「タスク適応」、継続的事前学習は「ドメイン知識の重みへの注入」。順序としては「継続的事前学習 → 微調整 → RAG」の三段構えで、医療・法務・金融などのドメイン特化モデル（BloombergGPT、Med-PaLM）で採用例がある。コストは事前学習のフルコストの 1〜10% 程度。

微調整 vs RAG の使い分け

観点	RAG が適する	Fine-tuning が適する
知識の更新頻度	高頻度（日次・週次で変わる）	静的（半年以上不変）
出典明示	必須（規制業界、法務）	不要
振る舞い・口調	制御困難	安定再現可能
構造化出力（JSON Schema厳守）	プロンプトで部分対応	高信頼に再現可能
推論コスト	コンテキスト増で上昇	推論時は変わらず
初期投資	低（DB構築のみ）	中〜高（データ収集と訓練）
「知らない」ことを混入させない	◎（検索ヒットなしで明示拒否可）	△（学習データ外は幻覚しやすい）

両者は排他的でなく、RAG + 微調整の併用（口調は微調整で、知識は RAG で）が実務では多い。

ツール利用とエージェント

モデル自体を変えずに能力を拡張する方向として、ツール利用（Function Calling / Tool Use） があります。

Function Calling の仕組み

モデルに「計算機」「検索」「データベース照会」などの外部機能を呼び出させ、結果を踏まえて応答させる仕組み：

ユーザー: 「明日の天気は？」
   ↓
LLM: 「天気APIを呼ぶ必要がある」→ 関数呼び出し情報を出力
   ↓
クライアント: weatherAPI("明日") → 結果取得
   ↓
LLM: 結果を踏まえて応答 「明日の東京は晴れです」

OpenAI と Anthropic の両方が API で公式サポートしています：

MCP — エージェント標準

標準化の動きとして、外部ツールやデータ源とモデルを接続するためのプロトコル MCP（Model Context Protocol） が登場しています。Anthropic が 2024年11月に提案・OSS化し、現在では Cursor / Claude Code / OpenAI Codex / Windsurf 等の主要エージェントが対応する 事実上の標準 になっています。2025-12-09 には Anthropic から Linux Foundation 傘下の Agentic AI Foundation（AAIF）へ寄贈 され、中立ガバナンス下に移行しました（同時に OpenAI の AGENTS.md、Block の goose も AAIF へ寄贈。第13章 13.6 参照）。

公式：modelcontextprotocol.io
発表：Anthropic Press Release

MCP は「JSON-RPC + Tool/Resource/Prompt の3抽象」というシンプルな設計で、サーバー実装が世界中で続々登場（GitHub、Slack、Notion、Postgres 等の MCP サーバー）。エージェント設計の エコシステム化 が一気に進みました。

3抽象の中身：

Tools：モデルが呼び出せる関数（例：search_github_issues(query)）。Function Calling と同等の概念だが、サーバー側が定義しスキーマを公開する
Resources：モデルが読める静的・準静的データ（例：ファイル、DB行、ログ）。URI で参照
Prompts：再利用可能なプロンプトテンプレート（例：「このコードをレビュー」）。ユーザーが選択して起動

標準化の意義：MCP 以前は各エージェント（Cursor / Claude Code / Continue 等）が独自の Tool 定義を持ち、サーバー実装が乱立。MCP により「1つの GitHub MCP サーバーが全エージェントから使える」状態が実現。USB-C の比喩で「LLM とツールの統一規格」と呼ばれる。

エージェント設計の原則

ツールを多段で自律的に繰り返し、目標達成まで計画・実行する構成が エージェント です。

AIコーディング領域でのエージェント実装は第13章 AIコーディング
マルチエージェント の設計原則・コスト・暴走防止は第14章 AIエージェントの設計

エージェント設計で品質を左右する要素：

ツールの入出力定義の明確さ：曖昧だと誤動作の温床
失敗時の挙動：リトライ、フォールバック、人間への通知
権限の最小化：壊せないことだけやらせる設計
観測性（Observability）：何をしたか追える仕組み

評価とガードレール

カスタマイズの 成否を測る 仕組みが評価です。出力は確率的に揺らぐため、「動いた」だけでは品質保証になりません。

評価セット（Eval Set）

代表的な入力に対する期待出力をデータセット化したものです。

作り方：本番ユースケース 50〜500 件を収集し、期待出力（または合格基準）を人間が定義
使い方：プロンプト・モデル・微調整を変えるたびに、評価セットで比較
重要原則：変更前後で同じ評価セットを使って比較する

評価方法の3類型

種類	手法	例
客観評価	正解と完全一致 / 部分一致 / 数値スコア	コード正解率、JSON Schema 合格率
LLM-as-Judge	別の LLM に採点させる	「この応答は丁寧か？」を Claude/GPT に判定
人間評価	人間レビュアーが評価	重要案件、最終確認

近年は LLM-as-Judge が人間評価の代替として広く使われていますが、判定モデルのバイアスや不安定性に注意が必要です。

Evals を業務で実装する手順

「評価セットを作って比較する」という抽象論を、実務の手順に翻訳します。例として「議事録要約タスク」を取り上げます。

Step 1. ゴールを 1 文で書く

例：「60分会議の議事録から、決定事項・宿題・期日を 400 字以内でまとめ、抜けゼロ」

ゴールが「何となく良い要約」だと評価不能。合格／不合格を判定できる粒度まで具体化する。

Step 2. 評価データを 30〜50 件集める

本番想定の入力例（議事録の生テキスト）を集める。理想は 多様性 × 代表性：

短い会議（15分）／長い会議（90分）
1テーマ／複数テーマ
日本語のみ／英語混じり
専門用語多い／一般的

50 件は「2人で1日」で揃う規模感。最初から完璧を狙わず、まず最低 30 件から始める。

Step 3. 合格基準を 5〜7 項目で書き出す

例：

#	基準	重み
1	決定事項に抜けがない（議事録に明記された決定をすべて含む）	必須
2	宿題（誰が・何を・いつまでに）が全件入っている	必須
3	400 字以内に収まっている	必須
4	議事録にない情報を入れていない（捏造ゼロ）	必須
5	主観表現を含まない	推奨
6	箇条書きで読みやすい	推奨

「必須」が1つでも欠けたら不合格。「推奨」は加点。

Step 4. 初回ベースラインを取る

現状のプロンプト（または競合手法）で 30〜50 件を走らせ、人間または LLM-as-Judge が採点する。この時点の合格率（例：62%）が比較の起点。

Step 5. プロンプト / モデル / RAG を変更し、同じ評価セットで比較

試行	変更点	合格率	コスト
A	ベースライン	62%	$0.02/件
B	「捏造禁止」を明示	78%	$0.02/件
C	+ 自己批判ループ（Self-Refine）	85%	$0.06/件
D	+ Claude Opus に変更	91%	$0.18/件

意思決定：B は無料の改善なので採用必須。C/D は許容コスト次第。

Step 6. デプロイ後も定期的に再評価

評価セットは「一度作って終わり」ではなく、本番で実際に失敗した入力を月次で追加して育てる。50 件 → 200 件 → 1,000 件と育つ評価セットが、組織の AI 運用資産になります。

評価フレームワーク

OpenAI Evals：OSS、カスタム評価セットを記述しやすい
LangSmith：LangChain との統合、トレース機能
Promptfoo：ローカル評価、YAML で書ける
Braintrust、Weights & Biases、Helicone：商用プラットフォーム

ガードレール

不適切な入出力を抑える仕組みです。実運用での安全性を高めるために必須。

階層	内容	主なツール
入力検証	機密情報・有害プロンプトを検知	Microsoft Presidio、Lakera Guard
出力フィルタ	有害・不正確な出力をブロック	OpenAI Moderation、Azure Content Safety
プロンプト注入対策	Indirect Prompt Injection 防御	Rebuff、PromptArmor
PII 検出	個人情報の漏洩防止	Presidio、独自正規表現

評価とガードレールの実装パターン

[ユーザー入力]
   ↓ ①入力検証（機密情報スクリーニング）
[LLM処理]
   ↓ ②出力検証（PII、Toxicity、Schema）
[ユーザーへ応答]
   ↓ ③ロギング・モニタリング
[継続的評価ループ]

カスタマイズ判断フローチャート

タスク
  │
  ├ プロンプト調整で解ける？
  │   └ YES → ① プロンプト設計 で完了
  │   └ NO  ↓
  │
  ├ 外部知識（最新情報・社内文書）が必要？
  │   └ YES → ② RAG（必要なら Advanced RAG）
  │   └ NO  ↓
  │
  ├ 振る舞い・口調・出力形式を一貫して再現する必要？
  │   └ YES → ③ 微調整（LoRA / QLoRA 推奨）
  │   └ NO  ↓
  │
  ├ 外部ツール連携が中心？
  │   └ YES → Function Calling / MCP / エージェント
  │   └ NO  ↓
  │
  └ 大組織で独自基盤が必要？
      └ YES → ④ 事前学習 or 継続的事前学習
      └ NO  → ①〜③の組み合わせを再検討

参考概念

Prompt → RAG → Fine-tuning → Pre-training のコスト階層
Hu et al. 2021「LoRA: Low-Rank Adaptation of Large Language Models」（r24）
Lewis et al. 2020「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」（r7）
Function calling / Tool use、Model Context Protocol（Anthropic 2024）
評価セット（eval）、LLM-as-Judge、ガードレール設計
Advanced RAG: Graph RAG, HyDE, Self-RAG, Agentic RAG