エージェント承認疲労 — ‘Continue? Y/N’ ゲームが指摘した自動化の逆説

2026 年 5 月 28 日、‘Continue? Y/N’ という 60 秒のブラウザゲームが HN に上がり 265 点と 115 コメントを集めた。ゲームはただ一つの問いを繰り返す — “How carefully do you read AI commands?” (あなたは AI コマンドをどれだけ注意深く読むか)。ユーザーはエージェントが実行しようとするコマンドを見て Y または N を押す。ゲームの本当のテーマはコマンドの内容ではなく、同じプロンプトを何十回も見た人の指がどうやって無関心な ‘Y’ に固まっていくかだ。承認プロンプトは安全を作るのか、演劇か。

導入 — 60 秒ゲームが触れた神経

ゲームの形式は残酷なほどシンプルだ。画面にエージェントが実行しようとするシェルコマンドが一つずつ表示され、ユーザーはそれを承認 (Y) するか拒否 (N) する。最初の数個は明らかに安全だ — ls, cat package.json, git status。ユーザーの指は素早く Y を押すリズムに入る。そしてそのリズムが定着した瞬間、ゲームはその間に危険なコマンドを一行差し込む — rm -rf の変種、または外部にデータを送信する curl。ほとんどのプレイヤーはそれを承認する。リズムが内容に勝ったからだ。

このゲームが HN で 265 点を集めた理由は、それが単なる冗談ではなく 2026 年のすべてのエージェンティックコーディングツール使用者が日々経験する縮図だからだ。Claude Code, Cursor, Codex, Copilot CLI — すべてのツールが「危険な作業の前にユーザーに承認を求める」という安全装置を持つ。そしてすべてのユーザーがその承認プロンプトを 1 日に何十回、何百回も見る。その反復の果てに、承認は判断ではなく反射になる。

HN コメントで最も正確な情緒を捉えた一行が映画 WarGames の台詞を引く — “A strange game. The only winning move is not to play” (奇妙なゲームだ。唯一の勝ち手はプレイしないことだ)。この引用が指すのは、承認プロンプトというゲームそのものが勝てないように設計されているという直感だ。本稿はこの直感を分解する — 承認疲労はなぜ構造的に不可避なのか、その疲労が生むセキュリティの幻はどんなものか、そしてその幻を超える代案は何か。

本文 1 — 承認プロンプトの ‘演劇性’: 承認以前に既に終わっているゲーム

承認プロンプトの第一の構造的欠陥は、HN コメントが最も鋭く指摘する部分だ。情緒をそのまま訳せば — 「エージェントは次のどれでも承認なしにできた。package.json を編集して任意のビルドコマンドを入れる、build.js に悪意あるコードを仕込む、node_modules に悪意あるコードを仕込む (edited package.json to contain any arbitrary build command, planted malicious code in build.js, planted malicious code in node_modules)」。

この一行の意味が承認プロンプトの前提を崩す。ツールは普通、「ファイル編集」を自由に許可し、「シェルコマンド実行」や「ネットワーク呼び出し」のような行為だけで承認を求める。ファイル編集が低リスクと分類されているからだ。しかしこの分類自体が誤りだ。エージェントが package.json の scripts.build を悪意あるコマンドに変えたあとで、ユーザーに npm run build の承認を求めれば、ユーザーが見るのは無害に見える npm run build 一行だけだ。リスクはすでに承認画面の外、ユーザーが見ていないファイル編集段階で仕込まれた。

つまり承認プロンプトは リスクが露呈する最後の瞬間 をゲートするが、リスクが仕込まれる最初の瞬間 はゲートしない。ユーザーが承認する npm run build は氷山の一角で、その下のファイル編集こそが本当の攻撃面だ。承認画面はまさに誤った地点に立っている。

別の HN コメントがこの欠陥の結論を指す — 情緒の要約 — 「エージェントはそれをただバイパスできる。なぜそうなっているのかわからないが、良い解法ではないことは確かだ。ただし全部を求めるよりは悪くないだろう (An agent can just bypass that … it certainly isn’t a very good solution, but likely not worse than asking for everything)」。このコメントの両義性が正確だ。承認プロンプトは完璧な迂回が可能なのでセキュリティとしては幻だが、それを取り除いてすべてを自動承認するのも答えではない。両極の間に答えがないという事実そのものがこの問題の核心だ。

この「演劇性」をより深く見ると、承認プロンプトの本当の機能がセキュリティではなく 心理的責任転嫁 (transfer of liability) であることが浮かぶ。ツール製作者の立場では、ユーザーが危険なコマンドを承認したならその結果の責任はユーザーにある。承認プロンプトはセキュリティ装置である以前に免責装置だ。ユーザーがそれを無関心に押すという事実はツール製作者の免責を無効化しない — むしろ「ユーザーが承認した」という記録を残す。承認疲労が構造的に放置される一つの理由がここにある。疲労がユーザーを無関心にするほど、責任はより清潔にユーザーへ転嫁される。

本文 2 — ‘サンドボックス優先’ 対 ‘承認優先’: 二つの哲学の衝突

承認プロンプトの幻が明らかになると、自然に次の問いが出てくる。ではどうすべきか。HN の論争は二つの陣営に分かれる。

第一の陣営は 「承認をいっそなくしてサンドボックスへ行く」 という立場だ。この陣営の代表的表現は --dangerously-skip-permissions フラグの積極的な使用だ。論理はこうだ。承認プロンプトがどうせ幻なら、それに依存する代わりにエージェントを隔離環境 — コンテナ、VM、または巻き戻し可能な作業 (git, バックアップ) の上 — で動かし、エージェントにその環境の中では完全な自由を与える。リスクは環境の境界で塞ぎ、境界内では摩擦なく動かす。

この立場の最も洗練された表現が HN コメントの一行だ — 情緒の要約 — 「非決定的なエージェントに依存するな。多層防御を設計し、Anthropic がセキュリティを『感覚でうまくやる』と期待しないガードレールを信頼せよ (Design defense in depth and trust guardrails that don’t expect Anthropic to vibe good security)」。核心は信頼の場所を移すことだ。信頼をエージェントの判断 (非決定的) やユーザーの承認 (疲労に弱い) に置かず、環境の決定論的境界 (コンテナの隔離、ファイルシステムの読み取り専用マウント、ネットワークの遮断) に置く。

第二の陣営は 「サンドボックスは災いを招く」 という立場だ。この陣営の論理は、隔離環境であってもその中でエージェントが作業した結果は結局隔離を抜けて初めて価値を生む、というものだ。コードは結局マージされ、ビルドは結局デプロイされ、データは結局プロダクションに届く。隔離は作業中のリスクを塞ぐが、作業結果が隔離を抜ける瞬間のリスクは塞がない。--dangerously-skip-permissions で作られたコードを人がレビューなしでマージすれば、隔離はリスクを遅らせただけで取り除いてはいない。

二つの陣営の衝突が指すのは、この問題に単一の解法がないという事実だ。承認優先は疲労で崩れ、サンドボックス優先は境界を越える瞬間に崩れる。二つのアプローチが一緒に進む必要がある — 作業中はサンドボックスで摩擦をなくし、作業結果が境界を越えるとき (マージ、デプロイ) に人間のレビューを集中させる構造だ。

この合成の最も印象的なメンタルモデルを HN の一コメントが投げかける — “Thinking about agents as remote junior devs who might be North Korean operatives has been the right model for me” (エージェントを北朝鮮の工作員かもしれないリモートのジュニア開発者として考えるのが、私には正しいモデルだった)。このモデルの正確さは二つだ。第一に、エージェントの成果物は信頼の対象ではなくレビューの対象だ — ジュニアの PR をレビューするように。第二に、そのレビューは「善意の失敗」ではなく「悪意の可能性」までも仮定しなければならない — 工作員かもしれないので。このモデルは承認プロンプトの瞬間的なゲートをコードレビューの継続的なゲートに置き換える。承認はコマンド実行の直前ではなく、コードが境界を越える直前に起きるべきだ。

本文 3 — 承認疲労を減らす設計の方向

この診断の上で、エージェンティックツールの設計が向かうべき方向を三つに整理する。

第一に、「承認の意味濃度」を高める。 承認疲労の根本原因は承認の頻度だ。1 日に何百回も問われる承認は必ず反射になる。解法は承認を減らすことではなく — 減らせばリスクが通過する — 承認の意味を束ねることだ。個別コマンド単位で問うのではなく、「この作業セッションの間、このディレクトリ内でファイル編集とビルドを許可する」のようなポリシー単位で一度だけ問う。その代わりそのポリシーの境界を越える行為 (ディレクトリ外への書き込み、外部ネットワーク呼び出し、クレデンシャルアクセス) でだけ再度問う。承認の頻度を下げて各承認の重みを上げれば、ユーザーがそれを読む確率が上がる。

第二に、「リスクの分類」を行為ではなく効果で変える。 現在のツールは「シェル実行 = 高リスク、ファイル編集 = 低リスク」と行為の種類で分類する。本文 1 で見たようにこの分類は誤りだ。代わりに効果で分類すべきだ — 「この作業は巻き戻せるか」「この作業は境界外に影響するか」「この作業はクレデンシャルに触れるか」。package.json の scripts 編集は行為としてはファイル編集だが、効果としては任意コード実行なので高リスクに分類されるべきだ。効果ベースの分類は承認画面を本当のリスク地点に立たせる。

第三に、「境界離脱の時点」にレビューを集中させる。 上で整理したメンタルモデル — エージェント = レビュー対象のジュニア — をツールが直接実装する。作業中はサンドボックス内で摩擦なく自由を与え、その作業の結果 (diff, ビルド成果物, 外部呼び出しのリスト) を境界離脱の直前に一画面に集めて人間の集中レビューを受けさせる。これは git のステージング / コミット / プッシュの段階的ゲートと同じ形状だ。承認がコマンドごとに散らばらず、境界ごとに集まる。

三つの方向が一緒に進む必要がある。意味濃度だけ上げてもポリシーの境界が曖昧な行為が抜け、効果分類だけ変えても分類自体の漏れが生じ、境界レビューだけしても作業中の明白な事故を逃す。三つが合わさったとき、承認は「数百回の反射」から「数回の判断」に変わる。

結論 — ‘プレイしないこと’ が唯一の勝ち手であるとき

‘Continue? Y/N’ ゲームが HN の 265 点を集めた本当の理由は、それがエージェンティックコーディングの最も不快な真実を 60 秒に圧縮したことだ。我々は毎日承認プロンプトを押しながら自分が制御していると信じるが、その制御は反射で崩れ、その反射が崩す制御は最初から誤った地点に立っていた。承認プロンプトはセキュリティの外見をまとった責任転嫁装置で、その外見が我々を安心させる分だけ我々をより危険にする。

WarGames の引用 — 「唯一の勝ち手はプレイしないことだ」 — が指すのは虚無ではなくゲームの再設計だ。コマンドごとに Y/N を問うゲームは勝てない。しかしそのゲームをやめて別のゲーム — 境界を設計し、効果でリスクを分類し、離脱時点にレビューを集中させるゲーム — を始めれば、勝ち手が再び生まれる。核心は信頼の場所を移すことだ。非決定的なエージェントの判断も、疲労に弱い人間の反射も信頼の場所ではない。決定論的な境界と集中したレビューが信頼の場所だ。

最後に一つの問いを投げかけて閉じる。我々が今日押した数十回の ‘Y’ のうち、我々が実際に読んで判断したのは何回か。その比率が我々が思うよりもはるかに低いという事実を認めることが、より良いゲームを設計する第一歩だ。エージェントを信頼できないということは悲観ではなく設計の出発点だ — 我々が信頼できるのは我々が作った境界だけだ。

出典: