homulaエージェントを本番に乗せた企業が最初にぶつかる壁は、「できることが少ない」ことではありません。むしろ逆で、何でもできてしまうがゆえに、何を選ぶか予測できないことです。自由文でアクションを生成するエージェントは、同じ入力に対して微妙に違う判断を返し、ときに存在しない選択肢を“でっち上げ”ます。この揺らぎが、テストと監査をとてつもなく難しくしています。
2026年9月29日にサンフランシスコで開催された OpenAI の DevDay 2026 では、常時稼働エージェント「dots」や computer use 対応の Agents API が注目を集めました（OpenAI DevDay 2026 Recap、CNBC, 2026-09-29）。その陰で、homula のようなエンタープライズ向け AIエージェント・インテグレーターの視点から見て最も示唆的だったのは、地味な新API——Decisions API でした。
Decisions API とは何か——出力を「有限の選択肢」に閉じる
Decisions API は、モデルに自由文を書かせるのではなく、開発者があらかじめ定めた選択肢の中から1つを選ばせるためのエンドポイントです。開発者は「問い」と「許可する答えの集合」を定義し、テキストや画像のコンテキストを渡す。モデルは、その有限集合の中から1つを返す——という設計になっています（InfoQ, 2026-10、Vercel: OpenAI DevDay 2026）。
| 項目 | 内容 |
|---|---|
| 入力 | 開発者が定義した「問い」＋許可する答えの集合＋コンテキスト（テキスト／画像） |
| 出力 | 許可された選択肢のうちの1つ（自由文ではない） |
| 主な用途 | コンテンツ分類、リクエストのルーティング、エージェントの“次の一手”の選択 |
| 提供状況 | 限定プレビュー。アクセスは順次拡大とされ、価格・仕様は未確定（報道ベース） |
報道によれば、この API は軽量・高速な専用モデル（GPT-6 Luna と報じられる）上で動くとされますが、正確なモデル名・価格・一般提供の時期は本稿執筆時点で OpenAI から確定情報が出ていません（InfoQ）。ここでは個別のスペックよりも、この設計思想そのものに注目します。
たとえばサポート問い合わせの振り分けなら、答えの集合を「請求」「技術サポート」「アカウント」「人手確認」のように閉じておく。モデルはこの4択の外を返せません。出力が有限なので、switch 文の分岐にそのまま流し込めます——自由文をパースして想定外の値を弾く、という後処理が要らなくなるわけです。
なぜ「選択肢に閉じる」ことがエンタープライズで効くのか
一見すると、構造化出力（JSON Schema で出力形式を縛る）でも同じことができそうに見えます。実際、仕組みとしては近く、Decisions API はこれまで各社がプロンプト＋スキーマ＋後処理で自作してきたパターンを、一級の概念として切り出したものと言えます。重要なのは、意思決定を有限集合に閉じると、エンタープライズで効く3つの性質が同時に手に入ることです。
- 検証可能性: 出力が有限なら、分岐のすべてを列挙してテストできる。「この入力でこの選択を返すか」を網羅的に回帰テストにかけられます。自由文では不可能だった“全パスの保証”が現実的になります。
- 監査可能性: ログに残るのが「N個のうちどれを選んだか」という離散値になる。後から「なぜこの判断をしたのか」を追跡し、ポリシー違反の選択を検知するのが容易になります。
- コストと速度: 1回の分類・ルーティングに大型モデルを使うのは割高です。小さな判断専用のエンドポイントに切り出せば、エージェントの“原価”を下げられます。
ポイントは「賢さ」ではなく「閉じていること」です。エージェントの失敗の多くは、推論能力の不足ではなく、出力空間が広すぎて予測・検証できないことから来ます。重要な分岐ほど、答えの集合を狭く定義する——これは特定ベンダーのAPIに依存しない、普遍的な設計原則です。
「自由作文するエージェント」の落とし穴
ここ数カ月、エージェント統制の議論は「どこで実行するか（実行境界）」や「どのIDで動くか（エージェント識別）」に集まってきました。Decisions API が加えるのは、もう一つの軸——各分岐点で、何を選べるようにするかです。
自由文でアクションを決めるエージェントには、構造的な弱点があります。第一に、ハルシネーション。許可していないツール名や存在しないカテゴリを返すことがあり、それを毎回バリデーションで弾く実装が必要になります。第二に、非決定性。温度や文脈の揺らぎで同じ状況でも判断がぶれ、本番で「昨日は通ったのに今日は落ちる」が起きます。第三に、監査の困難さ。自由文のログからは「どの判断をなぜ下したか」を機械的に集計できません。
意思決定を選択肢に閉じる設計は、これらを入り口で断ちます。危険な操作の“手前”に離散的な判断ゲートを置けば、「この操作を実行してよいか＝許可／人手確認／拒否」という3択に落とし込める。ゲートの出力が有限だからこそ、承認フローや監査ログと素直に接続できるわけです。
homula はどう設計するか
homula はエンタープライズ向けの AIエージェント・インテグレーターとして、PoC から本番運用・内製化までを支援しています。Decisions API のような“閉じた意思決定”の部品は、私たちが重視してきた設計順序とよく噛み合います。
- 重要な分岐を先に洗い出す: エージェントのワークフローの中で、「誤るとコストが大きい判断」を特定する。AIエージェント・ブートキャンプでは、業務棚卸しの段階でこうした分岐点を可視化し、プロトタイプに落とし込みます。
- その分岐を有限の選択肢に閉じる: 重要な判断ほど、自由文ではなく選択肢（分類・ルーティング・許可/拒否）として設計する。出力空間を狭めるほど、検証とテストが現実的になります。
- 判断を証跡として残す: Agens は MCP を活用したエンタープライズ向け統合プラットフォームで、200以上のツールと構築ゼロで接続できます。その上で Agens Control が承認フロー・DLP・RBAC・5年分の監査ログを提供し、「どの分岐で・どの選択肢を・誰が承認して実行したか」を構造化した証跡として残します。離散的な意思決定は、この監査ログと相性が良いのです。
ベンダーが新しい部品を出すたびに実装を乗せ替えるのではなく、「重要な判断は選択肢に閉じる」という設計原則を自社の標準にすること。これが、ツールの流行り廃りに左右されない勝ち筋です。実行をどこに置くかという論点は自己ホスト実行の境界設計でも、オーケストレーションと実行環境の分離はOpenAI Agents APIの読み方でも扱っています。
まとめ
Decisions API は、派手な発表ではありません。しかし、エージェント統制の議論に重要な一手を加えました。
- モデルに自由文を書かせるのではなく、開発者が定めた有限の選択肢から1つを選ばせる仕組み。分類・ルーティング・次の一手の選択に使う。
- 意思決定を有限集合に閉じると、検証可能性・監査可能性・コスト効率が同時に手に入る。これは特定APIに依存しない普遍的な設計原則。
- 統制の軸は「どこで実行するか」「どのIDで動くか」に加え、各分岐点で何を選べるようにするかへ広がった。重要な判断ほど、出力空間を狭く設計する。
- homula の設計順序は変わらない——重要な分岐を先に洗い出し、選択肢に閉じ、判断を証跡として残す。
エージェントに必要なのは、もっと自由に喋らせることではありません。肝心なところで、選べる答えをこちらが決めておくことです。自由は便利ですが、統制は有限から生まれます。
エージェントの意思決定をどこで“選択肢に閉じる”べきか、現状のワークフローを持ち寄って整理したい方は、無料相談からご相談ください。