AWS Summit JAPAN 参加報告(2024年6月)

AWS Summit JAPAN　

この記事について

梅雨入りをしなかなか過ごしづらい日が続いていますがみなさんいかがお過ごしでしょうか。たなべです。私は先日、AWS Summit JAPANに参加してきました。2日間の両日とも現地で参加して参考になる話を沢山聞くことができたのでお話いただいたことを自分なりに整理しながら少しまとめたいと思います。セッションの詳細などはオフィシャルサイトやiret.mediaの他の方の記事をぜひご参照ください。この記事では自分が大事だなと思ったことや感想などがメインとなります。尚、2024年7月5日まではオンデマンド動画が配信されているので実際のセッションを視聴することができます。

関連サイト

• AWS Summit Japan | 2024 年 6 月 20 日（木）, 21 日（金） オンデマンド配信中
• AWS Summit Japan 2024 | iret.media

AWS Summit JAPAN について

2024年6月20日(木)、21日(金)の2日間にかけて千葉県の幕張メッセで開催されたAWSが主催するイベントです。150以上のセッションと250以上の展示ブースがあり日本最大の “AWSを学ぶイベント” になっています。

AWS Summit JAPAN に参加した理由

今回、AWS Summit JAPANに参加しようと思った理由としては3点あります。まずはAWS Summit JAPANの基調講演をできれば現地で聞きたいと思ったこと。基調講演にはイベントのメインテーマや事業やサービスに関する方針も含まれています。日頃からAWSを使ったシステムの構築や運用を行っているのでぜひ聴いてみたいと思いました。2つ目は興味のあるセッションが沢山あったのでぜひ聞いてみたいと思いました。もちろん、オンラインでも聞くことはできますが、どうしてほ他の仕事のことや問い合わせの対応などあったりしてなかなか集中できないのも事実です。なので基調講演や各セッションの話しを集中して聞くためにもオフラインで参加することにしました。さらにもう一つの理由として、他の会社さんや参加者の方と直接話しをしたいと思ったことです。仕事が原則テレワークになり、会社の中でも直接色んな人と話しをする機会は減りました。ましてや他の会社の人と話しをする機会は担当している案件以外では殆ど無い状態です。AWS Summit はAWSという共通のテーマをもつ人が集まる場になるので、可能な限り色んな人の話しを聞いてみたいと思いました。そんな理由から今回は2日間、現地で参加することにしました。

事前登録したセッション

DAY1(2024/06/20)

DAY2(2024/06/21)

尚、DAY2(2024/06/21)の12:50~15:40の3つのセッションは事前登録はしたんですが諸事情で参加できませんでした。オンラインのセッションがあるようなので時間見つけて視聴しようと思います。

それぞれのセッションの概要と感想

セッションを選んだ理由とセッションの概要(というかキーワードレベルのメモ)、またそのセッションを通じで自分が理解できたこと、感じたことなどを各セッション毎にまとめていきます。

DAY1【KEY-01】基調講演　AWS と創る次の時代

このセッションを選んだ理由

AWS Summit JAPANに参加する理由の一つでもある『基調講演』なのでしっかりと聞きたいと思いました。そのため当日9時前には受付を済ませて指定席のチケットを頂きました。内容に関しては生成系AIが注目される中、AWSサービスや関連する機能がどうアップデートされていくのかの方向性みたいなのが聞けるといいなと思っていました。また Amazon.comのCTOであるヴァーナーボーガスさんの話しを直接聞いてみたかったというのもあります。英語はわからないので通訳頂いてですが。

このセッションでお話しされていたこと

• AWS Summit Tokyoの紹介
• AWSが目指す方向性を提示し、それを実現するための取り組みの説明
• 主に生成AIのテクノロジーを活用した課題解決、事業展開を行っている会社やサービスの紹介
• 『テクノロジストは社会問題を解決するためにテクノロジーを活用する』というメッセージ
• その中の一つに生成系AIがあり、ビジネス課題や生産性を向上させるために使われている
• コンピュータの進化と同じように生成系AIの進化も進んでいく

このセッションを通じて自分が理解できたこと、感じたこと

まずは目の前のお客さんやシステムの要件だけに注目するのでは無く、その先にある解決したいビジネス課題にフォーカスする必要性を感じました。またIT技術の進化は早いと認識していましたが、感じていた以上に生成系AIの進化が加速していくんだなと思いました。そのためしっかりと情報やトレンドを追いかけていかないと完全に取り残されるという危機感を覚えました。今年追加される2つのAWS認定試験もしっかりと手を動かして中身を理解した上で取得できるように頑張ります。

DAY1【AWS-01】Dive deep on Amazon S3

このセッションを選んだ理由

S3はAWSの中でも本当によく使うサービスですがチューニングや勘所みたいなのがあまりイメージできていなかったので、S3のアーキテクチャに対する理解を深めて今後利用する際に活用したいと思いました。また最近利用可能となったAmazon S3 Express One Zone についてはざっくりとした概要しか認識できていなかったので、サービスの理解度を深めて活用方法を知りたいと思いこのセッションを選びました。

このセッションでお話しされていたこと

• S3オブジェクトを作成する際のプレフィックスは大事。パフィーマンスに影響する。
  • プレフィックスの前半はできるだけばらけるように(カーディナリティを高く)
  • 後半は逆に日付など一意に特定できるように
• S3バケットのタイプは “General purpose buckets” と “Directory buckets” の二種類ありそれぞれ特徴や性能が異なる。
  • General purpose buckets
    • 汎用的なS3バケット
    • ストレージクラスも複数用意されている
    • マルチAZ(耐久性が高い)
  • Directory buckets
    • S3 Express One Zone ストレージクラスのみ利用可能
      • シングルAZ構成(耐久性は高くない)
      • パフォーマンス重視
• ディレクトリバケットの特性
  • ディスクIOを減らすことができる
  • MLトレーニングなど耐久性よりもパフォーマンスが求められる場合に効果的
• 『誤削除』への対策
  • 一括削除は危険。ほんとに危険。
  • 人の誤操作を完全になくすことはできないので緩和策が大事
    • S3バケットのバージョニング
    • S3オブジェクトレプリケーション
    • S3オブジェクトロック
    • S3バケットのバックアップ

このセッションを通じて自分が理解できたこと、感じたこと

バケットタイプ “General purpose buckets” と “Directory buckets” 違いをざっくりとでも理解できました。また新しいストレージクラスである “S3 Express One Zone” の使い所を知ることができた。要件があるようなケースでは積極的に利用を検討したいと思います。非常に大事だなと思ったのは『誤削除対策』ですね。システムを運用していく中で発生する作業ではあるので注意したいです。『経験を積むための圧縮アルゴリズムは存在しない』という言葉は確かにそうだなと思いました。

DAY1【AWS-22】AWS を活用した車載ソフトウエア開発ソリューションと自動車メーカー様事例

このセッションを選んだ理由

ガソリン車からハイブリッドや電気自動車、またMaaSや自動運転など大きな転換期にある自動車業界の開発現場でどういった課題があるのかを聞いてみたかった。また自分が担当している案件では自動車業界のお客様もいらっしゃるので活かせるノウハウなどがあればいいなと思いこのセッションを選びました。

このセッションでお話しされていたこと

• 自動車業界は大きな変革期にある。
• ハードウェアよりな仕組みからソフトウェアよりな仕組みにシフトしている
• それに伴いソフトウェアの重要性が増し、追加される機能や管理するコードの量が増えている
• ソフトウェア開発における課題
  • 一貫性のない開発環境になりがち
  • 多数のツールを利用し、環境のセットアップも複雑
  • フィードバックループが長い
  • ハードウェアに依存した開発になっている
• ソフトウェア開発の課題を解決するためのアプローチが必要
  • 仮想ECUによるハードウェアに依存しない開発
  • 柔軟でオンデマンドな開発環境
  • 先進機能の活用、最新技術の活用
• ECUもいくつかの種類がある
  • Powertrain
    • 駆動系の制御
  • IVI(in-vehicle infotainmen)
    • グラフィックやUI
    • 情報やエンタメ等の提供
  • ADAS(Advanced Driver-Assistance System)
    • 運転支援系の機能
• AWS上でAUTOSAR Classicプラットフォームを用いた開発ワークフローを構築
  • パイプラインの中で、MiL(モデルインザループ)テスト、コード生成、vECUのビルド、COSYMビルド、SiL(ソフトウェアインザループ)テストを実施
  • 成果物と結果はS3バケットに格納
• AWSの開発環境と実際に動かす車両の両方でArmを使えるとバイナリの互換性が保たれるので何かと助かる（環境パリティ）
  • 開発環境をArmで整えることのメリットの一つ
• QNX OSを用いいた開発環境の話し
  • BlackBerry QNX on AWS ワークショップも提供されている
  • CICD使ったテストも試せる
• BMW社やStellantis社の事例紹介

このセッションを通じて自分が理解できたこと、感じたこと

自動車業界のソフトウェア開発の現場でどういう事が行われているのかを知ることができた。ハードウェアを扱う産業では環境パリティを実現するためにArmを使う。Armを選択する理由はコスト削減だけが目的では無い。直接的にvECUの開発といった案件に携わる事は無いかもしれないけど非常に興味深い話しでした。自分も普段から自動車を運転するのでSDV(Software-Defined-Vehicle)の今後の発展に期待したいと思います。

DAY1【CUS-17】エンタープライズシステムが抱える課題とマイクロサービスアーキテクチャ

このセッションを選んだ理由

まずカインズさんはプライベートでもよく利用させてもらっているので非常に興味がありました。そしてエンタープライズ業界の事例としてマイクロサービスアーキテクチャへの移行をどのように行われてきたのか気になりました。また自分の業務の中でもエンタープライズ業界がターゲットの一つになっているので、ユーザ企業さんの話しを聞いてみたかったというのがこのセッションを選んだ理由です。

このセッションでお話しされていたこと

• 2018年以降、カインズさんで取り組まれてきたデジタル戦略の変遷
• 内製化に取り組む前の開発体制やシステムにおける課題
  • 縦割りな組織とシステム
  • ベンダー毎に異なる仕様
  • システムの複雑化により機構追加やテスト工数が膨らむ状態
  • ベンダーに投げてしまっているので人材の育成が進まない
• 内製化を進めて実現したいシステムの構成や開発体制
  • マクロサービス化し再利用可能な部品を増やす
  • 既存システムとの結合部分を連携可能でシンプルな形で作る
  • ビジネス部門とシステム部門の一体化
  • 組織を統合した内製化組織を実現し、コストとシステムの最適化を図る
  • 内製化により人材の育成を実現する
• 取り組んだこと
  • 『開発スタイル』の開発
  • 半年くらいかけてプロトタイプを作る
  • 開発を行う下地、環境を整える
  • MVP(Minimum Viable Product)の作成
• 解決したい課題
  • これまではベンダー毎に閉じていて似たような機能を持つシステムが複数ある。これらを集約、統合しスリム化したい
• オフラインとオンラインの融合
  • これまではPOSを中心としたオフラインシステムがメインでECサイトやモバイルアプリはPOSシステムのおまけ的な位置づけだった
  • これからは逆にPOSが”金庫付きのディバイス”になり、コマースシステムを中心としたスケーラブルなシステムになっていく
• 課題を解決するための取り組み
  • マイクロサービス単位で開発
  • 再利用可能なシステムを作って横展開していく
• リテールシステムの開発
  • 機能ごとに小さなアプリケーションを開発
  • 複数のサービスを組み合わせでシステム化するコンポーザブルなシステム
• 開発手法への挑戦(Group Open EcoSystem)
  • Basia Group Market Place
  • グループ全体での製品化とマーケットプレイスの提供

このセッションを通じて自分が理解できたこと、感じたこと

カインズさんがベイシアグループという大きい企業の中でどのように内製化やマイクロサービス化を実現していったのかをわかりやすくお話し頂きました。短い期間でプロトタイプを作ること、その中で開発手法やお作法も含めて検討されたというのが大事なポイントだなと思いました。コンポーザブルなシステムというのはマイクロサービス化のユースケースとしてわかりやすかったです。POSとコマースシステムの関係性については小売業を営む他の会社でも抱えている課題の一つのように思えました。内情をあまり知らない業種、業態なので自分にとっては非常に新鮮で勉強になりました。

DAY1【CUS-18】プログラムを書けないゼネコン社員が、3 年でどこまでやれるのか ～戸田建設の技術的自立と現場力の向上～

このセッションを選んだ理由

カインズさんのセッションにも近いですが内製化に関する具体的な事例を聞いてみたかったというのが一番の理由です。また “プログラムを書けないゼネコン社員が” という事なので組織、人材的な側面と技術、システム的な側面のそれぞれでどのようにアプローチしたのか気になりました。そしてIT未経験の方がサービスの開発現場でどのように活躍されているのか聞いてみたいと思いこちらのセッションを選びました。

このセッションでお話しされていたこと

• いわゆる2024年問題が顕在化し、運送業、建設業、医療業界、人手不足や業務の効率化が求められている
• 戸田建設では対策の一つとしてデスクワークをアウトソーシングするサービス『ToLabel』を開発
  • アウトソース先は社内、社外ともに可能
  • カレンダー機能もありガントも作成できる
  • 自分の現場だけでなく他の現場のタスクも確認できるので、依頼内容や書き方などの横展開が実現できている
  • 管理者向けの機能も充実
    • 通知機能やタスクの一覧画面、KPIや利用社員、作業時間などの統計情報も確認可能
• 『ToLabel』のアーキテクチャやシステム構成構成の説明
• 内製化は4人でスタート
• 人材のDXに必要な8要素
  • 学習意欲を持っている（最重要）
  • 共に歩める仲間がいる（ひとりだと辛い）
  • 没頭する時間（特に最初は色々勉強するのにも時間がかかる）
  • 旬な教材（「今どき」な技術を学べる）
  • 自由に使えるクラウド環境（実際に試すの大事）
  • 頼れる教師（実際にやっていることが正しいかどうかのフィードバックが必要）
  • アプローチ可能な実務データ（安全にデータにアクセスできる必要がある）
  • 実務的課題（事業部門出身だと課題の核心にアプローチできる）
• 実務的課題・課題解決へのアプローチ
  • デジタルイノベーションプログラムでAWS流のWorking Backwqrdsを学ぶ
  • 短い期間でサービスデザインを行い、プロトタイプまで作成する
• 内製化を進めていくうえでの三種の神器
  • S3
    • ストレージだけでなく静的コンテンツのWEBサーバやDB的な利用ができる
  • Lambda
    • イベントドリブンで動かす関数
    • 毎月100万リクエストまで無料
  • API Gateway
    • 29秒以内での処理を提供する
    • 様々な使い方ができる
      • REST API
      • HTTP API
      • WebSocket API
  • サーバレスシステムの動作説明（これわかりやすかったです）
    • サーバ管理者は不要になる！
• 実務データへのアプローチ方法
  • API Server経由でアクセス
• スマートビルディングの取り組み
  • いわゆるデジタルツイン
  • ビル運用やビルインフラのIT・DX化
  • 運用手順や設計書、進行表などが3Dモデル化されたビル上から参照できる

このセッションを通じて自分が理解できたこと、感じたこと

誰でも同じようにできるという訳では無いですが、サーバレスアーキテクチャであれば開発者というバックグランドが無い人達でも参画し易く、努力や工夫をすることで成果を残すことができると再認識しました。DX人材の8つの要素はエンジニア育成の汎用的な要素でもあるな思いました。どれもとても大事な要素です。また戸田建設さんの事例は自社や業界が抱えるビジネス課題をITテクノロジーで解決する典型的な事例だなと思いました。こういった成果の裏にはきっと沢山の挑戦や失敗があったんだろうなと思います。またリードする人のバイタリティが必要は必要ですね。様々な創意工夫があったのかなと思います。課題があって人材が見つかったとしても勝手には進まないですし、ファシリテートやサポート、枠組みや支援する体制、会社内でのコミットメントなど大小様々な努力の結果がこういった大きな成果につながっていると思いました。わかりやすくて参考にできるポイントが多いセッションでした。選んでよかったです。

DAY1【AWS-28】大規模クラウドインフラ設計・構築案件の歩き方

このセッションを選んだ理由

大規模クラウドのインフラ設計、構築ということで自分の業務にも直結する話しもあると思ったので気になりました。『求められる非機能要件の高度化』は案件対応を進めていく中でも感じている所だったのでどうアプローチするのか気になりました。また、AWS Professional Servicesの実績をベースとした知識、ノウハウを聞いてみたかったこともあり、こちらのセッションを選びました。

このセッションでお話しされていたこと

• 『大規模クラウドインフラの設計構築』を進めていくうえでの特徴や課題
  • 関係者が増える
  • 想定外が増える
  • 堅牢さが求められる
• 『関係者が増える』ことへの取り組み
  • 設計の枠組みを作る
  • アプリ/インフラチームの責任分界を決める
  • コーディングルールを明確にする
• 『想定外が増える』ことへの取り組み
  • クリティカルパスの特定
  • 展開手順の整備
  • コスト管理は今すぐ始める
• 『堅牢さが求められる』ことへの取り組み
  • クラウドリソースのテスト
  • 静的解析

設計について

• 『設計の枠組みづくり』について
  • 設計書一覧のサンプル
    • （非常に網羅性の高い設計書一覧でした）
  • 主担当を明確にする（RACIのR）
    • Responsible(実行責任者)
  • 設計書の項目では設計事由を記載する
    • ADR(Architecture Decision Record)を論点ごとにまとめる
  • 詳細設計書
    • IaCを正とするが最初はドキュメントと併用
  • 進捗の定義
    • 完了条件を明確にしておく
• 『アプリ/インフラチームの責任分界』について
  • 開発方針とガバナンスから境界を決めていく
  • もしくは権限分掌を重視する(IAM)
  • CICDはお互い補完し合う必要がある
• 『コーディングルール』について
  • “ルール”と”スケルトンコード”と”実例”を用意する
  • 生成AIを活用することで効率化できる
• 『静的解析』について
  • セキュリティ関連のチェックを行う(SAST)

構築について

• 『コスト管理』について
  • 運用が始まってから行うのでは無く、開発中からコスト管理を行う
  • モニタリングして意図しない費用の発生を抑制する
  • AWSのBudgetsやCost Explorerを活用する
    • AWS Cost Anomaly Detection(コスト異常検出)
• 『クリティカルパスの特定』について
  • システム構築はIaCだけで完結しない
    • 手動の方が適しているケースもある
    • セキュリティ関連ツール
  • IaCでできないケース（対応していないなど）
  • 社内調整や申請など
• 『展開手順の整備』について
  • 段階的に繰り返し展開する
  • 手順書は可能な限りローコンテキスト
    • 自分が展開作業を実施するとはかぎらないので
    • 他の人でも同じ対応ができるように
  • 依存関係を明確にしておく
• 『クラウドリソースのテスト』について
  • 単体テストと結合テスト
    • 単体テストは実環境で実施
    • 結合テストはシステム間の疎通性を確認する
  • 単体テスト
    • コードレビューや静的解析
    • 実際にデプロイして作成された環境やリソースを確認する
  • 結合テスト
    • アプリケーションを動かしてテストを行う
      • 疎通確認、ログの出力、ステータスなど
    • 負荷テストはフルスケールで実施する
      • 必要な上限緩和を申請
      • 実施後は縮退させる

このセッションを通じて自分が理解できたこと、感じたこと

大規模システム開発に求められることの多くは、大規模では無いシステムでも必要性のある項目が多く非常に勉強になった。もちろん、大規模案件と違い小規模・中規模の場合予算やスケジュールなどの制約があるが、限られたリソースの中で何を優先的にやるのかを検討する際の選択肢には入ってくるモノが多い。そういった選択肢それぞれが持つ必要性を再認識しました。特にコーディングルールで話されていた『”ルール”と”スケルトンコード”と”実例”を揃える』というのはしっかりと認識しておきたい。ルールをドキュメントにまとめるだけでは解釈のズレが出てくるので、スケルトンコードと実例は重要だなと思った。お話頂いた内容がどれも「確かに」と頷く内容が多くセミナーを聞いているような感じがしました。実績に裏付けされたノウハウがぎゅっと詰まった非常に中身の濃いセッションだったと思います。

DAY1【CUS-21】リファレンスアーキテクチャによるガバメントクラウド活用と Amazon Bedrock を活用したモダン化アプリの例

このセッションを選んだ理由

まず最初にデジタル庁の方の話しを聞いてみたかったというのがあります。デジタル庁ができてガバメントクラウドという言葉を聞くようになりましたが実際どういうものなのかを殆ど把握していなかったので。また庁内で作成された「リファレンスアーキテクチャ」がどういうモノか、またどう活用されているのかを聞いてみたいと思いました。ガバメントクラウドは今後案件でも対応する可能性があるので情報収集も兼ねてこのセッションを選びました。またBedrockの活用事例を聞きたかったというのも理由の一つです。

このセッションでお話しされていたこと

• ガバメントクラウドとモダン化を進めるうえで重要な『クラウドファーストの原則』
  • 迅速：IaCを活用して迅速に構築を行う
  • 柔軟：マネージドサービスを活用し、必要な分だけリソースを使う
  • セキュア：サーバレスやマネージドサービスを使うことでOSレイヤーを隠蔽できセキュリティリスクが減る
  • コスト効率：必要な時だけ必要なリソースを使う。オートスケールを活用する
• デジタル庁で作成された『リファレンスアーキテクチャ』の紹介
  • 2021年9月から開発
  • 2024年現在、800以上のシステムがクラウドに移行している
• アーキテクチャ
  • 基本的にマネージドやサーバレスを使用する
• 方針
  • クラウドバイデフォルト
  • クラウドを「スマート」に使う
  • アプリケーションのモダン化にも取り組む
• 課題
  • 人材やスキル不足
  • 期間や予算が限られている
  • 実装や品質に関する漠然とした不安がある
  • リフト＆シフトのリフトだけ済ませるような事は避けたい
    • 問題の先延ばしやレガシーな改修の繰り返しに繋がる
• リファレンスアーキテクチャの策定
  • 全てのパブリッククラウドサービスに対応
  • ダウンロード可能な状態
  • IaCコードも提供している
• リファレンスアーキテクチャの概要
  • 業務ブロックと非機能ブロックに分かれている
  • 代表的なシステムパターンも作成
  • GCASという内部ポータルを経由して提供している
• 『業務ブロック』
  • 汎用性を意識した
  • 共通的な機能や処理でブロックを作成している
  • 10個のブロック種別を用意し、全部で40個のブロックがある
  • 『非機能ブロック』も同じような構成になっている
• 各ブロックに含まれる内容
  • アーキテクチャ図
  • 業務概要
  • 処理概要
• 代表的なシステムパターンブロックの組み合わせ
  • ポイントとしては
    • WebAPIで提供
    • コンテナ・FaaS(Lambda等)
    • イベントドリブンで動く
    • DBは業種別に作成する
    • 非機能は必要なブロックを選択
• リファレンスアーキテクチャの実際の活用方法
  • 設計構築の流れ
    • BPRを行う(AsIs-ToBe)
    • 業務や機能の整理
    • 業務とリファレンスアーキテクチャブロックのマッピング
    • ブロックの組み合わせを検討
    • アーキテクチャ案の完成
  • メリット
    • 0→1の設計が無くなる
    • 工数を短縮できて生産性が向上する
    • 横展開することで品質を担保できる
    • 技術や知見不足を補填できる
    • システム的な無駄なコストを抑制できる
• リファレンスアーキテクチャを進めていく中での課題
  • 利用イメージがつかなくて不安という声があった
    • 実際にデモアプリを構築して具体例を作った
  • 手続きや審査などが大変
    • 移行審査を支援するアプリを作成
    • 生成系AIを活用してレビューやIaCコードを提供してくれる
    • Slack経由で問い合わせできる
• 今後
  • リファレンスアーキテクチャを実用的で価値あるモノに改善していく

このセッションを通じて自分が理解できたこと、感じたこと

デジタル庁が主導するガバメントクラウドへの移行について大枠や移行プロセスを聞くことができた。また省庁内で多数存在するシステムのように横展開が発生する場合はカタログ化やリファレンスアーキテクチャのようなデザインパターンを揃えることで設計業務の効率化や品質の担保を実現できる事がわかった。特にブロックを組み合わせるという考え方は大事だなと思いました。利用者目線としてはガバメントクラウドへの移行が進んで行政システムが効率化され便利になるといいなと思いました。どんどん推進してもらいたいです。

DAY2【KEY-02】基調講演　ビルダーとテクノロジーが加速する次のイノベーション

このセッションを選んだ理由

DAY1の基調講演と同様に、AWS Summitの基調講演なのでしっかりと現地で拝聴したいと思いました。JR東海さんは日頃からお世話になっていますし、電通デジタルさんはデジタルマーケティングの最前線にいらっしゃるのでそれぞれどんな話しを聞けるのか興味があり、このセッションを選びました。

このセッションでお話しされていたこと

• AWSのこれまでの取り組み
  • 2006年に東京リージョン開設(日本は5番目)
  • 2021年に大阪リージョンが誕生
  • 現在240以上のサービスが展開されている
• AWSが行う国内業界の支援・取り組み
  • 金融業界
    • SBI証券
      • 1日で2兆円以上の取引
      • IaC化により拡張性を実現
  • 自動車業界
    • Tier IV
      • マイクロサービス化
      • Gravitonの利用(vECU)
      • 開発環境の構築
  • 通信業界
    • docomo
      • 5G 通信基盤
  • 航空業界
    • ANA
      • 4万人が活用するデータレイク
• 生成AIに関連するAWSサービス
  • 生成系AIアプリケーション(Amazon Q)
  • LLM、Bedrock
  • コンピューティングインフラ
• 生成AIイノベーション事例
  • RICHO
    • 3ヶ月でLLM開発を実現
• JR東海さんによるリニア中央新幹線の話し
  • 方針
    • データドリブン
    • 内製化
    • 最新技術の採用
  • 活用事例
    • プロアクティブな故障検知
• 電通デジタルさんによる次世代マーケティングの話し
  • 生成系AIを使ったマーケティング戦略
  • バイアスの無いレスポンシブAI
  • ∞AI チャット
    • 開発期間2ヶ月
    • 生成系AIを活用した仕組みでマーケティングの支援を実現

このセッションを通じて自分が理解できたこと、感じたこと

国内の各業種においても生成系AIを活用した課題解決の取り組みが活発に行われている事がわかりました。コンピュータの進化と同じ、もしくはもっと早いスピートで進化していく生成系AIを活用できるとビジネス的なアドバンテージが大きいですね。逆に生成系AIの活用ができない場合、機会損失や効率化の遅れ、品質や性能のギャップが生まれるなど目に見えない形での損失が大きくなると思いました。やばいです。そういった意味でもBedrockやLLM、生成系AIに関する知識やサービスのキャッチアップは急務だなと痛感しています。

DAY2【AWS-43】大規模言語モデルのプロンプトエンジニアリングのコツ

このセッションを選んだ理由

LLMを十分に活用していく上でプロンプトエンジニアリングが大事というのは漠然と認識はしていたものの、具体的に何をどうすればいいのかをしっかりと聞いたことが無かったので聞いてみたいと思いました。またBedrockで使用できるClaudeモデルについてもどんなものか興味があり、このセッションを選びました。

このセッションでお話しされていたこと

• プロンプトエンジニアリングの概要
  • 期待する答えを導くために入力プロンプトを工夫する取り組み
  • ペルソナや人物像の指定などしてあげると良い
  • また回答のフォーマットを指定する場合もある
• プロンプトエンジニアリングのガイドライン
  • どんなAIでも「利用者の心の中を読むこと」はできないので、言語化して伝える必要がある
  • 『具体的』『明確さ』『説得力』など何を求めているのかを伝えてあげる
• Anthropic Claude について
  • 3.5がリリースされた
• プロンプトエンジニアリングのテクニック
  • 人間への質問
    • 開発したモデルに対し評価データを作成してテストを行う
    • 質問と想定する回答のセットを用意する
    • エッジケース(際どいケース、判断が難しいケース)も含めて準備できるといい
  • XMLタグの活用
    • プロンプトの構造を理解しやすくなる
  • 例示を使う
    • “example”タグを使うことで例示を提示できる
  • 出力形式の指定(Claudeの代弁)
    • 入力情報として思考過程と回答の出力形式を指定する
    • トラブルシューティングにも役立つ
  • 考える時間を与える
    • “thinking”タグで思考過程を出力させる
  • 役割をアサインする
    • ロールプロンプト
    • どんな役割を期待されているのかを伝える
  • ハルシネーションへの対処
    • 分からない時は『知らない』と言う許可を与える(寛容さ)
    • 自分の返答に自信がある時だけ答えるように言う(謙虚さ)
    • RAGの利用など適切な引用を見つけて回答するように頼む(お墨付き)
  • 不適切なユーザ入力への対処
    • Claudeは不適切な入力に対する耐性は高い
    • “harmlessness screen”を活用するとさらによい
      • Mitigate jailbreaks and prompt injections – Anthropic
  • プロンプトチェーン
    • 1つのプロンプトの結果を次のプロンプトにつなげる事で回答の精度を向上させる
  • 長い文章でのテクニック
    • “document”タグで文章を渡す
    • 後から質問すると予め伝える
    • 関連する引用を見つけさせる
    • 引用が見つからない場合はその旨を伝えてもらう
    • ドキュメントを元に例を提示する
    • プロンプトの最後で質問を行う

このセッションを通じて自分が理解できたこと、感じたこと

このセッションではいろんな気付きがありました。まず生成系AIも対人の場合でもコミュニケーションのベースは同じだなと。結局自分の頭の中だけで考えていることは文字やドキュメントなど伝わる形で伝えないと伝わらない。もちろん、ある程度同じ考えや知識を持っている人とはそこまで細かく伝えなくても理解できる局面はあると思いますが。リモートワークやテキストベースでのコミュニケーションで仕事をする機会が増えているので分かりやすい文章を心がけようを思いました。プロンプトエンジニアリングについては知っているか知っていないかで大きく結果が変わってくるので今回のセッションで基本となる考え方を聞くことができて参考になりました。今後、プライベートや業務で生成系AIの勉強や活用を行っていく上でスムーズに利用できるよう勉強しておきたいです。

DAY2【AWS-58】インシデントの影響を封じ込めるクラウドアーキテクチャの実践

このセッションを選んだ理由

“Cell-based architecture” についてはWell-Architectedレビューやベストプラクティスなどでも時々聞くことはあったんですが正直ぼんやりとしかイメージできていませんでした。そのため、”Cell-based architecture” についての具体的な仕組みや特徴、実装方法など聞いてみたいと思いこのセッションを選択しました。

このセッションでお話しされていたこと

• よくあるシステム障害の原因
  • テスト不足(これは100%防ぐのは難しい)
  • オペレーションミス(これも100%防ぐのは難しい)
  • ポイズンピル攻撃(100%を想定する事は難しい)
• 障害による影響
  • システム全体、もしくは全顧客に影響するなどインパクトが多い
• 対策
  • 障害分離性を確保するためにセルベースアーキテクチャが期待される
• セルベースアーキテクチャのメリット
  • セル単位の追加が可能になるのでスケール性を確保しやすい
  • 特定のセルからデプロイするなど選択肢が増えるのでテスト性が向上する
• セルベースアーキテクチャのデメリット
  • ハードウェア故障率の影響を受けやすいので自動復元が必要
  • システムの複雑性が増し、その分コストも増える
• EBSを例にしたセルベースアーキテクチャの事例
  • データプレーン
    • セルルータ
    • セル本体
  • コントロールプレーン
    • セルの管理を行う
• “セルルータ”の機能・特徴
  • セルへのマッピング情報の管理
  • 高い可用性とスケーラビリティが必要
  • 重要なコンポーネントになるのでできるだけシンプルな構成にしたい
• ルーティングの実装方法
  • a. DNSの活用(Route53)
  • b. API Gateway + DynamoDB
  • c. EC2やECS
• アンチパターン
  • 障害発生時に通常時とは異なる挙動を実装する（”バイモーダル”な挙動）
    • レジリエンスの確保という観点ではアンチパターンになる
    • サービスが成長するとデータプレーンの規模も大きくなるので、データベースへの負荷が集中する
    • クライアントには古いデータを返して、コントロールプレーンへのポーリングを続ける方がいい(通常時の挙動を維持させる)
• 規模の不一致がある場合
  • 規模の小さい方をベースに全体をコントロールする方がよい
• パーティションキーの振り方
  • セル同士のやり取りが少なくなるような分割方法
  • 偏りが大きい場合は複数のキーを組み合わせる
• パーティションキーとセルのマッピング例
  • 完全なマッピング
  • 範囲マッピング
  • モジュロマッピング
• セルベースアーキテクチャ設計ポイント
  • デプロイ(段階的にデプロイ)
  • オブザーバビリティの確保
    • モニタリングとロギング
  • セルの再配分(ストレージの同期)
• シャッフルシャーディング
  • クライアントに対して複数のワーカー(シャード)を割り当てる
  • セル障害時の影響範囲を限定することが可能になる

このセッションを通じて自分が理解できたこと、感じたこと

Well-Architectedレビューなどでも記載されている”セルベースアーキテクチャ”について実際の構成例を見ながら説明して頂き、理解が深まりました。”セルベースアーキテクチャ”にすることで障害範囲を限定できる、レジリエンスの確保にも繋がる、という点である程度規模のあるシステムでは有効なアーキテクチャかなと思いました。またアンチパターンで挙げられていたバイモーダルな挙動というのは小規模、中規模なシステムではやりがちなので本当に必要かどうか、また実装する場合の実現可能性などを慎重に検討する必要があると思いました。”セルベースアーキテクチャ”を導入する際はこのセッションの内容を振り返りたいと思います。

全体的な感想

AWS Summitを2日間通しで現地で参加したのは初めてで頭の中も体力的にも結構疲れました。それでもAWSの方を始め事例として発表頂いた各会社さんから具体的な話しを沢山聞くことができて非常に勉強になりました。またセッション以外にもパートナー各社のブースやAWS Villageでの展示、説明など面白そうな企画が沢山あって全然時間が足らなかったです。次回以降も調整がつくようであればまた参加したいと思います。個人的には社内、社外問わずいろんな方と話しができて非常に楽しかったです。またいろんな発見のあるAWS Summitでした。尚、この2日間は有給休暇を使用すること無くAWS Summitへの参加することができました。iretでは業務に関係するイベント・セミナーについては社内の手続きを適切にすれば参加することができます。非常にありがたい制度です。AWS Summitに参加して得たことを今後の業務や実際の案件で活かせるように社内へのフィードバック、追加の学習など取り組んでいきたいと思います。またAWSを始めAWS Summitの開催にご尽力された関係者の皆様に感謝とお礼を申し上げます。

最後まで読んでいただきありがとうございました。