みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。4 月は新年度のスタートということで、新入社員として新たにクラウドや生成 AI の世界に飛び込まれた方も多いと思います。そうしたみなさんが最新のトレンドや実践的な活用例をキャッチアップする一助として、このブログを日々の情報収集や学習に役立てていただければ幸いです。日本のお客様向けに、生成 AI の実用化を支援する各種プログラムや事例も増えてきており、「どのように始めるか」だけでなく「どうスケールさせるか」「どう安全に運用するか」といった観点でのベストプラクティスも見え始めています。新しくご入社された方も、すでにクラウドに取り組まれている方も、ぜひご自身のプロジェクトやキャリアの文脈に引き寄せながら読んでいただければと思います。 それでは 3月 30 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「 大成株式会社様の AWS 生成 AI 活用事例「Amazon Bedrock と Amazon Q Developer で非エンジニアが実現する契約書管理 AI エージェントの構築」のご紹介 」 ファシリティマネジメントや不動産投資事業を展開する大成株式会社様が、社内にエンジニアを擁さない状況の中、Amazon Bedrock と Amazon Q Developer を活用して契約書管理 AI エージェントを構築した事例です。非エンジニアのプロジェクトマネージャーが中心となり、Amazon Q Developer の自然言語によるコード生成支援と Amazon Bedrock 上の Claude による高度な PDF 文書解析を組み合わせることで、従来数十分かかっていた契約書からの情報抽出を数分に短縮（作業時間を約 70〜80% 削減）することに成功しました。「社内にエンジニアがいない」「開発リソースが限られている」という企業が抱えがちな課題に対して、業務を最もよく知る現場の担当者自身が AWS の生成 AI サービスを組み合わせて実用的なシステムを作り上げたこの事例は、スモールスタートで業務改善の成果を出すアプローチとして参考になります。 ブログ記事「 Agentic AIの運用化 Part 1: ステークホルダー向けのガイド 」 AWS Generative AI Innovation Center（GenAIIC）が 1,000 社以上の AI 本番移行支援から得た知見をもとに、Agentic AI を実業務に定着させるためのフレームワークを解説した記事です。多くの企業が AI パイロットを立ち上げながら実運用に至らない根本原因は「テクノロジーのギャップ」ではなく「オペレーティングモデルの欠如」にあるとし、成功している組織に共通する「仕事の詳細定義」「エージェントの自律性の境界設定」「継続的な改善の習慣化」という 3 つの要素を示しています。エージェント化に適した業務の見極め方（明確な開始・終了・目的、複数ツールを横断した判断、成功の測定可能性、安全な失敗モード）も具体的に説明されており、経営陣からビジネスオーナーまで幅広いステークホルダーが今日から取れるアクションをすぐに実践できる内容で、Agentic AI を活用している・これから活用を検討しているすべてのユーザーにとって、PoC 止まりを防ぎ本番稼働へと踏み出すための実践的な道標となる一記事です。 ブログ記事「 Agentic AIの運用化 Part 2: ペルソナ別のガイダンス 」 Part 1 で示した「Agentic AI の障壁はテクノロジーではなくオペレーティングモデルにある」という知見を受けて、AWS Generative AI Innovation Center（GenAIIC）が事業部門オーナー・CTO・CISO・CDO・Chief AI Officer・コンプライアンス責任者それぞれの役割に応じた実践的なガイダンスを提示しています。事業部門オーナーにはエージェントを KPI に直結させるジョブディスクリプション作成、CTO にはスケーラブルなエージェント基盤設計、CISO にはエージェントを「同僚」として扱うアイデンティティとポリシー管理、CDO にはデータの一貫性とガバナンス整備、Chief AI Officer には評価システムこそが真のプロダクトであるという考え方、コンプライアンス責任者には監査を想定した設計など、それぞれの責任に即した具体的なアクションが示されており、Agentic AI を「実験」から「本番稼働」へと引き上げるために誰が何をすべきかを職責ごとに明確に整理した内容は、生成 AI 活用を組織全体で推進しようとしているあらゆるステークホルダーにとって、今すぐ行動に移せる実用的なロードマップになっています。 ブログ記事「 AWS DevOps Agent の一般提供開始のお知らせ 」 AWS やオンプレミス環境を横断してインシデントの自律的な調査・解決・予防を行う AI エージェント「AWS DevOps Agent」が一般提供（GA）を開始し、東京リージョンを含む世界 6 リージョンで利用できるようになりました。GA にあわせて、Triage Agent による重複インシデントの自動検出、コードリポジトリのインデックスを活用したコードレベルの根本原因特定、PagerDuty・Grafana・Azure DevOps などの新規インテグレーション、プライベート接続やカスタマーマネージドキーによるエンタープライズ対応機能、そしてブラウザのロケール設定に応じてエージェントの応答を日本語を含む各言語に翻訳するローカライゼーション機能も追加されています。 ブログ記事「 「Physical AI on AWS 勉強会 #1」を開催しました 」 AWS ジャパンが「フィジカル AI 開発支援プログラム」の採択企業向けに開催した勉強会 の内容をまとめた記事で、ロボットなどの物理世界で動く AI（Physical AI）を AWS 上で開発するためのリファレンスアーキテクチャと、すぐに使えるサンプルコード集「Physical AI Scaffolding Kit（PASK）」が紹介されています。シミュレータでの合成データ生成から Amazon SageMaker HyperPod による分散学習、AWS IoT Greengrass を活用したエッジへのモデル配信までの一気通貫な開発サイクルを AWS 上で構築する方法が具体的に解説されており、ロボティクスや自動化システムの開発に取り組む企業・エンジニアにとって、Physical AI 開発の全体像と AWS 活用の実践的な出発点を得られる内容です。また、VLA（Vision-Language-Action）モデルという新しい AI アーキテクチャへの理解を深めたい生成 AI ユーザーにとっても、言語・視覚・行動を統合したモデルが実際にどのようなインフラで学習・運用されるのかを把握できる参考事例となっています。 ブログ記事「 Amazon OpenSearch Service のエージェント AI でオブザーバビリティとトラブルシューティングを効率化 」 Amazon OpenSearch Service の OpenSearch UI に、オブザーバビリティとトラブルシューティングを大幅に効率化する 3 つのエージェント AI 機能（エージェントチャットボット・調査エージェント・エージェントメモリ）が組み込まれました。エージェントチャットボットは現在表示中のコンテキストを理解して自然言語でクエリを自動生成し、調査エージェントは複数のインデックスをまたぐシグナルを plan-execute-reflect 方式で自律的に相関分析して仮説駆動型の根本原因レポートを生成します。複雑なログ分析に多大な時間を費やしてきた運用チームにとってアラートから根本原因の特定までを短時間で到達できるようになります。 ブログ記事「 Kiro のエンタープライズガバナンス: MCP サーバーとモデルを管理する 」 AI コーディング IDE「Kiro」に 2 つの新しいエンタープライズガバナンス機能が追加されました。管理者が承認済み MCP サーバーを JSON 形式のレジストリでホワイトリスト管理できる「MCP サーバーレジストリ」と、組織内の開発者が利用できる AI モデルを制限できる「モデルガバナンス」です。MCP レジストリは起動時・24 時間ごとに同期され、未承認サーバーへの接続を防止します。モデルガバナンスはデータレジデンシー要件への対応にも有効で、実験的モデルを承認完了まで無効化できます。これらの機能は Kiro IDE 0.11.28 / CLI 1.23 以降のエンタープライズユーザー向けに提供されます。 ブログ記事「 MiniMax M2.5 と GLM-5 が Kiro に追加 」 AI コーディング IDE「Kiro」に、新たにオープンウェイトモデルの MiniMax M2.5 と GLM-5 が追加され、Kiro IDE および Kiro CLI から利用できるようになりました。MiniMax M2.5 はクレジット消費が 0.25 倍という低コストながら SWE-Bench Verified で 80.2% を達成（オープンウェイトモデルとして初めて Claude Sonnet を超えた性能）した高速なモデルで、複数ステップのエージェントタスクや繰り返しの実装作業に強みを持ちます。米国東部（バージニア北部）と欧州（フランクフルト）リージョンで利用可能です。GLM-5 は 200K のコンテキストウィンドウを持つ大規模 MoE モデルでリポジトリ規模の長期的なエージェントワークフローに最適化されています。こちらは米国東部（バージニア北部）リージョンで利用可能です。 サービスアップデート Amazon Bedrock AgentCore Evaluations が一般提供を開始 AI エージェントの品質を自動評価する「Amazon Bedrock AgentCore Evaluations」が一般提供（GA）を開始し、アジアパシフィック（東京）を含む 9 リージョンで利用できるようになりました。本番トラフィックをサンプリングしてリアルタイムにスコアリングするオンライン評価と、CI/CD パイプラインや開発ワークフローに組み込めるオンデマンド評価の 2 種類を提供しており、応答品質・安全性・タスク完了率・ツール使用状況をチェックする 13 種類の組み込み評価器に加え、期待値との比較（Ground Truth）や Python・JavaScript による完全カスタム評価ロジックにも対応しています。AI エージェントを本番稼働させているユーザーにとっては品質劣化をいち早く検知できる仕組みが整い、生成 AI を活用しているエンジニアにとっても AgentCore Observability との統合によって評価・監視を一元管理できるようになる点は、Agentic AI を信頼性高く運用していく上で欠かせないアップデートです。 Amazon Bedrock Guardrails がクロスアカウントセーフガードの一般提供を開始 Amazon Bedrock Guardrails に、組織内のすべての AWS アカウントにセーフガードを一元適用できる「クロスアカウントセーフガード」が一般提供（GA）となりました。管理アカウントで設定したガードレール ID を Amazon Bedrock ポリシーに指定するだけで、組織内のすべてのメンバーアカウントや組織単位（OU）に対するすべての基盤モデル呼び出しに自動的にコントロールが適用されるため、アカウントごとに個別設定する運用負荷を削減できます。 Amazon OpenSearch Service がログ分析向けエージェント AI 機能を提供開始 Amazon OpenSearch Service に、エンジニアリングチームや運用チームが自然言語でログデータを分析できるエージェント AI 機能が追加され、東京 を含む 9 リージョンで追加費用なし（トークン使用量の制限あり）で利用できるようになりました。自然言語で質問して PPL クエリを自動生成・修正する「エージェントチャット」、根本原因を自律的に仮説立案・検証・ランク付けして報告する「調査エージェント」、セッションをまたいで会話を継続できる「エージェントメモリ」の 3 機能が提供されており、複雑なクエリ言語を書かなくてもインシデント調査を効率化することができます。 Amazon S3 Vectors が 17 の追加リージョンに拡張 クラウドオブジェクトストレージとして初めてベクトルのネイティブな保存・クエリをサポートする「Amazon S3 Vectors」が、大阪 を含む17のリージョンに拡張され、合計 31 リージョンで利用可能になりました。1 つのベクトルインデックスに最大 20 億ベクトルを保存でき、インフラのプロビジョニング不要で最大 1 万のベクトルインデックスに弾力的にスケール、頻繁なクエリでは 100 ミリ秒という低レイテンシも実現します。Amazon Bedrock Knowledge Bases とネイティブ統合されているため、RAG（検索拡張生成）やセマンティック検索に大規模なベクトルデータを低コストで活用したい生成 AI ユーザーにとっては、今回の拡張でデータレジデンシー要件を満たしながらより身近なリージョンで運用できるようになった点が嬉しいアップデートです。 GLM-5 が Kiro に追加 Kiro に、200K のコンテキストウィンドウを持つ大規模 MoE（Mixture of Experts）モデル「GLM-5」のサポートが追加され、Kiro IDE および Kiro CLI からエクスペリメンタルサポートとして利用できるようになりました。GLM-5 はリポジトリ規模の大量コンテキストを処理しながら複数ステップのツール利用にわたって一貫性を維持することに長けており、クロスファイルマイグレーション・フルスタック機能開発・レガシーコードのリファクタリングといった「全体像をモデルに把握させながら進める」複雑な作業に適しています。推論は米国東部（バージニア北部）リージョンで実行され、クレジット消費は 0.5 倍で、モデルセレクターから利用するには IDE または CLI の再起動が必要です。長いコンテキストを扱う生成 AI ユーザーにとっては、大規模コードベースを丸ごと扱う用途で Claude 系モデルとの使い分けを検討できる新たな選択肢が加わったことになります。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近天ぷらを(食べるのではなく)揚げるほうにハマってます。

はじめに タイミー QA Enabling Gの矢尻、岸、松田です。 ソフトウェアテストに関する国内最大級のカンファレンス「JaSST (Japan Symposium on Software Testing) ‘26 Tokyo」が、2026年03月20日に開催されました。 タイミーには、世界中で開催されるすべての技術カンファレンスに参加できる「KaigiPass」という制度があり、この制度を利用してオフラインで参加しました。 jasst.jp 今年の会場は東京ビッグサイトでした。 本レポートでは、印象に残ったセッションの内容を中心にお伝えします。 JaSST Tokyo 2026 参加レポート — AI駆動QA時代の到来とタイミーの現在地 タイミーの矢尻です。 今回のJaSSTは、前回にもから増して AI関連セッションが圧倒的に多い 回でした。基調講演からクロージングまで、ほぼすべてのトラックでAIが議論の軸となり、AI駆動開発における品質保証（QA for AI-Driven Development = QA4AIDD）が業界全体のメインテーマに昇格した印象です。 タイミーでは社内のQAガイドライン「QA Handbook」を通じてAI時代のQA戦略を先行して整備してきました。本レポートでは、セッション横断で見えた 3つの業界トレンド と、タイミーの取り組みとのフィットギャップを総論的にまとめます。 セッション横断で見えた3つのトレンド 今回、私が視聴したのは以下の6セッションです。 AIがテストチームに加わるとき- 期待、落とし穴、そしてソフトウェア品質の未来 – スペシャルトークセッション『AIと品質保証のこれまでとこれから』 AIがQAエンジニアの仕事を奪うのか？ 生成AI時代、ソフトウェア品質保証のロールと組織はどこへ向かうのか？ 品質を経営にどう語るか 人と関わるロボットの研究開発 –ロボットにおける人間らしさの重要性 – 横断すると、業界の議論は大きく 3つのテーマ に収束していました。 1. AIへの「プロセス要求」と人間の監督 複数セッションで共通して語られたのは、 AIに「何を作るか」だけでなく「どう作るか」を明示する 必要性です。 ベリサーブ様のセッションでは「ハーネスエンジニアリング」として、AIにプロセス要求を与えアクティビティログでオーディットするアプローチが紹介されました。SIG SQAの井芹様は「HITL（Human-in-the-Loop）」と「Everything as Code」をキーワードに、人が適切なポイントで介在するプロセス設計の重要性を強調。安野様のセッションでは、AIが一次スクリーニング（リコール向上）を担い、人間がコンテキストを踏まえた精査（プレシジョン向上）を行う「 2層スクリーニング 」モデルが示されました。 基調講演のGayathri Mohan様も、AIは「ベビーシッター」のように常に監視と調整が必要な存在であると指摘しており、 「AIに任せきりにしない品質保証のプロセス設計」が業界の最大関心事 になっていることを強く感じました。 2. リリース後の継続的品質バリデーション もう一つ、独立した複数セッションで繰り返し言及されたのが、 プロダクション環境での継続的モニタリング です。 ベリサーブ様のセッションでは「フライホイール型品質保証」として、リリース前で完結せず本番環境で継続的にスコアを監視→フィードバック→再リリースを回す「運用型QA」が提唱されました。Adobe様の小島様もAIエージェント評価において、事前テストだけでは限界があり実データでの課題探索が不可欠だと強調。基調講演でも、非決定論的なAIの出力に対して確率論的・メトリクスベースの評価が必要だと語られました。 リリース後の品質バリデーションは、もはや「やるかどうか」ではなく 「いつ・どう始めるか」のフェーズ に入っていると感じます。 3. 品質を経営の言葉で語る 3つ目のトレンドは、 品質と経営の対話 です。 kyon_mm様らのセッションでは、品質を「技術の詳細を説明する場」から「事業の優先順位を決める場」に移すための翻訳プロトコルとして、 バランススコアカード（BSC） 、 Cost of Quality（COQ） 、 NIST AIリスクマネジメントフレームワーク の3つが示されました。ベリサーブ様のセッションでも「QAエンジニアは経営の意思決定に必要な情報を提供する立場に移行する」という見通しが語られ、SIG SQAの伊藤様も「事業戦略と連携した品質戦略策定」を高度化すべきスキルとして挙げていました。 作業をAIに委ね、 QAエンジニアの役割がより上流・経営（ビジネス）寄りにシフトしていく という方向性は、セッションを跨いだ一貫したメッセージでした。 タイミーQA Handbookとのフィットギャップ タイミーでは「QA Handbook」として、 3つの戦略 （Business Reliability / Standardized Process / AI-DLC & QaC）を柱にQA活動を体系化しています。上記の業界トレンドと照合した結果を整理します。 ✅ フィットしている領域 業界潮流 タイミーの対応 評価 Everything as Code / AIフレンドリーな成果物 Gherkin/Markdownでの仕様標準化＋教師データ蓄積 先行 HITL型プロセス設計 Generative Testing Pipeline（Human=意思決定、AI=実装） 先行 プロセス要求＋オーディット DoR/AC/DoD＋壁打ちリファインメント 同期 AI×人間の分業テスト設計 テスト仕様書生成（AI一次生成→人間レビュー） 同期 リスクベースドテスト ISTQB準拠のRPN分析を体系的に整備済み 先行 ⚠️ ギャップがある領域 業界潮流 現状と推奨アクション 優先度 リリース後の継続的品質バリデーション 構想済みだが未着手。CUJベースの指標でスモールスタートすべき 高 品質活動のビジネス価値換算（BSC / COQ） エラーバジェット概念をCOQ文脈で再定義するアプローチが有効 高 AIエージェント評価の体系化 4テスト種類×二軸評価指標を自社AI評価に応用可能 中 非決定論的テストへの対応 パイプラインに統計的評価レイヤーの追加設計が必要 中 まとめ JaSST Tokyo 2026を通じて確信したのは、 タイミーのQA Handbookが掲げる方向性は業界潮流と高い整合性を持っている ということです。Everything as Codeによる教師データ蓄積、HITL型のプロセス設計、リスクベースドテストの体系化は、業界が「これからやるべき」と議論しているものを先行して体系化できています。 一方、 最大のギャップは「リリース後の継続的品質バリデーション」と「品質活動のビジネス価値換算」 の2点。いずれも複数セッションで繰り返し言及され、業界コンセンサスが形成されつつあるテーマです。 今回のJaSSTは、AI駆動開発が「一部の先進企業の取り組み」から「業界標準の議論テーマ」に移行したことを実感する場でした。先行して整備してきた資産を活かしつつ、ギャップの解消に取り組むことで、QA4AIDDの実践をさらに一歩進めていきます。 開発チームとの協業とトレーサビリティ基盤 タイミーの岸です。私からは印象に残った二つのセッションの紹介と感想をお届けします。 開発チームとQAエンジニアの新しい協業モデル：年末調整開発チームで実践する [QAリード施策] / SmartHR speakerdeck.com SmartHRの平澤さん・依田さんによる、開発エンジニアとQAエンジニアとの協業の取り組みについての講演でした。 開発チームによる自律的なQAを支援する施策であり、QAエンジニアが開発チームに入り込んで、最初はQAについて支援しつつ最終的にはチームから抜けていくというものです。 特徴的なのは、チームに参加するQAエンジニア以外に、チーム内からもQAを推進するメンバーを立てるという点でした。このメンバーは「QAリード」と呼ばれ、QAエンジニアとの1on1やチーム内での旗振り、テスト技法の勉強会などを通してQAプラクティスを根付かせていきます。QAリードの役割は目標設定にもきちんと反映されていくとのことでした。人選は指名ではなくチームからの立候補を基本とする形とのことで、SmartHRの開発チームにおける品質意識の高さがうかがえました。 こういったチームの自律性支援はタイミーでも実践の真っ最中です。QAリードの役割やQAエンジニアからの推進の方法など、私たちにとっても参考になる点が多く、とても興味深く聴かせていただきました。 仕様漏れ実装漏れをなくすトレーサビリティAI基盤のご紹介 / コインチェック speakerdeck.com コインチェックの国分さんによる、ドキュメント間のトレーサビリティとそれを検査する基盤についての講演でした。 ドキュメント間には関連性があります。例えば、要求からは仕様が派生し、仕様からは設計、設計からは実装が、また設計からはテストケースも派生します。このため、派生元と派生先は矢印で結ぶことでグラフとして表現できます。ここで、矢印の片方にドキュメントが存在しなかった場合は「アノマリー」となり、何かがおかしいことがわかります。派生先が存在しなければ、実装やテストが漏れている可能性があり、派生元が存在しなければ不必要な成果物が作成されている可能性があるということです。そして、コインチェックではこのグラフを検証するシステムをAIを活用して作っているとのことでした。 AI基盤については、可能な限り人手を抑えつつ、偽陽性・偽陰性を抑えるためのチューニングが行われていました。一方でAIを並列して稼働させるためには何よりも金銭コストがかかり、これを抑えるために敢えて軽量なモデルを使用するなど苦慮されている様子でした。 タイミーにおいては、ドキュメントを作成するかどうかチームによるバラツキがあります。そのためこういった検証基盤については、同じものを作っても定着するかどうかは未知数です。とはいえ、複雑化している仕様をどのように管理していくかは私たちにとっても大きな課題です。こういった取り組みを参考にしつつ、自分たちにマッチする仕組みを開発していくことは重要であると感じました。 要求・暗黙知・越境から見る AI 時代の QA タイミーの松田です。 昨年はタイミーとして登壇する側でしたが、今回は一参加者として様々なセッションに参加し多くの学びを得ることができました。 今回の JaSST Tokyo では AI と QA に関するトピックが多く、参加したセッションにはそれぞれ共通するテーマがあると感じました。私はその共通項を 3つ に整理しました。 要求エンジニアリング — QA の基礎能力としての重要性 暗黙知 — AI への適切なコンテキスト提供 越境 — エンジニアリングと QA の役割の進化 本レポートでは、それぞれの学びについてまとめます。 1. 要求工学(エンジニアリング )— QA の基礎能力としての重要性 こちらは、freeeの苅田さん・栗田さんが発表された「曖昧な要求は仕様かバグか-―ai時代の仕様とテストを考える」の発表から得た学びです。 ここでは 「要求工学(エンジニアリング)」 に関しての発表を軸に話が進みました。 カンファレンスでは要求工学に関する発表があり、その重要性が改めて強調されました。 プロダクトには必ず何かしらの価値が求められます。その価値を言語化し、プロジェクトとして具体化するためには、 要求を適切に言語化 → 仕様を策定 → 設計に落とし込む というフローが欠かせません。この流れは、AI を活用する時代になっても変わらない本質的なプロセスです。 AI がどれだけ進化しても、 「なぜ作るのか」が不明瞭もしくは曖昧であれば、意図通り・要求通りのプロダクトを作ることは困難 です。作るべきものの目的と価値を明確にすることは、AI 時代においても変わらず重要な技術です。 シフトレフトの流れの中で、QA エンジニアは 要求事項の適切性を検証する 役割を担います。要求が適切でない場合、そこには暗黙の前提や仮定が隠されている可能性があります。要求獲得などの技法を活用し、暗黙知を明確に引き出して、必要な情報から作り上げていくことが求められます。 2. 暗黙知 — AI への適切なコンテキスト提供 二つ目は 「暗黙知」 です。 こちらは、チームみらいの安野さんとテクバンの豊田さん・長島さんによるセッション 「AIがQAエンジニアの仕事を奪うのか？」 から得た学びです 現在、AI をできる限り活用し、精度を上げて素早く価値を出すことが大きなトピックになっています。この流れは今後も変わらないでしょう。 しかし、AI に意図通りの価値を出させるには、 適切なコンテキストを渡すこと が不可欠です。そのコンテキストは私たち人間から情報として伝達されます。つまり、どのような情報をどう入力するかが、AI を最大限に活用するための鍵になります。 ここで重要になるのが、 暗黙知の言語化、つまり「暗黙知を形式知に変えること 」です。人間が持つ暗黙知をできる限り言語化し、AI が学習・認識できる状態にする必要があります。 会話やメール、Slackなどのやり取りをログとして集めることも、コンテキストを得るうえで有効だと話されていました。 また、先ほどのfreee様の発表でも相手の真の要求を知るためにヒアリングするなどの「要求獲得」といった話題とも繋がると感じました。 3. 越境 — エンジニアリングと QA の役割の進化 三つ目は 「越境」 です。 チームみらいの安野さんから「QA もエンジニアも、今後同じ作業をし続けるわけではなく、その 業務内容自体が変わっていく」 という話がありました。エンジニアという職業はなくならないものの、担う内容は大きく変化していきます。 「ものを作り上げる」という過程そのものは変わりません。しかし、 どうやって作るのか、なぜ作るのか、作った後にどう運用するのか といった、従来のエンジニアリングよりも幅広い領域に踏み込むことが求められるようになります。 QA においても同様です。プロダクトの品質保証にとどまらず、 プロダクトを通じて自社にどのようなリスクが潜んでいるかを提示する ことが必要になります。 例えば、QA がPdMだけでなく事業部や経営層ともつながり、プロジェクトの意思決定に必要な情報を提示する役割を担うとことも、今後は視野に入れていくことが重要です。 品質保証の 範囲・方法・効果の説明責任 などが、今後のエンジニアの責務の一つとして求められていくと感じました。 まとめ JaSST Tokyo'26 を通じて、以上の 3つのキーワード を持ち帰ることができました。 これらはいずれも、 AI 時代により一層求められる力 だと感じました。今回の学びを今後の業務に活かしていきたいと思います。 おわりに 弊社ではQA、SETの採用も積極的に行っております。 hrmos.co タイミーのQA、ソフトウェアテストについてもっと知りたいという方はぜひカジュアル面談でお話ししましょう。 product-recruit.timee.co.jp

2026 年 3 月 24 日、アマゾン ウェブ サービス ジャパン合同会社（以下、 AWS ジャパン）は、「フィジカル AI 開発支援プログラム by AWS ジャパン」の採択企業向け勉強会を東京の AWS 目黒オフィスにて開催しました。勉強会では、 Physical AI on AWS リファレンスアーキテクチャ と Physical AI Scaffolding Kit の 紹介 、参加企業向けの個別相談会を開催しました。 本プログラムについては、過去のブログも参照してください。 「フィジカル AI 開発支援プログラム by AWS ジャパン」の応募受付を開始 「フィジカル AI 開発支援プログラム by AWS ジャパン」キックオフイベントを開催しました Physical AI on AWS リファレンスアーキテクチャ Physical AI の開発における全体構成とそれを実現するための AWS 構成及び活用いただける AWS サービスを AI Specialist Solutions Architect の飯塚より紹介しました。 Physical AI の開発は「データ生成・収集 → モデル学習 → モデル配信・推論」の 3 ステップを繰り返すサイクルで進みます。シミュレータでの大量データ生成、 GPU クラスタでの分散学習、エッジデバイスへのモデル配信と実環境での評価 ― これらを一気通貫で回す開発環境をいかに構築するかが、 Physical AI 開発の生産性を大きく左右します。 まずデータ生成・収集のステップでは、 NVIDIA Isaac Sim などのシミュレータ を用いて、ロボットの動作データを大量に生成します。実ロボットで収集できるデータ量には物理的な限界があるため、シミュレータによる合成データ生成が不可欠です。 AWS 上では Amazon EC2 の GPU インスタンスに Amazon DCV でリモートデスクトップ接続し、 Isaac Sim を操作する構成が推奨されます。生成したデータは Amazon S3 に格納し、後続の学習ステップで利用します。 次にモデル学習のステップでは、収集したデータを使って Vision-Language-Action Model （ VLA ）をファインチューニングします。学習規模に応じた構成の使い分けが重要で、 LoRA ファインチューニングのような軽量な学習であれば EC2 の GPU インスタンス単体で完結しますが、フルファインチューニングでは Amazon SageMaker HyperPod や AWS ParallelCluster による GPU クラスタ構成が必要になります。 SageMaker HyperPod は GPU 故障時にノードを自動置換しチェックポイントからジョブを再開する機能を備えており、長時間の学習ジョブでも安定した実行を支えます。ストレージには Amazon FSx for Lustre を採用することで、 S3 と透過的にデータを連携しながら、分散学習に求められる高速 I/O を実現できます。 GPU 確保も実践上の大きな課題です。 AWS では用途に応じた予約の仕組みが用意されており、 EC2 Capacity Blocks for ML では 1 〜 182 日の短期間で GPU を予約でき、需給に応じたダイナミックプライシングが適用されます。 SageMaker HyperPod 環境では Flexible Training Plans による予約が可能です。いずれも AWS マネジメントコンソールからキャパシティの空き状況を確認し、利用開始日と終了日を指定して予約する流れになります。 最後にモデル配信・推論のステップでは、学習済みモデルをエッジデバイスや実ロボットにデプロイし、実環境で動作を評価します。 AWS IoT Greengrass を使うことで、クラウドからエッジデバイスへのモデル配信をマネージドに管理できます。なお、ロボットのアクション生成に使う VLA モデルはリアルタイム性が求められるためエッジ側での推論が基本ですが、長期的な行動計画を担う LLM についてはクラウド側での推論も選択肢になります。評価結果は次のデータ収集にフィードバックされ、開発サイクルが回り続けます。 このアーキテクチャを俯瞰すると、 Physical AI の開発には ML 、 HPC 、 IoT 、ストレージ、ロボティクスと多様な技術領域が交差していることがわかります。単一の専門領域だけではカバーしきれない複合的な課題を、クラウド上で統合的に扱えるアーキテクチャの重要性がますます高まっています。 AWS 上で統合的に扱うことができ、またそういったアーキテクチャの重要性がますます高まっています。 スライド資料 Physical AI Scaffolding Kit VLA モデルのトレーニング環境を簡単に AWS 上に構築できるアセット「 Physical AI Scaffolding Kit (PASK) 」の紹介を Senior IoT Prototyping Solutions Architect の市川と ML Prototyping Solutions Architect の石橋より紹介がありました。 Github リポジトリ : https://github.com/aws-samples/sample-physical-ai-scaffolding-kit PASK の概要 PASK は、 Physical AI のモデルトレーニングに必要なサービスを AWS 上に簡単に構築できる CDK コードと学習実行用のサンプルスクリプトをまとめたアセットです。このアセットを使用することで、以下のような環境を数コマンドで構築できます。 アーキテクチャ Amazon SageMaker HyperPod : スケーラブルなクラスター環境です。 Amazon FSx for Lustre : SageMaker HyperPod 内 Node 間共有ストレージ（ S3 バケットとリンク）です。 SageMaker HyperPod クラスター環境の構築 まず、 AWS CDK を使用した SageMaker HyperPod クラスターの構築方法を紹介しました。 詳細な手順につきましては、 こちら をご確認ください。 クラスター構成 : Controller Group : クラスター管理ノードです Login Group : ユーザーがログインし作業するためのノードです Worker Group : モデル学習などが実際に行われるノードです デプロイの流れ : CDK のセットアップと関連ライブラリをインストールします cdk.json で環境設定を行います（クラスター名、インスタンスタイプなど） cdk deploy で一括デプロイを実行します（数十分で完了） SSH 接続を設定します（ AWS Systems Manager Session Manager 経由） Worker Group を追加します 実行前に適宜 GPU インスタンスの上限緩和申請や、 Amazon SageMaker HyperPod flexible training plans によるインスタンスの確保などが必要になります。 ストレージ構成 : 各ノードが共通の Lustre ストレージを /fsx にマウントします。 /fsx/s3link ディレクトリが S3 にリンクされ、トレーニングデータなどを該当バケットにアップロードするだけで各 Node 間でデータが自動連携されます。 VLA モデルのトレーニング実行例 ここでは、 2 つの代表的な Vision-Language-Action (VLA) モデルのトレーニング方法を解説しました。 こちらのアセットでは、 GR00T / openpi で用意されているサンプルデータセットを使って学習を行っていますが、 S3 にデータをアップロードいただくことで、独自データセットでの学習も可能です。 1. NVIDIA Isaac GR00T のファインチューニング GR00T は NVIDIA が開発する VLA モデルで PASK 環境上で以下のワークフローでトレーニングを実行します： 詳細な手順につきましては、 こちら をご確認ください。 事前準備 : Login Node で Git LFS インストール、 GR00T リポジトリのクローン などを実行します Docker ビルド : Docker イメージのビルドと ECR へのプッシュを行います（ Slurm ジョブとして実行） Enroot 実行 : Enroot による Docker イメージの SquashFS 形式への変換を行います 学習実行 : Slurm でファインチューニングジョブを投入します 2. OpenPI の LoRA ファインチューニング OpenPI (Pi0 モデル ) は Physical Intelligence が開発する VLA モデルで、 LoRA ファインチューニングを上記同様の環境で実行できます： 詳細な手順につきましては、 こちら をご確認ください。 開発環境 : Docker イメージのビルドと ECR へのプッシュを行います SageMaker HyperPod (Login Node) 環境 : セットアップスクリプト /Enroot 実行による環境準備を行います 正規化統計の計算 : 学習データの統計情報を取得します（初回のみ実行） 学習実行 : Worker Node (GPU インスタンス ) へ LoRA ファインチューニングジョブを投入します 今後のスケジュール 時期 内容 2026 年 4 月 9 日 基盤モデル開発勉強会 : LLM/VLM 開発の知見共有。 Data Parallel でマルチノードクラスターへスケールさせることを見越した内容 2026 年 4 月 14 日 NVIDIA Robotics Solutions 勉強会 2026 年 4 月中 ロボット勉強会 : AI 開発者がロボット業界に入っていく上で知っておくべき知識の共有（内容・日程調整中） 2026 年 5 月下旬 コミュニティイベント 2026 年 6 月 25-26 日 Demo Day （中間報告会） at AWS Summit Tokyo 2026 （幕張メッセ） 2026 年 7 月下旬 最終成果報告会（ AWS 麻布台ヒルズ オフィス 予定） おわりに 勉強会 #1 では、 AWS のサービスを利用して、フィジカル AI に関係してくるサービスや、スケーラブルなトレーニング環境についての基本的な知識を共有することができました。参加された企業の皆様は、既存の環境と合わせて活用いただくことで、より開発を加速させることができる様に、 AWS ジャパンとしても引き続き支援をさせていただきます。 AWS ジャパンは、本プログラムを通じて日本のフィジカル AI エコシステムの発展に貢献してまいります。採択企業の皆さまの挑戦と、成果発表会をどうぞご期待ください。 関連リンク : – フィジカル AI 開発支援プログラム by AWS ジャパン（発表ブログ）