はじめに

こんにちは。バックエンドエンジニアの齋藤です。

今回は、社内のCo-Learning委員会主催で2025年上期に行われた「クラウドデザインパターン勉強会」の内容をご紹介します。私は参加した側なので、参加者目線で紹介したいと思います。

この記事は、株式会社asken (あすけん) Advent Calendar 2025の12/11の記事です。

勉強会の背景

クラウドサービスを効果的に活用したシステムを構築するためには、設計段階での適切なアーキテクチャの判断が不可欠です。この勉強会では、クラウドデザインパターン（CDP）を学ぶことで、以下のようなスキル向上を目指しました。

クラウド特有の課題解決策の習得
高品質なシステム設計の実現
AIとの対話における要件定義・制約伝達の具体化

Co-Learning委員会とは

エンジニア組織全体の技術力と適応力を高めるため、マルチスタック開発能力の向上とAI/LLMの効果的活用を促進し、継続的な学習文化を醸成することをミッションとしている社内の委員会です。

勉強会の概要

上期に全4回にわたって開催され、各回「講義→ハンズオン」の形式で進められました。座学だけでなく、実際にAWS上でリソースを構築して動作確認できたので、説明だけではピンと来なかったパターンも理解が進みました。

回	テーマ	内容
第1回	ストラングラーフィグパターン	ALBの加重ルーティングを使った段階的移行
第2回	Valet Keyパターン	S3署名付きURLによるデータ転送のオフロード
第3回	Claim Checkパターン	S3とLambdaを連携したメッセージング
第4回	総合演習	これまで学んだパターンを用いた復習

各回の内容

第1回：ストラングラーフィグパターン

概要

ストラングラーフィグパターンは、レガシーシステムを段階的に新しいシステムやサービスに置き換えていく手法です。名前の由来は、宿主の木を徐々に覆い尽くす「絞め殺しのイチジク」から来ています。

このパターンでは、クライアントと新旧システムの間にファサード（プロキシ）を導入し、トラフィックを段階的に新システムへ移行していきます。ビッグバン移行と比べて、以下のようなメリットがあります。

段階的移行によるリスク軽減
ビジネス中断の最小化
既存システムへの投資を活かしながらの最新化

ハンズオン内容

ALBの加重ルーティング機能を使って、旧環境から新環境へトラフィックを切り替える体験をしました。重みを100:0から段階的に0:100へ変更していき、ダウンタイムなくサービス移行できることを確認しました。

感想

現在askenではバックエンドの段階的なリアーキテクチャを行っており、実際にALBでの加重ルーティングの設定も行なっているので、イメージしやすいパターンでした。段階的に移行するメリットを改めて意識できました。

第2回：Valet Keyパターン

概要

Valet Keyパターンは、アプリケーションからのデータ転送をオフロードするためのパターンです。動画や画像など容量の大きいファイルのアップロード・ダウンロードを、ビジネスロジックを処理するサーバーを介さずに、クライアントがストレージと直接やり取りできるようにします。

これにより、サーバーのプロセス・ネットワーク帯域・メモリの消費を抑えることができます。

ハンズオン内容

S3の署名付きURLを使って、アクセス制限付きのS3バケットからファイルをダウンロード・アップロードする体験をしました。署名付きURLを発行し、有効期限内であればAWS認証なしでもアクセスできることを確認しました。

感想

過去にある機能を実装した際に、将来的にこのような構成にしたいという話が出ていたのですが、実現する方法のイメージが湧きました。意外に難しくなさそう！という実感を得られたこともよかったです。

第3回：Claim Checkパターン

概要

Claim Checkパターンは、メッセージングシステムに直接データを流すことを避けるパターンです。大容量のデータをメッセージングシステム内に流すと、負荷やコストが大きくなる問題があります。

このパターンでは、送信側がデータを別の領域（S3など）に格納し、その参照キー（Claim Checkトークン）だけをメッセージに含めます。受信側は必要になった段階でトークンを使ってデータを取得します。

以下のようなケースでも有効です：

メッセージングシステムに流したくない機密データがある場合
メッセージが複数のコンポーネントを経由するが中間では処理されない場合

ハンズオン内容

S3・Lambda・Slackを連携させ、S3にファイルをアップロードするとSlackに通知が届く仕組みを構築しました。S3イベント通知でLambdaを起動し、Lambdaがファイルの内容を取得してSlackへ送信します。S3とLambda間のメッセージにはファイルの場所情報（バケット名・キー）だけが含まれ、ファイルの内容自体は含まれません。

感想

前回同様、サーバーの負荷を下げることに効果があるパターンでした。大量のリクエストを捌く必要があるaskenのシステムでは、このようなサーバーの負荷をできるだけ下げるパターンを多く知っておく必要があると感じました。

第4回：総合演習

第4回では、これまで学んだパターンを組み合わせた復習演習を行いました。4~5人のチームに分かれて、制限時間30分の中で、要求を満たす構成図をMermaid形式で作成しました。

感想

それぞれ理解したつもりでしたが、自分で1から作るとなると苦戦しました。また構成図を書くのに慣れておらず、こちらもこれから慣れていく必要があると感じました。

全体を通しての感想

Podcast「fukabori.fm」のt_wadaさんがゲストの回「AIコーディングの現在地」で、デザインパターンという共通語彙を用いることで、生成AIとの対話において少ないトークン数で文脈を圧縮して伝えられるという話がありました。当時は概念として理解したものの、自分の引き出しにパターンが少なく実践に結びついていませんでした。

fukabori.fm

今回の勉強会を通じて、単にパターンの名前を覚えるだけでなく、「どのような課題を解決するのか」「どのようなトレードオフがあるのか」を体系的に学ぶことができました。AIによるコード生成が普及した今だからこそ、生成されたコードの妥当性を判断し、適切な設計方針を示すためのソフトウェア設計の知識がより重要になってきていると感じます。引き続き学習を続けて実践につなげたいです。

社内にアーキテクチャやインフラに精通したメンバーが多くいたからこそ実現できた勉強会でした。学習機会を提供してくれたCo-Learning委員会の皆さん、改めてありがとうございました。