SNS 向け Markdown 画像化：サイズ・テーマ・繰り返せるワークフロー
長い技術記事がうまくいかない理由の多くは、読者が文字の壁をスクロールさせられることにあります。その中で一番効く部分を画像にすると、その主張にもう一度チャンスが生まれます。読めて、保存できて、共有できる 1 枚のカードになるからです。問題は、毎回デザインツールを開かずに、これを安定してこなす方法です。
このガイドのワークフローは 1 つの Markdown ソースから始まり、そのまま投稿できる画像を作ります。キャンバスを決め、読みやすいテーマを選び、代替テキストを書き、次の投稿でも同じ手順を使い回します。例で使うのは MarkdownToImage で、パラメーターは 2026 年 8 月 3 日に 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`
これを MarkdownToImage に貼り、幅 1200 ピクセルのキャンバスを選んでエクスポートします。ここで出たカードが、他のすべてのバリエーションの基準になります。
最初のレンダリングでは、実際の内容ではなく、あえて小さくしたこういうサンプルを使ってください。太字、タスクリスト、インラインコードという、一番よく崩れる要素を一通り試せて、しかも余白やコントラストの問題が一目でわかるくらい短く収まります。サンプルが思いどおりに出たら、設定はそのままで中身だけ本番の内容に差し替えます。
出力の形を決めるパラメーターは 3 つあります。幅、品質、出力フォーマットです。
width はレンダリング幅をピクセルで指定し、200 から 2560、既定値は 800 です。quality はデバイススケールファクターで 1.0 から 3.0、既定値は 2.0 です。実際のピクセル高さは内容の縦横比に従うので、幅 1200 ピクセルのカードならたいていの SNS フィードで文字がくっきり出ます。
幅 1200 ピクセルは安全な出発点です。高精細ディスプレイでも十分くっきりする幅がありながら、1 行が長くなりすぎない狭さでもあります。リンク付きの LinkedIn 投稿については、1.91:1（およそ 1200 x 627 ピクセル）と、幅 200 ピクセル超がプラットフォーム側の推奨です。元の Markdown は幅を抑えて書くと、レンダラーが横に広すぎる表を作らずに済みます。
format は PNG、JPEG、WebP、PDF に対応します。コードや図をくっきり保つのは PNG なので、SNS カードにはこれを使います。
明るいエディタの中だけでなく、フィードの中で十分なコントラストが出るテーマを選びます。ライトテーマは白い画面のアプリでよく読め、ダークテーマはダークモードのフィードで目を引きます。テーマはカード全体に効き、コードスタイルはフェンス付きコードブロックだけに効きます。
この 2 つは独立した設定で、そこを間違えやすいところです。ダークテーマに明るいコードスタイルを合わせると、真ん中だけ明るい長方形がくり抜かれたようなカードになります。テーマを決めてからコードスタイルを選び、コードブロックがカードの中に馴染んでいるか、それとも浮いているかを確かめてください。
テーマはエディタが前回使ったものに任せず、名前でメモやスクリプトに固定します。1 枚だけ違うパレットでレンダリングされた瞬間にカードのまとまりは崩れますが、この種のズレは、画像がフィードで並ぶまで誰も気づきません。
投稿前に、実際に表示される幅でレンダリング結果を確認します。プレビューペインでは問題なく見えるカードが、フィードで縮小されると読みにくくなることがあります。
長い投稿はカードのスレッドに分け、1 枚につき 1 つの論点にします。読む人はカードをばらばらの順序で目にするので、どのカードも単独で成立している必要があります。
実用的な分け方は、1 枚につき見出し 1 つ、要点 1 つ、短いチェックリスト 1 つです。テーマと幅はスレッド全体で揃え、ひと続きのセットに見えるようにします。
1 つの文を 2 枚にまたがらせたくなっても、そこは我慢します。スレッドは 1 枚ずつ拡散されるので、話の途中から始まるカードは、単独で流れてきたときに壊れて見えます。1 枚に収まりきらない考えがあるなら、それはカードではなくリンク先の記事に置くべきだというサインです。
たいていのスレッドでは 3 枚から 5 枚が現実的な範囲です。それを超えると、読者は記事を読むのと同じ労力を、拾い読みできる利点なしで払うことになり、画像がその場所を占める意味がなくなります。
代替テキストはアクセシビリティにも検索にも効きます。画像に何が写っているかを、含まれている文字も含めて説明します。ただしキャプション全体を繰り返す必要はありません。
代替テキストは、画像がそこに無いつもりで書きます。カードに "Deployment complete — all checks passing" とあるなら、一般の読者向けの代替テキストは「ダークテーマの Markdown カード。デプロイのチェックリストが表示され、2 項目が完了、1 項目が未対応」といった具合です。「チェックリストの画像」より役に立ち、Markdown を丸写しするより冗長になりません。
入力できる代替テキストの量にはプラットフォームごとの上限があります。X（Twitter）では、画像の説明欄が 1 画像あたり最大 1,000 文字を受け付けます。この数字は X の公開ヘルプドキュメントに基づくものですが、ヘルプページは 2026 年 8 月 3 日時点で機械可読ではなかったため、テンプレートに組み込む前に現在の上限を確認してください。LinkedIn のヘルプには、通常の画像投稿に対する代替テキストの上限は明記されていません。
代替テキストは、上限いっぱいまで書かず短く抑えます。文字数を使い切った説明が役に立つわけではなく、処理しづらいうえ、支援技術の経路によっては途中で切られることもあります。その画像から何がわかるのかを 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 ソースは分岐してしまい、以後の修正のたびにズレが積み重なります。再エクスポートは数秒で終わり、ソースを唯一の正にしておけます。
SNS 画像の最適なサイズは？ 唯一の正解はありませんが、幅 1200 ピクセルのキャンバスが実用的な既定値です。高精細ディスプレイでもくっきりし、1 行の長さも読みやすく収まります。リンク付きの LinkedIn 投稿については、1.91:1（およそ 1200 x 627 ピクセル）が推奨されています。
長い記事を 1 枚の画像にできますか？ できますが、たいていはやめたほうがよいです。1 枚につき 1 論点のカードスレッドに分けてください。
代替テキストはどれだけ入れられますか？ X（Twitter）では、X の公開ヘルプドキュメントによれば画像の説明欄が 1 画像あたり最大 1,000 文字を受け付けます。依存する前に現在の上限を確認してください。
MarkdownToImage に API はありますか？ あります。Bearer トークン付きの POST リクエストを受け付け、PNG、JPEG、WebP、PDF の出力に対応します。API ドキュメントと連携ガイドを参照してください。
カードの見た目を揃えるには？ セット全体で同じテーマ、コードスタイル、幅を使い、Markdown ソースをバージョン管理に置いてください。
プラットフォームの情報は 2026 年 8 月 3 日に確認しました：X の画像説明と LinkedIn のカスタム画像仕様。MarkdownToImage のパラメーターは API ドキュメントと一致しています。
プラットフォームの画像仕様や代替テキストの上限は予告なく変わります。具体的な数値をテンプレートや自動化パイプラインに埋め込む前に、上記 2 つのリンクを改めて確認してください。
1 つの Markdown ソースを、そのまま投稿できる画像にしてみてください：MarkdownToImage を開く、次の更新内容を貼り付けて、幅 1200 ピクセルのカードとしてエクスポートします。