AWS What's New Digest

Appearance

2026年06月23日 ​

[Aiml] Claude Tag is now available in beta via Claude Enterprise in AWS Marketplace ​

概要 ​

AnthropicのClaude Tagがベータで提供開始され、AWS Marketplace経由でClaude Enterpriseを利用するAWS顧客がSlackなどのチャネル内で@Claudeを呼び出して協働できるようになりました。チャネル単位のエージェントID、消費ベースの課金、チャンネル毎の支出制御などガバナンス機能を備えています。

変更内容・新機能の詳細 ​

Claude Tagはチームが普段使っているチャネル（まずはSlack）に直接Claudeを埋め込み、チャネルごとにアクセス権を与えてツール・データ・コードベースに接続できる“マルチプレイヤー”エージェントです。誰でもチャネル内で@Claudeをタグ付けしてタスクを委任でき、Claudeは参加チャネルから関連情報を記憶してコンテキストを構築し、将来実行するタスクの計画まで行います。セキュリティ面ではチャネルごとにスコープされた専用のエージェントIDで動作し、支出制御（組織全体の予算可視化とチャンネル毎の上限）をサポート、ambient mode（会話の受動的監視）はデフォルトでオフになっています。AWS Marketplace経由のClaude Enterprise体験はファーストパーティ版と同等で、既存のClaire Enterpriseのエントitlementを利用します。管理者はClaude管理コンソールでエージェントIDをプロビジョニングし（所要時間は概ね1時間）、対象チャネルにスコープします。課金はヘッドカウントではなく使用量ベースの消費課金で追跡されます。

影響範囲・利用シーン ​

  • 対象ユーザー: 開発者、プロダクト／データチーム、SRE／運用チーム、セキュリティ・ガバナンス担当者
  • 利用シーン: Slack上での問い合わせ対応やドキュメント検索、コードベース照会、タスク委譲・自動化ワークフローのトリガー、インシデント対応時のコンテキスト集約
  • 運用効果: チャンネル内で即時にタスクを割り当て・並行処理が可能になり、生産性向上と対応速度の改善が期待できる。チャネル単位のID・支出制御によりガバナンスとコスト管理を両立できる

技術的な注意点 ​

  • IAM権限: AWS Marketplaceの契約・エントitlement確認およびClaude Enterprise管理コンソールの管理者権限が必要。Slack連携時はSlackワークスペースの管理者権限でボット連携を許可する必要があります
  • リージョン制限: 記事では特定リージョンの記載なし。利用前に自組織のAWS Marketplace提供リージョンでの利用可否を確認してください（ベータ提供のため地域差があり得ます）
  • コスト: 消費ベースの課金（使用量トラッキング）。利用頻度や大量のコンテキスト保持でコストが増加する可能性があるため、組織全体の予算設定とチャンネル毎上限を活用してください
  • データ・プライバシー: チャネルに接続する外部ツールやコードベースへアクセス許可を与えるとデータが参照されるため、機密データの取扱いやログ保持ポリシーを確認・制限してください
  • ベータ注意: 現在はベータリリース。機能やAPI、提供リージョン、料金体系が変更される可能性があります
  • 導入手順: 既存のClaude Enterprise（AWS Marketplaceのエントitlement）を使用。管理者がClaude管理コンソールでエージェントIDをプロビジョニング（概ね1時間）し、チャネル単位でスコープを設定する必要があります

参考情報 ​

[Opensearch Service] Amazon OpenSearch Service now offers AI-assisted migrations ​

概要 ​

Amazon OpenSearch ServiceのMigration AssistantがAI支援機能を追加し、セルフマネージドのApache Solr/Elasticsearch/OpenSearchからOpenSearch Serverlessまたはマネージドクラスターへの移行を、AIエージェントを使って計画・実行・検証できるようになりました。Solr向けのライブトラフィックのキャプチャとリプレイもサポートします。

変更内容・新機能の詳細 ​

既存のMigration Assistant（2023年12月に導入）に、KiroやClaude CodeなどのサードパーティAIツールと連携するAIアシスト体験が追加されました。これにより、移行計画の策定、必要なインフラのデプロイ、自動化された手順による履歴データ移行およびライブトラフィック移行（キャプチャ＆リプレイ）をエージェント主導ワークフローで実行・検証できます。エージェントは移行のステップを構造化して実行順や検証ポイントを提示し、人手による手順ミスや計画の抜け漏れを減らします。対応先はOpenSearch ServerlessおよびManaged Clustersで、ソースは複数のSolr、Elasticsearch、OpenSearchバージョンに対応（詳細はドキュメント参照）。Migration AssistantはAmazon OpenSearch Serviceが利用可能なすべての商用リージョンおよびAWS GovCloud(US)で利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド移行を行うSRE/プラットフォーム/データエンジニア、DevOpsチーム、サービス運用チーム
  • 利用シーン: セルフマネージドのSolr/Elasticsearch/OpenSearchをAWSのOpenSearch ServerlessまたはManaged Clusterへ移行する際の計画策定・実行・検証（履歴データとライブトラフィックの移行）
  • 運用効果: 移行計画と手順の自動化により移行時間と人的ミスが削減され、移行の信頼性と再現性が向上する
  • ビジネス効果: ダウンタイムと移行コストの低減、移行プロジェクトの短期化によりサービス移行のリスク低減と迅速なクラウド移行が可能

技術的な注意点 ​

  • IAM権限: Migration Assistantおよび該当API/リソースを操作するための適切なIAM権限（OpenSearch、EC2、S3、VPC、KMSなど）を事前に用意してください
  • リージョン制限: Amazon OpenSearch Serviceが提供されているすべての商用リージョンおよびAWS GovCloud(US)で利用可能。詳細はリージョン別ドキュメントを確認してください
  • サポートバージョン: 対応するSolr/Elasticsearch/OpenSearchのバージョン制約があります。移行前にドキュメントでサポートバージョンと既知の制限を確認してください
  • ネットワーク/接続: オンプレ/セルフマネージド環境とAWS間のネットワーク接続（VPN/Direct Connect/パブリックエンドポイントなど）やファイアウォール設定が必要です。ライブトラフィックキャプチャは追加のネットワーク設定やプロキシが必要な場合があります
  • データ保護・セキュリティ: 移行中のデータ転送、ログ、メタデータに関する暗号化（KMS等）とアクセス制御を設計してください。AIツール連携時は機密データの扱いに注意し、サードパーティサービスのデータ利用ポリシーを確認してください
  • コスト: Migration Assistant自体の利用はリージョン・構成により影響がありますが、主に移行中のデータ転送、追加のインフラ（中間バケット、リプレイ用キャプチャストレージ）、およびOpenSearch側のクラスター/Serverlessリソースに対する料金が発生します。AIツールの利用は別途料金がかかる場合があります
  • 事前準備: スナップショット/バックアップ、インデックスの互換性チェック、マッピングやアナライザーの差異確認、性能テスト（ステージングでのリプレイ検証）を事前に実施してください

参考情報 ​

[General] AWS HealthOmics now supports Nextflow profiles ​

概要 ​

AWS HealthOmicsがNextflowのprofilesを実行時に指定できるようになりました。これにより、実行設定（リソース制限や実行オプション）をワークフロー本体から分離して再利用・切替でき、開発→本番移行やポータビリティが容易になります。

変更内容・新機能の詳細 ​

Nextflow profilesは、executor、リソース（CPU/メモリ/インスタンスタイプ）、Docker/コンテナ設定、ログやキャッシュの動作など実行時設定を再利用可能な設定セットとして定義し、実行時に選択できる仕組みです。AWS HealthOmicsはこれをサポートし、ワークフロー実行時に1つまたは複数のNextflow profileを指定できます（複数指定時はマージ・優先順位に従います）。これによりプラットフォーム固有の設定（例：AWS固有のexecutor設定やインスタンスタイプ、VPCやサブネット指定等）をワークフロー定義から分離し、ソースコードを変更せずに開発・検証・本番の設定を切り替えられます。nf-coreのようにパイプラインに同梱されているbuilt-inやinstitutional profileもHealthOmics上で有効化して利用可能です。機能は全対応リージョン（US East (N. Virginia), US West (Oregon), Europe (Frankfurt, Ireland, London), Israel (Tel Aviv), Asia Pacific (Singapore, Seoul)）で利用できます。詳細な指定方法や挙動はHealthOmicsのNextflowエンジン設定ドキュメント（Nextflow Profilesセクション）を参照してください。なお、AWS HealthOmicsはHIPAA適合対象サービスとして医療・ライフサイエンス用途に向けた運用が可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: バイオインフォマティクスエンジニア、研究者、SRE/DevOps（HealthOmicsでNextflowを使うチーム）
  • 利用シーン: 開発／検証／本番で異なる実行設定を使い分ける（例：ローカル軽量実行→大規模クラスタ／大きなEC2インスタンスタイプへの切替）、nf-coreパイプラインの既存プロファイルを利用して実行を標準化
  • 運用効果: ワークフローコードを編集することなく設定切替が可能になり、手動編集によるミスが減少、ワークフローの移植性とスケールアップ速度が向上し運用工数を削減

技術的な注意点 ​

  • IAM権限: HealthOmicsでワークフローを作成・実行・管理するための権限（HealthOmics関連API、S3アクセス、必要に応じてKMSやIAMロールの使用許可）を事前に確認・付与してください
  • リージョン制限: 本機能は記事記載の全対応リージョン（US East (N. Virginia)、US West (Oregon)、Europe (Frankfurt, Ireland, London)、Israel (Tel Aviv)、Asia Pacific (Singapore, Seoul)）で利用可。未対応リージョンでは利用不可です
  • コスト: profiles自体に追加料金は発生しませんが、profileで指定する実行リソース（より大きなインスタンス、より多くの並列ジョブ等）に応じてコンピュート・ストレージ費用が増加します
  • Nextflow互換性: 使用するワークフロー側がprofileを定義している必要があります（nf-core等の既存profileは利用可能）。複数profile指定時のマージルールや優先順位はNextflowの仕様に従います
  • 設定の適用範囲: profileはNextflowの設定を上書き・拡張します。executorやコンテナ設定、キャッシュや再実行ポリシーなどプラットフォーム固有設定を分離して管理できますが、期待する動作になるようprofile内容は十分に検証してください
  • ネットワーク／データアクセス: profileでVPC、サブネット、IAMロールやS3バケットへのアクセス方法を変更する場合、必要なネットワーク設定やアクセス権限が整っていることを確認してください
  • セキュリティ／コンプライアンス: HealthOmicsはHIPAA適合対象サービスですが、患者データ等を扱う場合は適切なアカウント設定、アクセス制御、監査ログ取得を行ってください

参考情報 ​

[General] AWS introduces Lambda MicroVMs for isolated execution of user and AI-generated code ​

概要 ​

AWSはLambda MicroVMsを発表しました。これはFirecrackerベースのVMレベルの分離、ほぼ即時の起動/再開、最大8時間のサスペンドによる状態保持を備えたサーバーレスの実行プリミティブです。

変更内容・新機能の詳細 ​

Lambda MicroVMsはFirecracker仮想化を基盤とし、ユーザーやAIが生成したコードを各ユーザー／ジョブごとに独立したMicroVMで実行できます。開発者はDockerfileからMicroVMイメージを作成し、そのイメージからMicroVMを起動します。各MicroVMには専用のHTTPS URLが割り当てられ、HTTP/2、gRPC、WebSocketなどの一般的な接続プロトコルをサポートします。起動は“near-instant”を目指しており、実行をサスペンドして最大8時間後に再開（resume）できます。運用面では仮想化インフラを管理する必要がなく、強い隔離（VMレベル）と高速な起動、状態保持を同時に実現します。起動方法はAWS Lambdaコンソール、CloudFormation、CDK、Agent Toolkit for AWSなどに対応します。料金はMicroVMが稼働している間のベースラインコンピュートに対して課金され、ワークロードがベースラインを超えた追加リソースは実際にアクティブな期間分のみ課金されます。提供リージョンはN. Virginia、Ohio、Oregon、東京、アイルランドです。

影響範囲・利用シーン ​

  • 対象ユーザー: マルチテナントな対話型コード実行環境やAIエージェントを使うアプリ開発者、SaaSプロバイダ、セキュリティスキャナ開発者
  • 利用シーンまたは効果: エンドユーザーやAI生成コードを安全に分離して実行する必要があるケース（オンラインIDE、コーディング支援、データ分析ジョブ、脆弱性スキャン等）において、ユーザー毎に専用実行環境を簡単に割り当てられる
  • 運用効果: 仮想化管理負荷を削減しつつVMレベルの隔離で悪意あるコードや誤った実行の影響を低減、ほぼ即時の起動とサスペンド/再開によりユーザー体験とリソース効率を両立

技術的な注意点 ​

  • リージョン制限: 現時点で利用可能なリージョンは US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo), Europe (Ireland) です
  • イメージ作成: DockerfileからMicroVMイメージを作成するワークフローが必要（既存のコンテナイメージから変換）
  • 状態保持: 実行のサスペンド→再開は最大8時間までサポート。永続化ストレージの取り扱いはアプリ設計次第（外部ストレージへの同期を検討）
  • 接続プロトコル: HTTPS URLを介してHTTP/2、gRPC、WebSocketに対応。接続のTLS設定や証明書管理は設計で考慮
  • セキュリティ/IAM権限: MicroVMの作成・起動・管理には適切なLambda関連とMicroVM専用のIAM権限が必要。最小権限のポリシー設計を推奨
  • リソース制限: Firecrackerベースの軽量VMだが、CPU/メモリ/ネットワークの割当・上限や同時起動数の制限を公式ドキュメントで確認すること
  • コスト: ベースラインでの稼働コストと、ベースラインを超えた分のアクティブ課金があるため、サスペンド運用やバースティング挙動を考慮したコスト設計が必要
  • 互換性: ランタイムやOSレベルの互換性、既存コンテナからの移行時の依存関係確認が必要
  • 可観測性/運用: ログ、メトリクス、トレースの収集方法（CloudWatch等）と、サスペンド/再開時の状態追跡設計を検討
  • ツールチェーン: コンソール、CloudFormation、CDK、Agent Toolkit for AWSが利用可能。CI/CDやイメージビルドパイプラインに組み込む設計を推奨

参考情報 ​

[Network Firewall] AWS Network Firewall updates default drop action for improved connection reliability ​

概要 ​

AWS Network Firewallの新しい既定のステートフルドロップ動作が「Application drop established (server-directed only)」に変更され、これにより新規作成されるファイアウォールポリシーでサーバー→クライアント方向の正当なTCP制御パケット（ウィンドウ更新、キープアライブ、リセット等）が誤って破棄される問題が緩和されます。

変更内容・新機能の詳細 ​

従来の既定値「Application drop established (bidirectional)」（旧名: Application layer drop established）は、確立済みフローの双方向でアプリケーション層のパケットをドロップする挙動でしたが、これが原因でサーバーからクライアントへ送られるTCPレベルの制御パケット（例えばウィンドウ更新、keep-alive、RSTなど）が密かに破棄され、断続的な接続障害や診断困難な通信不具合を引き起こす事例がありました。今回の変更により、新規に作成されるファイアウォールポリシーの既定のステートフルアクションは「Application drop established (server-directed only)」となり、サーバー→クライアント方向の重要な制御パケットを保護することで信頼性を高めます。既存のポリシーは自動的に変更されないため、影響を受ける環境ではポリシーの確認・切り替えが必要です。また、ポスト量子暗号（PQC）を利用した断片化されたTLSハンドシェイクなど特定のユースケースでは、旧来の双方向ドロップが必要になる場合があるため、その場合はドキュメントに従って「Application drop established (bidirectional)」を維持するか、TCPドロップルールに“to_server”フラグを追加してサーバー方向のフロー制御パケットをブロックしないように設定します。変更はAWS Network Firewallが提供されている全リージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: ネットワーク/セキュリティエンジニア、クラウドアーキテクト、SRE/運用チーム
  • 利用シーンまたは効果: 新規ファイアウォールポリシーでサーバー→クライアント方向のTCP制御パケットが誤検知・破棄される問題を軽減し、断続的な接続障害の発生を防止できます
  • 運用効果: トラブルシューティング負荷の低減、接続信頼性の向上、ユーザー体験の安定化
  • 既存環境への影響: 既存のポリシーは自動変更されないため、既存設定で双方向ドロップが必要なシナリオ（例: PQCで断片化されたTLSハンドシェイク）では設定の見直しが必要です

技術的な注意点 ​

  • IAM権限: ファイアウォールポリシーの作成/更新には network-firewall:CreateFirewallPolicy / network-firewall:UpdateFirewallPolicy 等の権限が必要です（ロールやIAMポリシーを事前確認してください）
  • リージョン制限: AWS Network Firewallが提供されている全リージョンで適用されます（サービス未提供リージョンでは利用不可）
  • コスト: 既定値の変更自体に追加料金は発生しません。ただし、ポリシー変更やテストに伴うログ保存（S3/CloudWatch Logs）や追加のトラフィック解析はコスト要因になります
  • 既存ポリシーへの影響: 変更は新規作成されるファイアウォールポリシーに対してのみ有効です。既存ポリシーは自動で切り替わらないため、運用ポリシーは手動で確認・更新してください
  • PQC/断片化TLSの注意: ポスト量子暗号化に関連する断片化されたTLSハンドシェイク等、特殊なトラフィックでは双方向ドロップが必要なケースがあります。その場合はドキュメントを参照して「Application drop established (bidirectional)」を維持するか、TCPドロップルールに“to_server”フラグを追加してサーバー方向の正当パケットがブロックされないように設定してください
  • テスト/ロギング: ポリシー変更後はステージング環境で十分に検証し、Network Firewallのログ（アラート/フロー）やVPC Flow Logs、監視メトリクスで通信の正常性を確認してください

参考情報 ​

[General] AWS Batch now supports customer-ordered instance allocation strategies ​

概要 ​

AWS Batchが顧客指定のインスタンスタイプ優先順をサポートする新しい配分戦略（BFPO／SCOP）を追加しました。これにより、ワークロード特性に合わせてインスタンスタイプの優先順位を明示的に制御できます。

変更内容・新機能の詳細 ​

新たに追加された Best Fit Progressive Ordered（BEST_FIT_PROGRESSIVE_ORDERED、以下BFPO）と Spot Capacity Optimized Prioritized（SPOT_CAPACITY_OPTIMIZED_PRIORITIZED、以下SCOP）は、Compute Environment作成／更新時にインスタンスタイプ（またはファミリー）の順序付きリストを渡すことで、AWS Batchによるインスタンス割り当ての優先度をユーザー側で決められるようにする配分戦略です。BFPOはオンデマンドのCompute Environment向け、SCOPはAmazon EC2 SpotのCompute Environment向けに指定します。実装方法は、CreateComputeEnvironment / UpdateComputeEnvironment API（またはAWS Batch Management Console）でallocationStrategyにそれぞれの値を設定し、ordered list（instance types / families）を指定します。BFPOは指定した順で“最適にフィットする”インスタンスタイプを順次試行して割当てを行い、SCOPはスポット容量最適化の挙動を維持しつつユーザーの優先度を反映します。これらはAWS Batchが利用可能なすべてのリージョンでサポートされています。

影響範囲・利用シーン ​

  • 対象ユーザー: バッチ／バッチワークロードを運用するクラウドエンジニア、SRE、データ処理パイプライン担当者
  • 利用シーン: 特定インスタンスタイプで最適なCPU/メモリ/ネットワーク特性が必要なジョブ、既知のインスタンスタイプでコスト対性能最適化を行いたい場合（オンデマンド／Spotそれぞれ）
  • 運用効果: インスタンスタイプの優先順位を明示できるため、パフォーマンス要件に合わせた割当てが可能になり、無駄なリソース選定や予期せぬ性能劣化を低減できる

技術的な注意点 ​

  • IAM権限: CreateComputeEnvironment/UpdateComputeEnvironment や AWS Batch の管理操作を行うIAM権限（例: batch:CreateComputeEnvironment, batch:UpdateComputeEnvironment）が必要です。Compute EnvironmentがEC2インスタンスを起動するためのEC2権限や関連ロール（ecsInstanceRole等）の設定も確認してください。
  • リージョン制限: 公表によれば「AWS Batchが利用可能なすべてのリージョン」でサポートされています。ただし個別のインスタンスタイプの可用性はリージョン／AZに依存します。
  • コスト: 指定するインスタンスタイプやSpot利用の割合によりコストが変動します。BFPOはオンデマンド割当てを対象にできるためコスト増加の可能性、SCOPはSpotを前提に容量最適化を行うがSpot中断リスクと価格変動を伴います。
  • 運用上の注意: 指定順に依存するため、上位に指定したインスタンスタイプが不足または非推奨になると割当てに影響します。Spotでは中断（interruptions）リスクを考慮したフォールバック設計が必要です。インスタンスのENI/CPU/memory制限やジョブのリソース要求と整合させてください。
  • API/コンソール: CreateComputeEnvironment / UpdateComputeEnvironment API および管理コンソールから設定可能です。フィールド名やJSONペイロードの形式（allocationStrategy とインスタンスタイプ順序）を事前に確認してから更新してください。

参考情報 ​

[General] AWS IAM Identity Center now supports separate quotas for AWS accounts and applications ​

概要 ​

AWS IAM Identity Center（旧AWS SSO）が、1つのIdentity Centerインスタンスで管理する「AWSアカウント数」と「アプリケーション数」を独立したクォータとして扱うようになりました。デフォルトでそれぞれ最大7,000件まで設定可能で、片方を多く使ってももう片方の容量を消費しません。

変更内容・新機能の詳細 ​

変更点は、IAM Identity Centerインスタンスごとに「AWSアカウント」と「アプリケーション」のクォータを個別に管理するようになったことです。デフォルトでは両方とも最大7,000件（accounts: 7,000、applications: 7,000）まで設定でき、必要であれば AWS Service Quotas コンソール（または API/CLI）からクォータ増加を申請できます。既により高い上限を持つ既存の顧客には、自動的に両方に同等の上限が付与されます。本変更により、大規模なマルチアカウント組織が多数のAWSアカウントを管理している場合でも、アプリケーションを追加する際にアカウント用のクォータを消費することなくオンボーディング可能になります。適用はIAM Identity Centerが利用可能な全リージョンで有効です。

影響範囲・利用シーン ​

  • 対象ユーザー: 大規模なマルチアカウントを管理するエンタープライズ、ID/アクセス管理者、SRE/運用チーム
  • 利用シーン: 数千のAWSアカウントを持つ組織が新しい業務アプリケーション（SAML/OIDC/カスタムアプリ）をIAM Identity Centerにオンボードする際、アカウント用クォータを消費せずにアプリ登録が可能
  • 運用効果: クォータ競合が解消され、クォータ計画や増加申請の頻度が低減。アプリ導入とアカウント管理を独立してスケーリングできる
  • コスト影響: クォータ増加申請自体に料金は発生しないが、アプリ/ユーザー/セッションの増加に伴う監査ログ、サードパーティ連携の利用料、運用コストが増える可能性がある

技術的な注意点 ​

  • IAM権限: Service Quotas で増加申請を行うには servicequotas:RequestServiceQuotaIncrease 等の権限、また増減を管理するにはIAM Identity Centerの管理権限が必要です
  • 増加手段: AWS Management Console（Service Quotas）、AWS CLI（aws service-quotas request-service-quota-increase）、またはAWS SDKから申請可能です
  • 既存ユーザー取り扱い: 既に高い上限を保有している顧客は自動的に同等の上限がアカウント用・アプリ用双方に適用され、追加操作は不要です
  • リージョン制限: IAM Identity Center が利用可能な全リージョンで適用されます。該当リージョンでIAM Identity Centerが有効であることを確認してください
  • 定義注意: ここでの“アプリケーション”はIAM Identity Centerに設定するSAML/OIDCアプリケーションや統合アプリ（AWSアカウントへの割当とは別のエンティティ）を指します
  • コスト: クォータ変更自体の課金はありませんが、リソース・ログ・統合先の利用増加に伴う料金影響を評価してください

参考情報 ​

[Msk] Amazon MSK now offers AI Agent Skills to help developers operate MSK efficiently and accelerate migrations to MSK ​

概要 ​

Amazon MSKがAIエージェント用の“AI Agent Skills”を提供開始しました。これにより開発者は既存のコード支援エージェントを使ってMSKの運用・トラブルシューティング・Kafkaからの移行を効率的に行えます。

変更内容・新機能の詳細 ​

AI Agent Skillsは、MSKに関する専門的かつ最新の運用知見をAIコーディングアシスタント（例: Kiro、Claude Code、Cursor）に付与する機能です。サポートするタスクには、トラブルシューティング、クラスタのサイズ設計（ブローカー種別・インスタンスタイプ選定）、設定（パラメータ、ブローカー構成）、監視（CloudWatchメトリクスの解釈やアラート設計）、および外部Apache KafkaクラスターからMSK Expressへの移行可否判定や移行手順の案内が含まれます。開発者はAgent Toolkit for AWSをAWS CLIで設定した後、普段使っているAIエージェントに「どのブローカー種別・サイズが適切か」「私のKafkaはMSK Expressと互換性があるか」などの自然文で質問するだけで、ガイド付きの具体的な推奨や手順を受け取れます。

特にMSK Expressへの移行に関して、記事では以下のパフォーマンス改善が挙げられています: ブローカー当たり最大3倍のスループット、最大20倍速いスケールアップ、リカバリ時間の90%短縮（いずれもStandardブローカー（Apache Kafka）との比較）。AIスキルはこれらの比較情報を踏まえ、移行適合性チェックや推奨設定（スループット目標に合わせたブローカーサイズ、パーティション数、I/O/ネットワーク要件等）を提示します。

実装面では、AI Agent Skillsは外部AIエージェントと連携するための「設定ガイド」を提供し、Agent Toolkit経由で必要なメタデータ（クラスタ設定やCloudWatchメトリクス等）への読み取りアクセスを与えることで、エージェントが実際の環境情報を参照して具体的なアドバイスを生成します。これにより、従来はKafkaやMSKの専門家が必要だった判断を開発チーム自身で短時間に行えるようになります。

影響範囲・利用シーン ​

  • 対象ユーザー: 開発者、プラットフォーム/インフラエンジニア、SRE、移行担当チーム
  • 利用シーン: MSKクラスタのサイズ設計や設定調整、パフォーマンス問題のトラブルシューティング、外部KafkaからMSK Expressへの移行判定と手順作成
  • 運用効果: 専門家依存度の低減による運用コスト削減、移行検討・実行スピードの向上、MSK Express利用でスループット/スケール/リカバリ性能が大幅改善される可能性

技術的な注意点 ​

  • IAM権限: Agent Toolkit/エージェントに与えるIAMは最小権限で設計してください（MSK Describe系/API、CloudWatch Read、必要に応じてSecretsManager/S3の読み取り等）。
  • リージョン制限: 記事でのリージョン制限は明記されていません。利用前に対応リージョンを公式ドキュメントで確認してください。
  • コスト: AIエージェント自体の利用料、Agent Toolkitの利用有無は各サービスの料金体系に依存します。加えてMSK ExpressとStandardの料金差やデータ転送コストを確認してください。
  • ネットワーク/セキュリティ: エージェントが実環境のメトリクスや設定にアクセスする場合はVPC接続、プライベートエンドポイント、暗号化（TLS/KMS）やログ監査の設定を確認し、機密情報が不必要に外部に出ないようにしてください。
  • 互換性チェック: Kafkaのカスタムプラグインや非標準機能を利用している場合、MSK Expressとの互換性評価が必要です。エージェントの判定結果は最終確認として十分に検証してください。
  • 前提条件: AWS CLIとAgent Toolkit for AWSのセットアップ、AIコーディングエージェント（Kiro/Claude Code/Cursorなど）との連携設定、MSKクラスタとCloudWatchの適切なメトリクス収集が必要です。

参考情報 ​

AI要約はOpenAI APIによって生成されています。

Copyright © 2026