WIP — この記事は追記・更新される可能性があります。
ObsidianとNext.jsで実現する「1ファイル表裏デュアル執筆術」|%%コメントアウトと.gitignoreで機密を守る自衛ハック
#ブログ運用 · #Obsidian · #Design Ops · #Cursor · #セキュリティ · #Next.js · #gitignore
公開
更新
ObsidianとNext.jsで実現する「1ファイル表裏デュアル執筆術」|%%コメントアウトと.gitignoreで機密を守る自衛ハック
個人ブログや技術記事を書くとき、「現場で起きた生の体験や未確定のメモ、スクショ」 を手元に残しておきたいことってありませんか?
かといって、「自分用メモ(Obsidian)」と「公開用記事(.md)」で別々のファイルを作ると、二重管理になって更新が面倒になりがちです。
以前は Syncthing などでスマホとも同期していましたが、いまはスマホ同期をやめています。出先は思考の下書き、メインPCで完全体を整える——その割り切りが先に決まっていて、今回の構成にもつながっています。
そこで、Obsidianの %% コメントアウト構文と、このサイト(Next.js)の記事読み込み処理、そして .gitignore を組み合わせることで、「手元(Obsidian)では完全な一次情報メモ」「Web上(本番サイト)ではクリーンな公開記事」 を1ファイルで両立するワークフロー(Design Ops)を整理しました(^^)
執筆の道具まわりは Cursorで直接書く話 や Gemini×Cursor の執筆ワークフロー にも書いています。この記事は 「表と裏を1ファイルに同居させる自衛」 の話です。
課題:生の一次情報を残したいが、誤公開やHTML露出が怖い
ブログ記事を書く際、次のようなジレンマがありました。
- 生々しい気づきや背景(一次情報)は手元に書き留めておきたい
- しかし、通常のHTMLコメント
<!-- メモ -->だと、ビルド後のソースコード(HTML)にバッチリ残ってしまう - 万が一にも公開用ファイルから情報が漏洩するのは絶対に防ぎたい
- スマホまで同じ完全体を同期し続ける運用は、むしろノイズとリスクが増えがちだった
「手元でのみ参照でき、公開用の本文からは完全に削ぎ落とされる仕組み」を、このブログ用に入れています(2026年5月ごろに追加した処理です)。Syncthing を手放したあとは、PCローカル+必要なフォルダだけクラウドバックアップ に寄せています。
解決策1:%% コメントアウトを、記事読み込み時に除去する
Obsidianの標準コメントアウト記法である %% 〜 %% を使います。
---
title: 記事のタイトル
---
ここからは表側の本文です。
%%
■ 自分用の裏メモ(Obsidian上でのみ表示)
・この記事を書いた背景や未整理のアイデア
・あとで検証したい参考リンクなど
%%
ここが大事なところです。Next.js が自動で %% を消してくれるわけではありません。
このサイトでは、記事を読む lib/posts.ts の getPostBySlug で、本文に対して processObsidianComments を通しています。
/**
* - 本番: %% … %% を公開用本文から完全除去
* - 開発(next dev): PrivateNote コンポーネントへ変換
*/
function processObsidianComments(markdown: string): string {
// NODE_ENV === "development" なら <PrivateNote> 化、それ以外は除去
}
// getPostBySlug 内
let body = processObsidianComments(content);
つまり HTML 生成の前に、Markdown 本文の %% ブロックを処理しています。
- 本番(Vercel など): ブロックごと削除するので、画面にもソースにも残らない
- ローカル(
next dev): 琥珀色の 個人用メモ 枠(PrivateNote)で表示。%%も内部で同じコンポーネントに変換される
next dev での見え方はこんな感じです(サンプル表示)。

逆に言うと、この除去処理を通さない経路(生の .md をそのまま配信する等)では消えないので、「フレームワーク任せ」ではなく サイト側で明示的に扱う のがポイントです。
ちなみに以前は %% … %% を単純な正規表現で切っていたため、コメントの中に %% という文字があるとそこで閉じてしまい、続きが本文として漏れる ことがありました。いまは 単独行の %% を開始/終了 として扱い、さらに コードフェンス/インラインコードの中は触らない ようにしています(この記事の書き方サンプルが誤って個人用メモ枠にならないため)。
サンプルと本物のメモを混ぜたくないときは、MDX で明示的に書けます(見た目は同じ)。
<PrivateNote>
■ 自分用メモ
・本番では出ない/next dev だけ個人用メモ枠で見える
</PrivateNote>
執筆ルールとしても、「自分用メモは %% または <PrivateNote> に書いて md に残す/編集時も削除しない」と決めています。
解決策2:添付画像は .gitignore でGit管理外へ隔離
メモに貼り付けたいスクショや検証用画像など、「GitHubには絶対に上げたくないけれど、ローカルのObsidian上では参照したい」 という画像ファイルもあります。
これは、プロジェクト内の特定フォルダを .gitignore に指定することで解決します。
# ローカル専用の秘密画像(Obsidian 参照用。GitHub / デプロイには載せない)
public/secret-images/
こうしておけば、どれだけ git add . を実行しても、その配下の画像が GitHub へプッシュされる事故を防げます。
Obsidian上からは public/secret-images/ 配下の相対パスを指定しておけば、手元のエディタでノートを開いた時だけ画像が表示されます(本番の公開記事本文には、そもそも載せない運用)。
あわせて、Vault 設定の .obsidian/ も .gitignore 済みです。Syncthing はもう使っていませんが、過去の残骸(.stfolder など)が残っていてもリポジトリに混ざらないよう、除外ルールだけは残しています。
解決策3:Git管理外の画像は Google Drive で「そのフォルダだけ」バックアップ
.gitignore で GitHub から遮断した画像ファイルは、PCのディスクにしかない状態になります。万が一のPC故障や誤削除に備えて、バックアップラインを別に用意しておくと安心です。
ここで同期したいのはリポジトリ全体ではなく、public/secret-images/ だけ です。
パソコン版 Google Drive では、ミラーリング対象をフォルダ単位で選べるので、secret-images 単体を同期フォルダに指定しています(プロジェクト丸ごとの同期はしない)。
【ローカル環境(Mac/PC)】
└─ star-moti / public / secret-images / ← .gitignore で Git 追跡オフ
│ ← Google Drive も「このフォルダだけ」同期(クラウド保護)
└─ Obsidian(ローカル画面で画像プレビュー表示)
なお、Google Drive 同期の副産物(.driveupload など)や .DS_Store も .gitignore に入れておくと、リポジトリを綺麗に保てます。
運用のトレードオフ:特定PC限定の環境と、デバイスごとの役割分担
Syncthing でスマホまで完全同期していた頃と比べると、「完全体のメモ(画像含む)はメインPCでしか見られない」 割り切りが前提になります。
一見不便に思えるかもしれませんが、デバイスごとに役割を切り分けることで、むしろ快適になりました。
- スマホ・外出先:最小限のテキストメモや、AI(Gemini)との壁打ち・ブレインダンプに集中する(完全同期はしない)
- メインPC(ローカル環境):画像を含む完全体のメモやブログ記事として整理・清書する。秘密画像は
secret-images+ Drive で守る
「いつでもどこでも同じ環境で書く」ことに固執せず、出先での思考整理とメインPCでの清書作業を分けることで、セキュリティと作業効率のバランスが良くなりました(^^)
デバイス役割の話は Gemini×Cursor 執筆ワークフローのデバイス分担 ともつながります。
まとめ
%%/<PrivateNote>➔ 本番では公開用本文から蒸発/next devでは個人用メモ枠で確認可.gitignore➔public/secret-images/を Git 追跡外にし、GitHub 流出を遮断(Syncthing 残骸の除外も残置)- Google Drive ➔
secret-imagesフォルダだけ を同期してクラウドバックアップ - 割り切った運用 ➔ スマホ完全同期はやめて、出先は AI 壁打ち/PC で完全体メモ
「流出リスクを下げる」と「手元の一次情報を失わない」を両立させながら、1つの Markdown ファイルで表と裏の情報を一元管理できるようになりました(^^)
自城(ブログ)の運用環境を整える Design Ops の一環として、とても快適な執筆フローになったと感じています。
サイトの改修ログとしては、【ハブ】star-moti.com 改修ログまとめ にも残しておきます。
(本文 随時追記予定)