アーキテクトカンファレンス2025 参加報告

はじめに

こんにちは！りゅうです。先日行われたアーキテクトカンファレンス2025の2日目(11/21)に参加してきました！セキュリティ、SRE、データ分析基盤、レジリエンスなど、普段あまり触れない分野のセッションがたくさんあり、新卒1年目の自分にとって刺激的な1日でした。各セッションで印象的だったことを簡単にまとめていこうと思います！

https://architecture-con.findy-tools.io/2025

生成AI時代の新・セキュリティ脅威：アーキテクトはいかにOSS依存とコード生成リスクに立ち向かうか

このセッションは近年のAIの普及に伴う新たなセキュリティ脅威がテーマでした。外部からの攻撃にはWAFなどで備えているものの、内部に存在する脆弱性の対策は不十分なケースが多いとのこと。特に印象に残ったのは、多くのシステムが活用しているOSSに関する脅威です。

信頼できるOSSであっても特定のバージョンに脆弱性があるケースがあったり、直接使っているOSSよりもそのOSSが依存している間接的なライブラリの脆弱性による被害の方が多いというのは初めて知りました。加えて、バイブコーディング(AIによるコード生成)が普及した今だからこそ危険視され始めているスロップスクワッティング(typosquattingのAI版で、類似した名前の悪意あるパッケージを公開する攻撃)といった脅威も存在するらしく、時代の進化とともに脅威も進化しているんだなと実感しました。

自分たちのシステムが依存しているOSSをちゃんと把握して、脆弱性が発覚したときに迅速に対応できる体制を整える必要性を感じたセッションでした。

SRE視点で振り返るメルカリのアーキテクチャ変遷と普遍的な考え

このセッションはメルカリのアーキテクチャの変遷とシステムの責務の分離に関する話でした。

メルカリはLAMP構成からマイクロサービスへ段階的に移行してきたそうで、その変遷が非常に興味深かったです。やっぱりプロダクトで挑戦する限りシステムとチームは変化し続けるもので、都度アーキテクチャの見直しが必要になるんだなと。その際に重要なのがCUJ(Critical User Journey)、つまり「ユーザーにとって最も重要な体験の流れ」です。サービスのコアとなる顧客体験に対してSLOを定義して、それを監視・管理することを重視しているそうです。

いずれ自分が携わるサービスが大きくなっていく過程で、こういったタイミングは絶対来るんだろうなと。その時のために、自社のサービス・システムを理解して、阻害してはいけないユーザー体験と停止してはならないシステムを頭の片隅に置いておく必要がありそうだと新卒ながら感じました。本カンファレンスの後述するClosing Keynoteでテーマになっていたレジリエンスに通じるものがあるなと思いました。

多様な最適化サービス開発をスケールさせる共通基盤とチーム構成

このセッションは各領域にアルゴリズムを最適化してサービスを提供するシステムをスケールさせるためのアーキテクチャの話でした。

共通の基盤を作ることで重複する領域のチームメンバーを削減でき、サービスがスケールするほど恩恵を受けられるという仕組みです。共通基盤を作る上で大事なのは「どこが共通化できるのか」。今回紹介されたアーキテクチャでは、UIとアルゴリズム以外は共通化できるケースでした。最適化サービスにおいて、UIとアルゴリズムだけはそれぞれの顧客に合わせて作り込む必要があるとのこと。

ただ、どのタイミングから共通基盤を作るべきかは難しい判断で、いずれにせよ「遅い」か「早すぎた」となってしまうとのことでした。早すぎると初期の設計と違う機能追加が必要になったり、遅すぎるとそれまで個別に作ってきたものを共通基盤に乗せ直すのが難しくなるそうです。

ビジネスモデルから分析データモデルへ 〜ビジネスステークホルダーとの共創テクニック〜

このセッションは会場限定の英語セッションでした。

ここで初めてBEAM(Business Event Analysis & Modeling：ビジネスイベントの分析とモデリング手法)とスタースキーマ(データウェアハウスで使われる、中心のファクトテーブルを複数のディメンションテーブルが囲む構造)が結びついた感覚がありました。自社サービスを持つ会社のエンジニアはビジネスをスケールさせるためのシステム開発をしているはずですが、そのシステムの利用者データがビジネスレイヤーを考えるマーケターに正しく過不足なく伝わる必要があります。

今はBigQueryによるデータ分析が当たり前になってきている世界なので、マーケターとAIが扱いやすい網羅的なデータを提供できるシステム作りって大事だなと感じました。

セキュリティ評価プラットフォーム事業とともに変わり続けるアーキテクチャ

このセッションは早い段階からマイクロサービスのアーキテクチャを取り入れたシステムの話でした。

将来的に同じアーキテクチャを使って横展開する想定(※少しうろ覚えです)だったり、マイクロサービスにする必要性がある場合は、最初からマイクロサービスとしてアーキテクチャを構築するのもありなのかなと感じました。

そもそも「レジリエンス」とは何か?

このセッションは本カンファレンスのClosing Keynoteでした。英語でのセッションで同時通訳を介しながら頑張って追っていました。

レジリエンスはスイッチのようにオンオフ、持っている・持っていないではなく、グラデーション(段階的なもの)として捉えるべきだと言っていました。

そして、レジリエンスを構成する要素として4つが挙げられていました:

• Rebound(回復力): 障害から元の状態に戻る能力
• Robustness(堅牢性): 障害に耐える能力
• Graceful Extensibility(段階的拡張性): 想定外の状況にも柔軟に対応できる能力
• Sustained Adaptability(持続的適応力): 進化する状況に継続的に適応する能力

参考: Four concepts for resilience and the implications for the future of resilience engineering

また、レジリエンスを実現するための実践として7つのフェーズが紹介されました:

1. Product Development: 障害に対応できるように作る
2. Capacity Planning: どうやって障害に対応するかプランを決める
3. Testing + Release procedures: デプロイとリリースを分けることが重要。本番環境へのデプロイは積極的に行おう
4. Postmortem: インシデントの振り返り
5. Incident Response: インシデント対応
6. Monitoring: 何が起きるか監視できるようにする
7. (心理的安全性の担保)

これらのフェーズを通じて、心理的安全性が担保されていることが重要だと述べられていました。

さらに、Hexagonal model for sociotechnical systemsを使って電車の大事故の要因についても分析されていて、「オペレーションを責める文化」といった失敗を恐れる環境や、失敗しないために無理をする状況が発生したのではないかと解説されていました。失敗の糾弾はレジリエンスを下げる要因になりうるという点は非常に印象的でした。

まだ自分の中では咀嚼しきれていないですが、レジリエンスという分野に興味が湧く講演でした。

まとめ

今回のカンファレンスではセキュリティ、SRE、データ基盤、レジリエンスといった多様なテーマに触れることができました。新卒1年目の自分にとって、これまで馴染みのなかった分野への興味関心が大きく広がってよかったです。

特に印象に残ったのは、どのセッションでも「システムは変化し続ける」という前提で語られていた点です。OSSの脆弱性対応、アーキテクチャの進化、共通基盤のタイミング、レジリエンスの考え方 - すべてが変化への対応と適応に関連していました。

今回わからなかった部分も多くありますが、それはむしろ今後の学習の指針になりそうです。知識がある状態で改めて学び直したいなと思いました！

※取っていたメモと記憶を頼りに書いているので勘違いなどをしている可能性があります。その時はご指摘いただけると幸いです。