AIエージェントの並列実行｜大量処理が割に合う条件

「AIに任せれば速くなると聞くけれど、台数を増やせば増やすほど効くのだろうか」——エージェントを並列で走らせようとするとき、多くの人がこの疑問に突き当たります。

結論から言うと、並列化が劇的に効く仕事と、台数を増やしてもほとんど変わらない仕事があります。境目は「その作業が独立に分割できるか」「一回きりか、反復か」の2点で見分けられます。

株式会社Fyveは、AI業務効率化の受託と、自社の定型業務を常時起動のマシンで無人化する運用を続けています。この記事では、州政府が4.66億行のコードを20時間で走査した実例を入り口に、私が実際に「どこを並列化し、どこを直列のまま人が見ているか」までを開きます。

州政府が示した「並列化の極端な実例」

まず、規模の桁が変わると何が起きるのかを示す事例から入ります。カナダ・アルバータ州政府は、約50体のAIエージェントを並列で走らせ、州の全システムのコードをスキャンしました。

Anthropicの発表（2026年7月6日公開のホワイトペーパー群「The Velocity White Papers」および同社の事例記事）によると、対象はおよそ4.66億行のコードで、走査に要した時間は約20時間だったとされています。同社は、人が同じ作業を担った場合の目安を約6.5人年と見積もっています。

対象となったのは、27の省庁で使われるシステム群です。報道によれば、そこには約1,280のアプリケーションと約3,400のコードリポジトリが含まれ、社会福祉・公共安全・山火事対応といった行政サービスを支えていました。これだけの規模を人手で一巡するのは、現実には何年もかかります。

スキャンの狙いは、セキュリティ上の弱点・インフラの脆弱性・そしてドキュメントの欠落の洗い出しでした。対象となったシステムの多くは、これまで包括的な見直しを受けたことがなく、技術的負債と説明資料の不足が積み上がっていた、とされています。つまり「そもそも何を持っているのか、全体像を誰も把握しきれていない」状態を、AIエージェントの並列走査で一気に可視化したわけです。

ここで注目したいのは「セキュリティ監査ができた」という結果そのものよりも、1回の網羅走査という仕事が、台数の並列化と極めて相性が良かったという構造のほうです。6.5人年が20時間になるのは、作業を独立した細かい単位に割って、同時に投げられたからです。

なぜ「棚卸し・監査」は並列化が効くのか

大量処理をエージェントに任せる話をするとき、私はいつも仕事を2種類に分けて考えます。ひとつは「広く浅く、一回きり」の仕事。もうひとつは「狭く深く、反復する」仕事です。

前者は、棚卸し・全件チェック・一括リネーム・大量ファイルの分類・監査のような作業が当てはまります。これらは、対象を1000個に割っても、それぞれの処理が互いに影響しません。だから台数を増やした分だけ、素直に時間が縮みます。

アルバータ州の例が極端に効いたのも、コードベースを repository 単位・ファイル単位に切り分けられたからです。1体が担当を終えるのを待たずに、別の1体が別の担当を進められる——この「待ちが発生しない」性質が、並列化の効き目を決めます。

並列が効く仕事に共通する3つの性質

• 独立に分割できる：作業Aの結果を、作業Bが待つ必要がない
• 一回きりで良い：同じ対象を何度も練り直す前提でない（棚卸し・走査・分類）
• 出力を後でまとめて検品できる：各エージェントは候補を出すだけで、採否は最後に人（または集約役）が判断する

この3つが揃っていれば、台数を増やす投資はほぼそのまま時間短縮に返ってきます。

読者特典・無料ダウンロードClaude Codeを「素のまま」使うな無料でダウンロード →↓

逆に、並列化が効かない仕事

一方で、台数を増やしてもほとんど効かない——むしろ管理の手間だけ増える仕事があります。反復的な作り込みや、前の判断が次の判断に効いてくる開発です。

たとえば1つの機能を設計しながら実装する作業は、「Aを決めたからBはこうする」という依存が連鎖します。ここに10体を投げても、9体は前の1体の結論を待つだけで、実質は直列になります。並べたつもりが渋滞するのです。

「たくさん走らせれば速い」という感覚は、この依存の深い作業では裏切られます。量を増やすほど良いわけではない、という論点は別記事で掘り下げています。

Claude CodeAIエージェントは量より質｜大量運用の失敗と本質

私の判断としては、「一回きりの網羅」は台数で殴り、「反復の作り込み」は1本の文脈で丁寧に進める——この使い分けを最初に決めてから並列化に入ります。

私が実際に並列化しているところ／していないところ

ここからは、私が自社運用で実際にどう線を引いているかを開きます。私は常時起動しているMac miniで、いくつかの定型作業を独立したジョブとして時間をずらして走らせています。互いに関係のない仕事なので、これは並列化の恩恵をそのまま受けられる部類です。

調べ物も同じ考え方で動かします。ひとつのテーマを複数の観点に割って、それぞれをサブエージェントに同時に投げ、私は結果だけを受け取る。「広く探す」フェーズは、1本で順番に調べるより、割って同時に走らせたほうが圧倒的に速く終わります。

司令塔役に仕事を分解させ、実行役へ並列で配り、最後にひとつへまとめ直す——このファンアウトとパイプラインの型は、独立した作業を数で捌くときの基本形です。たとえば「10個のページをそれぞれ点検する」なら、10体に1ページずつ割り当てて同時に走らせ、結果の一覧だけを受け取ります。1体が全ページを順番に見るより、待ち時間の総和が消える分だけ速くなります。

効かせる鍵は「分割の粒度」

並列化がうまくいくかどうかは、作業をどの単位で割るかでほぼ決まります。粒度が大きすぎると、1体あたりの負荷が偏って結局その1体が全体の足を引っ張ります。逆に細かく割りすぎると、分配と集約の管理コストが処理そのものより重くなります。

私は「1単位が数分で終わり、互いに参照しない」あたりを目安に割っています。ファイル単位・記事単位・案件単位のように、もともと独立している境界があれば、そこで切るのがいちばん素直です。アルバータ州がリポジトリ単位で切れたのも、この境界が最初から存在していたからです。

並列で走らせるほど「壊さない設計」が要る

ただし、複数のエージェントが同じ場所に同時に書き込むと、成果が互いを上書きして壊れます。ここは並列化の落とし穴で、対策を先に用意してから台数を増やす必要があります。作業を別々の場所に隔離してから走らせる考え方は、こちらで詳しく解説しています。

Claude CodeClaude Codeのworktree隔離｜並列作業を壊さない

もうひとつ、無人で回すなら「際限なく増やさない天井」も要ります。委任の数に上限を置いておかないと、思わぬ暴走で台数だけが膨らむことがあるためです。

Claude CodeClaude Codeのサブエージェント上限｜暴走委任を防ぐ

逆に、私が絶対に並列化しないのは方針を決める判断と、外へ出す最終確認です。ここは1本の文脈で私自身が見ます。並列で速くしたいのは「手数」であって、「決める」ことではないからです。

並列化の前に決める3つの判断軸

実際に「この仕事を並列化すべきか」を迷ったときは、次の3つを順に確認すると判断がぶれません。

3つとも左側に寄る仕事は、台数を増やす投資がそのまま時間短縮に返ってきます。ひとつでも右側に寄るなら、並列化より先に「分割できる形に作業を組み替えられないか」を考えるほうが効きます。

台数を増やすほど、本番は「検品」になる

最後に、並列化でいちばん見落とされがちな点に触れます。エージェントを50体走らせれば、成果も50倍の速さで積み上がります。ところが、その中に混じる誤検出や的外れも同じ速さで積み上がるということです。

アルバータ州の事例でも、エージェントが出したのはあくまで候補であり、どれを本当に直すかは人がトリアージ（優先順位づけ）しています。並列化は「探す」を速くしますが、「決める」までは肩代わりしません。

だからこそ、台数を増やす前に検品の受け皿を用意しておくことが要になります。私の場合は、成果を必ず一度ためてから見る・元に戻せる形で出させる・何をどう判断したかのログを残す、という3つを並列化の前提条件にしています。数で速くした分、最後に人が見る場所を1本に絞るわけです。

小さく始めるなら、まず「棚卸し」から

州政府ほどの規模でなくても、この考え方はそのまま使えます。中小企業や個人事業でも、「誰も全体を把握していない資産」は必ず持っているからです。長年ためた古いファイル群、担当者しか分からない業務手順、散らばった過去案件の記録——こうした対象は、まさに「一回きりの網羅」に当てはまります。

私が勧める始め方は、いきなり本番の作り込みを任せるのではなく、まず手持ちの資産をAIに一括で棚卸しさせることです。分類・要約・重複の洗い出しといった、独立に割れて検品しやすい仕事から入ると、並列化の効き目と限界を安全に体感できます。そこで「どこまで任せて、どこは自分で見るか」の感覚が掴めれば、より重い作業へ広げる判断がしやすくなります。

並列化は、規模の壁を越えるための強力な手段です。ただし効くのは「独立に分割できる、一回きりの、後でまとめて検品できる」仕事に限られます。この見極めさえ外さなければ、1人や小さなチームでも、かつては手が届かなかった規模の処理を現実的な時間で捌けるようになります。数で速くするほど、最後に人が見る一点を大切にする——これが、私が並列化と付き合ううえで守っている原則です。