複数AIの調査を並列化する——出力形式の取り決めと根拠の照合で比較資料へ統合する

三つの回答が一つの資料にならない

三社の取引先を比較する資料を、三つのAIへ同時に依頼する場面を考えます。全員に「最適な取引先を調べて」と伝えると、同じ会社紹介を調べ、異なる基準で順位を付け、似た文章を返すかもしれません。処理は並列でも、最後に人が全回答を読み直して基準を揃えるなら、時間を使う場所が移っただけです。人数を増やす前に、各社の調査と全体の比較をどの担当へ渡すかを決める必要があります。

まず資料で答える問いを決めます。今回は「必要な仕様、納期、保守条件を満たす候補を並べ、選択に必要な未確認事項を示す」とします。価格だけで最適を決める仕事にはしません。調査、比較表、推奨の判断を分けられるかを考え、同時に始められる部分を探します。作業の粒度が決まれば、三つのAIを使うべきか、二つで十分か、一つで順番に進めるべきかも判断できます。

分担の単位は文章の章だけとは限りません。会社ごとに資料収集を分ける方法、条件ごとに調べる方法、調査と検証を分ける方法があります。会社ごとの分担は独立しやすい一方、用語の対応を最後に揃える必要があります。条件ごとの分担は比較しやすい一方、各社の資料を複数担当が重複して読むかもしれません。今回の例では会社ごとの調査を並列にし、比較と統合を別の担当へ置く設計を選びます。

分担前に共通の質問を固定する

各調査担当へ、必要な仕様、納期の定義、価格に含む範囲、保守時間帯、参照可能な資料を共通に渡します。納期が出荷日か設置完了日かを決めずに調査すると、各社の回答が比較できません。取得できない情報は未確認とし、似た条件から推測して埋めないことも伝えます。統合する担当の都合で後から定義を変えると、調査をやり直す範囲が広がるため、比較の前提を先に文章にします。

担当ごとに必要な資料は同じではありません。各社の資料はその会社の担当へ渡し、共通の要件だけ全員へ渡します。資料の出所と版を明示すれば、古い見積を混ぜたときに発見できます。前の担当が書いた推奨案を調査担当へ先に渡すことは、結果をその案に寄せる可能性があります。独立した情報収集が目的なら、期待する結論を入れず、必要な一次資料と比較基準を渡す方が適切です。

前提には判断権限も含めます。調査担当は条件を抽出し、未確認を示せますが、取引先へ連絡したり発注したりはしません。比較担当は不足を整理できますが、契約を確定する担当ではありません。情報収集の並列化を外部操作の権限まで広げないようにします。各担当が何を提出し、何を行わないかは、成果を受け取る人が判断できる形で明記します。役割の境界は人数より重要です。

受け取る形式を先に合わせる

各調査の出力は、会社名、条件、根拠、対象時点、未確認事項に揃えます。長い説明文を自由に返してもらう方法は読みやすい場合もありますが、比較時に必要な項目が抜けやすくなります。一方、項目を厳しく揃えすぎると独自の条件を捨てるかもしれません。基本項目に加えて「他社と直接比べられない条件」の欄を用意すれば、整った表と重要な例外を両立できます。

出力の形式が同じでも、内容が比較可能とは限りません。「保守あり」とだけ書かれた欄と「平日の日中に対応」の欄では情報の粒度が違います。比較担当は両方をありとして丸めず、条件が不足した会社を未確認とします。根拠には会社の説明文や資料の該当箇所を結び付けます。AIが自信を持って書いたことを採用理由にせず、資料でどこまで確認できるかを統合の材料にします。

担当の完了には、文章を出したことだけでなく必要な項目の扱いが決まったことを含めます。見つからない項目を未確認として残すことも完了になり得ます。全欄を埋めることを求めると、資料にない条件を補ってしまう圧力になります。返答の早さと、根拠の充足は別に評価します。未確認事項が多い担当の成果でも、欠落を正確に示していれば、次の確認を進めるための価値があります。

同時に始める範囲を限定する

三社の資料収集は同時に進められますが、比較の結論は調査結果がそろう前に確定できません。早く終わった会社だけで推奨を決めると、残りの結果を添え物として扱うかもしれません。統合前に、必要な担当の完了を確認する条件を設けます。期限に一社が間に合わない場合は、二社での暫定比較として範囲を示し、三社比較と表題を付けないようにします。

並列化する部分が共有する資源にも注意します。同じ資料を全員が書き換える構成では、最後の保存が他の成果を消す可能性があります。各担当は自分の結果を別に保存し、統合担当が受け取って一つの資料へ反映します。担当の出力と統合後の出力を分ければ、統合の際に何が採用され、何が保留されたかを追えます。並列化のために同時書込みの複雑さを増やす必要はありません。

作業が長引いたときは、途中の情報を進捗として受け取れます。ただし未確認の途中結果を最終結果へ混ぜないことが必要です。担当が「価格は確認、納期は調査中」と報告したなら、比較表には価格だけを確定情報として取り込みます。途中結果を使って次の作業を始める場合は、後から修正される可能性を示します。全件の完了を待つ方法と、確定した部分だけ先へ進める方法を用途で選びます。

統合担当は多数決をしない

比較結果が食い違うとき、二つのAIが同じ条件を肯定し、一つが否定したから肯定を採用する、という方法は適切とは限りません。全員が同じ古い資料を見ている場合もあります。統合担当は回答の数より、資料の版、条件の定義、対象範囲を確認します。結論が違う理由を分け、資料の矛盾なら確認事項として残します。結論を一つへ揃えること自体を成功条件にしません。

取引先の順位を決める場合は、事前に定めた比較基準へ戻ります。要件を満たさない会社が価格だけで一位になるなら、基準の適用が違います。重要度を変更する必要が出た場合は、その判断を記録して比較をやり直します。調査結果を見て望む候補が勝つように基準を変えることは避けます。推奨には、選んだ理由だけでなく不足した情報と条件が変わった際の代案も添えます。

統合の出力には、採用した条件、保留した条件、追加確認を分けます。全ての文章を足し合わせる方法は、矛盾や重複を読む側へ押し付けます。比較表を短く整える際も、例外を落とさないようにします。例えば一社だけ初期設定費が別なら、総額の欄へ含めるか別に示すかを決めます。分担の価値は回答が増えることではなく、最後の資料で判断材料が揃うことです。

速さと独立性を別に確かめる

検証では、各担当が同じ定義を使ったか、必要な根拠を残したか、統合で例外が消えていないかを確認します。処理時間の比較だけでは品質は分かりません。一人で順番に処理した結果と、並列に処理した結果を同じ条件で比べる方法が考えられます。設計段階では実測の短縮率はまだ分かりません。速くなったと断定する前に、統合や修正へ使った時間も含めて測る必要があります。

独立した確認が必要な場面では、作者の推奨結果を確認者へ先に渡さないようにします。共通の要件と資料、比較表を渡し、基準に照らして検査してもらいます。別のAIを使うだけで独立性が保証されるわけではありません。会話の履歴や共通指示が同じなら、同じ思い込みを引き継ぐことがあります。誰が何を見たか、どの情報を分けたかを記録することが重要です。

見せる会社の順番を変えて判断が大きく変わらないかを確かめる方法もあります。資料の順序は基準に関係しないためです。初回に使う条件を先に決め、結果を見てから都合のよい試験だけ採用しないようにします。判定は肯定、否定、保留を許し、全員が同意するまでやり直すことを目標にしません。食い違いが見つかることは、追加の確認が必要な条件を発見した結果にもなります。

並列の成果を検証してから受け取る

複数担当を使う場合は、計画、実行、検証、記録を接続し、人の判断が必要な箇所を画面へ示す設計が考えられます。AI実行基盤のヤクモ提供の実装にも、この分担があります。取引先比較では、担当が回答した段階と、比較表へ採用できる段階を区別します。納期の根拠がないなら、文章が完成してもその項目は未確認です。共通の要件と提出項目を受付で照合し、基準に足りない成果を追加調査へ戻す経路を置きます。人数より、結果を受け取る条件をそろえることが重要です。

LangGraphで工程を制御し、SQLiteへ状態を保存する構成では、実作業、成果物の照合、別担当レビュー、差戻し、受入を分けられます。作業を行う担当の提出を待つ工程があり、AIが完全に無人で全工程を進める前提にはしません。取引先比較では調査の完了を待ち、出力の形式と根拠を検証してから比較担当へ渡します。保存しただけの回答を受入済みへ進めず、何が確認されていないかを明示します。途中で担当が止まった場合も、調査済みの項目と残る項目を分けて引き継げます。

並列実行の仕組みと受入の管理を組み合わせる場合も、まず一つの業務で受渡しを試します。利用可能な資料、外部操作の権限、保存範囲を定め、調査の出力が比較担当に必要な項目を満たすかを確かめます。二社の納期は確定、一社は未確認という結果なら、比較は暫定として返せる必要があります。基盤の名前がそろっていても担当の出力がそろわなければ統合は難しくなります。計画した接続と実際に通った接続を区別し、この段階では、三社比較の方法を検査案として示しています。

AI実行基盤のヤクモ提供の実装にはTypeScript、Python、React、PostgreSQL、Supabaseなどと、複数エージェントを並列実行し作業ごとに別の作業場所（作業ツリー）で分離する構成があります。取引先比較でも、担当ごとの成果を分けて受け取る方法が考えられます。会社別の根拠を独立に保存し、統合担当が採用した値と保留した条件を結び付けます。共有ファイルを全員が書き換える方法とは違うため、衝突を避けながら元の調査へ戻れます。所要時間や品質改善は、統合と修正を含めた別の測定で評価します。

人数を増やす前に境界を試す

最初は二つの独立した調査と一つの統合で、受け取る項目、根拠、未確認の表記を試します。担当が途中で止まった場合や、一つだけ旧い資料を使った場合も確認します。統合担当が不足を発見できれば、人数を増やしても同じ受渡しを使いやすくなります。全体の完了は全員が返答したことではなく、必要な判断材料が揃い、残った不明点が具体的になったこととして定めます。

この方法は市場調査、資料制作、実装作業の分担にも応用できます。一方、一つの資料を細かく分割しすぎると、前提の共有と統合の時間が増えます。分担による待ち時間の短縮より、互いの理解を揃える負担が大きいなら、担当を減らす方が合理的です。依存関係が強い仕事では順番に進める部分が残ります。並列化を目的にせず、独立して進められる作業を探すことが重要です。

運用の記録には、分担した単位、共通の基準、採用した成果、統合で直した点を残します。次回の仕事でどこが重複したか、どの出力が比較しにくかったかを見直せます。AIの数を毎回増やすより、受渡しの曖昧さを減らす方が効果的な場合もあります。担当を増やす判断を、できることの数ではなく、独立した仕事の数と統合の難しさに基づいて行うと、並列化の限界も説明できます。