はじめに
OpenAIが2025年12月12日、AI開発支援エージェント「Codex」を活用してSora for Androidアプリを28日間で開発・リリースした事例を詳細に公開しました。本稿では、この発表内容をもとに、Codexを活用した実践的な開発手法と、AI支援開発における組織運営の知見について解説します。
参考記事
- タイトル: How we used Codex to build Sora for Android in 28 days
- 著者: Patrick Hum and RJ Marsan, Members of the Technical Staff
- 発行元: OpenAI
- 発行日: 2025年12月12日
- URL: https://openai.com/index/shipping-sora-for-android-with-codex/
要点
- 4人のエンジニアチームがCodexと協働し、2025年10月8日から11月5日までの28日間でSora for Androidアプリを開発・リリースした
- 開発期間中に約50億トークンを消費し、クラッシュフリー率99.9%を達成した
- GPT-5.1-Codexモデル(開発者が現在利用可能なバージョン)を使用し、コードの約85%をCodexが生成した
- ブルックスの法則(遅延プロジェクトへの人員追加は更なる遅延を招く)を逆手に取り、少数精鋭チーム+Codexという体制を採用した
- Codexを「新入りのシニアエンジニア」として扱い、明確な基盤設計とガイダンスを提供することで高品質な実装を実現した
詳細解説
開発の背景と規模
OpenAIによれば、2025年11月にSora for AndroidアプリをリリースしたところローンチDay 1でPlay Storeランキング1位を獲得し、最初の24時間で100万本以上の動画が生成されました。
このアプリの初期バージョンは、わずか28日間(2025年10月8日〜11月5日)で構築されたとのことです。開発チームは4人のエンジニアで構成され、Codexと協働しながら約50億トークンを消費しました。使用したのはGPT-5.1-Codexモデルで、これは現在CLI、IDE拡張機能、Webアプリを通じて全ての開発者が利用できるバージョンと同じものです。
一般的に、この規模と品質のプロダクションアプリを開発するには、多数のエンジニアが数ヶ月かけて取り組む必要があると考えられます。しかし、OpenAIは異なるアプローチを選択しました。
ブルックスの法則を逆手に取った組織戦略
OpenAIは、アメリカのコンピュータ科学者フレッド・ブルックスの有名な警告「遅れているソフトウェアプロジェクトに人員を追加すると、さらに遅れる」を戦略的に活用しました。
この法則は、エンジニアを増やすことでコミュニケーションのオーバーヘッド、タスクの断片化、統合コストが増大し、効率が低下することを指摘しています。OpenAIはこの洞察を無視するのではなく、むしろ積極的に受け入れ、4人の優秀なエンジニアで構成された少数精鋭チームを編成し、各エンジニアをCodexで武装させることで個々の影響力を大幅に増幅させました。
この体制により、18日間で社内向けビルドを完成させ、その10日後に一般公開を実現したとのことです。従来型のプロジェクトと同等の信頼性基準を維持しながら、Androidエンジニアリングの高水準を保ち、保守性にも投資を行いました。
ソフトウェア開発では、人員を増やすことが必ずしも開発速度の向上につながらないことが知られています。この事例は、少数精鋭チームとAIツールの組み合わせが、大規模チームよりも効率的な選択肢となり得る可能性を示していると思います。
Codexを「新入りシニアエンジニア」として扱う
OpenAIは、Codexを新しく採用したシニアエンジニアのように扱うアプローチが効果的だったと説明しています。
Codexが指導を必要とする領域:
- 明示的に伝えられていない情報(アーキテクチャパターン、プロダクト戦略、実際のユーザー行動、内部規範)の推論
- アプリの実際の動作確認(デバイス上でSoraを開き、スクロールの違和感や分かりにくいフローに気づくこと)
- 各インスタンスへのオンボーディング(明確な目標、制約、「我々の方法」に関するガイダンスの共有)
- 深いアーキテクチャ判断(放置すると、既存のビューモデルを拡張すべき場面で新しいものを導入したり、リポジトリ層に属すべきロジックをUI層に配置したりする傾向)
OpenAIは、Codexにコードベース全体にわたって多数のAGENT.mdファイルを作成・維持させることが有用だったと述べています。これにより、セッション間で同じガイダンスとベストプラクティスを適用しやすくなりました。
Codexが優れている領域:
- 大規模コードベースの迅速な読解と理解
- テストカバレッジの作成(幅広いケースをカバーする単体テストの作成に熱心)
- フィードバックへの対応(CIが失敗した際、ログ出力を貼り付けて修正案を求めることが可能)
- 大規模な並列・使い捨て実行(複数のアイデアを並行してテストし、コードを使い捨てとして扱うことが可能)
- 新しい視点の提供(設計議論で潜在的な失敗ポイントを探索したり、新しい解決方法を発見したりするための生成ツールとして活用)
- より高レバレッジな作業の実現(実際には、自分でコードを書くよりもレビューや指示に多くの時間を費やす結果に)
これらの特性を理解したことで、明確に定義されたパターンと明確に区切られたスコープ内で大量の重労働をCodexに任せ、チームはアーキテクチャ、ユーザーエクスペリエンス、システム全体の変更、最終的な品質に集中できたとのことです。
手作業による基盤構築の重要性
OpenAIは、どれほど優秀な新入社員でも、すぐには長期的なトレードオフを適切に判断できないと指摘しています。
Codexを活用し、その作業が堅牢で保守可能であることを保証するために、チームはアプリのシステム設計と主要なトレードオフを自ら監督することが重要だったとのことです。これには、アプリのアーキテクチャ、モジュール化、依存性注入、ナビゲーションの形成が含まれ、認証とベースネットワーキングフローも実装しました。
この基盤から、いくつかの代表的な機能をエンドツーエンドで作成しました。コードベース全体で従うべきルールを使用し、プロジェクト全体のパターンを文書化していきました。代表的な機能をCodexに示すことで、Codexは基準内でより独立して作業できるようになったとのことです。
OpenAIの推定では、プロジェクトの約85%がCodexによって書かれましたが、慎重に計画された基盤により、コストのかかる後戻りやリファクタリングを回避できました。これは最も重要な決定の一つだったと述べています。
「動くもの」をできるだけ早く作るのではなく、「我々が物事を進めたい方法を理解したもの」を作るという考え方です。コードを書く「正しい」方法は多数あり、Codexに正確に何をすべきかを指示する必要はありませんでした。チームで「正しい」とされるものをCodexに示す必要があったのです。
ソフトウェア開発では、初期の設計決定が後の開発効率に大きく影響することが知られています。AI支援開発においても、人間が明確な設計方針と模範例を提供することで、AIの生成コードの品質と一貫性を大幅に向上させることができると考えられます。
コーディング前の計画フェーズ
OpenAIは、Codexの潜在能力を最大化する次のステップとして、Codexが長時間(最近では24時間以上)無監督で作業できるようにする方法を見出したと説明しています。
初期段階では、「この機能があります。いくつかのファイルがあります。構築してください」のようなプロンプトに直接飛びついていましたが、これは時々機能するものの、ほとんどの場合、技術的にはコンパイルされるが、アーキテクチャや目標から外れたコードを生成していました。
そこでワークフローを変更しました。些細でない変更については、まずCodexにシステムとコードがどのように機能するかを理解してもらうよう依頼しました。例えば、関連ファイルのセットを読み、その機能がどのように動作するか(データがAPI、リポジトリ層、ビューモデル、UIを通じてどのように流れるか)を要約してもらいます。その後、理解を修正または洗練しました。
同様に、優秀な新しいチームメイトに関与するように、Codexと協力して堅実な実装計画を作成しました。その計画は、どのファイルを変更すべきか、どのような新しい状態を導入すべきか、ロジックがどのように流れるべきかを指示する小規模な設計文書のようなものでした。その後初めて、計画を一つずつ適用するようCodexに依頼しました。
この追加の計画ループは時間をかける価値があったとのことです。Codexの計画が分かっているため、長時間「無監督」で実行させることができました。コンテキストなしでdiffを読むのではなく、計画に対して実装をチェックできるため、コードレビューが容易になりました。そして何かがうまくいかない場合、コードの前に計画をデバッグできました。
分散エンジニアリング
OpenAIによれば、プロジェクトのピーク時には、複数のCodexセッションを並行して実行することがよくあったとのことです。一つは再生機能、別の一つは検索、別の一つはエラー処理、時には別のものがテストやリファクタリングに取り組んでいました。ツールを使用しているというよりも、チームを管理しているような感覚だったと述べています。
各セッションは定期的に進捗を報告してきました。一つは「このモジュールの計画が完了しました。これが提案です」と言い、別の一つは新機能の大きなdiffを提供しました。それぞれに注意、フィードバック、レビューが必要でした。
結果として、協働的なフローが生まれました。Codexの生のコーディング能力により、多くの手動タイピングから解放されました。アーキテクチャについて考え、プルリクエストを注意深く読み、アプリをテストする時間が増えました。
同時に、その追加のスピードは、常にレビューキューに何かが待っていることを意味しました。Codexはコンテキストスイッチによってブロックされませんでしたが、人間はブロックされました。開発におけるボトルネックは、コードを書くことから、意思決定、フィードバックの提供、変更の統合へとシフトしたとのことです。
これは、ブルックスの洞察が新しい形で現れる場面と言えます。Codexセッションを追加し続けても、エンジニアをプロジェクトに追加し続けてスケジュールが線形に短縮されることを期待できないのと同様に、線形的な高速化は期待できません。仮想的なものであっても、追加の「手」はそれぞれ調整のオーバーヘッドを追加します。
クロスプラットフォーム開発への応用
OpenAIは、プロジェクト開始時に大きな足がかりがあったと述べています。SoraはすでにiOSでリリースされていました。主要な要件と制約を理解するために、CodexにiOSとバックエンドのコードベースを頻繁に参照させました。
プロジェクト全体を通じて、「クロスプラットフォームフレームワークという概念を再発明した」と冗談を言っていたとのことです。React NativeやFlutterは忘れてください。クロスプラットフォームの未来はただCodexです。
この冗談の背後には2つの原則があります:
- ロジックは移植可能: コードがSwiftで書かれていてもKotlinで書かれていても、基礎となるアプリケーションロジック(データモデル、ネットワーク呼び出し、検証ルール、ビジネスロジック)は同じです。CodexはSwift実装を読み、セマンティクスを保持する同等のKotlinを生成することが非常に得意です。
- 具体例は強力なコンテキストを提供: 「iOSでこれが正確にどのように機能するか」と「Androidアーキテクチャはこれです」を見ることができる新しいCodexセッションは、自然言語の説明のみから作業するセッションよりもはるかに効果的です。
これらの原則を実践するために、iOS、バックエンド、Androidのリポジトリを同じ環境で利用可能にしました。「iOSコードのこれらのモデルとエンドポイントを読み、既存のAPIクライアントとモデルクラスを使用してAndroidで同等の動作を実装する計画を提案してください」のようなプロンプトをCodexに与えました。
OpenAIは、共有抽象化ではなく、翻訳を通じてクロスプラットフォーム開発を効果的に行っていたとのことです。Codexがほとんどの翻訳を処理したため、実装コストを倍増させることを回避できました。
AI支援開発の未来像
OpenAIによれば、4週間のスプリントが終わる頃には、Codexの使用は実験的なものではなくなり、デフォルトの開発ループになっていたとのことです。既存のコードを理解し、変更を計画し、機能を実装するために使用しました。チームメイトのレビューと同じ方法でその出力をレビューしました。それは単にソフトウェアを出荷する方法でした。
AI支援開発は厳密性の必要性を減らすのではなく、増やすことが明らかになったと述べています。Codexがどれほど有能であっても、その目的はAからBへ、今すぐ移動することです。これが、AI支援コーディングが人間なしでは機能しない理由です。
ソフトウェアエンジニアは、システムの現実世界の制約、ソフトウェアを設計する最良の方法、将来の開発と製品計画を念頭に置いて構築する方法を理解し適用できます。明日のソフトウェアエンジニアのスーパーパワーは、深いシステム理解と、長期的な時間軸でAIと協働的に作業する能力になると考えられます。
ソフトウェアエンジニアリングの最も興味深い部分は、魅力的な製品の構築、スケーラブルなシステムの設計、複雑なアルゴリズムの記述、データ、パターン、コードの実験です。しかし、過去と現在のソフトウェアエンジニアリングの現実は、より平凡なことに傾きがちです。ボタンの中央揃え、エンドポイントの配線、ボイラープレートの記述などです。現在、Codexはソフトウェアエンジニアリングの最も意味のある部分と、我々がこの技術を愛する理由に焦点を当てることを可能にすると述べています。
まとめ
OpenAIは、4人のエンジニアチームがCodexと協働し、28日間でクラッシュフリー率99.9%のSora for Androidアプリを開発した実践事例を公開しました。この事例は、少数精鋭チーム+AIという体制が、従来の大規模チームよりも効率的な選択肢となり得る可能性を示しています。成功の鍵は、Codexを「新入りシニアエンジニア」として扱い、明確な基盤設計とガイダンスを提供することにあったとのことです。今後、AI支援開発が一般化する中で、深いシステム理解と長期的視点でAIと協働する能力が、ソフトウェアエンジニアの重要なスキルになると考えられます。
