AIを小さな開発チームとして使う

Model Weave
この記事は約8分で読めます。

Model Weaveを作っている中で、AIの使い方が少し変わってきた。

最初は、AIを「便利な相談相手」や「コードを書いてくれる道具」として見ていた。
しかし開発が進むにつれて、ひとつのAIに全部を任せるより、それぞれのAIの得意不得意に合わせて役割を分けた方がうまく回ると感じるようになった。

今は、ChatGPT、Codex、Geminiを小さな開発チームのように使っている。

ChatGPTで構想を整理し、Codexに実装してもらい、Geminiでレビューする。
その結果をまたChatGPTで整理し、次の実装指示やブログ記事へつなげる。

もちろん、AIだけで勝手に進んでいるわけではない。
最終的に何を作るか、何を採用するか、どこで止めるかは人間が判断する。

今回は、Model Weaveの開発で実際に使っているAIの役割分担について書いてみたい。

AIツールを、単体の便利機能ではなく役割で見る

実際のプロジェクトでも、全員に同じ仕事を任せるわけではない。

要件を整理する人がいる。
設計する人がいる。
実装する人がいる。
レビューする人がいる。
品質を見る人がいる。
最終的に判断する人がいる。

AIツールも、それに近い使い方ができると感じている。

ひとつのAIに全部を任せるのではなく、得意なところを担当させる。
そうすると、個人開発でも小さなチームを組んでいるような進め方ができる。

自分の場合、今の役割分担はだいたい次のようになっている。

役割担当主な使い方
プロダクトオーナー / PM人間方針決定、採否判断、違和感の検出
設計・編集・指示整理ChatGPT構想整理、仕様検討、Codex指示、記事化
実装担当Codexコード修正、ファイル更新、ビルド確認
レビュー / QAGemini実装レビュー、抜け漏れ確認、細かい指摘

こう書くと少し大げさに見えるかもしれない。
ただ、実際にModel Weaveを作っている感覚としては、かなりこれに近い。

人間が全部を手で進めるのではなく、必要な役割をAIに割り当てていく。
そのうえで、人間はPMやプロダクトオーナーのように、方針と判断を持つ。

この考え方に変えてから、AIの使い方がかなり整理された。

ChatGPT・Codex・Geminiを使い分けるようになった

使っていて感じたのは、どのAIも万能ではないということだ。

ChatGPTは賢い。
構想を整理したり、仕様の方向性を考えたり、文章にまとめたりするのが非常に使いやすい。
ただし、直接リポジトリを見てコードを修正する役ではない。

Codexは、コードを作れる。
実際のリポジトリを前提に、ファイルを読んで修正し、必要な確認まで進められる。
ただし、トークン消費が大きいので、長い相談を何度も投げるには少し重い。

Geminiは、細かく見てくれる。
実装結果や仕様の抜け漏れを確認するレビュー役として使いやすい。
一方で、かなり機械的に細かく見るので、すべてを採用すると硬くなりすぎることもある。

だから、それぞれを同じように使うのではなく、役割を分けるようになった。

大きな方向性や設計の相談はChatGPT。
実装はCodex。
実装後の別視点レビューはGemini。
レビュー結果の整理や次の指示づくりはまたChatGPT。

この流れにすると、それぞれの強みがかなり活きる。

ChatGPTは、構想整理と指示づくりに向いていた

ChatGPTは、直接コードを触るというより、考えを整理する役として使っている。

Model Weaveで何を作るべきか。
ERとClassのRelationの正本をどこに置くか。
DFDをcustom rendererで作るのか、Mermaid-firstに寄せるのか。
screenやapp_processの仕様をどこまで厳密にするのか。

こうした設計判断の壁打ちにかなり向いている。

特に便利なのは、まだ曖昧な考えを言葉にしてくれることだ。

自分の中では「何となくこの方向がよさそう」と思っている。
でも、まだ記事にも仕様にも実装指示にもできるほど整理されていない。
そういう段階で、ChatGPTに投げると、論点を分解し、選択肢を並べ、見出しや実装方針として形にしてくれる。

Model Weaveの開発では、Codexに渡す実装指示を作る役としてもよく使っている。

Codexには、長い雑談や背景説明をそのまま渡すより、実装チケットのように整理した方が使いやすい。

たとえば、

  • 目的
  • 対象ファイル
  • 作業内容
  • 対象外
  • 確認コマンド
  • 期待する結果

のようにまとめる。

この形にすると、Codexに実装を頼みやすくなる。
ChatGPTは、その前段の整理役としてかなり使いやすい。

また、最近はブログ記事の構成にも使っている。

開発経緯を何本の記事に分けるか。
各回のタイトルをどうするか。
スラッグやタグをどうするか。
アイキャッチをどういう方向にするか。
Xでどう紹介するか。

こういう発信まわりも、ChatGPTと相談しながら進めている。

Codexは、実装担当として強いが、使いどころを絞りたい

Codexは、実装担当としてかなり強い。

実際のリポジトリを前提に、ファイルを読んで修正し、必要なドキュメントやサンプルも更新できる。
Model Weaveの開発では、機能追加、仕様ファイルの更新、READMEの調整、サンプルの修正などをかなり任せている。

これは、ChatGPTだけでは難しい部分だ。

ChatGPTで設計を相談することはできる。
実装方針を作ることもできる。
しかし、実際のコードベースを見て、ファイルを編集し、差分を作るところはCodexの方が向いている。

ただし、Codexは何でも気軽に投げる場所ではないとも感じている。

トークン消費が大きい。
大きな背景説明を何度も渡すと重い。
まだ方向性が固まっていない相談を長々とするには、少し贅沢な使い方になる。

そのため、Codexには「考える前段」ではなく、「実装する段階」になってから渡すようにしている。

まずChatGPTで方針を整理する。
作業を小さく分ける。
実装指示にまとめる。
それをCodexに渡す。

この分け方にすると、Codexの強みを活かしやすい。

実際のプロジェクトでも、実装者に曖昧な相談を延々と投げるより、タスクとして整理して渡した方が進みやすい。
それに近い感覚だと思っている。

Geminiは、細かく見るレビュアーとして効いた

Geminiは、実装後のレビューや抜け漏れ確認に使っている。

使っている感覚としては、かなり細かく見るレビュアーに近い。
実装結果に対して、仕様とのズレ、未対応、説明不足、リスクを拾ってくれる。

たとえば、Codexで実装したあとに、その内容をGeminiに確認してもらう。
すると、細かい観点で指摘が出てくることがある。

このファイルの更新が足りないのではないか。
READMEと実装がズレているのではないか。
既存仕様との整合性をもう一度確認した方がよいのではないか。
このケースは未対応ではないか。

こういう指摘は、かなり助かる。

一方で、すべてをそのまま採用すればよいわけではない。
Geminiは細かく見てくれる分、指摘がやや機械的になることもある。
全部を取り込むと、実装や文章が必要以上に硬くなったり、優先順位がぼやけたりする。

そのため、Geminiは最終判断者ではなく、レビュー担当として置くのがちょうどよいと感じている。

レビューは重要だが、レビュー指摘をすべて採用するわけではない。
これは人間のプロジェクトでも同じだと思う。

指摘を受ける。
意味を確認する。
採用するかどうかを判断する。
必要なら次のCodex指示に落とす。

この流れで使うと、Geminiはかなり強い。

人間は、プロダクトオーナー兼PMとして判断する

この流れにすると、人間の役割は「全部を自分で作ること」ではなくなる。

ChatGPTが整理する。
Codexが実装する。
Geminiがレビューする。

では人間は何をするのか。

自分の場合、人間の役割はプロダクトオーナー兼PMに近い。

何を作るのかを決める。
どの提案を採用するのかを決める。
違和感があるところを止める。
今やらないことを決める。
公開するかどうかを決める。

AIはかなり多くの作業を代替してくれる。
ただし、判断まで完全に任せるものではない。

特に重要なのは、「これは自分の成果物として受け取れるか」という感覚だと思っている。

AIが出した設計案でも、Codexが書いたコードでも、Geminiのレビューでも、最終的に採用するなら自分の判断になる。
ブログ記事も同じで、AIが文章を整えてくれても、自分の言葉として公開できるかは確認する必要がある。

ここは、人間の役割としてかなり大きい。

個人開発では、これまで全部を一人でやる必要があった。
考える。
実装する。
レビューする。
ドキュメントを書く。
発信する。

AIを使うと、この作業のかなりの部分を分担できる。
ただし、その分、人間の役割は「作業者」から「判断者」に寄っていく。

何を任せるか。
何を採用するか。
どこで止めるか。
どこまでを公開するか。

この判断が、人間側に残る。

Model Weaveでは、この体制で開発と発信を回している

Model Weaveでは、この体制がかなりうまくはまっている。

ChatGPTで仕様や記事構成を整理する。
Codexで実装する。
Geminiでレビューする。
レビュー結果をまたChatGPTで整理し、次のCodex指示に変える。
開発が進んだら、ブログ記事として整理し、アイキャッチやX紹介文まで作る。

これは、単にAIに作業を頼んでいるというより、AIを含めた小さな開発体制を組んでいる感覚に近い。

Model Weave自体も、Markdownを正本にして、図やPreviewやdiagnosticsを派生出力として扱う考え方で作っている。
その開発プロセスも少し似ている。

会話やメモがある。
そこから実装指示が生まれる。
Codexがコードに反映する。
Geminiがdiagnosticsのように指摘する。
ChatGPTがそれを整理して、次の判断や記事に変える。

もちろん、きれいに毎回この順番で進むわけではない。
試行錯誤もあるし、戻りもある。
それでも、役割を分けていることで、かなり進めやすくなっている。

個人開発では、設計、実装、レビュー、発信をすべて一人で抱えがちだ。
でもAIを役割で使い分けると、それぞれを少しずつ分担できる。

この感覚は、今後の個人開発ではかなり大きいと思っている。

AIをひとつの万能な存在として見るより、得意不得意のあるメンバーとして見る。
そのうえで、どう配置するかを人間が考える。

自分にとって、ChatGPT、Codex、Geminiの使い分けは、まさにその実験になっている。

次の記事では、この体制によって「自分だけでは作れなかったもの」が作れるようになる、という話を書いてみたい。

コメント

タイトルとURLをコピーしました