2026 AWS SUMMITの参加記録

Last updated at 2026-07-11Posted at 2026-07-11

概要

オンデマンドで視聴したので、その中で見たものをまとめた。
個人的には2の話はめちゃくちゃ大切だと感じた。現場の間隔そのものでそれに対するソリューションも腹落ちしたしあえて非効率、というかAIを使わず自分で考えることはしていた部分もあったので納得した。その際１も観ておくとより頭に入りやすい。４はまた別視点だがエンジニアで普段当たり前に感じていることを非エンジニアの視点で話してくださっていて気づきを得られたし、素晴らしい取り組みであり、身が引き締まった。３は最近SSO周りを勉強しているから内容がスッと入ったその上、TokenVaultの仕組みが素晴らしくさすがAWS！同意疲れに対する明確なソリューションでこれはMCPServerを使う誰もが使いうる便利サービスだと感じた。５，６，７はまた後程時間があればまとめる。

参加したセッションごとに勉強になったと思ったポイント

1． AI 駆動開発ライフサイクル (AI-DLC) のご紹介

AIにはプランニング、アーキテクチャ、docs生成を対応させ、人間はそのレビュー・監督責任や意思決定を担う
コーディングを早くするだけではだめで結局人の意思決定がボトルネックになる。そこでモブエラボレーション、モブワークが解決の糸口になりうる
AIを賢く使うことも当然必要
[WIP]

2. AI でコードは書けても、レビューできる人がいなくなる ― ソフトウェア開発における自動化のパラドックス

※ コードに限った話ではなく、AIが担いうるすべての領域に通ずる
ポイントは「意図的な非効率」「AI-DLCでの実践」
- 問題点；AIを使うとオーナーシップが欠如し、スキル(技術力)は育たず、レビューする力も育たない。(AIの神格化・と極依存)
- 解決策
  - 意図的な非効率（＝AIを使い続けるための仕掛け）
    - 曖昧な領域はAIに頼らずあえて自身で開発し、なぜ必要なのか、どうあるべきなのか判断する
    - 狙い
      - ジュニアが考える力を身に着ける
      - ミドルが判断・レビューする力を維持
      - オーナーシップ形成の育成領域が機能
  - AI-DLCで実践
    - 参加者全員のオーナーシップ
    - AI出力を評価・判断する力と経験
    - 判断と取捨選択を引き受ける覚悟
    - ⇒ 意図的な非効率で育った人材なら問題なく、効率的に回せる開発手法

3. エージェンティック AI アプリのセキュリティ・UX・開発速度を同時に実現 ─ Amazon Bedrock AgentCore Identity が解決する3つの課題

AmazonCore Identity
- セキュリティ
  - IAM SigV4なら非常に簡単な実現可能。JWTでも認証可能で、より細かい認可を制御可能
- UX
  - TokenVaultに一度アクセス許可をしたOAuthトークンをWAT(Workload Access Token)を紐づけて保存する仕組みにより、毎回OAuthで外部ツールへのアクセス許可などしなくとも、利用可能になっている
- 開発速度
  - トークン取得はデコレータを付けるだけで実現可能
  - 他も最小限
- 監査性・可視性
  - CloudTrail対応

4. AI エージェントで現場を変えた－ 2 社の挑戦の瞬間

5. ゲームチャットを支える技術

6．MMO 戦略シミュレーションゲーム『三國志覇道』における Amazon Bedrock を用いたチャット等リアルタイム翻訳事例

7. AI に"賭ける": LayerX の AI エージェント基盤と活用最前線

ノート

1.AI駆動開発ライフサイクルのご紹介

AI-DLC(AI-Driven Development Lifecycle) : 人間とAIの協調的なワークフロー
- サイクル
- 役割
  - AI ：プランニング、ドキュメント作成、アーキテクテエィング
  - 人間：レビュー、最終的な意思決定、監督責任
- 全体の流れ(前のフェーズが)
  - Inception
    - 既存のコードのコンテキストを構築
    - 顧客に届けたい価値へフォーカスしてユーザーストーリを定義
    - 平行作業可能な単位で計画
  - Construction
    - ドメイン駆動設計であればドメインモデル（コンポーネントモデル）を選択
    - アーキテクチャコンポーネントを並行して追加実装
    - コードとテストを生成
  - Operation
    - IaCで本番環境にデプロイ
    - AIファーストなインシデント管理
    - 更なる改善に関して開発者への素早いフィードバック
- flow
  - 前のContextは次のフェーズへのリッチなContextになる
  - ウォーターフォール的ではなく、必要性に応じて適宜高速にフィードバックして前のフェーズに戻る
SDLC(Software Development Lifecycle)との対比
- SDLC：人手で行うため、誰かの作業を誰かが待つ時間が必ず発生していた
  - コーディングが早くなるだけではだめで、意思決定や合意形成がボトルネックになる
- ADLC：
  1. Inceptionフェーズで行う モブエラボレーション
    - 開発チーム、運用チーム、PM、ビジネスアナリスト、QAなどの全員が一つの場に集まり、AIを駆使するドライバを決め、AIとともにユーザーストーリ―を作成し、全員でレビュー、議論することで意思決定をする場
    - さらに、次のフェーズに向けた作業についても平行度などを議論・レビュー誌洗練させる場
      - その場でAIの成果物を全員が見るため、その場で合意・決定していくのがポイント
  2. Constructionフェーズで行う モブコンストラクション : 詳細設計と実装
    - インセプションフェーズで分割した作業単位ごとに3-5名程度の様々な役割の人(デザイナ、プロダクトオーナー、エンジニアなど)で構成された小規模チームを複数作成し、物理的に同じ空間でモブワークを行う
    - ここでも高速な判断をその場にいる全員で下していくことがポイント
評価
- デリバリー機関で測定(従来の見積もりvs AI-DLCの見積もりと実績)
  - メトリクス
    - プロジェクトの見積もり
    - タイムライン
    - 品質スコア
    - 見積の開発期間vs実際のAI-DLCの開発期間
AIをうまく使うために
1. ContextWindowの管理
2. 既存システムでもうまくいく
  - コールグラフ、クラス、各関数などの役割を要約したコンテクストを構築する
3. 既存コード例を模倣させる
4. 強い意味を持つトークンを使う
5. パッチ修正より書き直しのほうが早いのか
  1. 0からaiに作らせた方が早い、という可能性も考慮するべし
6. AIをシニアエンジニアと同じようには信頼しない
  1. AIの出力をうのみにせず、疑うことも止めず、躊躇うことなく問い詰めるべし。批判的な姿勢
7. 実験への姿勢
8. AIとの共同を学ぶには実戦経験が大切
9. 最終的なコードの所有者はあなたです。コミットログに著者として乗るのはあなたの名前です

2. AI でコードは書けても、レビューできる人がいなくなる ― ソフトウェア開発における自動化のパラドックス

背景
- 世界で起きていること
  - 生産性は個人単位で向上しているが、プロジェクト全体では向上していない
  - 生産速度が速くなったと感じているが、実際は遅くなっている
    - 個人の生産性は上がったが、市場投入期間が変わらないので財政への影響は5％程度だとマッキンゼーが報告している
  - コード作成は早くなったが、品質の相談は増えている
- AI活用のパラドックス：個人の開発生産性は効率的と感じる一方で、全体に効果が波及していない現象
AI活用は組織の強みと弱みを増幅させる
- 観測されるマルチエージェントAI利用の共通パターン
  - 「誰が」「何を」「どの成果物に責任を持つか」が未定義
  - 人間の役割分担の写し絵 ⇒ マルチエージェントが互いに整合しない成果物
  - 人間組織の「曖昧さ」をマルチエージェントはそのまま露呈している
- 本当の原因は組織構造の問題で不調はその「鏡」
  - Anthropicが提唱するOrchestratorWorkerPatternは人間の役割構造をそのまま模すのではなく、並列実行可能なタスクをマルチエージェントに任せるべきだと述べている
  - 鏡に映るものは？
    - 組織の意思決定の仕組みやその健全性
    - 責任範囲があいまい ⇒ レビュー不足、「詰まり」が人間⇒AIに移動するだけ
    - 判断を下す人がいない ⇒ AI出力の取捨選択ができない
    - 言語化をあきらめている組織 ⇒ プロンプトも曖昧、要件も曖昧
- AIは組織の弱みを作るのではなく、すでにあった弱みの在りかをはっきりさせる (AIミラー効果@DORA 2025
- "You build it, you run it." by Walter Vogels, Amazon CTO (作った人が、運用まで責任を持つ) これは本来運用に適用する言葉だがAI開発に適用するのが鍵だと主張
  - 強みの増幅
    - 顧客の反応が直接届く構造は、エンジニアの学習速度を加速
      - フィーロバックの解像度が上がるほど人が育つ速度も上がる
  - 弱みの構造的抑制
    - 「壁の向こうに投げる」選択肢が存在しない（＝開発チームと運用チームがおなじだから）
      - 下流の痛みが必ず上流の自分に跳ね返ってくる構造
  - 作った人が運用まで責任を持つ」という組織設計は強みの増幅を最大化し、弱みの増幅を構造的に抑える
AI活用のパラドックスの正体とは？
- 二つの要因
  - A. スキル浸食の悪循環：「簡単にできる」ツールによって人が考える工程を消す
    - 対象となっているシステムや業務が正常に動作している限り、「スキル浸食の悪循環」問題として顕在化しない
  - B. オーナーシップの欠如：「AIに任せる」範囲が「自分のコード」の実感を消す
    - 心理的オーナーシップが生まれる経路
      - コントロール
        
        自分がコントロールしている感覚
      - 深い知識
        
        端から端まで知っている感覚
      - 自己投入
        
        時間・思考・労力がしみ込んでいる感覚
    - AIに開発を任せると上記はどれも満たしにくい
      - AIがかいた
      - コードの設計妥当性は未確認
      - AIが10分でだしただけ
    - 例
      - いえらぶGroup
        
        エンジニア：AIによるコードは正解そのもの ⇒ PR　830件
        
        執行役員：AI禁止令 ⇒ 4か月かけて段階的にAI使用解禁
        
        「自分にできないことは、AIにやらせても判断できない」、「最後に責任をもって意思決定するのは自分」
  - A ⇒ 評価やレビューの「目」が育たず、さらにAI依存する「ループ」に陥る
  - B ⇒ 誰も最終判断を引き受けず、レビュー自体が組織機能の外に置かれる
    - ⇒ レビューできる人が育たなくなる
  - AIをつ活用するための警句として使えるであろうAmazonのリーダーシップ(プリンシンプル行動指針)「リーダーは長期的視点で考え、短期的な結果のために、長期的な価値を犠牲にしません。」
解決策：「意図的な非効率」とAI-DLCの両輪
- 意図的な非効率：効率化からあえて外す工程を組織に残す設計思想
  - 「型だけ」を導入し、「なぜそれが必要なのか」の言語化をさぼる ⇒ 「儀式化」、成果なし
  - 簡単すぎる環境は育成を止める
    - 学習には適度な難しさ、があるほど定着する
    - 熟達は自分の判断で楽な環境の外に踏み出し続けることでしか起こらない
  - 言い換えると、「スキル育成を阻害しないためにできる工夫」、「AIを活用したとしても自分の判断で自分の成果物として、工程を通り抜ける余地」をあえて残す
  - 3つの勘所
    - オーナーシップを形成する3つの育成領域の確保
    - ジュニアからシニアまで個人の経験値に合わせた段階的なAI活用の設計
    - トレーニングの環境を用意する安全な失敗経験の設計
    - ⇒ AIの利用禁止ではなく、どこが人間の領域化を設計するガードレール型の統制
- AI-DLC
  - 開始フェーズで用件・優先順位を先に確定してから実装
    - 判断が先送りされず、主体が明確になる
  - エグゼクティブ・PdM・デザイナー・開発者など関係者が共同参加
    - 誰が責任を引き受けるか、が全員に見える
  - AIがあらゆる工程を支援
    - 作業不可が下がり、人間は「判断・議論・育成」に時間を振り向けられる
  - ⇒ AI-DLCで弱点を映し、意図的な非効率で埋める
    - 例えば、監視工程があいまいなのであればそこは意図的にAIを用いずに人が行う
    - 移された弱点＝育成設計の入力
  - そもそもAI-DLCは熟達したエンジニアやエグゼクティブが実践する開発手法なので、若手のスキル育成という意図がある開発手法ではない。育成されたスキルを実践する開発手法

3. エージェンティック AI アプリのセキュリティ・UX・開発速度を同時に実現 ─ Amazon Bedrock AgentCore Identity が解決する3つの課題

Agentic AIを本番導入するにあたってのIDとアクセス管理の課題
- AgenticAIのメリット
  - 生産性が向上し、コンテキストに基づく意思決定を行い、使えば使うほど学習し精度が上がり、市場投入までの時間もさらに短縮する
- 本番運用の課題
  - セキュアなアクセス
    - エージェントに付与する最小権限の設定
  - 制御された自律性
    - エージェントの自律性vs組織のガードレール
      - 最初は制限して徐々にできることを増やすようなコントロールできる必要がある
  - 進化するガバナンス
    - エージェントによるリソースアクセスをもれなく追跡できる監査証跡(=log)
- 一般的なアクセスパターン : どちらであっても、リソースへのアクセスは必須
  - ユーザーのタスクを代理実行
    - 例：営業支援としてメール作成、要約資料作成
      - 懸念：正しいユーザーが呼び出しているのか？
      - 懸念：不正なユーザーが顧客情報をもつAgentにアクセスできてしまう？
  - 何かのイベント駆動でタスクの実行
- エージェントシステムが持つアイデンティティの課題
  - セキュリティ : 権限の安全な委任
  - UX : 同意疲れの対応
  - 開発速度 : 既存の仕組みとの統合
AmazonBedrockAgentCoreIdentity
- 概要
  - LambdaのようにAgentが実行されている時間だけ課金される課金モデル
  - AI(Claude, OpenAI,...)・Framework(strand agent, LangGraph...)など任意に選択可能
  - 外部ツールとはMCPを使って連携する。それをホストするのがAgentCore Gateway (AgentCore Policy). AgentCore Runtimeと深く統合されている
  - 仕組み
    - セキュリティ :
      - Agent固有IDを付与して安全なAgent運用を実現
      - AWS 3rd Serviceに安全にアクセス可能
    - UX :
      - セキュアなトークンボールトで同意疲れを最小化
      - 認証フローとクレデンシャル管理を最適化
      - 包括的な監査証跡
    - 開発速度 :
      - Azure Entra ID, Amazon Cognitoなどとシームレスに統合
      - ユーザー移行、認証再構築など不要
  - 認証・認可
    - 人ーAgentー外部ツール・AWSリソース・外部Agent
      - InboundAuth：人ーAgent間の認証認可
      - OutboundAuth：Agent-外部ツール・AWSリソース・外部Agent間の認証認可
      - この二つのつなぎ込みをするのがCoreIdentityの主な役割
  - アクセス制御(InboundAuth)
    - IAM SigV4による制御
      - EC2,ECS,EKSなどからAgentへアクセスする場合はヘッダーにユーザー情報を設定することで、OIDCのようなフローは不要になる
    - JWTによる制御
  - アクセス制御(OutboundAuth)
    - TokenVault
      - OAuthのフローで取得したOAuthトークンをWATに紐付けてを安全に管理するストレージ
      - 外部ツールに行く際は毎度OAuthするのではなく、WATでリクエストしてOAUTHトークンを得て、外部リソースなどへアクセスをする
      - さらにUserAがUserBのトークンを得ることは絶対にないように設計されているため問題無用
      - OAuthの方式は様々あるが人-マシン, マシン-マシンどちらも対応している
- 進め方

4.AI エージェントで現場を変えた－ 2 社の挑戦の瞬間

株式会社マキタ(船舶用ディーゼルエンジン) ・株式会社アド・ダイセン(ダイレクトメールの会社)
株式会社アド・ダイセン(ダイレクトメールの会社)
- 生成AIの利用
  - GenUで議事録を作るところから始め、分析ツール・スケジュール作成ツールの利用も開始したがテキストでアウトプットされても業務につながらないため、以下のようにExcelへのOutputにした
  - 既存ツール -> json -> GenU (Python) -> text -> excel
- 非エンジニアにとっては事務X生成AIxPythonは0から1にするものであった
- この流れから、ただエンジニアがやってくれるのを待つだけだったのが非エンジニアからも提案するように変革した
株式会社マキタ(船舶用ディーゼルエンジン)
- BI, チャットボット、メール管理すシステムなどを内製開発
- 過去事例の確認・法令調査の難易度が高く、属人化していた。AIチャットボットはプロンプト作成のコストが高かった。⇒ AI Agentで負担の少ない支援AIを作成したい
- Amazon Bedrock
  - 開発未経験でもハンズオンなどを模倣・AIへ細かく質問を繰りかえし1日で達成
  - 月1万円