プログラミング未経験のまま、Claudeと一緒にアプリ開発を始めた。 壁打ちの末、AIが提案した技術スタックで進めて、2日後には全部捨てて別のスタックに乗り換えた。 ――この経験で、AI時代の個人開発に必要な意外なスキルを学びました。
↑前回の記事 では、Windows一台でiOSアプリを公開するまでの全体マップを共有しました。今回はその中で、初心者にとっての最大の山場、技術選定の話です。
はじめに包み隠さず言うと、僕はこの開発を始めるまでプログラミング経験はほぼ初心者でした。HTMLもCSSもJavaScriptも、一行も書いたことがない状態。強いて言えば、大学の研究でUnityでC#を表面的に扱ったくらい…。
そんな未経験者が、AI（Claude）と相談しながらFlutterでアプリを作り始めて、わずか2日でReact Nativeに乗り換えた話です。技術記事というより、「AIと一緒に開発する時代の新しいスキル」についての記事になります。
始まりは「とりあえず作ってみたい」
僕がアプリ開発を始めた動機は単純で、「こういうアプリがあったら欲しい。おもしろそう。」というアイデアを持っており、それを実際にカタチにしたみたかったからです。アイデア出しだけは得意なので、ネタ帳には既に数十個のアイデアがあるのですが、その中でも広範的に需要ありそうなものをピックアップしました。それが第1回で書いた、音を置いてボールを落とすSÉtelier -セトリエ-ですね。
でも、プログラミング未経験。普通なら「まず勉強してから」となるところです。本を買って、入門サイトを巡って、半年〜1年かけて基礎を学んで……。
ここで僕が思ったのが、「AIがあるんだから、それを相棒にすれば最初から作れるのでは？」でした。
実際にやってみたのは、ClaudeチャットとClaude Code（ターミナル版）の2つを併用するスタイル。Claudeチャットで設計や方針を相談し、Claude Code（あるいはCodeX）に実装を任せる。(本当はClaudeチャットではなく、Claude Coworkが適切だったと思う。あくまで僕の実施したプロセスであり参考程度に。)
つまり、自分はディレクター役で、コードはほぼ書かない。
これでアプリが作れるなら、未経験者にとっては革命的ですし、希望をもって開発に挑戦してみました。
最初の選択：Claudeが推したFlutter
設計の壁打ちを終えて、次は技術スタックの選定でした。
最初にClaudeに伝えた条件はこうです:
- Windowsで開発したい
- App StoreとGoogle Playの両方に出したい
- ボールが落ちる物理演算が必要
- プログラミング未経験
すると、Claudeから返ってきた提案がこれでした。
Flutter + Flame + Forge2D
- Dart言語：Flutterは公式サポートも厚く学習リソースが豊富
- クロスプラットフォーム：iOS/Android両対応、Windows開発OK
- Flame：Flutter公式推奨のゲームエンジン
- Forge2D：物理演算ライブラリ、ボール挙動に最適
理にかなっていました。少なくとも僕にはそう見えました。
そして、これが今思えば最初の落とし穴でした。「AIが推した」というだけで、最適解だと思い込んでしまった。
ここで一つ、後から気づいた重要なこと
Claudeの提案はもちろん技術的に正しい根拠に基づいています。でも、AIの提案には必ず暗黙の前提があります。
たとえば「Flutterは学習リソースが豊富」というのは事実ですが、僕のように一行もコードを書かない開発スタイルには、その「学習リソース」はあまり関係がありません。重要なのは「AIがそのスタックでどれだけスムーズに動けるか」のほうです。
これに気づいたのは、Flutterで詰まった後。AIの提案を受け取るときには「この提案は誰の文脈に最適化されているか？」を意識すべきだったんです。
Phase 1：Flutter始動（Day 1）
ともあれ、Flutterで始めることにしました。
ここからの作業は完全にClaude任せでした:
- Flutter SDKのインストール手順 → Claudeが順番に指示
- Android Studioのセットアップ → Claudeに従う
flutter doctorのエラー解決 → 出てきた赤い文字をClaudeに見せて修正案をもらう- 音源ファイルの調達（オトダマ用に8音源） → Freesound.orgで探してCC0のファイルをダウンロード（＝無料音源サイトで商用利用OKのSEを探した）
- ClaudeCode用の指示書作成 → Claudeが詳細仕様書を生成
ここまでは順調でした。Claudeの指示通りに動けば、未経験者でも開発環境は整っていく。「これは行ける」と確信した瞬間でした。
Phase 2：環境構築の沼（Day 1夜〜Day 2朝）
ところが、いざ実装フェーズに入ったところで雲行きが怪しくなります。
沼その1：CodeXに見切りをつけてClaude Codeへ
実装フェーズで最初に試したのが、 CodeX（OpenAIのクラウド開発環境）でした。
なぜClaude CodeでなくCodeXかというと…
ろくに触ったことがなかったからです！使ってみたかった！ただの好奇心！
…そして、Claudeチャットで設計、CodeXで実装、という分業のつもりで推進しました。
ところが、CodeXにFlutterプロジェクトを作らせようとすると、毎回Flutter SDKをクラウド上にダウンロードしようとしてタイムアウトする現象に遭遇しました。何度試しても通らない。
ここでも結局、僕は「CodeXを諦めてClaude Codeに切り替える」判断をしました。
Anthropic公式のターミナル型AIコーディングツールであるClaude Codeなら、ローカルのVSCodeから僕のWindows環境を直接操作できます。「クラウド側にSDKをダウンロードする」という前提自体がない。
これが、後々まで続く僕のスタイル「Claudeチャット（設計・壁打ち）＋ Claude Code（実装）」の原型になりました。
ちなみにこの「CodeX→Claude Code」の乗り換えも、たった数時間の試行錯誤で見切った判断です。今思えば、これがこの後Flutter自体を見切った判断スピードにつながったのかもしれません。
沼その2：Forge2Dの描画問題
しかし次が本命の沼でした。Forge2Dを使ったゲームエリアが、画面に対してとんでもなく小さく描画される現象です。
iPhoneの画面いっぱいに広がるはずのゲーム領域が、画面の隅っこに親指の爪ほどのサイズで縮小されている。ボールも、オトダマも、全部豆粒。
Claudeに状況を見せて、いくつも提案をもらいました:
- カメラのズーム値を変える
- 座標系のスケールを調整する
- ビューポートの設定を見直す
でも、何を試しても直らない。
未経験の僕には、何が原因なのかすら分かりませんでした。Forge2Dの座標系？ Flutterのレイアウト？ それともFlame側の設定？――どれを疑えばいいのかも分からない。
Day 2の昼、「もうやめよう」と思った
ここが、この記事で一番伝えたいポイントです。
僕が「もうFlutterはやめよう」と判断した瞬間は、ドラマチックなものではありませんでした。
「Claudeが何度提案しても、同じエラーが出続ける」
それを見て、ふと思いました。
これだけ多くの事例を学習しているClaudeでも、すんなり解決策を出せない。 未経験の僕が一人で粘って解ける可能性はかなり低いのでは？
これに気づいた瞬間、「Flutter自体を捨てよう」と決めました。撤退判断です。
そして、自分からClaudeにこう言いました:
「React Native（Expo）で全面再設計してほしい」
Claudeから提案されたわけじゃありません。僕自身が決めて、Claudeに方向転換を指示しました。
補足：あとで調べて分かったこと
この記事を書くにあたって改めて調べてみたら、Flutter + Flame + Forge2D の組み合わせ自体は決してマイナーではありませんでした。Google公式のCodelabもありますし、日本語の解説記事も豊富にあります。
僕がハマっていたのは、おそらくFlameの「スケールモード」周りの定番ハマりポイントでした。Flameには「画面サイズに自動で合わせる機能」が標準で備わっておらず、onGameResize で手動調整する必要がある。これは経験者なら定番の落とし穴として知られています。
つまり当時の僕は、「マイナーだから誰も解けない問題」に直面していたわけではなく、「Flame初心者の定番ハマりポイントを、未経験者+AIの組み合わせで突破できなかった」というのが実態でした。
この事実が分かった上でも、当時の撤退判断自体は正しかったと思っています。次のセクションで、その理由を整理します。
なぜ「AIが詰まったら撤退」が判断軸として機能するのか
未経験者が技術選定で詰まったとき、「AIが詰まったら撤退のサイン」という判断軸が、実はかなり強力です。
理由を整理するとこうなります。
AIは膨大な事例を学習しているので、ネット上にある一般的な問題ならほぼ即座に解決策を出してくれます。なのに、何度提案しても同じエラーが出続けるとき、考えられるのは:
- AIの知識が古い（フレームワークのメジャーバージョン変更などで、古い情報と新しいAPIが混ざった提案になる）
- 問題の本質が、コードの外にある（環境設定、座標系の理解、フレームワーク独特の概念など）
- 未経験者の説明では、AIが状況を正確に把握できていない
このどれであっても、未経験者が独力で粘っても解ける確率は低いのです。経験者なら「あ、これはスケール周りだな」とピンとくる場面でも、未経験者には何が原因かを特定する手がかりすら持っていない。
つまり「AIが詰まる」という現象は、たまたま遭遇した問題が「マイナーで難しい問題」かどうかとは別に、未経験者+AIというチームの限界点を示すシグナルとして機能します。
「AIが詰まる ＝ 自分一人ではもっと詰まる」と考えれば、早く乗り換えることが合理的な選択になります。
Phase 3：React Native再出発（Day 2午後〜）
撤退を決めた瞬間、Claudeに改めて新しい仕様書を作ってもらいました。
技術スタックの全面入れ替えです:
主な変更点:
- 言語：Dart → TypeScript
- フレームワーク：Flutter + Flame → React Native + Expo
- 物理エンジン：Forge2D → Matter.js（JS界隈で実績豊富）
- 音声：音源ファイル8個 → WebAudio APIでリアルタイム合成（音源ファイル0個！）
- 開発環境：CodeX（タイムアウトで断念）→ Claude Code + VSCode + Expo Go（iPhoneでQR読むだけ）
特にWebAudio APIへの切り替えは革命的でした。Flutter版では8つの音源ファイルをFreesoundから探して、ライセンス（CC0/CC BY）を確認して、ファイル名を統一して、assets/audio/に格納して、pubspec.yamlに登録して……と大変でした。それが全部不要になりました。
オシレーターの周波数を変えるだけで「マリンバの音」「ベルの音」「水滴の音」が出せる。音源ファイルゼロでアプリが完成する。
（ただ、コードによる音の生成なので、実際の音と比べるとコレジャナイ感はあります。ここは、今後のアップデートで時間をかけてブラッシュアップしていく所存です）
乗り換え後、何が変わったか
React Nativeに移ってから、開発が劇的にスムーズに進み始めました。
「これだったのか」というのが、当時の率直な感想です。
具体的には:
- Expo GoアプリをiPhoneに入れて、PCでサーバー起動 → QRコードを読むだけで実機にアプリが映る。修正すると即時反映
- Matter.jsは最初の数行で物理演算が動く。Forge2Dで詰まったような描画問題は一切なし
- TypeScriptは型エラーが出るのでAIが書き間違えても気づきやすい
- WebAudio APIでオシレーター1行書けば音が鳴る
Flutterで2日かかっても豆粒サイズのゲーム画面しか出せなかったのに、React Nativeでは数時間で画面いっぱいに動くプロトタイプが動きました。
これは技術の優劣の話ではなく（FlutterもForge2Dも素晴らしい技術です）、「未経験者 + AI」という座組みで、どの組み合わせがハマるかの問題でした。
AI時代の個人開発者へのメッセージ
この経験から、3つの教訓を持って帰りました。
教訓1：AIの提案は仮説、確定事項ではない
AIが「Flutterがおすすめ」と言ったら、それは「現時点での仮説」だと思った方がいい。実装してみてうまく行かなかったら、AIの提案ごと捨てる勇気を持つ。AIに対して遠慮する必要はないんです。
教訓2：「AIが詰まる ＝ 自分も詰まる」と心得る
未経験者は、AIの能力に自分の能力を上乗せできるとは限りません。AIが解けない問題を一人で粘って解くのは、よほど時間に余裕がある人の趣味です。AIが詰まったら、それは技術選定の見直しサインだと考える。
教訓3：撤退は早ければ早いほど良い
僕は2日で見切りました。世間的には「短すぎる」と思われるかもしれない。でも結果として、移行先で1ヶ月後にはApp Storeに申請できる状態になりました。粘っていたら、半年経ってもMVPすら完成していなかったかもしれない。
「最初の選択にこだわらない」は、AI時代の個人開発でも案外大事なスキルかもしれません。
ちなみに僕は、早く一つの成果・実績を作りたくてスピード感に重きを置いていましたが、「速さは2の次、3の次」って人は、即時撤退せずに粘っていいと思います。正直、そのほうが忍耐力も鍛えられるし、試行錯誤の末の成功体験のほうが成長の糧になりそうです。
まとめ：未経験者ほど「AIと一緒に乗り換える」
この記事のメッセージを一言にまとめると:
AIに従って始めるのはOK。でも、AIに従って撤退するのもOK。むしろ、撤退判断は自分で下せ。
未経験者の僕でも、AIを相棒にすればアプリ開発を始められました。でも、最初の技術選定が外れることは普通にあります。それを早く認めて乗り換えることが、未経験者ほど重要だと、この経験で学びました。
「Flutterが悪い」という話では一切ありません。Flutterは素晴らしい技術で、他の人にとっては正解の選択肢でしょう。ただ僕の場合、僕の作りたかったものと、僕の開発スタイル（AI主導・コードを書かない）には、React Native + Expo の方がフィットしていた。それだけの話です。
次回予告
第3回は 「実装で詰まったポイント集 — 物理・音・状態管理の地雷」 です。
React Nativeに移って順調になった後も、もちろん詰まりポイントはありました。iOSのAudioContext数制限、Zustandのrace condition、reanimatedをわざわざ削除した話、ペンタトニック設計の理由など、実装を進める中で出会った技術的な地雷を共有します。
第3回も「未経験者がAIと一緒に解いた」という視点で書く予定です。
iOSアプリ開発備忘録 （もとい、SÉtelier 開発記） 第2回 / 全5回
↓公開したアプリのリンクです（興味あれば！フィードバックも大変有難いです！）↓
コメント