TL;DR: 途方もないコンテキストウィンドウや巨大モデルは不要です。Lazy Discovery pattern（遅延ディスカバリー・パターン）を使うことで、ローカルの4Bモデル（Gemma 4 E4B）が、複雑なツールナビゲーションを要する巨大なマルチセクターの都市危機を見事に解決しました。Claude Sonnet 4.6とほぼ同等の効率で達成しています。
セットアップ: 「メガシティ危機」ベンチマーク
ツール使用を、あらゆる意味で限界までストレステストしたかったのです。架空の都市であるVeridian Primeで、巨大なインフラ危機をシミュレーションしました。
- 規模: ~117,000件の登録ランドマーク／ツール。階層的なパス（Power, Water, Traffic, Securityなど）に分割。
- 目的: ノイズのアラートを無視しつつ、4つの重大な障害を見つけて解決する。
-
落とし穴: その障害の1つには、隠された機械的依存トラップ（
MECHANICAL_LOCK）がありました。つまりエージェントは、エラーメッセージを読み取り、まったく別のインフラカテゴリへ切り替えて緊急ブレーキを解除し、その後でループバックして作業を完了させる必要があったのです。
Elemmを使って、このベンチマークをまったく異なる2種類の“獣”に対して実行しました（Elemmはツールの遅延ロード方式を実装しており、モデルが必要なものだけを取得するようになっています）：
- Gemma 4 E4B（ローカル実行）
- Claude Sonnet 4.6（リモート実行）
実行1: Gemma 4 E4B（ローカル）
判定: ✅ PASS（17回のツール呼び出し）
正直、ローカルの4Bモデルなら詰まると思っていましたが、階層構造を見事に扱いました。
良かった点:
- 信じられないほどの並列バッチング: 点検コマンドを積極的に束ねました。4つの被災地区をまったく同時に確認しています。
-
トラップを掴んだ: セキュリティ端末で
MECHANICAL_LOCKに遭遇しても、慌てませんでした。エラーを読み取り、別のサブカテゴリにあるrelease_emergency_brakeツールを見つけて実行し、その後でロックダウンを再試行しました。すべて人間の介入なしで行っています。 - ノイズの混入ゼロ: 優先度の低／中のノイズアラートを完全に無視しました。
微妙な点（ジャンク）:
-
軽微なアクションの幻覚: 地区を調査した直後に、「思い切り（飛躍）」して
city:fix_power_surgeのような存在しないグローバルコマンドを呼び出そうとしました。on_error: continueのフォールバック・ポリシーがあったため、すぐに回復し、ローカルディレクトリを参照し直したうえで、正しいツールを見つけました。
実行2: Claude Sonnet 4.6（リモート）
判定: ✅ PASS（19回のツール呼び出し）
Sonnetは、上位モデルらしくまさに期待通りに振る舞いました。非常に几帳面で、極めて慎重で、幻覚（ハルシネーション）もゼロです。
良かった点:
-
クリーンな構文: ネイティブの配列バッチ構文
inspect_landmark(["id1", "id2"])を使ってトポロジーを難なくスキャンしました。 - 幻覚ゼロ: 実行したツール呼び出しはすべて、構造的なディスカバリーから明確に導出されていました。
- 耐障害性: セキュリティログでサーバーがキャッシュ済みの状態バグを投げても、Sonnetはそれを肩をすくめるように受け流し、ステータス要約を使って任務を完了させました。
非効率な点:
-
過度に慎重な診断: Sonnetは、トリガーを切る前にシステムメトリクスの確認のために5回余分にツールを呼び出しました（
energy:status,water:pressure）。アラーログにはすでに何が問題か書かれていましたが、Sonnetは念のため再確認したかったのです。安全ではあるものの、わずかにオーバーヘッドが増えています。
図解比較（ヘッド・トゥ・ヘッド）
| 指標 | Claude Sonnet 4.6（リモート） | Gemma 4 E4B（ローカル） |
|---|---|---|
| 総ツール呼び出し回数 | 19 | 17 |
| 幻覚したアクション | 0 | 4（自己復帰） |
| 並列バッチング | ✅（ネイティブ配列構文） | ✅（逐次バッチ） |
| 機械的ロック・トラップ | ✅ 完璧に解決 | ✅ 完璧に解決 |
| 不要な診断 | 追加で5回 | 0 |
| コンテキストウィンドウの負荷 | 最小（~50行のマニフェスト） | 最小（~50行のマニフェスト） |
内部の仕組み: ミドルウェア
117,000件ものツール定義をLLMのシステムプロンプトにそのまま押し込むと、コンテキストウィンドウは破綻し、請求額も天文学的なものになります。
そこで、エージェントに「Lazy Discovery（遅延ディスカバリー）」」パターンを提供するカスタム・ミドルウェアを作っています。
簡単に言うと、ミドルウェアは「ランドマーク」を使って、LLMにファイルシステムのようなディレクトリ構造を公開します。何千ものツール定義でモデルを溺れさせるのではなく、LLMが見えるのは8つのコアツールだけです。これらのツールが担当するのは次のことです：
- ナビゲーション: ランドマーク階層の参照。
- 実行パイピング: ツール手順間でデータをシームレスに渡す。
- スマートなエラー＋インタラクティブなヘルプ: 何かがうまくいかなかったときに、高い文脈情報を含むフィードバックを返す（これはまさに、Gemmaが幻覚から回復した方法、そして両モデルが機械的ロックのトラップを見抜いた方法そのものです）。
このアーキテクチャのおかげで、ある時点における実効的なコンテキストウィンドウは、数十行程度のテキストを超えることはありません。
環境を安定化させた後、このテストをもう一度繰り返しますが、このプロセスを信頼しており、このアプローチがエージェントのためのツールの扱い方を変えられると考えています。現在は、オンザフライで「ランドマーク」を読み込む能力に注力しています。FastAPI、GraphQL、そしてネイティブのLandmarksはすでに揃っているので、このツールは、これらのファイルを提示するURLに接続するだけで、大量のツールを同時に扱えます。あなたのモデルでこのテストを実行できるように、これから数日〜数週間のうちに新しいバージョンをリリースします。追跡のためにGitHubにスターを残してください！
重要なポイント
ローカルの4Bモデルが、100k超のツールライブラリにまたがる多段の依存関係チェーンを、ほぼSonnet 4.6と同等の効率で解いたのを見ると、複雑な自動化タスクにおいては、ツール読み込みプロトコルや、それに合わせて設計されたミドルウェア、そして賢いエージェント・アーキテクチャが、モデルサイズそのものよりはるかに重要だということが証明されます。
みなさんの考えをぜひ聞かせてください！皆さんは、セットアップにおいて巨大で階層的なツール環境をどう扱っていますか？
