2026 年 9 月 25 日、 Amazon CloudWatch は CloudWatch Omni を発表しました。これは、アプリケーション中心で AI を活用し、オープンスタンダードに基づいて構築され、オフコンソールで提供される、アプリケーションと AI ワークロードの統合オブザーバビリティエクスペリエンスです。CloudWatch Omni は、AI エージェント向けに特化して構築されたオブザーバビリティ、評価、実験のためのソリューションです。評価主導のワークフロー、既存のツールのサポート、そして作業環境に直接提供されるオブザーバビリティにより、チームは、モデルプロバイダー、フレームワーク、ランタイムを問わず、AI エージェントの設計、評価、運用を行えます。オブザーバビリティは IDE に直接提供されるほか、AWS Management Console とは独立したスタンドアロンの Web エクスペリエンスからも利用できます。 エージェント型 AI システムを導入する組織は、従来のモニタリングでは対処できないオブザーバビリティの課題に直面しています。エージェントの動作は非決定的です。標準的なメトリクスでエラーが示されていなくても、プロンプトを変更すると応答品質が低下する可能性があります。チームは複数のシステムにまたがるログを手作業で確認するために何時間も費やしており、何が変更されたのか、なぜ変更されたのかを特定できないことがあります。既存のツールでは、チームはサイロ化された生成 AI モニタリングを利用するか、コーディング環境とブラウザーベースのダッシュボードを頻繁に行き来する必要がある分断されたソリューションを利用するかの選択を迫られます。 CloudWatch Omni はすべてのトレースをキャプチャし、正確性、一貫性、検索品質、ツール選択などを評価する組み込みの評価機能を備えています。Playground でプロンプトバージョンを並べて比較したり、本番トラフィックからテストデータセットを構築したり、さまざまな構成で実験を実行したり、リグレッションを自動的に検出したりできます。 開発用と運用用の2つのサーフェス CloudWatch Omni は、相互に補完する 2 つのインターフェイスを通じてオブザーバビリティを提供しま開発者は、現在サポートされている IDE である VS Code と Kiro にネイティブ拡張機能を導入できます。エージェントの実行中にトレースが表示され、プレイグラウンドや評価機能にもワンクリックでアクセスできます。運用担当者は、AWS Management Console とは独立したスタンドアロンの Web エクスペリエンスを利用してフリートをモニタリングできます。SSO 経由でアクセスでき、AWS Management Console は必要ありません。どちらも同じデータを共有します。開発者がデバッグするトレースと、運用担当者が調査するトレースは同じものです。 Cloud Login 機能 は、ローカルの IDE 環境を AWS アカウントに接続し、テレメトリデータを Amazon CloudWatch に送信して永続的に保存したり、チームとトレースを共有したり、本番環境のダッシュボードにアクセスしたりできるようにします。この接続はオプションです。開発中は CloudWatch Omni を完全にローカル環境で使用し、本番環境のエージェントをモニタリングする準備ができたら、クラウドに接続できます。 使用の開始 CloudWatch Omni を使い始める方法は 2 つあります。IDE 拡張機能（VS Code と Kiro 向け）を使用する方法と、クラウドエクスペリエンスから直接開始する方法です。クラウドエクスペリエンスでは、IDE 拡張機能をインストールせずに CloudWatch へのテレメトリデータの送信を開始できます。このチュートリアルでは、拡張機能をインストールし、エージェントを作成して実行した後、IDE からトレースと評価ツールを確認します。 VS Code Marketplace から CloudWatch Omni 拡張機能をインストールすると、アクティビティ バーに CloudWatch Omni のアイコンが表示されます。ウェルカム画面から、[ サンプルプロジェクトを開始する ] を選択して、事前設定されたエージェントにサンプルトレースデータをロードするか、Command+Shift+P（macOS の場合）または Ctrl+Shift+P（Windows/Linuxの場合）を使用してコマンドパレットへのショートカットを使用し、[オムニ：新しいプロジェクトの作成] を選択します。 図 1.CloudWatch オムニウェルカムスクリーンと VS Code での新規プロジェクトの作成 サンプルプロジェクトには、エージェントの実装とサンプルデータセットが含まれています。使用開始時の設定の一環として、OpenTelemetry の計測機能を追加します。CloudWatch Omni が各手順をガイドします。新しいエージェントを最初から作成することもできます。CloudWatch Omni では、インタラクティブなチャットを使ってプロセスを進めます。チャットでエージェントの目的を定義し、モデルプロバイダーを選択して、ツールを設定します。デフォルトでは、すべてのデータはローカルに保存されます。必要に応じて AWS に接続し、Amazon CloudWatch にデータを送信できます。 設定を確認した後、ローカル開発サーバーを起動し、エージェントに質問を送信しました。これが一般的なチャットボットインターフェースと異なるのは、次に何が起こるかということです。「 トレースを表示 」を選択すると、エージェントがリクエストをどのように処理したかが正確に表示されます。 図 2.CloudWatch Omni は、AI コードアシスタントをガイドし、テスト用のローカル開発環境を設定できるようにします CloudWatch Omni は、Kiro、Claude Code、Codex などの AI コードアシスタントと統合し、セットアッププロセスを効率化します。これらのアシスタントは、Dev Server の設定、依存関係のインストール、計測機能の設定を代わりに行うことができるため、手動で設定することなく、インストールから最初のトレース付きエージェントセッションの実行までを数分で完了できます。 図 3.エージェントとのやり取りとトレースの表示 トレースは AI エージェントの動作を理解するために不可欠です。従来のリクエストとレスポンスのシステムとは異なり、エージェントは 1 回の呼び出しで複数の意思決定を行います。ツールの選択、プロンプトの組み立て、サブコールの連鎖などが含まれます。トレース全体を可視化できなければ、エージェントが誤った回答を生成した理由や、予期しない処理経路をたどった理由の診断は推測に頼ることになります。CloudWatch Omni は、すべてのステップを構造化されたタイムラインに記録するため、動作が想定から外れた箇所を正確に特定できます。 Trace Explorer では、エージェントが実行したすべてのステップ（LLM 呼び出し、ツールの呼び出し、推論ステップ）を、構造化された階層型タイムラインで詳細に確認できます。任意のスパンを詳細に確認して、入力、出力、トークン使用量、レイテンシーを調査できます。 図 4。エージェントの実行タイムラインを表示するトレースエクスプローラー Trace Explorer は比較モードもサポートしています。比較モードでは 、2 つのトレースを並べて表示し、異なるプロンプトや設定が動作にどのように影響するかを確認します。比較モードは、リグレッションのデバッグに特に役立ちます。また、 Ask Assistant を使用すると 、AI エージェントがトレースから表面のパターンや異常を分析し、「なぜエージェントはこのツールを2回呼び出したのか」などの質問に答えます。 図 5。2 つのトレースを並べて比較する 評価は、生成 AI のオブザーバビリティを、実際の品質改善につながるものに変える役割を果たします。レイテンシーやエラー率などの従来のメトリクスでは、エージェントの応答が有用で、一貫性があり、事実に基づいて正確なものかどうかを判断できません。評価機能は、各応答を品質の観点から評価することで、ユーザーが実際に体験する品質を測定し、標準的なモニタリングではまったく検出できないリグレッションを発見できるようにします。 CloudWatch Omni には、一貫性、有用性、忠実性、ルーティングの正確性などのメトリクスに対応する 17 種類の組み込み評価機能が含まれています。Trace Explorer からトレースを選択し、評価機能を選んで評価を実行しました。カスタム評価フレームワークを構築することなく、各サンプルのスコアと集計メトリクスを取得できました 。 図 6.トレースの評価の実行 そこから、 Playground を使用してさまざまなシステムプロンプトを並べてテストし、複数のモデルとプロンプト構成をリアルタイムで比較して、変更を加える前に各バリエーションが出力品質にどのように影響するかを確認しました。Experiments ビューを使用すると、同じデータセットに対して 2 つのエージェントのバリエーションを実行し、評価スコア、レイテンシー、トークン使用量を並べて比較できるため、パフォーマンスの高い構成を選択できます。 図 7 。Omni Experimentsコンソールでのエージェントバリアントの評価比較 Prompt Management を使用すると 、プロンプト構成を長期にわたってバージョン管理および追跡できるため、新しいバージョンのパフォーマンスが低下した場合でも、簡単にロールバックできます。 CloudWatch Omni には、完全な会話履歴を確認し、エージェントが複数ターンのインタラクションをどのように処理するかを把握できる Session Explorer も用意されています。また、 Agent Topology ビューでは、サブエージェント、ツール、およびそれらの相互接続を含むエージェントシステムのアーキテクチャを可視化できます。任意のノードを詳細に確認して、パフォーマンスを調査し、ボトルネックを特定できます。 CloudWatch Omni には、IDE を使用せず、任意のブラウザーからアクセスできる専用の Web エクスペリエンスも用意されています。チームは、アプリケーションモニタリング、分析、エージェントのオブザーバビリティ、AI を活用した調査など、すべての機能に共同でアクセスできます。 図 8.アプリケーションモニタリング、分析、エージェントオブザーバビリティを備えた CloudWatch Omni ウェブエクスペリエンス トレースをキュレーションしてゴールデンデータセットにし 、構造化された実験を行いました。 Experiment 関数は 、データセットに対してエージェントを実行し、結果を自動的に評価します。プロンプトやエージェントのロジックが変更されるたびに、リグレッションテスト用のベンチマークを作成できます。 サポートされているフレームワークで構築されたエージェントがすでにある場合、CloudWatch Omniはインストルメンテーションを追加するための2つの方法を提供します。 1つはフレームワークを検出してトレースを自動的に設定する Auto-Instrumentswith Kiro 、 もう1つは Python と TypeScript 用のすぐに使えるコードスニペットを使った手動インストゥルメンテーションです 。詳細なインストルメンテーションガイドについては、 CloudWatch Omni ドキュメントを参照してください。 サポートされているフレームワークとオープンスタンダード 上記のチュートリアルではサンプルプロジェクトを使用していますが、CloudWatch Omni は、チームがすでに使用しているエージェントフレームワークにも対応しています。LangChain、LangGraph、CrewAI、OpenAI SDK、Strands、Vercel AI SDK など、Python と TypeScript の両。また、 Amazon Bedrock AgentCore で構築されたエージェントにネイティブなオブザーバビリティを提供し、AgentCore の評価機能を使用してエージェントの品質をオムニワークフロー内で直接評価します。 計測機能には、エージェントが Lambda、ECS、EKS、その他のクラウドのいずれで実行されている場合でも、オープンスタンダード（OpenInference および ADOT）が使用 。評価については、Omni は Braintrust、DeepEval、Ragas などのサードパーティー評価ツールと統合できるほか、組み込みのデータセット、プレイグラウンド、バッチ実験も利 。再プラットフォーム化は不要です。 CloudWatch Omni は、エージェントのオブザーバビリティとアプリケーションのオブザーバビリティを 1 つのエクスペリエンスに統合します。アプリケーションのオブザーバビリティ体験については、関連記事「 Amazon CloudWatch Omni の紹介:人工知能を活用したアプリケーションのコラボレーティブオブザーバビリティ 」を参照してください。 料金と利用可能なリージョン Amazon CloudWatch Omni が一般公開されました。IDE 拡張機能は自由に使用できます。開始するのに AWS アカウントは必要ありません。Amazon Bedrock のモデルを使用する場合は AWS 認証情報のみが必要で、OpenAI や Anthropic などの他のプロバイダーを使用する場合は API キーのみが必要です。 VS Code マーケットプレイスから拡張機能をインストールして 、今すぐ始めましょう。 すべての機能を調べてすぐに使い始めるには、 CloudWatch on AWS Builder Center にアクセスしてください。 API を呼び出したり、ドキュメントを検索したり、リージョンごとの提供状況を確認したり、この新機能に関するトラブルシューティングを確認したりする場合は、お好みの AI ツールで AWS MCP Server と プラグイン を使用してみてください。 AWS re:Post でフィードバックを共有するか、通常の AWS サポート の連絡先からお問い合わせください。 ハッピービルディング! – Daniel Abib 原文は こちら です。

Webやアプリケーション開発において「アクセシビリティ」や「ユーザー補助」という言葉を聞くと、皆さんはどう感じるでしょうか。「重要だとはわかっているけれど、開発コストがかかる」「一部のユーザーのための特別な対応」といったイメージを持つ方も少なくないかもしれません。 しかし、技術的な観点からアクセシビリティの構造を紐解くと、そこにはエンジニアにとっても合理的で、美しいアーキテクチャが存在します。 結論から言うと、アクセシビリティ対応とは「ユーザーのための特別なUIをゼロから作る」ことではありません。 「ユーザーが利用している環境（OSやブラウザなど）」と「アプリケーション」が正しくデータを連携し、歩み寄ることで初めて成立する仕組み なのです。 今回は、アクセシビリティのはじめの一歩として「環境とアプリの握手」について解説します。 ユーザーを支える強力な武器：「環境」の支援技術 アクセシビリティを考える上で大前提となるのが、デジタル環境へのアクセスを支える仕組みの大半は「環境側」にすでに用意されている、ということです。 現代のOS（iOS、Android、Windows、macOS）やWebブラウザには、ユーザーの多様な特性（視覚、聴覚、運動機能、認知など）を補助する高度な機能が標準搭載されています。これらは大きく2つのレイヤーに分けられます。 ユーザーエージェント（ブラウザなど）： ズーム、文字サイズへの対応、キーボード操作など、表示や操作を調整する機能。 支援技術（Assistive Technology）： スクリーンリーダー（VoiceOver / TalkBack 等）、スイッチコントロールなど、OSのAPIを通じてデバイスの操作を直接的に補助する機能。 ユーザーは自身の状況に合わせて、これらの機能をONにしたり設定を調整したりして、Webにアクセスしています。つまり、ユーザーから差し出された「握手のための手」は、すでに環境側に用意されているのです。 ただし、アクセシビリティのすべてを環境側が自動で担ってくれるわけではありません。アプリケーション自身も、十分なコントラストの確保、フォーカス順序の管理、適切な見出し構造などを責任を持って設計し、環境側と正しく連動する必要があります。 アプリケーション側の役割：情報のリレーと握手 ユーザーがスクリーンリーダーをONにしていれば、どんなWebサイトでも完璧に音声で操作できるのでしょうか？ 答えは「No」です。 どんなに環境側（ブラウザや支援技術）が優秀でも、アプリケーション側が「今、画面に何が表示されていて、どのボタンが押せるのか」という意味情報（セマンティクス）を伝えていなければ、支援技術は正しく機能しません。 Webの世界では、書いたコードは以下のように情報を伝達してユーザーに届きます。 1. Webアプリ (HTML / CSS / JavaScript)       ↓ 2. ブラウザ (ユーザーエージェント) ※DOMツリーと同時に「アクセシビリティツリー」を構築       ↓ 3. OSのアクセシビリティAPI       ↓ 4. 支援技術 (スクリーンリーダーなど)       ↓ 5. ユーザー ブラウザは画面を描画するDOMツリーとは別に、支援技術向けの裏側のデータ構造である「アクセシビリティツリー」を生成します。（※Chrome DevToolsの「Accessibility（ユーザー補助）」タブなどで実際に確認することができます）。 HTMLは、このアクセシビリティツリーを正しく構築するための「指示書」なのです。このリレーを途切れさせず、環境と正しく接続（握手）することこそが、エンジニアの役割です。 Microsoftサイトのアクセシビリティツリー Webフロントエンドにおける「歩み寄り」の具体例 具体的に「環境と握手する」とはどういうことか、実務でやりがちなアンチパターンと改善例を見てみましょう。 1. 適切なHTMLタグを使う（セマンティクスの伝達） NG： <div onClick={submit}>送信</div> 視覚的にはボタンに見えても、ブラウザには「buttonとしての役割（Role）」が伝わりません。その結果、スクリーンリーダーでボタンとして認識されないだけでなく、Tabキーによる「フォーカス移動」や、Enter/Spaceキーによる「標準的なキーボード操作」が不可能になります。 OK： <button onClick={submit}>送信</button> <button>タグを使うことで、ブラウザが持つ標準的なセマンティクスとキーボード操作モデルを利用でき、環境との握手がスムーズに成立します。 2. フォームの入力欄にラベルを紐付ける（関係性の伝達） NG： <span>お名前：</span><input type="text" /> 視覚的には「名前の入力欄」ですが、支援技術が入力欄にフォーカスした際、単に「テキスト、編集テキスト」としか読み上げられず、何を入力すべきか分かりません。 OK： <label for="name">お名前：</label><input type="text" id="name" /> <label> の for 属性と <input> の id を紐付けることで「これはお名前の入力欄だ」と明確に伝わります。さらに、ラベルの文字をクリックしても入力欄にフォーカスが当たるようになり、マウスユーザーの操作性も向上します。 3. アイコンボタンに意味を持たせる（ただしARIAは計画的に） NG： <button><img src="search-icon.png" /></button> 支援技術は何のボタンか判定できません。 OK： <button aria-label="検索"><img src="search-icon.png" alt="" /></button> aria-label などを付与することで、情報を補うことができます。 【注意】 ただし、W3Cには「ARIAの第一原則（The First Rule of ARIA Use）」というものがあります。それは「標準HTMLで表現できる場合は、まず標準HTMLを使う」というルールです。ARIAは万能薬ではなく、誤用すると支援技術を混乱させるため、あくまでHTMLの補助として利用しましょう。 4. フォーカスを見えるようにする（キーボード操作の担保） NG： *:focus { outline: none; } デザイン上の理由でフォーカスリング（枠線）を消してしまうと、マウスを使わずキーボードで操作しているユーザーは「今、画面のどこにいるのか」が全く分からなくなります。 OK： :focus-visible 擬似クラスなどを活用し、キーボード操作時のみフォーカスリングを表示するようスタイリングする。環境からのアクセス経路を視覚的に遮断しないことが重要です。 「環境」と「アプリ」の機能がオーバーラップする領域 ここで一つ、実践的な観点を付け加えます。OSやブラウザの標準機能と、アプリケーションが独自に提供する機能は、 役割がオーバーラップ（重複）している領域 が存在します。 例えば、自治体のサイトなどでよく見かける「文字サイズ変更（大・中・小）」のボタンです。 文字の拡大は、本来ブラウザのズーム機能やOSの設定で行えます。しかし、すべてのユーザーが環境の設定方法に習熟しているわけではないため、アプリ側があえて独自のUIを提供し、環境側の機能を「場合によっては補完」しているのです。 ここで誤解してはいけないのは、「アプリ側で独自にボタンを作ったから、環境側の設定は無視していい」というわけではないことです。独自の文字拡大ボタンを作ったからといって、ブラウザの標準ズーム機能を使った時にレイアウトが崩れてしまっては本末転倒です。 重要なのは、アクセシビリティ機能を追加すること以上に、既存の環境の機能を「壊さない」こと。ユーザーがブラウザの標準ズーム機能を使ったとしても、レイアウトが破綻せずコンテンツが利用できるような、Web本来の堅牢でレスポンシブな設計が求められます。 まとめ：情報を「標準的な形」で公開しよう アクセシビリティ対応の核心は、「アプリケーションが持つ情報を、OSや支援技術が理解できる標準的な形で公開すること」に尽きます。 ユーザーが伸ばした手（支援技術やブラウザの設定）に対して、アプリケーション側からもしっかりと手を握り返す（データを正しく渡す）。これが、エンジニアにおけるアクセシビリティ対応の真髄です。 明日からの開発で、ぜひ以下の「最初の一歩」を試してみてください。 キーボードだけで操作してみる： マウスを置き、Tab キーと Enter / Space キーだけで、自分が作ったアプリの主要な機能が使えるか確認する。 ツールで監査してみる： ChromeのLighthouseや、axe DevToolsなどのブラウザ拡張機能を使って、自分のローカル環境のコードをチェックしてみる。 「環境」と「アプリ」のデータ連携が結実したとき、書いたコードはより強固で、本当に多くの人に届くソフトウェアになります。ぜひ「ブラウザやOSとの対話」を意識した実装を盛り込んでみてください。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post アクセシビリティは「環境」と「アプリ」の握手である 〜Webの構造から紐解くエンジニアの役割〜 first appeared on SIOS Tech Lab .

目次 1. はじめに 2. 動作環境 3. 以前のバージョンとの比較 4. シーケンス図（概略図） 5. 準備 6. MCPサーバーのURL の取得 6.1. Elasticsearch / Agent / Tool の画面の表示 6.2. すべてのツールを管理 6.3. MCPサーバーのURLをコピー 7. API Key の発行 7.1. APIキー作成画面の検索 7.2. APIキー作成画面への遷移 7.3. APIキーの作成 7.4. APIキーのコピー 8. LM Studio からの MCPサーバー への接続手順 8.1. Developer Mode 8.2. mcp.json の編集 9. LM Studio での Local LLM のロード 10. MCPサーバーとの接続 10.1. mcp/elastic-agent-builder との接続 10.2. 利用する tool の選択 11. 問い合わせの実行 11.1. 問い合わせの実行 11.2. 処理の継続 11.3. 回答の確認 12. 注意事項 13. 参考URL 1. はじめに 「Pythonコード不要？Elastic AI Agent と ES|QL で実現する超シンプルな次世代RAG」のブログ で Elastic AI Agent を使って、「柿之助」についての質問に答える RAG を作成しました。 その際、「柿之助」に関するコンテキストを取得する手段として ES|QL を用いた Elastic AI Agent Tool を作成・登録しました。 本記事では、この Tool を MCP (Model Context Protocol) サーバーとして公開し、LM Studio などの MCPクライアントから外部ツールとして呼び出せる環境を構築してみます。 ※一般的には MCPサーバーは多様な役割を担いますが、本稿では「柿之助のコンテキストを提供するデータソース」としてシンプルに活用しています。 Elastic AI Agent Tool （の集合）をMCP サーバーとして公開するメリット： Claude Desktop や LM Studio などの標準的な MCP クライアントから、自作の Elastic 検索ロジック（ES|QL）をコンテキスト提供ツールとしてシームレスに呼び出せるようになります。 2. 動作環境 Elastic Cloud Enterprise License (Elastic Integration Service (EIS) 用に必要) Docker 実行環境 (筆者はWindows用のRancher Desktop 1.24.0を利用) MCPクライアント : LM Studio 0.4.25 Local Chat LLM : google/gemma-4-e4b ※Elasticsearch 9.5.3 (Trial License) は、自動的にダウンロードされます。 ※今回、MCPクライアントには LM Studio を利用しました。MCPクライアントに Claude Desktop などを利用することも可能です。　→　参考URL: Claude DesktopにElastic Agent BuilderのMCPサーバーを追加する方法 3. 以前のバージョンとの比較 2025年1月に作成した RAG アプリケーションとの比較表です。 項目 2025年01月版 今回版(MCP利用版) ベースとなる Elasticsearch のバージョン v8.16.0 v9.5.3 index.mode standard vectordb_document Machine Learning Node 必須 不要 (代わりにEISを利用) クエリーの言語 Query DSL ES|QL 密ベクトル生成用のモデル .multilingual-e5-small_linux-x86_64 .jina-embeddings-v5-text-nano (EIS経由) セマンティックリランク用モデル なし .jina-reranker-v3.5 (EIS経由) MCPサーバー なし Elastic AI Agent Tool MCPクライアント なし LM Studio 質問回答用LLM Cohere Command R (2024年12月版) google/gemma-4-e4b UI Streamlit LM Studio 4. シーケンス図（概略図） 5. 準備 Pythonコード不要？Elastic AI Agent と ES|QL で実現する超シンプルな次世代RAG の準備作業の 1 ～ 5.4 までを行い、以下が完了している状態にします。 Elasticsearch / Kibana のセットアップ ES|QLを用いた AI Agent Tool (kakinosuke.get_contents) の登録 ※なお、Elastic 側の AI Agent の登録は今回は不要です。 6. MCPサーバーのURL の取得 ※ Kibana の Display language : 日本語 としています。 6.1. Elasticsearch / Agent / Tool の画面の表示 Kibana にログイン後、Home / Elasticsearch / エージェント / ツール の画面を表示します。 6.2. すべてのツールを管理 右上の すべてのツールを管理 をクリックします。 6.3. MCPサーバーのURLをコピー ツールライブラリ画面が表示されるので、右上の MCPを管理 から MCPサーバーのURLをコピー をクリックします。 MCPサーバーのURLがクリップボードにコピーされるので、メモ帳などに貼り付けて記録しておきます。 今回は Docker 上で、HTTP で動作させているため、下記のような URL になるはずです。 http://localhost:5601/api/agent_builder/mcp 7. API Key の発行 7.1. APIキー作成画面の検索 上部の検索窓に api と入力します。「セキュリティ / APIキー」が検索結果に表示されるのでクリックします。 7.2. APIキー作成画面への遷移 [(+) APIキーを作成] をクリックします。 既に他のAPIキーが存在する場合、表示される内容が異なりますが、その場合も [(+) APIキーを作成] をクリックしてください。 7.3. APIキーの作成 APIキー作成画面が表示されます。 名前に MCPサーバーへのアクセス用とわかる名前を入力し、右下の [APIキーを作成] をクリックします。 名前 : mcp_server_api_key (例) ※注 本番運用では、有効期限の設定や、セキュリティ権限の制御を行うことを推奨します。 7.4. APIキーのコピー APIキーが作成されると、APIキーの作成完了画面が表示されます。 エンコーディング済のAPIキーの値をコピーします。 コピーした APIキーは、メモ帳などに貼り付けて記録しておきます。 もしも、この値を忘れてしまったら、APIキーを再作成してください。 8. LM Studio からの MCPサーバー への接続手順 8.1. Developer Mode LM Studio を起動し、Developer Mode を選択します。 Developer Mode の画面から [mcp.json] をクリックします。 8.2. mcp.json の編集 mcp.json の編集画面になるので、下記を貼り付けます。貼り付けが終わったら、mcp.json を保存します。 ※既存の設定がある場合は、それらの設定を削除しないように貼り付けてください。 ※mcp-remote の次の行のURLには、6.3. でコピーしたMCPサーバーの URL を貼り付けます。 ※YOUR_API_KEY== のところには、7.4. でコピーした APIキーの値を貼り付けます。 { "mcpServers": { "elastic-agent-builder": { "command": "npx", "args": [ "-y", "mcp-remote", "http://localhost:5601/api/agent_builder/mcp", "--header", "Authorization:${AUTH_HEADER}" ], "env": { "AUTH_HEADER": "ApiKey YOUR_API_KEY==" } } } } 9. LM Studio での Local LLM のロード LM Studio で使いたい LLM を選択してロードします。ここでは、google/gemma-4-e4b を選択しています。 この状態では、まだ、Elastic AI Agent Tool の MCPサーバーとは接続できていません。 10. MCPサーバーとの接続 10.1. mcp/elastic-agent-builder との接続 LM Studio の画面の右側に Integrations メニューが表示されます。 そこから mcp/elastic-agent-builder の左のスイッチを ON にします。 MCPサーバー (Elastic AI Agent Tool) との接続が行われます（少し時間がかかります）。 10.2. 利用する tool の選択 MCPサーバー (Elastic AI Agent Tool) との接続に成功すると、tool の一覧が表示されます。 今回利用したい tool は、kakinosuke_get_contents のみなので、それ以外のチェックを外します。 ※ Elastic 側では、kakinosuke.get_contents として登録しましたが、LM Studio 側には kakinosuke_get_contents として表示されます。 なお、MCPサーバーへの接続に成功すると、LM Studio のチャット入力欄に elastic-agent-builder が追加されて表示されます。 11. 問い合わせの実行 11.1. 問い合わせの実行 LM Studio のチャット入力欄に次の内容を入力します。 あなたは柿之助についての質問に答えるエージェントです。 # 指示1 与えられた質問を query とし、次の tool を呼び出して、結果の 5 件のドキュメントを受け取りなさい。 受け取った5件のドキュメントを指示2に渡しなさい。 - tool : kakinosuke_get_contents # 指示2 指示1 で取得した 5 件のドキュメントを元に、与えられた質問 (query) に答えなさい。 # 質問 柿之助の3人の家来は誰? 11.2. 処理の継続 途中で、「処理を継続するか？」の確認を求められるので、処理の継続を選択します。 11.3. 回答の確認 回答が次のように返ってきます（下記は回答例です）。 ご提示いただいた資料に基づくと、柿之助の3人の家来は**猫**、**ゴリラ**、そして**鷹**です。 資料には「猫と、ゴリラと、鷹と、これで三にんまで、いい家来ができたので」といった記述や、「宝物をいっぱい積んだ車を、猫が先に立って引き出しました。鷹が綱を引いて、ゴリラがあとを押しました。」という描写から、この3体が一緒に行動していることが確認できます。 LM Studio から MCPサーバーとしての Elastic AI Agent Tool へ接続し、必要なコンテキストを取得して、Local LLM に回答させることに成功しました。 12. 注意事項 公開単位の仕様： Elasticsearch の MCPサーバーは、登録されている Elastic AI Agent Tool の「集合（ライブラリ全体）」を公開します。個別の Tool のみを個別に絞り込んで公開することはできません。 通信の暗号化 (HTTPS)： 本稿ではローカル検証のため、Kibana を HTTP で動作させていますが、本番運用時は必ず HTTPS (TLS) で保護してください。 スペースの分離： 今回は検証用に Kibana の Default スペースを使用しましたが、本番環境では公開専用のスペースを作成・整理して運用することを推奨します。 API Key の権限最小化： 今回発行した API Key は検証用に有効期限や権限を設定していません。本番環境では、必要最低限のロール設定および有効期限を設定してください。 13. 参考URL Pythonコード不要？Elastic AI Agent と ES|QL で実現する超シンプルな次世代RAG Claude DesktopにElastic Agent BuilderのMCPサーバーを追加する方法 GitHubリポジトリ The post 自作の Elastic AI Agent Tool をMCPサーバーとして公開してみる。 first appeared on Elastic Portal .