① 冒頭：事件の提示
2026年3月31日、AnthropicのClaude Codeのソースコード51万2千行が流出した。
原因はたった一行の記入漏れ。
*.map
.npmignore にこの一行がなかった。たった、それだけ。
- ハッキングではない
- 攻撃でもない
- 構造設計の空白が事故を起こした
さらに深刻な事実：これは同じミスの3度目です。
そしてもう一つの皮肉。
Claude Codeは
・マルチエージェントオーケストレーション
・JWT認証のIDE連携
・44個の機能フラグ
・KAIROS・ULTRAPLANという未来機能
これらの先進技術を持っているのに
find ./dist -name "*.map" && exit 1
この一行がなかった
- 「複雑処理・快適さ・正確さ」と「確実であること」は全くの別問題なのです。
② なぜ防げなかったか：チェックリストの限界
チェックリストは存在していたはず。なぜ機能しなかったか？
1回目 → 意識的に確認
100回目 → 半意識で確認
10000回目 → 手が動くだけ
10万回目 → チェックを「見た」だけ ← こんな感じで事故が発生したはずだと推測？
人間は10万回に一回だから起きないという全く根拠のない線形バイアスを持っています。
事故は確率論で扱えない領域です。
- 確率論の前提：事象が独立している
- 現実：10万回の正常実行が「つもり」を生む原因そのもの
- 安全の実績がδを蓄積させる 非線形問題
1回の事故を防ぐために10万回確認を増やすことはできない。
③ 代替手段の検討と限界
AI自動化
→ 人間が確認できない
AI二重監視
→ 責任の所在がない
認証強化
→ 出力されたものは止められない（方向が逆）
設定プロンプトでの禁止
→ AIの解釈層を通る以上、物理的な保証にならない
→ モデルが更新されると挙動が変わる
→ 命令の意図と実行結果は一意に定まらない
Copilot Agent / Claude Codeへの委任
→ エージェントはコンテンツ除外ルールを考慮しない。(全ての対処可能なNOT文がない。)
→ 同じ事故が自動化されて量産される
（必ず学習されるということはなく2度あることは3度あるのは何ら不思議ではありません）
全て同じ層の単なる改善であり根本解決ではないのです。
④ 問いの転換
× 「誰が確認するか」
○ 「何を通さないか」
チェックリストは「確認した記録」を残す。（10万回だと確認したつもりが発生。）
自分自身の確認したつもり、他の人が確認したはず・・・根拠は？
必要なのは「確認が不要な構造」です。
⑤ セキュリティより低位の問題
- 今回の事故はセキュリティ層の話ではない。
セキュリティ ← 侵入・攻撃・認証の問題
品質管理 ← バグ・テスト・レビューの問題
【保守点検】 ← 構造自体がそもそも機能しているか ← ここ
設計 ← 何を通してはいけないかの定義
ハッカーは関係ない。設計の空白が事故を起こした。
部分的な改修ではなく、フロー全体の組み直しが必要。
ゲートはシステムの最後に置くのではなく、最初に設計する。
⑥ 物理ゲートという解答
「確認する」のではなく「処理完了の物理的証拠を要求する」。
× 確認ベース
.npmignoreに除外記述があることを「確認する」
→ 人間が見る → つもりが発生する
○ 通過条件ベース
.mapファイルが出力物に含まれていないことをゲートが検証する
→ 含まれていればビルドが止まる
→ リリースパイプラインに進めない
一箇所に集中した繰り返し確認ではなく、各工程の出口に通過条件を埋め込む。
物理ゲートの定義
物理ゲートの条件：
1. 意味を解釈しない
2. 物理的事実だけを問う
3. YESかNOしかない
4. 人間もAIも介在しない
5. 条件外なら処理が止まる
物理ゲートの実装
# 存在確認（あってはいけないファイル）
find ./dist -name "*.map" && echo "ERROR" && exit 1
find ./dist -name "*.env" && echo "ERROR" && exit 1
find ./dist -name "*.pem" && echo "ERROR" && exit 1
find ./dist -name "*.key" && echo "ERROR" && exit 1
# 文字列確認（含まれてはいけない文字列）
grep -r "sk-ant-api" ./dist && echo "ERROR" && exit 1
grep -r "ANTHROPIC_API_KEY" ./dist && echo "ERROR" && exit 1
# 結果をprint出力してフライトレコーダーに記録
echo "Gate passed: $(date)"
find・grep・printで完結する。新しいツールは不要。AIも不要。
3年前は当然していた原始的でありながら確実な処理。
これがNRA-IDEの言う物理ゲートの実体。
三層の強度比較
強 ┌──────────────────────────────┐
│ 物理ゲート
│ find/grep/print + exit 1
│ 条件外は物理的に進めない
├──────────────────────────────┤
│ プロンプトサンドイッチ
│ Pre/Post両側で構造的に問う
│ ただし解釈層を通る
├──────────────────────────────┤
│ チェックリスト
│ 人間が確認する
│ 10万回に1回つもりが発生する
弱 └──────────────────────────────┘
理想は物理ゲートとプロンプトサンドイッチの二重構造。
プロンプトが止め、それでも通り抜けたものを物理ゲートが止める。
⑦ R = δ/τ で読む
NRA-IDEの構造式で今回の事故を記述する。
δ（蓄積ズレ）= .npmignoreの記述漏れ
τ（吸収厚み）= リリース前のゲート → 存在しなかった
R = δ/τ → ゲートなし = 閾値超え確定
Fail-Closed → 発火するゲートがなかった
⑧ プロンプトで制御できない理由
設定プロンプトは命令の最上位に見えるが意味解釈層を必ず通る。
命令（意図）→ LLMが解釈 → 出力（結果）
この変換は一意ではないといことです。
- Undercover Modeは「内部情報を漏らすな」という命令だった
- それでも別経路で全部漏れた
- モデルが更新されると挙動が変わる
- 「良くなった」のか「変わった」のか判断できない
命令で制御しようとするな。出力を構造で制御せよ。
⑨ ゲートも静的ではない：保守の義務
ゲートは一度作れば終わりではない。
Codeを書くのが簡単な時代。GREPアプリも検索・確認アプリも入れるだけ。
わずかの手間です。
今回の真の原因：
以前はNode.jsを使用
↓
Bunに変更（Bunはデフォルトでソースマップを生成する）
↓
ゲートの見直しが行われなかった
↓
ツール変更というδにτが追従しなかった
モデルが更新されたとき・ビルドツールが変わったとき・
環境が変わったとき、AI挙動が少しでも変化した時はゲートの見直しは必須。
δの変化 → τを追従させる
これを怠るとRは静かに上昇する
⑩ AI任せという反省
AI登場前
find + grep + exit 1
→ 当たり前に使っていた
→ シンプルで確実
AI登場後
「AIに確認させよう」
→ 高度に見える。多くのメディア,SNS,企業も専門家も推奨している流行最先端のテクノロジーのはず？
→ 実は退化している（結果が全てで、AIも、推奨している専門家も、責任はとってくれません。）
責任をとるのは当人。
AIに任せるべきこととそうでないことの分離：
AIに任せるべきこと
└── 意味の処理・生成・推論
人間とツールがやるべきこと
└── 物理事実の確認（find/grep/print）
└── ここはAIより確実で速くて責任が取れる
⑪ 結論：明日は我が身
Anthropicは世界トップクラスのAI安全企業です。
それでも同じミスを3度繰り返しました。
管理者への問い：
・あなたのビルドパイプラインにゲートはあるか
・ツールを変えたとき、ゲートを見直したか
・モデルを更新したとき、挙動の変化を確認したか
・find/grepのゲートが各工程出口にあるか
Anthropicの事故は他人事の話ではありません。
同じビルドツールを使い、同じフローで開発している組織は
全て同じ状態にあります。
たまたま流出していないだけです。
δは既に蓄積されています。ゲートがないだけで。
記事の締めくくり文
find・grep・print。
これらは古い道具ではありません。
意味を解釈せず、物理的事実だけを問い、条件外なら止まる。
AIより速く、AIより確実で、AIと違い責任の所在が明確です。
これがNRA-IDEの言う物理ゲートの実体でした。チェックリストは「確認した記録」を残す。
物理ゲートは「確認が不要な構造」を作る。
違いは記録の有無ではなく、設計の順序にあります。
ゲートの位置を最初に決めてから、システムを作る。最も単純なものが最も強いゲートでした。
AIは物理構造ではさみこむサンドイッチ構造が基本です。
サブAIで監視にも限界が存在します。
他にも色々な形での事件が起きていますが当分は「ゲート構造」という類の話題が継続するのではないかと思います。
NRA-IDE Project 律環公理/内包性動力学エンジン
( Nomological Ring Axioms / Intensional Dynamics Engine )
©M-Tokuni