前回の構造化出力から「機能を呼ばせる」へ
前回のT-04では、モデルの出力を、決められた項目と型のデータとして受け取る構造化出力を学びました。今回はその出力を一歩進めて、モデルに「アプリの機能を呼び出させる」仕組みへ入ります。ここまでのT章と同じく、視点はAIをアプリの部品として組み込む側です。AIが自分で操作しているように見える機能が、実際にはどんな分担で動いているのかを、これから解きほぐします。
このスライドのポイント
- 前回T-04: モデルの出力を決まった項目と型のデータで受け取る構造化出力
- 今回: その出力を一歩進め、モデルに「アプリの機能を呼び出させる」
- 視点はT章共通で「AIをアプリの部品として組み込む側」
- AIが自分で操作しているように見える機能の、実際の分担を解きほぐす
ツールとFunction Callingの定義
まず用語を定義します。ツールとは、モデルに「使ってよい」と伝えておく関数の一覧で、それぞれ名前・説明・引数のスキーマを持ちます。関数はE-07で、スキーマはT-04で見たとおり、決められた項目と型の定義です。Function Callingとは、モデルが「この関数をこの引数で呼びたい」という構造化出力を返し、実行はアプリ側が行い、その結果をモデルへ返す、往復の仕組みです。ここで最も重要なのは、モデルは選ぶだけ、実行はアプリ、という分担です。だから実行の前に、アプリ側で内容を検証したり制限したりできます。J-06で見た信頼境界が、ここでも防衛線になります。
このスライドのポイント
- ツール: モデルに「使ってよい」と伝えておく関数（E-07）の一覧。名前・説明・引数のスキーマ（T-04）を持つ
- Function Calling: モデルが「この関数をこの引数で呼びたい」という構造化出力を返し、実行はアプリ側が行い、結果をモデルへ返す往復の仕組み
- 最重要: モデルは選ぶだけ、実行はアプリ
- だから実行前にアプリ側で検証・制限できる（J-06の信頼境界が防衛線）
なぜ必要か——恐怖と楽観の両方を正す
この構造を知らないと、二つの落とし穴にはまります。一つは、「AIが勝手にデータを消したらどうしよう」という漠然とした恐怖です。構造を知れば、実行する権利はつねにアプリ側にあり、何を許すかは設計で決められるとわかります。もう一つは逆に、モデルが返した呼び出しを、無検証で何でも実行してしまう危険な実装を見抜けないことです。恐怖にも楽観にも寄りすぎないために、まず仕組みを正確に押さえます。
このスライドのポイント
- 知らないと陥る落とし穴（1）: 「AIが勝手にデータを消したら」という漠然とした恐怖
- 構造を知れば、実行の権利はつねにアプリ側にあり、何を許すかは設計で決められるとわかる
- 落とし穴（2）: モデルの返した呼び出しを無検証で何でも実行する危険な実装を見抜けない
- 恐怖にも楽観にも寄りすぎないために、まず仕組みを正確に押さえる
処理の往復——「実行」の箱はアプリ側
処理の流れは往復です。まず利用者の質問がモデルへ渡り、モデルは使えるツールの中から「この関数をこの引数で呼びたい」と選びます。次にアプリが、その内容を検証してから実行し、結果をモデルへ返します。最後にモデルが、結果をふまえた回答を作ります。注目すべきは、この流れの中で実際に実行する箱が、アプリ側にあることです。モデルは提案するだけで、実行の引き金はアプリが握っています。
このスライドのポイント
- 往復の流れ: 質問→モデルが関数と引数を選ぶ→アプリが検証して実行→結果をモデルへ→最終回答
- モデルは「呼びたい関数と引数」を提案するだけ
- 実際に実行する箱はアプリ側にある
- 実行の引き金をアプリが握っているから、途中で止めることもできる
具体例——検索ツールは持たせ、削除ツールは持たせない
共通例の経費アプリで考えます。AI相談機能に、過去の申請を検索するツールを持たせるとします。検索は読み取りだけなので、A-09でいう低リスクの操作です。一方で、申請を削除するツールはどうでしょうか。削除は元に戻せないことがある高リスクの操作なので、そもそも持たせない、あるいは人間の承認を挟む設計にします。つまりA-09のリスクレベルの判断が、そのままツールを持たせるかどうかの設計に直結します。
このスライドのポイント
- 共通例の経費アプリのAI相談機能で考える
- 過去の申請を検索するツール: 検索は読み取りのみ＝A-09の低リスク→持たせてよい
- 申請を削除するツール: 削除は元に戻せないことがある＝A-09の高リスク
- 高リスクのツールは、そもそも持たせない、または人間の承認を挟む
- A-09のリスクレベルの判断が、ツール設計に直結する
技術サンプルカード——ツール定義のJSON
サンプルは、先ほどの検索ツールを定義したJSONです。上半分が、アプリからモデルへ渡すツールの定義で、名前・説明・引数のスキーマが並びます。下半分が、モデルが返してくる呼び出しの例です。読み方の要点は三つあります。一つ、引数もスキーマで制約されていて、たとえば取得件数に上限があること。二つ、これは読み取り専用のツールで、危険な操作を含まないこと。三つ、アプリはこの呼び出しを受け取っても、実行の前にQ-05の権限チェックを通し、AIの依頼であっても本人の権限を超えさせないことです。
このスライドのポイント
- 種別: json
- 目的: モデルへ渡すツールの定義と、モデルが返す呼び出しの形を確かめる
- サンプル本体:
混同しやすい概念——「モデルが実行する」という誤解
混同しやすいのは、「モデルが実行する」という誤解です。正しくは、モデルは呼びたい関数と引数を選ぶだけで、実行するのはアプリです。この違いが、二つの極端な態度を、どちらも正します。「AIが何でも実行してしまう」という恐怖も、「AIに任せれば全部やってくれる」という楽観も、実行権がアプリ側にあるという事実の前では的外れです。選ぶのはモデル、実行はアプリ。この一線を覚えてください。
バイブコーディングでの確認点
バイブコーディングでツールを持つAI機能を作るときは、必ず確認することがあります。まず、「書き込みや削除をするツールはあるか」を聞きます。次に、あるのなら「実行の前に検証と権限チェックが入っているか」を確かめます。AIへの質問例としては、「このAI機能が持つツールの一覧と、それぞれのリスクレベル・実行前の検証を表にしてください」が有効です。この確認は、次に学ぶ自律的なAIで重要になる、人間の承認を挟む線引きの準備にもなります。
このスライドのポイント
- ツールを持つAI機能では必ず確認する（1）: 書き込み・削除系のツールはあるか
- （2）: あるなら、実行前に検証と権限チェック（Q-05）が入っているか
- AIへの質問例: 「このAI機能が持つツールの一覧と、それぞれのリスクレベル・実行前の検証を表にしてください」
- この確認は、次に学ぶ自律的なAIで重要になる「人間の承認を挟む線引き」の準備になる
まとめと一問一答
最後に一問一答です。Function Callingで、実際に関数を実行するのは、モデルとアプリのどちらでしょうか。……答えはアプリ側です。モデルは呼びたい関数と引数を選ぶだけで、引き金を引くのはつねにアプリです。30秒のまとめです。ツールはモデルに使わせる関数の一覧、Function Callingはモデルが選びアプリが実行する往復の仕組み、そして危険な操作はリスクレベルで判断し、持たせない・承認を挟む・検証を通す、で守ります。次回は、意味の近さを数値で表す埋め込みベクトルへ進みます。関連資料は、「AIエージェント入門」「API連携 超入門」です。
このスライドのポイント
- 一問一答: 「Function Callingで、実際に関数を実行するのは？」→ 答: アプリ側（モデルは呼びたい関数と引数を選ぶだけ）
- 30秒まとめ: ツール＝使わせる関数の一覧／Function Calling＝モデルが選びアプリが実行する往復／危険な操作はリスクレベルで判断し「持たせない・承認・検証」で守る
- 次回: 意味の近さを数値で表す「埋め込みベクトル」へ
- 関連資料: 「AIエージェント入門」「API連携 超入門」
