Claude（Opus）が実装し、テスト200件超が通ったヘッドレスCMSの差分を、別のAIであるGLM-5.3（Z.ai）に「攻撃者の目で読め」と5回通した。
指摘は延べ55件。Opusが実物のコードで1件ずつ確かめ、20件を採用した。1回目の査読で、他人のアカウントを乗っ取れる重大な穴が見つかっている。
翌日に自社のSEOツールでも同じ手順を回すと、GLMの指摘を受けて足した修正のほうに、新しい穴が開いていた。
前提
事例1: 自社のヘッドレスCMS
- 構成: Cloudflare Workers・D1・R2
- 追加した機能（1日で実装）
- 承認フロー
- ID/パスワードログイン
- 公開終了日時
- 添付ファイル
- 地図/動画の埋め込み
- 実装: すべてClaude（Opus）
- 査読前の状態: テスト200件超が通過済み、ローカルの動作確認も済み
- 査読役: GLM-5.3（Z.ai）
事例2: 自社のSEOツール
- 追加した機能: 関連キーワードの取得、URLの取得
- 査読の対象: 前日の差分とツール全体
- 査読役: GLM-5.3
- 査読の回数: 4回
手順
査読は以下の流れで回した。
1. Claude（Opus）が機能を実装し、テストとローカルの動作確認を通す
2. 差分を GLM-5.3 に渡し、「攻撃者の目で読め」と指示する
3. GLM-5.3 の指摘を Opus が実物のコードで1件ずつ確かめ、採否を決める
4. 採用した指摘だけを直す
5. 直した差分を、もう一度 GLM-5.3 に通す
6. 新しい穴が出なくなるまで 2〜5 を繰り返す
手順3で、GLMの指摘をそのまま正としては扱わない。事例1では55件中35件を捨てている。
GLMは「攻撃者の目で」読むので、実際には到達できない経路や、すでに別の場所で防いでいる入力まで指摘してくる。
採否を実物のコードで確かめる工程を飛ばすと、不要な修正が増え、修正した箇所がまた次の穴の入口になる（事例2で実際に起きた）。
事例1: 査読5回の記録
査読は2026-10-17 23:25から10-18 00:04までの間に5回回した。
| 回 | 何を通したか | 指摘 | 採用 | 判定 |
|---|---|---|---|---|
| 1 | 機能追加の差分（本番に出す直前） | 7 | 5 | 重大 |
| 2 | 査読の門のスクリプト自体 | 7 | 5 | 要確認 |
| 3 | 門の修正 | 6 | 0 | 要確認 |
| 4 | その日の変更全体を4塊に分けて通し直し | 28 | 9 | 重大 |
| 5 | 4回目の修正の差分 | 7 | 1 | 要確認 |
合計は指摘55件・採用20件・不採用35件。
表から読み取れる点は3つある。
- 1回目で「重大」が出た。 テスト200件超が通り、Claudeも問題を挙げていなかった差分だった
- 4回目で再び「重大」が出た。 差分単位ではなく、その日の変更全体を4つの塊に分けて通し直すと、指摘が28件に増えた。差分だけ見ていると、変更どうしの組み合わせで生まれる穴を見落とす
- 5回目でも新しい穴が1件出た。 直した差分を通し直す工程は、1回では終わらない
2回目と3回目は、査読を回すためのスクリプト（門）そのものを査読にかけた回になる。査読の仕組み自体にも穴があり得るので、仕組みも同じ目で読ませた。
事例1で見つかった重大な穴: 他人のアカウントにパスワードを付けて乗っ取れた
1回目の査読でGLMが見つけた穴。
- 場面: サイトのオーナーが、メンバーにIDとパスワードを発行できる機能
- 穴: メンバーを追加するときに、メールの確認が無い。そのため、他人のメールアドレスでメンバーを作り、パスワードを付けることで、そのアカウントを乗っ取れた
「オーナーがメンバーを招待する」という正常系だけを見ると、メールアドレスを入力してパスワードを発行する流れは自然に見える。
テストも正常系の動きを確かめるので、全部通る。
「入力したメールアドレスが、本当にその人のものか」を確かめる工程が無いことは、悪用する側の視点に立たないと気づきにくい。
自治体向けの提案に合わせて1日で5つの機能を足した日だった。ID/パスワードログインを足した日に、ログインまわりで重大な穴が出ている。
事例2: 直した修正のほうに穴が開いた
翌日（2026-10-18）、自社のSEOツールに関連キーワードとURL取得の機能を足し、前日の差分とツール全体をGLM-5.3で4回査読した。
指摘27件をOpusが実物で確かめ、10件を直して本番に出した。
ここで起きたのは、GLMに言われて足した修正のほうに穴が開くという現象だった。
落とし穴1: 回数の上限が同時リクエストで素通りできた
GLMの指摘を受けて、機能の呼び出しに回数の上限を足した。
その上限が、同時にリクエストを送ると素通りできた。
「今の回数を読む → 上限未満なら処理する → 回数を増やす」と工程を分けて書くと、読んでから増やすまでの間に別のリクエストが割り込める。
同時に送られたリクエストは、どれも「まだ上限未満」と読んでしまう。
落とし穴2: 「localhostなら通す」がHostヘッダーで破れた
開発中にログインを省くための「localhostなら通す」という修正が、Hostヘッダーの偽装で破れた。
Hostヘッダーはリクエストを送る側が自由に書ける値なので、本番に対して localhost を名乗るリクエストを送れば、開発用の抜け道に入れてしまう。
対処
回数の上限
上限は1文のSQLで先に予約する形に変えた。
回数を読む処理と増やす処理を1文にまとめ、上限に達していたら予約自体が失敗するようにした。読んでから増やすまでの隙間が無くなるので、同時リクエストでも上限を超えない。
開発用ログイン
開発用ログインは、設定ファイルの明示フラグだけで許す形に変えた。
リクエストに含まれる値（Hostヘッダー）で開発環境かどうかを判定するのをやめ、サーバー側の設定で明示したときだけ開発用ログインが有効になる。
本番でHostを偽装したリクエストを送り、403が返ることを確かめてから出した。
2つの事例から言えること
| 項目 | 事例1（ヘッドレスCMS） | 事例2（SEOツール） |
|---|---|---|
| 査読の回数 | 5回 | 4回 |
| 指摘 | 延べ55件 | 27件 |
| 採用・修正 | 20件 | 10件 |
| 主な穴 | メール確認なしでの乗っ取り | 修正で足した上限・開発用ログインの穴 |
- テストが通ることと、攻撃に耐えることは別物だった。事例1は、テスト200件超が通った状態で重大な穴が見つかった
- 別のAIの指摘は、そのまま正にしない。事例1では55件中35件を捨てた。採否は、書いた側のAIが実物のコードで確かめて決める
- 直した差分は、もう一度通す。事例1では5回目でも新しい穴が出て、事例2では修正そのものが穴になった
- 差分だけでなく、その日の変更全体を塊に分けて通し直す。事例1では、その工程で指摘が28件に増え、重大な穴も見つかった
- 開発環境かどうかの判定に、リクエスト側が書ける値（Hostヘッダー）を使わない。サーバー側の設定で明示する