メモ運用再訪とブログの見た目刷新

knowledge

Posted May 6, 2026 By tkhm

メモ運用再訪とブログの見た目刷新

ゴールデンウィーク。長期連休ということで、日々の仕事から離れて何かを整理するのに良いタイミングだなと思い、重い腰を上げて個人メモやブログなどの整理をしたのでその話を書く。

メモ運用

この数年はObsidianが便利に感じていて、メモをマークダウンで取って、それをObisidian上で管理、デバイス間共有はObsidian SyncやiCloudのSync機能などを必要としている端末の状況に合わせて使うようにしている。

個人ナレッジベース、というと少しおこがましいけれど、要するにメモを残すのはやり方にかなり自由度があって、その時々の世間や自分自身のトレンドでやり方も変わるのだけど、その変わったトレンドにメモを追い付かせることができていない状態だったのを、ようやく整理できたのが今の状態。件数にして2000ファイルほど。1日4-6時間くらいを3日ほどかけてようやく整えることができた。

まず、メモは3世代の流れがあった。

世代	フォーマット	閲覧システム	デバイス間共有・バックアップ保存先	ベーススタイル
1	Markdown	GitBook	Git	DITA
2	Notes(Apple)	Notes(Apple)	iCloud	DITA/タスクシュート
3	Markdown	Obsidian	iCloud/Obsidian Sync	Zettelkasten

あえて整理してみるとこんな感じ。

少し長くなるが、各世代の話を簡単にしてみる。

第1世代

このときは技術的なメモなどを中心にマークダウンで取るようにしてみた。これをGitBookという、マークダウンファイルがあれば章立てされた本のようにブラウザで読める優れものがあった。（久しぶりにWebサイトを見てみたら今も続いていてすごいなあと感心した。）

この方法でメモを残した時、似たようなメモが複数生まれてしまい、管理にコストを感じるようになった。一方で、ファイルをあちこちに散らすと、閲覧するときには面倒になってしまう。

そんな悩みを抱えていたとき、DITAという文書の構造の持ち方や整理の方法について知った。あまり深入りしても仕方がないのだけど雑に書くと

1ファイル1トピック（＝情報の単位、3-5分くらいで読めるようなイメージかな）で整理
Concept（概念の説明とか）、Task（How to系）、References（その名の通りAPIの一覧とか）などのようなトピックのタイプを特定し、そのタイプごとに適した書き方をする
書き出したトピック間の順序や繋がりは、Mapと呼ばれる紐付けファイルによって実施

というお約束で書いていくというもの。¹これは例えばLinux向けとWindows向けでマニュアルを作るのにほとんど同じ情報を使うけど部分的には異なるとか、Web向けと印刷したマニュアル向けであるとか、といったときに文書の再利用性を高めるために考えられた仕組み。

例えば初めてハイブリッドアプリケーションフレームワークであるCordovaを触った、といったシーンを考えて、Cordovaってそもそも何？という話と、それを手元でどのようにビルドしてリリース可能にするのかという話をそれぞれ分けてメモするようなイメージ。ある程度明確に書きやすくて良かった。が、時間の経過とともに、ファイル数が増えてきたのと、ちょっとした発見をメモしたい、といったときの柔軟性に欠ける印象だった。結果、きちんとファイル化できていないものが積み上がってしまった。あと、複数端末で見る際に毎回Gitにコミットすることや、GitBookで見るためにGitBook自体を動かさないといけない（もしくはどこかにデプロイしてみれるようにするとか）ということが面倒に感じた。

第2世代

数年程度運用を続けて課題を感じていたところに、ちょうど自身に手描きでシステムのデザインのラフ画を描いて考えるというブームが来ていた。 iPadにApple Pencilで配置図を描くとか、APIの設計イメージを描くとかそういうの。モバイル端末でも気軽に自分のメモを見たい、メモを取ることにハードルを感じてしまってメモに残さずに忘れてしまうということを避けたい、もっと気軽に運用したい。そんな思いと、自身のブームとの兼ね合いから、MacやiPhoneに備え付けのNotesを使うようになった。

第1世代の時のフォルダ構成はほぼ維持しつつ、一件一葉というスタイルにはこだわりすぎず、同じカテゴリなら気楽にメモの追記するということを始めた。ただ、メモをしている時が急いた気持ちで、適切なメモファイルを探してそこに書く、という手間を惜しんでしまい結局メモされない、ということが運用開始時に見受けられた。

そのため、デイリーノートのようなものを作り、そこにTaskChuteをできたらいいなという気持ちも相まって、その日にやったことや学んだことを書き溜めることにした。これは正直、結構上手く回せた。スマホから見たいときも手軽で結構気に入った。

が、このNotesはApple純正アプリ。そしていわゆるWYSIWYGエディター。ブログに書き出すときに、対象のシステムが同じくWYSIWYGのときは良いのだけど、そうでないときには不便した。また、Syntax Highlightがなかったり、自身が書いた内容をターミナルから操作することも基本的には（あまり深く立ち入ってないけど）難しかったりというところで少しずつ不満が溜まっていった。また、AppleがNotesの仕様を大きく変えたり、あるいは自身がApple製品自体を使わなくなったりした場合でも問題なく使えるかという継続可能性の点も気になり出した。

第3世代

そんな経緯も経て、やってきたのが第3世代。第1世代の時のメモも、第2世代の時のメモも、無理やり特定のフォルダに持ち込んで同じフォルダ（Vault）で管理することにした。

Zettelkastenという古典的なアイデア・メモ等の整理整頓方法が気に入ったので

日々のメモとしてのFleeting
読書メモや講演メモなどを残すLiterature
ブログとして外に出すなど含めまとまった知識にしたPermanent

を中心に採用しつつ、一定の期間継続的な更新を続けることが意図されるものとして、Projectsという独自概念を持ち込んで運用をかれこれ5年ほど続けてきた。（このProjectsの下にIdeaとLearningがあり、Ideaは例えば電子工作などで自身が実現したいことなどが書いてあり部分的にはその進捗なども書いてある、Learningは例えばBazelでROS2を使う方法などが書いてある）

この第3世代のやり方は基本的にこれまでの流れの中で困った点に対処する形で進化させてきていることもあって、いい具合に定着し、それなりに運用しやすく回っている。過去のメモと、Fleetingを除いては。

まず過去のメモは、メモを検索で見返すときにメモの取り方の明らかに異なる、重複したような内容が引っ掛かるなどし、その中から適切なものを見つけ出すのに苦労していて、情報の価値を下げる要因になってしまっていた。

それからFleetingについては、第2世代の流れで気軽にメモを残し、それがDailyないしWeeklyの単位でメモファイルとして残ってはいるものの、そのファイルを更新し、捨てるないしどこかに書き溜めるという努力を怠ってしまった。その結果、見返す価値のない、コンテキストを失ったメモが大量にそこに残置されてしまった。

対処方法

基本的に第3世代として確立した方法を維持しつつも、過去の使用できない情報を整理することと、整理をサボってしまう自分に対して適切な切迫感を出す方法を考え次のような対処をした。

第1世代、第2世代のメモはLLMをサポートに使いながら、現行のフォルダ構造を読み取らせた上で、新規ファイルを作成・既存ファイルに追記・削除を実施した。これによりメモの件数は概ね2/3以下に集約できた。
- 新規・追記内容を流し見して、問題なければ続行
- 削除候補などを提示させ、その内容を流し見して問題なければ削除

それから新規のメモについては次のルールの運用を設計・開始することにした。

明らかに特定のトピックでファイル内の書くべき場所も特定できている＝Projects以下の当該特定ファイルに書き出し
明らかに特定のトピックだがファイル内の書くべき場所は特定できていない=Projects以下の当該特定ファイルに “WIP” セクションを作りそこに書き出し
トピックとしてどこに書くべきか特定ができていない・しない=Fleeting以下の当月メモファイルに書き出し
Fleeting以下の当月メモファイルには、現在WIPセクション以下に書いているものをDataviewプラグインで集約、毎月WIP状態のメモをレビューする

これは、本来何でもかんでもメモに残すべきとはされていないFleetingを誤った運用方法で扱った結果、書き残したメモが大量に残置されてしまったことに対する措置。

またDataviewでの集約は次のようにしている。なお、実際に使う際は”```dataviewjs” と書いたコードブロック内に貼り付ける。また、Enable JavaScript Queries有効化必須。

        
      
// 集約対象
const pages = dv.pages('"projects/learnings" or "projects/ideas"');
const wipPages = [];
for (const p of pages) {
  try {
    const content = await dv.io.load(p.file.path);
    if (content && /^## WIP\b/m.test(content)) {
      wipPages.push(p);
    }
  } catch (e) {}
}
wipPages.sort((a, b) => a.file.mtime - b.file.mtime);
dv.table(
  ["File", "最終更新", "Folder"],
  wipPages.map(p => [p.file.link, p.file.mtime, p.file.folder])
);

ブログ運用

ここで少し毛色が変わるのだけど、ZettelkastenのPermanentという箱の中に、ブログ記事化したものを格納している。ということは、当然ながら、自身のまとまった知識だったり経験だったりがそこにまとまっているというわけで、探すときにはその対象も当然検索したい。

一方で、ブログとしては技術コミュニティ向けの別サイトの技術記事と、ここでのそれ以外の一切との2種類があり、前者はマークダウン、後者は最近のものだけマークダウン、以前のものはブログサイト内にて保管という状況だった。後者については、Bloggerを使用していたものの、そもそもマークダウンで手元で書いたものをWYSIWYG形式でうまく見れるように貼り直す作業が毎度億劫に感じており、また画像ファイルなどは手動でアップロードしパスを見直す必要などがあった。

そこで、後者のブログ記事をすべてエクスポートし、マークダウン形式にし直した上で、Jekyllを使ってビルドしデプロイするという形に入れ替えた。ついでにあまり気に入っていなかったブログの見た目も少し整えた。（他人にはあまり共感されないことを理解しているが、前より好きな見た目になっており読みやすく気分がいい）

またどちらのブログについても、それぞれ別々のプレビューシステムを持っていた。そのため、

Permanent以下に記事を書く
Scriptで、記事公開用のリポジトリとSyncする（必要に応じて画像のパスなども見直す）
記事公開用のリポジトリ側でプレビューし問題なければPublishする

という流れを取ることにした。

それから、こだわりポイントとしては、移行後も同じURLで見れるようにパーマリンクを維持したということ。正直、古い記事のURLを維持することにはそれほど価値はないように思う。のだけど、同時に、昔見れたあの記事、が今はもう移転で見れない、ということがあちこちで当然に起きていて、それに対して僅かに寂しさを覚える。昔は、インターネットにあるものはずっと変わらずそこにあるものだと思っていたけれど、実際には変わらずにずっと見られることは結構尊いことなのだなと実感することがあり、さほどの労力を必要としないなら維持するようにしよう、と思ったのだった。

要するに

適当にメモとか残してたせいで価値ある記録にするのに努力が必要だったよ
Zettelkastenのやり方（＋アレンジ）が長く続いて定着してるよ
ブログの記事の管理方法やこのブログの見た目の変更も整理に合わせて対応できたよ

って話かな。 TL;DRとかって最初に書いてもいいんだけど。

過去の記事を見てみると、同じようにメモの取り方を変えた時期の記録もあって、変遷が透けて見えるのは面白いね。以前よりも見通しが良くなって書きやすくもなったので、もう少し手軽に書けるといいなあと思っている。また数年後の自分、もしくは誰かの何かの参考になると良いな。

おしまい。

詳しく知りたい場合は、”DITA Best Practices: A Roadmap for Writing, Editing, and Architecting in DITA”がおすすめ。私はこれで勉強した。 ↩︎