本記事は 2026 年 6 月 25 日から 26 日に幕張メッセで開催された AWS Summit Japan 2026 の開催報告です。AWS for Industries Zone に出展した株式会社 SUMCO のブース展示 「Amazon Redshift × 生成 AI で挑む 半導体ウェーハメーカーの DX」 の内容を、SUMCO と AWS が共同で振り返ります。 図 1: AWS Summit Japan 2026 の SUMCO ブース。実物の 300mm シリコンウェーハとともに、生成 AI を活用したデータ分析の取り組みと AWS 基盤のアーキテクチャを展示した。 SUMCO と半導体を支えるシリコンウェーハ SUMCO は半導体デバイスの基板材料となるシリコンウェーハの製造・販売を手がける企業です。社名は「Silicon United Manufacturing Corporation」に由来します。スマートフォンや自動車、データセンターに至るまで、あらゆる半導体デバイスの起点となる素材がシリコンウェーハであり、その品質は半導体の進化を根底から支えています。 シリコンウェーハは珪石から多結晶シリコンを精製し、単結晶を引き上げてインゴットとし、スライシング・ラッピング・ポリッシング・洗浄といった多数の工程を経て、鏡面ウェーハとして出荷されます。この一連の製造プロセスの各工程で、製造装置・検査装置から膨大なデータが生成されます。 図 2: SUMCO のデータ活用。各工程の検査情報・経路情報・製造装置の稼働情報を Amazon Redshift に集約し、データの意味を解釈してシリコンウェーハの状態を推定する。 背景と課題：ビッグデータを“価値”に変えるために SUMCO が目指すのは、単一工程内の改善にとどまらず、製造装置・検査装置から生じる膨大なデータ、つまりビッグデータを収集・解析することで複数工程をまたいだ改善を実現することです。前工程が後工程に与える影響を把握し、工程間の装置の組み合わせまで見据えて最適化することで、より高精度・高品質なシリコンウェーハの製造につなげます。 一方でビッグデータを実際の価値へと変えていくには乗り越えるべきテーマがありました。分析を担う人材と製造現場とでは、得意とする領域が異なります。データ分析の専門人材であるデータサイエンティストは分析手法に、製造現場は工程や品質の知見に、それぞれ強みを持ちます。この双方の強みを結びつけ、限られた専門人材だけに頼るのではなく、現場を含む組織全体でデータを活用できる状態をつくることが取り組みの出発点です。 取り組み：3 つの要素で組織のデータ活用を底上げする AWS Summit での展示は、SUMCO のデータ活用を次の 3 つの要素でご紹介しました。セキュアな基盤という土台と、その上で動く RedPulse・SynchroFabAI という 2 つのデータ活用の取り組みです。RedPulse と SynchroFabAI はいずれも SUMCO が開発した仕組みの名称です。 A. 基盤 セキュアな AWS 環境。製造データをクラウドで安全に扱うための土台 B. RedPulse 大量データの加工・比較を支えるデータ処理の仕組み C. SynchroFabAI 生成 AI で自然言語によるデータ解析を行う取り組み 図 3: データ分析基盤の全体像。SynchroFabAI（生成 AI アプリ）と RedPulse（データパイプライン＋データ処理）が、Amazon Redshift を中核とする基盤とともに構成される。 A. 基盤：製造データを安全にクラウドで活用する 製造データをクラウドで安全に活用するための土台となるのが、AWS 上に構築されたセキュアな基盤です。半導体業界はセキュリティ要件が厳しく、製造データをクラウドで扱うこと自体が挑戦的な取り組みであるため、その土台には堅牢なガバナンスが不可欠でした。 SUMCO の AWS 基盤は工場と AWS を安全につなぎ、用途ごとにアカウントを分離した構成をとっています（図 4）。この基盤はネットワーク統制と権限統制の 2 つの観点で運用されています。 ネットワーク統制（閉域網の構築） AWS 環境からインターネットへの直接通信を禁止 AWS Direct Connect を用いたオンプレミスと AWS 間の専用ネットワーク接続 権限統制 AWS Identity and Access Management (IAM) による必要最小限の権限付与 AWS Organizations のサービスコントロールポリシー (SCP) による組織全体への予防的統制 AWS 環境に対して社内 IP アドレス以外からのアクセスを制限 図 4: AWS 基盤の全体構成。Organization・User・DWH のアカウントを分離し、AWS Transit Gateway で接続。工場からは AWS Direct Connect 経由で取り込み、DWH アカウントの Amazon S3・Amazon Redshift にデータを集約する。 運用から、社内向けシステムの企画・ソリューション提供へ SUMCO 社内の AWS チームの役割は基盤の運用にとどまりません。IAM の最小権限設計や AWS サービスの払い出し、社内向けの AWS サポート・教育を担いながら、さらに AWS の技術を使った社内向けシステムの企画から、現場へのソリューション提供までへと取り組みを広げています。この社内 AWS チームの活動が、次に紹介する 2 つのデータ活用の取り組みを支えています。 図 5: SUMCO 社内 AWS チームの取り組み。基盤構築・運用・教育を土台に、社内向けシステムの企画とソリューション提供へと役割を広げている。 B. RedPulse：データ加工の知見を組織で共有する RedPulse は大量データの加工・比較を支えるデータパイプラインとデータ処理の仕組みです。製造装置が生成する製造中の時系列データを抽出し、複数の装置や時間帯といった条件で比較できます。これまで熟練者の経験に根ざしていたデータ加工の手順を仕組み化し、誰もが同じ手順で大量データを扱えるようにすることで、分析の入口となる作業を組織の共有資産にします。 図 6: RedPulse。製造中の時系列データを抽出し、複数の装置・時間の条件で比較できる。 実装面では、工場から取り込んだデータを Amazon Simple Storage Service (Amazon S3) に CSV / Parquet 形式で格納します。その後 AWS Lambda や Amazon Elastic Container Service (Amazon ECS) でデータパイプラインを通じた処理を実行し、 Amazon Redshift を中核とするデータ分析基盤に集約しています。 図 7: RedPulse のアーキテクチャ。工場のデータを Amazon S3 に格納し、AWS Lambda・Amazon ECS でデータパイプラインとデータ処理を行い、Amazon Redshift に集約する。 RedPulse で取得・整形した時系列データは、機械学習による品質予測や、品質に強く寄与するパラメータの要因分析へとつながります。RedPulse は、こうしたデータ分析業務を支える役割を担っています。 C. SynchroFabAI：生成 AI で意味づけ・分析の知見を組織で共有する SynchroFabAI は生成 AI を活用して自然言語でビッグデータを解析する取り組みで、本記事執筆時点では PoC 段階です。データの意味を説明し、分析手法を提案・実行することで、分析の専門人材でなくても自然言語での対話だけでデータ分析を進められることを目指しています。 図 8: SynchroFabAI。自然言語での問いかけに対し、AI がデータの意味を説明し、分析手法を提案・実行する。 実装面では、オンプレミス環境に配置した AI エージェントの Cline が Amazon ECS 上に構築した Model Context Protocol (MCP) サーバーを介して、AWS 上の Amazon Redshift のデータソースを参照します。Cline の推論においては、 Amazon Bedrock で大規模言語モデルを利用します。Cline の振る舞いは Rules や Skills、および分析手法を記述した参照ファイルによって制御しています。 図 9: SynchroFabAI の実装。オンプレミスの Cline から、MCP を介して AWS 上の Amazon Bedrock・Amazon Redshift を利用する。 SynchroFabAI では、AI に持たせる知識の設計、すなわち製造現場の知見のうち何を、どのような形式で AI に渡すかの見極めを工夫しています。大量データへのクエリ生成を助ける専門用語集や、データと製品状態を紐づけるためのカタログ情報を AI に与え、「異常状態の推測」や「因果関係の推測」といった役割を担わせます。本 PoC では、データ・意味づけ・分析での解釈・AI の振る舞いという各層について、AI にどこまでの役割を担わせられるか、そしてデータと製品状態の紐づけや分析手法の選択・結果解釈の妥当性を検証しています（図 10）。こうして確立した意味づけ・分析の知見を仕組みに蓄積し、組織全体で共有・再利用していくことを目指しています。 図 10: SynchroFabAI へのデータ分析フローの実装。データ・意味づけ・分析での解釈・AI の振る舞いの各層について、AI に担わせる役割と、PoC で検証している内容を対応づけている。 “RedPulse では、Amazon Redshift の処理性能を引き出すことを念頭に SQL を作成・チューニングすることで、これまで時間を要していた大量データの集計が現実的な時間で回るようになり、Amazon Redshift のパワーを強く実感しました。SynchroFabAI では、生成 AI がデータの意味づけまで踏み込んで担う点が新鮮であり、集計や可視化の先にある「解釈」の領域にまで仕組みを広げられることは、現場のデータ活用の裾野を大きく広げると感じています。加えて、SynchroFabAI の設計にあたっては、専門用語集やカタログ情報として生成 AI に渡す知識の設計、そして意味づけ・分析手法の提案までを AI に担わせ、結果の妥当性の確認は人が担うという役割分担を、データサイエンティストと議論を重ねながら形にしていきました。実装側の視点だけでは辿り着けない分析の観点や知識に触れられたこの設計の過程こそ、本取り組みならではの面白さだったと感じています。” ― 株式会社 SUMCO AI推進本部 ICT推進部 荒木 亮 氏 今後の展望：データ活用を一部の専門人材から組織全体の力へ SUMCO の取り組みは単なる分析ツールの導入にとどまりません。多品種生産という SUMCO の事業価値を支えるには、品種・工程に合わせた分析やアプリケーションが必要になります。データ加工の知見である RedPulse と、意味づけ・分析の知見である SynchroFabAI を組織の共有資産としていくことで、限られた専門人材への依存を減らし、現場を含む組織全体のデータ活用の底上げを図ります。 セキュアな AWS 環境という土台の上に、データ基盤の確立、そして生成 AI の活用へと、SUMCO は着実に歩みを進めてきました。この積み重ねの先に、現場を含む組織全体でデータを活かせる状態の実現を見据えています。 “データは当社の競争力の源泉であり、それを一部の専門人材だけでなく組織全体で活用できるようにすることは、多品種生産を強みとする当社にとって不可欠な変革です。今回の取り組みは、その第一歩として大きな手応えを感じています。セキュアな基盤の上で現場と分析をつなぎ、変化に素早く対応できる組織へ。AWS とともに、この歩みをさらに加速させていきます。” ― 株式会社 SUMCO AI推進本部 ICT推進部 部長 武富 太志 氏 おわりに AWS Summit Japan 2026 の SUMCO ブースでは、実物のシリコンウェーハとともにデータ活用の取り組みを紹介しました。厳しいセキュリティ要件のもとで製造データをクラウドと生成 AI で活用する SUMCO の挑戦は、同じ課題に向き合う製造業の皆さまにとって、参考となる点があるのではないかと考えています。 SUMCO と AWS は、これからもデータ活用 DX の歩みをともに進めてまいります。本記事が、製造業におけるデータと生成 AI の活用を検討されている皆さまの一助となれば幸いです。 図 11: AWS Summit Japan 2026 の SUMCO ブースにて。展示を支えた SUMCO の皆さまと、AWS メンバー。 執筆者について 武富 太志 株式会社SUMCO AI推進本部 ICT推進部 / 部長 「データを、現場の力に変える」をテーマに、工場で生まれる膨大なデータをAIやクラウドで活用し、ものづくりの現場をスマートにする取り組みを率いる。難しいIT技術を社員が使いこなせるよう教育にも力を注ぎ、「一部の専門家だけでなく、全員でデータを使いこなせる会社」を目指して日々奮闘中。 荒木 亮 株式会社SUMCO AI推進本部 ICT推進部 半導体業界において、製造装置の制御技術と工場のデータ基盤、双方の実務領域にエンジニアとして関わってきた。SUMCOでは製造現場の知見をシステムとして具現化することで、ITを軸とした自動化とデータ活用に取り組んでいる。社内ではいつの間にか「万屋（よろずや）」と呼ばれるようになり、静かに受け入れつつも、熱量に限ってはその肩書きが窮屈らしい。 大森 敬太 株式会社SUMCO ウェーハ技術部 プロセス企画課 / データサイエンティスト 2021年にSUMCOへ入社後、ICT部門に配属。SEとしてIT知識を習得しながら、製造現場の見える化推進に取り組む。その後、システム開発やデータ分析業務など幅広いICT関連業務を経験。2023年よりデータサイエンス課に配属。現在、データサイエンス分野の博士後期課程に社会人博士として在学中。製造現場とデータ分析をつなぐ役割を担い、組織全体のデータ活用推進に取り組んでいる。 酒井 賢 アマゾン ウェブ サービス ジャパン合同会社 ハイテク＆ヘルスケア・ライフサイエンス部 / シニアソリューションアーキテクト IT 業界で 20 年以上の実務経験を持つソリューションアーキテクト。2020 年の AWS 入社後、製造業を中心にさまざまな業種の企業を支援し、現在は半導体業界を専門としている。企業がクラウドソリューションを計画・実装し、AWS 上で安全かつ高性能で柔軟な費用対効果の高い環境を構築することへの支援に注力している。

Amazon Bedrock は、Anthropic や OpenAI をはじめとする主要モデルからオープンウェイトモデルまで、幅広いモデルの選択肢を提供しています。アマゾン ウェブ サービス ジャパン（以下、AWS ジャパン）は 2026 年 7 月 28 日、東京・赤坂インターシティコンファレンスにて「AWS Bedrock LLM Day Japan」を開催しました。AWS Summit New York City で発表された最新アップデートをいち早くお届けするとともに、Amazon Bedrock で実験段階から本番運用へとスケールしているお客様 5 社の事例、AWS パートナー各社によるソリューション紹介とデモ展示（パートナー Expo）を通じて、本番環境対応のソリューションへ進むための次のステップをお届けしました。 イベントは 2 部構成で、前半は全参加者向けに最新アップデートとお客様事例を、後半はサービス詳細を掘り下げる Tech Session と、パートナー企業様が生成 AI のビジネス価値を紹介する Business Session を 2 会場で並行開催しました。本記事では、その模様をレポートします。 開会のご挨拶 イベントの冒頭では、AWS ジャパン AIML 事業開発マネージャー 井形 健太郎が開会の挨拶を行い、本イベントの狙いと一日の流れを案内しました。 AWS Keynote と最新アップデート 基調講演には、WW Bedrock & AgentCore GTM Director の Eugene Kawamoto が登壇しました。AWS に 13 年以上在籍し、日本で最初のビジネス開発担当者として東京でキャリアをスタートした Eugene は、冒頭で本日の主題として「モデルの柔軟性」「高セキュリティなプラットフォーム」「エージェントの大規模な構築」の 3 領域を提示しました。 Amazon Bedrock は現在、世界中で 12.5 万を超えるお客様の生成 AI を支え、100 を超えるモデルをサポートしています。直近では本年 4 月の OpenAI との戦略的パートナーシップを受けて GPT-5.5 / GPT-5.4 / Codex が利用可能になり、Anthropic の次世代モデル Claude Fable 5 も一般提供が開始されました。最高水準のオープンウェイトモデルがフロンティアモデルに肩を並べつつある点にも触れています。 基盤面では、AWS PrivateLink による閉域接続と Zero Data Retention（データ非保持）の原則に加え、新しい推論プラットフォーム Project Mantle を紹介しました。障害時もオペレーターが環境にアクセスしない「ゼロオペレーターアクセス」、統合キャパシティプールによる高いデフォルトクォータ、東京を含むアジアパシフィック 4 リージョンでの稼働とリージョン特化エンドポイント、リクエストを 3 つの優先度レーンに割り当てるサービスティアが特長です。 エージェントについては「本番稼働は依然として難しい」と切り出しました。多くのチームがエージェントのロジックではなく認証やメモリ、ガバナンスの構築に何か月も費やしており、「エージェントが本番で動いていない 1 か月は、組織の勢いを積み上げられない 1 か月」だと述べました。これに応える Amazon Bedrock AgentCore では、直近 6 か月でエージェントの実行タスク数が 15 倍に増加。鍵となるのは「ハーネス」で、モデルが「脳」、AgentCore の各コンポーネントが「身体」だとすれば、その身体をうまく使う仕組みがハーネスにあたります。AWS Summit New York City で一般提供を開始した AgentCore harnessにより、数回の API 呼び出しでアイデアから本番まで数分に短縮できるようになりました。 最後のテーマは「データ、コンテキストがすべて」です。優秀な新入社員でも社内のプロセスを知らなければ活躍が難しいのと同じだと Eugene は説明しました。公開データについては Amazon の Web 検索を AgentCore の Web Search として、社内データについては取り込み・解析・検索をマネージドで担う Amazon Bedrock Managed Knowledge Base として提供（いずれも一般提供開始）。さらに構造化・非構造化を横断する AWS Context（近日提供予定）も紹介し、「今日の限界を、明日の境界として受け入れるな」という言葉で講演を締めくくりました。 お客様事例 続いて、Amazon Bedrock で生成 AI を本番運用へとスケールさせているお客様 5 社にご登壇いただきました。 日本電気株式会社 コーポレート IT AI プラットフォーム統括部 ディレクター 野口 忠則 氏は、「Anthropic 協業の舞台裏」として、Claude Cowork on Bedrock を 2 週間で本番構築した経緯を共有しました。AWS から Amazon Bedrock 経由でも利用可能になるとの情報提供を受けたのは、全社展開を決めていた 6 月 1 日のわずか 3 週間前。国内のデータ所在要件を満たせるのが Amazon Bedrock 経由だけであり、利用者が作成したスキル等を後から移行できないため、初日を逃すと切り替えが実質不可能になることが決断の理由でした。 最大の難所は、リリース 1 週間前の金曜夜に判明した MCP 経由のシステム間認可の不具合です。深夜まで調査しても自社メンバーだけでは解決できず、AWS サポートへ緊急扱いでエスカレーションし、土曜の朝から調査を開始。「6 月 1 日のリリースは無理だと思った」という状況から、担当営業と AWS 側エンジニアの全力支援で日曜夕方には原因を特定できたと振り返りました。接続先の SaaS が OAuth 2.0 / DCR に対応しているとは限らない点は、自社の認可中継サーバーで対応しています。 結果として、一般提供前のサービスの早期適用で 2 週間・12 万人規模の本番展開を完遂し、国内大手 IT ベンダー初の先行事例となりました。7 月 27 日時点の利用者は 9,700 名です。成功のポイントは、組織の後押しと許容、大規模システムを支える推進力、そしてリファレンスがない中でもベンダーとともに問題を 1 つずつ検証・改善する One Team 体制の 3 点でした。 丸紅株式会社 バリュークリエーションオフィス 事業成長支援課 芹川 武尊 氏（写真上）と Digital Experts 株式会社 仲吉 朝洋 氏（写真下）は、AgentCore runtime 上で本番運用している 2 つのエージェントを紹介しました。1 つは「VCO Agent」で、チャットに指示するだけで AI がコードの作成・実行まで行い、データ分析からドキュメント生成、定型業務のスキル化と共有までをプログラミング不要で現場の非エンジニアに届けます。総合商社では機密区分やアクセス権が業務ごとに異なるため、機密データを社外に出さず本人の権限の範囲内で処理することが前提条件でした。4 月 1 日の開発開始から 9 日で初回利用、16 週後には利用者 619 名・直近週 1,647 件・ユーザー作成スキル 285 個に達しています。 もう 1 つは、企業名を入力するだけで市場調査から情報収集・数値分析・レポート出力までを実行する競合分析エージェントです。1 社あたり数分 × 競合企業数のため全体で 1 時間弱かかることもあり、サーバーレスで最大 8 時間の連続実行を完走できることが採用の決め手になりました。いずれも AWS Lambda やコンテナ基盤と比較のうえ、セッションごとの microVM 割り当てと JWT / IAM の標準サポートを理由に AgentCore runtime を選定。「本番化の鍵は、モデルの選定より安全な実行環境の設計」というのが 2 つの運用から得た結論でした。 ファストドクター株式会社 オンライン本部 プロダクト部 部長 / リードアーキテクト 加藤 倫弘 氏は、医療事務 AI による自動化を「PoC から本番への筋道」として共有しました。1 件の診察は数十ステップが直列に処理されますが、AI を入れたのはそのうち 1 ステップだけ。医療証を見てどの公費制度かを特定する工程で、医療事務が 1 件 2〜5 分かけており、自治体ごとに様式も運用も異なるためルールベースでは最後まで解けなかった「難所」でした。実行基盤に AgentCore runtime、フレームワークに Strands Agents を採用し、書いたのは業務手順とツールだけだったためプロトタイプは 1 日で動いたといいます。 本番化のコツは 3 点。精度を上げるのは AI 以外の作り込みであること（前処理は決定的なコードでやり切り、マニュアル照合だけを AI に任せる）、出力の型を先に決めて確信度が低い案件は止めて人へ回す「間違えても大丈夫な構造」を先に作ること、そして評価とダークローンチを経て約 1 週間の全件チェックを挟んで本番運用に移す段階的なリリースです。「間違えない AI を作ろうとすると、永遠に本番に出せない。構造で受け止める」という考え方が根底にあります。 株式会社リクルート プロダクト開発統括室 プロダクトディベロップメント室 VP 片岡 歩 氏は、「Chat から Agent へ — その転換を、6000 人全員に」をテーマに、社員 1,500 名とパートナー 4,500 名の計 6,000 名にエージェント型 AI 環境を届ける共通基盤を紹介しました。Claude Code のランチャーから LiteLLM を経由し、Amazon Bedrock 上のクローズドモデルと自社 GPU サーバー上のオープンウェイトモデルの双方を扱える構成です。チャット型は現行の業務フローがベースのため生産性改善は 10〜20% ですが、エージェント型は業務プロセスそのものに編み込まれ、リードタイムを 1/10、1/20 に変える。だからこそ部分導入では効かず、「全員が使えることが必要条件」だと語りました。 課題は、パートナーや非エンジニアも含めて全員が使える環境をつくることと、想定外のトークン利用によるコスト爆発を防ぐことの、半ば矛盾した 2 つ。オープンウェイトモデルによるコストの固定費化と、LiteLLM で月間上限に達したら利用不可にする制御で対応し、勉強会や非エンジニア向け GUI ランチャーで利用を促進。登録ユーザー数は 3,000 人に達しました。AI-DLC を適用したある事例では 120 人月規模の案件を 3 名・20 営業日で完了し、コストで 97.5%、リードタイムで 84% の削減となっています。 jinjer 株式会社 プロダクト開発部 VPoT 玄 章夫 氏は、AgentCore を本番導入して直面した壁とその越え方を共有しました。分断されていた勤怠・休暇・人事労務のサービスを、チャットの共通窓口から横断利用できる AI アシスタントを開発。基盤を自前で作らずプロダクト開発に集中するため、Runtime・Memory・Identity・Observability を標準提供する AgentCore を選定し、自前構築見積り 2 か月に対して実績 1 か月と、約 1 か月の期間短縮を実現しました。 一方で 2 つの壁に直面します。1 つはパフォーマンスで、設定への知見不足からメモリ処理が想定以上に実行され、レスポンス遅延を招いていました。プロファイリングと TTFB 計測でボトルネックを特定し、メモリ書き込みを一括化することで書き込み時間を 70% 短縮。「マネージドサービスでも、設定や実行方式の理解が重要」というのが学びです。もう 1 つの LLM コストは、Strands Agents の採用、共通プロンプトのキャッシュ（入力トークンコストを 70% 削減）、小型モデルやルールベースへの振り分け、入出力サイズの最適化で対応。「LLM コストはモデル単価だけでは決まらない」として、システム全体での最適化が必要だと述べました。 後半セッション①：Tech Session Tech Session では、AWS のスペシャリストソリューションアーキテクトが最新モデル活用とエージェント構築基盤を解説しました。 AWS ジャパンの Sr. AI Specialist SA 石見 和也は「Claude on AWS」として、単に Amazon Bedrock で Claude が使えるという話を超え、多様なアーキテクチャパターンが立ち上がっていることを解説しました。AWS が提供する Claude のソリューションは、包括的な生成AIプラットフォームである Amazon Bedrock、Anthropic ネイティブな API 群を AWS の認証・監査・支払いと組み合わせて使える Claude Platform on AWS、ClaudeのEnterprise PlanをAWS Marketplace上での契約・支払いに集約する形の 3 つがあります。さらに、Claude Agent SDK を AgentCore runtime 上で動作させる方法や、Claude Platform on AWS経由でClaude Managed Agentsを利用しつつ、Lambda MicroVM 経由で AWS にアクセスする方法など、クラウド上でエージェントを長時間動作させる際のアーキテクチャも紹介しました。 AWS ジャパン Senior AI Solution Architect 菊田 遥平は、AWS が提供する OpenAI の最新アップデートを解説しました。Amazon Bedrock では GPT-5.4,5.5,5.6 と ChatGPT Work / Codex が利用可能になっており、GPT モデルは bedrock-mantle エンドポイント経由・Responses API 形式で提供されます。従来のモデルや API 形式とは Zero Data Retention に関わるサーバー側のデータ保持の仕組みが異なるので、利点と注意点について紹介しました。現時点では機能差分も存在し、テキスト出力のみであること、Cross Region Inference（CRIS）に未対応で US リージョンに限られること、コンテキスト長が 272K トークンであること（発表後に GPT-5.6 で 1M コンテキスト長に対応 https://aws.amazon.com/about-aws/whats-new/2026/08/gpt-sol-terra-luna-long-context-bedrock/ ）を説明しました。そのうえで、セキュリティやガバナンス、請求の統合、技術的なサポートといった AWS の利点に価値を感じるお客様には、ぜひ Amazon Bedrock 経由で OpenAI の機能を使ってほしいと呼びかけました。 AWS ジャパンの AI Specialist SA 鯨田 連也は、AWS Summit New York City で提起された「エージェントには適切なコンテキストが必要」「エージェントの構築自体が難しい」という 2 つの課題について、AgentCore がどのように解決するのかを、キーノートより一歩踏み込んで解説しました。前者のコンテキストの課題に対しては、Amazon Bedrock Managed Knowledge Base から、ユーザーごとに検索可能な文書を制御する ACL、ドキュメント種別を問わず自動でパースとチャンキングを行う Smart Parsing、複雑なクエリを分解して複数のナレッジベースを並列検索する Agentic Retrieve Stream API などの機能を紹介しました。あわせて、Amazon 独自の検索スタックにより Zero Data Egress で検索できる Web Search Tool on AgentCore も取り上げました。後者のエージェント構築の課題に対しては、モデル・ツール・スキル・メモリ・ファイルシステムを設定するだけで、ノーコードでエージェントを構築できる AgentCore harness の機能や利用方法について示しました。 後半セッション②： Business Session ビジネストラックでは「業務プロセス自動化」「業界特化型」「セキュリティ」という 3 つのテーマで構成され、それぞれのテーマで 3 社が異なるアプローチから同じ課題に挑みました。全登壇を貫いていたのは、「PoC で終わらせず、本番環境で安全に動かす」という一貫した問題意識です。コスト、工数、統制のそれぞれで定量的な効果が示され、生成 AI を「現場で使い続けられる形」にする実践知が共有されました。本ブログでは、テーマごとに登壇 3 社をまとめてご紹介します。 テーマ①：業務プロセス自動化 「AI エージェントで業務を自動化したいが、コストが読めない」「ノーコードで始めたいが品質が担保できない」「マルチエージェントは概念としては理解できるが、実際どう動くのか」 ―　本テーマでは、3 社がそれぞれ異なるアプローチでこの課題に回答しました。 KDDI アイレット 平野 健介 氏 サーバーワークス 久保 賢二 氏 ナレッジコミュニケーション 横内 俊宏 氏 トップバッターの KDDI アイレット は、企業や組織の AI 活用を促進する「AI Chat for Business」の運用知見をもとに、ID 定額モデルの固定費課題を実利用量のみ課金する トークン従量課金モデル で解決し、100 名以上の利用でコスト最大半額程度に低減できる可能性を提示。続く サーバーワークス は、Amazon Bedrock AgentCore の Agent Skills を活用した「Paperwork Agent」で、複雑な申請書様式を「教える」だけで作成時間を 20 分から 5 分へ約 75%削減 。締めくくりの ナレッジコミュニケーション は「AI は人で動かす」をテーマに、評価軸ごとにエージェントを分離した課題発見型のマルチ AI エージェント（ミルボン様事例）を、PoC 1 か月・実装 3 か月で立ち上げた実践知を共有しました。 テーマ②：業界特化型 建設と製造 ― 日本の基幹産業が抱える「人手不足」「属人化」「紙文化」に、AI エージェントはどう応えるのか。3 社がそれぞれの「現場」で実証した解決策を共有しました。 アジアクエスト 菊池 啓介 氏 シーイーシー（CEC） 青山 貴哉 氏 富士ソフト 吉田 祐史 氏 アジアクエスト は建設業界向けの 3 つの AI ソリューション（定型書類の自動作成、AI チャットによる BIM ソフト「Revit」操作、2D 図面の AI 3D モデル変換）で業界の DX を加速。 シーイーシー（CEC） は、FA/製造現場のドメイン知識を活かした設備保全 AI エージェントで、設備停止による 年間 4,500 万円規模の損失 に対し平均復旧時間 40%短縮を目標に属人化を解消。 富士ソフト は AI カメラ×Amazon Bedrock の「VisionAI Navi」で、Nova Lite （Claude 比約 1/8）/ Qwen3 VL （約 1/5）/ Claude Sonnet 5 を用途で使い分け、PoC 20 万円〜の低コストでコストと精度を両立します。 テーマ③：セキュリティ AI エージェントを PoC から本番に昇格させるとき、最大の壁は「セキュリティと統制」です。暴走、データ漏洩、監査不能 ― 本テーマでは、3 社がそれぞれ異なるレイヤーからこの課題に挑みました。 Aokumo Norihiro Takachi 氏 SCSK 渡辺 大介 氏 NRI（野村総合研究所） 北條 学男 氏 Aokumo は、J-SOX / FISC 環境で 1,200 以上の本番アクションを安全に実行する「Governed Execution OS」で、4 つの統制を「構造」として組み込み MTTR 73%削減 ・J-SOX 監査証跡を 3 分以内に出力（SBI グループ様で監査サイクルを数か月→18 日に短縮）。 SCSK は「本番投入、最悪のシナリオ」を防ぐ実行・統制・データの 3 層構成「Agentic AI プラットフォーム」を提示。 NRI （野村総合研究所） は、OWASP 脅威 17 項目の 71%が入出力監視だけでは検知困難と示し、プロアクティブ脆弱性診断とトレースログ分析基盤「AgentTrase」で内部を可視化する継続的な診断・監視を実現します。 クロージング クロージングは Tech Session と Business Session の 2 会場でそれぞれ行いました。 Tech Session では AWS ジャパン Sr. GTM Specialist AI/ML 樋口 亮太より、Business Session では AWS ジャパン Partner AI Specialist 井上　陽治より、AI 市場が 2030 年まで約 24 倍に成長すると言われる中で「導入した後、いかに価値を最大化するか」が本日のメインテーマであったと振り返りました。そして登壇内容から共通して見えてきた価値最大化の鍵として、モデルの柔軟性、セキュアなプラットフォーム、エージェントの構築の 3 点を挙げました。 次のステップとして、320 社以上のお客様にご参加いただいている「AWS ジャパン 生成 AI 実用化推進プログラム」を案内。あわせて、2026 年 8 月末に AWS ジャパン本社（麻布台ヒルズ）で開催予定の「生成 AI Frontier Meetup」を紹介しました。 パートナー Expo とネットワーキングの様子 セッション終了後は、ご登壇いただいたパートナー企業様の展示ブースで各社のソリューションを体験いただけるパートナー Expo とネットワーキングを実施しました。軽食・ドリンクをご用意し、休憩時間も含めて参加者とパートナー、AWS メンバーが自由に交流できる場としました。会場では各ブースを巡る「ブーススタンプラリー」も実施し、多くの参加者にパートナー各社のデモをご覧いただきました。AWS のメンバーも待機し、セッションの内容や個別の技術相談にその場でお答えしました。 おわりに 本イベントでは、最新のサービスアップデートから、本番運用へとスケールさせているお客様の事例、パートナー各社が現場で積み上げた実装と統制の知見までを一日でお届けしました。共通して見えてきたのは、生成 AI の議論の焦点が「何ができるか」から「どう本番で動かし続けるか」へ移っているということです。AWS ジャパンは、今後もモデルの選択肢とエージェント構築基盤の拡充、そして技術支援を通じて、お客様の生成 AI の本番活用と価値創出に貢献してまいります。 イベント当日投影いたしました、資料はこちらよりダウンロードいただけます。 AWS より投影の資料： AWS Bedrock LLM Day Japan AWS セッション資料 パートナー企業様より投影の資料： AWS Bedrock LLM Day Japan Partner Session

本ブログは 2026 年 8 月 13 日に公開された AWS Blog “ AWS Certificate Manager will discontinue email validation to prove domain validation for certificates ” を翻訳したものです。 本日 (2026 年 8 月 13 日)、 AWS Certificate Manager (ACM) が 2027 年 9 月 30 日までに E メール検証済みパブリック証明書のサポートを終了することを発表します。ACM のパブリック証明書で E メール検証を使用している場合は、この日付より前に DNS 検証への移行が必要です。この変更は、 Certification Authority/Browser (CA/B) フォーラム による E メールベースのドメイン検証の業界全体での廃止に合わせたものであり、フォーラムが定める 2028 年 3 月の期限に先立ち、移行のために丸 1 年の期間を確保できるようにしています。 このブログ記事では、この変更の理由とタイムライン、そして証明書を DNS 検証に移行するための手順を紹介します。 背景 CA/B フォーラムは、パブリックに信頼される証明書についてブラウザと認証機関 (CA) が従うべき標準を定めています。2025 年 11 月、CA/B フォーラムは 2028 年 3 月 15 日をもって E メールベースのドメイン検証のサポートを終了することを決議しました。この日付以降は、どの認証機関が発行したかにかかわらず、E メールで検証された証明書はブラウザから信頼されなくなります。 ACM は CA/B フォーラムの要件に合わせ、2027 年 9 月 30 日までに E メール検証を廃止します。この ACM のタイムラインにより、お客様は CA/B フォーラムの最終期限を迎える前に、1 年間かけて移行を進めることができます。 変更のタイムライン 現在 ACM からリクエストした証明書で E メール検証を使用している場合は、以下の重要な日付に注意してください。 2027 年 1 月 1 日 : ACM は新しい AWS リージョンでの E メール検証の提供を終了します。 2027 年 3 月 31 日 : ACM はすべてのリージョンで、新規の証明書リクエストに対する E メール検証の提供を終了します。 2027 年 9 月 30 日 : ACM はすべてのリージョンで、E メール検証を使用する既存の証明書の更新を終了します。 2028 年 3 月 15 日 : CA/B フォーラムの規定により、パブリック認証機関は E メールベースのドメイン検証を使用して、パブリックに信頼される証明書を発行または更新できなくなります。この日付より前に発行された証明書は、有効期限が切れるまで有効です。 既存の E メール検証済み証明書を確認する ACM が発行したパブリック証明書をお持ちの場合は、ACM の AWS マネジメントコンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用して、E メール検証済みの証明書があるかどうかを確認できます。 ACM コンソールを使用して E メール検証済み証明書を特定する コンソールで以下の手順を実行して、E メール検証済み証明書を見つけます。 ACM コンソール を開きます。 フィルターで [Validation method] = [Email] (検証方法 = E メール) および [Type] = [Amazon Issued] (タイプ = Amazon 発行) を選択すると、E メール検証済み証明書の一覧が表示されます。 ここに表示された証明書は、E メール検証済みのパブリック証明書であり、2027 年 9 月 30 日までに移行する必要があります。 図 1: すべてのパブリック E メール検証済み証明書の一覧 AWS CLI を使用して E メール検証済み証明書を特定する 以下のコマンドを使用して、E メール検証済み証明書を見つけます。 # Discover email validated public certificates region="${1:-us-east-1}" aws acm list-certificates --region "$region" \ --query "CertificateSummaryList[?Type=='AMAZON_ISSUED'].CertificateArn" --output text | tr '\t' '\n' | while read -r arn; do aws acm describe-certificate --region "$region" --certificate-arn "$arn" \ --query 'Certificate.[DomainName,Type,DomainValidationOptions[0].ValidationMethod]' \ --output text done | awk -F'\t' '$3 == "EMAIL"' | column -t Usage: chmod +x list-email-validated-certs.sh ./list-email-validated-certs.sh # default region, us-east-1 ./list-email-validated-certs.sh us-west-2 # another region 既存の E メール検証済み証明書を移行する この移行を支援するため、ACM は UpdateCertificateOptions API を更新し、証明書を置き換えることなく、検証方法を E メールから DNS に切り替えられるようにします。これにより、証明書の Amazon リソースネーム (ARN) は変わらず、その証明書を参照している AWS リソースへの変更も不要です。 証明書を DNS 検証に更新すると、ACM は DNS 設定に追加する CNAME レコードを提供します。このレコードは 72 時間以内に追加する必要があります。この期間中、証明書は E メール検証のまま通常どおり機能し続けます。72 時間以内に DNS を更新しなかった場合でも、証明書は E メール検証のまま有効な状態を維持するため、準備ができた時点で再試行できます。DNS 検証が完了すると、ACM は有効期限が切れる前に証明書を自動的に更新するようになり、それ以上の手作業は不要です。ACM が中断なく証明書を最新の状態に保てるように、2027 年 9 月 30 日までに移行を完了することをお勧めします。 コンソールを使用して移行するには 更新が必要な証明書を特定したら、その証明書を開き、ページ上部の [ Update validation method ] (検証方法を更新) を選択します。 図 2: E メール検証済みパブリック証明書を表示した際の DNS 検証プロンプト 更新が開始されると、証明書ページの上部に [ View DNS records ] (DNS レコードを表示) というフラッシュバーが表示されます。 図 3: 検証方法の更新後に DNS 検証レコードを表示 フラッシュバーの [ View DNS records ] (DNS レコードを表示) を選択するとダイアログボックスが開き、他の DNS プロバイダーにエクスポートするための CNAME レコードの CSV ファイルをダウンロードできます。 図 4: ダイアログボックスから DNS 検証情報を取得 Route 53 をご利用の場合は、[ Create records in Route 53 ] (Route 53 でレコードを作成) を使用すると、ワンクリックで検証を実行できます。 図 5: Route 53 に DNS 検証レコードを作成 AWS CLI を使用して移行するには AWS CLI を使用して証明書を更新する手順については、 E メール検証から DNS 検証への移行に関するユーザーガイド を参照してください。 E メール検証の提供終了後の代替手段 ACM は今後、新しい証明書に対して 2 つの検証方法をサポートします。 DNS 検証 – DNS 設定に CNAME レコードを追加します。レコードが維持されている限り、ACM は DNS 検証済み証明書を自動的に更新します。ほとんどのユースケースでこの方法をお勧めします。 Amazon CloudFront 向けの HTTP 検証 – ACM が提供する一意のトークンを、ドメイン上の well-known URL パスでホストします。この方法は、 Amazon CloudFront で使用する証明書に限り利用できます。 どちらの方法も、E メール検証で必要だった手動の承認ステップが不要になり、ACM が証明書を自動的に更新できるようになります。 まとめ E メール検証の廃止と新しい UpdateCertificateOptions API の活用により、業界標準の進化に合わせて、証明書の信頼性とアプリケーションの安定した稼働を維持できます。更新された UpdateCertificateOptions API を使えば、この移行は簡単に行えます。証明書を置き換えずに検証方法を切り替えて DNS レコードを追加すれば、それ以降の更新は ACM が自動的に処理する仕組みになっています。 移行に関するご質問やサポートが必要な場合は、 AWS サポート にお問い合わせいただくか、 AWS re:Post の ACM フォーラム で新しいスレッドを作成してください。 Adam Aboudi Adam は AWS Certificate Manager チームの Senior Technical Product Manager です。お客様が証明書のライフサイクル管理を簡素化し、AWS 環境全体で強固なセキュリティポスチャを維持できるよう支援することに注力しています。 Poojil Tripathi Poojil は、テキサス州オースティンを拠点とする AWS の Solutions Architect です。AWS のお客様と協力して、あらゆる種類のワークロードに対する安全なアーキテクチャの設計を支援しています。「誰も見ていないかのように踊り、誰もが見ているかのように暗号化しましょう」というのが Poojil からのメッセージです。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

はじめに AWS では、データコラボレーションサービスの提供を超えて、様々な業界の企業間でのデータコラボレーションを加速できるような機会創出にも力をいれています。2026 年 6 月 10 日、新潟市の共創型イノベーション施設 NINNO ROOM F にて、第四北越銀行と第四北越ITソリューションズ 、AWS の共催で、新潟県における地域産業のデータコラボレーションワークショップを開催しました。新潟を代表する食品・製造・小売・物流・スポーツ・メディアなど多様な産業の企業が一堂に会し、AWS Clean Rooms を活用したデータ連携の可能性について、熱い議論が交わされました。本記事では、ワークショップの開催背景と当日の内容をご紹介いたします。 新潟県は食品・製造・小売・物流・スポーツ・メディアなど多様な産業が集積する地域です。これらの産業が保有するデータを安全に連携することで、地域経済の活性化や新たなビジネス機会の創出が期待されています。一方で、異業種間のデータ活用には、セキュリティやプライバシー保護の観点から技術的なハードルが存在します。 この課題を解決するため、AWS は第四北越銀行、第四北越ITソリューションズと共同でワークショップを企画しました。「食×エンタメ」「ものづくり」「健康・医療×自治体サービス」「モノ・流通・小売り」の 4 つのテーマでテーブルを構成し、各業界の企業が AWS Clean Rooms を活用したデータコラボレーションのユースケースを議論する場を提供しました。 開催概要 項目 内容 開催日 2026年6月10日（水）13:30〜17:00 会場 NINNO ROOM F （新潟県新潟市）— 地域の共創を促進するコラボレーション型イノベーション施設 共催 第四北越銀行 / 第四北越ITソリューションズ / アマゾン ウェブ サービス ジャパン 参加企業 11社・1自治体・1大学 / 32名 AWS事務局 14名 合計参加者 46名 参加企業・団体（すべて新潟県に本社を構える企業） 製造業（6社）、流通小売業（3社）、物流・運輸業（1社）、自治体、AWS パートナー3社、第四北越銀行（共催） アジェンダ 第四北越銀行　常務取締役　石坂様：開会のご挨拶 AWS南：新潟県とAWSのこれまでの取り組み 新潟県 創業・イノベーション推進課 課長　藤田様：「県内産業の攻めのDXとAI活用支援」 新潟大学 山崎教授 ：新潟大学におけるAI研究の取り組み AWS松本：AWS コラボレーションテクノロジーのご紹介 テーブル別ディスカッション（4グループ） BSNアイネット　上席執行役員　坂田様：ワークショップ総括 第四北越ＩＴソリューションズ　代表取締役社長　原様： 閉会のご挨拶 懇親会 前半をセミナー、後半をディスカッションと分けて開催いたしました。後半のディスカッションでは、4つのテーマごとに分かれたテーブルで、各企業が実際にデータコラボレーションする際のユースケースと協業内容について議論を行いました。 データコラボレーションとは 本ワークショップのメインテーマであるデータコラボレーションと、それを支える AWS のサービスについてご説明します。データコラボレーションとは、複数の組織が保有するデータを安全かつ効果的に共有・統合・分析し、単独では得られない洞察や価値を生み出す取り組みです。例えば、小売業とメディア企業が匿名化された顧客データをコラボレーションすることで、より精緻なマーケティング戦略の立案や新サービスの開発が可能になります。重要なのは、各組織のデータプライバシーとセキュリティを維持しながら、必要な情報のみを共有することです。これにより、安全性を確保しつつデータの価値を最大化することができます。 なぜ今データコラボレーションが注目されているのか データコラボレーションの注目が高まっている背景には、デジタル化の加速、消費者行動の複雑化、個人情報を含むデータの保護に関する規制環境の整備があります。さらに 1st party data (自社で直接収集したデータ) の重要性が増していることも大きな要因です。サードパーティ Cookie の廃止や個人情報保護の厳格化に伴い、企業は自社の顧客データをより効果的に活用し、同時に他社のデータと安全に連携する必要性が高まっています。このデータ活用と連携が、企業の競争優位性を生み出す鍵となっています。 各セッションのハイライト 第四北越銀行 常務取締役　石坂様のオープニング 第四北越銀行　常務取締役　石坂様よりオープニングスピーチを頂戴し、本ワークショップへの期待と新潟経済活性化への思いをお話いただきました。 新潟県とＡＷＳの取り組みのご紹介 アマゾン ウェブ サービス ジャパン合同会社 新潟県アンバサダーの南より、これまで産学官金の連携を通じて行ってきた新潟県とＡＷＳの取り組みをご紹介しました。 新潟県 創業・イノベーション推進課のご講演 新潟県 創業・イノベーション推進課 藤田課長より、新潟県における産業のDX推進の取り組みとAI活用を促進するための事業について講演いただきました。 新潟大学 基調講演 新潟大学 山崎教授より、新潟大学におけるAI研究の取り組みについてご講演いただきました。 AWS のコラボレーションテクノロジー アマゾン ウェブ サービス ジャパン合同会社 松本鋼治より、データコラボレーションを AWS 上で実現する方法についてご説明を行いました。まずはデータコラボレーションを支える AWS Clean Rooms というマネージドサービスについてご紹介しました。 テーブル別ディスカッション ワークショップのメインとなったテーブル別ディスカッションでは、4つのグループに分かれ、AWSのファシリテートのもと、具体的なデータコラボレーションのユースケースについて活発な議論が交わされました。 また、新潟県に本社を構えるAWSパートナー3社がテックサポーターとして、各テーブルの議論を技術面でフォローしました。 G1: 食×エンタメ × B2C  ：製造業、小売り業、スポーツ、メディア企業などが参加　テックサポーター：第四北越ITソリューションズ G2: ものづくり ：製造業4社および小売り業が参加　テックサポーター：BSNアイネット G3: 健康・医療×自治体サービス 自治体、大学、ヘルスケアサービス企業が参加　テックサポーター：フラー G4: モノ・流通・小売り 流通、小売り、製造、メディア企業新が参加　テックサポーター：フラー 総括 ワークショップの総括をBSNアイネット　上席執行役員の坂田様より賜り、各テーブルで生まれたコラボレーションのアイデアや、本ワークショップがデータ活用に関して、じっくり考える機会になったことへのお褒めの言葉をいただきました。 また坂田様からは新潟県でAI活用推進のための各種取り組みをご紹介いただきました。 閉会のご挨拶 最後に閉会のご挨拶を第四北越ITソリューションズ　代表取締役社長　原様より賜り、ワークショップ本編は終了いたしました。 お客様の声 本ワークショップを通じて、参加企業の皆様からは、以下のような声をいただいております。 「製造業においてはデータ共有は難しいテーマだと感じていましたが、議論を進める中で物流をはじめとした共通の課題があることが分かり、大変有意義な意見交換ができました。今後、課題解決に向けていい方向へ発展していくことを期待しています」 — 製造業ご参加企業様 「普段話をしないような企業様や議題について、じっくりお話できてよかったです」 — 物流業ご参加企業様 「県内企業間で何ができるのか、様々な視点で考える良い機会でした」 — 小売業ご参加企業様 「データ活用について、特に地域貢献・地方創生へ繋がるアイデアが発生し議論を深めることができたのは、本イベントならではの体験と感じました」 — パートナー企業様 おわりに 本ワークショップを通じて、新潟県の多様な産業におけるデータコラボレーションの大きな可能性と、参加企業の皆様の熱意を肌で感じることができました。ここに改めて、ご参加いただいた企業・団体の皆様、そして共催である第四北越銀行、第四北越ITソリューションズの皆様に心より感謝申し上げます。AWS は、今後もこの様なデータコラボレーションを推進する取り組みのご支援や、皆様に役立つ情報をセミナーやブログで発信していきます。どうぞよろしくお願い致します。 本ブログは、戦略事業開発本部　シニア事業開発マネージャー　飯島が担当しました。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 Kiro が公開から 1 周年を迎えました。 1 年間の歩みを振り返る記事 では、最初の 5 日間で 10 万人以上が Kiro IDE を試したことや、IDE、CLI、Web、Mobile へと利用環境が広がったことが紹介されています。パートナーによる 100 以上の curated powers に加えて、コミュニティから 15,000 以上の独自 power も生まれました。2 年目の展開にも期待が膨らみます。 それでは、8 月 10 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: ＪＣＲファーマ株式会社様、コーディング未経験の研究者が数日で機械学習解析を完遂 ＪＣＲファーマ株式会社様は、希少疾病などの治療薬を研究開発する製薬企業です。研究部門では、機械学習解析に必要なプログラミング技術の習得が課題でした。そこで、既存の AWS ガバナンスを活かし、推論先を東京・大阪リージョンに限定した Amazon Bedrock 経由の Claude Code 環境を約 10 日で整備しました。その結果、3 か月以上を見込んでいた技術習得を経ず、コーディング未経験の研究者が数日で実装から分析まで完遂。Active Directory 移行の調査・設計も、通常は外部委託で数週間かかるところを 2 日で内製しました。今後は社内データのセマンティック化と活用基盤を整備し、対象部門を広げる計画です。 ブログ記事「「聞くだけで、必要な情報が集まる」航空オペレーション基盤を Kiro で実現する」を公開 架空の航空データ 38 GB、約 29 万ファイルを使い、Amazon S3 に集約したデータを Amazon Bedrock Knowledge Bases と AgentCore Gateway で横断検索するリファレンス実装です。複数システムの確認に 30 分以上かかる想定業務を、自然言語で数秒以内に検索できる構成として示しています。12 のサブシステムと 79 の仕様ファイルを Kiro のスペック駆動開発で構築しており、複雑な業務基盤へ AI 開発を取り入れる際の参考になります。 ブログ記事「Kiro でライフサイエンス研究を加速する: 100 以上のオープンソースデータベースへの統合 AI インターフェース」を公開 Kiro power と 24 のドメイン特化 MCP サーバーを組み合わせ、NCBI、ClinVar、UniProt、PDB など 100 以上のデータベースとツールを自然言語から横断利用する「Kiro for Life Sciences」の紹介です。API や認証、データ形式の違いを Kiro が吸収し、複数データベースへの問い合わせと結果の統合を一度の会話で進めます。研究者やバイオインフォマティシャンは、具体的な導入手順まで確認できます。 ブログ記事「【開催報告】ISV SaaS 事業者向け 8 社合同 AI-DLC Unicorn Gym」を公開 ISV / SaaS 事業者 8 社、計 54 名が自社プロダクトの実テーマを持ち込み、Kiro や Claude Code で AI 駆動開発ライフサイクルを 2 日間実践したレポートです。8 チーム中 6 社がデモ可能な状態まで実装し、あるチームでは従来 1 か月以上かかっていた要件定義を 2 日間で完了しました。体感した平均工数削減率は 67.1%。AI の速度を活かしながら、人が判断へ集中する開発プロセスを考える材料になります。 ブログ記事「Motorway が Strands と AgentCore で構築した AI エージェント評価パイプラインの紹介」を公開 英国の中古車マーケットプレイス Motorway が、Strands Agents SDK と Amazon Bedrock AgentCore で構築したエージェント評価基盤を解説しています。ビルド時にはツール使用、推論、出力品質を 3 層で評価し、本番環境では AgentCore Evaluations で継続的に監視します。その結果、ツール選択の正確さは 87% から 98%へ、月次インシデントは 12 件から 2 件へ改善しました。サンプルリポジトリも公開されており、品質ゲートを設計する際の出発点になります。 ブログ記事「1 年間の経験。45 億行のコード。160 万時間の節約。そして私たちが学んだこと。」を公開 AWS Transform の一般提供開始から 1 年間の成果と、モダナイゼーションで得た知見をまとめた記事です。45 億行を超えるコードを処理し、数十万台のサーバーを移行して、お客様の作業時間を 160 万時間以上削減しました。MCP サーバー、Kiro powers、コーディングエージェントとの連携や、Kiro が生成仕様を引き継ぐメインフレーム刷新も紹介されています。継続的なモダナイゼーションを検討する方はぜひご覧ください。 ブログ記事「AWS が Anthropic および OpenAI と協業し、AWS Continuum を開発者ワークフローに統合します」を公開 コード脆弱性を検出・優先順位付け・検証・修復する AWS Continuum for code vulnerabilities が、Claude Code、OpenAI Codex、Kiro の開発ワークフローへ統合されます。AWS 環境の IAM ポリシーやネットワーク構成も踏まえて検出結果を検証し、文脈付きの修正情報をコーディングアシスタントへ返す仕組みです。Continuum はプレビュー提供中で、各開発環境との統合は近日提供予定です。 ブログ記事「AWS が Agent Plugins をサポート: ポータブルなエージェント拡張のためのオープン標準」を公開 Agent Plugins 1.0.0 は、Agent Skills と MCP サーバーを一度パッケージ化し、Kiro、VS Code、Cursor などの対応クライアントへ配布するためのオープン仕様です。AWS は設立メンバーとして仕様を支援し、 Kiro powers でも対応を順次展開 しています。既存の power はそのまま利用でき、標準形式のプラグインを power としてインストールできるため、クライアントごとの再パッケージ化を減らせます。 ブログ記事「AWS DevOps Agent と Kiro CLI によるインシデント修正の自動化」を公開 AWS DevOps Agent による原因調査と修正計画を、AWS CodeBuild 上でヘッドレス実行する Kiro CLI へ渡す、イベント駆動型の修正パイプラインを紹介しています。Kiro CLI が steering に従って対象を絞った変更を行い、pull request を作成。人は変更をレビューして承認します。調査からコード修正までを自動化しつつ、人の承認を残した自動修正パターンを具体的に示しています。 サービスアップデート OpenAI のサイバーセキュリティモデル Daybreak Red / Blue が Amazon Bedrock で利用可能に OpenAI のサイバー防御向けモデル Daybreak Blue と Daybreak Red が、対象のお客様向けに Amazon Bedrock で提供されました。Blue は脆弱性検出、検知エンジニアリング、インシデント対応などの防御業務向け。Red は、認可された脆弱性研究やエクスプロイト再現、緩和策の開発といった高度な用途向けです。米国東部（オハイオ）リージョンで利用でき、OpenAI の Daybreak access への登録と AWS でのアクセス申請が必要です。 Amazon Bedrock の IAM プリンシパル別コスト配分が bedrock-mantle に対応 bedrock-mantle エンドポイントの推論コストを、IAM ユーザーやロールに付けたタグで配分できるようになりました。チーム、プロジェクト、アプリケーションなどの単位で、AWS Cost Explorer や CUR 2.0 から利用額を分析できます。次世代推論エンジンを共用する組織でも、利用主体ごとのコストを追跡しやすくなります。bedrock-mantle が提供されているすべての AWS リージョンが対象です。 視覚認識・エージェント環境・マルチモーダル推論の 3 モデルが SageMaker JumpStart に追加 LocateAnything-3B、Qwen-AgentWorld-35B-A3B、Qwen3.5-122B-A10B が Amazon SageMaker JumpStart で利用可能になりました。画像内の物体位置特定、7 種類の操作ドメインにまたがるエージェント環境シミュレーション、262K コンテキストを備えた大規模マルチモーダル推論という、異なる用途をカバーします。専門的なモデルを AWS アカウントへ数回のクリックでデプロイできます。 長時間コーディング・効率的推論・複雑文書 OCR の 3 モデルが SageMaker JumpStart に追加 GLM-5.2 FP8、NVIDIA-Nemotron-Nano-12B-v2、GLM-OCR が Amazon SageMaker JumpStart に加わりました。GLM-5.2 FP8 は 100 万トークンのコンテキストで長時間のエンジニアリング作業を支援します。Nemotron-Nano は 12B のコンパクトな構成で推論スループットを高め、GLM-OCR は表や数式を含む文書を Markdown、JSON、LaTeX として再構築します。コーディングから文書処理まで幅広い選択肢が増えました。 セマンティックキャッシュ・コード推論・多言語 OCR の 3 モデルが SageMaker JumpStart に追加 langcache-embed-v3-small、Mellum2-12B-A2.5B-Thinking、LightOnOCR-2-1B が Amazon SageMaker JumpStart で利用可能になりました。意味的に同じ問い合わせを検出して LLM 呼び出しを減らす埋め込み、コードに特化した MoE 推論、多言語文書を直接テキスト化する軽量 OCR を提供します。推論コストや応答時間を抑えたい本番ワークロードで、用途に合ったモデルを選びやすくなります。 画像生成の軽量デコーダーと Gemma 4 が SageMaker JumpStart に追加 FLUX.2-small-decoder と gemma-4-12B-it が Amazon SageMaker JumpStart に追加されました。FLUX.2-small-decoder は、画質をほぼ維持しながらデコードを約 1.4 倍高速化し、VRAM 使用量を標準デコーダーの約 71% に抑えます。gemma-4-12B-it はテキスト、画像、音声を扱い、関数呼び出しとエージェントワークフローにも対応。限られたメモリでマルチモーダル処理を動かしたい場合にも選択肢が広がります。 生成 AI を活用したビジネス課題の解決を支援する AWS ジャパン生成 AI 実用化推進プログラム は、通年で応募を受け付けています。3 つのコースから選べて、AWS クレジットの付与や技術支援も用意されています。ぜひご検討ください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近の趣味はカメラです。 週刊 AWS の新しいサムネイルを撮影したので、是非ご覧ください。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 お盆も明け、まだまだ暑い日が続きますが、いかがお過ごしでしょうか。休暇中に溜まったアップデートを一気にキャッチアップされている方も多いかもしれませんね。 さて、生成AI開発の現場に身を置いていると、ここ最近「作る」こと自体のハードルがどんどん下がっているのを実感します。エージェントに任せられる作業が増え、これまで手作業だったコード生成やドキュメント作成、分析までもが数クリックで動き出す──そんな時代になってきました。一方で、便利になればなるほど「誰が・何に・どれだけ使っているか」を把握し、安全に統制する仕組みの重要性も増しています。今週は、まさにその「開発を加速させる機能」と「安心して使うためのガバナンス機能」が両輪で登場した、バランスの良い一週間でした。 それでは、2026年8月10日週の主要なアップデートを見ていきましょう。 2026年8月10日週の主要なアップデート 8/10(月) AWS Identity and Access Management が account access manager によるワークフォースユーザーへの IAM ロール割り当てを提供開始 AWS IAM に account access manager という新機能が追加されました。これまで、AWS アカウントへのワークフォースアクセスを付与するお客様は、2 つの代替的なアクセス管理アプローチのいずれかを使用できました。1 つは、各 AWS アカウントにユーザーを個別にフェデレーションし、各 AWS アカウント内の IAM ロールを使用してユーザーアクセス許可を細かく定義する方法です。もう 1 つは、IAM Identity Center を通じてユーザーを 1 回のみフェデレーションし、AWS マネージドアクセス許可セットを調整してプロビジョニングすることで、アクセスを一元的に管理する方法です。 本機能によりこの二つを両立できるようになりました。追加料金なしで、デフォルト有効の AWS 商用リージョンすべてで利用できます。 8/11(火) AWS Glue が AWS コンソールから SageMaker Unified Studio へのワンクリックアクセスを追加 AWS Glue コンソールから Amazon SageMaker Unified Studio をワンクリックで開けるようになりました。Glue コンソールでカタログテーブルを閲覧したり ETL ジョブを構築したりしているユーザーが、同じ IAM ロールのまま Unified Studio に移動し、データのクエリ、データ品質チェック、パイプライン構築、SageMaker Notebooks での分析を開始できます。今回の対応により、S3 Tables、Athena、EMR、Redshift、Glue の 5 つのコンソールから Unified Studio へ直接アクセスできるようになりました。未セットアップのユーザー向けには、IAM コンソールへ移動せずに必要な IAM ポリシーを作成・設定できるインライン権限パネルが提供されます。SageMaker Unified Studio が利用可能な全 15 リージョンで提供されます。 AWS Secrets Manager が Jenkins と SonarQube の managed external secrets 対応を追加 AWS Secrets Manager の managed external secrets に、Jenkins API Token と SonarQube Token が追加されました。これにより、Lambda 関数によるカスタムローテーションコードを書かずに、AWS コンソールからこれらのサードパーティ認証情報を自動ローテーションできます。Jenkins では新トークンの動作検証後に旧トークンを失効させるため、CI/CD ジョブを中断せずにローテーションできます。SonarQube では User Token、Global Analysis Token、Project Analysis Token の 3 種類に対応します。managed external secrets 自体は 2025 年 11 月に Salesforce、Snowflake、BigID の 3 パートナーで開始された機能で、追加料金なしで利用できます。 Amazon Bedrock が IAM プリンシパルによるコスト配分を bedrock-mantle エンドポイントに拡張 Amazon Bedrock の IAM プリンシパル (IAM ユーザーおよびロール) 単位のコスト配分機能が、`bedrock-runtime` エンドポイントに加えて `bedrock-mantle` エンドポイントでも利用できるようになりました。`bedrock-mantle` は OpenAI 互換の Responses API / Chat Completions API や Anthropic Messages API を提供する推論エンドポイントです。IAM ユーザーやロールに team、project、cost center などのタグを付与してコスト配分タグとして有効化すると、AWS Cost Explorer や CUR 2.0 で `bedrock-mantle` 経由の推論コストをユーザー、チーム、プロジェクト単位で分析できます。呼び出し元の識別 (IAM プリンシパル ARN の記録) はタグなしでも自動で行われ、アプリケーションコードの変更は不要です。 8/12(水) Amazon Quick が Microsoft Purview によるデータ損失防止に対応 Amazon Quick が Microsoft Purview と統合し、データ損失防止 (DLP) ポリシーを Quick 環境全体に適用できるようになりました。Microsoft Purview で定義済みの秘密度ラベル (例: Public、Confidential、Highly Confidential) を Quick が読み取り、chat、spaces、knowledge bases の 3 つの機能でファイル共有を制御します。ラベルごとに Block、Warn、Allow の 3 種類の強制アクションを設定でき、Microsoft 365 で運用中のガバナンスポリシーを追加ツールなしで Quick に拡張できます。Amazon Quick の agentic capabilities が利用できるすべての AWS リージョンで提供されます。 Amazon Quick のカスタム権限にデフォルト拒否 (deny by default) を追加 Amazon Quick のカスタム権限プロファイルに、ガバナンス設定として deny by default (デフォルト拒否) が追加されました。従来は Quick が新しい AI 機能をリリースすると、全ユーザーが即座に利用可能になり、管理者はリリース後に個別に制限する必要がありました。本機能を有効にすると、指定したカテゴリ (現時点では `AI` カテゴリのみ) に属する機能は、将来リリースされる新機能を含めてすべて自動的に拒否され、管理者が明示的に許可した機能だけがユーザーに提供されます。金融のモデルリスク管理 (MRM) やヘルスケアのコンプライアンス審査など、AI 機能の事前評価が必須の組織に向けた機能です。Amazon Quick が利用可能なすべての AWS リージョンで提供されます。 AWS IAM がロールマネージャーを提供、IAM ロールを自動でセットアップ可能に AWS は新機能ロールマネージャーの一般提供を発表しました。サポート対象のサービスコンソールでリソースを作成する際、必要な IAM ロールを AWS マネージドのロールテンプレートから自動作成、または既存の一致するロールを再利用します。ローンチ時点で AWS Lambda、Amazon EventBridge など 6 つのサービスコンソールに対応します。作成されるロールは通常の IAM ロールとして扱え、いつでも機能を無効化して IAM Access Analyzer で最小権限に絞り込めます。AWS GovCloud (US) と中国リージョンを除く全リージョンで利用できます。 Amazon Quick がユーザー単位のリソース制限に対応 Amazon Quick で、管理者がユーザー単位の index storage (インデックスストレージ) と agent hours (エージェント時間) の上限を設定できるようになりました。再利用可能な「limit profile」を作成し、ユーザー・ロール・アカウントの 3 レベルで割り当てられます。Quick の index storage は支払いアカウント単位でプールされるため、従来は 1 人のヘビーユーザーが共有容量を使い切り、$5/GB/月 の超過課金が発生する可能性がありました。本機能により、超過課金の抑止とサブスクリプション枠の配分管理ができます。Professional および Enterprise プランで、Quick のエージェント機能が利用できる全リージョンで提供されます。 Amazon Quick が共有に対する承認ポリシーをサポート Amazon Quick に、アセット共有時の承認ワークフローを強制する「承認ポリシー」機能が追加されました。管理者がポリシーを作成すると、対象ユーザーがナレッジベース、スペース、カスタムチャットエージェントを共有する際に、指定した承認者グループによるレビューと承認が必須になります。承認者はアセットの中身を実際に確認してから承認・却下でき、Submit / Approve / Deny / Revoke の全イベントが AWS CloudTrail に記録されます。機密データを扱う組織が、共有操作を統制・監査可能にするためのガバナンス機能です。 8/13(木) Amazon S3 がアクセス拒否エラーメッセージにポリシーの詳細情報を追加 Amazon S3 は、HTTP 403 Access Denied エラーメッセージに、拒否の原因となった IAM および AWS Organizations ポリシーの ARN を含めるようになりました。対象は同一アカウントまたは同一 Organization 内からのリクエストで、明示的拒否 (explicit deny) の場合に SCP、RCP、アイデンティティベースポリシー、セッションポリシー、Permissions Boundary の 5 種類のポリシー ARN が表示されます。従来はポリシータイプと拒否理由までしか分からず、同タイプのポリシーが複数存在する場合は 1 つずつ確認する必要がありましたが、今後はエラーメッセージから原因となったポリシーを直接特定できます。AWS GovCloud (US) リージョンと中国リージョンを含む全リージョンで利用できます。 AWS Certificate Manager が E メール検証から DNS 検証への切り替えに対応 AWS Certificate Manager (ACM) は、既存のパブリック TLS 証明書のドメイン検証方法を、証明書の再発行や ARN の変更なしに E メール検証から DNS 検証へ切り替えられるようになりました。背景には、CA/B Forum が 2025 年 11 月に決定した、2028 年 3 月 15 日付けのメール検証廃止があります。ACM は 2027 年 3 月 31 日に E メール検証証明書の新規発行を停止し、2027 年 9 月 30 日に更新も停止します。ARN が変わらないため、ロードバランサーや CI/CD パイプラインの既存の参照を修正せずに移行できます。ACM 証明書が利用可能なすべての AWS リージョンで利用できます。 Amazon Quick Microsoft 365 extensions が一般提供開始 Amazon Quick の Microsoft 365 extensions (Excel、PowerPoint、Word、Outlook) が 一般提供開始されました。各 Office アプリのサイドパネルから Quick のエージェントを呼び出し、ドキュメントのレッドライン、財務モデル構築、テンプレート準拠のスライド作成、受信トレイ管理などのタスクをアプリ内で直接実行できます。Quick Sight ダッシュボードや Salesforce などの企業データソースを参照した成果物作成に対応し、Plus (月額 20 USD/ユーザー) 以上のプランで追加ライセンスなしで利用できます。Word/Excel/PowerPoint は管理者設定なしで利用開始できますが、Outlook のフル機能には Microsoft Graph API のテナント全体の管理者同意が必要です。 AWS Client VPN が CLI、管理コントロール、接続の高速化に対応 AWS Client VPN のデスクトップクライアントが v6.0.x として再構築されました。新たに CLI (`aws-vpn-client`) が追加され、GUI と同等の全機能をコマンドラインから操作できます。これにより VPN 接続を CI/CD や IaC などの自動化ワークフローに組み込めます。また、企業向け管理コントロールにより、プロファイルのユーザー単位のスコープ設定、デバイス上の全ユーザー向けグローバルプロファイル、エンドユーザーのプロファイル管理権限の制御ができるようになりました。クライアントは OpenVPN3 ベースに再構築され、接続確立時間が改善されています。既存の Client VPN エンドポイントとの後方互換性は維持されており、エンドポイント側の変更は不要です。追加料金はありません。 8/14(金) AWS Billing and Cost Management が Managed Dashboards を発表 AWS Billing and Cost Management (BCM) Dashboards に、AWS が事前構成・保守する読み取り専用ダッシュボード「Managed Dashboards」が追加されました。Cost Overview & Trends、Compute、Database、Reservations、Savings Plans の 5 種類が提供され、自分のアカウントデータが最初から反映された状態でダッシュボード一覧に表示されるため、設定作業なしでコスト分析を開始できます。任意のダッシュボードを複製して編集可能なカスタムコピーを作成でき、PDF / CSV でのエクスポートにも対応します。全ての商用 AWS リージョンで追加料金なしで利用できます。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

みなさん、こんにちは。ソリューションアーキテクトの松永です。8 月に入り各地で猛暑が続いていますね。工場の現場では熱中症対策に神経を使う時期かと思います。少し先の話になりますが、年末の AWS re:Invent 2026 は 11 月 30 日から 12 月 4 日の開催で、早期割引の申し込み期限は 8 月 25 日です。夏のうちに社内調整を始めておくとちょうど良いタイミングかもしれません！今月は Amazon 自身のロボティクスの最前線をピックアップトピックとしてお届けしつつ、7 月に公開された製造業向けのブログとサービスアップデートをご紹介します。なお、リンク先には英語の記事も含まれていますが、日本語の解説を添えていますのでぜひご覧ください。 ピックアップトピック – Amazon のロボティクスに学ぶ、現場で動く AI 製造業のお客様と自動化についてお話ししていると、「どこまでロボットに任せられるのか」「導入した後に現場が使い続けられるのか」という 2 つの問いに行き着きます。実はこの 2 つは、Amazon 自身がフルフィルメントセンターという巨大な現場で向き合ってきた問いでもあります。今月は Amazon のロボティクスの取り組みを題材に、この問いへのヒントを 2 つの視点から探ってみます。 ロボットは「見る」から「感じる」「言葉で指示される」へ Amazon は 2012 年の Kiva Systems 買収以降、 100 万台を超えるロボット を配備してきました。注目したいのは台数ではなく、指示の与え方が進化してきた点です。搬送ロボットの Proteus は、床の符号マーカーに頼らずセンサーで周囲を認識して自律航行するため、人の立ち入りを制限したエリアを設けずに、人と同じ空間で 400 kg 近いカートを運べます。 2025 年に発表された Vulcan は、Amazon 初の触覚を持つロボットです。力覚フィードバックセンサーで押し付ける力を把握し、商品を壊さない範囲で棚の中をかき分けます。平均 10 点が詰まった棚から、対象品目の約 75% を従業員と同等の速度で扱えるとのことです。この能力は、シミュレーションではなく 実世界の接触データ で学習させて獲得されました。 そして 次世代の Proteus では、 自然言語で指示できる ようになりました。技術コマンドやプログラミングは不要で、優先順位や経路はロボット側が判断します（欧州展開は 2027 年上期予定）。土台にあるのはデータ基盤で、フリート全体を賢くする生成 AI 基盤モデル DeepFleet とオペレーター向けの agentic AI モデル Project Eluna も統合されています。 多品種少量で段取り替えが多い現場では、再プログラミングのコストが自動化の投資回収を難しくしてきました。ティーチングやラダーロジックではなく自然言語が操作インターフェースになる流れは、この構造そのものを変える可能性があります。 自動化の設計に、役割分担と人材投資まで含める もう 1 つの視点は、自動化を人の仕事の変化と一体で設計している点です。Vulcan が担うのは保管品目の約 75% で、残りは人に引き継ぎます。対象も脚立が必要だった約 8 フィートの上段と床付近で、人はエルゴノミクス上望ましい power zone の作業に集中できます。100% 自動化を目指さず、機械に任せる範囲を先に決める割り切りが導入の現実性を担保しています。協働型の搬送システム STARK は現場従業員の改善アイデアから生まれ、2027 年までに欧州 15 拠点への拡大が予定されています。 さらに 欧州での一連の発表 では、拠点の近代化に €10 billion 超という設備投資と、25,000 名の増員、Career Choice への 2030 年までの $1 billion のコミットがセットで語られています。対象分野にはメカトロニクスが明示されており、ロボット導入が保全・信頼性エンジニアという職種を必要とする実態と整合します。設備投資額と人材投資額を同時に示すアプローチは、労働力不足と技能継承を抱える日本の製造業が自動化を社内に説明する際のフレームとして参考になるのではないでしょうか。 直近で開催予定のイベント 9/4 – 9/8 IFA 2026 ヨーロッパ最大のコンシューマーエレクトロニクスの展示会が、ベルリンの Messe Berlin で開催されます。Amazon も Hub 27 にブースを出展予定です。 9/14 – 9/19 IMTS 2026 — International Manufacturing Technology Show 北米最大の工作機械の展示会が、シカゴの McCormick Place で開催されます。AWS もブースを出展予定です。会期中には、量子コンピューティングと製造業をテーマにした AWS 主催イベント「 Beyond AI: Quantum Meets Manufacturing — An IMTS Evening Reception 」も開催されます。 10/13 – 10/16 CEATEC 2026 10 月 13 日（火）から 16 日（金）まで幕張メッセで開催されます。主催は電子情報技術産業協会（JEITA）で、今年のテーマは「Transformation – 企業が、産業が、そして社会が変わる -」です。 AWS も Hall 4 で、安川電機様とご一緒に展示を予定しています。 ぜひブースにお立ち寄りください。 11/30 – 12/4 AWS re:Invent 2026 AWS 最大の学習イベントが米国ネバダ州ラスベガスで開催されます。2,200 を超えるセッションが予定され、そのうち約 70% がインタラクティブな形式です。早期割引価格 $1,299（通常 $2,499）の申し込みは 8 月 25 日 23:59 PDT までですので、お早めにご確認ください！ 製造関連ブログのご紹介 7/1 Reduce P&ID analysis time by 80% with hybrid AI maintenance planning PDF の P&ID（配管計装図）から機器とタグを検出し、Amazon Neptune のグラフで依存関係を表現して保全影響を推論する構成です。パイロットでは計画時間を最大 80% 削減できたとのことで、図面資産の活用を検討されている方の参考になります。 7/6 東海旅客鉄道株式会社：超電導リニアの電気設備保守を支える IoT プラットフォームの構築 ※本記事は「事例のご紹介」でご紹介します。 7/15 【開催報告】AWS Summit Japan 2026 — AI エージェントで危機対応：小売×消費財の混乱を AI と人が即座に解決 サプライチェーンの外乱に対し、AI エージェントが影響分析と代替案提示を行い、人の承認を経て実行まで回すデモの実装解説です。分析専用と実行専用でサブエージェントを分ける設計は、現場でエージェントに実行を任せる際の指針になります。 7/16 AI で変える鉄道保全と、「クローズド」を読み解くクラウド設計 — AWS Summit Japan 2026 展示ブース開催報告 異常検知から調査、対応計画の提示、作業指示書の出力までを 4 ステップで実装した保全プラットフォームの報告です。「クローズドは必ずしも安全ではない」という後半の論点は、製造業の OT セキュリティ設計にそのまま読み替えられます。 7/17 ナレッジグラフと IoT データによる生産ラインのボトルネック分析 〜AI エージェントのための製造データの構造化〜 設備やサプライヤーの関係を Amazon Neptune のグラフに、サイクルタイムなどの変動値を AWS IoT SiteWise に分離する設計の解説です。ISA-95 との対応表もあり、データモデル設計の出発点として参考になります。 7/22 AWS Japan Summit 2026 スマートマシンデモ ー自律診断とリアルタイム安全監視ー 展示報告 建設機械のフリート遠隔監視を題材に、予知保全の 3 つのアプローチを比較しています。異常スコアで終わらず原因推定と対処指示まで生成するエージェントの挙動と、人と AI の役割分担の考え方をご覧いただけます。 7/24 ISA/IEC 62443 を踏まえた AWS での OT とクラウドの接続設計 産業用制御システムのセキュリティ規格を踏まえ、OT ネットワークとクラウドの接続方法を解説しています。工場データの収集を始める方にも、既存構成を監査対応の観点で見直したい方にも実務的な内容です。 事例のご紹介 7/6 東海旅客鉄道株式会社：超電導リニアの電気設備保守を支える IoT プラットフォームの構築 東海旅客鉄道株式会社（JR 東海）との共著記事です。山梨リニア実験線の電気設備で状態監視保全を実現するため、AWS 上に IoT プラットフォームを段階的に構築した事例です。AWS IoT Greengrass のコンポーネントがメーター値の読み取りや動作音の特徴量抽出、異常推論をエッジで実行し、クラウドには集計値と推論結果のみを送信します。学習からモデル配信までを Amazon SageMaker Pipelines と AWS Step Functions で自動化し、MLOps を IoT 運用に統合している点が秀逸です。設置環境が多様な拠点を抱える工場やプラントの保全高度化に参考になります。 製造関連の主要なサービスアップデート 7/20 KNFSD File Cache（プレビュー） AWS 上に高速な NFS キャッシュを構築するオープンソースソリューションです。オンプレミスの NFS エクスポートをマウントして AWS 内に再エクスポートし、頻繁に読むデータをメモリとローカル NVMe にキャッシュします。解析モデルがオンプレミスに残ったままでも CAE をクラウドにバーストできます。 7/23 Amazon Bedrock AgentCore のトレースとログが単一のロググループに統合 従来は分散していたトレースとイベントログが、エージェント単位の単一ロググループに統合されました。エージェントごとに IAM ポリシーとカスタマー管理キーによる暗号化を適用できます。プロンプトに図面や品質データが含まれるケースで鍵と権限を絞れるようになりました。 7/23 AWS Parallel Computing Service がノードライフサイクルアクションに対応 CAE や CFD の実行基盤として使われる Slurm ベースのマネージドサービスで、計算ノードのライフサイクルの任意の時点でカスタムスクリプトを自動実行できるようになりました。共有ストレージのマウントやライセンスサーバーへの接続を、独自 AMI に作り込まずに宣言的に構成できます。 7/24 Claude Opus 5 が Amazon Bedrock で利用可能に 長時間のエージェント処理を想定したモデルで、Bedrock 上ではゼロデータリテンションが既定で有効です。図面や仕様書の解析に適しており、設計情報を扱う際の社内審査を通しやすくする要素になります。同じ 7 月には OpenAI GPT-5.6 系モデルの値下げ も発表されました。 7/27 Amazon Neptune がタグベースアクセス制御（TBAC）に対応 リソースタグと IAM プリンシパルタグを条件に使い、グラフデータベースのデータプレーン操作を制御できるようになりました。クラスターの ARN を列挙せずにアクセス境界を運用できるため、BOM グラフを事業部別・拠点別に分離して運用する際のガバナンス手段になります。 7/27 AWS Glue Data Quality が異常検知とカタログへの結果書き込みに対応 しきい値のルールを書かずに、機械学習による時系列予測で「一意な値の急減」や「行数のスパイク」を検出できるようになりました。結果は Data Catalog に書き戻して SQL で照会できます。あわせて 分布統計への対応 も発表され、品質監査の証跡づくりに活用できます。 7/31 Context Ontology Accelerator が一般提供開始 今月の一番の注目です。企業の業務を機械可読なオントロジーとしてモデル化するオープンソースで、AI が起案し現場の専門家が承認したうえで、W3C 標準のナレッジグラフとして自社で保有します。付属の MCP サーバー経由で任意のエージェントから参照でき、Amazon Neptune と Amazon OpenSearch Serverless で構成されます。設備・工程・品質規格の定義が PLM や MES に散在する状況は多くの現場で共通の課題です。回答根拠がグラフとして追跡できるため、PoC で止まりがちだった工場の AI エージェントを監査可能な形で本番に載せる道筋になります。 最後まで読んでいただきありがとうございました。今月はロボットが「感じる」「言葉を理解する」ようになる話と、企業の業務知識を機械可読なグラフとして持つ話をお届けしました。現実世界で動く AI にはそれを支える文脈のデータが必要という点で、この 2 つは同じ方向を向いているように思います。来月も 月刊 AWS 製造ブログ をよろしくお願いします。それでは、また来月お会いしましょう！ 著者について 松永 充弘 (Mitsuhiro Matsunaga) シニア ソリューションアーキテクト 製造業のお客様を担当するソリューションアーキテクトです。クラウド × データ × AI でお客様のビジネスを支援しています。前職では製造業にて、機器の IoT 化、AI 活用を担当していました。

本記事は 2026 年 3 月 23 日 に公開された「 Extract data from Amazon Aurora MySQL to Amazon S3 Tables in Apache Iceberg format 」を翻訳したものです。 Amazon Aurora MySQL-Compatible Edition でデータを管理していて、分析や機械学習 (ML)、サービス横断のクエリに活用できるモダンなレイクハウス形式で利用可能にしたい、という方は多いのではないでしょうか。 組織では分析の実行、ML モデルの構築、複数ソースのデータの結合が必要になることがよくあります。こうしたワークロードはリソースを大量に消費し、トランザクションデータベースで直接実行するのは現実的ではありません。Aurora MySQL のデータを Amazon S3 Tables に Apache Iceberg 形式で抽出すれば、本番データベースのパフォーマンスに影響を与えずに分析クエリをオフロードでき、分析に最適化されたフルマネージドの Iceberg テーブルストアにデータを保存できます。オープンな Apache Iceberg 標準に基づく Amazon Simple Storage Service (Amazon S3) Tables のデータは、 Amazon Athena 、 Amazon Redshift Spectrum 、 Apache Spark などのエンジンから追加のデータコピーなしでクエリできます。さらに、データレイクに既に存在する他のデータセットとリレーショナルデータを組み合わせることで、より充実したクロスドメインのインサイトを得られます。 Apache Iceberg と Amazon S3 Tables Apache Iceberg は、ACID トランザクション、スキーマの進化、タイムトラベル機能を提供する、広く採用されているオープンテーブル形式です。複数のエンジンが同一データセットに対して同時に処理できるため、オープンレイクハウスアーキテクチャの構築で広く選ばれています。 Amazon S3 Tables は、分析ワークロード向けに設計された専用のフルマネージド Apache Iceberg テーブルストアです。セルフマネージドの Iceberg テーブルと比較して、クエリパフォーマンスが最大 3 倍、1 秒あたりのトランザクション数が最大 10 倍に向上します。また、データの自動コンパクションと参照されていないファイルの自動削除により、ストレージとパフォーマンスが最適化されます。 本記事では、 Amazon Aurora MySQL Serverless v2 からテーブルを抽出し、 AWS Glue を使って Amazon S3 Tables に Apache Iceberg 形式で書き込む、エンドツーエンドの自動化ソリューションの構築方法を紹介します。インフラ全体を 1 つの AWS CloudFormation スタックでデプロイします。 課題 AWS は Amazon Aurora から Amazon Redshift や Amazon SageMaker AI へのゼロ ETL 統合を提供しており、分析や機械学習ワークロード向けにシームレスなデータフローを実現しています。 しかし、Amazon Aurora と Amazon S3 Tables 間にはまだネイティブな ゼロ ETL 統合がありません。そのため、レイクハウスアーキテクチャに Amazon S3 Tables を活用しようとする組織は、以下のような課題に直面します。 Amazon Aurora からデータを抽出し Apache Iceberg 形式に変換する ETL パイプラインの構築 プライベートサブネットの Amazon Aurora データベースにアクセスするための AWS Glue ジョブのネットワークとセキュリティの設定 ソースデータベース、ETL パイプライン、ターゲットテーブルストアのプロビジョニングの調整 ネイティブな自動化なしでのエンドツーエンドワークフローの管理 ソリューション概要 このソリューションでは、Amazon Aurora MySQL Serverless v2 のリレーショナルデータベーステーブルを AWS Glue 5.0 で Amazon S3 Tables に Apache Iceberg 形式で抽出する処理を自動化します。すぐに試せるように CloudFormation テンプレートを用意しています。このテンプレートでインフラのプロビジョニング、サンプルデータのロード、ETL パイプラインの設定がすべて完了します。独自のシナリオに合わせてテンプレートをカスタマイズできます。 サンプルデータ このソリューションでは TICKIT サンプルデータベース を使用します。Amazon Redshift のドキュメントで使われているよく知られたデータセットで、架空のチケット販売システムを 7 つの相互関連テーブル (users、venue、category、date、event、listing、sales) でモデル化しています。データセットは Amazon Redshift 入門ガイド に記載のとおり、一般公開されています。 ソリューションのフロー 前述のアーキテクチャ図に示したソリューションのフローは以下のとおりです。 AWS Lambda 関数が TICKIT サンプルデータセット (Amazon Redshift ドキュメントで使用されている架空のチケット販売システム) をパブリックな Amazon S3 バケットからステージング用 S3 バケットにダウンロードします。 2 番目の Lambda 関数が PyMySQL (Python の MySQL クライアントライブラリ) を使用し、 LOAD DATA LOCAL INFILE でステージング済みデータファイルを Aurora MySQL Serverless v2 データベースにロードします。 AWS Glue ジョブがネイティブな MySQL 接続で Aurora MySQL から 7 つの TICKIT テーブルを読み取り、SigV4 認証を使って S3 Tables REST カタログエンドポイント経由で Amazon S3 Tables に Apache Iceberg 形式で書き込みます。 移行されたデータは Amazon Athena で S3 Tables に対してクエリできます。 このソリューションは以下の主要コンポーネントで構成されます。 TICKIT サンプルデータセット (users、venue、category、date、event、listing、sales テーブル) を格納するソースリレーショナルデータベースとしての Amazon Aurora MySQL Serverless v2 Aurora MySQL データベースの認証情報を安全に保存する AWS Secrets Manager パブリックな redshift-downloads S3 バケットからダウンロードした TICKIT サンプルデータファイルのステージング用 Amazon S3 バケット PyMySQL を使って Aurora MySQL にデータをロードする AWS Lambda 関数 Aurora MySQL からテーブルを読み取り S3 Tables に Apache Iceberg 形式で書き込む AWS Glue 5.0 ジョブ (PySpark) 移行された Iceberg テーブルのターゲットストレージとしての Amazon S3 Tables プライベートサブネットと Amazon S3、S3 Tables、AWS Glue、Secrets Manager、AWS Security Token Service (AWS STS)、CloudWatch Logs、CloudFormation 用の VPC エンドポイントを備えた Amazon VPC このアーキテクチャの主な利点は以下のとおりです。 完全自動化されたセットアップ: 1 つの CloudFormation スタックでインフラのプロビジョニング、サンプルデータのロード、ETL パイプラインの設定が完了します。 サーバーレスでコスト効率に優れた構成: Aurora MySQL Serverless v2 と AWS Glue はどちらも需要に応じてスケールし、アイドル時のコストを最小限に抑えます。 Apache Iceberg テーブル形式: データは Apache Iceberg 形式で保存され、ACID トランザクション、スキーマの進化、タイムトラベルクエリが利用できます。 ネットワーク分離と認証情報管理: リソースはプライベートサブネット内で VPC エンドポイント経由で動作し、データベース認証情報は AWS Secrets Manager で管理されます。 拡張可能なパターン: 同じアプローチを他のリレーショナルデータベース (PostgreSQL、SQL Server) や AWS Glue がサポートする他のターゲット形式にも適用できます。 前提条件 この手順を進めるには AWS アカウントが必要です。まだ AWS アカウント をお持ちでない場合は作成してください。CloudFormation スタックのデプロイには約 30〜45 分 かかり、 Amazon S3 Tables 、 AWS CloudFormation 、 Apache Iceberg 、 AWS Glue 、 Amazon Aurora に関する基本的な知識が必要です。このソリューションは AWS のコストが発生します。主なコスト要因は AWS Glue ETL ジョブの実行 (DPU 時間あたりの課金、データ量に比例) と Amazon S3 Tables のストレージおよびリクエスト料金です。不要になったらリソースをクリーンアップしてください。 CloudFormation パラメータ CloudFormation スタックのデプロイ前に以下のパラメータを設定できます。 パラメータ 説明 デフォルト値 必須 S3TableBucketName 作成する (既存のものを使用する場合はその) S3 Tables バケット名 はい DatabaseName Aurora MySQL の初期データベース名 tickit いいえ MasterUsername Aurora MySQL のマスターユーザー名 admin いいえ VpcCidr VPC の CIDR ブロック 10.1.0.0/16 いいえ S3TableNamespace S3 Tables の Namespace tickit いいえ 実装ウォークスルー 以下の手順で実装を進めます。ゼロからエンドツーエンドのソリューションをデプロイしてテストする手順です。すでに一部のコンポーネントを実行している場合は、該当するステップに進んでください。ソリューション全体は aws-samples リポジトリの sample-to-write-aurora-mysql-to-s3tables-using-glue も参照できます。 ステップ 1: CloudFormation スタックのデプロイ CloudFormation テンプレート scripts/aurora-mysql-to-s3tables-stack.yaml を AWS マネジメントコンソールまたは AWS Command Line Interface (AWS CLI) でデプロイします。S3 Tables バケット名を指定すると、スタックが自動的に作成します (既存のバケットがある場合はそれを使用します)。 AWS マネジメントコンソール(推奨)でデプロイする場合、AWS CloudFormation コンソールに移動して CloudFormation テンプレートを使用します。AWS CLI でデプロイする場合は、まずテンプレートを S3 バケットにアップロードします (テンプレートはインライン ‐‐template-body の 51,200 バイト制限を超えるため)。その後スタックを作成します。 # Upload the template to S3 aws s3 cp scripts/aurora-mysql-to-s3tables-stack.yaml \ s3://<your-s3-bucket>/aurora-mysql-to-s3tables-stack.yaml \ --region <your-region> # Create the stack using the S3 template URL aws cloudformation create-stack \ --stack-name aurora-mysql-tickit-stack \ --template-url https://<your-s3-bucket>.s3.<your-region>.amazonaws.com/aurora-mysql-to-s3tables-stack.yaml \ --parameters \ ParameterKey=S3TableBucketName,ParameterValue=<your-s3-table-bucket-name> \ --capabilities CAPABILITY_NAMED_IAM \ --region <your-region> スタックは以下を自動的に実行します。 S3 Tables バケットの作成 (既存の場合はそのまま使用) プライベートサブネットと VPC エンドポイントを含む VPC の作成 Aurora MySQL Serverless v2 クラスターのプロビジョニング パブリックな Amazon S3 バケットから TICKIT サンプルデータのダウンロード PyMySQL を使った Lambda 関数による Aurora MySQL へのサンプルデータのロード S3 Tables に Iceberg 形式でデータを移行する Glue ジョブの作成 注記: S3 Tables バケットはスタック削除時にも保持され、データが保護されます。 ステップ 2: Aurora MySQL データの確認 CloudFormation スタックから AuroraClusterEndpoint、DatabaseName、SecretArn の値を取得してメモします。Amazon Aurora コンソールの Query Editor に移動し、CloudFormation スタックの値を入力して接続できます。 Amazon Aurora DB クラスターへの接続 で好みの方法を選択することもできます。 AWS CLI でスタック出力を取得するには以下を実行します。 aws cloudformation describe-stacks --stack-name aurora-mysql-tickit-stack --region <your-region> --query "Stacks[0].Outputs" 次の SQL コマンドでデータロードを確認します。 -- Verify if the tables are created SELECT * FROM information_schema.tables WHERE table_schema = 'tickit'; -- Verify if the data is loaded SELECT 'users' AS table_name, COUNT(*) AS record_count FROM tickit.users UNION ALL SELECT 'venue', COUNT(*) FROM tickit.venue UNION ALL SELECT 'category', COUNT(*) FROM tickit.category UNION ALL SELECT 'date', COUNT(*) FROM tickit.date UNION ALL SELECT 'event', COUNT(*) FROM tickit.event UNION ALL SELECT 'listing', COUNT(*) FROM tickit.listing UNION ALL SELECT 'sales', COUNT(*) FROM tickit.sales; ステップ 3: Glue ジョブの実行 AWS Glue コンソールに移動し、左パネルの Data Integration and ETL から ETL jobs を選択します。AWS Glue ジョブ mysql-tickit-to-iceberg-job を選択して Run job をクリックし実行を開始します。AWS CLI で ETL ジョブを開始することもできます。 aws glue start-job-run --job-name mysql-tickit-to-iceberg-job --region <your-region> AWS Glue ジョブは 7 つの TICKIT テーブルそれぞれに対して以下の処理を実行します。 ネイティブな MySQL Glue 接続で Aurora MySQL からテーブルを読み取り Spark DataFrame に変換 USING ICEBERG 句を指定した CREATE TABLE IF NOT EXISTS で S3 Tables Namespace に Iceberg テーブルを作成 INSERT INTO (テーブルが既に存在する場合は INSERT OVERWRITE) でデータを挿入 レコード数の検証とサンプルデータの表示 ステップ 4: 結果の確認 AWS Glue ジョブの完了後、Amazon S3 コンソールに移動して S3 Table バケットにテーブルが作成されたことを確認します。Buckets の Table buckets を選択し、S3 Table バケットを選びます。AWS CLI でも確認できます。 aws s3tables list-tables \ --table-bucket-arn arn:aws:s3tables:<your-region>:<your-account-id>:bucket/<your-s3-table-bucket-name> \ --namespace tickit \ --region <your-region> tickit Namespace のテーブルを選択し、 Preview をクリックしてデータを確認します。 Amazon Athena で移行されたテーブルに対してクエリを実行し、データを検証することもできます。 リソースのクリーンアップ 不要になったリソースは忘れずにクリーンアップし、不必要な料金の発生を防いでください。 CloudFormation コンソールでスタックを検索し、 Delete を選択します。AWS CLI でも削除できます。 aws cloudformation delete-stack --stack-name aurora-mysql-tickit-stack --region <your-region> S3 Tables バケットはデフォルトで保持されます。削除する場合は Amazon S3 コンソールまたは AWS CLI で Table バケットを個別に削除してください。ステージング用 S3 バケットはスタック削除時に自動的に空にされて削除されます。 aws s3tables delete-table-bucket --table-bucket-arn arn:aws:s3tables:<your-region>:<your-account-id>:bucket/<your-s3-table-bucket-name> --region <your-region> まとめ 本記事では、Amazon Aurora MySQL Serverless v2 からデータを抽出し、AWS Glue 5.0 を使って Amazon S3 Tables に Apache Iceberg 形式で書き込む方法を紹介しました。AWS Glue のネイティブな Iceberg サポートと S3 Tables REST カタログエンドポイントを活用することで、リレーショナルデータベースとモダンなレイクハウスストレージ形式の間のギャップを埋められます。CloudFormation でパイプライン全体を自動化することで、複数環境へのセットアップと展開を迅速に行えます。 AWS Glue と Amazon S3 Tables は今後も進化を続けるため、この自動化された移行パターンを維持しながら将来の機能強化を活用できます。 ご質問やご提案がありましたら、コメントをお寄せください。 著者について Kunal Ghosh Kunal は、AWS のシニアソリューションアーキテクトです。生成 AI、分析、データサイエンス、機械学習を活用した効率的で効果的なソリューション構築に情熱を注いでいます。家族との時間のほか、読書、水泳、サイクリング、映画鑑賞が趣味です。 Arghya Banerjee Arghya は、サンフランシスコ・ベイエリアの AWS シニアソリューションアーキテクトです。お客様の AWS Cloud 導入と活用を支援しています。ビッグデータ、データレイク、ストリーミングおよびバッチ分析サービス、生成 AI テクノロジーを専門としています。 Indranil Banerjee Indranil は、サンフランシスコ・ベイエリアの AWS シニアソリューションアーキテクトです。ハイテクおよび半導体セクターのお客様が AWS Cloud を使用してビジネス課題を解決するのを支援しています。レガシーモダナイゼーションと移行、分析プラットフォームの構築、生成 AI などの最先端テクノロジーの導入支援を専門としています。 Vipan Kumar Vipan は、AWS のシニアソリューションアーキテクトです。戦略的なお客様を担当しています。機械学習と生成 AI に豊富な経験を持ち、アプリケーション開発のバックグラウンドを活かして、クラウド向けエンタープライズアプリケーションの設計と構築に情熱を注いでいます。 この記事は、Solutions Architect の Shinya Sugiyama が翻訳を担当しました。

アマゾン ウェブ サービス ジャパン（以下、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 原文は こちら です。