AppleがVibe Codingアプリを拒否し始めた。
2026年3月18日、9to5Macが報じた。Replit、Vibecodeをはじめとする複数のVibe Codingアプリが、App Storeのアップデート審査で制限を受けている。
Appleが引用したのは、App Storeガイドライン2.5.2。「アプリはダウンロードしたコードを介して、アプリの機能を変更してはならない」——つまり、ユーザーがアプリ内でコードを生成し、それをそのまま実行する仕組みはNGだということだ。
このニュースを見て、私は「ついに来たか」と思った。
なぜ「ついに来たか」なのか
私はプロジェクトマネージャーとして、AI開発を日常的に行っている。Claude Codeでクライアントのシステムを構築し、117万メッセージ以上のAI対話を重ねてきた。5つの商用プロジェクトを並行運用し、月額3万円のAIチームで回している。
以前、Vibe Codingの先へ｜個人開発と商用開発の決定的な違いという記事を書いた。「コーディングの工程は同じ。その前後の設計・テスト・レビュー・インフラが全く違う」という話だ。
あの記事を書いたとき、「結局AIでコード書いてるんでしょ？」という反応があった。
あれから1ヶ月。外部からの裏付けが次々と出てきた。
データが示すVibe Codingのリアル
感覚論ではない。2026年時点のデータを整理する。
セキュリティ：AI生成コードの45%に欠陥
Veracodeの2025年レポートによると、AI生成コードの45%にセキュリティ欠陥が含まれている。 Contrast Securityの調査では、XSS保護の失敗率が86%、ログサニタイズの失敗率が**88%**だ。
これは「たまに脆弱性がある」レベルではない。ほぼ半分が危険ということだ。
技術的負債：従来の3倍速で蓄積
Vibe Codingで作られたプロジェクトは、従来の開発手法と比較して3倍の速度で技術的負債が蓄積する。GitClearの分析では、AI普及後にリファクタリングを示す「コードの移動」が24.1%から9.5%に急落している。
つまり、書くのは速いが、整理しない。コードは増え続け、重複が積み上がり、一貫性のない命名規則が広がる。
デバッグ：63%の開発者がむしろ時間を取られている
開発者の63%がAI生成コードのデバッグにより多くの時間を費やしていると回答している。さらに、AI使用量が25%増加すると、デリバリー安定性が7.2%低下する。
速く書けるが、速く壊れる。 そして壊れたものを直すのに、書いた時間より長くかかる。
パッケージ・ハルシネーション：新種のサプライチェーン攻撃
AIが存在しないライブラリ名を提案する。攻撃者がその名前で悪意あるパッケージをNPMやPyPIに登録する。開発者が無意識にインストールする。
PoC調査では、ダミーパッケージが3ヶ月で3万回以上ダウンロードされたと報告されている。Vibe Codingでは、AIの出力をそのまま実行する。この攻撃との相性は最悪だ。
Appleの判断は「品質ゲート」そのもの
Appleの審査拒否を、「Appleが厳しすぎる」と批判する声もある。
しかし、プロジェクトマネジメントの視点で見ると、**Appleがやっていることは「品質ゲート」**だ。
品質ゲートとは、次の工程に進む前に、一定の品質基準を満たしているかをチェックする仕組みだ。PMBOKでは「品質コントロール」の一環として定義されている。
- コードが動くか？ → 機能テスト
- セキュリティは担保されているか？ → セキュリティレビュー
- ガイドラインに準拠しているか？ → コンプライアンスチェック
App Storeの審査は、まさにこの品質ゲートだ。Vibe Codingには、この仕組みが内在していない。 だから外部のゲート（Appleの審査）に引っかかる。
エンタープライズが慎重な理由
データを見れば、企業が慎重になる理由がわかる。
| 業界 | Vibe Coding採用率 |
|---|---|
| ヘルスケア | 28% |
| 金融サービス | 34% |
| スタートアップ | 73% |
顧客データの重みを知っている業界ほど、採用率が低い。 ヘルスケアは患者データ、金融は取引データ——漏洩すれば企業の存続に関わる。
一方、スタートアップの73%が採用しているのは、スピード優先のフェーズだからだ。これ自体は合理的だが、プロダクトがスケールしたときに技術的負債のツケが回ってくる。
問題はAIではない。プロセスの欠如だ
ここで強調したい。AIが悪いのではない。
Appleが拒否しているのは「AIで生成されたコード」ではない。検証されていないコードが実行される仕組みだ。
むしろAIが品質を「上げた」経験がある
あるプロジェクトで、納期が明後日、人手はゼロという状況があった。深夜2時に1人でコードレビューをしていたとき、半ば自暴自棄でClaude Codeにセキュリティチェックを依頼した。5分後、「認証トークンの有効期限チェックが欠落している」という指摘が返ってきた。自分が3時間見落としていたセキュリティホールを、AIが5分で発見した。
Appleの審査で弾かれるVibe Codingアプリと、AIがセキュリティホールを防いだ私のプロジェクト。違いは何か。AIを使ったかどうかではなく、品質を検証するプロセスがあったかどうかだ。
私のチームでは、AIが書いたコードに対して必ず以下を実施する。
- 設計書との照合 — AIの出力が要件を満たしているか
- セキュリティレビュー — 認証・入力バリデーション・SQLインジェクション対策
- テストの検証 — テスト自体がビジネスロジックを正しく検証しているか
- 依存パッケージの確認 — 存在しないライブラリや悪意あるパッケージがないか
AIの出力速度 × 人間の検証品質。 この掛け算が、Appleの審査に弾かれない、プロダクション品質のAI開発の本質だ。
R&D時間の半分が負債処理に消える未来
もう1つ、経営視点で見逃せないデータがある。
- **R&D時間の30-50%**がレガシーコード保守に費やされている
- **IT予算の41%**が技術的負債管理に割り当てられている
- レガシーコード1行あたりの平均修正コスト：$3.60（CISQ）
Vibe Codingで3倍速く負債が蓄積するなら、数年後にはR&D時間の大半が「直す」作業に消えることになる。
書くのは一瞬。しかし、その一瞬で生まれたコードを、何年も保守し続けるのは人間だ。
私の開発フローが変わらない理由
Appleのニュースを見ても、私のフローは変わらない。なぜなら、最初から品質ゲートを組み込んでいるからだ。
要件定義（人間×人間）
↓
基本設計（人間主導）
↓
詳細設計（人間×AI）
↓
実装（AI主導 + 品質ゲート）
↓
レビュー（人間主導 + 設計書照合）
Vibe Codingは「実装」の部分だけを取り出したもの。 Appleが問題視しているのも、まさにこの部分だ。生成されたコードが検証なしに実行される仕組み——前後の工程が存在しない。
逆に言えば、前後の工程を入れれば、AI開発は極めて強力な武器になる。 実際に私は5つの商用プロジェクトを1人で並行運用しているが、Appleに弾かれるような品質事故は起きていない。設計書があり、テストがあり、レビューがあるからだ。
スキル・ロットという静かな脅威
最後に、あまり語られないリスクを1つ。
スキル・ロット ——エンジニアの基礎体力が衰える現象だ。
デバッグや論理構築をAIにアウトソーシングし続けると、人間側の能力が低下する。AIが生成したコードの誤りを見抜く力、アーキテクチャを俯瞰する力が失われていく。
AI生成コードの45%に脆弱性がある。その脆弱性を見抜くのは人間だ。しかし、その人間がスキル・ロットで判断力を失っていたら？
品質ゲートは仕組みだが、仕組みを運用するのは人間の判断力だ。AIを使いこなすほど、人間のスキルメンテナンスが重要になるという逆説がある。
まとめ：速さと品質は対立しない
Appleの審査拒否は、Vibe Codingの「終わり」ではない。**品質管理の「始まり」**だ。
- AI生成コードの45%に脆弱性 → 検証プロセスで防げる
- 技術的負債が3倍速で蓄積 → 設計とリファクタリングの仕組みで制御できる
- デバッグに時間がかかる → テスト設計を先にやれば減らせる
速さと品質は対立しない。 速さに品質を掛け合わせるのが、プロフェッショナルのAI開発だ。
Appleの判断は正しい。ただし、拒否すべきは「AIで書いたコード」ではなく、「検証なしに実行されるコード」だ。
問題はAIを使うか使わないかではない。プロセスがあるかないかだ。
私はこれからもAIでコードを書く。ただし、設計書を書いてから。テストを構造化してから。レビューを通してから。
AIの力を最大化するために、人間のプロセスを最大化する。 それがPMBOK-AIの核心であり、Appleの審査が改めて証明したことだ。
関連記事：
- Vibe Codingの先へ｜個人開発と商用開発の決定的な違い — 商用AI開発の5フェーズを詳解
- PMBOK-AIとは — AIをプロジェクトメンバーとして扱うフレームワーク
- 1人のPMが5案件を同時に回す方法 — Claude Code活用の実践例
AI開発やプロジェクトマネジメントについてのご相談はお問い合わせからお気軽にどうぞ。