AIに読ませるメモは、判断と根拠を分けて書くことにしました

AIに頼むたびに、同じ前提を説明していました。エンジニアではないこと、Windowsを使っていること、このアプリでは前に何を決めたか。説明を忘れると、前に戻った提案が出ます。

それを減らすため、自分用のメモを作業前に読ませています。ただ、読ませるメモが間違っていたら、その間違いも繰り返します。

このブログの原稿を見直して、その問題が実際に見つかりました。

いい教訓にまとめたつもりが、間違っていた

廃止した3本について、初期の原稿には「全部が手入力だったから続かなかった」と書いていました。

でも酒ログには購入履歴の取得があり、メシレコも履歴から提案を作る設計です。「手入力が負担だった」という一部の振り返りが、3本全部の説明に広がっていました。

短くまとめた結論だけを残すと、次のAIもそれを読んで答えます。だから今は、見た事実と、そこから考えたことを分けるようにしています。

次の作業に使えるメモの形

たとえば漫画トラッカーなら、こう書けます。

事実

読んだ話数も、配信された最新話も、手で更新していた。

振り返り

自分は更新を続けなかった。最新話の転記が負担だった。

次に試すこと

最新話を管理せず、読んだ話数だけ残して足りるか試す。

「今日はこれをした」だけでも、見返すには役立ちます。でも、次にAIに頼むときのためには、なぜそうしたかも残しておきたくなりました。

いつ、何で確かめたかを付ける

いま使っている項目は、次のくらいです。

確かめたこと: 最新話は手入力。未読数はそこから計算する。
見たもの: アプリの説明と画面。2026-09-05に確認。
判断: 自分の用途では、最新話の転記を増やしたくない。
次に試すこと: 作品名と読んだ話数だけで、次回の読書に使う。
未確認: 外部から最新話を継続して取得できるか。

料金、バージョン、ログイン状態のように変わるものには、確認日を付けます。「稼働中」も、画面が開く意味なのか、自分のデータを入れて使っている意味なのかを分けます。

「確信あり」と書くだけでは足りません。元が前のメモだけなら、同じ話を信じ直しているだけかもしれない。大きな変更をするときは、実際の画面やコードにも戻ります。

古い方針を、そのまま並べて残さない

考えが変わったら、いま読む説明を直し、変えた理由を短く添えます。昔の話は、過去の記録として分けておきます。

追記するだけだと、上の段には「手入力」、下の段には「自動」と書かれたメモができます。読む側は、どちらを採ればいいか分かりません。

今やることを知るために、毎回すべての履歴を解読しなくていい状態にしておきたいです。

読ませたあとも、現物に戻る

メモを読ませると、同じ説明を繰り返す手間は減ります。でも「前に完成と書いてあるから、今回も大丈夫」とは考えないようにしています。

今回も、メモだけでは分からず、アプリのコードやファイル、実際の画面を見直して説明を直しました。メモを増やすより先に、今の判断を誤らせる古い1行がないかを確かめるほうが効く場面がありました。