エージェント実行基盤の設計：適切なモデルの選び方

モデルルーティングは、ランキングを競うのではなく、運用を統制するための課題です。まずプライバシーとデータの保存・処理地域の要件から利用可能なモデル群を定め、その中でタスクの成功と出力品質に基づいて有効な経路を選びます。トークン数、レイテンシー、コストの最適化はその後です。ローカルモデルも有効ですが、通常は、より細かなタスク分解、情報検索、決定論的な検証が必要です。

成果を生む単位はエージェント実行基盤

企業向けエージェントは、長いシステムプロンプトを与えたモデルではありません。依頼の受付、コンテキストの構築、ポリシーに基づく判定、モデル実行、ツールへのアクセス、状態管理、検証、再試行、可観測性、エスカレーションを含むエージェント実行基盤です。モデルは、その中の交換可能な一部品です。

実行基盤の外で行うモデル比較は、本番での結果を予測できないことがよくあります。ベンチマークで優秀でも、組織固有の形式、権限、用語、ワークフローに対応できないモデルもあります。自由なチャットでは弱く見えても、タスクを分解し、根拠を検索し、決定論的な制約に照らして出力を確認すれば、安定して働くモデルもあります。

そのため、「最良のモデル」を選ぶという捉え方は適切ではありません。選ぶべきなのは、定義したタスクに対して許可される実行経路です。一つのモデル、複数の専門的な呼び出し、ローカルモデル、ホスト型モデル、あるいはモデルを使わない処理でも構いません。検証済みの業務状態に到達して初めて成功です。

アーキテクチャにも、この交換可能性を明示すべきです。スレッド型AIオペレーション層は、ユーザーの文脈と実行主体を分離するため、モデルを変更してもルーティング、状態、認可、検証を安定して維持できます。

第1段階：プライバシー、保存・処理地域、契約上の利用条件

ルーティングは品質評価より前に始まります。最初に問うのは、そのモデルのエンドポイントにデータを渡し、操作を実行させてよいかです。

タスクの分類ごとに利用条件を定めます。対象は次のとおりです。

データ分類と、個人情報・機密情報・規制対象情報・輸出管理対象情報の有無
必要な処理・保存地域
保持、ログ記録、学習への利用、削除の条件
再委託先と越境移転の制約
暗号化、本人確認、アクセス制御の要件
監査ログとインシデント通知の義務
ツールによる本番システムの読み取り・変更の可否
検索で取得した文書を管理環境の外へ出せるか

これらは公開後に付け足すポリシー文ではなく、ルーティングの制約です。制限対象のデータを含むタスクでは、条件を満たさないエンドポイントを除外します。情報のマスキングによって制約の少ない派生タスクを作れる場合もありますが、マスキング自体が信頼でき、記録され、対象形式で検証済みでなければなりません。氏名を置き換えても、一意の口座番号や商業上機密性の高い事実の組み合わせを残せば、実質的な匿名化にはなりません。

データの保存・処理地域の要件は、周辺の実行基盤にも適用されます。プロンプトを承認済み地域のエンドポイントに送っても、実行記録、ベクトルインデックス、エラーログ、人によるレビュー待ちのデータが別の地域に保存されれば、問題は解決しません。依頼の受付、一時ファイル、情報検索、推論、ツールの結果、監視、バックアップ、サポート担当者のアクセスまで、データ経路全体を調べます。

この判定で得られるのは許可された経路であり、最良の候補ではありません。ローカルモデルが必須のタスクも、選択肢の一つとなるタスクも、不適切なタスクもあります。ポリシーで選択肢を絞り、証拠で選定を完了します。

第2段階：タスクの成功、その後に品質

利用可能なモデル群の中で、最初に評価するのはタスクの成功です。ワークフローは意図した状態に到達したでしょうか。調査なら、根拠があり参照先を確認できる回答が得られたか。抽出なら、ソースの該当箇所に紐付いたスキーマ適合レコードが得られたか。業務上の操作なら、有効なドライラン計画、承認済みの変更、実行後の再読み取りによる確認ができたかを見ます。

タスクの成功は、回答品質より広い概念です。流暢でも、パースできず、利用できない証拠を引用し、禁止ツールを呼び出す回答は実行失敗です。逆に、短い出力でも、処理を確実に完了すれば成功です。

評価セットは、代表的な実務から定義します。各ケースに、入力、使用を許可された根拠、期待する状態遷移、失敗と判定する条件、採点基準を含めます。次のケースを網羅します。

件数の大部分を占める通常ケース
ポリシーや品質の閾値に近い境界ケース
欠損、古いデータ、重複、矛盾を含む入力
ツールや依存先の障害
プロンプトインジェクションや信頼できないコンテンツによる攻撃の試み
実行を見送るかエスカレーションすべきケース
必要に応じた言語・形式の違い

主観的な好みより先に、必須の制約を判定します。スキーマ適合、正しいツール選択、認可の遵守、引用の裏付け、必要な実行見送りは合否で判定します。意味の網羅性、明確さ、有用性は採点基準で評価できます。文章の完成度が高くても、検証済みタスクの完了率が低いことは補えません。

業務領域に特化したエージェントスキルでは、手順や必須確認を明示的な成果物として表せるため、会話ごとに探り直す必要がなく、評価を安定させられます。

第3段階：トークン数、レイテンシー、コスト

成功と品質の基準を満たした経路だけを対象に、効率を最適化します。見るべき単位は入力トークンの単価ではなく、検証済みタスク当たりのコストです。

安価なモデルでも、再試行、レビュー、下流での修正が増えれば高くつきます。最初の応答が速くても、実行基盤が無効な出力を何度も修復すれば、全体のレイテンシーは悪化します。大きなコンテキストウィンドウは無差別な読み込みを促し、コストと誤りの発生機会を増やすことがあります。

以下の指標を測定します。

評価項目	実行基盤全体の指標
成功	対象となる試行に対する検証済み完了の割合
品質	初回合格率、欠陥の重大度、検査をすり抜けた欠陥の割合
トークン数	検証済み完了当たりの入力、キャッシュ入力、出力、再試行のトークン数
レイテンシー	開始から検証済み状態までの時間の中央値と遅い側の分布
コスト	検証済み完了当たりの推論、情報検索、ツール、レビュー、手戻りの費用
安定性	時期、形式、需要の種類による性能の変動

正規化した指数を使えば、見せかけの精密さを示さずに社内比較を分かりやすくできます。現在承認されている経路について、品質を考慮したコストと端から端までのレイテンシーをBaseline = 100とします。候補経路のコスト指数が低くても、タスク成功率の低下、例外処理の増加、レビュー時間の増加を隠していれば有用ではありません。外部報告に正規化した値を使う場合も、監査用に元の件数と定義を保持します。

そのうえで対象を絞って最適化します。プロンプトキャッシュで繰り返し使うポリシーの文脈を減らし、検索で取得する箇所を短くして注意の分散を抑え、ツールの読み取りを並列化してレイテンシーを改善できます。小さいモデルで分類し、曖昧な情報の統合はより高性能な経路に任せる方法もあります。決定論的なコードで推論呼び出し自体をなくせる場合もあります。

ユーザーではなくタスクを振り分ける

部署別の固定ルーティングは、能力と費用を浪費します。同じ人でも、公開情報の要約、機密情報の比較、照合、本番への書き込みを依頼します。これらは利用条件、品質、権限の要件が異なるタスクです。

次のタスク属性に基づいて振り分けます。

task_type: extract | classify | synthesize | plan | act | verify
data_class: public | internal | confidential | restricted
residency: approved_regions
authority: read | recommend | dry_run | approved_write
evidence: source_ids and freshness requirements
output_contract: schema or rubric version
risk: consequence and reversibility
latency_budget: interactive | asynchronous | batch

ルーターは可能な限り決定論的にします。データ分類、保存・処理地域、権限はポリシー上の判断であり、依頼が「機密らしい」とモデルが推測することに依存させてはいけません。分類器が受付を補助しても、不確実な場合は安全な経路を選ぶか、具体的な確認を求めます。

モデルは、許可された分岐の中で選択します。経路とともに、ポリシー版、モデル版、プロンプトまたはスキルの版、取得した根拠の識別子、ツール呼び出し、検証結果、最終状態を記録します。この実行記録により、障害を診断し、比較を再現できます。

ローカルモデルに異なる実行基盤が必要な理由

ホスト型のエンドポイントに送っていた同じプロンプトをローカルのハードウェアへ移すだけでよいかのように、ローカル推論が語られることがあります。しかし、それだけで十分なことはまれです。ローカルモデルは、強いプライバシー統制、予測可能な追加処理コスト、オフライン動作、範囲を限定したタスクでの低レイテンシーを提供できます。一方、その時点で最も強力なホスト型モデルと比べ、指示への追従、ツール選択、長いコンテキストでの信頼性、多言語での一貫性が弱い場合もあります。

この違いを隠すのではなく、実行基盤を変えるべきです。

より細かく分解する

一度に一つの、範囲を限定した変換をモデルへ渡します。文書選択、抽出、分類、草稿作成、検証を分離し、各段階の入力と出力の仕様を狭く定めます。分解によって同時に処理する指示が減り、決定論的な統制で誤りの伝播を止められる確認点ができます。

ローカル経路では、まず関連箇所を特定し、主張をスキーマに抽出し、各主張をソースの該当箇所に対応付け、承認された主張だけから草稿を作る流れが考えられます。大きなプロンプト一つより処理の調整は増えますが、評価と修正が容易になります。

取得量を絞り、根拠の質を高める

リポジトリや文書群全体をコンテキストに入れることは、情報検索ではありません。選択の問題をモデルへ移しているだけです。ローカル経路では、構造化インデックス、メタデータの絞り込み、新しさの条件、短くまとめた根拠が有効です。検索結果にはソースの識別子と該当箇所を含め、後段で回答の裏付けを確認できるようにします。

情報検索とWeb検索を備えたローカルAIアシスタントの構築で紹介する実践的なパターンは、ローカル推論がモデルの記憶だけでなく、周辺のツールと根拠の層に依存する理由を示しています。

決定論的に検証する

可能な限り、スキーマ、パーサー、許可リスト、データベース制約、計算、ポリシーエンジン、実行後の再読み取りによる確認を使います。モデルが変更を提案しても、必須フィールドの存在、識別子の解決、合計の照合、実行権限、操作後の状態と承認済み計画の一致はコードで確認すべきです。

決定論的に確認できない意味上の評価には、採点基準と独立したレビュー経路を使います。同じ呼び出しに、自分の出力の生成、採点、承認を兼ねさせてはいけません。モデルによる評価を使うなら、人の判断に照らして校正し、最終的な権限判断の外に置きます。

段階的な振り分け、代替経路、実行の見送り

有用なルーターは、対象タスクをすべて最も強力なモデルへ送りません。そのタスク分類で受け入れ基準をすでに満たした最も安価な経路から始め、観測可能な失敗時に上位経路へ送る段階的な方式を使えます。

エスカレーションのシグナルは具体的にします。修復後も無効なスキーマ、根拠不足、ソースの矛盾、校正済み信頼度の低下、ツールの利用不能、ポリシーの境界、検証の失敗などです。トークン数だけでは品質のシグナルになりません。モデルが口頭で「不確実」と述べても、そのタスクで校正されていなければ同様です。

代替経路にも意味上の一貫性が必要です。主経路が保存・処理地域の要件を満たせず失敗した場合、代替経路でその要件を無視してはいけません。ツールを呼び出せないとき、チャットだけの経路が操作を実行したかのように装ってはいけません。根拠が古ければ、強いモデルを使っても新しくはなりません。

タスクの仕様がエスカレーションを求める場合、実行を見送ることは成功です。タスク成功指標に「正しく拒否またはエスカレーションした」を含めます。そうしなければ、根拠や権限を超える作業を試みるシステムが評価されてしまいます。

状態、バージョン、再現性

モデルとエンドポイントは変化します。モデル名が同じでも、バージョン、配信設定、システムプロンプト、検索インデックス、ツール定義、ポリシーの変更により挙動は変わります。実行基盤では、実行仕様全体をバージョン管理しなければなりません。

最低限、次の情報を記録します。

タスクとポリシーのバージョン
モデル提供元、エンドポイントの地域、モデルのバージョン
プロンプト、スキル、ツールスキーマのバージョン
検索クエリ、ソースID、データ鮮度を示すタイムスタンプ
サンプリングとタイムアウトの設定
検証処理のバージョンと結果
再試行、代替経路、人によるレビューの記録
最終操作と、実行後の再読み取りによる確認の証拠

運用の再現性は、入力、設定、外部への操作、検証の証拠から生まれ、制限なく保存した思考過程から生まれるものではありません。機密性のある実行記録は、企業のデータ最小化と保持のルールに従います。

プロジェクト固有のエージェントの調整で述べた手順の徹底も関連します。永続的な作業環境と再利用可能な手順は、変更、同時実行、障害のパターンを観測できて初めて役立ちます。

実務的な選定プロセス

段階的な選定プロセスを用います。

タスク分類を定義します。抽出、情報の統合、計画、操作、検証を分け、一つの平均スコアにまとめません。
利用条件を適用します。プライバシー、保存・処理地域、契約、権限の要件を満たさない経路を除外します。
評価セットを作ります。根拠を固定し、代表的なケース、境界ケース、攻撃を想定したケース、必ずエスカレーションすべきケースを用意します。
実際の実行基盤で経路を動かします。情報検索、ツール、タイムアウト、再試行、検証処理を含めます。
必須条件の違反を確認します。スキーマ、根拠、認可、実行見送りの要件に違反する経路を却下します。
タスクの成功と品質を採点します。平均的な性能だけでなく、少数の重大な欠陥も調べます。
全体の効率を測定します。検証済み完了当たりのトークン数、レイテンシー、推論コスト、レビュー時間、再試行、手戻りを比較します。
シャドーモードまたはドライランで試験運用します。未検証の書き込みを許可せず、実際の需要の変化を観測します。
タスク分類ごとに承認します。経路、制限、代替経路、判断の有効期限を記録します。
継続的に再評価します。モデル変更、ドリフト、新しいデータ分類、例外の反復、大幅な価格変更を契機にレビューします。

成果物は恒久的な順位表ではなく、バージョン管理されたルーティングポリシーです。

意思決定ルール

意思決定の順序こそ、責任あるモデルルーティングの核心です。プライバシー、保存・処理地域、契約上の条件が、何を利用してよいかを決めます。検証済みのタスク成功と品質が、何に実行能力があるかを決めます。残った経路の中で、トークン数、レイテンシー、総コストが効率を決めます。

順序を逆にすると、予測可能な失敗を招きます。コスト優先では、機密性の高い作業を利用不可のエンドポイントへ送ったり、低品質な作業を高価なレビューの反復へ回したりします。モデル優先では、好みのベンダーに合わせて業務を曲げます。ベンチマーク優先では、企業が実際には行わないかもしれないタスクに最適化します。

当社は、モデルを変更してもポリシー、状態、根拠が失われない実行基盤を設計します。ホスト型モデル、ローカルモデル、決定論的サービスには、それぞれ役割があります。正しい選択は、定義したタスクを完了し、品質基準を満たし、結果を証明できる、利用条件を満たした最小のシステムです。

スレッド型AIオペレーション層の参照アーキテクチャ：ルーティング、型付き状態、認可、実行、検証
業務領域に特化したワークフロー向けAIエージェントスキルの構築：手順と業務領域固有の確認事項の外部化
Web検索を備えたローカルAIアシスタントの構築：MCPとOllamaのセットアップ：ローカル推論、情報検索、ツールの実践的な構成例