ファクトリーエンジニアリング

AI がコードを書く速さに、人間の判断が追いつかない。レビューと承認がボトルネックになる。ファクトリーエンジニアリングは、判断の基準を定義してゲートに委譲し、人が判断する回数を減らす試みです。

本資料におけるソフトウェアファクトリーとは、仕様と基準を人間から受け取り、実装と判定を行うパイプラインとアセットの組です。ループエンジニアリングとの違いは、基準の委譲を前提としているかどうかです。本資料では、基準を価値基準、判断基準、品質基準に分割して捉えています。それらの基準によって、決まらないものだけが人に問われるようにしました。

0. AI エンジニアリングのこれまでとこれから。プロンプト、コンテキスト、ハーネス、ループ、ファクトリー
1. ソフトウェアファクトリーとは。Stripe、OpenAI、AI Engineer World's Fair 2026 の現物と定義
2. パイプラインとアセット。パイプライン 8 要素とアセット 7 つ
3. 基準を委譲する。3 つの基準、基準のフォーマット、基準がアップデートされていくサイクル
4. 仕様駆動開発との違い。Spec Kit、OpenSpec、Kiro、BMAD にあるものと無いもの
5. 「ソフトウェアファクトリー」を作ろう。OpenFactory の skill、todo アプリの実例、Issue から PR、人間の判断、マージまでのタイムライン
6. エンジニアは「理解」を手放していいのか

実装は OpenFactory でしてみました。Claude Code の plugin として公開されています。

https://github.com/ito-p/open-factory

OpenFactoryで試しに作った todo アプリの Issue と PR と trace は下記で公開されています。

https://github.com/ito-p/opfx-todo-fullstack-v2

Transcript

1. ファクトリーエンジニアリング 「ソフトウェアファクトリー」を作ろう 1
2. 0 エンジニアリングの推移
3. AI エンジニアリングのこれまでとこれから できなかったことを、次のエンジニアリングが克服してきた プロンプト コンテキスト ハーネス 2022 年から 2025 年から 2026 年から やり⽅ 指⽰を磨く 前提を⽂書で渡す できたこと 単発の質が上がる 仕様が基準になる できなかったこと ⻑い仕事で崩れる 守られたかを 確かめられない ファクトリー エンジニアリング ループ 2026 年から テストと判定を回す エージェントが 通しで回す 守られたかを フェーズをまたぐ ⾃動で確かめる 次のフェーズの 1 session で終わる 開始に⼈間の 判断が必要 基準を与えて判断を委譲し、より⻑期的・⾃律的にループを回す 出典: vibe coding、context engineering、Spec-driven development ／ Spec Kit、OpenSpec、Kiro、BMAD の公式文書 ／ Harness engineering ／ Honk の記事。Part 1 と Part 3 ／ Agentic Software Factory と Factory 2.0 ／ AI エージェントとは 3
4. 1 ソフトウェアファクトリーとは？
6. 「ソフトウェアファクトリー」とは Stripe 2026 年 2 ⽉ OpenAI 2026 年 2 ⽉ World's Fair 2026 年 6 ⽉ マージされる PR のうち、 毎週 1,000 件超が agent 製。 ⼈間が書いたコードは含まず、 レビューと承認は⼈間が担う 3 から 7 ⼈と Codex で、 5 か⽉、⼿書きのコード 0 ⾏。 約 100 万⾏、PR 約 1,500 件。 ⼈間は仕様と受け⼊れ基準、 検証と判断に回る トラック名は 「Software Factories」。 Microsoft、OpenAI、 Warp ほかが登壇。 Warp の講演。ソフトウェア エンジニアリングは factory engineering になる Minions。stripe.dev の記事 Harness engineering の記事 AI Engineer World's Fair の基調講演 この資料の定義 仕様と基準を⼈間から受け取り、実装と判定を⾏うパイプラインとアセットの組 Factory の定義は「⾃律でソフトウェアを開発するループとライフサイクルの全体」。McKinsey は AI agent factory と呼ぶ 数字は各社の記事の報告値。講演の⽂は主催の Latent Space の記録から 出典: Minions ／ Harness engineering ／ Software Factories のトラック ／ Factory engineers, not product engineers ／ The AI revolution in software development ／ ソフトウェアファクトリーとは何か 6
7. 現在のハーネスエンジニアリング、ループエンジニアリングの課題 ハーネスエンジニアリング 2026 年から ループエンジニアリング 2026 年から テストと判定を回し、 守られたかを⾃動で確かめる エージェントが フェーズをまたいで通しで回す できたこと 課題 ・1 session で終わる ・仕様の drift と⾮決定の⽣成は残る ・次の仕事を⾃分では始めない できたこと 課題 ・次のフェーズの開始に⼈間の判断が要る ・作る側と批評する側を分けても、判定は⼈に上がる ・ボトルネックは⼈間の判断 共通の課題: 判断が⼈間の⼿に残り、⼈間の判断がボトルネックになる 出典: vibe coding、context engineering、Spec-driven development ／ Spec Kit、OpenSpec、Kiro、BMAD の公式文書 ／ Agentic Software Factory と Factory 2.0 ／ AI エージェントとは ／ Honk の記事。Part 1 と Part 3 7
8. ⼈間の判断というボトルネックを部分的に解消 ループエンジニアリングとの違いは、基準の委譲を前提としているかどうか ループエンジニアリング ファクトリーエンジニアリング ⼈間の判断がボトルネック 基準を定義し判断を委譲する 次のフェーズの開始に⼈間の判断が要る ⼈間の判断の速さに依存 ⼈間は重要な判断のみ⾏う ループの速さに依存 部分的に、とは。基準で決まらないものと、基準が⼈を呼ぶ判断は、これまでどおり⼈が⾏う 出典: Agentic Software Factory と Factory 2.0 ／ Spec Kit、OpenSpec、Kiro、BMAD の公式文書 8
9. ソフトウェアファクトリーとは、 仕様と基準を⼈間から受け取り、実装と判定を⾏うパイプラインとアセットの組 ⼈間の想定を、仕様と基準の 2 本で LLM に渡す。仕様は何を作るか。基準はどう判断するか ⼈間の想定 要求、受け⼊れ基準、範囲外 渡す 仕様 基準 何を作るか 価値、判断、品質 ソフトウェアファクトリー = パイプライン + アセット パイプライン。どう回すか 1 トリガー 2 フェーズ 3 オーケストレーション 4 ゲート 5 エスカレーション 6 アーカイブ 7 リトライとコンバージ 8 モニタリング + 読む LLM の想定 context にあるものだけ アセット。何を持つか 1 テンプレート 2 アーティファクト 3 ナレッジ 4 eval 5 エージェント 6 tools 7 trace 決まらないものは⼈に問い、答えを仕様と基準に書き戻す 実装。テスト、レビュー、マージ 出典: The Case for Software Factories ほか ／ AI 主導のコード近代化の備え方 ／ open-factory。設計と実行の記録 9
10. エンジニアの仕事は、人間の想定を LLM に速く・低コストで 伝えるパイプラインを組んで開発・運用することになる エンジニアの仕事は 4 つ。「1 伝える」、「2 レビューする」、「3 答える」。そして、「4 その 3 点だけで開発・運用が済むようにパ イプラインを組む」こと。 ⼈間 1 伝える 想定を渡す 2 レビューする 3 答える 承認して進める 仕様と設計を⾒せる 仕様と計画 実装する 問いを上げる 4 ⾃動化する 答えを戻す 問いを上げる 判定とマージ ソフトウェアファクトリー 出典: Harness engineering ／ Honk の記事。Part 1 と Part 3 なぜ今か。OpenAI 2026 7 人と 5 か月で 100 万行。人間 が書いた行は 0。PR 約 1,500 件をマージ。報告値。 なぜ今か。Spotify 2025 エージェントがマージした PR は 1,500 件超。移行の時間を 60 から 90% 節約。報告値。 10
11. 2 パイプラインとアセット
12. パイプラインとアセット パイプラインが仕様を作り、アセットを使う。仕様がアセットを守る パイプライン 要望 ⼈間の想定を⾔葉に P1 トリガー P2 フェーズ P3 オーケストレーション P4 ゲート 作る 仕様 source of truth P5 エスカレーション 実装にする P7 リトライとコンバージ テスト、レビュー、マージ P6 アーカイブ P8 モニタリング 実装 使う アセット A1 テンプレート 守る 誤りを訂正 A2 アーティファクト A3 ナレッジ A4 eval A5 エージェント A6 tools A7 trace 12
13. パイプラインの 8 要素。どう回すか 要望を仕様に、仕様を実装にする 1 run トリガー P2 フェーズ P3 オーケストレーション P4 ゲート P5 エスカレーション P6 アーカイブ P7 リトライとコンバージ P8 モニタリング P1 要求や不具合の信号が run を始める アーティファクトを順に作る 誰がどのフェーズを持ち、どう渡すか 次へ進めるかを eval で判定する ⾃動で決められない判断を⼈間へ渡す 結果を仕様と trace に書き戻す ⽌まったものを直して、もう⼀度通す 本番の観測の結果が次のトリガーになる 枠組みは発表者の整理 13
14. アセットの 7 つ。何を持つか ロールが使い、パイプラインが読み書きする テンプレート A2 アーティファクト A3 ナレッジ A4 eval A5 エージェント A6 tools A7 trace A1 仕様、計画、タスクのフォーマット 書かれた仕様、計画、受け⼊れ基準 設計のルール、判断の記録 テスト、linter、LLM のレビュー、チェックリスト prompt、skill、subagent、ロール CLI、フレームワーク、sandbox 監査証跡、判断の記録 枠組みは発表者の整理 14
15. 計画フェーズと実装フェーズを繰り返し、仕様と成果物を積み上げる 1 run は計画フェーズと実装フェーズ。ゲートで基準が判定し、通ったものだけが積み上がる 次の run へ。要望と、⼈の答えと、run の記録から 計画フェーズ 仕様の差分、設計、タスク ゲート 1 価値基準、判断基準 ⾚なら直して同じゲートへ ⼈間 要望を出す 基準を定義する 決まらないものに答える 通ったら併合 run n run 3 run 2 run 1 仕様。source of truth 実装フェーズ コード、テスト、設計の記録 ゲート 2 と 3 品質基準、判断基準 ⾚なら直して同じゲートへ 通ったら併合 run n run 3 run 2 run 1 実装の成果物 要件と Scenario が増える コード、テスト、設計の記録が増える 基準で決まらないものは⼈へ。P と A の番号と基準の 3 つは前の枚のもの。枠組みは発表者の整理 15
16. 計画フェーズのパイプラインを通して、アセットはどう変わるのか 上の段は使うアセット、下の段は変わるアセット。⼈の答えは仕様に書き戻す A1 テンプレート A2 アーティファクト A4 eval ⼈の答え 要求の型 要求 形式の検査、判断基準 決まらない問いに⼈が答える A1 テンプレート A5 エージェント 仕様と計画の型 レビューする側の定義 A3 ナレッジ A3 ナレッジ 設計のルール P1 トリガー 計画フェーズ A2 アーティファクト A2 アーティファクト 要望を要求に書く A7 trace P2 仕様、設計、タスク 価値基準 P4 ゲート 1。計画 A7 trace 判定と指摘 run の開始 P5 エスカレーション A2 アーティファクト 仕様に書き戻す A7 trace 問いと答え P と A の番号は前の枚のもの。ゲートは eval で判定し、eval の中⾝はテストと LLM のレビュー 16
17. 実装フェーズのパイプラインを通して、アセットはどう変わるのか 上は使う、下は変わる。ゲートは 3 つ。マージはアーカイブに含める。モニタリングは今は trace A2 アーティファクト 仕様と計画 A3 ナレッジ A4 eval テスト、lint。品質基準 設計のルール P4 ゲート 2。テスト 実装フェーズ テストが増える 次の run の⼊⼒になる 価値基準 P2 A4 eval A5 エージェント 仕様の変更 run の記録 A3 ナレッジ CLI、sandbox コードとテスト CI、判断と品質の基準 A2 アーティファクト レビューする側の定義 A6 tools A2 アーティファクト A4 eval A7 trace 判定 P4 ゲート 3。CI とレビュー A7 trace 判定と指摘 P6 アーカイブ A2 アーティファクト 仕様に併合、マージ A7 trace P8 モニタリング 今は trace A7 trace token、時刻、要約 ⽇付つきの記録 P と A の番号は前の枚のもの。ゲートは eval で判定し、eval の中⾝はテストと LLM のレビュー 17
18. 3 基準を委譲する
19. 価値基準、判断基準、品質基準を定義し、⼈間は重要な判断のみ⾏う 基準の委譲とは、頭の中の基準を定義して渡し、判定を委ねること。決まらないものだけを⼈に問う 価値基準 判断基準 品質基準 決めること 設計と実装で 何を優先するか 通すか、戻すか、 ⼈に問うか 成果物が満たす⽔準 書く場所 A3 ナレッジ A4 eval A4 eval P4 ゲート 1。要望と計画 P4 全てのゲート P5 決まらないものは⼈へ P4 ゲート 2 と 3 仕様と実装に関する基準 当てるゲート ⼯程に関する基準 成果物の品質に関する基準 rubric は判断基準の書き⽅の 1 つで、基準そのものではない。P と A の番号は前の章のもの 出典: Honk の記事。Part 1 と Part 3 ／ Agentic Software Factory と Factory 2.0 ／ AI エージェントとは ／ Spec Kit、OpenSpec、 Kiro、BMAD の公式文書 ／ open-factory。設計と実行の記録 19
20. 基準のフォーマット 基準は 4 つの成分で定義する。書き⽅は記述でも rubric でもよい 条件 何が当てはまるか。 LLM かプログラムが読める⽂ 記述形式 対象 判定の分類 何に当てるか。 変更、計画、成果物 当たる、当たらない、 決められない。または緑と⾚ アクション 通す、直させる、⼈を呼ぶ。 誰がマージするか API の変更。 HTTP API を⾜す、消す、変える 変更は、⼈が PR をレビューし、設計⽂書を要する 判定の分類 条件 対象 アクション rubric 形式。open-factory の api の⾏を短くしたもの - [api] any change that alters an HTTP API => human_review:pr, design:required 判定の分類 対象 条件 アクション ⼈間判断のエスカレーションを規則で限定する 当たらないときと、決められないときのアクションも定義する。⼈はここに定義されたときだけ判断する 置き場は repo、履歴は git。rubric、constitution、steering、hooks、テストは、このフォーマットの書き⽅ 出典: open-factory。設計と実行の記録 ／ Spec Kit、OpenSpec、Kiro、BMAD の公式文書 20
21. 基準がアップデートされていくサイクル run のたびに 1 から 5 を回し、⼈間が判断した回数を減らす⽅向に基準を直す 初版の定義 頭の中の判断を フォーマットに 1 ゲートの判定 eval とレビューが当て、 判定とアクションを出す 次の run から、 直した基準が当たる 2 ⼈間の判断 呼ばれたときに答える。 レビューで指摘する 3 検証 判定と⼈の判断の⼀致。 ⾒逃しと誤検知を数える 基準のアップデートのサイクル run のたびに 1 から 5 を回す 5 履歴 repo に commit する。 理由を残す。変えるのは⼈ 4 基準の再定義 条件やアクションを直す。 答えを仕様と基準に書き戻す 最初から完全な基準は定義できない。⼈間が判断するたびに、その判断を基準に加えて再定義する 次の run からは同じ判断をゲートが⾏うので、⼈間が判断する回数は減っていく 基準を直すのは 4 つ⽬の仕事「⾃動化する」の中⾝。検証の数え⽅は発表者の整理 出典: opfx-todo-fullstack-v2。todo アプリの repo ／ open-factory。設計と実行の記録 21
22. 4 仕様駆動開発との違い
23. 仕様駆動開発にあるものと、ソフトウェアファクトリーで⾜すもの 型と⼿順はツールにある。基準の中⾝と、⼈が起動しなくても回り続ける仕組みは、ファクトリーで⾜す 仕様駆動開発にあるもの ソフトウェアファクトリーで⾜すもの A1 テンプレート A3 A4 3 つの基準の中⾝ 仕様、計画、タスクの型 A2 アーティファクト specs と changes の置き場 A6 tools CLI、IDE、MCP、hooks P2 フェーズ 計画から実装までの段 P4 ゲート 承認と検証。計画のゲートは⼈が承認する + ⾜す 価値、判断、品質の基準を定義して渡し、ゲートで判定 A5 ロール supervisor、handler、worker、reviewer の 4 つ P3 P7 run をまたいで回す batch を回し、⾚は直して同じゲートへ。上限で⼈へ P5 エスカレーションと書き戻し 決まらないものだけ⼈へ。答えを仕様と基準に書き戻す A7 P8 trace とモニタリング 判定と答えと usage を残し、次の run の⼊⼒にする 根拠は次の 2 枚の⼀覧と、例の open-factory。モニタリングはファクトリーでもまだ trace まで。枠組みは発表者の整理 出典: Spec Kit、OpenSpec、Kiro、BMAD の公式文書 ／ open-factory。設計と実行の記録 23
24. 4 つのツールにあるものと無いもの。パイプライン ◎と◯は 1 run の中に集まる。run をまたぐ P3、P7、P8 はツールの外 P1 トリガー P2 フェーズ P3 オーケストレーション P4 ゲート P5 エスカレーション P6 アーカイブ P7 リトライとコンバージ P8 モニタリング OpenSpec Spec Kit Kiro △ ◯ △ ◯ ✕ ✕ △ △ ◯ ◯ △ ◯ △ ✕ ✕ △ ✕ ◎ ✕ △ ✕ ✕ ※ BMAD ✕ △※ ◎ △※ ◯ ◯ ◯ ◎ ✕ ✕ ⼈が呼ぶ。Kiro は hooks BMAD は 1 ticket 無⼈ 1 run の中だけ 計画のゲートは⼈が承認 印か停⽌で⼈へ OpenSpec だけ併合 BMAD は最⼤ 5 回 4 つとも無い ◎ ⾃律で回る、◯ ある、△ ⼀部か⼈の運⽤、✕ 無い、※ 注記。印は発表者の整理。根拠は公式⽂書 出典: Spec Kit、OpenSpec、Kiro、BMAD の公式文書 24
25. 4 つのツールにあるものと無いもの。アセット 型は 4 つとも出す。ナレッジと eval の中⾝は組織が書く A1 テンプレート A2 アーティファクト A3 ナレッジ A4 eval A5 エージェント A6 tools A7 trace OpenSpec Spec Kit ◎ ◎ △※ △※ ◎ △ ◯※ △※ ✕ ✕ ◯ ◯ ◯ ✕ Kiro ◎ ◯ ◎※ ◯※ ◯ ◎ △ BMAD ◎ ◯ ◯※ ◯※ ◎ ◯ ◯ 型は 4 つとも出す Spec Kit は feature 別 器はツール。中⾝は組織 実装と仕様の照合は無い 2 つはロール無し CLI、IDE、MCP、hooks Spec Kit は記述無し ◎ ⾃律で回る、◯ ある、△ ⼀部か⼈の運⽤、✕ 無い、※ 注記。印は発表者の整理。根拠は公式⽂書 出典: Spec Kit、OpenSpec、Kiro、BMAD の公式文書 25
26. 5 「ソフトウェアファクトリー」を作ろう
27. OpenFactory github.com/ito-p/open-factory
28. OpenFactory の skill と agent。誰が何をするか ⼈が呼ぶ skill は init と supervisor。handler、worker、reviewer は同じ session の subagent /opfx:init 最初に 1 回。14 の問いで基準と設定を決め、OpenSpec と .factory と label を scaffold する ⼈間 supervisor Fable 推奨 要望を話す 問いに答える PR を承認 Issue に書き、渡す ⼈に問い、戻す merge と報告 handler Opus 推奨 worker を起こす worker Opus 推奨 計画。ゲート 1 reviewer R1。計画を読む Opus 推奨 ゲート 3。CI 実装。ゲート 2 R2。実装を読む 実線は渡す順。破線は基準が⼈の判断を求めるときだけ。model は init で選ぶ。ゲートは scripts、記録は trace.sh 出典: open-factory。設計と実行の記録 28
29. 実例。todo アプリを Issue 5 件、約 3 時間で ⼈は Issue を書き、基準を 1 度直し、7 回答え、計画と PR を承認した。コードは書いていない 5Issue と PR。全部マージ 約API 料⾦換算の⾒積り $17 約10:003から時間 12:56 7⼈が答えた回数 回 worker #1 タイムライン。2026-09-27、JST #2 68 分 worker の合計。1 件 7 から 30 分 4,341 ⾏ 追加した⾏。76 file #3 #4 #8 準備と基準 基準を直す 答える 7 回 マージ 5 回 10:00 11:00 12:00 13:00 数字は Issue と PR の記録と trace の usage の⾏から。コストは API 料⾦換算の⾒積りで、定額 plan の実費ではない repo: github.com/ito-p/opfx-todo-fullstack-v2。Issue: #1、#2、#3、#4、#8 出典: opfx-todo-fullstack-v2。todo アプリの repo ／ open-factory。設計と実行の記録 29
30. Issue から PR、⼈間の判断、マージまでのタイムライン #1 は計画の承認に⼈が 2 回。基準を直した後の #2 から #4 は、PR の承認に 1 回だけ #1 ⾻組み 起動 10:15 計画 ⼈ 承認 2 回 10:25、10:33 実装 PR #5 10:44 10:57 ⼈が基準を直す。API と DB と振る舞いの変更は、計画の承認ではなく PR で⼈が⾒る #2 完了の切替 #3 削除 #4 永続化 #8 follow-up merge 10:46 起動 計画 実装 PR #6 ⼈ 承認 merge 起動 計画 実装 PR #7 ⼈ 承認 merge 起動 計画 実装 PR #9 ⼈ 承認 merge 起動 計画 実装 PR #10 merge 10:57 11:14 11:29 12:47 11:07 11:24 11:39 12:54 11:13 11:28 11:46 11:13 11:29 11:46 12:56 ⽩い丸は⼈の答え。マージは 5 回とも handler が実⾏し、#2 から #4 は⼈の承認の後。時刻は JST Issue: #1、#2、#3、#4、#8。PR: #5、#6、#7、#9、#10。repo: opfx-todo-fullstack-v2 出典: opfx-todo-fullstack-v2。todo アプリの repo ／ open-factory。設計と実行の記録 30
31. 3 つの基準の例と、⼈間に残ること 例⽰ 価値基準 判断基準 品質基準 例 例 例 ⼈間に残ること ⼈間に残ること ⼈間に残ること 設計や実装は構造の正しさを優 先する 触らない場所と命名の規約を守 る 仕様の⽬的に合わない要望は受 けない 基準を定義する。境⽬の判断に答える UI の振る舞い、API、DB schema の変更は⼈間の approve が要る CRITICAL は⽌める。 QUESTION は⼈へ リトライは 3 回まで。超えた ら⼈へ 基準を定義。決まらないものに答える カバレッジ 95% を満たす テストと lint を通す。CI を 待つ Scenario ごとにテストがある ⽔準とテストの⽅針を書く 例の⼀部は open-factory の init と rubric の template の項⽬。3 つの区分は発表者の整理 出典: Honk の記事。Part 1 と Part 3 ／ Agentic Software Factory と Factory 2.0 ／ AI エージェントとは ／ Spec Kit、OpenSpec、 Kiro、BMAD の公式文書 ／ open-factory。設計と実行の記録 31
32. open-factory の基準は 3 つのファイル reviewer が読む rubric、supervisor と handler が読む config、ゲートが⾛らせる evals .factory/rubric.md .factory/config.json .factory/evals/ triage review scenario-tests.sh reviewer が読む 4 つの重さ。CRITICAL、WARNING、 SUGGESTION、QUESTION rules 6 ⾏。左は条件、=> の右はアクショ ン defaults 2 ⾏。当たらないとき、決められな いとき supervisor と handler が読む max_rounds 3。CRITICAL と QUESTION で⽌める。contest 1 回 gates pnpm test、pnpm build、CI を待 つ。retry 3 回 escalation 条件 a から f で⼈へ 例⽰ ゲート 2 と R2 が⾛らせる delta の Scenario の題が、テスト か source に無ければ⾚ test と lint config の gates の command を⾛ らせる 価値基準 判断基準 品質基準 AGENTS.md と config。ほぼ空だった rules の右側、defaults、review gates、evals、triage の WARNING 3 つの基準のうち、価値基準が最も薄かった。init の knowledge に製品の価値を書かなかったため ファイル: rubric.md、config.json、scenario-tests.sh 出典: opfx-todo-fullstack-v2。todo アプリの repo ／ open-factory。設計と実行の記録 32
33. rules の 1 ⾏と、reviewer の判定と、プログラムの決定 Issue #2 の計画のレビュー。条件は reviewer が読み、アクションはプログラムが読む 例⽰ rules の 1 ⾏ - [api] any change that adds, removes or alters an HTTP API (routes, request or response shapes, status codes) => human_review:pr, design:required id 条件。reviewer が読む reviewer の判定。6 ⾏のうち 3 ⾏ アクション。プログラムが読む PATCH /api/todos/:id の route と、200、404、400 の status を⾜す db no-match table は変えない。done の列は既に在る behavior-change match todo-api に ADDED が 2 つ。todo-web に ADDED 2、MODIFIED 1、REMOVED 1 プログラムの決定。rubric-parse の出⼒ api match human_review: pr design_required: true mergeable_by: handler ⼈が PR をレビューする 設計⽂書が要る マージは handler が実⾏ 既定は、当たらなければ handler がマージ、決められなければ⼈。証拠は reviewer の原⽂を短くした Issue: #2。判定の表は Issue のコメントにある 出典: opfx-todo-fullstack-v2。todo アプリの repo ／ open-factory。設計と実行の記録 33
34. 10:57 に⼈が基準を直した。その diff と理由 計画の段での⼈のレビューをやめ、PR で⼈が⾒る。#1 の後、#2 の前 例⽰ ⾏ 直す前 10:06 直した後 10:57 変わらないアクション [api] human_review:proposal human_review:pr design:required [db] human_review:proposal human_review:pr design:required [behavior-change] ⾏が無い human_review:pr undecidable human_review:proposal human_review:pr mergeable_by:human undecidable の⾏は、10:58 の 2 つ⽬の commit 理由。commit message 10:57 API, DB schema and behavior changes are reviewed by a human on the PR before merge (no plan-stage review) 10:58 undecidable changes are reviewed on the PR, not at the plan stage 効いたこと。#1 は計画の承認に⼈が 2 回。#2 から #4 は PR の承認に 1 回。マージは handler が実⾏した 基準は git 管理で、変えたのは⼈。まだ無いのは、基準の変更を通すゲートと、判定と⼈の判断の⼀致の測定 commit: 10:57 a3f60cc、10:58 aad9db9 出典: opfx-todo-fullstack-v2。todo アプリの repo 34
35. 例: open-factory。パイプラインをどう実装したか △はモニタリングだけ。Claude Code の plugin に、OpenSpec と GitHub を借りて組んだ P1 トリガー P2 フェーズ P3 オーケストレーション P4 ゲート P5 エスカレーション P6 アーカイブ P7 リトライとコンバージ P8 モニタリング opfx ◯ ◎ ◯ ◎ ◎ ◎ ◎ ※ △ 実装 ⼈が Issue を書き label を付ける。supervisor が拾う propose、apply、archive を worker が回す 1 session の subagent。batch は⼈が名指す validate.sh、eval.sh、check-pr.sh。R1 と R2 QUESTION と条件 a から f で⼈へ。答えを書き戻す archive.sh が specs へ併合し PR。mergeable_by retries 3、review 3 回、contest 1。超えたら⼈へ intake の受け⼝はある。観測して開く側は無い ◎ ⾃律で回る、◯ ある、△ ⼀部、※ 注記。印は発表者の整理。根拠は open-factory の設計⽂書と plugin と smoke の記録 出典: open-factory。設計と実行の記録 35
36. 例: open-factory。アセットをどう実装したか OpenSpec の型と CLI を借り、rubric と agents と trace を⾜した A1 テンプレート A2 アーティファクト A3 ナレッジ A4 eval A5 エージェント A6 tools A7 trace opfx ◎ ◎ ◯ ◯※ ◎ ◎ ◎ 実装 OpenSpec の型。Issue、PR、incident の template openspec/specs が source of truth。changes AGENTS.md と config の context。中⾝は⼈が書く rubric.md、test と lint、scenario-tests.sh supervisor の skill。handler、worker、reviewer openspec CLI、gh、git、jq。scripts 15 本 trace.sh が Issue と PR に 1 事象 1 ⾏。usage.mjs ◎ ⾃律で回る、◯ ある、△ ⼀部、※ 注記。印は発表者の整理。根拠は open-factory の設計⽂書と plugin と smoke の記録 出典: open-factory。設計と実行の記録 36
37. OpenFactory で ソフトウェアファクトリーの威力を実感してください！！！ 1 2 3 4 GitHub に製品の repo を 作り、Claude Code を開 く。model は Fable がお すすめ Claude に OpenFactory の repo の URL を渡し、 plugin を install させ る。marketplace add と install の 2 つ /opfx:init。14 の問いに 答える。基準、test の command、model。 handler と worker と reviewer は既定で opus /opfx:supervisor を起動 し、要望を話す。Issue になり、batch を渡すと 回る。人は問いに答え、 PR を承認する repo を作る opfx を入れる init する 要望を伝える repo は github.com/ito-p/open-factory。init の答えは後から .factory/ と openspec/config.yaml で直せる。 出典: open-factory。設計と実行の記録 37
38. 6 エンジニアは「理解」を手放していいのか？
39. すべての理解を⼿放して良いわけがない 理解を⼿放しても、短期的には成功するかもしれない。⻑期的には、応⽤ができなくなる ⻑期 短期 応⽤ができなくなり、 「仕様の定義」も「基準の委譲」も できなくなる 理解を⼿放しても、 成功するかもしれない 重要なのは、理解する必要がある箇所をエスカレーションさせること 理解する必要がある箇所とは、顧客への影響のリスクが⼤きいもの 全てを理解しないで進めてはいけない 特に、⼈間が理解すべきもの UI の振る舞い API 設計 データモデル open-factory の基準の例でも、UI と API と DB schema の変更は⼈間のレビューに回す 出典: open-factory。設計と実行の記録 39
40. これからのエンジニアに求められていること 顧客を理解すること。その先に製品の仕様がある これまで これから コードだけと向き合えば よい時代は、終わった 顧客の理解 顧客と向き合う時代が 来た 仕様と基準の定義 ソフトウェアファクトリー 顧客を理解した⼈間だけが、仕様と基準を定義できる。ファクトリーはその 2 本を受け取って回る 発表者の主張 40
41. 顧客への影響が⼤きい所が、 ファクトリーエンジニアリングで⼈間が判断すべきポイント 攻め 顧客に価値を提供できる所 守り リスクが⼤きい所 例 例 新機能の UI 分析⽤のログ設計 UI 改善 API 設計 DB スキーマの変更 ファクトリーエンジニアリングで、⼈間判断にエスカレーションすべき箇所にあたりをつける 基準のアクションに「⼈を呼ぶ」を定義する所は、まずこの 2 つから 守りの 3 つは、章 3 の判断基準の例と、open-factory の rules の ui、api、db に対応する。例は発表者の整理 出典: open-factory。設計と実行の記録 41
42. 出典(1/4) 枚 3、6、10 3、7、 10、19、 31 3、7 9 - 著者と年 OpenAI 2026-02 Spotify 2025 題 Harness engineering Honk の記事。Part 1 と Part 3 誌名 OpenAI、2026-02-11 Spotify Engineering、2025-11 と 2025-12 Karpathy と vibe coding、context Thoughtworks 2025 engineering、Spec-driven development Anthropic 2026-09 AI 主導のコード近代化の備え方 Galster ほか 2026 Harness Engineering の調査。 2,853 の repo X、2025-02 と 2025-06。 Thoughtworks、2025-12-04 Anthropic、2026-09-23 arXiv 2602.14690 42
43. 出典(2/4) 枚 3、7、8、19、20、23、 24、25、31 著者と年 Spec-driven development ツール 2026 21、29、30、32、33、34 opfx-todo-fullstackv2 2026 9、19、20、21、23、28、 open-factory 2026 29、30、31、32、33、 35、36、37、39、41 3、7、8、19、31 BCG と Factory 2026 3、7、19、31 McKinsey 2025-07 題 誌名 Spec Kit、OpenSpec、 GitHub と kiro.dev、 Kiro、BMAD の公式文書 2026-09 取得。 OpenSpec の issue opfx-todo-fullstackito-p、2026-09-27。 v2。todo アプリの repo Issue と PR と trace open-factory。設計と実 ito-p、2026-09-26 と 27 行の記録 Agentic Software BCG Platinion 2026-03、 Factory と Factory 2.0 Factory 2026-06 AI エージェントとは McKinsey 日本、2025-07 43
44. 出典(3/4) 枚 著者と年 6 McKinsey 2026-04 6 Stripe 2026-02 6 AI Engineer World's Fair 2026 6 Warp 2026-06 6 こぎそ 2026-08 題 The AI revolution in software development Minions Software Factories のトラック 誌名 McKinsey Tech and AI Practice、202604 stripe.dev、Alistair Gray、2026-02-09 ai.engineer 2026-06-30。Latent Space の記録 2026-07-01 Factory engineers, not product Warp、Zach Lloyd、2026-06-18 engineers ソフトウェアファクトリーとは何 note、2026-08-13 か 44
45. 出典(4/4) 枚 著者と年 題 9 Greenfield 2004 The Case for Software ほか Factories ほか 誌名 Microsoft 2004。Wikipedia、FedTech 2022、 Kessel Run。来歴は配布の文書に 45