- 2025/11/20
- https://architecture-con.findy-tools.io/2025
- https://conference.findy-code.io/conferences/architecture-con-2025/7/archives/slides
モダナイズの現実と選択：マイクロサービスが最適解か？
Sam Newmanさん
【AWS特別企画】実践的アーキテクチャレビュー会 〜KDDIアジャイル開発センター・gumi・ソラコム 〜
山﨑 翔太さん(アマゾンウェブサービスジャパン合同会社)
伊野瀬 出さん(KDDIアジャイル開発センター株式会社)
清水 佑吾さん(株式会社gumi)
片山 暁雄さん(株式会社ソラコム)
- アーキテクチャは責任分界点の設計
- それぞれの担当プロダクトに集中できるように分離
- 共通部分はプラットフォームとして提供
- IoT機器の通信の安全性
- AWS Well Architected
- AWS Well Architected Lens
- コンウェイ/逆コンウェイ
エーザイ戦略子会社が挑む、社会課題に「新しい答え」を生みだすマイクロサービスアーキテクチャ
- 認知症プラットフォーム
- 健康な人が増えることによるいいサイクル
- 医療介護費の削減
- 介護負担の軽減
- 労働力不足の解消
- 健康な人が増えることによるいいサイクル
- 発症リスクを下げる5finger
- アーキテクチャ
- AIによる開発
- マイクロサービス化された中で機能が小さいものはAIに自走させてみる
- ポータビリティ
- 個々のサービスが独立している
- クラウド移行もスムーズにできた
- API仕様
- オブザーバビリティ
- 専用のOtelサーバー
- AI関連はLangfuseへ
- それ以外はDatadogへ
- アプリ側はOtelのライブラリに依存するだけ
- AIとの会話
- 買い物に行くと言ったら何を買いに行くのかと聞いてあげたり
- AI側から話しかけてあげたり
- 最初のメッセージを内部的にAIに送ってあげることで会話をスタートさせる
- コンテキストなどをそこに入れておく
- ユーザの意見を肯定し続けるだけにならないように
- エコーチェンバー
- 過去のやりとりをそのまま保存するのではなく偏りを除去する
- 会話履歴を渡しすぎない
- ペルソナの活用
- ユーザ像を覚えさせて会話させる
- 毎日同じ行動してるかのように固定されてしまう
- 1ヶ月の予定を作成することで幅を持たせるよう工夫
- AIコンプライアンス
- 医療に関するやりとりをすることもある
- 例えば副作用はと聞かれても応えてはいけない
- 医師に聞いてと言わないと
- ガードレールのすり抜けはゼロにはできない
- プロダクトチームでアウトプットを検証
- JaDHA(日本デジタルヘルス・アライアンス)のチェックリスト
- リスクアセスメントシート
- Difyでシートを埋めていく
三菱UFJ銀行のアーキテクチャ戦略（エンタープライズアーキテクチャ～全行戦略～その後）
脇田 恭一郎さん(三菱UFJインフォメーションテクノロジー株式会社)
- EAの取り組み
- IT構築の都市計画
- 中長期的で持続的な取り組み
- 安心安定安全
- 開発保守効率の向上
- アジリティの向上
- EA推進からガイドラインを出したりレビューをしたり
- システムの複雑化肥大化
- 160システムで1億5000万ステップ
- あらゆる要望に愚直に応えて膨れ上がった
- 分岐が大量の解読困難なコード
- 人材問題
- 大規模合併などを経験したそうが高齢化し抜けていく
- このままだと数年で有識者がいなくなってしまう
- 全行アーキテクチャ戦略
- 2021年から指導
- MUFG社長をトップに委員会を
- 銀行システム部門とMUITだけでなく経営企画も巻き込んで現場の声を取り入れる
- トップが社長なので各部門が協力的な方向に
AI x Platform Engineeringでスケーラブルな組織を作るには
橋本 和宏さん(株式会社タイミー)
https://speakerdeck.com/kazutb/ai-x-platform-engineeringdesukeraburunazu-zhi-wozuo-runiha
- Platform Engineeringチーム
- PFEのスケール
- 少数になりやすく詰まりやすい
- タイミーでは7人で開発者の5%くらい
- 属人化してボトルネックになることも
- 人を増やしたとしてもそのオーバヘッドの問題もある
- スケールのしかたが難しい
- AI活用
複数事業を支える共通ID基盤のデータ設計とデータ・ID連携のアーキテクチャ
浦野 勝由さん(ウェルスナビ株式会社)
https://www.docswell.com/s/WN_Tech-PR/KPG18L-2025-11-20-154347
- ID基盤導入
- マルチサービス化
- 技術的負債
- 各サービスで似てるが差分があるという状態
- 難易度が高く保守が大変
- ID基盤の設計
- IDとメールアドレスを基板側でマスタとして持つ
- 更新されたらイベント駆動で各サービスに連携する
- 逆方向で更新する時はAPIで
- アーキテクチャ
- 可能な限り外部システムとの結合度を下げる
- 同期ではなく非同期でやりとりする
アーキテクチャの選択 ー ＜悩んだこと・変えたこと＞
無秩序からの脱却
nrsさん(株式会社コドモン)
https://speakerdeck.com/nrslib/emergence-from-chao
- 新規プロジェクト
- アーキテクチャについて勉強してるような人がほとんどいない
- まずは話し合うことからスタート
- 今の課題を解決する手段があることの動機づけ
- 変化への受け入れ度合いの確認
- 視座を変える
- 手本を作る
- 簡単/中難度/高難度
- ツール化してそっちに流れるように
- 他プロジェクトへの展開
- 新しいプロジェクトは過去のものを参考にされる
- 成功してるとしっているとなおさら
- 成功事例をスケールさせるために
- 考え方の型を学ぶ
完璧を求めない意思決定
竹内 健太さん(株式会社SmartHR)
https://speakerdeck.com/bmf_san/wan-bi-woqiu-menaiyi-si-jue-ding-akusesuzhi-yu-ji-pan-niokeruzhi-yue-tonoxiang-kihe-ifang
- 権限基盤
- 開発効率
- 統一的ユーザー体験
- セキュリティ
- マルチプロダクトで下図がどんどん増えていく
- 各プロダクトからの要望が集中してボトルネックになってしまう
- 従来の構成
- モノリスで中央集権
- プロダクト固有対応が難しい
- 理想的なアプローチ
- 各プロダクトが自律的に開発できるように
- ただし制約は出てしまう
- 落とし所の見つけ方
- 制約を設計のパラメータとしてとらえる
- ポリシーベースアーキテクチャ
- 既存UIを維持しながらポリシー層を追加
- 段階的に責務を分離していく
- アクセス性gyの仕組みだけ切り出した
- 中長期的な改善に向けた最初のステップ
LUUPの事業成長と変化の速さに耐えるモジュラーベースアーキテクチャの設計思想
安元 耀さん(株式会社 Luup)
- 事業成長に伴う課題
- データ量の増加
- LUUPのポート数が3年で1000倍
- 独自ドメイン領域が広がっている
- データ量の増加
- モジュールベースのアーキテクチャ
- モジュラーモノリスで
- 30以上のモジュール
- 1つ目を品質高く作って模倣しやすく
DMMプラットフォームのAI推進を支える情報アーキテクチャ
- AX
- AI Transformation
- AIで業務を根本から再設計
- 競争力と価値創造を高める
- これまでは人が集めて整理していた
- これからはAIが集めて提案し人が判断 3つの情報負債
- 分散
- データが散らばっている
- 人もAIも探しづらい状態
- 誰が責任を持つかが曖昧だしスピード優先で整理されない
- そもそも設計思想がなかった
- AIナレッジベースで一元化
- 形式知化する
- データが散らばっている
- 形骸化
- 更新されず複数バージョンが並ぶことも
- 誤ったデータを元にAIが処理してしまうことも
- 陳腐化しないような仕組み作りが必要
- リポジトリ管理する
- AIにレビューもさせやすい
- プロダクトの一部という認識にもなりやすい
- 属人化
- 暗黙知が特定の人の頭の中やDMに埋もれてる
- AIも人も活用できない
- 業務プロセスを見直して仕組みを作る
- 暗黙知が特定の人の頭の中やDMに埋もれてる
- ドキュメントの活用
- 同じリポジトリにドキュメントがあれば仕様通りに実装されてるかのチェックも楽にできる
- AIの使い分け
- 推測
- 曖昧な情報から類推
- 推論
- 構造化された情報から導出
- 機械的
- ルール通り確実に
- 土台を整えて推測させなくてすむようにすると安定する
- 推測
