参謀AI構築案

ローカルデータを優先して検索し、不足時のみWeb検索にフォールバックする常駐型参謀AI。

→ イリスペルソナ変遷

変遷

日付	出来事
2026-04-19	「秘書AI」として構想スタート。アーキテクチャ・検索フロー・失敗パターンを設計
2026-04-21	ペルソナ設計・購買履歴の自動抽出を追加
2026-05-03	「参謀」に改名。Todoistワークフローが入り、イリスとして実用化し始める
2026-07-21	人間がtaskを選ぶ運用から、Supervisorが意図を統合・委譲する非同期監督型へ移行開始

「秘書」から「参謀」への改名理由

当初「秘書AI」と呼んでいたが、作ろうとしているものの方向性を考えると「参謀」のほうが適切。秘書は気づきを与える存在ではなく、外部折衝やタスク管理などを行うもの。一方参謀は相手の中身を理解したうえで問題提起・分解・解決を行う。行いたいのは自分の中の考えを引き出して言語化することを手伝ってほしい、というところなので参謀が向いている。

最終的には複合的ペルソナまたは複数エージェントになるかもしれない:

• 司書 — 知識の管理・検索
• メンタリスト — 思考パターンを読んで先回り
• 軍師 — 統合して能動的に提案

参謀AIの振る舞い

• ユーザーがふと考えたことについて分解し、改善点や思考を引き出す
• PKMから情報を引き出し、気づきを与える
• 調査を行い、自分の考えを補強・修正する手伝いをする
• 何をしたいかはユーザーが決め、どう実現するかの細部をAIが埋める

思想

LLMは推論エンジン、知識は自分のVaultに置く。

AIに聞く前にまず自分のObsidianのVaultを参照する設計にする。Permanent noteやDailyに蓄積された文脈は、Web上の一般情報より自分の判断に近い。ローカル知識が足りないときだけWebに出ることで、「自分の思考の延長」として機能する参謀になる。

AI専用のメモリとPKMは分離する。

全部をMarkdownに押し込まず、AI用のstructured storeを別に作り、必要なときだけObsidianに昇格させる。会話ログの揮発問題への対処でもある。

アーキテクチャ

層	役割
Interface	CLI・通知・スマホ入力口
Orchestrator	タスク分解・状態管理・承認フロー
Memory	長期記憶・検索（SQLite + embeddings）
Executors	shell・API・browser automation
Policy	allowlist・confirm rules・audit log

常駐の形は3段階で広げる：受動（ホットキー起動）→ 能動（イベント監視・提案）→ 自律（定時バッチ・自動実行）。自律は最後、最初は「提案のみ」から。

記憶の設計

記憶を3種類に分けて管理する。

• エピソード記憶 — 「昨日この件を依頼した」「返信待ち案件」
• プロファイル記憶 — 好み・使うツール・頻出手順
• ワーキングメモリ — 進行中タスク・未承認アクション

検索フロー

Web検索層にはTavily（AI検索API参照）を使う。

1. クエリ分類 — Vaultで足りるか、Web必要か判定
2. ローカル検索 — VaultをBM25+ベクトル検索で参照
3. 不足判定 — 根拠件数・鮮度・Vaultに答えがないケースでWebへ
4. Web検索 — Tavilyで追加根拠取得
5. 回答生成 — Vault根拠とWeb根拠を分離して出典を明示

失敗パターン

• 記憶を何でも保存して汚染される
• タスク状態が曖昧で同じことを何度も提案する
• 実行権限が広すぎて怖くなり使わなくなる
• 監視イベントが多すぎて通知疲れする
• 人間可読のPKMとAI用メモリを混同する

NixOS環境ではsystemd user serviceとして常駐化し、設定をflakeで宣言管理するのが相性が良い。

参謀AIに多くを任せることはAI依存のリスクも伴う。AIと自律性参照。

タスク管理ワークフロー

自作タスク管理アプリの凍結に伴い、既存ツール+エージェントで代替する構想。

• 入力: 出先ではTodoistに書き留める（やりたいこと・アイデア・TODO）
• 管理: エージェントがTodoist API/CLI経由でリストを操作する
• 提案: エージェントが「今日やること」を提案する。基準は効果が高く対応コストが低いもの、および進行中プロジェクトの集中深掘り
• 終了: ユーザーが「もういい」と言ったら提案を止める

Obsidianは出先での入力には使わない（ウィジェットの使い勝手が不十分なため）。エージェントがTodoistとObsidianの両方を参照し、統合的に判断する。

未解決：購買履歴の自動抽出

購買履歴をエージェントに読ませ、ノートに関連するものや高額品を自動抽出・振り返りを促す構想がある。ただし購買データの一元化が課題で、Amazonは購入履歴APIが実質使えず、他の通販・実店舗・現金払いをカバーする手段がない。クレジットカード明細が最も網羅性が高いが品目が粗い。実装は保留。

ペルソナ設計

ペルソナは簡潔に（3–6項目、行動例1つ）。長文プロファイルは避け、固定プロファイル＋動的な「recent memories」をRAGで注入する。

メモは要約して重要度スコアを付与し、高重要度のみ長期保存する。TTLは数日でよく、古い雑談は自動凝縮・削除する。

評価はA/Bでタスク成功率と誤命令率を比較する。

ユビキタス化の検討

イリスをユビキタスに動かす参照。スマホ含む複数デバイスでの運用を検討したが、現時点では従量課金コストの問題で見送り。

異常検知型の秘書エージェント

一文定義

異常検知型 statusline の生活全域への一般化。常時表示せず、外れたときだけ浮かぶ秘書。

解剖図

• 目 — 信号アダプタ群
  • 予定（Radicale）
  • 天気
  • 交通
  • presence（LAN在圏 + PC最終入力）
  • 追加は週1本までに制限する
• 心臓 — Hermes の15〜30分ハートビート
  • LLMはステートレスにする
  • 状態はすべてファイルに保持する
• 口 — ntfy（UnifiedPush）
  • morning-paper と共用レールにする
  • presenceに応じて通知先を選ぶ
    • 在宅・active → デスクトップ
    • 外出 → スマホ
• 記憶 — Markdownファイルを正本にする
  • 人格
  • 監視リスト
  • 当日のstate（送信済み・保留キュー）
  • Hermesに依存しない可搬資産とし、エージェント本体は使い捨てられるようにする

判断の核

挙証責任は発言側に置く。黙るのに理由はいらない。

出力は次の三値に限定する。

1. 今すぐ割り込む
2. 保留キューに積む
3. 黙る（理由はログに残す）

割り込み判定の原則は一つ。

次の自然な接点まで待つと、価値が減衰するか。

秘書の本体は、賢い発言ではなくバッチングにある。

presenceは割り込みコストの項として扱う。活動中は割り込み閾値を上げ、離席中は保留キューに倒す。

育成機構

• すべての通知に初日から 👍 / 👎 を付ける
• 沈黙ログを育成データの半分として扱う
• 偽陰性は、沈黙の記録がなければ永久に不可視になる
• 週次レビューで閾値と事例集を更新する
• 割り込み権は領域ごとの段階制にする
  • まずは予定 + 天気から開始
  • 打率を確認してから対象領域を拡張する

Week 1の安全要件

• 一発で止められる kill スイッチ
• 発火ログの常時記録
• 過集中ガードを必須にする
• read は広く、write は狭くする
• 書き込みはドメインごとの単一ライタ経由に限定する

先行事例から輸入する禁則

• 通知は1日数件を上限とする
• ステートレスな設計にしない
• ベクトル検索は導入しない
  • Markdown + grep で足りる範囲から始める

スコープ境界

次は初期スコープから外す。

• 在庫管理
  • 人間の記録規律に依存する設計は避ける
  • 必要になった時点で購入周期推定から検討する
• コミュニケーション取り込み
• MF移行
• 本物の位置情報（OwnTracks）

これらは格上げ枠として凍結する。

1ヶ月後の続雇判定

次の2軸で継続を判断する。

• 割り込み打率（👍率）
• 不在日の不便感

合格なら、次の単位を切り出して拡張する。不合格なら、観測不足だった点を言語化するだけにして畳む。

非同期監督型への移行

参謀AIを、質問に答えたり次のtaskを提案したりする存在から、仕事の流れそのものを監督する存在へ進める。

人間は思いつき・訂正・撤回を自然言語で随時投入する。Supervisorはそれらをすぐ実行せず、冷却・統合・優先順位付けしたうえで、調査・実装・検証を権限の異なるAgentへ委譲する。

人間の役割は、細かなtaskの選択から、上位目的・例外・実環境適用の判断へ移す。

初期は上位目的を一つに固定し、その内部だけを並列化する。並列運用が完遂率やレビュー負荷を悪化させないと確認できた時だけ、上位目的数を増やす。

Codexを多く使える最初の一か月は、仕事量を最大化する期間ではない。反復判断をscript・Skill・runbookへ移し、強いモデルを常時呼ばなくても運用できる状態を作る期間とする。

→ ADR-013-supervisor-driven-work-system

詳細仕様と実装計画の正本：

• ~/.dotfiles/docs/hermes-supervisor-system-spec.md
• ~/.dotfiles/docs/plans/2026-07-21-hermes-supervisor-mvp.md