AI 流通を掲載から実入金・継続まで証拠化する

最終更新: 2026-08-02

AI 検索、plugin directory、MCP registry、agentic commerce、決済の仕様・対象地域・審査・計測・料金は変わる。この章は 2026-08-02 時点の一次情報を、個人開発者が誤った売上判断をしないための状態・証拠モデルへ変換したものである。申請、実装、販売の直前に対象地域・商品・主体・version を再確認する。法律、税務、会計、決済、プラットフォーム規約の個別助言ではない。

先に結論

AI 流通では「対応した」「掲載された」「AI に出た」「売れた」を同じ成功にしない。最低限、次を別状態として持つ。

program eligible
→ artifact accepted / published / indexed
→ listing or content resolvable
→ surfaced / cited
→ visited / installed / connected
→ invoked
→ accepted outcome
→ checkout created
→ payment succeeded
→ order created
→ fulfilled or entitled
→ processor balance available
→ bank cash received
→ refund・dispute・support を含む観測窓を通過
→ retained

これは全経路に共通する一本の funnel ではない。検索記事には install がなく、MCP Registry 自体は checkout を行わず、既存契約者の plugin 利用には新規決済がない。経路ごとに適用する段階だけを version 固定し、適用不能を N/A、未観測を UNKNOWN、観測したゼロを 0 とする。

個人開発者が守るべき原則は七つである。

1. protocol availability と program eligibility を分ける。 公開 spec を実装できても、地域・商品・審査・招待条件により live 販売できないことがある。
2. provider の状態を自社成果へ翻訳しない。 published は発見、invoked は受容、payment succeeded は履行、payout paid は銀行着金を証明しない。
3. 観測不能をゼロにしない。 AI citation や推薦の全母数が取れなければ、固定した probe での観測率と first-party 流入だけを示す。
4. 一つの journey を重複計上しない。 platform event、Web session、account、order、payment、bank cash を opaque correlation ID で結び、同じ売上を複数 channel へ配賦しない。
5. 売上でなく accepted outcome と net settled contribution を測る。 返金、dispute、税、provider fee、履行、人手まで閉じる。
6. source と時点を保存する。 current、preview、upcoming、deprecated を混ぜず、policy snapshot と実行 contract を分ける。
7. AI 流通を主事業の代わりにしない。 直接到達と Web で価値・価格・継続を確認した後、顧客が既に使う面だけを追加する。

この章の責任境界

• 04 章: positioning、SEO、コンテンツ、attribution、実験の基礎。
• 09 章: 創業者時間、完全負荷後貢献、CAC、cash runway。
• 10 章: 所有・借用・組込流通、手数料、agent の権限と責任。
• 11 章: 契約、invoice、payment、導入、更新の商流正本。
• 12 章: invoke 後の eligible job、品質、安全、原価、反復価値。
• 13 章: source revision、テスト、review、release、rollback の変更証拠。
• 15 章: platform 停止、共通依存、reserve、sunset。
• 16 章: 直接営業から Qualified まで。
• AI distribution evidence pack: contract、source snapshot、stage evidence、probe、commerce、週次判断の記入書式。
• SQLite companion: 経路別段階、時点、正本、cash、重複排除を架空データで検証する参考実装。

「対応済み」を五つに分解する

層	問い	最低限の証拠	証明しないこと
仕様	protocol/schema を実装できるか	version 固定した conformance test	program 利用資格、掲載
program	自分の主体・地域・商品が利用可能か	現行規約、dashboard 状態、承認 receipt	実装品質、露出
distribution	directory/feed/index から解決できるか	provider/API response、公開 URL、index receipt	推薦、需要
execution	install/connect/invoke/checkout が完了するか	first-party event、署名検証済 webhook、test/live 区分	顧客成果、実入金
economics	履行・着金・継続後に価値が残るか	outcome、order、bank、refund/dispute、cost ledger	因果的な channel 効果

conformance PASS を distribution PASS と呼ばない。逆に、directory から消えても既存接続が動く場合があるため、掲載可用性と runtime 可用性も別 SLO にする。

2026-08-02 の現在地

OpenAI Plugin Directory

OpenAI の現行開発資料では、公開 plugin は skills-only、MCP-only、skills + MCP を取り得る。公開には verified developer/business identity、組織の Apps Management write 権限、listing、support/privacy/terms、対象地域が必要で、MCP を含む場合は public endpoint、domain verification、tool metadata/annotation、review 用 credentials 等を揃える。申請時には少なくとも positive test 5 件、negative test 3 件を提出する。Submit plugins

状態は次の順である。

draft → submitted → in_review → approved | rejected
approved → publisher が publish
published → exact name search / direct listing URL で確認

承認は自動公開ではない。公開後も main page や proactive suggestion は保証されず、enhanced distribution を開発者から申請することもできない。MCP server review requirements

MCP metadata は scan 時の snapshot が review・公開対象となる一方、tool call と一部 live result は現行 server へ到達する。tool 名、schema、annotation 等の contract 変更は新 version の scan・review・publish が必要で、破壊的変更を live server に先出ししてはいけない。したがって次を別 revision として保存する。

plugin package revision
submission draft revision
scanned MCP metadata hash
approved version
published version
live server release SHA
live UI resource revision

公開 plugin に関する現在の checkout 資料は、一般提供の外部 checkout を含め、承認対象を physical goods に限定している。ChatGPT payment sheet は select marketplace partners 向け private beta である。digital product、service、subscription、content、token/credit の販売や freemium upsell は現行 guideline で認められず、既に別経路で購入した account entitlement の利用とは区別される。Checkout API reference / Commerce and monetization guidelines

したがって日本の Web/SaaS 個人開発者は、公開 plugin がそのまま software subscription の購入面になると仮定しない。まず plugin を既存契約者の利用・成果面として評価し、商品種別、地域、販売方法の eligibility を申請前に再確認する。

OpenAI の状態は一本の funnel ではなく、次の直交する台帳で持つ。plugin uninstall が bundled connector の disconnect を自動的に意味するとも限らないため、bundle と underlying app を別に revoke する。

台帳	独立して持つ状態
catalog	draft、review、approved、published、exact-searchable、featured/suggested
user bundle	visible、installable、installed、enabled、uninstalled
underlying app	workspace allowed、provider connected、sync enabled、revoked
runtime	eligible request、selected、called、result、accepted outcome
commerce	checkout、payment、order、fulfillment、cash、reversal

公式資料は tool-call analytics の確認を推奨するが、公開された developer analytics API/schema や統一された impression/install/connect/invocation 定義は確認できない。自分の MCP endpoint、OAuth、outcome telemetry を主証拠にし、provider に文書化されていない母数を作らない。

Official MCP Registry

Official MCP Registry は public MCP server の標準化された metadata 正本で、主な consumer は downstream aggregator や marketplace である。Registry 自体への掲載は各 client の表示、install、接続、呼出しを保証しない。The MCP Registry

2026-08-02 時点では preview で、breaking change や data reset の可能性が明記されている。公開する package または remote server は public に利用可能である必要がある。server.json を publish したら Registry API で exact name/version を再取得して証拠にする。Publisher quickstart

live /v0.1/version と release は Registry 1.8.0、build 2026-07-13 を示す。prose、CLI、OpenAPI に drift があり得るため、実行時は Registry version、mcp-publisher version、schema URL、API response を一組で保存する。Live version / v1.8.0 release / OpenAPI

重要な運用差は次である。

• Registry は artifact を host せず metadata を持つ。npm/PyPI/OCI 等の package または remote endpoint の可用性は別に監視する。
• 通常の metadata 更新は unique version を publish する。現行 publisher CLI には active / deprecated / deleted の status 操作と active への復帰がある。
• deleted は hard erase とみなさない。API consumer は include_deleted 等で metadata を得る場合があり、公開後に秘密や個人情報を完全消去できる前提は置かない。
• FAQ の「delete/unpublish 不可」という記述は現行 v1.8.0 API/CLI と矛盾する。current 実装を優先しつつ、この drift 自体を policy snapshot に記録する。Registry FAQ / v1.5.0 status change
• downstream aggregator の取得・審査・順位・install telemetry は Registry の published から推定しない。

Google と Bing の AI 検索面

Google は AI Overviews / AI Mode について、通常の Search eligibility と SEO 基盤を使い、専用の AI schema や llms.txt を要求していない。crawl/index を許可し、snippet 表示に eligible であることが前提となる。AI features and your website

したがって Googlebot が取得できた、URL Inspection で indexed、通常検索で impression、AI surface で supporting link が表示された は別の事実である。subset へ展開中の Search generative AI control は既定 Include で、Exclude は AI Overviews、AI Mode、生成 AI Discover の link/content/grounding と AI traffic を止めるが、通常検索、Merchant Center/Ads、model training control とは別である。Search generative AI control

Google-Extended は別 HTTP crawler ではなく control token で、Gemini model training と Gemini Apps / Vertex の grounding を制御する。これを block しても Google Search の inclusion/ranking には影響しない。Search 側は Googlebot と上記 Search Console control で扱う。Google-Extended

noindex、nosnippet、max-snippet、data-nosnippet の効果も分ける。directive を読ませるには crawler access が必要であり、robots.txt で block したまま meta directive が効くと仮定しない。Robots meta directives

新しい Generative AI performance report は一部 property へ段階導入され、AI Overviews / AI Mode の supporting-link impression を canonical page、country、device、date で示す。現行文書には query、click、CTR、exact answer、二 surface の分離 dimension がない。link impression を「本文が回答生成に使われた」と昇格させない。Generative AI performance report / launch note

Microsoft/Bing でも crawl/index、AI answer での利用、citation、referral は分ける。IndexNow は add/update/delete の通知で、Bing Webmaster Tools では submitted、crawled、indexed を追えるが、crawl、index、ranking、Copilot citation を保証する receipt ではない。IndexNow / Sitemaps in AI-powered Search

Bing の control では noindex、noarchive、nocache の AI/citation/training への効果が異なり、data-nosnippet は marked content を index/ranking に残しつつ snippet/AI answer から除く。名前の似た Google directive から挙動を推定せず、各 provider の現行資料を正本にする。Bing robots directives / Bing data-nosnippet

Bing AI Performance は public preview で、Copilot、Bing AI summary、select partner の sampled visible citation、page、generalized grounding phrase を示す。low-activity citation が欠けることがあり、exact prompt/answer、選択理由、click、traffic は示さない。Citation Share や Compare も rank・quality・因果効果ではない。AI Performance / AI Visibility Insights

Search Performance は Web と Chat の aggregate を含む一方、page/query detail は Web-only であり、citation row を Chat click へ一意 join できない。first-party referral や Clarity の AI channel group は post-click の補助証拠で、zero-click influence を回収しない。Bing Search Performance / Clarity AI channel groups

検索面の実務上の結論は単純である。

index されたページ数 ≠ AI に表示されたページ数
AI probe で一度引用 ≠ 全利用者への impression
AI referral session ≠ AI が唯一の成約原因

Shopify Catalog と UCP

Shopify は Global Catalog と Storefront Catalog を提供し、どちらも UCP Catalog capability を実装する。Global Catalog は複数 merchant、Storefront Catalog は一店舗を対象にし、MCP endpoint、scope、extension が異なる。search_catalog、lookup_catalog、get_product は発見、ID 解決、選択後の最新詳細という別操作である。About Catalogs

2026 Spring Edition では、core UCP development access の事前審査を外し、developer が agent profile を登録して public endpoint を使い始められる self-service を発表した。ただし全機能が無審査という意味ではない。Catalog MCP の基本利用は keyless で、API key は rate-limit 増枠に使う。complete_checkout には権限付き token、Order には追加 scope が必要で、order webhook 登録、promoted placement、Universal Cart 等には管理手続、招待、early access が残る。Shopify Spring ’26 / Auth and rate limiting / Carts and checkout / Order webhooks / Promoted placements

Catalog 利用時は検索結果を cache せず、商品画像を server 保存・再利用せず listing と同時に取得・表示する。agent profile の cache 可否とは混ぜない。endpoint URL は変わり得て、AI 推定 field や context signal には欠落・誤差があり得る。Catalog の価格・在庫・適格性は照会時点の discovery 情報で取引上の確約ではなく、Checkout の server-side read を正とする。session 固有結果を後の取引へ再利用しない。UCP Catalog

Public Catalog で商品を解決できても、商品・merchant の eligibility、特定 channel での有効化、direct checkout は別状態である。Shopify の現行 ChatGPT channel は merchant checkout への redirect で、ChatGPT 内決済と同一ではない。Catalog requirements / Selling on ChatGPT

UCP は capability negotiation と versioning を備え、checkout、identity linking、order 等を組み合わせる。2026-04-08 版 Checkout の状態は incomplete / requires_escalation / ready_for_complete / complete_in_progress / completed / canceled である。requires_buyer_input / requires_buyer_review は状態ではなく message severity で、checkout 自体は requires_escalation になる。AP2 Mandates 等の拡張がない通常の checkout は、信頼された UI で buyer が手動確定する境界を残す。Order には fulfillment expectation/event と refund・credit・dispute・cancellation 等の adjustment がある。UCP overview / Checkout / Order

/latest/ を production contract に保存せず、実際に negotiate した日付版、capability、schema URL/hash、payment handler version を receipt へ固定する。日付版は最後の非後方互換変更日で、UCP 自体は廃止期限を一律に決めない。supported_versions の実値と provider 固有の version drift を保存し、public discovery に draft capability を出さない。UCP versioning

Shopify Order webhook は delta でなく latest snapshot であり、delivery 重複用 ID と同一 merchant action の関連 ID を分け、raw body の HMAC を検証する。event replay だけで現在状態を合成せず、resource snapshot と get_order を照合する。agent 側 order data を永続会計台帳とせず、merchant permalink と merchant 正本を残す。Shopify Orders / Order webhooks

Stripe SPT と Agentic Commerce Suite

Stripe の Shared Payment Token は、agent が seller Stripe profile、currency、maximum amount、expiry 等を取引ごとに限定して渡す scoped credential である。seller は原 PaymentMethod でなく SPT から clone された PaymentMethod を使って PaymentIntent を作る。SPT の状態は active / requires_action / deactivated で、used/deactivated event は token の使用・失効を示すだけで PaymentIntent 成功を証明しない。決済には PaymentIntent の authoritative read-back または webhook が別に必要である。現行 SPT API は 2026-04-22.preview で、request ごとの version を receipt に固定する。Shared payment tokens

しかし技術仕様の存在は販売資格を意味しない。現行 Stripe docs では Agentic Commerce Suite の seller は米国・カナダ、SPT は agent・customer・seller が米国・カナダの scope で、ACS の agent role は private preview / waitlist である。Agentic commerce / Sell through agents

ChatGPT Instant Checkout を Stripe で受ける現行手順も、OpenAI-approved businesses in the United States と明記する。Accept a payment

日本の主体・日本販売を想定する時点では、ACS/SPT/ChatGPT Instant Checkout を LIVE_READY にしない。NOT_ELIGIBLE_CURRENT_SCOPE または根拠を確認できない UNKNOWN とし、sandbox/conformance と live 売上を分ける。一方、Stripe MCP app から通常の Stripe-hosted Checkout へ redirect する公開経路は Instant Checkout とは別なので、「Stripe の agent 経由 monetization 全体が不可」と一般化しない。Stripe apps

Stripe の catalog import は独立した非同期処理で、upload 順に完了する保証がない。awaiting_upload → processing → succeeded | succeeded_with_errors | failed を thin webhook 後の provider object read-back から取り、success/error count と error file を保存する。succeeded_with_errors を全商品 index 済みとせず、古い import の遅着完了を自動で正としない。replace は省略商品を削除し得るため upsert、明示 delete、discovery-only の意図を version 化し、export reconciliation で provider 実状態を確認する。feed success 後も seller enablement と agent acceptance は別状態である。現行 Product Catalog Import v2 は 2026-07-29.preview で、SPT や Checkout と同じ version と仮定しない。Product feed / Product Catalog Import

経路ごとに必要段階を宣言する

Search / citation motion

eligible URL
→ crawl fetched
→ indexed
→ query/surface で impression または固定 probe で observed
→ cited/link exposed
→ first-party landing
→ eligible job / accepted outcome
→ commercial cycle

probe observed は impression の代用品ではない。query、locale、device、logged-in 状態、surface、実行時刻、結果 URL、capture hash を保存し、全ユーザーへの露出率と呼ばない。

Plugin / MCP motion

program eligible
→ package/server conformance
→ submitted
→ approved
→ published
→ exact listing resolvable
→ installable for target plan/workspace/region/role
→ installed
→ authentication connected
→ tool or skill invoked
→ eligible job completed
→ outcome accepted
→ repeated within promised workflow window

HTTP 200 は tool success ではなく、tool success は user outcome ではない。read-only tool、draft、external write、payment の権限 class ごとに invocation と human confirmation を分ける。

Agentic commerce motion

seller/product/region eligible
→ catalog/feed row accepted and current
→ product surfaced
→ current product resolved
→ checkout created
→ buyer input/review complete
→ payment authorized/captured/succeeded
→ authoritative order persisted
→ fulfilled or digital entitlement granted
→ refund/dispute window monitored
→ processor payout available/paid
→ bank cash reconciled
→ repeat purchase or retained entitlement

order を返してから支払失敗する asynchronous method、支払成功後に fulfillment が失敗する商品、銀行着金後に dispute が起きる payment method がある。単一 success=true で表現しない。

Evidence strength を固定する

evidence class	例	使える判断	使えない判断
E0 inference	model 推定、創業者の推測	次に調べる仮説	stage 達成、売上
E1 manual observation	screenshot、固定 query probe	その条件・時点の表示	全 impression、因果効果
E2 provider control plane	dashboard、Registry/API object、Search Console	provider が表明する状態	自社 outcome、銀行着金
E3 verified provider event	署名検証済 webhook、immutable event ID	provider event の発生	fulfillment、顧客受容
E4 first-party authoritative	server log、account state、order/entitlement ledger	自社 runtime・履行状態	provider 全露出
E5 customer/bank authoritative	acceptance、renewal、銀行明細照合	受容・実入金	channel の因果効果

最低証拠 class は stage ごとに contract へ書く。たとえば SETTLED_CASH を dashboard screenshot だけで通さず、bank-side receipt または reconciliation を要求する。手動 screenshot は hash、capture 時刻、閲覧者、query/context を持たせるが、それでも全体母数には昇格しない。

六つの時刻を混ぜない

policy_effective_at: 規約・program 条件が効く時刻
occurred_at: 現実の event 時刻
provider_created_at: provider が event/object を作った時刻
recorded_at: 自社 ledger が取り込んだ時刻
snapshot_as_of: 判断時点で取り込み済みとみなす上限
outcome_cutoff_at: cohort outcome の発生期限

metric の基本条件は次である。

occurred_at <= outcome_cutoff_at
AND recorded_at <= snapshot_as_of
AND environment = LIVE
AND evidence is not retracted or superseded

遅着 webhook は最新 snapshot に反映してよいが、以前の意思決定 snapshot を上書きしない。provider の event ordering と自社 ingest sequence を因果順序に使わず、provider resource version、causal sequence、supersedes relation を別に持つ。

共通 event envelope

PII や raw prompt を分析台帳へ入れず、権限制御された正本への opaque reference を使う。

{
  "event_id": "evt_syn_...",
  "journey_id": "jny_syn_...",
  "motion_contract_id": "mot_syn_...",
  "canonical_stage": "INVOKED",
  "source_stage": "tools/call completed",
  "evidence_class": "E4_FIRST_PARTY",
  "source_system": "mcp_gateway",
  "source_event_id": "opaque-dedup-key",
  "source_revision": "17",
  "occurred_at": "2026-08-02T00:00:00Z",
  "recorded_at": "2026-08-02T00:00:02Z",
  "environment": "LIVE",
  "artifact_revision": "sha256:...",
  "policy_snapshot_id": "pol_syn_...",
  "payload_ref_hash": "sha256:...",
  "supersedes_event_id": null,
  "signature_status": "VERIFIED",
  "data_class": "NO_RAW_PII"
}

source_event_id へ unique constraint を置き、webhook retry を新成果にしない。署名検証前の payload は quarantine へ置く。処理結果が不明な write/payment は同じ idempotency key と authoritative object の read-back で照合し、別 key で自動再実行しない。

Identity と attribution

匿名の AI impression から銀行入金まで、一つの個人識別子で追跡しようとしない。境界ごとに最小 ID を使う。

provider listing / query observation ID
    ↓ verified link parameter がある場合だけ
first-party landing session ID
    ↓ consent・purpose の範囲
account / workspace ID
    ↓ commercial system
checkout / order / payment / entitlement ID
    ↓ reconciliation
payout / bank transaction reference

link がない境界は UNKNOWN_LINK である。時刻や金額が似ているだけで join しない。fingerprinting や、規約・同意を超える cross-context tracking で欠損を埋めない。

attribution は少なくとも次を分ける。

• provider_declared_origin: provider event に付く originating agent 等。
• first_known_touch: 自社が最初に検証できた touch。
• assist_touch: 成約前に検証できた補助 touch。
• commercial_owner: 収益を一度だけ計上する motion/cohort。
• incremental_effect: randomized holdout 等がある場合だけ主張する因果差。

last click や provider tag を incremental lift と呼ばない。同一 order の売上を search、plugin、partner の各 dashboard へ全額足してはいけない。

分母を stage ごとに固定する

指標	分子	分母	注意
publication rate	published artifact	submitted artifact	version grain
listing resolvability	exact lookup PASS	scheduled exact lookup	推薦率ではない
probe observation rate	cited/surfaced probe	eligible fixed probes run	impression share ではない
installability rate	installable target contexts	tested eligible contexts	installed user ではない
connection rate	connected installs	install attempts or installs	denominator を事前固定
invocation success	authoritative successful invokes	eligible invokes	HTTP requests ではない
accepted outcome rate	accepted outcomes	eligible jobs invoked	12 章と一致
checkout completion	authoritative completed checkouts	checkout created	duplicate/retry を除く
fulfillment rate	fulfilled/entitled orders	valid paid orders	refund/cancel cohort を明記
bank settlement rate	reconciled bank cash	captured/succeeded payments	金額と件数を別表示
retained contribution	mature retained net contribution	mature eligible cohort	未成熟 cohort を除外

upstream の全母数が取れない場合、下流 conversion を逆算して impression を捏造しない。unknown impressions / known referrals / known accepted outcomes を併記する。

Checkout から cash までの正本

支払成功と order を原子的に近づける

seller backend は価格、在庫、税、配送、entitlement を checkout 完了直前に再検証する。agent が渡した product title、price、country hint を authoritative としない。

1. idempotency key を reservation
2. current catalog/price/inventory/eligibility を server-side read
3. buyer review/authorization と allowance を検証
4. payment intent を作成・確認
5. authoritative payment result を read back
6. order を同じ correlation key で永続化
7. fulfillment/entitlement job を outbox へ一度だけ enqueue
8. webhook retry は既存 state を照合

atomic transaction を跨ぐ場合は outbox/inbox、idempotency、reconciliation queue を使う。timeout 時に新しい checkout/order/payment を作らない。

Stripe Checkout では checkout.session.completed 単独を着金成功とせず、Session、line items、PaymentIntent の authoritative status を照合する。delayed payment method は async_payment_succeeded / async_payment_failed まで待ち、fulfillment は自社の冪等 ledger から一度だけ起動する。Stripe Checkout fulfillment

fulfillment と entitlement

物理商品、デジタル商品、SaaS/API で fulfilled の定義を変える。

商品	完了証拠	継続して見る失敗
物理	carrier/delivery event、顧客例外	未発送、返品、紛失、再送
download/license	signed entitlement grant と取得可能性	key 発行失敗、取消、再発行
SaaS	account entitlement、最初の eligible job	login/auth、seat、region、cancel
API	credential grant と accepted call	quota、revocation、abuse、SLA
service	scope acceptance と提供 receipt	capacity、再作業、顧客承認

payment success だけで fulfillment job を完了扱いにしない。fulfillment success だけで顧客が成果を受け入れたともみなさない。

settled cash と reversals

gross customer consideration
- tax held for remittance
- discount / credit / refund
- processor / platform / FX / payout fee
- dispute loss and fee
= processor-side net cash
→ payout initiated
→ payout paid
→ bank receipt reconciled

銀行着金を gross revenue として再加算せず、bridge の終点として扱う。refund、dispute、reserve、negative payout は元 order/payment と結ぶ append-only adjustment にする。

refund は pending/failed、dispute は即時 debit と後日の反転、processor の payout paid は後日の failed を取り得る。Shopify Payments の Deposited も銀行への実着金とは限らない。provider-side terminal label を E5 の銀行証拠へ昇格させず、statement/transaction との照合日と差額を保存する。Stripe refunds / Disputes / Payout object / Bank reconciliation / Shopify payout details

retained net settled contribution
= bank-reconciled cash attributable once
- tax still payable
- COGS / AI / storage / delivery
- refund・dispute・fraud loss
- variable support and founder rescue time × internal hourly value
- allocated channel experiment cost

未成熟な refund/dispute/renewal 窓では PROVISIONAL と表示する。売上 0 件なら CAC や cost per retained customer を 0 にせず UNDEFINED / spend / zero customers とする。

Probe は観測装置であって需要創出ではない

AI 検索や directory recommendation を手動確認するときは、結果が良くなるまで query を変えて cherry-pick しない。

probe_contract_id:
surface / product / locale / region / account state / device:
query_set_version:
queries selected before run:
eligible URLs/artifacts:
run schedule and maximum repeats:
capture method and redaction:
positive definition:
negative definition:
unknown/error rule:
no personalization / personalization state:
outcome cutoff / snapshot as-of:

同じ query を過度に繰り返して provider の abuse control や personalization を歪めない。provider policy に反する scraping を計測基盤にしない。manual capture と first-party referral を同じ metric に合算しない。

最小 experiment contract

AI channel を試す前に一つの motion だけ選ぶ。

対象 ICP / region / product / job:
surface と version:
program eligibility evidence:
one artifact / offer revision:
required stage path:
stage ごとの minimum evidence class:
known unobservable stages:
primary outcome and denominator:
guardrails:
founder time cap / cash cap:
outcome cutoff / maturity date:
continue / change / stop / inconclusive rule:
fallback owned channel:
rollback / delist / credential revoke / customer notice:

普遍的な試行日数、掲載数、citation rate を成功閾値にしない。顧客の購入周期、検索頻度、契約期間、損失上限から自分の contract を作る。

ボトルネック別の変更 domain

最初の未達	変える候補	まだ変えないもの
eligible でない	region、商品、主体、別 surface	copy、広告費
submit/review 不合格	policy、metadata、tests、privacy、server	価格、顧客課題
published だが解決不能	listing/version、index/feed、runtime	製品価値全体
surfaced ない	query fit、structured fact、freshness、対象面	checkout UX
visit/install しない	promise、trust、permissions、listing	backend automation
connect しない	OAuth、scope、workspace/admin handoff	traffic volume
invoke しない	starter prompt、tool naming、job fit	payment flow
invoke するが outcome 不受容	quality、安全、workflow、human review	distribution spend
checkout 未完了	price、buyer review、tax、payment、handoff	citation volume
paid だが未履行	inventory、entitlement、outbox、support	acquisition
cash/retention が残らない	fee、refund、COGS、support、fit	top funnel vanity metric

一回に一つの change domain を変え、artifact revision、policy snapshot、cohort を跨いで集計しない。

Security・privacy・権限 gate

AI distribution は公開面、MCP、OAuth、payment、顧客データを跨ぐ。最低限、次を release gate にする。

• listing、tool description、starter prompt、privacy policy、実際の response field が一致する。
• tool の read/write/open-world/destructive annotation が実動作と一致する。
• OAuth scope は job に必要な最小値で、install、connect、invoke、revoke を監査できる。
• model に secret、raw payment credential、不要な PII、内部 log を返さない。
• provider webhook の署名、timestamp、replay、environment、event ID を検証する。
• test と live の key、profile、webhook、fulfillment を分離する。
• checkout は server-side price、currency、seller、amount ceiling、expiry、inventory を再検証する。
• external write/payment は exact action を buyer が確認し、timeout/unknown を成功にしない。
• delist、token revoke、provider outage、schema rollback、customer export の runbook がある。

MCP Registry metadata は public で、deleted status も hard erasure を意味しない。秘密だけでなく、後から公開したくなくなる個人名、連絡先、内部 URL も入れない。

14 日で作る最小証拠系

1–2 日目: 一つの motion を選ぶ

• 既存顧客が使う surface か、ICP の検索行動が確認できる surface だけを候補にする。
• 主体、region、商品、program status を一次情報で ELIGIBLE / NOT_ELIGIBLE / UNKNOWN にする。
• UNKNOWN を実装着手で埋めない。

3–4 日目: stage contract と source snapshot

• required / optional / N/A stage を宣言する。
• version、effective date、source URL/hash、次回確認 trigger を保存する。
• provider state を自社 stage へ変換する mapping を review する。

5–7 日目: correlation と first-party event

• listing/link、session、account、invoke、order、payment、entitlement の opaque ID を設計する。
• webhook signature、dedup、outbox、unknown queue を実装する。
• raw prompt、PII、secret を analytics event から除く。

8–10 日目: negative path

• wrong region、expired policy snapshot、uninstall/revoke、auth failure、duplicate webhook を試す。
• stale price、out-of-stock、token expiry、payment timeout、duplicate complete を試す。
• payment success 後の entitlement failure、refund、dispute、payout mismatch を試す。

11–12 日目: probe と reconciliation

• query/listing probe を事前固定する。
• provider object、first-party state、bank/cash bridge の照合 query を作る。
• UNKNOWN と N/A が 0 へ変換されないことを確かめる。

13–14 日目: 小さく live または停止

• eligibility、security、support capacity が揃った場合だけ capped cohort を開始する。
• 現行 scope 外なら sandbox/conformance の成果を保存して停止する。
• 最初の未達 stage と change domain を一つ選ぶ。

Codex に任せる範囲

Codex は次を支援できる。

• 一次資料 URL の候補探索と policy diff の下書き
• stage mapping、schema、fixture、migration、test の実装
• MCP metadata、tool annotation、positive/negative test の lint
• webhook signature/dedup、idempotency、reconciliation query の実装
• probe 結果と first-party event の redacted 集計
• review pack、rollback 手順、source freshness report の生成

人が確定する。

• 自分の主体・商品・地域の program eligibility
• 法務、税、privacy、payment、public listing の attestation
• external write/payment の権限と buyer confirmation
• accepted customer outcome、refund/dispute、bank reconciliation
• continue、stop、delist、顧客通知

AI が「公開できそう」と要約したことを eligibility receipt にしない。source snapshot の exact 文言・適用範囲と dashboard/control-plane の現在状態を人が照合する。

よくある失敗

Directory 掲載を PMF と呼ぶ

掲載は provider contract を満たした証拠で、反復価値や支払意思ではない。install、invoke、accepted outcome、retained contribution まで追う。

Registry publish を install 数に置き換える

Official MCP Registry は downstream aggregator 向け metadata source である。aggregator への収載、client install、connection、invocation を別に観測する。

AI citation を順位として毎日検索する

query/context の変動と personalization を需要に見立てる。固定 probe と provider report、first-party referral を分離する。

succeeded_with_errors を catalog 全件成功にする

row-level failure を denominator から消してしまう。accepted row、rejected row、stale row を分ける。

payment succeeded で売上を確定する

未履行、返金、dispute、reserve、fee、銀行未着金を無視する。provisional と settled/retained を分ける。

provider ごとの数字を足す

同じ order が AI referral、plugin、Stripe、Shopify に一件ずつ現れる。commercial owner と cross-system correlation を決め、一度だけ計上する。

preview を roadmap 売上へ入れる

招待、地域、商品、公開時期が不明な機能を forecast へ入れる。PREVIEW/UPCOMING は option backlog とし、current cash plan は現行経路だけで作る。

週次 review

contract / policy snapshot / artifact revision:
eligible target contexts:
stage ごとの observed / failed / unknown / N/A:
first missing required stage:
late / corrected / retracted evidence:
known referrals / installs / connects / invokes:
eligible jobs / accepted outcomes:
checkout / paid / ordered / fulfilled-entitled:
gross / refund / dispute / fee / bank cash:
mature retained contribution:
founder minutes / cash spent:
security・privacy・support guardrail:
one change domain:
continue / change / pause / stop:
owner / due date / evidence IDs:

最終チェックリスト

Eligibility と version

• protocol conformance と program eligibility を分けた
• 主体、地域、商品、plan/workspace/role を確認した
• current / preview / upcoming / deprecated を分けた
• exact version、effective date、source snapshot を保存した

Distribution と計測

• published/indexed と surfaced/cited を分けた
• installable、installed、connected、invoked を分けた
• 観測不能を 0 にしていない
• probe contract を実行前に固定した
• provider attribution を因果効果と呼んでいない

Outcome と commerce

• invoke と accepted outcome を分けた
• checkout、payment、order、fulfillment/entitlement を分けた
• retry/idempotency、署名、outbox、reconciliation がある
• test event が live metric や fulfillment を動かさない
• refund、dispute、payout、bank cash、retention を追う

判断

• stage ごとの分母と最低 evidence class がある
• 時間・現金上限と maturity date がある
• 最初の未達 stage だけを変更対象にした
• delist、revoke、rollback、顧客移行の runbook がある
• AI channel が止まっても owned Web と顧客関係を維持できる

まとめ

AI 時代の流通は、SEO、directory、MCP、commerce protocol、payment が一つにつながるように見える。しかし事業上は、各 provider が見せる部分状態を自社の履行・現金・継続へ慎重に接続する仕事である。

公開仕様を見つける
→ 自分が current scope で eligible か確認する
→ 経路別の required stage と証拠を宣言する
→ provider event と first-party outcome を分けて結ぶ
→ order・履行・銀行着金・reversal を閉じる
→ mature retained contribution で続行を決める

個人開発者の優位は、すべての新 surface に最速対応することではない。観測不能や preview を売上へ変換せず、顧客が実際に価値を受け取り、自分の銀行と時間に利益が残る経路だけを学習資産として積み上げることである。