前編では、Redmineの要求をAI Agentへ渡し、実装・CI・Pull RequestまでつなぐAIコーディング基盤の全体設計を整理しました。
この設計で重要なのは、単純な
Redmine
↓
ChatGPT
↓
Git
↓
AI Agent
ではなく、AI Agentへ渡す前に人間によるBriefの確認と承認を必須にすることです。
全体像は次のようになります。
Redmine
│
▼
人間がChatGPT Skillを起動
│
▼
Agent Brief生成
│
▼
人間がレビュー・承認
│
▼
Git Writer MCP
│
▼
承認済みAgent Brief
│
▼
Brief Ready
│
▼
Handlerによる検証
│
▼
Ready for Agent
│
▼
Agent Controller
│
▼
GCE Agent Worker
│
▼
Codex / Claude Code
│
▼
Application Git
│
▼
CircleCI
│
▼
Pull Request
ここで重要なのは、ChatGPT Skillは自動実行パイプラインの一部ではないという点です。
ChatGPT Skillは人間が起動し、Redmineの要求をAgent Briefへ変換するために使います。
一方、
Ready for Agent
↓
Agent
↓
Git
↓
CI
という実行ループはAgent Controller側で完結させます。
今回の実装編では、この設計を実際に動かすための最小構成を考えます。
最初からKubernetesや大規模なジョブ管理基盤を導入するのではなく、まずGoogle Compute Engine上に1台のAgent Runnerを構築します。
1. 今回構築するMVP
最初に作る構成は次の通りです。
Redmine
│
│ Issue
▼
Human Operator
│
▼
ChatGPT Skill
│
Brief Draft
│
▼
Human Review
│
Approve
│
▼
Git Writer MCP
│
▼
Agent Taskリポジトリ
Approved Brief
│
▼
Brief Ready
│
▼
Handler
│
▼
Ready for Agent
│
▼
Agent Controller
│
▼
GCE Agent Worker
│
┌───────────┴───────────┐
▼ ▼
Codex Claude Code
│ │
└───────────┬───────────┘
▼
Applicationリポジトリ
│
git push
│
▼
CircleCI
│
▼
Pull Request
この段階では、
- Agent ControllerとWorkerは同一VM
- Workerは1台
- 実行状態の正本はRedmine
- Agent BriefはGitで管理
- Workerの排他制御はControllerのローカルロック
- WorkspaceはDockerまたはディレクトリ分離
- CIはCircleCI
- AgentはCodexを優先
- Claude Codeは後からAdapterとして追加
とします。
ここでは、
queue/
↓
running/
↓
completed/
というGit上のファイル移動による状態管理は行いません。
Gitは、
Agentへ渡した指示内容を保存する場所
として使います。
実行状態はRedmineとControllerで管理します。
2. コンポーネント構成
GCE VM上には、次のコンポーネントを配置します。
ai-agent-runner-01
/opt/ai-agent/
├── controller/
├── adapters/
│ ├── codex/
│ └── claude/
├── scripts/
├── workspaces/
├── logs/
├── locks/
└── config/
それぞれの役割は次の通りです。
controller
Redmine上で
Ready for Agent
になったIssueを取得し、Agent Workerへ渡します。
状態遷移、CI監視、Retry制御もControllerが担当します。
adapters
CodexやClaude CodeのCLI差異を吸収します。
例えば、
run_agent(task)
という共通インターフェースを用意します。
workspaces
Issue単位の作業ディレクトリです。
workspaces/
├── 5320/
├── 5321/
└── 5322/
logs
AgentやControllerの実行ログを保存します。
locks
単一WorkerのMVPで二重起動を防止するためのロックを置きます。
例えば、
locks/5320.lock
です。
このロックはGitへコミットしません。
3. Agent Taskリポジトリを作る
まず、Agentへの指示書専用リポジトリを作ります。
例えば、
ai-agent-tasks
です。
構成は次のようにします。
ai-agent-tasks/
├── briefs/
│ └── approved/
├── templates/
└── README.md
Issue #5320の承認済みAgent Briefであれば、
briefs/approved/5320.md
とします。
重要なのは、ここに
queue/
running/
completed/
failed/
を作らないことです。
Agent Briefの保存場所とTaskの実行状態を二重表現しないようにします。
TaskファイルはMarkdownで管理します。
例えば、
---
issue: 5320
repository: mcp-redmine
repository_url: git@github.com:example/mcp-redmine.git
branch: agent/5320
agent: codex
brief_version: 1
requirements_fingerprint: sha256:0123456789abcdef...
source_updated_on: 2026-09-01T10:00:00Z
---
# Task
Context Budget Report / CI Integrationを実装する。
# Goal
CI上でコンテキスト使用量を計測し、確認可能にする。
# Requirements
- CI上で計測できること
- レポートを確認できること
- 既存CIを壊さないこと
# Acceptance Criteria
- 関連テストが成功する
- lintが成功する
- CircleCIが成功する
requirements_fingerprintは、Agent Briefがどの要求から生成・承認されたかを検証するために使います。
一方、
source_updated_on:
は監査や調査のための参考情報です。
Redmineのupdated_onは、Agent実装とは無関係な変更でも更新される可能性があるため、
approved updated_on
==
current updated_on
のような単純比較をAgent Briefの有効性判定には使いません。
実行状態についても、
status: ready
のような値は持たせません。
実行状態の正本はRedmineです。
4. ChatGPTからAgent Briefを作る
ChatGPTはAgent Controllerから自動的に呼び出すのではなく、人間が操作する要求変換ツールとして使います。
例えば、人間が、
Redmine #5320を取得してAgent Briefのドラフトを作成してください。
まだGitには保存しないでください。
と指示します。
処理は、
Human
↓
ChatGPT Skill
↓
Redmine MCP
↓
Issue取得
↓
Agent Brief Draft
となります。
人間は生成されたBriefを確認します。
必要であれば修正し、問題なければ、
このBriefを承認します。
Agent Taskリポジトリへ保存してください。
と指示します。
その時点で初めて、
ChatGPT
↓
Git Writer MCP
↓
briefs/approved/5320.md
へ保存します。
このように、
生成と承認を分離する
ことが重要です。
5. Git Writer MCPの権限を限定する
Git Writer MCPは汎用Gitクライアントにする必要はありません。
むしろ、
write_agent_brief(issue_id, content)
のような用途限定APIにします。
書き込み先も、
briefs/approved/<issue-id>.md
へ固定できます。
さらに、
- Applicationリポジトリには書き込めない
- 任意ファイルを削除できない
- mainブランチを変更できない
- Agent Brief専用リポジトリだけ操作できる
ようにします。
これにより、ChatGPTが誤ってアプリケーションコードを変更するリスクを減らせます。
6. Brief承認ゲートを設ける
Agent BriefをGitへ保存しただけでは、まだAgentを起動しません。
人間によるレビューが完了し、Handlerへ検証を要求する段階でRedmineを、
Brief Ready
へ変更します。
ここでのBrief Readyは、
人間によるBriefのレビューと承認が完了し、Handlerによる検証を要求した状態
と定義します。
つまり、
Human Review
↓
Human Approval
↓
Brief保存
↓
Brief Ready
↓
Handler検証
です。
Brief Readyは、Handlerによる検証が完了した状態ではありません。
非同期でHandlerが動く以上、人間による状態変更とHandlerの検証完了の間には時間差があります。
その時間差を状態モデルへ正しく反映します。
Handlerは、
- 承認済みBriefが存在するか
- BriefとRedmine Issueの対応が正しいか
- requirements fingerprintが一致しているか
- 承認メタデータを保存できるか
- 同じ承認イベントが二重処理されていないか
などを検証します。
成功した場合、MVPではHandler自身が、
Ready for Agent
へ自動遷移させます。
したがって、
Brief Ready
↓
Handler Validation
↓
Ready for Agent
となります。
ここでは、
Briefの承認 = Agent実行許可
として扱います。
承認済みのBriefを通常はそのまま実行するため、MVPでは別途人間がReady for Agentへ変更するゲートを設けません。
将来、
- 実行時間帯を制御したい
- 高コストTaskだけ別承認したい
- リリース凍結期間を設けたい
- Taskの優先順位を人間が調整したい
といった要件が出た場合には、
Brief Approved
↓
Execution Approval
↓
Ready for Agent
のように、Brief承認と実行許可を別ゲートへ分離できます。
最初からその複雑さを持ち込む必要はありません。
7. Briefの陳腐化を検出する
Agent Brief生成後にRedmineの要求が変更される可能性があります。
例えば、
10:00 Brief生成
10:10 RedmineのAcceptance Criteria変更
10:20 Agent開始
となった場合、Agentは古い要求を実装してしまいます。
そのため、Brief生成時または承認時の要求からfingerprintを作ります。
概念的には、
SHA256(
normalized_subject
+ normalized_description
+ normalized_acceptance_criteria
+ normalized_relevant_custom_fields
)
です。
承認時には、
Brief Requirements Fingerprint
Brief Approved At
Brief Approved By
Brief Git SHA
などをRedmineのカスタムフィールドへ保存します。
Agent起動前に現在のRedmine情報からfingerprintを再計算し、
approved fingerprint
!=
current fingerprint
であればAgentを起動しません。
その場合は、
Brief Draft
へ戻し、再生成または再承認を要求します。
ここでもupdated_onの単純比較は使いません。
コメント追加や担当者変更など、Agentへ渡す要求そのものと関係しない変更でもupdated_onが変わる可能性があるためです。
MVPの最初の段階ではfingerprint検証を自動化しなくても構いません。
ただし、
Agent起動前に人間がRedmineとBriefの差分を確認する
という運用上のゲートは残します。
fingerprintによる検証は後のPhaseで自動化します。
8. GCE VMを用意する
最初のWorkerは通常のCompute Engine VMで十分です。
例えば、
Machine type:
e2-standard-4
（4 vCPU / 16GB）
OS:
Ubuntu LTS
Disk:
50〜100GB
程度から始められます。
AI Agentは、
- Git
- Node.js
- Python
- Docker
- build tools
などを同時に利用する可能性があります。
そのため、最初から極端に小さなVMへ詰め込むより、ある程度余裕を持たせた方が運用しやすくなります。
9. VMに必要なソフトウェア
例えば、
sudo apt update
sudo apt install -y \
git \
curl \
jq \
build-essential \
docker.io
をインストールします。
Node.jsやPythonについては対象リポジトリに合わせます。
Agent自身の環境とアプリケーション依存環境を可能な限り分離するため、アプリケーションのビルドやテストをDocker内で実行する構成も有効です。
10. Codex CLIを導入する
Agent Workerでは対話UIではなく、スクリプトから実行できるCLIを利用します。
概念的には、
codex exec \
"Read TASK.md and AGENTS.md. Implement the task and run relevant tests."
のように実行します。
Promptそのものは極力短くします。
例えば、
Read TASK.md.
Follow AGENTS.md.
Implement the requested change.
Run relevant tests before finishing.
程度です。
実際の要求はTASK.md側から読み取らせます。
これもPull Contextの考え方です。
11. Codex Adapterを作る
ControllerからCodex固有のCLIを直接扱うのではなく、Adapterを挟みます。
例えば、
adapters/
└── codex/
└── run.sh
とします。
概念的には、
#!/bin/bash
set -e
WORKSPACE="$1"
cd "$WORKSPACE/repo"
codex exec \
"Read ../TASK.md and AGENTS.md. Implement the task, run relevant tests, and report the result."
です。
将来Claude Codeを追加する場合も、
adapters/
├── codex/run.sh
└── claude/run.sh
とできます。
Controllerからは、
run_agent("codex", workspace)
のような共通インターフェースだけを呼びます。
12. Taskの状態はRedmineで管理する
この設計ではGit上のファイル移動によってTask状態を管理しません。
状態の正本はRedmineです。
例えば、
Brief Draft
↓
Brief Ready
↓
Ready for Agent
↓
Agent Running
↓
Review
という状態を持ちます。
異常時には、
Needs Human
へ遷移します。
Gitには、
briefs/approved/5320.md
がそのまま残ります。
Agentが実行中だから、
running/5320.md
へ移動することはありません。
これにより、
Redmine status
Git directory
frontmatter status
という三重管理を避けられます。
13. 単一Workerではロックファイルを使う
Redmineを状態の正本にしても、Controllerの二重起動などによって同じTaskが同時処理される可能性はあります。
ただし今回のMVPはControllerもWorkerも1台です。
そのため最初は、
/opt/ai-agent/locks/5320.lock
のような単純な排他制御で十分です。
例えば、
Ready for Agent取得
↓
lock取得
↓
RedmineをAgent Runningへ変更
↓
Agent実行
↓
lock解放
とします。
Workerを複数台へ増やす段階では、このローカルロックを分散LeaseやController DBへ置き換えます。
14. Workspaceを作成する
Task #5320を処理する場合、
/opt/ai-agent/workspaces/5320/
を作ります。
その中で対象リポジトリをcloneします。
例えば、
git clone git@github.com:example/mcp-redmine.git \
/opt/ai-agent/workspaces/5320/repo
その後、
cd /opt/ai-agent/workspaces/5320/repo
git checkout -b agent/5320
とします。
Agent Briefは、
TASK.md
としてWorkspaceへコピーします。
構成は、
workspaces/5320/
├── TASK.md
└── repo/
となります。
AgentにはGit上のBriefを直接編集させず、実行時にWorkspaceへコピーしたものを参照させます。
Task終了後は、成功・失敗に関係なくWorkspaceを破棄します。
Workspaceは永続的な状態保存先ではありません。
15. AgentにGit認証を直接持たせすぎない
Agent WorkerにはGitへの書き込み権限が必要ですが、可能な限り権限を限定します。
例えばGitHub Appを使う場合、
- 対象リポジトリ限定
- Contents write
- Pull Requests write
- Administrationなし
とします。
長期間有効なPersonal Access TokenをVMへ直接配置するより、短命CredentialやGitHub Appを使う方が管理しやすくなります。
CredentialはGoogle Secret Managerなどへ保存します。
Agent Brief内にCredentialを書いてはいけません。
16. Controllerの基本処理
Agent Controllerは単純な処理から始められます。
MVPではWorkerが1台なので、1Taskずつ直列に処理する設計とします。
概念的には次のようになります。
while true:
issue = find_redmine_issue(
status = "Ready for Agent"
)
if issue does not exist:
sleep()
continue
if not acquire_lock(issue):
continue
workspace = null
try:
brief = load_approved_brief(issue)
if brief does not exist:
update_redmine(issue, "Brief Draft")
add_redmine_comment(
issue,
"Approved Brief was not found."
)
continue
if approval_validation_enabled:
validation = validate_approval_metadata(
issue,
brief
)
if validation failed:
update_redmine(issue, "Brief Draft")
add_redmine_comment(
issue,
validation.reason
)
continue
fingerprint = validate_fingerprint(
issue,
brief
)
if fingerprint mismatched:
update_redmine(issue, "Brief Draft")
add_redmine_comment(
issue,
"Requirements changed after Brief approval."
)
continue
update_redmine(
issue,
"Agent Running"
)
workspace = create_workspace(issue)
clone_repository(
issue.repository,
workspace
)
copy_brief_to_workspace(
brief,
workspace
)
run_agent(
issue.agent,
workspace
)
run_local_validation(
workspace
)
commit_changes(
workspace
)
push_branch(
workspace
)
retry = 0
while true:
ci_result = wait_for_ci()
if ci_result == success:
create_pull_request(issue)
update_redmine(
issue,
"Review"
)
break
retry += 1
if retry > max_ci_retries:
update_redmine(
issue,
"Needs Human"
)
add_redmine_comment(
issue,
"CI retry limit exceeded."
)
break
collect_ci_failure(
issue,
workspace
)
run_agent_retry(
issue.agent,
workspace
)
run_local_validation(
workspace
)
commit_changes(
workspace
)
push_branch(
workspace
)
except unexpected_error:
update_redmine(
issue,
"Needs Human"
)
record_error(
issue,
unexpected_error
)
finally:
if workspace exists:
cleanup_workspace(
workspace
)
release_lock(
issue
)
ここで重要なのは、承認情報やfingerprintの検証に失敗した場合、
Agent Running
へ進めないことです。
例えばRedmineの要求がBrief承認後に変更されていれば、
Ready for Agent
↓
検証失敗
↓
Brief Draft
へ戻します。
人間が内容を確認し、必要に応じてBriefを再生成・再承認します。
また、wait_for_ci()はブロックします。
これは意図的です。
今回のMVPでは、
Worker = 1
同時実行Task = 1
としているためです。
Taskが成功しても失敗しても、
cleanup_workspace()
と
release_lock()
は必ず実行します。
並列処理が必要になった段階でControllerとWorkerを分離します。
17. ローカル検証を実行する
Agentは変更後、まずWorkspace内部で高速な検証を行います。
例えば、
formatter
lint
typecheck
targeted unit test
です。
全テストを毎回Agent側で実行する必要はありません。
Agent側では、
失敗を早く検出できるチェック
を優先します。
包括的な検証はCircleCIへ任せます。
18. GitへPushする
ローカル検証が成功したら、
git add .
git commit -m "feat: implement Redmine #5320"
git push origin agent/5320
します。
ここでCircleCIが通常通り起動します。
Agent ControllerがCircleCIを特別な方法で起動する必要はありません。
git push
↓
通常のCI
という既存の開発フローをそのまま利用します。
19. CircleCIを独立Validatorとして使う
CircleCIは、
AI Agent
↓
Git
↓
CircleCI
の外部Validatorとして扱います。
Agent自身の、
テストは通りました
という自己申告だけで成功判定をしてはいけません。
Controllerは、
agent/5320
↓
CircleCI Pipeline
↓
Workflow
↓
Job
↓
status
を確認します。
CIが成功して初めて、実装成功と判定します。
20. CIが失敗したら必要な情報だけAgentへ渡す
CircleCIが失敗した場合、ログ全体をCodexへ渡す必要はありません。
Controller側で、
Pipeline
↓
Failed Workflow
↓
Failed Job
↓
Failed Step
↓
必要部分のログ
まで絞ります。
その内容を、
CI_FAILURE.md
としてWorkspaceへ保存します。
例えば、
workspaces/5320/
├── TASK.md
├── CI_FAILURE.md
└── repo/
とします。
そしてCodexへ、
Read CI_FAILURE.md.
Fix the failure without changing unrelated behavior.
Run relevant tests before finishing.
と指示します。
大量のCIログをPromptへ直接貼り付けないのがポイントです。
21. CI Retryには上限を設ける
AI Agentに無限修正を許可してはいけません。
例えば、
max_ci_retries: 3
とします。
流れは、
git push
↓
CircleCI失敗
↓
CI_FAILURE.md生成
↓
Agent修正
↓
ローカル検証
↓
再push
↓
CircleCI再実行
です。
これを上限まで繰り返します。
3回失敗した場合、
Needs Human
へ遷移します。
この状態もRedmineで管理するため、
needs-human/
のようなGitディレクトリを追加する必要はありません。
自律Agentでは、
自動化することより、どこで自動化を止めるかを決めること
の方が重要です。
22. CI APIの権限はRead中心にする
Agent Controllerには、
CI Status Read
CI Workflow Read
CI Job Read
CI Logs Read
を中心に与えます。
最初は、
rerun
cancel
config change
などの操作権限をAgentへ与えない方が安全です。
CIの実行そのものはGit pushで発生します。
Controllerは基本的に、
結果を読む側
に限定します。
23. PRを作成する
CircleCIが成功したらPull Requestを作成します。
例えば、
agent/5320
↓
main
です。
PR本文には、
Redmine: #5320
Agent: Codex
Agent Brief:
briefs/approved/5320.md
Requirements fingerprint:
sha256:0123456789abcdef...
Local validation:
- lint: passed
- unit test: passed
CircleCI:
- passed
CI retries:
1
Files changed:
- ...
などを記録します。
これによりReviewerは、
- どの要求から作られたか
- どのBriefをAgentへ渡したか
- どのAgentが実装したか
- どの要求fingerprintを基準にしたか
- ローカル検証結果
- CI結果
- Retry回数
を確認できます。
24. Redmineへ結果を戻す
PR作成後、Redmineを、
Review
へ変更します。
コメントには、
Agent implementation completed.
Branch:
agent/5320
Pull Request:
#123
CI:
Passed
CI retries:
1
Agent:
Codex
などを記録します。
Redmineが、
要求と実行状態の正本
になります。
詳細な実行ログまでRedmineへ保存する必要はありません。
25. ChatGPTを実行ループに入れすぎない
この構成で特に重要な点です。
ChatGPTは、
Human
↓
Redmine
↓
Agent Brief生成
↓
Human Approval
↓
Git
までを担当します。
その後の、
Brief Ready
↓
Handler
↓
Ready for Agent
↓
Agent Runner
↓
Git
↓
CI
↓
PR
は自動実行基盤側で完結させます。
例えばCI失敗時に、
Controller
↓
ChatGPT Skill
↓
次に何をするか判断
とはしません。
ChatGPT SkillはControllerから自動的に呼び出す実行APIとして設計しないためです。
役割は、
ChatGPT
= 要求変換
Human
= Briefレビューと承認
Handler
= 承認検証とReady for Agentへの遷移
Agent Controller
= 実行状態遷移
Codex / Claude Code
= 実装
CircleCI
= 独立検証
と分離します。
26. Agent Controller APIを用意する
後からSlackやWeb UIを追加できるように、Controllerには小さなAPIを持たせます。
例えば、
GET /tasks/5320
POST /tasks/5320/cancel
POST /tasks/5320/retry
です。
管理用途として、
POST /tasks/5320/start
を用意しても構いません。
ただし通常運用では、
Ready for Agent
をControllerが取得して自動実行するため、手動startを必須にはしません。
ステータス取得例は、
{
"issue": 5320,
"status": "ci_running",
"agent": "codex",
"branch": "agent/5320",
"ci_retry": 1
}
です。
Slackなどの外部UIは、このAPIを呼ぶだけにします。
Agent実行ロジックをSlack側へ持たせません。
27. ログを残す
最低限、次のログを保存します。
logs/
└── 5320/
├── controller.log
├── agent.log
├── local-test.log
└── ci.log
Redmineには、
成功
失敗
PR
CI結果
Retry回数
などの要約だけを保存します。
詳細ログはCloud Loggingなどへ送ります。
これによりRedmineのIssueが巨大なAgentログで埋まるのを防げます。
WorkspaceはTask終了後に削除しますが、必要な実行ログはWorkspace外へ保存しておきます。
28. Secret ManagerとSandboxを使う
GCE上には、
- GitHub Credential
- CircleCI Token
- OpenAI Credential
- Redmine Credential
などが必要になります。
これらを、
.env
へ長期間保存するのではなく、Secret Managerから取得する構成にします。
また、AgentへVM全体へのアクセス権限を与えないことも重要です。
Agentが操作できる場所を、
/opt/ai-agent/workspaces/5320/
へ限定します。
例えば、
/etc
/home
/opt/ai-agent/controller
/opt/ai-agent/config
などをAgentから自由に変更できないようにします。
もう一段分離する場合は、1Taskを1Containerで実行します。
GCE
Agent Controller
│
├─ Docker agent-5320
├─ Docker agent-5321
└─ Docker agent-5322
Containerには、
TASK.md
Applicationリポジトリ
Agent CLI
必要なBuild Tools
だけを渡します。
Task終了後はContainerごと削除します。
29. 複数Workerへ拡張する
最初はVM1台・Worker 1台ですが、Task数が増えたらWorkerを増やします。
Agent Controller
│
┌─────────┼─────────┐
▼ ▼ ▼
Worker-01 Worker-02 Worker-03
Google Compute EngineのManaged Instance Groupなどを利用すれば、同じ構成のVM群をまとめて管理できます。
ただし、Workerを複数台へ増やした時点で、
ローカルlockファイル
では排他制御できません。
その段階では、
Controller DB
Cloud Tasks
Pub/Sub
Redis
Database
などを使って、
Task取得
Lease
Retry
Timeout
Worker Assignment
を中央管理します。
ここでもGitを実行Queueとして使わないことが重要です。
Gitは引き続き、
承認済みAgent Briefの保存と監査
を担当します。
30. MVP構築の順番
最初から全部実装する必要はありません。
段階的に作ります。
Phase 1
Approved Brief
↓
Ready for Agent
↓
GCE
↓
Codex
↓
Application Git
まずは、
briefs/approved/5320.md
を人間が手動で作成し、
Ready for Agent
にすると、Codexが実装してpushできるところまで作ります。
この段階ではHandlerによる承認検証をまだ自動化せず、人間がBriefを確認したうえでReady for Agentへ変更しても構いません。
Phase 2
CircleCI連携を追加します。
git push
↓
CircleCI
↓
Controllerが結果確認
↓
失敗時Agent Retry
まで作ります。
Phase 3
ChatGPTとGit Writer MCPを追加します。
Redmine
↓
人間がChatGPT Skillを起動
↓
Agent Brief Draft
↓
Human Review
↓
Git Writer MCP
↓
Approved Brief
とします。
ここでもChatGPT Skillを自動起動しません。
Phase 4
Brief承認処理とRedmine状態遷移を自動化します。
Human Review
↓
Human Approval
↓
Brief Ready
↓
Handler
↓
承認メタデータ保存
↓
fingerprint検証
↓
Ready for Agent
を実装します。
このPhase以降は、Handlerが検証成功後に自動的にReady for Agentへ遷移させます。
またAgent起動前にもfingerprintを確認し、Brief承認後にRedmineの要求が変化していれば自動実行を止めます。
Phase 5
Workerを複数台へ増やします。
この段階で、
ローカルlock
から、
Controller DB
Cloud Tasks
Pub/Sub
などの中央Queue / Lease方式へ移行します。
この順番なら、最初から大規模基盤を作らず、
1 Worker
↓
CI連携
↓
Brief生成
↓
承認自動化
↓
複数Worker
と段階的に育てられます。
31. 完成後の流れ
最終形では、人間がまずRedmineのIssueを作成・更新します。
例えば、
Redmine #5320
です。
その後、
Human
↓
ChatGPT Skillを起動
↓
Redmine #5320取得
↓
Agent Brief Draft生成
↓
Human Review
↓
必要なら修正
↓
Human Approval
↓
Git Writer MCP
↓
briefs/approved/5320.md
↓
Redmine = Brief Ready
↓
Handler
↓
Brief / Redmine整合性検証
↓
requirements fingerprint検証
↓
承認メタデータ保存
↓
Ready for Agent
↓
Agent Controller
↓
GCE Worker
↓
git clone
↓
Codex
↓
Local Test
↓
git push
↓
CircleCI
となります。
CircleCIが失敗した場合は、
CircleCI失敗
↓
Controllerが失敗Job取得
↓
必要なログだけ抽出
↓
CI_FAILURE.md
↓
Codex修正
↓
Local Test
↓
git push
↓
CircleCI再実行
となります。
成功すれば、
CircleCI成功
↓
Pull Request
↓
Redmine Review
↓
Human Review
です。
Taskが成功しても失敗しても、最後に、
Workspace削除
↓
lock解放
を実行します。
全体を一枚で表すと、
Human
│
▼
Redmine
│
▼
ChatGPT Skill
（人間が起動する）
│
▼
Brief Draft
│
▼
Human Review
│
Approve
│
▼
Git Writer MCP
│
▼
Approved Brief
│
▼
Brief Ready
│
▼
Handler
│
┌─────────┴─────────┐
│ │
Validation NG Validation OK
│ │
▼ ▼
Brief Draft Ready for Agent
│ │
▼ ▼
Human Agent Controller
│
▼
GCE Worker
│
Codex / Claude
│
▼
Application Git
│
git push
│
▼
CircleCI
│
┌─────────────┴─────────────┐
│ │
Failed Passed
│ │
▼ ▼
CI Failure Context Pull Request
│ │
▼ ▼
Agent Retry Redmine Review
│
▼
Human Review
この構成で守る設計原則
この実装で最も重要なのは、各コンポーネントへ責任を持たせすぎないことです。
役割は次のように分けます。
Redmine
= 要求と業務状態の正本
ChatGPT Skill
= 要求をAgent Briefへ変換
人間が起動する
Human
= Briefレビューと承認
最終レビュー
Git Writer MCP
= 承認済みBriefを安全に保存
Agent Taskリポジトリ
= Briefの履歴・監査ログ
Handler
= Brief承認情報と陳腐化の検証
Ready for Agentへの遷移
Agent Controller
= Agent実行
状態遷移
Retry
CI監視
Worker制御
Codex / Claude Code
= コード実装
Application Git
= 開発履歴
CircleCI
= 独立した検証
Pull Request
= 人間とのレビュー境界
この境界を守ることで、例えばCodexをClaude Codeへ変更しても、要求管理やCI構成まで作り直す必要がありません。
同様に、将来WorkerをGCEからKubernetesへ移しても、RedmineやAgent Briefの仕組みはそのまま利用できます。
まとめ
最初のAIコーディング基盤は、意外と小さく作れます。
MVPで必要なのは、
GCE 1台
Gitリポジトリ 2つ
Agent Controller
Codex CLI
CircleCI API
Redmine
程度です。
大規模なAIプラットフォームから始める必要はありません。
まず確立するのは、
Approved Brief
↓
Ready for Agent
↓
Agent
↓
Git
↓
CI
という最小ループです。
その後、
Redmine
↓
ChatGPT Skill
↓
Human Approval
を前段へ追加します。
さらに、
Brief Ready
↓
Handler
↓
承認メタデータ
↓
requirements fingerprint
↓
Ready for Agent
を追加すれば、古くなったBriefがそのまま実行されることを防げます。
MVPでは、
人間によるBrief承認をAgent実行許可とみなし、Handlerの検証成功後に自動的にReady for Agentへ進める
設計とします。
将来、優先度制御や実行タイミング管理が必要になれば、
Brief Approval
↓
Execution Approval
↓
Ready for Agent
とゲートを分離できます。
開発者やTaskが増えたら、
1 Worker
↓
Multiple Workers
↓
Central Queue / Lease
↓
Managed Instance Group
へ拡張します。
ここで重要なのは、GitをWorker間のQueueや状態データベースとして使わないことです。
Gitには、
何をAgentへ依頼したのか
を残します。
Redmineには、
現在どの状態なのか
を残します。
Handlerには、
そのBriefを実行してよい状態か
を検証させます。
Controllerには、
承認済みTaskをどう実行するか
を管理させます。
この責務分離によって、
Redmine
↓
Human
↓
Approved Agent Brief
↓
AI Development Platform
↓
Pull Request
という開発フローを安定して構築できます。
この設計の本質は、AIを特別なチャットツールとして扱わないことです。
CI Runnerがコードを検証するように、
Agent Runnerが承認済みの開発作業を実行する
という共通基盤として扱います。
そして人間は、Promptを何度もコピーしてAIへ指示するのではなく、
要求を書くこと
Agentへ渡す要求を承認すること
成果物をレビューすること
に集中します。
実装順としては、まずPhase 1の
Approved Brief
↓
Ready for Agent
↓
GCE
↓
Codex
↓
Git Push
だけを実際に作るのが最短です。
ここが動けば、CircleCI、ChatGPT Skill、Git Writer MCP、Brief承認Handler、陳腐化検知、複数Worker化はすべて後から段階的に追加できます。