一つの問い合わせから
道具と担当をつないだ後、誰が依頼を終えるのか
「この製品の設定方法を知りたい。届いた注文の状況も確認したい」という問い合わせを考える。 これは基盤の管理範囲を比べる想定例である。 使い方は製品文書から、注文状況は顧客ごとのデータから答える。 開発者は、モデルを呼ぶ処理に加えて、検索、注文APIへの接続、依頼の振り分け、結果をまとめる処理を用意する必要がある。
3月11日のOpenAIのエージェント開発ツール発表と、3月10日のAmazon Bedrockの複数エージェント協調の一般提供は、その作業の一部を選べる部品にした。 検索をサービスに任せる、担当間の引き継ぎをSDKで組む、複数担当の調整をサービスで設定する。 開発の出発点は具体的になったが、両社が同じ範囲を引き受けるわけではない。
私が比較したいのは、機能名の数より、一件の問い合わせで誰が何を実行するかだ。 文書を検索できても、顧客の注文を参照してよいかは別に決める必要がある。 担当を振り分けられても、矛盾した結果を利用者へどう返すかは残る。 管理された基盤の価値は、こうした仕事を分解して初めて見える。
サービス側の検索
検索を任せると、接続の作業と資料の判断が分かれる
Responses APIは、Web検索、ファイル検索、computer useを組み込みの道具として示した。 Web検索は外部の情報を取得し、ファイル検索は用意した文書を探すための機能である。 製品文書を登録して検索させるなら、開発者が検索処理を一から組む範囲を減らせる。 どの資料を登録し、どの問い合わせで使うかは利用側が決める。
冒頭の問い合わせなら、公開の使い方と、顧客別の契約条件を同じ資料として扱わない。 検索結果が正しくても、旧製品の手順や別の顧客の条件を答えれば依頼を取り違える。 文書の版、対象製品、参照範囲を検索条件と回答の根拠へつなぐ必要がある。 引用が付くことも、その資料がこの顧客に適用できるという保証にはならない。
ここで減るのは、情報を取得するための実装の一部である。 資料を保守する仕事や、適用条件を確かめる判断まで消えるわけではない。 検索の部品を買うときには、検索精度に加えて、古い文書を除く方法や、対象を絞る条件を自分たちが管理できるかを比べたい。
画面操作の実行先
同じAPIにある道具でも、アプリが動かす操作がある
computer useは、モデルが生成したマウスやキーボードの操作を、開発者の環境で実行する仕組みとして説明されている。 検索と同じAPIに並んでいても、画面を動かす環境まで全てサービス側で引き受けるという意味ではない。 アプリ側には、操作を実行し、結果の画面を取得して次の判断へ渡す処理が必要になる。
この違いは、Operatorの1月23日の発表と比べると読みやすい。 Operatorは利用者向けのブラウザ操作を研究プレビューとして提供し、ログインなどで操作を人へ戻す設計を示した。 そのモデルを開発用APIから使うことと、利用者向け製品のブラウザや引き継ぎを、そのまま自社アプリへ受け取ることは別である。
注文システムにAPIがあれば、その経路を使う選択がある。 画面しかないシステムを操作するなら、ログイン状態、待機、操作後の結果をアプリが扱う必要がある。 同じ「道具の呼出し」という言葉でまとめず、どこで実行され、誰が結果を観測するかを確認する。 これが、必要な開発作業を見積もるための最初の分かれ目になる。
アプリに組み込む協調
短いSDKの例にも、返金依頼の処理は残っている
OpenAIのAgents SDKは、エージェントの設定、担当間の引き継ぎ、入力と出力の検査、実行記録の確認を部品として示す。 問い合わせを受け、買い物担当やサポート担当へ渡す流れをアプリへ組み込める。 これはオープンソースのSDKであり、自社アプリの配備や顧客認証までホストするサービスではない。
発表のサンプルでは、返金依頼を受け付ける関数の中身を開発者が追加する形になっている。 例の戻り値は成功を表す短い文字列だが、実際の業務処理はそこに実装する。 この小さな空欄に、対象の注文を調べる、変更可能かを確かめる、依頼を記録する、受付結果を返すという仕事が入る。 担当へ渡す仕組みが動くことと、依頼が受け付けられることを混同してはいけない。
入力と出力の検査も、条件を自分で定義して使う機能だ。 文章の形式を検査するだけでは、別の顧客の注文を参照してよいかを決められない。 実行記録は、どの担当へ渡り、何を呼んだかを調べる助けになるが、正しい注文が変更されたという根拠は業務システム側にも必要になる。
サービス内の担当分担
Bedrockは、依頼をまとめる場合と直接渡す場合を分ける
Amazon Bedrockの一般提供は、統括役が複雑な依頼を分解し、担当へ割り当て、結果をまとめる方式を説明した。 もう一つのsupervisor with routingでは、単純な依頼を該当する担当へ直接渡し、複雑な依頼や意図が明確でない場合には統括役による調整へ戻す。 担当間の調整をサービスの設定として扱える点が、アプリ内のSDKとは異なる。
使い方だけを聞く問い合わせなら、文書担当へ渡す経路を考えられる。 使い方と注文状況を一緒に聞くなら、文書と注文の結果をそろえる処理が必要になる。 独立した取得は並行して進められても、注文の特定が先に必要な変更処理まで同時に進めてよいとは限らない。 複数担当に分けることと、依頼の順序を正しく決めることは別に検査する。
一般提供の発表には、担当間の動きを確認する画面や、処理の細かな段階を残す記録も含まれる。 これは調整を調べるための機能であり、自社の問い合わせが必ず速く、正確になるという比較実験ではない。 担当の説明が重なって誤った振り分けが起きるなら、その説明と処理経路を利用側が直す必要がある。
研究から読める役割
会話と進捗を管理しても、業務の答えは自動で確定しない
AutoGenの原版は、複数エージェントの会話でアプリを組み、人の入力や道具を組み合わせる構成を示した。 Magentic-Oneの原版では、統括役が事実、推測、計画の台帳と、進捗や担当の台帳を持ち、ブラウザ、ファイル、コードなどを扱う担当を調整する。 これらは分担の仕組みを読む手掛かりになるが、特定の基盤の性能や、全ての仕事に必要な構成を証明するものではない。
問い合わせに戻ると、文書担当が「配送先を変更できる」と答え、注文担当が「既に出荷済み」と返す場合が考えられる。 文書の変更条件がどの注文状態を対象にし、注文の情報がいつ更新されたかを確かめなければ、まとめ役を置いても答えは確定できない。 不一致を滑らかな一文に整えると、利用者には何が未確認か分からなくなる。
分担は、担当を増やす目的で使わない方がよい。 参照する資料や使うAPI、変更できるデータを分ける理由があり、その結果を照合できるときに使う。 会話を管理する機能と、顧客の依頼に対する答えを確定する条件を、別々に持つ必要がある。
既存の業務処理とつなぐ
管理された基盤から、アプリへ操作を戻す選択もある
Bedrockの2024年4月の発表は、外部操作をLambda関数へ渡す以外に、呼出し元のアプリへ制御を戻す方法を示した。 顧客の設定を取得する例でも、アプリ側が関数の結果を返す流れを説明している。 既存の接続や業務処理を使いたい場合、全ての実行を新しい基盤へ移す必要はない。
さらに、11月のcustom orchestrationの発表は、Lambdaで独自の処理経路を定義する選択を示した。 サービスが提供する調整を使うことと、組織が実行の順序を定めることは両立する。 検索、確認、更新の全てをモデルに毎回選ばせることだけが実装方法ではない。
注文の問い合わせなら、本人と注文の対応、参照できる範囲、変更可能な状態を業務システム側で確認する。 エージェントが生成した顧客名を、そのまま本人確認済みの情報として使わない。 APIが失敗した場合も、依頼を受け付けたか未確認なのかを区別して返す。 この部分を明確にすれば、利用者は、文書の回答が正しいことと、注文の処理が進んだことを分けて理解できる。
選択を一件の仕事へ戻す
減らせる実装と、残る判断を同じ問い合わせで比べる
Building effective agentsは、単純な構成から始め、定めた経路とモデルが次の手段を選ぶ処理を必要に応じて使う考え方を示す。 文書の説明だけで済む仕事に複数担当を置く必然性はない。 一方、参照するデータと変更権限が異なる仕事なら、担当や処理を分ける意味がある。
サービスへ任せる処理
検索や担当調整のどこを任せるか。利用する機能と、実行される場所を確認する。
アプリが実装する処理
画面操作、外部API、本人確認、業務結果の記録。SDKの例で省略された処理も含める。
利用者へ返す結果
説明の根拠と注文の状態を分け、未確認の点を残す。人が調べ直す負担まで評価する。
選ぶ際には、同じ文書と注文データで、正常な回答、古い文書、担当間の不一致、注文APIの失敗を試したい。 何を基盤が処理し、何をアプリが補い、人がどこを直したかを記録する。 応答時間や利用量も、その内訳と合わせて比較する。 モデルや設定が違う結果を、調整方式だけの優劣に置き換えない。
3月の発表が広げたのは、開発作業をどこへ委ねるかの選択肢だ。 その利点を利用者へ届けるには、減った実装の先に残る仕事を見落とさないことが必要になる。 一件の依頼を通して、取得、調整、外部実行、結果の確認をつなぐ。 誰がどこまで引き受けたかを説明できる基盤を選ぶことが、部品の充実を使えるサービスへ変える道になる。