factoryとは？GitHub IssuesでAIコーディングエージェントを自動起動するRustフレームワーク

AIコーディングエージェントを使い始めると、すぐに気づく課題があります。「エージェントは賢いが、いつ・どのタスクに使うかを人間が毎回判断して指示しなければならない」という問題です。 factoryはこの問題をCI/CDと同じ考え方で解決します——GitHub Issuesのラベル変更をトリガーに、AIコーディングエージェントが自動で実装・PR作成まで担うフレームワークです。

factoryとは何か？AIコーディングエージェントのためのCI/CD

factoryは「Build your own software factory with AI agents」を掲げるRust製CLIフレームワークです。 GitHub Issuesを信頼されたチケットキューとして扱い、ステータス・ラベル・スケジュールなどのトリガー条件が満たされると、 Markdownワークフロー定義に従ってAIエージェントが自動的に起動します。

重要な設計思想は**「人間がマージゲートになる」**点です。 factoryはPRを作成しますが、マージは自動化しません。「何を作るか・どうレビューするか」は人間が決定し、「作業の実行」をエージェントが担う分業です。

4つのコアコンセプト：Source・Trigger・Workflow・Worker

Source（チケットソース）

GitHub Issuesが現在サポートされる信頼済みチケットキューです。設定された条件を満たすチケットがあれば、factoryが検知して処理します。

Trigger（トリガー条件）

ラベル・ステータス変更・スケジュール（定時実行）をトリガーにできます。 YAMLライクな設定ファイルでlabel: "agent-ready"のように指定します。 誰がチケットを開いたかではなく、誰がトリガー条件を満たせるかが信頼の境界です。

Workflow（Markdownワークフロー定義）

固定のDSLやグラフ定義ではなく、普通のMarkdownファイルにワークフロー内容を記述します。「このIssueに記載された機能を実装し、テストを書いてPRを作成せよ」というゴールをMarkdownで定義すると、エージェントはこれをプロンプトとして受け取り、gh・gitなどのツールを使って作業を進めます。

Worker（エージェントランタイム）

Codex CLIをワーカーとして使用し、管理されたworktreeまたはDockerクローン内で分離実行されます。同時並行数・タイムアウト・サンドボックスはfactoryが管理します。

インストールと基本的な使い方

前提条件とインストール

# 前提ツールのインストール・認証
gh auth login     # GitHub CLI
codex login       # Codex CLI
cargo install --path . --locked   # factory本体

リポジトリへの初期設定

# 管理対象リポジトリのルートで実行
factory init

# 設定ファイルを編集後
factory validate    # 設定の検証
factory run --once  # 一度だけ実行（テスト）
factory run         # 常駐実行開始

factory initが生成する設定ファイルを編集して、どのラベルをトリガーにするか・どのMarkdownワークフローを使うかを定義します。詳細な設定手順は公式セットアップガイドに記載されています。

GitHub ActionsやClaude Codeとの違い・なぜ今factoryなのか

比較点	GitHub Actions	Claude Code	factory
実行主体	CIスクリプト（決定論的）	人間が都度起動	AIエージェント（自動起動）
定義形式	YAMLステップ	なし（インタラクティブ）	Markdownプロンプト
用途	テスト・ビルド・デプロイ	任意の実装	Issue起点の実装・PR作成
自動化度	高（CIのみ）	低（人間起動）	高（Issue監視→実行）

GitHub Actionsが**「何をどう実行するか」を事前に定義するのに対し、 factoryは「何を達成するか」のゴールをMarkdownで定義し、AIエージェントが方法を判断**します。 Claude CodeやCursor等と異なる点は、人間がトリガーをかけなくてもチケットキューを監視して自動起動する点です。

こんな人に向いている

バックエンドエンジニア（AIエージェント活用を自動化したい方）

GitHub Issuesで管理しているタスクをagent-readyラベルを付けるだけで AIエージェントが実装してPRを出してくれる環境を構築したい場合に最適です。エージェントへの毎回の指示・起動・監視から解放され、レビューに集中できます。

DevOpsエンジニア（開発プロセス自動化担当）

トリアージワークフローを定義して、Issueの受け入れ基準が不明確な場合にエージェントが自動でIssueを調査・補完・質問するフローを構築できます。「実装可能な状態のIssue」を自動的に整備する仕組みが作れます。

テックリード（エンジニアチームのアウトプット向上を目指す方）

factoryを導入することで、エンジニアは設計・レビュー・意思決定に集中し、定型的な実装タスクはAIエージェントが担う分業体制を段階的に構築できます。

使う前に知っておきたいこと

現時点のV1スコープの制限

GitHub Issuesのみ対応（Jira・LinearはV1外だが拡張ポイントは存在する）
1リポジトリのみ（マルチリポジトリはV1外）
Codex CLIのみサポート（他のエージェントランタイムはV1外）

セキュリティと信頼境界

トリガー条件を満たせるのは管理者権限を持つユーザーのみにすることを推奨
チケット本文・コメントは信頼されない入力として扱われる（プロンプトインジェクション対策）
エージェントはprotected branchesへの直接pushができないよう設定を推奨
詳細はリポジトリのSECURITY.mdを参照

ライセンス

MIT License — 商用利用・改変・再配布が自由。

まとめ：AIエージェント時代のソフトウェアファクトリー

factoryはまだ初期段階ですが、「AIコーディングエージェントをCI/CDと同じように組み込む」というアイデアは AIエンジニアリングの次のステップとして注目されています。 GitHub IssuesベースのチームがAIエージェント活用を体系化・自動化するための最初のオープンソースフレームワークとして、今後の発展に期待が集まります。

詳しくは公式GitHubリポジトリ（owainlewis/factory）や設計ドキュメントをご確認ください。

この技術を学ぶ

DevToolに興味を持った方には、Udemyのオンラインコースもおすすめです。

🎓 関連するDevToolコース一覧 — セール時（最大90%OFF）を狙うとお得です