現在AI業界では、言語モデルにツールへのアクセスを与え、何を呼ぶか決めさせる方法が広まっています。デモでは見事に動きます。本番では崩れます。
Atlas VerifiedのAIエージェントは、政府コンプライアンスデータベース、船舶追跡API、制裁照合サービス、貿易データ提供元、コンテナ追跡システムなど、100を超える専門ツールにアクセスします。各ツールは、専門家が検証判断にその特定のデータを必要とするため存在します。設計上の課題はツールの構築ではありません。適切なツールを、適切な順序と入力で、毎回確実に呼ぶことです。
この記事では、大規模なツール統合実行の現実的な問題と、その解決のために開発した設計パターンを分析します。
ツール急増の問題
エージェントのツールが5つなら、選択は簡単です。モデルが説明を読み、適切なものを選び、呼び出します。しかし20、50、100を超えると、何かが破綻します。
第一に、コンテキストウィンドウの問題があります。各ツールの説明、パラメータースキーマ、使用ガイドをシステム指示に含める必要があります。100+のツールでは、ユーザーの質問が入る前に数万トークンを消費します。モデルは問題を考えるより、ツールの説明を読む時間が長くなります。
第二に、選択精度の問題です。言語モデルは、違いが明確な少数の選択肢から選ぶのは得意ですが、似た名称の数十のツールから選ぶのは苦手です。制裁確認や照合で名称が重なる複数のツールがあると、誤ったものを選んだり、重複データを返す複数のツールを呼んだりしがちです。
第三に、費用と待ち時間の問題です。指示内のツール説明はトークンを消費します。不要な呼び出しは外部サービスのAPI呼び出しを増やし、その多くは要求ごとの課金です。3つで十分なところ8つを呼ぶエージェントは、高価で遅くなります。
静的な振り分けが機能しない理由
単純な解決策は静的な振り分けです。質問をパターン照合し、決めたツール群へ振り分けます。"この会社を確認"なら制裁照合、"このコンテナを追跡"なら船舶追跡、"この証明書を検証"ならUSDA照会です。
実務ではすぐに破綻します。"インドからのこの有機証明書を検証できますか？"を考えてみてください。静的な振り分けではUSDA有機データベース照会が起動するかもしれません。それは合理的です。しかし専門家は、認証機関が制裁対象か、その国の製品に有効なFDA輸入警告があるか、輸出業者が取引禁止リストに載っているか、申告ルートに貿易上の異常があるかも知りたいはずです。
一つの質問が、まったく異なる分野の五つ以上のツールを正当に必要とする場合があります。静的な振り分けは重要な確認を見逃すか、すべてを過剰に起動し、費用と精度の問題に戻ります。
文脈は極めて重要です。"この会社について教えて"は、ユーザーが船荷証券を見ているか、有機証明書を見ているか、一般的な調査の会話をしているかによって、意味がまったく変わります。同じ四語でも、文脈ごとに別のツールが必要です。
二層構造：選択と実行
当社は異なる二つのモデルレイヤーを用い、ツール選択と実行を分離しています。
選択レイヤー は、速く安価なモデルを使います。役割は、質問、会話の文脈、利用可能なツールの簡潔な一覧を見て、このやり取りで使えるようにするツールを選ぶことだけです。呼び出しは行わず、実行モデルがアクセスすべきものを決めます。
選択モデルには、各ツールの一行説明、返すデータ、限界を簡潔に示します。完全なパラメータースキーマよりはるかに短いため、コンテキスト制限に達せず100+のツールを評価できます。通常、現在の質問に関連する8-12のツールを選びます。
実行レイヤー は、より能力の高い推論モデルを使います。選択レイヤーが選んだツールだけを、完全なパラメータースキーマと使用ガイドとともに受け取ります。全カタログではなく絞り込んだツール群を扱うため、何を、どの順序で、どのパラメーターで呼ぶかを、より適切に判断します。
この分離には測定可能な効果があります。選択は一秒未満で、費用もごくわずかです。実行モデルは整理された焦点の明確な文脈を受け取り、誤りが減ります。導入後、やり取りごとの総呼び出し数は大幅に減りました。
能力に基づく絞り込み
二層の選択に加え、システム内の各ツールは、実行できる作業の種類、すなわち能力を宣言します。コンプライアンス確認、貿易情報、文書分析、出荷追跡などに役立つと宣言します。
ユーザーの意図を判定すると、能力が一致するものだけが含まれるようカタログを絞り込みます。選択モデルは、現在の作業種類に無関係なツールを見ることさえありません。
これは微妙な理由で重要です。言語モデルは影響を受けやすいためです。制裁照合ツールが文脈にあると、単純な航路の質問でも制裁確認を実行すると判断するかもしれません。選択前に無関係なツールを除けば、この種の不要な呼び出しをまるごと排除できます。
品質のフィードバック循環
ツール選択は課題の半分にすぎません。残りは、役立つ結果を返すことを確保し、返さない場合に何をするかを知ることです。
実行後は毎回、結果の品質を評価します。よくある障害には以下があります：
空の結果。 ツールは正常に実行されてもデータを返さない場合があります。法人がそのデータベースに存在しないという有効で有益な結果か、照会の組み立てが悪く、修正・再試行すべき問題かもしれません。
確信度の低い一致。 あいまい名称検索で結果が出ても、一致スコアが基準を下回る場合があります。一致候補として示すか、破棄して別の検索方法を試すかを判断する必要があります。
不十分な標本数。 信頼性のため複数の情報源との照合が必要なのに、一つの情報源だけから貿易データが返る場合があります。システムは空白を認識し、補うため追加のツール呼び出しを促せます。
品質確認に失敗すると、エージェントの推論循環にガイドを戻します。単純な再試行ではなく、問題を説明し、照会の組み直し方を提案する方向付けられた再試行です。
段階的な結果の提供
貿易コンプライアンス検証は、本質的に複数段階です。船荷証券をアップロードして検証を求めると、荷送人の制裁照合、有機認証検証、船舶の現在位置、商品のFDA輸入警告、関税分類を確認する必要があります。各確認にかかる時間は異なります。
すべてが終わるまで何も表示せず待たせるのではなく、結果を段階的に配信します。ツールが返すたびに即座に整形し、ユーザー画面に届けます。制裁結果、船舶データ、有機認証状況が、準備できた瞬間に構造化カードとして順に表示されます。
すべての結果を結び付けた文章による概要を作る最終統合は、全ツールの完了後だけに実行します。
自動検証：循環を完成させる
OCR処理では、抽出システムがNOP ID、会社名、船舶識別子、コンテナ番号、港コード、HSコードなどの主要データを特定します。それぞれが特定の検証ツールに対応します。
ユーザーが"この書類を検証"と頼むのを待たず、検証の手掛かりを事前計算します。書類について会話を始める時点で、エージェントはどのツールをどのパラメーターで呼ぶかを把握しています。書類を読み、対象情報を特定し、確認内容を考える必要がないため、検証までの時間が大幅に短縮されます。実行できる計画がすでにあります。
原則
構築を通じて、AIエージェント設計に広く適用できると考えるいくつかの原則が明確になりました：
選択と実行を分離する。 推論モデルに振り分けも担当させないこと。分類には安価で速いモデル、推論には高価で高性能なモデルを使います。
選択肢を減らし、精度を上げる。 適合する10のツールから選ぶモデルは、毎回100から選ぶモデルを上回ります。選択前の絞り込みに投資します。
実行前だけでなく、実行後も検証する。 呼び出しは予測できない形で失敗します。悪い結果を検知し、再試行を導く品質のフィードバック循環を構築します。
まとめず、順次配信する。 結果は到着した時点で見られるべきです。段階的な提供は使い勝手の改善だけでなく、検証データとの関わり方を根本的に変えます。
意図を明示する。 "良い"状態をモデルに推測させず、伝えます。目標計画は、際限のない探索を方向のある検証へ変えます。
Atlas VerifiedのAIエージェントは100+の専門検証ツールを統合実行し、世界のサプライチェーン全体の貿易コンプライアンス確認を自動化します。