AIエージェント（Claude Code）にObsidian Vaultを使った「第二の脳」を持たせて運用を始めてから1週間が経ちました。指示書の肥大化、棚卸し忘れの発覚、記憶読み込みの肥大化など、いくつかのつまずきを経験してきましたが、今回は、直近約2週間、noteの週まとめ記事で3回続いたリンク漏れを題材に、「ルールを書くこと」と「再発を防ぐこと」の違いについて実例で紹介します。
「週まとめ記事」で3回連続起きたリンク漏れ
週の節目に、その週に紹介した記事を振り返る「週まとめ記事」を書くことがあります。その際、紹介する各記事へのリンクを本文に貼る必要があるのですが、これが7月12日・7月19日・7月24日と3回連続で漏れていました。
漏れに気づくたびに「今後は気をつける」という注意事項をルールとして書き足していましたが、それでも次の週まとめ記事で同じミスを繰り返してしまいました。
なぜ「気をつけます」では直らなかったのか
ルールを文書に書き足すことと、実際にその事故を防ぐことは、まったく別の作業だったからです。注意書きは、次に下書きを書く際にたまたま思い出せれば効果を発揮しますが、思い出せなければ何の防御にもなりません。これは人間に限った話ではなく、AIエージェントが下書きを生成する際にも、指示書の注意点を見落とすことがあります。
実際に行った対処：ルールをコードのチェックに変える
そこで、下書きを投稿する処理そのものに、機械的な検証を組み込みました。具体的には「週まとめ系のタイトルであるにもかかわらず、本文に紹介記事のURLが1つも含まれていない場合に警告する」という検証スクリプトです。投稿のたびに自動的に実行されるため、書き手が注意点を思い出す必要がなくなります。
翌日、別の掲載忘れが発生
ところが、この修正を反映した翌日、今度は期間限定で案内していたキャンペーン告知を本文に書き忘れるという、別の掲載忘れが発生しました。
原因の構造がリンク漏れと同じだったため、今回も「ルールとして覚えておく」のではなく、同じ検証スクリプトに「キャンペーン期間中であるにもかかわらず、本文に案内の記載がない場合に警告する」というチェックを追加しました。
2日連続で同じ教訓を受け取った理由
1つのミスを仕組みで直した直後に、構造がよく似た別のミスが発生したという点では、決して格好の良い展開ではありません。しかし、「ルールを書いて終わりにせず、コードで防ぐところまでやる」という対処の型が一度身についていれば、次に似た抜け漏れが起きた際の対応は速くなります。実際、2件目の掲載忘れに気づいた際は、対応にかかった時間はごくわずかで済みました。
振り返ってみると、この1週間で扱ってきた「指示書の圧縮」「棚卸し忘れの発覚」「記憶読み込みの肥大化」も、根っこは同じ構造の問題でした。仕組みを作った時点では正しく機能していても、運用を続けるうちに別の場所でほころびが出る。そのほころびに気づいたとき、応急処置で終わらせず、同じ理由で再発しない形まで直せるかどうかが、長く運用を続けられるかどうかの分かれ目になると感じています。
よくある質問（FAQ）
Q. ルールを文書に書くこと自体は無意味なのでしょうか？
A. いいえ、ルールを言語化すること自体は必要な最初の一歩です。問題は、それだけで実行を担保できると考えてしまうことです。文書化したルールのうち、繰り返し違反が起きるものについては、機械的なチェックへ落とし込む価値があります。
Q. すべてのルールをコード化するべきでしょうか？
A. 必ずしもそうではありません。今回のように「同じ種類のミスが繰り返し発生している」箇所を優先してコード化するのが現実的です。頻度が低いルールまで無理にコード化すると、検証コード自体の保守コストが増えてしまいます。
まとめ
AIエージェントを使った運用の中で、「ルールを書く」ことと「実際に事故を防ぐ」ことは別物であり、繰り返し発生するミスに対しては、注意書きではなく機械的な検証の仕組みに落とし込むことが有効だという実例を紹介しました。ルールを言語化した後、それが繰り返し破られるようであれば、次はコードでチェックする仕組みまで作り込むことをおすすめします。
