はじめに さくらインターネットで高火力 PHYチームに所属している道下です。 本連載では、高火力 PHYで利用しているサーバーと同種のGPUサーバーを利用し、近年注目度を増しているLLMの分散推論基盤技術に関して詳細な技 […]

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 .

はじめに はじめまして。介護/障害福祉事業者向け経営支援「カイポケ」の事業部でCS職（カスタマーサクセス/サポート）をしているTSUNOです。カイポケに携わって10年以上になります。 エンジニアではありません。プログラミングの経験もありませんでした。 そんな私がAIを活用して業務自動化ツールを開発した結果、 月17.7時間の工数削減 と 購買判断の適正化 を実現しました。 この記事は、非エンジニアのCS職がAIで業務自動化を進めた実践記です。AIでここまでできるんだ、という実感を持ってもらえたら嬉しいです。 なぜやろうと思ったのか カイポケのCSでは、お客様からの問い合わせ対応だけでなく、カイポケを利用するうえでの事務手続きまで、お客様の業務を幅広く支えています。 2024年11月、業務体制の変更にともない、新たに業務を引き継ぐことになりました。 この業務は完了までに多くのステップがあります（下図）。引き継いだのはそのフェーズ2の部分でした。 複雑な作業を、ひたすら繰り返す。通常業務にこれらが上乗せされる状況では、とてもではないですが手が回りません。ちょうどその頃、無料版のChatGPTで簡単なGoogle Apps Script（GAS）を書く体験をしていました。もっと本格的にプログラムで業務を改善できるのではないか——そう考え始めたのが、すべての出発点です。 AI活用のステップアップ 最初から有料ツールを使っていたわけではありません。 無料ツールで小さく始めて、成果が出たら次のステップへ。その繰り返しで、気がつけば本格的な開発環境が整っていました。 大事なのは、 最初から大きな投資をする必要はない ということです。 時期 やったこと きっかけ 2024年1月〜 無償版ChatGPTでAI活用を開始 AI活用への興味 2024年11月〜 GASで業務自動化に着手 業務効率化の必要性が高まった 2025年1月頃 Google Workspace標準搭載のGeminiを活用 会社の環境変化 2025年11月 Claude Codeで本格的な開発へ AIツールの比較・検証を経て 2025年12月 Claude MAXプランへグレードアップ ROIを上司に提示して承認 ※ 各時期は筆者が知った・使い始めたタイミングであり、サービスのリリース時期とは異なります。 AI活用の情報収集は多方面から行いました。 X YouTube Google CloudユーザーコミュニティのJagu'e'r ※ Jagu'e'r （ジャガー） とは、Google Cloudユーザー企業が企業の垣根を超えて最新技術やノウハウを共有し合い、クラウド活用の変革を推進する公式コミュニティです。 特にJagu'e'rの無料ハンズオンセミナーでVertex AIに触れたことが、「APIを通じてAIを使う」というイメージを掴むきっかけになりました。この体験が後述するデータ移行支援ツールの技術選定につながりました。こうした外部の学びの場に加え、最近では社内エンジニア主催のClaude Code活用ナレッジ共有会にも参加しました。 よくわからなくても飛び込んでみると、新しい発見があるものです。 生成AIを使った3つの取り組み ここからは、AIを活用して取り組んだ3つの事例を紹介します。 # 事例 概要 1 GAS + 業務フローの見直し 6時間→2時間に圧縮 2 介護保険請求の事務手続きRPA※ 月17.7時間の工数削減 購買判断の適正化 3 AI駆動で開発中のデータ移行支援ツール 帳票の自動解析とデータ整形 ※ RPA（Robotic Process Automation）：人がブラウザやアプリ上で行う操作をプログラムで自動化する技術 1．最初の成功体験 — GASで6時間の業務を2時間に AI活用で最初に取り組んだのは、GASによる業務自動化です。 コードは主にChatGPTで生成・修正しました。自分でゼロから書いたわけではなく、「こういう処理がしたい」とAIに伝えて、出てきたコードを実行し、うまくいかなければエラーメッセージをAIに貼って修正する——このサイクルを回すことで、コードは着実に動くものになっていきました。 結果、1日あたり約6時間かかっていた業務が約2時間に圧縮されました。ただし、これはGASによる自動化だけの効果ではなく、業務フロー全体の見直し（不要な手順の廃止や作業順序の組み替え）との合算です。GAS単体の削減効果として切り出せる数字ではありませんが、ツールを作ること自体が業務を棚卸しするきっかけになったという意味で、大きな一歩でした。 2．介護保険請求の事務手続きRPA — 業務自動化の本格展開 前述の業務見直しの過程で「GASでは解決できない業務」も浮き彫りになりました。業務の中には、介護保険の請求手続きに使う外部システム上で、ログイン・画面操作・帳票出力といったブラウザ操作を行う工程が含まれていました。 このシステムには外部からプログラムで連携するための仕組み（API）が提供されておらず、ブラウザを人の手で操作するしかありません。こうしたブラウザ操作はGASの守備範囲外であり、自動化するにはブラウザそのものを操作するRPAが必要でした。 なお、外部システムをRPAで操作するにあたっては、利用規約の確認や社内のリスクマネジメント部門への事前相談を行ったうえで開発を進めています（詳細は後述の「外部システムを操作する上での配慮」で触れます）。 介護事業所がカイポケを通じて介護保険を請求するには、このシステム上で各種手続きを行う必要があります。これらの作業は、全都道府県にわたる多数のアカウントに対して日々行われます。 以前にもこの業務を自動化するRPAツールが作られたことがありました。しかし、運用環境の変化に対応しきれなくなり、最終的に役割を終えていました。業務は再び手作業に戻っていたのです。 GASで積み重ねた成功体験が、「自分で作ろう。エラーが出ても、AIに聞きながら対処できる」という確信を支えていました。 成果①：月17.7時間の工数削減 RPAによる自動化で、月に17.7時間（稼働日20日/月換算で、1日あたり53分）の業務時間が削減されました。2026年1月時点の実績です。これらの業務はお客様の増加とともに件数が増える傾向にあり、今後さらに削減効果が拡大する見込みです。 数字には表れない変化もあります。以前はルーチン対応で手一杯でしたが、時間が生まれたことで、お客様への進捗報告をより適切な頻度で届けられるよう設計し直す余裕ができました。自動化の本当の価値は、 削減した時間そのものではなく、その時間で何ができるようになるか にあると感じています。 成果②：購買判断の適正化 工数削減以上にインパクトが大きかったのが、購買判断の適正化です。 従来の運用では、外部システムにログインして処理件数を一つひとつ確認する必要があり、全体の正確な把握が困難でした。そのため、実態より多めにアカウントを購入せざるを得ない状況が続いていました。 RPAがこのログインと件数取得を自動で行うようになったことで、実際の利用状況が正確に見えるようになり、不要なアカウント購入を回避してコスト適正化を実現しました。 こうした削減効果の見込みをROIとして上司に提示し、AIツールの上位プランの利用承認を得ました。承認後の実績データでもその効果が裏付けられています。「ツールの利用料に対して、これだけの時間が浮く」という説明は、社内で予算を取るうえで有効でした。 データが見えるようになると、正確な判断ができる と実感した出来事でした。 3．AI駆動で開発中のデータ移行支援ツール データ移行支援ツールは、RPAと並行して開発を進めてきたもう一つのプロジェクトです。現在は検証フェーズであり、RPAのような確定した成果はまだありません。ここでは「完成していなくても、非エンジニアがAIと一緒にここまで到達できる」という過程をお伝えします。 何を解決するツールか カイポケを導入いただく際、お客様がこれまで蓄積してきたデータを、カイポケに登録したいというニーズがあります。その際、帳票（PDF）を目視で読み取り、手作業で転記する。これは時間がかかるだけでなく、ミスが起きやすい作業です。 データ移行支援ツールは、この帳票をAI（Geminiをチャット画面ではなくAPI経由で利用）で自動解析し、カイポケに取り込める形式に変換する仕組みです。 Geminiアプリから始まり、Claude Codeで成長した 最初はGeminiアプリのチャット画面上で、1つのプログラムファイル（.py）にコードを書いていく形でスタートしました。「この帳票のこの項目を読み取って」「エラーが出たから直して」とやり取りしながら、少しずつコードを育てていきました。 しかし、コードが1,600行を超えたあたりで限界が来ました。チャットが一度に扱える文脈の範囲（コンテキスト）にコード全体が収まりきらなくなり、修正のたびに前後関係が途切れるようになったのです。 そこで切り替えたのが「Claude Code」という、テキスト入力で操作する開発ツールでした。プロジェクト全体のファイルを把握しながら、エージェントのように自律的にコードを編集・実行してくれます。 Claude Codeに切り替えてからは開発速度が大幅に上がり、1,600行の単一ファイルだったコードは、役割ごとにファイルを分けた9,300行超の構成にまで成長しています。 時点 規模 開発環境 初期 約1,600行・単一の.pyファイル Geminiアプリのチャット画面 現在 約9,300行 + テスト約1,800行・複数ファイル構成 Claude Code AIに任せる部分と、任せない部分 開発を進める中で、正確性の高いデータソースを優先する設計にたどり着きました。介護保険の請求データは、仕様書でCSV形式として定義されています。これらはCSVから確実に取得し、CSVでは得られない情報だけを帳票PDFからAIに読み取らせる「ハイブリッド方式」を採用しています。 CSV形式で確実に取得できるデータを、あえて精度にばらつきのあるAI読み取りに回す理由はありません。AIは帳票の読み取りで誤認識を起こすことがあるため、確実な手段があるならそちらを優先する。どのデータをどの方法で取得するかの線引きにも、ドメイン知識が活きています。 ※ 個人情報を含むデータのAI処理にあたっては、エンタープライズ向けのセキュアなサービスを利用しています。 現在地 開発環境での検証を経て、クラウド上で動くWebアプリとして構築し、ブラウザからアクセスできる状態にまで持ってきました。前述のハイブリッド方式は、実データを用いた検証でも一定の精度で動作することを確認しています。現在は様々なパターンのプロンプト（AIへの読み取り指示）を調整しながら、対応できる帳票の種類を増やしているところです。自分以外のメンバーが使える状態にすることは今後の課題です。 完成にはまだ時間がかかりますが、非エンジニアによる業務改善の新しい可能性を示せたと考えています。ここからは、3つの事例を通じて得た実践的な学びを共有します。 非エンジニアがAI駆動開発を進めるためのプラクティス 非エンジニアがAIを活用して成果を出すためには、具体的な手法の前に、まずベースとなる「心構え」からお伝えします。 まず押さえておきたい4つの心構え 1. プログラミング経験より、深い業務フロー理解 業務を深く理解し、常に改善点を模索すること。 2. 人間は「要件定義と判断」、AIは「実装担当」 「何を作るか」「どんなエラーが危険か」「どのデータをAIに任せてはいけないか」。こうした判断は人間の役割です。具体的な指示を出し、AIをコントロールすること。 3. AIの出力は「たたき台」として受け取る AIは自信満々に間違えることがあります。コードの中身をすべて理解するのは難しくても、「この修正で何が変わった？」「意図した設計になっている？」とAIに確認することはできます。複数のAIにクロスチェックさせるのも有効です。鵜呑みにせず、自分の言葉で問いかける習慣を持つこと。 4. 小さく始めて、成果を積み重ねる 小さな自動化の成功体験が、次の挑戦への自信と原動力になりました。まずは手を動かしてみること。 実践＆組織で進めるための6つのプラクティス 心構えを土台として、私が実際にやってきた中で「これは他の人にも再現できる」と感じた具体的なアクションを6つにまとめました。 カテゴリ # プラクティス ひとことポイント 実践 1 AIへの指示は「業務の言葉」でいい 専門用語より「何を・なぜ・どうしたいか」 2 エラーは壁ではなく、手がかり エラーメッセージをAIに貼るだけで前に進める 3 テストもAIに書いてもらう ただし「業務的に正しいか」は人間が考える 4 環境構築は「AIに聞く → 裏取り → セキュリティ確認」 シャドーITを避ける手順を省かない 組織 5 成果を数字で見せて、リソースを得る ROIで上司の承認を得る 6 外部システムを操作する上での配慮 利用規約・社内承認・負荷配慮 1. AIへの指示は「業務の言葉」でいい プロンプトエンジニアリングだと身構える必要はありません。大事なのは、 業務の文脈を丁寧に伝えること です。データ移行支援ツールの開発初期に私がAIに伝えたのはこんな内容でした。 専門用語は一切使っていませんが、「何を・なぜ・どうしたいか」が明確なので、AIはセキュリティ設計、並列処理、エラーハンドリング、コスト表示まで一度に提案してくれました。「個人情報はログに出ないようにして」——こうした発想は、業務で日常的に個人情報を扱い、その重みを知っているからこそ生まれるものです。AIの出力品質を左右するのは、プログラミングの知識ではなく業務の知識です。 ただし、AIに任せきりでいい部分と、人間が厳密に設計しなければならない部分はあります。外部システムの仕様書を読み込み、帳票にどのような値が入ってくるのかを整理した上で読み取りのロジックを設計する——ここは業務を知っている人間が責任を持つ領域です。 2. エラーは壁ではなく、手がかり 非エンジニアにとって最大の壁は、エラーが出たときの対処です。でもやることは簡単で、 エラーメッセージをそのままAIに貼る だけです。実際の開発では、エラー対処を段階的にレベルアップさせていきました。 まず貼る — エラーメッセージをAIに貼って「これどうすればいい？」と聞く。大抵はこれで解決策が返ってくる 戦略を作る — エラーの種類ごとの対処方針をAIと一緒に設計する 仕組み化する — エラー発生時に画面キャプチャやHTML、処理ログを自動取得し、原因特定を容易にする ひとつ注意しておきたいのは、エラーは自分のコードだけから起きるわけではないという点です。Pythonのバージョンアップをしたところ、コードを一切変えていないのに、ライブラリが未対応でツールが動かなくなった経験もあります。「動いているものを維持する」難しさも学びでした。 3. テストもAIに書いてもらう 「このコードが正しく動くか確認するテストを書いて」とAIに頼めばテストコードは生成してくれます。ただし、AIが自動生成するのは「コードが技術的に正しいか」の確認です。 「業務的に正しいか」を確認するテストは人間が考える必要があります 。 たとえば「処理が中途半端な状態のまま放置されていないか」というテストシナリオは、実際の運用リスクを知っている人間にしか発想できません。AIに「こういうケースをテストしたい」と伝えれば、コード自体は書いてくれます。 4. 環境構築は「AIに聞く → ネットで裏取り → セキュリティ部門に確認」 必要なライブラリやセットアップ手順をAIに聞き、全体像を把握します。次にライセンス形態や開発元の信頼性をネットで裏取りします。その上で、社内のセキュリティ部門に「このツールを導入してよいか」確認します。 たとえばライブラリ導入時は、ライセンスが商用利用可能であること、開発元が信頼できることを確認した上で社内の専門部署に確認を取る——この手順を省かず、シャドーIT（会社の管理部門を通さずにツールを導入すること）を避けることが、長く使える仕組みにするための土台になります。 5. 成果を数字で見せて、リソースを得る 非エンジニアが業務時間を使って開発を進めるには、上司の理解が不可欠です。前述のとおり、削減効果を数字で示すことで上位プランの承認を得ました。 段階的にスケールし、各段階で成果を見せていくことで、次のチャレンジへの許可を得やすくなります。 6. 外部システムを操作する上での配慮 RPAの開発着手前に、以下の確認・配慮を行いました。 利用規約の確認 — RPAによる自動操作が明示的に禁止されていないことを確認 robots.txtの確認 — 対象システムにrobots.txt（RPAによるアクセス範囲を示すファイル）は設置されていないことを確認 社内承認 — リスクマネジメント部門に事前相談し、問題ないとの確認を取得 負荷への配慮 — 人間が操作するのと同等の速度で動作させ、未知のエラー発生時には自動停止する設計 おわりに — 属人化しない自動化を目指して 「あなたがいなくなったらどうなるの？」 ——避けられない問いです。実際、過去に社内で作られたRPAも引き継ぎがうまくいかず使われなくなった経緯があります。だからこそ、トラブルシューティングガイドや運用手順書といったドキュメントを整備するようにしています。そして何より、 AIがメンテナンスの「通訳」になれる 可能性に期待しています。コードを読めなくても、AIにエラーメッセージを貼れば対処法が返ってくる。作った人がいなくなっても回せる仕組みを作ること——その「属人化しない自動化」を目指して、今も試行錯誤を続けています。 データ移行支援ツールはまだ完成していません。模索中のことも多くあります。でも、非エンジニアだからこそ「使う側の目線」で作れる強みがある。業務を深く理解した人間にしか書けない要件定義がある。そしてAIが、その要件定義をコードに落とし込んでくれる。 自分で作るようになって、大きな気づきがありました。先述のPythonアップデートで動かなくなった経験を通じて、社内のエンジニアがフレームワークや基盤の更新に日々取り組む大変さを、身をもって理解できました。大規模なシステムを止めずに改善し続けるエンジニアの仕事に対する解像度が上がったことで、協業の質も変わったと感じています。非エンジニアが自分で作る経験は、エンジニアとの共通言語を増やすことにもつながるのです。 この記事を読んで、「自分もやってみよう」と思ってくれる方が一人でもいたら、書いた甲斐があります。最初の一歩は、「AIで何ができるか」を考えることではありません。「こんな作業が大変なんだよね」と、AIに壁打ちしてみること。そこに、活用のヒントがあるかもしれません。 追伸： 実はこの記事自体も、大部分をAIに書いてもらっています。構成案の作成、文章の推敲、さらには実際のプログラムと記事の内容に食い違いがないかの確認まで、AIと一緒に進めました。 ただし、「何を伝えたいか」「どんなストーリーで読者に届けるか」——その核となる設計は、自分の頭で考えました。AIは優秀な道具ですが、魂を込めるのは人間の仕事です。ツール開発もブログ執筆も、そこは変わらないと思います。