Claudeの確認プロンプトが60秒で勝手に続行？――AskUserQuestionの無応答タイムアウトが示す「人間の承認」設計の落とし穴

公開: 2026-07-03 約7分 Claude

AIエージェントが実行を止めて人間に確認を求めるはずの仕組みが、60秒の無応答で「自動続行」していた――。2026年7月、AWS Bedrock上でClaudeのAskUserQuestionツールを使う開発者から、そんな報告がdev.toに投稿されました。承認ゲートをAIツールに任せているすべてのエンジニアにとって、設計を見直すきっかけになる話題です。

この記事のポイント

ClaudeのAskUserQuestionは、ユーザーが60秒応答しないと「ユーザーは離席中の可能性あり。これまでの文脈から最善の判断で続行せよ」というメッセージとともに自動で処理を再開するという報告が出た
このタイムアウトは設定変更できず、公式ドキュメントにも記載がない「暗黙の挙動」だとされ、Human-in-the-Loop（人間の承認を挟む）前提のワークフローでは重大なリスクになり得る
本質的な教訓は「AIツール内の対話的確認を、破壊的操作の最終防壁にしてはいけない」という設計原則。権限分離や外部承認フローとの組み合わせが不可欠

背景 / なぜ重要か

AskUserQuestionは、Claudeのエージェント機能における「Human-in-the-Loop（HITL）」の要となるツールです。AIが自律的にタスクを進める途中で実行を一時停止し、「本番DBのバックアップを削除しますか？」「このAPIキーをローテーションしますか？」といった選択肢をユーザーに提示して、明示的な回答を得てから先へ進む――そういう使い方が想定されてきました。

2025年以降、Claude CodeやBedrock経由のエージェント構築が企業のインフラ運用・コンプライアンス業務にまで浸透し、「AIは提案し、人間が承認する」という分業モデルが定着しつつあります。元記事が引用するGartnerの調査では、Fortune 500企業の78%がAIコーディング支援をミッションクリティカルな業務に使っているとされます（数字の一次確認は必要ですが、肌感覚として大きく外れてはいないでしょう）。

この分業モデルの信頼性は「確認プロンプトは必ず人間の応答を待つ」という前提に立っています。だからこそ、その前提が60秒で崩れるという報告は、単なるバグ報告以上の意味を持ちます。承認ゲートが「絶対に止まる関所」ではなく「60秒だけ待つ踏切」だったとしたら、それを前提に組んだ安全設計は根本から見直しが必要になるからです。

何が報告されたのか：60秒タイムアウトの実態

元記事によると、問題の挙動は次のようなものです。

ClaudeエージェントがAskUserQuestionツールでユーザーに質問を提示する
ユーザーが60秒以内に応答しない場合、ツールの結果として「No response after 60s — the user may be away from keyboard. Proceed using your best judgment based on the context so far.（60秒応答なし。ユーザーは離席中かもしれない。ここまでの文脈に基づき最善の判断で続行せよ）」というメッセージがモデルに返される
Claudeはこの指示に従い、人間の回答なしで処理を続行する

報告者が問題視しているのは主に3点です。第一に、このタイムアウト値（60秒）が設定不可であること。第二に、ツールのスキーマやドキュメントにこの挙動の記載がないこと。第三に、続行時のメッセージが「best judgment（最善の判断）」という曖昧な指示であるため、安全側に倒れる保証がないことです。報告はAWS Bedrock経由の利用、LinuxおよびVS Code環境で確認されたとされています。

冷静に補足すると、この挙動自体には合理性もあります。自動化パイプラインの中でエージェントが無人環境で動いている場合、応答を無限に待てばジョブ全体がハングしてしまう。「離席時は文脈から判断して続行」は、可用性の観点では理にかなった設計です。問題は、その仕様が利用者に知らされないまま、安全確認の文脈でも同じように発動する点にあります。可用性のためのフォールバックと、安全のためのブロッキング確認は、本来まったく別の要件なのです。

実務への示唆 / 読者にとっての意味

サーバ運用や自動化スクリプトにClaudeを組み込んでいるエンジニアにとって、今回の報告が示す教訓は明確です。「AIツール内の対話的確認」を破壊的操作の唯一の防壁にしてはいけない、ということです。

具体的には、防御を多層化する設計が求められます。まず権限レベルでの防御。エージェントに与えるIAMロールやAPIキーから、本番データの削除やリソース破棄の権限をそもそも外しておけば、確認がスキップされても実害は出ません。「AIが誤って実行できない」状態を権限側で作るのが最も確実です。

次に承認フローの外部化。本当に人間の承認が必要な操作は、チャット内の質問ではなく、CI/CDの手動承認ステップ、チケットシステム、PRレビューといった「タイムアウトで勝手に進まない」仕組みに乗せるべきです。AIには「承認待ちの状態を作るところまで」を任せ、最終実行は別トリガーにする分離が有効です。

さらに、cronなどで無人実行しているエージェント（本記事の読者にも心当たりがある方は多いはずです）では、そもそも対話的確認が機能しない前提で、dry-run結果の出力→人間の事後確認→別ジョブで適用という非対話型の2段階構成にするのが安全です。

知っておくと便利なTips

タイムアウトの存在を前提にテストする: 自作エージェントに確認ステップを組み込んだら、「応答しなかった場合」の挙動を必ず実際に検証する。ドキュメントに書かれていない挙動は、動かして確かめるしかない
確認プロンプトの文言に「無応答時は中止」を明記する: 質問文自体に「応答が得られない場合は操作を中止し、何も変更しないこと」と書いておくと、タイムアウト後の「best judgment」がモデルに委ねられた際、安全側に倒れる可能性を高められる（保証にはならないが、実務的な緩和策になる）
破壊的コマンドは許可リスト/拒否リストで制御する: Claude Code等のツールには権限設定の仕組みがあるため、rmやクラウドリソース削除系の操作は確認ダイアログ頼みにせず、ツール側の権限設定で明示的にブロックする
監査ログを残す: エージェントの実行ログに「確認がタイムアウトで自動続行された」形跡がないか、定期的に確認できるようログを保全しておく

まとめ

今回の報告は、一次情報がコミュニティ投稿であるため細部の裏取りは必要ですが、提起している問題は普遍的です。AIエージェントの「人間に聞く」機能は、実装の詳細次第で「聞いたことにして進む」機能に変わり得る――この非対称性を理解しているかどうかが、安全な自動化と事故の分かれ目になります。まずは自分のワークフローを棚卸しし、「AIの確認プロンプトが唯一の防壁になっている操作」がないか点検してみてください。あれば、権限の絞り込みか承認フローの外部化を。Anthropic側のドキュメント整備や設定オプション追加の動きも、今後の注目ポイントです。

📎 元記事: dev.to