Agent のボトルネックはあなたかもしれないので、毎月「人への依存度監査」を行おう

何が起きたか

@mihai673 が 30 日分の会話を振り返ると、「次は？」は 60 回、そのうち 32 回は直後の返事が「やって」でした¹。未処理の判断は朝のうちに長い列になり¹、Agent が増えるにつれ、管理だけでほぼ丸 1 日の勤務時間が埋まるようになりました³。ログイン画面で認証コードを待っていた Agent は、コードが来ないまま自らワークフローを一時停止しました⁴。これらの事例が示すことは同じです。ボトルネックはもはや Agent の賢さではなく、人間の注意力です²。コードをどれだけ速く書けても、その後で要件の確認やレビューを待っているなら、全体は速くなりません⁵。

Hugging Face などによる論文は、これを「承認疲れ」と呼んでいます。Agent の自律性が高まるほど、人は深く考えずに承認し、頼りすぎ、判断力も衰えやすくなるというものです⁶⁷。@anishmoonka がまとめた事例では、Claude Code が 1 回のセッションで同じ開発者に 47 回も権限を求め、そのたびに読まずに許可が押されていました⁸。

よく使われる方法

1. 毎月 1 回、Agent に棚卸しさせる。 「人への依存度監査」プロンプト¹⁶は、Agent に過去 1 か月を振り返らせ、あなたが何度も承認している箇所、何度も情報を補っている箇所、手作業で受け渡している箇所を挙げさせます。実際に実行された 2 例では、いずれも改善できる箇所が十数件見つかり、その大半が実際に改善されました¹⁷¹⁸。

2. リスクに応じて承認を段階分けする。 共通の原則は、元に戻せて影響の小さいものは任せ、お金、メール送信、削除、外部への公開が絡むものは人に残すことです¹³¹⁵。似たような監査では、ボトルネックの大半が、すでに 5 回承認した案件の再承認でした。常時の権限に切り替えたことで、どのプロンプトよりも多くの問題が解決しました¹⁹。PR が多すぎてレビューが追いつかないときは、チェック通過後に Agent が複数のリスク観点で各 PR を採点し、低リスクは自動承認、それ以外は人に通知する方法もあります。最後にマージを押すのは、やはり人です²³。

3. まず能力を制限し、それから承認を減らす。 サンドボックス、権限の絞り込み、開発環境と本番環境の分離によって、そもそも人に尋ねる必要のない操作が増えます。ただし、サンドボックスはファイルの誤削除は防げても、正当な権限を持つ Agent が本番データベースに誤った操作をすることは防げません。そうした操作は、引き続き毎回の承認が必要です¹²。

4. 別の Agent に先にレビューさせる。 OpenAI は、2 つ目の Agent が操作をレビューする Auto-review を公開しました。@thsottiaux が投稿したグラフでは、10,000 件の操作のうち 9,280 件がサンドボックス内にとどまっています⁹¹⁰。

5. 例外だけを報告させる。 誰も読まなかった更新通知が返金につながり、その後は期限前に早めに知らせ、普段は例外だけを報告する形に変わりました²¹。お金が絡むフローなら、最初のステップは「読み取り、フラグを立て、人の承認に向けて準備する」だけにとどめられます²⁴。

共通認識

承認ボタンそのものは統制ではありません。人が内容を理解する時間もなく、取り消すこともできないなら、ボタンはただの飾りです¹³。
承認依頼には、何を変えたか、何を確認したか、何が確認できなかったかを明記すべきです。そうでなければ、ただの形だけの承認になります²²。
常時の権限には期限を設け、取り消せるようにし、記録も残すべきです²⁰。

意見が分かれる点

人はループに残るべきか？ 段階ごとの承認そのものがボトルネックであり、Agent を使う目的に反します¹⁴。一方、自動運転にたとえると、普段は完全に自動なのに、肝心な場面で突然人に操作が戻されても、人はうまく引き継げません¹⁴。
自動レビューは監督と言えるか？ 減るのは低リスクな割り込みです¹⁰。しかし、同じモデルが同じ文脈で自分をレビューしても、独立したチェックにはなりません¹³。
問題は承認の多さか、作業の細切れか？ これほど多い承認は、インターフェースの問題ではなく、作業を細かく切りすぎた結果とも捉えられます。先に全体を計画し、確認を一度にまとめれば、疲れることはありません⁸³⁰。
権限は項目ごとに与えるべきか？ 別のやり方として、権限の判断を Agent の外に置き、プロンプトによる制約に頼らず、独立したポリシー層に任せる方法もあります¹¹。

どうすればいいか

毎月決まった日に、下の監査プロンプトを実行します。Agent が過去の仕事を覚えていない場合は、先月の会話ログや ToDo リストも一緒に貼り付けます。
対応するのは上位 5 項目だけ。1 回に変えるのは 1 項目にし、2 週間様子を見てから次に進みます。
まずは「毎回同じ答えを出している」承認から手をつけ、期限付きの常時の権限に切り替えます。
支払い、メール送信、削除、公開投稿は、すべて自分の手に残します。
翌月は、新しい監査を実行する前に、前回与えた権限を取り消すべきかどうかを確認します。

汎用プロンプト

過去の作業記録を読める Agent なら、どれにでも使えます：

人への依存度監査 · 25 行

人への依存度監査
過去〔30〕日間の私たちの協働を振り返ってください。情報源：〔あなたが覚えている仕事／私が添付した会話ログやタスクリスト〕。
実際にある記録だけに基づいてください。はっきり覚えていない部分はそう書き、推測はしないでください。

止まった、遅くなった、または私を待たないと先に進めなかった箇所をすべて洗い出してください。特に次の点です：
1. 私が言わなくてもあなたが始められた仕事
2. あなたが何度も私の決定を待った判断
3. あなたが何度も私に求めた、本来は保存しておけた情報
4. 私が毎回同じ答えを出している承認
5. 私が手作業でツールや Agent の間を受け渡している仕事
6. 定時実行や自動トリガーに変えられる繰り返しのチェック
7. 私が手作業で配っている、あなたが直接届けられる成果物
8. 私が全件確認しているが、例外だけ見れば足りる仕事

各項目について次を書いてください：
- 分類：私の判断に残す／あなたに教える／固定情報として保存する／自動化する／例外のみ報告
- 根拠：具体的な仕事や記録を挙げる
- 待ち時間：私を待って止まった時間の目安と頻度（記録がある場合のみ。推定はしない）
- 変更案：あなたに常時の権限を与える場合は、範囲、期限、〔30〕日後の見直しを明記する
- リスク：変更後に起こりうる問題と、元に戻せるかどうか

ルール：
- まだ何も変更しないでください。影響の大きいものから順に挙げ、その後 1 項目ずつ話し合います。
- 支払い、メール送信、削除、私の名前での公開投稿は、すべて「私の判断に残す」に分類してください。
- 今後私に承認を求めるときは、何をするのか、何を変えたのか、何を確認したのか、何が確認できなかったのかを書いてください。

〔〕内をあなたの状況に置き換えてください

@Michael_Fenech_ のやり方を参考に整理

ツールによる違い

記憶：会話をまたいで仕事を覚えている Agent（たとえば Grok Bot の記憶は好み、役割の背景、要約を Bot ごとに別々に保存します²⁷）なら、そのまま振り返れます。記憶を持たないツールでは、記録を自分で添付します。
承認の仕組み：Claude Code のサブエージェントは権限モードを設定できます²⁵。Grok Bot が自分のメールボックスからメールを送るときは 1 通ごとに承認が必要で、ルーティンやほかの Bot から出た承認依頼はしばらくすると失効します²⁶²⁸。OpenAI の Auto-review では、2 つ目の Agent が先にレビューします⁹。常時の権限に切り替える前に、使っているツールで権限をどこまで細かく設定できるか確認しましょう。
スケジュール実行：定時実行できるツール（たとえば Grok Bot の Routines。実行のたびに使用量を消費します²⁹）なら、監査を毎月 1 回に設定できます。できないツールなら、カレンダーにリマインダーを入れ、手動でプロンプトを貼り付けます。

参考情報

@mihai673：「次は？」60 回、そのまま OK が 32 回、未決事項 41 件 ↩ a b
@StanleyWei4748：ボトルネックは人間の注意力 ↩
Jason M. Lemkin（LinkedIn）：Agent が 3 体から 22 体に、1 日の管理時間は 8 時間に ↩
Ashish Gupta（LinkedIn）：認証コードが届かず Agent が一時停止 ↩
Kelly Waters（LinkedIn）：アウトプットは速くなったが、待ち時間は減らない ↩
@rohanpaul_ai：論文「AI Agents Push Humans Out of the Loop」の要約 ↩
@mmitchell_ai：論文で整理された 6 つの監督戦略 ↩
@anishmoonka：1 回のセッションで 47 回の「許可」 ↩ a b
@thsottiaux：Auto-review の無料公開、10,000 件の操作の分布グラフ ↩ a b
@aakashgupta：guardian サブエージェントによるコマンドのレビュー ↩ a b
r/AI_Agents：権限の判断は Agent とワークフローのコードの外に置く ↩
@vicky_grok：サンドボックスと認証情報の分離。コメントで正当な権限のリスクを指摘 ↩
Junaid Ahmed（LinkedIn）：人を残すべき 5 種類の仕事。同じモデル同士のレビューは独立ではない ↩ a b c
Adrian Sanabria（LinkedIn）：人がループにいることがボトルネックではないかという問題提起。コメントの自動運転のたとえ ↩ a b
mindforge.iq（TikTok）：低リスクで元に戻せるものは自動化、影響の大きいものは人に残す ↩
@Michael_Fenech_：人への依存度監査の元のプロンプト ↩
@Kevin_Logan：15 項目を発見、13 項目を適用 ↩
@DisruptConcept：15 項目を発見して 12 項目を実施、30 日ごとの実行に変更 ↩
@OpsDaddyAI：繰り返しの承認を常時の権限に切り替え ↩
@YoKoSuKa929：常時の権限には期限を設け、取り消し可能に ↩
@DanielMed_2：更新通知の見落としを機に例外のみ報告へ ↩
@brandononchain：承認依頼には確認内容を添える ↩
How I AI（YouTube）：リスクで PR を採点し、低リスクは自動承認（11:36 からフロー、15:47 から 6 項目のリスク採点） ↩
r/AI_Agents：お金が絡むフローは、まず読み取り・フラグ付け・人の承認待ち ↩
Claude Code 公式ドキュメント：Subagents ↩
Grok Bot 公式ヘルプ：FAQs ↩
Grok Bot 公式ドキュメント ↩
Grok Bot 公式ヘルプ：Agent email ↩
Grok Bot 公式ヘルプ：Routines ↩
@madebyoliver の返信：47 回の承認は作業を細かく切りすぎた問題 ↩