みんなの「データ活用」を支えるストレージ担当から持ち込むAWS活用/コミュニティー設計TIPS 10選~「作れる」より、「続けられる」設計へ~

2026/04/18 JAWS-UG横浜 #100 祝・第100回スペシャルでの5分LTの内容です。

Transcript

1. JAWS-UG横浜 #100 祝・第100回スペシャル 100回の歩みを振り返りながら、これからのJAWS-UG横 浜をみんなで楽しむ記念イベント 「作れる」より、 「続けられる」設計へ みんなの「データ活用」を支えるストレージ担当から 持ち込むAWS活用/コミュニティー設計TIPS 10選 AWSユーザー・パートナー・ビルダーとして、 「作れる」より「続けられる」で設計を紹介 〜AI/人類短期記憶時代における継承できるシステム/コミュニテ ィーへ 〜 5分LT提案 / Speaker notes付き 1 Storage-JAWS 藤原 善基 Disclaimer：本日の発表内容は所属する組織を代表するものではありません。
2. 「作れる」より「続けられる」 短期で動く構成/コミュニティー は作れる。 でも、運用・監視・説明責任・ 引き継ぎ含めて強い構成は、 別の判断軸が要る。 • サービスや機能ではなく、先に要 件を決める • 障害時に説明できる構成を選ぶ • 監視・ドキュメント・復旧まで設 計に含める 結論: 今日の10個のTipsは、全部 「続けられる設計」へ寄せるための 視点です。 →システムも、JAWS-UGのようなコミ ュニティー運営も今日のように錚々 たるメンバーが祝いに駆けつける状 態で「続けられる」ということにす ばらしさがあると思い、100回目に合 わせたメッセージとしました。 2
3. 藤原 善基（ふじわら よしき) ネットアップ合同会社 AWS SE Support / Sr. Cloud Solutions Architect – AWS AWS Community Builder 2023(Storage)、2024-2025(Cloud Operations) 2024-2025 Japan AWS Top Engineers(Software) 最近やっていくること：生成AI、ランサムウェア対策、仮想化環境のAWS移行/拡張 経歴 • 生後10ヶ月から7才までギリシャのアテネ(1986 - 1992) • 物流業の営業→コールセンターのオペレーター→SIer ヘルプデスク →SIer インフラエンジニア→ネットアップ合同会社 ← 今ココ 趣味 • 技術イベントへの参加・旅行・外食・ロックフェスティバルに行くなど • Storage-JAWS運営メンバー 好きなAWSのサービス • Amazon Elastic Container Service • Amazon FSx for NetApp ONTAP • AWSサポート • Amazon S3 自己紹介 Amazon Elastic Container Service Amazon FSx for NetApp ONTAP Amazon S3 Access points
4. Storage-JAWS 運営目的 • AWS上で「ストレージ」を活用するための議論や情報発信を していく場を作る • サービスやビジネスを加速するための活用方法も 参加対象者 • AWSストレージに興味がある方なら誰でもOK！ • 初心者から上級者までWelcome！！ • JAWS-UG Slack "#storage-jaws"で情報発信中！ • 他の専門支部、地域支部とのコラボを推進中！ https://storage-jaws.connpass.com/
5. 個人的な他のJAWS-UGとのコラボ：AWSのStorage観点で登壇。楽しく全国をま わりながら過ごしていますので、気軽にお声がけください。 • 専門支部 • 地域支部 • 地域支部 x 専門支部
6. 個人的なBuilder実践:去年JAWS-UG秋田で発表したKiroを利用 した個人？開発のその後…
7. 個人的なBuilder実践: Kiroと進めた Agentic-Access-Aware RAG System 公開している OSS は、Amazon FSx for NetApp ONTAP の ファイル権限情報を使って、Amazon Bedrock 上で Access するユーザーのファイルサーバーの権限に基づいてKBある いはAgent型の RAG を構成する AWS CDK サンプル。マルチ Agent、S3 Vectors、Bedrock AgentCore、Agent Registryな どを取り入れている。UIもドキュメントも8ヶ国語対応 →「Kiroのクレジット消費が激しい。」 Chrome DevTools MCP: Chromeブラウ ザでの動作検証、スクリーンショット 撮影、console / networkログ調査をKiro に一任し、UI確認の手戻りを減らした 実運用寄りの補助: Lambda tools で 関数確認、必要に応じてAWS系MCPも 併用。Hooksより、MCPサーバー群で 検証と修正のループを回した 「速く作る」より、ブラウザ検証・ロ グ調査・修正・公開までをAIと一緒に 回せる方が、あとから続けやすい Personal Kiro practice 7 “速く作る”より、“検証と改善を回し続ける”ための実践 個人的に強く効いたのは MCPサーバー活用 MCP orchestration: GitHub / filesystem / fetch / AWS knowledge / memory / sequential thinking を用途別に使い分け 実装・調査・公開をKiro上で往復した • https://github.com/Yoshiki0705/FSx-for-ONTAP-Agentic-Access-Aware-RAG 何を作っているか
8. TIP 1 捨てられない要件から決める サービスや機能から入らず、最初に “捨てられない要件”を決める。 見るポイント Tip 1 / 10 3 可用性・RPO/RTO・性能・運用負荷など、 先に外せない条件を固定してからサービスを 選ぶ。 →コミュニティーの場合：イベントの開催時期 ・開催方法 ・ 得たい結果 ・ 運営の Ownershipなどを明確にする
9. TIP 2 障害時に説明できる構成を選ぶ Tip 2 / 10 4 “作れる”構成より、“障害時に説明できる ”構成を選ぶ。 何が壊れたら、どこまで影響し、どの経路 で何分で戻すかを言える設計にする。 →コミュニティーの場合：想定外の事態が起 きた時に、何を優先して運営していくか、 最低限何をいつまでにできるべきか、 を言える運営にする。 見るポイント AWS Elastic Disaster Recovery (AWS DRS) Recovery point objective Recovery time objective Compliance reporting Backup restore
10. TIP 3 オブザーバビリティー を判断材料として置く 5 オブザーバビリティーは“異常検知”ではなく、 “判断材料の蓄積”として置く。 見るポイント メトリクス・ログ・トレースを後からつな げて見返せることが、継続運用では効く。 →コミュニティーの場合：過去開催イベント のオブザーバビリティーがあると、新メン バーのオンボーディング、次回開催イベン トの設計や運用に効く。 Amazon CloudWatch AWS Config AWS CloudTrail
11. TIP 4 バックアップは戻せて初めて価値がある Tip 4 / 10 6 バックアップは“あること”ではなく、“戻せ ること”で評価する。 見るポイント 取得済みより、復旧手順・検証・役割分担 まで含めてリストアできる状態を作る。 →コミュニティーの場合：それぞれの係を決 めておいて得意な人に任せつつ、フォロー し合ってチームとしてリストアできる状態 を作る。 AWS Backup Snapshot Amazon EFS Amazon FSx
12. TIP 5 単価より継続コストを見る Tip 5 / 10 7 コスト最適化は単価ではなく、 運用込みで見る。 見るポイント 安い構成でも毎回人手がかかるなら高くつ く。月額より Total Cost で判断する。 →コミュニティーの場合：なるべく無料ある いは安価なツールを使う意識を持ちつつ、 有限/無償の運営メンバーの時間やツールへ のモチベーションなどとバランスを取る。 AWS Budgets AWS Cost & Usage Report AWS Cost Explorer
13. TIP 6 PoCで壊し方まで見る Tip 6 / 10 8 PoCは“動いた”で終わらせず、“壊した時に どうなるか”まで見る。 見るポイント 本番で困るのは正常系より異常系。PoCで Failure Path を先に体験しておく。 →コミュニティーの場合：イベント会場の下 見やセットアップなどの際に、ネットワー クが切れたり、画面が切り替わらなかった り、マイクが入らない時、悪天候などを想 定したテストを行う。 AWS Fault Injection Service
14. TIP 7 移行は責任の置き場の移動 Tip 7 / 10 9 移行は“データやツールを動かす作業”、 ではなく、 “責任の置き場を移す作業”だと考える。 見るポイント 切替判断・チェックポイント・ロールバッ ク担当を先に決めると進む。 →コミュニティーの場合：同様に先に決めて おきつつ、運営全体としてOwnershipを 持って決める。選定も運用も、突破力のあ る人依存のままにしない。 AWS DataSync AWS Migration Hub AWS Migration Evaluator
15. TIP 8 運用は引き継げる文章にする Tip 8 / 10 10 運用設計は“引き継げる文章”になっているか で見る。 見るポイント Docs と Runbook が次の人に渡る形で整っ ていると、属人化せずに続けられる。 →コミュニティーの場合：AIの力を使ったド キュメント化と検証を行う。異なるAIモデ ルを使って複数回再実行した際に意図通り の回答が来ないようであれば、ドキュメン トのコンテキスト見直しが必要。 Document
16. TIP 9 速さより意図の追跡性 Tip 9 / 10 11 生成AI開発/運営はプロンプト力より、仕様 とタスクの追跡性が効く。 見るポイント Spec→Task→Code→Why が残ると、後から変 更理由をたどれて改善しやすい。 →コミュニティーの場合： AIの力を使ったド キュメント化は省力化して可能なので、引 き継げる コンテキスト をチェックポイント ごとにCommitする。 Traces
17. TIP 10 すぐに触れる設計 Tip 10 / 10 半年後に触れる設計 12 最終的に大事なのは、“今自分であればうま く動く”より、“誰でもすぐに触れる”こと。 人であれば半年後、AIであれば「別のAIで も」「すぐに」触れること 見るポイント 将来の変更レーンを用意した設計が、アッ プデートや拡張で効いてくる。 →コミュニティーの場合：変更に備える。既 存の人が参加できなくなったり、新規の方 の参加想定で、今の構成をすぐに触れるよ うな仕組み・雰囲気作りを行う。 Contributeできない/任せてもらえないチー ムにOwnershipがある人は、熱量を保てな い。
18. まとめ AWS/コミュニティーは、 作れるより、 続けられる設計へ ストレージの現場でも、 Builderとしての開発でも、 コミュニティーでも、 最後に効くのは「将来の変更に耐える設計」 →将来の変更を「楽しめる」 設計だと思います。 楽しんでいきましょう！！ 捨てられない要件は？ →先に要件を決める 説明できる障害設計 →障害と復旧を「数字」で説明できる 戻せるバックアップ →リストアまで検証し続けてこその バックアップ 引き継げる運用 → 監視・文書化・引き継ぎまで 設計する 追える仕様と変更 → AI開発だからこそ、 意図の追跡性を残す 6 1 8
19. ご清聴ありがとうございました！！ 今後も、Storage-JAWSや個人として地域支部、 専門支部とのコラボをやっていきますので、 よろしくお願いします！ Thank you!!