Slide 1
Slide 1 text
「図⾯」から「法則」へ
メタ視点で読み解くソフトウェアアーキテクチャ
【6社共催】スケールするサービスにおけるアーキテクチャの⼯夫‧苦労を語る会
2025年12⽉17⽇
株式会社ログラス
プロダクト基盤部 エンジニアリングマネージャー
⼩林 達
1
Slide 2
Slide 2 text
⾃⼰紹介
⼩林 達（Satoshi Kobayashi）
2
略歴
ディーバ (2004 〜 2014)
連結会計製品の導⼊‧開発
ビズリーチ (2014 〜 2024)
HRMOS採⽤‧評価の⽴ち上げ（開発部⻑）
ログラス (2024 〜)
リアーキテクチャ、共通基盤（EM）
使うモデル
Composer 1 、Opus 4.5、Gemini 3.0 Pro
趣味
娘とキャンプ、カメラ、⽇本酒
Slide 3
Slide 3 text
ここ数ヶ⽉、これまで、、
3
Slide 4
Slide 4 text
これまで、、、
「データ分析基盤」を作っています！という記事を出し、
https://note.com/loglass_post/n/n04d559e729c5
4
Slide 5
Slide 5 text
これまで、、、
「共通基盤」を⽴ち上げます！という記事も出しました
https://note.com/loglass_post/n/nba2b49ea7da5
5
Slide 6
Slide 6 text
これまで、、、
「マルチドライブアーキテクチャ」で交通整理してきました
https://speakerdeck.com/knih/multi-drive-architecture
6
Slide 7
Slide 7 text
これまで、、、
マルチプロダクトの第⼀弾「Loglass AI IR」が正式リリース！
7
https://www.loglass.jp/ai-ir
Slide 8
Slide 8 text
とあるように、
基盤の拡充に⼒を⼊れていますが、
具体的な技術⾯は、
後⽇あらためて発信していく予定です。
m(_ _)m
8
Slide 9
Slide 9 text
本⽇は、少し抽象的な話です。
9
Slide 10
Slide 10 text
提起
10
アーキテクチャ Conference の「マルチドライブアーキテクチャ」のスライドですが、
実際、⾬後のたけのこのように幾つものプロジェクトが同時進⾏しています。
Slide 11
Slide 11 text
もしかして、
「変化し続ける」ことが
あらたな「常態」なのではないか？
11
Slide 12
Slide 12 text
「変化」を前提としたときに、
アーキテクチャはどうなるのか？
12
Slide 13
Slide 13 text
そもそも、
「私のアーキテクチャに関する認識が
古いのではないか？」
（典型的な、私のアーキテクチャのイメージは「図」です）
13
Slide 14
Slide 14 text
少し過去を振り返って、
その後に現代のアーキテクチャの形について
まとめてみます。
14
Slide 15
Slide 15 text
時代背景
15
私たちが前提としてきた「変化の速度」と「変化の単位」が、
この⼗数年で劇的に、そして不可逆的に変わってしまっていそうです。
アーキテクチャの「何が『制約」で、何が『正解』とされていたか」という
価値観の変遷として、3つの時代を振り返ってみます。
アーキテクチャを設計するとは 、⼀体どういうことだったか
Slide 16
Slide 16 text
16
時代背景①
オンプレミス時代：「予測可能性」という信仰
物理的な制約が、開発のスピードを規定していた時代
‧サーバー調達は数週間〜数ヶ⽉。
‧最⼤の美徳は「予測可能性」。変更は莫⼤な
コストとリスクを伴う。
‧アーキテクチャは「城塞」の設計図。堅牢で、
揺るぎない。
‧Big Design Up Front が経済合理的だった
Slide 17
Slide 17 text
17
時代背景②
クラウド時代：「可処分性」の獲得
「とりあえず作って、ダメなら作り直す」アジャイルなアプローチが
インフラ層まで浸透。アーキテクチャはより流動的に
‧固有の名前をつけ、⼿塩にかけて育てる
‧不調になれば、原因を特定して修理する
‧唯⼀無⼆の存在として、⻑く維持する
‧番号で管理し、全体を⼀律に扱う
‧不調になれば、修理せず新品と⼊れ替え
‧個体に執着せず、システム全体を守る
The History of Pets vs Cattle and How to Use the Analogy Properly 「ペットvs家畜」をアレンジ
盆栽 農業
Slide 18
Slide 18 text
18
時代背景③
⽣成AI時代：「⾮連続な再構築」へのシフト
「リファクタリング」より「リライト」が速い世界
‧「仕様から実装へ」の変換コストが極限まで低下
‧変化のサイクル：「数年」→「数⽇‧数時間」
‧「仕様駆動開発」という名の現代版‧超⾼速
ウォーターフォール。やり直しコストはほぼゼロ
Slide 19
Slide 19 text
もはや、静的な「図⾯」は描けない。
（私のアーキテクチャのイメージは「図」 、、、）
19
Slide 20
Slide 20 text
20
もはや、静的な「図⾯」は描けない
アーキテクチャを再定義する
静的な「図⾯」から動的な「反応」へ
変化の防波堤として機能
する構成図。衝撃の伝わ
り⽅を決定づける
ストラクチャ
(Structure)
ルール
(Rules)
アーキテクチャ
変化の作法。システム
を健全に保ち続けるた
めのしくみ
Slide 21
Slide 21 text
これからのアーキテクチャに求められる 3 つの性質
（ここ数年のアーキテクチャに関する技術書や理論からの導き）
21
Slide 22
Slide 22 text
22
これからのアーキテクチャに求められる 3 つの性質
可観測性（Observability）：システムの振る舞いを透視する
• 静的な図⾯が正しくても、動いているシステムがどう
振る舞っているかが⾒えなければ、変化に対応できな
い。
• 従来の「死活監視」が"⽣きているが"を知るものに対
し、可観測性は“なぜ”そう振る舞うかを理解する能
⼒。
• ログ、メトリクス、分散トレーシングをアーキテク
チャの第⼀級市⺠として組み込むことで、変化への反
応速度を決定づける「⽬」を⼿に⼊れる
Slide 23
Slide 23 text
23
これからのアーキテクチャに求められる 3 つの性質
適応度関数（Fitness Functions）：「健全性」をコードで守り続ける
「変更に強い」といった定性的な⽬標を、定量的な指標で計測し、客観的に評価し続ける必要がある。
適応度関数は、アーキテクチャ上の⽬標（可⽤性、性能、依存関係など）をコード化し、⾃動的に評価する
仕組み。ルールを破る変更があればCIが失敗し、即座にフィードバックが得られる。「数値」を頼りにアー
キテクチャを継続的に進化させる。
Slide 24
Slide 24 text
24
これからのアーキテクチャに求められる 3 つの性質
可処分性（Disposability）：「⾮連続な再構築」を前提とする
• 「古くなったコードをいかに低コストで捨て、書き直
させるか」が重要になる。鍵となるのが「可処分性」
• 必ずしもマイクロサービスである必要はなく、「モ
ジュラーモノリス」のように内部境界が明確であれば
よい
• 他へ影響を与えずに切り離せる（Detachable）設計が
求められる
Slide 25
Slide 25 text
「メタ‧アーキテクチャ」という視点への昇華
（アーキテクチャのアーキテクチャ）
25
Slide 26
Slide 26 text
26
アーキテクティングは「個別の技術選定や構成の決定」から、
「アーキテクチャの変化そのものを管理する仕組みの構築」へとシフトしている
「メタ‧アーキテクチャ」という視点への昇華
システムの振る舞いを透視する
変化の良し悪しを⾃動判定する
いつでも構造を書き直せる
Disposability
Observability
Fitness Functions
適応度関数
Slide 27
Slide 27 text
27
「メタ‧アーキテクチャ」という視点への昇華
「形」ではなく「流れ」をデザインする
Design the "flow", not the "form"
静⽌画としての「ストラクチャ」に美しさは求められていない。
重要なのは、動画として⾒たときの「ルール（振る舞い）」の滑らかさ。
アーキテクティングは、チームの中に⾶び込み⽇々の開発の「流れ」そのものを整えることへ
Slide 28
Slide 28 text
28
詳細は Zenn にて
https://zenn.dev/loglass/articles/a31edf89fc5456
Slide 29
Slide 29 text
29
本⽇のまとめ
• 「変化し続ける」あらたな「常態」をどう捉えるか
• 時代背景：不変から流動への不可逆なシフト
‐ オンプレミス時代：「予測可能性」
‐ クラウド時代：「可処分性」
‐ ⽣成 AI 時代：「⾮連続な再構築」
• 「アーキテクチャ = ストラクチャ + ルール」で再定義
• 「メタ‧アーキテクチャ」という視点への昇華
‐ 1. Sense: 可観測性（Observability）
‐ 2. Judge: 健全性（Fitness Functions）
‐ 3. Act: 可処分性（Disposability）
• 「形」よりも「流れ」をデザインする
Slide 30
Slide 30 text
30