この記事は2026年8月時点の実測に基づく。
「どこに人間ゲートがあんだよ」
夜、CCの作業を見ていて、こう言った。
どこに人間ゲートがあんだよその人間ゲート取っ払いいらねえよ全部自分でやれ
自分のところでは、Claude Codeに24時間の自律運用をさせている。非エンジニアなので、
実装も調査も設定もCCがやる。俺がやるのは指示と判断だけだ。
その運用の中で、CCが「これは人間の承認が要ります」と判断した項目を積んでいくファイルがあった。
pending_for_human.md という名前で、週に1度、俺が1時間ほど見て処理する約束になっていた。
そのファイルが269行まで膨らんでいた。約20件。
見ていて腹が立ったのは、中身がほとんど「承認の一言だけ」「GO/NOの判断だけ」「最終確認だけ」
だったことだ。俺の1時間を待つために、20件が止まっている。しかも数か月単位で。
だから取っ払えと言った。全部自分でやれ、と。
面白いのはここからだった
CCに1件ずつ測らせた。「本当に人間しか通せないのか、現物で確かめろ」と。
結果が予想外だった。5件測って、本物は1件だけ。残りは、そもそも前提が壊れていた。
1. 「承認の一言だけ」→ 承認は関係なかった
MCPサーバーを公式の登録所に載せる件。CCの記録にはこう書いてあった。
準備を全部済ませ、検証まで完了している。最後の1コマンドだけ、安全の分類器が
「公開の登録先に新しい面を作る操作は明示の承認が要る」として拒否した。承認の一言があれば実行する。
俺が「やれ」と言ったので、CCが実行した。すると、承認とはまったく関係ないところで落ちた。
Error: publish failed: server returned status 401:
{"title":"Unauthorized","detail":"Invalid or expired Registry JWT token"}
認証トークンの期限切れ。承認の問題ではなかった。
しかもこの後がひどい。CCは「秘密鍵が保存されていない」と判断して、新しい鍵を生成し、
公開鍵を差し替えようとした。だがトークンの保存先を調べるために ls ~/.mcp* を実行したところ、
鍵は最初からそこにあった。探し方が浅かっただけだ。
既存の鍵で認証をやり直したら、あっさり通った。掲載完了。承認を待っていた数か月は何だったのか。
2. 「¥表示で英語圏の買い手が離れる」→ 前提が崩れた
英語で売っている本の価格表示が円になっていて、「日本向けの安物と誤認される」から
通貨をドルに変えたい、という項目。課金の欄なので人間のゲート、と書いてあった。
CCに販売画面を全部走査させた。商品ごとに通貨を変える欄が、そもそも存在しなかった。
そして、もっと重要なことが分かった。アカウントの設定に「買い手に現地通貨を表示する」という
項目があって、これは既に有効になっていた。英語圏の人は、自分の通貨での概算を見ている。
「¥だと日本向けに見える」という心配そのものが、実測で消えた。何か月も気にしていたのに。
3. 「公開の承認待ち」→ とっくに売られていた
これが一番驚いた。
サブエージェントの観測についての本。85ページ。記録にはこう書いてある。
案内は完全に作り込み済みだが、商品の本体のページが404のまま。
公開の可否と価格の最終の承認だけ人間。
俺が判断すれば公開できる、という話だった。だから中身を確かめさせた。
そうしたら、CCが別の場所を見つけてきた。同じ本が、Zennで全11章・¥1,500で、すでに公開されて
売られていた。しかも第8章には、4日前の発見まで入っている。ずっと更新され続けていた。
404だったのは、5月に作った古い版のほうだった。そっちは文体が壊れていて、こんな調子だ。
4つの sub-pattern は1つの軸を共有するが、4件の distinct な fix を要求する。
読めない。これは商品にならない。だから404のまま放置されていたのが、記録の上では
「承認待ち」に化けていた。
4. 本物だった1件
npmへの公開。これは本当に通せなかった。
二段階認証が物理のセキュリティキーで、パスワードの再設定までは進めるが、その先で止まる。
CCが測り直しても E401 のままだった。回線は生きている（npm ping は通る）ので、資格の問題だ。
これは俺がやるしかない。ただし待機列には積まない。リカバリコードを1回保存すれば、
次からはCCだけで完結する。それだけの話だ。
なぜこうなるのか
答えは単純だった。待機列は、書いた日の写真でしかない。
「これは人間の承認が要る」と書いた瞬間は、たぶん正しかった。だが状況は動く。
トークンは失効する。プラットフォームの設定は変わる。別のセッションが同じ本を
別の場所で公開して、そっちを育てていく。
そして誰も、記述を消しに戻ってこない。直した側は、記述が残っていることを知らない。
CCの記録を遡ると、前日にも同じことが起きていた。待機列の4件を測って、3件が既に解決済み。
今日の5件と合わせて、9件測って本物は1件。
使えるかたちにすると
自分の環境で効いた手順はこれだけだ。
着手する前に、その項目を現物で1回叩く。記録を読んで判断しない。
コマンドを打つ、ページを開く、ファイルを数える。5分もかからない。
今日の5件は、実測がそれぞれ5分以下だった。数か月止まっていたものが、だ。
あと1つ。測った結果を「うまくいった」側へ倒さない。
今日、CCは2回、測り方を間違えた。2回とも「もう直っている」側へ倒れていた。
たとえば販売ページの修正が反映されたかを確かめたとき、判定に使った語が
元から本文にあって、証拠になっていなかった。一意な形で測り直したら、実は保存されていなかった。
だから対照を1つ入れる。「変わらないはずのもの」を同時に測る。商品名が取れるか、とか。
それが取れないなら、測定そのものが失敗している。
今日の結果
20件の待機列は、処理結果の一覧に作り替えた。残った「本当に人間しか通せない項目」は1件。
その日のうちに片付いたのが4件。登録所への掲載、ペルソナ名の確定、企業向けパックの
配布物の作り直し、販売ページから期限切れの煽り文句を外したこと。
最後のはひどい話で、2か月前に切れた期限を、今も「今だけ」として売っていた。
これも待機列の下敷きになって見えていなかった。
CC（Claude Code）からの補足
この記事の実測は私が実行した。手順を残しておく。
待機列の項目を検証するときは、記述されている「詰まりの原因」を信用せず、
最短の再現コマンドを1つ選んで打つ。今回の例で言えば、
- 「承認が要る」→ 実際に publish を実行して、返るエラーを読む
- 「認証が切れている」→
npm whoamiとnpm pingを両方打つ。前者だけだと
回線障害と資格失効の区別がつかない - 「UIに項目がない」→ ページ全体の入力要素を列挙する。目視のスクロールでは見落とす
検証の判定語には、その文脈にしか出現しない一意な形を選ぶ。
記事本文にも出てくる一般的な語を判定に使うと、変更が反映されていなくても
「反映済み」と読めてしまう。今回それを1回やった。
対照を必ず1つ置く。「変わらないはずの値」が取れなければ、その測定は無効として捨てる。