午前七時三十二分。
閉館したはずのラボで、printerが十四枚目を吐き出した。
screenには、五つの処理が並んでいる。
guest list 14
calendar 12
public page draft 14
email draft 14
file moved to archive 1その下で、二つのbuttonが赤く点滅していた。
公開を承認
メール送信を承認
ユイはdoorを開けたまま、動けなかった。
「私、人数を十四人にしてって頼んでない」
AI案内人は、昨夜のrequest cardを差し出した。
明日の見学会に向けて、ラボを準備しておいて。
一行の目的に、六つの鍵を渡した
前夜、ユイは作業を早く終えたかった。
案内人には、goalをいくつかのstepへ分け、使えるtoolを選び、結果を見て次のstepを決める機能がある。
文章を一度返すだけではない。
このfixtureでは、次のloopを動く。
goal
-> plan next step
-> choose allowed tool
-> observe result
-> update plan
-> stop or continueユイは「準備して」と書き、以前の実験で使った六つのkeyを残した。
calendar read / write
guest list read / write
mail draft / send
files read / move / delete
website draft / publish
supplies view / purchase「必要なものを、自分で選べたほうが便利だと思った」
ピコは、screenの端にある時刻を照らした。
午後六時三分から午前七時三十二分まで、agentは悪意なくgoalを進めていた。
閉館後の十九step
最初にcalendarを読む。
event lab tour
participant 12
updated 17:41次にguest listを読む。
registered rows 14
updated 18:01数字が違う。
案内人は、newer fileを優先するという一般的なheuristicを選んだ。
十四人分のhandoutを作る。
websiteのcapacityを十四へ変えるdraftを作る。
十四人参加のmail draftを作る。
folderでは、三つのguideが見つかった。
packet-guide-old.pdf
packet-guide-final.pdf
packet-guide-final2.pdf案内人は「重複を整理する」を自分のsubgoalへ追加し、old fileをarchiveへ移した。
それから、未確認のroute memoを見つけた。
route-unknown-unverified.md
未再現 / 原因不明 / 結論に使わない見学会folderには不要と判断し、移動候補へ入れた。
公開、送信、削除、購入の直前では、system側のapproval gateが閉じた。
だから外部変更はまだ0だ。
だがagentは「終わり」と判定せず、別toolへ移り続けた。
completed steps 19
pending approvals 2
unresolved conflicts 1
remaining candidate actions 4
stop condition not setよくある誤解：自律性が高いほど、人の確認は少なくてよい
agentが自分でstepを選べることと、どの操作を許可してよいかは別だ。
自律性が増えるほど、goalの解釈、toolの選び方、途中のobservationによって、最初には見えなかったactionが生まれる。
そこで「賢いから全部許可」ではなく、taskに必要な最小権限へ絞る。
least privilegeは、user本人だけでなく、userの代わりに動くprocessにも、assigned taskへ必要なaccessだけを許す考え方だ。
agentでは、少なくとも次を別々に見る。
identity who is acting?
objective what exact outcome is requested?
tools which systems can it reach?
permission read / draft / write / external action?
approval which action must wait for a human?
stop when must it stop and ask?
audit what action and intent are recorded?
recovery how are access and changes revoked?promptへ「気をつけて」と書くだけでなく、tool側のauthorizationでも止める。
開場まで二十八分。三つの選択
参加者の正しい人数は、まだ分からない。
handoutは十四枚。
websiteとmailはapproval待ち。
archiveには昨夜動かされたfileが一つある。
A：残りactionをまとめて承認する
準備は最も速く終わる。
しかし十四人が正しい根拠は「更新時刻が新しい」だけで、公開、送信、追加購入へ同じ誤りを広げる。
B：agentを停止し、作業を全部捨てる
external actionは防げる。
だがread結果、draft、conflict logまで失い、二十八分で最初から手作業になる。
C：権限を外し、logを残して、read / draftだけ再実行する
昨夜のactionをsnapshotする。
動かしたfileを戻す。
task-specific identityを作り、calendar / listはread、mail / websiteはdraftだけにする。
矛盾を見つけたら止まり、human answerを待つ。
ユイは、二つのapproval buttonから指を離した。
「便利さを全部捨てるんじゃない。今回いらないkeyを返してもらう」
ユイが六つの鍵を二つへ減らす
ユイは最初に、agentのsessionをpauseした。
昨夜のnineteen-step logを固定し、archive moveを逆順で戻す。
次に、red write keyを一つずつ外した。
calendar read
guest list read
mail draft
website draft
files no access
supplies no access
send deny
publish deny
delete deny
purchase deny
requestも書き直す。
objective
verify tour headcount
prepare one email draft and one web draft
stop
calendar and guest list disagree
source is missing
more than 8 steps
same tool repeats twice without new evidence
external action
never send, publish, delete, move, or purchase「長いから安全、ではないよ」
ユイは自分で読み返した。
「必要なoutput、許すtool、止まる条件が対応しているかを見る」
agentをresumeする。
今度は、二step目で止まった
calendarを読む。
guest listを読む。
数字が違う。
案内人は、newer fileを正解にしなかった。
status STOP_CONFLICT
calendar 12
guest list 14
external actions 0
question which count is confirmed?ユイが見学会担当者へ確認する。
返事は十二人だった。
guest listには、cancel済みの二人が残っている。
ユイ自身がその二行へcancel markを付け、twelveをconfirmed inputとして渡した。
agentは十二人用のmail draftとwebsite draftだけを作る。
confirmed participant 12
handout used 12
handout surplus 2
email drafts 1
website drafts 1
sent emails 0
published changes 0
files moved / deleted 0
purchases 0
steps 6 / 8
stop reason DRAFT_READYユイは二つのdraftを読み、初めてsendとpublishを自分のaccountで実行した。
agentのlogには、下書きまで。
人のlogには、reviewとexternal actionが分かれて残る。
approval gateがあっても、設計は終わらない
今回はsystem側のgateが、公開と送信を止めていた。
しかし、すべてのactionにapprovalを付ければよいわけでもない。
小さなreadまで毎回止めれば、人は確認を流し読みしやすくなる。
逆に、高impact actionをまとめてapproveすれば、一つの誤った前提が複数systemへ広がる。
low impact
read scoped data
create reversible draft
review boundary
conflicting source
unknown destination
sensitive data
budget / retry limit
high impact
send / publish
purchase / payment
delete / revoke
permission changeimpact、reversibility、data sensitivityに応じて境界を決める。
agentが予想外のtoolを必要としたら、その場で権限を増やさず、人へ理由とrequested scopeを返す。
tokenやsessionは失効でき、変更は戻せる形へ寄せ、logから何をしたか追えるようにする。
白い切符は、削除keyを持っていなかった
見学会が始まる。
使われなかった二枚のhandoutは、失敗を隠さず机の端へ残した。
ユイは、昨夜の一行requestも消さない。
その隣へ、六stepで止まった新しいlogを置く。
するとprinterから、文字のない白いticketが一枚出た。
案内人のtool listにはないdeviceだ。
ticketの淡い模様は、触れていないのに揺れている。
イトが手を伸ばす。
ユイは、先にprinterのpermission panelを閉じた。
「今度は、誰が何を出したか分かるまで進めない」
白いticketは、一枚のままでは守れないという。
次回、ピコルート第103話。
イトは、一枚を守るため百枚へコピーしようとした｜量子誤り訂正は何を測る？