本ブログは 2026 年 3 月 17 日に公開された AWS Blog、” Essential security controls to prevent unauthorized account removal in AWS Organizations ” を翻訳したものです。 AWS メンバーアカウントが侵害された場合、攻撃者はアカウントを組織から離脱させ、すべてのガバナンスコントロールを無効化する可能性があります。本記事では、サービスコントロールポリシー (SCP)、安全なアカウント移行、一元化されたルートアクセス管理などの多層的なセキュリティコントロールを使用して、AWS 環境をアカウント侵害から保護する方法を解説します。 AWS はクラウドを実行するインフラストラクチャのセキュリティを担い、お客様はクラウド内のワークロードとデータのセキュリティを担います。そのために、AWS Organizations には不正なアカウント離脱を防止し、アカウント全体のガバナンスを維持するセキュリティコントロールが含まれています。 本記事では、4 つのコントロールについて説明します。サービスコントロールポリシー (SCP) による不正なアカウント離脱の防止、正当な移行のためのブレークグラス手順の確立、組織間でのアカウントの直接移行、およびメンバーアカウントのルートアクセスの無効化です。 前提条件 本記事では、 AWS Organizations と マルチアカウント戦略の概念 に精通している必要があります。以下の権限を持つ AWS Organizations 管理アカウントへのアクセスが必要です。 サービスコントロールポリシーの作成とアタッチ — organizations:CreatePolicy 、 organizations:AttachPolicy 組織単位の管理 — organizations:CreateOrganizationalUnit 、 organizations:MoveAccount 一元化されたルートアクセス管理の有効化 — iam:EnableOrganizationsRootCredentialsManagement セキュリティと柔軟性を両立する組織単位 (OU) 構造の設計 マネージドサービスプロバイダー、リセラー、アカウントの入れ替わりが多い組織など、メンバーアカウントが定期的に組織を離脱することを許可する必要があるビジネスモデルの場合、最初からこのワークフローを考慮して OU 構造を設計する必要があります。 アカウントのライフサイクルステージ (オンボーディング、アクティブ、オフボーディング) ごとに専用の OU を作成し、長期的なガバナンス下に置くべきアカウントを含む OU にのみ DenyLeaveOrganization SCP を適用することを検討してください。このアプローチにより、コアインフラストラクチャを保護しつつ、短期間のアカウントの移行を簡素化できます。 セキュリティコントロールと運用の柔軟性のバランスを取る 階層的な OU 構造を作成 してください。本番環境と開発環境の OU に DenyLeaveOrganization SCP を適用して重要なワークロードを保護し、制御されたアカウント移行のためにこの制限のない別の移行用 OU を維持します。 推奨される OU アーキテクチャ 本番 OU: DenyLeaveOrganization SCP を適用して、本番ワークロードを実行するアカウントが組織を離脱することを防止します 開発 OU: 同じ SCP を適用して、開発およびテスト環境のガバナンスを維持します 移行 OU: DenyLeaveOrganization SCP を適用せず、組織を離脱する準備をしているアカウントの制御されたステージングエリアとして機能させます 正当なビジネス上の理由でアカウントが組織を離脱する必要がある場合、管理アカウントはそのアカウントを移行 OU に移動でき、メンバーアカウントの離脱操作が可能になります。これにより、明確な承認ワークフローが作成され、移行プロセス全体の可視性が維持されます。 管理アカウントは組織からメンバーアカウントを離脱させることができるため、メンバーアカウントが自ら離脱する正当な必要性がない場合は、離脱アカウント用の移行 OU アプローチを実装する必要はありません。 OU 構造の整理と管理に関する詳細なガイダンスについては、 AWS Organizations での組織単位の管理に関する AWS ベストプラクティス を参照してください。 組織離脱アクションを拒否するサービスコントロールポリシーの実装 メンバーアカウントが組織を離脱することを防止するには、メンバーアカウントに対して organizations:LeaveOrganization アクションを拒否する SCP を実装します。この予防的コントロールにより、アカウントがガバナンスフレームワーク内に留まり、セキュリティコントロールと組織ポリシーが維持されます。 AWS マネジメントコンソールを使用した SCP の作成 管理アカウントで AWS Organizations コンソールにサインインします。 ナビゲーションペインで ポリシー を選択します。 サービスコントロールポリシーを有効化 します。 ポリシーの作成 を選択します。 ポリシー名を入力します (例: “DenyLeaveOrganization” )。 ポリシーエディタに以下の JSON を入力します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "organizations:LeaveOrganization", "Resource": "*" } ] } ポリシーの作成 をクリックします。 AWS CLI を使用した SCP の作成 以下のコマンドを実行してポリシーを作成します。 aws organizations create-policy \ --name DenyLeaveOrganization \ --type SERVICE_CONTROL_POLICY \ --description "Prevents member accounts from leaving the organization" \ --content '{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"organizations:LeaveOrganization","Resource":"*"}]}' 次のステップで使用するため、出力からポリシー ID を記録してください。 ポリシーを作成したら、 移行 OU を制限なしのまま維持しつつ、 本番 OU と 開発 OU に DenyLeaveOrganization SCP を適用します。 AWS マネジメントコンソールを使用した OU への SCP のアタッチ AWS Organizations に移動します。 対象の OU ( 本番 または 開発 ) を選択します。 ポリシー タブを選択します。 アタッチ を選択し、「DenyLeaveOrganization」ポリシーを選択します。 ポリシーが必要な各 OU に対して繰り返します。 AWS CLI を使用した OU への SCP のアタッチ 作成ステップで取得したポリシー ID を使用して、対象の OU にポリシーをアタッチします。 aws organizations attach-policy --policy-id p-xxxxxxxx --target-id r-xxxx ポリシーのアタッチを確認します。 aws organizations list-targets-for-policy --policy-id p-xxxxxxxx ポリシーが必要な各 OU に対して繰り返します。 このコントロールは、コンソール、CLI、SDK を通じた API レベルでの離脱の試みをブロックします。管理アカウントの保護に関するベストプラクティスについては、 ドキュメント を参照してください。 SCP は管理アカウントには適用されず、組織内のメンバーアカウントにのみ影響することに注意してください。そのため、管理アカウントを MFA、アクセス制限、一時的な認証情報のみの使用、包括的なモニタリングなど、可能な限り強力なセキュリティコントロールで保護することが不可欠です。 ブレークグラス手順の文書化 アカウントの移行、合併、買収、事業売却の際に特定のアカウントが組織を離脱することを許可する必要がある場合は、文書化された承認ワークフローと技術的メカニズムを備えた正式なプロセスを確立してください。 シナリオに適したブレークグラスメカニズムを選択してください。アカウントが組織を離脱する必要がある場合、標準的な変更管理プロセスを通じて、現在の OU から移行 OU に移動します。移行 OU に移動すると、DenyLeaveOrganization SCP の制限なしに離脱操作を実行できます。このアプローチにより、組織ルート全体から SCP を一時的に削除することなく、すべてのアクティブなアカウントのセキュリティコントロールが維持されます。 メンバーアカウント離脱の文書化された例外プロセスの確立 安全な招待ベースの移行プロセスの外で、メンバーアカウントが独自に組織を離脱する場合は、正式な承認を必要とする例外として扱う必要があります。各例外リクエストには、標準的な組織間移行プロセスを使用できない理由を説明する明確なビジネス上の正当性と、セキュリティおよびガバナンスポリシー要件との整合性を検証するためのセキュリティおよび IT 管理チームによるレビューと承認が含まれている必要があります。 この例外をセキュリティベースラインに文書化し、移行 OU は標準的な招待ベースの移行を使用できない承認済みの移行中の一時的なアカウントステージングのためにのみ存在することを明示的に記載してください。この文書化により、説明責任が確立され、コンプライアンスレビューのための監査証跡が作成され、セキュリティコントロールの例外が意図的で、正当化され、期限付きであることが保証されます。 合併・買収時のアカウントの安全な移行 合併、買収、または組織統合の際、AWS Organizations は組織間の安全な直接アカウント移行をサポートし、アカウントがスタンドアロンになることを防止します。移行先の組織の管理アカウントが移行するアカウントに招待を送信します。承認されると、アカウントは組織のガバナンスの外で運用されることなく、移行元から移行先の組織にシームレスに移行します。サービスコントロールポリシー (SCP)、ログ記録、モニタリングは移行中も継続的に適用され、セキュリティ体制が維持され、 AWS CloudTrail を通じた完全な監査証跡が作成されます。 この招待ベースのアプローチは、アカウントが独立して運用される際に発生するセキュリティギャップを防止しながら、ほとんどの正当な移行ユースケースに対応します。管理アカウントがメンバーアカウントを手動で離脱させる必要はなく、招待プロセスが移行を自動的に処理します。移行後は、適切なポリシーが適用されていることを確認し、正しい組織 ID で IAM ポリシーを更新し、請求設定、税金設定、リザーブドインスタンスの移行を確認してください。詳細なガイダンスについては、 AWS Organizations ユーザーガイドのアカウント移行 を参照してください。 メンバーアカウントのルートアクセスの脆弱性の排除 メンバーアカウントのルートユーザー認証情報は、AWS 環境における最高レベルの特権アクセスであり、AWS Identity and Access Management (IAM) ポリシーやサービスコントロールポリシーをバイパスできます。2025 年の AWS 一元化されたルートアクセス管理の開始以降、新しく作成されたメンバーアカウントにはデフォルトでルートユーザー認証情報がなくなりました。これは、組織内のすべての新しいアカウントの標準的な動作です。新しく作成されたメンバーアカウントはルートユーザー認証情報なしで自動的にプロビジョニングされるため、多要素認証の設定などのプロビジョニング後のセキュリティ対策が不要になります。 このデフォルトが有効になる前に作成された既存のアカウントについては、長期間有効なルートユーザー認証情報の削除は迅速かつ簡単です。AWS 一元化されたルートアクセス管理を使用すると、パスワード、アクセスキー、署名証明書、MFA デバイスなどのルートユーザー認証情報を、管理アカウントから組織全体にわたって直接削除できます。各メンバーアカウントに個別にサインインする必要はありません。 この一元化されたアプローチにより、メンバーアカウント全体で一貫したセキュリティが維持されます。また、アカウント作成とセキュリティ設定の間の脆弱性ギャップを排除することで、運用オーバーヘッドが削減されます。一元化されたルートアクセス管理の実装に関する詳細なガイダンスについては、 メンバーアカウントのルートアクセスの一元管理 を参照してください。 AWS マネジメントコンソールを使用したルートユーザー認証情報の削除 管理アカウントを使用して IAM コンソールを開きます。 ナビゲーションペインの アクセス管理 で、 ルートアクセス管理 を選択します。 一元化されたルートアクセス管理がまだ有効になっていない場合、ページの上部にバナーまたはプロンプトが表示されます。 有効化 を選択してアクティブにします。プロンプトが表示されない場合、この機能は組織で既に有効になっています。有効化すると、ページにメンバーアカウントを含む組織構造が表示されます。 アカウントを選択し、右側のルートユーザー認証情報パネルを確認します。アクティブなルートユーザー認証情報がまだあるアカウントについては、 ルートユーザー認証情報の削除 を選択して削除します。 図 1: ルートアクセス管理 AWS CLI を使用した一元化されたルートアクセス管理の有効化 以下のコマンドを実行して、一元化されたルートアクセス管理を有効化します (既に有効な場合でも安全に実行でき、現在の機能の状態が返されます)。 aws iam enable-organizations-root-credentials-management 有効化された機能を確認して設定を検証します。 aws iam list-organizations-features 出力を確認して、有効化が成功したことを確認します。機能が有効化されている場合、以下のように表示されます。 { "OrganizationId": "o-xxxxxxxxxxxx", "EnabledFeatures": [ "RootSessions", "RootCredentialsManagement" ] } 機能がまだ有効化されていない場合、 aws iam list-organizations-features は以下のように空の EnabledFeatures 配列を返します。 { "OrganizationId": "o-xxxxxxxxxxxx", "EnabledFeatures": [] } まとめ AWS Organizations をアカウント侵害から保護するには、保護と運用の柔軟性のバランスを取る多層的なセキュリティコントロールが必要です。DenyLeaveOrganization サービスコントロールポリシーは、不正なアカウント離脱をブロックし、継続的なガバナンスの監視を維持します。組織間の招待ベースのアカウント移行機能は、セキュリティギャップを作ることなく、合併、買収、統合などの正当なビジネスニーズをサポートします。AWS 一元化されたルートアクセス管理によるルートアクセスの排除は、セキュリティコントロールをバイパスできる最高特権の経路を削除します。 これらのコントロールにより、侵害された認証情報を使ったアカウントの組織からの離脱を防止し、移行中もサービスコントロールポリシーとログ記録をアクティブに保ち、セキュリティインシデントをガバナンスフレームワーク内に封じ込めることで、問題の検出、対応、修復をより迅速に行えるようになります。 まず OU 構造を設計し、ブレークグラス手順を文書化してから、DenyLeaveOrganization SCP を適用し、AWS 一元化されたルートアクセス管理を有効化してください。OU 構造を定期的にレビューし、例外リクエストを監査し、AWS CloudTrail を通じて不正アクセスの試みを監視してください。アカウントガバナンスを重要なセキュリティコントロールとして扱い、AWS 環境を安全でコンプライアンスに準拠し、ビジネス目標に沿った状態に保ちましょう。サービスコントロールポリシーの例とテンプレートについては、 AWS SCP Examples GitHub リポジトリ をご覧ください。 著者について Nivedita Tripathi Nivedita Tripathi は AWS Organizations のシニアプロダクトマネージャーです。セキュリティとガバナンスのベストプラクティスを活用し、組織が設定したコンプライアンス境界内で、お客様が複数のアカウントにわたるクラウドインフラストラクチャを構築・拡張できるよう支援することに注力しています。テクノロジーへの情熱に加え、音楽、世界旅行、家族との時間を楽しんでいます。 Ryan Bates Ryan は AWS のテクニカルアカウントマネージャーです。学ぶことと、学んだことで人々を助けることが大好きです。IT 業界で 20 年以上の経験があり、エンドユーザーサポート、インフラストラクチャサポート、IT 部門の構築を担当してきました。お客様のことに没頭していない時は、家族との時間、ワインテイスティング、ディズニーランドへの訪問を楽しんでいます。 Samir Behara Samir Behara は AWS プロフェッショナルサービスのシニアクラウドインフラストラクチャアーキテクトです。クラウド導入戦略を通じて、お客様の IT モダナイゼーションの加速を支援することに情熱を注いでいます。豊富なソフトウェアエンジニアリングのバックグラウンドを持ち、パフォーマンス、運用効率、イノベーションのスピード向上を推進するために、アプリケーションアーキテクチャと開発プロセスを深く掘り下げることを好みます。 翻訳は Security Solutions Architect の 松崎 博昭 が担当しました。

NTTドコモビジネス イノベーションセンター テクノロジー部門 MetemcyberPJでの経験を通じ、私は「自分でやり切ること」と「チームとして成果を出すこと」のバランスの重要性を学びました。若手社員でも幅広い業務に挑戦できる環境の中で、責任感を持ちながらも周囲と協力することで、個人の成長とチーム成果の両立が可能であると実感しています。この記事では、その経験から得た学びと実践のポイントを紹介します。 はじめに 若手でも幅広く挑戦できる環境 スクラムという前提 私が経験した「抱え込み」 タスクの優先順位のつけ方 最後に はじめに こんにちは。イノベーションセンター テクノロジー部門 MetemcyberPJの2年目社員、千坂知也です。 私は1年目の8月からMetemcyberPJに参画し、OSSコントリビューターとして開発業務に携わってきました。 はじめのころは主に開発コードを書くことに注力していましたが、2年目になってからは、他メンバーのコードレビューやマージ、デプロイ作業など、開発プロセス全体に関わる業務も任されるようになりました。また開発以外の案件支援業務にも携わる機会をいただきました。 こうした経験を通じて、単なる技術力のみならずチームで成果を出すための働き方や考え方についても多くの学びがありました。 そして、自分の成長を大きく感じた一方で、「自分でやり切ること」と「チームとして成果を出すこと」のバランスの難しさも同時に実感する経験をいたしました。 そこで、「自分でやり切ること」だけでチームは強くならないということを本稿にて述べたいと思います。 若手でも幅広く挑戦できる環境 MetemcyberPJでは若手社員であってもコード実装だけにとどまらず、他メンバーのコードレビューやデプロイ、また開発以外の案件支援など、幅広く経験できます。こうした経験を通じて技術的な知識のみならず、チームとしての開発体制のあり方なども学ぶことができます。 また、学ぶだけではなく、改善につながる意見があれば、若手社員であっても発言できます。そして、その意見がチームにとって有益だと判断されれば、柔軟に取り入れてもらえる文化があります。 私自身も、2年目でこうした役割を担当するようになり、自分の視野が大きく広がったと感じています。単にコードを書く力だけではなく、次の観点の視野を持つことが出来ました。 ユーザーにとって必要なものは何か 今チームとして開発は順調に進んでいるか 若手社員の意見も柔軟に取り込んでもらえる環境のおかげで、先輩任せにするのではなく、自分自身の責任感も強まり、成長につながっていると感じています。 一方で、私自身がその責任感を持ちすぎたあまり、うまく動けなかった経験もしました。 若手社員の場合、次のような考え方に陥りがちなこともあります。 自分の担当業務だから最後まで自分の力でやろう！ せっかく任せてくれたのだから最後までやり切りたい！ こうした意気込みは大切ですが、行き過ぎると周りが見えなくなることもあります。 さて、私自身のこのような経験について少し話してみたいと思います。 スクラムという前提 MetemcyberPJでは、スクラムというアジャイル開発手法を用いて開発を進めています。 スクラムではタスクを細かく分解し、チームメンバーで分担しながら開発を進めます。タスクを適切に分担することで、チーム全体の生産性を高めることを目的としています。 そのため、「特定の誰か一人が最後まで抱えなければならない仕事」はほとんどありません。 この前提があるからこそ、状況に応じて役割や優先順位を見直しやすく、若手社員も周囲と相談しながらチャレンジできる環境になっていると感じています。 私が経験した「抱え込み」 1月某日、案件支援業務の資料作成の期日が近づいていた一方で、並行して任されていた開発タスクにも注力しすぎてしまい、資料作成を後回しにしてしまったことがあります。その結果、期日直前まで資料が完成せず、最終的には先輩社員にサポートしていただきながら、なんとか完了させることになりました。 振り返ると、このとき任されていた開発タスクは必ずしも自分一人で最後まで担当しなければならない仕事ではありませんでした。「任された仕事を自分でやり切ろう」という思いが強すぎた結果、タスク全体の優先順位を見失っていたのだと思います。 この経験から学んだのは、「自分でやり切ろう」という責任感を持つことは大切であるが、同じくらいチームとしての成果を出すことも大切であるということです。 個人として頑張ることに意識が向きすぎると、かえってチーム全体の進行や成果に影響を与えてしまうことがあります。 チーム開発では「自分がやり切ること」も大事ではありますが、「今どの進め方がチームにとって最適か」も考えることが重要なわけです。 このとき、もし開発タスクを他メンバーに任せ自分は案件支援業務を優先していれば、資料の品質もより高く担保され先輩社員のサポートも必要になかったかもしれません。結果として複合的にチーム全体への良い影響につながったはずです。 タスクの優先順位のつけ方 このときの経験を通じて、私は自分でやりきることを意識するよりも前に、タスクの優先順位を冷静に見直すことを心がけるようになりました。 タスクの優先順位において、私が意識しだしたのは「工数」と「専門性」の2軸で整理することです。 工数が小さく、専門性の低いタスク 他メンバーに任せやすい仕事 工数は大きいが専門性の低いタスク 上記と同様に他メンバーに任せやすい仕事。特に経験のあるメンバーにお願いすることで、工数を削減されることが期待できる。 専門性が高いタスク タスクを細分化することで協力して進められることもある このように、「他のメンバーが担うことで効率的に進行させられる仕事」を整理したうえで、自分の担当する範囲を決めていくことで、結果としてチーム全体の最適化につながると感じています。 また、若手社員のうちは、任された仕事がどれも同じくらい重要に見えたり、どこまでを自分で持つべきか判断が難しいこともあります。そのようなときこそ、一人で抱え込まず、優先順位や役割分担を周囲と相談しながら決めることが大切だと学びました。そうすることで個人の成果もチームの成果も両立できることに気づきました。 こうして、チーム全体の成果が最大化されるように仕事を整理し、自分の担当範囲を決めることが重要です。 MetemcyberPJ、そしてNTTドコモビジネスでは、個人の成果だけでなくチームとして成果を出すことも同じくらい大切にしています。 「この仕事のこの部分はお願いしたい」「こちらを優先したい」といった相談は、勇気が要るものかもしれません。 特に若手のうちは、「頼りなく見えないだろうか」「忙しい先輩に負担をかけてしまうのではないか」と考えてしまいがちです。 しかし、チームとして成果を重視する環境であれば、そうした相談は前向きな行動として受け止められます。 繰り返しにはなりますが、個人の頑張りは大切であり、それをチーム全体の成果につなげることの方も同じくらい重要です。上記の経験談でもタスクを適切に分担していれば、資料の品質を保ちつつ、自分も開発タスクで価値を出すことができたはずです。 上述した通り、NTTドコモビジネスは若手社員の意見を柔軟に取り込んでもらえます。だからこそ、「自分でやりきること」のみを最優先で考えるのではなく、チームとしてより良い成果を出すための行動をおこしてみましょう！ 最後に 今回の経験から学んだのは、「自分一人でやり切ること」だけを目指すのではなく、チームとして成果を最大化することを意識することで、自分の成果もより価値のある形で発揮できるということです。 若手のうちは、目の前の仕事に真剣に向き合うほど、一人で抱え込んでしまうことがあります。しかし、チーム開発で本当に重要なのは、誰か一人が無理をしてやり切ることではなく、チームとしてより良い成果を出すことです。 私自身もこの経験を通して、「個人の成果を追いかけるだけ」から「チームの成果と自分の成果を両立させる視点」へと意識を変えることができました。 これからも、この環境の中でより良い開発の進め方を学びながら、自身の成長につなげていきたいと考えています。 チームとともに成長しながら開発に取り組みたい方は、ぜひNTTドコモビジネスに興味を持っていただけると嬉しいです。 最後までお読みいただき、ありがとうございました。

みなさん、こんにちは。Amazon Connect ソリューションアーキテクトの坂田です。 2026年2月に発表された Amazon Connect のアップデートをまとめてお届けします。今月は、エージェントの通話品質を向上させる音声強化機能や、タスクの AI 概要・推奨アクション、ダッシュボードのきめ細かいアクセス制御、Amazon Connect Cases の複数の機能拡張、スケジューリングやアウトバウンドキャンペーンの運用改善など、合計 13件のアップデートが発表されました。加えて、AWS Contact Center Blog では AI エージェントの活用やコンタクトセンター移行のベストプラクティスなど 4件のブログ記事が公開されています。以下、カテゴリごとにご紹介します。 目次 注目のアップデートについて 2026年2月のアップデート一覧 エージェント体験の向上 AI・分析機能の強化 Amazon Connect Cases の機能強化 スケジューリングとアウトバウンドキャンペーン AWS Contact Center Blog のご紹介 まとめ 1. 注目のアップデートについて 今月の注目アップデートは以下の 3つです! 注目 1: Amazon Connect が騒音環境向けのオーディオ拡張機能を導入 ひとつめは、2月4日に発表された Audio Enhancement 機能 です。これは、エージェント側の音声をリアルタイムで処理し、エンドカスタマーが聞く音声品質を向上させるものです。コンタクトセンターではしばしば、他のエージェントの会話やネットワーク機器から発せられる騒音など、周囲の雑音が気になることがあります。今回のアップデートは、こうした環境で業務を行うエージェントにとって特に有用な機能です。 この機能には 2つのモード が用意されています。 ノイズ抑制（Noise Suppression）モード : バックグラウンドノイズを低減します。有線・無線ヘッドセット、ヘッドセットなしのいずれの構成でも利用可能です。 音声分離（Voice Isolation）モード : ノイズ低減に加え、コンタクトセンター内で複数の人が話している環境でもエージェントの音声を分離します。有線ヘッドセット使用時のみ推奨されます。 有効化方法 : 管理者がユーザー管理画面から対象エージェントの Phone type を Soft phone に設定し、Audio Enhancement のモードを選択します。設定変更は次の通話から適用されます。セキュリティプロファイルの「コンタクトコントロールパネル (CCP)」権限の「オーディオデバイスの設定」を有効にすると、エージェント自身が CCP 上でモードを切り替えることも可能です。 API サポート : CreateUser / UpdateUserConfig API の VoiceEnhancementConfigs パラメータ、Amazon Connect Streams API の agent.setVoiceEnhancementMode() 、ConnectSDK の Voice API に対応しています。 前提条件 : ソフトフォンユーザーのみ対象。最低 4コア CPU（仮想マシンは 4 vCPU）が必要。VDI 環境ではローカルブラウザアクセス方式のみサポート（Amazon Connect audio optimization 方式は非対応）。 利用可能リージョン : Amazon Connect が提供されているすべての AWS 商用リージョン 関連リソース : Amazon Connect でエージェントのオーディオ強化を有効にする 注目 2: タスクの AI 概要と推奨アクション 概要 : Amazon Connect にタスクの AI 概要と推奨アクション機能が追加されました。エージェントがタスクを受け取った際に、AI が過去のアクティビティを要約し、次に取るべきアクションを提案します。例えば、オンラインフォームから送信された返金リクエストのタスクを受け取った場合、注文詳細の確認、返品資格のチェック、支払い方法の確認といった過去のアクティビティが要約され、返金を完了するための推奨ステップが提示されます。この機能を有効にするには、タスクがエージェントに割り当てられる前のフローに コネクトアシスタント フローブロックを追加します。ナレッジベースを追加することで、推奨内容をさらにガイドすることも可能です。 利用可能リージョン : Amazon Connect のリアルタイムエージェントアシスタンスが利用可能なすべての AWS リージョン 関連リソース Amazon Connect のフローブロック: Connect Assistant 注目 3: Agent Workspace での通知機能 概要 : Amazon Connect Agent Workspace に通知機能が追加されました。ワークスペースのヘッダーに通知が表示され、どのページからでも確認できるため、エージェントやビジネスユーザーは現在の作業を中断することなく、緊急のアップデートやポリシー変更、アクションアイテムなどの重要な情報を受け取ることができます。新しい通知 API を使用することで、組織内の特定のオーディエンスに対してプログラムからターゲットメッセージを送信することが可能です。パブリック API および AWS CloudFormation にも対応しています。 利用可能リージョン : Amazon Connect が提供されているすべての AWS リージョン 関連リソース : ワークスペースヘッダーの通知機能 通知の設定方法 通知の作成・送信はすべて API 経由で行います。Amazon Connect の Notifications API として以下の8つのアクションが提供されています。 CreateNotification : 新しい通知を作成し、指定した受信者に配信します UpdateNotificationContent : 既存の通知内容を更新します DeleteNotification : 通知を削除します DescribeNotification / ListNotifications / SearchNotifications : 通知の詳細取得・一覧・検索を行います ListUserNotifications : 特定ユーザーの通知一覧を取得します UpdateUserNotificationStatus : ユーザーの通知ステータス（既読/未読）を更新します 通知を作成する際の主なパラメータは以下の通りです。 Content : ロケールコード（ ja_JP 、 en_US など 11言語）をキーとしたマップ形式で、各言語の通知テキストを指定します（1言語あたり最大 500文字）。リンクの埋め込みにも対応しています。 Recipients : 受信者のユーザー ARN を配列で指定します（最大 200件）。インスタンス ARN を指定すると、インスタンス内の全ユーザーに送信できます。 Priority : HIGH または LOW を指定します。高優先度の通知は低優先度より上に表示されます。 ExpiresAt : 通知の有効期限をタイムスタンプで指定します。未指定の場合、デフォルトで作成から1週間後に自動的に非表示になります。 Tags : タグベースアクセス制御（TBAC）に使用するタグを付与できます。 アクセス制御 通知の受信には追加の権限は不要ですが、通知の作成・編集・削除・送信済み通知の閲覧には API 権限が必要です。タグベースアクセス制御（TBAC）により、管理者は自身に割り当てられたタグと一致する通知のみを管理でき、一致するタグを持つユーザーにのみ送信できます。階層ベースアクセス制御（HBAC）では、管理者は自身の階層レベル以下のユーザーにのみ通知を送信できます。 2. 2026年2月のアップデート一覧 2.1. エージェント体験の向上 エージェントパフォーマンス評価の異議申し立てワークフロー （2026年2月3日） 概要 : エージェントがパフォーマンス評価に対して異議を申し立てるための統合ワークフローが追加されました。エージェントは評価に同意できない場合、Connect UI 上から理由を添えて異議を申し立てることができます。指定されたマネージャーには自動メール通知が送信され、異議の確認と解決を行います。マネージャーは異議が申し立てられた評価の一覧やステータスを追跡でき、タイムリーな解決が可能です。 利用可能リージョン : Amazon Connect が提供されているすべてのリージョン 関連リソース : 評価の異議申し立て Audio Enhancement（音声強化）によるエージェント通話品質の向上 （2026年2月4日） 注目 1 を確認してください! チャット・タスク・Eメール・コールバックの自動応答（Auto-Accept）設定 （2026年2月5日） 概要 : チャット、タスク、Eメール、コールバックの各チャネルに対して、エージェントの自動応答（Auto-Accept）を設定できるようになりました。自動応答を有効にすると、着信コンタクトがエージェントの手動承認を待たずに自動的に接続されるため、顧客への迅速な対応が可能になります。これまでこの設定はインバウンド音声通話に対してのみ利用可能でしたが、今回のアップデートでチャネルごとに個別に設定できるようになりました。例えば、タスクには自動応答を有効にしつつ、音声通話では無効のままにするといった運用が可能です。 利用可能リージョン : Amazon Connect が提供されているすべての AWS リージョン 関連リソース : 自動応答の有効化 チャネル別の後処理（ACW）タイムアウト設定 （2026年2月11日） 概要 : チャット、タスク、Eメール、コールバックの各チャネルに対して、エージェントの後処理（After Contact Work）タイムアウトを設定できるようになりました。ACW タイムアウトにより、エージェントが後処理に費やせる時間を制限し、タイムアウト後は自動的に対応可能状態に戻ります。これは、エージェントごと、チャネルごとに異なるタイムアウトを設定でき、例えばEメールには短い ACW タイムアウトを設定しつつ、音声通話には次の顧客対応に備えるためのクールダウン時間として長めのタイムアウトを維持するといった運用が可能です。 利用可能リージョン : Amazon Connect が提供されているすべての AWS リージョン 関連リソース : エージェントの設定 Agent Workspace 内の通知機能の追加 （2026年2月13日） 注目 3 を確認してください! 2.2. AI・分析機能の強化 音声インタラクションのテスト・シミュレーション API （2026年2月） 概要 : コンタクトセンターの体験をシミュレーションするテストを構成・実行するための API が追加されました。発信者の電話番号やカスタマープロファイル、通話理由（「注文状況を確認したい」など）、期待される応答（「リクエストが処理されました」など）、営業時間外やキュー満杯といったビジネス条件をプログラムで設定できます。CI/CD パイプラインへの統合、複数テストの同時実行、デプロイサイクルの一部としての自動回帰テストが可能になり、ワークフローの変更を迅速に検証して本番環境へ自信を持ってデプロイできます。 利用可能リージョン : アジアパシフィック（ムンバイ、ソウル、シンガポール、シドニー、東京）、アフリカ（ケープタウン）、欧州（フランクフルト、ロンドン）、米国東部（バージニア北部）、米国西部（オレゴン）、カナダ（中部） 関連リソース : Amazon Connect API リファレンス タスクの AI 概要と推奨アクション （2026年2月13日） 注目 2 を確認してください! ダッシュボードのきめ細かいアクセス制御 （2026年2月12日） 概要 : Amazon Connect ダッシュボードにきめ細かいアクセス制御機能が追加されました。リソースタグを適用することで、特定のエージェント、キュー、ルーティングプロファイルなどのリソースに対するメトリクスの表示権限を制御できます。タグを使用してメトリクスをフィルタリングし、同じタグを共有するエージェントやキューの集計メトリクスを表示することも可能です。例えば、エージェントに「Department:Customer Service」タグを付与することで、カスタマーサービスチームのマネージャーのみがダッシュボードメトリクスを閲覧できるよう制限できます。 利用可能リージョン : Amazon Connect が提供されているすべての AWS 商用リージョンおよび AWS GovCloud (US-West) 関連リソース : ダッシュボードのタグベースアクセス制御 2.3. Amazon Connect Cases の機能強化 依存フィールドオプションをマッピングするための CSV アップロードをサポート （2026年2月6日） 概要 : Amazon Connect Cases のケースフィールドに設定する依存フィールドドロップダウンメニューを CSV ファイルのアップロードで一括設定できるようになりました。依存フィールドオプションは、カスケードドロップダウンメニューを作成します。1 つのフィールド (ターゲットフィールド) で使用可能な選択肢は、別のフィールド (ソースフィールド) で選択された値によって異なります。CSV ファイルは「Parent Field Name」「Child Field Name」「Parent Value」「Child Value」の4列フォーマットで、各行が1つの親子関係を表します。1つの CSV ファイルに複数のフィールドペアを含めることも可能です。地理的な階層構造（国 → 都道府県 → 市区町村）や製品カテゴリの分類（カテゴリ → サブカテゴリ）など、複雑な階層データの設定作業を大幅に効率化できます。なお、ソースフィールドとターゲットフィールドはいずれも単一選択型である必要があります。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、カナダ (中部)、欧州 (フランクフルト、ロンドン)、アジアパシフィック (ソウル、シンガポール、シドニー、東京)、アフリカ (ケープタウン) 関連リソース : 依存フィールドオプション 依存フィールドオプションの CSV アップロード ケーステンプレートでの複数行テキストフィールドのサポート （2026年2月17日） 概要 : ケーステンプレートで複数行テキストフィールドがサポートされるようになりました。この新しいフィールドタイプは、複数の段落に対応して縦方向に拡張されるため、エージェントは根本原因分析、取引の詳細、調査結果などの詳細な自由記述ノートや構造化データをケース内に直接記録できます。これまでの単一行テキストフィールドでは記録しきれなかった詳細情報を、ケースに直接紐づけて管理できるようになり、ケース管理の質が向上します。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、カナダ (中部)、欧州 (フランクフルト、ロンドン)、アジアパシフィック (ソウル、シンガポール、シドニー、東京)、アフリカ (ケープタウン) 関連リソース : Amazon Connect Cases でケースフィールドを作成する AWS Service Quotas との統合 （2026年2月18日） 概要 : Amazon Connect Cases が AWS Service Quotas に対応しました。管理者は Service Quotas コンソールから、適用されているクォータの確認、使用率のモニタリング、およびクォータの引き上げリクエストを一元的に行えるようになりました。対象となるクォータの引き上げリクエストは手動介入なしで自動承認されるため、予期しないサービス制約に遭遇することなくケースワークロードをスケールできます。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、カナダ (中部)、欧州 (フランクフルト、ロンドン)、アジアパシフィック (ソウル、シンガポール、シドニー、東京)、アフリカ (ケープタウン) 関連リソース : Amazon Connect Cases のサービスクォータ 2.4. スケジューリングとアウトバウンドキャンペーン ドラフトスケジュールでのエージェント休暇リクエスト表示 （2026年2月17日） 概要 : 承認済みのエージェント休暇リクエストがドラフトスケジュール内に表示されるようになりました。スケジュール管理者は、特定の日にエージェントがスケジュールされなかった理由を容易に確認でき、スケジュールを公開する前にカバレッジのギャップを特定して調整することが可能になります。これにより、スケジュール作成時の可視性が向上し、人員配置の最適化に役立ちます。 利用可能リージョン : Amazon Connect のエージェントスケジューリングが利用可能なすべての AWS リージョン 関連リソース : 休暇管理 アウトバウンドキャンペーンのダイヤルモード動的切り替え （2026年2月26日） 概要 : アウトバウンドキャンペーンにおけるダイヤルモードの動的切り替え機能が発表されました。コンタクトセンターの管理者は、アクティブなキャンペーン実行中にプレビューモードと非プレビューモード（プログレッシブダイヤルなど）を切り替えることができます。従来はキャンペーン開始後にダイヤルモードを変更するにはキャンペーンの停止と再起動が必要でしたが、今回のアップデートによりキャンペーンを中断することなくリアルタイムで切り替えが可能になりました。例えば、高優先度のコンタクトに対応する際にプログレッシブダイヤルからプレビューモードに切り替え、追加のコンテキストを確認した後、通常のトラフィックパターンに戻った際に元のモードに復帰させるといった運用が可能です。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、カナダ (中部)、欧州 (フランクフルト、ロンドン)、アジアパシフィック (ソウル、シンガポール、シドニー、東京)、アフリカ (ケープタウン) 関連リソース : アウトバウンドキャンペーンの設定 3. AWS Contact Center Blog のご紹介 2026年2月には、AWS Contact Center Blog において Amazon Connect に関連する 4件のブログ記事が公開されました。機能アップデートの発表とは別に、AI エージェントの活用方法やコンタクトセンター移行のベストプラクティスなど、実践的な知見が共有されています。 AI エージェントによるハイパーパーソナライゼーション （2026年2月2日） Amazon Connect Customer Profiles と Amazon Personalize を組み合わせ、顧客対応中にリアルタイムでパーソナライズされた商品レコメンデーションを提供する方法を解説しています。「おすすめ商品」「類似アイテム」「よく一緒に購入される商品」「人気商品」「トレンド商品」の5つのレコメンデーションユースケースが紹介されており、AI エージェントのガードレールやプロンプトのカスタマイズによるブランド一貫性の確保方法も説明されています。さらに、アウトバウンドキャンペーンを活用したプロアクティブな Web 通知の配信についても触れられています。 CX 業界予測 2026 （2026年2月3日） 2026年のカスタマーエクスペリエンス（CX）業界の展望をまとめたソートリーダーシップ記事です。AVOA、Cavell、IDC、Constellation Research などのアナリストの見解を集約し、「オーケストレーション（断片的な AI 導入から統合的なマルチエージェント体験へ）」「トラスト（AI ガバナンスフレームワークの構築）」「スケール（AI 成果の測定可能なビジネスアウトカムへの転換）」の3つのテーマで整理されています。 Amazon Connect への移行ベストプラクティス （2026年2月26日） 既存のコンタクトセンターから Amazon Connect への移行における「人」の側面に焦点を当てた包括的なガイドです。オペレーションチーム（エージェント、スーパーバイザー、QA アナリスト、ワークフォースマネージャー）、インフラストラクチャチーム（テレフォニーエンジニア、ACD 管理者、ネットワークスペシャリスト）、アプリケーションチーム（CX 開発者、エージェントデスクトップ開発者、ルーティング開発者）の3カテゴリに分けて、レガシーロールから Amazon Connect ロールへのトレーニングパスが詳細に解説されています。 Kiro を活用した AI エージェント開発の高速化 （2026年2月27日） AI コーディングアシスタント Kiro を使用して、15 のバックエンド API を統合した Amazon Connect AI エージェントをわずか3日間で構築した事例を紹介しています。通常 2〜3週間かかる POC 開発を大幅に短縮し、Kiro によるアーキテクチャ設計、Lambda 関数のコード生成、CloudWatch ログ分析によるデバッグ、MCP ツールスキーマの作成といった開発プロセスが解説されています。Amazon Bedrock Agents、AWS Lambda、Amazon DynamoDB、Amazon Bedrock AgentCore Gateway を活用した統合パターンが示されています。 4. まとめ 2026年2月は、エージェント体験の向上（Audio Enhancement、チャネル別設定、Agent Workspace 内の通知機能）、AI・分析機能の強化（タスクの AI 概要・推奨アクション、ダッシュボードのきめ細かいアクセス制御）、Amazon Connect Cases の機能強化（CSV 一括設定、複数行テキスト、Service Quotas 統合）、そしてスケジューリングとアウトバウンドキャンペーンの運用改善と、幅広い領域にわたる13件の機能アップデートが発表されました。 特に、Audio Enhancement によるエージェントの通話品質向上、タスクの AI 概要・推奨アクションによるエージェント生産性の向上、そしてアウトバウンドキャンペーンのダイヤルモード動的切り替えは、日々のコンタクトセンター運用に直接的なメリットをもたらす注目のアップデートです。 また、AWS Contact Center Blog では、AI エージェントによるハイパーパーソナライゼーション、CX 業界の 2026年予測、Amazon Connect への移行ベストプラクティス、Kiro を活用した AI エージェント開発の高速化の 4件のブログ記事が公開されました。機能アップデートと合わせて、これらのブログ記事もぜひご確認ください。 今後も最新の Amazon Connect のアップデート情報は AWS の What’s New ページ や Amazon Connect のリリースノート 、そして AWS Contact Center Blog で確認できます。引き続き最新情報をチェックしてみてください。 シニア スペシャリスト ソリューションアーキテクト/Amazon Connect, 坂田 陽一郎