第98話で二つに分かれた音声cardを、イトは大きいほうの工房へ滑らせた。
「計算力が大きいなら、最初からcloudへ全部送ればいい」
青い送信gateが開く。
その瞬間、ユイがcardの波形を止めた。
「待って。いまの声、後半だけじゃないよ」
波形を三つに切る。
voice segment 1 「ピコ、メモ開始」
voice segment 2 「午後三時に診察。保険証は青いポーチ」
voice segment 3 「棚卸し報告を三点に要約して」二つ目はマコトの個人的な予定だ。
三つ目の仕事に必要なのは、棚卸し報告のうち共有を許可された部分だけだった。
けれどイトが開いたrouteには、raw voice全部と報告全文が積まれている。
送信前previewの赤い帯が、雲の入口まで伸びた。
「どこで計算するか」の前に、何を渡すか
端末の中には、小さな推論工房がある。
modelと入力を端末内に置けば、networkへ出さずに結果を返せる。通信がなくても動かせ、往復時間も要らない。
ただし、端末のmemory、compute、battery、heatに収まるmodelと仕事までだ。
networkの向こうには、remote serviceの推論工房がある。
端末に載せにくいmodelや大きなcomputeを使いやすく、service側でmodelを更新できる。その代わり、requestは送信され、responseは戻ってくる。network待ち、service availability、送ったdataの取扱いも設計に入る。
on-device inference
input -> device model -> result
cloud inference
input -> network -> remote model -> network -> resultピコが、二つの工房を結ぶ一本の橋を照らした。
「appは片方しか使えないわけじゃないよ。featureや一回のrequestの中で、仕事を分けてもいい」
closed fixture：声と要約を二十tick以内に返す
今回のlabでは、違いを追えるように条件を固定する。
deadline tick 20
network unavailable tick 6-12
raw voice blocks 18
share-approved inventory blocks 6
private voice blocks 4
local model
wake detection supported
20-second voice transcription supported
long-report summarization unsupported
remote model
long-report summarization supportedこの数字は製品のbenchmarkではない。routeの差を見るためのlab内fixtureだ。
最初の全量cloud previewでは、十八個のvoice blockと報告全文がupload queueへ入った。
estimated finish tick 28
private blocks in payload 4
offline result no計算が大きくても、networkで止まればdeadlineに間に合わない。
それ以前に、今回のsummaryへ不要な診察メモまで送る理由がない。
よくある誤解：端末AIなら安全、クラウドAIなら危険
計算場所だけで、安全性やprivacyは決まらない。
on-device処理でも、appが結果をsyncする、logへ残す、backupする、別機能が送信するなら、dataは端末外へ出る可能性がある。modelを後からdownloadする設計なら、そのnetworkも別に存在する。
cloud処理でも、送る範囲を絞り、利用者へ示し、通信、access、保存、削除の扱いを決める設計はできる。
確認する単位は「このappは端末AIか」ではなく、この機能で、何が端末を出るのかだ。
check 1 raw inputは送るか
check 2 intermediate data / resultは送るか
check 3 log / retention / secondary useはどう扱うか
check 4 networkが切れたら何が残るか場所は入口であって、結論ではない。
残り十四tick。三つのroute
network lampが消えた。
送信可能になるのはtick 13。deadlineまでは七tickしか残らない。
マコトは、音声cardの隣にある実行buttonへ指を置いた。
「会議までに、メモと要約の両方が要る」
イトの前に三つのrouteが開く。
A：raw voiceと報告全文をcloudへ送る
remote modelへ一つの大きな仕事として渡す。
local modelの制約は避けられるが、不要なprivate segmentまでpayloadに入り、network回復後もfinishはtick 28だ。
B：全部をon-deviceで処理する
raw voiceは外へ出ない。wake detectionとtranscriptionは進む。
しかし、このlocal modelはlong-report summarizationをsupportしていない。要約は返せない。
C：端末で声を分け、許可された要約材料だけcloudへ送る
wake detectionとvoice transcriptionを端末で行う。
診察メモはlocal noteへ保存し、summary requestから外す。共有許可済みのinventory block六個だけを、network回復後にremote modelへ送る。
localとcloudの両方を使うhybrid routeだ。
ピコは答えを言わず、payload previewへinspection lightを当てた。
イトは、赤い全量送信gateと、端末内の白い工房と、六個だけ入る青い送信trayを見比べた。
「大きい工房を選ぶんじゃない。仕事を分けて、渡す荷物を決める」
イトが閉じたのは、雲ではなく全量送信
イトは左手で、raw voice uplinkの赤いgateを閉じた。
右手で、音声cardを端末工房へ差し込む。
local task 1 wake detection
local task 2 voice transcription
local output private note + summary instruction端末工房が、三つのsegmentを文字へ変えた。
イト自身が二つ目をlocal noteへ移し、cloud payloadから外す。
次に棚卸し報告を開き、共有許可済みの六blockだけを青いtrayへ置いた。
送信previewを一行ずつ確認する。
payload destination remote summarization service
payload includes 6 approved inventory blocks
raw voice included no
private appointment no
requested output 3-point summary
network lampが戻る。
イトが青いtrayだけを押し出した。
切断の一tick前に、二つの結果がそろう
端末側から先に、local noteが戻る。
wake detected tick 2
voice transcription complete tick 5
private note saved local
private blocks sent remote 0tick 13、六個のinventory blockがcloud routeへ出た。
remote modelから三枚のsummary cardが戻る。
approved blocks sent 6
summary cards returned 3
observed finish tick 17
missing / duplicate block 0
unapproved block sent 0tick 18、network lampがもう一度消えた。
一tick遅ければ、cloud summaryは戻らなかった。
それでも診察メモは端末のlocal noteに残り、networkが切れたあとも開けた。
マコトが二つの結果を確認する。
「雲を使わなかったんじゃない。雲へ渡す仕事を、小さく決めたんだね」
イトは、閉じた赤いgateへ手を置いた。
「端末かcloudか、じゃなかった。入力のどこを、何の仕事へ渡すかだった」
hybridにも、残るcostがある
今回のCが、いつでも正解とは限らない。
端末modelを置けば、storage、memory、battery、heat、対応device、model更新を管理する必要がある。
cloud側には、network、latency、service cost、availability、送信dataと生成結果の取扱いが残る。
taskを分ければ、localとremoteのversion差、失敗時のfallback、二つの結果を統合するcodeも増える。
音声からprivate部分を機械的に正しく分けられるとも限らない。今回はイトがpreviewを見て、自分で外した。
before enabling an AI feature
what runs on device?
what leaves the device?
what fails offline?
what does the remote service return or retain?製品では、実際の仕様、permission、privacy表示、service policyを確認する。
三つの扉に、同じ「AI」が書かれていた
二つの工房が静かになる。
奥の廊下に、三枚の扉が現れた。
一枚目では写真を分類している。
二枚目では文章を生成している。
三枚目ではrobotが障害物を避けている。
扉の上には、どれも同じ二文字が光っていた。
AI
イトは、今度は大きい扉を選ばなかった。
三枚の前に空のinspection trayを一つずつ置く。
「場所は分けられた。でも、そもそもこの三つを同じ名前で呼ぶのは、なぜだ？」
扉はまだ開けない。
次回、ピコルート第100話。
イトは、AIと書かれた三つの扉を同じ機械だと思った｜AIとは何？