はじめに
今回の記事の内容
こんにちは、@Takayoshi_maです。技術に携わっている方であればQiitaやZenn、そしてはてなブログなどのプラットフォームを利用して、情報発信している方も多いかと思います。人によってはこれら多くのブログプラットフォームを跨いで使い分けしてる方もおられるのではないかと思います。 そこで今日は、それぞれのブログプラットフォームの管理方法について、現状公式などからどのような仕組みが用意されているのかについて調査してみました。
記事にした動機
- テックブログとして、はてな・Qiita・Zennを全て利用しているが、いまいち使い分けできていないので、これを機会に各社どういったサービスを提供しているのかを調査する
- 自分の書いた記事を掘り返して調査する際に一々、webから探しに行くのが手間すぎる
- 変更履歴をきちんと残しておきたい
- 記事の検索性を高めたい。エディタからならすぐ辿れる
- GitHub Copilotが使えないとブログすら書きたくない
はてな
2023年10月現在、はてな公式から以下のようなBoilerplateのベータ版がリリースされているのを発見しました。まだベータ版ということで今後少しずつ機能が追加されていくようです。
上記のボイラープレートですが、大元のワークフローを繋ぎ合わせたものになっており処理のほとんどはこちらのリポジトリに記載されているようです。
（完全に余談ですが、こちらのプロジェクトはおそらく始まったばかり？ということもあり、先日一部ワークフローについて issue & PR を上げたところマージしていただけました）
はてなBoilerplate 概要
従来から存在していた（らしい）blogsyncを利用したワークフローを公式が用意してくれています。なおblogsync自体は非常にシンプルで使い勝手良さそうなコマンドですが、今回はその紹介は割愛して一旦こちらのテンプレートの話をしていきます。
ちなみに、自分も個人用のはてなブログをレポジトリ管理始めてみました。
はてなBoilerplate 感想
企業(チーム)でブログを管理している人向けに細かなワークフローが多く用意されている
これははてなブログならではだと思いました。QiitaやZennと違い、はてなは企業のテックブログとして採用されているケースも多い気がしています。おそらくそれを意識してだと思いますが、細かなワークフローがデフォルトで数多く用意されていました。 どのようなワークフローが用意されているかは、こちらをご参照ください。
今の所の想定フローは以下のような流れになります。(2023/10時点、公式情報より抜粋)
- 下書きを作成する
- 下書き記事をプルリクエスト上で編集する
- 適宜レビューなどを行い、通れば次の公開手順に進む
- 下書き記事を公開する
下書き記事がリポジトリ同期されてしまうのを防げる
この特徴は、はてなブログだけでした。確かに誰にも見られたくない未公開記事がGitHubに上がってしまうと困る時もあります。そういう意味でも、はてなブログは企業ブログとしての執筆サポートを意識して作っているのかなあと思いました。
その他感想
公式からもある通り、まだリリースされた直後ということで画像の自動投稿機能や、ローカルでのプレビュー機能などはありません。ただ他のプラットフォーム異なるユニークな思想が垣間見れて面白いなと思いました。今後のアップデートにさらに期待です！
Qiita
Qiita公式が出しているQiita CLI、およびryokat3さんが開発していたSync Qiitaの両方を触ってみました。Sync Qiita自体は昔から使っていて、Qiita CLIはこのテックブログ執筆に合わせて使いはじめた感じです。
以下にざっと感想を述べていきます。
Qiita CLI概要
2023年8月、Qiita公式からQiita CLIがリリースされたようです。今までは後述のQiita Syncを使ってましたが、これを機に公式へ乗り換えを検討してみたところです。
Qiita CLI感想
セットアップが比較的楽
Qiitaトークンの発行、secretsへの登録、プロジェクトの初期化くらいなもので比較的簡単に導入可能です。
記事のプレビューが可能
コマンド一つで記事のプレビューが可能です。しかもUIがシンプルで見やすいです！！
npx qiita preview
過去記事も簡単に同期可能
プレビューを一度するだけで過去記事も自動的に同期されます。
投稿が気楽
リポジトリにpushするだけでOKです。一応qiita CLIを使ってコマンドで投稿や編集も可能です。
その他
マークダウンのファイル名については記事IDと紐づいているため、変更はできません。またファイルの配置に関してはpublic/直下に固定されます。後述しますが、これはZenn CLIと似ている仕様です。（Qiita CLIはおそらくZenn CLIを意識して作っているのか、非常に似ている面が多かったです。）
また、画像ファイルのレポジトリ管理機能はなく、Qiitaへの画像アップロードは以下からダイレクトにアップロードして、そのリンクを記事内に埋め込む形になります。
https://qiita.com/settings/uploading_images
Qiita Sync概要
使い方はこちらのリポジトリを参照ください。
Qiita Sync感想
ファイル名やディレクトリ管理に融通がきく
こちらが最大の特徴だと思います。確かに指定したディレクトリ直下にしか記事がないと限定されると、事故は起こりづらい一方、記事数が増えてくるとみづらくなります。またファイル名がarticle_idなどの意味のない文字列だった場合、なおさら目的の記事を探しづらいです。（そのためのローカルプレビュー機能なんでしょうが） 一方、このQiita syncだとそこら辺を自由に設定できるようにしてるので、そこはいい点だなと思いました。
画像の管理がしやすい
記事内にはる画像を同じリポジトリ内で管理できます！これは便利！
定期的な同期チェックが可能
お互いを同期させるワークフローだけでなく、定期的に同期が正しく行えているかどうかのヘルスチェックを行います。 もし、webから編集してしまっていてレポジトリに反映されていない時などは、手動で同期ワークフローを実行すればOKでした。
その他
ryokat3さんのワークフローをそのまま実行すると、リポジトリ直下に記事が同期され、後でそれを自分でリネームしたり、好きなディレクトリに移動するのですが、何かと不便なのでarticles/yyyy/ディレクトリを自動作成し、そちらへ移動するようワークフローを自分で修正して、使ってました。以下のような感じです。
name: Qiita Sync on: push: branches: - main workflow_dispatch: jobs: qiita_sync_check: name: Run qiita-sync sync runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v2 - name: Set up Python uses: actions/setup-python@v2 with: python-version: '3.9' - name: Install qiita-sync run: | python -m pip install qiita-sync - name: Run qiita-sync run: | qiita_sync sync . env: QIITA_ACCESS_TOKEN: ${{ secrets.QIITA_ACCESS_TOKEN }} - name: Organize MD files by year run: | for file in *.md; do # ファイル名が yyyy-mm-dd の形式を持っているかチェック if [[ ! "$file" =~ ^[0-9]{4}-[0-9]{2}-[0-9]{2}.*\.md$ ]]; then echo "Skipping non-matching file: $file" continue fi year=$(echo "$file" | grep -oP '^\d{4}') # 年の取得に失敗した場合はスキップ if [[ -z "$year" ]]; then echo "Warning: Failed to extract year from filename $file" continue fi if [ ! -d "articles/$year" ]; then mkdir -p "articles/$year" fi # 移動先に同名のファイルが存在する場合はスキップ if [[ -e "articles/$year/$file" ]]; then echo "Warning: File $file already exists in articles/$year/. Skipping..." continue fi mv "$file" "articles/$year/" done - name: Git run: | find . -name '*.md' -not -path './.*' | xargs git add if ! git diff --staged --exit-code --quiet then git config user.name github-actions git config user.email github-actions@github.com find . -name '*.md' -not -path './.*' | xargs git add git commit -m "updated by qiita-sync" git push fi
その他感想
シンプルで使いやすい点、それとファイル名やディレクトリ管理が比較的自由なのがいい点かなと思います。ただ公式のように、プレビュー画面を開けないので非公開記事としてpushして都度都度確認するみたいなプロセスが発生する可能性はあります。
Zenn
概要
Zennに関しては、公式から出ているZenn CLIをそのまま利用するのが一番楽そうでした。使用方法などは以下を参照ください。
セットアップや使用方法などは公式に譲ります。割とすぐに導入が可能です。自分も現状Zennはリポジトリ管理しています。
使用感としては先述のQiita CLIと似ていますが、すぐに気づいた点として以下の2点でした。
- リポジトリ内で直接画像の管理を行うことが可能
- Webからは一切更新できない
- 過去記事の同期は半手動
## 感想 まだ使い始めたばかりですが、以下の点に満足しています。
セットアップが楽
GitHub Actionsを使い始める際に必要となってきそうなsecretesの管理や、tokenの発行が必要ありません。すぐに使い始めることが可能で非常に良いなと感じました。多分導入に関しては今まで紹介してきたどの仕組みよりも楽です。
画像の管理がしやすい
Zenn CLIでは画像ファイルのリポジトリ管理が可能です。
上の記事を読んでもらえればやり方はすぐわかるかと思います。個人的に/images ディレクトリの中の構造に制限はありませんが、拡張子だけはチェック対象となります。という点が非常にいいなと思いました。シンプルさと自由さを両立しているなと感じました。（個人的に記事ファイルもそうやってサブディレクトリ管理できると最高だったのですが）
# 以下公式より抜粋
# 画像ファイルはリポジトリ直下の /images ディレクトリに配置します。
# /images ディレクトリの中の構造に制限はありませんが、拡張子だけはチェック対象となります。
.
├─ articles
│ └── example-article-1.md
└─ images
├── example-image1.png
└── example-article-1
└─ image1.png
# 画像は、記事の本文や、本のチャプターの本文から参照することができます。
# 正しい指定方法
# 誤った指定方法
プレビューが便利
先述のQiita CLI同様、こちらもコマンド一つでプレビューが可能です。
npx zenn preview
その他
CLI導入以前の過去記事については、一応公式から以下のようにmarkdownファイルをエクスポートしてくる機能があるので、そちらをダウンロードして手動で移す形になります。また記事マークダウンのファイル名については記事ID(Zennではslugと呼ばれる)と紐づいているため、変更はできません。またファイルの配置に関してはarticles/直下に固定されます。また、一度リポジトリ管理を始めると、その設定を解除しない限りwebから直接記事を編集したり投稿したりすることができなくなります。（結構ストリクト）
まとめ
一旦まとめると以下のようになりました。webからの編集を可能にするかどうかは意見が分かれるところですが、ストリクトにすることでコンフリクトを避けることができる一方、急遽削除しなければならないことになった場合に不都合が生じる可能性もあると思うので、その辺は運用方法にもよるかなと思います。
| Qiita CLI | Qiita Sync | Zenn | はてな | |
|---|---|---|---|---|
| セットアップ | ○ | ○ | ◎ | ○ |
| 投稿の手軽さ | ◎ | ○ | ◎ | △ |
| ローカルでのプレビュー | ◎ | × | ◎ | これから? |
| 画像の管理 | ○ | ◎ | ◎ | これから? |
| 過去記事の同期 | ◎ | ◎ | ○ | ◎ |
| ファイル名・ディレクトリ見やすさ | △ | ◎ | △ | ○ |
| Webからの編集 | ○ | ○ | × | ○ |
| 公式がリリース | ◎ | × | ◎ | ◎ |
| ワークフロー充実度 | ○ | ○ | ○ | ◎ |
最後に
株式会社ABEJAでは採用に力を入れています！技術情報の発信好きな方ぜひご応募ください！
