OpenAIの記事「Codexを使って28日間でAndroid版Soraを構築した方法」を読みました。これは非常に注目すべき記事です。Sora Androidクライアントアプリのコードの約85%はAIによって記述されました。リリース初日には、ユーザーが24時間以内に100万本以上の動画を作成し、常に高品質でクラッシュ率99.9%を達成しました。 この結果に疑問を抱く人もいるでしょう。中にはプログラマーは絶望的だと考える人もいるでしょう。この結果を見て、私の考えを述べさせてください。簡単に言えば、これは最先端の兵器を装備した特殊部隊の兵士数人のようなもので、当然ながら無敵です。ですから、この結果を過度に誇張しすぎないようにしましょう。たとえ特殊部隊の兵士でなくても、この結果から貴重な教訓を学ぶことができるはずです。 『人月の神話』の著者フレッド・ブルックスは、ソフトウェアエンジニアリングにおいて古くから語り継がれてきた格言をこう述べています。「遅延しているソフトウェアプロジェクトに人材を追加しても、プロジェクトはさらに遅延するだけだ。」これは、エンジニアを増やすと、コミュニケーションコスト、タスクの細分化、統合コストの増加により、効率が低下することが多いためです。 チームに AI を追加するのはどうでしょうか? それはチームメンバーのAI管理能力にかかっています。「韓信が率いる兵士が多ければ多いほど良い」という古い格言があります。チームメンバーが韓信であれば、AIエージェントの数が多いほど良いのです。OpenAI Androidチームは明らかにエリートチームで、わずか4人で構成されており、まるで特殊部隊のようにそれぞれが様々なロボット支援を装備しています。 それで彼らはどうやってそれをやったのでしょうか? 1. アーキテクチャ優先: 最初に人間がフレームワークを構築し、次に AI が空白を埋めます。 この棚をどうやって設置すればいいですか？ チームはまず、アプリ全体のアーキテクチャ（モジュール方式、依存性注入、ナビゲーション構造、認証プロセス、基本的なネットワーク層）を自ら定義しました。次に、いくつかの代表的な機能をテンプレートとして手書きで記述しました。 重要なステップ：彼らは https://t.co/9M2TJcCBVQ のような、AI初心者向けのガイドとなる多数のファイルを作成しました。例えば、CIがこの時点で停止してしまうため、各コミットの前にdetektFixを実行してフォーマットを確認する必要があると書かれています。 これにより、新しいCodexセッションが始まるたびに、これらの仕様を素早く読み取ることができます。まるで新入社員に社内Wikiを提供するようなもので、繰り返しの説明にかかるコストを削減できます。 チームはそれを一言でまとめました。「Codexにコードの書き方を指示する必要はありません。チームにとって何が正しいのかを指示する必要があるのです。」これは微妙ですが重要な違いです。 2. コードを書く前に計画を立てる 当初、彼らは「これが機能要件で、これが関連ドキュメントなので、それを実装してください」とだけ言って、手抜きをしようとしました。コードは実行できましたが、軌道から大きく外れ、期待されたアーキテクチャを完全に満たせませんでした。 その後、彼らはプロセスを変更しました。複雑な機能の場合、最初のステップはAIにコードを書かせることではなく、AIにシステムを理解させることでした。例えば、APIからリポジトリ、ViewModel、そしてUIへとデータがどのように流れるかをまとめるために、関連ファイルセットを読み込ませました。そして、人間が理解を修正しました。 理解が正しければ、AIはミニ設計書のような実装計画を生成します。これには、どのファイルを修正する必要があるか、どのような新しい状態を導入する必要があるか、そしてロジックの流れがどのようになるかが含まれます。人間が計画の妥当性を確認した後、AIは実装を開始します。 この計画段階は時間がかかるように思えるかもしれませんが、実際には多くの手戻りを省くことができます。さらに重要なのは、AIの計画が分かれば、コードのレビューがはるかに容易になることです。大量の差分をぼんやりと眺めるのではなく、実行が計画に沿っているかどうかを確認できるのです。 また、ちょっとした工夫も凝らされています。特に長いタスクの場合、AIに計画をファイルに保存させています。こうすることで、セッションが変わってもタスクを続行できます。 Codexの複数のタスクが同時に実行されると、開発エクスペリエンス全体が一変します。ツールを使っているという感覚ではなく、チームを管理しているという感覚になります。 一つのタスクはメディアプレーヤーの最適化、もう一つは検索機能の作成、三つ目はエラーロジックの処理、そして四つ目は追加テストです。それぞれが独立して作業し、時折「このモジュールの計画は立てたんだけど、どう思う？」と報告してくることもあります。あるいは、大きな差分を突きつけてくることもあります。 エンジニアの仕事は、コードを書くことから、意思決定とフィードバックを提供することへと移行しました。ボトルネックとなるのは、もはやコードをどれだけ速く書けるかではなく、頭の中でコードをどれだけ速くレビューし、検証できるかです。 これは、人月神話を再び証明しています。つまり、人員を増やすことも、エージェントを無制限に増やすことはできません。 3. 最高のクロスプラットフォーム フレームワークは AI エージェントです。 もう 1 つの興味深い実践は、クロスプラットフォーム開発という新しいパラダイムです。 SoraにはすでにiOS版があります。Android版の開発にあたっては、iOSのコードベースをCodex環境にアップロードするだけでした。そして、Codexに「iOSのコード実装を参照し、Androidのアーキテクチャを確認して、対応するKotlinコードを生成してください」と指示しました。 そのため、記事では冗談めかしてこう述べています。「React Native と Flutter は忘れてください。将来のクロスプラットフォーム フレームワークは Codex です。」 この発言は半分本気で、半分冗談です。なぜなら、アプリケーションロジックは移植可能だからです。データモデル、ネットワークリクエスト、そして検証ルールは、Swiftで書かれていてもKotlinで書かれていても、本質的には同じものです。AIはこうした翻訳作業に優れており、十分なコンテキストがあれば、言語間のロスレス変換を実行できます。 では振り返ってみると、なぜ私たちは彼らを過度に神格化すべきではないと言うのでしょうか? わずか4人ですが、全員がハン・シンのようなリーダーとしてチームを率い、エージェントを巧みに使いこなしています。しかし、人数が多いほど良いというわけではありません。タスクの割り当てや結果の検証には人員が必要です。さらに、iOSのコードはすでに存在するため、多くのロジックを共有でき、AIによる「翻訳」だけで済みます。 しかし、学ぶべきことはまだたくさんあります。 まずアーキテクチャを設計し、AIに空白を埋めさせる。これにより、コードの保守が容易になり、品質が向上します。 コードを書く前に計画を立て、AIがコンテキストを完全に理解してから行動できるようにしましょう。Codexは遅すぎると不満を言う人が多いですが、私自身はエージェントがあまりにも速く、不安定に行動してしまうのではないかと心配しています。もう少し待って、コンテキストをより深く学習させ、最初の試行で成功させる方が良いと思います。そうしないと、手戻り作業に非常に時間がかかります。 AIが模倣学習できるよう、適切な参照情報を提供しましょう。まずはベストプラクティスを文書化することに時間をかけましょう。AIがこれらのベストプラクティスを参照することで、出力が大幅に向上します。他の言語での実装が利用可能な場合は、AIにそれらを「翻訳」させることで、さらに効率が向上します。 これらのことを実行するだけで、AI支援開発を効果的に活用できます。AI支援開発は開発水準を下げるのではなく、むしろ向上させます。 エージェントは特定の小さなタスクを完了することに優れていますが、ソフトウェアエンジニアリングは小さなタスクではありません。動的に変化する無数の小さなタスクで構成されています。これらのタスクは、人間によって分解され、検証される必要があります。 したがって、将来のソフトウェア エンジニアの中核となる能力は、コードを素早く書くことではなく、システムに対する深い理解と、長期的に AI と連携する能力の 2 つになります。 コードは安価になりつつあるが、センスは高価になっている。何が正しく、何がエレガントで、何が未来志向かを判断できる人は、ますます少なくなっていくだろう。 AI がレンガ積みの作業を引き継ぎましたが、設計図の作成作業は引き続きあなたの仕事です。
