Blog

検閲のない非公式LLM APIについて考えてみた

Published · Jul 10, 2026

Topics

llm

security

opensource

ai安全性

はじめに

「検閲のないLLM」や「uncensored API」をうたう非公式サービスは、今後どこまで広がり、どの程度残り続けるのでしょうか。

この記事を書く直接のきっかけは、Claude CodeでClaude Fable 5を使い、自分の個人プロジェクトに対してセキュリティレビューを実行した経験です。

Claude Codeには、プロジェクト内で/security-reviewを実行すると、コードベースを分析して潜在的な脆弱性を探す自動セキュリティレビュー機能があります。私がレビューしていたのは第三者のシステムではなく、自分が開発しているプロジェクトであり、目的も脆弱性の発見と修正でした。

しかし実際には、私の環境ではレビュー中にサイバーセキュリティ向けの安全策が反応し、Fable 5からClaude Opus 4.8へ自動的にフォールバックする挙動が頻発しました。利用者の側から見れば、作業途中で意図しないモデルへ切り替わる状態です。私の意図と対象に照らすと、正当な防御目的の作業が危険な要求として扱われた誤検知と思われるケースが多くありました。

このフォールバック自体は、Anthropicが公開している仕様です。モデルが自動的に切り替わる理由についての説明によれば、Fable 5はすべての要求に安全チェックを行い、最新の入力だけでなく、モデルが読むファイルやメモリなども判定対象にします。サイバーセキュリティの通常作業でも高いフォールバック率が見込まれ、既定設定では、検知された要求の多くがOpus 4.8で再実行されます。自動切り替えは設定で無効化できますが、その場合は検知された時点で処理が止まります。なお、APIでは自動切り替えを利用者側で明示的に設定する必要があります。

さらにFable 5のサイバー安全策に関する説明では、有害な要求を取りこぼさないため安全マージンを広く設定しており、その範囲には無害な利用も含まれるため、誤検知が増えることを明記しています。つまり、私が体験した摩擦は、安全性を優先した意図的な設計トレードオフの一部でもあります。

そこで私は、正当なセキュリティレビューを途中で止められにくく、拒否やモデル変更の少ないモデルや実行環境を調べ始めました。出発点は、攻撃用途に制約のないモデルが欲しかったからではありません。自分のコードを防御目的で調べる作業を、同じモデルで最後まで継続したかったからです。

このような体験があると、「拒否されにくいLLM」に魅力を感じる理由はよく分かります。一方で、正当な利用者にとって摩擦の少ないモデルは、悪意ある利用者にとっても摩擦が少ないというデュアルユースの問題に行き着きます。

この記事では、次の問いを順に考えます。

「検閲のない」「非公式」とは、具体的に何を指すのか
なぜ公開重みモデルから、そのようなAPIを作れるのか
API化によって、利便性と悪用リスクはどう変わるのか
正規のSaaSとして成功しなくても、なぜサービス群が残り得るのか
利用者、開発者、政策側はどう向き合うべきか

先に結論を述べると、私の見立ては次の通りです。

高性能な公開重みモデルが普及するほど、回答拒否を弱めた派生モデルを作り、周辺の利用制限も少ない非公式APIとして再提供しやすくなる。個々のサービスは不安定でも、停止と再出現を繰り返すサービス群として残る可能性は、脅威モデルに含める必要がある。

「検閲のない非公式LLM API」とは何か

タイトルの「検閲のない」は、uncensoredやno-refusalを掲げるモデルやサービスを日本語で分かりやすく表したものです。ただし、ここでいう「検閲」は厳密な技術用語ではありません。国家による検閲を指しているわけでも、あらゆる制御が本当に存在しないと保証する表現でもありません。

LLMサービスの制限には、少なくとも次の層があります。

モデル自体が回答を拒否する傾向
入出力を判定する安全分類器やフィルタ
利用規約、本人確認、レート制限、アカウント停止
エージェントや外部ツールに与える権限

「検閲のない」と称するサービスが、このすべてを取り除いているとは限りません。単に拒否が少ないモデルを使っている場合もあれば、周辺のフィルタや監視を弱めている場合もあります。そのため、技術的な説明では、モデルの振る舞いとAPI運用上の制限を分けたうえで、低ガードという表現を使います。

また、この記事でいう「非公式API」は、元のモデル開発者が直接提供・推奨しているのではなく、第三者が運営するAPIを指します。非公式であること自体が、直ちに違法・悪質という意味ではありません。この記事が主に対象とするのは、その中でも公開重みモデルを利用し、拒否や利用制限の少なさを売りにするサービスです。非公開モデルの認証情報を不正利用するリバースプロキシなどは対象にしません。

用語	この記事での意味
公開重みモデル	モデルの重みを取得し、第三者が実行・改変できるモデル
低ガードモデル	追加学習や重み編集などによって、回答拒否の傾向を弱めたモデル
低ガードAPI	モデルの拒否傾向に加え、入出力フィルタやアカウント制限なども比較的弱いAPIサービス
非公式API	元のモデル開発者ではない第三者が運営するAPI
地下・半地下型	正規市場の信用や安定性より、停止後の移転・再出現を重視する運用形態

「OSS」と「公開重み」は同じではない

この記事では、原則として「OSSモデル」ではなく、公開重みモデル（open-weight model） という表現を使います。モデルの重みを取得して実行・改変できることと、オープンソースの条件を満たすことは同じではないためです。Open Source InitiativeのOpen Source AI Definitionは、適切なライセンスのもとで、学習・改変に必要な十分な情報とコード、パラメータなどが提供されることを求めています。

また、低ガード化とは、モデルから「安全性」という独立部品だけをきれいに取り外すことでもありません。拒否率が下がることと、モデルの危険能力が上がることも同じではありません。

より正確には、事後学習や推論設定によって形成された振る舞いの一部を、追加学習や重み・推論コードへの介入によって変えられる場合がある、という意味で使います。

なぜ今、この問題を考える必要があるのか

International AI Safety Report 2026は、主要ベンチマーク上で公開重みモデルと非公開モデルの性能差が縮まり、最先端の非公開モデルのリードは1年未満と推定されると整理しています。

これは、公開重みモデルがあらゆる危険領域で直ちに最先端へ到達した、という意味ではありません。一般能力のベンチマークと、現実の悪用能力は別だからです。

それでも、非公開モデルで先に現れた能力が、時間をおいて改変可能な重みとして広く流通する可能性を示しています。公開重みモデルの性能が上がるほど、「配布時点の安全調整」だけでなく、「第三者が改変し、ツールと接続し、再提供した後」のリスクが重要になります。

モデルが知識を持つことと、現実の被害は同じではない

事前学習データはモデルごとに異なり、その全容が公開されるとは限りません。ただし、Llama 3の技術報告やQwen2.5の技術報告では、一般知識に加えて、コード、数学、科学・技術などを含む大規模な多分野コーパスが使われたと説明されています。そのため、汎用モデルは幅広いデュアルユース知識を持ち得ます。

領域	モデルが支援し得ること	実害までの主な追加条件
サイバー	コード理解、設定分析、既知の脆弱性や攻撃・防御概念の説明	対象環境、実行権限、ツール、検証、反復試行
生物・化学	論文や安全資料の整理、一般的なプロトコルの理解	設備、材料、技能、実験検証、安全管理
兵器・工学	物理、材料、歴史、工学的な設計原理の説明	製造設備、部品、試験、専門知識、現実の調達

したがって、危険領域の質問に答えられることを、そのまま「高度な攻撃や兵器開発ができる」と読み替えるべきではありません。知識、課題遂行能力、現実の被害の間には大きな隔たりがあります。

一方で、サイバー領域は、本稿で挙げた物理設備を必要とする領域に比べて実害へつながりやすいと考えています。作業対象、ツール、成果物、検証環境がすべてデジタルで完結しやすく、コード実行と反復試行を自動化しやすいからです。

ただし、ここにも限界があります。International AI Safety Report 2026は、AIがサイバー攻撃の複数工程を支援・自動化し始めている一方、完全自律のエンドツーエンド攻撃が確認されたわけではないと整理しています。

重要なのは「現時点ですでに万能な攻撃者である」という断定ではなく、モデル、ツール接続、コード実行、反復ループが組み合わさるほど、人間に必要だった時間や技能の一部が圧縮されるという方向性です。ICML 2025で発表されたEnIGMAの評価でも、対話的なツールを与えることで、LLMエージェントのCTF課題における性能が大きく改善したと報告されています。

ガードは誰が管理するのか

大手事業者が管理するAPIでは、モデル本体に加えて複数の安全レイヤーを組み合わせられます。実際の構成は事業者やサービスによって異なりますが、International AI Safety Report 2026が説明する多層防御の考え方を踏まえて整理すると、たとえば次のような構成です。

利用者・アカウント管理
        ↓
入力分類・不正利用検知
        ↓
安全調整されたモデル
        ↓
出力分類・フィルタ
        ↓
レート制限・ログ・停止対応

このような多層防御なら、ひとつの安全策が破られても、別の層で検知・遮断できる可能性があります。問題が起きた後に、アカウント停止、モデル更新、ルール変更を行うこともできます。

ここで、公開重みモデルを自己ホストする人と、第三者APIを使う人は分けて考える必要があります。自己ホストでは利用者自身が推論環境を管理できます。一方、非公式APIでは、元の開発者が設計した安全策がそのまま保たれる保証はなく、最終的な管理権はAPI運営者が持ちます。

観点	公式の管理API	第三者の低ガードAPI	公開重みの自己ホスト
モデルの更新	モデル開発者	API運営者	利用者
システムプロンプト	モデル開発者	API運営者	利用者
入出力フィルタ	モデル開発者	API運営者	利用者
追加学習・推論コード	モデル開発者	モデル配布者やAPI運営者	利用者
ログと利用制限	モデル開発者	API運営者	利用者の構成次第
問題発生後の停止	公式APIを停止できる	API運営者や上流事業者が停止できる	配布済みコピーの回収は難しい

International AI Safety Report 2026も、公開重みモデルは安全策を除去しやすく、管理外の環境で利用でき、一度公開された重みを回収できない点を固有の課題として挙げています。

米国NTIAの公開重みを持つデュアルユース基盤モデルに関する報告書も、重みへ直接アクセスできる場合、コンテンツフィルタなどの安全策をより容易に回避・除去できる可能性を指摘しています。

つまり、「検閲のないAPI」の本質は、すべてのガードが消えることではなく、誰が各レイヤーを管理するかが変わることにあります。公開重みの安全性を考えるときも、「配布時点で拒否するか」だけでは不十分です。第三者が改変・再提供した後に、どの安全上の性質が残り、誰が利用を監督できるのかまで評価する必要があります。

拒否傾向は実用上弱められる場合がある

公開重みモデルの安全調整は、単純なオン・オフスイッチではありません。事後学習による重みの更新を通じて、安全な応答や拒否の傾向が内部表現に形成されています。

しかし、重みにアクセスできれば、その傾向への介入も可能になります。

Refusal in Language Models Is Mediated by a Single Directionは、複数の公開モデルを対象に、特定の活性化方向へ介入することで有害な要求への拒否を大きく弱められると報告しました。別の研究であるFine-Tuning Aligned Language Models Compromises Safety, Even When Users Do Not Intend To!も、追加のファインチューニングが安全性を損なう可能性を示しています。

これらの研究から「すべての安全性はひとつの方向だけで決まる」と一般化することはできません。安全性と拒否は同義ではなく、モデルや評価方法によって結果も変わります。

それでも、現在の安全調整が改変に対して完全に耐性を持つわけではない、という点は重要です。OpenAIによる公開重みモデルの最悪ケース評価では、gpt-oss-120bに回答拒否を減らす強化学習を施したところ、評価用の有害な要求に対する拒否率がほぼゼロになりました。一方、その改変モデルが既存の最先端モデルを大幅に超える危険能力を得たわけではないことも報告されています。

このため、安全策が追加学習にどこまで耐えるかを評価する研究や、改変耐性の高い安全策を設計する研究も進んでいます。

また、モデル共有コミュニティでは以前から、uncensored、no-refusal、abliteratedなどを名乗る派生モデルや、安全調整（alignment）を弱めたと説明するモデル群が公開されてきました。たとえば、Dolphin 2.9 Llama 3 8BやLlama 3 8B Instruct Abliteratedのモデルカードには、その方針が明記されています。

もちろん、モデル名やモデルカードの自己申告は、安全性や危険能力の実証ではありません。しかし、低ガード化を目的とした改変と再配布が、将来の仮説ではなく、すでに存在する行動類型であることは確認できます。

非公式APIになると何が変わるのか

ローカルで大規模モデルを動かすには、計算資源、量子化、推論ランタイム、モデル管理、障害対応などが必要です。この摩擦は、利用できる人を自然に絞ります。

ところが、誰かが推論環境をまとめてAPIとして提供すると、利用者側の負担は大きく下がります。

公開重みモデル
      ↓
第三者によるモデル・推論設定の変更
      ↓
運営者が管理する安全レイヤーと汎用API
      ↓
チャットUI・ボット・エージェント・自動化ツール

特に既存の開発ツールと互換性のあるAPIであれば、チャットUI、コーディングエージェント、スクリプト、ブラウザ自動化などへ接続しやすくなります。実際、Hugging Face Text Generation Inferenceのような公開モデル向け推論基盤も、OpenAI Chat Completions APIと互換性のあるエンドポイントを提供しています。

ここで増えるのは、単発の質問に対する回答だけではありません。

反復処理へ組み込める
複数利用者で共有できる
他のツールやデータ源と接続できる
モデル運用の知識がない利用者もアクセスできる
人間の確認を減らしたワークフローを作りやすい

この意味で、低ガードモデルのAPI化は、危険能力そのものを新しく作るというより、既存能力の流通コストと利用障壁を下げる働きをします。

一方で、API提供者という集中点が生まれることは、防御側にとっての手掛かりでもあります。ローカルで完全に分散したコピーと比べて、サーバーやネットワークに加え、運用形態によっては決済や利用者管理といった観測・遮断が可能な集中点（チョークポイント）が生じるからです。

利用者にとっての魅力とリスク

私が調べ始めた理由のように、拒否の少ないAPIには正当な需要もあります。防御目的のセキュリティ調査、機微なテーマを扱う研究、創作、再現性が必要な自動処理では、誤検知による中断が少ないこと自体が価値になります。大きなモデルを自分で運用せず、既存ツールから同じAPI形式で使える点も便利です。

しかし、公式APIのガードを避けるために、運営実態の分からないAPIへ移るなら、別のリスクを引き受けることになります。

リスク	利用者側で起こり得ること
データの扱い	ソースコード、会話、認証情報が保存・再利用されたり、漏えいしたりする
モデルの真正性	表示されたモデル名や改変内容が実態と一致するか検証しにくい
出力の信頼性	拒否が少なくても、正確性や安全性が高いとは限らない
サービス継続性	突然の停止、価格変更、モデル差し替えが起こり得る
APIキーと決済	認証情報や支払い情報を未知の運営者へ渡すことになる
ツール連携	エージェントへ強い権限を与えると、誤操作や有害な出力がそのまま実行され得る

特に、自分のコードを守るためのセキュリティレビューで、未公開コードや秘密情報を信頼できないAPIへ送ってしまえば本末転倒です。利用するなら、運営主体、利用規約、モデルの出所、ログの保存期間、学習への利用、削除方針を確認し、秘密情報を送らない設計にする必要があります。ツール連携では、最小権限、サンドボックス、利用上限、人間による実行承認も欠かせません。

拒否が少ないことは、性能が高いことでも、安心してデータを預けられることでもありません。 自由度と信頼性は別の軸として評価すべきです。

非公式APIをすべて地下サービスとはみなさない

第三者が提供するAPIには幅があります。ライセンスに従って公開モデルをホスティングし、企業や開発者へ提供する事業もあれば、運営実態や規約との適合性が不明なサービス、違法な用途を積極的に支える高リスクなサービスもあり得ます。

類型	主な特徴
正規の第三者ホスティング	モデルのライセンスや法令に従い、一般用途向けに運営する
適合性が不透明なサービス	モデルの出所、運営者、データ方針、上流規約との関係を確認しにくい
地下・半地下型の高リスクサービス	正規市場の信用より、制限の回避や停止後の移転を優先する

どの類型に当たるか、運営が適法かどうかは、モデルのライセンス、提供地域、利用目的、各国の法令によって変わります。「非公式」や「低ガード」というだけで、一括して地下サービスとみなすべきではありません。

そのうえで、この記事では最後の類型がどのように残り得るかも考えます。

私は当初、高リスクな低ガードLLM APIは長期継続しにくいと考えていました。通常のSaaSとして見ると、弱点が多いからです。

クラウド事業者や決済事業者の審査を受ける
高リスク用途によって評判が悪化する
法人顧客や提携先を得にくい
SLA（サービスレベル合意）を満たす安定性を維持する必要がある
不正利用によって推論費用が膨らむ
規制や法執行の対象になり得る

しかし、これは表の信用と継続契約を目指す事業者を前提にした評価でした。地下・半地下型では、同じ制約の重みが変わります。

評価軸	正規SaaS	地下・半地下型
信用	法人信用、評判、継続契約が重要	限定された市場内の信用でも成立し得る
決済	正規の決済網への依存が大きい	正規経路への依存を下げる動機が強い
品質	SLA、低遅延、サポートが要求される	顧客層によっては低品質も許容される
モデル開発	独自性能と継続投資が必要	公開モデルへの追随が中心になり得る
費用回収	後払い、返金、不正利用による赤字が問題になる	前払いと利用上限で一部を抑えられる
停止	ブランドやドメインの喪失が重大	移転や再出現を前提にし得る

これは地下型サービスが安定した優良ビジネスになる、という意味ではありません。詐欺、障害、摘発、顧客離反が多い不安定な市場になり得ます。

それでも、ひとつの事業者が長く存続する必要はないという点が重要です。あるサービスが止まっても、モデルの重みと需要が残っていれば、別の主体が似たサービスを再び立ち上げる可能性があります。

なぜ高リスクな非公式APIは残り得るのか

停止と移転を繰り返す構造は、海賊版コンテンツ配布サイトや高リスクなネットワークサービスと似ています。実際、Europolが公表したbulletproof hostingの摘発事例では、通常の事業者が拒む利用者を受け入れるインフラが、複数のサイバー犯罪を支えていました。

ただし、LLM APIはファイル配布と同じではありません。リクエストごとに推論費用がかかり、GPU、電力、冷却、回線、保守要員を継続的に必要とするからです。

残り得る条件	同時に働く制約
公開された重みを複製・再利用できる	推論のたびに計算費用が発生する
標準的なAPIによって開発・利用の負担を下げられる	GPU、電力、回線、保守が必要になる
量子化、小型モデル、バッチングなどで費用を下げられる	能力低下や遅延を伴う場合がある
低速・不安定でも受け入れる利用者が存在し得る	信用不足、障害、詐欺によって顧客を失いやすい
ひとつの運営者が止まっても別の主体が再提供できる	上流事業者、物理拠点、法執行が停止要因になる

たとえば、PagedAttentionは推論時のメモリ利用とスループットを改善し、AWQは低ビット量子化による高速化と省メモリ化を報告しています。MoE、共通する接頭辞のキャッシュ、推論ランタイムの最適化も、構成や負荷によっては費用を下げる方向に働きます。一方、量子化や小型化が常に元モデルと同じ能力を保つわけではありません。

API運営では巨大な事前学習をやり直す必要はなく、既存モデルの推論が中心になります。そのため、計算資源は「市場を小さくする参入障壁」にはなっても、「存在を完全に防ぐ壁」になるとは限りません。同時に、大規模に運用するほど設備や電力に物理的な足跡が残るため、防御側から見ればチョークポイントにもなります。

また、高リスクな市場では、モデルを起動する技術だけでなく、設備と回線の維持、障害対応、原価管理、限定された市場内での信用、停止後の復旧といった運用能力が差になります。これは大規模市場として実証された結論ではなく、既存の地下サービスとの構造比較から導く仮説です。

個々のサービスは依然として止まりやすい

地下・半地下型を前提にしても、運営上の制約が消えるわけではありません。

停止要因	内容
重大事件との関連	大規模な被害に使われれば、捜査や制裁の優先度が上がる
物理拠点・上流インフラ	設備の発見や、ISP・ホスティング・名前解決からの遮断が起こり得る
法執行・制裁	国際捜査、資産凍結、関係者の摘発対象になり得る
内部者・顧客	情報提供者、詐欺客、競合が入り込みやすい
妨害	同業者や敵対者からDDoSなどの攻撃を受けやすい
収益の換金	暗号資産を使っても、実体経済との接点にリスクが残る

想定すべき持続シナリオは、「ひとつの巨大サービスが何年も安定運営される」より、「小規模なサービスが停止、移転、招待制への移行、再出現を繰り返す」に近いと考えています。

この分析で分かること、分からないこと

まず、公開資料と研究から直接確認できることがあります。

公開された重みの全コピーを後から回収することは難しい
重みと推論環境へのアクセスがあれば、安全策を改変しやすい
標準的なAPIは、モデル運用の負担を提供者側へ集約できる
LLMの継続的な推論には、計算設備、電力、ネットワークが必要になる

そこから、次のように構造的に推論できます。

API化によって、ローカル運用できない利用者の利用障壁も下がり得る
正規SaaSの停止要因が、地下型でも同じ強さで働くとは限らない
推論インフラは、参入障壁であると同時に防御側のチョークポイントになる
ひとつの運営主体を止めても、同種サービスが別の主体から再出現し得る

一方で、次のことはまだ分かりません。

低ガードAPI市場がどの程度の規模になるのか
利用者が継続的に料金を払うのか
低ガードモデルへの安価なAPIアクセスが、現実の重大被害にどこまで寄与するのか
国際的な法執行やインフラ規制がどの程度有効になるのか
改変耐性を高める安全技術が、実環境での適応的な攻撃にどこまで耐えられるのか

したがって、この記事の結論は市場予測ではなく、無視できない持続シナリオの提示です。「必ず巨大化する」でも「完全に根絶できないと証明された」でもありません。

では、どう向き合えばよいのか

公開重みモデルには、外部研究者による監査、ローカル環境での利用、プライバシー保護、教育、競争促進といった利益があります。そのため、「公開モデルは禁止すべきだ」という一行の結論では不十分です。

米国NTIAも2024年の報告書で、当時の証拠だけでは公開重みを一律に制限すべきとも、将来にわたって制限が不要とも断定できないとして、継続的な証拠収集と評価を提言しました。

利用者側では、拒否の少なさとは別に、API運営者の信頼性とデータ処理方針を評価する必要があります。モデル開発者や政策側も、一度広く配布された重みを回収できない以上、公開後の利用規約やモデルカードだけに依存することはできません。必要になるのは、複数層での対策です。

1. 公開前に能力と改変耐性を評価する

通常の有害出力評価だけでなく、追加学習、重みへの介入、ツール接続後にも危険能力がどの程度残るかを確認する必要があります。

2. 公開方法を二択にしない

完全公開か完全非公開かだけでなく、段階公開、研究者向けアクセス、API提供、用途に応じた評価など、能力とリスクに応じた公開方法を検討できます。

3. モデルの外側も防御する

エージェントやツールとの接続時には、最小権限、サンドボックス、実行承認、監査ログを設けることが重要です。低ガードモデルが存在しても、接続先の権限まで無制限である必要はありません。

4. 公開後のチョークポイントも使う

重みを回収できなくても、重大な悪用に使われるAPIのインフラ、資金、ネットワーク、被害情報を追跡し、法に基づいて対処する余地は残ります。ここでは一度の遮断で根絶するのではなく、再出現コストを継続的に上げる発想が必要です。

5. 特にサイバー防御を強くする

サイバー領域は攻撃側と防御側が同じAI能力を利用するデュアルユース領域です。公開を抑える議論だけでなく、脆弱性修正、認証強化、最小権限、監視、インシデント共有を進め、AI支援攻撃が成功しにくい環境を作る必要があります。

おわりに

私が最初に感じた「正当なセキュリティレビューを、同じモデルで最後まで続けたい」という問題意識は、今も妥当だと思っています。安全策の誤検知は、正当な利用者の作業を止める現実的なコストだからです。

ただし、その摩擦を避けるために非公式APIへ移ると、問題がなくなるわけではありません。モデルの改変、入力の記録、ツール実行の許可、問題発生時の停止といった管理の主体が、公式事業者とは別の運営者になります。

「検閲のない非公式LLM API」の本質は、モデルが突然新しい能力を得ることではなく、安全レイヤーの管理者が変わり、既存能力へのアクセス摩擦が下がることにある。その自由度は正当利用の摩擦を減らす一方で、悪用可能性と、利用者側のデータ管理・運営者への信頼・権限管理に関するリスクも増やす。

高性能な公開重みモデルと標準的な推論基盤が広がれば、このようなAPIを作る条件は整います。個々のサービスは計算費用、上流インフラ、法執行、信用不足によって止まり得ます。それでも、重みと需要が残る限り、別の主体が似たサービスを再び提供する可能性があります。これは市場の巨大化を断定する話ではなく、停止と再出現を繰り返すシナリオを無視しない、という話です。

だからこそ、「検閲があるか、ないか」だけでLLM APIを選ぶべきではありません。どのレイヤーを誰が管理しているのか、何のデータを預けるのか、どのツール権限を渡すのかまで含めて判断する必要があると考えています。