共通基盤とは何か ─ 抽象を設計するということ

2026/05/09

共通基盤とは何か ─ 抽象を設計するということ

「共通基盤」と一言で言うと、ドメインを持たないドメインになる。これがすべての違和感の出発点だ。

共通基盤の典型例

Inside（社内向け / プラットフォーム）

種別	例	提供するもの
認証・認可	OAuth サーバー、Keycloak、Cedar	ID トークン、認可判定
API ゲートウェイ	Kong、Envoy、API Gateway	ルーティング、認証、レート制限
メッセージ基盤	Kafka、SQS、PubSub	非同期通信
ジョブ基盤	Temporal、Airflow、Cron 系	バッチ・ワークフロー
設定ストア	Consul、etcd、AWS AppConfig	フィーチャーフラグ、設定
通知	SES、Twilio、自前	Email / SMS / Push
監査	自前、Elasticsearch	変更履歴
識別子発行	Snowflake ID、ULID generator	グローバル一意 ID
課金・料金	自前、Stripe Billing	計量・請求
メトリクス・ログ	Datadog、Prometheus、Loki	観測

Outside（外部公開）

利用者が外部の開発者の場合（Stripe、Twilio、Auth0、AWS）。社内基盤と本質は同じだが、規模と SLO が桁違い。

ドメインがあるシステムとの違い

ドメインを持つアプリケーション（注文管理、人事、会計）と共通基盤の差を 4 軸で見る。

graph TB
  subgraph "ドメインを持つシステム"
    D1[Order Aggregate]
    D2[Customer Aggregate]
    D3[Invoice Aggregate]
    DB1[(Domain DB)]
    D1 --> DB1
    D2 --> DB1
    D3 --> DB1
  end

  subgraph "共通基盤"
    P[抽象 API]
    P --> User1[利用者ドメイン A]
    P --> User2[利用者ドメイン B]
    P --> User3[利用者ドメイン C]
  end

  style D1 fill:#e1f5ff
  style P fill:#ffe1e1

違い 1：抽象度

ドメインは 具体的。「Order を作成する」「Invoice を発行する」── ビジネス概念がそのまま言語になる。

共通基盤は 抽象的。「メッセージを送る」「ジョブを実行する」「ID を発行する」── ビジネス概念を持たず、メタな機能を提供する。利用者ごとに意味が変わる：

// 認証基盤の API
authService.issueToken(userId, scopes);
// ↑ "userId" が何の user かは認証基盤は知らない
//   "scopes" の意味も利用者ドメインが決める

「自分のドメインを持たない」という性質が、設計を難しくする。

違い 2：責務の置き方

ドメインの責務は明確。Aggregate の整合性、ビジネスルールの遵守。

共通基盤の責務は 利用者次第で伸び縮みする：

// 通知基盤に Email 配信を頼む
notificationService.send({
  to: '[email protected]',
  subject: 'Welcome',
  body: '...',
});

// 「失敗したら？」
// → 基盤が retry する？ 利用者が retry する？
// 「重複したら？」
// → 基盤が dedupe する？ 利用者が idempotency key を渡す？
// 「未配達ログは？」
// → 基盤が保存する？ 利用者が監視する？

すべての境界で「どちらが持つか」を決める必要がある。これが第 2-4 章の主題になる。

違い 3：非機能要件の桁

ドメインの SLO は事業要件で決まる。注文受付なら 99.9% で十分かもしれない。

共通基盤の SLO は 利用者の SLO の和 に縛られる：

利用者 A が 99.9% で動きたい
利用者 B が 99.9% で動きたい
利用者 C が 99.9% で動きたい
利用者 ... 全員が 99.9% を求める

共通基盤の SLO ≥ 99.99%（直列依存なら）

「自分が止まると 100 個のサービスが止まる」立場の SLO は、1 桁シビアになる。これが第 6-9 章の主題。

違い 4：利用者の存在

ドメインの利用者は エンドユーザー（人間）。ある程度の操作ミスは許容、UX で吸収できる。

共通基盤の利用者は 他のエンジニア / 他のサービス：

誤った使い方をされる（idempotency key を再利用、retry を入れない、timeout を設定しない）
想定しない使い方をされる（高頻度ポーリング、巨大ペイロード、無限の TTL）
deprecate しても使い続けられる（移行コストを払いたがらない）

利用者は 理性的だが時間に追われている。「使いやすさ」と「壊れにくさ」を両立させる必要がある。これが第 13 章の Golden Path / SDK の主題。

「ドメインを持たないドメイン」のパラドックス

共通基盤は ドメインを持たない が、自分自身のドメイン は持つ。

graph TB
  subgraph "利用者から見ると"
    A[共通基盤は "詳細"]
  end

  subgraph "共通基盤チーム自身から見ると"
    B[共通基盤は "ドメイン"]
  end

  A -. 同じ実体 .- B

  Note1[Robert Martin: "The Database is a Detail"<br/>は利用者視点のステートメント]

  style A fill:#e1f5ff
  style B fill:#ffe1e1

利用者から見れば「Repository の向こう側、関係ない詳細」。だが共通基盤チームから見れば、それは 自分のドメインで、Aggregate を引いて、Repository を書いて、進化させていく対象。

立場が変わると見える景色が変わる。これは前作 DB 設計の軸 2026 ch16 で扱った「Repository が DAO に堕ちる宿命」と同じ構造。

共通基盤を設計する 8 つの問い

シリーズ全体で答えていく問いを先に置く：

何を提供し、何を提供しないか（責務の境界）
抽象度をどこに置くか（薄い vs 厚い）
制御は誰が持つか（基盤主導 vs 利用者主導）
API は何年持つか（進化戦略）
SLO はどこに引くか（利用者の SLO の和）
Hot tenant は誰の責任か（マルチテナンシー）
失敗時の挙動はどう設計するか（Resilience）
そもそも作るべきか（Build or Not）

これらが第 15 章の 外さない 8 軸 に対応する。

この章の要点

共通基盤は「ドメインを持たないドメイン」── 自分のビジネス概念を持たず、利用者にメタ機能を提供する
ドメインを持つシステムとは 4 軸で本質的に違う：抽象度 / 責務 / 非機能要件 / 利用者
抽象度: 具体的 vs 抽象的（メタ機能）
責務: 明確 vs 利用者次第で伸び縮み
非機能: 自分の SLO は利用者の SLO の和
利用者: 人間 vs 他エンジニア・他サービス
立場が変わると同じ実体の見え方が変わる ── 利用者から見れば “詳細”、自分から見れば “ドメイン”

次章への問いかけ

共通基盤の本質は分かった。だが具体的な設計に入ろうとすると、最初の関門は「何を提供するか」だ。

「全部入り」を作りたくなる気持ちと、「最小限から始める」べきという理屈が衝突する。次章で Team Topologies の Thinnest Viable Platform を起点に、責務の境界を引く方法を見る。