Elastic Inference Service (EIS) を使った「ベクトル検索」と「生成AIによる回答（RAG）」について、全2回にわたって解説します。 第1回となる今回は「準備編」として、環境構築からクラウド連携までを詳しく説明します。 目次 Elastic Inference Service (EIS) とは？ 本連載で実現できること システム構成イメージ 動作確認環境 サンプルコード ベクトル検索のための準備作業 1. 環境変数の準備 2. コンテナの起動 3. Elastic Cloud 連携 (Cloud Connect) 3.1. Self-Managed Kibana へのログイン 3.2. Cloud Connect 画面への移動 3.3. Elastic Cloud へのログインと接続 次回予告 Elastic Inference Service (EIS) とは？ Elastic Inference Service (EIS) は、Elastic Cloud 上で推論モデルをホスト・運用するためのマネージドサービスです。 従来、Self-Managed（オンプレミスや独自インスタンス）の Elasticsearch でベクトル検索やAI回答を行うには、自前で推論用ノードを構築・管理する必要がありました。EIS を活用することで、インフラ管理の手間を抑えつつ、強力なベクトル検索機能を Self-Managed 環境に組み込むことが可能になります。 公式ドキュメント: Elastic Inference Service (EIS) | Elastic Docs 本連載で実現できること 今回と次回の記事を通して、以下の機能を実装します。 Embedding: 外部モデルによるベクトル生成およびベクトル検索 Rerank: セマンティック・リランクによる検索精度の向上 Completion: LLM（OpenAI等）を利用した RAG（生成AI回答）の実現 システム構成イメージ 今回の構成は、Self-Managed 側のリソースを抑えつつ、計算負荷の高い推論処理を Elastic Cloud に委託するハイブリッドな構成です。 [Self-Managed Elasticsearch] <--- Elastic Cloud Connect ---> [Elastic Cloud (EIS)] Self-Managed 側に重いモデルをデプロイする必要がないため、既存環境への導入ハードルが低いのが特徴です。 [!CAUTION] 課金に関する注意 モデルの使用量に応じて、Elastic Cloud の利用料が発生します。検証の際は、トークン消費量やモデルの起動時間に十分ご注意ください。 動作確認環境 記事の執筆にあたり、以下の環境で動作を確認しています。 Elastic Cloud: Enterprise License Self-Managed Elasticsearch: v9.3.2 (Trial License) OS/Tool: Windows版 Rancher Desktop v1.20.1 利用モデル: Jina-embeddings-v5-text-nano Jina-reranker-v3 OpenAI-gpt-oss-120b-completion サンプルコード 本記事で使用するスクリプトや設定ファイルは、以下の GitHub リポジトリで公開しています。 GitHub:  SIOS-Technology-Inc/elastic-blogs/2026-03-eis ベクトル検索のための準備作業 ※作業には、ログイン可能な Elastic Cloud アカウントがあらかじめ必要です。 1. 環境変数の準備 リポジトリ内の  .env.sample  をコピーして .env を作成し、各項目を環境に合わせて編集します。 cp .env.sample .env 主な設定項目: ELASTIC_PASSWORD: Elasticsearch の elastic ユーザ用パスワード SAVEDOBJECTS_ENCRYPTIONKEY: 32文字以上のランダムな文字列（Kibana用） ES01_MEM_LIMIT: es01 コンテナに割り当てるメモリサイズ KIBANA_MEM_LIMIT: kibana コンテナに割り当てるメモリサイズ 2. コンテナの起動 Rancher Desktop 等の Docker ランタイムが起動していることを確認します。 docker-compose.yml  ファイル、および、  Dockerfile-es01  ファイルがあるディレクトリ上で以下のコマンドを実行します。 docker-compose up -d --build ※初回起動時はプラグインのインストールが走るため、完了まで数分かかります。 ※本構成は検証用のため、シングルノード構成となっています。 3. Elastic Cloud 連携 (Cloud Connect) 3.1. Self-Managed Kibana へのログイン ブラウザで  http://localhost:5601  にアクセスします。 User: elastic Password: .env で設定した ELASTIC_PASSWORD 3.2. Cloud Connect 画面への移動 Home > Management > Cloud Connect を選択します。 3.3. Elastic Cloud へのログインと接続 画面の指示に従い、Elastic Cloud へログインします。 Elastic Cloud にログイン後、Cloud Connect API Key を発行・コピーします。 取得したキーを Self-Managed 側の Kibana 画面に貼り付け、[Connect] をクリックします。 ステータスが正常になれば、Self-Managed 環境と Elastic Cloud の連携は完了です！ 次回予告 今回は、Cloud Connect を利用して Self-Managed Elasticsearch と Elastic Cloud を橋渡しする手順を解説しました。 次回（実践編）は、いよいよ EIS を通じてモデルを呼び出し、「ベクトル検索」と「生成AIによる回答（RAG）」を実際に動かしてみます。お楽しみに！ The post Elastic Inference Service (EIS) を使った「ベクトル検索」および「生成AIによる回答（RAG）」（準備編） first appeared on Elastic Portal .

こんにちは。ワンキャリアでデータエンジニアリングチームに所属している塚田（github：@carbscountry）です。 本記事では、AWS 上の RDS（PostgreSQL）の更新差分を GCP の Datastream で取得し、BigQuery へリアルタイム連携した取り組みについて紹介します。

こんにちは。香西です。 今回は、生成AI（Claude Code や GitHub Copilot など）と MCP（Model Context Protocol）を組み合わせて、AIに自由度が高く人間にもわかりやすいシステム構成図を .drawio.svg 形式で描かせるためのツール「 mcp-drawio-svg 」を作成し、OSSとして公開しました。 この記事では、開発に至った背景や、既存の作図ツール（Mermaidなど）が抱えていた課題、そして本ツールを使った実際の作図フローについて解説します。 コードは GitHub で公開しているので、ぜひ試してみてください。 https://github.com/Takashi-KOZAI-sti/mcp-drawio-svg なぜ作ったのか？ — 「AIにdraw.ioを書かせる」の落とし穴 生成AIが開発スタイルの主流になってくる中で、「AIにMarkdown形式でドキュメントを記述させる」というフローはすでに当たり前になりつつあります。それに伴い、インフラ構成図やシステム概要図などもAIに作図させたいというニーズが急速に高まっています。 「AIで図を描く」となれば、Mermaid や PlantUML が第一候補に挙がりますが、上流設計においては表現力不足（自由な配置、色味、公式アイコンの利用など）が否めません。そこで昨今トレンドになっているのが、**「生成AIに draw.io のファイルを作らせる」**というアプローチです。実際、ネット上でもこの手法を紹介する記事を多く見かけるようになりました。 しかし、真に業務でのドキュメント運用を考えたとき、既存のアプローチには 重大な課題 があると私は考えています。 それは**「エクスポートの手間と、ファイルの二重管理」**です。 通常、AIが出力した .drawio ファイルはそのままでは Markdown に埋め込めません。そのため、一度 draw.io でファイルを開き、PNG や SVG 形式でエクスポートして Markdown から参照する、という作業が必ず発生します。これを繰り返すと「図を更新したのにエクスポートし忘れて、設計書の画像が古いまま」という惨事が必ず起きます。 本当に私たちが欲しいのは、**「AIが作図してくれて、そのままMarkdownでプレビューでき、かつ後から人間が直接手直しできる」**という、シームレスな体験のはずです。 解決策：最初から「.drawio.svg」を出力させ、ローカルで完結させる この課題を根本から解決するために作成したのが、AIが構成図を .drawio.svg 形式 で直接生成するための MCP サーバー「 mcp-drawio-svg 」です。 本ツールの最大の強みであり、既存の「生成AI × draw.io」手法との明確な差別化ポイントは以下の2点です。 ① 「表示」と「編集」を1ファイルで両立するデュアルフォーマット 本ツールは .drawio ではなく、最初から .drawio.svg 形式を出力します。 これは draw.io が定義する特殊なSVGファイルで、画像データの中に編集用のソースデータが内包されています。 Markdownにそのまま埋め込める ：  と書くだけで、設計書に画像として表示されます。エクスポート作業は一切不要です。 1ファイルでそのまま編集可能 ：生成されたファイルを VS Code の draw.io 拡張などで開けば、通常の draw.io と同様にノードの移動やスタイル変更が可能です。 ② 機密情報を守る「完全ローカル動作」 社内システムのインフラ図やアーキテクチャ図には、外部に漏らしたくない機密情報が多く含まれます。外部の作図SaaSやAPIに構成データを投げて図をレンダリングさせる手法は、セキュリティの観点からエンタープライズでの導入ハードルが高くなります。 mcp-drawio-svg は、図のレイアウト計算やファイル生成の処理が すべてローカルマシンのMCPサーバー内で完結 します。構成データが外部に漏洩する心配がなく、セキュアな業務環境でも安心して利用できます。 mcp-drawio-svg ができること そこで作成したのが、AIが構成図・インフラ図・システム概要図を .drawio.svg 形式で生成するための MCP サーバー「 mcp-drawio-svg 」です。 AIに対して「こんな構成の図を作って」とお願いすると、AIがこのMCPサーバー（ create_drawio_svg ツール）を呼び出します。MCPサーバー側では、図の構成要素（ノード・エッジ・グループ）を JSON で受け取り、以下の処理を全自動で行います。 自動レイアウト計算 : 座標の指定は不要です。フロー方向やレイヤーを考慮して自動で配置を決定します。 アイコン解決 : simple-icons などから適切なアイコンを自動検索して適用します。（もちろん指定することもできます） ファイル生成 : 最終的な .drawio.svg ファイルを出力します。 実装・使い方 — AIに構成図を生成させる ここからは実際の設定と使い方です。今回は Claude Code などに組み込む例を紹介します。 1. セットアップ まずはリポジトリをクローンしてビルドします。 Bash git clone <https://github.com/Takashi-KOZAI-sti/mcp-drawio-svg.git> cd mcp-drawio-svg npm install npm run build 2. MCPサーバーとして登録 お使いの AI クライアントの MCP 設定に本ツールを追加します。 Claude Code の場合 ( ~/.claude/settings.json ) JSON { "mcpServers": { "drawio-svg": { "command": "node", "args": ["/path/to/mcp-drawio-svg/dist/index.js"] } } } 3. AI に「ざっくり」プロンプトを投げる ここが生成AI×MCPの便利なところです。人間がいちいちノードやエッジを細かく指定する必要はありません。 例えば、Claude Code であれば、以下のように 非常にざっくりとした依頼 をplan mode で投げると、MCPのインプットに合わせて構成等を考えてくれます。 あなた（ユーザー）： azure 上で構築するwebアプリの、典型的なインフラ構成図を記述してください。 アイコンについては、./icons ファオルダに使えそうなものを配置してあるので、適当に使ってください。 アイコンについては、あらかじめしてしておけばそれを使って図を作成してくれますし、なければsimple-icons からそれっぽいものをMCP側で当て込んでくれます。それでも該当するものがなければ、矩形での表示となります。 Claude Code（AIによる構成案の提案）： Azure Web App 典型インフラ構成図の作成プラン ノード & アイコンパス ノード アイコンパス Users general/10783-icon-service-Browser.svg Front Door & CDN web/10073-icon-service-Front-Door-and-CDN-Profiles.svg Application Gateway (WAF) networking/10076-icon-service-Application-Gateways.svg … グループ構成 Azure Subscription  (全体) Virtual Network  グループ Application Gateway, App Service, Function Apps Data Services  グループ SQL Database, Cache for Redis, Blob Storage Security & Identity  グループ Key Vault, Entra ID エッジ（接続） Users → Front Door Front Door → App Gateway App Gateway → App Service … レイアウト algorithm: layered, direction: RIGHT spacing: 70 あなた（ユーザー）： 「それでOK！」 これで、あとは、Claude Code がノードとエッジの情報を組み立てて、 create_drawio_svg ツールを実行し、アイコン付きの立派な .drawio.svg ファイルを出力してくれます。例えば、こんな感じ(中身のシステムの妥当性は今は気にしないでくださいね)。      4. 手修正と追加 自動生成らしく、一部エッジが交錯していたり、見にくかったりするので、ここは残念ながら手修正をおねがいします。ある程度調整しているつもりですが、残念ながら完璧な配置はなかなか難しいです。お手数ですが、例えば、こんな感じに修正してみてください。 これに対して、追加/削除を行っていくことも問題なくできます。   あなた（ユーザー）： 作成した drawio.svg をベースに、新しいdrawio.svg を作って欲しいです。 構成要素として、github を追加して、cicd をこの構成図に増やしてください。 今の構成図のレイアウトはそのままにしてください。 アイコンはやはり./icons フォルダから適当に探してください。 そうすると、AIは対象となる drawio.svg の構成を読み取るため read_drawio_svg を実行し、現在の図の構造を読み取ります。そして、 edit_drawio_svg を用いて手修正で変更したものを壊すことなく、新しいノード（画像右端のCI/CD Pipeline）を追加することができました。 デフォルトでは以前のレイアウトを残したまま新しいノードを追加する動作ですが、 layout_mode: "recompute” を指定すれば(AIにレイアウトを再計算しろと指示すれば)、すべてのノード位置を改めて再計算し、配置し直すことも可能です。ただし、自分で加えた微修正（ノード位置の修正やエッジの接続点の変更など）は再計算でもとに戻ってしまいますし、手作業で作成した図などは場合によっては原型を全く留めない場合もあるので、図を完全に新規で作り直したいときなどに限定して使用してください。 あとはこれの繰り返しで、期待する図を作成していくことができます。 人間とAIの理想的な役割分担（設計思想） このツールの根底にある設計思想は、**「人間が主導権を持ちつつ、面倒な作業をAIに任せる」**という理想的な役割分担です。 私が目指したのは、以下のような人間とAIの協働プロセスです。 【人間】大枠の指示を出す 「AzureでよくあるWebアプリの構成にして」「セキュリティ要件としてPrivate Endpointは必ず入れて」など、大まかなプランや絶対に外せないポイントを指示します。 【AI】詳細化と提案（たたき台の作成） 人間の指示を受けて、AIが必要な構成要素（各サービス、ネットワーク、接続関係）を具体的に洗い出し、構成案を提案します。 【人間】レビューと承認 提案内容を確認してOKを出します。これにより、**「論理的には100点、見栄え的には70点」**の構成図（ .drawio.svg ）が全自動で出力されます。 【人間】見栄えの最終仕上げ 出力された図を draw.io で開き、ノードの配置バランスや色使いなど、人間の感性が問われる「見栄え」の部分を100点に仕上げます。 つまり、 「大きな方向性の決定」と「感性が必要なデザインの最終調整」は人間が担当し、その間にある「構成要素の洗い出しから初期レイアウト（たたき台）の作成」をAIが担う 、という形です。 最初から真っ白なキャンバスに向かってアイコンを一つずつ配置していくのは、結構な手間ですよね。すでに論理的な接続が完了している70点の図を100点に引き上げる作業から始められるため、設計ドキュメント作成の負担が圧倒的に軽くなるというところです。 実運用に向けた環境構築とTips 第2章で触れた通り、 mcp-drawio-svg は完全にローカル環境で動作しますが、実際に業務等のプロジェクトに組み込む際には以下の点にご注意ください。 1. AIクライアントとMCPサーバー間のファイルアクセス 本ツールはローカルで .drawio.svg ファイルを直接生成・上書き保存します。そのため、Claude Code などの生成AIクライアントと、このMCPサーバーのプロセスは、 出力先のディレクトリに対して共通の読み書き権限 を持っている必要があります。 もしAIクライアントを Docker などのコンテナ内で実行している場合は、ホスト側のディレクトリを適切にマウントし、両者が同じファイルパスを正しく参照・編集できるように設定してください。 2. プロンプト（LLM）側のデータ管理 MCPサーバーの処理（レイアウト計算やファイル生成）において、構成データが外部の作図APIなどに送信されることは一切ありません。ただし、ユーザーがAIクライアントに入力する指示（「こういうシステム構成を作って」というプロンプト）自体は、当然ながらバックエンドのLLM（AnthropicやOpenAIなど）へ送信されます。 業務利用の際は、作図の処理自体はローカルで安全に行われていることを理解しつつ、利用するLLMプロバイダのデータ規約（学習への利用オプトアウト設定など）を自社のポリシーに合わせて適切に管理した上でご活用ください。 まとめと今後の展望 今回は、生成AI時代の新しい作図アプローチとして、 mcp-drawio-svg を紹介しました。 Mermaid のような「コード駆動の手軽さ」と、 draw.io の「表現力・直感的な編集のしやすさ」を両立させることで、開発現場のドキュメント作成・設計体験が劇的に向上するはずです。 コードは GitHub で公開していますし、ここでは紹介していない機能も実装していますので、ぜひ手元の環境で動かしていただき、日々のドキュメント作成に役立ててみてください！ https://github.com/Takashi-KOZAI-sti/mcp-drawio-svg おわりに（余談）：マネージャー職が「片手間」でOSSを作れる時代 最後に少しだけ、個人的な所感を書かせてください。 実は私、現在の会社ではマネージャー的ポジションにおります。旧来の日本企業の考え方からすれば、「管理職が自らコードを書いてツールなんか作っていないで、組織の利益最大化のためのマネジメント業務に専念しなさい」とお叱りを受けかねない立場です（笑）。 しかし、私は**「業務改善のヒントや組織の本当の強さの源泉は、常に現場にある」**と強く信じています。現場のペイン（今回の例で言えば、ドキュメント作図の煩わしさ）を解消する細やかな改善こそが、最終的に組織全体の大きな生産性向上に繋がるからです。 これまでは、こうした現場向けのニッチなツールを管理職が自ら作るのは、時間的にもリソース的にも困難でした。しかし、生成AIの登場で状況は一変しました。 AIに対して「こんな課題があるから、こういうアプローチで解決したい」とイメージを伝え、少しのやり取り（壁打ち）を行うだけで、 日々の業務の隙間時間に「ペロッと」具体的な動くものが作れてしまう のです。今回の mcp-drawio-svg も、季節柄の胃の痛くなる業務を行う傍らで、少し息抜きしながらAIという優秀なアシスタントの力を借りてサクッと形にしたものです。 さらに白状すると…… 実はこのブログ記事自体も、私がゼロから執筆したわけではありません。 私が「こういう構成で、こういうアピールポイントを入れて」と要点を箇条書きで投げただけで、あとは生成AIがいい感じに文脈を汲み取って、この原稿を書き上げてくれました。この余談くらいでしょうか、自分で書いたのは。(^_^;) アイデアと現場への課題意識さえあれば、ポジションに関わらず誰でも素早く形にできる。本当に素晴らしい時代になりましたね。 皆さんもぜひ、生成AIという強力なツールを使って、日々のちょっとした業務改善を形にしてみてください！ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【ローカルで完結】AIエージェントに”いい感じの”構成図を描かせるMCP「mcp-drawio-svg」を作りました first appeared on SIOS Tech Lab .