IV.1 パターン

第IV部の位置づけ

第III部までで、五層の担当を決めた。第IV部は、現場でよく出る型と、届かない線を見る。本章は、知識の限界を補う型の選び方である。RAG の実装手順は、ここでは切らない。

1.1 よく出る型

モデルの中に無い知識を、外から足す型はいくつかある。排他ではない。一つの仕事に、いくつかを重ねてよい。

型	何をするか	向くとき	壊れやすいとき
プロンプト	今回の聞き方を整える	小さく試す。トーンを決める	全部をここに書く
RAG	文書を切って検索し、答えのそばに置く	社内の説明文、マニュアル	条文のように、場所を指して引用したいとき
MCP	原文や API へ、決まった形でつなぐ	法令、RFC、いまの値	サーバが止まったとき
GraphRAG	関係をグラフにしてから探す	「だれと何がつながるか」	グラフの品質が悪いとき
Fine-tuning	モデルの中身を書き換える	言い回しや形式を、長く染み込ませる	法令や仕様がよく変わるとき
Agentic	計画し、ツールを使い、確かめる	複数の段がある仕事	判断が要らない単純作業に載せたとき

プロンプトは、どの型でも土台になる。Agent は、RAG と MCP を組み合わせて使うことが多い。

両方とも、モデルの外の知識を使う。違いの中心は、切って似た文を探すか、場所を指して取るか、である。

「RFC 6455 の Close code 1006 は何か」を、文書の切れ端の検索だけで取ると、隣の番号が混ざることがある。MCP で節を指定して取ると、出典を付けられる。

社内 Wiki の「あのときの説明」は、RAG で足りることが多い。法令の条は、MCP で原文へつなぐ。関係の網が仕事の本体なら、Memory や GraphRAG の側を見る。

RAG を「標準」だと思ってはならない。検索と生成を組んだ型の一つである。チャンクの切り方が悪いと、文脈が落ちる。構造のある原文を、切れ端の検索だけで済ませない方がよい（SHOULD / するのがよい）。

Fine-tuning で、よく変わる知識をモデルの中に焼き込んではならない（MUST NOT / してはならない）。法改正のたびに学習し直す設計は、運用が先に壊れる。

判断が要らない処理は、普通のプログラムのままでよい。これは第II部の配置と同じである。

パターンは、層の別名ではない。RAG は、多くの場合 Agent の中の取り方である。MCP は層でもあり、型でもある。本書では層の名前を優先する。型の名前は、現場の言葉に合わせるときに使う。

組み合わせの現場向けの話は、構成パターンに残してある。

型は重ねてよい。原文へたどるなら MCP、説明文の検索なら RAG、関係の残りなら Memory、言い回しの染み込みなら Fine-tuning、段のある仕事なら Agent、である。銀の弾丸は無い。壊れ方を見て選ぶ。

手段選択の補助（鮮度・判断の量・データの状態）は全体地図にも短い判定がある。