この記事の結論（先に3つだけ）
結論から書きます。毎朝AIが出してくれる「きのう何をしたか」の報告が、実際より多く数えられていました。外から持ってきた文章を保存しただけの記録まで、「仕事をした」と数えていたのです。直すために、Obsidian のプロパティに「これは保存しただけ」という印を付けることにしました。ところが翌日、その直し方そのものに穴が見つかりました。
- 動いた事業は6件と報告されていたが、本当は3件だった。 48件の記録のうち15件が、文章を保存しただけのものだった
- AIは、ファイルの名前しか見ていなかった。 保存しただけの記録と、手を動かした記録が、形の上で区別できなかった
- 直した仕組みが、直した記録そのものを「保存しただけ」と数えた。 印の説明を本文に書いただけで、引っかかっていた
50代・非エンジニアです。プログラミングはできません。
この連載では、AIを社員のように使って一人で事業を回そうとしている記録を書いています。第14回ではAIの見張り役の話、第15回では Git のブランチの話を書きました。
私は、AIとの仕事の記録を Obsidian というメモのアプリに全部ためています。そして毎朝、AIが「きのう Claude がやったこと」を事業ごとにまとめて報告してくれます。
今回は、その朝の報告の数字が間違っていた話です。2026年9月10日から11日にかけての記録です。
Obsidian の記録を数える朝の報告で、何が間違っていたのか
朝の報告で「動いた事業」が6件と出ていましたが、本当は3件でした。 前の日の記録48件のうち15件は、外から持ってきた文章を保存しただけのものでした。それを、AIが「その事業で仕事をした」と数えていたのです。記録は33件、残りの15件は保存だけ、というのが正しい数え方でした。
私の保管庫では、AIが仕事をひと区切りするたびに、記録を1件書きます。朝の報告は、その記録を日付ごとに数えて、「どの事業が動いたか」を一覧にしたものです。
ところが、記録には2種類ありました。
| 中身 | 例 | |
|---|---|---|
| 手を動かした記録 | AIが調べた・作った・直したことの記録 | 記事を書いた、設定を直した |
| 保存しただけの記録 | 外の文章や動画の要点を、あとで読むためにしまったもの | 気になった記事の要約 |
保存しただけの記録も、事業の名前を付けて同じ場所にしまっていました。そのため、9月9日は3つの事業が「動いた」と数えられていました。でも実際には、その3つの事業では誰も手を動かしていませんでした。
AIは、9月10日の朝の報告を訂正しています。
- 動いた事業：6件 → 3件
- 記録：48件 → 33件＋保存15件
なぜ Obsidian の記録を見分けられなかったのか
保存しただけの記録と、手を動かした記録が、形の上でまったく同じだったからです。 どちらも同じ種類の印を付け、同じように事業の名前を書いていました。しかも、数えるプログラムはファイルの名前しか見ていませんでした。中身を読まなければ区別できない状態で、名前だけを見て数えていたのです。
Obsidian の記録の先頭には、「プロパティ」という欄があります。Obsidian の公式の説明には、プロパティはファイルの先頭に YAML という形式で保存される、と書いてあります※1。
YAML とは、「項目の名前：中身」という形で、情報を1行ずつ書き並べる書き方のことです。先頭の --- と --- で挟んだ部分がそれにあたり、frontmatter（前書き）とも呼ばれます※2。
私の記録の前書きは、たとえばこんな形です。
---
type: log
project: ai-workflow
status: done
---
type: log は「これは記録です」、project は事業の名前、status: done は「終わった」という意味です。
問題は、保存しただけの記録も、手を動かした記録も、この前書きがまったく同じだったことでした。AIは記録に、「この記録は種類Aです」という区別を付けていませんでした。
さらに、朝の報告を作るプログラムは、ファイルの名前しか見ていませんでした。ファイルの名前に事業の名前が入っていれば、その事業が「動いた」と数える作りだったのです。
Obsidian のプロパティにどんな印を付けることにしたのか
前書きに kind: stock という1行を足すことにしました。 stock は「在庫」「たくわえ」という意味です。外の文章を保存しただけの記録には、この印を付けます。朝の報告は、この印がある記録を事業の稼働から外して、「素材の保存」という別の欄に並べるようにしました。過去の記録には印が無いので、当面は本文の決まり文句で見分ける仮の作りにしています。
AIが9月10日にやったことは、3つです。
- 朝の報告を作るプログラムに「素材の保存」の欄を作り、事業の稼働の数から外した
- 9月10日の朝の報告を、正しい数え方に差し替えた
- 見分ける印として
kind: stockを提案した
過去の記録は書き換えられない
ここで1つ、困ったことがありました。
私の保管庫には「過去の記録は書き換えない」という決まりがあります。複数のAIが同じ保管庫に同時に書くので、あとから書き換えると、ほかのAIの書いた内容を消してしまうことがあるからです。
だから、これまでの記録に kind: stock を足して回ることはできません。
そこでAIは、過去の記録については、本文に出てくる決まり文句で見分けるという分岐を入れました。
分岐とは、プログラムの中で「この条件ならこちら、そうでなければあちら」と道を分ける書き方のことです。印が付いた新しい記録は印で見分け、印の無い古い記録は決まり文句で見分ける。2本の道を用意したわけです。
ただしAIは、これを「文面が変われば効かなくなる暫定の作り」と記録に書いていました。8月31日、9月5日、9月8日の分でも、報告が壊れないことを確かめています。
Obsidian の記録の数え方は、私が何を決めたのか
私が決めたのは2つです。修正を取り込んでよいこと、過去の朝の報告はさかのぼって直さないこと。 保存しただけと判定された記録5件についても、本当に保存だけかを私が確かめました。私の要望は「分かるようにしてもらえば大丈夫」でした。数えないだけでなく、何を保存したかが見えていることが大事だったのです。
AIは、修正をまず「枝（ブランチ）」という別の作業場所に置きました。枝の話は第15回で書いたとおりで、本番の保管庫を汚さずに試せる場所のことです。
取り込んでよいと承認したとき、私が伝えたのがこの言葉です。
分かるようにしてもらえば大丈夫
AIはこれを、「消す・数えないだけでなく、何が保存されたかが見えていることが要件だった」と受け取っていました。新しく作った「素材の保存」の欄は、保存した記録の題を並べて見せる形です。だから、数からは外れても、何を保存したかは毎朝見えます。
9月10日の7時30分、修正は本番の保管庫に入りました。取り込んだあと、9月9日の分を数え直すと、動いた事業3件・記録33件・素材の保存15件と正しく出ました。
過去の朝の報告は、さかのぼって直さないことにしました。これは私の判断です。
Obsidian の印で直したのに、翌日に何が起きたのか
直した仕組みが、直した作業の記録そのものを「保存しただけ」と数えていました。 9月10日の2件の記録は、どちらも本文で kind: stock という印の説明を書いていました。判定は「ファイルのどこかにこの文字があるか」だったので、印を説明しただけの記録まで引っかかったのです。前書きの中だけを見るように直しました。
翌朝、9月11日。前の日に入れた仕組みに、おかしな点が見つかりました。
保存しただけとして数えられた記録の中に、次の2件が入っていたのです。
- 9月10日 7:00「素材の保存を事業の稼働と数えていた誤りを直した」
- 9月10日 7:30「素材の保存を分ける修正が承認され main に入った」
どちらも、AIが実際に手を動かした作業の記録です。外の文章を保存したものではありません。
原因は、判定のやり方でした。「ファイル全体のどこかに kind: stock という文字があるか」で見ていたのです。この2件は、本文で「kind: stock という印を付けることにした」と説明していました。印を付けたのではなく、印について書いただけなのに、文字が一致してしまいました。
前書きの中だけを見るように直した
AIは、判定を2か所直しました。
kind: stockは、前書き（先頭の---で挟まれた欄）の中にあるときだけ数える- 過去の記録の決まり文句は、文章の中に引用として書いた部分を取り除いた本文だけを見る
AIの記録では、コマンドや設定の文字を、記号で囲んで本文と区別して書くことがよくあります。その囲まれた部分は説明のための引用なので、判定の対象から外したのです。
直す前と後の数字は、こうなりました。
| 日付 | 直す前 | 直した後 |
|---|---|---|
| 9月10日 | 8事業／18記録／素材7件 | 8事業／20記録／素材5件 |
| 9月9日 | 3事業／33記録／素材15件 | 変化なし |
| 9月8日 | 4事業／17記録／素材0件 | 変化なし |
| 9月7日 | 8事業／21記録／素材2件 | 変化なし |
9月10日の分だけ、記録が2件増えて、素材が2件減っています。まさに、巻き込まれていた2件です。ほかの日は変わっていません。
この日の朝の報告も、訂正の一文を付けて正しい数字に差し替えています。
Obsidian のプロパティで分かった「印」の付け方（独自）
印は、決まった場所に置いて、決まった場所だけを見ることが大事でした。 本文のどこかに文字があるかで判定すると、説明しただけの文まで拾ってしまいます。前書きは「その記録が何者か」を書く場所なので、印はそこに置き、そこだけを読む。この順番を守れば、本文で何を説明しても数え方は狂いません。
今回の流れを、私なりに表にしました。
| 段階 | 判定のしかた | 起きたこと |
|---|---|---|
| 最初 | ファイルの名前だけを見る | 保存しただけの記録も「仕事をした」と数えた |
| 1回目の直し | ファイル全体に印の文字があるかを見る | 印を説明しただけの記録まで「保存」と数えた |
| 2回目の直し | 前書きの中に印があるかだけを見る | 正しく数えられた |
見るところが広すぎると、関係ない文字まで拾ってしまう。見るところが狭すぎると、区別に必要な情報を見落とす。今回は、その両方を1回ずつ踏んでいます。
そして、この kind: stock という印は、今では私の保管庫の決まりになっています。AI向けの決まりの文書には、「外の文章を保存しただけなら kind: stock を足す」と書かれています。
この連載の記事を書くときにも、この印は効いてきました。記事の材料を選ぶ手順に、「外の文章を保存しただけの記録（kind: stock）は材料にしない」と書いてあるのです。保存しただけの文章は、私の体験ではないからです。今回の記事も、印の付いていない、AIが手を動かした記録3件だけから書いています。
おわりに：Obsidian のプロパティでわかったこと
今回の区切りで分かったことは、次の4件です。
- 朝の報告の「動いた事業」は6件ではなく3件だった。 48件のうち15件が、文章を保存しただけの記録だった
- AIは、ファイルの名前しか見ていなかった。 保存しただけの記録と、手を動かした記録の前書きが同じだった
- 印は前書きに置き、前書きだけを見る。 本文のどこかで探すと、印を説明しただけの記録まで拾ってしまう
- 「分かるようにしてもらえば大丈夫」。 数から外すだけでなく、何を保存したかが見えていることが大事だった
まだ片付いていないこともあります。過去の記録を見分けるために入れた「決まり文句で見分ける」仮の作りを、いつ外すか。この時点では、まだ決めていませんでした。
出典
- ※1 Properties（Obsidian Help）
- ※2 Front Matter（Jekyll Docs）
