疎結合とは？密結合との違い・メリットとデメリットを結合度の段階とコード例で解説

疎結合（そけつごう、英語は loose coupling）とは、システムの部品どうしが決められたインターフェース越しにしか関わらず、公開インターフェースの互換性を保つ限り、片方の内部変更がもう片方に及ぼす影響を小さくできる状態のことです。対義語は密結合（tight coupling）で、部品が互いの内部構造に依存しているため、1か所の変更や障害がほかへ波及しやすくなります。この記事では、密結合との違いを一次情報の定義で押さえたうえで、プログラムの部品単位で見る「モジュール結合度」の段階、Pythonで動かした密結合と疎結合のコード、システム間を分ける手段、そしてメリットとデメリット、分けないほうが安く済む条件までを説明します。

まとめ：疎結合の要点と、分離を選ぶ条件

疎結合は「公開されたインターフェースだけを知っていれば相手を使える」状態で、密結合との差は変更の波及範囲と障害の広がり方に現れます。プログラムの中では、部品が具体的なクラスを自分で生成せず、約束（インターフェース）を満たす相手を外から受け取る形にすると疎結合になります。システムの間では、API・キュー・イベントで切り離します。

効果は無条件では出ません。Google Cloudが2025年9月に発表した2025 DORA Reportは、疎結合なアーキテクチャと速いフィードバックループを持つチームはAI導入の成果を上げる一方、密結合なシステムと遅いプロセスに制約されたチームはほとんどメリットを得られないと報告しています。分けたうえで、独立してテスト・デプロイできることが効果の条件です。

システムを分けるかどうかは、複数のチームが並行して開発する、画面と業務ロジックの改修サイクルが明確に違う、片方だけ負荷が突出する、の3点で判断します。該当数だけで決めず、独立した改修や増強による利益と、通信・運用の追加コストを比較します。小規模システムでは、一体構成のまま内部の依存を整理する案も比較対象にします。

疎結合の意味と、密結合との違い

疎結合の定義：公開インターフェースだけに依存する状態

IT用語辞典e-Wordsは疎結合を、各要素が「あらかじめ決められた最小限の約束事（インターフェース）のみを通じてやり取りを行い、互いの内部構造を深く知る必要はない」状態と説明しています（2026年4月23日更新）。英語の形容詞形は loosely coupled です。

効いているのは「内部構造を知らなくてよい」という一点です。呼び出す側が相手のテーブル構造や内部の関数名を前提にしていると、相手の都合で自分が壊れます。公開された入出力の形式と、その意味や失敗時の振る舞いを含む約束が保たれていれば、相手が内部を書き換えても影響は小さく抑えられます。AWS Well-Architectedのベストプラクティス REL04-BP02「疎結合の依存関係を実装する」も、疎結合では「依存コンポーネントが知る必要があるのは、バージョン管理されて公開されたインターフェイスのみです」と書いています。

密結合との違い：変更範囲と障害の波及

e-Wordsの密結合の項は、密結合な構成は「要素間の通信や連携のために必要な手間（オーバーヘッド）が小さいため、処理性能を高めやすくリソース効率の面で有利に働く」としています。同一プロセス内の呼び出しをネットワーク通信に置き換える場合には通信コストが増えますが、結合度だけで速度や費用の優劣は決まりません。差が出るのは、変更するときと壊れたときです。

変更時の差は修正範囲に現れます。密結合では、在庫テーブルの列名を1つ変えるだけで、そのテーブルを直接読んでいる受注画面・帳票出力・バッチを同時に直し、同時にリリースしなければなりません。在庫参照APIを挟んでいれば、API側が応答形式を保つ限り呼び出し側は無改修です。障害時の差は影響範囲です。推薦機能の応答を待つ設計では、その遅延が商品一覧の表示を止めます。推薦結果を事前生成して保存し、取得できなければ推薦枠を省く設計なら、一覧表示を継続できます。AWSの同じページは、疎結合によって「あるコンポーネントの障害が別のコンポーネントに影響を及ぼさないように隔離することができます」としています。

通信負荷や監視対象の増加は、結合度そのものより、主に別サービスへ分割した場合のコストです。後半の「デメリット」の章で扱います。

デカップリングの分野別の意味と、要件定義での表記

デカップリング（decoupling）は依存を切り離す行為を指し、その結果の構成をデカップルド構成と呼びます。疎結合は、依存を小さくした状態を表す言葉です。「ディカップルド」「デカップルド」は decoupled の表記ゆれです。ただし日本語で「デカップリングとは」を検索すると、上位には証券会社の用語集の「経済分断」、環境分野の経済成長と資源消費の切り離し、生産管理の「デカップリングポイント」が並びます。要件定義書やRFPでは「疎結合」または「フロントエンドとバックエンドの分離」と日本語で書くほうが、読み手の専門分野による解釈の割れを防げます。

モジュール結合度で見る疎結合の段階

プログラムの部品（モジュール）どうしの結びつきの強さは「モジュール結合度」として段階に分けられています。e-Wordsのモジュール結合度の項は、強い順に内容結合・共通結合・外部結合・制御結合・スタンプ結合・データ結合の6段階を挙げ、その下にメッセージ結合と無結合を置く場合もあるとしています。「疎結合」は、この段階の弱い側に寄せた状態を指す総称です。

この段階は基本情報技術者試験の定番です。e-Wordsがまとめた出題履歴には、「モジュール間の情報の受渡しがパラメタだけで行われる，結合度が最も弱いモジュール結合はどれか」という問いが平成30年秋期から令和7年までに5回並びます。答えはデータ結合です。

実務で疎結合を崩しやすいのは、段階の真ん中にある制御結合とスタンプ結合です。「modeが1なら印刷、2なら保存」という引数を受け取る関数は、呼び出し側が相手の内部の分岐を知っていることになり、分岐の番号や意味を変えると呼び出し側も直す必要が出ます。こうした関数は、印刷と保存を別の関数に分けるのが定石です。スタンプ結合は、顧客オブジェクトを丸ごと渡した結果、使っていない項目の型変更まで呼び出し先の再テスト対象になる形で問題になります。渡すのは必要な値だけに絞ります。

コードで見る密結合と疎結合（Python）

部品の内部で相手を具体的に生成しているか、外から受け取っているか。この差が、変更とテストのしやすさを分けます。ここでは注文を受け付けて通知メールを送る処理を例に、Python 3.9.6と3.14.6で実行した結果を載せます。

具体クラスを自分で生成する密結合の形

OrderServiceが送信の実装であるSmtpMailerを自分で生成しています。この例のSmtpMailerは接続失敗を模して常に例外を送出するため、SMTPサーバーの有無にかかわらずplaceは失敗します。内部で生成する依存先もunittest.mock.patchでテスト用に差し替えられますが、生成箇所を知る必要があります。実装を外から渡す設計なら、差し替え箇所を明示できます。

class SmtpMailer:
    def send(self, to: str, body: str) -> None:
        raise ConnectionError("SMTPサーバーに接続できません")

class OrderService:
    def __init__(self) -> None:
        self.mailer = SmtpMailer()  # 具体クラスを自分で生成している

    def place(self, order_id: str, email: str) -> str:
        self.mailer.send(email, f"注文{order_id}を受け付けました")
        return "accepted"

print(OrderService().place("A-001", "[email protected]"))

$ python3 tight.py
ConnectionError: SMTPサーバーに接続できません

Protocolで約束だけを受け取る疎結合の形

疎結合にするには、OrderServiceが知る範囲を「sendというメソッドを持つもの」まで狭め、相手は外から渡します。Pythonでは typing.Protocol（PEP 544、Python 3.8で追加）でこの約束を型として書けます。依存する相手を外から渡す書き方を、依存性の注入（DI）と呼びます。

from typing import Protocol

class Notifier(Protocol):
    def send(self, to: str, body: str) -> None: ...

class OrderService:
    def __init__(self, notifier: Notifier) -> None:
        self.notifier = notifier  # 「send を持つもの」だけを前提にする

    def place(self, order_id: str, email: str) -> str:
        self.notifier.send(email, f"注文{order_id}を受け付けました")
        return "accepted"

class FakeNotifier:
    def __init__(self) -> None:
        self.sent: list[tuple[str, str]] = []

    def send(self, to: str, body: str) -> None:
        self.sent.append((to, body))

fake = FakeNotifier()
print(OrderService(fake).place("A-001", "[email protected]"))
print(fake.sent)

$ python3 loose.py
accepted
[('[email protected]', '注文A-001を受け付けました')]

FakeNotifierはNotifierを継承していませんが、sendの引数名・引数型・戻り値型がNotifierの定義と互換なので、型チェッカー上で約束を満たします。メールサーバーなしで受付処理をテストでき、送った内容も fake.sent で確かめられます。テスト用の代役の作り分けはテストダブル（TestDouble）とは｜5分類の違いと使い分けで整理しています。本番でも同じ送信契約を満たす実装ならOrderServiceを変えずに渡せます。ただし、sendは同期呼び出しのままなので、送信失敗でplaceも失敗します。注文受付を継続させるには別途、通知の非同期化などが必要です。

mypyによるProtocolの型不一致の検出

Protocolは実行時には検査されません。sendではなくpostを持つSlackNotifierを渡すと、生成の時点では何も起きず、placeを呼んだ瞬間に AttributeError で落ちます。約束違反を事前に見つけるのは型チェッカーの役目で、mypy 2.4.0では次のように検出されました。bad.pyの中身は次のとおりです。

from loose import OrderService

class SlackNotifier:
    def post(self, channel: str, text: str) -> None:  # send ではなく post
        print(channel, text)

OrderService(SlackNotifier())

mypyはコードを実行せずに検査します。なお bad.py を python3 で実行すると、import した loose.py 末尾のデモ出力が表示されますが、SlackNotifierでの送信が成功したわけではありません。

$ uvx mypy==2.4.0 loose.py bad.py
bad.py:7: error: Argument 1 to "OrderService" has incompatible type "SlackNotifier"; expected "Notifier"  [arg-type]
Found 1 error in 1 file (checked 2 source files)

Protocolで疎結合にするなら、CIで型チェックを回すところまでをセットにしてください。型チェックを省くと、Protocolとの型不一致を静的に検出する機会を失います。型チェックに加え、送信内容や失敗時の動作はテストで確認します。

システム間を疎結合にする手段：API・キュー・イベント

サービスやシステムの間を疎結合にする代表的な手段を比較します。キューとイベント駆動は併用できます。AWSのREL04-BP02も、疎結合な依存関係の例としてキューイングシステム、ストリーミングシステム、ワークフロー、ロードバランサーを挙げています。

同期APIは結果をその場で使えますが、相手が遅ければ自分も遅くなります。キューは送信に成功したメッセージを保持期間のあいだ残すため、受け手が一時的に止まっても送り手は処理を続けられます。ただし滞留が保持期間や受け手の処理能力を超えないよう、滞留量の監視と流入の抑制が要ります（キューの設計はAmazon SQSとは？FIFOキューと標準キューの違い・重複排除・可視性タイムアウトとDLQの設計【2026年10月】で扱っています）。イベント駆動は「受注が確定した」という事実だけを発行し、後から受け手を足しても発行側は変わりません。その代わり処理の流れが1か所のコードでは追えなくなるので、分散トレーシングなどの追跡手段を先に用意します。実装パターンはイベント駆動アーキテクチャとは？仕組み・実装パターンと採用判断を実装者目線で解説が詳しく扱っています。

フロントエンドとバックエンドの分離とヘッドレス

Webシステムでよく見る疎結合は、画面側と業務処理側をAPIで分ける構成です。サーバーはJSONなどのデータだけを返し、画面の組み立てはブラウザ上のJavaScriptや別のレンダリングサーバーが担います。画面の文言変更はバックエンドを触らずに、在庫計算の修正は画面を再ビルドせずに反映できます。両側の担当範囲はフロントエンドとバックエンドの違いとは？役割・言語・連携と開発発注時の体制設計を解説で整理しています。

「ヘッドレス」は、疎結合のうち表示機能（head）を持たない製品構成を指す狭い呼び名です。製品の比較はヘッドレスCMSとは？従来型との違い・料金比較とプレビュー実装【2026年10月】が対応します。

疎結合のメリットと、効果が出る前提条件

他チームの都合から切り離されたリリースと、部分単位の増強

疎結合のメリットは、どれも「独立して動かせること」から生まれます。サービス単位で分けたときに大きいのは、リリースを他チームの都合から切り離せることです。DORAは疎結合なチームの条件として「Teams deploy and release their product or service on demand, independently of the services it depends on or of other services that depend on it.」（自分が依存するサービスにも、自分に依存するサービスにも縛られず、必要なときにデプロイ・リリースできる）を挙げています。合同リリースの日程調整に使っていた時間が、そのまま消えます。

もう1つは、負荷の高い部分だけを増強できることです。画面配信と業務処理が同じサーバー上にあると、アクセスが集中したときにサーバー全体を増やすしかありません。分けていれば逼迫している側だけを増やせます。

サービス分離の効果を支える独立したテストとデプロイ

2025 DORA Reportの発表記事（2025年9月公開、約5,000人の技術者の回答に基づく）は、強力な自動テストや迅速なフィードバックループといった制御の仕組みがないと変更量の増加は不安定につながるとし、「フィードバック ループが高速な疎結合アーキテクチャで作業するチームは成果を上げますが、密結合システムと遅いプロセスに制約されるチームはほとんど、またはまったくメリットがありません」と書いています。

読み取るべきは、分離は効果の十分条件ではないということです。分けてもテストが共有の統合環境でしか回せない、リリースに他チームの承認が要る、という状態では、独立したテストやリリースによる効果は得られにくくなります。分離と同時に、独立したテスト実行とデプロイの権限を設計に含めてください。

疎結合のデメリット：通信の失敗・整合性・運用対象の増加

e-Wordsは疎結合について「要素間の連携に仲介の仕組みが必要となるため、通信コストや処理の負荷が増す場合もある」と記しています。プログラム内部の疎結合で増えるのは、インターフェースの定義と、呼び出し先の実装を追う手間です。部品を別のプロセスやサービスに分けると、次のデメリットが加わります。

• 通信の失敗が増える：関数呼び出しがネットワーク越しの通信に変わると、タイムアウト・接続断・部分的な失敗という新しい失敗が生まれます。リトライ、時間制限、相手が落ちているときの代替表示は、分けなければ要らなかったコードです。
• データの整合性を自前で設計する：1つのデータベースのトランザクションで済んでいた更新が複数サービスにまたがると、途中で失敗したときの打ち消し処理を自分で作ることになります。
• 結合テストの手間が増える：境界をまたぐ動作を確かめるには、相手の応答を模した代役を作り、相手の仕様変更に合わせて保守し続ける必要があります。
• 運用の対象が増える：監視対象、ログの集約先、デプロイパイプライン、証明書やAPIキーの更新対象が、分けた数だけ増えます。障害調査も複数サービスをまたぐ追跡に変わります。

なかでも見積から漏れやすいのは運用の増分です。分けると決めた時点で、増えた監視とデプロイを誰が担うかまで決めておかないと、リリース後に運用チームが詰まります。

別サービスへの分割を避ける条件と、境界設計の失敗パターン

次の条件に当てはまるなら、別サービスに分けない判断のほうが合理的です。プログラム内部のモジュール分割は、この場合も有効です。

1つ目は、開発と運用を担うチームが1つしかない場合です。単一チームでも疎結合は変更範囲の限定やテストの容易化に役立ちます。ただし、独立した拡張や配備が不要なら、別サービスへの分割による追加コストを回収しにくくなります。Martin Fowlerは2015年5月13日の「MicroservicePremium」で「don’t even consider microservices unless you have a system that’s too complex to manage as a monolith」（モノリスとして管理するには複雑すぎるシステムでない限り、マイクロサービスは検討すらするな）と書いています。

2つ目は、複数のデータを1つの取引としてまとめて更新する処理が業務の中心にある場合です。受注確定・在庫引当・与信枠の更新が必ず同時に成立しなければならない業務では、分けた瞬間に整合性の設計コストが跳ね上がります。この領域は1つのサービスに収めるのが定石です。

3つ目は、新規開発の初期で業務の境界がまだ固まっていない場合です。Fowlerは2015年6月3日の「MonolithFirst」で「Almost all the successful microservice stories have started with a monolith that got too big and was broken up」（成功したマイクロサービスの事例はほぼすべて、大きくなりすぎたモノリスを分割したところから始まっている）と述べています。境界を誤ったまま分けると、機能追加のたびに複数サービスを同時に直すことになり、密結合の面倒さと分散のコストを両方背負います。

失敗の典型はこの3つ目です。APIで分かれているのに、片方を変えるたびにもう片方も直している状態は、分離できていません。リリース履歴から、技術的な依存のために同時配備が必要だった変更を調べます。同じ理由が繰り返されるなら境界の見直しを検討し、営業上の都合で同日に公開した場合とは区別します。段階的に分ける中間解はマイクロサービスとは？モノリスとの違い・メリット・デメリットと選び方、モジュラモノリスまで整理で扱っています。

外注・見積で境界を決めるときの確認項目

開発を外部に依頼する場合、疎結合にするかどうかで見積の構造が変わります。発注前に次の4点を確認してください。

1. どこで分けるのか。「画面とサーバー」か「業務領域ごと」かで、要員数と期間が変わります
2. インターフェースの仕様を誰がいつ確定するのか。ここが遅れると両側の開発が同時に止まります
3. 分けることで増える作業（API認証、CORS設定、2系統のデプロイ、監視設定）が見積に入っているか
4. リリース後、どちらの側をどの頻度で改修する想定か

効くのは2番目と4番目です。仕様が固まらないまま画面側とサーバー側を並行着手すると、互いの完成を待つ状態になり、分けたはずが工程上は密結合になります。仮の応答データで画面側を先行できる体制かを契約前に確かめてください。4番目では改修頻度だけでなく、片方の変更が他方の修正や配備を必要とするかを確認します。同じ頻度でも独立して変更できるなら、分離の利点は残ります。API境界の設計から相談したい場合は、一創のAPI開発・システム連携で既存システムとの接続方式を含めて検討できます。

よくある質問

疎結合の読み方と英語表記は？

読み方は「そけつごう」です。英語は loose coupling、形容詞形は loosely coupled です。対義語の密結合は「みつけつごう」と読み、英語は tight coupling です。日本語の言い換えには「疎な結合」「ゆるやかな結合」「分離」「切り離し」があります。

疎結合と密結合はどちらが優れていますか？

優劣は固定されていません。単一チームで運用する小規模システムや、複数データの一括更新が中心の業務では、単一アプリケーションと単一データベースに収めると分散処理の追加コストを避けられます。その内部は疎結合に設計できます。一方でe-Wordsは、高い処理効率やリアルタイム性が求められるシステムでは、あえて密結合な構成が採用されることも少なくないと記しています。別サービスへの分割は通信の失敗処理や監視対象の増加という代償を伴うため、効果が出る条件を満たさないまま採用するとコストだけが残ります。

疎結合にするにはマイクロサービスにする必要がありますか？

必要ありません。マイクロサービスは疎結合を実現する手段の1つで、1つのアプリケーションの内部でモジュール間の依存をインターフェース経由に限る「モジュラモノリス」でも、メリットの多くは得られます。本文のPythonの例も、1つのプログラムの中での疎結合です。デプロイ単位が1つのままなので、ネットワーク越しの通信や分散トランザクションの問題は起きません。まずモジュール分割で境界を試し、境界が安定してからサービスとして切り出すのが失敗の少ない順序です。

デプロイとリリースの違いは何ですか？

デプロイは新しいコードを本番環境に配置すること、リリースはその機能を利用者に使える状態にすることです。両者を分けておけば、コードは配置済みのまま機能を止めておき、宣伝の開始日に合わせて公開する、といった運用ができます。Pete HodgsonはMartin Fowlerのサイトに載せたFeature Togglesで、機能フラグによるこの使い方を、継続的デリバリーの原則「separating [feature] release from [code] deployment」を実装する最も一般的な方法としています。疎結合なチームが「独立してデプロイ・リリースできる」状態の実装手段の1つです。フラグの種類と運用はフィーチャートグル（機能フラグ）とは？4種類の使い分けと実装例・削除までの運用で扱っています。

疎結合マルチプロセッサとは何ですか？

ソフトウェア設計ではなく、ハードウェア構成の用語です。e-Wordsは、1台の機器に複数のCPUを搭載し、それぞれがメモリやOSを持って独立して動作する構成を疎結合マルチプロセッサと呼ぶことがあるとしています。対する密結合マルチプロセッサは、複数のプロセッサが主記憶を共有し、単一のOSのもとで連携して動きます。プロセッサ間のデータ交換は速い反面、1つのプロセッサの障害が全体に波及するリスクを伴います。

関連記事

• システムアーキテクチャとは？意味と代表5方式の違い・選び方をわかりやすく解説
• マイクロサービスとは？モノリスとの違い・メリット・デメリットと選び方、モジュラモノリスまで整理
• フロントエンドとバックエンドの違いとは？役割・言語・連携と開発発注時の体制設計を解説
• テストダブル（TestDouble）とは｜5分類の違いと使い分け