このブログはGitHubで書いています。流れとしては、下書きをGitHub Actionsで生成し、下書き更新ではてなブログのプレビューを更新、PRマージではてなブログへ投稿されます。

今回はGitHubと連動したはてなブログ投稿の仕組みを書きます。

おすすめ
なぜGitHubとはてなブログを連動させるのか
はてなブログとGitHubの連動方法の変遷
- push-to-hatenablogをテンプレートに採用(2022年～)
- HatenaBlog Workflows Boilerplateをテンプレートに採用(2025年～)
textlintを使った記事校正の調整
GitHubで書くメリット
GitHubで書くデメリット
まとめ

なぜGitHubとはてなブログを連動させるのか

そもそもはてなブログは記事管理ができるのになぜGitHubで記事を書くのかという疑問ではないでしょうか。はてなブログは記事管理ができるので、記事を書く場所としては十分です。

記事の公開先と保持を分けたい

私がGitHubと連動させようと思ったきっかけはZennとGitHub Pagesです。これらはGitHubで記事を保持して、公開する場を自分で選択していくことができます。

それに対して自分は記事自体をはてなブログに保持してしまっているため、記事の公開先を将来変えたくなった時に困ります。もともとWordPressからはてなブログに引っ越してきたこともあり、記事の公開先を将来変えたくなる動機があります。ブログを引越す時、記事をGitHubで管理していると記事の移行がとても楽です。はてなブログの記事ははてなブログの管理画面からエクスポートできますが、初めからGitHubで管理すれば記事の移行はデプロイ変更にフォーカスできます。

記事の履歴を取りたい

また、GitHubで管理していると記事のバックアップや履歴も取れるので安心です。

はてなブログとGitHubの連動方法の変遷

はてなブログとGitHubの連動方法は2種類試してきました。

push-to-hatenablogをテンプレートに採用(2022年～)

はてなブログで直接書いていた記事をGitHubから連動するように変えたのは次の記事がきっかけでした。

push-to-hatenablogを使ってはてなブログ記事をGit管理してみた

ほかにも方法があるかと2022年当時探したのですが、blogsyncを使った方法しかなかったので整備されている方法に乗りました。

記事を更新する

この記事更新方法は次のフローです。

# 下書きの作成

1. GitHubでIssueを作成 > `記事の追加用テンプレート`を選択し、記事本文の`path: `に`yyyy/MM/dd/適当なID`を指定してIssueを作成します
2. IssueをcloseするとActionsで`_draft`パス以下に下書き記事が作成されます

# 下書き記事の編集

- 作成された下書きをVS Codeで編集する。
- プルリクエストを作成するとをtextlintで校正されます
- プルリクエストをマージすると下書きがはてなブログに同期されます
- はてなブログの下書きを見て、記事を調整するか決めます

# 下書き記事の公開

- 記事を公開する前に`_draft/`から`entry/`ディレクトリに移動します
- 下書き記事の`Draft: true`行を削除し、プルリクエストを作成。mainブランチにマージすると記事がはてなブログで公開されます

# 既存記事を修正する場合

- 修正ブランチを作成し、mainブランチにマージすると修正がはてなブログに反映されます

はてなブログで直接書いていた時は校正がなかったので、公開してからちょくちょく修正することを繰り返していました。GitHubで記事を書くにあたりtextlintを導入して、PR時にGitHub Actionsで校正し始めました。

問題点

GitHubをいつも使っているので、やり方も大したことないしモチベーション変わらず書けるだろうと考えていたのですが甘かったです。いざやってみると記事を書きたくなくなっていたのですが、振り返ると原因はめんどくささが爆発していました。

記事を書くときにIssue作ることを思い出せない
Issueのpath:に何を入力すればいいか思い出せない。READMEに書いても直感的じゃない
Issueのpath:のIDをどうやって決めるかわからない。適当はむしろわからなくなる
下書きをはてなブログに反映させるのにいちいちPRを作ってマージするのが面倒
公開時に_draftから_entryに移動するのがめんどうで、先に移動するとdraftが混じってどこに行ったか探す羽目になる

どれも大したことないことなのですが、これが積み重なって記事を書くのがストレスになっていました。一度やる気をなくすと2,3カ月放置し、久々に記事を書こうとするとまたやり方を忘れていて、下書きまで作ったところでやる気をなくすという悪循環に陥りました。

問題点はわかっていましたが忙しさを言い訳に放置していました。

HatenaBlog Workflows Boilerplateをテンプレートに採用(2025年～)

2024年中にはてなブログ公式ブログを見かけていたのですが、いったん放置していました。2025年に毎日記事書く気力がわいたので、ようやく手を付けました。幸いにもGitHubからの同期方法はblogsyncから変わっていなかったので、設定調整はほぼありませんでした。

この記事更新方法は次のフローです。

# 下書きの作成

1. Actionsから  `create draft`を選択し、`Title`に記事タイトルを設定、`Branch: main`に対して実行します
2. 作成した下書きを含むプルリクエストが作成されます

# 下書き記事の編集

- 手順「下書きの作成」にて作成したプルリクエスト上で記事を編集します
- はてなブログでプレビューできるようにするため、下書き記事に限りプッシュされた時点ではてなブログに同期されます
- 記事の編集画面のURLは、プルリクエストに記載されています

# 下書き記事の公開

- 下書き記事の`Draft: true`行を削除し、プルリクエストをmainブランチにマージすると記事がはてなブログで公開されます
- 記事を公開すると、下書き記事は下書き記事用ディレクトリ`draft_entries`から公開記事用`entries`ディレクトリに移管されます

# 既存記事を修正する場合

- 修正ブランチを作成し、mainブランチにマージすると修正がはてなブログに反映されます

このフローは、以前めんどく感じていた諸々を解消しています。

記事を書くときにGitHub Actionsから適当なタイトルをつけるだけなので単純

下書きPRを更新するとはてなブログに下書き同期されて、プレビューURLもPRに記載されるので公開まで調整が楽

下書きPRをマージするとdraft_entriesから公開記事用entriesディレクトリに移動するPRを自動作成される

textlintを使った記事校正の調整

はてなブログの更新テンプレート修正に合わせてtextlintの使い方を調整しました。

textlintを2019年まで適用する

過去の記事が多すぎてtextlintする気がなくなり、過去の記事を修正するまで新しく書きたくないという悪循環ループになっていました。そこで2019年までの記事についてtextlintの校正を終えました。¹

幸い2018年以前の記事を参照する機会は少ないので、これで「textlintしないといけない」という強迫観念がなくなりました。

textlintをサクッと使う

これまでtsuyoshicho/action-textlint@v3を使ってPRにtextlintのコメントもつけていましたが、PRのコメントが爆発したときにやる気をなくします。

      - name: textlint-github-check
        uses: tsuyoshicho/action-textlint@v3
        with:
          github_token: ${{ secrets.github_token }}
          reporter: github-check
          textlint_flags: "./entries/guitarrapc-tech.hatenablog.com/entry/${{ matrix.year }}/**/*.md"
      - name: textlint-github-pr-review
        uses: tsuyoshicho/action-textlint@v3
        with:
          github_token: ${{ secrets.github_token }}
          reporter: github-pr-review
          textlint_flags: "./entries/guitarrapc-tech.hatenablog.com/entry/${{ matrix.year }}/**/*.md"

VSCodeで自動的にtextlintがかかるようにしてtextlintのエラーを書いていて即修正できるようにしました。また、PRではtextlintが落ちたかどうかだけ判断するようにしました。²

      - name: textlint
        run: |
          for year in 2019 2020 2021 2022 2023 2024 2025; do
            echo "::group::textlint for ${year}"
            npm run "lint${year}"
            echo "::endgroup::"
          done

PRで駆動するめんどくささがあるので、GitHubのAuto Mergeを併用しています。記事自体の推敲が終わったが些細な文言調整だけすることがあります。こんな時はtextlintが通ったら³自動マージして公開します。

GitHubで書くメリット

はてなブログで記事を書いているとやりにくく、GitHubで記事を書くとやりやすいことがあります。

複数記事をまとめて調整する

はてなブログで記事管理していると一個一個の記事を開いては調整、更新する必要があります。GitHubで記事を書くと複数記事を修正したPRを立ててマージするだけで一気に記事を修正できます。

記事の数が増えれば増えるほど効果的です。例えば、いろんな記事フォーマットを試したくなって過去記事も修正したくなったときでも最小限の手間で修正できます。

記事を戻す

はてなブログには履歴がありません。このため記事を戻してくても戻すことは難しいです。GitHubで管理していると、過去記事が履歴に残っているため戻すのが簡単です。

CIを挟める

文書、難しくないですか。私は文書を書くのが得意じゃないので、CIを挟んで文書の校正を自動化しています。ローカルのVSCodeでも校正できるのでCIは念のため、ですが効果的です。

はてなブログ機能をやめる動機

はてなブログは画像をドラッグ&ドロップでアップロードできます。カードプレビューも特殊記法で簡単にできます。はてなブログの機能は便利ですが、はてなブログで公開しない将来を考えるとはてなブログ機能は減らしたいものです。

GitHubで記事を書く場合VSCodeプレビューで見た目99％を決めるので、はてなブログの機能は使わない矯正ギプスになっています。

GitHubで書くデメリット

GitHubで記事を書くデメリットもあります。

気分で記事を書くにはめんどくさい

以前よりは楽になりましたが、記事を書く気分になって記事を書き始めるまで1m程度かかるハードルは高いです。はてなブログで書いているときは、管理画面から記事を書き始めるまでワンクリックなので大きな違いです。

画像

画像がめんどくさいです。今は割り切ってGitHub Issueに画像をあげてリンクを張っていますがよくないです。GitHub上に画像を置くのもめんどくさいのでどうしたものか。画像を配置すること自体がめんどくさい。

まとめ

はてなブログ公式から、GitHubとはてなブログの連携方法が公開されたのは本当に良いタイミングでした。そして、自分のやる気はめんどくさいに左右されるのも改めて実感しました。めんどくさい駆動ブログです。

2018年以前はいったん見ないふりです↩
PRコメント多すぎになるのはよくない↩
PR Status Checkにtextlintを指定している↩

tech.guitarrapc.cóm

Technical updates

GitHubとはてなブログを連動させる

おすすめ