問い

次のエージェントは、渡された値を何として信用するか

社員が「営業用のアカウントを、プロジェクトの間だけ使いたい」と申請する。 最初のエージェントは部署名と役割と期限を読み取り、次のエージェントは申請書を作る。 ところが「営業」が部署の正式名称なのか、利用目的なのかは未確認だった。 この想定例では、整った形式で値を渡すほど、前段の推定が後段で確定済みの事実に見える危険がある。

11月25日に発表されたFoundry Agent Serviceの複数エージェントワークフローは、図とYAML、変数、構造化出力で工程をつなぐ公開プレビューである。 担当名と矢印だけでなく、何を次へ渡し、どの条件で分岐するかを定義する部品が示された。 これにより、複数エージェントの受け渡しを、実装者以外も確認する対象にできる。

本稿が重視するのは、値を渡せることに加え、その値の意味と根拠を渡すことだ。 申請文から読み取った値、台帳で確かめた値、まだ推定の値、管理者が許可した内容を分ける。 後段が何を信用してよいかを明確にすることが、役割を増やす前に必要な設計になる。

公開機能

図とYAMLで、受け渡しと分岐を確認する

Foundryの発表は、視覚的な編集とYAML定義が相互に更新され、エージェントの出力をローカル変数へ保存して後段で参照できると説明する。 出力の形にはJSON Schema、条件分岐や変換にはPower Fx式を使う。 保存ごとの不変版も説明されている。 これは、曖昧な会話だけで作業を引き継ぐ方法とは異なり、受け渡す項目と分岐条件を明示する仕組みである。

アカウント申請なら、部署の照合が終わった場合と、候補が複数ある場合を別の経路にできる。 図を見る担当者は、部署を読み取る工程から、登録する工程へ直接進んでいないかを確認できる。 YAMLを見る開発者は、次の工程へどの変数を渡すかを調べられる。 この例の具体的な項目や経路は、本稿の提案であって、製品に用意された申請処理ではない。

ただし、定義は可能な経路を示すもので、実行済みの事実ではない。 不変の手順版があっても、参照する台帳が変われば、同じ申請への照合結果は変わり得る。 受け渡しの定義を保存することと、どの入力・資料でその値が得られたかを残すことを分けて考えたい。

型の限界

文字列として正しくても、部署として正しいとは限らない

JSON Schemaは、項目の型や必須項目など、データの構造に条件を付けるための仕組みである。 部署名を文字列、役割を配列にそろえることには意味がある。 後段が想定外の形を受け取り、処理できなくなる失敗を減らせるためだ。 しかし、存在しない部署名も文字列としては正しく、配列に並んだ役割がその社員に適するかは別に確かめる必要がある。

有効期限にも注意が要る。 JSON Schema Draft 2020-12の検証仕様は、formatを注釈として扱う場合と、値の適合を検査する場合を分ける。 日付の形式を指定するだけで、必ず日付として検査されるとは限らない。 Foundryが使う仕様の版や検証設定は、この発表だけでは確定しないので、実際の処理で確認したい。

さらに、正しい日付でも、申請に書かれたプロジェクト期間と一致するとは限らない。 期限が不明なときに、形式を満たすためだけに日付を推測して入れれば、型の検査を通る代わりに不確実さを隠してしまう。 読み取りに成功した項目と不足した項目を別に返すことが、次の工程を正しく止める手掛かりになる。

想定例の受け渡し

抽出した値を、照合済みの値へ進める

ここから、申請を三つの段階で扱う設計を考える。 最初の段階は、申請者の識別情報と原文を保持し、部署、希望する役割、期限の候補を取り出す。 「営業用」しか書かれていない場合は、正式な部署IDへ置き換えず、用途の記述と部署不明という結果を渡す。 どの文から候補を読み取ったかも、必要な範囲で残す。

次の照合段階では、社員台帳と役割の一覧を使う。 申請者に対応する部署が一つに定まるか、希望する役割が許可された候補か、期間が規則に合うかを確かめる。 部署の候補が複数なら補足依頼へ進み、台帳を取得できないなら未確認のまま止める。 確認できないことを、部署が存在しないことや、許可されたことへ読み替えない。

その結果を申請書にするときは、読み取った希望と、照合で確かめた項目を区別する。 申請ID、参照した台帳と役割一覧の版、不足情報を結び付ければ、担当者は判断の根拠へ戻れる。 これらの項目は、本稿が提案する受け渡しの設計であり、Foundryが自動で保存する情報の一覧ではない。 また、原文や個人情報をすべて後段へコピーする必要もなく、確認に必要な部分を選ぶことが重要になる。

値の形をそろえる

部署は文字列、役割は配列、必要な項目は必須とする。 後段が受け取れる形式を定める。

値を信用できる範囲を示す

原文由来の候補、台帳で確認した値、取得失敗、不足、実際の承認を区別する。 形式に合う値を確定済みと誤読させない。

承認と実行

「承認済み」という出力を、管理者の許可と取り違えない

照合が終わっても、登録してよいという判断が済んだとは限らない。 この想定例では、管理者が申請者、役割、期限を見て許可した記録を、アカウント作成の前提にする。 エージェントが出した真偽値や「承認済み」という文字列だけでは、その管理者が許可した証拠にならない。

管理者が三か月の閲覧権限を認めた後、申請書が期限なしの編集権限へ変われば、同じ承認では登録できないようにする。 誰に何をいつまで認めたかを、実際の登録内容と照合する必要がある。 権限を変更する操作に進む前に、この一致をアプリ側で確かめる。 これは人の承認を条件とする本稿の設計例であり、あらゆる処理に人の確認が必要だという主張ではない。

登録処理の後も、申請書の完成とアカウント作成の完了は別だ。 外部の登録先が失敗を返したり、結果が不明だったりすれば、申請を完了と表示する根拠は足りない。 照合結果、承認記録、登録先の実際の結果を結び付けることで、どの段階まで済んだかを担当者へ伝えられる。

動的な計画との比較

探索の順序を変えても、推定を事実へ変えない

工程の受け渡しを明示することは、すべての手順を固定することとは異なる。 Magentic-Oneの研究は、統括エージェントが計画を立て直す構成を示す。 タスクの記録に事実、推測、計画を置き、進捗の記録で次の担当や作業を決める。 ブラウザー、ファイル、コードを扱う担当を、状況に応じて使う研究例である。

申請であれば、どの資料から不足情報を探すかは変えてよい場合がある。 一方、根拠が得られない部署や期限を、計画を進めるために確認済みへ変えてはいけない。 Magentic-OneとFoundryは、同じ実装や同じ性能を示す比較ではない。 前者の動的な計画と後者の明示的な受け渡しを比べることで、柔軟な探索と、信用できる値の範囲は別に設計できると考えられる。

複数エージェントが同じ値に同意しても、独立した確認とは限らない。 最初の担当が推測した部署を次の担当が申請書へ写し、確認担当もその申請書だけを読めば、同じ推定が三回繰り返される。 確認担当が台帳や原文へ戻れる受け渡しにすることが、担当を増やすだけでは得られない検証になる。

実行から調べる

どの工程で、不確かな値が確定扱いになったか

Foundryの発表は、呼び出し、入出力、変数代入、分岐経路の追跡と、組み込み・独自の評価器を説明する。 初期リリースの観測は、ワークフロー内の個々のFoundryエージェントが中心である。 表示された経路だけから、外部の台帳や登録先のすべての状態まで確認できるとは言えない。

この範囲を踏まえ、実行記録では、抽出時は部署不明だったのに、後段で正式な部署へ変わっていないかを調べる。 その間に台帳照合の結果があれば変更を説明できるが、モデルが補っただけなら根拠が欠けている。 分岐が予定どおりだったかに加え、その分岐に使った値がどこから来たかを確認する必要がある。

試行には、部署名の曖昧な申請、期限のない申請、照会失敗、承認後の内容変更を含めたい。 正しいアカウントを作れた割合だけでなく、未確認の値で止まれたか、担当者が根拠へ戻れたかも見る。 同じ入力と台帳を使い、固定した処理や単一エージェントとの比較を置けば、分担の追加に見合う改善を判断しやすい。 どの確認も、評価器を選ぶだけでは決まらず、申請の規則から先に定める必要がある。

判断

役割の数より、次の担当に何を渡せるか

図、変数、構造化出力が提供されることで、複数エージェントの仕事を確認できる対象として扱いやすくなる。 ただし、情報を渡す形式と、その情報を信用する根拠は同じではない。 推定、照合、承認、実行結果を分けて渡すことが、見える手順を実際の業務へつなぐ条件になる。

本稿の申請例なら、抽出と申請書作成に別のモデルを使うことが必須ではない。 台帳照合や承認内容の一致は、決められた処理で確かめられる部分もある。 複数エージェントを選ぶなら、分担することで誰の判断が明確になり、どの誤りを見つけやすくするのかを示したい。 受け渡しの根拠が説明できないまま担当を増やしても、同じ不確実さが長い経路を通るだけになり得る。