コンテキストマッピング（こんてきすとまっぴんぐ）

2025年11月17日

コンテキストマッピング（こんてきすとまっぴんぐ）

英語表記: Context Mapping

概要

コンテキストマッピングは、ドメイン駆動設計（DDD）の核となる手法であり、大規模なソフトウェアシステムを構成する複数の「境界づけられたコンテキスト（Bounded Context）」とその相互関係を視覚的に定義・文書化するプロセスです。特に、マイクロサービスアーキテクチャにおけるサービス分割戦略を実行する際、どのビジネス領域を独立したサービスとして切り出すべきか、そしてそれらのサービス間をどのように連携させるべきかを決定するための、非常に重要な設計ツールとして機能します。このマッピング作業を通じて、各サービス（コンテキスト）が持つモデルと言語の範囲を明確にし、システム全体の整合性と複雑性の管理を容易にするのが主な目的です。

詳細解説

コンテキストマッピングは、ただの図を作成する作業ではなく、システム全体のアーキテクチャ設計、特にマイクロサービスアーキテクチャにおけるサービス分割戦略の根幹をなします。このプロセスは、ドメイン駆動設計（DDD）の活用において、現実世界に存在する複雑なビジネスドメインを、技術的な実装可能な単位に落とし込むために不可欠です。

目的：複雑性の管理とサービス境界の定義

ビジネスドメインは往々にして巨大で、一つのシステム全体で「顧客」や「商品」といった用語が常に同じ意味を持つわけではありません。例えば、ECサイトにおいて、「顧客」はマーケティング部門では「見込み客」を指し、注文処理部門では「支払能力のある購入者」を指すかもしれません。

コンテキストマッピングの最大の目的は、このような曖昧さを許容せず、用語や概念が明確に定義された領域（境界づけられたコンテキスト：BC）を特定することです。マイクロサービスアーキテクチャでは、このBCがそのまま独立したマイクロサービスの境界となります。これにより、サービス分割戦略がビジネスロジックに深く根ざした、意味のあるものになるのです。

主要な構成要素と動作原理

コンテキストマッピングは主に以下の要素とその関係性によって構成されます。

境界づけられたコンテキスト (BC): マッピングの基本単位です。これは、特定のユビキタス言語（その領域内でのみ通用する共通言語）と、それに紐づくソフトウェアモデルが定義される論理的な境界です。マイクロサービスでは、一つのBCが一つの独立したサービスに対応することが理想的です。
関係性 (Relationship): 複数のBCがどのように連携するかを示す、設計上最も重要な要素です。この関係性が、マイクロサービス間のデータ交換方法や依存度を決定します。

代表的な関係性には次のようなものがあり、これらが具体的なサービス分割と連携の戦略を決定づけます。

共有カーネル (Shared Kernel): 複数のサービスがデータベースやコードの一部を共有する関係です。分割は進んでいますが、結合度は高くなります。マイクロサービスにおいては、極力避けるべき関係ですが、現実的な移行期や密接な連携が必要な場合に限定的に使用されます。
顧客/供給者 (Customer/Supplier): 一方のサービス（供給者）が他方のサービス（顧客）に対してデータや機能を提供する関係です。顧客側が供給者側の要求（API仕様など）に影響を与えることができる場合があります。
適合者 (Conformist): 顧客側のサービスが、供給者側のサービス仕様（データ形式やAPI）に完全に合わせることを受け入れる関係です。これは、供給者側が巨大なレガシーシステムである場合など、顧客側が変更を要求できない場合に採用されます。
腐敗防止層 (Anti-Corruption Layer: ACL): 外部のコンテキスト（特にレガシーシステムや外部サービス）の複雑なモデルや言語が、自身のサービス内部に侵入してくるのを防ぐための「翻訳層」を間に挟む関係です。これは、マイクロサービスが独立性を保つために非常に重要な戦略です。

コンテキストマッピングを行うことで、設計者はこれらの関係性を図示し、どのサービスが誰に依存し、どのような統合パターン（例：REST API、メッセージキュー、ACL）を採用すべきかを一目で判断できるようになるのです。これは、ドメイン駆動設計の活用が、単なる技術選定ではなく、ビジネス言語に基づいたアーキテクチャ設計であることを示しています。

具体例・活用シーン

コンテキストマッピングは、特に大規模な組織がレガシーシステムをマイクロサービスアーキテクチャに移行する際や、複数のチームが並行して開発を進める際に真価を発揮します。

活用シーン：大規模ECサイトの再構築

ある大規模ECサイトを例にとりましょう。このサイトには「在庫管理」「注文処理」「顧客管理」「マーケティング」の4つの主要なビジネスドメインが存在するとします。

境界の特定: まず、それぞれのドメインを境界づけられたコンテキスト（BC）として特定します。
- BC A: 注文処理サービス
- BC B: 在庫管理サービス
- BC C: 顧客管理サービス
- BC D: マーケティングサービス
言語の定義: 各BC内で使われる「ユビキタス言語」を定義します。
- 注文処理サービスでは「Item」は「発注された商品ライン」を意味します。
- 在庫管理サービスでは「Item」は「倉庫内のSKU（在庫管理単位）」を意味します。
関係性のマッピング: 連携が必要な箇所に関係性を定義します。
- 注文処理サービス（顧客）は、在庫管理サービス（供給者）に依存します。注文時に在庫確認が必要です。この関係は「顧客/供給者」として定義され、在庫管理サービスは注文処理サービスからの要求を考慮してAPIを設計します。
- 注文処理サービスは、レガシーな決済システム（外部BC）と連携する必要があります。このレガシーシステムのデータ構造は複雑で変更できません。そこで、注文処理サービスは決済システムとの間に「腐敗防止層（ACL）」を設けます。これにより、レガシーな用語やデータ形式が、モダンに設計された注文処理サービス内部に影響を与えるのを防ぐのです。

アナロジー：都市計画の地図

コンテキストマッピングを理解するための最もわかりやすいメタファーは、「都市計画の地図」です。

システム全体を一つの巨大な都市だと想像してください。この都市には、金融街、住宅地、工業地帯など、機能が明確に分かれた「区画（境界づけられたコンテキスト）」が存在します。

BC（区画）: 各区画は独自のルール（ユビキタス言語）と建築基準（ソフトウェアモデル）を持っています。金融街では「ドル」が中心ですが、住宅地では「家族」や「学区」が中心概念となります。
コンテキストマッピング（地図）: この地図は、各区画の境界線がどこにあるのか、そして区画同士がどのように繋がっているのか（道路、高速道路、地下鉄）を示します。
腐敗防止層（税関・翻訳センター）: もし、ある区画（モダンなマイクロサービス）が、隣の古い区画（レガシーシステム）から物資を受け取る必要がある場合、そのまま古い区画のルールで物資を受け入れると混乱が生じます。そこで、区画の境目に「税関や翻訳センター」を設けます。これが腐敗防止層（ACL）です。このセンターで、古い区画の複雑なフォーマットを、モダンな区画で理解できるシンプルなフォーマットに変換するのです。

もしこの地図（コンテキストマッピング）がなければ、開発者は区画の境界を無視して無秩序に建物を建ててしまい、結果としてどこに何があるかわからない「分散した巨大なスラム街（分散モノリス）」が誕生してしまいます。コンテキストマッピングは、健全なサービス分割戦略を実行するために、都市計画段階で必須となる設計図なのです。

資格試験向けチェックポイント

コンテキストマッピングは、応用情報技術者試験や高度試験（特にシステムアーキテクト試験）において、ドメイン駆動設計（DDD）を活用したサービス分割の具体的な手法として出題される可能性があります。

ITパスポート/基本情報技術者試験レベル:
- ドメイン駆動設計（DDD）の主要な構成要素の一つであることを理解しておく必要があります。
- システムの複雑性を管理し、ビジネスドメインに基づいてソフトウェアの境界を定める手法である、という基本的な定義を把握しておきましょう。
- 「境界づけられたコンテキスト（Bounded Context）」とセットで問われることが多いです。
応用情報技術者/高度試験レベル:
- コンテキストマッピングが、マイクロサービスアーキテクチャにおける「サービス分割戦略」を具現化するツールであることを理解してください。
- 単に境界線を引くだけでなく、境界間の「関係性」を定義することが重要であることを確認しましょう。特に、以下の関係性の名称と役割を区別できるようにしておく必要があります。
  - 腐敗防止層（ACL）の役割：レガシーシステムや外部ドメインとの統合において、自身のコアモデルを守るための「翻訳」や「緩衝材」として機能すること。
  - 共有カーネル：密結合のリスクがあるが、特定の状況下で選択される統合パターンであること。
- コンテキストマッピングの結果が、具体的なマイクロサービスのAPI仕様や統合技術（同期通信か非同期通信かなど）の選択に直結することを理解することが重要です。