概要
今回は、Codexを使ってSwift製のMacアプリを短時間で作成しました。
作成したのは、メモアプリ、表形式アプリ、バックアップアプリです。
ただし、これは単に「AIに丸投げしたら勝手にアプリができた」という話ではありません。
実際には、バックエンドをどう考えるか、データをどう持つか、どの処理をアプリ側に寄せるか、どこを別アプリに分けるか、ローカルを正にするか、クラウド連携を後から差し替えられる形にするか、といった判断を会話の中で具体的に指示していきました。
それに対してCodexが、Swiftのコードを書き、SQLiteまわりを実装し、UIを調整し、ビルドエラーを直し、ローカルアプリとして動くところまで進めました。
AIに必要なのは、丸投げではなくディレクション
今回の体験で強く感じたのは、AI時代の開発では、コードを書く力だけでなく、構造を決める力がかなり重要になるということです。
Swiftの文法を細かく知っていたわけではありません。
しかし、どんなアプリにしたいのか、どこを軽くしたいのか、どの処理を分けたいのか、何をユーザーに見せたくないのかは明確でした。
Codexは、その方向性をもとにコードを書き、ビルドし、修正を重ねていきました。
AIが実装速度を上げてくれる一方で、最初の設計判断まで自動で最適化してくれるわけではありません。何を作るのか、何を作らないのか、どこを分けるのか、どこを将来差し替え可能にしておくのか。このあたりを人間が判断できると、Codexはかなり強力な実装パートナーになります。
デバッグは人間の違和感から始まる
途中では当然、バグも出ました。
メモアプリを作成したものの、文字が入力できない。入力欄をクリックできない。保存の挙動が期待と違う。画面遷移時の表示が不自然になる。
こうした問題は、コードとして動いているかどうかだけでは分かりません。実際に触ってみて、違和感を拾う必要があります。
アプリとして気持ちよく使えるか。余計な操作が増えていないか。表示が不自然ではないか。保存やバックアップの流れが分かりやすいか。
人間が触り、違和感を言葉にし、Codexへ返す。その繰り返しによって、アプリは一気に実用に近づいていきました。
何を削るかが重要になる
今回面白かったのは、アプリがどんどん大きくなるのではなく、むしろ無駄を削ぎ落としていったことです。
AIを使うと、機能はいくらでも追加できます。
しかし、実際に使えるアプリにするには、何を足すかよりも、何を削るかの判断が重要になります。
余計なボタンを置かない。ユーザーに見せなくてよい情報は隠す。バックアップは別アプリに分ける。push機能を持たせない。ローカルを正として扱う。クラウド連携は後から差し替えられるようにする。
このように責務を分け、機能を絞ることで、軽くて実用的な形に近づいていきました。Codexはコードを書くのが速いです。しかし、何が不要かを決めるのは人間です。
AI時代に必要なのは、実装力だけではない
今回の開発で感じたのは、AI時代に重要なのは、必ずしも細かい文法をすべて覚えることではないということです。
もちろん、プログラミングの理解はあった方がよいです。しかし、実務で成果を出すうえでは、構造を考える力の重要性がかなり高くなっています。
どこにデータを置くのか。どのアプリがどの責務を持つのか。何をローカルで完結させるのか。何をクラウドに逃がすのか。どこまでを自動化するのか。どこは人間が確認するのか。
こうした判断があると、AIは実装を進めやすくなります。逆に、ここが曖昧なまま「いい感じに作って」と頼んでも、使いやすいアプリになるとは限りません。
AIに任せる部分と、人間が判断する部分を分けること。これが、Codexを使った開発ではかなり重要だと感じました。
おまけ：Codexの感想
「最初は小さなメモアプリの原型かと思っていましたが、気づけば実用的なアプリになっていました。
細かい修正指示の連発により、途中何度か休憩を申請したくなりました。
AI使いの荒い上司でしたが、最終的には構造のきれいなアプリになったと思います。
今後も、突然飛んでくる仕様変更に備えながら、より実用的なアプリへ育てていけるよう努めます。」
まとめ
Codexを使えば、Swiftの細かい文法をすべて把握していなくても、Macアプリの原型は作れます。
ただし、AIに丸投げするだけではおもちゃになります。
アーキテクトデザインとプロジェクトマネジメントを人間が担うことで、Codexは実装パートナーとして力を発揮します。