AIとの作業で一番大事なのは「とりあえず記録すること」だった

以前、「Obsidianをもう一度はじめた話」と「ObsidianにAIを載せたら別物になった話」という記事を書いた。一度Obsidianをやめた人間が、Claude Codeと組み合わせることで復帰し、ノート処理や情報収集をAIに任せる運用を始めた、という話だった。

あれから数週間ほど運用を続けてみて、一つ確信に変わったことがある。AIとの作業で一番大事なのは、ツールの選定でもプロンプトの書き方でもなく、「とりあえず記録を残すこと」だった。

AIとの作業は「文脈」が全て

前回、「AIコーディングが後から苦しくなる原因はコンテキストの喪失だ」と書いた。セッションが切れると全て忘れる。これは仕組みで対処するしかないとも書いた。

あれから数週間、ADRを自動保存する運用を続けた結果、Vault全体で97件のADRが溜まった。数週間でこの数だ。

97件と聞くと多いように見えるかもしれないが、1件1件はそこまで長くない。「こういう問題があった」「こう判断した」「こっちの案は却下した。理由はこう」という3点セットが書いてあるだけだ。でもこれがあるのとないのとでは、翌日のセッション開始時の立ち上がりが全く違う。AIがVault内を検索して過去の判断を参照できるので、「前回こういう理由でこの方式にしましたが、今回もこの方針で進めますか？」と聞いてくる。人間が口頭で説明し直す手間がゼロになった。

何が変わったかというと、認知コストの負担が移った。複数のプロジェクトを並行していると、どれがどこまで進んでいたかを思い出すだけで疲れる。記録があればAIがそれを読んで文脈を復元してくれる。人間はAIの要約を見て「そうそう、それ」と確認するだけでいい。この差は、実際にやってみると想像以上に大きい。

「記録」は整理じゃない——raw保存の思想

ここが今回一番書きたかったことなのだが、記録する＝整理して保存する、ではない。

前回の記事で「人間がやることは3つだけ——1ノート1トピックで書く、適切なフォルダに置く、そのまま保存する」と書いた。これは運用の話だったが、数週間やってみて、もう少し踏み込んだ話ができる。

ポイントは「整理しなくていい」だけではなく、「整理しない方がむしろ良い」ということだ。従来のナレッジ管理とAI前提のナレッジ管理は、設計思想が根本的に違う。

	従来のナレッジ管理	AI前提のナレッジ管理
前提	人間が探す	AIが探す
整理コスト	人間が負担	AI処理で代替
検索性	フォルダ・タグ・リンクで確保	AI検索・セマンティック検索で確保
ボトルネック	整理の手間で記録が止まる	記録さえあればAIが構造化する
スケール	人間の管理限界に依存	ノート数に依存しない

整理にかけるコストよりAIの処理コストの方が安いなら、「全部突っ込んでAIに任せる」が合理的な選択になる。整理に時間をかけているうちにメモを取る習慣自体が死ぬ。それが以前の自分だった。今は書くことだけに集中して、構造化はAIに投げている。

記録が「仕組み」を育てる

記録が単なる記録で終わらず、運用改善の起点になる。これはやってみて初めて実感した。

記録から仕組みが育つサイクルはこうだ:

品質チェックシートがわかりやすい例だ。メール文面やブログ記事を出力するときに、サブエージェント（Claude Codeが裏で別のAIプロセスを起動する機能）がチェックリストに照らして検査する仕組みを入れている。で、ミスが見つかったらチェック項目を追加する。最初から完璧なチェックリストを設計するのではなく、失敗を記録して改善ループを回す。チェックシート自体が「記録の蓄積」として育っていく。

もう一つ具体的な例を挙げると、メールチェックスキルの変遷がある。最初は「3つのメールアカウントを巡回して内容を報告する」というシンプルなものだった。それが実際に使っていく中で問題が見つかり、ADRとして記録され、改善されていった。

日付	改善内容	きっかけ
3/29	チェック結果をVaultに記録	振り返りができなかった
3/31	Outlook既読化問題を対処	メールが勝手に既読になった
3/31	IPMessenger確認を追加	社内連絡の見落とし
4/1	タスク自動切り出し	手動でTODO転記していた
4/2	サブエージェント委任で高速化	処理が遅かった
4/3	Gmail→CLI、Outlook→ローカルMbox	アーキテクチャ刷新

メールチェックに関連するADRだけで16件。5日間で16回の改善だ。一気に作ったのではなく、使いながら「ここが不便」「ここでミスが起きた」と記録し、その記録をもとに改善を重ねた結果だ。

同じことがスキル全体にも言える。現在、Vault固有のスキルが29個、プロジェクト横断で使う共通スキルが5個、合計34個のスキルがある。これも最初から30個を設計したわけではない。日々の作業で「これ毎回やってるな」と気づいたものを、まずメモとして記録し、何回か繰り返して安定したらスキル化する。記録→パターン認識→スキル化、という流れが自然に回っている。

ADRが改善の連鎖を生み、スキルが日常の記録から育つ。記録は記録で終わらない。放っておくと勝手に仕組みに進化する。

正直な運用の話——完璧じゃなくても回る

ここまで書くと「すごく整った運用をしている」ように見えるかもしれないが、実態はそうでもない。そして「完璧じゃなくても記録があれば回る」というのが、今回の主張の裏側にある話だ。正直に書く。

タスク管理は一度棚卸しをしたとき、アクティブなノート63件のうちTODOが定義されていないものが12件あった。「処理中」とされているのにやることが書かれていない、という状態が放置されていた。結局100件近いTODOを一括で整理し直した。

定期タスクのトラッカーにも期限超過は普通に出る。メールチェックが21時間超過、ジャンク品チェックが5日超過、みたいなことは日常的にある。完璧な自動化なんてものは実現していない。

でも、それでいいと思っている。大事なのは「完璧に運用する」ことではなく、「記録が残っているからいつでも棚卸しできる」という安心感だ。期限超過があってもトラッカーに記録されていれば、次のセッションで「これ遅れてますよ」と通知が来る。TODOが形骸化しても、棚卸しスキルを回せば全件洗い出せる。

前回の記事で「完璧を目指すと挫折する」と書いた。今回もそれは変わらない。完璧な運用より、崩れても復旧できる運用の方がよほど持続する。そして復旧を支えるのは、結局のところ記録だ。

この先の話

「なぜ記録するのか」の答えはある程度出せたと思う。記録はAIの燃料であり、仕組みの種であり、崩れたときの復旧手段だ。

ただ、ここまで読んで「で、具体的にどうやっているの？」と思った人もいるだろう。CLAUDE.mdという464行の運用ルールファイル、スキルとセッション記録の3層管理構造、Obsidian Syncが同期してくれないディレクトリへの対処法——仕組みの実装の話は後編で書く。

後編を読む前に、一つだけ提案がある。今日の作業で何か一つ、テキストファイルに記録を残してみてほしい。ノートアプリでもメモ帳でもいい。「何をやって、なぜその判断をしたか」を1行だけ書く。それが仕組みの起点になる。