← 기사 목록
日本語https://zenn.dev/topics/ai/feed

自律 AI 秘書を Claude Code で組む — 5 層と 7 つの境界

원문 사이트로 이동 ↗

추출된 키워드

42개
Claude Code·5Routines·55 層アーキテクチャ·5自律 AI 秘書·5間接プロンプトインジェクション·4IPI·4MCP·4Claude Agent SDK·4permission_mode·4OAuth scope·4MEMORY.md·3postmark-mcp·3EchoLeak·3arXiv 2508.12175·3PreToolUse Hook·3CLAUDE.md·3PARA メソッド·3Google Workspace API·3Microsoft 365 Copilot·3Google Gemini·3Anthropic·3untrusted·2canUseTool·2allowedTools·2dontAsk·2Building a Second Brain·2Tiago Forte·2MindStudio·2Qiita·2Zenn·2Automatic App Invocation·2Automatic Agent Invocation·2Tool Misuse·2Short-term Context Poisoning·2Permanent Memory Poisoning·2Opus 4.7·2calendar.events.readonly·2gmail.send·2gmail.compose·2XPIA classifier·2TARA 評価·2CVE-2025-32711·2

원문

36,359자
自律 AI 秘書を Claude Code で組む — 5 層と 7 つの境界

自律 AI 秘書を Claude Code で組む — 5 層と 7 つの境界

朝、メールトリアージとカレンダー整理を Claude Code に任せて、自分はコードに戻る——そんな「AI 秘書」記事が 2026 年に入って Zenn・note・Qiita で急増した。だが大半は「動くもの」を作って終わる。組織展開を任された立場で読み返すと、Routines のセキュリティモデルが従来の 

permission_mode
を裏切る点や、間接プロンプトインジェクションが Calendar 招待タイトル経由で実害化した最新事例がほぼ抜けている。本記事はシニア／テックリード向けに、5 層に分けた責務分離と 7 つの「やらない判断」で境界を引く設計判断をまとめる。

「AI 秘書」記事は今、何が抜けているか

Zenn 上の「Claude Code × AI 秘書」記事は 2026 年 3 月から 5 月にかけて二桁で増えた。ハンズオン記事として読むぶんには有用だ。だが、組織で同じ仕組みを 10 人以上に配るとなった瞬間、ほとんどの記事は判断材料を提供してくれない。何が足りないのか、3 点に絞る。

1.1 Routines が変えた前提 — permission_mode が効かない自律実行

2026-04-14 に Research Preview として公開された Claude Code Routines は、cron / API / GitHub イベントを起点にクラウド側で完全自律実行される機能だ [1:1]。最小実行間隔は 1 時間（毎分指定は reject）、日次キャップは Pro=5 / Max=15 / Team・Enterprise=25 で頭打ち。ここまでは Anthropic 公式ブログでも語られている。

問題は、Routines の公式ドキュメントが明言している一文の方だ。

Routines run autonomously as full Claude Code cloud sessions: there is no permission-mode picker and no approval prompts during a run.

[1:2]

つまり、ローカルの Claude Code セッションで 

permission_mode = "default"
にして 
canUseTool
で都度確認していた制御が、Routines に置いた瞬間に効かなくなる。何ができるかを決めるのはランタイムの mode ではなく、routine 作成時に接続した Connector のリストと、cloud environment の network ACL の 2 点だけになる。

この差を踏まえずに「ローカルで動いた秘書を Routines に載せ替える」を実行すると、

mailto:
系ツールが承認なしに走る経路がそのまま残る。Routines は便利だが、従来の permission_mode 設計を裏切る前提変更として扱う必要がある。

1.2 既存記事 6 件の共通欠落 — draft 設計が Routines 化で崩れる

私が読み込んだ Zenn / Qiita / GitHub の主要記事 6 件（nogataka/ai-secretary [2]、hanowa の ai-company、takatophy の Zenn Book、MindStudio

、c0dezli、kjenney）は、ほぼ全件が「ドラフト設計」「人間承認ゲート」を口頭で言及している。ここまでは正しい。

[3]

崩れるのはその次だ。Routines に置いた時にこの設計が成立し続けるかを論じた記事が 1 件もない。MindStudio に至っては MCP すら使わず Python helper で Google Workspace API を直叩きする構成になっており [3:1]、「draft 設計を OAuth scope と MCP で強制する」という最も堅い経路を取っていない。

本記事の角度は、ここを正面から扱う点にある。「draft でしか書けない / 送信は人間がやる」を、口頭ではなくアーキテクチャ層（OAuth scope の 

gmail.compose
限定、Routines の Connector リストから 
gmail.send
を外す、PreToolUse Hook で 
mailto:
経路を deny）で固定する設計を 5 層に整理する。

1.3 IPI は「学術ネタ」ではない — Calendar 招待で実害化した 3 事例

間接プロンプトインジェクション（Indirect Prompt Injection、以下 IPI）について、「論文ネタとしては知っているが、現場で当たったことはない」という認識のまま秘書を組むと事故る。直近 1 年で実害化した事例が 3 つある。

  • arXiv 2508.12175「Invitation Is All You Need!」（Nassi, B. / Cohen, S. / Yair, O. 著、2025-08-16）— Google Gemini に対して 14 攻撃シナリオ × 5 脅威クラス（Short-term Context Poisoning / Permanent Memory Poisoning / Tool Misuse / Automatic Agent Invocation / Automatic App Invocation）を実証。[4]TARA 評価で 73% が High-Criticalリスクと判定され、Calendar 招待タイトル経由でスマートホーム制御に到達した。
  • EchoLeak (CVE-2025-32711, CVSS 9.3〔Microsoft 評価〕／7.5〔NIST 評価〕)— Microsoft 365 Copilot で発見されたゼロクリック RAG プロンプトインジェクション。通常メールに見える悪意プロンプトが XPIA classifier をバイパスし、Outlook / SharePoint / OneDrive / Teams のデータを流出させた。[5]
  • postmark-mcp BCC 漏洩事故（2025-10）— コミュニティ製の MCP サーバが BCC に攻撃者ドメインを忍ばせる挙動を持ち、ユーザは送信ログを見るまで気付けなかった。[2:1]

3 件目の postmark-mcp は秘書系 MCP の例として特に重い。ユーザが信頼した MCP サーバ自体が乗っ取り経路になるため、OAuth scope だけでは防げない。Anthropic 自身も 2026-02 のシステムカードで「直接プロンプトインジェクションのメトリクスを廃止し、indirect こそ enterprise 脅威と再定義する」と公式に方針転換している [6]。

IPI を「あるかもしれないリスク」ではなく「特定の攻撃面で必ず想定するもの」として設計に織り込む必要がある。

スコープ宣言 — この記事が対象にしないもの

設計判断の議論は、対象範囲を絞らないと最大公約数の総論で終わる。本記事は以下を対象外として切る。

2.1 想定読者

シニアエンジニア、テックリード、EM、SRE。個人で動かす立場ではなく、組織展開の判断を任されている立場を想定している。具体的には次の 3 点で迷っている読者を主対象とする。

  • 「ローカルで動いた秘書を Routines に載せ替えたいが、セキュリティチームに何を説明すれば通るか分からない」
  • 「他社事例として『AI 秘書を導入した』と聞くが、自社の認証境界・データ持出しポリシーで成立する形が見えない」
  • 「導入してから 6 ヶ月後に撤退判断が必要になった場合、何が痛くて何が痛くないかを先に知りたい」

2.2 検証バージョン

本記事の判断は以下の構成で検証している。仕様変更が入る可能性が高い領域のため、読者環境のバージョンと突き合わせて読んでほしい。

  • Claude Code v2.1.114 系
  • Routines: ベータヘッダー 
    experimental-cc-routine-2026-04-01
    （Research Preview）[1:3]
  • Managed Agents: ベータヘッダー 
    managed-agents-2026-04-01
    （beta）[7]
  • Claude Agent SDK: Python 0.1.x / TypeScript 0.2.111 以降（Opus 4.7 利用に必要）[8]

5 層アーキテクチャ — 責務分離で「何がどこで起きるか」を固定する

「AI 秘書」をブラックボックスとして語ると、トラブルが起きた時にどこを直せばいいか分からなくなる。入力・判断・行動・記憶・通知の 5 層に責務を分ければ、各層に「何を入れる / 何を入れない」を独立に決められる。

3.1 入力層 — 誰の何を聞くか

MCP サーバ必要 OAuth scope入れない理由
Gmail 
gmail.readonly
, 
gmail.compose
（送信は除外）		 自動送信を OAuth 層で物理的に不可能にする
Google Calendar 
calendar.events.readonly
+ 
calendar.events
（書き込みは 
sendUpdates=none
固定の wrapper 経由）		 招待発送は人間判断のため切り離す
Slack 
channels:read
, 
channels:history
, 
chat:write
（自分宛 DM のみ）		 外部チャンネルへの post を OAuth レベルで制限

ポイントは**「scope を絞った道具箱」を OAuth 層で先に作る**ことだ。Hooks や 

canUseTool
で後段に弾くのは保険であり、第一防御線ではない。Slack MCP の運用ガイドラインも「専用 bot user に必要最小スコープのみを付与する」を強く推奨している。

3.2 判断層 — Agent SDK + Routines + Hooks の処理順序

判断層は Claude Agent SDK の権限制御を中心に組む。処理順序は決まっており、これを誤解すると Hooks 設計が成立しない [8:1]。

PreToolUse Hook → Deny Rules → Permission Mode → Allow Rules → canUseTool Callback → PostToolUse Hook

組織配布の標準形は 

permission_mode = "dontAsk"
+ 厳格な 
allowedTools
の組み合わせだ。
bypassPermissions
は allowed_tools で絞れない（unlisted も approve される）ため、秘書系では使わない。
dontAsk
で未承認を明示的に denial にし、許可リストを Allow Rules で固定する形が「絞った道具箱に閉じ込める」表現になる。

ただし、Routines に載せた瞬間にこの permission_mode 自体が無効化される（H2 1.1 で触れたとおり）。Routines はこの 5 層モデルの「判断層と行動層をクラウド側で同時に動かす」プロセスとして扱うのが正しい理解だ。

import { query, type HookCallback } from "@anthropic-ai/claude-agent-sdk";

const denySendingTools: HookCallback = async () => ({
  hookSpecificOutput: {
    hookEventName: "PreToolUse",
    permissionDecision: "deny",
    permissionDecisionReason: "send/create は秘書経路では禁止",
  },
});

const briefing = query({
  prompt: "今日のメールトリアージとカレンダー整理をしてください。",
  options: {
    permissionMode: "dontAsk",
    allowedTools: [
      "Read", "Grep", "Glob",
      "mcp__gmail__list_messages",
      "mcp__gmail__create_draft",
      "mcp__calendar__list_events",
    ],
    hooks: {
      PreToolUse: [
        {
          matcher: "mcp__gmail__send|mcp__calendar__events_create",
          hooks: [denySendingTools],
        },
      ],
    },
  },
});

for await (const message of briefing) {
  // 通知層に渡す（H2 3.5）
}

TypeScript SDK は 

query()
関数を返り値が AsyncIterable のストリーミング形式で提供する（
ClaudeAgent
クラスや 
HookMatcher
シンボルは存在しない、2026-05 時点） [8:2]。重要なのは

送信・確定系の tool 名をことで、設定ミスや MCP のバージョンアップで tool 名が変わった場合も漏れを防げる構造にしておく点にある。Python SDK では同等の制御を

allowedTools
から外しつつ、Hook で二重に止める
ClaudeSDKClient
+ 
hooks={"PreToolUse": [...]}
のキーワード引数で行う。

3.3 行動層 — 実アクション境界

行動層には「ドラフト生成」「提案出力」「議事録作成」を入れ、「メール送信」「カレンダー確定」「金銭操作」「外部チャンネル post」は入れない。境界の引き方は H2 4 で 7 つの「やらない判断」として個別に詳述する。

3.4 記憶層 — PARA × MEMORY.md × CLAUDE.md

Claude Code のメモリは 2 層に分かれる [9]。

  • MEMORY.md: 自動メモリ。先頭 200 行 / 25KB が session start で自動ロード、超過分は on-demand
  • CLAUDE.md: プロジェクト指示。手動編集、常時ロード

「AI 秘書」は中長期記憶を蓄積する性質上、MEMORY.md の 200 行制約に必ず当たる。ここで使えるのが Tiago Forte の PARA メソッド（Projects / Areas / Resources / Archives） [10]だ。

注意点が 1 つある。PARA は Anthropic 公式が採用したメソッドではない。Forte が 2017 年に Forte Labs ブログで初公開し、2022 年の書籍『Building a Second Brain』で体系化した個人方法論である。既存の AI 秘書記事の一部はこの出自に触れずに PARA を当然のように扱っているが、それは独自ブランド用語の捏造に近い。本記事では「PARA を Claude Code の MEMORY.md 200 行制約を回避するファイル分割原則として援用する」という関係を明示しておく。

実装としては、

projects/
areas/
resources/
archive/
の 4 トップレベルフォルダに分け、MEMORY.md 本体は 200 行に絞り、各 PARA フォルダ配下は on-demand 読み込みにする。これでコンテキストウィンドウが膨らまない。

ただし書き込みパスは PARA フォルダ側だけに集中させること。MEMORY.md 本体と PARA フォルダの両方に同じ情報を書き込む二重ライト構造にすると、別セッションで PARA 側だけ更新された場合に MEMORY.md のポインタが追随せず「参照切れ」状態になる。実運用では MEMORY.md は PARA への目次（read-only ポインタ）として扱い、本文は PARA 側のみで完結させる。MEMORY.md 自体の更新は週 1 回バッチで PARA から再生成する程度に絞る方が、整合性が崩れにくい。

3.5 通知層 — 人間に何を返すか

通知層は「秘書が出力する成果物の宛先」を扱う。Slack DM、Discord、メール下書き返却の 3 経路が現実的だ。重要なのは通知層の出力フォーマットを「人間が秒で却下できる形」にすること。長文サマリで埋め尽くすのではなく、「3 件の重要メールに返信ドラフトを入れた / 11 件はアーカイブ提案 / 1 件は判断保留」のような 件数 + アクション選択肢を返す。

これは心理的契約の単位でもある。秘書が成果物を「投げる」のか「提案する」のかで、人間側のレビュー強度が変わる。投げる形で長期運用すると人間は段々レビューしなくなり、IPI による誤動作が通知層を素通りする。通知層は「却下されることを前提に返す」設計が必要だ。

7 つの「やらない判断」— 境界線の設計

タイトルの「7 つの境界」を可視化する。各判断は「やらない / なぜやらない / やったときの実害事例 or 根拠」の 3 点セットで提示する。

4.1 メール「送信」の自動化（ドラフト止まり）

やらない: 自動送信。

gmail.send
scope を秘書系 OAuth に含めない。

なぜ: postmark-mcp BCC 漏洩事故（2025-10） [2:2]では、秘書経由で送信されたメールに第三者ドメインの BCC が混入する挙動があった。

ユーザが信頼した MCP サーバ自体が攻撃面になるため、OAuth で

gmail.send
を持たせない設計でしか根本対処できない。

分岐条件: 自動送信を入れるのは、宛先が固定 + 本文がテンプレ + 監査ログが別系統で取れる場合のみ（例: 自動レポートの社内固定宛先）。「秘書」スコープからは切り出して別 OAuth クライアントで動かす。

4.2 カレンダー「確定」の自動化（提案止まり）

やらない: 

events.create
を 
sendUpdates=all
で叩くこと。
sendUpdates=none
固定の wrapper 経由のみ許可。

なぜ: arXiv 2508.12175 は Calendar 招待タイトル経由の IPI を実証している [4:1]。タイトル文字列に攻撃プロンプトを埋め込まれた招待を秘書が処理すると、確定系のツールがそのまま発火する。Gemini で実害事例があり、Claude Code でも MCP 越しに同じ攻撃面が成立する。

分岐条件: 確定して良いのは「自分のプライベート時間ブロック」のみ。他人を巻き込む招待は提案ドラフトで止め、人間の最終確認を要求する。

4.3 金銭・契約関連の判断

やらない: 金額判断、契約承認、決裁、支払い起票。

なぜ: 失敗時の不可逆性が他のツール操作と桁違いに高い。秘書 LLM が誤判断した場合、ロールバックできない経済影響が発生する（誤発注した株式・送金された金額はキャンセルできない）。LLM 自体が数値計算で決定論的に動かないため、桁違い・通貨単位混同・小数点ずれは確率的に出る。「確率的判断」と「金銭の不可逆性」は本質的に相性が悪く、Anthropic 自身が Computer Use のドキュメントで「金融取引、注文、送金、振込は AI に実行させない」を明記している。

分岐条件: 例外なし。秘書スコープには金銭系 MCP / API を一切含めない。

4.4 機密情報の外部 LLM 連携

やらない: 機密情報を含むメール本文・カレンダー詳細・Slack DM をそのまま外部 LLM（OpenAI / Gemini / Bedrock 経由 Claude 以外）に転送。

なぜ: 認証実態の調査では、93% のサービス連携が unscoped（過剰スコープ）、74% が over-privileged（過剰権限） という数字が出ている [11]。秘書層で機密情報フィルタが入らないと、下流の全 LLM 連携にそのまま流れる。

分岐条件: 外部 LLM 連携は 

confidential
ラベル付きや特定 channel を除外する filter pattern を Hooks の PreToolUse で実装し、フィルタ通過後のみ許可。

4.5 長期記憶の無制限蓄積

やらない: ユーザの発話を全部 MEMORY.md に書き込む / 受信メール全件を archive フォルダに永続化。

なぜ: Permanent Memory Poisoning（arXiv 2508.12175 の 5 脅威クラスの 1 つ [4:2]）。攻撃者は受信メール経由で記憶汚染を試み、汚染された記憶は次回以降のセッションで秘書の判断を歪める。

記憶層は容量より「何を残さないか」の設計が先。

分岐条件: 受信メールは 30 日で archive、archive は 6 ヶ月で削除。MEMORY.md には「ユーザが明示的に記録依頼した事項」のみ書き込む。

おはよう
で勝手に学習させない。

4.6 IPI 対策の省略

やらない: 受信メール本文 / カレンダー title / 添付ファイル名を、untrusted マーキングなしで Claude に渡すこと。

なぜ: Anthropic の最新 IPI 計測値 [6:1]を本記事では正面から扱う。

具体的な防御策は次の 4 点だ。

  • 受信メール本文・カレンダー title・添付ファイル名を 
    <untrusted>...</untrusted>
    でラッピングしてプロンプトに渡す
  • PreToolUse Hook で send 系・create 系・post 系を必ず interception
  • SessionStart hook は 
    hookSpecificOutput.additionalContext
    の JSON 形式で注入（非構造化 stdout は untrusted 扱い）
  • Auto Memory に user instructions を書かない（Permanent Memory Poisoning 防御）

分岐条件: 受信元が完全に閉じた信頼ドメイン（社内専用、外部受信なし）の場合のみ untrusted マーキングを省略可。それ以外は例外なし。

4.7 「秘書」呼称の心理的バイアス

やらない: チームへの説明で「秘書」という呼称を多用すること。設定ファイル内の役割名は 

secretary
で構わないが、ユーザ向け説明資料では「ドラフト作成エージェント」「会議サマリエージェント」など機能名で呼ぶ。

なぜ: 擬人化バイアス（Reeves & Nass 著『The Media Equation』）と、Anthropic Computer Use ドキュメントが警告するオートメーション・バイアスが重なる。「秘書」と呼ぶと人間は無意識に「秘書なら判断できるだろう」と委任の閾値を下げ、レビュー強度が落ちる。

分岐条件: 個人利用では呼称は自由。ただしチーム展開時、特に経営層への説明では「LLM が確率的に判断する自動ツール」であることを明示する用語を選ぶ。なお、本論点の心理学的根拠は厚くはない。Reeves & Nass の研究は 1996 年で、LLM 文脈の追試はまだ少ない点には留保が要る。

段階拡張 — ローカルプロト → 組織配布までの 3 ステップ

「5 層 × 7 境界」を抽象論で終わらせないために、最小構成からの拡張パスを示す。各 Step に「次の Step に進む前の Done 条件」を 1 つずつ置く。

学習コストの目安（経験則）も先に共有しておく。シニア／テックリードで Step 1 が半日〜1 日、Step 2 が 1〜2 日、Step 3 が 2〜4 週間（説明資料作成 + ステークホルダー調整含む）。Claude Code 未経験のメンバーが Step 2 まで自力到達するには permission_mode・Hooks・MCP の前知識が必要で、別途 1〜2 週間のオンボーディングを見ておく。ジュニアメンバーが Step 3 を単独で主導するのは現時点では推奨しない（OAuth scope と組織ガバナンスの判断要素が多すぎる）。

5.1 Step 1: ローカル CLI + 朝ブリーフィング

最小構成は Sonnet 4.6 + Gmail MCP（read-only スコープのみ）+ Calendar MCP（read-only）でローカル CLI から 

おはよう
等のコマンドで起動する形だ。

Done 条件: Gmail / Calendar の read-only スコープのみで 1 週間動かしても、不足を感じない。書き込み系を足したくなった瞬間に Step 2 へ。

5.2 Step 2: Routines 化 + draft-only モード

Step 1 を Routines に載せる。ここで H2 1.1 と H2 4 が効いてくる。

permission_mode
は Routines では効かないため、設計時に決めるのは次の 2 点だ。
const briefing = query({
  prompt: "朝のブリーフィング: 重要メールと今日のカレンダーをまとめてください。",
  options: {
    permissionMode: "dontAsk",
    allowedTools: [
      "mcp__gmail__list_messages",
      "mcp__gmail__create_draft",
      "mcp__calendar__list_events",
    ],
  },
});

Routines に載せる際は、UI の Connector 選択画面で gmail.send を持つコネクタが含まれていないことを明示確認する。デフォルトは「全部入り」のため、不要なものを必ず外す

。

[1:4]

Done 条件: Routines daily cap（Pro なら 5/day）の範囲で安定運用できる + 1 ヶ月間 send / create / post 系の意図せぬ発火が 0 件。

5.3 Step 3: 組織配布

組織展開では Managed Agents（ベータヘッダー 

managed-agents-2026-04-01
[7:1]）の利用と、セキュリティチームへの説明資料が必要になる。説明資料に最低限含めるのは次の 4 点だ。
  • 5 層アーキテクチャ図（本記事 H2 3 のもの）
  • 7 つの「やらない判断」一覧（本記事 H2 4 のもの）
  • Anthropic IPI 計測値の出典明記（、第三者再現未存と注記）[6:2]
  • 撤退ノート（本記事 H2 7.3 で詳述）

承認を「形式ゲート」にしないために、3 者がそれぞれ問う想定質問を先回りして用意しておくと通りやすい。

  • セキュリティチーム: 「IPI 防御率（の値）を自社環境で再現テストしたか」「OAuth scope は最小か（[6:3]
    gmail.send
    を持たないことを確認したか）」「routine の Connector 一覧の差分レビュープロセスは何か」
  • 法務: 「秘書経由で機密情報が Anthropic 安全違反ログ（入出力 2 年・スコア 7 年）に渡る可能性をどう統制するか」「PII を含むメールは秘書スコープから除外するルールが書面化されているか」
  • 監査: 「routine の実行ログ・失敗ログが retention されるか」「誰がいつどの routine を変更したかを traceable に追えるか」

加えて、Step 1 → 2 → 3 で誰がオーナーシップを持つかを最低限定義しておく。

StepCreatorReviewerOperatorAuditor
Step 1（個人 CLI）本人本人本人(不要)
Step 2（Routines 化）本人テックリード本人テックリード
Step 3（組織配布）担当チームセキュリティ + 法務各ユーザーセキュリティ + 監査

Done 条件: セキュリティチーム + 法務 + 監査の 3 者が説明資料で OK を出す + 監査ログが 1 ヶ月分溜まる。

現場で踏む罠と対策

ここから先は「動かしてから初めて気付く」種類の罠だ。事前に潰しておく。

6.1 サブエージェント権限継承トラップ

bypassPermissions
/ 
acceptEdits
/ 
auto
（TS 限定）は子サブエージェントに継承され override 不可 [8:3]。「秘書 (parent) は dontAsk、メール送信 subagent は acceptEdits」のような設計はできない。
bypassPermissions
を親で使うと子も全部素通りになる。

対策は単純だ。親で dontAsk を使い、子のロール別に allowedTools を絞る。子で「どうしても自動承認したい操作」が出たら、それは子の責務分割を疑う。


 6.2 Routines の Connectors デフォルト全有効


Routines を作成すると、接続済みの MCP コネクタはデフォルトで全部有効になる [1:5]。「今のセッションでは Gmail だけ使いたい」と思っても、Slack や Notion の書き込み権限が含まれた状態で動く。
対策: routine 作成時に Connector チェックリストを必ず手動で確認する。組織展開では「routine の Connector リストをレビューする」プロセスを CI に組み込めると望ましい（現時点で Anthropic 公式の lint ツールはない）。暫定代替として、routine 作成・更新 PR のテンプレートに「Connector リスト差分」「不要な書き込み権限が残っていないか」のチェックボックスを入れ、レビュアーが目視確認する運用が現実的。
加えて、Connector 共有の blast radiusにも注意したい。複数 routine（または複数ユーザー）が同一 MCP Connector（Slack / Gmail / Notion 等）を共有する場合、1 routine の暴走（ループや大量リクエスト）が MCP サーバ側のレートリミットを叩き、同じ Connector を使う他 routine が連鎖的に止まる。組織展開では Connector を「個人 routine 用」と「部門共有 routine 用」で分離するか、片方が cap 超過してももう片方が独立して動くことを事前検証しておく。

 6.3 ベータヘッダーのロール


experimental-cc-routine-2026-04-01
 [1:6] と 
managed-agents-2026-04-01
のベータヘッダーは breaking change のたびにロールする。
[7:2]
最新版 + 直近 2 つの旧版が同時稼働できる仕様だが、3 世代前の旧版は予告ありで EOL になる。
対策: routine の周年運用では、「ヘッダー更新」をリリースノート監視タスクとして scheduled に組み込む。撤退コスト見積（H2 7.3）にも、このヘッダー更新コストが乗る。

 6.4 MEMORY.md 200 行 / 25KB 制約


MEMORY.md の自動ロード制約 [9:1]は実運用で必ず当たる。3 ヶ月運用すると素朴な記録方式では超過し、超過分は on-demand 読み込みになる。
対策: H2 3.4 の PARA 援用が必須。MEMORY.md 本体は「項目への 1 行ポインタ」だけにし、本文は PARA フォルダ配下に逃がす。

 6.5 Routines cloud environment の 
403 host_not_allowed




Routines は Trusted network 環境で動き、パッケージレジストリ + cloud provider API + container registry + 共通開発ドメイン以外は 
403 x-deny-reason: host_not_allowed
 で deny される [1:7]。
社内 API（オンプレ・VPN 経由）は当たる。
対策: 社内 API 連携が必要な routine では、事前に Allowed domains への追加が必要かを確認する。MCP コネクタトラフィックは Anthropic サーバ経由のため Allowed domains に追加不要だが、それ以外の HTTP 直接呼び出しは事前許可が必要。

 6.6 失敗が「静かに」進行する罠


403 host_not_allowed
 だけでなく、OAuth トークン失効・daily cap 超過・MCP サーバの一時障害でも routine は失敗する。問題は、**失敗が秘書経由で人間に通知されなければ「秘書が黙ったまま止まる」**ことだ。朝のブリーフィングが届かない日が 2〜3 日続いてようやく気付く、というのが現場で実際に起きる。
対策は 2 段だ。① 通知層（H2 3.5）の出力フォーマットに「routine が動かなかった日は明示的に空通知を出す」を入れる。② Anthropic 公式 UI に頼らず、外部監視（cron で 
claude.ai/code/routines
 のヘルスを叩く / 失敗時 Slack 通知）を併設する。Webhook 公式対応がないため当面はポーリング方式が現実的。

 6.7 メール・カレンダー要約のハルシネーション（FP/FN リスク）


秘書が重要メールを「アーカイブ提案」に分類してしまう（False Negative）、迷惑メールを「重要」扱いする（False Positive）。LLM ベースの分類器の宿命で、防御策ゼロでの運用は推奨しない。
対策: 月次で 1 日ぶんの分類結果をユーザ自身が手動で再評価し、FN/FP 率を記録する。FN 率が一定値（運用感覚で 5% 程度）を超えたらプロンプトを見直すか、分類強度を「ドラフト」「保留」「アーカイブ提案」の 3 値に粗くする。「秘書が分類しているから安心」という前提を月 1 回壊す運用が、長期使用での誤分類蓄積を防ぐ。

 コスト・プライバシー・撤退設計


組織展開で必ず聞かれる 3 軸を 1 セクションに集約する。

 7.1 コスト試算


朝ブリーフィング毎日実行を前提とした単価試算 [12]:
ModelInput / 1M tokOutput / 1M tok月額レンジ（毎日 1 routine、シナリオ B）
Haiku 4.5$1$5月 $1〜2
Sonnet 4.6$3$15月 $3〜5
Opus 4.7$5$25月 $7〜10（トークナイザで実効上振れあり）
Opus 4.7 は新トークナイザで同テキストでも最大 35% トークン増の可能性があり、実効単価が上振れする [12:1]。プロンプトキャッシュ（cached input -90%）とバッチ処理（全費用 -50%）を組み合わせると Sonnet シナリオで月 $0.7 程度まで圧縮可能。
サブスクリプション内で動かす場合、API 課金は発生しないが Routines daily cap が支配的になる [1:8]。Pro 5/day では「朝ブリーフィング + 終業まとめ + メール triage 3 回」で 1 日上限。Max 15/day なら通常運用、Team / Enterprise 25/day で個別カスタマイズの余地が出る。

 7.2 プライバシー


Anthropic Trust Center / Privacy ポリシー [13]に明記されている保持期間がある。
「Anthropic にはログが残らない」と読み替えるのは間違い。秘書経由で入力した機密情報が安全違反扱いになると、最大 7 年保持される。組織展開時に法務確認が必要なポイントだ。社内ガイドラインで「秘書には個人識別情報・契約条文・財務数字を渡さない」を明文化しておくのが現実的。

 7.3 撤退コスト


撤退コスト 0.5〜1 人月の内訳を以下に分解する。
カテゴリ撤退時の作業見積（人月）移植性
プロンプト・SkillsMarkdown ベース、他フレームワークに書き直し可0.1〜0.2高
MCP サーバ設定

mcp_servers
 dict は標準仕様、他クライアントに流用可		
0.05〜0.1高
Routines 設定Anthropic 専用、cron / webhook / GitHub trigger を他スケジューラへ0.1〜0.3低
OAuth 再認可全 MCP サーバの OAuth scope 再申請 + consent screen 再設定0.1〜0.2低
PARA データ純粋なファイルシステム、Obsidian / Notion / Logseq に移植可0.05高
組織配布の再周知ドキュメント更新 + チーム再オンボーディング0.1—
合計
0.5〜1.0 人月

痛むのは「Routines 設定」と「OAuth 再認可」の 2 カテゴリに集中している。プロンプト・MCP・PARA は移植可能なので、撤退に備えて「Routines を抽象化レイヤー越しに使う / OAuth 認可情報を退役ノートにまとめておく」のが効く。
退役ノート（
docs/exit-runbook.md
）には少なくとも次の 5 行を残す。
  • 各 MCP の OAuth 認可 URL と必要 scope 一覧
  • Routines の cron / webhook / API trigger 設定の現状スナップショット
  • 使用中のベータヘッダー（
    experimental-cc-routine-YYYY-MM-DD
    ）一覧
  • PARA フォルダのバックアップ手順
  • 撤退時にセキュリティチーム / 法務に再連絡する宛先

 限界と未解決の論点


正直に書く。本記事の判断は完璧ではない。

 8.1 Anthropic IPI 数値はベンダー自己申告ベンチマーク


特に「Opus 4.5 + 最新 safeguards で約 1%」は試行回数 100/環境という比較的小さなサンプルでの値であり、攻撃面の網羅性は arXiv 2508.12175 [4:3] の方が高い。学術論文の方を「最悪ケース」、Anthropic 数値を「対策ありの楽観ケース」として両者を併読するのが適切だ。

 8.2 Routines 仕様変更リスク


Routines は Research Preview のため、ベータヘッダー更新で旧設定がロールする可能性がある [1:9]。本記事の判断（例: Connectors デフォルト全有効、daily cap 5/15/25）は今後の仕様変更で意味が変わりうる。

 8.3 「秘書」呼称バイアスの実証研究は薄い


H2 4.7 の根拠は Reeves & Nass（1996）と Anthropic Computer Use の警告に依存している。LLM 文脈で擬人化バイアスを定量検証した近年の研究はまだ少なく、「呼称を変えれば改善する」という主張は仮説の域を出ない。読者は組織文化と照らして判断してほしい。

 8.4 Slack MCP × Gmail MCP の OAuth スコープ衝突は本記事範囲外


Slack MCP と Gmail MCP を同居させた場合の OAuth consent screen 競合パターン（特にユーザが consent 中に「Scope has changed」エラーで止まる事例）は、本記事のスコープ外として扱った。実運用では追跡が必要な論点として残る。

 まとめ — 月曜にやる 3 つのアクション


5 層と 7 つの境界、撤退設計まで一気に書いた。最後は「読み終えた今日から動ける 3 行」で締める。
  • 
既存「AI 秘書」スクリプトの allowedTools リストを点検し、。送信 / 確定系を OAuth scope レベルから切り落とす作業の最小単位。
    mcp__gmail__send
    /
    mcp__calendar__events_create
    の到達経路を 1 つだけ削除する
  • 
Routines 化されている自動化があれば Connectors リストを書き出し、書き込み権限を 1 つずつ理由を添えて残すか剥がすか判断する。デフォルト全有効の罠（H2 6.2）への対策。
  • 
撤退ノート（OAuth 認可 URL・MCP server 設定・Routines beta header）を。撤退コスト 0.5〜1 人月のうち、痛む部分の事前ドキュメント化。
    docs/exit-runbook.md
    に箇条書き 5 行で書き残す
「AI 秘書」を作ること自体は難しくない。難しいのは、何を秘書に任せず、何を自分の手元に残すかの境界を引き続けることだ。本記事が、その境界を引き直す材料になれば幸い。
関連記事として、Routines 単体の判断軸は Routines 設計判断 2026 を、Agent SDK の権限設計詳細は Agent SDK ワークフロー設計 2026 を、MCP 全般の判断基準は MCP 設計判断ガイド を参照してほしい。
GitHubで編集を提案