AIエージェント時代の人間の役割設計: レビュアー、承認者、改善オーナーを分ける

1. 概要: AIが働いても責任は消えない

AIエージェントのデモは、一つの良いプロンプトでもかなり見栄えよく作れます。難しいのはその後です。エージェントが実務フローに入り、会社の文脈を読み、顧客向け文面を作り、CRMフィールドを変更し、メッセージ送信やツール実行を求める瞬間から、これは運用問題になります。

この時、人間の役割が曖昧ではいけません。全員が「誰かが確認するだろう」と思うと、品質境界は誰にも所有されません。すべての行動が創業者一人に集中すると、エージェントは見た目の良い待ち行列になります。逆にレビューなしで行動させると、速度は出ますが責任が消えます。

だから人間の役割設計は技術問題ではなく運用問題です。OpenAI Agents SDKの文書は、人間承認とguardrailを具体的なワークフロー機構として扱っています。NIST AI RMFも、ガバナンス、リスク把握、測定、管理を重視します。簡単に言えば、エージェントが行動する前に誰が何を責任を持つかを決める必要があります。

2. やさしい用語整理: 役割表、レビュアー、承認者、エスカレーション

役割表は、AIが業務に入った時に誰が何をするかを書いたシンプルな表です。エンジニアだけでなく、事業担当者が読める必要があります。

ワークフローオーナーは、最終的なビジネス結果に責任を持つ人です。返金業務が失敗した場合、AIが下書きを作ったとしても、運用上の修正責任はこの人が持ちます。

レビュアーは品質を確認する人です。回答、情報源、トレース、変更フィールド、リスクを見て、「この結果は正しく十分か」を判断します。

承認者は実際に影響を与える行動を許可する人です。メール送信、記録変更、返金処理、デプロイ、顧客連絡のように外の世界に影響する行動を、「今やってよいか」と判断します。

• エスカレーション: 不確実または高リスクのケースを、最初のレビュアーに無理に判断させず、上位の責任者へ渡す経路。
• 監査記録: 誰がレビューし、誰が承認し、何が変わり、なぜ変わったかを残す記録。
• RACI: responsible、accountable、consulted、informedの略。AI導入では複雑な儀式ではなく、役割漏れを防ぐチェックリストとして軽く使えば十分です。
• 改善オーナー: 反復する失敗をSOP、プロンプト、権限、評価ケース、学習例へ戻す人。

3. 失敗パターン: 人間が疲れた監視役になる

一つ目の悪いパターンは「人間=監視役」です。エージェントが走り、人間はキューを見ながら承認ボタンを押します。安全に見えますが、実際には承認ごっこになりやすいです。人間が要約だけを見て承認し、エージェントが何を読み、何を変更するのかを確認できないからです。

LangChainやAIエージェント関連のReddit議論でも、同じ運用問題が繰り返されています。重要なのは承認ボタンそのものではなく、判断の瞬間に行動内容、理由、リスク、影響を受ける記録、ロールバック経路が見えることです。これは検証済み統計ではなくコミュニティシグナルですが、現場の痛みは一貫しています。

二つ目の悪いパターンは「人間=後始末担当」です。エージェントが失敗し、人間が手で直し、その修正がシステムに戻りません。するとAIはより速い混乱を作ります。修正は必ずSOP、プロンプト、権限、評価ケースに戻すべきです。

• 弱いレビュー: 「この顧客返信を承認しますか？」
• 良いレビュー: 「この返信はこの三つの情報源に基づき、この二つのフィールドを変更し、リスクはこれで、ロールバック経路はこれです。承認しますか？」
• 弱い改善: 「次から気をつけるように言う。」
• 良い改善: 「SOPルール一つ、評価ケース一つ、権限境界一つを追加する。」

4. 役割1: ワークフローオーナー

ワークフローオーナーはプロンプトを書く人ではありません。ビジネス結果を所有する人です。顧客サポートならサポートリード、財務ならコントローラー、営業運用ならCRMオーナーかもしれません。

オーナーは業務範囲、許容できるエラー水準、承認基準、ロールバックルールを決めます。この人がいないと、AIプロジェクトは安全に広げられない技術実験になります。

Guildex型の自動化診断では、最初の項目がワークフローオーナーです。「どのエージェントを使うか」より先に、「導入後にこの業務を誰が所有するか」を聞くべきです。

• ビジネス結果と品質目標を所有する。
• 業務範囲と除外範囲を決める。
• 下書き専用からレビュー後の行動へ広げるか決める。
• エージェント品質が悪化した時のロールバック判断を所有する。

5. 役割2: レビュアー

レビュアーは仕事を判断できる人です。最終回答に判子を押す管理者とは違います。レビュアーはエージェントがどの経路で判断したかを見られる必要があります。

良いレビュー画面には、入力、情報源、ツール呼び出し、下書き、変更フィールド、信頼度、リスクラベル、類似した過去失敗が表示されるべきです。OpenAIのtracingやguardrailの考え方も同じ方向を示しています。レビューは実行文脈が見える状態で行う必要があります。

レビュアーの仕事はすべてを書き直すことではありません。失敗をラベル付けすることです。情報源が間違っていたのか、トーンが違ったのか、ポリシーが抜けたのか、ツール呼び出しが不要だったのか。このラベルが改善ループに入ります。

• レビュー項目: 情報源の正確性、ポリシー適合、トーン、抜けた文脈、変更フィールド、リスク、トレース品質。
• レビュー結果: 承認、修正依頼、拒否、エスカレーション。
• レビュー指標: 人の修正率、拒否理由、レビュー時間、反復失敗タイプ。

6. 役割3: 承認者

承認者は外部への影響に責任を持ちます。メール送信、DB記録変更、返金処理、ファイル削除、コードデプロイ、顧客連絡は下書き作成とは違います。これらの行動は外の世界に痕跡を残します。

OpenAIとMicrosoftのエージェントフレームワーク文書は、どちらもツール呼び出し前の人間承認パターンを説明しています。実務的には、敏感な行動の前にシステムが止まり、行動を明確に見せ、人間の判断後に再開するという意味です。

承認者はすべての小さなステップを承認する必要はありません。承認は、戻しにくい、顧客に見える、お金・法務・セキュリティ・評判に影響する行動に置くべきです。

• 返信下書き: 多くの場合レビュアーゲート。
• 返信送信: 顧客向けまたは高リスクなら承認者ゲート。
• 返金メモ作成: レビュアーゲート。
• 返金実行: 承認者ゲート。
• 低リスクの内部タグ変更: 十分に検証された後なら自動化可能。

7. 役割4: 改善オーナー

改善オーナーは最も抜けやすい役割です。この人は、人間レビューが消えずに蓄積されるようにします。この役割がないと、すべての修正は一つのチケット、一つのSlackスレッド、一人の記憶に閉じ込められます。

改善オーナーはSOP、プロンプト、権限表、評価ケース、スコアカード、失敗分類表を管理します。同じエラーが三回出たら、エージェントにもっと注意しろと言うのではなく、システムを変えます。

x-inbox-routerで拾ったOpenHarness、会社OS、skill、MCP関連のシグナルも同じ教訓を示しています。モデルは運用システムの一部にすぎません。持続する価値はモデル周辺の手順から生まれます。

• 新しい失敗例をゴールドセットに追加する。
• SOPとプロンプト指示を名前付き変更として更新する。
• 根拠に基づいてツール権限を狭める、または広げる。
• 毎週の反復パターンをワークフローオーナーへ報告する。

8. Guildex役割表

最初のAI業務では、表は小さく始めれば十分です。一つの業務に一行でかまいません。目的は官僚制を作ることではなく、責任が見えなくなるのを防ぐことです。

最初の行には、業務、エージェントの担当、ワークフローオーナー、レビュアー、承認者、エスカレーション担当、改善オーナー、承認基準、ロールバックルール、週次指標を書きます。

初期は一人が複数の役割を持っても問題ありません。問題は一人が複数の帽子をかぶることではなく、その帽子の名前を誰も決めていないことです。

• 顧客返信下書き: サポートリードが所有、シニアサポートがレビュー、リスクある送信は創業者が承認、運用担当がSOP改善。
• CRM更新: 営業運用が所有、アカウント担当がレビュー、高価値アカウント変更は売上責任者が承認、営業運用がフィールド規則を改善。
• 内部リサーチ要約: 創業者が所有、運用担当がレビュー、外部行動につながらなければ承認不要。

9. エージェント拡張前チェックリスト

AIエージェントを下書き専用から実際の行動へ広げる前に、役割の質問に答える必要があります。この業務は誰が所有するのか。誰が品質を判断できるのか。誰が戻しにくい行動を承認するのか。誰がエスカレーションを受けるのか。誰が失敗後にシステムを更新するのか。

この答えがないなら、次のステップは大きなモデルではありません。役割設計です。AIは業務を速くできますが、役割設計があって初めて業務を統制できます。

• すべての業務に一人のオーナーがいる。
• リスクある出力には十分な文脈を見られるレビュアーがいる。
• 影響のある行動には承認者と明確な行動要約がある。
• すべての承認には監査記録が残る。
• 反復失敗はSOP、プロンプト、権限、評価ケースのどれかに戻る。