[🛠] NaverブログのPDFバックアップをGitHub Pagesへ移した話

✨ GPT-5.5の要約 　

NaverブログのPDFバックアップ18個から記事173本と画像1521枚を抽出し、既存のGitHub Pagesブログ構造の中へ移植し直した記録。

Naverブログにためていた記事を、もう一度GitHub Pagesブログへ持ってきたくなった。

正確に言うと、単にバックアップファイルをどこかに保管したかったわけではなかった。すでに書いた記事があった。日付もあり、画像もあり、カテゴリもあり、その時期に考えていたこともあった。けれどその記録は、Naverブログという別の家に置かれたままだった。

結局、僕はこのブログを自分の記録の中心として立て直したかった。GitHub Pagesブログはシンプルだけれど、自分が望む構造で記録を積み上げられる。

ただ、今回は新しい記事をひとつ書く話ではなかった。

NaverブログのPDFバックアップ18個を受け取り、その中に入っている記事と画像を、既存のJekyllブログ構造の中へ移し直す必要があった。

まず条件を決めた

最初から目標は単純だった。

Naverブログのバックアップを取り込む。ただし、このブログの中で最初から存在していた記事のように読める状態にしたかった。

条件をいくつか決めた。

• PDF 18個の中の記事を漏れなく抽出する。
• 記事の日付と元リンクを残す。
• 画像は既存ブログの慣例に合わせて assets/images/YYYY-MM/YYYY-MM-DD/ の下に置く。
• 今日の一日 シリーズ番号は既存記事とつながるようにする。
• グルメ、旅行、AI、開発のような記事は 今日の一日 番号に混ぜない。
• 既存カテゴリへ無理に押し込まず、必要なら新しいカテゴリを作る。
• PDFで壊れた文をそのまま持ち込まない。
• 成果物はビルド可能なJekyll記事であること。

言葉にすると普通だ。ところが実際にやってみると、これはただのファイルコピーではなかった。

記録を別のシステムへ引っ越しさせる作業だった。

PDFのテキストだけを信じてはいけなかった

最初は、PDFからテキストと画像を抜き出せば終わると思っていた。

実際に記事は抽出できた。画像も抽出できた。けれど問題は本文だった。PDFから持ってきた文が、ところどころ変な位置で切れていた。

たとえばこんな感じだった。

その巨大な嵐を僕ひとりで一日も早く制御しようとする、そんな過剰な意欲そのものが僕を無力にさせる一番大きな原因で

あるからだ。

ひとつの文が段落のように割れ、単語が分断され、読むリズムが崩れていた。

この状態で移せばバックアップにはなるかもしれない。でも記事は壊れる。人が読む文章というより、PDFから剥がれ落ちた痕跡に近かった。

だから方針を変えた。

PDFは記事一覧と画像抽出の出発点として使い、本文はNaverの元HTMLをもう一度読んで復元した。Naverエディタの段落、リスト、引用の流れを追いながら、Markdown本文として作り直した。

そこでようやく、記事が記事らしく戻ってきた。

画像は既存ブログの方式に合わせた

画像も重要だった。

Naverの記事には画像が多かった。特に旅行記事やグルメ記事では、画像が本文そのものに近かった。テキストだけを移すと、半分だけの記録になってしまう。

最終的に取り込んだ画像は1521枚だった。

画像パスは既存ブログの慣例に合わせた。

assets/images/2025-09/2025-09-09/naver-004-001.jpg

年-月、日付、そしてNaver import番号が入ったファイル名で整理した。こうしておくと、後からファイルを見ても、どの日付のどのimport画像なのか追跡できる。

本文では通常のMarkdown画像構文をそのまま使った。

![naver-004-001](/assets/images/2025-09/2025-09-09/naver-004-001.jpg)

静的ブログでは、こういう単純さが大事だ。ビルドが終われば、ただのファイルになる。別の画像サーバーや外部リンクに頼らなくてもいい。

カテゴリは分け直した

いちばん慎重になった部分はカテゴリだった。

最初はNaverの記事をざっくり diary の下へ入れればいいのではないかと思った。けれどそうすると、後で記事を探しにくくなるし、ブログの構造もぼやける。

だから新しいカテゴリを作った。

diary life
diary thought
diary relationship
diary restaurant
diary travel

既存の diary ai、diary dev、diary religion も一緒に使った。読書・マインドセット系の記事は reading mindset、アプリ紹介記事は tip app、ブログ構築の記録は devlog github-pages-blog 配下に入れた。

カテゴリを新しく作る作業は、ファイルをひとつ移せば終わるものではない。

カテゴリページが必要だ。サイドバーのナビゲーションも必要だ。アーカイブで見えるカテゴリラベルとリンクも合わせる必要がある。タイトル前のアイコンも、既存ブログの慣例と揃えなければならない。

グルメ記事は [🍽️]、AI記事は [🤖]、開発記事は [🧑‍💻]、旅行記事は [🧳] のように整理した。

些細に見えるけれど、こういう部分が乱れると、取り込んだ記事がずっと外から来た異物のように見えてしまう。

今日の一日 番号は別に守った

いちばん混乱しやすかったのは 今日の一日 番号だった。

Naverにあった 今日の認証 記事は、実質的にはDaily Reviewだった。だから既存ブログの 今日の一日 シリーズとつながる必要があった。

逆に、グルメ、旅行、AI、読書の記事は、日付が近くても 今日の一日 シリーズではない。これらの記事まで番号に混ぜると、シリーズそのものが壊れる。

最終結果はこう合わせた。

今日の一日 #1 ~ #200

番号は1番から200番までつながり、抜けや重複はなかった。Daily Reviewではない記事に 今日の一日 # 番号が入らないことも確認した。

これは単なる数字の整理ではなかった。

シリーズの正体を守る作業だった。

検証が作業の半分だった

こういう移行作業で怖いのは、見た目にはそれらしく見えるのに、どこかがひとつずつずれていることだ。

画像ファイルがないのにMarkdown参照だけが残っているかもしれない。カテゴリのfront matterと実際のフォルダが食い違うかもしれない。タイトルアイコンが既存の慣例と違うかもしれない。PDFで壊れた ? アイコンが本文にそのまま残っているかもしれない。

だから検証を別に回した。

確認した内容はだいたいこんな感じだ。

import記事: 173本
画像参照: 1521件
画像不足: 0件
表示される単独?の残り: 0件
「今日の一日」番号: #1 ~ #200
非Daily Review番号の混入: 0件
カテゴリフォルダ不一致: 0件

最後にはJekyllビルドも回した。

bundle exec jekyll build

静的ブログは、ビルドが通って初めて安心できる。MarkdownひとつのLiquid構文が壊れても、サイト全体が止まる可能性があるからだ。

結果

結果的に、NaverブログのPDFバックアップ18個から記事173本と画像1521枚をこのブログへ移した。

でも数字より大事なものがある。

この作業は単純なバックアップではなかった。散らばった記録を、もう一度ひとつのシステムの中へ復元する作業だった。

PDF、Naver HTML、Jekyll front matter、カテゴリページ、サイドバーナビゲーション、画像パス、シリーズ番号が全部合っていなければならなかった。ひとつでも間違えれば、記録の文脈が崩れる。

他の人から見れば、ただ記事を移しただけに見えるかもしれない。でも僕にとっては、記録システムをもう一度整備する作業だった。

単にたくさんの記事を持ってきたわけではない。自分が積み上げてきた記録をどう構造化するか、壊れたデータをどう復旧するか、既存システムの慣例の中にどう着地させるかを、改めて決める作業だった。

記録は書くことも大事だけれど、失わないようにつかまえ直すことも大事だ。

今回の作業は、そちらに近かった。