Claude Desktop Web Searchが最新の回答を取得、ただし経路はAWSが制御
Claude Desktop web searchは10月2日、別個の検索APIを経由せずに知識の空白を埋める、AWS管理下の経路を獲得した。AWSは、Amazon Bedrock上のClaude DesktopをAmazon Bedrock AgentCoreのマネージドWeb Searchツールへ接続するリファレンスアーキテクチャを公開した。企業は認証、認可、検索インフラを既存のAWS環境内に維持しながら、モデルに最新情報を取得させられる。
この組み合わせが重要なのは、Bedrock上のClaude DesktopがAnthropicのコンシューマー向けサービスで利用できるすべての機能を自動的に継承するわけではないためだ。検索ツールが接続されていなければ、その回答は基盤モデルの学習カットオフと、ユーザーが提供したコンテキストに制約される。新しいドキュメント、変化する製品仕様、現在の出来事に関する質問では、古い回答が返る可能性がある。
より深い競争は、Claudeと別のチャットボットの対決ではない。AWSが管理し、アイデンティティに紐付く検索経路と、外部検索APIやカスタム検索サービスを接続する一般的な慣行との競争である。AWSは複数の統合作業を不要にする一方、多段階のアイデンティティチェーンを導入し、ネットワーク境界、権限、ログ、運用責任に関する重要な問題をもたらす。
Claude Desktop Web SearchにAWS管理の経路が追加
AWSは、外部アドオンだったWebアクセスを、Claude DesktopがMCP経由で検出できるマネージドAgentCoreターゲットへと変えた。
AWSは、新しいClaudeモデルのリリースではなく、技術的な手順説明としてリファレンスアーキテクチャを公開した。中心となる変更はアーキテクチャにある。Claude Desktopは、AWS Web SearchをModel Context Protocolツールとして公開するAgentCore Gatewayに接続できる。
MCPは、AIアプリケーションが標準インターフェースを介して外部ツールを検出し、呼び出せるようにするオープンプロトコルだ。この構成では、ゲートウェイがClaude Desktopにツール一覧を提示する。Claudeは、モデルがすでに持っていない情報にプロンプトが依存する場合、検索を要求できる。
この検索サービスは、ユーザー管理のサードパーティAPIを薄くラップしたものではない。AWSによれば、数百億件のドキュメントを対象とするAmazon運営のインデックスに依存している。マネージドサービスはタイトル、URL、スニペット、公開日を返すとともに、モデルのコンテキストウィンドウに適した文章を抽出する。
AWSはまた、このインデックスが継続的に更新され、新規または変更されたコンテンツは数分以内に反映されるとしている。この主張は時間に敏感な質問にとって重要だが、検索の鮮度はページ、クロールの可用性、パブリッシャーの挙動によって依然として異なる。頻繁に更新される公開ドキュメントと、複雑なスクリプトの背後にある無名のページでは、取得の難しさが異なる。
より広範なWeb Searchドキュメントでは、マネージドインデックスとともにドメイン制御や日付フィルターが説明されている。ターゲット管理者は指定したドメインを除外できる。新しいコネクタバージョンでは、ドメインの許可ルールと、リクエスト単位の公開日範囲もサポートされる。
これらの制御は、単なるオープンWebへの経路ではなく、検索を取り巻くポリシーの領域を作り出す。組織はアシスタントを承認済みのドキュメントドメインに限定したり、社内の信頼要件を満たさないソースを除外したりできる。また、定義した期間に公開されたコンテンツへリクエストを絞り込むことも可能だ。
この手順説明では、この統合でサポートされるAWSリージョンとして、北バージニアのUS East、アイルランドのEurope、東京のAsia Pacificの3つを挙げている。企業は、これらの場所を恒久的な制約と見なす前に、最新の提供状況を確認すべきだ。AWSのサービス提供範囲は、古いチュートリアルとは独立して拡大する可能性がある。
実務上の結果は明快だ。Claude Desktopは、開発者がクローラーを構築したり、検索結果を正規化したり、別の検索プロバイダーの認証情報を管理したりせずに、静的なモデル知識を超えられる。これは、返されたすべての事実が正しいことを意味しない。モデルに、より新しい根拠を探すための統制された仕組みを与えるものだ。
知識カットオフは本質的にガバナンスの問題だった
不足していた機能は単なる検索ではなかった。企業には、管理されていない新たなデータ経路を作らずに最新情報を得る必要があった。
ユーザーが最近のソフトウェアリリース、更新されたクラウドドキュメント、新しい規制、変化する運用状況について尋ねると、モデルの知識カットオフが明らかになる。モデルは提供された資料に基づいて推論できるが、アプリケーションが適切なツールを与えない限り、欠けた事実を取得することはできない。
コンシューマー向けAI製品は、しばしば検索ボタンの背後にこの違いを隠している。企業導入ではそうはいかない。セキュリティチームは、どのサービスがクエリを受け取るのか、認証情報がどこにあるのか、誰がリクエストを開始したのか、どの権限がその操作を統制したのかを把握する必要がある。
そのため、Claude Desktop web searchはアイデンティティとインフラの意思決定となる。チームは外部検索サービスを接続することも、自ら検索レイヤーを運用することも、クラウド環境内のマネージドサービスを利用することもできる。各選択は、関与するベンダー、認証情報、ログ、障害点の数を変える。
AWSはAgentCore Gatewayを制御点として位置付けている。ゲートウェイは、認証とターゲットアクセスのルールを適用しながら、AIクライアントにツールを提示する仲介役だ。Claude Desktopは、デスクトップ設定に検索APIキーを置くことなく検索を呼び出せる。
ゲートウェイはまた、クライアント向けのアイデンティティフローと、マネージドターゲットの呼び出しに使う権限を分離する。Claude Desktopはユーザーに紐付いたトークンをゲートウェイに提示する。次にゲートウェイは、必要な権限を持つAWSサービスロールを通じてWeb Searchを呼び出す。
この区別により、バックエンド認証情報が直接露出するリスクを抑えられる。また、管理者がアクセスを確認し、ポリシーを適用する場所も得られる。ただし、すべてのクエリが適切かどうか、すべてのユーザーに同一の検索機能を与えるべきかどうかを自動的に判断するわけではない。
この設計は、従業員アクセスにAWS IAM Identity Centerをすでに利用している組織に適している。別個のアイデンティティディレクトリを作る代わりに、承認済みのユーザーやグループへアプリケーションを割り当てられる。既存のオフボーディングやアクセスレビューのプロセスで、検索接続も扱えるようになる。
これがアーキテクチャによって生まれる主な圧力だ。外部検索APIを利用するチームは、ユーザークエリのための追加の認証情報ストアと追加の処理者を正当化しなければならない。カスタム検索スタックを運用するチームは、エンジニアリングと監視の負担を正当化しなければならない。AWSはこうした懸念を集約する経路を提供するが、それは同社のクラウド境界とセットアップモデルを受け入れる組織に限られる。
この変化はナレッジワークフローにも影響する。検索は最新の公開情報を提供する一方、knowledge blendingのようなシステムは、公開情報の発見とユーザーが保持する社内コンテキストを結び付けられる。有用な区別は、組織の外部で変化したものを取得することと、組織がすでに知っていることを想起することの間にある。
AgentCoreはAPIキーをアイデンティティチェーンに置き換える
中核となる仕組みは、緩やかな共有認証情報を、追跡可能なユーザー認証、トークン発行、ゲートウェイ検証、AWS認可済み検索の連鎖へ置き換える。
フローは、組織のシングルサインオンプロセスを通じて従業員を認証するAWS IAM Identity Centerから始まる。公開された設計では、Identity CenterはSAMLアイデンティティプロバイダーとして機能する。SAMLは、アイデンティティプロバイダーとアプリケーションの間で認証アサーションを転送するための標準だ。
Amazon Cognitoは、このSAMLログインとAgentCore Gatewayの間に位置する。CognitoはIdentity Centerのユーザーをフェデレーションし、OAuth 2.0認可コードフローを完了して、JSON Web Tokenを発行する。JWTは、受信サービスが検証できるクレームを含む署名付きトークンだ。
Claude Desktopは、設定されたクライアントIDとクライアントシークレットを通じて認可フローを開始する。コールバックはポート53280のlocalhostアドレスに戻る。ユーザーがサインインすると、Claude Desktopはゲートウェイへの接続に必要なトークンを受け取る。
AgentCore Gatewayは、すべてのリクエストでそのトークンを検証する。呼び出しを受け入れる前に、設定されたOpenID Connectディスカバリー情報と許可されたクライアント識別子を確認する。AWSのインバウンド認可ガイドは、より細かな検証のためにオーディエンス、スコープ、必須カスタムクレームもサポートしている。
この粒度は重要だ。有効な組織アイデンティティが、必ずしもすべてのAIツールを使う権限を意味するわけではない。管理者は、アイデンティティ設計に応じて、割り当てられたグループ、クライアント制限、スコープ、クレームを通じてアクセスを狭められる。
認証後、ゲートウェイはマネージドWeb SearchコネクタをMCP経由で公開する。Claude Desktopはプロトコルのtools/list操作を使い、利用可能なツールを検出する。Claudeがプロンプトに最新情報が必要だと判断すると、ゲートウェイを通じてツールを呼び出す。
この手順説明では、AWS Web Searchリソースを呼び出す権限をゲートウェイの実行ロールへ設定している。これはアウトバウンド認可であり、ゲートウェイがインバウンドのユーザーリクエストを検証した後にターゲットへ認証することを意味する。ユーザーに基盤となるAWSロール認証情報が渡ることはない。
AWSは、IAMベースのインバウンドアクセスやオフロードされた認可を含む、他の認可パターンについてもゲートウェイの概念で文書化している。Claude Desktopのパターンでは、デスクトップクライアントに直接のAWSリクエスト署名ではなくOAuth互換のユーザーフローが必要なため、カスタムJWT認可を用いる。
その結果、共有検索キーを設定ファイルに置くよりも構造化された仕組みになる。各リクエストは認証済みのクライアントを通じて入り、AWSロールによって認可されたターゲットに到達する。組織はインターフェース全体を再設計せずに、どちらの側も変更できる。
ただし、この構造はコンポーネントも増やす。Identity Centerには適切なユーザーとグループが含まれていなければならない。SAMLアプリケーションは属性を正しくマッピングする必要がある。Cognitoにはユーザープール、アイデンティティプロバイダー、アプリケーションクライアント、ドメイン、コールバックアドレス、OAuth設定が必要だ。AgentCoreにはゲートウェイ、オーソライザー、ロール、ポリシー、コネクタターゲットが必要となる。
このチェーン内のどこかで設定ミスが起きると、ユーザーには一般的な検索障害のように見える可能性がある。期限切れのトークン、不正なオーディエンス、不一致のコールバック、無効なクライアント、欠けたゲートウェイ権限、利用不能なターゲットは、いずれも同じ目に見える操作を中断させうる。
これが、AWSのパターンにおける安全なClaude web searchがワンクリックで有効化できる機能ではない理由だ。その価値は明示的な制御から生まれ、明示的な制御には運用作業が伴う。企業はより明確な境界を得る代わりに、それらの境界間にあるアイデンティティ関係を所有することになる。
マネージド検索が特注の検索スタックに圧力をかける
AgentCoreの最も強い主張は、AmazonがWeb検索を発明したことではなく、マネージドMCPエンドポイントが複数の統合レイヤーを一度に排除できることにある。
従来型の実装では、多くの場合、外部検索APIから始まります。開発者は認証情報を用意し、ラッパーを構築し、ツールスキーマを定義し、レスポンスを解析し、有用な箇所を選別して、その結果をAIクライアントに公開します。さらに、クォータ、エラー、テレメトリー、ベンダー固有のレスポンス形式も管理しなければなりません。
カスタムインデックスでは、さらに多くの責任が加わります。チームはクロール、保存、ランキング、鮮度確認、コンテンツ抽出、悪意あるページへの防御を担う必要があります。サイトの制限をどのように尊重するか、古くなった文書や低品質な文書をどのように削除するかも判断しなければなりません。
AgentCoreは、その作業の多くをマネージドターゲットへ集約します。AWSがインデックスと検索サービスを運用します。GatewayはMCP経由でターゲットを提供し、サービスロールが外向きのアクセスを処理します。Claude Desktopはクライアント体験を提供し、必要に応じてツールを呼び出します。
この構成は、3つの選択肢に競争圧力をかけます。
第一に、サードパーティの検索APIは、網羅性、ランキング品質、専門コンテンツ、ポータビリティで競争する必要があります。特にAWSを利用していないチームにとっては、その簡易な導入性が引き続き魅力となり得ます。ただし、追加のプロバイダーは、新たなデータ処理関係と認証情報の境界を増やすことにもなります。
第二に、セルフホスト型の検索システムは、カスタマイズ性が維持管理の負担を正当化することを示さなければなりません。専門コーパス、非公開データソース、分野特化のランキングモデルがあれば、カスタム検索に価値が生まれます。一般的な公開Webのクエリでは、コモディティ化したインフラを再構築する意義は弱まります。
第三に、AIアプリケーションに組み込まれたネイティブ検索機能は、エンタープライズのガバナンス要件を満たす必要があります。消費者向けの便利な検索スイッチでは、組織アイデンティティ、リージョン選択、アクセス割り当て、クラウドレベルの監査可能性に関する疑問には答えられません。
Anthropicのconnector guidanceは、重要なネットワーク上の詳細を付け加えています。リモートMCP接続は、ユーザーのコンピューターから直接ではなく、Anthropicのクラウドインフラから開始されます。そのため、リモートサーバーは該当するAnthropicのネットワーク範囲からのトラフィックを受け入れる必要があります。
この詳細は、対話全体を単一のプライベートネットワーク内に維持できるという単純な主張を複雑にします。AWSの検索ターゲットとインデックスはAWSインフラ内にとどめられますが、クライアントからGatewayへの接続は依然としてAnthropicのサービスからAWSエンドポイントへとまたがります。企業は、AWS境界について説明する際に、どの区間を指しているのかを正確に定義する必要があります。
ローカルMCPサーバーは、Claude Desktopがローカルマシンから接続するため、異なる方式で動作します。ただし、ローカルプロセスでは、AWSが説明するような一元管理されたリモートGatewayは提供されません。この選択は、普遍的なセキュリティ順位ではなく、展開範囲、一元的な管理、ネットワーク露出の問題です。
AgentCoreの利点は、すでにAWSのアイデンティティ基盤と運用にコミットしている組織で最も強く発揮されます。こうした組織は、アカウント構造、ロール、監視慣行、管理上のオーナーシップを再利用できます。AWSによれば、CognitoはSAMLまたはOIDC互換プロバイダーとフェデレーションできるため、別のアイデンティティプラットフォームを持つ企業でもこのパターンを適用できます。
小規模なチームにとっては、同じアーキテクチャが過剰に感じられるかもしれません。最初の検索が成功する前に、ユーザープール、フェデレーションブリッジ、アプリケーションクライアント、Gatewayロール、ネットワークポリシーによる負担が生じます。マネージド検索サービスは検索インフラを不要にしますが、エンタープライズ向けアイデンティティアーキテクチャまで不要にするわけではありません。
これが競争上の分岐点です。AgentCoreは、最小限の導入時間よりもポリシーの一貫性を重視する組織に有利です。ポータビリティと迅速な導入が統一されたAWSコントロールプレーンより重要な場面では、外部APIやよりシンプルなコネクターにも依然として余地があります。
セキュアなClaude Web Searchにも脅威モデルは必要
JWT検証とAWS管理の検索機能は一部のリスクを減らしますが、Webコンテンツを信頼できるものにしたり、管理上の失敗要因を取り除いたりするわけではありません。
最初の不確実性は、「すべてのクエリがAWS境界内にとどまる」という表現にあります。AWSは、検索トラフィックが自社インフラ内にとどまり、サードパーティの検索キーを必要としないと説明しています。これは、検索レイヤーにおけるベンダー露出を意味のある形で減らすものです。
しかし、Claude Desktopは依然としてリクエストを開始するクライアントです。リモートMCPコネクターについて、Anthropicは自社のクラウドインフラがリモートサーバーへ接続すると説明しています。セキュリティレビュー担当者は、Claudeサービス、公開Gatewayエンドポイント、AWS Region、Web Searchターゲット、ロギングシステム、返却されるコンテンツを含め、完全なリクエスト経路をマッピングすべきです。
第二の不確実性はトークン設計です。AgentCoreはJWTを検証しますが、その保護は構成されたクレームに依存します。過度に広範なクライアント登録や不適切なグループ割り当てにより、意図した以上のアクセス権が付与される可能性があります。有効なトークンが証明するのは、受け入れられたアイデンティティとクレームのセットであり、すべてのリクエストの妥当性ではありません。
AWSのドキュメントでは、一部のJWTクレームがCloudTrailレコードに含まれる可能性があると指摘しています。subjectフィールドに個人を特定できる情報を入れないこと、また不透明な識別子を使うことが推奨されています。アイデンティティクレームに不要な個人データが含まれている場合、監査可能性がプライバシー問題になり得るため、この警告には注意を払う価値があります。
第三の不確実性は、認可の深さです。このウォークスルーでは、ユーザーまたはグループをIdentity Centerアプリケーションに割り当て、Gatewayを許可済みクライアントに制限しています。企業には、部門、データ分類、承認済みドメイン、機密性の高いクエリカテゴリに対応する追加の制御が必要になる可能性があります。
ドメイン許可リストは信頼できないソースへの露出を減らせますが、事実の正確性を保証することはできません。承認済みサイトであっても、古い、侵害された、あるいは不正確な情報を公開する可能性があります。検索結果は、無批判に受け入れる真実ではなく、モデルの推論を支える根拠として扱うべきです。
プロンプトインジェクションも懸念事項です。取得されたページには、ユーザーの目的と衝突する指示を含め、AIエージェントに影響を与えることを意図したテキストが含まれている場合があります。セマンティック抽出は無関係なページ素材の一部を除去しますが、抽出されたすべての文章が安全であることを保証するものではありません。
リスクは、検索後にClaudeが何を実行できるかに依存します。読み取り専用のリサーチアシスタントは、メッセージ送信、レコード変更、管理ツール呼び出しが可能なエージェントよりも影響範囲が狭くなります。組織は、Web Searchを単独で承認するのではなく、組み合わされたツール権限を評価すべきです。
ツール承認ダイアログは、ユーザーレベルの1つの保護策を提供します。AWSのウォークスルーでは、Claudeが提案されたクエリを提示し、拒否、1回のみ許可、現在のタスク中は許可という選択肢を示します。この可視性は、予期しない検索をユーザーが見つける助けになります。
承認は完全なポリシーシステムではありません。ユーザーはリスクを認識せずに有害なリクエストを承認する可能性があり、頻繁なプロンプトは習慣的な承認を招くことがあります。一元的な制限、限定されたスコープ、慎重なツール構成は依然として必要です。
第四の不確実性は可観測性です。チームは、どのユーザーが検索を開始したか、どのクエリがターゲットに到達したか、どの結果が返されたか、どの応答にそれらが取り込まれたかを再構築できる必要があります。また、必要以上に機密性の高い情報を収集しない保持ポリシーも必要です。
第五の不確実性は可用性です。ユーザー体験は、Identity Center、Cognito、AgentCore Gateway、Web Search、Claudeのコネクターサービス、リージョン間の接続性に依存します。いずれかのコンポーネントで障害が発生すると、ベースモデルが古い知識から回答し続ける一方で、最新情報へのアクセスが失われる可能性があります。
これは微妙なプロダクトリスクを生みます。ユーザーは、最新の検索結果に基づく回答と、検索が成功せずに生成された回答を常に区別できるとは限りません。インターフェースと運用監視では、ツール障害が古い回答へと黙って劣化するのではなく、見えるようにすべきです。
したがって、AWSのアーキテクチャはセキュリティの出発点であり、完成された脅威モデルではありません。認証情報の拡散を減らし、検索ターゲットをAWSの管理下に置きます。それでも組織は、データ境界、アクセスルール、ログ記録の慣行、障害時の挙動、敵対的な取得コンテンツへの防御を定義する必要があります。
アーキテクチャが成立するかを示す3つのシグナル
次の検証対象は、デモが1つの最新回答を返せるかではなく、運用面で採用されるかどうかです。
第一のシグナルは、企業が基本的なアプリケーション割り当てを超えて認可をどのように絞り込むかです。強力な導入では、スコープを限定したクライアント、制限されたクレーム、慎重に割り当てられたグループ、限定的なGateway権限が用いられます。弱い導入では、認証済みの従業員であれば誰もが同じ検索機能を等しく利用できるものとして扱われます。
AWSがグループクレーム、最小権限ロール、クエリレベルのポリシーに関する本番向けパターンをさらに公開すれば、マネージドな経路はより正当化しやすくなります。顧客がそれらの制御を独自に考案しなければならない場合、個別のセキュリティ作業は導入における大きな部分として残ります。
第二のシグナルは、AWSとAnthropicがエンドツーエンドのネットワーク境界をどのように明確化するかです。検索インデックス、結果処理、ターゲット呼び出しはAWS内にとどめられますが、リモートMCPリクエストはAnthropicのクラウドから始まります。エンタープライズの購入者は、エンドポイント、許可されるネットワーク範囲、リージョンでの挙動、テレメトリー、コンテンツ処理に関する正確なドキュメントを求めるでしょう。
境界に関するドキュメントが明確になれば、このパターンが不要なサードパーティ検索への露出を避けるというAWSの主張は強化されます。曖昧な表現は、すべての処理者とネットワークホップを文書化しなければならない規制対象の購入者にとって、特にその主張を弱めることになります。
第三のシグナルは、実際のワークロードにおける検索品質です。数百億件の文書にまたがるインデックスは広範に聞こえますが、ユーザーは鮮度、関連性、引用の品質、レイテンシ、一貫性で評価します。チームがドキュメント、規制、製品アップデート、急速に動くニュースを検索する際、ドメインフィルターと公開日制御は予測可能に機能しなければなりません。
このシグナルによって、マネージド検索が外部プロバイダーを置き換えるのか、それとも単に追加されるだけなのかが決まります。あるサービスが一般的なクエリには優れていても専門ソースには弱い場合、企業は複数の検索経路を維持することがよくあります。
このアーキテクチャは、使いやすさの試験にも直面します。管理者はフェデレーション、トークン、Gateway、ロール、コネクターの設定を完了しなければなりません。ユーザーは認証を行い、ツール承認を理解する必要があります。サポートチームは、各インシデントをクラウドアイデンティティの調査に変えることなく、複数のサービスにまたがる障害を診断しなければなりません。
開発者にとって当面の価値は、マネージドインデックスに支えられた標準MCPインターフェースです。エンタープライズの購入者にとっての価値は、アイデンティティと検索の制御をAWSに統合することです。ナレッジワーカーにとっての価値は、同じClaude Desktopインターフェースから最新の公開情報へより簡単にアクセスできることです。
これらの利点のいずれも、重要な回答を検証する必要性を取り除くものではありません。検索によるグラウンディングは最近の根拠へのアクセスを改善しますが、Webを信頼できるデータベースに変えるわけではありません。ユーザーは引用元を確認し、相反する主張を比較し、結果が変化するページに依存している場合を認識すべきです。
決定的な問いは、組織がアイデンティティチェーンを責任を持って運用するだけの価値を、最新の回答に見いだすかどうかです。すでにBedrockとIAM Identity Centerを利用しているチームには、Claude DesktopのWeb検索を試験するもっともな理由があります。より大きな影響を持つツールを接続する前に、限定したユーザーグループ、制限された権限、明示的なドメイン、可観測な障害、読み取り専用のワークフローから始めるべきです。
