Claude CodeとCodexでiOSアプリを作った話
Claude Codeすげえを超え恐怖
最近Claude Codeが非IT系の仕事でも相当使えるということがバレて来たと思っている。 Claude の使い方みたいなTipsが人気のようですが、 それすら来月には要らなくなるよと思ってしまういっぴきこあらです （多分Claudeがインストールできれば、後はいい感じにしてくれる）
多分、「Claudeで業務改善！」とか言っていられるレベルはきっとすぐ終わって、 「Claudeで改善できることって人がやる意味なくね？」となるのではと戦々恐々としている。
なのでClaude Codeでアプリを作った話をします。 これもきっとskillsになっているはずで、それを使えばよかっただけ説はある。 1ヶ月前に正しかったことが、すぐに非効率なやり方となる世界で何を残したらいいのかわからんが、 とりあえず書いてみている。
Claude CodeとCodexでiOSアプリを作った話
きっかけは妻からの一言。その一言を載せたいがクックパッドが炎上しているので載せません。 ※問題ない使い方はしています
ということでぼかすけど、iOSアプリ未経験の自分がアプリを作ることになった。
結論を言うと1時間で動くものができた。知ってたけどClaude まじすげえ。 けど結局、ちゃんとものにするまでに1時間×6日掛かっており、 ここにソフトウェア開発のノウハウも含まれていると思う。
フロー
通常のSW開発と同じように、要件定義→仕様作成→実装→テスト→改善というフローで進めた。 Claude Code が要件定義・実装・設計改善を担当し、応答性の改善は Codex を使った。
| Day | やったこと |
|---|---|
| Day1 | Claudeが妻にヒアリングして要件定義・実装 |
| Day2 | iPhoneにインストール・動作確認 |
| Day3 | バグ多発のためClaudeに再設計を指示 |
| Day4 | 動きが遅いためClaudeに調査させる |
| Day5 | Claudeが調査に詰まり→Codexに改善指示 |
| Day6 | 応答性が大幅改善・完成！ |
Day1〜2：Claudeが妻にヒアリングして要件定義
まじで思うけど、AIに何かさせるときはまず要件を決めるべきです。 いいプロンプトとか要らんからまずこれをしましょう（真顔）
GPTのCopilotだけは擁護しませんが、これをやってからAIの力を評価してあげてください。
要件定義というと難しく見えますが、お仕事お願いするときに自然とやっていることと同じ。 しっかりAIが何をしたらいいか理解するまで、コミュニケーションに付き合ってあげましょう。
人と仕事をするときもコミュニケーションして 目的は何か、何をして、しないかみたいなことを決める。
それをAIに壁打ちしながらやればOK。 というか「〇〇したいんだけど、どうやったらうまくいく？」とAIに聞いたほうがはやい。
人が1からやり方を考えるより、AIに考えさせる、聞いてもらう方が圧倒的に賢い
非エンジニアの妻による要件定義
まず自分からClaudeにこう投げた：
「○○のようなiOSアプリを作りたい。実際のユーザに聞いて要件定義を 固めてから実装しよう。ユーザは非エンジニア。 実装できるようになるまで何回でもいいので足りない情報を聞いて」
自分は要件定義が一番大切と感じるので、Opus × Plan Modeでじっくりやってもらう。
Claudeが妻に直接ヒアリングを開始。 ４択の質問を繰り返し、たたき台となる要件.mdを作ってきた。
ここですごいのは妻は非エンジニア（DX反対派）であること。 誰でもClaudeにインタビューさせることでまあまあな要件が作れる。
そのまま実装させてもOKで動くソフトはできるはず。 Claude Code で非エンジニアでもアプリが作れました！みたいな記事を見ていると、 本当にこれでOKなんだろうなと思う。
が、、、自分はエンジニアの端くれとして、 要件をちゃんと決めないと手戻りが発生したり、非効率なコードになり、 今後の機能追加も難しくなる感覚がある。
「バージョン管理はどうすんの？設定はハードコードしないで？ データ保管は？RAM食わないようにして？機能追加しやすい構造にして？」といった エンジニアなのか何なのか微妙な指摘を入れる。
質問と回答を繰り返して要件.modeをブラッシュアップ。 承認してそのまま実装まで終わらせる。
1時間でできたアプリは妻に高評価
ここまで1時間くらい。妻はよろこぶと同時に驚いていた。 僕は最近「無職になる」とよく言っていますが、現実味が出てきた思う。
iPhoneへのデプロイ方法もClaudeに教わった
Xcodeの操作・設定方法はすべてClaudeに聞いた（たまに存在しない画面を指定されたが）。
Day3：実機試験でバグだらけ
ちゃんと触ってみるとまあまあ不具合がでる。 ユニットテストは通しているけど、OS側のAPIを叩くような結合レベルの箇所であらが出る。
修正指示→確認→別箇所で不具合→また修正、という無限いたちごっこが発生。
典型的な症状としては、「カメラロールで画像を選択して決定を押すと、なぜかカメラロールに戻ってしまう（発生確率30%）」。 これはあるあるだと思うんだけど、 Claudeに原因を調査させて修正してもらうが、直すたびに別のバグが出る。
これは根本的な問題と判断し、設計を1から見直させることにした。
「1から設計するならどうする？」でいたちごっこを防止
小手先の修正ではデグレが発生する。こういう時は根本設計の見直しが正解。
Claudeに「1から設計するならどうする？」と聞いて現状を分析させると、「画面遷移の状態管理が複雑すぎる」という問題が判明。 再設計案として「状態管理を一元化、画面遷移をシンプルな1方向フローに変更」が提示され、 そのまま実装してもらった結果、同種のバグが発生しなくなった。 「教訓：3回直しても治らないなら設計を疑え」とClaudeが言っている
Day4：性能問題で詰まる
画像選択から次画面に移るまで20秒かかることがある、という非機能面の不具合が発生。 iOSアプリの知識がないため、Claudeに適切に突っ込めない。
「治っていないよ、ログ仕込んで」と指示すると「修正したw確認して」 を繰り返すだけで埒が明かない（僕のClaudeはネット民にしているのでwをつけている）。
ここでClaude Codeの限界を感じ、Codexを導入することにした。
Codexを導入
Claudeは陽キャ、Codexは口下手なベテランエンジニアっていう感じ。 Codexはゴールがあればひたすら問題を切り分けて解決してくれる。
Claude CodeとCodexの使い分けはこんな感じ。
| Claude Code（Anthropic） | Codex（OpenAI） | |
|---|---|---|
| 得意なこと | 対話しながらの開発 | コードの解析・調査 |
| 料金 | Pro: 17$/月（よく1日でlimitに引っかかる） | Go: 1,400円/月 / Plus: 3,000円/月 |
| 今回の使い方 | Opus: 要件定義・不具合調査 / Sonnet: 実装 | 性能問題の調査・改善 |
性能問題をCodexに丸投げしたところ、原因特定＋修正を自律的に実施してくれた。 自分は指示に従っただけで性能が大幅改善。
1つのツールに固執せず、適材適所で使い分けるのが大事なのかなと。Copilotだけは許さんが。
Claude CodeをPMにして、タスク分解させた後にCodexのAPIを叩くみたいな使い方が 本質なのかもね
80%の法則はAIにも適用される
「AI使えば楽勝」ではない。 ∙ ただ動くアプリ（80%の完成度）は簡単に作れる ∙ クオリティを求めると、それなりに時間がかかる
とはいえ、iOSアプリを知識ゼロから作れたのは事実。 AIなしなら数ヶ月〜半年はかかっていた。 動くアプリを作る80%は簡単、品質を上げていく20%が本当の勝負。結局時間はかかる。
GWは九州に行きたくなっている：
