指示は中央値24文字、ObsidianはAIが書く
Obsidian の vault を、AI が保守し、私は読んで決める場所にしました。
自分でノートを書く習慣がなくても、作業の経緯と全体像を残す意味はありました。
初回の自動週報では、自分で気づいていなかった未マージ PR が13本見つかりました。
この記事では、記録を AI に任せるための構成と、二重管理を避ける役割分担を紹介します。
自分で書かないなら、AIに書いてもらう
私は自分ではノートを書きません。AI への指示も中央値で24文字です。普段から短い指示で作業を進めているので、その後に自分で経緯をまとめ直す運用は、私の使い方に合いません。
Obsidian も、自分で書く人に向けた道具だと考えていました。書くつもりがない私が、そのまま使っても意味がない。これは製品の良し悪しではなく、私と運用の相性の問題です。
転換点は、「AI が書くなら意味がある」と考えたことでした。
作業を進めた AI が、その結果や決定を vault に残す。私はそれを読んで、現状を把握し、次を決める。ノートを書くことを私の仕事から外すと、Obsidian の役割がはっきりしました。
目指したのは、私の指示を長くすることではありません。短い指示から進んだ作業について、何が起きたのかを後から読めるようにすることです。入力する場所としてではなく、AI の作業を人間が見渡す場所として使っています。
vaultは「読む目的」で分ける
vault は、次の構成にしました。
| 場所 | 残す内容 |
|---|---|
| Home | vault を読むための入口 |
| daily | やったこと、見つかった問題、決定、次にやること |
| projects | プロジェクトの現状、経緯、未了事項 |
| decisions | 決定と理由。1決定につき1ファイル |
| howto | 手順 |
| reports | レポート |
| weekly | 自動生成する週報 |
| backlog | AI が自発的に改善を進めるためのキュー |
この構成では、同じ作業にも複数の見方があります。ある日の動きを知りたいなら daily、プロジェクト全体の状態を知りたいなら projects、判断の理由を知りたいなら decisions です。
特に、決定は日々の記録だけに埋め込まず、1決定1ファイルにしています。「何をしたか」と「なぜそう決めたか」は、後から読む目的が違うためです。決定と理由がまとまっていれば、その判断を見直すときの入口にもなります。
ただし、vault に何でも複製するわけではありません。事実の正本は AI のメモリ、経緯と全体像は vault、と役割を分けました。
両方を同じ情報の正本にすると、食い違った際にどちらを直すかという管理が増えます。AI が使う事実と、私が読むための説明を分けることで、二重管理を避ける設計です。vault は、メモリを丸ごと写す場所ではありません。
作業の節目に追記し、週1回で横断する
AI が vault を更新するタイミングは、作業完了、決定、問題発見のたびです。
完了したことだけを記録すると、読んだときには順調に進んだ部分ばかりが見えます。そこで、問題を見つけた時点も更新のきっかけにしています。daily に「見つかった問題」と「次」を含めるのも、作業の結果と残りを一緒に読めるようにするためです。
この随時更新に加えて、週1回、ヘッドレス実行で週報を自動生成しています。ここでいうヘッドレス実行は、対話画面で私が指示を出し続ける形ではなく、画面操作を伴わずに処理を走らせる形です。
週報の材料は、セッションログ、git、PR、常駐ジョブの状態です。
日々の記録は、その作業で起きたことを残します。一方、週報は複数の材料を横断して、残っているものや状態を確認する機会になります。個々の作業が終わったという記録だけでは、PR が未マージのままなのか、常駐ジョブの状態を把握できているのかまでは、見渡せないことがあります。
そのため、週報を日報の文章をまとめ直すだけのものにはしていません。作業の記録に加えて、git や PR、ジョブの状態も材料にしています。
初回の週報で、未マージPRが13本見つかった
初回の週報が拾ったのは、未マージ PR が13本あること、状態不明の常駐ジョブ、そして手動作業の残りでした。私は、それらに気づいていませんでした。
ここで見えた問題は、作業を進めることと、残った状態を把握することが別だった、という点です。AI に作業を任せていても、私が全体を把握できているとは限りません。
週報の価値は、きれいな活動報告ができたことよりも、私が確認すべきものが表に出たことにありました。PR が13本あるという具体的な状態が分かれば、それを読んで次の判断に進めます。
ただし、未マージだから不要だとは限りません。状態不明のジョブも、停止していると断定はできません。「手動作業が残っている」という記録も、作業の完了そのものではありません。
週報ができたことと、見つかった問題が片づいたことは分けて扱う必要があります。今回の仕組みで補ったのは、まず見落としていたものを読む機会です。AI が記録と整理を担い、私はそれをもとに決めるという役割分担が、ここで具体的になりました。
導入はフォルダ操作、秘密情報は置き場所だけ
Obsidian のインストールには Homebrew cask を使いました。AI による更新の中心は、vault 内のファイル操作です。
vault はただのフォルダなので、AI からは普通のファイル操作で足ります。ノートを更新するために、Obsidian の画面を操作する必要はありません。AI がファイルを書き、私は Obsidian で読むという分担です。
この構成では、導入方法そのものより、何をどこへ書くかが運用の中心になります。作業の記録は daily、判断の理由は decisions、全体の状態は projects というように、書き先に役割を持たせています。
また、秘密情報は中身を書かず、「置き場所だけ」の索引にしました。必要な情報を探す入口は残しつつ、秘密の値そのものをノートへ転記しないためです。
置き場所の索引も、公開してよい情報とは限りません。それでも、秘密そのものと、その所在を知るための情報を分けて考えることはできます。vault にすべてを集めるのではなく、読むために何を残すかを決める。この考え方は、AI のメモリとの役割分担にも共通しています。
学び
- 書く担当を先に決める。 自分でノートを書く習慣がないなら、AI が記録し、人が読んで判断する運用を検討できます。
- 正本と説明を分ける。 私は事実の正本を AI のメモリ、経緯と全体像を vault に置きました。同じ情報の正本を複数作らないことが大切です。
- 完了だけでなく、決定と問題発見も記録する。 成果に加えて、判断の理由と未了事項が読めるようにします。
- 週報には実際の状態も使う。 日々の文章だけでなく、git、PR、常駐ジョブを材料にすると、確認すべき残りを拾う機会になります。
- 秘密は転記せず、所在を示す。 読むための入口と秘密の中身を分け、vault に残す範囲を決めます。