AIが動く前に人へ確認すべき瞬間

1. 概要: 良い自動化は止まる瞬間を知っている

多くのAIデモは派手な場面を見せます。エージェントが検索し、下書きを作り、ファイルを直し、toolを呼び出し、成果物を出します。しかし実際の運用は、地味な場面で壊れます。誤ったメッセージを送り、誤ったfieldを更新し、誤ったdataを公開し、誤ったrecordを削除し、弱い推測を確信のように実行するときです。解決策はagentを避けることではありません。権限境界を与えることです。

権限境界は「AIが今やってよい仕事」と「AIが先に聞くべき仕事」の間の運用線です。簡単に言えば、新人が返金案内文は準備できても承認なしで返金実行はできず、営業アシスタントが提案書は作れても一人で割引を約束できない、という考え方です。

公式文書の方向も同じです。OpenAI Agents guardrails/approvalsはguardrailの結果に応じて続行、停止、human reviewへ回す処理を説明しています。MCP toolsはtool callをユーザーが見て、敏感な呼び出しを確認し、状態と結果をlogに残す前提で扱います。Codexがapproval modeとsandboxを持つのも、file write、shell command、network accessが単なる文章ではなく現実を変える行動だからです。

2. 小さな用語集: 言葉は難しくても概念は単純

Human-in-the-loopとは、AIが仕事をする一方で、重要な瞬間には人間がdecision loopの中に残る構造です。すべての出力を人が書き直すという意味ではありません。人間が判断すべき瞬間をシステムが知っているという意味です。

Approval gateは実行前のチェックポイントです。エージェントは何をしようとしているのか、なぜそうするのか、根拠は何かを見せます。人間はapprove、edit、rejectのどれかを選びます。Escalationは、危険、曖昧、情報不足のためエージェントが人間に渡すことです。

Confidence thresholdは、不確実性がこの線を超えたら自動実行しないという基準です。Side effectはモデルの外側を変える行動です。メール送信、CRM更新、お金の移動、database変更、コンテンツ公開、command実行、API呼び出しが含まれます。Audit logは後で再構成できる証拠です。誰または何が、いつ、なぜ、どの入力で、どんな結果を作ったかを残す記録です。

• Human-in-the-loop: AIが働くが、重要な判断には人間が残る構造です。
• Approval gate: 実際の行動が起きる前の承認チェックポイントです。
• Escalation: エージェントが危険または曖昧な仕事を人間へ渡すことです。
• Side effect: 顧客、file、system、決済、message、recordを変える行動です。
• Audit log: 後で行動を再構成できるように残す記録です。

3. レーン1: AIが基本的に自動実行できる仕事

最も安全な自動化レーンは、内部向けで、戻しやすく、費用が低く、検証しやすい仕事です。会議要約、support ticket分類、invoiceからのfield抽出、下書きformatting、関連SOPページ検索、customer feedbackのグルーピング、内部メモ翻訳、レビュー用checklist作成が例です。

もちろん自動実行は無制御という意味ではありません。会社知識に基づく回答なら出典を示すべきです。logも残すべきです。最新policyが重要な仕事なら古い文書を使わないようにすべきです。しかし、すべてのformattingや低リスク分類に人間承認が必要なら、システムは手作業より遅くなります。

実務ルールは単純です。read-onlyで、内部用で、戻しやすく、修正費用が低いなら、自動化を基本値にできます。その代わり、後でsample reviewをし、promptを改善し、反復失敗はeval caseへ変えます。

• 承認済み文書の中でread-only検索と要約を行います。
• 内部summary、classification、formatting、translation draftを作ります。
• 検証ルールがある低リスクdata extractionを処理します。
• 内部task ticket、SOP update、handoff noteの下書きを作ります。
• 人が変更判断をする前にfeedbackをまとめ、patternを見せます。

4. レーン2: AIが下書きを作り、人間が承認する仕事

多くのbusiness valueは第二レーンにあります。AIが70パーセントの仕事を処理し、最後のside effectは人間が承認する構造です。顧客返信、返金、outbound email、契約条項、lead qualification変更、公開投稿、support上の約束、敏感なCRM更新がここに入ります。

核心は不信ではなくleverageです。AIが根拠を集め、行動の下書きを作り、不確実性を示し、何が変わるかを説明します。人間は意思決定にだけ注意を使います。最初から人間が全部書くより速く、agentに直接実行権限を与えるより安全です。

OpenAIのapproval patternとCodexのpermission modeは良い参考になります。エージェントがtool call直前に止まり、提案された行動を見せ、approval後にだけresumeする方式です。business workflowの承認画面は五つの質問に答えるべきです。何が変わるか、誰が影響を受けるか、根拠は何か、何が失敗しうるか、どう戻すか。

• 顧客に送るemail、chat reply、案内文を送信します。
• 返金、coupon、割引、upgrade、cancellationを実行します。
• blog、landing page、sales page、social postを公開します。
• pipeline、価格、顧客状態に影響するCRM fieldを変えます。
• 契約下書き、法務関連回答、policy例外、payment requestを作ります。

5. レーン3: 基本禁止、または毎回明示承認

一部の行動は、モデルがtoolを呼べるという理由だけで自動化してはいけません。お金の移動、account削除、credential変更、個人情報共有、戻しにくいproduction write、法的約束、医療または金融判断、大量outbound、destructive file operationには強い境界が必要です。

ここでHuman-in-the-loopはUXの好みではなく管理ルールです。システムは毎回明示承認を求め、場合によっては二人承認も必要です。agentは曖昧なcontinueボタンの裏に行動を隠してはいけません。正確な行動、影響を受けるsystem、想定blast radius、rollback planを見せるべきです。

NIST AI Risk Management Frameworkが役立つのもここです。AIリスクはモデル精度だけの問題ではありません。誰が被害を受けうるか、影響がどれほど大きいか、行動を戻せるか、組織が後からどんな証拠を示せるかが重要です。

• お金を移動し、billingを変え、一定金額以上のrefundを承認し、payment detailを修正します。
• accountを削除し、dataを消し、credentialを変え、access controlを更新します。
• 個人情報、機密情報、規制対象情報、顧客の敏感情報を共有します。
• production deploy、destructive command、重要record overwriteを実行します。
• 法律、医療、金融、compliance、HR判断を責任者レビューなしで確定します。

6. MCPとtool callingを接続する前に設計する

MCPは簡単に言えば標準connectorです。AI applicationがfile、API、database、business toolへ共通方式でアクセスするのを助けます。Tool callingはモデルがその機能を実際に使いたいと要求する瞬間です。Skillやplaybookは反復業務を行うために保存した手順書です。この三つは同じものではなく、違う層です。

ローカルX inboxでもこの信号は強く出ていました。ビルダーたちはpromptだけを話していません。toolsが実行される前のapproval、MCP server management、すべてのtool callとerrorのstructured log、permission、hook、lifecycle check、safeguardを話しています。実務の方向は明確です。toolは接続する。ただし行動境界を見えるようにする。

失敗は、すべてのtoolを先につなぎ、承認ルールを後で書くことです。agentがemailを送り、CRMを更新し、private recordを取得し、commandを実行し、payment APIを呼べるようになった後では、failure surfaceはすでに大きい。より良い順序は単純です。actionを地図化し、riskを付け、approval ruleを決め、最初のtoolだけを接続し、logで安定性を確認してから広げます。

7. 小さな会社がすぐ使える承認境界表

小さな会社が最初から大きなgovernance組織を作る必要はありません。まずは簡単な表です。workflowごとにaction、許可されたdata source、自動レーン、承認レーン、禁止レーン、owner、log場所、rollback方法を書きます。Notion、Obsidian、repo Markdown、内部SOPフォルダで十分です。

宿泊運営者なら、AIに内部FAQ検索とguest question groupingは自動で任せられます。しかしrefund、late checkout、damage、compensationの約束は送信前に聞くべきです。Ecommerceではticket分類とreply draftは自動化できますが、refund実行、shipping address変更、policy exceptionは承認対象です。Outboundではlead researchとmessage draftはAIに任せ、大量送信は人間が承認します。

内部SOP lookupでは、agentが承認済み出典を引用して答えられますが、文書が衝突したりfreshnessが不確かならescalationします。Codeやoperationsではdiff提案とsafe check実行は任せられますが、destructive command、production deploy、credential作業、live systemに触れるnetwork actionは聞くようにします。

• 質問: この行動は外部に出るか、費用がかかるか、敏感か、戻しにくいか、法的意味があるか。
• そうでなければlogとsample reviewを前提に自動実行できます。
• そうであれば、先に下書きを作り、根拠を説明し、approvalを受けます。
• 影響範囲が大きいなら毎回明示承認を求め、rollback noteを残します。
• 絶対にしてはいけない行動は助言ではなくforbidden ruleとして書きます。

8. 承認を学習loopに変える

承認はブレーキだけではありません。運用のためのtraining dataです。approve、edit、reject、escalateされた行動はすべて、会社がagentに何を教えるべきかを示します。チームは反復承認事例を見て、ルールをより明確にできるか、出典を改善できるか、そのtaskをより安全な自動レーンへ移せるかを確認します。

だからaudit logが重要です。logは官僚主義ではありません。「AIが変なことをした」と「この日にagentがこのsourceを使い、このactionを提案し、人間がこのfieldを修正し、結果が承認された」の違いです。記録がなければincidentは感覚で残ります。記録があれば改善作業になります。

loopは単純です。approval caseを集め、なぜ承認が必要だったかlabelを付け、SOPを更新し、例を追加し、eval caseを作り、forbidden actionを明確にし、その次にautonomyを広げます。自律性は楽観で与えるものではなく、証拠で獲得するものです。

9. AIが発展するほど人間も一緒に発展すべき理由

AIが良くなっても、より良い人間が不要になるわけではありません。人間の能力が使われる場所が変わります。これから価値あるoperatorは、すべての返信を手で書く人だけではありません。仕事を定義し、source of truthを選び、approval boundaryを決め、failure patternを読み、反復修正をより良い運用システムへ変える人です。

だからHuman-in-the-loop設計はanti-automationではありません。より深い自動化への道です。人間がrisk、evidence、ownership、rollbackを明確に書けるようになると、agentは時間とともにより多くの仕事を安全に引き受けられます。人間は小さな仕事をすべて直接行う位置から、システムが信頼される条件を設計する位置へ上がります。

今週の最初の行動は小さくて十分です。AI workflowを一つ選び、自動実行、承認必要、禁止の三レーンに分けてください。ownerを一つ、log場所を一つ、rollback ruleを一つ付けます。その表一つが、別の曖昧なpromptより次のagentをずっと良くします。