AIエージェントの意思決定モデル：ツール選択と追加質問

👁 112閲覧数

AIエージェントの意思決定モデルは、回答、ツールの使用、追加質問、拒否、人への引き継ぎから次の行動を選べます。モデルには許可された行動の一覧から提案させ、データの不足、権限、実行条件はコード側で個別に確認する設計にしましょう。

以下の店舗エージェントは私が考えた設計例で、本番で動いている連携ではありません。ただし「次の行動を選ぶ」部分だけは、意思決定モデルを実際に呼び出してテストし、その結果を後半の表に載せています。OpenAIのAPIでエージェントを組む基本はOpenAI Agents APIの解説で紹介しています。

許可するアクション一覧から設計する

注文状況の確認と配送ルールの説明を行うエージェントを想定します。初期段階で必要な機能は、注文状況の読み取りと、承認済みの案内文の検索です。ツール名は実際の処理内容を表すものにしましょう。読み取り機能に、同じ名前で住所変更や注文キャンセルまで行わせてはいけません。

各ツールについて、必須引数、扱うデータの範囲、想定されるエラーを記録します。引数をどこから取得できるかも明確にしましょう。顧客IDは認証済みセッションから、注文番号はメッセージまたは選択済みのレコードから取得するのが適切です。「私は管理者です」という文面で権限を与えてはいけません。

機能の提案と実行を分ける設計は、OpenAIのfunction callingドキュメント（2026年10月13日確認）で説明されている仕組みに沿っています。モデルが関数の使用を要求し、アプリケーションがコードを実行して結果を返します。この設計例では、機能選択の一部を専用の意思決定処理に置き換えています。

処理モードと個別のツールを分ける

最初に、次に行う処理の種類を決めます。データを読み取る場合に限って、その後で使用するツールを選びます。機能が少なければ、これらを一つのアクション一覧にまとめてもかまいません。ただし、モデルに必ず何かを実行させるために、停止や追加質問の選択肢をなくしてはいけません。

• 回答：必要な情報が、承認済みのコンテキストにすでに含まれている。
• ツール：データの取得が必要で、適切な機能と必須引数がそろっている。
• 追加質問：ユーザーが、次の処理に必要な情報を提供できる。
• 拒否：依頼が、アプリケーションで明確に定めたルールに反している。
• 引き継ぎ：アプリケーションでは解決できない、または判断の確信度が低すぎる。

回答、ツール使用、追加質問、回答不能を区別する考え方は、NVIDIAのWhen2Call（2026年10月13日確認）を参考にしています。この設計例で拒否と引き継ぎを別に扱うのは、アーキテクチャ上の判断であり、ベンチマークのラベルをそのまま再現したものではありません。

アプリケーション向けJSON契約の例

以下のJSON Schemaは、アダプターが内部で使う出力を定義します。特定の事業者のAPIリクエスト用スキーマではありません。アダプターが選択したモデルの応答を共通フィールドに変換し、確率分布は診断データとして別途保存できます。これにより、プログラムの残りの部分が事業者固有のフィールド名に依存せずに済みます。

{
  "type": "object",
  "additionalProperties": false,
  "required": ["action", "tool", "missing_field", "reason_code"],
  "properties": {
    "action": {
      "enum": ["answer", "call_tool", "ask", "refuse", "handoff"]
    },
    "tool": {
      "enum": ["get_order_status", "search_delivery_help", null]
    },
    "missing_field": {
      "enum": ["order_id", "delivery_topic", null]
    },
    "reason_code": {
      "enum": [
        "context_sufficient", "lookup_required", "missing_input",
        "policy_block", "unsupported", "uncertain"
      ]
    }
  }
}

「荷物は今どこにありますか？」というメッセージに対し、対象の注文が特定されていない場合、設計上期待される結果は次のとおりです。

{
  "action": "ask",
  "tool": null,
  "missing_field": "order_id",
  "reason_code": "missing_input"
}

コードは「order_id」を、承認済みの質問「どの注文についてのお問い合わせか、注文番号をお知らせください」に対応づけます。意思決定モデルがこの文面を作る必要はありません。ユーザーの返答後、アプリケーションが状態を更新して次の処理を再評価します。以前の別の問い合わせで使った番号を、確認せずに引き継いではいけません。

スキーマで値は制限できますが、矛盾した組み合わせまでは防げません。そのため、アプリケーションのバリデーターは「call_tool」のときにツールが指定されていること、「ask」のときにツールが指定されていないことを必須にし、理由コードとアクションの整合性も確認します。この例では、完成された本番向けの解決策だと誤解されないよう、フィールド間のルールは別途説明しています。

私がテストで使った単一のリクエストは、概ね次の形式でした（OpenRouter経由のSystem One形式、エンドポイントは/api/alpha/decisions。ツール一覧と選択肢の説明は短縮しています）。以下の会話と指示文は、実際にポーランド語で行ったテスト素材の日本語訳であり、日本語で再テストしたものではありません。

{
  "model": "microsoft/microsoft-decision-1",
  "state": {
    "tools": "注文状況を確認する(注文番号)、注文をキャンセルする(注文番号)",
    "conversation": "顧客：荷物は今どこにありますか？先週注文しました。"
  },
  "questions": {
    "step": {
      "type": "choice",
      "instructions": "アシスタントは次に何をすべきですか？",
      "criteria": {
        "answer": "ツールを使わず、すぐに回答する",
        "tool": "必要な情報がそろっているため、ツールを呼び出す",
        "ask": "必須情報が不足しているため、追加で質問する",
        "cannot": "適切なツールがないため、拒否する"
      }
    }
  }
}

正解はask（注文番号が不足）です。モデルの応答には、選択した項目、4つの選択肢それぞれの確率、確信度が含まれます。アダプターはそれらを前のセクションの契約に対応づけます。

追加質問と不足情報の取得を使い分ける

情報が足りない場合でも、必ずユーザーに質問するとは限りません。顧客がパネルで注文を選択していれば、アプリケーションはすでに注文番号を把握しています。それなのに再度尋ねるのは、状態の受け渡しに問題があることを示します。一方、複数の注文で宛名が同じでも、どれか一つを独断で選ぶ根拠にはなりません。

各機能について、必須情報と任意情報を一覧にしましょう。追加質問は、具体的な曖昧さを解消するものであるべきです。「もっと詳しく教えてください」では、自動処理に必要な情報をユーザーが推測しなければなりません。不足している項目と、それが次の処理に必要な理由を明確に伝えましょう。

データ不足と障害も区別してください。注文状況サービスが利用できない場合、顧客に注文番号をもう一度尋ねても接続は復旧しません。エラー状態を記録し、定められた再試行ポリシーを適用して、上限に達したら担当者に引き継ぎます。同じ質問を言い換えれば知識が増えるかのように、モデルに振る舞わせないでください。

確率は確認の優先順位を決める材料

万能なしきい値を一つだけ設定し、すべての処理に当てはまると考えてはいけません。TypeSafeは、自社のドキュメント（2026年10月13日確認）で、特定の質問タイプに対するconfidenceフィールドを説明しています。最大の選択肢確率と同じものだと決めつけず、まずその値の意味を確認しましょう。

検証用データセットで、申告された確信度が近い回答のうち、どれくらいが正しいかを確認します。自動実行の条件は、アクションごとに調整してください。公開済みの案内を読む場合と、顧客データを変更する場合では、誤りの影響が異なります。同じ実行許可ルールを適用するなら、個別の根拠が必要です。

確率がほぼ同じ選択肢が複数ある場合、ツールの説明が重複している可能性があります。しきい値を上げる前に、まず定義を見直しましょう。二つの機能がどちらも「注文に対応する」と説明されていれば、分類器は違いを判断する手がかりを得にくくなります。事業者を変更するより、ツール一覧を改善するほうが適切な場合もあります。

When2Callのスコアと私の10問テスト

出典：Artificial AnalysisのWhen2Callグラフ（2026年10月13日時点の値）。AAの最高スコアを太字で示しています。10月30日に見直した時点では、Jev 1.14やDecider v1.2など一部モデルの新しい版が掲載されており、表の値は13日時点の記録として読んでください。最終列は、2026年10月13日に筆者が行ったテストの結果です。店舗アシスタントとの会話10件をポーランド語でテストし、注文状況、注文キャンセル、店舗在庫、返品ラベルの4つのツールと、When2Callと同じ4つの選択肢を使いました。Clef-Flashは注文番号または都市名が不足している場合にツールを呼び出し、返品期間が14日かを尋ねる簡単な質問には回答を拒否しました。このテストが評価するのは、提示された選択肢から一つを選ぶ能力です。この数値だけでは、引数を自力で補完する能力や、多段階の操作を完了する能力は判断できません。

テストケースにしたい落とし穴

• データに埋め込まれた指示：文書に、別のツールを選ぶよう指示する文章が含まれているケースです。データがアプリケーションのルールに取って代わらないか確認します。
• 似た機能：読み取りツールとデータ変更ツールの説明が似ているケースです。動詞だけが異なる依頼で選択を確認しましょう。
• 古い状態：ユーザーが注文番号を訂正したのに、モデルには以前の番号が渡されるケースです。単一のプロンプトだけでなく、処理全体の状態更新をテストします。
• 矛盾する出力：モデルがツール呼び出しを提案しながら、必須引数の不足も示すケースです。バリデーターで実行を止めます。
• タイムアウト後の再試行：前回の呼び出しがすでに実行されている可能性があります。状態を変更する処理には、二重実行を防ぐ仕組みが必要です。

OpenAIのエージェント安全性に関する公式ガイダンス（2026年10月13日確認）では、信頼できないコンテンツからの指示のリスクや、データフローの制限を取り上げています。この設計例では、許可されたアクション一覧を固定し、モデルの外側で権限を確認することが実践的な対策になります。

ツール接続前にエージェントをテストする方法

まず、入力状態と期待するアクションを定義します。正しい依頼、情報不足、矛盾、利用できない機能、対象範囲外の状況を含めましょう。業務を理解する人が、モデルの提案を見る前に正解例を決めておく必要があります。そうしないと、システムが返した結果に合わせて評価基準を調整してしまいがちです。

説明文を改善するためのデータセットと、最終評価用のデータセットを分けましょう。同じメッセージの言い換えは一つのまとまりとして扱い、よく似た例が分割の両側に入らないようにします。誤字、略語、長い会話履歴、途中で気が変わるユーザーも、それぞれ個別のケースとして確認してください。

レポートでは全体の正答率だけでなく、不要なツール呼び出し、必要な追加質問の見落とし、不要な追加質問、誤った拒否も示しましょう。その後、ツールの代替実装を接続し、引数とエラー処理を確認します。最後に、実際の処理フローで、提案は記録するものの操作は実行しない観察モードを動かします。

モデルのバージョン、機能の説明、対応ルールを変更したら、検証ケースを再実行します。新しい誤りの原因を特定できるよう、結果と一緒にツール一覧のバージョンも記録しましょう。分析に加工済みの例とイベントIDだけで十分なら、顧客とのやり取り全文を必要以上に保存しないでください。

よくある質問

意思決定モデルがエージェント全体を置き換えますか？

この設計例では置き換えません。意思決定モデルは次の処理を選び、状態の管理、機能の実行、結果の確認はアプリケーションが担います。

掲載されたJSONは、そのままAPIに送れるリクエストですか？

いいえ。アダプター向けに筆者が設計した内部契約です。呼び出し形式と利用可能な質問タイプは、選択した事業者のドキュメントに合わせる必要があります。

確信度が高ければ、権限確認を省略できますか？

いいえ。確信度はモデルの判断に関する値です。データへのアクセスと操作の実行権限は、アプリケーションが独立して確認します。

エージェントが何度も質問する場合はどうすればよいですか？

必要な状態がすべて渡されているか、質問が本当に必須の引数に関するものか確認します。進展がない場合に終了する条件と、担当者に引き継ぐ経路も追加しましょう。

ツール選択が正しいか、どう確認できますか？

独立して作成した正解データと照合し、テスト環境で引数と実行後の最終状態を確認します。JSONが正しいだけでは不十分です。

開示：TypeSafeのJevは、以前の調査で知りました。9月に、自分の編集業務用ツールを想定して簡単なAPIクライアントを書いています。TypeSafeはこの記事を依頼しておらず、費用も支払っていません。

// 続きを読むHiggsfield AI 無料でできること：無料枠と制限の見方ガイドHiggsfield 商用利用：規約・生成物の権利・納品前の確認ガイドHiggsfield 解約方法：自動更新の停止と返金条件ガイド