Claude × Codexで、ぼっち開発をAIチーム化している

AIチームと作る、ぼっち事業のOS という記事を書いた。

そこでは、4つのブログ、公式サイト、事業集計、日次レポート、AIとの作業体制をつなげて、自分の事業を動かす仕組みを作っている話をした。

今回は、その中でも開発の話。

１０数年前にフリーランスとなってから、ずっとひとりで開発している。
チームで動くこともあるが、基本はひとり。

それが生成AIが全盛になってからはひとりで開発している感じがしなくなってきた。
最初は心強い相棒という印象だったが、今はそれぞれが独立して動くチームという認識になった。

全自動ではなく、最終的に何を作るかを決めるのも、何をやらないかを決めるのも、どこで閉じるかを判断するのも自分。
ただ、その過程にはそれぞれ明確に役割がある。

Producer。
Director。
Assistant Director。
Engineer。
Tester。
Designer。
Document Owner。

これらを、ClaudeやCodexに役割として持たせながらチームとして開発を進めている。
AIを「何でもやってくれる万能アシスタント」として使うのではなく、プロジェクトの中の役割として動いてもらう。

この構成がしっくりきている。

これはサービス紹介ではなく、開発体制の話

この記事では、いま作っているサービスの内容は書かない。
具体的な業界名、会社名、顧客名、画面URL、データ構造、API、機能名も出さない。

そこが主題ではないから。
書きたいのは、開発体制の話。

ひとりでWebサービスを作っているときに、AIをどう使うと、会話の勢いだけで進まずに済むのか。
どうすれば、仕様、実装、確認、ドキュメント、リリース判断を分けて進められるのか。

その実践記録。

僕が最近やっているのは、「AIに開発してもらう」というより、「AIチームで開発を進める」に近い。
この違いは、想像するより大きい。

AIを万能助手として使うと、すぐ混線する

AIは便利。
当たり前のことだけど。

相談できる。
コードを書ける。
レビューできる。
テスト観点も出せる。
ドキュメントも整理できる。

でも、全部をひとつの会話に詰め込むと混線する。

最初は方針を相談していたはずなのに、突然実装の細部に入る。
実装の話をしていたはずなのに、いつの間にか仕様変更の判断までAIに寄っている。
テストの話をしていたのに、AIが勝手に新しい仕様を足し始める。
ドキュメント更新のつもりが、過去の前提を持ち出して話が戻る。

こうなると、便利なはずのAIが逆に判断を散らすことになる。

だから、役割を分けることにした。

同じAIでも、Directorとして見るべきものと、Engineerとして見るべきものは違う。
Testerとして見るなら、期待値と実値を照合してほしい。
Designerとして見るなら、情報の見え方や視線誘導を整理してほしい。
Document Ownerとして見るなら、人間向けの文書に反映すべきかを判断してほしい。

「何でもやって」ではなく、「この役割として、この範囲を、この完了条件で」と渡す。

これだけで、AIとの仕事の進み方がかなり変わった。

ClaudeにはProducerとして動いてもらう

ClaudeはProducer寄りに使うことが多い。

これは、Claudeが上でCodexが下、という話ではなく、使いどころの違い。

Claudeには、最初のもやっとした段階で入ってもらう。

何を作るのか。
なぜ作るのか。
どこまでを今回の範囲にするのか。
何をやらないのか。
誰にとって何が大事なのか。

このあたりを、一緒に整理する。
壁打ちの相手。

Claudeはコンテキストの総量が多いし、Codexよりも柔軟なところがあるからこの相手に最適。

プロジェクトが大きくなるほど、いきなり実装に入ると当然ながら危ない。

機能を足すこと自体はできる。
でも、それが本当に今やるべきことなのか。
既存の流れを壊さないか。
ユーザーの一連操作として成立しているか。
あとから説明できる形で残せるか。

そういう上流の問いを、Claudeとかなり長く話す。

この段階では、コードはまだ触らない。
むしろ、触らないことが大事だったりする。

会話しながら、目的、論点、リスク、非対象、判断待ちを整理する。
その後、必要ならDirectorやEngineerへ渡せる形に落とす。

ProducerとしてのClaudeは、プロジェクトの「なぜ」と「どこまで」を整える役割に近い。

CodexにはDirectorや実作業担当として動いてもらう

一方で、Codexは実務進行担当。

Director。
Assistant Director。
Engineer。
Tester。
Designer。
Document Owner。

こうした役割を、タスクごとに切り替えて使う。

たとえばDirectorとして使うときは、目的、scope、やること、やらないこと、完了条件を整理してもらう。
実装担当へ渡すhandoffを作る。
上がってきた結果をレビューする。
今closeしてよいか、まだ確認が必要かを整理する。

Assistant Directorとして使うときは、短い依頼を受けて、必要な確認、要約、handoff起草、実作業担当への分配を支える。

Engineerとして使うときは、実装、build、verify、差分整理を担当する。

Testerとして使うときは、Playwrightや手動確認の観点を整理し、期待値と実値が一致しているかを見る。

Designerとして使うときは、画面構成、情報整理、視線誘導、モックやUI方針を考える。

Document Ownerとして使うときは、仕様変更を人間向けの文書に反映すべきかを判断する。

大事なのは、同じCodexでも、そのときの役割によって「やること」と「やらないこと」を変えること。

Engineerに仕様の最終判断はさせない。
Testerに新しい仕様を足させない。
Designerに実装まで進めさせない。
Document Ownerに実装変更をさせない。

役割を分けると、AIの出力がかなり扱いやすくなる。

ちなみにChatGPTはProを契約している。
使い倒しても早々枯れることもないのでその点を気を遣う必要がなくていい。

役割は、AIを増やすことではない

AIチームというと、AIをたくさん並べることのように聞こえるかもしれない。

でも、本質はそこではなく、同じAIを使っていても、役割を分けることが大事。

役割	主に見るもの
Producer	目的、背景、企画、事業上の意味
Director	scope、判断、handoff、レビュー、close
Assistant Director	整理、要約、実作業への分配、進行補助
Engineer	実装、build、verify、差分整理
Tester	期待値と実値、操作フロー、回帰確認
Designer	情報設計、視線誘導、UI方針
Document Owner	人間向け文書、更新要否、公開粒度

僕は、こう分けている。

考える人。
作る人。
確認する人。
記録する人。
閉じる人。

AIに役割を持たせることでチームになる。

人間を増やしているわけではないけれど、思考・実行の担当を分けている。

handoffが、AIチームの共通言語になる

役割を分けると、次に大事になるのがhandoff。

AIに「これやって」と雑に渡せばおかしくなる。
だから、役割ごとに渡す文面を決める。

たとえばEngineerに渡すなら、次のようなことを書く。

• どのbranchで作業するか
• どのworktreeを見るか
• どのHEADを前提にするか
• 今回の目的は何か
• 今回やることは何か
• 今回やらないことは何か
• 完了条件は何か
• どのドキュメントを読むか
• 終わったら何を報告するか

Testerに渡すなら、期待値、確認URL、port、起動前提、確認する操作、報告形式を書く。

Designerに渡すなら、今回の対象範囲と、今回変えない共通要素を書く。

Document Ownerに渡すなら、どの変更が人間向け文書に影響するのか、どの文書に反映すべきかを見てもらう。

このhandoffが、AIチームのインターフェース。
skillに設定したりして、共通言語を合わせていく感じ。

別スレッドは、前の会話を全部覚えている前提にしない。
毎回、その指示文だけで着手できるようにする。
背景だけではなく、やること、やらないこと、完了条件まで書く。

これをやると、人間が頭の中で覚えておかなくてはいけない量がかなり削減される。
「前に話したよね」を減らせる。

AIに任せるほど、指示文が大事になる。

これは、実際にやってみて強く感じている。

docsは、会話の記録ではなく作業場所になる

もうひとつ大事なのが、ドキュメント。

AIと開発していると、会話はどんどん流れていく。

その場では分かっている。
でも、別スレッドに渡すとき、翌日に再開するとき、別の役割で確認するとき、会話だけでは足りなくなる。

コンテキストの消費を制限するのも限界があるし、指示する側としてはストレスもある。

だから、仕様、論点、意思決定、今のactive task、タスク履歴をドキュメントに落としている。

ここでいうドキュメントは、あとからきれいにまとめる議事録ではなく、作業の正本のこと。

今のタスクは何か。
今回の固定前提は何か。
今回採用しない旧前提は何か。
やることは何か。
やらないことは何か。
どこまで確認したらcloseできるのか。

そういうことを、次のAIが読める形で残す。

会話の記憶に頼らず、ドキュメントを読ませる。
これをやると、安定する。

もちろん、ドキュメントを書く手間はある。
なので、それもAIにやってもらう。

ディレクターがドキュメントをまとめ、そのドキュメントに沿ってデザイナー・エンジニア・テスターが動く。
作業者からの返答をディレクターがドキュメントにまとめる。

こうすることで、目標に向かってチームが一丸となって動ける。

「やる」と「やらない」をペアで書く

この運用で、かなり大事にしていることがある。

「やること」だけでなく、「やらないこと」も書く。

AIは、気を利かせて範囲を広げることがある。

たしかに、よかれと思っての提案ではある。
でも、開発ではそれが危ない。

今回触らない共通コンポーネント。
今回変えない導線。
今回扱わない仕様変更。
今回採用しない過去前提。
今回の確認対象ではないもの。

これらを明示しておく。

「ここまでやる」だけでは足りない。
「ここから先はやらない」も必要になる。

これは、人間同士のチームでも同じだと思う。

ただ、AI相手だと、より強く必要になる。

AIは速い。
だからこそ、進んでほしくない方向にも速く進む。

そこを止めるために、scopeを書く。

人間の判断を保つために、境界を書く。

Engineerが作って終わりにしない

以前の自分なら、実装が終わると少し安心していた。

動いた。
buildも通った。
ひとまずOK。

そんな感じ。
でも、今はそこで終わりにしない。

Engineerが実装したら、Testerが見る。

Testerは、単に「画面が表示されるか」だけを見ない。

期待値は何か。
実値は何か。
それが一致したのか。
ユーザーの一連操作として成立しているのか。
途中で詰まらないか。
関係ない画面が一瞬見えていないか。
通常操作に戻れるか。

こういう見方をする。

画面単体で動いても、実際の操作の流れで詰まるならOKではない。
保存できても、そのあと通常の導線に戻れないならOKではない。

この視点は、AIチーム運用を始めてから確かになった。

Engineerは作る。
Testerは見る。
Directorは、その結果を統合してcloseするか判断する。

役割を分けると、実装後の抜けが減る。

DesignerとDocument Ownerがいると、開発が落ち着く

Designerの役割も大きい。
ここでいうDesignerは、ただ見た目をきれいにすることを担当するだけではない。

情報の優先順位を整理する。

どの情報を強く見せるか。
どこを抑えるか。
既存のトーンを壊していないか。
今回変えない共通要素まで触っていないか。

そういったことを見る。

実装者がいきなり画面を作るより、先にUI方針やラフを作っておくと、かなり迷いが減る。

Document Ownerも同じ。

実装が終わったあと、人間向けの文書に反映すべきかを見る。

毎回全部の文書を更新するわけではない。
でも、説明に影響する変更、リリース判断に関係する変更、利用者向けの理解に関係する変更は、文書へ反映する必要がある。

逆に、内部の実装差分だけで、人間向け文書に出す必要がないものもある。

その判断を、Document Ownerが担当すると。

これがあると、実装して終わりではなく、説明できる状態を常にキープしやすい。

ClaudeとCodexを、上下ではなく役割で使い分ける

ClaudeとCodexの使い分けについても少し。

僕は、ClaudeをProducer寄りに使うことが多い。

企画、背景、方向性、論点、判断の整理。
少し大きい話を、長めに考える相手として使う。

Codexは、実務進行に寄せている。

Directorとして整理する。
Engineerとして実装する。
Testerとして確認する。
Document Ownerとして文書更新要否を見る。

ただ、これは固定の上下関係ではない。

Claudeが常に上流で、Codexが常に下流という話でもない。

タスクによってはCodexと一緒に方針を考えることもある。
Claudeには常に第三者的な立ち位置で仕様決めの壁打ちや、作業後の全体的なレビューを担当してもらっている。

大事なのは、AIツールの優劣ではなく、その場でどの役割を持たせるか。
「このAIは何が得意か」より先に、「いま必要な役割は何か」を考える。

そうすると、AIの使い方が少し落ち着く。

人間の役割は減るのではなく、判断に寄っていく

AIチーム化していると言うと、人間の役割が減るように聞こえるかも。
実際手数は減るのだけど、実感としては少し違う。

手を動かす量は減る。
調査、実装、テスト、要約、文書整理をAIに渡せる場面は増えた。

ただ、人間の判断はむしろ重要になる。

何を作るのか。
なぜ今それをやるのか。
どこまでを今回のscopeにするのか。
何をやらないのか。
どの報告を採用するのか。
どこでcloseするのか。

これは、人間が持つ。

AIに任せるほど、人間側の判断の仕方が問われる。

曖昧なまま渡すと、曖昧なまま進む。
だから、目的を書く。

やることを書く。
やらないことを書く。
完了条件を書く。
確認結果を見る。
必要なら差し戻す。

AIチームは、人間を不要にするためのものではない。

人間が判断に集中するための構造だと考えている。

まだ完成形ではない。でも、ぼっち感は薄くなった

この運用は、まだ完成形ではない。

handoffが長くなりすぎることもある。
役割を分けすぎて、逆に重くなることもある。
別スレッドに渡す前提を書きすぎて、ちょっとした修正に時間がかかることもある。
AIの確認結果を、そのまま信じてはいけない場面もある。

それでも、全体としてはかなり前に進みやすくなった。

ひとりで開発しているのに、ひとりで全部を考えている感じは薄い。

方針を考える相手がいる。
実装する担当がいる。
確認する担当がいる。
ドキュメントを見る担当がいる。
close判断の材料を出す担当がいる。

もちろん、それは全部AI。

でも、役割を分けて、handoffを書いて、docsを正本にして、確認して、閉じる。
そうすると、かなりチーム開発に近い運営になる。

僕がいま作っているのは、AIで全部を自動化する仕組みではない。
ぼっち開発を、AIチームで進められるようにする仕組み。

ぼっち事業のOS の中で、開発体制そのものも少しずつ変わってきた。

その現在地として、Claude × Codexで、ぼっち開発をAIチーム化している。