JAWS Festa 2025 in 金沢に参加してきた

おはようございます!DWSの木村です!
今回、JAWS Festa 2025 in Kanazawaに参加してきましたので、その参加レポートを紹介していきたいと思います!
JAWS FESTAとは?
JAWS-UG地域支部が主催するカンファレンスイベントです。毎年開催地が変わり、その土地の文化や雰囲気を活かしたユニークな企画が展開されるのが特徴です。
また、地域の企業やエンジニアが登壇し、地方からAWS活用の輪を広げていくこともJAWS FESTAの魅力でもあります。
2025年は石川県金沢市で開催されました。
キーノート
JAWS FESTAのキーノートは地方とITの取り組みに関するテーマで、毎年講演がございます。今回は「能登半島地震の復興」がJAWS FESTAのテーマとしてあったので、キーノートはそれに関する話がございました。私は実行委員として、この後話題に挙げますキーノートの「日本語文字起こし/英語翻訳対応」担当しておりました。
能登半島地震で見えた災害対応の課題と組織変革の重要性

今回、能登半島地震の震災をテーマに、震災当時副知事をしていた西垣さんより震災時の行政におけるデジタル対応と、そこから得た課題からの組織変革について、発表がありました。
地震発生時に災害関連死を防ぐため、石川県として下記3つのステップで、避難者への支援に取り組みをしました。
- 避難所情報の把握(場所と人数の把握)
- 避難者情報の把握(支援対象を特定)
- 生活再建支援(どこにいてもニーズに対応した支援)
1. 避難所情報の把握(場所と人数の把握)
まず、避難所情報を把握しようと取り組んだのですが、3つの課題に直面したようです。
- 避難所情報が独自様式(Excelや紙など)
- →県職員が市町に出向き入力が必要
- 指定避難所以外の避難先が多数発生
- →避難所情報が一致しない
- 避難所名簿が入力できない
- →避難者数の増減情報だけでは、人の移動が把握できない
これによって、システムが把握している被災者情報と、それに必要な物資の量が合わない問題が発生したようです。
これら課題への対応として、自衛隊と協力し、各避難所の写真を撮影し、写真データから、避難所の状況と、緯度経度の情報を取得できるようにし、「どこに避難所があったか/避難所の場所を地理的に把握」する土台情報を補強したそうです。
また、各市町村で登録されている避難所名が異なっても実際には同じ場所である可能性を考慮し、重複排除・統合する処理(名寄せ)を行ったようです。
2. 避難者情報の把握(支援対象を特定)
次に避難者情報の把握についても下記のような課題が発生したようです。
- 被災者は避難所ではなく自宅や、納屋、ビニルハウス、土蔵などにも存在
- 災害関連死を防ぐために、避難所以外の被災者を把握する必要性がある
- 被災者が広域に避難
- 広域で被災者情報を把握・共通化する仕組みが必要になった
震災発生時に避難者数は34,173名ほどいたが、その中で「その後どこへ移ったか」が把握できない人が17,102名ほどいたようです。
これに伴って、市長、県、関係機関が必要な情報を連携する被災者データベースを構築したようです。
被災者データベース整備としては、避難所外にいる被災者(指定避難所以外の避難先・自宅帰還者など)を把握するために、被災者自身が情報を入力・アクセスできる手法(例:LINE、マイナンバーカード連携、オンラインフォーム等)で検討し、現在石川県ではSuicaなどのICカードを活用した被災者の所在・動態把握システムの導入が進められているようです。
3. 生活再建支援
現在、「被災者生活再建支援システム」によって、支援メニューの発信が行われているようです
被災者はこちらを確認することで、被災証明書の発行や、特別給付金の申請などを把握することができ、より広域の避難先でも情報が届くようになっているようです。
また、このシステムによって、情報発信媒体(メールやLINEなど)が避難者ごとに異なり、行政の負担が増すようなことが起こらないようになっているようです。
JAWS-UGの災害支援と石川県の災害を振り返る - エンジニアクロストーク
ここでは、下記3テーマでクロストークがございました。
- 東日本大震災でのJAWS-UGの活動
- 実家が能登の方にある被災したエンジニア達による震災時の様子
- デジタル庁:災害派遣デジタル支援チームによる震災に対してエンジニアがどう貢献できるかについて
当時は自治体のDNSサーバーもオンプレミスにあったようで、
自治体が管理しているデータは津波で流されてしまい避難所などのも発信することができなかったようです。そこで、現在はAWSクラウドを活用を進めており、実際、熊本地震では、湧水場所の情報を示すアプリが役に立ったようです。
実家が能登の方にあるエンジニアたちのトークでは、震災後は、金沢でもスーパーから食料が消え、さらに能登方面の道は地割れでとても車を走らせられる状態ではなく、物資などを実家に届けに行ける状態ではなかったよう。
また、実家は無事だったようだが、近隣の建物は倒壊しており、実家までの道も通れる状態ではなかったと、能登半島地震の現状について、説明いただきました。
そういった状態の中で、エンジニアがどう震災に貢献できるかについて、災害派遣デジタル支援チームより発表がありました。
デジタル庁は2025年8月5日に「災害派遣デジタル支援チーム(D-CERT)」創設しており、大規模災害時に民間のデジタル人材を被災地に派遣し、行政のデジタル対応を支援する新しい仕組みが導入されているようです。
D-CERTは、平時と災害発生時で異なる役割を担います。
- 平時の活動:派遣要員のリストアップ、研修実施、過去の災害派遣の知見のとりまとめ、制度の周知・広報、意識啓発など
- 災害発生時の活動:被災地に入り、被災都道府県の幹部(CIO/CDO)やデジタル・防災部署等との関係構築、被災状況や支援ニーズの把握、支援活動方針の決定などを行い、現地でのデジタル支援を実施
この支援チームによって、震災時にエンジニアが重要な役割を果たすことができるようになっているようです。
セッション
午後より、セッションが各会場であったので、そちらを聞きに行ってきました。私が聞いたセッションの内容と感想を以下より記載させていただきます。
業務効率化をさらに加速させる、ノーコードツールとStep Functionsのハイブリッド化
Step Functionsの実践レベルでの活用の幅を知りたくて聞きました。
内容としては、自社のAtlassian(Jira, Confluence, JSMなど)をオンプレ版からCloud版に移行したときに、Jira Automationというノーコードツールを用いて作業の自動化や、 各種Cloudへの接続を行ったが、痒いところに手が届かないので、StepFunctionを用いたハイブリッド構成をとることで、その問題点を克服した話でした。

上記のようなフローにすることで、JSM周りの処理はJira Automationの方が適切で、Jira Automatioでできないネストされた条件分岐や値の変換などの処理はStepFunctionの方でやるといった、それぞれの良さをとった構成を行ったようです。
私としては、「StepFunctionはJSONataが導入されたことのにより、多種多様な値の変換処理が行えるようになり、よりシンプルなフローを作れるようになった。」というところが気になりました。
「JSONata便利!」という話はちらほら聞いてはいたものの、しっかり触っていなかったので、今度ハンズオンでもしてみようと思いました…
一応、調べると下記記事が大変わかりやすかったので、私も含めたJSONata初心者は下記記事を参照してみてください!
StepFunctionsがJSONataに対応したらしいので試してみた
https://qiita.com/ayukichi0219/items/7a190002dec12f1f4aca
メールの検索に困ってたのでAmazon SESに転送してS3 VectorでRAGに!
S3 Vectorが気になって聞きに行ってきました!
Amazon SESで受けたメールをS3 Vectorに入れ、それをBedrockからメールについて質問すると、返答を返してくれるAIを作ったという話です。

AWSの構成は上記のようで、「Lambdaの処理が失敗しても、再実行できるように、SQSやEventBridgeをわざわざ挟んでいる」ようです。
現場での SQS 活用方法をより具体的に学ぶことができ、非常に勉強になりました!
また、「OpenSearch Serverlessを使う代わりにS3 Vectorを用いることで大幅なコスト削減を実現した」というところも、勉強になりました。調べてみると、通常のS3同様、従量課金なので、それほどデータを入れない状態だと数百円~数千円/月で済みそうです。
まだ、S3 Vectorはベータ版のようですが、今後RAGの検証する際は、積極的にS3 Vectorを使おうと思いました。
オンプレ→S3の大容量データ移行におけるサービス選定のリアル

オンプレからの移行方法に現場レベルでどんなサービス使っているのだろう?というところが気になり、聞きに行きました。
内容は移行サービスに様々な制約があり、技術選定ではこんな考えることがあるよと言った内容になります。
例えば、AWS DataSyncは仮想マシンにAgentを入れて移行をするのですが、「Agentを動かすために32GB、もしくは64GBのメモリが必要」であったり、Snowballも「10個注文したら、一気に10個のSnowballが到着するわけではなく、全部届くまでの移行がスタートできない」と言ったり、それぞれの移行サービスについての、色々な制約があるようです
登壇者の方も、S3への移行のためにAWS DataSyncを検証したけど、色々制約が判明し、納期までに検証が終えられそうになかったので、最終的にAWS CLIで、 s3 sync
コマンドを実行し、移行したとのことで、私も昔、DBの移行でdumpコマンドで移行する方針にしたときもそんな感じだったなと思い出しました。
大規模サーバーレスAPIの堅牢性・信頼性設計 〜AWSのベストプラクティスから始まる現実的制約との向き合い方〜
サーバーレス構成の課題や、課題に向き合った結果何が最適だったか、現場レベルで導き出した答えを知りたく聞きに行ってきました。

上記のようなフルサーバーレスな構成で、下記のような要件があり、その要件に応えられるように、構成を考えたという内容になります。
- セキュリティ
- データの適切な保護
- 基準はAWSのベストプラクティスに沿っているか
- 性能要件
- 200~500ms 以下の通信
- エラー率0.01%未満
- イレギュラーなピーク時にも落ちない
- リクエスト数は数十〜数百RPS
セキュリティ性を担保するためにOpenSearchをVPC内に入れたけど、踏み台からの通信が必要になり、踏み台で使うEC2の管理の手間、コストの増大や、セッションがよく切れて使いにくくなったりと、ちょっと不便だなってことで、VPC入れない判断をしたそうです。
ただし、要件に「データの安全な保護」があるので、力技的にリソースポリシーにOpenSearchを実行するLambdaのIAMロール(約20個)を登録したようです。
また、スパイク対策のためにOpenSearch Serverlessを採用しようとしたが、OpenSearch ServerlessだとIP制限ができなかったり、要件で出ていた必須のプラグインが使えなかったそうで、採用を断念…
こちらも地道ですが、 CloudWatchのダッシュボードを確認して、最適な運用パフォーマンスの出るインスタンスタイプを人間の目で判断するようにしたようです。
なんだか、職人芸みたいですが、結局色々要件が重なってしまい、AWSサービスの制約で選択肢がなくなると、こうせざるを得ないパターンも出てくるのかと思いました…
実行委員としての関わり(日本語文字起こし/英語翻訳対応)

今回私は実行委員として、キーノートの日本語文字起こし、英語翻訳機能の開発にも関わりました。
開発の目的としては、耳が不自由な方や外国の方が参加されることを考慮するためになります。文字起こしはAmazon Transcribe、Amazon Translateを用いて行なっております。
色覚特性のある方にも配慮し、誰にでも見やすい色合いになるよう調整しました。
また、こちらの作成内容については別途ブログなどに起こしていこうと思います!
実行委員は初めての経験でしたが、普段参加しているコミュニティが、大変な準備をもとに開かれているのだと実感しました。また、コミュニティ活動が成功することで、今まで以上に達成感が感じられることも知ることができました。
今後も、また機会があれば、実行委員として参加したいと思いました!
交流
オフラインのイベントに参加する最大の意義としては、やはりコミュニティメンバーとの交流だと私は思います。
そこから得られるものは知識だけでなく、強いエンジニアから様々な刺激をもらったり、色々なつながりができたり、その価値は参加した人しかわからないものが多くあると思います。
今回も、DWS参画後、初めてのJAWSの参加ということもあり、「DWSのメンバーで知り合いがいます!また、勉強会しましょう!」といった話も上がるなど、オフラインだからこそ得られる貴重なつながりを感じました。
まとめ
今回、「能登半島地震」がテーマになっており、震災の際に裏側で様々なシステム的問題が起こって、その問題に対して今後の地震に対しての対応が進んでいることも知れました。
「エンジニアとして働く上で、震災は無関係な話ではないんだな…」ということを実感する機会になりました。
また、今回JAWS FESTA 2025は地方イベントにも関わらず300名ほど参加者がいたようです。改めて、JAWSの熱、AWSの熱が凄い!実感しました!
「参加したことがない!」という方がいましたがら、ぜひ一度参加して、その熱に当てられてみることをお勧めします!