書いたものを自分の手元に置く ― Markdown から記事を出す小さな出版ツールを作りました
シリーズ・第 1 回 — 「個人で出版ツールを作って配るまで」（全 5 回予定）。各回は単独でも読めますが、まとめて辿るなら シリーズの記事一覧 からどうぞ。今回は全体像と前提の共有で、個々の設計判断は次回以降に取り上げます。
書いたものは、どこに残るでしょうか。
普段、文章を書く場所の多くは、誰かのプラットフォームの上です。読んでもらいやすい一方で、記事の住所（URL）も、見た目も、読者との接点も、その場所の仕様に委ねることになります。サービスが方針を変えたり、畳んだりすれば、書いたものもそれに従うしかありません。
それ自体が悪いわけではないのですが、「長く手元に残しておきたい文章」については、もう少し自分の側に置いておきたい。そう思ったのが、小さな出版ツール crofty を作りはじめたきっかけでした。
このシリーズでは、その crofty を作って配るまでに考えたこと・つまずいたことを、テーマごとに分けて残していきます。今回はその土台として、「何をしたかったのか」と「全体の流れ」をまとめます。
何をしたかったか
やりたかったことは、ひとことで言うと「自分のコンテンツを所有したまま出版する」ことでした。具体的には、次の 4 つです。
- 自分のドメインで出す — 記事の住所（URL）を、自分の側に持っておく
- Markdown で書く — プレーンテキストなら、どこにでも移せて、長く読める
- 静的サイトにする — データベースを持たず表示が速い。仕組みを入れ替えても記事はそのまま
- エッジから配信する — 世界中どこからでも、軽く開ける
平たく言えば、「書いたものが、それを作る道具より長生きする」状態にしておきたかった、ということです。
なぜ既存のツールそのままではないのか
ここで正直な疑問があります。静的サイトを作る道具（いわゆる SSG）はすでに優秀なものが揃っていて、たとえば Hugo はとても速くて安定しています。実際、crofty も内部では Hugo を使っています。では、なぜわざわざ別の道具を作ったのか。
理由は、「出版」は書くこと自体だけでは終わらないからです。実際にやってみると、書く前後にこまごました工程がついてきます。
- 記事を書く土台を用意する（最初のセットアップ）
- 体裁が整っているかを確かめる
- 出力が、配信先で正しく開ける形になっているかを確かめる
- 配信する
- 後から見た目や設定を見直す
これらを、その都度ばらばらの手順でやるのではなく、コマンド 1 つずつの薄い手順にまとめておきたかった。crofty は、Hugo を置き換えるものではなく、その上に薄くかぶせた小さな道具です。土台は素の Hugo のままなので、いつでも crofty を外して、ただの Hugo プロジェクトとして扱えます。この「いつでも自分の手元に戻せる」感覚も、最初から大事にしていました。
なお、「道具を変えても記事は自分のもの」をどう保証するかは、それ自体で 1 本の記事になるテーマなので、次回にゆずります。
全体の流れ
実際の流れは、とてもシンプルです。Markdown を書いて、組み立てて、配る。ほぼそれだけです。
登場するコマンドも、役割で並べるとこれだけです。
| コマンド | 役割 |
|---|---|
crofty init |
記事を書く土台を用意する |
crofty build |
Markdown を静的サイト（dist）に変換する |
crofty validate |
記事の体裁（frontmatter など）を点検する |
crofty doctor |
出力が、配信先で正しく開ける形か点検する |
crofty deploy |
エッジ（Cloudflare Pages）へ配信する |
crofty theme |
見た目を調整する |
新しいランタイムやデータベースは増えません。書いたものは dist という静的なファイルの集まりになり、それをそのまま配るだけ。だから速いですし、仕組みを途中で見直しても、記事そのものには手を入れずに済みます。
操作はすべて、端末（ターミナル）から打つ素朴なコマンドです。人が手で打ってもいいですし、手順がはっきりしているぶん、自動化から呼び出すのにも向いています。
このブログ自体も、これで出しています
少し説得力のために付け加えると、いま読んでいただいているこのブログ自体が crofty で作られています。
- 図は、ビルド時に SVG として焼き込み（この記事の流れ図もそうです）
- コードの着色も、ビルド時に処理
- 読み込む JavaScript は最小限
つまり、表示の速さを保ったまま、図・表・コードといった表現は普通に使える、という状態です。自分で日々使ってみて、不便なところを直す。その繰り返しで形にしてきました。
これから
次回以降は、crofty を作るなかでの個々の判断を、1 本につき 1 テーマで掘り下げていきます。だいたい次のような並びを考えています。
- 出力を契約する — 道具を配ったあとも、互換性をどこで守るか
- JavaScript を増やさずに多言語化する — 言語の出し分けを、どの層でやるか
- brew や scoop で配る — 個人で作ったツールを、手元から配布するまで
- コマンドの設計 — 人にも、自動化にも読みやすい「いまの状態と次の一手」
どれも crofty に限らず、「小さな道具を作って配る」ときに通る道だと思います。同じように「書いたものを自分の手元に持っておきたい」と感じている方の、ささやかな手がかりになれば嬉しいです。
次の記事：出力を契約する →