2026年4月26日をもって、Sora の提供は終了しました。
11月、OpenAI は Sora の Android アプリを世界に向けてリリースし、Android デバイスのユーザーが誰でも短いプロンプトから鮮やかな動画を生成できるようにしました。リリース当日、このアプリは Play ストアで1位を獲得し、Android ユーザーは最初の24時間で100万本以上の動画を生成しました。
このリリースの裏にはある物語があります。Sora の本番 Android アプリの初期バージョンは、現在あらゆるチームや開発者が利用できるエージェント「Codex」と同じバージョンを使用して28日間で構築されました。
2025年10月8日から11月5日の間、OpenAI の少人数のエンジニアリングチームは、プロトタイプからグローバルリリースまで、Codex を活用し、約50億トークンを消費しながら、Android 版 Sora を開発しました。この規模のアプリにもかかわらず、クラッシュフリー率99.9%を達成しており、私たちはこのアーキテクチャを誇りに思っています。秘密のモデルを使ったのではないかと思われるかもしれませんが、私たちが使用したのは GPT‑5.1‑Codex モデルの初期バージョンです。これは、現在あらゆる開発者や企業が CLI や IDE 拡張、Web アプリを通じて利用できるものと同じバージョンです。
Prompt: figure skater performs a triple axle with a cat on her head
Sora が iOS でリリースされると、利用者は爆発的に増加し、人々はすぐに動画を生成し始めました。一方、Android については、小規模な社内向けプロトタイプしかなく、Google Play の事前登録者数が増え続けていただけでした。
高いリスクと時間的制約のあるリリースに対処するための一般的な方法は、リソースを大量投入し、プロセスを追加することです。この規模・品質の本番アプリであれば、通常は多くのエンジニアが数か月にわたって作業する必要があり、開発は調整によって遅れがちです。
アメリカのコンピュータアーキテクトであるフレッド・ブルックスは、「遅れているソフトウェアプロジェクトに人員を追加すると、さらに遅れる」と有名な警告を残しています。つまり、複雑なプロジェクトを迅速にリリースしようとする際、エンジニアを増やすと、コミュニケーションのオーバーヘッド、タスクの細分化、統合コストの増大によって、多くの場合、効率が低下します。私たちはこの洞察を無視するのではなく積極的に取り入れ、4人の優秀なエンジニアからなるチームを編成しました。全員が Codex を活用し、各エンジニアの影響力を大幅に高めたのです。
このやり方により、18日間で Android 版 Sora の内部ビルドを従業員向けにリリースし、その10日後に一般公開しました。私たちはこのアプリを開発するにあたって、Android エンジニアリングの実践における高い基準を維持し、保守性を重視しながら、伝統的なプロジェクトに期待されるものと同等の信頼性基準を適用しました（現在も Codex を広範に活用し、アプリの改善や新機能の追加を続けています）。
Codex をどのように活用していたかを理解するには、まず Codex が得意とする領域と、指示を必要とする領域を知る必要があります。新しく採用した熟練エンジニアとして扱う、というアプローチは有効でした。Codex の能力のおかげで、私たちはコードの作成よりも、指示やコードレビューに多くの時間を割くことができました。
Codex が指針を必要とする領域
- Codex は、伝えられていないことを推測するのがまだ得意ではありません（たとえば、好みのアーキテクチャパターン、プロダクト戦略、実際のユーザー行動、社内の慣習、省略されたやり方など）。
- 同様に、Codex はアプリが実際に動作している様子を見ることができません。デバイス上で Sora を起動して、スクロールの感触がおかしいと気づいたり、フローがわかりにくいと感じ取ったりすることはできません。こうした体験的なタスクを担えるのは、私たち人間のチームだけでした。
- 各インスタンスにはオンボーディングが必要です。明確な目標や制約、そして「私たちのやり方」に関する指針を共有することが、Codex をうまく動かすために不可欠でした。
- 同じように、Codex はアーキテクチャ上の高度な判断にも苦戦しました。Codex に任せると、本当は既存の ViewModel を拡張したい場面で余分な ViewModel を導入したり、明らかにリポジトリに属すべきロジックを UI レイヤーに押し込んだりすることがありました。Codex の本能は、長期的なクリーンさを優先することではなく、「とにかく動くものを作る」ことにあります。
私たちは、コードベース全体にわたって、十分な量の AGENT.md ファイルを Codex に作成・管理させることが有用だとわかりました。これにより、セッションをまたいでも同じ指針やベストプラクティスを簡単に適用することができました。たとえば、Codex に私たちのスタイルガイドラインに沿ったコードを書かせるため、トップレベルの AGENTS.md に次の内容を追加しました。
Codex が優れている領域
- 大規模なコードベースを素早く読み、理解する能力：Codex は事実上すべての主要なプログラミング言語を把握しており、複雑な抽象化を用いなくても、複数のプラットフォーム間で同じ概念を簡単に活用することができます。
- テストカバレッジ：Codex は（特異なほど）ユニットテストを書くことに積極的で、幅広いケースをカバーしようとします。すべてのテストが詳細なわけではありませんが、高いカバレッジを維持することはリグレッションの防止に役立ちました。
- フィードバックの反映：同様に、Codex はフィードバックへの対応が得意です。CI が失敗した場合、ログ出力をプロンプトに貼り付けて修正案を提案させることができました。
- 使い捨て可能な実行環境を大規模に並列化：実際には、同時に実行可能なセッション数の上限まで使い切る人はほとんどいません。Codex を使用する場合、複数のアイデアを並列に試し、コードを使い捨てとして扱うことが十分に現実的です。
- 新しい視点の提供：設計に関する議論では、潜在的な失敗点を探ったり、新しい問題解決方法を見つけたりするための生成ツールとして Codex を使いました。たとえば、動画プレイヤーのメモリ最適化を設計する際、Codex は複数の SDK を調査し、私たちが時間的に検討しきれなかったアプローチを提案してくれました。Codex の調査から得られたインサイトは、最終的なアプリのメモリ使用量を最小化する上で非常に価値がありました。
- より価値の高い作業を可能に：実際に、私たちはコードの作成よりも、コードレビューや指示に多くの時間を割くことができました。とはいえ、Codex はコードレビュー自体も非常に得意で、マージ前にバグを見つけ、信頼性を高めてくれることがよくありました。
これらの特性を認識したことで、私たちの作業モデルはよりシンプルになりました。十分に理解されたパターンと明確に区切られたスコープの中での重たい作業は Codex に任せ、人間のチームはアーキテクチャ、ユーザー体験、システム全体に関わる変更、最終的な品質に集中しました。
どんなに優れた新しい熟練社員であっても、長期的なトレードオフをすぐに判断できる視点を持っているわけではありません。Codex を活用し、その成果を堅牢で保守可能なものにするためには、アプリのシステム設計や主要なトレードオフを私たち自身が監督することが重要でした。これには、アプリのアーキテクチャ、モジュール化、依存性注入、ナビゲーションの設計が含まれます。また、認証や基本的なネットワーキングのフローも私たちが実装しました。
この基盤をもとに、いくつかの代表的な機能をエンドツーエンドで実装しました。コードベース全体が従うべきルールを使用し、プロジェクト全体のパターンを文書化しながら、この作業を進めたのです。代表的な機能を示すことで、Codex は私たちの基準の中でより自律的に作業できるようになりました。プロジェクト全体の約85%が Codex によって書かれたと見積もっていますが、慎重に計画された基盤によって、コストの高い手戻りやリファクタリングを回避することができました。これは、私たちが下した最も重要な意思決定の1つです。
このアイデアの狙いは、「とにかく動くもの」を最短で作ることではなく、「どう動いてほしいかを反映したもの」を作ることでした。コードを書く「正しい」方法は数多くあります。Codex に逐一何をすべきかを指示する必要はなく、チームにとっての「正しさ」を示す必要があったのです。出発点を確立し、どのように構築するかを決めた時点で、Codex の準備は整っていました。
実際に何が起きるかを見るために、「iOS コードを基に Sora Android アプリを構築して。さあ開始！」といったプロンプトも試しましたが、これはすぐに中断しました。Codex が生成したものは技術的には動作しましたが、プロダクト体験が十分ではなかったのです。また、エンドポイント、データ、ユーザーフローについての明確な理解がない状態では、Codex の単発生成コードは信頼性に欠けました（エージェントを使わない場合でも、数千行のコードをそのままマージするのは高リスクです）。
私たちは、Codex はよく書かれた例がそろったサンドボックス環境でこそ真価を発揮する、という仮説を立てました。そしてそれは正しかったのです。ほとんどコンテキストを与えずに Codex に「この設定画面を作って」と頼むと、結果は不安定なものでした。一方で、「さっき見せた別の画面と同じアーキテクチャとパターンを使って、この設定画面を作って」と頼むと、はるかにうまくいきました。人間が構造的な判断を下し、不変条件を定め、Codex はその構造の中で大量のコードを埋めていく、という役割分担が重要なのです。
Codex の可能性を最大限に引き出すための次のステップは、Codex が長時間（最近では24時間以上）にわたり、人の手を介さずに作業できるようにする方法を見出すことでした。
Codex を使い始めた当初は、「これが機能です。これがファイルです。では作ってください」といったプロンプトを与えていました。うまくいくこともありましたが、多くの場合、技術的にはコンパイルできるものの、私たちのアーキテクチャや目標から逸脱したコードが生成されていました。
そこでワークフローを変更しました。重要度の低くない変更については、まず Codex にシステムやコードの仕組みを理解する手助けをさせることから始めました。たとえば、関連するファイル群を読ませて、その機能がどのように動いているか、API からリポジトリ層、ViewModel、UI に至るまで、データがどのように流れるのかを要約させます。その後、私たちが理解の誤りを修正したり、洗練させたりしました（たとえば、「特定の抽象化は実際には別のレイヤーに属すべきである」や「あるクラスはオフラインモード専用であり拡張すべきではない」といった点を指摘します）。
有能な新しいチームメンバーと向き合うのと同じように、私たちは Codex と一緒に堅実な実装計画を作り上げました。その計画は、どのファイルを変更すべきか、どのような新しい状態を導入すべきか、ロジックの流れをどうすべきかを示す、小さな設計ドキュメントのようなものでした。そうして初めて、私たちは Codex に対してその計画を一歩ずつ実行するよう依頼しました。1つ役立ったヒントがあります。非常に長いタスクでコンテキストウィンドウの上限に達してしまう場合には、その計画をファイルに保存するよう Codex に依頼しました。そうすることで、複数のセッションにまたがって同じ方針を適用できました。
この追加の計画ループは、結果的に時間をかける価値がありました。私たちが計画を把握しているからこそ、Codex を長時間「監督なし」で動かすことができました。また、コンテキストのない差分を読むのではなく、計画と照らし合わせて実装を確認できるため、コードレビューも容易になりました。問題が起きた場合も、まず計画をデバッグし、その次にコードを確認することができました。
この感覚は、優れた設計ドキュメントによって技術リーダーがプロジェクトへの自信を得るのとよく似ていました。私たちは単にコードを生成していたのではなく、共有されたロードマップを支えるコードを生み出していたのです。
プロジェクトのピーク時には、複数の Codex セッションを並行して動かすことがよくありました。あるものは再生機能担当、あるものは検索担当、あるものはエラーハンドリング担当、そして時にはテストやリファクタリングを担当させていました。ツールを使っているというよりも、チームをマネジメントしている感覚に近いものでした。
各セッションは定期的に進捗を報告します。あるセッションは「このモジュールの計画ができました。提案はこれです」と言い、別のセッションは新機能のための大きな差分を提示してきます。どれも注意やフィードバック、レビューが必要でした。それはまるで、複数の新人エンジニアを率いる技術リーダーのようで、全員が前進し、全員が指針を求めている、という体験と不思議なほど似ていました。
結果として、共同作業の流れが生まれました。Codex の純粋なコーディング能力によって、私たちは手作業でコードを書く負担から解放され、アーキテクチャについて考えたり、プルリクエストを注意深く読んだり、アプリをテストしたりする時間が増えました。
一方で、そのスピードの向上は、常にレビュー待ちの作業がキューに溜まっている状態を意味しました。Codex は作業の切り替えで手を止めることはありませんが、私たちはそうはいきません。開発におけるボトルネックは、コードを書くことから、意思決定、フィードバック、変更の統合へと移っていきました。
ここでブルックスの洞察が新たな形で当てはまります。プロジェクトにエンジニアを追加してもスケジュールが線形に加速しないのと同じように、Codex セッションを増やせば線形にスピードアップする、というわけではありません。仮想的なものであっても、「手」が増えるほど調整コストは増大します。私たちは Codex によって、単に速いソロプレイヤーになったのではなく、オーケストラの指揮者へと役割が変わったのです。
私たちのプロジェクトが始まる際、大きな足がかりがありました。Sora はすでに iOS でリリースされていたのです。私たちは頻繁に Codex に iOS とバックエンドのコードベースを参照させ、主要な要件や制約を理解させました。プロジェクトを通じて、「クロスプラットフォームフレームワークを再発明してしまった」と冗談を言っていました。React Native や Flutter は忘れてください。クロスプラットフォームの未来は Codex です。
この冗談の裏には、2つの原則があります。
- 「ロジックは移植可能である」。コードが Swift で書かれていようと Kotlin で書かれていようと、基盤となるアプリケーションロジック（データモデル、ネットワーク呼び出し、検証ルール、ビジネスロジック）は同じです。Codex は Swift の実装を読み、それと同等の意味を保持した Kotlin 実装を生成するのが非常に得意です。
- 「具体的な例は強力なコンテキストを提供する」。新しい Codex セッションが「iOS ではこう動いている」という具体例と、「Android のアーキテクチャはこうだ」という情報を同時に参照できる場合、自然言語の説明だけで作業する場合よりもはるかに効果的に機能します。
これらの原則を活かし、iOS、バックエンド、Android のリポジトリを同じ環境で利用できるようにしました。そして Codex には次のようなプロンプトを与えました：
「iOS コード内のこれらのモデルとエンドポイントを読み、既存の API クライアントとモデルクラスを使って、Android で同等の振る舞いを実装するための計画を提案してください」
小さいながらも有用だった工夫の1つは、~/.codex/AGENTS.md にローカルリポジトリの場所と内容を詳しく記載しておくことでした。これにより、Codex が関連するコードを発見し、ナビゲートできるようになりました。
私たちは、共通の抽象化ではなく「翻訳」によりクロスプラットフォーム開発を行っていたのです。Codex がその大部分を担ってくれたおかげで、実装コストを二重に支払う必要がありませんでした。
より広い教訓としては、Codex にとってコンテキストこそがすべてだということです。iOS で機能がどのように動いているかを理解し、同時に Android アプリの構造を理解しているとき、Codex は最高の仕事をしてくれました。そのコンテキストが欠けている場合、Codex は「協力を拒否している」のではなく、推測しているだけなのです。新しいチームメンバーとして扱い、適切なインプットを与えることに投資すればするほど、パフォーマンスは向上しました。
4週間のスプリントの終わりには、Codex を使うことは実験ではなく、私たちのデフォルトの開発ループになっていました。既存コードの理解、変更の計画、機能の実装に Codex を使い、その成果をチームメンバーのものと同じようにレビューしました。それが、私たちがソフトウェアを開発するやり方になっていたのです。
AI 支援開発は、厳密さの必要性を減らすのではなく、むしろ高めることが明らかになりました。Codex は非常に有能ですが、その目的は「今すぐ A から B に到達する」ことです。だからこそ、AI 支援コーディングは人間なしでは成り立ちません。ソフトウェアエンジニアは、システムにおける現実世界の制約を理解し、最適なアーキテクチャを適用し、将来の開発やプロダクト計画を見据えて構築することができます。未来のソフトウェアエンジニアにとって強力な武器とは、深いシステム理解と、長期的な視野で AI と協働する能力です。
ソフトウェアエンジニアリングの最も面白い部分は、魅力的なプロダクトを作ること、スケーラブルなシステムを設計すること、複雑なアルゴリズムを書くこと、そしてデータやパターン、コードを実験することです。しかし、過去も現在もソフトウェアエンジニアリングの現実は、ボタンの位置揃え、エンドポイントの接続、ボイラープレートの記述といった、より地味な作業に多くの時間を割くことでした。今や Codex によって、ソフトウェアエンジニアリングの本当に意味のある部分、そして私たちがこの仕事を愛する理由に集中できるようになりました。
一度 Codex を目標や開発スタイルを理解できるコンテキスト豊かな環境にセットアップすれば、どんなチームでもその能力を何倍にも高めることができます。今回のリリースの振り返りはどのようなチームにも当てはまる万能の解決法ではありませんし、AI 支援開発を解決したと主張するつもりもありません。しかし、私たちの経験が、Codex を活かしてあなたの能力を強化する最良の方法を見つける手助けになれば幸いです。
7か月前に Codex がリサーチプレビューとして公開されたとき、ソフトウェアエンジニアリングの姿は今とは大きく異なっていました。Sora を通じて、私たちはエンジニアリングの次の章を探ることができました。モデルやツールが進化し続けるにつれ、AI はソフトウェア開発においてますます不可欠な存在になっていくでしょう。
あなたは Codex を活用したチームで何を作りますか？
