周辺アドオン・ミドルウェア層(Periphery Add-on Layer)

## 抽象形 海外モデルの本体(プラットフォーム・免許・大規模インフラ)は個人には作れない。しかし本体が持つ「機能の一部」だけを、既存の国内インフラに後付けする軽量レイヤーとして提供することはできる。本体を丸ごと輸入しようとせず、機能を分解して「今すぐ作れる一片」だけを切り出すのがこのメカニズムの核心。cases-forward/52件のうち過半数がこのパターンの smb_angle を持つ ── これは第2弾で最も反復頻度の高いメカニズムである。 ## 大資本での実例 - periphery/p-ec-rakuten-agency.md: 楽天・Amazon という本体プラットフォームの周辺で、出店代行・運営代行という「後付けサービス層」が個人・中小の主戦場になった(ただし2010年代半ばで飽和・window closed) - localization-patterns.md 1-6(SMB向け軽量版): フル機能の海外エンタープライズ版に対し機能を絞った安価な国産代替が SMB 層を取る、と同型 ## 個人・スモールでの実例 - fw-clio-solo-lawyer-saas.md: 統合法律事務所SaaS本体は作らず、既存の低価格・単機能ツール(loioz/Armana)に「依頼者向けポータル+決済リンク+書類自動化」だけを後付けするアドオンSaaSとして参入 - fw-lili-self-employed-banking.md: 銀行免許は取れないが、既存の口座API連携+会計SaaSの上に「税金積立の自動振替」だけを乗せるミドルウェアは個人開発でも作れる - fw-fourthwall-creator-commerce.md: 統合基盤をゼロから作らず、既存の分散サービス(SUZURI・Ci-en・OFUSE)を束ねる薄い連携レイヤー(リンクページ+決済ハブ+運用代行)を提供する側に回る - ai-wrapper-micro-saas.md: LLM APIという「本体」の上に薄いUIを乗せるという構造自体がこのメカニズムの技術版(ただし ai-double-edge.md 参照 ── モート不在という弱点も同時に持つ) ## 検知シグナル - 候補モデルの本体機能が「免許・大規模資本・独自ハードウェア」に依存している - 一方で、その機能の一部(通知・可視化・連携・簡易版UI)だけなら既存の国内インフラに接続する形で実装できる - 国内に「本体は無いが、隣接する低価格・単機能ツールは複数存在する」状態(乱立している = 統合レイヤーへの需要がある兆候) ## 個人スケールでの行動 1. 候補モデルの機能を分解し、「免許・資本が要る部分」と「ソフトウェアだけで完結する部分」を切り分ける 2. 後者だけを、国内の既存プレイヤー(会計SaaS・決済・EC基盤等)に接続する形で最小実装する 3. 本体機能を持つ大手・海外企業自身が同じアドオンを内製化するリスクを前提に置く(fw-fourthwall-creator-commerce.md が明記する通り、この種の「空白」は大手が本気を出せば数ヶ月〜1年で埋まりうる)。先行者利益は短命前提で、次の周辺機会への乗り換えを設計しておく