外部依存性を増やさない
—— やれることをやらない設計

1. 現在の依存先

トキストレージが現在依存している外部サービスを、まず正直に列挙する。

• GitHub Pages — ホスティング。サイトの存在そのもの
• Cloudflare Workers + Google Apps Script — お問い合わせフォーム・注文フォーム・アクセス解析の送信
• Wise API — 国際決済。Webhook経由で入金を自動検知し、注文ステータスを自動更新
• OpenStreetMap — QR再生ページで録音位置の地図を表示。コミュニティ運営のオープンデータ
• Claude Code — 唯一の有償サブスクリプション。開発ツールであり、サイトの動作には一切関与しない

これが全部だ。アクセス解析もCloudflare Web Analyticsではなく、自前のtracker.jsがGASにビーコン送信する仕組みで完結している。無料枠の範囲内で動いているものと、従量課金（Wise）と、月額課金（Claude Code）が混在するが、いずれもサイトのコア機能——エッセイの表示とQRコードの生成・再生——には依存しない。Wiseが落ちれば手動で入金確認すればいい。OpenStreetMapが落ちても音声は再生できる。Claude Codeを解約してもサイトは一行も変わらない。フォントはシステムフォントを使っており、外部配信に依存しない。だが、コンテンツは届く。

この「壊れても致命的にならない」構造が、依存先を選ぶ基準だ。

生成AI——全領域を試した上での一本化

依存先リストの中で、Claude Codeだけが有償サブスクリプションだ。なぜこれだけは払っているのか。そして、なぜ「これだけ」なのか。

主要な生成AIは、すべてハンズオンで試してきた。

• コーディング支援 — ChatGPT、Gemini、GitHub Copilot、Cursor、Sourcegraph Cody
• 画像生成 — Midjourney、DALL-E、Stable Diffusion
• 動画生成 — Sora、Runway
• LLM API — OpenAI API、Anthropic API、Google Gemini API
• Agentic AI — LangChain、CrewAI、AutoGPT
• Deep Research — Perplexity、Genspark
• ローカル生成AI — Hugging Face、Ollama、llama.cpp。外部APIに依存しないセルフホスト型も検証済み

この中で、サイトの開発に直接貢献し、ランタイムに一切影響を与えず、解約してもサイトが一行も変わらないものは、Claude Codeだけだった。画像生成や動画生成は成果物をサイトに組み込めば外部依存になる。LLM APIを組み込めばランニングコストが発生する。Agentic AIフレームワークは開発の複雑さを増すだけだ。ローカル生成AIは外部依存を排除できる点で思想に合致するが、開発生産性ではクラウドモデルに及ばない。

Claude Codeは「道具」であり「部品」ではない。大工が使う鉋を捨てても、建てた家は倒れない。それと同じ構造だ。

地図エンジン——API課金なしの選択

QR再生ページには録音位置を地図で表示する機能がある。地図エンジンの選定にも、同じ基準を適用した。

• Google Maps API — 高機能だが従量課金。無料枠の上限を超えると月額が発生する
• Mapbox — デザイン性が高いがAPI課金モデル。同上
• HERE Maps — 自動車産業向けに強いが、やはりAPI課金
• Leaflet — ライブラリ自体は無料だが、タイル配信元が必要。結局どこかに依存する

選んだのはOpenStreetMapだ。API課金がない。Wikipediaと同じコミュニティ運営のオープンデータであり、特定企業の経営判断で消滅するリスクがない。そしてOSMが落ちても、QRコードの音声再生には一切影響しない。地図は補助情報であり、コア機能ではない。

プログラミング言語——超長期で持続する技術の選定

プログラミング言語は、用途によって向き不向きがある。そして向き不向きとは別に、超長期の持続性という軸がある。

Node.jsでサーバを立てれば、npmのパッケージエコシステムに依存する。Spring BootでAPIを書けば、JVMとMaven/Gradleに依存する。RailsならRubyGemsに、DjangoならPyPIに、LaravelならComposerに。どのバックエンドフレームワークも、ランタイムとパッケージ管理の連鎖を抱えている。依存ツリーの末端にある一つのライブラリがメンテナンスを停止しただけで、ビルドが壊れる。left-padの11行が消えてインターネットが止まりかけた事件を、開発者なら覚えているだろう。

10年なら問題ない。20年なら怪しい。100年後にnpm installが通る保証はない。1000年後は論外だ。

Node.jsの設計を反省したRyan Dahl自身が作ったDeno（Nodeのアナグラム）は、npmの依存ツリーを排除してURLインポートに切り替えた。だが、URLの先にあるサーバが消えれば、コードは動かなくなる。依存先の形が変わっただけで、依存という構造そのものは消えない。

この判断を下すために、30以上のプログラミング言語をハンズオンで書いた。

• システム・低レイヤー — C、Rust、Go、Fortran、D
• アプリケーション — Python、JavaScript、TypeScript、Ruby、Java、Kotlin、Swift、C#、PHP
• 関数型・論理型 — Haskell、Lisp、Elm、Scala、Prolog、F#
• レガシー — COBOL、Pascal、Objective-C、Perl
• 新興・ニッチ — Julia、Nim、Solidity、SAS、Smalltalk
• インフラ・設定 — Shell、HCL（Terraform）、Dockerfile、Vim Script

170を超えるハンズオンリポジトリがGitHubに公開されている。仕様書を読むだけでは見えない特性が、コードを書くと見える。言語ごとのエコシステムの厚み、依存関係の深さ、ランタイムの重さ——それは実際に触らなければわからない。

そして30以上の言語を試した結果、トキストレージはHTML、JavaScript、CSSに落ち着いた。コンパイラ不要。サーバ不要。パッケージマネージャ不要。ブラウザさえあれば動く。HTMLは1993年から存在し、ブラウザが解釈する限り動き続ける。プリミティブな技術だけが、超長期の持続性を持つ。バックエンドフレームワークの便利さは10年の生産性を上げるが、1000年の持続性を毀損する。だからトキストレージにはバックエンドがない。

TypeScriptやJSXを書けば、Babelやtscといったトランスパイラがビルドチェーンに加わる。コードが動くまでに通過するレイヤーが一つ増えるたび、1000年後の再現性は一段下がる。ピュアJavaScriptなら、ブラウザがそのまま解釈する。中間層はゼロだ。

3D・ビジュアル——体験の豊かさと依存の重さ

石板をブラウザ上で回転させ、刻印されたQRコードを拡大できたら。録音された声を3D空間の中で聴けたら。ビジュアル体験としてのインパクトは計り知れない。この可能性を検証するために、3D技術もハンズオンで試した。

• Three.js — WebGLベースの3Dシーンギャラリーを構築。ブラウザ上で動く3Dの可能性と限界を確認
• WebGL — Three.jsを介さず、低レイヤーのGPU描画を直接扱った
• Blender — Pythonスクリプトによる3Dモデリングとレンダリングの自動化
• Unity — ゲームエンジンによる2D/3Dインタラクティブコンテンツ

どれも動いた。だが、どれも依存が重い。Three.jsはnpmパッケージであり、バージョン更新が止まればWebGLの仕様変更に追従できなくなる。Unityはランタイムとライセンスに依存する。Blenderのレンダリング結果を静的画像として書き出せば依存は切れるが、それならHTMLとCSSで十分だ。3Dの体験は魅力的だが、1000年の持続性の前では、その魅力はコストに変わる。

ここでは詳しく触れないが、同じ思想は物理層にも貫かれている。記録媒体の選定でも、複雑な機構を排し、最もプリミティブな素材——UVラミネートと石英ガラス——にたどり着いた。デジタルでもフィジカルでも、引き算の設計が1000年を支える。

2. 入れませんか？——一覧表

ここまで、生成AI、地図エンジン、プログラミング言語、3D技術——あらゆる領域で技術検証と選定を繰り返し、現在の構成にたどり着いた。だが、1000年という時間軸の中では、依存先の見直しが必要になる局面はゼロにはならない。そのとき、判断の基準が属人的な記憶に頼っていては再現できない。ここでは、未来の運用者のために判断の指針を一覧として残す。

「このサービスを入れたらどうですか」と提案されそうなもの、あるいは実際に検討したものを一覧にした。なお、以下で言及するサービスはいずれも優れたソリューションであり、多くのプロジェクトにおいて最適な選択肢となり得る。ここでの不採用判断は、1000年の保管という特殊な要件に基づくものだ。筆者自身、別のプロジェクトやコンサルティングの場面では、これらのサービスを状況に応じて推奨・提案することもある。また、以下の13項目はすべて、過去にCTOやコンサルタントとしてのキャリアの中で実際にハンズオンで導入・運用した経験がある。「知らないから使わない」のではない。使った上で、このプロジェクトには不要だと判断した。

13項目すべてが不採用。これは偏屈ではなく、一貫性だ。

補足すれば、ここに挙げた13項目は氷山の一角に過ぎない。クラウドプラットフォーム（AWS、GCP、Azure）、BIツール（Tableau、Looker Studio）、DWH（BigQuery、Redshift）、CRM（Salesforce、HubSpot、Dynamics 365）、プロジェクト管理（Jira、Redmine、Backlog）、CI/CD（GitHub Actions以外の有償パイプライン）、APM（Datadog、New Relic）、SAST（Fortify、SonarQube）、CDN（Fastly、CloudFront）——エンタープライズの現場で扱ってきたスタックは数え切れない。そのすべてをやった上で、トキストレージにはHTML + CSS + JavaScript + WASMだけで十分だと判断している。

「知らないからやらない」と「やった上でやらない」では、
判断の重みがまったく違う。

3. 判断基準——三つの問い

外部サービスの導入を検討するとき、三つの問いを立てる。

問い1：それが止まったとき、コンテンツは届くか？

GASが停止しても、ページは表示される。Wiseが停止しても、手動で入金確認すればいい。だがFirebaseが停止したら？ データベースに依存していたら？ そのサービスの停止がコンテンツの到達を妨げるなら、依存してはいけない。

問い2：無料枠が消えたとき、支払い続けられるか？

多くのサービスは無料枠で始められる。だが無料枠は永遠ではない。料金改定、プラン変更、サービス終了——いつ起きてもおかしくない。1000年のうちに、無料枠が維持される保証はゼロだ。

問い3：それなしで、ブラウザだけで代替できないか？

音声読み上げはWeb Speech APIでできる。検索はJavaScriptでできる。オフライン対応はService Workerでできる。ブラウザの標準機能でできることを、わざわざ外部APIに委ねる必要はない。ブラウザは1000年後も存在するだろう。特定のAPIが存在する保証はない。

「できるか」ではなく「それが消えたとき何が起きるか」。
依存先を選ぶとは、消えたときの影響を選ぶことだ。

4. 体験を増やす誘惑

サービスを追加すれば、体験は確実に向上する。

YouTube動画を埋め込めば、テキストを読まない人にもリーチできる。OpenAIのTTSを使えば、ブラウザ標準よりはるかに自然な音声でエッセイを読み上げられる。Algoliaを入れれば、114本のエッセイを瞬時に全文検索できる。チャットbotがあれば、問い合わせの応答速度が上がる。

どれも正しい。どれも「入れた方がいい」と言える。正直に書けば、誘惑は本物だ。OpenAIのTTSで生成した音声を聴いたとき、ブラウザ標準のWeb Speech APIとの品質差に息を呑んだ。Algoliaのデモを触ったとき、静的サイト検索では逆立ちしても出せない速度と精度に唸った。「これを入れたら、もっと多くの人に届くのに」——その思いは、今でも消えていない。

だが「もっと多くの人に届く」と「1000年後にも届く」は、同じ軸の上にない。短期の到達範囲を最大化する設計と、超長期の到達確率を最大化する設計は、トレードオフの関係にある。この葛藤を認めた上で、トキストレージは後者を選ぶ。体験の豊かさより、体験が届き続けることを優先する。

体験を増やすたびに、依存先も増える。依存先が増えるたびに、どこかが壊れたときにサイト全体が劣化するリスクが増える。そして「壊れた箇所を直す」という運用負荷が発生する。運用負荷は、ランニングコストの別名だ。

金銭的コストがゼロでも、外部サービスのAPI仕様変更に追従するための時間的コストは発生する。現にトキストレージでも、Cloudflareのスクリプトタグが変わった。WiseのWebhookフォーマットが変わった。GitHub Pagesのビルド仕様が変わった。依存先がたった5つでもこれだ。12個あれば、年に数回はどこかが変わる。

5. やらない選択の積み重ね

トキストレージの設計は、「やらない選択」の積み重ねでできている。

• カスタムドメインを取らない。github.ioで運用する。ドメイン更新料がかからない
• サーバーを持たない。GitHub Pagesの静的ホスティングで完結する
• データベースを使わない。すべてのデータはHTMLとQRコードに含まれる
• ユーザー登録を求めない。個人情報を預からない
• アプリストアに出さない。PWAで十分だ
• Webフォントを使わない。システムフォントで十分だ。外部配信に依存しない
• 外部APIを増やさない。ブラウザ標準でできることはブラウザに任せる

これらは「できないからやらない」のではない。「やれるがやらない」のだ。やれることをやらない選択には、明確な意思が必要だ。トレンドに流されず、提案に惑わされず、「それは本当に1000年持つか」と問い続ける。

やれることをやらない。
その選択の根拠を説明できることが、設計思想だ。

6. 例外の条件

すべての外部サービスを拒絶しているわけではない。現に、GitHub Pages、Cloudflare、Wiseには依存している。例外を認める条件がある。

条件1：停止してもコンテンツが届く。Cloudflareが落ちてもページは表示される。Wiseが落ちても手動で入金を確認すればいい。フォントは外部配信ではなくシステムフォントだから、ネットワーク障害にも影響されない。「劣化するが死なない」依存だけが許容される。

条件2：無料であり続ける蓋然性が高い。GitHub PagesはMicrosoftのインフラ、CloudflareはWeb全体のインフラ。いずれもビジネスモデル上、無料を維持する動機がある。Wiseは従量課金だが、月額固定費はゼロだ。

条件3：移行先が存在する。GitHub Pagesが終了しても、静的HTMLはどこにでもホスティングできる。Wiseが終了しても、銀行振込に戻せばいい。依存先が消えたとき、移行できないものには依存しない。

この三条件をすべて満たすものだけが、依存先として許容される。逆に、一つでも満たさないものは、どれだけ便利でも採用しない。

7. 引き算の設計

ソフトウェア開発では、機能を足すことが進歩とされがちだ。新しいAPIを組み込み、新しいサービスを連携し、新しい体験を提供する。足し算の設計だ。

トキストレージは引き算で設計する。何を足すかではなく、何を足さないか。何を依存するかではなく、何に依存しないか。依存先を一つ減らすたびに、壊れるポイントが一つ消える。壊れるポイントが消えるたびに、1000年後にコンテンツが届く確率が上がる。

これは、墓石と同じ構造だ。墓石は、訪れた人にはすべてを見せる。だが自らどこかに出向くことはない。YouTubeに動画を上げるのは、こちらから出向くことだ。App Storeにアプリを出すのも、出向くことだ。間口は開けておく。来てくれた人にはコンテンツが届く。だが、こちらからは組み込まない、埋め込まない、出張らない。

現在の構成——HTML、CSS、JavaScript、WASM。ブラウザが解釈できるファイルだけで、サイトの全機能が動く。サーバーサイドの処理はない。データベースはない。APIコールはない（アクセス解析とフォーム送信を除く）。この構成は、20年前のブラウザでも基本的に動く。そして20年後のブラウザでも動くだろう。

外部依存性を増やさないことは、機能の制限ではない。持続性の設計だ。

8. ポリシーが検討を終わらせる

SEOが効き始め、検索エンジンやAIからリコメンドされるようになると、関連業者からの提案が増えてくる。「アクセス解析ツールを入れませんか」「チャットbotを導入しませんか」「広告を出しませんか」「動画コンテンツをやりませんか」——善意の提案もあれば、営業もある。

ポリシーがなければ、一件一件を個別に検討しなければならない。メリットとデメリットを比較し、コストを計算し、導入の可否を判断する。これを毎回繰り返すことの時間的コストは、ランニングコストの一形態だ。

だが、ポリシーが明文化されていれば、回答は一瞬で終わる。「ポリシーにより不採用です。理由はこちらに記載しています。」——この一覧表がそのまま回答テンプレートになる。検討する時間がゼロになる。

「13項目の一覧表を作ること自体がコストではないか」——その通りだ。だが、一覧表を一度作るコストと、提案が来るたびに個別検討するコストを比較すればいい。前者は一回限り、後者は永続的に発生する。ポリシーとは、一度の設計コストで、以後の検討コストをゼロにする仕組みだ。

これは、ソロ開発者にとって特に重要だ。チームがいれば提案の検討を分担できる。だがひとりで開発し、ひとりで運用する場合、「検討する時間」は「開発する時間」から直接奪われる。不要な検討を排除することが、開発の持続可能性に直結する。

ポリシーとは、毎回考えなくていい仕組みのことだ。
明文化された「やらない理由」が、持続可能性を守る。

9. 原体験——外部依存で会社が死ぬとき

この依存性ポリシーは、理論から生まれたものではない。実体験から生まれた。

かつて、成果報酬型SEOサービスを提供する会社でCTOを務めていた。売上の大部分は、検索エンジンのアルゴリズムに依存していた。ある日、アルゴリズムが変わった。売上が吹き飛んだ。上場計画は頓挫し、自ら辞任を選んだ。

外部依存とは、自分がコントロールできない変数に事業の存続を委ねることだ。検索エンジンのアルゴリズムは、Googleの一存で変わる。APIの料金体系は、提供元の経営判断で変わる。無料枠は、いつでも廃止される。それが起きたとき、依存していた側は何もできない。

2026年2月、まさに同じ構造の崩壊が起きた。Anthropicが法務AIプラグインを発表し、法務SaaS企業の株価が一日で暴落した。Thomson Reutersは史上最大の下落幅を記録し、RELX、Wolters Kluwer、LegalZoomが軒並み二桁の下落。市場全体で約2,850億ドルの時価総額が消失した。「AIモデルを借りて、専門領域のUIを被せて月額課金する」——そのビジネスモデルの依存先であるAnthropicが、自らアプリケーション層に降りてきた。ラッパーSaaSの存在意義が一瞬で消えた。

トキストレージは、この構造とは無縁だ。Claude Codeは開発に使っているが、サイトのランタイムには一切組み込んでいない。仮にAnthropicが専門サービスのレイヤーに降りてきても、仮にClaude Codeが終了しても、サイトは一行も変わらない。HTML、CSS、JavaScript、WASM——ブラウザが解釈できるファイルだけで動いている。依存先が方針を変えても、死なない。

外部依存で会社が死ぬところを見た。
だから、外部依存で死なない設計を選んだ。