高価なモデルがなぜ安いのか

TL;DR

最も高性能な AI モデルは タスク単価が 60% 安い です — トークン単価が 67% 高いにもかかわらず — トークン消費量が少なく、反復回数が少なく、エラーが 50〜75% 少ないからです。コードを読めないバイブコーダーにとって、モデルの品質は効率の問題ではありません — パイプライン全体で唯一の安全網です。

最終確認: 2026 年 2 月

この記事のベンチマークスコア、モデル名、価格は 2026 年 2 月時点のフィールドの状態を反映しています。コアの議論 — タスク単価はトークン単価より重要 — は具体的な数字が変わっても耐久性があります。

最も高価な AI コーディングモデルは、実際に重要なことを測定するとほぼ常に最も安い選択肢です。トークン単価は気を散らすものです。実際のコストを決定するのは 仕事を完了するのに何トークンかかるか、どれだけの反復を費やすか、そして出力のレビューと修正にどれだけの時間がかかるかです。

プライシングの幻想

Claude モデルの API の価格を見てみましょう:

モデル	入力（100 万トークンあたり）	出力（100 万トークンあたり）
Claude Opus 4.5	$5	$25
Claude Sonnet 4.5	$3	$15

Opus は 67% 高く見えます。ほとんどの人はここで止まって Sonnet を選びます。それは間違った計算です。

実際に起こること

Anthropic のベンチマークは別の話を教えてくれます。中程度の努力で、Opus 4.5 は 76% 少ない 出力トークンを使用しながら、Sonnet 4.5 の最高 SWE-bench スコアに 一致します。最高努力では、Opus は 48% 少ないトークン を使用しながら Sonnet を 4.3 ポイント 上回ります。^[1]

実際の計算をしてみましょう:

	Sonnet 4.5	Opus 4.5
タスクあたりの出力トークン	約 500	約 120
100 万出力トークンあたりの価格	$15	$25
タスクあたりコスト	$0.0075	$0.0030

Opus は タスク単価が 60% 安い — トークン単価が 67% 高いにもかかわらずです。^[2]

これは意図的に選んだ例ではありません。長期間のコーディングタスクで、Opus はより高いパス率を達成しながら 最大 65% 少ないトークン を使用し、50% 少ないツール呼び出し を行います。^[1:1]

反復税

トークンコストは話の一部にすぎません。より大きなコストは 反復 — 正しいコードを得るためにどれだけの生成-レビュー-修正のラウンドがかかるか — です。

Opus 4.5 は 4 回の反復 でピークパフォーマンスに達します。競合モデルは同様の品質を達成するために 最大 10 回の試行 が必要です。^[1:2] 各失敗した反復はコストがかかります:

• トークン — モデルがコンテキストを読み再度生成する
• 時間 — 出力をレビューし、問題を見つけ、再プロンプトする
• 注意 — 「これは正しいか?」と「何が悪いのか?」の間のコンテキストスイッチ

開発者レートが$75/時間の場合、レビューと修正に15分かかる失敗した反復は $18.75 の人件費がかかります。6 回の余分な反復（4 回と 10 回の差）は $112.50 の開発者時間コストになります — 複雑なタスクごとに。トークンコストの差は? 約半セント。^[3]

開発者の時間節約はトークンコスト差の 22,500 倍の価値があります。

エラー乗数

安価なモデルは反復が多いだけでなく — 本番環境に生き残るエラーをより多く生み出します。

Opus 4.5 はツール呼び出しエラーとビルド/lint エラーの両方で他のモデルに比べて 50〜75% の削減 を示します。^[1:3] これは重要です。コーディングセッションから逃れたエラーは下流でより高いコストになるからです:

• コーディング中に発見されたバグは修正に数分かかる
• コードレビューで発見されたバグは 1 時間かかる（あなた + レビュアーの時間）
• 本番環境で発見されたバグは数日かかる（デバッグ、ホットフィックス、コミュニケーション、事後分析）

Faros AI の研究 — 1,255 チームと 10,000 以上の開発者をカバー — では、AI の高い採用が開発者あたり 9% のバグ増加 と PR レビュー時間の 91% 増加 に相関していることが判明しました。^[4] AI がより低い精度でより多くのコードを生成すると、レビューのボトルネックが「生産性」向上を完全に吸収します。

最初のパスで正しいモデルはこのカスケードを回避します。

SWE-bench の証拠

SWE-bench Verified は、実際のソフトウェアエンジニアリングタスクで AI のコーディング能力を評価するための業界標準です。2026 年 2 月のリーダーボード:^[5]

モデル	SWE-bench Verified
Claude Opus 4.5	80.9%
Claude Opus 4.6	80.8%
GPT-5.2	80.0%
Gemini 3 Flash	78.0%
Claude Sonnet 4.5	77.2%
Gemini 3 Pro	76.2%

Opus 4.5 と Sonnet 4.5 の 3.7 ポイントの差は、Opus が Sonnet が失敗する 約 1/27 の追加タスク を解決することを意味します。これらの各失敗が手動デバッグセッションを引き起こすとき、コストは急速に積み重なります。

しかしここに本当のポイントがあります — 研究者がトークンあたりのコストではなく タスクあたりのコスト を測定したとき、Opus はソネットより安かったです:

モデル	タスクあたりのコスト	SWE-bench スコア
Claude Opus 4.5	約 $0.44	80.9%
Claude Sonnet 4.5	約 $0.50	77.2%

Sonnet は タスクあたりのコストが高い にもかかわらず より少ないタスクを解決します。^[6]

Codex CLI: 同じパターン、異なるベンダー

OpenAI の Codex CLI は推論努力レベルで同じダイナミクスを示します:

• 中程度の推論: バランスの取れた速度と知性 — デフォルト
• 超高（xhigh）推論: より長く考え、より良い答えを出す — 難しいタスクに推奨

GPT-5.1-Codex-Max は中程度の努力で、30% 少ない思考トークン を使用しながら同じ努力の標準 GPT-5.1-Codex を上回ります。^[7] プレミアムモデルはより上手く推論するためにより多くのトークン効率があります — 正しい答えに到達するためにそれほど多くの中間ステップを生成する必要がありません。

このパターンはベンダーを横断して普遍的です: 賢いモデルはコンピューティングを無駄にしません。

METR の警告

METR のランダム化比較試験は重要な警告の話を提供します。16 人の経験豊富な開発者（$150/時間）が 246 タスクで AI ツールを与えられました。結果: 開発者は AI 支援で 19% 遅く なりました。さらに顕著なのは — 開発者は 20% 速くなったと信じており、知覚のギャップは約 39 パーセンテージポイントでした。^[8]

研究では Sonnet クラスのモデル（Cursor Pro 経由の Claude 3.5/3.7 Sonnet）を使用していました。AI 生成コードの 44% 未満しか受け入れられませんでした。

これは品質の閾値が非常に重要であることを示唆します。コードを 44% しか受け入れないモデルはあなたを遅くします — レビューと拒否に節約以上の時間を費やします。エラーが 50〜75% 少なく、初回パスの精度が劇的に高いモデルはこの方程式を逆転させる可能性があります。

METR の研究は AI コーディングツールが遅いことを示していません。凡庸な AI コーディングツールが遅いことを示しています。

テクニカルデット: カウントしていない 75%

コードを書く最初のコストはライフサイクル全体でのソフトウェアコストの 15〜25% にすぎません。残りの 75〜85% は保守、運用、バグ修正に費やされます。^[9]

GitClear の 2020〜2024 年のコード分析では、AI ツールの採用と相関して 重複コードブロックが 8 倍増加 し、コードチャーンが 2 倍増加 していることが判明しました。SonarSource は、Claude Sonnet 4 の出力をその前身と比較したとき BLOCKER レベルのバグが 93% 増加 していることを発見しました。^[10]

安価なモデルが深刻なバグレートが 2 倍近いコードを生成し、保守がライフサイクルコストの 75〜85% を消費するなら、コード生成での「節約」は下流のコストによって圧倒されます。保守が最も安いコードは最初から正しかったコードです。

サブスクリプションの計算

ヘビーユーザーにとって、サブスクリプション対 API の選択はモデル品質の議論をさらに増幅します。

プラン	月額コスト	得られるもの
Claude Max ($100)	$100	高い Opus 使用量
Claude Max ($200)	$200	無制限 Opus
同等の API 使用	$3,650+	同じ Opus トークン

サブスクリプションは同じ作業の API の請求より 約 18 倍安い です。^[11] サブスクリプション価格では、最高モデルを使用するための限界コストはゼロです — 「高価な」モデルが追加クエリごとに文字通り無料になります。

サブスクリプションでの Claude Code の平均コスト: 開発者 1 人あたり 1 日$6、90%のユーザーが$12/日以下です。^[12] 開発者給与 $75/時間で、1 日 5 分の時間節約 でサブスクリプションの元が取れます。それを超えるものはすべて純粋な利益です。

複合議論

なぜ計算が時間とともにさらに偏るのか:

1. 反復が少ない = コンテキスト汚染が少ない

各失敗した試行は会話履歴に追加されます。長い会話はモデルのパフォーマンスを低下させます — 信号対ノイズ比が低下します。4 回の反復で成功するモデルは 10 回で迷走するものより、クリーンなコンテキストを持ちます。つまり、後の応答も良くなります。

2. エラーが少ない = レビュー疲労が少ない

GitHub Copilot の Productivity 研究では、タスクの難易度とともにメリットが増加することが判明しました。^[13] 難しいタスクは安価なモデルが最も失敗する場所であり — 高価なモデルが輝く場所です。ZoomInfo のケーススタディでは、AI を用いた 40〜50% の生産性向上 が示されており、複雑さが増すにつれてギャップが広がります。

3. 良いコードは良い学習につながる

スキルを伸ばしている開発者（そしてすべての開発者がそうあるべきです）にとって、読むコードが本能を形成します。一貫して正しく、よく構造化された AI 出力を読むことは良いパターンを教えます。バグの多い冗長な出力を読むことは悪い習慣を教えます。

4. 正しいコードはより速く出荷される

不要な反復はなくなり、機能がより早く出荷されます。競争の激しい市場では、生成されたトークンではなく提供された機能で測定される開発スピードが重要です。

バイブコーダーにとって、これはコストの問題ではなく生存の問題

上記はすべて、diff を読み、バグを見つけ、壊れたコードを修正できるプロのエンジニアに当てはまります。しかし、モデル品質の議論が効率ではなくソフトウェアが動くかどうかの問題である急速に成長しているグループがあります。これらは 100% バイブコーダー: 非プログラマーで、生成されたコードの 1 行も読んで、監査し、理解できずに、自然言語プロンプトだけで本物のアプリケーションを構築している人たちです。

見えないリスク

プロの開発者にとって、バグの多いコードを生成する安価なモデルは 煩わしい — レビューでバグを見つけ、修正して進みます。非プログラマーにとって、同じバグは 見えません。それは検出されずに本番環境に出荷されます。

この問題の規模は驚異的です:

• Veracode は 100 以上の LLM で 100 以上のタスクをテストし、AI 生成コードが 45% のタスク にセキュリティの欠陥を導入することを発見しました。Java が最悪で 70% 以上。重要なことに、より新しくより大きなモデルはセキュリティの大幅な改善を示しませんでした — 問題は構造的であり世代的ではありません。^[14]
• CodeRabbit は 470 のオープンソース PR を分析し、AI 作成コードが人間のコードより 1.7 倍多い主要な問題 と 1.4 倍多い重大な問題 を持つことを発見しました。ロジックエラーは 75% 高く、パフォーマンスの問題（過剰な I/O）は 8 倍も多く、セキュリティの脆弱性は 1.5〜2 倍高い。^[15]
• BaxBench と NYU の研究では、AI 生成コードの 40〜62% にセキュリティの欠陥が含まれていることが確認されています — クロスサイトスクリプティング、SQL インジェクション、入力検証の欠落 — アプリをクラッシュさせずにすべてのユーザーのデータを静かに公開するような脆弱性です。^[16]

プロの開発者はこれらのパターンを認識します。バイブコーダーはそれらが存在することを知りません。

現実の大惨事

これは理論的ではありません。2025 年、セキュリティ研究者の Matt Palmer は、Lovable — 人気のバイブコーディングプラットフォーム — で構築された 1,645 のアプリケーションのうち 170 がデータベースのセキュリティを致命的に誤設定していたことを発見しました。インターネット上の誰でもデータベースに読み書きできました。公開されたデータには氏名、メールアドレス、電話番号、自宅の住所、個人の借金額、API キーが含まれていました。^[17]

Escape.tech はさらに進んで、Lovable、Base44、Create.xyz、Bolt.new を含むプラットフォームで公開デプロイされた 5,600 以上のバイブコーディングアプリ をスキャンしました。2,000 以上の脆弱性、400 以上の公開シークレット、医療記録、IBAN、電話番号を含む 175 件の公開 PII を発見しました。^[18]

これらは開発者のエラーではありませんでした。開発者 — そう呼べるなら — は脆弱性が存在することを知りませんでした。AI にアプリを作るよう頼み、アプリは動作するように見え、デプロイしました。セキュリティの欠陥はコードを読めない人には見えませんでした。

サプライチェーンの罠

非コーダーは経験豊富な開発者でも捉えにくい脅威に直面しています: スロップスクワッティング。AI モデルはパッケージ名を幻覚します — コードサンプルの約 20% が存在しないパッケージを参照しています。攻撃者はこれらのファントムパッケージ名を登録してマルウェアを注入します。バイブコーダーの AI がパッケージのインストールを提案すると、マルウェアがアプリケーションに自動的に入ります。^[19]

開発者は見慣れないパッケージ名に気づいて確認するかもしれません。バイブコーダーは AI が言うものを何でもインストールします。何が正当で何が幻覚かの参照フレームがありません。

モデル品質が唯一の安全網である理由

Palo Alto Networks の Unit 42 研究チームは明確に述べています: 市民開発者 — 開発背景のない人々 — は「セキュアなコードの書き方のトレーニングを受けておらず、アプリケーションライフサイクルで必要なセキュリティ要件を十分に理解していない可能性がある」。彼らの調査では、バイブコーディングされたアプリケーションに直接起因する実際のデータ漏洩、認証バイパス、任意コード実行が発見されました。^[20]

プロの開発者にとって、コードレビュー、テスト、セキュリティ監査が安全網として機能します。それらはモデルが見落とすものを捉えます。バイブコーダーには これらの安全網がありません。読めないコードをレビューできません。理解していない動作のテストを書けません。聞いたこともないセキュリティプロパティを監査できません。

これは AI モデル自体がパイプライン全体で 唯一の 品質管理であることを意味します。モデルが導入するすべての欠陥は直接ユーザーに出荷されます。セカンドチャンスも、人間のチェックポイントも、安全網もありません。

そしてこれがまさにモデル品質が最も重要な場所です:

• Opus は安価なモデルより 50〜75% 少ないエラーを生み出します。^[1:4] エラーを捉える能力がゼロのバイブコーダーにとって、これは動作するアプリと静かにユーザーデータを漏洩するアプリの違いです。
• Opus は 4 回の反復でピークパフォーマンスに達します、10 回ではなく。^[1:5] 余分な各反復は、バイブコーダーが自然言語で問題を説明しなければならないことを意味します（間違っている行を指摘できません）、AI が理解することを望み、修正が見えない新しいバグを導入しないことを願います。
• Opus は最先端モデルの中でプロンプトインジェクションへの最高の耐性を持ちます — バイブコーダーが自身でサニタイズできないユーザー入力を処理するアプリを構築するときに重要です。
• Opus はタスクあたりより少ないトークンを使用します。つまり同じ目標を達成するためのコードが少なく — コードが少ないと攻撃面が少なく、誰も読まないコードにバグが隠れる場所が減ります。

開発者にとって、安価なモデルは生産性税です。バイブコーダーにとって、安価なモデルは 責任 です。モデルはアシスタントではなく エンジニアリングチーム全体 です。作業をチェックする能力が全くないときに最も安い「エンジニア」を雇うのは節約ではありません。無謀です。

非コーダーのための本当の決定

コードが読めない場合、安価なツールと高価なツールの間で選んでいるのではありません。次のどちらかを選んでいます:

1. 55% の時間しかセキュリティを正しく処理しないモデル（残りの 45% については決して知りません）
2. 80% 以上の時間でセキュリティを正しく処理するモデル（ビジネスを破壊する静かな見えないバグをはるかに少なく生み出す）

トークンあたり 67% の価格プレミアムは、読めないコードに構築され、実際のユーザーにデプロイしたアプリケーションでのデータ漏洩のコストの前では無意味です。

バイブコーダーにとって、高価なモデルは安い選択肢ではありません。唯一の責任ある選択肢です。

意思決定フレームワーク

あなたが...	使うべき	理由
毎日何時間もコーディングする	Opus + サブスクリプション	限界コストゼロ、最高品質
複雑なタスクを行う	Extra-high / Opus	反復が少なく、バグが少ない
長期間維持するコードを書く	利用可能な最高のモデル	テクニカルデットが本当のコスト
コードを読まずにバイブコーディングする	Opus — 交渉の余地なし	モデルが唯一の安全網
予算が限られている	それでもサブスクリプションで Opus	$200/月 < 安価な出力のデバッグコスト
素早い一回限りのクエリを実行する	Sonnet / 中程度の努力	シンプルなタスクでは品質の閾値があまり重要ではない

安価なモデルが勝つ唯一のシナリオは どのモデルでも最初の試行で成功する些細なタスク です。他のすべてのことに対して — これが実際のソフトウェアエンジニアリングのほとんどです — 高価なモデルが安い選択肢です。

結論

トークンあたりの価格はバニティメトリクスです。タスク単価が本当のメトリクスです。そしてタスクあたりでは、最も高性能なモデルが一貫して勝ちます — 小さな差ではなく、倍数で:

• タスクあたり 60% 安い（少ないトークン）
• ピークパフォーマンスまでの反復が 60% 少ない
• エラーが 50〜75% 少ない
• トークンコスト差よりも開発者の時間節約が 22,500 倍 価値がある

最も高価なモデルは贅沢品ではありません。時間を大切にするすべての人にとっての最低限の選択肢です。

---

1. Anthropic (2025). Introducing Claude Opus 4.5. 主な発見: 中程度の努力で、Opus 4.5 は 76% 少ない出力トークンを使用しながら Sonnet 4.5 の最高 SWE-bench スコアに一致; 最高努力では、Opus は 48% 少ないトークンを使用しながら Sonnet を 4.3 ポイント上回る; ツール呼び出しとビルド/lint エラーが 50〜75% 削減; ピークパフォーマンスは競合他社の最大 10 回に対して 4 回の反復で達成。 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

2. claudefa.st (2025). Claude Opus 4.5: 67% Cheaper, 76% Fewer Tokens. トークン単価プレミアムがタスクあたりの劇的に低いトークン消費によって十分に相殺されることを示す分析。ほとんどのワークロードで Opus がより費用対効果の高い選択肢であることを示す。 ↩︎

3. Glassdoor の開発者給与データ（2025）: 米国ソフトウェア開発者の平均給与$121,264〜$172,049/年。$75/時間で、失敗した反復ごとのレビュー/修正の15分 = 人件費$18.75。6 回の余分な反復（4 回と 10 回の差）= 複雑なタスクあたり $112.50。参照: Glassdoor Software Developer Salary. ↩︎

4. Faros AI (2025). The AI Productivity Paradox. 1,255 チームと 10,000 以上の開発者の研究: 高 AI チームの個別の開発者は 21% 多くのタスクを完了し、98% 多くの PR をマージするが、PR レビュー時間は 91% 増加し、バグは開発者あたり 9% 増加し、PR サイズは 154% 増加した。AI 採用と会社レベルのパフォーマンス向上の間に有意な相関はなかった。 ↩︎

5. SWE-bench Verified リーダーボード、2026 年 2 月。marc0.dev、llm-stats.com、The Unwind AIから集計。Claude Opus 4.5 は SWE-bench Verified で 80% を超えた最初のモデルでした。 ↩︎

6. JetBrains AI Blog (2026). The Best AI Models for Coding: Accuracy, Integration, and Developer Fit. トークン消費と成功率を組み込んだ複数モデルにわたるタスクあたりのコスト分析。 ↩︎

7. OpenAI (2025). GPT-5.1-Codex-Max; Codex Prompting Guide. Codex-Max は中程度の推論努力で 30% 少ない思考トークンを使用しながら同じ努力の標準 Codex を上回ります — プレミアムモデルは本質的にトークン効率が高い。 ↩︎

8. METR (2025). Measuring the Impact of Early 2025 AI on Experienced Open-Source Developer Productivity. 無作為化比較試験: 16 人の経験豊富な開発者、246 タスク、$150/時間の報酬。AI 支援開発者は 19% 遅かった。開発者は 24% のスピードアップを期待し、事後に 20% 速かったと信じていた — 約 39 パーセンテージポイントの知覚ギャップ。AI 生成コードの 44% 未満が受け入れられた。参照: arXiv:2507.09089. ↩︎

9. ソフトウェアライフサイクルコストに関する業界データは一貫して保守を総コストの 60〜80% に置いています。参照: Sommerville, I. (2015). Software Engineering, 10th ed., Chapter 9。参照: MIT Sloan: The Hidden Costs of Coding with Generative AI. ↩︎

10. GitClear (2024). AI Code Quality Analysis: 重複コードブロックが 8 倍増加、コードチャーンが 2 倍増加（2020〜2024）。SonarSource (2025): AI 生成コードの分析では、すべてのモデルでセキュリティ意識の体系的な欠如が判明し、Claude Sonnet 4 は BLOCKER レベルのバグの割合がほぼ 2 倍 — 重大なバグ導入率が 93% 増加。参照: DevOps.com: AI in Software Development. ↩︎

11. Level Up Coding (2025). Claude API vs Subscription Cost Analysis. 継続的なコーディングセッションでサブスクリプションが API の請求より約 18 倍安いことを示す比較。 ↩︎

12. The CAIO (2025). Claude Code Pricing Guide. Claude Code の平均コスト: サブスクリプションプランで開発者 1 人あたり 1 日$6、90%のユーザーが$12/日以下。 ↩︎

13. Peng, S. et al. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. ラボ研究: 開発者は Copilot で 55.8% 速くタスクを完了。参照: ZoomInfo のケーススタディでは 40〜50% の生産性向上が示されており、タスクの難易度とともにギャップが大きくなる（arXiv:2501.13282）。 ↩︎

14. Veracode (2025). 2025 GenAI Code Security Report. 100 以上の LLM にわたる 80 のコーディングタスクの分析: AI 生成コードが 45% のケースにセキュリティの欠陥を導入。Java が最悪で 70% 以上、Python/C#/JavaScript は 38〜45%。より新しくより大きなモデルはセキュリティで大幅な改善を示さなかった。参照: BusinessWire announcement. ↩︎

15. CodeRabbit (2025). State of AI vs Human Code Generation Report. 470 のオープンソース GitHub PR（320 の AI 共同作成、150 の人間のみ）の分析: AI コードは 1.7 倍多い主要な問題、1.4 倍多い重大な問題、75% 多いロジックエラー、1.5〜2 倍多いセキュリティ脆弱性、3 倍多い可読性問題、ほぼ 8 倍多いパフォーマンス問題（過剰な I/O）を持つ。参照: The Register coverage. ↩︎

16. BaxBench と NYU の AI コードセキュリティに関する研究。参照: Tihanyi, N. et al. (2025). Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks. BaxBench はバックエンドコーディングシナリオと専門家設計のセキュリティエクスプロイトを組み合わせ、AI 生成コードの 40〜62% に XSS、SQL インジェクション、入力検証の欠落を含むセキュリティの欠陥が含まれていることを発見。 ↩︎

17. Palmer, M. (2025). Statement on CVE-2025-48757. 1,645 の Lovable 構築アプリの分析: 170 が Row Level Security を致命的に誤設定し、未認証でユーザーデータベースへの読み書きアクセスを許可。公開された PII には氏名、メール、電話番号、自宅の住所、個人の借金額、API キーが含まれていた。参照: Superblocks: Lovable Vulnerability Explained. ↩︎

18. Escape.tech (2025). The State of Security of Vibe Coded Apps. Lovable、Base44、Create.xyz、Bolt.new などのプラットフォームで公開デプロイされた 5,600 以上のバイブコーディングアプリケーションのスキャン。2,000 以上の脆弱性、400 以上の公開シークレット、医療記録、IBAN、電話番号を含む 175 件の公開 PII を発見。参照: Methodology detail. ↩︎

19. Lanyado, B. et al. (2025). AI-hallucinated code dependencies become new supply chain risk. 16 のコード生成 AI モデルの研究: 756,000 のコードサンプルの約 20% が存在しないパッケージを推薦。幻覚されたパッケージの 43% がクエリにわたって一貫して繰り返され、悪用可能にしている。オープンソースモデルは 21.7% で幻覚; 商業モデルは 5.2%。参照: HackerOne: Slopsquatting. ↩︎

20. Palo Alto Networks Unit 42 (2025). Securing Vibe Coding Tools: Scaling Productivity Without Scaling Risk. 現実のバイブコーディングセキュリティインシデントの調査: データ漏洩、認証バイパス、任意コード実行。市民開発者は「セキュアなコードの書き方のトレーニングを受けておらず、アプリケーションライフサイクルで必要なセキュリティ要件を十分に理解していない可能性がある」と指摘。SHIELD ガバナンスフレームワークを導入。参照: Infosecurity Magazine coverage. ↩︎