← 一覧に戻る

AI秘書体制 ベストプラクティス設計書

2026年4月4日 15:10 更新
MD から自動変換されたページです。内容について質問があれば右下の ? ボタンからどうぞ。

作成日: 2026-04-02 統合ソース: OpenClaw/@usedhonda調査、Claude Code公式docs調査、harness engineering調査、WHYインタビュー結果 対象読者: 非エンジニアのプロダクトオーナー（AIの仕組みを理解して判断したい人）

1. WHY -- なぜこの体制が必要か

解決する問題

PCを開かずに、アイデアをPoCまで持っていきたい。

具体的には:

なぜ秘書なのか（エージェントだけではダメな理由）

AIエージェント（自律的に動くAI）は「言われたことをやる」のは得意だが、以下が苦手:

  1. 意図のドリフト（指示が委譲されるうちに薄まる問題） -- 秘書なしだと「元々何がしたかったか」が作業の途中で失われる
  2. 検証の省略 -- 作業セッションが「できました」と言っても実際は70%しかできていないケースが頻発する（2026-03-31 秘書セッション運用中に複数回観測。具体例: Obsidian 2026-03-31_秘書運用振り返り.md 参照）
  3. 文脈の分断 -- 複数セッションを跨ぐとき、どこに何があるかを把握している存在が必要
  4. 先回り提案 -- ジョブ履歴やSecond-Brain（Obsidianの記録庫）から「次にやるべきこと」を推測できるのは、ユーザーの文脈を知っている秘書だけ

OpenClawが証明したこと、現体制が証明すべきこと

OpenClaw（オープンソースのAI秘書フレームワーク）は「既存チャットアプリをUIにして、AIが自律的に動く」というコンセプトの有効性を証明した（GitHub 345,000+スター、2026年4月時点）。

現体制が証明すべきは: OpenClawが専用フレームワークで解決した問題を、Claude Code + harness engineering（ハーネスエンジニアリング = AIの振る舞いを制御するシステム設計）で同等以上に解決できること。

2. ベストプラクティス設計（ゼロから構築する場合の理想形）

2.1 アーキテクチャ概要

[ユーザー] ── Telegram ──→ [秘書セッション（オーケストレーター）]
                                │
                 ┌──────────────┼──────────────┐
                 │              │              │
            [作業セッションA] [作業セッションB] [Codex（GPT-5.4）]
            （実装担当）     （調査担当）     （レビュー/ファクトチェック）
                 │              │              │
                 └──────────────┼──────────────┘
                                │
                          [検証フェーズ]
                                │
                          [Telegram報告]

3つの原則:

  1. 秘書は成果物を直接編集しない -- dispatch（指示送信）・検証・報告・セッション制御のみ。コードやファイルの作成・編集は全て作業セッションに委任する。ただしセッション制御（tmux.py send による作業セッションへのメッセージ送信・方向修正）は許可される。これは成果物の編集ではなく「指揮」の範疇
  2. 作業セッションの自己申告を信じない -- 秘書が独自に検証する
  3. 意図を最初に記録し、最後に再確認する -- 意図のドリフト防止

⚠️ 未定義の設計課題: この体制にはまだ定義が必要な重要課題がある。セキュリティ境界と情報漏えい対策、失敗時のロールバック手順、競合時の優先順位ルールについては 付録C で課題を整理している。これらは実装フェーズに入る前に設計を確定する必要がある。

2.2 ハーネス設計（5層モデル）

ハーネス（AIの振る舞いを制御する仕組み全体）は5つの層に分かれる。層ごとに更新頻度が違うので分離する。

層 名前 実装 更新頻度 役割
第1層 アイデンティティ層 CLAUDE.md（基本原則のみ、60行以下目標） 月単位 「誰として振る舞うか」を定義
第2層 ドメイン知識層 .claude/rules/（ファイルパターンで自動注入） + skills 週単位 「何を知っているか」を必要時だけ注入
第3層 行動制約層 hooks（settings.jsonに定義） 問題発生時 「何をしてはいけないか」をプログラムで強制
第4層 ランタイム状態層 jobs.db（SQLite） + registry.json + tmuxセッション リアルタイム 「今何をしているか」を追跡
第5層 フィードバック層 memory/（永続記憶） + Second-Brain（Obsidian） セッション単位 「何を学んだか」を蓄積

Progressive Disclosure（段階的開示）の原則: 全ての情報を常時ロードしない。TypeScriptのルールはTypeScriptファイルを触る時だけ注入する。秘書ルールは秘書セッションだけに注入する。これにより、コンテキスト（AIが一度に処理できる情報の枠）を節約する。

2.3 自律的タスク管理の仕組み

ジョブのライフサイクル

BACKLOG（いつかやる）
  ↓ ユーザー指示 or 秘書の先回り提案
PENDING（やること確定・承認待ち）← clarify/proposeはこの段階で秘書が実施
  ↓ ユーザー承認（Telegramのボタンタップ）
SENT（作業セッションに送信済み）
  ↓ 作業中
IN_PROGRESS（作業中、任意使用）
  ↓ 作業セッションが完了を通知
VERIFYING（秘書が検証中）
  ↓ 検証3段階を通過
DONE（本当に完了）/ WAIT（ユーザー判断待ち）/ FAILED（失敗）/ RETRY（差分再送信、最大1回）

注: 理想形では CLARIFIED（指示明確化済み）→ APPROVED（ユーザー承認済み）の中間状態も想定しているが、現在のjobs.dbスキーマではPENDINGに統合している。将来的に信頼度ベース自律度を実装する際に分離する可能性がある。

完了条件ファースト

dispatchする前に「何を持って完了とするか」を定義し、jobs.dbに記録する:

ジョブ: 課金モデルの変更
完了条件:
  □ Stripe Payment Link が新価格で生成されている
  □ テストが全件パス
  □ ドキュメントが更新されている

秘書はDONEにする前に、この完了条件を1つずつ検証する。

先回り提案

秘書はアイドル時（待機中）に以下を巡回して提案を生成する:

2.4 信頼度ベースの自律度調整

信頼は「ドメイン × 操作の種類」で細分化される。「コードを書くのは信頼できるが、デプロイは慎重に」という粒度。

信頼レベル 秘書の動作 条件
Lv.0 初期 clarify → propose → ユーザー承認 → dispatch → 検証 → 報告 デフォルト
Lv.1 基本信頼 clarify → propose → dispatch → 検証 → 報告（承認省略） 同種のタスクが3回連続成功
Lv.2 高信頼 clarify → dispatch → 検証 → 報告（提案も省略） 同種のタスクが10回連続成功
Lv.3 完全委任 dispatch → 検証 → 報告（曖昧さ解消も自動） ユーザーが明示的に許可したドメインのみ

降格条件: 検証で不合格が1回出たら、そのドメインは1レベル降格する。

用語定義:

WHYインタビューからの洞察（出典: 2026-04-01 WHYインタビューセッション、Obsidian 2026-04-01_WHYインタビュー.md）: UIで入力コストを下げ、harnessで文脈を補完し、信頼度に応じて自律度を段階的に上げる。これは@usedhondaのobserve/autonomous/autoの3モードと思想は同じだが、こちらの方が粒度が細かい。

2.5 通知・検証フロー

検証3段階

段階 方式 内容 強度
1. 自動検証 ドメイン別の自動検証器を実行 成果物が壊れていないか 強い
2. 条件検証 秘書がjobs.dbの完了条件と照合 指示通りにできたか 中
3. 意図検証 秘書が元のユーザー指示を再読して照合 本来の目的を満たしたか 弱いが重要

自動検証器のドメイン別対応:

通知の設計

イベント 通知先 方法 即時性
ジョブ完了 Telegram reply（返信メッセージ） 即時
Permission要求 Telegram Permission Relay（承認ボタン） 即時
エラー発生 Telegram + ntfy reply + プッシュ通知 即時
進捗更新 Telegram edit_message（既存メッセージ更新） 適宜
先回り提案 Telegram 新規メッセージ アイドル時

秘書から作業セッションへの「意見注入」（3者会話パターン）

@usedhondaのOpenClaw運用で実証済みのパターン（出典: @usedhonda X投稿 2026-03-29〜、OpenClaw GitHub Discussions）。秘書が作業セッションの進行にリアルタイムで介入する。

実装方法: 秘書が tmux.py send（tmuxラッパースクリプト）で作業セッションにプレフィックス付きメッセージを送る。例: tmux.py send SESSION:WINDOW "[Secretary Agent] この方向でいいが、テストも追加して"。作業セッションは「ユーザーではなく秘書からの指示」と認識する。注: tmux send-keys の直接使用は、AskUserQuestionモーダル中の入力処理と衝突するため非推奨。tmux.py send はこれを安全にハンドリングする。

3. 現体制とのdiff（対比表）

読み方ガイド: このセクションは「理想形（2章）と現在の実装状態の差分」を示す。✅は実装済み、⚡は一部実装済み、🔴は未実装。セクション4（OpenClawとの比較）とセクション5（差別化戦略）は参考情報であり、実装の優先順位はセクション6のロードマップに従う。

3.1 機能ごとの差分

機能 理想形 現状（2026-04-02時点） ギャップ
ジョブ管理 SQLite（jobs.db）による永続化。BACKLOG/WAIT等の豊富なステータス ✅ SQLite（jobs.db）で永続化済み。11ステータス（BACKLOG/PENDING/SENT/IN_PROGRESS/VERIFYING/DONE/FAILED/BLOCKED/WAIT/RETRY/EXPIRED）対応。dispatch-job.shがSQLiteに直接記録 実装済み（2026-04-01移行完了）。通知スクリプト3本（notify-secretary.sh, notify-secretary-blocked.sh, claude-stop.sh）のメッセージ文面に旧「jobs.jsonを確認して」という指示が残存。機能リスク: 秘書がこの文面を素直に実行するとjobs.jsonを探そうとしてジョブ照合に失敗する可能性がある。P1 #8bで早期修正が必要
完了条件 dispatch前に完了条件をjobs.dbに記録。検証時に照合 ✅ done_whenテーブルでdispatch前に完了条件を記録。dispatch-job.shの第8引数でJSON配列として渡す。検証時にverification_checksで照合 実装済み。completion-contract.xmlに検証ワークフロー定義済み
検証フロー 自動検証 → 条件検証 → 意図検証の3段階 ✅ インフラ実装済み: verification_checks/verification_summaryテーブル + completion-contract.xml + prompt.mdに検証手順を定義 インフラ実装済み。自動検証（tsc→lint→test）のスクリプト化が未着手。条件検証と意図検証は秘書の手動判定で運用中
信頼度管理 ドメイン×操作で細分化された信頼レベル。自動昇降格 Phase 0〜3の固定段階。手動切り替え 動的信頼度管理は未設計
先回り提案 jobs.db + Second-Brain + memoryからのプロアクティブ提案 なし 完全に未実装
Permission承認 Telegram経由の直接承認 通知はキューファイル方式で信頼性確保済み（案C、2026-04-04実装）。承認フローは未完成。PermissionRequestフック（Edit/Writeのみ対象、Bash等は未カバー）で秘書に通知（spool→drain→ACK確認で配信保証）→秘書がTelegramでユーザーに連絡→ユーザーがPC上で直接操作が必要。設計詳細: investigation-permission-hook.md 2つの選択肢: (1) Claude Code公式のPermission Relay機能（v2.1.81+、--channels 経由。公式機能として存在確認済み。 調査メモ research-claude-code-docs.md L167参照。現環境での有効化方法・制約は未検証）、(2) Telegramボットの callback_query で承認UIを自作。(1)の検証を優先し、制約があれば(2)にフォールバック
3者会話 秘書→作業セッションへのリアルタイム意見注入 なし @usedhondaが実証済み。tmux.py send で実装可能
セッション終了検知 SessionEndフックでregistry.json自動更新 + 秘書通知 ✅ notify-secretary-session-end.sh でSessionEndフック実装。registry.jsonから終了セッション削除 + 秘書通知。async: true 実装済み（2026-04-04）
ツールエラー検知 PostToolUseFailureフックで秘書に即時通知 ✅ notify-secretary-failure.sh でPostToolUseFailureフック実装。ツール名・エラー内容・中断判定を秘書に通知。async: true 実装済み（2026-04-04）
通知フックの非同期化 全通知フックを async: true に設定 ✅ notify-secretary.sh: settings.jsonで async: true。notify-secretary-blocked.sh/permission.sh: スクリプト内 & で非同期 実装済み（2026-04-02）
フックの精度 if フィールドで引数レベルのフィルタリング（要検証: 2026-04-02時点で公式docsに記載未確認） matcher のみ（ツール名レベル） "if": "Bash(rm *)" 等の構文が使えるかは未検証。P1 #10bで実地検証予定
CLAUDE.md 60行以下。基本原則のみ。ドメイン知識はrules/に分離 74行。基本原則中心だがplan-viewer/外部ツール連携等のドメイン知識が混在 目標の60行に近いが、ドメイン知識の一部をrules/に移動可能（現在rules/は3ファイルのみ）
メモリ構造 カテゴリ別整理。秘書feedbackは1ファイルに統合 30ファイルがフラット配置。秘書feedback12件が個別ファイル メモリ統合と棚卸しが必要
hookインベントリ 全hookの一覧表（イベント・条件・動作・解決する問題） settings.json + プラグインhooks.jsonに分散。一覧なし docs/hook-inventory.md 作成が必要
コンテキスト予算 ハーネス固定コストのトークン計測。目標値の設定 「50%超えたらcompact」のルールのみ ハーネス自体のコスト可視化が未実施
マルチdispatch 複数セッションへの同時dispatch + 結果統合 アクティブジョブ1件制限 Phase 3で予定。Agent Teams（公式実験機能）との組み合わせも検討可能
スキル自動生成 繰り返しパターンの検出 → 秘書がスキル化を提案 create-skillスキルで手動作成可能。自律的な提案はなし 中期課題
環境変数管理 CLAUDE_ENV_FILE でSessionStartフックから永続化 環境変数はlaunchctlやシェルで個別管理 CLAUDE_ENV_FILE が未活用

3.2 ハーネス5層の現状評価

層 理想形の実装度 評価
第1層 アイデンティティ 80% CLAUDE.mdに基本原則が定義済み。ただしドメイン知識と混在しており肥大化傾向
第2層 ドメイン知識 85% rules/に3ファイル（code-style, config-files, dotfiles）、skills 50+。Progressive Disclosureが機能している
第3層 行動制約 65% hooksは動作中（settings.jsonで11種のイベントタイプを使用）。一元管理（hook-inventory）がない
第4層 ランタイム状態 85% jobs.db（SQLite）+ registry.jsonで動作中。done_when/verification_checks/verification_summary/wait_detailsテーブル実装済み。SessionEnd/PostToolUseFailureフック連携済み（2026-04-04）
第5層 フィードバック 75% memory 30件（2026-04-02時点）、Second-Brain連携済み。ただし秘書feedback12件が分散、自動ルール昇格未実装

4. OpenClaw vs 現体制

4.1 OpenClawの各機能に対する現体制の対応

OpenClawの機能 現体制の対応 状態
Gateway層（WebSocketルーティング） Claude Code Channels（--channels plugin:telegram@...） 対応済み。単一チャネルだが目的上十分
23+チャットプラットフォーム Telegram単一 意図的に限定。チャネル増は認証管理コスト増なだけ
LLM非依存（Claude/GPT/DeepSeek差替え） Claude固定 + Codex（GPT-5.4）併用 現行で十分。LLM切替えが必要な場面がない
Pi agent runtime Claude Code セッション + tmux管理 機能的に同等
Swarm（複数エージェント協調） アクティブジョブ1件制限 + 将来のマルチdispatch ギャップあり。Phase 3課題
3者会話（Agent→CLAUDE.md介入） 未実装 ギャップあり。tmux.py send で実装可能
observe/autonomous/autoモード Phase 0〜3の段階管理 現体制が優位。Phase制の方が粒度が細かく安全
永続メモリ（ローカルMarkdown） memory/ + Second-Brain + recall CLI 現体制が優位。3層構造で検索性が高い
自己拡張（AIがスキルを自作） create-skillスキルで手動可能 秘書が自律的に提案するフローは未実装
ClawHub（スキル配布） ローカルプラグイン + marketplace.json スコープが違う（個人利用 vs コミュニティ）
ブラウザ制御（Chromium） peekaboo MCP（computer-use） 同等。用途が異なるだけ
音声操作（Wake word + TTS） なし 不要（Telegramテキストで十分）
Cron + Webhook内蔵 CronCreate + launchctl 同等

4.2 現体制の優位性

注: 以下の比較はOpenClaw GitHub README・Discussions・@usedhondaのX投稿（2026-03-29〜04-01）を根拠としている。OpenClawの内部実装は未検証のため、公開情報ベースの評価である。

項目 現体制の優位点 OpenClawとの差（根拠）
安全ガード Phase制 + clarify/propose/dispatchフロー。段階的にリスク管理 OpenClawのautoモードは作者(@usedhonda)自身が「危険」と表現（X投稿 2026-03-30）。確率的実行パスのため事前テストが困難
PC操作の最小化 指示・報告はTelegramで完結。ただしPermission承認は通知のみ実装済みで、承認フロー自体は未完成（Mac稼働が前提）。完全なTelegram完結にはP2 #11の実装が必要 @usedhondaの運用ではMacメニューバーアプリが起点（X投稿から観測）
記憶の検索性 Obsidian（全文検索可） + recall CLI + memory/（構造化） の3層 OpenClawの永続メモリはローカルMarkdownファイル（README記載のmemory機能）
ジョブの永続化 registry.json + jobs.db（SQLite）で秘書がステートレス（状態を持たない）。クラッシュ復帰が容易 OpenClawのPi runtimeはプロセス内管理（README記載のアーキテクチャ図から推定。永続化レイヤの有無は未確認）
レビュー統合 Codex（GPT-5.4）によるクロスモデルレビュー OpenClawはLLM非依存だが、クロスモデルレビューの仕組みはREADMEに記載なし
harness engineering 7原則に基づく体系的設計。5層モデル、フィードバックループ、Build to Delete OpenClawのスキルシステムは充実しているが、harness設計の体系化ドキュメントはREADMEに見当たらない

4.3 不足している部分

不足 影響 対処案
Swarm的な並列協調 複数タスクを同時に進められない Phase 3のマルチdispatch + Agent Teams
3者会話 秘書が作業の方向性をリアルタイムで修正できない tmux.py send でプレフィックス付きメッセージ送信
自律的スキル生成 繰り返しパターンがスキル化されず手作業が残る 秘書のアイドル時にパターン検出 → 提案フロー

5. @usedhondaを超えるために

5.1 相手の強み

強み 内容
OpenClawコミュニティの集合知 345,000+スターのOSSプロジェクト。スキル・プラグインが豊富。バグ修正やベストプラクティスがコミュニティから供給される
マルチプラットフォーム WhatsApp/Telegram/Slack/LINE等23+対応。状況に応じてチャネルを切り替えられる
ハードウェア連携の先見性 「OpenClawのためのハードウェアが出まくる」という予測。IoTデバイスとの連携に先行投資
3者会話の実戦経験 autonomousモードで「Claude Codeの性格が変わる感じ」を実体験。秘書→作業者への介入パターンを日常的に運用
起業家ネットワーク FreakOut CEO、40社グループ、Angel投資家。技術的な実験を事業に転換する力

5.2 こちらの差別化ポイント

差別化 内容
harness engineeringの体系化 「モデルはコモディティ、ハーネスがモート」を実践。5層モデル・7原則に基づく体系的設計。OpenClawのREADME・Docsにはharness設計の体系化ドキュメントが見当たらない（2026-04-02時点で確認）
検証フレームワーク 自動検証→条件検証→意図検証の3段階。「作業者の自己申告を信じない」を仕組みで保証。OpenClawのautoモードは@usedhonda自身が「確率的実行パス」と表現しており、事前テストが困難とされる
フィードバックループの実装 feedback memory → 繰り返し → rules/に昇格 → hook化の「強制力の勾配」が設計されている。失敗が仕組みの改善に直結する
Codexクロスレビュー Claude（生成）+ GPT-5.4（レビュー）の異なるモデルによる交差検証。OpenClawはLLM非依存設計だが、クロスモデルレビューの仕組みはREADMEに記載なし（ユーザーが自前で設定すれば可能と推定）
PC操作の最小化 指示・報告はTelegramで完結。caffeinate + computer-useでMac稼働を維持。ただしPermission承認は通知のみ実装済みで、承認フロー自体は未完成。 現状はユーザーがPC上で直接操作する必要がある。完全なTelegram完結にはP2 #11の直接承認実装が必要
非エンジニア向け設計 専門用語の解説、plan-viewerによるスマホ閲覧、Obsidianへの自動記録。エンジニアでなくても全体を把握できる

5.3 具体的なアクション

# アクション 何をするか なぜ差がつくか
1 3者会話パターンの実装 秘書→作業セッションへのプレフィックス付きメッセージ送信を仕組み化 @usedhondaの実証済みパターンを取り込み、検証フレームワークと組み合わせて精度を上げる
2 検証3段階の実装 secretary-orchestration-bestpractice.md v3の設計を実装に移す OpenClawが「確率的実行パス」で苦戦している領域で確実に勝てる
3 信頼度ベース自律度の実装 ドメイン×操作の信頼スコアをjobs.dbに記録、自動昇降格 observe/autonomous/autoの3段階より精緻。ユーザーの信頼を定量化できる
4 Telegram直接承認の実装 現状の通知のみ→Telegram callback_query経由の承認UIに切り替え PC操作なしで承認可能に。ユーザーのスマホ完結度を向上
5 先回り提案の実装 秘書アイドル時にjobs.db/Second-Brain/memoryを巡回して提案生成 OpenClawにはない「秘書が自分で仕事を見つける」機能

6. 改善ロードマップ（優先順位付き）

P0: 即座に適用可能（設定変更のみ、コード不要）

# やること ファイル/コマンド 効果
1 通知フックを async: true に変更 ~/.claude/settings.json の notify-secretary.sh（idle_prompt）に "async": true 追加済み。notify-secretary-blocked.shとnotify-secretary-permission.shはスクリプト内で & 使用済みのため変更不要 ✅ 実装済み（2026-04-02）。メイン処理のブロッキング解消
4 --channels フラグの正式採用確認 run-claude.sh で --channels plugin:telegram@claude-plugins-official として既に使用中 ✅ 確認済み（2026-04-02）。メモリの古い記述（「--channelsは存在しない」）は削除済み

P1: 短期改善（1-3日、設計済みの実装）

# やること 依存関係 効果 状態
2 PostToolUseFailure フック追加 なし settings.jsonにイベントハンドラ追加 + 処理スクリプト新規作成（既存通知スクリプトを流用可能、エラー内容抽出ロジックは別途） 🔴 未着手
3 SessionEnd フック追加 なし settings.jsonにイベントハンドラ追加 + registry.json更新スクリプト新規作成（セッション名取得→status更新→秘書通知） 🔴 未着手
6 jobs.json → jobs.db（SQLite）移行 なし ジョブ管理の堅牢化。BACKLOG/WAITステータス対応 ✅ 実装済み（2026-04-01）。5テーブル・11ステータス
7 完了条件ファーストの実装 #6 dispatch前に完了条件を記録、検証時に照合 ✅ 実装済み。done_whenテーブル + dispatch-job.sh第8引数
8 検証3段階の自動化強化 #6, #7 自動→条件→意図の3段階検証 ⚡ インフラ実装済み。自動検証（tsc→lint→test）のスクリプト化が残課題
8b 通知スクリプトの「jobs.json」参照修正 なし notify-secretary.sh, notify-secretary-blocked.sh, claude-stop.shのメッセージ文面を「jobs.db」に更新 ✅ 実装済み（2026-04-02）。3ファイルの通知文面を「jobs.dbを確認して」に修正
9 秘書feedbackメモリの統合 なし 12件の個別ファイル → 1-2件に統合。MEMORY.md圧縮 🔴 未着手
10 hookインベントリ作成 なし 全hookの一覧表（docs/hook-inventory.md） 🔴 未着手
10b if フィールドでhook精度向上 #10 rm-rf-guardを "if": "Bash(rm *)" 等に変更。要検証: if フィールドのフォーマットは公式docsで未確認（2026-04-02時点）。hook-inventory作成後に実地検証する 🔴 未着手

P2: 中期改善（1-2週間、新規設計必要）

# やること 依存関係 効果
11 Telegram直接承認の実装 なし 現状の「通知のみ・PC操作必要」からTelegram直接承認に切り替え。まず公式Permission Relay（v2.1.81+、存在確認済み）の有効化・制約を検証し、制約があれば callback_query ベースの自作UIにフォールバック
12 3者会話パターン実装 なし 秘書→作業セッションへのリアルタイム意見注入
13 信頼度ベース自律度 #6 ドメイン×操作の信頼スコア管理と自動昇降格
14 CLAUDE.mdスリム化 #10 ドメイン知識をrules/にプロモーション。60行以下目標（現在74行、rules/は3ファイルのみ）
15 コンテキスト予算計測 なし ハーネス固定コストのトークン計測スクリプト作成

P3: 長期改善（1ヶ月+、実験的）

# やること 依存関係 効果
16 マルチdispatch（Phase 3） #6, #8 複数セッションへの同時dispatch + Agent Teams検討
17 先回り提案 #6, #13 秘書アイドル時のプロアクティブ提案
18 自律的スキル生成 #17 繰り返しパターンの検出→スキル化提案
19 メモリ自動ルール昇格 #9, #10 N回同じfeedback → rules/に自動昇格提案
20 Remote Control統合 #11 秘書経由とRemote Control直接操作の併用設計

成功の定量指標

指標 現在の推定 目標 計測方法
検証なしDONEの割合 高い（目視未計測） 0%（全ジョブに検証3段階を通す） 3段階全通過の判定: (1) verification_checks にdone_whenの全条件が result='pass'、(2) verification_summary にレコードあり、(3) intent_satisfied='yes'。前提: DONEにする前にdone_whenが最低1件登録されていること（dispatch-job.shの第8引数で強制）。 SQL例: SELECT j.id FROM jobs j WHERE j.status='DONE' AND (NOT EXISTS (SELECT 1 FROM done_when dw WHERE dw.job_id=j.id) OR j.id NOT IN (SELECT vs.job_id FROM verification_summary vs WHERE vs.intent_satisfied='yes') OR EXISTS (SELECT 1 FROM done_when dw WHERE dw.job_id=j.id AND NOT EXISTS (SELECT 1 FROM verification_checks vc WHERE vc.job_id=dw.job_id AND vc.condition=dw.condition AND vc.result='pass')))
dispatch → 完了の平均時間 不明 計測開始 jobs.dbの sent_at→done_at の差分を集計。注: RETRYを含むジョブでは sent_at が初回dispatch時刻のため、総リードタイムを表す。 RETRY時の再送時刻を別途記録する場合は last_sent_at カラムの追加を検討（P2 #13のスキーマ拡張で対応）
意図ドリフト（元の指示と結果の乖離）発生率 体感的に3割程度 5%以下 意図検証（検証3段階の第3段階）で「不合格」になった割合。verification_summaryの intent_satisfied カラム（'no' or 'unclear'）で集計
秘書への確認回数/ジョブ 2-3回 信頼Lv.2到達ドメインは0回 jobs.dbに clarify_count カラム追加が必要（P2 #13と同時に実施）
ハーネス固定コスト（コンテキスト消費割合） 未計測 15%以下 CLAUDE.md + .claude/rules/ + 秘書 prompt.md + .claude/projects/.../memory/ + MEMORY.md のトークン数合計 / コンテキストウィンドウ上限。計測にはClaudeのトークナイザー（anthropic SDKの count_tokens API）を使用。 日本語混在文書では wc -w は不正確なため非推奨（P2 #15）

付録A: ハーネスエンジニアリング7原則（要約）

  1. レイヤード制御 -- 5層に分離。更新頻度の異なる関心事を混ぜない
  2. 自律性と制御のスペクトラム -- まず制御寄りで始めて、信頼が確認できたら緩める
  3. コンテキスト経済学 -- 全トークンにコストがある。Progressive Disclosureで節約
  4. 強制力の勾配 -- プロンプト < テンプレート < hook < 状態マシン。失敗はたいてい「強制力不足」
  5. フィードバックループ -- 失敗→記録→改善→安定→緩和のサイクルを仕組みとして持つ
  6. 永続的エラー防止 -- ミスを直すのではなく、ミスが生まれない環境を設計する
  7. Build to Delete -- ハーネスはモデルの弱点への仮定。モデルが改善されたら削除する

付録B: 定量的実証データ

事例 介入内容 成果
Vercel v0 ツールを15→2に削減 精度80%→100%、トークン-37%、速度3.5倍
LangChain Terminal Bench ハーネス改善のみ（モデル変更なし） 52.8%→66.5%（順位30位→5位）
OpenAI Codex（5ヶ月間） 3〜7名でハーネス設計 PRを1人あたり3.5本/日
Hashline実験 行編集フォーマット変更のみ Grok Code: 6.7%→68.3%（+10倍）

核心: 同じモデルでも、ハーネスの差だけでタスク完了率60% vs 98%の開きが生まれる。モデルはコモディティ（汎用品）、ハーネスがモート（競争優位の堀）。

付録C: 未定義の重要課題（Codexレビュー 2026-04-02 指摘）

以下はCodex（GPT-5.4）による設計レビューで「定義が必要」と指摘された課題。現設計書では未カバー。

C.1 セキュリティ境界と情報漏えい対策

Telegram・Second-Brain・memory/・jobs.dbをまたいで情報が流れる設計だが、以下が未定義:

C.2 失敗時のロールバック手順

FAILED/WAITを定義しているが、コード変更や設定変更が途中まで適用された場合の巻き戻し手順がない:

C.3 競合時の優先順位ルール

先回り提案・マルチdispatch実装時に必要:

C.4 「実装済み」判定の証拠

項目 確認方法 確認日
jobs.db移行 sqlite3 ~/secretary-state/jobs.db '.schema' で5テーブル確認 2026-04-02
完了条件 dispatch-job.shの第8引数 + done_whenテーブルのINSERT確認 2026-04-02
検証フロー completion-contract.xml + verification_checks/summaryテーブル確認 2026-04-02
通知スクリプト notify-secretary*.sh 3本の存在とsettings.jsonへの登録確認 2026-04-02

付録D: Codexレビュー履歴（2026-04-02）

Codex（GPT-5.4）による設計書レビューを13ラウンド実施し、LGTM取得。

Round 指摘数 Critical Warning 主な指摘内容 対応
1 11 0 0 (分類なし) 事実誤認（memory件数、--channels既使用）、論理矛盾（P0に未検証項目、原則の自己矛盾）、出典不足、比較根拠不足、数値定義不足、構成問題 件数修正、P0/P1整理、原則明確化、出典追加、比較根拠に注記、計測方法追加、読み方ガイド追加
2 5 0 5 jobs.dbスキーマとの不整合（domain/intent_check未存在）、連続成功判定SQL不正確、検証第1段階がコード限定、PC非依存が強すぎ、jobs.json残存影響過小 スキーマ差異を注記、ドメイン別検証器に修正、「PC操作の最小化」に緩和、影響評価引き上げ
3 3 1 2 Permission承認の現状が事実と異なる（通知のみで代理承認は未実装）、tmux send-keys→tmux.py send、jobs.json影響さらに引き上げ 全セクション統一、tmux.py sendに全修正、「機能リスク」に引き上げ
4 1 1 0 4.2のPermission承認に旧表現残存 統一漏れを修正
5 1 1 0 3.1/5.2/P2#11にまだ「tmux代理承認」残存 全箇所を「通知のみ実装済み」に統一
6 2 1 1 Permission Relayが調査メモで確認済みなのに「未確認」、3.1にファイル名未明示 「公式機能として存在確認済み」に修正、ファイル名明示
7 4 0 4 PermissionRequestのEdit/Write限定が未記載、P0に新規スクリプト必要な項目、検証SQL不十分、memory/パス不正確 対象範囲明示、P0→P1移動、SQL改善、パス修正
8 4 0 4 成功定義にverification_checks不足、計測SQLも同様、P0見出し矛盾、SQL例不正確 成功3条件明示、#2/#3をP1移動、SQL全面改訂
9 2 0 2 SQL照合がid比較でなくcondition文言ベースであるべき、jobs.json修正優先度が未確定 condition照合に修正、P1に確定
10 2 0 2 done_when未登録ジョブの検出漏れ、トークン計測がwc -wでは日本語で不正確 NOT EXISTS追加、count_tokens APIに変更
11 1 0 1 完了時刻の基準カラム（done_at vs updated_at）が未確定 done_atを基準と明記、定量指標も統一
12 1 0 1 RETRYジョブでsent_at→done_atが総リードタイムを区別できない sent_atが総リードタイムである注記追加、last_sent_atカラムをP2課題に
13 0 0 0 LGTM --
📝 質問モード — テキストを選択してね
✓ 質問を送信しました