gpt-live-1 技術解説：会話とバックエンドの分離、Function Calling / Jev の実行経路の可視化

音声は、生成 AI とやり取りする主要なインターフェイスの一つになりつつあります。Menlo VenturesがMorning Consult と実施した2026年の全米調査では、AI 利用者の 19% が音声を主なインタラクション方法としており、さらに 27% が音声とタイピングを使い分けていました。つまり、AI 利用者の 46% が少なくとも一部の場面で音声を利用していることがわかっています¹。日本においても、流暢な AI 音声対話の例がよくバズったり、英語の勉強を音声対話で行ったりという声を聞くようになりました。

_{¹ Menlo Ventures, “2026: The State of Consumer AI,” September 16, 2026. Survey conducted with Morning Consult among 5,067 U.S. adults in July 2026.}

サマリー

• gpt-live-1 は音声対話を担当し、検索・深い推論・ツール選択などの作業を「バックエンド」に委譲するフルデュプレックス（全二重）音声モデルです。 音声理解・推論・ツール選択・音声応答を 1 つのモデルが担う gpt-realtime-2.1 とは、役割分担が異なります。2.1 は推論量を調整できる音声モデルですが、カスタム関数を実行するのは、いずれの場合もアプリケーションです。
• Client delegation の委譲イベント（session.delegation.created）にはタスク文が含まれません。 この方式では、アプリケーションが文字起こしとアプリ状態からバックエンドへの入力を組み立てます。Responses delegation では GPT-Live が文脈を供給します。
• OpenAI は、表示用に発話を区切る TranscriptGrouper（OpenAI Node SDK）と、バックエンドへの引き渡し用に会話を保持する TranscriptLedger（OpenAI Cookbook）という、目的の異なる 2 つの実装を公開しています。
• これら機能をすべて可視化するアプリ「GPT-Live Transcript Lab」を開発します

1. gpt-live-1 とは何か

1.1 モデル仕様

gpt-live-1 は Azure OpenAI でも利用できる音声対話モデルです。ユーザーの声を聞きながら同時に話すことができ、会話中に必要になった検索・推論・ツール選択をバックエンドへ委譲します。音声モデルは、発話のタイミングや作業を委譲するタイミングも判断します。

主な仕様は次のとおりです（2026-09-28 時点）。

項目	内容
モデル ID	gpt-live-1
入力モダリティ	音声、テキスト
出力	音声。Azure では文字起こしもイベントとして取得可能（OpenAI のモデルページでは出力モダリティを音声・テキストと記載）
非対応モダリティ	画像、動画
知識カットオフ	2025 年 7 月 31 日
Azure の WebSocket 接続先	/openai/v1/live/sessions
料金体系	音声セッションの時間課金。バックエンドのモデル・ツール利用料は別課金
対応機能（OpenAI のモデル表記）	ストリーミング、Function Calling
非対応機能（OpenAI のモデル表記）	Structured Outputs、ファインチューニング、Predicted Outputs
Azure の同時セッション数上限	サブスクリプション単位で既定 10、Tier 1〜5 は 25 / 50 / 200 / 300 / 500

音声セッションには、無音の時間やバックエンドの処理待ちも含めて課金されます。Azure の利用料金は Azure OpenAI の料金表で確認してください。

gpt-live-1 は Chat Completions や Responses API に直接指定する汎用テキスト推論モデルではなく、音声セッション用のモデルです。Azure の WebSocket 接続では /openai/v1/live/sessions を使います。テキストによる推論や関数の引数生成が必要な場面では、別のバックエンドに処理を渡します。この「渡す」という操作が、次に説明する 委譲（delegation） です。

1.2 フルデュプレックスという設計思想

gpt-live-1 最大の特徴は、ユーザーの発話を聞きながら同時に話すことができる「フルデュプレックス（全二重）」性です。電話のように、相手が話し終えるのを待たずに音声を双方向へ流せます。また、音声対話とバックエンドの作業が独立して進むため、検索やツール実行を待っている間も会話を続けられます。

ただし、「大阪ではなく京都で」という訂正を受けた際の古い処理の取消や結果の破棄は、アプリ側で管理する必要があります。音声への割り込みだけではバックエンドの処理は停止しません。「話すのをやめて」と「注文を取り消して」は、異なる処理として扱います。

1.3 委譲（Delegation）という考え方

会話そのものは gpt-live-1 が担当しますが、複雑な推論やツール実行（検索、関数呼び出し、外部 API 呼び出しなど）は「バックエンド」に 委譲 します。委譲には次の 2 つのモードがあります。

• Responses delegation：指定した Responses API のデプロイに GPT-Live が会話文脈を供給し、バックエンド要求や結果の返却を管理します。ホスト型ツールはサーバー側で実行され、アプリ側で処理するカスタム関数の呼び出しはアプリに返されます。

• Client delegation：アプリケーション側が独自のエージェントやワークフローを運用し、結果を検証してから gpt-live-1 に返します。別のバックエンドや複数モデルの使い分け、履歴・アプリ状態の選別、結果の修正・破棄をアプリ側で制御したい場合に適しています。どちらのモードでも、権限と必要なユーザー確認を担保するのはアプリです。

Client delegation の役割分担を図にすると、次のようになります。Responses delegation の経路は 4.4 節で示します。

今回、この gpt-live-1 モデルによる委譲処理および後段の Function calling まで、内部の処理をすべて可視化して理解を助けるための Web UI 「GPT-Live Transcript Lab」を開発しました。

本ラボは、Client delegation + Function Calling / Jev と Responses delegation + Function Calling を切り替えられるローカル検証環境です。音声対話と天気関数は共通ですが、会話文脈の準備とモデルへの接続を誰が担うかが異なります。

2. gpt-realtime-2.1 との違い：「音声モデル内の推論」か「会話とバックエンドの分離」か

2.1 gpt-realtime-2.1 との対比

比較対象は gpt-realtime-2.1 です。Azure OpenAI ではバージョン 2026-07-07 が一般提供されており、音声対話モデル自身が推論を行います。reasoning.effort で推論量を調整でき、2.1 では 2 と比べて無音・雑音への対応が改善されています。OpenAI のモデル説明では、英数字の認識や割り込み時の挙動の改善も挙げられています。

gpt-live-1 との違いは、推論できるかどうかではなく、音声対話と推論・ツール選択をどこで結びつけるかにあります。Azure OpenAI の設計ガイドは、音声アプリを次の 3 つに整理しています。

構成	適した要件	役割分担
GPT-Live	バックエンドの処理中も全二重の会話を続けたい	音声モデルと推論・ツール用のバックエンドを独立に選ぶ
Realtime API（gpt-realtime-2.1）	音声理解・推論・ツール選択・音声応答を 1 つのモデルに担わせたい	音声モデルに推論機能を内蔵し、推論量を調整できる
音声認識 → テキストエージェント → 音声合成	各段の中間テキストを検査・変換したい	3 つの処理を分離し、各段を独立に差し替える

Realtime 2.x も、推論に時間がかかるときに「少し考えます」のような前置きを発話できます。ただし、これは同じモデルによる応答の一部であり、GPT-Live のように音声対話とバックエンドの作業を独立させる構成とは異なります。

「バックエンドを会話から独立して選び替えたいか」「音声と推論を 1 つのモデルに任せたいか」「各段の中間テキストを検査したいか」 によって構成を選びます。カスタム関数をアプリが実行する点は、GPT-Live と Realtime API に共通です。

2.2 モデル仕様の比較

	gpt-live-1	gpt-realtime-2.1
Azure の WebSocket 接続先	/openai/v1/live/sessions	/openai/v1/realtime
入力モダリティ	音声、テキスト	テキスト、音声、画像
料金体系	音声セッションの時間課金	トークン課金
推論・ツール選択と実行	バックエンドへ委譲。アプリがカスタム関数を実行	音声モデル自身が関数を選択。アプリが実行
知識カットオフ（OpenAI のモデル表記）	2025 年 7 月 31 日	2024 年 9 月 30 日

見落としやすいポイントとして、カスタム関数を実行する主体はいずれのモデルでもアプリケーションです。違いは「誰が関数の選択・引数生成を行うか」であり、gpt-realtime-2.1 は音声モデル自身が、gpt-live-1 は分離されたバックエンドが担います。

2.3 移行前後の役割分担

gpt-realtime-2.1 から gpt-live-1 へ移行すると、推論・関数選択の担当が音声モデルからバックエンドへ移ります。予約システムを例にすると、役割分担は次のようになります。

処理	移行前：gpt-realtime-2.1	移行後：GPT-Live
音声の聞き取り・応答	gpt-realtime-2.1	GPT-Live
空き状況確認・予約などの関数選択	gpt-realtime-2.1	分離されたバックエンド
関数の引数検証・権限確認・実行	アプリケーション	アプリケーション

「関数を検証・実行するのはアプリ」という部分は変わらず、「関数を選ぶ主体」が音声モデルからバックエンドへ移るのが移行の骨子です。Client delegation を使えば、既存のテキストエージェントやワークフローを接続できます。ただし、会話文脈の準備や結果返却など、GPT-Live との接続処理はアプリ側に必要です。

3. 会話履歴の役割分担：TranscriptGrouper と TranscriptLedger

3.1 なぜ会話履歴を管理するのか

この章の Ledger による入力準備は Client delegation の説明です。Responses delegation では GPT-Live がバックエンドへ文脈を供給するため、本ラボは Ledger を生成せず、記録・消費もしません。Grouper による字幕表示はどちらのモードでも利用します。

Client delegation の委譲イベント session.delegation.created には、委譲 ID などのメタデータはあっても、「東京の天気を検索して」というタスク本文は含まれません。そのため、アプリは文字起こしとアプリ自身の状態から、バックエンドへの依頼を組み立てます。

一方、文字起こしは完成した一文ではなく断片として届き、ユーザーとアシスタントの発話が重なることもあります。そこで、画面で読みやすく見せる処理と、バックエンドに渡す会話を管理する処理を分けます。

Client delegation の場合、アプリ側でやらなきゃいけないことが増えますね…😅できればベストプラクティスを採用したい。

3.2 TranscriptGrouper と TranscriptLedger の意味・違い・使い分け

TranscriptGrouper は、文字起こしの断片を読みやすい発話のまとまりにする表示用の処理です。TranscriptLedger は、会話を蓄積し、前回取り出した範囲と新しい範囲を管理する台帳です。 それぞれ OpenAI Node SDK と OpenAI Cookbook で公開されています。

観点	TranscriptGrouper	TranscriptLedger
答える問い	字幕として、どこで発話を区切るか	バックエンド用に、どこまで会話を取り出したか
主な役割	話者交代や沈黙などを考慮して表示を整える	会話を蓄積し、新しく取り出す部分を管理する
出力	画面に表示する発話のまとまり	話者と時刻を含む会話テキスト（SRT 形式）
本ラボでの配置	ブラウザ	サーバー
使う場面	字幕・会話履歴を読みやすく表示したいとき	Client delegation のバックエンド入力を準備するとき

どちらか一方を選ぶ関係ではなく、目的に応じて併用します。 本ラボの Client モードは同じ文字起こしを両方に渡し、Grouper の出力は画面へ、Ledger から取り出した会話は委譲処理へ渡します。表示上の発話の区切りを、そのままバックエンドへの依頼の区切りにはしません。Responses モードは表示用の Grouper のみを使います。

3.3 アーキテクチャ：表示と引き渡しを分ける

図の上側は人が読むための経路、下側はバックエンドが判断するための経路です。Ledger 自体が依頼の意味を判断するわけではありません。アプリが会話履歴と状態を揃え、その内容をバックエンドに解釈させます。

3.4 シーケンス：文字起こしから委譲まで

たとえば、後から「いえ、大阪でお願いします」と訂正された場合、その一文だけでは何を大阪に変更するのか分かりません。本ラボでは、新しく取り出した会話を過去の文脈と合わせてバックエンドに渡します。Ledger が扱う「新しい部分」と、判断に必要な「会話全体の文脈」は別です。 また、会話を取り出したことは、送信や実行の成功を意味しません。

4. Function Calling との連携：モデルの判断とアプリの実行

4.1 Client delegation + Function Calling の役割分担

Function Calling は、ご存じ使える関数の説明と引数の形式をモデルに伝え、どの関数を、どの引数で呼ぶかをモデルに判断させる仕組みです。関数を実行するのはモデルではなくアプリです。

本ラボでは、音声対話を gpt-live-1、関数の選択と引数生成を Azure OpenAI Responses API のモデルが担当します。

担当	役割
gpt-live-1	音声対話を続け、必要な作業をアプリへ委譲する
アプリケーション	Ledger から文脈を準備し、モデルの判断を検証して関数を実行する
Responses API のモデル	会話と関数定義から呼び出しを判断し、実行結果を基に回答を作る
天気関数・外部 API	実際の天気情報を取得する

モデルと外部 API の間には、アプリの検証と実行処理が入ります。 モデルが「東京の現在の天気を取得する」と判断しても、実際の天気は外部 API から取得し、その結果を基に回答します。

4.2 Client モードのシーケンス：「東京の天気を教えて」への応答

ポイントは、「関数を選ぶ判断」と「取得結果から回答を作る処理」の間に、実際の関数実行があることです。検索条件が不足していれば、関数を呼ばず確認を求める場合もあります。

GPT-Live への返却には session.commentary.append を使います。GPT-Live は内容を言い換えて話す場合があり、受理確認はユーザーへの発話完了を意味しません。

4.3 委譲方式の違いと Function Calling の併用

Function Calling と Responses delegation は対立する機能ではなく、併用できます。 Function Calling は「関数名と引数をモデルが指定する仕組み」、委譲方式は「文脈の準備・バックエンド接続・回答の返却を誰が管理するか」の違いです。Client モードではアプリが Responses API を呼び出し、Responses モードでは GPT-Live がその呼び出しを管理します。

観点	Client delegation + Function Calling	Responses delegation + Function Calling
文脈の準備・モデル呼び出し・結果返却	アプリが管理する	GPT-Live が管理する
本ラボの Ledger	会話を記録し、バックエンド入力に使う	生成・記録・消費しない
関数の選択・引数生成	アプリから呼ぶ Responses モデル	GPT-Live が呼ぶ Responses モデル
カスタム関数の検証・実行	アプリが担当する	アプリが担当する
関数結果の送信	アプリが Responses API への次の要求に含める	Live のイベントチャネルへ response.item.create を送る
モデルの続行	アプリが回答作成の要求を送る	アプリが response.create を明示的に送る
回答を Live に渡す処理	アプリが session.commentary.append を送る	GPT-Live が自動注入する
適した場面	履歴や結果を選別したい、独自バックエンドに切り替えたい	対応するモデル・ツールの範囲で、接続処理をサービスに任せたい

Client モードでは、判断部分を Function Calling と次章の Jev で切り替えます。Responses モードでは Function Calling を使います。Ledger を使わなくても、関数の許可・引数検証・実行状態の管理はアプリの責任です。 本ラボでは、両モードで同じ天気関数と引数検証を利用します。

4.4 Responses delegation + Function Calling のシーケンス

セッション作成時に delegation.type を responses とし、delegation.responses にモデル、指示、天気関数の定義を設定します。本ラボは tool_choice: "auto"、parallel_tool_calls: false として構成します。アプリが Ledger の SRT をモデルへ送る処理はありません。

関数要求は、response.event の内側にある response.output_item.done から取得します。本ラボはラウンドの response.completed を確認してから未処理の要求を実行し、call_id を付けた結果を返します。関数結果を送るだけではモデルは再開しないため、その後に response.create が必要です。 また、関数結果の追加には単独の成功 ACK がありません。アプリ内の「送信済み」、Responses の完了、Live の音声出力を別々に観察します。同じ回答を session.commentary.append で重ねて送信することはありません。

5. Jev 判断方式との連携

Jev が話題ということで、こちらの方式も試してみることにしました。本ラボの Jev 判断方式は Client delegation 専用です。

5.1 Jev（TypeSafe API）とは何か

Jev 判断方式は、関数名・引数をモデルに自由生成させる代わりに、事前定義した操作候補から 1 つを選ばせるというアプローチを取ります。使用しているのは TypeSafe の評価エンドポイントで、state（評価対象のデータ）と questions（型付きの質問）を送ると、質問ごとに構造化された answers が返る HTTP API です。

本リポジトリが使う質問タイプは Choice です。定義した選択肢のうち最も確率が高い候補を choice として返し、全選択肢の確率分布を probabilities、分布から求めた確信度を confidence として返します。

エンドポイントは POST https://api.typesafe.ai/v1/systemone、モデルは既定で jev-latest を使用します。

5.2 Function Calling との違い

この表は、Client delegation 内で切り替える 2 つの判断方式の比較です。Ledger の入力やモデル要求の回数は、Responses delegation の動作を表すものではありません。

項目	Function Calling	Jev 判断
判断に使う API	Azure OpenAI Responses API	TypeSafe の POST /v1/systemone（Choice）
モデルへの主な入力	Ledger の累積 SRT、関数の JSON Schema	Ledger の累積・今回分の SRT、17 候補、判断ルール
モデルの出力	関数呼び出し要求と JSON 引数、または確認回答	選択候補、全候補の確率、confidence
引数を確定する処理	モデル出力をアプリが検証	選択候補からアプリが都市と current を確定
天気取得	アプリが既存の天気関数を実行	同じ天気関数を実行
検索後の回答	function_call_output をモデルに渡して回答作成	天気関数の summary をそのまま使用（追加推論なし）
1 委譲あたりのモデル要求	関数実行時は最大 2 回	最大 1 回

呼び出し回数の少なさは、総遅延・費用・精度が改善したことを実測した結果ではありません。天気関数の内部では地名検索と天気取得の 2 回の HTTP 要求を行うため、「関数呼び出し 1 回」は「HTTP 通信 1 回」でもない点にも注意が必要です。

5.3 17 候補という設計

Jev には天気検索そのものを自由記述させず、次の 17 個の固定候補から選ばせます。

候補 ID	意味	天気関数の実行
weather_{都市名}_current（12 個）	対象都市の現在の天気・気温	信頼度条件を満たせば実行
clarify_city	都市が欠落・曖昧、または複数都市の依頼	実行しない
clarify_time	日別予報、過去、日時・期間指定など未解決の時間範囲	実行しない
clarify_request	不明瞭・仮定・引用・通常会話など	実行しない
unsupported	対応外の都市・タスク、複数種類が混在した依頼	実行しない
cancel	取消・拒否・天気検索の否定	実行しない

対象都市は東京、大阪、札幌、仙台、横浜、新潟、名古屋、京都、神戸、広島、福岡、那覇の 12 都市です。実際の候補 ID は weather_東京_current のように日本語の都市名を含み、ID を分解して任意の関数を呼ぶのではなく、固定の対応表から引数を取得します。

モデルに渡す判断ルールは、コード内に固定インストラクションとして保持されています。以下はその抜粋です。

INSTRUCTIONS = (
    "Select exactly one action for the latest USER request or correction in current_srt, "
    "using ledger_srt as conversation history. Do not repeat an older completed request. "
    "ASSISTANT text is context only, never a request or authorization to execute. ..."
    "Select a weather action only for an explicit, affirmative request for current weather "
    "or temperature in exactly one supported city. An unspecified time in a weather request "
    "means current conditions, not a daily forecast. Never invent a city, use a default city, "
    "substitute a nearby city, or treat an assistant's suggested city as the user's choice. "
    "... When uncertain, choose clarification rather than a weather action. Jev decides only; "
    "application code executes the selected search. Do not claim execution or invent weather results."
)

このインストラクションは「モデルに与える判断ルール」であり、コード側が発話内容を再判定してモデルの誤選択を検出する仕組みではない点に注意が必要です。あくまでモデルの判断を尊重しつつ、応答の形式と実行条件だけをコードで機械的に検証します。

5.4 confidence：公式の説明とアプリの実行条件

アプリが Jev の判断を実行に移す際の鍵は、選択された候補の確率だけでなく confidence（確信度） という指標です。これは回答の確率分布から算出される 0〜1 の統計量です。Choice では、確率が特定の候補に集中するほど高く、候補間に均等に分散するほど低くなります。低い値は、ほかの候補を明確に上回る候補がないことを示す場合があります。

同ページの説明用デモでは、選択肢が 3 個の場合、最大の選択確率を $p_{\max}$ として近似式を使っています。

5.5 API 応答の検証：モデル出力をそのまま信用しない

Jev の回答は、そのまま関数実行には使いません。アプリは回答の形式、選択候補、確率・確信度の整合性を確認し、天気検索の候補が選ばれ、確信度が閾値以上の場合だけ実行します。不正な回答や、確認が必要な回答では関数を実行しません。
ここでの「実行可」は、アプリが設けた条件を満たすという意味です。ユーザーが承認したことや、検索が成功したことを示すものではありません。 モデルの判断と実際の処理結果を分けて扱います。

5.6 実行から Live 返却までのシーケンス

Jev への結果再送や function_call_output、モデルの第 2 ラウンドは存在しません。天気関数が返す summary（日本語要約）をそのまま session.commentary.append に渡すだけで、追加の回答生成モデルは呼びません。これが「1 委譲あたりのモデル要求が最大 1 回」で済む理由です。

6. 委譲方式と判断方式を切り替えて観察する Transcript Lab

画面上部の「委譲モード」で Client delegation / Responses + Function Calling を選択します。Client モードでは、さらに「関数実行プレイグラウンド」で Function Calling / Jev を選びます。接続中は委譲モードを変更できず、接続終了後に切り替えて新しいセッションを開始します。委譲モードの変更時は記録がリセットされるため、必要な記録は先に JSON 保存します。

構成	会話文脈の準備	Grouper / Ledger	利用可能な入力
Client + Function Calling	アプリ	両方使用	ライブ、リプレイ、音声なしのモデル実行
Client + Jev	アプリ	両方使用	ライブ、リプレイ、音声なしのモデル実行
Responses + Function Calling	GPT-Live	Grouper のみ	ライブのみ

以下は macOS / Linux の起動例です。

python3 -m venv .venv
.venv/bin/python -m pip install -r requirements.txt
.venv/bin/python app.py

起動後、ブラウザで http://localhost:8765 を開くと次のタブが利用できます。

• ライブ接続：.env の AZURE_OPENAI_ENDPOINT / AZURE_OPENAI_DEPLOYMENT を設定し、実際の gpt-live-1 セッションに接続します。
• リプレイ：Client モード専用です。「天気検索を実行する」を OFF にすれば API キー不要で、合成イベントを処理クラスに流して観察できます。ON の場合は合成の委譲も実 API 呼び出しの対象です。

タイムラインの段階	Client delegation	Responses delegation
入力・委譲	入力 transcript と Client 委譲	入力 transcript と Responses 委譲
文脈・判断	Ledger 送信、Function Calling または Jev の判断	response.event、関数要求、Responses 応答待機
実行	関数・検証済み引数・取得結果	同じ実関数・引数検証・取得結果
結果の返却	回答作成または要約、commentary 送信、ACK	関数結果送信、明示的続行、Responses 完了・失敗

Responses モードでは Ledger のパネル・レーン・集計を表示せず、Jev と音声なしのモデル実行も選択できません。委譲 ID で絞り込み、関数要求・結果・送信コマンドを確認できます。Client モードに戻すと Ledger の表示と従来のレーンが戻ります。

Client モード全体の処理を俯瞰すると、次のような構成になります。Responses モードでは Ledger とアプリからのモデル呼び出しを通らず、4.4 節の経路を使います。

タイムラインでは、選択した方式の送信本文、応答、関数の実結果、Live への返却を確認できます。表示される候補や確率は内部の推論過程そのものではありません。また、通知の受信時刻には通信・待機を含み、方式を切り替えた別の要求同士をそのまま公平な速度比較として扱うことはできません。

7. まとめ

• gpt-live-1 は、会話（音声の聞き取り・発話）とバックエンドでの推論・ツール実行を分離するフルデュプレックス音声モデルです。音声モデル自身が推論・ツール選択を担う gpt-realtime-2.1 とは役割分担が異なります。既存のテキストエージェントをバックエンドとして活かせますが、会話文脈の準備や結果返却などの接続処理は必要です。
• Client delegation を選んだ場合、委譲イベントにタスク文が含まれないという制約があるため、アプリ自身が transcript を管理する必要があります。この課題に対して OpenAI は、表示用の TranscriptGrouper と、バックエンド引き渡し用の TranscriptLedger という 2 つの実装を公開しています。
• Responses delegation と Function Calling は併用できます。 文脈とバックエンド接続を GPT-Live が管理するため、本ラボでは Ledger を使いません。アプリは関数を検証・実行し、結果を返した後で明示的に続行させます。
• バックエンドでの引数確定には、モデルに自由な JSON を生成させる Function Calling 方式と、事前定義した候補から選ばせる Jev（TypeSafe Choice API）判断方式という 2 通りのアプローチがあり、それぞれ検証すべき項目（応答形式、確率分布の整合性、confidence の閾値など)が異なります。
• いずれの方式でも、関数の実行主体は常にアプリケーションであり、モデルの出力を無条件に信頼せず検証してから実行する、という設計が徹底されています。

GitHub