2025年の9月に、GPT‑5-Codexが登場してから、OpenAI Codexがすごく便利だ。
It’s more steerable, adheres better to AGENTS.md instructions, and produces higher-quality code—just tell it what you need without writing long instructions on style or code cleanliness.
GPT‑5-Codexはより指示に従いやすく、AGENTS.md のガイドに忠実で、高品質なコードを出力します—スタイルやコードのクリーンさに関する冗長な指示を書かずとも「必要なこと」を伝えれば動きます。
OpenAIがこう述べているように、従来のコーディングエージェントとは異なり、AIが暴走しないように細かい指示や工夫をせずとも、簡単な依頼で高度な実装ができるようになっている。
この性能で、月額20ドルのChatGPT Plusプランでも利用できるのだから驚きだ。
最近は、仕事でも個人開発でも、Codexを使い倒している。
この記事では、私が最近ハマっている、CodexにGitHub CLIを使わせてGitHubと連携する開発手法について書きたい。手法としては、Codex以外のコーディングエージェントに対しても応用可能だと思う。
AIに人間のように自律的に開発してもらいたい気持ち
仕事でもプライベートでも、やることが非常に多く、忙しい中で、AIには、人間に仕事を依頼するときと同じように、できるだけ丸投げに近い形で、自律的にタスクをこなしてもらいたい気持ちがある。
その点で、私はDevinのユーザー体験が好きだ。Devinは「完全自律型のAIエンジニア」を標榜している、クラウドサーバーで動作するタイプのツールで、GitHubのIssueを指定して依頼すると、PR作成まで全自動で進めてくれるような機能性になっている。
CodexにもDevinのようにクラウドサーバーに開発環境をセットアップする機能が存在するが、Devinとは異なり、Docker Composeを使えないなど、実用面で今ひとつ機能が足りない印象がある。現在のCodexは、手元のローカル環境で動かす使い方がメインになるだろう。
その一方で、ローカル環境で動かすツールだとしても、GitHub CLIを使えば、人間のようにGitHubを読み書きする自律的な開発が可能になると気づいた。
以下はGitHub CLIがインストールされていて、ghコマンドが動作する環境を前提とした説明になる。
ghコマンドを活用した依頼
ghコマンドを使ってissue 123の実装をしてください
ghコマンドが動作する環境では、デフォルト設定のCodexでも、上のように依頼すれば、GitHubと連携した開発が可能になる。
これだけでも便利だが、設定ファイルのAGENTS.mdに、依頼に使えるプロンプトと作業内容を定義することで、よりまとまった量の作業を簡単に依頼できるようになる。
AGENTS.mdでのプロンプト定義
## 作業依頼のプロンプト ### Issueの開発 ```text develop issue <ISSUE_NUMBER> ``` このように依頼された場合は、以下を実行します。 - ghコマンドで指定された<ISSUE_NUMBER>のissueの内容を確認します - 開発用のGitブランチを新しく作成します - 開発します ### PR作成 ```text create pr ``` このように依頼された場合は、以下を実行します。 - ghコマンドでprを作成します ### コードレビュー ```text review pr <PR_NUMBER> ``` このように依頼された場合は、以下を実行します。 - ghコマンドで<PR_NUMBER>のprのコードレビューをします
AGENTS.mdにこのように書いておくと、 コーディングエージェントに依頼する際に、以下のようなプロンプトが動作するようになる。
# #123のIssueを開発する develop issue 123 # PRを作成する create pr # #123のPRをコードレビューする review pr 123 # &&でプロンプトをつないでもいい感じに解釈してくれる # #123のIssueを開発してPRを作成する develop issue 123 && create pr
GitHub利用に関する運用ルールの追加
ただし、これだけでは現場の開発ルールに従ったアウトプットができないので、以下のように、GitHub利用に関する運用ルールをAGENTS.mdに追加する。
## Git運用 - `feature/` から始めるブランチ名とします - コミットメッセージはConventional Commitsのスタイルとします ## GitHub PR作成 GitHubのPR作成を指示された場合は、以下の方針でPRを作成します。 - タイトルは開発対象のIssueと同じとします - PRの説明を記載します - `Resolves` の記法を用いて開発対象のIssueと紐づけます - assigneeに実装者を指定します
開発環境セットアップ・構文チェック・テスト実行のコマンド整備
また、開発環境のセットアップや構文チェック、テスト実行のコマンド群も記載しておくと、AIが自律的に自らのコードの正しさを検証できるようになる。
例えばRailsアプリケーションをDocker Composeで動かす場合は、以下のような記載になるだろう。
## コマンドの実行方法 Rails関連のタスクを実行する際は、ローカル環境で直接コマンドを実行せず、常にDocker Compose経由でコンテナ内のアプリケーションにアクセスします。 ## コマンドリスト - Install: `docker compose run --rm app bundle install` - Migrate: `docker compose run --rm app bin/rails db:migrate` - Lint: `docker compose run --rm app bin/rubocop` - Test: `docker compose run --rm app bin/rspec`
AGENTS.mdの全容
ここまでの内容をまとめると、以下のようなAGENTS.mdファイルになる。
# AIコーディングエージェント向けのガイドライン ## コマンドの実行方法 Rails関連のタスクを実行する際は、ローカル環境で直接コマンドを実行せず、常にDocker Compose経由でコンテナ内のアプリケーションにアクセスします。 ## コマンドリスト - Install: `docker compose run --rm app bundle install` - Migrate: `docker compose run --rm app bin/rails db:migrate` - Lint: `docker compose run --rm app bin/rubocop` - Test: `docker compose run --rm app bin/rspec` ## Git運用 - `feature/` から始めるブランチ名とします - コミットメッセージはConventional Commitsのスタイルとします ## GitHub PR作成 GitHubのPR作成を指示された場合は、以下の方針でPRを作成します。 - タイトルは開発対象のIssueと同じとします - PRの説明を記載します - `Resolves` の記法を用いて開発対象のIssueと紐づけます - assigneeに実装者を指定します ## 作業依頼のプロンプト ### Issueの開発 ```text develop issue <ISSUE_NUMBER> ``` このように依頼された場合は、以下を実行します。 - ghコマンドで指定された<ISSUE_NUMBER>のissueの内容を確認します - 開発用のGitブランチを新しく作成します - 開発します ### PR作成 ```text create pr ``` このように依頼された場合は、以下を実行します。 - ghコマンドでprを作成します ### コードレビュー ```text review pr <PR_NUMBER> ``` このように依頼された場合は、以下を実行します。 - ghコマンドで<PR_NUMBER>のprのコードレビューをします
まとめ
このような設定をすることで、GitHubのIssueに開発チケットを起票してAIに依頼するだけで、開発がドンドン進む環境が手に入る。もう昔の開発スタイルには戻れないな、という感じがしている。
