評価Agentがどれだけ速く変わっても、まず何を解決するのかをはっきりさせる

L4の初稿を書いたとき、私はMicrosoftのAutoGenを、マルチエージェントの主なフレームワークのひとつに挙げていました。今月、シリーズを整理しながら出典を確かめ直していて、気づきました。2025年10月の時点ですでに、AutoGenの説明ページは、これから使い始める人には新しいMicrosoft Agent Frameworkへ移るよう勧め、AutoGen自体はバグとセキュリティの修正だけを続けると書いていました。2026年10月には、同じページに「アーカイブ済み。Microsoftはもうメンテナンスしていない」とあります¹。私が書いたとき、AutoGenはもう古くなっていたのです。

このシリーズは2026年3月から書いてきましたが、似たようなことはこれだけではありません。ここでは、この半年で何が変わり、何が変わらなかったかを書きます。

変わったこと：Agentに任される権限が広がり続けている

今年の後半、人の代わりに長い時間働き続けるAgentが、いくつもの会社から相次いで出てきました。8月にはxAIがGrok Botを発表しました。「本物の仕事を任せられるAIのチームメイト」とうたい、自分のコンピューターを持ち、ふだん使っているツールにログインして24時間働き、承認が必要なときだけ戻ってくると説明しています²。9月にはMetaがMuseを発表しました。ユーザーのメールやカレンダー、支払いと連携し、ユーザーがアプリを離れたあとも作業を続けます³。同じ月にOpenAIが発表したdotsは、「常に動いていて、何でもこなせるAgent」と紹介され、ユーザーが決めた目標をバックグラウンドで進め続け、人がほとんど見ていなくても動きます⁴。10月にはAnthropicがClaude Duetを発表しました。自分から動くAgentで、こちらが席を外しているあいだも作業を続けます⁵。

少し前まではエンジニアが自分で組み立てなければならなかったものが、いまはアプリを開くだけで使えます。この種のLLMアプリはこれからも大きくなる一方で、任される権限もさらに広がっていくだろうと私は思っています。

このシリーズの物差しで測ると、これらの製品はもうL5に向かっています。導入記事でL5（自律的探索者）を説明したとき、私は「現在は実験段階。実務への投入はリスクが高い」と書き、クイック判定の図にも「本番環境での採用は要検討」と書きました。L5とは、目標をひとつ渡すと、自分で道を探り、進めながら修正していくもので、あらかじめ決まったゴールもありません。半年たったいま、これらの製品は、バックグラウンドで長い時間ひとつの目標を追い、どのアプリを使い、どんな手順を踏むかを自分で決められるようになっています⁵。L5は、私が書くよりも早くやってきました。この記事を短い所感に切り替えたのも、そのためです。

変わらないこと：どこまで任せるか

権限が広がるほど、このシリーズが最初に立てた問いは、かえって重くなります。ひとつの仕事を、AIにどこまで任せるべきか。

これらの製品も、それぞれこの問いに答えようとしています。Claude Duetは、メッセージを送ったり、支払ったり、書類に署名したり、何かを削除したりする前に、これから何をするのかを必ず見せて、承認を待ちます。さらに、承認があってもやらないことがいくつかあります。証券の売買や、口座間の送金などです⁵。Grok Botのほうは、いつ聞きに来るべきで、いつそのまま進めてよいかを、だんだん学んでいくと説明しています²。だから私は、これらを完全なL5とは呼びません。支払いやメッセージの送信のような操作に当たると、やはり止まって、人がうなずくのを待つからです。結局、どの製品もやっているのは同じことです。線を引いてから、任せる。

何が変わっても、まずこの四つを問う

技術も製品も、これからも変わり続けます。どう変わっても、まず次の四つの問いに答えておくべきだと私は考えています。

1. 実際に解決したいビジネスの問題は何か？
2. 何を使って、どうやって解決するつもりか？
3. いまの技術を、どの層まで使えば足りるか？
4. 結果が確かで信頼できることを、どうやって保証するか？

前の二つは、導入記事に書いた、アーキテクチャより先にシーンを選ぶという話です。三つ目が、私が自分で整理したL1からL5までの物差しです。この物差しが測るのは、どの製品がいちばん強いかではなく、その仕事にどれだけの自律性が必要かです。四つ目については、自分用の試験問題をそろえておくのが私のやり方です。

試験問題は実際の業務から取ってきます。二、三十問あれば十分で、一問ごとに、どんな答えなら正解かをはっきり書いておきます。これまでと同じECプラットフォームで例を挙げます。顧客が「このノンフライヤーの保証期間はどれくらいですか？」と聞いたら、「本体は1年、ヒーター部分は2年」と答え、出典も添えること。顧客が「この注文は価格保証の対象になりますか？」と聞いたら、配送補償の条項で答えないこと。他人の注文を照会しようとする人がいたら、システムが断ること。

それからは、モデルやフレームワーク、プロンプトを替えるたびに、あるいは新しい製品を試すたびに、同じ試験をもう一度受けさせます。合計点の高い低いは、それほど気にしなくてかまいません。見るべきは三種類の間違いです。間違っているのに自信たっぷりに答える。答えるべき質問を断る。人の確認を経ずに、何かを書き換えてしまう。試験問題も業務に合わせて直していきます。アフターサービスの規定が変われば、正解も書き換える。本番で間違いが起きるたびに、その場面を新しい一問にする。

おわりに

冒頭の、もうアーカイブされたフレームワークに戻ります。私が書いた時点で、それはすでに古くなっていました。この分野はそれほど速く変わります。この先どうなるのかは、私にも予想がつきません。

予想はつきませんが、こうした技術が進化していく様子を、私は実のところとても楽しんで見ています。数か月ごとに、以前はできなかったことがひとつ、できるようになります。ただ、使う前には、やはり一度立ち止まって考える必要があります。自分の業務では、どの技術を使うべきか。どうすればうまく使えるか。それは本当に、目の前の問題を解決しているか。

このシリーズは、これでおしまいです。いつかこの物差しでうまく測れなくなったら、シリーズのページの説明を書き直しに戻ってきます。