先日「仕事が忙しいので、プライベートに AI 秘書を雇ってみた」という記事を読んだ。著者はClaude Opus 5.5を使い、5日間でホームサーバーの障害調査・Gmailのラベル整理・ふるさと納税の寄附先選定・写真選別などを秘書エージェントに任せ、119件のコミット（うち36件はルール改善）を積んだという記録だった。学びの章で印象的だったのは、「外部ツール連携（メール送信等）は機密情報が手元に入る危険性があるので業務未導入とし、Docker Sandbox内の開発作業に限定する」という結論だ。
私も似た構成（指示書＋権限設定＋フック）で秘書エージェントを動かしているが、スコープが少し違う。元記事は「個人のプライベート」1本に絞った5日間の実験で、メールやチャットなどの外部ツール連携はプライベートの範囲で承認を挟みながら使い、業務での外部ツール連携は見送るという判断に落ち着いた。私の場合は事業（AI駆動の法人運営）と生活（タスク管理・引き継ぎ）の両方を同じ秘書エージェントに横断させており、しかも3ヶ月以上ノンストップで動かしている。業務側の外部アクションも、承認キュー・kill switch・ルーティングという3つの機構で「許可はするが必ずゲートを通す」設計にして、メール送信やSNS投稿も実際にこの秘書経由で動かしている。今回はその3機構を実装レベルで比較してみる。
元記事との差分を一言でいうと
| 項目 | 元記事（araom氏・5日間） | 私の運用（3ヶ月以上） |
|---|---|---|
| スコープ | プライベート専用 | 事業＋生活を1つの秘書に統合 |
| 外部アクション | 危険性を認識し業務未導入に決定 | 承認キューを通して実行まで許可 |
| 安全装置 | 指示書＋権限設定＋Pythonフックの3層 | ルーティング＋承認キュー＋kill switchの3層 |
| 記憶の扱い | （言及なし、都度の指示書ベース） | セッション終了時にhandoffファイルへ構造化保存 |
| 規模 | 単一エージェント | 役割別に分割した複数エージェント＋ルーティング担当 |
元記事の3層防御（指示書／権限設定／フック）という発想自体は、私がやっていることとほぼ同じ理屈に立っている。元記事も元に戻せない操作を検出したら承認を求める形にしており、「検出したら人間の承認を挟む」という点は私と同じだ。違うのは適用範囲で、元記事はそれをプライベート環境に限り、業務での外部連携は見送った。私は業務側にも広げ、承認を承認キューという1か所に集めた。以下、順番に実装を見ていく。
1. ルーティング — 1人の秘書に全部任せない
最初に秘書エージェント1本で全業務（技術判断・経理・法務っぽい確認・雑務）を処理させていた時期があった。コンテキストが肥大化し、技術的な質問にふわっとした回答が返るようになった。実際、毎朝の朝会で各メンバーが口頭で進捗報告をしていて、30分の会議のうち20分が進捗報告だけで消費されていた業務改善の現場でも、似た問題が起きていた。Slack Botで毎朝「昨日やったこと・今日やること・困っていること」の3点を自動投稿させ、朝会は困りごとの議論だけに絞ったところ、所要時間が30分から10分に短縮した例がある。これは「同期が必要なもの（議論・意思決定）だけを人に振り、それ以外は仕組みに任せる」という発想で、私が秘書エージェントを分割した時の設計判断とほぼ同じだった。
秘書エージェントを「ルーティング担当」として独立させ、技術判断はCTO役、経理はCFO役、というように役割別エージェントへ振り分ける構成に変えた。各エージェントは専用のペルソナファイル（話し方・専門分野・対応方針を明文化したMarkdown）を持つ。カスタマーサポートの初回応答で「分類と担当者割り当てを自動化する」と応答時間が8時間から1.5時間に短縮した例があるが、これも「人間が判断すべきは内容であって、誰が対応するかではない」という同じ原則に基づく。秘書の役目は「振り分けの精度」であって、全部を自分で解決することではない。
2. 承認キュー — 「危険だからやらない」ではなく「ゲートを通す」
元記事が業務での外部連携を見送った理由は理解できる。メール誤送信は一発アウトのリスクだ。実際、私も過去にAIエージェントの外部アクションで冷や汗をかいた経験がある。だからこそ「内部操作は自動実行、外部操作は必ず人間の承認を挟む」という境界線を敷いて、ドラフト生成→承認キュー格納→人間承認→実行の4ステップに固定した。承認作業自体は1日あたり数分で済む範囲に収まっている。
似た構造は社内の稟議フローでも見た。紙の稟議書は承認者が不在だと机上で止まり、完了まで平均10日かかっていた。これをWeb化し、3日以上滞留したら自動でリマインダーを送る仕組みに変えただけでリードタイムが10日から2日に縮んだ。学びは「承認プロセスで一番効くのはリマインダーで、承認者はだいたい忘れているだけ」という点だった。私の承認キューにも「一定時間承認が動かなければ再通知する」ロジックを入れている理由はここにある。承認フローは「止める仕組み」ではなく「止まったままにしない仕組み」として作るのが要点だと考えている。
3. kill switch — 規約ではなく機械的に止める
元記事はPythonスクリプトで「元に戻せない操作」を検出する仕組みを作っていた。私も同じ発想で、特定のフラグファイルが存在する間は外部アクション系のツール呼び出しを一律ブロックする「kill switch」を、Claude CodeのHooks機能（PreToolUse）で実装している。
ポイントは「ルールを文章で書いて守らせる」のではなく「ツール呼び出しの直前に機械的にチェックして止める」ことだ。Claude Code公式のHooksリファレンス（Exit code 2の挙動を示す表、2026-10-12時点で確認）によると、PreToolUseフックが終了コード2を返すとツール呼び出しはブロックされ、フック側がJSON出力でpermissionDecision: "allow"を返していてもこのブロックを上書きできない、と明記されている1。つまり「許可する」設定が別経路で生きていても、exit code 2が出た時点で必ず止まる。これを使えば、フラグファイル1つの有無だけで「全体を一律ブロックする安全弁」を規約ではなく仕組みとして作れる。
最小構成のチェックスクリプトはこうなる（自分の環境・bash 3系で動作確認済み。フラグファイル無しでexit 0、フラグファイル有りでexit 2・標準エラーにメッセージを出すことを両方確認した）。
#!/bin/bash
# kill-switch-check.sh — PreToolUseフックから呼ぶ想定
FLAG_FILE="${KILL_SWITCH_FLAG:-./PAUSED}"
if [ -f "$FLAG_FILE" ]; then
echo "blocked: kill switch is active (${FLAG_FILE} exists)" >&2
exit 2
fi
exit 0
このスクリプトはフラグファイルの有無だけを見ており、読み取り系か書き込み系かといったツールの種類は区別しない。ただし、これは判定スクリプト単体で、置いただけでは呼ばれない。PreToolUseフックとして設定ファイルに登録し、どのツールで呼ぶかを matcher で指定して初めて動く（登録の書き方は公式のHooksリファレンス1を参照）。全ツールに一致する matcher で登録すれば、フラグが立っている間は読み取り系も含めて通常のツール呼び出しは止まるが、限定した matcher で登録すればそのツールしか止まらない。また、公式リファレンスによると会話を終える操作（EndConversation）はPreToolUseを通らないので、このフックでは止められない。ログの肥大化でディスク使用率が95%に達した時にログローテーションの保持ポリシーを事前に決めておかなかったことを後悔した経験があるが、kill switchも同じで「どの条件で誰が止めるか」を後から決めると大体手遅れになる。最初にフラグファイル1個という最小の判定条件に決めてしまうのが運用上は楽だった。
4. handoffファイル — セッションが切れても秘書は忘れない
元記事では言及がなかったが、自律的に秘書を運用する上で地味に効くのがセッション間の記憶だ。AIエージェントとの作業は毎回セッションが切れる。切れた瞬間に前回の文脈をゼロから説明し直すのは非効率で、業務改善の文脈でもよく出てくる「属人化」とほぼ同じ構造の問題だと感じている。経理の月次決算が1人の頭の中にしかなく、その人が休むと止まる、というのを72ステップに分解してフローチャート化したら誰でも引き継げるようになった、という事例と原理は同じだ。
秘書エージェントにも、セッション終了時に「進行中タスク・保留事項・次のアクション・決定事項」を構造化して1つのMarkdownファイルに書き出させている。次のセッション開始時にはそのファイルだけを読めば、前回どこまで進んだかを数秒で復元できる。「前回どこまでやったっけ？」のやり取りが発生しなくなったのが一番の効果で、これは属人化解消の工数削減(2日の引き継ぎ研修で完了)と同じ理屈で「暗黙知を形式知にする」作業が効いている。
まとめ表（実装の対応関係）
| 課題 | 元記事の対処 | 私の対処 | 実装箇所 |
|---|---|---|---|
| 全業務を1人に任せると精度が落ちる | （単一エージェント運用） | 役割別エージェント＋ルーティング担当に分割 | ペルソナファイル×役割数 |
| 外部アクションのリスク | 業務未導入に決定 | ドラフト→承認キュー→承認→実行の4ステップ | 承認キュー＋リマインダー |
| 元に戻せない操作の検出 | Pythonスクリプトで検出 | フラグファイル＋PreToolUseフックで一律ブロック | kill-switch-check.sh |
| セッションが切れると文脈が消える | 言及なし | handoffファイルに構造化保存 | セッション終了時フック |
まとめ
結局のところ、元記事と私の違いは「危険性に気づいた後、どちらに倒すか」だけだったように思う。元記事は業務での外部連携を見送る方向に倒し、それは5日間の実験としては十分に合理的な判断だ。私は同じ危険性に気づいた上で、承認キューとkill switchという2段のゲートを間に挟むことで外部アクションを許可する方向に倒した。どちらが正しいというより、運用期間とスコープが違えば守り方の形も変わる、という当たり前の話に帰着する気がしている。3ヶ月運用してみて一番効いているのは、意外にも一番地味なhandoffファイルだった。セッションが切れることを前提にした設計にしておくと、他の3つの機構も「毎回ゼロから説明し直す」という前提なしで安定して回る。
正直、kill switchを規約でなく機構として作り込むまでは「PreToolUseでブロックしたつもりが別経路で許可されていた」という抜け道がないか不安だった。今回Hooksの公式リファレンスを読み直して、exit code 2がpermissionDecisionを上書きできる形で明記されているのを確認できたのは収穫だった。似た設計で防御層を作っている方がいれば、どこで一番ヒヤッとしたか聞いてみたい。
-
Claude Code Hooks reference（"Exit code 2 behavior per event" / "Exit code output"）: https://code.claude.com/docs/en/hooks （2026-10-12時点で確認。バージョン番号非公開の常時更新ドキュメントのため確認日を記載） ↩ ↩2