一つの仕事を複数の処理へ分割すると、それぞれの役割と責任範囲を明確にできる。しかし、役割が異なっていても、判断に必要な情報まで独立しているとは限らない。注文情報を調べる処理、配送状況を確認する処理、返品の可否を判定する処理は、それぞれ異なる機能を担当する。それでも、返品という一つの仕事を完了するには、同じ注文番号を使って取得した情報を組み合わせる必要がある。これらを独立した推論主体へ割り当てた場合、各処理が情報を再取得するか、先行する処理が必要な情報を後続の処理へ引き渡すことになる。
処理を分割することで得られる利益もある。大量の文書を複数の処理で同時に検索できれば、逐次検索より短い時間で結果を収集できる可能性がある。また、先行する判断とは独立した情報や手順を使って検証すれば、元の判断が依拠した誤った前提を検出できる場合がある。前者は処理の並列性、後者は判断の独立性による利益であり、分割する理由が異なる。同じシステムの中でも、情報を共有した方が合理的な処理と、情報を分離することで利益が得られる処理が共存する。
処理の分割境界は、情報共有による利益と、並列実行・独立検証による利益を、品質と制約条件の下で比較して決定すべきである。情報を共有すれば受け渡しの費用を削減できるが、共有する範囲が広がるほど、個々の処理が本来必要としない情報まで参照する可能性も増える。反対に、情報を分離すれば個々の処理が参照する範囲を限定できるが、後続の判断に必要な情報が境界を越える場合には受け渡しが発生する。分割境界の適否を判断するには、処理間の情報依存関係、独立して実行することの利益、変更後の仕事の完了条件をそれぞれ確認する必要がある。
1. 仕事を分ければ処理は効率化するのか
ソフトウェアを機能別に分割する理由には、変更時の影響を限定すること、個々の機能を理解しやすくすること、担当範囲を定めることなどがある。Parnas は、モジュールをどの基準で分割するかによって設計上の性質が変わることを示し、処理の実行順序に沿った分割と、変更される可能性のある設計上の判断を隠蔽する分割を比較した[1]。例えば、配送情報の取得方法が変更された場合、その変更を配送照会の内部に閉じ込められれば、返品判定の実装まで変更する必要は小さくなる。このような責務の分離は保守性に関係する。一方、返品判定を実行するときに配送情報をどこへ保持し、どのように参照するかは、実行時の情報配置に関する別の設計判断である。
ある購入者が商品を返品したいと申し出た場合を考える。システムは注文の存在を確認し、配送が完了した日付を取得し、返品可能期間と商品の条件を照合し、条件を満たした場合に返金手続きへ進む。仮に返品期限を配送完了日から 30 日以内とする規則があり、配送完了日が 10 月 10 日、返品申請日が 10 月 25 日であれば、経過日数は 15 日である。期間条件は満たされるが、返金を確定するには、商品の状態や返品対象外の商品に該当しないことなど、別の条件も確認する必要がある。各条件を別々の機能で判定しても、最終的な返金可否は複数の判定結果を組み合わせて決まる。
注文照会と配送照会は、異なるデータを取得する独立した機能として実装できる。注文照会は注文番号に対応する購入者、商品、注文日などを返し、配送照会は同じ注文番号に紐づく配送状態や配送完了日を返す。返品判定は両方の結果を受け取り、適用される規則と照合する。この構成では、機能を分離していても、取得したデータを一つの処理で保持して判定に利用できる。業務機能の分離と、情報を保持する推論主体の分離は、同時に採用しなければならない関係にはない。
これに対して、注文確認、配送確認、返品判定をそれぞれ独立した推論主体へ割り当てると、情報の受け渡し方法が判断結果に影響する。例えば、配送確認を担当する推論主体が「配達済み」という結果だけを返した場合、返品判定を担当する推論主体には配送完了日が伝わらない。配送完了日を再取得できれば判定を続けられるが、そのための問い合わせと処理時間が追加される。再取得せず注文日を基準に期間を計算すれば、規則とは異なる日付を使ってしまう可能性がある。先行処理の結果を短くまとめたことが必要情報の欠落を生み、その欠落が追加処理または誤判定の原因になる。
一方、配送確認の結果に配送完了日、配送状態、注文番号を含めれば、後続の返品判定に必要な情報を引き渡せる。返品資格の判定結果についても、単に「返品可能」と返す方法と、適用規則、期間条件、商品条件、判定に使用した日付を返す方法がある。後続の処理が判定結果だけを利用するなら前者で足りる場合があるが、返金額の計算や例外条件の再確認が必要なら、追加の情報が求められる。受け渡す情報の適切な範囲は、情報を生成した処理の都合だけでなく、その情報を利用する後続処理の条件によって決まる。
推論主体を統合する構成では、注文照会、配送照会、返品規則の取得をそれぞれ独立したツールとして維持しながら、取得結果を一つのコンテキストで参照できる。注文番号と配送完了日を保持したまま返品資格を判定できるため、推論主体間の要約や再問い合わせを減らせる可能性がある。ただし、返金処理のように業務データを変更する操作では、情報を参照できることと操作を実行する権限を持つことを区別する必要がある。返品資格の確認を一つの推論主体で完了しても、返金確定には業務上の承認条件を適用できる。推論の統合は、業務機能や実行権限の統合を必然的に伴うものではない。
既稿「AI に仕事を任せるには、モデルの外側を設計する」では、仕事の完了をモデルの出力だけで評価するのではなく、観測、操作、検証を含めた実行系で捉えた[2]。また「方針を実行構造へ変換するエージェント設計」では、モデルが生成した計画と、その計画を実際の操作条件へ変換する仕組みを区別した[3]。これらの設計では、モデルが何を判断するかと、外部システムがどの操作を許可するかを別々に定義できる。同じ考え方を処理の分割へ適用すると、業務機能を独立させる境界、推論に必要な情報を共有する境界、操作権限を強制する境界は、それぞれ異なる条件から決定される。
返品処理を例に、機能の分割と推論主体の分割によって何が変わるかを整理する。
| 構成 | 情報の扱い | 成立条件と帰結 |
|---|---|---|
| 業務機能を分離し、推論主体を統合 | 注文照会と配送照会を独立した機能として呼び出し、取得結果を一つのコンテキストで保持する。 | 複数の判断で同じ情報を利用できる。業務機能の独立性を維持しながら、推論主体間の情報受け渡しを削減できる。 |
| 業務機能と推論主体をともに分離 | 各推論主体が必要な情報を取得し、後続の推論主体へ結果を引き渡す。 | 各処理のコンテキストを独立させられる。後続の判断に必要な情報が受け渡されなければ、再取得や判定条件の欠落が発生する。 |
| 独立した検証処理を分離 | 先行する判断結果を受け取り、必要に応じて別の情報源や検証手順で妥当性を確認する。 | 先行処理の判断を別の経路で確認できる。ただし、同じ誤った根拠を共有する場合には、推論主体を分けても独立した検証の利益は限定される。 |
| 実行権限を分離 | 推論主体が判定結果を生成し、返金確定などの状態変更は別の実行機構が受け付ける。 | 判断に必要な情報を共有しながら、未承認の操作を実行機構で拒否できる。推論主体の数とは独立して権限境界を設定できる。 |
この比較から、責務を分割する理由と、コンテキストを分割する理由が異なることが分かる。配送照会を独立した機能にすることは、配送情報の取得方法を変更しやすくする。一方、配送照会のためだけに独立した推論主体を置くと、取得結果を返品判定へ引き渡す経路が追加される。その経路に必要な情報が完全に含まれていれば判断品質を維持できるが、要約によって日付や条件が失われれば、後続処理の結果が変わる可能性がある。機能の独立性を確保することと、推論時の情報を分離することには、それぞれ異なる費用と利益が存在する。
分割境界を決める際には、どの処理が同じ情報を必要とするか、どの処理が先行する結果を必要とするか、どの処理に独立した実行や検証が求められるかを識別する必要がある。注文照会と返品判定のように情報を共有する利益がある処理では、共通のコンテキストを利用する構成が候補になる。大量の文書を並列に調べる処理や、先行判断を独立して検査する処理では、コンテキストを分ける構成が候補になる。分割の適切さは、機能や担当者の数よりも、処理間の情報依存関係と、分離によって実際に得られる利益から評価できる。
2. 処理間の情報依存関係を数式で表す
処理を分割する際には、二つの異なる依存を確認する必要がある。一つは複数の処理が同じ情報を必要とする関係であり、もう一つは先行する処理の結果が得られなければ後続の処理を実行できない関係である。例えば、注文照会と配送照会は同じ注文番号を使うが、取得する情報は異なる。一方、返品資格の判定は、注文照会と配送照会の結果が揃って初めて実行できる。情報の重複は同じデータを共有できる可能性を示し、実行順序の依存は処理を開始できる条件を示す。この二つを区別することで、情報を共有するために統合する処理と、独立したまま実行順序を管理する処理を判断できる。
処理の集合を \(V\)、処理間の依存関係を \(E\) とし、有向グラフを次のように定義する。
\[G=(V,E)\]
ここで、\(V\) は処理を表す頂点の集合、\(E\) は先行処理の結果を必要とする関係を表す有向辺の集合である。例えば、注文取得を \(v_1\)、配送照会を \(v_2\)、返品資格判定を \(v_3\)、返金確定を \(v_4\) とする。返品資格判定が注文取得と配送照会の結果を必要とし、返金確定が返品資格判定の結果を必要とする場合、依存関係は次のように表せる。
\[E=\{(v_1,v_3),(v_2,v_3),(v_3,v_4)\}\]
\((v_1,v_3)\) は、注文取得の結果が返品資格判定の入力になることを意味する。同様に、\((v_2,v_3)\) は配送照会の結果への依存を示し、\((v_3,v_4)\) は返金確定が返品資格判定の結果を必要とすることを示す。この例では、注文取得と配送照会の間に依存する辺がないため、両者は並列に実行できる。ただし、返品資格判定は両方の結果を待つ必要があり、返金確定は資格判定の完了を待つ。さらに、実際の返金操作には承認などの実行条件が加わる。処理を独立した推論主体へ分割しても、この依存関係そのものは維持しなければならない。
実行順序に加えて、各処理がどの情報を必要とするかを測定する。処理 \(i\) が参照する情報項目の集合を \(C_i\) とし、二つの処理で共通する項目の割合を Jaccard 係数で表す。
\[J(i,j)=\frac{|C_i\cap C_j|}{|C_i\cup C_j|}\]
分子の \(|C_i\cap C_j|\) は二つの処理で共通する情報項目の数、分母の \(|C_i\cup C_j|\) は少なくとも一方が必要とする情報項目の総数を表す。両集合が空でない通常の場合、\(J(i,j)\) は 0 から 1 の範囲を取り、1 に近いほど情報項目の重複が大きい。\(J(i,j)=1\) なら必要項目は完全に一致し、\(J(i,j)=0\) なら共通項目がない。両集合が空の場合は分母が 0 になるため、別途定義する必要がある。この係数は情報項目を同じ重みで数える指標であり、情報の意味、取得費用、更新頻度、判断への寄与を直接測定するものではない。
返品処理の主要な情報項目を例に、情報の重複と実行上の条件を比較する。
| 処理 | 必要な情報 | 実行上の条件 |
|---|---|---|
| 注文照会 | 注文番号、注文日、配送状況を取得する。 | 注文番号が特定できれば実行できる。 |
| 返品資格判定 | 注文番号、注文日、配送状況、返品可能期間を参照する。 | 注文と配送の確認結果を必要とする。 |
| 返金確定 | 注文番号、判定結果、返金額、承認状態を参照する。 | 資格判定と必要な承認が成立してから実行する。 |
表の最初の二つの処理について、注文照会が必要とする情報集合を \(C_1=\{\text{注文番号},\text{注文日},\text{配送状況}\}\)、返品資格判定が参照する情報集合を \(C_3=\{\text{注文番号},\text{注文日},\text{配送状況},\text{返品可能期間}\}\) とする。このとき、共通部分は 3 項目、和集合は 4 項目となるため、重複率は次のように求められる。
\[J(1,3)=\frac{3}{4}=0.75\]
この値は、表に示した主要項目の 75% が二つの処理で共通していることを意味する。ただし、これは情報項目を限定した例である。実際の返品資格判定では配送完了日や商品条件なども必要になり、それらを集合に追加すれば重複率も変わる。また、同じ「配送状況」という項目であっても、注文情報に記録された状態と、配送システムから取得した最新の状態では、更新時点や信頼できる範囲が異なる場合がある。情報項目の名称が一致することと、同じ判断根拠として使用できることは区別する必要がある。
重複率が高い処理は、情報を共有する構成の候補になる。注文照会で取得した情報を返品資格判定が再利用できれば、同じ注文を再検索する費用を削減できる。一方、注文照会の結果を後続処理へ必要な項目を保持したまま引き渡せるなら、独立した処理を維持しても情報の再取得は不要になる。逆に、先行処理が「注文を確認済み」という結果だけを返し、返品判定に必要な注文日や配送状況を省略した場合、後続処理は不足した情報を再取得する必要がある。情報の重複そのものよりも、共有または受け渡しによって必要な情報を保持できるかが、処理費用と判断品質を左右する。
実行順序への依存は、情報の重複率とは別に残る。注文照会と返品資格判定を同じ推論主体へ統合しても、存在しない注文に対して返品資格を確定することはできない。反対に、注文照会と配送照会を異なる推論主体へ分離しても、両者の間に実行上の依存がなければ並列化できる。つまり、必要情報の重複が大きいことは統合の候補を示すが、処理順序や並列実行の可否まで決定するわけではない。分割境界を変更しても、依存グラフが表す先行条件を維持する必要がある。
Shannon が定式化した情報量の理論は、情報伝達と不確実性を数量化する基礎を与える[4]。ただし、ここで使用した Jaccard 係数は情報理論における相互情報量そのものではなく、必要な情報項目の重複を確認するための集合上の指標である。情報項目が同じでも、その値の分布や他の情報との関係が異なれば、判断に対する情報量は変わる。また、先行処理が取得した情報を要約して後続処理へ渡す場合には、項目が存在するかどうかに加えて、その値や判断に必要な関係が保持されているかも確認する必要がある。
分割境界の評価では、情報項目の重複、処理結果への依存、受け渡しによって保持される情報を別々に測定する。情報集合の重複は共有可能なデータを特定し、有向グラフは実行順序と並列化の可能性を特定する。両者を組み合わせることで、同じ情報を共有しながら実行順序を管理する構成と、独立した処理へ分離する構成を比較できる。さらに、処理間で情報を圧縮する場合には、その圧縮が後続の判断にどのような影響を及ぼすかを評価する必要がある。
3. 情報を受け渡すと何が失われるのか
先行する処理が大量の情報を取得しても、後続の処理がそのすべてを必要とするとは限らない。例えば、返品資格の判定では注文履歴、配送記録、商品条件、返品規則を参照するが、返金処理では確定した判定結果と返金額だけを使用する構成も考えられる。この場合、参照した全文を引き渡すより、必要な項目を抽出して渡す方が通信量やモデルへの入力を削減できる。ところが、返金額を後続の処理で計算する場合には、購入金額、割引条件、送料の扱いなどが必要になる。返品資格判定の結果を「返品可能」とだけ要約すると、資格の有無は伝わっても、返金額を算出するための情報は失われる。
情報の受け渡しによって何が失われるかは、先行する処理が取得した情報と、後続の処理が必要とする情報の関係から考えられる。元情報を \(X\)、後続処理へ渡す要約を \(M=f(X)\)、後続の正しい判断に関係する変数を \(Y\) とする。例えば、\(X\) は注文履歴や配送記録、返品規則を含む情報、\(M\) は返品資格判定が返す結果、\(Y\) は後続の処理で確定すべき返金条件に対応する。ここで \(Y\) はモデルが実際に出力した判断ではなく、必要な条件を満たす正しい判断を表す確率変数として定義する。
要約 \(M\) が元情報 \(X\) だけから生成され、元情報が与えられたときに要約が正しい判断 \(Y\) に関する追加情報を持たないなら、\(Y\rightarrow X\rightarrow M\) というマルコフ連鎖が成立する。この条件の下では、データ処理不等式により次の関係が成り立つ。
\[I(Y;M)\leq I(Y;X)\]
\(I(Y;M)\) は要約 \(M\) が正しい判断 \(Y\) について持つ相互情報量、\(I(Y;X)\) は元情報 \(X\) が持つ相互情報量である。相互情報量は、一方の変数を知ることで他方の変数に関する不確実性がどれだけ減少するかを表す。右辺は元情報を利用した場合、左辺は要約だけを利用した場合に対応する。要約が元情報から生成される限り、その変換によって正しい判断に関する情報を新たに増やすことはできない。
例えば、元情報に購入金額 10,000 円、割引額 2,000 円、返品資格を満たすという判定が含まれているとする。返金額を購入金額から割引額を差し引いた 8,000 円とする規則であれば、元情報から返金額を算出できる。しかし、要約が「返品可能」という文字列だけなら、返金額を確定するための購入金額と割引額が欠落する。後続の処理が要約だけを参照する場合、正しい返金額を求めるには元情報を再取得するか、追加の入力を必要とする。これは、要約による情報の省略が後続の判断に影響する具体例である。
一方、要約に注文番号、確定した返金額 8,000 円、承認状態が含まれ、後続の処理がその金額を指定された決済手段へ返金するだけなら、購入金額や割引額を改めて参照する必要は小さくなる。このように、情報を省略しても正しい判断に必要な関係が保持される場合がある。Tishby らの情報ボトルネック法は、入力に含まれる情報を圧縮しながら、予測対象に関連する情報を保持する課題を定式化している[5]。圧縮の目的は、入力の情報を一律に削減することではなく、後続の判断に必要な情報を残すことである。
この条件は、元情報と要約の関係からさらに明確にできる。要約 \(M\) が \(X\) の関数であるとき、次の条件が成立すれば、要約は \(Y\) の判断に関して元情報が持つ情報を保持している。
\[P(Y\mid X)=P(Y\mid M)\]
これは、元情報 \(X\) をすべて参照した場合と、要約 \(M\) だけを参照した場合とで、正しい判断 \(Y\) の条件付き確率分布が一致することを意味する。この等式が成り立つ場合、要約は \(Y\) に関する十分統計量となり、相互情報量についても \(I(Y;M)=I(Y;X)\) が成立する。要約によって文章量が減っていても、対象となる判断に関しては情報が失われていないことになる。ただし、この等式は正しい判断に必要な情報が保持される条件を表すものであり、実際のモデルがその情報を常に正しく利用することまで保証するものではない。
要約の十分性は、後続の処理が何を判断するかによって変わる。返金額を確定した後に決済操作だけを行う処理なら、確定済みの金額が十分な入力となり得る。しかし、返品資格を再判定する処理では、配送完了日、適用した返品規則、商品の状態などが必要になる。さらに、返品規則が変更された場合、以前の規則に基づいて確定した判定結果だけでは、新しい規則による再判定に対応できない。ある判断に対して十分な要約であっても、別の判断や条件変更に対して十分とは限らない。
情報をどの形式で受け渡すかによって、後続の処理が取得できる情報と、欠落を検出できる範囲も変わる。返品資格判定から返金処理への受け渡しを例に整理する。
| 受け渡し方式 | 保持する情報 | 成立条件と失敗条件 |
|---|---|---|
| 結論だけの要約 | 「返品可能」という判定結果だけを渡す。 | 後続処理が資格の有無だけを必要とする場合には利用できる。返金額の計算や判定根拠の確認が必要な場合には情報が不足する。 |
| 構造化された判定結果 | 注文番号、資格判定、適用規則、判定基準日、返金額、承認状態などを定義された項目で渡す。 | 必要項目の存在や形式を検証できる。項目の定義が後続処理の要件を満たしていなければ、構造化されていても判断材料が不足する。 |
| 元情報への参照を保持 | 判定結果とともに、注文記録、配送記録、適用規則を取得できる識別情報を渡す。 | 必要に応じて詳細を再取得できる。参照先の変更、権限不足、取得不能が発生すると、元の判定根拠を確認できない場合がある。 |
| 元情報をそのまま共有 | 先行処理が取得した注文履歴、配送記録、返品規則などを後続処理でも参照可能にする。 | 情報の再取得や要約による省略を減らせる。一方、後続処理が必要としない情報も入力に含まれ、処理量や参照対象が増える。 |
構造化された判定結果は、自由文の要約に比べて必要項目の欠落を検出しやすい。例えば、返金処理の入力仕様で注文番号、返金額、承認状態を必須とすれば、返金額が存在しない結果を実行前に拒否できる。ただし、必須項目が揃っていても、その値が正しいとは限らない。返金額が誤った割引条件から計算されていた場合、形式検証だけでは誤りを検出できない。項目の存在と型を確認する検証に加えて、金額の算出根拠や適用規則との整合性を確認する仕組みが必要になる。
元情報への参照を保持する方法では、判定結果と根拠を分離して管理できる。例えば、返品資格判定の結果に注文記録の識別子と適用した規則の版を含めれば、後続処理は必要な場合に限って詳細を取得できる。ただし、参照先の記録が更新される場合、後から取得した情報が当初の判定時点と一致する保証はない。判定時点の配送状態や適用規則を再現する必要があるなら、記録の版、更新時刻、履歴などによって参照対象を特定する必要がある。参照を渡す方式は情報量を削減できる一方、参照先の同一性と取得可能性を維持する条件が加わる。
元情報を一つのコンテキストで共有する場合には、別の制約が生じる。取得した情報が増えるほど、モデルへの入力が長くなり、判断に必要な項目が大量の無関係な情報に埋もれる可能性がある。Liu らは、長い入力に含まれる関連情報の位置によって、言語モデルの利用性能が変化することを示した[6]。関連情報が入力の途中に置かれた場合、入力の先頭や末尾に置かれた場合と比較して性能が低下する条件が報告されている。これは、情報をコンテキストに含めたことと、その情報をモデルが正しく利用できることを区別する必要があることを示している。
Anthropic も、エージェントが利用する情報を目的に応じて選別し、必要な情報を実行時に取得するコンテキスト設計を説明している[7]。例えば、注文履歴全体を最初から読み込む代わりに、注文番号で対象を絞り、返品資格判定に必要な情報だけを取得する構成が考えられる。返金額に疑義が生じた場合には、購入時の割引条件や規則の履歴を追加で取得する。この方法では、必要な情報へ到達できる経路を保持しながら、個々の判断で参照する情報量を制限できる。
データ処理不等式が示すのは、元情報から生成された要約が、正しい判断に関する情報を増加させないという関係である。一方、実際のエージェントでは、入力の長さ、情報の配置、検索ツールの利用、モデルの判断能力も結果に影響する。元情報を共有した構成が理論上より多くの情報を保持していても、モデルが必要な情報を取得できなければ、その利益を十分に利用できない。逆に、情報を適切に選別した構造化結果は、元情報より短い入力であっても、後続の処理に必要な判断を成立させる場合がある。
分割境界で評価すべき性質は、受け渡した文章の長さだけでなく、後続の判断に必要な情報が保持され、その情報を実際に利用できるかである。返品資格の判定結果だけで足りる処理には短い結果を渡し、返金額の再計算や例外条件の確認が必要な処理には根拠への参照を残す。複数の処理が同じ情報を繰り返し必要とする場合には、共通のコンテキストで保持する構成も候補になる。情報の圧縮による処理量の削減と、判断に必要な情報の保持を両立できる範囲が、合理的な情報共有の境界となる。
4. 分割によって得られる並列化と独立検証の利益
処理を分割すると情報の受け渡しが必要になる一方、それぞれの処理を独立して実行できるようになる場合がある。例えば、注文情報の取得と配送状況の照会は、同じ注文番号を入力として、それぞれ異なる情報源へ同時に問い合わせることができる。両方の結果を必要とする返品資格判定は、それらの問い合わせが完了してから実行する。返金確定はさらに資格判定の結果と承認を必要とする。この構成では、注文照会と配送照会を並列化できるが、返品資格判定と返金確定の先行関係は維持される。処理を何個に分割したかよりも、どの処理を同時に実行できるかが全体の所要時間を左右する。
処理の分離には、実行時間の短縮とは異なる目的もある。例えば、あるエージェントがコードを修正した後、別のエージェントが修正内容を検証する場合、検証担当は修正担当が採用した推論をそのまま引き継ぐ必要がない。要求仕様、変更前のコード、実行したテストなどを独立して確認できれば、修正担当が見落とした条件を発見する可能性がある。この場合、コンテキストの分離には、先行判断への依存を制限するという役割がある。並列化と独立検証は、どちらも分離によって実現できるが、成立条件と評価指標が異なる。
4.1 並列化の効果と限界
処理の並列化による時間短縮を考えるには、全体の仕事のうち、同時に実行できる部分と、順序を守って実行しなければならない部分を区別する必要がある。例えば、注文照会と配送照会を同時に実行しても、それらの結果を使う返品資格判定は両方の完了を待つ。この待ち合わせが存在するため、すべての処理を独立させても、全体の所要時間が処理数に反比例して短くなるわけではない。
全体の処理時間のうち並列化できる割合を \(p\)、並列実行に利用できる処理資源の数を \(n\) とする。逐次部分の割合は \(1-p\) であり、並列化できる部分の所要時間は、理想的には元の \(1/n\) になる。通信、待ち合わせ、処理資源の競合を無視した場合、Amdahl の法則に基づく速度向上率は次のように表される[8]。
\[S(n)=\frac{1}{(1-p)+p/n}\]
\(S(n)\) は、並列化前の所要時間を並列化後の所要時間で割った速度向上率である。例えば、全体の処理時間の 80% を並列化でき、4 個の処理資源を利用できると仮定する。このとき、\(p=0.8\)、\(n=4\) となり、速度向上率は次のように計算できる。
\[S(4)=\frac{1}{0.2+0.8/4}=2.5\]
元の処理時間を 100 秒とすると、逐次部分の 20 秒はそのまま残り、並列化できる 80 秒は理想的には 20 秒へ短縮される。合計は 40 秒となり、速度向上率は 2.5 倍である。4 個の処理資源を利用しても 4 倍にはならない理由は、全体の 20% を占める逐次部分が残るためである。並列化できる割合が一定なら、処理資源を増やしても逐次部分が速度向上率の上限を決める。
ここでの \(n\) は、同時に処理を実行できる資源の数を表している。エージェントを 4 個に増やしたことだけで、4 個の処理が同時に進むとは限らない。各エージェントが同じモデルの実行枠を共有する場合、同時リクエスト数の制限や待ち行列によって実行が直列化される可能性がある。また、複数のエージェントが同じ情報源へ問い合わせれば、接続数や要求頻度の制限が全体の所要時間に影響する。エージェント数と実際に利用できる並列処理能力は区別して測定する必要がある。
実際のエージェントでは、モデルへの問い合わせ、ツールの実行、結果の要約、情報の受け渡しにも時間がかかる。例えば、注文照会に 3 秒、配送照会に 5 秒、返品資格判定に 4 秒、返金確定に 2 秒かかるとする。すべてを逐次実行すれば、処理時間の合計は 14 秒である。注文照会と配送照会を同時に開始でき、処理資源の競合や追加の受け渡し時間がなければ、最初の二つの処理は長い方の 5 秒で完了する。そこから資格判定に 4 秒、返金確定に 2 秒かかるため、全体は 11 秒となる。
この例では、並列化によって 3 秒を短縮できる。ただし、注文照会と配送照会の結果を別の推論主体へ引き渡す際に、それぞれ追加のモデル呼び出しや要約が必要になる場合がある。仮に並列化による短縮が 3 秒であっても、そのために追加した受け渡し処理が全体の完了までの経路上で合計 4 秒を要するなら、並列構成の所要時間は逐次構成より長くなる。並列実行そのものの利益と、並列実行を成立させるための調整費用を同時に評価する必要がある。
こうした依存関係は、前述した有向グラフを使って表現できる。処理の実行順序に循環がないと仮定し、開始から終了までの依存経路を \(p’\)、処理 \(i\) の所要時間を \(t_i\)、処理間の境界 \(e\) における受け渡し時間を \(h_e\) とする。このとき、全体の所要時間 \(L\) は、少なくとも最長の依存経路に含まれる処理時間と受け渡し時間の合計以上になる。
\[L\geq\max_{p’\in\mathcal{P}(G)}\left(\sum_{i\in p’}t_i+\sum_{e\in p’}h_e\right)\]
\(\mathcal{P}(G)\) は開始から終了へ至る依存経路の集合である。右辺は、それぞれの経路に含まれる処理時間 \(t_i\) と受け渡し時間 \(h_e\) を合計し、その最大値を求めている。最も時間のかかる依存経路をクリティカルパスと呼ぶ。複数の処理を同時に実行できても、クリティカルパス上の処理には先行関係があるため、この経路が終わる前に全体を完了することはできない。処理資源が十分にあり、各処理時間が固定され、経路外の待ち時間が発生しない理想的な条件では、この下限に一致する。
例えば、注文照会が 3 秒、配送照会が 5 秒の場合、両者が並列に動いている間は配送照会が長い方の経路になる。注文照会を 3 秒から 2 秒へ短縮しても、配送照会が 5 秒かかる限り、返品資格判定を開始できる時点は変わらない。一方、配送照会を 5 秒から 4 秒へ短縮すれば、後続の判定を 1 秒早く開始できる。この違いは、個々の処理をどれだけ短縮できたかだけでなく、その処理がクリティカルパス上に存在するかによって、全体の応答時間への影響が変わることを示している。
分散データ処理の MapReduce も、仕事を複数の処理へ分散する一方で、途中結果の集約やデータの受け渡しを必要とする構成である[9]。複数の処理資源へ仕事を割り当てることで並列性を得られるが、処理間のデータ転送や集約には費用が発生する。エージェントの場合は、これに加えてモデル呼び出しやコンテキストの再構成が必要になることがある。処理の分割による時間短縮が成立するのは、並列化によって削減できる時間が、追加される通信、調整、待ち合わせの時間を上回る場合である。
4.2 独立検証のための分離
並列化とは別に、先行する判断を独立して検証するために処理を分ける場合がある。例えば、あるエージェントがソフトウェアの不具合を修正したとする。修正担当は、発生したエラー、関連コード、想定した原因を調べ、変更内容を決定する。検証担当が修正担当の説明だけを受け取って確認する場合、修正担当が見落とした条件も説明から欠落している可能性がある。修正担当が「原因は入力値の検証不足である」と判断していても、実際には状態の更新順序や並行処理にも問題が存在する場合がある。
検証担当が変更前の要求仕様、変更差分、既存のテスト、実行結果を独立して参照できれば、修正担当が採用した原因説明とは異なる観点から確認できる。例えば、修正担当が特定の入力でエラーが発生しなくなったことを確認していても、検証担当は別の入力や並列実行条件で同じ不具合が発生しないかを調べられる。検証に使用する情報や手順が異なることで、先行する判断が見落とした条件を検出する可能性が生まれる。
ただし、検証担当を別のエージェントにしただけでは、判断の独立性は確保されない。両者が同じ誤った仕様を正しい前提として使用していれば、別々に推論しても同じ誤った結論に至る場合がある。また、検証担当に修正担当の推論過程をすべて渡し、その説明に沿って確認するよう指示すれば、検証の着眼点が先行判断に依存する可能性がある。同じモデルを利用する複数のエージェントでは、モデルに共通する誤りも残る。コンテキストを分離することは独立検証を実現する手段の一つだが、使用する証拠と検証手順の独立性も必要になる。
検証の独立性を評価する際には、何を分離するかを具体的に定義する必要がある。例えば、修正担当が使用した原因仮説を検証担当に渡さず、変更内容と要求仕様だけを与える構成では、先行する原因説明への依存を減らせる。一方、修正箇所を特定するために必要な情報まで隠すと、検証対象を正しく理解できなくなる可能性がある。検証に必要な事実は共有しながら、先行判断の結論や推論経路に対する依存を制限することが、独立した確認を成立させる条件になる。
実際のソフトウェア検証では、異なるエージェントが同じコードを読んで結論を出すだけでなく、テストの実行や静的解析の結果を利用できる。例えば、修正担当が「問題は解消した」と報告しても、検証担当が回帰テストを実行して失敗を観測した場合、その実行結果は修正担当の自己評価とは異なる根拠になる。テストの期待値自体が誤っている可能性は残るが、モデルによる説明と、実行環境で観測された結果を区別できる。独立性の利益は、推論主体の数よりも、異なる証拠や判定条件によって誤りを検出できるかに現れる。
Anthropic のマルチエージェント調査システムでは、複数の調査担当が異なる方向を並列に探索し、その結果を統合する構成が採用されている[10]。これは、独立した調査経路を用意することで探索範囲を広げる事例である。また、複数の協調方式を比較した資料では、独立した作業を並列に実行する構成、結果を生成する処理と検証する処理を分ける構成、共有状態を介して協調する構成などが区別されている[11]。これらの構成は、処理を複数に分割する点では共通するが、並列化、探索範囲の拡大、検証という異なる目的を持っている。
分割によって得られる利益と、その成立条件を整理すると次のようになる。
| 分割の目的 | 利益が成立する条件 | 利益が限定される条件 | 評価する指標 |
|---|---|---|---|
| 並列実行 | 処理間に逐次依存がなく、複数の処理資源を同時に利用できる。 | 待ち合わせや処理資源の競合が多く、通信・調整時間が短縮時間を上回る。 | 全体の応答時間、クリティカルパス、待機時間を比較する。 |
| 探索範囲の拡大 | 異なる情報源や探索方針を利用し、複数の候補を調べられる。 | 同じ情報源と探索条件を繰り返し使用し、取得結果が重複する。 | 必要な情報の発見率、探索結果の重複、追加の取得費用を比較する。 |
| 独立検証 | 先行判断とは異なる証拠や検証手順を利用し、誤りを検出できる。 | 同じ誤った前提を共有するか、先行判断の結論を追認する。 | 誤りの検出率、見逃し率、検証結果の再現性を比較する。 |
| コンテキストの隔離 | 各処理が大量の情報を参照し、後続処理には限定された結果だけが必要になる。 | 後続処理が元情報を繰り返し必要とし、要約による欠落や再取得が発生する。 | 入力トークン数、再取得回数、必要情報の保持率を比較する。 |
この表では、並列実行による時間短縮と独立検証による品質改善を別々の評価対象としている。例えば、コード修正と独立検証を異なるエージェントに割り当てても、検証が修正の完了後に始まるなら、その二つの処理は逐次依存する。この構成では並列化による時間短縮は得られないが、検証に使用する証拠や手順を独立させる利益は残る。反対に、複数の文書を並列に検索する構成では応答時間を短縮できても、各検索結果の正確性を独立して検証したことにはならない。
コンテキストの隔離についても、分離そのものを目的とする場合と、処理に必要な情報を削減する手段として利用する場合を区別できる。例えば、大量のログから障害原因を調べる処理では、調査担当が数万行のログを参照しても、主エージェントには障害の発生時刻、原因候補、根拠となるログの位置だけを渡せば足りる場合がある。このとき、大量の中間情報を主エージェントのコンテキストへ追加せずに済む。一方、主エージェントが原因候補を再評価する必要があるなら、要約だけでは情報が不足する可能性がある。分離の利益は、後続処理が必要とする情報の範囲によって変わる。
並列化と独立検証の利益は、情報共有による利益と必ずしも両立しない。複数の処理へ共通情報を渡せば重複した問い合わせを減らせるが、その中に先行する結論や原因仮説まで含めると、検証担当の判断が影響を受ける可能性がある。反対に、各処理へ完全に独立した情報取得を要求すれば、同じ資料を何度も読み込む費用が発生する。どの情報を共有し、どの情報を独立して取得するかを区別することで、処理費用と検証の独立性を調整できる。
同じ情報を必要とする逐次処理では、情報を共有することで受け渡しや再取得を削減できる。独立した探索を並列に進める処理では、分離によってクリティカルパスを短縮できる場合がある。先行判断を検証する処理では、情報経路や検証手順を分けることで誤りの検出可能性を高められる場合がある。これらはそれぞれ異なる条件で成立する利益であり、同じ指標だけで比較することはできない。適切な分割境界を決めるには、応答時間や処理費用に加えて、判断品質、検証の独立性、実行上の制約を同時に評価する必要がある。
5. 品質を維持したまま分割境界を決定する
処理を統合して応答時間や実行費用を削減できても、最終的な仕事の完了品質が低下するなら、その変更を採用する理由は限定される。例えば、注文照会、配送確認、返品資格判定を一つのエージェントへ統合した結果、モデルの呼び出し回数が減ったとしても、配送完了日の確認を省略して返品資格を誤判定すれば、業務上の目的を満たさない。反対に、複数のエージェントを利用して正確な判定結果を得られても、必要な承認を経ずに返金を確定する構成は採用できない。処理の分割境界を評価するには、応答時間、実行費用、仕事の完了品質、操作の制約を区別し、それぞれに成立条件を定める必要がある。
これらの条件は、すべて同じ方法で評価できるわけではない。応答時間や実行費用は、同じ仕事を実行した際の時間や金額として測定できる。一方、仕事の完了品質は、期待された業務状態に到達したか、必要な情報を取得したか、判定に誤りがなかったかなど、複数の観点を含む。さらに、権限外の情報取得や未承認の返金操作は、発生率が低ければ許容できるという性質のものではない。平均的な性能を比較する指標と、個々の操作で必ず満たすべき制約を分けることで、構成変更の採用条件を明確にできる。
候補となるエージェント構成を \(A\)、モデルとツールの実行費用を \(C(A)\)、応答時間を \(L(A)\)、仕事全体の完了品質を \(Q(A)\)、許容可能なリスク指標を \(R(A)\) とする。品質とリスクについて要求水準を定めたうえで、費用と応答時間を最小化する問題は、次のように定式化できる。
\[\begin{aligned}
\min_A\quad & \alpha C(A)+\beta L(A)\\
\text{subject to}\quad
& Q(A)\geq Q_{\min}\\
& R(A)\leq R_{\max}
\end{aligned}\]
ここで、\(\alpha\) と \(\beta\) は費用と応答時間の相対的な優先順位を表す重みであり、\(Q_{\min}\) は要求する最低品質、\(R_{\max}\) は許容するリスクの上限である。費用と時間は単位が異なるため、重みを設定する際には単位の整合性を確保する必要がある。例えば、応答時間を 1 秒短縮することに対して許容する追加費用を定めれば、両者を共通の尺度で比較できる。また、構成間で品質の測定方法が異なれば、同じ \(Q_{\min}\) を使用しても比較は成立しない。評価対象となる仕事、正解条件、集計方法を統一したうえで、品質制約を適用する必要がある。
この式は、特定の研究で性能が検証された最適化手法をそのまま適用したものではなく、分割境界の評価条件を整理するための定式化である。目的関数が表すのは、必要な品質とリスク条件を満たす構成の中から、費用と応答時間の組み合わせが適切なものを選択するという考え方である。すべての構成が品質制約を満たさない場合、費用や応答時間を比較しても採用可能な構成は得られない。また、重みを変更すれば最適と判定される構成が変わる場合がある。最適なエージェント数が一意に決まるのではなく、業務上の要求と評価条件によって採用すべき構成が決まる。
例えば、従来のマルチエージェント構成と、処理を統合した単一エージェント構成を比較するとする。統合後の構成でモデル呼び出し回数が減り、応答時間が短縮された場合でも、返品資格判定の完了率が低下していれば、品質制約を満たすかどうかを確認する必要がある。さらに、全体の完了率が維持されていても、返金額の誤計算が増えたり、返品対象外の商品を誤って受理したりする場合がある。失敗の種類によって業務上の影響が異なるため、単一の完了率だけでは構成変更の妥当性を十分に判断できない。
仕事の完了品質を測るには、最終的な状態と、その状態に到達するために必要な条件を定義する。返品処理であれば、正しい注文を特定したこと、配送完了日を確認したこと、適用規則に基づいて返品資格を判定したこと、返金額を正しく算出したことなどが該当する。返金を伴う場合には、必要な承認を経て、正しい注文に対して適切な金額の返金が確定したことまで確認する。注文番号の取得に成功しても配送確認を省略していれば、途中の処理は成功していても仕事全体が正しく完了したとは評価できない。
一方、各処理がすべて実行されたことだけを成功条件にしても、品質を十分に測定できない場合がある。例えば、返金額が既に確定している注文に対して、同じ計算を再実行する必要はない。逆に、必要な情報が不足している注文では、追加の照会や確認を実行しなければ正しい結論へ到達できない。評価すべきなのは、あらかじめ決めたすべての処理を通過したかどうかだけではなく、個々の入力条件に対して必要な確認が行われ、最終状態が要求を満たしたかである。処理経路は、正しい結果が得られた理由や失敗の原因を分析するための情報として記録する。
構成変更による品質差を評価する際には、集計値と個別の失敗を分けて確認する必要がある。既稿「安全判定の揺らぎを入力・構造・評価方法に分けて測る」で扱ったように、平均値が同じでも、個別入力に対する判定が変化している場合がある[12]。例えば、100 件の返品要求のうち 95 件を正しく処理できる構成が二つあっても、失敗した 5 件が同じとは限らない。一方は配送完了日の取得に失敗し、もう一方は返品対象外の商品を誤って受理している可能性がある。両者の完了率は同じ 95% でも、失敗が発生した条件と業務上の影響は異なる。
この違いを調べるには、同じ評価課題を構成変更の前後で実行し、個々の課題について成功と失敗の変化を確認する必要がある。変更前に成功していた課題が変更後に失敗すれば、回帰の候補として原因を調べる。反対に、変更前に失敗していた課題が成功するようになれば、改善が発生した条件を確認できる。全体の完了率だけを比較する場合、改善した課題と悪化した課題が相殺される可能性がある。構成変更の影響を特定するには、課題ごとの結果と、その結果に至った処理経路を対応させる必要がある。
また、生成モデルの出力には、同じ入力でも結果が変化する場合がある。そのため、単発の評価だけで構成間の品質差を確定することは難しい。例えば、ある返品要求に対して統合前の構成が 3 回中 3 回成功し、統合後の構成が 3 回中 2 回成功した場合、統合後に失敗が観測されたことは確認できるが、その差が安定して再現するかは追加の評価が必要になる。評価回数、入力条件、使用モデル、ツールの応答条件を管理し、必要に応じて複数回の実行結果を比較することで、偶発的な出力変動と構成変更に伴う回帰を区別しやすくなる。
品質と実行費用の比較では、評価対象となる仕事の分布も揃える必要がある。返品可能な通常注文ばかりを評価すれば、例外条件の確認を省略する構成でも高い完了率が得られる可能性がある。返品期限を超過した注文、配送状態が未確定の注文、割引が適用された注文、承認が必要な返金などを含めることで、実際に必要となる判断条件を評価できる。費用についても、単純なモデル呼び出し回数だけでなく、入力・出力トークン、ツール利用、失敗後の再実行を含めて比較する必要がある。ある構成で通常処理の費用が減っても、例外処理の再実行が増えれば、仕事全体の費用は増加する場合がある。
品質の評価とは別に、業務上の禁止操作には確定的な制約を設ける必要がある。NIST の AI Risk Management Framework は、AI システムのリスクを特定、測定、管理するための枠組みを提示している[13]。リスクを継続的に評価する考え方は構成変更にも適用できるが、権限外の情報取得や未承認の返金確定については、平均的な失敗率の測定だけで実行の安全性を確保することはできない。返金操作を実行するツールや業務システム側で、対象注文、操作主体の権限、返品資格、承認状態を確認し、条件を満たさない要求を拒否する必要がある。
例えば、モデルが返金資格を満たすと判断し、返金確定ツールを呼び出したとしても、その判断結果だけで返金を実行する構成では、モデルの誤判定が業務データの変更につながる。ツール側で資格判定済みであることと必要な承認が成立していることを確認すれば、モデルが誤った引数を生成しても、実行前に拒否できる。さらに、返金対象の注文番号と承認対象が一致しているか、承認が現在も有効か、既に返金済みでないかを確認することで、別注文への誤操作や重複した返金を防ぐ条件を実装できる。これらの条件は、エージェントを統合するか分離するかにかかわらず維持する必要がある。
モデルに禁止操作を指示しないよう求めることと、実行基盤が禁止操作を拒否することは、検証方法も異なる。評価課題でモデルが禁止されたツールを呼び出さなかったとしても、禁止操作を拒否する仕組みが正常に動作することまでは確認できない。実行基盤の制約を検証するには、承認が存在しない状態、権限外の注文番号、不正な返金額、重複した返金要求などを直接入力し、操作が拒否されることを確認する必要がある。モデルの判断品質はタスク評価で測り、強制的な実行制約は対象となるツールや業務システムのテストで確認する。両者を分けることで、モデルの出力変動と実行基盤の欠陥を区別できる。
分割境界の変更を採用する際に必要となる評価軸を整理する。
| 評価軸 | 測定対象 | 構成変更の採用条件 |
|---|---|---|
| 仕事の完了 | 注文特定、配送確認、返品資格判定、返金額の計算など、業務上必要な最終状態を測定する。 | 必須の完了条件を満たし、重要な入力条件や処理経路で許容できない回帰が発生していないことを確認する。 |
| 情報の保持 | 注文番号、配送完了日、適用規則、判定根拠など、後続の判断に必要な情報の受け渡しを確認する。 | 必要項目が保持され、例外時に元情報や判定根拠を確認できることを検証する。 |
| 判断の再現性 | 同じ評価課題を複数回実行し、成功率、失敗条件、処理経路の変動を確認する。 | 観測された品質差が偶発的な出力変動によるものか、構成変更に伴うものかを評価する。 |
| 応答時間 | 処理全体の経過時間、クリティカルパス、ツール応答待ち、モデル呼び出し時間を測定する。 | 同じ仕事の完了条件を満たした構成同士で、処理時間の分布と短縮幅を比較する。 |
| 実行費用 | モデル呼び出し、入力・出力トークン、ツール利用、失敗後の再実行を含む費用を集計する。 | 評価課題の構成と実行回数を揃え、仕事全体の費用を比較する。 |
| 操作の制約 | 権限外の情報取得、未承認の状態変更、不正なツール引数、重複操作に対する拒否を確認する。 | 禁止された操作が実行基盤で拒否されることを、正常系と異常系の直接テストで検証する。 |
この表では、仕事の完了品質、判断の再現性、応答時間、実行費用、操作の制約を別々に評価している。例えば、単一エージェント構成へ変更して応答時間を短縮できても、例外的な返品条件で判断の誤りが増えれば、完了品質の評価で問題が検出される。また、品質と応答時間が改善しても、未承認の返金要求を拒否する仕組みが欠落していれば、操作の制約を満たさない。複数の評価軸を分けることで、ある指標の改善が別の指標の悪化を隠すことを防げる。
Anthropic は、エージェントが利用するツールの粒度や返却情報を、実際の評価結果に基づいて調整する方法を説明している[14]。例えば、モデルが複数のツールを適切な順序で呼び出せない場合、関連する処理を一つのツールへまとめることで、呼び出し順序の判断を実行基盤側へ移せる場合がある。一方、独立して再利用される機能まで統合すると、別の処理から必要な機能だけを呼び出しにくくなる可能性がある。ツールの粒度と推論主体の分割境界は関連するが、それぞれの変更が品質と実行経路に与える影響を個別に測る必要がある。
ソフトウェア開発における SWE-bench も、モデルが修正方法を文章で説明できるかではなく、実際のソフトウェア課題に対して生成した変更が所定の評価を通過するかを測る設計の例である[15]。これは、途中の説明や推論の妥当性だけでなく、最終的な成果物の状態を評価するという点で、エージェント構成の比較にも参考になる。ただし、所定のテストを通過することが、すべての要求や運用条件を満たす保証になるわけではない。返品処理でも、通常の返金が成功するかだけでなく、期限超過、権限不足、二重返金などの条件を評価課題に含める必要がある。
構成変更の前後で比較する際には、処理を一度に大きく変更すると、結果の変化がどの変更に由来するか特定しにくくなる。例えば、注文照会と配送照会を統合すると同時に、返品資格判定の規則や返金ツールの引数まで変更した場合、品質が低下しても原因を切り分けるには追加の調査が必要になる。分割境界の変更を一つずつ適用し、各変更の前後で同じ評価課題を実行すれば、処理経路や判断結果の変化を対応付けやすくなる。変更した処理だけでなく、共通の情報やツールを利用する隣接処理も確認することで、局所的な改善が別の業務へ及ぼす影響を検出できる。
最終的な構成選択では、要求品質を満たし、必須の操作制約が実行基盤で強制されていることを確認したうえで、応答時間と実行費用を比較する。独立検証によって品質が改善する処理では、追加のモデル呼び出しや受け渡し費用を負担してでも分離を維持する理由がある。一方、同じ情報を使う逐次処理で、分離による品質上の利益が確認できなければ、共通のコンテキストへ統合することで費用を削減できる可能性がある。エージェントの数は最適化の直接的な目的ではなく、情報依存関係、品質、費用、応答時間、実行制約を満たすために選択される構成上の変数となる。
6. サブエージェントを統合する実例と比較する
処理の分割境界を情報依存関係から決定する考え方は、大規模言語モデルを使ったエージェントにも適用できる。エージェントは、モデルが現在の状態から必要な操作を選び、ツールの実行結果を受け取って判断を更新する仕組みとして構成できる。ReAct は、言語モデルによる推論と外部環境への操作を交互に実行し、観測された結果を後続の推論へ反映する方法を示した[16]。例えば、返品要求を受けたモデルが注文照会ツールを呼び出し、取得した注文情報を確認してから配送照会ツールを呼び出し、その結果に基づいて返品資格を判定する。このように、判断、操作、観測を繰り返す処理を一つの実行ループとして構成できる。
同じ仕事を複数のエージェントで実行する場合には、計画担当、注文照会担当、配送照会担当、返品判定担当などへ処理を分割し、それらを調整する仕組みを設ける構成が考えられる。調整担当は利用者の要求を解釈して適切な担当へ処理を委譲し、各担当が返した結果を集約する。担当ごとに独立したシステムプロンプト、ツール、コンテキストを保持するため、それぞれの専門処理を個別に設計できる。一方、返品判定担当が配送完了日を必要とする場合には、配送照会担当が取得した情報を受け取らなければならない。業務上の処理を担当別に分割することで、情報の受け渡しと複数の推論ループを調整する処理が追加される。
Anthropic は、あらかじめ定義した手順でモデルやツールを実行するワークフローと、モデル自身が状況に応じて操作を選択するエージェントを区別している[17]。例えば、注文番号が与えられたら必ず注文情報を取得し、その結果を使って返品期限を計算するという固定手順は、通常のプログラムによって実装できる。一方、利用者の要求が曖昧であり、注文の特定、配送状況の確認、追加質問のいずれを行うか判断する必要がある場合には、モデルによる動的な選択が役立つ。固定手順まで独立したエージェントに担当させると、プログラムで確定的に実行できる処理にもモデルの判断と呼び出し費用が発生する。
例えば、配送完了日から 30 日以内という返品規則が確定しているなら、期限の計算そのものをモデルに任せる必要はない。注文照会と配送照会で取得した日付を入力として、業務ツールが期間条件を判定できる。モデルは、利用者の要求に対してどの情報が必要かを判断し、必要なツールを呼び出す。業務上の計算や禁止条件はツール側で実行する。この構成では、判断の柔軟性が必要な部分と、入力が決まれば結果が一意に定まる処理を分けられる。モデルを一つに統合しても、業務機能まで一つの処理へ統合する必要はない。
一方、複数の推論主体を持つ構成が有利になる条件もある。Anthropic は、単一エージェントのコンテキストに不要な情報が蓄積して性能が低下する場合、複数の処理を並列に実行できる場合、専門化によってツールの選択や作業への集中が改善する場合を挙げている[18]。例えば、障害調査で大量のログを読む担当と、修正内容を判断する担当を分離すれば、ログの全文を主エージェントへ保持させずに済む。独立した文書調査では、複数の担当が異なる情報源を並列に探索できる。これらの利益が調整費用を上回る場合、複数のエージェントを維持する理由がある。
ただし、分離によって追加される費用も評価する必要がある。Anthropic は、同等の仕事を対象とした同社の検証で、マルチエージェント構成のトークン使用量が単一エージェント構成の 3～10 倍になる傾向を報告している[18]。複数の担当が共通の情報を読み込み、担当間で結果を要約し、調整担当が最終的な回答を構成するため、仕事そのものの処理以外にもトークンを消費する。この数値は Anthropic の検証条件における観察であり、すべての業務やモデルに共通する費用倍率を示すものではない。並列実行によって応答時間が短縮されても、総トークン使用量が増える場合があるため、費用と応答時間は別々に測定する必要がある。
2026 年 10 月 22 日、Anthropic の Diane Sarkis は、企業向けエージェントにおいてサブエージェントを主エージェントの実行ループへ統合した経験をまとめた[19]。この報告では、部門や専門分野ごとにエージェントを設け、それらを中央の調整担当で接続する構成が、必ずしも最適な情報配置になっていないことを指摘している。企業内で機能ごとに異なる開発チームが存在する場合、各チームが自分の専門エージェントを開発し、最後に調整担当を配置する構成になりやすい。しかし、開発組織の境界と、推論時に情報を共有すべき境界は一致するとは限らない。
例えば、顧客対応システムで注文担当、配送担当、返品担当をそれぞれ別のエージェントとして提供すると、各担当は独自の指示と応答形式を持つことになる。顧客から返品を依頼された際、注文担当が注文の存在を確認し、配送担当が配送完了日を取得し、返品担当が期限を判定する。各担当の出力が自由文であれば、調整担当は後続の処理に必要な情報を抽出して引き渡さなければならない。配送担当が「配送済み」とだけ返した場合、返品担当には期限計算に必要な日付が伝わらない。担当間の受け渡しが増えることで、情報の省略や再問い合わせが発生する構造である。
Anthropic の報告では、このような構成に伴う問題として、担当間のコンテキスト管理、サブエージェントの増加、システムプロンプト内の指示の競合、個別処理に偏った評価、応答時間の増加が挙げられている[19]。ある企業では、顧客対応に多数の専門サブエージェントを設けた結果、一貫した応答方針を維持しにくくなった。また、別の顧客による構成比較では、単一の実行ループが従来のマルチエージェント構成より約 2 倍高速に動作したと報告されている。後者は特定顧客の評価結果であり、すべてのエージェントを統合すれば同じ改善率が得られることを意味しない。
複数の担当を統合する案では、主エージェントが一つのコンテキストで計画と判断を継続し、必要な外部機能をツールとして呼び出す。例えば、注文番号を特定した主エージェントは、注文照会と配送照会を実行し、取得した注文日や配送完了日を保持する。その情報を使って返品資格を判断するため、別のエージェントへ結果を要約して引き渡す処理を減らせる。追加の確認が必要になった場合も、主エージェントが既に取得した情報を参照して判断を更新できる。情報を必要とする複数の判断を同じ実行ループに配置することで、処理間の受け渡し費用を削減する構成である。
ただし、専門機能を一つの実行ループへ統合すると、主エージェントが参照する指示やツールの数が増える可能性がある。すべての専門手順、業務規則、ツール定義をシステムプロンプトへ常時含めれば、返品処理に必要のない情報までモデルの入力に加わる。コンテキストが長くなることで処理費用が増えたり、適切なツールを選択しにくくなったりする可能性がある。専門エージェントを減らす代わりに、すべての専門知識を常時読み込む構成では、統合による利益が限定される場合がある。
そこで Anthropic は、必要になった時点で情報や機能を読み込む段階的な取得方式を提案している[19]。専門的な作業手順は Skills に配置し、外部データの取得や操作はツールに配置する。主エージェントは、利用可能な機能の短い説明を参照し、実際に必要なものだけを読み込む。例えば、返品要求に対応するときは返品規則に関する Skill を読み込み、注文照会と配送照会のツールを利用する。利用者が配送先の変更を要求した場合には、別の手順とツールを選択する。専門知識を機能別に管理しながら、利用者との対話と判断に必要な情報を主エージェントへ保持できる。
この構成における Skills は、専門処理の進め方や判断時に確認すべき事項をモデルへ伝える役割を持つ。一方、ツールは外部システムからの情報取得や、実際の業務操作を担当する。例えば、返品規則を確認する手順は Skill に記述できるが、返金可能期間の判定に使う現在の配送記録は業務システムから取得する必要がある。また、未承認の返金を禁止する条件は、モデルが従うべき指示として説明するだけでなく、返金ツール側で検査する必要がある。専門知識、実行時のデータ、強制的な制約を異なる場所へ配置することで、主エージェントへ判断を集約しながら、業務上の制御を維持できる。
ツールの数にも注意が必要になる。Anthropic は、多数のツール定義をシステムプロンプトへ同時に含めると、適切なツールを選択する性能が低下する傾向を報告している[19]。同資料では、30～50 件を超えるツール定義を一度に扱う場合に、必要なものを検索して読み込む方式を推奨している。この数値はモデルやツール設計にかかわらず適用できる固定的な上限ではなく、同社の経験に基づく設計上の目安である。専門エージェントを統合した結果、主エージェントが大量のツールを常時参照する構成になれば、情報の受け渡し費用が減ってもツール選択の品質が低下する可能性がある。
統合と分離の判断では、サブエージェントが独立したコンテキストを必要とする理由を具体的に確認する。例えば、調査担当が大量のログや文書を読み、主エージェントには数項目の結論と根拠だけを渡せばよい場合、調査担当を独立させることで主エージェントの入力を小さく保てる。逆に、主エージェントが調査過程の詳細を何度も参照する必要がある場合には、要約を受け取るたびに元情報を再取得する費用が発生する。元の情報量が大きいことだけで分離を決めるのではなく、後続の判断がどの程度の情報を必要とするかを確認する必要がある。
また、独立したサブエージェントを維持する場合でも、その担当が利用者との会話全体を引き継ぐ必要があるとは限らない。例えば、障害調査担当へログと調査条件を渡し、障害原因の候補と根拠を構造化された結果として返す構成が考えられる。主エージェントは利用者との対話を継続し、必要に応じて調査担当をツールとして呼び出す。この方法では、調査担当のコンテキストを隔離しながら、利用者への回答と後続の判断を主エージェントへ集約できる。ただし、調査担当の内部でもモデル呼び出しが発生するため、独立した推論ループの費用は残る。
返品処理と独立した調査処理を例に、統合と分離の成立条件を整理する。
| 判断対象 | 主エージェントへ統合する条件 | 分離を維持する条件 |
|---|---|---|
| 情報取得と判定 | 注文・配送情報を複数の判断で繰り返し利用し、同じコンテキストで保持することで再取得や受け渡しを削減できる。 | 大量の検索結果やログを独立して処理し、後続の判断に必要な情報を構造化した結果として返せる。 |
| 処理順序 | 先行処理の結果を受けて計画を更新し、共通の現在状態に基づいて後続の操作を選択する。 | 互いの中間結果に依存する必要がなく、独立した処理を並列実行することで応答時間を短縮できる。 |
| 専門知識と手順 | 必要な専門手順を Skills として読み込み、外部システムの操作をツールとして呼び出すことで、独立した推論ループを省略できる。 | 専門処理が独立した判断過程を必要とし、主エージェントへすべての情報を渡すと品質や処理量に不利益が生じる。 |
| ツールの選択 | 必要なツールを検索して段階的に読み込めるため、主エージェントが適切な機能を選択できる。 | ツール選択の誤りや指示の競合が実測され、専門処理の分離によってその問題を低減できる。 |
| 独立検証 | 同じ事実の整合性確認など、共通情報を使って一つの判断過程で確認できる。 | 先行判断とは異なる証拠や検証手順を必要とし、独立した判断によって誤りの検出率が改善する。 |
| 権限管理 | ツールや実行基盤が利用者権限と承認条件を検査し、主エージェントからの不正な操作を拒否できる。 | 実行環境や資格情報の隔離が必要であり、単一の実行ループでは要求される分離条件を満たせない。 |
この比較から、サブエージェントを残す理由を、担当する専門分野の違いだけで説明することには限界がある。例えば、注文照会担当と配送照会担当が別のチームによって開発されていても、主エージェントから両方のツールを利用できれば、専門機能の分離を維持したまま推論時の情報を共有できる。一方、独立したセキュリティ検証が必要な場合には、同じ主エージェントのコンテキストで判断を継続すると、先行する推論や誤った前提が検証結果へ影響する可能性がある。専門機能を維持するための境界と、推論の独立性を確保するための境界は、異なる条件で設定される。
実行権限についても、推論主体を分けることと実際の操作権限を分離することは区別できる。主エージェントが返金要求を判断する場合でも、返金ツール側で注文番号、資格判定、承認状態を検査すれば、必要な条件を満たさない操作を拒否できる。ただし、特定の処理に対して実行環境や資格情報そのものを隔離する要件がある場合には、ツールによる承認条件の検査だけでは十分とは限らない。その場合は、別の実行環境や権限境界を維持する必要がある。モデルのコンテキストを統合するかどうかと、実行基盤の権限境界をどこに設けるかは、別々に設計できる。
Anthropic の移行方針では、既存のサブエージェントを一度にすべて統合するのではなく、利用頻度や情報の共有関係を確認し、統合候補を一つずつ変更して評価することを推奨している[19]。例えば、注文照会担当と配送照会担当が連続して呼び出される頻度が高く、両者の情報を返品資格判定が利用しているなら、これらを統合する候補として扱える。一方、配送障害の詳細調査が大量のログを必要とし、主エージェントには原因候補と根拠だけを返せばよい場合には、その調査担当を維持する理由がある。呼び出し頻度、参照する情報、独立性の必要性を確認することで、組織上の担当区分とは異なる分割境界を選択できる。
統合後に品質が維持されるかは、実際の仕事の完了条件によって確認する必要がある。例えば、注文照会と返品判定を統合した結果、モデルが配送照会を省略して返品可否を回答するようになれば、モデル呼び出し回数や応答時間が減少しても、その変更は品質上の回帰を含む。逆に、同じ情報を何度も取得していた処理を統合し、返品資格と返金額の正確性を維持できれば、情報の再取得と調整費用を削減した構成として評価できる。統合の採否は、サブエージェントを削減できた数ではなく、仕事の完了品質と処理費用の変化から決定する。
Anthropic の事例は、モデル能力の向上や段階的な情報取得によって、従来は独立したサブエージェントが必要と考えられていた処理の一部を、共通の実行ループへ移せることを示している。ただし、そこで報告された品質や応答時間の改善は、対象となった企業システムと評価条件に依存する。並列調査、独立検証、大量情報の処理では、分離を維持する利益も残る。情報を共有する利益と独立した処理の利益を比較し、実際の評価結果によって分割境界を更新するという判断が、単一エージェントとマルチエージェントのどちらにも適用できる。
7. 分割境界を変更したときの回帰をどう検出するか
サブエージェントを統合すると、主エージェントが利用できるツール、参照情報、判断の順序が変わる。例えば、従来は注文照会担当が注文番号を特定し、配送照会担当が配送完了日を取得し、返品判定担当が期間条件を確認していたとする。これらの処理を一つのエージェントへ統合すれば、注文情報と配送情報を同じコンテキストで利用できるようになる。一方、主エージェントが注文情報だけで返品資格を判断できると考えた場合、配送完了日の取得を省略してしまう可能性がある。モデル呼び出し回数や応答時間が減っても、必要な確認が省略されれば、業務上の正確性は低下する。
このような回帰は、統合した処理だけを評価していても検出できない場合がある。注文照会の結果が正しく取得され、返品資格判定の処理自体も正常に終了していれば、各処理の単体評価では成功と判定される可能性がある。しかし、返品資格の判定基準が配送完了日から 30 日以内である場合、配送完了日を確認せずに結論を出すことは、必要な判断条件を満たしていない。処理の分割境界を変更すると、個々の機能の実装を維持していても、それらを組み合わせる順序や情報の利用方法が変化する。構成変更の影響は、変更した処理と、その前後に接続する処理を含めて評価する必要がある。
7.1 処理単位の評価と業務全体の評価を区別する
返品処理では、注文の特定、配送状況の確認、返品資格の判定、返金額の算出、返金の確定という複数の処理が連鎖する。各処理が正しい結果を返していても、必要な処理が呼び出されなければ仕事全体は正しく完了しない。例えば、注文照会が注文日を返し、主エージェントがその日付を使って返品期限を計算した場合、計算そのものが正しくても、配送完了日を基準とする返品規則には適合しない。誤りの原因は日付計算の実装ではなく、計算に使用する情報を選択した判断にある。
この違いを検出するには、最終的な判定結果に加えて、必要な情報が取得され、その情報が正しい処理へ渡されたかを確認する。例えば、返品資格の判定が正しいという結果だけでは、配送完了日を実際に確認したかは分からない。注文日と配送完了日が近い場合、誤った基準日を使っても同じ判定結果になることがある。注文日と配送完了日が大きく離れた評価課題を含めれば、どちらの日付を使ったかによって判定が変わるため、情報の選択に関する誤りを検出しやすくなる。
仮に注文日が 9 月 1 日、配送完了日が 10 月 10 日、返品申請日が 10 月 25 日とする。返品期限が配送完了日から 30 日以内なら、申請日は配送完了日から 15 日後であり、期間条件を満たす。一方、注文日から計算すると 54 日が経過しており、期間条件を満たさないと判定される。この評価課題では、注文日と配送完了日を取り違えた場合に異なる結果が得られるため、誤った情報を使用した処理を識別できる。実際の返品資格は商品条件などにも依存するが、期間条件だけを検証する課題としては、使用した基準日の違いを明確にできる。
さらに、最終的な判定が正しい場合でも、必要な情報を取得せずに推測していないかを確認する必要がある。例えば、注文日と配送完了日が偶然同じであれば、注文日を使った誤った手順でも正しい結果になる可能性がある。この場合、最終結果だけを採点する評価では、正しい情報を使用した処理と偶然正解した処理を区別できない。実行履歴から配送照会の呼び出し、取得した日付、返品判定に使用した値を確認することで、正解に至った経路を検証できる。
ただし、特定のツールを呼び出した回数だけを成功条件にすると、別の正しい実装を誤って失敗と判定する可能性がある。例えば、注文照会ツールが配送完了日を信頼できる情報として返す仕様であれば、配送照会ツールを別途呼び出す必要はない。評価すべき条件は、指定されたツールを必ず使用したことではなく、必要な情報が信頼できる情報源から取得され、正しい判断に利用されたことである。業務上の必須条件と、特定の実装に依存する処理経路を分けて評価することで、構成変更による合理的な経路の短縮と、必要な確認の省略を区別できる。
7.2 段階的な統合と変更前後の比較
Anthropic が公開した Single Agent Loop Kit は、既存のマルチエージェント構成を評価し、必要に応じて単一の実行ループへ移行するための参考実装である[20]。この実装では、既存のエージェントと処理経路を調査し、変更前の評価結果を取得した後、複数のサブエージェントの統合や、専門機能の Skills・ツールへの移行を一つずつ実施する。各変更について同じ評価課題を実行し、変更前後の結果を比較する構成になっている。すべてのサブエージェントを最初から統合するのではなく、変更によって品質が維持されるかを確認しながら、分割境界を段階的に更新する方法である。
この方法では、最初に既存の構成を把握する必要がある。例えば、返品処理に注文照会担当、配送照会担当、返品判定担当が存在する場合、それぞれがどのツールを利用し、どの情報を取得し、どの担当へ結果を引き渡すかを確認する。さらに、実行履歴から各担当の呼び出し頻度や連続して呼び出される組み合わせを調べることで、統合候補を選択できる。注文照会担当と配送照会担当が常に連続して呼び出され、両者の結果を返品判定担当が必要とするなら、情報の共有と受け渡しの削減という観点から統合を検討できる。
ただし、呼び出し頻度が高いことだけでは、統合による品質維持を保証できない。例えば、配送照会担当が大量の配送履歴を参照し、返品判定担当には配送完了日だけを返している場合、独立したコンテキストを維持する利益がある。反対に、配送照会担当が単一のツールを呼び出して結果を短く整形するだけなら、独立したモデルの推論ループを維持する必要性は小さい可能性がある。既存の呼び出し経路を調査する目的は、利用頻度だけでなく、各担当が独立したコンテキストを必要とする理由を明確にすることにある。
統合前の評価では、個々の担当の動作に加えて、複数の担当が連続して実行される課題を含める必要がある。例えば、注文照会と配送照会の統合を予定している場合、注文情報だけで完了する課題と、配送完了日を必要とする返品判定の課題を用意する。さらに、返品資格判定の結果を返金確定へ渡す課題も含めることで、統合対象の前後に接続する処理への影響を確認できる。統合後に注文照会の成功率が維持されても、返品判定や返金確定に失敗が発生するなら、変更が処理連鎖へ影響した可能性がある。
Single Agent Loop Kit では、実行履歴に現れるサブエージェントの処理連鎖と、評価課題が対象とする処理連鎖を照合する仕組みも用意されている[20]。統合対象を含む処理連鎖が評価課題で確認できない場合、その変更について十分な回帰検証を実施できない。例えば、注文照会と返品判定を統合する際に、配送照会を経由する課題が評価対象に存在しなければ、配送情報の受け渡しが失われても評価結果に反映されない可能性がある。構成変更によって影響を受ける経路を先に特定し、それぞれの成立条件を評価課題へ対応付ける必要がある。
変更前後の比較では、同じ評価課題、採点条件、モデル、実行環境を使用することが基本になる。異なる課題や採点条件で得られた結果を比較すると、品質差が構成変更に由来するのか、評価条件の違いによるものかを識別しにくくなる。また、生成モデルの出力には変動があるため、必要に応じて同じ課題を複数回実行する。変更前後で成功した回数が異なる場合には、失敗した実行履歴を確認し、必要な情報の欠落、ツール選択の誤り、処理順序の変更など、結果が変わった直接原因を調べる。
7.3 統合した処理の周辺で発生する回帰
サブエージェントを統合した結果、統合対象ではない処理の経路が変化する場合がある。例えば、従来の構成では主エージェントが注文照会担当から注文情報を受け取り、その後に配送照会担当へ配送完了日を問い合わせていたとする。注文照会担当を主エージェントへ統合すると、主エージェントは注文照会ツールを直接利用できるようになる。この変更によって、主エージェントが配送照会担当を呼び出さず、注文照会の結果だけで返品資格を判断する可能性が生じる。
Single Agent Loop Kit の公開評価例でも、統合後に主エージェントが利用できるツールの変化によって、隣接する専門処理への委譲が省略される回帰が観測されている[20]。これは、統合対象の専門処理に関する評価だけでは検出しにくい失敗である。変更後の主エージェントは、以前より多くの情報へ直接アクセスできるため、別の専門担当が取得すべき情報まで揃っていると判断する場合がある。実際には必要な確認が残っていても、処理の途中で回答を確定すれば、隣接する業務の品質が低下する。
この回帰を検出するには、統合対象の評価課題に加えて、共通のツールや情報を利用する周辺業務の評価課題を実行する必要がある。例えば、注文照会担当を統合した場合、注文照会そのものだけでなく、配送状況の確認、返品資格の判定、返金額の算出なども確認する。統合対象のツールが主エージェントから直接利用可能になったことで、どの処理への委譲が減り、どの情報取得が省略されたかを実行履歴から調べる。変更した機能が正常でも、変更によって別の機能の呼び出し条件が変わっていれば、システム全体の動作は変化している。
処理経路の変化が常に回帰であるとは限らない。統合前に複数回取得していた注文情報を一度の照会で共有できるようになれば、情報の取得回数が減ることは合理的な改善である。一方、返品可能期間の基準日を確認する処理まで省略されれば、必要な判断条件が欠落する。経路の短縮を評価する際には、省略された処理が重複した情報取得だったのか、必須の確認だったのかを区別する必要がある。実行履歴と業務上の完了条件を対応付けることで、処理の効率化と判断品質の低下を識別できる。
分割境界の変更によって確認すべき代表的な失敗と検証方法を整理する。
| 変更対象 | 確認すべき失敗 | 必要な検証 |
|---|---|---|
| 注文照会と資格判定の統合 | 配送完了日を確認せず、注文日など別の情報を使って返品可能期間を判定する。 | 注文日と配送完了日が異なる課題を使用し、基準日の取得と判定への利用を確認する。 |
| 専門エージェントのツール化 | 返却情報から判定根拠や必須項目が欠落し、後続処理が必要な判断を完了できない。 | 返却値の形式、必須項目、元情報との整合性を確認し、後続処理まで実行する。 |
| 権限判定の移動 | モデルが未承認の操作を選択した際、実行基盤が拒否せず状態を変更する。 | 権限不足、承認なし、不正な対象指定などの入力でツールを直接呼び出し、拒否されることを確認する。 |
| コンテキストの共有 | ある業務で取得した情報だけで別の業務を早期に完了と判断し、必要な追加確認を省略する。 | 共通情報を使用する隣接業務と複数処理にまたがる課題を再評価し、実際の情報取得経路を確認する。 |
| 並列実行への変更 | 先行処理の結果が確定する前に後続処理が実行され、古い情報や未確定の状態を使用する。 | 処理順序と待ち合わせ条件を確認し、応答順序が変化する条件でも最終結果が正しいことを検証する。 |
| 独立検証の統合 | 検証担当が先行判断の推論経路を共有し、従来検出できた誤りを見逃す。 | 意図的な誤りを含む課題を使用し、統合前後の誤り検出率と検証根拠を比較する。 |
表の各項目は、構成変更によって発生し得る失敗の種類が異なることを示している。情報の欠落は後続判断の入力を不完全にし、ツールの選択変更は必要な確認を省略する可能性を生む。並列実行への変更では、処理順序や待ち合わせ条件が結果に影響する。独立検証を統合した場合には、先行判断と検証判断が共通の誤りに依存する可能性もある。これらを一つの完了率だけで評価すると、失敗の発生箇所と原因を区別しにくくなる。
7.4 品質評価と実行制約の検証を分離する
構成変更の評価では、モデルが正しい判断を選択できるかという問題と、誤った判断を選択した場合に実行基盤が禁止操作を拒否できるかという問題を分ける必要がある。例えば、返品資格を満たさない注文に対してモデルが返金ツールを呼び出さなかった場合、その評価からはモデルが適切な判断を選択したことを確認できる。しかし、モデルが誤って返金ツールを呼び出したときに、ツール側の制約が正常に動作するかまでは確認できない。
返金ツールの承認条件を検証するには、資格判定が未完了の注文、承認が存在しない注文、返金額が許容範囲を超える要求などを直接入力する。ツールが禁止された操作を拒否すれば、モデルの判断に依存せず実行制約が機能していることを確認できる。返金済みの注文に同じ要求を送った場合の処理も、業務上の重複操作を防ぐための検証対象になる。通常のエージェント評価で禁止操作が発生しなかったことと、禁止操作を実行できない仕組みが存在することには、異なる根拠が必要である。
Single Agent Loop Kit でも、プロンプト上の制約をツール側へ移す場合、禁止条件を満たす入力でツールを直接呼び出し、拒否されることを単体テストで確認する方法が示されている[20]。これは、モデルが禁止操作を選択しないという期待を、ツールが禁止操作を実行しないという検証可能な条件へ置き換える方法である。サブエージェントを統合した結果、主エージェントが利用できるツールの範囲が広がる場合には、ツールの呼び出し権限と実行条件を再確認する必要がある。
実行基盤の制約は、個別の処理を統合しても維持できる。例えば、返品資格判定と返金額の計算を一つのエージェントで実行しながら、返金確定の権限は業務システム側で検査する構成が考えられる。主エージェントが返金確定を要求しても、承認条件が成立していなければ操作を拒否できる。一方、サブエージェントごとに異なる実行環境や資格情報を用意していた場合、それらを統合することで従来の権限分離が失われる可能性がある。推論コンテキストの統合と実行権限の統合を区別し、必要な権限境界を維持した状態で品質と費用を比較する必要がある。
7.5 公開された参考実装で確認できる範囲
Single Agent Loop Kit の README では、顧客サポートを模したサンプルについて、実際のモデルを使用した評価が 2 回記録されている[20]。最初の評価では 12 件の課題を使用し、返品処理に関するサブエージェントの統合を扱っている。次の評価では 17 件の課題を使用し、別の専門処理をツールとして呼び出す構成を扱っている。どちらも、一人の実施者が同一モデルを使用して記録した評価である。
一方、README には、完成した単一エージェント構成全体、複数のサブエージェントをまとめる工程、継続的な保守に関する工程などについて、実モデルによる検証が行われていないことも明記されている。また、参考実装の一部には、実モデルによる評価後に修正され、オフラインのテストだけが実行されている箇所がある。公開されている結果は、段階的な変更と評価の具体的な方法を確認するための資料であり、単一エージェント構成が一般的に優れていることを実証するものではない。
この区別は、実務で構成変更を判断する際にも当てはまる。例えば、顧客サポートのサンプルで返品処理の統合が成功したとしても、企業内の障害調査やソフトウェア開発でも同じ結果が得られるとは限らない。仕事に必要な情報量、並列実行の可能性、利用するツール、業務上の制約が異なるためである。導入先のシステムで既存の処理経路を確認し、そのシステムの完了条件に対応した評価課題を用意する必要がある。公開された参考実装は評価手順の設計に利用できるが、統合の採否を決める根拠は対象システムで測定した結果から得られる。
特に、変更前に成功していた課題が変更後に失敗した場合、その失敗が統合した処理の内部で発生したのか、隣接する処理への委譲が省略されたのか、必要な情報が受け渡されなかったのかを調べる必要がある。失敗原因が明確になれば、ツールの返却形式や選択条件を修正するか、サブエージェントを維持するかを判断できる。複数回の評価で結果が安定しない場合には、試行回数を増やして差の再現性を確認する。統合による改善が確認できない場合、既存の分割を維持することも合理的な選択である。
処理の分割境界を変更することで、情報の受け渡し回数やモデル呼び出し回数を減らせる可能性がある。しかし、主エージェントが参照できる情報やツールが変われば、従来とは異なる処理経路を選択する可能性も生じる。評価対象を個々のサブエージェントから業務上必要な処理連鎖へ広げることで、統合による効率化と、必要な確認の省略による品質低下を区別できる。最終的な仕事の完了条件、情報の利用経路、実行制約を検証し、その条件を満たした構成同士で費用と応答時間を比較することが、分割境界の変更を採用するための判断基準となる。
8. 分割境界は固定された設計原則ではない
処理の分割境界は、機能ごとの役割だけで決まるものではない。複数の処理が同じ情報を必要とする場合、その情報を共有することで再取得や受け渡しを削減できる。一方、独立した処理を並列に実行する場合や、先行する判断を別の証拠によって検証する場合には、情報と推論の経路を分離する利益がある。どちらの構成が適切かは、処理間の情報依存関係、実行順序、判断品質、業務上の制約によって変わる。機能の分割と推論コンテキストの分割を区別することで、専門機能を維持したまま、判断に必要な情報の配置を変更できる。
返品処理の例では、注文照会、配送確認、資格判定が同じ注文に関する情報を繰り返し参照する。注文番号、配送完了日、適用する返品規則を共通のコンテキストで保持すれば、各処理の間で同じ情報を再取得する回数を減らせる。例えば、配送完了日が 10 月 10 日、返品申請日が 10 月 25 日である場合、返品資格判定は配送完了日からの経過日数を計算し、適用規則と照合する。注文日と配送完了日を別々の担当が保持する構成では、後続の判定に必要な日付を明示的に受け渡す必要がある。一つの判断コンテキストで両方の情報を保持する構成では、この受け渡しを省略できる。ただし、モデルが正しい基準日を選択したことは、統合後も検証する必要がある。
返金確定のように業務データを変更する処理では、情報の共有と操作の許可を分けて考える必要がある。主エージェントが注文情報、返品資格、返金額を参照できても、それだけで返金を実行できる構成にする必要はない。返金ツールが操作主体の権限、対象注文、承認状態、返金済みかどうかを確認し、条件を満たした場合にだけ状態を変更する構成を維持できる。この場合、推論に必要な情報は共有しながら、操作に必要な条件は実行基盤で強制される。推論主体を統合したことによって、業務機能の独立性や承認条件まで失われるわけではない。
一方、大量の文書を調査する処理では、異なる分割境界が合理的になる。例えば、障害原因を調べるためにアプリケーションのログ、データベースの実行記録、外部サービスの応答履歴を確認する場合、それぞれの調査担当が独立した情報源を参照できる。複数の調査を並列に進めれば、逐次実行する場合より早く必要な証拠を収集できる可能性がある。また、各担当が大量の記録を読み、原因候補、発生時刻、根拠となる記録の位置を構造化して返せば、主エージェントがすべての記録を直接保持する必要は小さくなる。調査対象の情報量が大きく、後続の判断に必要な結果を限定できる場合には、コンテキストを分離する利益が生まれる。
ただし、障害原因の候補を比較するために、複数のログを時系列で照合する必要がある場合もある。アプリケーションの処理開始時刻、データベースの応答遅延、外部サービスのエラー発生時刻を組み合わせなければ、原因と結果の関係を判断できないことがある。各調査担当が「異常あり」という結論だけを返すと、主エージェントは異常の発生順序を確認できない。この場合、各担当が必要な時刻や根拠を返すよう受け渡し形式を定義するか、主エージェントが詳細を再取得できる経路を設ける必要がある。調査を分離する利益は、後続の判断に必要な情報を保持できる範囲で成立する。
独立検証では、情報の重複が大きくても分離を維持する理由がある。例えば、コード修正を行ったエージェントと、その変更を検証するエージェントが同じ要求仕様と変更差分を参照していても、検証担当が別のテストや独立した確認手順を実行することで、修正担当が見落とした条件を発見できる可能性がある。共通の情報を参照すること自体が検証の独立性を失わせるわけではない。先行する原因仮説や結論を無条件に受け入れず、異なる根拠や実行結果で確認できることが独立検証の成立条件になる。複数のエージェントを設けても、同じ誤った前提を共有していれば、誤判断が繰り返される可能性は残る。
このように、処理の分割境界には、必要情報の重複、先行処理への依存、並列化の可能性、検証の独立性という異なる条件が関係する。情報の重複が大きい場合でも、独立検証の利益が確認できれば分離を維持する理由がある。反対に、専門分野が異なる処理であっても、同じ情報を使って逐次的に判断し、独立したコンテキストを必要としなければ、共通の実行ループへ統合する候補になる。処理を分ける理由を機能名や担当組織から判断するのではなく、実行時に何を共有し、何を独立させる必要があるかから判断できる。
この判断は、利用するモデルやツールの能力によっても変化する。例えば、従来のモデルでは大量のツール定義を同時に与えると選択を誤りやすく、専門分野ごとにツールを分離する必要があったとする。その後、必要なツールを検索して段階的に読み込める仕組みが導入されれば、主エージェントが常時保持するツール定義を増やさずに、利用できる機能の範囲を広げられる。以前は独立した専門エージェントが必要だった処理でも、主エージェントから必要な機能だけを呼び出す構成が成立する可能性がある。ただし、ツールを検索できることと、適切なツールを常に選択できることは異なるため、実際の処理品質を確認する必要がある。
逆に、統合した処理が新たに大量の情報を扱うようになれば、分離する利益が増える場合もある。例えば、当初は注文情報と配送状況だけを取得していた返品処理に、商品画像の確認、過去の問い合わせ履歴の検索、不正利用の調査が追加されたとする。主エージェントがこれらの情報をすべて保持すると、入力トークン数や必要情報を探す処理が増える。画像や問い合わせ履歴の分析を独立した処理に任せ、必要な判定結果と根拠だけを受け取る構成へ変更すれば、主エージェントが保持する情報を限定できる。業務要件の追加によって、以前は合理的だった統合境界を見直す理由が生まれる。
分割境界を変更する際には、実行費用と応答時間だけでなく、仕事の完了条件を維持できるかを確認する。例えば、統合によってモデル呼び出し回数が減少しても、配送完了日の確認を省略する回帰が発生すれば、返品資格判定の品質は低下する。一方、分離によって独立検証を追加しても、従来検出できなかった誤りを発見できず、処理費用と応答時間だけが増える場合には、その分離を維持する利益は限定される。構成の優劣は、エージェント数の増減から直接判断するのではなく、同じ評価課題に対する結果の違いから確認する必要がある。
また、完了率が同じ構成でも、失敗が発生する条件は異なる場合がある。例えば、統合前後の構成がそれぞれ 100 件中 95 件の返品要求を正しく処理したとしても、統合後だけで配送完了日の確認漏れが発生していれば、処理経路の変更による回帰が存在する。逆に、統合後に重複した注文照会が削減され、必要な配送情報が正しく利用されているなら、情報共有による改善を確認できる。評価課題ごとの結果、使用した情報、実行したツール、禁止操作の拒否を対応付けることで、品質の維持と処理の効率化を分けて判断できる。
実行環境の変化に応じて分割境界を再評価する場合も、比較条件を維持する必要がある。モデルを更新すると、同じプロンプトやツール定義でも判断結果が変わる可能性がある。業務規則を変更すると、以前は十分だった要約に必要な情報が含まれなくなる場合がある。ツールの返却形式を変更すると、主エージェントが直接利用できる情報も変化する。これらの変更によって構成の品質が変わった場合、モデル、業務規則、ツール、分割境界のどの変更が結果に影響したかを確認できるようにする必要がある。変更前後で評価課題と完了条件を揃えることが、構成を更新する判断の前提になる。
最適化の対象として見れば、エージェント数は費用、応答時間、品質、制約遵守に影響する設計上の変数の一つである。情報を共有することで費用が減少しても、必要な独立性が失われれば品質制約を満たさなくなる場合がある。分離によって品質が改善しても、追加の処理費用が業務上許容される範囲を超える場合には、別の構成を検討する必要がある。ただし、未承認の返金や権限外の情報取得のような禁止操作は、費用や応答時間との交換条件にせず、実行基盤で強制する制約として維持する。この条件の下で、要求品質を満たす構成同士の費用と応答時間を比較できる。
分割境界を固定的な設計原則として扱うと、構成を導入した時点のモデル能力や業務条件が変わっても、以前の役割分担を維持し続けることになる。その結果、必要性が小さくなったサブエージェントを呼び出し続けたり、新たに独立性が必要になった処理を共通のコンテキストへ保持し続けたりする可能性がある。既存の分割には、その構成が採用された理由がある一方、現在の条件でも同じ利益が得られているかは測定によって確認する必要がある。分割境界を変更する際には、既存構成の品質を基準として、変更によって失われる条件と新たに得られる利益を比較することが合理的である。
仕事を分けるべき境界は、複数の処理が同じ情報を必要とする場所と、独立した実行や検証によって利益が得られる場所の関係から決まる。返品処理では、注文情報や配送情報を共有する利益が大きく、返金の承認条件は実行基盤へ保持できる。大量の文書調査では、独立した探索とコンテキストの隔離によって処理時間や入力情報量を削減できる場合がある。独立検証では、先行判断とは異なる証拠や手順を利用できることが分離の理由になる。これらの条件を品質、費用、応答時間、実行制約と対応付けて測定することで、統合すべき処理と分離を維持すべき処理を選択できる。分割境界を繰り返し評価できることが、モデル能力や業務条件の変化に対応しながら、必要な品質と制約を維持するための条件となる。
参考文献
- David L. Parnas, On the Criteria to Be Used in Decomposing Systems into Modules（1972-12-01）. https://doi.org/10.1145/361598.361623
- id774, AI に仕事を任せるには、モデルの外側を設計する（2026-08-21）. https://blog.id774.net/entry/2026/08/21/5544/
- id774, 方針を実行構造へ変換するエージェント設計（2026-10-20）. https://blog.id774.net/entry/2026/10/20/5744/
- Claude E. Shannon, A Mathematical Theory of Communication（1948-07）. https://doi.org/10.1002/j.1538-7305.1948.tb01338.x
- Naftali Tishby, Fernando C. Pereira, William Bialek, The Information Bottleneck Method（2000-04-24）. https://arxiv.org/abs/physics/0004057
- Nelson F. Liu et al., Lost in the Middle: How Language Models Use Long Contexts（2023-07-06）. https://arxiv.org/abs/2307.03172
- Anthropic, Effective context engineering for AI agents（2025-09-29）. https://www.anthropic.com/research/effective-context-engineering-for-ai-agents
- Gene M. Amdahl, Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities（1967-04-18）. https://doi.org/10.1145/1465482.1465560
- Jeffrey Dean, Sanjay Ghemawat, MapReduce: Simplified Data Processing on Large Clusters（2004）. https://research.google/pubs/mapreduce-simplified-data-processing-on-large-clusters/
- Anthropic, How we built our multi-agent research system（2025-06-13）. https://www.anthropic.com/research/multi-agent-research-system
- Anthropic, Multi-agent coordination patterns: Five approaches and when to use them（2026-04-10）. https://claude.com/resources/articles/multi-agent-coordination-patterns
- id774, 安全判定の揺らぎを入力・構造・評価方法に分けて測る（2026-10-21）. https://blog.id774.net/entry/2026/10/21/5796/
- Elham Tabassi, Artificial Intelligence Risk Management Framework (AI RMF 1.0)（2023-01-26）. https://doi.org/10.6028/NIST.AI.100-1
- Anthropic, Writing effective tools for agents — with agents（2025-09-11）. https://www.anthropic.com/research/writing-tools-for-agents
- Carlos E. Jimenez et al., SWE-bench: Can Language Models Resolve Real-World GitHub Issues?（2023-10-10）. https://arxiv.org/abs/2310.06770
- Shunyu Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models（2022-10-06）. https://arxiv.org/abs/2210.03629
- Anthropic, Building effective agents（2024-12-19）. https://www.anthropic.com/research/building-effective-agents
- Anthropic, Building multi-agent systems: When and how to use them（2026-01-23）. https://claude.com/resources/articles/building-multi-agent-systems-when-and-how-to-use-them
- Diane Sarkis, Building agents: When to fold subagents into your main agent loop（2026-10-22）. https://claude.com/ja/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop
- Anthropic, Single agent loop kit. https://github.com/anthropics/single-agent-loop-kit