AIエージェントアーキテクチャ：モデルルーティングとツール発見

LLMを接続するだけでアプリケーションはテキストを生成できます。しかし、AIエージェントが実世界のタスクを完了するには不十分です。

モデルに文書を要約するように依頼すると、モデル層だけで十分です。しかし、今日の競合価格を比較したり、会社の記録を充実させたり、ソーシャルアカウントを確認したり、未知の仕事に最適なAPIを選択したりするように依頼すると、欠けている半分が明らかになります：エージェントは外部システムにアクセスする信頼できる方法が必要です。

したがって、生産エージェントは2つの別々の決定を下します：

このステップを処理するのはどのモデルか？
データまたはアクションを提供するのはどのツールまたはAPIか？

AIHubMixは、統一されたモデルアクセスとリクエスト時のモデルルーティングで最初の決定に対処します。Monidは、ランタイムツール発見、スキーマ検査、および従量課金の実行で2番目の決定に対処します。これらの製品は、同じアーキテクチャの異なる層に位置しています。

開示：この記事はMonidとのコンテンツコラボレーションの一環として作成されました。AIHubMixは以下で議論されるモデルプラットフォームであり、Monidはツールプラットフォームです。どちらも独立して使用できます。

AIエージェント内の2つのルーティング問題

エージェントの実行は、ほとんどの場合、1つの均質なモデル呼び出しではありません。リサーチエージェントはリクエストを分類し、最新情報を検索し、構造化された事実を抽出し、結果を比較し、最終的な回答を書きます。これらのステップには異なる能力が必要です。

モデルの外でも同様です。会社のリサーチタスクは、今日検索APIが必要で、明日会社の充実エンドポイントが必要で、来週はブラウザ自動化ツールが必要かもしれません。すべてのモデルとツールがビルド時にハードコーディングされている場合、新しいタスクはすべて統合プロジェクトになります。

この2つの層は並行しています：

	モデル層	ツール層
コア決定	どのモデルが応答するべきか？	どのAPIを呼び出すべきか？
選択時	リクエストごと	タスクごと、ランタイムで
入力	プロンプト、モダリティ、品質およびレイテンシのニーズ	目標、必要なデータまたはアクション、スキーマと価格
出力	モデルの完了	外部データまたは実行されたアクション
例	AIHubMix	Monid

この分離は重要です。より良いモデルはライブデータへのアクセスを作成できず、より大きなツールカタログは返すデータを推論できません。エージェントは両方の能力を必要とし、それらの間に明確な契約が必要です。

Monidは、AIエージェントが2つの統合を必要とする理由で補完的なツール側のビューを提示します。モデル側から見ると、アーキテクチャの教訓は同じです：モデル選択とツール選択を独立させ、それぞれの層をその仕事に最適化します。

なぜ固定モデル1つがエージェントループで高くつくのか

どこでも1つのモデルを使用するのは簡単に見えます。しかし、実際には、すべてのステップが能力、レイテンシ、価格の同じトレードオフを受け入れることを強制します。

市場調査エージェントを考えてみましょう：

意図分類は短く機械的です。
ツール選択は信頼できる指示の遵守が必要です。
返されたJSONからフィールドを抽出するのは主に変換です。
最終報告書はより強い推論とより良い執筆を必要とするかもしれません。

すべての4つのステップを最も能力の高いモデルに送ることは、ルーチン作業にお金を無駄にします。すべての4つを最も安価なモデルに送ると、ユーザーが読む唯一の出力の質が低下する可能性があります。エージェントループが成長するにつれて、その妥協はすべての呼び出しで繰り返されます。

AIHubMixは、広範なモデルカタログにわたるOpenAI互換のエンドポイントを提供します。既存のOpenAI SDK統合は、APIキーとbase_urlを変更することでAIHubMixを指すことができます：

from openai import OpenAI

client = OpenAI(
    api_key="<AIHUBMIX_API_KEY>",
    base_url="https://aihubmix.com/v1",
)

response = client.chat.completions.create(
    model="auto:balanced",
    messages=[
        {"role": "user", "content": "このリクエストを分類し、次のステップを提案してください。"}
    ],
)

modelをautoに設定すると、モデル選択がリクエストパスに移動します。ルーターはタスクを分析し、それに適したモデルに解決します。ポリシーサフィックスは最適化目標を明示的にします：

ルーター値	優先順位	典型的なエージェントステップ
`auto`	コスト優先	バッチ作業とルーチン変換
`auto:balanced`	能力、コスト、レイテンシ	汎用エージェント作業
`auto:quality_first`	能力優先	複雑な推論と最終成果物
`auto:latency_critical`	速度優先	インタラクティブループと軽量プランニング

ルーティングには別途料金はかかりません。リクエストは、実際に処理したモデルのリスト価格で請求されます。解決されたモデルとルーティングの詳細は、X-Aihubmix-Router-Resolved-Modelヘッダーを含むレスポンスに表示されるため、決定は観察可能であり、ブラックボックスにはなりません。

完全な動作、サポートされているエンドポイント、ポリシー、および現在の制限は、AIHubMix LLMルーターガイドに文書化されています。

モデルルーティングはエージェントにライブデータを提供しない

モデルルーティングが設定された後、エージェントは各ステップに対してより良い脳を選択できます。それでも、モデルのトレーニングデータ以降に何が変わったかを知ることはできず、プライベートビジネスシステムにアクセスしたり、別のアプリケーションでアクションを実行したりすることはできません。ツールがその能力を提供しない限り。

ここで、多くのエージェントプロジェクトが脆弱なコードを蓄積します。チームは1つの検索APIを接続し、次に1つのスクレイピングAPI、次に1つの充実APIを接続します。各統合は、別のアカウント、資格情報、リクエスト形式、エラーモデル、および請求関係を導入します。ツールの説明はしばしばシステムプロンプトにコピーされ、徐々に古くなります。

失敗モードは危険です。なぜなら、成功しているように見えるからです。モデルは古いスキーマに対してもっともらしい呼び出しを生成し、不完全な応答を受け取り、タスクが成功したかのように続行します。ランタイムスキーマ検査は、モデルにトレーニングや古いプロンプトからAPI契約を記憶させるよりも安全です。

したがって、ツール層は実行前に次の3つの質問に答えるべきです：

この目標を満たすツールは何か？
現在適用されるスキーマと価格は何か？
呼び出しが実際に返した結果は何か？

ツール発見は第2のルーティング層である

Monidはツールアクセスを発見・検査・実行のワークフローに変えます。エージェントが必要とするすべてのAPIを予測することを開発者に要求するのではなく、エージェントは自然言語でカタログを検索し、候補の契約を検査し、選択したエンドポイントを実行できます。

基本的な流れは次のようになります：

# 1. 目標に合ったツールを見つける
monid discover -q "公開ウェブページから現在の製品価格を見つける"

# 2. 選択したエンドポイントのスキーマと価格を読む
monid inspect -p PROVIDER_SLUG -e ENDPOINT_PATH

# 3. エージェントが契約を確認した後にのみ実行する
monid run -p PROVIDER_SLUG -e ENDPOINT_PATH \
  --query '{"url":"https://example.com/product"}'

発見と検査により、エージェントは何かを費やす前にオプションを比較できます。実行は選択したエンドポイントの価格モデルに従って請求されます。開発者は1つの統合を維持しながら、エージェントは複数のプロバイダーにわたるツールへのアクセスを得ます。

エージェントランタイムがセットアップ指示を読み取れる場合、Monidは機械可読のスキルも公開しています：

Set up https://monid.ai/SKILL.md

Monidワークフロードキュメントは、カタログ、検査、および実行ステージについて詳しく説明しています。

2つの層がどのように連携するか

モデルゲートウェイとツール層は、小さく明示的なハンドオフを持つ別々のコンポーネントであるべきです：

エージェントはユーザーの目標を受け取ります。
AIHubMixは計画呼び出しを適切なモデルにルーティングします。
計画は欠けている情報または必要な外部アクションを特定します。
Monidは候補ツールを発見し、それらのスキーマと価格を公開します。
エージェントはその権限と予算内でツールを選択し実行します。
ツールは事実またはアクション結果を返します。
AIHubMixは必要な品質、コスト、またはレイテンシに応じて合成呼び出しをルーティングします。
エージェントはツール結果に基づいた回答を返します。

簡略化されたPythonでは、モデル側の呼び出しは変更されず、ツール結果がコンテキストとして挿入されることができます：

from openai import OpenAI

client = OpenAI(
    api_key="<AIHUBMIX_API_KEY>",
    base_url="https://aihubmix.com/v1",
)

# 軽量な計画ステップには高速モデルが十分です。
plan = client.chat.completions.create(
    model="auto:latency_critical",
    messages=[
        {
            "role": "user",
            "content": "これらの製品の現在の価格を比較する方法を計画してください。",
        }
    ],
)

# あなたのエージェントはMonidを使用して適切なツールを発見、検査、実行します。
# これらのプレースホルダーをその呼び出しによって返された構造化結果に置き換えます。
tool_result = {
    "source": "<source-url>",
    "data": "<structured-tool-result>",
}

report = client.chat.completions.create(
    model="auto:quality_first",
    messages=[
        {
            "role": "system",
            "content": (
                "簡潔な比較を書いてください。供給されたツール結果のみを使用し、"
                "ソースURLを保持し、値が欠けている場合はその旨を述べてください。"
            ),
        },
        {"role": "user", "content": str(tool_result)},
    ],
)

重要な詳細は行数ではありません。どちらの選択もアプリケーションロジックに永続的に埋め込まれる必要がないことです。プロンプトが変わるとモデルも変わり、タスクが変わるとツールも変わります。

コスト管理は両方の層に属する

モデルとツールのコストは異なる単位を使用するため、別々に測定する必要があります。

モデル層では、解決されたモデルがトークン価格を決定します。AIHubMixはその決定を追跡可能にし、開発者がルーティングポリシーを選択したり、APIキーが使用できるモデルを制限したりできるようにします。ルーチンステップはコストやレイテンシを優先でき、ユーザー向けの出力は品質を優先できます。

ツール層では、エンドポイントは呼び出しごとまたは結果ごとに料金を請求する場合があります。Monidは実行前に検査中に価格を公開します。エージェントは予算を超えるエンドポイントを拒否したり、確認済みのオプションを優先したり、異常に高価な操作の前に承認を求めたりできます。

有用な生産管理には以下が含まれます：

各APIキーのモデル許可リストまたは価格上限。
タスクごとの最大ツール呼び出し予算。
規制データのためのプロバイダーまたはエンドポイント許可リスト。
モデルルーティング決定をツール呼び出しおよび最終回答に接続するログ。
不可逆的または敏感なアクションの前の明示的な確認。
ツールデータが信頼できない入力として扱われ、指示としてではなく出力検証。

この分割はコストデバッグを容易にします。実行が高くなると、トークンログはエージェントが過剰に推論したかどうかを示し、ツールログはエージェントが過剰に取得したかどうかを示します。修正は異なり、アーキテクチャはその区別を保持する必要があります。

信頼性には新鮮な契約と可視的な決定が必要

動的選択は予測不可能な動作を意味してはなりません。

モデル側では、AIHubMixは各リクエストの解決されたモデルとルーティングポリシーを報告します。セッションの一貫性は、マルチターン作業全体でモデルの一貫性とプロンプトキャッシュの利点を保持でき、必要に応じて不健康なモデルから離れるフォールバック動作を持つことができます。

ツール側では、エージェントは有料呼び出しを行う前に現在のエンドポイントスキーマを検査します。発見結果には候補を比較するために必要な情報が含まれ、実際の呼び出しの結果は最終的な完了に渡される唯一の外部証拠となります。

これらの制御を合わせることで、有用な監査トレイルが作成されます：

user goal
  -> routing decision and resolved model
  -> discovered tool candidates
  -> inspected schema and price
  -> selected endpoint and result
  -> final model decision and grounded response

そのトレイルは、多くのモデルや多くのAPIにアクセスすること以上に価値があります。それは、エージェントが各選択を行った理由と、その回答を支持する証拠を説明します。

両方の層が必要ないとき

すべてのワークフローがランタイム選択の恩恵を受けるわけではありません。

アプリケーションが1つの安定したプロンプトを1つのベンチマークモデルに送信する場合、そのモデルを直接指定する方がルーティングよりも簡単で決定的です。スケジュールされたパイプラインが常に1つの既知のAPIを呼び出す場合、そのAPIを直接統合する方が発見層を追加するよりも明確かもしれません。

2層アーキテクチャは、バラエティが作業負荷の一部であるときにその地位を得ます：

プロンプトが十分に異なるため、最適なモデルがステップごとに変わります。
エージェントが複数のモデル呼び出しを行い、累積コストやレイテンシを制御する必要があります。
必要なツールはビルド時に完全に予測できません。
外部データは最新でなければならず、そのソースは可視でなければなりません。
チームは、各機能のために新しいベンダー統合を追加することなく、機能を追加したいと考えています。

モデル層、ツール層、または両方を、アプリケーションが実際に行う必要がある決定に応じて使用してください。

依存関係ではなく決定に基づいてエージェントを構築する

生産AIエージェントは、どれだけのモデルやAPIにアクセスできるかによって定義されるのではありません。現在のステップに対して適切な能力を選択できるか、予算内で操作できるか、何が起こったかを説明できるかによって定義されます。

AIHubMixは、エージェントに統一されたモデルエンドポイントとコスト、品質、レイテンシの優先順位に基づくリクエスト時のルーティングを提供します。Monidは、ランタイムツール発見、現在のスキーマ、可視価格、および外部プロバイダーにわたる実行を提供します。

1つの層はエージェントがどのように考えるかを決定します。もう1つの層は、どのように情報を見つけて行動するかを決定します。それらの決定を分離することで、拡張、観察、制御が容易なエージェントが生まれます。

AIHubMixクイックスタートから始め、その後、Monidを通じてツール側を接続してください。

FAQ

AIエージェントのためのモデルルーティングとは何ですか？

モデルルーティングは、タスクの種類、能力、コスト、レイテンシなどの要因に基づいて各リクエストのモデルを選択します。AIHubMixでは、modelをautoまたはauto:quality_firstのようなポリシーに設定することで、リクエスト時の選択が可能になり、OpenAI互換のAPIを保持します。

LLMがすでに知識を持っている場合、なぜAIエージェントはツールを必要とするのですか？

LLMは受け取ったコンテキストとトレーニング中に学んだことから回答を生成します。現在の価格を信頼できる方法で知ったり、プライベートデータベースを照会したり、接続されたツールなしで外部アクションを実行したりすることはできません。ツールはライブデータと実行を提供し、モデルは結果を計画し解釈します。

モデルゲートウェイはMCPサーバーやツールプラットフォームと同じですか？

いいえ。モデルゲートウェイは推論リクエストをモデルにルーティングします。MCPサーバーやツールプラットフォームは、エージェントに外部機能を公開します。これらは補完的な統合問題を解決し、一緒に使用できます。

AIHubMixとMonidは独立して使用できますか？

はい。AIHubMixは動的ツール要件のないアプリケーションのためにモデル呼び出しをルーティングできます。Monidは別のモデルプロバイダーやゲートウェイを使用するエージェントにツール発見を提供できます。両方を使用することは、エージェントが両方の層でランタイム選択を必要とする場合に便利です。

自動ルーティングを監査可能に保つにはどうすればよいですか？

各タスクのために解決されたモデル、ルーティングポリシー、ツール候補、検査された価格、選択されたエンドポイント、および返された結果をログに記録します。AIHubMixはレスポンスにモデルルーティングの詳細を公開し、Monidは実行から発見と検査を分離するため、ツールの決定を有料呼び出しの前に記録できます。