きれいにしただけでは、また散らかる
シリーズ外の記事では、ObsidianのVaultにあったMarkdown 21件、画像664件、画像参照600か所を整理しました。孤立画像64件は確認用へ分け、重複候補52組は自動削除せず、リンク切れが0件であることまで確認しています。
整理が終わった時点では、探しやすい状態になりました。ただ、これからAWSの作業を続けるたびに以前と同じ保存方法へ戻れば、また画像とログの対応が分からなくなります。
そこで今回は片付けの結果ではなく、次の作業からどう残すかを決めました。
最初は作業しながら記録すれば十分だと思っていた
AWSの設定中は、あとで分かるように画面を撮り、思いついた内容をMarkdownへ書いていました。その場では証跡が増えるので、記録できているつもりになります。
ところが記事にしようとすると、どの画像がどの手順に対応するか、試す前に考えていたことは何か、最終的にどこまで確認したかを探し直す必要がありました。
不足していたのは記録の量ではなく、作業単位で最初から置き場所を決めることでした。
作業ごとにログとscreenshotsをまとめる
整理後のVaultでは、作業ごとの連番フォルダに次の二つを置きます。
作業ログ.mdscreenshots
Markdownと画像を同じ作業フォルダの中へ置くことで、別の作業で撮った似た画面と混ざりにくくなります。記事を書く時も、対象フォルダを一つ見れば、その作業の記録と画像候補を追えます。
孤立画像は通常の作業フォルダへ無理に戻さず、_review/orphan-imagesに残しました。今の作業記録と、判断が必要な過去画像を同じ場所で扱わないためです。
作業を始める前に短いテンプレートを置く
ログは次の項目から始める形にしました。
# 作業タイトル
## 背景
## 目的
## なぜ必要なのか
## 前提条件
## 手順（GPTからコピペ）以前は、実行した手順から書き始めることが多く、あとで読むと「なぜこの設定を試したのか」が抜けていました。先に背景と目的だけでも書いておくと、操作の結果と判断を分けて残せます。
手順（GPTからコピペ）は、AIの提案をそのまま自分の判断として扱わないための区切りでもあります。提案された内容、実際に実行した内容、確認できた結果を同じものにしないようにしました。
スクリーンショットは作業の最後ではなく途中で結びつける
以前は画像を先に撮り、作業後にMarkdownへまとめて貼ろうとしていました。画像が増えるほど、どの場面だったかを思い出す作業が増えます。
新しい運用では、画像を作業フォルダのscreenshotsへ保存し、その場でログから参照します。必要なら画像の前後に、見るポイントと、その画像から確認できたことを書きます。
大事なのは、画面を撮った事実ではなく、その画像がどの判断を支えるのかです。認証情報、メールアドレス、AWSアカウントID、ARNなどが含まれる画面は、公開用の記事へ移す前に別途確認します。
Obsidianのログから記事へつなぐ
SAMEKORO LABの記事は、Markdown原本からサイト用HTMLとnote用Markdownを生成します。Obsidianの作業ログをそのまま公開するのではなく、次の順番で使います。
- 作業前の疑問と目的をログへ書く
- 実際の操作とスクリーンショットを作業単位で残す
- 確認できた結果と、確認できなかったことを分ける
- 公開できない情報を除き、記事として構成し直す
- HTMLとnote用Markdownを生成してリンクを検証する
この流れなら、記事のために経験を後付けするのではなく、作業時の記録から書けます。確認できない失敗や感情を補う必要もありません。
個人運用だから、続けられる量にした
企業の作業記録なら、変更申請、承認者、実施時刻、対象、ロールバック、証跡保管期間など、より多くの項目が必要です。
今回は自分一人で続ける個人環境なので、最初から項目を増やしすぎませんでした。背景、目的、必要性、前提、手順を入口にし、結果や判断は作業に合わせて追加します。
決めた形式を毎回使えることを優先しました。整理されたVaultを保つには、完璧なテンプレートより、作業開始時に迷わない小さな型のほうが合っています。
まとめ
664件の画像を整理したこと自体より、そのあと同じ状態へ戻らない運用を作れたことが今回の中心です。
作業ごとにMarkdownとscreenshotsをまとめ、実行前の目的から書き始め、画像をその場でログへ結びつけます。その記録を確認してから、サイト記事とnote用Markdownへつなぎます。
次回は、この流れの中でChatGPTとCodexへ何を任せ、人がどこを判断するかを整理します。