ServiceNowのトークン交換、Bedrock AgentCore Gatewayに移行
AWSは、Amazon Bedrock AgentCore Gatewayを介したServiceNowのトークン交換を文書化し、ID委任の経路からカスタムLambdaインターセプターを排除しました。11月3日に公開された手順では、作業を依頼した本人のIDを維持したまま、AIエージェントをServiceNowに接続します。この変更により、一般的なセキュリティ処理がマネージドゲートウェイ内に組み込まれます。
この仕組みは、仲介者がサインイン済みユーザーに代わって下流システムへのアクセスを要求できる、オンビハーフオブ認可（OBO）を使用します。認証情報は、MicrosoftのIDサービスであるMicrosoft Entra IDが発行します。ユーザーが何にアクセスできるかの判断は、引き続きServiceNowが担います。
エンタープライズ開発者にとって中心的な比較対象は、マネージドな委任と、カスタムトークン交換コンポーネントの維持です。AWSは現在、この統合向けに前者を文書化しています。これにより実装作業は減りますが、購入者は、拒否されたリクエスト、設定変更、日常的な運用障害が発生してもID境界が維持されることを示す証拠を依然として必要とします。
ServiceNowのトークン交換がゲートウェイ設定に
AWSのネイティブOBO手順によると、ゲートウェイは受信したユーザー認証情報を、ServiceNowが受け入れる認証情報に交換します。この処理はカスタムのインターセプターコードなしで実行されます。
文書化された構成では、エージェントとServiceNowコネクターにそれぞれ別個のEntraアプリケーション登録を使用します。ServiceNowは、名前付きトークン属性である受信IDクレームを既存ユーザーにマッピングします。ゲートウェイには、AWSがネイティブOBO用に指定するツール接続プロトコルのバージョンであるModel Context Protocol 2025-11-25が必要です。
直接的な変化は、交換が実行される場所と、その実装を保守する主体です。
これは、企業の認可システムそのものを置き換えるという話ではありません。チームには、委任を実行するためのマネージドな場所が提供されます。どの人、アプリケーション、操作をワークフローに含めるかは、引き続き組織が決定します。
この発表を評価する際、この区別は重要です。トークン交換コンポーネントはアーキテクチャ図では小さく見えても、大きな責任を負っている場合があります。その動作は、個人の依頼とエンタープライズシステムの権限判断の間に位置します。
実装前に、責任の所在を検討してください。委任リクエストが失敗した場合、その失敗がユーザー、アプリケーション、宛先のいずれに関するものかを誰かが判断しなければなりません。カスタムコンポーネントをなくすことで、その調査の境界も変わります。
独自の交換サービスを保守しているチームでは、問うべきことが具体的になります。そのコンポーネントは、標準的な委任以外に何をしているのか。目的が下流の認証情報取得だけであれば、マネージドな代替手段を評価する価値があります。ビジネスルールも適用しているなら、廃止前にそのルールの明確な移行先が必要です。
これは、よくある移行ミスを防ぎます。主要機能がプラットフォームに移ったからと統合コンポーネントを削除すると、その周辺に蓄積された振る舞いまで削除してしまうおそれがあります。責任ある評価では、認証処理とアプリケーション判断を分けます。
同じ考え方はプロジェクト見積もりにも当てはまります。チームは消える作業を数えたうえで、移動する作業を特定する必要があります。設定の所有、権限レビュー、サポート手順、受け入れ証拠には、引き続き担当者が必要です。
したがって、ServiceNowのトークン交換は、インフラが製品設定へと変わる有用な例を示しています。運用上の利点は、組織がその設定を、置き換えられるコードと同じくらい慎重にレビューできるかどうかにかかっています。
このニュースを評価する読者にとって、最も確かな初期結論は実務的なものです。AWSは、この交換ロジックを自ら保守する代替手段を文書化しました。この手順は、測定済みの本番成果を示す証拠ではなく、評価の出発点を提供します。
IDチームはより可視化された製品判断を引き継ぐ
最も直接的な影響を受けるのは、プラットフォームエンジニア、ID管理者、ServiceNowの運用担当者です。各グループは、同じユーザージャーニーの異なる部分を管理します。マネージドな交換により、それらの連携はより可視化されます。
エージェントチームは、有用な回答を受け取ることを成功と定義するかもしれません。IDチームは、正しく委任されたアクセスを成功と定義するかもしれません。ServiceNowの運用担当者は、未認可のレコードが引き続きアクセス不能であることの証拠を求めるかもしれません。
これらの定義は、導入前に一致させるべきです。そうしなければ、同じデモがあるグループを満足させる一方、別のグループにとって最も重要な疑問を未解決のままにする可能性があります。説得力のある回答だけでは、その下にある権限境界について限定的な証拠しか得られません。
重心は、チーム横断で認可契約を証明することへ移ります。
有用な契約は、平易な言葉から始まります。アシスタントは、依頼者本人に許可されたアクセスを使い、承認済みのタスクを実行すべきです。この記述により、特定のモデルに受け入れ基準を結び付けずに、エンジニアとレビュアーが共通の成果を共有できます。
たとえば、サポート担当者が、自分の業務に関連するインシデントを要約するようアシスタントに依頼する場面を想定します。これは報告された顧客導入ではなく、例示的なシナリオです。その価値は、有用な検索と適切な制限の両方に依存します。
成功した応答では、担当者が閲覧を許可されたインシデントを説明すべきです。その境界を超える要求には、明確な制限を示すべきです。どちらの結果も、製品における正しさの定義に含まれます。
この枠組みは購買判断も改善します。購入者は、代表的なアカウントを用いて、認可済みと未認可の振る舞いをベンダーに実演するよう求められます。観測された結果を、書面化されたアクセス方針と比較できます。
これに対し、管理者アカウントだけで実施されたデモを受け入れる方法もあります。そのようなデモは接続性を示すかもしれませんが、一般従業員の通常利用についてはほとんど明らかにしません。調達チームは、こうした証拠の形態を区別すべきです。
文書化にも影響があります。アプリケーションID、宛先権限、ユーザーマッピングをどのチームが所有するかを、誰かが記録する必要があります。この記録がなければ、通常の人事異動が統合上の謎になりかねません。
こうした判断を保守するチームは、検索可能なナレッジベースを活用して、設定の説明やトラブルシューティングの文脈を保持できます。この文書化は、認可境界の一部になることなく、統合の運用を支えます。
開発者にとって、組織上の機会は重複の削減です。標準的な交換パターンにより、アプリケーションチームは共通の出発点を得られます。レビュー作業を、自社のアシスタントに必要な特定の操作や情報に集中させることができます。
セキュリティチームにとっては、より明確なインベントリを得られる機会です。個別アプリケーションの実装内にある委任の振る舞いを発見する代わりに、レビュアーはゲートウェイ設定とその所有者を確認できます。この利点は、設定が見つけやすく、最新に保たれていることに依存します。
結果として生じる圧力は、推測上のものではなく即時的です。この統合を評価するチームは、誰がアクセスを承認でき、誰が拒否を説明できるのかについて合意しなければなりません。マネージドゲートウェイはこうした判断を見つけやすくしますが、最終的に判断するのは人です。
交換は認証情報の宛先を変える
アクセストークンは、特定のリソースへの呼び出しを認可する認証情報です。そのオーディエンスは、意図された受信者を特定します。リクエストがエージェントを通過して別のアプリケーションに到達する場合、この宛先は重要です。
MicrosoftのOBO認可フローでは、仲介者が適切な受信ユーザートークンを提示する必要があります。IDプラットフォームはその後、下流向けトークンを発行します。このフローでは、ユーザーに代わって実行される作業に対して要求される権限である、委任されたスコープを使用します。
Microsoftは、これをアプリケーション専用アクセスとも区別しています。OBOには、人を表すIDであるユーザープリンシパルが必要です。アプリケーションのみに発行されたトークンでは、同じ委任関係は成立しません。
委任は、依頼した本人と下流の権限判断とのつながりを維持すべきです。
この仕組みを検討する読者にとって、有用な例えは、来訪者がセキュリティで保護された部署間を移動する場面です。受付に入る許可があっても、すべてのオフィスに入る許可が自動的に与えられるわけではありません。それぞれの宛先には、その宛先に適した認可判断が必要です。
この例えには限界がありますが、単に認証情報を先へ渡すだけでは不十分な理由を明確にします。仲介者は、承認済みの委任関係に参加しなければなりません。その後、宛先は自らの利用を目的とした認証情報を受け取ります。
AWSのゲートウェイ文書では、より広範なツール統合機能と並んで認証を位置付けています。Gatewayは、受信および送信認証を管理しながら、既存サービスを共通インターフェースで公開できます。
これは評価に値するアーキテクチャ上の利点を生みます。チームは、モデルの推論を、ツールに認証情報を供給する仕組みから分離できます。言語モデルは操作を要求し、インフラが認証経路を処理できます。
この分離はアプリケーション設計に影響を与えるべきです。プロンプトではツールが有用な場面を記述できますが、権限判断には信頼できる強制ポイントが必要です。製品チームは、誰にアクセスを与えるかを変えずに文言を変更できるべきです。
マネージドな交換は、カスタムコードとの比較も変えます。ローカルで保守するコンポーネントは、チームに実装詳細の直接的な制御を与えます。マネージドサービスは標準的な設定画面を提供し、実装上の責任の一部をプロバイダーに移します。
どちらを選んでも、障害時の振る舞いを理解する必要はなくなりません。重要な比較には、診断、レビュー可能性、ライフサイクル管理、サポートが含まれます。ソースファイル数だけを数えても、運用上の判断の多くを見落とします。
したがって、AgentCoreのOBO動作を評価する開発者は、リクエストを責任の連鎖として追跡すべきです。どのコンポーネントが受信する呼び出し元を検証するのか。どのコンポーネントが下流アクセスを要求するのか。どのシステムが最終的なリソース判断を下すのか。
プラットフォームが交換を自動実行する場合でも、これらの問いは有用です。自動化は手動の実装手順を減らします。しかし、正確なアーキテクチャ記述の必要性をなくすものではありません。
この仕組みは、モデル選定で解決できることとできないことも明確にします。より優れたモデルは、より適切なツールを選んだり、結果をより明確に説明したりできるかもしれません。認可には、モデルの回答品質にかかわらず、独自の受け入れ証拠が必要です。
エンタープライズ購入者にとって、これが最も有用な技術的要点です。推論品質と委任アクセスを別個の能力として評価してください。権限制御された職場で信頼できる支援を提供するには、製品には両方が必要です。
Azureは同じ境界を比較するうえで有用な例を示す
Microsoftのエージェント分離に関するガイダンスでは、独立したエージェントIDと並んで委任認可について説明しています。また、コンテキスト転送を強制するためのツールゲートウェイとして、Azure API Managementが候補になり得ることも示しています。
これはAWSのアプローチを比較するうえで有益な材料となる。どちらの議論でも、アイデンティティの強制はモデルの裁量的な推論の外部に置かれている。Microsoftのガイダンスは、生成テキストに左右されずにルールを強制する決定論的な制御を明示的に求めている。
競合比較で有用な問いは、各アーキテクチャがアクセスコンテキストをどれだけ明確に保持・強制できるかである。
これは、対応コネクタ数を比較するよりも多くを示す。コネクタはアプリケーションへの経路を確立する。一方で、エンタープライズ導入には、その経路を通じてどの権限が伝達されるのかを説明可能な形で示すことも必要になる。
プラットフォームを比較する購買担当者は、代表的なワークフローから始めるべきだ。そのワークフローには、許可されたアクセス、制限されたアクセス、そして復旧可能な失敗を含める必要がある。各プラットフォームは、その同一の期待結果に照らして評価できる。
このアプローチにより、比較が製品機能の主張を並べるだけのものになるのを避けられる。組織にとって重要な挙動をベンダーに示すよう求めることになる。また、管理対象プラットフォームの外部に残る統合作業も明らかになる。
比較では、アーキテクチャの違いを尊重すべきである。すでに確立されたゲートウェイを運用している企業は、既存の制御との一貫性を重視するかもしれない。別の企業は、アプリケーションチームが維持するインフラの量を減らすことを優先する場合もある。
これらはいずれも正当な優先順位の違いである。ただし、いずれかのプラットフォームが普遍的により優れた認可を提供することを示すものではない。判断は、選択した構成が組織の実際のアクセス要件を満たすかどうかにかかっている。
AgentCoreとカスタム認証を検討するチームにも、同じ評価が当てはまる。カスタムシステムは、管理対象の代替手段と同じアクセス拒否シナリオに直面させるべきだ。既存コードへの慣れが、証拠の代わりになってはならない。
移行レビューでは例外的な挙動も調査すべきである。たとえば、現行コンポーネントが承認確認を追加していたり、内部アイデンティティを変換していたりする場合がある。その挙動が引き続き必要であれば、置き換え後のアーキテクチャでも明示的に保持する必要がある。
管理対象インフラは、ここで組織に存在する文書化されていない前提を明らかにできる。標準構成では、統合のどの部分が標準的で、どの部分が固有なのかをチームが説明する必要がある。その明確化は、移行判断の前であっても価値を持ちうる。
したがって、競争圧力はAWSとMicrosoftの範囲を超える。統合ベンダーや社内プラットフォームチームは、認可境界を運用上の言葉で説明する必要性がますます高まっている。「エンタープライズ対応」という広範な主張は、アクセスインシデントの最中にはほとんど役に立たない。
また読者は、この統合をモデルプロバイダー間の競争として捉えるべきではない。アイデンティティ経路は、エンタープライズアプリケーションを呼び出すために使用される権限に関わる。その設計は、リクエストを生成するモデルとは独立して精査に値する。
より広い意味は、評価基準にある。同じ権限契約を用いてプラットフォームを比較することだ。有用な応答、適切な拒否、理解可能な失敗は、コネクタのデモだけよりも、購買担当者に確かな判断基盤を与える。
成功したリクエストにも重要な未解決事項が残る
正常に動作する統合は、許可された経路が成功できることを示す。しかし、関連するすべてのユーザー、権限変更、ポリシー上の課題にわたり、システムがどのように動作するかを示すものではない。これらの問いには別途評価が必要である。
Microsoftは、下流のポリシーが追加のユーザー認証を要求する場合のインタラクション要件を文書化している。これはあらゆる仲介レイヤーに対して、ユーザー本人の対応が必要であることをアプリケーションがどう伝えるかというプロダクト設計上の問いを生む。
作業を継続できない場合、アシスタントはユーザーに有用な説明を提供すべきだ。権限上の制約と、情報の不足や一時的なサービス障害を区別する必要がある。そうでなければ、ユーザーは曖昧な失敗に直面し、サポートチームが調査を引き継ぐことになる。
本番運用への信頼は、許可されたリクエストを完了することだけでなく、失敗を説明することからも生まれる。
最初の評価領域は、拒否時の挙動である。チームは、代表的なユーザーの承認済みアクセス範囲外にある操作を意図的に試すべきだ。期待される結果は、テスト開始前に書き出しておく必要がある。
これは、正しい制限と統合の不具合を区別するのに役立つ。期待結果がなければ、開発者はすべての拒否を修正すべき問題として扱うかもしれない。その結果、デモを動かすためだけにアクセスを広げる圧力が生まれる。
次の領域は変更管理である。組織は、関連する権限、アイデンティティマッピング、アプリケーション構成が変更された際に何が起きるかを検証すべきだ。目的は、理解可能な応答と、調査の明確な担当者を確保することである。
認証情報の取り扱いには、独自の運用レビューが必要である。管理対象の交換はカスタム実装を減らせる一方で、構成入力を維持する責任は管理者に残る。チームは、必要な変更がデプロイ済み統合にどのように反映されるかを把握しておくべきだ。
運用上の証拠を通じてシステム挙動を理解する能力である可観測性は、このレビュー全体で重要となる。サポート担当者は、機密性の高い認証情報を公開せずに失敗を特定できる十分なコンテキストを必要とする。ログを増やせば自動的にログの質が上がるわけではない。
有用な調査記録は、リクエストをその結果および関連する構成に結び付けるべきだ。そうすればレビュアーは、その証拠が提示された権限契約を裏付けているかを確認できる。記録の正確な設計は、組織のデータ取り扱い要件に従う必要がある。
公開するアクションの範囲も重要である。レコードの読み取りと変更では、ユーザーに生じる結果が異なる。チームは、接続性を包括的な承認として扱うのではなく、各操作が何を実行できるかに応じて評価すべきだ。
たとえば、例示的なインシデント要約ワークフローは、取得のみから始められる。インシデント更新を追加する場合は、確認、説明責任、復旧に関する別のプロダクト判断が必要になる。既存の接続だけでは、これらの問いは解決しない。
公開されている資料が証明できる範囲にも限界がある。引用したウォークスルーは、構成と意図された挙動を説明している。信頼性、保守負荷、ビジネス成果について、独立して検証された本番環境の比較を提供するものではない。
この隔たりは、導入判断に使う表現に反映すべきである。チームは、管理対象アプローチがテストに値すると合理的に結論付けられる。しかし、運用負荷が軽減されるというより強い主張には、チーム自身のデプロイから得た証拠が必要となる。
したがって、ServiceNowのトークン交換は、明確な成功・失敗基準を持つ限定的なパイロットを通じて評価するのが最適である。これにより組織は、成功したデモを包括的な保証とみなすことなく、文書化された機能を評価できる。
デプロイの証拠、ポリシー処理、再利用を注視する
次に有用なシグナルは、自律的な作業に関する別の広範な約束ではなく、運用上の証拠に関するものだ。今後数か月、購買担当者はデプロイ結果、ポリシーからの復旧、追加ワークフローでの再利用を注視すべきである。いずれも、管理対象の委任という主張の異なる部分を検証する。
最も強力な証拠は、カスタム交換コードの削減が、より明確に運用できるシステムにもつながることを示すものになる。
まず、代表的な従業員権限を使ったデプロイ結果の文書化に注目すべきだ。有用な事例では、どのアクションが許可され、どれが拒否されたか、そしてチームがその違いをどのように検証したかが説明される。顧客名だけでは、得られる情報は少ない。
一貫したアクセス結果の証拠は、管理対象の委任を支持する材料となる。統合を安定させるためにチームが権限を広げたという報告は、それを弱める。重要な詳細は、デプロイ後の挙動が元の権限契約とどう比較されるかである。
保守に関する証拠も役立つ。移行を評価するチームは、初期設定後に何が起こるのかを理解する必要がある。構成更新やインシデント調査に関する明確な説明は、セットアップ時間だけよりも強い運用上の根拠を支える。
次に、実装がポリシーによる中断と復旧をどのように処理するかに注目すべきである。本番環境のアシスタントには、ユーザーが再認証または承認取得を必要とする場合に、適切な経路が必要だ。説明のないエラーを繰り返し返すだけでは、重要なプロダクト作業が未解決のまま残る。
明確な復旧挙動は、管理対象の交換が体験全体を簡素化するという主張を強める。各アプリケーションでその周囲に大規模なカスタム処理が必要であれば、メリットはより限定的なものにとどまる。それでも有用ではあるが、実装見積もりは変わる。
このシグナルは、サポートの責任範囲にも関わる。アプリケーションチームは、問題を自ら解決できる場合と、アイデンティティ管理者の介入が必要な場合を知る必要がある。文書化された引き継ぎは、ユーザーがチーム間を行き来する事態を避けるのに役立つ。
第三に、組織がこのパターンを追加のエンタープライズアクションに再利用するかを注視すべきである。統合が拡大しても同じ権限原則が明確に保たれるなら、再利用には意味がある。その明確さを維持せずに接続先を増やしても、証拠としては弱い。
再利用可能なパターンでは、各接続先の権限が理解可能であるべきだ。レビュアーは、ユーザー、承認済み操作、責任を持つシステムを引き続き識別できなければならない。コネクタ数の増加だけでは、その結果を示せない。
エンタープライズ開発者にとって、これらのシグナルは発表への実践的な対応を示唆する。カスタムコードが現在一般的な委任を担っている箇所で、管理対象の経路を評価する。業務固有の制御は明示的に維持し、既存実装と結果を比較する。
購買担当者は、通常の従業員アカウントと現実的な制限を用いた証拠を求めるべきだ。根本のリクエストがなぜアクセスを得たのかを誰も説明できないなら、印象的な回答の価値は下がる。評価では、理解可能な認可挙動を重視すべきである。
次回のレビューを計画するチームは、具体的なワークフローから始め、その許可されたアクションを書き出すべきだ。ServiceNowに到達すべきユーザー権限を特定し、許可されたリクエストと意図的に制限したリクエストをテストする。アプリケーションが各結果をどのように説明するか、また失敗時の担当者が誰かを記録する。その結果を用いて、AgentCoreを介したServiceNowのトークン交換が、意図したアクセス境界を維持しながら保守を削減できるか評価する。ワークフローを拡大する前に、アイデンティティ管理者およびServiceNowの担当者と構成をレビューする。最も有用な次のステップは、チームが検証・再現でき、既存の交換コンポーネントを置き換えるかどうかの判断に利用できる証拠を生む、焦点を絞った評価である。
