IskayPetのオフィスチームにはナレッジに関する課題がありました。返品ポリシー、獣医療プロトコル、オンボーディングの手順といった日常業務上の質問への回答が、4言語・3か国に分散した何百ものMicrosoft SharePointドキュメントに散在していたのです。大量のドキュメントリポジトリから適切な情報を見つけるには長い時間がかかりました。新しい店舗、国、手順が追加されるたびに問題は拡大していきました。
検索拡張生成（RAG）はこの課題を解決する一般的な方法です。しかし、RAGを本番環境で運用するには、通常、ベクターデータベース、エンベディングパイプライン、インジェストジョブを自ら運用する必要があります。
本記事では、イベリア半島の有力ペットケア企業であるIskayPetが、Amazon Bedrock Managed Knowledge Bases上に社内ナレッジアシスタントを構築した方法を紹介します。このアシスタントは、小売オペレーション、獣医療、人事・オンボーディング、調達にわたる従業員の質問に、4言語・3か国で回答し、管理すべきRAGインフラは一切ありません。チームは、店舗向けフロントエンドからAWSアーキテクチャとデプロイまで、ソリューション全体をKiroとClaude Haiku 4.5を使って構築しました。アーキテクチャ、SharePoint統合、検索設定の意思決定、本番環境での結果について解説します。
IskayPetについて
IskayPetはイベリア半島の有力ペットケア企業です。Kiwoko、Tiendanimal、Kivet、Clinicanimal、Animalisの各ブランドで、スペイン、ポルトガル、フランスに330以上の店舗を展開しています。従業員4,500人以上、顧客700万人を擁するIskayPetは、小売、獣医療クリニック、アニマルケア、調達、人事・オンボーディングにわたる事業を運営しています。各部門には、スペイン語、ポルトガル語、フランス語、英語での独自のポリシーと手順があります。
課題
すべての事業部門で、IskayPetのオフィススタッフは、手順、ポリシー、契約、オンボーディングに関する業務上の質問に答えるため、何百ものSharePointドキュメントを手作業で検索していました。3か国・4言語で事業を展開する中で、これには相当な時間がかかり、その答えは古かったり間違っていたりすることもよくありました。
社内ナレッジを照会する信頼できる方法はなく、国、部門、ドキュメントが追加されるたびに問題は拡大していきました。IskayPetには、以下を実現できるソリューションが必要でした。
- 自社の社内ドキュメントに基づいた自然言語の質問に回答すること。
- 個別のシステムを維持することなく、4言語に対応して動作すること。
- 各質問を適切なナレッジ（部門、国）に、相互汚染なしにルーティングすること。
- アーキテクチャを再設計せずに、新しい部門や国へスケールすること。
- 出典を引用し、従業員が回答を信頼して検証できるようにすること。
- コストのかかる移行を行わずに、既存のSharePointリポジトリを再利用すること。
なぜAmazon Bedrock Managed Knowledge Basesなのか
IskayPetは、マネージド型のRAGインフラを提供し、ベクターストア、エンベディング、インジェストパイプラインの運用が不要になるAmazon Bedrock Managed Knowledge Basesを選択しました。主な理由は以下のとおりです。
- マネージドRAG： Amazon Bedrockがデータインジェスト、マルチモーダル解析、ベクターストレージ、エンベディング生成、検索を処理します。IskayPetは保存・検索した分だけ支払います。
- ネイティブのSharePointコネクター： このコネクターは、IskayPetの既存のSharePoint環境から直接ドキュメントを取り込むため、データ移行が不要になりました。高度なインデックス作成を有効にすると、ドキュメントに埋め込まれた画像のコンテンツも処理されます。
- 組み込みのハイブリッド検索： セマンティック検索とキーワード（BM25）検索を追加コストなしで組み合わせることで、純粋なセマンティック検索では見落とされがちな、製品コードやリファレンスなどの正確な用語を回収できます。
- マネージドリランキング： 取得されたパッセージは、追加料金なしで関連度に応じて並べ替えられます。
- ドキュメントレベルのアクセス制御： ナレッジベースは検索時にソースシステム自体の権限を強制できるため、クエリはリクエスト元のユーザーがすでに読み取りを許可されているドキュメントのパッセージのみを返します。これにより、IskayPetは認可モデルを再構築する代わりにSharePointの権限をそのまま再利用できます。
- モデルの柔軟性： IskayPetはコスト効率の高いモデルで開始し、インフラを書き直すことなく後で変更できます。
- ネイティブのRAG評価： チームは内蔵の評価ツールを使って各ステップで品質を測定しました。
ソリューション概要
以下の図は、従業員の質問から権限を考慮した検索を経て、根拠のある引用付きの回答に至るまでのエンドツーエンドのフローを示しています。
図1: ソリューションアーキテクチャ
このソリューションは、従業員が既存のチャネルを通じてアクセスするアシスタントです。従業員が質問をすると、アシスタントはナレッジベースから、その従業員が閲覧を許可されているドキュメントに限定して、最も関連性の高いパッセージを取得します。その後、従業員の言語で根拠のある引用付きの回答を生成します。
大まかに言えば、フローは次のように機能します:
- 従業員がチャットインターフェースを通じて自然言語で質問を送信します。
- アプリケーションは、リクエストされたアシスタントのナレッジベースを呼び出し、従業員のIDを渡すことで、ドキュメントレベルの権限が検索に適用されるようにします。
- ナレッジベースは、インデックス化されたコンテンツに対してハイブリッド検索（セマンティック検索とキーワード検索）を実行し、結果をリランキングして、最も関連性の高いパッセージを出典参照とともに返します。
- 基盤モデル（FM）が、検索されたパッセージに基づいて根拠のある回答を生成します。プロンプトでは出典の引用を必須とし、回答が検索されたコンテンツに存在しない場合にはその旨を伝えるようモデルに指示しています。
- 従業員は、出典ドキュメントとともに回答を受け取り、フィードバック（良い/悪いの評価）を残すことができ、そのフィードバックは評価セットに反映されます。
Kiro と Claude Haiku 4.5 によるソリューションの構築
IskayPet は、店舗向けフロントエンドから AWS アーキテクチャやサービスのデプロイまで、ソリューション全体を以下を使用して構築しました: Kiro。エージェント型開発環境である Kiro を、Amazon Bedrock 上の Claude Haiku 4.5 で実行して使用しました。Amazon Bedrock で新しいモデルが利用可能になると、IskayPet は各ユースケースについてそれらを評価し、採用する予定です。
AWS リージョンごとのモデル利用可否については、以下を参照してください: Amazon Bedrock の AWS リージョン別サポートモデル.
- 店舗向けフロントエンド – チームは Kiro を使用して、店舗従業員がアシスタントとやり取りするためのフロントエンドを構築し、Claude Haiku 4.5 を使って UI コードを生成および反復改善しました。
- アーキテクチャとデプロイ – Kiro は、AWS アーキテクチャの設計や、ソリューションの基盤となるサービスのプロビジョニングにも役立ちました。具体的には、ナレッジベースの設定、データソース、AWS Identity and Access Management (IAM) ロール、アプリケーション層です。
Kiro と、Claude Haiku 4.5 のような高速でコスト効率の良いモデルを用いたエージェント型ワークフローにより、小規模なチームがコンセプトから本番環境へ迅速に移行できました。また、アプリケーションコードとインフラストラクチャの一貫性と保守性も保たれました。
取り込み: 高度なインデックス機能を備えた SharePoint コネクタ
IskayPet のドキュメントはすでに SharePoint に存在し、部門や国ごとに整理されていました。チームは移行を行うのではなく、Amazon Bedrock Managed Knowledge Bases のネイティブ SharePoint コネクタを使用しました。
データソースの「Advanced configurations（詳細設定）」の「Content indexing（コンテンツインデックス）」にある「Advanced indexing（高度なインデックス）」で、IskayPet は「Visual content in documents（ドキュメント内の視覚的コンテンツ）」を有効にしました。この設定により、ドキュメント（PDF、DOCX、PPTX）に埋め込まれた画像や、スタンドアロンの画像からコンテンツが抽出されます。手順書の中の図表やスキャンされたコンテンツが、別途前処理パイプラインを用意することなく検索可能になりました。
コネクタは増分同期を行うため、同期のたびに新規および更新されたドキュメントが取り込まれます。
複数国・複数部門のアーキテクチャ
重要な設計上の決定事項は、4 つの言語、複数の事業部門、3 つの国にわたるナレッジをどのように構造化するかでした。IskayPet は 2 つのアプローチを検討しました:
- 単一の共有ナレッジベースを使用し、すべてのドキュメントに国と部門のタグを付け、クエリごとに検索フィルターを適用する方式。これにより共有コンテンツの再利用が最大化されますが、すべてのドメインが 1 つのインデックスに結合されます。
- アシスタントごとに専用のナレッジベースを設け、それぞれが関連する SharePoint サイトやライブラリにスコープされる方式。これにより、各ナレッジの集合体がエンドツーエンドで分離され、各アシスタントを独立してチューニングできます。
IskayPet は、アシスタントごとのナレッジベースを選択しました。各アシスタントは特定の SharePoint サイトを参照し、インクルージョンパスによってさらに特定のドキュメントライブラリやフォルダに絞り込むことができるため、意図されたコンテンツのみがインデックス化され、企業サイト全体が対象になることはありません。新しい部門や国を追加するということは、システムを再設計するのではなく、アシスタントを追加して適切なコンテンツを参照させることを意味します。
アクセス制御
アクセスは、ユーザーの既存の SharePoint 権限によって管理されます。アシスタントは何も新しいアクセス権を付与するわけではありません。従業員がすでに開くことのできるドキュメントの照会を、より簡単にするだけです。これは 2 つのレベルで機能します。
- ユーザーに表示されるアシスタント – 従業員には、基盤となるドキュメントを読む権限を持っているアシスタントのみが表示されます。この権限は、直接の権限、グループメンバーシップ、または特定のフォルダへのアクセスに由来するものです。アクセス権を確認できない場合、アシスタントは表示されずに非表示になります。
- 回答の根拠となるドキュメント – アクセス権は、検索時にもドキュメントごとに強制されます。従業員の ID がナレッジベースに渡され、その人物が閲覧を許可されているドキュメントからのみパッセージが返されます。Amazon Bedrock Managed Knowledge Bases はこのドキュメントレベルのアクセス制御をネイティブにサポートしているため、同じ質問に対する同じ回答でも、異なる権限を持つ 2 人の従業員間で正当に異なる場合があります。
アクセス確認のたびに権限が SharePoint から読み取られるため、SharePoint でのアクセス権の取り消しや付与は、アプリケーションを変更することなくアシスタントに反映されます。
検索と生成の設定
RAGシステムの品質は主にインジェスト、検索、生成の段階で決まります。ファインチューニングは補完的な手法です。このユースケースでIskayPetが調整した設定は以下の通りです:
- チャンキング – マネージド型ナレッジベースが処理するため、チームはチャンキングパイプラインを構築・調整する必要がありませんでした。これにより、セルフマネージドのRAGでは通常大きな運用工数となるコンポーネントが排除されました。
- ハイブリッド検索 – ナレッジベースはセマンティック検索とキーワード検索を組み合わせており、純粋なセマンティック検索では見逃されがちな製品コードなどの正確な用語を復元できます。
- 結果の数 – 評価セットに対して調整されました。アシスタントは25のパッセージを取得し、重複やコンテキストとして短すぎる断片を除去した後、最大15をプロンプトに注入します。この数値はすべての質問で入力トークンが乗算されるため、主なコストのレバーとなります。
- 生成プロンプト – コーポレートトーンを強制し、出典の引用を要求し、取得したコンテンツに回答が含まれていない場合にはその旨を述べるようモデルに指示します。これによりハルシネーションが減少し、トレーサビリティが向上します。
本番運用の管理策として、チームは Amazon Bedrock Guardrails を追加し、生成される回答にコンテンツフィルタリングと責任あるAIポリシーを適用しています。
- 評価 – Amazon Bedrock のネイティブな RAG 評価を使用し、実際の利用からの高評価・低評価のフィードバックを評価セットとして活用して、各変更の前後で品質を測定します。
応答の生成
回答の生成には、IskayPet は Amazon Bedrock 上でコスト効率の良い基盤モデルを使用しています。ナレッジベースは検索と生成を分離しているため、IskayPet は取り込み層や検索層に触れることなく、生成モデルを切り替えたりアップグレードしたりできます。これにより、チームは利用の拡大に応じてコストと回答品質のバランスを取ることができます。
コスト効率
ナレッジベースにはマルチモーダル解析、埋め込み生成、リランキングが追加料金なしで含まれているため、IskayPet の継続的なコストは主にインデックスストレージ、検索 API 呼び出し、生成モデルのトークンから発生します。本番環境では、各プロンプトに注入されるパッセージのために、入力トークンがそのコストの大部分を占めています。チームは、利用の拡大に伴い、プロンプトの安定した部分に対するプロンプトキャッシングや、非インタラクティブなワークロードに対するバッチ推論など、さらなる最適化を検討しています。
結果
本番環境での最初の約2か月間で、IskayPet は以下を確認しました:
- より速い回答 – 運用上の答えを見つけるまでの時間が 3–5 分から約 7 秒に短縮されました。
- より高い生産性 – 手順やポリシーの検索にかかる時間が約 95 パーセント削減されました。
- スケール – このソリューションは、すべての事業領域と国を対象に、月に約 100,000 件のクエリを処理できると見込まれています。
結論
IskayPet は、Amazon Bedrock Managed Knowledge Bases 上に本番運用可能なコーポレートナレッジアシスタントを構築し、3 か国、4 言語、複数の事業領域に対応させ、RAG インフラを一切運用することなく実現しました。ネイティブの SharePoint コネクタにより、既存のリポジトリをそのまま再利用しました。アシスタントごとに専用のナレッジベースを設けたことで、各ドメインがエンドツーエンドで分離されたクリーンな複数国構成を実現しました。マネージド型の解析、埋め込み、リランキングにより、運用工面とコストの両方を低く抑えられました。フロントエンドと AWS アーキテクチャを Kiro と Claude Haiku 4.5 で構築したことで、小規模なチームでも迅速に本番環境へ到達できました。
同様のナレッジ検索の課題に直面している場合は、AWS 無料利用枠で始めて、Amazon Bedrock コンソールで最初のナレッジベースを構築できます。さらに詳しく知るには、以下のリソースを参照し、SharePoint コネクタとドキュメントレベルのアクセスコントロールを自分のドキュメントに対して試してみてください。
詳細については、以下を参照してください: Amazon Bedrock Managed Knowledge Base および Amazon Bedrock evaluations を使用した RAG ソースのパフォーマンス評価.