初めまして！ 山越です。 2026年6月26日、幕張メッセで開催された
初めまして！ 山越です。
2026年6月26日、幕張メッセで開催された「AWS Summit Japan 2026」に参加してきました！
この記事では、今回の参加目的、現地で見聞きした内容、そして今後の開発に取り入れたいことをまとめます。
AWS Summit Japan 2026について
AWS Summitは、AWSが世界各地で開催している、クラウド技術とAWSサービスを学ぶための大規模イベントです。
日本では「AWS Summit Japan」として開催され、AWSの最新サービスや導入事例を、260を超えるセッション、300以上の展示、ハンズオンなどを通じて学べます。参加は無料の事前登録制です。
2026年は6月25日（木）・26日（金）の2日間、幕張メッセで開催されました。私は2日目の6月26日に参加しました。
今回の参加目的
現在、生成AIやAIエージェントへの関心が、業界全体で急速に高まっています。
私自身もAIを活用した個人開発に取り組んでおり、今回は次の点に関して知見を広げるために参加しました。
- AI駆動開発には、実際にどのような方式やプラクティスがあるのか
- AWSや各社が実際の業務やプロダクトでどのようにAIを活用しているのか
- AI駆動開発で人間が介入するのはどんなタイミングか
印象に残ったセッション
今回、特に印象に残ったのは、スペシャルセッション「AI エージェントが変える企業の未来 ─ 構築から運用まで、ビルダーと創る自律型 AI の実践」です。
チャットボットからAIエージェントへ
セッションでは、チャットボットとAIエージェントの違いが、次のように整理されていました。
チャットボットは、質問に対して回答し、何をすべきかを教えてくれます。しかし、実際に手を動かすのは人間です。
一方、AIエージェントは回答するだけでなく、必要な作業の洗い出し、問題箇所の確認、チケットの作成、タスクの実行までを担います。
AIが「回答する存在」から「作業を実行する存在」へ変わってきた、という整理です。
実際に2026年はAIエージェント元年ともいわれ、生成AI・基盤モデル開発企業はAIエージェントの自立稼働がいかに長く作業できるかを前面に出し、競争をしています。
AI-DLC：AIを開発プロセスの中心に置く
ソフトウェア開発におけるAI活用について、セッションでは次のような問題提起がありました。
「既存の開発プロセスを大きく変えず、AIツールを追加するだけにとどまっていないか。
その結果、コーディングで節約した時間が、レビューやテストに消えていないか。」
この問いへの答えとして紹介されたのが、AmazonのAI-DLC（AI-Driven Development Lifecycle）です。
AIを開発プロセスの一部として追加するのではなく、開発プロセスの中心に位置づけ、ソフトウェア開発ライフサイクル全体でAIの能力を活用する考え方です。
セッションでは、AIを開発プロセスの中心に置く実行モデルが紹介されました。
まず対比として、AIをツールとして導入した場合の一般的な流れは次のようになります。
1. 人間が要件や設計を決める
2. 人間が実装を進める
3. 必要に応じてAIにコード生成や補完を依頼する
4. 人間がレビュー・テストを行う
この場合、AIはあくまで作業を補助する存在であり、開発プロセスの主導権は人間にあります。
これに対して、AI-DLCでは次のような実行モデルが提示されていました。
1. 人間が意図を伝える
2. AIが計画を立案する
3. 人間が計画をレビューする
4. AIが計画を修正する
5. 人間が修正結果をレビューする
6. AIが計画を実行する
7. 人間が結果をレビューする
AIが計画と実行を担い、人間はレビューと意思決定に集中します。従来の開発では、人間が設計から実装まで主導し、AIは補助的なツールとして使われることが一般的でしたが、AI-DLCではAIが計画立案や実行の中心を担い、人間はその内容を確認し方向性を調整する役割にシフトします。
作業の主体が人間からAIへと移り、開発プロセス全体の進め方が大きく変わっています。
AIを開発プロセスの中心に据え、人間がその舵を取る。この関係性こそが、AI駆動開発の核となる考え方だと感じました。
そして、人間はこれまで以上に意思決定の領域を重視する必要があるとも感じました。
AWS Continuum：段階的に自律化するセキュリティ
セキュリティの文脈では、「AIの進化によって、セキュリティ運用の前提が変わってきている」と語られていました。
AIの成長により脆弱性の発見から攻撃までの時間が短くなっている中、従来のように人間がアラートを確認してから対応する運用だけでは、追いつくことが難しくなっています。
この課題を解決するものとして紹介されたのが「AWS Continuum」です。
れは、単にコードをスキャンして脆弱性を一覧化するだけの仕組みではありません。
AWS上のインフラストラクチャ、アクセス許可、コードなどの技術情報に加え、組織のドキュメントやコミュニケーション、ビジネス上の優先事項も判断材料として利用します。
これらの情報をもとに、検出した脆弱性が実際の環境にどのような影響を与えるのかを分析し、次のサイクルを自律的に実行します。
発見 → 優先順位付け → 検証 → 修復
つまりAWS Continuumは、脆弱性を数多く検出することだけを目的としたものではありません。検出した脆弱性が自分たちの環境で本当に対応すべき問題なのかを判断し、優先順位付けから検証、修復までを一つのループとして継続的に回す仕組みです。
さらに、AWS Continuumでは「段階的に信頼する」という設計思想を採用しています。
AWS Continuumでは「段階的に信頼する」という設計思想を採用しています。
最初からAIに修復作業をすべて任せるのではなく、人間が介在するlearnモード（学習モード）から始まります。
「learnモード」では、AIが脆弱性への対応方法を提案しますが、自動的には適用せず、人間がその内容を確認します。また、提案には結論だけでなく、なぜその脆弱性を優先したのか、どの情報からその修復方法を導いたのかといった推論の背景も含まれます。
人間はAIの提案内容と根拠を確認し、実際の環境に適しているかを判断します。この過程を繰り返し、提案や修復結果に対する信頼が積み上がった段階で、enforceモード（適用モード）へ移行できます。
「enforceモード」では、利用者があらかじめ定義した脆弱性のカテゴリやリスクプロファイルに基づき、修復作業を自動的に実行する範囲を広げていきます。
その他のトピック
このほかにも、さまざまな企業やサービスの事例が紹介されました。
・オムロン
研究開発における仮説、計画、分析、実験のサイクルにAIエージェントを組み込み、ワークフローの作成にHuman in the Loopを取り入れた事例
・サイバーエージェント
AI利用をレベル1からレベル5に分類し、推進体制や経営層のコミットメントの有無によって、成果に差が生まれると分析した事例
・AWS Transform
自然言語でコード変換の方針を定義し、レガシーシステムの分析から移行計画、実行までを支援するモダナイゼーションサービス
AI-DLCから感じたこと
今回のセッションで最も持ち帰りたいと感じたのは、AI-DLCの考え方です。
ここまで見てきたように、AIは単にコード生成を補助するだけでなく、設計や検証、さらにはセキュリティ対応に至るまで、開発プロセス全体に関与する存在になりつつあります。その前提に立つと、AIをどのように開発プロセスへ組み込むかという視点が重要になります。
仕様や計画をAIと一緒に詰め、内容を人間が確認した上で実行に進む。この流れは、AIに作業を一方的に任せるというよりも、AIと伴走しながら開発を進める感覚に近いと感じました。
目的や意図は人間が決定し、間の作業はAIが高速化する。
現時点では、この形がAI駆動開発を現実のプロジェクトに取り入れる上で、目標とする形では無いかと考えています。
AI駆動開発で意識したいポイント
参加したセッションの内容をもとに、今後のAI駆動開発において、プロンプトの内容やAIに読み込ませる情報について意識したいポイントを自分なりに整理しました。
- コンテキストウィンドウを慎重に管理する
- 大規模なコードベースを、そのまま全部読み込ませない
- 既存コードや既存の設計を手本として与える
- 曖昧な指示ではなく、具体的な設計意図や制約を伝える
- AIの出力を鵜呑みにせず、根拠や妥当性を確認する
- 小さく試し、早い段階で失敗から学ぶ
- AIとの協業方法は、実践を通じて身につける
- AIが生成したコードであっても、品質、安全性、運用結果には人間が責任を持つ
上記の内容を見てAIを触ることで何ができて、何が苦手なのかを体験するべきだと感じました。
「小さく試し、早い段階で失敗から学ぶ」、「AIとの協業方法は、実践を通じて身につける」これはすごく大切ですね！
AIとの試行錯誤は、小さく始めれば失敗のコストも抑えられます。最初から大きな作業を任せて完璧を求めるのではなく、小さな作業から任せ、経験を蓄積していきたいと思います。
企業ブースを回って
企業ブースでは、さまざまな企業がAIに関するプロダクトや支援サービスを紹介していました。
「アーキテクチャ設計をあなたのプロダクトに」「AI駆動開発の導入を支援」といった展示が数多く並び、各社のAIに対する熱量を肌で感じました。
また、会場を歩いているだけでノベルティが増え、帰る頃にはバッグがすっかり膨らんでいました（ノベルティ祭り）。
その中で足を運んだのが、以前から気になっていたVercelのブースです。Vercelが出展していることは、会場に着いてから知りました。
ブースでは、AIを活用してUIデザインとコード生成ができるツール「v0」のデモを見せていただきました。
v0では、AIと対話しながらUIを作成できます。
UI開発で手間のかかる細かな調整や部分的な修正についても、修正したい箇所を指定し、「ここをこう直してほしい」と伝えることで変更を反映できます。
また、文字やボタンを選択し、サイズや色を自分で直接調整することも可能です。
AIによる生成と、人間による細かな調整を組み合わせられる点が便利だと感じました。
今後、Webアプリのフロントエンドを作る際には、v0を使って実装してみたいと考えています。
まとめ：AIの現在地と今後の取り組み
今回のAWS Summit Japan 2026で感じたのは、AI活用がすでに実験の段階を越え、要件整理、設計、実装、セキュリティ、運用まで広がっているということです。
また、「スキルやハーネスをどう作るか」という段階から、AIエージェントをプロダクトや業務プロセスそのものにどう組み込むかという段階へ進んでいることも実感しました。
私自身は、Claude Codeを使い、CLAUDE.md、Skills、Hooksを組み合わせて、実装作業をスキル化することに取り組んでいます。この方向性は、会場で紹介されていた事例とも大きくずれていないと感じました。
一方で、会場ではさらにその先となる、業務に特化したAIエージェントの構築や、仕様生成、論理チェック、実装などを複数のエージェントが段階的に担うパイプラインの話も紹介されていました。
今後は、現在取り組んでいる作業のスキル化に加えて、AIエージェント同士をどのようにつなぎ、どの段階で人間がレビューし、意思決定するのかという点も意識していきたいと考えています。
AIが多くの作業を担えるようになっても、人間の責任がなくなるわけではありません。
AIを疑いすぎて使わないのでも、信じすぎてすべてを任せるのでもなく、AIと伴走しながら開発を進め、AIに計画や実行を任せつつ、人間がレビューし、方向を修正し、最終判断を下す。そのためには人間側の技術理解とレビュー能力も必要になってきます。
AIがコードを書けることと、自分がその正しさを保証できることは別なのでここは自分も努力していかなければと思いました。
そして最後には、AWSの方々とお酒を飲みながら話をする機会もありました。
セッションや展示から情報を得るだけでなく、直接交流できることも、現地参加ならではの価値だと実感した一日でした。
## 参考リンク
– [AWS Summit Japan 公式サイト](https://aws.amazon.com/jp/events/summits/japan/)
– [11 社合同 AI-DLC Unicorn Gym で体験した開発のパラダイムシフト](https://aws.amazon.com/jp/blogs/news/joint-ai-dlc-unicorn-gym-202601/?utm_source=chatgpt.com)
– [AWS Continuumのご紹介：マシンスピードで実現するセキュリティ（AWS公式ブログ）](https://aws.amazon.com/jp/blogs/news/introducing-aws-continuum-security-at-machine-speed/)