「Obsidian + Codex」の運用でスキル作成によって繰り返されるミスを解決
以前、AIエージェントの使い分けについて投稿した。
ObsidianはほぼCodex、Zedで開くプロジェクトはClaude Code、と完全に分かれて落ち着いた、という内容。
その投稿の最後に、設定ファイルやスキルまわりのTips的な話は、また別で書く、と予告していた。
今回はそのうちの一つ。
Obsidian側、つまりClaudian上で動かしているCodexで、地味にハマって、地味に解決した話。
Codexは、Claude Codeと遜色なく、ファイルの作成・編集から情報の取得・分析まで、ひと通りこなしてくれる。
自分のObsidian運用は、デイリーノートが中心。
その日のデイリーノートを起点にして、新しいファイルを作ったり、考えごとを整理したり、調べものをして書き留めたり、という流れで動いている。
なので、「デイリーノートに何かを追記する」という操作が、とにかく頻繁に起きる。
本格的に「Obsidian + Codex」での運用を始めた頃は、特に問題は感じていなかった。
ところが、使い込んでいくうちに、ひとつだけ、どうにもうまくいかないことが出てきた。
「デイリーノートに、これ追記しておいて」。
人間からすれば、これ以上ないくらい簡単な指示。
それなのに、ある時期から、同じところで失敗するように。
最初はちゃんとできていたのに、だんだんAGENTS.mdを確認しないまま、「追記なんだから、既存のものにそのまま書けばいいだろう」という挙動に変わっていった。
そして、それが続いた。
何が起きていたか
自分のデイリーノートには、ちょっとしたルールがある。
ノートの一番下に体調管理のテーブルを固定で置いていて、その日の追記はテーブルの「上」に入れる、という決まり。
このルール自体は、AIに渡している設定ファイルAGENTS.mdにも、専用のコマンドにも、きちんと書いてある。
それでも、Codexはこうなる。
体調テーブルの「下」に追記して、テーブルが最下部じゃなくなる
区切り線 `---` の前後に空行を入れず、Markdownの表示が崩れる
特に区切り線。
`---` は前後に空行がないと、表示上ぐちゃっと崩れることがある。
最初の頃はやらかさなかったのに、いつの間にか、こういうミスを繰り返すようになっていた。
そのたびに「いや、それAGENTS.mdに書いてあるよね？」となる。
ルールが足りないわけじゃなかった
最初は、ルールの書き方が悪いのかと思った。
何度も書き換えたりしたし、確認すれば普通に書いてある。
最下部に体調テーブルを残すことも、追記はその上に入れることも、ちゃんと明記してある。
問題はルール不足ではなく、別のところにあった。
追記作業の直前に、そのルールを読み直していない。
ここに尽きる。
気になったので、ブラウザ版ChatGPTでも原因を調べてもらった。
そこで腑に落ちたのが、既存ファイルへの「追記」という作業の特殊さ。
まず、Codexの思考の流れは、ざっくりこうなっている。
AGENTS.mdを読み、指示を読み、対象ファイルを読んで、最後に「どこをどう編集するか」を推論する。
この一番最後の「編集位置の推論」が、人間が考えている以上に、追記という作業では一気に重くなる。
既存のMarkdownへの追記では、もとの構造、周りの文章、どこに入れるべきかの探索、ユーザーからの追加指示……と、大量の情報が一気にコンテキストへ流れ込む。
その中で、AGENTS.mdに書いてあった「追記前に必ずルールを確認」という一般論より、「いま目の前に見えている文脈に、自然に繋げよう」という推論のほうが勝ってしまう。
しかも、これは特殊な不具合というわけでもないらしい。
長いセッションのなかでAGENTS.mdの指示がだんだん薄れていく現象は、Context Drift（コンテキストドリフト）という名前で、すでに知られた問題なのだという。
ここで自分が理解したのは、コレ↓
長いコンテキストの中で「追記」のようなタスクに切り替わると、最初に読んだルールが、目の前の文脈に押し負ける。
人間が「言われたことを忘れる」のとは、ちょっと種類が違う。
ルールは目の前にあるのに、追記という直近のタスクに引っ張られて、参照しそびれる、という感じに近い。
これは優劣ではなく、向き合い方の問題
ここで思ったのが、Claude Codeのときは、こんなことで困らなかったな、ということ。
同じようにClaudeCodeの設定ファイルであるCLAUDE.mdにルールを書いておけば、追記もだいたい意図通りにやってくれていた。
ただ、これを「Claude Codeが賢くてCodexがダメ」と片付けるのは違う。
CodexはCodexで、指示に対する処理のキレや、サクッと動いてくれる感じが気持ちいいくらいで、メインで使うだけの理由がある。
そもそも、さっきの「長い文脈でルールの優先度が下がる」という現象自体は、程度の差こそあれ、生成AIのエージェントに共通して起こりうる話。
たまたま今回、Codexで自分の運用とぶつかって、はっきり表に出ただけ。
だったら、AIの賢さに期待して待つより、その現象を前提にして、こちらの渡し方を設計したほうが早い。
「いま何を参照すべきか」を作業の手前で明示してやれば、Codexの持ち味である的確さと速さが、そのまま活きる。
ちなみに、この「スキルにして運用したら？」という発想自体は、Codex側からは一度も出てこなかった。
ここも面白いところで、Claudian上のCodexは、Obsidianの設定ベースで淡々と動いている分、与えられた指示には忠実だけれど、「そもそもこの運用、別のやり方に変えたほうがよくない？」という一歩引いた提案には、あまり踏み込んでこない。
ミスは繰り返すのに、その根本対処を自分から言い出さないあたり、ちょっとヘンではある。
でもこれも、優劣というより、忠実さの裏返しとしてのクセなんだろうな、と受け取っている。
だから、運用の枠組みを考えるところは人間がやって、決まった手順を的確にこなすところはCodexに任せる。
その分担に落ち着いた。
「守るべきルール」を「作業前のワークフロー」に変える
原因が分かれば、対処の方向も見えてくる。
ChatGPTとそのまま壁打ちして出てきたのが、こういう方針だった。
AGENTS.mdは「常時の前提」であって、「作業直前のチェックリスト」ではない
既存ファイルへの追記では、周辺の文脈を読む推論が優先されて、冒頭のルールが薄れやすい
だから「守るべきルール」として足すより、「編集を始める前のワークフロー」として切り出すほうがいい
要は、ルールをもう一行増やすのではなく、「デイリーに追記するときは、まずこの手順を踏む」という入口を別に作る、ということ。
そして、その入口が発動したら、必要なルールファイルとデイリーの全文を、毎回そこで読み直す。
これなら、Codexが作業に集中する前に、参照すべきものを必ず通る。
なぜAGENTS.mdではなく「スキル」だったのか
ここがたぶん、Claudian上でCodexを使ううえで、一番コアで理解すべき部分だろう。
Claudianはプラグインの設定として、スキルをObsidian側に置いても、大元のCodex CLI側に置いても、どちらも拾って使ってくれる仕様になっている。
その前提で、AGENTS.mdとスキルの「読まれ方」を比べると、決定的な違いがある。
AGENTS.mdは、最初に一度読み込まれる常時ルール。
だから、追記のたびに毎回ちゃんと読み返してくれるとは限らない。さっきの、文脈に押されて薄れる、というやつ。
一方スキルは、そのタスクに該当したときに、作業の直前で読み込まれる。
つまり、「追記のたびに必ず読まれる場所」が欲しいなら、AGENTS.mdに書き足すより、スキルとして切り出すほうが理にかなっている。
繰り返し失敗する操作ほど、常時ルールに足すのではなく、作業直前に読まれるスキルに逃がす。
この使い分けに気づいたのが、今回いちばんの収穫だった。
追記専用のスキルを1つ作った
それで、デイリーノートへの追記・整理専用のスキルを1つ作った。
このスキルが発動すると、Codexは作業に入る前に、次のことをやる。
追記のルールが書かれたファイルを読み直す
対象のデイリーノート全文に目を通す
一番下の体調テーブルを「動かしてはいけないブロック」として認識する
追記はそのテーブルの上に入れる
区切り線 `---` の前後に空行があるか確認する
編集後、もう一度読み直して結果を報告する
AGENTS.mdのほうも、役割を変えた。
ルール本体を全部書き込む場所ではなく、「デイリーを編集するときは、必ずこのスキルを使え」とスキルへ誘導する入口にした。
ルールはスキルの中に集約して、AGENTS.mdは交通整理に徹してもらう、という分け方。
図にすると、こんな住み分けになる。
vault/ ← Obsidianのvault直下
└─ .codex/
├─ AGENTS.md
│ └─ 全体方針だけ書く
│ 「既存ノートを編集・追記するときは
│ obsidian-daily-append スキルを必ず使う」
│
└─ skills/
└─ obsidian-daily-append/
└─ SKILL.md
├─ 追記前のルール再読込
├─ 追記位置の確認（体調テーブルの上）
├─ 既存記法の確認（区切り線の前後の空行）
└─ 編集後のチェックと報告AGENTS.mdには「どこへ行くか」だけ書いて、「何をするか」はスキルに集約する。
この形にしておくと、追記のたびにスキルが呼ばれ、その中の手順が毎回頭から読まれる。
結果、ミスがなくなった
これで、あれだけ繰り返していた追記ミスが、ピタっと止まった。
体調テーブルが下から押し出されることもないし、区切り線で表示が崩れることもない。
追記のたびに自分でチェックし直す手間も消えた。
面白いのは、やったことは「ルールを増やす」ではなく、「読むタイミングを設計する」だったこと。
同じルールでも、作業のどの段階で参照させるかを変えただけで、結果がここまで変わる。
ここまでの「なぜ崩れるのか」と「どう解決したか」を、1枚にまとめるとこうなる。
判断プロセスの最後で目の前の文脈がルールに勝ち、構造が崩れる。それを、追記専用スキルで「毎回ちゃんと読ませる」ことで防ぐ。
ひとつの図にすると、やったことのシンプルさが、かえってよく分かる。
特殊なケースかもしれないが、応用は効く
ひとつ正直に書いておくと、今回のミスが起きたのは、自分のデイリーノートに「体調テーブルを最下部に必ず置く」という、ちょっと特殊なルールがあるから。
その固定ブロックの前後に追記するから、書く位置や `---` まわりの表示が崩れやすくなる。
なので、ただのメモを下にどんどん足していくだけ、みたいな使い方なら、ここまでの仕組みは要らないかもしれない。
ただ、ここで言いたいのは体調テーブルそのものの話ではない。
スキルを自作して作業直前に手順を読ませる、というやり方そのものが、Codex運用ではかなり使えるカードだということ。
たとえば、
何度同じことを指示しても、Codexがその通りに動いてくれない
AGENTS.mdにルールを足しても、同じ説明を毎回し直すはめになる
「ここは崩してほしくない」という体裁が、いつの間にか壊れている
こういう場面は、自分の体調テーブルに限らず、けっこう起きると思う。
そういうとき、ルールを書き足し続けるより、その操作専用のスキルを一つ作って、作業の直前に必ず読ませる。
これがCodexにはよく効く。
繰り返し失敗する操作があるなら、そこはスキル化のサインだと思っていい。
どちらも、使い方次第で活きる
今回の学びをまとめると、
長いコンテキストの中でタスクが切り替わると、最初に読んだルールの優先度は下がる。
だから、設定ファイルにルールを書き足し続けるより、「いつ・何を読ませるか」を設計したほうが効く場面がある。
そしてこれは、Claude CodeとCodexのどちらが上か、という話ではない。
Codexの特性を知って、スキルを上手く使ったり、足りなければ自分で作ったり。
そうやって付き合い方を工夫するのが、Codexを使いこなすコツだ、と。
もちろん、そこまでして使いたくない、というなら、素直にClaude Codeを使えば良いし。
ただ、CodexはClaude Codeと比べて、トークンの制限にわりと余裕があって、あれこれ試せる。
スキルを作っては動かして、ダメならまた直して、というのを気軽に繰り返せる。
この「いろいろ試せる」面白さがあるから、自分はObsidianとの運用をけっこう楽しんでいる。
人間なら一度言えば済むことを、AIには「ちょうどいいタイミングで思い出させる仕組み」として作ってやる。
その仕組みづくり自体が、最近はちょっとした遊びになっている。
