はじめに
Codexのクラウド環境を触っていて、あらためて感じたことがあります。
これは単に「AIがコードを書いてくれる場所」ではありません。リポジトリを読み、タスクを理解し、必要なファイルを編集し、テストやビルドを実行し、公開前の成果物として差分をまとめる。そこまでを、ローカルPCから切り離されたクラウド上の作業環境で進められる点に価値があります。
OpenAIの開発者向けドキュメントでも、CodexはGitHubアカウントと接続することで、リポジトリ上の作業やPull Request作成に使える環境として説明されています。また、Codexの紹介記事では、機能追加、バグ修正、コードベースに関する質問、Pull Requestの提案などを、クラウド上のサンドボックス環境で実行できるものとして位置づけられています。
この構造は、私たちが提唱しているAI仕様駆動開発と相性がよいと考えています。
AI仕様駆動開発では、AIに「いい感じに作って」と依頼するのではなく、仕様、制約、受け入れ基準、レビュー観点を明文化して渡します。Codexのクラウド環境は、その仕様を実際の開発タスクへ変換し、記事ファイルやコード差分を作るための実行基盤になり得ます。ただし、本番公開までをクラウド環境だけで完結させるものではありません。
この記事では、Codexのクラウド環境で何ができるのかを整理しながら、AI仕様駆動開発の観点でどのように活用できるかを考えます。
Codexのクラウド環境でできること
Codexのクラウド環境で重要なのは、AIがチャット上で助言するだけでなく、実際の開発作業に近い単位で動けることです。
たとえば、次のような流れを任せられます。
- リポジトリの構成を読む
- 既存の実装パターンやドキュメントを確認する
- 指定されたIssueや要件に沿ってファイルを編集する
- 型チェック、テスト、ビルドなどを実行する
- 変更差分を確認し、必要なら修正する
- 変更差分をまとめる
- GitHub連携が整っていればPull Requestとして提案する
もちろん、Codexだけで本番環境へ直接公開するわけではありません。また、クラウド上の作業画面は、PCのターミナルで自由にGitコマンドを実行する環境とは分けて考えた方が安全です。GitHub上の権限やリポジトリ設定、組織のセキュリティ設定によって、実際にどこまで自動化できるかは変わります。
現実的には、Codexクラウドに任せる中心は「公開できる記事ファイルやコード差分を作ること」です。PR作成は、その差分を受け渡すための便利な方法の一つです。最終的な確認、merge、本番公開は、人間がPC上で行う作業として残しておく方が、運用として分かりやすいと感じています。
ただし、開発プロセスとして見ると、重要なのは「AIが実行できる範囲が広がった」ことではありません。
重要なのは、AIに渡す仕様の品質が、そのまま成果物の品質に反映される環境になったということです。
なぜクラウド環境がAI仕様駆動開発に向いているのか
AI仕様駆動開発では、開発タスクを「AIが迷わず実行できる単位」に分解します。
たとえば、人間に対しては次のような依頼でも通じるかもしれません。
ブログ記事を追加して、公開できる状態まで整えておいて。
しかし、AIに安定して任せるなら、もう少し構造化したほうがよい。
目的:
Codexのクラウド環境で、AI仕様駆動開発が実現できることを説明するブログ記事を追加する。
対象:
feelflow-site/src/content/blog/<slug>/index.mdx
受け入れ基準:
- Astro Content Collections の blog schema を満たす
- author は active author registry の値を使う
- draft: false で公開対象にする
- Codexの機能説明は公式情報に基づき、過度な断定を避ける
- pnpm check と pnpm build が通る
制約:
- develop / main には直接pushしない
- クラウド側の完了条件は記事ファイルと検証結果の提示までにする
- PRを作る場合も、mergeと本番公開はPC上で確認してから行うこのように書くと、AIは「何を作るか」だけでなく、「どのルールに従うか」「何をもって完了とするか」を理解できます。
クラウド環境のCodexは、リポジトリ内のドキュメントやAGENTS.md、スキル、既存記事、設定ファイルを読みながら作業できます。つまり、仕様がリポジトリに残っていれば、AIは毎回その文脈を読み直して実装に反映できます。
これは、AI仕様駆動開発における大きな前提です。
仕様がチャットの中だけにあると、再利用できません。Issue、README、AGENTS.md、設計ドキュメント、レビューガイド、Playbookとして残っていれば、次のタスクでもAIが参照できます。
クラウド環境は、その「仕様を読むAI」と「実装するAI」を同じ作業単位に近づけます。
Issueが、AIへの作業指示書になる
Codexを活かすうえで、GitHub Issueの役割はさらに重要になります。
従来のIssueは、人間同士の作業メモとして使われることが多かったと思います。背景、やりたいこと、関連リンク、完了条件が書いてあれば十分、という使い方です。
AI仕様駆動開発では、IssueをAIへの作業指示書として扱います。
良いIssueには、少なくとも次の情報を含めます。
- 背景: なぜこの変更が必要なのか
- 目的: 何を達成したいのか
- 対象範囲: どのファイル、画面、機能を触るのか
- 非対象範囲: 今回やらないことは何か
- 受け入れ基準: 完了判定に使う条件
- 制約: 守るべき設計、文体、セキュリティ、運用ルール
- 検証方法: どのコマンドや画面で確認するか
ここまで書くと、Issueは単なるチケットではなくなります。AIが作業を開始するための仕様書になります。
Codexのクラウド環境では、Issueを起点に実装し、公開前の差分を作る流れを設計できます。GitHub連携が整っていればPRとして受け取ることもできます。人間は「AIに毎回説明する」のではなく、「AIが読めるIssueを書く」ことに集中できます。
この変化は小さく見えて、開発組織にとっては大きい。
AI活用のボトルネックが、プロンプトの技巧から、仕様の設計へ移るからです。
差分は、レビュー可能な境界で受け取る
CodexがPRを提案できるようになると、「AIが作ったものをそのままmergeする」ことに意識が向きがちです。
しかし、AI仕様駆動開発では、PRをAIの最終成果物とは考えません。PRは、あくまで差分をレビューするための一つの形です。
重要なのは、AIの作業結果をレビュー可能な境界で受け取ることです。
AIが実装し、人間または別のAIがレビューし、必要な修正を加え、品質を収束させる。そのための単位として、PRや差分レビューを使います。
この考え方を取ると、AIに任せるタスクの粒度も変わります。
大きすぎる差分は、人間にもAIにもレビューしづらい。影響範囲が広すぎると、どこで品質を判断すればよいか分からなくなります。逆に、Issueと差分を小さく保てば、受け入れ基準に照らして確認しやすくなります。
Codexには、GitHub PRに対するコードレビュー機能も用意されています。OpenAIのドキュメントでは、Pull Requestの差分をレビューし、重大な問題に焦点を当ててGitHub上にレビューを投稿する用途が説明されています。
つまり、Codexは「実装するAI」としてだけでなく、「レビューするAI」としても使えます。
ここでも重要なのは、レビュー観点を明文化することです。
- 既存パターンに従っているか
- schemaや型を壊していないか
- 公開前の記事が漏れないか
- セキュリティ上の情報を含んでいないか
- テストやビルドが通っているか
- 仕様で定めた非対象範囲に踏み込んでいないか
AIレビューも、人間レビューと同じで、観点が曖昧だと網羅性が落ちます。レビューガイドやAGENTS.mdに観点を残しておくことで、Codexはそのルールを読みながらレビューできます。
公開は、PC上の最終確認から先に置く
ここでいう「公開」は、Codexが本番サーバーへ直接ファイルをアップロードする、という意味ではありません。
実務上は、次のような分担になります。
- Codexが仕様を読み、記事ファイルやコード差分を作る
- Codexが可能な範囲で検証コマンドを実行し、結果を示す
- 必要であれば、GitHub連携でPull Requestとして差分を受け取る
- 人間がPC上で内容確認、Git操作、merge、release判断を行う
- VercelがGitHubのmainブランチ更新を検知し、本番へdeployする
つまり、Codexクラウドで実現できるのは「記事を書く」だけではなく、公開前の成果物を仕様に沿って整えることです。そしてVercelがmainブランチをProductionとして監視していれば、PC上で確認してmergeした後に本番公開へつながります。
この分担を明確にしておくと、「AIに公開まで丸投げする」のではなく、「AIが公開前の記事データを整え、人間がPC上で公開判断を行い、Vercelがdeployする」という安全な流れを作れます。
「クラウドに任せる」と「丸投げする」は違う
Codexのクラウド環境が便利になるほど、注意したいことがあります。
それは、クラウドに任せることと、丸投げすることを混同しないことです。
AIに任せる範囲が広がるほど、最初の仕様が重要になります。曖昧なIssueを渡せば、AIは曖昧なまま実装します。制約を書かなければ、既存の設計思想とズレる可能性があります。検証コマンドを書かなければ、どこまで確認すべきかをAIが推測することになります。
AI仕様駆動開発で目指しているのは、人間が何もしなくてよい開発ではありません。
人間の役割を、手作業の実装から、仕様設計、境界設定、レビュー、ナレッジ化へ移すことです。
Codexのクラウド環境は、その移行を後押しします。
ローカルPCに張り付かなくても、タスクをクラウドに委任できる。複数の作業を並行して進められる。公開前の記事ファイルや差分という形で成果物を受け取れる。レビューで見つかった問題を、次のIssueやPlaybookに戻せる。
この一連の流れが整うと、AI開発は単発の効率化ではなく、チームの開発プロセスになります。
このプロジェクトでの記事追加を例にすると
フィールフロウのWebサイトでは、記事はAstro Content CollectionsのMDXとして管理しています。
Codexに記事追加を任せる場合、AIは次のような作業を行えます。
AGENTS.mdを読み、ブランチ運用や検証コマンドを確認する- blog collectionのschemaを確認する
- author registryを確認し、正しい著者名を使う
- 近いテーマの既存記事を読み、文体や構成を合わせる
src/content/blog/<slug>/index.mdxを作成する- frontmatterの
title,date,author,tags,excerpt,draftを整える - 本文を書く
- Prettier、型チェック、ビルドを実行する
- 変更内容と検証結果をまとめる
- 必要であれば、Pull Requestとして差分を渡す
これは、単に「AIが文章を書く」よりも広い作業です。
コンテンツモデル、公開制御、著者管理、ビルド検証まで含めて、記事追加という業務を一つの開発タスクとして扱っています。
一方で、PC上に残す作業もあります。
- 記事内容を最終確認する
- 必要に応じてローカルで追加検証する
- Git操作、merge、release判断を行う
- VercelのProduction Deployで本番反映を確認する
この線引きをしておくと、Codexクラウドに任せる仕事は「公開できる記事データを作ること」だと説明しやすくなります。PR作成は便利な受け渡し手段ですが、公開そのものはPC上で人間が責任を持って進める。現時点では、この分担が一番現実的だと感じています。
まさに、AI仕様駆動開発で扱いたい単位です。
導入時に決めておきたいこと
Codexのクラウド環境をチームで使うなら、最初に決めておきたいことがあります。
1. AIに任せてよい範囲
軽微な修正、記事追加、テスト追加、リファクタリング、依存関係更新など、どこまでをCodexに任せるかを決めます。
その範囲は「公開前の成果物を作るところまで」なのか、「Pull Request作成まで」なのか、「レビュー指摘の反映まで」なのか。ここを曖昧にしないことが大切です。
特に、本番影響が大きい変更、認証・決済・個人情報に関わる変更、インフラ設定の変更は、レビュー観点を強める必要があります。
2. Issueのテンプレート
AIに渡すIssueには、目的、受け入れ基準、制約、検証方法を必ず含める。これだけで成果物の安定性は大きく変わります。
3. 受け渡しと公開判断の方針
Codexクラウドの成果物を、差分として確認するのか、Pull Requestとして受け取るのかを決めます。さらに、公開判断は誰がPC上で行い、どのブランチへmergeし、どのタイミングでVercelの本番反映を確認するのかも明文化しておきます。
feature PRはsquash merge、release PRはmerge commitなど、チームの履歴設計がある場合は、そのルールもAIが読める場所に置いておくと安全です。
4. レビューとナレッジ蓄積
AIが作ったPRで見つかった指摘を、その場限りで終わらせないことが重要です。
「次から同じミスをしないために、どのドキュメントへ何を追記するか」を決める。これにより、AI活用は回数を重ねるほど安定していきます。
まとめ
Codexのクラウド環境は、AI仕様駆動開発を実践するうえで強力な実行基盤になり得ます。
ポイントは、AIに任せられる範囲が広がったことそのものではありません。
仕様、Issue、レビュー観点、検証コマンド、ブランチ運用、ナレッジ蓄積を整えることで、AIがクラウド上で迷わず作業できる状態を作れることです。
AI開発の主役は、魔法のプロンプトではありません。
AIが読める仕様です。
Codexのクラウド環境は、その仕様を実際の記事ファイル、コード変更、テスト結果、レビュー可能な差分へ接続する場所になります。
そして公開は、PC上で人間が最終確認し、GitHubとVercelの流れに乗せて行う。この境界をはっきりさせることで、AIに任せる範囲と人間が責任を持つ範囲を分けられます。
だからこそ、これからの開発チームに必要なのは、「AIにどう頼むか」だけではなく、「AIが働ける開発プロセスをどう設計するか」です。
AI仕様駆動開発は、そのための方法論です。