AIエージェントはモデルを呼び出すべきです

MLAT論文では、本番環境での試験運用が紹介されています。エージェントがXGBoostの価格モデルをツールとして呼び出し、ホールドアウトデータでR^2 = 0.807を達成し、平均絶対誤差は3688 USDでした。さらに、提案書の作成時間を数時間から10分未満に短縮しています。¹

重要なのは、その価格モデルそのものではありません。重要なのは境界です。スコア、予測、価格、リスク推定、ランキング、分類、検出が必要なタスクでは、エージェントはその仕事のために学習されたモデルを呼び出すべきです。流暢な文章で統計的な答えを即興するべきではありません。

学習済みモデルは、エージェントのツールレジストリに置くべきです。LLMは、いつ呼び出すかを判断し、結果を説明し、不足している入力を尋ね、例外を処理できます。数値推定、信頼度のシグナル、バージョン付きの出力、証拠の記録を生成するのは、学習済みモデルの役割です。

要約

LLMエージェントは、作業の調整に向いています。一方で、範囲が定まった予測では、統計モデルや機械学習モデルのほうが適していることが少なくありません。Machine Learning as a Toolという考え方では、学習済みMLモデルを、検索、データベース、API、その他のツールと同じように、エージェントのワークフロー内で呼び出せるツールとして扱います。¹

このパターンにより、チームは明確な運用ルールを持てます。作業全体の調整はエージェントに任せ、専門的な推論は専門モデルに任せる、というルールです。結果には、モデルのバージョン、入力スキーマ、出力スキーマ、キャリブレーションに関する注記、追跡可能な呼び出し記録を含めるべきです。この境界がないと、LLMは確信に満ちた口調で、モデルを推測に置き換えてしまう可能性があります。

重要なポイント

• エージェント開発者向け: 学習済みモデルは、スキーマ、バージョン、失敗時の挙動を持つ型付きツールとして公開しましょう。
• MLチーム向け: エージェントは呼び出し元として扱い、モデル評価、永続化、レジストリ運用の規律の代替と見なしてはいけません。
• プロダクトチーム向け: 数値がモデル呼び出し、ルール、データベース、LLMによる説明のどれから来たのかを示しましょう。
• セキュリティチーム向け: モデルツールにも、エージェントキーにはリスク予算が必要ですで述べた権限範囲の考え方を適用しましょう。
• レビュー担当者向け: 回答を信頼する前に、モデル呼び出し、モデルバージョン、入力、出力、信頼度の限界を求めましょう。

なぜエージェントはモデルのふりをせず、モデルを呼び出すべきなのでしょうか？

LLMは価格について説明できます。価格モデルは、学習した特徴量から価格を推定できます。LLMはリスクを要約できます。リスクモデルは、検証済みの特徴量セットからリスクをスコア化できます。LLMは解約を説明できます。解約モデルは、学習プロセスに結びついた確率を返せます。

これらは別の仕事です。

エージェントツールは、すでにこの分担を可能にしています。OpenAIのAgents SDKでは、JSON Schemaパラメータを持つ関数ツール、ツール呼び出しハンドラ、構造化されたツール出力が説明されています。² Anthropicのツール利用ドキュメントでは、ClaudeがJSON Schema入力を通じて、クライアント側ツールや外部関数を呼び出す方法が説明されています。³ エージェントは、検索、カレンダー更新、シェルコマンド、データベースクエリに使うのと同じツールパターンで、モデル予測を依頼できます。

問題は、チームがこの分担を省略したときに起こります。LLMが数値を出せるからという理由で、LLMに推定を求めてしまうのです。答えはすぐに返ってきます。文章はもっともらしく見えます。インターフェース上には、その数値が学習済み推定器ではなく、パターン補完から生まれたことを示す手がかりがありません。

これは弱い契約です。ユーザーには、何が結果を生み出したのかがわかりません。レビュー担当者は、モデルバージョンや入力特徴量を確認できません。運用担当者は、呼び出しを再現できません。プロダクトは、なぜ答えが変わったのかを説明できません。

証拠ゲートの考え方は、ここにも当てはまります。確信は証拠ではありません。モデル呼び出しは証拠を生み出せます。文章による推測は、たいていそうではありません。

MLATパターンは何を加えるのでしょうか？

MLATはMachine Learning as a Toolの略です。この論文では、学習済みMLモデルを、会話の中で定量的な推定が必要になったときにLLMエージェントが呼び出せる第一級のツールとして位置づけています。¹

論文の試験システムであるPitchCraftは、2つのエージェントを使います。リサーチエージェントが並列ツール呼び出しで見込み客の文脈を集めます。ドラフトエージェントはXGBoostの価格モデルを呼び出し、その後、構造化出力を通じて提案書を書きます。¹ 価格設定はMLモデルが担当し、文脈、組み立て、説明はLLMが担当します。

この分担が重要なのは、次の2つの悪い設計を避けられるからです。

それでも、エージェントの役割は残ります。価格設定に必要な入力が不足していると判断できます。足りない項目をユーザーに尋ねられます。モデルを呼び出す前に、検索やCRMツールを呼び出せます。その推定値が自分自身の権威ではなく、モデルから来たものだと説明できます。

これが正しい役割分担です。LLMは調整し、学習済みモデルは予測します。

モデルツールは何を返すべきでしょうか？

モデルツールは、むき出しの数値だけを返すべきではありません。本格的なモデルツールは、証拠オブジェクトを返すべきです。

この出力形式により、モデルツールはエージェント実行記録は実行時の契約ですと両立します。エージェントが価格モデルを呼び出したなら、実行記録にはそのモデル呼び出しが表示されるべきです。モデルを使わずに数値を書いたなら、その欠落が明らかになるべきです。

同じ考え方は、レビューパケットは新しい最終回答ですにもつながります。価格だけを含む最終回答は弱いものです。モデル呼び出しの記録、モデルバージョン、特徴量のスナップショット、信頼度に関する注記があれば、レビュー担当者は確認すべき対象を持てます。

モデルレジストリはどこに入るのでしょうか？

ツールで包むことは、MLOpsの代替ではありません。MLOpsをエージェントの実行環境に見える形で接続することです。

MLflowのモデルレジストリドキュメントでは、モデルの系譜、バージョン管理、エイリアス、メタデータタグ、ライフサイクル情報が説明されています。⁴ このレジストリ層が重要なのは、そもそもプラットフォームがバージョンを追跡していなければ、エージェントワークフローがモデルバージョンを引用できないからです。

scikit-learnのモデル永続化ドキュメントは、提供側から関連する点を示しています。永続化の選択にはセキュリティと移植性のトレードオフがあり、ONNXはPython環境なしでモデルを提供できます。一方、pickleベースの経路では、提供元を信頼する必要があります。⁵ エージェントが予測を求めたからといって、モデルツールが安全でないモデル成果物をエージェントに持ち込むべきではありません。

最小限の運用スタックは次のようになります。

チームはしばしば、これらの層をpredictという1つのエンドポイントに押し込めます。デモではそれで動きます。しかし、エージェントが予測を顧客メール、営業提案、引受メモ、インフラ計画、医療トリアージの下書きへ連鎖させ始めると、その近道は破綻します。

プロダクトに必要なのは、魔法のエンドポイントではなく、モデルの契約です。

プロダクトはモデル出力をどう見せるべきでしょうか？

UIは、回答がモデルツールから来たときに、そのことをユーザーへ伝えるべきです。

よくないインターフェース文言は、出所を隠します。

よりよい文言は、本番での生成経路を明示します。

この区別は、ユーザーの尊厳を守ります。数値が検証済みモデル、モデルカード、ビジネスルール、言語モデルの補完のどれから来たのかを、ユーザーに推測させるべきではありません。エージェント型デザインとは制御面のデザインですでは、エージェントプロダクトには監督と制御のための画面が必要だと論じています。モデルの出所も、その画面の1つです。

モデルカードは、ドキュメント層で同じ問題を支えます。Model Cards論文は、モデルの特性、想定用途、指標、評価文脈を構造化して報告することを提案しています。⁶ エージェントのインターフェースは、この考え方を実行時に借りられます。すべてのモデル回答は、そのモデルがどの種類の主張をしたのかをユーザーやレビュー担当者が理解できるだけの文脈を持つべきです。

エージェントは何を拒否すべきでしょうか？

モデルを理解しているエージェントは、いくつかの誘惑に抵抗すべきです。

モデルツールが利用できないときに、モデル出力を作り上げることを拒否すべきです。価格モデルが失敗したと伝えることはできます。人間がラベル付けした概算を出すかどうかを尋ねることもできます。しかし、モデルを黙って置き換えてはいけません。

証拠なしにモデルの適用範囲を広げることも拒否すべきです。中堅SaaS企業のデータで学習された解約モデルは、プロンプトで頼まれたからといって、あらゆる事業の健全性を占う万能モデルにはなりません。

不確実性を隠すことも拒否すべきです。モデルが区間を返すなら、プロダクトに明確な表示ルールがない限り、それを自信満々の単一数値へ潰すべきではありません。

不足した特徴量や捏造した特徴量でモデルツールを呼び出すことも拒否すべきです。エージェントは入力を集め、追加質問をし、フィールドを不明として扱えます。都合のよい作り話で特徴量ベクトルを埋めるべきではありません。

モデルの権威を、行動の権限として扱うことも拒否すべきです。モデルは不正リスクを推定できます。だからといって、エージェントがアカウントを凍結してよいことにはなりません。行動には、エージェントキーにはリスク予算が必要ですで述べた、範囲を限定したキーの規律が引き続き必要です。

判断ルール

エージェントワークフローを作るときは、このルールを使います。

このルールにより、LLMには価値ある仕事が残ります。ただし、他のすべてのシステムになりすますことは許しません。ワークフローを調整し、出力を説明し、メッセージを下書きし、よりよい質問を投げられます。しかし、流暢に話せるからといって、価格モデル、リスクモデル、不正検知モデル、ランキングモデル、ポリシーエンジンになることはできません。

最良のエージェントプロダクトは、1つのモデルに会社全体のふりをさせません。それぞれのシステムが、証明できる仕事を担うためのツール接点を作るはずです。

FAQ

これは従来型の機械学習モデルだけの話ですか？

いいえ。同じパターンは、専門的な推定器やスコアラー全般に当てはまります。勾配ブースティングモデル、分類器、ランキングシステム、予測モデル、ルールエンジン、検索スコアラー、ドメイン特化型の検出器などです。重要なのはアルゴリズムではありません。出力をめぐる契約です。

なぜLLMに直接推定させないのですか？

大まかな定性的推定で十分な場合もあります。その場合、プロダクトはそう明示すべきです。ユーザーが価格、リスクスコア、予測、適格性判断を必要としているなら、答えは、追跡可能な入力と制限を持つ検証済みモデルまたはルール経路から出るべきです。

モデルツールを使えば、答えは自動的に正しくなりますか？

いいえ。モデルツールも、古くなっていたり、偏っていたり、キャリブレーションがずれていたり、誤用されていたり、有効範囲の外で使われていたりする可能性があります。モデルツールが改善するのは、検査しやすさです。評価、監視、人間によるレビューは不要になりません。

最小限のモデルツール契約とは何ですか？

入力スキーマ、出力スキーマ、モデルバージョン、予測、信頼度または注意書き、エラー形式、タイムアウト、記録IDから始めましょう。モデルが金銭、アクセス、安全、顧客向け判断に影響する場合は、特徴量名、レジストリリンク、モデルカード参照、キャリブレーション注記も追加します。

これはエージェントUXをどう変えますか？

インターフェースは、重要な出力の出所を明示すべきです。回答がモデル呼び出し、取得したドキュメント、ビジネスルール、人間の承認、LLMによる統合のどれから来たのかを、ユーザーが確認できるようにします。その出所によって、答えにどれだけ信頼を置けるかが変わります。

参考文献