AI開発の並列化は本当に速いのか — 人間の判断コストを考える

AIエージェントを複数同時に動かせば、生成や調査にかかる時間を短縮できます。ただし、人間は成果物を確認し、設計の妥当性や受入れの可否を判断する必要があります。その判断に時間がかかれば、開発全体の進み方も制約されるはずです。

この記事で考えるのは、AIの並列実行と人間の判断をどう組み合わせるかです。完了時間に加え、タスクを切り替えたときの理解の浅さや、チェックミスによる損失も比較します。深い判断が必要な開発で、標準として使いやすい進め方を整理します。

AIを並列に動かしても、人間のリリースゲートは並列にならない

開発の工程は、次の図のように整理できます。

flowchart LR
    A[AIの生成・調査を並列化] --> B[人間の確認・設計・受入れ判断]
    B --> C{深い判断を同時に行うか}
    C -->|行う| D[パターンB：完全直列を基本にする]
    C -->|行わない| E[パターンC：安全な先行作業だけ許可]
    F[独立したタスク] --> G[パターンA：AIを並列実行]

AIは複数の処理を同時に進められます。一方、人間が複数の結果を深く理解し、比較して受け入れるには、一つずつ判断する時間が必要です。

AIを何本並列に動かしても、人間が最後に一つずつ確認するなら、リリース前の確認工程は直列のままです。開発全体の時間を考えるには、人間の判断を待つ工程がどこにあるかを把握する必要があります。

比較する3つのパターン

作業は「タスク1・2・3」、進め方は「パターンA・パターンB・パターンC」と呼び分けます。

今回は、AIの生成・検証に0.2時間、人間の確認に0.4時間かかると仮定します。AIと人間の作業比は1対2です。

パターンA：独立並列

タスク1・2・3の作業をAIに同時に実行させ、最後に人間が順番に確認します。

AI：タスク1生成 ─┐
AI：タスク2生成 ─┼→ 人間：タスク1確認 → タスク2確認 → タスク3確認
AI：タスク3生成 ─┘

タスクが本当に独立していれば、各タスクのAI生成が終わるのを順番に待つ必要がありません。人間が確認するのは3件で、その確認時間は合計する必要があります。

パターンB：完全直列

タスク1生成 → タスク1確認 → タスク2生成 → タスク2確認 → タスク3生成 → タスク3確認

人間が確認する対象は、基本的に一つです。AIの実行中も別の結果を気にする必要がなく、一つの成果物の理解と判断に集中できます。

パターンC：パイプライン

タスク1生成 → タスク1確認中にタスク2生成 → タスク2確認中にタスク3生成

パターンCでは、人間がタスク1を確認している間にAIがタスク2を生成します。タスク2の生成時間をタスク1の確認時間と重ねるのが、パターンCで時間を短縮する仕組みです。ただし、人間がタスク2やタスク3の状態を気にしたり、途中で指示を変更したりすると、タスク1を確認する負担が増えます。

時間だけを比較すると、パターンCはパターンBより速い

この仮定で比較すると、次のようになります。

パターンCには、重なり時間に1.2倍のマルチタスクペナルティーを仮置きしています。パターンBとの差は次の通りです。

1.80時間 − 1.48時間 = 0.32時間

パターンCはパターンBより約19分短い計算です。完了時間だけを比較すれば、パターンBよりパターンCを選びたくなります。

ただし、この比較では、人間のチェック品質が変わらないと仮定しています。パターンCではAIの生成時間を重ねる一方、人間が確認中に別のタスクを気にすると、認知負荷が増えます。

AIの作業時間が人間の確認時間より長い場合

ここまでは、AIの作業時間0.2時間、人間の確認時間0.4時間という、AI：人間が1：2のケースでした。逆に、AIの作業時間が長く、人間の確認時間が短いケースも考えられます。

ここでは、1タスクあたりの合計時間をそろえたまま、AI：人間を2：1にします。

この場合の結果は次の通りです。

パターンCでは、人間の確認中に次のAI生成を始めます。AIの生成には0.4時間、人間の確認には0.2時間かかる設定です。確認が終わってもAIは生成を続けているため、各区間で0.2時間待つ必要があります。

タスク1生成       0.4h
タスク1確認       0.2h ─────┐
タスク2生成       0.4h      ├ 0.2hは重なる、0.2hは待ち時間になる
                       ┘
タスク2確認       0.2h ─────┐
タスク3生成       0.4h      ├ 0.2hは重なる、0.2hは待ち時間になる
                       ┘
タスク3確認       0.2h

AI生成時間をg、人間の確認時間をh、タスク数をnとします。重なり部分のペナルティー係数をkとした場合、パターンCの完了時間は次の通りです。

T_C = g + n × h
    + (n − 1) × max(g − h, 0)
    + (n − 1) × min(g, h) × (k − 1)

g ≤ hなら、AI生成は人間の確認時間に収まるため、待ち時間は発生しません。先ほどの1：2のケースはこの条件です。

一方、g > hなら、確認が終わってもAI生成が終わっていないため、g − hが待ち時間になります。AIの作業時間が長いほど、パターンCのパイプラインはこの待ち時間の影響を受けます。

2：1のケースでの短縮幅も、パターンBと比べて0.32時間です。一方、パターンAは1.00時間で終わるため、パターンCを選ぶとパターンAより0.48時間長くかかります。

AIの作業時間が人間の確認時間より長い場合も、パターンCを使えばパターンBより短縮できます。ただし、独立したタスクをパターンAのように並列実行できるなら、パターンAの方が速い計算です。パターンCでは、確認が終わってから次の成果物ができるまでの待ち時間が残るためです。

パターンCで人間が同時に扱う3つの仕事

AIの状態を見ながら指示を変更する

人間がAIの状態を監視し、必要に応じて指示を変更する場合、次の閉ループが発生します。

状態確認 → 状況解釈 → 指示決定 → AI状態の変化 → 再確認

状態を十分に確認しないまま指示すると、古い状態を前提にしたり、以前の指示と矛盾したりするおそれがあります。指示を変えた後、その影響を確認し忘れることも、想定すべきミスの一つです。AIの状態を理解したつもりでも、実際には把握できていないかもしれません。状態の監視に注意を向けるほど、本来の確認対象への集中も途切れやすくなります。

AIが裏で処理を進め、人間が介入しなければ、この負荷は小さくできます。状態を見ながら指示を変える場合は、待ち時間を短縮する一方、監視と指示変更にも注意を向けなければなりません。

タスク1を確認しながら、タスク2・3の設計判断を行う

タスク1の確認中にタスク2・3の設計を考えると、タスク1の確認状況と設計意図を覚えたまま、タスク2・3それぞれの目的や制約も考える必要があります。さらに、タスク1の確認結果をタスク2・3へどう反映するかも判断しなければなりません。複数の未完了の設計判断をワーキングメモリに保持するため、画面を二つ開くこと以上の負担がかかります。

複数のAI結果を比較して受入れ判断する

複数の結果を比較する場合、人間は次の処理を行います。

各結果を理解
→ 評価基準を適用
→ 結果同士を比較
→ 差分の意味を理解
→ 共通する欠陥を探す
→ 受入れ判断

結果が複数ある場合、表面的な類似を正しさと取り違えたり、共通する欠陥を見逃したりするおそれもあります。人間は各結果を確認したうえで、評価し、統合し、受入れを決める必要があります。

既存研究から言えること、言えないこと

割込みやタスク切替に関する研究からは、パターンCのリスクを考える材料が得られます。ただし、AI開発のパターンCでチェックミスが何％増えるかを直接示す研究は、今回確認した範囲では見つかりませんでした。

研究から比較的強く言えること

Altmann and Traftonの研究では、割込み後に主作業へ戻るまでの再開遅延が、通常の操作間隔より長くなりました。割込み前に作業状態を示す手掛かりがあると、再開しやすくなります。Task Interruption: Resumption Lag and the Role of Cues

また、割込み時間が長くなると、正しい次の手順を失う「順序エラー」が増える一方、選択した手順の実行エラーは同じようには増えなかったという研究もあります。Altmann et al., 2017

この結果からは、割込みによって中断前の作業位置や未完了の目標、次の手順を思い出しにくくなると考えられます。あらゆる能力が同じように低下する、とまでは言えません。

ソフトウェア開発でも、割込みの影響はタスクの種類やタイミングに依存します。要求工学は、設計意図や制約を保持しながら判断するため、他の開発活動より割込みに脆弱でした。Task Interruptions in Requirements Engineering

コードレビューを含む実験でも、割込みの組み合わせはレビュー時間に影響しました。ただし、レビューの正誤率を直接測定した研究ではありません。Breaking the Flow, ICSE 2024

研究から直接は言えないこと

既存研究だけでは、パターンCでチェックミスが必ず増えるとも、ミス率が5％から8％になるとも言えません。ここで仮置きした1.2倍のペナルティーが常に当てはまる根拠もありません。最適なAgentの数も、これらの研究からは決められません。

Bailey and Konstanの実験では、作業途中に周辺タスクを割り込ませた条件で、境界で提示した条件より完了時間やエラー数が増えました。しかし、その「エラー数が約2倍」という値を、AIによるコードレビューへそのまま移すことはできません。Bailey and Konstan, 2006

既存研究は、品質上のリスクが高まりやすい条件を考える材料として使えます。パターンCの具体的なミス率については、別途検証が必要です。

0.32時間の短縮と、追加ミスの期待損失を比較する

パターンCを採用する条件は、時間だけでなく、追加ミスの損失を含めて次のように考えられます。

0.32時間の短縮
>
マルチタスクによる追加ミスの期待損失

追加ミスを種類ごとに分けると、次の形になります。

0.32h
>
Δp_state  × L_state
+ Δp_design × L_design
+ Δp_accept  × L_accept

• Δp_state：AI状態の監視・指示変更に関する追加ミス率
• Δp_design：設計判断に関する追加ミス率
• Δp_accept：受入れ判断に関する追加ミス率
• L：そのミスが発生した場合の損失

ミスが起きた後の損失は、種類によって異なるはずです。

状態確認のミスなら、再確認だけで済むかもしれません。設計判断のミスなら、後続タスク全体のやり直しになるかもしれません。受入れ判断のミスなら、リリース後に発見され、さらに大きな手戻りになる可能性があります。

比較には、ミスの種類ごとに追加の発生確率と損失を掛け合わせた値を使います。

深い判断が必要なら、パターンBを標準にする

深い判断を含む開発では、パターンBを標準の進め方にするのが無難だと考えています。必ずしも最速の方法ではありません。一つの対象に集中し、前の確認結果を覚えたまま次へ進めるためです。受入れ基準も曖昧になりにくく、ミスの原因や、やり直す範囲を特定しやすくなります。

人間が深い判断を行う工程は直列にし、その判断に必要な準備作業は並列に進めます。AIの実行をすべて一つずつにする必要はありません。

パターンCを使ってよい作業、避けた方がよい作業

パターンCを使うかどうかは、次の条件で判断できます。

パターンCに向いているのは、テスト実行やビルド、ログ収集といった作業です。依存ライブラリの調査、既存コードの検索、参考資料の整理も候補になります。

アーキテクチャ設計、仕様の確定、複数案の比較、リリース可否の判断は、パターンBのように一つずつ進めた方が安全です。

内容を理解しながら進める

AIに作業を先に進めさせ、人間が十分に理解しないまま成果物を受け入れることがあります。その場では進んだように見えても、後で説明や変更、問題の切り分けを行うときに、内容を理解し直す時間が必要です。

ここでは、こうした理解の先送りを「理解負債」と呼びます。先送りした内容を学ぶだけでなく、その内容に関係する問題を調べる作業も後から必要になる、という意味です。

内容を理解しながら進める方法は、短期的には遅く見えるかもしれません。ただ、成果物を再利用でき、次の判断が速くなり、説明や修正にかかる時間が減るなら、長期的な効率は改善すると考えられます。

私自身、Work Hubで約2週間この進め方を試しました。準備や整理に時間を使っている感覚はありましたが、レジュメに載せられる情報が増え、ブログも継続して書けるようになりました。因果関係を証明する実験ではありません。それでも、内容を理解しながら進める間に、こうした成果は得られました。

実務で使う判断ルール

現時点では、次のルールが扱いやすいと考えています。

1. 深い設計判断は、一度に一つだけ扱う
2. AIの生成・調査・テストは、可能なら並列化する
3. 通知はリアルタイムで受けず、まとめて確認する
4. 人間の確認中に、別タスクの設計判断を始めない
5. パターンCは、失敗しても安全な先行作業に限定する
6. 時間だけでなく、理解度・手戻り・受入れミスを記録する
7. 重要な判断は、後から自分の言葉で説明できる状態を受入れ条件にする

AIの実行は並列化し、人間の判断は直列化する

AI開発では、判断に必要な準備作業を並列化し、人間の深い判断は一つずつ進める方法を勧めます。

独立したタスクなら、パターンAのようにAIを並列実行する。深い設計判断や受入れ判断があるなら、パターンBのように人間の判断を直列化する。パターンCは、人間の注意を奪わず、失敗しても安全にやり直せる作業だけに使う。

開発の速さには、AIの生成時間に加え、人間が内容を理解して判断する時間も影響します。どの作業を同時に進め、どの判断を一つずつ行うかを決める必要があります。