翻訳を担当した書籍『ソフトウェアアーキテクチャの基礎 第2版 ― エンジニアリングに基づく体系的アプローチ』（オライリー・ジャパン）が3月6日に発売されます。本書は、2025年4月に出版されたMark Richards, Neal Ford著『Fundamentals of Software Architecture, 2nd Edition』（O'Reilly Media）を全訳したものです。
ソフトウェアアーキテクチャの基礎 第2版 - O'Reilly Japan
本書について
本書は、ソフトウェアアーキテクチャという分野が持つ多様な側面を現代的な視点から整理し、その基礎を詳しく解説した書籍です。本書の第1版は、2020年（邦訳は2022年）の刊行以来、国内外で高く評価され、ソフトウェアアーキテクチャに入門するための定番書としての地位を築いています。
本書の概要について詳しくは、第1版の邦訳刊行時に書いた次の記事をご覧ください。
『ソフトウェアアーキテクチャの基礎――エンジニアリングに基づく体系的アプローチ』 - snoozer05's blog
第2版での改訂について
第1版の刊行から5年が経過し、ソフトウェア開発の前提は大きく変化しました。アーキテクチャが時代とともに進化するように、本書もまた、著者らの新たな知見とこの間の技術的潮流を取り込み、大幅な改訂が行われています。
具体的には、クラウド活用、データアーキテクチャ、ガバナンス、チームトポロジー、生成AIなど、この数年で重要性を増したトピックが加わりました。加えて、もともとあった内容も全体的に深掘りされ、構成も再整理されています。分量も第1版の約430ページから約560ページへと大きく増え、読み応えのある一冊になっています。
『ソフトウェアアーキテクチャの基礎』第1版と第2版の厚さの比較画像です pic.twitter.com/0UcafsCV0B
— Koji Shimada / 島田浩二 (@snoozer05) 2026年3月4日
第2版の目次は次のようになっています。
本書への推薦の言葉
はじめに
1章 イントロダクション
1.1 ソフトウェアアーキテクチャの定義
1.2 ソフトウェアアーキテクチャの法則
1.3 アーキテクトへの期待
1.3.1 アーキテクチャ決定を下す
1.3.2 アーキテクチャを継続的に分析する
1.3.3 最新のトレンドを把握し続ける
1.3.4 決定の順守を徹底する
1.3.5 多様な技術に触れ、経験している
1.3.6 ビジネスドメインを理解している
1.3.7 対人スキルを持ち合わせている
1.3.8 政治を理解し、かじ取りする
1.4 本書の構成
第I部 基礎
2章 アーキテクチャ思考
2.1 アーキテクチャと設計
2.1.1 戦略的な決定と戦術的な決定
2.1.2 労力の度合い
2.1.3 トレードオフの重要性
2.2 技術的な幅
2.2.1 20 分ルール
2.2.2 パーソナルレーダーの開発
2.3 トレードオフを分析する
2.4 ビジネスドライバーを理解する
2.5 アーキテクティングとコーディングのバランスを取る
2.6 アーキテクチャ思考はもっと広い
3章 モジュール性
3.1 モジュール性と粒度
3.2 モジュール性の定義
3.3 モジュール性の測定
3.3.1 凝集度
3.3.2 結合度
3.3.3 コアメトリクス
3.3.4 主系列からの距離
3.3.5 コナーセンス
3.4 モジュールからコンポーネントへ
4章 アーキテクチャ特性
4.1 アーキテクチャ特性とシステム設計
4.2 アーキテクチャ特性の（部分的な）リスト
4.2.1 運用アーキテクチャ特性
4.2.2 構造アーキテクチャ特性
4.2.3 クラウドアーキテクチャ特性
4.2.4 横断的アーキテクチャ特性
4.3 トレードオフと最も現実的なアーキテクチャ
5章 アーキテクチャ特性を明らかにする
5.1 ドメインの関心事からアーキテクチャ特性を捉える
5.2 複合アーキテクチャ特性
5.3 アーキテクチャ特性を導き出す
5.3.1 カタを使う
5.4 事例：シリコンサンドイッチ
5.4.1 明示的なアーキテクチャ特性
5.4.2 暗黙的なアーキテクチャ特性
5.5 アーキテクチャ特性の制限と優先順位付け
6章 アーキテクチャ特性の測定と統制
6.1 アーキテクチャ特性の測定
6.1.1 運用アーキテクチャ特性の測定
6.1.2 構造アーキテクチャ特性の測定
6.1.3 プロセスアーキテクチャ特性の測定
6.2 統制と適応度関数
6.2.1 アーキテクチャ特性の統制
6.2.2 適応度関数
7章 アーキテクチャ特性のスコープ
7.1 アーキテクチャ量子と粒度
7.2 同期通信
7.3 スコープの影響
7.3.1 スコープとアーキテクチャスタイル
7.3.2 カタ：Going Green
7.4 スコープの決定とクラウド
8章 コンポーネントベース思考
8.1 論理コンポーネントの定義
8.2 論理アーキテクチャと物理アーキテクチャ
8.3 論理アーキテクチャの作成
8.3.1 核となるコンポーネントを識別する
8.3.2 コンポーネントにユーザーストーリーを割り当てる
8.3.3 役割と責務の分析
8.3.4 アーキテクチャ特性の分析
8.3.5 コンポーネントの再構成
8.4 コンポーネントの結合
8.4.1 静的結合
8.4.2 一時的結合
8.4.3 デメテルの掟
8.5 事例：「Going, Going, Gone」におけるコンポーネントの発見
第II部 アーキテクチャスタイル
9章 基礎
9.1 スタイルとパターン
9.2 基礎的なパターン
9.2.1 巨大な泥団子
9.2.2 ユニタリーアーキテクチャ
9.2.3 クライアント／サーバー
9.3 アーキテクチャの分割
9.3.1 カタ：シリコンサンドイッチにおける分割
9.4 モノリシックアーキテクチャと分散アーキテクチャ
9.4.1 誤信1：ネットワークは信頼できる
9.4.2 誤信2：レイテンシーがゼロ
9.4.3 誤信3：帯域幅は無限
9.4.4 誤信4：ネットワークは安全
9.4.5 誤信5：トポロジーは決して変化しない
9.4.6 誤信6：管理者は一人だけ
9.4.7 誤信7：転送コストはゼロ
9.4.8 誤信8：ネットワークは均一
9.4.9 その他の誤信
9.5 チームトポロジーとアーキテクチャ
9.6 特定のアーキテクチャスタイルへ
10章 レイヤードアーキテクチャ
10.1 トポロジー
10.2 スタイルの詳細
10.2.1 レイヤーの分離
10.2.2 レイヤーの追加
10.3 データトポロジー
10.4 クラウドに関する考察
10.5 一般的なリスク
10.6 統制
10.7 チームトポロジーに関する考察
10.8 スタイルの特徴
10.8.1 いつ使うか
10.8.2 いつ使わないか
10.9 例とユースケース
11章 モジュラーモノリス
11.1 トポロジー
11.2 スタイルの詳細
11.2.1 モノリシック構造
11.2.2 モジュラー構造
11.2.3 モジュール間通信
11.3 データトポロジー
11.4 クラウドに関する考察
11.5 共通のリスク
11.6 統制
11.7 チームトポロジーに関する考察
11.8 スタイルの特徴
11.8.1 いつ使うか
11.8.2 いつ使わないか
11.9 例とユースケース
12章 パイプラインアーキテクチャ
12.1 トポロジー
12.2 スタイルの詳細
12.2.1 フィルター
12.2.2 パイプ
12.3 データトポロジー
12.4 クラウドに関する考察
12.5 一般的なリスク
12.6 統制
12.7 チームトポロジーに関する考察
12.8 スタイルの特徴
12.8.1 いつ使うか
12.8.2 いつ使わないか
12.9 例とユースケース
13章 マイクロカーネルアーキテクチャ
13.1 トポロジー
13.2 スタイルの詳細
13.2.1 コアシステム
13.2.2 プラグインコンポーネント
13.2.3 「マイクロカーネル性」のスペクトラム
13.2.4 レジストリ
13.2.5 コントラクト
13.3 データトポロジー
13.4 クラウドに関する考察
13.5 一般的なリスク
13.5.1 コアシステムの高い変動性
13.5.2 プラグインの依存関係
13.6 統制
13.7 チームトポロジーに関する考察
13.8 スタイルの特徴
13.9 例とユースケース
14章 サービスベースアーキテクチャ
14.1 トポロジー
14.2 スタイルの詳細
14.2.1 サービスの設計と粒度
14.2.2 ユーザーインターフェイスのオプション
14.2.3 API ゲートウェイのオプション
14.3 データトポロジー
14.4 クラウドに関する考察
14.5 一般的なリスク
14.6 統制
14.7 チームトポロジーに関する考察
14.8 スタイルの特徴
14.9 例とユースケース
15章 イベント駆動アーキテクチャ
15.1 トポロジー
15.2 スタイルの詳細
15.2.1 イベントとメッセージの違い
15.2.2 派生イベント
15.2.3 拡張可能なイベントを送信する
15.2.4 非同期処理機構
15.2.5 ブロードキャスト機構
15.2.6 イベントペイロード
15.2.7 「ブヨの群れ」アンチパターン
15.2.8 エラー処理
15.2.9 データロスの防止
15.2.10 リクエスト・リプライ処理
15.2.11 メディエーター型イベント駆動アーキテクチャ
15.3 データトポロジー
15.3.1 モノリシックデータベーストポロジー
15.3.2 ドメインデータベーストポロジー
15.3.3 専用データベーストポロジー
15.4 クラウドに関する考察
15.5 一般的なリスク
15.6 統制
15.7 チームトポロジーに関する考察
15.8 スタイルの特徴
15.8.1 リクエストベースモデルとイベントベースモデルの選択
15.9 例とユースケース
16章 スペースベースアーキテクチャ
16.1 トポロジー
16.2 スタイルの詳細
16.2.1 処理ユニット
16.2.2 仮想化ミドルウェア
16.2.3 メッセージンググリッド
16.2.4 データグリッド
16.2.5 処理グリッド
16.2.6 デプロイメントマネージャー
16.2.7 データポンプ
16.2.8 データライター
16.2.9 データリーダー
16.3 データトポロジー
16.4 クラウドに関する考察
16.5 一般的なリスク
16.5.1 データベースからの頻繁な読み取り
16.5.2 データの同期と整合性
16.5.3 高データ量
16.5.4 データ衝突
16.6 統制
16.7 チームトポロジーに関する考察
16.8 スタイルの特徴
16.9 例とユースケース
16.9.1 コンサートチケット販売システム
16.9.2 オンラインオークションシステム
17章 オーケストレーション駆動サービス指向アーキテクチャ
17.1 トポロジー
17.2 スタイルの詳細
17.2.1 分類
17.2.2 再利用……と結合
17.3 データトポロジー
17.4 クラウドに関する考察
17.5 一般的なリスク
17.6 統制
17.7 チームトポロジーに関する考察
17.8 スタイルの特徴
17.9 例とユースケース
18章 マイクロサービスアーキテクチャ
18.1 トポロジー
18.2 スタイルの特徴
18.2.1 境界づけられたコンテキスト
18.2.2 粒度
18.2.3 データ分離
18.2.4 API レイヤー
18.2.5 運用面での再利用
18.2.6 フロントエンド
18.2.7 通信
18.2.8 コレオグラフィとオーケストレーション
18.2.9 トランザクションとサーガ
18.3 データトポロジー
18.4 クラウドに関する考察
18.5 一般的なリスク
18.6 統制
18.7 チームトポロジーに関する考察
18.8 スタイルの特徴
18.9 例とユースケース
19章 適切なアーキテクチャスタイルを選ぶ
19.1 アーキテクチャの「トレンド」の変化
19.2 判断基準
19.3 モノリスのケーススタディ：シリコンサンドイッチ
19.3.1 モジュラーモノリス
19.3.2 マイクロカーネル
19.4 分散アーキテクチャのケーススタディ：Going, Going, Gone
20章 アーキテクチャパターン
20.1 再利用
20.1.1 ドメインによる結合と運用による結合の分離
20.2 通信
20.2.1 オーケストレーションとコレオグラフィ
20.3 CQRS
20.4 インフラストラクチャ
20.4.1 ブローカーパターン
第III部 テクニックとソフトスキル
21章 アーキテクチャ決定
21.1 アーキテクチャ決定に関するアンチパターン
21.1.1 資産防御アンチパターン
21.1.2 グラウンドホッグデーアンチパターン
21.1.3 メール駆動アーキテクチャアンチパターン
21.2 アーキテクチャ上重要なもの
21.3 アーキテクチャデシジョンレコード
21.3.1 基本構造
21.3.2 例
21.3.3 ADR の保管
21.3.4 ADR をドキュメントとして使用する
21.3.5 ADR を標準として使用する
21.3.6 既存システムでのADR の使用
21.3.7 アーキテクチャ決定における生成AI とLLM の活用
22章 アーキテクチャ上のリスクを分析する
22.1 リスクマトリクス
22.2 リスクアセスメント
22.3 リスクストーミング
22.3.1 フェーズ1：識別
22.3.2 フェーズ2：合意
22.3.3 フェーズ3：リスク軽減
22.4 ユーザーストーリーリスク分析
22.5 リスクストーミングのユースケース
22.5.1 可用性
22.5.2 弾力性
22.5.3 セキュリティ
22.6 まとめ
23章 アーキテクチャの図解
23.1 図解
23.1.1 ツール
23.1.2 図解標準：UML、C4、ArchiMate
23.1.3 図解ガイドライン
23.2 まとめ
24章 効果的なチームにする
24.1 コラボレーション
24.2 制約と境界
24.3 アーキテクトのパーソナリティ
24.3.1 コントロールフリークアーキテクト
24.3.2 アームチェアアーキテクト
24.3.3 効果的なアーキテクト
24.4 どの程度関与すべきか？
24.5 チームの警告サイン
24.5.1 プロセスロス
24.5.2 多元的無知
24.5.3 責任の分散
24.6 チェックリストの活用
24.6.1 開発者向けコード完成チェックリスト
24.6.2 ユニットテスト・機能テスト用チェックリスト
24.6.3 ソフトウェアリリース用チェックリスト
24.7 ガイダンスの提供
24.8 まとめ
25章 交渉とリーダーシップのスキル
25.1 交渉とファシリテーション
25.1.1 ビジネスステークホルダーとの交渉
25.1.2 他のアーキテクトとの交渉
25.1.3 開発者との交渉
25.2 リーダーとしてのソフトウェアアーキテクト
25.2.1 アーキテクチャの4 つのC
25.2.2 プラグマティックでありながらもビジョナリーであること
25.2.3 手本を示してチームをリードする
25.3 開発チームに溶け込む
25.4 まとめ
26章 アーキテクチャと交わるもの
26.1 アーキテクチャと実装
26.1.1 運用上の関心事
26.1.2 構造上の整合性
26.1.3 アーキテクチャの制約
26.2 アーキテクチャとインフラストラクチャ
26.3 アーキテクチャとデータトポロジー
26.3.1 データベーストポロジー
26.3.2 アーキテクチャ特性
26.3.3 データ構造
26.3.4 読み書きの優先順位
26.4 アーキテクチャとエンジニアリングプラクティス
26.5 アーキテクチャとチームトポロジー
26.6 アーキテクチャとシステム統合
26.7 アーキテクチャと全社標準
26.8 アーキテクチャとビジネス環境
26.9 アーキテクチャと生成AI
26.9.1 生成AI をアーキテクチャに組み込む
26.9.2 生成AI をアシスタントとして活用する
26.10 まとめ
27章 ソフトウェアアーキテクチャの法則（再考）
27.1 第一法則：ソフトウェアアーキテクチャはトレードオフがすべてだ
27.1.1 共有ライブラリと共有サービス
27.1.2 同期メッセージングと非同期メッセージング
27.1.3 必然的帰結その一：トレードオフの見落とし
27.1.4 必然的帰結その二：一度だけではできない
27.2 第二法則：「どうやって」よりも「なぜ」の方がずっと重要だ
27.2.1 コンテキスト無視アンチパターン
27.3 極端な選択肢の間のどこか
27.4 最後のアドバイス
この大幅な増補改訂により、本書は、これからソフトウェアアーキテクチャを学ぶ方々のための入門書として、いっそう完成度の高いものに仕上がったと感じています。
とはいえ、本質的なメッセージは第1版から変わりはありません。本書が繰り返し強調する最も重要なメッセージは、ソフトウェアアーキテクチャに絶対的な正解はなく、すべてがトレードオフの上に成り立っているという点です。
新しい技術やプラットフォーム、製品を広めたい人たちによる「正解」が、世の中にはどうしても溢れています。ですが、アーキテクトが実際に向き合うのは、制約も状況も少しずつ変わっていく現実です。現実世界のアーキテクトの仕事に「正解」はありません。だからこそ、トレードオフを見据えながら、イテレーティブにアーキテクチャを育てていく姿勢が大切になります。
本書は、そのための道具立てを与えてくれる一冊です。この第2版が、これからソフトウェアアーキテクチャについて学ぶ方、そして現場で悩んでいる方のえとなる一冊になることを、訳者として切に願っています。ボリュームのある一冊ではありますが、ぜひ手に取っていただけると幸いです。
