トップ > Amazon Bedrock > Amazon Bedrock Managed Knowledge Base を東京リージョンで徹底検証してみた

Amazon Bedrock Managed Knowledge Base を東京リージョンで徹底検証してみた

Amazon Bedrock Amazon Bedrock Knowledge Bases RAG Amazon Bedrock AgentCore Bedrock AgentCore Gateway 生成AI
記事タイトルとURLをコピーする

はじめに

2026年6月、Amazon Bedrock Managed Knowledge Base が一般提供（GA）となりました。

これまでの Amazon Bedrock Knowledge Bases（以下、Customer-managed Knowledge Base）では、ベクターストア（Amazon OpenSearch Serverless や Amazon Aurora など）を自分で用意・運用する必要がありました。

Managed Knowledge Base は、このベクターストア・データ取り込みパイプライン・検索最適化をすべて AWS がマネージドします。さらに、埋め込みモデルとリランキングモデルを追加料金なしで組み込みで提供します。

本記事では、アジアパシフィック（東京）リージョン（ap-northeast-1、以降東京リージョンと略）で実際に手を動かし、次の観点を網羅的に検証しました。

  • Managed Knowledge Base と Customer-managed Knowledge Base（OpenSearch Serverless）の両方を構築して比較
  • マネージド埋め込みとカスタム埋め込み（Amazon Titan Text Embeddings V2）の比較
  • マルチモーダル取り込み（テキスト・画像・音声・動画）の実態と精度
  • agentic retrieval（複数文書を横断するマルチホップ検索と回答生成）の挙動
  • Amazon Bedrock AgentCore（以降AgentCoreと略）Gateway からMCPツールとして接続するエンドツーエンド
  • AWS CloudFormation での IaC 対応状況

先に結論

  • ベクターストアの構築・運用が消え、S3 にデータを置いて取り込むだけでRAGが立ち上がります。Customer-managed で必要だったベクターストアそのものが不要になりました。
  • マルチモーダルは強力ですがクセがあります。「画像」はPDF等の文書に埋め込まれたビジュアルが対象で、単体の画像ファイル（.png）は直接取り込めません。音声は発話があれば文字起こしして取り込めます。
  • 最大の魅力は「agentic RAG が組み込み」であることです。エージェントが自律的に 検索計画 → 反復取得 → 再ランク → 引用付き回答 までを1呼び出しで実行します（AgenticRetrieveStream）。複雑・多段の質問に、自前のエージェントループを書かずに対応でき、従来型の単発RAGや Customer-managed（agentic 非対応）にはない強みです。
  • 2026年6月18日時点で CloudFormation は Managed Knowledge Base に未対応でした。
  • 料金体系も従来と大きく変わり、従量課金の恩恵を受けられるようになった。

以降、実際のコマンドと出力を交えて解説します。

検証に使ったデータ（前提）

検証結果を読みやすくするため、最初に「何を入れて、何を聞いたか」を整理します。

1つの S3 バケットに、以下の検証用データを配置しました。

テキスト（架空のダミー文書3点）

実在しない架空のSaaS（本記事では「サンプル製品」と表記します。実在の製品・企業とは関係ありません）の社内文書です。わざと相互参照を持たせて、マルチホップ検索を試せるようにしています。

  • shanai-faq.md（社内FAQ）… 「対応リージョンは“製品仕様書”を参照」など、他文書へ誘導
  • seihin-shiyo.md（製品仕様書）… 対応リージョン、保持期間（標準90日）などの数値
  • security-policy.md（セキュリティポリシー）… 暗号化方式（AWS KMS / TLS 1.2以上）

画像（PNG 5枚）

サーバーワークス エンジニアブログのアイキャッチ画像です。日本語の文字や図が含まれており、画像のビジュアル抽出の検証に使います。単体PNGと、後述の「PDFに埋め込んだ版」の両方を用意しました。

5枚中1枚の例

音声（MP3 2点）

  • ohayougozaimasu.mp3 … 「おはようございます」という発話あり
  • cat-meow.mp3 … 猫の鳴き声（発話なしの効果音）

動画（MP4 1点）

UHD のサンプル動画です。

いずれも検証専用のダミー／サンプルです。記事中の社名・数値はすべて架空のものです。

ソリューションアーキテクチャ

今回検証した構成のデータフローは次のとおりです。

構成図

各サービスの役割は次のとおりです。

  • Amazon S3：データソース。Managed Knowledge Base は S3 / SharePoint / Confluence / Google Drive / OneDrive / Web Crawler / Custom の7コネクタに対応します。
  • Managed Knowledge Base：取り込み・パース・チャンク分割・埋め込み・ベクター保存・検索最適化をマネージド。
  • AgentCore Gateway：Managed Knowledge Base を Model Context Protocol（MCP）ツールとして公開し、エージェントから標準的に呼び出せるようにします。

Managed と Customer-managed の比較と設計トレードオフ

実際に両方を作って比較した結果を整理します。

観点 Managed Knowledge Base Customer-managed Knowledge Base
ベクターストア フルマネージド（自前準備不要） OpenSearch Serverless 等を用意（コンソールのクイック作成で自動生成可）
埋め込みモデル 組み込み（追加料金なし）／任意でカスタム指定可 自分で指定（Titan / Cohere など）
リランカー 組み込みマネージドリランカー（追加料金なし） 自分で構成
agentic retrieval 対応（計画・反復取得・リランク・回答生成を内蔵） 非対応
マルチモーダル 画像・音声・動画の抽出に対応 既定はテキスト中心（FMパーサーで拡張）
検索API Retrieve（managedSearchConfiguration） Retrieve（vectorSearchConfiguration）／RetrieveAndGenerate
回答生成 AgenticRetrieveStream（合成回答） RetrieveAndGenerate
AgentCore Gateway 連携 コネクタで対応 非対応
CloudFormation 未対応（2026年6月18日時点） 対応（AWS::Bedrock::KnowledgeBase）
コスト 従量課金が中心（ストレージ・検索）。アイドル時の固定費なし RAG利用料＋ベクターストアの費用（OpenSearch Compute Unitの最小固定費に注意）

設計の勘所

運用負荷・立ち上げ速度・コストを最優先するなら Managed が第一候補です。

逆に、ベクターDBのチューニングや既存のOpenSearch資産の活用、RetrieveAndGenerate を含む既存実装との互換性が必要なケースでは Customer-managed が残ります。

なお Managed でカスタム埋め込みモデルを選ぶと、組み込みマネージドリランカーは併用できません（後述の実機エラーで確認しました）。

実装手順

前提条件

  • データを S3 等の対応コネクタに配置
  • Knowledge Base 作成ロールに iam:PassRole（bedrock.amazonaws.com 向け）
  • マネージド埋め込みを使う場合、モデルアクセスの申請は不要（カスタム埋め込み時のみ対象モデルのアクセスが必要）

Managed Knowledge Base を CLI で作成する

マネージド埋め込みの場合、設定はわずか数行です。

# kb-config-managed.json
# { "type": "MANAGED",
#   "managedKnowledgeBaseConfiguration": { "embeddingModelType": "MANAGED" } }

aws bedrock-agent create-knowledge-base \
  --region ap-northeast-1 \
  --name "verify-mkb-managed-embed" \
  --role-arn "arn:aws:iam::<ACCOUNT_ID>:role/<KBRole>" \
  --knowledge-base-configuration file://kb-config-managed.json

データソースは、画像・音声・動画の抽出を有効化して作成します。

# ds-config-managed.json（抜粋）
# "type": "MANAGED_KNOWLEDGE_BASE_CONNECTOR",
# "managedKnowledgeBaseConnectorConfiguration": {
#   "mediaExtractionConfiguration": {
#     "imageExtractionConfiguration": { "imageExtractionStatus": "ENABLED" },
#     "audioExtractionConfiguration": { "audioExtractionStatus": "ENABLED" },
#     "videoExtractionConfiguration": { "videoExtractionStatus": "ENABLED" } },
#   "connectorParameters": { "type": "S3",
#     "connectionConfiguration": { "bucketName": "<BUCKET>", "bucketOwnerAccountId": "<ACCOUNT_ID>" } } }

aws bedrock-agent create-data-source \
  --region ap-northeast-1 \
  --knowledge-base-id "<KB_ID>" \
  --name "s3-multimodal" \
  --data-source-configuration file://ds-config-managed.json \
  --data-deletion-policy DELETE

aws bedrock-agent start-ingestion-job \
  --region ap-northeast-1 \
  --knowledge-base-id "<KB_ID>" --data-source-id "<DS_ID>"

これだけで、ベクターストアの準備なしにRAGが立ち上がります。

Customer-managed Knowledge Base はコンソールのクイック作成が手軽

比較対象として Customer-managed（VECTOR 型）KB も作成しました。

ポイントはベクターストアの用意方法です。bedrock-agent CLI の create-knowledge-base は VECTOR 型では storageConfiguration が必須で、省略すると次のエラーで弾かれます。

You must provide a storage configuration if you create a VECTOR knowledge base.

つまり CLI 単体では OpenSearch Serverless を自動作成できません。

そこで Amazon Bedrock コンソールの「ベクトルストアでナレッジベースを作成」を使います。

ウィザードで 「新しいベクトルストアをクイック作成（推奨）」→ Amazon OpenSearch Serverless を選ぶと、Bedrock がコレクション・ベクターインデックス・サービスロールまで自動生成します（セキュリティポリシーやインデックス定義の手作業は不要）。

今回も、埋め込みに Titan Text Embeddings V2（1024次元・float32）を選ぶだけで、OpenSearch Serverless コレクションとインデックス（bedrock-knowledge-base-default-index）が自動で用意されました。

それでも Managed Knowledge Base ならこのベクターストア自体が不要です。「自分のベクターDBを持つかどうか」が両者の最大の分岐点になります。

CloudFormation（IaC）対応状況の検証

IaC 対応も実機で確認しました。

AWS::Bedrock::KnowledgeBase のリソーススキーマを取得すると、KnowledgeBaseType の enum は VECTOR / KENDRA / SQL のみで、MANAGED も ManagedKnowledgeBaseConfiguration も存在しません。

実際に Type: MANAGED のテンプレートをデプロイすると、次のエラーでロールバックしました。

Properties validation failed for resource ManagedKnowledgeBase ...
[#/KnowledgeBaseConfiguration/Type: MANAGED is not a valid enum value,
 #/KnowledgeBaseConfiguration: extraneous key [ManagedKnowledgeBaseConfiguration] is not permitted]

結論：2026年6月18日時点で CloudFormation は Managed Knowledge Base を宣言できません。

IaC 化したい場合は、当面 CLI / SDK / コンソール、または AWS CDK の AwsCustomResource のようなカスタムリソースで bedrock-agent API をラップする必要があります。Customer-managed 型は従来どおり CloudFormation で構築できます。

検証結果

取り込み（マルチモーダルの実態）

前述のデータ（テキスト3・PNG画像5・音声2・動画1・画像埋め込みPDF1）を同一の S3 から取り込んだ結果です。

Knowledge Base indexed failed 取り込めたもの
Managed（マネージド埋め込み） 6 6 テキスト・PDF・動画・発話音声
Customer-managed（コンソール / OpenSearch） 4 8 テキスト・PDF（テキストのみ）

失敗の中身が重要です。

単体PNG画像（image/png）

「The document type (image/png) is not supported」で全滅しました。

画像のビジュアル抽出は PDF / DOCX / PPT 等の文書に“埋め込まれた”画像が対象で、単体の画像ファイルは直接取り込めません。

音声（.mp3）

発話入りの音声（ohayougozaimasu.mp3）は Managed で INDEXED されました。一方、発話のない効果音（cat-meow.mp3）は「contains no content」で失敗します。

音声抽出は「発話の文字起こし」なので、発話があるかどうかが分かれ目です。

動画mp4

Managed では INDEXED。Customer-managed の既定パーサーでは失敗しました。

なお、単体PNGはそのままでは取り込めないため、5枚のPNGを1つのPDFに埋め込んで再取り込みしました。すると Managed では正常に INDEXED されます。

検索してみると、ビジュアル抽出はOCRに留まらず、図の内容を意味的に記述して取り込んでいることが分かります。

クエリ：「最近使ったフォルダを削除する方法」
→ "The main title states: How to Delete 'Recently Used Folders' in Claude Code Desktop ...
   LevelDB as the database system ... ~/.claude/ and ~/.claude/LevelDB/"
（PDFに埋め込んだ画像から抽出。score 0.79）

マルチモーダルの「精度」には注意が必要（日本語の所感）

発話音声は取り込めましたが、日本語の精度には注意が要ると感じました。

ohayougozaimasu.mp3（「おはようございます」）を取り込んだチャンクの文字起こしは、次のように英語の音写になっていました。

"Oh hi yogamos."
「話者が誰かに挨拶した」

それでも、検索自体は問題なく機能しました。「おはようございます」「朝の挨拶」「good morning greeting」のいずれのクエリでも、当該MP3が最上位ヒット（score 0.84）しました。意味記述（「挨拶した」）が効いているためです。

ここから読み取れる実務上の注意点は次のとおりです。

  • 短い日本語音声では、逐語的な文字起こし精度が落ちる場合がある（音写・英語寄りの表記）。
  • それでもセマンティック検索（意味の近さ）でのヒットは成立しやすい。

_language_code は自分で指定できるのか

取り込んだ音声チャンクのメタデータを見ると、_language_code が en と付いていました（日本語音声なのに英語判定）。

これは Knowledge Base が取り込み時に自動付与する予約メタデータです（_ 始まりはシステム予約フィールド）。こちらが入力する値ではありません。

つまり、仮にこのラベルを ja に書き換えても、文字起こし自体がやり直されるわけではないため、取り込み内容の精度は変わりません。

実際、マネージドコネクタの音声抽出設定（audioExtractionConfiguration）には ENABLED / DISABLED しかなく、言語を指定するオプションがありません。フルマネージドの音声取り込みでは、言語は自動判定に委ねられます。

日本語音声を確実に扱いたい場合の選択肢は次のとおりです。

  • Amazon Bedrock Data Automation（BDA）を使う：BDA には音声の入力言語を指定する設定（AudioLanguageConfiguration の InputLanguages）があります。Customer-managed 側の「基盤モデル／BDA パーサー」経路と組み合わせれば、言語を明示できる余地があります。
  • 事前に Amazon Transcribe（ja-JP）で文字起こししてテキストとして取り込む：逐語精度が重要な用途（議事録など）はこちらが堅実です。

いずれにせよ、日本語コンテンツの言語判定・解析品質は本番投入前に自分のデータで確認しておくことをおすすめします。

agentic retrieval（マルチホップ）

Managed Knowledge Base の Retrieve は managedSearchConfiguration を使います（Customer-managed の vectorSearchConfiguration とは別物です）。

aws bedrock-agent-runtime retrieve --region ap-northeast-1 \
  --knowledge-base-id "<KB_ID>" \
  --retrieval-query '{"text":"東京リージョンでの利用可否と保持期間、暗号化方式は？"}' \
  --retrieval-configuration '{"managedSearchConfiguration":{"numberOfResults":5}}'

「リージョン＋保持期間＋暗号化」という複数文書にまたがる質問を投げると、3つの文書（FAQ・製品仕様・セキュリティポリシー）から横断的にチャンクが返りました。

agentic retrieval が複数ソースを統合している様子が確認できます。なお rerankingModelType: MANAGED を指定すると組み込みリランカーが効きます。

注目ポイント：Managed は agentic RAG が組み込み（本検証イチオシ）

Managed Knowledge Base の真価は、agentic RAG（エージェント型RAG）が標準で組み込まれていることです。

通常のRAGは「1回検索して、その結果で答える」単発処理です。これに対し agentic RAG は、エージェントが質問をタスクとして捉え、検索の計画を立て、複数回・多段で検索し、結果を評価・再ランクし、引用付きの回答にまとめる——という一連の判断を自律的に行います。しかもこれを、自前のエージェントループやオーケストレーションを実装することなく利用できます。

この機能は AgenticRetrieveStream として、AgentCore Gateway のコネクタ経由でツール提供されます（計画 → 反復取得 → リランク → 回答生成までを1呼び出しで実行）。

移行時の注意：Customer-managed で一般的な RetrieveAndGenerate は Managed では使えません（ValidationException: This operation is not supported for managed knowledge bases.）。Managed の回答生成は AgenticRetrieveStream（agentic RAG）を使います。

実際に AgentCore Gateway 経由で AgenticRetrieveStream を呼び出すと、ストリームで以下のトレースが流れました。

traceEvent: Starting speculative retrieval for query: サンプル製品を東京リージョンで使う場合...
traceEvent: Speculative retrieval completed successfully
traceEvent: Agent planning started
traceEvent: Agent planning completed

そして、3件の引用付きで次の合成回答が返りました（複数文書を統合）。

標準プランのデータ保持期間は90日です。
データの暗号化は次の2つです。
- 保管時暗号化: AWS KMS（顧客管理キー対応）
- 転送時暗号化: TLS 1.2以上
なお、サンプル製品は東京リージョン（ap-northeast-1）に対応しています。
（citations: 3）

注目すべきは、トレースに出ている Speculative retrieval（先読み検索） と Agent planning（検索計画） です。エージェントが自分で検索戦略を立てて多段に取りに行っている証拠で、これがマルチホップ・曖昧な質問に強い理由です。

単発検索の結果をそのまま返すのではなく、「どう探すか」をマネージドのエージェントに委ねられる——RAGの“賢さ”を作り込まずに享受できるのが、Managed KB を選ぶ大きな理由になります。

AgentCore Gateway 連携（エンドツーエンド）

Managed Knowledge Base を AgentCore Gateway の MCPツールとして公開しました。

  1. Gateway を作成（protocol-type MCP / authorizer-type AWS_IAM）
  2. Gateway target を mcp.connector（connectorId: bedrock-knowledge-bases）で Knowledge Base にバインド

このとき AgenticRetrieveStream と Retrieve の2ツールが自動公開されます。資格情報プロバイダは GATEWAY_IAM_ROLE を使います。

MCPクライアントから tools/list すると2つのツールが自動検出され、tools/call で実際の取得・回答が返ってきました。

tools/list -> managedkb___AgenticRetrieveStream, managedkb___Retrieve
tools/call Retrieve -> "データ保持期間の上限 - 標準プラン: 90日 ..."（seihin-shiyo.md より）

ベクターDBもRAG実装コードも書かずに、エージェントから標準MCPで根拠付き検索・回答ができる——これが Managed Knowledge Base ＋ AgentCore の体験です。

トラブルシューティング（実機でハマった点）

症状 原因 対処
create-knowledge-base に MANAGED が無い CLIが古い（GA直後） AWS CLI を最新へ更新（本検証では 2.34.2 → 2.35.7）
vectorSearchConfiguration is not supported Managed は設定キーが異なる managedSearchConfiguration を使う
This operation is not supported for managed knowledge bases Managed は RetrieveAndGenerate 非対応 AgenticRetrieveStream（AgentCore連携）を使う
画像（png）が not supported 単体画像は対象外 PDF/DOCX/PPT に埋め込んで取り込む
音声が contains no content 発話が無い（効果音など） 文字起こし可能な発話入り音声を使う
Customer-managed を VECTOR で CLI 作成できない storageConfiguration 必須 コンソールのクイック作成で OpenSearch Serverless を自動生成
Customer-managed で取り込み直後に検索が空 OpenSearch Serverless の反映遅延 数十秒待ってから再検索（本検証では約45秒で解消）
Gateway target が Insufficient permissions 実行ロールに権限不足 bedrock:GetKnowledgeBase を付与
AgenticRetrieveStream で 403 実行ロールに権限不足 bedrock:AgenticRetrieveStream を付与
on-demand throughput isn't supported（生成時） 新しめモデルはオンデマンド不可 推論プロファイルARNを指定
Customer-managed KB が DELETE_UNSUCCESSFUL 先にベクターストアを削除した データソースを dataDeletionPolicy: RETAIN にして再削除

コスト（料金の考え方）

両者は課金モデルが大きく異なります。以下は本記事執筆時点（2026年6月18日）の料金で、最新かつリージョン別の正確な金額はAmazon Bedrock 料金・Amazon OpenSearch Service 料金の各公式ページでご確認ください。

Managed Knowledge Base

従量課金が中心で、アイドル時の固定費がありません（呼ばなければ課金されない）。

  • インデックスストレージ：$5.00 / 取り込み元データ 1GB・月
  • 検索（Retrieve API）：$1.00 / 1,000 リクエスト
  • agentic retrieval（AgenticRetrieveStream）：$4.00 / 1,000 リクエスト（＋内部の Retrieve 呼び出し $1.00 / 1,000）
  • マルチモーダルのドキュメント解析・埋め込み生成・リランキングは追加料金なし（組み込み）

今回の検証のような小規模データであれば、ストレージ・検索ともごく低コストに収まります。「使った分だけ」が効くのがマネージドの利点です。

Customer-managed（OpenSearch Serverless）

RAGの利用料に加えて、ベクターストア（OpenSearch Serverless）の費用が別途かかります。

  • OpenSearch Serverless は OpenSearch Compute Unit（以降OCUと略）単位の時間課金です（単価はリージョンにより異なります）。
  • 従来型（Classic）コレクションは最小OCUの継続課金があり、検索していなくてもコレクションが存在する限り費用が発生します。これがマネージドとの最大のコスト差です。
  • 新しい NextGen コレクションはゼロにスケールできる場合があり、アイドル時の費用を抑えられます。

実際、本検証でも OpenSearch Serverless は「立てている間ずっと課金」されるため、検証後すぐに削除しました（次節のクリーンアップ参照）。

コスト観点での使い分け

  • 小〜中規模・スパイク的な利用、PoC〜初期本番 → Managed（固定費なし・従量課金）が有利。
  • 大規模・高QPSで常時稼働、既存の OpenSearch 資産を活用したい → Customer-managed にも分があるが、最小OCUの固定費を必ず見積もりに織り込む。

クリーンアップ

検証リソースは課金対象です。特に OpenSearch Serverless は最小OCU課金が発生するため、検証後は確実に削除します。

削除順序は依存関係に注意してください。

# 1) AgentCore: target -> gateway
aws bedrock-agentcore-control delete-gateway-target --gateway-identifier <GW> --target-id <T>
aws bedrock-agentcore-control delete-gateway --gateway-identifier <GW>

# 2) Knowledge Base（Customer-managed は先に data source を RETAIN 推奨）
aws bedrock-agent delete-knowledge-base --knowledge-base-id <KB_ID>

# 3) OpenSearch Serverless: collection -> 関連ポリシー（暗号化/ネットワーク/データアクセス）
aws opensearchserverless delete-collection --id <COLL_ID>

# 4) S3 / IAM ロール
aws s3 rm s3://<BUCKET> --recursive && aws s3api delete-bucket --bucket <BUCKET>

補足：Managed Knowledge Base の削除は、マネージドデータストアの解体を伴うため数分かかることがあります。Customer-managed を削除する際は、ベクターストアより先に Knowledge Base（またはデータソース）を RETAIN で処理しておくと、DELETE_UNSUCCESSFUL を避けられます。

考察・今後の展望

Managed Knowledge Base は「RAGのインフラを持たない」という選択肢を現実的にしました。

PoCから本番までの距離が大幅に縮まります。なかでも、agentic RAG（自律的に検索計画 → 反復取得 → 引用付き回答）が組み込みである点は強力で、AgentCore と組み合わせれば、賢く根拠付きの検索・回答を自前のエージェント実装なしに最短で組み込めます。複雑・多段の業務質問に効くこの「賢さ」を、運用負荷ゼロで使えることが Managed KB 最大の価値だと感じました。

一方で、設計時に押さえておきたい「落とし穴」もあります。

  • マルチモーダルの入力要件：単体画像は不可（文書への埋め込みが必要）、発話のない音声は不可。
  • 日本語音声の解析精度：日本語音声は音写になる場合があり、逐語精度が要る用途では事前検証が必須。
  • API体系の差分：RetrieveAndGenerate は非対応。回答生成は AgenticRetrieveStream を使う。
  • CloudFormation 未対応：IaCを重視するなら、対応が追いつくまでカスタムリソースでの暫定対応を計画に織り込む。

おわりに

本記事では、Amazon Bedrock Managed Knowledge Base を東京リージョンの実機で、Customer-managed との比較・マルチモーダル・agentic retrieval・AgentCore 連携・CloudFormation 対応まで一通り検証しました。

マネージドの恩恵は大きい一方、API体系や入力要件・日本語精度の差分を理解して使い分けることが重要です。本記事が、RAG基盤の設計判断の一助になれば幸いです。

本記事の検証は2026年6月18日時点の挙動に基づきます。新機能はアップデートが頻繁なため、最新の仕様は必ず公式ドキュメントでご確認ください。

ロータッヘイ(執筆記事の一覧)

24卒入社の香港人です。
2026 Japan Top Engineers ＆ All AWS Certifications Engineers
Claude on AWS Expert
リンゴちゃん（デボンレックス）にいつも癒されています。