シリーズ最終回は、6ヶ月の先の話です。社内ボット（Gem）で小さく始めた意味の層を、来期、全社の基盤へどう育てるか。基盤・深さ・広さの3つの問いに順に答え、最後にシリーズ全体を一つの結論へ畳みます。
入り口（ボット）から到達点（コーパス）へ
社内ボットは意味の層への入り口でした。ノーコードで作れ、現場が自走でき、知識ファイルの個数制限の中で「分割と結合」を学ばせてくれる。けれど全社展開の局面では、この制限が天井になります。その先の受け皿が、コーパス（大規模インデックス）方式です。文書を取り込んでチャンク化・索引化し、大規模な検索基盤として管理する。人事規程・製品仕様・過去事例といった複数のコーパスを、それぞれ別管理のまま、利用者からはひとつの知識基盤としてまたいで検索できます。
ここで、シリーズで繰り返してきた原則が結実します——build once, consume many：土台を一度こしらえれば、多くの用途がそれを使い回せる。部門ごとにボットもデータもばらばらに増やせば、維持の手間は部門数なりに膨らみます。逆に共有の土台の上にチャット・検索・エージェントといった窓口を載せれば、整備の成果がすべての用途へ一度に行き渡ります。
そして移行でいちばん効いてくるのは、これまでの7工程で築いた資産が、そのまま移行の設計図になることです。正本の置き場は取り込み元に、分類体系はコーパスの区切りに、旧版の排除は取り込み時の自動フィルタに、評価セットは移行の良し悪しを測る回帰テストに——それぞれ横滑りします。移行は一気の切替でなく並行で——先行部門で同じ評価セットをボットとコーパスの両方に流し、品質が上回ったのを確認してから窓口を切り替えます。
どこまで深めるか——技術4段階の再訪
検索技術の深さ（第2回で見た4段階）も、ここで判断します。規制下の製造業の現実解は、第2回の結論から変わりません——第2段階（メタデータ付きRAG）を全社基盤に、関係推論が効く高価値領域に限って第3段階（GraphRAG系）を部分適用するハイブリッド。第4段階（オントロジー接地）は時期尚早です。
第4段階の効果は、原論文（OG-RAG）の表記（「正確性が約40%向上、再現率が約55%向上」）のみを採り、「ハルシネーションが40%減る」という流通表現は不正確な言い換えなので使いません。GraphRAG系の優位を示す勝率も、AIに優劣を判定させる方式のバイアスが指摘されるため留保付き参考値として扱います。なお OG-RAG（arXiv:2412.15235・v1）・GraphRAG（arXiv:2404.16130・v2）とも査読前のプレプリントで、数値は方向の根拠として扱います。段階を上げる判断は流行でなくKPIで——第2段階の正答率が頭打ちで、誤答の原因に「関係を辿れなかった」型が増えてきたら、第3段階を検討する合図です。
ロックインを恐れず、縛られず——層別設計
本格展開で必ず衝突する2つの要望——「特定ベンダーに縛られたくない」と「この基盤ならではの強力な機能を使いたい」——は、層で分ければ両立します。
- 相互運用の層：標準（エージェントとデータ／ツールをつなぐMCP、エージェント同士をつなぐA2A など）に乗り、資産を持ち出せる状態にして将来に備える。評価セット・プロンプト・整備の型をどの基盤にも依存しない中立な形式で保管し、契約で自社のものと明記する。これらの資産こそが移行の保険で、基盤を乗り換えても、評価セットさえあれば「乗り換えた後の品質」をすぐ測れます。
- 基盤特化の層：閉域での運用・大規模コーパス・長時間の自律実行など、個人向けの単体AIでは原理的に無理で、しかも乗り換えコストに見合う領域だけに絞って、その基盤ならではの機能を深く使う。
「広く浅く標準で、狭く深く基盤で」——これが両立の形です。標準への対応は「つなげばすぐ動く」ものではなく「将来の引っ越し費用を下げる保険」と捉えるのが、今の時点の正直な見方です（本番での実装例はまだ少なく、移行の費用も現に残ります）。
エージェント化と「総合デバッグ」——越境の現在地
最後に「AIにどこまで任せるか」。複数の手順を自律的にこなすエージェントの道具立ては急速に整っていますが、立場は変わりません——エージェントは意味の層を“使う側”であって、その代わりではない。共有の土台があってはじめて、その上のエージェントは組織の文脈に沿って動けます。土台のないエージェントは、「自信満々に間違うボット」の、より高速で危険な版になるだけです。
「仕様書・コード・実行ログを突き合わせ、矛盾から不具合箇所を特定する」総合的な検証基盤は、規制下の製造業にとって自然な到達目標に見えます。ただし現在地は正確に——構成要素の技術はそれぞれ実在するが、三者を単一パイプラインで統合し一気通貫で行う公開システムは、現時点で確認できません。三者は異なる解析パラダイム（文書＝意味検索、コード＝プログラム解析、ログ＝系列解析）に属するため、統合部分は既製品でなく各社の独自開発になります。買えないことは悪い知らせではなく、要素が揃って統合だけが空いている今は、ドメイン知識を持つ企業が差別化できる時間帯でもあります。なお自律デバッグの実力は、厳密に再評価すると上位システムでも成功率が大きく下がるという第三者検証（"The SWE-Bench Illusion"）もあり（arXiv:2506.12286・v4・査読前プレプリント。ベンチマーク外のリポジトリでは最高でも約76%→約53%に低下）、現実的な成熟度は「人間の確認を前提とした強力な支援」——ここでも前回のHuman-in-the-Loopが効きます。
結論——土台が先、エージェントは後
シリーズを一文に畳むと、こうなります。
土台が先、エージェントは後。 『生成AIの内製化』第13章
来期に最初に置くべき項目は、エージェントの導入ではなく、意味の層を広げることです。エージェントは、その積み上げの先で得られる果実であって、そこへの近道ではありません。
そして、最終的な検証は文献の中にはなく、あなたの現場の数字の中にあります。正答率が、検索時間の短さが、根拠の提示率が、土台への投資と歩調を合わせて動き出したとき——「意味の層が成否を分ける」という見立ては、ようやくあなたの組織にとっての事実になります。
明日からの三歩だけ、具体的に。①棚卸しから始める（領域を1つ選び、文書がどこにあるか・正本があるかを聞き取る。会議室ひとつと1週間あれば着手できる）。②最初の1個を決める（仕様書検索か社内規程回答。生成でなく検索から）。③評価セットを20問作る（現場の実際の質問と模範解答を書き出す。この20問が、以後すべての投資判断の物差しになる）。巨額の予算も、最新モデルも、基盤の選定さえも要りません。要るのは、組織の意味と向き合う意思だけです。
まとめ——事実・整理・結論
- 【事実】 標準（MCP/A2A等）は整備が進むが本番実装は希薄で移行コストも実在／自律デバッグは厳密評価で成功率が大きく下がる第三者検証がある／三者統合の公開システムは未確認。
- 【本記事の整理】 Gem→コーパスの移行は7工程の資産が設計図に／技術は第2段階を全社・第3段階を部分適用／「広く浅く標準・狭く深く基盤」の層別設計。括り方は本記事側の整理です。
- 【結論】 土台が先、エージェントは後。来期の第一項目は意味の層の拡張。検証は自社の数字で。