TL;DR — AIは確実に一個人に接近団体級の安全処理能力をもたらすが、それが出す✅はground truthと等価ではない。commitは上線と等価でなく、摘要は驗証と等価でない。真に信頼できるのは、git logに残る記録であり、curlが返すステータスコードであり、そして人が最後の逐項核対という責任を負う意志があるかどうかである。
私が一つの✅をあまりに早く信じないことを学び始めたのは、実は非常に完整で、非常に専門的に見える説明図から始まったのである。
5月28日Claude Codeがdynamic workflowsを推出すると、コミュニティには すぐにこの機能を詳しく説明する図が流れた：YAMLファイルでプロセスを定義し、下には非常に専門的に見える一連のコマンドがリストされていた。私は危うく同じように.yamlを開くところだった。
危うく。後で私はやはり先に公式のIntroducing dynamic workflowsを調べた。読み終えて呆然とした：dynamic workflowsは全くYAMLではなく、JavaScriptで書くものだった。その図にリストされていたコマンドの半分は存在しなかった。
その図は悪意があったわけではない。それは単に熱心な人がまとめた二次的な簡易版だった。しかしそれは私に初めて一つのことを気づかせた：誤りは必ずしも誤りのようには見えない。それは非常に専門的で、非常に完整に見え、直接コピーできる操作ガイドのように見える場合もある。これは その日一日の基本原則ともなった：二次的摘要に留まるな、美しい整理に説得されるな。真に重要なことは、最終的に全て源頭に戻る必要がある。
AIが「修好了」と言ったとき、あなたは そのまま受け取るだろうか？
その日、私はこのツールを使って、自分のウェブサイトに一回の安全監査を行った。私はこれをStage-2 hardeningと呼ぶ。平たく言えば、ウェブサイトが上線した後の、真に補うべき、遮るべき、綺麗に収拾すべき防護を一つ一つ補強することである。
dynamic workflowsの売りは、まさにこの種のタスクを突いていた：大きなテーマを投げると、自分で企画し、数十から百のsubagentを開いてrepo全体を並行スキャンし、そして公式の言葉を借りれば、「回報前に自己驗証し、偽陽性を除去する」。公式はデモ用途の一つに直接安全監査を挙げている。聞こえるのは、驗証まで誰かがやってくれたということだ。
問題はまさにここにある。確実に多くのことを行い、確実に大量の人力を節約した。しかし「驗証」ということは、AIが強くなったからといって、人の責任から自動的に消失するものではない。それは単により発見しにくい位置に変わっただけで、非常に完整で、非常に秩序があり、人を安心させるような完成摘要の中に隠れているのだ。
一人でどうやって系統的安全監査を行うか？マルチセッション分業の実際の配置
私がどのように配置したか説明しよう。後の いわゆる「驗証」が本当に有効かどうかは、実は最初の分業方式から半分決まっている。
私は作業を異なるいくつかのセッションに分割し、それぞれの役割を分担させた。Chat側は私が驗証と決策の中心位置に置いた。直接プログラムには触れず、より重要な機能を専門的に保留した：「このことは本当に完成したのか？」と絶えず問いただすことだ。Coworkはコードを読み、方案を設計し、引き継ぎを書き、ブラウザ内のClaudeを誘導してCloudflareバックエンドをクリックする責任を負った。CodeはImplementationを担当し、修正後自分でcurl、自分でauditを実行して検収し、その後commitする。
さらに私が自分に課した硬い規則がある：big-bangは行わない。一回につき一つの安全側面のみ動かし、commitする時に入るファイルを指名し、デプロイ前にサイトを壊していないことを確認し、デプロイ後すぐにcurlでオンラインの実況を見て、各決策をその場で記録に書き込む。一回につき一つのブロックのみプッシュし、壊れても どのブロックが壊れたかわかる。これは遅く聞こえるが、私は後になるほど この種の遅さは一種の統治コストだと信じるようになった。それが得られるのは：各ステップが単独で追跡可能、単独で驗証可能、そして エラー時に単独で分解可能であることだ。
なぜ「已经commit」は「線上已生效」と等価ではないのか？
ここで背景を説明しておく必要がある。これは後の全ての判断格差の鍵となるからだ。
私のこのウェブサイトの自動デプロイは、4月末から壊れていた。それは前回のアカウント停権後の靱性再構築が残した後遺症だった：私は一套の迂回デプロイ方式に替えたが、一つの自動上線パイプラインがずっと接続し直されていなかった。結果は：私が変更をrepoにcommitすると、gitの記録は綺麗だが、ウェブサイトで動いているのはまだ古いものだった。手動で一つのwrangler pages deployコマンドを下す必要があり、変更が真にproductionに到達するのだ。
言い換えれば、その期間「commitした」と「オンラインで有効になった」は二つのことだった。git logは一段のプログラムコードがかつて提出されたことを証明できるが、ユーザーが今それを見ていることを証明することはできない。オンラインが実際に何を返すかを知るには、curlに頼る必要がある。率直に言えば、curlは全ての摘要を回避して、直接そのサーバーに「あなたは今実際に私に何を返すのか？」と問うことだ。gitの記録は人に「事情は既に完成した」という秩序感を与えるが、ユーザーが真に打ち当たるサーバーは、まだ古い世界に留まっている可能性がある。最も危険な状況は：記録は非常に完整に見えるが、現場は追いついていないことだ。この格差は、後で繰り返し現れる。
「以为做完」と「真的做完」の差はどこにあるか？驗証によって阻止された三つの例
その日最も記録する価値があるのは、三つの「私は既に完成したと思ったが、驗証して初めて していないことがわかった」瞬間である。
第一つ目。git statusを綺麗に見せるため、私は一つのファイルをcommitした。後でプロジェクト全体をgrepで調べて初めてわかった：このファイルは参照ゼロで、どこでも使われておらず、回路に接続されていない孤児プログラムコードだった。私は一つの修復を完成したと思ったが、実際にはgit statusを綺麗にしただけだった。gitは綺麗になったが、その種の綺麗さは管理上の幻覚に過ぎなかった。
第二つ目。一つの保護用設定を、私は環境変数で「設定完了」し、その時は非常に安心した。curlで実際に打ってみて初めて知った：その設定を使用するエンドポイントは、まだデプロイされておらず、静的な404を返してきた。設定は確実に存在したが、それが保護すべきエンドポイントはその時まだ真に上線していなかった。設定したが、ground truthでは設定していないのと等価だった。
第三つ目が最も記録する価値がある。全体が終わった時、私は一份の摘要を受け取った：十一項全て完成、整然とした✅の列、私は危うく仕事を終えるところだった。しかし私は逐項でgitとcurlの実況に照らして核査した：誰も使わない孤児プログラムコード、まだ上線していない404の空殻設定、私が数分前に手ずから見つけた二つの問題が、きちんとその列の✅の中に横たわり、完成として計算されていた。
📊 この行程のいくつかの数字
- 自動デプロイ中断起点：2026/04/29（前回のアカウント停権の後遺症、監査当日まで未接続）
- AI摘要でground truthに阻止された「偽完成」：11項中2項
- 靱性演練完成度：0%（意図的に人工実行に残し、私が直接gateする必要）
これはそのツールの売りに戻る。それは「各発見を驗証し、偽陽性を除去する」ことを謳っている。プログラムコードをスキャンするレイヤーでは、確実に非常に強力で、大量の人力を省いてくれた。この点は否認しない。しかし「私は一括で完了した」というこの摘要は、前述の査核とは根本的に異なる：それは本質的に一段の文字予測であり、モデルがその対話文脈で、最も自然で、最も出現すべき次の一句を算出したものだ。そしてタスクが終盤に向かう時、最も出現すべきその一句は、往々にして「全て完成」である。その列の✅は很可能このようにして生まれたのだ。それが読み取ったのは対話の向かう先、タスクの雰囲気、そして一つの収束すべきように見える叙事のリズムである。しかしそれはサーバーの この瞬間の状態を真に読み取ったわけではない。だからground truthは決して摘要の中には住んでいない。それはgit logのその一行の追跡可能な記録の中に住み、またcurlが返すそのステータスコードの中に住んでいる。
repoが見えない時、驗証はまだどうやって関門を守れるか？
その日私の側にはもう一つの非常に実際的な制限があった：私はrepoを読めなかった。ファイルシステムの接続がずっと停止し、毎回4分まで持ってから切断された。だから私が「目で見ることができる」ものは、実際には非常に限られていた。
そこで関門は「私が見た」に頼れなかった。私が頼ったのはgitの底層コマンドが吐き出す硬い事実に加えて、Code側が貼り返してくる真実のcurl回応だった。残りの見えない部分は、一つの規則に従って進んだ：見えるものは硬く驗証し、見えないものは正直に「被告知」とマークする。私は「聞こえるように完成」を「已经驗証」に偽装せず、他人の報告を自分の判断にすり替えもしない。
これは認輸のように聞こえるが、実際は全体の方法の中で最も関鍵的な部分である：自分の可視範囲を正直に認めること、それ自体が統治の一部なのだ。「我驗証過」と「我只是被告知」を分清し、それらを同じ色の✅に混同させない。「已驗証」と「被告知」を分けられない人、或いはこの両者を分けられないAIは、報告をいくら美しく作っても、最終根拠として扱うことはできない。
この種の「表面設好、其實沒擋住」の盲点は、デプロイのレイヤーだけにあるのではない。私はその日この監査でAI使用量を爆発させないよう、サイト全体共用の毎日コスト上限も設定した。dynamic workflowsは非常にtokenを消費し、公式自身も小規模タスクで先にコストを試すよう注意している。機制は正しかった。
しかし私は二つの收拾しきれていない尻尾があることを認めなければならない。一つは、その上限の数字は私が「先射箭再畫靶」で埋めたものだった：その時もう一つの前提がまだ確認されていなかったので、その閾値には実際推導根拠がなく、プログラム中にコメントすら残していなかった。二つ目は、その計数プログラムに例外処理が含まれておらず、万一背後のストレージが壊れた場合、より厳格に関門を守るのではなく、直接通すことになってしまう。最も遮るべき極端状況で、私はかえって破口を残した。私はこの二つを記録することを選択し、そこで統治已完成を偽装させないことにした。監査の本分は欠口を命名し、記録し、次回の処理に残すことである。なぜなら推導がなく、最も遮るべき時に通してしまう上限は、あの列の驗証されていない✅と実は同じものだからだ：遮ったように見えるが、実際にはそうではない。
なぜこの驗証規律は こんなに守りにくいのか？
まず今回の経験を位置づけたい。
これは「一人でAIに頼って完璧に全体の防護を修好した」爽文ではない。そう書いた方が見栄えは良いが、誠実ではない。より正確な表現は：AIは確実に私一人で過去小チームが必要だったかもしれない系統的処理を完成させてくれた。しかし作業に品質をもたらしたのは、後の逐項ground truth驗証という地味な功夫である。
そしてまさにその地味な功夫が、どの「完了した」が実際には完了していない作業かを捉えた。
この二つのことは一緒に語らなければならない。前半は能力の跳躍であり、後半がこの能力の品質である。後半がなければ、前半は優位性ではないだけでなく、逆に噛み付いてくる可能性もある。
私は全ての問題が既に清算されたふりはしていない。内容安全政策のブロックは複雑すぎて、先に置いておく。靱性演練の全体は今でも0パーセントのまま。あの孤児プログラムコードもまだ横たわっている。コスト上限のあの二つの尻尾もまだ収拾し終わっていない。
しかし真に困難なのは、その未完成リストにあるのではない。
真に反省する価値があるのは別のことだ：私はなぜあの列の✅の前で止まりたがり、それを信じようとしたのか？
それは単なる粗忽ではない。
より深いレイヤーで言えば、私の心の一部が、実はあの列のチェックマークが真実であることを願っていたということだ。私は「一個指令把全站跑完」を望み、私が省きたかったのは根本的には時間だけではなかった。ある程度、私が降ろしたかったのも労働だけでなく、私の判断だった。
私はそのツールが一種の私がもう振り返って核対する必要のないものになることを希望していた。まるでそれが全てを知り、私に代わって全てを担うかのように、全知の神のように。
あの列の美しい✅が危険である理由は、まさにそれがその願望が実現しようとしている場所に ちょうど落ちているからだ。私自身が、そのように説得されたがっていた。
そして「判断を降載」することは、実際には二つのタイプがあり、大きく異なる。
苦労を投げ出すのは合理的である。それらの繰り返しの、機械的な、誰がやっても大差ない作業は、本来ツールが存在する理由である。これも一人がチーム級産出まで拡大される鍵である。この種のことは、投げ出せば投げ出すほど良い。
しかし、判断を投げ出すことは、また別の話である。特にground truthに対する最終判断。その一刀を譲り出したら、あなたが譲り出すのは作業量ではなく、本来あなただけに属する責任である。
超級個体の「超級」は、決して産量が大きくなることだけではなく、判断力が拡大されることである。判断まで譲り出したら、拡大されるのはただより高効率の混乱に過ぎない。
私が危うく譲り出しそうになったのは、まさに後者である。
私は先ほど「全知の神のように」と言った。私はこの言葉の含意をよく理解している。
「全知」は非常に古い、神学に属するほど古い言葉である。それは決してツールを形容するために使われるものではなく、造物主への仰賴を指し示すものである。しかし人類は既に、終極の信頼をそれを承載すべきでないものに置くことを期待し始めている。現在の人類技術でこのようにすることは誤りである。
私にブレーキを踏ませたのは、その瞬間私がどれほど清醒だったかではなく、私が以前に踏んだ穴と事前に設けた規則である：各判断は必ず基礎を持ち、かつ反証可能でなければならない。
私自身も実は信頼できない：忘却し、記憶違いをし、認知帯域幅も限られている。信頼できるのは規則である。
人は疲労し、手を抜きたがり、美しい結論を信じたがる。しかし良い統治規則は、人が最も自分を許したい時に、ブレーキを踏むのを助け、線を越えさせない。
緑のチェックマークは安い
安いのは緑のチェックマーク、高いのはground truthである。より警戒すべきは、ツールが強くなるほど、この両者の価格差が開かれることだ。自分で企画し、自分で並行作業し、振り返って「私は驗証した」と言うツールが与える✅は、ますます多く、ますます美しくなる。緑のチェックマークの供給量が突然暴増すると、その信頼度はかえって希釈される。真に稀少なのは、常に現場で驗証できる事実だからである。
git logはあなたのために演技しない。curlが返すステータスコードも、今日あなたが疲れているかどうかを気にしない。あの説明図は非常に自信を持って私にYAMLを書くよう要求したが、間違っていた。あの摘要は非常に自信を持って私に十一個の✅をくれたが、そのうち二つは偽物だった。
だから次回また誰かが、それが一人であろうと、一つのAI Agentであろうと、さらには私自身であろうと、非常に確信を持って「これは解決した」と言っても、あなたも私も やはり源頭に戻り、自分でもう一度証拠を検査するだろう。
私が見に行くのは、私が生来より慎重だからではなく、自分が実際にどれほど手を抜きたがっているかを知っているからだ。我々がどれほど検査しなくても良いことを希望しているか、大脳がどれほど楽をしたがっているか。
💬 コメント
読み込み中...