幕張メッセで開催された、AWS Summit 2026に参加してきました。
前よりも人が多くなっている印象。少しずつ規模が大きくなっているように感じました。会場の熱量が伝わってきました。
基調講演の席も満席で、立ち見の人も多くいました。
連日雨で並ぶのも大変でした。
聞いたセッションについて
まずは各セッションの内容、学んだことなどまとめました。
セッション1: 生成AIサービスの開発・提供におけるClaude on Amazon Bedrockの活用
Anthropicブース内で行われた、NTTデータによるミニセッションです。お客様向けの生成AIサービス「LITRON」で、Amazon Bedrock上のClaudeをどう活用しているかを紹介していました。
話の軸は、Claudeを「サービスへの組み込み」と「サービス開発の効率化」の両面で使っている、という2つでした。
サービスへの組み込み
Claudeを、ユーザー接点と判断・統括を担う中核機能として組み込んでいるとのことでした。あわせて、文書読解やスライド生成といったタスク特化の機能も担わせています。利用者から見ると、裏側でClaudeが動いていることを意識せずに、サービスの一機能として価値を受け取れる形になっています。
利点として挙げていたのが、Amazon Bedrock経由なら推論を日本国内で完結できる点です。これにより、セキュリティ要件が厳しい顧客にも対応しやすくなるとのことでした。
サービス開発の効率化
開発側では、Amazon Bedrock上のClaude CodeとAWS MCP Serverを組み合わせて使っているそうです。
紹介されていたのは、次のような場面でした。
- 方式検討・PoC: 生成AI関連のAWSサービスは日々アップデートされるため、最新情報の収集から始めたい。「最新情報調査 → AWSリソースのデプロイ → コーディング」までをClaude Codeに実行させ、PoCを高速化している。
- 設計・実装: ソースコードと設計書を踏まえて実装案を提案させ、そのままコーディングまで進める。外部システム連携などで出てくるレガシーなExcel設計書も、インプットとして活用できる。
- チーム開発の管理: 開発メンバーが各自の裁量でAWSリソースを作成・利用するため、管理が煩雑になりがち。リソース状況の確認や分析をClaudeに支援させ、定型作業はスクリプト化して定期実行している。
印象に残ったのは、コミットメッセージの形式といったチームのルールをSkillにまとめ、メンバー間で共有して開発を標準化していた点です。属人化しがちな暗黙のルールを、Skillという仕組みでチームの資産に変えていく使い方だと感じました。
セッション2: AI 駆動開発による開発者体験の変革
スライド: https://pages.awscloud.com/rs/112-TZM-766/images/R12_0625_6_AIM213_v1.pdf
東京海上日動システムズ社によるセッションです。組織全体でAIをどう開発・業務に取り込んでいるかを、AI駆動開発を主題に紹介していました。
同社は2018年からAWSを中核にクラウド推進を進め、クラウドへの移行(LIFT)は7割まで完了したとのこと。そこで得たアジリティを、次はAIに振り向けるという流れでした。生成AIの活用は、ビジネス領域の「for BIZ」と、システム開発・運用の「for IT」の2軸で展開しているそうです。
業務にAIを組み込む(for BIZ)
専門性の高い判断業務にAIを組み込んだ「業務AIナビゲーター」が紹介されていました。実装はマルチエージェント構成で、Amazon Bedrock AgentCoreを実行基盤に、その上で動かすフレームワークとしてMastraを採用しています。
Supervisorエージェントが、Web検索・文書チェック・回答レビューの3つのエージェントを統制する形です。役割を分割することで、回答の精度と説明可能性を確保しているとのことでした。これとは別に社内情報検索(SysSearch)なども構築されていて、効率化の効果が出始めていることが共有されていました。
AI駆動開発(for IT)
ここからがメインテーマのAI駆動開発です。同社では2つのスタイルで進めているそうです。
1つは「AI駆動な開発」で、既存プロセスは活かしつつ成果物はAIが作成し、人は指示と承認に集中するスタイル。もう1つは、AWSが提唱するAI-DLC(AI-Driven Development Life Cycle)をベースにカスタマイズした「AI-DLC」で、ビジネスオーナーと開発者が同席し、要件定義から実装までを1日で完結させる一気通貫のスタイルです。
2025年8月には、AWSと共同でAI-DLCワークショップを実施したとのこと(日本国内3社目、金融業界では初)。4チーム・約40名が参加し、試行ではスピードが約10倍、生産性が約3倍という結果も出たそうです。
見えてきた課題
一方で、金融システム開発でAI-DLCを本格運用するには越えるべき壁も見えてきた、と率直に語られていました。
Excel方眼紙のようなLLMが構造を読み取りにくい既存資産やコンテキストウィンドウの限界、生成物の品質・レビュー、そしてUI/UXはAI-DLCでまだ十分カバーできていないといった点が挙げられていました。最大の課題は「問い」のスピードに人が追いつくこと。AIが問いを量産する中で、「問い → 検証 → 判断」の回転をどれだけ速くできるかが鍵で、これは開発者側だけでなくビジネスオーナー側にも意識改革とスキル向上が求められる、という話が印象的でした。
組織として向き合う
これらの課題に組織として向き合うため、「AI駆動開発全体推進事務局」を設置しているそうです。
プラットフォーム構築・人材育成・個別案件支援・開発プロセス改定の4つに、最新動向の研究を加えて並行で進めるとのこと。なかでも「ハーネスエンジニアリング」という考え方が面白く、AIの出力品質を決めるのはモデルそのものではなく、モデルを取り巻く環境(ハーネス)の設計品質だ、という整理でした(Agent = Model + Harness)。仕様書テンプレートや検証スクリプト、AIレビューエージェントといったハーネスを組織の資産として整えることで、どのチームが担当しても一定以上の品質を担保しようとしています。
最後は、AI駆動開発をウォーターフォール・アジャイルに並ぶ「第3の開発手法」として位置付け、2027年度の全社展開を目指す、という展望で締めくくられていました。
セッション3: Physical AI における学習・運用での AWS 活用方法
スライド: https://pages.awscloud.com/rs/112-TZM-766/images/R10_0625_AIM328_v1.pdf
Physical AIをAWS上でどう学習・運用していくかを、リファレンスアーキテクチャまで含めて解説していました。あわせて、AWS Village内の「Physical AI - 見て、考えて、動かす」ブースにも立ち寄りました。この考え方を体現したデモが動いていたので、その様子もまとめます。
Physical AIとは
セッションでのPhysical AIの定義は「物理世界を知覚し、推論し、学習しながら、自律的に行動するシステム」でした。座標や動作を人があらかじめ指示する従来の産業ロボットと違い、学習データから適応的に動けるのが特徴で、これまで自動化が難しかった変化の多い現場での活用が期待されています。
構成としては、全体を統括する低速なエージェンティックAIと、高速(数十Hz)でロボットを制御するロボット基盤モデル(VLA: Vision Language Action Model)を組み合わせる、という整理が紹介されていました。エージェンティックAIが「何をどうやるか」を計画し、ロボット基盤モデルがセンサー入力をもとに実際の制御や動作を生成する、という役割分担です。
ブースのデモ
大きなブースに、仮想の街を模したジオラマとロボットアームが2台並んでいました。街なかの建物もAIで生成したそうです。道路にはグリーン通り・パープル通りといった名前がつけられていて、その上をライントレースで走る配達ロボットが荷物を運んでいます。
デモのシナリオはこうです。配達ロボットが走行中に道をふさぐ障害物に遭遇すると、その情報をクラウドに送信します。クラウド側では、どの位置からアラートが上がったかをもとに、2台のうちどちらのロボットアームを動かすかを判定します。
街を俯瞰するカメラは置かれていないので、指名されたロボットアームがアラートのあった付近まで動いて道路を撮影し、その画像から障害物を認識します。画面には「ARM2でグリーン通りを観察します」「ペットボトルと思われる異物が道を塞いでいます」といった思考の途中経過が表示されていて、AIが状況をどう捉えているのかが見えるようになっていました。アームの先にはグリッパーが付いていて、QRコードを貼った障害物をなめらかな動きで取り除いていきます。ペットボトルやスマホも異物として認識はしていましたが、実際に掴めるのはQRコードのついたものだけ、という作り込みでした。
この判断の部分は、クラウド上のClaude Haikuが担っているとのことでした。現場のロボットは見て動く役に徹し、状況の解釈や次の一手の判断はクラウドのエージェンティックAIに任せる。先ほどの役割分担がそのまま形になっていて、わかりやすいデモでした。
学習と運用をAWSでどう支えるか
セッション本編は、こうしたPhysical AIを成り立たせる学習・運用の基盤をAWSでどう作るか、という話でした。大きくは3段階の流れで整理されていました。まずエッジからのデータ収集です(AWS IoT GreengrassやAWS IoT Core、保存先はAmazon S3)。次にクラウドでのモデル学習とシミュレーション(Amazon SageMaker AIやAWS Batch、Isaac SimやMuJoCoといった物理シミュレーター)、そして学習済みモデルを実機に届けて差分を埋めるSim2Realのループ、と続きます。最後はロボットとエージェンティックAIをつなぐ部分としてStrands Agentsが紹介され、これらをまとめたリファレンスアーキテクチャやサンプル実装も公開されているとのことでした。
物理世界で動くロボットも、裏側はデータ収集・学習・デプロイというMLのライフサイクルに落ちる、という整理が腑に落ちました。ブースのデモは、そのループのうち運用側を切り出して見せてくれていたのだと、後から振り返って気づきました。
セッション4: 165 日から 30 分へ：JAL デジタルが敷いた「開発者専用の滑走路」 －認知負荷をゼロにする Platform Engineering 実践記
スライド: https://pages.awscloud.com/rs/112-TZM-766/images/0626_PRT141-S.pdf
JALデジタルの大用拓也さんと、Red Hatの大塚洋さんによるセッションです(PRT141-S、Red Hatのスポンサーセッション)。社内の開発者が、環境構築や各種申請に追われてなかなかコードを書き始められない、という状況をPlatform Engineeringでどう変えたかの実践報告でした。タイトルの「165日から30分へ」は、最低限のシステムをリリースするまでのリードタイムが165日かかっていたのに対し、開発環境の準備を30分以内にすることを目標に掲げた、という対比です。
なぜ「滑走路」が必要だったのか
発足の背景として挙げられていたのが、開発者を取り巻く「乱気流」でした。コード規約・監視設定・CI/CD・脆弱性対応・申請手続きと、本来のコードを書く前に消耗してしまう状態です。これを変えるために、Platform Engineering(PFE)チームが立ち上がりました。
まず取り組んだのは、現状を数字で測ることでした。VSM(Value Stream Mapping)やUSM(User Story Mapping)、開発者へのヒアリングで可視化したところ、リードタイム165日・プロセスタイム385時間・申請書40種類以上という3つの数字が見えてきたそうです。感覚ではなく数字で示すことで、課題を経営層と現場の双方で共有できるようにする、という姿勢がセッション全体を通して一貫していました。
経営計画に組み込む
次に印象的だったのが、この取り組みを単発の改善で終わらせず、経営計画に組み込んだ点です。FY25を黎明期、FY26を成長期、FY27を展開期とするロードマップを引き、初年度のKPIとして「ポータル経由の開発環境準備を平均30分以内」「本番リリースまでの平均リードタイムを70%短縮」「JALデジタル社員の90%以上がPFE活動を認知」といった具体的な目標を置いていました。数字の裏付けがあるからこそ、予算や人材を確保して全社を巻き込める、という整理です。
認知負荷をなくす3つのアプローチ
環境準備のリードタイムを165日から30分へ縮めるために、3つの解決策が紹介されていました。
1つ目は、社内文書のTechDocs化です。あちこちに散らばっていたドキュメントを、開発者ポータルという1つの入口に集約します。その先にはAIと連携した対話的なナレッジ基盤を見据えていて、「探す」から「聞く」へ、ドキュメントの探索時間をゼロにするのが狙いだそうです。
2つ目は、Software Templateの作成です。申請から環境構築までを数分に短縮するもので、AWS LambdaとAmazon DynamoDBという社内で採用されやすいシンプルな構成から自動で払い出します。リポジトリの作成からTerraformの起動までを自動化し、CI/CD周りの認知負荷も下げていました。
3つ目は、全社向けの教育・啓蒙です。作っても使われなければ意味がない、という考えから全社員向けの教育を実施し、受講率80%突破・PFEの意義理解96.2%という結果を出していました。あわせて「お困りごとダンプ」という形で現場の生の声を継続的に集め、改善につなげているとのことでした。
基盤づくりと、Red Hatの伴走
これらを支える基盤として、ROSA(Red Hat OpenShift Service on AWS)とRHDH(Red Hat Developer Hub)が紹介されていました。ROSAはマネージドサービスとして運用をオフロードし、RHDHは開発者ポータルとしてセルフサービスでの環境払い出しを担う、という役割分担です。開発者はポータルから、Terraform・Ansible・GitOpsを通じて自分でAWS環境を払い出せるようになっています。
一方で、製品を入れただけではうまくいかなかった、という話も率直でした。PFEチーム「LUX」を立ち上げる際には、経営層の賛同を得る・各部署に協力してもらうといった点で壁にぶつかったそうです。そこはKGIとKPIで合意を取りつけたり、リーダーが何度も啓蒙してメンバーを集めたりして乗り越えたとのことでした。「作っても使い方が分からなければ広がらない」という課題には、教える・試させる・隣で走るというEnabling Teamの動きで現場に伴走していました。Red Hat側も、経営層を巻き込んだ支援体制づくりや自走できるエンジニアの育成といった面で並走していた、という座組みでした。
まとめ
最後は、明日から動き出すための3つとしてまとめられていました。まず「測る」、「経営計画」に組み込む、そして「主戦場」から始める。なかでも、いきなり全部をやろうとせず自社で一番使う部分(JALの場合はAWSとROSAが大半を占める基盤)から成果を出し、そこから広げていくという現実的な進め方は、他のセッションにも通じる学びだと感じました。
その他
ロボット系の実演は数多く行なっており、人間の動きをトレースするロボットや、5本指を持ったロボットなど様々なロボットがいました。
医療分野や産業分野など様々な分野でロボットxAIが活躍しそうです。
まとめ
今年のAWS Summitを通して強く感じたのは、AIをどう開発に取り込み、組織として駆動していくか、というテーマのセッションが本当に多かったことです。生成AIサービスの作り方から、AI駆動開発(AI-DLC)による開発プロセスの見直し、ロボットと連携するPhysical AI、開発者向けのPlatform Engineeringまで、切り口は違っても「AIを前提に開発のやり方を組み立て直す」という方向を各社が向いていました。個人がツールを便利に使うという段階から、全社・組織としてどう進めるかへ、話の重心が移ってきているのを感じます。
裏を返すと、決定版のやり方はまだ誰も持っていない、ということでもあります。AIの進化は今まさに移り変わりの激しい最中で、半年前の正解が次の半年で変わってもおかしくありません。だからこそ、事例をそのまま真似るのではなく、自分たちの現場で小さく試して測り、改善しながら型をつくっていくしかないのだと思いました。
自分自身も、ここで見聞きしたことをきっかけに、AI駆動開発まわりを色々と手を動かして試していきたいです。来年のSummitで、今年見た景色がどこまで当たり前になっているのか、楽しみにしたいと思います。
