Codexと開発していると、任せたい作業が少しずつ増えてきます。
最初はコードの調査や修正だけでしたが、そのうちテストを実行し、コミットを作り、Issueへ結果を残すところまで任せたくなりました。そこで気になったのが、CodexがGitHubを操作するときの名義です。
普段使っている自分のアカウントでCodexがIssueへコメントすると、GitHub上では自分が書いたのか、Codexが書いたのか分かりません。コミットも同じです。
そこでCodex専用のGitHubアカウントを用意し、GitHub上の操作とコミットのidentityを人間から分離しました。GitHub Issuesをタスクの正本にし、Codexがどこまで操作してよいかはAGENTS.mdへ書いています。
今回作りたかったのは、AIの能力を上げる仕組みではありません。AIへ作業を任せても、誰が何をしたのか、最後に誰が判断するのかが曖昧にならない環境です。
実際にCodexへ任せる範囲を広げて感じたのは、作業を始めてから制限するより、先に境界を決めておく方が進めやすいということでした。GitHubで許可する操作だけでなく、新しく生成するシステムのフォルダ構成や、設定、ソースコード、データをどこへ置くかも先に決めています。
Codexが迷うたびに配置先を確認する必要がなくなり、こちらも想定外の場所へファイルが増えていないかを確認しやすくなりました。権限と同じように、ファイルの置き場所もAIと開発するための境界の一つだと考えています。
- Redmineを使ってみて、GitHub Issuesの役割も見えてきた
- Codex専用アカウントを用意した
- Fine-grained PATを必要なリポジトリだけに発行する
- Codexを起動するときだけGH_TOKENを渡す
- コミットのidentityも一時指定にした
- GitHub Issuesをタスクの正本にする
- Issueを作る前に構成を確認する
- Issueには逐次ログではなく判断と結果を残す
- コミットからIssueは参照するが、自動Closeはしない
- 通常の停止地点をcommitにした
- AGENTS.mdへ操作範囲を書く
- 新しいシステムはファイルの置き場所も先に決める
- AI開発で改めて実感したこと
- AIに任せる範囲が広がるからこそ、境界を先に決める
- 参考
Redmineを使ってみて、GitHub Issuesの役割も見えてきた
前回、RedmineをSpec-driven Developmentの管理基盤として使ってみる。レガシーシステムとAI開発をつなぐという記事を書きました。
Redmineは、複数のリポジトリやGitで管理していない作業まで横断し、仕様や制約を残すには便利です。一方で、一つのGitHubリポジトリの中で完結する開発まで、必ずRedmineへ持っていく必要はありません。
GitHub上のコードとIssueを直接結び付けたい小さな開発では、GitHub Issuesの方が自然です。Sub-issuesを使えば、大きな作業だけ親Issueと子Issueに分けることもできます。
今回の使い分けは、次のように考えています。
複数システムをまたぐ仕様や作業 → Redmine 一つのGitHubリポジトリで完結する作業 → GitHub Issues
どちらを使う場合でも共通していたのは、人間とCodexを同じユーザーにしない方が履歴を追いやすいということでした。RedmineではAgent Userを作ったので、GitHubでも同じ考え方を試しました。
Codex専用アカウントを用意した
GitHubの利用規約には、自動化されたタスク専用に使うmachine accountという考え方があります。2026年8月時点の規約では、無料のPersonal Accountに加えて、無料のmachine accountを一つ持てるとされています。アカウントの作成と管理には人間が責任を持ち、machine accountは自動化されたタスクだけに使うことが条件です。
今回はそのmachine accountとして、Codex専用アカウントを作りました。以下では仮にcodex-userとします。
普段使いのGitHubアカウント ├─ 最終確認 ├─ push、Pull Request、mergeの判断 └─ IssueのClose Codex専用GitHubアカウント ├─ Issueの作成とコメント ├─ ソースコードの修正 ├─ テスト └─ commit
アカウントを作ったあと、対象のPrivate Repositoryへアクセスできるようにします。Organizationで管理しているなら、Codex用アカウントを必要なリポジトリだけに参加させます。個人所有のリポジトリなら、Collaboratorとして招待する方法があります。
専用アカウントを作るだけでは権限分離は完成しません。リポジトリへ与える権限と、後述するPersonal Access Tokenの権限も必要最小限にします。
Fine-grained PATを必要なリポジトリだけに発行する
Codex用アカウントで、Fine-grained Personal Access Tokenを発行しました。
対象はすべてのリポジトリではなく、Codexに操作させるリポジトリだけです。権限も用途に合わせて絞ります。
Issueの参照だけ → Issues: Read-only Issueの作成・コメント → Issues: Read and write リポジトリ内容の参照 → Contents: Read-only Git経由のpushも許可 → Contents: Read and write
実際に必要な権限は操作するAPIによって変わります。GitHubの公式ドキュメントにあるFine-grained PATに必要な権限を確認し、最初から広い権限を渡さないようにしました。
今回の通常の停止地点はcommitです。リモートへのpushまで許可しないなら、PATへContentsの書き込み権限を与えない方が明確です。AGENTS.mdに「pushしない」と書くのは運用上の制約ですが、PATの権限を削るのはGitHub側で効く制約です。
発行したPATはリポジトリへ置かず、ローカルの設定ファイルへ保存しました。
mkdir -p ~/.config/codex chmod 700 ~/.config/codex nano ~/.config/codex/github-token chmod 600 ~/.config/codex/github-token
もちろん、PATそのものはGitへコミットしません。シェルの履歴やCodexとのチャットにも貼らないようにします。
保存したPATで、Codex用アカウントとして認証できるか確認します。
GH_TOKEN="$(< ~/.config/codex/github-token)" gh api user
返ってきたloginがCodex用アカウントなら、意図したPATを使えています。対象リポジトリも確認しました。
GH_TOKEN="$(< ~/.config/codex/github-token)" \ gh repo view OWNER/REPOSITORY
ここでは出力だけでなく、Codexに許可していないPrivate Repositoryが見えないことも確認します。
Codexを起動するときだけGH_TOKENを渡す
普段使っているGitHub CLIのログイン先を、Codex用アカウントへ切り替えることはしませんでした。
GitHub CLIはGH_TOKENが設定されている場合、保存済みの認証情報よりもそちらを優先します。そのため、Codexを起動するときだけ環境変数として渡します。
GH_TOKEN="$(< ~/.config/codex/github-token)" codex
これで、普段のターミナルとCodexプロセスを分けられます。
普段のターミナル
└─ 自分のGitHub認証
Codexプロセス
└─ GH_TOKEN
└─ Codex専用GitHubアカウント
GitHub CLIの認証状態やcredential helperをCodex自身に変更させないことも、AGENTS.mdへ書きました。認証方法をCodexに切り替えさせるのではなく、起動する側で使う資格情報を決める形です。
なお、この方法で分離されるのはghや、GH_TOKENを参照する処理です。git pushがどの認証情報を使うかは、remote URL、credential helper、SSH鍵など別の設定に左右されます。pushまでCodex用アカウントへ分離する場合は、Gitの認証経路も別途確認する必要があります。
コミットのidentityも一時指定にした
GitHub APIの認証と、Gitのコミットに記録される名前やメールアドレスは別物です。
Codexが作ったコミットも専用ユーザーとして記録したかったので、コミット時だけidentityを指定することにしました。
git \ -c user.name="codex-user" \ -c user.email="12345678+codex-user@users.noreply.github.com" \ commit -m "feat: 機能を追加"
12345678+codex-user@users.noreply.github.comの部分には、Codex用アカウントのGitHub設定に表示されるnoreplyアドレスを使います。値を推測せず、実際のアカウント設定で確認します。
この方法なら、次の設定を書き換えずに済みます。
git config --global user.name "..." git config user.name "..."
普段のGit設定はそのままで、Codexがコミットするときだけ名義を変えられます。
ただし、コミットのAuthorがCodex用になったからといって、そのコミットを誰がpushしたかまで同じになるわけではありません。コミットのidentity、GitHub APIの認証、Git remoteへの認証は別々に考える必要がありました。
GitHub Issuesをタスクの正本にする
GitHubをCodex用アカウントから操作できるようにしたので、リポジトリ内で完結するタスクはGitHub Issuesへ寄せました。
小さな作業まで毎回親Issueと子Issueに分けると、管理の方が重くなります。そこで、単独で完了できる作業は一つのIssueにし、複数の独立した作業が必要な場合だけSub-issuesを使います。
小さな作業
└─ 単一Issue
複数の作業に分ける意味がある変更
└─ 親Issue
├─ 子Issue
├─ 子Issue
└─ 子Issue
単なるチェックリストではなくSub-issuesとして関連付けておくと、GitHub ProjectsでもParent issueとSub-issue progressを表示できます。Projectsは別のタスク管理システムにせず、Issue全体を人間が見るためのビューとして使っています。
Issueを作る前に構成を確認する
CodexへGitHub Issuesの書き込みを許可しても、依頼を受けた時点で好きなだけIssueを作らせる運用にはしませんでした。
基本の流れは次のとおりです。
人間が作業を依頼
↓
CodexがIssue構成を考える
↓
人間が内容と分割単位を確認
↓
CodexがIssueを作成
↓
実装を開始
これはIssue作成を毎回面倒にするためではありません。作業の分割自体が設計判断になるからです。
明らかに一つのIssueで済む軽微な作業で、こちらからIssue化を明示した場合は再確認しません。一方、大きな親Issueの下へ何枚も子Issueを作る場合は、作る前に構成を確認するようにしました。
Issueには逐次ログではなく判断と結果を残す
「進捗をIssueへ記録する」とだけ決めると、Issueがコマンド実行の実況で埋まります。
後から知りたいのは、テストコマンドを打った順番ではありません。何を変更し、なぜその判断をし、どこまで確認できたかです。
そのため、CodexがIssueへ書く内容を次に絞りました。
- 作業開始
- 重要な判断や仕様変更
- 作業が止まった理由
- 人間の判断が必要なこと
- 最終的な変更内容
- 検証方法と結果
- 残っている制約
単なるファイル参照やコマンド実行は書きません。Issueは実況ログではなく、変更の理由と結果を後から追う場所として使います。
コミットからIssueは参照するが、自動Closeはしない
コミットメッセージには、関連するIssue番号を残します。
feat: ○○機能を追加 Refs #123
一方で、次のキーワードはCodexに使わせません。
Fixes #123 Closes #123 Resolves #123
これらは既定ブランチへマージされたときにIssueを自動でCloseするためのキーワードです。今回の運用では、実装とテストが終わったことと、そのIssueを完了と判断することを分けました。
Codexが実装を完了 ≠ 人間がIssueをClose
CodexはIssueへ変更内容とテスト結果を記録します。人間が内容を確認し、問題ないと判断したあとでCloseします。
通常の停止地点をcommitにした
push、Pull Request作成、merge、releaseは、明示的に依頼した場合だけ実行するルールにしました。
Codexの通常の作業範囲は次のとおりです。
Issueを確認
↓
実装
↓
テスト
↓
commit
↓
Issueへ変更内容と検証結果を記録
↓
commit SHAを報告して停止
ここから先へ進めるかは人間が決めます。
この境界は、AGENTS.mdだけでなくPATの権限でも合わせる必要があります。pushを通常許可しないならContentsをRead-onlyにしておけば、指示上のルールとGitHub側の権限が一致します。必要なときだけ別の認証経路で人間がpushする方が、今の運用には合っていました。
AGENTS.mdへ操作範囲を書く
毎回同じ制約をチャットへ書かなくて済むように、リポジトリのAGENTS.mdへ操作範囲を明記しました。
考え方は次のようなものです。
通常許可する操作 ├─ Issueの参照 ├─ 承認済み構成でのIssue作成 ├─ Issueへのコメント ├─ ソースコードの変更 ├─ テスト └─ commit 明示的な指示が必要な操作 ├─ push ├─ Pull Requestの作成 ├─ merge └─ release 許可しない操作 ├─ Issueの自動Close ├─ GitHub CLIの認証設定変更 ├─ globalまたはlocalのGit identity変更 └─ GH_TOKENの表示やリポジトリへの保存
ここで気を付けたいのは、AGENTS.mdが認可システムそのものではないことです。
GitHub側で実行できないようにするのがPATやリポジトリ権限で、実行できる範囲の中でどのように作業するかを決めるのがAGENTS.mdです。両方をそろえて、初めて意図した境界に近づきます。
新しいシステムはファイルの置き場所も先に決める
責任境界を考える中で、GitHubの操作権限とは別に効果があったのが、システムのフォルダ構成を実装前に決めておくことでした。
Codexは短時間で多くのファイルを作れます。その一方で、配置ルールが曖昧なまま「このシステムを作って」と依頼すると、機能としては動いても、設定ファイルやデータ、スクリプトの置き場所が自分の想定とずれることがあります。あとから移動すると、import、設定パス、Dockerのvolume、テストなども一緒に直すことになり、余計な作業が増えます。
そこで新しいシステムを作るときは、少なくとも最初に次のような配置を決めるようにしました。
system/ ├─ cmd/またはsrc/ アプリケーション本体 ├─ config/ 設定のひな形 ├─ scripts/ 開発・運用スクリプト ├─ tests/ テスト ├─ docs/ 設計や運用手順 └─ data/ 実行時データ
実際の名前や分け方は、言語やシステムの規模に合わせます。重要なのは、この構成を毎回そのまま使うことではなく、何をどこへ置くか、どこへは置かないかを実装前に共有することです。
たとえば、認証情報はリポジトリへ置かない、永続データはソースコードと分ける、再利用するスクリプトは一時ファイルにしない、といったルールも合わせて決めます。既存リポジトリなら、現在の構成をCodexに確認させ、そこへ合わせるようにします。
この準備をするようになってから、生成されたファイルをあとで整理する場面が減りました。Codexも配置先を判断しやすくなり、こちらの確認も「動くか」だけでなく「決めた場所に収まっているか」という基準で行えます。
GitHubの操作境界 → 何をしてよいかを決める フォルダとファイルの境界 → どこに何を作るかを決める
どちらも、Codexの動きを細かく監視するためのものではありません。先に判断基準を渡し、実装中の迷いと手戻りを減らすためのものです。
AI開発で改めて実感したこと
専用アカウントやフォルダ構成の分離は、AIが登場して初めて必要になった考え方ではありません。誰が変更したのかを履歴へ残すこと、必要以上の権限を与えないこと、設定やデータの置き場所を決めることは、以前から開発や運用の基本として分かっていたことです。
ただ、実際の業務では目の前の実装や障害対応を優先し、こうした土台の整理をないがしろにしてしまうことがありました。重要だとは分かっていても、今すぐ動くものを作ることに比べると、後回しになりやすい部分です。
Codexと開発するようになり、その重要性を改めて実感しました。AIは人間より短時間で多くのファイルを変更し、Issueやコミットも作れます。任せる範囲が広がるほど、操作主体、権限、停止地点、ファイルの配置が曖昧な場合の影響も大きくなります。
専用アカウントへ分けたことで、Issueでは自分が決めたことと、Codexが調査して追記したことをアカウント名で確認できるようになりました。コミットもCodex用のidentityになるため、あとから履歴を見たときに作業主体を判断しやすくなります。
一方で、「Codex専用アカウントを作れば終わり」ではありません。今回整理した境界は、次のように複数の要素に分かれています。
Identity → GitHubアカウントとcommit identityを分ける Authentication → Codex起動時だけGH_TOKENを渡す Authorization → PATとリポジトリ権限を必要最小限にする Working Rules → AGENTS.mdで通常の停止地点を決める File Placement → フォルダ構成と生成先を実装前に決める Task Management → GitHub IssuesとSub-issuesを正本にする Final Decision → push、採用、Issue Closeは人間が判断する
このうち一つだけ分けても、責任範囲はきれいに分かれません。特にGitHubの認証とコミットのidentityは別なので、それぞれを意識して設計する必要があります。
AIを使う目的は、空いた時間へさらに多くの実装を詰め込むことだけではないと思っています。調査や実装にかかる時間をCodexで短縮できたなら、その時間を、これまで忙しさを理由に後回しにしていた権限設計、ディレクトリ構成、テスト、運用ルールの整備へ使いたいところです。
AIが速く作れるからこそ、人間は何を作らせるかだけでなく、どの範囲で作らせるかを考える。今回の専用GitHubアカウントとIssue運用は、そのための土台を改めて整えたものです。
AIに任せる範囲が広がるからこそ、境界を先に決める
コードの提案だけを頼むなら、ここまでの仕組みは必要ありません。
しかし、Issueを作り、コードを変更し、テストし、コミットし、結果をGitHubへ戻すところまで任せると、Codexは単なるコード生成ツールよりも開発作業者に近くなります。
そこで必要になるのは、何でも自動化することではなく、どこまで任せ、どこで止まり、どこに何を作るかを先に決めることでした。
今のところ、Codexには決めた構成の中で実装と記録を任せ、リモートへ反映する判断とIssueを閉じる判断は自分で行う形が扱いやすいと感じています。専用アカウントを作った目的も、AIを目立たせることではなく、この境界をGitHubの履歴から確認できるようにすることです。
RedmineとGitHub Issuesは競合するものではなく、管理したい範囲で使い分けられます。複数システムをまたぐ仕様はRedmineへ、一つのリポジトリで完結する実装はGitHub Issuesへ。どちらでも、人間とCodexのidentityを分け、最終判断を人間に残す考え方は共通しています。
