AIは「聞かれたら答える」フェーズから「先に動く」フェーズへの移行を加速しています。今週は、AnthropicがOrbitという先回り型アシスタントを発表し、iOS 27がClaude・Geminiをデフォルトに選べる設計を打ち出す一方、エージェントの多段展開で権限管理と攻撃伝播が実運用の急所として急浮上した週でした。「賢さ」の競争が一段落した今、使い方の設計と守り方の設計が、プロダクトの差を決めます。
AnthropicがOrbitを発表：先回り型AIが"通知"を超える
Anthropicは5月6日の「Code with Claude」カンファレンスで、プロアクティブ型アシスタントOrbitを発表しました（TestingCatalog）。OrbitはGmail・Slack・GitHub・Calendar・Drive・Figmaなどのツールに接続し、ユーザーが問いかける前に状況の要約や推奨アクションを届けます（PCWorld）。
これまでのAIアシスタントは「聞いたら答える」モデルが中心でした。Orbitはその前提を崩し、カレンダーの空きを見てスケジュールを提案したり、GitHubのPRをレビューして朝のブリーフィングに盛り込むなど、AIが「仕事の流れを先読みして割り込む」位置に移ります（Phemex）。
実務上の示唆：先回り型AIは「割り込みコスト」の設計が鍵
- プロアクティブ通知が増えるほど、いつ・何を・どの優先度で届けるかのポリシー設計が、使い勝手と疲弊感を分けます。通知量の自動チューニング（重要度スコアリング、サイレント時間帯の学習）が、Orbitのような製品の差別化点になるはずです。
- 開発側では、既存ツール連携の認証フロー（OAuth、APIキー管理）に加えて「Orbitがどのデータに触れてよいか」のスコープ設計が急務です。Slack全チャンネル読み取りとGitHub全リポジトリ読み取りを無制限に与えると、情報漏洩リスクが集約されます。
- ユーザーが自分の代わりに動くAIを許容するには、何をしたかが見える（監査ログ）・**いつでも止められる（即時無効化）**の二点が信頼の最低条件です。プロダクト設計でこの二点を後回しにすると、インシデント時に手が打てなくなります。
iOS 27がAIのデフォルト選択を開放：Claude・Geminiがエコシステムに入る
Appleは、iOS 27・iPadOS 27・macOS 27でApple IntelligenceのデフォルトAIをサードパーティに変更できる設計を採用すると報じられました（MacRumors）。Writing Tools・Image Playground・Siriの各機能でClaude・Gemini・その他モデルが選択肢になるとされています（9to5Mac）。
これはブラウザのデフォルト解放に匹敵する変化です。これまでiOS上のAI体験はAppleのサーバー側処理とOpenAI連携に依存していましたが、ユーザーが信頼するモデルを軸に選べる時代になります。
実務上の示唆：モデル選択が「設定」になると、品質保証の責任が分散する
- エンタープライズ向けMDM（Mobile Device Management）の文脈では、どのAIをデフォルトに許可するかの管理ポリシーが必要になります。会社支給端末でGemini・Claudeへの情報送信を許可するかどうか、情報セキュリティ担当が判断を迫られる場面が増えます。
- アプリ開発者側は、ユーザーが選んだAIに応じた出力品質のばらつきを前提にした設計が必要です。一種類のモデルを前提にしたUXは、デフォルト変更後に崩れる可能性があります。
マルチエージェントの認可設計が構造的問題として可視化
arXivに投稿された「Authorization Propagation in Multi-Agent AI Systems: Identity Governance as Infrastructure」（arXiv:2605.05440）は、マルチエージェントシステムにおける認可の伝播を、ワークフローレベルの設計問題として定式化しました。
論文は「推移的委任（transitive delegation）」「集約推論（aggregation inference）」「時間的有効性（temporal validity）」という3つのサブ問題を特定し、認可アーキテクチャに必要な7つの構造要件を導きます（arXiv:2605.05440）。
注目すべきは、現状のエンタープライズ展開の数字です。セキュリティレポートによれば、エージェント導入チームの81%が計画段階を超えて実装に入っているにもかかわらず、セキュリティ承認が完了しているのは**わずか14.4%**です（Gravitee）。また、88%の組織が今年、確認済みまたは疑わしいセキュリティインシデントを経験しており、エージェントを独立したアイデンティティとして扱っているチームは22%に留まります（Gravitee）。
実務上の示唆：エージェントを「ユーザーの代理」ではなく「独立した主体」として設計する
- 最も多いリスクは共有APIキーの使い回しです。エージェントが人間の認証情報を借りて動くと、誰が何をしたかのトレーサビリティが失われます。エージェントごとにサービスアカウントを発行し、スコープを最小権限に絞る設計が、事後調査の基盤になります。
- 認可の「時間的有効性」は盲点になりやすい要素です。タスクが完了した後もAPIキーやOAuthトークンが有効なまま残ると、意図しない継続アクセスが発生します。タスク単位で認可を発行・失効させる仕組みが、長期運用での安全弁になります。
- 46%のチームが既存システムとの統合を最大の課題と挙げています（Gravitee）。“賢いエージェント"より先に、「エージェントが安全に本番システムへアクセスできる回路」を整備することが、実際の競争力になります。
100体超のエージェント網に1通の悪意ある指示が伝播する脆弱性
Microsoftの研究は、フロンティアモデル（GPT-5など）でも、単一の悪意ある入力が100体超のエージェントに連鎖するネットワーク環境では対応が困難であることを示しました（Microsoft Research）。
研究が使った手法は「Whimsical Strategies」と呼ばれ、既存の安全評価では想定外の分布外（out-of-distribution）戦略を使って安全ガードを突破します。単一エージェントへの攻撃が、マルチエージェント系全体に伝播することで、影響範囲が爆発的に広がる構造です（Microsoft Research）。
実務上の示唆：「一点を守る」から「伝播を止める」へ
- 単一エージェントのガードレール強化だけでは、エージェント連鎖の攻撃には不十分です。エージェント間通信の検証レイヤー（指示の出所を確認、異常なスコープ拡大を検知）が、境界防御の一部として必要になります。
- 爆発半径（blast radius）の制限が設計の核心です。あるエージェントが侵害されたとき、何にアクセスでき、何ができないかを事前に定義し、横方向への移動（lateral movement）を構造的に防ぐ権限設計が、被害を局所化します。
- 攻撃が「想定外の分布から来る」という前提は、テストケースの設計に影響します。既知の敵対入力に対するレッドチームだけでなく、通常業務に見える指示の中に潜む逸脱を検出する評価が、本番環境の安全確認に必要です。
まとめ：AIが「先手を打つ」ほど、設計の責任も「先手」が要る
今週の動きをまとめると、AIは反応型から先行型へのシフトを加速させており（Anthropic Orbit）、プラットフォームも選択の自由を開放しつつあります（iOS 27）。一方で、マルチエージェントの認可は構造的に未整備のまま展開が先行し（arXiv:2605.05440）、攻撃伝播は一点の突破が全体に波及する形で深刻化しています（Microsoft Research）。
プロダクトを作る側に求められるのは、「どう賢くするか」と同時に「どう止めるか」「誰が何をしたかをどう追うか」「どこまでを許可の範囲とするか」を設計の最初から組み込む姿勢です。先行するエージェントの能力に、ガバナンスの設計が追いつくかどうかが、この先の実用展開の分水嶺になりそうです。