AIに業務を実行させる前に、誰が何を承認するか。承認待ち・却下・内容変更を含む業務フローと、発注時に合意したい受入条件を整理します。
AIエージェントの導入では、提案の正しさと、実行してよい権限を別々に確認します。発注書に「人が確認する」とだけ書くと、何を見て承認するか、内容が変わったらどうするかが曖昧になります。まず一つの業務を選び、実行前に止める場所と、止まった後の担当者を決めましょう。
公式資料で確認できる承認の仕組み
Google ADKには、ツールの処理をいったん止め、利用者などから確認を受け取るTool Confirmationがあります。単純な可否の確認と、構造化した情報を受け取る方法が説明されています。確認時点では実験的な機能で、セッション管理との組み合わせに制限があるため、採用時には利用環境で対応状況を確認する必要があります。
Google ADK：Action confirmations
以下はFor fによる設計上の提案です。特定製品を必須にするものではなく、業務担当者と開発担当者が依頼範囲を決めるための整理です。
承認対象は、文章より具体的な実行内容にする
確認画面には、対象の取引や顧客、更新前後の値、送信先、添付資料、取り消せる範囲を示します。「処理してよいですか」という一文だけでは、承認者は影響を判断できません。AIの説明文と実際に送る値が一致することを確認し、承認後に値が変更された場合は再承認する条件を設けます。
実行権限と承認権限を分けて整理する
閲覧できる利用者が、そのまま更新を承認できるとは限りません。申請者、承認者、実行するシステムの権限を一覧にし、代理承認や担当不在の扱いも決めます。画面上でボタンを隠すだけでなく、実行を受け付ける側でも承認者と対象操作を確認する設計を依頼します。
待機・却下・期限切れを通常の業務として扱う
承認待ちの間に在庫や金額が変わることを想定します。何時間待てるかを業務側で決め、期限切れや却下から勝手に実行へ進まないことを確かめます。担当者への通知、差し戻し理由、再申請する方法も成果物に含めると、現場で処理が取り残される原因を探しやすくなります。
仮定の例：見積書を作成し、顧客へ送る
AIが見積書の下書きを作り、営業担当が確認して送信する業務を想定します。試作ではまず送信せず、商品・数量・値引き・宛先を含む承認画面を評価します。承認後に値引きを変更した場合、古い承認で送れないかを試します。この例は設計の説明であり、For fの導入実績や効果数値ではありません。
受入検証で残したい証拠
- 承認者、承認時刻、承認した内容の版、実行結果が対応している記録
- 却下・期限切れ・権限不足・承認後の内容変更で実行されない検証結果
- 承認画面に出す情報と、ログに残してよい情報を分けた仕様
すべてを毎回承認すると確認の負荷が増えます。開始時は影響が大きい操作を対象にし、承認待ちの件数、差し戻し理由、担当者の確認時間を記録します。自動化を広げる判断は、その記録と業務上の許容範囲を合わせて行い、承認を省く条件を文書化します。
相談前に用意するもの
現在の申請・承認フロー、実行したい操作の一覧、承認画面に必要な項目、担当不在時の対応を用意すると、見積もりの範囲を絞れます。仕様が未確定なら、更新機能を作る前に承認画面と状態遷移を試作し、業務側が判断できるかを先に確認する方法もあります。
承認ボタンがあれば安全に使えますか？
ボタンだけでは足りません。誰が、どの版の内容に、どの権限で承認したかを実行側で確認できることが重要です。承認後の内容変更や、担当者が判断できない情報不足も、受入検証の対象にしてください。
For fに相談する
現在の業務と、今回確かめたいことから対象範囲を整理します。資料が揃っていない場合も、分かっている範囲からご相談ください。
参考資料・情報確認日
公式ページの公開日・更新日は確認できませんでした。
情報確認日：2026年9月22日。製品の機能・条件は変更されることがあります。導入時は最新の公式資料と利用環境を確認してください。
サムネイルはAI生成による概念イメージです。実際のシステム画面や測定結果ではありません。