AI 時代の配信経路・プラットフォーム経済・エージェント委任
最終更新: 2026-08-02
価格、手数料、掲載条件、広告対象、プロトコル、法令解釈は変わる。この章の数値は 2026-08-02 時点の一次情報に基づく比較用スナップショットであり、実装・出稿・申請・契約の直前に再確認する。法的な記述は一般的な設計論であって、個別案件への法律意見ではない。
AI で実装が速くなるほど、個人開発者の希少資源は次へ移る。
- 顧客の問題と例外を正しく定義する専門性
- 顧客へ繰り返し到達できる、自分が制御する販売資産
- 税、決済、返金、支援、自分の時間まで引いた完全負荷後貢献
- AI に何を読ませ、何を書かせ、どこで人が承認するかという権限設計
- 製品の宣伝、UI、契約、実際の運用で一致した責任境界
したがって、ChatGPT、App Store、Shopify 等への掲載や MCP/A2A/AP2 対応を事業そのものと考えない。それらは、既に価値と単位採算がある製品へ追加する「借りた流通・相互運用の選択肢」である。
本章は経路選択、手数料、権限、責任の判断を扱う。OpenAI Plugin Directory、Official MCP Registry、Google/Bing の AI 面、Shopify/UCP、Stripe を、eligibility から accepted outcome、履行、銀行着金、成熟後貢献まで検証する event・evidence の正本は 17 章とする。
個人開発者の基本方針は次である。
狭い顧客課題を有償で確認→ Web と直接営業で受注・提供・継続を確認→ 取引・顧客月・cohort の完全負荷後貢献と事故境界を確認→ 顧客が実際に使うプラットフォームだけ追加→ 読取、下書き、低リスク実行、送信・支払を段階的に解放観測事実と戦略的推論を分ける
Section titled “観測事実と戦略的推論を分ける”- OpenAI は 2025-08-05 に Apache 2.0 の open-weight モデル
gpt-oss-120bとgpt-oss-20bを公開した。公表値では前者は単一 80 GB GPU、後者は 16 GB メモリで動作し、両者とも 128k context と tool use を備える。OpenAI - Anthropic が 2025-10〜2026-04 の約 40 万 Claude Code セッションを分類した研究では、人が平均約 70% の計画判断を、Claude が約 80% の実行判断を担った。タスク上の初心者は verified success が 15%、intermediate 以上は 28〜33% だった。Anthropic
- 同研究の code-producing sessions では、software-related occupations とその他の職種の verified success は 34% と 29%、partial success 以上は 89% と 88% だった。
- OpenAI の 2026-07-09 App Developer Terms は、App Directory や会話内提案での掲載位置、可視性、順位、宣伝を保証せず、公開義務も置かない。外部 checkout は可能だが、取引、PSP、AML、輸出管理、制裁対応は開発者側の責任となる。OpenAI
- 同日以後、ChatGPT/Codex の発見面は App Directory から Plugin Directory へ移行した。plugin は skill、app、app template を束ね得るが、表示されても plan、workspace、role、region、基盤 app 権限によって install・接続・invoke できない場合がある。
listed ≠ installable ≠ connected ≠ invokedとして測る。OpenAI Help - 2026-08-01 時点で ChatGPT Ads Manager は日本で利用可能である。広告は Plus、Pro、Business 系プランと 18 歳未満には表示されず、CPC キャンペーンの開始時最大入札額として $3〜$5 が案内されている。提供地域 / 広告の基本
このプレイブックの推論
Section titled “このプレイブックの推論”- 実装能力の供給は増え、モデル/API/OSS の選択肢も増える。単なる「AI を付けた CRUD」は長期の差別化になりにくい。
- ただし、上記の Anthropic 調査は Claude Code の自己選択的利用者を対象に、職業・専門性・成功を classifier で推定した観察研究である。全体は CLI、Claude.ai、desktop の interactive sessions で、第三者 IDE、SDK、headless 利用を含まない。職業別分析は occupation を推定できた約 70%、success 分析は明確な目標なしと分類された約 7.7% を除く。製品の売上や長期品質も測っていないため、「専門家なら必ず成功する」ことの証拠ではない。
- より妥当な読み方は、実装の一部を agent へ移しても、問題定義、完了条件、検証、例外理解というタスク固有の専門性は残る、というものである。
- したがって元 Web エンジニアの優位は、コード量ではなく、業務担当者から例外を聞き出し、安全な仕様・計測・復旧へ変換できることに置く。
流通は一つの分類でなく、直交する台帳で持つ
Section titled “流通は一つの分類でなく、直交する台帳で持つ”次のラベルは依存の発見には有用だが、相互排他的な顧客分類ではない。一人の顧客が「検索で発見し、比較記事で納得し、Shopify へ install し、MoR で支払い、MCP から利用する」ことがある。
| 流通 | 例 | 長所 | 主な依存 | 最初に測るもの |
|---|---|---|---|---|
| 所有 | 顧客リスト、メール許諾、指名検索、導入済み連携、契約更新 | 再接触でき、学習が蓄積 | 配信同意、データ品質、信頼 | 再商談率、紹介率、更新率 |
| 獲得 | 検索、比較記事、事例、コミュニティでの評判 | 複利になり得る | 検索・推薦仕様 | ICP の有効訪問、商談化率 |
| 借用 | App Store、ChatGPT/Codex Plugin Directory、Shopify App Store、マーケットプレイス | 購入文脈と信頼を借りる | 審査、権限、順位、規約、手数料 | 掲載→install可能→接続→invoke→有償継続 |
| 有料 | 検索広告、SNS 広告、ChatGPT Ads | 速く反証できる | オークション、計測、獲得費 | 完全負荷 CAC、回収月数 |
| 提携 | 士業、業界団体、代理店、既存 SaaS、再販 | 信頼と対象リストを借りる | 利益配分、enablement、競合 | 紹介→成約、パートナー別粗利 |
| 組込 | API、MCP server、A2A、OEM | 顧客の既存業務に入る | 相手の仕様、権限、SLA | 呼出から成果まで、障害損失 |
「所有」は顧客データを好きに使えるという意味ではない。適法な目的・同意の範囲で、自社が再接触と体験改善を管理できるという意味である。
顧客または契約ごとに、少なくとも次の列を別々に持つ。
| 軸 | 値の例 | 判断すること |
|---|---|---|
| 商談起点 | 直接、検索、有料、紹介、marketplace | 最初の有効接点と獲得費 |
| assist touch | 事例、比較記事、webinar、partner | 成約を助けた接点。起点と重複可 |
| 利用面 | Web、native app、組込、API/MCP | runtime・認証・連携停止の影響 |
| 決済面 | 請求書、銀行振込、PSP、MoR、ecosystem | 契約主体、fee、税、払出し、移行 |
| 制御度 | 連絡、認証、契約、entitlement、export の各可否 | platform 停止後も維持・移行できる範囲 |
流通のポートフォリオ規則
Section titled “流通のポートフォリオ規則”初期は次を目安にする。
- 所有または直接到達の主チャネルを 1 本持つ。
- 借用プラットフォームは最大 1 本ずつ検証し、同時に増やさない。
- 対象 motion が成熟する観測期間、cohort、最小母数、依存警戒線を事前に version 固定する。一つの起点が新規商談・顧客の完全負荷後貢献を支配し、その停止 scenario が reserve と回復目標を超えるなら、代替経路を調査する。普遍的な 90 日、件数、構成比を成功法則にしない。
- 成熟母数が小さい段階では分散投資を急がず、x/n、contribution share、最大停止 exposure を表示し、
新規発見 / install・onboarding / API・認証・runtime / 課金・払出しの停止 runbook を先に用意する。 - プラットフォームから得た顧客を、規約と同意に従って onboarding、サポート、更新という自社体験へ接続する。
- CAC はクリック単価でなく、有効な有償顧客を得るまでの広告費、制作、営業、自分の時間を含める。
チャネル別完全負荷 CAC= (広告・掲載・紹介費 + 制作・営業・提案時間 × 内部時間価値) / 当該チャネル起因の有償成約数09 章の内部時間価値を使い、安価に見えるコミュニティ投稿や個別営業も時間原価へ戻す。有償成約 0 件なら 0 除算せず、CAC未定義 / 獲得費総額 / 成約0件 と記録する。導入時間、初月値引、返金は初期貢献へ入れ、CAC へ重複計上しない。
掲載は販売保証ではない
Section titled “掲載は販売保証ではない”OpenAI の App Developer Terms を一例にすると、公開申請できること、公開されること、推薦されること、売れることはすべて別である。借用チャネルは次の四段階で管理する。
| 段階 | 成功条件 | 失敗時の解釈 |
|---|---|---|
| 審査 | 公開・更新が承認される | 製品品質だけでなく規約適合の問題かもしれない |
| 発見 | ICP が掲載・推薦・広告を見る | 価値が弱いとはまだ言えない |
| 有効化 | 対象業務を完了する | メッセージ、権限、初期設定、連携の問題 |
| 収益・継続 | 支払って反復利用する | 課題頻度、価格、品質、支援、責任の問題 |
一つ前の段階を通っていないデータで次の段階を評価しない。広告クリックが少ないときに製品全体を否定せず、クリックは多いが有効化しないときに広告だけ増やさない。
実装時は四段階をさらに経路固有の required / optional / N/A stage へ分解する。published / indexed / surfaced / installed / connected / invoked / accepted / paid / fulfilled / bank-reconciled / retained の定義と最低証拠は 17 章で固定する。
ChatGPT Ads の扱い
Section titled “ChatGPT Ads の扱い”日本で利用可能でも、初期 B2B の主チャネルとは限らない。広告非表示の有料・Business 利用者があり、会話文脈に基づく新しいオークションで、長期の業界別 conversion benchmark もまだ薄い。次の条件で小さく試す。
- 既に ICP、約束する成果、価格が決まっている。
- 専用 landing page と server-side の商談・成約計測がある。
- 1 回の最大損失額と停止条件を決める。
- CTR ではなく
粗利ベース CACと 30/60/90 日継続で判定する。 - 検索広告や直接営業と同じ期間・同じ ICP で比較する。
広告の最大許容 CPC= 商談化率 × 有償成約率 × 90日実現貢献 × 許容獲得費率例として landing page→商談 4%、商談→有償 20%、90 日に実際に得る完全負荷後貢献 300,000 円、許容獲得費率 25% なら、最大許容 CPC は 600 円である。成熟 cohort から retention と貢献が観測できるまでは、推定 LTV で上限を膨らませない。これは説明用の仮定で、OpenAI が例示するドル建て入札額をそのまま採用する根拠にはならない。
手数料率ではなく「取引・cohort 貢献」で比較する
Section titled “手数料率ではなく「取引・cohort 貢献」で比較する”provider ごとに税と fee の計算基礎が異なる。まず次を別フィールドで保持する。
顧客支払総額税額と徴収・納付主体providerの手数料計算基礎sellerに帰属する税抜売上provider控除額と内訳providerからの決済額払出し予定日、保留額、実入金日例えば Lemon Squeezy の公表 fee は tax を含む total order value が基礎である。Apple、MoR、PSP に同じ税抜額×料率の式を流用しない。契約上の基礎から provider fee を算定した後、成功取引または 1 顧客月の貢献を計算する。
成功取引後完全負荷貢献= sellerに帰属する税抜売上 - 値引・返金・回収不能の期待値 - プラットフォーム手数料 - PSP / MoR / Billing / 通貨換算 / 払出し手数料 - 売上税・VAT・消費税の自己負担分 - AI、保存、配信、外部 API 等の変動現金費 - chargeback と不正対応の期待値 - 変動サポート時間 × 内部時間価値決済経路は成功取引だけでなく、購入完了率も分けて比較する。
checkout開始当たり期待貢献= 購入完了率 × 成功取引後完全負荷貢献 - 失敗試行にも生じる決済・不正・サポート等の費用AI 機能固有の provider usage、planned review、correction、founder rescue と workflow value は 12 章で job から集約する。ここではその結果を取引・account commercial cycle に一度だけ取り込み、同じ refund、credit、売上、人手を複数 workflow へ重複計上しない。
費用の正本階層は 09 章と共通にする。
cohort貢献= 対象期間の顧客月完全負荷後貢献の合計 + 導入後初期貢献 - 完全負荷CAC会計上の売上・費用区分や税込/税抜処理は契約と税務で変わる。ここでの目的は、選択肢を同じ責任範囲で比較し、同じ費用を二度引かないことである。
2026-08-02 時点の代表例
Section titled “2026-08-02 時点の代表例”| 選択肢 | 公表された主な料率・条件 | 事業者側に残る主な仕事 |
|---|---|---|
| Stripe Japan | 国内カード成功取引 3.6%、通貨換算が必要なら +2%、Stripe Billing は対象取引額の 0.7%、不審請求申立て受領 1 件 1,500 円 | 販売主体、税務、表示、返金方針、顧客対応、リスク判断。料金 |
| Paddle | checkout 1 件 5% + $0.50。cross-border sales tax compliance、billing、fraud/chargeback protection の処理・機能等を含む。$10 未満等は custom pricing | Supplier は製品・delivery/technical support を担い、返金・chargeback 等が Supplier Fee から相殺され得るため、損失が一律に移転するわけではない。料金 / 契約 |
| Lemon Squeezy | 基本 5% + $0.50 を tax を含む total order value へ適用。米国外取引 +1.5%、PayPal +1.5%、subscription +0.5% 等があり、米国外銀行への Stripe 払出しは 1% | 商品適格性、追加・払出し費、サポート、MoR との責任分担。手数料 / MoR |
| Shopify App Store | 2025-01-01 以後の累計 gross app revenue 最初の $1M は revenue share 0%、超過分 15%。全 billing に 2.9% processing fee。refund は threshold 計算から控除せず、大規模事業者等に例外 | Shopify billing、関連アカウント合算、審査、merchant support。収益分配 |
| Apple App Store / 日本 | 新制度は iOS 26.2 以降の日本向け。Small Business 等と subscription 2 年目以降は commission 10%、その他のデジタル財は 21%。Apple IAP は別に processing 5%。外部 actionable link は 10% または 15% | 代替決済では税、取引記録、月次報告、PSP、返金、表示・年少者保護等。日本での配信 |
| Google Play / 日本（未施行） | 新料金体系の日本導入予定は 2026-09-30。新規/既存 install、recurring/non-recurring、年間収益 program 等で service fee が変わり、Play billing、代替課金、外部 link のいずれにも service fee が残る。日本の追加 billing fee と一部 program 詳細は後日公表 | 2026-08-02 時点では将来条件であり、現行取引へ適用しない。install cohort、地域、effective date、program、billing method を version 管理する。Google Play 公式案内 |
MoR は「手数料が高い PSP」ではない。販売・間接税・請求・不正等の一部責任と実務を束ねる。そのため PSP 3.6% と MoR 5% + 固定額 の差だけを見ず、自分で行う税登録、申告、請求、dunning、紛争、通貨、サポートの対象国と時間を足す。
逆に、B2B 国内少数顧客で請求書・銀行振込が自然なら、国際 D2C を前提にした MoR の包括機能へ毎取引払う合理性は弱いことがある。
Apple 日本の 1 万円例
Section titled “Apple 日本の 1 万円例”新制度を使う日本向けアプリでは、経路ごとの条件も異なる。
- 代替 in-app 決済は Apple commission 10% または 21% に PSP 費が加わる。商品を提示する際は Apple IAP も同時提示し、disclosure sheet と child-safety 要件へ対応する。
- Web への actionable link は Apple の store services commission 10% または 15% に PSP 費が加わり、link tap 後 7 日以内の売上だけが対象となる。
- 代替 marketplace では Apple IAP を使えず、有料 app と app 内デジタル財等に CTC 5% がかかる。
- Small Business Program は自動的な小規模料金ではない。関連アカウントを合算し、原則として前年 proceeds が 100 万 USD 以下等の適格性確認と登録が必要で、当年 threshold 超過後は通常率へ移る。Apple
以下は比較方法を示す算術例で、市場価格や税務判断ではない。App Store Small Business Program 対象のデジタル財、顧客支払額 10,000 円、税・返金・為替・固定費を除外し、代替決済を Stripe 国内カード、外部 link は tap 後 7 日以内の成約と仮定する。
| 経路 | 仮定した変動手数料 | 10,000 円当たり | 手数料控除後 |
|---|---|---|---|
| Apple IAP | commission 10% + processing 5% | 1,500 円 | 8,500 円 |
| 代替 in-app + Stripe | Apple commission 10% + Stripe 3.6% | 1,360 円 | 8,640 円 |
| 外部 link + Stripe | Apple store services commission 10% + Stripe 3.6% | 1,360 円 | 8,640 円 |
| 代替 in-app または外部 link + Stripe Billing | Apple 10% + Stripe 3.6% + Billing 0.7% | 1,430 円 | 8,570 円 |
IAP との差はそれぞれ 140 円、70 円にすぎない。この差から、税の徴収・納付、Apple への取引報告、決済失敗、返金、購入 UX を担う時間を引く。標準 21%/外部 15%、subscription 年数、対象取引、Apple の料率計算基礎によって結果は変わるため、自分の契約条件で再計算する。
結論は「外部課金が得」ではなく、顧客獲得・購入完了率・責任・運用時間まで同じ箱へ入れない限り比較できない、である。
PSP、MoR、エコシステム課金の選び方
Section titled “PSP、MoR、エコシステム課金の選び方”料率比較の前に次を埋める。国内少数 B2B では、最安の料率より「その契約主体・請求書・支払方法で顧客経理が払えるか」が先のハードゲートになる。
顧客ごとの signatory、vendor 登録、PO、請求先、支払日、入金は 11 章の商流状態と請求台帳へ接続する。
- 購入者が要求する契約主体、適格請求書、見積・発注書、銀行振込、支払サイト
- 商品、販売国、通貨、B2B/B2C、顧客属性が provider の受入対象か
- seller/MoR/marketplace のうち誰が税、返金、一次決済支援、製品支援を担うか
- fee 計算基礎、固定 fee、FX、chargeback、refund、payout fee
- 払出し周期、rolling reserve、保留・凍結条件を 09 章の 13 週へ反映したか
- 解約・provider 停止時に customer、subscription、支払手段、entitlement を移行できるか
- 契約、プライバシー、support 表示と実際の販売主体が一致するか
PSP を優先しやすい条件
Section titled “PSP を優先しやすい条件”- 国内中心で税務・表示・請求を自分で扱える。
- 高単価で固定手数料の影響が小さい。
- 顧客・請求関係を直接保ちたい。
- B2B の請求書、カード、銀行振込を組み合わせたい。
- 将来の provider 移行を見込んで顧客・entitlement 台帳を自社に持てる。
MoR を優先しやすい条件
Section titled “MoR を優先しやすい条件”- 多国間のデジタル販売を早く始め、間接税登録・申告・送金を減らしたい。
- 比較的高単価で
$0.50や国際追加率を吸収できる。 - 対象商品・国・返金・審査条件が適合する。
- MoR が法的 seller となることを、契約、請求書、サポート文言まで理解している。
エコシステム課金を優先しやすい条件
Section titled “エコシステム課金を優先しやすい条件”- 顧客がそのエコシステム内で製品を探し、購入し、権限付与する。
- 発見、信用、install、billing、解約を含む conversion 改善が手数料を上回る。
- 審査・規約変更・ランキング低下でも顧客を支えられる。
- entitlement と契約状態をプラットフォーム webhook だけに依存させない。
共通の可逆性
Section titled “共通の可逆性”customer、contract、entitlement、invoice/payment、refundを別テーブルにする。- provider ID は外部キーとして保持し、自社の主キーにしない。
- webhook は署名、重複、順不同、遅延、再送を前提にする。
- entitlement 変更を冪等にし、reconciliation job を持つ。
- 価格、税区分、利用規約版、同意、返金判断をイベント時点で保存する。
- provider 停止時の猶予、read-only、手動請求、data export を設計する。
プロトコルは価値・流通・決済を代替しない
Section titled “プロトコルは価値・流通・決済を代替しない”AI エージェント周辺の役割を混ぜない。
| 層 | 主な役割 | 例 | それだけでは解決しないもの |
|---|---|---|---|
| API / webhook | 自社サービスの決定的な読取・書込 | REST、GraphQL、event webhook | agent にとっての発見・意味 |
| Tool access | agent が tool/data を発見し呼び出す | MCP | agent 間の長い協調、支払権限 |
| Agent coordination | 異なる agent の能力発見・情報交換・作業調整 | A2A | 顧客需要、販売主体、返金 |
| Commerce | 商品、checkout、注文の受渡し | Agentic Commerce Protocol 等 | 販売者の履行・サポート責任 |
| Payment mandate | 誰が何をいくらまで承認したか | AP2、scoped payment token | 商品価値、税務、品質 |
A2A は 2025-06-23 に Google から Linux Foundation のプロジェクトへ移され、当時 100 社超が支持していた。Google Developers
Google は 2026-04-28 に AP2 を FIDO Alliance へ寄贈し、v0.2 で事前承認した指示に基づく Human Not Present 支払と、ユーザー承認行為の改ざん耐性ログを志向する Verifiable Intent を紹介した。Google
OpenAI が 2025-09-29 に公表した初期 Instant Checkout は、米国の ChatGPT Plus、Pro、Free 利用者が米国 Etsy seller から単品を購入する歴史的な開始スコープで、Shopify merchant は当時 coming soon だった。この初期設計では、merchant が merchant of record のまま注文、決済、履行、返品、サポートを扱い、ユーザーが各段階を明示確認し、token は特定金額・特定 merchant に限定された。OpenAI
これらは相互運用と委任の方向を示すが、採用数、流通量、仕様、地域は変わる。顧客から「今の業務でこの接続が必要」と確認できる前に、複数プロトコルの完全対応を作らない。
先に作る共通中核
Section titled “先に作る共通中核”特定プロトコルより先に次を持つと、Web UI、API、MCP、A2A、commerce の各 surface で再利用できる。
Quote- quote_id / version / seller / buyer- item / quantity / total / currency / tax treatment- expiry / cancellation terms
Intent / Authorization- human or agent principal- allowed operation / resource / amount / count / category- valid_from / expires_at / one-time or recurring- immutable payload hash / consent record
Execution- idempotency_key / request_id- current state / retry policy / compensating action- actual amount / result / error
Audit / Receipt- who requested / approved / executed- input source / policy version / tool version- before-after / external reference / timestamp- user-visible receipt / dispute and refund path委任は一段ずつ上げる
Section titled “委任は一段ずつ上げる”委任レベルは製品全体へ一つ付けず、tool × operation × tenant × data class ごとに付ける。read や draft も、機微情報を外部 model へ送る、または秘密を含む下書きを作るなら低リスクではない。
委任レベルを、顧客への提供形態と混ぜない。self-service でも外部送信は人が承認でき、managed service でも内部 agent が限定的な write を行い得る。提供形態 delivery_mode の正本は 14 章、変更 risk tier の正本は 13 章とし、三軸を別 event で昇格・失効させる。
操作リスク= データ感度 × sinkの強さ × 不可逆性 × 第三者への影響| レベル | agent ができること | 既定の境界 | 昇格に必要な証拠 |
|---|---|---|---|
| 0 | 検索・要約 | 外部情報は untrusted、書込なし | source attribution、誤り率 |
| 1 | 下書き・候補提示 | 人が編集・送信 | 採用率、修正量、重大誤りゼロ |
| 2 | reversible な低リスク書込 | 対象・回数・期限を限定、undo | sandbox/canary、監査、回復成功 |
| 3 | 外部送信・予約・発注 | 実行直前に immutable payload を表示し承認 | 宛先/金額/範囲の照合、通知、取消 |
| 4 | 事前承認内の自律実行 | 金額・カテゴリ・回数・時間・相手を capability で限定 | 長期 shadow、異常停止、独立照合、損失上限 |
「確認ボタンを付けた」だけでは十分でない。確認後に宛先、本文、添付、金額、商品、権限が変われば、確認を無効にして再承認する。
昇格ごとに次を埋める。件数と率は業界 benchmark ではなく、このプレイブックの安全側の既定値である。損害が大きい場合は厳しくできるが、理由なく緩めない。
tool / operation / tenant / data class:対象resourceと第三者への影響:可逆性と1回・日次・累積の最大損失:shadow件数・期間:critical / major / minor の定義と各件数:許容率:canary対象・件数・期間:rollback成功条件とRTO:kill switch責任者:監査・通知・補償操作:再評価日と、model/tool/policy変更時の再評価条件:実装時は、この昇格カードを task の risk trigger、threat-model delta、eval、release recordへ同じ change_id で結ぶ。以下の件数基準を一般のコード変更へ移植しない。
既定の最低線:
| 昇格 | shadow | 品質 | canary・復旧 |
|---|---|---|---|
| Level 0/1 → 2 | 代表例 50 件以上 | unauthorized access / tenant 越境 / secret exposure 0 | reversible test、rollback 5/5 成功 |
| Level 2 → 3 | 100 件以上かつ 30 日以上 | critical 0、major 1% 以下 | 対象を限定した 20 件以上、定めた RTO 内で取消/補償 100% |
| Level 3 → 4 | 500 件以上かつ 90 日以上 | critical 0、major 0.2% 以下、独立照合一致 99.8% 以上 | 30 日以上、日次・累積損失上限と kill switch drill 成功 |
ここで critical は無権限送信・支払、機密/個人データの越境・漏えい、安全・法令上の重大結果等、major は利用者成果が使えず rollback・再処理を要する結果と定義する。分母の異なる率だけを比較せず、件数も併記する。
08 章で人の最終判断に限定した採否、税務判断、食品・介護・施工・運送等の高損害判断は、実績が良くても Level 4 へ上げない非補償ゲートとする。自律化するなら別途、専門家、法令、保険、責任分担を含む再設計が必要である。
Source-to-sink で設計する
Section titled “Source-to-sink で設計する”OpenAI は prompt injection を単なる悪性文字列の検出問題でなく social engineering と捉え、untrusted external content という source と、第三者への情報送信や tool action 等の sink を組み合わせた影響を制限する設計を説明している。OpenAI このプレイブックでは安全側の threat-model assumption として、外部 Web、メール、文書、コメント、外部 tool response は攻撃者が影響できる source、送信、公開、権限変更、秘密の送出、購入、返金は高リスク sink として扱う。
個人開発者向けの最低条件:
- 外部内容を読む段階と、書く・送る・払う段階を別 request にする。
- model へ root secret を渡さず、operation、resource、amount、expiry を絞った短命 capability を使う。
- 外部文書中の「権限がある」「この URL へ送れ」を認可根拠にしない。
- 実行直前に deterministic code で policy、対象、金額、rate limit を再検査する。
- 人に見せる approval payload を実行 payload と同一にし、hash/version を固定する。
- 最小権限、tenant 分離、idempotency、監査、取消/補償操作を持つ。
- tool/model/prompt 更新時は、正常系だけでなく injection、data exfiltration、confused deputy を回帰評価する。
「補助」と「代替」の約束を一致させる
Section titled “「補助」と「代替」の約束を一致させる”経済産業省が 2026-04-09 に公表し、06-09 に資料を差し替えた「AI利活用における民事責任の解釈適用に関する手引き〔第1.0版〕」は、新しい無過失責任や免責を作る法律ではない。不法行為法・製造物責任法を中心とした現行法の解釈整理で、具体的責任は個別事案による。経済産業省
手引きは利用形態を二つの参考類型で整理する。次表はその法的記述の逐語引用ではなく、個人開発者が製品の約束・運用へ翻訳した要約である。
| 類型 | 製品の約束 | 利用者側の基本姿勢 | 提供者が特に設計・説明すること |
|---|---|---|---|
| 補助／支援型 | 人の判断材料を出す | 最終判断者が正確性・適切性を検証し、必要情報を集める | 機能、利用場面、限界、予見しにくいリスク、検証方法 |
| 依拠／代替型 | 通常の人の判断・行動の一部を置き換える | 全出力を個別検証する義務ではなく、AI を組み込んだ業務プロセスを適正に構築し、リスクを可能な限り低減して運用する | 予定精度の維持、外部情報/tool の扱い、人の介在範囲、重要リスク |
手引きは依拠／代替型に、(1) 人の介在では得にくい便益を得る必要性、(2) 通常の人と同程度以上を目安とする精度・安全性、という二つの要件を示す。AI エージェントだから自動的にどちらかへ分類されるわけでも、AI 事業者ガイドラインへの形式的準拠・非準拠だけで過失が決まるわけでもない。一方、合理的なリスク調査、体制整備、予防・回避措置を行った事実は、予見可能性や結果回避義務違反の判断で考慮され得る。
製品では次の五つを一致させる。
| 面 | 補助として売るなら | 代替に近づけるなら |
|---|---|---|
| 広告 | 「判断材料を整理」「確認を支援」 | 自動実行の対象、品質水準、除外を限定して明示 |
| UI | 根拠、不確実性、編集、差分、確認 | policy、権限、承認、例外 queue、停止、復旧 |
| 契約 | 顧客の最終確認、禁止用途、入力責任 | 精度/SLA、役割、上限、変更、監査、事故分担 |
| 運用 | 検証しやすい出力、誤り報告 | shadow/canary、継続 eval、drift、human fallback |
| 証拠 | source、version、user edit | intent、authorization、execution、receipt、incident |
landing page では「完全自動」と約束し、利用規約の奥だけで「全出力を確認」とする設計は避ける。価値提案と人の確認負担が矛盾し、顧客の期待、支援コスト、責任のすべてを悪化させる。
個人開発者の段階的な出荷ゲート
Section titled “個人開発者の段階的な出荷ゲート”Gate 1: 問題と購入者
Section titled “Gate 1: 問題と購入者”- 同じ ICP 5 人以上から、同じ反復業務と現在損失を確認した。
- 支払者、利用者、損害を受ける第三者を分けて書いた。
- 手作業でも有償提供し、購入手続きと期待成果を確認した。
Gate 2: Web 単体の経済性
Section titled “Gate 2: Web 単体の経済性”- 09 章で必要顧客数が容量上限以下である。
- 返金、決済、AI 原価、サポート時間後の成功取引・顧客月完全負荷後貢献が正である。
- 13 週の最低現金と停止条件を置いた。
Gate 3: 借用チャネル
Section titled “Gate 3: 借用チャネル”- 顧客の発見・購入・利用のどこを改善するか一文で言える。
- 審査失敗、掲載順位ゼロ、規約変更でも既存顧客を支援できる。
- channel-specific CAC と 30/60/90 日 retention を分離計測する。
- 手数料変更を価格へ反映する条件と、撤退・移行手順を持つ。
Gate 4: Agent の read/draft
Section titled “Gate 4: Agent の read/draft”- 代表例、edge case、禁止例を含む eval set がある。
tool × operation × tenant × data classごとにデータ感度、外部送信、retention、学習利用を確認した。- 出典、差分、人の修正量を記録する。
- tenant 越境、秘密送出、prompt injection の試験を通す。
- 昇格カードの Level 0/1 → 2 の件数、重大度、rollback 条件を満たす。
Gate 5: Agent の write/send/pay
Section titled “Gate 5: Agent の write/send/pay”- read と write を分離し、権限は短命・対象限定である。
- idempotency、approval、監査、取消/補償、通知がある。
- 対象レベルの昇格カードに定めた shadow 件数・期間、critical/major 許容率、canary、RTO を満たす。
- 1 回・日次・累積の損失上限と kill switch があり、drill に成功した。
- 高損害判断の Level 4 非補償ゲートに該当しない。
- 宣伝、UI、契約、runbook が同じ自律水準を説明する。
いずれかが未達なら、一段前の manual/review-required モードで販売を続ける。完全自動化を待って販売を止める必要はない。
毎月と四半期の監視表
Section titled “毎月と四半期の監視表”| 項目 | 指標 | 悪化時の最初の行動 |
|---|---|---|
| 流通 | channel 別有効商談、成約、完全負荷 CAC | ICP・message・landing のどこで落ちるか分解 |
| 経済 | 顧客月完全負荷後貢献、cohort 貢献、refund、chargeback | 高原価機能、低価格顧客、支援例外を特定 |
| 継続 | cohort retention、利用成果、解約理由 | 約束した成果に到達しない cohort を面談 |
| Agent 品質 | task success、重大誤り、human override | 自律範囲を下げ、失敗例を eval へ追加 |
| 権限 | denied action、再承認、異常停止、越境試行 | capability、policy、tool scope を狭める |
| 運用 | support p50/p90、incident、復旧時間 | 例外を標準化し、容量モデルを更新 |
次の一次情報を再確認する。
- App/marketplace の公開、推薦、外部 checkout、手数料、データ条件
- PSP/MoR の料率、対象国、税、払出し、返金、chargeback
- 広告の対象ユーザー、入札、計測、禁止業種・表現
- AI model/API の価格、retention、学習利用、region、deprecation
- MCP/A2A/commerce/payment mandate の採用、互換性、security update
- 日本の個人情報、AI、消費者、決済、税務の施行・ガイドライン
更新のたびに「何が変わったか」だけでなく、次を記録する。
影響する顧客:影響する売上・原価・責任:いつまでに対応が必要か:回避経路:撤退条件:90 分で行う現在地診断
Section titled “90 分で行う現在地診断”- 直近 90 日の顧客、最初と補助の touch、契約、請求、返金、provider fee
- 顧客別の導入・提供・support 時間
- checkout の開始、成功、失敗と各経路の入金日
- platform 別の新規流入、install、既存利用、認証/runtime、課金・払出し依存
- agent tool、operation、権限、tenant、data class、事故・override
- landing page、UI、契約、privacy notice、runbook
欠ける入力があれば推測で採点せず、UNKNOWN を red gate として、取得担当・期限・最小ログを決める。
- 0〜10 分 — 範囲とデータ充足: 対象製品、期間、cohort、欠測を固定する。
- 10〜25 分 — 流通: 商談起点、assist touch、利用面、決済面、制御度の五軸で記録する。
- 25〜45 分 — 経済: fee 計算基礎から入金までの waterfall、CAC、初期、顧客月、cohort の重複を照合する。
- 45〜60 分 — 購買と現金: 契約・請求要件、payout/保留を 13 週資金繰りへ置く。
- 60〜75 分 — Agent:
tool × operation × tenant × data classで source-to-sink と昇格カードを確認する。 - 75〜90 分 — 判定: 全 red gate、最優先の可逆的実験 1 件、owner、期限、停止条件を決める。
platform 停止は一つの「ゼロ流入」でなく、次を別々に想定する。
- 新規発見がゼロ
- 新規 install / onboarding が不能
- API、認証、runtime が停止
- 課金または払出しが凍結
複数製品が同じ channel、store account、PSP、identity、cloud、AI provider を使う場合は、製品別の依存を足し合わせず、15 章の failure_domain_id と共同停止 scenario へ集約する。
この診断の成果物は新しい機能一覧でも、最大問題一つだけでもない。全ハードゲートを残したうえで、今週扱う優先実験を一つ選ぶ。
RED GATES- gate / evidence / maximum loss / owner / due date
UNKNOWN INPUTS- field / minimum logging / owner / due date
PRIORITY EXPERIMENT- hypothesis / smallest reversible action- success metric / stop date / stop condition- expected cash and founder-time costこの章の限界
Section titled “この章の限界”- ベンダーの研究・料金・導入事例は、そのベンダーの利用者・定義・商流に依存する。
- 手数料は税抜/税込、国、通貨、取引種別、program、売上規模、契約交渉で変わる。
- platform の公開規約だけでは、審査運用、実際の推薦、conversion、support 負担は分からない。
- agent protocol の支持企業数は、production traffic や個人開発者の売上を意味しない。
- 民事責任は、契約、表示、当事者、予見可能性、設計・運用上の措置、実際の損害等で個別に決まる。
したがって、この章は「最適な platform を決める表」ではなく、変わる外部条件を自分の流通、取引・cohort 貢献、権限、責任へ変換するための判断枠組みとして使う。