Two different types of agent authorization｜2種類のエージェント認証方式

![image](https://blog.langchain.com/content/images/2026/03/agent-identity-banner.png)先週、エージェントを構築、使用、管理する方法としてLangSmith Fleetをリリースしました。このリリースの重要な部分は、2種類の異なるエージェント認可の導入でした。 エージェント認可とは、エージェントが何を行うことを許可されているかを指します。エージェントがSlackツールを呼び出すとき、データを取得する前に誰として認証するのでしょうか？ **代理（On-behalf-of）** 最近までほとんどの人が想定していたエージェントの標準的な形態は、ユーザーの「代理（On-behalf-of）」として動作するというものです。 NotionとRipplingにアクセスできるオンボーディングエージェントを想像してみてください。アリスがそれと対話するとき、エージェントはRipplingでアリスに関する情報を参照し、アリスがアクセス権を持つすべてのNotionページを閲覧できるべきです。アリスがこのオンボーディングエージェントを使って、Ripplingでボブの個人情報を参照したり、ボブが持つ可能性のある非公開のNotionページを見たりすることはできません。ボブがオンボーディングエージェントを使うとき、彼はRippling内の自分のすべての情報とNotion内の自分の非公開ページにアクセスできますが、アリスのものにはアクセスできません。 これを実装するには、いくつかの要素が必要です。誰がエージェントを使っているのか（アリスかボブか）を知る方法が必要です。次に、それらのユーザーIDを、実行時にツールへ渡される認証情報にマッピングする必要があります。 **そしてOpenClawが登場** OpenClawが登場するまで、「代理（On-behalf-of）」はエージェントを考える上での主要な方法でした。OpenClawでは、アリスがエージェントを作成します。おそらく彼女だけがそのエージェントを使うでしょう（その場合、この認可の区別はあまり重要ではありません）。しかし、彼女は異なるチャネル（テキスト、メール、Twitterなど）を通じて他の人にそのエージェントを公開するかもしれません。 他の人がそのエージェントと対話するとき、エンドユーザーの認証情報は使わず、アリスが与えた認可を使用します。 これはアリス自身の認証情報である場合もありますが、それは望ましくないかもしれません。エージェントがアリスの認証情報を持っている場合、アリスがアクセスできるNotion内のあらゆる情報を参照できてしまいます。そこには、他の人にエージェント経由で問い合わせられることを望まない、アリスの非公開文書が含まれている可能性があります。 このため、人々はそのエージェント専用にNotionやRipplingなどに専用アカウントを作成し、エージェントがアクセスできる範囲を制御するようになりました。そのエージェントと対話するすべての人は、実質的に同じ認証情報セットを使用することになります。 **LangSmith Fleet** LangSmith Fleetをリリースする際、私たちはユーザーが両方のタイプのエージェントを求めていることを認識しました。エージェントを作成して他の人に各自の認証情報で使わせたい場合もあれば、エージェントに独自の固定された認証情報セットを持たせたい場合もあります。私たちはこれら2種類の認可に対応する、2種類の異なるエージェントを追加しました： * **アシスタント（Assistants）**: エンドユーザーの「代理（On-behalf-of）」として動作 * **クロー（Claws）**: 独自の固定された認証情報を持つ ![image](https://blog.langchain.com/content/images/2026/03/Fleet-agent-identity.png)また、チャネル（まずはSlack、Gmail、Outlook、Teams）とエージェントの共有という概念も追加しました。アシスタントとクローは異なるチャネルをサポートします。アシスタントを共有するためには、そのチャネル内のエンドユーザー（例：SlackユーザーID）をLangSmith IDにマッピングする必要があります。そのため、現在アシスタントは、このマッピングをサポートしている一部のチャネルでのみ利用可能です。 チャネルとこれらの異なる認可タイプは、**人間の介入（human in the loop）** の必要性も浮き彫りにします。固定された認証情報セットを持つエージェントを作成し、チャネルを通じて公開する場合、それは様々な形で使用される可能性があります。そのエージェントが潜在的に危険または機密性の高いアクションを実行できるのであれば、それらのアクションにゲートを設けるために、何らかの「**人間の介入（human-in-the-loop）**」**ガードレール**を使用したいと考えるでしょう。 **例** 具体的に理解するため、私たちが作成した実際のエージェントのいくつかとその認可タイプを見てみましょう。 * **オンボーディングエージェント**: **アシスタント**。SlackとNotionにアクセスでき、Slackで公開されています。エンドユーザーのSlackとNotionの認証情報を使用します。 * **メールエージェント**: **クロー**。このエージェントは受信メールに応答します。誰がメールを送ってきても、このエージェントは私のカレンダーを確認して会議の空き状況を判断し、私の代理で応答を試みます。メール送信とカレンダー招待状の送信は、**人間の介入（human-in-the-loop）** **ガードレール**によって制御されています。 * **製品エージェント**: **クロー**。このエージェントは競合他社を監視し、製品に関する質問やロードマップの策定を支援します。独自のNotionアカウントを持ち、カスタムSlackボットを通じて公開されています。 **今後の取り組み** LangSmith Fleetでこれら2種類のエージェントを提供できることを嬉しく思います。しかし、これはエージェント認可の始まりに過ぎないと考えています。今後の潜在的な方向性については、WorkOSのこのブログ記事をご覧ください。 また、より細かいメモリ権限でこの機能を発展させることにも期待しています。エージェントのタイプ（アシスタントかクローか）によって、メモリの扱い方を変えたい場合があるでしょう。例えば、アシスタントがアリスに関する機密事項を記憶し、それをボブとのチャットで使用できるようにしたくはないはずです。現在は、アクセス権限でこれを管理しています。エージェントを共有する際、他のユーザーがそのメモリを含めて編集できるかどうかを選択します。将来的には、ユーザー固有のメモリを導入する予定です。 ぜひ今日からLangSmith Fleetをお試しください。

2種類のエージェント認証方式

背景や根拠まで確認しますか？

調べる

選ぶ

サイト