ZERONOVA LAB（個人運営の AI ネイティブ実験スタジオ）では、無料の Web ツールを継続的に作っています。最近、その開発を「何を作るかを決めて仕様書にする工程」と「仕様書を受け取って実装する工程」の2つに分け、それぞれを別のリポジトリ・別の AI（Claude Code）セッションで動かす形に組み替えました。この記事は、組織なら PdM とエンジニアに分かれているロール分業を、個人開発でどう疎結合に再現したのか、その設計判断の記録です。
具体的には、上流に「何を作るか」を考えて仕様書を生成するリポジトリ（私はこれを spec 工場と呼んでいます）を置き、下流にその仕様書を実装する ZERONOVA LAB のリポジトリを置きました。両者は直接つながず、あいだにブリッジレイヤーを一枚はさんでいます。なぜ1つの環境にまとめず、わざわざ分けたのか。分けるときに「何を共通の通貨にし、何を疎結合に保ち、来歴をどこに残すか」をどう決めたのか。この3点を順に開いていきます。
なぜこの記録を残すか
個人開発のいちばんの強みは、企画と実装が同じ頭の中にあって、思いついた瞬間に手を動かせることです。「企画から実装までのタイムラグをゼロにする」のは、私が ZERONOVA LAB を AI ネイティブ実験スタジオと名乗っている理由そのものでもあります。
ところが、ツールが100本を超えたあたりから、この強みが弱みに反転する場面が増えてきました。「何を作るか」を考えている最中に、頭の中で勝手に「どう実装するか」が走り出してしまうのです。実装の都合（このライブラリなら速い、この構成なら楽だ）が、企画の判断（そもそも誰のどんな課題を解くのか）に逆流して、企画が実装に引きずられる。組織であれば PdM とエンジニアが別の人間なので、この逆流は構造的に起きにくい。役割が分かれていること自体が、判断の汚染を防ぐ仕切りになっています。
個人開発でその仕切りを取り戻したい。けれど、ただ「考える時間」と「作る時間」を分けるだけでは弱くて、すぐに混ざります。そこで、工程そのものを別リポジトリ・別 AI セッションに物理的に分け、あいだの通信をフォーマット化することにしました。組織のロール分業を、人ではなくリポジトリの境界で再現する、という発想です。
開発日記には、この設計の狙いをこう書きました。
この設計は、社内で PdM とエンジニアが分かれているチームのワークフローを、個人開発でもパイプライン化できる例になっている。
ここで言う「パイプライン化」は、上流が仕様書を出し、ブリッジが形式を変換し、下流が実装する、という一方向の流れを指しています。流れを一方向に固定することと、各工程を疎結合に保つことが、この記録の中心テーマです。
判断軸①：何を「共通通貨」にするか
工程を分けると、まず決めなければならないのは「上流と下流が何を介して会話するか」です。人と人なら口頭やドキュメントで補い合えますが、別リポジトリ・別 AI セッションのあいだには共有された文脈がありません。下流のセッションは、上流が何を考えてその仕様にたどり着いたのかを知らない状態で実装を始めます。
そこで、上流から下流へ渡すものを「共通通貨」として明示的に設計しました。中身は2つです。
- 戦略ブリーフ：ZERONOVA LAB の現状、ツールと記事の二層構造、想定読者の分離、ツール選定の5基準、候補テーマの粗評価、判断を歪めやすいバイアスの警告、そして上流に期待するアウトプットの形式。要するに「上流が判断するために必要な、下流側の前提」を一枚にまとめたものです。バイアスの警告を通貨に入れたのは、戦略を組むときに成功サンプル1個に判断が引きずられる失敗を、別の機会に身をもって踏んだからでした。
- 既存ツールの一覧：すでに公開済みのツールを、カテゴリ別に「識別子・名前・1行説明」で並べたもの。上流が「それ、もうあります」を避けて重複アイデアを排除するための辞書です。
この2つを上流に渡しておくと、上流が出してくる仕様書には、機能仕様だけでなく「このツールは記事の素材としてどう効くか」「どんなキーワードで検索流入を狙うか」といった、下流が本来あとから足していた観点が最初から含まれるようになりました。共通通貨を設計した効果がいちばん出たのはここで、通貨の中に「二層構造」という前提を入れておいたからこそ、上流の出力が単なる機能仕様書で止まらなかった、ということです。
逆に言えば、共通通貨に入れ忘れた前提は、上流の出力から確実に抜け落ちます。別セッションは私の頭の中を読めないので、通貨に入っていない暗黙知は伝わりません。「何を通貨に積むか」が、そのまま「上流に何を考えさせられるか」の上限になる。これは分業を設計するうえで、いちばん効いた拘束条件でした。
判断軸②：疎結合をどこで保つか
上流と下流をつなぐとき、いちばん素直なのは下流の実装フローに「上流フォーマットも読めるように」機能を足すことです。最初はその案も検討しました。けれど、最終的には上流と下流のあいだに独立したブリッジレイヤーを一枚はさむ形にしました。このときの判断を、AI との対話として残しておきます。
ZeronovaZeronovaこの対話で決まったのが、ブリッジレイヤーを独立させる、という判断です。理由は3つに整理できました。
- 責務の分離：「実装する」工程と「外部フォーマットを内部フォーマットに変換する」工程は別物で、混ぜると片方の変更がもう片方に波及します。
- 上流フォーマット変更への耐性：上流は別リポジトリで独立して進化します。フォーマットが変わったとき、下流の実装フローを一切触らず、ブリッジだけを更新すれば追従できる。変更の影響範囲をブリッジ1枚に閉じ込められます。
- 概念としての整理：「上流を受け入れる → 実装する → 公開する」の3段階が、3つの独立した工程として並びます。あとから見ても、どこで何が起きるかが追いやすい。
ここで自分が外していなかったのは、疎結合とは「変更の影響範囲を局所化すること」だという分離でした。上流と下流を別リポジトリに置いただけでは、つなぎ目の知識が両側に散らばって、結局どちらを変えても両方を触ることになります。つなぎ目の知識をブリッジ1枚に集約したからこそ、上流と下流はお互いの内部事情を知らずに済む。分けることと疎結合に保つことは、別の作業なのだと実感しました。
判断軸③：来歴をどこに残すか
疎結合にすると、こんどは「いつ、どの仕様書を受け取って、何を実装したのか」という来歴が追いにくくなります。別リポジトリ・別セッションで動く以上、放っておくと「気づいたらできていた」状態になりがちです。
最初に書いた設計では、上流リポジトリのローカルな置き場所を絶対パスで指定して、下流からそこを直接読みにいく形にしていました。これも対話で方針転換しています。
ZeronovaZeronovaこの方針転換で得たものは3つでした。来歴がリポジトリの履歴に残るので「どの仕様書を受け取って実装したか」を後から追える。絶対パスをやめたので、どのマシンでも同じように動く。そして「受け取ったけれど実装しなかった」仕様書も、見送った理由を添えて履歴に残せる。疎結合を保ちながら、来歴だけは下流のリポジトリに集約する、という形に落ち着きました。
この判断の裏には、少し恥ずかしい失敗もありました。別の作業で、下流から上流に渡す資料を生成したとき、その出力先をリポジトリの外側の一時ディレクトリに置いてしまったのです。「なぜリポジトリの外に勝手にアクセスしているのか」と指摘を受けて、判断ミスを認めて消しました。AI 側のデフォルトには「成果物」と「中間ファイル」の区別がなく、放っておくと成果物までリポジトリの外に置いてしまう。人が手に取って使うものは、最初から履歴の残る場所に置く。来歴をリポジトリ内に集約する、という拘束条件は、この失敗の裏返しでもあります。
分けたことの副産物：工程が単純になると設計を使い回せる
3つの判断を実際に動かしてみて、想定していなかった副産物がありました。工程を疎結合に分けると、ひとつひとつの工程がそれだけで完結する単純な部品になり、ある工程の設計を次の工程の足場にそのまま使い回せるようになったのです。
今回のブリッジレイヤーを作るとき、私はゼロから設計したわけではありませんでした。下流にはすでに「実装する工程」が存在していて、それは「前提チェック → いくつかのステップ → 人間が確認するゲート」という骨格を持っていました。新しく作るブリッジレイヤーも、入力の前提を確認し、変換のステップを踏み、最後に人間が補完結果をレビューする、というまったく同じ骨格で書けました。すでにある工程の構造を、新しい工程がほぼそのまま踏襲できたのです。
これが成り立ったのは、工程が疎結合だったからです。もし上流フォーマットの認識を下流の実装工程に埋め込んでいたら、実装工程はどんどん複雑になり、その複雑な塊から「骨格だけ」を取り出して再利用するのは難しかったはずです。工程を分けて、それぞれを単純な責務に絞っておいたからこそ、骨格が見える形で残り、次の工程の設計コストが下がりました。
そしてもうひとつ。新しいブリッジレイヤーが1セッションでほぼ完成したのは、その前に下流側の前提（ツール選定の5基準、仕様書のテンプレート、実装工程の前提チェック）を先に整えていたからでもありました。「上流から仕様書が来た、どう実装につなげるか」という問いに、すでにあるドキュメントが半分以上答えてくれている状態だったのです。事前の構造化が、あとからの実装速度を生む。疎結合な分業は、この「構造化の貯金」が効きやすい形でもあります。各工程が独立しているぶん、ひとつの工程に貯めた構造が、別の工程の足場として無駄なく効いてくれます。
つまり、上流と下流を分けることの見返りは、判断の汚染を防ぐことだけではありませんでした。工程が単純な部品になることで、設計と前提の再利用が効き、次に何かを足すときの速度まで上がる。分業の利点は、思っていたより広い範囲に及んでいました。
3つの拘束条件としてまとめる
ここまでの判断を、別の誰かが自分の分業設計に持ち帰れる形に圧縮すると、3つの拘束条件になります。
- 共通通貨を明示的に設計する：上流と下流のあいだに共有文脈はない。通貨に積んだ前提だけが上流に伝わり、積み忘れた前提は確実に抜ける。「何を通貨に積むか」が「上流に何を考えさせられるか」の上限を決める。
- つなぎ目の知識をブリッジ1枚に集約する：上流と下流を別リポジトリに置くだけでは疎結合にならない。フォーマット変換という「つなぎ目の知識」を独立したレイヤーに閉じ込めて初めて、上流の変更が下流に波及しなくなる。
- 疎結合でも来歴は1か所に集約する：分業すると来歴が散らばる。受け入れ口を下流リポジトリの中に置き、何を受け取り何を見送ったかを履歴に残す。絶対パスのような環境依存の参照は使わない。
この3つは、上流から下流への一方向の流れを「分けつつ、追える」状態に保つための制約です。フレームワークと呼ぶには軽すぎますが、「別リポジトリにしたのに結局両方を触っている」「いつの間にか実装が進んでいて経緯が追えない」という個人開発の分業でよくある失敗を防ぐには、十分に機能しています。
組織の分業を個人開発に写すということ
この設計が成立したのは、たまたま私が複数のリポジトリと複数の AI セッションを使い分けられる環境にいたから、という面はあります。けれど、本質はツールの数や環境ではなく、「役割が分かれていること自体が判断の質を守る」という、組織なら当たり前に効いている構造を、個人開発に持ち込めるかどうかにあります。
組織では、PdM が仕様を決め、エンジニアが実装し、そのあいだを仕様書や定例が取り持ちます。この分業の利点は、単に手が増えることではなく、企画と実装が別の人格に宿ることで、片方の都合がもう片方に逆流しにくくなる点にあります。個人開発はその人格の分離を失う代わりに、速度を得ています。
今回やったのは、失った人格の分離を、リポジトリと AI セッションの境界で部分的に取り戻す試みでした。上流のセッションは下流の実装都合を知らないまま「何を作るか」だけを考え、下流のセッションは上流の判断経緯を知らないまま「どう作るか」だけに集中する。あいだを共通通貨とブリッジがつなぐ。速度を大きく損なわずに、判断の汚染だけを仕切れる。
同じことは、1人で複数のプロジェクトを回している人や、企画と実装の頭の切り替えに苦労している人にも、形を変えて持ち込めるはずです。必ずしも別リポジトリである必要はなく、「考える環境」と「作る環境」のあいだに、共通通貨にあたる交換フォーマットを1枚はさみ、つなぎ目の知識をそこに集約する。それだけでも、企画が実装に引きずられる逆流はかなり減ります。
開発日記の最後に、こう書きつけていました。上流と下流を別環境で扱い、ブリーフという共通通貨で連携する設計は、組織が個人になっても分業構造を再現できる面白さがある、と。個人開発の速度を保ったまま、組織の分業の利点を一部だけ借りてくる。そのための具体的な置き場所が、共通通貨・ブリッジ・受け入れ口の3点だった、というのが今回の記録です。
なお、こうして組んだパイプラインそのものを、構築に関与していない別の AI セッションにレビューさせて穴を探した話は、自分で組んだ AI 自動化パイプラインを「静かな成功」から守るに別途まとめています。分けて組むことと、組んだものを外から検査し続けることは、同じ「自分の判断を仕切りで守る」発想の表と裏だと考えています。
Zeronova（呑名 健造）
PdM × AI-Native Builder × Senior UX × Civic Tech
Web/IT業界19年以上・20以上のWebサービスを担当した PdM。コロプラ子会社（株式会社ビジプル）元代表として事業経営を経験。現在はシニア向け BtoC プラットフォームの PdM、かんたん連絡網合同会社（自治会DX）・Koship合同会社の共同代表として ZERONOVA LAB を並行運営。