端末内・browser・cloud AI を顧客 job の証拠で配置する

Executive Summary

• AI の配置先は model ranking ではなく、一つの顧客 job × 一つの client cohort で決める。 browser-provided / app-shipped local / OS-native / cloud-edge / bounded hybrid を、同じ accepted outcome、eligible coverage、end-to-end latency、fallback、data transfer、support、regression、完全負荷後 contribution で比較する。desktop Chrome の成功を mobile や他 browser へ外挿しない。
• 端末内は「token 原価ゼロ」でも無料ではない。 model download、storage、hardware、battery、初回待ち、runtime 非対応、model update、prompt regression、support、cloud fallback の二重経路が残る。利用者の端末へ費用と待ち時間を移しただけの可能性も、full-loaded cost と client guardrail へ入れる。
• local-first は silent cloud fallback を許さない。 local eligibility と model readiness を実行時に確かめ、cloud へ送る field、目的、地域、保持、provider、通知・同意、timeout、停止条件を別契約にする。一つの job が local failure と cloud success を二つの outcome や二人の利用者へ増幅しない。
• 最初の判断は万能な hybrid ではなく、14 日の bounded placement pilot である。 task-fit、runtime coverage、accepted outcome、time-to-accepted-outcome、完全負荷後 contribution、privacy・safety veto を同じ cohort で測る。判断優先度は STOP > PAUSE > UNKNOWN > CHANGE > MAINTAIN > BOUNDED_EXPAND とし、平均品質や平均利益で重大 incident を相殺しない。

基準日: 2026-08-02
対象: Web app、SaaS、AI feature を一人または小規模で開発・運用する technical founder
判断単位: 一つの customer job × 一つの client cohort × 一つの ai_placement_contract_id / contract_version

この章は技術・事業・計測・運用の一般教材であり、法律、privacy、security、製造物責任、契約、税務、会計その他の個別助言ではない。model、browser、OS、hardware、API、提供地域、規約、価格、法令、ガイドは変わる。live 化する feature、主体、顧客、地域、data、端末、provider について、実行時点の一次資料と必要な専門家へ確認する。

本文、付属 pack、SQLite companion の customer / job / operational fixture にある ID、client、job、件数、金額、時間、品質、判断結果は fully synthetic であり、実績、予測、benchmark、推奨 threshold ではない。一方、日付と一次資料を明示した policy、仕様、価格、quota は synthetic data ではなく、その取得日時点の public source snapshot であるため、利用時に再確認する。公開物や生成 AI prompt へ氏名、連絡先、IP address、device identifier、customer document、prompt / output 全文、credential、API key、token、private key を入れない。

この章は AI job の実行場所を決める

12 章は AI feature の customer job、accepted outcome、quality、cost、retention を扱い、13 章は検証可能な release、19 章は小標本の成熟判断、21 章は provider cost と銀行現金を扱った。本章はそれらを上書きせず、同じ job をどこで実行するかだけを受け持つ。

customer intent
  → exact job and accepted-outcome contract
  → client cohort assigned before outcome
  → runtime / hardware / language / model readiness observed
  → placement policy resolved
  → local attempt | cloud attempt | bounded fallback | safe degradation
  → one accepted or rejected outcome per opportunity
  → support / incident / model-version maturity
  → full-loaded contribution
  → bounded decision

付属物は次の二つである。

• AI placement and fallback pack: customer job、client eligibility、model / prompt / tool version、data transfer、eval、readiness、fallback、cost、incident、週次判断、Codex handoff を複製する 14 書式。
• SQLite companion: runtime 未確認の local eligibility、silent cloud fallback、wrong model / prompt version、二重 outcome、TEST / REAL 混在、未成熟 cohort、value / economic closeout 欠落、未承認の cohort 拡大を fail closed にする、synthetic operational fixture と時点付き public reference fact を分離した参考実装。

章、pack、SQL の一件を ai_placement_contract_id / contract_version で結ぶ。この ID は runtime support、privacy、同意、品質、現金、法的適合を証明しない。各 placement_opportunity_id は exact customer job、client cohort、assignment、runtime observation、attempt chain、accepted outcome、cost、maturity snapshot を別 ID で持つ。

一つの顧客 job と client cohort を先に固定する

「AI を local にするか」という問いは広すぎる。 先に、顧客が何を終えたいか、何を受入と呼ぶか、どの端末群へ提供するかを固定する。

customer_job_id / job_revision:
actor and moment:
input boundary:
desired business outcome:
accepted outcome definition:
rejection / abstention definition:
maximum wait and recovery path:
irreversible effect boundary:

client_cohort_id / cohort_revision:
product / plan / geography:
browser or OS family and version rule:
device and runtime capability rule:
language / modality:
network expectation:
accessibility and support boundary:
assignment frozen_at:

たとえば 文章を生成する では、要約、抽出、分類、最新情報検索、複雑推論、顧客への送信が混ざる。accepted outcome は「文字が返った」ではなく、job に応じた schema、事実整合、policy 適合、人の受入または downstream system の検証済み受入までを定める。世界知識や最新情報が必要な job と、端末内 document からの bounded extraction を同じ task-fit にしない。

client cohort は user-agent 文字列だけで作らない。実行時 feature detection、model availability、hardware / storage、language、permission、app version を別 evidence にする。既存顧客を後から「対応 client だけ」の cohort に再定義して coverage を上げない。assignment 後の unavailable、download abandonment、fallback failure も分母に残す。

五つの placement を同じ accepted outcome で比較する

placement	誰が model / runtime を管理するか	強みになり得る条件	先に負う cost・risk	fail-closed の入口
BROWSER_PROVIDED	browser vendor	browser 内処理、app が model を配布しない、offline-after-ready	browser・desktop・hardware・storage・language の限定、download、vendor update	runtime availability() と exact options が current でない
APP_SHIPPED_LOCAL	自社	browser / desktop app に合う小型・専門 model、version 固定、offline	model asset、WASM / WebGPU runtime、download、cache、CSP、memory、battery、model license、更新・support	asset / runtime / model / prompt version が結べない
OS_NATIVE	OS vendor と native app	OS 組込み model、native data / UX、offline、app size を増やさない場合	対応 device・region・language・OS、native 実装、OS update regression	runtime availability または task-fit が不明
CLOUD_EDGE	自社と provider	広い client coverage、中央更新、大きい model、world knowledge / tool integration	network、data transfer、per-use cost、provider outage、latency、rate / spend、retention、vendor change	data-transfer contract、cost cap、timeout、provider evidence が不明
BOUNDED_HYBRID	自社が route と fallback を管理	local の privacy / latency と cloud の coverage / capability を job ごとに組合せ	二重実装、silent fallback、二重 cost、attribution、consent、support、policy drift	fallback reason、current consent、one-outcome reconciliation がない

placement は排他的な brand choice ではない。一つの product に複数 placement があっても、一つの placement_opportunity_id には一つの current policy と一つの authoritative accepted outcomeを置く。local attempt が失敗して cloud が成功した場合、attempt は二件、customer opportunity と accepted outcome は一件である。

BROWSER_PROVIDED と APP_SHIPPED_LOCAL も同じではない。前者は browser が model と API を提供・更新し、後者は app が model artifact、runtime、cache、version、license を負う。OS_NATIVE も Web の portable baseline ではなく native platform option である。

2026-08-02 の runtime facts を一般論へ広げない

Chrome 148 Prompt API は current だが Chrome-specific である

Chrome 148 release notes は stable release date を 2026-05-05 とし、Prompt API を browser-provided on-device language model への直接 access と説明する。text、image、audio input と response constraint を含む。しかし、Chrome の current path を「全 browser の Web 標準」または「mobile 対応済み」と呼ばない。

Chrome Prompt API documentationの 2026-05-19 更新版では、foundation-model API の current requirements として次が示される。

• Windows 10 / 11、macOS 13 以降、Linux、一定の Chromebook Plus。Chrome Android、iOS、非 Chromebook Plus ChromeOS は未対応。
• Chrome profile volume に少なくとも 22 GB の空き。GPU は 4 GB を超える VRAM、CPU path は 16 GB 以上 RAM と 4 cores 以上。audio input は GPU が必要。
• 初回 model download は unlimited / unmetered connection が必要。その後は network なしで利用でき、この model 利用では data は Google または third party へ送られないと説明される。
• 空き容量が download 後に 10 GB 未満になると model は削除され、条件を満たせば再 download される。
• model は origin が初めて使うとき別途 download される。実際の prompt と同じ modality / language options で LanguageModel.availability() を呼び、user activation、download progress、failure を扱う。
• expected text languages は現行 docs 上 en / ja / es / de / fr。input modality や language が合わなければ NotSupportedError 等を扱う。

したがって Chrome version >= 148 や UA match だけでは eligible でない。API の生値 unavailable / downloadable / downloading / available と、同じ options、checked_at、storage / hardware condition、model-ready time を attempt 前に記録する。availability が一度 available でも、storage、browser、model update により将来の availability を保証しない。

Chrome の model download UX guidance は、download と準備に時間がかかることを利用者へ示すこと、また local model 準備中に一時的な server path を使う hybrid も説明する。これは silent fallback の許可ではない。cloud へ送れる data と current user expectation が揃う場合に限り、別の fallback contract で扱う。

Chrome built-in model management によれば、hardware に応じた model variant の選択、regular update、background download、hot swap、disk / policy / eligibility による purge は browser が管理する。JavaScript から model version を programmatically query できず、swap 中の prompt failure や mid-session purge もあり得る。したがって browser-managed path に偽の exact model hash を要求せず、model_version_visibility=OPAQUE、browser / OS build、availability observation、eval snapshot、checked_at を receipt にする。browser / model management の変化を re-eval trigger にし、同一 session 中も safe failure を扱う。

Apple Foundation Models は device-scale task へ限定する

Apple の Foundation Models framework では複数の language-model path を区別する。本章で privacy / offline を検討する主語は、Apple Intelligence の on-device SystemLanguageModel である。WWDC25 session は、この system model が OS に組み込まれ、on-device / offline で動く一方、約 3B parameters・2-bit quantization の device-scale modelで、summarization、extraction、classification 等に適し、world knowledge や advanced reasoning 向けではないと説明する。

session 作成前に SystemLanguageModel の availability を確認する。Apple Intelligence 対応端末、supported region、language 等に依存し、unavailable reason、guardrail violation、unsupported language、context window 等の error を UX と fallback へ接続する。tool calling は fresh data や action を補えるが、外部 tool へ渡した時点で「すべて端末内」という claim は再評価する。state-changing tool は生成結果だけで実行せず、人の確認、scope、idempotency、receipt を持つ。

Foundation Models updates は、26.4 系の system update に伴う on-device model change のように、OS update 後に prompt behavior を再 test する必要を示す。app version が同じでも model behavior は変わり得る。system model generation を app から確実に観測できない場合は model_version_visibility=OPAQUE とし、OS build / availability observation / prompt revision / eval snapshot で補う。PrivateCloudComputeLanguageModel 等の server-side path、custom LanguageModel、Developer/Beta の将来 OS path は SystemLanguageModel の privacy / offline claim へ混ぜず、CLOUD_EDGE または別の placement / data-transfer contract として current availability を確認する。

app-shipped local は model distribution product である

app が model を配る path では、browser vendor や OS vendor の組込み model とは別に、model license、artifact hash、download、cache、runtime、operator coverage、memory、battery、update、rollback を自社が負う。

Microsoft の ONNX Runtime Web deployment guide は、JavaScript bundle、WebAssembly binary、model files を production asset として挙げ、大きい model の download / IndexedDB cache、artifact size、WebGPU の secure context、CSP、worker、runtime と binary の整合を考慮する。ONNX Runtime Web overview は、WASM path が全 ONNX operators を support する一方、WebGL / WebGPU / WebNN path は現在 subset であると説明する。さらに ONNX Runtime Web get started は、onnxruntime-web/webgpu import を experimental feature と明記する。これは W3C WebGPU 自体の maturity とは別の runtime / execution-provider status である。これらは一つの実装例であり、すべての model・operator・browser が同じ coverage や performance を持つという証拠ではない。

W3C WebGPU は GPU 上の rendering / computation API で、2026-07-14 の現行文書は Candidate Recommendation Draft である。WebGPU support、adapter、operator、memory、precision、thermal behavior を feature detection し、unsupported path を cloud success と取り違えない。WASM fallback があっても latency、memory、battery、artifact size の guardrail を別に測る。

cloud-edge の free tier と rate limit を SLO にしない

cloud-edge cost は provider、model、task、plan、usage 時点の source snapshot で入力する。一例として Cloudflare の Workers AI pricing は 2026-07-29 更新版で、日次 10,000 Neurons の free allocation、超過分の $0.011 / 1,000 Neurons、model ごとの token 換算、一部 paid-only model を説明する。この数字は他 provider の相場、自社の推奨 budget、将来価格ではない。

Workers AI limits は 2026-04-21 更新版で、task ごとの default と model-specific rate limit、text generation の default 300 requests/minute と例外、Beta model の lower limit の可能性、Wrangler local mode の inference も quota に算入されることを説明する。limit は availability、latency、accepted outcome、SLO を保証しない。free allocation、rate limit、spend control、application quota、timeout、circuit breaker を別 field にし、local development usage も reconciliation へ入れる。

coverage は「対応 client の中」だけで作らない

配置判断の分母は、outcome 前に割り当てた scoped customer opportunities である。

scoped_assigned_opportunities
= placement opportunities assigned to the frozen job × client cohort
  before readiness or outcome was observed

known_local_eligible_opportunities
= assigned opportunities with current runtime, hardware, storage,
  language, modality, model-readiness, data and policy gates observed

local_ready_coverage
= known local-ready opportunities
 / all scoped assigned opportunities

eligibility_unknown_share
= assigned opportunities with any required eligibility fact UNKNOWN or stale
 / all scoped assigned opportunities

local_ready_coverage の分子は raw available だけでなく、job の modality / language、client version、model / prompt revision、privacy policy、required capability を満たす。downloadable と ready を分ける。download 完了前に離脱した opportunity を「非対象」として消さない。

coverage table には最低限、次を並べる。

dimension	observed state	失敗時の扱い
product / plan eligibility	OBSERVED / UNKNOWN / FAILED	current feature を出さない
browser / OS / app version	exact source and checked time	cohort を勝手に狭めない
runtime capability	actual feature detection	UA 推測を代用しない
hardware / storage / memory	permitted, minimized observation	過剰な fingerprint を保存しない
model readiness	unavailable / downloadable / downloading / available	ready 前に local attempt しない
language / modality / context	exact requested options	unsupported input を cloud へ黙って送らない
network / offline expectation	current session condition	download と fallback を分ける
accessibility / device impact	user-visible wait、battery、thermal、screen reader	token cost で相殺しない

未知の端末情報を集めればよいわけではない。必要な capability を boolean / coarse state で判定し、raw device fingerprint、IP、document content を分析 artifact へ集めない。

attempt、fallback、outcome を一つの chain にする

上書き status では、local failure と cloud success、retry、遅着 outcome が二重計上される。append-only event から snapshot を作る。

OPPORTUNITY_ASSIGNED
  → CLIENT_CAPABILITY_OBSERVED
  → PLACEMENT_POLICY_RESOLVED
  → MODEL_UNAVAILABLE | MODEL_DOWNLOADABLE | MODEL_DOWNLOADING | MODEL_READY
  → LOCAL_ATTEMPT_STARTED
  → LOCAL_OUTPUT_PRODUCED | LOCAL_FAILED | LOCAL_ABORTED
  → LOCAL_ACCEPTED | LOCAL_REJECTED | FALLBACK_REVIEW
  → FALLBACK_NOT_ALLOWED | FALLBACK_CONSENTED
  → CLOUD_ATTEMPT_STARTED
  → CLOUD_OUTPUT_PRODUCED | CLOUD_FAILED | CLOUD_ABORTED
  → CLOUD_ACCEPTED | CLOUD_REJECTED | SAFE_DEGRADATION
  → OUTCOME_MATURED

最低限、次の時計を分ける。

clock	用途
assigned_at	cohort へ opportunity を割り当てた時点
availability_checked_at	actual runtime condition を観測した時点
model_ready_at	download / initialization を終え local 実行可能になった時点
attempt_started_at / completed_at	local または cloud attempt の経過
accepted_at	user または authoritative validator が受入した時点
recorded_at	event が分析正本へ記録された時点
outcome_cutoff_at / snapshot_as_of	発生・記録を含める二つの cutoff
maturity_at	correction、refund、support、regression 等を評価できる時点

time_to_first_output だけでは、download、retry、fallback、human correction を隠す。主 latency は user action または job assignment から accepted outcome または safe terminal state までの time_to_accepted_or_safe_terminal とする。local / cloud execution time、model readiness、queue / network、fallback、human correction を breakdown する。

p50 / p95 は同じ job、client cohort、placement revision、clock definition の実測から出し、sample count、missing、timeout、censoring を併記する。少数 pilot の p95 を普遍的 SLA にしない。download済み利用者だけの warm latency と、初回を含む customer-perceived latency を分ける。

accepted outcome と task-fit を placement ごとに変えない

quality 比較では同じ eval contract を使う。

accepted_outcome_rate
= placement opportunities with exactly one matured, policy-compliant,
  accepted business outcome
 / matured eligible placement opportunities assigned before outcome

accepted outcome には、少なくとも task-specific correctness、required schema、safety / policy、source / freshness requirement、human correction boundary を含める。abstention や safe degradation が正しい job では、それを failure にしない一方、empty output を自動的な成功にしない。

評価 dataset は client cohort と実利用条件を代表し、利用権、privacy、redaction、language、modality、難易度を version 化する。開発者が prompt を調整した dataset だけで production quality を推定しない。model / OS / browser / runtime update 後は regression set を再実行し、以前の snapshot を上書きしない。

Apple が device-scale model について示す task-fit のように、local model の知識限界を placement policy へ反映する。最新情報、広い world knowledge、複雑推論が必要なら、local 出力を自信値で押し切らず、source-backed tool / cloud path、人 review、または SAFE_DEGRADATION を選ぶ。

NIST AI RMF Core は、intended context、利用者、business value、risk tolerance を先に定め、deployment に近い条件で性能を測り、production で behavior を監視し、knowledge limit を超えるとき安全に失敗できること、independent assessor を含む定期評価を扱う。本章ではこれを、task-fit、placement-specific eval、safe terminal、production regression、independent review へ落とす。NIST の AI RMF page は 1.0 を voluntary framework とし、改訂中であることも示すため、法的適合、製品認証、固定 checklist として扱わない。

local privacy claim と cloud fallback を分ける

処理場所は privacy の一要素であり、privacy compliance の同義語ではない。 local path でも app analytics、crash report、sync、tool call、model download、feedback attachment が data を外へ出し得る。cloud path でも data minimization、regional processing、retention、access control、deletion を設計できる。実際の data flow を event と config で示す。

data_classification_id / revision:
input fields and sensitivity:
local-only fields:
fields allowed for cloud fallback:
fields prohibited from transfer:
provider / region / subprocessors:
purpose / retention / training-use contract:
notice / consent or other reviewed basis:
logging / analytics / support capture:
deletion / incident / access route:
effective_from / expires_at / recheck trigger:

fallback は次をすべて満たす場合だけ候補にする。

1. exact local failure reason が current taxonomy にある。
2. job が fallback を許し、offline-only / local-only promise と矛盾しない。
3. cloud へ送る最小 field と禁止 field が決まっている。
4. current notice、必要な同意その他の適切な basis、user choice がある。
5. provider、region、retention、training use、security、cost cap が current である。
6. timeout、retry、circuit breaker、cancel、safe degradation がある。
7. local attempt と cloud attempt を一つの opportunity に照合できる。
8. UI と receipt が、どの path で最終 outcome を作ったか誤表示しない。

local が timeout した後、同じ prompt を自動で複数 cloud provider へ fan-out しない。outcome 不明なら authoritative state を read back し、同じ irreversible tool action を再実行しない。cloud fallback を使った accepted outcome を LOCAL_ACCEPTED として privacy claim や cost savings に入れない。

透明性と責任は placement で消えない

EU Article 50 — 2026-08-02 から適用

European Commission の Article 50 guidelines は 2026-07-20 公表、2026-07-31 更新で、Article 50 の transparency obligations は 2026-08-02 から適用されると説明する。Commission Q&Aによれば、自然人と直接対話する対象 AI system は、原則として最初の interaction の開始時から、明確・区別可能・accessible な方法で AI interaction を知らせる。provider による machine-readable marking と、deployer が人へ見える label を行う義務は同じではない。

同 Q&A は、Article 50(2) の marking / detection について既存 system の限定的 grace period を 2026-12-02 まで説明するが、他の obligation 全体へ広げない。source code、machine-to-machine output、standard editing 等の scope・exception も条件付きであり、local / offline / small model というだけで適用外としない。public-interest text の human review も、grammar check のような形式確認だけでは足りないと説明される。

この章は個別の EU 適用判断をしない。EU で output が使われるか、provider / deployer のどちらか、direct interaction、content type、public-interest purpose、human review、marking / label、accessibility、effective date を legal card へ渡す。placement economics の positive result は legal review を置換しない。

日本 — current guide は safe harbor ではない

経済産業省・総務省の AI事業者ガイドライン第1.2版 は 2026-03-31 公表で、AI governance、risk、透明性等を事業者が運用へ落とす current reference である。経済産業省の AI利活用における民事責任の解釈適用に関する手引き は 2026-04-09 公表で、裁判例の蓄積が十分でない中で現時点の解釈を整理する。

これらを「この checklist を満たせば免責」という safe harbor にしない。AI が人を補助するのか、人の判断を実質的に置換するのか、利用者にどの検証・修正を期待するか、機能・重要な risk をどう説明するか、monitoring、stakeholder communication、適切な human involvement を placement / job contract へ落とし、実際の損害、契約、表示、設計、運用、因果関係を個別に確認する。

full-loaded contribution は model invoice 以外を引く

端末内 path の provider token bill がゼロでも、management contribution はゼロ cost にならない。

matured_full_loaded_placement_contribution
= matured, non-duplicated gross contribution allocated to accepted outcomes
 - browser / OS / cloud provider charges
 - model and runtime distribution, CDN, cache, storage and egress cost
 - failed local attempt plus cloud fallback variable cost
 - support and founder rescue minutes × approved internal hourly value
 - eval, regression, release and compatibility maintenance cost
 - privacy, security and transparency operations attributable to the placement
 - refund, credit, compensation and incident remediation
 - device-impact compensation or alternative-path cost where actually borne

これは管理用 metric であり、会計利益、銀行現金、税務上の所得ではない。subscription 全体の gross contribution を一 feature へ恣意的に全額配賦しない。job / account / feature へ事前承認した allocation basis がなければ value は UNKNOWN とする。cloud cost avoided は baseline cost の差として一度だけ表し、gross contribution と二重加算しない。

cohort の分母は outcome 前に固定し、成功した local attempt だけを残さない。少なくとも次を placement ごとに併記する。

role	metric	boundary
primary	matured full-loaded placement contribution	accepted、maturity 到達、value / cost reconciliation 済み
driver	local-ready coverage	all scoped assigned opportunities が分母
driver	accepted outcome rate	same job / eval / maturity contract
driver	fallback rate and fallback rescue yield	local failure reason と cloud result を exact join
driver	time-to-accepted-or-safe-terminal p50 / p95	cold / warm、download、timeout を内訳化
guardrail	data-transfer and disclosure violation	一件でも平均利益で相殺しない
guardrail	client harm	battery、thermal、memory、crash、accessibility、unexpected wait
guardrail	safety / wrong action / unsupported claim	tool effect、hallucination、mislabel、local-only 誤表示
DQ	unknown eligibility / duplicate outcome / stale version	coverage と primary を fail closed

founder time は実測または承認した internal rate を使い、ゼロで固定しない。model download を provider が負担しても、利用者の network、storage、wait、battery を「自社 cost ではない」と消さず、client guardrail と adoption / support の driver にする。

routing policy は safe degradation を terminal action にする

一 opportunity に一つの current routing policy を適用する。

KILL_SWITCH
  > LOCAL_ONLY_DENY_CLOUD
  > SAFE_DEGRADATION
  > HUMAN_REVIEW
  > CLOUD_ONLY
  > LOCAL_THEN_CONSENTED_CLOUD
  > LOCAL_ONLY

これは普遍的な優先順位ではなく、overlap 時に安全側へ解決する一例である。exact rule、scope、exception、effective time、rollback を version 化する。

• LOCAL_ONLY: local readiness と task-fit が current。cloud transfer を禁止する job。
• CLOUD_ONLY: local coverage / capability が不十分で、data-transfer contract と cost control が current。
• LOCAL_THEN_CONSENTED_CLOUD: local attempt 後、列挙した reason と current user choice の場合だけ一度 fallback。
• HUMAN_REVIEW: quality / risk が自動受入を許さず、人が修正・承認する。
• SAFE_DEGRADATION: deterministic function、manual workflow、保存して後で処理、feature unavailable など、誤 output より安全な terminal。
• LOCAL_ONLY_DENY_CLOUD: offline / confidential / contractual promise により transfer 不可。
• KILL_SWITCH: model / provider / policy / incident の active harm を止める override。

高 risk action では、local だから human approval を省かない。Apple の tool calling guidance も model が code を呼び action を取り得ることを示す。prompt injection 対策は完全ではないため、untrusted input を developer instruction へ直接補間せず、tool allowlist、argument validation、confirmation、least privilege、idempotency、result receipt を持つ。

14 日で一つの job を pilot する

14 日の目的は長期 retention や全端末対応を証明することではなく、一つの job × cohort で placement chain、unknown、support burden、最小の safe next action を閉じることである。

Day 1 — decision contract

ai_placement_contract_id / contract_version、job、accepted outcome、client cohort、baseline placement、candidate、claim cap、最大 customer / data / cash / device / founder-time exposure を固定する。

Day 2 — source and eligibility freeze

browser / OS / runtime / model / provider docs、app version、feature detection、language / modality、data-transfer contract の current snapshot を作る。UA だけで compatible にしない。

Day 3 — eval and safe terminal

representative な redacted / synthetic eval set、task-fit、accepted / rejected / abstained、irreversible action boundary、safe degradation を承認する。production customer content を公開 fixture へ複製しない。

Day 4–5 — local readiness and cold path

unavailable、downloadable、downloading、available、insufficient storage、unsupported language / modality、asset hash mismatch、WASM / WebGPU fallback を test する。download、initialization、warm inference を別時計にする。

Day 6 — cloud path

provider / model、region、data field、retention、training use、timeout、cost cap、rate / spend control、error、safe degradation を test する。provider alert を hard cap と呼ばない。

Day 7–8 — fallback and negative paths

silent fallback、duplicate cloud request、local output 後の unnecessary fallback、timeout outcome unknown、consent expiry、offline-only data、wrong model / prompt / tool version、state-changing retry を negative probe にする。

Day 9–10 — bounded cohort

one job、one frozen client cohort、one routing policy、one loss cap で SANDBOX または LIMITED_LIVE を実行する。client capability、attempt、accepted outcome、data transfer、cost を exact ID で結ぶ。

Day 11 — support and device impact

download abandonment、browser / OS incompatibility、memory / crash、battery / thermal complaint、accessibility、manual rescue、fallback explanation、support minutes を記録する。token cost に隠さない。

Day 12 — maturity and economics

assigned denominator、unknown eligibility、one-outcome reconciliation、accepted outcome、time-to-terminal、fallback、value allocation、full-loaded cost、incident を同じ cutoff で閉じる。accepted job ごとの value closeout と、cohort の attempt / direct cost / support / incident を数えた economic closeout を versioned evidence にし、行がないことを 0 と呼ばない。未成熟 outcome もゼロにしない。

Day 13 — independent review

front-line 実装者と異なる reviewer が source freshness、cohort leakage、silent transfer、double count、model / prompt drift、guardrail、TEST / REAL、kill-switch、rollback を確認する。

Day 14 — bounded decision

STOP / PAUSE / UNKNOWN / CHANGE / MAINTAIN / BOUNDED_EXPAND の一つ、対象 client / job / model / period / cost / data scope、owner、due、recheck trigger を記録する。

件数不足は自動 failure ではなく、integrity が保たれていれば UNKNOWN または MAINTAIN で追加 evidence を指定する。14 日の warm-path success から、mobile coverage、長期 model stability、retention、法的適合を確定しない。

Codex は実装・照合を担い、placement authority を持たない

任せやすい

• official docs の current snapshot 候補と version 差分。
• capability detection、routing policy、event schema、synthetic fixture。
• local / cloud adapter、timeout、circuit breaker、safe degradation の実装下書き。
• model / prompt / tool artifact hash、eval、regression、negative probe。
• opportunity → attempt → fallback → outcome → cost の reconciliation query。
• missing / stale / duplicate / cross-environment / silent-transfer DQ。
• weekly review、release、rollback、redacted evidence bundle の下書き。

人が承認・実行する

• customer job、accepted outcome、claim、client cohort、loss cap。
• data classification、cloud transfer、notice / consent、法令適用、contract 解釈。
• production model / provider、pricing、retention、training use、地域、security posture。
• high-impact tool action、人 review、customer communication、compensation。
• LIMITED_LIVE / LIVE の activation、kill-switch解除、final placement decision。

Codex handoff には allowed / forbidden files、environment、source cutoff、観測可能な exact model / runtime / prompt / tool versions、または managed model の OPAQUE receipt、redaction、positive / negative tests、maximum external effects、required approvals、rollback を入れる。raw customer prompt、device fingerprint、credential、provider secret、signing authority を渡さない。

生成 code の test pass は、browser support、task-fit、privacy、適法性、顧客受入、positive contribution を証明しない。formal invariant の合格を business approval へ昇格させない。

よくある失敗は placement と outcome の短絡から起きる

• local token bill を total cost 0 とする: distribution、download、device impact、support、regression、fallback を引く。
• Chrome 148 を全 Web user の coverage とする: actual runtime / hardware / storage / language readiness を cohort 分母で測る。
• UA で availability を推測する: exact options の runtime check を行い、downloadable と available を分ける。
• warm inference latency だけを見せる: first-use download と fallback を含む time-to-accepted-or-safe-terminal を併記する。
• 対応端末だけを outcome 後に cohort 化する: assignment を outcome 前に固定し、unavailable と abandonment を残す。
• local failure と cloud success を二人分にする: attempt は二件でも opportunity と accepted outcome は一件。
• cloud fallback を local accepted と記録する: final producer、transfer、cost、notice を exact event で示す。
• local-only 表示の裏で cloud へ送る: transfer 禁止を hard gate にし、safe degradation を返す。
• model download を利用者へ黙って始める: user activation、progress、cancel、storage / network impact を設計する。
• 端末内 model を world knowledge に使う: task-fit、source-backed tool、人 review、cloud または abstention へ分岐する。
• OS / browser model update を自社 release 外とする: exact model version が opaque でも browser / OS build、availability、eval snapshot を release gate に入れる。
• app-shipped model の asset mismatch を無視する: runtime、WASM、model、tokenizer、prompt の hash / version を結ぶ。
• tool output が構造化されれば安全とする: authorization、argument、side effect、confirmation、receipt は別である。
• provider alert を cloud hard cap とする: enforcement、lag、app quota、circuit breaker、kill switch を test する。
• 平均品質で重大 incident を相殺する: privacy、security、wrong action、false disclosure は veto にする。
• EU transparency を cloud AI だけの義務とする: placement でなく system、interaction、content、provider / deployer 等の事実を確認する。
• 行政 guide を免責 checklist にする: current interpretation と個別事実、契約、設計、運用、専門家 review を分ける。
• synthetic eval を customer KPI に混ぜる: environment を固定し、TEST outcome を REAL contribution から除外する。

週次 review と最終 checklist

ai_placement_contract_id / contract_version:
weekly_snapshot_id / outcome_cutoff_at / snapshot_as_of / maturity_at:
customer_job_id / accepted_outcome_revision:
client_cohort_id / assignment_frozen_at:
placement policy / model / runtime / prompt / tool revisions:

assigned opportunities:
known local eligible / unavailable / downloadable / downloading / available:
eligibility UNKNOWN / stale / failed:
local attempts / accepted / rejected / failed / aborted:
fallback reviewed / consented / prohibited / executed:
cloud attempts / accepted / rejected / failed / aborted:
safe degradation / human review:
duplicate or missing accepted outcomes:

accepted outcome numerator / matured eligible denominator:
cold / warm / fallback time-to-terminal p50 / p95 / sample count:
data transferred / prohibited field attempts / disclosure state:
provider, model, prompt, OS or browser drift:
support / rescue / regression / incident cost:
matured full-loaded placement contribution:

privacy / security / safety / client-impact veto:
DQ: late / duplicate / stale / TEST-in-REAL / cross-version:
decision: STOP | PAUSE | UNKNOWN | CHANGE | MAINTAIN | BOUNDED_EXPAND
scope / owner / due / rollback / recheck trigger:

Job and cohort

• 一つの customer job と accepted outcome を placement 間で共通にした。
• client cohort と assignment を outcome 前に固定した。
• unavailable、download abandonment、unsupported client を分母から除いていない。
• user-agent で runtime availability を代用していない。
• language、modality、context、accessibility を eligibility に含めた。

Runtime and version

• browser / OS / app、runtime、model、tokenizer、prompt、tool、eval revision が結ばれる。
• availability check は実行 options と一致し、checked_at がある。
• download、initialization、warm inference、fallback の時計を分けた。
• OS / browser / model update 後に regression eval を通した。
• app-shipped asset の license、hash、cache、rollback を確認した。

Outcome and economics

• 一 opportunity に accepted outcome は最大一件である。
• local attempt と cloud fallback を二重 customer / value にしていない。
• accepted outcome rate の eligibility と maturity を outcome 前に固定した。
• warm success だけでなく failure、timeout、support、fallback cost を含めた。
• value allocation、provider、distribution、device、support、regression、incident cost を同じ scope で照合した。
• accepted job の value closeout と cohort economic closeout が current で、missing row を observed 0 にしていない。
• foreign-currency tariff は current FX evidence で base currency へ正規化し、reference price をそのまま実原価にしていない。
• token bill 0 を total cost 0 にしていない。

Data, safety, transparency

• local path でも analytics、sync、tool、feedback の transfer を確認した。
• cloud fallback の field、目的、provider、region、retention、training use、notice / basis が current である。
• local-only / offline promise では cloud fallback を hard deny した。
• direct AI interaction、generated content、provider / deployer 等の適用確認を placement と別に行った。
• high-impact tool に human approval、least privilege、idempotency、receipt がある。
• privacy、security、safety、wrong action、false claim を平均利益で相殺していない。

Authority and recovery

• LIMITED_LIVE / LIVE、fallback policy、customer communication は人が承認した。
• fallback attempt 数は policy の typed cap 以下で、retry / fan-out を暗黙に増やしていない。
• kill-switch、safe degradation、rollback、resume conditions を rehearsal した。
• public fixture は fully synthetic で PII、customer data、credential を含まない。
• independent reviewer が source freshness、cohort、version、transfer、double count を確認した。
• BOUNDED_EXPAND の job、client、model、data、cost、期間と next-cohort 件数が owner signal の typed authorization と完全一致する。

Findings

配置の最初の制約は model quality ではなく coverage ontology である。 built-in API が current でも、runtime、hardware、storage、language、download、model readiness を満たす client は一部になり得る。assigned opportunity を分母に残さなければ、local path は実態以上に良く見える。

local と cloud の比較は原価移転と責任移転を同時に測る必要がある。 provider token cost を減らしても、利用者の待ち・storage・battery と、開発者の compatibility・regression・support が増える。hybrid は coverage を救えるが、data transfer、二重 cost、誤 attribution、silent fallback を新たに負う。

個人開発者の競争力は一つの万能 route ではなく、safe terminal を含む routing contract にある。 exact job、client、model、prompt、data、cost、maturity を結び、local-only、cloud-only、consented fallback、人 review、safe degradation を明示すれば、provider change や端末差を bounded change として扱える。

Recommendations

• 最初に一つの customer job と client cohort を選び、同じ accepted outcome で BROWSER_PROVIDED / APP_SHIPPED_LOCAL / OS_NATIVE / CLOUD_EDGE / BOUNDED_HYBRID を比較する。
• current Chrome / Apple path を feature detection と source snapshot で扱い、browser・OS・model update を regression trigger にする。対応 client だけの成功率を全顧客へ外挿しない。
• local-first を採る場合も、model readiness、download UX、device guardrail、cloud fallback の data-transfer contract、safe degradation を release 前に実装する。
• primary を mature な full-loaded placement contribution にし、coverage、accepted outcome、time-to-terminal、fallback、support / regression、privacy / safety veto を同じ週次 snapshot で読む。
• 14 日 pilot では one job、one cohort、one routing revision、one loss cap に限定し、独立 review 後に証拠が支える client / model / period だけ BOUNDED_EXPAND する。

Further Questions

• 最も価値の高い AI job は summarization / extraction / classification か、world knowledge / advanced reasoning / tool action か。
• 現在の利用者は desktop Chrome、Apple Intelligence 対応 native app、mobile Web、企業管理端末のどこに集中するか。
• 初回 download と model unavailable を含む end-to-end wait を、顧客はどこまで受容するか。
• local-only promise が必要な data class と、明示的に cloud fallback 可能な field は何か。
• accepted outcome を user action、human review、schema validator、downstream business event のどれで確定できるか。
• subscription value を job へ配賦する current basis と、support / founder time の測定はあるか。
• browser / OS model update を検知し、prompt / tool / safety regression を再実行できるか。
• safe degradation は deterministic alternative、manual queue、後処理、feature unavailable のどれか。
• EU その他の地域で、system provider / deployer、direct interaction、content marking / labelling、human review のどれが適用し得るか。

Caveats

• current runtime facts は 2026-08-02 の official documentation snapshot である。browser、OS、model、hardware requirement、language、region、API stage、provider terms は変わり得る。
• Chrome Prompt API は Chrome-specific current implementation であり、他 browser や mobile の portable baseline を証明しない。W3C incubation / draft status と product shipment を分ける。
• Apple の device-scale task guidance は個別 job の品質保証ではない。app、prompt、language、device、OS build と available な model evidence ごとに eval し、system model identifier が opaque ならその限界を残す。
• ONNX Runtime Web は app-shipped local の一実装例であり、全 model、operator、browser、GPU、WASM の互換性・性能を保証しない。
• EU Article 50、METI guidelines、民事責任手引き、NIST AI RMF は個別の legal conclusion、免責、safe harbor、product approval を与えない。
• contribution は管理用 model で、会計利益や銀行現金ではない。value allocation、founder internal rate、device impact、long-term retention が不明なら UNKNOWN を残す。
• 14 日 pilot では長期 retention、rare incident、model drift、全 client coverage、法的適合を確定できない。maturity と recheck trigger を継続する。