公式ドキュメント、AIに読ませたら強すぎた──Bedrock RAGとGemini Live APIの最新機能を発掘した話

Last updated at 2026-08-19Posted at 2026-08-19

この記事でわかること

AWS / Google 公式 MCP を Cursor から使う調査フロー
Bedrock Knowledge Base の RAG 最新機能 4 つ（Implicit filtering ほか）
Gemini Live API の RAG 連携 と Function Calling の設定イメージ

はじめに

ゼンリンデータコムの川越です。普段は AI アプリ開発に携わっていて、最近は「最新機能を既存のアプリへどう入れるか」を日々考えています。

今回は AWS / Google Cloud の公式 MCP サーバーで技術調査した話 を紹介します。

AI の進化は速く、使えるサービスも機能も増え続けています。「最新を押さえて、できるだけ盛り込みたい」——そう思う方も多いはずです。

我々も AWS / Google Cloud の最新機能を調べてアプリに活かす取り組みを続けています。

ただ、従来のやり方（検索 → ページ探し → 読む）だと……

情報が多すぎて時間がかかる
「自分のアプリに使える？どう入れる？」まで遠い
見落としのリスク

公式 MCP を導入したことで、Cursor から公式ドキュメントを直接参照し、「使えるか？」をその場で検討できるようになりました。この記事では 調査事例を 2 本 紹介します。

使った MCP サーバー

MCP サーバー	用途
AWS Knowledge MCP Server	AWS 公式ドキュメントを Cursor から直接参照（AWS ホスト型・認証不要）
Google Developer Knowledge MCP Server	Google Cloud / Firebase 等の公式ドキュメントを Cursor から直接参照

Cursor の mcp.json（プロジェクト単位は .cursor/mcp.json、全体設定は ~/.cursor/mcp.json）に以下を設定します。

mcp.json

{
  "mcpServers": {
    "aws-knowledge-mcp-server": {
      "url": "https://knowledge-mcp.global.api.aws"
    },
    "google-knowledge-mcp": {
      "url": "https://developerknowledge.googleapis.com/mcp",
      "headers": {
        "X-Goog-Api-Key": "YOUR_API_KEY"
      }
    }
  }
}

設定のポイント

AWS は URL 指定だけ。API キーや AWS アカウント設定は不要です。
Google は Developer Knowledge API を有効化し API キーを発行。YOUR_API_KEY に設定します。

プロキシ利用時は HTTP_PROXY / HTTPS_PROXY のホスト・ポート・認証を 各自の環境に合わせて変更してください（上記はダミー値）。
TLS 証明書エラーが出る場合は、社内 CA 追加など セキュリティを下げない方法 を IT 部門と相談することをおすすめします。

設定後はチャットで「AWS公式ドキュメントを適宜参照しつつ回答お願い」や「Google Cloud公式ドキュメントを見つつ回答お願い」と聞くだけで、公式ドキュメントを踏まえて答えてくれます。

AWS 編：RAG 最新機能の調査と開発中のアプリへの適用

背景

最近、Bedrock Knowledge Base の RAG に注目しています。

シンプルなメタデータフィルタを使ったベクトル検索などの実装経験はあるものの、「もっと検索精度を上げたい」「使いこなせていない機能があるのでは」と思っていました。

とはいえ、正直難しそうな印象もありました。そこでAWS Knowledge MCP で最新機能を洗い出してみると……

調査に使ったプロンプト例

前提: Cursor は開発中アプリのソースコード把握済み。

プロンプト

Cursor へのプロンプト（AWS 編）

課題一覧はこちら <<課題一覧(md)のリンク>> 
RAG 関連の課題について、AWS 公式ドキュメント（Knowledge Base、OpenSearch 等）の
最新機能から適用できそうな解決策を提示してください。

調べてみると、シンプルなメタデータフィルタ以外にも機能が山ほどあることがわかりました。

把握した機能と適用検討

#	機能	ひとこと
①	Implicit metadata filtering	自然言語 → 自動でメタデータフィルタ
②	Hybrid search	ベクトル + キーワードで固有名詞も拾う
③	Reranking	候補を再評価して精度アップ
④	Query decomposition	複合条件をサブクエリに分解

① Implicit metadata filtering

自然言語の問い合わせを LLM がメタデータフィルタに自動変換してくれる機能（Anthropic Claude 向け）。

「prefecture = 東京都」のような明示フィルタなしで、「カジュアルな雰囲気」「初心者向け」みたいな曖昧条件でも LLM が絞り込んでくれる、とのことでした。

なかなか良さそうですね^ ^

明示的フィルタ

# 明示的なフィルタの場合
response = bedrock_agent_client.retrieve(
    retrievalQuery={"text": query_text},
    knowledgeBaseId=knowledge_base_id,
    retrievalConfiguration={
        "vectorSearchConfiguration": {
            "numberOfResults": 10,
            "filter": {"equals": {"key": "category", "value": "restaurant"}}
        }
    }
)

Implicit metadata filtering

# Implicit metadata filtering を使う場合
# 自然言語のクエリだけ渡せば、LLM が自動でフィルタを生成してくれる
response = bedrock_agent_client.retrieve(
    retrievalQuery={"text": "カジュアルな雰囲気のお店を教えて"},
    knowledgeBaseId=knowledge_base_id,
    retrievalConfiguration={
        "vectorSearchConfiguration": {
            "numberOfResults": 10,
            "implicitFilterConfiguration": {
                "metadataAttributes": [
                    {"key": "category", "type": "STRING"},
                    {"key": "atmosphere", "type": "STRING"}
                ],
                "modelArn": "arn:aws:bedrock:ap-northeast-1::inference-profile/jp.anthropic.claude-sonnet-4-6"
            }
        }
    }
)

modelArn は利用リージョンで有効な Anthropic Claude モデルの ARN を指定します（例は Claude Sonnet 4.6 / 東京リージョン）。

② Hybrid search

ベクトル検索とキーワード検索の併用。「渋谷スクランブル交差点」「六本木ヒルズ」のような固有名詞が、ベクトルだけだと弱くなりがち。

これがHybrid search で漏らしにくくなるとのこと。

おお、これも良さそうですね、、。

Hybrid search

retrievalConfiguration={
    "vectorSearchConfiguration": {
        "numberOfResults": 20,
        "overrideSearchType": "HYBRID"
    }
}

HYBRID は Amazon OpenSearch Serverless で filterable text field が有効な構成など、条件を満たす場合に利用できます（それ以外のベクトルストアでは SEMANTIC のみ）。

③ Reranking

取得した候補をクエリとの関連度で再評価する機能。広めに取ってから絞り込むと、ユーザーの意図に近い結果を返しやすくなるとのこと。

レイテンシがどれくらい増えるか気になったので、cohere.rerank-v3-5:0 でナレッジベースから取得した 約30件 を Rerank してみました。結果、処理時間は 約1.8秒 増えました。ユースケース次第ですが、許容範囲かな、という感触です。

Reranking

# 取得件数は従来どおり。同じ件数を Rerank して返す
vector_config = {
    "numberOfResults": number_of_results,
    "filter": {"equals": {"key": "prefecture", "value": prefecture}},
    "rerankingConfiguration": {
        "type": "BEDROCK_RERANKING_MODEL",
        "bedrockRerankingConfiguration": {
            "numberOfRerankedResults": number_of_results,
            "modelConfiguration": {
                "modelArn": "arn:aws:bedrock:us-east-1::foundation-model/cohere.rerank-v3-5:0"
            },
        },
    },
}
response = bedrock_agent_client.retrieve(
    retrievalQuery={"text": query_text},
    knowledgeBaseId=knowledge_base_id,
    retrievalConfiguration={"vectorSearchConfiguration": vector_config},
)

④ Query decomposition

「週末に家族で楽しめて、食事もできる場所」のような複合条件を、自動でサブクエリに分解して検索してくれる。複雑な要求にも対応しやすくなるとのこと。

いいですね。
先ほどの①との違いが少し気になりますが、複雑な要求への対応はかなり需要ありそうです^ ^

まとめ（AWS 編）

MCP でAWSの公式ドキュメントを参照しながら進めたら、多くの発見がありました。また、開発中アプリのソースをAIに見せながら調査ができるので、現行実装の改善余地が見え、アプリへの適用方針まで一気に具体化しやすいです。

Google Cloud 編：Gemini Live API の知識拡張調査

背景

Gemini Live API のリアルタイム音声会話にも注目していました。こちらを使った簡単な音声会話は作ったことがあるものの、「もっと自分専用にカスタマイズしたい」「事前に構築した RAG データベースを会話中にリアルタイム検索させたい」と思っていました。

正直「結構難しそう」と思ってました——が Google Developer Knowledge MCP で調べたら「あれ、意外といけそうだぞ？」 となりました。

調査に使ったプロンプト例

前提: Cursor は開発中アプリのソースコード把握済み。

プロンプト

Cursor へのプロンプト（Google Cloud 編）

一旦 Gemini Live API の最新仕様 / できること / できないことを調査したいです。
Google Cloud 公式ドキュメントを参照しつつ、調査お願いできますか？

以下で紹介する Python のコード例は、公式ドキュメントをもとにした設定イメージです。vertex_rag_store と Function Calling については、筆者による動作確認は行っていません（コメントアウト部分は Live セッション接続のサンプルで、実行・検証はしていません）。

把握した機能と適用検討

#	機能	ひとこと
①	vertex_rag_store（RAG 連携）	事前に構築したコーパスを会話中に都度検索
②	Function Calling	外部 API と連携してリアルタイム応答

① vertex_rag_store（RAG 連携）

Gemini Live API では tools の retrieval に vertex_rag_store を指定すると、事前に構築した RAG を会話中に都度検索して応答してくれるそうです。

格納する情報次第で AI を自分向けにカスタマイズできそうですね（ニヤリ）。

以下は公式ドキュメントをもとにした設定イメージです。vertex_rag_store 自体は動作確認していません。 コメントアウト部分は Live セッション接続のサンプルで、実行・検証はしていません。Preview 機能です。実際の接続は Live API の WebSocket セッション経由になります。

Gemini Live API + RAG 連携（設定イメージ・未検証）

# Gemini Live API で RAG を tools として指定する例（google.genai SDK）
from google import genai
from google.genai import types
from google.genai.types import LiveConnectConfig, Modality

PROJECT_ID = "your-project-id"
LOCATION = "us-central1"
RAG_CORPUS = "projects/{}/locations/{}/ragCorpora/{}".format(
    PROJECT_ID, LOCATION, "your-corpus-id"
)

client = genai.Client(vertexai=True, project=PROJECT_ID, location=LOCATION)

rag_tool = types.Tool(
    retrieval=types.Retrieval(
        vertex_rag_store=types.VertexRagStore(
            rag_resources=[
                types.VertexRagStoreRagResource(rag_corpus=RAG_CORPUS)
            ]
        )
    )
)

# Live セッション接続（非同期）
# async with client.aio.live.connect(
#     model="gemini-2.0-flash-exp",
#     config=LiveConnectConfig(
#         response_modalities=[Modality.AUDIO],
#         # 音声出力時は speech_config（language_code 等）の指定も検討
#         tools=[rag_tool],
#     ),
# ) as session:
#     ...

Google Search グラウンディングと同様 tools に組み込むだけで、事前に構築したコーパスを参照できるので、ハードルは想定より低めでした（google_search と vertex_rag_store は別 built-in tool）。

② Function Calling

Function Calling で外部 API とも連携可能。会話しながらリアルタイムで外部データを引いて応答する体験が実現できます。

セッション設定の tools に function_declarations を渡し、モデルから tool_call が返ったらクライアント側で外部 API を実行して send_tool_response で結果を返す、という流れになるそうです。

以下は公式ドキュメントをもとにした設定イメージで、Function Calling による外部 API 連携は動作確認していません。 コメントアウト部分は Live セッション接続と tool_call 処理のサンプルで、実行・検証はしていません。

generateContent API と違い、Live API では ツール応答の自動処理はされません。tool_call を受け取ったら、クライアント側で FunctionResponse を組み立てて返す必要があります。

Gemini Live API + Function Calling（設定イメージ・未検証）

# 外部 API 連携の設定イメージ（google.genai SDK）
from google import genai
from google.genai import types
from google.genai.types import LiveConnectConfig, Modality

client = genai.Client(vertexai=True, project=PROJECT_ID, location=LOCATION)

get_weather = types.FunctionDeclaration(
    name="get_weather",
    description="指定した都市の天気を取得する",
    parameters={
        "type": "object",
        "properties": {
            "city": {"type": "string", "description": "都市名"},
        },
        "required": ["city"],
    },
)
weather_tool = types.Tool(function_declarations=[get_weather])

# async with client.aio.live.connect(
#     model="gemini-2.0-flash-exp",
#     config=LiveConnectConfig(
#         response_modalities=[Modality.AUDIO],
#         tools=[weather_tool],
#     ),
# ) as session:
#     async for response in session.receive():
#         if response.tool_call:
#             function_responses = []
#             for fc in response.tool_call.function_calls:
#                 # ここで外部 API を呼び出し、結果を返す
#                 result = call_weather_api(fc.args["city"])
#                 function_responses.append(
#                     types.FunctionResponse(
#                         id=fc.id,
#                         name=fc.name,
#                         response={"temperature": result},
#                     )
#                 )
#             await session.send_tool_response(function_responses=function_responses)

① の RAG と組み合わせれば、「事前に構築したデータベースを検索しつつ、必要に応じて外部 API も叩く」といった拡張もできそうです（いずれも未検証の設定イメージ）。

公式を読む限り、Gemini Live API は思ったより拡張できそうだな、という感触です（ニヤリ）。

まとめ（Google Cloud 編）

「難しそう」と思い込んでいた機能が、公式ドキュメントでの確認したら実現可能だった——という発見でした。さらにはAWS編同様、調査をきっかけに新機能への実装方針の具体化までをスムーズに行えました。

公式 MCP のおかげで、「なんとなく難しい」→「実は使えそうなのがありそう」→ 設計に落とすサイクルが回せるようになっています。

まとめ

Before / After でざっくりこう変わります。

従来の調査	MCP を使った調査
検索 → ページ探し → 読む	チャットで直接聞く
使えそうな機能探しに時間	最新機能を網羅的に把握しやすい
アプリへの適用判断が遠い	コードと公式を行き来して即検討
思い込みで「無理」	正確な仕様確認で解除

魅力的なアプリの出発点は「何ができるか」の正確な把握です。公式 MCP なら見落としにくく、適用可否まで一気に検討できます。

おわりに

「最新機能を使いたいけど調査に時間がかかる」方は、ぜひ MCP 調査フローを試してみてください。

これからも 最新 AI を積極的に盛り込み、より魅力的なアプリを作り続けたいと思います！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up