AI PMの1年史 2：一本の長い対話から、並列のチームへ
AI PMの1年史 2：一本の長い対話から、並列のチームへ
この時期に起きたこと（2026年3月〜4月）
前の回の最後に、少数の長い対話に全部を載せるやり方は、数か月で形を変えると書いた。その変化は、3月の数字に表れた。
| 月 | メッセージ数 | セッション数 | 1セッションあたり |
|---|---|---|---|
| 2026年2月 | 607,708 | 234 | 約2,597 |
| 2026年3月 | 282,700 | 582 | 約486 |
| 2026年4月 | 184,039 | 667 | 約276 |
セッション数は2月から3月で2.5倍近くに増え、1セッションあたりのメッセージ数は5分の1ほどに縮んだ。作業の単位が小さく、多くなった。理由は統計からは分からない。長い対話の後半に品質が落ちる問題と、複数の作業を並行で進めたい要求が、作業を分ける方向に押したと考えている。これは推測である。
（出典：自社のAI利用統計 2026-02〜04（3台合算）。「1セッションあたり」はメッセージ数をセッション数で割った計算値）
Agent Teams の運用：3月2日、複数のセッションをチームとして協調させる運用を、自社ブログで公開した。当時は、書籍14章、動画14本分のスライドと台本、ブログ19本、企業サイト10ページを1人で制作しており、台本が終わらないとスライドが作れない直列の待ち、台本とスライドで数字がずれる不整合、長いセッションの後半での品質の低下という3つの問題があった。
役割は4つに分けた。台本、スライド、Web編集、そして品質保証である。2つの担当が同じファイルを同時に編集すれば片方の変更が消えるので、役割ごとに書き込んでよいファイルを排他的に決め、書籍原稿と共通のスタイルシートは誰も編集しない原本としてロックした。品質保証は読み取り専用にし、問題は直さずに該当の担当へ知らせるだけにした。動画1章の制作は、丸1日から半日以内に収まった。ただし、半日は運用の実感で、計測した数字ではない。
（出典：自社ブログ記事「Claude Code Agent Teams で1人出版社を運営」2026-03-02）
分けた先で起きたこと：文書が実装に追いつかない
作業を分けて並列で回すと、速くなった。そして、新しい困りごとが出た。最も目立ったのが、文書の鮮度である。
受託のSaaS開発では、画面、API、テーブル定義を、別々の担当に同時に進めさせた。1か月後に実装と文書を突き合わせると、数字が合わなかった。
| 項目 | 文書上の値 | 実装ベース |
|---|---|---|
| 画面数 | 237と244が混在 | 209 |
| テーブル数 | 73 | 75 |
| APIルーター数 | 73 | 75超 |
「文書を書く暇がない」という話ではない。変更の速度が、文書を管理する仕組みを超えた。もう1つの問題はデグレだった。共通部品を変えたとき、ある機能の修正が別の機能に影響した。AIは「今直している場所」に集中する。波及先の見極めは、人が指示しなければならなかった。
対処は2つだった。機能の領域ごとに手順書を分けて必要な文脈だけを渡すこと。そして、フェーズが変わるたびに、手順書を月1回見直すことだ。実装を担当するAIとレビューを担当するAIも分けた。同じAIに「作って、チェックして」と頼むより、役割を分けたほうが、見える問題が増えた。ただしAIのレビュー結果は、人が再確認した。
（出典：自社ブログ記事「SaaS開発をPM1人×AIで乗り切る」2026-03-24）
比較して、乗り換えなかった
3月13日、他社の同種のツールと自社の環境のマルチエージェント機能を比べる記事を書いた。結論は、乗り換えなかった。理由は、費用の見通しやすさと、安全のかけ方だった。担当ごとに使うモデルを選べるので、安価なモデルと高性能なモデルを使い分けられる。作業用のブランチを分けて本番に触れさせない、危険な操作を事前に止めるフックを置く、といった網を運用の側でかぶせられた。この比較は、比較・検証にとどまっている。
4月に入ると案件の種類が増え、教える仕組みを書き足し始めた。AIに仕事を教える仕組みは、規約、フック（作業の前後で自動実行する小さなプログラム）、メモリ（セッションをまたいで残す記録）の3層で整理した。当時の私には筋が通って見えたが、毎回読み込まれる規約は増え続けた。足すことの代償は、足している最中には見えにくい。
（出典：自社ブログ記事「Codex CLI vs Claude Code」2026-03-13、「AIを育てる技術」2026-04-15）
この時期に残ったルール
| 起きたこと | 残ったルール | 守らせ方 |
|---|---|---|
| 同じファイルを複数の担当が触ると、片方の変更が消える | 担当ごとに書き込み先を排他的に決める。原本は誰も編集しない | 書き込み先の一覧表 |
| 台本とスライドで数字が食い違う | 横断の整合性検査を、制作の最後に必ず置く | 品質保証担当（読み取り専用） |
| 設計の誤りが、制作の後半で見つかる | 設計案を先に出させ、承認してから本制作に入る | 計画の承認ゲート |
| 文書の数字と実装の数字がずれる | 手順書は月1回見直す。実装ベースの数字を正とする | 見直しの周期 |
| 共通部品の変更でデグレが出る | 影響範囲の特定は人が指示する。修正後に横断テストを回す | 手順 |
表の右端を見ると、守らせ方の多くは、一覧表や手順、見直しの周期といった、人の運用に依存する形だった。守らせる力の弱さは、次の時期以降の課題になる。
明日からやること
- 並列で動くAIの担当ごとに、書き込んでよい場所を一覧にする
- 文書上の数字と実装の数字を、1つだけ突き合わせてみる
- 手順書の見直しの周期を決め、カレンダーに入れる
- 実装する担当とレビューする担当を分ける
- 共通部品を変えるときは、影響範囲を人が先に指定する
まとめ
作業を分けたら、次に足りなくなるのは文書と正本である。
前回：全部AIと組んだ最初の半年（1）／次回：AIが朝に報告する会社（3）
関連：note連載9：文書管理
