ObsidianのAIエージェント運用｜権限表と失敗談で作るルール

ObsidianのVaultにAIエージェントを住まわせると、すぐに悩むことが出てきます。「どこまで確認なしで任せるか」という線引きです。ここは承認の必要はないのでサクサク進めてほしい、こっちは勝手に進められると困るので確認が必要…など悩ましさが出てくるんですよね。

前回の記事では、ClaudianでClaudeをVaultに組み込む手順と料金の話を書きました。今回はその続きで、導入したあとの運用編です。

最初に結論を言うと、私は領域ごとに確認の要否を決めた「権限表」を作り、失敗するたびにルールを直していく形に落ち着きました。最初からカチッと完璧に設計する話ではなく、運用しながら直していく、実運用の話です。

最初に決めたいのは「どこまで確認なしで任せるか」

AIエージェントにVaultの中を自由に触らせるなら、最初に決めておきたいのが任せる範囲のラインです。決めずに始めると、毎回「これは頼んでいいのかな」と考えることになります。

ここでは、私が実際に使っているルールファイルと権限表の考え方を紹介します。

ルールファイルで振る舞いの土台を作る

土台になるのは、Vaultのルート付近に置くルールファイルです。私の場合はCLAUDE.mdで、役割・口調・Vaultの構造・作業時のルールを書いています。

エージェントによってはAGENTS.mdという名前のファイルを読む構成もあります。私はClaude（Claudian）しか使っておらず、Codexなど他のエージェントは実際には試していません。お使いのエージェントがどのファイルを読むかは、各公式の情報で確認してください。

ルールファイルは、放っておくと長くなります。そこで、ブログ執筆、LLM Wiki（AIが参照するための知識ベース）、エージェントの記憶など、領域別のガイドラインは別ファイルに分けました。本体を短く保てるうえ、その領域を触るときだけ読み込ませられます。また、部分的に分けておくことでメンテナンス性も上がります。

もうひとつ、Gitで管理している場合は.gitignoreの設定も忘れずに。個人情報や非公開データを含むフォルダは、コミット対象から外しておきます。くれぐれもパーソナルなデータをコミット範囲内に入れないように気をつけましょう。

確認要否の権限表を作る

次に作ったのが、領域ごとの権限表です。「新規作成」「既存の編集」「移動」「削除」の4つの操作について、確認が必要かどうかを一覧にしてルールファイルに常設しています。

私の表を、フォルダ名を一般化して載せます。

領域	新規作成	既存の編集	移動	削除
メモ・下書き・ブログ	確認不要	確認不要	確認不要	要確認
未整理フォルダ（inbox）	確認不要	要確認	要確認	要確認
個人情報を含む領域	禁止	禁止	禁止	禁止
上記以外のすべて	要確認	要確認	要確認	要確認
システム設定（.obsidian・.gitなど）	禁止	禁止	禁止	禁止

考え方は次の4点です。

• 普段からAIに整理を任せている領域は、編集や移動まで確認不要にして、作業スピードを優先する
• 未整理フォルダは、新規作成だけ確認不要にする。編集や移動を許すと、仕分け前の状態が崩れてしまうため
• 個人情報を含む領域は、読み取り専用にしてAIの対象から外す
• 削除だけは、領域を問わず常に確認を挟む

「削除だけは例外なし」という一文を、表の外にも書いておくのがコツです。領域ごとの例外を増やしていくと、いつの間にか抜け道ができるためです。

最初から完璧な表は要りません。運用しながら「ここは確認なしで大丈夫だった」「ここは危なかった」を見つけて、その都度表に反映していけば十分です。自分で決めきれないときは、AIに相談しながら作るのもおすすめです。

ルールは「指示」であって「制限」ではない

ここで一点だけ、注意しておきたいことがあります。ルールファイルに書いた権限表は、エージェントへの指示です。エージェントがそれを守ってくれる前提で動きますが、システムとして操作を止める仕組みではありません。

強制力が必要な場面では、Claude Codeの権限設定（denyなどのルール）や、Gitによる変更履歴、別途バックアップとの併用が安全です。設定方法は公式ドキュメントの権限を設定するにまとまっています。私の運用は、権限表をベースにしつつ、Gitで元に戻せる状態を保っています。

手順を一言で言えるか：スキル・コマンド・子エージェントの使い分け

ルールで振る舞いの土台ができたら、次は「具体的に何をどう任せるか」の仕組みを用意します。私は大きく3種類を使い分けています。

種類（私の使い分け）	発動のしかた	向いている作業
コマンド	/commandで発動	手順が決まっていて、判断が要らない定型作業
スキル	/スキル名、または会話から自動発動	手順は決まっているが、内容によって判断や調査が要る作業
子エージェント	本体から依頼して委任	特定の専門領域を任せきりにしたい作業

迷ったときの目安は次のとおりです。

• 手順を一言で説明できて、判断も要らないなら、コマンド
• 判断や調査が絡むなら、スキル
• 専門領域を継続的に任せたい、または役割を分けて事故を防ぎたいなら、子エージェント

子エージェントは、本体とは別の役割を持たせ、使えるツールの範囲も変えられる点がポイントです。たとえば校正を担当する子エージェントには編集権限を与え、ファクトチェックを担当する子エージェントには「指摘だけ返して本文は編集しない」という権限にしています。

最初からきっちり作る必要はなく、「同じ指示を何度も繰り返しているな」と気づいたときに、コマンド化やスキル化を考える程度で十分です。必要になったら作る、必要ないなら作らない、これがメンテナンスを考えたときにも有効な判断だと思いました。

私が組んでいる仕組みの一覧

実際に運用しているものを、種類別にまとめます。試運転中のものも含みます。

種類	名前	役割
子エージェント	blog-editor	ブログ記事の校正・推敲
子エージェント	blog-factchecker	事実関係のチェック（指摘のみ）
子エージェント	blog-scout	ネタ探し・リンク点検
子エージェント	blog-competitor	競合記事の調査（読み取り専用）
子エージェント	vault-worker	Vault内の実作業全般を担う汎用ワーカー
スキル	blog-research / research-review	ゼロからの調査と、集めた調査内容の検証（工程を分離）
スキル	competitor-research	執筆前の競合リサーチと、既存記事の鮮度点検
スキル	grill-me	曖昧なアイデアを問い詰めて、計画書にまとめる壁打ち
スキル	wiki-ingest	Webクリップや個人メモを、知識ベースへ取り込む
スキル	sns-announce	公開記事のX・Misskey告知文を生成
スキル	article-summary	記事URLを日本語の概要にして保存
スキル	daily-log-fill	日次ログの「決めたこと」「見送り」欄を、短期記憶から埋める
スキル	weekly-monthly-review	週次の振り返りと月一メンテを、相談しながら進める
コマンド	commit-push	ルールに沿った、確認付きのコミット・プッシュ
コマンド	uma-calendar-sync	Googleカレンダーとウマ娘イベントの同期
コマンド	add-spots	撮影・観光スポットのノート作成

このほか、スキル自体を作る・改善するskill-creatorや、Obsidian操作・Bases・Markdown記法をサポートするスキルも使っています。これらのスキルは、Anthropic公式・Obsidianの開発者（kepano氏）が公開しているものです。物によってはそのまま使うのではなく、AIと相談しながら自環境に最適化してもらうと使いやすくなりますよ。私の場合は、表に挙げているgrill-meがまさにそれです。

Vault側の自動化も組み合わせています。タグを付けるとフォルダへ自動で振り分けるAutoMoverや、QuickAddのスクリプトによるステータス変更などです。QuickAddの運用は、Obsidianのステータス管理をQuickAddで自動化｜タグ運用をやめた理由で詳しく書いています。

定期的な情報収集は、クラウド側のルーティンに任せています。ただし、ローカルとクラウドの使い分けは別の記事で扱えるほどの内容なので、今回は触れる程度にとどめます。

運用で経験した失敗談

AIにVaultの作業を任せていれば、失敗は起きます。ここでは、実際に起きた事例と、その後の対処を紹介します。

リネーム後に旧名のパスへ書き込まれた

ノート名を変えたとき、Obsidian上のwikilinkは自動で追従します。だから「リンク切れの心配はない」と思い込んでいました。

ところが、スキルやコマンドの定義ファイル、.gitignoreの除外設定などは、wikilinkではなく生のパス文字列で旧名を持っています。こちらは自動追従の対象外でした。

結果として、リネーム後にスキルが旧名のパスへ書き込み、存在しないはずのファイルが新規に作られました。重複ノートの発生です。

この経験から、「リネーム・移動のあとは、Vault全体で旧名の文字列をGrep検索する」という手順をルールに追加しました。設定ファイルやスクリプトへの参照も、ここで洗い出します。エージェント運用ならではの、見落としやすいポイントだと感じています。

ミス記録を仕組みにして再発を防ぐ

失敗は、記録して終わりにすると同じことを繰り返しがちです。そこで、エージェントが繰り返しやすいミスを専用のメモファイルに蓄積し、「同じ状況になったらこのルールを思い出す」仕組みにしました。

記録する基準は絞っています。1回限りの事情によるものは残さず、同じ種類のミスが2回以上起きたものだけです。何でも記録すると、肝心の教訓が埋もれてしまうためです。

地味な運用ですが、任せる範囲を広げるほど、こうした振り返りの型が効いてきます。

失敗をきっかけに、チェックを置くようになった

ルールを直すだけでは防ぎきれない失敗には、チェックを置くようにしました。ここでは、きっかけになった例を3つ挙げます。

• 自動の収集が、何も取れないまま空振りしていた: 定期実行の取り込みが「対象0件」で終わっていたのに、私が指摘するまで気づきませんでした。そこで、週次のメンテナンスで「ほかの自動処理が動いた形跡があるか」を確かめるようにしました。
• ルールを読まずにファイルを書かれた: 専門ガイドラインがあるフォルダに、読まないまま書き込まれることがありました。Hooks（特定の操作の前に、自動でスクリプトを走らせる仕組み）を使い、読んだ形跡がなければ書き込みを止めるスクリプトを自作して組み込みました。完全な保証ではありませんが、読み忘れを減らす手段としては役立っています。
• 記事の公開後に、運用ノートの更新が漏れた: 公開した記事が、アイデアメモ側に反映されていませんでした。公開時のリマインダーと、週次の点検の二段構えで拾っています。

どれも、最初から設計していたわけではありません。失敗が起きてから、「次は何で気づけるか」を考えて足していったものです。

記憶と自己改善を仕組みにする

失敗を記録するだけでなく、それを運用に反映し続ける仕組みも整えています。ここでは要点だけ紹介します。

短期記憶と長期記憶を分ける

日々の作業ログは、日付ごとの「短期記憶」として残しています。一定期間が過ぎたら、月単位にまとめてアーカイブします。

その中から「あとで参照する価値のある意思決定や経緯」だけを、トピックごとの「長期記憶」として別に保存します。昇格し忘れが出ないよう、週次のチェックで候補を拾う仕組みも用意しました。

ルール変更を「お題」で検証する

ミスを記録するとき、「やったこと」「正しい動作」に加えて、同じ状況を再現する依頼文（お題）も残します。ルールを直したら、同じお題をAIに解かせて、修正前後の挙動を見比べるわけです。

判定の軸は2つあります。最終結果が合っているかと、途中の確認手順を踏んでいるかです。結果だけ合っていても、確認を飛ばしていれば不合格にしています。

記録漏れを多層で防ぐ

記録は、その場で残すのが基本です。ただ、1層だけに頼ると抜けるため、層を重ねています。

• コミットなどの定型コマンドの実行時に、当日分の記録漏れを自動でチェックする
• 週次のルーティンで、もう一段確認する
• それでも拾えなかった分は、気づいたときに手動で棚卸しする

この部分は、また別の機会に詳しく書くかもしれません。

運用を整えて変わったこと

導入前は、Vaultの整理・リンク修正・記事の校正といった作業を、思いついたときに手動で進めていました。「今日はここまでやった」という状態も、自分で把握しておく必要がありました。

ルール・スキル・子エージェントを整えた今は、領域ごとに確認要否が決まっています。迷う場面が減り、記事の下準備（リサーチ・ネタ探し・校正）やVaultのメンテナンスを、かなりの部分任せられるようになりました。

一番の変化は、「AIに何を任せていいか」を毎回考え直さなくて済むことです。仕組みが決まっているぶん、新しい作業を頼むときの心理的なハードルも下がりました。

まとめ

AIエージェントの運用は、最初から完璧に設計しなくても回り始めます。今回のポイントを整理しておきます。

• 領域×操作（新規作成・編集・移動・削除）で、確認要否を表にする
• 削除だけは、領域を問わず常に確認を挟む
• ルールは「指示」なので、強制力が必要ならGitや権限設定を併用する
• 道具は、手順が一言で言えるならコマンド、判断が要るならスキル、専門領域は子エージェントに分ける
• 失敗は記録して、同じミスが繰り返されたものをルールに反映する

まずは「削除は必ず確認」の一行から始めてみてください。されては困ることから先に設定をする。そこから運用をしながら、自分に合った表に育てていくのが、無理のない進め方だと思います。作ったまま放置せず、ときどき棚卸しをして見直していくことも大切です。