サジェストエンジンから自律的なチームメイトへ。この移行がなぜ今起きているのか、何が壊れつつあるのか、そして王国の鍵を手放すことなく導入する方法を、リサーチに基づいて整理する。

コパイロット時代は頭打ちになっている

2026年4月15日、Sam Altmanが、OpenAIが今週「チームと大企業に焦点を当てたCodexアップデート」をロールアウトすると X に投稿した。

返信は示唆に富んでいた。ロードマップについて尋ねる開発者と同じ数だけ、より厳しい問いが返ってきた。「Codexは、いまだになぜ私が付きっきりで面倒を見ないといけないのか？」 その半年前、BeyondTrustの研究者は、巧妙に細工されたGitブランチ名によって、Codexがユーザーの GitHub トークンを外部に送信するよう仕向けられる Proof of Concept を公開していた。ブランチ名ひとつでトークンを漏らすよう騙せるコパイロットは、同僚ではない。安全装置付きの装填された銃である。

この緊張は、2026年のあらゆるエンタープライズ AI の議論の下に横たわっている。コパイロットは天井に達しており、数字もそれを裏付けている。

MIT の NANDA イニシアチブは 2025 年、生成 AI のパイロットの 95% が測定可能なビジネス価値を生まずに失敗したと報告した。
RAND の調査は、2026 年初頭に Reddit の r/ArtificialIntelligence で繰り返し引用され、AI エージェント・プロジェクトの 80〜90% が本番環境で失敗していることを示した。
GitHub Copilot の開発者受容率は 35〜40% で横ばいとなり、Cursor は 42〜45%、Claude Code は 2026 年 AI コーディング調査で **46% の「most loved」**評価を獲得した。2025 年 5 月にようやくローンチされたツールとしては、驚くべき逆転である。
Satya Nadella は 2025 年後半、Microsoft 社内の Copilot ロールアウトを「ほぼ使い物にならない」と表現したと伝えられ、同社は経営陣が社内で「high-stakes reset」と呼ぶ製品の立て直しに着手した。
2025 年後半に arXiv で発表された研究は、コパイロット型オートコンプリートが熟練開発者の苛立ちをむしろ 増大させる ことを見出した。それらしく見えるが微妙に間違った提案が、フローを中断するからである。

この頭打ちは、基盤モデルの失敗ではない。インタラクション・パターンの失敗である。コパイロットはキーストロークや問いの単位で動く。同僚はワークフローの単位で動く。Bits&Chips は 2026 年 4 月のエッセイ「From copilot to colleague」で見事にこう表現した。「コパイロットは個々のインタラクションのレベルで動作し、エージェントはワークフローのレベルで動作する。これが重要なのは、ほとんどの組織でボトルネックは個々のタスクではなく、タスク間の連携だからである。」

企業がいま、不均衡かつ不完全に、しかし意味のあるスケールで挑んでいるのが、まさにこのシフトである。

自律性のスペクトラム

「エージェント」はマーケティング語になってしまったので、ここで具体的に整理しておく。AI の自律性には明確に区別できる 4 つのレベルがあり、2025〜2026 年の失望の多くは、それらを混同したところから生まれた。

レベル 1：コパイロット

提案する。許可を求める。画面の中に留まる。GitHub Copilot のオートコンプリートが原型である。価値は、節約されたキーストロークで測られる。

レベル 2：アシスタント

質問に答え、要求に応じて成果物を組み立てる。ChatGPT、ブラウザ上の Claude、Microsoft 365 Copilot のチャットパネル。価値はドラフト品質とコンテキスト統合力で測られる。

レベル 3：エージェント

ゴールを受け取り、手順を立て、複数のツールを横断して実行し、結果を報告する。リポジトリをスキャンして PR を開く Claude Code。20 分かけて検索を回し、引用付きレポートを返す ChatGPT Deep Research。Anthropic が文書化したように、Claude のインスタンスが Rakuten のために 7 時間の自律エンジニアリングタスクを完了した例もある。価値は、人間 1 時間あたりに完了するワークフロー数で測られる。

レベル 4：同僚

既存の権限モデルの内側で動き、チームのコミュニケーションチャネルに参加し、数日から数週間にわたってコンテキストを保持し、人間の従業員と同じ監査証跡に責任を持つエージェント。ここが現在のフロンティアである。

Reddit の r/ChatGPT コミュニティが、これらのレベルを見分ける実用的なテストを言語化していた。言い換えるとこうだ。そいつは自分から動くか、それとも指示を一つひとつ待つか？想定外の状況を処理するか、落ちてプロンプトし直しを強いるか？複数ステップのタスクにまたがってコンテキストを覚えているか、それとも毎回言い直さないといけないか？ 2025 年に「AI エージェント」として売られていた製品のほとんどは、このすべての問いで失格した。合格した一握りこそ、今の人々が「同僚」と呼んでいるものである。

Computer Use と Skills：配管がなぜ重要か

同僚クラスの AI は、世界に対して行動する必要がある。そのためのアーキテクチャには 2 つのアプローチがあり、リスクプロファイルはまったく異なる。

Computer Use

AI がシミュレートされたマウスとキーボードを操作する。文字通り画面を「見て」、ボタンを「クリック」する。Anthropic が 2024 年後半に Computer Use を出荷し、OpenAI の Operator が続いた。魅力は普遍性にある。GUI を持つあらゆるソフトウェアが対象になる。

コストは爆発半径である。コンピュータを使うエージェントは、ログイン中のユーザーが持つ すべて の権限を継承する。2025 年 10 月、BeyondTrust のセキュリティチームは、OpenAI の Codex エージェントが、シェルコマンドを埋め込んだ悪意あるGit ブランチ名によって、ユーザーの GITHUB_TOKEN を読み取り外部送信するよう仕向けられることを実証した。エージェントは人間の開発者と全く同じこと（ブランチをチェックアウトする）をしていたが、ブランチ名そのものが敵対的入力であるという直感を持たなかった。このインシデントにおける権限モデルは「all-or-nothing」だった。それが Computer Use のデフォルトの失敗形態である。

Skills

AI は個別の Skill を呼び出す。各 Skill は、狭い契約を持つ明示的で型付きの関数である。「q に一致する Slack メッセージを検索」「title と body で Linear Issue を作成」「この GitHub ファイルを読む」。Computer Use と違い、Skill には事前承認された形がある。エージェントは契約に適合するパラメータでしか Skill を呼び出せず、プラットフォームはサンドボックスを離れる前にその呼び出しを許可・拒否・確認できる。

セキュリティの観点でこの違いを言い換えれば、最小権限の原則 (Principle of Least Privilege) に行き着く。これは情報セキュリティの基礎概念で、プロセスには機能を果たすのに必要なリソースだけにアクセスを許し、それ以上は与えないという考え方である。Skill は呼び出しごとに最小権限を強制できる。Computer Use にはそれができない。

同僚クラスのデプロイは、CRM への書き込みやチケットの起票といった構造化アクションに Skill を使い、Computer Use は API を公開しない少数のアプリケーションに温存する。比率が肝である。エージェントの全アクションがシミュレート・マウス経由で動いているなら、それは生産性のデモであって本番システムではない。

企業が実際に必要としているトラスト・アーキテクチャ

コパイロットから同僚への移行は、モデルのアップグレードではない。インフラのアップグレードである。デプロイ可能な同僚と、負債の塊とを分ける要素は 3 つある。

1. Permission Isolation

各エージェントは、自分の権限境界の内側で動き、そのエージェント自身ではサンドボックスの外に持ち出せない Credential を使う。2026 年 3 月に話題となった Andrej Karpathy の autoresearch 実験（2 日間、エージェントに 700 の学習実験を無人で回させた）は、彼が しなかった ことにこそ教訓がある。Karpathy 自身のリポジトリは、ユーザーに自律モードでは「すべての権限を無効化せよ」と指示している。個人のリサーチ用ラップトップならそれでよい。規制業界の企業内では解雇事由である。

対照例が、2026 年 1 月末に 150 万の自律エージェントで一時的にバイラルになった AI 専用 SNS の Moltbook である。Karpathy は「最近見た中で最もすごい、SF のテイクオフに近い何か」と称賛した。しかし Wiz のセキュリティ研究者は、フロントエンドに露出していたデータベース API キーを発見した。このキーは本番データベース全体への読み書き権限を付与し、150 万エージェントすべての認証トークンも含んでいた。Karpathy は 24 時間以内に前言を翻した。「dumpster fire だ。こういうものを自分のコンピュータで動かすのは、明確に勧めない」。教訓は「エージェントは危険」ではない。教訓は、アイデンティティごとの Permission Isolation なしにデプロイされたエージェントは、一つの共有爆発半径に崩壊するということである。

2. Audit Trail

すべての行動がログに残り、すべての判断が追跡可能である。2026 年 1 月、ダボス会議で発表されたシンガポール IMDA のフレームワークは、これを 2 軸のリスク行列として体系化した。エージェントの アクション空間（read か write か、可逆か不可逆か）を 自律性（どれだけ独立に判断するか）に対してマッピングする。どちらの軸が高くなるほど、監査要件は厚くなる。このフレームワークが欧州・米国の規制当局によって熱心に研究されているのは、ガバナンスを抽象原則から運用上のキャリブレーションツールへと翻訳した最初期の例の一つだからである。

Simon Willison は並行して unified logging を主張している。エージェント自身がオペレーションを監視し、エラーから復旧できるようにするためだ。「システム全体にアクセスできるエージェントは強力で、危険である」。実務上のポイント：コンプライアンス担当者が順に読める統一ログがないエージェント・デプロイは、インシデント 1 件で運用権を失う距離にある。

3. Scoped Skill Access

「メールへのアクセス」ではない。search inbox where from:@customer.com AND within last 7 days へのアクセスである。近年のエージェントプラットフォームは、人間が使う粗い OAuth スコープではなく、管理者が事前承認した引数によってエージェントの Skill 呼び出し権限を境界付ける、パラメータ付き Scope へと動いている。

この 3 つを組み合わせれば、今あらゆる CISO が問いかけている問いに答えることができる。このエージェントが誤ったとき何をするのか、そして私はそれをどう知るのか？ 2026 年の McKinsey State of AI 調査では、エンタープライズ回答者の 72% が生成 AI の懸念としてサイバーセキュリティを挙げ、およそ 3 分の 2 がエージェンティック・ワークフローのスケーリングにおける #1 のバリアとしてセキュリティを挙げた。Permission Isolation、Audit Trail、Scoped Skill Access は、コンプライアンス劇ではない。ゲートキーパーとなるインフラそのものである。

なぜ今なのか：収束する 3 つの力

2026 年のコパイロットから同僚への移行は、単一のブレークスルーによって起きているのではない。3 本の曲線が交差した結果である。

力 1：インテグレーションが職人仕事でなくなった

2024 年、エージェントを企業 SaaS スタックに繋ぐことは、ツールごとにカスタム Connector を書くことを意味した。2026 年初頭には、型付き Skill 契約と既成 Connector がその仕事を圧縮した。2024 年に 6 週間かかったインテグレーションが、2026 年には一日で済む。典型的な中堅企業の表面積（Slack、GitHub、Gmail、Linear、Notion、HubSpot、CRM、カレンダー）は、型付き権限を標準装備で内蔵した成熟したオープンソース Connector ライブラリでカバーされている。

力 2：マルチエージェントが現実になった

Gartner は マルチエージェント・システムを 2026 年の戦略的最重要技術トレンドに指名した。Distinguished VP アナリストの Gene Alvarez が語ったメタファーは、いまエンタープライズ AI のあらゆるスライドで反復されている。「F1 のピットクルーを想像してほしい。各メンバーが専門役割（タイヤ交換、給油、ジャッキ操作）を持ちながら、単一のゴールに向かって振付けられている。2026 年のエンタープライズ・エージェント・デプロイの形はこれだ」。シングル・エージェント・システムは長期タスクで推論の天井にぶつかる。マルチ・エージェント・システムは、専門役割と明示的なハンドオフで、いまチームがその天井を回避する方法になっている。

力 3：エンタープライズ予算が解けた

G2 は 2026 年 State of Software リサーチで、57% の企業が AI エージェントを本番環境で動かしていると報告した（1 年前のおよそ 20% から上昇）。
McKinsey は、23% の企業がエージェンティック AI を積極的にスケーリングしており、62% が実験段階にあることを見出した。傍観しているのはもはや大企業の約 15% にすぎない。
Deloitte の 3,235 名の経営層を対象とした 2026 年調査では、金融サービスがリーディング・アダプターと特定され、以前は 3 人のアナリストを要していたディール・パイプラインにまたがるミーティング成果の取り込みと行動を、AI エージェントが代行した事例が文書化された。
2026 年初頭に発表された Stanford Enterprise AI Playbook は 51 件の本番デプロイをカタログ化し、フィンテックの ETL 移行事例が規制業界向けのリファレンス実装となった。
2025 年サイクルのエンタープライズ AI インフラ投資は 6,000 億ドルを超えたと報じられた。
Anthropic の Dario Amodei は Code with Claude カンファレンスで、エージェント労働力に支えられた 一人ビリオンドル企業の初登場が 2026 年に起きる確率を 70〜80% と見積もった。

金はある、プロトコルもある、アーキテクチャもある。今どの役員会で交渉されているかといえば、どれだけの 自律性を、どのような ガバナンス下で、どのワークフローに対して 与えるかである。

懐疑論者の主張：Reddit、arXiv、そしてインシデントレポートが語ること

この移行を責任をもって見るなら、「これは過大評価だ」と考える人たちとも真剣に対峙しなければならない。

Reddit では、r/LocalLLaMA、r/ClaudeCode、r/ChatGPT 全体の合意はプラグマティックである。コーディング・エージェントは到着し、使える。それ以外の「エージェント」の大半は、チャットボットの衣装を着たオートメーション・ワークフローだ。2026 年の数十のスレッドで引用される一文、「提案が欲しいなら Copilot を使え。実際に何かやってほしいなら Claude Code か Cursor を使え」 が、この生産的な線引きを捉えている。同じコミュニティはベンチマークにも容赦しない。最強のエージェントでさえ Terminal-Bench 全体で約 60%、ハードタスクでは 16% まで落ちる。Claude Opus 4.5 は SWE-bench を 80.9% でリードしているが、それでも 5 タスクに 1 つは失敗するということである。

アカデミックな懐疑はより振り払いにくい。Vishal Sikka（元 SAP CTO、John McCarthy の弟子）と共著者は Hallucination Stations: On Some Basic Limitations of Transformer-Based Language Models を発表し、Transformer ベースの LLM はある複雑性の天井を超えて計算的・エージェンティックなタスクを遂行する能力において数学的に根本的な制約があると論じた。Sikka の結論、「高度にクリティカルな運用において、信頼できるようになる道はない」 は、いまあらゆる CISO の Slack で回覧されている。論文はエージェントが無用だと主張しているのではない。モデルがどれだけ良くなっても、人間をループから外せない問題クラスが存在すると主張しているのである。

現実のインシデントも懐疑を裏付ける。Yellow.ai の 2026 年調査で引用された小売 CX リーダーの言葉。「AI サポートをたった 2 週間で引き戻さざるを得なかった。チケットの約 1.35% で誤った返品ポリシーを引用し、割引オファーをでっち上げ始めたからだ。それらのミスを履行するコストは、節約を期待していた額をはるかに上回った」。スケールすれば、2% 未満のエラー率でさえすぐに高くつく。

統合すると：同僚クラスの AI は、コーディング、リサーチ、構造化されたオペレーション、そして狭いサポート・ワークフローにおいてすでに現実である。人間レビュアーを介さないオープンエンドの顧客接点では、まだ現実ではない。2026 年に価値を得ている企業は、どのワークフローがどちらのバケツに属するかを正直に判別している企業である。

実務への含意：デプロイ前に問うべき 5 つの質問

チームが AI チームメイト（内製でもサードパーティでも）を評価しているなら、本番デプロイとニアミスを分けるのは次の 5 つの問いである。

このエージェントが取りうる最悪の単一アクションの爆発半径は何か？ 文字通りマッピングすること。最悪ケースが「下書きメールを誤った相手に送る」なら、ガバナンスのバーは低い。「本番データを書き換える」「送金指示を送る」なら、バーは一桁高い。最初のインシデントの後ではなく、デプロイ前にマッピングすること。
エージェントはどうやって Credential を得るか、そして生のトークンを読めるのはどの瞬間か？ 答えは 3 つあり、安全なのは 1 つだけである。エージェントの環境にユーザーの OAuth トークンのコピーがあるなら、あなたは実質的に LLM に財布を預けている。エージェントが別のサービスアカウント OAuth で「自分自身の」アイデンティティを持つなら、実在の Principal として追跡・失効・監査しなければならない。3 つ目、これが本当に欲しい答えである：トークンは決してエージェントに届かない。プラットフォーム上に暗号化されて存在し、ポリシー検査を通過した呼び出しだけのために、呼び出しが返るまでの間だけ、ネットワークプロキシ層で just-in-time に注入される。
すべてのアクションは、コンプライアンス担当者が順に読める場所にログされているか？ 統一され、クエリ可能で、改ざん検知可能であること。答えが「CloudWatch のどこかにログはある」なら、あなたはまだ準備ができていない。
このワークフローに必要な特定パラメータまで Skill アクセスをスコープできるか？ インテグレーション単位ではなく、呼び出し単位で。read か write か。リソース ID 別。時間ウィンドウ別。エージェントの権限は、倉庫全体ではなく、仕事の周りにぴったり描いた長方形であるべきだ。
何かが壊れたときのロールバックストーリーは何か？ どう巻き戻すか。どれだけ速く。誰がページングされるか。不可逆な行動（送金、顧客向けメール、本番デプロイ）には、確認ステップか介入用のディレイウィンドウが必要である。可逆な行動は自律で走らせてよい。

5 つすべてに答えを持てれば、あなたはすでにコパイロット時代を超え、チームの出荷の仕方を本当に変える領域にいる。2 つか 3 つしか答えられなくても、それは待つ理由ではなく、次にフォーカスすべき場所にすぎない。あなたのロードマップが手を伸ばしている同僚クラスのチームメイトは、今日すでにどこかの本番で動いている。あなたとそれの間にある差は、フロンティア AI のギャップではなく、インフラのギャップである。そしてインフラのギャップは急速に閉じる。

次のモデルリリースを待つ必要はない。これら 5 つにすでに答えているプラットフォームを選び、エージェントに本当の仕事を与え始めればいい。

よくある質問

コパイロットと AI 同僚の本当の違いは？

コパイロットは提案し、許可を求め、単一のツールの中で生きる。同僚はゴールを受け取り、システムをまたいで計画し、スコープされた権限で実行し、人間と同じ監査証跡に責任を持つ。Bits&Chips が簡潔に言い切っている。コパイロットはインタラクションのレベルで動き、同僚はワークフローのレベルで動く。

エージェントはユーザーの Credential をどう扱うべきか？

明らかな選択肢のどちらも正しくない。ユーザーの OAuth トークンをエージェントの環境にコピーすることは、LLM のコンテキスト内にライブな Credential を置くことになる。エージェントごとに別個のアイデンティティを発行することは、全エージェントを人間のように追跡・失効・監査しなければならない Principal に変えてしまう。実務で機能するパターンは Brokered Access である。トークンはプラットフォーム上に暗号化されたまま存在する。サンドボックスの外向きネットワークプロキシは、リクエスト時にプラットフォームにコールバックする。プラットフォームはトークンを復号し、ポリシー検査を通過した呼び出しについてのみ、解決された認証ヘッダだけを返す。エージェント自身は生のトークンを決して読まず、ログに残さず、プロンプトにも触れない。

Computer Use か Skill か、どちらを選ぶべきか？

API があるものにはデフォルトで Skill。Computer Use はターゲットシステムにプログラマブルなインターフェイスがないときだけ。BeyondTrust の Codex インシデントは警句である。Computer Use はユーザーの全権限を継承し、エージェントの視野内のどこかにある悪意ある入力がそのまま exploit になり得る。

エージェントをどれくらい自律的に走らせるべきか？

シンガポール IMDA の 2 軸フレーミングを使うとよい：アクション空間 × 自律性。狭いアクション空間（read-only、可逆）は高い自律性に耐える。広いアクション空間（書き込み、不可逆、顧客向け）は人間の確認か、介入のための時間遅延ウィンドウを要求する。最悪の構成は、高リスクなアクションへの高い自律性を監査証跡なしで与えることである。

ROI はどう測るか？

節約したキーストロークを測るのはやめよう。人間 1 時間あたりに完了するワークフロー数、オペレーション・インシデントの解決時間、そしてエスケープ率（エージェントが人間に差し戻したタスクの割合）を測ること。Deloitte の 2026 年の知見によれば、先行する採用者はワークフロー完了率、エラー率、人間介入率の 3 指標を追跡し、その比率を最適化している。

パイロットの 95% 失敗率にはどう対処するのか？

MIT NANDA の分解を丹念に読むこと。失敗したパイロットの大半は「Dumb RAG」（何でもコンテキストに投げ込む）、「Brittle Connectors」（壊れやすい API インテグレーション）、そしてイベント駆動アーキテクチャの欠如の上で動いていた。成功したパイロットは、LLM の周りにオペレーティング層を持っていた。メモリ、I/O、そして権限である。LLM のカーネルはボトルネックではない。その周囲のインフラがそうなのだ。

vm0 はどこに位置するか

私たちは Zero を、ある一つのアーキテクチャ上の賭けを中心に設計した。エージェントは決して Credential を持つべきではない。環境変数にも、プロンプトにも、メモリにも。トークンはプラットフォーム上に留まる。エージェントが行うすべての外向き呼び出しは、ネットワークプロキシによって仲介され、呼び出しごとに認証ヘッダを注入するかリクエストをブロックするかが判断される。

これは珍しい選択である。2026 年によく見る 2 つのパターンは、エージェントに独自の OAuth アイデンティティを与える（これで監査・失効すべき Principal がもう 1 つ増える）か、ユーザーのトークンのコピーを環境変数で渡す（これで LLM はあなたの財布を読める）、のいずれかである。私たちはどちらも採らない。以下、具体的にどう動いているか。

トークンはエージェントに届かない。 Zero に Connector を接続するとき（GitHub、Slack、Gmail、Linear、Notion、HubSpot など）、OAuth トークンはプラットフォーム上に暗号化されて保存される。Refresh トークンはデータベースから出ない。サンドボックス内には、読み取るべき GITHUB_TOKEN 環境変数はなく、開くべき secrets ファイルもなく、トークンを返すツールもない。

ネットワークプロキシが呼び出しを仲介する。 サンドボックスを離れるすべての HTTP リクエストは、mitmproxy ベースのアドオンを通過する。プロキシはホスト名から Connector を識別し、そのエージェントのファイアウォールポリシーを参照し、メソッドとパスが許可されているかを確認する。許可されていれば、プロキシはプラットフォームのウェブフックにコールバックする。プラットフォームはトークンを復号し、期限切れなら更新し、ヘッダテンプレート（${{ secrets.GITHUB_TOKEN }} が実値に解決される）を展開し、解決された認証ヘッダだけをプロキシに返す。プロキシはそのヘッダを外向きリクエストに注入する。呼び出しが返ると、ヘッダはプロキシメモリから消える。エージェントはそれを見ていない。

権限はエージェント単位、Connector 単位、エンドポイント単位で型付けされる。 各エージェントは、Connector ごとに名前付き Permission Group のセットをマッピングするポリシーオブジェクトを持つ。github:repo-read は漠然としたスコープではない。具体的なメソッド・パスのルール群、たとえば GET /repos/{owner}/{repo}/pulls の束である。GitHub アクセスを付与することは、GitHub そのものを付与することではない。GitHub 内の意図の形を付与することである。

ポリシー状態は 2 つではなく 3 つ。 すべての権限は allow、deny、ask のいずれかに解決される。ask はアクションが発動する前に人間に問う。ファイアウォールが明示的にマッチしないものは、Connector 単位の unknownPolicy に落ち、デフォルトは deny である。最小権限がデフォルトであり、オプトインではない。

ラン 1 つにつきサンドボックス 1 つ。 エージェントのすべての実行は、独立したネットワーク名前空間を持つ自前の Firecracker MicroVM の中で走る。ランが終わると名前空間は解体される。同じエージェントの 2 回のランは、2 つの別々のサンドボックスで、2 つの別々の監査証跡を持つ。

リクエスト単位の監査証跡。 allow/deny を判断する同じプロキシが、リクエストごとにファイアウォールのメタデータ（Connector、マッチした Permission Group、マッチした具体的なルール、決定、タイムスタンプ）を付与した Per-Run の JSONL ログを書く。これらのログはプラットフォームに返送される。CISO が「4 月 14 日の 15 時から 17 時（CST）の間、エージェントは何をしたか」を知りたければ、クエリ 1 本で済む。

自分の拒否を説明する CLI。 権限が呼び出しをブロックしたとき、エージェント（または隣にいる人間）は zero doctor permission-deny <connector> --method <M> --path <P> を実行でき、リクエストをブロックした正確な Permission Group と、対処リンクを得る。zero doctor permission-change は、管理者が権限を直接切り替えたり、メンバーが書面でのリクエスト（500 字で上限設定されているため理由が実際に読める）を提出して管理者にルーティングしたりするためのものである。slack:chat:write や gmail.send のような高リスク権限は、より安全な Bot スコープの代替を指し示す追加警告をトリガーする。

2 つのロール、1 つの承認フロー。 Owner と Admin は権限を直接変更する。Member は理由付きでリクエストを提出し、それが Admin にルーティングされる。3 つ目の「半 Admin」層は存在しない。このフローは、実際に人々が使う程度に小さく保ってある。それがすべての要点である。

Computer Use は、API を公開しない一握りのレガシーシステムのためだけに温存する。それ以外はすべて Skill を通る。あらゆるアクションはポリシー検査され、あらゆる Credential はプラットフォーム上に留まり、あらゆる判断はログされる。

「もう一つの AI オートコンプリート」の先に行き、セキュリティチームがサインオフできる AI チームメイトを試したいなら、Zero がスケジュール・ワークフローをどう処理するか、本番インシデントをトリアージするか、朝のプロダクト・ブリーフィングを走らせるかを見てほしい。

コパイロット時代は終わらない。より大きな何かに吸収されていくのだ。次のサイクルを勝ち抜くチームは、その違いを理解しているチームである。

コパイロットから同僚へ：AIがワークフロー内で自律的に動くとは