FUTURE THINKING

端末の引き継ぎは脱獄ではない：CAP はいかに制御権を監査可能な社会契約に変えるか

「AI が端末を引き継ぐ」という言葉は、世間の語感では災害予告のように響く。なぜなら多くの人の頭に浮かぶイメージはただ一つだからだ：あなたが眠っている間に、それはあなたのスマホを自分のものにする；あなたが見ていない間に、それはあなたのコンピュータを自分のものにする；あなたが認可していなくても、それは「ついでに何かをやる」ことができる。

この種の恐怖は根拠なきものではない。過去 2 年間で、私たちはあまりに多くの事故を見てきた：権限の暴走、データの誤削除、権限を超えた呼び出し、ブラックボックスな意思決定、責任追及の不能。ひとたび AI が「質問への回答」から「外部への手出し」に変わると、社会のそれへの寛容度は瞬時にゼロになる。

だから私はずっと強調してきた：AI を放任してはならず、人間の監護下で行動しなければならない。 しかしこの言葉が立場にとどまっているだけでは、現実を変えることはない。プロトコルに、ランタイムに、端末制御のあらゆるゲートに書き込まなければならない。

Control Authority Protocol（CAP）はまさにそのような「ゲートプロトコル」だ。それは AI をより賢くすることを担当しない；極めて素朴でありながら、社会が AI を受け入れられるかを決定する一つの問いに答えることだけを担当する：

この Fay（iFay または coFay）はこの行為を行うことを許されているのか？

1. iFay 体系における CAP の単一責務：認可検証と制御権管理

CAP の位置づけは抑制的だが、確固たるものでもある：

それは唯一のコア責務を担う——Fay が Human Prime（自然人の責任主体）または Official Post（公式ポスト/公共役割）の認可を得ているかを検証し、もって正当に端末リソースへアクセスすること。

この一文は 5 つのエンジニアリング動作に分解できる：

認可検証：端末は Fay が携帯する認可クレデンシャルが合法・有効・未失効であるかを検証する。
セッション管理：検証通過後に制御セッションを確立し、完全なライフサイクルを管理する。
制御権協調：人と Fay の間、Fay と Fay の間でリソース制御権のハンドオーバーを協調する。
リソースアクセス階層化：リソースアクセスを read/write/execute/configure に階層化し、「一度認可すればすべて開放」となるのを避ける。
生存検知：ハートビート検知とタイムアウト回収によって、「ゾンビセッション」が端末リソースを長時間ロックすることを避ける。

私がこれを「社会契約プロトコル」と呼ぶのは、それが「あなたができるかどうか」を製品 UI の心理的ヒントから、システム層面の事実検証へと変えるからだ。

2. CAP が明確に行わないこと：能力、アイデンティティ、知性、いずれも管轄しない

健全なプロトコルは自分が何を行わないかを知らねばならない。さもなければ万能接着剤と化し、最終的に制御不能になる。

CAP は明確に以下を担当しない：

Fay のアイデンティティ作成と管理（それは FayID/アイデンティティシステム）。
Fay の知性的推論と計画（それは Ego/思考層）。
端末リソースのビジネスロジック（それは端末自身）。
下層のネットワーク伝送実装（WebSocket/gRPC は重要ではない）。
オペレーティングシステム内部のセキュリティメカニズム（OS 自身のサンドボックス/権限モデルを CAP が代替しない）。

CAP の責務境界が明確であるほど、それは監査可能なガバナンスインフラとなり、業務理由に侵食される「セキュリティパッチ」にはならない。

3. なぜ「制御権」はプロトコル化されねばならないか：さもなくば責任は決して貫通しない

私たちが今行っている認可は、最も一般的な形態として：アプリがダイアログを出し、あなたが「許可」をタップすると、それから「長期間許可」となる。

人間がソフトウェアを使う時代でさえ、これは十分に酷いものだった； Fay が端末を引き継ぐ時代では、これは直接的な災害となる。

なぜなら Fay の行動は一度のタップではなく、連続した一連の行為だから：アプリを開き、データを読み、判断を生成し、動作を実行し、例外を処理し、引き続き実行する…… この行為に「制御セッション」という明確な境界がなければ、責任は時間の中で蒸発してしまう。

CAP が制御権をプロトコル化する核心的価値は二点：

認可を心理的な感覚から検証可能なクレデンシャルに変える
行動を散漫な操作から責任追及可能なセッションに変える

事故が発生したとき、ようやく答えられるようになる：誰がいつ、どんな認可範囲でこのセッションを開始したか？セッションはどれだけ続いたか？どのリソースを操作したか？最終的に誰が失効させ／誰がタイムアウト回収したか？

これが「責任貫通」の前提だ。

4. オフライン主体・オンライン補助：CAP のリアリズム

私は CAP のコア設計原則に強く同意する：オフライン主体・オンライン補助。

その背後にあるのは現実的な判断だ：ネットワーク中断は、人間から制御権を奪うべきではないし、監護下にある Fay の可用性を奪うべきでもない。

CAP はこの判断を二つのメカニズムで受け止める：

オフライン認可（Authorization_Descriptor）：暗号化ファイル、ローカルで検証可能。
オンラインチケット（Trusted_Ticket）：オンライン時にリアルタイムの失効と動的調整能力を提供する。

この組み合わせの利点は「漸進的デグレード」にある：

ネットワークがあるときはより強いリアルタイムセキュリティを得る；ネットワークがないときもシステムは検証可能な認可下で動作し続けることができ、人間を手動の時代へ突き戻すことはない。

iFay を人の延長としたいなら、一つの現実を受け入れねばならない：人の生活は常時オンラインではない。

5. CAP の危険点：端末に近づくほど、監護体系と結びつかねばならない

CAP 自身は「監護のセマンティクス」を担当しない。それは「あなたがこの行為を許されているか」だけを担当する。

しかし CAP を「権限検証」から「無制限の引き継ぎ」へ変えた瞬間、それは脱獄ツールへと変わる。だから CAP の設計は、より上位の監護体系と結びつかねばならない：

Human View：人間がいつでも確認、回顧、介入できる。
Faying：制御権の引き渡しは明示的、立証可能、失効可能でなければならない。
Rogue Fay：監護関係が成立しないとき、外部に手を出すよりも停止することを選ぶ。

私は AI が端末を引き継ぐことに反対しない。私が反対するのは「責任の受け止め点のない引き継ぎ」だ。

端末の引き継ぎは脱獄ではない。それは契約を結ぶようであるべきだ：境界が明確、監査可能、失効可能、責任追及可能。

CAP が行うのは、この「契約」を端末層で実行可能にすることだ。

6. coFay シナリオ：公共役割の制御権はより敏感

iFay が引き継ぐのが個人の端末であるとき、責任主体はあなただ。 coFay が引き継ぐのが病院システム、航空システム、行政システムであるとき、責任主体は組織と公共ポストだ。

この違いが一つのことを決定する：公共役割の制御権は「内部規定」だけに頼ることはできず、監査可能、申し立て可能、対外的に説明可能でなければならない。

さもなくば効率は直接的に権力のブラックボックスに変わる：

なぜトリアージはあなたを列の最後尾に振り分けたのか？
なぜリスク管理はあなたを拒否したのか？
なぜ教育システムはあなたにラベルを貼ったのか？

これらの意思決定に coFay が関与するとき、CAP は保証しなければならない：認可元が明確、セッション境界が明確、リソースアクセス階層化が明確、失効経路が明確。

これが AI 時代において公共サービスがなお信頼されうる基本条件だ。

7. 結語：真の難点は「引き継げるかどうか」ではなく「あえて引き継がせるかどうか」

技術的には「端末の引き継ぎ」は神秘的なものではない。本当に難しいのは、いかにして社会が端末を委ねる勇気を持てるか、だ。

私が考える答えは、より強力なモデルでも、より美しい UI でもなく、以下である：

AI は人の監護下で行動しなければならない；
制御権はプロトコル化されねばならない；
認可は検証可能でなければならない；
セッションは監査可能でなければならない；
失効は到達可能でなければならない；
失踪は自動回収されねばならない。

CAP が iFay 体系で担うのは、最も素朴な一環だ：「私はあなたにこれを許す」を端末層の実行可能な事実に変えること。

この最低ラインが回避されない限り、AI は社会に長期的に存在しうる。さもなくば、私たちは次のパニックを加速して作り出しているにすぎない。