※この記事は、2026年8月時点の自分のブログ管理とAI運用について書いたものです。
先日、AIにブログ管理用のMarkdownを更新してもらった。
頼んだ内容自体は難しいものではない。
記事のUP版が完成したので、対象記事の状態を「下書き」から「UP版完成」へ変え、作成したファイル名を追記してもらう作業だった。
更新後のファイルには、追加してほしかった情報がきちんと入っていた。
一見すると、問題なく終わっている。
ところが、最後に周辺を確認すると、情報が入っていたのは対象記事の欄ではなかった。
少し前に作った、別の記事の履歴が書き換わっていた。
幸い、投稿本文やWordPressへ貼り付けるHTMLが壊れたわけではない。公開前の確認で見つけ、元へ戻した上で、正しい記事の欄へ追記できた。
ただ、この失敗で一つ分かったことがある。
AIにファイルを編集してもらう時は、何を書くかだけでなく、どこへ書くかを見出しまで固定する必要がある。
正しい内容が、間違った場所に入っていた
今回、AIへ渡した情報は間違っていなかった。
対象のファイルも合っていた。追記するファイル名も、変更後の状態も合っていた。
間違っていたのは、編集する場所だった。
ブログの管理ファイルには、記事ごとの記録が並んでいる。
それぞれの欄には、次のような似た状態文が入っている。
- 内容確認待ち
- 下書き未作成
- UP版完成
- WordPressへの貼り付け待ち
今回の更新では、その中にあった同じ状態文を手掛かりにした。
しかし、その文は対象記事だけにあるものではなかった。
過去の記事にも、同じ状態のまま残っている欄があった。
そのためAIは、先に見つかった別の記事の状態文を置き換え、そこへ今回のファイル情報を追加した。
文字列の置換として見れば成功している。
ブログ管理として見れば、明確な失敗だった。
これは文章生成の間違いではなかった
AIの失敗というと、事実と違う文章を作ったり、存在しない情報を補ったりする話が目立つ。
今回は少し違う。
文章の内容は正しい。ファイル名も正しい。書き方も、周囲の形式に合っていた。
それでも、入った場所が違えば使えない。
以前、URLや引用のように正解がある値は、AIにそれらしいものを作らせず、正本から取得した方がよいと書いた。
今回は、その次にある問題だった。
正しい値を取得できても、正しい記事へ結び付けられなければ、管理情報としては壊れてしまう。
AIに必要なのは、正しい内容だけではない。
その内容を入れる対象を、一つに決められる情報も必要だった。
ファイル名だけでは編集対象として足りなかった
最初は、対象ファイルを指定しているのだから十分だと思っていた。
しかし、一つのMarkdownに多くの記事履歴が入っている場合、ファイル名は入口にしかならない。
ファイルを開いた後、どの見出しを編集するのか。
その見出しの中でも、どの項目を置き換えるのか。
ここまで決まって、ようやく編集対象が一つになる。
たとえば、単にこう頼むだけでは弱かった。
管理ファイル内の「内容確認待ち。UP版未作成」を「UP版完成」に変更する。
同じ文が複数あれば、どれを変更するのかは決まらない。
少なくとも、次のように範囲を狭めた方がよい。
管理ファイル内にある「2026年8月21日」の見出しを探す。
その中の対象記事タイトルと一致する欄だけを更新する。
見出しや記事タイトルが見つからない場合、または複数見つかった場合は変更せずに止める。
日付だけで重複する可能性があるなら、記事タイトルや固有IDも組み合わせる。
AIに長いファイルを触ってもらうほど、対象を示す情報は具体的にした方がよさそうだ。
編集前に、一致件数を数える
今回のような誤更新を防ぐなら、置換する前に対象文が何件あるか確認する方法が使える。
一致が1件なら、そのまま変更できる可能性が高い。
一致が0件なら、見出し名や現在の状態が想定と違っている。
一致が2件以上なら、状態文だけでは対象を特定できていない。
この時点で止まり、見出しや記事タイトルを追加で確認する。
大事なのは、AIに何としても変更を完了させることではない。
対象が一つに絞れない時に、勝手に最初の一件を選ばせないことだと思う。
これは、AIへ細かい文章を書かせるためのプロンプトというより、ファイル編集の安全条件に近い。
今後は、整理やUP版作成のスキルにも、次のような条件を入れた方がよさそうだ。
- 対象見出しを先に確認する
- 固有タイトルまで一致させる
- 変更候補が1件であることを確認する
- 0件または複数件なら、自動で進めず報告する
AIの性能に期待するだけでなく、迷った時の止まり方を決めておく。
この方が、似た形式が繰り返される管理ファイルでは安定しやすい。
更新後は「文字があるか」ではなく「どこにあるか」を見る
今回、追記した文字列がファイル内に存在するかだけを確認していたら、成功と判断していたと思う。
必要だった情報は、確かに入っていたからだ。
しかし、本当に見るべきだったのは、その文字列が入った位置だった。
更新後は、少なくとも次を確認したい。
- 新しい内容が対象見出しの中に入っているか
- 対象記事の状態が意図どおり変わっているか
- 直前と直後にある別の記事が変わっていないか
- 変更箇所以外に予想外の差分がないか
全文を最初から読み直す必要はない。
変更した見出しと、その前後を見る。可能なら、変更前後の差分も確認する。
AIに編集を任せるほど、人間が見るべきものは完成後の全文ではなく、変更された場所と差分になっていくのかもしれない。
「書く作業」と「編集先を選ぶ作業」は分けて考えたい
今回の失敗は、AIが文章を書けなかったわけではない。
書く内容は作れていた。
問題は、それを入れる場所の選択だった。
この二つを一括りにして「AIにファイルを更新してもらう」と考えると、何を確認すればよいのか分かりにくい。
実際には、少なくとも二つの作業がある。
一つは、変更内容を作ること。
もう一つは、変更対象を特定すること。
文章作成が得意なAIでも、対象を決める手掛かりが曖昧なら、正しい内容を間違った場所へ入れる可能性がある。
だから、変更内容にはAIの生成力を使い、変更対象には見出し、タイトル、ID、一致件数のような構造を使う。
この分け方は、ブログ管理だけの話ではないと思う。
議事録の特定案件を更新する時。
学習記録の特定テーマへ追記する時。
Obsidianの長い一覧から、一つのノート情報だけを直す時。
設定ファイルの似た項目を変更する時。
同じラベルや似た文章が繰り返される場所では、内容より先に対象を一意にする必要がある。
まとめ
AIにブログ管理用のMarkdownを更新してもらったところ、追記内容は正しかったものの、別の記事の欄へ入っていた。
原因は、対象ファイルは指定していても、編集する見出しまで固定していなかったことだった。
同じ状態文が複数あるなら、文字列だけでは編集先を一つに決められない。
今後は、対象ファイルに加えて、見出し、固有タイトル、必要ならIDまで指定する。
変更前には一致件数を確認し、0件や複数件なら止める。
変更後は、新しい文字列が存在するかではなく、意図した見出しの中へ入ったかを見る。
AIにファイル編集を任せる時、正しい内容を作れることと、正しい場所を変更できることは別だった。
書く内容だけでなく、変更先と確認方法まで渡す。
今回の誤更新は公開前に直せたが、次からは最終確認だけに頼らず、編集前の時点で対象を一つに絞れる形へ変えていきたい。
コメント