エージェントとアプリケーションの間の欠落したリンク

***TL;DR: 多くのエージェントツールはサーバー上で動作するため、エージェントは API を呼び出すことはできますが、ユーザーが実際に作業を行うブラウザ、アプリの状態、またはデバイスの機能とは直接対話できません。LangChain のヘッドレスツールを用いることで、地理情報、クリップボードへのアクセス、ローカルメモリ、アプリ内アクションといったクライアントサイドの機能をファーストクラスのツールとしてエージェントに呼び出させることが可能になり、このギャップを埋めることができます。これにより、エージェントはより有用で、プライバシー保護にも優れ、実際のアプリケーション動作とも整合性が取れたものになります。*** 今日のエージェントはますます能力が高まっていますが、ユーザーが関心を持つ多くの機能はサーバー上ではなく、クライアントランタイム内に存在します。ブラウザやアプリケーションは、ローカル状態、ユーザーの選択結果、デバイス API、バックエンドシステムでは利用できないアプリ固有のアクションなどを管理しています。その結果、エージェントは次に何が起こるべきかを推論することはできても、ユーザーが実際に作業を行っている環境に対して行動を起こすことには依然として苦労します。 このギャップが生じる理由の一つは、多くのエージェントツールがサーバー上で実行されている点にあります。モデルがツールの使用を決定すると、エージェントはそのツールをプロセス内で実行するか、MCP サーバーなどの外部サービスに委任し、その結果を推論ループに戻してフィードバックします。これは API、データベース、バックエンドシステムにとってはよく機能しますが、明確な限界があります： - ブラウザ固有またはデバイス固有の API に直接アクセスすることはできません。 - サーバーに同期されたことのないフロントエンドの状態に対して行動を起こすことはできません。 - 頻繁にプライバシーに関わるデータをデバイスから外部へ持ち出させることになります。 - 本質的にローカルなアクションに対して、不必要な往復通信を導入してしまいます。 ブラウザは、多くの高価値なエージェントのアクションが実際に発生する場所です：ローカルアプリケーションの状態を読み取り、現在の UI に基づいて行動し、データをバックエンドに送信することなくデバイス機能を利用します。デスクトップアプリもまた、ローカルファイル、ネイティブ統合、セッション固有の状態を通じて同じパターンを露出しています。もしあなたのエージェントがこのランタイムに到達できないなら、バックエンドワークフローでは優れていても、ユーザーが実際に体験するインタラクションにおいては弱くなります。 Figma、Google スライド、あるいはリッチテキストエディタ向けのサイドカー型エージェント（sidecar agent）を構築していることを想像してください。エージェントはサーバー上でユーザーの要求について推論できますが、ドキュメントモデル、選択状態、編集コマンドはすべてクライアント側に存在します。サーバー側のツールでは、カーソル位置へのテキスト挿入、選択されたオブジェクトの書式変更、アクティブなスライドへのジャンプを行うことができません。なぜならそれらのアクションはアプリケーションランタイムに属するものであり、バックエンド API には属さないからです。現在、チームはこのギャップを、クライアントの状態の一部をシリアライズしてサーバーへ送り、レスポンスを受け取ってからクライアントを命令的にパッチする、場当たり的な UI ブリッジ（UI bridge）で埋め合わせています。これは機能しますが、脆く、組み合わせが難しく、モデルの推論ループからは見えない存在です。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a29971f331e51d15edef8fd_headless-tools-demo.gif) *エージェントが、ユーザーのブラウザから直接メモリや地理位置情報 API にアクセスできるようにしましょう。* これが LangChain における [ヘッドレスツール](https://docs.langchain.com/oss/python/langchain/frontend/headless-tools) が解決する課題です。 ## ヘッドレスツールが変えるもの モデルにとって、ヘッドレスツールは他のツールと何ら変わらない外観をしています：名前、説明、そして期待される入力セットを持ちます。モデルは他のどのツールと同様に、いつ呼び出すかを決定します。違いは、その後の処理にあります。 サーバー自体がツールを実行するのではなく、ツール呼び出しをクライアント（ユーザーのブラウザ、デスクトップアプリ、あるいは実際にその機能を持つ環境）に送信します。クライアントはローカルでツールを実行し、結果を戻り値として返し、エージェントはその続きから処理を進めます。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a2997e2ba2469142d2ecb78_1.png) これは一見すると小さな実装の詳細に思えるかもしれませんが、実際にはエージェントが確実に制御できるシステムの種類そのものを変えます。 モデルはツールがどこで実行されるかを知らなくても構いません。ツールを見て使用を決定し、結果を受け取るだけです。裏側ではサーバーとクライアントが連携しています：サーバーはエージェントが*何を*したいかを知っており、クライアントは*どのように*行うかを知っています。この分離こそが核心となる考え方です。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a299822df8f9322bf816b73_2.png) これを手動で接続し、React アプリから navigator.geolocation.getCurrentPosition() を呼び出して結果をエージェントに送ることもできます。しかし、その場合、モデルにはその機能の発見やいつそれを呼び出すかを決定する方法がありません。それは推論ループの外側、アドホックなサイドチャネルとして存在することになります。ヘッドレスツールは、クライアント側のアクションを推論ループの横ではなく、ループ内部に組み込みます。 ## なぜこれが重要なのか その利点は単なる「ブラウザへのアクセス」だけではありません。スライドデッキの作成を手伝うエージェントを想像してみてください。アクティブなスライドへジャンプし、ローカルコンテキストを読み取り、セッション全体をバックエンドに転送することなく、その場でプレゼンテーションを更新できるはずです。ヘッドレスツールは、クライアント側の機能をエージェントループ内の実際のツールとして公開することで、そのようなインタラクションを可能にします。 一部の操作は、バックエンドで正しくエミュレートすることは不可能です。地理位置情報は明白な例であり、ブラウザが権限プロンプトとデバイス信号を管理しています。クリップボードへのアクセス、キャンバス描画、ファイルピッカー、ライブ UI ナビゲーションはすべて、アクティブなクライアント環境に依存します。標準的なツールはバックエンドサービスを通じてこれらの機能を近似することができますが、ヘッドレスツールは実際の機能そのものを呼び出すことができます。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a2998ab21667aea15b1199a_3.png) しかし、ヘッドレスツールはブラウザ API のためのものだけではありません。これは、エージェントにアプリケーションネイティブなアクションへの安全なアクセスを与える一般的なメカニズムです。例えば：人気のある [Slidev](https://sli.dev/) 発表フレームワーク用のプラグインである [slidev-agent](https://github.com/christian-bromann/slidev-agent) は、ヘッドレスツールを使用して、ユーザーのアクティブなプレゼンテーション内の特定のスライドへ移動します。これはデータ取得の問題でもサーバー自動化の問題でもありません。 このパターンはプライバシーのトレードオフも変化させます。エージェントのメモリが常に集中型バックエンドにある必要はありません。IndexedDB などのブラウザストレージに支えられたヘッドレスツールを使用すれば、デフォルトでメモリをローカルに保つことができます。これは永続性があり、低レイテンシであり、そのユーザーとブラウザに自然にスコープされたものであり、リコールをサーバーサイドのデータ管理の問題に変えることなく実現できます。 ## コード内での動作方法 TypeScript では、定義と実装の分離が特に明確です。ツールは一度定義し、.implement(...) で実装をアタッチし、その実装を [frontend streaming hook](https://reference.langchain.com/javascript/langchain-react/useStream) に渡します。サーバーとクライアントは同じスキーマを共有しますが、ブラウザ固有の実行ロジックを読み込むのはクライアントのみです。 // tools.ts import { tool } from "langchain"; export const geolocationGet = tool({ name: "geolocation_get", description: "Get the user's current location from the browser.", schema: z.object({}), }); // App.tsx import { useStream } from '@langchain/react'; // shared tools definition import { geolocationGet as geolocationGetDefinition } from './tools'; export function App() { const stream = useStream({ // ... tools: [ // actual tool implementation on the client side geolocationGetDefinition.implement(async () => { const position = await new Promise((resolve, reject) navigator.geolocation.getCurrentPosition(resolve, reject), ); return { latitude: position.coords.latitude, longitude: position.coords.longitude, accuracy: position.coords.accuracy, }; }), ], }); return ... ; } LangChain のドキュメントにあるライブデモ [LangChain docs](https://docs.langchain.com/oss/javascript/langchain/frontend/headless-tools) をチェックしてください。ここでは、ブラウザローカルのメモリと地理情報機能、そして任意の人間の承認を組み合わせています。 ## まとめ 標準的なツールはエージェントにバックエンドシステムへのアクセス権を与えました。ヘッドレスツール（headless tools）は、ユーザーが実際に作業を行う場所へのアクセスを可能にします。 ユーザーはあなたのバックエンドに住んでいるわけではありません。彼らはブラウザ、アプリ、デバイスの中に住んでおり、そこで最も価値のあるエージェントとのインタラクションの多くが発生しています。ヘッドレスツールは、型付きスキーマ（typed schemas）、明示的な機能（explicit capabilities）、構造化された出力（structured outputs）、そしてレビュー可能性を維持しながら、それらのインタラクションを利用可能にします。これにより、エージェントはサーバーにとって便利なだけでなく、ユーザーにとってネイティブなツールを使用できるようになります。 ヘッドレスツールは、[LangChain Python](https://docs.langchain.com/oss/python/langchain/frontend/headless-tools) または [LangChain JS](https://docs.langchain.com/oss/javascript/langchain/frontend/headless-tools) で始められます。 [@huntlovell](https://x.com/@huntlovell)、[@colifran_](https://x.com/@colifran_)、そして [@sydneyrunkle](https://x.com/@sydneyrunkle) には、思慮深いレビューとフィードバックをいただき、感謝申し上げます。

エージェントとアプリケーションの間の欠落したリンク

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

調べる

選ぶ

サイト