AI Agentがデータを読み取り、判断し、APIを呼び出して実行までできるようになった今、問われているのは「AIにできるかどうか」ではなく、「この判断をAIに任せてよいのか」です。
この問いは、導入初期の高揚感の中では見落とされがちですが、実はAI Agentが長く信頼されて使われ続けるかどうかを分ける境界線そのものです。本記事では、どこまでをAIに完全に任せてよいか、どこはAIが提案するだけに留めるべきか、そしてどこは常に人が最終判断すべきか——その線引きのためのシンプルなフレームワークを提案します。
I. 課題：すべての判断が同じ重みを持つわけではない
AI Agentを設計するチームの多くは、最初からこう問いを立ててしまいがちです。「このステップは自動化すべきか？」——まるで自動化が、業務フロー全体に一律で適用される二択（する／しない）であるかのように。
しかし実際には、1つの業務フローの中には、性質のまったく異なる判断が混在しています。
- 単純なロジックチェックだけで済む判断（正誤が明確）
- データだけでは表現しきれない、ビジネス上の文脈理解が必要な判断
- 間違えても、すぐに修正できる判断
- 間違えると、取り返しがつかない判断（すでに顧客へ送付済み、すでに送金済み、すでにデータが削除済みなど）
これらすべてを「自動化するかどうか」という1つの問いにまとめてしまうことが、AI Agentプロジェクトが自動化しすぎて事故を起こすか、逆に慎重すぎて価値を生まないか、どちらかに振れてしまう原因になっています。
II. 判断を分類する2つの軸
業務フロー内の個々の判断は、次の2つの軸で分類できます。
軸1 — 確実性： この判断は、明確なルールに基づいて機械的に正誤を判定できるものか。それとも、文脈理解やビジネス上のトレードオフが絡み、唯一の「正解」が存在しないものか。
軸2 — 可逆性： 判断を誤った場合、それをすぐに発見し、修正できるか。それとも、影響がすでにシステムの外（顧客、金銭、失われたデータ）に及んでおり、取り消せない状態になっているか。
この2つの軸を組み合わせると、次の4つの領域に整理できます。
- 確実 × 可逆 → 完全に自動化してよい領域。
- 確実 × 不可逆 → 自動化はできるが、対象範囲の限定・監査ログなど、追加の保護策が必要な領域。
- 要判断 × 可逆 → AIが値を提案し、人が確認してから適用する領域。
- 要判断 × 不可逆 → 常に人が最終決定すべき領域。AIは情報提供・分析・提案に徹し、自ら実行してはならない。
III. 具体例：同じ業務フローの中にある4つの異なる判断
イメージしやすいように、よくある業務フロー——ECサイトにおける返金対応——を例に見てみましょう。これは4つの別々のシステムの話ではなく、同じ1つの業務フローの中にある4つの判断ステップであり、それぞれが異なる領域に属している、という点がポイントです。
ステップ1：返金条件の確認（領域1：確実 × 可逆）
注文が実在するか、購入日が規約上の返金受付期間（例：30日）内かをチェックします。これは日付の比較にすぎず、正誤以外の解釈の余地はありません。万が一判定を誤っても、担当者が開いて修正すればよく、金銭面ではまだ何も発生していません。→ 完全に自動化してよい。
ステップ2：社内システム上で「返金対象」とマークする（領域2：確実 × 不可逆）
注文がすべての条件（期間内、返金対象カテゴリ、過去に返金履歴がない）を満たした場合、システムが自動的にステータスを「返金承認済み」に変更します。これも明確なルールに基づいていますが、注文のステータスを上書きするため、誤りがあればその後の処理に影響します。そのため、対象範囲を厳密に限定し（すべての条件を満たす注文のみ）、後から確認できるよう監査ログを残します。→ 自動化するが、対象範囲の限定とログ記録を伴う。
ステップ3：具体的な返金額を提案する（領域3：要判断 × 可逆）
商品の一部をすでに使用している、あるいはセット割引を含む注文で按分計算が必要など、複雑なケースでは、AIが返金額とその算出根拠を提案します。担当者はその提案を確認し、必要に応じて修正してから確定します。まだ送金は行われていないため、提案が誤っていてもその場で修正すればよく、コストはかかりません。→ AIが提案し、人が確認する。
ステップ4：実際に返金を実行する（領域4：要判断 × 不可逆）
最後の行為は、自社の口座から顧客の口座・ウォレットへ実際に資金を移動させることです。一度送金してしまうと、特に電子ウォレットや他行への送金の場合、回収はほぼ不可能です。そのため、ステップ3で金額が正しく計算されていたとしても、「送金する」という行為には常に人による最終確認が必要であり、AIが自らこのボタンを押すことは決してあってはなりません。→ 常に人が決定する。
このように整理すると、「返金フローを自動化すべきかどうか」という問いはもはや意味を持ちません。4つのステップのうち3つは、それぞれ異なる度合いで自動化できる。最後の「実際の送金」だけが、常に人を必要とするのです。
IV. 重要なのは、境界を「コード」に置くこと。「プロンプト」ではない
よくある誤りは、プロンプトに「Xを行う前は必ず人に確認してください」と書けば十分だと考えてしまうことです。しかし、それは単なる「お願い」にすぎず、強制力を持つ制約ではありません。
上記4つの領域の境界は、実際のシステム上の制約として実装される必要があります。
- Toolは、人がすでに確認済みのパラメータのみを受け取り、機密性の高い値をAI自身が推測しない
- 領域4に該当する操作については、そもそもAIが呼び出せる機能として実装しない。実行の最後の一押しは、人だけがアクセスできる画面上で、人が直接行う
- 領域2・3・4のすべての操作は、誰が・いつ・どの値を選んだかが分かる形で監査ログに記録される
つまり、この4領域の分類は、AIに「守ってもらう」ためのガイドラインではなく、どのToolを存在させ、どのToolを存在させず、どのToolにどこまでの制約を持たせるかを決める、システム設計そのものなのです。
V. この境界は固定ではない。しかし変更は意図的であるべき
「自動化する領域」と「人が決定する領域」の境界は、永久に固定されたものではありません。AI Agentが実際の運用を通じて信頼性を積み重ねてきた場合——例えば、領域3での提案が何百回と続けて修正なしで承認されているような場合——一部のケースを領域3から領域2へ移すことを検討してもよいでしょう。
ただしそれは、実際の運用データに基づいた、意図的な設計判断でなければなりません。AIがこなす業務範囲が徐々に広がっていく中で、誰にも気づかれないまま境界が「なし崩し的に緩んでいく」ことがあってはならないのです。
まとめ
「このAI Agentは自動化すべきか」という問いは、業務フロー全体に対して立てる限り、常に誤った問いです。正しい問いは、「業務フロー内のこの個別の判断は、上記4領域のどれに該当するのか。そしてその境界は、コードによって守られているのか、それとも一行のプロンプトに『期待』しているだけなのか」ということです。
この境界を——事故が起きた後ではなく——最初から正しく設計しておくこと。それこそが、長く信頼され使われ続けるAI Agentと、一度試されただけで放棄されるAI Agentを分ける違いです。
