I Built an Agentic Software Factory with Codex and Claude Code
概要
AIエージェントを使った「ソフトウェア工場(Software Factory)」の構築ガイド。従来の開発プロセス(意図→チケット精査→設計→実装→テスト→レビュー→マージ)の各段階にエージェントを配置し、GitHubのIssueとラベルをトリガーにパイプラインを自動実行する仕組みを、自作のオープンソースツール(Rust製「factory」)のデモを通して解説する。要点は「どのエージェントを使うかより、ワークフローの定義こそが本質」という主張。
主なポイント
- ソフトウェア工場はCI/CDの発想の延長。デプロイを自動化したのと同じように、実装〜レビューまでのループ自体をシステム化する。
- パイプラインは2段構成。①トリアージ(曖昧なIssueを受け入れ基準付きの実装可能なチケットに書き換える) ②実装(コード変更→テスト→レビュー→PR作成)。
- エージェントに毎回自由に指示するのではなく、手順を事前に「ワークフロー/スキル」として明文化しておくことで、開発プロセスの一貫性が劇的に上がる。
- 実際の運用は「タスクをPRに変換するスキル」1つで開発作業の99%をカバー。人間は計画と設計に時間を使い、実装は委譲する。
- トリガーはGitHubのラベル運用。
factory-ready-for-specを付けるとトリアージが走り、factory-ready-for-implementationを付けると実装エージェントが起動する。人間の作業はカンバンでカードを動かすだけ。 - 分離戦略はgit worktreeベース(ローカル)、本番/VM運用ではDockerサンドボックス。エージェントを走らせるたびに新しいworktreeを生成して隔離する。
- スケジュールジョブが強力。例として「bug finder」ワークフローを定期実行し、発見したバグを自動でチケット化する。手動トリガーもできる。
- コスト面の反論への回答: ポーリング部分はほぼ決定論的なコードなので、実際に作業があるときだけトークンを消費する。24時間稼働させても無駄が出ない。
- 1タスクの実行時間は20分〜1時間(広範なコードレビューやCIチェックを含むため)。ターミナルに張り付いて何百のタスクを見るのは非現実的なので、VM等にオフロードして後で差分を確認する運用になる。
- 万能ではない。機械的な作業・セキュリティアップグレード・バグ修正・面倒な雑務が適任で、批判的思考が必要なタスクは人間が関与すべき。チームに導入する際はパイプラインを乱用しない文化が前提。
- 専用ツールがなくてもGitHub Actionsで代替可能(Issue作成時やラベル付与時にエージェントを起動)。自動化定義をバージョン管理下に置けるのが利点。
実践に使えること
- まず自分の開発手順を1枚のワークフロー定義に書き出す(タスクを読む→簡易計画→実装→テスト→セルフレビュー→PR作成→フィードバック対応→人間へ引き渡し)。これをスキル/カスタムコマンドとして固定し、毎回同じ手順で走らせる。
- チケットのテンプレートを決める(成果・背景・受け入れ基準・補足情報)。曖昧なIssueをこのテンプレートに書き換える「トリアージ用プロンプト」を別途用意し、実装前に必ず通す。
- GitHubラベルをステートマシンとして使う。
ready-for-spec/ready-for-implementationの2ラベルだけで、人間の承認ポイントを挟んだ半自動パイプラインが作れる。 - GitHub Actionsで「Issueに特定ラベルが付いたらエージェント起動」を組む。専用インフラなしで今日から試せる最短ルート。
- 定期実行の「バグ探しジョブ」を1本仕込む。深夜に走らせてIssueを作らせるだけでも効果があり、信頼できたらPR作成まで権限を広げる。
- 並行実行するならgit worktreeで作業ディレクトリを必ず分離する。VMやチーム運用に移すならDockerサンドボックス等の隔離を先に用意する。
- 自動化の設定ファイル(スケジュール・ワークフロー定義)はリポジトリに入れてバージョン管理する。クラウド側のGUI設定に置くとチームで再現できない。
- 信頼は段階的に広げる。最初はレビュー必須、慣れたら実行時間を延ばし、PR自動作成、個人プロジェクトなら自動マージまで、と権限を少しずつ渡す。