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

はじめに

AWS Summit Tokyo 2024が2024.6.20-21に開催されました。
一部セッションは7.5 19:00まで動画が公開されています。

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

Room L

生成 AI を活用したソフトウェア開発の効率化

• スピーカー：三菱電機株式会社　田中 昭二様、長峯 基様
• 課題
  • ソフトウェアの技術選定・開発プロセスの選択は、各製作所が担っている
    • 個別に開発プロセスを改善するにはリソースの確保が難しい
  • 生成AIを用いて、標準的な環境の提供によって統一的に品質を担保したい
• 行った施策
  • ユースケース発掘
    1. 社内で現状業務と課題確認
    2. それをもとに、AWSがユースケースアイデアを提案
    3. 三菱さんとAWSで評価して絞り込み
  • 依頼内容に応じた仕様書・コードの抽出（検証）
    • 製品開発部門からの改修依頼に対して、関連記事や影響範囲を生成AIで抽出させたい
      • そのために、図や表・インデントなどの視覚情報・社内の暗黙知が多い開発資料をClaude 3を使ってメタデータ付与

次世代自動運転のための LLM 開発：大規模モデル学習とエッジデバイス環境の実現

• スピーカー：Turing株式会社　山口 祐様
• 前提
  • 自動運転の実現方法には以下がある
    • 多数のセンサと事前に計測したマップを組み合わせて車両を制御
    • 主にカメラ映像のみで周囲を認識し、運転操作を行うVision Centric方式
  • Turing社は、Vision Centric方式で開発
• 課題
  • 難しい運転状況は発生頻度がすくない
• 行った施策
  • GPT-4で車を動かす
    1. カメラで撮影した情報を、既存の画像認識モデルで言語化
    2. 音声指示とプロンプトを用いてAPIで渡す
    3. APIからの戻り値を元に指定座標へ自動で車を移動
    • LLMをそのまま使うことは難しく、学習が必要
  • 視覚情報と結合した言語モデルの学習
    • 画像-言語のペアのデータセットを学習し、画像と言語を入力するモデルを作成
    • 上記モデルに対して、人間の自動車運転走行データで追加学習
      • マルチモーダルIA「Heron」の開発

Room M

「魔の川」「死の谷」を内製開発で越境する 〜ガス会社が挑むエネマネサービスの開発〜

• スピーカー：北海道ガス株式会社　栗田 哲也様、國奥 広伸様
• 課題
  • 市場ニーズに沿ったサービスの内製開発
    • 設備をIoT化することで、温水・冷水による空調機器のパラメータを柔軟に変更し省エネにつなげるサービス
• サービス開始までの道のり
  • 乗り越えなければならない障壁
    • 研究->開発：市場ニーズと技術シーズの不一致（魔の川）
      • 課題
        • 外部ベンダーではリードタイム・コスト面で問題あるため、内製化
        • 内製化でも、大きな投資ができない、少人数、インフラ知見なし
      • 取り組み
        • ボトムアップ
          • 技術系の社内サークル立ち上げ、技術取得、知見獲得
          • Working Backwordsでサービス企画を実施、上長に相談しコンセンサスを得る
        • 若手熱量と経営ミッションが合致し、開発スタート
          • 内製開発の課題は主にクラウドで解決
        • PoC成功に向けて
          • 突破力を持たせる
            • 好きな分野を突き詰める、トライ＆エラーを繰り返す
              • デバイス、通信、クラウド
          • 共通レイヤーを持たせる
            • 朝会で取り組み・ナレッジを共有し、ディスカッション
              • 先の「デバイス、通信、クラウド」のナレッジ共有
    • 開発->事業化：リソース不足や外的要因（死の谷）
      • 6つの苦労
        • 開発体制
          • 半導体不足リスクやコスト面から、デバイスメーカーと協力しデバイス開発
            • 従来の請負契約では仕様変更時に時間とコストがかかる
              • 発注者として覚悟をもって、準委任契約
          • アジャイル開発を採用
            • 最初は見積もりが甘かったが、徐々に安定
            • 不確実性が減り、高価値の作業に集中
        • セキュリティ
          • 事業部門にてIoTのセキュリティ評価基準を研究・調査・初案策定し、IT部門と相談し具体化
            • IPA -> CCDS -> AWS Well-Archi
        • 遠隔制御・遠隔アップデート
          • AWS Iot Device Shadowを採用し、多数のゲートウェイを状態管理
        • 画面開発・認証
          • Amazon Cognitoを採用し、Webアプリのセキュアな認証、ログイン画面を実現
          • Amplifyフレームワークを活用し、AWSサービスと連携
        • システム構成管理～運用開発負担の軽減
          • AWS CDKで、インフラのコード化と自動構築の恩恵を得る
          • Amazon CodeCatalystでCICD導入、テスト・リリースまで自動化
        • プログラミング
          • ペアプロ/モブプロを実施し、スキル・経験不足の解消
          • Amazon Q Developerを導入、AIによるコーディング支援
          • Amazon Bedrockを導入、プログラミングエラーの解決等に活用
    • 事業化->産業化：市場競争・自然淘汰（ダーウィンの海）
      • BizDevOpsに取り組み、競争力強化/顧客要求への迅速な対応/ニーズの正確な把握
        • 顧客要望の実装はAWSで実装することで、素早く柔軟に実現
          • デバイス側では時間がかかる

リニア中央新幹線における設備 IoT 化に向けて～データドリブンによる徹底的な省人化の実現～

• スピーカー：東海旅客鉄道株式会社　宮本 真樹様、藤原 海渡様
• 取組み
  • 状態監視保全を、人力中心からICT中心にして、データドリブンな運営に
    • 現在PoC中
• 状態監視の取り組み事例
  • 保守用車リアルタイム状態監視
    • 始発走行前に線路内の状況を走行しながら確認する車　が対象
    • 背景
      • 不具合発生時の早期復旧
        • 従来は保守用車のユーザーが電話で状況報告
      • 重大な事象につながる前に、その兆候をとらえたい
    • 取り組み事項
      • 採用サービス
        • AWS IoT SiteWiseで、リアルタイムデータ取得
        • Grafanaで取得データの表示画面作成
          • 現場からの、自分たちでいろんな画面を作りたい、という要望に適う
          • アラーム機能で、異常変化を監視
        • S3+QuickSightで、取得した大量データを蓄積、可視化
      • 意識したこと
        • 自分たちで対応。都度ベンダーへの依頼は回避
        • 重要な要件はまず実装
          • 使ってみることで気づくことが必ずある。要件定義に時間をかけすぎない
  • 開閉器動作音による異常検知
    • 電源の「入」、「切」をするスイッチ
      • 鉄道会社が用いているものは巨大
      • 動作音からの異常検知手法を独自開発
        • 従来は電圧や電流などで異常検知
    • 背景
      • 労力・コストをかけない設備保全が必須
        • 労働人口の減少、設備数が膨大
    • 取り組み事項
      • 採用サービス
        • AWS Sagemaker Pipelines
          • 機械学習を自動化
          • 推論と、推論に使うモデルの作成、の両方を行う
        • Amazon QuickSight
          • 推論結果を可視化
      • 意識したこと
        • だれでも、どこでも使えるように
          • ICTが苦手な人でも使えるように
        • スモールスタートとプロトタイピングの活用で、スピード感を高く
          • 成果を示し、理解を得る
    • 得られたもの
      • システム構築
        • セキュリティ制限がある中で各サービスとの連携を実現
      • MLOps
        • 将来の機械学習運用を考慮した設計

Room O

創薬を加速する第一三共のセルフサービス型クラウド基盤　～モブワークで挑む基盤内製と人材育成の両立～

• スピーカー：第一三共株式会社　岡本 敦之様
• （”モブワーク”という言葉は英語ではよくない模様）
• 背景
  • 医薬品開発は、長期間・高額・低成功率
    • 10年以上、数百億～数千億
    • 成功確率は年々低下（20年前は1/1.3万、現在は1/2.3万）
    • 発見した55万化合物のうち、臨床試験をパスするのが24化合物
  • ディスカバリー研究の向上
    • 薬の種を見つけて、磨き上げて、非臨床試験・臨床試験に使える物質（開発候補物質）を創出するプロセス
    • 開発候補物質の素質、成功確度が価値
  • 開発候補物質をどれだけ早く出すか
    • 使うデータが高度化、膨大
      • 高機能な機器が出力するデータ（TBオーダー）
      • 患者層別／個別化によって、必要なデータが多様化／高度化
    • ディスカバリー研究を中断したデータを利用して効率的に進める
  • データ活用に向けてディスカバリー研究を変革
    • データの属人化、サイロ化の回避
      • 実験データ産生と同時に特定の場所に保管
    • 実験の、計画などのメタデータと産生されるデータを連結
      • 新たな実験系構築時は、ITシステムも同時に構築
    • 生データから最終データまで紐づけ
      • データプロセスパイプラインの構築
    • 再利用時のデータの信頼性を担保
      • 創出部門がデータの品質を確保
• 今までの活動と振り返り
  • 現在までの道のり
    • 第一三共RDノバーレから第一三共に要望
    • 第一三共Global DXはITシステム外注というビジネスモデル
    • ノバーレ側で社長コミットの下、独自活動しつつ継続的にコミュニケーション
  • 基盤の主要件
    • スピード
      • 短い期間の変化に対応できる必要あり
      • セルフサービス型
    • 柔軟性
      • 一般研究、ゲノム、外部コラボなどができる必要あり
      • 用途に合わせたマネージドサービスの利用
    • セキュリティ
      • 社内システムと同等のセキュリティ対策
    • 透明性
      • 監査証跡の改ざん防止、監査担当者チェック
  • 構築した環境
    • アーキテクチャ
      • AWS Control Towerを利用したランディングゾーン設定
      • AFTによるIaCの実現とアカウントベースライン設定
      • ハブ＆スポーク型ネットワークトポロジー
    • 将来自分たちで運用していく前提
    • 自律的に学び、共通の理解を固めて属人化を回避
  • 構築タイムライン
    • AWS基礎の学習　構築するアーキテクチャの確認（2023.7）
      • 基礎トレーニング
      • ワークショップ（AWS ProServe）
      • 実機操作
    • 詳細設計の確定　構築開始（2023.10）
      • チーム編成
      • ワークショップ（AWS ProServe）
      • モブワークによる構築
    • 構築本格化　運用課題整理（2023.12）
      • 自主勉強会開始
      • モブワークによる構築
    • 構築完了　運用課題対応・運用開始（2024.4）
      • チーム再編
      • モブワークによる構築
  • 起きた変化
    • モブワークに対する考え方
      • 最初はギクシャク。次第に価値を理解し自律的に成長
      • モブ（ペア）での作業が人材育成方法として認識
    • AWS Professional Serviceとの協業の仕方
      • 最終的にドキュメント作成してもらわず、モブワークへ参加
      • 結果的に納品物無し
    • 第一三共Global DX
      • 他の部門でも内製化が避けられないという認識に至る
  • 重要だったポイント
    • 小さい別会社が起点
      • 社長コミットの下で先行着手できた
      • キャリア採用も独自に実施
    • 形として見せることが重要
      • Capabilityの拡充をアピール
      • 段階的に構築・可視化してステークホルダーのフィードバックを得る
    • 継続的なコミュニケーション
      • 地道に現場のサポーターを拡充
      • キーパーソンとのコネクション
      • AWSからキーパーソンへのインプット
• 今後の展望
  • ディスカバリー研究への価値提供
  • CCoEチームの進化
  • ディスカバリー研究以外への拡大

イオン生活圏を支えるシステム基盤と決済を担う当社の取り組み

• スピーカー：イオンフィナンシャルサービス株式会社　光石 博文様
• 内容：今まで作ってきた大量のシステムをどのようにクラウドに載せていくか
• システム基盤の高度化
  • イオンのシステム基盤の歴史
    • ～2017年：オンプレミス個別基盤
      • SI提案の基盤の上に構築。ベンダーさんごとに別々
        • SIさん独自の別々の開発標準
        • 運用品質など統一できず
    • 2018年～2021年：オンプレミス統合基盤
      • イオン管理のデータセンターに統一、統合基盤化
        • 独自の開発標準を作成（用語レベルまで含め）
          • 品質向上の恩恵
        • VMWareを利用
      • 基盤とアプリケーションを分離
      • 基盤のSIとアプリのSIを分けてそれぞれコンペ
        • システム本部がマルチベンダコントロール
        • 境界線を引かないで一緒にやっていくカルチャー
      • 既存のシステムもすべてこれに載せ替え
        • 100越のシステム、1000超のサーバーを統合基盤化
        • 統合による効率化
    • 2023年～：クラウド基盤
      • クラウドシフト
        • セキュリティ強化
        • ベンダー価格競争力を創出
      • AWSを中核として位置づけ
        • Azure、Google Cloudも利用
          • 4社以上になるとコストが高くなる
      • オンプレミス環境とクラウド環境はネットワーク接続プラットフォーム上で連携
      • クラウドも含めた統合運用基盤を構築、運用品質向上
        • これまでのオンプレ統合基盤ツールは廃止
          • 運用担当がどこにいても管理可能
        • 利用サービス
          • システム監視・ログ管理：DATADOG
          • インシデント管理：servicenow
          • その他サービスを利用
  • クラウドシフトの進め方
    • 150システムをロードマップ化して、複数年で年間計画
      • 毎年、クラウドベンダーとSIerをコンペ
        • ごちゃまぜによる問題は、今のところ無し
      • VMWwareのライセンス体系変更のため、クラウドシフトを前倒し
  • クラウドシフトの課題
    • コスト削減はできない
      • オンプレでの基盤更改とクラウドでは、5年では価格差さほどなし
    • Oracle問題
      • ほとんどOracleDBで作っていた
      • Oracle社とクラウドベンダーが仲悪い
        • 初期はサポート得られず
        • 少しずつ雪解けムード
    • メンテナンスによる停止
      • クラウドベンダー都合によるメンテ
        • 重たくなったりスパイクしたり
        • メンテは米国時間深夜＝イオン書き入れ時
        • アプリ側で努力、SLA調整などで、現時点では概ねクリア
    • オートスケール問題
      • （イオンレベルの）急激なアクセススパイクには対処できない
        • 「負荷前にスケール」では、オートとは言えない
  • グループ統合（計画中）
    • AFSグループ・イオングループで整備した基盤をシェア
      • 主要メリット：コスト削減、運用品質向上、セキュリティ強化
      • 統合運用チームが各社システムも運用
• DXの取り組み
  • キャッシュレス推進
    • 諸外国（アジアなど）に比べて遅れている
    • AEON Pay決済基盤
  • マーケティング促進に向けたデータ活用
    • クラウドDMSへの移行
    • マーケティング情報の一元化やリアルタイム連携を実現
      • パーソナライズドマーケティングへの活用
    • ASEAN域内へも展開
  • AEON WALLETリニューアル

おわりに

取り急ぎ、事例セッションを見てまとめてみました。
テーマとしては生成AIが多かった印象ですが、自分は内製化やCCoE、クラウドリフトなどに注目していました。
この記事がどなたかのお役に立てれば幸いです。