本稿は、KDDI 株式会社 コア技術統括本部 情報システム本部 DX システム 2 部 フロント SRE グループ 西 総一朗 氏に寄稿いただきました。 はじめに KDDI 株式会社 （以下、KDDI）では 2026 年 7 月、通信事業のお客さま向けサービスを支える Amazon Elastic Kubernetes Service （以下、EKS）のクラスタを、マネージドノードグループから Amazon EKS Auto Mode （以下、EKS Auto Mode）へ移行しました。移行の目的は、ワーカーノードの更新にかかる運用工数を削減し、そのセキュリティを継続的に担保することでした。EKS Auto Mode の導入に際して、解決すべき課題が 2 つありました。起動時の CPU 需要への対処と、ノードの入れ替え時刻の制御です。後者については、EKS Auto Mode の仕様を本システムの要件に合わせるため、筆者がカスタムコントローラを開発しました。移行完了後、ワーカーノードは AWS が提供する最新の AMI へ自動で入れ替わり、遅くとも 21 日以内には必ず更新されるため、脆弱性への対応のために計画していたワーカーノードの更新作業はなくなり、運用工数の削減に繋がりました。本稿では、採用と対処のそれぞれの判断を支えた実測値とあわせて、導入から運用までの経緯を紹介します。 プロジェクトの概要 KDDI は通信事業を基盤としながら、au PAY・Ponta ポイント・エンタメ・エネルギーなど、ユーザーの生活に密着した多彩なサービスを展開しています。本稿で扱うのは、そのうち通信事業のお客さま向けサービスです。筆者は KDDI の内製 SRE チーム（社内では「クラウド SA（ソリューションアーキテクト）」と呼んでいます）に所属し、AWS 上のインフラの設計・構築・運用を担当しています。開発体制の特徴として、インフラとアプリケーションで変更のリードタイムが異なる点が挙げられます。AWS インフラは KDDI の SRE チームが内製しており、設計変更を短いサイクルで実施できます。アプリケーションは組織をまたいで開発しているため、改修には相応の調整期間が要ります。そこで本事例では一貫して、アプリケーション開発チームの負荷をインフラ側で吸収する方針で設計を進めました。 本稿で言及するワークロードは、複数の Java（Spring Boot）マイクロサービス群で構成されています。トラヒックには季節性があり、繁忙期には平常時の 3 倍以上のリクエストが発生します。1 日の中でも、最大と最小で 6 倍以上の開きがあります。アプリケーションが稼働する EKS クラスタは過去に 7 回のバージョンアップをしてきました。いずれの作業も、切り戻しが容易であることから、既存クラスタとは別に新しいクラスタを構築し、Amazon Route 53 の加重レコードで切り替える Blue/Green 方式で実施していました。直近 2 回のバージョンアップ作業の中で、ノード OS の Bottlerocket OS への変更と、EKS Auto Mode への移行を実施しました。 EKS Auto Mode を採用した理由 脆弱性対応を、人手の作業から切り離したかった 従来の構成では、ワーカーノードへの変更を最小限の差分に留める方針を採っていました。脆弱性への対応が必要になると、対象のミドルウェアにだけパッチを適用し、その作業では EKS のバージョンやほかのミドルウェアは変更しませんでした。変更範囲を絞ることで正常性を確実に確認し、性能や機能のリグレッションを防ぐためです。ワーカーノードを入れ替える際はメンテナンス状態にする必要があるため、アプリケーション側と調整したうえで夜間に作業していました。脆弱性には都度対応できていた一方で、そのたびに調整・検証・夜間作業の工数がかかっていました。また近年はセキュリティ要件が厳格になり、脆弱性へのより迅速な対応が求められるため、人手を前提とした運用では負担が増え続けます。 EKS Auto Mode では、 ノードの有効期限を最長 21 日に設定 でき、有効期限を迎えたノードは AWS が管理する最新の AMI へ自動で入れ替わります。また、AWS がパッチを適用した新しい AMI を公開すると、有効期限を待たずに自動で最新の AMI へと入れ替わります。人手を介さずにノードを更新できるこの仕組みは魅力的でした。 自動更新を受け入れられると判断した根拠は 2 つあります。 ノードの更新がアプリケーションに影響しにくいこと。EKS Auto Mode ではカスタム AMI や OS を選べず、ノードに独自のソフトウェアや設定を持ち込めません。本システムはもともと、アプリケーションが必要とする機能をノードに依存させていませんでした。そのため、ノードが入れ替わってもアプリケーションへの影響は小さいと判断しました。 互換性の確認を自分たちで行う範囲が減ること。ノード OS と VPC CNI や CoreDNS などの基盤コンポーネントを AWS が一体で管理・更新するため、組み合わせごとの更新計画や互換性の確認を自分たちで抱える必要が少なくなります。 EKS Auto Mode にはノードの Amazon EC2 の料金に加えて管理料金がかかります。それでも、脆弱性への対応にかけていた工数と比較すると、本システムのようなセキュリティ要件の厳しいエンタープライズの用途では、追加料金を上回る効果があると判断しました。 OS の切り替えと EKS Auto Mode の導入を 2 段階に分けることで、リスクを抑えて段階的に移行できる見通しが立った EKS Auto Mode のノード OS は Bottlerocket OS に固定されています。Bottlerocket OS はコンテナの実行に必要な最小限の構成とイミュータブルなルートファイルシステムにより、攻撃面を小さくする設計の OS です。当時のクラスタは Amazon Linux 2 で動いていました。そこで 2 段階の計画にしました。1 度目のバージョンアップでまずノード OS を Bottlerocket OS へ切り替え、2 度目のバージョンアップで EKS Auto Mode へ移行する順序です。1 回の移行で変える要素を減らし、問題が起きたときに原因を切り分けやすくするためです。あわせて、EKS アドオンとして導入できるコンポーネントはアドオンに集約する方針も採りました。 この 2 段階の間に、アプリケーション側では Graceful Shutdown への対応を進めました。EKS Auto Mode ではノードが人の立ち会いなしに入れ替わります。ノードの入れ替え時にリクエストを途切れさせないためには、Pod が SIGTERM を受けてから処理中のリクエストを完了して終了する動作が必要です。 アーキテクチャ概要 図 1: システムのアーキテクチャ システムを構成する主なサービスは次のとおりです。 役割 サービス 静的コンテンツの配信 Amazon CloudFront → Amazon S3 API の経路 Amazon CloudFront → Amazon API Gateway → Application Load Balancer（ALB）→ Pod コンテナの実行基盤 Amazon EKS Auto Mode（プライベートサブネットに配置） データストア Amazon Aurora、Amazon ElastiCache for Valkey 認証基盤 Amazon Cognito クラスタは閉域で、ノードからインターネットへの直接の経路はありません。外部向けの通信は Squid によるプロキシを経由し、AWS の API へは VPC エンドポイントを通じて到達します。 EKS Auto Mode に内蔵された Karpenter がノードを起動する単位である NodePool は、用途別に 3 つ用意しました。API を載せる NodePool はインスタンスタイプを m5.xlarge に固定しています。ほかにバッチ用と、監視系のコンポーネントを載せるシステム用の NodePool があります。インスタンスタイプを固定した理由は後述します。 クラスタ内のコンポーネントは、管理主体ごとに次のように分かれます。EKS Auto Mode への移行により、VPC CNI や CoreDNS などのコンポーネントは AWS の管理下に移りました。 管理主体 コンポーネント AWS（EKS Auto Mode の組み込み機能） VPC CNI、CoreDNS、kube-proxy、EBS CSI Driver、ロードバランサーの管理（AWS Load Balancer Controller 相当の機能） KDDI（EKS アドオンとして導入） metrics-server、kube-state-metrics、Prometheus Node Exporter、Fluent Bit KDDI（Helm チャートで導入） Prometheus、本稿で紹介する自作ツール 導入時の課題と対処：起動時の CPU スロットリング 課題は終了時ではなく起動時にあった 移行前に注力していたのは、終了時の対策でした。Graceful Shutdown に対応すればノードの入れ替えに伴う影響は抑えられるはずでした。検証環境に構築した新バージョンのクラスタでは、ノードの入れ替えが負荷の高い時間帯にも起こりうる前提で、Pod を入れ替えながら負荷試験を実施しました。すると旧バージョンのクラスタと同じ構成のまま、主要なサービスのスループットが半分近くまで落ち、ノードの CPU 使用率は上限に張り付いたままになりました（数値は後述の表にまとめています）。原因を調べると、問題は起動時にありました。これは EKS Auto Mode 固有の性能劣化ではありません。従来は人手で吸収していた Pod 配置の偏りが、無人のノード更新を前提にしたことで導入の障壁として表面化したものです。 API の Pod は CPU の request を 200m、limit を 2000m に設定していました。10 倍のオーバーコミットです。Kubernetes のスケジューラはリソースについては request の値を見て Pod を配置します。そのため、起動時の実際の CPU 需要を合計するとノードの容量を大きく超えるほどの数の Pod が、1 台に載ることがあります。Java アプリケーションは起動直後、JIT コンパイルとクラスロードで limit 近くまで CPU を使います。複数の Pod が同時に起動すると需要が容量を超え、limit に達したコンテナで CPU スロットリングが発生し、同居する Pod の間で CPU の競合も重なります。起動が遅れるだけでなく、同じノードで稼働中の Pod まで CPU を奪われ、通常のリクエストがタイムアウトします。 同じ事象は旧バージョンのクラスタでも発生していました。発生条件は再デプロイ時で、旧バージョンの負荷試験と同じです。EKS Auto Mode への移行時に変化していたのは、人が立ち会うかどうかだけでした。 移行前（マネージドノードグループ） 移行後（EKS Auto Mode） Pod が入れ替わる契機 再デプロイ（メンテナンス状態にして人が立ち会う商用作業） ノードの自動更新（時刻を問わない、無停止） 配置が偏ったとき 解消するまで再デプロイをやり直す やり直す人がいない 起動直後の CPU バースト メンテナンス状態を解除する前に収まる エンドユーザーのリクエストを受けながら発生する エンドユーザーへの影響 メンテナンス状態のため、配置の偏りや起動直後の CPU バーストの影響は及ばない 同じノードのほかのユーザーまでタイムアウトする可能性 本システムでは、Pod の配置を自動で適正化する仕組みがなければ EKS Auto Mode を導入できません。 これが最初の課題でした。 対処：既存の台数のまま Pod の配置を適正化する 図 2: Pod 配置の対策前と対策後 対策として、検討したものの採用しなかった選択肢と、その理由は次のとおりです。 選択肢 採用しなかった理由 CPU の request を limit と同じ値にする オーバーコミットは解消するが、商用環境で必要なノードの台数が大幅に増える PodDisruptionBudget Pod の退避の経路にしか効かず、起動時の集中は防げない NodePool の期限をずらす 1 ノードに同居する Pod のまとまりは分解できない 最終的に、ノードの台数を増やさず Pod の配置を適正化する方針を採用しました。具体的には、配置の制御を中心に次の対処を組み合わせました。 対処 内容 topologySpreadConstraints ノード間の分散を DoNotSchedule 、AZ 間の分散を ScheduleAnyway で制約 podAntiAffinity CPU 消費の大きいサービス A とサービス B の 1 ペアに限定し、同じノードに同居させない インスタンスタイプの固定 m5.xlarge に固定。大きいインスタンスを許容すると、ノードの容量で同居数を抑える設計が成り立たない ALB の slow start 起動直後のターゲットへのトラヒックを段階的に増やし、リクエストの集中を回避 ノード間分散の制約には、本構成では matchLabelKeys: pod-template-hash が必要でした。これがないと Rolling Update での更新時に新しい Pod が旧 Pod の載っているノードを回避し続け、 maxSurge: 1 の構成では置き場所がなくなって Pending のまま止まります。 負荷試験での効果検証 効果は、検証環境（m5.xlarge）での負荷試験で確かめました。この検証では原因を確認するため、CPU 消費の大きい 3 サービスを podAntiAffinity で 1 ノードあたり 1 Pod に隔離し、その分ノードを増やしています。表には、このうち商用環境で相互排他を適用したサービス A とサービス B の値を示します。 指標 移行前：Pod 手動入れ替え 移行後：Pod 入れ替え時・対策前 移行後：Pod 入れ替え時・対策後（検証用の隔離構成） サービス A の RPS 398 216 410 サービス B の RPS 167 92 179 ノードの CPU 使用率（最大） 85% 約 100% 72% スループットと CPU 使用率が移行前と同じ水準に戻り、原因が Pod の配置にあることを確認できました。商用環境では必要台数の増加を抑えるため、隔離の対象を 1 ペアに絞って適用しています。 ただし、オーバーコミットの状態そのものは変わっていないため、CPU スロットリングの発生頻度が下がった段階です。オーバーコミット自体が問題なのではなく、起動直後の CPU 需要が収まる前に Pod がリクエストを受け付けることが問題です。恒久的な対策は、起動直後の CPU 需要が収まってから Pod を healthy にすることだと考えています。この対応については「今後の展望」で触れます。 導入の効果 EKS Auto Mode の導入による一番の効果は、ノードの継続的な更新が運用の一部になったことです。ノードは最長 21 日の周期で、AWS が提供する更新済みの AMI へ入れ替わります。AWS が AMI を更新すると、Karpenter が設定との差異（Drift）を検知してノードを入れ替えます。この入れ替えは、Disruption Budget（中断の台数や時間帯を制限する設定）で許可したメンテナンスウィンドウ内で行われます。商用導入以降は、AMI の更新のたびに全ノードがその時間帯に入れ替わっています。AMI の更新がないまま有効期限が近づいたノードは、後述する node-rotation-controller が同じメンテナンスウィンドウで入れ替えます。ワーカーノード側の脆弱性への対応を求められても、「ノード OS は自動で更新されるため、原則として個別の作業は不要」と回答できるようになり、更新の計画と作業に充てていた工数がなくなりました。また、VPC CNI や CoreDNS などの基盤コンポーネントの更新を AWS に任せられるようになったこともメリットのひとつです。 移行前後の運用を比べると次のようになります。後半の 2 点は EKS Auto Mode そのものの効果ではなく、前述の Pod 配置の対処と、後述する node-rotation-controller によるものです。 項目 移行前（マネージドノードグループ） 移行後（EKS Auto Mode） ノードの更新 脆弱性対応のたびに人が計画し、メンテナンス状態にして夜間に作業 最長 21 日の周期で自動で入れ替え。週 1 回のメンテナンスウィンドウで無停止 ワーカーノードの脆弱性への対応 依頼のたびに影響を確認し、対象のミドルウェアだけを更新 「ノード OS は自動で更新されるため、原則として個別の作業は不要」と回答 基盤コンポーネント VPC CNI、CoreDNS、EBS CSI Driver などのバージョンの更新を自分たちで管理 AWS が管理 Pod の配置 再デプロイ時に偏りが出たら人がやり直し topologySpreadConstraints と podAntiAffinity で自動的に分散 ノードの入れ替え時刻 人が作業する時間帯 メンテナンスウィンドウにて実施（EC2 の中断イベントなどを除く） 導入後の運用課題：ノードの入れ替え時刻を制御する 導入後にも、ノードが入れ替わるたびに直面する課題がありました。この課題に対して筆者が開発したのが、後述する node-rotation-controller です。 失効による入れ替えは、時間帯を選べない EKS Auto Mode のノードには、OSS の Karpenter にはない上限があります。有効期限（ expireAfter ）と、失効後に Pod の退避を待つ猶予（ terminationGracePeriod ）の合計が 21 日以内でなければならず、ノードは必ず失効します。Karpenter はノードの中断を graceful と forceful に分けています。台数や時間帯を制限する Disruption Budget が効くのは、graceful な中断だけです。 中断の種類 Disruption Budget 該当する中断 graceful 効く（台数・時間帯を制限できる） Drift、Underutilized、Empty forceful 効かない（条件が成立すると Disruption Budget を待たずに開始） Expiration、Interruption 実際、AMI の更新に伴う Drift による入れ替えは、Disruption Budget のとおりメンテナンスウィンドウに収まっていました。一方、失効（Expiration）は forceful に分類されているため、時間帯を制限できません。前述のとおり、本システムでは Pod の起動時に CPU の需要が集中します。アクセスの多い日中にノードが入れ替わると通常のリクエストがタイムアウトするため、入れ替えの時刻を制御する手段が必要でした。 対処：失効の前に、メンテナンスウィンドウの中で先回りして置換する 図 3: 標準の失効と node-rotation-controller による置換の比較 ノードが失効を迎える前に、メンテナンスウィンドウの中で先回りして置換するカスタムコントローラを開発しました。これが node-rotation-controller です。各ノードについて、有効期限までにメンテナンスウィンドウがあと何回巡ってくるかを数え、残りの回数が指定値を下回ったノードを次のウィンドウで置換します。置換は新しいノードを先に用意してから古いノードを削除する方式（make-before-break）で、次の順に進みます。 置換に必要な容量を要求する placeholder Pod を作成する placeholder Pod が Pending になり、Karpenter が新しいノードを起動する 新しいノードが利用可能になったことを確認する 旧ノードを drain して Pod を移し、旧ノードを削除する この方式は、Karpenter が Pending の Pod に応じてノードを起動する NodePool を前提としています。置換中は一時的にノードが増えるため、NodePool の limits や EC2 のクォータには余裕を持たせています。 商用環境の設定は次のとおりです。コントローラのメンテナンスウィンドウと Karpenter 側の Disruption Budget は、同じ時間帯に揃えています。 設定 値 意味 expireAfter 500 時間 ノードの有効期限 terminationGracePeriod 1 時間 失効後に Pod の退避を待つ猶予。合計 501 時間（20 日と 21 時間）で、上限の 21 日に対して 3 時間の余裕 コントローラのメンテナンスウィンドウ 毎週 1 回 失効前の置換を実行する時間帯 Disruption Budget（ウィンドウ内） 同時に最大 1 台 graceful な中断の同時実行数を最大 1 台に制限 Disruption Budget（ウィンドウ外） 0 台 メンテナンスウィンドウ外は設定との差異（Drift）と低使用率（Underutilized）による中断を禁止。空ノードの削除（Empty）は常時、同時に最大 1 台まで許可 いつどのノードが入れ替わるかを事前に把握できるよう、置換予定をシミュレーションするツールもあわせて開発しました。 商用導入後の 1 か月は AMI の更新が続き、Drift による入れ替えで有効期限が更新されていたため、コントローラが置換を実行することはありませんでした。その後、AMI の更新が途絶えた期間に初めてコントローラが置換を実行し、メンテナンスウィンドウ内に API ノード全台の置換を完了しました。AMI の更新が再開してからは、Drift による入れ替えに戻っています。失効と Drift によるノードの入れ替えについては、メンテナンスウィンドウに収まる状態になっています。 今後の展望 まず、ログの保全を進めます。移行時点の EKS Auto Mode では kubelet のログローテーション設定を変更できず、1 コンテナあたり合計 50 MiB までしかログが保持されませんでした。そのため、ログの出力量が多い環境では、Fluent Bit が転送する前にログが破棄される恐れがあります。この制約に備えて、筆者はログファイルをハードリンクで退避し、転送の完了を確認してから削除する pod-log-preserver を開発しました。現在は限定的な範囲で検証しています。また、本プロジェクト完了後の 2026 年 10 月のアップデートで、NodeClass の advancedCompute.kubelet.logging から、ログローテーションのサイズと世代数を変更できるようになりました。こちらもあわせて導入を検討していきます。 Pod のオートスケールの導入と、それにあわせたリソースの最適化にも取り組みます。Karpenter は、Pod のリソース要求に応じてノードの台数を自動で決めます。Pod のオートスケールを導入すれば、増減するトラヒックにノードの台数を追随させられます。Karpenter の機能を活かせる次の領域です。あわせて、起動直後の CPU 需要が収まってから Pod を healthy にする対応を、アプリケーション側と進めます。 node-rotation-controller は、本システムのメンテナンスウィンドウの要件を EKS Auto Mode の現時点の機能に合わせて補うものです。失効の時間帯を標準機能で制御できるようになれば、構成を見直す予定です。 まとめ EKS Auto Mode では、人が立ち会うことを前提にした運用は成り立ちません。ノードは無人の時間帯に入れ替わり、Pod の配置のやり直しも、入れ替え時刻の選択も、人の手には戻ってきません。だからこそ、それらを自動で行う仕組みを自分たちで用意する必要がありました。Graceful Shutdown への対応はアプリケーション側と進め、Pod の配置と入れ替え時刻の制御はインフラ側で補いました。その結果として得られたのが、ノードの継続的な自動更新による運用工数の削減と、ワーカーノードのセキュリティの担保です。EKS Auto Mode の導入を検討されている方、とくにエンタープライズでアプリケーションとインフラを複数のチームで分担して開発されている方の参考になれば幸いです。 著者について 西 総一朗 KDDI 株式会社 コア技術統括本部 情報システム本部 DX システム 2 部 フロント SRE グループ 2024 年に KDDI に入社し、通信事業のお客さま向けサービスを支える AWS 上のインフラの設計・構築・運用に従事しています。本事例では EKS Auto Mode への移行と、node-rotation-controller および pod-log-preserver の開発を担当しました。著者の写真は、AWS re:Invent 2025 参加時に、米国ラスベガスで撮影しました。

数週間前、サンパウロにある AWS オフィスで、ブラジルの農業関連ビジネスに携わるビジネス部門と技術部門のリーダーからなる少人数のグループに向けて講演を行いました。私の講演では、農業関連ビジネスの各業務段階において生成 AI がどのような役割を果たすのかを一通り紹介しました。そして何度も立ち返ったのが、伝統的とされる市場だからこそ、この技術の進化に対応し続けられるかどうかで、最終的に誰が時代の先を行くかが決まるという考えです。参加者の誰も、そもそも農業に AI を導入すべきかどうかという点を問題にはしていませんでした。問われていたのは、出力結果の提供方法です。誰に、何語で、どのデバイスに届けるのか。そして、その受け手は農場から別の農場へ車で移動していることも少なくありません。こうした背景から、普段なら通常のリリースの 1 つとして扱っていたかもしれない発表を、今週の注目ニュースの最初に取り上げることにしました。 Amazon Polly の生成エンジンがアップグレードされ、ブラジルポルトガル語の 2 種類を含む、14 種類の新しい音声が追加されました。ユーザーが運転中で両手をハンドルから離せない状況では、音声そのものがインターフェイスになります。 サンパウロにある AWS オフィスで「GenAI no Agronegócio Brasileiro」というタイトルの講演を行っている様子。 一方、2026 年 10 月 26 日週のその他のニュースには、より緊迫した話題が並びました。10 月 26 日週最大のリリースは、脆弱性が公表されてから悪用されるまでの猶予期間が実質的に消滅したことを前提とするセキュリティサービスです。さらに AWS は、その状況を裏付けるハニーポットの観測データを同じ週に公開しました。それでは、10 月 26 日週の AWS ニュースを詳しく見ていきましょう。 AWS Continuum for code vulnerabilities の一般提供を開始 AWS Continuum は、脆弱性管理を、検出結果のリストを渡すだけのスキャナーによる作業ではなく、エンドツーエンドで実施する一連のプロセスとして位置づけています。リポジトリと AWS 環境からコンテキストグラフを構築し、各検出結果に証拠レベルを割り当てます。さらに、悪用可能な問題を概念実証コードを使って分離されたサンドボックス内で再現するため、単なる重大度のラベルではなく、問題そのものを確認できます。攻撃経路がビジネス上重要なシステムにどれだけ近いかに基づいて問題に優先順位を付け、その後、修正内容をプルリクエストとして提出します。重要なのは、制御の境界が明確になっていることです。現時点ではすべての修復に人間の承認が必要なため、プルリクエストを確認してマージするのはユーザーです。将来的に特定の種類の修正を自律的に実行する場合も、信頼度のしきい値を満たすことが条件となります。 このサービスが今必要とされる理由は、同じ週に AWS が運用するハニーポットによって明らかになりました。Amazon Threat Intelligence は、CVE-2026-109618 と CVE-2026-109619 が一般公開される 4 日前の 10 月 17 日付の MadPot テレメトリデータから、PHP2Shell の悪用を試みた形跡 を発見しました。また、脆弱性の公開当日には、情報公開の制限が解除される予定だった UTC 14:00 の約 12 時間前に当たる UTC 02:00 頃から、概念実証用のエクスプロイトが出回っていました。実務上の教訓は明白です。パッチ適用までの猶予を日数単位で考えることは、もはや存在しない時間的余裕を前提としています。また、調査は脆弱性の公開日ではなく、確認されている最も早い悪用時点を起点として始めるべきです。AWS は、これらの CVE に対応する AWS WAF の緩和策 も公開しました。Continuum は、米国東部 (バージニア北部) および米国西部 (オレゴン) リージョンで利用できます。 Amazon ECS Gateway のご紹介 Amazon ECS Gateway は、サービスを外部に公開するための作業を、ネットワークの管理担当者とアプリケーションの管理担当者の間で分担できるようにします。プラットフォームチームは、組織のサブネット、セキュリティグループ、TLS 証明書、リスナー設定、AWS WAF ウェブ ACL を使用して、1 つのゲートウェイを定義します。アプリケーションチームは、サービス定義にゲートウェイコネクタを追加することで、この機能の利用を選択できます。すると ECS によって、ACM 証明書、一意の DNS ホスト名、リスナールール、ターゲットグループ、Application Load Balancer からのトラフィックのみを許可するセキュリティグループが提供されます。 具体的な数値を見ると、コスト効率の高さがわかります。最大 25 のサービスで 1 つの ALB を共有でき、ECS は初回接続時に最初の ALB をプロビジョニングし、不要になった ALB は削除します。また、1 つのゲートウェイに最大 10,000 のクラスターを関連付けることができ、各クラスターには最大 5 つのゲートウェイを設定できます。既存のロードバランサーをそのまま維持しながら、UpdateService を使用して段階的に導入できます。Amazon ECS Gateway は、Amazon ECS を利用できるすべての商用リージョンで、追加料金なしで提供されています。 10 月 19 日週のリリース 10 月 26 日週、私が特に注目したリリースをいくつかご紹介します。 Amazon Polly の Generative エンジンが大幅にアップグレード – 生成エンジンで利用できる音声のラインナップが拡充され、表現力も向上しました。現在は 11 言語、25 ロケールに対応する 57 種類の生成音声を利用できます。今回、9 ロケールで 14 種類の新しい音声が追加されたほか、ヒンディー語とフィンランド語の一般提供が初めて開始されました。新しい音声のうち 2 種類は、ブラジルポルトガル語の Leo と Carolina です。既存の実装を変更せずに適用できるアップグレードのため、音声名、SynthesizeSpeech の呼び出し方法、料金はすべてそのままで、より自然な音声出力が得られます。 AWS が TorchNeuron を発表: AWS Trainium で PyTorch をネイティブサポート (パブリックベータ) – TorchNeuron はオープンソースの PyTorch バックエンドです。コードを書き直すことなく、設定を `.to(‘neuron’)` に変更するだけで、Eager 実行と `torch.compile` をそのまま利用しながら、Trainium 上でモデルを実行できます。カスタム演算子向けの Neuron Kernel Interface と統合されており、Trainium2 および Trainium3 インスタンスで動作します。ハードウェアの選択によってソフトウェアが特定の環境に固定されるべきではない理由を、より広い視点から理解したい場合は、 そのテーマを扱った AWS Insights の記事 も併せて読むことをお勧めします。今回のリリースは AWS Neuron 2.33 と同時に公開されました。 GPU を管理せずに Amazon SageMaker AI でモデルをカスタマイズする新たな方法 – トレーニングセッションの一般提供が開始されました。カスタム損失関数や報酬シグナルを含む事後学習のループをユーザーが制御できる一方、GPU の割り当て、分散実行、障害からの復旧、チェックポイントの保存は SageMaker AI が処理します。料金は SageMaker AI が処理したトークンに対して発生し、報酬関数がバッチを評価している間は課金が停止します。 詳細な技術ウォークスルー と トレーニングセッション API が公開されているほか、 Muse Glimmer、Qwen 3.8、Ministral 3 の新たなサポートも提供されています。 Amazon Bedrock の Claude モデルで構造化出力が利用可能に – Amazon Bedrock 上のすべての Anthropic Claude モデルから、指定したスキーマに準拠する JSON を取得できるようになりました。bedrock-runtime と bedrock-mantle の両エンドポイントに対応しており、独自の解析処理、再試行ロジック、後処理は必要ありません。これにより、財務レポートから必要なすべての項目を抽出する作業、診療記録の解析、問い合わせ内容の意図に応じたサポートチケットの振り分けなどを、はるかに高い信頼性で自動化できます。 Amazon ElastiCache Serverless for Valkey がダウンタイムゼロのオンライン移行に対応 – Amazon EC2 上で自己管理している Valkey または Redis OSS を、ダウンタイムなしで ElastiCache Serverless に移行できます。ここでいうダウンタイムゼロとは、ElastiCache の SLA における可用性の測定方法に従い、移行中にクライアントへ返されるエラーがゼロであることを意味します。移行の準備を行い、データ同期を開始した後、手動または自動の切り替えを選択するだけで、サードパーティー製のレプリケーションツールは必要ありません。この機能は、すべての商用リージョン、中国リージョン、AWS GovCloud (米国) リージョンで利用できます。 AWS のその他のニュース このほかにも、皆さんの興味を引きそうなプロジェクトや記事をいくつかご紹介します。 AWS Agent Registry を使用して実行時にツールを検出 – AWS Agent Registry は、MCP サーバー、エージェント、エージェントスキルを管理するカタログサービスです。これにより、オーケストレーターはビルド時にすべてのツールを組み込む代わりに、実行時に承認済みの機能を検索できます。このウォークスルーでは、実際に動作するサンプルを使って、検出、インスタンス化、実行という一連の処理を説明しています。検索結果には接続用のメタデータが返されますが、呼び出しに必要な認証情報が返されることはありません。 コーディングエージェントのトークンエコノミクス: 自分のコードを使用してコストと品質をベンチマーク評価 – コーディングアシスタントは、やり取りのたびに蓄積されていく会話履歴を再処理するため、コストの計算方法が通常の推論とは大きく異なります。この記事では、独自のリポジトリを使用してモデル、ハーネス、ホスティングの選択肢を評価し、コストと品質のトレードオフを示す独自のフロンティアを構築するためのオープンソースツールを紹介しています。サンプル結果では、ルーティングによって平均品質が 4.8% 低下する一方、コストは 44.7% 削減されました。 U.S. Bank が 119 TB のデータを Oracle Exadata から Amazon RDS for Oracle に移行した方法 – U.S. Bank は、Oracle XTTS、AWS DataSync、Amazon EFS を基盤とする設定駆動型のパイプラインを使用して、合計約 119 TB に及ぶ 4 つの Oracle Exadata データベースを Amazon RDS for Oracle に移行しました。帯域幅が制限された Direct Connect 接続を使用しながら、最初のベースラインコピーはデータ損失ゼロで約 7 日間で完了し、切り替えに要した時間はデータベース 1 つ当たり平均約 4 時間でした。 今後開催される AWS イベント 今後開催される以下のイベントを、ぜひカレンダーに登録しておいてください。 AWS re:Invent – AWS re:Invent は、11 月 30 日から 12 月 4 日までラスベガスで開催され、2,200 以上のセッションが予定されています。セッションカタログが公開され、座席の予約も受け付けていますので、今こそ参加スケジュールを立てる絶好のタイミングです。 AWS Community Days – AWS Community Day Brasil Norte は 10 月 31 日にベレンで開催され、2026 年のブラジルにおけるコミュニティイベントシーズンを締めくくります。お近くで開催されるイベントについては、イベントハブをご確認ください。 10 月 26 日週のニュースは以上です。11 月 2 日週も、Weekly Roundup をぜひご覧ください! – Daniel この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します! 原文は こちら です。

2026 年 10 月 22 日、 AWS Continuum for code vulnerabilities の一般提供の開始についてお知らせします。AWS Continuum は、コードの脆弱性を検出して検証し、修正を自動化できるパッチとして、さらにリポジトリのプルリクエストとして提供できるセキュリティサービスです。AWS Continuum for code vulnerabilities は、お客様の環境でどの検出結果が悪用可能であるかを確認し、発生した問題をビジネスへの影響に基づいてランク付けし、それぞれの修正を提案します。すべての修正作業は、Continuum が修正案を提示し、リリース前に担当者が承認するモードで開始されます。今後は、定義したガードレールの範囲内で、Continuum が独自に実行できるアクションを決定できるようになります。 最先端の人工知能（AI）モデルを利用することで、脅威アクターは脆弱性の情報公開からわずか数分で実際に動作するエクスプロイトコードを作成できます。また、開発を加速させる同じツールによって、チームが処理しなければならない脆弱性の検出結果も増加しています。大規模なアプリケーション群を運用している組織では、脆弱性スキャナーによって1日に数千件の検出結果が生成され、その多くは対応が不要なものであると考えられます。検出結果は、到達不能である、悪用不可能である、またはランタイムの制御機能によってすでにリスクが軽減されている場合があります。一般的な深刻度スコアでは、脅威アクターが実際にどのリソースにアクセスできるかは分かりません。そのため、開発環境でのみ使用されるユーティリティの「重大」スコアが、決済データベースにあと一歩で到達できるサービスの「中」スコアと同じように扱われてしまいます。これまでは、検出結果が悪用可能かどうかを確認するために、何時間もの手作業による調査が必要でした。また、安心して修正をリリースするには、セキュリティ、インフラストラクチャ、アプリケーションの各チーム間で数日かけて調整する必要がありました。これは、ビジネス上の背景情報がなければ、変更による影響範囲を評価することが難しいためです。このギャップを埋めるため、Continuum は、どの検出結果が実際に悪用可能であるかを実証し、提案する各修正によるリスクの範囲を明確にします。 Continuum は、主にコードリポジトリと AWS 環境という2つの情報源から、コンテキストグラフを構築します。AWS の場合は、コードが実行されるアカウントとリージョンにコレクターを設定します。コレクターは、AWS Config リソースやネットワーク設定などのリソースの詳細を収集し、Continuum がネットワーク経由で脆弱性に到達できるかどうか、また脅威アクターがそこからアクセスできる脆弱性は何かを判断できるようにします。このグラフを通じて、Continuum は、どのシステムがビジネス上重要なのか、各システムの担当者は誰か、サービス間にどのような依存関係があるのか、また、各サービスがどのデータを取り扱うのかを把握します。Continuum は、この全体像を基に、顧客データストア、決済処理パイプライン、認証サービスなど、特に重要度の高いシステムを特定し、検出された各問題について、攻撃経路がこれらのシステムにどれだけ近いかに応じて優先順位を付けます。 Continuum は、検出結果をコードとその実行環境のコンテキストに照らして分析し、証拠レベルを割り当てます。例えば、脆弱なコードパスの静的解析によって裏付けられた判定などが含まれます。Continuum は、再現可能な検出結果について、隔離されたサンドボックス内でエクスプロイトを実行し、再現手順とともに概念実証コードを添付します。リスクスコアのみだけではなく、攻撃経路、裏付けとなるソース分析、爆風半径評価を生成します。また、既存の防御が検証済みのパスを検出して停止するかどうかも評価します。 Continuum は確認された問題ごとに、修正 (コードパッチ、依存関係のアップグレード、または設定変更) を生成し、それを接続されたリポジトリでプルリクエストとして開き、レビューできるようにします。すべての修正には人による承認が必要です。担当者がプルリクエストをレビューしてマージするため、最終的な判断はチームに委ねられます。将来的には、特定の修復クラスへの信頼度を高め、Continuum が信頼度ゲートを通過したら、テストカバレッジ、スコープの範囲、過去の成功率などの修正を自動的に適用できるようになります。 AWS Continuum for code vulnerabilities の実施 これがどのように機能するかを示すために、コンソールで AWS Continuum を開き、 コードの脆弱性 に移動します。課題を確認する前に、環境を設定します。コードソース (GitHub インテグレーションまたは Amazon S3 バケット) を接続し、選択したスケジュールでそれをスキャンする環境を作成します。Amazon S3 ソースにはいくつかの前提条件があります。バケットが AWS Continuum をオンにしたのと同じアカウントと AWS リージョンにあることと、AWS Continuum が引き受ける AWS ID およびアクセス管理 (IAM) ロールを通じてアクセスを許可することです。オプションで、コードが実行されるアカウントとリージョンに AWS Continuum コレクターを設定し、その使用を環境に許可することで、AWS インフラストラクチャコンテキストを追加できます。すべての要件とステップについては、AWS Continuum ユーザーガイドを参照してください 。 概要ページでは 、これらの要素が 1 か所にまとめられ、 コード統合 、 その上に構築された環境 、AWS リソースコンテキストを提供するすべての AWS コレクターのステータスが表示されます 。 環境の 1 つを開きます。 問題 タブに、未処理のスキャナー出力ではなく、検証済みで優先順位が付けられた問題が、それぞれ重要度、ステータス、および作成された時間とともに表示されます。その中から一つを選びます。 概要 では重大度が「高」と評価されており、ステータスは「 完了 」で、修正は既に GitHub に配信されています 。 リスクアセスメント はその理由を説明しています。Continuum はその 悪用可能性 を「 悪用可能 」と評価しており、エビデンスレベルは「 静的検証済み 」、検証実行ステータスは「 完了 」となっています。このサービスは攻撃者からアクセス可能で、認証が不要であり、ユーザーによる操作も必要としないため、 悪用される可能性 は「 高 」と評価されます。 影響 は 中程度 です。つまり、攻撃者はビジネスデータを変更できるようになり、その影響範囲は同じテナント内の他のユーザーにまで及ぶことになります。 プルーフ セクションには、判定の背後にあるソース分析が含まれています。 修正 セクションには、すでに GitHub でプルリクエストとして配信された修正が表示され、カートサービス全体で 50 行が追加され、24 行が削除された 4 つのファイルが変更されています。Continuum は Continuum fix というタイトルのプルリクエストとして修正を開き、私は [ プルリクエストを表示 ] を選択して GitHub で開きます。コンソールには、生成されたパッチが問題の修正を意味するものではないことが明記されています。今もレビューして統合するので、最終的な決定はチームに任せています。 関連する検出結果 セクションには、この問題の発生元となった特定のスキャナーが一覧表示されます。 プルリクエストの説明には、同じリスク評価、修復要約、およびコンソールからの証拠が記載されているため、GitHub でレビューした人は誰でも、ワークフローを離れることなく証拠を確認できます。 検出結果 タブには、環境全体にわたる未処理のスキャナー結果、つまり問題の発生元となった証拠が表示されます。 スキャン タブには、各スキャンの履歴とそのステータス、起点、リクエストおよび完了時間が表示されます。 スキャン頻度の設定を使用してケイデンスを変更するか 、 スキャンをキューに追加する を使用してオンデマンドで実行します。 設定 タブでは、環境を管理します。読み込むコードとコンテキストソース、コードの統合、Continuum が修復パッチを作成するかどうかなどの環境設定、AWS コンテキストに使用する AWS コレクターなどです。 1つのワークフローで、スキャンするたびに検証済みの問題を優先順に処理し、それぞれの背後にある証拠と範囲を確認してから、信頼できる修正を承認して統合します。すべての修正は私の承認を待っているので、バックログは減り続け、チームはリリース内容の管理を維持できます。 今すぐご利用いただけます AWS Continuum for code vulnerabilities は、10 月 22 日、米国東部 (バージニア北部) および米国西部 (オレゴン) リージョンでご利用いただけます。価格については、 料金ページ をご覧ください。 詳細については、 AWS Continuum for code vulnerabilities 製品ページ と ユーザーガイド をご覧ください。今すぐ AWS Continuum コンソールで試してみて、通常の AWS サポートの連絡先からフィードバックをお寄せください。 – Esra 原文は こちら です。

本記事は、合同会社 BrightFlow 代表社員の池田 健人様による寄稿記事です。 はじめに みなさん、こんにちは。合同会社 BrightFlow 代表の池田です。AWS Community Builder（DevTools 領域）として、2021 年から活動しています。 BrightFlow は、外部 CTO や技術顧問として企業の開発を支援しながら、自社プロダクトの開発にも取り組んでいます。プロダクト開発では、AI を全面的に活用しているだけでなく、開発の進め方そのものも実験的に試しています。開発の過程で得られた知見を、このように記事として発信することも、その試みの一つです。 AI エージェントにコードを書かせ、プルリクエスト（PR）を作らせることは、もう特別なことではありません。任せる範囲が広がるほど、問われるのはモデルの性能よりも「境界」です。 誰がタスクを決め、誰が書き込みを要求でき、誰が実際に書き込むのか エージェントが「完了しました」「テストが通りました」と言ったとき、何をもって事実とみなすのか 何をレビューし、何をマージしたのかを、後から確かめられるか AI エージェント同士を組み合わせること自体は、いまではさまざまな方法で実現できます。2 つのコーディングエージェントを対話させる方法もあれば、Kiro のように公式の機能で複数のエージェントを段階的に動かす方法もあります。本記事が扱うのは、組み合わせ方そのものではありません。組み合わせた AI に書き込みを任せるとき、誰が権限を持ち、どこまで変更してよく、何を条件にマージするのか、という境界の置き方です。 私は、自社プロダクトの開発のために、Kiro CLI を実装役とする仕組み（以下 BRIDGE）を作り、約 1 か月運用しました。本記事では、BRIDGE を作ったきっかけ、その構成と 4 つの境界、運用で分かったことを紹介し、最後に 2026 年 10 月時点の Kiro の標準機能と比較します。 注: 本記事で紹介する構成は私の環境のもので、AWS が推奨する構成ではありません。利用条件については記事末尾を参照してください。 1. なぜ BRIDGE を作ったのか BRIDGE を作り始めたのは 2026 年 8 月末です。この時点で、クラウドで自律的に作業する Kiro Web （2026 年 5 月 7 日にプレビュー公開）と、セルフホストで常駐させる Kiro Crew （2026 年 8 月 4 日に公開）は、すでに公開されていました。公式機能では技術的に不可能だったから自作した、というわけではありません。 自作を選んだのは、次の 3 つの使い方を先に決めていたためです。 異なる 2 つの AI の長所を組み合わせて、チームとして動かしたい。 人間の開発チームが設計担当と実装担当で役割を分けるように、計画とレビューを担う AI と、実装を担う Kiro を組み合わせたいと考えました。簡易的なオーケストレーションです。計画役の AI には、その AI に追加したアプリやコネクタを通じて、ドキュメントやチケット、Web 上の情報など、リポジトリの外にある情報を集めてもらいます。それを踏まえて整理した依頼を、実装の得意な Kiro に渡す、という分担です。計画役の AI は、MCP に対応したものであれば差し替えられるようにし、特定の製品に縛られない形にしました。 人が見るべきところは見続け、それ以外は任せて効率化したい。 方針の判断や、AI が迷って止まった場面には人が関わり、それ以外の定型的な流れは、AI のレビューを経てマージまで進める運用を想定しました。 想定どおりの変更はそのまま進め、想定外の変更が起きたら止めたい。 変更するファイルが依頼の内容から明らかな作業は、確認を待たずに進めて構わないと考えました。一方で、想定していないファイルにまで変更が及んだときは、自動で進めずに止めて確認したいと考えました。 1 つ目の使い方は、境界が必要になる理由そのものでもあります。計画役の AI が外部のアプリから集めた情報は、私が中身を管理できない入力です。その情報をもとに書かれた依頼で Kiro が動く以上、依頼の内容に関わらず、書き込める範囲とマージの条件をシステムで決めておく必要がありました。 2 つのエージェントを手元で対話させるだけであれば、仕組みを作る必要はありません。ただしその場合、両方のエージェントが同じ環境で、同じ資格情報を使うことがほとんどです。私が必要としたのは、計画役の AI には書き込みの資格情報を渡さず、書き込みの経路と条件を、システムで決めておく仕組みでした。本記事では実装役に Kiro を使いましたが、この考え方は、組み合わせるエージェントが何であっても変わりません。 2. BRIDGE の構成と、4 つの境界 全体の構成 BRIDGE は、チャット側の AI から接続する MCP（Model Context Protocol）サーバーと、その背後で実装を担当するコントローラーで構成しています。 チャット側は、MCP のリモートサーバーに接続できるクライアントであれば、原理的には何でも構いません。ChatGPT のカスタム MCP アプリや Claude のカスタムコネクタなど、選択肢は複数あります。私が実際に使ったのは ChatGPT で、本記事の数値や障害事例はすべて ChatGPT から利用したときのものです。 図 1：構成と境界。GitHub と Kiro の資格情報を持つのは Dev Controller だけです。 Kiro との接続は 2 通りです。READ 経路では、Agent Client Protocol（ACP）で Kiro のセッションを開き、リポジトリの設定ファイル（Steering）を読み取らせるだけです。WRITE 経路では、Kiro CLI を headless モードで実行し、出力を stream-json 形式で受け取ります。BRIDGE では、Kiro CLI 2.21 系（V2 エンジン）を使っています。 依頼からマージまでの流れは、次のとおりです。 図 2：依頼からマージまでの流れ。 人がどこで関与していたか 作業の開始と判断 : 作業は私がチャットで依頼して始めていました。その後は AI がツールを続けて呼び、AI が止まったときや判断が必要な場面で、私が指示を出します。 書き込みの実行 : チャットの実行確認は、「常に許可」に設定していました。何でも任せるために確認を外したわけではありません。後で説明する境界をシステムに作り込んでいたので、確認を外しても、AI が要求できることは変わらないからです。書き込めるのは依頼ごとに宣言した範囲だけで、実行はサンドボックスの中に限られ、マージできるのは指定した HEAD の PR だけです。操作のたびに人が判断する代わりに、システムで境界を強制することで、AI に任せる自由度と安全性のバランスを取りました。その一方で、変更の中身が正しいかどうかは、AI のレビューと検証に任せていました。この部分は、第 3 章の教訓 4 で振り返ります。 利用した機能 : チャット側はクライアントが提供しているカスタム MCP の接続機能を、Kiro 側は公式の Kiro CLI を使っています。 境界 1: 資格情報を渡さず、要求できる操作を固定する エージェントに書き込みを任せるとき、最初に決めるべきなのは「書き込みの資格情報を誰が持つか」です。GitHub のトークンやクラウドの認証情報をエージェント自身が持つと、指示の解釈次第で、どこにでも書き込めてしまいます。ただし、資格情報を持たないことは、書き込みができないことと同じではありません。要求できる操作の種類と引数まで固定して、初めて境界になります。 BRIDGE では、チャット側の AI は、GitHub のトークンも Kiro の API キーも持ちません。持っているのは、5 つのツールを呼ぶ手段だけです。 ツール 経路 役割 inspect_app READ リポジトリの状態の確認 inspect_pr READ PR のメタデータと差分の取得 execute_dev_task WRITE 開発タスクを Kiro に委譲し、検証を通過したら PR を作成 merge_pr_and_sync WRITE 指定した HEAD SHA と一致する場合だけマージし、同期 inspect_dev_task WRITE タスクの実行状態を確認 書き込み先のリポジトリ、base のブランチ、マージの方法はサーバー側で固定し、チャット側からは指定できません。 READ と WRITE は、URL、OAuth の scope、チャット側の接続設定（READ 用と WRITE 用で別のアプリ）の 3 つのレベルで分けました。URL には、READ と WRITE で別々の秘密値を含めています。ただし、この秘密値は認証の代わりではありません。ツールの実行には、常に OAuth の認証が必要です。URL の秘密値は、それ以外のパスへのリクエストをすべて 404 にして、外部から見える範囲を狭めるための補助です。URL に秘密値が含まれるので、アクセスログも記録していません。 境界 2: 変更してよい範囲を先に決め、終わった後に照合する 「このファイル以外は触らないでください」という指示は、守られることを期待するものであって、保証ではありません。変更してよい範囲を機械が読める形で先に決め、作業後の差分と照合する必要があります。 BRIDGE では、 execute_dev_task を呼ぶとき、チャット側の AI に、指示文と一緒に、どのファイルを作成・変更・削除してよいかを宣言させます。 { "taskId": "example-task-001", "baseCommit": "<40桁のコミットSHA>", "instruction": "…", "verifierProfile": "test", "changePolicy": { "allowedChanges": [ { "path": "app/src/example.ts", "type": "modify" }, { "path": "app/src/example.test.ts", "type": "create" } ] } } Kiro の実行後、Dev Controller は作業領域の差分を実際に観測し、宣言にない変更が一つでもあればタスクを失敗とします。想定どおりの変更はそのまま次に進み、想定外の変更が起きたときだけ止まる、という第 1 章の使い方を、この照合で実現しています。 境界 3: 書き込みを止めるのは、エージェントの申告ではなく実行環境 エージェントは、自分が何をしたかを出力します。しかし、その出力を見て書き込みを判定すると、出力形式の変化や想定外の操作に対して判定が漏れます。出力は後から確かめるための記録として扱い、書き込みの上限は実行環境（サンドボックス）で決めます。 BRIDGE では、Kiro CLI のプロセス全体を、Linux の bubblewrap と seccomp によるサンドボックスの中で動かしています。そのため、シェルコマンドだけでなく、Kiro の組み込みのファイルツールによる書き込みも、OS のレベルで使い捨ての作業領域に限定されます。サンドボックスを用意できない環境では、Kiro を起動しません。Kiro に事前許可するツールは read 、 grep 、 glob 、 write だけで、シェルの実行は許可していません（いずれも Kiro CLI 2.x 系のツール名で、V3 では read_file や grep_search などに名前が変わっています）。stream-json の出力は記録しますが、書き込みの判定には使いません。 なお、BRIDGE で使っていた Kiro CLI（2.21 系）には、後述する Kiro のローカルコマンドサンドボックスはまだありませんでした。 境界 4: 何をレビューし、何をマージしたかを固定する PR はレビューの後でも更新されます。マージするときには、少なくとも「レビューした PR の HEAD」と「マージする PR の HEAD」が同じであることを確かめる必要があります。さらに、マージ先のブランチが進んでいれば、マージ後の状態はレビュー時と変わります。 BRIDGE では、マージの要求で、チャット側が指定できるのは PR 番号と、レビューしたときの HEAD SHA（ expectedHeadSha ）だけです。Dev Controller は PR を取得し直し、BRIDGE が作成した PR であること、draft でないこと、GitHub が競合なしと判定していることを確認したうえで、GitHub のマージ API に sha として expectedHeadSha を渡します。HEAD が動いていれば、GitHub がマージを拒否します。GitHub 上の承認を使わず、AI のレビュー結果に基づいてマージするため、branch protection の承認に関する設定の代わりに、HEAD SHA の一致を BRIDGE 自身で確認しています。 マージの後はサーバー上のリポジトリを同期し、 main の最新 SHA とマージコミットの到達可能性を返します。「マージは成功したが同期に失敗した」状態は、「マージされていない」と区別して返します。呼び出し側の AI が誤解して、同じ操作を繰り返さないためです。 マージと同期を一つの手順にまとめたのは、運用を始めた直後の出来事がきっかけです。GitHub 上で PR をマージした後、サーバー上のリポジトリが古いままになり、次のタスクが古いコミットを基準に作業を始めてしまいました。このタスクは、PR を作る段階で基準のずれが検出されて止まりました。この経験から、マージと同期を分けずに、一つの手順として扱うようにしました。 規模 BRIDGE は約 49,000 行の TypeScript になりました（約半分がテスト）。書き込みの各段階（作業領域の作成、サンドボックスでの実行、変更範囲の照合、成果物の固定、検証、PR 作成）で、前の段階の結果を信用せずに独立して確認する設計にしたためです。 3. 1 か月運用して分かったこと この章では、まず作成された PR の集計結果を示し、そこから得た教訓と、運用中に実際に発生した障害を紹介します。 3.1 PR の集計結果 BRIDGE を使って開発した、自社プロダクトのリポジトリの PR を、運用を始めてから約 1 か月分集計しました。 状態 件数 マージ 317（約 51%） クローズ（未マージ） 159（約 25%） Open 148（約 24%） 約半数がマージされていません。未マージの 307 件を一件ずつ調べると、その多くは「レビューで不採用になった PR」ではありませんでした。 未マージの理由 件数 PR 全体に差分が無い 122 疎通確認用の PR 9 マージ済みの PR と内容が同一 2 同じ作業の後続の PR がマージ済み（※1） 37 集計時点の main と競合する 81 集計時点の main に適用できるが、未マージ（※2） 56 合計 307 集計期間：2026 年 9 月 11 日〜10 月 12 日（2026 年 10 月 12 日時点の状態）。上の行から順に判定し、最初に当てはまった理由で数えています。 ※1 PR の名前から判定した推定を含みます。 ※2 うち約 20 件は、調査結果をファイルに書き出しただけと見られる PR です（ファイル名からの推定）。 差分が無い、疎通確認用、内容が同一、後続がマージ済みの PR を合わせると 170 件で、未マージの半数以上は、もともとマージする必要の無い PR でした。 BRIDGE の PR は、作成時の base を親とする 1 コミットで構成されます。差分の有無は、このコミットと base の tree の比較と、GitHub が返す PR 単位の変更ファイル数の両方で確認しました。 3.2 運用から得た教訓 集計結果から得た 4 つの教訓と、それぞれの解決方法を紹介します。 教訓 1: 書き込みの経路しかない作業は、書き込みの経路で行われる READ 経路の inspect_app が返せるのは、リポジトリの状態と設定ファイルの確認結果だけでした。コードを読んで質問に答える経路はありません。そのため、チャット側の AI は照合・監査・確認のようなタスクにも execute_dev_task を使いました。Kiro が何も変更せずに終わると、変更の無い PR ができます。調査結果をテキストファイルとしてリポジトリに書き出す PR も作られました。 この間も、境界そのものは破られていません。調査のためのタスクも、宣言した変更範囲とサンドボックスの中で実行され、許可していない書き込みは起きていません。問題は、読み取りの経路が足りなかったために、本来は書き込み用の経路が調査にも使われ、変更の無い PR や調査結果だけの PR が増えたことでした。 書き込みを厳しく絞るほど、読み取りの経路を広く用意しないと、書き込みの経路が調査に使われます。 解決方法 : 調査や確認を、読み取りだけで完結する経路に分けることで解決できます。Kiro であれば、ソースを変更せずに調査してレポートを返す Workflows の investigate や、書き込みを許可しない Permissions の設定が、この役割を担えます。調査の結果はリポジトリに書き出さず、レポートとして受け取る形にするのがポイントです。 教訓 2: PR の作成を完了の条件にすると、PR が入出力のチャネルになる BRIDGE は、変更が無い場合でも PR を作成していました。PR がタスクの完了通知を兼ねていたためです。変更の無いタスクでは、PR を作らずに結果だけを返すべきでした。 解決方法 : PR を作る条件に「差分があること」を加え、差分が無いタスクでは結果だけを返す形にすれば、変更の無い PR は生まれません。あわせて、差分が無い PR、内容が重複する PR、main と競合したまま残っている PR を定期的に検出する仕組みがあると、PR の滞留も防げます。 記事の執筆後、集計期間に作られた未マージの PR を整理しました。PR をまとめてクローズする操作は、取り消しにくい操作です。そこで、整理の方針と実行するコマンドは AI に作らせ、私が内容を確認してから実行しました。PR は番号や古さだけで閉じず、同じ作業の後続の PR との比較や、現在の main との差分の確認を経てから閉じています。その過程で見つかった、まだ必要な小さな変更 3 件は、BRIDGE で現在の main に合わせて作り直して取り込みました。集計期間の未マージの PR は、すべて整理済みです。 教訓 3: 秘密を守るための最小ログは、境界の効果を測れなくする Dev Controller は、パス・ファイル内容・トークンを漏らさないように、ログには固定の文字列しか出さない設計でした。タスクの結果（宣言外の変更による失敗、SHA の不一致によるマージ拒否など）はチャット側への応答として返すだけで、サーバー側には記録していません。 その結果、境界 2 と境界 4 が実際に何回処理を止めたかを、後から数えられませんでした。秘密を含まない結果の種類と件数だけは、最初から記録すべきでした。 解決方法 : パスやファイルの内容は記録せず、結果の種類（成功、宣言外の変更、SHA の不一致など）とその件数だけを記録すれば、秘密を漏らさずに境界の効果を数えられます。この 2 つは両立できます。 教訓 4: AI のレビューを自動化したら、レビューの範囲と記録を設計する マージされた PR の、作成からマージまでの時間の中央値は 32 秒でした。約半数は作成から 30 秒以内に、8 割以上は 10 分以内にマージされています。GitHub 上の Review は 0 件で、レビューの判断はチャットの会話の中にだけ残っています。書き込み系ツールの実行確認を「常に許可」にしていたため、マージの多くは、私の都度の承認を経ずに、AI のレビュー結果だけで実行されていました。私が個々の PR の差分をどこまで自分で読んだかは記録していないため、集計できません。数十秒でマージに至った PR は、AI のレビュー結果に依拠していたと考えるのが自然です。 さらに、レビューの入力にも上限がありました。 inspect_pr が返す差分は、1 ファイルあたり 8KiB、最大 50 ファイル、全体で 128KiB までで、それを超えると切り詰めを示すフラグが付きます。AI が全変更を見ていなかった可能性があります。 境界 4 の実装にも、運用してみて分かった限界がありました。マージ済み PR の 9 割以上は、作成時と同じ main にマージされていました。この場合、マージ後の main の中身は、BRIDGE が PR を作る前に検証した状態と同じになります。一方、約 6%（19 件）は、レビューの後に main が進んだ状態でマージされていました。この 19 件について、PR が変更したファイルと、レビューの後に main で変更されたファイルを比べたところ、重なっているものはありませんでした。その後に変更を取り消した記録もありません。それでも、この 19 件のマージ後の状態は、検証されないまま main に入っています。マージの前に、最新の main と合わせた状態で検証し直すべきでした。 解決方法 : 次の 3 つをマージの条件に加えることで、この限界を補えます。 最新の main と合わせた状態で、CI のビルドとテストが通っていること レビューに使った差分が切り詰められていないこと レビューの判断と根拠が、PR など後から参照できる場所に残っていること 人がマージを承認する運用に切り替える場合は、GitHub の branch protection（第 4 章）で、最初の条件を満たせます。 3.3 実際に発生した障害 運用中に発生した障害のうち、外部の AI クライアントと MCP サーバーをつなぐ構成で共通して起こり得る 2 つを紹介します。 障害事例 1: OAuth の認証開始とツール一覧の取得が、互いを待っていた この事例は ChatGPT のカスタム MCP アプリで起きたものですが、OAuth で保護した MCP サーバーを外部のクライアントにつなぐ場合に共通する論点を含んでいます。 ChatGPT のカスタム MCP アプリを作成すると、ツールが 0 件のままで、OAuth のアカウント連携が始まりませんでした。 原因は 2 つ重なっていました。1 つは、ツールごとの認証の宣言が、ChatGPT に届いていなかったことです。ChatGPT は、ツール一覧（ tools/list ）に含まれる各ツールの securitySchemes を見て、どの認証が必要かを判断します。使用していた MCP の公式 TypeScript SDK（ @modelcontextprotocol/server 2.0.0）は、ツール定義の未知のキーを取り除くため、 securitySchemes を直接書いても応答に含まれませんでした。もう 1 つは、BRIDGE が、認証済みでなければ tools/list を返さない設計だったことです。ChatGPT はツール一覧を見てから認証を始め、BRIDGE は認証が済むまでツール一覧を返さない。互いに相手を待つ状態でした。 対応は次のとおりです。 securitySchemes を、SDK に取り除かれない _meta の中に宣言したうえで、 tools/list の応答を返す直前に、その値を各ツールの直下の securitySchemes に写す処理を加えました。この処理は tools/list の応答の形だけを変え、ツールの実行や認証の判定には触れません。WRITE 経路は、ツール一覧の応答を自前で組み立てているため、最初から直下に置いています。READ のツールは read scope だけ、WRITE のツールは write scope だけを要求します。 認証なしで許可するのを、 initialize 、 notifications/initialized 、 tools/list の 3 つだけにしました。不正なトークンや、scope が違うトークンを持つリクエストは、匿名扱いに格下げせず拒否します。 未認証の tools/call には、 _meta["mcp/www_authenticate"] を含むツールエラーを返し、ChatGPT が認証を始められるようにしました。 本番で、 initialize と tools/list が成功し、READ のツール一覧に READ の 2 ツールだけが含まれること、未認証の tools/call が認証を促すエラーを返すことを確認しました。 残る制約として、ツールの名前と入力スキーマは、URL を知っている相手には認証なしで見えます。URL に含めた秘密値によって、見える相手を絞っていますが、これは見える範囲を狭める補助で、ツールの実行は引き続き OAuth の認証で守っています。 障害事例 2: 長時間かかるツールと、MCP クライアントの再試行が衝突した READ 経路の inspect_app は、完了までに約 60 秒かかることがありました。外側の MCP クライアントは約 60 秒で同じリクエストを再試行し、再試行は実行中の元のリクエストとぶつかって「実行中」のエラーを受け取っていました。実装タスクの execute_dev_task でも、再試行のたびに新しいタスク ID が採番され、2 つ目のタスクとして「実行中」のエラーになる一方、元のタスクは実行を続けていました。 execute_dev_task は、実装から PR の作成までを 1 回の呼び出しで終える、同期のツールです。この問題に対しては、呼び出し方を非同期に作り直すのではなく、同期のまま、足りない部分を足す形で対応しました。 まず、再試行を拒否せず、実行中の処理に合流させて同じ結果を返すようにしました（single-flight）。同じ内容のリクエストかどうかは、自動で採番されるタスク ID ではなく、リクエストの内容で判定します。内容が異なるリクエストは、従来どおり「実行中」として拒否します。あわせて、実装の時間の上限を、120 秒から 600 秒まで段階的に延ばしました。本番では、約 1 分後に届いた再試行が、新しいタスクを始めずに実行中の処理へ合流することを確認しています。 それでも、チャット側で応答を待ちきれずにタイムアウトすると、実行が続いているのか終わったのかを確かめる手段がありませんでした。そこで、タスク ID を指定して状態（実行中／完了）を確認できる inspect_dev_task を追加しました。これにより、タイムアウトの後でも、同じ依頼を再実行せずに結果を確認できるようになりました。 結果として、通常は同期で結果を受け取り、応答が途切れたときだけ状態を確認する、という構成になっています。振り返ると、1 回の呼び出しで PR の作成まで完結し、状態の確認を繰り返さずに済む点は、同期の利点でした。一方で、長時間の処理を同期で公開する限り、クライアント側のタイムアウトとの関係は残ります。これから作るのであれば、実行の開始だけを返し、状態は別のツールで確認する非同期の形も、最初から選択肢に入れておくとよいと思います。 4. Kiro の標準機能との比較 BRIDGE を作り始めた 2026 年 8 月末から、この記事を書いている 2026 年 10 月までの約 2 か月の間にも、Kiro には機能が追加されています。たとえば、各ステップを独立したエージェントのセッションで動かす Workflows は、2026 年 9 月 30 日に、 Kiro CLI（2.26.0） と Kiro Web で提供が始まりました。 この章では、2026 年 10 月時点の Kiro の標準機能で、BRIDGE の 4 つの境界と運用の教訓がどこまで実現できるかを整理します。いずれも公式ドキュメントで確認できた範囲の内容です。 4 つの境界と Kiro の機能 境界 1（資格情報を渡さず、要求できる操作を固定する） : Permissions で、エージェントが使える操作（ファイルの読み書き、シェル、MCP など）ごとに、許可・確認・拒否を設定できます。拒否が常に優先され、エージェントの設定にも埋め込めます。レビュー役のエージェントには書き込みを与えない、といった役割ごとの設定ができます。 境界 2（変更してよい範囲を先に決め、終わった後に照合する） : 事前に絞る部分は、Permissions で実現できます。 fs_write に書き込みを許可するパスを glob で指定でき、headless モードでは確認が必要な操作はすべて拒否として扱われるため、明示的に許可した範囲の外には書き込めません。終わった後の照合は、利用者が自分で組み込みます。エージェントが作業を終えたときにコマンドを実行できる Hooks や、PR の変更ファイルを確認する CI などを使い、許可した範囲と実際の差分を比べる処理を加えます。BRIDGE では、この照合を、依頼ごとの宣言と作成・変更・削除の区別まで含めて、自前で実装しています。 境界 3（書き込みを止めるのは、実行環境） : Kiro CLI と Kiro IDE では、ローカルで実行するコマンドを隔離する ローカルコマンドサンドボックス が使えます。Linux では bubblewrap、macOS では Seatbelt で動きます。対象は、エージェントが実行するシェルコマンドとその子プロセスです。エージェント本体と組み込みのファイルツールはサンドボックスの外にあり、ファイルの読み書きは Permissions で制御します。ファイルツールによる書き込みまで含めて OS のレベルで隔離したい場合は、BRIDGE のようにプロセスごと隔離する方法があります。また、Kiro Web はクラウドの隔離されたサンドボックスでエージェントを動かし、Kiro Crew は、OS レベルのサンドボックスと署名付きの監査ログを備えています。 境界 4（何をレビューし、何をマージしたかを固定する） : Workflows には、PR を作成し、レビュー指摘に対応し、マージできる状態にして人に渡すレシピ（ publish-pr ）が用意されています。最終的なマージを人が行う運用であれば、GitHub の branch protection と組み合わせることで、レビューとマージの対象をそろえられます。 レビューした HEAD とマージする HEAD をそろえる : 「Dismiss stale pull request approvals when new commits are pushed」で、承認の後に新しいコミットが追加されたら承認を取り消します。あわせて「Require approval of the most recent reviewable push」で、最後の更新を自分以外の人が承認することを必須にします。 base の更新に対応する : 「Require branches to be up to date before merging」で、最新の base を取り込んだ状態で必須チェックが通るまで、マージできないようにします。マージが頻繁に重なるリポジトリでは、merge queue も使えます。 Kiro の中で役割を分けることもできます。Workflows では、各ステップが独立したセッションで動き、ステップ間は明示的な受け渡しでのみ結果を渡します。ステップごとにエージェントとモデルを指定できるので、設計・実装・レビューを別のモデルに担当させることもできます。 自作を選んだ理由は、いまも成り立つか 第 1 章で挙げた 3 つの理由を、2026 年 10 月時点の Kiro の標準機能と照らし合わせてみます。 自作を選んだ理由 2026 年 10 月時点の Kiro では 自作の必要性 1. 異なる AI の長所を組み合わせて、チームとして動かしたい Workflows で、計画・実装・レビューの各ステップに別のエージェントとモデルを割り当てられる。外部のツールや情報も、Kiro に MCP サーバーを追加すれば使える 多くの場合は無い。Kiro 以外の AI を計画役にして、その AI にすでに整えているアプリやコネクタ、会話の文脈をそのまま活かしたい場合に必要 2. 人が見るべきところ以外は任せたい Workflows の publish-pr は、PR をマージできる状態まで進め、最後のマージは人に渡す マージまで任せたい場合だけ必要。マージを人が承認する運用なら不要 3. 想定外の変更が起きたら止めたい Permissions で、書き込めるパスをあらかじめ制限できる。終わった後の照合は、Hooks や CI で組み込める 依頼ごとに範囲を宣言させ、作成・変更・削除を区別して照合したい場合に、その照合の処理が必要。多くの場合は、事前の制限と人による PR のレビューで足りる つまり、2026 年 10 月時点では、Kiro の中で完結させる使い方であれば、3 つの理由の多くは標準機能で満たせます。一方で、Kiro 以外の AI を計画役にする、マージまで任せる、照合を依頼ごとに細かく行う、といった使い方を選ぶ場合は、Kiro の外に仕組みを用意する必要があります。BRIDGE は、この 3 つの使い方をすべて選んだ場合の構成です。 Kiro で同じことを始めるなら BRIDGE のような外部の仕組みを持たずに、同じような使い方を Kiro で始める場合は、まず Kiro の標準機能で組み立て、運用の教訓をもとに必要な部分を足していく形になります。 境界 Kiro の機能で実現する部分 自分で足す部分（運用からの教訓） 1. 資格情報を渡さず、操作を固定する Permissions、Custom Agents（レビュー役に書き込みを与えない）、Workflows の investigate （読み取り専用の調査） 調査や確認を、読み取りの経路だけで完結できるようにする 2a. 変更範囲を先に決める Permissions（ fs_write のパス指定） — 2b. 終わった後に照合する 組み込み先として、Hooks の Stop トリガーを使える 許可した範囲と差分を比べる処理。変更が無いタスクでは PR を作らない。不要になった PR を定期的に検出する 3. 実行環境で書き込みを止める ローカルコマンドサンドボックス、Kiro Web のサンドボックス、Kiro Crew 境界が止めた結果の種類と件数を、秘密を含まない形で記録する 4. レビューとマージの対象を固定する Workflows の publish-pr と、GitHub の branch protection（承認の取り消し、最新の更新の承認、base への追従）、merge queue 最新の main と合わせた状態で検証する。AI のレビューでマージまで進めるなら、レビューの入力が完全だったことと判断の記録を、マージの条件に加える Kiro 以外の AI を計画役にする場合は、これに加えて、その AI に資格情報を渡さず、要求できる操作と引数を固定し、READ と WRITE を分ける仕組みが必要になります。長時間の処理を公開する場合は、同期と非同期のどちらにするかも、最初に決めておくとよいと思います。 まとめ AI エージェントを組み合わせること自体は、いまでは Kiro の標準機能で実現できます。難しいのは接続ではなく、どの判断を AI に任せ、どこをシステムで担保し、どの条件で次の工程に進めるかを決めることです。 BRIDGE での分担を整理すると、次のようになります。右の列は、BRIDGE のシステムで担保していることだけでは担保できず、教訓で挙げた解決方法や、人の確認で補う必要がある点です。 AI に任せた判断 システムで担保していること それだけでは担保できないこと どう実装するか 変更が、宣言したファイルの範囲に収まっているか 範囲内の変更が、正しく実装されているか どんなテストが必要か 使い捨ての環境で、ビルドとテストが通ったか 最新の main と合わせた状態でも、ビルドとテストが通るか レビューの結果 マージする PR の HEAD が、レビューしたときの HEAD と同じか レビューで差分をすべて見ていたか。レビューの後に main が進んでいないか マージしてよいか マージ後の main に、そのコミットが含まれているか 人がその判断に同意していたか 境界を設計するときは、境界そのものに加えて、「境界の外側で AI がどう振る舞うようになるか」と、「境界が働いたことを後から確かめられるか」まで考える必要があります。Kiro で同じことを始める場合も、この 2 点は確認しておく価値があると思います。 BrightFlow のプロダクトは、現在開発を進めています。リリースの際には、SNS などでお知らせしますので、そのときはぜひご覧ください。 利用条件について 本記事の構成は、各サービスが公式に提供している機能だけで組み立てています。Kiro 側は公式の Kiro CLI（headless モードと ACP）、チャット側はカスタム MCP の接続機能です。 AI エージェントを外部のツールと組み合わせる使い方については、各サービスの利用条件が更新されることがあります。同様の構成を試す場合は、Kiro、利用する AI チャット、GitHub それぞれの最新の利用条件を確認してください。 著者について 池田 健人（Ikeda, Kento） 合同会社 BrightFlow 代表社員 株式会社 GENDA Platform Engineering 部 部長 株式会社 ZINE 取締役 CTO 2011 年にヤフー株式会社に入社。Yahoo!ニュース トピックス等のリプレイスや開発・保守運用を担当。その後、マネジメントや新規本部の開発組織立ち上げを行う。2019 年に株式会社 ZOZO テクノロジーズ(現 株式会社 ZOZO)に入社し CTO 室や ZOZO CSIRT の設立に携わり、エンジニア採用や教育など幅広くエンジニアリング組織のマネジメントを行う。現在は株式会社 GENDA で Platform Engineering 部 部長として Engineering Office、SRE/インフラ、QA、PjM 組織を率いながら、株式会社 ZINE 取締役 CTO に就任。AWS Community Builder（DevTools 領域）に 2021 年から継続して採択される。AWS User Group Leaders。Amplify Japan User Group 運営メンバー。一般社団法人 日本 CTO 協会 個人会員・スタッフ（プロボノ）。NPO 法人 CancerWith 理事。合同会社 BrightFlow 代表社員。

この記事は Introducing advanced Kubernetes control plane configuration in Amazon EKS (記事公開日: 2026 年 8 月 12 日) を翻訳したものです。 大規模な Amazon Elastic Kubernetes Service (Amazon EKS) クラスターを運用するお客様は、リソースの使用率を高めてコンピューティングコストを下げるために、Pod の配置戦略を最適化したいと考えています。入れ替わりの激しいバッチ、継続的インテグレーションと継続的デリバリー (CI/CD)、AI と機械学習 (AI/ML) のワークロードを実行するチームは、etcd のストレージの逼迫を抑えるために、イベントの保持期間などのリソースのライフサイクル管理の設定をカスタマイズしたいと考えています。また、セルフマネージドの Kubernetes から移行するお客様は、長年調整してきたスケジューラの設定を引き継ぎたいと考えています。これまで、こうしたニーズの多くに応えるには独自の仕組みを構築して維持する必要があり、運用オーバーヘッドとメンテナンスの負担が増えていました。2026 年 8 月に、Amazon EKS は高度な Kubernetes コントロールプレーン設定の提供を開始しました。API サーバー、スケジューラ、コントローラーマネージャーのパラメータを、Amazon EKS で直接設定できるようになりました。Amazon EKS の可用性とパフォーマンス特性は、これまでと変わりません。 この記事では、この機能の概要とサポートされているパラメータを説明したうえで、2 つのウォークスルーで実際に試します。まず、 MostAllocated スコアリング戦略を使って、デフォルトの分散配置よりもリソースの使用率を優先するように Pod の配置戦略を設定します。次に、デバッグのしやすさとストレージの効率のバランスを取るように、イベントの保持期間を設定します。 設定できる項目 スケジューラのカスタマイズでは、Pod の配置戦略を設定して、Pod のスケジューリングでノードをどのようにスコアリングするかを制御できます。デフォルトでは、Kubernetes スケジューラは LeastAllocated スコアリング戦略を使います。この戦略は、可用性を重視して、リソースの割り当てが少ないノードを優先します。 MostAllocated スコアリング戦略は、すでに割り当てが多いノードを優先し、リソースの使用率を最適化します。 MostAllocated 戦略では、使用率がすでに高いノードに Pod を詰め込むので、同じワークロードをより少ないノードで実行できます。その結果、コンピューティングコストが下がり、クラスター内で一部しか使われていないインスタンスが減ります。 コントローラーマネージャーの設定では、 Horizontal Pod Autoscaler (HPA) がスケーリングを判断する頻度を制御できます。同期間隔を短くすると、HPA コントローラーがメトリクスを評価して対応する頻度が上がるので、負荷が増えてからワークロードがスケールアウトするまでの時間が短くなります。 Amazon EKS Provisioned Control Plane のクラスターでは、最近の改善で HPA の同期の同時実行数が Kubernetes のデフォルト値の最大 40 倍に引き上げられていて ( 発表 )、同期間隔の設定と組み合わせて使えます。同時実行数の引き上げと同期間隔の短縮によって、HPA コントローラーはより多くのスケーリングイベントを並列に処理し、ワークロードの需要の変化にすばやく対応できます。その結果、Pod のオートスケーリングが速くなり、需要の変化への応答性が高まります。 API サーバーでは、 イベントの保持期間 を設定して、デバッグのしやすさとストレージの効率のバランスを取れます。バッチパイプライン、CI/CD ランナー、AI/ML ジョブなど、Pod の入れ替わりが激しいクラスターでは、大量の Kubernetes イベントが生成されます。これらのイベントは etcd の領域を消費し、クラスターの動作に必要なオブジェクトと領域を奪い合います。保持期間を短くすると、こうした短期間しか使わない診断データが早く消去されるので、etcd のデータ量を抑え、list と watch のリクエストを速くできます。一方、保持期間を長くすると、チームがトラブルシューティングに使える履歴が増えます。また、 NodePort タイプの Service に割り当てるポート番号の範囲 を変更して、ポートの割り当てを組織のネットワークとファイアウォールのポリシーに合わせたり、NodePort タイプの Service を多数実行するクラスターで範囲をデフォルトより広げたりすることもできます。この設定は移行の際に役立ちます。レガシーアプリケーションとその呼び出し元のクライアントは、特定の固定ポートでサービスが提供されることを前提にしていることがよくあります。それらのポートが Kubernetes のデフォルトの範囲外にある場合、通常はアプリケーションを変更するか、アプリケーションの前に外部のプロキシを立てる必要があります。範囲をアプリケーションがすでに使っているポートに合わせれば、その作業が不要になり、アプリケーションを書き直したり、保守が必要なネットワークコンポーネントを追加したりせずに、ワークロードを Amazon EKS に移行できます。 提供開始時にサポートされるパラメータ 次の表に、提供開始時に使用できるパラメータをまとめます。サポートされている値と範囲を含む全一覧は、 Amazon EKS のドキュメント をご覧ください。 コンポーネント パラメータ 制御する内容 kube-scheduler nodeResourcesFit.scoringStrategy リソースの割り当てに基づいてノードをスコアリングし、Pod の配置戦略を設定します。MostAllocated はすでに割り当てが多いノードを、LeastAllocated は使用可能なリソースが多いノードを優先します。cpu、memory、アクセラレーター (nvidia.com/gpu、aws.amazon.com/neuron、aws.amazon.com/neuroncore) に、リソースごとの重み (1～100) を指定できます。 kube-controller-manager horizontalPodAutoscalerControllerConfig.horizontalPodAutoscalerSyncPeriod アプリケーションの要件に合わせて、HPA がメトリクスを評価してスケーリングを判断する頻度 (10～15 秒) を設定します。 kube-apiserver eventTtl デバッグのしやすさと etcd のストレージの効率のバランスを取るように、イベントの保持期間 (10～60 分) をカスタマイズします。 kube-apiserver serviceNodePortRange NodePort タイプの Service に割り当てるポート番号の範囲 (10260～32767) を定義します。アプリケーションを変更せずにレガシーシステムを移行できます。 注: horizontalPodAutoscalerSyncPeriod パラメータを使うには、 Amazon EKS Provisioned Control Plane が必要です。Provisioned Control Plane は、負荷の高いワークロードに常に対応できるコントロールプレーンのキャパシティを事前に割り当て、追加の負荷を吸収できるサイズを確保します。 これらはクラスター全体の設定で、クラスターで実行されるワークロードに適用されます。前の表は、お客様の要望に基づいて選んだ、最初にサポートするパラメータの一覧です。他に設定したいパラメータがあれば、 AWS Containers Roadmap でお知らせください。 前提条件 このウォークスルーを実施するには、次のものが必要です。 AWS アカウント Kubernetes バージョン 1.31 以降を実行している Amazon EKS Auto Mode クラスター 手元のデバイスで設定済みの最新バージョンの AWS コマンドラインインターフェイス (AWS CLI) 、または AWS CloudShell クラスターと通信できるように設定した kubectl Amazon EKS クラスターの情報の取得と更新、クラスターへのワークロードのデプロイを行うアクセス許可を持つ AWS Identity and Access Management (IAM) プリンシパル まず、クラスター名と AWS リージョンを設定します。 export CLUSTER=my-eks-cluster export AWS_REGION=us-west-2 ウォークスルー 1: MostAllocated スコアリング戦略による Pod の配置の最適化 このウォークスルーでは、既存のクラスターで MostAllocated スコアリング戦略を設定し、Kubernetes スケジューラが新しい Pod を、使用可能なリソースが多いノードではなく、すでに割り当てが多いノードに配置する様子を確認します。高度な Kubernetes コントロールプレーン設定を使えば、この戦略を Amazon EKS クラスターで直接設定できるので、カスタムスケジューラを維持する運用の負担がなくなります。 ステップ 1. ノードの使用率に偏りのあるクラスターを用意する この例では、Pod の数に関係なく一定数のノードを維持するために、 静的キャパシティのノードプール を設定した Amazon EKS Auto Mode クラスターを使います。静的キャパシティのノードプールは、予測可能なキャパシティやリザーブドインスタンスが必要なワークロードや、インフラストラクチャの規模を一定に保つことが求められるコンプライアンス要件のあるワークロードに役立ちます。ノードプールを作成します。 cat <<EOF | kubectl apply -f - apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: demo-static spec: replicas: 2 template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "node.kubernetes.io/instance-type" operator: In values: ["m5.large"] limits: nodes: 2 EOF kubectl wait --for=condition=Ready nodes --all --timeout=180s 両方のノードの準備ができたら、サイズの異なるワークロードをデプロイして、割り当てに偏りを作ります。 # 1 つのノードで重いワークロードを実行する (ノードのキャパシティの大半を使う) cat <<EOF | kubectl apply -f - apiVersion: apps/v1 kind: Deployment metadata: name: heavy-app spec: replicas: 1 selector: matchLabels: app: heavy-app template: metadata: labels: app: heavy-app spec: nodeSelector: karpenter.sh/nodepool: demo-static containers: - name: pause image: registry.k8s.io/pause:3.9 resources: requests: cpu: 1500m memory: 1Gi --- apiVersion: apps/v1 kind: Deployment metadata: name: light-app spec: replicas: 1 selector: matchLabels: app: light-app template: metadata: labels: app: light-app spec: nodeSelector: karpenter.sh/nodepool: demo-static containers: - name: pause image: registry.k8s.io/pause:3.9 resources: requests: cpu: 500m memory: 512Mi EOF kubectl wait --for=condition=Ready pods --all --timeout=120s 次のコマンドで、各ノードのリソースの割り当てを確認します。スケジューラは、スコアリングの判断に (実際の使用量ではなく) リソースの要求量を使います。 kubectl get pods -o wide kubectl describe nodes -l karpenter.sh/nodepool=demo-static | grep -A 5 "Allocated resources" Node: i-0b3a5fb6f3823fd2f Allocated resources: CPU Requests: 1500m (84%) Memory Requests: 1Gi (14%) Node: i-08c2daa17b2fbe865 Allocated resources: CPU Requests: 500m (28%) Memory Requests: 512Mi (7%) ノード A (i-0b3a5fb6f3823fd2f) は CPU の 84% が割り当てられています。ノード B (i-08c2daa17b2fbe865) は 28% だけです。kube-scheduler は、ノードをスコアリングするときに、この割り当ての差を使います。 ステップ 2. デフォルトの配置 (LeastAllocated) を確認する 新しい Pod をデプロイして、スケジューラがどのノードに配置するかを確認します。 cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: test-pod spec: nodeSelector: karpenter.sh/nodepool: demo-static containers: - name: pause image: registry.k8s.io/pause:3.9 resources: requests: cpu: 200m memory: 128Mi EOF kubectl wait --for=condition=Ready pods --all --timeout=120s kubectl get pods -o wide NAME READY STATUS NODE test-pod 1/1 Running i-08c2daa17b2fbe865 LeastAllocated では、スケジューラは使用可能なリソースが多いノードを優先し、Pod をノード B (CPU 28%、メモリ 7% が割り当て済み) に配置しました。先に進む前に、このテスト用の Pod を削除します。 kubectl delete pod test-pod ステップ 3. MostAllocated スコアリング戦略を有効にする 既存のクラスターにスケジューラの設定を適用します。 aws eks update-cluster-config \ --name "$CLUSTER" \ --kube-scheduler-config '{ "nodeResourcesFit": { "scoringStrategy": { "type": "MostAllocated" } } }' 注: 必要に応じて、カスタムの重みを指定した resources 配列を指定し、スコアリングの判断でどのリソースを重視するかを調整できます。サポートされているリソースは cpu 、 memory 、 nvidia.com/gpu 、 aws.amazon.com/neuron 、 aws.amazon.com/neuroncore で、重みは 1～100 です。 レスポンスとして、進行状況を追跡できる更新の情報が返されます。 { "update": { "id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "status": "InProgress", "type": "ControlPlaneComponentConfigUpdate" ... } Amazon EKS は、他のクラスターの更新と同様に、コントロールプレーンの設定の更新を非同期に適用します。更新が完了するまで待ちます。 aws eks wait cluster-active --name "$CLUSTER" このコマンドは、クラスターが Active ステータスに戻るまで待機します。通常は数分以内に戻ります。 ステップ 4. 新しい配置 (MostAllocated) を確認する これで、新しいスケジューリングの判断には MostAllocated が使われます。別のテスト用の Pod をデプロイして、どのノードに配置されるかを確認します。 cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: test-pod spec: nodeSelector: karpenter.sh/nodepool: demo-static containers: - name: pause image: registry.k8s.io/pause:3.9 resources: requests: cpu: 200m memory: 128Mi EOF kubectl wait --for=condition=Ready pods --all --timeout=120s kubectl get pods -o wide NAME READY STATUS NODE test-pod 1/1 Running i-0b3a5fb6f3823fd2f MostAllocated では、スケジューラは、すでにリソースの割り当てが多いノード A (CPU 84%、メモリ 14% が割り当て済み) を優先するようになりました。ノードアフィニティ、Taint と Toleration、トポロジー分散制約など、独自のスケジューリング要件を指定した Pod では、引き続きその要件が優先され、スケジューラはそれに従います。この詰め込む動作によって、時間がたつにつれて、使用率の低いノードには新しいワークロードが配置されなくなり、統合 (consolidation) に対応したノードプールでは、それらのノードを統合できるようになります。ポイントは、カスタムスケジューラを使わずに、1 回の API コールでクラスター全体のスケジューリング戦略を変更できたことです。 ウォークスルー 2: eventTtl によるイベントの保持期間の設定 Kubernetes は、Pod のスケジューリングの判断、イメージのプル、ヘルスチェックの失敗、スケーリングのアクションなどのクラスターのアクティビティを記録するために、イベントを etcd データベースに保存します。アップストリームのデフォルトでは、イベントは 1 時間保持されます。大規模なバッチジョブ、機械学習 (ML) のトレーニング、CI/CD パイプライン、大規模な CronJob など、入れ替わりの激しいワークロードを実行するクラスターでは、数千のイベントがすぐに蓄積します。etcd 内のイベントが増えると、ストレージが逼迫し、API サーバーの list 処理が遅くなるおそれがあります。 高度な Kubernetes コントロールプレーン設定では、デバッグのしやすさとストレージの効率のバランスを取るように、イベントの保持期間を調整できます。このウォークスルーでは、 eventTtl をデフォルトの 1 時間から 15 分に短縮します。 ステップ 1. eventTtl を 15 分に短縮する API サーバーの設定を適用します。 aws eks update-cluster-config \ --name "$CLUSTER" \ --kube-api-server-config '{ "eventTtl": "15m" }' 更新が完了するまで待ちます。 aws eks wait cluster-active --name "$CLUSTER" ステップ 2. 短縮の効果を確認する 新しい eventTtl の設定は、設定の変更が反映された後に Kubernetes が作成するイベントに適用されます。既存のイベントは元の保持期間を維持し、その期間に従って期限切れになります。保持期間が短くなったことを確かめるために、新しい Pod を作成して、その Pod のイベントを確認します。 kubectl run ttl-test --image=registry.k8s.io/pause:3.9 kubectl get events --field-selector involvedObject.name=ttl-test LAST SEEN TYPE REASON OBJECT MESSAGE 6s Normal Scheduled pod/ttl-test Successfully assigned default/ttl-test to i-0b3a5fb6f3823fd2f 3s Normal Pulled pod/ttl-test Container image "registry.k8s.io/pause:3.9" already present on machine 3s Normal Created pod/ttl-test Container created 3s Normal Started pod/ttl-test Container started 約 15 分後に、同じイベントを照会します。 kubectl get events --field-selector involvedObject.name=ttl-test No resources found in default namespace. Kubernetes が 15 分後にイベントをガベージコレクションで削除したことから、新しい保持期間が有効になっていることを確認できます。設定の変更前からあったイベントは、引き続き元の保持期間で期限切れになります。1 時間に数千のバッチジョブを実行するクラスターでは、この設定によって etcd の領域を大幅に空けられ、イベントを多く扱うクエリに対する API サーバーの応答時間を短縮できます。 イベントの保持期間を設定するタイミング 次のような場合は、 eventTtl を短くするのが適しています。 クラスターで、大量のイベントを生成するバッチ、CI/CD、ML のトレーニング、CronJob のワークロードを実行している。 etcd のストレージが容量の上限に近づいている。 イベントを永続的に保存するために外部のオブザーバビリティシステム ( Amazon CloudWatch Container Insights やログアグリゲーターなど) を利用していて、過去のイベントを調べるのに kubectl get events に頼っていない。 TTL を短くすると、 kubectl describe pod と kubectl get events で表示される期間も短くなることに注意してください。ストレージの効率とデバッグの手順のバランスが取れる値を選んでください。 クリーンアップ 継続的な料金が発生しないように、AWS アカウントで作成した Amazon EKS クラスターのリソースを必ず削除してください。 kubectl delete deployment heavy-app light-app kubectl delete pod test-pod kubectl delete nodepool demo-static Amazon EKS クラスターを削除するには、Amazon EKS のドキュメントの 手順 に従ってください。 考慮事項 高度な Kubernetes コントロールプレーン設定を適用する前に、次の点に留意してください。 既存の Amazon EKS API で管理: 高度な Kubernetes コントロールプレーン設定では、既存の CreateCluster API と UpdateClusterConfig API を新しいパラメータとともに使います。設定は、 AWS マネジメントコンソール 、AWS CLI、 AWS CloudFormation で適用できます。 eksctl 、AWS Controllers for Kubernetes (ACK)、Terraform のサポートも予定されています。(訳注: eksctl は、2026 年 8 月 14 日にリリースされた v0.230.0 でサポートされました。)Amazon EKS は各設定を適用する前に検証し、監査できるように変更を AWS CloudTrail に記録します。 設定はクラスター全体に適用: サポートされている各パラメータは、クラスター全体と、クラスターで実行されるワークロードに適用されます。Kubernetes がすでに従っている Pod レベルの指定 (Pod 自身のリソースの要求量など) は、引き続き適用されます。クラスターの設定で変わるのはコントロールプレーンのデフォルトとスコアリングの動作で、現在利用している Kubernetes の優先順位のルールは変わりません。 スケジューラとノード管理は別のレイヤーで動作: MostAllocated スコアリング戦略が影響するのは、スケジューラが、条件を満たす既存のノードのどれに Pod を配置するかです。Amazon EKS Auto Mode や Karpenter がノードをプロビジョニングしたり削除したりする方法は変わりません。設定を更新する前に、ワークロードでスケジューラとノード管理を組み合わせた動作を検証することをお勧めします。 一部のパラメータには Provisioned Control Plane が必要: horizontalPodAutoscalerSyncPeriod など、コントロールプレーンのパフォーマンスやリソースの消費に影響しうるパラメータは、 Provisioned Control Plane の階層を使うクラスターでのみ使用できます。 HPA の同期間隔とクラスターの規模: Provisioned Control Plane のクラスターでは、Amazon EKS は HPA の同期の同時実行数を Kubernetes のデフォルト値の最大 40 倍に引き上げています。同時実行数の引き上げと、HPA の同期間隔 (10～15 秒) を設定できることによって、HPA コントローラーはより多くのスケーリングイベントを並列に処理し、ワークロードの需要の変化にすばやく対応できます。HPA オブジェクトが多いクラスターでは、本番環境に適用する前に、選んだ同期間隔と HPA オブジェクトの数で期待どおりに動作するかを、お客様の環境で検証してください。 Kubernetes バージョンとリージョンのサポート: 高度な Kubernetes コントロールプレーン設定は、Kubernetes 1.31 以降を実行する新規および既存の Amazon EKS クラスターでサポートされています。Amazon EKS を利用できるすべての AWS 商用リージョン、AWS GovCloud (米国)、中国リージョンで、追加料金なしで利用できます。 horizontalPodAutoscalerSyncPeriod を使うには Provisioned Control Plane が必要で、Provisioned Control Plane にはスケーリング階層に応じた時間料金がかかります。 まとめ 高度な Kubernetes コントロールプレーン設定により、クラスター管理者は Amazon EKS の可用性とパフォーマンス特性を維持したまま、スケジューリング、リソース管理、API サーバーの設定を直接制御できます。お客様は、デフォルトの Kubernetes スケジューラを改変したものを実行したり、回避策を実装したりする必要がなくなり、運用オーバーヘッドを減らしながら、リソースの使用率を高め、コストを下げられます。この記事では、 MostAllocated のビンパッキングで Pod の配置を最適化してリソースの使用率を高め、イベントの保持期間を調整してデバッグのしやすさとストレージの効率のバランスを取りました。ぜひこの機能を使い始めて、 AWS Containers Roadmap でフィードバックをお寄せください。 使い始めるには、次の情報をご覧ください。 Amazon EKS ユーザーガイド で、高度な Kubernetes コントロールプレーン設定について確認してください。 コントロールプレーンのキャパシティを事前に割り当てる必要があるパラメータについては、 Amazon EKS Provisioned Control Plane の詳細をご覧ください。 ノードの管理を自動化してクラスターの運用を簡素化する Amazon EKS Auto Mode について、詳しくご覧ください。 翻訳はシニアパートナーソリューションアーキテクトの市川が担当しました。原文は こちら です。

本投稿は、2026年 10 月 16 日に公開された、 Know Before You Go: your re:Invent 2026 guide to managing cloud and AI spend を翻訳したものです。 世界が AI を大規模に取り入れつつある今、IT 支出を管理する皆さんは新たな難題に直面しています。これまでの クラウド財務管理 (CFM) の時代では、IT とファイナンスのリーダーにクラウドと財務の両方の言葉を理解できることが求められていましたが、AI の時代にはトークン（この言葉をご存知でしょうか？）をはじめとする新たな用語やコストの切り口が加わります。総所有コスト (TCO) をようやく把握できたと思った矢先に、それは AI の総コスト (TCA) へと広がりました。この新しい環境では、投資を正当化するために組織が必要とするコストの追跡可能性とコントロールを実現できるよう、 コスト管理のあり方を見直すことが求められます。 今年の re:Invent では、AI コスト管理の最新のフレームワーク、ソリューション、そして実際の成功事例をしっかりおさえていただけるよう、素晴らしいセッションを数多く用意しました。これらのセッションは、トークノミクスといった概念を理解し、AI コスト管理で一歩先を行くための助けになります。各トラックを横断して、30 を超えるクラウド財務管理と AI コスト管理に関するセッションが揃っています。本ブログ記事では、そのうち 9 つを取り上げ、会期中に AWS の FinOps のエキスパートや同じ課題を持つ仲間に会える場所をご紹介します。 3 つのテーマ セッションの詳細に入る前に、さまざまなセッションを通して織り込まれている 3 つのテーマを紹介します。 AI コストに対するネイティブな可視性とコントロール (FinOps for AI) : AI の採用が加速する中で、財務面のコントロールを失うことなくスケールできるよう、AI支出を詳細に把握できるようにしたいと考えています。 FinOps の基礎を極める : きめ細かなコスト配分、より精度の高い予測、そしてカスタムベネフィットの共有により、すべての支出が可視化され、計画され、意図を持って共有される状態を実現します。 AI for FinOps : AI を FinOps チームのために働かせることで、ビジネス上の重要なタスクに集中し、既存のクラウド支出と新たに生じるAIコストの双方の管理にかける時間を減らせます。 最新情報のキャッチアップ (ブレイクアウトセッション) COP209: Manage Cloud Costs and AI Spend with AWS Cost Management 12月1日(火) | 14:30〜15:30 PST | MGM Grand | Level 3 | Premier 318 毎年恒例の新機能発表ブレイクアウトセッションです。AI がチームのクラウドコスト管理をより効果的にする方法 (「AI for FinOps」) と、AI 自体のコストを管理する方法 (「FinOps for AI」) を取り上げます。AVIV Group が登壇し、（彼らの）実体験から得られた学びを共有します。 スピーカー: Bowen Wang (Principal PM Outbound, AWS)、Matt Berk (Principal TAM, AWS)、 Jordi Espasa (FinOps Director, AVIV Group) COP201: Accelerating Cost Optimization on AWS 12月3日(木) | 8:30〜9:30 PST | Venetian | Level 2 | Ballroom F | Content Hub コスト最適化の機会を持続的に発見して実行し、成果を測定し、削減額を組織全体に分配する方法を学びます。 スピーカー: Jimmy Yang (Principal PM, AWS)、Mary Nachimov (Sr. Technical PM, AWS) ハンズオンで学ぶ (Codeトーク、ワークショップ、Builders’セッション) Codeトーク COP403: Optimize AI Apps on Amazon Bedrock for Cost, Latency, and Control 11月30日(月) | 11:30〜12:30 PST | Wynn/Encore | Upper Convention Promenade | Cristal 2 リピート開催: 12月2日(水) | 8:30〜9:30 PST | Wynn/Encore | Upper Convention Promenade | Cristal 2 本番環境の AI アプリケーション向けの高度な最適化手法 (プロンプトエンジニアリング、モデル選定、コンテキストウィンドウ管理など) を扱うライブコーディングセッションです。それぞれの設計判断がコストに与える直接的な影響を、 AWS Billing and Cost Management 上で確認します。 スピーカー : Andy Brown (Sr. Manager, FinOps, AWS)、Steph Gooch (Principal Tech Advocate, AWS) ワークショップ COP324: AI-Powered FinOps: Cloud Cost Optimization in Practice 11月30日(月) | 8:30〜10:30 PST | Wynn/Encore | Upper Convention Promenade | Cristal 7 リピート開催: 12月2日(水) | 15:30〜17:30 PST | MGM Grand | Level 1 | Grand 124 AI を活用したコスト最適化により、FinOps を運用上の規律として定着させます。最適化の自動化、ライトサイジング、AI/MLおよびコンテナワークロードのコスト配分、マルチクラウドレポーティング、AI による支出分析をハンズオンで体験します。*ノート PC が必要です。 スピーカー : Rupesh Lunia (Principal PM, AWS)、Enrico Bonaccorsi (Principal TAM, AWS) Builders’セッション COP311: FinOps for AI: Cost Allocation Strategies for Amazon Bedrock 12月2日(水) | 16:30〜17:30 PST | Wynn/Encore | Convention Promenade | Latour 7 リピート開催: 12月3日(木) | 10:30〜11:30 PST | Wynn/Encore | Convention Promenade | Latour 7 Amazon Bedrock 向けの最新のコスト管理機能をハンズオンで体験します。API 呼び出しにタグを付けてきめ細かくコストを紐付け、予算を設定して AI 支出を制御し、発生するコストをその都度追跡します。さらに、CUR 2.0 の新しい製品メタデータをクエリし、100 万トークンあたりのコストの推移を CUDOS で可視化します。 スピーカー: Yuriy Prykhodko (Principal Technologist, AWS)、Judith Lehner (Principal TAM, AWS)、Brenno Passanha (Sr. TAM, AWS)、Ariel Fu (Sr. PM-Tech, AWS)、Eric Christensen (Sr. TAM, AWS) COP312: Embed FinOps into Your CI/CD Pipelines 11月30日(月) | 13:30〜14:30 PST | Caesars Forum | Level 1 | Forum 120 | Content Hub リピート開催: 12月3日(木) | 10:30〜11:30 PST | Caesars Forum | Level 1 | Forum 120 | Content Hub 実際に動作するコスト見積もりゲートを CI/CD パイプラインに直接組み込みます。プルリクエストの時点でインフラコストへの影響を評価し、デプロイ前に支出のしきい値を強制します。*ノート PC が必要です。 スピーカー : Fredrik Tunvall (Sr. PM, AWS)、Jenny Shen (SA, AWS)、Travis James (Sr. Optimization SA, AWS)、Hicham Lahlal (Sr. Cloud FinOps Architect, AWS)、Shubho Laga (Sr. TAM, EMEA) エキスパートや仲間と学ぶ (チョークトークとライトニングトーク) チョークトーク COP328: Building a Cost Governance Framework That Scales 12月2日(水) | 16:30〜17:30 PST | MGM Grand | Level 1 | Boulevard 165 リピート開催: 12月3日(木) | 13:00〜14:00 PST | MGM Grand | Level 3 | Premier 311 コストデータの整理、予算のガードレール設定、支出の配分、組織全体での可視性の確立について、AWS FinOps Agent を取り上げながら、インタラクティブなディスカッションとホワイトボードを使ったアプローチで進めます。現在抱えている FinOps の課題をお持ちください。 スピーカー : Adam Richter (Sr. Optimization SA, AWS)、Jason Wu (Sr. Technical PM, AWS) COP329: Automate Savings with AWS Billing and Cost Management Services 12月2日(水) | 16:30〜17:30 PST | MGM Grand | Level 3 | Room 353 リピート開催: 12月3日(木) | 12:00〜13:00 PST | Wynn/Encore | Convention Promenade | La Tache 2 コミットメントの購入やライトサイジングによる最適化をビジネス目標に整合させるアプローチと、継続的なコスト最適化の取り組みに自動化を組み込む方法について議論します。 スピーカー : Savanna Jensen (Sr. Cloud FinOps Architect, AWS)、Haritha Chitalia (Cloud FinOps Architect, AWS) ライトニングトーク COP348: Monitor and Optimize Costs for Amazon Bedrock 11月30日(月) | 17:30〜18:30 PST | Venetian | Level 2 | Hall B | Expo | Global Impact Theatre Amazon Bedrock のコスト監視と最適化に役立つ実践的なヒントを、短時間で押さえるセッションです。軽めながら、re:Invent の1週間を始めるうえで欠かせない内容です。 スピーカー : Adam Richter (Sr. Optimization SA, AWS) 今年復活: CFM キオスクへお立ち寄りください re:Invent 2026 では、CFM 専用キオスクが帰ってきます。1 年のブランクを経て、ふらっと立ち寄って質問したり、製品のライブデモ ( AWS FinOps Agent やその他の新機能を含む)を見たり、CFM のプロダクトマネージャーやエキスパートと直接話したりできる場として、会期中ずっとオープンします。ご自身のコストに関する課題をお持ちいただき、私たちのチームと一緒に解決策を探しましょう。予約は不要です。お気軽にお立ち寄りください。 キオスク担当 : Larry Im (Sr. SA, AWS)、Koushik Das (Sr. TAM, AWS)、Sean Falconer (Sr. SA, AWS)。CFM のプロダクトマネージャーや現場のエキスパートも、ご質問に備えて待機しています。 FinOps コミュニティとつながる FinOps Foundation は、今年は Tokenomics Foundation および FOCUS チームも加わり、re:Inventでコミュニティイベントを開催するという恒例の取り組みを継続します。今年は 12 月 1 日(火)、Rock House にて午前から昼にかけてのプログラムが予定されています。朝の基調講演のウォッチパーティーで一日を始め、ネットワーキングランチで FinOps 仲間と交流しましょう。お申し込みは こちら から。 ご都合がつかない場合もご心配なく。FinOps Foundation のチームは火曜の夕方近くに AWS CFM チームとともにキオスクに参加し、FOCUS、トークノミクス、そして FinOps コミュニティのより広範な取り組みについて引き続き会話できる場を設けます。 計画のTips 早めに登録してください – セッションには定員があり、人気のあるものはすぐに埋まります 会場間の移動のために、セッションの間にバッファ時間を確保してください – ラスベガスのホテル間の距離は、見た目以上に離れていることがあります。 セッションのレベルを考慮して計画を立ててください – セッション ID で判断できます。例えば、COP209 は 200 レベルのセッション、COP403 は 400 レベルのセッションです。 リピート開催を確認してください – 今年はいくつかのセッションが 2 回実施されるため、第一希望が重複した場合でももう一度チャンスがあります。 水曜の午後は注意してください – COP311、COP328、COP329 はすべて同じ時刻に始まり、COP324 のリピート開催はその 3 つすべてと重なります。複数参加したい場合は、木曜のリピート開催を利用してください。 スケジュール一覧 日時 セッション 場所 11月30日(月) 8:30-10:30AM COP324 ワークショップ: AI-Powered FinOps Wynn/Encore, Cristal 7 11:30 AM–12:30 PM COP403 Codeトーク: Optimize AI Apps on Bedrock Wynn/Encore, Cristal 2 1:30–2:30 PM COP312 Builders’セッション: FinOps in CI/CD Caesars Forum, Forum 120 5:30–6:30 PM COP348 ライトニングトーク: Bedrock Cost Monitoring Venetian, Expo Hall, Global Impact Theatre 12月1日(火) Morning to midday FinOps Foundation コミュニティイベント Rockhouse 2:30–3:30 PM COP209 ブレイクアウト: Manage cloud and AI Spend MGM Grand, Premier 318 4:30-6PM FinOps Foundation がキオスクでAWS CFM チームに合流 CFM kiosk, Expo Hall 12月2日(水) 8:30–9:30 AM COP403 Codeトーク (リピート) Wynn/Encore, Cristal 2 3:30–5:30 PM COP324 ワークショップ (リピート) MGM Grand, Grand 124 4:30–5:30 PM COP311 Builders’セッション: Bedrock Cost Allocation Wynn/Encore, Latour 7 4:30–5:30 PM COP328 チョークトーク: Cost Governance Framework MGM Grand, Boulevard 165 4:30–5:30 PM COP329 チョークトーク: Automate Savings MGM Grand, Room 353 12月3日(木) 8:30–9:30 AM COP201 ブレイクアウト: Accelerating Cost Optimization Venetian, Ballroom F 10:30–11:30 AM COP311 Builders’セッション (リピート) Wynn/Encore, Latour 7 10:30–11:30 AM COP312 Builders’セッション (リピート) Caesars Forum, Forum 120 12:00–1:00 PM COP329 チョークトーク (リピート) Wynn/Encore, La Tache 2 1:00–2:00 PM COP328 チョークトーク (リピート) MGM Grand, Premier 311 この記事に記載されているセッションの日時と場所は、セッションの人気度と会場の収容人数に基づいてスケジュールを最適化し続けているため、変更される可能性があります。登録済みのセッションに関する最新情報については、 re:Invent のセッションカタログ を定期的にご確認ください。 re:Invent 2026 でお会いできることを楽しみにしています！ Bowen Wang Bowenは、AWS請求およびコスト管理サービスのプリンシパルプロダクトマーケティングマネージャーです。彼女は、財務およびビジネスリーダーがクラウドの価値とクラウド財務管理を最適化する方法をより良く理解できるよう支援することに注力しています。以前のキャリアでは、テクノロジースタートアップの中国市場参入を支援していました。 本記事の翻訳はテクニカルアカウントマネージャーの 鍛治田 が担当しました。

本ブログは “ How financial institutions can operationalize AI-DLC quickly and effectively “（2026 年 9 月 23 日公開）を翻訳したものです。 金融機関は AI コーディングエージェントを急速に導入していますが、多くの金融機関には、規制当局や自社のリスクアペタイトを満たすガバナンスの枠組みがありません。その結果、強力なツールが組織の統制の外でコードを生成しています。以前の記事「 金融サービスのための AI 駆動開発ライフサイクル 」（AI-DLC）では、お客様がこれをどう運用に乗せているかを説明しました。今回はさらに踏み込みます。チームが Amazon の Kiro 、 Anthropic Claude Code 、 OpenAI Codex のどれを使っていても、エージェントを組織のルールの範囲内で動かすためのガバナンス層をどう構成すればよいのでしょうか。この記事では、ガバナンスハーネスを数日で構築する方法と、エンジニアリングチームとガバナンス・リスク・コントロール（GRC）チームがそこから何を得られるかを説明します。 ハーネスのガバナンス層 なぜ重要なのか ガバナンス層がなければ、コーディングエージェントは強力でありながら統制の効かない存在になります。生成されたコードがデータの取り扱いや行動規範のルールに違反するかもしれません。承認されていない依存関係は、問題が起きる可能性を高めます。脆弱なパッケージを通じて、シークレットが意図せず漏えいすることもあります。規制当局は、適切なモニタリングが行われている証拠を見つけられません。ガバナンス層は組織のポリシーを技術的な制約に変換し、コードを書く速さが統制を犠牲にしていないことを確かにします。 主要なコーディングエージェント（ハーネス）は、いずれもガバナンス層を構築するための基本要素を備えています。 ハーネスの基本要素 Kiro Claude Code OpenAI Codex 永続的なコンテキスト（エージェントが毎セッション読むルール） ステアリングファイル（.kiro/steering/） CLAUDE.md + Rules（.claude/rules/） AGENTS.md（ディレクトリごとに階層化） イベントに応じた自動の強制（自動アクション） Hooks（AI フックを含む） Hooks Hooks（hooks.json / config.toml） コンテキストを分離したレビュー サブエージェント（カスタムエージェント） サブエージェント サブエージェント 再利用可能なワークフロー Skills（SKILL.md） Skills（.claude/skills/） Skills（.agents/skills/） 外部ツールとの統合 MCP サーバー MCP サーバー MCP サーバー 権限の境界 エージェント定義の権限ルール 権限システム（allow/deny/ask ルール） config.toml の承認ポリシーとサンドボックスモード これらのファイルに、その会社固有の標準を書き込みます。ハーネスは、その会社のために、その会社がすでに持っている知識（ポリシー、アーキテクチャ設計ガイドライン、セキュリティ標準など）から作ります。たとえば、コーディングエージェントに設計ガイドラインを読ませ、関連する情報を抽出して、スキル、フック、ステアリングファイル、エージェントに書き込ませます。 ハーネスのガバナンス層がもたらすもの エンジニアリングのリーダーにとって： すべての開発者、すべてのエージェントとのやり取りから、一貫してガバナンスの効いた成果物が得られます。新しく加わったメンバーも、リポジトリをクローンするだけで初日からルール一式を引き継げます。 GRC チームにとって： エンジニアリングの証跡を、規制対応にそのまま使える報告に自動で変換するコンプライアンスの仕組みを作るためのデータが得られます。 開発チームにとって： ガバナンスの効いていないコードの手戻りなしに、エージェント型開発の速さを得られます。エージェントはルールから外れる前に確認を求め、チームが学ぶほど組織の知識が蓄積されます。 金融機関のお客様と 3 日間で構築したもの 最近、欧州の大手保険会社と取り組みを行いました。このお客様は、エージェント型開発を使って既存の画面に新しい UI ガイドラインを適用する必要があり、同時に組織のルールへの準拠も保たなければなりませんでした。AI-DLC の Inception フェーズに続いて、お客様のエンジニアが AWS と協力し、ハーネスのガバナンス層と、それを保守するために必要なスキルを 3 日で構築しました。お客様は、ステアリングファイルのアーキテクチャと spec 駆動開発のワークフローを標準で備えている点から Kiro を選びました。 構築したガバナンス層は 6 つの要素からなり、それぞれがコンプライアンス・リスク管理チームになじみのあるリスク統制に対応しています。 ハーネスの要素 役割 対応する統制（GRC 向け） 永続的なコンテキスト（Kiro のステアリングファイル / CLAUDE.md / AGENTS.md） エージェントがタスクの前に毎回読むルール ポリシーと標準、人間が関与するチェックポイント 自動のゲート（Hooks） 保存時 とパイプラインでの決定論的なチェック 予防的統制と発見的統制 手順をスキルとしてまとめる（手続きのガバナンス） 複雑な複数ステップのワークフローを毎回同じ方法で実行する コンプライアンスに沿ったプロセスの遵守 ナレッジループ 修正内容を記録し、繰り返し現れるパターンを恒久的なルールに格上げする 課題管理と統制の改善 対立的なレビュー（レビュー用エージェント定義を持つ Kiro、Claude Code、Codex のサブエージェント） マージ前に、コンテキストを分離してエージェントの成果物を批評する メーカー・チェッカー／職務分離 権限の境界（権限設定） エージェントがアクセス・実行できる範囲を制限する 最小権限／特権アクセス管理 取り組みの中で、シニアエンジニアやアーキテクトは、ガイドラインの文書、コード例、チームが持つ組織の知識から、ハーネスの要素を生成するよう Kiro に指示しました。作業は反復的に進めました。チームは最初のハーネスをレビューして明らかな誤りを取り除き、あらかじめ用意したインプットを与え、必要に応じてエージェントを誘導し、出力が期待に届かないたびにハーネスを修正しました。この過程で、実務上の疑問が浮かびました。改善の手段がいくつもある中で、ハーネスを磨くのに最も効率のよい方法は何か、という疑問です。ハーネスを作るためのルールはまだ形になりつつある段階で、厳密に体系化されていません。しかも、新しいモデルがリリースされるたびに変わります。そのため、ハーネスを時間をかけて磨き、適応させていくうえで、チームを導く経験豊富な実務者が欠かせません。 各要素がガバナンスの観点で何をもたらすか ステップ 1：ルールを定義する（永続的なコンテキスト） エージェントは、文書化されバージョン管理されたポリシーの範囲内で動きます。すべてのルールには担当者（人間）が 1 人おり、組織の標準までたどることができます。 既存のガイドラインは、各エージェント固有の指示形式に変換します。Kiro ならステアリングファイル、Claude Code なら CLAUDE.md、Codex なら AGENTS.md です。 主な設計原則（エージェントを問わない）： ルールを関連するコンテキストに絞る： たとえばフロントエンドの標準はフロントエンドのタスクのときだけ読み込みます。コンテキストが薄まるのを防ぎ、エージェントが関係するルールだけを見るようにします。 要件レベルの語彙（MUST / MUST NOT / SHOULD / MAY）： RFC 2119 の制約キーワードを使い、AI エージェントの振る舞いを決定論的にします。これらのキーワードを大文字で書くことで重みが増し、エージェントがより確実に守るようになります。 質問を必須にする規律： あいまいな要件からコードを生成する前に、エージェントは必須の質問への回答を集めます。要件の誤解がそのまま顧客向けの誤りになる金融機関にとって、これは価値の高いガバナンスです。 ステップ 2：決定論的な統制を強制する（自動のゲート：Hooks） 決定論的にチェックできる統制は、人間のレビューを経てコーディングエージェントがスクリプト化します。これにより、人為的なミスや AI のハルシネーションの可能性を取り除き、監査人に向けて再現可能な証跡を提供します。 永続的なコンテキストがエージェントの振る舞いを方向づけ、自動のゲートがそれを決定論的に強制します。 保存時のコンプライアンスチェック： ファイルを保存するたびにポリシーのチェックが走り、違反はエージェントに戻されてすぐに修正されます。 完了前の検証： エージェントは、コンパイル、テスト、lint の結果を示さない限り、タスクを完了と宣言できません。 実行前のブロック： 危険な操作は、実行前に人間の承認を必要とします。 これらは、第 2 の防御線として CI/CD パイプラインにも広げます。 ステップ 3：手順をスキルとしてまとめる（手続きのガバナンス） これまで複雑な複数ステップのワークフローは、開発者の習熟度によって実行方法がまちまちで、逸脱や誤りの原因になっていました。これを、どの開発者がどのセッションで呼び出しても毎回同じ方法で実行できるようにし、組織の手順を書き込んで、準拠した成果物を生み出します。 永続的なコンテキストは、エージェントに何をすべきかを伝えます。スキルは、それをどうやるかを伝えます。スキルはバージョン管理されたディレクトリ（SKILL.md を起点とする）で、指示、テンプレート、スクリプトを繰り返し使えるワークフローにまとめたものです。エージェントは名前でスキルを見つけ、関係があるときだけ指示の全文を読み込み、毎回同じ手順に従います。 Kiro の場合： .kiro/skills/ にある SKILL.md ファイル。キーワードの一致で見つけられます。 Claude Code の場合： .claude/skills/ にあるスキルのフォルダ。それぞれに SKILL.md と、必要に応じてスクリプトを置きます。 Codex の場合： リポジトリ、ユーザー、システムの各スコープの .agents/skills/ にあるスキルのフォルダ。プラグインで配布できます。 スキルは、指針と強制の橋渡しをします。準拠した成果物を生む手順を書き込むことで、フックが発動する回数を減らします。スキルはリポジトリに置かれるため、すべての変更が git で追跡されます。スキルはオープンなエージェントスキルの標準（ agentskills.io ）に従っているため、ツールが進化しても投資が無駄になりません。 ステップ 4：組織の知識を蓄積する（ナレッジループ） 会社の標準と組織の知識は継続的に改善されます。新しいルールはどれも、git の履歴にある日付付きの修正記録にさかのぼれます（トレーサビリティ）。 コードの修正は、タイムスタンプとタグを付けた事例として、バージョン管理されたファイルに記録します。同じパターンが 3 回繰り返されたら恒久的なルールに格上げし、人間がレビュー・承認した組織の知識として蓄積していきます。 実際には、繰り返し出てくる修正は、新しいステアリングファイルの項目（Kiro）、ルールファイル（Claude Code）、AGENTS.md の更新（Codex）になります。ルールを決定論的にチェックできるなら、スクリプトにします。 ステップ 5：エージェントのためのメーカー・チェッカー（対立的なレビュー） リスクの高い変更は、人間が目にする前に、独立したコンテキストを分離したレビューを受けます。これは、リスク管理部門が機微な業務に求めるのと同じ職務分離です。 コーディングエージェントがコードを生成し、続いてコンテキストを分離したレビュー用エージェントが、その成果物をステアリングのルールに照らして批評します。承認されるか、人間にエスカレーションされるまで、このやり取りを繰り返します。企業はこれを、欠陥を見逃した場合のコストがレビューのコストを上回るリスクの高い変更に絞って適用します。 ステップ 6：エージェントの能力の範囲を限定する（権限の境界） エージェントの自律性はエージェント型開発の速さの中心にあり、ここまでの要素でエージェントがすべきことはすでに制約されています。権限の境界は、最後の安全策を加えます。問題を解くときに、エージェントがタスクに必要な範囲を超えられないようにするものです。最小権限のアクセスを設定し、エージェントが定められた範囲の外にあるものを読んだり、変更したり、実行したりできないようにします。 Kiro の場合： カスタムエージェントの定義で、エージェントが使えるツールの種類（読み取り、書き込み、シェル）を宣言します。 Claude Code の場合： 4 層の権限システム（モード、allow/deny/ask ルール、フック、OS レベルのサンドボックス）が、すべてのツール呼び出しを、失敗したら拒否する（フェイルクローズの）パイプラインで評価します。 Codex の場合： 承認ポリシーとサンドボックスモードにより、設定可能な人間の承認と OS レベルの分離を提供します。 人間と違い、エージェントは報告に疲れることがありません。手作業での証跡収集は面倒で誤りも起きやすいものですが、エージェントはコンプライアンスチェックを 1 回目でも 1,000 回目でも同じ厳密さで、ほかのタスクと同じように実行します。そのため、ハーネスの一部を、監査人が求める可能性のある証跡を継続的に集める仕組みとして構成できます。成果物を構造化されたリポジトリに保存しておけば、監査報告書の作成は、記録を作り直す作業ではなく、取り出す作業になります。 ハーネスのガバナンス層のデリバリーパイプライン ハーネスがガバナンスの役割を果たしていることを、どう検証すればよいでしょうか。ハーネスもソフトウェアの成果物なので、2 つの検証層を持つ専用のデリバリーパイプラインを用意します。 第 1 層：静的検証（コード変更のたび、数秒で）： リンク切れがないこと、フォーマットが正しいこと、ルールに担当者がいること、スクリプトが動くことを自動でチェックします。これにより、ガバナンスの成果物が動き出す前に、正しく組み立てられていることを確認します。 第 2 層：振る舞いの回帰テスト（毎晩、およびモデルが変わるたび）： 正しい出力があらかじめ決まっている既知のシナリオでエージェントを動かし、ルールが実行時に機能することを確かめます。第 1 層は「ルールは正しく設定されているか」を問い、第 2 層は「AI が動いたときにルールは機能するか」を問います。 重要な気づき：ハーネスには継続的な調整が必要 お客様との取り組みから、ガバナンスハーネスは機能することが分かりました。ただし、成功させるには、監視と調整、そしてエンジニアリングチームと GRC チームの共同の責任が必要です。 モデルは進化し、ハーネスもそれに合わせて進化しなければなりません。実践的な指針は次のとおりです。 厳格な承認ゲートは、本当に元に戻せない操作だけに残す：新しい依存関係、構造的なリファクタリング、スコープを変える判断など。 各ルールは 1 か所に 1 回だけ書き、担当者を 1 人にする。 ルールは、ドメインやファイルの種類に応じて条件付きで適用する。 まず、矛盾と参照切れをなくす：整理され、矛盾のないルールセットこそが、品質を上げる最大の手段です。 根底にある原則はおなじみのものです。統制のしすぎは守るべきプロセスを損ない、一貫性のないポリシーは少なすぎるポリシーよりも悪い、ということです。適切な調整の水準はモデルの世代が変わるたびに動くため、ハーネスには回帰テストが必要です。この調整の規律は、定められたリスクアペタイトの範囲でエージェント型 AI のメリットを得るために、GRC 部門が身につけなければならないスキルです。 ハーネスだけでは機能しない この枠組みは、成熟した DevSecOps のプラクティス（自動化された CI/CD、ブランチ保護、コードレビューの文化）がすでに整っていることを前提にしています。エージェントのガバナンスを上に重ねる前に、まずそこから始めてください。 重要なのは、ステアリングファイルやプロンプトに基づくルールは非決定論的な統制だという点です。エージェントの振る舞いに影響を与えますが、それを保証することはできません。ガバナンスを完全なものにするには、エージェントが何を生成しても準拠を強制する、CI/CD パイプラインの決定論的な統制（linter、静的解析、Policy as Code のゲート）で補う必要があります。ハーネスは、層を重ねた仕組みとして最もよく機能します。非決定論的な統制が生成時の違反を減らし、決定論的な統制が、すり抜けたものをコードが本番環境に届く前に捕まえます。 まとめ 冒頭で示したガバナンスのギャップは解決でき、しかも素早く解決できます。AI-DLC は金融機関に手法を提供し、ガバナンスハーネスは、コンプライアンスを組み込んだ状態でエージェント型開発を大規模に運用するためのツールを提供します。ハーネスは、準拠したコードの実装を容易にすると同時に、実装中に下された判断をより体系的に記録します。その記録が可視性と透明性を生み、開発チームに追加の負担をかけずに、規制対応の証跡に変えることができます。 前提条件は、経営層の合意と、ハーネスが増幅する土台となる成熟した DevSecOps のプラクティスです。投資は、多くの金融機関が想定するより小さくて済みます。基盤となるハーネスは、新たなポリシーを一から作るのではなく、組織がすでに持っている知識から作るため、数日で形になります。 AI-DLC の展開ハーネスの一部として効果的なガバナンス層を構築するために AWS がどのようにお手伝いできるか、詳しくは AWS のアカウントチームにお問い合わせください。 参考資料 AWS ブログ： AI-Driven Development Life Cycle（手法の紹介） AWS ブログ： Open-Sourcing Adaptive Workflows for AI-DLC Kiro Steering のドキュメント 、 Kiro Hooks のドキュメント 、 Kiro CLI v3 のドキュメント Claude Code：CLAUDE.md と Rules、Hooks、Subagents のドキュメント OpenAI Codex：AGENTS.md、設定プロファイル、サンドボックスモードのドキュメント Kiro の変更履歴 Jean-Francois Landreau Jean-Francois Landreau は、Global Financial Services 担当のシニアソリューションアーキテクトです。レジリエンス、コンテナ、ソフトウェア開発ライフサイクル（SDLC）の加速などについてお客様を支援しています。お客様との対話では、長年にわたって培ってきたアジャイル、DevOps、プラットフォームエンジニアリングの経験を活かしています。2007 年以降、Thomson Reuters、その後 Allianz で、さまざまな立場からプラットフォームの導入を率いてきました。「現場（マシンルーム）から離れすぎていては、企業として賢明な判断は下せない」というのが彼の信念です。 Richard Caven Richard Caven は AWS のワールドワイドバンキングスペシャリストです。お客様のクラウド移行とデジタルトランスフォーメーションを支援する戦略的な取り組みを立案し、実行する役割を担っています。2018年に Barclays から AWS に入社しました。Barclays では Managing Director を務め、Global Treasury 部門の COO でした。 Silvia Prieto Silvia は、EMEA、アジアパシフィック、日本の Global Financial Services のお客様を担当する生成 AI・機械学習（ML）部門の責任者です。現在の職務では、AI の市場開拓（Go-To-Market）戦略とソートリーダーシップの立案と推進を担っています。お客様がこれらの新しい技術とその活用方法を細部まで理解できるよう支援しており、大規模な導入に向けた助言も行っています。

本記事は 2026 年 10 月 27 日 に公開された「 Introducing time series collections for the next generation of Amazon OpenSearch Serverless 」を翻訳したものです。 本日、Amazon OpenSearch Serverless NextGen が時系列コレクションに対応したことを発表します。時系列コレクションを使えば、クラスターのプロビジョニングや管理をせずに、ログ、メトリクス、トレース、イベントデータを取り込み、保存、分析できます。時系列コレクションは取り込みのスパイクを自動で吸収し、直近のデータは高速にクエリでき、数か月から数年分の履歴も低コストで検索可能にします。これらすべてを同じコレクション内で実現します。時系列コレクションは OpenSearch Serverless にアラートと異常検知も追加するため、問題が起きた瞬間に発見して対処できます。コレクションあたり最大 100 TB のホットストレージをサポートし、アプリケーション監視、セキュリティ分析、IoT テレメトリなど大規模なオブザーバビリティワークロードに対応します。 オブザーバビリティデータは量が多く、不具合のあるデプロイや障害など、チームが最も早く答えを求める瞬間に急増します。クラスターのサイジングが不足すると処理が追いつかず、エンジニアが待っているログの到着が遅れるため、チームはピーク負荷に合わせてサイジングし、それ以外の日もその容量分を支払うことになります。履歴が増えるとホットストレージの費用がかさむため、保持期間を短縮したり、古いデータをスナップショットに移したりせざるを得ません。しかしスナップショットからクエリするには、まず誰かが復元する必要があります。クラスターには継続的なチューニングと容量計画も必要で、本来データが支援するはずの調査からエンジニアを引き離してしまいます。あらゆる判断がコスト、保持期間、システムへの疑問に答えるまでの速度のトレードオフになります。 OpenSearch Serverless の時系列コレクションはトレードオフを取り除きます。インシデントでログ量が急増しても、コンピュートが数秒でスケールして追従するため、エンジニアが待っているログは時間通りに届きます。トラフィックが落ち着けばコンピュートはゼロまでスケールダウンするため、ピーク時の容量に支払い続ける必要はありません。古いデータは低コストのウォーム層に移動しますがクエリは可能なので、保持期間を縮めたりスナップショットを復元したりせずに数年分の履歴を保てます。サイジングやチューニングが必要なクラスターはありません。コンピュートの上限といくつかのインデックス設定を指定すれば、あとはサービスが処理します。 クエリ頻度の低いデータは低コストで 時系列データへのクエリの大半は直近数時間から数日を対象としますが、古いデータはクエリ頻度こそ低いものの、引き続き利用可能にしておく必要があります。新しい index.warm.after 設定で、データがホット層に留まる期間を指定し、低コストのウォーム層へ移動するタイミングを決められます。日単位または時間単位で指定でき、最小 1 日 ( 24h または 1d ) から最大 10 年 ( 3650d ) までの範囲で、インデックスの保持期間を超えることはできません。未指定の場合、データは 1 日後にウォーム層へ移動します。 PUT /app-logs { "settings": { "index.warm.after": "7d" } } 取り込み時、各ドキュメントは低レイテンシーのホット層と Amazon Simple Storage Service (Amazon S3) の両方に書き込まれます。データが指定した経過期間に達すると、古いものから順にホットコピーが解放され、データは Amazon S3 上のウォーム層に残ります。クエリでウォーム層のデータが必要になると、サービスがそのデータをホット層に読み戻して処理します。該当データへの最初のクエリは時間がかかりますが、同じデータへの以降のクエリはホット層のレイテンシーで実行されます。古いデータに対する調査やレポート作成のように、同じ時間範囲を繰り返しクエリする用途に適しています。クエリが両方の層にまたがる場合も、結果は 1 つのレスポンスで返ります。ホットストレージの料金は、ホット層に残っているデータ分だけ発生します。 図 1: データは 7 日後にホット層からウォーム層へ移動し、全期間を通じて Amazon S3 に永続化される ワークロードが必要とする期間だけデータを保持 保持期間はインデックス自体に設定するため、別途ライフサイクルポリシーを作成・維持する必要はありません。インデックステンプレートで index.data.retention を設定すれば、パターンに一致するすべてのインデックスがその設定を継承します。1 日から 3,650 日 (10 年) までの範囲で、日数の整数で指定します。 PUT /_index_template/app-logs { "index_patterns": ["app-logs*"], "template": { "settings": { "index.data.retention": "30" } } } 階層管理と保持期間は独立しています。階層管理はクエリ速度とコストを制御し、保持期間はデータが削除されるタイミングを制御します。たとえばアプリケーションログは 7 日間ホット層に置いて 30 日間保持する、あるいはコンプライアンス要件に合わせて監査データを数年間ウォーム層に残す、といった運用が可能です。監査が必要になったら、同じコレクション内で履歴をクエリするだけで、検索コンピュートが追加負荷に合わせてスケールアップします。スナップショットの復元も、調査用クラスターの立ち上げも不要です。 図 2: データの階層管理と保持期間 インデックスごとにイベントタイムスタンプを指定 時系列コレクション内のすべてのドキュメントには、タイムスタンプフィールドが必須になりました。各インデックスには、サービスがデータの整理とソートに使う時刻フィールドが 1 つ指定されており、タイムスタンプが欠落、null、または無効なドキュメントは拒否されます。 デフォルトの時刻フィールドは @timestamp です。イベントが event_time のような別のフィールドをすでに持っている場合は、インデックス作成時またはインデックステンプレートで index.timestamp_field を設定すれば、プロデューサー側を変更せずに済みます。フィールドはトップレベルの date フィールドである必要があり、ドキュメントのタイムスタンプはインデックス登録後に変更できません。 PUT /app-logs { "settings": { "index.timestamp_field": "event_time" } } 拒否はドキュメント単位で、リクエスト全体には及びません。 _bulk リクエストでは有効なドキュメントはインデックス登録され、拒否されたドキュメントはレスポンスの errors ブロックに列挙されるため、1 件の不正レコードでバッチ全体が失敗することはありません。 図 3: 時刻フィールドが各ドキュメントのインデックス登録または拒否を決める仕組み 障害に発展する前に問題を見つける 時系列コレクションではアラートと異常検知も使えるようになりました。従来の Classic サーバーレスコレクションでは提供されていなかった機能です。別のシステムに頼って不具合を知らせてもらう代わりに、データを保存しているコレクション自体で監視、検知、通知ができます。運用チームはエラー率やレイテンシーの急増時に通知を受け取れ、セキュリティチームはログイン失敗の急増を検知でき、ビジネスチームは注文数の急落を発見できます。 アラートモニターはスケジュールに従ってデータをクエリし、条件が満たされると選択したチャネルを通じて通知します。Per-query モニターは、平均レイテンシーがしきい値を超えるなど、単一の値に対してアラートを発します。Per-bucket モニターは、エラー率が上がりすぎたホストごとなど、グループを個別に評価します。PPL モニターは Piped Processing Language (PPL) で、より複雑なロジックを扱えます。 異常検知は Random Cut Forest (RCF) 機械学習アルゴリズムでデータの通常パターンを学習し、固定しきい値を推定することなく、ほぼリアルタイムで逸脱を検出します。検出器の結果にモニターを向けておけば、異常が現れた瞬間に通知を受け取れます。 モニターと検出器は OpenSearch UI ワークスペースで管理し、アクセス権はワークスペースのコラボレーター権限に従います。読み取り専用のコラボレーターはモニターとアラートを閲覧でき、読み書きおよび管理者のコラボレーターは作成、更新、確認応答も可能です。Observability ワークスペースではアラートがダッシュボードや PPL クエリと並んで配置されるため、サーバーレスコレクションや既存の Amazon OpenSearch Service ドメインを横断して、アラートから背後のイベントまでたどれます。 使ってみる ワンクリックで始めるなら、Amazon OpenSearch Service コンソールの Express Create を使います。コレクショングループ、暗号化、ネットワークアクセス、データアクセスを自動で設定してくれます。各ステップを自分で制御したい場合は、以下のように AWS Command Line Interface (AWS CLI) を使います。 図 4: Express Create がデフォルト設定でコレクショングループ、暗号化、ネットワークアクセスを設定する様子 まず、NextGen のコレクショングループを作成します。コレクショングループは、所属するすべてのコレクションで共有するコンピュート上限を設定します。OpenSearch Compute Unit (OCU) の最小値を 0 にすれば、アイドル時にグループをゼロまでスケールダウンでき、最大値で支出に上限を設けられます。 aws opensearchserverless create-collection-group \ --name app-logs-group \ --generation NEXTGEN \ --standby-replicas ENABLED \ --capacity-limits '{ "minIndexingCapacityInOCU": 0, "minSearchCapacityInOCU": 0, "maxIndexingCapacityInOCU": 96, "maxSearchCapacityInOCU": 96 }' 次に、コレクションへアクセスできる場所を制御する ネットワークポリシー と、どの AWS Identity and Access Management (IAM) プリンシパルがデータを読み書きできるかを制御する データアクセスポリシー を作成します。 続いて、コレクショングループ内に時系列コレクションを作成します。 aws opensearchserverless create-collection \ --name app-logs \ --type TIMESERIES \ --collection-group-name app-logs-group \ --encryption-config aWSOwnedKey=true コレクションがアクティブになったら、時刻フィールド、階層管理、保持期間の設定を含むインデックステンプレートをワークロードに合わせて作成します。名前がパターンに一致するすべてのインデックスが、以下の設定を自動で引き継ぎます。 PUT /_index_template/app-logs { "index_patterns": ["app-logs*"], "template": { "settings": { "index.timestamp_field": "event_time", "index.warm.after": "7d", "index.data.retention": "30" } } } 最後にデータをコレクションに取り込み、OpenSearch UI の Observability ワークスペースを開いて、最初のダッシュボード、モニター、異常検出器を作成します。 本日提供開始 時系列コレクションは、NextGen の OpenSearch Serverless が利用可能なすべての AWS 商用リージョン で本日から提供されます。料金は OCU 単位で使用したコンピュートと、GB 月単位のホットおよびウォームストレージに対して発生します。詳細は Amazon OpenSearch Service 料金ページ をご覧ください。 詳しくは、 Amazon OpenSearch Serverless 製品ページ と Amazon OpenSearch Serverless 開発者ガイド を参照してください。 Amazon OpenSearch Service コンソール でぜひお試しいただき、 AWS re:Post または普段ご利用の AWS サポート窓口からフィードバックをお寄せください。 著者について Kevin Fallis Kevin はベテランのリーダー、アーキテクト、デベロッパーで、農業、アドテック、金融サービス、ネットワーキング、セキュリティ、通信、そしてもちろん検索技術など、さまざまな業界と専門領域での経験を持ちます。顧客がビジネス目標を達成できるよう、AWS サービスとオープンソースソリューションの適切な組み合わせを引き出すことに情熱を注いでいます。仕事以外では、家族と過ごす時間、DIY プロジェクト、大工仕事、乗馬、ドラム演奏、音楽全般を楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。

本記事は 2026 年 10 月 5 日に公開された Jaiganesh Girinathan、Harith Gaddamanugu、Kaustubh Phatak、Ted Middleton による “Protect MCP Endpoints at the Edge with Amazon CloudFront and AWS WAF” を翻訳したものです。 AWS WAF を使うと、 Model Context Protocol (MCP) エンドポイントをエッジで実用的に保護し、可視化できます。MCP は、 AI エージェントがツールやデータとやり取りするための標準的な方法として急速に普及しました。もともと MCP は、長時間のセッション、永続的な接続、クライアントとサーバーインスタンスの紐付けを前提としたステートフルなプロトコルでした。 2026 年 7 月 28 日の改定 では、 MCP がステートレスな HTTP リクエスト/レスポンス型のプロトコルとして再設計されました。これにより、すべての MCP リクエストは自己完結した POST リクエストとなり、ネットワーク上ではほかの REST API 呼び出しと見分けがつかない形になりました。その結果、ほかの HTTP API の前段ですでに利用しているのと同じレイヤー 7 の検査、変換、最適化を、 MCP サーバーのコードを変更することなく CDN や AWS WAF のレイヤーで適用できるようになります。 本記事では、Amazon CloudFront または Application Load Balancer (ALB) の背後にデプロイした MCP エンドポイントを、 AWS WAF で保護し、可視化する方法を紹介します。新しい仕様によって簡単に適用できる、次の 9 つのユースケースを順に説明します。 すべてのリクエストで、許可された MCP-Protocol-Version を必須にする AWS WAF Bot Control で呼び出し元を分類し、相手がどのエージェントなのかを把握する ボディサイズのプリフライトチェックを追加する エージェントが呼び出せるツールの許可リストを作成する query_database ツールで破壊的な SQL をブロックする ツールの引数に隠されたサーバーサイドリクエストフォージェリ ( SSRF )をブロックする クエリ形式の入力に含まれる SQL インジェクションを検出する ツールごとにレート制限を設け、単一の高コストな操作によってバックエンドのリソースが枯渇しないようにする オプションとして、ツールごとの制限の下に、全体の上限となるグローバルなレート制限を設ける MCP をエッジで検査できるようになった理由 2026 年 7 月 28 日の改定より前の仕様では、 MCP セッションにはハンドシェイクが必要でした。クライアントが initialize を送信すると、サーバーが Mcp-Session-Id を返し、以降のすべてのリクエストはその識別子を付けて同じサーバーインスタンスに送られていました。リモート環境へのデプロイでは、接続の固定 ( ピニング ) 、レプリカ間でのセッション状態の共有、ストリームを維持するためのプロキシの運用が必要でした。プロトコルがステートフルで、リクエストストリームの中身も不透明であったため、エッジでの検査は現実的ではありませんでした。 新しい仕様では、セッションが完全に廃止されました。 MCP リクエストは、どのサーバーインスタンスでも処理できる単一の自己完結した HTTP POST リクエストになっています。 POST /mcp HTTP/1.1 MCP-Protocol-Version: 2026-07-28 Mcp-Method: tools/call Mcp-Name: query_database Authorization: Bearer eyJhbGciOi... Content-Type: application/json { "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "query_database", "arguments": { "filter": "id = 42" } } } エッジでポリシーを適用するうえで重要になるのが、 Mcp-Method と Mcp-Name の 2 つのヘッダーです。どちらも Streamable HTTP Transport では必須とされています ( SEP-2243 ) 。これらのヘッダーは、ロードバランサー、ゲートウェイ、ファイアウォールがボディを解析せずに、操作の内容に基づいてルーティングできるようにするために用意されています。ヘッダーとボディの内容が一致しないリクエストをサーバーは拒否するため、これらのヘッダーは意図を示す信頼できるシグナルになります。 AWS WAF にとってこれは、MCP リクエストに関するもっとも重要な 2 つの情報 ( どの操作が実行されるのか、どのツールが呼び出されるのか ) を、ヘッダーだけで把握できることを意味します。より深い検査が必要な場合は、 JSON ボディの $.params.arguments パスが対象になります。すべての MCP ツール呼び出しは、ツールごとの引数をこのパスに格納します。上記のサンプルリクエストであれば、 query_database に渡される filter の値が該当します。 JSON ペイロードのそれ以外の部分は、プロトコルの定型構造です。 ポリシーを適用する場所は、 MCP クライアントの内部 ( たとえば、エージェントが呼び出せるツールの制限 ) 、ネットワーク境界 ( たとえば、承認されていない MCP メソッドをブロックするファイアウォールルール ) 、あるいはサーバーの前段にある CDN レイヤーのいずれかです。本記事では CDN レイヤー ( エッジ ) に焦点を当てます。 CDN レイヤーは、利用者自身が完全にコントロールできる唯一の適用ポイントです。フレームワークやネットワーク経路に関係なくすべての呼び出し元をカバーでき、 MCP サーバーのコードを変更する必要もありません。 AWS WAF による MCP エンドポイント保護のリファレンスアーキテクチャ アーキテクチャは、一般的な REST API の前段で運用しているものと同じです。 Amazon CloudFront ディストリビューション ( または Application Load Balancer ) を MCP サーバーの前段に配置し、 AWS WAF のウェブ ACL をそのディストリビューションに関連付けます。エージェントから届いたリクエストを AWS WAF がインラインで評価し、すべてのルールを通過したリクエストだけがオリジンに到達します。追加のホップやプロキシ層は不要で、 MCP サーバーのコードを変更する必要もありません。図 1 にリクエストの経路を示します。 図 1. AWS WAF のウェブ ACL を関連付けた Amazon CloudFront ( または ALB ) が、各 MCP リクエストをインラインで評価する構成。ブロックルールに一致したリクエストには 403 が返され、通過したリクエストは MCP サーバーに転送されます。 検査の境界を理解する：エッジとオリジン Amazon CloudFront では、AWS WAF は CloudFront Functions や Lambda@Edge が実行される前にリクエストを評価します ( AWS WAF のリクエスト評価順序   ) 。そのため、 AWS WAF はエッジ関数が追加したヘッダーを参照できず、呼び出し元が最初に送信した内容だけを参照します。 MCP トラフィックの場合、利用できるフィールドは MCP-Protocol-Version 、 Mcp-Method 、 Mcp-Name 、 Authorization ヘッダーの 4 つです。 AWS WAF は最初の 3 つに対して直接マッチングやレート制限を行えます。一方、ベアラートークンの検証やデコードはできないため、トークンの検証はオリジンで行います。 この境界によって、セキュリティ対策は 2 つに分かれます。プロトコルやリクエスト形式に基づく制御 ( バージョンチェック、ツールの許可リスト、引数の検査、 SSRF パターンの検出、 SQL インジェクションの検出、 IP ベースのレート制限 ) は AWS WAF で行います。アイデンティティに基づく制御 ( ユーザーごとのレート制限、ロールに基づくツールへのアクセス、トークンの検証、きめ細かな認可 ) は、ベアラートークンを検証して呼び出し元が既知のプリンシパルであることを確認したあとに、 MCP サーバーで行います。 AWS WAF のルールスタック AWS WAF には、ベースラインの保護に向けたルールの推奨事項と、ルールの順序に関するベストプラクティスがあります。ベースラインとしてこれらのパターンに従うことをおすすめします。こちらの ブログ で、参考情報とあわせて詳しく説明しています。各ルールの JSON 内にある Priority は、評価順序を制御する AWS WAF のプロパティです。たとえば、軽量なヘッダーチェックを最初に、対象を絞った JSON ボディの検査を次に、レート制限を最後に配置します。本記事で使用している優先度の値は、あくまで一例です。重要なのは順序であり、具体的な数値ではありません。番号の間隔をあえて空けているのは、あとから新しいルールを追加する際に、ウェブ ACL 全体の番号を振り直さなくて済むようにするためです。 ユースケース 1：有効な MCP プロトコルバージョンを持たないリクエストを拒否する 後続のすべてのルールは、 Mcp-Method と Mcp-Name を意図を示すシグナルとして信頼します。この信頼が正当化できるのは、ヘッダーとボディの整合性検証が必須となるプロトコルバージョンをリクエストが宣言している場合に限られます。 2026 年 7 月 28 日の仕様改訂 でも、このことが明記されています。ミラーリングされたヘッダーに基づいてポリシーを適用する中間装置は、検証されていないヘッダー値を信頼するのではなく、 MCP-Protocol-Version が古いまたは存在しないリクエストを拒否すべきとされています。 このルールは、有効な MCP-Protocol-Version を持たない /mcp へのリクエストをすべてブロックします。単一のヘッダーをマッチングするだけでボディの検査を行わないため、スタックの中でもっとも軽量なルールであり、先頭に配置します。 ルールのロジック： パスが /mcp で始まり、かつ mcp-protocol-version ヘッダーが ^2026-07-28$ に一致しない場合にブロック { "Name": "RequireMCPProtocolVersion", "Priority": 1, "Action": { "Block": {} }, "Statement": { "AndStatement": { "Statements": [ { "ByteMatchStatement": { "SearchString": "/mcp", "FieldToMatch": { "UriPath": {} }, "PositionalConstraint": "STARTS_WITH", "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } }, { "NotStatement": { "Statement": { "RegexMatchStatement": { "RegexString": "^2026-07-28$", "FieldToMatch": { "SingleHeader": { "Name": "mcp-protocol-version" } }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } } } } ] } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "RequireMCPProtocolVersion" } } 正規表現にはアンカーを付けているため、わずかに異なる値 ( たとえば 2026-07-28-preview ) も拒否されます。新しいリビジョンがリリースされた場合は、 ^(2026-07-28|2026-11-15)$ のようにマッチする候補を追加してください。対象を /mcp に限定しているため、同じディストリビューション上のほかのコンテンツには影響しません。 ユースケース 2：AWS WAF Bot Control で各呼び出し元のアイデンティティにラベルを付ける エージェントによるトラフィックは、マシンによるトラフィックです。マシンの呼び出し元に付与できるもっとも強力なシグナルは、正規化されたアイデンティティラベルです。これにより、「どのエージェントが呼び出しているのか」と「どのツールを呼び出しているのか」を組み合わせて扱えます。この組み合わせこそがこのルールの特長であり、他のボディを検査するすべてのルールより前に Bot Control を配置する理由です。 AWS WAF Bot Control は、各リクエストにラベルを付与します。 MCP に関連するラベルのファミリーは、 Bot Control のラベルのリファレンス に記載されています。 呼び出し元の種類 ラベル 備考 検証済みクローラー awswaf:managed:aws:bot-control:bot:name:<name> awswaf:managed:aws:bot-control:bot:verified 検証済みボットに付与されるラベル Web Bot Auth を使用するエージェント awswaf:managed:aws:bot-control:bot:web_bot_auth:verified 署名の検証に失敗した場合は :invalid、:expired、:unknown_bot 識別可能なベンダー awswaf:managed:aws:bot-control:bot:vendor:<vendor_name> 現在は Amazon Bedrock AgentCore でホストされているエージェントに付与される クラウドでホストされている呼び出し元 awswaf:managed:aws:bot-control:signal:cloud_service_provider:<csp> サフィックスは aws、gcp、azure、oracle のいずれか ヘッドレスブラウザ awswaf:managed:aws:bot-control:signal:automated_browser MCP エンドポイントでは不審なものとして扱う Bot Control の共通の保護レベルには、デフォルトのアクションが Block に設定されたサブルールがいくつか含まれています。そのうち 5 つは、正当なエージェントのトラフィックに対して誤検知を起こすため、 MCP エンドポイントでは Count にオーバーライドする必要があります。 SignalNonBrowserUserAgent は、 User-Agent が実際のブラウザではない呼び出し元をブロックします。そのため、標準的な HTTP クライアント (python-requests 、Go の net/http 、 Node の fetch) を使用するエージェントフレームワークはすべて、このルールに引っかかります。 CategoryHttpLibrary は、既知の HTTP ライブラリを直接ブロックします。 curl や wget に加え、ほとんどの MCP クライアントのコードベースが依存している SDK も対象になります。 SignalAutomatedBrowser は、ヘッドレス Chrome 、Selenium 、Playwright をブロックします。これらは、エージェントフレームワークが内部でよく利用しているものです。 CategoryAI は、 AI エージェントのトラフィックであることを自ら名乗るトラフィックをブロックします。正当な MCP クライアントのほとんどは、このカテゴリに該当します。 SignalKnownBotDataCenter は、既知のクラウドデータセンターの IP 範囲からの呼び出し元をブロックします。 MCP エンドポイントへのエージェントのトラフィックの大半は、一般家庭の IP ではなくデータセンターから送信されます。そのため、このルールをそのまま有効にすると、正当な呼び出し元のほとんどがブロックされてしまいます。 これら 5 つをオーバーライドしても、Bot Control のそれ以外の保護機能は維持されます。具体的には、大量のリクエストでエンドポイントを攻撃するボットを止める Targeted の大量リクエスト向けルール ( TGT_VolumetricSession 、 TGT_VolumetricIpTokenAbsent ) 、スクレイパーや SEO カテゴリのブロック、そして後続のアイデンティティとツールを組み合わせたルールの入力となる Web Bot Auth ( WBA ) の判定です。グループ全体に対してウェブ ACL レベルで OverrideAction: Count を設定するのではなく、マネージドルールグループのステートメントで RuleActionOverrides を使用してください。前者の方法では、ルールグループ全体が Count になり、Bot Control の利点が失われてしまうからです。 ルールのロジック： 検査レベルを COMMON にした Bot Control ルールグループで、すべてのリクエストを評価する。 SignalNonBrowserUserAgent 、 CategoryHttpLibrary 、 SignalAutomatedBrowser 、 CategoryAI 、 SignalKnownBotDataCenter の各ルールを Count に設定し、ブロックせずにラベルだけを付与 { "Name": "BotControlCommon", "Priority": 2, "OverrideAction": { "None": {} }, "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesBotControlRuleSet", "ManagedRuleGroupConfigs": [ { "AWSManagedRulesBotControlRuleSet": { "InspectionLevel": "COMMON" } } ], "RuleActionOverrides": [ { "Name": "SignalNonBrowserUserAgent", "ActionToUse": { "Count": {} } }, { "Name": "CategoryHttpLibrary", "ActionToUse": { "Count": {} } }, { "Name": "SignalAutomatedBrowser", "ActionToUse": { "Count": {} } }, { "Name": "CategoryAI", "ActionToUse": { "Count": {} } }, { "Name": "SignalKnownBotDataCenter", "ActionToUse": { "Count": {} } } ] } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "BotControlCommon" } } 5 つのサブルールはすべて、オーバーライド後もラベル ( signal:non_browser_user_agent 、 bot:category:http_library 、 signal:automated_browser 、 bot:category:ai 、 signal:known_bot_data_center ) を付与します。そのため、後続のルールでこれらのラベルを引き続き利用できます。 Block によって評価が終了しなくなるだけです。 これらのラベルを利用できるような状態であると、後続のルールでアイデンティティの条件と Mcp-Name のマッチングを組み合わせられます。たとえば「呼び出し元の Web Bot Auth 署名が無効で、かつ高コストなツールを呼び出している場合はブロックする」といったルールを、独自のフィンガープリンティングのロジックなしで記述できます。次の例がそのルールです。 tools/call に一致し、ツールが expensive-tools パターンセットに含まれ、かつ Web Bot Auth のラベルが invalid または unknown_bot である場合にブロックします。 ルールのロジック： mcp-method ヘッダーが tools/call と等しく、かつ mcp-name が expensive-tools パターンセットに一致し、かつ呼び出し元の Web Bot Auth ラベルが invalid または unknown_bot である場合にブロック { "Name": "BlockUnverifiedBotOnHighCostTool", "Priority": 4, "Action": { "Block": {} }, "Statement": { "AndStatement": { "Statements": [ { "ByteMatchStatement": { "SearchString": "tools/call", "FieldToMatch": { "SingleHeader": { "Name": "mcp-method" } }, "PositionalConstraint": "EXACTLY", "TextTransformations": [ { "Priority": 0, "Type": "LOWERCASE" } ] } }, { "RegexPatternSetReferenceStatement": { "ARN": "arn:aws:wafv2:us-east-1:123456789012:global/regexpatternset/mcp-expensive-tools/def456", "FieldToMatch": { "SingleHeader": { "Name": "mcp-name" } }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } }, { "OrStatement": { "Statements": [ { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:managed:aws:bot-control:bot:web_bot_auth:invalid" } }, { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:managed:aws:bot-control:bot:web_bot_auth:unknown_bot" } } ] } } ] } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "BlockUnverifiedBotOnHighCostTool" } } BlockUnverifiedBotOnHighCostTool は、まず Count モードでデプロイしてください。そして一定の観察期間を設けて、呼び出し元に付与されるラベルの分布を確認してから、この組み合わせルールを Block に切り替えます。Bot Control の料金は、サブスクリプション料金とリクエストごとの評価料金で構成されます。有効にする場合は、その分の予算を確保してください。最新の料金は、 AWS WAF の料金と Bot Control の料金セクション を参照してください。 ユースケース 3：検査の前にサイズの大きすぎるリクエストボディをブロックする CloudFront における AWS WAF のボディ検査のデフォルトの上限は 16 KB です。ウェブ ACL の AssociationConfig を使用すると、この上限を 64 KB まで引き上げられます。本記事では上限を 32 KB に引き上げています。これは、一般的な MCP ツールの引数には十分なサイズでありつつ、過大なペイロードを招かない値です。 注意： AWS WAF を Application Load Balancer (ALB) に関連付けた場合、ボディ検査の上限は 8 KB に制限されており、引き上げることはできません。 MCP エンドポイントの前段に ALB を配置する場合は、ツールの引数を 8 KB 以下に抑えるか、ALB の前段に CloudFront ディストリビューションを配置して AWS WAF をそちらに関連付けてください。 設定した上限を超える部分は、各ルールの OversizeHandling の設定に従って処理されます。ボディを検査するすべてのルールで OversizeHandling: MATCH を設定すると安全ではありますが、ノイズが多くなります。正当なサイズの大きいボディが、すべてのルールに引っかかってしまうためです。代わりに、最初の段階で一度だけフェイルクローズする方針を取ります。具体的には、 32 KB を超えるボディを単一のサイズ制約ルールで拒否します。この設定があれば、サイズの大きすぎるボディは後続のルールに到達しないため、後続のすべてのルールで OversizeHandling: NO_MATCH を安全に使用できます。 この事前チェックを 32 KB で機能させるには、ウェブ ACL のボディ検査の上限を 32 KB 以上に設定する必要があります。デフォルトの 16 KB のままだと、16 KB から 32 KB の間のリクエストで OversizeHandling: MATCH が発動し、誤ったブロックが発生してしまいます。ウェブ ACL の作成時に上限を引き上げてください。 { "Name": "mcp-web-acl", "Scope": "CLOUDFRONT", "AssociationConfig": { "RequestBody": { "CLOUDFRONT": { "DefaultSizeInspectionLimit": "KB_32" } } }, "DefaultAction": { "Allow": {} }, "Rules": [ /* ... */ ] } プリフライトチェックのルールは次のとおりです。 { "Name": "MCPBodySizePreflight", "Priority": 5, "Action": { "Block": {} }, "Statement": { "SizeConstraintStatement": { "FieldToMatch": { "Body": { "OversizeHandling": "MATCH" } }, "ComparisonOperator": "GT", "Size": 32768, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "MCPBodySizePreflight" } } ユースケース 4：呼び出し可能なツールを許可リストで制限する 組織が 20 個のツールを公開していたとしても、ツールのレイヤーで最小権限の原則を適用するのであれば、エージェントには特定のタスクに必要なツールの呼び出しだけを許可すべきです。正規表現パターンセットを使用して呼び出し可能な範囲を制限しておけば、プロンプトインジェクションによってエージェントが execute_shell や delete_all_records を呼び出そうとしても、リクエストはエッジで 403 として止められ、サーバーには到達しません。 Mcp-Name はファーストクラスのヘッダーであるため、このルールはボディを解析しない、純粋なヘッダールールになります。 このルールは、 動的ラベル補間 を使用して、AWS WAF のリクエスト ID を含む JSON 形式の 403 レスポンスボディを返します。 ${awswaf:request_id:} というプレースホルダーは評価時に実際のリクエスト ID に置き換わります。これにより、呼び出し元はサポートに伝えるべき単一のフィールドを把握でき、オンコール担当者はログ内を直接 grep で検索できます。 ルールのロジック： リクエストヘッダーの mcp-method が tools/call と等しく、かつ mcp-name が許可されたツールの正規表現パターンセットに一致しない場合にブロック { "Name": "BlockUnapprovedMCPTools", "Priority": 10, "Action": { "Block": { "CustomResponse": { "ResponseCode": 403, "CustomResponseBodyKey": "McpBlockedTool", "ResponseHeaders": [ { "Name": "x-mcp-waf-request-id", "Value": "${awswaf:request_id:}" } ] } } }, "Statement": { "AndStatement": { "Statements": [ { "ByteMatchStatement": { "SearchString": "tools/call", "FieldToMatch": { "SingleHeader": { "Name": "mcp-method" } }, "PositionalConstraint": "EXACTLY", "TextTransformations": [ { "Priority": 0, "Type": "LOWERCASE" } ] } }, { "NotStatement": { "Statement": { "RegexPatternSetReferenceStatement": { "ARN": "arn:aws:wafv2:us-east-1:123456789012:global/regexpatternset/mcp-allowed-tools/abc123", "FieldToMatch": { "SingleHeader": { "Name": "mcp-name" } }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } } } } ] } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "BlockUnapprovedMCPTools" } } 参照先のレスポンスボディはウェブ ACL レベルで一度だけ定義するため、ほかの Block アクションでも再利用できます。 { "CustomResponseBodies": { "McpBlockedTool": { "ContentType": "APPLICATION_JSON", "Content": "{\"error\":\"tool_not_allowed\",\"waf_request_id\":\"${awswaf:request_id:}\",\"client_ip\":\"${awswaf:ip:}\"}" } } } 正規表現パターンセットは、サーバーの tools/list レスポンスから生成するため、マニフェストと常に同期した状態を保てます。初期の内容は、ツール名をアンカー付きの選択肢として連結したものです： ^(query_database|get_document|send_notification)$ ユースケース 5：query_database ツールで破壊的な SQL をブロックする 多くの MCP サーバーは、データベースにクエリを実行するツールを公開しています。 query 引数には、 LLM が組み立てた生の SQL が含まれます。プロンプトインジェクションによって、 SELECT が DROP TABLE に書き換えられてしまう可能性があります。 AWS WAF を使えば、リクエストがサーバーに到達する前に、破壊的なパターンをエッジで拒否できます。 このルールは、マネージドルールグループの AWSManagedRulesSQLiRuleSet とは異なります。このマネージドルールグループは、本来 SQL が含まれるべきではないフィールド向けに作られています。そのため構文パーサーを使用して、整った形式の SQL を見つけるとすべて検出してしまいます。そこには、ツールが本来実行すべき正当な SELECT クエリも含まれます。ここで説明するルールはより限定的です。 query 引数は SQL を扱うことが目的なので SQL 自体は許可しつつ、読み取り専用のツールが発行する必要のないサブセット ( DROP 、 TRUNCATE 、 ALTER 、 GRANT 、 DELETE FROM 、 UPDATE…SET ) をブロックします。 実装： ラベル付けルールは、 Mcp-Name ヘッダーが一致した場合に mcp:tool:query_database というラベルを付与します。ブロックルールは、このラベルが存在し、かつ query 引数に破壊的なキーワードが含まれている場合にのみ発動します。 ルールのロジック ( 2 つのルールの組み合わせ ) ： mcp-name が query_database と等しい場合に mcp:tool:query_database のラベルを付与する。次に、そのラベルが付与されていて、かつ /params/arguments/query が破壊的な SQL キーワードに一致する場合にブロック { "Name": "LabelToolQueryDatabase", "Priority": 15, "Action": { "Count": {} }, "RuleLabels": [ { "Name": "mcp:tool:query_database" } ], "Statement": { "ByteMatchStatement": { "SearchString": "query_database", "FieldToMatch": { "SingleHeader": { "Name": "mcp-name" } }, "PositionalConstraint": "EXACTLY", "TextTransformations": [ { "Priority": 0, "Type": "LOWERCASE" } ] } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "LabelToolQueryDatabase" } } { "Name": "BlockDestructiveSQL", "Priority": 20, "Action": { "Block": {} }, "Statement": { "AndStatement": { "Statements": [ { "LabelMatchStatement": { "Scope": "LABEL", "Key": "mcp:tool:query_database" } }, { "RegexMatchStatement": { "RegexString": "\\b(DROP|TRUNCATE|ALTER|GRANT|REVOKE|CREATE|DELETE\\s+FROM|INSERT\\s+INTO|UPDATE\\s+.+\\s+SET)\\b", "FieldToMatch": { "JsonBody": { "MatchPattern": { "IncludedPaths": [ "/params/arguments/query" ] }, "MatchScope": "VALUE", "InvalidFallbackBehavior": "MATCH", "OversizeHandling": "NO_MATCH" } }, "TextTransformations": [ { "Priority": 0, "Type": "COMPRESS_WHITE_SPACE" }, { "Priority": 1, "Type": "UPPERCASE" } ] } } ] } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "BlockDestructiveSQL" } } このツールは、データを読み取るためのものです。 query 引数に書き込みや削除のキーワードが含まれているのであれば、上流のどこかで何かが改ざんされています。もっとも可能性が高いのは、プロンプトインジェクションです。 COMPRESS_WHITE_SPACE によって、「D R O P」のような回避の試みも検出できます。 InvalidFallbackBehavior: MATCH を指定すると、 query 引数自体が含まれていないリクエストもブロックされます。欠落したフィールドを検査なしで通過させるのではなく、ポリシー違反として扱うためです。 ユースケース 6：ツールの引数に隠された SSRF を検出してブロックする 呼び出し元が指定した宛先に対してデータを取得 (fetch) 、名前解決 (resolve) 、送信 (post) する MCP ツールは、 SSRF の攻撃対象になりやすいものです。内部 IP 、クラウドのメタデータエンドポイント、サービス内部の DNS 名を指定する引数は、よく見られるパターンです。ボディを検査する単一のルールで、一般的なパターンをカバーできます。具体的には、インスタンスメタデータサービス (IMDS) のエンドポイント ( 169.254.169.254 ) 、 IPv4 のプライベートアドレス範囲、 IPv6 のループバックおよびユニークローカルのプレフィックス、クラスター内部のサービスに到達するための DNS 名です。マッチングの前に URL_DECODE を適用して、 1 回分のパーセントエンコーディングを展開します。 ルールのロジック： mcp-method が tools/call と等しく、かつ /params/arguments 内のいずれかの値がプライベート IP 、IMDS エンドポイント、内部 DNS 名に一致する場合にブロック { "Name": "BlockMCPSSRF", "Priority": 30, "Action": { "Block": {} }, "Statement": { "AndStatement": { "Statements": [ { "ByteMatchStatement": { "SearchString": "tools/call", "FieldToMatch": { "SingleHeader": { "Name": "mcp-method" } }, "PositionalConstraint": "EXACTLY", "TextTransformations": [ { "Priority": 0, "Type": "LOWERCASE" } ] } }, { "OrStatement": { "Statements": [ { "RegexMatchStatement": { "RegexString": "(169\\.254\\.169\\.254|metadata\\.google\\.internal|kubernetes\\.default(\\.svc)?|\\.(local|internal)([^a-z0-9.-]|$))", "FieldToMatch": { "JsonBody": { "MatchPattern": { "IncludedPaths": [ "/params/arguments" ] }, "MatchScope": "VALUE", "InvalidFallbackBehavior": "NO_MATCH", "OversizeHandling": "NO_MATCH" } }, "TextTransformations": [ { "Priority": 0, "Type": "URL_DECODE" }, { "Priority": 1, "Type": "LOWERCASE" } ] } }, { "RegexMatchStatement": { "RegexString": "\\b(10|127|169\\.254|172\\.(1[6-9]|2[0-9]|3[01])|192\\.168)\\.\\d{1,3}\\.\\d{1,3}\\b", "FieldToMatch": { "JsonBody": { "MatchPattern": { "IncludedPaths": [ "/params/arguments" ] }, "MatchScope": "VALUE", "InvalidFallbackBehavior": "NO_MATCH", "OversizeHandling": "NO_MATCH" } }, "TextTransformations": [ { "Priority": 0, "Type": "URL_DECODE" } ] } }, { "RegexMatchStatement": { "RegexString": "(::1|::ffff:|f[cd][0-9a-f]{2}:|fe80:)", "FieldToMatch": { "JsonBody": { "MatchPattern": { "IncludedPaths": [ "/params/arguments" ] }, "MatchScope": "VALUE", "InvalidFallbackBehavior": "NO_MATCH", "OversizeHandling": "NO_MATCH" } }, "TextTransformations": [ { "Priority": 0, "Type": "URL_DECODE" }, { "Priority": 1, "Type": "LOWERCASE" } ] } } ] } } ] } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "BlockMCPSSRF" } } ここで 2 つの注意点を挙げておきます。 1 つ目に、このルールは多層防御の一部であり、 SSRF に対する主要な対策ではありません。 AWS WAF のテキスト変換は 1 回しか実行されないため、 10 進数や 8 進数による IP のエンコーディング、 DNS リバインディング、マルチパスエンコーディングは、このルールをすり抜けてしまいます。主要な対策はネットワークレベルで行います。ツールを実行する環境で IMDSv2 を必須にし、セキュリティグループや VPC エンドポイントポリシーで送信先を制限してください。 2 つ目に、正当な理由でプライベートアドレスと通信するツール ( たとえば、 Kubernetes クラスターのイントロスペクションツール ) がある場合は、ラベルのマッチングを使って除外してください。グローバルなルールを緩めるよりも、「この特定のツールは .svc.cluster.local への到達を許可する」と定義する方が、判断が容易になります。 ユースケース 7：クエリ形式の入力に含まれる SQL インジェクションを検出する AWS WAF に SQL インジェクションの検出を組み込む方法は 2 つあります。AWS マネージドルールグループの AWSManagedRulesSQLiRuleSet を使用する方法と、組み込みのプリミティブである SqliMatchStatement を使用する方法です。マネージドルールグループは生のボディをルールセットと照合して検査するため、HTML フォームや URL エンコードされた API に対しては適切なデフォルトの選択肢です。しかし MCP の場合、ペイロードは JSON であり、脆弱性のあるフィールド ( sql 、 query 、 filter など ) は $.params.arguments 内の文字列です。JSON エンコードされても有効なままの典型的なインジェクションペイロードは、生のボディの検査をすり抜ける可能性があります。たとえば、値として埋め込まれた 1 UNION SELECT username, password FROM users は周囲の JSON 構造によって偽装されてしまいます。 MCP において信頼性の高いアプローチは、 AWS WAF の SQL パーサーを arguments フィールドに直接向けることです。 JsonBody に対して SqliMatchStatement を使用すると、まず指定した JSON パスにある文字列の値を抽出し、次にそれぞれの値に対して SQL の構文パーサーを実行します。JSON のラッパーではなく、実際の SQL の内容を検査するということです。ボディを検査するほかのルールと同様に、 tools/call にスコープを限定し、 SQL を正当に受け付けるツールをラベルチェーンで除外します。 ルールのロジック： mcp-method が tools/call と等しく、かつ mcp:tool:execute_sql のラベルが付与されておらず、かつ /params/arguments が感度 LOW の SQL インジェクションパーサーに検出された場合にブロック { "Name": "MCPSQLiProtection", "Priority": 40, "Action": { "Block": {} }, "Statement": { "AndStatement": { "Statements": [ { "ByteMatchStatement": { "SearchString": "tools/call", "FieldToMatch": { "SingleHeader": { "Name": "mcp-method" } }, "PositionalConstraint": "EXACTLY", "TextTransformations": [ { "Priority": 0, "Type": "LOWERCASE" } ] } }, { "NotStatement": { "Statement": { "LabelMatchStatement": { "Scope": "LABEL", "Key": "mcp:tool:execute_sql" } } } }, { "SqliMatchStatement": { "FieldToMatch": { "JsonBody": { "MatchPattern": { "IncludedPaths": [ "/params/arguments" ] }, "MatchScope": "VALUE", "InvalidFallbackBehavior": "NO_MATCH", "OversizeHandling": "NO_MATCH" } }, "SensitivityLevel": "LOW", "TextTransformations": [ { "Priority": 0, "Type": "URL_DECODE" }, { "Priority": 1, "Type": "HTML_ENTITY_DECODE" }, { "Priority": 2, "Type": "LOWERCASE" } ] } } ] } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "MCPSQLiProtection" } } SensitivityLevel は慎重に設定する必要があります。HIGH の場合、AWS WAF の SQL パーサーは整った形式の SQL をすべてフラグ付けします。単純な SELECT id FROM users LIMIT 10 であっても、SQL であるというだけで問題として扱われます。これは、呼び出し元が SQL を一切送信すべきではないエンドポイントには適していますが、フィルター式を受け付けるツールには適していません。MCP において実用的な設定は LOW です。LOW では、典型的なインジェクションマーカー ( OR 1=1 、 UNION SELECT 、 ; による複数ステートメントの連結、 EXEC xp_cmdshell ) を検出しつつ、通常のフィルター値にはフラグを立てません。 これに関連して、ここで述べておくべき設計上のポイントがあります。ツールが呼び出し元から任意の生の SQL を受け付ける場合、AWS WAF の感度設定では「安全な SELECT 」と「意図しない SELECT 」を区別できません。完全な SQL ステートメントは構文的に SQL であり、パーサーは SQL として扱わざるを得ません。 MCP ツールは、完全な SQL ステートメントではなく、構造化された引数 ( テーブル名、フィルター式、列のリスト ) を受け取るように設計してください。生の SQL を扱うツールは、管理者向けの execute_sql のように、限定的かつ除外されたパスに限定します。リファレンス実装では、 query_database は filter 引数 ( WHERE 句形式の式 ) を受け取り、 execute_sql はラベルによって除外された生の SQL 用のツールになっています。これが私たちの推奨するパターンです。 ユースケース 8：高コストなツールにレート制限を設ける Mcp-Name を使えば、ツールごとのレート制限を簡単に実装できます。 expensive-tools のパターンセットに含まれるツール ( データベースクエリ、有料 API、大量の計算処理 ) には控えめな制限を設定し、低コストなツールにはより緩い制限を設定します。AWS WAF の RateBasedStatement は、デフォルトでは IP ごとに集計します。MCP の場合は、 カスタム集約キー を使用してツールのヘッダーで集計し、特定の操作に上限を設けます。 EvaluationWindowSec には 60、120、300、600 秒のいずれかを指定できます。この例では 300 ( 5 分 ) を使用しています。 ルールのロジック： mcp-name が expensive-tools のパターンセットに一致し、かつ同じ mcp-name と送信元 IP の組み合わせによるリクエストが 300 秒間に 200 件を超えた場合にブロック { "Name": "MCPExpensiveToolRateLimit", "Priority": 50, "Action": { "Block": {} }, "Statement": { "RateBasedStatement": { "Limit": 200, "EvaluationWindowSec": 300, "AggregateKeyType": "CUSTOM_KEYS", "CustomKeys": [ { "Header": { "Name": "mcp-name", "TextTransformations": [ { "Priority": 0, "Type": "LOWERCASE" } ] } }, { "IP": {} } ], "ScopeDownStatement": { "RegexPatternSetReferenceStatement": { "ARN": "arn:aws:wafv2:us-east-1:123456789012:global/regexpatternset/mcp-expensive-tools/def456", "FieldToMatch": { "SingleHeader": { "Name": "mcp-name" } }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } } } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "MCPExpensiveToolRateLimit" } } Mcp-Name と送信元 IP の組み合わせで集計しているのは、単一の呼び出し元がツール全体の割り当て予算を使い切ってしまうことを防ぎつつ、多数の正当な呼び出し元がそれぞれ自分の割り当て分を利用できるようにするためです。これは、OAuth トークンをデコードせずに AWS WAF で実現できる「呼び出し元ごと・ツールごと」の制限にもっとも近い方法であり、エッジにおける妥当なデフォルトです。ただし、IP はアイデンティティの代わりとしては大まかな指標にすぎません。エージェントのトラフィックは少数のデータセンターの送信元 IP 範囲から送られる傾向があり、何千もの異なるユーザーがわずかな数の IP の背後にまとまってしまうことがあります。真のユーザーごとのレート制限を行うべきレイヤーはオリジンであり、ベアラートークンを検証してユーザーのアイデンティティを確立された後に行うべきです。 ユースケース 9 ( オプション )：IP ごとのグローバルなレート制限 ツールごとの制限に加えて、 /mcp パスを対象に IP 単位で集計するグローバルな RateBasedStatement を設定すると、全体の上限を設けられます。これにより、検証済みかどうかにかかわらず、単一の送信元が評価ウィンドウ内に N 件を超えるリクエストを送信できなくなります。 AWS WAF では EvaluationWindowSec の値として 60、120、300、600 をサポートしているため、トラフィックに対する考え方に合ったウィンドウを選択できます。一般的な設定は、IP ごとに 5 分間のウィンドウで 5,000 リクエストです。この設定であれば、正当なエージェントのワークロードを妨げることなく、暴走したループや明らかに悪意のある大量のリクエストを検出できます。ウィンドウを短く ( 60 秒 ) すると、バーストへの反応は速くなりますが、通常のトラフィックの変動に対する許容度は低くなります。 可観測性 (Observability) ブロックルールは全体像の半分にすぎません。 AWS WAF のログ記録 ( Amazon CloudWatch Logs、Amazon S3、Amazon Data Firehose への出力 ) を使用すると、リクエストごとの記録を取得できます。レコードにはヘッダー、終了ルール、適用されたラベル、最終アクションが含まれます。 Mcp-Method と Mcp-Name は httpRequest.headers に含まれているため、各ログエントリを見れば、どのツールが呼び出され、それがどう処理されたのかがわかります。 ツール名の抽出： AWS WAF のログでは、 httpRequest.headers は {name, value} オブジェクトの配列です。次の Amazon CloudWatch Logs Insights のクエリは、ツールごとに抽出・集計します。 fields @timestamp, action, terminatingRuleId, @message | parse @message /"name":"[Mm][Cc][Pp]-[Nn][Aa][Mm][Ee]","value":"(?<tool>[^"]+)"/ | filter ispresent(tool) | stats count() as invocations by tool | sort invocations desc | limit 10 図 2. 呼び出し回数の多いツールを表示するサンプルダッシュボード ツールの列挙攻撃の検出： 正常に動作している MCP クライアントは、2〜3 個のツールを予測可能なパターンで繰り返し呼び出します。プロンプトインジェクションによってエージェントが能力探索へと誘導されると、送信元 IP ごとの呼び出しツールの種類数が急増します。数分のうちに 3 種類から 15 種類へと呼び出すツールが増えた IP は、振る舞いの形状が変化しています。このクエリでは、承認済みツールに対するパラメーターの改ざんのような、より巧妙な手法は検出できません。それでも、単なるスループットではなく意図の変化を捉えられるため、早期警告として役立ちます。 次のクエリは、5 種類を超えるツールを呼び出している IP を抽出します。 parse @message /"name":"[Mm][Cc][Pp]-[Nn][Aa][Mm][Ee]","value":"(?<tool>[^"]+)"/ | parse @message /"clientIp":"(?<ip>[^"]+)"/ | filter ispresent(tool) | stats countDistinct(tool) as tools_called_by_ip, count() as total_reqs_by_ip by ip | filter tools_called_by_ip > 5 | sort tools_called_by_ip desc 図 3. 送信元 IP ごとの呼び出しツールの種類数。単一の IP から呼び出されるツールの種類数が急増している場合、プロンプトインジェクションによる能力探索が行われている可能性があります。 振る舞いのベースライン：エージェントのアイデンティティ × ツールのフィンガープリント： Bot Control の CategoryAI ルールは、エンドポイントを呼び出している検証済みの AI ボットを検出します。通常の運用では、検証済みのエージェントと、そのエージェントが呼び出すツールの関係は安定しています。未検証またはなりすましのエージェントには bot:name ラベルが付与されないため、この方法ではそれらを検出できません。それでも、昨日まで存在しなかった新しい ( エージェント、ツール ) ペアが出現した場合、上流で何かが変化したことを示すため、有用なベースラインになります。次のクエリは、この対応関係を作成します。 parse @message /awswaf:managed:aws:bot-control:bot:category:(?<category>[^"]+)/ | parse @message /awswaf:managed:aws:bot-control:bot:name:(?<bot_name>[^"]+)/ | parse @message /"name":"[Mm][Cc][Pp]-[Nn][Aa][Mm][Ee]","value":"(?<tool>[^"]+)"/ | filter category = "ai" and ispresent(tool) | stats count() as calls by bot_name, tool | sort calls desc 図 4. MCP エンドポイントへの検証済みと未検証のエージェントのトラフィックを示す AI トラフィック分析ダッシュボード AWS WAF コンソールで無料で利用できる AI トラフィック分析ダッシュボード を使用して、 MCP エンドポイントへの検証済みと未検証のエージェントのトラフィックを分析することもできます。 図 5. リクエスト数とカテゴリ別の上位のボットクローラー。MCP エンドポイントにアクセスしている Bedrockbot、Claudebot、GPTBot などの検証済み AI エージェントを識別しています。 異常検出： ラベル付けルールのメトリクスに対して Amazon CloudWatch 異常検出を使用し、過去の範囲からの逸脱を検知します。アーカイブしたログに対して Amazon Athena の日次クエリを実行し、「ツールの種類数」のシグナルを確認します。1 日のうちに呼び出すツールの種類数が 3 から 15 に急増したエージェントは、振る舞いの形状が変化しています。これは、通常のリクエスト量よりも強力なプロンプトインジェクションの兆候です。ブロックされた mcp-name の値について、上位コントリビューターを継続的に把握するには Amazon CloudWatch Contributor Insights を使用します。 アラート：ページング ( 呼び出し ) に値するアラートは、明示的なブロックに紐づけられています： SSRF のブロック ：即座にページング。SSRF のブロックは、内部のインフラストラクチャへの到達が実際に試みられていることを示します。 未承認ツールのブロックの急増 ：プロンプトインジェクションの可能性があるイベントとして調査します。ブロックされたツール呼び出しが急増している場合、エージェントが操作されている可能性があります。 レート制限への継続的な到達 ：人によるレビューにエスカレーションします。グローバルなレート上限に継続的に達している呼び出し元は、手動で調査すべきほど異常な動作をしています。 安全にデプロイする すべてのルールは、Block を有効にする前に Count モードでデプロイしてください。Count モードでは、トラフィックをブロックせずにリクエストを評価し、一致した結果を Amazon CloudWatch のメトリクスに記録します ( テストとチューニング ) 。サンプリングされたリクエストを確認して誤検知を特定し、スコープダウンステートメントやラベルに基づく除外でチューニングします ( サンプリングされたリクエスト ) 。影響を切り分け、必要に応じて個別のルールを元に戻せるように、ルールは 1 つずつ Block に切り替えてください。Block に切り替えたあとも、 SampledRequestsEnabled は true のままにしておきます。 AWS WAF は、ルールごとに一致したリクエストのデータを 3 時間保持します。 まとめ 2026 年 7 月 28 日の改定により、 MCP はヘッダーに十分な構造化メタデータを持つ HTTP プロトコルとなり、エッジでのセキュリティ対策が現実的な選択肢になりました。適切な順序で構成した AWS WAF のスタックを使えば、 MCP サーバーのコードを変更することなく、堅牢な境界防御を実現できます。 AWS WAF のログとラベルをもとに構築した可観測性のレイヤーにより、その境界全体でエージェントが何をしているのかを把握できます。ユーザーごとのレート制限は、意図的にエッジでは行っていません。ユーザーごとのレート制限は、ベアラートークンを検証し、呼び出し元の ID を明確に扱えるオリジンで行うべきものです。ユーザーや IP に基づくレート制限を実現するさまざまな手法については、ほかにもいくつかのブログで紹介しています。たとえば、 Limiting requests to a web application using a Gatekeeper Solution を参照してください。 著者について Jaiganesh Girinathan Jaiganesh Girinathan は、AWS のコンテンツ配信ネットワークとエッジコンピューティングの機能を専門とするプリンシパルエッジスペシャリストソリューションアーキテクトです。過去 20 年にわたり世界中のメディア業界のお客様を支援し、プラットフォームのモダナイズと拡張に取り組んできました。お客様の重要なニーズに応えるソリューションの構築に情熱を注いでいます。仕事以外では、たいてい星空を眺めています。 Harith Shantan Gaddamanugu Harith は、AWS のシニアエッジスペシャリストソリューションアーキテクトです。世界中の何百万人ものユーザーが利用する、重要なインフラストラクチャとセキュリティのソリューションを設計しています。クラウドの境界防御とウェブの高速化に関する 10 年の専門知識を活かし、レジリエントなアーキテクチャを構築する大企業を支援しています。仕事以外では、家族とのハイキングや風景写真の撮影を楽しんでいます。 Kaustubh Phatak Kaustubh は、AI/ML システムとエンタープライズ向けセキュリティソリューションを専門とするプロダクトリーダーです。AI を活用したプロダクトを大規模に展開する部門横断チームを率い、セキュリティアーキテクトや CISO と緊密に連携しながら、AI のイノベーションとサイバーセキュリティリスクが交わる領域の課題に取り組んできました。とくに、従来のフレームワークが通用しない新しい技術領域において、複雑な技術的機能をビジネス価値へと結びつけることに注力しています。 Ted Middleton Ted Middleton は、AWS のエッジスペシャリストソリューションアーキテクトチームのグローバルリーダーであり、以前は CloudFront チームのプリンシパルプロダクトマネージャーを務めていました。CDN とエッジサービスにおいて 20 年以上の経験を持っています。 翻訳はプロフェッショナルサービスの鈴木（隆）が担当しました。

本記事は 2026 年 10 月 28 日に Kiro ブログで公開された「 Kiro for Students expands to 41 more universities 」を翻訳したものです。 Kiro for Students の対象を、世界の 41 大学に広げます。対象校の学生は Kiro を 1 年間無料で使えます。毎月 1,000 クレジットと、プレミアムモデルなどの有料機能が含まれます。対象校は 対象大学の一覧 でご確認ください。 申し込み方法 いただいたフィードバックをもとに、申し込みの流れをできるだけスムーズになるよう見直しました。 申し込みの手順は次のとおりです。 IDE 、 CLI 、 Web 、 Crew のいずれかで、Google、GitHub、AWS Builder ID を使って Kiro にサインアップまたはサインインします。 サインイン後に設定 (Settings) ページを開き、Students セクションをクリックします。ドロップダウンで自分の学校が対象かどうかを確認し、verify をクリックして学生認証を完了します。 SheerID による学生認証では、氏名、生年月日、大学のメールアドレスの入力が必要です。在籍を確認するため、認証の途中で追加の書類を求められる場合があります。SheerID での認証で問題が起きた場合は、 フォーム から SheerID にお問い合わせください。 認証が終わると設定ページのティア名が Kiro Students に変わり、すぐに毎月 1,000 クレジットを丸 1 年間使えるようになります。 在籍している大学が現在の対象校に含まれていない場合は、 こちら から追加をリクエストできます。 いくつか注意点があります。 認証は 1 回だけです。 学生認証は 1 回しか行えないため、入力内容に誤りがないか確認してください。 毎月のクレジットについて。 1,000 クレジットを使い切った場合は、次の月のサイクルまで待つ必要があります。使わなかったクレジットは翌月に繰り越されません。このプランでは追加のクレジットを購入できません。 1 年が過ぎたあと。 1 年間の利用期間が終わると、アカウントは自動的に Kiro の無料プランに切り替わります。 Kiro Students に含まれるもの 毎月 1,000 クレジット付きで Kiro を丸 1 年間無料で使え、有料プランで提供しているモデルも利用できます。Kiro は IDE、CLI、Kiro Web、Kiro Crew の 4 つの形で使えます。学期中にそれぞれをどう使うかは こちらの記事 で紹介しています。やりたいことを伝えると Kiro が作業を分解し、主導権はあなたが持ち続けます。これは卒業後も役立つスキルです。コードを書くことだけでなく、難しい問題を分解し、適切なツールを選び、作業を指揮する力が身につきます。 この取り組みの背景 9 月に学生プログラムを 133 大学へ広げて以来、対象校の追加を求める声を数多くいただきました。学生はすでに次の時代のものを作り始めています。プロ仕様のツールを学ぶのに最適なのは、自由に試し、壊し、プレッシャーなく学べる学生のうちです。AI エージェントはエンジニアの標準的な道具になりつつあり、すべての学生が実際に使える環境を届けたいと考えています。 キャンパスにも、世界中にも Kiro をキャンパスに直接届ける取り組みを、より多くの国に広げています。 Kiro Student Discord コミュニティに参加 すると、世界各地の一部の学校で開催するキャンパス訪問、ワークショップ、ハッカソンの最新情報を受け取れます。日程や詳細はまず Discord でお知らせします。 在籍している学校で、Kiro と ハッカソンを共催 しませんか。どの国の学校でも、ぜひ一緒に取り組みたいと考えています。 始めましょう 詳細と申し込みは kiro.dev/students をご覧ください。作ったものはぜひ #KiroStudents を付けてシェアしてください。Kiro の公式アカウントは X の @kirodotdev 、 LinkedIn 、 Instagram 、Bluesky の @kiro.dev です。 Kiro for Students には追加の 利用規約 が適用されます。 皆さんが何を作るのか、楽しみにしています。 翻訳者について 稲田 大陸 – いなりく AWS Japan で働く Kiro をこよなく愛すソリューションアーキテクト。普段は製造業のお客様を支援しています。その活動の傍ら、最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、 Kiro のブログ などを執筆しています。

概要 この記事はもともと AWS Korea Tech Blog に韓国語で掲載されたものです。 韓国語版はこちら 。 AMOREPACIFIC の ERP Platform Planning チームは、Kiro の spec-driven development（仕様駆動開発）、MCP サーバー、そして Steering ファイルを活用し、SAP ECC 6.0 上の ABAP と SAPUI5 に AI 駆動開発を導入しました。4 つのプロジェクトを通じて、同チームは最大 72% の生産性向上と 80% のドキュメント作成時間の削減を計測しました。 本記事では、同チームがどのように Kiro をレガシーな SAP システムに接続し、チームのコーディング標準に従うよう構成したかを紹介します。また、Kiro が同チームの Jira ベースのワークフローにどのように組み込まれたか、そしてチームが計測した成果についても取り上げます。 AMOREPACIFIC はグローバルな化粧品企業です。その ブランド には Sulwhasoo、AESTURA、LANEIGE、HERA、IOPE などがあります。市場は韓国、アジア、南北アメリカ、ヨーロッパに及びます。販売は自社店舗、 AMOREMALL 、および各ブランドの公式オンラインモールを通じて行われています。これらのコマースチャネルは成長を続け、変化し続けています。 図 1: AMOREPACIFIC のオンライン販売チャネルの 1 つである AMOREMALL ライブコマースチャネル。 このブランドポートフォリオとコマースインフラストラクチャの背後には、数十年にわたって構築されてきた SAP ERP システムがあり、ビジネスの大部分を支えています。AI がソフトウェアの書き方を変えていく中で、AMOREPACIFIC の ERP Platform Planning チームは 1 つの問いを立てました。 AI 支援による開発は、レガシーな SAP 環境で機能するのか？ 背景 AMOREPACIFIC は NetWeaver 7.40 上で SAP ECC（ERP Central Component）6.0 EHP7 を運用しています。FI、CO、SD、MM といったコアモジュールに加え、同チームは拡張 ERP 機能と SAPUI5 フロントエンドを運用しています。開発者は ABAP バックエンドを SAP GUI で、SAPUI5 フロントエンドを NWDS（NetWeaver Developer Studio） で記述しています。 これらのツールは長年にわたってチームを支えてきました。チームは AI のトレンドに乗り遅れないよう、AI ツールを使って開発者の生産性を高めたいと考えていました。そこで AWS と共同で AI-DLC（AI-Driven Development Life Cycle） フレームワークを定義するプロジェクトを開始しました。プロジェクトは 2025 年 8 月から 2026 年 3 月まで実施されました。 チームは複数の AI コーディングツールを比較し、 Kiro を選択しました。汻め手となったのは spec-driven development（仕様駆動開発） です。Kiro はまず、要件・設計・実装計画を網羅した構造化された仕様を作成します。その後、その仕様からコードを生成します。SAP 開発はすでにこの順序で進められています。開発者はコードを書く前に FS/TS（機能仕様書／技術仕様書）を作成します。これにより、チームは Jira ベースのワークフローを変更することなく AI を採用できました。Kiro に SAP システムへのアクセスを与えるため、チームは AWS ソリューションアーキテクトが構築した SAP 専用の MCP サーバーを使用しました。安定性と長期的な保守性の観点から、これが最適だとチームは判断しました。 プロジェクト開始前、チーム独自の分析では、SAP のコンテキストやチームの規約を考慮しない AI コーディングツール単体による生産性向上を 20% から 30% と見積もっていました。 図 2: Kiro の spec-driven development（仕様駆動開発）: コードを書く前の要件・設計・実装計画。 SAP 開発に AI を適用する際の課題 1. GUI ベースの環境 SAP 開発は Web ブラウザではなく SAP GUI 上で行われます。さらに重要なのは、SAP 開発の多くがそもそもコーディングではないという点です。それは GUI を介した構成作業です。 SE11 でのテーブル作成、 SPRO での設定、 PFCG での権限設定などです。これらの作業は AI コーディングツールでは自動化できません。 また、ほとんどの AI コーディングツールは、ファイルシステム上にソースコードが存在することを前提としています。ABAP コードは SAP サーバー内部に存在し、ローカルファイルとしては利用できません。ソース統合がなければ、AI コーディングツールは作業対象を持ちません。 2. MCP サーバーの不在と、限定的な ADT サポート AI ツールが SAP システムを理解するには、 MCP（Model Context Protocol） サーバーが必要です。2025 年 8 月にプロジェクトが始まった時点では、SAP 向けの公式 MCP サーバーは存在しませんでした。チーム独自のカスタム RFC ファンクションモジュール、 ABAP の命名規則 、SAPUI5 フレームワークのパターンをモデルに渡す手段がなかったのです。 NetWeaver 7.40 上の SAP ECC 6.0 は、 SAP S/4HANA と比べて SAP ADT（ABAP Development Tools） のサポートも限定的です。AI ツールはシステムからテーブル構造や RFC ファンクションモジュール を読み取ることはできますが、生成したコードをシステムに書き戻すことには技術的な制約があります。 3. 非標準の SAPUI5 フロントエンド SAPUI5 開発は ABAP よりも複雑な環境で行われていました。チームは標準の SAP Fiori を使用していません。 NWDI（NetWeaver Developer Infrastructure） 上で Portal Application Standalone プロジェクトを運用しています。 領域 ABAP バックエンド SAPUI5 フロントエンド 開発ツール SAP GUI NWDS 上の Portal Application コーディングスタイル 標準 SAP ABAP 社内カスタムフレームワーク AI 適用の障壁 GUI ベース、ソース統合が限定的 非標準フレームワーク、多数の社内規約 4. モデルが知っておくべき規約 モデルに通常の ABAP や SAPUI5 コードを生成させること自体は難しくありません。本当の課題は、このチームが書くのと同じやり方でコードを生成させることです。 ABAP 側では、チームは長年にわたって蓄積した標準を持っています。TOP、F01、C01 の Include プログラムのパターン、 ALV レポート のスケルトン、 選択画面 の定義などです。SAPUI5 側には、カスタムフレームワーク、 IIFE （即時実行関数式）パターン、そして Jira チケットに対して管理される FS/TS ドキュメントシステムが加わります。 ソリューション AI コーディングツールを単にインストールするだけでは不十分です。これらの課題に対処するため、チームはまず MCP サーバーを通じてシステムのコンテキストを、 Steering を通じてコーディング標準を取り込む必要がありました。その両方を AWS とともに解決したことが、このプロジェクトの出発点です。 AI-DLC: SAP 開発に AI を適用する チームが AWS と共同で設計した AI-DLC フレームワークは、既存の開発ツールを置き換えるものではありません。設計、コーディング、ドキュメント作成の全体にわたって、AI を既存のワークフローに統合するものです。 開発パラダイム これまで Kiro と AI-DLC を用いた場合 開発者の役割 コードを書く 要件を定義し、生成されたコードをレビューする 設計とコードの連携 FS/TS を読み、頭の中で翻訳する Kiro が FS/TS を仕様ドキュメントに構造化する 反復的なボイラープレート 毎回、オートコンプリートを使いながら手作業で記述 確立されたパターンから生成 コーディング標準 各開発者が記憶して適用する Steering ファイルから自動的に適用される ドキュメント 開発完了後の別作業 コード生成に合わせて仕様ドキュメントが同期し続ける 知識の依存度 経験豊富な開発者に集中 コンテキストは Kiro から提供され、チーム全体に広がる 要点は、ツールではなくチームの働き方を変えることでした。従来の SDLC（ソフトウェア開発ライフサイクル） では、人が主導しツールが補助します。AI-DLC は重心を移します。人が意思決定し、AI が実行を加速するのです。 このフレームワークは 3 つの構成要素、すなわち Kiro、MCP サーバー、Steering の上に成り立っています。 1. Kiro: 設計を起点とする開発 Kiro は、spec-driven development（仕様駆動開発）をサポートする AWS の AI 駆動開発環境です。チームは目の前の作業内容に応じて、Kiro の 2 つのモードを使い分けました。 図 3: Spec モードと Vibe モードの選択、Steering の構成、MCP サーバー接続を示す Kiro IDE。 Spec モード: 構造化された新規開発。 Spec モードは新規プロジェクトや複雑な機能に適しています。Kiro は要件、次にシステム設計、そして実装計画という 3 段階の設計プロセスを実行します。 図 4: 要件から実装計画までの Spec モードによる自動設計フロー。 Vibe モード: チャットによる高速な反復。 Vibe モードは、すでに仕様ドキュメントが存在するプロジェクトで、会話を通じてコードを素早く変更します。開発者が変更内容を自然言語で説明すると、Kiro は既存の仕様ドキュメントを参照し、コンテキストに適合した変更を行います。 図 5: Vibe モードのプロセスフロー: チャットベースの反復開発。 Spec か Vibe か: どちらのモードをいつ使うか？ 領域 Spec モード Vibe モード 適した用途 新規プログラム、複雑な新機能 既存プログラムの変更、バグ修正 前提条件 Jira チケットと FS/TS ドキュメントまたは要件 仕様ドキュメントがすでに存在すること Kiro の動作 要件 → 設計 → タスクの 3 つの構造化された段階 チャットでの会話的な変更 スピード 最初に設計へ時間をかけ、その後は体系的に開発 即座のコード変更 成果物 3 つの仕様ドキュメント、ABAP または SAPUI5 コード、DDIC* 更新されたコードと更新された仕様ドキュメント 典型的なシナリオ 新規レポート、新規インターフェース、複雑なビジネスロジック フィールドの追加・削除、ロジック変更、UI テキスト変更、バグ修正 *DDIC（SAP Data Dictionary）: テーブル、構造、ドメインを定義する SAP のメタデータリポジトリ。 この中核的な実験は、新規要件には Spec モードを、変更には Vibe モードを使うことで、初期設計の品質と保守の俊敏性を同時に実現できるかどうかというものでした。 注: チームは Kiro IDE 0.x を使用しており、チャット開始時に Spec セッションか Vibe セッションを選択します。Kiro IDE 1.0 では、セッションは Vibe モードのように動作する汎用エージェントで開始し、Spec はいつでも開始できる組み込みワークフローになっています。詳細は Kiro IDE 0.x リファレンス を参照してください。 2. MCP: Kiro と SAP をつなぐコンテキストの橋渡し MCP は、AI IDE と外部システムの間でコンテキストを共有するためのオープンプロトコルです。Kiro を SAP システム内の既存コード、データ構造、ビジネスロジックに接続し、Kiro がそれらを読み取り参照できるようにします。 図 6: MCP サーバーを介して SAP タスクを実行する Kiro。 汎用モデルはプログラミングの方法は知っていますが、この SAP システム内のカスタム RFC ファンクションモジュール、テーブル構造、ビジネスロジックは知りません。MCP サーバーがそのコンテキストをモデルに渡します。Kiro に ZXXX_GET_EMPLOYEE_DATA RFC ファンクションを呼び出すコードを生成する よう依頼すると、MCP サーバーはそのファンクションのパラメータ構造、戻り値、使用例をリクエストとともに提供します。 チームは MCP サーバー をユーザーレベルで一度 ~/.kiro/settings/mcp.json に構成し、ABAP RFC ファンクションモジュールと SAPUI5 バックエンドの RFC の両方を分析するようにしました。この構成は AMOREPACIFIC の SAP 開発者のすべての Kiro プロジェクトに適用されるため、新しいプロジェクトごとに環境を再構築する必要はありません。 注: AWS はその後、SAP 向けの Kiro サンプルエージェントを公開しました。それらには 80 以上の事前構築ルールを含む Steering ファイルが含まれ、機能仕様書と技術仕様書を生成し、ABAP コード変換と単体テストを自動化します。ABAP に加えて、SAP BW から SAP BDC（Business Data Cloud）への変換、および SAP PI/PO から SAP Integration Suite への変換のための Kiro エージェントもあります。はじめるには、 Kiro で SAP モダナイゼーションを加速 を読み、 サンプルエージェントの GitHub リポジトリへのアクセスを登録 してください。 3. Steering: AMOREPACIFIC のコードの書き方を Kiro に教える Steering は、モデルの振る舞いをガイドする一連のドキュメントです。Kiro はコードを生成するたびに ~/.kiro/steering/ 内のファイルを自動的に参照します。チームのコーディング標準は、誰かがプロンプトを書かなくてもコードに反映されます。 汎用モデルは、このチームの変数命名規則、Include 構造、エラーハンドリングのパターン、 g.get() フレームワークの使い方を自力では守りません。Steering ファイルがそのギャップを埋めます。チームがコードの書き方を一度ドキュメント化すれば、Kiro が生成するものはすべて、詳細なプロンプトなしにそれらの標準に従います。 チームは ABAP 用と SAPUI5 用の Steering ファイルを別々に用意しました。 図 7: 組織のコーディング標準ガイドとしての Steering: 汎用コードジェネレーターが Steering ファイルを参照することで社内標準に従う。 Steering ファイル 対象範囲 何を伝えるか product.md 共通 SAP ECC 6.0 環境、モジュール構成、ビジネスルール tech.md ABAP ABAP コーディング標準、命名規則、Include 構造 structure.md 共通 プロジェクトのディレクトリ構造、成果物フォーマット sapui5-development.md SAPUI5 NWDI Portal Application ガイド、 g.get() API、IIFE パターン、ERP 通信パターン、 _new サフィックスルール design_doc_template.md 共通 FS/TS 成果物テンプレート、Jira チケットフィールド アーキテクチャ: Jira から SAP まで ECC 6.0 の書き戻し制約を回避するため、Kiro は生成したコードを共有フォルダに書き出し、開発者がそれを SAP に移します。図 8 は Jira チケットから SAP システムまでの全体フローを示しています。 図 8: Jira チケットから Kiro と共有フォルダを経て SAP GUI および NWDS に至るアーキテクチャ。 ここで FS/TS が Spec モードにマッピングされます。Jira チケットの要件は requirements.md に、FS/TS 設計ドキュメントは design.md に、作業分解は tasks.md になります。このマッピングのおかげで、チームは既存プロセスを大きく変えることなく Kiro と連携できました。Jira ベースの要件管理と AI コード生成が、いまやつながっています。 ABAP は SAP GUI（ABAP エディター用の SE38、ABAP ディクショナリ用の SE11）を介して SAP に、SAPUI5 は NWDS を介して SAP に投入されます。このアプローチはどの SAP リリースでも機能し、レビューステップが組み込まれています。生成されたコードがシステムに到達する前に、開発者がチェックするのです。 ABAP と SAPUI5 のための AI-DLC プロセス チームの AI-DLC フレームワークは以下のプロセスで実行され、ABAP バックエンドと SAPUI5 フロントエンドの双方に同じように適用されます。 図 9: ABAP と SAPUI5 のための 6 ステップの AI-DLC プロセス。 ステップ 5 はステップ 4 にループバックします。エラーが発生すると、開発者は Kiro と協力してコードを修正し、再適用します。 ステップ 主な活動 成果物 1. 環境をセットアップする Kiro をインストールし、MCP サーバーを接続し、Steering ファイルを配置する 稼働する開発環境 2. ドキュメントを準備する Jira チケットを確認し、既存の FS/TS を docs/ フォルダに保存する requirements.md （Jira の詳細が自動的に取り込まれる） 3. モードを選択する 新規開発 → Spec、変更 → Vibe なし 4. コードを生成する Kiro が Steering ルールに従ったコードを生成する ABAP（ .abap ）、SAPUI5（コントローラーとビュー）、DDIC（TSV） 5. システムに適用する 生成されたコードを SAP GUI または NWDS を介して SAP に移す アクティベートされたオブジェクト、トランスポートリクエスト 6. クローズアウトする 仕様ドキュメントを同期し、FS/TS 成果物を生成する Jira チケットにリンクされた FS/TS 成果物（ .md または .html ） このプロセスを支える 1 つの原則があります。コードが変わるとき、その変更のもとになったドキュメントも一緒に変わる、ということです。コードと仕様ドキュメントは常に一緒に動くため、設計とコードの乖離がその源で取り除かれます。 成果 およそ 8 か月にわたり、チームはこの働き方を 4 つのプロジェクト、すなわち 1 つの ABAP バックエンドプロジェクトと 3 つの SAPUI5 フロントエンドプロジェクトに適用しました。プロジェクト開始前、チーム独自の分析では生産性向上を 20% から 30% と見積もっていました。4 つのプロジェクトにわたるチーム自身の計測では、AI-DLC フレームワークと MCP サーバーによって生産性が最大 72% 向上しました。成果物とソースコードも最新の状態に保たれ、設計とコードが同期し続けました。 パイロット 1: ABAP バックエンド、Spec モードによる新規開発 目標: Kiro の spec-driven development（仕様駆動開発）を新規要件に適用し、AI-DLC フレームワークを検証する。 プロジェクト: 新しい SAP レポート（Jira チケット ERP-101）。 結果: 既存のフローはシンプルですが反復的でした。Jira チケットが起票され、開発者が FS/TS を書き、コードを書き、レビューに持ち込む、という流れです。Kiro はそのフローを変えました。Spec モードは FS/TS を requirements.md 、 design.md 、 tasks.md に変換します。また、 TOP と F01 の Include や ALV レポートのスケルトンを含むボイラープレートを、DDIC TSV ファイルとともに生成します。反復的な作業がなくなったことで、開発者は要件の検証とビジネスロジックの実装に集中できるようになりました。 パイロット 2: SAPUI5 フロントエンド、Spec モードと Vibe モードの併用 目標: 新規開発には Spec モードを、変更には Vibe モードを使い、AI-DLC が SAPUI5 環境にも拡張できるかを検証する。 プロジェクト: HR 勤怠管理画面の改善（ERP-102）、HR 承認プロセスの変更（ERP-103）、新しい HR モバイルビュー（ERP-104）。 結果: SAPUI5 Portal Application 開発には、NWDI 独自のフォルダ構造（ ui.pdk.{code} 、 _comp/dist/mvc/ ）、カスタムフレームワーク、IIFE パターン、ファイル管理ルールが伴います。経験豊富な開発者でもミスをする領域です。 sapui5-development.md という 1 つの Steering ファイルを追加するだけで、これらのルールがすべて自動的に適用されました。 ドキュメントも変わりました。FS/TS 成果物は design_doc_template.md から生成されるようになり、ドキュメント作成時間が 80% 削減されました。Jira チケット番号、タイトル、依頼者が自動的に取り込まれるため、チームは 100% の要件トレーサビリティを得ました。 2 つのパイロットが改善したもの 領域 これまで AI-DLC を用いた場合 効果 Jira チケットからコードへ FS/TS を書き、その後に手作業でコーディング Kiro の Spec モードが構造化する 要件の解釈にかかる時間が短縮 反復的なボイラープレート 毎回手作業で記述 Kiro が生成 初期コーディング時間が短縮 コーディング標準 レビュー時に手作業でチェック Steering から自動的に適用 コードレビューのサイクルが短縮 DDIC 定義（ABAP） SE11 で手作業で入力 生成された TSV から貼り付け DDIC オブジェクト作成時間が短縮 FS/TS 成果物 開発後に手作業で記述 Kiro が生成 ドキュメント作成時間が 80% 削減 スタック間の壁 ABAP と SAPUI5 は分離されたまま 両者にまたがる 1 つのフレームワーク 開発者がスタック間を移動できる 仕様とコードの同期 しばしばずれる 100% で同期 長期的な保守コストの低減 定性的な成果 数字以上に重要なのは、開発者がいま何をしているかという変化です。AI-DLC 以降、開発者はコードを 1 行ずつ打ち込む時間が減り、要件を検証し Kiro が生成したものをレビューする時間が増えました。 Steering はまた、技術スタック間の壁を下げました。ABAP 開発者がいまや SAPUI5 Portal Application の構造を読み、それを直接変更できます。ABAP パイロットに参加したある開発者は、その後 SAPUI5 である 2 つ目のパイロットに貢献しました。 新人開発者にとって、かつての主な障害はカスタムフレームワークの呼び出し構造と NWDI の複雑なフォルダレイアウトでした。Steering がその学習曲線を吸収します。開発者はいまや、その時間を構造の解明ではなく開発に充てられます。結果として、チームは新人開発者のオンボーディング時間が短縮されると見込んでいます。 4 つのプロジェクトはすべて、仕様ドキュメントとコードを 100% 同期させた状態に保ちました。仕様が先に書かれ、そこからコードが生成されるためです。Jira チケット、FS/TS、コーディング、ドキュメントという別々の段階が、いまや 1 つのフローになりました。 Jira チケット → Kiro Spec モード → 生成されたコード → 生成された FS/TS 成果物 です。 今後の展望 AMOREPACIFIC はこのプロジェクトを出発点ととらえ、次のステップを準備しています。 1. GitLab リポジトリ統合。 チームは Kiro プロジェクトフォルダ（ .kiro/specs/ 、 ABAP_Code/ 、 ui.pdk.{code}/ 、 docs/ ）を、バージョン管理とコラボレーションのために AMOREPACIFIC の GitLab に保存する計画です。仕様ドキュメント（ .md ）、生成されたコード、FS/TS 成果物を Git で管理することで、チームは変更履歴を得て、チーム全体での共有を日常的なものにできます。 2. Jira と Confluence の MCP 統合による、エンドツーエンドの自動化。 今日、開発者は Jira の Web インターフェースからチケットの詳細を Kiro にコピーしています。Jira MCP 統合が整えば、Kiro はチャットから直接 Jira の課題を照会し、それを仕様ドキュメントに取り込めます。Kiro に Jira チケット ERP-102 の要件から仕様ドキュメントを作成する よう依頼すると、Jira API を通じてチケットを取得し、 requirements.md を生成します。開発後は、FS/TS 成果物を Confluence にアップロードします。これにより、Jira → Kiro → SAP → Confluence というエンドツーエンドのフローが完成します。 3. AI コーディングアンバサダー。 AI-DLC の経験が最も豊富なパイロット開発者が、Steering ドキュメントの作成を指導し、他チームに 6 ステップのプロセスを教え、トラブルシューティングを支援することで、他チームへの展開を推進します。 まとめ AMOREPACIFIC は、手が届かないように見えていた GUI ベースのレガシーな SAP ECC 6.0 環境に AI 駆動開発を導入し、4 つの ABAP および SAPUI5 プロジェクトに適用しました。 このプロジェクトの核心は新しいテクノロジーではありません。人を中心とした開発から AI を中心とした開発へという、チームの働き方の転換です。Kiro の spec-driven development（仕様駆動開発）のアプローチ、AWS ソリューションアーキテクトが構築した SAP MCP サーバー、そして Steering ドキュメントが一体となって、AI が組織のコーディング標準に従えるようにしました。チーム自身の計測では、プロジェクト前の 20% から 30% という見積もりに対し、生産性は最大 72% 向上しました。成果物とソースコードは最新の状態に保たれ、設計とコードは同期し続けました。spec-driven development（仕様駆動開発）が SAP の既存の FS/TS 設計文化と合致していたため、開発者はほとんど抵抗なくそれを採用しました。 AMOREPACIFIC の経験が、レガシーシステムの制約を理由に AI 導入をためらっているエンタープライズの開発チームにとって役立つことを願っています。このアプローチを試すには、次のとおりです。 Kiro からはじめ、 AI-Driven Development Life Cycle について読んでください。 SAP 向けの Kiro サンプルエージェントについては、 Kiro で SAP モダナイゼーションを加速 で詳しく学び、 サンプルエージェントへのアクセスを登録 してください。ABAP 向け、BW から SAP BDC への変換、PI/PO から Integration Suite への変換のためのエージェントがあります。 AI-DLC に関する別のお客様事例については、 AI-DLC で Woongjin ThinkBig の Book Curator AI エージェントを構築する（韓国語） を参照してください。 ご自身の SAP 環境に向けた AI 駆動開発を計画するには、担当の AWS アカウントチームにお問い合わせください。 このエンゲージメントを当初から AMOREPACIFIC とともに主導し、その成功の鍵を握った、元 AWS SAP ソリューションアーキテクトの Sejun Kim 氏に特別な感謝を申し上げます。 著者について Jinho Wang は AMOREPACIFIC の ERP Platform Planning チームを率い、ERP プラットフォームを担当しています。SAP ERP を中心とするエンタープライズシステムの企画と運用を通じて、ビジネスの安定性と効率性を高めてきました。現在は、日々の業務をより速くシンプルにするため、クラウドと生成 AI を ERP 運用に取り入れています。デジタルトランスフォーメーションと AI トランスフォーメーション（AX）を支える ERP プラットフォームの改善を続けています。 Dayoung Hu は AMOREPACIFIC の ERP Platform Planning チームでグローバル ERP 財務領域を統括し、ビジネスに合わせた財務・トレジャリーシステムの構築と運用を主導しています。海外子会社の複雑なビジネス要件をシステムに標準化し、プロセスを最適化することに注力し、グローバルグループ全体でデータ駆動の意思決定ができる透明性の高い効率的な環境づくりに取り組んでいます。ビジネスフローと IT の架け橋として働き、AMOREPACIFIC のグローバル展開と安定したシステム運用に貢献しています。 Jaehyeok Choi は AMOREPACIFIC の人事情報システム（HRIS）テクニカルプロジェクトマネージャーであり、SuccessFactors と SAP HR 上に構築された HR システムの統合と運用を主導しています。複雑なレガシーシステムと SaaS ソリューションの間のデータ同期とプロセス最適化を通じて、HR の意思決定のためのデータ中心の環境構築に注力しています。技術的な深さと HR ビジネスフローの架け橋として働き、安定的で効率的な HR 環境に貢献しています。 Jonghyuok Kim は AWS のソリューションアーキテクトで、小売・消費財（CPG）業界のお客様のクラウドジャーニーに伴走しています。Haein は、お客様のビジネス課題を理解し、AWS サービスを効果的に活用してイノベーションと成長を推進できるよう支援しています。 Haein Lim は AWS のソリューションアーキテクトで、製造・小売業界のお客様のクラウドジャーニーに伀走しています。Haein は、お客様がビジネス課題を理解し、AWS サービスを効果的に活用してイノベーションと成長を推進できるよう支援しています。 Whye Loong Wong は AWS の SAP パートナーソリューションアーキテクトで、ERP とエンタープライズアーキテクチャにおいて 20 年以上の経験を持ちます。ASEAN 全域の SAP パートナーおよびお客様と連携8、SAP ワークロードの AWS への移行とモダナイゼーションを支援しています。彼の焦点は、エンタープライズシステムを AI で拡張すること、すなわち SAP データを解き放ち、お客様がエンタープライズシステムと連携するエージェント型 AI ソリューションを構築できるよう支援しています。 <!-- '"` --> 本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

本記事は 2026 年 10 月 26 日に公開された Zejiang (Joe) Guo、Bolin Chen、Zezhen Xu による “ Keeping a software factory stable at 1,000 PRs a week ” を翻訳したものです。 前回の記事 では、3 人のエンジニアとエージェントのクルーが 1 週間で 1,000 件のプルリクエストをマージした経緯を紹介しました。これに対して最も多く寄せられた質問は、1,000 件ものマージで全体が壊れないようにするにはどうしているのか、というものでした。しかし、私たちはもっと良い問いがあると考えています。人間は、自分がマージしたすべての PR に責任を持てるのでしょうか。その中には、自分で書いておらず、1 行ずつ読んでもいないコードも含まれます。技術リーダーからそのうちの 1 件について尋ねられたとき、自信を持って説明できるでしょうか。 エージェントはコードの変更を数分で書けるので、速度を出すのは簡単です。難しいのは、その速度で高い品質基準を保つことです。人間がすべての行を読まなくても、それぞれの変更が正しく、安全で、マージする価値があると確認できなければならないからです。 確信はどこから生まれるのか AI が登場する前から、確信はレビューですべての if/else を読んで承認することだけから生まれていたわけではありません。手動のレビューは必要でしたが、それだけでは不十分でした。そのあとには数多くのテストが続き、たいていは誰かが実環境またはシミュレーション環境で変更を手で動かしていました。確信の源になっていたのはテストです。 ただし、人間によるテストだけでも十分ではありません。人が試せるのは少数のケース、通常はハッピーパスか明らかなエッジケースに限られます。私たち 3 人のエンジニアのうち 1 人は、以前に本番サービスを運用していました。そのサービスでは、入念に手動でテストしたあとでも、すべての変更をリリースパイプラインの自動テストにも通していました。この例から、AI が登場する前から、人間は高い確信を得るために自動テストの仕組みに頼っていたことがわかります。 そのため、「人間は AI が書いたコードにどう責任を持てるのか」という問いは、別の問いに変わります。自分で読むよりも信頼できるほど強力な自動テストとチェックを、どのように構築するか、という問いです。人間にはすべての変更を読めませんが、パイプラインならすべての変更を、毎回、同じ方法でテストできます。そのため、Kiro Crew チームは時間の約 20% を、より多くの作業を自動化するためのインフラに費やしています。 これは「PR を知っている」ことの意味も変えます。誰かから PR 番号を渡されても、私たちは差分を暗唱しません。Crew に尋ねると、1 分で平易な言葉の要約が返ってきます。要約は、コード、スクリーンショットや動画やデータといったテストの証拠、そしてレビュー記録に基づいています。レビュー記録とは、CI（継続的インテグレーション）がすべてのプルリクエストに書き込む記録です。すべてのレビュアーの指摘、それぞれをどう修正したか、または証拠を添えてどう回答したか、すべてのチェック結果、そして最終的な準備完了の判定が含まれます。この記録は、すべての変更が同じレビュー、テスト、ゲートを通過したことを示します。私たちが責任を持つのは、この記録です。 こうして、品質は CI/CD とテストの問題になります。私たちはテストカバレッジを 90% 超に引き上げ、100% の達成を目指しています。テストスイートでのリグレッションを防ぐ仕組みを入れ、さらにエージェントが実際のアプリをユーザーと同じように操作するエージェント型テストも追加しました。 ここに至るまで 品質は、コーディング速度の向上と並行して 5 つの段階を経て高まりました。システム全体を最初から計画していたわけではありません。どの段階も、品質の向上と自動化の拡大という同じ 2 つの目標に向かうもので、1 つの問題を解決すると次の問題が見えてくることがほとんどでした。どの段階もまだ完成しておらず、毎週改善を続けています。実際のコードベースでコーディングエージェントを運用する場合、同じ壁に同じ順番で突き当たる可能性が高いでしょう。 図 1: 各段階で、コードの高速化に歩調を合わせるようチェックを追加した。 段階に入る前: 人間によるレビュー 3 月上旬、チームは基本的なコードレビューの仕組みを整え、すべての変更を手作業でレビューしようとしました。この方法は 1 日も続きませんでした。当時の Kiro Crew はまだサイドプロジェクトで、変更の数ははるかに少なかったのですが、それでも人間によるレビューでは手に負えませんでした。このため、レビューを自動化せざるを得なくなりました。 ステージ 1: 自動化されたレビュアー、人間によるパイプライン Kiro Crew は、すべての変更に対して自動レビューボットを実行する社内のビルド・レビューシステム上でスタートしました。そこで、AI のコメントは優先度にかかわらず、マージ前にすべて解決しなければならないという厳格なルールを追加しました。このルールは品質を高めそうに聞こえましたが、実際には作業の妨げになり、すぐに 3 つの問題が生じました。 実際のエンドツーエンドテストがない。 パイプラインには Kiro Crew のエンドツーエンドテストがなく、プロダクトを実際に使う工程もなかったため、すべてのコメントを解決したあとでも、変更によってアプリが壊れる可能性がありました。人間がすべてを手動でテストし、証拠としてスクリーンショットを添付する必要があり、すり抜けた不具合はホットフィックスとして戻ってきました。 コメントがラウンドごとに届く。 5 件のコメントを修正してプッシュすると、手を加えていないコードに対して新たに 4 件のコメントが付き、さらに 3 件が続きます。すべてのコメントを解決する必要があるため、小さな変更でもやり取りに丸 1 日かかることがありました。さらに、追加のチェックやコードパスのように、修正のたびに新しいコードが加わることが多く、それ自体にもコメントが付きました。小さな修正が、誰も想定していなかったほど大きな変更に膨らむこともありました。 レビュアーを制御しにくい。 独自のルールは追加できましたが、ルールが発動したかどうか、その理由、見逃した理由を確認できませんでした。こうしたフィードバックがなければ、繰り返し遭遇する問題に合わせてレビュアーを調整できませんでした。 私たちの学びです。 厳格なルールが役に立つのは、レビュアーが網羅的で調整可能なフィードバックを返す場合に限られます。変更を実際のプロダクトでエンドツーエンドにテストすることも必要です。この 2 つがなければ、レビューは空回りするだけで、本物のバグはそれでもユーザーに届いてしまいます。 ステージ 2: 重大度のティアと 2 人目のレビュアー 最初に、コメントを重大度でティア分けしました。ブロッキングの指摘と本物の懸念は、同じ PR で修正する必要があります。軽微なコメントやスタイルの nit は、今後の PR に向けたフォローアップの課題にします。これにより各 PR が小さく保たれ、レビューは目の前の変更に集中できます。 ティア分けは基準を下げているように見えかねず、修正のたびに新しいコメントが付くループも止められません。そこで、既存のボットとは別に、独自のレビューエージェントも追加しました。このエージェントは変更を複数のパスでスキャンし、各パスには前のパスで見つかった内容を飛ばすよう指示します。目的は、本物のコメントを 1 回のラウンドですべて出し切り、コントリビューターが何度もではなく 1 回の修正で済むようにすることです。この段階でレビューを丁寧に読み込んだことで、驚いた点もありました。AI レビュアーは、人間の読み手が通常は見つけられないような、より深い問題を見つけていたのです。この発見を踏まえて、コードを 1 行ずつ手動でレビューするのをやめると決めました。 追加した AI レビュアーは役に立ちましたが、修正の各ラウンドを動かすのは依然として人間でした。ローカルで動く Crew はレビューコメントに基づいて実際の修正を行えますが、オンラインのレビューのために更新したコードをプッシュするのは人間で、その後しばらく待って新しいコメントをローカルの Crew に持ち帰り、次の修正に進みます。この過程は複数のラウンドに及び、長い時間がかかります。何回かループを繰り返したあとで、この面倒な手順を理由にコントリビューションをやめてしまう人もいました。このギャップを埋めるために、誰でもテストと、オンラインと同じ AI レビューをローカルで実行できる組み込みスキルを提供しました。これにより、PR を送る前に、ローカルマシン上で必要なコメントを受け取ってすばやく修正できます。 私たちの学びです。 厳格なレビューは良いソフトウェアを作る助けになりますが、人間が動かす長いループはコントリビューターを遠ざけかねません。解決策は自動化ですが、その自動化を実行するための CI がまだありませんでした。 ステージ 3: オープンソース化、本格的な CI、多数のレビュアー Kiro Crew を GitHub に移したことで、オープンソースプロジェクトとして強力な CI/CD のサポートを得られました。すべてのプルリクエストに対して、ビルド、ユニットテスト、エンドツーエンドテストが自動的に実行されるようになりました。Kiro Crew に組み込まれたテストポッドは、更新されたコードを分離された環境で実行し、関連する機能のスクリーンショットや動画を撮影して、プルリクエストに添付します。以前はエンジニアの午後を丸ごと費やしていた作業が、すべての変更で自動的に実行されます。CI が自動化されたので、はるかに充実したチェックを追加できるようになりました。 図 2: 信頼されないフォークのコードと、信頼されたレビューワークフローは、境界を挟んで反対側で実行される。 役割の異なるレビュアー。 1 人の AI レビュアーがすべてを見るだけでは、十分に深く掘り下げられません。そこで、役割ごとにレビューを分けました。設計レビュアーは、変更がアーキテクチャに適合しているか、はるかにシンプルな解決策がないかを問います。第一原理レビュアーは、変更が根本原因を修正しているか、ユーザーが本当に必要としているかを問います。UX レビュアーは、ユーザーに見える変更を評価します。コードは、異なるモデルファミリーのレビュアーによってもスキャンされます。あるモデルが同じファミリーのコードをレビューすると、盲点を共有してしまうからです。 完全なテストセット。 ユニットテスト、統合テスト、フロントエンドテスト、デスクトップのパッケージング、バンドルサイズの予算、カバレッジの下限、エンドツーエンドテストは、それぞれ異なる種類の障害を検出します。エージェントが最も間違えやすいのは統合の部分です。個々の変更を単体で見ると、どれも正しく見えるからです。 ブロッキングの単一の定義。 ブロッキングの指摘には、具体的な場所、引用した証拠、発生条件、結果が必要です。レビュアーが何がどのように壊れるのかを説明できない場合、その指摘は参考意見として扱います。具体的には、設計上の懸念は、one-way door、つまり後から元に戻せない選択を示すものでない限り、参考意見です。元に戻せる選択であれば、後でリファクタリングするのも簡単なので、そのリスクは受け入れます。 私たちの学びです。 自動化によって、人間にはとてもできない量のチェックが可能になります。しかしチェックが増えると、人間が読んで対応しなければならない結果も増え、人間がボトルネックになりました。 ステージ 4: ループを閉じる ステージ 3 では、コード修正の各ラウンドを依然として人間が動かしていました。ラウンドごとに、エンジニアがどの CI ステップが失敗したかを確認し、AI レビューの提案を含む CI の失敗内容を Crew にコピーして、問題の修正を依頼します。私たちは AI の提案を、信頼しなければならないものとしてではなく、ローカルでより深く分析するための入力として扱っています。Kiro Crew は提案をコードと照らして確認し、テストを実行し、次のラウンドで CI が修正を再度チェックします。各修正の裏にあるこうした追加の作業と比べると、人間がすべての判断を下しても付加価値はほとんどありませんでした。 そこで、プルリクエストがグリーンになるまでループを回す組み込みスキル prepare-pr を提供しました。このスキルには、読み取るべき明確なシグナルが 1 つ必要でした。すべてのプルリクエストで 80 件以上のチェックをスキャンするのはコストがかかるからです。そこで、すべての CI/CD アクションの結果を 1 つの判定にまとめる PR Readiness チェックを 1 つ追加しました。この判定は、まだ赤いものがないというだけでなく、期待されるすべての CI/CD アクションが実行されて成功したことを意味していなければなりません。新しいプルリクエストでは、「失敗しているチェックがない」と「まだ何も実行されていない」が同じに見えるからです。 prepare-pr はその判定を読み取り、失敗している CI/CD アクションとレビューの指摘を取得して、本物の問題を修正し、そうでないものには証拠を添えて返信し、再びプッシュします。CI が新しいリビジョンをチェックし、ループがその結果を読み取ります。判定がグリーンになるとスキルは停止し、同じ判定が、プルリクエストの準備ができたことを人間に伝えます。人間とエージェントは、「完了」について 1 つの定義を共有しています。 図 3: すべてのレビュアーとテストが、1 つの PR Readiness 判定に集約される。 エージェントがプルリクエストを自動的にグリーンにするようになると、PR の数が多い場合には、承認ボタンを押す作業に時間がかかるようになりました。この手順を自動化するために、まず各プルリクエストをティアで分類します。単純なティアの PR は自動的に承認されてマージされ、それ以外については、AI が人間向けのレビュー提案の下書きを作成します。人間のレビューを速くするために、エージェントはプルリクエストの説明文を書き、実際のコードの変更に合わせて毎回書き直します。説明文には固定のテンプレート、わかりやすい言葉、さらには変更に関連する図も使うので、人間は数秒でプルリクエストを理解できます。説明文がコードと厳密に一致していることを検証する CI チェックもあります。 私たちの学びです。 チェックと修正が 1 つのシグナルを共有すれば、エージェントがループを回せるようになり、人間は必要な判断だけを下せば済みます。ただし、このループにも固有の問題があります。主に、過剰なエンジニアリングと、行き過ぎたセキュリティ修正です。この 2 つについては、最後のステージのあとで取り上げます。 ステージ 5: マージ後のこと 私たちのコードレビューは、それでも一部のバグを見逃します。そのため、コードのマージは最後のステップではありません。全体的な品質は、通常、1 つのプルリクエストに含まれるコードだけで決まるものではありません。 リリースゲート 各リリースの前に、ビルドしたプロダクトに対して、エージェント型テストを含む追加のテストを実行します。エージェントが実際のアプリをインストールし、セッションの開始、タスクの実行、メモリの利用、ジョブのスケジュールといったコアフローを操作します。ユニットテストは特定の機能が動作することを確認し、エージェント型テストはプロダクトの中核となる手順がユーザーの期待どおりに動作し続けていることを確認します。 マージ後のセキュリティ マージされたコードは複数の層で継続的にチェックされるので、1 つの層をすり抜けた問題が長く残ることはありません。 マージされたコードが必要なレビューを経ており、コアのセキュリティルールに従っているかを、1 時間ごとに確認するコンプライアンスチェック。 社内のセキュリティエージェントによる日次スキャン。他の社内サービスと同様に、私たちのオープンソースコードベースにも適用されます。 ツールに対して実際の操作を実行し、セキュリティのガードレールの突破を試みて、修正すべき問題を見つける常時稼働のセキュリティボット。 外部からの報告を迅速な対応で受け付ける、マネージドのセキュリティ受信箱。 定期的なリファクタリング 変更が速いと、大きなファイル、重複したロジック、デッドコードといった粗が残ります。人間とエージェントの両方がコードベースを変更しやすい状態を保つため、定期的にリファクタリングしています。また、定期的にリファクタリングしておくと、最新のモデルでより良いコードを書けます。 チェック自体のスケーリング すべてのプルリクエストに数十の自動チェックがあり、1 日に 100 件のプルリクエストが出ると、GitHub のレート制限と自社のリソース上限に達しました。この問題を緩和するために、CI アクションをグループに分け、グループごとに実行しています。たとえば、現在は高速なゲートが先に軽いチェックを実行し、低速なチェックは高速なゲートを通過してから開始します。また、レビューを AWS CodeCommit に、一部のテストワークロードを自社のホストに移し、上限を自社のハードウェアで決められるようにしました。 開発プロセス コードを書くのが簡単なら、機能に「はい」と言うのも簡単です。しかし、あまりに多くの機能を一度にマージすると、気づかないうちに予期しない競合が起きやすくなります。コードを書くコストが低いと、チームが正しい作り方に集中せず、技術的に凝った解決策に引き寄せられることもあります。この問題に対処するため、すべての機能リクエストは、誰かが作り始める前に分類されるようになりました。単純な変更はそのまま作り、中程度の機能は 1 ページの設計書が必要で、複雑なものはチーム全体でのレビューが必要です。 私たちの学びです。 マージ前にすべてのチェックを通過することと、長期にわたって健全であり続けることは同じではありません。品質には、プロダクトのコードに対して実行され続けるチェックが必要です。どの機能を作るかを決めるプロセスも必要です。最も高くつくバグは、ユーザーが必要としない機能から生まれるものだからです。 乗り越える必要があった 2 つの重大な問題 過剰なエンジニアリング 過剰なエンジニアリングは、レビューと修正のループが自律的に回り始めると、無駄の最大の原因になります。レビュアーがエッジケースを指摘すると、エージェントは仕組みを追加します。次のレビューで、その新しい仕組みのエッジケースが指摘されると、エージェントはさらに別の仕組みを追加します。5 ラウンドを経ると、10 行の修正が、必要のなかった小さなサブシステムに変わっています。 そこで、 prepare-pr スキルと CI の両方に振り返りを追加しました。同じ領域で何ラウンドか繰り返すと、ループは自身の履歴を振り返ります。何が変わったのか、レビュアーが何を言ったのか、そして変更が収束せずに拡大していないか、という点です。そのうえで、停止、リバート、よりシンプルな方法のいずれかを推奨します。最初の一手は、多くの場合、不要になった仕組みを取り除くことで、残りの指摘も減っていきます。 提案された修正が適切な規模かどうかも、すべてチェックします。指摘が正しくても、求めすぎている場合があります。修正は、プルリクエストの説明に書かれた問題を解決する直接的なコード変更にとどめ、それより大きなものはフォローアップにします。唯一の例外は、到達可能なクラッシュ、セキュリティホール、データ損失で、これらは常に修正します。 しかし、振り返りは新たな問題も生みました。コーディング戦略をどう変えるかを決めるのに人間の操作が必要になったのです。戦略の推奨内容は、たいてい明確であるにもかかわらずです。人間の入力を増やすことが、より高品質なコードを得る最善の方法に思えるかもしれませんが、質問のたびに自動化は止まります。この問題に対処するため、2 つ目のエージェントであるコンダクターが、振り返りの推奨内容を読み、最初の判断を自分で下します。コンダクターが決められない場合にのみ、人間が呼び出されます。 図 4: 振り返りとコンダクターエージェントにより、レビューのループが修正をサブシステムに肥大化させるのを防ぐ。 セキュリティに関する考慮事項 AI はセキュリティに熱心です。1 つの本物の指摘を受けると、3 層の防御、新しい設定フラグ、そして一度も実行されない検証ステップを追加します。追加はどれも壊れる可能性のある新しいコードであり、次のレビューのラウンドで指摘される新たな対象にもなります。以下は、私たちの開発中に見つかった興味深い 2 つの事例です。 通常の作業をブロックするサンドボックス。 レビューのラウンドごとに、エージェントのサンドボックスが少しずつ厳しくなりました。個々の変更は単独では妥当に見えましたが、合わさると、ビルドの実行やプロジェクトファイルの読み取りといった通常のタスクが失敗するようになりました。プロダクトは書類上は安全になりましたが、実際には使えなくなったのです。 すでに勝利した攻撃者への対策。 典型的なセキュリティの提案に、実行ファイルを専用のフォルダーにコピーしてロックダウンし、マシン上の攻撃者に差し替えられないようにする、というものがあります。この対策はコピー、権限チェック、更新パスを追加しますが、そのどれもが壊れる可能性があり、守れるのはきわめてまれなケースだけです。 そこで、私たちのセキュリティ修正は単純なルールに従っています。ユーザーが実際に到達できる問題を、最小限のコード変更で修正する、というものです。 今日から適用できること 以下は私たちのチームで効果があった提案ですが、コードベースはそれぞれ異なるため、自分のプロダクトで機能するように調整してください。 レビューコメントをティア分けする。 「すべてのコメントを解決する」は厳格に聞こえますが、空回りを生むことが多くあります。 すべてのコメントを 1 回のラウンドで求める。 時間はかかっても網羅的なレビュアーのほうが、指摘をラウンドごとに小出しにするレビュアーよりコストが低くなります。 レビュアーを役割とモデルで分ける。 問いやモデルファミリーが異なれば、見つかる問題も異なります。 チェックを 1 つの準備完了フラグにまとめる。 このフラグは「まだ失敗したものはない」ではなく、「すべて実行されて成功した」を意味します。 部分だけでなく、プロダクト全体をテストする。 リリース前に、実際のフローを操作するステップを少なくとも 1 つ入れます。 エージェントのループに振り返りを組み込む。 2 つ目のエージェントに最初の判断を任せれば、一時停止のたびに人間が必要になることはありません。 セキュリティ修正は妥当な範囲にとどめる。 厳格なチェックで実際の問題を明らかにし、修正は小さく直接的なものにします。 Kiro Crew はオープンソースです。ここで説明したワークフロー、レビューのプロンプト、 prepare-pr スキルは、すべて GitHub のリポジトリ にあります。 Crew を試して 、実際の動作を確認してください。 翻訳は Solutions Architect の吉村が担当いたしました。

この記事は 2026 年 8 月 27 日に公開された Building audio provenance for AI-generated content at the source with AWS を翻訳したものです。 AI 生成オーディオは、世界中のメディア・サプライチェーンにますます組み込まれています。欧州市場向けにこのコンテンツを生成する場合、 EU AI 法第 50 条 に基づき、2026 年 12 月 2 日までにコンプライアンス要件を満たす必要があります。本記事では、合成の段階で AI 生成オーディオに暗号技術を用いた来歴情報 (プロヴェナンス) の透かしを埋め込み、ライブストリーミングメディアパイプラインを通じて検証可能な管理の連鎖 (チェーン・オブ・カストディ) を保持する、 Amazon Web Services (AWS) のパイプライン「SENTINEL」の構築方法について解説します。本記事では、アーキテクチャ、AWS サービスの実装、デプロイ手法、および SENTINEL の構築中に直面したエンジニアリング上のトレードオフについて取り上げます。 なぜ 2026 年に急務になったのか？ EU AI 法第 50 条は、欧州連合 (EU) で提供される AI 生成コンテンツに対し、機械可読な来歴情報の表示を義務付けています。2026 年 8 月 2 日より後に提供を開始したシステムは、直ちに準拠する必要があります。既存のシステムの期限は 2026 年 12 月 2 日です。違反した場合、最大 1,500 万ユーロまたは全世界売上高の 3% のいずれか高い方の制裁金が科されます。 Universal Music Group と Warner Music Group による業界の著作権和解は、AI 生成音楽に帰属メタデータが必要であることを示しています。 業界では、NextGen TV 放送向けの VP1 透かし形式を規定する ATSC A/334 規格が認知されています。 2026 年 7 月 9 日、欧州委員会は AI 生成コンテンツの透明性に関する行動規範 (Code of Practice on Transparency of AI-Generated Content) を、第 50 条への準拠を示すうえで適切なものとして承認しました。最終版の規範は、プロバイダーに対し、(1) 一般に利用可能な検出ソリューション、(2) 知覚できない透かしを伴うデジタル署名付きメタデータ、(3) 検出のために提出されたコンテンツを保持しない取り扱い (ゼロリテンション)、(4) 2027 年 2 月 2 日を期限とする相互運用性などの最低限の義務を定めています。これらの義務により、オーディオプロバイダーに求められる技術要件は、2025 年 12 月の第 1 次草案で想定されていたものより厳しくなっています。 オーディオの来歴情報に、新しい技術は必要ありません。業界にはすでに必要な要素がそろっており、SENTINEL はそれらを AWS 上で稼働するパイプラインとして組み上げています。 AudioSeal は、MIT ライセンスのオープンソースの透かし技術で、堅牢で知覚できないという特長があります。SENTINEL は AudioSeal を使って透かしを生成し、埋め込みを合成の段階に移すことで、ペイロードを生成モデルと、 Amazon Bedrock Guardrails による安全ポリシーの評価に結び付けます。 C2PA 2.0 は、暗号署名されたオープンなコンテンツクレデンシャルのマニフェストを提供します。SENTINEL はこのマニフェストを作成・署名し、配信チェーン全体に引き継ぎます。さらに、C2PA の「ソフトバインディング」を備えた Durable Content Credentials は、SENTINEL が実装する復元の仕組みそのものを定義しています。これは、途中の処理で埋め込みメタデータが削除された場合に、不可視の透かしを使ってリポジトリからマニフェストを復元する仕組みです。 SynthID は、生成時の埋め込みと C2PA を組み合わせる同じ方向性を、単一ベンダーの製品群の中で大規模に実現しています。SENTINEL は、このモデルをサードパーティのあらゆる AWS パイプラインで利用できるようにします。 これらの構成要素を組み合わせたものが、Durable Content Credentials です。これは、署名付きのマニフェストと、処理を経ても残るソフトバインディングで構成されます。AI 生成オーディオがライブ制作パイプラインを流れるとき、オーディオには 2 つの来歴情報のアセットが付随します。C2PA マニフェスト (メディアコンテナに添付される署名付きメタデータ) と、AudioSeal の透かし (オーディオ波形に直接埋め込まれる 16 ビットのペイロード) です。マニフェストは、メタデータのパススルーを実装していないトランスコーダーによって削除されることがよくあります。一方、透かしはオーディオ信号そのものの中にあるため、コーデックのトランスコード、再量子化、±6 dB のゲイン変更、10% へのクロッピングを経ても残ります。ただし、タイムストレッチや中程度の加算ノイズには耐えられません。SENTINEL は、残った透かしをソフトバインディングとして使い、削除されたマニフェストを来歴情報のレジストリから復元します。こうして、ライブオーディオ向けの耐久性のある C2PA コンテンツクレデンシャルを AWS 上で実装しています。 この実装では、AI コンテンツを Amazon Polly (ニューラルエンジン) で合成し、 AWS Elemental MediaLive でトランスコードし、 AWS Elemental MediaPackage で HTTP Live Streaming (HLS) セグメントに再パッケージします。さらに、 AWS Elemental MediaTailor のサーバーサイド広告挿入 (SSAI) で加工し、 Amazon CloudFront で配信します。また、Amazon Bedrock Guardrails がポリシーの評価を行います。 ソリューションの概要 SENTINEL は、4 つの機能プレーンにまたがって動作します。 生成 (プレーン 1) – AI による合成の間に、パルス符号変調 (PCM) の生のオーディオに透かしを埋め込む 変換 (プレーン 2) – メディア処理の各段階で、管理の連鎖を示す署名付きアサーションを付与する レジストリ (プレーン 3) – 組織をまたいだアンカリングを備えた、改ざん検知可能な来歴情報のストレージ 復元 (プレーン 4) – キャプチャした 1 秒以上のオーディオから、来歴情報のチェーン全体を再構築するエッジ API 次の図は、生成から復元まで、オーディオが SENTINEL の 4 つのプレーンをどのように流れるかを示しています。 図 1: SENTINEL の 4 プレーンアーキテクチャ オーディオは合成時に透かしが埋め込まれ (プレーン 1)、メディア処理の各段階でアサーションが付与され (プレーン 2)、来歴情報は改ざん検知可能なレジストリに保存され (プレーン 3)、チェーン全体はエッジで復元できます (プレーン 4)。 共有のコントロールプレーン ( Amazon API Gateway 、 Amazon Cognito 、 Amazon DynamoDB 、 Amazon CloudWatch ) が、すべてのプレーンに対して認証、API 管理、オブザーバビリティを提供します。 プレーン 1: 合成の時点での透かし SENTINEL は、オーディオをプレーン 1 から送り出す前に、各合成リクエストに対して次の 4 つの処理を行います。 安全ポリシーの証明 – Amazon Bedrock Guardrails が、ApplyGuardrail API を使用して、設定されたコンテンツポリシーのカテゴリに照らして合成リクエストを評価します。Guardrails は評価結果 (action フィールドと assessments 配列) を返します。これは通常の API レスポンスであり、署名されたアーティファクトではありません。そこで SENTINEL は、暗号による信頼の連鎖を自ら確立します。まず、ガードレールのポリシーハッシュ (ガードレール ID、バージョン、評価結果を含む、シリアライズした ApplyGuardrail レスポンスの SHA-256) を計算し、そのハッシュに AWS Key Management Service (AWS KMS) (ECDSA_SHA_256) で署名します。KMS キーは、FIPS 140-3 セキュリティレベル 3 の検証を受けた HSM で保護されています。署名されたハッシュは透かしのペイロードの一部となり、そのオーディオが特定の安全ポリシー設定のもとで生成されたことを示す、永続的で検証可能な記録になります。改ざん検知性をもたらすのは、Guardrails ではなくこの署名です。 暗号鍵の導出 – AWS KMS が、管理の連鎖のタイムスタンプに対する FIPS 140-3 レベル 3 の署名とあわせて、GenerateDataKey でテナントごとの一時的なデータキーを導出し、マルチテナントでの暗号学的な分離を維持します。 オーディオの合成 – Amazon Polly (ニューラルエンジン) が、16 kHz の生の PCM 波形を生成します。 ボコーダー層での透かしの埋め込み – 透かしの埋め込み処理は Amazon SageMaker 上で動作し、AudioSeal のジェネレーターを使用します。エンコードやパッケージングの前に、16 ビットのペイロードを生の PCM 波形に埋め込みます。知覚できないこと (不可知覚性) は、AudioSeal が学習した知覚損失と、品質ゲート付きの SENTINEL の適応的な α 探索によって実現しています。安全策として、BS.1387 に由来するマスキング閾値のチェックも実行します。測定した最悪ケースのマージンは +22.3 dB で、467 フレーム中、可聴なフレームは 0 でした (検証済み)。 波形に埋め込まれる透かしは 16 ビットで、アセットの SHA-256 コンテンツハッシュの先頭 2 バイトを、レジストリの検索キーとして保持します。コンテンツハッシュ、モデルの ID、ガードレールのポリシーハッシュ、テナントのキー ID、タイムスタンプ、ナンスを結び付ける来歴情報の 128 ビットの完全なペイロードは、署名付きの C2PA マニフェストに格納され、切り詰めていない完全な値はレジストリに保持されます。透かしは指し示し、マニフェストが証明します。 エンコード前のこの段階で埋め込むことで、オーディオの忠実度が最も高い時点で透かしが組み込まれます。Advanced Audio Coding (AAC) 圧縮から HLS のパケット化、広告挿入まで、その後のすべての処理は、すでに来歴情報のペイロードを含むオーディオに対して行われます。 次の表は、透かし埋め込みのエンジニアリング目標をまとめたものです。 指標 目標 根拠 音声品質の知覚評価 (PESQ) の劣化 0.23 MOS 以下 ITU-T P.862 (聴取者には知覚されない) スケール不変の信号対雑音比 (SI-SNR) 25 dB 以上 信号の完全性 埋め込みのレイテンシー オーディオ 1 秒あたり 50 ms 未満 リアルタイムストリーミングの要件 復元可能な最小のオーディオ長 1.0 秒以上 モニタリングサービスで実用的 ペイロード容量 16 ビット マニフェストの検索キー MP3 128k または AAC 96k 後の透かしのビット誤り率 (BER) 4% 以下 AudioSeal が公表した堅牢性 (ICML 2024) 注: これらは、AudioSeal が公表した ICML 2024 の結果とアーキテクチャ上の制約に基づくエンジニアリング目標です。多様な種類のコンテンツで本番環境向けに検証するには、MUSHRA (Multiple Stimuli with Hidden Reference and Anchor) の聴取パネルによる厳密な A/B テストが必要です。 プレーン 2: ライブストリーム全体での管理の連鎖 メディア放送パイプラインの各段階で、AWS Elemental サービスからの Amazon EventBridge イベントが、transformer-signer という AWS Lambda 関数を起動します。この関数は、暗号署名されたアサーションを来歴情報のチェーンに追加します。 AWS Elemental MediaLive – インジェストとトランスコードの時点でのアサーション AWS Elemental MediaPackage v2 – HLS、Common Media Application Format (CMAF)、Dynamic Adaptive Streaming over HTTP (DASH) への再パッケージの時点でのアサーション AWS Elemental MediaTailor – SSAI の時点でのアサーション 各アサーションは prev_assertion_id で直前のアサーションを参照し、AWS KMS の非対称キー (ECDSA_SHA_256) で署名されます。その結果、次のような連結されたチェーンが作られます。 { "assertion_id": "ast-7f3a9b2c", "transform_type": "transcode", "created_at": "2026-05-20T14:23:07.442Z", "digest": "a8f2e1...", "signature": "MGQCMBn...", "prev_assertion_id": "ast-2d8e4a1f", "sequence_number": 3 } アサーションの挿入、削除、並べ替えのいずれによる改ざんも、チェーンの暗号上の完全性を損ないます。アサーションの処理に失敗した場合は、 Amazon Simple Queue Service (Amazon SQS) のデッドレターキュー (DLQ) に送られ、再試行されます。 プレーン 3: 改ざん検知可能なレジストリ SENTINEL は、次の表に示す複数の層からなるレジストリに、来歴情報のチェーンを保存します。 層 サービス 目的 プライマリのマニフェストストア Amazon Aurora PostgreSQL 互換エディション Serverless v2 低レイテンシーのクエリ。追記専用のジャーナルをアプリケーション層で実装 (ハッシュで連結した行) し、挿入のみの権限とトリガーで強制 組織をまたいだアンカリング ファーストパーティまたはサードパーティのブロックチェーン連携 (Hyperledger Fabric) 組織の信頼境界をまたいだハッシュのアンカリング C2PA マニフェストの作成 AWS Lambda (Rust、c2pa-rs) 標準に準拠した C2PA コンテンツクレデンシャルのマニフェスト 変更不可能なアーカイブ Amazon Simple Storage Service (Amazon S3) の Object Lock (COMPLIANCE モード) 長期の法的保持のための WORM (Write Once Read Many) ストレージ フィンガープリントのインデックス Amazon OpenSearch Serverless 透かしが削除された場合の、自動コンテンツ認識 (ACR) によるフィンガープリント照合 プレーン 4: エッジでの復元 API どの下流プラットフォームも、キャプチャした 1 秒以上のオーディオを、Amazon CloudFront と Lambda@Edge にデプロイされた復元 API に送信し、来歴情報のチェーン全体を受け取ります。処理は、次の 2 つの経路のいずれかをたどります。 主経路 (透かしが残っている場合) – Lambda@Edge が AudioSeal の検出器で 16 ビットのペイロードを抽出し、Aurora でマニフェストを検索します。そして、チェーン全体 (モデルの ID、ガードレールの証明、すべての変換アサーション) を、信頼度スコアとともに C2PA 互換のマニフェストとして返します。 フォールバック経路 (透かしが劣化または削除された場合) – システムが、オーディオのフィンガープリントを OpenSearch Serverless の ACR インデックスと照合し、信頼度スコアを下げた確率的な一致結果を返します。この副次的な経路は、 コンテンツ配信ネットワーク (CDN) での積極的なトランスコードや敵対的な処理によって、埋め込まれた透かしが劣化した場合に対応します。 目標レイテンシーは、CloudFront のグローバルエッジネットワークを通じて、99 パーセンタイル (p99) で 1 秒未満です。 AWS WAF がレート制限とボット対策を、 AWS Shield Advanced が DDoS 対策を提供します。次の図は、SENTINEL の実装における機能フローの概要です。 図 2: SENTINEL の機能データAmazon CloudFronフロー SENTINEL の実装で得られた主な知見は次のとおりです。 AudioSeal の 16 ビットのメッセージ上限により、マルチフレームのエンコードが必要になる – AudioSeal の事前学習済みモデルは、1 フレームあたり 16 ビットを扱います。128 ビットのペイロードを連続する 8 フレームに分けて埋め込むと、完全に読み取るのに約 8 秒のオーディオが必要になり、順序に依存する壊れやすいデコードになります。ただし SENTINEL は、16 ビットをそのままレジストリの検索キーとして使い、完全なペイロードは署名付きマニフェストに保持します。これにより、復元に必要なオーディオは 1 秒に保たれます。AudioSeal のマルチビット拡張モードやカスタム学習によるキーの拡張は、ロードマップに含まれています。 ボコーダーの後での埋め込みが、現実的な出発点になる – 改変した HiFi-GAN ボコーダーの内部で透かしを埋め込むと、先行技術との差別化は最も大きくなりますが、Amazon SageMaker の p4d.24xlarge インスタンス (NVIDIA A100 GPU 8 基) で 2〜4 週間のカスタムボコーダー学習が必要です。SENTINEL の現在の実装は、AudioSeal をそのまま使い、ボコーダーの出力直後、かつ非可逆エンコードの前に埋め込みます。ロードマップでは、今後のフェーズでボコーダー内部での埋め込みに移行します。 Lambda@Edge のコールドスタートには、アーキテクチャでの対策が必要になる – Lambda@Edge 関数は、リージョンの Lambda よりもコールドスタートのレイテンシーが高く、プロビジョニングされた同時実行もサポートしていません。SENTINEL は、CloudFront のキャッシュ優先のアーキテクチャ (透かしのハッシュでマニフェストの検索結果をキャッシュ) と、軽量な関数設計 (最小限の依存関係、重いフレームワークを使わない) によってこれを軽減し、p99 の復元レイテンシーを目標の 1 秒未満に保っています。計算負荷の高い検出 (AudioSeal の推論) は、プロビジョニングされた同時実行を利用できるリージョンの Lambda 関数に転送します。 まとめ SENTINEL は、後処理のステップとしてではなく、生成の間に透かしを埋め込み、署名付きのアサーションによってあらゆる変換を通じて来歴情報を追跡します。これにより、オーディオと切り離せない管理の連鎖が作られます。このソリューションは、 Amazon Bedrock 、AWS KMS、 AWS Elemental Media Services 、Amazon Aurora、Amazon CloudFront などの AWS マネージドサービスで構築されているため、すでに運用しているインフラストラクチャを使ってパイプラインをデプロイできます。 オーディオの来歴情報は、差別化要因ではなくコンプライアンス要件です。EU AI 法の 2026 年 12 月の期限は、2026 年 7 月に最終化された行動規範が一般に利用可能な検出ソリューションとゼロリテンションでの取り扱いを義務付けたことで、さらに厳しくなりました。音楽業界の帰属に関する義務付けや放送規格も、AI オーディオを生成するのであれば、来歴情報は生成元で組み込まなければならない、という点で一致しています。SENTINEL は、後処理のワークフローが追いつくのを待たずに、これらの義務を満たすための設計図を提供します。 SENTINEL のリファレンス実装は、2026 年 10 月に GitHub で公開される予定です。2026 年 12 月 2 日の期限までに AI 生成オーディオに検証可能な来歴情報を組み込めるよう、 AWS for Media and Entertainment Blog で最新情報をご確認ください。 参考資料 AWS マネジメントコンソール で Amazon Bedrock を使い始める。 コンテンツクレデンシャルのマニフェストについては、 C2PA 2.0 仕様 を参照する。 著者について Saurav Bhattacharya Saurav Bhattacharya は、AWS のシニアソリューションアーキテクトで、通信、ブロードバンド、メディアの分野で豊富な経験を持っています。現在は、メディア &amp; エンターテインメント業界の課題の解決に注力し、技術営業を加速するとともに、お客様のデジタルトランスフォーメーションを加速するスケーラブルなソリューションを構築しています。 参考リンク AWS Media Services AWS Media &amp; Entertainment Blog　(日本語) AWS Media &amp; Entertainment Blog　(英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳は SA 金目、SA 石井が担当しました。原文は こちら をご覧ください。

本記事は 2026 年 10 月 27 日に公開された Shweta V A による “ Kiro’s new free trial gives you 500 extra credits ” を翻訳したものです。 11 月 1 日から、Kiro の無料トライアルの仕組みが変わります。初めて Pro にアップグレードすると、その月の残りの期間は無料です。さらに、今後 12 か月間いつでも使える 500 トライアルクレジットが付与されます。たとえば 15 日にアップグレードした場合、翌月 1 日まで料金は発生しません。Pro プランの約半月分のクレジットと、追加の 500 クレジットを利用できます。 変更内容 11 月 1 日から、プラン料金とクレジットの両方が日割り計算になります。月の途中でアップグレードした場合、1 か月分ではなく、残りの日数に応じたクレジットが付与されます。 無料プランから初めてアップグレードする場合、Pro での最初の月の残り期間は無料です。最初の請求は、翌月の 1 日に発生します。トライアルクレジットは、プランのクレジットを使い切った後に消費されます。トライアルクレジットの有効期間は 12 か月です。 より上位のプランで開始する場合 Pro の代わりに、Pro+、Pro Max、Power で開始することもできます。この場合も、Pro の無料期間が適用されます。お支払いが必要なのは、選択したプランの日割り料金と Pro の日割り料金との差額のみです。 20 ドルの割引について 11 月 1 日までにアップグレードすれば、20 ドルの割引が適用され、未使用のクレジットもそのまま残ります。その日以降になると、新しいトライアルに置き換わります。 ダウングレードと再アップグレード 無料プランに戻した場合、未使用のトライアルクレジットは引き継がれます。ただし、無料プランでは、トライアルクレジットを無料プラン対象のモデルにのみ使用できます。無料トライアルが適用されるのは、最初のアップグレードのみです。その後に再度アップグレードした場合は、これまでどおり料金とクレジットは日割りになりますが、2 回目の無料期間は付与されません。 計算方法 日割り計算は秒単位で行い、アップグレードした正確な時刻を基準にします。月に占める割合は、請求サイクルの残り秒数をその月の総秒数で割った値です。 日割り料金 =（残り秒数 ÷ 月の総秒数）× 月額プラン料金 日割りクレジット =（残り秒数 ÷ 月の総秒数）× 月間プランクレジット 月額 $20 で 1,000 クレジットの Pro プランを例にします。30 日の月（2,592,000 秒）の 15 日 00:00 UTC にアップグレードすると、残りは 16 日間（1,382,400 秒）です。日割り料金は（1,382,400 ÷ 2,592,000）× $20 = $10.67 になります。日割りクレジットは（1,382,400 ÷ 2,592,000）× 1,000 = 533 です。Pro での最初の月は無料のため、お支払いは $0 のまま、533 のプランクレジットと 500 のトライアルクレジットを受け取れます。 同じタイミングで Pro+（$40）にアップグレードした場合、日割り料金は $21.33 です。この金額から無料となる Pro の日割り料金 $10.67 を差し引いた、$10.67 をお支払いいただきます。 00:00 ではなく 14:30 UTC にアップグレードした場合は、残り秒数が減るため、日割り料金とクレジットも少なくなります。以下の表の前提は、11 月のように 30 日ある月の 00:00 UTC にアップグレードした場合です。 月の 15 日にアップグレードした場合（残り 16 日間） プラン 日割り料金 お支払い額 プランクレジット トライアルクレジット 合計クレジット Pro $10.67 $0 533 500 1,033 Pro+ $21.33 $10.67 1,067 500 1,567 Pro Max $53.33 $42.67 2,667 500 3,167 Power $106.67 $96.00 5,333 500 5,833 この変更を行う理由 日割り計算にすることで、請求がより公平になります。また、サインアップのタイミングにかかわらず、全てのお客様に最初から良い体験をしていただきたいと考えています。たとえば 28 日にサインアップした場合でも、500 トライアルクレジットがあれば、実際のプロジェクトで十分に Kiro を試していただけます。トライアルクレジットは月が替わっても失効しないため、ご自身のペースでじっくり試せます。 翻訳は Solutions Architect の吉村が担当いたしました。

本ブログは株式会社ドコモSMTBネット銀行 カスタマーサービス部 CS・DX企画グループ 中﨑 敬太様のご協力のもと執筆しました。 コンタクトセンターへの生成 AI 導入は、すでに「試してみる」段階を越えつつあります。導入から数年が経ったコンタクトセンターでよく伺うのは、FAQ の回答精度が思ったほど伸びないという悩みです。窓口を増やすたびに開発が必要になる、利用量が増えたときのコストが読めない、といった二周目の課題もここに重なります。 株式会社ドコモSMTBネット銀行（以下、ドコモSMTBネット銀行）は、生成 AI による自動応対をすでに本番で運用していました。その基盤を Amazon Connect Customer AI agents に移し、2026 年 9 月から電話とチャットの両チャネルで応対を開始しました。本ブログでは、なぜ基盤を移したのか、そして本番導入に向けて何を作り込んだのかをご紹介します。 同社カスタマーセンターにおける AI 活用のあゆみは、2026 年 6 月 26 日の AWS Summit Japan 2026 において、カスタマーサービス部 CS・DX企画グループの中﨑 敬太様が「銀行カスタマーセンターにおける AI 活用の実践と進化」として講演されています。本ブログはその概略を振り返りながら、Amazon Connect Customer AI agents の採用に至る判断と、導入に向けた検証の内容を整理したものです。 ドコモSMTBネット銀行のカスタマーセンター ドコモSMTBネット銀行は 2007 年 9 月に開業したインターネット専業銀行です。モバイルアプリを通じた個人・法人向けサービスに加え、2020 年には邦銀で初めてフルバンキングの BaaS（Banking as a Service）を提供し、多様な業界のパートナーへ銀行機能を提供しています。 同社は 2017 年に「クラウドファースト」の方針を決定し、2018 年にコールセンターシステム、2025 年には勘定系システムを AWS 上に構築することを発表してきました。電話基盤として Amazon Connect Customer を採用したのは 2018 年で、今回の取り組みはその延長線上にあります。 カスタマーセンターでは、電話、お問合せフォーム、チャットの各チャネルを運用し、お客さまからのお問合せを受け付けています。 第 1 世代と第 2 世代で見えたこと 同社が生成 AI の検討を始めたのは 2023 年下期。問題意識は 2 つありました。 ひとつは、ボイスからノンボイスへの移行が頭打ちになっていたこと。問い合わせに占める比率はボイスとノンボイスで 4 対 6 まで進みましたが、そこから先が動きません。IVR（自動音声応答）をさらに作り込む方向では、この壁を越えられないという判断がありました。もうひとつは、目的別に用意した窓口に目的外の入電が多数寄せられていたことです。結果として一次解決率が低下し、オペレーターの負荷も増していました。 そこで 2024 年 8 月、一部の受付窓口で生成 AI（SaaS）による PoC を、実トラフィックを流す本番運用として開始しました。ここで下した割り切りが、その後の展開を支えました。回答文の生成は行わず、コールリーズンの判定と、事前に用意した FAQ の提示だけに機能を限定したのです。生成させなければハルシネーションは起きません。リスクを運用で抑えるのではなく、設計で消しにいった判断でした。あわせて、入力データのオプトアウト機能により自動学習を排除し、個人情報の取り扱いにも配慮しています。 2024 年 10 月には他社の対話型 AI プラットフォームを採用して本格開発に着手し、窓口別の「フロー」を用意してコールリーズン判定で振り分ける構成へ拡張しました。2025 年 6 月に受付窓口と FAQ を広げて本格導入した結果、問い合わせ対応の自動化率が大きく向上し、顧客利便性の向上と運営コストの最適化を両立しています。 図 1 カスタマーセンターにおける生成 AI 適用の変遷 継続課題として残ったのは FAQ 回答精度の向上です。お客さまの照会内容と生成 AI が提示した FAQ を突き合わせて検証し、ヒット率を上げていく地道な改善が要ります。チャットへの展開にも余地がありました。従来のシナリオ型チャットボットでは、お客さまからの多様なお問い合わせへの柔軟な対応や自然な対話の実現に課題がありました。 Amazon Connect Customer AI agents を選んだ理由 第 2 世代の運用を通じて、同社は 3 つの課題を明確に持っていました。Amazon Connect Customer AI agents の採用は、この 3 つに対応する判断です。 自社の AWS 環境内で構築できる 当時は外部の SaaS を利用する構成だったため、お客さまごとの状況に応じた応対を作り込むうえで制約がありました。Amazon Connect Customer AI agents は、すでに稼働している Amazon Connect Customer の環境に AI サービスを追加する形で構成できます。発信者番号やお客さまの属性といった、既存のコンタクトフローで扱っている情報を、そのまま応対の判断材料として使えます。 応対の処理が自社アカウントの中で完結することも、金融機関としては見過ごせない点です。ログの保管やアクセス制御は既存の統制の枠組みをそのまま適用でき、外部サービスとのデータ受け渡しについて個別に整理する手間がなくなります。 AI に任せる範囲とフローで案内する範囲を使い分けられる 従来の構成では、応対の分岐を追加するたびに「開発」が必要でした。Amazon Connect Customer では、意図の理解や FAQ の選択のように自律的な判断を AI agents に任せ、決まった手順どおりに実行したい決定論的な処理はコンタクトフローで組む、という分担ができます。どちらか一方に寄せるのではなく同じ基盤の上で組み合わせられることが、窓口を増やしていく際の開発負荷の軽減につながります。 通話時間とチャット数を基にした料金体系 トークンベースの料金体系では、利用量が増えたときのコストを事前に見積もりにくく、既存の仕組みとの単純比較も困難でした。AI agents は Amazon Connect Customer の料金体系に沿って通話時間とチャット数を基に課金されるため、コンタクトセンターの運用計画と同じ単位でコストを扱えます。 アーキテクチャ 図 2 カスタマーセンターの構成（ダイジェスト版） 構成の中心は Amazon Connect Customer AI agents と、それを呼び出すコンタクトフローです。お客さまが電話をかける、あるいは Web サイトからチャットを開始すると、コンタクトフローが AI agents に処理を渡します。AI agents は自社の FAQ を登録したナレッジベースを参照し、ご用件に応じた回答や次のご案内を返します。 AI agents に持たせているツールは 3 つの役割に分かれます。お客さまの発話や入力からコールリーズンを分類する処理、ナレッジベースから該当する FAQ を検索する処理、検索結果をもとに回答内容を組み立てる処理です。組み立てた結果はコンタクトフローに戻され、フロー側が音声での読み上げ、SMS による Web サイト URL のご案内、有人エージェントへの転送、電話予約のご案内へと振り分けます。 先に挙げた役割分担は、この構成にそのまま表れています。たとえば事故受付のように確実な取り扱いが求められる用件は、AI が分類した時点でフロー側の専用経路に載せます。AI agents の応答が得られない場合に有人転送へ縮退させる経路も、同じ考え方でフロー側に用意しました。 なお、ツールの実行結果をコンタクトフローに返して以降のルーティングをフローに任せるこの形は、Amazon Connect Customer の セルフサービス として提供されている構成です。 PoC で確かめたこと 2026 年 1 月、Amazon Connect Customer AI agents の PoC を実施しました。通話とチャットの両チャネルに対応でき、回答精度は 95% 以上を確認できました。 差がはっきり表れたのは、お客さまの質問が曖昧なケースです。 「キャンペーンについて知りたいんだけど」という問い合わせに対して、同社の従来の構成では複数あるキャンペーンにかかる FAQ のうち、お客さまが本当に知りたいのがどのキャンペーンに関するものか掘り下げることはできませんでした。 AI agents では「どのようなキャンペーンについて、お知りになりたいですか？」と聞き返し、「定期預金のキャンペーンです」という回答を受けてから該当する FAQ を選びます。有人オペレーターが自然に行っている用件の深掘りが、そのまま自動応対の中で成立します。 PoC は、ドコモSMTBネット銀行と AWS が課題管理表で論点を往復しながら進めました。曖昧な質問の聞き返しをどの条件で発生させるか、FAQ の信頼度が低いときに複数候補を提示するか、キーワードによって専用フローへ遷移させるか。こうした論点を、実際にプロンプトを修正して挙動を確認しながら決めています。プロンプトは Amazon Connect Customer の管理画面から編集できるので、試行のサイクルを短く回せました。 応答時間をどう縮めたか 自動応対では、回答が正しいことと同じくらい、待たされないことが体験を左右します。本番導入に向けて、Amazon Connect Customer AI agents の応答時間を検証しました。 お客さまが 1 回発話してから回答が返るまでに、AI agents は 2 回の推論と 1 回のナレッジ検索を行います。発話を分類して FAQ 検索ツールを呼ぶ判断が 1 回目の推論、検索結果から回答の引数を組み立てるのが 2 回目の推論です。この間はお客さまが待っている時間になります。 図 3 お客さまの 1 発話に対する処理の流れ（オレンジは待ち時間の主因となる LLM の推論） 検証で得られた知見は 2 点です。 1 点目は、所要時間が AI agents の出力トークン数にほぼ比例することです。AWS の検証環境で推論時間を出力トークン数で割ると、チャネルや構成を問わず 1 トークンあたり 15〜21 ミリ秒に収まりました。入力側であるナレッジ検索の結果件数を削っても、所要時間はほとんど変わりません。短縮の余地は、LLM に書かせるトークンを減らすことにありました。 2 点目は、AI agents が書いている内容の大半が固定値だったことです。フローに返す引数を項目ごとに分解すると、SMS の定型文や URL のプレフィクス、復唱の定型句など、約 9 割が問い合わせ内容によらない固定値でした。可変なのは FAQ の識別番号と、お客さまのご用件を復唱する部分だけです。 そこで、固定値はコンタクトフロー側で組み立て、AI agents には可変部だけを書かせる構成に見直しました。お客さまに提示される内容は変えないまま、応答時間を短縮できます。ここでも判断の主体をどちらに置くかという線引きが働いています。 なお、ここで示した数値は AWS の検証環境での測定値です。ナレッジベースの内容やコンタクトフローの構成によって変わるため、実際の短縮幅はご自身の環境で測ることをおすすめします。 運用開始後の改善 適切な応対を維持するには、稼働後もプロンプトの調整と精度のモニタリングを続ける必要があります。ドコモSMTBネット銀行は第 2 世代の運用でも、お客さまの照会内容と生成 AI が提示した FAQ を突き合わせて検証し、ヒット率を上げる改善を積み上げてきました。この地道な作業をどれだけ続けやすくできるかが、基盤を移した後のテーマになります。 Amazon Connect Customer には、この改善サイクルを支える機能があります。電話とチャットのやり取りは録音・文字起こしされ、すべてが会話分析の対象になります。そのうえで、AI agents が担当した自己解決のやり取りも、有人オペレーターと同じ枠組みで採点できます。 セルフサービスインタラクションのパフォーマンス評価 では、「お客さまのご用件は AI agents で解決できたか」といった基準を自然言語で評価フォームに定義しておくと、生成 AI が会話を自動で採点し、スコアの根拠とトランスクリプト上の該当箇所まで示します。意図の理解に繰り返し失敗している、お客さまの感情が悪化している、有人転送に至っている、といった観点も評価の対象にできます。 この仕組みを使うと、集計されたダッシュボードで傾向を掴み、気になるコンタクトに降りて録音とトランスクリプトを見ながらやり取りをターンごとに追う、という進め方ができます。どの発話で意図を取り違えたのか、どの FAQ が選ばれたのかが分かるため、直すべきはプロンプトなのかナレッジベースなのかを切り分けられます。生成 AI が下書きした評価を人が確認して確定する運用から始め、精度を確かめながら自動化を広げることもできます。 安定稼働を確認しながら、こうした仕組みを段階的に運用へ組み込んでいくことが次の段階になります。 今後の展開 2026 年 9 月から、電話とチャットの両チャネルで Amazon Connect Customer AI agents による応対を開始しました。まずは安定稼働を優先し、その先ではパーソナライズ機能の追加を検討しています。お客さまごとの状況に応じた自己解決の手段を広げていくことが次のテーマです。 Amazon Connect Customer のセルフサービスは、AI エージェントが複数ステップにまたがって推論し、必要なツールを自ら選んで会話を継続する エージェンティックセルフサービス へと進化しています。今回構築した基盤の上に、こうした機能を段階的に取り込んでいけます。 ドコモSMTBネット銀行からのコメント 今回の取り組みについて、ドコモSMTBネット銀行 執行役員の半田 英二様からは、以下のようなコメントをいただきました。 「当社のカスタマーセンターは、お客さまの『困った』に最短でお応えすることを大切にしてきました。今回の Amazon Connect Customer AI agents の導入は、その姿勢を自動応対の領域へと広げるものです。電話とチャットのどちらでも AI がご用件を的確に汲み取り、必要なときにはオペレーターが引き継ぐ。この組み合わせによって、お客さまの利便性と応対品質を両立させていきます。今後も最先端のテクノロジーを積極的に取り入れ、くらしと金融の境目のない体験の実現に取り組んでまいります。」 本件のシステム開発を担当されている、システム開発部の室 良樹様からは、以下のようなコメントをいただきました。 「今回はカスタマーセンター全体の要件を改めて整理し、電話とチャットの両チャネルを Amazon Connect Customer に集約しました。AI に委ねる領域とコンタクトフローで作り込む領域を分けることで、新しい機能や窓口を同じ基盤に追加していける構成としています。応答時間についても、AWS と共同で処理時間の内訳を切り分け、改善箇所を見極めてまいりました。担当のテクニカルアカウントマネージャーをはじめ、継続的な技術支援をいただいた AWS に感謝いたします。今後もこの基盤の上に最先端のテクノロジーを取り込み、お客さま一人ひとりに応じた応対を広げてまいります。」 まとめ ドコモSMTBネット銀行の取り組みで一貫していたのは、意図の理解のように自律的な判断は AI agents に任せ、確実性が求められる経路や定型文の組み立てといった決定論的な処理はコンタクトフローに寄せるという役割分担です。この線引きが、回答精度だけでなく応答時間と開発負荷にも影響していました。基盤の選定も、すでに稼働している自動応対の実績と残った精度課題を出発点にしています。 生成 AI 導入の二周目に入ったコンタクトセンターへの示唆は 2 つあると考えています。どこまでを AI に任せるかを決めてから基盤を選ぶこと。そして、運用開始後の改善を前提に設計しておくことです。プロンプトを管理画面から編集でき、お客さまのフィードバックを観測できる構成にしておけば、稼働後の精度向上を運用の中で回していけます。 Amazon Connect Customer AI agents については、 製品ページ と 管理者ガイド で機能と設定方法を確認できます。コンタクトセンターの応対高度化についてご相談があれば、担当の AWS メンバーまでお気軽にお声がけください。 著者について 遠藤 亘 (Wataru Endo) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 銀行業界のお客さまを担当しているソリューションアーキテクトです。AWS 全般を活用いただく際の技術的な課題解決に加えて、コンタクトセンターソリューションである Amazon Connect Customer の活用も支援しています。 三木 康次 (Koji Miki) アマゾン ウェブ サービス ジャパン合同会社 シニアテクニカルアカウントマネージャー 金融業界のお客さまを担当するテクニカルアカウントマネージャーです。AWS 利用全般の技術支援を通じて、お客さまのシステムの安定稼働と改善を継続的にご支援しています。 坂田 陽一郎 (Yoichiro Sakata) アマゾン ウェブ サービス ジャパン合同会社 シニアスペシャリストソリューションアーキテクト Amazon Connect Customer を専門とするスペシャリストソリューションアーキテクトです。コンタクトセンターの設計や生成 AI を活用した応対の高度化をご支援しています。

本記事は 2026 年 9 月 1 日に公開された “ Intelligent alarm management for power and utilities using Amazon Bedrock AgentCore ” を翻訳したものです。 発電および送配電 (T&amp;D) のオペレーターは、分散型制御システム (DCS)、SCADA、プロセスヒストリアン、設備保全管理システム (CMMS)、保護リレーなど、共通のインターフェイスを持たない複数の運用システムを扱っています。発電所の制御室や電力会社の運用センターでは、これらのシステム全体で 1 日に数千件のアラームを受け取ります。系統事故などの発生時には数分のうちに数十件のアラームが発生することがありますが、その大半は独立した障害ではなく、連鎖して発生する二次的なアラームです。根本原因を特定するには、3〜4 つのアプリケーションに個別にクエリを実行する必要があり、通常 25〜40 分かかります。 ISA-18.2、IEC 62682、EEMUA Publication 191 などの業界規格はアラーム管理のベストプラクティスを定めていますが、規格と現場の運用との隔たりは依然として大きいのが実情です。従来のアラーム管理ツールはルールベースで、個々のシステムの中で完結しています。そのため、プロセスヒストリアンのセンサーのトレンドを、CMMS 上の期限を過ぎた予防保全タスク、ドキュメント管理システムにある OEM の技術情報、チケットシステムにある過去の類似インシデントと関連付けることはできません。 本記事では、北米の大手電力会社が現在、 Amazon Bedrock AgentCore 上で運用しているマルチエージェント AI アーキテクチャを紹介します。このアーキテクチャにより、オペレーターがシフトごとに何十回も、複数のシステムをまたいで手作業で行っていた調査が不要になり、アラームのトリアージにかかる時間が数時間から数分に短縮されています。業界の課題、マルチエージェントの設計、ご自身の環境にデプロイできる GitHub 上のリファレンス実装について、順を追って説明します。 アラーム管理の課題 ISA-18.2 規格 (プロセス産業向けアラームシステムの管理) と EEMUA Publication 191 は、優れたアラーム管理のあり方を定義しています。規格と現実の隔たりは大きく、次の表のとおりです。 指標 ISA-18.2 / EEMUA 191 の目標値 アラーム管理を行っていない一般的な現場 オペレーター 1 人あたりのアラーム件数 1 時間あたり 6 件未満 1 時間あたり 40〜200 件以上 不要アラーム (ニューサンスアラーム) の割合 10% 未満 60〜80% アラームの大量発生を判定するしきい値 10 分あたり 10 件超 毎日超える スタンディングアラーム 常時 10 件未満 50〜200 件以上 従来手法によるアラーム合理化の期間 該当なし 12〜18 か月 訳注：スタンディングアラームとは、発生したまま数時間にわたって解消されないアラームのことです。 これらの数値は、発電所の制御室と T&amp;D の運用センターの両方に当てはまります。アラームの発生元は、発電所では DCS とプロセスヒストリアン (AVEVA PI など)、変電所では SCADA と IEC 61850 対応の IED (Intelligent Electronic Device、インテリジェント電子デバイス) と異なりますが、オペレーターが置かれている状況は同じです。アラームが多すぎる一方で判断に必要なコンテキストが少なすぎ、システムをまたいでアラームを自動で関連付ける手段もありません。 問題が解消されない理由 アラームを調査するオペレーターは、複数のサイロ化されたシステムに対して手作業でクエリを実行する必要があります。 プロセスヒストリアン (AVEVA PI など)：センサーのトレンドと変化率の分析 設備保全管理システム (CMMS、IBM Maximo や SAP PM など)：保全履歴、期限を過ぎた予防保全 (PM: Preventive Maintenance)、故障の傾向 ドキュメント管理システム：OEM のアラーム対応手順、IEEE や IEC の規格、標準作業手順書 (SOP: Standard Operating Procedure) チケットシステムとインシデント履歴：過去の類似イベントとその解決策 各システムでは、全体像の一部しか把握できません。振動のトレンドを、期限を過ぎたベアリングの交換、OEM の技術情報、計画外停止につながった過去の類似故障 3 件と、1 つで関連付けられるツールがないのが現状です。アラームが大量発生している中で、このように 1 つずつ順に調べるやり方は現実的ではありません。 ソリューションの概要 単一のモノリシックな AI エージェントでは、4 つのデータドメインすべてに効果的に対応できません。プロセスヒストリアンのデータには、時系列分析の専門知識が必要です。保全記録には、CMMS の作業指示 (ワークオーダー) のライフサイクルと、信頼性重視保全 (RCM) の理解が必要です。機器のドキュメントには、技術マニュアルを対象とした検索拡張生成 (RAG) が必要です。インシデント履歴には、構造化されたチケットのスキーマを対象とした SQL 分析が必要です。 この課題には、マルチエージェントパターンで対処します。データドメインごとに専門のエージェントを置き、スーパーバイザーエージェントがそれらを統括します。スーパーバイザーエージェントはアラーム管理の規格を理解しており、各データドメインの調査結果を、対応につなげられる 1 つのレポートにまとめます。 次の図は、ソリューションのアーキテクチャを示しています。 図 1：電力・公益事業向けインテリジェントアラーム管理 (Amazon Bedrock AgentCore 上のマルチエージェントによるトリアージのアーキテクチャ) 主要なコンポーネントは次のとおりです。 Amazon Bedrock AgentCore Runtime は、すべてのエージェントと Model Context Protocol (MCP) ツールサーバーを、マネージドランタイムとしてホストします。ネットワークやコンピューティングのオーケストレーション基盤をプロビジョニングする必要はありません。 Strands Agents SDK は、ツールの利用、推論トレース、ストリーミングレスポンスを備えたエージェントフレームワークです。このソリューションでは Python SDK を使用しています。 MCP ツールサーバー は、各バックエンドを標準化されたプロトコルで公開します。新しいデータソース (SCADA ヒストリアン、排出量監視システム、気象 API など) を追加する場合は、新しい MCP サーバーを 1 つデプロイします。既存のエージェントは変更しません。 Amazon Bedrock ナレッジベース と Amazon S3 Vectors は、機器マニュアル、SOP、OEM の技術情報、アラーム対応のランブック、過去のインシデントレポートを対象とした RAG を提供します。ソースドキュメントは Amazon Simple Storage Service (Amazon S3) バケットにアップロードします。ナレッジベースはそのバケットをオンデマンドで同期し、各ドキュメントをチャンクに分割します。 Amazon Titan Text Embeddings v2 で埋め込みを生成し、類似検索に使うベクトルを S3 Vectors に書き込みます。 Amazon Aurora PostgreSQL Serverless は、インシデントチケットを保存し、過去のインシデントや ISA-18.2 に基づくアラーム KPI の SQL 分析に使います。 Amazon Bedrock 上の Anthropic Claude Sonnet (本実装では Claude Sonnet 4.6) が、各エージェントの推論を担います。 4 つのデータドメインすべてを 1 つのエージェントで扱うと、コンテキストウィンドウが埋まりやすく、どのドメインにも汎用的な回答しか返せず、クエリも 1 つずつ順に処理することになります。マルチエージェントアーキテクチャでは、各エージェントが 1 つのドメインに絞り、深い専門知識 (ISO の振動規格、CMMS のライフサイクル、NERC PRC-005 への準拠) を持って処理できます。スーパーバイザーエージェントはすべてのエージェントを並列に呼び出すため、レイテンシーが短くなります。新しいデータソースを追加するときは、新しいエージェントと MCP サーバーを用意するだけでよく、既存のコンポーネントは変更しません。各エージェントが独自の推論トレースを出力するため、システムのすべてのステップを監査できます。 仕組み：トリアージの流れ この記事のユースケース例では、コンバインドサイクルガス発電所のオペレーターが、通常の日勤シフト中に 1 号機を監視しています。そこに新しいアラーム「TUR-001.BRG3.VIB: HIGH VIBRATION, 68 micrometers」が表示されます。 オペレーターは、チャットインターフェイスに次のように入力します。「タービン 1 号機のベアリング #3 の振動が 68 ミクロンでアラームが発生した。何が起きているのか？」 スーパーバイザーエージェントは、これをアラームのトリアージ要求と判断し、4 つの専門エージェントすべてに同時に処理を振り分けます。 PI Historian エージェント： プロセスヒストリアンにクエリを実行し、次の結果を得ます。 30 日間のトレンド：2 週間で振動が 45 から 68 マイクロメートルに上昇 ベアリング #3 の温度も連動して上昇：同じ期間に 68 から 78°C パターン分類：実在し、進行中 (チャタリング〔断続的なばたつき〕、一過性、古い値のいずれでもない) 現在の 1 日あたり 1.5 µm のペースでは、約 5 日で ISO 10816 の Alert しきい値 (80 µm) に達する Maximo Maintenance エージェント： CMMS にクエリを実行し、次の結果を得ます。 ベアリング交換の予防保全 (作業指示 WO#45678) が、期限を 2 か月過ぎている 直近の類似故障：TUR-001 のベアリング #2 (2026 年 3 月) で、3 日間の計画外停止が発生した 修理コスト：事前に修理した場合は平均 45,000 ドル、故障後に対応した場合は平均 180,000 ドル 必要なベアリングアセンブリは、倉庫に在庫がある Document Knowledge エージェント： ナレッジベースから次の情報を取得します。 OEM TIL-2024-017：H クラスガスタービンのベアリング振動の制限値 ISO 10816-3：68 µm は「Satisfactory (良好) 」ゾーン、80 µm は「Alert (警戒) 」、130 µm は「Alarm (警報) 」 OEM の推奨：トレンドが 1 日あたり 0.5 µm を超えたら、ベアリングの状態を調査する (現在は 1 日あたり 1.5 µm で、しきい値の 3 倍) Ticket Analytics エージェント： 設備のインシデントチケットを管理するデータベースにクエリを実行し、過去のインシデントについて次の結果を得ます。 保有設備全体で、類似のベアリング劣化が 3 件 3 件中 2 件は、7 日以内に対処しなかったため計画外停止に至った 早期に発見した場合の平均解決時間は、計画保全で 8 時間 スーパーバイザーエージェントは、これらの調査結果を 1 つのレポートにまとめます。 重大度：高 TUR-001 でベアリング #3 の劣化が進行中。現在のペースでは、振動は 5 日以内に ISO の Alert しきい値に達する見込み。振動と連動した温度上昇から、機械的な摩耗と判断できる。ベアリング交換の予防保全は期限を 2 か月過ぎている。 推奨アクション： 48 時間以内にベアリングの点検を予定する (部品は在庫あり) 振動の監視頻度を 1 時間ごとに上げる 早期警告のため、75 µm に条件付きアラームを設定する 次に需要が低くなる期間に、8 時間の保守時間を確保する 先送りした場合のリスク：保有設備の履歴から、10 日以内に計画外停止となる確率は 67 %。コスト差：計画保全で 45,000 ドル、計画外では 180,000 ドル以上。 処理時間の合計は数分です。同じシステムを手作業で調査すると、通常 40〜60 分かかります。 アラームが大量発生するシナリオ：発電と T&amp;D このアーキテクチャは、複数の設備にまたがってアラームが大量に発生した場合でも、同じパターンで処理します。たとえば、広い地域を嵐が襲っている間に、発電所と 3 つの変電所から 10 分間で 14 件のアラームがオペレーターのコンソールに殺到し、ISA-18.2 が大量発生と判定するしきい値を超えたとします。オペレーターが入力する質問は、次の 1 つです。「大規模な嵐で、コンソールにアラームが殺到している。実際の根本原因は何か。連鎖して発生した二次的なものはどれか。最初に何をすべきか？」 スーパーバイザーエージェントは、すべてのエージェントに処理を振り分けます。PI Historian エージェントはタイムスタンプを突き合わせ、独立した 2 つの事象を特定します。1 つは送電線の落雷事故で、下流で連鎖して発生した 8 件のアラームを伴いますが、これらは自然に解除されます。もう 1 つは、猛暑による変圧器巻線のホットスポット温度の上昇です。これは嵐とは無関係で、IEEE C57.91 のしきい値である 105°C に近づいています。スーパーバイザーエージェントは、根本原因と症状を切り分けて対応の優先順位を付け、該当する規格も引用して、それらすべてを 1 つの回答にまとめて提示します。 実装の詳細 この実装では、オーケストレーションに Strands Agents SDK を使い、バックエンドのデータソースを、言語に依存しない MCP ツールサーバーとして公開しています (Python と .NET の実装例を掲載)。ISA-18.2 のアラームパターン分類を含むドメインの専門知識は、エージェントのシステムプロンプトに直接記述しています。システム全体は、1 つの AWS Cloud Development Kit (AWS CDK) スタックでデプロイします。実装一式は GitHub で公開しています。 Strands SDK によるエージェントのオーケストレーション スーパーバイザーエージェントは、Strands Agents SDK を使い、Amazon Bedrock AgentCore の InvokeAgentRuntime API で専門エージェントを呼び出します。 @tool def invoke_specialized_agent(agent_key: str, query: str) -&gt; str: """Invoke a specialized Alarm Management agent and return its response.""" agent_arn = AGENT_REGISTRY[agent_key]["arn"] payload = json.dumps({"prompt": query}).encode("utf-8") response = agentcore_client.invoke_agent_runtime( agentRuntimeArn=agent_arn, runtimeSessionId=_current_session_id.get(), contentType="application/json", accept="application/json", payload=payload, ) body = response.get("response") or response.get("body") raw = body.read() if hasattr(body, "read") else body result_text = raw.decode("utf-8") if isinstance(raw, bytes) else str(raw) parsed = json.loads(result_text) return parsed.get("response", result_text) データアクセス用の MCP ツールサーバー 各バックエンドは、MCP サーバーを通じて公開しています。たとえば PostgreSQL MCP サーバーは、text-to-SQL の機能を提供します。SELECT 以外の SQL 文は、データベースに届く前に拒否する安全策を備えています。 @mcp.tool() def run_query(sql: str) -&gt; str: """Run a single read-only SELECT/WITH statement against the asset-ticketing database.""" _assert_select_only(sql) # Rejects INSERT/UPDATE/DELETE/DDL via sqlparse response = rds_client.execute_statement( resourceArn=CLUSTER_ARN, secretArn=SECRET_ARN, database=DATABASE_NAME, sql=sql, includeResultMetadata=True, ) columns = [c["name"] for c in response.get("columnMetadata", [])] rows = [dict(zip(columns, _decode(r))) for r in response.get("records", [])] return json.dumps({"sql": sql, "row_count": len(rows), "results": rows}, default=str) OEM の Web API SDK が .NET ベースのため、PI Historian MCP サーバーは .NET 8 で実装しています。AgentCore Runtime 上では、カスタムの ARM64 コンテナとして動作します。 var builder = WebApplication.CreateBuilder(args); builder.Services.AddMcpServer() .WithHttpTransport(o =&gt; o.Stateless = true) .WithTools&lt;SensorDataTools&gt;() .WithTools&lt;TrendAnalysisTools&gt;(); var app = builder.Build(); app.MapMcp("/mcp"); // POST /mcp on port 8000 app.Run("http://0.0.0.0:8000"); ここに MCP の大きな利点があります。MCP は、言語に依存しないプロトコルです。Python、.NET、Node.js をはじめ、HTTP を扱えるほとんどの言語で、Amazon Bedrock AgentCore 上の MCP ツールサーバーを実装できます。 ISA-18.2 に沿ったエージェントのプロンプト 各エージェントは、ドメインの専門知識をシステムプロンプトに直接記述しています。たとえば PI Historian エージェントは、すべてのアラームを ISA-18.2 のパターンカテゴリに分類します。 ### ISA-18.2 Alarm Pattern Classification Classify any alarm query into one of these patterns: - **Chattering**: cycles in/out more than 3 times in 1 minute (tuning/deadband issue) - **Fleeting**: clears on its own within seconds (noise/filtering issue) - **Standing**: continuously active for hours (largest source of alarm fatigue) - **Stale**: tag unchanged for days (suspect frozen signal/failed transmitter) - **Real and advancing**: monotonically tracking toward threshold (report time-to-threshold) 上のプロンプトの意味は、次のとおりです。 パターン 定義 問題 Chattering (チャタリング) 1 分間に 3 回超、発生/復帰を繰り返す チューニング/デッドバンドの問題 Fleeting (一過性) 数秒で自然復帰する ノイズ/フィルタリングの問題 Standing (スタンディングアラーム) 数時間にわたり、発生したままの状態が続く アラーム疲労 (alarm fatigue) の最大の原因 Stale (古い値) タグが数日間変化しない 信号凍結/伝送器故障の疑い Real and advancing (実在・進行中) しきい値に向かって単調に推移 本物の異常 (しきい値への到達までの時間を報告) Infrastructure as Code (IaC) システム全体は、1 つの親 AWS CDK スタックでデプロイします。親スタックは、次の 2 つのネストされたスタックで構成されています。 StorageStack (ネストされたスタック)：ドキュメントを保存する S3 バケットと、S3 Vectors を使う Amazon Bedrock ナレッジベース (1024 次元、コサイン類似度、Amazon Titan Text Embeddings v2) RuntimeStack (ネストされたスタック)：5 つの AgentCore エージェントランタイムと、4 つの MCP サーバーランタイム。スーパーバイザー、サブエージェント、MCP サーバーの間で必要な AWS Identity and Access Management (IAM) の権限も設定します。 cdk deploy alarm-management # Deploys both nested stacks in dependency order 設計上の主な判断 このソリューションのアーキテクチャは、4 つの設計判断に基づいています。いずれも、すぐに評価できることと、本番環境での安全性やオペレーターの信頼とのバランスを取ったものです。 デフォルトでモックを使い、すぐに評価できる： すべての MCP サーバーに、シミュレーターが組み込まれています。リポジトリをクローンしてデプロイすれば、ISA-18.2 の典型的なシナリオ 6 種類を収録したモックデータで、デモをエンドツーエンドで実行できます。実際のバックエンドへの切り替えは環境変数の設定で行い、コードの変更は不要です。 MCP によるデータソースの抽象化： 新しいデータソース (嵐との関連を調べる気象 API、排出量監視システム、SCADA ヒストリアンなど) を追加する場合は、新しい MCP サーバーを 1 つデプロイします。既存のエージェントとスーパーバイザーエージェントは変更しません。 推論の透明性： スーパーバイザーエージェントは、推論トレース全体をストリーミングで出力します。どのエージェントを呼び出したか、各エージェントで何が分かったか、調査結果をどのようにまとめたかが含まれます。オペレーターは、すべての推奨事項について根拠のつながりを確認できるため、システムの結論を信頼しやすくなります。 Text-to-SQL の安全性： PostgreSQL MCP サーバーは、すべての SQL 文字列を sqlparse で解析します。複数の文を含む入力、SELECT と WITH 以外のキーワード、網羅的な禁止キーワードの一覧に該当するものは拒否します。そのため、LLM がこのインターフェイスを通じてデータベースを変更することはできません。 前提条件 このソリューションを実装するには、次のものが必要です。 Amazon Bedrock で次のモデルにアクセスできる AWS アカウント (Anthropic Claude Sonnet 4.6、Amazon Titan Text Embeddings v2) AWS CDK v2.170 以降 Python 3.10 以降と .NET 8 SDK Docker (AWS CDK でコンテナイメージをビルドするため) デプロイと実行 次のコマンドで、インフラストラクチャをデプロイし、UI を実行します。 git clone https://github.com/aws-samples/sample-intelligent-alarms-agent.git cd sample-intelligent-alarms-agent # Deploy infrastructure cdk bootstrap aws://&lt;ACCOUNT_ID&gt;/&lt;REGION&gt; cdk deploy alarm-management # Run the operator chat UI locally cd ui/streamlit cp .env.example .env # Add SUPERVISOR_AGENT_ARN from CDK output streamlit run app.py 訳注：原文では cd intelligent-alarm-management-agent と記載されていますが、クローンされるディレクトリ名に合わせて修正しています。 デプロイ直後から、モックデータを使ってエンドツーエンドで動作します。本番データを使う準備ができたら、MCP サーバーの接続先を、お使いのプロセスヒストリアン、CMMS、Aurora PostgreSQL 互換エディション、Amazon Bedrock ナレッジベースに切り替えてください。 デプロイの確認 Streamlit が起動したら、「過去 24 時間の TUR-001 のベアリング #3 の振動トレンドを表示して」などのサンプル質問を入力します。UI に、推論トレース付きの回答がストリーミングで表示されます。これで、Streamlit アプリケーション、スーパーバイザーエージェント、PI Historian エージェントに接続でき、それぞれが応答していることを確認できます。 コストについて このリファレンスアーキテクチャは、AgentCore Runtime、Amazon S3、Amazon Bedrock ナレッジベース、Amazon Elastic Container Registry (Amazon ECR) など、課金対象の AWS リソースをプロビジョニングします。モックモードで動かす低トラフィックのデモであれば、月額で約 10〜30 ドルが目安です。実データに接続して使う場合 (Aurora クラスター、継続的な呼び出し、ナレッジベースへの大量の取り込み) は、費用が大幅に高くなります。実際のコストは、AWS Cost Explorer で確認してください。 クリーンアップ デプロイしたリソースを削除するには、次のコマンドを実行します。 cdk destroy alarm-management このコマンドを実行すると、アップロードしたドキュメントとナレッジベースに取り込んだデータが削除され、元に戻せません。独自に追加したドキュメントは、実行する前にバックアップしてください。 ソリューションの拡張 このリファレンスアーキテクチャが示しているのは、発生したアラームに対応するトリアージです。オペレーターが質問をすると、数分で回答が得られます。発展させる方向として、次のものが考えられます。 予測的なアラーム ：同じ PI Historian エージェントで、学習したベースラインと比べてトレンドを継続的に監視し、アラームが発生する前に劣化を捉える 作業指示の自動生成 ：システムが保全の必要性を特定したときに、正しい故障コード、優先度、部品リストを含む Maximo の作業指示の下書きを作成する アラーム合理化の加速 ：Ticket Analytics エージェントで頻発するアラーム (バッドアクター：発生頻度が上位 N 件のアラーム) を特定し、ISA-18.2 の目標値に沿って、抑制、優先度の見直し、設定値の変更を提案する シフト引き継ぎの支援 ：退勤するシフトのアラームの発生状況、進行中の調査、未完了の対応を、次のシフトのオペレーター向けに要約する Amazon Bedrock AgentCore Gateway によるツールのスケーリング このリファレンス実装では、起動時に、各 MCP サーバーのツール一覧のすべてをエージェントに渡しています。現在の規模 (4 つのサーバーで計十数個のツール) では、この方法で問題ありません。しかし、接続するデータソースが SCADA、気象、排出量、保護リレーなどへと広がると、ツールの合計数はいずれ、1 つのエージェントのコンテキストに無理なく収まる範囲を超えます。ツール数がおよそ 50〜100 個を超える場合は、Amazon Bedrock AgentCore Gateway を使う構成が推奨されます。ツールはゲートウェイに登録しておき、エージェントは、すべてのプロンプトにすべてのツール定義を含めるのではなく、クエリごとに意味的に関連するツールだけを取得します。これにより、データソースを追加しても、プロンプトの大きさに上限を保ち、レイテンシーも見通せる範囲に収まります。 セキュリティとコンプライアンスの態勢 このアーキテクチャは、ID、暗号化、ネットワーク分離、監査の各領域で、多層防御を実現しています。 エージェントの最小権限 ：各 AgentCore エージェントランタイムと MCP サーバーランタイムは、それぞれ専用の IAM 実行ロールで動作し、ポリシーの範囲は厳密に絞っています。スーパーバイザーエージェントはサブエージェントを呼び出せますが、サブエージェント同士は呼び出せません。MCP サーバーには、それぞれのバックエンドへの接続に必要な権限だけを与えています。これにより、ラテラルムーブメント (横方向への侵害の拡大) を設計の段階で防ぎます。 シークレットの管理 ：バックエンドの認証情報は AWS Secrets Manager に保存し、実行時に Amazon リソースネーム (ARN) で参照します。シークレットは、エージェントのプロンプト、環境変数、ソースコードには埋め込みません。Secrets Manager は自動ローテーションに対応しており、アクセスは AWS CloudTrail で監査します。 保存時と転送時の暗号化 ：Amazon S3、Aurora PostgreSQL 互換エディション、Amazon Bedrock ナレッジベースに保存するデータは、 AWS Key Management Service (AWS KMS) で暗号化します。キーのローテーションのポリシーと、アクセスログの記録は設定できます。サービス間の通信は、TLS 1.2 以降で暗号化した経路を通ります。 ネットワークの分離 ：AgentCore Runtime と MCP サーバーは、マネージドなコンピューティング環境で動作し、デフォルトではパブリックインターネットに公開されません。オンプレミスのシステムへの接続は、 AWS PrivateLink や仮想プライベートクラウド (VPC) エンドポイントを経由させることができ、OT/IT のデータがパブリックインターネットを通らないようにできます。 ログ記録と監視 ：CloudTrail は、Amazon Bedrock、Amazon Bedrock AgentCore、Secrets Manager、Amazon S3、AWS KMS の API 呼び出しを記録します。 Amazon CloudWatch は、エージェントの呼び出しメトリクス、レイテンシー、エラー率を収集します。スーパーバイザーエージェントの推論トレース全体はセッションごとにログに記録され、どのエージェントを呼び出したか、どのデータにアクセスしたか、調査結果をどのようにまとめたかが残ります。 ガードレール ：Amazon Bedrock Guardrails は、モデルの呼び出しに、コンテンツフィルターと拒否トピックのポリシーを適用します。これにより、プロンプトインジェクションを防ぎ、安全でないコンテンツの生成をブロックし、扱う話題の範囲を制限して、エージェントが担当する業務の範囲にとどまるようにします。 まとめ 電力・公益事業におけるアラーム管理は、知見が十分に蓄積された運用分野です。ISA-18.2 や EEMUA 191 などの業界規格が目標値を定めており、課題も数値で示されています (不要アラームが 60〜80% を占め、アラームの大量発生が毎日起きている)。また、適切なアラーム管理は、運用の信頼性を高める重要な要素とされています。残る課題は、分断された運用システムをまたいで、リアルタイムに関連付けることです。 Amazon Bedrock AgentCore 上のマルチエージェントアーキテクチャは、この課題に対応します。専門エージェントが各データドメインに並列でクエリを実行し、スーパーバイザーエージェントがアラーム管理の規格に照らして調査結果をまとめます。推論の過程をすべて示しながら、トリアージにかかる時間を数時間から数分に短縮します。 リファレンス実装 は、クローンしてデプロイすれば、お手元の運用データで評価できます。まずモックのシナリオでエージェント間のやり取りを確かめ、次にお使いの PI Historian、CMMS、ドキュメント管理システムを接続して、実際のアラームで効果を確かめてください。 本ブログはソリューションアーキテクトの筒井 智哉が翻訳しました。 Muthu Kumar Muthu Kumar は AWS のシニアソリューションアーキテクトです。エネルギー・公益事業のお客様が、運用の高度化に向けてクラウドと AI の技術を導入できるよう支援しています。テクノロジーを活用し、お客様とともにビジネスの成果を上げることに力を注いでいます。 Ganapathi Krishnamoorthi Ganapathi Krishnamoorthi は AWS の生成 AI と機械学習を担当するプリンシパルスペシャリストソリューションアーキテクトです。お客様が本番環境の AI/ML システムを設計、実装できるよう支援しています。 Stephen Knox Stephen Knox は AWS のプリンシパルカスタマーソリューションマネージャーです。電力・公益事業のお客様と協力し、クラウドの価値の実現を推進しています。エネルギー企業がデジタルトランスフォーメーションを加速し、運用を最適化し、サステナビリティに関する約束を果たせるよう、戦略的な助言を行っています。エネルギー業界全体で、ビジネス戦略とテクノロジーの成果を結び付けることに力を注いでいます。

AI コーディングエージェントは数分で ABAP を生成できますが、スペック（仕様）がなければ、次の開発者にはなぜそのようにコードが作られたのかという記録が残りません。現在、多くの ABAP チームは SAP ABAP コードの作成やモダナイゼーションにバイブコーディングを用いています。結果は早く得られますが、コードの背後にある開発上の判断は失われ、要件が変わったときの修正が難しくなります。 SAP ERP Central Component (ECC) を今も運用しているお客様の SAP ABAP チームは、RISE with SAP へのアップグレードに先立ち、カスタムコードをレビューしてモダナイゼーションするようますます強く求められています。ABAP コードは、それを書いた開発者が別の役割に移った後も長く残り続け、ドキュメントは存在しないか古くなっています。ABAP のモダナイゼーションに同じバイブコーディングのアプローチを取ると、何をなぜ変更したのかの記録がないまま、ドキュメント化されていないコードがさらに増えていきます。 本記事では、ABAP におけるスペック駆動開発 (SDD) の仕組み、良い ABAP スペックに含めるべき内容、そしてトランスポートのリリース後もスペックが役立ち続ける方法を紹介します。例では AWS Coding Plugin for SAP ABAP を使用します。これは、AWS のエージェント型開発環境である Kiro のコマンドラインインターフェース Kiro CLI 上で動作します。プラグインの機能とインストール方法については、 AWS Coding Plugin for SAP ABAP, powered by Kiro のご紹介 &nbsp;を参照してください。 バイブコーディングの問題点 バイブコーディングを使えば素早く開発できますが、複雑な要件や大規模な ABAP コードベースでは、コンテキストが失われ、判断がドキュメント化されないまま残るため、開発チームは苦労します。コンテキストウィンドウには上限があり、50 メッセージ前に AI コーディングエージェントに伝えたビジネスルールが、気付かないうちに対象外になってしまうことがあります。会話が長くなるにつれ、エージェントは当初の意図を解釈し直し始め、やり取りのたびに方向がずれていきます。コードはコンパイルされ有効化もされますが、意図したとおりには動作しません。 その結果、正しく見えても実際の業務シナリオでは失敗するコードが生まれます。そして次の開発者がそのプログラムを引き継いだとき、スペックも設計上の根拠もなく、あるのはコードとトランスポートの説明だけです。開発者はまた、コンテキストを理解するためにプログラムを 1 行ずつ読み解くことになります。 スペック駆動開発とは スペック駆動開発は、ワークフローの中心に仕様を据えます。ABAP コードを生成する前に、要件、システム設計、実装上の判断を定義します。主要な判断が明示的に記録されるため、複雑な要件にも少ない反復で取り組みやすくなり、何をなぜ作ったのかという明確な記録が残ります。要件が変わったときは、スペックを更新して ABAP コードを再生成します。 Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl の中で、Birgitta Böckeler は SDD の 3 つのレベルを説明しています。 Spec-first（スペックファースト） : コードを生成する前にスペックを書きます。ABAP 開発者にとっては機能仕様書として馴染みのあるステップです。 Spec-anchored（スペックアンカー） : 作業完了後もスペックを保持し、以降の変更に利用します。 Spec-as-source（スペック・アズ・ソース） : スペックのみを編集し、生成されたコードには一切手を加えません。 SDD が ABAP 開発に適しているのは、スペックがすべてのセッションの開始時に読み込まれ、コンテキスト内に保持され続けるためです。スペックは平易な言葉で書かれるため、AI コーディングエージェントが 1 行のコードを書く前に、機能コンサルタントや新しい開発者がレビューできます。エージェントは双方が合意したタスク定義に基づいて作業し、その定義は会話全体を通じて維持されます。 AWS Coding Plugin for SAP ABAP は、要件・設計・タスクを記録する 3 つの Markdown (.md) ファイルによって、ABAP にスペック駆動開発をもたらします。 ABAP スペックに含めるべき内容 良い ABAP スペックは、シニア開発者が作業を始める前に確認する質問に答えるものです。レポート、クラス、汎用モジュール、Business Add-In (BAdI) 実装といったオブジェクトタイプを明記します。入力と出力、ビジネスルールを列挙し、データが欠落している場合や呼び出しが失敗した場合に何が起こるかを記述します。 スペックには、エージェントがビジネス要件から推測できない SAP 上の判断を明記します。これらを未定義のままにすると、エージェントはコンパイルは通るものの要件に合わないものを選んでしまいます。スペックでは、BAdI、ユーザーエグジット、新規プログラムのいずれであるかといった拡張手法を明記すべきです。 スペックには、そのタスク固有の事項を記録します。命名規則、承認済みライブラリ、再利用可能なスキルといったチーム全体の標準は、エージェントが自動的に読み込むステアリングファイルに置きます。 次の例は、ABAP レポートの例における要件ファイルの一部です。 Requirements: Program type: Report (executable program) User story: As a sales back-office clerk, I want to see open sales orders that are past their requested delivery date, grouped by age, so that I can follow up with the customers. Input: Sales organization (required), customer (optional), order date range (optional) Output: ALV list using CL_SALV_TABLE (no REUSE_ALV function modules or classic lists), grouped by overdue aging buckets (30 days or less, 31 to 90 days, more than 90 days) Acceptance criteria: 1. The selection screen requires a sales organization and accepts an optional customer and order date range. 2. The report runs an AUTHORITY-CHECK for the sales organization before it reads any data. 3. Orders are grouped as 30 days or less, 31 to 90 days, and more than 90 days overdue. 4. If no orders match, the report shows an information message and doesn’t display an empty list. 5. Database access uses Open SQL with host variables escaped by @. No SELECT *. 6. After each successful BAPI call, commit with BAPI_TRANSACTION_COMMIT. 7. Exceptions use CX_ROOT subclasses. No MESSAGE statements in methods. 8. ABAP Unit tests cover the grouping logic and use test doubles for database access. スペックからトランスポートのリリースまで ABAP の観点で見たスペックからトランスポートのリリースまでの道のりは、 AI-Driven Development Lifecycle (AI-DLC) に沿って進みます。AI-DLC は、次の図に示すように、AI ネイティブな開発を Inception（開始）、Construction（構築）、Operations（運用）の 3 つのフェーズに構造化する方法論です。 AWS Coding Plugin for SAP ABAP では、各フェーズは次のように進みます。 Inception（開始） : エージェントはセッション開始時にステアリングファイルを読み込み、スペックを起案する前にチームの標準、ベストプラクティス、承認済みライブラリを適用します。開発者とエージェントが協力して要件を定義し、設計について合意します。エージェントは重複を避け確立されたパターンに従うため、ABAP リポジトリから関連オブジェクトを検索します。そのうえで、考慮すべきエッジケースを提案します。開発者はその結果を検証し、ビジネス上のコンテキストを提供します。エージェントがスペックを起案し、開発者がそれを修正・承認します。承認前にコードが書かれることはありません。 Construction（構築） : エージェントは ABAP コードを書いて有効化し、ベースラインに対して ABAP Test Cockpit (ATC) チェックを実行します。また、新規および既存の ABAP Unit テストの両方を実行します。すべてのチェックに合格するまでこのループを繰り返します。その後、オブジェクト間の問題を検出するためにトランスポート全体を一括で有効化し、トランスポートの長いテキストを作成します。エージェントは、SAP 開発システム上で開発者の SAP ユーザーの権限で動作します。開発者はコードをレビューし、結果がスペックと一致していることを確認します。「すべてのチェックに合格」はレビューの終わりではなく、始まりとして捉えてください。 Operations（運用） : トランスポートを本番環境にインポートします。スペックを Git リポジトリにコミットすることもでき、各変更の背後にある意図を保存できます。要件が変わったり不具合が見つかったりすると、サイクルは Inception に戻ります。各イテレーションは既存のスペックから始まります。 このワークフローで生成されたコードに問題がある場合は、失敗の種類に注目してください。構文エラー、有効化エラー、テストの失敗は、Construction フェーズでエージェントが修正すべきものです。コードが有効化されすべてのテストに合格しているのに誤った結果を出す場合、問題はスペックにある可能性が高いでしょう。 修正するには、スペックで期待する結果をより具体的にする、テストケースを追加する、またはシステム内ですでに正しく動作している類似コードをエージェントに示します。エージェントが誤った BAPI やクラスを選ぶ場合は、正しいものをスペックに明記します。 エージェントが何度も間違える BAPI のように、このタスク以外にも当てはまる修正をスペックに加えた場合は、それをステアリングファイルに移します。次のスペックは、その教訓をあらかじめ組み込んだ状態から始まります。 新規コードと既存コード 新規開発の場合、進め方はシンプルです。スペックを書き、コードを生成し、検証してテストします。 ABAP の作業では、SAP S/4HANA に向けたコードのモダナイゼーション、SAP クリーンコア原則への準拠、新しいビジネス要件への対応など、既存コードの変更が伴うことがよくあります。 こうした変更では、まずエージェントにプログラムの現在の処理内容を要約させ、その要約をスペックの土台にします。次に、変更しない部分も含めて、目指す最終状態の全体像を記述します。差分だけを扱うスペックでは、それ以外のすべてについてエージェントが推測することになります。ビルド後は、既存機能が引き続き期待どおりに動作することを確認します。 このアプローチに従うと、ドキュメント化されていなかったプログラムが、変更を重ねるごとに徐々にスペックを獲得していきます。変更のたびにスペックが追記され、数回のイテレーションを経ると、以前は存在しなかった最新のドキュメントがプログラムに備わります。 ステアリング: すべてのスペックの背後にある標準 どのチームにも、ABAP オブジェクトの命名規則、出力パターン、トランスポートの説明など、ABAP 開発全体に適用される標準があります。これらの標準は、エージェントがすべてのセッションの開始時に読み込む Markdown ファイルであるステアリングファイルに含めるべきです。AWS Coding Plugin for SAP ABAP は、接続された SAP システムごとにステアリングファイルを作成します。一般的なステアリングファイルには、次のような標準が含まれます。 ABAP development standards - Report naming conventions: Z&lt;module&gt;_&lt;description&gt;, for example, ZFI_, ZSD_, ZMM_ - ALV output: CL_SALV_TABLE only, no classic list output - Exceptions: CX_ROOT or a subclass, errors logged to the application log (SLG1) - Database access: Open SQL only, host variables escaped with @, no SELECT * - Testing: 80% coverage for business logic, test doubles for database access - Transport description: [TICKET-ID] Brief description スペックはタスク固有の事項に使い、ステアリングでは従うべき標準をエージェントに示すようにしてください。 組織で多数の ABAP プロジェクトを運用している場合、ステアリングファイルとスペックテンプレートは再利用可能な資産になります。あるプロジェクト向けに作成したクリーンコアのステアリングファイルが、次のプロジェクトの出発点になります。 早速始めましょう AWS Coding Plugin for SAP ABAP のインストールについては、 開発者ドキュメント を参照してください。セットアップが完了したら、小さなタスクでスペック駆動開発を試してみましょう。 Eclipse ADT 環境からサンドボックスの SAP システムに接続します。 期待される結果がすでに分かっている、単純なレポートを選びます。 エージェントと一緒にスペックを書き、コードが生成される前に承認します。 完成したスペックを Git にコミットします。そのレポートに次の変更要求が来たら、スペックから始めます。 SAP S/4HANA 上の完全な ABAP アプリケーションに AI-DLC を適用したステップバイステップの例については、 AI-DLC（AI 駆動開発ライフサイクル）による SAP ABAP アプリケーション開発 &nbsp;を参照してください。 まとめ 本記事では、スペック駆動開発によって AI が生成した ABAP コードの背後にある根拠をどのように保持できるかを紹介しました。エージェントがコードを生成する前に、要件・設計・タスクを書きます。共通の標準はステアリングファイルに保持し、スペックはチャットセッション終了後も残るため、何をなぜ作ったのかという明確な記録になります。次の変更要求で、AWS Coding Plugin for SAP ABAP を使ってぜひ試してみてください。スペック駆動の ABAP 開発についてのご経験を、ぜひコメントでお聞かせください。 AWS Coding Plugin for SAP ABAP は無料でご利用いただけます。Kiro CLI のサブスクリプションが必要で、無料枠（50 クレジット）から始められます。より大きな容量が必要な場合の有料プランは、月額 20 ドルの Pro から月額 200 ドルの Power まであります。詳細は Kiro の料金 を参照してください。 著者について Stephan Kremer は AWS のシニア SAP スペシャリストソリューションアーキテクトです。SAP のお客様とともに ABAP のモダナイゼーションやクラウド移行に取り組んでいます。 Adren D Souza は AWS のシニア SAP パートナーソリューションアーキテクトです。グローバルシステムインテグレーター (GSI) とともに、AWS 上での SAP の移行とモダナイゼーションに取り組んでいます。 <!-- '"` --> 本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

Claude Haiku 5.5 が本日より Kiro IDE 、 CLI 、 Web 、 Crew のすべてで利用可能になりました。Claude 5.5 ファミリーで最も高速なモデルで、大量に実行され素早い応答が求められる作業を想定しています。Claude Haiku 4.5 から明確に進化しました。Haiku 5.5 の登場で、Claude 5.5 の 3 つのモデルがすべて Kiro で使えるようになります。最も難しい問題には Opus 5.5 、日常的なコーディングには Sonnet 5.5 があり、処理量や速度が何より重要な場面では Haiku 5.5 が担います。 より速く、より高性能に Anthropic のデータ によると、Haiku 5.5 は Anthropic がこれまでにリリースした中で最も高速なモデルで、Haiku 4.5 から品質も大きく向上しています。エージェント的なコーディングを測る Terminal-Bench 4.0 では 0.0% から 39.2% に、実務的なナレッジワークを測る GDPval-AA v2.1 では 735 から 1620 にスコアを伸ばしました。 速度とコスト効率が求められる作業向け Haiku 5.5 は、量が多く速度が重要で、コストも気になる作業に向いています。長いコンテキストの要約や圧縮、リクエストの分類やルーティング、大量のテキスト処理、多数のファイルにまたがる小さく限定的な編集などです。並列で動かすレビュー用やコンピューター操作用のサブエージェントとしても力を発揮します。 Adaptive Thinking に対応し、effort は low から max までの 5 段階で設定できます(既定値は medium)。コンテキストウィンドウは 1M トークンです。 安全性 Haiku 5.5 には Anthropic のセーフガードが組み込まれており、モデルの制御は Haiku 4.5 より厳しくなっています。防御目的のセキュリティ作業については Sonnet 5.5 のセーフガードより幅広く通す一方で、ペネトレーションテストなど攻撃者側の利用に寄った手法は引き続き断ります。 生物学関連のセーフガードは Sonnet 5、Sonnet 5.5、Opus 5 と同じです。研究レベルの質問は通り、危害につながるおそれがあると判断されたリクエストは制限されます。 提供状況 Claude Haiku 5.5 は本日より、us-east-1 (バージニア北部) および eu-central-1 (フランクフルト) の Kiro Pro、Pro+、Pro Max、Power をご利用のお客様に 実験的サポート として提供されます。 クレジット乗数は 0.06 倍 です。100K トークンを超えるリクエストは 0.3 倍の乗数で課金されます。これは Anthropic と Amazon Bedrock における Haiku 5.5 の長いコンテキストの料金体系に合わせたものです。 この記事は Kiro ブログの Claude Haiku 5.5 is now available in Kiro を翻訳したものです。

SAP ABAP コードを書くエンタープライズ開発者は、複雑に統合されたシステムの中でビジネスロジックを実装・変換しなければなりません。この課題に対処するために、ABAP 開発者には、エージェントと開発者の協働を通じてビジネス要件の解決を中心に据えた AI コーディングツールが必要です。スペック駆動開発 (SDD) は、ビジネス要件を最優先する規律ある方法論です。 2025 年、Kiro はエージェント型開発への構造化されたアプローチとして、SDD を開発者コミュニティにもたらしました。そして本日、お客様が SAP の ABAP Development Tools (ADT) と併せて Eclipse で SDD を活用できるよう、Kiro を搭載した AWS Coding Plugin for SAP ABAP をリリースしました。ABAP 開発者は、普段お使いの ABAP エディタでスペックファーストのワークフローを利用できるようになりました。 「AWS Coding Plugin for SAP ABAP と、スペック駆動開発プロセスにビジネス要件を組み込むその能力に感銘を受けました。わずか 5 時間で、当社の TMS コードのカスタマイズをレビューし、今後予定されている変更との互換性を検証し、さらに深掘りに活用できるレポートを作成してくれました。」Mondelēz International、Continuous Integration Lead、Rajesh Shah 氏 協働型のアプローチ AWS Coding Plugin for SAP ABAP は、設計フェーズで開発者を巻き込むことで ABAP 開発ワークフローを変革します。その後、エージェントは実装中に自律的に作業できます。そして引き渡しの準備ができたときや要件が変わったときに、再び開発者と連携します。 Coding Plugin は、Eclipse 内のエージェント型チャットを通じて開発者と連携します。必要なことを説明すると、プラグインが開発者にヒアリングしてステアリングドキュメントを作成し、ビジネス要件の定義を協働で進めます。次に、稼働中の SAP バックエンドで見つけた関連 ABAP オブジェクトに基づいてソリューションを設計します。そしてその設計に基づく実装計画を提案します。この「スペック」は、開発者とエージェントの協働の成果物です。スペックがあることで、エージェントは自らテストし、高品質な結果に向けて反復しながら、大規模な開発、変換、改善に取り組むことができます。チャットでは、Coding Plugin が adt:// ハイパーリンクを記述できるため、参照している ABAP コードやオブジェクトにすばやくジャンプできます。さらに、変更内容のレビューやコードについての議論のために、エディタでオブジェクトを開くこともできます。 Coding Plugin は、Kiro の思考プロセスと Kiro のツール承認プロンプトを表示します。Kiro は、チケット管理システム、社内ドキュメント、メッセージングなど、組織の MCP サーバーにも接続できるため、ABAP チームのエンドツーエンドの開発ワークフローの一部として機能します。 プロンプトの例 Coding Plugin の動作を示すプロンプトの例をいくつか紹介します。 「テーブル ZLOGISTICS に新しい項目を追加し、関連する検証ロジックを更新するスペックを書いてください。レポート ZFREIGHT_PATH に最近加えた変更を考慮してください。結果の出力が添付のスプレッドシートのサンプルデータと一致することを検証してください。」 「パッケージ ZFINANCE のオブジェクトをレビューし、abapdoc アノテーションと必要に応じたインラインコメントでドキュメント化するスペックを作成してください。パッケージ ZSHIPPING に見られる社内スタイルに合致していることを検証してください。」 「パッケージ ZSALES のクラスにユニットテストを追加し、ATC を使ってクリーンコア準拠のために反復的にリファクタリングするスペックを作成してください。最後にユニットテストが引き続き合格することを検証してください。」 AWS Coding Plugin for SAP ABAP はどのような方に適しているか AWS Coding Plugin for SAP ABAP は、エージェント型ツールとの協働を求める ABAP 開発者のチームに最適です。プログラマーのドメイン知識とビジネスの専門性を尊重しつつ、Kiro のコーディング能力を活用します。IBM Consulting の SAP AI Leader である Devraj Bardhan 氏は次のように述べています。「AWS Coding Plugin for SAP ABAP を開発ワークフローに統合したことで、カスタム ABAP 拡張の開発時間を最大 30% 短縮し、開発後の不具合を最大 45% 削減しました。これにより、最初の 1 行のコードからセキュリティとコンプライアンスを組み込んだエンタープライズグレードの SAP ソリューションを、より迅速にお客様に提供できるようになりました。当社の SAP 開発者が日々頼りにしている環境に、ABAP 向けの真のコーディングエージェントをもたらしてくれた AWS に敬意を表します。」 Coding Plugin の特長は次のとおりです。 ABAP エディタの中で動作。Coding Plugin は、関連オブジェクトを Eclipse ワークベンチで直接開き、開発者が見ている内容を追いかけることで人間のエキスパートと協働します。まるで隣に座っている開発者のように機能します。 スペック駆動開発。Coding Plugin は、コードを生成する前に仕様を書くことを中心に作られています。つまり、テスト可能な成功基準をあらかじめ定義し、大きな変更を軌道に乗せ続けるタスクリストを維持します。 手間の少ないセットアップ。インストールは、Eclipse に SAP ADT をインストールするのと同じ手順です。Coding Plugin はバックグラウンドで Kiro CLI を起動し、MCP 接続を自動で構成します。Eclipse ですでに定義済みの ABAP への接続をそのまま使うため、別の認証や接続経路を追加することはありません。 ABAP 規模のコンテキストに対応。ツールは、長い ABAP Test Cockpit (ATC) の結果や大きなコードオブジェクトに対しても効率を保つよう調整されており、コンテキストを節約して使用します。 現在の環境に合わせて設計 SAP ECC を運用し、S/4HANA と RISE への移行を進めているお客様こそ、エージェント型開発を最も必要としています。Coding Plugin は ECC から S/4HANA、BTP ABAP まで、幅広い ABAP ベースのシステムをサポートしているため、クリーンコアと RISE への道のりを加速できます。 はじめに AWS Coding Plugin for SAP ABAP の要件は次のとおりです。 Eclipse 2026-06 以降 SAP ADT 3.60 以降 Kiro のサブスクリプション AWS Coding Plugin for SAP ABAP は無料でご利用いただけます。お支払いいただくのは使用した Kiro クレジットのみです。詳細とプラグインのインストールについては、 開発者ガイド をご覧ください。 <!-- '"` --> 本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。今週も生成 AI に関する 1 週間のアップデートをお届けします。 いつもご案内している生成 AI を活用したビジネス課題の解決を支援する AWS ジャパン生成 AI 実用化推進プログラム について、このプログラムの 1 コースである 「 フィジカル AI 開発支援プログラム by AWS ジャパン 」第 2 期 の応募受付が始まりました。VLA をはじめとするロボット基盤モデルや、VLM、世界モデルなどの周辺技術を AWS 上で開発する企業・団体が対象で、スタートアップから大企業、大学・研究機関まで応募できます。フィジカル AI のスペシャリストによる技術支援、コスト最適化、コミュニティ形成、GTM 支援が受けられ、第 1 期に応募した方も再応募が可能です。締切は 11 月 16 日（月）なので、ロボティクス × 生成 AI に取り組んでいる方は是非ご検討ください。 また、 re:Invent 2026 のセッションカタログ も公開されていますのでこちらもチェックしてみてください。 それでは 10 月 19 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「 約 3 万人のAIネイティブエンジニア体制へ ― NEC は Claude Code をどう全社展開しているのか？ CoE・チャンピオン制度による取り組み 」 NEC は全社員 (最大 12 万人) 向けに Claude Desktop on Amazon Bedrock を展開しています。開発現場では約 3 万人の AI ネイティブエンジニア体制を目指し、Claude Code on Amazon Bedrock の活用を広げています。成功要因として、各事業部門の推進体制 (部門 CoE)、チャンピオン制度、Skills による知見の標準化の 3 つを挙げています。2026 年 7 月と 8 月には NEC と AWS の共催で Claude Code ワークショップを開き、延べ 158 名が参加しました。アンケートでは 93% が開発業務で活用したいと回答しています。生成 AI ツールの定着を進める大規模組織にとって、推進体制と人材育成の組み合わせ方の具体例になります。 AWS生成AI国内事例ブログ「 株式会社コーテッグ様の「聞くだけ」で分析が完結する AI 分析基盤「Dotta」を Amazon Bedrock AgentCore で実現 」 株式会社コーテッグは、自然言語で問いかけるだけでデータの取得・集計から可視化、レポート生成まで完結する AI 分析プラットフォーム「Dotta」を構築しました。Amazon Bedrock AgentCore を中核にした非同期の AI エージェント基盤です。分析処理は数十秒から数分かかるため、Amazon SQS と AWS Lambda から AgentCore Runtime を呼び出す構成にしています。分析には Claude Opus 4.8 / Sonnet 4.6、軽量な処理には Claude Haiku 4.5 と使い分けています。試算では 1 件 240 分の分析業務が約 10 分になります。長時間実行するエージェントを UI を止めずに本番運用する設計の実例として、エージェント基盤を検討中の方に役立ちます。 ブログ記事「 Amazon Bedrock API キーの保護: 実装と管理のベストプラクティス 」 AWS は Amazon Bedrock の認証に AWS STS の一時的な認証情報を優先し、使えない場合のみ API キーを検討するよう推奨しています。API キーには短期キーと長期キーの 2 種類があります。短期キーの有効期間は IAM セッションと 12 時間の短い方で、長期キーは 1 日から無期限まで設定できます。防御では bedrock:BearerTokenType など 4 つの条件キーを SCP で使う方法を示します。検知では CloudTrail の callWithBearerToken フラグを拾う Amazon EventBridge ルール、対応では AWS CLI でキーを無効化・削除する手順を扱います。 ブログ記事「 Amazon Bedrock における最小権限アクセスの実装 」 Amazon Bedrock を使うアプリケーションに最小権限の原則を適用する方法を、モデルの選択・適応・テスト・運用の 4 つのフェーズに沿って解説しています。Anthropic と Amazon のモデルだけを許可リスト方式で使えるようにする SCP や、AWS PrivateLink の VPC エンドポイントポリシーで呼び出せるモデルを限定する例を示します。条件キー bedrock:GuardrailIdentifier で特定のガードレールの利用を強制する方法も扱います。運用フェーズでは、モデル呼び出しログの閲覧権限を 3 つの IAM ロールに分ける構成を提案しています。ポリシー例をそのまま出発点にできるため、生成 AI 基盤の権限設計を任された方の時間を節約できます。 ブログ記事「 AWS のサービスで構築する生成 AI アプリケーションのセキュアなネットワークアーキテクチャ 」 「生成 AI をセキュアにする」シリーズのパート 5 として、生成 AI アプリケーションを外部脅威から守るネットワーク設計を多層防御の観点で解説しています。DDoS 攻撃、ウェブリクエストフラッド、SQL インジェクションなどの脅威を整理したうえで、AWS PrivateLink による Amazon Bedrock API へのプライベート接続、AWS WAF の Bot Control と Anti-DDoS マネージドルールグループ、AWS Shield、AWS Network Firewall を順に紹介します。最後に Amazon CloudFront を入口にしたリファレンスアーキテクチャをまとめています。一般公開する前に、ネットワーク面の防御に抜けがないか確認するチェックリストとして使えます。 ブログ記事「 スピードと安全性の両立: AI コーディングエージェントのためのコントロールフレームワーク 」 AI コーディングエージェントは、組織のリスクを理解しないままマシンの速度で動きます。記事はそのためのアプリケーションセキュリティ (AppSec) のフレームワークとして、プロンプトインジェクションやスコープクリープなど 7 つのリスクを整理し、対策を 2 つの柱に分けます。作成時 (author-time) はステアリングドキュメント、レビュー済みの仕様、MCP (Model Context Protocol) のツールアクセス制御で IDE 内の生成を方向付けます。ビルド時 (build-time) はシークレット検出・SAST・SCA・IaC のスキャンと品質ゲート、人間によるレビューで本番到達前に検証します。エージェント導入とセキュリティチームの承認を両立したい開発組織が、どこにガードレールを置くかを決める指針になります。 ブログ記事「 Amazon Bedrock と LiteLLM による OpenAI ChatGPT Codex の予算・レート制限管理 」 OpenAI Codex のモデル推論を、お客様の AWS アカウント内に置いた LiteLLM ゲートウェイ経由で Amazon Bedrock 上の OpenAI モデルにルーティングする構成を解説しています。LiteLLM はオープンソースの AI ゲートウェイです。Amazon ECS (AWS Fargate) にデプロイし、モデルエイリアス、ユーザーやチーム単位のスコープ付きキー、予算とレート制限を一元管理します。ローカルのツール実行は引き続き開発者側の Codex が担います。代替経路として AWS IAM Identity Center による直接アクセスと Portkey も比較しています。コーディングエージェントの利用が個人の試行から全社導入に広がる段階で、誰がどれだけ使ったかを把握したい方に向いています。 ブログ記事「 AWS DevOps Agent で調査コストを事前に制御する 」 AWS DevOps Agent の調査で、最初の課金対象クエリを実行する前にコストを見積もって予算と照合する、オープンソースのスキル「Investigation Cost Guardrail」を紹介しています。動詞ベースのルールや有料操作レジストリを含む 4 層で操作を分類し、AWS Price List API から対象リージョンの最新料金を取得します。判定は Proceed・Warn・Halt の 3 種類です。たとえば 9 月全体のログの相関分析は 2,673 GB のスキャンで $13.37 と見積もられ、デフォルト予算の $10.00 を超えるため停止します。GitHub の aws/tools-for-devops-agent から導入できます。エージェントに調査を任せたいが、ログのスキャン料金が読めないという運用チームの不安に直接応える内容です。 ブログ記事「 AWS Physical AI Toolchain を発表 」 Physical AI Toolchain on AWS は、ロボットなどのフィジカル AI のポリシーを AWS 上でトレーニング・デプロイするための、リファレンスアーキテクチャと Infrastructure as Code を 1 つにまとめた一般公開のコレクションです。NVIDIA の GR00T (VLA モデルのトレーニング)、Isaac Sim (シミュレーション)、Isaac Lab (強化学習)、Cosmos (合成データ生成)、OSMO (オーケストレーション) を AWS のマネージドサービス上で 1 つのパイプラインとして動かします。GitHub の aws-samples リポジトリでワークショップもあります。工程間の引き継ぎに時間を取られているロボティクスチームが、基盤構築を省いてモデル改善に集中できます。 ブログ記事「 AWS で AI を活用したスタジオを構築するためのガイダンス 」 スタジオが生成 AI をコンテンツ制作に組み込むためのプラットフォームアーキテクチャ「AI-Powered Studio」を紹介しています。設計の軸は Consistency (一貫性)、Context (コンテキスト)、Control (コントロール)、Compliance (コンプライアンス)、Cost (コスト) の 5 つの C です。中核はサーバーレスのオーケストレーションで、AWS AppConfig の設定変更だけでモデルを切り替えられます。来歴 (プロベナンス) は生成時に DynamoDB へ自動記録されます。モデルが数か月で入れ替わる中、特定ツールに依存せずに来歴と権利の説明責任を果たしたいメディア企業にとって、設計の土台になります。 ブログ記事「 Kiro IDE と CLI にメモリ機能が登場 」 Kiro IDE と Kiro CLI にメモリ機能が導入されました。Kiro は、好みの作業の進め方、リポジトリ固有のコマンドや規約、受けた訂正、デバッグで得た知見、すでに除外したアプローチを覚えます。再び関係する場面で、そのコンテキストを引き継ぎます。メモリはマシンのローカルに保存され、そのマシン上の IDE と CLI で共有されます。IDE では Memories ビューで一覧・検索や削除ができ、CLI では /memories で確認やアクセス設定を行います。既定ではオフで、Kiro IDE 1.4.0 以降と Kiro CLI 2.29.0 以降のローカル V3 セッションで利用できます。セッションごとに同じ前提や訂正を繰り返している方は、その手間を減らせます。 ブログ記事「 Kiro はどのように自らを修正し、その修正の正しさをどう担保しているか 」 Kiro のファイル読み取り・検索ツールの説明に、ハーネスの動作について事実と異なる一文がありました。この一文は数百のセッションで 61,742 回モデルに届いていました。Kiro チームは実行結果から改善を提案する社内システム kiro-trace を構築しました。変更の提案はモデルが行いますが、受け入れるか退けるかは決定論的なコードが 3 段階のゲートで判定し、最後に人がレビューしてマージします。最初の 1 週間で 7 件の修正がマージされ、会話の要約 (コンパクション) の保持率は 0.82 から 0.92 に改善しました。自社のエージェントを自己改善させたい開発者にとって、「提案する者と判定する者を分ける」という教訓がそのまま使えます。 サービスアップデート Grok 4.7 が AWS GovCloud (US) の Amazon Bedrock で利用可能に AWS GovCloud (US) の Amazon Bedrock で、SpaceXAI の Grok 4.7 が利用できるようになりました。コーディング、エージェント型タスク、ナレッジワーク向けのフロンティアモデルです。Grok 4.6 より複数文書を混在させた入力の扱いとリポジトリ規模のコーディングの安定性が向上しています。GovCloud の要件がある米国公共部門のワークロードでも、最新のフロンティアモデルを選択肢に加えられます。 Amazon CloudWatch Omni が追加の AWS リージョンで利用可能に AI を活用したオブザーバビリティ体験である Amazon CloudWatch Omni が、新たに 8 つの AWS リージョンで利用できるようになりました。追加されたのは、東京リージョンを含む、カナダ (中部)、アジアパシフィック (ムンバイ)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (ロンドン)、南米 (サンパウロ) です。CloudWatch Omni では、アプリケーションとエージェントの観測やトラブルシューティングを 1 か所で行えます。チャット操作から AWS DevOps Agent による根本原因の特定まで進められます。国内にデータを置いたまま、AI による障害調査を運用に取り入れられるようになります。 AWS が TorchNeuron を発表: AWS Trainium 向けのネイティブ PyTorch サポート (パブリックベータ) AWS Trainium 向けのオープンソースのネイティブ PyTorch バックエンド、TorchNeuron のパブリックベータが公開されました。PyTorch コードを .to('neuron') に切り替えるだけで Trainium 上で動かせます。eager 実行、torch.compile、標準の PyTorch API との互換性は維持されます。Neuron Kernel Interface (NKI) と統合され、カスタムオペレーターも実装できます。Amazon EC2 の Trainium2 と Trainium3 インスタンスで使えます。既存の PyTorch コードを大きく書き換えずに Trainium のコスト効率を試せる点が、移行を検討するチームにとっての価値です。 Amazon Bedrock Advanced Prompt Optimization がプロンプト短縮に対応 Amazon Bedrock Advanced Prompt Optimization に、評価スコアを維持または改善しながらプロンプトの長さを削減するオプション設定、プロンプト短縮が追加されました。これまでは最適化後のプロンプトが元より長くなることが多く、入力トークンのコストや最初のトークンが返るまでの時間を増やす要因になっていました。有効にすると、元より短く、かつ評価で同等以上のスコアを得た場合にのみ最適化後のプロンプトが返されます。Advanced Prompt Optimization が利用できるすべての AWS リージョンで使えます。品質を落とさずに推論コストとレイテンシーを下げたい本番アプリケーションで、手作業のプロンプト圧縮を置き換えられます。 Amazon Bedrock Guardrails がコンテキストグラウンディングチェックの Standard ティアに対応 Amazon Bedrock Guardrails のコンテキストグラウンディングチェックに Standard ティアが追加されました。この機能は、モデルの応答が参照ソースに基づき、ユーザーの質問に関連しているかを確認してハルシネーションを検出・フィルタリングします。Standard ティアは推論や会話的な内容を含む応答に対応し、対応言語も広がりました。料金は Classic ティアと同じで、利用にはガードレールプロファイルを使ったクロスリージョン推論が必要です。東京リージョンを含む次の AWS リージョンで利用できます: 米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ミラノ)、欧州 (パリ)、欧州 (スペイン)、欧州 (ストックホルム)、アジアパシフィック (東京)。会話型の RAG アプリケーションでも、同じ料金で根拠のない回答をより確実に抑えられます。 Amazon WorkSpaces が、運用・管理するインフラを減らしつつ、エンタープライズクラウドデスクトップへの AI エージェントの安全なアクセスを簡素化 WorkSpaces for AI agents が、認証とデスクトップ接続をマネージドな MCP (Model Context Protocol) サービスの一部として処理するようになりました。カスタムコードを書かずにエージェントを統制されたクラウドデスクトップに接続でき、MCP に対応するあらゆるクライアントから WorkSpaces を利用できます。手動だったストリーミング URL の生成とローテーションが不要になり、既存の AWS 認証情報を使った OAuth 2.0 で接続のライフサイクルをサービス側が管理します。エージェントのセッションは、人間の従業員と同じネットワーク分離とコンプライアンスの境界内で実行されます。新たに南米 (サンパウロ)、欧州 (ミラノ)、欧州 (スペイン)、アジアパシフィック (マレーシア) でも利用できます。GUI 操作が必要な社内アプリケーションをエージェントに任せたいが、セキュリティ境界は崩したくない企業にとって現実的な選択肢になります。 Polly の Generative エンジンがアップグレード: より自然な音声、14 の新しい音声、2 つの新言語 Amazon Polly の Generative エンジンに新しい基盤モデルが導入され、より自然で正確な音声を低レイテンシーで出力できるようになりました。9 つのロケールにわたる 14 の新しい音声が追加され、ヒンディー語とフィンランド語が Generative エンジンで初めて一般提供されました。ストリーミング API により、LLM ベースの音声エージェントをリアルタイム会話向けに構築できます。新しい Generative 音声は、東京リージョンを含む次の AWS リージョンで利用できます: 米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (フランクフルト)、欧州 (チューリッヒ)、欧州 (ロンドン)、アジアパシフィック (シドニー)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (東京)、カナダ (中部)、AWS GovCloud (米国西部)。音声エージェントの応答品質を上げたい方は、東京リージョンでそのまま試せます。 Amazon Bedrock で Claude モデルの構造化出力が利用可能に Amazon Bedrock が、bedrock-runtime と bedrock-mantle の両エンドポイントで、すべての Anthropic Claude モデルの構造化出力に対応しました。定義したスキーマに従う JSON 応答を受け取れるため、独自のパース処理やリトライロジックは不要です。Claude モデルが利用できるリージョンで使えます。抽出結果の形式崩れに対処するコードを書いて保守してきた方は、その負担から解放されます。 AWS Neuron 2.33 がネイティブ PyTorch サポート、Neuron Observer などの新機能を追加 AWS Neuron 2.33 がリリースされ、AWS Trainium 向けのネイティブ PyTorch バックエンドである TorchNeuron がパブリックベータとして導入されました。PyTorch のモデルを Amazon EC2 Trn2 および Trn3 インスタンス上で eager モードまたは torch.compile で実行できます。あわせてパブリックベータの Neuron Observer が導入され、Trainium の健全性の問題を 1 秒未満で検出し、影響を受けたノードやデバイスを特定します。NKI Library には DeepSeek-V3.2、Qwen3.5、Kimi Delta Attention 向けを含む 25 の実験的カーネルが追加されました。大規模学習でノード障害の特定に時間を取られているチームにとって、Neuron Observer は停止時間の短縮につながります。 Amazon SageMaker AI がサーバーレスモデルカスタマイズジョブでカスタムシーケンス長に対応 Amazon SageMaker AI のサーバーレスモデルカスタマイズジョブで、学習時に使うシーケンス長を設定できるようになりました。これまでは各レシピが固定のシーケンス長で実行されていましたが、モデルと手法の公開上限 (多くのモデルで最大 16K トークン) までの範囲でハイパーパラメータとして指定できます。SFT と DPO では dataset_max_len を、RFT では max_prompt_length と max_response_length を使います。東京リージョンを含む、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (東京)、欧州 (アイルランド) で利用できます。複数ページの文書を学習データにしたいのに切り詰められていた、という課題を解消できます。 Reflection の Beam モデルが Amazon SageMaker JumpStart と AWS Trainium で利用可能に 米国の Reflection が提供する初のオープンウェイトモデル Beam が、Amazon SageMaker JumpStart で利用できるようになりました。推論、コーディング、エージェント型のベンチマークで高い性能を示し、Apache 2.0 ライセンスで公開されています。ファインチューニングや重みの検査・変更を行い、自身の AWS アカウント内で実行できます。AWS Trainium3 向けに最適化され、当初は米国東部 (バージニア北部) と米国東部 (オハイオ) で BF16、FP8、NVFP4 のチェックポイントをデプロイできます。モデルの重みとデータを自社の管理下に置きつつフロンティア級の性能を求める組織にとって、新しい選択肢になります。 AWS Continuum for code vulnerabilities が一般提供開始 AWS Continuum for code vulnerabilities が一般提供を開始しました。コードの脆弱性をマシンスピードで発見、検証、優先順位付けし、修正する機能です。AWS 環境のリソース、アイデンティティ、ネットワーク到達性からコンテキストグラフを構築し、検出結果を隔離されたサンドボックスでテストして悪用可能なものを確認します。修正パッチはプルリクエストとして開発者のワークフローに届きます。利用開始時はユーザーが承認する Learn モードで動作し、信頼が高まれば自律的に動く Enforce モードに切り替えられます。大量のアラートのうち、本当に対処すべきものだけに人手を割きたいセキュリティチームの負荷を下げます。 AgentCore Gateway が Bedrock InvokeModel API とモデルフォールバックに対応 Amazon Bedrock AgentCore Gateway の推論エンドポイントが、Amazon Bedrock の InvokeModel API と InvokeModelWithResponseStream API に対応し、モデルフォールバックルーティングも追加されました。既存の Amazon Bedrock SDK の統合をそのままゲートウェイに向けるだけで、統制された 1 つのエンドポイントから任意のモデルプロバイダーに到達できます。モデルフォールバックでは、プライマリの宛先がスロットリング、容量不足、到達不能の場合に自動で代替のモデルやプロバイダーに振り分け、組み込みのサーキットブレーカーが失敗中の宛先をスキップします。Amazon Bedrock AgentCore Gateway が利用できるすべての AWS リージョン (中国リージョンを除く) で使えます。各クライアントにリトライ処理を書き込まずに、エージェントの可用性を基盤側で確保できます。 Amazon OpenSearch Service が Amazon S3 のログとドキュメント向けのインテリジェントインジェストを発表 Amazon OpenSearch Serverless に、Amazon S3 に保存されたログやドキュメントを OpenSearch Serverless (NextGen) コレクションで検索可能にするフルマネージド機能、インテリジェントインジェストが追加されました。コンソールの数クリック、または 1 回の API 呼び出しで設定でき、JSON 形式のログと、PDF、Word、プレーンテキスト、Markdown 形式の非構造化ファイルに対応します。ドキュメントの解析、画像の説明生成、チャンク化、ベクトル埋め込みの生成、インデックス作成までを自動で行い、料金はアクティブな処理分のみです。東京リージョンを含む AWS リージョンで利用できます。RAG 用のインデックス構築パイプラインを自作・保守してきたチームは、その工程をまるごと置き換えられます。 Amazon SageMaker AI がサーバーレスモデルカスタマイズ向けのトレーニングセッション API を発表 Amazon SageMaker AI のサーバーレスモデルカスタマイズに、トレーニングセッション API が追加されました。GPU インフラを管理することなく、チーム自身がトレーニングループを記述し、カスタム損失関数や新しい RL 報酬信号などを実装できます。 forward_backward() 、 optim_step() 、 sample() といった操作がライブセッションへの API 呼び出しになり、GPU の割り当て、分散実行、障害復旧は SageMaker AI が担います。課金は処理トークン単位です。米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ) で一般提供されています。既成のレシピでは足りない研究寄りのポストトレーニングを、GPU クラスターを持たずに試したいチームに向いています。 Amazon SageMaker AI が Muse Glimmer、Qwen 3.8、Ministral 3 モデルのサーバーレスモデルカスタマイズに対応 Amazon SageMaker AI のサーバーレスモデルカスタマイズが、Muse Glimmer、Qwen3.8 27B、Ministral 3 の 3B、8B、14B モデルに対応しました。教師ありファインチューニング (SFT)、直接選好最適化 (DPO)、強化ファインチューニング (RFT) で適応させられ、LoRA (低ランク適応) とフルファインチューニングのどちらも選べます。東京リージョンを含む、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (東京)、欧州 (アイルランド) で利用できます。小さなモデルを自社データで調整してコストとレイテンシーを下げたい場合に、選べるベースモデルの幅が広がります。 Web Search on Amazon Bedrock がドメインフィルタリングとユーザー位置情報の制御に対応 Web Search on Amazon Bedrock に、ドメインフィルタリングとユーザー位置情報が追加されました。どちらも OpenAI Responses API リクエスト内の web_search ツールで設定します。ドメインフィルタリングでは、最大 100 件の allowed_domains で信頼できるソースに結果を限定したり、最大 100 件の blocked_domains で不要なソースを除外したりできます。ユーザー位置情報では、その地域に関連する結果を返せます。米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、AWS GovCloud (米国西部) で利用できます。公式サイトや指定ソースだけを根拠にした回答が求められる業務用途で、検索結果の出所を統制できます。 Kiro : Claude Haiku 5.5 が利用可能に Kiro で Claude Haiku 5.5 が実験的 (Experimental) サポートとして利用できるようになりました。対象は Pro、Pro+、Pro Max、Power のお客様で、us-east-1 (IAD) と eu-central-1 (FRA) において Kiro IDE、CLI、Crew、Web から使えます。1M トークンのコンテキストウィンドウを持ち、クレジット倍率は 100K トークンまでのリクエストが 0.06x、100K トークンを超えるリクエストは 0.3x です。定型的な変更や大量のファイル処理を低コストでこなしたい場面で、クレジットの節約につながります。 Kiro : Claude Fable 5.1、Claude Sonnet 5.5、GPT-5.6 Terra、GPT-5.6 Luna が一般提供開始 Claude Fable 5.1、Claude Sonnet 5.5、GPT-5.6 Terra、GPT-5.6 Luna が、Kiro の完全なサポート付きで一般提供になりました。GPT-5.6 Sol は引き続き Experimental です。Fable 5.1 は米国東部 (バージニア北部) (us-east-1) の Kiro Enterprise 組織向けに、Sonnet 5.5 は Kiro IDE、CLI、Crew、Web で、GPT-5.6 Terra と Luna は Kiro IDE、CLI、Web で利用できます。Sonnet 5.5、Terra、Luna は米国と EU の地域で Pro、Pro+、Pro Max、Power のお客様が利用できます。Preview と Experimental のラベルが外れ、Kiro Excluded Models の補償 (indemnity) 例外も適用されなくなりました。試験的な扱いが理由でこれらのモデルを本番で使えなかった組織は、補償の面でも採用を検討しやすくなります。 Kiro CLI 2.34.0 : MCP Elicitation、ワークフローの制御、メモリの削除 Kiro CLI 2.34.0 では、ローカルの V3 セッションで MCP ツールが入力を求められるようになりました (MCP Elicitation)。追加情報が必要なときにツールが一時停止してフォームやリンクを表示し、利用者は入力、別ページでの操作、拒否を選べます。ワークフローでは、V3 のプラン承認時に変更案を直接入力するとステップの実行前にプランが更新され、新しい Workflow use 設定で Only when asked、Only for large tasks、As much as possible からワークフローを開始するタイミングを選べます。 /memories でメモリを削除、 /model edit で使わないモデルを非表示にできます。ツールが足りない情報を聞き返せるようになったことで、認証や確認が必要な MCP 連携を途中で諦めずに進められます。 Kiro CLI 2.33.1 : ワークフローは依頼したときだけ開始 Kiro CLI 2.33.1 では、V3 の Workflows の開始方法が変わりました。機能を有効にしただけではワークフローは開始されず、明示的に依頼したときだけ実行されます。修正では、スクリーンリーダー使用時に /tools が各ツールの Source、Status、Description を 1 行ずつラベル付きで表示するようになりました。V2 セッションを V3 で再開する際は、保存済みのツール承認が引き継がれないことと、V3 で承認を維持する方法が案内されます。画像の多い長い V3 セッションがリクエスト上限で失敗する問題なども修正されました。小さな依頼のたびにワークフローが立ち上がって待たされていた方は、通常のチャットの軽快さが戻ります。 Kiro CLI 2.33.0 : ワークスペースの信頼、ワークフロープランのステップツリー、Mermaid サブグラフ Kiro CLI 2.33.0 では、対話型の V3 セッションにワークスペースの信頼 (workspace trust) が追加されました。フォルダで初めて V3 セッションを開始すると、そのフォルダの hooks、エージェント、MCP サーバー、steering、ワークフロー設定を読み込む前に「Trust this workspace?」画面が表示されます。回答はワークスペースルートごとに ~/.kiro/workspace-roots/ に保存されます。V3 セッションではモデルフォールバックの設定が再び可能になり、ワークフローのプラン承認はコンパクトなステップツリーで表示されます。クローンしたリポジトリに含まれる設定が、許可なくエージェントの挙動を変えるリスクを防げます。外部コードを扱う機会の多い方ほど効果があります。 Kiro IDE 1.4.26 : Kiro がワークフローを使うタイミングを選択 Kiro IDE 1.4.26 では、チャットの Workflows パネルに Use workflows の設定が追加され、Only when asked、Only for large tasks、As much as possible から Kiro がワークフローを開始する頻度を選べるようになりました。新しいチャットは Only when asked で始まり、選択は新しいローカルチャットにも記憶されます。あわせて、Kiro CLI でインストールした Powers が Powers パネルの Installed 一覧に表示され続けるようになり、Memory 設定はレベル未選択の場合にデフォルトの Off が適用されます。タスクの大きさに応じて単発のチャットと多段のワークフローを使い分けたい方が、その判断を Kiro に任せる度合いを自分で決められます。 Kiro IDE 1.4.10 : Memory 設定のデフォルトが Off に、ワークフロープランへのフィードバック、Powers の耐障害性向上 Kiro IDE 1.4.10 では、Kiro Agent: Memory 設定のデフォルトが Off に変わりました。Use and learn、Use but don’t learn、Use only のいずれかを選ぶとメモリの使い方を設定でき、すでに選んでいる場合はその選択が維持されます。ワークフローでは、提案されたプランに変更を求めると、承認後のステップが利用者の修正に沿うようになりました。Powers は、MCP サーバーへの接続に失敗してもそのサーバーなしでターンが実行されます。画像の多い会話が拒否されたりコンパクションに失敗したりする問題に対しては、古い画像を省いて要約を再試行するようになりました。スクリーンショットを多く貼り付けて作業するセッションが途中で止まっていた方には、安定性の改善につながります。 Kiro IDE 1.4.0 : チャットセッションをまたぐ Memory Kiro IDE 1.4.0 で Memory が導入されました。リポジトリの規約、修正指示、すでに却下したアプローチといった有用なコンテキストを、セッションをまたいで引き継げます。アクティビティバーの Memories アイコンから Memory ビューを開き、Kiro が記憶している内容を確認でき、メモリへのアクセスや変更はチャットに表示されます。Kiro Agent: Memory 設定では、メモリを変更せずに使うだけの Use only も選べます。Markdown Review の検索改善と、Ubuntu 24.04 以降で .deb パッケージからインストールした Kiro が起動しない問題の修正も含まれます。何を覚えさせるかを自分で管理したい方は、Use only から安全に試し始められます。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近ハーブを育てるのにハマってます。