数千のアプリをApp Storeに公開してきたスタートアップが、2026年3月に削除された。バイブコーディングアプリ「Anything」の話だ。
削除の理由を一行で言うと、「Appleが審査していないコードをiPhone上で動かしていたから」になる。だが、この説明だけでは「じゃあ自分が作るときはどうすればいいのか」が見えてこない。ここでは「Anything」が何をしていて、なぜ問題になったのかを、プログラミングの知識がなくても分かる形で順番に解説する。
「Anything」とは何だったか
Anythingは2025年9月、1,100万ドル（約16億円）をバリュエーション1億ドルで調達した。リード投資家はFootwork、Uncork・Bessemer・M13が参加した。
派手な数字はそれだけではない。ローンチから2週間で年換算売上200万ドル（$2M ARR）を達成した。非エンジニアが自然言語でWebアプリやモバイルアプリを作れるフルスタックプラットフォームとして登場し、「バイブコーディングの寵児」と呼ばれた。
2025年11月にiOSアプリとしてリリースされ、審査を通過した。習慣トラッカー、CPRトレーニング、ヘアスタイル試着アプリなど、Anythingを通じて数千のアプリがApp Storeに公開された。
ここまでは成功の物語だ。
2025年12月、静かなブロックが始まった
Anythingがリリースされてから1ヶ月後、Appleはアップデートをブロックし始めた。同時期にReplit・VibecodeのiOSアプリも更新が止まった。
Appleは表立って何も言わなかった。外側からは何も変わっていないように見えた。だが内側では、3ヶ月かけて静かに圧力がかかり続けた。
Anythingの共同創業者Dhruv Aminは、アプリ内でコードを表示するのではなくブラウザプレビューに変更する形でAppleに再申請を試みた。Appleはその申請もブロックし、そのまま2026年3月末に「Anything」をApp Storeから削除した。
Appleは削除前に「2ヶ月で3回の電話」を行い、ガイドライン違反を説明していたと主張している。
Guideline 2.5.2——「アプリは自分だけで完結せよ」
Appleが根拠として挙げたのがGuideline 2.5.2だ。公式の条文はこうなっている。
"Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the app completely viewable and editable by the user."
英語なので平易に訳す。
「アプリは自分のパッケージの中だけで完結しなければならない。アプリの機能を変えるようなコードをダウンロード・インストール・実行してはいけない。ただし、コードを学習・開発・テストするための教育アプリは、限られた条件の下でコードをダウンロードできる。その場合、コードはユーザーに完全に表示・編集可能でなければならない。」
要するに、「App Storeの審査を通過していないコードをiPhone上で動かすな」ということだ。
なぜバイブコーディングアプリが引っかかるのか
バイブコーディングアプリの内部動作を分解すると、問題が見えてくる。
❌ Guideline 2.5.2 違反の構造（Anythingがやっていたこと）
1. ユーザーが「習慣トラッカーを作って」と入力
2. AIがコードを生成（このコードはAppleが審査していない）
3. アプリ内のWebViewでそのコードを実行・表示
↑
Appleが見たことのないコードが数億台のiPhoneで動く
✅ Guideline 2.5.2 を通過できる構造
1. ユーザーが「習慣トラッカーを作って」と入力
2. AIがコードを生成
3. Safariを開いてプレビュー（アプリの外なので規制対象外）
↑
iOSアプリとしては動いていない。ブラウザの話
出版に例えると分かりやすい。Appleは本を出版前に内容を審査する出版審査機関だとする。App Storeに申請して審査を通過した本だけを店頭に並べられる。
Anythingがやっていたのは「審査を通った本」の中に、あとから別の印刷物を追加で挟み込んで読者に渡すことだった。最初の審査とは関係のない内容が、知らないうちに本に含まれている状態だ。
Appleが問題にしているのはその「後から挟み込まれた部分」——つまりAIが生成して、Appleがレビューしたことのないコードが、実際のiPhone上で実行される点だ。
「アプリを作るアプリ」の本質的な問題はここにある。ユーザーが指示を出すたびに、Appleが審査したことのない新しいコードが生まれる。審査は申請時の1回だけ。以降はAppleのコントロール外で何でも動く。
教育アプリ例外——「Pythonista」はなぜ生き残るか
ガイドラインには例外がある。「コードを学習・開発・テストするための教育アプリ」だ。Pythonista（Pythonコードを書いて実行するアプリ）やApple自社のSwift Playgroundsがこれに当たる。
だがこの例外には条件が3つある。
✅ 教育アプリ例外の3条件（すべて満たす必要がある）
条件1: 教育目的（コードの学習・開発・テストであること）
条件2: ソースコードがユーザーに「完全に表示・編集可能」であること
条件3: そのコードが「他の目的に使われない」こと
→ バイブコーディングアプリは条件2を満たせても
「他の目的（実際のアプリを作って動かす）に使われている」ので
条件3でアウトになる
Swift Playgroundsは「コードを書いて学ぶ場所」だ。生成したアプリを配布したり、実際のサービスとして動かしたりしない。コードはユーザーの目の前にあり、学習のために書かれ、学習のためにだけ実行される。
バイブコーディングアプリは違う。ユーザーが「本当に使えるアプリ」を作ることを目的にしている。学習ではなく、実際のサービス開発が目的だ。その時点で教育アプリ例外の外に出る。
Xcode 26.3 との矛盾
2026年2月、AppleはXcode 26.3にClaudeとCodexを組み込んだ。AIがコードを生成してビルドしてテストする——いわゆるエージェントコーディングを、公式IDEに追加した。
「AppleがAIコーディングを禁じた」という文脈でこれを見ると、矛盾に思える。だがAppleの立場から見ると一貫している。
Xcodeで生成されたコードはAppleのビルドプロセスを通り、App Storeの審査を受けてからiPhoneに届く。AnythingのようなバイブコーディングアプリはApp StoreのレビューをスキップしてiPhone上でコードを実行する。この構造の違いが、Appleにとっての区別の根拠だ。
どこでAIを使うかではなく、Appleの審査を通るかどうかが問題になっている。
他のアプリはどうなったか
ReplitとVibecodeも同時期にアップデートブロックの対象になった。ただしAnythingとは異なる条件をAppleから提示された。
Replitはアプリ内WebViewでのプレビューをやめ、Safariで開く形式への変更を求められた。Vibecodeは、iOS向けアプリを生成する機能そのものを削除するよう求められた。
対照的に、WebアプリだけをターゲットにするLovable・Bolt・v0は影響を受けていない。App StoreでもなくiOSネイティブでもない、ブラウザで動くWebアプリを作るツールはGuideline 2.5.2の対象外だからだ。
バイブコーディングでiPhoneアプリを作りたい人への整理
この件が示していることを、作る側の視点で整理する。
iOSアプリをバイブコーディングで作って配布したい場合、構造として問題にならない方法は2つある。
ひとつ目は「ネイティブバイナリをビルドして審査に提出する」。Xcodeを通じてビルドし、App Storeの審査プロセスを経由する。Adalo・FlutterFlowはこのアプローチで今回の影響を受けていない。Appleが審査した上でインストールされるアプリになるため、2.5.2の対象外だ。
ふたつ目は「Webアプリとして作る」。iOSネイティブのアプリとして配布しない。ブラウザで開くURLとして提供する。App Storeを通らないため、Appleのガイドラインは関係ない。
問題になるのは「iOSアプリのフリをしてApp Storeに乗り込み、内部でAI生成コードを実行する」という構造だ。これはAnythingが示した通り、許可されない。
✅ iOSアプリを届ける方法（Guideline 2.5.2 対応）
方法A: ネイティブビルド路線
バイブコーディングツール → コード生成 → Xcodeでビルド
→ App Store申請・審査 → ユーザーのiPhoneに届く
例: Adalo、FlutterFlow を使ってビルドする
方法B: Webアプリ路線
バイブコーディングツール → Webアプリ生成
→ ブラウザのURLとして公開
例: Lovable、Bolt、v0 で作ったものをそのまま公開する
「App Storeで公開できる」とうたっているバイブコーディングツールを使う前に、どちらの方法でiPhoneに届けるかを確認すること。アプリ内でAI生成コードを実行する仕組みを使っている場合、将来的に更新停止・削除のリスクがある。
審査の一貫性という別の問題
この件には、もう一つの問題がある。
インドのバイブコーディングアプリ「Emergent」は、Anythingが削除されたのと同じ週にApp Store更新が承認された。2026年4月1日時点でApp Storeのデベロッパーツールカテゴリ1位に立っている。
Appleが「ルール違反」と説明する一方で、同種の仕組みを持つと見られるアプリが同週に承認されている。ルールの文面ではなく、Appleの裁量が結果を決めている面があることは否定しにくい。
これが示すのは「ガイドラインを守れば安全」ではなく「Appleの判断に最終的な権限がある」という事実だ。プラットフォームの上に乗っているということは、そのプラットフォームのルール変更・執行判断に常にさらされるということでもある。
「Anything」から学べること
Anythingは技術的に機能するものを作り、市場に受け入れられ、2週間で$2M ARRを達成した。それでも削除された。
問題はプロダクトの質ではなかった。構造だった。「iPhoneの上でコードを動かすアプリ」というアーキテクチャそのものが、Appleのプラットフォームポリシーと相容れなかった。
バイブコーディングで何かを作るとき、最初に問うべき問いがひとつある。「これはどのプラットフォームの上で動くのか」。Webブラウザの上なのか、App Storeを通じたiOSアプリなのか、macOSネイティブなのか。その問いへの答えが、後々の制約を決める。
Anythingが学んだことを、後から学ばなくていい。
