アマゾン ウェブ サービス ジャパン（以下、AWS ジャパン）は本日、地域経済の自立的な成長を、クラウドや生成AI／AIエージェントなどの最新技術活用支援、デジタル人材育成支援、地域内データ活用支援を通じて包括的に支援する新プログラム「 AWS ジャパン地域創生支援プログラム 」（以下、 LEAP by AWS ジャパン ）を発表しました。地域経済の成長を加速する日本独自のプログラムです。LEAP は “Local Economy Acceleration Program” の頭字語で、”飛躍”を意味する英単語でもあります。 本プログラムは、AWS ジャパンがこれまで複数の部門で個別に進めてきた取り組みを、初めて 4つの支援メニュー として体系化し、1つのプログラムにまとめたものです。8月18日から28日にかけて全国8か所で開催する「 デジタル社会実現ツアー 」でも順次紹介し、全国の地域企業・自治体・教育機関へ展開していきます。 LEAP by AWS ジャパン 4つの支援メニュー 地域企業のAI・クラウド活用を積極支援 ：AIトランスフォーメーション（AX）を加速する地域の企業に対し、AIエージェントの構築から導入・運用定着までを一貫支援。審査を経て条件を満たせば最大5万USドル相当のAWSクレジットを提供します。 地域ITサービス企業の提案力を強化 ：「AWS 地域創生トレーナー」（下記「支援メニュー②」を参照）企業がスキルアップトレーニング（クラウド／AI提案力向上）を提供し、地域に根差したIT企業を育成・認定します。 次世代デジタル人材を育成 ：自治体・教育機関と連携し、成人学生向けに実践的なデジタル／ハンズオントレーニングやアウトプットの場としてビジネスコンテストを提供していく予定です。 地域データ活用を支援 ： AWS Clean Rooms を活用した地域データのコラボレーションや、AIエージェント活用に向けたクラウドへのデータ移行を支援します。 LEAP by AWS ジャパン お申込みフォームは こちら 支援メニュー①：地域企業向け AI・クラウド体験・導入支援 対象：地域企業の方々 地域の企業がAXを加速し生産性を向上することは、地域経済の成長の重要課題です。とりわけAIエージェントの活用は鍵となります。 LEAP by AWS ジャパンでは、地域企業がAIエージェントを「体験」から「本導入」まで一気通貫で進められるよう、次の3つの取り組みで支援します。 AWS クレジット for LEAP： AWSの活用拡大を目指す地域企業を対象に、審査を経た上で条件を満たせば、1社あたり最大5万USドルのAWSクレジット「AWS クレジット for LEAP」 * を提供します。これにより、PoC（概念実証）から本格運用までにかかるコストを資金面で強力にサポートし、初期投資負担を大幅に軽減します。 AIエージェント体験ハンズオン： AWSやパートナーによる、全国でのAIエージェント体験イベントやハンズオンセッションを提供します。お客様の属性を問わず、 Amazon Quick や Kiro 等のAIエージェントに実際に触れる体験機会を創出します。 PoC／本番導入支援： AIエージェントの構築から導入・運用定着までを支援します。「体験 → 検証 → 本導入」のステップを一気通貫でサポートし、地域の中小企業がAI時代の恩恵をいち早く享受できる環境を整備します。 * 適用条件詳細はお問合せください。担当よりお伝えいたします。クレジット付与に関しては こちらの規定 が適用されます。 LEAP by AWS ジャパン お申込みフォームは こちら 支援メニュー②：地域ITサービス企業向け AI・クラウドスキル強化支援 対象：地域ITサービス企業 中小企業庁によれば、企業の79.7％が東京・大阪以外に存在する一方 *1 、情報通信業の従業者の約50%が東京都に、約65%が関東圏 *2 に集中しています。つまり地域経済では、クラウドやAIの導入を支援できるITサービス企業や、AI・クラウドスキルが不足しています。 この状況を受け、LEAP by AWS ジャパンでは、AI／AIエージェントの利活用に向けた第一歩として、クラウド移行支援を推し進められる地域ITサービス企業を育成するトレーニングを強化します。 AWS 地域創生トレーナー プログラムローンチ時点では、トレーニングや中堅・中小企業領域に専門性がある3社を、「 AWS 地域創生トレーナー 」として連携し、地域ITサービス企業へクラウドスキルアップ支援・営業力向上研修・技術支援を提供します（提供メニューは各社異なりますので、各社のページをご確認ください）。 ダイワボウ情報システム株式会社 支援プランはこちら クラスメソッド株式会社 支援プランはこちら NHN テコラス株式会社 支援プランはこちら AWS 地域創生サポーターの認定 あわせてAWSは、各県で地場企業のクラウド／AI案件の導入・運用を支える、地域に根差したITサービス企業様を「 AWS 地域創生サポーター 」として認定・拡大していきます。トレーナーによる育成を経た地域ITサービス企業に加え、各地域で既にクラウドビジネスを展開しているAWSパートナー様にもご参画いただけます。 認定にあたっては、以下を要件とします。 AWS Partner Tier が「Select」以上であること 各県に拠点を有すること 以下の地域創生サポーター登録フォームにて申請し、AWSより承認を得ること AWSは地方自治体や地銀との関係の構築を通じて、AIエージェントやクラウドの導入を意図している地場企業と「AWS 地域創生サポーター」とのビジネスマッチングによる支援を目指します。 AWS地域創生サポーター登録は こちら *1: 中小企業庁「中小企業・小規模事業者の数」（2021年6月時点） *2: 総務省「経済センサス 令和3年」 支援メニュー③：教育機関及び所属の学生様向け デジタルスキルトレーニング 対象：教育機関・自治体 地域経済の成長には、企業やITサービス企業のDX/AXを担うデジタル人材の育成が欠かせません。LEAP by AWS ジャパンは、地域の教育機関と連携し、AIエージェントやクラウドの構築・企画ができるデジタル人材向けのトレーニングを提供します。以下のプログラムをご用意しています。 ハンズオントレーニング／ビジネスコンテスト： AWSのソリューションアーキテクトやパートナーによる、AI統合開発環境「 Kiro 」を活用した実践的な開発ハンズオントレーニングを提供します。あわせて、地域課題解決をテーマとしたAIを活用したビジネスコンテストを自治体・教育機関と協力して開催する予定です。ハンズオントレーニングおよびビジネスコンテストのご提供には、以下記載の開催要件がございます。 AWS Academy： 教育機関向けに無料で提供しているクラウドコンピューティングカリキュラムです。詳細は こちら 。 AWS Skill Builder： 900を超える無料オンラインコースを提供しており、自己学習で活用頂けます。詳細は こちら 。 JAWS-UGコミュニティ： 全国60以上の支部を持つ JAWS-UGコミュニティ も、継続的な学びの場としてご参加いただけます。 お申込みの際は、ご関心のあるプログラムをフォームでお選びください。 ハンズオントレーニング／ビジネスコンテストのお申込みにあたっての要件 会場の手配はお申込みの組織側でお願いいたします（自組織会議室など） IT環境のご準備はお申込みの組織側でお願いいたします（PC、WiFiはじめインターネット環境など） 参加組織招集へのご協力 当日運営へのご協力 LEAP by AWS ジャパン お申込みフォームは こちら 支援メニュー④：地域データ活用支援 対象：主に自治体・地方銀行 地域経済におけるデータ活用は、AIエージェントの利活用やフィジカルAIの導入による経済活動の活性化に、大きな可能性を秘めています。地域でのAI活用を加速するには、まず地域のデータ資産を安全に蓄積・連携できる基盤が不可欠です。 LEAP by AWS ジャパンでは、こうしたデータの活用と民主化を、次の3つの取り組みで支援します。 データコラボレーションワークショップ： AWS Clean Rooms を活用し、地域の産学官金の多様なステークホルダーが、互いの自社データを開示することなく安全にデータを掛け合わせることで、組織の垣根を越えた新たな価値創出を支援します。あわせて本ワークショップを各地で開催し、AWSと地域のプレイヤーがデータ連携に踏み出すための場を提供します。ワークショップのご提供には以下記載の開催要件がございます。 データ基盤整備支援： クラウドへのデータ移行や、分散するデータの統合・整備を通じて、活用可能なデータ基盤の構築を支援します。あわせてデータガバナンスとセキュリティの確保にも継続的に取り組みます。この整備は、AWSおよび「AWS 地域創生サポーター」やその他AWSパートナーが継続的に支援します。 AIエージェント活用： 整備・蓄積されたデータのAIエージェントでの活用を支援し、地域経済の活性化を後押しします。 データコラボレーションワークショップお申込みにあたっての要件 お申込みの組織側で会場の手配をしていただく（自組織会議室など） 参加組織招集へのご協力 当日運営へのご協力 LEAP by AWS ジャパン お申込みフォームは こちら 背景 — なぜ、いま地域経済にAIトランスフォーメーション（AX）が必要なのか 地域経済の活性化を実現するためには、地域の企業（中堅・中小企業・スタートアップ企業）およびITサービス企業が自律的に成長し、AXを加速することが求められます。AXの加速は生産性の向上のみならず、新規ビジネスの創出を促し、雇用創出につながるなど、長期的に循環型経済へと導く可能性を持っています。 とりわけ生成AIやAIエージェントの活用は、地域企業の課題解決に有効なソリューションとなります。たとえば、地域の宿泊業が問い合わせ・予約対応をAIエージェントで自動化する、製造業が需要予測・在庫最適化にAIエージェントを用いる、といった形で、限られた人員でも生産性を高めることが可能になります。さらに、蓄積された地域のビジネスデータをステークホルダー間で安全に連携し、AIで掛け合わせることで、データに新しい価値を生み出すこともできます。たとえば地域金融機関の資金繰りデータと中小企業の会計データをAIが分析することで、決算書だけでは見えない成長投資の好機やリスクを早期に捉えることが可能になります。 ここで重要なのは、AIによる省人化と人材育成が「両輪」であることです。AIが定型業務を省人化して人材を解放し、育成された人材がより付加価値の高い業務を担い、そこから生まれる新規ビジネスが新たな雇用を生む。LEAP by AWS ジャパンは、この循環を地域内で完結させ、自律的な成長を目指します。 AWS ジャパンの地域創生ビジョン アマゾン ウェブ サービス ジャパン合同会社 常務執行役員 広域事業統括本部長 原田 洋次は、以下のように述べています。 「AWSは東京リージョン開設から15年、3.8兆円の投資を通じて日本のデジタル基盤を支え、Amazon自身もAIやクラウドで自社のビジネスを成長させてきました。この15年間、お客様と伴走してきたことで培った経験と実績、全国に広がるパートナーネットワークやユーザーコミュニティ、240を超えるサービスがあるからこそ、LEAP by AWS ジャパンをお届けできると確信しています。東京や大阪だけでなく、日本のすべての地域でAIエージェントやクラウドを活用できる環境を整える——それが私たちの目指すテクノロジーの民主化です。皆さまとともに、活力のある地域経済、そして日本を創り上げる支援をしてまいります。」 プログラムへのお申込みについて LEAP by AWS ジャパンの利用を検討する自治体・地方銀行・教育機関・中小企業は、以下のフォームからプログラムにお申込みやお問合せいただけます。（支援メニュー②は支援を希望される該当のトレーナーのサイトより直接お申込み・お問合せください） お申込み内容を確認のうえ、担当より最適なご案内をいたします。   LEAP by AWS ジャパン お申込みフォーム また本プログラムへのお申し込みは、 意思決定者の方からのお申込みをお願いいたします。 お問い合わせはAWS地域創生事務局：aws-jp-sousei@amazon.com にご連絡ください。

本ブログは 2026 年 8 月 12 日に公開された AWS Blog「 How AWS IAM role manager rethinks the starting point for IAM roles 」を翻訳したものです。 Amazon Web Services (AWS) 上で新しいアプリケーションや機能を構築するとき、注力したいのは構築そのものです。しかし、サービスを稼働させる作業は、ほとんどの場合 AWS Identity and Access Management (IAM) から始まります。お客様に代わって動作する多くの AWS サービスには IAM ロールが必要です。IAM ロールとは、サービスが引き受けることで、定義されたアクセス許可のセットの範囲でお客様のリソースにアクセスするためのアイデンティティです。サービスがロールを引き受けられるように信頼ポリシーを作成し、ワークロードに必要なアクセス許可を選択してアタッチします。一般的なパターンに対するロールとポリシーの設定は繰り返し発生する作業であり、本来手作業で行う必要はないはずです。 IAM role manager は、この作業を代行します。Role manager を有効にすると、サポート対象のサービスコンソールで構築を進めるのに合わせて AWS が IAM ロールを作成・設定するため、背後のロールは AWS に任せて、すぐにサービスを使い始めることができます。必要なリソースを作成すると、role manager が同じフローの中で対応するロールをプロビジョニングしてアタッチします。そのため、まずは構築を進め、ワークロードの成熟に合わせてアクセス許可を絞り込んでいくことができます。 このステップが自動化されることで、開始までの時間は数分になります。 AWS Lambda 関数を作成すると、実行ロールが既に作成・アタッチされた状態でコードの実行を開始でき、ロールを設定するためにコンテキストを切り替える必要はありません。ロールの作成は独立したステップではなく、アプリケーション構築の中に自動的に組み込まれた一部になります。 Role manager が特に役立つのは、サービスを立ち上げたい、概念実証 (PoC) を動かしたい、ロールの設定は開発プロセスの後半まで先送りしたい、といった使い始めの場面です。使い始めるにあたって IAM の事前知識は必要ありません。また、作成されるロールは、自分で作成したロールと同じように表示・編集・削除できる通常の IAM ロールであるため、何が作成されるかを完全にコントロールし続けられます。ロールを絞り込みたくなったときは、 AWS IAM Access Analyzer がロールの使用状況をレビューし、必要なアクセス許可のみにスコープを絞ったポリシーを推奨します。 Role manager を有効にする方法 Role manager には、有効と無効の 2 つの状態があります。アカウントで有効にすると、そのアカウント内でのロール作成を AWS に許可することになります。組織で利用する場合、管理者はサービスコントロールポリシー (SCP) を使用して、メンバーアカウントが role manager を有効化・使用できるかどうかを制御できます。有効にする手順は次のとおりです。 IAM コンソールを開き、 アカウント設定 を選択します。 Role manager のセクションで、 有効化 を選択します。 図 1: Role Manager の有効化 一部の AWS サービスは、ロールを必要とするリソースを作成する際に、従来からロールを自動的に作成します。Role manager はこの動作を変更しません。それらのサービスは引き続き自動的にロールを作成し、既に作成済みのロールもそのまま機能し続けます。Role manager が追加するのは、アカウントレベルの単一のコントロールと、組み込みのフローでは対応できないケース、つまり必要なアクセス許可を AWS が事前に判断できないタスク (お客様自身のコードの実行など) への対応です。そのようなタスクに対して、role manager は後から絞り込めるロールをプロビジョニングします。 例: Amazon EventBridge ルールの作成 まずは一般的なタスクから始めましょう。 Amazon Simple Queue Service (Amazon SQS) キューや Amazon Simple Notification Service (Amazon SNS) トピックなどのターゲットを呼び出す、 Amazon EventBridge のルールです。Role manager がない場合、ここで一旦作業を中断して、EventBridge がターゲットを呼び出せるようにするロールを作成し、ロールの信頼ポリシーを記述し、必要なアクセス許可をアタッチしてから、ルールの作成に戻ることになります。Role manager が有効な場合は、ルールとそのターゲットを定義して 作成 を選択すると、role manager がロールをプロビジョニングし、アタッチまで行います。EventBridge コンソールにはルールが作成されて利用可能な状態で表示され、ロール作成のフローを開く必要は一切ありません。 図 2: 手動のロール設定なしで EventBridge ルールを作成する このロールは AWS マネージドロールテンプレートから作成されます。これは特定のタスクのために AWS が構築・保守する定義で、信頼ポリシーとアクセス許可があらかじめ設計されています。コンソールは新しい IAM API である AcquireRole を呼び出します。AcquireRole は一致するテンプレートを見つけ、そこからロールをプロビジョニングして EventBridge に返します。サービスに応じて、AcquireRole は新しいロールを作成するか、既に条件に合う既存のロールを再利用するため、同じタスク用の重複したロールでアカウントがあふれることはありません。 Role manager は、専用の role manager アクセス許可ではなく、お客様自身の IAM アクセス許可を使用してロールを作成します。新しいロールをプロビジョニングするには、テンプレートが実行するアクションに対するアクセス許可、最低でもロールの作成とアタッチを行うアクセス許可が必要です。 AcquireRole が新規作成ではなく既存のロールを再利用する場合に必要なのは、 iam:GetRole と iam:GetRoleTemplateVersion のみです。これらのアクセス許可のいずれかが不足している場合、コンソールはロールを作成せず、どのアクセス許可が必要かを表示します。 他の AWS サービスを呼び出すコードの実行 すべてのタスクに AWS が事前に定義できるアクセス許可のセットがあるわけではありません。Lambda 関数のように、ロールがお客様自身のコードを実行する場合、そのコードがどのサービスを呼び出すのかを AWS が知る方法はありません。Role manager はこのケースにも対応します。Role manager を有効にして Lambda 関数を作成すると、コードからすぐに使用できる実行ロールがアタッチされ、関数が何を呼び出すかが分かった時点で絞り込むことができます。 コードが必要とするアクセス許可が事前には分からないため、role manager は AWS マネージドポリシーである PowerUserAccess をロールにアタッチします。 PowerUserAccess は AWS サービスへのアクセスを付与するため、関数は必要なサービスを呼び出せます。設計上、IAM、 AWS Organizations 、アカウント設定を管理するアクセス許可は付与されません。また、テンプレートは Lambda サービスのみを信頼するようにロールを設定します。 図 3: 手動のロール設定なしで AWS Lambda 関数を作成する Role manager が実行ロールをアタッチし、関数は実行可能な状態になります。図 4 は、関数の 設定 タブにある実行ロールパネルに、role manager がアタッチしたロールが表示されている様子です。 図 4: Role manager が AWS Lambda 関数にロールを自動的に提供する IAM コンソールでロールを開いて、そのアクセス許可を確認できます。図 5 は、 PowerUserAccess ポリシーがアタッチされたロールの 許可 タブです。 図 5: AWS Lambda 関数向けに role manager が提供したロールのアクセス許可 Role manager が作成するものに対する完全な可視性は維持されます。作成されるすべてのロールには、元になったロールテンプレートが記録され、 GetRole と ListRoles の両方がそのテンプレートへの参照を返します。アカウント内の任意のロールを調べて、どれが role manager によって作成されたかを判別できます。ロールの信頼ポリシーとアクセス許可は、自分で作成したロールと同じ方法で確認でき、 AWS CloudTrail には各ロールの作成が記録されます。 ワークロードの成熟に合わせたロールの絞り込み ワークロードが成熟してきたら、最小権限の原則に従うように、role manager が作成したロールを絞り込みます。準備ができたタイミングで role manager を無効にすると、IAM Access Analyzer の未使用アクセス分析を 90 日間、追加料金なしで利用できます。Access Analyzer は各ロールの使用状況を分析し、そのロールが必要とするアクセス許可のみを残したポリシーを推奨するので、それを適用できます。最も重要なワークロードにアタッチされたロールから始めて、順に対象を広げていきましょう。 Role manager を無効にしても、既に実行中のものが中断されることはありません。リソースは現在のロールをそのまま保持し、それらのロールは変更しない限りアカウントに残ります。それ以降の新しいロールは、以前と同じように自分で作成することになります。アカウント全体ではなく単一のロールだけを絞り込みたい場合は、そのロールを編集すると role manager の管理から外れ、変更内容が保持された標準のカスタマー管理ロールになります。サンドボックスや開発用のアカウントでは、role manager を有効にしたままにしておくと時間を節約できます。本番ワークロードについては、本番稼働の前に role manager を無効にし、作成されたロールを最小権限に絞り込んでください。 まとめ Role manager は IAM ロールのセットアップを自動化するため、最初から構築そのものに集中できます。有効にすると、構築を進めるのに合わせて、リソースに必要な IAM ロールを AWS が作成・アタッチするため、IAM の事前知識がなくても数分で使い始められます。作成されるのは完全にコントロール可能な IAM ロールであるため、これまでと同じ可視性を保ちながら、既に使い慣れたツールをそのまま使い続けられます。構築中は role manager を有効にしておき、ワークロードの成熟に合わせて、作成されたロールを絞り込んでいきましょう。 使い始めるには、IAM コンソールで role manager を有効にし、サポート対象のサービスでリソースを作成してください。詳細については、IAM ユーザーガイドの「 IAM ロールの作成 」およびサポート対象サービスの一覧を参照してください。 Zach Jiang Zach は AWS のシニアテクニカルプロダクトマネージャーで、AWS Identity プロダクトを専門としています。お客様にとってアイデンティティが AWS 上での構築の「簡単な部分」になることに注力しています。テクノロジー以外では、旅行や、新しい文化・料理の探求を楽しんでいます。 David Sing David は AWS のプリンシパルプロダクトマネージャーで、AWS IAM を専門としています。ビルダーと AI エージェントのための IAM の簡素化、AI エージェントへの安全な認証情報の発行、エージェントのアクセスを統制する認可ポリシーに注力しています。テクノロジー以外では、経済と市場、釣り、家族と屋外で過ごす時間を楽しんでいます。 Punit Deotale Punit は AWS IAM チームのソフトウェア開発マネージャーです。お客様が AWS サービスのワークフロー内で直接 IAM ロールを作成・管理しやすくする取り組みをリードしており、作業の流れを離れることなく適切なアクセス許可を設定できるようにしています。AWS 全体でアクセス許可設定にともなう摩擦を減らしながら、お客様が最小権限を維持できるよう支援することに注力しています。仕事以外では、読書、サイドプロジェクトの開発、アウトドアを楽しんでいます。 本ブログは Solutions Architect の松井 僚太郎が翻訳しました。

こんにちは。アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクトの辻林です。2026 年 7 月 29 日に、大阪オフィスにて「AWS Business Innovation Series – West Japan」の第 3 回を開催いたしました。本シリーズは、西日本のお客様のデジタル変革を加速することを目的に、生成 AI を活用した実践的なプログラムを約 3 ヶ月に 1 回のペースでお届けしているものです。ご参加いただいた皆様に、改めて御礼申し上げます。 本ブログでは、イベントの背景や当日の様子、参加者の皆様からいただいた声をお届けいたします。 はじめに 本シリーズは 2025 年に関西を中心に開催したワークショップの高い満足度を受けて、2026 年は業界を問わず幅広い企業の皆様にご参加いただける形で継続しています。今回がその第 3 回です。 第 3 回のテーマは、第 2 回に続いて Amazon Quick です。ただし切り口を変えました。第 2 回はメール・ファイル・社内システムといった多様なデータソースへの接続と、チャットエージェントの構築が主題でした。今回はもう一つの入口、つまり BI とダッシュボードを起点に据えています。 データを可視化するところまでは、多くの企業がすでに到達しています。難しいのはその先です。ダッシュボードを前にしても「で、次に何をすればいいのか」が決まらない。決まっても、社内を動かす提案の形にならない。今回のプログラムは、この「見えている」と「動ける」の間にある溝を、半日で越えていただくことを狙いました。データを見渡し、AI と対話して深掘りし、外部の事例を集めて、最後にアクションプランと提案資料に落とし込む。そこまでを一気に体験する構成です。 過去開催分についてはこちらをご覧ください。 第 1 回：お試しから卒業！Kiro の仕様駆動開発を本格活用（2026/3/17） 第 2 回：データから業務アクション、展開まで繋げる Amazon Quick ワークショップ（2026/5/29） イベント概要 項目 内容 テーマ Amazon Quick ではじめるデータドリブン実践ワークショップ 日時 2026 年 7 月 29 日（水）13:00〜18:00 場所 アマゾン ウェブ サービス ジャパン 大阪オフィス（中之島三井ビルディング 26F） 参加者 10 社 25 名 満足度 4.13 / 5 タイムテーブル 時間 内容 13:00 – 13:10 オープニング 13:10 – 13:30 Amazon Quick 座学 〜 最新のアップデートをお届け 13:30 – 14:50 Amazon Quick ハンズオン 〜 データドリブンな意思決定体験ハンズオン 14:50 – 15:00 休憩 15:00 – 17:35 Amazon Quick ハッカソン 〜 Quick ではじめるデータドリブン実践ハッカソン 17:35 – 17:50 LT：数字は正しい。でも提案が通らない理由 17:50 – 18:00 クロージング 当日の様子 Amazon Quick 座学 〜 最新のアップデートをお届け 発表資料： Amazon Quick 座学 〜 最新のアップデートをお届け 最初のセッションは、ソリューションアーキテクトの大内より、Amazon Quick の全体像と最新アップデートをご紹介しました。 出発点は「なぜデータ分析をするのか」という問いかけから、勘や思い込みではなくデータに裏付けされた事実で判断する、施策の効果を検証する、次の一手を決めるためにまず現状を把握する — こうした目的のために BI があります。 そしていま多くの BI ツールで起きている「後付け AI」の限界について説明しました。既存の BI 基盤の上に AI 機能を足していくアプローチは、たしかにアナリストの作業を効率化します。しかしその AI が動く土俵は、あくまで BI のパラダイムの中 — データベースやデータウェアハウスといった構造化データに最適化された世界です。ドキュメント、メール、顧客フィードバック、市場調査といった非構造化データは、依然として届きにくいままです。結果として、従来の BI が扱ってきたデータの範囲でしか AI を活用できず、AI 起点の新たなサイロが生まれてしまいます。 この課題に対する答えが、AI を中心に据えた統合プラットフォームという設計です。2025 年 10 月、Amazon QuickSight は Amazon Quick（旧称 Amazon Quick Suite）としてリブランディングされ、これまでの QuickSight は Quick を構成する一機能（Quick Sight）という位置づけになりました。Quick は次の 5 つを軸に構成されています。 BI — 可視化・分析ツールでデータを探索し、インサイトを明らかにするチャートやグラフを作成する スペース — ファイルやデータなど特定の情報を集積し、チームで共有する場をつくる チャットエージェント — データを分析・計画・操作してタスク完了を支援する AI エージェントを構築する フロー — 目標を迅速かつ予測可能に達成するワークフローを作成・共有する リサーチ — 企業内外のデータソースを横断した包括的な分析で、複雑なインサイトや関係性を発見する BI についてはGenerate Analysis による自然言語からのダッシュボード生成、ダッシュボードの内容を理解した状態で質問できるダッシュボード Q&A、SQL を書かずに自然言語で分析クエリを実行できるデータセット Q&A（Text-to-SQL）、そしてダッシュボードを離れることなくチケット作成や通知を実行できるアクション機能をご紹介しました。数日かかっていたダッシュボード構築を数分に短縮できること、そして普段ダッシュボードを見慣れていない方でも自然言語で問いを立てられること — つまりデータの民主化が、この座学の中心的なメッセージでした。 最後に活用イメージとして、路線ごとの遅延傾向をその場で分析して会議中の問い合わせに答える例、AWS 利用料の上位項目を探索してベストプラクティスを調べ、Jira にタスク化して Slack に通知する例などを共有し、後半のハンズオンへ繋ぎました。 Amazon Quick ハンズオン 〜 データドリブンな意思決定体験ハンズオン 続いてソリューションアーキテクトの伊藤より、実際に手を動かすハンズオンです。このハンズオンではダッシュボード × AI × 追加情報の組み合わせでデータの理解を深め、データドリブンな意思決定を体験します。 最初にデータ活用を 4 つの段階で捉えるフレームで示しました。 探せる（Search） — 最低限必要な情報から始める起点 見渡せる（Visibility） — 何がどこにあるかを広げ、関連情報を含む広い範囲が見える わかる（Insight） — 何が起きているか、なぜかを深掘りし、深い考察ができる 動ける（Action） — 伝える / 決める / 作る / 記録する。データで判断し、次の一手を打てる 多くの現場は「探せる」「見渡せる」で止まりがちです。今回のハンズオンは、ダッシュボード × AI × 意思決定のための追加情報の組み合わせによって「動ける」まで到達させることを体験することに目標に置きました。 ハンズオンの流れは次の通りです。サンプルデータから自然言語でダッシュボードを生成する。（見渡せる）ダッシュボードのデータを自然言語で深掘りする。（わかる）リサーチ機能で業界事例やベストプラクティスといった外部データを集め、そこで得た事実と外部情報を合わせて、アクション・改善提案を検討、提案書の作成まで進む。（動ける） 「見渡せる → わかる → 動ける」を、Amazon Quick の中で一続きの操作として体験できる構成です。ここで基本の型を身につけたうえで、後半のハッカソンに臨みます。 Amazon Quick ハッカソン 〜 Quick ではじめるデータドリブン実践 続いてハッカソンでは題材として、あらかじめ用意したユースケースカタログから自業界・業務に近いユースケースを選んでいただきました。ハンズオンで型を覚えたうえで、今度は自分の業務に引き寄せて進める。ここが難所であり、同時に面白さでもあります。用意されたサンプルデータを自社の実態に近づけて調整し、自然言語で要件を伝えダッシュボードを生成し、必要な情報を考え、リサーチで外部の事例やプラクティスを集め、生成されたダッシュボードを起点にAI と対話して深掘りし、収集したリサーチ情報も加えて、アクションプランと提案資料まで仕上げることにチャレンジ頂きました。 終盤は成果をグループ内・全体共有をする場を設けました。選んだテーマとカスタマイズしたポイント、ダッシュボードやリサーチから得た発見とアクションプランを共有します。同じテーマを選んだ方同士では、出発点が同じでも自社の事情を反映させた結果が違ってくる — その差分がそのまま学びになります。 需要予測に踏み込んだ方、経理部門の課題を題材にした方など、業界も切り口も多彩な発表が並びました。 LT：数字は正しい。でも提案が通らない理由 〜 BI が知らない、現場の秘密 発表資料： 数字は正しい。でも提案が通らない理由 — BI が知らない、現場の秘密 最後に 、ソリューションアーキテクトの多田より「数字は正しい。でも提案が通らない理由」というタイトルでLTセッションを行いました。 データを分析したAIからこんな提案が返ってきました。「スーパーのお弁当コーナー、廃棄が多いので仕入れを減らしましょう」 — コスト削減の観点では正しそうですが、実際のスーパーは仕入れを減らしませんでした。なぜなら品揃えの豊富さそのものが集客装置だから。廃棄はその戦略のコストであり、数字だけ見れば「無駄」に見えるものが、実は意図的な投資だったりします。 このように提案が通らない理由は、こうしたビジネスコンテキストがデータに落ちていないことにあります。同じ「未使用の SaaS ライセンスが 63 件」というデータでも、コンテキストを持たない AI は全件の解約を勧めます。一方コンテキストを持つ AI は例えば「1 件は育休中のため未ログインで、9 月に復帰予定。今解約すると違約金が発生するため継続を推奨」と、例外まで教えてくれます。ただ、コンテキストは毎日現場で生まれるものです。都度拾い上げて反映するのは現実的ではありません。 そこで Amazon Quick です。チャット機能とMCP統合を通じて、現場の担当者が自分でビジネスコンテキストを記録できる。現場が主役のまま知識が積み上がっていく。デモでは 記録したコンテキストを踏まえてAIの回答が変わる様子を実際にご覧いただきました。 「数字 + 現場のコンテキスト = 同じ的外れを繰り返さない AI」。ハンズオンとハッカソンでデータと向き合った直後だったこともあり、多くの方に印象的なセッションでした。 参加者の声 イベント後のアンケートから、いくつかの声をご紹介します。 「Amazon Quick が 2 回目だったのでより理解が深まり、さまざまな使い方を学べたので良かったです。毎回テーマが違ってももちろん学びになりますが、複数回触ることで身についた実感がありました。」 「テストデータも準備していただいて、ハッカソンの時間に注力できて、いい体験ができたと感じました。この形式で Quick を社内に紹介するのも良いのかなと思いました。」 学びを今後の業務に活用できそうかという問いには、回答者全員から「活用できそう」との回答が寄せられました。「今回使いきれなかった機能もぜひ学びたい」という声もあり、次回以降のテーマ設計に活かしてまいります。 まとめ 第 3 回「AWS Business Innovation Series – West Japan」では、BI の側面からデータドリブンな意思決定を支援するためのAmazon Quick 活用プログラムをお届けしました。座学で「後付け AI」の限界と AI 中心のプラットフォームという設計思想を押さえ、ハンズオンで型を身につけ、ハッカソンで自社のユースケースでデータドリブンなアクション設計にチャレンジしました。参加者の皆様が、ご自身の業界のデータと格闘しながら提案の形まで作り上げていく姿は、印象的でした。 ご興味のある方は、担当のアカウントチームまでお気軽にお問い合わせください。皆様のご参加をお待ちしております。 本ブログは、ソリューションアーキテクトの辻林 侑が執筆いたしました。

本記事は、2026 年 8 月 12 日に Massimo Re Ferre が公開した「 Which Kiro app should I pick? 」を翻訳したものです。 Kiro はもう、単一のプロダクトを指す名前ではなくなりました。2025 年 7 月、Kiro を AI IDE としてローンチしました。それ以来、Kiro は IDE という枠にとどまらなくなりました。今の Kiro はソフトウェアエンジニアリングエージェントであり、 IDE 、 CLI 、 Web アプリ 、 モバイルアプリ 、そして Kiro Crew として利用できます。最近 Kiro を少しでも触っていた方なら、おそらく口にした（あるいは口にしたかった）問いがあるはずです。拍子抜けするほど単純な問いです。「結局どれを選べばいいの？」 正直に答えるなら「場合によります」。ですが、もう少しお付き合いください。この逃げのような答えの裏には、れっきとした判断の枠組みがあります。それが分かれば、選ぶのはずっと楽になります。しかも、そもそも問いの立て方が少しずれていたと気づくはずです。問うべきなのは「どれを選ぶか」ではありません。ほとんどの場合、「この用途ならどれを選ぶか」です。 本題に入る前に、この問いの前提を変えた最近の変化を押さえておきます。 1 つのプロダクト、複数の玄関口 内部的には、Kiro は単一のエージェントハーネスに収束しつつあります。Kiro は、あらゆるサーフェスの裏側で動く 1 つのエージェントになりました。そのハーネスこそがプロダクトです。あらゆる機能が集まる、唯一の正式な置き場所です。実際に触れるもの、たとえば IDE や CLI、Web アプリはいずれもアプリであり、そのプロダクトを利用するための手段です。ハーネスとアプリは意図的に切り離されています。ハーネスは Kiro に何ができるかを定め、アプリはそれをどう体験するかを定めます。 ずっとこんなに整っていたわけではありません。今年の初めまでは、各アプリがそれぞれ独自のエージェントを抱えていました。IDE 版は TypeScript、CLI 版は Rust、Web 版は Python で書かれていました。これらは 3 つの独立した頭脳でした。セッションの保存方式はそれぞれ異なり、権限の表し方にも互換性がなく、新しい機能を追加するには毎回 3 通り実装しなければなりませんでした。その後、これらは単一のエージェントハーネスに統合されました。このハーネスはコードのすぐ隣で独立したプロセスとして動作し、明確に定義されたプロトコル（ACP、 Agent Client Protocol ）を介して各アプリと通信します。頭脳は 1 つ、顔はいくつも。メリットは 3 つあります。1 つめは、ハーネスに追加されたコア機能がすべてのサーフェスで一斉に使えるようになることです。2 つめは、どのアプリを使っても振る舞いが一貫することです。そして 3 つめは、ここがおもしろいところですが、ラップトップで始めたセッションをクラウドで動かし続け、スマートフォンから確認できることです。最初から最後まで同じエージェントが動いているからです。統合後も、個々のアプリがそのサーフェスでしか意味を持たない機能を独自に増やしていくことはできます。ただし、中核となる体験はどこへ移っても変わらず付いてきます。 そして、引き継がれるのはエージェントの機能だけではありません。手元の設定もそのまま付いてきます。スキル、ステアリングファイル、カスタムエージェント、作り込んだ環境設定。いずれも個々のアプリの内側ではなくハーネス側に設定するものです。そのため、使うアプリを変えても環境をゼロから作り直す必要はありません。現時点では特定のアプリの組み合わせに限られますが、目指しているのはどの組み合わせでも成り立つ状態です。どこで作業していても、自分の Kiro が付いてくる形にしたいと考えています。 この統合に至った詳しい経緯と、そこで下した判断（なぜ独立したプロセスにしたのか、なぜプロトコルとして ACP を選んだのか、その過程でどんなもつれを解く必要があったのか）は、Kiro エンジニアリングチームが One agent, every surface にまとめています。少し回り道になりますが、読む価値は十分あります。 これはアーキテクチャの細部の話に聞こえるかもしれませんが、「どのアプリを選ぶか」という問いにまともな答えが出せるのは、まさにこの構造のおかげです。すべてのアプリが同じエンジンを土台にしているので、どれを選ぶかは、外したら困る賭けではありません。選んでいるのは、出口のない囲い込まれた環境ではありません。玄関口を選んでいるだけです。 これらのアプリは、どれも他のアプリを置き換えるために作ったものではありません。アプリはそれぞれ異なるニーズに応えます。そして組み合わせることで、どれか 1 つでは届かない範囲までカバーできます。アプリが収束していく先は下方向、つまり共通のエンジンです。横方向、つまり互いに似ていく方向ではありません。アプリ間の重複は、躍起になって排除すべきバグではありません。1 つの土台の上に複数の体験レイヤーが載る構成なら、当然そうなる形です。IDE と Web アプリの両方でエージェントをオーケストレーションできるかもしれません。それでいいのです。ただし両者がそれを担うのは、違う相手に向けて、違う場面で、違う場所で、違う手癖や好みに沿ってなのかもしれません。 こうした判断を支える原則 アプリのラインアップをさらに詳しく見ていく前に、判断を支えている原則を整理しておきましょう。どんなアプリを作るかを決めるときに必ず立ち返るものがいくつかあります。個々のアプリの話に入る前に押さえておくと、この先が読みやすくなります。 まず、Kiro が対象にするのはソフトウェアデリバリーライフサイクルです。ソフトウェアを届ける人たちのためにアプリを作ります。まずは開発者、そしてそのすぐ隣にいる職種も対象です。プロダクトマネージャー、プロジェクトマネージャー、アーキテクト、QA リード、UX デザイナー、システムを動かし続けている運用や DevOps の人たちです。そしてこれは、肩書きだけの話ではありません。いま何をしているかの話でもあります。Slack の通知をさばいたり、メールを片付けたり、予定をやりくりしたりしている開発者も、ソフトウェアを届ける仕事をしていることに変わりはありません。ですから、そうした場面で役に立つアプリも対象に含まれます。逆に、意図して作らないと決めているのが「万人向けの汎用 AI アシスタント」です。ただし、この境界線は意図的に曖昧なままにしてあります。線引きの基準は「この人は開発者か？」でも「この作業はコーディングか？」でもありません。「これはソフトウェアを届けるという行為に役立つか？」です。 次に、ビルダーが今いる場所に合わせます。今の環境やスタイルをそのまま受け入れたうえで、そこから一歩先へ進めるよう後押しする、という考え方です。ファイルや関数の中で暮らす人（コードファースト）もいれば、エージェントをオーケストレーションしてコードは副産物と見なす人（エージェントファースト）もいます。業界の大半は今も前者です。母数が大きいのもそちらで、エンタープライズ導入の多くもそこにあります。エージェントファースト勢は今はまだ少数です。ただ、業界が向かっているのはそちらであり、いちばんはっきりした手応えを得られるのもそこです。ですから、エージェントファーストの世界に向けて作りながら、2 つの世界のあいだにシンプルで文脈に即した合流路を用意します。誰でも自分のペースで行き来できるようにするためです。 これがメンタルモデルです。収束させたアーキテクチャの方針から外れないよう気をつけていますが、変化が猛烈に速い領域でもあるので、好機が見えたときには現実的な判断も取りたいと考えています。さて、アプリそのものの話に移りましょう。「結局どれを選べばいいの？」への本当の答えは、ここから先にあります。 アプリを 1 つずつ見ていく Kiro IDE: 開発の本拠地 IDE は、多くの人が「Kiro」と言うときに指しているものです。Code OSS ベースのエディターで、すでに GA（一般提供）になっており、実際に最も多くのコードが書かれる主要なサーフェスです。企業のチームで一般的な開発スタイルを取っているなら、ここが本拠地になります。 最近の追加でおもしろいのが Agent Focus Mode です。数週間前に、実験的機能として公開しました。IDE では今、2 つのビューを切り替えられます。Code Focus は使い慣れた、手引きのあるコード中心の編集です。Agent Focus は複数のセッションを並行して動かし、状態を管理し、ワークフローが進んでいくのを見守るビューです。どちらもエディターから一歩も出ずに行き来できます。現時点では、この 2 つのビューはまだ緩くつながっている程度です。常に改善して使う人の好みに寄せていきたいので、ぜひ声を聞かせてください。Agent Focus Mode は、先に挙げた 2 つ目の原則を実際に試してもらうための入口だと考えています。使い慣れた環境という安全な足場から、エージェントファーストの世界を覗いてみることができます。ファイルや関数に戻りたくなったら、その時点でいつでも元のビューに戻せます。 Kiro CLI: ターミナルとパイプライン こちらも GA です。 CLI が相手にしているのは、性質がまるで違う 2 つの利用者層です。しかもこの 2 つは、たまたままったく同じインターフェースを欲しがっています。 1 つ目は、ターミナルを好んで使う開発者です。シェルの中で暮らし、フラグとパイプで考え、グラフィカルな画面は助けになるどころか、むしろ邪魔だと感じる人たちです。こうした開発者が CLI セッションを 4〜6 本並べて動かしているのを見かけるのも、珍しくありません。しばしば（あるいは時折）コードを覗きますが、1 行ずつレビューすることはあまりなく、テストを（かなり）頼りにしています。2 つ目は自動化です。こちらには人がまったく介在しません。シェルスクリプトに包まれた Kiro、GitHub や GitLab の CI/CD パイプラインの 1 ステップとして組み込まれた Kiro、誰かのラップトップ上の会話ではなくジョブとして走る Kiro です。この 2 つ目が成り立つのは、エンジンが体験から切り離されているからにほかなりません。UI を一切持たない Kiro です。 CLI からは、予想していなかったことも学びました。誰もが、もっと多機能なアプリへと「卒業」していくわけではないということです。私たちはつい、この話全体を一方向の進歩として語ってしまいます。ビルダーはシンプルなツールから凝ったツールへ移っていく、という語り方です。しかし、フル機能の TUI（Terminal User Interface）を出したあと、lite モードを追加せざるをえなくなりました。かなりの割合のユーザーにとって、TUI はすでに過剰だったからです。あえてゆったり構えていて、機能や画面はもっと少なくてよい、増やさなくてよいと考えている人もいます。サーフェスが増えれば便利になるとは限らない。ここは覚えておきたいところです。 Kiro on the web: クラウドファーストのサーフェス Kiro on the web は、現時点では Preview です。クラウドファーストのサーフェスであり、共同作業をする場、作業を立ち上げる場、そしてバックグラウンドのエージェントを見守る場です。エージェントは、つきっきりで面倒を見なくても裏で黙々と作業を続けます。そして最近は、そちらが本当の役割になりつつあります。つまり、クラウドセッションのコントロールプレーンです。IDE や CLI からクラウドエージェントを直接起動できるようになった今、問いは「どうやって 1 つ起動するか」ではなく、「走り出したエージェント全部をどこで見守り、どこから舵を取るか」に変わりました。Web は、セッションがどこで始まったかを問わず、その「一箇所」に急速になりつつあります。向いているのは、フロンティア開発者やチーム、それに PM やリードといった開発の周辺にいる職種の人たちです。一日中エディターに張りついてはいたくないけれど、ソフトウェアを届ける過程には関わりたい人たちです。 Kiro on the web を見ると、この切り離しが理論ではなく実際のものだとよく分かります。統合ハーネスの上で動いているので、機能が生まれたアプリの中に閉じ込められることがなくなります。その効果が最初にはっきり出たのが Web でした。いちばん分かりやすいのが spec-driven development（仕様駆動開発）です。以前は IDE でしか使えませんでしたが、spec ワークフローがハーネス側に移ったとたん、Web 向けに作り直すこともなく Web に現れました。機能をエンジンの中で一度だけ作っておくことの見返りは、まさにここに出ます。できることが、たまたま最初に使ったエディターに縛られず、サーフェスをまたいで持ち歩けるようになります。 Kiro Mobile: 出先で使う Kiro Kiro Mobile も Preview です。正直なところ、これは議論の余地がありません。あって当たり前のものです。エージェントをクラウドで実行できる開発ツールなら、スマートフォン向けのサーフェスは避けて通れません。いま力を発揮するのは、離れた場所から行う操作です。バックグラウンドエージェントの監視、結果のレビュー、アクションの承認、長く走っているタスクをひと押しして先に進めること。要するに、机に向かっていなくてもできることすべてです。一方、スマートフォンから手元のラップトップのローカルセッションにつなぐほうは、もっと難しく、まだ手つかずです。まずは見通しの立っているところから着手して、残りは進みながら解いていきます。 Kiro Crew: 外側のハーネス Kiro Crew は、永続メモリ、スケジュールジョブ、非同期バックグラウンドエージェントといった機能をまとめたものです。いずれも「エージェントを動かす」の先、「スケジュールに沿って、自分が寝ている間にエージェントのクルーをまるごと動かす」という領域に踏み込んだ機能です。しかも、Kiro としては初のオープンソースアプリです。それでも、GA プロダクトに期待されるのと同じ品質・サポートの水準で扱っています。 では、実際には何をしてくれるのでしょうか。Crew は、自分でハンドルを握るのではなく、任せるための場所です。チケットキューを渡せば、トリアージして振り分けます。複数のリポジトリに散らばったインシデントを割り当てれば、こちらが修正に集中している間に調査を進めます。マイグレーションを走らせれば、会議中でも寝ている間でも、チェックポイントとリトライを挟みながら黙々と最後まで進めます。複数のエージェントを同時に動かし、好みや過去の修正をセッションをまたいで引き継ぐので、毎回ゼロから始めることにはなりません。同じ作業には、デスクトップアプリ、Web ダッシュボード、TUI、Slack のいずれからでもアクセスできます。 コードを書く場所が IDE、それをスクリプトにする場所が CLI だとすれば、Crew は、席を外している間もエージェントのクルーが作業を前に進めておいてくれる場所です。だからこそ向いているのは、エージェントを 1 つずつ手で操るよりも、問題に向けてエージェントの一団をまとめて差し向けたいパワーユーザーやフロンティア開発者です。ここで少し歴史の話を。Kiro Crew は、最初からこの名前だったわけではありません。何か月ものあいだ、社内では MeshClaw という名前で動いていました。チーム内で毎日徹底的に使い込まれた期間があったからこそ、そのまま社外に出すことができました。半年もしないうちに、Amazon のビルダー 39,000 人以上が使うようになり、そのうち 500 人近くが開発に参加しました（更新 597 件、週 143 コミット前後のペースです）。その頃にはもう実験の段階を抜けて、多くの人が仕事を進めるために頼る存在になっていました。 ここで、アーキテクチャについて正直に注記を 1 つ加えておきます。Kiro Crew を「アプリ」と呼ぶのは、少し雑な言い方です。実際には、Kiro エンジンを中核に据えた本格的なシステム拡張であり、それ自体が独自のアプリを備えています。Web アプリ、Slack、デスクトップアプリです。Crew の便利さを支えている部分の多くは、統合ハーネスの側ではなく Crew 自身に実装されています。常時稼働の自動化、マルチエージェントのオーケストレーション、セッションをまたいで残るメモリなどです。中には、ハーネスが別のやり方ですでに実現している機能と重なっているものもあります。話としてきれいにまとまる筋書きではありません。リリースの時期が来たとき、誰も触れないまま何か月もかけてすべてをハーネスへ分解し直すのではなく、アーキテクチャの原則からあえて外れて前に進めることを選びました。意図的な判断です。とはいえ、Kiro Crew を共通のアーキテクチャに寄せていく予定です。 結局、どれを選べばいい？ はい、知りたいのはそこですよね。実際にやろうとしていることを基準に、早見表をまとめました。 やりたいこと 使うアプリ 現在の状況 AI を組み込んだエディターでコードを書く。興味が湧いたら Agent Focus Mode からエージェントファーストを試す IDE GA ターミナルで作業する。あるいは人手を介さずに Kiro を動かす（スクリプト、CI/CD、パイプライン） CLI GA 腰を据えてエージェントと向き合う。起動元を問わず、すべてのクラウドセッションを 1 か所で開始・確認・調整する Web Preview 移動中に単発の操作を済ませる。スマートフォンからセッションを起動し、承認し、確認し、先に進める Mobile Preview 最も踏み込んだ、最も自律的な作業を任せる（メモリ、スケジュール、非同期エージェント、そして席を外している間も動き続けるエージェントのクルー） Crew Open source ここで、1 つ注目してほしいことがあります。どの答えも、やろうとしている作業を指しているだけで、「自分は何派か」という肩書きではありません。そして、ここが肝心なところです。特定のツールに愛着を持って落ち着く人が多いことは、私たちも分かっています。ですが、必ずしも 1 つに決めなければならないわけではありません。土台のエンジンは同じ、という話でしたね。デスクでは IDE を、パイプラインでは CLI を、電車の中では Mobile を、動かしっぱなしにしたい作業では Crew を使ってください。どれも同じハーネスを土台にしているので、全部を同時に使っても構いません。本当の問いは、そもそも「どのアプリを一生使うか」ではありませんでした。「この作業、この瞬間、この気分に、どのアプリか」です。 そして、私のように図で見たほうが分かりやすいという方は、こちらもどうぞ。ここまでの概念を 1 枚の図にまとめてみました。 各アプリと Kiro Crew は、1 つの共有ハーネスへと統合され、そのハーネスはさらにその下にあるプラットフォームサービス上に構築されています。 ですから、これさえあれば済む 1 つのアプリを探しに来た方には申し訳ないのですが、私たちが作ろうとしているのはそういう世界ではありません。作っているのは、できることが増えていく 1 つのエンジンに通じる、いくつもの玄関口です。それぞれの玄関口は違う人、違う場面に合わせて形を変えていて、どれも他を置き換えようとはしていません。（Kiro Crew は玄関口というより、家 1 軒に近い存在です。それでも、開いた先にあるのは同じエンジンです。）今日やろうとしていることに合う玄関口を選んでください。明日は別の玄関口を通るかもしれません。というより、それこそが狙いなのです。 いずれにしても、わくわくする時代です。 翻訳は Solutions Architect の吉村が担当いたしました。

本稿は、ＪＣＲファーマ株式会社による、 Amazon Bedrock で Claude Code を導入した約2ヶ月間の取り組みについて、 蘆田 勇平様、服部 将太様、東本 伸一様、前田 善貴様、倉本 航佑様より寄稿いただきました。 1. 会社紹介 ＪＣＲファーマ株式会社（JCR Pharmaceuticals Co., Ltd.）は、1975年創業、兵庫県芦屋市に本社を置く研究開発型製薬企業です。医療用医薬品・再生医療等製品・医薬品原料の製造・販売を事業の中核とし、連結従業員数985名（2026年3月31日現在）で事業を展開しています。 「私たちは、希少疾病にとどまらず、最も困難とされる治療の課題に挑戦し、答えを創り出していきます。」を企業理念に掲げ、希少疾病をはじめとするアンメット・メディカル・ニーズの高い疾患領域において、これまで治療法のなかった患者さんへ新しい治療の選択肢を届けることを使命としています。 本記事では、Amazon Bedrock で Claude Code を導入した約2ヶ月間の取り組みをご紹介します。 2. きっかけ・背景：パラダイムシフトとの出会い AWS アカウントチームによる研究向け AI 活用ワークショップを社内で開催いただきました。サンプルでアプリを作るとき、エージェントがプログラムを作成、実行、エラーを自ら検知して修正し続ける様子は、「質問に答えるツール」という AI のイメージを根底から覆すものでした。 その後、Amazon Bedrock 経由で Claude Code を導入した主な理由は以下の3点です。 既存の AWS 基盤をそのまま活用できる ：Anthropic 社との個別契約が不要で、すでに社内で整備された AWS アカウントからすぐに利用開始できました。ユーザ認証や監査ログなど、既存のガバナンスをそのまま適用できたことでスピーディに導入ができました。 国内でデータを完結できる ：推論プロファイルを国内（東京・大阪リージョン）に限定することで、研究データが国外に出ない設計が実現できました。 入力データがモデルの学習に使用されない ：Amazon Bedrock の仕様上、利用者が入力したデータはモデルの学習に使用しないという、当社のセキュリティ要件を満たしています。 これらの条件が揃っていたことで、新たな個別契約や長期間の構築期間を要することなく、ワークショップから約10日で利用環境の準備を完了し、研究部門への展開を開始しました。そこから約2ヶ月で実業務での活用に至っています。 3. 環境構築：製薬企業のセキュリティ要件に対応した設計 情報システム部が中心となって、用途に応じた2つの利用形態を整備しました。 3-1. Amazon EC2 による共有実行環境 Amazon Elastic Compute Cloud (Amazon EC2) 上に Claude Code の実行環境を構築し、 Amazon Bedrock を経由して Claude モデルへアクセスする構成です。推論プロファイルは東京・大阪リージョンに限定しており、データを国内で処理できます。セキュリティ対策としてセキュリティソフト（ AWS Marketplace 経由で導入した CrowdStrike 製品）や Claude Code CLI 等をセットアップした AMI を準備しており、展開するだけで済むようにしています。情報システム部がセキュアな実行環境（ソフト、クラウド環境）を一括提供することで、研究者は環境構築を意識せず利用を開始できました。 【構成図】     【利用画面】     EC2 から Claude Code CLI を起動した画面。AWS Bedrock へのアクセスは、EC2 の IAM ロールで制御。 3-2. デスクトップ版 Claude と Bedrock の連携 デスクトップ版 Claude も Amazon Bedrock 経由で利用できます。端末に Claude のデスクトップアプリをインストールして、 AWS Identity Center の SSO で認証して Bedrock と連携すれば利用できます。コーディングを伴わない文書作成・情報調査・Q & A など、日常業務での活用に主に使っています。EC2 環境とデスクトップ版の両方を整備することで、ヘビーユーザーから初めて AI に触れる社員まで、幅広い利用シーンをカバーできるようにしました。 【構成図】     【利用画面】     Claude のデスクトップアプリ。推論プロファイルが Amazon Bedrock を利用していることが、左下に表示されます。 4. 活用事例 事例①：研究部門でのバイオインフォマティクス解析支援 研究部門では、バイオインフォマティクス領域における計算科学で利用しています。機械学習を活用した解析プログラムの開発が必要になる場面が増えていますが、担当研究者はコーディング経験が浅く、Python の基礎から機械学習の習得まで相当な時間がかかる見込みでした。一般的にこれらを習得して実装まで進むには3ヶ月以上かかると見込まれていました。 Claude Code はこの「技術習得の壁」を大きく変えました。Python プログラムの作成は Claude が補完してくれるため、研究者は研究テーマの本質——「どんな解析をしたいか」「どのモデルを選ぶか」——に集中できます。エラーが発生した場合も Claude が自律的にログを確認・修正を繰り返すため、人手を介さずデバッグが完結します。プログラムのパフォーマンスチューニングやモデルの最適化も Claude に依頼することで、Claude が提案から実行・修正まで対応してくれます。結果として、コーディング未経験の研究者が数日で機械学習プログラムの実装から分析まで完遂できるようになっています。 研究者からは次のような声が寄せられています。 「Claude Code によって、アイデアからプログラムの実装まで短時間でできた」 「Python 経験がほとんどなかったため BioPython などのライブラリ、機械学習の実装方法など、道のりは長いと感じていました。しかし、Claude Code によってその不安は無くなりました」 「トラブルでも、Claude がログを分析して対処してくれます。例えば GPU を認識していないときは、必要なドライバを調べ、プログラムのライブラリの依存関係を分析して自動的に対応してくれました。」 事例②：Active Directory の AWS 移行支援 情報システム部では、オンプレミスの Active Directory 環境を AWS EC2 上へ移行するプロジェクトを進めています。オブジェクト数5,000台超という規模の移行であり、NTLMv1 や RC4 Kerberos を使用しているレガシー機器の洗い出しから、ドメイン機能レベル昇格の影響調査まで、多岐にわたる調査・分析が必要でした。 CrowdStrike NG-SIEM に蓄積された約1年分の認証ログ（NTLMv1：10,351件、RC4 Kerberos：数十万件）の分析や、AD の設定を調査するための PowerShell スクリプト作成を Claude に任せることで高速に対応できました。通常であれば外部委託業者に依頼して数週間を要するような調査・設計を、Claude との対話を通じて情報システム部による内製で実施し、2日間で完結しました。 また、今回のプロジェクトでは機能レベルの更新を計画していました。そのため、「機能レベルを2019に上げた場合、NTLMv1 の挙動はどう変わるか」「RC4 Kerberos はいつ強制無効化されるか」といった技術的な問いを Claude と議論しながら整理を進めて設計方針を確定することができました。 さらに、移行作業を進める中でエラーが発生した際も、そのエラーメッセージをそのまま Claude に入力するだけで状況分析とネクストアクションの提示が得られます。従来は担当者の経験に基づいていたログ解析・切り分けが、AI によるサポートで大幅に効率化されることで、確実なプロジェクト推進が実現できます。 5. 導入を通じて感じた変化 「AI に『聞く』から、AI と『一緒に作る』へ」 ——これが最も大きな変化です。ログのコピー貼り付け・コマンドの手入力・エラー調査といった繰り返し作業が自動化され、研究者・IT 担当者が本来集中すべき「ビジネス価値を生み出すこと」「考えること」「判断すること」に時間を使えるようになりました。AI エージェントが「知識の壁」「時間の制約」から解放し、研究と業務のフロンティアを広げています。 研究部門と情報システム部という異なる部門が同じ AI 基盤を共有し、それぞれの課題に活用できているのも大きな特徴です。既存の AWS 環境があれば特別な準備なく展開できるため、「まず試してみる」ことへのハードルが低く、組織全体への AI 活用の広がりを後押しできる可能性を感じました。 6. 今後の展望：データ活用基盤の整備と AI 活用の拡大 現在は研究部門と情報システム部を中心に Claude Code を活用していますが、今後はさらに広い部門への展開を目指しています。社内のノウハウを AI が理解・活用できる形に整える「データのセマンティック化」と、それを組織全体で活かす「データ活用基盤の整備」が次の重要課題と考えています。AI エージェントをより深くシステムに組み込むことで創薬研究をさらに加速させ、希少疾患など治療法の届かなかった患者さんへ新しい治療の選択肢を届けることを、より速く実現したいと考えています。 7. まとめ AWS ワークショップという出会いから約2ヶ月で、研究部門・情報システム部の双方が Claude Code を実業務に投入しました。既存の AWS ガバナンスを活かした設計により、製薬企業のセキュリティ要件を満たしながら迅速な導入が実現できています。本事例が「自社でも検証してみたい」と感じていただける参考となれば幸いです。 本記事に関するお問い合わせは ＪＣＲファーマ株式会社 情報システム部までお寄せください。 著者： 蘆田 勇平 研究開発本部創薬研究所トランスレーショナルリサーチ推進ユニット 遺伝子治療を中心とした創薬研究を行っています。これまで改変カプシドベクターなどの研究に取り組んできました。現在 AI 技術の活用についても取り組んでいます。 服部 将太 研究開発本部創薬研究所トランスレーショナルリサーチ推進ユニット 遺伝子治療を中心とした創薬研究を行っています。これまで改変カプシドベクターなどの研究に取り組んできました。現在 AI 技術の活用についても取り組んでいます。 東本 伸一 管理本部情報システム部 社内システムの運用保守や業務部門の支援、AWS の活用に向けた環境準備や社内展開などに取り組んでいます。 前田 善貴 管理本部情報システム部 社内システムの運用保守や業務部門の支援、Claude を利用して業務効率化に取り組んでいます。 倉本 航佑 管理本部情報システム部 社内システムの運用保守や研究・工場の IT 支援をしています。

航空業界では、散在するデータの横断的な活用が長年の課題でした。本ブログでは、 Amazon S3 を中心としたデータレイクに航空データを集約し、Amazon Bedrock AgentCore と Amazon Bedrock Knowledge Bases で横断的に AI 検索できる 航空オペレーション基盤 を紹介します。この基盤の上に業務アプリケーションを載せて具体的な課題を解決する例として、 ターンアラウンド管理 （フライトの地上折り返し作業の可視化・管理ツール）を紹介します。 また、本ソリューションは Kiro （AI 搭載の IDE）を活用し、自然言語による仕様定義からコード実装までを一貫して行う「スペック駆動開発」で構築しています。要件を自然言語で整理すれば、ここで紹介する規模のソリューションを開発できることも合わせてお伝えします。 注： 本ソリューションで使用している航空データ（フライトスケジュール、整備マニュアル、乗客情報など）はすべて架空のデモデータです。実在の航空会社・便名・人物とは一切関係ありません。 なぜ作ったのか 本ソリューションは、以下の問いに答えるために構築したデモソリューションです。 「航空会社が保有する膨大で多様なデータを、 AWS の AI ・データサービスで統合し、現場の意思決定を加速できるか？」 航空会社は日々、フライトスケジュール、フライトデータ、整備マニュアル、安全報告書、作業員音声記録、ケータリング在庫、乗客情報など、膨大なデータを生成しています。しかしこれらは業務システムごとにバラバラに管理されており、横断的な分析には人手と時間がかかります。 現場がよく直面する課題として、たとえば以下のようなものがあります。 情報がバラバラに散らばっている — 「この機材の整備履歴と異常を突き合わせたい」と思っても、 3 つも 4 つもシステムを開いて手作業で確認するしかない 蓄積されたデータが業務改善に活かされていない — 日々生成されるフライトデータ、作業記録は膨大ですが、分析や意思決定に活用する仕組みが追いついておらず、経験と勘に頼った判断が続いている ベテランの知識が共有されない — 整備マニュアルの PDF 、安全報告書、経験に基づくノウハウ。キーワード検索では見つからず「あの人に聞くしかない」状況 これらの課題に対し、 AWS が提案するのは 「聞けば、必要な情報が集まり、状況が分かる」 航空オペレーション基盤です。各システムのデータをデータレイクに集約し、 AI が横断的に検索・統合して回答する仕組みで解決します。 ソリューションの全体像 本ソリューションは 2 つの層で構成されています。 データレイク（基盤層） — 38 GB ・約 29 万ファイルの航空データ全体に、自然言語で質問するだけで答えが返ってくる AI 検索基盤 ターンアラウンド管理（活用層の一例） — データレイク基盤の上に構築した、フライトの地上作業を可視化・管理する課題解決ツール（このようなツールを業務ごとに追加できる構成です） 両層は AI の検索基盤を共有しており、ターンアラウンドの作業画面から画面を切り替えることなく、整備マニュアルや過去のフライトデータに自然言語で質問できます。 データレイク — 「聞くだけ」で全データから答えが返る フライトスケジュール、整備マニュアル、安全報告書、フライトデータ、作業員の音声記録。これまで別々のシステムに散在していた航空データを、 AI が横断検索できるようにしました。 使い方は簡単です。画面右側のチャット欄に、普段使う言葉で質問を入力するだけ。 AI が関連する複数のデータソースから情報を収集・統合し、回答を生成します。キーワードの完全一致ではなく「意味」で検索するため、マニュアルの表現が少し違っていても関連情報を見つけ出します。 従来は複数のシステムを手動で開いて突き合わせに 30 分以上かかっていた作業が、 AI への一言の質問で数秒に短縮されます。しかも、人が見落としがちな関連情報も AI が自動的に引き出します。 AI 分析パネル。「このデータをどう活用できるか？」と聞くだけで、 AI がターンアラウンド最適化、整備計画の高度化、安全分析など具体的な活用シナリオを提案。左側のエクスプローラーでデータを閲覧しながら AI に相談できる統合画面。 データの全体像を把握するダッシュボードも備えています。「そもそもどんなデータが、どれだけあるのか」を可視化することで、分析の出発点を明確にします。データの偏りやカバレッジの不足も一目で発見できます。 データカタログダッシュボード。カテゴリ別のデータ量・ファイル数・最終更新日を一覧表示。「特定カテゴリのデータが最大」「最近更新されたファイル」など、データの健全性を即座に確認できる。 地図・フライトデータ・音声 — 多様なデータをそのまま活用 航空データは構造が多種多様です。テキストだけでなく、航路データ（地図表示）、フライトレコーダー、作業音声（録音ファイル）を、それぞれ最適な形式でプレビュー・活用できます。わざわざ専用ソフトを開く必要がなく、ブラウザ上で即座に確認できることが運用効率に直結します。 航路データの地図表示。特定便の飛行ルートが地図上に自動描画される。航路計画と実績の比較や、空域の可視化に活用。 フライトレコーダーの構造表示。姿勢・エンジン・環境・位置の各データが 2,880 ポイントで記録。専用ソフト不要でデータの中身を即確認。 作業音声の再生画面。ケータリング搭載作業の録音をブラウザ内で直接再生でき、 AI による文字起こしと要約もセット表示。ベテランが口頭で伝える作業ノウハウを、テキスト化して組織の共有知にする仕組み。 ターンアラウンド管理 — データ活用による課題解決ツールの一例 データレイク基盤の上に構築した具体的な課題解決ツールとして、ターンアラウンド管理（フライトの到着から出発までの地上作業の可視化・管理）を紹介します。 飛行機が到着してから次に出発するまで、わずか 45 〜 90 分。その間に清掃、給油、ケータリング搭載、手荷物積み降ろし、機体点検など多数の作業を並行して完了させなければなりません。本デモでは仮に以下の 8 つの作業を定義していますが、実際の運用では乗務員ブリーフィングや機用品補充なども加わります。必要な作業が変わった際にも柔軟に追加や入れ替えができる設計にしています。 口頭報告を待たなくても全タスクの状態が即座にわかり、遅延の兆候を早期に検知できます。 45 分のターンアラウンドで 5 分の遅延発見が早まるだけで、定時出発率への影響は大きく変わります。 フライト一覧 — 全便の状況を一目で把握 本日の運航便を一覧表示し、各便のターンアラウンド進捗を色分けで即座に確認できます。「どの便が問題を抱えているか」を管理者が瞬時に判断し、リソースを再配分するための全体俯瞰画面です。 3D 地球儀モードでは飛行中の便の位置がリアルタイムに更新され、全体のオペレーション状況を直感的に把握できます。 フライト一覧。各便の進捗が色分け表示され、遅延が発生している便を即座に特定できる。 3D 地球儀モード。飛行中の便は赤色アイコンで位置がリアルタイム更新。運航全体の俯瞰に。 フライト詳細 — 1 便の全情報を集約 便を選択すると、その便に関する全ての情報が一画面に集約されます。 8 タスクの進捗バー、機材情報、出発・到着時刻、乗客数。複数画面を行き来する必要がなく、「この便は今どういう状態か」が 1 クリックで完全に把握できます。 フライト詳細画面。 8 タスクの進捗バー・機材情報・乗客数が一画面に統合され、便の全体像を即座に把握できる。 タスク管理 — 現場からリアルタイムに報告 作業員が無線機やスマートフォンから「作業開始」「作業完了」を 1 タップで送信するか、現場の無線通信内容から AI がステータスを自動判定して、管理画面にリアルタイムで反映されます。 従来の口頭報告やハンドサインに頼る仕組みでは、「報告を受けた時にはもう遅い」ことが多発していました。デジタル入力にすることで、報告の遅延ゼロ・記録の自動蓄積を同時に実現します。蓄積されたデータは過去分析に活用でき、「どのタスクがどの空港でボトルネックになっているか」を定量的に把握できるようになります。 タスク管理の初期状態。 8 タスクが全て「未着手」。ここからリアルタイムに状態が変化。 作業進行中。一部タスクが「進行中」に変わり、進捗バーで可視化される。 無線機から受信を開始すると、文字起こしをしながらステータスコマンドを監視。 無線通信が終了すると、録音データとともに、文字起こしと要約を保存し、音声からタスクのステータスを自動変更。 スマートフォンからもタスク入力が可能。専用デバイスがなくても、既存のスマートフォンで即座に運用開始できる。導入コストの低さも重要なポイント。 完了結果 — 作業実績の自動記録と分析 全タスク完了後、各タスクの所要時間・音声記録の文字起こし・ AI 要約が自動的に生成されます。手書き報告書の作成が不要になり、作業記録は即座に検索・分析可能な形で蓄積されます。「何が報告されたか」「どのタスクで問題があったか」を定量的に振り返れるようになります。 作業音声の文字起こし結果を自動表示。 AI が文字起こしから要約を自動生成。 タスク別の作業報告をテキストで一覧確認。 フライトツイン 3D — 巡航中の機体のデータを「見て」判断する 飛行中の航空機のフライトデータを 3D でリアルタイムに可視化し、フライトレコーダーのデータと連動させます。 PFD（計器表示）、エンジン状態、健全度スコアがリアルタイムに更新されます。 エンジン温度の偏差や N1 回転数の左右非対称など、数値だけでは気づきにくい異常の兆候を視覚的に捉えられます。「見ていて面白い」だけでなく、故障予兆の早期発見という実用的な価値があります。整備部門との情報共有も、 3D 画面を共有するだけで直感的に行えます。 フライトツイン 3D 。巡航中の機体をリアルタイムに可視化。 PFD（速度・高度・姿勢）とエンジン計器が連動し、機体の健全度スコアも常時表示。 7 つの表示レイヤー（3D 地形、飛行経路、 PFD 、エンジン、健全度、環境、方位）を目的に応じてオン・オフ可能。 フライトレコーダー分析 — フライトデータを AI が読み解く エンジン温度、振動、油圧などのフライトデータを時系列グラフで表示し、 AI が異常値の傾向を自動判定します。過去のフライトとの比較も可能です。 ベテラン整備士が経験に基づいて「この数値の傾向は気になる」と判断していたプロセスを、 AI が 24 時間自動的に実行します。属人的な判断を組織的な仕組みに変え、見落としリスクを低減します。 フライトデータの時系列表示。各パラメータの推移を一画面で確認。 AI による分析結果。エンジン健全度スコアや異常傾向を自動判定し、注意が必要な箇所をハイライト。 ケータリング搭載管理 — 搭載計画から在庫管理まで一元化 機内食の搭載計画と在庫管理を統合しています。「どの機材のどのギャレーに、どのカートを搭載するか」を視覚的に管理できます。在庫状況・販売実績・需要予測まで一画面で確認でき、欠品リスクの早期検知と発注判断を支援します。 ケータリング搭載の遅延はターンアラウンド全体に波及します。搭載計画を事前に最適化し、在庫不足を予測段階で検知することで、当日の手戻りを防ぎます。また、エアライン別のデータ分離により、外航受託便でも正確な搭載管理が可能です。 品目別の搭載数と在庫引き当て。欠品リスクを事前に検知。 ケータリング管理の概要。搭載計画の全体像を把握。 機材別カート配置図。搭載位置を視覚的に指示。 乗客情報 — サービス品質の事前準備 搭乗予定の乗客情報を事前に把握し、サービス品質の準備に活用できます。上級会員の比率が高い便では追加の対応準備が必要になりますし、販売チャネルの偏りは今後のマーケティング施策にも活きるデータです。 会員ランク別構成。上級会員比率を事前把握し、サービス準備の判断材料に。 販売チャネル別構成。予約経路の傾向分析に活用。 分析ダッシュボード — 過去データから改善ポイントを発見 蓄積されたターンアラウンドデータを集計し、「どのタスクが遅れやすいか」「どの空港で遅延が多いか」「時間帯による傾向はあるか」といった分析が行えます。 感覚的だった改善活動が、データに基づく定量的な PDCA サイクルになります。「特定空港の給油は午後に遅延しがち」「特定機材の清掃は他機材より 10 分長い」といった具体的な知見が得られ、人員配置やプロセス改善の根拠になります。 ターンアラウンド分析ダッシュボード。タスク別の平均所要時間・遅延傾向・空港別パフォーマンスを可視化し、改善すべきポイントを明確にする。 AWS アーキテクチャ ここからは、本ソリューションを支える AWS の技術構成について解説します。 データレイクの構成 データレイクの AWS 構成。 CloudFront → ALB → ECS Fargate（Private Subnets）。 S3 Files Volume をマウントし、 VPC Endpoint 経由で AgentCore Gateway → Knowledge Base → Claude に接続。 EventBridge → SQS → Lambda → DynamoDB でカタログ自動同期。 S3 共有バケットに格納された航空データ（38 GB / 29 万ファイル）を Amazon Bedrock Knowledge Bases でベクトルインデックス化し、 Amazon Bedrock AgentCore Gateway 経由で統合的にアクセスします。 主要コンポーネント： Amazon Bedrock AgentCore Gateway — RAG 検索の統合エンドポイント（IAM SigV4 認証、複数システムから共有利用） Amazon Bedrock Knowledge Bases — S3 上の航空データに対するセマンティック検索 Amazon S3 Vectors — サーバーレスベクトルストア（管理不要、低コスト） Amazon Titan Embed V2 — 埋め込みモデル（1,024 次元） Amazon EventBridge — S3 オブジェクト変更のリアルタイム検知 Amazon SQS — デバウンス付きバッファ（5 分ウィンドウで変更を集約） AWS Lambda — カタログインデクサー、 KB 同期、統計集計（6 関数） Amazon DynamoDB — カタログメタデータ・統計情報のサーバーレス管理 カタログ自動同期の仕組み S3 オブジェクト変更 (PUT / DELETE) → EventBridge ルール（リアルタイム検知） → SQS キュー（デバウンス: 5 分ウィンドウで集約） → Lambda（カタログインデクサー） → DynamoDB 更新 → Knowledge Base インジェスション（ベクトル再構築） S3 にデータを置くだけで AI 検索インデックスが自動更新される仕組みです。 SQS の 5 分デバウンスで細かな変更を集約し、 Lambda 起動回数とコストを最適化しています。 ターンアラウンド管理の構成 ターンアラウンド管理の AWS 構成。 ECS Fargate 上のフロントエンド（React + Three.js + MapLibre）とバックエンド（Express.js + WebSocket）が、 AgentCore Gateway 、 Transcribe 、 Location Service 、 S3 Files と連携。 ユーザー（ブラウザ） → CloudFront → ALB → ECS Fargate (フロントエンド: React + Three.js + MapLibre) → ECS Fargate (バックエンド: Express.js + WebSocket) ├→ AgentCore Gateway (SigV4) → KB → Claude [AI 分析] ├→ Amazon Transcribe (WebSocket) [音声文字起こし] ├→ Amazon Location Service (API Key) [地図・航路描画] └→ Amazon S3 + S3 Files (/mnt/s3) [データストレージ] └→ エフェメラルキャッシュ (50 GB) [高速読み込み] 主要コンポーネント： Amazon Bedrock (Claude Sonnet 4 / Claude 3.5 Haiku) — AI 分析・要約生成 Amazon Transcribe — 作業員音声のリアルタイム WebSocket 文字起こし Amazon Location Service — 空港マップ・航路可視化（API Key 方式） Amazon ECS on AWS Fargate — バックエンド・フロントエンドのコンテナ実行 Amazon S3 + S3 Files — 38 GB / 29 万ファイルの共有ストレージ（NFS マウント） Amazon Polly — デモ音声生成（Neural ボイス、デプロイ時バッチ処理） AWS Cost Explorer — システム別コスト可視化 Kiro によるスペック駆動開発 本ソリューションは、 AWS が提供する AI 搭載 IDE Kiro を活用して構築しています。 Kiro のスペック駆動開発では、開発者が自然言語で要件を定義すると、 AI が設計・タスク分解・コード実装までを一貫して支援します。 自然言語で要件を記述（requirements.md） → Kiro が技術設計を提案（design.md） → タスクリストを自動生成（tasks.md） → タスクに沿ってコードを実装 → 受入基準に基づく検証 本プロジェクトでは、 12 のサブシステムにわたる 79 個の仕様ファイルを Kiro のスペックとして管理しています。 24 の要件を 9 つのフェーズに分割して段階的に実装しました。要件を自然言語で整理すれば、ここで紹介した規模のソリューションを Kiro で開発できます。 まとめ 本ソリューションは、航空オペレーションが抱える「データのサイロ化」「作業進捗の不可視性」「暗黙知の属人化」という 3 つの課題に対して、 AWS サービスの組み合わせでどこまで解決できるかを示すリファレンス実装です。 散在するデータは AI が横断検索する。 Amazon Bedrock Knowledge Bases + Amazon Bedrock AgentCore Gateway により、 29 万ファイルに自然言語で即座にアクセス 作業進捗はリアルタイムに見える化。 無線機・モバイル対応で、口頭報告に頼らない進捗管理を実現 フライトの状況は地図上で一目でわかる。 Amazon Location Service により、全機材の航路・空港状況をリアルタイムに可視化 データ変更は自動でカタログに反映。 EventBridge + SQS + Lambda のイベント駆動で運用負荷を最小化 仕様は自然言語で書き、 AI が実装する。 Kiro のスペック駆動開発で、 12 システム・ 79 仕様を効率的に管理・実装 このアーキテクチャパターンは航空に限らず、製造業・物流・医療など、複数の業務システムにまたがるデータを AI で統合検索・分析し、現場の意思決定を支援したい多くの産業で応用可能です。要件を整理すれば、 Kiro で開発できます。 著者 アマゾンウェブサービスジャパン合同会社 エンタープライズ事業統括本部 交通・物流事業本部　シニアアカウントマネージャー 金子 暁人 アマゾンウェブサービスジャパン合同会社 技術統括本部 ソリューションアーキテクト 稲田 崇志

はじめに リアルタイム性の高いマルチプレイヤーゲームは、複数のプレイヤーの入力を集約し、ゲームの状態を一貫させて全員へ配信する仕組みを必要とします。この仕組みの一つに、権威あるサーバーがゲームの状態を管理する専用ゲームサーバー (Dedicated Game Server) 方式があります。対戦の公平性やチート対策、多人数の同時接続が求められるタイトルでは、専用ゲームサーバー方式が広く採られています。この方式では、マッチメイキング、ゲームサーバーの割り当て、セッション終了後のサーバー回収といったライフサイクル管理が必要になり、そのオーケストレーション基盤をどう構築・運用するかが設計上の大きなテーマとなります。 AWS で専用ゲームサーバーをホストする主な選択肢は、マネージドサービスの Amazon GameLift Servers を利用するか、 Amazon Elastic Compute Cloud (EC2) や Amazon Elastic Container Service (ECS) 、 Amazon Elastic Kubernetes Service (EKS) 上でセルフホストするかの 2 つです。GameLift Servers はインフラ構築・運用の大部分を担いますが、要件によってはより柔軟な制御が必要な場合があり、 Agones の利用が選択肢の一つとなります。Agones はオープンソースの専用ゲームサーバーホスティング向け製品で、Amazon EKS 上にデプロイでき、柔軟性を享受しつつ専用ゲームサーバーの構成を簡素化できます。しかし Kubernetes 基盤の運用は避けられず、Agones の運用には一定の負荷が存在しました。 2024 年 12 月に一般提供が始まった Amazon EKS Auto Mode は、Kubernetes の構築・運用負担を低減する機能です。Agones の基盤となる EKS クラスタで EKS Auto Mode を利用できれば、専用ゲームサーバーを柔軟かつ簡素に構築・運用できます。ただし EKS Auto Mode にはいくつかの制約もあります。 本記事では、EKS Auto Mode の制約が Agones の特性を阻害しないようにするための設計方針を紹介します。 Agones リソースの概要 本記事の内容に関連する Agones カスタムリソースについて説明します。 GameServer： プレイヤーが接続するゲームサーバープログラムが動作する Pod にあたるリソースです。状態を持ち、Ready 状態はゲーム開始可能で待機している状態、Allocated 状態はゲームプレイのためにリソースが確保された状態を表します。 Fleet： GameServer のまとまりを管理するためのリソースです。常に起動しておくべき GameServer リソースの数を指定でき、Fleet Autoscaler リソースによるスケーリング制御も可能です。 GameServer Allocation： ゲームプレイのために GameServer リソースを選択し確保する操作を行うリソースです。この操作により選択された GameServer リソースは Ready 状態から Allocated 状態となります。 コントローラ系リソース： Agones の機能を実現・制御するためのリソース群です。 EKS Auto Mode と Agones の共存における課題 EKS Auto Mode は、クラスタのノード管理を AWS の責任範囲で自動化します。例えば Karpenter をベースとしたノードのプロビジョニング・スケーリング・入れ替え、Bottlerocket による最適化された OS、各種アドオンのマネージド管理といった機能により、Kubernetes の運用を大幅に簡素化できます。 一方、ユーザー側で設定できる範囲が狭まるというトレードオフがあります。Agones の基盤として特に考慮が必要なのは、EKS Auto Mode が以下の目的のために自動で行うノードの中断です。 Consolidation： 稼働中の Pod が少ないノードを終了し、利用率の高いノードへ Pod を集約してコストを最適化する。 Drift： NodePool や NodeClass の設定変更、AMI の更新などに追従してノードを入れ替える。 Expiration： セキュリティ維持のため、一定期間が経過したノードを強制的に入れ替える。 Interruption： Spot Instance の中断通知やハードウェア障害などに応じてノードを終了する。 ※EKS Auto Mode の長期実行ワークロードでの扱いについては、builders.flash 記事「 Amazon EKS Auto Mode のノード自動更新を Deep Dive する 」もあわせて参照ください。 いずれの中断でも、対象ノード上の Pod へ SIGTERM が発行されます。Agones上で動かすような専用ゲームサーバーには「プレイ中のゲームセッションを中断させない」という強い制約があるため、対策をしないとプレイ中のゲームサーバーが強制終了されるリスクがあります。 EKS Auto Mode と Agones を共存させる設定のポイント そこで、Agones のコントローラ系とゲームプレイ中のサーバープログラムをノードの中断から保護する仕組みを、次の 6 つのポイントで構成します。以降、それぞれのポイントについて、実際の設定ファイル ( nodepools.yaml / fleet.yaml / agones-values.yaml ) を引用しながら、具体的な実装方法を説明します。 Point # 対象 内容 Point 1 共通 NodePool の expireAfter 、 terminationGracePeriod を適切に設定する Point 2 GameServer GameServer の Pod の terminationGracePeriodSeconds をゲームの最大持続時間より長い値に設定する Point 3 GameServer GameServer 上で動くサーバーアプリで、適切なシグナルハンドリングを実装する Point 4 GameServer Eviction を許可してノードの自動最適化を機能させる ( spec.eviction.safe: Always ) Point 5 コントローラ系 Agones コントローラ系と GameServer が配置される NodePool を分ける Point 6 コントローラ系 agones-allocator と agones-ping の PDB を有効にする Point 1 (共通) ：NodePool の expireAfter / terminationGracePeriod を適切に設定する EKS Auto Mode では、ノードは必ずいつか中断されます。特に Expiration はノード生存期間最大21日の制約があり、必ず発生します。この expireAfter の値と、ノードが強制的に中断されるまでの猶予期間である terminationGracePeriod を、ワークロード特性に合わせて NodePool に設定することが起点になります。 NodePool とは、Karpenter ベースのノード管理機能で、Pod の要求に応じてインスタンスを自動的にプロビジョニング・スケーリングし、クラスターのコンピュートリソースを柔軟に管理するための仕組みです。 設定にあたっては、次の関係を守るようにしてください。 terminationGracePeriod は、後述する Pod の terminationGracePeriodSeconds より長く設定する (ノードが強制削除される前に、Pod が Graceful に終了しきるようにするため) 。 expireAfter + terminationGracePeriod の合計は最大 21 日に収める (EKS Auto Mode の制約) 。 また disruption.budgets の nodes: "10%" （NodePool Disruption Budgets: NDB）により、同時に中断処理へ入るノード数を全体の 10 % に制限し、一斉中断の影響を抑えます。 consolidationPolicy: WhenEmpty については Point 4 で触れます。 Point 1 を踏まえた NodePool の設定例は次の通りです（ nodepools.yaml ）。 # GameServer 用 NodePool apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: agones-worker spec: template: spec: # Point 1: ゲームセッション時間を考慮して設定 # terminationGracePeriod は Pod の terminationGracePeriodSeconds より長くすること expireAfter: 336h # 14日 terminationGracePeriod: 4h # expireAfter + terminationGracePeriod が21日(504h)に収まるように disruption: consolidationPolicy: WhenEmpty consolidateAfter: 30s budgets: - nodes: "10%" Point 2（GameServer）：Pod の terminationGracePeriodSeconds をゲーム最大持続時間より長く設定する ノードが中断され Pod に SIGTERM が発行されてから、Pod が強制終了（SIGKILL）されるまでの猶予が terminationGracePeriodSeconds です。この値をゲームの最大持続時間より長く設定することで、進行中のゲームが途中で強制終了されることを防ぎます。 terminationGracePeriodSeconds は Pod リソースの設定値ですが、Agones では GameServer リソース定義内で設定することになります。また GameServer の制御は Fleet で行うことが一般的なため、ここでは Fleet の設定例を次の通り示します ( fleet.yaml ) apiVersion: "agones.dev/v1" kind: Fleet metadata: name: simple-game-server-fleet spec: replicas: 3 template: spec: # ... (省略) template: spec: # Point 2: ゲームセッション最大持続時間 + バッファより長い値を設定 # 例: ゲーム最大30min + クリーンアップ5min = 35min = 2100sec terminationGracePeriodSeconds: 2100 ゲームセッション 1 つの最大持続時間に、クリーンアップ処理のバッファを加えた値を設定します。Point 1 の terminationGracePeriod (ノード側の猶予) を、この terminationGracePeriodSeconds (Pod 側の猶予) より長く設定することで、 terminationGracePeriod > terminationGracePeriodSeconds > ゲーム最大持続時間 の関係が成立し、プレイ中のゲームを保護できます。 まとめると、 以下を満たすように各パラメータを設定すればよいことになります。 NodePool の terminationGracePeriod > Pod の terminationGracePeriodSeconds > ゲームの最大持続時間 NodePool の expireAfter は自由 ( terminationGracePeriod との合計は 21 日以下) Point 3 (GameServer) ：適切なシグナルハンドリングを実装する Point 1・2 で猶予期間を確保しても、SIGTERM を受け取ったサーバープログラムが適切に振る舞わなければ、ゲームサーバーは安全に終了できません。GameServer 上で動くサーバープログラムでは、SIGTERM を受信したときに次の動作を実装します。 Allocated 状態 (ゲーム進行中) ：進行中のゲームの終了を待ち、クリーンアップ処理を行った後に Agones SDK の sdk.Shutdown() を呼び出す。 Ready 状態 (待機中) ：新規 Allocation を防ぐため、即時 sdk.Shutdown() を呼び出す。 この実装により、ノード中断のシグナルを受けても、進行中のゲームを守りつつ、待機中のサーバーは速やかに退去できます。 Point 4 (GameServer) ：Eviction を許可してノードの自動最適化を機能させる ( spec.eviction.safe: Always ) Point 1〜3 でプレイ中のゲームを保護できたら、次に Agones の spec.eviction.safe を Always に設定し、EKS Auto Mode によるノードの自動最適化を機能させます ( fleet.yaml ) 。 spec: template: spec: # Point 4: eviction.safe を Always に設定 # Karpenter の Drift/Consolidation/Expiration 時に Graceful な Eviction を許可する eviction: safe: Always spec.eviction.safe は、各 GameServer の Pod に対して Agones が内部的に作成する PDB ( maxUnavailable: 0% ) を有効化するかどうかを制御します。デフォルトの Never の場合、常に eviction をブロックする動きとなります。 (表は https://agones.dev/site/docs/advanced/controlling-disruption/ より) Never のままでは、この PDB がすべての Eviction をブロックし、EKS Auto Mode 環境で次の問題が発生します。 Karpenter が Consolidation / Drift を試みても Pod に SIGTERM が発行されず退去しないため、Cordon 状態のノードが既存 Pod ごと残り続け、コスト効率が悪化する。 Drift (AMI 更新) が PDB にブロックされ、セキュリティパッチの適用が遅延する。 上記の動作の結果、近い時間帯に起動した全ノード上の Pod が Expiration まで生存し続け、それらの Pod が近い時間帯に一斉に SIGKILL されるリスクが生じる。 Always を設定すると Agones のネイティブ PDB が無効化され、Eviction が許可されます。Pod が稼働中のノードでも Drift による AMI 自動更新と、Expiration 時の Graceful なノード入れ替えが機能するようになります (Never ではこれらが PDB にブロックされます) 。プレイ中のゲームの保護は Point 1〜3 で確保した猶予期間とシグナルハンドリングが担保するため、Always にしても進行中のゲームが即座に切断されることはありません。 Always の設定でも安全に運用する目的で、Point 1 で設定した consolidationPolicy: WhenEmpty (Pod が残っているノードでは Consolidation を発動させない) と NDB ( nodes: "10%" 、同時中断ノード数の制限) を補完策として組み合わせます。Always は Drift / Expiration を有効に機能させる一方、Consolidation まで WhenEmptyOrUnderutilized にすると稼働中 Pod のあるノードも集約対象となりゲームサーバーが頻繁に Evict され得るため、Consolidation は WhenEmpty に絞り、空ノードの回収のみに留めます。Agones の Fleet 設定 spec.scheduling の値はデフォルトで Packed となっており、できるだけ既に GameServer が動作しているノードに新規 GameServer を起動するようにスケジュールするため、 WhenEmpty の設定でも十分なコスト最適化効果が見込めます。 Point 5 (コントローラ系) ：Agones コントローラ系と GameServer の NodePool を分ける Point 1 で設定した expireAfter / terminationGracePeriod は NodePool 単位の設定です。Agones のコントローラ系 (controller / extensions / allocator / ping) と GameServer では、必要な猶予期間が異なります。 コントローラ系： 短時間の再起動が許容されるため、長期安定稼働を優先しつつ猶予は比較的短くてよい。 GameServer： ゲーム最大持続時間に対応した長い猶予 ( terminationGracePeriod ) が必要。 そこで、コントローラ系用と GameServer 用で NodePool を分離します ( nodepools.yaml ) 。 # コントローラ用 NodePool apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: agones-controller spec: template: metadata: labels: agones-role: controller # ラベルで役割を区別 spec: # コントローラは長期安定稼働を優先 expireAfter: 336h # 14日 terminationGracePeriod: 72h # 3日 --- # GameServer 用 NodePool (Point 1 で前掲) # labels: agones-role: gameserver / terminationGracePeriod: 4h そのうえで、GameServer 側は Fleet の nodeSelector で GameServer 用 NodePool を指定します ( fleet.yaml ) 。 template: spec: # Point 5: GameServer 用 NodePool にスケジュール nodeSelector: agones-role: gameserver コントローラ系は、Agones の Helm Values で nodeSelector を指定し、コントローラ用 NodePool に配置します ( agones-values.yaml ) 。 agones: controller: # Point 5: コントローラ用 NodePool にスケジュール nodeSelector: agones-role: controller extensions: nodeSelector: agones-role: controller allocator: nodeSelector: agones-role: controller ping: nodeSelector: agones-role: controller これにより、それぞれのワークロード特性に合った猶予期間を両立できます。 Point 6 (コントローラ系) ：agones-allocator と agones-ping の PDB を有効にする 前述の通り EKS Auto Mode ではいつか必ずノードの中断が発生するため、Agones のコントローラ系サービスでも可用性維持のための設定が重要です。agones-allocator (ゲームサーバーの割り当てリクエストを受け付けるサービス) と agones-ping (レイテンシー計測用サービス) はデフォルトで PDB が無効のため、ノードが中断されてもこれらが全停止しないよう、PDB を有効化します ( agones-values.yaml ) 。 agones: allocator: replicas: 3 # Point 6: allocator の PDB を有効化 pdb: enabled: true minAvailable: 1 ping: replicas: 2 # Point 6: ping の PDB を有効化 pdb: enabled: true minAvailable: 1 minAvailable: 1 により、ノード中断時にも最低 1 レプリカが稼働し続けることを保証し、コントロールプレーンの可用性を維持します。 なお、agones-controller, agones-extensions はデフォルトで PDB が有効となっています。 さらに安定した運用のための補足 (レアケースへの対処) Point 1〜6 の設計により、通常のノード中断からのゲームサーバー保護を実現できます。さらに安定した運用のためには、次のレアケースへの対処も検討ポイントになります。いずれも各実装に依存するため、必要に応じて検討してください。 GameServerAllocation のレースコンディション Ready 状態の GameServer が SIGTERM を受信した直後から Shutdown 完了までの間に、GameServerAllocation によって Allocate される可能性がゼロではありません。これが起こると、プレイヤーが接続するころには Allocate された GameServer が既に停止しておりエラーとなるリスクがあります。以下はこれを防ぐ方法の例です。 GameServer にあらかじめラベル ( allocationblock=false 等) を付与し、GameServerAllocation 側でそのラベルを持つ Pod のみを対象とする設定を行う。SIGTERM 受信時には即座にラベルを外す。ラベル削除後も一定時間待機し、その間に Allocate された場合はゲームを継続し、終了後に Shutdown する。 起動中 Pod への SIGTERM 発行時のハンドリング不可 コンテナ起動中 (Starting / ContainerCreating) に SIGTERM が発行されると、アプリケーション側でハンドリングできず、GameServer は正常に起動し Ready 状態となる一方、 Pod は terminationGracePeriodSeconds 経過後に停止してしまう動作となり、ゲームを保護できません。これを防ぐには以下の方法が例として挙げられます。 対策例 1： GameServer にあらかじめラベル (allocationblock=false 等) を付与し、GameServerAllocation 側でそのラベルを持つ Pod のみを対象とする設定を行う。外部コントローラで Pod の deletionTimestamp を監視し、非 null、つまり削除予定がある状態なら、前述の Allocation 用ラベルを外し、新規 Allocation を防ぐ。 対策例 2： イメージサイズの削減・DaemonSet 等による事前 pullといった方法で起動時間短縮を図り、発生確率を最小化する。 まとめ 本記事では、Agones の基盤に EKS Auto Mode を採用する際、ノードの自動中断からゲームサーバーを保護する設計を 6 つのポイントで紹介しました。専用ゲームサーバーのセルフホストで、Agones の柔軟性を活かしつつ EKS Auto Mode で運用管理をシンプルにするには、EKS Auto Mode のノード中断と Agones のゲームサーバーライフサイクルの競合を解消する設計が鍵になります。 本記事で紹介した Point 1〜6 の設計パターンと実装例 ( nodepools.yaml / fleet.yaml / agones-values.yaml ) が、EKS Auto Mode 上での Agones 導入を検討する方の参考になれば幸いです。

本記事は 2025 年 2 月 25 日に公開された Dr. Tomasz Zemojtel、Christopher Gatsch、Dr. Manuel Delpero、Zhan Ying、Dr. Mueller Michael による “ Enhanced Genomic Data Storage and Workflows with MGI, Sentieon, and AWS ” を翻訳したものです。 ゲノム研究の分野はかつてないスピードで進化しており、データストレージと解析に堅牢かつスケーラブルなソリューションが求められています。MGI、Sentieon、Amazon Web Services (AWS) は協業により、ゲノム研究を支援する機能を提供します。研究者や臨床医は、AWS HealthOmics と Sentieon のワークフローを活用することで、MGI のシーケンシング技術の能力を最大限に引き出せるようになりました。これにより、効率的なデータの保管、取得、整理と、大規模で高精度なゲノム解析が可能になります。 本記事では、この統合的な協業のソリューションアーキテクチャ、ワークフローの選択肢、そして研究ラボにおけるハイスループットなゲノム解析の実装の詳細をご紹介します。 ベルリンのMGI 欧州本社におけるハイスループットなゲノムデータ解析 ハイスループットシーケンシング施設は、膨大なデータ量と解析ワークフローの管理に大きな課題を抱えています。ローカルストレージや計算基盤を利用する従来のアプローチでは、データ生成の規模に対応しきれず、処理のボトルネック、高いメンテナンスコスト、複雑なデータセキュリティ要件などが発生しがちです。ラボには、データストレージをシームレスに扱い、スケーラブルな計算リソースを提供し、セキュリティコンプライアンスを維持しつつ、予測可能なコストで利用できるソリューションが必要です。 MGI-tech はバイオテクノロジーイノベーションのリーダーであり、次世代シーケンシング (NGS) とラボオートメーション技術を開発・提供しています。同社のフラッグシップである DNBSEQ プラットフォームは、精密医療、農業、ヘルスケア分野に向けて、高精度かつハイスループットな遺伝子解析ソリューションを提供します。 ベルリンにあるMGI 欧州本社には 3 台のハイスループット T7 シーケンサーが設置されており、週あたり合計で最大 63 テラベース (Tb、テラ塩基) のゲノムデータを生成しています。3 台の T7 シーケンサーが生成したデータは AWS へ安全に転送され、ゲノムデータ向けにスケーラブルかつコストを最適化したストレージソリューションである AWS HealthOmics Sequence Store に取り込まれます。AWS HealthOmics 内では、Sentieon の高性能なプライベートワークフローが実行され、高速かつ高精度なデータ解析が行われます。 この統合型のハイスループットソリューションにより、MGI 欧州本社の研究者や臨床医は、重要なアプリケーションに向けて複雑なゲノムデータから価値ある知見を引き出せます。具体的には、遺伝性疾患の診断、がん研究、医薬品開発、大規模な集団ゲノミクスの研究などが含まれます。 AWS HealthOmics と Sentieon AWS HealthOmics は、ゲノムデータの保管、処理、解析のためのセキュアでスケーラブルなサービスです。HealthOmics Sequence Store は、大量のシーケンシングデータをコスト効率よく保管する手段を提供し、HealthOmics ワークフローとのシームレスな統合によって、下流解析ですぐに利用できる状態を保ちます。保存時の機密性の高い顧客データを保護するため、HealthOmics は AWS Key Management Service (AWS KMS) の AWS 所有のキーを用いてデフォルトで暗号化を行います。カスタマーマネージドキーもサポートされています。 Sentieon は 2014 年から AWS パートナーであり、高速かつ高精度なゲノムデータ処理のために最適化されたバイオインフォマティクスアルゴリズムを開発してきました。HealthOmics ワークフローでは、Sentieon の DNAscope および TNseq パイプラインを、あらかじめ定義された Ready2Run ワークフローとしても、カスタマイズ可能なプライベートワークフローとしても実行できます。 アーキテクチャの概要 図 1 – ベルリンのMGI 欧州本社で実装されたワークフローアーキテクチャ。 図 1 は次の流れを示しています。 MGI DNBSEQ-T7 シーケンサーが 1 週間で最大 21 Tb (テラベース) のデータを CAL 形式 (MGI シーケンサーのベースコールソフトウェアが生成するバイナリファイル形式) で出力します。 MGI ZTRON Lite Pro が CAL ファイルを FASTQ ファイルに変換し、データの受け渡しを可能にします。 FASTQ ファイルは AWS 上の Amazon Simple Storage Service (Amazon S3) に安全に転送されます。 これらのファイルは AWS HealthOmics Sequence Store にインポートされます。また、 HealthOmics Transfer Manager を通じて、ローカルストレージから FASTQ ファイルを HealthOmics Sequence Store に直接アップロードすることもできます。 DNAscope や TNseq パイプラインなどの Sentieon Genomics ソフトウェアは、HealthOmics ワークフロー上で Ready2Run ワークフローとしても、カスタマイズ可能なプライベートワークフローとしても実行できます。 ワークフロー実行の最後に、AWS HealthOmics は生成された BAM および VCF ファイルを S3 バケットへ転送します。 結果は臨床研究者などのユーザーによって参照されます。 Ready2Run ワークフロー: 迅速かつ簡単なセットアップ 迅速でシンプルなソリューションを求める研究者向けに、Sentieon の Ready2Run ワークフローは、あらかじめ構築・最適化されたパイプラインを提供します。数クリックまたはシンプルな API 呼び出しでデプロイでき、固定料金かつ予測可能な実行時間で動作します。これらのワークフローは、次のようなさまざまなゲノム解析タスクに対応するよう設計されています。 DNAscope : MGI シーケンシングプラットフォーム向けに最適化された、生殖細胞系列バリアントコール用パイプライン。 TNseq : 体細胞バリアントコール用パイプライン。GATK の Mutect2 と同等の精度を達成しながら、MGI データではより短い実行時間を実現します。 AWS HealthOmics ワークフローを利用することで、研究者は Sentieon の Ready2Run パイプラインから選択でき、さまざまな解析ニーズ、リファレンスゲノム、シーケンシングプラットフォームに対応する柔軟な選択肢を得られます。これらのワークフローは実行単位で課金されるため、コストを予測しやすく、ハイスループットなゲノミクスプロジェクトに必要なスケーラビリティを提供します。 プライベートワークフロー: 高度なユーザー向けの完全なカスタマイズ より高度な制御やカスタマイズを必要とするチーム向けに、Sentieon は AWS HealthOmics 上でパイプラインをプライベートワークフローとして実行することもサポートしています。これらのワークフローは完全な柔軟性を提供し、研究者が固有のニーズに合わせてワークフローをカスタマイズ・最適化できるようにします。 Sentieon のプライベートワークフローを実行することで、ユーザーは次のことが可能になります。 AWS 向けの Sentieon コンテナイメージを独自に構築する。 パラメーター、リファレンスゲノム、解析結果の出力内容をカスタマイズする。 パイプライン構成を制御しつつ、AWS HealthOmics のインフラストラクチャを活用する。 プライベートワークフローを始めるには、 Sentieon GitHub リポジトリ で提供されている詳細なセットアップ手順に従ってください。このリポジトリには、コンテナイメージ、セットアップスクリプト、WDL および Nextflow の両エンジン向けのワークフローサンプルなど、カスタマイズしたワークフローの構築とデプロイに必要なものがすべて含まれています。プライベートワークフロー向けに Sentieon ライセンスサーバーを有効化する手順については、 Requesting Sentieon licenses for private workflows を参照してください。 まとめ MGI、Sentieon、AWS の協業は、ゲノミクスラボ向けの堅牢なソリューションを提供します。MGI のシーケンシング技術を活用することで、合理化された、かつカスタマイズ可能なワークフローを AWS インフラストラクチャとシームレスに統合して利用できます。また、Sentieon の Ready2Run ワークフローを実行する場合でも、プライベートワークフローをセットアップする場合でも、研究者は AWS HealthOmics を活用して、セキュアでコンプライアンスに準拠した環境で大規模にゲノムデータを保管・解析できます。これにより、より迅速かつ高精度な発見が可能になります。 AWS KMS 暗号化などの組み込みのセキュリティ機能により、コンプライアンスに準拠した環境でのデータ保護が確保されます。また、固定料金の Ready2Run ワークフローは、予測可能なコストと自動化されたリソース管理を提供します。 MGI、Sentieon、AWS のこの協業は、MGI シーケンシング技術を活用するゲノミクスラボ向けに堅牢なソリューションを提供し、より迅速かつ高精度な発見を可能にします。このソリューションは、ハイスループットシーケンシング業務に一般的に伴う処理のボトルネックの解消に役立ちます。 この統合ソリューションをゲノム研究や臨床アプリケーションに実装する方法について詳しくは、 AWS HealthOmics のウェブページや Sentieon GitHub リポジトリ をご覧ください。また、この技術がお客様のゲノム解析ワークフローをどのように加速できるかについて、個別のご相談を承ります。 AWS 担当者 までお問い合わせください。 謝辞 本ブログの作成にご協力いただいた MGI-tech のバイオインフォマティクスサイエンティスト Dr. Liene Astica、フィールドバイオインフォマティクスサイエンティスト Ying Zhan、フィールドアプリケーションサイエンティスト Ongeziwe Mbhele の各氏に感謝申し上げます。 参考資料 AWS for Genomics Solutions AWS Healthcare & Life Sciences Blog Collection AWS Healthcare & Life Sciences – Security and Compliance Genomics Unlocked: MGI-tech の最新ウェビナーシリーズを視聴できます 著者について Dr. Tomasz Zemojtel Dr. Tomasz Zemojtel は、AWS の EMEA 地域におけるヘルスケアビジネス開発マネージャーです。ヘルスケアとテクノロジーのバックグラウンドを持ち、ヘルスケア組織や研究・臨床機関がクラウドサービスを活用してイノベーションを推進できるよう支援することを専門としています。Tomasz は、クラウドコンピューティングを通じて大規模な臨床データセットの可能性を引き出し、個別化医療や統合型ヘルスケアソリューションを前進させることに情熱を注いでいます。仕事以外では、ジョギングや山歩き、海辺で過ごす時間を楽しんでいます。 Christopher Gatsch Christopher Gatsch は MGI のフィールドバイオインフォマティクスサイエンティストで、顧客ワークフローの最適化や BIT 製品体験・ワークフロー効率の向上に注力しています。読書、アウトドア活動、さまざまな国への旅行に情熱を注いでいます。 Dr. Manuel Delpero Dr. Manuel Delpero は MGI のアプリケーションサイエンティスト部門のアソシエイトマネージャーで、顧客ワークフローの最適化と、バイオインフォマティクスとコマーシャル戦略の橋渡しを専門としています。分子遺伝学およびバイオインフォマティクスの博士号を持ち、バイオテクノロジーの技術面とビジネス面の両方において幅広い業界経験があります。ウェイトトレーニング、旅行、新しいビジネス機会の探求に情熱を注いでいます。 Zhan Ying Zhan Ying は人工知能のバックグラウンドを持つ IT スペシャリストで、包括的な BIT ソリューションを提供しています。マシン統合、ユーザーラボのネットワーキング、販売後のトラブルシューティングなど、BIT 関連の IT サポートを担当しています。 Dr. Mueller Michael Dr. Michael Mueller は AWS のシニアゲノミクスソリューションアーキテクトです。ゲノミクスとクラウドコンピューティングの力を組み合わせてヘルスケアを改善する取り組みを支援することに情熱を注いでいます。ロンドンの大都会の探索と、イギリスやヨーロッパのアウトドアの両方を楽しんでいます。 翻訳は Solutions Architect の吉村が担当いたしました。

本記事は 2025 年 7 月 18 日に公開された Edwin Sandanaraj、Charlie Lee、Billy Rowell、Khi Pin Chua、Rajesh Sukumaran による “ Benchmarking PacBio whole genome sequencing variant pipeline analysis with AWS HealthOmics workflows ” を翻訳したものです。 ゲノム研究が医療とポピュレーションヘルス (集団全体の健康) の最前線を切り拓き続ける中で、複雑なゲノム領域の解読、構造バリアントの同定、そして遺伝的多様性の大規模な理解には、ロングリードシーケンシングがますます不可欠になっています。 PacBio HiFi シーケンシングは、高精度かつ長いリードを生成するため、包括的な全ゲノムシーケンシング (WGS) に適しています。 大規模なロングリード WGS 解析を実行するには、スケーラブルでセキュア、かつ本番運用に耐える計算環境が必要です。 AWS HealthOmics はまさにこの用途に特化して構築されており、バイオインフォマティシャンはコンテナ化されたワークフローの実行と大量のゲノムデータの処理を、高い信頼性と柔軟性をもって行えます。 PacBio と AWS HealthOmics ワークフローの統合 アーキテクチャは、大規模ゲノミクスプログラムの中核として機能してきました。この実装により、セキュアかつ効率的なデータ処理を実現しながら、大規模な解析結果の提供を効率化できます。HealthOmics の堅牢なセキュリティとスケーラブルなインフラストラクチャを活用することで、PacBio ワークフローは大規模なロングリードシーケンシングデータを処理しつつ、国家的なヘルスケア施策に求められるデータガバナンス基準を維持できます。こうした実際の運用実績は、HealthOmics が PacBio の全国的な精密医療プログラムをエンタープライズ級の信頼性とパフォーマンスで支えられることを示しています。 本ガイドでは、PacBio の WGS バリアントパイプライン を AWS HealthOmics 上で実装する方法を紹介し、広範なベンチマークに基づく大規模かつコスト効率の高いデプロイに向けたパフォーマンス最適化の知見とエビデンスに基づく推奨事項をお伝えします。 PacBio HiFi シーケンシングは、典型的には 15〜25 キロ塩基のロングリードを、高い塩基精度 (塩基の 90 パーセントが Q30 を上回る) で生成します。この組み合わせにより、研究者は反復領域や GC (Guanine-Cytosine) リッチな領域を網羅し、ハプロタイプを正確にフェージング (決定) し、ショートリード技術では見落とされがちな構造バリアントを検出できます。ロングリードシーケンシング解析の代表的な用途は次のとおりです。 一塩基バリアント (SNV) および小規模な挿入・欠失 (indel) – 塩基レベルの変化や複数塩基にわたる小さな変異 構造バリアントの発見 – 大規模な挿入、欠失、再構成を塩基レベルの精度で解読 ハプロタイプのフェージング – 長いハプロタイプブロックにわたって、バリアントを母方または父方のアレルに割り当て 複雑な遺伝子座のアセンブリ – 疾患関連遺伝子座における反復配列や遺伝子重複を解き明かす De novo アセンブリ とパンゲノム構築 – 集団特有の多様性を反映した、高品質で連続性の高いゲノムアセンブリの生成 DNA メチル化 – ゲノム全体の CpG サイトにおける 5-メチルシトシン (5mCpG) マークから、活性領域や不活性領域を同定 PacBio HiFi WGS バリアントパイプラインの技術概要 PacBio の WGS バリアントパイプラインは Workflow Description Language (WDL) で定義されており、二次解析と三次解析に向けたモジュール式かつコンテナ化されたソリューションを提供します。このパイプラインには、HiFi アライメントツールに加え、SNV、小規模な挿入・欠失、コピー数バリアント (CNV)、構造バリアント (SV) 向けに設計されたバリアントコーラーが組み込まれています。さらに、タンデムリピート (TR) のジェノタイピング、セグメント重複領域内の遺伝子の型判定 (遺伝子タイピング)、バリアントのハプロタイプへのフェージング、コンセンサス 5mCpG 確率の推定などの機能も備えています。マルチサンプルのコホートに対しては、小規模バリアントと構造バリアントの両方に対するジョイントコーリング (joint-calling) を提供します。包括的なアノテーションツールは、小規模バリアントと構造バリアントの両方に対応します。ヒト HiFi データを解析するステップは次のとおりです。 リードアライメント – HiFi リード向けに最適化されたマッパーおよびアライナーである pbmm2 を用いて、ロングリードをリファレンスゲノムにアライメントします。このアライナーはスプリットマッピングや大きなギャップを効率的に扱えるため、構造バリアントやセグメント重複を正確にマッピングするうえで重要です。出力は、下流処理向けの豊富なメタデータを含む、ソート済み・インデックス付きの Binary Alignment Map (BAM) ファイルです。 SNV と小規模バリアントのコール – SNV および小規模な挿入・欠失の検出には、HiFi リードに特化して学習させたバリアントコーラー ( DeepVariant ) を使用します。ロングリードデータのエラープロファイルとリード特性に合わせて調整された 機械学習 (ML) モデルを適用することで、マッピングが難しい領域でも偽陽性率の低い高信頼のバリアントコールを生成します。 構造バリアントの検出 – このステップでは、リードシグネチャとアライメントパターンを比較して、欠失、挿入、逆位、転座などの大規模なゲノム変化を同定します。PacBio の構造バリアントコーラー ( pbsv ) はロングリードデータ向けに設計されており、ショートリードのアプローチでは見落とされがちな複雑なブレークポイント、タンデムリピート、マルチアレリック (multi-allelic) なイベントを検出できます。 重複領域のバリアント – Paraphase は、遺伝子ファミリーのリードを単一のリファレンスコピーへ再アライメントしてハプロタイプを同定することで、セグメント重複領域における小規模バリアントをコールします。 タンデムリピートバリアントコーラー – Tandem repeat genotyping tool (TRGT) は、HiFi リードにおけるタンデムリピートの変動 (多型) を解析・ジェノタイピングします。リピート長 (サイズ) に基づく標準的なジェノタイピングに加えて、配列組成、リピートのモザイク性、CpG メチル化パターンの包括的な解析、そしてリピートをスパンするリードの視覚的表現も提供します。 フェージングとハプロタイプの決定 – 下流の解釈をサポートするため、ワークフローにはバリアントをハプロタイプに割り当てるフェージングステップが含まれています。 HiPhase は HiFi リードのロングレンジ情報を活用し、数十キロ塩基にわたるハプロタイプブロックを決定することで、臨床および集団ゲノミクスの文脈における解釈性を向上させます。 5mCpG 検出 – pb-CpG-tools は、アライメント済みの HiFi リードから、CpG に対するハプロタイプ特異的なサイトメチル化確率を生成します。 コホートレベルのジェノタイピング (任意) – 複数サンプルのコホートに対しては、 glnexus と pbsv を用いたジョイントジェノタイピング (joint-genotyping) のステップを追加することで、サンプル間のバリアントコールを整合させることができます。 アノテーション – パイプラインには 2 つのアノテーションツール、 slivar と svpack が含まれており、小規模バリアントと構造バリアントに対する包括的なアノテーションを提供します。 ワークフローは 7 つの主要なステップで構成されています (次のアーキテクチャ図の 1〜7 に対応)。 HiFi-WGS パイプラインを AWS CloudFormation にデプロイし、コンテナの移行をトリガーします。 AWS Lambda 関数が AWS CodeBuild をオーケストレーションし、コンテナ処理を行います。 未アライメントの BAM (unaligned BAM / uBAM) ファイルから Amazon Simple Storage Service (Amazon S3) への入力データフロー。 Amazon CloudWatch によるパイプライン実行のモニタリング。 Amazon EventBridge を用いたイベント駆動のワークフロー管理。 出力用 S3 バケットへの結果の保存。 HealthOmics ツールによるパフォーマンス分析で、コストと利用状況を追跡。 このサーバーレスかつマネージドなアーキテクチャは、運用可視性と最適化機能を備えた、スケーラブルかつコスト効率の高いゲノムデータ処理を提供します。 図 1: AWS HealthOmics WGS パイプラインのワークフローと統合ポイントを示すアーキテクチャ図 大規模運用における AWS HealthOmics 上の PacBio WGS バリアントパイプライン AWS HealthOmics は、パイプラインのデプロイと実行を管理し、インフラストラクチャ、コンテナオーケストレーション、WDL のサポートを担当します。各タスクはカスタマイズ可能なリソースを持つコンテナ化ジョブとして実行され、依存関係の管理、そして AWS Identity and Access Management (IAM) によって権限管理された Amazon S3 でのデータストレージを扱います。ワークフローの入力、出力、ログは、HealthOmics コンソールと Amazon CloudWatch を通じて追跡可能です。 AWS HealthOmics 上の WGS パイプラインのソリューションのデプロイは HiFi-human-WGS-WDL v2.1.2 に基づいており、ゲノム解析への無駄のないアプローチを提供します。CloudFormation ソリューションスタックのデプロイでは、Docker イメージの移行を自動化し、 Amazon Elastic Container Registry (Amazon ECR) のポリシーと HealthOmics ワークフロー用 IAM ロールを設定します。パイプラインは次のステップに従います。 aws-samples リポジトリ の CloudFormation テンプレートは、必要な Docker イメージを適切な権限とともに ECR のプライベートリポジトリへ移行する AWS スタックを構築します。このカスタマイズ可能なスタックは、HealthOmics サービスが必要とする S3 バケットと ECR イメージに対して、最小権限アクセスの原則に沿うよう調整できます。 スタックは Docker イメージの移行に CodeBuild を利用します。パイプライン操作を進める前に、CodeBuild プロジェクトが SUCCEEDED ステータスに達しているかを確認してください。 未アライメントの HiFi BAM ファイルは、Amazon S3 または HealthOmics シーケンスストア に保存します。どちらも互換性がありますが、HealthOmics シーケンスストアはゲノミクス固有の追加機能と、よりよいメタデータ管理を提供します。本実装では、PacBio の リファレンスデータリソース と、検証用の HG002 の公開 HiFi データセットを使用しています。 HiFi-human-WGS-WDL リポジトリをクローンし、Docker イメージが選択したパイプラインバージョンと一致することを確認します (テンプレートは v2.1.2 用に構成されています)。別のバージョンを使う場合は、CloudFormation テンプレート内のイメージハッシュ値を調整してください。バリアント解析パイプラインのワークフローパラメーターを作成するには、 aws-samples リポジトリで提供されているサンプルテンプレートを利用します。 HealthOmics は複数サンプルの並列処理を可能にします。マネージドサービスとして、実行の投入を処理し、通知や下流のパイプライントリガーのために Amazon EventBridge と統合します。Amazon EventBridge ルールの構成例 については、 AWS ブログ を参照してください。 HealthOmics ワークフローは、パイプラインの進捗モニタリングのために CloudWatch と統合されます。ワークフローログは CloudWatch ストリームで確認でき、出力用 S3 バケットへコピーされ、サンプル追跡のために実行 ID ごとに整理されます。 HealthOmics run_analyzer ツールは、サンプル単位で詳細なコストとリソース利用状況の知見を提供し、最適なインスタンスタイプを推奨します。本記事のベンチマーク結果はこれらの分析に基づいています。 aws-healthomics-tools は pypi 経由でインストールするか、後述の手順に従ってください。 HealthOmics プライベートワークフローで PacBio WGS バリアントパイプラインを作成・実行する方法 CloudFormation スタックは、PacBio WGS バリアントパイプライン解析に必要な Docker イメージの作成を自動化します。 PacBio WGS analysis with HealthOmics workflows に記載された手順に従ってください。PacBio WGS バリアントパイプラインのプライベートワークフローを作成する主な手順は次のとおりです。 PacBio リポジトリ から HiFi-human-WGS-WDL v2.1.2 リポジトリをダウンロードするか、 PacBio リポジトリ から任意のバージョンをダウンロードします。バージョンによっては、CloudFormation テンプレートの Docker パスを修正する必要があります。 CloudFormation デプロイの前提条件として、Lambda 関数が操作を実行するための AWS Key Management Service (AWS KMS) キーと、 Amazon Virtual Private Cloud (Amazon VPC) 接続内の 2 つの利用可能なパブリックサブネットを作成する必要があります。ポート 443 経由の HTTPS インバウンドトラフィックを許可する自己参照型のセキュリティグループを作成してください。 パイプラインの評価 実行完了後、 run_analyzer ツールを使用して計算利用状況とコストを評価します。 pip install aws-healthomics-tools aws-healthomics-tools run_analyzer <RUN_ID> -o Pacbio-WGS-run_analyser_outputs.csv エンドツーエンドのパイプライン HiFi 解析のベンチマーク結果 PacBio の公開データセットである HG002 HiFi データセットを用いて、米国東部 (バージニア北部) us-east-1 AWS リージョン における HealthOmics 上でさまざまな最適化戦略を検証しました。WGS バリアント解析パイプラインには、1 CPU から 64 CPU、最大 256 GB の RAM まで、リソース要求が幅広いタスクが含まれます。HealthOmics は計算リソースを動的にプロビジョニングします。最も負荷の高いタスクである DeepVariant によるバリアントコールは、HiFi リードでは 64 CPU と 239 GB RAM を必要とし、GPU アクセラレーションも利用可能です。本ベンチマークでは、タスクアクセラレーターによるコストパフォーマンス最適化と、パイプライン性能に対するストレージタイプの影響に焦点を当て、本番運用に最適な構成の確立を目指しました。 最も要求の高いタスクは、 pbmm2 によるリードアライメントと DeepVariant によるバリアントコールでした。DeepVariant の処理を、複数の GPU アクセラレーター (NVIDIA Tesla T4 (omics.g4)、NVIDIA Tesla A10G (omics.g5)、NVIDIA L4 (omics.g6)) で評価しました。これらは、静的および動的な HealthOmics の実行ストレージ (static / dynamic run storage) を用いた CPU ベースのアクセラレーション (omics.m) と比較してベンチマークしています。 最適な構成は NVIDIA Tesla A10G を搭載した omics.g5.2xlarge で、動的ファイルストレージを利用してパイプラインを 8.67 時間・21.26 ドルの計算コストで完了しました。DeepVariant 用の GPU コンテナは、CPU ベースの構成と比較して 21.3 パーセントのコスト削減と 8.5 パーセントの高速化を実現し、パフォーマンスとコスト効率の両面で明確なメリットを示しました。 ストレージ構成の分析では、NVIDIA Tesla T4 (omics.g4) と L4 (omics.g6) のインスタンスは動的ストレージから大きな恩恵を受ける一方で、標準的な omics インスタンスと Tesla A10G (omics.g5) インスタンスはストレージタイプ間の差がほとんどないことが分かりました。これは、ストレージ最適化戦略をインスタンスごとに検討すべきであることを示唆しています。 HealthOmics の run_analyzer ツールでは、Tesla A10G と静的ストレージの組み合わせで 19.15 ドルまでコスト最適化できる可能性が示されました。この分析により、いくつかのタスクでメモリ割り当てを最適化できる余地があることが明らかになりました。pbmm2 アライナーは 64 GB、DeepVariant の make_examples は 16 GB、pbsv_call は 16 GB、DeepVariant の postprocess_variants は 8 vCPU と 64 GB、hiphase は 32 GB で動作できます。ただし、これらの要件はシーケンシング深度や遺伝的多様性によって変動し得ることに注意が必要です。遺伝的多様性の高い集団では、リファレンスに対して相対的により多くのバリアントが検出される傾向があるためです。特にバリアント数に応じてスケールする場面では、PacBio のデフォルトの計算リソース要件が依然として必須となります。 次の棒グラフでは、分析結果を 3 つのパネルで示しています。実行時間 (時間)、実際のコスト (ドル)、そして run_analyzer の推奨事項を適用した後の最適コスト (ドル) です。NVIDIA Tesla A10G と静的ストレージの組み合わせは、19.15 ドルという最良の最適コストを示すと同時に、8.67 時間という競争力のあるランタイム性能も維持しています。この最適コストは、HealthOmics ツール run_analyzer が推奨する計算構成を用いることで達成可能です。 図 2: AWS HealthOmics 上の WGS バリアント解析パイプラインにおける、アクセラレーター種別とストレージ構成別の価格性能比較 AWS HealthOmics は、ゲノムデータに不可欠な堅牢なセキュリティフレームワークを提供し、HIPAA、GDPR、ISO 27001 などの規制に沿った包括的な対策を実装しています。これには、エンドツーエンドの暗号化、KMS キー、ロールベースのアクセス制御、セキュアなロギングと監査が含まれます。この高度なセキュリティアーキテクチャにより、組織はゲノム解析ワークフローをスケールさせながら、厳格なデータガバナンスとプライバシー基準を遵守できます。これにより、HealthOmics は規制要件を守りつつ、機密性の高いデータを大規模に扱うのに適したサービスとなっています。 まとめ 本分析では、PacBio の HiFi WGS バリアント解析パイプラインを AWS HealthOmics 上に実装し、パフォーマンスとコストの大幅な最適化を達成しました。GPU アクセラレーション、特に NVIDIA Tesla A10G (omics.g5.2xlarge) は、CPU ベースの構成と比較して 21.3 パーセントのコスト削減と 8.5 パーセント高速なパイプライン完了を実現しました。評価では、NVIDIA Tesla T4 と L4 のインスタンスは動的ストレージから恩恵を受け、Tesla A10G はストレージタイプにかかわらず安定した性能を維持することが分かりました。HealthOmics の run_analyzer ツールにより、適切なリソース割り当てを通じて、Tesla A10G と静的ストレージを組み合わせた 19.15 ドルの最適コスト構成を特定できました。HealthOmics のリソースを動的にプロビジョニングする能力と、HIPAA、GDPR、ISO 27001 に準拠した堅牢なセキュリティフレームワークが組み合わさることで、機密性の高いゲノムデータを大規模に処理するのに適しています。これらの知見は、厳格なデータガバナンスとプライバシー基準を維持しながら、効率的でセキュア、かつスケーラブルなゲノム解析ワークフローを実装するための貴重な指針となります。 始め方 PacBio HiFi データを大規模に解析するには、次を参照してください。 PacBio のオープンソース HiFi-human-WGS-WDL パイプライン を活用する AWS HealthOmics がどのようにセキュアかつスケーラブルなゲノム解析を実現するかを学ぶ サポートやカスタマイズされたワークショップのご依頼は、 AWS Genomics チームまでお問い合わせください 著者について Edwin Sandanaraj Edwin は AWS のゲノミクスソリューションアーキテクトです。神経腫瘍学で博士号を取得し、ヘルスケアゲノミクスのデータ管理と解析で 20 年を超える経験を持ち、アジア太平洋・日本地域における精密ゲノミクスの取り組みを加速するために豊富な知見を提供しています。臨床ゲノミクスとマルチオミクスをクラウドベースのソリューションで組み合わせ、精密医療を加速することに情熱を注いでいます。 Charlie Lee Charlie は AWS におけるアジア太平洋・日本地域のゲノミクス業界リードで、バイオインフォマティクスに軸足を置く計算機科学の博士号を持っています。バイオインフォマティクス、ゲノミクス、分子診断で 20 年以上の経験を持つ業界リーダーであり、最先端のシーケンシング技術とクラウドコンピューティングをゲノミクスに活用し、研究の加速とヘルスケアの改善に情熱を注いでいます。 Billy Rowell Billy は PacBio のシニアスタッフバイオインフォマティクスサイエンティストで、遺伝学とゲノミクスの研究に 25 年以上の経験を持っています。バリアントコールと希少疾患研究に向けた高性能計算 (HPC) およびマルチクラウドワークフローの開発をリードしています。 Khi Pin Chua Dr. Khi Pin は PacBio の計算生物学グループのサイエンティストです。彼の仕事は、PacBio の HiFi シーケンシングデータから新しい生物学的知見を引き出すための革新的なツールと解析ワークフローの開発に集中しています。PacBio の最先端のロングリードシーケンシング技術を、特にがんゲノミクスなどの分野で高度なゲノミクス応用に活用する研究者や臨床医の広いネットワークと協働しています。 Rajesh Sukumaran Rajesh は AWS のアジア太平洋・日本地域を担当する HealthTech (ヘルステクノロジー) のシニアパートナーマネージャーです。ヘルスケアとテクノロジーの分野で 20 年以上の経験を持ち、AWS パートナーと協働してヘルスケアの変革を推進するソリューションを提供しています。熱意あるヘルスケア起業家であり、コンピューターエンジニアでもある Rajesh は、INSEAD で MBA を取得しています。 翻訳は Solutions Architect の吉村が担当いたしました。

本記事は 2026 年 6 月 3 日に公開された Edwin Sandanaraj、Dr. Charlie Lee、Maruthi Alamuru による “ Accelerating life sciences research with Kiro: A unified AI interface to 100+ open source databases ” を翻訳したものです。 ライフサイエンス分野の研究者は、データ統合という根深い課題に直面しています。たとえば、体細胞変異を創薬可能な標的と結びつけるといった 1 つの調査だけでも、遺伝子のコンテキストを得るために National Center for Biotechnology Information (NCBI) 、臨床的意義を確認するために ClinVar 、タンパク質の機能を確認するために UniProt 、構造データを得るために Protein Data Bank (PDB) 、相互作用パートナーを確認するために STRING 、化合物の生物活性を確認するために ChEMBL に問い合わせる必要があるかもしれません。それぞれのデータベースには独自の API、認証方式、データ形式、レート制限があります。研究者は数十のブラウザタブを行き来しながらコンテキストを切り替えるか、API が変更されるたびに壊れるカスタムスクリプトを書くかを強いられているのが現状です。 本記事では、 Kiro for Life Sciences を紹介します。これは Kiro power パッケージ で、Kiro を 24 の科学分野にわたる 100 以上のデータベースを横断する統合研究インターフェースへと変貌させます。ポータルでもダッシュボードでもなく、研究者が自然言語で質問を投げると、権威ある情報源から直接引き出された構造化・相互参照された回答を得られる AI アシスト開発環境です。 データサイロが発見のスピードを鈍らせる BRCA1 のバリアントを研究する計算生物学者は、昨今、次のような作業を行う必要があるかもしれません。 NCBI Gene で基本的なアノテーションを検索する。 UniProt からアミノ酸配列を取得する。 ClinVar で病的バリアントを確認する。 PDB または AlphaFold で立体構造を調べる。 STRING で相互作用パートナーを探す。 疾患との関連を調べるために OMIM と相互参照する。 集団における頻度を確認するために gnomAD を調べる。 そのパスウェイを標的とする化合物を ChEMBL で検索する。 これで 1 つの遺伝子につき、8 つのデータベース、8 つの認証フロー、8 種類の結果フォーマットです。これがバリアントごと、プロジェクトごとに積み重なっていきます。認知負荷は非常に大きく、重要なクロスリファレンスを見落とすリスクも現実的な問題として存在します。 ソリューション概要: Kiro for Life Sciences Kiro for Life Sciences は、Kiro power とモジュラーな Model Context Protocol (MCP) サーバーを組み合わせたアーキテクチャを採用しています。中心となる power がハブとして機能し、オンボーディングダッシュボード、検索可能なリソースカタログ、認証情報マネージャー、ドメインスキル、ガイド付きワークフローを提供します。実際のデータベース接続は、独立してデプロイ・設定可能な 24 のドメイン特化 MCP サーバーが担当します。 このソリューションは、次の主要なアーキテクチャ設計判断に基づいて構築されています。 設計上のモジュール性 – 必要なサーバーだけをインストールできます。プロテオミクス研究室に生態学用サーバーは不要です。各サーバーは独立した Python パッケージとして提供されます。 認証情報の一元管理 – API キーは mcp.json に一度設定するだけです。認証情報マネージャーがトークンの更新、レート制限、エクスポネンシャルバックオフを用いたリトライロジックを処理します。 データベース横断検索 – 1 つの質問を投げるだけで、複数のデータベースから同時に回答を得られます。手動でのオーケストレーションは不要です。 カバー範囲の全体像 次の表は、各ドメインにおいてどのデータベースやツールがカバー範囲となっているかを示しています。 ドメイン データベースおよびツール ツール数 ゲノミクスおよびシーケンシング NCBI、Ensembl、ClinVar、gnomAD、 COSMIC 、 dbSNP 、 ENCODE 、 GEO 、 SRA 、 DDBJ 、 1000 Genomes 18 プロテオミクス UniProt、 InterPro 、STRING、PRIDE、 neXtProt 8 構造生物学 PDB、 AlphaFold DB 、 CATH 、 SCOP 6 臨床および製薬 OMIM、 DrugBank 、ChEMBL、 PharmGKB 、 OpenTargets 、 ClinicalTrials.gov 、 FDA FAERS 10 ケモインフォマティクス PubChem 、 ChemSpider 、 RDKit 、 SwissDock 8 免疫学 IEDB 、 ImmPort 、 IMGT 、 abYsis 4 微生物学およびメタゲノミクス SILVA 、 QIIME 2 、 MG-RAST 、 BV-BRC 、 CARD 8 パスウェイおよび相互作用 KEGG 、 Reactome 、 BioCyc 、 WikiPathways 、 IntAct 7 生態学および環境 GBIF 、 IUCN 、 iNaturalist 、 BOLD 、 MGnify 7 分子生物学 BLAST 、 Primer3 、 HMMER 、 REBASE 、 Clustal Omega 9 その他 14 以上のドメイン 神経科学、細胞生物学、メタボロミクス、エピゲノミクス、イメージング、農業、ヘルスケア、バイオバンキング、パイプライン、データ標準、AI/ML 50 以上 合計 100 以上のデータベースおよびツール 250 以上 仕組み このインターフェースは、1 つのクエリに対して複数のデータベースから回答を返すよう設計されています。使い始めるには、まず Kiro に次のように尋ねます。 TP53 を研究しています。UniProt から配列を取得し、PDB で実験的に決定された構造を探し、AlphaFold で予測構造を確認し、STRING から相互作用パートナーを取得し、InterPro からドメイン構造を表示してください。 Kiro は 5 つのデータベースへ並列にクエリを発行し、統合されたタンパク質プロファイルを返します。スクリプトを書く必要も、タブを切り替える必要も、フォーマットの調整も不要です。 データベース横断検索インテリジェンス データベース横断検索機能は、インストール済みの MCP サーバーに並列クエリをオーケストレーションし、結果の自動集約とグレースフルデグラデーションを行います。 検索タイプ 並列で問い合わせるデータベース gene NCBI Gene、UniProt、Ensembl、ClinVar、OMIM、Gene Ontology、KEGG、Reactome drug DrugBank、ChEMBL、PharmGKB、OpenTargets、PubChem、 HMDB 、CARD protein UniProt、PDB、AlphaFold DB、InterPro、STRING、neXtProt、 ESM species GBIF、IUCN Red List、BOLD、iNaturalist、NCBI Taxonomy、MGnify metabolite HMDB、MetaboLights、METLIN、MassBank、PubChem、KEGG cell_type CellxGene、Single Cell Expression Atlas、Cell Atlas、Allen Brain Atlas ガイド付きのマルチステップワークフロー power には 16 個の steering ファイルが含まれています。これらは、ワークスペースのファイルパターンに基づいて自動的に有効化される、段階的なワークフローガイドです。 バリアントコーリングパイプライン – AWS HealthOmics を通じて、体細胞または生殖細胞系列のバリアントコーリングをセットアップして実行します。 遺伝子と疾患の関連 – ClinVar を OMIM および HPO と相互参照し、バリアントから表現型までを網羅したマップを構築します。 化合物スクリーニング – PubChem で候補を検索し、RDKit で記述子を計算し、ZINC でフィルタリングした上で、分子ドッキングまで実施します。 プライマー設計とクローニング – Primer3 でプライマーを設計し、PrimerBLAST で特異性を検証し、制限酵素解析を行い、最終的なコンストラクトを構築します。 マイクロバイオーム解析 – SILVA を用いて分類群を割り当て、QIIME 2 で多様性を評価し、CARD で薬剤耐性遺伝子をプロファイリングします。 これらはドキュメントページではありません。Kiro が段階的に手順を辿って実行する実行可能ガイドであり、適切なツールを適切な順序で呼び出します。 ベストプラクティスを内包したドメインスキル 10 個のドメインスキルは、作業内容に応じて有効化されるコンテキスト対応のガイダンスを提供します。 バイオインフォマティクスファイル形式 – FASTA、FASTQ、BAM、VCF、GFF、BED の取り扱いパターン ゲノミクスパイプラインのベストプラクティス – 再現性のあるワークフローのための WDL、Nextflow、CWL の設計パターン データコンプライアンス – HIPAA、GDPR、GxP、MIAME、MINSEQE の要件 臨床インターオペラビリティ – FHIR、HL7、OMOP CDM の統合パターン ケモインフォマティクス – SMILES または InChI の取り扱い、Lipinski の法則、SAR 解析 パイプラインを書いているときには、Kiro は慣例を知っています。患者データを扱っているときには、コンプライアンス要件を知っています。 例: 1 セッションでバリアントから創薬標的まで 現実的な研究セッションはこのような形になります。研究者が質問を投げると、ツールが適切なデータベースから自動的に情報を引き出し、回答を返します。 ClinVar で EGFR の病的バリアントを検索してください : 臨床的意義付きのバリアント ID を返します。 PDB から EGFR のタンパク質構造を取得してください : 分解能と手法を含む 1M17 を返します。 ChEMBL における EGFR と薬剤の既知の相互作用を教えてください : 化合物の生物活性データを返します。 OpenTargets で EGFR の疾患関連を確認してください : がん種を横断したスコア付きの関連情報を返します。 このリード化合物の ADMET 特性を予測してください : 溶解度、BBB 透過性、CYP450 の予測を返します。 受容体 1M17 とこのリガンドの SMILES でドッキングジョブを投入してください : 結合親和性と相互作用する残基を返します。 研究者は 1 回の会話の中で 6 つのステップを踏み、6 つのデータベースを検索しました。コンテキストの切り替えも、フォーマット変換も、認証情報の切り替えも不要です。 何が違うのか Galaxy や UCSC Genome Browser のような Web ポータルは強力ですが、特定のドメインに特化しています。1 つのインターフェースで 24 の分野にまたがることはできません。Kiro for Life Sciences は、ライフサイエンスの全ドメインを横断する統合体験を、IDE の内部から直接利用できる形で提供します。 Biopython のようなスクリプトライブラリはプログラマティックなアクセスを提供しますが、データベースごとに統合コードを書き、メンテナンスする必要があります。Kiro が API 呼び出し、ページング、エラー処理、レート制限を処理するため、研究者は配管作業ではなくサイエンスに集中できます。 汎用の AI アシスタントは生物学について議論できますが、データベースに対してライブクエリを実行することはできません。Kiro は認証済みで構造化された API 呼び出しを行い、機械可読な結果、つまり訓練コーパスからの要約ではない実データを返します。 このソリューションが提供する独自の価値は、研究者が平易な言葉で質問を投げられる点にあります。Kiro が問い合わせるべきデータベースを判断し、並列で呼び出しを実行し、認証やリトライを処理し、統合された結果を、コードを書いたりパイプラインを実行したりデータを解析したりする環境と同じ場所で返します。 計算科学者のためのアーキテクチャ 各 MCP サーバーは、非同期 HTTP クライアント、エクスポネンシャルバックオフ、構造化されたエラー処理を備えた、独立した Python パッケージとして構築されています。共通の基盤パッケージである life-sciences-common が、すべてのサーバーが継承する HTTP クライアント、リトライロジック、エラー分類を提供するため、あらゆるドメインで一貫した挙動が保証されます。 サーバーは uvx を使って実行可能で、Docker コンテナやインフラストラクチャの管理は不要です。バンドルマニフェストは 24 のサーバーすべてを宣言的に記述しており、ステータスの確認やセットアップの構成を容易にします。Hypothesis を用いたプロパティベーステストが、エッジケースにも耐える堅牢性を提供し、予期せぬ入力に対してもツールが正しく動作するという安心感を与えます。 大規模な計算処理については、AWS HealthOmics 統合により、独自のクラスタインフラストラクチャを管理することなく、nf-core、WDL、CWL のパイプラインを実行できます。 このソリューションは、複数の分野の研究者に次のようなメリットをもたらします。 データベース API ごとにラッパースクリプトを保守しているバイオインフォマティシャンは、その定型コードを廃止し、統合レイヤーを Kiro に任せられます。複数のデータソースを横断して発見を相互参照する必要のある計算生物学者は、これまで 6 つものツールの出力をつなぎ合わせなければ実現できなかったことを、1 回の会話でこなせるようになります。 臨床研究者は、解析環境を離れることなくバリアントを疾患、そして薬剤へとマッピングできるため、調査の一連の流れを 1 か所に集約できます。タンパク質構造を調べたり、プライマーを設計したりしたい実験系の科学者は、もはやプログラマティックな API を学ぶ必要はなく、自然言語で尋ねるだけで済みます。 研究チームにとっては、データベースへの問い合わせを共有・再現可能なアプローチで行えることが、全員が同じツール群から作業できることを意味し、共同研究にありがちな「私のマシンでは動くのに」問題を軽減します。 導入手順 power をインストールし、対象ドメインの MCP サーバーを構成して、質問を始めるだけです。オンボーディングダッシュボードには、利用可能なもの、認証情報が必要なもの、すぐに使えるものが表示されます。 次のコードブロックは mcp.json の設定例です。 { "mcpServers": { "life-sciences-genomics": { "command": "uvx", "args": ["life-sciences-genomics"], "env": { "NCBI_API_KEY": "your-ncbi-api-key" } }, "life-sciences-proteomics": { "command": "uvx", "args": ["life-sciences-proteomics"] }, "life-sciences-structural": { "command": "uvx", "args": ["life-sciences-structural"] } } } 結果として、3 つのサーバーが構成され、1 つのチャットインターフェースから NCBI、Ensembl、ClinVar、UniProt、PDB、AlphaFold のほか、さらに十数個のデータベースへすでにクエリを実行できるようになっています。 まとめ ライフサイエンス研究が抱えているのは計算能力の問題ではなく、統合の問題です。データは何百ものデータベースにわたって存在しています。課題は、それらに効率的にアクセスし、正しく相互参照し、しかもプロジェクトごとにカスタムの統合レイヤーを構築せずに実現することです。 Kiro for Life Sciences は、1 つのインターフェース、一元化された認証情報、そして研究者が遺伝子からバリアント、構造、創薬標的、臨床試験まで、数日ではなく数分で辿り着ける 1 つの場所を提供することで、その統合コストを解消します。データベースは引き続き唯一の情報源であり、Kiro が唯一のアクセスポイントとなります。始めるには、24 の MCP サーバー、スキル、steering ファイル、設定例をすべて含む完全な power パッケージを GitHub でご覧ください。 著者について Edwin Sandanaraj Edwin は Amazon Web Services (AWS) のシニアソリューションアーキテクトです。神経腫瘍学の博士号を持ち、ヘルスケアゲノミクスのデータ管理と解析において 20 年以上の経験を持つ彼は、豊富な知識でアジアパシフィックおよび日本における精密ゲノム医療の取り組みの加速を支援しています。クラウドベースのソリューションを活用した個別化医療の推進を目的に、臨床ゲノミクスとマルチオミクスに強い関心を寄せています。 Dr. Charlie Lee Charlie Lee は AWS のアジアパシフィックおよび日本におけるゲノミクス業界リードで、バイオインフォマティクスを専門とするコンピューターサイエンスの博士号を持っています。バイオインフォマティクス、ゲノミクス、分子診断の分野で 20 年以上の経験を持つ業界リーダーであり、最先端のシーケンシング技術とクラウドコンピューティングによるゲノミクスを通じて、研究の加速とヘルスケアの向上に情熱を注いでいます。 Maruthi Alamuru Maruthi は AWS Healthcare and Life Sciences 業界担当のメンバーです。15 年以上にわたり、ライフサイエンスおよびヘルスケア企業が最先端テクノロジーと実世界の成果とのギャップを埋めるのを支援してきました。これにより企業は、創薬の加速、患者体験の再構築、そして生命を変える治療法や製品をこれまでにない速さで市場に届けることができるようになっています。 翻訳は Solutions Architect の吉村が担当いたしました。

2026 年 7 月 16 日（木）、 17 日（金）の 2 日間、東京・麻布台ヒルズにて、ISV SaaS 事業者向けの 8 社合同 AI-DLC Unicorn Gym を開催しました。株式会社サイバーセキュリティクラウド、freee 株式会社、株式会社いえらぶ GROUP、モビルス株式会社、エムオーテックス株式会社、株式会社ヌーラボ、テクマトリックス株式会社、株式会社ヴァル研究所（順不同・敬称略）の 8 社から計 54 名にご参加いただき、各チームが自社プロダクトの開発テーマを持ち込んで、Kiro や Claude Code などの Coding Agent を活用しながら 2 日間 AI 駆動の開発プロセスを実践しました。 本記事では、ご参加いただいた各社が 2 日間 AI-DLC をどう体験したのか、参加者の声を交えてレポートします。 AI-DLC (AI-Driven Development Lifecycle) とは AI 駆動開発ライフサイクル（AI-DLC）は、AWS が提唱する、AI を開発プロセスの中心に据えた開発手法です。AI を単なるアシスタントとして使うのではなく、要件定義・設計・実装の主役を AI が担い、人間は「何を作るか」「その出力は正しいか」という意図のすり合わせと重要な判断に集中します。この役割分担により、従来は数ヶ月かかっていた要件定義から実装までの期間を数日に圧縮することを目指します。 AI-DLC の開発プロセスは Inception・Construction・Operations の 3 フェーズで構成されます。鍵となるのが、チーム全員で 1 つの画面を囲み、AI と対話しながら進める「モブワーク」というスタイルです。一人が操作役（ドライバー）となって手を動かし、残りのメンバー全員がその場で意見を出し合い、議論しながら進めます。Inception を全員で行うフェーズを「モブエラボレーション」、Construction をサブチームに分かれて進めるフェーズを「モブコンストラクション」と呼び、いずれもこのモブワークを基本形とします。AI が要件を整理し、選択肢やコードを素早く提示し、ビジネス・開発メンバーがその場で検証・判断する。この共同作業が、開発速度の向上だけでなく、ビジネスと開発のギャップを埋め、チーム全員の認識を揃える効果をもたらします。 AI-DLC の詳細については、 AI 駆動開発ライフサイクル：ソフトウェアエンジニアリングの再構築 をご参照ください。 AI-DLC Unicorn Gym 開催の背景と ISV SaaS 8 社が持ち込んだテーマ AI-DLC Unicorn Gym は、AI-DLC を座学ではなく自社の実テーマで実践していただくプログラムです。各チームが実際の開発テーマを持ち込み、AI と対話しながらユーザーストーリーの作成から実装、成果発表までを 2 日間で走り切ることで、AI 駆動の開発プロセスによる効果を体感していただきます。 今回の AI-DLC Unicorn Gym は、ISV SaaS 事業者を対象とした複数社合同の形式で開催しました。AI-DLC Unicorn Gym 開催のご要望を多くいただいておりますが、複数日にわたって数十名の参加者を集めることがハードルとなり実施を断念されるケースもありました。複数社合同とすることで、各社 1 チームからの参加を可能にしました。 参加各社には、練習用の題材ではなく「自社の実際のプロダクト開発テーマ」をご用意いただきました。テーマは、既存プロダクトへの新機能追加、既存ページのリニューアル・モダナイズ、新規プロダクトの立ち上げ、業務プロセスの改善支援など多岐にわたりました。 2 日間のスケジュール 本イベントは、初日に Inception、2 日目に Construction を中心に据えた 2 日間の構成で実施しました。各日ともチーム全員が 1 つの画面を囲むモブ形式で進め、初日の終わりに中間報告会、2 日目の終わりに最終報告会を設けています。タイムスケジュールは目安であり、各チームの進捗状況に合わせて進めていただきました。 今回は AI-DLC の進行には Coding Agent 用のルールセットである aidlc-workflows をご利用いただきました。aidlc-workflows v2 が 7月に GA しましたので、詳しく知りたい方は AI-DLC Workflows 2.0 のご紹介 および AI-DLC Workflow V1からV2へ：人間のボトルネックを解消する設計の進化 をご確認ください。 Day 1 9:30　キックオフ / AI-DLC Introduction 10:00　aidlc-workflows EC サイト構築ハンズオン 11:30　昼食 12:30　Mob Elaboration（Inception）: 開発対象のスコープやユーザーストーリー、作業単位の精緻化 17:15　中間報告会（1 日目の進捗状況を共有） Day 2 9:30　Mob Elaboration / Mob Construction :ドメインモデル設計、アーキテクチャコンポーネントの追加、プログラムやテストの作成 11:30　昼食 12:30　Mob Construction（各チームの進捗に応じて） 17:00　最終報告会（成果・学びの共有） 18:00　懇親会 Day 1: Inception 初日の午後から、各チームが自分たちのテーマをユーザーストーリーへ分解する「モブエラボレーション」に取り組みました。チーム全員が 1 つの画面を囲み、AI と対話しながら要件を詳細化します。ビジネスメンバーも開発メンバーも同じ場で AI の提案を検証し、判断し、修正していきます。このプロセスを通じてチーム全員のコンテキストが揃い、その共通認識が Construction フェーズにそのまま引き継がれます。AWS からは、「5 分以上 AI を遊ばせない」、「HTML/CSS でモックを作りチームのイメージを合わせる」、「How に関する議論は Construction まで我慢する」などのガイドを提供しました。 複数のチームから、 「仕様を決める速さで AI-DLC の力を実感した」 「圧倒的に早いスピード感で一定動くものを作れたのは大きな発見」 といった、要件定義のスピード向上に関する感想をいただきました。 株式会社いえらぶ GROUP の開発風景 Day 2: Construction 2 日目は、並行して実装できるサブチームに分かれて Construction を進め、最終報告会へ臨みます。AI が高速にコードを生成するなか、参加者はその方向性が適切かを検証・判断しました。 2 日間という短い時間ながら、8 チーム中 6 社がデモ可能な状態まで実装を完了しました。設計フェーズでの AI 活用に対して、 設計での AI という使い方で、よくできたフレームワーク。次回の新機能開発はこれで実施する。 といった手応えを語るチームもありました。 最終発表会では、「従来 1 ヶ月以上かかっていた要件定義フェーズが2日間で完了した」、「ジュニアメンバーが AI との対話を通じてドメイン知識へのキャッチアップを実現した」、といった成果の共有がおこなわれました。 参加者からのフィードバック 今回は参加者の方には AWS オフィスにお集まりいただき、各社様担当の営業メンバー・ソリューションアーキテクトがサポートをさせていただきました。モブワークという形式について、いくつものフィードバックをいただきました。 我々のチームのことをよく知るサポーターが、過度でもなく過小でもなく、適切なタイミングで声掛けしてもらえた 普段リモートワークなので、オフラインで一緒に開発できてよかった。フレームワークのおかげで会話が整理された。 また、ドキュメント作成やコーディングを高速にこなす AI に対して高頻度で意思決定・判断が求められることについて、 判断負荷が高いので、普段の業務時間だと後回しにしてしまいそう。集中して向き合えてよかった という感想もいただきました。モデルの進歩により AI の自律性が高まる中、どこまでを人間が判断し、どこまでを AI に委ねるかはまさに今注目されている観点です。 イベント後のアンケートでは、80 % の参加者から最高点の ︎5 評価をいただきました。「AI-DLC はあなたの働き方を変える可能性があるか」という問いに対しても平均 4.76 / 5.0 というご回答をいただきました。また平均工数削減率は 67.1%と、これまでの 3 倍の速度を実現できると体感していただきました。 おわりに AI がコードを書いてくれるようになると、人間の仕事は「書くこと」から「決めること」へと移っていきます。何を作るか (あるいは作らないか) を決めること、設計の方向性を判断すること、チーム間の認識を揃えること。AI-DLC がモブワークを重視するのは、この意思決定に集中できる環境を作るためです。 自社で AI-DLC を試してみたいという方は、まず aidlc-workflows をお試しください。Kiro や Claude Code などを使って AI-DLC を始めるためのワークフローやテンプレートが公開されています。AI-DLC は特定のツール・ワークフローに依存しない方法論です。皆様のこれまでの開発プロセスや組織構造、スキルセットなどによってカスタマイズして取り入れていただくことができます。 自社プロダクトを持つ ISV/SaaS 事業者にとって、AI-DLC はプロダクトの開発サイクルそのものを変えうる手法です。合同開催が「終わり」ではなく、それぞれの現場での「始まり」として受け止めていただき、この 2 日間の体験を各社の現場に持ち帰り、それぞれの形で活かしていただけることを楽しみにしています。 これまでの合同型 AI-DLC Unicorn Gym については以下のブログ記事もご覧ください。 11 社合同 AI-DLC Unicorn Gym で体験した開発のパラダイムシフト 9 社合同 AI-DLC Unicorn Gym 大阪 ── AI と開発した 3 日間で見えた、人間の仕事 9 社合同 AI-DLC Unicorn Gym：AI と作った 2 日間で見えた、 「書く」から「決める」への転換 筆者について 山崎 宏紀 (Hiroki Yamazaki) 山崎宏紀 は Amazon Web Services Japan G.K. のソリューションアーキテクトとして、ISV/SaaS 業界のお客様を中心にアーキテクチャ設計や構築、生成 AI の活用・AI エージェントの開発をご支援しています。Kiro CLI や AWS CDK を好みます。(より良いご支援のために) AI エージェントに代わりに働いてもらおうと画策しています。

2026 年 8 月 3 日週、私たちは世界中から集まった AWS ヒーローたちを集め 、つながり、協力し、AWS コミュニティでこれまで以上に活躍したビルダーを祝いました。 AWS Heroes Summit は招待制の年次集会で、AI、サーバーレス、コンテナなどの分野を専門とする世界中の専門家が一堂に会し、社内の AWS 製品およびサービスチームとの直接のコラボレーション、技術的な詳細調査、フィードバックセッションを行います。 1日目は、AWS の CEO、マット・ガーマンによる心に響く暖炉辺談話から始まります。2 日目の James Hamilton との洞察に満ちた AMA から、新しいアイデアを呼び起こすさまざまな製品チームによるブレイクアウトセッションまで、AWS ヒーローたちは知識を共有し、お互いを高め、会話をコラボレーションに変えることに長けていました。詳細については、 LinkedIn で参加者からのフィードバックをご覧ください 。 8 月 3 日週のリリース 私が注目したリリースをいくつかご紹介します。 Amazon Bedrock でのウェブ検索 ：Amazon Bedrock では、OpenAIモデル (GPT-5.4、GPT-5.5、GPT-5.6 Sol/Terra/Luna) がインターネットから情報を閲覧したり取得したりできるようになりました。これにより、AIアプリケーションはトレーニングデータ以外の最新情報にアクセスできるようになりました。この機能により、リアルタイムのウェブコンテンツを使用して質問に回答できる AI エージェントとアプリケーションを構築する新たな可能性が開かれます。また、データの流出は発生せず、安全な AWS 環境内にデータを保存できます。開始するには、 AI ブログ投稿 および Amazon Bedrock ユーザーガイド をご覧ください。 Amazon Bedrock AgentCore のランタイムインスタンス ：Amazon Bedrock AgentCore を介して専用のランタイムインスタンスに AI エージェントをデプロイして実行できるようになりました。これにより、パフォーマンスとコストを予測可能な状態でエージェント実行環境をより細かく制御できるようになりました。開始するには、 Sébastien のブログ投稿 および AgentCore documentation をご覧ください。 Amazon DynamoDB のベクトル検索 ：個別のベクトルデータベースを管理しなくても、ベクトル埋め込みを既存のデータと一緒に DynamoDB に保存してクエリできます。DynamoDB はすでに AI エージェントのメモリ保存をサポートしていますが、ベクトル検索では、そのメモリにセマンティック検索を追加してエージェントのグラウンディングを行うことができ、パフォーマンスも予測可能です。詳細については、 Esra のブログ投稿 および Amazon DynamoDB開発者ガイド をご覧ください。 AWS Transform の継続的なモダナイズが一般提供開始 :この機能は、エンジニアリングチームがソースコードリポジトリ全体の技術的負債を大規模に分析して修正するのに役立ちます。メインフレームとレガシーワークロードは、1 回限りの移行イベントではなく、継続的かつ自動化されたアプローチでモダナイズできます。詳細については、 Micah のプレビューブログ投稿をご覧ください 。 AWS Transform Kiro パワーとエージェントプラグインを試すこともできます 。 最大 3,000 Mbps の AWS Lambda 関数帯域幅 ：AWS Lambda 関数は増加したネットワーク帯域幅をサポートするようになり、データ集約型のワークロードと Lambda 関数と他の AWS サービス間の高速通信が可能になりました。この機能により、2 GB 以上のメモリで構成されている VPC 外部の機能でも、2 GB で 625 Mbps から 10 GB で 3,000 Mbps まで、比例してスケーリングされるネットワーク帯域幅にアクセスできます。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース 興味深いと思われるその他のニュース項目をいくつかご紹介いたします。 Dogwood の紹介：AI エージェント向けのランタイム検証 ：AWS は Dogwood をオープンソース化しました。これは、AI エージェントが Cedar ポリシーをサポートし、時間的条件を追加するための専用ガバナンス言語です。Dogwood を支える Amazon Bedrock AgentCore では、現在のリクエストだけでなく、 セッション中のエージェントのアクションの履歴に基づいて決定されるテンポラルポリシーが導入されました 。 AWS によるエージェントプラグインのサポート:ポータブルエージェント拡張のオープンスタンダード ：AWS は、エージェントプラグインのサポートを発表しました。これは AI エージェント拡張機能に共通のパッケージ形式を提供するオープンソースのベンダー中立仕様であり、拡張機能を一度パッケージ化すれば、Kiro、VS Code、Cursor、またはこの仕様を実装する任意のツールを含む任意のクライアントに配布できます。 Kiro Crew のご紹介 ：Kiro Crewは、オンラインでもオフラインでも作業を円滑に進め、Kiro IDE 内での共同マルチエージェント開発ワークフローを可能にする、永続的で自己進化型のワークスペースです。1 回のチャットセッションにとどまらず、リポジトリ、ツール、日数にわたるエンジニアリング作業向けに構築されています。複数の作業を並行して実行することも、レポートを返すサブエージェントに作業を引き継ぐこともできるので、列に並ぶ必要はありません。 AWS のブログ記事一覧については、 AWS ブログ ページをご確認ください。 AWS の詳細について学び、今後予定されている AWS 主催の対面イベントやバーチャルイベント 、 スタートアップイベント 、 開発者向けイベント 、 AWS Summits や AWS Community Days を閲覧して、ご参加ください。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 8 月 10 日週のニュースは以上です。8 月 17 日週に再びアクセスして、新たな1週間のまとめをぜひお読みください! — Channy 原文は こちら です。

本記事は 2026 年 8 月 12 日 に公開された「 Introducing Oracle Exadata on Exascale for Oracle AI Database@AWS 」を翻訳したものです。 Oracle AI Database@AWS 向けに Oracle Exadata Database Service on Exascale Infrastructure (ExaDB-XS) が一般提供開始となりました。ExaDB-XS は、従量課金モデルで Exadata クラスのパフォーマンスと可用性を提供します。コンピューティングとストレージを小さな単位で個別にスケールでき、使用した分だけを支払います。専用インフラストラクチャを事前にプロビジョニングする必要はありません。AWS Marketplace のパブリックオファーまたはプライベートオファーで、最小 8 Elastic CPU (ECPU)、ストレージ 300 GB から始められます。 Oracle AI Database@AWS では、AWS アベイラビリティゾーン内で Oracle Exadata インフラストラクチャをネイティブに実行できます。AWS Marketplace から購入し、他のワークロードと並べて管理できます。Oracle Exadata や RAC のワークロードを再アーキテクチャなしで移行し、Oracle データベース資産を統合して、AWS の分析、AI、運用サービスに直接接続できます。データベースが AWS リージョン内で動作するため、AWS の幅広いサービスに低レイテンシーでアクセスできます。生成 AI と検索拡張生成 (RAG) には Amazon Bedrock、モニタリングとガバナンスには Amazon CloudWatch、AWS KMS、AWS IAM、AWS CloudTrail を利用できます。 お客様からは、専用インフラストラクチャのコストとコミットメントという壁なしに Exadata の機能を使いたいという声が寄せられていました。専用インフラストラクチャでは、開始時にデータベースサーバー 2 台とストレージサーバー 3 台が最低構成として必要で、初期投資は決して小さくなく、すべてのワークロードに見合うわけではありません。ExaDB-XS はこのコストとコミットメントの壁に直接応えます。RAC、Smart Scan、Hybrid Columnar Compression (HCC) を含む Exadata と同じパフォーマンス、可用性、セキュリティを、プールされた共有モデルで提供します。ECPU 単位、ギガバイト単位という小さな増分でスケールし、コンピューティングとストレージを個別に追加できます。大規模な初期インフラストラクチャのコミットメントなしに始めたい場合、新しい AWS リージョンへコスト効率よく拡張したい場合、容量効率の高い 高速なデータベースクローニング を活用したい場合、Exadata Database Service on Dedicated (ExaDB-D) のクロスリージョン災害対策スタンバイをコスト効率よく運用したい場合に適しています。 Oracle AI Database@AWS ポートフォリオにおける ExaDB-XS の位置づけ ExaDB-XS は Oracle AI Database@AWS ポートフォリオをあらゆる規模のワークロードに広げ、専用インフラストラクチャの下に空いていた領域を埋めます。同一の Exadata ハードウェア上で、Oracle のデプロイメント選択肢が一通り揃いました。 サービス モデル お客様にとってのメリット ExaDB-XS (新規) — Exadata on Exascale Infrastructure 共有・プール型の Exadata コンピューティングとストレージ上で、お客様が管理する VM クラスター コミットメントが必要な最低構成インフラストラクチャなしに、Exadata のパフォーマンスと機能をフルに利用できる OS とデータベースの制御は ExaDB-D と同じなので、移行時も勝手が変わらない 従量課金 — 小さく始めて、コンピューティングとストレージを個別にスケールし、使用した分だけ支払う Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D) 専用 Exadata インフラストラクチャ上で、お客様が管理する VM クラスター 最大規模かつ最も要求の厳しいワークロードに向けた Exadata のパフォーマンスとシングルテナント分離 OS とデータベースをフルに制御し、必要なとおりに Oracle を運用できる パッチ適用とバージョン更新のタイミングを自社で管理し、変更管理を完全にコントロールできる Oracle Autonomous AI Database on Dedicated Exadata (ADB-D) 専用 Exadata インフラストラクチャ上のフルオートノマスデータベース 専用環境による分離と最小の運用工数 — パッチ適用、チューニング、スケーリングは Oracle がオートノマス機能で処理 日々の DBA 作業から解放され、アプリケーションに集中できる メンテナンスウィンドウは自社のビジネスカレンダーに合わせて制御できる Oracle Autonomous AI Database Serverless (ADB-S) フルオートノマス、サーバーレス、マルチテナント フルマネージドかつサーバーレスで、運用負荷は最小限。オートノマス機能を備える エラスティックなサーバーレススケーリングで、使用した分だけ支払う 管理するインフラストラクチャをゼロにしたい場合に最適 ExaDB-XS では、共有・プール型インフラストラクチャ上で ExaDB-D と同等の制御性とデータベース管理の使い勝手が得られます。Exadata の価値を支える機能を諦めることなく、小規模ワークロードまでスケールダウンできる Exadata の経済性を利用できます。 ExaDB-XS の新機能 ExaDB-XS は、Oracle Cloud Infrastructure (OCI) で利用できる Oracle Exascale の全機能と、Oracle AI Database@AWS がサポートする AWS 統合をリリース時点から備えています。つまり初日から本番ワークロードを ExaDB-XS に移行でき、最も重要な Oracle データベースに求められるセキュリティ、運用、コンプライアンスの機能もそのまま利用できます。以下の 3 つのセクションでは、ExaDB-XS が Oracle AI Database@AWS に追加する主な新機能を説明します。 コンピューティングとストレージのエラスティックなスケーリング ExaDB-XS はインフラストラクチャレベルでコンピューティングとストレージを分離します。まず、Exadata インテリジェントストレージを共有する単一の論理プール、Exascale Storage Vault をプロビジョニングします。次に 1 つ以上の VM クラスターをプロビジョニングし、Exadata のデータベース最適化コンピューティングの共有プールからコンピューティングを、Storage Vault からストレージを割り当てます。専用デプロイメントで使う Automatic Storage Management (ASM) ディスクグループとは異なり、Storage Vault は自動的にスケールし、オブジェクト単位で高冗長性を自動適用するため、ディスクグループの設計や容量分割は不要です。1 つの Storage Vault が複数の VM クラスターに対応できるので、ストレージはコンピューティング間で共有しつつ、ワークロード間の分離は保たれます。 コンピューティングは ECPU、ストレージは GB を単位とします。VM クラスターは 8 ECPU、ストレージ 300 GB から開始でき、その後はワークロードの変化に応じて各項目を個別に調整できます。スケーリングは AWS マネジメントコンソール、AWS Command Line Interface (AWS CLI)、AWS API から実行できます。 即時シンクローニング ExaDB-XS では、Oracle AI Database@AWS でシンクローニングが使えるようになります。redirect-on-write 技術により、ストレージを複製せずにデータベースの即時コピーを作成できます。クローンを作成すると、Storage Vault 内の元のデータブロックへのポインタが作られます。クローンは完全に独立したデータベースとして見え、そのように動作しますが、作成直後は追加のストレージを消費しません。ストレージを消費するのは、クローン内のデータがソースから変化した分だけです。シンクローニングは、読み取り/書き込みデータベース、読み取り専用データベース、プライマリおよびスタンバイデータベース、プラガブルデータベース、さらには既存クローンのクローンでも機能します。 本番データに対して 10 本の開発ブランチを並行して動かすチームは、フルコピー 10 個分ではなく、データベース 10 個分の変更量に対して支払います。自動化された継続的インテグレーション/継続的デリバリー (CI/CD) パイプラインの一部として新しいデータベースクローンをプロビジョニングし、テスト完了後に破棄することもできます。 初日から使える AWS サービス統合と AI 対応 ExaDB-XS は、Oracle AI Database@AWS で利用できる AWS サービス統合をリリース時点からすべて備えています。データベースの自動バックアップは Amazon Simple Storage Service (Amazon S3) に保存されます。AWS KMS がカスタマー管理キーによる暗号化を担います。Amazon CloudWatch と Amazon EventBridge がメトリクスとイベントのモニタリングを提供します。AWS IAM がアクセスを制御し、AWS CloudTrail が API 監査ログを記録します。ネットワーク接続の選択肢には AWS Transit Gateway、Amazon VPC Lattice、AWS Cloud WAN があります。ExaDB-XS は AWS Secrets Manager とも統合されており、作成/更新操作時にデータベースと Oracle Database Vault のパスワードをマネージドシークレットから安全に渡せます。機密性の高い認証情報をスクリプトや設定ファイルに置く必要がなくなります。 ExaDB-XS では、次世代の AI アプリケーションやエージェント型アプリケーションの中心に Oracle データベースを据えられます。Oracle AI Database 26ai では、AI Smart Scan が AI Vector Search を Exadata インテリジェントストレージにオフロードします。ベクトル検索と検索拡張生成 (RAG) は、分析やオンライントランザクション処理 (OLTP) を高速化するのと同じストレージ側のインテリジェンスを使い、運用データ上で動作します。データベースが AWS リージョン内で動作するため、生成 AI やエージェント向けの Amazon Bedrock、Amazon Bedrock AgentCore といったサービスをすぐ隣で利用できます。AI エージェントやアプリケーションは、最も価値あるビジネスデータを移動も複製もせずに低レイテンシーで利用できます。 ExaDB-XS を使い始める ExaDB-XS は AWS Marketplace から、セルフサービス調達のパブリックオファーまたは個別交渉のプライベートオファーで利用できます。License Included (全オプション付きの Oracle Enterprise Edition) と Bring Your Own License (BYOL) の両方に対応しています。以下では AWS マネジメントコンソールで最初の ExaDB-XS 環境を作成する手順を説明します。AWS CLI と CloudFormation の手順は Oracle AI Database@AWS のドキュメントを参照してください。 ステップ 1: ODB ネットワークを作成する Oracle AI Database@AWS を初めて使う場合は、まず ODB ネットワークを作成します。ODB ネットワークは、AWS アベイラビリティゾーン内で Oracle インフラストラクチャをホストするプライベートで分離されたネットワークです。AWS マネジメントコンソールで Oracle AI Database@AWS に移動し、[ODB Networks]、[Create ODB network] の順に選択します。アベイラビリティゾーン、クライアント接続とバックアップ接続用の Classless Inter-Domain Routing (CIDR) 範囲を指定し、必要に応じて Amazon S3 バックアップと Amazon Redshift ゼロ ETL 接続をネットワーク上で設定します。既存の Exadata Dedicated デプロイメントの ODB ネットワークがある場合は、その同じネットワークに ExaDB-XS リソースをプロビジョニングできます。 図 1: クライアントサブネットとバックアップサブネットの範囲を指定して ODB ネットワークを作成する 図 2: ODB ネットワークのサービス統合を設定する ステップ 2: Exascale Storage Vault を作成する Storage Vault は、VM クラスターが容量を割り当てて使うプール型ストレージリソースです。コンソールで [Exascale Storage Vaults] に移動し、[Create Storage Vault] を選択します。初期ストレージ容量を GB で指定し、Storage Vault を ODB ネットワークに関連付けます。作成後はいつでも容量を拡張できます。 図 3: Exascale Storage Vault を作成しストレージ容量を設定する ステップ 3: Exascale VM クラスターを作成する Storage Vault を用意したら、[VM Clusters] に移動して [Create VM Cluster]、[Exascale] の順に選択し、VM クラスターを作成します。ECPU 数 (VM あたり最小 8)、GB 単位のストレージ割り当て (合計最小 300 GB)、Oracle Database のバージョン (19c または 26ai)、ライセンスタイプを指定します。あわせて ODB ネットワークを選択し、VM へのアクセスに使う Secure Shell (SSH) キーペアを指定します。 図 4: Exascale VM クラスターの一般設定と構成を確認する 図 5: 作成前に VM クラスターの接続設定と診断設定を確認する ステップ 4: Oracle データベースを作成する VM クラスターの準備ができたら、AWS マネジメントコンソールで VM クラスターの詳細ページに移動し、[Manage in OCI] を選択します。OCI コンソールが開き、そこで Oracle データベースを作成、管理します。Oracle Database のバージョンを選択し、Amazon S3 バケットへの自動バックアップを設定して、データベースを作成します。インフラストラクチャリソース (Storage Vault、VM クラスター、ODB ネットワーク) は AWS マネジメントコンソールと AWS API の両方から引き続き参照、管理できます。 図 6: OCI コンソールで VM クラスターから Oracle データベースを作成する 料金 ExaDB-XS の料金は従量課金です。VM クラスターが消費した ECPU とストレージに対して支払い、最低インフラストラクチャコミットメントはなく、1 秒あたりの I/O 操作数 (IOPS) への個別課金もありません。License Included と Bring Your Own License の両方が利用できます。料金は OCI 上の Oracle Exadata Database Service on Exascale Infrastructure と同じです。最新の単価は Oracle AI Database@AWS の料金ページ を参照してください。 知っておきたいこと 提供リージョン。 ExaDB-XS は、Oracle AI Database@AWS が利用可能な 22 の AWS リージョンすべてで利用できます。米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、米国西部 (北カリフォルニア)、カナダ (中部)、南米 (サンパウロ)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (ミラノ)、欧州 (パリ)、欧州 (スペイン)、欧州 (ストックホルム)、欧州 (チューリッヒ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (ムンバイ)、アジアパシフィック (大阪)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (東京)、オーストラリア (メルボルン)、オーストラリア (シドニー) です。 Storage Vault の容量。 Exascale Storage Vault は 1 つあたり最大 100 TB のインテリジェントストレージに対応します。それ以上の専用容量が必要な場合は、同じ ODB ネットワーク内で Oracle Exadata Database Service on Dedicated Infrastructure も併用できます。 データベースバージョン。 リリース時点では Oracle Database 19c と 26ai をサポートしています。対応バージョンは今後追加していく予定です。 モニタリング。 ExaDB-XS のリソースは AWS/ODB 名前空間で Amazon CloudWatch にメトリクスを発行します。AWS CloudTrail は API 呼び出しを記録します。Amazon EventBridge のルールを設定して、プロビジョニング完了、パッチ適用、スケーリング操作といったデータベースのライフサイクルイベントに対する自動応答をトリガーできます。 今日から始める ExaDB-XS は、世界中の Oracle AI Database@AWS 対応 22 リージョンすべてで本日から利用できます。 Oracle AI Database@AWS のサービスページ を確認するか、AWS マネジメントコンソールで Oracle AI Database@AWS に移動し、 [Create Storage Vault] を選択して始めてください。 詳細は Oracle AI Database@AWS ドキュメントの Exascale セクション、または以下のリソースを参照してください。 Oracle AI Database@AWS ドキュメント Oracle Exadata on Exascale ドキュメント (OCI) Oracle AI Database@AWS の料金 著者について Karthik Gopalakrishnan Amazon Web Services のシニアプロダクトマネージャーです。Oracle AI Database@AWS のプロダクトマネジメントを担当しています。 Jobin Joseph Jobin はトロントを拠点とするシニアデータベーススペシャリストソリューションアーキテクトです。リレーショナルデータベースエンジンを専門とし、お客様のデータベースワークロードの AWS への移行とモダナイゼーションを支援しています。Oracle Certified Master であり、Oracle データベースの経験は 25 年以上に及びます。 この記事は Solutions Architect の 矢木 覚が翻訳しました。

本記事は 2026 年 7 月 23 日 に公開された「 Evaluating AI Agents: A production blueprint with Strands and AgentCore 」を翻訳したものです。 本記事は、Motorway および AWS Prototyping and AI Customer Engineering (PACE) チームと共同で執筆しました。 英国を拠点とするオンライン中古車マーケットプレイスの Motorway は、最大 8,000 のディーラーが最大 2,500 台の車両に入札する日次オークションを運営しています。Motorway は AWS Prototyping and AI Customer Engineering (PACE) と協力し、AI を活用したディーラー向け在庫検索エージェントを構築しました。このエージェントによって、ディーラーの車両の探し方は大きく変わり、何時間もかかっていた手作業のフィルタリングが自然言語での問い合わせに置き換わりました。 課題 エージェントは自信ありげな応答を返します。しかし、実際のお金がかかっている状況で、それが確実に機能すると、どうやって証明すればよいのでしょうか。 ツール選択の誤り は誤った検索結果を招き、ディーラーの信頼を損ないます。 セマンティック検索の誤解釈 は、無関係な結果を返します。「5 年落ちまでのガソリン車、ハイブリッド車、電気自動車」のような問い合わせでは、エージェントが複数の条件を正しく解釈する必要があります。 複数ターンの会話での コンテキストのずれ は、ディーラーが絞り込んだ条件を失わせます。 非決定的な出力 は、1 回だけのテストを信頼できないものにします。 解決策 Motorway と AWS は共同で、エンドツーエンドの評価パイプラインを構築しました。その結果、誤った結果は 8 件に 1 件から 50 件に 1 件へと減り、問題の検知にかかる時間は数時間から数分に短縮されました。 このパイプラインは、Strands Agents SDK と Amazon Bedrock AgentCore を組み合わせています。AgentCore は、AI エージェントを大規模にデプロイして運用するためのフルマネージドサービスです。本記事では、自分のエージェント向けにこのパイプラインを構築する方法を紹介します。 2 段階の評価戦略 。ビルド時のテスト (Strands Agents 向けのオープンソース評価ライブラリ strands-agents-evals を使用) と、本番環境での監視 ( Amazon Bedrock AgentCore Evaluations を使用) にまたがります。 ツールの使い方、推論、出力品質を評価する 3 層のフレームワーク 。 品質ゲートを備えた 5 段階のデプロイパイプライン 。指標がしきい値を下回るとリリースをブロックします。 付属のリポジトリ には、自分のエージェントに合わせて調整できる、デプロイ可能な設計図が含まれています。この設計図は AWS のサービスを使っていますが、その中核となる原則は、本番運用に耐える AI エージェントであればどのようなシステムでも必要となる、システムに依存しない要件です。原則には、3 層の評価フレームワークと、一貫性を測る pass^k 指標の利用が含まれます。 前提条件 本記事の手順を進めるには、次の前提条件を満たす必要があります。 Amazon Bedrock 、 AWS Lambda 、 Amazon Simple Storage Service (Amazon S3) 、 Amazon DynamoDB 、 Amazon EventBridge 、 Amazon CloudWatch 、 Amazon Simple Notification Service (Amazon SNS) の権限を持つ AWS アカウント 。 インストールおよびブートストラップ済みの AWS Cloud Development Kit (AWS CDK) v2。 Python 3.14 以降。 Amazon Bedrock のモデルアクセス を通じた、Anthropic Claude モデルと Amazon Titan モデルへのアクセス。 Python、AWS CDK、およびエージェントの概念 (ツール呼び出し、複数ターンの会話) に関する知識。 所要時間: 初回デプロイに 30〜45 分、自分のドメインに合わせたカスタマイズに 2〜3 時間。 想定コスト: サンプルの評価スイートの実行には、Amazon Bedrock の推論料金として約 5〜10 USD かかります。本番環境の監視コストは、サンプリングレートによって変わります。 セキュリティに関する注記: 付属のリポジトリは、最小権限の AWS Identity and Access Management (IAM) ロールを実装し、API キーを (環境変数ではなく) AWS Systems Manager Parameter Store に保存し、型付きパラメータを使ってインジェクション攻撃を防ぎやすくしています。詳細は リポジトリの README を参照してください。 実例: ディーラー向け在庫検索エージェント Motorway は、ディーラー向け在庫検索エージェントを Strands Agents SDK と Amazon Bedrock AgentCore の上に構築しました。このエージェントは 8 つのツールを公開しており、89 を超える車両属性にわたる構造化フィルタリングと、 LanceDB および Amazon Titan Text Embeddings V2 によるベクトル類似検索を組み合わせています。 これまでディーラーは、CSV と融通の利かないフィルターを使って、何時間もかけて在庫リストを見て回っていました。対話型の AI エージェントの導入により、ディーラーはエージェントに話しかけられるようになりました。たとえば「近くのディーラーにある 2 万 5,000 ポンド以下のディーゼル SUV を探して」や「家族向けのスポーティなオートマ車」のように問いかけます。 ピーク時には約 1,500 人が同時に利用するため、エージェントの挙動を正しくすることは避けて通れません。ツール選択の誤りやセマンティック検索の誤解釈は、ユーザーの信頼に直接影響します。図 1 は、エンドツーエンドのリクエストの流れを示しています。ディーラーは Web インターフェイスから自然言語の問い合わせを送信し、それが Amazon Bedrock AgentCore Runtime にルーティングされます。ランタイムは、Amazon Bedrock のモデル (推論には Claude、埋め込みには Amazon Titan) を使いながら、8 つの異なるツールへの呼び出しを調整します。ツールからの応答はランタイムを経由して戻り、ディーラーに提示する最終的な結果を生成します。 エージェントの評価が異なる理由 大規模言語モデル (LLM) の評価は、テキスト生成の品質、つまり一貫性、事実の正確さ、応答の関連性に注目します。一方、エージェントの評価は、それとは根本的に異なるものを見ます。こう考えるとわかりやすいでしょう。LLM の評価はエンジンの性能を調べるものです。エージェントの評価は、渋滞のなか、雨のなか、あるいは後部座席が乗客でいっぱいのときに、車全体がどう走るかを見るものです。 従来の LLM の指標では、Motorway のエージェントが「グレード 1 の Suzuki のモデル」に対して正しい検索ツールを呼び出したかどうかはわかりません。エージェントが LanceDB に正しいフィルターパラメータを渡したかどうかも明らかになりません。さらに、前のターンの結果を絞り込むディーラーが正しい応答を得られたかどうかも見落とします。 評価の観点 エージェントにとって重要な理由 タスクの完了 エージェントは複数ステップのワークフローを実行し、部分的な完了がよく起こる ツール使用の正確さ 誤ったツールや不正なパラメータは、ワークフロー全体を狂わせる 推論の一貫性 推論に欠陥があると、条件が変わったときに予測できない失敗につながる 信頼性と一貫性 非決定性により、同じ入力でも異なる結果が生じうる 安全性とコンプライアンス 自律的なエージェントは、現実に影響を与える行動をとりうる コストと効率 1 タスクあたり 50 回の API 呼び出しを要するエージェントは、経済的に成り立たないことがある 「7〜12 年落ちの Volkswagen Golf」のような正確な問い合わせは完璧に動くかもしれません。しかし、「古めの VW を探している」のような口語的な言い回しは、セマンティック検索の層が適切に評価されていないと失敗することがあります。 strands-agents-evals でデプロイ前に問題を検出する この設計図は、 GenAIOps のライフサイクルに対応する 2 つのフェーズで評価を実装します。ビルド時の評価はデプロイ前に問題を検出し、本番環境での評価は合成テストが見落とすものを捉えます。次の図 (図 2) は、ツールの使い方、推論、出力品質の各層が、デプロイ前にすべて合格しなければならないことを示しています。このフレームワークは、エージェントを 3 つの層で評価します。 レイヤー 1 (ツールの使い方) は、正しいツール選択とパラメータの受け渡しを、95% 超のしきい値で検証します。 レイヤー 2 (推論) は、論理的な意思決定を、85% 超のしきい値で評価します。 レイヤー 3 (出力品質) は、応答の有用性と正確さを、90% 超のしきい値で測定します。デプロイを進めるには、3 つの層すべてが合格する必要があります。 開発時、および継続的インテグレーションと継続的デプロイ (CI/CD) の際、パイプラインは strands-agents-evals フレームワークを使ってデプロイ前に問題を検出します。このフレームワークは、出力の検証、軌跡 (trajectory) の評価、複数ターンの会話のシミュレーション、実験の自動生成を提供します。いずれも、Strands Agents SDK 上に構築されたエージェントとネイティブに連携するよう設計されています。フレームワークは、3 つの基本要素 (プリミティブ) を提供します。 Experiment : エージェントに対して実行するテストケースの集まり。 Case : 入力の問い合わせ、期待される出力、期待されるツールの軌跡。 Evaluator : 採点ロジック (決定的、または LLM ベース)。 テストは層に分けて構成します。レイヤー 1 では、ツール選択の正確さを測る決定的なコードベースの採点器を実行します。レイヤー 2 と 3 では、推論と出力品質のために LLM-as-judge の評価器 (LLM を使ってエージェントの出力を採点する方式) を使います。 独自の Evaluator サブクラスは、ドメイン固有の関心事に対応します。Motorway のエージェントの場合、データの鮮度、ディーラー単位のスコープ、安全性のガードレールをカバーします。あなたのエージェントには、それ独自のドメイン制約があるはずです。 3 種類の採点器 評価フレームワークは 3 種類の採点器を使い、それぞれ異なる評価ニーズに適しています。 採点器の種類 レイヤー 測定する対象 トレードオフ コードベースの決定的採点 レイヤー 1 ツール選択、パラメータの受け渡し、軌跡の順序 高速、低コスト、再現可能 LLM-as-judge (Claude Sonnet 4.6) レイヤー 2〜3 推論の品質、出力の有用性、目標の達成 柔軟だが非決定的 (pass^k で制御) 人によるレビュー キャリブレーション エッジケースと安全性 コストが高く、LLM 判定のプロンプトの調整に使う 実際には、エージェントがたどった経路を採点するよりも、エージェントが生成した結果を採点する方が、多くの問題を見つけられます。重要なのは、ユーザーが関連性の高い結果を得られたことであって、エージェントが最初にどのツールを呼び出したかではありません。 3 層の評価フレームワーク ビルド時の評価は、3 つの異なる層で動作し、それぞれに固有の合否しきい値があります。 レイヤー 1: ツールの使い方 (しきい値 95% 超)。 エージェントは正しいツールを、正しいパラメータで呼び出したか。 「7,000〜20,000 ポンドのディーゼル車」は、型付きフィルター ( fuel_type=diesel 、 min_price=7000 、 max_price=20000 ) を指定して search_vehicles を使うべきです。 「走行距離の少ない新しめのハッチバック」は、セマンティックな埋め込みと構造化フィルターを組み合わせた hybrid_search を呼び出すべきです。 これは決定的に測定できます。 ToolSelectionGrader がどのツールを呼び出したかを確認し、 TrajectoryOrderGrader が呼び出しの順序を検証します。 レイヤー 2: 推論 (しきい値 85% 超)。 意思決定のプロセスは論理的だったか。strands-agents-evals の HelpfulnessEvaluator と TrajectoryEvaluator は、LLM-as-judge による採点を使い、エージェントの推論が筋の通ったものかを評価します。論理的でない推論で正しい応答にたどり着くエージェントは、条件が変わると予測できない形で失敗します。 レイヤー 3: 出力品質 (しきい値 90% 超)。 応答は有用で、正確で、実行に移せるものだったか。strands-agents-evals の OutputEvaluator と GoalSuccessRateEvaluator は、LLM-as-judge による評価を使い、ユーザーが有用で整った形式の応答を得られたかを評価します。 3 つの層は、デプロイ前にすべて合格する必要があります。いずれかの層で失敗すると、パイプラインはブロックされます。 非決定性への対処 LLM の出力は実行のたびに変わるため、1 回だけの試行の結果は誤解を招くことがあります。付属リポジトリの run_all_layers() 関数は、これに対処するために num_trials パラメータを受け取ります。コード生成の研究コミュニティ発の 2 つの指標が、信頼性の測定に役立ちます。 pass@k は、k 回の試行で少なくとも 1 回成功する見込みを測ります。正しい解を 1 つ見つければ十分な場合に役立つ指標です。 pass^k (pass の k 乗) は、k 回連続で成功する確率を測ります。ユーザーが毎回信頼できる挙動を期待する場合に役立つ指標です。 顧客向けのエージェントでは、pass^k が最も重要です。1 試行あたりの成功率が 75% のエージェントは、3 回連続で合格する確率がわずか 42% (0.75³) しかありません。ユーザーは、やり取りのたびに一定の品質を期待します。 付属のコードでは、 run_all_layers(task_fn, registry, num_trials=5) が複数試行に対応して評価の各層を実行し、pass^k でデプロイをゲートします。 実装の全体 を参照してください。 テストケースの管理 テストケースはカテゴリ別に整理します。 ハッピーパス : 成功するはずの一般的な問い合わせ。 エッジケース : 曖昧な問い合わせ、スラング、複数ターンでの絞り込み。 安全性/ガードレール : エージェントが拒否または誘導し直すべき問い合わせ。 本番環境の監視で問題を検出すると、そのやり取りが新しいテストケースになります。Motorway のスイートは、当初の 50 ケースから 3 か月で 150 ケースに増え、いずれも実際のユーザーの行動に基づいています。まずは 20〜50 ケースから始め、本番データでスイートを育てていきましょう。 エージェントが特定のツールを呼び出す べきでない ネガティブケースも含めます。たとえば、プロフィールの問い合わせは、検索ツールではなくプロフィールツールを呼び出すべきです。構造化された問い合わせは、生の SQL へのフォールバックではなく構造化検索を使うべきです。一方向だけの評価は、一方向だけの最適化を生みます。 複数ターンの会話のテスト 単一ターンの評価は、重要な観点、すなわち会話の一貫性を見落とします。ディーラーは、複数のターンにわたって自然に検索を絞り込んでいきます。 ターン 1: 「ディーゼルの SUV を探して」 ターン 2: 「次は、オートマだけを見せて」 ターン 3: 「かわりにステーションワゴンはどう?」 strands-agents-evals フレームワークは、現実的な複数ターンのやり取りを生成する ActorSimulator と、ターンをまたいだコンテキストの保持を採点する InteractionsEvaluator  を提供します。複数ターンのテストは、単一ターンのテストが見落とす、コンテキストのずれ、フィルターの累積エラー、代名詞の解決の失敗を捉えます。 AgentCore Evaluations で本番環境の挙動を監視する Strands Agent を Amazon Bedrock AgentCore Runtime にデプロイすると、 AgentCore Evaluations が継続的な監視を提供します。OpenTelemetry の計装 (業界標準の可観測性フレームワーク) を通じて Strands Agents と統合します。図 3 は本番環境でのアーキテクチャを示しており、可観測性のトレースは 1〜5% でサンプリングされ、指標は Amazon CloudWatch に集約されます。 2 つの監視アプローチ AgentCore Evaluations は、互いに補完し合う 2 つのモードを提供します。 オンデマンド評価 は、Amazon CloudWatch のログからスパンを選択して、特定のエージェントのやり取りを分析します。問題のデバッグや修正の検証に役立ちます。 オンライン評価 は、稼働中のトラフィックを自動的にサンプリングし、バックグラウンドで評価器を適用します。サンプリングレートを設定し (1〜5% を推奨)、最大 10 個の評価器を選んで、あとは実行させておきます。 組み込みの評価器とカスタム評価器 AgentCore は、一般的なシナリオ向けにあらかじめ構成された評価器を提供します。次の表は、組み込みの評価器と、それぞれが測定する対象を示しています。 評価器 レベル 測定する対象 Builtin.Helpfulness TRACE エージェントの応答がどれだけ有用か (7 段階で 0〜1 のスコア) Builtin.GoalSuccessRate SESSION ユーザーの全体的な目標が達成されたかどうか Builtin.ToolSelection TOOL_CALL エージェントが適切なツールを選択したかどうか Builtin.Correctness TRACE 応答の事実としての正確さ ドメイン固有の要件には、LLM-as-a-judge の構成を使ってカスタム評価器を作成できます。どのエージェントにも、組み込みの評価器がカバーしないドメイン制約があります。たとえば、データの鮮度、アクセスのスコープ、禁止された行動、レイテンシーの予算、コストの上限などです。 付属のリポジトリには、調整して使える 5 つのカスタム Evaluator サブクラスが含まれています。 評価器 検証する対象 DataFreshnessEvaluator オークションサイクルのタイムスタンプを検証し、エージェントが古い在庫を提示しないようにする SafetyGuardrailEvaluator エージェントが自動入札の操作を試みるのをブロックする DealerDataScopingEvaluator データ分離のために、ディーラー単位にスコープされた問い合わせを強制する LatencyEvaluator と CostEvaluator の例は、 付属のリポジトリ を参照してください。 追跡すべき主要な指標 付属のリポジトリには、CloudWatch のダッシュボードとアラームをプロビジョニングする AWS CDK スタックが含まれています。エージェントの健全性を監視するために、次の指標を追跡してください。 指標 目標 アラートのしきい値 タスク完了率 >95% <80% ツール選択の正確さ >95% <90% 有用性スコア (0〜1) >0.83 <0.58 応答レイテンシー P50 / P99 <2s / <10s >5s / >15s ハルシネーション率 <2% >5% やり取りあたりのコスト 傾向を監視 ベースラインの 2 倍超 品質チェックをデプロイのゲートにする 評価は、後回しにするものではなく、デプロイパイプラインの品質ゲートにすべきです。図 4 は、評価ゲートを備えたデプロイパイプラインを示しており、ビルド時の評価、ステージングでの検証、シャドウモード、A/B テスト、本番環境へのロールアウトにまたがります。失敗するとデプロイはブロックされます。 デプロイパイプラインは、5 つのフェーズで進みます。 ビルド時の評価 : ユニットテスト、ツールの正確さ ( ToolSelectionGrader 95% 超)、軌跡のテスト、LLM-as-judge による採点 ( HelpfulnessEvaluator 85% 超)。 ステージングでの検証 : ステージングデータに対する合成トラフィックを使った、オンデマンドの AgentCore 評価。 シャドウモード : 実際の本番トラフィックを、ユーザーに影響を与えずに並行して処理します。2% の乖離しきい値を設定し、少なくとも 4 時間実行します。 A/B テスト : 稼働中のトラフィックの 5% を候補のエージェントにルーティングし、実際の結果を測定します。 本番環境へのロールアウト : 継続的なオンライン評価と監視のもとで、トラフィックの 100% を移行します。 各フェーズにしきい値を定義します。ツール選択の正確さが 95% を下回るか、タスク完了率が 80% を下回ると、デプロイはブロックされます。大きなリリースでは、 num_trials=5 による複数試行の評価が pass^k でゲートし、非決定的な失敗を捉えます。 シャドウモード ステージングと本番環境の間で、候補のエージェントを、ユーザーに影響を与えずに実際の問い合わせに対して実行します。 シャドウモード は、本番トラフィックの複製を受け取り、候補のエージェントで並行して処理し、結果を比較します。A/B テストに進む前に、シャドウモードを少なくとも 4 時間実行してください。デプロイを自動的に一時停止する乖離しきい値 (2% が良い出発点です) を定義します。 シャドウモードは、ほかの段階が見落とす問題を捉えます。 同時負荷のもとでのタイムアウト処理。 合成テストに含まれていないドメイン用語。 実際のトラフィックパターンのもとでレイテンシーの急増を引き起こす、ツール呼び出しの順序。 始め方: 段階的なアプローチ フェーズ 1: テストスイートを作る。 実際のユーザーの問い合わせから抜き出した 20〜50 個のテストケースから始めます。ポジティブケースとネガティブケースの両方を含めます。エージェントが行うべきことと、拒否すべきことの両方をテストします。 フェーズ 2: ビルド時の評価を構成する。 採点器の種類を、測定する対象に合わせます。ツール選択には決定的な採点を、推論と出力品質には LLM-as-judge を使います。 フェーズ 3: 本番環境の監視を有効にする。 AgentCore Evaluations を 1〜5% のサンプリングレートで構成します。低めから始め、評価器のコストが許容範囲だと確認できたら引き上げます。 フェーズ 4: フィードバックループを閉じる。 本番環境の失敗をテストケースに変えます。失敗がリグレッションテストになると、このフィードバックループは、複数のチームで一貫して評価品質を高めてきました。 成果とインパクト この評価パイプラインを導入する前、エージェントのツール選択の正確さは 87% でした。つまり、ディーラーの問い合わせ 8 件に 1 件は誤った結果を返していたことになります。本番環境のインシデントは月に 12 件発生しており、ディーラーに影響が出始めてから問題を検知するまで、平均 4 時間かかっていました。 パイプラインを導入した後の結果は次の通りです。 指標 導入前 導入後 ツール選択の正確さ 87% 98% タスク完了率 82% 96% コンテキストの保持 (複数ターン) 71% 94% 本番環境のインシデント (月次) 12 2 問題検知までの平均時間 数時間 数分 ビジネス面のインパクトとして、ディーラーは車両の検索を数時間ではなく数分で完了できるようになり、結果が正確で最新であるという確信も得られています。 トラブルシューティング 軌跡の採点器の失敗、LLM-as-judge のばらつき、評価結果が空になる問題、コストしきい値の調整など、よくある問題の解決策は、 付属リポジトリの README を参照してください。 重要なポイント 評価パイプラインを構築するときは、次の原則を念頭に置いてください。 評価を層に分ける : ツールの使い方 (95% 超)、推論 (85% 超)、出力品質 (90% 超) は、それぞれ異なる失敗パターンを捉えます。 単一試行ではなく pass^k でゲートする : 1 試行あたりの成功率が 75% でも、3 回連続では信頼性が 42% しかありません。 本番環境の失敗をテストケースに変える : 実際のユーザーの行動で評価スイートを育てましょう。 シャドウモードは合成テストが見落とすものを捉える : 実際のトラフィックは、タイムアウト処理、まれな用語、レイテンシーのパターンを明らかにします。 監視は 1% のサンプリングから始める : 評価器のコストを管理するために、少しずつ拡大します。 まとめ ここまで、Motorway のディーラー向け在庫検索エージェントを実例として、AWS 上で本番運用の AI エージェント向けの評価パイプラインを構築する方法を見てきました。 核心となる教訓は、流暢な応答は、エージェントが正しいことをした証拠にはならないということです。ツールの選択、パラメータの正しさ、推論の一貫性、そして繰り返し実行したときの安定性を検証する必要があります。strands-agents-evals によるビルド時のテストと、AgentCore Evaluations による本番環境の監視を組み合わせることで、エージェントが設計通りに動くという裏付けを持ってデプロイできます。 これらのパターンは、複数のツールを使う顧客向けエージェントの多くに当てはまります。ナレッジベースやチケットシステムに問い合わせるカスタマーサービスのエージェント、ポートフォリオデータや市場フィードを取り込む金融アドバイザリーのエージェント、患者記録やスケジュール調整ツールにアクセスするヘルスケアのトリアージエージェントなど、いずれにも適用できます。 まずは次の手順から始めます。 付属のリポジトリをクローンします。 git clone https://github.com/aws-samples/sample-evaluating-agents-on-aws-with-strands-and-agentcore CDK プロジェクトのディレクトリに移動します。 cd sample-evaluating-agents-on-aws-with-strands-and-agentcore/examples/vehicle-auction-agent/cdk サンプルのインフラをデプロイします。 リポジトリの README のデプロイ手順 に従って、サンプルのインフラをデプロイします。デプロイが完了したら、AWS CloudFormation コンソールですべての AWS CloudFormation スタックが CREATE_COMPLETE の状態になっていることを確認し、インフラを検証します。CloudWatch のダッシュボードと Lambda 関数が、それぞれのコンソールに表示されているはずです。 サンプルの評価スイートを実行します。 付属のテストケースに対して実行し、3 層のフレームワークが動く様子を確認します。成功したかどうかは、レイヤー 1 (ツールの使い方) の合格率が 95% 超、レイヤー 2 (推論) が 85% 超、レイヤー 3 (出力品質) が 90% 超になっていることで確認します。いずれかの層が失敗した場合は、CloudWatch のログで詳細なエラーメッセージを確認してください。 評価器を自分のドメインに合わせてカスタマイズします。 DataFreshnessEvaluator と SafetyGuardrailEvaluator をテンプレートとして始めます。 さらに深く知るには、 Amazon Bedrock AgentCore のドキュメント と、GitHub 上の Strands Agents SDK を調べてみてください。 リソースのクリーンアップ 継続的な課金を避けるために、このチュートリアルで作成したリソースを削除します。 CDK プロジェクトのディレクトリに移動します。 cd sample-evaluating-agents-on-aws-with-strands-and-agentcore/examples/vehicle-auction-agent/cdk デプロイしたすべてのスタックを削除します。 cdk destroy --all プロンプトが表示されたら、削除を確定します。 AWS マネジメントコンソールで、Lambda 関数、S3 バケット、DynamoDB テーブル、CloudWatch のロググループとダッシュボード、EventBridge のルール、SNS トピックを含むすべてのリソースが、クリーンアップ処理で削除されたことを確認します。 注意: オブジェクトが入っている S3 バケットは、手動での削除が必要な場合があります。保持したい評価データやログがある場合は、クリーンアップを実行する前にエクスポートしてください。 参考資料 Evaluating AI agents for production: A practical guide to Strands Evals 。 Strands Agents SDK 。 strands-agents-evals 。 Amazon Bedrock AgentCore Evaluations 。 Evaluating AI agents: Real-world lessons from Amazon 。 著者について Amit Deol Amit は、AWS Prototyping and Cloud Engineering (PACE) のシニアプロトタイピングアーキテクトです。AWS のお客様と協力して新しいアイデアを試し、生成 AI、データ分析、リアルタイムストリーミングにわたる本番運用対応のソリューションを構築しています。プロトタイピングをしていないときは、森の中を長く散歩している姿が見られます。 Hin Yee Liu Hin Yee は、AWS のシニアプロトタイプエンゲージメントマネージャーです。AI のプロトタイプから本番運用までの道のりを速める顧客エンゲージメントを率い、チームが AWS 上で生成 AI ワークロードを構築・運用するためのベストプラクティスを取り入れられるよう支援しています。 Ryan Cormack Ryan は、Motorway のプリンシパルエンジニアであり、AWS Community Builder です。ディーラー向けの AI 活用ツールの開発を率いており、AWS Summit London で Motorway のエージェント型 AI の採用について講演しました。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。

本記事は 2026 年 8 月 10 日 に公開された「 Configure AWS Advanced JDBC Wrapper connection pooling with the assistant 」を翻訳したものです。 本記事では、Amazon Aurora および Amazon Relational Database Service 上で AWS Advanced JDBC Wrapper のコネクションプーリングを設定する方法を紹介します。ラッパーの外部プーリングと内部プーリングの違い、選択基準、JDBC-WRAPPER-CONFIGURATION-ASSISTANT による設定構築の方法も解説します。 AWS Advanced JDBC Wrapper は、コミュニティ JDBC (Java Database Connectivity) ドライバーの上に配置されるラッパーで、ドライバーを置き換えることなく Amazon Aurora、Amazon Relational Database Service (Amazon RDS)、AWS クラウドの機能を追加します。アプリケーションと実際のドライバーの間に単一のレイヤーを挿入し、すべての JDBC 呼び出しをインターセプトして Amazon Aurora や Amazon RDS 向けの機能を提供します。既存の SQL コードやツールを変更せずに、高速フェイルオーバー、Enhanced Failure Monitoring (EFM)、IAM 認証、リード/ライトスプリッティングなどの機能をプラグインとして有効化・無効化できます。 プラグインベースのアーキテクチャ ラッパーのすべての機能はプラグインとしてパッケージ化されており、各 JDBC 呼び出しはプラグインチェーンを通過してから実際のドライバーに到達します。以下の図は、アプリケーションが connection.prepareStatement(...) のような JDBC メソッドを呼び出したときの動作を示しています。 図 1: JDBC メソッド呼び出しがラッパーのプラグインチェーンを通過してコミュニティドライバーに到達する流れ 設計上の重要なポイントをいくつか紹介します。 コネクションごとに専用のインスタンス : 各 Connection オブジェクトは、固有のプラグインマネージャー、プラグインサービス、プラグインインスタンスを保持します。 サブスクリプションベースの実行 : プラグインは getSubscribedMethods() を通じて関心のある JDBC メソッドのみをサブスクライブします。関心のないメソッドはチェーンをバイパスしてドライバーに直接渡されるため、オーバーヘッドを最小限に抑えられます。 チェーンの末端は常に DefaultConnectionPlugin : このプラグインが実際のコネクション作成を担当し、 ConnectionProvider が呼び出されるポイントです。コネクションプーリングはここでフックされます。 デフォルトで有効なプラグインは initialConnection 、 auroraConnectionTracker 、 failover2 、 efm2 です。これら以外にも、リード/ライトスプリッティング、AWS Identity and Access Management (IAM) 認証、AWS Secrets Manager、Blue/Green デプロイメント、Limitless など、さまざまなプラグインが用意されています。 コネクションプーリングとは データベースへの新しいコネクションの確立にはコストがかかります。TCP ハンドシェイク、TLS ネゴシエーション、認証、セッション初期化などを含めると、1 つのコネクションで数十～数百ミリ秒かかることがあります。リクエストごとに新しいコネクションを開閉すれば、毎回同じコストが発生します。 コネクションプールは、あらかじめ一定数のコネクションを作成して再利用する技術です。アプリケーションはプールからコネクションを「借り」、使い終わったらクローズする代わりにプールに「返却」します。返却されたコネクションは物理的にはクローズされず、次のリクエストで再利用されます。以下の図は、アプリケーションがプールからコネクションを借りて使用後に返却する流れを示しています。 図 2: アプリケーションがプールからコネクションを借りて返却する仕組み コネクションプーリングのメリット リクエストごとに新しいコネクションを開くのではなく再利用することで、次のようなメリットが得られます。 レイテンシの低減: コネクション確立コストがなくなり、リクエストのレスポンスタイムが改善します。 スループットの向上: コネクション作成に消費されていた CPU やネットワークリソースを、実際のクエリ処理に使えるようになります。 リソース保護と上限制御: コネクションはサーバー上のメモリと CPU を消費するため、インスタンスが維持できるコネクション数には限りがあります。オープンなコネクション数を制限してデータベースの過負荷を防ぎます。 負荷の平滑化: トラフィックスパイク時でもプールサイズが上限として機能し、データベースへの負荷を安定させます。 コネクション状態の管理: アイドルタイムアウト、最大ライフタイム、ヘルスチェック (バリデーション) によって無効なコネクションが除外されます。 ラッパーにおける外部プーリングと内部プーリングの動作 ラッパーのプーリングを理解するカギは、プラグインチェーンのどちら側にプールが位置するかです。以下の図は、外部プールと内部プールのプラグインチェーンに対する位置を示しています。 図 3: プラグインチェーンに対する外部プールと内部プールの配置 外部プーリング プールの起動時に N 個のラッパーコネクションが作成されます。各ラッパーコネクションは、専用のプラグインマネージャーとプラグインサービスを持つ完全な論理コネクションです。 アプリケーションがプールからコネクションを借りると、1 つの ConnectionWrapper を受け取ります。 その上で実行されるすべてのクエリはプラグインチェーンを通過し、実際のドライバーに転送されます。 アプリケーションが処理を完了してコネクションをクローズしても、物理的にはクローズされません。 ConnectionWrapper がプールに戻り、次の借り出しで再利用されるため、同じ論理コネクションが複数のリクエストにまたがって存続します。 フェイルオーバーが発生すると、ラッパーは同じ ConnectionWrapper 内で基盤となる物理コネクションを新しいインスタンスに再接続し、フェイルオーバー例外を発生させます。プールが保持するラッパーオブジェクト自体は変わらず、即座に再利用可能です。ただしプール側は例外しか認識しないため、例外をキャッチしつつコネクションを破棄せず、ラッパーが再接続済みのコネクションをそのまま保持するようプールに指示する必要があります。 フェイルオーバー例外を適切に処理してください。コネクションを無条件に破棄してはいけません。 08S02 (トランザクション外でのフェイルオーバー成功) では同じコネクションが再接続済みで再利用可能です。ラッパーはデフォルトで追跡中のセッション状態 ( autoCommit 、 readOnly 、 isolation など) を新しいコネクションに転送する ( transferSessionStateOnSwitch=true ) ため、最後のステートメントを再実行すれば済みます (実行中の処理はロールバックされます)。 08007 (トランザクション内での失敗) の場合も同様にしたうえで、トランザクション全体をやり直してください。コミット状態が不明なためです。 08001 (フェイルオーバー失敗) の場合のみコネクションが真に使用不可となるため、破棄して新しいものを開いてください。これらを汎用の SQLException としてキャッチし、 finally/catch ブロックでコネクションをクローズするのが、高速フェイルオーバーを無効にしてしまう典型的なミスです。 内部プーリング プールの分割方法。ラッパーは内部的に複数のコネクションプールを保持し、「接続先のインスタンス」と「接続ユーザー」の両方で区別します。デフォルト設定では、接続先インスタンスのアドレスとユーザー名を組み合わせてプールを分離します。同じインスタンスでもユーザーが異なれば別のプールになり、同じユーザーでもインスタンスが異なれば別のプールになります。実質的に、インスタンスとユーザーの組み合わせごとに 1 つのプールが作成されます。 コネクションの貸し出し方法。アプリケーションがコネクションを要求すると、ラッパーは毎回新しい物理コネクションを作成するのではなく、該当する組み合わせのプールを探します。プールが存在すればアイドルコネクションを取り出して貸し出し、存在しなければ新規作成してからコネクションを渡します。使用後にクローズされたコネクションは実際には切断されず、プールに戻って再利用されます。 未使用プールのクリーンアップ。一定期間 (デフォルト 30 分) コネクションのリクエストがないプールは クリーンアップ候補 としてマークされます。ただし候補になっても即座にクローズされるわけではありません。貸し出し中のコネクションがすべて返却されて初めて、プールが実際にクローズされリソースが回収されます。つまり、そのプールからまだコネクションを使用中のクライアントがいれば、有効期限を過ぎてもプールは存続し、使用中のコネクションが突然切断されることはありません。 内部プーリングのメリットが得られるケース 内部プーリングが最も効果を発揮するのは、いくつかの特定のシナリオで、最も重要なのがリード/ライトスプリッティングです。 リード/ライトスプリッティング: 内部プーリングの最大のメリットは、リード/ライトスプリッティングプラグインと組み合わせたときに現れます。 setReadOnly(true/false) の呼び出しに応じて、リード/ライトスプリッティングプラグインは 1 つの論理コネクションの接続先をライターとリーダーの物理コネクション間で切り替えます。 内部プールなしの場合: setReadOnly(true) が初めて呼び出されるたびにリーダーへの新しい物理コネクションが開かれ、そのコネクションは論理コネクションの存続期間中のみキャッシュされます。他の論理コネクションからは再利用できません。 内部プールありの場合: 各インスタンス (ライター/リーダー) への物理コネクションがプールに蓄積され、複数の論理コネクションが setReadOnly での切り替え時にこれらを再利用します。 @Transactional(readOnly = true) のようにリーダーとライターを頻繁に行き来する Spring ワークロードでは特に効果的です。 JDBC-WRAPPER-CONFIGURATION-ASSISTANT とは JDBC-WRAPPER-CONFIGURATION-ASSISTANT は、AWS Advanced JDBC Wrapper 4.0 以降で利用できる生成 AI ベースの設定アシスタントです。ラッパーの設定選択、既存設定のレビュー、設定の問題診断を支援します。ラッパーのソースコードや公式ドキュメントに基づいた回答を生成し、プラグインの動作、パラメータ名、デフォルト値、排他的な組み合わせなどの詳細を含みます。 Kiro を例にすると、JDBC-WRAPPER-CONFIGURATION-ASSISTANT スキルを有効化した後、会話の開始時に 3 つのエントリーポイントが提示されます。状況に最も合ったものを選択できます。 Greenfield – 達成したいゴールを説明します。例: 「HikariCP を使用した Aurora PostgreSQL クラスターのフェイルオーバーを設定したい」。アシスタントがフォローアップの質問をし、段階的に設定を絞り込みます。 Review – 現在の設定を貼り付けるか、スタックを説明します。アシスタントがレビューして改善点を提案します。 Skip the interview – 動作する設定を直接リクエストします。例: 「デフォルトの Aurora PostgreSQL + HikariCP 設定をください」。アシスタントが使用可能な設定を返し、前提条件を明示します。 内部プーリングの設定オプションと例 内部プーリングを有効にする方法は 2 つあります。 オプション A — 組み込み設定パラメータ (connectionPoolType) 最も直接的な方法です。コネクションプロパティで connectionPoolType を指定し、プール固有の設定は cp- プレフィックスで渡します。以下に例を示します。 # HikariCP 内部プールの有効化 + プールパラメータ connectionPoolType=hikari&cp-MaximumPoolSize=20&cp-MinimumIdle=1 # c3p0 内部プール connectionPoolType=c3p0&cp-MaxConnectionAge=3600&cp-MaxPoolSize=15 指定可能な値: hikari 、 c3p0 cp- の後の名前は com.zaxxer.hikari.HikariConfig または com.mchange.v2.c3p0.ComboPooledDataSource のプロパティに直接マッピングされます。例: cp-MaximumPoolSize は HikariConfig.maximumPoolSize に対応します。 内部的には InternalConnectionPoolService が clusterId ごとに PooledConnectionProvider を作成してキャッシュします。つまり、異なる clusterId を持つクラスターは別々のプールを使用します。 JDBC-WRAPPER-CONFIGURATION-ASSISTANT の使用例 質問: connectionPoolType=hikari のみ有効にしました。プールサイズなどの詳細設定はどこに記述すればよいですか？ 回答: 詳細なプール設定は cp- プレフィックスで渡します。プレフィックスの後のキーは HikariCP の HikariConfig プロパティと 1 対 1 で対応します。例えば、最大 20 コネクション、アイドル 2 コネクションを維持する場合は以下のように設定します。 connectionPoolType=hikari&cp-MaximumPoolSize=20&cp-MinimumIdle=2 内部プールは clusterId で分離・キャッシュされるため、1 つのアプリケーションが複数のクラスターに接続する場合は、プールの混在を避けるため各クラスターに一意の clusterId を割り当ててください。プールサイズは控えめに設定してください。内部プーリングではインスタンスごとに複数のプールが作成される可能性があるため、プール全体の最大値の合計がデータベースインスタンスの max_connections 制限を超えないようにしてください。 オプション B — カスタム HikariPooledConnectionProvider より細かい制御が必要な場合に使用します。プール設定関数 ( HikariPoolConfigurator ) と、オプションでプールキー関数 ( HikariPoolMapping ) を提供します。 // 1) プール設定関数 private static HikariConfig getHikariConfig(HostSpec hostSpec, Properties props) { HikariConfig config = new HikariConfig(); config.setMaximumPoolSize(10); config.setMinimumIdle(1); config.setIdleTimeout(60_000); return config; } // 2) プールキー関数 --- インスタンス URL + ユーザー + カスタム値の組み合わせでプールを分離 private static String getPoolKey(HostSpec hostSpec, Properties props) { final String user = props.getProperty(PropertyDefinition.USER.name); final String somePropertyValue = props.getProperty("somePropertyValue"); return hostSpec.getUrl() + user + somePropertyValue; } // 3) 登録 final HikariPooledConnectionProvider connProvider = new HikariPooledConnectionProvider( MyApp::getHikariConfig, MyApp::getPoolKey); Driver.setCustomConnectionProvider(connProvider); // 4) アプリケーションシャットダウン時 ConnectionProviderManager.releaseResources(); プールを正しく動作させるため、ラッパーは以下の 4 つの設定を自動的にオーバーライドします: jdbcUrl (ホスト/ポート/データベースを含む)、 exceptionOverrideClassName 、ユーザー名、パスワード。そのため、 HikariPoolConfigurator でこれらの値を指定しても無視されます。コンストラクタは、プールキー、クリーンアップ、適格性を制御するいくつかのオプションパラメータも受け付けます。以下の表にまとめます。 パラメータ 型 意味 hikariPoolConfigurator HikariPoolConfigurator (必須) プール設定を返す関数。追加設定がない場合は空の HikariConfig を返します。 mapping HikariPoolMapping (オプション) プールキーを生成する関数。キーが一意になるたびに新しいプールが作成されます。デフォルトはユーザー名です。 acceptsUrlFunc AcceptsUrlFunc (オプション) どのコネクションに内部プールを適用するか決定します。デフォルトはインスタンスエンドポイントのみです。 poolExpirationNanos long プールがクリーンアップ候補になるまでのアイドル時間 (デフォルト 30 分)。 poolCleanupNanos long 期限切れプールをクリーンアップする間隔。 外部プーリングと内部プーリングの違い 以下の表は、配置、トポロジー認識、設定、シャットダウン動作の観点で両方のプーリングアプローチの主な違いをまとめたものです。 観点 外部プーリング (HikariCP など) 内部プーリング (ラッパー) プールの配置 ラッパーの上 (アプリケーションとラッパーの間) ラッパーの内部 (ラッパーとターゲットドライバーの間) プール対象 論理コネクション ( ConnectionWrapper ) 物理コネクション (インスタンスごと) トポロジー認識 なし (接続先インスタンスを認識しない) あり (インスタンスごとにプールが分離) プールキー 通常は単一のデータソース (エンドポイント) (インスタンス URL、ユーザー/カスタムキー)。プールプロバイダーは clusterId ごとにキャッシュ クラスターエンドポイント そのままプールされる (注意が必要) プールされない (インスタンスエンドポイントのみプール) 設定の記述場所 プールライブラリ + AwsWrapperDataSource connectionPoolType または HikariPooledConnectionProvider setReadOnly 切り替え プールは切り替えられたリーダーコネクションを認識しない → オブジェクト間での共有が限定的 インスタンスプールから再利用 → オブジェクト間で共有 leastConnections 戦略 利用不可 利用可能 シャットダウンのクリーンアップ プールライブラリの close ConnectionProviderManager.releaseResources() が必要 外部プーリングと内部プーリングの長所と短所 外部プーリングの長所 外部プーリングにはいくつかの利点があり、フレームワーク駆動のアプリケーションで特に効果的です。 フレームワークとの親和性: Spring Boot などのフレームワークはデフォルトで外部プールを管理します。 アプリケーションレベルでの合計同時コネクション上限 ( maximumPoolSize ) を直感的に制御できます。 チューニングのノウハウやトラブルシューティングのリソースが豊富です。 外部プーリングの短所 一方で、フェイルオーバーやリード/ライトスプリッティングではトレードオフがあります。 setReadOnly ベースのリード/ライトスプリッティングでは、プールレベルでのリーダーコネクション再利用が難しくなります。 フェイルオーバー直後、プール内の多くのコネクションが無効化され、プール枯渇や再接続の急増を招くことがあります。 leastConnections のようなプール対応のホスト選択戦略は使えません。 内部プーリングの長所 内部プーリングには独自の利点があり、多くはトポロジー認識に関連しています。 トポロジー認識: インスタンスごとにプールを保持するため、リード/ライトスプリッティングでリーダーへの切り替えコストが大幅に削減され、複数の Connection オブジェクトがプールを共有します。 クラスターエンドポイントプーリングの落とし穴を構造的に回避します (インスタンスエンドポイントのみプール)。 leastConnections のようなプール対応戦略でリーダー負荷をより均等に分散します。 フェイルオーバー時にラッパーがインスタンスプールを直接管理するため、切り替えがスムーズです。 内部プーリングの短所 一方で、運用上のトレードオフもいくつかあります。 設定と運用の概念が増えます ( HikariPoolConfigurator 、 HikariPoolMapping 、 releaseResources() )。 プールキーからユーザー名を省略すると権限分離が壊れ、キャッシュされたプールコネクションがパスワードを再検証しません。 プール数が インスタンス × ユーザー で増加するため、メモリとコネクションのオーバーヘッドに注意が必要です。 外部プーリングと内部プーリングのプラグイン互換性の違い 以下の表は、外部プーリングと内部プーリングで各プラグインや機能がどう動作するかを示し、推奨事項を記載しています。 プラグイン / 機能 外部プーリング 内部プーリング 備考 Read/Write Splitting ( readWriteSplitting ) 動作するがリーダーの再利用は限定的 推奨 内部プールがオブジェクト間でリーダーコネクションを再利用 @Transactional(readOnly=true) (Spring) 非推奨 (切り替えごとにオーバーヘッド) 推奨 内部プールと組み合わせた場合のみ推奨 leastConnections ホスト選択戦略 利用不可 利用可能 プールのアクティブコネクション数の読み取りが必要なため、内部プールが必須 lowestLoad / highestLoad / roundRobin / weightedRandom / random 利用可能 (戦略による) 利用可能 内部プールプロバイダーが直接サポート Failover / Failover2 利用可能 (プール側で例外処理が必要) 利用可能 EFM / EFM2 利用可能 利用可能 Amazon RDS Proxy エンドポイントとは互換性なし (監視対象のインスタンストポロジーがないため) IAM / Secrets Manager 認証 利用可能 利用可能 (キャッシュされたコネクションがパスワード再検証をスキップする可能性あり) ユーザーをプールキーに含める必要あり Blue/Green 利用可能 利用可能 スイッチオーバー時に Blue コネクションを切断 外部プーリングと内部プーリングの選択時の考慮事項 選択はどちらが普遍的に優れているかではなく、ワークロードと運用環境への適合度で決まります。以下のセクションでは主な判断ポイントをまとめ、Greenfield モードでアシスタントを活用する方法を示します。 ワークロード / 機能の観点 リード/ライトスプリッティングを使用するかどうか: setReadOnly ベースの R/W スプリッティングを多用する場合 → 内部プールが有利です。使用せず、シンプルな単一インスタンス/単一エンドポイント構成の場合は、外部プールで十分です。 リード負荷分散戦略: leastConnections でリーダーを分散したい場合 → 内部プールが必須です。 フェイルオーバーの頻度と感度: フェイルオーバーが頻繁に発生する場合や高速リカバリが重要な場合、内部プールならラッパーがインスタンスプールを直接管理するため切り替えがスムーズです。外部プールでは、古いコネクションの処理やプール枯渇への対策が必要です。 トランザクションパターン: @Transactional(readOnly=true) を多用する Spring アプリケーションでは、内部プール + R/W スプリッティングの組み合わせが推奨されます。 JDBC-WRAPPER-CONFIGURATION-ASSISTANT の使用例 (Greenfield) 質問: Spring アプリケーションで @Transactional(readOnly = true) を頻繁に使用しています。どちらのプーリングアプローチを使うべきですか？ 回答: リード/ライトスプリッティングのユースケースですね。まず 2 点確認させてください。(1) 対象は Aurora クラスターですか？ (2) リードモードの切り替えはフレームワーク経由で @Transactional(readOnly = true) を使用していますか？ 質問: 両方 Yes です。Aurora PostgreSQL を使用しています。 回答: その場合、 readWriteSplitting プラグインとラッパーの 内部プール を組み合わせてください。内部プーリングがないと、論理コネクションでリードモードが初めて有効化されるたびに新しい物理リーダーコネクションが開かれ、コネクションチャーンが増加しインスタンスのコネクション上限を圧迫します。まず以下の設定をベースにしてください。 data-source-properties: wrapperPlugins: initialConnection,readWriteSplitting,failover2,efm2 wrapperDialect: aurora-pg readerHostSelectorStrategy: random connectionPoolType: hikari cp-MaximumPoolSize: 20 cp-MinimumIdle: 2 この構成では auroraConnectionTracker を追加しないでください。内部プールが既に clusterId によってインスタンスコネクションを追跡・無効化するため、トラッカーは冗長になります。また、トレースログで @Transactional(readOnly = true) が実際にラッパーまで伝播されているか検証することをお勧めします。 エンドポイント / トポロジーの観点 接続 URL の種類: クラスター/リーダークラスターエンドポイント経由で接続する場合、外部プールは古い DNS のリスクがあるため、 initialConnection プラグインとバリデーション設定が重要です。内部プールはインスタンス単位で動作するため、この問題を構造的に回避します。 マルチクラスター接続: 1 つのアプリケーションが複数のクラスターに接続する場合、クラスターごとに異なる clusterId を割り当てる必要があります。内部プールは clusterId でプールを分離するため、この設定は特に重要です。 カスタムドメイン/IP/プロキシ: 非標準の URL では、 clusterId と clusterInstanceHostPattern の設定を確認してください。 JDBC-WRAPPER-CONFIGURATION-ASSISTANT の使用例 (Greenfield) 質問: 1 つのサービスが 2 つの Aurora クラスターに接続しています。プールをどう分離すべきですか？ 回答: マルチクラスター構成では、プーリングアプローチに関係なく各クラスターに一意の clusterId を割り当ててください。両方のクラスターがデフォルト値を共有すると、トポロジーキャッシュが衝突し、間違ったクラスターへのフェイルオーバーやモニター間の干渉が発生する可能性があります。内部プーリングでは、 clusterId がプール分離の境界にもなります。 a.addDataSourceProperty("clusterId", "cluster-a-prod"); b.addDataSourceProperty("clusterId", "cluster-b-prod"); 質問: クラスターライターエンドポイント経由で接続し、外部プーリングを使用する場合、何に注意すべきですか？ 回答: フェイルオーバー直後、古い DNS によりクラスターエンドポイントが一時的に旧ライターに解決される場合があります。外部プーリングのみを使用する場合は、 initialConnection プラグインを含めることで最初のコネクションが実際のインスタンスエンドポイントに着地するようにしてください。EFM がクラスターエンドポイントではなくインスタンスエンドポイントを監視するためにも有効です。内部プーリングはインスタンスエンドポイントのみをプールするため、この問題を構造的に回避します。 セキュリティの観点 マルチユーザーの権限分離: HikariPoolMapping にユーザー名を必ず含めてください (省略すると、異なる権限を持つユーザー間でプールが共有されるリスクがあります)。 IAM トークン認証: トークン TTL とプールコネクションのライフタイムの関係を考慮してください。内部監視ワーカーが IAM プラグインを失わないように ConfigurationProfile の設定が推奨されます。 JDBC-WRAPPER-CONFIGURATION-ASSISTANT の使用例 (Greenfield) 質問: HikariCP で IAM 認証を使用していますが、15 分あたりから一部のコネクションが失敗し始めます。どう対処すべきですか？ 回答: 直感的な対処法は HikariCP の maxLifetime を短くすることですが、ここでは効果がありません。 iam プラグインがサブスクライブするのは connect と forceConnect のみで、トークンはハンドシェイク時に一度だけ提示され、以降の呼び出しにフックはありません。認証に成功したコネクションがトークンの経過時間によって失敗することはありません。 maxLifetime はプールの衛生管理の観点で設定し、トークンとは切り離して考えてください。 重要なのは iamExpiration です。ラッパーはトークンを (region, host, port, user) ごとにキャッシュし、 iamExpiration はそのキャッシュの TTL で、デフォルトは 870 秒 (サーバー側のトークンウィンドウ 15 分に対して) です。900 を超える値は設定しないでください。ドライバーは値をクランプせずに読み取るため、大きな TTL を設定するとキャッシュが RDS によって既に無効化されたトークンを配信します。プラグインのドキュメントでは 600 を例として使用しています。 hikari: max-lifetime: 1800000 data-source-properties: wrapperPlugins: initialConnection,auroraConnectionTracker,iam,failover2,efm2 iamRegion: us-east-1 iamExpiration: 600 キャッシュされたトークンが拒否された場合、プラグインはトークンを再生成して接続を1回リトライするため、完全な障害にはなりません。ただし、影響を受けるコネクションはそれぞれ最初のハンドシェイクが一度失敗するため、間欠的な接続遅延やエラーとして症状が現れます。 コンテナや Lambda 環境では、 iamRegion を明示的に設定するほうが安全です。内部プーリングを使用し、ユーザーごとに権限が異なる場合は、キャッシュされたコネクションがユーザー間で再利用されないよう、プールキーにユーザーを含めてください。 運用 / フレームワークの観点 フレームワーク標準: Spring Boot のようなフレームワークはデフォルトで外部プールを管理します。チーム標準が外部プールで R/W スプリッティングを使用しない場合、外部プールのほうが運用がシンプルです。 プールサイジング: 内部プールは インスタンス × ユーザー の数だけプールが増える可能性があり、合計コネクション数が増加します。各インスタンスの maximumPoolSize を控えめに設定し、データベースの max_connections 制限内に収まるようにしてください。 メモリ/スレッドコスト: プール数が増えるほど、アイドルコネクションやヘルスチェックスレッドのコストが増加します。有効期限/クリーンアップ間隔 ( poolExpirationNanos 、 poolCleanupNanos ) と minimumIdle を適切にチューニングしてください。 コネクションライフタイムの制御: リーダーのキープアライブ ( cachedReaderKeepAliveTimeoutMs ) をプールの maxLifetime / idleTimeout ポリシーと合わせて設計してください。 JDBC-WRAPPER-CONFIGURATION-ASSISTANT の使用例 (Greenfield) 質問: チーム標準は Spring Boot + HikariCP です。リード/ライトスプリッティングは使用していません。内部プーリングは必要ですか？ 回答: いいえ。リード/ライトスプリッティングを使用しないシンプルな単一エンドポイントの Spring アプリケーションでは、おなじみの外部 HikariCP プールで十分で、運用もシンプルです。ただし、HikariCP + フェイルオーバーで 1 つ重要な設定があります: exception-override-class-name に software.amazon.jdbc.util.HikariCPSQLException を設定し、ラッパーがフェイルオーバー後に再接続済みのコネクションを HikariCP が破棄しないようにしてください。 hikari: maximum-pool-size: 30 exception-override-class-name: software.amazon.jdbc.util.HikariCPSQLException data-source-properties: wrapperPlugins: initialConnection,auroraConnectionTracker,failover2,efm2 wrapperDialect: aurora-pg 質問: リードデータソースとライトデータソースを完全に分離すれば、内部プーリングを避けられますか？ 回答: はい。リードがリーダークラスター URL、ライトがライタークラスター URL を使い、2 つの別々のデータソースを構成する場合、リード/ライトスプリッティングプラグインと内部プーリングの両方を回避できます。各データソースに固定のロールを付与し、 failoverMode を strict-reader または strict-writer に設定してください。リーダーデータソースに readWriteSplitting を追加しないでください。切り替えるロールがないためです。 判断のまとめ (クイックガイド) シンプルな単一エンドポイント + 標準的な Spring アプリ、R/W スプリッティングなし → 外部プール (HikariCP)。フェイルオーバー SQLState マッピングに注意。 リード/ライトスプリッティング + リーダー負荷分散 ( leastConnections ) が必要 → 内部プール。 データソースを分離してリードはリーダークラスター URL、ライトはライタークラスター URL を使える場合 → R/W プラグインと内部プールの両方をスキップし、2 つの外部プールで対応可能。 まとめ AWS Advanced JDBC Wrapper のコネクションプーリングを理解するカギは、「 プールがラッパーの上 (外部) か下 (内部) か 」という位置関係です。 外部プーリング は 論理コネクション をプールします。ツールが成熟しておりフレームワークとの親和性が高い一方、リード/ライトスプリッティングには制約があります。 内部プーリング は 物理コネクション をインスタンス単位でプールします。トポロジーを認識するため、リード/ライトスプリッティング、リーダー負荷分散 ( leastConnections )、フェイルオーバー切り替えに優れています。その代わり、クラスターエンドポイントはプールされず (インスタンスエンドポイントのみ)、プールキー、パスワード再検証、リソースクリーンアップなどの運用概念が追加されます。 最終的に、ラッパーのプラグインアーキテクチャとプーリングアプローチは別々の選択ではなく、一体として設計すべきものです。まず JDBC-WRAPPER-CONFIGURATION-ASSISTANT を開いてワークロードを説明し、アプリケーションにそのまま組み込める初期設定を提案してもらいましょう。ワークロードの読み書き比率、フェイルオーバー感度、セキュリティ要件、運用標準を総合的に検討すれば、Aurora の高可用性とプーリングによるパフォーマンス向上の両方を活用できます。 プールがラッパーのどちら側に位置すべきか迷ったら、ワークロード (エンジン、エンドポイント、フレームワーク、読み書きパターン) を JDBC-WRAPPER-CONFIGURATION-ASSISTANT に伝えてください。初期設定の提案に加え、内部プールなしでリード/ライトスプリッティングプラグインを使用している、HikariCP の例外オーバーライドが不足しているなど、よくあるアンチパターンも指摘してくれます。 著者について Dave Cramer Dave は、Amazon Web Services のプリンシパルソフトウェアエンジニアです。PostgreSQL JDBC ドライバーのメンテナーとして PostgreSQL にも大きく貢献しています。クライアントインターフェースとクライアントとの連携に情熱を注いでいます。 Youngdong Lee Youngdong は、データベースを専門とするソリューションアーキテクトです。Amazon データベースサービスに関する技術的な問い合わせや課題の分析を支援し、データとインフラストラクチャの安定した導入・運用に取り組んでいます。 この記事はSolutions ArchitectのShinya Sugiyama が翻訳を担当しました。

本記事は 2026 年 8 月 11 日 に公開された「 How GPU acceleration builds billion-scale vector indexes on Amazon OpenSearch Service 」を翻訳したものです。 生成 AI アプリケーションが急速に増えるなか、いまの検索には高性能なベクトルインデックス作成とスケーラビリティが求められます。データセットが数十億件規模に達すると、従来の CPU ベースのインデックス作成がボトルネックになりがちで、生産性やイノベーションのスピードを鈍らせてしまいます。 GPU で高速化したベクトル (k-NN) インデックス作成が Amazon OpenSearch Service と Amazon OpenSearch Serverless で 利用できるようになり 、数十億件規模のベクトルにも効率よくスケールできます。この機能は、GPU アクセラレーションによるベクトル検索向けのオープンソースライブラリ NVIDIA cuVS を基盤としており、計算負荷の高いベクトルインデックスの構築を専用の GPU ワーカーにオフロードします。その間、既存の CPU インフラは検索の処理を続けられます。結果として、クエリ性能を犠牲にすることなく、大規模なベクトルインデックスをより速く、より低コストで構築できます。 以前の記事 では、性能とコスト面のメリットを詳しく紹介しました。本記事では、この機能の仕組みをさらに掘り下げます。まず、その土台にある分離型アーキテクチャを見ていきます。次に、GPU で構築したインデックスが、品質を落とすことなく CPU データノードで検索可能な形式に変換される過程を説明します。さらに、10 億件の 1024 次元ベクトルを使ったベンチマークで、大規模環境でもこの方式が通用することを示します。最後に、本番環境で GPU アクセラレーションによるインデックス構築を運用する際に推奨するベストプラクティスを紹介します。 ユースケースとメリット さまざまな業界の企業が、より豊かな顧客体験を提供するために AI やエージェント型のアプリケーションを構築しています。ベクトルインデックス作成の GPU アクセラレーションは、こうした幅広いユースケースで役立ちます。いくつか例を挙げます。 新しい埋め込みモデルへの移行を速める: より新しい埋め込みモデルにアップグレードすると、すべてのベクトルを生成し直してインデックスを作り直す必要があります。数億から数十億件規模になると、CPU での再構築には数日から数週間かかることもあります。GPU アクセラレーションなら再構築を数時間に短縮できるため、より高品質なモデルへ移行しつつ、再インデックスにかかる時間と可用性へのリスクを大幅に減らせます。 大規模な再インデックスを高速化する: 数十億件の商品リスト、カスタマーレビュー、行動シグナルを扱うグローバルな e コマースアプリケーションでは、新しい商品や埋め込みが追加されるたびに、ベクトルインデックスを素早く作り直す必要があります。GPU アクセラレーションは限られた運用時間内で再インデックスを完了し、検索の関連性を常に最新に保ちます。 急増する書き込みや高い持続書き込みを吸収する: ワールドカップやオリンピックといった大規模スポーツイベントを扱うメディア企業では、数百万件のリアルタイム埋め込みを同時にインデックスする必要があります。これらの埋め込みは、試合のハイライト、解説クリップ、選手のプロフィール、ファンが投稿したコンテンツにまたがり、同時に数百万人の視聴者が関連コンテンツを検索します。GPU ワーカーはこのインデックス作成の急増を吸収し、ライブ検索トラフィックを処理する CPU ノードと競合しません。そのため、大量書き込みにつきものの遅延の急増を避けられます。 読み書き混在のワークロードに合わせてクラスターを最適化する: 小売システムでは従来、カタログ更新時のピーク時のインデックス負荷と、同時に発生する検索トラフィックの両方に対応するため、CPU クラスターを過剰にプロビジョニングし、ピーク時の容量分を常時支払っていました。インデックス作成を GPU にオフロードすれば、CPU クラスターを検索専用に適正なサイズへ調整でき、性能を落とさずにインフラコストを削減できます。 セマンティック検索や OpenSearch への移行を速める: テキストベースのコーパスを初めてベクトル埋め込みに変換する場合でも、既存のベクトルワークロードを別のデータベースから Amazon OpenSearch Service へ移行する場合でも、GPU アクセラレーションによるインデックス作成なら、数日かかるインデックス構築を数時間に短縮できます。GPU による上流の埋め込み生成のスピードに歩調を合わせ、切り替え時のリスクも最小限に抑えられます。 GPU アクセラレーションはいつ有効になるのか GPU アクセラレーションは、オプトインすれば自動的に有効になります。OpenSearch Service ドメインでは、Vector Acceleration オプションをオンにするだけで有効になり、それ以降はコードや API フラグを変更する必要はありません。OpenSearch Serverless では、NextGen ベクトル検索コレクションで GPU によるインデックス構築の高速化がデフォルトで有効です。図 1 はインデックス構築のワークフローを示しています。OpenSearch はセグメントのサイズに応じてベクトルインデックス作成の処理を GPU と CPU に自動で振り分け、性能を最適化します。問題が発生した場合は CPU にフォールバックします。 OpenSearch がセグメントをフラッシュまたはマージするとき、そのセグメントのベクトルデータサイズを、 index.knn.remote_index_build.size.min と index.knn.remote_index_build.size.max で区切られた 設定可能な範囲 と比較します。下限のデフォルトは 50 MB です。下限を超えるセグメントはリモートの GPU ワーカーにオフロードされ、それより小さいセグメントはローカルの CPU で構築されます。セグメントのベクトルサイズは次の式で計算します。 segment_vector_size = num_vectors × dimensions × bytes_per_element そのため、ドキュメント数が同じ 2 つのワークロードでも、セグメントサイズが異なることがあります。 ベクトル数 次元数 エンコーディング セグメントのベクトルサイズ 100,000 1536 Float32 約 586 MB 100,000 768 Byte 約 74 MB どちらの例もデフォルトの下限 50 MB を超えているため、デフォルト設定では両方のセグメントが GPU ワーカーにオフロードされます。 図 1: インデックス構築の簡略化したフロー 分離型のインデックス作成アーキテクチャ OpenSearch のインデックスは内部的にセグメントに分割され、各セグメントが独自のベクトルグラフを持ちます。このセグメント単位の構造こそが、GPU へのオフロードを実用的にしています。各セグメントのグラフは、インデックス全体で調整をとらなくても、GPU ワーカー上で独立して構築できます。これを土台にした、アーキテクチャ上の重要な着想が、ベクトルをインデックスする場所と検索する場所を分離することです。既存の CPU データノードは、取り込み、検索、ベクトル以外のワークロードの処理を続けます。セグメントがベクトルインデックスの構築段階に入ると、負荷の高いグラフ構築の作業が専用の GPU ワーカーにオフロードされ、完成したインデックスがデータノードに返されて検索に使われます。 インデックス構築のワークフロー 取り込み – ベクトルフィールドを持つドキュメントは、通常どおり OpenSearch Service ドメインまたは OpenSearch Serverless コレクションに取り込まれます。ベクトルは CPU データノード上のセグメントに蓄積されていきます。 オフロード – セグメントがフラッシュまたはマージされ、そのベクトルデータが GPU の有効化範囲に収まると、データノードは元のベクトルを Amazon Simple Storage Service (Amazon S3) にアップロードし、構築リクエストを送信します。 構築 – マネージドなウォームプールの GPU ワーカーがジョブを受け取り、ベクトルを読み込んで、NVIDIA cuVS の GPU ネイティブなグラフアルゴリズムである CAGRA (CUDA ANN Graph) を使ってインデックスを構築します。できあがった CAGRA グラフは、その後 CPU ベースの検索と互換性のある Hierarchical Navigable Small World (HNSW) グラフに変換されます。 受け取り – 完成した HNSW インデックスは Amazon S3 に書き戻され、データノードがダウンロードします。データノードはそのインデックスを使って検索クエリに応答します。 フルマネージドな GPU インデックス構築 Vector Acceleration を有効にする だけで、あとは Amazon OpenSearch Service が処理します。 自動スケーリング – GPU ワーカーは、待機中の構築ジョブ数に応じて自動でスケールアップ・スケールダウンします。一括取り込みや再インデックスの際には、負荷に対応するために GPU ワーカーが増えます。キューが空になると、ゼロまで縮小します。 自動インスタンス選択 – サービスがセグメントサイズに基づいて、構築ジョブごとに適切な GPU インスタンスタイプを選びます。ユーザー側でキャパシティプランニングやインスタンスの選択を行う必要はありません。 アクティブな構築時のみ課金 – 課金されるのは GPU が実際にインデックスを構築している間だけで、アイドル状態のときは課金されません。ドメインやコレクションで Vector Acceleration を有効にしていても、OpenSearch Compute Unit (OCU) で計測される GPU の料金は、セグメントが有効化のしきい値に達してインデックス構築が始まったときにのみ発生します。GPU インフラを常時保有するコストはかかりません。 したがってコストは、インデックス作成の量に応じて直接増減します。急増する再インデックスのワークロードは構築が続く間だけ GPU 容量を消費し、次の構築まで GPU コストはゼロに戻ります。 図 2 は分離型の GPU ワークフローを示しています。Amazon S3 がデータノードと GPU ワーカーの仲介役となり、両者が独立して動作できるようにします。データノードは元のベクトルを Amazon S3 にアップロードし、GPU ワーカーが CAGRA グラフを構築して HNSW に変換します。完成したインデックスはデータノードに返されて検索に使われ、その間も検索は中断なく動き続けます。 図 2: GPU インデックスフローのアーキテクチャ CAGRA から HNSW への変換の中身 前のセクションでは、GPU ワーカーがベクトルインデックスを構築してデータノードに返す流れを説明しました。では、GPU で構築したグラフはどうやって CPU で検索可能になるのでしょうか。そして、この変換で品質は落ちるのでしょうか。結論から言うと、落ちません。 CAGRA アルゴリズム GPU ワーカーは、 Facebook AI Similarity Search (Faiss) ライブラリの cuVS GPU バックエンドを通じて統合された CAGRA アルゴリズムを使います。CAGRA は、GPU アクセラレーションを前提に一から設計されたグラフベースのインデックス作成手法です。まず、 Inverted File with Product Quantization (IVF-PQ) や Nearest Neighbor Descent (NN-Descent) といった別の近似最近傍探索の手法を使って k-NN グラフを構築します。次に、近傍間の冗長な経路を取り除き、探索しやすいグラフに整えます。 図 3: CAGRA グラフの構築フロー 出典: CAGRA: Highly Parallel Graph Construction and Approximate Nearest Neighbor Search for GPUs GPU ワーカーによるインデックス構築の流れ GPU ワーカーがベクトルインデックスの構築リクエストを受け取ると、そのリクエストにはセグメント固有のベクトルインデックスを構築するために必要なパラメータが含まれています。ベクトルインデックス構築コンポーネントは、まず Amazon S3 からベクトルファイルを取得して CPU メモリに読み込み、処理を開始します。読み込んだベクトルを使って、Faiss で CAGRA インデックスを構築します。GPU 上で CAGRA インデックスを構築したあと、CPU ベースの検索処理と互換性を持たせるために HNSW グラフ形式へ変換します。できあがったインデックスを Amazon S3 にアップロードして、構築リクエストが完了します。 CAGRA グラフを HNSW に変換する 一般的な HNSW インデックスは、複数の層からなる階層型グラフです。グラフの 最下層 (レイヤー 0) がベクトルを保持し、上位の層はナビゲーションだけに使われる疎なサブセットです。上位の層は、検索アルゴリズムが最下層への適切な入口を見つけるのを助けます。ただし、今回の HNSW 実装では CAGRA グラフを最下層として使い、CAGRA の検索手法と同じように、グラフへのランダムな入口から探索を始めます。そのため上位の層はまったく必要ありません。 つまり、基盤となる層のグラフを構築する重い処理は GPU が担います。そのグラフを HNSW の基盤層としてそのまま再利用することで、CPU で作り直す必要がなくなり、変換の負荷を低く抑えられます。図 4 のように、CAGRA グラフがそのまま基盤層になります。クエリの実行時には、グラフ内のノードをランダムに選び、最近傍へのリンクをたどってグラフを探索します。これは貪欲探索 (greedy search) と呼ばれる方法です。 図 4: HNSW に変換した CAGRA グラフの検索 同じ再現率で、より速い構築 これまでの ベンチマーク で、GPU で構築したインデックスが、 CPU で構築した HNSW と同じ再現率 を、品質を落とさずに達成することが確認されています。これは、CAGRA が生成する最下層のグラフ構造が、接続性と検索品質の点で、HNSW が CPU 上で構築するものと同等だからです。異なるのは構築の方法だけです。 GPU メモリを超える規模へのスケール GPU メモリに収まらないデータの構築 従来の GPU インデックス作成では、データセット全体を GPU メモリに載せる必要があり、利用できるハードウェアによってインデックスサイズに明確な上限が生まれていました。CAGRA は、データセット全体を一度に GPU メモリへ載せずに k-NN グラフを構築する方式 ( アウトオブコア構築 ) によって、この制約を取り除きます。CAGRA の初期 k-NN グラフの構築に IVF-PQ を使う場合、データはシステムメモリから GPU へバッチ単位でストリーミングされるため、データセット全体を一度に GPU メモリへ収める必要がありません。その一方で、計算負荷の高い距離計算やグラフの最適化は引き続き GPU が担います。 量子化 GPU アクセラレーションによるインデックス作成は、OpenSearch で利用できる量子化レベル (2 倍、8 倍、16 倍、32 倍の圧縮) に対応しています。量子化は、ベクトルを GPU に送る 前に 適用されます。これにより、GPU ワーカーへのデータ転送量と、グラフ構築時のメモリ使用量の両方を削減できます。その結果、より大きなセグメントに対してインデックスを構築でき、コスト効率が高まります。 GPU で 10 億件の 1024 次元ベクトルをインデックスする データセットの準備 現実的な大規模ワークロードを評価するために、1024 次元のベクトルを 10 億件含むデータセットを使いました。一様なランダムベクトルは、インデックス構築と再現率のどちらでも誤解を招く結果になるため、実世界の埋め込みの構造を保ったデータが必要でした。このデータセットは、 cuvs-bench に含まれる cuVS の合成データセットジェネレーターで作成しました。このジェネレーターは、Common Crawl から得た実際の埋め込みデータセットの分布を模した合成データを出力します。この方法を使えば、機微な元データを公開したり配布したりせずに、現実的なデータセットを用意できます。ジェネレーターは、10 億件のベクトルデータセット一式と 10,000 件のクエリベクトル、および対応する正解ラベルを、1 台の Amazon Elastic Compute Cloud (Amazon EC2) g6e.16xlarge インスタンス上で、約 2 時間で生成できます。 クラスター構成 ベンチマーク用のクラスターは、OpenSearch のベクトル検索のパフォーマンスチューニングの ベストプラクティス に従って OpenSearch Service 上に設計し、 OpenSearch Benchmark フレームワーク を使ってベンチマークを実施しました。 設定項目 値 理由 データノード 24 × r8g.4xlarge 大規模なベクトルインデックス向けのメモリ最適化インスタンス プライマリシャード 48 シャードサイズを扱いやすく保ち、並列性を最大化する レプリカ 0 インデックス作成のスループットを最大化する。レプリカは構築後に追加する GPU ワーカー 10 (事前スケール) 測定中のコールドスタートの影響を避ける 一括クライアント 160 24 ノードにわたって取り込みパイプラインを飽和させる 一括サイズ 500 ドキュメント/リクエスト リクエストごとの負荷とメモリ圧迫のバランスをとる リフレッシュ間隔 -1 (取り込み中) 小さなセグメントの生成を防ぐ。取り込み後に強制マージを実行する マージの自動スロットリング 無効 ベンチマーク中の人為的なボトルネックを避ける 適用した主なベストプラクティス メモリ最適化インスタンス – r8g.4xlarge は、構築後の HNSW グラフを読み込むのに十分なヒープとネイティブメモリを備えています。 一括取り込み中はリフレッシュを無効化 – 小さなセグメントが多数生成され、それぞれが個別の GPU 構築を発生させるのを防ぎます。 多数の一括クライアント – ノード全体で取り込みを飽和させ、GPU がインデックス構築で常に稼働している状態を保ちます。 HNSW の構築と検索の設定 ( m や ef_construction など) は OpenSearch のデフォルト値を使いました。ほとんどのユーザーがデフォルト値から始めるため、ベンチマークを実態に即したものに保てます。 ベンチマーク結果 データセット インデックス構築 (分) 再現率 @k =100 再現率 @1 P50 (検索) P90 (検索) P99 (検索) 使用した Vector Acceleration OCU 1024D 1B 274 0.93 0.93 26.47ms 32.5ms 66.6ms 44 構築時間はデータ量に比例してスケールする 以前の OpenSearch Service でのベンチマーク では、10 億件の 128 次元ベクトル (BigANN SIFT データセット) を約 35.5 分でインデックスしました。最新のベンチマークでは、次元数を 8 倍の 1024 次元に拡大し、274 分でインデックス構築を完了しました。これはデータ量の増加におおむね比例した結果です。GPU アクセラレーションが、次元数が増えても一貫したスループット効率を保つことを示しています。構築時間は固定的な起動コストではなくデータ量に応じてスケールするため、データセットのサイズからインデックス構築時間をあらかじめ見積もれます。この規模でも検索のレイテンシーは低いままだったため、できあがったインデックスは、構築の速さを犠牲にすることなく応答性の高いクエリに対応できました。 GPU アクセラレーション向けに一括取り込みを最適化する 大量のベクトルデータを読み込むとき、インデックスの動作を一時的に調整すると、GPU の処理負荷を大幅に減らせます。この方法は、ユースケースがデータの一時的な鮮度低下を許容できる場合に有効です。インデックス全体を構築している間は、新しく取り込んだベクトルはリフレッシュを再度有効にするまで検索対象にならないため、通常は問題ありません。一括取り込み中にリフレッシュを無効にする ( "index.refresh_interval": "-1" ) と、小さなセグメントが連続して生成されるのを防げます。そうしないと、小さなセグメントのそれぞれが個別の GPU 構築ジョブを発生させてしまいます。取り込みが完了したら、リフレッシュ間隔を有効に戻してリフレッシュを実行し、セグメントを検索可能にします。この方法により、GPU は多数の小さなセグメントに対して繰り返しインデックスを構築するのではなく、大きく密に詰まったセグメントに対して一度だけ構築するため、全体としてインデックス作成のスループットが速くなります。 GPU アクセラレーションを有効にしたあとは、 Amazon CloudWatch メトリクス (クラスターレベル) と OpenSearch k-NN Stats API (ノードごと) で構築状況を監視できます。GPU での構築が失敗した場合、システムは自動的に CPU ベースのインデックス構築にフォールバックするため、データは引き続きインデックスされます。 今後の最適化 現在は、完成した HNSW インデックス (グラフ構造とベクトル) が、GPU ワーカーから Amazon S3 を経由してデータノードに転送されています。データノードは元のベクトルをすでにローカルに保持しているため、今後の最適化ではグラフ構造 (近傍リスト) だけを転送するようにします。これにより、Amazon S3 への書き戻し量とデータノードへのダウンロード時間を大幅に削減できます。 まとめ GPU アクセラレーションによるインデックス作成を使うと、Amazon OpenSearch Service 上で 10 億規模のベクトルインデックスを、数日ではなく数時間で構築できます。しかも、OpenSearch Service ドメインと OpenSearch Serverless コレクションのどちらでも、クエリの処理方法を変える必要はありません。本記事では、OpenSearch Service が対象となるインデックス構築を GPU ワーカーにオフロードし、Faiss の NVIDIA cuVS バックエンドを通じて CAGRA グラフを構築し、それを CPU で検索可能な HNSW インデックスに変換する仕組みを紹介しました。さらに、10 億件の 1024 次元ベクトルで大規模にこの方式を実証し、一括取り込みの最適化や、構築状況と OCU 使用量の監視についてのベストプラクティスを共有しました。 使ってみる GPU アクセラレーションによるベクトルインデックス作成を試してみませんか。対応している AWS リージョンでは、OpenSearch 3.1 以降を実行する OpenSearch Service ドメインを作成または更新する際に、GPU アクセラレーションを有効にできます。設定には、AWS マネジメントコンソール、AWS Command Line Interface (AWS CLI)、または AWS SDK を使います。OpenSearch Serverless を新しくデプロイする場合は、 NextGen ベクトル検索コレクション を作成してください。このコレクションでは GPU によるインデックス構築の高速化がデフォルトで有効になっており、インデックスごとに制御できます。Classic ベクトルコレクションの場合は、コレクションレベルで GPU アクセラレーションを有効にします。 謝辞 著者一同、本記事への貢献に対し、NVIDIA の Ben Gardner、Manas Singh、Zack Meeks、Jiahong Liu、James Yi、Jinsol Park の各氏に感謝します。 著者について Navneet Verma Navneet は、 Navneet は AWS のプリンシパルソフトウェアエンジニアで、OpenSearch のコアなベクトル検索に取り組んでいます。スケーラビリティ、性能、そして大規模な AI ワークロードに向けたベクトル検索の発展に情熱を注いでいます。 Vamshi Vijay Nakkirtha Vamshi は、 Vamshi は、OpenSearch Project と Amazon OpenSearch Service に携わるソフトウェアエンジニアリングマネージャーです。分散システムに関心があります。 Gowri Balasubramanian Gowri は、 Gowri は、Amazon Web Services でデータスペシャリストソリューションアーキテクトチームを率いるシニアマネージャーです。AWS のデータベースサービスと分析サービスの導入を推進するとともに、リファレンスアーキテクチャからベストプラクティスまでの実践的なガイダンスを整備し、企業のデータと AI の変革を後押ししています。スケーラブルな分散データシステムに情熱を注いでいます。 Kshitiz Gupta Kshitiz は、 Kshitiz は NVIDIA のシニアソリューションアーキテクトで、クラウドのお客様が GPU 上で大規模な AI ワークロードを最適化できるよう支援しています。GPU アクセラレーションによるデータ処理、ベクトル検索、LLM の推論と幅広く手がけ、AWS や Amazon のチームと緊密に連携して、これらの機能を本番環境に届けています。仕事以外では、音楽、ヨガ、ハイキングを楽しんでいます。 Corey Nolet Corey は、 Corey は NVIDIA でベクトル検索、データマイニング、古典的な機械学習ライブラリを担当するディスティングイッシュトエンジニアで、極めて大きなデータ負荷を高速に処理するためのアルゴリズムの構築とスケールに注力しています。2018 年に NVIDIA に加わる前は、防衛業界のビッグデータや HPC 環境で、大規模な探索的データサイエンスとリアルタイム分析のプラットフォームを長年にわたり構築してきました。Corey はコンピューターサイエンスの博士号を持ち、データを使って世界をよりよく理解することに情熱を注いでいます。 Rajeshwari Devaramani Rajeshwari は、 Rajeshwari は NVIDIA のソリューションアーキテクトです。ジョージア工科大学で計算科学工学の修士号を取得しています。GPU プログラミング、ハイパフォーマンスコンピューティング、ディープラーニングを専門としてきました。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。

この記事は、”One year. 4.5 billion lines of code. 1.6 million hours saved. Here’s what we learned.” を翻訳したものです。 1 年前、私たちは AWS Transform を立ち上げました。その使命は、ただ 1 つです。それは、世界のインフラストラクチャとアプリケーションをモダナイズすることです。 AWS Transform の一般提供開始から 12 ヶ月が経過した今、これまでに 45 億行を超えるコードが処理され、数十万台のサーバーが移行され、160 万時間を超えるお客様を節約できたこと、そして移行、モダナイゼーション、そしてこの作業が待った無しの状態である理由がわかりました。 モダナイゼーションが何故これまで以上に重要なのか 企業は今でもインフラストラクチャのかなりの部分をオンプレミスで運用しています。世界のソフトウェアの大部分は 20 年以上前のものです。今でも給与計算を行っています。まだ請求処理が行われています。お客様のビジネスが日常的に依存しているシステムが引き続き稼働しています。そして今、経営陣は、その上にエージェンティック AI を組み込むことを望んでいます。15 年間手が入っていないメインフレームでは、エージェンティック AI ワークロードを実行することはできません。退職したエンジニアが開発した継ぎ接ぎだらけの .NET Framework アプリケーションに AI エージェントを投下することはできません。皆さんが先送りし続けているモダナイゼーションが、今や CEO が前四半期に発表した AI 戦略とあなたとの間に立ちはだかっているのです。 その一方で、技術的負債はどんどん膨れ上がっています。米国だけでも、技術的負債は年間 1.52 兆ドルに上ると見積もられており、AI コーディングエージェントは、その山を小さくするのではなく、むしろ大きくしています。彼らは現在出荷されているコードを生成しますが、明日の標準には従わないでしょう。企業リーダーからのシグナルは、「モダナイズすべき」から「モダナイズしなくてはならない」に変わりました。しかし、モダナイゼーションは技術的に難しく、ビジネスが複雑になり、そして重要なのは、モダナイゼーションは決して終わらないということです。今日のモダナイゼーションは明日の遺産です。だからこそ、モダナイゼーションはプロジェクトではなく、継続的なプロセスでなければならないのです。 これが AWS Transform を構築した理由です。 お客様が実際に求めたこと アーキテクチャではありません。フレームワークではありません。他のツールでもありません。 彼らが求めたのは「スピード」という結果でした。精度。継続性。彼らは行き詰まったものを終わらせたかったのです。彼らのプロジェクトのいくつかは何年も手つかずのまま放置されていました。AWS では 20 年間にわたり、数十万件に上るプロジェクトでお客様を支援し、移行ツールを自社で構築してきました。何がうまくいくのか、規模を拡大するには何が必要か、どこにギャップがあるのかはわかっていました。 これが 1 年前、AWS Transform が誕生した経緯です。私たちは学んだことのすべてを数十個の専門的な AI エージェントにまとめ、エージェント型のワークフローで結び付けました。これらのエージェントは、ゴール駆動型のオーケストレーションを使用して end-to-end の自動化を実行しています。ディスカバリー、計画、トランスフォーメーション、テストはすべて相互に関連しています。共同作業者間のシームレスな引き継ぎ。ステージ間でコンテキストが失われることはありません。20 年にわたる移行の専門知識を AI 支援サービスとして提供し、イテレーションを重ねるごとに改善されていきます。 この取り組みは、3 つのユースケース (VMware インフラストラクチャーの移行、IBM z/OS COBOL アプリケーションのモダナイゼーション、.NET のアップグレード) を立ち上げることから始めました。これらのワークロードは、お客様がモダンなワークロードを実行するのを嘗て妨げており、現在はエージェント型のワークロードの実行を妨げているからです。re:Invent 2025 では、広範に技術的負債を削減するべく、あらゆるコード、言語、API、フレームワークのアップグレードに合わせて独自のカスタムトランスフォームを定義できる機能を追加しました。 12 ヶ月で何が起こったか AWS Transform の利用を通じて、45 億行を超えるコードを処理し、数十万台の VM を移行しました。 速度の違いは小さくはありません。25 万行のメインフレームアプリケーション全体のトランスフォーメーションとテストを 6 週間で完了したお客様がいらっしゃいます。以前は、同じ作業に何年もかかっていました。現在、数千台のサーバーを数週間ではなく数時間で移行することを計画しているインフラストラクチャーチームも居ます。これらのお客様による評価では、AWS に移行することでコンピューティングが平均 35%、ライセンスが 45% 節約され、クラウドに移行することでコストを 60% 削減できることが一貫して明らかになっています。Windows と .NET のモダナイゼーションにより、ライセンスコストが 40% 削減され、プロジェクトのスケジュールが 4 倍短縮されたケースもあります。 これらの数字の背景にある顧客リストには、より大きな物語があります。CSL 社は、数千台のサーバの移行を数日で計画しました。これは、以前のアプローチの 10 倍のスピードです。ADP 社は Transform のメインフレームとカスタム機能を使用して複雑なメインフレームをモダナイズし、Kiro と連携して新しいコードの構築を完了しました。現在、110 万のクライアントに対応できるようになり、その成果は数年ではなく数週間で完了しています。Signaturit Group は、Windows .NET から Linux への移行期間を 6~8 ヶ月から数日間に短縮しました。Air Canada は Node.js ランタイムを数日でアップグレードし、90% の効率化と 80% のコスト削減を実現しました。その後、Transform を社内標準にしました。また、何千ものお客様を対象に、過去からの技術的負債を修復するのではなく、将来のためのイノベーションに投資することで、すでに 810 人年分に相当する開発者の工数を節約しています。 しかし、最も強いシグナルは、どの指標にもありません。5 人中 4 人の顧客が AWS ツールに戻ってきて、より多くのプロジェクトを行っているということです。現在、約半数が複数のトランスフォーメーション機能を利用しています。顧客は価値を見出さない限りツールに戻りません。 パートナーと ISV は複合的な効果を生み出します。30 を超えるパートナー組織が Transform をベースにソリューションとデリバリープラクティスを構築しています。ISV も Transform と統合して事業を拡大しています。Wavicle 社は、AWS Transform による BI モダナイゼーションを AWS Marketplace を通じて提供することを発表しました。AWS のフィールドエンジニアは、お客様が直面するパターンに応じてトランスフォームを行っています。つい先週、あるフィールドメンバーが規制対象の顧客のニーズをサポートするためにインフラのアセスメントを拡大しました。 私たちが学んだ 4 つのことと、それがロードマップをどのように進化させたか 今年、数千のお客様と数十のパートナーと協力してきた結果、私たちのアプローチとロードマップは、次の 4 つの重要な洞察から導き出されました。 1. ユーザーが作業しているところで会うこと。 まず、プログラムマネージャーやアーキテクト向けの専用ウェブアプリを開発しました。しかし、アーキテクトはダッシュボードの中で生きています。開発者とプラットフォームエンジニアは IDE と CLI で生活しています。パートナーはそれぞれ独自の配信環境に住んでいます。誰もが、誰かが中断したところから再開したいと思っています。私たちの答えは、「ユーザーが作業しているところで出会う」という選択へのこだわりを引き継いでいます。 現在、MCP サーバーを介して、エージェントにバンドルされていないアクセスを提供しています。この MCP サーバーは、Kiro powers や Claude Code、Cursor、Codex などのエージェントプラグインなど、新しいアクセスサーフェスを強化します。顧客やパートナーは、これらを既存のワークフローにさらに簡単に統合したり、エージェントを召喚して新しいワークフローを構築したりできます。CLI を使用すると、コードのモダナイゼーションパターンを繰り返し実行できます。すべてのサーフェスは同じコンテキストを共有し、再入力や進行状況の損失はありません。 2. ガードレール付きのフェデレーテッド開発。 私たちのチームは、お客様からのフィードバックを取り入れてあらゆるトランスフォームを構築しています。そして、それを何千人ものプラクティショナーに送り、彼らは私たちが計画していなかった場所にそれを導入します。AWS のフィールドチームはお客様と協力して、問題をその場で解決します。パートナーは独自の視点をもたらします。AI はチームのイノベーションのハードルを下げました。フェデレーテッドモデルはクローズドモデルよりも速く合成されます。しかし、品質と運用の一貫性を保ちながらこの機能を活用することは容易ではありません。だからこそ、お客様、パートナー、ISV、そして当社のフィールドチームがパーソナライズして独自の特製ソースを追加できるように、私たちは初日からコンポーザビリティを備えた Transform を設計に組み込んでいます。 本日 ※ 、エージェントビルダーツールキットを Kiro powers として提供を開始しました。これにより、AgentCore でエージェントを構築して Transform に組み込むことがさらに簡単になります。このコンポーザビリティサービスでは、カスタムエージェントを構築し、それらを AWS Transform 内の機能と組み合わせることができます。 (※) 訳注: 本ブログ(原文)の公開日である 2026/05/14 3. エンタープライズモダナイゼーションはマルチプレイヤーです。 エンタープライズポートフォリオのモダナイゼーションは、開発者が単独で行う作業ではありません。アーキテクトが目標状態を定義します。開発者が実行します。リーダーはレビューと承認を行います。パートナーは大規模に提供します。ボトルネックは、オーケストレーション、ガバナンス、そして社内のセキュリティ境界内のチーム間のコラボレーション能力です。だからこそ、私たちはまず、ソースからターゲットまでの完全なトレーサビリティ、実行するユーザーに依存しない一貫性、既存の IT システムへのコネクターなど、Transform を共同のエンタープライズ基盤として構築しました。 そして本日、新しい S3 コネクタを追加し、IAM ロールをサポートする権限を拡張し、human-in-the-loop とのやりとりを複数の領域に拡大しようとしています。ユーザーはチーム全体でジョブサマリーを見ることができ、次のステップをどの面からでも簡単に通知できます。 4. 聞いて、作って、出荷して、繰り返す。 お客様が初期のユースケースで Transform を使い始めたとき、私たちは彼らが必要としている新しい機能について学びました。移行を行う際には、サーバーを移動するだけではなく、その過程でモダナイズしたいと考えていました。メインフレームでは、顧客は新しいコードを生成するために、言語を増やし、コーディングエージェントとの統合を強化したいと考えていました。Windows ワークロードをモダナイズする際、専門家はトランスフォーメーションの実行方法やプランの編集方法をより細かく制御したいと考えていました。また、お客様は当初の出荷目的以外にも、他の種類の技術的負債を是正したいと考えていました。全体的に見て、お客様はより複雑な移行に取り組むにつれて、反復による制御を強化し、精度と再現性が必要な場合に決定論的アプローチを使用するオプションを求めていました。 本日、私たちは、お客様が Transform でできることをさらに深める機能をすべてのユースケースに導入しています。移行については、VM のコンテナ化やネットワークの再構築など、移行中にお客様がモダナイズできるようになりました。メインフレームのモダナイゼーションでは、PL/I への拡張と Kiro や Claude などのコーディングエージェントとの統合も提供しています。双方向性を高めるため、専門家によるガイダンスと自律的な変革を組み合わせる機能により、Windows のモダナイゼーション機能を強化しました。さらに、組織全体で大規模な技術的負債を是正できる新しいカスタムトランスフォームが数十種類追加されました。 さらに詳しく: 各ユースケースがどのように進化しているか インフラの移行については 、引き続き計画と実施を強化します。あらゆる形式のインベントリをアップロードし、ビジネスコンテキストを追加し、仮説シナリオを検討して、最適化された TCO を数分で算出できます。そして、技術的な制約とビジネス上の制約の両方を考慮して、数千台のサーバーにわたる移行ウェーブを数時間で計画できます。ネットワークやセキュリティ設定を移動すると、プロジェクトが脱線することが多いことがわかりました。オンプレミスネットワークを AWS と同等のネットワークに移行する機能を提供していますが、今回、VPC の最適化、CIDR の適切なサイジング、セキュリティグループの強化、命名の修正など、ネットワークを再構築するための拡張を行っています。これにより、数週間にわたる手作業によるレビューなしにネットワークの移行準備が整います。安全なターゲット環境のプロビジョニングを簡単にするために、ランディングゾーンを自動的に作成して AWS Control Tower と統合するようになりました。また、VMware 以外にも Hyper-V、ベアメタル、クラウドベースのサーバーをサポートするようになりました。モダナイズを希望するお客様は、アプリケーションをコンテナ化して ECS または EKS に移行できます。また、従来の移行ツールである MGN を、プロジェクト指向のアプローチで AWS Transform から手軽に使用できるようにしました。移行後は、構成、検証、コンプライアンスの実施を自動化できるため、何日にもわたる手動のランブックから移行を確定的で繰り返し可能なイベントに変えることができます。また、複数のターゲットアカウントにまたがる、あらゆる商用 AWS リージョンと GovCloud に移行できます。また、発見からデプロイ、移行後の検証まで、すべてのステップが統合され、コンテキストが共有されます。 メインフレームアプリケーションのモダナイゼーションでは 、パイプライン全体でパフォーマンスを向上させ続けました。ファクト生成エージェントは、コード、ランタイムの動作、ビジネスルール、データリネージを分析して詳細な実行グラフを構築し、レガシーコードの意図をビジネスルールとして抽出し、トランスフォーメーション後のコードのすべての機能を元のルールにマッピングして、これまで数ヶ月または数年停滞していたプロジェクトを数週間で完了させます。決定論的分析と AI 駆動の生成を組み合わせることで、これまでベンチマークした中で最も正確で幅広い結果が得られます。私たちは IBM COBOL、VSAM、IMS、Db2 から始め、現在は PL/I にまで拡大しています。PL/I は金融サービス、保険、公共部門で一般的な言語であり、ポインター演算と動的ストレージ割り当てのために歴史的にモダナイゼーションが困難でした。同じ reimagine パターンを使用して、Transform は PL/I ビジネスロジックを構文に依存しない仕様に抽出し、Kiro がインタラクティブに引き継ぎます。開発者は、モダナイズされたアプリケーションがクラウドネイティブなイベント駆動型パターンにデプロイされるまで、生成されたサービス仕様のレビュー、アーキテクチャに関する意思決定の改良、コードとインフラストラクチャの反復など、会話形式でエンジニアリングを進めます。 Windows アプリケーションのモダナイゼーションは 、.NET のアップグレードにとどまりません。エンタープライズ Windows 環境は単なるコードではありません。コード、データベース、アプリケーションの依存関係が絡み合っています。Transform はこれを自律的に処理します。複雑さを評価し、作業を段階的に実行し、トランスフォーメーションを end-to-end で実行します。しかし、アーキテクトが意思決定の指導 (トランスフォーメーションプランの調整、特定の選択肢の上書き、最も複雑な変更の完成) を望む複雑なプロジェクトも見てきました。今では、自律的な流れを断つことなく、いつでも介入し、一歩下がることができます。また、ASP.NET ウェブフォームから Blazor への UI のモダナイゼーションや SQL Server から Aurora PostgreSQL への移行など、フルスタックのモダナイゼーション機能も拡張してきました。拡張されたデータベースモダナイゼーション機能は現在ベータ版で、スキーマ、ストアドプロシージャ、アプリケーションデータアクセスコードなど、スタック内のすべてのオブジェクトをまとめて変換します。始めるのは簡単です。仮想ソースを使用すれば、本番環境データベースへの直接アクセスを待つ必要がなくなります。このワークフローは反復型です。つまり、ある程度の労力で評価を受け、データベース管理者がレビューして承認し、Transform が実行します。構文検証、セマンティック等価性、合成データによる機能検証という 3 段階の検証により、本番データが移動する前に正確性が確認されます。 コードのモダナイゼーションについては 、企業規模で技術的負債をなくすというビジョンに向けて拡大しています。フレームワークの老朽化、EOL (end-of-life) を迎える SDK、依存関係の積み重なりなど、技術的負債は加速しています。また、エージェントが新しいコードを作成するスピードがかつてないほど速くなっているため、顧客は 1 回限りのプロジェクトで可能になるよりも迅速に行動する必要があります。彼らは私たちの既存の Java、Python、Node.js、SDK のアップグレードを使用してきており、お客様の要望により、私たちは何十もの新しいパターンに引き込まれました。現在、Vue.js アップグレード、Scala/Glue アップグレード、Spring Boot アップデート、Log4j から SLF4J、Angular から React へ、Angular から Flutter へ、Progress 4GL から Java へ、PHP リプラットフォームへ、ColdFusion から React/Java へ、Datadog から CloudWatch Monitors へ、JBoss から Spring Boot へ、すぐに使えるトランスフォームを出荷しています。これらはすべて、個々の専門家の手腕に頼ることなく、組織全体やリポジトリ全体に適用できます。そして今、私たちは 3 つの新しいコード評価機能を導入しています。技術的負債の評価は、お客様の優先順位付けに役立ちます。コードリポジトリを指定するだけで、フレームワークの脆弱性、サポート終了後の依存関係、修正すべき重要度など、ポートフォリオレベルの完全な分析が数分で得られます。エージェント対応状況評価では、ドキュメント、パイプライン、テストの完全性をチェックすることで、アプリケーションが実際にどの程度エージェント対応状態にあるかがわかります。モダナイゼーション評価は、クラウドネイティブの成熟へのステップを理解し、AWS ベストプラクティスへの道筋を特定するのに役立ちます。これらの新機能を強化するために、基盤となるエージェントを再設計し、最大 2 倍のパフォーマンスを実現しました。 これから進む道 私たちの使命は、世界のレガシーソフトウェアとインフラストラクチャを継続的にモダナイズすることです。あるワークロードが次に引き込まれます。ある顧客が VM を移行し、トランスフォーメーションが必要な Windows アプリケーションを発見してモダナイズし、コードベースにフレームワークの負債が蓄積されていることに気付きます。このサイクルは決して終わりません。歩調を合わせているサービスは、学習を止めることはありません。 2026 年末までに私たちが実現したい目標はシンプルです。エージェンティックになりたいすべての企業が、専用のプログラムや複数年にわたるロードマップなしで、継続的に Transform を使用してインフラストラクチャとポートフォリオを使える状態できるようにすることです。 モダナイゼーションはプロジェクトではなくバックグラウンドプロセスになります。1 つのワークロードから始めます。サービスはコンテキストを引き継ぎます。次に何をモダナイズするかはあなた次第です。 PS: 5 社の顧客のうち 4 社はすでに事業を拡大しています。次はあなたの番です。 著者 Dr. Asa Kalavade Dr. Asa Kalavade は AWS Transform をリードし、お客様のインフラストラクチャ、アプリケーション、コードの移行とモダナイゼーションを支援しています。以前は、AWS の go-to-market ツールのトランスフォーメーションをリードし、最初の大規模な生成 AI 機能をリリースしました。また、ハイブリッドストレージとデータ転送サービスのマネジメントも担当していました。2016 年に AWS に入社する前、Asa はベンチャーキャピタルによる支援のもと 2 つのスタートアップを設立し、現在もボストンのスタートアップのメンタリングに積極的に取り組んでいます。Asa は、カリフォルニア大学バークレー校で電気工学とコンピューターサイエンスの博士号を取得し、40 件以上の特許を取得しています。 この投稿の翻訳は Mainframe Modernization Specialist Solutions Architect の皆川が担当致しました。原文記事は こちら です。 2026/09/17(木) AWS Mainframe Modernization Day Tokyo 2026 開催のお知らせ メインフレーム基幹系システムの AWS 移行を真剣に検討中のお客様向けの対面イベントを 2026 年 9 月 17 日 (木) に麻布台ヒルズで開催します。参加費は無料です。 詳細・お申し込みは ブログ をご覧ください。

本記事は 2026年7月6日に公開された「 Turn Your Amazon CloudWatch Alarms into Actionable Signals 」を翻訳したものです。 午前2時にアラームが鳴ります。スマートフォンを手に取り、目を細めて通知を見ると、こう書いてあります： 「ALARM: my-service-alarm が ALARM 状態に遷移しました。」 コンテキストなし。アプリケーション名なし。200台のインスタンスのうちどれが問題なのか、そもそもそれが重要なのかすら分かりません。 私もそうでした。誰もがこの経験をしたことがあるはずです。 アラームに対する不満は、「何かがおかしい」と「何をすべきか分かっている」の間のギャップから生まれることが多いです。メトリクス名と閾値しか得られないとき、コンテキストは自分で補うしかありません。どのリソースか、どのアプリケーションか、このサービスはどれくらい重要か？ Amazon CloudWatch アラームは、AWS 環境の問題を検知する最初の防衛線です。このブログ記事では、そのギャップを埋める CloudWatch アラームの設計方法を紹介します。適切なものを監視し、必要なコンテキストを含み、適切な対応をトリガーするアラームです。 適切なデータ – 重要なリソースとメトリクスを監視するようにアラームのスコープを設定し、環境の変化に自動的に適応させ、実際の問題を反映する閾値を設定します。 適切なコンテキスト – 通知に必要な情報を含めます。何が影響を受けているか、どこか、どう対処するか。 適切なアクション – 「メールを送る」を超えて、自動修復、情報を付加した通知、複数ツールが連動し一体化されたインシデント対応へ。 前提条件 この記事に沿って進めるには以下が必要です： Amazon CloudWatch にアクセスできる AWS アカウント 監視対象の既存 AWS リソース（Amazon EC2 インスタンス、AWS Lambda 関数、Application Load Balancer など） CloudWatch アラーム、メトリクス、ダッシュボードを作成・管理する権限 （オプション）タグベースのフィルタリング用に AWS リソースに適用されたリソースタグ 注意：CloudWatch アラーム、ダッシュボード、Amazon EventBridge には AWS 料金が発生します。詳細は Amazon CloudWatch の料金 を参照してください。継続的な課金を避けるため、使い終わったらこれらのリソースを削除してください。 適切なデータ：アラームの対象を重要なものに絞る 次のケースを考えてみましょう。特定の Amazon EC2 インスタンスの CPUUtilization メトリクスに CloudWatch アラームを作成します。問題なく動作します。しかし Amazon EC2 Auto Scaling グループが新しくインスタンスを3台起動すると、新しいインスタンスにはアラームカバレッジがない状態となってしまいます。フリートの75%について監視が欠落した状態です。 あるいは、動的なリソースがあるため、Application Load Balancer の全ターゲットの 平均 レイテンシメトリクスにアラームを作成します。平均は問題なく見えますが、1つのターゲットは5秒のレスポンスを返し、他は50ミリ秒です。平均が問題を隠してしまいます。 単一メトリクスおよび単一集計値に対するアラームは作成・管理が簡単ですが、単一メトリクスに対するアラームは動的な環境でギャップを残し、単一集計値に対するアラームでは平均値により問題が埋もれてしまいます。 動的リソースへの対応 CloudWatch Metrics Insights を使うと、SQL ライクなクエリを書いて、リソース全体のメトリクスを動的に検出・集計できます。インスタンスごとに1つのアラームを作成する代わりに、環境の変化に自動的に適応するクエリで複数リソースにまたがる単一のアラームを作成します： SELECT AVG(CPUUtilization) FROM SCHEMA("AWS/EC2", InstanceId) この Metrics Insights クエリは全ての EC2 インスタンスを自動的にカバーし、手動更新は不要です。EC2 Auto Scaling グループが3台から30台にスケールしても、アラームは適応します。30個の個別アラームを作成・管理する代わりに、1つのアラームだけを管理すれば済みます。 サーバーレスワークロードの場合、 AWS Lambda 関数全体の Duration に対する Metrics Insights クエリを作成することもできます： SELECT AVG(Duration) FROM SCHEMA("AWS/Lambda", FunctionName) コンセプトは同じです。このクエリは Lambda 関数が3個でも30個でもカバーします。 この記事の例では Metrics Insights を使用していますが、 PromQL を使ってメトリクスをクエリ し、クエリにラベルを含めて同じ効果を得ることもできます。 適切なリソースへの絞り込み アラームが動的なリソースに適応するようになりましたが、おそらく特定のアプリケーションや環境をターゲットにしたいはずです。InstanceId のような生のディメンション値では、リソースが何をしているか、どれくらい重要かは分かりません。 カスタムメトリクスの場合、ディメンションを自分で制御できます。Application や Environment などのコンテキストを含め、直接クエリします： SELECT AVG(ProcessingTime) FROM SCHEMA("Custom/PaymentService", Application, Environment) WHERE Application = 'PaymentService' AND Environment = 'Production' Amazon EC2 や AWS Lambda などの AWS サービスは、事前定義されたディメンション（例：InstanceId、FunctionName）でベンダーメトリクスを自動的に発行します。独自の追加ディメンションを追加することはできません。代わりに、 テレメトリ用のリソースタグ でビジネスコンテキストを追加します。 テレメトリでリソースタグを有効にする と、Amazon CloudWatch は既存のリソースタグを Metrics Insights のディメンションとして公開します。リソースに既に適用されているタグ（例：Amazon EC2 インスタンスの Environment=Production や Application=PaymentService）は、WHERE 句や GROUP BY 句で使用可能になります。 SELECT AVG(CPUUtilization) FROM SCHEMA("AWS/EC2", InstanceId) WHERE tag.Environment = 'Production' AND tag.Application = 'PaymentService' これで、アラームは PaymentService アプリケーションに属する本番インスタンスを監視します。それらのタグを持つ新しいインスタンスが起動すると、自動的にアラームに含まれます。死角は生まれず、午前2時に開発環境でアラームが鳴ることもありません。 1つのアラーム、複数のリソース アラームは動的に適応し、適切なリソースをターゲットにするようになりました。しかし、もう1つの問題である問題が平均に埋もれてしまう件を思い出してください。ここで GROUP BY の出番です。クエリに GROUP BY を追加すると、 マルチ時系列アラーム を作成できます。Amazon CloudWatch はクエリ結果の各時系列に対して独立に閾値を評価します。いずれかの時系列が閾値を超えると、フリート平均が正常に見えてもアラームが発火します。 SELECT AVG(CPUUtilization) FROM SCHEMA("AWS/EC2", InstanceId) WHERE tag.Environment = 'Production' AND tag.Application = 'PaymentService' GROUP BY InstanceId GROUP BY を使うと、グラフには複数の時系列（マッチする EC2 インスタンスごとに1つ）が表示されます。これがなければ、単一の集計ラインだけが表示されます。アラーム用のクエリを確認するには、「メトリクスと条件の指定」ステップのグラフで、1つの集計ではなく複数の時系列を評価していることを確認してください。クエリの下にある「Order By」オプションに注意してください。マルチ時系列アラームには必須です。 図1：Metrics Insights クエリが複数のメトリクス時系列を返すアラーム作成画面。 適切なリソースを監視し、それぞれを独立に評価しています。では、どの値でアラームを発火させるべきでしょうか？ 適切な閾値を選ぶ 閾値は「適切なデータ」の最後のピースです。実際の問題をキャッチするアラームと、頻繁に発火しすぎたり、顧客が影響を受けている間も沈黙したままのアラームとの違いを生みます。 静的閾値のアラーム は、ハードリミットのあるメトリクスに適しています。ディスク使用率が100%に近づく、キュー深度が際限なく増大する、常にゼロであるべきエラーカウントなどです。「悪い」値が分かっていれば、設定すればそれで完了です。 しかし、多くのメトリクスには自然な変動があります。ピーク時の CPU 使用率70%は正常かもしれませんが、午前2時の同じ70%は懸念材料です。月曜日に200ミリ秒で正常なレイテンシが、静かな日曜日には異常に高いかもしれません。これらの場合、静的閾値は「敏感すぎる（アラート疲れ）」か「寛容すぎる（インシデント見逃し）」のどちらかを選ぶことを強います。 異常検出 はこの問題を解決します。Amazon CloudWatch はメトリクスのベースラインパターン（日次・週次のトレンドと期待される範囲）を学習し、その学習プロファイルからメトリクスが逸脱したときにアラームを出します。数値ではなく感度を設定します。「閾値をいくつにすべきか分からない」シナリオや、「正常」が時間とともに変化するメトリクスに最適です。異常検出の仕組みの詳細は「 CloudWatch 異常検出の使用 」を参照してください。 適切なコンテキスト：通知をアクション可能にする 「何かがおかしい」と「何をすべきか分かっている」のギャップを思い出してください。コンテキストがそれを埋めます。通知が伝える情報が多いほど、対応は速くなります。十分なコンテキストがあれば、対応を完全に自動化できます。 アラームの種類に関係なく、通知には常にアラーム名と説明、状態変更、変更理由、閾値が含まれます。このうち、名前と説明は完全にコントロールできる2つの要素であり、対応者が最初に見るものです。適切に書かれた名前と説明は多くのコンテキストを伝えることができます。アラーム名は素早いシグナルを与えます：本番、決済、CPU。説明にはドキュメント、ランブック、ダッシュボード、エスカレーションパスへのリンクを記載します。 Alarm Details: - Name: prod-payments-cpu - Description: Alarm on payments service CPU. Impact: Payment processing may slow. Runbook: https://wiki.example.com/runbooks/payment-cpu Dashboard: https://console.aws.amazon.com/cloudwatch/... Escalation: #payments-oncall - State Change: OK -> ALARM - Reason for State Change: Threshold Crossed: 1 out of the last 1 datapoints [3.0705 (15/06/26 12:49:00)] was more than the threshold (90.0) (minimum 1 datapoint for OK -> ALARM transition). - Timestamp: Monday 15 June, 2026 12:54:30 UTC - AWS Account: xxxxxxxxxxxx - Alarm Arn: arn:aws:cloudwatch:us-east-xxxxxxxxxxxx:alarm:prod-payments-cpu ダッシュボード：問題の全体像を見せる アラームは単一の時点で発火します。値は分かりますが、どれくらい速く変化しているか、より広い影響は分かりません。ダッシュボードはより大きな絵を見せることができます。メトリクスの時間的な挙動（スパイクか、徐々に劣化しているか？ いつ変化し始めたか？）に加え、そのアラームが発火したときに関連する情報の表示、つまりアプリケーションの RED メトリクス（Requests、Errors、Duration）と関連リソースです。対応者が簡単にアクセスできるよう、アラームの説明にダッシュボード URL を含めてください。 メトリクスクエリからコンテキストを得る 名前と説明は自分で追加するコンテキストであり、全てのアラームタイプの通知イベントにはアラーム詳細が含まれます。しかし、アラーム通知は自動的にコンテキストも運びます。何が含まれるかはアラームの構築方法に依存します。 単一メトリクスアラーム ：メトリクス名前空間、名前、ディメンション、統計、メトリクス値。 マルチ時系列アラーム（GROUP BY 付き Metrics Insights） ：Metrics Insights クエリ、およびどの時系列が閾値を超えたかを特定する Contributor Attributes。 単一メトリクスアラーム通知は、どのメトリクスが閾値を超えたかを伝えます： Monitored Metric: - MetricNamespace: AWS/EC2 - MetricName: CPUUtilization - Dimensions: [InstanceId = i-xxxxxxxxxxxxxxxxx] - Statistic: Average 例えば、Amazon EC2 CPUUtilization のアラームは InstanceId ディメンションを表示し、Lambda Duration のアラームは FunctionName を表示します。ここで表示される内容は、アラーム作成時に選択したメトリクスとディメンションに依存します。 Metrics Insights クエリで作成されたアラームでは、特定のインスタンスの情報を得る唯一の方法は、クエリで GROUP BY 句を使用することです。通知には Contributor Attributes セクションが含まれ、クエリのどの時系列が閾値を超えたかを正確に示します： Contributor Attributes: - InstanceId i-xxxxxxxxxxxxxxxxx - tag."Environment" Production - tag."Application" PaymentService Threshold: - The alarm is in the ALARM state when the metric is GreaterThanThreshold 90.0 for at least 1 of the last 1 period(s) of 300 seconds. Monitored Metrics: - MetricExpression: SELECT AVG(CPUUtilization) FROM SCHEMA("AWS/EC2", InstanceId) GROUP BY InstanceId, tag.Environment, tag.Application ORDER BY AVG() DESC GROUP BY に InstanceId、tag.Environment、tag.Application を含めたため、Contributor Attributes は3つの値全てを表示します。これが「あるインスタンスが高負荷」と「本番環境の決済アプリに問題がある」の違いです。 複合アラームによる影響レベルのシグナル化 個々のアラームは個々の症状を伝えます。 複合アラーム は複数の症状を単一のヘルスシグナルに要約します。 複合アラームは、ブール論理を使って複数の子アラームの状態を組み合わせます。例えば、エラーレートアラームとレイテンシアラームの 両方 が ALARM 状態のときのみ発火する複合アラームは、エンジニアに2つの別々のアラームではなく影響レベルのシグナル（「サービスが劣化している」）を与えます。 複合アラームはノイズも削減します。10個の子アラームがあり、3個以上が同時に発火しているときだけページしたい場合、複合アラームがそのロジックを処理します。 適切なアクション：通知から解決へ アラームが発火しました。適切なリソースにスコープを合わせ（適切なデータ）、通知は何が影響を受けているかを伝えます（適切なコンテキスト）。そのコンテキスト（アプリケーション、環境、特定のリソース）があるため、通知以上のことができます。自動化できます。 多くの場合、アラームアクションは「誰かにメールが届く」です。しかし、問いかける価値のある質問があります： このアラームが発火したとき、実際に何が起こるべきでしょうか？ アクションを自動化する 一部のアラームは人間が調査、判断、調整する必要があります。これらには、GROUP BY、タグ、ディメンションを使い、迅速な対応に十分なコンテキストを通知に含めてください。 しかし、対応が決定論的な場合（タスクの再起動、フリートのスケール、障害インスタンスの復旧など）、アラームをそのアクションに直結します。Amazon CloudWatch は EC2 アクション（停止、再起動、復旧）、 Amazon EC2 Auto Scaling ポリシー、または AWS Lambda 関数を呼び出せます。人間の介入は不要です。 AWS Well-Architected フレームワーク はこれを明示的に述べています。人間が毎回同じ方法で同じランブックに従うなら、それは自動化の候補になります。 複雑な対応を連動させる Amazon CloudWatch は アラームの状態変更時に Amazon EventBridge にイベントを送信 します。Amazon EventBridge を使えば、これらのイベントを複数のターゲットに送信できます。アラームが発火したとき、同時に以下を実行できます： PagerDuty 経由でオンコールエンジニアにページする チケット管理ツールでインシデントを作成する コンテキストを付加した専用 Slack チャンネルに投稿する 単一のアラームイベントが、インシデント管理ワークフロー全体にわたる連携した対応を開始します。 計画メンテナンス中のアクション抑制 新バージョンのデプロイ、ロードテストの実行、インフラの更新中に、アラームが自動修復を呼び出したり、予期された動作でエンジニアにページしたりすることは望ましくありません。 CloudWatch アラームミュートルール を使えば、事前定義された時間ウィンドウ中にアラームアクションを一時的に抑制できます。 アラームアクションの無効化 （誰かがアラームを再度有効にすることを覚えている必要がある）とは異なり、ミュートルールは特定の時間ウィンドウ用です。アラームは評価と状態変更を続けますが、ミュートウィンドウ中はアクションを呼び出しません。ミュートルールは特定のアラームにスコープできます。デプロイ対象のサービスのアラームをミュートしながら、残りの監視は完全にアクティブのままです。 ミュートルールがなければ、デプロイは不要なアラームノイズを生みます。予期された動作でアラームが発火し、対応者はそれを無視するようになり、アラームシステムへの信頼が損なわれます。 実践的なパターン：CI/CD パイプラインでデプロイ前にミュートルールを作成し、デプロイと安定化の時間をカバーする有効期限ウィンドウを設定します。ウィンドウの期限切れ後にアラームが発火すれば、デプロイノイズではなく実際の問題だと分かります。 全要素の統合 午前2時のアラームに戻りましょう。適切なデータ、適切なコンテキスト、適切なアクションを組み合わせるとこうなります： アラームは GROUP BY とリソースタグによるフィルタリングを使った Metrics Insights クエリを使用するため、フリート全体を自動的にカバーし、適切な環境とアプリケーションにスコープを合わせます。 通知は特定のインスタンス、環境、アプリケーション名を含み、さらに影響の説明とランブックおよび RED メトリクスを表示するダッシュボードへのリンクを含むアラーム説明があります。 アラームアクションは既知の問題に対する自動復旧を呼び出します。復旧に失敗した場合、または自動化できない場合、コンテキストを付加してインシデント管理プロセスにエスカレーションします。 午前2時にアラームが発火します。インスタンスは自動復旧されます。アラームは OK に戻ります。誰もページされません。 まとめ CloudWatch アラームは、適切なリソースを監視し、必要なコンテキストを含み、適切な対応をトリガーするときに最も効果的です。GROUP BY 付き Metrics Insights クエリを使用し、タグと説明で通知を充実させ、可能な場合は対応を自動化することで、アラームをノイズからアクション可能なシグナルに変えることができます。 さっそく始めましょう 実践的なスタートパスを示します： 主要サービスの Amazon CloudWatch 設定で テレメトリでリソースタグを有効にします 。 既存リソースの AWS 推奨アラーム をレビューします。 最も価値の高い静的アラームを GROUP BY と タグベースのスコープ 付き Metrics Insights クエリ に変換します。 明確な静的閾値がないメトリクスに 異常検出 を追加します。 有用なリンク付きの 意味のあるアラーム説明 を書きます。 重要なサービスの ダッシュボード を作成し、アラーム説明にリンクします。 デプロイウィンドウと計画メンテナンス用の アラームミュートルール を設定します。 重要なサービスの 複合アラーム を作成します。個々の症状ではなく影響レベルのシグナルを表面化させます。 既知の解決策に対して 自動アクションを実装 します。人間の判断が必要な問題のために、人間の注意力を温存します。 全てを一度にやる必要はありません。1つのサービスから始め、パターンを正しく構築し、そこから拡張してください。午前2時のあなたが感謝するはずです。 クリーンアップ CloudWatch アラーム、ダッシュボード、EventBridge ルールには AWS 料金が発生します。詳細は Amazon CloudWatch の料金 を参照してください。継続的な課金を避けるため、使い終わったらこれらのリソースを削除してください。 TAGS: Amazon CloudWatch , Best Practices , Management & Governance , Management Tools , Monitoring , observability Helen Ashton Helen Ashton は AWS のシニアカスタマーサクセススペシャリストであり、オブザーバビリティを専門としています。お客様のビジネス課題の解決とクラウドジャーニーの推進を支援することに情熱を注いでいます。仕事以外では、音楽、サイクリング、ガーデニングを楽しんでいます。 Gagandeep Singh Gagandeep Singh は AWS のシニアテクニカルアカウントマネージャーであり、エンタープライズのお客様のクラウドジャーニーを支援しています。18 年以上の IT 経験を持ち、AI とセキュリティに情熱を注いでいます。仕事以外では、写真撮影、旅行、好きなスポーツチームの観戦を楽しんでいます。 翻訳は Technical Account Manager の 桜山 陽平 が担当しました。

本ブログは 2026 年 8 月 5 日に公開された AWS Blog、” AWS partners with Anthropic and OpenAI to bring AWS Continuum into developer workflows ” を翻訳したものです。 お客様は、世代を重ねるごとに改善され続けるモデルを利用できます。新しい世代のモデルは、より大きなコンテキストウィンドウ、より強力な推論能力、より低いトークンコストをもたらします。最も強力な AI によるセキュリティは、最も適切なモデルとお客様固有の環境に関する深い知識を組み合わせたツールから生まれます。 AWS Continuum for code vulnerabilities (プレビュー) は、マシンスピードでコードのセキュリティ保護を支援する、まさにそのためのツールとして構築されています。本日、AWS は Anthropic および OpenAI との協業を発表します。これにより、AWS Continuum は、コードが書かれる開発者ワークフローである Anthropic Claude Code、OpenAI Codex、Kiro に直接組み込まれます。開発者はこれらの統合を利用して、既存のワークフローの中で脆弱性の発見、コンテキストに基づく優先順位付け、検証、修復を行うことができます。 モデルは賢くなり続けている AI モデルは急速に進化しています。世代ごとに新しい能力が加わり、モデルによって得意なタスクも異なります。最新のフロンティアモデルは、人間のセキュリティチームが手作業で追跡すると数週間かかるような多段階の攻撃経路を推論し、脆弱性を特定できるようになっています。 これは検出における真のブレークスルーですが、セキュリティチームには新たな課題をもたらします。検出結果は増え、複雑さも増し、自社の環境でどの問題が最も重要か、どう対処するかを判断する必要が生じます。お客様が直面する次の課題は、これらのモデルを検出から修復までをつなぐ単一のインターフェイスに変えるための、適切なハーネスとオーケストレーションを構築することです。これこそが、私たちが Continuum を作る際に目指したものです。Continuum は多様なモデルを組み合わせ、プロセスの各部分で最も効果的なモデルを使用します。 また、AWS は Frontier Model Forum とも連携しています。これは、共通の安全基準、評価手法、ベンチマークを開発する業界コンソーシアムであり、これらのモデルを共同で効果的に評価できるようにするものです。さらに、モデルプロバイダーとセキュリティ性能の共通ベンチマークにも取り組んでおり、Continuum やその他の AWS セキュリティ製品において、各タスクに最適なモデルを使用できるようにしています。 ハーネス AI ハーネスとは、モデルを包み込み、ツール、ガードレール、メモリ、ワークフローに接続して成果を生み出すオーケストレーションレイヤーです。モデルをエンジン、ハーネスをその周囲のすべてと考えてください。高性能な車には、その両方が必要です。 ハーネスはますます複雑になっています。チームは複数のモデル、エージェントを呼び出すエージェント、動的なワークフローをつなぎ合わせており、モデル、エージェントフレームワーク、ツール統合の革新がもたらす絶え間ない変化に対応し続けています。 その複雑さの結果として、お客様はモデルとツールにまたがる統合レイヤーを管理するために、シャドーインフラストラクチャを構築しています。状況が変わるたびにセキュリティとガバナンスのコントロールが壊れる可能性があり、チームは見直しと更新を迫られます。 こうした課題はモデルだけにとどまりません。さまざまなモデルや開発環境を、お客様の環境全体にわたるツール、コンテキスト、コントロール、ワークフローと接続するために必要なオーケストレーションにおいても生じます。AWS は、この複雑さの管理を AWS が解決すべき重労働 (heavy lifting) と捉えています。私たちはハーネスをインフラストラクチャとして扱い、AWS のコアインフラストラクチャにおけるアイデンティティ、ディスカバリ、ポリシー適用、可観測性、コンプライアンスに適用しているのと同じ厳格さで取り組んでいます。 Continuum の登場 AWS Continuum for code vulnerabilities は、脆弱性を発見し、お客様のビジネスのコンテキストの中で優先順位を付け、サンドボックスで検証し、マシンスピードで修復を提供します。内部的には、Continuum はエージェントチームによるループアーキテクチャです。適切なモデルの選択、お客様環境への接続、コンテキストの中で検証されたセキュアなコードの提供、そのすべてをオーケストレーションする高度なハーネスです。オーケストレーションがどのように動いているか、最新リリースで何が変わったかを意識する必要はありません。 Anthropic および OpenAI との協業 AWS は Anthropic および OpenAI と協力し、コードが書かれる開発者ワークフローに Continuum を組み込もうとしています。 動作の仕組み: Claude Code、Codex、Kiro のコーディング環境内で、オンデマンドの脆弱性スキャンが潜在的な問題を特定し、検出結果を Continuum に送信します。Continuum は、お客様の AWS 環境のコンテキスト (設定、 AWS Identity and Access Management (IAM) ポリシー、ネットワークトポロジー、露出面) の中でそれらに優先順位を付け、サンドボックスで検証します。その後、優先順位付けされたコンテキスト付きのインテリジェンスをコーディングアシスタントに返し、コーディングアシスタントはそれに応じて提案を調整します。 これにより、従来は複数のステップと複数のチームにまたがっていたプロセス (記述、スキャン、トリアージ、優先順位付け、修正、再スキャン) が、コード提案そのものという単一の成果に集約されます。2 つのモード、1 つの成果: 既存のコードの場合: AWS の Continuum for code vulnerabilities を使用して、環境全体で脆弱性の発見、優先順位付け、検証、修復を行います。 新規のコードの場合: Codex、Claude Code、または Kiro 内の Continuum プラグインを使用して、開発環境でセキュリティ検証済みの提案を受け取ります。 初期のデザインパートナーは、すでに成果を実感しています。 「AWS Continuum はソースコードとエンタープライズナレッジを結び付け、チームがセキュリティ脆弱性を正確に特定し、指摘された問題が本当に意味のあるものかを確認できるようにします。これにより、本当に重要なこと、つまり深刻な脆弱性を修正するまでの時間が短縮されます。」 – Mike Johnson 氏、CISO、Rivian 次のステップ AWS Continuum for code vulnerabilities は、AWS を通じてプレビューで利用できます。 AWS Continuum からサインアップしてアクセスをリクエストしてください。 Claude Code、Codex、Kiro のワークフローへの Continuum の統合 は近日提供予定です。 本記事に関するフィードバックがある場合は、以下の コメント セクションからコメントを送信してください。 著者について Chet Kapoor Chet は、Amazon Web Services の Search, Security, and Observability 担当バイスプレジデントです。エンタープライズテクノロジーで 20 年以上、API からクラウド、AI に至るプラットフォームシフトの中で、急成長や買収、IPO を通じて事業を構築・拡大してきました。ビルダー思考と運用経験、お客様志向で、新しいテクノロジーの安全かつ大規模な導入を支援しています。 翻訳は Security Solutions Architect の 松崎 博昭 が担当しました。

本記事は 2026 年 8 月 6 日に公開された Libby Clark、James Ward による “ AWS Supports Agent Plugins: An Open Standard for Portable Agent Extensions ” を翻訳したものです。 MCP サーバーやエージェントスキルを構築したことがある方なら、それをパッケージ化するには 1 つのクライアント向けに調整し、別のクライアント向けに書き直し、チームで使うツールごとにその作業を繰り返すことになるとご存知でしょう。 Agent Plugins 1.0.0 は、AI エージェントの拡張機能に共通のパッケージ形式を提供するオープンソースかつベンダーニュートラルな仕様です。拡張機能を 1 度パッケージ化すれば、Kiro、VS Code、Cursor など、この仕様を実装した任意のクライアントに配布できます。 AWS は、Cursor、Microsoft、OpenAI、Vercel と並ぶ Agent Plugins Technical Steering Committee の設立メンバーであり、エージェント間でスキルや MCP のパッケージングにポータビリティをもたらすこの標準を支持できることを嬉しく思います。すでに AWS Agent Toolkit を対応させており、 Kiro でも Agent Plugins 仕様のサポートを順次展開しています。 拡張機能とは、スキル、MCP サーバー、フック、サブエージェントのように、AI エージェントに新たな能力を与えたり、外部ツールやデータへ接続したり、エージェントに代わってタスクを自動化したりする再利用可能なコンポーネントのことです。Agent Plugins の初版では、現在最も採用が進んでいる 2 つのコンポーネントタイプ、Agent Skills と MCP サーバーを標準化しています。フックやカスタムエージェントといった追加の拡張機能タイプは、将来のバージョンに向けたロードマップに含まれています。 モデル選択が、どの AI を使うかについての柔軟性を開発者に与えるのに対して、Agent Plugins は、その選択を特定のクライアントやプロバイダーに縛られることなく、AI がどのツールを使うかについての柔軟性を与えます。 エージェント型 AI にとってオープン標準が重要な理由 これまで、エージェント拡張の管理は、パッケージマネージャー登場前のライブラリ配布や、標準的なコンテナ形式が確立する前のアプリケーション配布に少し似ていました。JavaScript が package.json という共通の形式に落ち着いたことで、npm、yarn、pnpm のいずれからも同じパッケージをインストールできるようになり、手作業でのスクリプトダウンロードやコピー&ペーストによる依存関係管理は終焉を迎えました。同様に、OCI がベンダーニュートラルな形式をコンテナイメージにもたらしたことで、1 度ビルドしたイメージが Docker、containerd、Podman、あるいは仕様に準拠した任意のランタイムで実行できるようになり、Docker 独自のイメージ仕様を置き換えました。オープン標準は、その上に築ける共通の土台を全員に提供します。 AWS は、オープンソースとオープン標準による構築こそが AI アーキテクチャの柔軟性と相互運用性を保つと考えています。オープン標準は、開発者に自らの条件でワークロードを組み合わせ、拡張し、移行する自由を与えます。私たちが Model Context Protocol (MCP)、 Agent Client Protocol (ACP)、 x402 、そして Agent Plugins のような 標準に投資している のは、モデル、ツール、クライアントに至るまで、皆さんが選んだいかなる決定も特定のベンダーに縛られないようにするためです。 Agent Plugins とは Agent Plugins は、ツール間で容易に共有・バージョン管理・インストールできるように、エージェント拡張をどうパッケージ化するかを定義します。内部的には、プラグインはディレクトリであり、その中にプラグインの識別情報とエントリーポイントを宣言する JSON マニフェストと、コンポーネントの固定配置場所を持ちます。互換性のあるクライアントは、ディレクトリ構造をスキャンして内部に何があるかを検出します。skills/ フォルダーがあればスキルを読み込み、MCP 設定があればそれらのサーバーに接続します。 フォーマットは意図的に小さく保たれています。バージョン 1.0.0 では、Agent Skills (エージェント向けの再利用可能な指示およびリソース) と MCP サーバー (外部ツールやデータへの接続) を標準化しています。クライアントがプラグインをどのようにインストール、表示、配布するかは、意図的に仕様の対象外としています。これらは、共通のフォーマットを共有しつつ、クライアントが差別化できる領域だからです。 これは正しい設計思想です。共有フォーマットは、相互運用に不可欠なコンポーネントを定義したうえで、それ以上のことには介入しないべきです。拡張機能の作者は 1 度パッケージ化するだけで、互換性のあるクライアントが同じ構造からコンポーネントを検出して読み込みます。クライアントは、名前空間で分離した拡張機能によってプロプライエタリな機能を追加する自由を保ちつつ、ポータブルなコアを煩雑にしないでいられます。 Agent Plugins はコミュニティによる取り組み Agent Plugins は、エージェント向けツールを構築するあらゆるチームが独立して直面してきた実務的な課題から生まれました。拡張機能の作者は同じコンポーネントを異なるクライアント向けに調整する冗長な作業を強いられ、開発者は互換性のないパッケージング慣習を渡り歩くことで時間を失っていました。 Vercel が仕様の初期ドラフトを公開し、その後、それぞれのやり方でこの問題を解決してきた各社のチームからなるワーキンググループを結成しました。AWS、Cursor、Microsoft、OpenAI、Vercel の代表者たちは、日々開発者が使うエージェントクライアントを構築してきた自らの経験を持ち寄って、共同で仕様を洗練させました。このグループは、1 社のプロダクトロードマップがフォーマットの方向性を左右することがないようにするガバナンス構造を確立しました。 その結果として得られたのは、拡張機能の作者とクライアント実装者の両方の視点が場に揃っていたからこそ実現できた、両者の実際のニーズを反映した仕様です。Technical Steering Committee には設立 5 社すべてからコアメンテナーが参加しており、プロジェクトのコントリビューションプロセスと技術的な意思決定は完全に公開されています。 これこそが、最良の標準が生まれるあり方です。1 社のビジョンをエコシステムに押し付けるのではなく、共有された課題を各社が共に解決していく中での収束から生まれるのです。ツール連携における MCP、可観測性における OpenTelemetry、そしてそれ以前のコンテナ標準でも、私たちは同じパターンを目の当たりにしてきました。 AWS による Agent Plugins のサポート 私たちは、開発者が AWS 上で AI エージェントを構築・拡張する 2 つの主要なオファリングである Kiro と AWS Agent Toolkit の両方で、Agent Plugins のサポートをローンチと同時に提供します。 Kiro は、開発ライフサイクル全体を通じてエージェントを開発者の意図に沿わせ続けるための spec、フック、自動テストといったステアリング機構を備えたエージェントハーネスです。今回のローンチにより、インストール可能なパッケージによって Kiro を拡張する Kiro Powers が Agent Plugins 仕様をネイティブにサポートするようになりました。開発者は、Skills と MCP サーバーをまとめてバンドルしたプラグインをインストールでき、それぞれのコンポーネントを手動で構成することなく、シームレスに動作する機能を利用できます。 AWS Agent Toolkit は、AI コーディングエージェントが AWS 上で信頼性高く構築できるようにする、公式にサポートされた MCP サーバー、スキル、エージェントプラグインのコレクションです。これらは複数のパッケージング形式で提供され、Lambda、S3、DynamoDB、CDK などのサービスをカバーする 30 以上の厳選されたスキルを、複数のプラグインとしてバンドルしています。新しい Agent Plugins 仕様をサポートすることで、異なるハーネスやコード支援ツールが同じパッケージング形式を利用できるようになり、AWS Agent Toolkit のようなエージェント拡張のパッケージをエージェントがどのように取り込むかに関するフラグメンテーションが最終的に減少します。 今後の展望 Agent Plugins 1.0.0 は出発点です。仕様は、ポータビリティの恩恵を受ける追加のコンポーネントタイプをエコシステムが見出すにつれて進化していきます。Technical Steering Committee では、フック、サブエージェント、その他の拡張機能タイプが将来のバージョンでどのように Plugins に加わりうるかについて、すでに検討が始まっています。 私たちがこの取り組みに真剣に向き合っているのは、オープン標準が開発者の生産性にもたらす効果を見てきたからです。オープン標準は、優れたツールがそれを必要とする人々の手元に届くのを妨げている摩擦を取り除きます。今日、その対象はエージェント拡張ですが、エージェント型 AI エコシステムが進化を続けるにつれて、さらに多くの標準が生まれてくると私たちは考えています。 仕様の詳細は agent-plugins.org でご確認いただけます。 GitHub リポジトリ を確認したり、Kiro で最初のプラグインをインストールしたりしてみてください。 著者について Libby Clark Libby Clark は AI に注力するプリンシパルオープンソースストラテジストです。 James Ward James Ward は AWS のプリンシパルデベロッパーアドボケイトです。James は世界を飛び回りながら、エンタープライズ開発者が信頼性の高いシステムを構築する方法を学ぶのを支援しています。現在は、Spring AI、Embabel、Strands Agents、Amazon Bedrock、MCP、A2A を用いた AI エージェントシステムを開発者が構築できるように支援することに注力しています。 翻訳は Solutions Architect の吉村が担当いたしました。