IskayPet Knowledge Assistant、企業内検索をマネージド Amazon Bedrock へ移行
2026年10月22日に公開されたケーススタディによると、IskayPet は4言語・3か国にまたがる企業向けナレッジアシスタントを構築した。IskayPet のナレッジアシスタントは、既存の SharePoint 文書をもとに従業員の質問へ回答するため、Amazon Bedrock Managed Knowledge Bases を利用している。その意義は責任分担にある。検索インフラは AWS が運用する一方で、信頼できるナレッジに対する責任は企業側に残る。
検索拡張生成（RAG）は、AI モデルが回答する前に検索で取得した文書を提供する仕組みである。このアプローチにより、企業向けアシスタントは学習データを超えた参照ライブラリを利用できる。マネージドサービスを選択すると、そのライブラリの技術的な基盤を誰が維持するかは変わるが、権限、アクセス、正確性に関する課題は組織に残る。
代替案は、より多くのインフラ選択肢と保守責任を伴う、顧客管理型の検索システムである。すでに文書を保管している企業にとっては、Microsoft の SharePoint agents も別の比較対象となる。IskayPet の導入は、マネージドかカスタムかという判断を具体的に示しているが、すべての組織でどちらか一方のプラットフォームがより良い回答を提供すると立証するものではない。
IskayPet Knowledge Assistant が変えたこと
AWS と IskayPet が共同執筆した企業ナレッジのケーススタディによると、このアシスタントは小売、獣医業務、オンボーディング、調達を対象としている。スペイン、ポルトガル、フランスにわたり、スペイン語、ポルトガル語、フランス語、英語をサポートする。
著者らは、業務上の回答を見つけるまでの時間が、約2か月の本番運用期間中に3～5分から約7秒へ短縮されたと報告している。月間クエリ数は約10万件と予測している。この数値は実証済みの利用量ではなく、想定需要を示すものだ。
実務上の変化は、従業員の質問から会社が文書化したガイダンスまでの経路が短くなることだ。 文書リポジトリと回答インターフェースでは、従業員に求められることが異なるため、これは重要である。
リポジトリでは、適切なファイルを見分け、その構造をたどり、関連する箇所を特定しなければならない。アシスタントは、回答を提示する前にこれらの手順を実行しようとする。その後、従業員は回答が実際の状況に対応しているかを判断する必要がある。
この変化により、労力の所在も変わる。文書を開く時間が減れば、適用される規則を確認する時間を増やせる可能性がある。ただし、回答が速くなるほど、情報源を確認せずに回答を受け入れやすくもなる。
たとえば、返品ポリシーに関する説明用の質問を考えてみよう。従業員は、特定の購入に例外が適用されるかを尋ねるかもしれない。有用な回答であれば、適用対象のポリシーを特定し、その条件を保持する。例外を省いた流暢な要約は、異なる業務上の結果を生み出す。
同じ区別はオンボーディングにも当てはまる。一般的なチェックリストを見つけても、それが従業員の役割や勤務地に合っている場合にしか役立たない。システムは関連文書を取得できても、別の状況向けの指示を選ぶ可能性はある。
こうした例は、報告された速度改善が注目に値する一方で、それだけで完全なビジネスケースにはならない理由を示している。検索時間はタスク完了の一要素にすぎない。検証、エスカレーション、修正にも従業員の時間が必要となる。
意味のある比較では、質問から解決までの全過程を追う必要がある。従業員はタスクを正しく完了できたのか。管理者による介入は依然として必要だったのか。回答は追加の検索を防いだのか、それとも検索の場所を移しただけなのか。
この公開内容は、新しい汎用モデルのリリースではなく、企業による導入事例を記録したものである。ニュースとしての価値は、マネージド検索を反復的な業務課題に適用した点にある。その影響は、この適用が日常業務をどれだけ確実に処理できるかに左右される。
したがって、エンタープライズの購入担当者にとって有用な要点は具体的だ。回答インターフェースは、既存のガイダンスへのアクセスを改善できる。その価値を測るには、従業員が回答を受け取った後に何をするのかを調べる必要がある。
マネージドインフラがエンタープライズの購買判断を変える
マネージド検索は、購買判断の重心をアプリケーション品質、運用適合性、説明責任へと移す。 エンジニアリングの取り組みは引き続き重要だが、検索インフラの維持は計算上の別の要素になる。
AWS のドキュメントによると、managed knowledge bases は、取り込み、保存、インデックス作成、検索インフラを処理する。取り込みはソース資料をシステムに取り込み、インデックス作成は検索のためにそれらを整理する。サービスはマネージドの埋め込みモデルと再ランキングモデルも提供する。
埋め込みは類似性検索のためにコンテンツを数値で表現するもので、再ランキングは取得した資料を関連性に応じて並べ替える。AWS はこの構成を、顧客が基盤となるデータストアをプロビジョニングし維持する顧客管理型ナレッジベースと区別している。
この違いは、エンジニアリングリーダーにより明確な問いを与える。このアプリケーションにとって、どのインフラ上の判断が優位性を生み出すのか。要件が日常的な社内ガイダンスへのアクセスであるなら、カスタムのストレージアーキテクチャには具体的な正当化が必要となる。
企業は、特殊な検索動作、専門的な制御、またはインフラに対するより深い可視性を必要とするかもしれない。そうした要件は、追加のエンジニアリング責任を正当化し得る。ただし、自動的な前提条件として扱うのではなく、実際のアプリケーションニーズに照らして評価すべきである。
マネージドという選択肢は、社内開発提案に対する要求を変える。カスタムシステムを求めるチームは、追加の制御が何を実現するのかを説明しなければならない。「チャットボットが必要だ」というだけでは、なぜ企業が自前で検索コンポーネントを運用すべきかについて、ほとんど示唆を与えない。
同じ圧力はベンダーにも及ぶ。インフラの柔軟性を販売するサプライヤーは、その柔軟性が顧客の成果をどこで改善するのかを示す必要がある。シンプルさを販売する別のサプライヤーは、マネージドサービスの境界を説明する必要がある。
どちらの提案も、機能数だけでは評価できない。より広い設定メニューは、組織がそれを効果的に活用できる場合にのみ価値を持つ。設定の選択肢が少ないことは、デフォルト設定がワークロードの要件を満たす場合に価値を持つ。
したがって購入担当者にとって、Amazon Bedrock の検索機能は、より広範な所有責任の判断の一部となる。回答漏れを誰が診断するのか。変更を誰がレビューするのか。テスト用の質問を誰が維持するのか。従業員が特定の結果を見た理由を誰が説明できるのか。
基盤となるサービスが正しく動作している場合でも、これらの責任には明確な担当者が必要である。コネクタは、企業が廃止すべき文書を正常に取り込む可能性がある。検索システムは、権限が過度に広く割り当てられたコンテンツを正しく表示する可能性がある。
また、調達部門は技術サポートと編集上の責任を区別すべきである。サービスプロバイダーは失敗したリクエストを調査できる。しかし、どの社内ポリシーが会社の現行方針を示すかを独自に判断することはできない。
コスト比較にも同様の注意が必要である。インフラへの支出は、アプリケーション経済性の一部しか捉えていない。コンテンツレビュー、従業員サポート、評価、インシデント調査にもスタッフの時間が必要となる。
マネージドサービスは、削減する作業について評価されるべきだ。公正な評価では、残る作業も特定する。この方が、どちらのアーキテクチャも手間がかからないと表現するより有用な比較になる。
戦略的な意味合いは、エンタープライズAIの提案により高い基準を求めることだ。チームは、アーキテクチャ上の選択を測定可能な業務要件に結び付けるべきである。検索システムを組み立てられることは、出発点にすぎない。
分離されたアシスタントが事業上の境界を検索に持ち込む
ケーススタディの著者らによると、IskayPet は各アシスタント向けに、選択した SharePoint コンテンツを対象とする個別のナレッジベースを選んだ。検索では、従業員が既存の文書に持つ権限が適用される。
この設計は、回答の対象範囲を明示的なプロダクト判断にする。 そして、広範な企業内検索ボックスでは見えにくくなる問いを投げかける。どのナレッジ領域がこのリクエストに回答すべきなのか。
共有インデックスは、あらゆる質問にとって便利な行き先になることを約束する。その利便性には、重なり合う部門、拠点、文書の目的をアプリケーション側が区別することが求められる。誤った組織的文脈から参照していても、回答は関連性があるように聞こえることがある。
アシスタントを分離すると、この問題は変わる。各アシスタントは、可能な情報源がより限定された状態で始まる。その後、組織は従業員にその境界を理解させ、責任範囲の変化に合わせて維持しなければならない。
これは、広範な発見性と意図的な対象範囲の間のトレードオフである。より限定されたアシスタントは、その目的を説明しやすくできる。一方で、部門横断の質問が、どのアシスタントの完全な視野にも入らなくなる可能性もある。
たとえば、購買上の例外とオンボーディング要件を組み合わせた説明用の質問を想定してみよう。調達ガイダンスが一部に回答し、人事運用のガイダンスが別の部分に回答するかもしれない。質問がこれらの境界をまたぐとき、インターフェースには適切な応答が必要となる。
考えられる応答には、明確化を求める、不足している文脈を示す、または従業員を別の担当者へ案内することが含まれる。適切な選択はワークフローに依存する。不完全な回答を完全なものとして静かに提示すれば、その制約を隠すことになる。
このため、アシスタントの境界はプロダクト設計の議論に含めるべきである。それは、ユーザーがシステムに合理的に期待できることを決定する。また、失敗をどのように説明すべきかにも影響する。
権限は別の区別を導入する。アクセスは、従業員に文書を読む権利があるかに答える。適用可能性は、その文書がその状況を規定するかに答える。両者は関連しているが、結果の異なる問いである。
従業員は、複数の拠点のガイダンスに正当にアクセスできるかもしれない。しかし、それですべてのポリシーが地域の業務に等しく適用できるわけではない。アシスタントには、この区別を維持するための十分な文脈が必要である。
同様に、言語が地理の偶発的な代替指標になってはならない。英語で質問する人が、別の言語で書かれた地域ポリシーを必要とする可能性がある。言語的な類似性だけに従うシステムでは、誤った権威を選ぶリスクがある。
これらは IskayPet で観察された障害の証拠ではなく、このアーキテクチャから導かれる分析上の含意である。別の企業がこの設計を採用する前に検討すべき点を説明している。
Microsoft は有用な比較対象を提供している。同社の SharePoint agents は、選択された情報源を使用し、ユーザーのコンテンツ権限を尊重する。Microsoft は、SharePoint、Teams、Microsoft Copilot を通じたアクセスについても説明している。
これは、同じ文書資産を評価する組織にとって代替アプローチを示すものだ。IskayPet の導入との性能比較を示すものではない。どちらを選ぶかには、組織自身の質問、アイデンティティ、ワークフローをテストする必要がある。
より広い競争上の論点は、所有権に関わるものです。企業は、自社のコラボレーション環境に組み込まれたアシスタントと、マネージドクラウドサービスを中心に構築されたアプリケーションを比較できます。どちらが有利かは、統合要件と運用上の統制に左右されます。
チームナレッジベースを比較する読者にとって、この違いは根本的です。共有ドキュメントの集合は、その境界、権限、および対象読者が明確になって初めて役に立ちます。
多言語の社内検索はエビデンスへの要求水準を引き上げる
多言語の社内検索では、回答が言語をまたいで適用すべきルールを維持していることを示すエビデンスが必要です。 自然な表現の回答であっても、すべての条件が損なわれずに保持されていることの証明にはなりません。
翻訳は情報へのアクセスを容易にする一方で、限定条件の受け取られ方を変えることがあります。推奨、要件、例外には、それぞれ異なる運用上の意味があります。評価では、流暢さだけを評価するのではなく、これらの意味を確認する必要があります。
たとえば、従業員が承認できる内容と、マネージャーの承認を必要とする内容を区別するポリシーを考えてみましょう。短縮された回答では、主な指示は維持されていても、承認条件が抜け落ちる可能性があります。その結果、読みやすくても誤った行動を促すことになります。
ここには厳しい評価上の課題があります。システムは正しい情報を見つけ、質問を解釈し、適切に回答を表現しなければなりません。最終的な文言だけをテストすると、誤りの原因を特定しにくくなります。
AWSの検索評価に関するドキュメントでは、検索のみの評価と、検索および生成を含む評価を分けています。前者は取得された情報を検証し、後者は生成された応答も検証します。これにより、異なる段階を個別に評価する基盤が得られます。
この分離は、Amazon Bedrockの検索構成を比較する際に重要です。適用すべき文書が検索結果に含まれなければ、回答プロンプトを書き換えても誤った問題に対処することになります。検索が成功しているなら、生成段階に注目するほうが有益です。
エンタープライズの購入担当者にとって、実務上の意味は診断の質が上がることです。「アシスタントが間違っていた」という表現は結果を示すだけです。文書が欠けていたのか、条件が誤解されたのか、場所に関して誤った前提が置かれたのかを区別しません。
したがって、評価用の質問には運用上の文脈を含めるべきです。「手順は何ですか？」のような曖昧な質問では、指定されていない事項が多すぎます。現実的な質問では、正しい回答に必要な条件を確定できるだけの状況を示します。
一部のテストでは、意図的にその文脈を省くべきです。信頼できるアシスタントは、確認が必要な場面を認識する必要があります。場所や部署を自信満々に選ぶことは、従業員に短い追加質問をするより悪い結果を招く可能性があります。
言語間で同等の質問を用意することも、有用な確認になります。文言を逐語的に一致させる必要はありません。適用されるポリシー、必要な行動、関連する例外は一貫していなければなりません。
ローカルのレビュアーは重要です。一般的な言語評価では見逃される違いを特定できるからです。文法的に正しい文でも、なじみのない用語を使ったり、義務を弱めたりする場合があります。こうした欠陥は、従業員が回答に基づいて行動できるかどうかに影響します。
結果は言語別、事業領域別にも可視化すべきです。総合スコアは、より小規模な従業員グループにとって体験が劣ることを隠してしまう可能性があります。集計されたパフォーマンスでは、アプリケーションのどこに注意が必要かは分かりません。
Microsoftのドキュメントも同様に、生成コンテンツは不正確または古くなっている可能性があり、検証すべきだと注意を促しています。これは、共通する評価ニーズに比較の軸を置くため、有用な競合上の参考になります。
最も強いエビデンスは、言語面の確認と実際の業務成果を組み合わせるものです。従業員は適用すべき手順を特定できたか。回答は例外を保持していたか。情報源はその行動を裏付けていたか。
これらの問いは、多言語対応をより意味のあるものにします。知識を有用たらしめる区別を失わずに、システムが企業知識を言語間で伝達できるかを評価するものです。
報告された速度向上は、品質とガバナンスに関する疑問を残す
公開された説明には、ベンチマーク用データセットや言語別の詳細な精度スコアは示されていません。そのため、報告された時間短縮は、運用上の有効性を総合的に評価する場合よりも限定的な結論を裏付けるものです。
迅速な回答と信頼できる回答には、別々のエビデンスが必要です。 検索アプリケーションは前者を改善できても、後者に関する重要な疑問を残す可能性があります。
この限定は、入手可能なエビデンスに基づくものです。導入によって信頼性の低い応答が生じているという主張ではありません。顧客事例は、有用なアーキテクチャ上の詳細を提供できますが、独立した評価に必要なすべてを示すとは限りません。
ビフォーアフター比較を解釈する際、ベンチマーク手法の欠如は重要です。読者は、両方の測定で同じ種類の質問が用いられたかを知る必要があります。また、時間計測が回答の配信時点で終わったのか、それとも問題解決の成功時点まで含むのかも知る必要があります。
質問の難易度は結果を変え得ます。単純な検索は、複数の文書にまたがる例外を組み合わせる依頼とは異なります。構成を説明せずに両方をまとめて測定すると、平均値の解釈は難しくなります。
利用予測にも同様の規律が必要です。想定需要はキャパシティ計画に役立ちます。実証された導入には、従業員が関連業務のためにアプリケーションを継続利用していることを示すエビデンスが必要です。
クエリ数が多いだけでは、なお曖昧さが残ります。それは有益な継続利用を示す場合もあれば、受け入れ可能な回答を得ようとする繰り返しの試行を反映する場合もあります。解決率と修正パターンは、これらの可能性を区別する助けになります。
情報源の品質は、別のガバナンス上の問題をもたらします。アシスタントは、すでに置き換えられたポリシーを正確に要約することがあります。その回答は取得したテキストには忠実でも、従業員の現在の業務には不適切なままです。
したがって、組織には現在の権威ある情報を特定する方法が必要です。文書の所有者、レビュー日、置換手順は、回答システムの実務上の信頼性の一部になります。検索品質では、ポリシー所有者間で未解決の見解の相違を解決できません。
権限には独自のレビューが必要です。既存のアクセスルールを維持することは、そのルールにすでに組み込まれた判断を維持することです。それらの過去の判断が今も適切かどうかを決めるものではありません。
この違いは、情報を見つけやすくなるほど重要になります。従業員がブラウジングではほとんど遭遇しなかった資料も、直接質問すれば容易に利用できるようになります。企業は、このアクセス可能性の変化を理解する必要があります。
コンテンツ管理は、別のリスク領域に対処します。AWSはBedrock Guardrailsを、機密情報のフィルタリングや文脈的根拠の確認を含む、入力と応答のための設定可能な安全策として説明しています。根拠の確認では、応答が提供された資料によって裏付けられているかを評価します。
これらの機能は、意図された目的に沿って評価すべきです。不適切な応答をフィルタリングしても、基礎となるポリシーが最新であることは証明されません。権限チェックをしても、要約が完全であることは証明されません。
信頼できるガバナンスモデルでは、各責任を明確に割り当てます。ポリシー所有者は権威あるガイダンスを維持します。アプリケーション所有者は回答の挙動を調査します。セキュリティチームはアクセスを評価します。従業員には、誤っていると思われる回答を報告する明確な経路が必要です。
購入担当者にとって、これらの問いはIskayPetのナレッジアシスタント事例の価値を明確にします。報告された改善は検討に値します。再現可能な価値を確立するには、応答速度を超えるエビデンスが必要です。
次のエビデンスは、品質、アクセス、継続利用を追跡すべき
最も有用な追加検証は、文書や利用状況が変化しても、導入環境が正確かつ適切な回答を継続して生成できるかを示すものです。 今後数か月にわたり、3つの指標に注目する価値があります。
まず、言語別および業務機能別に分類された評価結果を確認してください。これらの結果では、質問セット、期待される回答、レビュアーが正確性をどのように判断したかを説明すべきです。そうすれば、報告された効果を評価しやすくなります。
これらのカテゴリー全体でより強い結果が得られれば、より広範な利用への信頼を支えることになります。あるカテゴリーで継続的な差が見られれば、より限定的な結論を示唆します。どちらの結果も、単一の総合満足度指標より有益です。
評価には、アシスタントが情報源から回答できない質問も含めるべきです。十分なエビデンスがないことを認識するのも、有用なパフォーマンスの一部です。確認を求めるアプリケーションは、裏付けのない前提からワークフローを守ることができます。
モデルや検索設定の変更も、エビデンスを得る別の機会になります。追加検証では、変更前後で同じ代表的な質問を比較できます。そうすれば、改善と従業員からの依頼における通常のばらつきを区別しやすくなります。
次に、情報源の更新とアクセス変更に関するエビデンスを確認してください。本番運用のアシスタントは、ポリシーが変わった場合や従業員の権限が終了した場合に、適切に応答する必要があります。静的なデモでは、時間の経過に伴うその挙動を証明できません。
有用なエビデンスでは、改訂されたガイダンスがいつ回答に利用可能になるか、また古いガイダンスがどのように回答へ影響しなくなるかを説明します。さらに、アクセス変更がその後のリクエストにどのように影響するかも示します。
一貫した挙動は、このワークロードにおけるマネージドサービスの有効性を強めます。更新の遅れや責任の不明確さは、追加の運用作業を露呈させます。関連する問いは、企業がこれらの状況を予測可能な形で検出し、解決できるかどうかです。
この指標は管理運用にも関係します。別のアシスタントを追加する際には、明確な所有者、情報源の範囲、レビュー手順を伴うべきです。こうした責任を管理可能な状態に保てるとき、拡張は価値を生みます。
3つ目に、解決の成功と併せて継続的な導入状況を確認してください。実際の需要は、公開された予測に文脈を与えます。継続利用、情報源の検証、エスカレーション、修正のパターンは、トラフィックだけよりも従業員にとっての価値をよく説明します。
回避可能なエスカレーションが少ない安定した利用は、運用上の根拠を支えます。頻繁な言い換えや未解決の質問は、使いやすさまたは知識の不足を示します。応答配信が高速なままであっても、これらのパターンは調査に値します。
これらの指標のいずれも、どの企業が最も高性能な汎用モデルを持つかを競う必要はありません。対象は、特定の文書群に対する特定アプリケーションのパフォーマンスです。エンタープライズでの購入を正当化できるのは、この水準です。
同様の投資を評価するチームは、範囲を限定した業務上の問いと、権威ある文書セットから始めてください。候補となるシステムが、通常の依頼、欠けた文脈、改訂されたポリシー、制限されたアクセスをどのように扱うかを比較します。ローカルのレビュアーに、回答が従業員に実際に必要な指示を保っているか判断してもらってください。応答速度を、解決の成功、修正に要する労力、継続的な管理運用とともに可視化してください。IskayPetのナレッジアシスタントは検討すべき具体的な導入事例を提供しますが、アーキテクチャの選択は自社のエビデンスに基づいて決めるべきです。より広範な展開を承認する前に、どの運用上の意思決定が改善され、どの不確実性が残っているかをチームに示してもらってください。従業員がその回答を信頼できることを、どのようなエビデンスが立証するでしょうか。
