AgentKitで試作が速くなると、公開前に何を確かめるか

問い

手順が画面でつながった後に、残る仕事

顧客からの問い合わせを分類し、注文を調べ、返信案を作る。 開発者が画面上でこの手順をつなぐと、最初の質問に答える試作が動いた。 ところが返品規約を更新した翌日、画面には新しい期限、返信案には古い期限が出る。 この想定例では、エージェントを作れたことと、製品の変更が一貫していることは別の問題になる。

10月6日のAgentKitの発表は、手順の作成、接続管理、埋め込み画面、評価をまとめて提供する方向を示した。 同じ発表で、LY Corporationは最初の複数エージェントの処理を作り、2時間未満で動かしたと説明する。 これはベンダーが掲載した顧客の説明であり、既存の顧客データや規約との統合を含む全開発工数を測った比較ではない。

速い試作には価値がある。 業務担当者が完成品を待たずに、手順の誤りや不足を指摘できるためだ。 ただし、公開できる製品にするには、手順、接続先、業務規則、画面の説明が同じ変更を反映する必要がある。 本稿の判断は、道具で省ける実装を選びつつ、その対応関係まで一つの変更として確かめることだ。

提供範囲

手順を描く道具と、実行を組み込むSDK

AgentKitでは、Agent Builderが視覚的な手順定義、試行実行、版管理を担う。 Connector Registryは接続をまとめて管理し、ChatKitは応答の逐次表示や対話の管理を含むチャット画面を製品へ組み込むための部品になる。 評価にはデータセットや、処理経路を採点するトレース評価が加わる。 それぞれが別の実装を減らすので、ひとまとめの機能数だけでは選びにくい。

提供状態も異なる。 発表ではChatKitと新しい評価機能が一般提供、Agent Builderはベータ、Connector Registryは対象を限ったベータである。 接続管理を使える組織と使えない組織では、同じ構成をそのまま選べない。 計画として述べられた単独のWorkflows APIやChatGPTへの配備まで、既定の機能に含めないようにしたい。

比較対象のMicrosoft Agent Frameworkは、10月1日にオープンソースのSDKと実行環境として発表された。 業務ロジックによる手順と、モデルが進め方を選ぶ処理を説明する。 9月29日のClaude Agent SDKの説明は、文脈収集、操作、検証の反復、ファイルやコマンドを扱う仕組みを示す。 どちらも既存アプリへ実行を組み込む比較材料だが、AgentKitと同じ製品構成とは限らない。

ここから読み取れるのは、画面から手順を作る方法と、コードから実行を組み込む方法が並んでいることだ。 Microsoftの将来の統合計画を現在の共通基盤とみなしたり、Claudeの用途例を業務での成功率とみなしたりすることはできない。 道具が提供する範囲を、使う版と提供状態に沿って比べる必要がある。

画面との統合

対話が表示できても、誰の注文を扱うかは決まらない

その違いを、既存のサポート画面へ返信案の作成を追加する想定例で考える。 担当者は顧客の画面を開き、返品が遅れている理由を調べる。 アプリは、ログイン中の担当者がその顧客を担当できるか確認してから、対応する注文や配送記録を取得する。 担当者のIDと顧客のIDを同一視するのではなく、既存の権限と担当範囲を使って両者を結び付ける。

Agent Builderなら、分類、記録の取得、返信案の作成という経路を可視化する手掛かりになる。 ChatKitなら、対話を表示する実装の一部を省ける。 しかし、対話欄へ入力された顧客IDだけを信用して記録を取得してよいかは、画面を埋め込めたことからは決まらない。 サーバー側が確認した顧客と利用者の条件を、実際の照会へ反映する必要がある。

表示にも業務の意味がある。 「返信案を作成」「顧客へ送信済み」「返金完了」は、異なる出来事だ。 生成した文章を画面へ流す処理だけでは、その違いを表せない。 アプリが実際の操作結果と結び付けて表示しなければ、担当者は未送信の案を送信済みと思い込む可能性がある。 これは本稿が提案する統合上の確認であり、特定製品が必ずこう誤表示するという報告ではない。

変更の広がり

返品期限を変えると、手順以外も変わる

次に、承認済みの返品期限が14日から30日へ変わったと仮定する。 業務担当者は新しい規約を登録し、開発者は返信案の指示を更新した。 それでも接続先が古い規約の写しを返せば、手順は正常に進んで古い回答を作り得る。 正しい規約を参照しても、画面の定型説明が14日のままなら、利用者には矛盾して見える。

したがって、手順の版管理があることと、製品の判断を再現できることは同じではない。 保存した手順が、どの規約、接続設定、モデルへの指示、画面の説明と組になっていたかまで確かめたい。 外部の規約が更新されたり、接続先が変わったりすれば、同じ手順の版でも結果の条件は変わる。 この対応を記録するのは、製品を作る側の仕事である。

同時にすべてを一つの製品へ移す必要はない。 規約を既存システムに残すなら、参照した版を報告できるようにする。 画面を既存アプリに残すなら、手順を更新した際に表示の意味も確認する。 道具へ委ねる範囲を広げるほど、残した部分との受け渡しを明確にすることが必要になる。

評価の使い分け

経路を調べる評価と、結果を確かめる評価

この食い違いを探すには、処理経路と最終結果の両方が必要になる。 AgentKitのトレース評価は、途中の呼び出しや判断を調べる材料になる。 ただし、「規約を取得して返信案を作った」という経路だけを正解にすると、古い規約の利用を見逃し得る。 結果側では、正しい顧客と規約を使い、案内した期限と金額が期待する条件に合うかを別に確かめたい。

Anthropicの道具を評価する説明も、現実の仕事に基づく課題と検証できる結果を組にし、正答率に加えて時間、呼び出し回数、使用量、エラーを調べる方法を述べる。 評価に使わず残した課題での確認も扱う。 採点を改善することと、改善に使った事例だけへ合わせ込むことを分けるための考え方である。

本稿の想定例なら、14日以内、14日を超えて30日以内、30日を超える返品を用意する。 期限だけでなく、規約の適用日や商品の条件にも合わせた期待結果を、業務担当者が先に定める。 別の顧客の注文、取得できない規約、配送記録の欠落も含め、回答する場合と止める場合を比較する。 新旧の指示を同じ入力と参照資料で試せば、変更の効果を判断しやすい。

モデルによる採点は、誤りの候補を探す助けになり得る。 それでも顧客の一致や金額など、既存データから直接確かめられる条件まで、同じ生成モデルの評価だけに委ねる理由はない。 評価の仕組みを用意した後も、何を正しいと判定するかは、実際の規約と操作結果から定める必要がある。

人の仕事

同じ手順を見ても、同じ理解とは限らない

視覚的な手順は、業務担当者と開発者が同じ対象を見て話す助けになる。 例えば「顧客へ回答」という一つの箱を見て、一方は案を作る段階、もう一方は送信まで含む段階と考えているかもしれない。 箱の名前だけで合意せず、入力、参照する規約、出力、外部操作を具体的に確かめることで、この違いを見つけられる。

担当者へ渡す確認画面も、手順の図だけでは足りない。 どの顧客と注文を扱い、どの規約から判断し、何をまだ実行していないかを示したい。 資料が取得できないときは、不足を文章で埋めて返信案を完成させず、その不足を引き継ぐ。 確認者が全記録を読む負担まで含めて測らなければ、試作の速さが運用の速さへつながったかは分からない。

選定

既存アプリに何があるかで、必要な道具は変わる

利用者画面も手順管理も評価の仕組みもない試作では、複数の部品をまとめて導入できる道具が有用な場合がある。 一方、既存の顧客画面、認証、監査記録がある製品では、そこへ実行を接続するSDKの方が適するかもしれない。 新しい対話画面を追加することが、常に最も大きな実装削減になるわけではない。

選定では、作らずに済む部分と、接続・移行・検証に増える仕事を両方見る。 道具の画面では簡単に試せても、既存アプリへ利用者の条件や操作結果を渡す作業が大きければ、全体の工数は小さくならない。 同じ顧客対応の試作を使い、返信案、規約変更、取得失敗、既存画面への反映まで確かめると、機能一覧では見えない差を比較できる。

判断

速く作れることを、変更を確かめる時間へつなげる

開発ツールが手順、画面、実行、評価を提供することで、最初の動作へ到達する道は短くなり得る。 だが、短くなった試作の時間だけで完成を判断すると、規約や画面との食い違いが製品へ残る。 公開前に確かめる対象は、手順の図に加えて、その手順が使う資料と利用者へ伝える結果である。

私が選定で重視するのは、どれだけ早く案を作れるかと、業務の条件が変わった後に何を確認できるかの両方だ。 試作で得た余地を、関係者が具体的な誤りと変更を確かめる時間に使う。 それができれば、開発ツールの価値は、作成画面の便利さから、製品を改善し続ける仕事へ広がる。