SNS 向け Markdown 画像化：サイズ・テーマ・繰り返せるワークフロー
長い技術記事がうまくいかない理由の多くは、読者が文字の壁をスクロールさせられることにあります。その中で一番効く部分を画像にすると、その主張にもう一度チャンスが生まれます。読めて、保存できて、共有できる 1 枚のカードになるからです。問題は、毎回デザインツールを開かずに、これを安定してこなす方法です。
SNS 用のカードセットは Markdown to Cardsから始められます。この記事では編集可能な Markdown を原稿として、文章量、幅、テーマ、代替テキスト、繰り返せる公開手順を説明します。スクリプト描画は API 文書を参照してください。
画像が効くのは、メッセージが 1 画面に収まるとき、テキスト投稿では潰れてしまう書式が効くとき、単独のファイルとして共有したいときです。コード、表、チェックリストが一番わかりやすい例で、画像の中では読めるままなのに、プレーンテキストの投稿では読みにくくなります。
テキストのままが良いのは、内容が長いとき、後で編集するとき、検索やコピーができる必要があるときです。記事全体を 1 枚の画像にするのはやめましょう。もう一度見る価値のある部分だけを画像にして、本文へリンクを張ります。
元のメッセージは Markdown で持っておき、チャンネルごとに画像を手描きするのではなく、バリエーションをレンダリングします。1 つのソースから、横長の LinkedIn カード、正方形の投稿、縦に短い更新告知を、キャンバスとテーマを変えるだけで作れます。
これが効くのは、もう一方のやり方がまるでスケールしないからです。画像ファイルを 3 つ別々に編集するということは、打ち間違いのチャンスが 3 回あるということで、6 週間後に一文だけ直したくなったら 3 つとも探して作り直すことになります。ソースが Markdown なら、1 行直して再エクスポートするだけです。
そのソースは、デザインツールの中ではなく、他のコンテンツの隣に置きます。ドキュメントと同じリポジトリに短い .md ファイルを 1 つ置けば十分で、バージョン履歴もついてきます。先月のカードはなぜ違う書き方だったのかと聞かれたとき、答えはコミットログにあります。
だからこのワークフローは小さな Markdown ブロックから始まります。メッセージは短く、見出しは 1 つ、組版はレンダラーに任せます。
この Markdown は、実際の内容を入れる前に組版を確認できるくらい小さくしてあります。
# Deployment complete
Environment: **production**
- [x] Database migrated
- [x] Health checks passing
- [ ] Post-deploy review
`status: healthy`
このデモを Markdown to Cardsに貼り付けて確認します。完了した 2 項目と未完了のレビューはサンプルデータで、実際のデプロイ報告ではありません。文章を置き換える前に、見出しの階層、リストの間隔、インラインコードのコントラストを確認してください。
最初のレンダリングでは、実際の内容ではなく、あえて小さくしたこういうサンプルを使ってください。太字、タスクリスト、インラインコードという、一番よく崩れる要素を一通り試せて、しかも余白やコントラストの問題が一目でわかるくらい短く収まります。サンプルが思いどおりに出たら、設定はそのままで中身だけ本番の内容に差し替えます。
出力の形を決めるパラメーターは 3 つあります。幅、品質、出力フォーマットです。
width は 200〜2560 ピクセルの論理的な描画幅です。quality は 1〜3 のデバイス倍率で、JPEG の圧縮品質ではありません。上げると出力画素が増えますが、長いカードや読みにくい文字は改善しません。高さは内容で決まるため、幅だけでは投稿先の縦横比を保証できません。
編集の出発点として論理幅 1200 を試し、出力の実寸と投稿画面のプレビューを確認します。これはサンプル設定で、共通のプラットフォーム規格ではありません。幅広の表は簡略化し、長文は分割します。
format は PNG、JPEG、WebP、PDF に対応します。コードや図をくっきり保つのは PNG なので、SNS カードにはこれを使います。
明るいエディタの中だけでなく、フィードの中で十分なコントラストが出るテーマを選びます。ライトテーマは白い画面のアプリでよく読め、ダークテーマはダークモードのフィードで目を引きます。テーマはカード全体に効き、コードスタイルはフェンス付きコードブロックだけに効きます。
この 2 つは独立した設定で、そこを間違えやすいところです。ダークテーマに明るいコードスタイルを合わせると、真ん中だけ明るい長方形がくり抜かれたようなカードになります。テーマを決めてからコードスタイルを選び、コードブロックがカードの中に馴染んでいるか、それとも浮いているかを確かめてください。
テーマはエディタが前回使ったものに任せず、名前でメモやスクリプトに固定します。1 枚だけ違うパレットでレンダリングされた瞬間にカードのまとまりは崩れますが、この種のズレは、画像がフィードで並ぶまで誰も気づきません。
投稿前に、実際に表示される幅でレンダリング結果を確認します。プレビューペインでは問題なく見えるカードが、フィードで縮小されると読みにくくなることがあります。
Markdown to Cardsを開き、1 枚に 1 つの要点となるよう原稿を整理して、全カードを確認します。各カードの最初と最後を見て、見出しだけが前のカードに残り、説明が次へ移る場合は修正します。幅、テーマ、コードスタイルは揃えます。
実用的な分け方は、1 枚につき見出し 1 つ、要点 1 つ、短いチェックリスト 1 つです。テーマと幅はスレッド全体で揃え、ひと続きのセットに見えるようにします。
1 つの文を 2 枚にまたがらせたくなっても、そこは我慢します。スレッドは 1 枚ずつ拡散されるので、話の途中から始まるカードは、単独で流れてきたときに壊れて見えます。1 枚に収まりきらない考えがあるなら、それはカードではなくリンク先の記事に置くべきだというサインです。
たいていのスレッドでは 3 枚から 5 枚が現実的な範囲です。それを超えると、読者は記事を読むのと同じ労力を、拾い読みできる利点なしで払うことになり、画像がその場所を占める意味がなくなります。
代替テキストはアクセシビリティにも検索にも効きます。画像に何が写っているかを、含まれている文字も含めて説明します。ただしキャプション全体を繰り返す必要はありません。
代替テキストは、画像がそこに無いつもりで書きます。カードに "Deployment complete — all checks passing" とあるなら、一般の読者向けの代替テキストは「ダークテーマの Markdown カード。デプロイのチェックリストが表示され、2 項目が完了、1 項目が未対応」といった具合です。「チェックリストの画像」より役に立ち、Markdown を丸写しするより冗長になりません。
代替テキストの設定と制限は投稿先や投稿形式で異なります。下の公式ヘルプを参照し、実際の投稿画面で説明が保存されることを確認します。重要な手順やリンクは、アクセス可能な投稿本文にも記載してください。
代替テキストは、上限いっぱいまで書かず短く抑えます。文字数を使い切った説明が役に立つわけではなく、処理しづらいうえ、支援技術の経路によっては途中で切られることもあります。その画像から何がわかるのかを 1、2 文で伝えて、そこで止めます。
大量に画像を作るようになると、同じパラメーターがそのままスクリプトになります。Markdown to Image API は Bearer トークン付きの POST リクエストを受け付け、URL モードでは 24 時間保持される一時 URL を、binary モードでは画像データそのものを返します。結果は早めにダウンロードしてください。一時 URL は永続ストレージではありません。
最小限のリクエストでは、エディタで選んだのと同じ width、quality、theme を指定します。
{
"markdown": "# Weekly update\n\n- Faster exports\n- Clearer reports\n- One repeatable workflow",
"format": "png",
"width": 1200,
"quality": 2,
"theme": "github-dark",
"mode": "url"
}
cURL、Node.js、Python、n8n を扱う完全な連携ガイドはこちらです：Markdown to Image API: Generate PNGs with cURL, Node.js, Python, and n8n。
- 実際に表示される幅で画像を確認する。
- メッセージが 1 画面に収まり、行が切れていないか確認する。
- ライトテーマとダークテーマの両方でコントラストを確認する。
- キャプションの繰り返しではなく、画像を説明する代替テキストを付ける。
- テーマと幅がセットの他のカードと揃っているか確認する。
- 一番長い行と表が、横方向に窮屈にならずに収まるか確認する。
- Markdown ソースをバージョン管理に置く。
- 内容が変わったら再エクスポートする。ビットマップの中の文字を直接いじらない。
PNG の中の文字を直接編集すると、Markdown 原稿と画像が分かれてしまいます。原稿を修正して再出力し、次の改訂も同じ正しい文章から始めてください。
サイズはどう選びますか？ 論理幅 1200 などから始め、出力寸法と投稿先のプレビューを確認します。プリセットに保存する前に、その投稿形式の現在の要件を調べてください。
長い記事を 1 枚の画像にできますか？ できますが、たいていはやめたほうがよいです。1 枚につき 1 論点のカードスレッドに分けてください。
代替テキストは何文字にしますか？ カードの要点が伝わる長さにし、投稿先の現在の制限と保存された説明を確認します。重要な内容は画像以外にもテキストで残してください。
MarkdownToImage に API はありますか？ あります。Bearer トークン付きの POST リクエストを受け付け、PNG、JPEG、WebP、PDF の出力に対応します。API ドキュメントと連携ガイドを参照してください。
カードの見た目を揃えるには？ セット全体で同じテーマ、コードスタイル、幅を使い、Markdown ソースをバージョン管理に置いてください。
公開前に現在の案内を確認します。X の画像説明と LinkedIn の画像仕様を参照してください。描画パラメーターは API 文書に記載されています。
プラットフォームの画像仕様や代替テキストの上限は予告なく変わります。具体的な数値をテンプレートや自動化パイプラインに埋め込む前に、上記 2 つのリンクを改めて確認してください。
1 つの Markdown ソースを、そのまま投稿できる画像にしてみてください：MarkdownToImage を開く、次の更新内容を貼り付けて、幅 1200 ピクセルのカードとしてエクスポートします。