一つの報告へまとめる

担当を分けた調査で、結論を出す人の仕事は減るか

複数のAI担当に省電力なモデルを調べてもらう。 一人は学習時の消費電力を集め、もう一人は推論時の消費電力を集める。 どちらも出典を添えて返したのに、そのまま並べると比較は成立しない。 これは本稿の設計上の想定例である。 収集が速くなっても、測定範囲の違いを見抜く仕事が利用者に残れば、報告の完成は近付かない。

Semantic Kernelの5月27日の発表は、複数エージェントの進め方を、順番、並列、対話、担当の引き継ぎ、状況に応じた調整として実装する枠組みを示した。 Azure AI Foundry Agent Serviceの一般提供やResponses APIの更新も、道具をつなぎ、長い処理を追う部品を増やしている。 これらを使うなら、人数に先立って仕事の依存関係を決める必要がある。

本稿では、独立した収集を分け、比較条件を保って引き継ぎ、統合時に足りない根拠を取り直せる構成を提案する。 複数担当の価値は、出力の本数では測れない。 人が一つの判断へまとめるまでの調査、照合、修正の負担が減るかで評価したい。

順番と並列

前の出力が必要な仕事は、同時に始めても進まない

Semantic Kernelは、順番に処理する例として、文書の要約、翻訳、品質確認を示す。 後の担当は前の担当の出力を受け取る。 一方、並列処理では、複数担当が同じ入力を独立して扱い、結果を集める。 違う案や観点を得たいときの構成だ。 いずれも説明と実装パターンであり、同じ文書で品質や時間を比較した実験結果ではない。

冒頭の報告なら、対象にするモデルと測定範囲を決めた後、別々の一次資料を並列に探せる。 比較の計算は、必要な数字と条件がそろうまで待つ。 文章の確認は、結論と根拠の対応ができてから行う。 担当を同時に起動するだけでは、まだ存在しない比較結果を執筆者へ渡すことはできない。

さらに、順番に渡せば十分とも限らない。 要約が測定条件を落とした場合、その要約を翻訳し、文法を確認しても、失われた条件は戻らない。 原文を読めるようにして、各担当が必要とする情報を出力に残す必要がある。 処理の順番と、受け渡す情報は一緒に決めたい。

途中で経路が変わる

足りない根拠が見つかったら、次へ進む代わりに収集へ戻す

同じ発表のMagentic方式は、機械学習モデルのエネルギー効率とCO₂排出量を比較する報告を例にする。 管理役が調査担当へ資料収集を頼み、計算を行う担当へ分析を渡し、必要に応じて調査と計算を繰り返す構成だ。 完成までの経路が最初から固定できない仕事を説明している。 この例も、実際の省電力比較の正しさを測定した結果ではない。

基になるMagentic-Oneの論文では、全体の仕事を扱う台帳と、進捗を扱う台帳を使う。 前者は既知の事実、推測、必要な情報、計画を整理し、後者は担当を選び、進んでいるかを確認する。 停滞すれば計画を見直す。 単に担当名を並べる構成との違いは、途中で何が分かったかによって次の行為を変えられる点にある。

ただし、管理役も判断を誤り得る。 資料が不足したまま「完成」と決めたり、同じ検索を繰り返したりすれば、人数を増やした分だけ確認の負担が増える。 調査へ戻す条件、試行の上限、根拠が見つからない場合の報告を定める必要がある。 対象資料と処理が固定される仕事なら、順番を決めた処理のほうが検査しやすいこともある。

道具と実行の管理

参照する担当と変更する担当を、道具の接続まで分けて考える

Microsoftの5月19日のDeveloper Essentialsは、Foundry Agent Serviceの一般提供とともに、参照用の道具と操作用の道具を説明する。 SharePointやAzure AI Searchなどから知識を得る接続と、Logic AppsやAzure Functionsなどを使って処理を実行する接続が示される。 実行の追跡、評価、監視も開発と運用の対象になる。

報告を作る想定例では、調査担当は資料を読むだけで足りる。 下書きを作る担当には作業用の文書への書き込みが必要かもしれない。 公開先を更新する権限は、別の処理として持たせられる。 この分け方は本稿の設計案であり、Foundryが役割名から自動的に権限を決めるという説明ではない。

道具が増えると、結果の間違いも異なる場所で起こる。 閲覧できない文書を見つけたこと、検索が空だったこと、計算が失敗したことを、同じ「資料なし」として渡すと、執筆者は原因を判断できない。 追跡記録を使って、どの入力と道具で止まったかを調べられるようにする。 記録があることと、主張を検証できることは違うため、本文に使った根拠も残す。

一般提供という表現の範囲にも注意したい。 Semantic Kernelの4月の発表は中核Agent APIの一般提供を説明した。 5月に紹介された協調パターンをすべて同じ提供状態と推定することはできない。 利用する機能と実装版を確かめた上で、一件の仕事を通して検証する必要がある。

長い処理を追う

応答が完了したことと、報告を使えることを分ける

Responses APIの5月21日の更新は、外部のMCPサーバーへの接続、Code Interpreter、非同期で長い処理を始めるbackground modeを加えた。 アプリケーションは応答オブジェクトを照会して完了を確かめたり、イベントを追って処理状況に追い付いたりできる。 調査と計算を伴う仕事を待つための部品になる。

この仕組みは、処理の進み方を扱う。 必要な資料が集まったか、計算の前提が合っているかは、別の確認である。 たとえば計算が正常終了しても、異なる単位の値をそのまま比べれば結論は使えない。 通信の待ち時間を扱う機能と、業務の完成を判定する条件を混同しない。

利用者には、調査中、計算中、確認待ちといった仕事の状態を、実際の処理に結び付けて示したい。 ここでの表示は本稿の提案だ。 内部の呼び出しが終わっただけで「報告完成」と知らせず、不足している資料や人の判断を示せば、待つべきか、条件を変えるべきかを選べる。

報告作成の想定例

数字だけを渡すと、統合役は比較条件を調べ直すことになる

省電力の比較報告を、ここから具体的な設計例として追う。 調査担当は、一次資料のURL、公開日、該当箇所に加え、モデル、機器、処理の範囲、測定単位を返す。 確認できなかった条件も書く。 学習と推論の値が混ざっていれば、計算へ進む前に比較対象をそろえるか、別の比較として分ける。

計算担当は、使った値と変換の方法を返す。 執筆担当は、測定された事実と、条件付きで導いた解釈を分けて結論を作る。 確認担当は、その結論が元の条件を超えていないかを読む。 大きい数字を見つけた担当の意見を多数決で採用しても、測定範囲の違いは解消しない。

確認担当を増やすだけでも、品質は保証されない。 全員が条件の抜けた同じ要約を読むなら、その抜けを共有してしまう。 確認担当には、下書きに加えて原典の該当箇所を渡し、測定範囲を照合できるようにする。 収集担当の自信の強さを、根拠の強さとして引き継がない。 条件が合わない部分を結論から外せることも、確認の役割に含めたい。

根拠が不足すれば、確認担当から収集へ戻す。 資料が見つからないなら、比較不能な部分を残して報告する。 こうすれば、すべての担当の応答がそろったことを、結論の完成と取り違えずに済む。 利用者が確認するのは、どの数字を信じるかだけでなく、何を比べられて、何を比べられないかになる。

この分割で利益が出るのは、独立した探索量が十分にある場合だ。 一つの短い資料で済む報告なら、担当間の受け渡しと統合が余分な仕事になり得る。 役割は人の作業を整理するための設計であり、必ず別々のエージェントとして動かす必要はない。

採用の判断

完成までの負担を比べてから、分ける工程を増やす

Building effective agentsは、問題に合う単純な構成から始めるよう勧める。 同じ報告課題で、一担当の構成と分割した構成を比べるのが出発点になる。 収集の時間に加え、引き継ぎ、統合、確認、やり直しの時間とモデル利用量を記録する。

比べるときは、対象資料、使える道具、モデル、完了条件をそろえる。 分割した側だけに多くの調査時間や別のモデルを与えたなら、その差も結果に含まれる。 担当を増やしたこと自体の効果とは断定しない。 収集は速くなったが統合で時間を失った、といった工程ごとの違いを残すと、次に分ける仕事を選びやすい。

評価では、出典の対応、条件の抜け、根拠のない結論を確認する。 資料が不足する場合や、担当の結果が食い違う場合も含める。 短時間で下書きが出ても、人が原典を探し直す必要が増えれば、改善とは言いにくい。 反対に、並列探索で待ち時間が減り、条件を保ったまま統合できる工程は、分ける理由を持つ。

独立性

前工程の出力なしで進められる収集を見つけ、並列化する。

受け渡す根拠

数字や要約に、比較条件、出典、未解決点を添える。

戻す条件

統合で不足を見つけたら、再調査か、比較できないという報告へ進む。

5月の発表によって、仕事の進め方をコードとサービスの設定へ置く選択が増えた。 その選択を生かすには、担当の人数から、成果物が完成するまでの依存関係へ目を移す必要がある。 利用者が複数の答えを整理し直す負担まで減らせたとき、分業は仕事の改善になる。