G-gen の杉村です。当記事では、Google Cloud の AI エージェント向けネットワークセキュリティ機能である Agent Gateway について解説し、仕様の把握や設計時の考慮事項の検討に役立つ情報を提供します。 概要 Agent Gateway とは アーキテクチャ メリット 通信制御 概要 通信制御の対象 Identity-Aware Proxy（IAP） Model Armor セマンティックガバナンスポリシー Service Extensions デプロイと運用 エージェントへのルール適用（Gemini Enterprise app） エージェントへのルール適用（Agent Runtime） Agent Gateway の使用を強制 プロジェクト構成 ロギング ドライラン ゲートウェイ ゲートウェイとは 設定値 デプロイメントモード Identity-Aware Proxy（IAP） IAM ポリシーとは 設定値 設定イメージ セマンティックガバナンスポリシー 概要 ネットワーク要件 技術的な詳細 プロトコル 通信の暗号化と認証 概要 Agent Gateway とは Agent Gateway は、AI エージェントが行う通信についてセキュアな接続とガバナンスを提供する、Google Cloud のセキュリティ機能です。 なお Agent Gateway は、Google Cloud が提供する AI 開発・運用プラットフォームである Gemini Enterprise Agent Platform （以下、Agent Platform）のコンポーネントの1つです。 Agent Gateway は「ユーザーとエージェント」「エージェントとツール」「エージェントと他のエージェント」の間の通信など、エージェントが行うさまざまな通信の出入り口として機能します。 組織のセキュリティ管理者は Agent Gateway を使うことで、エージェントに対するセキュリティとガバナンスポリシーを強制することができます。具体的には、明示的に許可されていない外部の API や MCP サーバー、他のエージェント等に対するエージェントからのリクエストを一元的に防いだり、Model Armor によるトラフィックの検査を強制することができます。 参考 : Agent Gateway overview なお、Agent Gateway を含む、AI エージェント開発プラットフォームである Gemini Enterprise Agent Platform の全体像については、以下の記事を参照してください。 blog.g-gen.co.jp アーキテクチャ Agent Gateway は、以下のようなイメージで、エージェントの通信を制御します。 Agent Gateway のアーキテクチャ Agent Gateway を使用することで、Google Cloud にホストされた AI エージェントの通信を一元的に統制できます。例として、リスクのある外部 API や MCP サーバーなどへのアクセスを拒否したり、不必要な AI エージェント間の通信を制限したりすることができます。 メリット Agent Gateway の導入により、AI 開発者とインフラ管理者（セキュリティ管理者）の双方に利点があります。 AI 開発者にとっての利点は、複雑なネットワーク管理やセキュリティのオーバーヘッドを意識することなく、エージェントの開発に集中できることです。mTLS ハンドシェイクの自動処理や、MCP、Agent-to-Agent（A2A）、REST、gRPC などによる通信の制御をプラットフォーム側でシームレスに行うことができます。また Agent Gateway は Cloud Monitoring や Cloud Logging と統合されているため、Agent Gateway を介することでオブザーバビリティが向上し、エージェントの動作の把握に役立ちます。 インフラ管理者（セキュリティ管理者）にとっては、エージェントの通信や外部システムへのアクセスに対して、一元的なガバナンスを効かせられるメリットがあります。また Identity and Access Management（以下、IAM）を用いた最小権限の原則の適用や、Model Armor を用いたプロンプトインジェクション保護などの AI セキュリティガードレールを実装できます。またエージェントと Agent Gateway の間では、Agent Identity や mTLS といった技術により自動的にセキュアな通信が確立されます。 通信制御 概要 Agent Gateway は、ゲートウェイを通過するトラフィックに対して、以下の仕組みを適用することでエージェントの通信を制御します。 名称 説明 適用可能なゲートウェイ Identity-Aware Proxy（IAP） エージェントから他のエージェント、MCP サーバー、API エンドポイントへの呼び出し可否を制御 egress モードのみ Model Armor LLM への入出力（プロンプトとレスポンス）を検査して危険なコンテンツをブロック egress / ingress モード セマンティックガバナンスポリシー（SGP） 自然言語でルールを記述してエージェントのツール呼び出しや Agent Skills 呼び出しを制御 egress モードのみ Service Extensions カスタム認可エンジンをゲートウェイに統合 egress / ingress モード 参考 : Agent Gateway overview - Access control policies Agent Gateway を適切に設定すると、制御対象のエージェントの外部への通信や LLM とのデータ入出力がゲートウェイによってインターセプト（傍受）されて、上記の仕組みにルーティングされて評価され、その結果としてブロックされたりロギングされたりします。 それぞれ、egress / ingress モードのどちらのゲートウェイに適用できるかが決まっています。ゲートウェイのデプロイモードについては後述します。 なお、トラフィックがゲートウェイによって検査されるようにするためには、Agent Gateway を展開するだけでなく、 エージェント側にも設定が必要 です。既存および新規にデプロイされるエージェントが Agent Gateway を必ず経由するようにするためには、後述する組織のポリシーを設定する必要がある点に注意してください。 通信制御の対象 Agent Gateway が通信制御の対象にできるのは、以下の環境で動作するエージェントのみです。 Agent Runtime （旧称 Vertex AI Agent Runtime） Gemini Enterprise app 上記以外の環境にホストされているエージェントは、Agent Gateway による制御の対象外です。 参考 : Agent Gateway overview - Agent runtimes Agent Runtime にホストするエージェントの場合、Agent Gateway の制御対象とするには、以下の条件があります。 エージェントのデプロイ時にゲートウェイを明示的に指定している エージェントが Agent Identity を持っている 同一プロジェクトの同一リージョンでは同じ Agent Gateway（egress / ingress ごと）に紐づける Agent Runtime のエージェントについては、組織のポリシーを使うことで、必ず承認されたゲートウェイを指定しないとデプロイできないように統制可能です。 参考 : Route Agent Runtime traffic through Agent Gateway 参考 : Route Agent Runtime traffic through Agent Gateway - Restrict Agent Runtime to approved Agent Gateways Gemini Enterprise app のエージェントの場合、アプリの管理設定で、使用するゲートウェイを明示的に指定する必要があります。 参考 : Route Gemini Enterprise traffic through Agent Gateway Identity-Aware Proxy（IAP） Agent Gateway は Identity-Aware Proxy （以下、IAP）の仕組みを使って、エージェントから他のエージェント、MCP サーバー、API エンドポイントへの呼び出し可否を決定します。 IAP による通信制御が使用できるのは Agent-to-Anywhere（egress）モードのゲートウェイのみです。Client-to-Agent（ingress）、つまりエージェントに入ってくる通信を IAP で制御することはできません。よって、Agent Gateway を介さないエージェントの呼び出しについては、エージェント側の認証・認可やネットワーク制御で適切に担保する必要があります。 制御のルールは、 IAM ポリシー によって定義します。詳細は後述します。 Model Armor Model Armor は、Google Cloud が提供する LLM 用の保護機能であり、LLM へのインプット（プロンプト）と出力されるアウトプット（レスポンス）を検査するサービスです。ゲートウェイで Model Armor を有効化すると、ゲートウェイを通るプロンプトやレスポンスが検査されるようになります。 Model Armor についての詳細は以下の記事を参照してください。 blog.g-gen.co.jp セマンティックガバナンスポリシー セマンティックガバナンスポリシー （Semantic Governance Policy、以下 SGP）は、自然言語を使って定義するセキュリティポリシーです。エージェントのツール呼び出し時や Agent Skills の呼び出し時に評価され、ユーザーの意図と組織のルールの両方に合致しているかどうかがチェックされます。 SGP は自然言語で定義され、LLM によって評価されるため、動的にポリシーを適用できるのが特徴です。SGP についての詳細は後述します。 参考 : Configure semantic governance policies Service Extensions Service Extensions を使うことで、独自の認可エンジンやサードパーティのエンジンに認可を委任できます。日本語の Google Cloud コンソール上では「サービス拡張機能」などと表記されます。 Service Extensions はもともと、Cloud Load Balancing と Cloud CDN の機能拡張のためにリリースされた機能であり、軽量な処理を Rust、Go、C++ などの言語で記述してアドオンできるプラグイン機能です。そのうちの Authorization extensions と同じ基盤を用いているのが、Agent Gateway の Service Extensions 機能です。 参考 : Delegate authorization with Service Extensions 参考 : Cloud Load Balancing and Cloud CDN extensions overview なお Agent Gateway でゲートウェイを作成して IAP を有効化したり Model Armor を有効化すると、それぞれに対応した Service Extensions が自動的に作成されます。Agent Gateway のバックエンドでは、実質的にこの Service Extensions が動作していることがわかります。 ゲートウェイ詳細画面 デプロイと運用 エージェントへのルール適用（Gemini Enterprise app） Gemini Enterprise app のエージェントに Agent Gateway の統制を適用するには、アプリの管理設定において、明示的にゲートウェイを指定します。 使用するゲートウェイは、アプリの管理画面の「セキュリティ > 構成」画面から設定できます。 また、Discovery Engine サービスエージェントと呼ばれる特殊なサービスアカウントに、所定の権限を付与する必要がある点にも注意してください。詳細は公式ドキュメントを参照してください。 参考 : Route Gemini Enterprise traffic through Agent Gateway エージェントへのルール適用（Agent Runtime） Agent Runtime にホストするエージェントを Agent Gateway の制御対象とするには、以下の条件があります。 エージェントのデプロイ時にゲートウェイを明示的に指定する エージェントが Agent Identity を持っている 同一プロジェクトの同一リージョンでは同じ Agent Gateway（egress / ingress ごと）に紐づける なお、ゲートウェイを作成するより前に既にデプロイされていたエージェントについては、ゲートウェイを指定してデプロイし直す必要があります。 参考 : Route Agent Runtime traffic through Agent Gateway Agent Gateway の使用を強制 組織のポリシーのカスタム制約を使用すると、Agent Runtime にデプロイされるエージェントが特定のゲートウェイを必ず使用するように強制することができます。組織としての統制のため、全エージェントのトラフィックが必ず Agent Gateway を通過するようにするためには、以下のドキュメントを参考にして組織のポリシーのカスタム制約を設定してください。 参考 : Route Agent Runtime traffic through Agent Gateway - Restrict Agent Runtime to approved Agent Gateways これらにより、組織内で Agent Gateway の使用を強制し、エージェントの通信に統制を効かせることができます。 プロジェクト構成 Agent Gateway のゲートウェイと、制御対象の Agent Runtime エージェントは、 同一プロジェクト ・ 同一リージョン に存在している必要があります。Gemini Enterprise app を制御対象とする場合も同様に、Agent Gateway のゲートウェイと、Gemini Enterprise app のアプリは同じプロジェクト・対応するリージョンに存在している必要があります。 よって組織全体でエージェントに対する統一した統制ルールを設定し、それを単一チームで運用するには、例として以下のような構成が考えられます。 案1: エージェントは単一の Google Cloud プロジェクトにデプロイ（組織のポリシーで制御）する。このプロジェクトで管理チームによって Agent Gateway が管理されている。 案2: 開発者チームごとに Google Cloud プロジェクトを払い出す。エージェントはそれらのプロジェクト内に存在している。Agent Gateway は管理チームが IaC 等で管理し、各プロジェクトに展開する。 案1 の構成では、エージェントデプロイ用の権限を持ったサービスアカウントを開発者チームに借用させたり、あるいは開発者チームにデプロイ権限を付与する、または CI/CD パイプラインによる自動デプロイでゼロタッチな本番デプロイをさせる、などによって実現することが考えられます。 案1: ゲートウェイを中央管理 ロギング Agent Gateway を通過するトラフィックは、Cloud Logging によって記録されます。ログには以下のような情報が含まれます。 タイムスタンプ Agent Registry リソース名（呼び出し元エージェント、呼び出し先の MCP サーバーなど） MCP のメソッド名（tools/call など） アクセス制御を処理した Service Extensions 拡張機能の情報 このログは、設定ミス等のトラブルシューティングのほか、ドライランモードで動作させている場合のポリシー監査に役立ちます。 ログエントリは networkservices.googleapis.com/Gateway リソースタイプとして記録されます。ログエクスプローラで以下のようなクエリを実行することで、Agent Gateway が出力したログを抽出できます。 resource. type=" networkservices.googleapis.com/Gateway " 参考 : Monitor traffic through Agent Gateway ドライラン 既存のエージェント環境に Agent Gateway を適用する場合は、事前にドライランを行って設定が適切であることを確かめてから、ポリシーを実際に適用することが推奨されます。 ゲートウェイの「アクセス認可」設定を「監査のみ」に設定することで、ロギングのみが行われブロックは行われないように設定されます。トラフィックのログは、前述のとおり Cloud Logging で確認できます。 ゲートウェイ ゲートウェイとは ゲートウェイ （Gateway）は、Agent Gateway の管理単位です。Google Cloud プロジェクト内に作成します。ingress モードと egress モードがあり、プロジェクト内に複数作成できます。 参考 : Set up Agent Gateway 設定値 ゲートウェイの作成時には、以下のような設定値を指定します。 リージョン ゲートウェイを展開するリージョンを指定します。制御対象の Agent Runtime のエージェントと同じリージョンを指定する必要があります。制御対象が Gemini Enterprise app のエージェントであれば、Gemini Enterprise app のアプリを作成したリージョンに対応したリージョンを指定する必要があります。例として Gemini Enterprise app のアプリが global リージョンにあれば、ゲートウェイは us-central1 に配置する必要があります。 Agent Registry ゲートウェイが制御対象とする Agent Registry のレジストリを指定します。制御対象の Agent Runtime エージェントと同じリージョンのレジストリを指定します。対象レジストリはグローバルレジストリ、リージョンレジストリ、US マルチリージョンレジストリ、EU マルチリージョンレジストリのいずれかから選択する必要があり、 //agentregistry.googleapis.com/projects/my-project/locations/asia-northeast1 のようにプロジェクト ID とロケーションの組み合わせで表されます。 デプロイメントモード（管理対象アクセスパス） Google Cloud コンソール上は「管理対象アクセスパス」、公式ガイド上は「デプロイメントモード」と表記されています。Client-to-Agent（ingress）または Agent-to-Anywhere（egress）から選択します。作成するゲートウェイが、エージェントに入ってくる通信を制御するものなのか、エージェントから出ていく通信を制御するものなのか、を決定する設定値です。詳細は後述します。 アクセス認可 デプロイメントモードが「Agent-to-Anywhere（egress）」のときだけ指定可能です。「監査のみ」または「ポリシーを適用」から選択します。前者を指定した場合はドライランとなり、ログが記録されるのみで、実際のアクセス制御は適用されません。後者の場合は、実際に IAM を使用したアクセス制御が適用され、明示的な許可がされていない通信はブロックされます。まずは前者でテストを行い、ポリシーが適切であると確かめられたら後者に変更する運用が想定されます。 Model Armor Model Armor の使用有無と、使用するテンプレートを指定します。 デプロイメントモード Agent Gateway には2つの デプロイメントモード （Deployment modes）があります。デプロイメントモードは、ゲートウェイを作成するときに選択します。Google Cloud コンソール上では「管理対象アクセスパス」と表記されています。 Client-to-Agent（ingress） Agent-to-Anywhere（egress） なお Google Cloud コンソール上では、前者は 「クライアントからエージェントへ（内向き）」、後者は「エージェントから任意の宛先へ（外向き）」と表記されています。 図左寄りが ingress モード、右寄りが egress モード Client-to-Agent（ingress） Client-to-Agent（ingress）は、クライアント（Claude Code、Gemini CLI、Antigravity CLI など）からエージェントへの通信を保護するためのモードです。エージェントに入ってくる通信に対して Model Armor のルールなどを適用できます。 Agent-to-Anywhere（egress） Agent-to-Anywhere（egress）は、エージェントから外部のサーバー、他のエージェント、ツール、MCP サーバー、API などへの通信を保護するモードです。IAP と IAM ポリシーによる認可や、Model Armor による検査などが適用できます。 Identity-Aware Proxy（IAP） IAM ポリシーとは ゲートウェイを通るトラフィックは、Identity-Aware Proxy（IAP）により検査されます。このとき IAP は IAM ポリシー （IAM policies）を使ってトラフィックを評価します。デフォルトではすべてのトラフィックが拒否されますが、ポリシーで指定されたソースとターゲットに合致したトラフィックであれば、許可されます。 参考 : IAM policies overview 参考 : Create IAM agent policies Agent Gateway における IAM ポリシーの実体は、IAP リソースが持つ IAM 許可ポリシーです。この概念を正確に理解するには、Identity and Access Management（IAM）の基本的な仕組みと、許可ポリシーについての理解が必要です。以下の記事も参照してください。 参考 : Google CloudのIAMを徹底解説！ - G-gen Tech Blog 設定値 IAM ポリシーは「Google Cloud コンソールの Agent Platform > エージェント > Policies」画面や gcloud コマンドラインを使い、プロジェクト内に複数作成できます。IAM ポリシーには、以下のような設定値があります。 参考 : IAM policies overview ‐ Policy components 接続元エージェント（ソースエージェント） アクセスを許可する対象の、接続元エージェントです。ゲートウェイに紐づけられたすべてのエージェントを指定することもできますし、個々のエージェントを指定することもできます。 ターゲット ポリシーが認可する接続先（ターゲット）を定義する設定値です。ターゲットとしては、Agent Registry に登録されているエージェント、MCP サーバー、API エンドポイントを選択できます。また、特定の Agent Registry に所属するすべてのターゲットを許可することもできます。 条件（Condition） 通常の IAM 許可ポリシー同様、条件（Condition）を指定することもできます。ただし指定可能な条件には制限があります。詳細は公式ガイドを参照してください。 設定イメージ Google Cloud コンソールの設定画面では、以下のスクリーンショットの上部の赤枠がソースエージェント、下部の赤枠がターゲットを指します。 IAM エージェントポリシー作成画面 ターゲットの Agent Registry としては、 グローバルレジストリ とリージョンごとの リージョンレジストリ が選択できます。Agent Registry では、エージェントや MCP サーバー、API エンドポイントを登録する際に、登録先としてグローバルレジストリまたはリージョンレジストリが選択できるので、対象が登録されているレジストリを適切に選択する必要があります。 グローバルレジストリまたはリージョンレジストリ セマンティックガバナンスポリシー 概要 セマンティックガバナンスポリシー （Semantic Governance Policy、以下 SGP）は、自然言語を使って定義するセキュリティポリシーです。エージェントのツール呼び出し時に評価され、ユーザーの意図と組織のルールの両方に合致しているかどうかがチェックされます。 参考 : Configure semantic governance policies 例として、出張手配エージェントが、宿泊先の手配をするツールを呼び出すケースを考えます。ツールは宿泊先の予約 API を実行するものですが、呼び出しの際に SGP が評価され「2万円を超える金額の自動的な決裁は禁止する」というルールに抵触している場合は、事前の設定に応じてツールの呼び出しを中止するか、人間の承認を求めます。このように、内容によって動的にポリシーを適用できるのが SGP の特徴です。 また SGP は、Agent Skills のロードに関するエージェントの挙動も傍受して制御できます。エージェントが実行する list_skills 、 load_skill 、 run_skill_script ツールなどを傍受して、ポリシーを適用できます。 ネットワーク要件 SGP を Agent Gateway で有効化するには、VPC ネットワークやプロキシ専用サブネット、Cloud DNS のプライベート DNS ゾーン、Private Service Connect エンドポイントなど、追加のネットワークコンポーネントが必要です。 参考 : Configure semantic governance policies ‐ Configure SGP policies and the SGP engine 技術的な詳細 プロトコル Agent Gateway は、MCP、A2A プロトコル、REST、gRPC など、HTTP ベースのトラフィックをサポートします。通信のペイロードは暗号化されます。 なお、エージェントの開発に使用するフレームワークは問いません。Agent Development Kit（ADK）でも、LangChain など Google 以外から提供するフレームワークでも、Agent Gateway で制御できます。 参考 : Agent Gateway overview - Key benefits 通信の暗号化と認証 ゲートウェイとエージェントとの間の通信は、mTLS（相互 TLS）によって暗号化されており、また Agent Identity に基づいて Demonstrable Proof of Possession（DPoP）による所有権証明も行われます。 これにより、エージェントになりすましたリクエストが困難になり、セキュリティが確保されます。 参考 : Agent Gateway overview - Integration with the Agent Platform ecosystem 参考 : IAM policies overview - IAP and Context-Aware Access provide end-to-end security Agent Identity については以下の記事で詳細に解説されています。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

1年ほど前に、日本語アナライザーを比較する記事を書きました。 前回の記事： 日本語アナライザーの比較（Kuromoji / Sudachi / MeCab / LLM の性能検証） あれから1年がたち、日本語の検索まわりは少しずつ変わりました。 新しい選択肢も出てきましたし、考え方も少し変わりました。 そこで今回は、続編としてもう一度比較します。 ただし、前回とまったく同じことを繰り返すわけではなく、 2026年の今なら、こう測るともっと良い、というやり方で見直します。 今回の検証は「去年と同じ条件での定点観測」ではありません。そのため、今回の数値を前回のものとそのまま比較できません。 検証に使用したプログラム等は GitHub リポジトリで公開しています。同リポジトリ内の GLOSSARY.md にまとめた用語集を参照してください。 目次 この記事で見ること、見ないこと この1年で変わったこと 1. 既存のアナライザーは、ちゃんと進化していた 2. 「Elasticsearch の中で使えるか」で整理すると分かりやすい 3. いちばん大きな変化：形態素解析に頼らない検索 4. LLM は「アナライザー」ではなく「参考枠」 今回の改良点（前回との違い） 再検証：実際に比べてみる 使うテキスト 比べるアナライザー 結果：トークン数 結果：専門用語の扱い 結果：アナライザー間の似ている度合い（Jaccard） 結果：検索クエリでの動作 参考：LLM は何を「キーワード」として拾ったか アナライザーの選び方ガイド まとめ Links この記事で見ること、見ないこと 先に、ゴールを明確に整理します。 読みながら「結局なにを比べているの？」と迷わないためです。 この記事で見ること： それぞれのアナライザーが、日本語をどう単語に区切るか。 検索用のトークンとして、どれが使いやすいか。 専門用語・英数字・単位（例：NSAIDs、300〜500mg）が保たれるか。 実際の検索クエリで、目的の文書がちゃんとヒットするか。 この記事で深くは扱わないこと： 大規模なデータでの検索ランキング評価。 人手による「この結果は正しい」という関連度判定。 LLM を Elasticsearch のアナライザーとして使う構成。 この1年で変わったこと 1. 既存のアナライザーは、ちゃんと進化していた まず押さえたいのは、定番のツールは止まっていない、ということです。 Kuromoji は、Elastic 公式の日本語アナライザーとして引き続き使えます。 Sudachi は、外部プラグイン（Works Applications の elasticsearch-sudachi）として進化を続け、 新しい Elasticsearch にも対応してきました。 Sudachi の辞書は、数か月おきに新語が追加されています。 MeCab や Janome も、Python 前処理用の選択肢として現在も利用されています。 ここで大事なのは、Kuromoji と Sudachi の「立場」が違うことです。 – Kuromoji は Elastic 公式 の Japanese analysis plugin です。 – Sudachi は 外部プラグイン です。 つまり、Sudachi を使うときは、 使っている Elasticsearch のバージョンに対応しているかを必ず確認します。 2. 「Elasticsearch の中で使えるか」で整理すると分かりやすい ここで混乱しやすいのが、「結局どのアナライザーを Elasticsearch で使えるの？」という点です。 実は、全部を同じようには使えません。 3つのグループに分けると分かりやすいです。 Elasticsearch の中で動く（プラグイン）：Kuromoji（公式）、Sudachi（外部）。 Elasticsearch の中では動かない：MeCab、Janome、Lindera。 これらは Python などで先にトークン化し、その結果を Elasticsearch に入れて使います。 番外（参考枠）：LLM。これはアナライザーとは目的が違います（あとで説明します）。 さらに、実行環境による違いもあります。 Self-Managed（自前で運用）：   Kuromoji などの公式プラグインは、各ノードに analysis-kuromoji をインストールし、ノードを再起動して使います。外部プラグイン（Sudachi など）も入れられます。 Elastic Cloud Serverless： Kuromoji などの core analysis plugins は最初から利用できます。 一方で、外部プラグインの追加や、独自ファイルのアップロードはできません。 そのため、Sudachi などの外部プラグインや、ファイルとして配置する独自辞書（synonyms / stop words / language analyzer 用 dictionary files など）を前提にした構成は使えません 。 ただし、同義語についてはファイルアップロードではなく、synonyms API を使って管理できます。 3. いちばん大きな変化：形態素解析に頼らない検索 一言でいうと、この1年で「検索のやり方そのもの」に選択肢が増えました。 これまでの日本語検索は、形態素解析で単語に区切り、その単語で探すのが基本でした。 これは今も有効で、なくなりません。 ただ、もう1つの道が実用的になりました。 意味で探す検索（セマンティック検索） です。 仕組みをシンプルにいうと、こうです。 文章を「意味のベクトル（数字の並び）」に変換し、意味が近いものを探します。 このとき、形態素解析で単語に区切る必要はありません。 Elasticsearch では、semantic_text という仕組みと、 EIS（Elastic Inference Service）経由の多言語の埋め込みモデルを使うことで、 日本語でもこの検索がぐっと手軽になりました（例として、EIS では Jina Embeddings v5 系や Microsoft Multilingual E5 Large などの embedding model が利用できます）。 実務で考えると、これは大きいです。 「ロキソニン」と入れなくても、「痛み止め」で関連文書を拾える、というような検索ができます。 本番環境では、既定の inference endpoint に依存せず、利用する埋め込みモデルの inference_id を明示するのが安全です。既定モデルはバージョンや環境によって変わる可能性があり、複数インデックスで異なる embedding model が混在するとランキングに影響するためです。 4. LLM は「アナライザー」ではなく「参考枠」 前回は LLM（当時は GPT-4o）も比較に入れました。 今回も LLM を見ますが、立ち位置をはっきり分けます。 なぜかというと、LLM はインデックス用のトークナイザーとは目的が違うからです。 LLM を、Kuromoji や Sudachi と横並びにして「どれが良いアナライザーか」と比べると、 かえって混乱します。 そこで今回は、LLM を別カテゴリ（参考枠）として、次の点だけ見ます。 専門語を「意味のまとまり」として拾えるか。 検索の補助（キーワード抽出や意味理解）に使えそうか。 ここで、混同しやすい点を1つ整理します。 「LLM によるトークン分割は再現性がない」という声もありますが、必ずしもそうとは限りません。 LLM の tokenizer そのものは、同じ条件なら基本的に同じ結果になります。 バラつくのは、「重要語を抜き出して」とお願いしたときの 生成結果 のほうです。 なので今回は、再現できるように、モデル名・プロンプト・temperature を記録します。 今回の改良点（前回との違い） 前回より良くした点を、正直に宣言します。 詳しくは METHODOLOGY.md を見てください。ここでは要点だけ。 正規化を「入口」でそろえる。 Python で NFKC 正規化を1回だけかけ、同じ入力を全アナライザーに渡します。 機能語の除去を「品詞ベース」に統一する。 手書きのストップワード一覧ではなく、助詞・記号などの品詞でそろえて除きます。 Kuromoji を「正解」と決めつけない。 類似度を1つの数字で出すだけでなく、全アナライザー間の一致や、専門語の扱いも見ます。 実際の検索クエリで動作を確認する。 トークンが似ているかだけでなく、「探したい文書が見つかるか」を見ます。 バージョンを記録する。 Elasticsearch・プラグイン・辞書・ライブラリ・LLM の情報を残し、来年また比べられるようにします。 再検証：実際に比べてみる 使うテキスト 医療系のテキストを2つ使います。 Text 1：ロキソニンの説明文（前回と同じ、短めの文）。なじみのある例として。 Text 2：アセトアミノフェンの説明文（今回のために書き下ろした、少し長い文）。 専門用語・カタカナの薬品名・英語の略語・数値を多く含みます。 比べるアナライザー Elasticsearch の中： Kuromoji（標準、Elasticsearch にもともとあるアナライザー）、Kuromoji_search（ kuromoji_tokenizer を mode: search に設定して、この記事用に作ったアナライザーですのでElasticsearch にもともと入っている名前ではありません。）、Sudachi（A / B / C）。 Python で前処理： MeCab、Janome。 （Lindera は Rust 製の新しい選択肢ですが、今回の環境では Python 版を導入できなかったため、 本文での紹介にとどめ、計測には含めていません。） 参考枠（LLM）： openai-gpt-oss-120b（EIS 経由）。 結果：トークン数 クリーニング後の、ユニークなトークン数です（実測値）。 Text 1（ロキソニン、約137文字）: アナライザー ユニークなトークン数 Kuromoji（標準） 34 Kuromoji（search） 34 Sudachi A 36 Sudachi B 33 Sudachi C 33 MeCab 35 Janome 38 Text 2（アセトアミノフェン、約290文字）: アナライザー ユニークなトークン数 Kuromoji（標準） 64 Kuromoji（search） 65 Sudachi A 64 Sudachi B 58 Sudachi C 56 MeCab 70 Janome 72 ここで読み取れることを少しだけ。 細かく分割する MeCab や Janome はトークン数が多めです。 Sudachi は C（大きい単位）になるほどトークン数が減り、複合語をまとめていることが分かります。 ただし「数が多い＝良い」ではありません。大事なのは、次に見る専門用語の扱いと検索のヒットです。 結果：専門用語の扱い ここが検証の肝となる、興味深いポイントです。 特定の専門用語が、意図通りにひと塊のトークンとして保持されたかを確認します（○ = 単一語として検出）。 Text 1（ロキソニン）: 用語 kuromoji kuromoji_search sudachi_a sudachi_b sudachi_c mecab janome ロキソニン ○ ○ ○ ○ ○ × ○ 解熱鎮痛 × × × × × × × 非ステロイド性抗炎症薬 × × × × × × × NSAIDs ○ ○ ○ ○ ○ ○ ○ 炎症 ○ ○ ○ ○ ○ ○ ○ 発熱 ○ ○ ○ ○ ○ ○ ○ Text 2（アセトアミノフェン）: 用語 kuromoji kuromoji_search sudachi_a sudachi_b sudachi_c mecab janome アセトアミノフェン ○ ○ ○ ○ ○ × ○ 中枢神経系 × × × × × × × 解熱鎮痛薬 × × × × ○ × × 非ステロイド性抗炎症薬 × × × × × × × NSAIDs ○ ○ ○ ○ ○ ○ ○ インフルエンザ ○ ○ ○ ○ ○ × ○ 300mg × × × × × × × 肝機能障害 × × × × ○ × × アナフィラキシーショック × × × × × × × スティーブンス・ジョンソン症候群 × × × × × × × ここから読み取れることを、いくつか。 まず、カタカナの薬品名（ロキソニン、アセトアミノフェン）や インフルエンザ は、 ほとんどのアナライザーが1語のまま残しました。 ただし、今回の MeCab の構成だけは残しませんでした。 一点だけ補足します、 これは「MeCab はダメ」という話ではありません。 分割のされ方は、使う辞書（UniDic 系か IPAdic 系かなど）や設定の影響が大きいです。 今回の MeCab ＋ 使用辞書(UniDic)の組み合わせでは、カタカナ語が細かく分割される傾向がありました。 次に、英字の略語 NSAIDs は、すべてのアナライザーが1語で保持しました。 英字のかたまりは、そのまま残りやすいです。 そして、長い複合語（非ステロイド性抗炎症薬、中枢神経系、アナフィラキシーショック、 スティーブンス・ジョンソン症候群）は、すべてのアナライザーが分割しました。 どれも、そのままでは1語になりません。 面白いのは、解熱鎮痛薬 と 肝機能障害 を、Sudachi の C モードだけが1語で残したことです。 C モードは大きい単位でまとめるため、こうした複合語をひとかたまりにできます。 数値＋単位の 300mg は、どのアナライザーも1語にしませんでした （今回の元の文が 300〜500mg なので、300・500・mg に分かれます）。 ここで大事なのは、「1語で残る＝良い」ではない、ということです。 細かく分割されると、部分一致で拾いやすくなります（再現率が上がる）。 1語でまとまると、完全一致やフレーズ検索でズレにくくなります（精度が上がる）。 つまり、どちらが良いかは「あなたの検索の目的」で決まります。 非ステロイド性抗炎症薬 のような長い語を1語で完全一致させたいなら、 ユーザー辞書への登録や、フレーズ検索の併用を検討します。 結果：アナライザー間の似ている度合い（Jaccard） 次に、アナライザーどうしがどれくらい似ているかを見ます。 前回は「Kuromoji にどれだけ似ているか」だけを見ましたが、 今回は Kuromoji を正解と決めつけず、全ペアを比べます（1.00 が完全一致）。 Text 1（ロキソニン）: kuromoji kuromoji_search sudachi_a sudachi_b sudachi_c mecab janome kuromoji 1.00 1.00 0.84 0.63 0.63 0.64 0.85 kuromoji_search 1.00 1.00 0.84 0.63 0.63 0.64 0.85 sudachi_a 0.84 0.84 1.00 0.64 0.64 0.58 0.72 sudachi_b 0.63 0.63 0.64 1.00 1.00 0.42 0.54 sudachi_c 0.63 0.63 0.64 1.00 1.00 0.42 0.54 mecab 0.64 0.64 0.58 0.42 0.42 1.00 0.62 janome 0.85 0.85 0.72 0.54 0.54 0.62 1.00 Text 2（アセトアミノフェン）: kuromoji kuromoji_search sudachi_a sudachi_b sudachi_c mecab janome kuromoji 1.00 0.98 0.85 0.67 0.62 0.59 0.74 kuromoji_search 0.98 1.00 0.84 0.69 0.64 0.59 0.76 sudachi_a 0.85 0.84 1.00 0.67 0.64 0.68 0.68 sudachi_b 0.67 0.69 0.67 1.00 0.87 0.44 0.58 sudachi_c 0.62 0.64 0.64 0.87 1.00 0.42 0.54 mecab 0.59 0.59 0.68 0.44 0.42 1.00 0.53 janome 0.74 0.76 0.68 0.58 0.54 0.53 1.00 数字が多いので、読み方をまとめます。 kuromoji と kuromoji_search はほぼ同じでした（1.00〜0.98）。 今回のテキストでは、search モードの差はほとんど出ませんでした。 複合語の固有名詞（例：関西国際空港）が多い文では差が出やすくなります。 （この点は、次の検索クエリの結果で確認します。） kuromoji / janome / sudachi_a は互いに近い（細かく分割するグループ）。 sudachi_b と sudachi_c は互いに近い（大きい単位でまとめるグループ）。 mecab は、他と最も離れていました。 ただしこれは MeCab 固有の特徴というより、今回使用した辞書・設定による切り方の違いです。 この「グループ分け」は、そのまま選び方の指針になります。 細かく拾いたい → kuromoji / sudachi A / janome。 まとめたい → sudachi B / sudachi C。 mecab は独特なので、目的に合うかを個別に確認する。 結果：検索クエリでの動作 最後に、実際の検索で確かめます。 ここが、検索システムとして一番大事なところです。 少数の文書を登録し、クエリごとに「期待する文書が拾えるか」を見ます（○ = ヒット）。 クエリ 期待文書 kuromoji kuromoji_search sudachi_a sudachi_b sudachi_c 空港 doc 1 ○ ○ ○ ○ ○ 関西空港 doc 1 ○ ○ ○ ○ × NSAIDs doc 2 ○ ○ ○ ○ ○ 300mg doc 2 ○ ○ ○ ○ ○ アセトアミノフェン doc 2 ○ ○ ○ ○ ○ （doc 1 は「関西国際空港は大阪府にある国際空港です。」、 doc 2 はアセトアミノフェンの説明文です。） 結果を読み解きます。 まず、ほとんどのクエリは、すべてのアナライザーでヒットしました。 唯一の取りこぼしは、関西空港（略称）を Sudachi C で検索したときだけです。 なぜでしょうか。 Sudachi C は、大きい単位でまとめるため、関西国際空港 を1つのトークンにします。 そのため、略称の「関西空港」とはうまく一致せず、ヒットしませんでした。 これは、まさに精度と再現率のトレードオフです。 大きい単位（Sudachi C）は、正式名称での完全一致に強い。 ただし、略称や部分的なクエリは取りこぼすことがあります。 細かい単位（Kuromoji や Sudachi A）は、部分一致で拾いやすい。 一方で、うれしい結果もあります。 英字の略語 NSAIDs、数値＋単位の 300mg、カタカナの専門語 アセトアミノフェン は、 すべてのアナライザーで検索できました。 300mg は1つのトークンではありませんでしたが、300 と mg が別々に索引されるため、検索では拾えます。 ただし、ここは設定に依存します。 今回の query 設定ではヒットしましたが、operator（and / or）、 クエリ側のアナライザー、フィールド側のアナライザーの設定によって結果は変わります。 ここでの学びは、最初に立てた問いそのものです。 トークンが1語できれいに残るかどうかと、検索で見つかるかどうかは、必ずしも一致しません。 最終的に大事なのは「ユーザーが探したい文書が見つかるか」です。 なお、今回の小さな例では、Kuromoji の標準と mode: search で差は出ませんでした。 mode: search の効果は、複合語の固有名詞がもっと多いデータで効いてきます。 参考：LLM は何を「キーワード」として拾ったか 最後に、参考枠の LLM（EIS 経由の gpt-oss-120b）を見ます。 くり返しになりますが、これはアナライザーの比較ではありません。 「意味のまとまりとして、専門語を拾えるか」を見るための参考です。 抽出されたキーワードは次の通りです。 Text 1（ロキソニン）: ロキソニン錠 / ロキソニン / 非ステロイド性抗炎症薬 / NSAIDs / 解熱鎮痛作用 / 関節リウマチ / 変形性関節症 / 腰痛症 / 肩こり / 歯痛 / 手術後 / 外傷後 / 炎症 / 痛み / 風邪 / 熱 Text 2（アセトアミノフェン）: アセトアミノフェン / 中枢神経系 / 解熱鎮痛薬 / 非ステロイド性抗炎症薬 / NSAIDs / 抗炎症作用 / 一般用医薬品 / 頭痛 / 歯痛 / 月経痛 / 関節痛 / インフルエンザ / 風邪 / 発熱 / 成人 / 1回300〜500mg / 1日3回 / 経口投与 / 肝機能障害 / 高齢者 / 用量調整 / 重篤な副作用 / 肝障害 / アナフィラキシーショック / スティーブンス・ジョンソン症候群 ここが、形態素解析との大きな違いです。 形態素解析がすべて分割してしまった長い専門語を、LLM は1つの意味のまとまりとして拾いました。 たとえば、非ステロイド性抗炎症薬、中枢神経系、アナフィラキシーショック、 スティーブンス・ジョンソン症候群 などです。 さらに、1回300〜500mg や 1日3回 のような、用量を表す「意味のかたまり」も拾っています。 一言でいうと、LLM は「索引用の最小単位」ではなく「意味のまとまり」を取り出します。 このため、LLM が向いているのは次のような場面です。 クエリの意図を理解する（クエリ理解）。 文章から重要語を抜き出す（キーワード抽出）。 意味で探す検索（セマンティック検索）の補助。 逆に、インデックスのトークン化には向きません。 理由は3つあります。 生成結果は毎回まったく同じとは限らない（再現性が低い）。 大量の文書をすべて LLM に通すのはコストが高い。 そもそも目的が、転置インデックス用の最小トークンを作ることではない。 今回使用した LLM の設定（再現性のため）: 使用モデル：openai-gpt-oss-120b 実行環境：EIS（Elastic Inference Service）経由 temperature：0 プロンプト：付録（GitHub のリポジトリ）に掲載 アナライザーの選び方ガイド ここまでをふまえて、用途別の選び方をまとめます。 「結局どれを使えばいいの？」への答えです。 部分一致や再現率を重視したい（広く拾いたい） → Kuromoji、または Sudachi A（細かく分割）。 完全一致・フレーズ検索を重視したい（複合語をまとめたい） → Sudachi C。 バランスを取りたい → Sudachi B。 新語・製品名・固有名詞が多い → 辞書更新の速い Sudachi、または Kuromoji に辞書を足す構成。 意味で探したい（言い換えにも強くしたい） → 形態素解析ではなく、semantic_text + 多言語埋め込み（EIS）。 Elasticsearch の中だけで完結させたい → 実質、Kuromoji か Sudachi（ほかは Python 前処理が必要）。 LLM → インデックスのトークン化には向きません。 クエリ理解やキーワード抽出など、検索の「補助」に使うのが向いています。 まとめ 最後に、覚えておきたいことを1つだけ。 「いちばん良いアナライザー」は存在しません。用途で決まります。 この1年での大きな変化は、選択肢が増えたことです。 形態素解析は今も主役の1つですが、意味で探すセマンティック検索という道も、 日本語で手軽に使えるようになりました。 次の一歩としては、自分の検索でよく使うクエリをいくつか決めて、 この記事の方法で実際に試してみるのがおすすめです。 results/ に数値が出るので、自分のデータで「どれが合うか」を確かめられます。 ※本記事の Python コードと検証環境は、Claude Codeを使って作成しました。 Links Kuromoji（analysis-kuromoji）プラグイン kuromoji analyzer kuromoji_tokenizer semantic_text フィールド semantic_text による意味検索 Elastic Inference Service（EIS） EIS の対応モデル （gpt-oss-120b など） 自前クラスタから EIS を使う （Cloud Connect） カスタムプラグイン／バンドルのアップロード （Serverless の制約の出典） Hosted と Serverless の違い Synonyms API （Serverless で同義語を使う方法） The post Kuromoji・Sudachi・MeCab・Janome・LLM・semantic search の使い分け【2026】 first appeared on Elastic Portal .

リアルタイム分析、バッチ処理、ビデオエンコーディング、科学モデリング、CPU ベースの機械学習推論など、計算量の多いワークロードを実行する場合、パフォーマンスのあらゆるパーセンテージポイントが重要になります。チェックでのコストを抑えながら、vCPU あたりのスループットが高く、メモリアクセスが速く、ネットワーク帯域幅が大きいインスタンスが必要です。 2026 年6 月 30 日、 AWS Graviton5 プロセッサを搭載した Amazon Elastic Compute Cloud (Amazon EC2) C9g および C9gd インスタンスが一般公開されたことを発表できることを嬉しく思います。C9g インスタンスはコンピューティングに最適化されており、前世代の C8g インスタンスと比較して、最大で 25% 高い vCPU あたりのパフォーマンスを提供しています。それは、DDR5 8800MT/秒 の DIMM、5 倍以上の L3 キャッシュ、Graviton4 ベースのインスタンスと比較して最大で 3 倍高いパケット処理パフォーマンスを備え、クラウド内のすべてのプロセッサインスタンスで最速のメモリを搭載しています。メモリが速く、キャッシュが大きいほど、ワークロードがデータの待機に費やす時間が短くなり、インメモリ分析のスループットが高くなり、エージェントループが速くなり、リアルタイムアプリケーションの応答性が向上します。 C9g インスタンスは、 Amazon Elastic Block Store (Amazon EBS) をストレージ用に利用できるバッチジョブ、ビデオエンコーディングパイプライン、または分散分析に最適です。また、同時実行環境や CPU に依存する推論ステップが、Graviton5 の高いコア数と大容量のキャッシュの恩恵を受けるエージェンティック AIワークロードにも適しています。AI が、質問への回答から、アクションの実行、コードの実行、複数ステップのタスクのオーケストレーションに変化するにつれ、CPU コンピューティングの需要は高まっており、C9g インスタンスはこの変化に対応するために構築されています。 一部のワークロードには、その計算能力に加えて高速のローカルストレージも必要です。HPC シミュレーション中のスクラッチスペース、ML 推論用の一時キャッシュ、広告配信エンジン用のローカルバッファなど、高速で低レイテンシーのローカル NVMe SSD ストレージがアプリケーションにメリットをもたらす場合は、C9gd を選択してください。 NVMe インスタンスストアボリュームを備えた Graviton5 ベースのインスタンスは、 詳細なパフォーマンス統計もサポートして、最大 1 秒の精度で I/O サイズごとに分類されたレイテンシーヒストグラムなどの高解像度 I/O メトリクスを提供しており 、 Amazon CloudWatch または nvme-cli 経由で追加コストなしでアクセスできます。 一目で分かる C9g インスタンスと C9gd インスタンス C9g インスタンスと C9gd インスタンスには、medium から 48xlarge まで 11 のサイズがあり、ベアメタルオプションもあります。前世代と比較して、サイズ全体で平均で最大で 15% 高いネットワーク帯域幅と 20% 高い EBS 帯域幅を提供します。最大の 48xlarge サイズでは最大 100 Gbps のネットワーク帯域幅と最大 72 Gbps の EBS 帯域幅を実現し、2 倍に増加しています。 C9g vCPU 数 メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) medium 1 2 最大 15 最大 12 large 2 4 最大 15 最大 12 xlarge 4 8 最大 15 最大 12 2xlarge 8 16 最大 17 最大 12 4xlarge 16 32 最大 17 最大 12 8xlarge 32 64 17 12 12xlarge 48 96 25 18 16xlarge 64 128 34 24 24xlarge 96 192 50 36 48xlarge 192 384 100 72 metal-48xl 192 384 100 72 C9gd インスタンスは、前世代のローカルストレージインスタンスと比較して最大で 30% 高いストレージパフォーマンスを備えたローカル NVMe SSD ストレージを追加します。 C9gd vCPU 数 メモリ (GiB) インスタンスストレージ (GB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) medium 1 2 1 x 59 最大 15 最大 12 large 2 4 1 x 118 最大 15 最大 12 xlarge 4 8 1 x 237 最大 15 最大 12 2xlarge 8 16 1 x 474 最大 17 最大 12 4xlarge 16 32 1 x 950 最大 17 最大 12 8xlarge 32 64 1 x 1900 17 12 12xlarge 48 96 3 x 950 25 18 16xlarge 64 128 1 x 3800 34 24 24xlarge 96 192 3 x 1900 50 36 48xlarge 192 384 3 x 3800 100 72 metal-48xl 192 384 3 x 3800 100 72 両方のファミリーは、ハイパフォーマンスコンピューティング (HPC)、バッチ処理、ゲーム、動画エンコーディング、科学的モデリング、分散分析、CPU ベースの機械学習推論、広告配信などに適しています。 その他の機能は次のとおりです: インスタンス帯域幅設定 (IBC) では、Amazon EBS と Amazon VPC ネットワーキング間の帯域幅割り当てを最大で 25% 調整できるため、データベースやキャッシュなどの特定の帯域幅要件を持つワークロードのパフォーマンスを最適化できます。 拡張ネットワーキングの ENA Express サポート 最大 128 個の EBS ボリュームを仮想インスタンスにアタッチできます。 Savings Plans、オンデマンド、スポットインスタンス、ハードウェア専有インスタンス、専有ホストのサポート。 Nitro Isolation Engine C9g インスタンスと C9gd インスタンスは、 AWS Nitro System の新機能である AWS Nitro Isolation Engine を搭載した、最初のコンピューティングに最適化された Amazon EC2 インスタンスです。Nitro Isolation Engine は、Rust で実装された Nitro Hypervisor の専用コンポーネントであり、仮想マシン間の分離を適用します。VM メモリ、CPU レジスタの状態、および I/O デバイスへのすべてのアクセスを、最小限の API セットを通じて仲介します。 Nitro Isolation Engine の詳細については、 ブログ投稿 をご覧ください。スコープや前提を含む正式な検証結果の詳細については、 テクニカルホワイトペーパー を参照してください。 今すぐご利用いただけます Amazon EC2 C9g および C9gd インスタンスは現在、米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、欧州 (フランクフルト) の AWS リージョンでご利用いただけます。その他のリージョンも順次追加される予定です。 C9g および C9gd インスタンスは現在、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS SDK を使用して起動できます。料金の詳細については、 Amazon EC2 の料金ページ をご覧ください。 詳細については、Amazon EC2 C9g および C9gd インスタンスページをご覧ください。また、フィードバックを AWS re:Post for EC2 に送信するか、通常の AWS サポートの連絡先を通じて送信してください。 – seb 原文は こちら です。