📑 Markdown TOC ジェネレーター
Markdown を貼り付けるだけで、見出し (h1〜h6) を抽出してネスト付き目次を自動生成。GitHub / GitLab スラグ生成、Markdown / HTML / プレーン出力、深さ制限、番号付きリストに対応。
🔒 プライバシーについて
- ・Markdown はブラウザ内のみで解析されます
- ・入力テキストは一切サーバーに送信されません
- ・登録・ログイン・課金は一切不要です
⚙ オプション
プレビュー (HTML レンダリング)
📖 つまずきやすいポイント
Markdown の見出しを読み取って目次を生成します。出力形式 (プレーン / スラグ / カスタム)、対象とする見出しレベル、番号付きリスト、h1 の除外を選べ、処理はブラウザ内で完結します。アンカーリンクの生成規則は、貼り付け先のプラットフォームごとに違います — ここで生成したリンクがそのまま動く保証はありません。とくに日本語の見出しは、環境によって扱いが大きく異なります。
| ケース | 何が起きるか | どうする |
|---|---|---|
| 目次のリンクをクリックしても飛ばない | 見出しから id を作る規則 (スラグ化) はプラットフォームごとに違います — 記号の削除、連続する空白の扱い、絵文字、そして日本語の扱いが最も分かれます。GitHub は日本語をそのまま id に使い、リンク側では URL エンコードされた形になりますが、環境によっては日本語を全部落として section-1 のような連番にするものもあります。さらに、同じ Markdown でも GitHub・GitLab・Qiita・Zenn・VitePress・Docusaurus でそれぞれ違う id が生成されます — つまり「どこに貼るか」を決めないと、正しいリンクは作れません。 |
貼り付け先で実際にクリックして確認してください — これが唯一確実な検証方法です。GitHub なら、見出しにマウスを乗せると左に鎖のアイコンが出るので、そこからコピーしたリンクが正解です。1 つ確認すれば規則が分かるので、残りは同じ変換をかければ済みます。そして、目次のリンクが動くかどうかは、公開後に必ず 1 回は全部クリックしてください — 特に長い記事では、リンク切れの目次は無いほうがましです (読者を無反応なリンクに導くのは、目次が無いより悪い体験です)。複数のプラットフォームに同じ文章を出すなら、目次のリンクは諦めてプレーンテキストの一覧にするという判断も現実的です。 |
| 同じ見出しが複数あるとリンクが 1 つ目にしか飛ばない | 「## まとめ」や「### 注意点」のような見出しは、1 つの記事に何度も出てきます。ほとんどのプラットフォームは、2 つ目以降の id に -1・-2 と連番を付けて衝突を避けますが、目次を生成する側がその規則を知らなければ、全部同じリンク先になります — 結果として3 つある「まとめ」のどれをクリックしても、最初のものに飛びます。連番の付け方も統一されておらず、-1 から始まる実装と -2 から始まる実装があります。読者から見ると「リンクは動くが、間違った場所に行く」ので、壊れていることに気付きにくいのが厄介です。 |
見出しを一意にしてください — 「まとめ」ではなく「認証まわりのまとめ」「パフォーマンスのまとめ」と書けば、リンクの問題が消えるだけでなく目次を眺めたときに内容が分かるようになります。つまりこれは技術的な回避策ではなく、文章の改善そのものです — 目次に同じ語が 3 回並んでいる時点で、読者にとっての価値は低くなっています。どうしても同じ見出しを使いたい場合は、HTML の <a id="..."> を手で埋め込んで、自分で id を管理してください — Markdown の中に生の HTML を書けるプラットフォームであれば動きます (ただし Slack など、HTML を解釈しない環境では無効です)。 |
| 目次が長すぎて逆に読みにくい | h4 や h5 まで含めると、目次だけで画面 1 つ分を占めます。読者が最初に目にするのが30 行の箇条書きだと、本文にたどり着く前に離脱します。目次の目的は「全体像を一目で把握させること」なので、一目で把握できない目次は目的を果たしていません。加えて、目次の長さは見出し構造そのものの問題を映しています — 20 項目を超えるということは、1 つの記事に詰め込みすぎているか、見出しを段落の代わりに使っているかのどちらかです。 | 目次に載せるのは h2 と h3 までにしてください — このツールの「最小 / 最大レベル」で指定できます。h1 は記事タイトルなので「h1 を除外」を有効にしてください (本文中に h1 が 2 つあるのは、そもそも HTML の構造として正しくありません)。それでも 20 項目を超えるなら、記事を分割することを検討してください — 目次が長いという症状は、記事が扱いきれない範囲に広がっているという診断結果です。読者が目次を見て「自分に必要な節はどれか」を 5 秒で判断できるかを基準にすると、適切な粒度が決まります。 |
そもそも目次を本文に埋め込む必要があるかを確認してください。GitHub は 2021 年からREADME の右上のボタンで見出しのアウトラインを自動表示しますし、Zenn・Qiita・多くの静的サイトジェネレータ (VitePress・Docusaurus・Astro) も見出しから目次を自動生成して、スクロールに追随する形で表示します。つまり目次を手で書く必要があるのは、それを持たない環境だけです。埋め込む場合の代償も理解しておいてください — 見出しを 1 つ変えるたびに目次を手で直すことになり、そして必ず忘れます。腐った目次は、読者を存在しない節に案内するので無いより悪くなります。継続的に更新する文書なら、CI で目次を再生成する仕組みを入れるか、いっそ入れないという判断をしてください — markdown-toc のようなツールを pre-commit フックで走らせれば、手作業は消えます。「一度書いて放置される目次」が最悪の選択です。
📖 使い方
-
1
Markdown を貼り付け左側のテキストエリアに Markdown 全文をペースト。
-
2
オプションを調整出力形式 (Markdown / HTML / プレーン)、スラグ、最小・最大レベル、番号付きを選択。
-
3
コピー / ダウンロード生成された目次をクリップボードにコピー、または .md / .html / .txt としてダウンロード。
❓ よくある質問
GitHub のアンカー (#anchor) と同じになりますか?
入力した Markdown はサーバーに送信されますか?
コードブロック内の # は無視されますか?
🔗 関連ツール
🐛 このツールで問題が発生しましたか?
完全無料・登録不要。再現手順だけでも結構です。届いたご報告は運営者に直接届き、修正の参考にします。
ご報告ありがとうございます!
運営者に届きました。改善の参考にさせていただきます。