AI英会話のアプリで「今日の学習記録を残しておいて」と話しかけると、記録が本当に残ることがある。
このとき、AIが自分で記録を書いているわけではない。
AIがやっているのは「この道具を、この引数で呼んでくれ」と注文を出すところまでだ。
その注文を受け取って実際にコードを動かすのは、アプリを作った側のプログラムである。
この仕組みが関数呼び出し（function calling）で、音声で会話するAIにも同じ形で載っている。
OpenAI の Realtime API の入門ガイドも、音声モデルの特徴として、音をそのまま扱いながら会話の状態を保ち、そのうえで道具を呼べる点を挙げている。
この記事では、AIの部品を売っている会社の開発者向けドキュメントに書かれたイベントの流れだけを材料に、会話の裏で何が往復しているのかを開けていく。
サービスの順位づけはしない。仕組みの話だけをする。
【結論】AI英会話の関数呼び出しは、AIが「やる」のではなく「頼む」仕組み
先に答えを置く。
OpenAI の Realtime conversations は、この機能を、開発者が書いたコードを走らせてモデルの守備範囲を広げるための仕掛けだと位置づけている。
そして流れを4段で示している。
| 段 | 誰が動くか | 何をしているか |
|---|---|---|
| ① | アプリ側 | 呼べる関数の一覧をAIに渡す |
| ② | AI側 | 入力を見て「この関数を呼ぶべきだ」と判断し、引数を会話に追加する |
| ③ | アプリ側 | その引数を使って自前のコードを実行する |
| ④ | アプリ側→AI側 | 実行結果を会話に戻し、返事を作らせる |
⇒ AIが出すのは答えではなく「注文票」であり、実行したのはアプリの側だ。
この境目が分かると、AI英会話で「やったと言っているのに反映されていない」が起きる理由まで見通せる。
AI英会話の関数呼び出し①｜まず「呼んでいい道具の一覧」を渡している
AIは、渡されていない道具を呼ぶことはできない。
公式ドキュメントは、道具の一覧を渡す場所が2つあると書いている。
- セッション全体に渡す＝
session.updateのsession.tools。 - 返事1回ぶんだけに渡す＝
response.createのresponse.tools。 - あわせて
tool_choiceを"auto"にすると、呼ぶかどうかの判断そのものをAIに任せる形になる。
1つの道具は、名前・説明文・引数の定義の3点セットで書かれる。
公式が載せている例は generate_horoscope という関数で、説明文には「星座を1つ受け取り、その日の運勢を返す」という趣旨の一文が置かれている。
引数のほうも sign という文字列で、取りうる値が enum で12個に限定されている。
ここが重要なところで、関数と引数のそれぞれに添えた説明文が、呼ぶか呼ばないかの判断と、各引数に何を入れるかの判断を支える、とドキュメントは明記している。
⇒ AIは道具を、コードではなく「日本語や英語で書かれた説明文」で選んでいる。
AI英会話の関数呼び出し②｜返ってくるのは音声ではなく、引数の入ったJSON
道具を呼ぶと判断したとき、AIはその回だけ「しゃべらない」。
文章や音声をその場で返す代わりに、関数へ渡すべき引数を抱えた返事のほうが生成される、とドキュメントは書いている。
このとき届くイベントの中身は、次の4つのプロパティで読み取る。
| プロパティ | 入っているもの |
|---|---|
response.output[0].type | function_call なら「これは注文票だ」という印 |
response.output[0].name | 呼びたい関数の名前 |
response.output[0].arguments | 引数の入ったJSON文字列（星占いの例なら星座名が1つ入る） |
response.output[0].call_id | この呼び出しに付く識別子。結果を戻すときに要る |
いずれも、返事の出力配列の1件目を見にいく形になる。
引数は少しずつ流れてくる作りにもなっている。
途中経過は response.function_call_arguments.delta というサーバーイベントで受け取れ、完成形のほうは response.done に入る、と説明されている。
音声のやり取りと同じで、引数も「まとめて1回」ではなく「少しずつ」届く。
AI英会話の関数呼び出し③｜結果を会話に戻すまで、話は前に進まない
注文票を受け取っただけでは、AIはまだ何も知らない。
アプリ側は自前のコードを走らせたあと、結果を会話の項目として押し戻す必要がある。
公式ドキュメントが挙げている戻し方の要点は3つだ。
- 会話項目の種類は
function_call_output。 - 識別子は
item.call_idで、さきほど受け取ったcall_idをそのまま使う。 - 実行結果は、JSON文字列にして
item.outputに入れる。
そのうえで、もう一度 response.create を送って初めてAIが口を開く。
この送信が引き金になり、関数から返ってきたデータを踏まえた返事が作られる、とドキュメントは説明している。
⇒ 1回の「やっておいて」の裏で、アプリとAIのあいだを4段ぶんのやり取りが行き来している。
AI英会話で、道具を使う指示を出したときだけ返事が遅く感じるのは、この往復が挟まるからだ。
AI英会話の関数呼び出し④｜自然に聞こえる返事は、道具が動いた証拠にならない
ここがこの記事でいちばん大事な部分だ。
OpenAI の Voice agents は、評価の章でこう書いている。
返事が自然に聞こえたからといって、それは道具が走った証明にも、アプリの状態が変わった証明にもならない。
英語の原文でも「does not prove」と言い切っており、聞き心地と実行結果は別物だという立場が取られている。
だから同じドキュメントは、評価の手順として、口に出した確認の内容と、実際に終わった処理の内容が合っているかを突き合わせよ、とも書いている。
音声モデル向けの指示文のガイドである Prompting voice models は、さらに踏み込んでいる。
裏側の処理から確認が返る前に、予約を約束すること、値段を当てずっぽうで答えること、処理が片づいたと宣言すること。この3つを、いずれもやってはならない振る舞いとして並べている。
待っているあいだに結果を推測するな、という一行も別に置かれている。
⇒ 「先に言ってしまう」のは起こりうる挙動として想定されていて、だから指示文の側で禁じるよう書かれている。
AI英会話の関数呼び出し⑤｜危ない処理は、実行の直前で止められる
道具が外の世界を書き換えるとき用に、実行を保留する仕掛けが用意されている。
Guardrails and human review は、承認を、道具の呼び出しに人を挟み込むための経路だと説明している。
行動が要ると判断すること自体はAIに任せたままでよく、人が承認するか却下するまで処理の進行だけが止まる、という設計だ。
ドキュメントは承認の流れを4段で示している。
| 段 | 何が起きるか |
|---|---|
| ① | 道具を実行せず、承認待ちとして記録する |
| ② | 結果に interruptions と、再開できる state が返る |
| ③ | アプリ側が承認するか、却下する |
| ④ | 新しいターンを始めるのではなく、同じ state から再開する |
承認に時間がかかるなら state を保存して後で再開してよい、とも書かれている。
ただし同じページは、検査が効く範囲を限定している。
入口側の検査が走るのは連鎖の先頭に立つエージェントだけで、出口側の検査が走るのは最終的な出力を作るエージェントだけだ、と書かれている。
⇒ 道具の周りを守りたいなら、検査は道具のすぐ隣に置くしかない。
AI英会話の関数呼び出し⑥｜会話に残さない「裏の呼び出し」もできる
学習アプリが裏で採点や分類をしていても、それが会話の履歴に残るとは限らない。
Realtime conversations には、会話状態に加えない返事を作る方法が書かれている。
やり方は単純で、response.conversation に none という文字列を指定すると、その返事は既定の会話状態から外れる。
公式の言い方では、会話の外側で作る返事という扱いになる。
さらに metadata を付けておくと、どのイベントがその裏の処理に対応するかを見分けられる、とも書かれている。
この形を使うと、利用者に聞こえる会話を止めずに、別の判定を走らせられる。
⇒ 画面に出ているやり取りが、そのセッションで起きたことの全部とは限らない。
AI英会話の関数呼び出し⑦｜どこで道具を動かすかで、設計が3つに割れる
同じ「音声で道具を使う」でも、置き方が1つではない。
Voice agents のドキュメントは、設計を3つに整理している。
| 設計 | ドキュメントの整理 | 道具はどこで動くか |
|---|---|---|
| GPT-Live | 話し手とAIが同時に話せる会話を、独立した裏側と組み合わせる形 | 会話は前面、道具と推論は別の裏側 |
| Realtime API | 発話・推論・道具の利用を、ひとつのセッションに載せる形 | 1つのセッションの中でまとめて |
| Chained voice pipeline | 音声と文章の各段を、個別に制御する形 | 音声認識→処理→音声合成の間に自分で挟む |
裏側に寄せる形の利点として、裏の処理が走っている最中も利用者は話し続けられる点が挙げられている。
つまり、道具が動いているあいだも会話は途切れない。
一方で段を分ける形については、使い方の例が順番つきで示されている。
- 話した内容の書き起こしを保存する。
- 文章を扱う側が答える前に、方針に反していないかを検査する。
- 社内のシステムを呼びにいく。
- 承認された答えに行き着いてから、ようやく音声を作る。
AI英会話のアプリが「反応は速いが記録は遅れて反映される」ように見えたり、逆に「記録は確実だが返事の前に少し間がある」ように見えたりするのは、この3つのどれを選んだかの差として現れる。
AI英会話の関数呼び出しが、学習者の体験に出てくる場面
仕様の話を、画面の上で起きることに置き換えておく。
- 言ったことが記録に残る＝「今日はここまで」と話した内容が、関数の引数としてアプリに渡り、アプリ側のコードが保存している。
- 道具を使うときだけ返事が遅い＝注文票を受け取り、実行し、結果を戻し、返事を作らせる往復が挟まっている。
- 「やっておきました」と言われたのに反映がない＝公式ドキュメント自身が、自然な返事は実行の証明にならないと書いている領域だ。
- 確認を求められてから実行される＝承認の仕掛けが入っていると、処理は保留され、同じ
stateから再開される。 - 会話には出てこない採点がある＝
conversationをnoneにした裏の呼び出しは、会話状態に足されない。
どれも、英語力ではなくアプリの設計で決まっている部分だ。
だから「AIが嘘をついた」と感じる場面の一部は、道具の呼び出しと返事のタイミングのずれとして説明がつく。
AI英会話の関数呼び出し｜よくある質問
Q. AIが勝手に外部のサービスを操作することはあるのか。 A. 呼べるのは、アプリ側が session.tools や response.tools で渡した関数だけだ。一覧に無いものは注文票に書けない。
Q. 「予約しておきました」と言われたら信じていいのか。 A. 公式ドキュメントは、自然に聞こえる返事は道具の実行やアプリの状態変化の証明にならないと書いている。確認は画面の状態のほうで取るのが仕様に沿った読み方だ。
Q. 道具を呼ぶかどうかは誰が決めているのか。 A. tool_choice を "auto" にした場合はAIが決める。判断の材料は関数と引数に添えられた description の文章だと明記されている。
Q. 途中で処理を止めることはできるのか。 A. 承認の仕組みでは、道具を実行せずに承認待ちとして記録し、interruptions と再開用の state を返す。承認が遅れるなら state を保存して後から再開してよいと書かれている。
Q. 会話の履歴を見れば、裏でやったことは全部わかるのか。 A. response.conversation を none にした返事は、既定の会話状態に追加されないと書かれている。履歴に出ない処理は存在しうる。
まとめ｜AI英会話の関数呼び出しは「注文票と実行者」を分ける仕組み
もう一度整理する。
- 関数呼び出しは4段の往復＝道具を渡す／AIが引数を出す／アプリが実行する／結果を戻して返事を作らせる。
- AIが返すのは
function_callという注文票で、nameargumentscall_idの3つが要になる。 - 道具を選ぶ材料は説明文（
description）。日本語や英語の文章が、そのまま分岐の条件になっている。 - 自然な返事は実行の証明にならないと公式ドキュメントが明記している。先に言ってしまう挙動は想定されている。
- 止める仕掛け（承認）と、会話に残さない裏の呼び出し（
conversation: none）の両方が用意されている。
⇒ AI英会話で道具が絡む機能を見るときは、「AIが何をできるか」ではなく「どこまでがAIの注文で、どこからがアプリの実行か」で線を引く。そこが分かっていれば、返事の遅さも、反映されない記録も、仕様の側から説明できる。
※本記事の一次ソースは、各公式ドキュメントを2026-09-16および2026-09-18に取得した生テキストで確認した。仕様は更新されるため、最新は各公式ドキュメントで確認してほしい。
Comments