「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は作業に入る前に、次のことをやる。

1. 追記のルールが書かれたファイルを読み直す

2. 対象のデイリーノート全文に目を通す

3. 一番下の体調テーブルを「動かしてはいけないブロック」として認識する

4. 追記はそのテーブルの上に入れる

5. 区切り線 `---` の前後に空行があるか確認する

6. 編集後、もう一度読み直して結果を報告する

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には「ちょうどいいタイミングで思い出させる仕組み」として作ってやる。

その仕組みづくり自体が、最近はちょっとした遊びになっている。