はじめに
「モノリスをマイクロサービスに分割しましょう」という話は、もう十分に語り尽くされた感があります。しかし実際に手を動かす段になると、途端に困ることばかりです。
- どこから切り出せばよいのか
- 切り出したサービスの API は REST でよいのか、gRPC にすべきか
- 外から来る通信と、サービス間で飛び交う通信は同じ仕組みで管理してよいのか
- 段階的に移行する間、既存システムを止めずにどう共存させるのか
本書『マスタリングAPIアーキテクチャ』は、こうした「理屈は分かったが、で、どうすればいいのか」に対して、API を軸にアーキテクチャを段階的に進化させるという一貫した視点から答えを出そうとする本です。
本記事では、本書の全体構成と各章の要点、そして読んで特に印象に残った点をまとめます。
書誌情報
| 項目 | 内容 |
|---|---|
| 書名 | マスタリングAPIアーキテクチャ ―モノリシックからマイクロサービスへとアーキテクチャを進化させるための実践的手法 |
| 著者 | James Gough、Daniel Bryant、Matthew Auburn |
| 訳者 | 石川 朝久 |
| 出版社 | オライリー・ジャパン |
| 発行 | 2024年10月17日（初版第1刷） |
| ISBN | 978-4-8144-0089-8 |
著者陣は Morgan Stanley の Distinguished Engineer（James Gough）、Ambassador Labs のデベロッパーリレーションズ責任者（Daniel Bryant）、そして金融システムとセキュリティを専門とする Matthew Auburn という顔ぶれです。この構成が、本書の「設計」「プラットフォーム」「セキュリティ」という三本柱にそのまま対応しています。
一言でいうと
API を「システムを段階的に進化させるための道具」として捉え直す本
本書はグリーンフィールド（新規開発）を前提にしていません。既存のアーキテクチャを、進化的アプローチで少しずつ改善していくことこそ読者にとって最も有益である、という立場が明確に打ち出されています。
そして序文でも触れられているとおり、著者たちは明確なベストプラクティスがある領域ではそれを示す一方、状況によって答えが変わる領域では「何に依拠して決めるのか」を示すフレームワークを提供します。この姿勢が本書全体のトーンを決めています。
想定読者
本書はペルソナを3つ挙げています。開発者（数年の実務経験があり API の設計・テストを深く学びたい層）、偶発的アーキテクト（Accidental Architect）（正式な肩書きはないが実質的にアーキテクチャレベルの意思決定をしている層）、ソリューション／エンタープライズアーキテクト（複数システムの統合と標準化を担う層）です。
個人的には2番目の「偶発的アーキテクト」が刺さりました。チームリーダーやテックリードとして、気づけばアーキテクチャの意思決定をしている――そういう立場の人にこそ本書は効きます。
全体構成
本書は4部10章に加え、イントロダクションと総括章から構成されています。
| 部 | 章 | テーマ |
|---|---|---|
| — | イントロダクション | ケーススタディ／C4／ADR の導入 |
| 第1部 | 1章・2章 | API の設計・構築・仕様化／テスト |
| 第2部 | 3章・4章 | API ゲートウェイ／サービスメッシュ |
| 第3部 | 5章・6章・7章 | 展開とリリース／脅威モデリング／認証・認可 |
| 第4部 | 8章・9章 | API 駆動への再設計／クラウド移行 |
| — | 10章 | 総括と将来展望 |
「設計 → テスト → トラフィック管理 → 運用・セキュリティ → 進化」という流れが、そのまま API のライフサイクルに沿っています。
本書を貫く3つの装置
本書を読み進める上で、最初に押さえておくと理解が一段深まる仕掛けが3つあります。
1. カンファレンスシステムというケーススタディ
出席者が講演を閲覧・予約するカンファレンスシステムが、本書全体を通じて登場します。最初は UI・サーバ・データストアの典型的な3層アーキテクチャです。
そこに、アプリオーナーから3つの要求が来ます。
- モバイルアプリを構築したい
- グローバル展開し、外部の CFP（Call For Papers）システムと統合したい
- 自社データセンタを廃止し、クラウドで運用したい
この要求を起点に、Attendee（出席者）コンポーネントを独立サービスとして切り出すところから旅が始まります。以降、各章の学びがこのシステムに毎回反映されていく構成になっており、抽象論が宙に浮きません。
2. C4 ダイヤグラム
アーキテクチャの可視化には C4 モデルが使われます。UML の課題は「アーキテクトや開発者の記憶に残りづらい」ことだと本書は指摘し、Context / Container / Component の3種類の図で議論を進めます。「多くの UML ダイヤグラムは、誰かが間違えて油性マジックで書いたときのみプロジェクトの履歴として残る」というジョークが引かれており、なかなか痛烈です。
3. ADR ガイドライン
本書の最大の特徴が、この ADR（Architecture Decision Records）ガイドラインです。
アーキテクチャの問いに対する答えは、多くの場合「場合による」になります。本書はそこで止まらず、「では何に依拠するのか」を 決定事項 / 論点 / 推奨事項 の3項目で整理したガイドラインを各所に配置しています。
たとえば「通信をどうモデル化するか」の論点は、外部トラフィックか内部トラフィックか、利用者側のコードを自分たちでコントロールできるか、どのようなバージョン管理が必要か、高トラフィックで帯域幅やパフォーマンスが問題になるか、といった項目です。推奨事項としては、外部利用者向けなら参入障壁が低く強いドメインモデルを提供できる REST、自分たちの管理下にある2サービス間の密なやり取りや高トラフィックなら gRPC を検討する、と示されます。
この「論点の言語化」だけでも本書を読む価値があります。
第1部：API の設計・構築・テスト
1章 API の設計・構築・仕様化
REST、RPC（gRPC）、GraphQL のそれぞれの立ち位置を整理する章です。
リチャードソン成熟度モデルが改めて丁寧に解説されます。
| レベル | 内容 |
|---|---|
| レベル0 | HTTP/RPC。単一 URI に POST するだけ。実質 REST 上の RPC |
| レベル1 | リソース。URI でリソースをモデル化する |
| レベル2 | 動詞。HTTP メソッドで操作を表現し、冪等性を保証する |
| レベル3 | ハイパーメディアコントロール（HATEOAS） |
興味深いのは、レベル3 への評価がかなり現実的なことです。柔軟な UI を持つシステムでは有効だが、サービス間の API 呼び出しには適さず、実際のところ現代の RESTful HTTP サービスではほとんど使われていない、と本書は述べます。目指すべきは基本的にレベル2、という現場感覚に沿った結論です。
GraphQL については、複数の API にまたがるフィールドをクライアントが必要な分だけ正確にリクエストできる点、全 API で単一バージョンを提供できる点が利点として整理されます。画面が小さくネットワーク制約のあるモバイルでは特に有利、という説明は納得感があります。
OpenAPI 周りでは、コード生成・検証・モック・変化の検知という4つの実践的活用が示されます。重要なのは「OpenAPI を導入する」ではなく「どの機能をプロジェクトに適用するかを積極的に選択する」という言い方をしている点です。バージョン管理については「利用者に公開される API は、バージョン管理を行わないと危険」とはっきり警告されます。
さらに、REST と gRPC の両方を提供する「マルチフォーマット API」の難しさにも踏み込みます。OAS から .proto を自動生成すると、後方互換のつもりで追加したフィールドがアルファベット順に挿入されてフィールド ID がずれ、バイナリ互換性が壊れる――という具体例は、思わず「そうなるのか」と唸りました。
2章 API のテスト
テストの4象限、テストピラミッドといった基本を押さえた上で、本書が最も強く推すのがコントラクトテストです。
コントラクトはリクエストとレスポンスがどうあるべきかを定義するもので、コントラクトテストはそれが履行されているかを検証します。失敗するということは、提供者が契約を守っておらず、利用者が API を使えないことを意味します。本書は、提供者と利用者のやり取りを定義する方法としてコントラクトが最適だと言い切ります。さらにコントラクトからスタブサーバを構築できるため、追加サービスを起動せずローカルで検証できる、という運用上のメリットもあります。
そのほか、コンポーネントテスト、Testcontainers を用いた統合テスト、E2E テストが順に扱われ、それぞれに「追加すべきか否か」を判断する ADR ガイドラインが付きます。テストは全部やればよいのではなく、どこに時間を投資するかの意思決定である、という整理が一貫しています。
第2部：API トラフィック管理
ここから本書の色がはっきり出てきます。トラフィックを 外部トラフィック（North-South） と 内部トラフィック（East-West） に分け、それぞれ別の道具で管理する、という設計思想です。
3章 API ゲートウェイ
まず「API ゲートウェイは唯一のソリューションなのか？」という問いから始まり、答えは端的に「ノー」です。自分たちが推す技術にも最初に疑いを向ける姿勢が本書らしいところです。歴史的経緯の整理も秀逸で、1990年代のハードウェアロードバランサ → ソフトウェアロードバランサ → ADC → 第一世代 API ゲートウェイ → 2015年以降の第二世代、という流れで「なぜ今の形になったのか」が腑に落ちます。
分類法として3種類が提示されます。
| 種類 | 主目的 | 特徴 |
|---|---|---|
| 従来の商用 API ゲートウェイ | ビジネス API の公開・管理・収益化 | ライフサイクル管理と統合。外部データストアの運用が必要 |
| マイクロサービス API ゲートウェイ | バックエンドへのインバウンドルーティング | Envoy 等がベース。サービスメッシュとの統合に優れる |
| サービスメッシュゲートウェイ | メッシュへの入口 | メッシュと暗黙に結合。単独採用には向かない |
デプロイ時の落とし穴として挙げられるのが、API ゲートウェイの ESB 化と「ずっと下まで亀（API ゲートウェイ）が続いているのよ」という多段化アンチパターンです。ゲートウェイにビジネスロジックを載せ始めると、機能性の低い ESB が出来上がる――この警告は現場で何度も思い出すことになりそうです。
単一障害点になり得る点についても、検知・認知・解決・リスク低減という節が丁寧に割かれています。
4章 サービスメッシュ
こちらも「サービスメッシュは唯一の解決策なのか？」から始まります。そして印象的な一文がこれです。
すべてのアーキテクチャにはトレードオフがあります。アーキテクトの役割を果たす上で、フリーランチは存在しません。
サービスメッシュが提供するのは、細かなルーティング制御、透過的なオブザーバビリティ、mTLS を含むセキュリティの強制、多言語対応、そして外部／内部トラフィック管理の分離です。実装パターンとしては、言語固有ライブラリ、サイドカープロキシ、プロキシレス（gRPC）、eBPF などのカーネルベース技術が比較されます。
ケーススタディでは、Istio でルーティング、Linkerd でオブザーバビリティ、Consul でネットワークセグメンテーション、と実際のプロダクトが登場します。
章の締めくくりが本書のスタンスをよく表しています。サービスメッシュの最も脆弱なコンポーネントは通常コントロールプレーンであり高可用性サービスとして運用する必要があること。導入可否と技術選定は Type 1 の意思決定（取り消せない一方通行のドア）であること。採用するなら独自開発ではなくオープンソース実装か商用ソリューションで標準化するのがベストであること。Type 1 / Type 2 の区別を持ち込むことで、「慎重に決めるべきこと」と「さっさと試せばよいこと」が切り分けられます。
第3部：API の運用とセキュリティ
5章 API の展開とリリース
この章の出発点は、デプロイメントとリリースの分離です。
分離の手段として、コードレベルではフィーチャーフラグ、インフラレベルではトラフィック管理が示されます。リリース戦略としてはカナリアリリース、トラフィックミラーリング、ブルーグリーンが並びます。
カナリアについて、Kubernetes だけで実現しようとすると 1% のトラフィックを流すために v1 のポッドを99個と v2 のポッドを1個動かす必要がある、という指摘は実務的で刺さりました。だからこそサービスメッシュや API ゲートウェイのトラフィックシフト、あるいは Argo Rollouts のようなツールが必要になる、という筋道です。
メトリクスの節も良質です。RED メソッド（Rate / Errors / Duration）や SRE の「4つのゴールデンシグナル」を紹介した上で、ルールに注視するあまりシステムの広いコンテキストを見逃す、という最大の欠点を指摘します。具体例が鋭くて、500番台は明らかにインフラ／サービス障害だが、400番台はクライアント側の問題だから無視してよいのか？ 連続した 403 Forbidden は、権限のないデータにアクセスしようとする攻撃者の兆候かもしれない――と展開されます。メトリクスはコンテキストとセットで初めて意味を持つ、という主張です。
カンファレンスシステムでの具体例としては、利用者ごとの1分あたりのリクエスト数、平均レイテンシ（SLO）とその著しい逸脱、外部 CFP システムからの 401 エラー数（侵害やトークン盗難の兆候）、可用性と稼働時間、メモリ／CPU 使用状況などが挙がります。
6章 セキュリティ運用：脅威モデリング
セキュリティは「シフトレフト」すべき、という主張から始まります。理想は「スタートレフト」、つまり開発の最初からセキュリティを前提に組み込むこと、という注釈まで付いています。
脅威モデリングは6ステップで示されます。
- 目標の特定
- 適切な情報の収集
- システムの分解（データフローダイヤグラム＝DFD の作成）
- STRIDE を利用した脅威の特定
- DREAD によるリスク評価
- 検証
STRIDE は、なりすまし（Spoofing）／改ざん（Tampering）／否認（Repudiation）／情報漏洩（Information disclosure）／サービス拒否（Denial of Service）／権限昇格（Elevation of Privilege）の頭文字です。DREAD は被害・再現性・悪用可能性・影響ユーザ数・発見可能性を各1〜10で採点し、合計を5で割ってリスク値を算出します。DREAD について「Microsoft ではもはや利用されていない」「基準が主観的で一貫性に欠ける」という注意書きが添えられているのも、鵜呑みにさせない誠実さです。
章のメッセージは、セキュリティ専門でないエンジニアにとって重要です。脅威モデリングの実施にセキュリティ専門家である必要はなく、「攻撃者のように考えること」が重要なスキルである、と本書は述べます。OWASP API Security Top 10 を出発点に、Microsoft Threat Modeling Tool のような自動分析ツールで叩き台を作る、という現実的な進め方も示されています。
7章 API の認証と認可
認証（誰であるか）と認可（何が許されるか）を切り分けた上で、OAuth2 と OIDC を軸に解説する章です。
特に納得したのが「キーとユーザを混ぜてはいけない理由」の節でした。外部 CFP システムが API キーで自身を識別できても、そのシステムが「今どのエンドユーザの代理で動いているか」を主張できるわけではありません。かといってユーザ名とパスワードを第三者システムに渡すのは論外です。この構造的なジレンマの解として OAuth2 が導入される、という流れが非常に腹落ちしました。
要点は以下のとおりです。
- OAuth2 は API セキュリティの事実上の標準で、Bearer ヘッダ内の JWT と組み合わせて使われることが多い
- JWT はエンコードおよび署名され、改ざんされていないことを保証する
- 最も一般的な構成は 認可コードグラント + PKCE か クライアント認証情報グラント
- リフレッシュトークンは、ユーザに認証情報の再入力を強いないための仕組み
- スコープは粗い粒度の認可を提供し、エンドユーザがクライアントへのアクセスを設定できるようにする
- クライアントがエンドユーザの情報を必要とする場合は OIDC を使う
第4部：API を利用した進化的アーキテクチャ
8章 API 駆動アーキテクチャへの再設計
本書の中核をなす章だと感じました。
キーワードは 凝集性（Cohesion） と 疎結合（Loose Coupling） という、きわめて古典的な概念です。API はシステム内の自然な抽象化であり「シーム（seam）」を提供する、という捉え方が示されます。
最終アーキテクチャの選択肢としてモノリス、SOA、マイクロサービス、関数型アーキテクチャが並列に扱われるのも良いところです。マイクロサービスが唯一のゴールではない、という前提が明確になっています。
進化プロセスの管理は、目標の決定 → 適応度関数の利用 → モジュールへの分解 → シームとしての API 作成 → 変更レバレッジポイントの特定 → 継続的デリバリーと検証、という順で進みます。
パターンとしては、既存システムを包み込みながら段階的に置き換えるストラングラーフィグ、呼び出し先を制御して新旧サービスを切り替えるファサード／アダプタ、そして階層化 API である API Layer Cake（各層内の凝集は高くても層間が結合しやすいという歴史的トレードオフも併記）が紹介されます。進化を止める側の要因、つまりペインポイント（アップグレード／メンテナンスの問題、パフォーマンス問題、密結合した API）の見つけ方にも紙面が割かれています。
本章の警告で最も実務的だったのは、現在のゴールと制約を常に明確にすべきだ、という指摘でした。これを明確に設定し共有しなければ、移行は無制約になりがちで、リソースを消耗する一方でほとんど価値を提供せず、チームのモラルにも影響しかねません。「終わらないリアーキテクチャ」を経験したことがある人ほど、この一文の重さが分かるはずです。
9章 クラウド環境への移行
クラウド移行戦略として「6つの R」が整理されます。
| 戦略 | 内容 |
|---|---|
| Retain / Revisit | 保持・再検討（何もしない） |
| Rehost | 再ホスティング（いわゆるリフトアンドシフト） |
| Replatform | 再プラットフォーム |
| Repurchase | 再購入（SaaS 等への置き換え） |
| Refactor / Re-architect | リファクタリング／再設計 |
| Retire | 廃止 |
移行時のポイントは、API ゲートウェイをファサードとして使い、ロケーションの透明性を提供することです。これにより、サービスをクラウドにデプロイしつつ、通信を既存サービスから新サービスへ徐々にシフトさせても、利用者への影響を限定的（あるいはゼロ）にできます。
後半はゼロトラストの話に移ります。境界防御型からゼロトラストへという流れの中で、サービスメッシュがその移行を円滑にする役割を担う、という位置づけです。面白いのは、サービスメッシュだけではゼロトラストは完成しないと明言している点でした。サイドカーはアプリケーションと密結合しているため、その配下のプラットフォームについては何も保証できません。そこで Kubernetes の NetworkPolicies（Calico など）と組み合わせ、default-deny-all を出発点にマイクロセグメンテーションを構成する具体例が示されます。
さらに、マルチクラスタのサービスメッシュをピアリングし、オンプレとクラウドのデータプレーンに統合されたコントロールプレーン設定を適用するハイブリッド構成にまで踏み込みます。「オンプレをクラウドのように機能させる」ことで残りのサービスをクラウドへ進化させる道筋が見えてくる、という論展開は説得力がありました。
10章 総括と将来展望
最終章では、旅路の振り返りとして、C4 図の変遷が一気に並べ直されます。3層モノリスから始まり、Attendee サービスの抽出、API ゲートウェイの導入、Session サービスの抽出とサービスメッシュ、フィーチャーフラグによる並行運用、モバイルアプリと脅威モデリング、外部 CFP システムと認証・認可、そしてクラウド移行とマルチクラスタメッシュ。
この一連の図を並べて眺めると、アーキテクチャの複雑さと引き換えに柔軟性を得ているというトレードオフが視覚的に理解できます。
そのほか、コンウェイの法則（「4つのグループがマイクロサービスシステムに取り組んでいるなら、4種類の API ができる」）、Type 1 / Type 2 の意思決定、そして将来の注目領域として非同期通信と AsyncAPI、HTTP/3（QUIC によるヘッドオブラインブロッキングの解消）、プラットフォームベースのメッシュが扱われます。
最後の「学び続ける方法」の節も良かったです。基本を絶えず磨くこと、業界ニュースと技術トレンドレポートを定期的に見ること、実践で学ぶこと、そして教えることで学ぶこと。特に最後の項目は、こうして書評を書く行為そのものへの後押しになりました。
特に印象に残った点
1. 「場合による」で終わらせない設計
本書の価値の大半は ADR ガイドラインにあると感じました。アーキテクチャの問いに一般解がないのは事実ですが、論点を列挙して意思決定を構造化することはできます。「決定事項 / 論点 / 推奨事項」というフォーマットは、そのまま自分のチームに持ち込めます。
2. 外部トラフィックと内部トラフィックの分離
North-South と East-West を明確に分け、それぞれに API ゲートウェイとサービスメッシュを対応させる整理は、モヤモヤしていた部分を一気にクリアにしてくれました。同時に、9章で「クラウド移行時にはこの境界が曖昧になる」と自ら揺さぶってくる点も含めて誠実です。
3. アンチパターンの充実
「API ゲートウェイを ESB として使う」「サービスメッシュを ESB として使う」「サービスメッシュをゲートウェイとして使う」「ネットワークレイヤが多すぎる」――どれも実際にやってしまいそうなものばかりです。避けるべき悪手のカタログとして繰り返し参照できます。
4. セキュリティが後付けになっていない
セキュリティ専門の著者が入っていることもあり、脅威モデリングと認証・認可に丸2章が割かれています。「設計の本」でここまでセキュリティに紙面を割く例は多くありません。訳注も充実しており、日本語圏の参考リンク（メルカリの脅威モデリング事例など）が補われているのは翻訳書として大きな価値です。
5. ケーススタディが最後まで一貫している
同じカンファレンスシステムが章を追うごとに姿を変えていくため、「この技術は、いつ、なぜ導入されるのか」が常に文脈付きで理解できます。技術単体の解説書との決定的な違いはここだと思います。
気になった点
-
具体的なコードは多くありません。 Kubernetes マニフェストや
.protoの断片は登場しますが、実装のハンズオン本ではありません。 - 各技術の網羅的な比較表を期待すると物足りないかもしれません。Istio / Linkerd / Consul は登場しますが、製品選定ガイドではなく「選び方の考え方」を教える本です。
- 原書は2022年刊のため、エコシステムの最新動向（Kubernetes Gateway API や eBPF ベースのメッシュの成熟など）は自分で補う必要があります。ただし主張の中核は原理原則寄りなので、陳腐化しにくい構成です。
こんな人におすすめ
- モノリスからの段階的な移行を、これから計画する立場の人
- API ゲートウェイとサービスメッシュの使い分けが曖昧なままになっている人
- 技術選定の場で「なんとなく」ではなく、論点を示して合意形成したい人
- 設計はできるが、運用・セキュリティまで含めて語る言葉を持ちたい人
逆に、REST API の書き方そのものを学びたい入門者や、特定プロダクトの設定方法を知りたい人には、本書はやや遠回りかもしれません。
まとめ
本書を読み終えて残るのは、「アーキテクチャは目的地のない旅路である」という一貫したメッセージです。
技術は変わり、ビジネス要件も変わります。だからこそ、一度で完璧な設計をするのではなく、変化を前提として、変化しやすい形を保ち続ける。そのための道具として API を捉え直す――これが本書の核心だと理解しました。そして旅の各地点で下すべき意思決定について、本書は「答え」ではなく「問いのリスト」を渡してくれます。銀の弾丸を売らない本ですが、だからこそ手元に置いて何度も参照する価値があります。
進化的アーキテクチャという言葉に興味はあるが具体的なイメージが湧かない、という方には、まずイントロダクションと10章だけでも読んでみることをおすすめします。カンファレンスシステムが姿を変えていく様子を眺めるだけで、この本が何を教えようとしているのかが掴めるはずです。