なぜ『何もしてないのに壊れる』のか？～事業継続性を担保する依存性管理手法を解説～

“止まっているのはあなただけ”という話

月曜の朝9時、Slackが鳴ります。

そう、あなたは“何もしてない”。けれど世界はずっと何かをしているのです。

太平洋の向こうでメンテナが1行直し、欧州でライセンス条項が1文変わり、アジアのどこかで“無害そうな”パッチが1つ増える。

あなたの会社は止まっていても、依存グラフは時差で生き物のように動く——そしてある朝、システムは「なぜか壊れました」と言い出す。

依存は悪ではない。だが無計画は悪です。

本記事では、事業継続性の土台を“設計”する手法について徹底解説します。

1. 依存関係とは“前提”であり“土台”である

まず言葉を整えましょう。

依存関係とは、単に「オープンソースを使うこと」や「公開サービスを利用すること」ではありません。

自社ビジネスの前提として、何を“地盤”にするかの選択です。

家づくりで地盤と基礎がすべてを左右するように、プロダクトづくりでも「どこから上を自分で積むか」「どこまで下を他人に預けるか」を決めるこのが重要です。そして、この行為そのものが依存関係管理です。

現実のITサービスは、すべてを自社で賄うことが非現実的です。

クラウド、Web標準、OS、ミドルウェア、外部API、ライブラリ、フレームワーク——多数の外部前提を受け入れて初めて、1つの機能が立ち上がります。

だからこそ問うべきは「使うか使わないか」ではなく、“どこまでを内製し、どこから外部前提にするか”という線引きです。

想像してください。自分は何もしていないのに、ある朝、自社サービスが起動しない状況を。

よく探すと外部ライブラリの破壊的変更、CDNの挙動変更、SaaSの料金プラン改定、あるいは脆弱性の緊急パッチが原因だった

——つまり前提が動いたのです。

依存関係管理は、事業継続性（BCP）の基礎工事です。

以降では、外部依存を賢く使う作法、内外の線引き、そして“根性では埋まらない穴”を仕組みで埋める設計について、順に解き明かします。

2. 「巨人の肩」に乗る作法――基本を間違えなければ武器になる

暗号、圧縮、日時、レンダリング、etc.。

枯れた技術は外部依存した方が安全で速い。

ただし、その外部依存の“置き場所”を誤ると土台が揺らぎます。

鍵は実行面とビルド面の分離です。

本番環境（ユーザー端末で実行される実行面）に載せる依存は最小集合に抑え、巨大な外部ライブラリは既知安定バージョンを同梱して外部CDNや最新追従に任せない。
ビルド支援の依存は開発環境の中だけに閉じ込め、ユーザーの世界まで“お出かけ”させない。

これだけで外部依存のリスクは目に見えて小さくなり、外部の天気に左右されにくくなります。

同時に、決定論的ビルドを徹底します。

lockfileは“真実のソース”、コンテナイメージは"システムの実像"です。
誰が、どこで、いつビルドしても同じ結果になる状態こそ、安心して依存できる条件です。

これが、外部依存を取り扱う最低限の作法です。

3. 線引きの核心――生殺与奪を外部に握らせない

作法を押さえたら、次は線引きです。

結論から言えば、コア技術は外部依存しない。

ここで言うコアとは、自社事業が生み出す顧客価値の源泉であり、事業の存続を左右する技術・アルゴリズム・データ・体験の総体です。

ITサービスを運営するなら、事業の生殺与奪の権利を外部に委ねないことが最優先の原則になります。

もちろんサービスによって性質が異なります。

たとえば「既存技術を巧みに組み合わせ、UI/UXの提示で価値を出す」タイプのサービスなら、深層のロジックは外部依存でも成立します。
この場合のコアは組み合わせ方とプレゼンテーション層であり、そこだけは内製で守ります。

一方、独自アルゴリズムやデータ資産が価値の源泉であるサービスの場合、そこを外部ライブラリに依存した瞬間に断頭台に自らの首を差し出すことになります。

どちらのタイプであっても、自社のコアはどこかを言語化し、そこに外部依存を置かない。

この線引きができて初めて、依存は“効率の友”になります。

4. Obsidianに学ぶ「Less is safer」――少ないほど安全、だが盲目的に減らさない

ノートアプリのObsidianは、サプライチェーン攻撃の増加に対し「Less is safer」を設計に落とし込みました。

Less is safer: How Obsidian reduces the risk of supply chain attacks

小さな機能は自作し、中規模はフォークして内包し、大型は既知良版をピン留め同梱する。これが、Obsidianの依存管理の基本方針です。

postinstallのようなインストール時の任意実行は避け、更新は“遅らせて”検証。配布物に載る依存を意図的に絞ることで、外部の変動が実行面に伝わる経路を細くする。

ここには「全部自前」という原理主義はなく、粒度の設計があります。

初速はやや落ちても、事故と保守を含む総コストで見ればむしろ合理的。

短期目線ではなく、中長期の安定運用を重視した合理的な戦略です。

5. “根性では埋まらない穴”を、仕組みで埋める

事業継続性の担保や依存性管理に、なぜ仕組みが必要なのか。

理由は単純で、外部依存は常にリスクであり、同時に未来のコスト（負債）だからです。

運用中の現場は常に負荷にさらされています。利用者からの問い合わせ、障害対応、競合との機能競争、日々の新機能開発、etc.。

そこへ予告なく外部ライブラリの更新が降ってきたらどうなるでしょう。

ライブラリの破壊的変更、SaaSの仕様変更、CDNのふるまい、脆弱性の緊急パッチ……根性で受け止め続けられるほど人間は強くできていません。

だから事業継続性の“前提”にルールを与えます。

たとえば、言語やライブラリの選定段階で「後方互換性を継続的に宣言し、実務で守っている」ものに依存する。
Goのように互換性方針を強く掲げるエコシステムは、更新対応の見通しを与えてくれます。

逆に、いつ破壊的変更が来るか読めないライブラリは、内製で置き換えるか、ベンダーのサポート契約を取ることで、"リスクの問題"を"コストの問題"に転換する。

前提の安定性にお金を払うのは、弱さではなく経営の判断です。

セキュリティも同じです。

依存や言語に脆弱性が出た時、速やかなアップデートが必要になります。

この“速やかさ”は気合いでは実現できません。

ポイントはテスト資産と封じ込めの設計です。

業務コンポーネント単位で境界を切り、外部との接点はAdapter/Portで明確化する。

間にアンチコラプションレイヤやサーキットブレーカを挟み、壊れる可能性を常に想定する。

ユースケースの動線に沿った手でなぞるコアシナリオが10本だけでも用意されていれば、脆弱性パッチ後の“怖さ”は桁違いに下がる。

封じ込めの境界とテストの資産は、更新の恐怖を“手順”に変える変換器なのです。

ここまで踏み込むと、「なるほど仕組み化とはこのレベルの前提設計まで含むのか」と腹落ちしてくると思います。

見える化、固定化、遅延、分離

——これらは絵に描いた理想ではなく、“前提の動きを人間が扱える速度に落とす”ための現実的な道具です。

結び――変化の通り道は、設計できる

外部依存は武器にもリスクにもなります。

違いを生むのは、綿密な計画と設計、そして前提の置き場所です。

巨人の肩に乗るなら、肩のどの位置に立つかまで決める。

コアは外に出さない。型に合った線引きを言語化し、更新は戻れる速さで運用する。

根性ではなく仕組みで穴を埋める。

• 自社のコアを一文で書き、そこに外部のスイッチが無いかを見直す。

• 主要依存を一つだけ選び、互換性方針を明文化する。

• テストを用意し、責任分界点に一つだけ“安全弁”を挟む。

これだけで、「何もしてないのに壊れた」問題は、あなたの管理下に収まります。