なぜMetaのAIはツール呼び出しが40%減ったのか。最新公式情報とClaude Code開発のコンテキスト完全ガイド

巨大プロジェクトでAIが迷走する本当の理由

Metaが巨大データパイプラインにAIエージェントを導入した。

4,100ファイル。3言語。4つのリポジトリ。

最初は全く使い物にならなかったらしい。

だが、ある仕組みを導入した結果、AIのツール呼び出し回数が40%も減少した。

AIがコードを理解できない原因は、モデルの性能不足ではない。

僕ら開発者の頭の中にしかない「暗黙知」をAIに渡せていないからだ。

これは、Claude Codeで開発する僕ら全員に関係する話だ。

暗黙知を抽出する50以上のAIエージェント群

Metaのデータ処理パイプラインは途方もなく巨大だ。

4,100ファイルが連携している。

Python、C++、Hackの3言語が入り乱れる。

さらに4つのリポジトリにまたがって運用されている。

設定レジストリ、ルーティング論理、DAGの構成、検証ルール。

さらにC++のコード生成や自動化スクリプト。

これら6つのサブシステムが完全に同期して動いている。

1つのデータフィールドを追加するだけで、これら全てに変更が必要になる。

ここに最新のAIエージェントを投入しても、最初は完全に崩壊した。

AIには「地図」がなかったからだ。

設定モードによって、同じ操作でもフィールド名が異なる。

間違えればエラーも出ずに無言で間違った出力が出る。

数十個の「非推奨」な値が存在する。

これを削除すると、シリアライズの互換性が致命的に壊れる。

こういう「コードを読んだだけでは絶対に分からない暗黙のルール」が存在する。

現場のエンジニアの頭の中にしかない「部族の知識」だ。

AIはこれを知らない。

だから推測する。

探索して、失敗して、また推測する。

結果として、コンパイルは通るが微妙に間違ったコードを量産し続けた。

モデルのコンテキストウィンドウがどれだけ広くても無意味だった。

そもそも正解がコードベースの中に書かれていないからだ。

そこで彼らはアプローチを根本から変えた。

50以上の特化型AIエージェント群を構築した。

全ファイルをシステマティックに読み込ませた。

エンジニアの頭の中にしかなかった暗黙知を抽出させたのだ。

そして59の簡潔なコンテキストファイルを作成した。

彼らはこれを「百科事典ではなくコンパス」と呼んでいる。

1ファイルあたり25〜35行。

トークン数にして約1,000トークン。

無駄な情報は一切ない。

以下の4つの要素だけが凝縮されている。

• モジュールの目的と全体像
• 重要な依存関係と影響範囲
• テストと検証の具体的な手順
• 非自明なパターンと暗黙のルール

特に最後の「非自明なパターン」が重要だ。

隠れた命名規則や、追記専用の識別子ルール。

これらを言語化したことで、劇的な変化が起きた。

全モジュールの100%をカバーできるようになった。

以前はたった5%だったカバー率からの飛躍だ。

結果として、タスクあたりのAIツール呼び出しが40%も減った。

さらに重要なのは、このシステムが自律的に維持されることだ。

数週間ごとに自動ジョブが走る。

ファイルパスを検証し、カバレッジのギャップを検出する。

古い参照を見つければ自動で修正する。

AIは単なるインフラの利用者ではない。

このインフラを回すエンジンそのものになったのだ。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、
海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

状態依存性とツール統合が鍵を握る情報アーキテクチャ

この事例は、AI開発における致命的な勘違いを指摘している。

AIに全リポジトリを読み込ませれば勝手に理解してくれる、という幻想だ。

現実は全く違う。

企業システムや複雑なプロジェクトの難しさは、知識の量ではない。

「状態依存性」にあるのだ。

ある要件を満たすコードを書くとき、正解は常に変動する。

時点によって正解が変わる。

案件の条件によって正解が変わる。

組織のルールによって正解が変わる。

これが状態依存性の正体だ。

ローカルLLMに社内知識を学習させても、すぐに古くなる。

モデルの内部に焼き込まれた知識と、現実の業務状態との間にズレが生じる。

これを「知識更新ドリフト」と呼ぶ。

閉じた環境でAIを動かすと、一見それっぽいコードを出力する。

だが、古いルールのまま「整合したゴミ」を生み出す危険があるのだ。

しんたろー：
RAGで全部読ませればいいじゃんって思ってた時期が僕にもありました。
Claude Codeに膨大なファイルを探らせると、平気で古い仕様を引っ張ってくる。
結局、人間が「今はこっちのルールだから」って教えないと動かないんだよね。

だからこそ、Metaのアプローチが光る。

彼らは知識をモデルに固定化しなかった。

動的なコンテキストファイルとして抽出し、定期的に自動更新する仕組みを作った。

常に最新の「状態」をAIに注入するアーキテクチャだ。

モデルを賢くするのではなく、モデルに渡す情報を賢くしたのだ。

これは、僕らが個人開発で使うツール設計にも直結する。

AIエージェントに渡すツールの粒度の話だ。

ある海外の開発者の検証データが非常に面白い。

ポートフォリオのダッシュボードを表示するツールを7個から3個に統合した事例だ。

ツールが7個あると、LLMは似た名前のツールを混同する。

「ダッシュボードを見せて」という指示に対し、LLMは迷走する。

まずツール一覧を取得する。

次に詳細を取得する。

最後にレンダリングする。

3回の往復が発生する。

しかも、呼び出し順序によってはLLM向けのガイダンスが欠落してしまう。

これを3個に統合した。

1回の呼び出しで、必要な情報を全て返すようにした。

マークダウンのデータ。

署名付きURL。

分析モードのガイダンス。

全てを1つのレスポンスに詰め込んだ。

結果、LLMのツール選択ミスが激減したのだ。

往復回数が減り、コンテキストの欠落もなくなった。

機能を追加するとき、僕らはつい新しいツールを作りたくなる。

だが、LLMから見れば選択肢が増えるだけだ。

選択肢が増えれば、混乱と迷いが生じる。

しんたろー：
ツールを細かく作りすぎるの、エンジニアの悪い癖だよね。
単一責任の原則とか言って細分化すると、LLMは途端に迷子になる。
Claude Codeには「全部入り弁当」を1個渡すのが一番安定するって最近気づいた。

ここで注目すべきは、ツールの移行手順だ。

いきなり古いツールを削除してはいけない。

まず非推奨のスタブにする。

古いツールが呼ばれたら、内部で新しいツールに委譲する。

この状態でテストを通す。

実際の運用で古いツールが呼ばれないことを確認してから、完全削除する。

既存の呼び出しパターンを壊さずに移行するプロの手法だ。

Metaの「コンパス」と、この「ツールの統合」。

規模は全く違うが、本質は完全に一致している。

AIに探索させない。迷わせない。

事前に情報を集約・構造化し、1回のアクセスで必要なコンテキストを渡す。

これがAIエージェントの性能を極限まで引き出す情報アーキテクチャ設計だ。

AIのための環境構築という新しい開発者の仕事

では、僕らの日々の開発にどう落とし込むか。

Claude Codeを使って1人SaaSを開発しているような環境でも、やるべきことは明確だ。

AIを導入して終わりではない。

AIが迷わず働ける環境を整えることが、僕らの新しい仕事になる。

まず、プロジェクトの暗黙知を言語化することだ。

「このファイルは触るな」。

「この変数は非推奨だが消すな」。

こういったルールは、コードを読んでも絶対に分からない。

これをREADMEの片隅に書くのではなく、AI向けの「コンパス」として独立させる。

マークダウン形式で簡潔にまとめる。

1,000トークン以内に収めるのがコツだ。

長すぎるドキュメントは、AIの注意力を削ぐだけだ。

人間が読むための丁寧な説明は不要だ。

事実と制約だけを箇条書きで羅列する。

次に、そのコンテキストを陳腐化させない仕組みを作ることだ。

手動で更新するのは絶対に続かない。

CI/CDのパイプラインに組み込む。

定期的にスクリプトを回す。

ファイルパスの変更や依存関係の更新を検知し、コンテキストファイルを自動で書き換える。

AIに「古い正解」を信じ込ませないための防波堤だ。

しんたろー：
うちのプロジェクトでも、規約をまとめたファイルをClaude Codeに最初に読ませてる。
でも気づいたら中身が1ヶ月前のままで、AIが古いライブラリの書き方をしてきたりする。
コンテキストの鮮度管理、マジで自動化しないと死ぬなこれ。

そして、AIに渡すツールの設計を見直すことだ。

自作ツールを提供しているなら、粒度を点検すべきだ。

機能ごとに細かく分けすぎると、AIは必ず迷う。

「どれを呼べばいいか迷わない」構成を目指す。

複数のツールを1つに統合する。

1回のレスポンスで必要な情報を全て返す。

AI向けのインターフェースは、人間向けのAPI設計とは全く異なるのだ。

人間にとっては使いにくくても、AIにとってはそれが正解になる。

入力パラメータも極力シンプルにする。

複雑な形式を要求すれば、AIは必ず構文エラーを起こす。

AIエージェントは魔法の杖ではない。

ただの超優秀な作業員だ。

作業員が迷わず動けるように、現場のルールを整理する。

道具箱を使いやすく整頓する。

僕ら開発者の役割は、コードを書くことから「AIのための環境構築」へと完全にシフトしている。

このシフトに適応できた者だけが、AIの真の恩恵を受けられるのだ。

よくある質問（FAQ）

Q1: AIエージェントにコードベースを理解させるには、全ファイルをRAGで検索させるだけではダメですか？

ダメだ。AIは「非自明なパターン」や「暗黙のルール」をコードから推測できない。非推奨の値を削除してはいけない、といった背景はコードに書かれていないからだ。RAGによる探索に頼ると、AIは推測と失敗を繰り返し、一見正しいが微妙に間違ったコードを生成する。プロジェクトの暗黙知を抽出した「コンパス」となるコンテキストファイルを事前に用意することが必須だ。

Q2: MCPサーバーでツールを作る際、機能ごとに細かく分けた方が良いですか？

いいえ、LLM向けにはある程度統合した方が安定する。ツールが多すぎると、AIは似た名前を混同したり、複数回の呼び出しでコンテキストが欠落したりする。ある事例では、ツールを7個から3個に統合したことでLLMのツール選択ミスが激減した。LLMが「どれを呼べばいいか迷わない」粒度でツールを設計し、1回の呼び出しで必要な情報をまとめて返すのがベストプラクティスだ。

Q3: プロジェクトのルールやコンテキストをドキュメント化しても、すぐに古くなりませんか？

その通りだ。静的な知識はすぐに陳腐化し、AIが「古いルールに従って自信満々に間違える」原因になる。これを防ぐには、コンテキストの有効性を定期的に自動検証・更新する仕組みをセットで構築する必要がある。ファイルパスや依存関係の変更を検知し、常に最新の状態（状態依存性）をAIに提供するアーキテクチャが求められる。

AIの真価を引き出す情報設計

AIの性能を引き出すのはモデルの賢さではない。

僕らが渡すコンテキストの質と鮮度だ。

迷わせず、最新の地図を渡し続ける仕組みこそが、これからの開発の生命線になる。

AIエージェントを迷わせないためのコンテキスト設計や、最適なツールの粒度について、ThreadPostで議論しませんか？

👉 ThreadPostでSNS運用を自動化する