クラウド利用者の「責任」をどう果たす？AWSセキュリティ対策のススメ #AWSSummitJapan #AWSSummit | DevelopersIO

Insights from the Session「Harness the power of AWS to build game changing applications」 #AA-04 #AWSSummit | DevelopersIO

Introduction Hello, this is Hemanth from the Department of Alliance. In this blog, I’ll share my experience from the AWS Summit Tokyo 2024 session on “Harnessing the Power of AWS to Build Game-Changing Applications”. It was fascinating to see that many sessions at AWS Summit Tokyo 2024 offered content in both Japanese and English, making the event more accessible and engaging. Agenda Game-changing” applications running on AWS Key points for decision makers Why customers choose AWS The first step towards innovation Bringing Unprecedented Ideas to the Real World During the session, several innovative applications of AWS technology were highlighted. Each showcased the transformative power of AWS in solving complex challenges: …

[セッションレポート] 労働力不足の現場を救う！「京セラロボティックサービス」を支えるクラウド基盤の開発ストーリー #AWSSummit | DevelopersIO

AWS Summit Japan 2024の弊社クラスメソッドのパートナーセッションにて、弊社が長年ご支援させていただいている京セラ株式会社のロボティクス事業部の巽様にご登壇いただきました。セッション内容をレポートします。

[セッションレポート]スマートなクラウド活用を目指す行政組織における CCoE の構築の方法について#AWSSummit | DevelopersIO

行政という組織でクラウド利用を推進する際には、行政組織特有の背景（多くの関係者・予算の承認など）を考慮する必要があります。そのため、組織内にCCoEを設置し、行政官や関係各所への適切な情報伝達・コミュニケーションを行なっていくことが非常に重要です。

【セッションレポート】なぜ、AWS 活用のメリットを実感できないのか？〜内製化・運用改善の考え方〜 (AP-22) #AWSSummit | DevelopersIO

AWS Summit Japan 2024 のセッション「なぜ、AWS 活用のメリットを実感できないのか？〜内製化・運用改善の考え方〜（AP-22）」に関するレポートです。

【セッションレポート】OpenSearch のベクトル機能による検索の改善（AWS-47） #AWSSummit | DevelopersIO

ベクトル検索が求められるようになってきた背景から、OpenSearch を利用したベクトル検索と、LLM を組み合わせた RAG の実装について解説されるセッションです。

[ブースレポート]AIによるプラント保守の伝承 | DevelopersIO

はじめに こんにちは大阪オフィスのよなです。 本記事は2024年6月20~21の2日間で開催されたAWS Summitのブースレポートです。 個人的にすごく面白い！と思ったブースについて書きたいと思います！ 私の主観も結構入ってるのでその点はご了承ください。 概要 テーマ：IoT, 生成AI ブースタイトル：「AIによるプラント保守の伝承」 Amazon Web Services ブログでも以下のブログが紹介されています。 一部、上記のブログより画像を引用させていただいております。 アジェンダ プロセス製造業でどのように生成AIが活用できるのか？ということを製造現場を模したデモ機を用いて紹介されていました。 具体的には、ベテランエンジニアが持つノウハウをデータ化することで、新人や経験の浅いエンジニアもAIを使ってベテランのノウハウを活かすことができるという内容でした。 プロセス製造業に限らず、製造業や機器メーカーでも共通の課題を持っている企業は多いと思うので、幅広く参考になる内容だと思いました。 私自身クラスメソッドにジョインするまでは機器のメンテナンスなどに従事していたこともあり、とても興味を持てる内容でした。 デモの全体像 それではまずデモの全体像です。 以下の図と説明部分はAWSブログを引用させて頂いております。 オペレータは現場から発報されたアラートを確認する。 オペレータは生成AIチャットボットに問い合わせする。チャットボットは過去のレポートを元に原因・対処方法と、推奨される現場への確認アクションを応答する。 オペレータは現地エンジニアにリモート通話で、AI から生成された応答を基に状況確認を依頼する。 現地エンジニアは実際の状況を確認後、対応作業を行う。もし原因究明や解決が困難な場合は、別途ベテランエンジニアに通話に入っていただく。 対処が完了した場合、原因や対処法などをレポートに記載し保存する。 デモンストレーション トラブル発生 今回のデモでは 液体を水槽Aから水槽Bに送液する装置でトラブルが発生した場合のデモンストレーションが行われていました。 まずは異常状態として攪拌機にかかる電圧を下がることで期待する攪拌結果が得られい状況を作ります。 この異常な状態を検知してオペレータへアラートが発報されます。 次にオペレーターは異常が発生した原因を調査します。 ベテランと新人 原因調査のプロセスではベテランと新人に大きな差が生まれます。 ベテランは自身の経験から、エラーの原因、確認するべき点、確認方法、対処方法、対処の優先順位などを頭の中で想像しながら効率よく作業を行います。 対して新人はエラー内容をマニュアルで調べて、確認箇所を調べて、確認の方法を調べて…というように一つずつ「探す、調べる」という行為が発生します。 通常、機器は複数の部品の組み合わせで構成されています。 そのため、多くのマニュアルやメンテナンスログと睨めっこしながら1つずつ原因を潰していくのは非常に時間がかかる作業です。 生成AIを活用した原因調査 そこで生成AIが活躍します。 生成AIを用いて蓄積されたノウハウというデータベースを自然言語で検索できるようにします。 具体的にはRAGを使ってマニュアルやメンテナンスログなどを検索することで、AIがあたかもベテランエンジニアのアドバイスのような回答をしてくれます。 今回のデモでは下の画像のように、エラー内容から考えられる原因、過去に同じエラーが出た際の対処方法などが出力されていました。 これってめちゃくちゃすごいことなんです！！ 実際にマンパワーでこの情報を揃えるには、 エラー内容をマニュアルで探す 過去のメンテナンスログから似た症状が発生していないか探す 過去の解決方法から最適な解決方法を探す 対処方法の手順を調べる 他の要因がないか調べる などなど、他にも考えるべきことは多岐にわたります。 私も以前、機器のエンジニアとして働いていた時は、分厚いキングファイに挟まれたメンテナンスマニュアルと過去のメンテナンスログから可能性の高そうな箇所を探すことにかなり時間を取られることがありました。 これを自然言語で解決できるなんて感動しますよね！ トラブルシューティング 次に生成AIの回答を元に現場の作業者へ指示を出します。 ここのオペレーションは今まで新人がベテランに聞く。というフローとあまり変わらないように思います。 しかし、ベテランの時間を割かなくても解決できる可能性があるというのはお互いにとって非常に良いことですね。 また、トラブルが1度で解決しないことも多いので、そこでもAIを使って自然言語で解決までの手助けをしてくれるのはありがたいですね。 トラブル解決後は必ず確認作業がつきものです。 確認作業に関してもマニュアルや過去の作業履歴を参考にステップバイステップで教えてくれると作業の効率化につながると思います。 今回のデモでは遠隔でオペレータが指示をする想定でしたが、現場の人が生成AIを使って作業するというようなケースでも活躍しそうですね。 デモの中でも解説がありましたが、新人+AIでは解決できずにベテランに頼って解決できた場合でも、そのデータを残すことで次回以降にAIが参照するデータソースになります。 このように、新たな情報もどんどんデータとして残すことで将来的な作業効率化につながります。 感想 ベテランと新人を比べましたが、たとえベテランエンジニアでも情報を探すのには時間がかかるものです。 その調べるという行為を短縮できるのは誰にとってもメリットになるのではないでしょうか。 ただし、こういったAIの活用にはソースとなるデータが不可欠です。 そのために以下のことが非常に重要だと思います。 エンジニアがなるべく手間をかけずに作業データを保存できる仕組み ベテランのノウハウを言語化、データ化する 紙ベースのデータをAIのデータソースとして使える形式に変換する まだまだ現場ではベテランの頭の中にのみ貴重な情報がある状態や、紙ベースで情報が管理されていてデータとして扱えないケースも多いのではないかと思います。 昨今はエンジニアの確保も難しくなってきているので、技術を活かしてひとりひとりの作業効率を上げていくことが求められているように思います。 そのめにも、まずは活用できるデータを蓄積して、うまく利用していくことが重要だと改めて感じました。 全体を通してとても楽しく、今後こういった技術が増えてくることが期待できるとてもいい内容でした！

【セッションレポート】大規模クラウドインフラ設計・構築案件の歩き方（AWS-28）#AWSSummit | DevelopersIO

こんにちは、八木です！ AWS Summit Japan 2024 に参加しております！！ 「大規模クラウドインフラ設計・構築案件の歩き方」セッションの内容が素晴らしかったので、レポートします！ 設計段階での骨組み作りや責任分解、ルールや、構築段階での手順整備やコスト管理、テストに至るまでを経験から語っていただいた内容で、プロジェクトマネジメントの観点でも、 改めて気づいたことや、学びが多かったです。 なおセッションのオンデマンド配信および、資料は公式サイトから登録後、視聴可能となっています！ セッションスピーカー： 仲谷 岳志 氏 所属：アマゾン ウェブ サービス ジャパン合同会社 プロフェッショナルサービス本部 プリンシパルビッグデータコンサルタント セッションの感想 設計段階で基本設計や詳細設計の設計書項目の整理について触れられていましたが、設計事由は必ず含めることを言及されていました。 また、詳細設計書についても、初版は「IaC＋文書」で残す（パラメーターがコードに残るのでそれで良しとするのではなく、初版は文書を添えたドキュメントにする）ことについても言及されており、初期でのこういった「人が読む目的」での文書を残すことを推奨されていたのが印象に残りました。 例えばIaCですとパラメーター自体はコードにあるため設計書にも残す必要が無いようにも思われがちですがそうではなく、レビューや引き継ぎ、チームでの説明をする人に対してのコミュニケーション上の配慮として必要ということですが、自分でも振り返るとドキュメントに書くことを省くこともありがちではあったため、気をつけるべきポイントとして再認識できた気がします。 また構築段階において、開発開始時点からコストを管理すること（本番運用を開始する前に始めること）も当たり前のようで大規模だと特に重要となってくるので、その点も改めて気づきを得ることができました。 ここに挙げた点以外についても、特に大規模なプロジェクトでのクラウド移行案件や、環境構築案件を担当される方には学びが多いセッションと思いましたので、興味のある方はご視聴をお勧めいたします！

AWS Summit Tokyo 2024 の雰囲気をお伝えします #AWSSummit | DevelopersIO

コーヒーが好きな emi です。 2024/6/20(木)、6/21(金)で開催中の AWS Summit Tokyo 2024 の 1 日目に現地参加しましたので、写真盛りだくさんで会場の雰囲気をお伝えします。 会場まで 海浜幕張駅から徒歩 10～15分程度で開錠の幕張メッセに到着します。たくさんの人がぞろぞろ歩いていくので、ついていけば迷うことはないと思います。 私は朝一で企業ブース対応があり、スポンサー入口から入場することになっていたので 8:50 ごろに幕張メッセに到着しました。 8:00 くらいは 200~300 名程度の長蛇の列ができていたと聞いたのですが、私が到着した 8:50 頃はもうかなり入場案内が進んでいて、入り口付近までスムーズに行くことができました。受付の対応が早くて本当にありがたいです！！ 外から見えるレストラン WORLD KITCHENS! -ワールドキッチンズ- は、AWS Summit Japan 2024 の会場出口を出てすぐのところにあります。お昼ご飯に良さそうです。 受付 これは 8:55 くらいの受付の入り口です。駅から歩いていって手前が一般入場入口、奥がスポンサー、事例登壇者受付と分かれています。 空いているタイミングで撮った写真です。左が一般受付、右がスポンサー受付です。 受付にすごく人を配置くださっていて、かなり早いスピードで入場できました。 入場の際は名刺、もしくは運転免許証などの本人確認ができるものを提示します。私は運転免許証を提示しました。 今年は携帯の画面で QR コードを見せればその場で印刷してくれる仕様だったので、自分で印刷していかなくても OK でした。 ありがたいです。 受付では以下 3 点セットを受け取ります。AWS のセッションを聞かれる方はイヤホンが必要なので、なくさないようにしましょう。 印刷した受講票 入場パス（首から下げるケース） オレンジのイヤホン（セッションを聞く際にレシーバーにつなげて使う） ちなみに、入場パスの色には意味があります。 黒：一般来場者 灰色：Exective 紫：事例関係者 緑：スポンサー（パートナーブース担当者など） オレンジ（黄色？）：AWS 社員 白：スタッフ 背中に「Ask me」と書かれたシャツを着ている方はスタッフの皆さんです。いろんなところにいてくださるので、困ったら聞いてみましょう。 \ 会場のみなさまをサポート✨/ 「Ask me」がプリントされたスタッフTシャツが目印👀#AWSSummit 会場内でお困りごとがありましたらお声がけください！ pic.twitter.com/jkL8uPVLHo — AWS公式☁️アマゾン ウェブ サービス ジャパン/クラウドサービス (@awscloud_jp) June 19, 2024 セッション会場 全体はこんな配置です。 今年は基調講演（キーノート）のための指定席券が配られて指定席制になっており、かなり評判が良かったそうです。 また、基調講演で指定席券をゲットし損ねてしまった方向けに、会場の反対側の Partner Solution Expo 側の Room でもオンラインで配信をしてくださいました。 基調講演を視聴するために会場の反対側の Partner Solution Expo 側の Room に移動される皆さん。まだ Partner Solution Expo オープン前です。 朝のまだ静かな Partner Solution Expo。 自分が参加するセッションがどの会場でおこなわれるかは、受講票の裏を見るとすぐわかります。※画像は昨年のものです。 このようなレシーバーがあり、イヤホンを差し込んでセッションを聴く形式です。 レシーバー本体右側面に電源兼音量調節用のダイヤルがついているので、ぐりぐりして音量を上げます。 セッションごとにチャンネルが決まっています。 ※画像は昨年のものです。 セントラルラウンジ、各種ラウンジ 今年の大きな特徴は、Partner Solution …

Serverlesspresso – コーヒーをサーバーレスとともに – をAWS Summit JAPAN2024 で体験してみた #AWSSummit | DevelopersIO

こんにちは、八木です！ AWS Summit Japan 2024 に参加しております！！ 昨年のBerlinでも体験した、Serverlesspresso – コーヒーをサーバーレスとともに – をAWS Summit JAPAN2024　を体験しましたので、その振り返りと共にブログへ記載したいと思います！！ AWS Summit Berlin 2023 で体験した様子はこちら！ AWS Summit Berlin Expoと当日の様子について #AWSSummit AWS Summit Japan 2024 の詳細はこちらの記事にも紹介されています！ [ブース紹介] AWS Summit Japan 2024で歩き疲れたら美味しいコーヒーで一息つきませんか？　#AWSSummit AWS Summit Berlin 2023 での体験と異なる点についての感想 AWS Summit Berlin 2023　では、エスプレッソメニューだけではなく、ミルクを使ったメニューがあり、合計7種類のオーダーが可能となっていました。 そのため、注文が立て込んだ時、サーバレス化された注文処理システムはスケールして問題なく対応できるのですが、そのオペレーションに人の作業が追いつかず、注文を一時停止する運用が取られていました。 また、受け取るまでにも10分程度待ち時間がありました。 今回は、メニューは２種類のエスプレッソとアメリカーノに絞られており、人のオペレーションの手数が減らされており、待ち時間は数分ほどで、混雑も少なくすぐ受け取ることができました！ 些細な違いではありますが、この体験から、システムと人のオペレーションの処理速度について、設計段階でバランスをとっていく工夫が必要なんだなーと気づきを得たので、ブログで共有できればと思います！ なおコーヒーもとても美味しかったです！ そのほかブースもとても興味深いものばかりなので、ぜひ立ち寄ってみてください！！