> ## Documentation Index
> Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt
> Use this file to discover all available pages before exploring further.
# オープン・クローズド原則
> オープン・クローズド原則は、動いている部分を書き換えず、新しい振る舞いは横に足す設計規則です。メイヤーの起源、WordPress のプラグイン、限界を整理します。
**カテゴリ**: 原則
**種類**: システム設計原則
**起源**: バートランド・メイヤー、『Object-Oriented Software Construction』、Prentice Hall、1988年
**別名**: OCP、開放閉鎖原則、Open/Closed Principle
**先に答えると** — **オープン・クローズド原則**（Open-Closed Principle）は、すでに動いているモジュールはそのまま使える状態を保ち、新しい振る舞いは中を削らず横に足す、という設計規則です。バートランド・メイヤーは1988年にこの考えに名を付け、ロバート・C・マーティンはのちに「拡張に開き、修正に閉じる」と言い直しました。実務の検査は単純です。新しい事例は新しい部品として着地すべきで、すでに動いているファイルへの追記であってはなりません。
## オープン・クローズド原則とは？
オープン・クローズド原則は、ソフトウェアの実体——あるいは同じ形をしたどんな仕組みでも——既存の利用者がすでに依存している部分を書き換えることなく、拡張によって新しい振る舞いを受け入れる、という設計規則です。
> モジュールは、まだ拡張に使えるなら開いていると言われる。……他のモジュールがそれを使えるなら、閉じていると言われる。
日常の絵は壁のコンセントです。ランプを買うたびに家の配線をやり直したりはしません。コンセントは閉じている。形が、他人が信頼できる契約だからです。コンセントは同時に開いている。ケトルも充電器もラジオも、壁を変えずに差し込めるからです。
コードでは、その蝶番はインターフェイス、フック、プラグインの差し込み口です。新しい税、支払い方法、学生の種類が来るたびに開き直す長い `if` の列は、逆の形です。[単一責任の原則](/ja/principles/single-responsibility) は、変わる理由を一つに切り分ける助けになります。オープン・クローズド原則は、その理由を安定した扉の向こうに置き、昨日の利用者が引っ越さなくて済むように、と求めます。
メイヤーの1988年版は継承に寄りました。コンパイル済みのクラスは利用者に対して閉じ、子孫が機能を足します。1990年代、マーティンらは同じ蝶番を抽象インターフェイスとプラグインに書き直します。家系の名前は残りました。仕組みは「古いモジュールをサブクラスする」から「契約に依存し、新しい実装を足す」へ移りました。
### オープン・クローズド原則を3つの深さで理解する
* **入門**: 新しい事例が来たら、古いものを直す前に、部品を足せないか問う。ランプを増やすたびに壁を開けるなら、コンセントは最初から設計されていません。
* **実務**: 今四半期に本当に予想する変異——支払いの種類、帳票の形式、部活の種類——を名指しし、その周りに安定したインターフェイスを置く。新しい事例は新しいハンドラとして足す。名指しできない未来のための差し込み口は作らない。その争いは [YAGNI](/ja/principles/yagni-principle) の側です。
* **上級**: モジュールを閉じられるのは、*予測した*変異に対してだけです。蝶番を誤ると、変更のたびに寄り道しなければならない空の枠組みになります。蝶番を一つも置かないと、変更は散弾銃のような手術になります。原則は、次の違いがどこに着地するかについての賭けであり、ファイルに二度と触らない誓いではありません。
## 起源
オープン・クローズド原則は、チームの壁の標語としてではなく、モジュール化の難題として始まりました。
当時 Eiffel の言語と方法を組み立てていた **バートランド・メイヤー** は、**Prentice Hall** が **1988年** に刊行した *Object-Oriented Software Construction* でこれを述べます。初版の23ページで、「満足できるモジュール分解」は、開いてもいて閉じていてもいるモジュールを生み出さねばならない、と要求しました。開いているとは、まだフィールドや機能を足せること。閉じているとは、他のモジュールが安定したインターフェイスから使えること——コンパイルされ、ライブラリに格納され、ベースラインとして公開されること。当時の技術的な答えは継承でした。クラスは利用者に対して凍結でき、子孫が元を乱さずに拡張できます。
人々が引用する短い一行は、メイヤーの文言ではありません。**1996年1月** の *C++ Report* で、**ロバート・C・マーティン** は彼を言い換えています。ソフトウェアの実体は「拡張に開き、修正に閉じるべき」である、と。この記事は、2000年の “Design Principles and Design Patterns”、そして **2003年** Prentice Hall の *Agile Software Development: Principles, Patterns, and Practices* に再利用されます。蝶番は実装の継承から抽象インターフェイスへ移りました。新しい振る舞いは、契約を満たす新しいクラスです。古いソースは触れません。
下には、より古い考えが二つあります。**1972年12月**、**David Parnas** は *Communications of the ACM*（第**15**巻第12号: 1053–1058）で、変わりやすい設計上の決定を隠すようにシステムを分解せよ、と論じました。情報隠蔽であり、データを包むことだけではありません。**1996年**、**Alistair Cockburn** は *Protected Variations* を述べます。予測した変異を特定し、安定したインターフェイスを周りに置く。**Craig Larman** は *IEEE Software* **18**(3): 89–91（**2001年5/6月**）で、オープン・クローズド、Protected Variations、Parnas の隠蔽を、名前の違う同一の原則として扱いました。
**2004年** 前後、**Michael Feathers** はマーティンの「最初の五原則」を SOLID の頭字語に並べます。オープン・クローズド原則はその「O」です。包装が名前を有名にしました。仕組みは凍結しませんでした。**2014年5月12日**、マーティンは、Eclipse、Vim、Minecraft のようなプラグインシステムこそ原則の「究極の完成」だと書きます。コアはプラグインを指さず、プラグインがコアを指す。
> ソフトウェアの実体（クラス、モジュール、関数など）は、拡張に開き、修正に閉じるべきである。
## 要点
オープン・クローズド原則が本領を発揮するのは、次の違いが来そうで、しかも来る前にその*種類*を名指しできるときです。編集の禁止ではありません。編集がどこに着地すべきか、という規則です。
モジュールが閉じているとは、他人が、あなたが書き直す様子を見守らずに使える、ということです。公開された形——インターフェイス、帳票、コンセント——が十分に静止していれば、彼らの仕事は崩れません。新しい依頼のたびに同じ関数を開き直すなら、利用者は契約ではなく、あなたの私的な決定に結合しています。閉鎖は*彼ら*のためであり、作者のトロフィーではありません。
拡張とは、コード、プラグイン、ハンドラ、サブクラスを足すことであり、昨日の論理に枝を一本差し込むことではありません。新しいアダプタを落として支払い方法を足す店は、開いています。カードブランドのたびに会計ファイルを開き直す店は、開いていません。古い部品が動き続けるのは、削っていないからです。
未知に対して閉じることはできません。閉じるのは、名指しできる違いです。図形の描き方、税の計算、部活の運営。そこに安定した扉を置きます。[関心の分離](/ja/principles/separation-of-concerns) は、どの決定を離しておくかを教えます。オープン・クローズド原則は、そのうちどれを*差し込み可能*にすべきかを教えます。変異を名指しできなければ、待つ。早すぎる蝶番は、[YAGNI](/ja/principles/yagni-principle) が破られる仕方です。
修正に閉じることは、バグもセキュリティホールも誤った抽象も直さない誓いではありません。利用者向けの*振る舞い*を変えてはならないモジュールでも、修正は受け取れます。契約そのものが間違っていれば、契約を変え、代価を払います。設計が腐っているのにファイルを神聖視するのは、カーゴ・カルトであり、原則ではありません。
## 応用場面
似た事例の一族が増え続け、しかも古い事例は動き続けてほしいときに、オープン・クローズド原則を使います。まだ理解していない設計を凍結するためには使いません。
新しい宿題のたびに400行の採点スクリプトを直す助手は、壁を開き直しています。共有の契約——入力、ルーブリック、出力——を名指しし、各課題を小さなハンドラにします。古いスクリプトは閉じたまま。新しい週は新しいファイルです。[KISS](/ja/principles/kiss-principle) はなお有効です。契約は短く。
会計、給与、税のエンジンは、新しい方法のたびに `if` を足すと腐ります。アダプタのインターフェイスを一つ公開する。Apple Pay、地域の付加価値税、学生割引は新しい実装として足す。新しい部品だけを試す。古い枝に触ったからといって、レジ全体を再試験しない。
学校や地域の集まりは、ロボット部や合唱団が出るたびに会則を書き直しがちです。*部のルール*——誰が始められるか、金の報告、いつ集まるか——を書き、部の一覧は付録に残します。会則は閉じ、所属は開く。家事当番表も同じ形です。枠の形は固定し、名前は入れ替えます。
確定申告、助成金、建築確認は、うまくいっているときすでにこうなっています。短い本体と、特例の別表。新しい別表を足しても、1ページ目を書き直すべきではありません。例外のたびに冊子全体を改版するなら、市民も窓口も、欠けた蝶番の代を払っています。
## 事例
オープン・クローズド原則を運用上の選択として見る、数字のある窓は **WordPress** とそのプラグインアーキテクチャです。ブログソフトがメイヤー通りの完成品になった、という主張ではありません。
2004年より前、人々は WordPress と祖先の **b2** を「ハック」で伸ばしていました。説明書は *このコアファイルを編集し、この塊を貼れ* と書いてあります。アップグレードは貼り付けを上書きします。カスタム作業と製品が喧嘩します。**2004年5月22日**、**Matt Mullenweg** は WordPress **1.2**、「Mingus」を発表します。機能の一つが「新しいプラグインアーキテクチャ」で、プラグインは「WordPress が行うほぼすべての動作にフックできる」。フック——アクションとフィルタ——が拡張点です。新しい振る舞いは `wp-content/plugins/` に住み、アップグレードが置き換えるファイルには住みません。
設計は、機能の持ち主も変えました。プラグイン機構をプロジェクトに押し進めた **Ryan Boren** は、のちにコアチームの経験則をこう述べます。機能が利用者のおよそ8割に役に立たないなら、プラグインで試せ、と。1.2 に同梱された最初の例が **Hello Dolly** です。歌詞を出す小さなプラグインで、コアの中ではなく横に座ります。名前こそありませんが、仕組みはオープン・クローズド原則です。コアが契約を出す。新しい振る舞いは新しい部品。フック自体が安定していれば、旧サイトはアップグレードしてもプラグインを保てます。
後年の規模は公開されています。ただしディレクトリの件数であり、品質監査ではありません。**2026年8月** 時点で、WordPress.org のプラグインディレクトリは「**71,000** を超える無料プラグイン」と謳っていました。この数字は、差し込み口がどれほど広くなったかを測ります。すべてのプラグインが安全だとも、コア自身が決して変わらないとも証明しません。境界の注記: WordPress は今も、バグ、セキュリティ、新しい編集機能のためにコアを直します。フックが動くと、多くのプラグインはメジャーリリースで壊れます。コアを編集させるプラグインは、新しいフォルダに入った古いハックです。事例が見せるのは蝶番——安定したフック、新しいファイル——であり、71,000 の追加機能の生態系が自動的に良く設計されているという主張ではありません。
## 限界と失敗パターン
変異をまだ名指しできないとき、オープン・クローズド原則は失敗します。来ない未来のための「柔軟な枠組み」は、典型的な閉じすぎです。空のコンセントは多く、本物のランプは一つ、家は誰も配線し直せない。だから原則は [YAGNI](/ja/principles/yagni-principle) と [反復と改善](/ja/principles/iterate-and-improve) の隣に置く必要があります。蝶番を閉じるのは、似た事例が二つ三つ来たあとであり、最初の前ではありません。
改訂と再認証が必須の成果物でも失敗します。医療機器、航空機の手順、裁判所がすでに解釈した法定帳票は、非公式のプラグインでは育ちません。そこでの「閉じ」は規制であり、拡張は新しい承認版を通らねばなりません。禁じられたフォークを「拡張に開いている」と呼ぶのは、カテゴリーの誤りです。
よくある誤用は、継承を反射にすることです。メイヤーの1988年の答えはサブクラスでした。マーティンの後の答えはプラグインと抽象インターフェイスです。誤った親を共有する深い木は、オープン・クローズド設計ではありません。あとで開き直す階層です。もう一つの誤用は、[DRY](/ja/principles/dry-principle) を「一行も複製せず、常に戦略オブジェクトを足せ」と読むことです。5行の事例の重複は、早すぎる蝶番より安いことがあります。
## よくある誤解
英語名は、「古いコードは決して編集しない」「常に継承を使う」、SOLID をクラスの性格診断にする、といった標語と衝突します。
バグもセキュリティホールも誤った契約も、直します。閉鎖は*ある振る舞いの利用者*に相対的です。彼らが使わない事例を足したからといって、引っ越させてはならない。公開契約そのものが間違っていれば、それを変え、波及の代を払います。パッチできないファイルは閉じていません。捨てられています。
メイヤーの初版が継承を使ったのは、当時教えていた道具だったからです。プラグインのフック、関数表、設定、紙の別表さえ、同じ形です。安定した扉と、その横の新しい部品。マーティンが2014年に言った要点は、プラグインアーキテクチャが原則の実物大だということです。壁のコンセントはサブクラスではありません。
見ていない変異には閉じられません。投機的な戦略オブジェクト、空のプラグイン API、「念のため」の枠組みは、チームがコンセントで溺れる仕方です。二つ目の本物の事例を待つ。それから蝶番を抜き出す。それまでは、はっきりした `if` が正直です。原則は予測した変化への応答であり、新しいファイルすべてへの税ではありません。
## 関連概念
これらのページは、すでに動いているものを揺らさずにシステムを変える、という同じ問題の隣に座っています。
モジュールごとに変わる理由は一つ。オープン・クローズド原則は、その理由が*どこに着地してよいか*を決める。
異なる決定を離しておく。差し込み可能性には、スロットの前にきれいな切り口が要る。
変異が本物になるまで蝶番を作らない。YAGNI のないオープン・クローズドは投機的アーキテクチャになる。
一つの事実は一つの表現。やりすぎた DRY は偽の蝶番を強い、足りない DRY は同じファイルを開き続ける。
契約は短く。肥大化したプラグイン API は、正直な枝が数本あるより単純ではない。
すぐ隣とだけ話す。内部を漏らす閉じたモジュールは、閉じていない。
## 一言で言うと
次の事例が、すでに名指しできる種類なら、安定した扉の向こうに新しい部品を足す。ランプのたびに壁を開き直さない。