10月9日、InfoWorldが「As AI agents grow, vendors carve out decision-making as a separate model layer」と題した記事を公開した。AWS・Cloudflare・OpenAIが相次いで「意思決定」を独立したモデルレイヤーとして切り出す動きと、それがエンタープライズAIアーキテクチャにもたらす複雑性について論じている。

意思決定を専用モデルに切り出す——何が変わるのか

AIエージェントのスケールに伴い、推論コストの削減が課題となる中、「エージェントが次に何をするかを決める」という処理を、大規模モデルから切り離して軽量な専用モデルに任せる設計が登場しつつある。

先鞭をつけたのはTypeSafe AIのJev（先月リリース）だ。JevはTypeSafe AIが開発した意思決定特化型モデルであり、エージェントの「推論」と「アクション」の間に位置する限定的な判断処理を専用モデルで担う構成を提示した。トークン消費と推論コストの削減を狙ったアプローチとして注目を集めている。

これに続く形で先週、CloudflareとAWSがそれぞれ独自の意思決定モデルを発表した。

Cloudflare「Clef」——エッジで動かす意思決定モデル

Cloudflareが公開したClefおよびClef-flashは、Workers AIプラットフォームを通じて提供されるオープンモデルだ。大規模な中央集権型モデルにリクエストを送らず、アプリケーションの近くで軽量な意思決定を処理することで、レイテンシと推論コストを削減するというアプローチを取る。

AWS「Strands Decider 2B」——エージェントの制御フロー担当

AWSが展開する20億パラメータの意思決定モデル「Strands Decider 2B」は、ツールの選択・タスクのルーティング・エージェントワークフローの次ステップ決定といった処理を担う。複雑な推論は大規模モデルに残し、制御フロー部分をこのモデルがオーケストレーターとして受け持つ設計だ。オープンソースとして公開されており、ローカルでの実行とAWSインフラ経由のデプロイの両方に対応する。

このモデルはStrands Boxと呼ばれるフレームワークの一部として提供されている。Strands BoxはAWSが開発したAIエージェント向けのランタイム環境・ツールキットであり、エージェントの暴走的な挙動を抑制し、制御可能な形でのデプロイを支援することを目的としている。Strands Decider 2BはそのStrands Box内の意思決定レイヤーを担うコンポーネントとして位置づけられている。

コスト削減のはずが、複雑性という別のコストを生む

この流れを単純にコスト削減策と見るのは早計だ、とアナリストは警告する。

HFS Researchのエグゼクティブリサーチリーダー、Ashish Chaturvediはこう指摘する。

「企業がこれらの意思決定モデルを、推論モデル・リランカー・埋め込みモデル・ルーター・ガードレールといった既存コンポーネントに追加していくにつれ、AIスタックの肥大化というリスクが生じる。特に評価とキャリブレーションの領域でそれが顕在化するだろう。ClefとDecider、Lunaそれぞれが出力する確率0.8は、同じ信頼度を意味しない。あるモデル向けに調整した閾値は別のモデルには転用できず、ベンダーを切り替えたり複数を併用したりする企業は、自社データで閾値を再キャリブレーションし直さなければならない」

引用中の「Luna」は、後述するOpenAIのGPT-6 Lunaを指している。Cloudflareのクライアントサイドモデル（Clef）、AWSの軽量モデル（Decider）、そしてOpenAIのAPIベースモデル（Luna）という異なる設計思想を持つ三者を並置することで、同一の出力値でも信頼度の解釈が異なるというキャリブレーション問題を示している。

また、意思決定スキーマの管理も課題になると同氏は続ける。質問・回答セット・閾値のひとつひとつがビジネスポリシー（「払い戻しに承認が必要かどうか」「何をクリティカルインシデントと見なすか」）を体現しており、それが数百単位で積み上がれば、プロンプトと同様にバージョン管理・オーナーシップ・レビューが必要な新たなロジック群になる。

大手スーパーマーケットH-E-Bのシニアデータエンジニア、Aditya Ranjanはコスト面の現実も指摘する。

「意思決定モデルで推論コストを大きく削減できたとしても、複数モデルの保守・障害対応・不整合な結果の調査に追加のエンジニアリングリソースが必要になれば、財務的なメリットは期待より小さくなる。さらに、誤った判断が引き起こしたダウンストリームのアクションを修正するコストが、推論コスト自体を上回るケースもある」

Ranjanは、エンドツーエンドのワークフローレイテンシ・成功判断あたりのコスト・判断精度・運用オーバーヘッド・障害回復コストを軸に評価するよう勧めている。

OpenAI「Decisions API」——複雑性を抽象化する選択肢

一方、OpenAIが同じく先週公開したDecisions APIは、別の方向性を示している。テキストと画像の両方に対応するこのAPIは、開発者がアプリケーションに必要な判断内容と選択肢を定義すると、自由形式のモデル応答から開発者自身が答えを抽出する必要なく、構造化された結果を直接返す仕組みだ。

これにより、開発者は意思決定モデルを個別に選定・デプロイ・管理しなくても済む。APIを呼び出すだけでよく、背後のモデルは抽象化されている。現在GPT-6 Lunaによって動作しており、OpenAI APIを通じてパブリックベータとして提供中だ。GPT-6 LunaはOpenAIが2025年にリリースしたGPT-6ファミリーのモデルのひとつで、効率性と応答速度を重視した設計となっている。

ただし、この抽象化はあくまで実装上の簡略化であり、判断を支配する閾値やビジネスルールの評価・ガバナンスの必要性をなくすものではない点は変わらない。

意思決定の専用レイヤー化は、エンタープライズAIスタックに新たなアーキテクチャの選択肢をもたらす一方で、モデルの乱立・キャリブレーションの複雑化・スキーマガバナンスという新たな課題も生み出す。コスト削減を目的として導入する前に、トータルの運用コストを見積もることが不可欠だ。「どのモデルを選ぶか」という問いの前に、「そもそも意思決定レイヤーを分離すべきか」を問い直すことが、導入の成否を分ける第一歩になるだろう。

詳細はAs AI agents grow, vendors carve out decision-making as a separate model layerを参照していただきたい。