オライリー『プラットフォームエンジニアリング』のレビューに参加し、献本をいただきました！
レビュー時点でも、幅広いベストプラクティスが紹介された良書だと感じていたので、改めて読み直すのが楽しみです。
https://t.co/BYYYIOlXXQ https://t.co/iksL3YCwl8 November 11, 2025

書籍コーナーでプラットフォームエンジニアリング本が先行発売されてたので、購入。あとで読むぞ〜

#アーキテクチャcon_findy https://t.co/2nX0ldUrrg November 11, 2025

翻訳レビューに参加していた『プラットフォームエンジニアリング』本の献本が届きました。ありがとうございます！
「プラットフォームエンジニアリングなんぞや」の議論の出発点にふさわしい一冊かと思いますー
11/29発売とのこと https://t.co/vVLjk95dAa November 11, 2025

アーキテクチャ Conference で学んだ内容をシェアします！

マイクロサービスにするべきかどうかは、 「それによって得られる成果」 が明確かどうかで決まる
- 「マイクロサービスにしたい」 自体が目的にするのではない
- Deploy の速度が遅くなったなど、マイクロサービスにする必要性を認識した時に、初めて検討する。
- 手段を先行させない

モジュラーモノリスから、マイクロサービスに移行する時の手順とコツ
1. 徐々に移行していく
2. 新サービスの開発とデプロイを分けて、作った後にすぐリプレースしない
3. 旧サービスも残しておいて、新サービスがバグってた時もすぐにロールバックできるようにする
4. 新しく作ったサービスを測定しつつ、正しく動作しているか？コストはどれだけか？を図る

ユーザーもビジネスサイドの人も、 「マイクロサービスかどうか？」 は気にしていない
与えられる価値によって、マイクロサービスにするかどうかは決めるべき
与えられる価値が、マイクロサービスによって増えるなら、マイクロサービスにする

アプリケーションの規模は、次第に大きくなっていく
それに伴い、デブロイの時間やデグレチェックなどで、変更を反映するまでにかかる時間が増えていく。
これを回避するためにも、マイクロサービスは有効
重要なのは、小さくてかつ頻度の高い変更。

セキュリティ要件は、クリティカルになりうる。
そのため、サービスが小さいうちから意識して予防したり、安全に扱う仕組みを作ることが大切。

開発チームを、サービスチーム(そのチーム内で用件定義 ~ テストまで行えるチーム)で完結させると、迅速な意思決定と主体性を育める
- コミュニケーションコストが低くなる
- 信頼関係を建築しやすい。なぜそれをやろうとしているのか？とか背景情報・考えていることを理解できるから、コミュニケーションの摩擦が少なくなる。
- サービスチームがプロダクトに対するオーナーシップを持つので、主体性も育める

ドメイン型のチーム と プロジェクト型のチームのメリットデメリット
ドメイン型のチーム体制
メリット
- 持続可能性高いエンジニアリングができる
- 深い知見が溜まりやすいので、オーナーシップを与えやすくなる
デメリット
- ドメイン分割する協会を定義しにくい
- 非注力なドメインがある場合は、開発チームを継続的に配置するのが難しい。注力対象が変わるスタートアップだと難しい。

プロジェクト型のチーム体制
メリット
- チーム組成が簡単
- 開発作業に集中できる
デメリット
- 持続可能性が低い
- 深い知見がたまらない。一年前に作った機能を忘れて、開発効率が遅くなる。

もしプロジェクト型にしたとしても、持続可能性について検討しておく
事前に誰が、何をやるか？という所を決めておくと、責任が明確になるのでおすすめ。

サービスメンバーが、全員 「フルスタック & フルサイクル」 だとコミュニケーションコストが減る
また、職能におけるボトルネックの排除ができる。職能で分けると、何かの職種のタスクでボトルネックになるので、そこを避けることができる。

チームにコードな専門性が必要かどうか？
- 現在は、クラウドなど 「テクノロジーのコモディティ化による恩恵」 がある
- そのため、ある程度はジェネラリストでも対応できる。
- 専門性の高い領域は、横断チームとして切り出す
- セキュリティチームなどは、別で切り出せばいい
- 実際は、人にはそれぞれ得意領域があるから面白い
- そのため、専用の人を雇わなくても、誰かが得意、という状況が起こる

必要に応じて専門職を採用するメリットもある
- 専門職の人によって、周りの人たちのレベルを上げることも出来る

サービスチームとして、必要な意思決定ができる
- ここも、職種ごとにチームを分けていたら、上手くいかない

現場チームに採用の権限を任せるのも有効
- 現場の人が一番どんな人が欲しいかわかってる。
- 募集要項、スカウトメールまで現場の人が考えたりする。
- また、最終的には登壇などによる認知度向上など、活動勝負になるので、オーナーシップを与えることが重要
- 随時 HR の人ともコミュニケーションをとる

規模が小さいと、オーナーシップを発揮しやすい反面、知見の共有や技術的なエコシステムの構築は難しくなる。

AI はいづれ人間を凌駕する、それは段階的に起こりうる
最終的には責任を負って、信頼を勝ち取ることが人間に役割になる
- AI は、責任を果たすことが難しい。
- 人間は AI を信頼し切れるのか？という疑問が残るので、人間がここを保証する必要が出てくる
具体的には、最後の検査等を人が行い、責任と信頼を持つのが大切。

人に求められる責任の量が今後多くなるのではないか？
- 求められる責任の量が増える
- 求められる責任の水準も上がる
- 非エンジニアのリテラシーが向上して、定量的な信頼性と適切な説明責任が出てくる

今後エンジニアは、AI の成果物に対してどう検査していくべきか？
今後は、専門的な知見をもとにした説明が必要になる。
- 判断の基準(客観 <-> 主観)
- タイミング(予防 <-> 回復)
などの軸で、検査を進める必要がある。

アーキテクチャは、認知負荷を軽減する鍵になる。
上手くアーキテクチャを構築すると、人がレビューするときの負荷を減らせる

AIでの開発を進める上で、重要なアーキテクチャ 6選
- 境界付けられたコンテキスト
- イベント駆動アーキテクチャ
- CQRS(Command Query Responsibility Segregation)
- AVDM(Always-Valid Domain Model)
- Type First
- 型エラーで事前に駆動できる
- Event Sourcing
- なぜそうなったのか？の検査の精度もあげられる

CQRS を取り入れることのメリット
ファイルごとに処理を分けることで、 「人がどこに注力するべきなのか？」 をチェックできる。
レビューした方がいい所は重点的に見つつ、そうじゃない所はテストと型エラーを軽く見るだけで済む。
このグラデーションをつけることが重要

サービス設計時、 「その機能が必要な理由」 をなぜなぜと繰り返して問いかけて理解する
それにより、お客さんのことを理解できるようになり、ユーザーの真のニーズが見えてきて、製品にもそれが反映されるようになる。
同時に、ユーザーの課題を解決することで自信がつくようにもなる。
また、必要に応じてセールスとも会話して、今顧客が何を求めてるか？も随時把握する

Figma の アーキテクチャ や 技術前提の選定基準
パフォーマンスを最重要に考えている。
フレームレートは、1秒あたり60コマから30コマにならないか？などを重点的にテストする。
ここの最重要事項、ケアするべきとこは、集中して確認する。

アプリケーション のパフォーマンスは、エンジニアリングの問題だけではない
デザインが問題になる可能性もある。新しい機能を出すことで、既存のサービスイメージと競合する時がある。
時には、既存サービスを切り捨てる必要もあるし、新しい機能を区別させないように同化させたりして、初めの利用障壁を下げる工夫なども必要になる。

AI によって役割が変わったとしても、常に 「ユーザーが何を求めてるからを徹底して考える」 ことが重要
エンジニアであれば、実現可能性の観点から見る
また、肩書きでは無くて、何をやるか？が重要になる。
どうしてこれをやるか、なぜそれの優先順位が高いのか、
ここは、製品の整合性などで、Why How を出しつつ、人間的な所から、ベストな経験はなにか？を考えたり、ビジネスの経験から、ベストなものを得る。

アイデアは、面白い、ワクワクするようなストーリーから逆算して作る。
そこからのストーリーを作らないと、意義が少なくなる可能性が出てくる。
ナラティブから始めて、実際の付加価値をつけていく

新しい機能を作り出すなら、まずは何を考えるべきか？
最初に頭に浮かぶ時は、最初はスタンダードな、なぜそれをやるのか？そして、どうして面白いのか？なぜそれがワクワクするのか？
ユーザーが見た時に、 「それは価値がある」 って分かるならいいアイデア。
逆にすぐ理解できなかったら、何か間違えている可能性がある。

プラットフォームエンジニアリングとは？
会社組織としての組織と、価値創出を目的としたチーム
仮想組織として、PMやデザイナーなどの職種のメンバーを全員入れて、それぞれの職能を持った人が集めたもの。
対象のサービスでバックエンドが既に作成済みなら、フロントエンドだけのチームも作る。

Platform Engineering が作成されるきっかけの一例
開発チームが全てを担当するのはするのは限界がある。だからこそ、インフラ周りの整備の専門家で切り出したりする。

会社の状況に応じて、専門領域を作るべきか変わる。
- 小さい会社なら、少人数で全部やる
- 大きい会社なら、分業していく
- 中間層として、PFEでオフロードする、が入る。規模が大きくなりと分業が進む。

AI に色々なタスクを任せると上手く動かない
必要に応じて、AWS Resource Explorer を使うなど、必要なリソースをわかりやすい形でアクセスさせるのが大切
これをSQlite でインデックス化すると、より高速にアクセス可能にもなる。

必要に応じて、人間が補足情報を加える
ソースコードのリバースエンジニアリングだけだと、 「なぜそれをしたのか？」 の文脈が失われがち
なので、わからないこと・決まってないことを人が決めた上で、再度 AIに考えさせるのが大切
AI に推論させず、人間が必要な背景情報は人が与える
この時に、 「まだ決まってなかった、必要な仕様を認識」 できるので、ドキュメントの質向上に加えて、足りてない項目は補足できる。

Devin を使うメリット
雑に聞いても、複数のレポジトリを横断して調べてくれる
つまり、一メンバーとして動いてくれるし、プロンプトで正しい情報を与えなくても、いい感じで回答してくれるのは大きい。

AI の本質的な 3つの力
- 幅広い知識の補完
- 文章・コード・情報の整理
- 人間の得意なことを支えて、面倒なことをやってくれる

90% の簡単なコードを書くことには価値がなくなった、でもどんなコードを書くべきか、のアーキテクトの重要性は1000 倍になった。という名言があった。

AI は知識の代替ではなく、能力の増幅機
- 使い手の能力をがないとダメ
- AI を能力向上のために使う必要がある
- 結局、自分自身のスキルアップが大切

AI コーディングの価値はスピードだけど、一方で品質が落ちる。
結局人がレビューする必要がある。
またアーキテクチャはコンパスで、完璧な地図は書けない。あくまで方針を示しているだけ

コードの複雑性は、2種類ある
- Essential Complexity
- ドメインに固有、除去不可能
- Accidental Complexity
- 技術的制約、フレームワークで削減可能
偶有的複雑性をどれだけ削減できるか？

データベースによる制約に縛られないため、インメモリの中で解決できるようにする。
モデル全体や設計を、データベースとは異なる方法で構造化する。
初めは大変だけそ、後々楽になっていく。

イベントソーシングの本質
- 全ての変更を記録する
これは、ステートソーシング(データの現在の状態だけを保存する)とは異なる。
これがあると、何が起きたか？を流れとしてわかるようになる。

Always Valid Domain Modelとは？
- 常に正しい状態を、インメモリで DB とは関係ない状態で作る
例) C# で、Pureなオブジェクトを作る。

後悔しないアーキテクチャを作るために、最初からスケールアウト出来る設計で作っておく
- 後々で、DBがボトルネックになる。
- 最初からやっておけばよかった、を防げる。

結合のバランス
- 実装や進化、メンテナンスが容易なモジュラーシステムを設計すること
- 結合の3つの次元全てを考慮すること

AI時代での 開発者の役割
- アーキテクチャの方針を決定
- ドメインの本質を理解
- 制約とガードレールを定義

まずは小規模でスタートして、徐々にスケールさせる
- ある程度コストを前払いする必要がある
- 学習コスト、初期設計、フレームワーク選定も重要
- これにより、後々からの後悔を避けることができる。
判断基準としては、将来のリアーキテクチャコストがどれだけかかるか？後でリアキクトするなら、作る前から意識する。

設計は選択肢を知っておくことが重要
- 詳しく知らなくても、コンセプトを理解していると、AI のアシストで採用していくことができる
- また、完璧ではなく、 「選択に納得できる」 ことをすることが重要

情報は、AI が収集・生成・提案して、人が判断するようになる
AI が読める情報を増やしていく、 AI リーダブルな情報設計が必要

情報負債が起こる原因は？
- 分散
- 形骸化
- 属人化

なぜ情報が分散するのか？
- ドキュメントの責任範囲が曖昧
- 検索性・再利用性よりスピードを優先
- 情報構造の設計思想が存在しない

AI ナレッジベースによる情報の一元化
- 事業運営に必要な情報を一元管理
- 人が必要な根拠・文脈に辿り着けるようにする
- 人とAI が同じ情報で判断できるようにする

形骸化する原因は？
- ドキュメントが利用できず、古いまま放置されてる
- チームの運用手順書が古いので、手戻りが発生
- 結果的に、AIが間違った分析をしてしまう

なぜドキュメントが形骸化するのか？
- 頻繁な仕様変更に追従が大変
- 古くても誰も困らず、責任が曖昧
- 成果に直結しにくい
保守が後回しになりやすい構造になる。

ドキュメント運用の自動化は？
Docs-as-Code でドキュメント運用の自動化をするといい。CI で常に更新させる。
また、Cron で定期的に情報収集させる。
必要な加工をした上で、ナレッジの情報収集を行えるようにする。

なぜ情報が属人化するのか？
暗黙知による属人化が起こる。
- 知見が個人に依存してる
- 「あの人しか知らない」 を放置しても、問題化されない
- 誰がどの知識を持っているかが分からない

属人化の対策方法
- AI 前提の業務プロセス設計を構築する。
- ドキュメントが自動的に生まれる仕組みを作る。
- 会議 -> 自動要約 -> ナレッジに自動追加

AI ナレッジベースの情報設計は？
- GitHubレポジトリを採用
- レビューや自動化を容易に
- Markdownを利用する
- AIの挙動を制御するガードレールを整備する、など

ドメイン知識をナレッジベースで貯めておくと、意図に沿ったクエリを出せたり、結果を出力できる。
その結果、設計の壁打ちでも使えるようになるかもしれない。

定期的にAIに動かして、ドキュメントを常に更新する
- 情報 × 状態 = 次のアクションを決める
- 推論させる時と、機械的に動かす、をきちんと分ける。
- 業務推進の自動化がどこまでできるのか？が重要になる

マイクロサービスだと、それぞれのサービスで独自実装される場合が多い
ここを、汎用サービスとして共通化できると、重複を減らせる

汎用化という定義の難しさ
- 共通部分だけだと、各サービスだけで利用するデータが足りない。
- 和集合だと、ただ大きくなっただけになる。
- ここのちょうどいいバランスをとる

汎用システム作成時の5つのポイント
- なんでもできないけど、定めたユースケースはちゃんと満たせるようにする
- 汎用的なデータ構造設計が大切、出来ることを絞りつつ、どうやって複雑な要件を満たすか？
- 利用者への正しい理解を促進する。使えないシステムだとレッテルを貼られないために、どういうことをスコープしたサービスなのか？を理解する。また、社内でのコンサルの理解も大切
- オーナーシップが大切。汎用システムを一つのプロダクトとして捉えて、開発運用して行く。
- 効果の定期的な見直し。作りっぱなしではなく、定量・定性的な所で、より見直して修正する。

アーキテクトの役割は、全員よりも賢くなることではない。
他の人たちをより賢くするためのもの。
他の人達が意思決定に対して、主体性を持たせるのが一番大事

砂時計というアンチパターンが存在する
理想と期待値は多いのに、肝心のロジック部分の話があまり出来ていない場合がある。
バズワードを使うと注目は集められるが、中身の内容こそ肝心

大企業のアーキテクチャを真似するだけではダメ
Googleのアーキテクチャが、自分たちの会社に最適ではない。
自分達の要件にあったものを考える必要がある。

アーキテクチャは、 「何を使うか？」 ではなく、何がしたいか？そのために何が必要なのか？を考える。
単語ベースだけで話をしない。

アーキテクチャには、常にトレードオフが存在する
なので、決まりきった結論を出すのではない、A が絶対にうまくいく、という前提を持たない。
また、成功に結びつけるには、更なる努力が必要

時には、一歩下がって見るのも大切
- どういう前提を自分で考えるか?を認識する
- アーキテクチャする時は、 AI を使てt壁売りをする

アーキテクチャを検討する時は、 「実際のデータ・数字」 を把握して考える
- 3 倍のコストでも、 Vs か、000 vs 000で 変わる
- スケールはどれくらい欲しいのか？どれくらいのトラフィックがあるのか？にもよる。
判断するためには、リアルなデータが必要になる。

常に他の選択肢があるかも、見落としていることはあるかも？と考える。
- 実際はもっと選択肢があるのではないか？をアーキテクチャは考える
- 問題を一視点しか見てないと、解決できない。
- 何か勘違いしている可能性がある、という前提も持つ
- そもそも今適切な情報になってるのか？
- 今のトレードオフは何なのか？
- 途中にある意思決定が重要になる
- いろんな可能性が無限に出てくる、ここの途中の過程があるから面白い

モノリス、マイクロサービスではなく、4つの領域で考える
- Replicas
- Modular Monolith
の二つが存在する
問題は何か？を理解した上で、何が必要なのか？を考える必要がある

変化するのにも、いろいろな背景がある。
- どうしてこのバージョンを延長させるのか？
- 変更するコストもかかる。
- だからベンダーロックインが起こる
- でも、これは必ずしも悪いことではない
- 一度いろいろな次元を理解すると、よりよい意思決定ができるようになる。

常に 「一番インパクトが大きい所」 を考える
- レイテンシーであれば、一番のボトルネックを解消する必要がある。
- また、重要な要件を明確にして、一貫性を持つのも大切
- いろいろと最適化しようとして、複雑になりすぎるとマイナスに

いい設計には、 「トレードオフ」 が付きまとう
- ちょっとしたトレードオフ・衝突が存在する
- 早く価値は出したいけど、一直線で行かない時もある。
- その時には、常に重要な原則に則って判断する

早々と意思決定をしきらない
- プロジェクト初期が、一番情報が少ない
- プロジェクトが始まるとわかってくることが多い
- 何もわかってない状態で全てを決めないようにする

アーキテクチャは、常に選択肢を持つ
- 仮説を持った上で取り組んで、それが当たればプラスで、外れれば負け
- 将来は見れないからこそ、選択肢を持って柔軟に対応できるようにする

選択肢は、時間が経つと正しいかどうかが判断しやすい
- オプションは、タイムトラベルとして扱える
- 時間が経てば、答えがわかっていく
- もっとキャパシティが必要ならさらに追加する
- 意思決定を先延ばしにすると、後々判断に必要な情報を取得できる
- ただ、全てに対して選択肢を持つのは費用的にはマイナス
- 自分で積極的に選ぶ必要が出てくる

最適なアーキテクチャは、スナップショットでは得られない
- 成長が今後見込まれるなら、よりスケールできるようにする
- また、利用者の数がどのように変わっていくのか？によっても、必要なインフラの要件は変わる

アーキテクチャを判断するときのモデルを作成する時は、「どこを見てるのか？何が必要なのか？」 を意識する
- 意思決定は一つのモデルで完結しない
- いいモデルは答えを出してくれる

全てのセッションで学びが多すぎて、毎回パンクしてました...
とても貴重なお話をありがとうございました！
明日もよろしくお願いいたします！

#アーキテクチャcon_findy November 11, 2025

アーキテクチャ Conferene で学んだ内容をシェアします！

マイクロサービスにするべきかどうかは、 「それによって得られる成果」 が明確かどうかで決まる
- 「マイクロサービスにしたい」 自体が目的にするのではない
- Deploy の速度が遅くなったなど、マイクロサービスにする必要性を認識した時に、初めて検討する。
- 手段を先行させない

モジュラーモノリスから、マイクロサービスに移行する時の手順とコツ
1. 徐々に移行していく
2. 新サービスの開発とデプロイを分けて、作った後にすぐリプレースしない
3. 旧サービスも残しておいて、新サービスがバグってた時もすぐにロールバックできるようにする
4. 新しく作ったサービスを測定しつつ、正しく動作しているか？コストはどれだけか？を図る

ユーザーもビジネスサイドの人も、 「マイクロサービスかどうか？」 は気にしていない
与えられる価値によって、マイクロサービスにするかどうかは決めるべき
与えられる価値が、マイクロサービスによって増えるなら、マイクロサービスにする

アプリケーションの規模は、次第に大きくなっていく
それに伴い、デブロイの時間やデグレチェックなどで、変更を反映するまでにかかる時間が増えていく。
これを回避するためにも、マイクロサービスは有効
重要なのは、小さくてかつ頻度の高い変更。

セキュリティ要件は、クリティカルになりうる。
そのため、サービスが小さいうちから意識して予防したり、安全に扱う仕組みを作ることが大切。

開発チームを、サービスチーム(そのチーム内で用件定義 ~ テストまで行えるチーム)で完結させると、迅速な意思決定と主体性を育める
- コミュニケーションコストが低くなる
- 信頼関係を建築しやすい。なぜそれをやろうとしているのか？とか背景情報・考えていることを理解できるから、コミュニケーションの摩擦が少なくなる。
- サービスチームがプロダクトに対するオーナーシップを持つので、主体性も育める

ドメイン型のチーム と プロジェクト型のチームのメリットデメリット
ドメイン型のチーム体制
メリット
- 持続可能性高いエンジニアリングができる
- 深い知見が溜まりやすいので、オーナーシップを与えやすくなる
デメリット
- ドメイン分割する協会を定義しにくい
- 非注力なドメインがある場合は、開発チームを継続的に配置するのが難しい。注力対象が変わるスタートアップだと難しい。

プロジェクト型のチーム体制
メリット
- チーム組成が簡単
- 開発作業に集中できる
デメリット
- 持続可能性が低い
- 深い知見がたまらない。一年前に作った機能を忘れて、開発効率が遅くなる。

もしプロジェクト型にしたとしても、持続可能性について検討しておく
事前に誰が、何をやるか？という所を決めておくと、責任が明確になるのでおすすめ。

サービスメンバーが、全員 「フルスタック & フルサイクル」 だとコミュニケーションコストが減る
また、職能におけるボトルネックの排除ができる。職能で分けると、何かの職種のタスクでボトルネックになるので、そこを避けることができる。

チームにコードな専門性が必要かどうか？
- 現在は、クラウドなど 「テクノロジーのコモディティ化による恩恵」 がある
- そのため、ある程度はジェネラリストでも対応できる。
- 専門性の高い領域は、横断チームとして切り出す
- セキュリティチームなどは、別で切り出せばいい
- 実際は、人にはそれぞれ得意領域があるから面白い
- そのため、専用の人を雇わなくても、誰かが得意、という状況が起こる

必要に応じて専門職を採用するメリットもある
- 専門職の人によって、周りの人たちのレベルを上げることも出来る

サービスチームとして、必要な意思決定ができる
- ここも、職種ごとにチームを分けていたら、上手くいかない

現場チームに採用の権限を任せるのも有効
- 現場の人が一番どんな人が欲しいかわかってる。
- 募集要項、スカウトメールまで現場の人が考えたりする。
- また、最終的には登壇などによる認知度向上など、活動勝負になるので、オーナーシップを与えることが重要
- 随時 HR の人ともコミュニケーションをとる

規模が小さいと、オーナーシップを発揮しやすい反面、知見の共有や技術的なエコシステムの構築は難しくなる。

AI はいづれ人間を凌駕する、それは段階的に起こりうる
最終的には責任を負って、信頼を勝ち取ることが人間に役割になる
- AI は、責任を果たすことが難しい。
- 人間は AI を信頼し切れるのか？という疑問が残るので、人間がここを保証する必要が出てくる
具体的には、最後の検査等を人が行い、責任と信頼を持つのが大切。

人に求められる責任の量が今後多くなるのではないか？
- 求められる責任の量が増える
- 求められる責任の水準も上がる
- 非エンジニアのリテラシーが向上して、定量的な信頼性と適切な説明責任が出てくる

今後エンジニアは、AI の成果物に対してどう検査していくべきか？
今後は、専門的な知見をもとにした説明が必要になる。
- 判断の基準(客観 <-> 主観)
- タイミング(予防 <-> 回復)
などの軸で、検査を進める必要がある。

アーキテクチャは、認知負荷を軽減する鍵になる。
上手くアーキテクチャを構築すると、人がレビューするときの負荷を減らせる

AIでの開発を進める上で、重要なアーキテクチャ 6選
- 境界付けられたコンテキスト
- イベント駆動アーキテクチャ
- CQRS(Command Query Responsibility Segregation)
- AVDM(Always-Valid Domain Model)
- Type First
- 型エラーで事前に駆動できる
- Event Sourcing
- なぜそうなったのか？の検査の精度もあげられる

CQRS を取り入れることのメリット
ファイルごとに処理を分けることで、 「人がどこに注力するべきなのか？」 をチェックできる。
レビューした方がいい所は重点的に見つつ、そうじゃない所はテストと型エラーを軽く見るだけで済む。
このグラデーションをつけることが重要

サービス設計時、 「その機能が必要な理由」 をなぜなぜと繰り返して問いかけて理解する
それにより、お客さんのことを理解できるようになり、ユーザーの真のニーズが見えてきて、製品にもそれが反映されるようになる。
同時に、ユーザーの課題を解決することで自信がつくようにもなる。
また、必要に応じてセールスとも会話して、今顧客が何を求めてるか？も随時把握する

Figma の アーキテクチャ や 技術前提の選定基準
パフォーマンスを最重要に考えている。
フレームレートは、1秒あたり60コマから30コマにならないか？などを重点的にテストする。
ここの最重要事項、ケアするべきとこは、集中して確認する。

アプリケーション のパフォーマンスは、エンジニアリングの問題だけではない
デザインが問題になる可能性もある。新しい機能を出すことで、既存のサービスイメージと競合する時がある。
時には、既存サービスを切り捨てる必要もあるし、新しい機能を区別させないように同化させたりして、初めの利用障壁を下げる工夫なども必要になる。

AI によって役割が変わったとしても、常に 「ユーザーが何を求めてるからを徹底して考える」 ことが重要
エンジニアであれば、実現可能性の観点から見る
また、肩書きでは無くて、何をやるか？が重要になる。
どうしてこれをやるか、なぜそれの優先順位が高いのか、
ここは、製品の整合性などで、Why How を出しつつ、人間的な所から、ベストな経験はなにか？を考えたり、ビジネスの経験から、ベストなものを得る。

アイデアは、面白い、ワクワクするようなストーリーから逆算して作る。
そこからのストーリーを作らないと、意義が少なくなる可能性が出てくる。
ナラティブから始めて、実際の付加価値をつけていく

新しい機能を作り出すなら、まずは何を考えるべきか？
最初に頭に浮かぶ時は、最初はスタンダードな、なぜそれをやるのか？そして、どうして面白いのか？なぜそれがワクワクするのか？
ユーザーが見た時に、 「それは価値がある」 って分かるならいいアイデア。
逆にすぐ理解できなかったら、何か間違えている可能性がある。

プラットフォームエンジニアリングとは？
会社組織としての組織と、価値創出を目的としたチーム
仮想組織として、PMやデザイナーなどの職種のメンバーを全員入れて、それぞれの職能を持った人が集めたもの。
対象のサービスでバックエンドが既に作成済みなら、フロントエンドだけのチームも作る。

Platform Engineering が作成されるきっかけの一例
開発チームが全てを担当するのはするのは限界がある。だからこそ、インフラ周りの整備の専門家で切り出したりする。

会社の状況に応じて、専門領域を作るべきか変わる。
- 小さい会社なら、少人数で全部やる
- 大きい会社なら、分業していく
- 中間層として、PFEでオフロードする、が入る。規模が大きくなりと分業が進む。

AI に色々なタスクを任せると上手く動かない
必要に応じて、AWS Resource Explorer を使うなど、必要なリソースをわかりやすい形でアクセスさせるのが大切
これをSQlite でインデックス化すると、より高速にアクセス可能にもなる。

必要に応じて、人間が補足情報を加える
ソースコードのリバースエンジニアリングだけだと、 「なぜそれをしたのか？」 の文脈が失われがち
なので、わからないこと・決まってないことを人が決めた上で、再度 AIに考えさせるのが大切
AI に推論させず、人間が必要な背景情報は人が与える
この時に、 「まだ決まってなかった、必要な仕様を認識」 できるので、ドキュメントの質向上に加えて、足りてない項目は補足できる。

Devin を使うメリット
雑に聞いても、複数のレポジトリを横断して調べてくれる
つまり、一メンバーとして動いてくれるし、プロンプトで正しい情報を与えなくても、いい感じで回答してくれるのは大きい。

AI の本質的な 3つの力
- 幅広い知識の補完
- 文章・コード・情報の整理
- 人間の得意なことを支えて、面倒なことをやってくれる

90% の簡単なコードを書くことには価値がなくなった、でもどんなコードを書くべきか、のアーキテクトの重要性は1000 倍になった。という名言があった。

AI は知識の代替ではなく、能力の増幅機
- 使い手の能力をがないとダメ
- AI を能力向上のために使う必要がある
- 結局、自分自身のスキルアップが大切

AI コーディングの価値はスピードだけど、一方で品質が落ちる。
結局人がレビューする必要がある。
またアーキテクチャはコンパスで、完璧な地図は書けない。あくまで方針を示しているだけ

コードの複雑性は、2種類ある
- Essential Complexity
- ドメインに固有、除去不可能
- Accidental Complexity
- 技術的制約、フレームワークで削減可能
偶有的複雑性をどれだけ削減できるか？

データベースによる制約に縛られないため、インメモリの中で解決できるようにする。
モデル全体や設計を、データベースとは異なる方法で構造化する。
初めは大変だけそ、後々楽になっていく。

イベントソーシングの本質
- 全ての変更を記録する
これは、ステートソーシング(データの現在の状態だけを保存する)とは異なる。
これがあると、何が起きたか？を流れとしてわかるようになる。

Always Valid Domain Modelとは？
- 常に正しい状態を、インメモリで DB とは関係ない状態で作る
例) C# で、Pureなオブジェクトを作る。

後悔しないアーキテクチャを作るために、最初からスケールアウト出来る設計で作っておく
- 後々で、DBがボトルネックになる。
- 最初からやっておけばよかった、を防げる。

結合のバランス
- 実装や進化、メンテナンスが容易なモジュラーシステムを設計すること
- 結合の3つの次元全てを考慮すること

AI時代での 開発者の役割
- アーキテクチャの方針を決定
- ドメインの本質を理解
- 制約とガードレールを定義

まずは小規模でスタートして、徐々にスケールさせる
- ある程度コストを前払いする必要がある
- 学習コスト、初期設計、フレームワーク選定も重要
- これにより、後々からの後悔を避けることができる。
判断基準としては、将来のリアーキテクチャコストがどれだけかかるか？後でリアキクトするなら、作る前から意識する。

設計は選択肢を知っておくことが重要
- 詳しく知らなくても、コンセプトを理解していると、AI のアシストで採用していくことができる
- また、完璧ではなく、 「選択に納得できる」 ことをすることが重要

情報は、AI が収集・生成・提案して、人が判断するようになる
AI が読める情報を増やしていく、 AI リーダブルな情報設計が必要

情報負債が起こる原因は？
- 分散
- 形骸化
- 属人化

なぜ情報が分散するのか？
- ドキュメントの責任範囲が曖昧
- 検索性・再利用性よりスピードを優先
- 情報構造の設計思想が存在しない

AI ナレッジベースによる情報の一元化
- 事業運営に必要な情報を一元管理
- 人が必要な根拠・文脈に辿り着けるようにする
- 人とAI が同じ情報で判断できるようにする

形骸化する原因は？
- ドキュメントが利用できず、古いまま放置されてる
- チームの運用手順書が古いので、手戻りが発生
- 結果的に、AIが間違った分析をしてしまう

なぜドキュメントが形骸化するのか？
- 頻繁な仕様変更に追従が大変
- 古くても誰も困らず、責任が曖昧
- 成果に直結しにくい
保守が後回しになりやすい構造になる。

ドキュメント運用の自動化は？
Docs-as-Code でドキュメント運用の自動化をするといい。CI で常に更新させる。
また、Cron で定期的に情報収集させる。
必要な加工をした上で、ナレッジの情報収集を行えるようにする。

なぜ情報が属人化するのか？
暗黙知による属人化が起こる。
- 知見が個人に依存してる
- 「あの人しか知らない」 を放置しても、問題化されない
- 誰がどの知識を持っているかが分からない

属人化の対策方法
- AI 前提の業務プロセス設計を構築する。
- ドキュメントが自動的に生まれる仕組みを作る。
- 会議 -> 自動要約 -> ナレッジに自動追加

AI ナレッジベースの情報設計は？
- GitHubレポジトリを採用
- レビューや自動化を容易に
- Markdownを利用する
- AIの挙動を制御するガードレールを整備する、など

ドメイン知識をナレッジベースで貯めておくと、意図に沿ったクエリを出せたり、結果を出力できる。
その結果、設計の壁打ちでも使えるようになるかもしれない。

定期的にAIに動かして、ドキュメントを常に更新する
- 情報 × 状態 = 次のアクションを決める
- 推論させる時と、機械的に動かす、をきちんと分ける。
- 業務推進の自動化がどこまでできるのか？が重要になる

マイクロサービスだと、それぞれのサービスで独自実装される場合が多い
ここを、汎用サービスとして共通化できると、重複を減らせる

汎用化という定義の難しさ
- 共通部分だけだと、各サービスだけで利用するデータが足りない。
- 和集合だと、ただ大きくなっただけになる。
- ここのちょうどいいバランスをとる

汎用システム作成時の5つのポイント
- なんでもできないけど、定めたユースケースはちゃんと満たせるようにする
- 汎用的なデータ構造設計が大切、出来ることを絞りつつ、どうやって複雑な要件を満たすか？
- 利用者への正しい理解を促進する。使えないシステムだとレッテルを貼られないために、どういうことをスコープしたサービスなのか？を理解する。また、社内でのコンサルの理解も大切
- オーナーシップが大切。汎用システムを一つのプロダクトとして捉えて、開発運用して行く。
- 効果の定期的な見直し。作りっぱなしではなく、定量・定性的な所で、より見直して修正する。

アーキテクトの役割は、全員よりも賢くなることではない。
他の人たちをより賢くするためのもの。
他の人達が意思決定に対して、主体性を持たせるのが一番大事

砂時計というアンチパターンが存在する
理想と期待値は多いのに、肝心のロジック部分の話があまり出来ていない場合がある。
バズワードを使うと注目は集められるが、中身の内容こそ肝心

大企業のアーキテクチャを真似するだけではダメ
Googleのアーキテクチャが、自分たちの会社に最適ではない。
自分達の要件にあったものを考える必要がある。

アーキテクチャは、 「何を使うか？」 ではなく、何がしたいか？そのために何が必要なのか？を考える。
単語ベースだけで話をしない。

アーキテクチャには、常にトレードオフが存在する
なので、決まりきった結論を出すのではない、A が絶対にうまくいく、という前提を持たない。
また、成功に結びつけるには、更なる努力が必要

時には、一歩下がって見るのも大切
- どういう前提を自分で考えるか?を認識する
- アーキテクチャする時は、 AI を使てt壁売りをする

アーキテクチャを検討する時は、 「実際のデータ・数字」 を把握して考える
- 3 倍のコストでも、 Vs か、000 vs 000で 変わる
- スケールはどれくらい欲しいのか？どれくらいのトラフィックがあるのか？にもよる。
判断するためには、リアルなデータが必要になる。

常に他の選択肢があるかも、見落としていることはあるかも？と考える。
- 実際はもっと選択肢があるのではないか？をアーキテクチャは考える
- 問題を一視点しか見てないと、解決できない。
- 何か勘違いしている可能性がある、という前提も持つ
- そもそも今適切な情報になってるのか？
- 今のトレードオフは何なのか？
- 途中にある意思決定が重要になる
- いろんな可能性が無限に出てくる、ここの途中の過程があるから面白い

モノリス、マイクロサービスではなく、4つの領域で考える
- Replicas
- Modular Monolith
の二つが存在する
問題は何か？を理解した上で、何が必要なのか？を考える必要がある

変化するのにも、いろいろな背景がある。
- どうしてこのバージョンを延長させるのか？
- 変更するコストもかかる。
- だからベンダーロックインが起こる
- でも、これは必ずしも悪いことではない
- 一度いろいろな次元を理解すると、よりよい意思決定ができるようになる。

常に 「一番インパクトが大きい所」 を考える
- レイテンシーであれば、一番のボトルネックを解消する必要がある。
- また、重要な要件を明確にして、一貫性を持つのも大切
- いろいろと最適化しようとして、複雑になりすぎるとマイナスに

いい設計には、 「トレードオフ」 が付きまとう
- ちょっとしたトレードオフ・衝突が存在する
- 早く価値は出したいけど、一直線で行かない時もある。
- その時には、常に重要な原則に則って判断する

早々と意思決定をしきらない
- プロジェクト初期が、一番情報が少ない
- プロジェクトが始まるとわかってくることが多い
- 何もわかってない状態で全てを決めないようにする

アーキテクチャは、常に選択肢を持つ
- 仮説を持った上で取り組んで、それが当たればプラスで、外れれば負け
- 将来は見れないからこそ、選択肢を持って柔軟に対応できるようにする

選択肢は、時間が経つと正しいかどうかが判断しやすい
- オプションは、タイムトラベルとして扱える
- 時間が経てば、答えがわかっていく
- もっとキャパシティが必要ならさらに追加する
- 意思決定を先延ばしにすると、後々判断に必要な情報を取得できる
- ただ、全てに対して選択肢を持つのは費用的にはマイナス
- 自分で積極的に選ぶ必要が出てくる

最適なアーキテクチャは、スナップショットでは得られない
- 成長が今後見込まれるなら、よりスケールできるようにする
- また、利用者の数がどのように変わっていくのか？によっても、必要なインフラの要件は変わる

アーキテクチャを判断するときのモデルを作成する時は、「どこを見てるのか？何が必要なのか？」 を意識する
- 意思決定は一つのモデルで完結しない
- いいモデルは答えを出してくれる

全てのセッションで学びが多すぎて、毎回パンクしてました...
とても貴重なお話をありがとうございました！
明日もよろしくお願いいたします！

#アーキテクチャcon_findy November 11, 2025

アーキテクチャ Conferene で学んだ内容をシェアします！

マイクロサービスにするべきかどうかは、 「それによって得られる成果」 が明確かどうかで決まる
- 「マイクロサービスにしたい」 自体が目的にするのではない
- Deploy の速度が遅くなったなど、マイクロサービスにする必要性を認識する
- 手段を先行させない

モジュラーモノリスから、マイクロサービスに移行する時の手順とコツ
1. 徐々に移行していく
2. 新サービスの開発とデプロイを分けて、作った後にすぐリプレースしない
3. 旧サービスも残しておいて、新サービスがバグってた時もすぐにロールバックできるようにする
4. 新しく作ったサービスを測定しつつ、正しく動作しているか？コストはどれだけか？を図る

ユーザーもビジネスサイドの人も、 「マイクロサービスかどうか？」 は気にしていない
与えられる価値によって、マイクロサービスにするかどうかは決めるべき
与えられる価値が、マイクロサービスによって増えるなら、マイクロサービスにする

アプリケーションの規模は、次第に大きくなっていく
それに伴い、デブロイの時間やデグレチェックなどで、変更を反映するまでにかかる時間が増えていく。
これを回避するためにも、マイクロサービスは有効
重要なのは、小さくてかつ頻度の高い変更。

セキュリティ要件は、クリティカルになりうる。
そのため、サービスが小さいうちから意識して予防したり、安全に扱う仕組みを作ることが大切。

開発チームを、サービスチーム(そのチーム内で用件定義 ~ テストまで行えるチーム)で完結させると、迅速な意思決定と主体性を育める
- コミュニケーションコストが低くなる
- 信頼関係を建築しやすい。なぜそれをやろうとしているのか？とか背景情報・考えていることを理解できるから、コミュニケーションの摩擦が少なくなる。
- サービスチームがプロダクトに対するオーナーシップを持つので、主体性も育める

ドメイン型のチーム と プロジェクト型のチームのメリットデメリット
ドメイン型のチーム体制
メリット
- 持続可能性高いエンジニアリングができる
- 深い知見が溜まりやすいので、オーナーシップを与えやすくなる
デメリット
- ドメイン分割する協会を定義しにくい
- 非注力なドメインがある場合は、開発チームを継続的に配置するのが難しい。注力対象が変わるスタートアップだと難しい。

プロジェクト型のチーム体制
メリット
- チーム組成が簡単
- 開発作業に集中できる
デメリット
- 持続可能性が低い
- 深い知見がたまらない。一年前に作った機能を忘れて、開発効率が遅くなる。

もしプロジェクト型にしたとしても、持続可能性について検討しておく
事前に誰が、何をやるか？という所を決めておくと、責任が明確になるのでおすすめ。

サービスメンバーが、全員 「フルスタック & フルサイクル」 だとコミュニケーションコストが減る
また、職能におけるボトルネックの排除ができる。職能で分けると、何かの職種のタスクでボトルネックになるので、そこを避けることができる。

チームにコードな専門性が必要かどうか？
- 現在は、クラウドなど 「テクノロジーのコモディティ化による恩恵」 がある
- そのため、ある程度はジェネラリストでも対応できる。
- 専門性の高い領域は、横断チームとして切り出す
- セキュリティチームなどは、別で切り出せばいい
- 実際は、人にはそれぞれ得意領域があるから面白い
- そのため、専用の人を雇わなくても、誰かが得意、という状況が起こる

必要に応じて専門職を採用するメリットもある
- 専門職の人によって、周りの人たちのレベルを上げることも出来る

サービスチームとして、必要な意思決定ができる
- ここも、職種ごとにチームを分けていたら、上手くいかない

現場チームに採用の権限を任せるのも有効
- 現場の人が一番どんな人が欲しいかわかってる。
- 募集要項、スカウトメールまで現場の人が考えたりする。
- また、最終的には登壇などによる認知度向上など、活動勝負になるので、オーナーシップを与えることが重要
- 随時 HR の人ともコミュニケーションをとる

規模が小さいと、オーナーシップを発揮しやすい反面、知見の共有や技術的なエコシステムの構築は難しくなる。

AI はいづれ人間を凌駕する、それは段階的に起こりうる
最終的には責任を負って、信頼を勝ち取ることが人間に役割になる
- AI は、責任を果たすことが難しい。
- 人間は AI を信頼し切れるのか？という疑問が残るので、人間がここを保証する必要が出てくる
具体的には、最後の検査等を人が行い、責任と信頼を持つのが大切。

人に求められる責任の量が今後多くなるのではないか？
- 求められる責任の量が増える
- 求められる責任の水準も上がる
- 非エンジニアのリテラシーが向上して、定量的な信頼性と適切な説明責任が出てくる

今後エンジニアは、AI の成果物に対してどう検査していくべきか？
今後は、専門的な知見をもとにした説明が必要になる。
- 判断の基準(客観 <-> 主観)
- タイミング(予防 <-> 回復)
などの軸で、検査を進める必要がある。

アーキテクチャは、認知負荷を軽減する鍵になる。
上手くアーキテクチャを構築すると、人がレビューするときの負荷を減らせる

AIでの開発を進める上で、重要なアーキテクチャ 6選
- 境界付けられたコンテキスト
- イベント駆動アーキテクチャ
- CQRS(Command Query Responsibility Segregation)
- AVDM(Always-Valid Domain Model)
- Type First
- 型エラーで事前に駆動できる
- Event Sourcing
- なぜそうなったのか？の検査の精度もあげられる

CQRS を取り入れることのメリット
ファイルごとに処理を分けることで、 「人がどこに注力するべきなのか？」 をチェックできる。
レビューした方がいい所は重点的に見つつ、そうじゃない所はテストと型エラーを軽く見るだけで済む。
このグラデーションをつけることが重要

サービス設計時、 「その機能が必要な理由」 をなぜなぜと繰り返して問いかけて理解する
それにより、お客さんのことを理解できるようになり、ユーザーの真のニーズが見えてきて、製品にもそれが反映されるようになる。
同時に、ユーザーの課題を解決することで自信がつくようにもなる。
また、必要に応じてセールスとも会話して、今顧客が何を求めてるか？も随時把握する

Figma の アーキテクチャ や 技術前提の選定基準
パフォーマンスを最重要に考えている。
フレームレートは、1秒あたり60コマから30コマにならないか？などを重点的にテストする。
ここの最重要事項、ケアするべきとこは、集中して確認する。

アプリケーション のパフォーマンスは、エンジニアリングの問題だけではない
デザインが問題になる可能性もある。新しい機能を出すことで、既存のサービスイメージと競合する時がある。
時には、既存サービスを切り捨てる必要もあるし、新しい機能を区別させないように同化させたりして、初めの利用障壁を下げる工夫なども必要になる。

AI によって役割が変わったとしても、常に 「ユーザーが何を求めてるからを徹底して考える」 ことが重要
エンジニアであれば、実現可能性の観点から見る
また、肩書きでは無くて、何をやるか？が重要になる。
どうしてこれをやるか、なぜそれの優先順位が高いのか、
ここは、製品の整合性などで、Why How を出しつつ、人間的な所から、ベストな経験はなにか？を考えたり、ビジネスの経験から、ベストなものを得る。

アイデアは、面白い、ワクワクするようなストーリーから逆算して作る。
そこからのストーリーを作らないと、意義が少なくなる可能性が出てくる。
ナラティブから始めて、実際の付加価値をつけていく

新しい機能を作り出すなら、まずは何を考えるべきか？
最初に頭に浮かぶ時は、最初はスタンダードな、なぜそれをやるのか？そして、どうして面白いのか？なぜそれがワクワクするのか？
ユーザーが見た時に、 「それは価値がある」 って分かるならいいアイデア。
逆にすぐ理解できなかったら、何か間違えている可能性がある。

プラットフォームエンジニアリングとは？
会社組織としての組織と、価値創出を目的としたチーム
仮想組織として、PMやデザイナーなどの職種のメンバーを全員入れて、それぞれの職能を持った人が集めたもの。
対象のサービスでバックエンドが既に作成済みなら、フロントエンドだけのチームも作る。

Platform Engineering が作成されるきっかけの一例
開発チームが全てを担当するのはするのは限界がある。だからこそ、インフラ周りの整備の専門家で切り出したりする。

会社の状況に応じて、専門領域を作るべきか変わる。
- 小さい会社なら、少人数で全部やる
- 大きい会社なら、分業していく
- 中間層として、PFEでオフロードする、が入る。規模が大きくなりと分業が進む。

AI に色々なタスクを任せると上手く動かない
必要に応じて、AWS Resource Explorer を使うなど、必要なリソースをわかりやすい形でアクセスさせるのが大切
これをSQlite でインデックス化すると、より高速にアクセス可能にもなる。

必要に応じて、人間が補足情報を加える
ソースコードのリバースエンジニアリングだけだと、 「なぜそれをしたのか？」 の文脈が失われがち
なので、わからないこと・決まってないことを人が決めた上で、再度 AIに考えさせるのが大切
AI に推論させず、人間が必要な背景情報は人が与える
この時に、 「まだ決まってなかった、必要な仕様を認識」 できるので、ドキュメントの質向上に加えて、足りてない項目は補足できる。

Devin を使うメリット
雑に聞いても、複数のレポジトリを横断して調べてくれる
つまり、一メンバーとして動いてくれるし、プロンプトで正しい情報を与えなくても、いい感じで回答してくれるのは大きい。

AI の本質的な 3つの力
- 幅広い知識の補完
- 文章・コード・情報の整理
- 人間の得意なことを支えて、面倒なことをやってくれる

90% の簡単なコードを書くことには価値がなくなった、でもどんなコードを書くべきか、のアーキテクトの重要性は1000 倍になった。という名言があった。

AI は知識の代替ではなく、能力の増幅機
- 使い手の能力をがないとダメ
- AI を能力向上のために使う必要がある
- 結局、自分自身のスキルアップが大切

AI コーディングの価値はスピードだけど、一方で品質が落ちる。
結局人がレビューする必要がある。
またアーキテクチャはコンパスで、完璧な地図は書けない。あくまで方針を示しているだけ

コードの複雑性は、2種類ある
- Essential Complexity
- ドメインに固有、除去不可能
- Accidental Complexity
- 技術的制約、フレームワークで削減可能
偶有的複雑性をどれだけ削減できるか？

データベースによる制約に縛られないため、インメモリの中で解決できるようにする。
モデル全体や設計を、データベースとは異なる方法で構造化する。
初めは大変だけそ、後々楽になっていく。

イベントソーシングの本質
- 全ての変更を記録する
これは、ステートソーシング(データの現在の状態だけを保存する)とは異なる。
これがあると、何が起きたか？を流れとしてわかるようになる。

Always Valid Domain Modelとは？
- 常に正しい状態を、インメモリで DB とは関係ない状態で作る
例) C# で、Pureなオブジェクトを作る。

後悔しないアーキテクチャを作るために、最初からスケールアウト出来る設計で作っておく
- 後々で、DBがボトルネックになる。
- 最初からやっておけばよかった、を防げる。

結合のバランス
- 実装や進化、メンテナンスが容易なモジュラーシステムを設計すること
- 結合の3つの次元全てを考慮すること

AI時代での 開発者の役割
- アーキテクチャの方針を決定
- ドメインの本質を理解
- 制約とガードレールを定義

まずは小規模でスタートして、徐々にスケールさせる
- ある程度コストを前払いする必要がある
- 学習コスト、初期設計、フレームワーク選定も重要
- これにより、後々からの後悔を避けることができる。
判断基準としては、将来のリアーキテクチャコストがどれだけかかるか？後でリアキクトするなら、作る前から意識する。

設計は選択肢を知っておくことが重要
- 詳しく知らなくても、コンセプトを理解していると、AI のアシストで採用していくことができる
- また、完璧ではなく、 「選択に納得できる」 ことをすることが重要

情報は、AI が収集・生成・提案して、人が判断するようになる
AI が読める情報を増やしていく、 AI リーダブルな情報設計が必要

情報負債が起こる原因は？
- 分散
- 形骸化
- 属人化

なぜ情報が分散するのか？
- ドキュメントの責任範囲が曖昧
- 検索性・再利用性よりスピードを優先
- 情報構造の設計思想が存在しない

AI ナレッジベースによる情報の一元化
- 事業運営に必要な情報を一元管理
- 人が必要な根拠・文脈に辿り着けるようにする
- 人とAI が同じ情報で判断できるようにする

形骸化する原因は？
- ドキュメントが利用できず、古いまま放置されてる
- チームの運用手順書が古いので、手戻りが発生
- 結果的に、AIが間違った分析をしてしまう

なぜドキュメントが形骸化するのか？
- 頻繁な仕様変更に追従が大変
- 古くても誰も困らず、責任が曖昧
- 成果に直結しにくい
保守が後回しになりやすい構造になる。

ドキュメント運用の自動化は？
Docs-as-Code でドキュメント運用の自動化をするといい。CI で常に更新させる。
また、Cron で定期的に情報収集させる。
必要な加工をした上で、ナレッジの情報収集を行えるようにする。

なぜ情報が属人化するのか？
暗黙知による属人化が起こる。
- 知見が個人に依存してる
- 「あの人しか知らない」 を放置しても、問題化されない
- 誰がどの知識を持っているかが分からない

属人化の対策方法
- AI 前提の業務プロセス設計を構築する。
- ドキュメントが自動的に生まれる仕組みを作る。
- 会議 -> 自動要約 -> ナレッジに自動追加

AI ナレッジベースの情報設計は？
- GitHubレポジトリを採用
- レビューや自動化を容易に
- Markdownを利用する
- AIの挙動を制御するガードレールを整備する、など

ドメイン知識をナレッジベースで貯めておくと、意図に沿ったクエリを出せたり、結果を出力できる。
その結果、設計の壁打ちでも使えるようになるかもしれない。

定期的にAIに動かして、ドキュメントを常に更新する
- 情報 × 状態 = 次のアクションを決める
- 推論させる時と、機械的に動かす、をきちんと分ける。
- 業務推進の自動化がどこまでできるのか？が重要になる

マイクロサービスだと、それぞれのサービスで独自実装される場合が多い
ここを、汎用サービスとして共通化できると、重複を減らせる

汎用化という定義の難しさ
- 共通部分だけだと、各サービスだけで利用するデータが足りない。
- 和集合だと、ただ大きくなっただけになる。
- ここのちょうどいいバランスをとる

汎用システム作成時の5つのポイント
- なんでもできないけど、定めたユースケースはちゃんと満たせるようにする
- 汎用的なデータ構造設計が大切、出来ることを絞りつつ、どうやって複雑な要件を満たすか？
- 利用者への正しい理解を促進する。使えないシステムだとレッテルを貼られないために、どういうことをスコープしたサービスなのか？を理解する。また、社内でのコンサルの理解も大切
- オーナーシップが大切。汎用システムを一つのプロダクトとして捉えて、開発運用して行く。
- 効果の定期的な見直し。作りっぱなしではなく、定量・定性的な所で、より見直して修正する。

アーキテクトの役割は、全員よりも賢くなることではない。
他の人たちをより賢くするためのもの。
他の人達が意思決定に対して、主体性を持たせるのが一番大事

砂時計というアンチパターンが存在する
理想と期待値は多いのに、肝心のロジック部分の話があまり出来ていない場合がある。
バズワードを使うと注目は集められるが、中身の内容こそ肝心

大企業のアーキテクチャを真似するだけではダメ
Googleのアーキテクチャが、自分たちの会社に最適ではない。
自分達の要件にあったものを考える必要がある。

アーキテクチャは、 「何を使うか？」 ではなく、何がしたいか？そのために何が必要なのか？を考える。
単語ベースだけで話をしない。

アーキテクチャには、常にトレードオフが存在する
なので、決まりきった結論を出すのではない、A が絶対にうまくいく、という前提を持たない。
また、成功に結びつけるには、更なる努力が必要

時には、一歩下がって見るのも大切
- どういう前提を自分で考えるか?を認識する
- アーキテクチャする時は、 AI を使てt壁売りをする

アーキテクチャを検討する時は、 「実際のデータ・数字」 を把握して考える
- 3 倍のコストでも、 Vs か、000 vs 000で 変わる
- スケールはどれくらい欲しいのか？どれくらいのトラフィックがあるのか？にもよる。
判断するためには、リアルなデータが必要になる。

常に他の選択肢があるかも、見落としていることはあるかも？と考える。
- 実際はもっと選択肢があるのではないか？をアーキテクチャは考える
- 問題を一視点しか見てないと、解決できない。
- 何か勘違いしている可能性がある、という前提も持つ
- そもそも今適切な情報になってるのか？
- 今のトレードオフは何なのか？
- 途中にある意思決定が重要になる
- いろんな可能性が無限に出てくる、ここの途中の過程があるから面白い

モノリス、マイクロサービスではなく、4つの領域で考える
- Replicas
- Modular Monolith
の二つが存在する
問題は何か？を理解した上で、何が必要なのか？を考える必要がある

変化するのにも、いろいろな背景がある。
- どうしてこのバージョンを延長させるのか？
- 変更するコストもかかる。
- だからベンダーロックインが起こる
- でも、これは必ずしも悪いことではない
- 一度いろいろな次元を理解すると、よりよい意思決定ができるようになる。

常に 「一番インパクトが大きい所」 を考える
- レイテンシーであれば、一番のボトルネックを解消する必要がある。
- また、重要な要件を明確にして、一貫性を持つのも大切
- いろいろと最適化しようとして、複雑になりすぎるとマイナスに

いい設計には、 「トレードオフ」 が付きまとう
- ちょっとしたトレードオフ・衝突が存在する
- 早く価値は出したいけど、一直線で行かない時もある。
- その時には、常に重要な原則に則って判断する

早々と意思決定をしきらない
- プロジェクト初期が、一番情報が少ない
- プロジェクトが始まるとわかってくることが多い
- 何もわかってない状態で全てを決めないようにする

アーキテクチャは、常に選択肢を持つ
- 仮説を持った上で取り組んで、それが当たればプラスで、外れれば負け
- 将来は見れないからこそ、選択肢を持って柔軟に対応できるようにする

選択肢は、時間が経つと正しいかどうかが判断しやすい
- オプションは、タイムトラベルとして扱える
- 時間が経てば、答えがわかっていく
- もっとキャパシティが必要ならさらに追加する
- 意思決定を先延ばしにすると、後々判断に必要な情報を取得できる
- ただ、全てに対して選択肢を持つのは費用的にはマイナス
- 自分で積極的に選ぶ必要が出てくる

最適なアーキテクチャは、スナップショットでは得られない
- 成長が今後見込まれるなら、よりスケールできるようにする
- また、利用者の数がどのように変わっていくのか？によっても、必要なインフラの要件は変わる

アーキテクチャを判断するときのモデルを作成する時は、「どこを見てるのか？何が必要なのか？」 を意識する
- 意思決定は一つのモデルで完結しない
- いいモデルは答えを出してくれる

全てのセッションで学びが多すぎて、毎回パンクしてました...
とても貴重なお話をありがとうございました！
明日もよろしくお願いいたします！

#アーキテクチャcon_findy November 11, 2025

11/29発売の『プラットフォームエンジニアリング』をご恵贈いただきました🙏
原著も大変興味深かったですが、訳者の松浦さんによる、著者の意図を汲み取った翻訳でさらに深い学びに繋がりました…。
Platform Engineeringに携わる多くの人に届いてほしいです✨ https://t.co/9ucdqVcIAY November 11, 2025

オライリー『プラットフォームエンジニアリング』のレビューに参加し、献本をいただきました！
レビュー時点でも、幅広いベストプラクティスが紹介された良書だと感じていたので、改めて読み直すのが楽しみです。
https://t.co/VMDYsCuSV1 https://t.co/JZsMCLblmY November 11, 2025

オライリーから発売される『プラットフォームエンジニアリング』の書籍をご恵贈いただきました。PFEM/PEKの有志メンバーと共同で、私も少しだけレビューに関わらせていただいてます。11/29発売予定ですので、気になる方は本屋さんへGO！ https://t.co/Ke9DV5R6Er November 11, 2025