AWS Summit Japan 2026の事例セッションを個人的にピックアップ

はじめに

先月、AWS Summit Japan 2026が開催されました。例年同様、セッション動画が公開されています。

検索する際は、以下の資料ページに記載のコードを検索キーとして指定すると、楽に見つけられます。

その中で自分が気になったセッションを備忘録的にまとめました。

まとめ

AIM146 ランサム危機を転機にーアスクルが加速させた AI-DLC

• スピーカー
  • 吉岡 晃 様
    • アスクル株式会社 代表取締役社長CEO
• 内容
  • ランサムウェア感染からの復旧と、それを機に導入したAIーDLCの効果
    • ランサムウェア復旧までも道のり
      • 侵害エリア、侵害無しエリア
        • どのエリアが侵害されたか
          • 一部オンプレ
            • 物流システム：全物流センターがストップ
            • 社内システム
          • 一部SaaS
            • お問い合わせ管理システム
        • 侵害無し
          • クラウドエリア
            • 基幹業務システム
            • フロントシステム
            • その他システム
      • 当時の復旧への判断軸
        • 01.被害の拡大防止
          • お客様の仕事、事業、システムを止めてはいけない
        • 02.安全かつ安心な再開
          • 復旧、再開後に、もう一度使って安全なのか
        • 03.一刻も早いサービス再開
      • いつ、何を判断したのか
        • 発生4日目で進むべき道を確定
        • 25.10.19 発生当日
          • AM 発覚
          • 対策本部設置（14時）
            • 本部長をCEO
              • 基本的な大方針
                • 本当にGOするのか：サービス、順序、プレスリリースの中身
            • 各部を設置、責任者を任命して権限移譲
              • IT復旧部会
              • 事業継続部会
          • サービス停止(売上がゼロになる判断)
            • ネットワーク遮断
            • ご注文、出荷停止
            • 透明性高い情報開示
              • ランサムウェアであることを当日にプレスリリース
              • ありのままに正直に、適宜発信
        • 25.10.23
          • 自力で再構築（侵害の範囲が特定できたので、判断できた）
            • 攻撃者とは接触せず
              • 企業倫理、再攻撃抑止
            • AWSクラウドへの移行
      • AWSクラウドとAIで再構築
        • クラウド移行：1週間
        • AI活用で再構築：2週間
      • 自力構築から全面復旧まで
        • 新ネットワーク構築：28日後
        • 物流拠点の全面復旧：108日後
          • 全国に10か所の物流拠点で時間がかかった
          • 理由
            • サーバ、PCで7,000台以上：物理的な機器が存在
              • 一つ一つ除染、更新
                • これを1日で行う必要あり
            • 拠点ごとにOSのバージョン等が異なる
          • 学び
            • 現場機器は詳細な仕様管理と継続的な更新が不可欠
              • 今後のBCP対策として不可欠
    • AI-DLCへの挑戦
      • 復旧作業と並行して、限られた人員で新たな価値創造
        • AI-DLC（AI-Driven Development Life Cycle）で仮説->判断の速度が劇的に向上
          • 人が目的と仮説を指示
          • AI(kiro)が高速で　調査・生成・提案
            • 課題発見・解決策設計・価値提供
          • 人が判断し方向を決める
        • 方針決定以外をAI主体で
      • 小さな事例から挑戦、事例づくり
        • メルマガ、広告
        • ビジネス側、エンジニア側も参加
        • 小さな成功体験で、体感知を得られる
      • 挑戦１：品揃えスピードを超速にする
        • 課題
          • 商品をつかさどる商品担当が、色々な関係者の窓口になり、色々なツールを使って管理している
          • 人に暗黙知が集中、低スピード
        • あるべき姿を設計
          • データ、ツールを一元化して、その中で連携させる
          • それをスクラッチで開発
          • 商品担当は本来業務に注力
        • AI-DLCで、ビジネスメンバーとエンジニアが一体で推進
          • 一同に会し、その場でAIに壁打ち、フィードバック、即断即決
          • エンジニア側のビジネス理解が深くなる
        • 結果
          • 開発期間：50%短縮
          • 商品掲載スピード：2倍
      • 挑戦２：ナフサ機器による供給不安を緩和する
        • 課題
          • どんな商品が枯渇するのか
          • どんなお客様へどれくらいの供給が必要になってくるのか
            • 供給元に早めに調整可能
        • 対応
          • 方針決定もAI-DLCに任せる：需要分析から提案まで
            • 従来の人出であれば2週間
              • 需要分析、世界情勢分析、商品・お客様特定、提案資料作成
              • 上記が直列で、各フェーズで要レビュー、手戻り、待ち時間
            • AIで、3時間
              • 各々が高速
              • 各々が並列に実施
              • AIの中で連携、レビュー
              • 人間は、AI-DLCで構築したメカニズムと対話しただけ
        • 結果
          • 厚労省備蓄の医療グローブの対応
          • シンナーの直接供給の対応
      • 学び：AI-DLCを成功させる4つ
        • 目的目標を共有し覚悟を決める
          • 何のために何をしようとするのか
          • 本丸に行くのであれば、本丸を捨てる覚悟
        • 全関係者を巻き込む
          • ビジネス側とエンジニアが一体化して動く
          • 重要案件ほど、エースを投入する
            • 会社の本気度が周りに渡る
        • 現場に権限と責任を委譲する
          • 目的と目標、明確なビジョンを共有後、権限移譲でスピードが加速
        • AI活用に十分な環境を整備する
          • エンジニアが安心して開発できる環境
          • それらに投資

ANT325 LINEヤフーが挑む大規模 DWH 基盤のクラウド化の軌跡 / LINEヤフー株式会社

• スピーカー
  • 田中 章宏 様
    • LINEヤフー株式会社
• 内容
  • オンプレミスのデータウェアハウスで管理していたデータを、Amazon Redshiftに移行
    • サイズ：3PB、ユーザ数：約3,000、クエリ/日：約7.25億
    • CTOからの「新技術と比較しているか」の指摘がスタート
      • 技術面、コスト面で比較評価
      • PoCを1年半経て、決定
  • PoC
    • PoC クライテリア(技術検証項⽬)
      • 機能要件や、一般的な非機能要件では差がでない
        • 性能要件での検証に注力
      • クラスタ別に、性能検証に使う代表クエリ群を選定
        • クエリタイプ、クエリの複雑さ、データ量で分類して選定
      • 必要なデータをすべて移行した状態で検証
    • 結果
      • SELECTは早いが、大量行のインサートや特定の術語を含むクエリは極端に遅い
        • クエリ書き替えで対処。書き替えコストも移行工数としてTCOへ加算
  • 移行
    • アーキテクチャ
      • 2つのVPC：Redshift用のVPC（豊富なIPアドレス空間）と、エンドポイント用のVPC
      • クラスター間でdata sharing構成することで、データコピーなどが不要
    • 性能課題
      • 「負荷の高い時間帯に、高負荷のクエリのレスポンスが担保されるのか」
        • 疑似的に再現して検証
          • 当初想定の構成ではレスポンスが2倍以上に
      • 改善
        • 許容できる条件を定義：「95%が現行以下」「平均応答時間が現行以下」
        • Multi-AZと自動ワークロードマネジメントで性能向上
          • Multi-AZ側にSecondaryクラスタがActiveで実行
            • Primaryのキュー待ちが多くなると（可能なクエリのみ）Secondaryにルーティング
        • 最適な構成を模索
          • クラウドサービスなのでリサイズして検証が容易
          • ノード数と予算の兼ね合いを模索
  • 恩恵
    • 全体で高速化：26%
    • クラスタ構築スピード向上：CloudFormation活用
    • 物理メンテからの解放
    • AWSエコシステム利用

IND215 三菱UFJ銀行のオントロジー×ナレッジグラフを活用した海外事務プロセスの効率化

• スピーカー
  • 溝口 直樹 様
    • 株式会社三菱UFJ銀行 執行役員 国際事務企画部長
• 内容
  • オントロジーとナレッジグラフを活用して海外事務プロセスを効率化（標準化・集中化・自動化）
    • 約30か国　3,000人超が、一日20万件の取引をシステムに記帳入力
      • 送金業務が約8割
    • 事務プロセスを標準化し、インドに集中化し、自動化していく
      • 国ごとにQCDのバランスが大きくばらついている：事故発生率・事務経費・取引件数
        • 各国の商慣習や規制等に対応してきた結果
    • 事務プロセスの標準化に着手
      • 以前から行ってきたが、苦戦続き
    • 事務標準化の難所
      • 各拠点の固有手続きが膨大
        • 本部作成の、抽象的な標準手続き（600ページ）
        • 各国固有の、具体的な手続き（1拠点当たり数百～数千ページ）
          • 方法や担当など、具体的なプロセスが規定
          • 各国でプロセスが異なる / 同じであっても表現が揺れている
      • 熟練した知見者のリソースに制限
        • 以下作業を、従来は知見者の人海戦術で対応
          • ①フローチャートを作成
          • ②他拠点のフローチャートと比較
          • ③関係者協議
          • ④プローチャート修正
        • AIで①、②、④を代替
    • AIフローチャートの難所
      • プロトタイプの品質不芳
        • 生成AIがプロンプト・手続きを誤って理解し、的外れや不正確なフローチャートが散見
          • カラフルなだけのフローチャート、過度に単純化した短いフローチャート、複数人を一人と読み間違える
    • AWSからオントロジーとナレッジグラフの提案
      • オントロジー
        • 概念と関係性を、ノードとエッジで定義した、設計図
          • 本部の標準手続きを表現
      • ナレッジグラフ
        • 実態と関係性を、ノードとエッジで定義した、実データ
          • 上記のオントロジーを通して、各拠点の事務プロセスを表現
        • グラフ化することで、AIで比較可能に
    • オントロジー・ナレッジグラフを構築する流れ
      • 生成AIで本部標準手続きをトリプル（主語・述語・目的語）に分離
      • 知見者がトリプルの分類を確認・修正
      • 知見者がトリプルの欠落・不足を補充
      • トリプル一覧からオントロジーを構成（AWSによる支援）
        • 約２万件のトリプルから生成
      • ナレッジグラフを構成する拠点固有手続きを選定
      • ナレッジグラフを構築（AWSによる支援）

MAM202 創業 100 年の酒屋カクヤスが挑む、生成 AI で実現するシステム革命

• スピーカー
  • 石井 伸明 様
    • 株式会社ひとまいる グループシステムサービス部 特命担当
• 内容
  • 業種変更に伴う、基幹システム刷新
    • 酒類卸から物流業へ
  • 課題
    • 30年間動き続けたシステムは、建増しを重ねて膠着化
      • VB.NET、Oracle初版
      • 自社ではわからず、保守ベンダー依存
    • 基幹システム
      • 画面 2,200
        • 誰も全数を把握していない
      • テーブル 3,000
        • 命名規則は時代ごとに揺れ
        • 意味の重複が常態化
      • ストアド 1,200
        • 業務ロジックの大半がここに
      • 検証環境が本番環境と異なる
        • 本番環境
          • 毎日稼働し、停止不可
          • 30年分のバッチ
          • DBダンプしても、意味が読めない
        • 検証環境
          • 外部連携は停止
          • 部分的な検証のみ
          • 保守ベンダーの検証環境頼み
            • 自分たちで検証できない
  • 取り組み
    • ストアド
      • AI駆動開発：AIにて、ストアドを解析
        • Amazon Bedrockでロジック抽出
        • 依存・呼び出し関係を図表化
          • 「読めないコード」を読む手法を獲得
        • 本番Oracleと、AWS上に再現したOracleとで　元新比較
      • 業務駆動開発：AIの解読を現場の言葉に翻訳
        • 営業・商品・店舗・物流・経理の各部門の協力のもと、業務フロー作成
        • 業務フロー単位でストアドに意味を付け、要不要を判断
    • 画面
      • 画面の数は、業務の数ではない
      • AIと現場とでそぎ落とし：2,200から800に
      • 画面ではなく、業務として再定義
        • 200の業務フローとして再設計
    • 明確になった業務ロジックから、システム設計思想を定義
      • 以前はクライアントが低スペックであったため、すべてDB側で計算
      • 新設計思想
        • 金銭計算とテーブル間移動は、ストアド
        • データの登録・フラグの変更は、人が画面から実施
  • 用いた技術
    • Claude Code on Amazon Bedrock
      • プロンプトの資産化
        • セキュア環境下で生成AIを実行
        • プロンプトを共有・蓄積・継承
          • 個人技を組織知に変えていけた
    • Oracle on AWS
      • 元新比較を高速で実施
        • ストアドの挙動を本番と突き合わせ
        • 解読用の足場として利用
  • AI開発の感想
    • AIの癖・限界と直面
      • 自分たちでAIを動かす：外部知見より大事
      • 「記憶」は設計対象：AIは「覚えている」前提は通用しない
      • 「記憶」の補強：AIに思い出させる仕組みの構築
      • ルールの外部化：ルールはファイルに記述し、AIに参照させる
    • AI制御の確立
      • AIに「作らせる」と「説明・検証」をセットに
        • 何を参照して作ったのかを説明させる
      • AIに役割と経歴を付与
        • 思考の土台を定義
      • 二段階プロンプト方式
        • 業務要件から「”コード開発のプロンプト”を作るためのプロンプト」を作らせる
    • AIが解釈できる要件に整理
      • 5W2Hの型を定義
        • 依頼は本質的に、雑
          • 依頼者は、困りごとを完全に言語化できないため、翻訳作業が必要
        • 5W2Hで抜け漏れを機械的に発見
          • 属人化を排除し、誰でも再現可能に
      • 流れ
        • INPUT：雑な依頼
        • 構造化：5W2Hで構造化
          • 空欄になったところが、依頼者に要確認
        • OUTPUT：AIプロンプト
          • 目的・機能・入出力・制約を含むプロンプトに翻訳

おわりに

今年は、昨年以上にAIがテーマのセッションが多い印象でした。
都合がつかず参加できなかったので、例年より長期間アーカイブを配信してくれていたので、一通り確認することが出来ました。
この記事がどなたかのお役に立てれば幸いです。