自動化の仕組みそのものを作ってくれますか

このスキルが扱うのは設計の用語と考え方で、構築の手順やスクリプトは含まれていません。助けてくれるのは、どのサービスを使い、どのタスクを何がきっかけで動かすかを決めるところまでです。

GitHubだけで構成できますか

できます。構成例の1つが、チケット管理をGitHub Issues、オーケストレーターをGitHub Actions、ランナーをActionsのランナーにする形です。この構成ではActionsの実行画面で足りるため、可観測性基盤は置いていません。

何から自動化すればよいか分かりません

解きたい問題をそのまま伝えてください。未分類のチケット、自動レビュー待ちのPR、誰も読まないバグ報告などがあれば、エージェントがEXAMPLE-TASKS.mdから対応するタスクの例を示します。

自動化で品質が落ちないか心配です

自動チェック、自動レビュー、人のレビューの3つのブレーキを組み込む前提です。トリガーは1つずつ絞って足し、すべてのPRを人が確認するところから始めます。ブレーキが信頼できると分かってから、少しずつ絞りを緩めていきます。

software-factory開発

開発自動化の基盤を設計する software-factory スキルの使い方

cccskills 編集部2026年11月9日公開読了約 11 分

この記事の結論

こんな人に: チケットやPRを起点に開発作業をエージェントで自動化したいが、設計の進め方に迷っている開発リーダーや個人開発者
入れると: 「ジョブ」「ワークフロー」など人ごとに違う呼び方が、タスクやランといった共通の用語にそろう
チケット管理やGitホストなどの枠に製品を当てはめ、構成案を表で比べられる
タスクごとに5つの問いへ答えるので、人の確認箇所と重複実行の防ぎ方が設計に残る
向かない人: 設計の整理ではなく、すぐに動く自動化の仕組みやスクリプトそのものが欲しい人

software-factoryは、チケットからマージまでをエージェントに任せる仕組みを、共通の用語で設計するためのスキルです。入れておくと、開発リーダーや個人開発者が、決まった用語と問いに沿って設計を詰められるようになります。この記事では、そろえられる用語とサービス構成、インストール方法、依頼文の例、使う前に知っておきたい注意点を順に紹介します。

使うとこうなる

software-factoryを使うと、開発自動化の設計を決まった用語と決まった問いで詰められます。ここでいう「ソフトウェアファクトリー」は、チケットやPR、定期実行をきっかけにエージェントが動き、マージされたコードに仕上げる仕組みのことです。たとえば次のように頼みます。

software-factoryを使って、未分類のチケットを振り分けるソフトウェアファクトリーを設計してください。チケットはGitHub Issuesで管理しています。

エージェントは仕組みの全体像より先に、解きたい問題から話を始めます。未分類のチケットのようなよくある課題なら、付属のEXAMPLE-TASKS.mdにある対応するタスクの例が参照先です。

設計は「サービス」と「タスク」の2つに分かれます。サービス側では、チケット管理やGitホストなどの枠（スロット）ごとに製品を決めます。タスク側で答えるのは、起動条件や人の確認箇所など5つの問いです。すべての枠に製品が入り、すべての問いに答えが出たら設計は完成です。

会話の途中で「ジョブ」や「ワークフロー」と言うと、エージェントは正式な用語の「タスク」を示します。そのため、チーム内で言葉がぶれないまま議論を進められます。

software-factoryでできること

用語をそろえる

このスキルの中心は、設計で使う9つの用語です。エージェントはこの用語だけを使い、避けるべき言い方が出てきたら言い換えます。

用語	意味
Task（タスク）	一度定義して何度も実行する作業の種類。レビュー、調査、実装など
Trigger（トリガー）	ランを始めるきっかけ。チケット管理やGitホストの変更、時刻、別のラン
Run（ラン）	1つのタスクを1台のランナーで実行する1回分
Runner（ランナー）	ランが動く使い捨ての環境。終わると何も残らない
Ticket tracker（チケット管理）	チケットの置き場所で、人とエージェントの窓口
Ticket source（チケットの発生源）	フィードバックボタン、監視、エラートラッカー、受信箱など
Git host（Gitホスト）	ブランチ、PR、レビューの置き場所
Orchestrator（オーケストレーター）	トリガーを受けてランを起動し、待機中・実行中・完了を記録する
Observability platform（可観測性基盤）	ランのログや状態を人が確かめる場所。なくてもよい

設計の前提になる考え方も決まっています。1つは、ランが人の返答を待たずにいったん終わることです。人がチケットやPRを変更したときに、新しいランが始まります。

もう1つは、ランナーに前回の記憶が残らないことです。そのため過去の経緯は、チケット管理、Gitホスト、オーケストレーターにだけ残ります。

自動化を少しずつ広げる

トリガーを増やすほど自動化は加速しますが、歯止めがないと質の低い変更が量産されます。そこで組み込むのが、次の3つのブレーキです。

ブレーキ	内容
自動チェック	型、リント、テストなど、すべてのランが通る決まった関門
自動レビュー	別のランが差分を先入観なく読み、規約やチケットと照らし合わせる
人のレビュー	マージ前に人がPRを読む。見つけた問題は自動チェックや自動レビューに反映する

自動のトリガーは1つずつ足し、最初は絞って動かします。バグ報告10件に1件だけ処理する、定期実行は1日1回にする、といった具合です。

あわせて、最初はすべてのPRを人が確認します。ランの繰り返しにも、数回で人に戻す上限を設けておきます。

サービスの構成を比べる

各サービスは、製品を当てはめる枠として扱います。1つの製品で複数の枠を埋めてもかまいません。スキルに載っている構成例は次の3つです。

サービス	すべてGitHub	チケットはLinear	自前のトラッカー
チケット管理	GitHub Issues	Linear	自前のアプリ
チケットの発生源	フィードバックボタン	フィードバックボタン、監視	フィードバックボタン、監視
Gitホスト	GitHub	GitHub	GitHub
オーケストレーター	GitHub Actions	自前のサーバーとデータベース	自前のアプリ
ランナー	Actionsのランナー	Actions、E2B、Daytona、VPS	自前のアプリかサンドボックス
可観測性基盤	なし（Actionsの実行画面で足りる）	LLMのトレースツール	自前のアプリ

基本方針は「サービスは買い、タスクは作る」です。設計の工夫はタスクに込め、サービスは汎用品で済ませます。

チケット管理については既製品が勧められています。安定していて、利用者がすでに使い方を知っており、外部の人も招きやすいからです。

タスクごとに問いに答える

各タスクについて、次の5つの問いに答えます。

何がこのタスクを起動するか
何をして、どのサービスを読み書きするか
次に何を起動するか
人はどこで関わるか
2つのランが同じ作業をしないよう、何で防ぐか

チケットの発生源に対しては、同じチケットを二重に起票しないための仕組みを問います。

インストール方法

ターミナルで次のコマンドを実行してください。途中で、Claude CodeやCodexなど入れる先を選べます。

npx skills add https://github.com/mattpocock/skills --skill software-factory

エージェントにインストールを任せる場合は、次の文面をそのまま送ってください。

次の Agent Skill をインストールしてください。
https://github.com/mattpocock/skills/tree/main/skills/in-progress/software-factory

まず SKILL.md と付属ファイルの中身を確認し、不審な処理（外部への送信、認証情報の読み取りなど）がないことを確かめてから、Claude Code なら ~/.claude/skills/software-factory/、Codex なら ~/.agents/skills/software-factory/ に配置してください。

置き場所は、すべてのプロジェクトで使うかどうかで選びます。

入れる先	すべてのプロジェクトで使う	特定のプロジェクトだけで使う
Claude Code	`~/.claude/skills/`	プロジェクトの`.claude/skills/`
Codex	`~/.agents/skills/`	プロジェクトの`.agents/skills/`

このスキルは、エージェントが自分の判断で読み込まない設定になっています。使うときは依頼文でスキル名を指定するか、Claude Codeなら/software-factoryで呼び出してください。

使い方の例

1つ目は、何から自動化するか決まっていないときの相談です。

software-factoryを使って、レビュー待ちのPRがたまっている問題を解決するファクトリーを設計してください。まずは人のレビューを残したまま始めたいです。

エージェントはEXAMPLE-TASKS.mdから合うタスクを選び、サービスの枠と各タスクの5つの問いを順に埋めていきます。最初のトリガーは1つに絞り、どこで人が確認するかも答えに含めます。

2つ目は、製品選びの相談です。

software-factoryを使って、ランナーに何を使うか決めたいです。GitHub Actionsと外部のサンドボックスを比べてください。

エージェントは付属のRUNNERS.mdを読んで全体像をつかんだうえで、現在の選択肢を調べ直します。調査資料では選択肢が種類ごとに分けられ、その枠を決めるための問いが並んでいます。返ってくるのは、その問いに沿った比較です。

3つ目は、1つのタスクを詰める依頼です。

software-factoryを使って、PRの自動レビューのタスクについて、起動条件、読み書きするサービス、次に起動するもの、人の確認箇所、重複実行の防ぎ方を整理してください。

5つの問いに1つずつ答えた整理が返ってきます。答えが出ない項目は、そのまま設計の未決事項として残ります。

注意点

software-factoryは設計を整理するためのスキルです。含まれるファイルはSKILL.mdと5つのMarkdown資料だけで、自動化を動かすスクリプトは入っていません。GitHub Actionsの設定やランナーの構築は、設計が固まったあとに別途進めることになります。

付属の調査資料にある製品の情報は、全体像をつかむための手がかりです。SKILL.mdには、現在の選択肢はエージェントが自分で調べ直すよう書かれています。製品の機能や料金は、決める前に公式の情報で確かめてください。

スキルはリポジトリのin-progressフォルダに置かれており、ライセンスはMITです。入れる前と更新したときに、SKILL.mdと付属ファイルの中身を読んでおくと安心です。

まとめ

software-factoryは、チケットやPRからマージまでをエージェントに任せる仕組みを、共通の用語で設計するためのスキルです。チーム内で呼び方がそろっていない開発リーダーや、構成を一から考える個人開発者に向いています。

**最初に整理するのは、解きたい問題と、それを担う1つ目のタスクの5つの問いです。**そこから枠ごとの製品を決め、トリガーを1つずつ増やしていきます。

インストール方法と概要はcccskillsのページにまとめています。リポジトリは https://github.com/mattpocock/skills/tree/main/skills/in-progress/software-factory です。

よくある質問

自動化の仕組みそのものを作ってくれますか: このスキルが扱うのは設計の用語と考え方で、構築の手順やスクリプトは含まれていません。助けてくれるのは、どのサービスを使い、どのタスクを何がきっかけで動かすかを決めるところまでです。
GitHubだけで構成できますか: できます。構成例の1つが、チケット管理をGitHub Issues、オーケストレーターをGitHub Actions、ランナーをActionsのランナーにする形です。この構成ではActionsの実行画面で足りるため、可観測性基盤は置いていません。
何から自動化すればよいか分かりません: 解きたい問題をそのまま伝えてください。未分類のチケット、自動レビュー待ちのPR、誰も読まないバグ報告などがあれば、エージェントがEXAMPLE-TASKS.mdから対応するタスクの例を示します。
自動化で品質が落ちないか心配です: 自動チェック、自動レビュー、人のレビューの3つのブレーキを組み込む前提です。トリガーは1つずつ絞って足し、すべてのPRを人が確認するところから始めます。ブレーキが信頼できると分かってから、少しずつ絞りを緩めていきます。

このスキルを試す

software-factory の入れ方とインストールコマンドは、cccskills のスキルページにまとめてあります。

スキルのページを見る GitHub でソースを見る

この記事は、公開されている SKILL.md と cccskills の紹介文をもとに AI（Claude）が下書きし、cccskills 編集部の方針に沿って推敲・公開しています。正確な仕様はスキルのページで原文を確認してください。