OpenAI Decisions APIで何が作れるか　曖昧な言葉をアプリの動作につなぐ

ゲームの仲間に『橋の向こうを見てきて。敵がいたら戦わずに戻って』と頼む。返ってくる言葉がどれほど自然でも、仲間が橋を渡るとは限らない。依頼を受け取ること、実行できる行動へ変換すること、その行動を始めることは、それぞれ別の仕事だからだ。

OpenAIが2026年10月22日に一般提供を発表したDecisions APIはこのうち入力を評価して判断を返す仕事を扱う。通常のLLMでも分類や構造化出力はできる。専用APIを使う意味はAIに初めて判断能力を与えることではない。候補が決まっていて何度も現れる判断を、返答や計画の生成から切り出し、アプリの動作へつなぎやすくする点にある。

では、分けることで何が作れ、どんな場合に分ける価値があるのか。まず仲間NPCへの依頼を最後まで追い、その仕組みを音声、仕事の振り分け、資料の確認へ広げて考える。公式仕様は10月23日時点で確認した。以下のアプリ設計は公式例と明記したものを除いてLATENTの提案であり、APIの性能実測や製品への導入実績を示すものではない。

OpenAIのGA発表 / Decisions公式ガイド

会話できるNPCを、頼めるNPCにする

先ほどのゲームには、仲間を同行させる、指定した場所へ偵察に出す、その場で待機させるという操作があるとする。従来のメニューなら、プレイヤーが『偵察』を選び、地図上の目的地を押せばよい。自然な言葉で頼めるようにすると、その選択を言葉の意味から補う必要が生まれる。新しく作るのは行動そのものよりも、すでにある行動へ自由な言い方でたどり着ける入口だ。

ここで発話だけをAIへ渡すと、『橋』がどこか分からない。入力には直前の会話、現在地、仲間が知っている橋の候補、今の任務も添える。たとえば川沿いの橋と城門前の橋があるなら、それぞれをゲーム内部の識別子と短い説明で示す。情報を添えるのは、今回の依頼に必要な対象と条件を区別できるようにするためだ。

問いも依頼を実行するための選択へ分解する。主な意図は『偵察・同行・待機・会話・保留』のどれか。目的地は候補のどれか、それとも未特定か。敵を見つけたときの方針は『交戦を避ける・交戦を許す・指定なし』のどれか。ここで挙げた値は応用設計用の例で、APIに最初からゲーム用の命令が備わっているわけではない。ゲームの開発者が自分の作品にある行動と対応する選択肢を用意する。

想定する結果は『偵察、川沿いの橋、交戦を避ける』になる。しかし、この結果だけで移動を始めない。ゲームは橋が現在も通れるか、仲間が別のイベントに拘束されていないか、プレイヤーに指示する権限があるかを自分の記録で調べる。通れるかどうかがゲーム内の数値や状態で確定するなら、その検査は通常のプログラムで行える。言葉を解釈する仕事と、確定した状態を照合する仕事には違う道具を使える。

検査を通ったら、ゲームは偵察を現在の任務として登録する。その確定した結果を会話生成へ渡せば、仲間は『敵がいたら引き返すよ』と返事を作れる。橋が封鎖されていれば、生成する返事にはその失敗を渡す。これで目指すのは、口では引き受けたのに実際は何も起きない食い違いを減らすことだ。会話の口調を変える仕組みと、任務を登録する仕組みを別々に直せるようにもなる。

この流れを通常のLLMにまとめて任せることもできる。LLMに命令のJSONを返させ、ゲームが検査し、その結果から返答を作る構成は成立する。Decisions APIを加える理由が生まれるのは、会話を生成する必要がないときも同じ命令の解釈を繰り返す、複数の画面で同じ判断を使う、会話モデルを変えても命令の評価を独立して管理したい、といった場合だ。分離そのものが唯一の実装方法ではない。

同じ入力でも保留になる例を考えると、必要な機能が見えてくる。『あっちを見てきて』だけでは目的地を決められないかもしれない。その場合は勝手に近い橋を選ばず、地図の候補を表示して選んでもらう。『橋を渡るな』という訂正が直後に来たら、先ほどの依頼を取り消す。曖昧な依頼を何でも一発で理解する体験より、足りない情報だけを聞き返して正しく終えられる体験の方が、この用途では設計しやすい。

通信の途中で場面が変わることもある。橋へ行くという判断が届いたとき、すでに仲間が戦闘に入っていれば古い依頼を適用しない。アプリ側で依頼と場面の番号を結び付け、結果を受け取る時点でも有効か確かめる。待っている間は今の行動を続け、再送された同じ依頼を二重に登録しない。この待機と照合があるから、通信を伴う判断をゲームの流れへ組み込める。

偵察中の状態選択にも同じ考え方を使える。味方から助けを求められたとき、任務を続けるか、報告に戻るかという意味の判断を候補から選ばせる案だ。ただし、体力が定めた値を下回ったら退避するという明確な規則まで、毎回AIへ尋ねる必要はない。判断を入れる場所を、会話や出来事の意味を読む場面へ絞るほど、なぜその呼び出しが必要か説明しやすくなる。

歩行、照準、当たり判定のような毎フレームの制御は、ゲームが持つ処理を動かし続ける。クラウドAPIの返答を待って画面を更新する設計では、通信のばらつきが操作感に直結する。今回任せたいのは任務や行動方針を選ぶ場面であり、それを細かな動きへ変えるのは行動木や状態管理の仕組みだ。操作中に通信できなくても遊べることが条件なら、ローカルのルールやモデルを選ぶ理由になる。

LATENTのd1記事では、判断モデルをゲームと同じPCへ置くときの資源や待ち時間を扱った。Strands Deciderの記事では、大型モデルとローカルの判断モデルの分担を考えた。今回の問いは、判断の置き場所をクラウドにしたとき、配布や端末差への対応を減らす価値が、通信と継続費用に見合うかだ。同じ『偵察を選ぶ』という設計でも、遊ぶ環境によって使う手段は変わる。

関連記事　d1をゲームと同じPCで動かせるか / 関連記事　Strands Deciderによる役割分担

同じ判断を繰り返すなら、専用APIへ切り出せる

NPCの例で起きた変化を、ゲームから離れて考えてみる。利用者は自由な言葉を使うが、アプリが動かせる機能は決まっている。その間に『どの機能へつなぐか』を判断する処理を置くと、利用者に内部のメニューや分類名を覚えてもらわなくてもよくなる。言葉を理解した結果が、返答の文章だけでなく、表示する候補や次に進む作業にも反映される。これが今回考える用途に共通する変化だ。

従来のLLMでも、その間を埋めることはできる。構造化出力を使えば、決めたJSONの形式に沿う結果を返せるため、自由な文章から無理に命令を抜き取る必要はない。機能呼び出しなら、実行したい道具と引数をモデルに提案させられる。比較するのは、一つの生成処理へまとめる構成と、必要な判断を別の処理へ渡す構成だ。

Decisions APIの結果は、条件が成立する推定確率、指定した候補からの選択、順序を持つ評価段階のスコアという形に絞られる。公式の名前ではpredicate、choice、scoreだ。『どの部署か』は順序のない選択で、『どの程度作業を妨げるか』は順序のある評価になる。自由な報告書を頼む窓口と比べ、アプリへ渡す答えの役割が先に決まっている。現在対応するモデルはgpt-6-lunaだが、名前からモデルの内部規模を推定することはできない。

入力には共通の証拠を置き、設問には何を知りたいかを置く。NPCなら会話と状態が証拠で、依頼の種類や目的地が設問になる。GAで加わったネイティブJSON入力は、状態や注文記録のような構造をそのまま渡すための機能だ。ただし『処理中』という値が決済中か発送準備中か分からなければ、JSONでも曖昧さは残る。意味の明確な項目を渡すことが、アプリで使える判断の前提になる。

この形が役に立つのは、一つの入力から複数の独立した観点を確認したいときだ。問い合わせなら、担当の区分、添付の読みやすさ、追加情報の必要性を別々に尋ねられる。設問を名前で区別しておけば、どの判断が誤ったのかも調べやすい。会話の説明文が流暢だったかとは別に、担当を正しく選べたかを評価できる。判断の定義を共有すれば、チャット画面とメール受付から同じ処理を利用する構成も考えられる。

GAでは最大設問数が200問から400問へ増えた。ただし、その上限を埋めること自体に価値はない。最初の答えを見て次の作業を決めるなら、後の判断は別の段階になる。『写真が読めるか』と『問い合わせの種類は何か』は並べられても、読めないと分かったあとに再撮影の案内を作るのは結果を受け取ってからだ。独立した観点をまとめる仕組みと、手順を順番に進める仕組みは区別する。

一方で、注文番号や住所を取り出し、説明文と一緒に返してほしい場合は、独自のJSON形式を生成する通常のLLMが自然な候補になる。選択肢を作るところから相談したい場合も同じだ。Decisionsの固定した答えへ収めるために、必要な情報を無理に削るとアプリの仕事が増える。出力が短いほど単純な問題になるわけでもなく、長い会話の意図を一語へまとめる判断には難しさが残る。

分担の単位はモデルの大小よりも仕事の性質で決まる。大きなモデルが計画や表現を担当し、用途を絞ったモデルが日常的な選択を受け持つ構成は考えられる。しかし、どちらが必要な精度を出せるかは対象の入力で調べる必要がある。担当を分けた結果、同じ資料を二度送り直すだけになったり、生成と判断の待ち時間が直列に増えたりするなら、まとめた方が扱いやすい場合もある。

ここまでで切り出す候補を絞れる。結果を受け取ったアプリが次の処理を決められること、その判断が繰り返し現れること、会話の文章とは別に良し悪しを確かめたいことだ。これらがそろうと、専用の判断処理を置く理由が明確になる。次は同じ構成を、判断する時点そのものが体験を変える音声へ持ち込んでみる。

Decisions公式ガイド / 構造化出力の公式ガイド / OpenAIのGA発表

音声では、話し終わる前の準備を任せる

NPCへの依頼では、何を頼んだかが分かってから行動を登録した。音声で話す場合は、話が終わる前にも情報が少しずつ届く。全文が確定するまで何も変えない構成に加え、分かった範囲で次に使う画面や候補を準備する構成が考えられる。ここで判断を切り出す目的は、完成した返答を速く書くことに限られない。会話を続けながら、利用者が次に必要とするものを用意することだ。

注文を確認する音声アプリで『昨日の注文、キャンセル……じゃなくて、配送日を知りたい』と話した場合を考える。途中では取消の相談に見えても、最後まで聞けば配送の問い合わせだ。『注文について話している』という判断なら、利用者自身の注文一覧を表示する準備に使える。一方、『取消を実行する』という判断にはまだ使えない。同じ発話の途中でも、先に進めてよい作業と、確定を待つ作業がある。

このアプリの入力はその時点までの文字起こしと、表示中の注文や直前の会話だ。設問を『話題は注文、商品案内、その他のどれか』『候補として見せるのは注文一覧、配送状況、取消の説明、保留のどれか』と分ける。結果が注文と配送状況なら、アプリは対象を確かめて配送カードを準備する。対象が複数あれば選択を求める。表示用の準備と、実際の注文を変更する処理を別に持つことで、言い直しへ追従しやすくなる。

これに使える公式機能がGPT-Liveとのネイティブ連携だ。Liveからアプリへ通知し、アプリがDecisionsを呼ぶ経路に対し、Liveが直接Decisionsを呼ぶことでアプリを経由する往復を減らす。入力や出力のtranscript deltas、つまり文字起こしの差分をきっかけに評価する方法もある。Decisionsへ生の音声をそのまま渡しているという説明ではない。言葉が追加される途中で、文字起こしに対応する判断を受け取る仕組みだ。

準備なら何でも先に行ってよいわけでもない。別の人の注文を読み込む、見せる必要のない個人情報を画面へ出す、といった処理は、後で表示を戻せても問題が残る。アプリが確認した利用者と閲覧権限の範囲内で、候補を用意する必要がある。その範囲が定まれば、操作を確定する前にも役立つ反応を設計できる。たとえば内容を変えずに対象の注文を強調し、『この注文ですか』という確認へつなぐ。

話し途中の結果は時間の順序も含めて扱う。公式ガイドでは、未処理の差分がまとめられる場合や、結果が順不同で届く場合が説明されている。アプリは結果が対応する発話を識別し、配送の話へ進んだあとに古い取消の候補で画面を戻さない。細かな単語の変化ごとに画面を切り替えると落ち着かないので、一定の条件がそろってから表示を変える。何をいつ見せるかは判断結果を受けたアプリの設計になる。

公式ガイドには、車内の操作を選ぶ例と、デジタル人物の表情や身ぶりを会話へ合わせる例がある。後者は文章を返す機能とは別に、小さな動作を選ぶ意味が見えやすい。声で返事をしている間にも、うなずきや視線などの反応を組み合わせられる。ただし、これらは公式の実装例であって、特定製品での成功率や遅延を実証した導入事例ではない。表情の選択を、人の感情を正しく見抜いた証明と扱うこともできない。

この用途で短くしたい時間は、利用者が話し始めてから適切な反応を見るまでだ。API単体が速くても、文字起こしが遅い、対象の注文を取得するのが遅い、古い画面が残る、といった問題があれば体験は変わらない。逆に返答の完成を待たずに対象だけが選ばれることに価値があるかもしれない。通信、判断、画面の更新を含めて、準備によって何が早まったかを測る必要がある。

途中の判断を増やせば、呼び出し回数や誤った先回りも増えうる。何度も画面が変わるより最後に一度だけ確かめる方がよい利用者もいる。取消や送信のような操作は確定を待ち、準備の反応が邪魔になる場合には表示を控える。この用途の採用理由は『話し途中でも判断できる』という仕様だけでは決まらない。最後まで話したときに、確認と操作がどれだけ分かりやすく終わるかで評価する。

音声連携の公式ガイド

仕事では、依頼を渡す先と承認の要否を選ぶ

音声の例では、話の途中から次の画面を準備した。同じ『次に何を用意するか』という判断を、人の仕事へ使うと問い合わせの振り分けになる。顧客が『支払いは終わっているはずなのに、また請求された』と書いたとする。欲しいのは流暢な一般論より、自分の支払いについて適切な担当者が確認してくれることだ。文章を作る前に、誰が何を調べる必要があるかを決める余地がある。

入力には問い合わせ文と会話履歴、閲覧が許された範囲の注文記録を渡す。『顧客が支払ったと言っている』ことと、『台帳に入金がある』ことは別の項目にする。設問は請求相談か、配送相談か、使い方の質問か、どれにも当てはまらないかという担当の候補と、調査に必要な情報が足りるかに分ける。モデルに入力した主張がそのまま会社の確定した記録へ変わらないようにするためだ。

『請求担当、注文番号が不足』という結果なら、アプリは請求担当の受け付けへ案件を置き、必要な番号を尋ねる下書きを用意する。番号と記録がそろっていれば、担当者に原文と該当記録をまとめて見せる。返金するかどうかは後の手続きだ。最初に短い判断を置くことで、長い返答を生成してから結局担当者へ回すという工程を減らせる可能性がある。狙う効果を初動の整理へ限定すれば、改善も調べやすい。

ここで一件の相談を一つのラベルへ押し込むと、別の問題が消えることがある。『荷物が届かず、請求も二重になっている』なら配送と請求の両方を扱う必要がある。どちらか一つを選ぶ問いを増やすより、それぞれの問題が含まれるかを別に確認し、アプリが主担当と協力先を決める方が目的に合う。現場で必要な受け渡しから設問を作り、APIの答えをそれへ対応付けるわけだ。

この受け渡しの先が人から別のAIへ変わると、実務エージェントの振り分けになる。問い合わせを整理したあと、注文の照会、記録の集計、説明の草稿、人への確認のどれへ進むかを選ぶ構成だ。生成AIは調査の計画や説明を作り、Decisionsは現在の材料がどの定型処理へ進める状態かを評価する。数字を集計すること自体はプログラムへ任せられる。異なる仕事を得意な処理へ渡すために判断を使う。

たとえば入金記録が不足しているなら、選ぶ結果は『追加照会』になる。ただし、その選択が返っただけで検索条件やツールの引数が完成するわけではない。アプリは照会できる範囲を確かめ、注文番号を既存の照会機能へ渡す。新しい検索文や複雑な引数を組み立てる必要があれば、その生成は別に担わせる。判断の結果が指す仕事を、実際に呼べる機能へ対応付けて初めて分担が成立する。

この構成で重要になるのが、承認をどう扱うかだ。Decisionsへ『依頼の意味が曖昧なので本人へ確認すべきか』『予定した処理に社外送信が含まれるか』と尋ね、人へ見せる候補を拾うことは考えられる。しかし、会社が必須と決めた承認を、モデルの『不要』という判断で省略することはできない。認証された利用者、宛先、金額の上限、使える道具といった条件は、アプリの権限管理で別に照合する。

実際に確認してもらう画面にも、この分担が表れる。『返金を許可しますか』という操作名だけでは、対象が合っているか判断しにくい。対象の注文、金額、相手、実行後の状態をまとめ、人がその内容に対して承認する。承認後に金額や相手を変えたら同じ承認は使わない。AIは確認が必要な案件を選ぶ手伝いをし、承認の記録と確定した操作の対応はアプリが維持する。

失敗したときの受け皿も担当の候補として見える形にしておく。どの候補にも合わない相談、必要な情報が足りない相談、APIが拒否した設問、通信が終わらない案件は、原文を残して確認待ちにできる。これらを正常な『問題なし』へ丸めると、調査が必要な仕事ほど見えなくなる。一方、何でも人へ送れば自動化の意味が薄れるため、保留になった理由と件数も採用後に追う必要がある。

エージェントには同じ照会を繰り返してしまう別の失敗もある。追加照会を選んだが新しい情報が得られず、また追加照会を選ぶ状態だ。アプリが回数と経過時間を管理し、同じ結果が続けば担当者へ戻す。ここで評価するのは判断の正答率だけではなく、最終的に問い合わせを解決できたか、途中で何度人や別の処理へ渡したかになる。小さな判断を安く増やしても、仕事が完了しなければ効果は出ない。

問い合わせの受付とエージェントの分岐は、同じ入力を異なる担当へ渡すという点でつながっている。ただし、担当を選んだことは、その担当の仕事が成功したことを意味しない。ログには選択した行き先、実際に行った照会、返ってきた結果を分けて残す。そうすれば、分類を直すべきなのか、照会機能を直すべきなのか、説明文を直すべきなのかを切り分けられる。この見直しやすさも判断を独立させる価値の一つになる。

Decisions公式ガイド / Decisions APIリファレンス

文書と画像では、人が確認する場所を絞る

ここまでは、判断から次の動作や担当へ進む用途を見た。結果をすぐ実行へつながなくても役立つ場面がある。人が大量の資料を見る前に、何を先に確認するかを整理する仕事だ。たとえば製品紹介ページを公開するチームには、説明文の条件、写真の対応、表示する注意書きを毎回確認する作業がある。AIに完成したページを丸ごと『正しい』と認定させるより、確認の必要な箇所を選ばせる使い方を考えられる。

文書側では、紹介文の段落と製品の確定情報、説明上の基準を入力にする。『期間限定の価格と通常価格を区別しているか』『追加料金のある機能を基本料金に含むように書いていないか』という問いなら、確認したい意味が比較的はっきりする。返す結果を各項目の確認候補として扱い、アプリは該当する段落を編集者へ見せる。単に『文章がよいか』と聞くより、読み手に何を誤解させるかという仕事へ結び付けやすい。

このとき、判断APIが理由や修正文まで返してくれる前提にはしない。確認した段落の番号はアプリが持ち、その段落への設問と答えを対応付ける。結果を見た編集者は元の文と製品情報を並べて確かめる。修正案が欲しければ、その後に生成AIへ依頼する。確認箇所を選ぶ処理と文章を書き直す処理を分けることで、確認だけしたい段落まで勝手に改変する必要がなくなる。

文書の分け方によって判断は変わりうる。料金の条件が次の段落にあり、例外が脚注にあるのに、紹介文の一文だけを渡せば誤った指摘が増える。アプリは対象の段落と必要な脚注や表をまとめて渡す。一方で、すべての資料を毎回送れば費用も読み取る範囲も増える。どこまでを一つの判断に使うかは、編集者が実際に何を読み比べているかを観察すると決めやすい。

同じ製品ページの写真も共通の確認基準へつなげられる。基準の製品写真と説明を共有入力に置き、設問側へ掲載候補の写真を渡す。『対象の型番と違う外観が写っていないか』『必要なラベルが見えるか』『画像が暗くて判断できない状態か』を別々に確認する案だ。GAで追加された設問単位の画像入力は、このように共通の見本に対して候補を変える構成へ利用できる。

想定する結果が『ラベル確認が必要、撮影は判定可能』なら、アプリはその写真を担当者の確認一覧へ送る。『暗くて判定できない』なら再撮影の候補にする。画像の外側や裏面まで確認できたことにはせず、写っている範囲と基準を一緒に表示する。見えないことと問題がないことを分けるのは、写真を見て人が確認するときにも必要な区別だ。APIを使う場合にも、その区別を結果の受け取り方へ残す。

公式ガイドにも写真から目に見える傷を確認する例はある。ただし、ここで提案した製品ページの検査工程や、誤掲載を防げる割合を公式が実証したという意味ではない。実際には光の反射、角度、色違い、圧縮によって見え方が変わる。決まった位置の寸法や部品数を厳密に測りたいなら、専用の画像処理や検査器と比べるべきだ。言葉で基準を指定しやすいことと、狭い対象を安定して測れることは別の利点になる。

文書と画像の結果をまとめると、公開前の画面に『価格の条件を確認』『写真のラベルを確認』『再撮影が必要』という作業の候補を並べられる。人は全文と全画像を最初から同じ密度で見直す代わりに、候補を起点として確認を進める。ただし候補に出なかった部分も正しいと保証されたわけではない。必須の確認工程を残したまま、確認する順番や資料の提示を改善できるかを試す使い方になる。

この用途では、誤った指摘が多いことにも費用がある。毎回大量の候補を消す必要があれば、編集者は一覧を信用しなくなる。逆に指摘を減らすだけでは、重要な条件の抜けを見逃すかもしれない。見落とした問題、余計な指摘、確認に使った時間を合わせて比べる。文書や基準の版が変わったら古い結果を使わず、通信が失敗した項目は未確認として残す。結果の扱いまで含めて初めて、確認作業を助けたかどうかが分かる。

NPCでは行動、音声では準備、問い合わせでは担当を選んだ。文書と画像では、人が注意を向ける対象を選んでいる。いずれも入力の意味を読み、次の仕事へ使える形に変える点は共通するが、誤りが起きたときの影響は異なる。だから同じAPIだからという理由で、一つの基準を全用途へ当てはめることはできない。この違いが、次の採用判断で見る品質と費用につながる。

Decisions公式ガイド / OpenAIのGA発表

分ける価値は、品質と一件あたりの総費用で決める

ここまでの案は、答えの形式を決めるだけなら試作しやすい。採用の判断には、今の処理と比べて何が改善するかが必要になる。NPCなら依頼どおりに行動を始められた割合、音声なら誤った先回りの回数、問い合わせなら担当へ届くまでと解決までの時間、資料確認なら見落としと確認時間だ。APIの呼び出しが成功したことを、利用者の仕事が成功したことと同じに数えない。

最初は同じ入力を既存の処理とDecisionsへ渡し、実際の操作へ反映せず結果を比べる方法がある。普通の成功例に加え、否定や言い直し、候補にない依頼、情報不足、複数の問題を含む例を集める。設問を調整した例だけで最終評価をすると、見慣れた言い方に合わせただけかもしれない。調整用と最後の比較用を分け、どの入力に改善があり、どこが悪化したかを見る。

答えに付く確率やconfidenceは、そのまま自分のアプリの正解率にはならない。『戦わずに戻る』を読み落とす誤りと、資料に余計な確認候補を一つ出す誤りでは、避けたい損失が違う。高い値だけを自動処理へ回すとしても、どこで保留するかは対象の事例で確かめる。人へ回す件数を増やして正しく見せる構成になっていないかも合わせて確認する。

待ち時間も用途で基準が変わる。NPCの移動開始は遅いと気付かれやすいが、公開前の資料確認なら処理をまとめて待てる場合がある。平均だけでなく遅い側の分布、期限を超えた割合、同時利用が増えたときの変化を測る。公式が速度上の利点を掲げていても、入力、地域、通信、アプリの処理が異なれば同じ待ち時間にはならない。本記事の設計案について固定の遅延や正確性を保証できる測定は行っていない。

料金を考えるには、問い合わせの受付を例にすると分かりやすい。GA時点のDecisions APIでは、Lunaの通常入力が100万トークン当たり0.10ドル、キャッシュ読み出しが0.01ドルで、出力トークンの料金はない。1件につき課金対象の入力が合計3,000トークンあり、すべて通常入力として課金されると仮定すれば、10万件は30ドルになる。3,000÷1,000,000×0.10×100,000という試算であり、実際の問い合わせを測った値ではない。

ここでいう入力には、顧客の本文だけでなく、共有する記録、設問、選択肢の説明、画像なども関係する。400問を一度に尋ねれば追加の399問が無料になる、という計算はできない。設問を増やせば入力も増え、問い合わせを何回評価するかでも費用は変わる。受付時に一度分類する場合と、音声の途中で繰り返し判断する場合を同じ『一件』として比べると、必要な呼び出し量を見落とす。

同じ確認基準を何度も使う資料検査には、プロンプトキャッシュが費用へ効く可能性がある。再利用するのは、共有入力の一致する先頭部分だ。最低1,024トークンが必要で、設問内の内容や設問ごとの画像は再利用する共有部分に含まれない。固定した基準を共有入力へ置き、変わる対象を適切に分ける設計には意味がある。ただし、最低長を満たすためだけに不要な説明を追加すれば、元の入力を大きくしてしまう。

キャッシュには読み出しだけでなく書き込みの費用もある。100万トークン当たり、30分の書き込みは0.125ドル、12時間は0.25ドルだ。書き込み対象のトークンはこの単価で数え、通常入力の料金を重ねて足さない。利用量のinput_tokensにも読み出しと書き込みの内訳が含まれているため、内訳を総量へ足すと二重計上になる。費用を比べる際は、通常入力、読み出し、各保持時間の書き込みへ分ける必要がある。

具体的には、1万回の検査で共有部分2,000トークンを最初の一度だけ書き込み、残り9,999回がすべて読み出しに成功し、毎回変わる1,000トークンを通常入力とする仮定を置く。30分の書き込みなら0.00025ドル、読み出しが0.19998ドル、変化する入力が1ドルで、合計1.20023ドルになる。同じ3,000トークンを毎回すべて通常入力にする比較条件では3ドルだ。

この数字は、同じ共有部分が有効な期限内に再利用され、再書き込みがなく、変化する部分に書き込み料金が付かないという条件付きだ。12時間の書き込み単価へ変え、ほかを同じとすれば1.20048ドルになる。長く保持すればいつでも得という話ではなく、保持中に何回同じ内容を使うかが問題になる。問い合わせごとに内容が変わる会話履歴と、繰り返し使う製品の基準では、実際のキャッシュの当たり方も異なる。

上の試算はDecisions部分だけで、地域処理の割増や長文入力への倍率、GPT-Live、返答生成、外部ツール、保存、再試行、人による確認を含めていない。音声アプリなら判断の料金だけを見ても、一回の会話の費用は分からない。問い合わせならAPI代が減っても、誤転送の修正に時間がかかれば総費用は増える。正しく完了した一件あたりの費用を比べると、安い判断を増やすことと仕事を安く終えることの違いが見える。

比較対象も用途に合わせる。金額や有効期限の照合ならルール、抽出項目と説明を同時に作るならLLMの構造化出力、分類が安定した大量の入力なら専用分類器、端末内で処理を完結させたいならローカルモデルが候補になる。専用分類器には学習データと更新の負担があり、ローカルモデルには端末の資源と配布の負担がある。Decisionsの試しやすさや共有しやすさを、それぞれの品質と運用負担に照らして評価する。

小さな試験で効果が見えたら、対象を広げる前に戻す条件を決めておく。問い合わせの誤転送が増えたら従来の受付へ戻す、音声の途中表示が不安定なら確定後の表示だけにする、といった条件だ。モデルや設問を変えた際にも同じ事例で比べられるようにする。独立した判断処理には、必要な部分だけ入れ替えて測れる利点がある。その利点を使って、採用と見送りの両方を具体的に決められる。

OpenAIの料金表 / プロンプトキャッシュの公式ガイド / Decisions公式ガイド / Decisions APIリファレンス

自分のアプリのどの判断を切り出すか

橋の向こうへ仲間を向かわせるために必要だったのは、気の利いた返事を一つ増やすことだけではなかった。依頼の意味を候補へ変え、ゲームが対象と条件を確かめ、確定した行動を返事へ反映する流れだった。Decisions APIはその中で繰り返し現れる解釈や評価を受け持つ選択肢になる。通常のLLMで同じ流れを作れている場合にも、どの部分を独立させると改善を測りやすいかという問いは残る。

自分のアプリへ置き換えるなら、利用者の入力を一つ選び、受け取りたい結果と、その結果で変わる処理を書いてみる。たとえば『請求についての自由な相談』から『請求担当と不足情報』を得て、担当者の画面と聞き返す内容を用意する。結果が分かっても次の仕事が変わらないなら、判断を追加する目的は弱い。逆に、同じ分岐が何度も現れ、別々の入口から利用されるなら、切り出す候補として説明しやすい。

その候補に、分からなかったときの戻り先と、比較する既存手段を添える。NPCなら目的地の再確認、音声なら確定後の操作、資料なら人の確認へ戻れる。これで、試したい機能だけでなく、使い続けられるかを確かめる対象ができる。必要なのは何でもAIに任せる方針より、一つの判断を変えたときに利用者の体験や作業がどう変わるかを追える設計だ。

文章を生成する能力に加えて、曖昧な入力を選択へ変える能力を使うと、AIの理解を次の操作、準備、担当、確認箇所へ反映できる。Decisions APIへ分ける意味があるのは、その選択が繰り返され、結果の形と受け取る処理が明確で、品質と総費用を比べられる場面だ。何を任せるかが定まれば、生成AI、ルール、人の確認を組み合わせたまま、アプリの一部分から使い道を確かめられる。

出典と確認範囲

仕様と料金の確認日は2026年10月23日。GA発表日は10月22日。アプリ設計と費用の計算例はLATENTの提案と試算であり、公式例は音声と資料確認の章で明記した。APIの速度・精度の実測、提案したアプリの動作検証、製品への導入は行っていない。

• OpenAIのGA発表
• Decisions公式ガイド
• 音声連携の公式ガイド
• OpenAIの料金表
• プロンプトキャッシュの公式ガイド
• Decisions APIリファレンス
• 構造化出力の公式ガイド
• 関連記事　d1をゲームと同じPCで動かせるか
• 関連記事　Strands Deciderによる役割分担