論文を原文で読む：精読ガイド

第1章と第4章では、論文の結論だけを日本語で紹介しました。応用編の最初の章では、その論文を原文で読みます。英語論文には決まった読み方の順序があり、章立てにも型があります。型が分かれば、専門外の人でも「どこに何が書いてあるか」「この数字はどこまで信じてよいか」を自分で確かめられます。監査報告書を結論の一文だけでなく、手続の記載まで読む練習です。

英語論文の読み方：Abstract、図表、Conclusion、本文の順で

論文は最初から順に読むものではありません。まずAbstract（要旨）を3回読みます。問い、方法、主要な数字、結論が200語ほどに全部入っています。次に本文を飛ばして図表（Figure、Table）のキャプションだけを順に見ます。骨格は図表に現れます。そしてConclusion（結論）をAbstractと照らし合わせ、最後に本文で肉付けします。分からない段落は飛ばして構いません。

読む前に、版（バージョン）を必ず確かめます。arXivの論文は改訂のたびに数字が変わります。この論文は初版が2026年6月、v4が2026年9月14日です。初期の版を基にした解説記事には、脆弱性1,471件、致命的・高76.7%といった数字が出てきますが、v4では1,186件、65.77%です。この教材はv4に揃えています。

論文の章立てと、見るべき図表

論文は9つの節からなり、4つの研究課題（RQ、Research Question）がそのまま第4〜7節の見出しです。

RQは原文のまま覚えておくと参照が追えます。RQ.1「What is the landscape of real-world vibe-coded applications?」（どんなアプリが実在するか）。RQ.2「How prevalent and severe are vulnerabilities in deployed vibe-coded applications?」（どれだけ広く、深刻か）。RQ.3「What factors contribute to these vulnerabilities?」（何が生むか）。RQ.4「What conditions can mitigate the vulnerabilities of vibe-coded applications?」（どんな条件なら減らせるか）。

第3節：監査手法は、何を保証し、何を保証しないか

数字を信じてよいかは、第3節で決まります。ここは飛ばさずに読んでください。収集（3.1）は、GitHubのコード検索で Claude Code と Lovable の痕跡を持つ74,800件を集め、品質で38,078件に絞り、「AI由来のコミットと行数がともに90%以上」という条件で9,041件にしています。

発見（3.2）は、Claude Code（Claude Sonnet 4.6）と GitHub Copilot（GPT-5.3-Codex）の2系統に、セキュリティ用スキル2種類を組み合わせた2×2の4通りです。200件に対して800本の監査報告が作られ、生の指摘は11,150件。AIが重複排除と選別で2,125件に絞り、別のAIエージェントが「本当に届くか」を無害な方法で確かめて1,287件に。最後にセキュリティ専門家である著者2名が独立に見て1,186件を確定しました。2名の一致度はCohenのκ（カッパ。偶然の一致を除いた一致度で、1が完全一致）で0.87です。

保証すること

偽陽性（false positive、誤報）は抑えられています。11,150件のうち確定は1,186件で、各段階で「届かないもの」「実害のないもの」を落としています。偽陰性（false negative、見逃し）にも上限の目安があります。執筆に関わっていない研究者が20件を盲検で監査し、枠組みが報告していない脆弱性は見つかりませんでした。20件で見逃しゼロなら、統計の「3の法則」で、見逃し率の95%信頼区間の上限は3÷20＝15%です。また、答えの分かっている練習用アプリ OWASP Juice Shop に同じ枠組みを当て、既知の脆弱性の95.70%を見つけています。

保証しないこと

• 見逃しがゼロとは言っていない。15%は「それより悪くはないだろう」という上限です。実際の脆弱性は1,186件より多い可能性があり、91.0%も、見逃しがあれば上がる方向にしか動きません。
• 母集団の偏り。GitHubで公開され、公開稼働中のものだけです。著者も第8節で、2つの道具の痕跡だけで集めたことを限界として挙げています。ただし、Claude Code製とLovable製を分けても、脆弱性の種類の順位（相関ρ=0.73）と原因の順位（ρ=0.86）は似ていたと補足しています。
• 監査役と被監査者の重なり。Claude Code製のアプリを、Claude Code自身が監査しています。著者はこれを偏りの可能性として明記し、2系統の監査と人のレビューで補ったとしています。完全な独立性ではありません。

RQ.1〜RQ.4を、節ごとに読む

RQ.1 どんなアプリが作られているか（第4節）

9,041件のうち8,695件（96.17%）がWebアプリでした。規模の中央値はコード8,254行、100ファイル。開発期間の中央値は8.39日で、67.81%が30日以内に作り終えています。公開稼働まで至ったのはWebアプリの984件（11.32%）です。言語はJavaScript、CSS、HTML、TypeScript、技術はReact、Tailwind CSS、Viteが多数派です（Figure 1）。典型は「1週間ほどで作られた1万行弱のWebアプリで、9本に1本だけが公開されている」。あなたが作ってきたものと、ほぼ同じ姿です。

RQ.2 脆弱性はどれだけあるか（第5節）

200件のうち182件（91.00%）に1件以上、合計1,186件。脆弱性があったアプリ1件あたりの中央値は6件（平均6.52件）。深刻度は致命的18.47%、高47.30%で合わせて65.77%、低は9.36%です。Table 2は分類ごとの件数と割合に加え、「その種類を1件以上含むアプリの割合」を載せています。第1章の表になかった列です。

「アクセス制御の不備を含むアプリが64%」は、「自分のアプリにもある確率が6割を超える」と読み替えられます。場所の内訳はサーバー側625件（52.70%）、ブラウザ側426件（35.92%）、設定135件（11.38%）。Table 1は規模別で、大きいアプリほど件数は多いが、1,000行あたりの密度は下がります。

RQ.3 なぜ生まれるか（第6節）

第4章で扱った3分類・8つの失敗モードの節です。記憶の欠陥160件（13.5%）、目的の欠陥274件（23.1%）、知識の欠陥752件（63.4%）。Figure 3は8つのモードを、仕様（specification）、実装（implementation）、反復（iteration）、公開（deployment）という工程に対応づけています。「変更の伝播不足」と「機能修正の副作用」は反復、「先送りの忘却」と「利用者任せ」は公開の工程で起きます。どの工程で何を見張ればよいかが読めます。

RQ.4 どうすれば減るか（第7節）

設計は OFAT（one-factor-at-a-time、一度に一つの条件だけ変える）です。70件の脆弱性を対象に、8条件×3回で合計1,680回、各条件210回ずつ。Table 3が条件の定義、Table 4が結果です。基準のモデルはGPT-5.6-Terra、弱いモデルはLuna、強いモデルはSolという名前で出てきます。

第4章で触れなかった観察が3つあります。知識の欠陥が改善したのは強化スキルと「ready for production」の2条件だけで、他は目的の欠陥にしか効いていません。35件の脆弱性は3条件以上で再発し、どの条件も全部は消せず、同じ条件で3回繰り返しても22.0%のセルで結果が割れました。そして再発した434回のうち90回（20.7%）では、AIが危険に気づいて警告を書きながら、そのまま危険なコードを出していました。著者はこれを「気づきと行動の隔たり（awareness–action gap）」と呼んでいます。

第8節：不安全の源と、利用者への提言

著者は不安全の源を3つに分けます。AI側の限界（文脈を保てない、完成を優先する、暗黙の要件を見落とす）、作業の進め方の弱さ（短期間で作り、レビューや公開前の関門がない）、責任の不一致（AIが作るのに、設計やセキュリティ確認や運用は利用者に委ねられ、利用者にその専門性がない）。3つ目は、この教材の読者のことです。

利用者への提言は5つです。仕様の段階でセキュリティ要件を明示し、本番向けの実装を求め、強化スキルを入れる。理解していない技術的な詳細を書かない。AIの警告を軽く承認しない。公開前に、先送りした作業、認証と権限、入力処理、秘密情報の自己点検を求める。生成されたアプリは試作品として扱い、実際の利用者に気軽にさらさない。結論は、これを「コード生成の品質だけに頼らず、作業の流れ全体のセキュリティ問題として扱うべきだ」とまとめています。

原文を読むための道具：対訳表と、AIへの頼み方

論文に出てくる英語用語の対訳

vulnerability

脆弱性。攻撃に使える弱点。

exploitability

悪用可能性。実際に攻撃として成立するか。この論文は専門家2名がこれを確認したものだけを数えている。

false positive

偽陽性、誤報。脆弱性でないものを脆弱性と報告すること。

false negative

偽陰性、見逃し。脆弱性があるのに報告しないこと。

severity

深刻度。Critical（致命的）、High（高）、Medium（中）、Low（低）の4段階。

prevalence

広がり、発生率。「何件中何件にあるか」。

trust boundary

信頼境界。信頼できる領域とできない領域の境目。第8章の図で描いた線。

authentication

認証。本人確認。「誰か」を確かめる。

authorization

認可。「何をしてよいか」を確かめる。access control（アクセス制御）とほぼ同義で使われる。

sanitization

無害化。入力から危険な部分を取り除く処理。escaping（エスケープ）は表示時に記号を文字に変える処理で、近いが別物。

injection

インジェクション。入力が命令として解釈されること。

misconfiguration

設定の不備。

recall

再現率。見つけるべきもののうち何割を見つけたか。Juice Shopでの95.70%がこれ。

inter-rater agreement

評価者間一致。Cohen's κ（カッパ）で測る。

reintroduction rate

再発率。同じ機能を作り直したとき、同じ脆弱性がまた入る割合。

harness

ハーネス。AIエージェントを動かす枠組み（道具、手順、追加知識）。hardened harness は守りを強めた枠組み。

prototype

試作品。著者は生成されたアプリをこれとして扱うよう勧めている。

AIに論文を読ませるときの頼み方

丸ごと要約させると、数字が丸められ、主張と根拠の区別が消えます。節ごと、図表ごとに、「主張」と「根拠」を分けて出させます。

添付した論文（arXiv:2606.23130 v4）を、次のルールで読む手伝いをしてください。

1. 節ごとに要約してください。一度に1節だけ扱い、私が「次」と言うまで先に進まないでください。
2. 各節について、「著者の主張」と「その根拠（数字、図表番号、実験条件）」を分けて箇条書きにしてください。根拠がない主張には「根拠の記載なし」と書いてください。
3. 図表は、番号ごとに「何と何を比べているか」「軸や列の意味」「読み取れる一文」の3点で説明してください。
4. 数字は論文に書かれたとおりの桁で引用し、丸めないでください。論文にない数字を補わないでください。
5. 専門用語が出たら、初出時に日本語の対訳と一文の説明を添えてください。
6. 分からない箇所は推測で埋めず、「原文の該当箇所を確認してください」と書いて、節と段落の位置を示してください。

まず第3節（Dataset Construction）から始めてください。

方法の節から読ませると、AIが「要約の要約」に流れるのを防げます。出てきた数字は、必ず原文の表と突き合わせてください。