AIとの役割分担をGitHubへ固定した理由

1. リード

AI と一緒に開発していると、役割分担は会話の流れで少しずつ変わってしまう。今日うまくいった依頼が、明日も同じ前提で通るとは限らない。だから Step50 で大事だったのは、新しい機能ではなく、誰が何を持つかを GitHub 側の文書へ固定したことだった。

Current Context で確認できる役割は明快だ。ChatGPT は設計・レビュー、Cursor は実装、GitHub は正本、最終判断は人間。Qiita 作業は OS 本体と分離して進める。この整理は地味だが、非エンジニアが AI と走り続けるための土台だった。

2. 背景

Season 1 の前半では、MCP をつなぎ、Human Approval を決め、Connector と Dashboard を育ててきた。だが部品が増えるほど、「今この判断はどこに残すのか」が重くなる。会話は速い。速いが、そのままでは正本にならない。

RC 検証週に入ると、この問題はもっとはっきりする。朝の運用で違和感が出たとき、ChatGPT の発話、Cursor の編集、GitHub の文書、Issue の状態がずれていたら、どれを信じてよいか分からなくなる。だから Step50 では、Project Freeze と ChatGPT Handoff を通じて、役割と正本の位置を固定する必要があった。

3. 今回のテーマ

テーマは、AI との役割分担を GitHub に固定したことで、会話の速さより説明責任を優先できるようになったことだ。

AI と作業すると、うまくいった瞬間ほど「このまま全部任せたくなる」誘惑がある。だが任せる範囲を言葉だけで運用すると、成功も失敗も再現しにくい。再現しにくい状態は、朝の運用に向かない。

4. 実際の出来事

Current Context にあるとおり、Step50 で確定したのは次の線だ。ChatGPT は設計・レビュー、Cursor は実装、GitHub は正本、最終判断は人間。Qiita は OS 本体と分離された独立プロジェクトで進める。この分け方は単なる担当表ではない。責任の置き場所を明文化したという意味がある。

ChatGPT が設計とレビューを担うと決めると、少なくとも「その場の会話で本番状態を上書きしない」という安心が生まれる。Cursor が実装を担うと決めると、編集の結果はファイル差分として追える。GitHub を正本にすると、会話の印象よりコミットや文書を優先できる。最後に人間が判断を持つと、Version や公開の責任がぼやけない。

特に大きかったのは、GitHub を正本に固定したことだと思う。AI との会話は、理解を深めるには強いが、現在地の唯一の根拠には向かない。あとで読み返しても、その発話がどの時点の事実だったか分かりにくいからだ。GitHub に寄せると、少なくとも「このコミット時点で何が確定していたか」を追いやすくなる。

RC 検証週の文脈では、この違いがかなり実務的だった。朝の結果に違和感が出たとき、会話ログと頭の中の理解だけでは「今の正式な前提」が分からない。Issue なのか、Current Context なのか、手元のメモなのか、どれを優先すべきかで迷い始める。迷うたびに説明責任は弱くなる。だから Step50 では、判断の速さよりも「何を正本として残すか」を先に固定する必要があった。

この固定は、AI を弱めるためのものでもない。むしろ逆で、AI を長く使うための前提だと思う。ChatGPT が得意なのは、論点整理、設計レビュー、危険の言語化だ。Cursor が強いのは、実際の編集を差分として積み上げることだ。両者の強みをそのまま使うには、どこで会話を止め、どこでファイルへ落とし、どこで人間が最終判断を引き取るかが明確でないといけない。

Qiita を別プロジェクトとして分けたことも重要だった。記事制作は、どうしても表現を整える方向に引っ張られる。だが OS 本体の文書や Version 管理まで同じ場所で触ると、執筆都合で正本を揺らす危険が出る。分離したことで、「書くために本体を変える」を避けやすくなった。

これは Qiita 側の作業を軽く見るためではなく、逆に OS 本体を守るための線でもあった。記事を書く側から見ると、「この表現の方が説明しやすいから Current Status も直したい」「シリーズの流れに合わせて Version の書き方も寄せたい」と感じる瞬間がある。だがその誘惑を許すと、記録のために正本を動かす順序になる。Current Context と PROJECT_RULES が強く分離を求めているのは、その順序の逆転を防ぐためだ。

さらに、この役割固定は公開判断の境界ともつながっている。Qiita の投稿、Version の確定、正式 Go の判断のような本番操作は、人間が持つ。ここが曖昧だと、ChatGPT の提案、Cursor の編集、GitHub 上の進捗が、そのまま「決まったこと」に見え始める。Step50 で最終判断を人間に固定したことで、提案と決定、編集と承認が同じものとして流れていくのを止められた。

5. 考えたこと

AI との役割分担で一番怖いのは、能力の不足より境界の曖昧さだと思う。設計と実装と公開判断が混ざると、誰がどこで止めるのか分からなくなる。止める場所が曖昧だと、速さは出ても説明責任が残らない。説明責任が残らないままの速さは、長く続かない。

非エンジニアの立場では、この整理がかなり効いた。コードの細部を全部評価できなくても、「この話は GitHub に残っているか」「これは実装なのか判断なのか」は見られる。見られる境界が増えると、AI に任せることへの不安が減る。減るのは、丸投げしたからではなく、むしろ丸投げしない形が固まったからだ。

Human Approval ともつながっている。Human Approval は本番操作に境界を引く思想だった。Step50 の役割固定は、それをプロジェクト全体に広げた形に近い。どこまでを AI が担い、どこからを人が持つか。曖昧な善意ではなく、文書化された運用にしたことが大きい。

私は最初、役割分担という言葉を少し事務的に感じていた。だが実際には、これは作業分担より「責任の交通整理」に近かった。設計レビューが強くても、実装差分が見えなければ困る。実装が速くても、正本が曖昧ならあとで追えない。公開まで一気に流れても、誰が最後に止めるかが決まっていなければ怖い。役割を固定することは、それぞれの強みを活かすより先に、事故の起点を減らすことだった。

GitHub を正本に置く意味も、単に便利だからではないと思っている。GitHub に置くと、会話より冷たい。だが冷たいから強い。コミット、ファイル、Issue、Release の形に落ちたものだけが、あとで同じように読み返せる。AI と一緒に走るほど、その冷たさが必要になる。会話が柔らかく前に進めてくれるからこそ、どこかに固い地面が要る。その地面が GitHub だった。

Qiita を独立プロジェクトに分けた意味も、毎日運用を考えるほど重くなる。記事を書いていると、読みやすさのために主語を寄せたり、時系列を圧縮したり、補足を入れたくなる。そうした編集感覚は必要だが、OS 本体の正本へ持ち込むべきものではない。分離していれば、記事側では表現を整えつつ、本体側では事実の固定を守れる。この二層が分かれているだけで、日々の作業はかなり安全になる。

結局ここで守りたかったのは、AI を信用しないことではなく、信用の置き場を間違えないことだった。ChatGPT は設計とレビューで信用する。Cursor は編集と実装で信用する。GitHub は正本として信用する。人間は最終判断で責任を持つ。この並びがあると、何かが揺れたときも「どこへ戻ればよいか」が分かる。毎日触る運営 OS では、その戻り先があること自体がかなり大きい。

毎日公開したい、毎朝自動で回したい、といった継続運用の欲求は強い。だが継続は、気合いより境界で支えられるのだと思う。誰が考え、誰が直し、どこに残し、誰が決めるか。この線が決まっていないまま本数だけ増やすと、昨日は通ったのに今日は説明できない、という崩れ方をしやすい。Step50 で固定した役割分担は、派手な改善ではないが、毎日続けるための土台そのものだった。

特に Qiita のように連日公開を目指す運用では、この土台がないと在庫だけが先に弱る。公開日が近いから出す、画像が足りないけれど先に進める、会話で合意したから確定扱いにする。そうした近道を選びやすいからこそ、役割と正本の境界を最初に固定しておく意味がある。毎日公開できる体制は、毎日がんばることより、毎日崩れない線を残すことから始まる。

6. 学び

• AI との役割分担は、その場の会話ではなく正本の文書に固定した方が強い
• GitHub を正本にすると、会話の印象より確定事実を優先しやすい
• ChatGPT、Cursor、人間の責任境界を分けると判断の迷子が減る
• Qiita を本体と分離すると、執筆都合で正本を揺らしにくい
• 境界が明文化されると、非エンジニアでも運用責任を持ちやすい

7. 次回メモ

この続きで書くなら、テストが Green でも Go にしなかった理由へつながる。役割が整理されても、正式版の判断は別の基準で止まるからだ。