Function Callingは権限ではない:AIツールの安全設計

検証、最小権限、確認、監査可能なツール実行により、モデルの提案とアプリケーションの権限を分離する方法。

A proposed tool action stopped at a permission checkpoint

モデルが生成した関数呼び出しは、構造化された提案です。その提案が有効で、許可され、安全に実行できるかを決めるのはモデルではなくアプリケーションです。

制御境界を理解する

Function Callingでは、モデルが宣言済みの操作を選び、引数を生成します。Googleの文書は実行境界を明確にしています。関数コードを実行するのはアプリケーションです。この分離が安全設計の基礎です。

構文上有効な引数を権限として扱ってはいけません。モデルはユーザーを誤解し、注入された指示を繰り返し、過剰な操作を選ぶことがあります。認証はユーザーを特定しますが、認可では要求された資源と操作を改めて確認する必要があります。

用途を絞ったツールを設計する

任意の内部APIを呼べる汎用エンドポイントより、draft_refundとsubmit_refundを選びます。各ツールには必要最小限のデータ範囲と副作用だけを与え、識別子、送信先、操作種別には許可リストを使います。

説明には前提条件と対象外を明記します。ツールスキーマに秘密情報を置いたり、不要な個人データを返したりしてはいけません。モデルに必要なのは正しく選べるだけの文脈であり、バックエンドへの無制限アクセスではありません。

通常のコードで検証する

厳密なスキーマで解析し、値を正規化し、解析後にビジネスルールを適用します。価格と権限はサーバー側で再計算します。検索内容に埋め込まれ、権限拡大を狙う指示は拒否します。操作を現在のユーザー、セッション、承認済み資源に結び付けます。

反復可能な書き込みには冪等性キーを使い、ドライランと確定を分けます。タイムアウトや曖昧な応答があれば、操作を重複させる盲目的な再試行ではなく、読み戻して整合を確認します。

結果の重大さに応じて確認を求める

低リスクで元に戻せる参照は自動実行できます。外部メッセージ、購入、削除、権限変更、公開投稿にはプレビューまたは明示的な確認が必要です。生のJSONではなく、宛先、金額、対象、効果といった意味のある項目を示します。

確認は、内容を固定した正確なペイロードに結び付けます。モデルが後から引数を変えたら、再度確認を求めます。承認には有効期限を設け、一度の確認でユーザーが見ていない一連の操作を許可しないようにします。

判断と結果を監査する

ユーザー要求、選択したツール、検証済み引数、ポリシー判断、確認、結果を記録します。秘密情報は伏せつつ、インシデント調査に十分な証拠を残します。拒否された呼び出し、繰り返す再試行、不自然なツール列を監視します。

直接的なプロンプトインジェクションと、ツールが返す悪意ある内容をテストします。目標は、モデルが悪い呼び出しを一度も提案しないことではなく、悪い提案が実行境界を越えられないシステムです。

実践に移す方法

まず、Function Callingと権限を分離するAIツール安全設計に関わる範囲の限られたワークフローを一つ選びます。システムを変える前に、現在の完了時間、品質チェック、主な失敗分類、エスカレーション経路、結果の責任者を1ページにまとめます。最も整った例だけでなく代表的なサンプルを選び、通常例、難しい境界例、停止または追加情報の確認が正解となる例を少なくとも一つ含めます。

既存プロセスを置き換える前に、候補システムを並行稼働させます。誤り率が下がっても新たな重大事故を隠すことがあるため、成功と失敗の両方を確認します。各テストの正確な構成を記録し、別のレビュー担当者が再現できる成果物を残します。試行の終了時には、最良のデモを見た後の印象ではなく、事前に合意したしきい値に基づいて、拡大、修正、中止を決めます。

ベンダーや社内チームへの確認事項

中心的な主張を支える証拠、その証拠を生成したシステム版とデータ版、除外条件を確認します。導入先で扱う言語、入力形式、リスク分類ごとの結果を求めます。変更の告知方法、回帰の検出方法、インシデント調査に必要なログを顧客が書き出せるかも確認します。

確信度が低い場合、依存先が失敗した場合、依頼が対応範囲外の場合に、システムがどう動くかも確認します。信頼できる製品には、単に洗練された回答ではなく、定義済みの失敗状態が必要です。責任体制も重要です。ワークフローを停止できる人、例外を承認する人、重大な誤りが本番へ流出したとき影響を受けたユーザーへ知らせる人を特定します。

実践チェックリスト

  • モデルやツールを選ぶ前に、ユーザーのタスクと重視すべき失敗を定義する。
  • 実務から抽出した、扱いにくいケースや敵対的ケースを含む小規模なテストセットを版管理する。
  • 実行ごとに、モデル、プロンプト、ツール、検索設定、データ版、遅延、コストを記録する。
  • 元に戻せない、影響が大きい、または外部から見える操作には、人による確認を必須にする。
  • 一つの平均点だけでなく分類別に失敗を確認し、回帰ケースをテストセットへ追加する。

Meydo Journalの関連記事

一次情報