ローカルAI編 / 第105話

第105話:ユイの未公開ノートが、送信前に雲へ並んだ|端末AIなら秘密は外へ出ない?

ピコルート第105話。端末内で整理するはずの未公開ノートが、モデル停止後にクラウド送信待ちになる。fallback、queue、syncを分け、送らない境界を作ります。

オンデバイスAIローカルAINPUクラウドfallbackプライバシー境界10分更新

UPLOAD IN 00:14

ユイのscreenで、十四秒が減り始めた。

送信buttonは押していない。

それでも、未公開noteの全文がcloud queueへ入っている。

document       observation-private.md
classification unset
local model    unavailable
fallback       cloud-large
queued bytes   184,221

noteには、新しい企画、予算、失敗した仕事、家族へまだ話していない迷いが混じっていた。

「端末AIを選んだはずなのに」

ユイは、Wi-Fi iconを押しかけた。

残り十二秒。

端末で推論する機能と、app全体の通信は同じではない

on-device AIは、modelのinferenceをsmartphoneやPCなどの端末上で実行する構成だ。

対応する処理なら、inputをremote serverへ送らずに実行できる。

latency、offline動作、dataを端末内に保ちやすいことが利点になる。

AppleのCore MLは、modelをdevice上で動かし、CPU、GPU、Neural Engineを活用するframeworkだ。

GoogleのML Kitにも、device上で動くAPIがある。

ただし、これはapp全体のnetwork trafficが0という意味ではない。

local inference
  model execution on device

separate possible network paths
  model download / update
  cloud fallback
  account sync
  logs / telemetry
  search / external tools
  backup

今回のappには、local modelが使えないときだけcloudへ切り替える設定があった。

ユイは初期設定でHELPFUL FALLBACKを許可していた。

「普段は端末内」という表示は正しかった。

「絶対に送らない」という設定にはなっていなかった。

local modelは、熱で止まっていた

イトがdiagnostic panelを開く。

local model package        present
NPU session                released
memory pressure            high
thermal state              elevated
local retry                after 60 sec
cloud fallback             immediate

NPUは、neural networkの計算を効率よく動かすためのprocessorだ。

同じdeviceでも、modelやoperatorの対応、memory、battery、temperatureによってCPUやGPUを使うことがある。

「NPUがある」と「いつでも同じmodelをlocalで完走できる」は同じではない。

local modelが止まること自体は、秘密の外部送信を意味しない。

その後のfallback policyが、送るか止まるかを決める。

残り八秒。

よくある誤解:端末AIを選べば、入力は何があっても外へ出ない

model selectorだけでは、data boundaryを固定できない。

端末内のmodelを選んでも、appがfallback、sync、telemetry、toolを別経路で使えばnetwork trafficは生まれる。

逆に、cloudを使うこと自体が常に不適切でもない。

送ってよいdataを、利用条件と目的を確認してremote serviceへ渡す選択はあり得る。

問題は、dataの機密度より先に「使えるmodel」がrouteを決めたことだ。

wrong order
  model available?
    -> choose local or cloud

safer order
  may this data leave?
    -> choose allowed execution routes

残り七秒。三つの選択

queueには184,221 bytes。

local modelは一分後まで使えない。

朝までに、会議用の論点を七つへ整理する必要がある。

A:Wi-Fiだけを切る

この十四秒のuploadは止められる。

しかしqueueとfallback設定が残れば、network復帰後に再送されるかもしれない。

update、sync、telemetry、toolのどれがnoteへ触れたかも分からない。

B:名前と金額だけを消して、cloud fallbackを許可する

大きなmodelをすぐ使える。

ただし、人間関係や失敗の経緯など、名前以外の組み合わせからprivate contextが残る。

何を送ってよいかを決める前に、時間切れでredaction範囲を決めることになる。

C:documentをNO_NETWORKへ分類し、queueを破棄して、local unavailableなら止める

note workspaceからのoutboundをpolicy側でdenyする。

fallback、sync、telemetry、external toolを一つずつ閉じる。

localが戻るまでは、modelなしのmanual outlineだけを作る。

残り四秒。

ユイはWi-Fi iconではなく、document policyを開いた。

「今だけ切るんじゃない。このnoteから出る道を閉じる」

ユイが雲への待ち列を消す

ユイはobservation-private.mdへNO_NETWORKを付ける。

pending payloadを開かずに破棄し、fallback switchをSTOP_LOCAL_UNAVAILABLEへ変えた。

ユイが未公開noteのcloud upload gateを閉じ、queued payloadを空にして、端末内のlocal-only workbenchだけを開く

document policy       NO_NETWORK
cloud fallback        DENY
account sync          DENY
content telemetry     DENY
external tools        DENY
local unavailable     STOP

countdownは、残り二秒で消えた。

network cableは挿さったままだ。

他の公開用workspaceは、update checkを続けている。

private noteからの経路だけが閉じた。

queued bytes destroyed       184,221
content upload bytes               0
blocked outbound attempts          3
other workspace traffic      allowed

「cableを抜かなかったの?」

イトが聞く。

「この端末をofflineにしたいんじゃない。このdocumentを送らないと決めたの」

modelが戻るまで、便利さを諦める

local modelの再試行まで五十二秒。

ユイはnoteを人の目で読み、空のcardを七枚置いた。

goal
  extract seven decision constraints

must not do
  invent facts
  rank life choices
  use network

stop
  missing date / amount / owner
  ambiguous reference

一分後、端末が冷え、small local modelが戻った。

長いnoteを八つのchunkへ分ける。

modelは、時間、費用、家族への影響、戻せる範囲、必要な協力、成功条件、中止条件を抽出した。

だが、三番目のchunkにあった「契約更新日」を落とした。

requested constraints       7
local candidates            7
source-linked               6
missing source link         1
human correction            1
cloud content bytes         0
elapsed                    11 min

cloud-largeなら、もっと速く、滑らかに整理できたかもしれない。

local-onlyは、privacyの代わりに正しさを自動でくれる仕組みではない。

ユイは全candidateを元noteの行へ結び、一つだけ根拠がないcardを捨てた。

自分で契約更新日を戻す。

七枚が揃ったのは、十一分後だった。

「外へ出ない」は、観測範囲を決めて確かめる

今回確認したのは、このclosed fixtureにおけるnote本文のcontent upload bytesが0という結果だ。

端末のあらゆる通信が0だったわけではない。

OS、別app、model update、時刻同期などは、別のnetwork boundaryを持つ。

また、端末を紛失したときのstorage encryption、screen lock、backup、他userの権限も別問題だ。

privacy claim to avoid
  "on-device means nothing ever leaves"

claim this fixture observed
  "this document content had no allowed outbound route
   and content upload bytes remained zero"

必要ならnetwork log、OS権限、service設定を別々に監査する。

「local」というlabelではなく、どのdataが、どのprocessから、どのdestinationへ出られるかを確かめる。

雲へ送らなかった七枚を、床のロボットが読んだ

朝、ユイは七枚のcardを机へ並べた。

noteの原文は、local workspaceから出ていない。

cloud queueも空のままだ。

床を走る整備robotが、机の端へ近づいた。

昨夜のtest commandが残っている。

objective     clear the workbench
deadline      before opening
stop zone     unset
owner check   unset

robot armが、七枚のcardをつかんだ。

ユイは、送信gateを閉じた手で、今度は赤いphysical stop barを倒した。

情報が端末の中に残っても、機械の行動が安全とは限らない。

次回、ピコルート第106話。

イトは、「机を片づけて」とだけ命じた|フィジカルAIはどこまで動いてよい?

この物語を、解説で深める

第105話で生まれた疑問を、解説記事で少し深く見ていきます。物語で感じた不思議さを残したまま、言葉と仕組みを順番に整理しましょう。

オンデバイスAIとは?クラウドへ送らず処理する利点を読む

この出来事の「いま」と「次」を分けて見る

オンデバイスAIを、観測と体験へつなぐ