AI活用が進むほど、なぜか人間が疲れる。
その原因は、AIそのものよりも、AIによって増えた情報量・変更量・確認量を、人間がそのまま受け止めていることにあるのかもしれません。
この記事では、AI Agentを業務や開発で使うときに、
「記録は詳しく残す。でも人間への報告は短くする」
という運用の考え方を整理します。
AIで増えたのは「作業速度」だけではない
AIを使うと、文章、調査結果、コード、PR、設計案などを短時間で大量に作れます。
一方で、人間側の読む速度や判断速度はそれほど変わりません。
そのため、次のようなことが起きます。
- 報告や情報伝達の密度が上がり、読む側が追いつかない
- AIが丁寧に説明しすぎて、報告そのものが長くなる
- Agentが大量に変更を作り、人間のレビュー量だけ増える
- 「AIが作ったものが本当に正しいか」を確認する仕事が増える
- 重要な判断と、機械的に処理できる確認が混ざる
Microsoft Researchの調査でも、生成AIを使うことで人間の仕事が完全に消えるのではなく、
情報の検証、回答の統合、AI作業の監督へ重心が移ることが報告されています。
GitHubも2026年に、Agent生成PRのレビューについて、見た目がきれいでテストが通っていても、冗長性や技術的負債が入り込む可能性があるため、意図的なレビュー設計が必要だと説明しています。
つまり、
AIで「作る量」は増やせても、人間の「判断量」まで無限に増やせるわけではない
ということです。
「証跡」と「報告」を分ける
ここで重要なのが、トレーサビリティと報告量を同じものとして扱わないことです。
AIが何をしたかを後から確認できることは重要です。
ただし、その情報を毎回すべて人間に読ませる必要はありません。
裏側では詳しく残す
例えば次のようなものです。
- 実行ログ
- 変更差分
- テスト結果
- セキュリティチェック結果
- 参照した仕様やファイル
- AIが利用したツール
- 実行日時
- Run ID
- PR / Issue / Ticket
- 重要な設計判断のADR
NISTのガイダンスでも、監査に必要なイベントを定義し、必要な監査記録を生成・保持・保護することが重視されています。
表側では短く報告する
人間向けには、例えば次の程度で十分です。
【結果】
成功
【変更】
3ファイル変更
【品質チェック】
Test: PASS
Lint: PASS
Security: PASS
Spec: PASS
【人間確認】
不要
【注意事項】
なし
【証跡】
PR #123 / Run ID abc-001
通常時はこれだけ読む。
何か気になったときだけ、PR、ログ、ADR、テスト結果などを掘ればよいわけです。
重要なのは、
Traceability ≠ Verbosity
という考え方です。
記録が詳しいことと、報告が長いことは別です。
ADRも「全部残す」のではなく境界を決める
ADR（Architecture Decision Record）は、重要な設計判断とその理由を残すための方法です。
ADRの考え方では、単なる作業履歴ではなく、後から見たときに「なぜこの判断をしたのか」が重要になる決定を記録します。
例えば、
- アーキテクチャ変更
- 技術選定
- DB設計方針
- セキュリティ方針
- 外部インターフェース変更
- 後戻りコストが高い判断
などです。
逆に、
- 単純な文言修正
- 小さなバグ修正
- 自明なリファクタリング
までADR化すると、今度はADRそのものがノイズになります。
「何を残すか」の境界を先に決めることが重要です。
AIと人間の「アラート境界線」を決める
もう一つ大事なのが、どこまでAIに任せ、どこから人間を呼ぶかです。
例えば開発なら、次のように決められます。
| 状態 | AI | 人間 |
|---|---|---|
| Test / Lint / Security 全PASS | 続行 | 原則不要 |
| 軽微な警告 | 記録して続行 | 原則不要 |
| 仕様との不一致 | 停止 | 確認 |
| Security High | 停止 | 必須確認 |
| DB破壊的変更 | 停止 | 必須確認 |
| 外部API仕様変更 | 停止 | 必須確認 |
| 同じ処理を複数回失敗 | 停止 | 確認 |
Google SREの監視設計でも、アラートは「人が行動できるもの」であるべきで、機械的な対応で済むなら自動化を検討すべきだという考え方が示されています。
これはAI Agent運用でもそのまま使えます。
Human-in-the-loopからHuman-on-the-exceptionへ
AIの各工程を毎回人間が確認すると、自動化の意味が薄れます。
AIが作業
↓
人間が確認
↓
AIが作業
↓
人間が確認
この形では、人間がボトルネックになります。
そこで、
要求
↓
AI Agent
↓
Test / Lint / Security / Spec Check
↓
基準内なら自動続行
↓
完了
└─ 閾値を超えた場合だけ → 人間
という形にします。
人間が常にループの中にいるのではなく、
例外時だけ人間が入る形です。
これをここでは「Human-on-the-exception」と呼びます。
「信号機＋定型フォーマット」で十分
AIだからといって、人間向けUIまで複雑にする必要はありません。
例えば、
- GREEN：自動処理可能
- YELLOW：注意。記録して続行
- RED：人間の判断が必要
くらいでも十分です。
人間は昔から、定型帳票、チェックリスト、信号機、例外報告に慣れています。
AI時代でも、この分かりやすさは強いです。
まとめ
AI Agent時代に重要なのは、AIに詳しい説明を書かせることではありません。
大事なのは、
裏側では詳細に記録し、表側では短く報告する
ことです。
整理すると、次のようになります。
- ログや差分は機械的に残す
- 重要な判断だけADRとして残す
- 人間向け報告は定型フォーマットにする
- AIと人間のアラート境界線を決める
- Test / Lint / Security / Spec Checkなどを自動化する
- 人間は例外と重要判断に集中する
AIが増えるほど、人間が全部を見る運用は続きません。
必要なのは「AIを減らすこと」ではなく、
人間が見るべき情報を減らす運用設計なのだと思います。
参考
-
Microsoft Research, The Impact of Generative AI on Critical Thinking
https://www.microsoft.com/en-us/research/publication/the-impact-of-generative-ai-on-critical-thinking-self-reported-reductions-in-cognitive-effort-and-confidence-effects-from-a-survey-of-knowledge-workers/ -
GitHub Blog, Agent pull requests are everywhere. Here's how to review them.
https://github.blog/ai-and-ml/generative-ai/agent-pull-requests-are-everywhere-heres-how-to-review-them/ -
Architectural Decision Records
https://adr.github.io/ -
MADR - Markdown Architectural Decision Records
https://adr.github.io/madr/ -
Google SRE, Monitoring Distributed Systems
https://sre.google/sre-book/monitoring-distributed-systems/ -
NIST SP 800-92, Guide to Computer Security Log Management
https://csrc.nist.gov/pubs/sp/800/92/final -
NIST SP 800-171 Rev.3, Audit and Accountability
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/800-171r3/NIST.SP.800-171r3.html