皆さん、こんにちは。ファーストループテクノロジーのマルコです。
当社では、お客様の効率と安全性の両方を向上させる、堅牢で長寿命なソリューションの提供に努めています。
今回は、現代のエンジニアの多くが見落としがちな、非常に重要な概念について紹介したいと思います。
現在の開発状況
ソフトウェア開発において、多くの人々は複雑なフレームワーク、複数のパッケージ、そして REST API やマイクロサービスを使用しています。
これらの標準化されたビルディングブロックを利用することで、開発者は迅速に動作するプロトタイプを構築でき、作業の大部分を自動化できるため、非常に快適な開発体験を得ることができます。
一見すると、これらのツールを使わない理由はないように思えるでしょう。
しかし、忘れてはならないのは、これらのパッケージが「魔法のように」何かをしてくれるわけではなく、実際の処理をある程度隠蔽しているということです。
また、これらのパッケージは常に誰かが保守し、所有しているものでもあります。
有名な「left-pad 事件」を覚えている方もいるかもしれません。
この出来事では、ある小さな NPM パッケージが削除されたことによって、インターネットの広範囲、特に人気ライブラリ React までもが影響を受けました。
この事件は、現代の Web フレームワークがいかに脆く、そしてわずかな変更でも多くの人々に影響を与えうるかを示しました。
この問題はパッケージに限らず、API にも深く関係しています。
近年話題となっている大規模言語モデル（LLM）は、RAG（Retrieval-Augmented Generation）やエージェント機能、さらには関数呼び出しなど、さまざまな形で API を介して利用することができます。
しかし、「API が変更される可能性や、提供会社がサービスを停止する可能性は低いから大丈夫」と思ってはいないでしょうか？
ここで少し視点を変えて考えてみましょう。
例：パーソナル音声アシスタントアプリケーション
たとえば、自分専用の音声アシスタントアプリを作りたいとします。
自然な言葉で話しかけると、天気を教えてくれたり、メールを送ったり、音楽を再生したりしてくれる――そんなアプリを想像してください。
ここでは、無数のライブラリやインフラ構成を一旦無視したとしても、実際に機能させるためには複数の API に依存する必要があります。
まず、音声をテキストに変換し整形する音声解析 API、
次に、内容を理解して指示を判断する言語モデル API、
そして最終的に、天気情報 API、メール送信 API、音楽プレイヤー APIなどが必要になります。
このように、アプリの動作には少なくとも 5つの API に依存していると仮定しましょう。
では、これらの API が年を経てもすべて問題なく動作し続ける確率を考えてみます。
その確率は、次の式で表せます：
- p … 各サービスが1年後も変更・停止されずに稼働している確率
- x … 利用しているサービスの数
- n … 経過年数
たとえば、まず非常に楽観的なケースとして「各サービスが毎年 99% の確率で存続する」と仮定してみましょう。
一見ほとんど安全に思えますが、依存するサービスが5つあると、10年後にすべてが問題なく動作している確率はおよそ 60% にまで低下します。
次に「各サービスが毎年 98% の確率で存続する」と仮定した場合を見てみましょう。
1年ごとの変化はわずかに見えますが、年数を重ねるとその影響は指数関数的に大きくなり、10年後の稼働確率は 36% 程度にまで落ち込みます。
わずか2%の差が、長期的にはこれほど大きな信頼性の違いを生み出すのです。
続いて「各サービスが毎年 95% の確率で存続する」と仮定した場合です。
この場合、たった5%の差とはいえ、10年後のシステム全体の稼働確率は 約8% にまで下がります。
つまり、100人のユーザーが同じ構成を使っていても、10年後に動いているのはわずか8人分のアプリという計算になります。
最後に、より現実的な前提として「各サービスが毎年 90% の確率で存続する」と仮定してみましょう。
このケースでは、5つの API に依存するアプリが10年後まで問題なく稼働する確率は、わずか0.3%以下 にまで低下します。
言い換えれば、ほぼ確実に何らかの API が停止・仕様変更・アクセス制限などによってアプリ全体が動作しなくなるということです。
このように、見た目には小さな「年間信頼性の差」でも、複数サービスへの依存と時間の経過によって、その影響は驚くほど大きくなります。
仮にあなたのシステムが10個、20個の外部 API に依存している場合、長期的な安定稼働の確率はさらに急激に下がります。
ここからわかるのは、現代の開発において「便利さ」と「持続性」はトレードオフの関係にあるということです。
安定したシステムを維持したいなら、依存関係を減らすこと、そして自分でコントロールできる範囲を広げることが何より重要です。
なぜこれは重要なのか
現代では「すぐに作れること」や「迅速なリリース」が重視されがちですが、この確率の低さが示しているのは、現代のソフトウェアの多くは長期運用を前提に設計されていないという事実です。
システムは往々にして、開発者が完全にコントロールできない外部コンポーネントの上に構築されています。
つまり、自分のコードが完璧でも、外部サービスの変更によって全体が壊れてしまう可能性があるのです。
ソフトウェアを単なるツールではなく、**インフラストラクチャ（基盤）**として捉えましょう。
長期的に維持可能で、安定して動作し続けることこそが本質的な価値だと考えています。
そのためにはフレームワークや API を避けるのではなく、リスクを理解し、独立性を保てる設計を行うことが重要です。
たとえば次のような戦略が有効です：
- 重要な依存関係に対する 内部フォールバック や ミラー構築
- API 抽象化レイヤー を導入し、容易に切り替え可能にする
- 重要な処理は可能な限り ローカルで完結 させる
- 外部依存が途絶した場合の フェイルモード（失敗時挙動） を明確に設計する
結論
ここでの教訓は非常に明快です。
外部システムに依存すればするほど、自分のシステムの未来をコントロールできなくなります。
安定性、回復力、独立性 は古い考え方ではなく、長期にわたって持続可能なシステムに欠かせない要素です。
多くの外部サービスに頼る必要はありません。
モダンなフレームワークや API は確かに強力ですが、それらはあなたのシステムを「支配する」ものではなく、「補助する」ものであるべきです。
真に堅牢なソフトウェアとは、自分で理解し、コントロールできる構成要素によって支えられているものです。
不要な依存関係を減らし、重要な処理の所有権を自分の手に取り戻すことで、信頼性を高めるだけでなく、将来にわたって柔軟に進化できる自由を得ることができます。
FLTでは、「便利さの先」にある設計思想を大切にしています。
それは、システムを支える技術に対して制御・透明性・所有権を確保すること。
そうすることで、今日構築したものが、明日も、そして10年後も確かな形で存在し続けるのです。
この記事はこちらのポッドキャストを参考にして作られました。
▼ 転職を検討中の方、お気軽にご連絡ください！カジュアル面談から可能です。
ファーストループテクノロジー株式会社| 採用情報（コチラ）
ファーストループテクノロジー株式会社（FLT）の採用情報です。エンジニア・デザイナー・プロダクトマネージャー、セールス、コーポレート等、未来を創る仲間を募集中です！
▼ 取材などメディア関係者の方は会社HPよりお問い合わせください
お問合せフォームは コチラ
▼ 当社のnoteもぜひご覧ください！
コチラ
ファーストループテクノロジー株式会社です。私たちは、自社の最新のIT技術を用いて製造や建設、インフラといった日本のあらゆる現場における課題の解決を図っています。「現場エンジニアリング」を掲げる当社の、公式テックブログになります。
Discussion