giftee Tech Blog

ギフティの開発を支えるメンバーの技術やデザイン、プロダクトマネジメントの情報を発信しています。

GitHub CLIとAGENTS.mdで「自律駆動のAIエンジニア」をローカル環境で実現する

こんにちは。エンジニアの安達です。普段はカタログギフトなどの開発に携わっています。また、社内のワーキンググループとして、AI開発ツールの導入推進にも関わっています。

今回は、OpenAI Codexのようなコーディングエージェントをローカル環境で動かすユースケースについて、GitHubと連携した自律的な開発を可能とする手法について紹介します。

この記事でできるようになること

develop issue <ISSUE_NUMBER> && create pr

このように、独自に定義されたコマンドのようなプロンプトを用いて、コーディングエージェントに依頼できるようになります。

上の例で言うと、指定された番号のGitHub Issueについて、PRの作成まで開発を実行します。

OpenAI Codexの驚き

最近、ギフティでも、コーディングエージェントのOpenAI Codexを導入しました。

私も日々の開発で利用しているのですが、2025年9月にリリースされた、コーディング特化型モデルのGPT‑5-Codexの性能が非常に高い印象で、アウトプットの精度の高さに驚いています。

openai.com

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がこのように述べているように、GPT‑5-Codexは従来のモデルとは異なり、AIが暴走しないように細かい指示や工夫をせずとも、簡単な依頼で高度な実装ができるようになっていると感じます。

AIに人間のように自律的に開発してもらいたい気持ち

日常の業務で、やることが非常に多く、忙しい中で、AIには、人間に仕事を依頼するときと同じように、できるだけ丸投げに近い形で、自律的にタスクをこなしてもらいたい気持ちがあります。

devin.ai

その点で、私はDevinのユーザー体験が好きです。Devinは「完全自律型のAIエンジニア」を標榜している、クラウドサーバーで動作するタイプのツールです。GitHubのIssueを指定して依頼すると、PR作成まで全自動で進めてくれるような機能性になっています。Devinはギフティでも導入されていて、便利に活用されています。

developers.openai.com

CodexにもDevinのようにクラウドサーバーに開発環境をセットアップする機能が存在します。その一方で、Devinとは異なり、現状ではDocker Composeを使えないなどの制約があり、実用面でのハードルがある印象です。2025年10月現在のCodexは、手元のローカル環境で動かす使い方がメインになると思います。

その一方で、ローカル環境で動かすツールだとしても、GitHub CLIを使えば、人間のようにGitHubを読み書きする自律的な開発が可能になると気づきました。

cli.github.com

以下はGitHub CLIがインストールされていて、ghコマンドが動作する環境を前提とした説明になります。

GitHub CLIを用いたGitHubとの連携

ローカル環境でGitHub CLIのghコマンドを動かせる状態になっていると、コーディングエージェントもGitHub CLIを介して、GitHubの情報の読み書きができます。

ghコマンドを使ってissue <ISSUE_NUMBER>の実装をしてください

そのため、上のようにコーディングエージェントに依頼するとGitHubと連携した開発が可能になります。

agents.md

これだけでも便利ですが、コーディングエージェントに対する設定を記載する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コーディングエージェント向けのガイドライン

AIコーディングエージェント向けのガイドラインを記載します。ローカル環境でDockerとGitHub CLIが動作することを前提としています。

## ローカル環境でのコマンド実行方法

ローカル環境でコマンドを実行する場合は、直接コマンドを実行せず、常に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のコードレビューをします

おわりに

Codexに対して、この設定ファイルの内容で開発依頼を試して、期待通りに動作することが確認できています。実際に動作確認ができているのはCodexのみですが、その他のコーディングエージェントに対しても応用できる手法だと思います。

こういうザックリとした日本語の自然言語の設定記述で、コーディングエージェントに対するマクロのようなものがよしなに動くようになっていることには、様々な応用可能性を感じます。