AIエージェントを並列実行する「エージェントマネージャー」という働き方——レビュー速度という新しい壁

複数のAIエージェントを同時に動かす、という発想の転換

VibeCodingが生まれた原点には、ITとは無縁だった一人の女性がいます。プロのタイピングすら実務レベルに達していないにもかかわらず、AIに自然言語で指示を出すだけでアプリケーションを作り上げてしまう。私の妻が見せたその姿こそが、AI-Path創業のきっかけになりました。当時は「1人が1つのAIと対話する」という前提でした。ですが2026年に入り、その前提そのものが変わりつつあります。

私たちの社内では、代表が就寝中もAIへの指示を出し続け、1週間で4〜5個のプロダクトを並行して作り上げるということが実際に起きています。議事録作成AI、需要予測ツール、スライド生成、マーケティング分析——デスクトップに複数のツールを並べて走らせる、いわば「エージェントマネージャー」という働き方です。1人のエンジニアが1つのタスクを順番にこなすのではなく、複数のAIエージェントに同時並行でタスクを渡し、自分は指揮者として立ち回る。これが、いまVibeCodingの現場で起きている変化の本質だと私たちは捉えています。

「並列実行」はもう一部のギークの趣味ではない

「AIエージェント 並列実行」や「Claude Code 並列開発」といった言葉で検索してこの記事にたどり着いた方は、すでに個人の工夫の範囲を超えて「複数AIエージェント 管理」という壁にぶつかっているはずです。Claude Codeのようなコーディングエージェントを複数同時に走らせる手法は、個人開発者の工夫にとどまらなくなってきました。ソフトバンクは2025年、「全社員1人100エージェント」という構想を掲げ、実現に向けて独自のAI管理ツール「Cloud Proxy」を開発しています。現在は240システム・2万人以上のユーザーが利用しており、トークン単位での監視・制御まで踏み込んでいるといいます(@IT の報道より)。1人が扱うAIエージェントの数が、個人の工夫の範囲を超えて企業のインフラ設計の課題になった、ということです。

これは私たちの実感とも一致します。1人のエンジニアが2〜3個のエージェントを並列で使うのは、もはや珍しい光景ではありません。エージェントAにテストを実行させながら、エージェントBには別機能の実装を指示する。エージェントCには先ほどのレビュー指摘の修正を任せる。空き時間ゼロで手を動かし続けられることに、最初は誰もが高揚します。正直に申し上げると、私たちの社内でも「これで生産性が3倍になる」と浮かれた時期がありました。ですが、その先に思わぬ壁が待っていました。

git worktreeとClaude Codeで、実際にどう並列稼働させるか

技術的な仕組み自体は、決して難しくありません。git worktreeは、1つのリポジトリから複数の作業ディレクトリを作り出す機能です。Claude Codeには--worktreeオプションがあり、実行するたびに独立したworktreeでセッションを開始できます。ブランチを切り替えるのではなく、ブランチごとに別々の物理ディレクトリを持つイメージです。

私たちが実践している構成は次のようなものです。

1. worktreeの命名規則を決める(wt/機能名のように統一する)。あとで「どれが何のブランチだったか」を忘れないための最低限のルールです
2. 1つの機能を細かく分割し、依存関係のある小さなPRの連鎖として設計する。大きな1本のPRにしてしまうと、そもそも並列化する意味がなくなります
3. 独立して進められるタスクだけを複数のworktreeに割り当てる。同じファイルを複数のエージェントが同時に触る設計は避けます
4. エディタは開かず、確認はCLIとGitHubのWeb UIで完結させる。ウィンドウを画面いっぱいに広げて視認性を確保するほうが、複数セッションの切り替えには向いています。

RAKSUL社の技術ブログでは、この考え方を「小さなPRの依存チェーン+複数worktreeでの並行作業」として詳しく実践しています。特に「細かいところを自分で直したくなる誘惑を断つ」という一文は、私たちが社内で新人エンジニアに伝えている感覚とほぼ同じでした。AIの性能が上がるほど、ボトルネックは人間の「編集したくなる衝動」に移っていく——この指摘は、次の章の話に直結します。

見えてきた壁——ボトルネックは「AIの数」ではなく「レビューする側の速度」だった

並列実行を試した個人開発者のブログには、共通する率直な告白があります。あるエンジニアは複数のAIエージェントを同時に走らせる実践を重ねた末に、「並列数の上限は、AIの性能ではなく自分のレビュー速度で決まる。ここを見誤ると、ただ散らかるだけだった」と振り返っています(宮崎クリエイターズブログ)。5つのエージェントを同時に走らせても、出てきた成果物を確認する人間は1人のままです。これは私たちの現場でも繰り返し起きた現象でした。

一方で、正直に別の声も紹介しておきたいと思います。ある技術者は多重並列開発に憧れ、実際に試してみたそうです。ですが「人間は同時に3〜4個の事柄しか処理できず、タスクの切り替えには15〜30分の再集中時間が必要になる」という認知科学的な限界にぶつかりました(Zennの記事)。結局、自分には向いていないと結論づけています。つまり、並列運用が誰にとっても正解とは限らないということです。この誠実さは、私たちも共有すべきだと考えています。ワーキングメモリの得意・不得意には、明確な個人差があります。

いくつものプロジェクトで並列運用を試した末に、私たちが行き着いた結論は一つです。この壁を越えられるかどうかを分けるのは「気合」でも「慣れ」でもなく、レビュー工程そのものの設計だということです。人間が全件を目視で確認するという前提を捨てない限り、エージェントの台数を増やすほど確認待ちの列が伸びるだけになります。

私たちがこの壁をどう設計で崩したか——テストの自動化と、それでも人に残す領域

AI-Pathでは、AIが書いたコードの品質を、単体テスト(Vitest)とシナリオテスト(Playwright)の自動化で担保しています。「バグかどうか」「仕様通りかどうか」の一次判定はここで機械的に済ませてしまう発想です。実はこの切り分けには、外部の実践からも裏付けがあります。ある記事によると、あるエンジニアは3カ月・62件のPRにわたるレビュー指摘300件を分析しました。実際に欠陥の減少と相関していたのは「バグ指摘」と「仕様に関する質問」の2種類だけだったといいます。スタイルや命名など残り4種類の指摘は、時間を割くほどむしろレビュー速度を下げていたと報告しています。同記事によれば、低ROIの指摘を自動フォーマッタやAIの自動チェックに任せた結果、レビュー時間を42%短縮できたそうです。つまり、レビューの質を上げたいなら指摘の「量」ではなく「種類」を絞り込むべきだということです。

これは私たちの実感とも完全に一致します。私たちが社内で徹底しているのは、「機械的に判定できることは機械に任せ、人間はUX観点のユーザー受け入れテスト(UAT)だけに集中する」という役割分担です。VibeCodingで起こりがちな「頼んでいない項目がいつの間にか増えている」という事故は、単体テストでは検出できません。ここだけは、実際に画面を触った人間が「使いにくい」「思っていたのと違う」と声を上げる工程として、あえて自動化せずに残しています。台数を増やすときに削るべきは人間の目ではなく、人間が見るべき範囲そのものだ、というのが私たちの結論です。

「AIは壁打ち相手、判断は人間がする」を並列運用でどう守るか

私たちが繰り返し社内で確認している原則があります。AIは信用するのではなく、こちらの考えをぶつけ、前提情報や意図を渡し続けることで初めて深い対話が生まれる、という考え方です。AIは相手を見て会話するため、表向きの情報しか与えなければ表向きの回答しか返ってきません。これはエージェントが1体でも5体でも変わらない大前提です。

台数が増えるほど陥りやすいのが、「とりあえず任せて、あとでまとめて確認すればいい」という発想です。ですが信用は、使ってもらうことでしか積み上がりません。私たちは、新しいタスクの種類をエージェントに任せるときほど、最初は確認の粒度を細かくし、想定通りの成果物が出るとわかった領域から少しずつ確認の間隔を広げるようにしています。裏を返せば、慣れていない業務・重要度の高い業務ほど、並列化の対象から外すべきだということです。台数を増やす判断は、技術的な限界ではなく、この「どこまで信用を積み上げられているか」という基準で決めています。

これは新入社員を迎えるときの感覚に近いといつも感じます。初日から全ての判断を任せる上司はいません。まず小さな仕事を渡し、期待通りの仕事ぶりを何度か確認してから、任せる範囲を少しずつ広げていきます。エージェントに対しても同じ順番を踏むだけのことです。台数を一気に増やしたくなる衝動を抑え、信用を積み上げる速度に運用を合わせる。地味に聞こえるかもしれませんが、これが遠回りに見えて一番早い進め方だと私たちは考えています。

個人の実践から、企業のエージェント運用へ——ソフトバンクの事例に見る統制の設計

先ほど触れたソフトバンクのCloud Proxyは、個人の並列実行がそのまま組織のインフラ課題に接続する好例です。@ITの報道によると、Cloud Proxyはセキュリティ・ガバナンス・運用という3つの障壁に対応するために作られました。Azure OpenAIやGemini、国産LLMのSarashinaなど複数のLLMをまたぎ、APIキーを直接渡さずに間接的に認証させる仕組みを備えています。同記事によれば、IdP連携によって想定されるセキュリティリスクを70%削減し、わずか14週間で3000万リクエストを処理できる規模までスケールアウトしたといいます。つまり、1人あたりのエージェント数が増えるほど、統制の設計を先に用意しておく必要があるということです。

私たちが自社のAIPLA(業務基盤)で徹底しているのも、根は同じ考え方です。資料の閲覧制限だけでなく機能単位でアクセス権を分離し、取引先ごとに権限セットを細かく運用しています。エージェントの数を増やす前に、「誰が・どの範囲で・何を承認したか」を追える設計を先に用意する。これを怠ると、AIの数が増えた分だけ、何か問題が起きたときに原因を追えなくなるリスクも増えます。個人のgit worktree運用も、企業のAIゲートウェイ運用も、突き詰めれば「増えたエージェントをどう統制するか」という同じ問いに行き着くというのが私たちの見立てです。

FDEの現場でどう使い分けているか——伴走開発を並列化した実例

ある中堅の製造業のお客様先では、技術顧問契約のもとで複数のエージェントを役割分担させています。現場からの改善要望はまずイシューとして登録し、翌週にはプロトタイプを持っていく、というサイクルを回しているのですが、この「翌週までに」を支えているのが並列実行です。1つのエージェントには前回指摘された不具合の修正を任せ、別のエージェントには次のイシューの実装を先行して進めさせる。現場担当者と対話しながら、動くものをその場で触ってもらい、要望を反映していく——この「思っていたのと違う、を防ぐ」進め方自体は、私たちがFDEとして一貫して大切にしてきた手法です。並列実行は、その手法をより素早く回すためのエンジンとして機能しています。

ただし誤解のないように申し上げると、現場のすべての工程を並列化しているわけではありません。装置の挙動のような、担当者の感覚に強く依存する領域は、担当者への丁寧なヒアリングを挟みながら1つずつ進めています。属人化した知見をAIに渡す工程まで並列化を急ぐと、かえって手戻りが増えるというのが私たちの実感です。

別のお客様では、生産計画・製造管理システムの技術顧問契約を週2回ペースで回しています。ここでは1つのエージェントに定例前のデータ整備を任せ、もう1つのエージェントには現場から上がった小さな改善要望の実装を並行して進めさせています。「できている」と「使える」の間には距離があります。この距離を埋める作業を、複数のエージェントに役割ごと振り分けることで、月2回だった改善サイクルを週次に近い頻度まで引き上げられました。

自己診断——並列化に向いている業務・向いていない業務

ここまでの実践を踏まえ、私たちが導入判断の際に確認している基準を整理します。

• サブタスクへの分割: 業務を、互いに依存しない小さな単位に切り分けられるか
• 合否の機械判定: 「正しいかどうか」をテストコードやチェックリストで機械的に判定できるか
• 誤りの発覚速度: 万一間違えた場合、その誤りにどれくらい早く気づけるか
• 切り替えへの耐性: 担当者自身が、複数のタスクを行き来する働き方に強いタイプか

4つのうち2つ以上に自信を持って「はい」と答えられない業務は、無理に並列化せず、まず1本のエージェントで丁寧に仕上げる進め方を私たちはお勧めしています。並列化は目的ではなく、あくまで手段です。

AI-Pathの見解——台数を増やす前に決めるべきこと

ここまでをまとめると、私たちの立場は次の通りです。並列実行というエンジンそのものは、確かに生産性を押し上げます。ですが「何台のエージェントを動かせるか」ではなく「どこまでを機械に任せ、どこから先を人間が見るか」を先に設計しておかなければ、台数を増やした分だけ確認待ちの渋滞が発生します。私たちの現場経験では、まず1つの業務・1つのリポジトリで並列運用を試し、機械的に判定できる領域を仕分けてから、対象を広げていくという順序が最も確実でした。

もう一つ付け加えるなら、この設計は一度作って終わりではありません。エージェントに慣れていない業務を任せるたびに、レビューの粒度を見直す必要があります。私たちも、新しい業務領域を並列化の対象に加えるたびに、最初の数回は確認を厚めに戻すようにしています。この地味な調整の積み重ねこそが、台数を増やしても崩れない運用を支えていると考えています。

よくある質問

Q. 何人・何台からエージェントの並列運用を始めるべきですか。 まずは1人が2〜3個のエージェントを同時に扱う規模から始めることを私たちはお勧めしています。いきなり台数を増やすと、レビューの詰まりに気づく前に混乱だけが積み上がります。

Q. tmuxのようなターミナル多重化ツールは必要ですか。 必須ではありません。私たちの現場では、ターミナルを複数起動するほうがスクロールや視認性の面で扱いやすいという声が多く、tmuxのペイン分割はかえって画面を狭くすると感じるメンバーもいます。使い慣れたツールに合わせるのが実務的です。

Q. 並列運用に向いていない人・業務はありますか。 あります。ワーキングメモリの得意・不得意には個人差があり、タスク切り替えのたびに強い負荷を感じる方には、並列よりも1本ずつの逐次処理のほうが結果的に速いケースもあります。業務についても、属人的な感覚に強く依存する領域は、並列化よりも丁寧なヒアリングを優先すべきです。

Q. AIのミスがセキュリティリスクになりませんか。 なり得ます。だからこそ私たちは、本番の顧客環境へ移行する前に攻撃テストを実施し、権限分離とアクセス履歴の記録を先に設計しています。AIツールのミスに起因するセキュリティリスクは、今後どの企業も遅かれ早かれ向き合うことになる課題だと私たちは捉えており、自社で先に厳格な運用を試してから顧客に展開しています。

まず試すなら

1. 今の業務から1つだけ選び、2エージェント構成で試す——全業務を一気に並列化するのではなく、影響範囲の小さいタスクから始めます
2. レビューの一次判定を機械化できないか棚卸しする——単体テストやフォーマッタで肩代わりできる指摘と、人間のUATに残すべき指摘を仕分けます
3. 統制の設計を先に決める——誰がどの範囲を承認するか、何かあったときに追跡できるかを、台数を増やす前に確認します

自社にとって、どこまでを機械に任せられるかは業務によって大きく異なります。私たちは、まず無償の業務プロセス診断(BPR)を通じて現状の業務を棚卸しし、どこにAIエージェントの並列運用が効くかを一緒に見極めるところから始めています。関連してAIエージェントの『ループ』はどこで止めるべきか、VibeCodingのコードレビューを誰が担うのかもあわせてご覧ください。

参考リンク

本記事の執筆にあたり以下を参照しました。

ソフトバンクの「1人100エージェント」を支える独自AIゲートウェイ「Cloud Proxy」の正体 - @IT

git worktree × claude code で並列開発を実践する - RAKSUL TechBlog

コードレビュー指摘300件を3ヶ月分類したら効いていたのは2種類だけだった - Zenn