2026年09月05日
[Aiml] Amazon Bedrock Managed Knowledge Base introduces user-managed setup for SharePoint, OneDrive, and Confluence data sources
- 公開日: 2026-09-05 (JST)
- カテゴリ: Aiml
- リンク: https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-bedrock-managed-knowledge-base-user-managed-setup-sharepoint-onedrive-confluence/
概要
Amazon Bedrock Managed Knowledge BaseがSharePoint、OneDrive、Confluenceのデータソースに対して「ユーザー管理セットアップ(3LO)」を導入しました。管理者がサービスアカウント(2LO)を作成しなくても、既存のサードパーティ資格情報でサインインして数分でデータ接続できるようになりました。
変更内容・新機能の詳細
今回の変更はOAuthの3-legged flow(3LO/Authorization Code Grant)を利用したユーザー主体の認証フローをBedrockのManaged Knowledge Baseに追加したものです。従来はSharePoint/OneDrive/Confluence側でサービスアカウントや2-legged(2LO)認証情報を発行する必要があり、特に管理者権限がないチームにとって導入のハードルが高かった点を解消します。ユーザーは各サードパーティのアカウントでサインインするだけで、Bedrock側が認可コードの交換やトークン管理(取得・リフレッシュ)を代行し、短時間でデータソースのセットアップを完了できます。なお、ユーザー管理セットアップはプロトタイピングやクイックスタート向けの迅速な接続手段であり、プログラム的・本番向けの自動化や組織全体での安定運用を想定する場合は従来のサービスアカウント(2LO)による認証を引き続き利用できます。対応データソースは SharePoint、OneDrive、Confluence で、公式のBedrockユーザーガイドにそれぞれのセットアップ手順が示されています。
影響範囲・利用シーン
- 対象ユーザー: AIアシスタントや検索基盤を短期間で試作したい開発者/プロダクトチーム、ドキュメントを素早く地に足の着いたAIで利用したいSRE/アプリチーム
- 利用シーン: SharePointの社内ドキュメント、OneDriveのファイル、ConfluenceのWikiを素早く取り込んでプロトタイプのKB(ナレッジベース)や社内向けAIアシスタントを構築する場面
- 運用効果: 管理者に依頼してサービスアカウントを作成する手間が不要になり、数分レベルでデータ接続と検証が可能。導入の初期コスト(時間・調整負荷)が低下するためPoCや短期評価が加速する
技術的な注意点
- IAM権限: AWS側でBedrockおよびManaged Knowledge Baseを操作するための適切なIAM権限が必要です(該当サービスのCreate/Manage権限等)。
- リージョン制限: BedrockやManaged Knowledge Baseの機能提供リージョンに依存します。利用前に対象リージョンで機能が有効か確認してください。
- コスト: データ取り込み、ストレージ、検索やBedrockのモデル利用に伴う料金が発生します。プロトタイプでも利用量に応じた課金が発生するため見積りを行ってください。
- セキュリティ/コンプライアンス: 会社ポリシーによりOAuthアプリの利用が制限されている場合、管理者の承認(admin consent)が必要になることがあります。機密データを扱う場合はDLPやアクセス制御、監査ログの確認を行ってください。
- 制限・注意点: ユーザー管理の3LOは個々のユーザーの権限範囲内で動作するため、組織全体のコンテンツや特定の制限付きコンテンツへのアクセスができない場合があります。また、トークン有効期間や同意取り扱いはサードパーティ(Microsoft/Atlassian)の設定に依存します。
- 運用/自動化: 本番の継続的なデータ取り込みやスケジュール実行、APIベースの完全自動化が必要な場合は従来のサービスアカウント(2LO)を用いた方式を引き続き検討してください。
参考情報
- https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-bedrock-managed-knowledge-base-user-managed-setup-sharepoint-onedrive-confluence/
- https://docs.aws.amazon.com/bedrock/latest/userguide/
- https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow
- https://developer.atlassian.com/cloud/confluence/oauth-2-3lo-apps/
[Aiml] Amazon Bedrock Managed Knowledge Base now supports ServiceNow as a native data source connector
- 公開日: 2026-09-05 (JST)
- カテゴリ: Aiml
- リンク: https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-bedrock-managed-knowledge-base-servicenow-native-data-source-connector/
概要
Amazon Bedrock Managed Knowledge BaseがServiceNowをネイティブなデータソースコネクタとしてサポートしました。ServiceNowのナレッジ記事やサービスカタログ項目(および添付ファイル)を直接クロールしてManaged Knowledge Baseに取り込めるようになります。
変更内容・新機能の詳細
新しいServiceNowコネクタは、顧客がServiceNowインスタンスの資格情報を提供するだけで、ナレッジ記事とサービスカタログ項目を自動でクロール、メタデータ抽出、インクリメンタル同期します。主な機能は以下の通りです。
- 対象コンテンツ: ナレッジ記事、記事カテゴリ、サービスカタログ項目、ファイル添付(添付ファイルは取り込み対象)
- スコーピング: sys_idの包含リストを使って特定のknowledge base、記事カテゴリ、サービスカタログのみを選択可能
- 同期方式: 初回クロール+以降はインクリメンタル同期により差分取り込みを実施
- メタデータ処理: 記事のメタデータを抽出してRAG(retrieval-augmented generation)向けに索引化
- 運用負荷低減: これまで必要だったカスタムの取り込みパイプライン構築・保守が不要になり、迅速にAIエージェントにServiceNowの組織内知識を活用させられる これにより、従業員向けITアシスタント、HRヘルプデスク、カスタマーサポート向けのエージェントを、常に最新のServiceNowコンテンツに基づいて運用しやすくなります。詳細な設定や制限(対応ファイル形式、サイズ上限、認証方式など)は公式ユーガイドを参照してください。
影響範囲・利用シーン
- 対象ユーザー: IT運用者、SRE、ヘルプデスク/サポートチーム、AI/チャットボット開発者、ナレッジマネジメント担当者
- 利用シーン: ServiceNowに蓄積されたナレッジ記事やサービスカタログをソースにした社内向けITアシスタント、HR問合せ対応ボット、サポート向けナレッジベース検索エージェントの構築
- 運用効果: カスタムETLを作らずにデータ取り込みが可能になり、導入時間と開発/保守コストを削減。インクリメンタル同期で最新情報の反映が容易になり、エージェント応答の鮮度が向上
- 導入上の利点: sys_idによるスコープ指定で不要コンテンツの取り込みを防げるため、索引サイズとノイズを抑制できる
技術的な注意点
- IAM権限: BedrockのKnowledge Baseやデータソース操作に必要なIAM権限を付与する必要があります(最小権限の構成を推奨)
- ServiceNow認証: ServiceNowインスタンスの資格情報(専用サービスアカウントでの読み取り権限を推奨)を提供する必要があります。最小権限での設定を行ってください
- リージョン制限: 新機能はリージョンごとに提供状況が異なる可能性があります。利用予定リージョンでのサポート有無は公式ドキュメント/コンソールで確認してください
- コスト: Bedrock Managed Knowledge Baseの索引作成・ストレージおよびAPI利用に伴う料金、ServiceNowからのデータ転送コストが発生する可能性があります。大量データをクロールする場合はコスト見積りが必要です
- データプライバシー: 機密情報や個人情報を含むコンテンツの取り込みはリスクがあります。取り込み前にスコーピング、フィルタリング、必要に応じたマスキング/除外を検討してください
- 重複と同期: インクリメンタル同期により再取り込みは最小化されますが、既存Knowledge Baseとの重複やバージョン管理の挙動は事前に動作確認してください
- 添付ファイル対応: 添付ファイルの取り込みをサポートしますが、対応ファイル形式やサイズ上限はドキュメントで確認してください
- 既存パイプライン移行: 既存のカスタム取り込みパイプラインから移行する場合、メタデータマッピングやID整合性(sys_id)を確認して移行計画を立ててください
参考情報
- https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-bedrock-managed-knowledge-base-servicenow-native-data-source-connector/
- https://docs.aws.amazon.com/bedrock/latest/userguide/managed-knowledge-base-datasources.html#servicenow-data-source
- https://aws.amazon.com/bedrock/knowledge-bases/
[Aiml] Amazon Bedrock Managed Knowledge Base now supports automatic sync scheduling for data source connectors
- 公開日: 2026-09-05 (JST)
- カテゴリ: Aiml
- リンク: https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-bedrock-managed-knowledge-base-automatic-sync-scheduling-data-source-connectors/
概要
Amazon Bedrock Managed Knowledge Baseが、ネイティブデータソースコネクタ向けに自動同期スケジュール機能を追加しました。日次・週次・月次のスケジュールでナレッジベースを自動更新でき、手動同期やカスタムスケジューラを構築する必要がなくなります。
変更内容・新機能の詳細
Amazon Bedrock Managed Knowledge Base(RAG向けのフルマネージドサービス)は、データ取り込み、ストレージ最適化、検索用の埋め込み/インデクシング処理をAWS側で管理します。今回の更新で、Confluence、SharePoint、Amazon S3などの「ネイティブ」データソースコネクタに対して、日次・週次・月次の自動同期スケジュールを設定できるようになりました。設定した頻度に応じてBedrockが定期的にソースを巡回し、最新のコンテンツを取り込んでナレッジベースを更新します。これにより、急速に変化するFAQやサポートドキュメントは日毎、週単位で更新されるポリシー文書は週毎、参照用の静的資料は月毎というように、ソースの更新頻度に合わせて同期ポリシーを最適化できます。自動スケジュールはあくまでネイティブコネクタが対象で、手動同期トリガーは引き続き可能です。初回同期や同期中の取り込み方法(フル更新か増分更新か)、同期エラーの監視方法や権限設定などの運用上の詳細は、ユーザーガイドの「Sync scheduling for data sources」を参照してください。
影響範囲・利用シーン
- 対象ユーザー: AIアプリケーション開発者、ナレッジ管理担当、SRE/運用チーム
- 利用シーンまたは効果: ナレッジベースを最新に保つ必要があるRAGアプリ(カスタマーサポートのFAQ、社内ポリシー参照、ドキュメント検索エージェント)において、手動や自前のスケジューラを廃止して運用負荷を削減できる
- 運用効果: 同期の自動化によりデータ鮮度の担保が容易になり、応答の正確性向上と運用コスト(スケジューラやパイプライン保守)の低減が期待できる
技術的な注意点
- IAM権限: Bedrockのナレッジベース作成・編集、および各ネイティブコネクタ(Confluence, SharePoint, S3等)へアクセスするための適切な認可/ロール(OAuthやサービスロール、S3アクセス許可など)が必要です。事前に必要権限を確認してください。
- リージョン制限: 記事時点で明示的なリージョン制限は記載されていません。導入前に利用するリージョンで機能がサポートされているか公式ドキュメントで確認してください。
- コスト: 自動同期に伴うデータ取り込み、ストレージ、埋め込み生成(推論)やAPI呼び出しに対する課金が発生する可能性があります。同期頻度を上げるとコストが増加するため、コスト影響を評価してスケジュールを決めてください。
- コネクタ制限: 機能は「ネイティブ」データソースコネクタが対象です。カスタムコネクタや非対応の外部システムは自動スケジュールの対象外となる場合があります。
- 同期挙動: 同期は設定頻度で実行されますが、初回同期や差分処理の具体的な挙動(フル再インデックスか増分更新か)はコネクタや実装に依存します。整合性や競合解決ポリシーはドキュメントを確認してください。
- 監視/障害対応: 同期の成功/失敗や詳細なログはコンソールやドキュメントで確認できるはずです。自動同期の失敗時のリトライやアラート連携(CloudWatch等)についてはユーガイドを参照し、必要に応じて通知設定を行ってください。
参考情報
- https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-bedrock-managed-knowledge-base-automatic-sync-scheduling-data-source-connectors/
- https://docs.aws.amazon.com/bedrock/latest/userguide/managed-knowledge-bases-sync-scheduling.html
- https://aws.amazon.com/bedrock/knowledge-bases/
[Govcloud Us] Amazon EC2 now supports specifying compatible instance types on AMIs
- 公開日: 2026-09-05 (JST)
- カテゴリ: Govcloud Us
- リンク: https://aws.amazon.com/about-aws/whats-new/2026/09/ec2-images-supported-instances
概要
Amazon EC2の機能拡張により、AMIの所有者がそのAMIと互換とするインスタンスタイプを明示的に指定できるようになりました。非許可のインスタンスタイプでの起動は自動でブロックされ、互換性のない組み合わせによる失敗を防げます。
変更内容・新機能の詳細
AMI所有者は、特定のインスタンスタイプを「サポートする(許可)」または「サポートしない(禁止)」として指定でき、両方の指定を組み合わせることも可能です。指定されたポリシーにより、許可されていないインスタンスタイプでの起動要求は自動的にブロックされ、起動エラーとなります。従来通り、何も指定しなければAM Iは任意のインスタンスタイプで起動可能(既存ワークフローは影響なし)です。管理画面(コンソール)やCLI/SDK/API経由で設定できる想定の操作が提供され、AMIの流通や共有時にオーナーが互換性を制御できるため、誤ったインスタンスタイプでの起動による失敗やデバッグ工数を削減できます。本機能はすべてのAWSリージョンで追加料金なしで利用可能です。
影響範囲・利用シーン
- 対象ユーザー: AMI作成者、プラットフォームチーム、SRE/運用チーム
- 利用シーン: 独自AMI(カスタムドライバや特定ハードウェア依存)の配布時に誤ったインスタンスタイプでの起動を防止する
- 運用効果: 不適合なインスタンスとAMIの組み合わせによる起動失敗を事前に抑止し、トラブルシュートとコスト増のリスクを低減する
技術的な注意点
- IAM権限: AMI属性の変更には該当API/アクション(例: ec2:ModifyImageAttribute、ec2:DescribeImages など)の権限が必要です。適切なIAMポリシーで操作権限を付与してください。
- リージョン制限: AWSはすべてのリージョンで提供すると発表しています(GovCloud含む)。ただし、導入直後は一部リージョンでロールアウト状況が異なる可能性があるため利用前に対象リージョンでの利用可否を確認してください。
- コスト: 本機能自体に追加料金は発生しませんが、互換性設定に伴う運用フロー変更やテストにかかる工数は考慮してください。
- 既存AMIへの影響: デフォルトでは既存AMIに制限は適用されないため、明示的に制限を設定するまで既存ワークフローはそのまま動作します。
- 互換性検討: CPUアーキテクチャ(x86_64/ARM)、仮想化方式(Nitro vs 非Nitro)、カーネル・ドライバ依存性など、技術的互換性は引き続き開発者側で確認してください。
- 運用上の注意: 制限を適用したAM Iを共有・公開する際は、共有先が想定するインスタンスタイプで起動できるか事前に検証し、ドキュメントで互換性情報を明記することを推奨します。
参考情報
- https://aws.amazon.com/about-aws/whats-new/2026/09/ec2-images-supported-instances
- https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html
[ECS] Amazon ECS introduces Early Success Criteria for service deployments
- 公開日: 2026-09-05 (JST)
- カテゴリ: ECS
- リンク: https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-ecs-deployments-early-success/
概要
Amazon ECSはローリングサービスデプロイに対して「Early Success Criteria」を導入しました。指定した割合のタスクが正常に起動すればデプロイを早期に成功扱いにでき、後続のデプロイやCI/CDパイプラインを早く進められます。
変更内容・新機能の詳細
Early Success Criteriaでは、サービスのデプロイ成功判定に用いる「healthy percent」(目標タスク数に対する正常に稼働しているタスクの割合)を設定できます。たとえば desired count が 100、healthy percent を 90% に設定すると、ECS は最初に 90 タスクが正常になった時点で当該デプロイを成功とマークし、残りのタスクの起動は通常のサービススケーリングの流れでデプロイ外で継続します。これにより、GPU 等の専用リソースで起動に時間がかかるワークロードや、タスクのスケールイン保護・長時間接続を維持する必要があるケースで、デプロイの停止時間や次のデプロイのブロックを短縮できます。また、デプロイ中のソースリビジョンのクリーンアップ動作を BLOCKING(クリーンアップ完了まで成功宣言を遅らせる)か DEFERRED(成功条件到達で即成功とし、ソースリビジョンのタスクは非同期でドレインする)から選択可能です。機能はローリングデプロイ戦略で動作し、AWS マネジメントコンソール、AWS CLI、SDK、および IaC ツールから既存サービス・新規サービスの両方で設定できます。
影響範囲・利用シーン
- 対象ユーザー: コンテナ運用者、SRE、プラットフォームチーム、MLOps(GPU/専用リソースを使う推論サービス)
- 利用シーン: GPU を含む特殊ハードウェアで起動遅延が発生するワークロード、長寿命コネクションを持つサービス、タスクのスケールイン保護が有効なサービスのデプロイ
- 運用効果: デプロイを早期に終了できるためCI/CDや後続デプロイのブロックを減らし、デプロイ時間の短縮とパイプラインのスループット向上が期待できる
技術的な注意点
- 適用戦略: ローリングデプロイメント(rolling deployment)でのみ利用可能です
- 設定方法: コンソール、AWS CLI、AWS SDK、および更新された IaC(例: CloudFormation/Terraform のプロバイダ更新)から設定可能です
- パラメータ: healthy percent(デプロイ成功判定に必要な正常タスク割合)、ソースクリーンアップ動作(BLOCKING/DEFERRED)を指定します
- ロールバック監視: 成功条件を満たすまでロールバック保護を継続させる設定が可能で、その後のスケールアウトは通常のサービススケーリングで継続されます
- リージョン制限: すべての AWS Commercial および AWS GovCloud (US) リージョンで利用可能とされています(リージョンごとの反映状況は確認してください)
- IAM権限: サービスの更新・作成を行う権限(ecs:UpdateService / ecs:CreateService など)および必要に応じて iam:PassRole が必要です
- コスト: この機能自体に追加課金はありませんが、デプロイの振る舞い変更により同時稼働タスクの数や稼働時間が変わる場合は通常の ECS/EC2/Fargate リソース使用料が発生します
- 互換性: CodeDeploy 型デプロイなどローリング以外のデプロイ戦略には適用されません。既存のデプロイ構成との整合性は事前に検証してください
参考情報
- https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-ecs-deployments-early-success/
- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-types.html
[Developer Tools] AWS MCP Server adds a serverless capability for AWS Lambda functions
- 公開日: 2026-09-05 (JST)
- カテゴリ: Developer Tools
- リンク: https://aws.amazon.com/about-aws/whats-new/2026/09/aws-mcp-server-serverless/
概要
AWS Model Context Protocol Server(AWS MCP Server)がLambda関数向けの「サーバーレス診断」機能を追加しました。これによりClaude CodeやKiroなどのコーディングエージェントがLambdaとその接続先リソースを効率的に解析・トラブルシュートできます。
変更内容・新機能の詳細
新しいサーバーレス機能は、Agent Toolkit for AWS経由または単独でインストールしたAWS MCP Serverから利用可能で、Lambda関数とそれに関連するAmazon API Gateway、Amazon EventBridge、Amazon S3、Amazon DynamoDB、Amazon SNS、Amazon SQS、AWS Step Functionsを横断して診断データを取得します。エージェントは取得したデータを基に、過去7日間のベースラインとエラー信号を突合して「何が変わったか」を特定し、再発するエラーの傾向抽出、デプロイ済み構成の取得、最近の変更のタイムライン提示、接続リソース間のレイテンシ分析などを行います。単一APIコールで包括的なデータを返すため、従来の複数API呼び出しをオーケストレーションするよりもトークン消費(および呼び出し数)が抑えられます。導入はAWS CLIで 'aws configure agent-toolkit' を実行するか、AWS MCP Serverを直接有効化するだけで開始できます。AWS MCP Server自体はUS East (N. Virginia) と Europe (Frankfurt) に配置されており、MCP Serverは商用AWSリージョン内のサービスへアクセス可能です。サーバーレス診断機能は追加料金なしで提供されています(ただし、診断に伴う基盤サービスの通常の料金やデータ転送等の費用は別途発生する可能性があります)。
影響範囲・利用シーン
- 対象ユーザー: サーバーレスアプリケーションの開発者、SRE、デブオプスエンジニア
- 利用シーンまたは効果: Lambda関数の原因特定(設定ミス、依存サービス障害、最近の変更との相関分析)や、接続リソース全体のレイテンシ/エラー傾向の可視化により、障害対応時間の短縮
- 運用効果: 単一コールで包括的な診断データが得られるため、複数API呼び出しを組み合わせる手間とトークン消費が削減され、問題切り分けが高速化
- コスト: サーバーレス診断自体に追加料金はないが、診断で参照するCloudWatchログやデータ転送、関連APIの呼び出しによる通常課金は発生する可能性あり
- リージョン影響: MCP ServerはUS East (N. Virginia) と Europe (Frankfurt)上で稼働するが、商用リージョン内のサービスにアクセス可能。リージョン間のデータアクセスや遅延を考慮する必要あり
技術的な注意点
- IAM権限: MCP Server/エージェントに対してLambda、API Gateway、EventBridge、S3、DynamoDB、SNS、SQS、Step Functionsなどのリード権限(例: lambda:GetFunction, lambda:GetFunctionConfiguration, apigateway:GET, events:DescribeRule, s3:GetObject 等)を最小権限で付与する必要があります
- リージョン制限: AWS MCP Server自体は us-east-1 と eu-central-1 で稼働しますが、診断対象のAWSサービスは商用リージョン内でアクセス可能です。クロスリージョンの権限やネットワーク要件に注意してください
- コスト: サーバーレス診断機能は追加料金なしとされていますが、診断で利用するCloudWatch Logs/metricsの取得、S3やDynamoDBの読み取り、データ転送に対する標準の課金は別途発生します
- セキュリティ/データ取扱: エージェントに与える権限は最小権限に留め、監査ログ(CloudTrail等)でMCP Serverのアクセスを追跡してください。機密情報や環境変数の取り扱いに関する社内ポリシーを確認すること
- 導入手順: CLIから 'aws configure agent-toolkit' を実行するか、MCP Serverを直接有効化してAgent Toolkitを設定します。オンプレやVPC内からのアクセス要件がある場合はネットワーク設定(エンドポイント、NAT、エンドポイントポリシー等)を確認してください
- 既存監視との併用: CloudWatch、X-Ray、既存のログ/トレース基盤と併用することで診断精度が向上します。MCP Serverの出力は補助的情報として活用してください