AI agent に複雑な設計を委譲していると、ときどきこういう返事が混ざります。
このタスクは、〇〇 の稼働状況が未確認のまま含めるのはリスクです。Phase 分離か、別 Issue 化を検討してください。
これを 「ちょっと不安そうだけど、まあやれそうって言ってるから進めて」 と読み飛ばすと、後で必ずハマります。本記事は、Agent の「ためらい」を decision gate（判断分岐点）として扱う運用ルールの記録です。
AI 駆動開発で最も実用的なシグナルハンドリングは、Agent の不安サインを 沈黙させずに即座に外部化 することです。
事の発端：Plan agent が “判断留保” を出してきた
Claude Code の Plan agent に、複数 Issue を統合した実装プランを依頼しました。Agent は5つの Issue を分析し、依存関係を整理し、Phase 分けまで提案してきました。
ところが、最後のセクションに こんな一文 が混ざっていました。
1注意: Phase 3 に含めている fx_staleness_analysis の2稼働状況が未確認のまま含むのはリスクです。3Phase 分離か別 Issue 化を検討してください。これを最初は「あー、リマインダーね」と流しそうになりました。プランの本文はしっかり書かれていて、Phase 構造も合理的に見えたからです。
しかし、「リスク」という言葉を agent が自発的に使うのは、人間が同じ立場で言うのとは意味が違うことを思い出しました。
なぜ Agent の「リスク」発言は重いのか
AI agent は通常、結論を出すように訓練されています。質問されたら答える、依頼されたら作る。「やれません」「判断できません」と返すのは、コスト関数的に不利なはずです。
それでも Agent が「リスクです」「未確認です」「判断を留保します」と言ってくるとき、それは以下のどれかが起きています。
1. 構造的に情報が欠けている
Agent が情報を取りに行ったが、該当データが取れなかった。例: ジョブの稼働状況を確認しようとしたが、ログが見つからなかった。
2. 矛盾するエビデンスを掴んだ
複数のソースを参照したら、互いに食い違う情報が出てきた。例: README と実装が違う、コメントとコードが矛盾している。
3. 一般則と個別事情の乖離
Agent が知っている一般パターンと、目の前のコードベース固有の状況が乖離していることを察知した。
どのケースも、人間が 「だいたいOK」で押し切ると地雷を踏む性質を持っています。Agent はその地雷の存在を感じ取っているけれど、踏むかどうかの最終判断はできない。だから「リスクです、検討してください」という形で投げ返してきます。
沈黙させない：Agent の不安を decision point に変換する
このサインを無視しない運用ルールは、シンプルです。
Agent が「リスク」「未確認」「判断を留保」「Phase 分離を検討」のいずれかを口にしたら、そのセッション内で押し切らない。即座に Issue / Decision Log に外部化する。
「外部化」というのが重要で、これには3つの段階があります。
Step 1: Agent の発言をそのまま引用してログに残す
要約せず、Agent が使った原文をコピーします。要約すると「ちょっと不安らしい」程度に薄まってしまい、後で読み返したとき重みが消えます。
1## Decision Log: 2026-05-17 Phase 3 設計2
3### Plan agent からの判断留保4
5> Phase 3 に含めている fx_staleness_analysis の稼働状況が未確認のまま6> 含むのはリスクです。Phase 分離か別 Issue 化を検討してください。7
8### 検討事項9- 稼働状況の確認方法は何があるか10- Phase 分離した場合のスケジュール影響11- 別 Issue 化の判断基準Step 2: その場で決めようとしない
ありがちな失敗は、「じゃあ、その点も気をつけてやりますね」と返してプランをそのまま実行に移してしまうこと。Agent は判断留保したのに、人間が勝手に「気をつける」で押し切る。これは典型的な事故パターンです。
代わりに、「判断を後回しにする」と明示的に決めます。
Step 3: 判断トリガーを Issue 化する
「いつ判断するか」を Issue にします。例:
1Issue: Phase 3 の fx_staleness_analysis 含有判定2
3判断条件:4- [ ] 稼働状況を実環境で確認（直近 7 日のジョブログ）5- [ ] 失敗時の影響範囲を見積もる6- [ ] 含めない場合のスケジュール遅延を計算7
8期限: Phase 2 完了時点までこれで、Agent の「ためらい」が忘れられない形で残るようになります。
「いずれ気づくだろう」が一番危険
このルールを作る前、私は何度か 「進めていけば途中で気づくでしょ」モードで押し切って、その後ハマりました。具体的には:
- Phase 3 に組み込んだまま実装 → 想定外の依存が出てきて手戻り
- 「気をつけてやる」と言ったが、別の作業に集中している間に 危険箇所を忘れる
- ハマってからログを読み返すと、Agent が事前に警告していたことに気づく（しかし手遅れ）
最後のパターンが最も悔しいです。Agent はちゃんと教えてくれていたのに、自分が無視した。
CLAUDE.md に組み込む
このルールは個人の意識だけだと崩れるので、CLAUDE.md に運用ルールとして書きました。
1## Agent の判断留保ハンドリング2
3Agent（Plan / Explore / その他 subagent）が以下の表現を使った場合、4そのセッションで実行に移さず、必ず Decision Log に外部化する:5
6- 「リスクです」「リスクがあります」7- 「未確認」「未検証」8- 「判断を留保します」「判断材料が不足しています」9- 「Phase 分離を検討してください」「別 Issue 化を検討してください」10
11外部化フォーマット:121. Agent の発言を原文引用132. 検討事項を箇条書き143. 判断トリガー（いつ・何を確認したら判断するか）を Issue 化これを書いておくと、Claude Code 自身が 「先ほどの発言は判断留保に該当します。Decision Log に追加しますか?」 と聞いてくるようになります。
副次効果：Agent の質が上がる
このルールを運用していると、もう一つ副次効果が出てきました。Agent が判断留保しやすくなるのです。
理由は、ユーザー（私）が判断留保を歓迎する姿勢を見せるので、Agent も「無理に結論を出さなくていい」と学習する。結果として、
- 「全部やりました」より「ここは判断材料が足りません」と返してくる頻度が上がる
- 押し切られた末の事故が減る
- Agent との協働品質が上がる
逆に、判断留保を無視して押し切っていると、Agent もそれに合わせて「無理にでも結論を出す」モードになり、ハルシネーションが増えます。
適用シーンの判別：すべての agent 発言に適用するわけではない
このルールは 「判断留保系の発言」だけ に適用します。Agent が「やります」「できます」「完了しました」と言っている場合は通常通り進めて構いません。
判別の鍵は、「Agent が結論を保留している兆候があるか」 です。
| 発言例 | decision gate? |
|---|---|
| 「実装しました。動作確認済みです」 | ❌ 通常進行 |
| 「これで完了です」 | ❌ 通常進行 |
| 「リスクがあります」 | ✅ 外部化 |
| 「判断材料が不足しています」 | ✅ 外部化 |
| 「〜は未確認のままです」 | ✅ 外部化 |
| 「Phase 分離を検討してください」 | ✅ 外部化 |
| 「これでよろしいでしょうか?」 | △ 文脈次第（軽い確認なら通常） |
判別に迷ったら 「Agent は答えを返したか、それとも投げ返してきたか」 を見ます。投げ返してきていたら decision gate です。
まとめ：AI 協働の最も実用的なシグナル
AI agent は「やります」モードがデフォルトです。だからこそ、「やれません」「リスクです」と言ってくる瞬間は最高度に貴重なシグナルです。
これを「気をつけてやる」「いずれ気づく」で押し切ると、後で必ず手戻ります。代わりに、
- そのセッションで実行に移さない
- Agent の発言を原文で Decision Log に残す
- 判断トリガー（いつ何を確認するか）を Issue 化する
この3ステップで、Agent のためらいが忘れられない判断分岐点に変換されます。
AI と協働するうえで最もコスパが良いのは、「自分が見落としていることを Agent が代わりに気づいてくれる瞬間」を逃さないことです。そのためには、Agent の不安サインを沈黙させない運用が要ります。
Agent の「リスクです」は、「お前は今、地雷の上に立っているぞ」というシグナルです。ありがたく受け取って、その場で踏まずに済むようにしましょう。