業務アプリに AI エージェントを組み込むとき、どの操作で人が止めるか：承認ゲートと監査ログの決め方

業務アプリに AI エージェントを組み込む話が増えています。問い合わせの下書き、受注データの更新、顧客へのメール送信など、AI に任せたい作業はたくさんあります。一方で、事業責任者が決めておきたいのは「どこまで任せるか」です。AI の賢さの話ではなく、どの操作の前で人が止めるか、あとから何を確かめられるようにするかという、仕組みの話になります。

この記事では、最近の提言と公開資料を手がかりに、業務アプリの操作単位で承認と記録を決めるための考え方を整理します。依頼先の選び方や引き渡しの確認、AI に任せる範囲の広げ方そのものは扱わず、操作ごとの承認とログに絞ります。

最近の提言：統制の仕組みはモデルの外に置く

ITmedia AI+ の記事（2026 年 10 月 12 日）によると、Microsoft の Nadella CEO は 10 月 10 日（現地時間）に X へ投稿し、フロンティアモデルを組織内の「インサイダーリスク」と同じように扱い、統制の仕組みをモデルの外側に置くよう提言しました。モデルが悪意を持つからではなく、重要なシステムにアクセスできる主体はミスや侵害を受けうるから、という理由です。

記事は、知能の供給と、それに対する権限を切り離す考え方だと説明しています。示された 7 つの設計原則には、改ざんできない証拠を残すこと、権限を持つ人間がタスクの途中でもモデルを停止できること、検証を検証対象のモデルから切り離すことなどが含まれます。

この提言は大きな組織の安全策についてのものです。ただ、業務アプリに AI を組み込む場面にも通じる考え方があると私たちは見ています。AI に何を許すかは、AI の判断に任せず、アプリの側の仕組みで決める、ということです。

考え方 1：権限は 4 段階に分けて、一度に許さない

AI エージェントのガバナンスを解説した funnel-ai の記事（2026 年 1 月公開、同年 7 月更新と記載）は、読み取り、提案（下書き）、更新、送信の 4 段階を一度に許可しないことが重要だとしています。まず読み取りと提案から始め、本番で慣れてから更新系に進むという進め方です。

業務アプリに当てはめると、次のように考えられます。

• 読み取り：画面に出ているデータを見て要約する、検索する
• 提案（下書き）：返信文や入力内容の案を作る。確定はしない
• 更新：受注ステータスや顧客情報など、アプリ内のデータを書き換える
• 送信・公開：顧客へのメール、外部システムへの連携、公開ページの更新

段階が進むほど、間違えたときに戻しにくくなります。最初の段階では読み取りと提案に絞り、実際の業務で使って様子を見てから、更新や送信を足していく順番が安全だと私たちは考えています。

考え方 2：承認は「戻しにくい操作」の直前に置く

funnel-ai の記事は、承認を送信、更新、公開の直前に置くこと、事故のコストが高い操作に絞ることを挙げています。顧客への送信、CRM の更新、公開コンテンツがその例です。また、承認者は役職名ではなく、実際に操作を止められる人にするとも書かれています。承認の数を増やすより、重要な操作に絞るという考え方です。

承認を増やしすぎると、確認が形だけになるおそれがあります（これは私たちの見解です）。同記事は、承認の差し戻し率を指標にして、運用が重すぎないかを見ることも勧めています。

考え方 3：実行前の機械的なチェックと、環境の分離

AI の開発・運用環境の権限設計を解説した FYVE の記事（2026 年 5 月 29 日公開）は、権限を allow（許可）、ask（都度確認）、deny（拒否）の 3 段階で設定すること、送信・削除・課金のような機密度の高い操作は都度確認にすることを挙げています。さらに、Hooks で実行の前後に強制チェックを入れ、クライアント情報の混入などを機械的に検査する例も紹介しています。人の目に頼るだけでなく、機械で止められるものは機械で止める、という考え方です。

funnel-ai の記事には、テスト環境と本番環境の API キーを混在させた事例が出てきます（同記事は実際のインシデント例としていますが、出典は示されていません）。原因はモデルではなく、接続先の環境分離の不備だったとされています。同記事は、本番への接続に別ロールによる承認を求めることを勧めています。

FYVE の記事は開発環境での AI の使い方を扱っており、業務アプリに組み込む AI エージェントの話とは前提が違います。ただ、「許可、都度確認、拒否の 3 段階で考える」「テストと本番を分ける」という整理は、業務アプリの設計でも使えると私たちは考えています。

操作別の判断表

ここまでを踏まえて、業務アプリの操作を例に、承認と記録の置き方を表にしました。これは出典にある表ではなく、上の考え方をもとにした私たちの整理の例です。実際の業務では、扱うデータや影響範囲に合わせて見直してください。

操作の例	戻しやすさ	承認の置き方（例）	記録したいこと（例）
画面データの検索・要約	影響が小さい	承認なし	誰が、いつ、何を参照したか
返信文・入力内容の下書き	確定前なので戻せる	承認なし（確定の操作で承認）	下書きの元データ、生成した案
自社の内部データの更新（ステータス、メモなど）	履歴があれば戻せる	重要度に応じて、確認画面か承認	更新前後の差分、実行者
顧客データ・金額・在庫の更新	戻しにくい	人の承認を必須にする	更新前後の差分、承認者、承認時刻
顧客へのメール送信	戻せない	人の承認を必須にする	送信内容、宛先、承認の有無
外部サービスへの連携・課金・削除	戻せない場合が多い	人の承認を必須にする（別ロールでの承認を求める案もある）	接続先、操作結果、承認の有無
公開ページ・公開コンテンツの更新	外部に見える	人の承認を必須にする	変更内容、承認者

判断の軸は、戻しやすさと、外部への影響です。迷う操作は、承認を置く側に倒しておき、運用してから緩めるほうが、逆よりも安全に進められると私たちは考えています。

監査ログに残すもの

funnel-ai の記事は、監査ログに残す項目として、入力データの出所、実行時刻、接続先、操作結果、承認の有無を挙げています。モデル内部の詳細より、業務上の行為を中心に残すほうが有効だという考え方です。FYVE の記事も、実行日時、実行内容、対象データ、結果（変更前後の差分を含む）を最低限の項目として挙げ、後付けではなく最初から設計に入れることを勧めています。

2 つの記事に共通するのは、実行した時刻（日時）と操作の結果を残すことです。そのうえで、funnel-ai は承認の有無を、FYVE は更新前後の差分を挙げています。ログは事故の調査だけでなく、承認ゲートが適切な位置にあるかを見直す材料にもなります。「この承認はいつも通っている」「この操作は差し戻しが多い」といった傾向が見えるためです（これは私たちの見解です）。

発注前に決めておきたいこと

業務アプリの開発を外部に頼む場合は、次の点を要件に含めておくと、あとから手戻りが起きにくくなります。

1. AI が行える操作の一覧と、それぞれの段階（読み取り、下書き、更新、送信）
2. 人の承認が必要な操作と、承認できる人（実際に止められる人）
3. 承認を待つ間、操作がどう保留されるか、期限が切れたらどうなるか
4. 監査ログの項目と保存期間、誰が見られるか
5. テスト環境と本番環境の分離（接続先、キーの管理）
6. 緊急時に AI の動作を止める方法と、止められる人

6 つ目は、Nadella 氏の提言にある「人間による強制停止」にあたります。画面にスイッチを用意するのか、設定で権限を外すのかなど、方法は設計で決めることです。

まとめ

• AI に許す操作は、読み取り、下書き、更新、送信の順に、一度に許さず段階的に広げる
• 承認は戻しにくい操作の直前に絞って置き、承認者は実際に止められる人にする
• 実行前の機械的なチェックと、テスト・本番の分離を、仕組みとして用意する
• 監査ログは、実行時刻と操作の結果を軸に、承認の有無や更新の差分など、操作に応じた項目を残す

私たちは、業務アプリの新規開発・リプレイスを要件定義から公開後の改善まで支援する「SaaS・業務アプリ開発」と、本開発の前に短期間で確かめる「AIプロトタイプ・MVP開発」を提供しています。AI 機能を載せる業務アプリについても、ご相談ください。