エージェントを8個同時に動かしたら、開発は8倍速くなる？
ミドリ： タツヤさん、最近のAIコーディングツールって、エージェントを何個も同時に走らせられるんですよね。エンジニアの方が「8並列」と言っていて驚きました。
タツヤ(nodding)： 実際できるようになったよ。並列実行を前提にしたCLIツールが増えたし、自律的に作業を振り返りながら進めるエージェントも次々出ている。
ミドリ(smiling)： じゃあ開発が8倍速くなるんですか？
タツヤ(thinking)： ……そこが今日の本題でね。実装は確かに速くなる。でも全体が8倍になった会社は、ほぼ見たことがない。
ミドリ： どこで詰まるんですか？
タツヤ： 人間のレビュー。並列化は、ボトルネックを消すんじゃなくて移動させるだけなんだ。
何が並列化されたのか
ミドリ： そもそも、何が同時に動いているんですか？
タツヤ： ざっくり3つの形がある。
| 形 | 内容 | 向く作業 |
|---|---|---|
| タスク並列 | 独立した機能を別々のエージェントが実装 | 機能追加、バグ修正 |
| 視点並列 | 同じ対象を違う観点で複数が検査 | レビュー、監査 |
| 試行並列 | 同じ課題に複数案を作らせて比較 | 設計判断、リファクタ方針 |
ミドリ： 同じものを何個も作らせる、というのもあるんですね。
タツヤ： 3つ目が意外と強力でね。設計方針を3案同時に作って、動くものを見てから選ぶという進め方ができる。今までは机上で議論していた部分が、実物比較になる。
ミドリ(thinking)： 議論の時間が実装の時間に置き換わる感じですか。
タツヤ： そう。しかもエージェントの実装は捨てても痛くない。「捨てる前提で作る」が現実的な選択肢になったのが、この2年でいちばん大きい変化かもしれない。
並列で必ず起きる3つの事故
ミドリ： うまくいかないパターンも聞きたいです。
タツヤ： 定番が3つある。
事故1：同じファイルを同時に書き換える
タツヤ： いちばん多い。2体のエージェントが同じ設定ファイルを触って、後から書いた方が前の変更を消す。
ミドリ： 気づけるものですか？
タツヤ： 気づけないことがあるのが怖いところ。テストが通ってしまうと、そのまま統合されて、数日後に「なぜかこの設定が消えている」となる。
ミドリ(surprised)： 静かに壊れるんですね……。
事故2：全員が同じ勘違いをする
タツヤ： 2つ目。同じ指示を渡して並列で走らせると、全員が同じ方向に間違えることがある。
ミドリ： 多数決で確認すればいいのかと思ってました。
タツヤ(thinking)： そこが落とし穴でね。同じ材料・同じ指示で動いた3体が一致しても、それは検証になっていない。同じ前提から出た同じ結論なんだから、当たり前に一致する。
ミドリ： じゃあ、どうすれば……。
タツヤ： 観点を変えて走らせる。「正しく動くか」「セキュリティ的に問題ないか」「既存の書き方と揃っているか」というふうに、それぞれ違う目で見させる。同じ質問を3回するのは無意味だけど、違う質問を3つするのは意味がある。
事故3：レビュー待ちの山ができる
タツヤ： 3つ目が本丸。8体が並列で成果物を出すと、レビュー対象が8倍になる。
ミドリ： レビューする人は8人になりませんもんね。
タツヤ： そう。結果として、エージェントは1日で終わったのに、統合まで2週間かかるという状態になる。これが「速くなった気がしない」の正体。
タスクの割り方の原則
ミドリ： 事故らないための分け方はありますか？
タツヤ： 4つの原則を守るだけで、かなり違う。
- 触るファイルが重ならないように割る — 分割の基準は機能ではなくファイルの所有。同じファイルを触るタスクは並列にしない
- 1タスクの粒度は「レビューが30分で終わる量」 — 大きすぎる成果物は、並列化の効果をレビューが食い潰す
- 共通部分の変更は先に、単独で終わらせる — 共通ライブラリや型定義の変更は並列化しない。先に1体でやって確定させる
- 作業場所を物理的に分ける — Gitのワークツリーやブランチを分け、同じ作業ディレクトリで複数体を動かさない
ミドリ： 「ファイルの所有」で割る、というのは新鮮です。
タツヤ(nodding)： 人間のチームだと、機能で割って「まあ被ったら相談で」で済む。エージェントは相談してくれないから、被らせない設計が要るんだ。
レビュー詰まりをどう解くか
ミドリ： 一番の課題はレビューでしたよね。ここはどうすれば？
タツヤ： 3段構えにする。人間が最初から全部見るのをやめるんだ。
第1段：機械チェック(人間ゼロ)
型検査 / テスト / 静的解析 / フォーマット
→ 落ちたらエージェントに差し戻し、人間は見ない
第2段：AIレビュー(観点別に並列)
正しさ / セキュリティ / 既存コードとの一貫性
→ 指摘をエージェント本人に返して直させる
第3段：人間レビュー(ここだけ人間)
「この変更を本当に入れるべきか」の判断のみミドリ： 人間は最後の判断だけ、ですか。
タツヤ： そう。細かい書き方の指摘に人間の時間を使わないのが鍵。人間にしかできないのは「これは作るべきものか」「この方針で会社として困らないか」という判断だからね。
ミドリ(thinking)： 逆に言うと、そこは絶対にAIに渡さないんですね。
タツヤ： 渡さない。判断は残す、作業は渡す。この線引きが崩れると、誰も内容を把握していないコードが本番に積み上がっていく。
人間が把握できる量を超えない
ミドリ： そもそも、並列数って上限を決めたほうがいいんでしょうか。
タツヤ： 決めたほうがいい。基準はシンプルで、その日のうちに人間がレビューを終えられる数。
ミドリ： ツールの上限じゃなくて、人の処理量で決めるんですね。
タツヤ(nodding)： 8並列できるツールで8並列する必要はまったくない。レビュー担当が1人なら、同時に走らせるのは2〜3体が現実的なところだと思う。
ミドリ： 少ないですね。
タツヤ： でも、未統合の成果物を10個抱えるより、確実に統合できる3個のほうが速い。在庫を積んでも出荷できなければ意味がないのと同じだよ。
脱エンジニアの視点で考えると、「どこまでを検収できるか」を自分たちで決められるかが分岐点になります。 作れる量ではなく、責任を持って世に出せる量が上限になる。この感覚は、業務側の人のほうがむしろ持っていることが多い。
効果はどこに出るか
ミドリ： 実際、並列化するとどこが良くなるんですか？
タツヤ： 「速さ」より「選択肢」に効くと考えたほうがいい。
| 期待 | 実際 |
|---|---|
| 実装が8倍速くなる | 実装工程は大幅短縮。ただし全体は統合で律速 |
| 人員を減らせる | 減らない。役割がレビューと判断に移る |
| 品質が上がる | 観点別の並列レビューを入れれば上がる |
| 設計の質が上がる | 複数案を実物で比較できるため上がりやすい |
ミドリ： 「速さ」を期待すると裏切られるけど、「質」には効く、と。
タツヤ： うん。捨てる案を作れるようになったことが本質的な価値だと思う。今までは1案しか作れないから、その案を正当化する議論になりがちだった。3案動かせるなら、比較して選べる。
並列に向かない仕事
ミドリ： 逆に、並列にしないほうがいい作業ってありますか？
タツヤ： はっきりある。この4つは並列にしない。
- 仕様がまだ固まっていない作業 — 前提が動くと全員分やり直しになる。1体で探索してから並列に渡す
- DBのスキーマ変更や共通の型定義 — 全員が依存する土台。ここが動くと全員が壊れる
- バグの原因調査 — 調査は「見つけた情報を次の仮説に使う」直列の作業。並列にすると同じ場所を8回調べるだけになる
- 本番環境への適用 — 順番と確認が命。同時に触ってはいけない
ミドリ(thinking)： 調査が並列に向かない、というのは意外でした。
タツヤ： ここ誤解されやすいんだけど、調査は情報が積み上がって初めて進むんだ。「ログを見る → 怪しい箇所を絞る → コードを読む」という流れがあって、後半は前半の結果に依存している。
ミドリ： 同時にやっても、後ろの人は材料がないんですね。
タツヤ(nodding)： そう。依存があるものを並列にすると、待ち時間が増えるだけ。並列化の前提は「独立していること」だと覚えておくといい。
ミドリ： じゃあ探索フェーズは1体で、実装フェーズから並列、という順番ですか。
タツヤ： それが基本形だね。わからないうちは直列、わかってから並列。この順番を守るだけで無駄な作り直しが激減する。
誰も内容を把握していない状態を避ける
ミドリ： もう一つ心配なのが、コードの中身を誰も知らなくなることです。
タツヤ(thinking)： それは正当な心配だよ。並列化の最大のリスクは速度でも品質でもなく、理解の空洞化だと思う。
ミドリ： 空洞化。
タツヤ： 動いているけど、なぜそうなっているか説明できる人が社内にいない状態。障害が起きた時に誰も直せないし、外部に説明もできない。
ミドリ： 防ぐ方法はありますか？
タツヤ： 3つある。
- 変更の意図を人間の言葉で残す — 何をしたかはコードを見ればわかる。なぜそうしたかは書かないと消える
- 週1回、人間が全体像を口頭で説明する時間を作る — 説明できなければ、理解が追いついていない証拠
- 重要な部分だけは人間が書く — 認証、課金、個人情報。ここは自分で書けるようにしておく
ミドリ(smiling)： 「説明できるか」がものさしなんですね。
タツヤ： それが一番わかりやすい基準だと思う。説明できない量まで作らない。これは並列数の上限を決める、もうひとつの現実的な指標でもあるよ。
よくある失敗
ミドリ： 導入時の注意点は？
タツヤ： 4つ。
- いきなり最大並列で始める — 2体から始めて、レビューが回るか確認してから増やす
- 共通ファイルの変更を並列に混ぜる — 型定義や設定の変更は先に単独で確定させる
- 同じ指示で複数体に検査させて「一致したからOK」とする — 検証になっていない。観点を変える
- 未統合の成果物を溜める — 溜まった時点で並列化のメリットは消える。統合できない分は走らせない
ミドリ(thinking)： 最後の、在庫管理みたいですね。
タツヤ： まさにそうだよ。仕掛品を増やさないという製造業の原則が、そのまま当てはまる領域なんだ。
まとめ
タツヤ： 今日の要点を整理しよう。
- 並列化にはタスク並列・視点並列・試行並列の3形態がある。設計判断には試行並列が効く
- 定番事故は同一ファイルの衝突・全員同じ勘違い・レビュー詰まりの3つ
- 分割の基準は機能ではなく触るファイルの所有。共通部分の変更は先に単独で確定させる
- レビューは機械チェック → 観点別AIレビュー → 人間の判断の3段構え。人間は最後だけ
- 並列数の上限はツールの上限ではなく、その日にレビューを終えられる数
- 得られるのは速さより選択肢。捨てる前提の案を複数作れることが本質的な価値
ミドリ(smiling)： 「8並列できる」と「8並列すべき」は違う、ということですね。
タツヤ： そう。エージェントを増やす前に、統合の仕組みを整える。順番を逆にすると、速くなったのに納期が伸びるという不思議な現象が起きるよ。
次のアクション
ミドリ： 試すとしたら、どこから？
タツヤ： 3ステップで。
- 直近のタスクを「触るファイル」で分類し、重ならない組を2つ作る — まず2並列から。機能単位ではなくファイル単位で見るのがコツ
- 機械チェックを整える — 型検査・テスト・静的解析を、人間が見る前に自動で通す。ここが弱いとレビュー詰まりは絶対に解けない
- レビュー観点を3つ文章化する — 「正しさ・安全性・一貫性」など。これがAIレビューの入力になり、人間の見る範囲も明確になる
タツヤ： Shimanto AI Solutionsでは、この移行を支援しているよ。
- 並列前提の開発プロセス設計 — タスク分割の基準づくりから、作業場所の分離方法まで整える
- 3段レビュー体制の構築 — 機械チェックの整備と、観点別AIレビューの導入を伴走
- 統合が詰まらない運用への改善 — 仕掛品を溜めない並列数の決め方と、指標の可視化を支援
ミドリ： エージェントを増やす話じゃなくて、受け止める仕組みの話なんですね。
タツヤ： そこが本質だよ。作る力はもう十分にある。足りないのは受け止める力なんだ。
情報の時点について
本記事は執筆時点(2026年8月)における当社の開発運用での実践に基づく整理です。並列実行の上限や機能は各CLIツールのバージョンで異なるため、具体的な設定値は利用中のツールの公式ドキュメントをご確認ください。