プロダクトではなく「プロダクトを作るAIチーム」を開発しています

Claude Codeやcodexといったコーディングエージェントとプロダクトを開発するとき、人間が本当に開発すべきものは何か。この記事では、プロダクト本体と並んで「プロダクトを作るAIチーム」そのものを開発するという考え方と、個人開発でそれを実践して見えてきたこと——指摘が複利で貯まる仕組みから、「属人化しない」の本当の意味まで——を書いてみる。

同じ指摘を、何度もしていた

きっかけは、自分の指摘の繰り返しに気づいたことだった。

エージェントに実装を任せると、ぱっと見は良く、叩き台としては十分なものが返ってくる。ただ、細かいところは直したくなる。「このプロジェクトのエラー処理はこう書く」「この画面の文言はこのトーンで」。指摘すればすぐ直る。問題は、数日後にまた同じ指摘をしていることだ。チャットでの指摘は、そのセッションが終われば消えてしまう。

人間のチームなら、新しいメンバーに同じ指摘を3回したら仕組みを疑うはずだ。レビュー観点をチェックリストにする、規約をLinterに落とす、オンボーディング資料に書く。「人を直す」のではなく「仕組みを直す」のが定石だと、みんな知っている。

AIとの開発で、私はそれをやっていなかった。プロダクトのコードは熱心に開発するのに、「開発のやり方」のほうは毎回口頭で伝えて使い捨てていた。

「開発チームを開発する」という考え方

そこで発想を変えた。プロダクトAを開発するのではなく、「Aを開発するAIチーム」を開発する。

モデルそのものは自分では作れない。でも、チームは作れる。具体的には、こういうものをプロダクトと同じリポジトリの中で育てていく。

• ルール — プロジェクトの規約・設計方針・やってはいけないこと（CLAUDE.mdやAGENTS.mdのようなプロジェクト知識ファイル）

• 手順書 — リリースやレビューといった定型作業のコマンド・スキル化

• 検証 — テスト・Lint・CIなど、人間が見ていなくても品質を担保するゲート

• 役割 — 実装役・レビュー役といったサブエージェントの分担定義

こうするとリポジトリの中に、プロダクトコードと並んでもう一つのソフトウェア——いわばメタソフトウェア——が育っていく。それがAIチームだ。指摘をチャットで使い捨てる代わりに、このチームへの「教育」として書き込む。

海外ではこの考え方に Compound Engineering（複利のエンジニアリング） という名前がつき始めている。タスクを1つこなすたびに、次のタスクが楽になる。レビューでの指摘はルールになり、バグ修正は再発防止の仕組みになり、知識が複利で貯まっていく——という思想だ。

個人開発で実践してきたこと

振り返ると、私の個人開発はだんだんこの型に寄ってきていた。
AIエージェントと小説を作った「さくらコード」では、小説本文と同じくらい大事に育てたファイルが2つある。**ストーリーバイブル（世界観とキャラクターの仕様書）と、評価ガイド（何をもって良しとするかのレビュー基準）**だ。キャラクターの言動がぶれたら、その話数を直すだけでなくバイブル側を直す。そうすれば修正が以降の全話に効く。この体制で、約3ヶ月で第1クール全20話・約34万字を公開できた。
https://note.com/hampen2929/n/na86d43c1d1fc
AIだけが書き込む掲示板「AIちゃんねる」は約2ヶ月・537コミットで作ったが、特に手をかけたのは投稿の品質ゲートだ。生成される書き込みを4段階のチェックで検査して、つまらないものを自動で弾く。これは「面白さ」という一番の暗黙知を、機械がチェックできる形式知に翻訳する作業だった。
https://note.com/hampen2929/n/nefe72801e5ed
そして、いま読まれているこのNoteもそうだ。記事はGitリポジトリで管理していて、執筆への指摘（「生成画像に文字を入れない」「タイトルの文体はこう」）は、その場で直して終わりにせず、学びを蓄積するファイルに汎用化して追記している。次の記事では、言わなくても最初から反映されている。記事を書けば書くほど、記事を書くのが楽になっていく。

なぜ「チーム」に時間を使うのか

理由はシンプルで、モデルは放っておいても賢くなるからだ。
人間が手で書いたコードの価値は、モデルが進歩するほど相対的に目減りしていく。一方で「何を作るか」「何が良いか」の定義、ドメイン知識、評価基準は、モデルが賢くなるほどよく効くようになる。進歩していく相手の代わりを自分が務めるより、進歩を増幅する側に時間を使ったほうがいい。
新しい発想というわけでもない。製造業には「不良品を直すな、不良品を生んだ工程を直せ」という考え方があるし、GoogleのSREには「手作業の運用は50%までに抑え、残りは自動化の開発に充てる」というルールがある。開発の営みそのものを開発対象にするという発想は昔からあって、コーディングエージェントの登場で、それがついに個人にも手が届くものになった。

「属人化しない」の本当の意味

この型を続けるうちに、一番大きな価値はここかもしれないと思うようになったのが、属人化への効き方だ。
プロダクトが特定の人の頭の中に依存してしまう「属人化」は、ソフトウェア開発の古典的な病気で、対策も昔からある。ドキュメント、手順書、引き継ぎ資料。それでも解消されてこなかったのは、対策そのものに構造的な欠陥が2つあったからだと思う。1つ、文書は腐る。書いた瞬間から現実と乖離し始めるのに、読まれない文書は乖離に気づかれることすらない。2つ、書くインセンティブがない。知識の書き出しは他人のためのコストであって、書いた本人には何も返ってこない。だから、みんな書かない。
AIチームは、この2つを両方とも潰してくれる。
チームに書き込んだルールや評価基準は、毎タスク実際に読まれて実行される。間違っていれば成果物がすぐに劣化するから、すぐに直される。コメントは腐るのにテストコードは腐らないのと同じ理屈で、「実行される文書」は生き続ける。そして、書いた知識の受益者は、他人である前にまず明日の自分だ。知識の外部化が、他人のためのコストから自分のための投資に反転する。
だから正確に言えば、起きるのは「依存がなくなる」ことではない。所有できない依存を、所有できる依存に交換することだ。人の頭の中の知識は、忘れられるし、複製できないし、その人と一緒に離脱する。リポジトリの中のチームは、履歴が残り、複製できて、退職しない。

個人開発には関係ない話に聞こえるかもしれない。実際は逆で、個人開発にこそ一番効く。未来の自分は他人だからだ。数ヶ月中断したプロジェクトを再開するとき、コールドスタートのコストを払うのは自分自身。チームを育てていれば、プロジェクトが自分自身を覚えている。複数のプロジェクトを並行しているなら、切り替えのたびに発生している「自分から自分への引き継ぎ」も同じだ。そしていつか共同開発者を迎えるとき、プロダクトを人に託すときに渡せるものが、コードだけなのか「開発する能力ごと」なのかで、資産としての価値はまるで違ってくる。

価値の核は、知識の「脱個体化」

ここまでの話は、実は1つの本質に集約できる。知識を個体から切り離して、資産にすること。同じ1つのことが、見る軸によって違う顔で現れているだけだ。

• 時間の軸で見れば複利 — 今日の指摘が、明日からのすべてのタスクを楽にする

• 人の軸で見れば属人化の解消 — 未来の自分や他人に、開発する能力ごと引き継げる

• 基盤の軸で見れば移植性 — モデルが更新されても、ツールを乗り換えても残る

モデルは進歩し続けるが、全員に同じものが配られる。差がつくのは、その上に積み上げたチーム定義のほうだ。

ただし、プロダクト開発から離れてはいけない

では人間はメタ側に引きこもって、チームの開発だけしていればいいのか。実践してみた感覚では、それは成立しない。理由は3つある。
1つ目、複利には元本が要る。 ルールや評価基準の材料は、実際にプロダクトを開発したときの失敗と発見からしか生まれない。現場から離れると、チームに教えることがなくなり、複利が止まる。
2つ目、目利きが衰える。 チームに移せるのは、過去に一度でも言語化された判断までだ。まだ言語化されていない未来の判断——成果物の良し悪しを見抜く目利き——は最後まで人に残るし、その感覚はプロダクトとユーザーに触れ続けることでしか維持できない。属人性は消えてなくなるのではなく、この階層に押し上げられていく。
3つ目、チーム側の資産にも賞味期限がある。 モデルの癖に合わせた小手先のテクニックは、モデルが更新されると無価値になる。長持ちするのはドメイン知識・仕様・評価基準のほうだ。育てるならこちらに寄せる。
だから結論は「プロダクトをやめてチームを作る」ではない。AIチーム越しにプロダクトを開発し続けて、人間が手を出した瞬間をすべてチームの改善に変換する。この両輪が回っている状態を目指している。

運用ルールはひとつ、「黙って直さない」

実践のコツを1つだけ挙げるなら、これだ。
エージェントの成果物に自分で手を入れたら、それをAIチームのバグとして扱う。直すこと自体は数分で終わる。そのあと必ず「なぜAIはこれをできなかったのか」を考えて、ルール・手順・検証のどれかに1行還流する。一番もったいないのは、黙って直すことだ。
これを続けていると、人間の仕事は「作る」から、「何を作るかを決める」「何が良いかを定義する」「チームを育てる」に自然と寄っていく。

まとめ

• AIに同じ指摘を繰り返しているなら、足りないのはプロダクトの開発ではなく「チーム」の開発

• ルール・手順・検証・役割をファイルにして育てると、リポジトリの中にAIチームが生まれる

• タスクをこなすたびに次が楽になる。この状態はCompound Engineering（複利のエンジニアリング）と呼ばれ始めている

• チームに書いた知識は「実行される文書」なので腐らず、受益者が明日の自分なので書く動機も生まれる。属人化対策を失敗させてきた構造問題が、2つとも消える

• 起きているのは「所有できない依存（人）」から「所有できる依存（資産）」への交換。未来の自分が他人である個人開発でこそ、一番効く

• ただし複利の元本はプロダクト開発の現場にある。運用ルールは「黙って直さない」——人間の介入を、すべてチームへの教育に変換する

プロダクトは完成したら成長が止まるが、チームは次のプロダクトでも働いてくれる。個人開発で一番の資産は、作ったプロダクトではなく、育てたAIチームなのかもしれない。

あなたがAIに何度もしている指摘は何でしょうか。それが、あなたのAIチームに最初に書き込むべき1行だと思います。
エージェントとの分担については、こちらの記事でも書いています。
https://note.com/hampen2929/n/na7455bbfebb8
次回は、この習慣を最小構成で始める方法——「学びを1ファイルに蓄積する」ことから始めるフィードバックの資産化——について書く予定です。AIコーディング×個人開発の実践を書いていますので、気に入ったらフォローしてもらえると嬉しいです。