参謀AI構築案

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

イリスペルソナ変遷

変遷

日付出来事
2026-04-19「秘書AI」として構想スタート。アーキテクチャ・検索フロー・失敗パターンを設計
2026-04-21ペルソナ設計・購買履歴の自動抽出を追加
2026-05-03「参謀」に改名。Todoistワークフローが入り、イリスとして実用化し始める

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

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

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

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

参謀AIの振る舞い

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

思想

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

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

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

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

アーキテクチャ

役割
InterfaceCLI・通知・スマホ入力口
Orchestratorタスク分解・状態管理・承認フロー
Memory長期記憶・検索(SQLite + embeddings)
Executorsshell・API・browser automation
Policyallowlist・confirm rules・audit log

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

記憶の設計

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

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

検索フロー

Web検索層にはTavilyAI検索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でタスク成功率と誤命令率を比較する。

ユビキタス化の検討

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