はじめに
2025/11/20~21にベルサール羽田空港で開催された「アーキテクチャConference2025」に参加してきました。
折角いろいろとメモを取ったので形にせねば！ということで、初めてこのような参加レポートを書いてみようと思います。
参加してみての感想や、特に印象に残った発表について改めて振り返ってみようと思います。
（個人メモ的な書き味になってしまっていますがご容赦ください 
）
全体的な感想
- 生成AI時代だからこその「人間の意思決定力」が重要であると再確認
- AWSが提唱するAI-DLC1でも「開発者は、検証、意思決定、監督の最終的な責任を保持する」と語られていました
- コンウェイの法則よろしく、アーキテクチャを語るうえで外せないのが「組織構造」
- よりプロダクトの価値を高めるためのアーキテクチャ設計において、組織構造を変えてしまうというのがアプローチの1つであると再発見
- アーキテクチャに問題がある時、組織構造に着目してみる
- 基調講演は聴いて理解することに精一杯で、メモを取る余裕がなかった
- 来年頑張ることの一つに「英語でのコミュニケーション能力向上」を設定するべきと痛感
- レコグラは分かりやすく、ポップな絵柄でとても良い取り組みだなと感心しておりました
↓こんな感じ
特に印象に残ったセッション
全て書くと文量がとんでもないことになるので、3点ほど
目的で駆動する、AI時代のアーキテクチャ設計
by ミノ駆動さん（合同会社DMM.com）
概要
- AIによるコーディング（AX: AI Transformation）は開発を高速化する一方で、以下のような課題も引き起こす可能性がある。
- 高速実装による負債の蓄積: 目的を理解しないままコードが生成され、構造的な崩壊を招く。
- AIの混乱: 既存の設計意図（目的）が不明確だと、AIが不適切なコードを追加・変更し、既存機能を破壊する。
- 持続可能性の欠如: ただ動くコードを作るだけでは、変更容易性が損なわれ、長期的な開発が困難になる。
- これらを解決するためには、「目的」を持ったアーキテクチャ設計が不可欠である。
ポイント
- 目的→目標→手段という順にブレイクダウンして考えていくことが重要
- 手段は目標達成のためにある。目標は目的を達成するためにある。
- 上位にある目的、目標を達成できない手段は選ぶべきではない
- 上記の考え方は設計パターンに昇華できる
- ドメイン駆動設計やクラス毎の責務分割、アーキテクチャレイヤ
- 「契約による設計」2は目標の厳密な定義である
- 事前条件、事後条件、不変条件を考えることで、目標を設計する
- 開発タスクを書く際に、「目的-目標-手段」の形式を取ることで、それをそのままAIへの指示に転用することも可能
- 仕様書（目標）だけを見ていても本来の「目的」は分からず、変更容易性の高い設計は困難。人間が目的を正しく定義し構造化することで、AIは良きパートナーとなる。
感想
- 今まで開発者は「手段」について試行錯誤してきたが、今後はより視座を高くビジネス的な視点を持たないと仕事がなくなるよね
- ただ、手段について厳密な検証は出来なければいけないので、技術的研鑽は引き続きやっていく必要がある
AI時代のインシデント対応〜現場に権限を、組織に学習を〜
by 草間 一人さん（PagerDuty株式会社）
概要
- AI時代の課題: デプロイ頻度増加とシステム複雑化により、インシデントは増加する。強固な組織アーキテクチャの構築が必要。
- ICSの導入: インシデントコマンダーに全権限を与え、指揮系統を明確化。コントロールプレーン(意思決定)とデータプレーン(情報伝達)を分離。
- フルサービスオーナーシップ: 開発者がライフサイクル全体に責任を持ち、フィードバックループで改善を続ける。
- AIと組織学習: AIを適材適所で活用しつつ、ポストモーテムを通じて技術と組織アーキテクチャの両面を改善。
ポイント
- 障害のほとんどはデプロイによって引き起こされる = デプロイが増えると障害が増える
- AIエージェントで開発が高速化する→デプロイ頻度が上がる→障害が増えるの構図
- AI活用のための構造設計が重要
- システム障害による混乱は人や組織の構造から生まれる
- 情報の流れ、意思決定、責任の所在が曖昧な組織アーキテクチャから生じる
- 組織構造を「平時」と「戦時」で分けて設計する
- 戦時＝インシデント・障害発生時、インシデントの解決が最重要
- 平時＝戦時でない時、ビジネスを回すのが最重要
- インシデント発生時にインシデントコマンダー（以下、IC）を配置し、ICが対応の指揮を執る
- 戦時はICが一番偉くなる構図（あくまでインシデントの解決の文脈において）
- 最初に現場到着したメンバーがICを務めるのがセオリー、決め方は組織でルールを作ると良い
- 起きたインシデントは振り返り、改善に繋げる（ポストモーテム）
- 人間的な要素に注目する（なぜそのように対応したのか？など）
- 技術的課題と組織アーキテクチャの2点から振り返る
- 開発Tと運用Tで分断する体制はそろそろ限界？→フルサービスオーナーシップの適用
- 開発メンバーが運用メンバーに「そのコードはAIが書いたから分からん…」とか言えないよね
- 上記の組織設計を踏まえた生成AIの活用
- 状況判断や意思決定、責任をとることは人間にしか出来ない
感想
- 状況に応じて組織構造を変えるというアイデアがかなり参考になった
- 自社でもインシデント発生時はそれ用の対策チーム等が立ち上げられることもあるが、在り方はかなり違うかな？と感じた
- （結果的に出来てるような気もするが）ポストモーテムにおいて「人間的な要素への着目」はかなり重要だとセッションを聴いて思った。
- 自チームで何度かポストモーテムを実施する機会があったが、何だかんだ人間的な視点での振り返りができていた記憶
セキュリティアーキテクトの設計思考──変化と制約を前提とした“再現性ある判断軸”とは
by 石川 朝久さん（東京海上ホールディングス株式会社）
概要
- セキュリティアーキテクチャの本質：予防・検知・ハントの3層防御で攻撃者を排除する構造設計（城の防御構造に例えられる）
- 設計アプローチ：標準フレームワーク適用（コンプライアンス型）と脅威モデリング（リスクベース型）を組織規模や対象に応じて使い分ける
- トレードオフ判断：捨象（共通基盤への委譲）・優先順位（Crown Jewel保護）・将来性（拡張可能性）の3原則で早期に判断
- 組織への浸透：セキュリティを「後付け（Bolt-On）」から「組み込み（Built-In）」へ移行し、自動化・ガードレール・伴走支援で開発プロセスに統合
ポイント
- 「アーキテクチャ」という広い言葉の中に、セキュリティアーキテクチャというものもある
- 侵入されづらい構造設計
- セキュリティ要件の洗い出し
- 「理想状態 (To-Be)」と「現状 (As-Is)」の差分から抽出する
- コンプライアンス型とリスク型という2種類のアプローチ
- セキュリティアーキテクチャの決定におけるトレードオフ
- パフォーマンス、ユーザビリティ、開発スピードの全てを兼ね備えるのは困難
- 制約条件や他のアーキテクチャ特性が明らかになった時点で議論するのが好ましい
- 判断基準となる3つの原則：捨象（見極め）、優先順位、将来性
- 組織の規模・フェーズによって、目指すべき戦略は異なる
- スタートアップ・小規模: リスクベース型
- 中規模: コンプライアンス型
- 大規模: コンプライアンス型 × リスクベース型
感想
- セキュリティ対策ってどの程度やればいいんだろう、という漠然とした不安に対する考え方が手に入ったなと感じた
- セキュリティ従事者視点での話を聞くことがあまりなかったので新鮮だった
- 早期関与が好ましいということで、積極的に相談していく方がお互いWin-Win
- 脅威モデリングワークショップは一度チームでやってみたい
最後に
2日間通して新たな発見や刺激を沢山得ることができました。
アーキテクチャカンファレンスの参加は初めてでしたが、とても良いイベントだったので来年開催があるなら社内から何人か連れていきたいなと…！
（ゆくゆくは登壇出来るところを目指して…！）
素敵なイベントを作り上げてくださった主催のFindy様、スピーカーの皆様、スポンサーの各社様に感謝申し上げます。
資料・リンク集
- イベント詳細