複数AIを並列で動かすと、
最後に詰まるのは人間のレビューである
Codexへサイト改修を依頼しながら、別のAIにアプリを作らせ、裏では動画処理を走らせる。人間はその間に次の要件を考える。
以前なら一人で順番に処理するしかなかった作業を、複数のAI作業ラインへ分けられるようになった。個人でも、小さな制作会社のような動きができる。
しかし、並列数を増やせば無限に速くなるわけではない。
最後に詰まるのは、
AIではなく人間である。
個人でも複数の作業ラインを持てる
AIエージェントへの依頼は、常に人間が横で見ている必要がない。
目的、対象範囲、制約、完了条件を渡せば、調査、実装、テスト、修正を数時間続けられる。その間に、人間は別の依頼を準備できる。
ある日は、価格比較サイトの改修、動画のダウンロード、Kindle画像のOCR処理、要約アプリの開発を同時に進めていた。手を動かしているのは一人だが、実行ラインは複数ある。
これは同時に五つの作業をしているというより、複数の作業者へ仕事を割り振る監督者に近い。
並行している感覚が薄い理由
AIへの大きな依頼は、一度渡すと2時間、3時間と進むことがある。
人間側が要件を書く時間は10分程度で、その後は待ち時間になる。確認依頼が来るまで別の作業へ移れるため、本人には忙しく切り替えている感覚があまりない。
ここが、人間同士の並行作業と大きく違う。
進捗確認の会議も、細かな説明も、作業中の質問への即時回答も少ない。非同期で長く動くため、ラインを増やしやすい。
完成物は一斉に人間へ戻ってくる
問題は、複数ラインの成果物が近い時間に戻ってきた時に起きる。
サイトの表示確認、データの整合性、アプリの操作、規約の判断、文章の品質。AIが「完了」と報告しても、採用してよいかは人間が確認しなければならない。
確認中に別のAIから質問が来る。さらに別の成果物が完成する。どの修正が最新か分からなくなる。レビュー待ちが積み上がり、AIは空いているのに全体は進まない。
実行能力を増やした結果、確認能力が新しい制約になる。
ボトルネックは監査能力へ移る
AI導入前の制約は、人間が作業できる時間だった。
AI導入後は、作業そのものより、何を作らせるか、出力が正しいか、どれを採用するか、どこへ統合するかが重くなる。
つまり、人間の役割は作業者から監査者へ移る。
並列数を増やす時に見るべきなのは、PC性能や利用枠だけではない。一日に何件の成果物を、十分な品質で確認できるかである。
チャットではなく状態で管理する
複数のAIを動かすと、会話の記憶だけでは管理できない。
最低限、各タスクを「未着手」「作業中」「確認待ち」「修正中」「完了」に分ける。目的、担当AI、成果物の場所、次の人間判断も一行で残す。
重要なのは、AIが何をしているかより、人間が次に何を確認すべきかを見えるようにすることだ。
確認待ちが増えすぎたら、新しい依頼を止める。仕掛かりを増やすより、完成へ流すことを優先する。
レビューを最後にまとめない
大きな作業を最後まで走らせてから全部確認すると、修正範囲が広がる。
最初に設計、途中で代表画面、最後に全体というように、確認点を小さく分けた方がよい。AIが間違った方向へ長時間進むことも防げる。
ただし、確認回数を増やしすぎると、人間が常時呼び出される。途中確認は、後戻りコストが大きい判断だけに限定する。
非同期で任せる部分と、人間が止める場所を最初に決める。
正本と判断ログを残す
並列作業で最も危険なのは、どれが最新か分からなくなることだ。
成果物の正本を一つに決める。修正前のコピーを増やすのではなく、変更履歴を残せる場所で管理する。AIへ追加依頼する時も、必ず同じ正本を参照させる。
さらに、採用した理由と却下した理由を短く残す。後から同じ提案が出た時、再びゼロから検討せずに済む。
AIの作業速度が上がるほど、ファイル管理と判断記録の価値は高くなる。
並列数は人間から逆算する
技術的に10本動かせるからといって、10本動かす必要はない。
一日に丁寧に確認できるのが三つなら、確認待ちが三つを超えないように依頼する。重要度が高い仕事は並列数を減らし、単純な変換や長時間処理だけを裏で走らせる。
AIの数を最大化するのではなく、人間の判断品質が落ちない範囲で最大化する。
レビュー待ち行列を数値で管理する
複数AIを感覚だけで動かすと、依頼時には余裕があっても、数時間後に成果物が集中する。そこで、各タスクの「実装時間」ではなく「人間が必要な確認時間」を先に見積もる。
| タスク例 | AIの作業時間 | 人間の確認時間 | 同時実行の扱い |
|---|---|---|---|
| 長時間の動画変換 | 2時間 | 5分 | 他作業と並列しやすい |
| 記事の初稿作成 | 40分 | 30〜60分 | 同時に増やしすぎない |
| UI全面改修 | 2〜4時間 | 60〜120分 | 一件ずつレビュー枠を確保 |
| データ移行 | 1〜3時間 | 30〜90分 | 差分と復旧確認が必須 |
| 規約に関わる仕様変更 | 1時間 | 60分以上 | 人間判断を優先し並列数を下げる |
AIの作業時間が長くても、人間確認が5分なら並列しやすい。逆に、AIが20分で作れても、一時間の読解が必要な原稿を十本同時に作らせれば、人間側に十時間分の負債が生まれる。
並列数は、AIが何本動けるかではなく、今日と明日に確保できるレビュー時間から決める。
個人AIスタジオの運用ボード
最低限の管理表は、次の項目だけでよい。
| 項目 | 内容 |
|---|---|
| 目的 | この作業で何を改善するか |
| 正本 | AIが触る唯一の対象ファイル・ブランチ |
| 状態 | 未着手／AI作業中／人間確認待ち／修正中／完了 |
| 完了条件 | 何を確認したら終わりか |
| 人間レビュー時間 | 何分を予定するか |
| 危険度 | 壊れても戻せるか、本番・規約へ影響するか |
| 次の判断 | 人間が決めなければ進まないこと |
運用ルールとして、確認待ちは三件までのように上限を置く。三件たまったら、新しいAI作業を開始せず、レビューを消化する。本番データ、決済、公開、規約に触れる仕事は、通常タスクと同じ列へ置かず、別の高危険度レーンで扱う。
また、完了報告を受けた瞬間にレビューできない場合、AIへ追加修正を思いつきで投げない。正本と要件が揺れ、どの状態を確認しているか分からなくなるからである。一度レビュー項目をまとめてから、次の修正依頼を出す。
並列運用で起きる事故と予防策
同じファイルを複数AIが変更する
一方の修正がもう一方を上書きする。対象ファイルかブランチを分け、統合担当を一つにする。同じ正本を同時編集させない。
完了条件がタスクごとに違う
AIは「コードを書いた」を完了とし、人間は「画面が正しく動いた」を完了と考える。依頼時に、テスト、表示確認、データ整合性、成果物の場所まで明示する。
確認依頼へ即答し続けて集中が切れる
すべての質問をリアルタイムで受けると、監督者が最も忙しくなる。後戻りが大きい質問だけ即時、軽微なものは仮定を置いて継続、とルールを決める。
完成物の場所が分からない
チャット内の説明だけで終わらせず、成果物の絶対的な正本と変更一覧を返させる。レビュー後の採用・却下も状態へ反映する。
レビュー品質が落ちる
夜間に大量の成果物を確認すると、見逃しが増える。危険度の高いレビューは翌朝へ回し、単純な外観確認とデータ・規約確認を分ける。
AIを並列化すること自体は難しくない。難しいのは、複数の成果物を同じ品質基準で受け止め、正しい一つへ統合することだ。運用設計がなければ、並列化は生産性ではなく仕掛かり在庫を増やす。
レビューの深さを、成果物ごとに変える
すべてを同じ厳しさで確認すると、人間の時間が足りなくなる。一時的な調査メモは出典と結論だけ、内部ツールは対象範囲と戻し方、公開記事は事実、表現、重複、リンク、画像まで見る。外部へ与える影響が大きい成果物ほど深く確認する。
レビュー項目を先に決めると、AIにも必要な証拠を添えさせられる。コードなら変更ファイルとテスト結果、記事なら参照チャットと事実の根拠、画像なら入れる文字と寸法を返させる。完成後に人間が情報を探し直す時間を減らす。
完成通知を一か所へ集める
複数チャットを開いたままにすると、どこで何が終わったかを記憶へ頼ることになる。タスク名、成果物の場所、状態、次に人間が行う確認を一つの一覧へ集める。チャットは作業場所であり、進捗の正本にはしない。
完了の定義も揃える。「コードを書いた」は実装完了、「テストが通った」は検証完了、「人間が結果を見た」は確認完了であり、同じ完了ではない。状態を分ければ、未確認の成果物を公開済みと誤認しにくい。
人間の集中力をスケジュールへ入れる
難しいレビューを会議の隙間や夜へ積むと、見落としが増える。判断が必要な記事、設計、公開変更は、集中できる時間帯へまとめる。単純な形式確認は自動化し、人間は主張、意味、安全性へ時間を使う。
並列数はAIの上限ではなく、翌日までに人間が確認できる数で決める。レビュー待ちが上限を超えたら、新しい生成を止め、既存の確認と統合を優先する。この運用ができて初めて、並列化が速度ではなく成果へつながる。
毎週一度、待ち時間が長かった工程を確認する。AI作業が遅いのか、必要な情報が不足したのか、人間の判断が集中したのかで対策は変わる。レビューだけが詰まるなら生成数を増やさず、検査の自動化と依頼時の証拠整理を先に改善する。