単一障害点をなくす

1. 「無料プランが終わったら」という問いが設計を変えた

あるとき、こんな問いが浮かんだ。「このAIサービスの無料プランがなくなったら、自分の仕事はどうなるか。」

朝のブリーフィング、タスク管理、メモの整理——気づけばAIが日常業務の中枢を担っていた。便利だった。摩擦がなかった。だからこそ、依存の深さを測ることを怠っていた。

問いに正直に答えようとしたとき、答えは「止まる」だった。データは手元にある。フローも設計している。だが「考える」部分だけが、特定のサービスに縛られていた。

2. 単一障害点とは何か

システム設計の世界に「単一障害点（Single Point of Failure）」という概念がある。ひとつの部品が止まると、システム全体が止まる構造のことだ。冗長化設計の反対語でもある。

これはサーバーやネットワークだけの話ではない。業務フローにも、個人のワークスタイルにも、同じ概念が当てはまる。特定のツール、特定のサービス、特定のモデル——それらへの依存が深まるほど、その部品が止まったときのダメージは大きくなる。

AIサービスは今、急速に業務の中核に入り込んでいる。その速さゆえに、依存の構造を意識する前に組み込まれてしまうことが多い。気づいたときには、抜けられない設計になっている。

3. データとロジックとモデルを分離する

解決策は単純だった。AIを「交換可能な部品」として設計することだ。

そのためには、三つの層を明確に分ける必要がある。

データ層（自分のGit）
　↓
ロジック層（ワークフロー・スキル定義）
　↓
モデル層（Claude / GPT / Llama / Gemini...）

データはどこに置くか。ロジックはどう書くか。モデルはどう呼ぶか。この三つを分離して設計すれば、モデル層だけを差し替えることができる。上の二層は何も変わらない。

4. 実際にやってみた

朝のブリーフィングを例に取る。毎朝、プロジェクトの状況・声メモ・メールを読んで、今日のフォーカスを整理するルーティンだ。

最初はAIに手動で渡していた。毎朝、ファイルを読んで、整理して、返答をもらう。便利だったが、AIなしでは動かない設計だった。

次に、データをGitリポジトリに置き、ワークフローを自動化した。AIへの問いかけ方をスキル定義としてファイルに書き起こした。すると、あることに気づいた。このスキル定義さえあれば、どのモデルに渡しても同じ出力が得られる。

試しに、あるAIサービスの無料枠で動くモデルに切り替えてみた。スキル定義のファイルはそのまま。呼び出すエンドポイントのURLと、モデル名の一行だけを変えた。ブリーフィングは動き続けた。

5. モデルを等価に扱うということ

「等価に扱う」とは、どういうことか。それは、モデルに固有の語り口や癖に依存しないということだ。

特定のモデルが「なぜかうまく答えてくれる」という体験がある。プロンプトの微妙なニュアンスが、そのモデルの特性とたまたま合っていることがある。だが、それに依存してしまうと、モデルを変えたときに壊れる。

等価に扱うための設計原則は、「どのモデルに渡しても動くプロンプトを書く」ことだ。出力フォーマットを明示する。入力データの構造を整える。期待する動作を具体的に書く。曖昧さを減らす。これは、特定のモデルへの依存を減らすだけでなく、プロンプト全体の品質を上げることにもつながる。

6. ローカルモデルという選択肢

クラウドのAIサービスがすべて有料化・停止されたとしても、ローカルで動くモデルという選択肢がある。手元のコンピュータで動かせる小型モデルは、数年前と比べて格段に精度が上がっている。日本語にも強いモデルが増えた。

ブリーフィング程度のタスクなら、クラウドサービスと遜色ない出力が得られる。インターネット接続がなくても動く。利用制限もない。データが外部に出ない。

もちろん、高精度が求められるタスクにはクラウドの大型モデルが適している。重要なのは、用途に応じて使い分けられる設計を持つことだ。ローカルモデルでも動くように設計しておけば、クラウドは「性能向上のオプション」になる。依存ではなく、選択になる。

7. 持続可能なAI活用の条件

AIサービスの市場は今も激しく動いている。無料枠が縮小され、価格が改定され、サービス自体が統合・終了するケースも出てきた。数年前に「これしかない」と思っていたサービスが、今は別の何かに置き換わっている。

持続可能なAI活用の条件は、特定のサービスへの依存度を意識的に下げ続けることだ。データを自分で持つ。ロジックを自分で書く。モデルを差し替え可能にする。この三つが揃ったとき、AIは「借りている道具」から「自分のインフラの部品」に変わる。

道具は消耗する。インフラは育つ。その違いは、設計思想にある。

この思想を、記録そのものに適用すると何が起きるか。声・画像・テキストといった個人の記録を、デジタルだけでなく物理媒体にも、単一の国や機関に依存せず複数の場所に分散して保管する。クラウドが終わっても、会社が消えても、国が変わっても、記録が残る設計だ。単一障害点をなくすという原則は、AIツールの選択だけでなく、記録の保管層にまで貫かれてはじめて、本当の意味での持続可能性になる。

8. 止まらないシステムの静けさ

単一障害点のないシステムには、独特の静けさがある。何かが止まっても、別の何かが動いている。慌てない。焦らない。代替を探す必要がない。なぜなら、代替は最初から設計に組み込まれているからだ。

これは冗長化の話でもあるが、もっと根本的には「依存の意識化」の話だ。何に依存しているかを知り、その依存が断ち切られたときのプランを持つ。それだけで、システムの脆弱性は大きく下がる。

AIをどう使うかより、AIとどう付き合うかを設計する。その問いに答え続けることが、長く動き続けるインフラを育てることになる。