ObsidianにAI会話全文を入れなかった理由：42会話・197メッセージで作った根拠の残し方

AIとの会話をObsidianへ全部保存すれば、あとから何でも検索できる。最初は私もそう考えていた。

実際にChatGPTの履歴を取得すると、1日分だけで42会話・197メッセージあった。これをそのまま保管すれば情報量は増える。しかし、中には認証の途中経過、内部のファイル名、失敗した試行、同じ説明の繰り返しも含まれる。

さらに困ったのは、会話ログをそのままブログ記事へ変えた時だった。本人にしか分からない専門用語が並び、「何を実装したか」は書いてあるのに、「読者の何が変わるのか」が分からない記事になった。

そこで私は、AI会話全文をObsidianへ入れるのをやめた。全文を捨てたわけではない。生ログは個人PCへ残し、Obsidianには安全化後の件数、判断、根拠、次の作業だけを入れるようにした。

この記事では、情報を減らしながら根拠へ戻れるようにした実際の流れを紹介する。

全文保存だけでは「根拠」が見つからなかった

会話全文を残す最大の利点は、あとから確認できることだ。一方で、保存量が増えるほど、次のような区別が難しくなる。

AIが提案しただけの内容
私が実際に試した内容
成功した結果
途中でやめた案
外部へ公開した内容
認証や秘密情報を含む非公開情報

AIが「できました」と返答していても、本当に公開されたとは限らない。ローカルにファイルができただけかもしれない。YouTubeなら動画ID、Kindleなら出版受付の識別情報、ブログなら更新後のURLや応答確認がなければ、外部成果として数えられない。

全文検索で「出版」という言葉が見つかっても、それが計画、下書き、提出、公開のどれなのかは別の話だ。

私が欲しかったのは、何でも入る倉庫ではなく、「何を根拠に次の判断をしたか」が見える台帳だった。

生ログとObsidianを二つに分けた

現在は、保存先を二層に分けている。

1. 個人PCに置く生ログ

ChatGPTやCodexの会話全文は、日付別のJSONとしてローカル領域へ置く。取得件数、メッセージ数、途中で切れていないか、取得失敗がないかも同じ場所で確認する。

ここは公開用の文章ではない。あとから事実を再確認するための一次記録だ。そのため、読みやすくする目的で内容を勝手に要約したり、失敗部分を消したりしない。

2. Obsidianに置く安全な日次台帳

Obsidianには、次だけを残す。

取得できた会話数とメッセージ数
生ログが欠損していないか
体験として使える候補数
ブログ、YouTube、Kindleへ渡す候補
当日の公開・提出結果
未完了作業と再開地点
会社ログが未受領、確認中、利用可能のどれか

確認日の実データは、42会話・197メッセージ、取得失敗0件、体験品質を通った候補2件だった。

Obsidianを開けば「今日は何件取れたか」「何が候補になったか」「次はどこから始めるか」が分かる。一方、詳しい会話へ戻る必要がある時だけ、ローカルの生ログを確認する。

この分離により、Obsidianの検索結果がコマンドや内部ログで埋まりにくくなった。

197メッセージを2件まで絞った基準

会話が多いからといって、投稿ネタが多いとは限らない。私は次の順番で候補を減らした。

個人情報、認証情報、会社・顧客情報を除外する
実際に試していない提案を除外する
「作業した」だけで、変化がない内容を除外する
迷い、失敗、変更前後、再現方法があるものを残す
すでに同じ切り口で公開していないか確認する

最終的に残したいのは、次のような体験だ。

problem: 何に困ったか
tried: 実際に何を試したか
failed: どこで失敗したか
changed: 何を変えたか
result: 何を証拠として確認したか
reader_action: 読者が次に何を試せるか

反対に、「スクリプトを実装した」「APIをつないだ」「ログを解析した」だけでは候補にしない。その説明を「毎朝15分かかっていた確認が自動で終わった」「公開待ちの記事を二度作らなくなった」のような変化へ言い換えられるかを見る。

情報を減らす目的は、きれいに見せることではない。実際に確認できたことと、AIの提案を混ぜないためだ。

根拠へ戻れる最小項目を決めた

Obsidianの日次台帳には、長い説明の代わりに、機械と人間の両方が読める短い項目を置く。

たとえば記事改善なら、次の情報を残す。

項目	意味
source_id	元記事や会話を識別する番号
checked_at	いつ確認したか
source_version	元データが最後に変わった時刻
artifact	完成した下書きの場所
article_sha	本文が同じか確かめる値
quality_pass	品質検査を通ったか
external_actions	外部を何回変更したか
next_action	次に再開する処理

この形式なら、「公開日は先だが、下書きは完成している」状態を表現できる。完成済みの下書きを未完了と誤認して、AIがまた同じ記事を書く無駄も防げる。

また、ObsidianのPropertiesは、テキスト、日付、チェックボックス、数値、リストなどの構造化データをノートに持たせられる。公式ヘルプでも、Propertiesは人間と機械の両方が扱いやすい小さな情報向けと説明されている。長い会話全文ではなく、状態や確認日を置く用途に合っている。

詳しい判断記録は本文へ書き、関連する日次台帳やプロジェクトノートは内部リンクでつなぐ。Obsidianはファイル名を変更した時に内部リンクを自動更新する設定も持つため、絶対パスを本文へ大量に貼るより扱いやすい。

会社PCのログを同じVaultへ入れなかった

仕事中のAI利用には、発信ネタになりそうな気づきがある。ただし、会社の会話全文を個人のObsidianへ同期する設計にはしていない。

会社名を消すだけでは不十分だからだ。顧客の課題、社内の手順、URL、アカウント名、数値、ファイル名の組み合わせから、内容を推測できる可能性がある。

会社側から使えるのは、会社環境で次の処理を終えた抽象的な気づきだけにした。

会社や顧客を特定できる情報を除く
秘密情報、認証情報、固有URLを除く
会社側で公開可能と判断された短い要点にする
個人PCでは「再検証が必要な発想」として受け取る
個人環境で同じ問題を別のデータで試す
個人の実験結果が出てから公開候補にする

会社側の安全な要点が届いていない日は、未受領と表示する。個人ログが正常だからといって、会社ログまで取得済みとは数えない。

この境界は、完全自動化より優先する。個人情報保護委員会の注意喚起でも、生成AIサービスへ入力した個人情報が、提供者側で機械学習に利用されないことなどを十分確認するよう案内している。社内規程、秘密保持、利用サービスの規約も別に確認が必要だ。

ブログ・YouTube・Kindleへ同じ文章を配らない

安全化後の体験候補ができても、三つの媒体へ同じ文章をコピーしない。

ブログでは、問題、失敗、手順、根拠リンクを詳しく説明する。YouTubeでは、一つの変化を冒頭で見せ、短い実演や比較へする。Kindleでは、同じ方法を複数の場面で使えるよう、章立てと演習へ広げる。

同じ日に別候補がある場合は、媒体ごとに題材を分ける。候補が1件しかない場合は、毎日の成果を止めず、読者、切り口、行動、結末を変えて使う。

これにより、「今日は品質が悪いから何も出さない」を避けながら、同じ内容の大量投稿も防げる。

今日から作れる小さな台帳

最初から大きなVault構成を作る必要はない。日次ノートへ次の項目を置くだけでもよい。

---
date: 2026-07-12
capture_ok: true
conversation_count: 42
message_count: 197
verified_idea_count: 2
company_status: not_received
raw_in_obsidian: false
---

本文には、今日の体験候補、使わなかった理由、媒体別の候補、次の再開地点を書く。元資料へ戻る必要があるものだけ、内部リンクや識別番号を付ける。

ObsidianのProperties公式ヘルプでは構造化項目の型とYAML形式、内部リンク公式ヘルプではノート、見出し、ブロックへのリンク方法を確認できる。

まとめ

AI会話を活用するために必要だったのは、全文をObsidianへ詰め込むことではなかった。

会話全文は個人PCへ欠損なく残す
Obsidianには安全な日次台帳だけを置く
42会話・197メッセージを、根拠のある体験2件まで絞る
AIの提案、実行、公開を別の状態として記録する
元データの版と成果物のハッシュで二重作業を防ぐ
会社ログは生データを移さず、個人環境で再検証する
ブログ、YouTube、Kindleは媒体ごとに切り口を変える

残す情報を減らしたことで、むしろ根拠へ戻りやすくなった。Obsidianは会話の倉庫ではなく、今日の判断と次の行動が分かる入口として使うほうが、私の運用には合っていた。

※会社の情報、個人情報、生成AIサービスへの入力可否は、所属組織の規程と利用サービスの最新条件を確認してください。

根拠を使える形にする次の記録

保存9件のうち6件しか見えなかった表示を直した記録では、保存成功と利用者が確認できる状態の違いを扱っています。
42会話から公開候補を2件へ絞った記録では、生ログを公開物へ直結させない選別工程を確認できます。