生成AIの普及以降、アプリ開発の風景は明らかに変わった。
設計書よりもプロンプト。
細かな実装よりも構造の指示。
いわゆる「バイブコーディング」が現実になりつつある。
その流れの中で、バックエンド基盤の重要性はむしろ増している。
フロントはAIが生成できる。
だがデータはどこに置くのか。
認証はどうするのか。
APIは何で支えるのか。
そこで支持を集めてきたのが、PostgreSQLを中核に据えたクラウド基盤だ。とりわけSupabaseは、SQLの構造とクラウドの初速を両立させる存在として、開発者コミュニティで存在感を強めてきた。
そんな最中、インド国内でSupabaseへのアクセスが遮断されるという事態が起きた。
対象はSNSではない。
動画アプリでもない。
開発基盤だ。
このニュースは単なる地域的トラブルなのか。
それとも、インフラと主権の関係が変わり始めた兆候なのか。
本稿では、事件そのものを追うだけでなく、そこから読み取るべき構造的メッセージを整理していく。
第1章 事件の概要
1.1 何が起きたか
2026年2月下旬、インド国内の複数のISP環境で、開発者向けバックエンド基盤「Supabase」へのアクセスが不安定になった、もしくは接続できないという報告が相次いだ。影響は、単に管理画面が開けないといった話ではなく、Supabaseをバックエンドとして利用しているアプリやWebサービスの認証・DB接続・ストレージアクセスなど、運用の中核に直撃し得る性質を持つ。
報道によれば、背景にはインド政府によるブロッキング命令があるとされる。命令の法的根拠として挙げられているのは、インドの情報技術法にある Section 69A だ。
ここで重要なのは、止められた対象が「SNS」や「動画アプリ」のような消費者向けサービスではなく、開発者がサービスを作るための「基盤」だった点だ。表に見えるコンテンツではなく、裏方のインフラが止まった。
1.2 Section 69A とは何か
Section 69A は、政府が一定の要件のもとでオンライン情報へのアクセス遮断を指示できる枠組みとして知られている。過去にもインドでは、国家安全保障や公共秩序などの文脈で、各種オンラインサービスが規制対象になってきた。
ただし今回の件は、仮に同じ法的枠組みであったとしても、対象が「アプリ」ではなく「開発基盤」であるという点で性格が違う。アプリを止めるのは利用者体験の問題で済むが、基盤を止めるのはサービス運用そのものを止める。つまり経済活動の停止に近い。
1.3 「理由が非公開」という事実
現時点で報道上は、ブロッキング命令が出たこと自体は伝えられている一方で、政府が「なぜSupabaseなのか」を具体的に説明しているわけではない。ここが最大の論点になる。
この種の案件で、理由が公開されないのは珍しくない。だが、理由が公開されないまま「開発基盤」が止められると、利用者側は対策の立てようがない。どの機能が問題なのか、どの利用形態が危険なのかが分からないからだ。
本稿ではこの「説明の欠如」を、単なる不親切ではなく、技術者にとってのリスクとして扱う。
1.4 回避可能性（DNSで抜けるという報告）
影響範囲や遮断の方式については、DNSを変更すると到達できた、VPNで回避できた、といった報告も流通している。少なくとも「国家レベルの全面遮断」というよりは、ISPレベルの手段で実装されている可能性が示唆される。
ただし、この話は重要な注意点がある。
回避できることは「規制が緩い」と同時に「一般ユーザーにとっては実質的に止まる」という意味でもある。開発者はDNSを替えるが、一般ユーザーは替えない。すると、サービス提供者は「自分のサービスが落ちた」ように見える。
この時点で言えるのは、回避手段があるかどうかではない。「ある日突然、接続が前提だった基盤が不安定になる」という事実それ自体が、設計上の前提を揺さぶる、という点だ。
第2章 なぜアプリではなく「基盤」を止めたのか
ここからは事実を踏まえた構造分析に入る。断定はしない。可能性を分解する。
2.1 コンテンツ規制とインフラ規制の違い
これまで各国で行われてきたブロッキングの多くは、消費者向けアプリや特定コンテンツを対象としてきた。
SNS、動画アプリ、ゲームアプリ。
止められるのは「見えるもの」だった。
しかし今回対象になったのは、アプリではない。
開発者向けバックエンド基盤だ。
これは性質がまったく違う。
アプリを止めるのは「消費の制限」。
基盤を止めるのは「生産の制限」。
この差は大きい。
アプリ停止は利用者の不便で済む。
基盤停止は、サービス運営そのものが止まる。
つまり、規制の重心が「コンテンツ」から「接続」に移った可能性がある。
2.2 なぜ基盤が警戒対象になるのか
仮説として考えられるのは、次のような構造だ。
Supabaseのような基盤は：
- 誰でも即座にAPIを生成できる
- データベースを数分で公開できる
- 認証基盤をすぐ立ち上げられる
- 無料で試せる
これは開発者にとっては合理性の極みだ。
だが政府視点に立つとどう見えるか。
- どのプロジェクトが立ち上がっているか把握しにくい
- 短期間で多数のアプリが生まれる
- データが国外リージョンに保存される可能性がある
ここで重要なのは、「違法コンテンツがあったかどうか」ではない。
問題は、
統制が難しい構造かどうか
だ。
コンテンツは個別に削除できる。
だが、基盤は個別に止めにくい。
だからこそ「まとめて止める」という発想が生まれる。
2.3 「共有されるべきでないデータ」という曖昧さ
報じられている説明は「共有されるべきでないデータが共有されていた」という曖昧な表現だ。
この言い回しの特徴は三つある。
- 違法とは言っていない
- 国家安全とも明言していない
- 具体的対象を示していない
つまり、解釈の幅を残している。
これは偶然ではない可能性が高い。
具体性を持たせると、規制は限定される。
曖昧にすると、適用範囲は広がる。
この種の表現は、規制の可動域を確保するためのものでもある。
2.4 DNSレベル遮断が意味するもの
もし遮断がDNSレベル中心であれば、それは「完全封鎖」ではない。
IPレベル、BGPレベル、DPI（深層パケット検査）まで踏み込んでいないなら、技術的には回避可能だ。
だがここで考えるべきは、
技術的に回避可能かどうかではない。
重要なのは「公式に止めた」という事実だ。
それはシグナルになる。
- 政府は基盤を止め得る
- SaaSは不可侵ではない
- 開発インフラも政治対象になる
これは市場に対するメッセージでもある。
2.5 前例の意味
仮に今回が例外的措置だとしても、「一度起きた」という事実は残る。
そして規制は、常に前例を積み重ねる。
一度「基盤を止められる」と示されれば、次は他の基盤も理論上は対象になる。
ここで名前を出す必要はない。
問題はブランドではなく、構造だ。
2.6 本質
今回の件が示すのは、
アプリは文化だが、
インフラは主権に接触する。
という構図だ。
基盤は国家の境界をまたぐ。
データは国境を越える。
税は国内で発生する。
この交差点で摩擦が起きる。
そして摩擦が起きたとき、止められるのは「接続」だ。
第3章 なぜわざわざ公式SaaSを使うのか
どこのVPSでも動くのに、なぜ公式SaaS？
政府がピリつくなら国内VPSでよくないか？
合理的な疑問だ。
だが、ここには三層の構造がある。
3.1 「動く」と「運用できる」は違う
確かに Supabase は自己ホスト可能だ。
Dockerで立つ。
PostgreSQLだ。
EdgeもAuthも動く。
しかし、
動くことと、
安定運用できることは別だ。
公式SaaSは：
- 自動バックアップ
- リージョン冗長
- 証明書管理
- モニタリング
- SLA
を含んでいる。
VPSで立てた瞬間から、あなたは：
- OS管理者
- セキュリティ担当
- 障害一次対応者
になる。
スタートアップや小規模開発者は、そこに時間を使わない。
ここは思想ではなく、単純な経済合理性。
3.2 信頼を“借りる”という行為
公式SaaSは単なるホスティングではない。
それは、
信頼の借用
だ。
- 可用性
- セキュリティ設計
- 運用体制
- 監査ログ
これらを自前で積むのは重い。
特にB2B向けサービスでは、
「どこにホストしているか」は信用材料になる。
公式SaaSはブランドを含む。
3.3 それでもロックインではない
ここが一番重要。
Firebaseと違い、Supabaseは：
- 素のPostgreSQL
- dump可能
- 別VPSへ移行可能
- 自己ホスト可能
つまり、
囲い込み型SaaSではない。
これは設計思想の違いだ。
Firebaseは“中で完結”する。
Supabaseは“外に出られる”。
だから、
いつでも尻をまくれるSaaS
それがSupabase。
3.4 国内VPSが本当に安全か？
「国内に置けば安全」という発想は直感的だが、実は単純ではない。
国内VPSは：
- 行政命令が直接届く
- 物理押収可能
- ログ提出命令が即時
国外SaaSは：
- 法的摩擦が生まれる
- 国際手続きが必要
- 即時停止が難しい場合もある
つまりリスクの種類が違う。
国内は「速く止まる」。
国外は「外交を経由する」。
どちらが安全かは、事業モデルによる。
3.5 跳ねっ返り勢力なのか？
Supabase利用者の大半は政治思想で選んでいない。
選択基準は：
- 速い
- 安い
- SQLが使える
- ロックインが弱い
合理性だ。
だが結果として、
国家の統制が直接届きにくい構造
を持つことはある。
意図ではなく、構造がそうなる。
ここを誤読すると陰謀論になる。
3.6 タックスヘブン仮説
「巨大インターネット企業が国外に逃げるのを恐れているのでは？」
これはあり得る仮説だが、現時点では直接的証拠はない。
ただし事実として、
- 売上は国内
- データは国外
- 利益は国外法人
という構造は、各国政府が警戒している。
これはSupabase固有の問題ではない。
グローバルSaaS全般の構造問題だ。
3.7 本質
公式SaaSを使う理由は政治ではない。
初速の速さと、出口の自由。
この二つが共存しているからだ。
- 今は楽をする
- いつでも出られる
このバランスが評価されている。
第4章 2次元一辺倒からSQL回帰へ
ここ数年、バックエンドの主流は「手軽さ」だった。
Firebaseに代表されるドキュメント指向モデル、
JSONベースのNoSQL、
“テーブルらしきもの”はあるが、JOINはない世界。
いわば、2次元の拡張だ。
配列とキー、
フラットな構造、
ネストで逃げる設計。
それは確かに速かった。
小さなアプリは短時間で作れた。
だが、その世界には限界があった。
4.1 NoSQLの黄金期とその副作用
NoSQLの強みはシンプルさだ。
- スキーマ不要
- 柔軟なデータ構造
- 即時スケール
しかし柔軟さは、やがて曖昧さになる。
- データ整合性がアプリ側依存
- 複雑な関連を持つと破綻
- クエリが肥大化
- ビジネスロジックがフロントに漏れ出す
最初は速い。
だがプロジェクトが育つほど、複雑さが滲み出る。
4.2 AI時代に再評価される「構造」
AIが普及すると、状況が変わる。
AIは曖昧なデータも扱えるが、
構造化されたデータの方が圧倒的に強い。
- JOINで意味関係を明示できる
- VIEWで意図を定義できる
- FUNCTIONでロジックを閉じ込められる
- 権限をDB側で管理できる
これは単なる古典回帰ではない。
データの「意味」を機械が扱う時代に、
意味構造を明示できるSQLは再評価される。
4.3 Supabaseが刺さる理由
Supabaseが支持を集めた背景には、この文脈がある。
- クラウドの速さ
- PostgreSQLの構造
- API自動生成
- 認証統合
つまり、
“楽”と“構造”の両立
Firebaseは楽だが、構造は弱い。
従来のRDBMSは構造は強いが、初速が遅い。
Supabaseはその中間を狙っている。
4.4 SQLは古いのか？
SQLは半世紀近い歴史を持つ。
だがそれは「古い」のではなく、
「淘汰を生き延びた」という意味だ。
- トランザクション
- ACID
- 正規化
- インデックス
- クエリ最適化
これらは流行ではなく、基盤技術だ。
JSONブームがあっても、
裏で支えているのはRDBであることが多い。
クラウドが変わっても、
ストレージが変わっても、
最終的に残るのは構造。
4.5 2Dの限界と、再構築の時代
「テーブルっぽいJSON」は便利だ。
だが本質は2Dの拡張だ。
関連はコード側に押し出される。
それは短距離走には向くが、
長距離には向かない。
AI、分析、業務ロジック、権限制御。
これらを扱うには、構造の重みが必要になる。
SQL回帰は懐古ではない。
複雑さを扱うための必然。
その文脈で、Supabaseの位置づけは明確になる。
クラウドであることよりも、
PostgreSQLであることが本体なのだ。
第5章 亡命可能なSaaSという設計思想
今回の件が示したのは、
クラウドが突然止まり得るという現実だ。
では、その時に問われるのは何か。
それは「どれだけ楽か」ではない。
どれだけ出られるか
だ。
5.1 ロックイン型SaaSとの決定的な違い
SaaSには二種類ある。
囲い込み型と持ち出し可能型だ。
囲い込み型は、
- 独自データ構造
- 独自API
- 移行困難
- エコシステム内完結
一度入れば便利だが、
外に出るときは再設計になる。
一方、Supabaseは本質的にPostgreSQLだ。
- 標準SQL
- dump可能
- 他社VPSへ移行可能
- 自己ホスト可能
これは偶然ではない。
設計思想の差だ。
5.2 なぜ「逃げられる設計」が安心になるのか
クラウドは便利だ。
だが便利さは、依存でもある。
DNSが止まる。
リージョンが止まる。
法令が変わる。
政治が変わる。
そのとき、
- データを持ち出せるか
- 同じ構造で再構築できるか
- 別リージョンに移せるか
これが生死を分ける。
PostgreSQLは、世界中にある。
だから持ち帰れる。
5.3 SaaSは悪か？
ここで誤解してはいけない。
自己ホスト至上主義ではない。
公式SaaSには意味がある。
- 初速が速い
- 運用コストが低い
- 冗長化が最初からある
- セキュリティが一定水準ある
問題はSaaSであることではない。
ロックインされること
だ。
Supabaseはこの点で中間解を提示している。
クラウドだが、出口がある。
5.4 規制時代のインフラ設計
今回のようなケースが示すのは、
- インフラは政治対象になる
- 接続は制御可能
- グローバルSaaSも不可侵ではない
という現実だ。
だから今後の設計は二層化する。
第一層：
スピードと市場投入のためのクラウド
第二層：
持ち帰り可能な構造
この二層を持たないと、
クラウドはリスクになる。
5.5 SQLが持つ“主権”
SQLの強みは機能ではない。
互換性だ。
- どこでも動く
- ツールが豊富
- 人材がいる
- 歴史が長い
それは主権に近い。
クラウドが借り物であっても、
データ構造が標準であれば、
主体性は保てる。
5.6 結論：クラウドの時代は終わらないが、無警戒ではいられない
Supabaseの遮断は、
一企業の問題ではない。
それは次の問いを投げかける。
- 自分のバックエンドは誰の支配下にあるのか
- データはどこにあるのか
- 出口は確保されているか
クラウドは消えない。
だが、設計思想は変わる。
クラウドは借りる。
構造は自分のものにする。
それが、規制時代の現実的な答えになる。
第6章 インフラは主権に触れる
Supabaseの遮断は、単なる技術トラブルではない。
それは、
インフラが国家の境界に触れた瞬間
でもある。
6.1 コンテンツ規制の時代から接続規制の時代へ
かつての規制はコンテンツ中心だった。
- 投稿を削除する
- アプリをストアから消す
- ドメインをブロックする
対象は「表面」だった。
しかし基盤を止めるという行為は違う。
止まるのは投稿ではない。
止まるのはログイン。
止まるのはデータ書き込み。
止まるのはAPI。
つまり、
経済活動の神経系
に触れる。
規制の対象がコンテンツから接続へ移るとき、
議論の次元も変わる。
6.2 データは国境を越えるが、法は越えない
クラウドの前提は越境だ。
- データはグローバルリージョンへ
- APIは世界に公開
- ユーザーは多国籍
だが法は国境単位で存在する。
ここに摩擦が生まれる。
売上は国内で発生する。
ユーザーデータは国外にある。
利益は海外法人に流れる。
政府から見れば、
統制と徴税の可視性が薄れる。
これはSupabase固有の問題ではない。
グローバルSaaS全体の構造だ。
6.3 無料×即時×匿名の緊張
Supabaseの強みは、
- 無料プラン
- 即時API生成
- 数分でバックエンド完成
だ。
しかし同時に、
- 誰が何を立ち上げたか追いにくい
- 一時的プロジェクトが大量発生し得る
- データが高速で移動する
という性質も持つ。
国家が警戒するのはコンテンツではなく、
制御不能な速度
であることが多い。
6.4 DNSで止められるという現実
今回の遮断は、完全な技術封鎖ではない可能性がある。
だが重要なのはそこではない。
DNSという“蛇口”を握る側が、
止める意思を持てば止められる
という事実だ。
インフラの最上流を誰が持つのか。
それは常に国家だ。
クラウドは国家の上位レイヤーにあるが、
ネットワークは国家の内側にある。
この力関係は変わらない。
6.5 開発者にとっての意味
この現実は、開発者に何を意味するのか。
- SaaSは絶対ではない
- DNSは単一障害点になり得る
- 接続は政策の対象になる
だからこそ、
- データの持ち出し可能性
- 標準互換性
- 多層設計
が重要になる。
技術の話に戻ると、
PostgreSQLという標準は防御になる。
なぜなら、どこでも再構築できるからだ。
6.6 主権と構造
国家は主権を守ろうとする。
企業は市場を広げようとする。
開発者は速度を求める。
この三者が交差する地点が、
バックエンド基盤だ。
Supabaseの件は、その交差点で火花が散った一例に過ぎない。
だが象徴的だ。
6.7 結語
クラウドの時代は終わらない。
だが、
インフラは政治から自由ではない。
この前提を持たない設計は、
いずれどこかで揺さぶられる。
だから今、問われているのは利便性ではない。
- 出口はあるか
- 構造は標準か
- 接続が切れても再建できるか
それが規制時代のバックエンド設計だ。
最終章 規制時代のバックエンド設計
クラウドを否定する話ではない。
問題は、
無警戒な依存
だ。
今回の件が示したのは、
「止まる可能性は常にある」という当たり前の事実だ。
では、どう設計するか。
1. データの可搬性を前提にする
最初に確認すべきは、
- dumpは定期取得しているか
- 自動バックアップは外部保存しているか
- 復元テストをしているか
バックアップは取得していても、
復元検証をしていないケースは多い。
“取っている”と“戻せる”は違う。
特にPostgreSQLなら、
- pg_dump
- WALアーカイブ
- 外部オブジェクトストレージ
を組み合わせる。
重要なのは、
別リージョン、別ベンダー、別VPSに戻せるか
だ。
2. DNSを単一障害点にしない
DNSは便利だが、
最上流でもある。
- 複数DNS運用
- フェイルオーバー設計
- セカンダリドメイン
などを考える。
完全な防御は難しいが、
1点依存を減らす
ことはできる。
3. クラウドと自己ホストの二層構造
現実的な解は極端ではない。
第一層：
公式SaaSで初速を出す
第二層：
自己ホスト可能な構造を持つ
Supabaseはこの設計が可能だ。
- 今は公式
- いざとなればVPS
- 最終保険は自宅サーバー
思想ではなく、保険だ。
4. 標準技術を選ぶ
標準であることは強い。
- PostgreSQL
- 標準SQL
- オープンソース
- 広く使われているプロトコル
独自APIは便利だが、
非常時には足枷になる。
構造が標準なら、
移植は可能だ。
5. ローカルという最終防衛線
すべてをローカルに戻す必要はない。
だが、
- 検証環境
- 予備バックアップ環境
- 最低限の復旧環境
をローカルに持つことは、
心理的にも技術的にも意味がある。
クラウドは消えない。
しかし、
ローカルは消えない。
この二層構造が安定を生む。
6. 現実的な結論
Supabaseの遮断は、
「使うな」というメッセージではない。
それは、
使うなら設計せよ
という現実の提示だ。
クラウドは借りる。
構造は持つ。
データは持ち出せるようにする。
そして、
いつでも再建できる状態にしておく。
これが規制時代のバックエンド戦略になる。
参照
- TechCrunch
India disrupts access to popular developer platform Supabase with blocking order
https://techcrunch.com/2026/02/27/india-disrupts-access-to-popular-developer-platform-supabase-with-blocking-order/ - Mezhа
Supabase blocked in India under IT Act 69A causes access disruption
https://mezha.net/eng/bukvy/supabase-blocked-in-india-under-it-act-69a-causes-access-disruption/ - Supabase 公式サイト
https://supabase.com/ - Information Technology Act, 2000 – Section 69A（インド政府法令）
https://www.meity.gov.in/static/uploads/2024/10/1d131885a32a55ddd3a91c5e93d373af.pdf
