本ブログは dSPACE Japan 様と アマゾン ウェブ サービス ジャパン合同会社が共同で執筆いたしました。 1. はじめに 自動車分野で行われている自動運転技術の開発では、データ駆動型アプローチの重要度が高まっています。膨大な実走行データを体系的に整備・活用することで多様な運転環境への対応が可能になり、モデルの汎化性能と信頼性を継続的に向上させることができます。 しかし、自動運転システムが生成するデータ量は膨大であり、その管理と活用には大きな課題が伴います。データ収集から学習、検証、デプロイ、モニタリングまでを統合管理する「MLOps」の導入が不可欠です。 本記事では、30 年以上にわたり車両開発ツールを提供してきた dSPACE 社の製品と、AWS クラウドサービスを統合した MLOps ソリューションをご紹介します。 2. 自動運転開発における課題 自動運転技術の進展に伴い、AI を活用した認識・判断アルゴリズムの高度化が急速に進んでいます。一方で、実際の車両開発・量産適用を見据えると、単なるモデル精度の向上だけでは解決できない、複合的な課題に直面されているのではないでしょうか。 膨大かつ多様なセンサーデータの管理と活用 先進的な自動運転システムでは、1 時間あたり 1 テラバイトを超えるカメラデータに加え、LiDAR、Radar、GPS など多種多様なセンサーデータが生成されます。これらのデータは地理的にも分散して収集されることが多く、効率的な保存・検索、シナリオや条件に基づくデータ抽出、開発・検証フェーズ間での一貫したデータ利用を実現することが大きな課題となっています。 学習精度と車両環境での挙動の乖離 クラウド環境で学習した AI モデルが高い認識精度を示していても、リアルタイム実行制約、センサー同期誤差やノイズ、車載ハードウェア上での実行条件といった要因により、実車両環境では期待通りに動作しないケースが少なくありません。このため、学習結果をそのまま車両に適用するのではなく、車両環境を考慮した検証・評価プロセスを MLOps と連携させることが不可欠となります。 検証と学習の分断による改善サイクルの停滞 自動運転の安全性は、まれなエッジケースや特定シナリオへの対応によって大きく左右されます。しかし多くの開発現場では、クラウドを中心とした AI 開発・MLOps チームと、SIL (Software-in-the-Loop)／HIL (Hardware-in-the-Loop)／実車評価を担う車両開発チームが、異なるツールやプロセスで作業しています。この分断により、どのシナリオで性能低下が発生したのか、その原因となるデータをどのように再学習へ反映させるのかといった情報がチーム間で共有されず、検証結果を効率的に再学習へフィードバックする仕組みが整っていないケースが多く見られます。検証結果と学習データを結び付け、継続的な改善サイクルを回すことが大きな課題です。 再現性・説明責任の確保と検証コストの増大 自動運転 AI の開発では、使用したデータ、学習条件、モデル構成、検証環境を後から正確に説明・再現できることが求められます。しかし、実験管理、検証条件、車両構成情報が個別に管理されることで、結果の再現性やトレーサビリティの確保が困難になり、社内レビューや将来的な認証・法規対応を見据えた際に重大なリスクとなります。さらに、データ駆動型開発ではモデル更新が頻繁に行われるため、そのたびに同等レベルの検証を実施することは大きな負担となります。すべてを再検証するのではなく、モデル変更の影響範囲を見極め、効率的に検証を行う仕組みが必要とされています。 これらの課題を解決するためには、クラウド MLOps のスケーラビリティと、車両開発・検証を熟知したツールチェーンを統合し、データ収集から学習、検証、デプロイ、モニタリングまでを一貫して管理できる基盤が求められます。次章では、こうした課題に対応する dSPACE と AWS による統合 MLOps ソリューションについて詳しく説明します。 3. ソリューション： dSPACE と AWS による自動運転向け統合 MLOps アーキテクチャ 自動運転 AI 開発における効率化を実現するため、dSPACE と AWS はそれぞれの強みを活かし、AI モデルの学習から SIL/HIL での検証、さらに実運用を見据えた評価・改善までをつなぐ統合 MLOps 環境を共同で提供します。本ソリューションでは、データ駆動開発（DDD）で扱うデータ収集・整備・検証の流れ（左側）と、MLOps で扱う学習・追跡・デプロイの流れ（右側）を接続します。これにより、学習と検証が分断されがちな自動運転 AI 開発において、改善サイクルを一貫したパイプラインとして回すことを目指します。 本アーキテクチャの特徴は、dSPACE 製品と AWS サービスがシームレスに連携できる点にあります。 図1: AWS サービスと dSPACE 製品の統合アーキテクチャ Data Collection：後工程で“使える形”を前提にしたデータ収集 本パイプラインの起点は、走行試験、評価ベンチ、シミュレーションなど多様なソースから得られるデータの収集です。自動運転開発ではデータ量の多さだけでなく、どの条件・どのシナリオで取得されたかが重要となるため、後工程での検索・抽出・学習・検証に耐えうる形で蓄積することが求められます。 この Data Collection フェーズでは、 RTMaps を活用することで、カメラ、Radar、LiDAR など複数センサのデータをリアルタイムに扱いながら、システム全体としての振る舞いを意識したデータ取得が可能となります。さらに、RTMaps を用いたデータ収集は、後続の検証や SIL/HIL を含むシステム統合試験でも同一の処理構成を再利用できるため、データ取得と検証の分断を抑えたパイプライン設計につながります。こうして収集されたデータは、次の Data Preparation フェーズにおいて IVS に引き渡され、タグ付けや検索、データセット化といった処理へとスムーズに接続されます。 Data Preparation：IVS によるデータマネジメントとデータセット管理 収集したデータは、学習にそのまま利用できるとは限りません。Data Preparation フェーズでは、 dSPACE IVS (Intempora Validation Suite) を用いて、データの自動タグ付け、検索、変換を行い、学習に適したデータセットとして整理します。 重要なのは、単にデータを整えるだけでなく、どの条件で抽出・加工されたデータセットなのかを後から辿れることです。本パイプラインでは、IVS を介してデータセット定義と証跡（トレーサビリティ）を管理し、以降の学習・検証フェーズと一貫して結び付けます。 Training：AWS を活用した学習の自動化と実験・モデル管理 整備されたデータセットは、AWS のクラウドサービスへシームレスに受け渡され、大規模な学習処理が実行されます。本構成では、 Amazon SageMaker AI を中心とした学習基盤を活用し、必要な計算リソースを柔軟に利用することで、効率的なモデル学習を実現します。 SageMaker Training Jobs は、学習ジョブごとに GPU インスタンスを自動的にプロビジョニングするため、高価な GPU リソースを学習実行時のみ使用でき、コスト効率に優れています。また、学習コードをコンテナイメージとして Amazon ECR に格納し、学習データを Amazon S3 に配置するアーキテクチャにより、「コード・データ・環境」の三要素が分離され、実験の再現性が担保されます。さらに、実験管理には SageMaker AI のマネージド MLflow を用い、学習条件、評価指標、生成されたモデルを一元的に管理します。これにより、モデルの品質担保に必要な履歴情報を体系的に蓄積し、後工程の検証や将来の説明責任に対応します。 Validation / System Integration & Testing（SIL/HIL）：学習成果を車両開発レベルで検証し、信頼性を高める 学習によって得られた AI モデルは、SIL や HIL を活用して、自動運転システムとしての機能検証や統合試験へと進みます。 dSPACE の SIL/HIL ソリューション は、制御ソフトウェアや AI モデルを実車に近い条件で段階的に評価できる点が特長です。SIL では、アルゴリズムやソフトウェアの論理的な正しさや機能挙動を早期に確認でき、モデル更新による影響を効率的に洗い出すことができます。さらに HIL では、実際の ECU (Electronic Control Unit) として AI モデルを接続することで、リアルタイム性やインタフェース、システム全体としての振る舞いを含めた検証が可能となります。 検証フェーズで得られた結果は、データ条件やモデル情報とひも付けて管理され、Data Preparation フェーズへフィードバックされます。これにより、SIL/HIL で顕在化した課題を起点に学習データセットを見直し、再学習へつなげるといった、検証起点の改善サイクルを回すことが可能となります。結果として、モデル開発と車両開発・検証を分断することなく、品質向上と開発効率化の両立を支援します。 4. 開発環境「Kiro」を活用した開発効率化 MLOps 開発プロセスをさらに効率化するためには、AWS が提供する開発環境「 Kiro 」を利用することが考えられます。 Kiro は Spec 駆動開発を特徴とし、要件定義・設計・実装タスクを構造化されたドキュメントとして管理しながら、エージェント機能によるコード生成を行うことで、開発者が本質的なアルゴリズム設計に集中できる環境を提供します (図 2 参照)。 図 2: Kiro による MLOps 開発ワークフローの効率化 ここでは、MLOps 開発において Kiro がどのように活用できるか、いくつかの例をご紹介します。 ハイパーパラメータ最適化スクリプトの生成 エージェント機能に最適化要件を伝えることで、2 フェーズアプローチの最適化スクリプトを生成できます。Phase 1 (粗探索) でパラメータ範囲を広く設定し、ランダムに 20 組をサンプリングして並列・短時間で完了させ、Phase 2 (細探索) で Phase 1 の結果を基に最良パラメータ周辺を詳細に探索するといった、重要なパラメータを体系的に調整するスクリプトの生成が可能です。 学習データ品質チェックの自動化 学習データの品質チェックスクリプトの生成にも活用できます。データセット構造チェックでは必要なディレクトリ構成や設定ファイルを検証し、PIL (Python Imaging Library) を使った画像破損チェック、YOLO フォーマットのラベル形式検証、画像-ラベル対応関係チェックにより、不整合を検出します。破損画像や不正確なアノテーションを学習前に自動検出することで、無駄な学習実行を防止できます。 このほか、train.py や Dockerfile などのボイラープレートコード生成、SageMaker ジョブ投入スクリプトの雛形作成など、MLOps 開発における定型的な作業にも Kiro を活用することで、開発者が本質的なアルゴリズム設計に集中でき、開発サイクルの短縮が期待できます。 5. まとめ 本記事では、自動運転 AI 開発における課題と、dSPACE と AWS による統合 MLOps ソリューションをご紹介しました。RTMaps と IVS によるデータ収集・整備から、Amazon SageMaker AI と MLflow を活用した学習・実験管理、さらに SIL/HIL による車両レベルでの検証までを一貫したパイプラインとして接続することで、学習と検証の分断を解消し、検証起点の改善サイクルを回すことが可能となります。加えて、開発環境「Kiro」を活用することで、ハイパーパラメータ最適化やデータ品質チェックといった定型作業を自動化し、エンジニアが本質的なアルゴリズム設計に集中できる環境を実現します。 自動運転 AI 開発の効率化や継続的改善を検討されている方にとって、本記事がソリューション選定の一助となれば幸いです。ご質問やご相談は、dSPACE および AWS の担当者までお気軽にお問い合わせください。 著者について 丹羽 伸二 AWS Japan のシニアソリューションアーキテクトとして自動車業界のお客様を担当。自動車業界で15年以上の経験を持ち、主にプロダクトエンジニアリング領域におけるモダナイゼーションや AI 活用の取り組みを支援しています。 村山 哲也 dSPACE Japan 株式会社 CX 技術部 Business Prototyping グループリーダー。データドリブン開発や開発環境のプラットフォーム化などのクラウド系ソリューション、および自動車開発に関わる AI 活用に関するプロトタイピング活動とエンジニアリングをリードしています。 宮本 敬丈 dSPACE Japan 株式会社 CX 技術部 Business Prototyping グループ AI チームリーダー。データサイエンティストとして、製造業、自動車領域における AI 活用、MLOps 基盤構築、エンジニアリングプロセスの自動化に従事。AWSを含むクラウドアーキテクチャの構想や生成 AI、RAG、MCP を活用した業務高度化に取り組んでいます。  

本ブログは 2026 年 7 月 30 日に公開された AWS Blog “ Extend Amazon Inspector SBOM Generator with Plugins ” を翻訳したものです。 Amazon Inspector は、 Amazon Web Services (AWS) のワークロードを継続的にスキャンしてソフトウェアの脆弱性を検出する、自動化された脆弱性管理サービスです。Amazon Inspector の脆弱性管理機能は、 Amazon Inspector SBOM Generator (inspector-sbomgen) と呼ばれる資産インベントリエンジンによって支えられています。これはスタンドアロンのコマンドラインツールで、コンテナイメージ、ディレクトリ、アーカイブ、ローカルシステム、コンパイル済みバイナリなどから ソフトウェア部品表 (SBOM) を生成します。過去 2 年間で、AWS は inspector-sbomgen のカバレッジを数十のプログラミング言語エコシステム、オペレーティングシステム、広く導入されているアプリケーションへと拡大してきました。 今回、inspector-sbomgen を利用するビルダー向けの新機能として、独自のカスタムパッケージコレクターを記述できる プラグインシステム を発表します。ソースコードのコンパイルや公式リリースを待つ必要はなく、すぐに使い始めることができます。 inspector-sbomgen の最新バージョンは、 Amazon Inspector ユーザーガイド からダウンロードできます。 この記事では、inspector-sbomgen プラグインシステムでできること、これを構築した理由、そして数分で最初のプラグインを書く方法を紹介します。あわせて、プラグインが生成したパッケージコンポーネントを Amazon Inspector の脆弱性スキャンと統合する方法や、セキュリティが強化された予測可能なプラグイン動作を実現するプラグインの安全性モデルについても解説します。 プラグインシステムを構築した理由 ソフトウェアのエコシステムは動的です。新しい言語パッケージマネージャー、ロックファイル形式、エンドユーザーアプリケーションが絶えずリリースされ、その多くは迅速に採用されます。中にはセキュリティの検証がほとんど行われないまま使われるものもあります。その結果、セキュリティチームには可視性のギャップが残ります。つまり、SBOM ツールがまだ認識できないソフトウェアが本番ワークロードで動いているという状態です。お客様からは、こうしたエコシステムの多くを直接インベントリ化したいという要望をいただいてきました。最近まで、それを実現する唯一の方法は、機能リクエストを出して inspector-sbomgen チームがエコシステムに対応し、新しいリリースをデプロイするのを待つことでした。 inspector-sbomgen プラグインシステムは、この状況を変えます。プラグインを使うと、次のことができます。 inspector-sbomgen が標準では対応していないエコシステムへの対応 – 新しいオープンソースエコシステム、ニッチまたは変化の速いパッケージ形式、組織独自のツールなど、inspector-sbomgen を変更することなくインベントリ化できます エコシステム検出の迅速なプロトタイピング – 開発者にも AI コーディングアシスタントにも扱いやすいプラグインシステムを設計しました。プラグインは Lua で記述され、実行時にロードされるため、Go ツールチェーンもコンパイルも不要です。組み込みのテストハーネスを使ってプラグインを繰り返し改善し、すぐに結果を確認できます 安定した基盤の上での構築 – プラグイン API はアーティファクトの種類による違いを抽象化するため、検出ロジックを一度書くだけで、コンテナイメージ、アーカイブ、ローカルシステムなどでシームレスに動作します。また、プラグインは sbomgen の内部構造から分離されているため、コアツールでリグレッションが発生した場合の影響範囲も小さく抑えられます 実際、私たち自身もこのプラグインシステムを内部で活用し、新しいエコシステムのカバレッジを以前より速く提供できるようになりました。 1.13 リリース では、Apache Tomcat、NGINX、MySQL、Redis、WordPress、OpenSSH ツールチェーンなど、これまで Go で実装されていた 20 以上のエコシステムが、プラグインとして sbomgen バイナリに組み込まれています。同じリリースでは、Apache Cassandra、Apache Struts、Conda、Swift パッケージ、AI エージェントコレクター (Amazon Q Developer、Kiro CLI、Claude Code、GitHub Copilot、Ollama) など、10 を超える新しいエコシステムもプラグインとして追加されました。 inspector-sbomgen プラグインの仕組み sbomgen プラグインは 2 段階のパイプラインで動作します。 検出 (discovery) – アーティファクトのファイルシステムをスキャンし、インストール済みパッケージのメタデータを含むファイルを特定します 収集 (collection) – 検出された各ファイルを開き、ファイルの内容を解析して、結果を SBOM にパブリッシュします 内部では、イベントバスが検出プラグインと収集プラグインをつないでいます。検出プラグインは検出したファイルの一覧をイベントとしてパブリッシュし、1 つ以上の収集プラグインがそのイベントをサブスクライブして、パッケージ収集をトリガーします。開発者にとっては、これは オブザーバーパターン としておなじみの動作でしょう。 この分離により、1 つの検出プラグインが複数のコレクターにデータを供給できます。例えば、あるコレクターはパッケージメタデータを抽出し、別のコレクターはシークレットをスキャンし、さらに別のコレクターはポリシーをチェックする、といった構成が可能です。各収集プラグインは、計算コストの高いアーティファクトファイルシステムの再走査を行うことなく、同じファイルリストを利用できます。 5 分で書ける最初のプラグイン inspector-sbomgen を使えば、プラグイン環境を簡単にセットアップできます。 plugin new コマンドで sbomgen に新しいプラグインワークスペースを作成させ、 --with-example フラグを指定すると、すぐに実行できる検出プラグインと収集プラグインのペアがワークスペースに用意されます。 inspector-sbomgen plugin new --with-example 上記のコマンドを実行すると、プラグイン名と、プラグインワークスペースを格納するディレクトリの入力を求められます。カスタム値を指定することも、デフォルト値をそのまま使うこともできます。 Plugin name (identifies the software ecosystem your plugin will inventory, e.g. debian-dpkg, rhel-rpm, python-pip, cmake) [my-custom-ecosystem]: <enter> Project directory [my-sbomgen-plugins]: <enter> Created plugin "my-custom-ecosystem" in my-sbomgen-plugins/ なお、対応するコマンドラインインターフェイス (CLI) 引数でプラグイン名とディレクトリを指定すれば、対話形式のプロンプトをスキップできます。 inspector-sbomgen plugin new \ --with-example \ --name my-custom-ecosystem \ --path my-sbomgen-plugins プラグインワークスペースを作成すると、inspector-sbomgen は次のステップを案内する画面を表示します。開発者や AI コーディングアシスタントに対して、変更が必要なソースファイルや関連ドキュメントの場所を示してくれます。 Next steps: Get started: 1. Open plugin folder in a code editor (VS Code recommended) 2. Add test files that your plugin will discover and parse (e.g., config files, lockfiles, binaries, etc.): my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/_testdata/ Develop: 3. Edit discovery: my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/init.lua 4. Edit collection: my-sbomgen-plugins/collection/cross-platform/extra-ecosystems/my-custom-ecosystem/init.lua Test: 5. Write unit tests: my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/init_test.lua 6. Run unit tests: inspector-sbomgen plugin test --path my-sbomgen-plugins Deploy: 7. Distribute your plugin directory wherever you run inspector-sbomgen: inspector-sbomgen <arguments> --plugin-dir /path/to/my-sbomgen-plugins Example: inspector-sbomgen container --image alpine:latest -o /tmp/sbom.json --plugin-dir /path/to/my-sbomgen-plugins For code completion, install the VS Code Lua language server extension: https://luals.github.io/#vscode-install For more information: - Plugin guide: my-sbomgen-plugins/docs/sbomgen-plugin-developer-guide.md - Testing guide: my-sbomgen-plugins/docs/sbomgen-plugin-testing-guide.md - API reference: my-sbomgen-plugins/docs/sbomgen-plugin-api-reference.md - Documentation: https://docs.aws.amazon.com/inspector/latest/user/sbom-generator.html プラグインワークスペースができたので、その中身を詳しく見てみましょう。 tree my-sbomgen-plugins ├── AGENTS.md ├── collection │   └── cross-platform │   └── extra-ecosystems │   └── my-custom-ecosystem │   └── init.lua ├── discovery │   └── cross-platform │   └── extra-ecosystems │   └── my-custom-ecosystem │   ├── _testdata │   │   ├── empty │   │   └── example.lock │   ├── init_test.lua │   └── init.lua ├── docs │   ├── sbomgen-plugin-api-reference.md │   ├── sbomgen-plugin-developer-guide.md │   └── sbomgen-plugin-testing-guide.md ├── library │   └── sbomgen.lua └── README.md スキャフォールディングされたプロジェクトには、動作する検出プラグインと収集プラグインのペア、 _testdata/ 配下のテストフィクスチャを使ってパスするユニットテスト、統合開発環境 (IDE) 連携用の .vscode/settings.json 、開発者ドキュメントのローカルコピーが含まれています。 スキャフォールディングは、人間と AI コーディングアシスタントの両方が読みやすいように、意図的に簡潔で完結した内容になっています。各ファイルには、それぞれの関数の役割と、プラグイン作成者が記述すべき箇所を説明する明確なコメントが付いています。 プラグインをテストするには、まずパッケージロックファイルやコンパイル済みバイナリなど、スキャン対象となるものが必要です。サンプルプラグインは、次の内容を持つ架空の example.lock をインベントリ化します。 my-package-alpha==1.0.0 my-package-beta==2.3.1 my-package-gamma==0.9.5 付属の検出プラグインは、アーティファクトのファイルシステム内で example.lock のインスタンスを探す方法を知っています。 -- my-custom-ecosystem discovery plugin -- Discovers example.lock files in the artifact file list. function discover() return sbomgen.find_files_by_name({"example.lock"}) end そして、付属の収集プラグインは、 example.lock の内容を解析し、パッケージ情報を出力 SBOM にパブリッシュする方法を知っています。 -- my-custom-ecosystem collection plugin -- Parses example.lock files and extracts package name and version. function collect(file_path) local content = sbomgen.read_file(file_path) if content == nil then return end for line in content:gmatch("[^\n]+") do local name, ver = line:match("^(.+)==(.+)$") if name and ver then sbomgen.push_package({ name = name, version = ver, purl_type = "generic", namespace = "my-custom-ecosystem", component_type = sbomgen.component_types.APPLICATION, }) end end end テストの実行 プラグインにはテストフレームワークが組み込まれているため、実際のアーティファクトをスキャンする前にロジックを検証できます。テストは Lua で記述し、プラグインと同じ場所の init_test.lua に配置して、 _testdata/ 内のフィクスチャデータを参照します。 function test_discovers_packages() local result = testing.scan_directory("_testdata") testing.assert_equals(3, #result.findings) testing.assert_equals("my-package-alpha", result.findings[1].name) testing.assert_equals("1.0.0", result.findings[1].version) end function test_no_findings_for_empty_directory() local result = testing.scan_directory("_testdata/empty") testing.assert_equals(0, #result.findings) end 次のコマンドでテストを実行します。 inspector-sbomgen plugin test --path my-sbomgen-plugins -v === RUN my-custom-ecosystem/discovery/init_test/test_discovers_packages --- PASS: my-custom-ecosystem/discovery/init_test/test_discovers_packages (0.04s) === RUN my-custom-ecosystem/discovery/init_test/test_no_findings_for_empty_directory --- PASS: my-custom-ecosystem/discovery/init_test/test_no_findings_for_empty_directory (0.04s) ok 2 tests passed これは、私たちが設計し得た最も短い開発ループです。Go ツールチェーンも、再ビルドも、コンテナの起動も不要です。テストを書き、実行し、繰り返し改善するだけです。 実際のアーティファクトのスキャン プラグインが結果を生成するには、プラグインが探すファイルを含むアーティファクトを inspector-sbomgen に与える必要があります。サンプルプラグインの場合、 example.lock ファイルを含む任意のディレクトリが対象になります。先ほど生成したフィクスチャがちょうど良い題材です。 inspector-sbomgen directory \ --plugin-dir ./my-sbomgen-plugins \ --path ./my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/_testdata \ -o sbom.json --plugin-dir フラグは、Lua プラグインの読み込み元を inspector-sbomgen に伝えます。生成される SBOM には、 example.lock 内の 3 つのパッケージそれぞれに対応する CycloneDX コンポーネントが含まれます。例を以下に示します。 { "bom-ref": "comp-2", "type": "application", "name": "my-package-alpha", "version": "1.0.0", "scope": "optional", "purl": "pkg:generic/my-sbomgen-plugin/my-package-alpha@1.0.0", "properties": [ { "name": "amazon:inspector:sbom_generator:source_path", "value": "./my-sbomgen-plugins/example.lock" } ] } プラグインが生成するすべてのコンポーネントには、収集元のファイルを記録する amazon:inspector:sbom_generator:source_path プロパティが付いています。そのため、コンポーネントを生成元のアーティファクトまで常にたどることができます。 Amazon Inspector による脆弱性スキャン プラグインが生成したパッケージ情報は、他のコンポーネントと同等の正式な SBOM コンポーネントとして扱われます。Amazon Inspector を含め、CycloneDX SBOM を読み取るあらゆる下流のツールで利用できます。SBOM を Amazon Inspector に送信して脆弱性分析を行うには、 --scan-sbom フラグを追加します (有効な AWS アカウントが必要です)。 inspector-sbomgen directory \ --path ./my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/_testdata \ --plugin-dir ./my-sbomgen-plugins \ --scan-sbom \ --aws-profile your_profile \ --aws-region your_region \ -o /tmp/sbom.json まったく新しいエコシステムに対応する際の重要な注意点 : プラグイン作成者は任意のエコシステムをインベントリ化できますが、Amazon Inspector が脆弱性を報告できるのは、アドバイザリが存在するコンポーネントに限られます。アドバイザリフィードにまだ含まれていないエコシステムのコンポーネントを Amazon Inspector に渡すと、Amazon Inspector は Component skipped: no supported rules found (コンポーネントはスキップされました: サポートされるルールが見つかりません) というプロパティ付きでコンポーネントを返します。以下に例を示します。 { "bom-ref": "comp-1", "name": "my-package-alpha", "properties": [ { "name": "amazon:inspector:sbom_scanner:path", "value": "my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/_testdata/example.lock" }, { "name": "amazon:inspector:sbom_scanner:info", "value": "Component skipped: no supported rules found." } ], "purl": "pkg:generic/my-custom-ecosystem/my-package-alpha@1.0.0", "type": "application", "version": "1.0.0" } これはエラーではなく、想定どおりの動作です。SBOM は正しく生成され、コンポーネントは引き続き追跡され、 source_path によってどのファイルから生成されたかを正確に把握できます。Amazon Inspector がそのエコシステムのアドバイザリカバレッジを追加すれば、プラグインを一切変更することなく、同じ SBOM から脆弱性の検出結果が生成されるようになります。Amazon Inspector がすでにサポートしているエコシステムについては、プラグインが生成したコンポーネントは組み込みスキャナーが生成したコンポーネントと区別なく扱われます。 ファーストクラスの IDE サポート AWS は、プラグインを書くときの生産性と効率を重視しています。オートコンプリートのようなモダンな便利機能なしで Lua を書くのは快適とは言えません。そのため、 plugin new コマンドでスキャフォールディングされたすべてのプラグインプロジェクトには、 library/sbomgen.lua 定義ファイルと、それを VS Code の Lua Language Server 拡張機能に自動的に接続する .vscode/settings.json が付属します。 コード補完と IDE サポートを利用するには、まず sumneko.lua 拡張機能をインストールし、VS Code でプラグインプロジェクトを開きます。これにより、すべての sbomgen.* 関数で次の機能が使えるようになります。 型情報付きのパラメータヒント ホバー時のドキュメント表示 定数のオートコンプリート ( sbomgen.component_types.* 、 sbomgen.groups.* 、 sbomgen.platform.* ) 関数呼び出しの型チェック push_package() に必須フィールドが欠けている場合のインライン警告 この定義ファイルのおかげで、AI コーディングアシスタントによるプラグイン開発もうまく機能します。型情報とドキュメントがツールで読み取れる形式で埋め込まれているため、アシスタントは、素の Lua で記述する場合に比べてはるかに少ない人手の確認で正しいプラグインコードを生成できます。 安全な基盤 プラグインは inspector-sbomgen と同じプロセス内で実際のコードを実行するため、そのコードが安定し、セキュリティが強化された状態を保てるように実行環境を設計しました。すべての Lua プラグインは隔離されたサンドボックス内で実行されます。各 Lua 仮想マシン (VM) は、安全な操作のみが許可されるように、Lua 標準ライブラリの制限されたサブセットにのみアクセスできます。 ファイルシステムへの直接アクセスの禁止 – Lua の io ライブラリはロードされません。すべてのファイル操作は sbomgen.* 関数を経由して sbomgen の内部処理にルーティングされるため、ディスク上のディレクトリ、コンテナイメージ、圧縮アーカイブ、マウントされたボリュームのいずれをスキャンする場合でも、プラグインは同じように動作します サブプロセスの実行や環境の変更の禁止 – Lua の os ライブラリはブロックされているため、プラグインはプロセスの起動、環境変数の変更、アーティファクト外のファイルへのアクセスができません VM のイントロスペクションの禁止 – Lua の debug ライブラリはブロックされています 無制限なコードロードの禁止 – dofile 、 loadfile 、 loadstring は削除されています。 require() は利用できますが、プラグイン自身のディレクトリツリーに制限されているため、プラグインは自身のヘルパーモジュールを共有できる一方、他のプラグインやシステムパスからコードをロードすることはできません プラグインが未処理の Lua エラーを発生させた場合、inspector-sbomgen は警告をログに記録し、次のファイルまたはプラグインの処理を続行します。1 つの不具合のあるプラグインが他のプラグインの実行を妨げることはありません。また、プラグインが inspector-sbomgen の組み込みパッケージコレクターを上書きすることもありません。すべてのプラグインは一意の名前を宣言する必要があり、カスタムプラグインが公式の組み込みプラグインですでに使われている名前を使用した場合、そのカスタムプラグインは警告付きでスキップされます。組み込みプラグインが常に優先されるため、カスタムプラグインがツール自身の検出動作をひそかに置き換えたり隠したりすることはできません。 次のステップ 今すぐ独自のプラグインの構築を始めるには、次の手順に従ってください。 Amazon Inspector ユーザーガイド から最新の inspector-sbomgen をインストールします inspector-sbomgen plugin new --with-example を実行し、プロンプトに従います inspector-sbomgen plugin test --path ./my-sbomgen-plugins -v を実行し、サンプルテストがパスすることを確認します サンプルのロジックを、独自のエコシステム向けの検出ロジックに置き換えます すべての関数、定数、コマンドについては、以下の完全なリファレンスドキュメントで詳しく説明しています。 Lua プラグイン開発者ガイド : プラグインの概念、ディレクトリ構造、ライフサイクル Lua プラグインテストガイド : テストフレームワークのリファレンスとフィクスチャの規約 Lua プラグイン API リファレンス : sbomgen.* API の完全なカタログ まとめ 組織独自のロックファイル形式への対応の追加、新しいオープンソースエコシステム向け検出のプロトタイピング、あるいは自作スキャナーから組織全体で大規模に運用できる仕組みへの置き換えなど、どのような用途であっても、このプラグインシステムは、アイデアから動作する SBOM までの道のりをできる限り短くするように設計されています。皆さんがこれを使って何を作るのか、とても楽しみにしています。 この記事に関するご質問がある場合は、 AWS サポートにお問い合わせください 。 Michael Long Michael は AWS の Amazon Inspector 担当 Senior Security Researcher です。Amazon Inspector SBOM Generator と Amazon Inspector for GitHub Actions の研究開発を率いています。AWS 入社前は、MITRE ATT&CK チームで principal adversary emulation engineer を務めていました。また、U.S. Army (米国陸軍) で約 10 年間、軍事情報およびサイバー作戦に従事しました。 Charlie Bacon Charlie は AWS の Amazon Inspector 担当 Head of Security Engineering and Research です。Amazon Inspector や他の Amazon Security の脆弱性管理ツールを支える脆弱性スキャンおよびインベントリ収集サービスを担当するチームを率いています。AWS 入社前は、金融業界とセキュリティ業界で 20 年間にわたり、研究と製品開発の両分野で上級職を務めました。 Anthony Verleysen Anthony は Amazon Inspector 担当の Senior Technical Product Management です。Amazon Inspector の前は、AWS Systems Manager の Product Manager として Node Management 機能を担当していました。仕事以外では、テニスとサッカーに熱心に取り組んでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

2026年6月11日（木）、12日（金）の2日間、AWS 麻布台オフィスにて AI 駆動型ハッカソンイベント「AWS GenAI Catapult! 」を開催いたしました。本イベントは、生成 AI 活用を前提にAmazon のイノベーション創出メカニズム「Working Backwards」手法を用いて顧客起点で生成 AI ユースケースを創出し、プロトタイプ開発まで行うコンテスト形式のイベントです。 前回 に続く2回目の開催となる今年は、創出したユースケースを AI コーディングエージェント「Kiro」でプロトタイピングし、アイデアを「動くもの」に変えるところまでを2日間で一気通貫に体験するという新たな挑戦を加えました。金融領域の13社12チーム（47名）の皆様にご参加いただき、活発な議論と創造的なアイデア創出、プロトタイプ開発、そして各社それぞれの工夫を凝らした内容で熱のこもった発表が行われました。本記事では、企画の背景から当日の様子、参加者の声までをお届けします。 前回開催からの進化 — アイデア創出から「動くプロトタイプ」へ 昨年7月の「AWS GenAI Catapult! 」は、Working Backwards によるアイデア創出を中心とし、プロトタイプの提示は任意（加点要素）、発表は初日から約3週間後に別日を設けて実施する形式でした。今年は昨今の生成 AI の進化に伴い次の3点を大きくアップデートして、「考える」から「作る」まで地続きで体験できるようにしたことが、今年最大の特徴です。 連続2日間で完結：学び・アイデア創出・開発・発表までを途切れさせずに2日間でやり切る構成に変更 Kiro によるプロトタイプ開発を本格導入：アイデアを構想で終わらせず、その場で動くアプリケーションとして形に 発表は「動くデモ」付き：プレスリリースに加えてプロトタイプのデモを披露 企画の背景 日本企業の生成 AI 活用の現状 — AI活用の方針は前進、しかし「使いこなし」はこれから 総務省の 令和7年版 情報通信白書 によると、日本企業で生成 AI の活用方針を「定めている」とした比率は 49.7% （前回の調査の 42.7% から増加）と着実に前進しました。一方で、調査した他国と比較すると依然として低い水準にとどまっています。実際の利用面でも、何らかの業務で生成 AI を利用している企業は日本で 55.2% 、「メールや議事録、資料作成等の補助」での利用は 47.3% と、いずれも他国より低い割合でした。導入に際しての懸念事項として日本企業が最も多く挙げたのは「 効果的な活用方法がわからない 」で、次いで社内情報の漏えい等のセキュリティリスク、ランニングコスト、初期コストが続きます。生成 AI を「どう自分たちの価値創出につなげるか」という具体的な適用イメージを描けていないことが、依然として大きな壁になっていると考えられます。 「業務効率化」の先へ — 顧客起点のイノベーションという課題 同白書では、生成 AI 活用による自社への影響について、日本企業は「 業務効率化や人員不足の解消につながる 」を最も多く挙げました。これに対し、米国・ドイツ・中国の3か国では「ビジネスの拡大」「新たな顧客獲得」「新たなイノベーション」を多く挙げる傾向が見られます。つまり日本では、生成 AI が業務効率化の手段にとどまりがちで、新たな顧客価値の創造へと踏み込めていない構図がうかがえます。金融業界でも、技術起点のアプローチに偏り、顧客価値創出に課題を抱えるケースは少なくありません。 「AWS GenAI Catapult! 」は、まさにこの「業務効率化の先」へ一歩踏み出すための場です。顧客起点でユースケースを発想し、その価値をその場で検証する体験を通じて、生成 AI 活用を効率化からイノベーション創出へと引き上げることを狙いました。 Amazon 流・顧客起点のイノベーション創出メカニズム「Working Backwards」 Amazon が実践してきたイノベーション創出のメカニズム「Working Backwards」手法 は、Amazon Echo、Amazon Prime、AWS などのサービス開発に活用されてきたアプローチです。顧客の理想的な体験から逆算してサービスを設計することで、顧客が本当に求める価値に焦点を当てた開発を可能にします。具体的には、企画段階から顧客体験をプレスリリースという形に詰め込むことで実現します。「Working Backwards」は知識として学ぶだけでは習得できません。実際にプレスリリースを書き、発表しフィードバックを受ける体験を通して、はじめて身につきます。 コーディングエージェントの進化が、「作る」のハードルを下げた 今年プロトタイプ開発まで踏み込んだ最大の理由が、AI コーディングエージェントの急速な進化です。 Kiro に代表されるコーディングエージェントは、自然言語の対話から要件定義・設計・実装・テストまでを支援できるまでに進化し、エンジニアでなくとも、アイデアを短時間で「動くもの」に落とし込めるようになりました。 これにより、「顧客起点で何を作るべきかを考える力（Working Backwards）」と「それを素早く形にする力（AIコーディングエージェント Kiro）」が地続きになり、アイデアの価値を構想で終わらせず、その場で動かして検証できるようになりました。昨年はアイデア創出が中心でプロトタイプ開発は任意でしたが、こうした技術の進化を背景に、今年は「考える」から「作る」までをやり切る2日間へと踏み切りました。 イベント概要 項目 内容 開催日時 2026年6月11日（木）、12日（金） 会場 AWS 麻布台オフィス（麻布台ヒルズ 森JPタワー） 参加者数 47名 参加企業 金融関連企業 13社（12チーム） AWS GenAI Catapult! とは 「AWS GenAI Catapult!」は、顧客起点での生成 AI ユースケースを創出し、世に送り出すための発射台（カタパルト）としての位置づけで、その意図をイベント名の「Catapult」に込めています。生成 AI の学習・スキル習得に留まらず、ユーザーの課題や体験に焦点を当て、Amazon 流のイノベーション文化を理解し、「Working Backwards」手法による実践的なユースケース創出につなげることを目指しています。今年はさらに、創出したユースケースを Kiro でプロトタイピングし、動くアプリケーションとして発表するところまでを2日間で体験いただきました。企業横断の交流セッション「World Café」も実施し、参加者同士の学びの共有とネットワーキングの機会も提供しました。 イベント開催報告 参加企業・チーム 金融領域の事業会社・サービサーなど 13社にご参加いただき、12チームを編成して臨みました。各社が個性豊かなチーム名で参加しています。 チーム名 会社名 Masult 株式会社アイフィスジャパン 麴町 Squad 株式会社オリエントコーポレーション TQQQ 株式会社QUICK 東池袋 4+1 株式会社クレディセゾン やる KIRO 満々 株式会社ジェーシービー しんぷれこ シンプレクス株式会社 NEXT BAMBOO 株式会社セゾンテクノロジー えぇアイをつくる会 CHEER証券株式会社 TMN Sei-katsu-sha AI Lab 株式会社トランザクション・メディア・ネットワークス AIに任せ隊 株式会社Finatext / 株式会社ナウキャスト P:AI プレミアグループ株式会社 ほか、1社 AWS GenAI Catapult! 1日目 Amazon Culture of Innovation Session / Working Backwards Experience Workshop 1日目は、Amazon のイノベーションを支えるカルチャーとテクノロジーの紹介から始まりました。Amazon は「地球上で最もお客様を大切にする企業であること」を使命とし、徹底したお客様志向、あくなき挑戦、辛抱強さを基本理念としています。お客様から逆算して考える「Working Backwards」というメカニズム、「Every day is still Day One」という心構え、小さく権限委譲された「Two-pizza チーム」という組織構造、そして変化に対応できるアーキテクチャが、イノベーションを生み出す源泉であることが説明されました。失敗を恐れず Builder 精神を持った社員が、顧客中心主義に基づいて新しい顧客体験を創造している——その文化が共有されました。 Working Backwards 体験ワークショップでは、参加者は各社チームに分かれ、生成 AI を活用したユースケースの創出に取り組みました。「Customer Obsession（お客様へのこだわり）」「Think Big（広い視野で考える）」「Bias for Action（行動へのこだわり）」というリーダーシッププリンシプルに基づき、まず「お客様は誰か」を特定し、課題を明確化。続いて課題を解決するソリューションとその目玉機能を考案し、最終的にプレスリリース形式でアイデアをまとめます。完成したプレスリリースは他チームに発表し、建設的なフィードバックを受けることで、アイデアをさらに洗練させていきました。 参加者からは「要件定義ではなく“体験定義”をするという観点が非常に勉強になった」「プレスリリースから物事を考えること自体が新鮮だった」という声が多く聞かれました。 AWS GenAI Service Introduction / AWS Dojo Hands-on [ Kiro ] 続いて、AWS Session で AWS の生成 AI サービスの全体像を学び、続くAWS Dojo Session ではいよいよ AI コーディングエージェント Kiro のハンズオンに取り組みました。AWS のワークショップ「Kiroで学ぶ：AI駆動開発」を教材に、まず講師が Vibe モード（AI と会話しながら探索的に実装を進める使い方）をデモで実演。続いて参加者自身が Spec モード（仕様駆動開発）を実践し、要件を Kiro の Spec に落とし込み、そこから自動生成される設計ドキュメントを確認しました。Vibe（素早く作る）と Spec（要件→設計→タスクに構造化する）の両方をここで体験することで、翌日のプロトタイプ開発で両者を使い分けるための確かな助走となりました。 AWS GenAI Catapult! 2日目 Prototyping Workshop with Kiro 今年最大の挑戦が、AI コーディングエージェント Kiro を用いたプロトタイプ開発です。Working Backwards で描いた顧客体験を、構想で終わらせずに「動くもの」へと変えていきます。Kiro は、次の３つの機能をうまく活用頂くことで効率良く開発を進めていくことができます。 Spec（仕様）：自然言語の対話から、要件定義・設計ドキュメント・実装タスクを構造化 Steering（制約）：Steering ファイルで規約やアーキテクチャ制約を AI に教え、チームの意図に沿った実装へ誘導 Coding（実装）：タスクリストに沿って AI が実装。必要に応じて Vibe コーディングで素早く形にする 開発をスムーズに始められるよう、運営からは Working Backwards やアプリ雛形の生成などのスキルと、規約・アーキテクチャ制約を定義したステアリングを同梱した「スターターキット」を配布しました。各チームはまず Day1 で作った PR/FAQ を Spec に落とし込み、アプリの雛形を生成。生成 AI 部分はモックと実モデルを切り替えられる構成（Mock/Real 切替）にしておくことで、ネットワークやモデルに左右されずデモのシナリオを安定させる工夫も共有されました。実装は「頼む → 動かす → 確認する → 次へ」という小さなループ（黄金ループ）を回し、迷子にならずに少しずつ完成へ近づけていきます。 「雑な自然言語からでも仕様書やモックを作成してくれる」「開発未経験でもここまで作れるのかと驚いた」「要件定義からテストまで1〜2時間で実行できた」——短時間で完成度の高い成果物が生まれていく様子と、会場のあちこちで驚きの声を聞くことができました。 参加チーム プレスリリース発表 & デモ & QA 2日目午後、いよいよ発表の時。今年は プレスリリースに加えて、Kiro で作り上げた動くプロトタイプのデモ を披露するスタイルです。12チームを4チーム×3ブロックに分けて予選を行い、各ブロックの1位が決勝に進出するトーナメント形式で実施しました。各チームが顧客課題に深く向き合い、生成 AI ならではの新しい顧客体験を提案。単なる業務効率化に留まらず、顧客体験を根本から再定義するような大胆な提案が並び、Q&A では他チームの提案を積極的に理解しようとする姿が印象的で、会場は熱気に包まれました。 AWS World Café [AI 活用推進] 生成 AI 活用をテーマにした参加者交流セッション「World Café」を開催しました。少人数グループで「ホスト」と「旅人」の役割を交代しながらメンバーの組み合わせを変え、対話を深めていく独自の形式です。結論や合意形成を目的とせず、多様な意見の共有と相互理解の深化を重視。「同じ課題に直面していることがわかって安心した」「他業種の取り組みが参考になった」など、業界や立場を超えた対話から多くの共感と気づきが生まれました。 Networking Party & Awards Ceremony *表彰式 セッション終了後、会場は和やかなネットワーキングパーティーへ。参加者は2日間の学びを共有し合い、企業の垣根を越えた新たな繋がりが次々と生まれました。表彰式では、AI審査員を加えた5名による厳正な審査の結果、以下の3チームがAWS Awardsを受賞しました。 優勝：TMN Sei-katsu-sha AI Lab ( 株式会社トランザクション・メディア・ネットワークス ) 準優勝：P:AI （ プレミアグループ株式会社） 3位：TQQQ （ 株式会社QUICK ） さらに、プレスリリースの完成度を称える特別賞「Kiro賞」を、しんぷれこ（シンプレクス株式会社）／AIに任せ隊（株式会社Finatext・株式会社ナウキャスト）／やる KIRO 満々（株式会社ジェーシービー） の3チームが受賞しました。受賞チームには記念トロフィー・メダルと AWS クレジットが贈られ、参加者全員にも AWS オリジナルグッズが配布されました。会場は受賞チームへの祝福と拍手に包まれ、和やかな雰囲気の中で締めくくられました。 参加者の声 本イベントの参加者アンケート（回答47件）では、総合満足度（CSAT） 4.8 / 5.0 と昨年（CSAT 4.6）を上回る非常に高い評価をいただきました。また、Working Backwards × 生成 AI によるサービス創出プロセスの有用性も 4.76 / 5.0、今後も Kiro を業務で使いたい と回答した方は約94%にのぼりました。参加者からは、次のような声が寄せられました。 「要件定義ではなく“体験定義”をするという観点が非常に勉強になった」 「雑な自然言語からでも仕様書やモックを作ってくれるのがすごくよい」 「開発をしたことがない人間でも、ここまで作れるのかと興奮した」 「他社の AI 活用のリアルな実情やアイデアを聞ける、貴重な交流の場だった」 「‘それは私たちの仕事ではありません、と言わない’を自分の信条にしたい」 運営の工夫 — イベント運営そのものも生成 AI と 今年は、イベントの「中身」だけでなく「運営」にも AI コーディングエージェントを活用しました。参加者に Kiro での開発を勧める私たち運営自身が、その Kiro を使って運営の仕組みを作り上げる——これもまた、今年のイベント開催における裏テーマでした。 イベントポータルサイトの開発 当日の参加者体験を一元化するため、専用の イベントポータルサイト を内製しました。参加者はこのポータルから、当日のアジェンダ・各セッションのガイド、開発チートシート、FAQ／トラブルシューティングを確認でき、完成した成果物（PR/FAQ・発表スライド・プロトタイプ・デモ動画）をカテゴリ別にアップロードできます。 技術構成はフロントエンドに React + Vite + TypeScript、バックエンドに AWS Amplify Gen2（認証は Amazon Cognito、ストレージは Amazon S3、ホスティングは Amplify Hosting）を採用。チーム単位のアカウントを運営が事前発行し、各チームの成果物は S3 上で IAM により相互に隔離（他チームからは参照不可、運営のみ横断アクセス可）しました。参加者が金融機関であることを踏まえ、全ページ認証必須・S3 のパブリックアクセス全ブロックと暗号化・成果物の一定期間後の自動失効といった、セキュリティとデータ保護の作り込みも行っています。 アプリ開発用スターターキットの準備と配布 コーディングエージェントを初めて使う参加者でも、半日で動くアプリを作り切れるように、運営が事前に「スターターキット」を配布しました。0 から作るのではなく、これを起点に開発できるようにする狙いです。 キットには、Working Backwards の PR/FAQ・ストーリーボードの生成、発表資料づくり、コーディングエージェントの「運転ガイド」、Spec / Vibe の使い分け、生成 AI アプリの雛形生成、HTML スライド作成といった用途別の スキル群 と、毎回守ってほしい制約を定義した ステアリング（共通ガードレール）、そして開発中に手元で見る 1 ページの早見表やトラブルシュートを同梱しました。これにより、初心者がつまずきやすい「曖昧に大きく頼んで迷子になる」「動作確認せずに進む」「生成 AI 連携部分を自力で組めない」「Spec を巨大にして破綻する」といった落とし穴を、あらかじめ吸収できるよう設計しています。 Kiro と AI 駆動型開発 特筆すべきは、ポータルサイトもスターターキットも、コーディングエージェント Kiro を使って開発したことです。とりわけポータルサイトは、Kiro の Spec モード（仕様駆動開発） を用い、要件定義（requirements）→ 設計（design）→ タスク分解（tasks）という流れで開発しました。これはまさに、当日参加者に体験いただいた開発プロセスそのものです。 「考える」から「作る」までを生成 AI で地続きにする——その手応えを、運営は準備段階から自ら検証していました。参加者に届けた体験は、私たち自身が有効性を確かめたうえでお渡ししたもの、と言えます。 まとめ 「AWS GenAI Catapult! 」は、単なる技術セミナーではなく、顧客起点でのイノベーション創出プロセスを学び、実践する場です。今年は Working Backwards による「考える」体験に、Kiro による「作る」体験を加え、アイデアを2日間で動くプロトタイプにまで昇華させる挑戦を行いました。生成 AI という革新的技術を真に価値あるものにするためには、技術の可能性を理解しつつ、常に顧客価値を中心に据えたアプローチが不可欠です。そして今、その顧客価値を「素早く形にして検証する」ことが、誰の手にも届く時代になりました。参加者の皆様がこの本質を体感し、自社での実践に活かしていただけることを心から願っています。 最後に、2日間にわたり熱心にご参加いただいた皆様、そして革新的なアイデアとプロトタイプを生み出してくださった各チームの皆様に、心より感謝申し上げます。皆様の挑戦が、日本の生成 AI 活用を加速し、新たな顧客価値の創造へとつながることを確信しています。AWS では今後もお客様のイノベーション創出を支援するプログラムを継続的に提供してまいります。