以下の内容はhttps://ozaki25.hatenadiary.jp/entry/2025/06/25/175049より取得しました。


「AWS Summit Japan 2025(Day1)」に参加してきました

感想

  • 初参加でしたが参加者があまりに多く驚きました
    • 普段行くカンファレンスの10倍以上いたと思う
  • セッションのバリエーションも多て、事例を聞くのが好きなのでひたすら事例でたくさんの話が聞けてよかったです

基調講演 ビルダーと描く新たな価値創造

柳澤 花芽 氏 株式会社野村総合研究所 代表取締役 社長
ケイト ジェンセン 氏 Anthropic 上級副社長 グローバル営業統括責任者
田中 昭二 氏 三菱電機株式会社 AI戦略プロジェクトグループ プロジェクトグループマネージャー/DXイノベーションセンター 副センター長
松本 勇気 氏 株式会社LayerX 代表取締役CTO
ラフ―ル パサック Amazon Web Services Inc. バイス プレジデント、データおよび生成 AI マーケット戦略担当
白幡 晶彦 アマゾン ウェブ サービス ジャパン合同会社 代表執行役員社長

製造業での Agentic AI による改革推進: 三菱電機エンタープライズアジャイルAmazon Bedrock 事例

徳 隆宏 氏 三菱電機株式会社 AI 戦略プロジェクトグループ 改革推進部長
塚田 真規 氏 三菱電機株式会社 デジタルイノベーション事業本部 AI 戦略プロジェクト 基盤整備部 基盤整備部

  • 経営課題にAIを活用している
    • 人のパートナーとして使えるレベルまできた
  • AI CoE組織が基盤を提供している
  • ノンコア業務を効率化
    • 浮いたリソースをコアな領域にあてて高度化
  • scrum@scaleで複数部門でのAI活用を管理

アイウエア接客の未来を拓く〜生成 AI で進化するあたらしい店舗体験への挑戦~

松田 真一郎 氏 株式会社ジンズホールディングス AI 推進室 常務執行役員
黒尾 玲奈 氏 株式会社ジンズ AI 推進室 プロダクトマネジャー

  • AI推進室3名からスタート
    • 2025年をJINSのAI元年に
  • ユーザの分からないをAIで解決させたい
    • 店内で迷ったとき
    • フレーム選び
    • レンズ選び
  • ターゲットを店頭に絞った
    • 性質上ECもあるが店頭での購入が多い
  • 機能
    • 画像で似たメガネ検索
    • チャットで自由質問
    • 回答は多言語で
  • 技術
  • エンドユーザ向けのAIサービスを作るにあたって
    • AIの人格設定
    • 回答精度の向上が大変
      • Bedrockの中でグラフ構造のワークフロー
      • 意図判断ノードが重要で最新のモデル
      • フレームやレンズなどさまざまな情報のRAGノード
    • ハルシネーション/ガードレール
      • 関係ない質問に対する入力のバリデーション
      • 出力も失礼がないようにバリデーション
    • ガバナンス
    • そもそも使ってもらえるのか
  • ローンチ判断
    • 社員で検証
    • 最後は社長の判断

大塚製薬の DX による診断イノベーションへの挑戦

大橋 達朗 氏 大塚製薬株式会社 診断事業部 執行役員 事業部長

  • 診断事業部
    • 研究開発から生産販売までやってる
  • 2010年代からデジタルヘルスの取り組みをしている
  • 問診式の検査からアプリを使った検査へのシフト
    • 20分かかっていた検査が3分に
    • 検査者によるばらつきの防止
  • AWS上での医療機器プログラム
    • 血液がん遺伝子検査
    • 遺伝子のゲノムデータ
      • 130億文字
      • その中からエラーを発見する
      • 1つの検査で10GB程度のファイルができる
      • それらを最大100並列
      • 年間で100TBオーダー
    • AWSを選択
      • 並列処理のためのスケーラビリティ
      • 個人情報を扱うセキュリティ
      • 安定稼働のための耐障害性
        • 24h365の監視

国内金融業界初: AWS 上での勘定系システム移行の成功と次世代バンキングの展望

市村 元信 氏 SBIセキュリティ・ソリューションズ株式会社 取締役社長

  • 次世代バンキングシステムの開発
    • 日本で始めてAWS上で稼働した勘定系システム
    • 2024/7
    • 東京/大阪のオンプレミスデータセンター
    • 大規模災害時の事業継続性
  • ビジネス的な観点
    • 地方創生戦略の一環
    • 地銀に利用してもらうサービス
      • 地銀のITコスト削減
  • システム構成
    • コンテナベースでフルスクラッチで開発
    • マルチリージョン/マルチAZ
    • AWS上にセキュリティのルールを作り込んだ共通基盤
  • レジリエンス
    • ノード障害は1分
    • プライマリリージョン障害は1時間
    • RPOは計画切替なら0秒予期せぬときも1秒以内
    • マネージドサービスの仕組みを活かして実現
    • どこにデータを置くとどこをどう切り替えられるか整理
    • 目標ベースで実現するための構成を検討した
  • クラウド障害
    • めったに起きないけど起きることはある
      • 予兆連絡が来て対応するケースも
      • 連絡なく落ちることも
    • クラウドといっても障害は起きる
    • 障害が起きる前提で対策を用意しておく
  • オペレーション
    • 運用作業の自動化
    • 人の判断の迅速化
      • 迷わないような作業内容
    • AWS Incident Detection and ResponseでAWSのシステム状態の監視や相談

日本生命の次世代型お客様サービスの構築 ~生成 AI 活用で生保基幹業務を革新~

矢野 智郎 氏 日本生命保険相互会社 DX 戦略企画部 上席専門部長

  • 保険の契約事務
    • 求める品質が高い
    • 紙の業務が残っている
  • DX推進
    • 従来は定型業務のシステム化が中心
      • 利用が少ない領域は投資対効果が見合わない
    • 生成AIが出て非定型業務にも手を出せるように
      • 定型業務の完全自動化も目指せる
    • レゾリューションライフ社との協業/完全子会社化
      • 独自にRAGを作っている
      • AWS上に移してサービス化して使おうとしている

電力システムなのに毎週リリース!? ENEOS が考える内製開発の価値とポイント

原田 耕佑 氏 ENEOS ホールディングス株式会社 AI イノベーション部 デジタル事業開発グループ グループマネージャー 博士(光学)

  • 電気業界
    • 電力の需給を常に均等に保つ必要がある
    • 電力自由化で事情も変わってきている
  • 内製開発で作ったもの
    • 蓄電池の運用システム
      • 市場価格の予測
      • 入札計画
      • 充放電計画
  • 体制
    • 最初は2020年頃2,3人のチームで研究開発の1つとして
      • 実際手を動かすのは業務委託
    • 2021年頃から半内製でシステム開発を始める
    • 2023年から蓄電池の案件で内製で始める
    • 今は運用改善のフェーズで脱属人化を進めてる
  • アーキテクチャ
    • Lambdaを活用しサーバーレスに
    • 対抗先ごとにVPCを分離
    • AWS Security Hubで設定監査/脆弱性権と
    • Amazon Verified Permissionsで認可
    • Terraform + GitHub Actionsでインフラ自動化
  • AWSのサポート
    • AWS Countdown Premiumの利用
    • リリース前後のシステムをさまざまな視点でレビューしてくれる
    • 設計内容や運用周りも
    • 仕様のレビューもしてくれる
    • 担当がついてやりとりできる

AWS と共につむぐマイクロサービスプラットフォーム ~エネルギー企業の内製開発チームが大切にしていること~

杉山 祐介 氏 東京ガス株式会社 リビング戦略部 デジタルプロダクト推進グループ Software Engineering & Strategy Lead
迫田 賀章 氏 東京ガス株式会社 リビング戦略部 デジタルプロダクト推進グループ

  • 内製開発のきっかけ
    • エネルギー小売全面自由化
      • 電力もガスも
    • ユーザがどこから買うか選べる状況になった
      • 選んでもらう立場になった
    • 変化に対応して素早く価値を届ける必要性
    • ビジネス/クリエイティブ/テクノロジーの距離にこだわった組織
  • myTOKYOGAS
    • ガスや電気の料金や使用料を確認できるサービス
    • UI周りを中心に内製で刷新
    • マイクロサービスで作った
  • アーキテクチャ
    • FE - BFF - BE - 基幹システム
    • FEとBFFを内製
    • BEは東京ガスiネットが担当
  • 内製開発での課題
    • 会員/契約/料金などのデータを扱うために複数のバックエンドAPIを呼ぶ必要あり
      • それらを統合整形して使っていかないといけない
    • この処理をあらゆる場所でやらないといけない
      • BFFで吸収して各FEで使えるようにした
      • ただしBFFにドメインロジックが入ったことで肥大化していった
      • 今後新しい利用者が出てくることも想定できる
    • BFFのドメインロジックを分離してマイクロサービス化
  • マイクロサービスプラットフォーム
    • EKS上でアプリが稼働
    • GitHub ActionsでECRにデプロイ
    • armベースのAWS Graviton搭載のインスタンスを利用
      • コスト効率がいい
      • 消費電力が小さいという点もある
    • Bottlerocketによる運用負荷軽減
    • Karpenterによる柔軟なスケーリング
      • k8sクラスタ内のノードライフサイクルを管理するOSS
      • スケールさせたりをコードで管理できる
      • podを見て最適なインスタンスを使ってくれる
      • Karpenterそのものを動かすノードが必要
      • Terraformで扱うためにはひと手間いる
        • CloudFormation向けのものが公式であるのでそれを書き換えて使う



以上の内容はhttps://ozaki25.hatenadiary.jp/entry/2025/06/25/175049より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14