ハクソク

世界を動かす技術を、日本語で。

Org Modeの構文は、テキストに使用する最も合理的なマークアップ言語の一つです。

135日前原文(karl-voit.at)

概要

  • 本記事は 軽量マークアップ言語 について解説
  • Org mode構文 の利点を他言語と比較しながら紹介
  • Markdownの 標準化問題 や多様な方言への批判
  • Org mode構文の 直感性と一貫性 を強調
  • 見出し・リスト・テーブル等の 具体例と比較 を提示

Org mode構文が最良の軽量マークアップ言語である理由

  • 本記事は 軽量マークアップ言語 全般と、その中での Org mode構文 の優位性を論じる内容
  • Emacs 以外のエディタ（vim, Atom, Notepad++など）でも Org mode構文 は利用可能
  • Org mode構文は 見出し・リスト・強調表示 など、一般的な文書構造を直感的に表現可能
  • 例：
    • * 見出し
    • ** サブ見出し
    • *太字* /斜体/ _下線_ +取り消し線+ =等幅=
    • [[http://Karl-Voit.at][リンク説明]] や http://Karl-Voit.at
    • - リスト項目 1. 番号付きリスト
    • - [ ] 未完了タスク - [X] 完了タスク
    • : ソースコードなどの整形済みテキスト
    • コードブロック例： 
      #+BEGIN_SRC python
myresult = 42 * 23
print('Hello Europe! ' + str(myresult))
#+END_SRC
  • Org modeの テーブル構文 はやや複雑だが、整形を無視しても動作する柔軟性
    • 例： 
      | カラム1 | カラム2 | カラム3 |
|---------+---------+---------|
| 42      | foo     | bar     |
| 23      | baz     | abcdefg |
|---------+---------+---------|
| 65      |         |         |
  • 直感的な記法 で、初心者でもチートシート不要で使い始められる

Markdownの標準化問題と方言の混乱

  • Markdownは 多くの方言 が存在し、ツールやサービスごとに仕様が異なる
    • 例：Original Markdown, Markdown Extra, MultiMarkdown, GitHub Flavored Markdown, CommonMark, Djot, MySTなど
  • 新しい機能（脚注、テーブル等）の追加で 非互換性 が発生
  • Markdownの「標準」とされるものが複数存在し、 移植性・互換性の低下 を招く
  • ファイル拡張子も .md, .mkdn, .markdown, .txt などバラバラ
  • 結果として ユーザビリティ地獄 に陥りやすい

Org mode構文の一貫性と標準化

  • Org mode構文は Emacs Org-mode を基準にし、他ツールでのサブセットも 元仕様に忠実
  • これにより データ移行時の情報損失が少ない
  • 2025年2月時点で 正式な構文定義 はないが、実装基準が明確
  • 拡張子は一貫して .org で統一
  • どのツールでも 同じ記法 で解釈可能

見出し・リスト・定義リストの比較

  • 見出し記法の種類
    • プレフィックス型（例：* 見出し Org mode, # Heading Markdown）
    • プレ&ポストフィックス型（例：== Heading ==）
    • アンダーライン型（例：Heading 1\n========= AsciiDoc, reStructuredText）
  • Org modeは プレフィックス型 で、階層が明確で覚えやすい
  • アンダーライン型やプレ&ポストフィックス型は 可読性や一貫性に欠ける ため混乱しやすい
  • リスト記法も言語ごとに複数存在し、 MarkdownやAsciiDocでは混在・混乱 しやすい
  • 定義リストの例（AsciiDoc）：
    • Term 1:: Definition 1
    • Term 2.1;; Definition 2.1
    • 階層やインデントが複雑で、 視認性や記憶性が低い

テーブル・リンク記法の比較

  • AsciiDoc等では 複雑なテーブル記法 や多機能を提供するが、 記憶・手入力が困難
  • Org modeは 基本的なテーブル記法 を提供し、手軽に利用可能
  • リンク記法も Org modeは一貫してシンプル
    • [[URL][説明]]やURLのみでOK

結論

  • Org mode構文は 直感的・一貫性・拡張性 に優れ、他の軽量マークアップ言語よりも 多くのユースケースに最適
  • Markdownなどの 方言乱立や標準化問題 に悩まされることなく、 安心して長期利用できる構文
  • Emacsユーザー以外にも 幅広く推奨可能 な軽量マークアップ言語

Hackerたちの意見

Orgフォーマットは結構直感的だよね（マークダウンもそうだけど）。でも、Orgの本当の力はorg-modeとEmacs全体にあるんだ。PIMとして使ったり、ドキュメントを書くのにサクッと使えたり、ノートを取るのにも便利だし、Emacsユーザーにとってはほぼ自動的にできるキー操作もあるしね。これがOrgが輝く理由だと思う。Emacs以外で単なるマークダウンフォーマットとしての価値はあまり感じないな。

└

Emacsの外でのOrgの価値は、マークダウンが広く採用されていれば持っている価値と同じだと思う。Voit'sの投稿は、Orgの構文がマークダウンが現在やっていることをすべてこなせる能力があることを強く主張していて、マークダウンよりも一貫性があって簡潔だと。だから、もっと広く採用されることを推奨してるんだ。技術の世界では、最初に良いフォーマットが勝つとは限らないし、勝たないこともあるけど、私たちは提唱することができるよね！

最近、マークダウンをGeminiの.gmi/gemtextフォーマットに置き換え始めたよ。機能が少ないマークダウンみたいな感じ。シンプルさが気に入ってるし、カスタムツールが解析するのもめっちゃ楽。インラインフォーマットはなくて、ATXヘッダーは3レベルだけ（#は付かない）、箇条書きはアスタリスクだけでダッシュは使わないし、隣接する非空白行をマージしない（だから段落ごとに1行を期待する）、トリプルバックティックの囲まれたプレフォーマットテキストエリアだけをサポートしてる。リンクは必ず独立した行に書かれて、=>の後に続いてオプションで代替テキストが付く。俺のgemtextパーサーは70行くらいで、マークダウンに必要な95%くらいの機能をカバーしてると思う。

└

自分だけかと思ってた。ヘッダーやリンクがあるテキストを持つのに、気を散らすものがないのがいいよね。ただ一つの不満は、行の改行を一部のマークダウンのバリアントみたいに扱うところで、各行が一つの段落になってしまうこと。俺は改行は単なる空白として扱って、段落を終えるのにはダブルブレークを使う方が好きなんだ。例えばPandocのマークダウンフォーマットみたいに（これが俺がマークダウンをレンダリングするときにいつもそれを使う理由の一つ）。

Orgには自分の構文をエスケープする仕組みがあるのかな？前に調べたときは、this（アスタリスクを保持するためには）を入力するにはゼロ幅スペース（U+200B）を挿入しなきゃいけなかったんだ。マークダウンだと、*this*って感じでエスケープすればいいのに。

└

コメントを編集したの？最初はどうやってそれをエスケープしたのか分からなかったけど、今はバックスラッシュが見えるよ。org-modeのドキュメントでもゼロ幅スペースを使うことを推奨してるみたいだね。https://orgmode.org/manual/Escape-Character.html 俺はorg-modeが主にそのレンダリング出力についてではないと思ってる。ほとんどのユーザーは、俺みたいに、さまざまなorg-modeドキュメントに何時間も費やして、基本的には生のマークアップを見つめてるんだ。Emacsのorg-modeは、リンクのターゲットを隠すなど、テキストの表示方法にほんの少しだけ変更を加えるだけだから、出力を見ることはほとんどない。俺はorgドキュメントの1%未満をエクスポートするから、フォーマットがどう見えるかはあまり気にしない。org-mode自体が機能するためにマークアップが正しくあればいい（リンクがたどれるとか、セクションが折りたためるとか）。エクスポートしたいドキュメントにはゼロ幅スペースみたいな回避策を使うことを想像できるけど、出力でorg-modeのマークアップがどう見えるかにこだわる必要はあまりないと思う。少なくとも俺にとっては、マークアップをエスケープすることを心配するのは気が散るし、ノイズを増やすだけだと思う。生のマークアップはどうせ読むからね。でも、何か良いエスケープ方法があれば悪くないと思う。ちなみに、非orgコンテンツの行全体を使うときに使えるそのままのブロックもあるし、もちろんsrc-blocksもある。でも、それは明らかにエスケープが役立つすべてのケースをカバーしているわけじゃないね。

└

その構文をエスケープする意味って何なの？最上位では、ただの任意にネストされたリストじゃん。

└

そうそう、エスケープは面倒だよね。「エスケープキャラクター」方式に加えて、以下の方法も使ってるよ（他のコメント者が指摘したように公式に文書化されてる）：インラインエスケープにはチルダブロック ~ ~ ... を使ってる。これでエクスポート時にモノスペース（コードフォーマット）でタイプセットされるから、通常はそれが欲しいものだよね。シンボルを明確にするために。非コードのテキストブロックには「リテラル例」 https://orgmode.org/manual/Literal-Examples.html これもエクスポート時にモノスペースでタイプセットされるよ。特別なシンボルにはLaTeX風の構文 https://orgmode.org/manual/Special-Symbols.html

もちろん。左側通行は運転するのに合理的な側面の一つだけど、みんなが右側通行の国ではそれを受け入れるのがいいよね。左側通行にも同じくらいの利点があるけど、続けることにこだわるべきじゃない。マークダウンもテキスト用の合理的なマークアップ言語の一つで、十分なシェアを得てるから、軽量マークアップのデフォルト選択として使うべきだと思う。org-modeがどれだけ合理的でもね。

└

org-modeにMarkdownを簡単に埋め込めるから、"十分なシェアを持つ"ものを逃す必要もないよね。* Orgにmdブロックを使って #+begin_src markdown ..... #+end_src たしかにMarkdownは勝者かもしれないけど、org-modeがあるのにそれを選ぶのは、両手を背中に縛って足だけで真剣なことをしようとするようなもんだよ。

└

これは好みの問題だよね？LaTeXとTypstみたいなもんだ。自分にとって一番合う環境を作ればいいんだよ。

└

他のフォーマットの人気に応じて、自分のプライベートファイルのマークアップ形式を選べって言ってるの？あなたの言いたいことがよくわからない。org-modeを使ってる人に、それを使うなって言ってるの？

└

Markdownは（主観的に）プレーンテキストの時にOrgより見た目がいいと思う。ポストフィックスのヘッダーやダッシュリストは解析するのが面倒だけど、視覚的にセクションを区別できるからね。対照的にOrgはアスタリスクの海みたいだ。（でも、/italic/の構文にはちょっとワクワクするけど…）

└

これは生成AIが出る前に私が考えてたアドバイスだね。今はちょっと自信がない。実は、私はzim-wikiの構文にすごく慣れてるから、それを使い始めたんだ。で、「動かす」ことが、たくさんの小さなスクリプトを使って他のものとより良く連携させることができるおかげで、桁違いに簡単になってきてる。これがちょっと逆の意見に思えるかもしれないけど、「市場シェアはもはや重要じゃない。あなた自身が一番合うものを使うべきだ。そうすれば翻訳が桁違いに楽になる」という考えに頼ることは合理的だと思う。

└

みんなが使ってるものに合わせるべきだって言ってるなら、なんでMicrosoft Wordフォーマットを使わないの？

└

ほんとそれ。orgで文書を書いたら、誰かのMarkdownファイルにぶつかってまだ入院中だよ。

└

誰もこの話題を出さなかったのが意外だな。左側通行のメリットって何だろう？操作系が利き手に対してどうなってるかとか、安全性の向上とか、特定のシチュエーションでの視界の良さとか？アメリカの郵便配達員がLLVを運転してるけど、彼らは両方の世界の「いいとこ取り」なのか「悪いとこ取り」なのか、考えちゃうな！こういうことを考えるのが好きなんだよね。

└

それでもBBCode系のことを応援してる自分がいる...

俺は'16年にEvernoteから移行してorg-mode（その結果Emacsも）を使い始めたんだ。今ではプロジェクト、タスク、知識管理のために使ってて、ファイルサイズは15MBを超えるものもあるよ。それでもまだ大好きだ。最初はヘッダーだけで始めたけど、もっと何かが欲しいと思ったときには、いつもすぐに手に入った。使いやすいし、めちゃくちゃパワフルだよ。両方の特性を兼ね備えたものは他に思いつかないな。

└

ファイルのサイズが15MBを超えるものもある。ワードカウントは約300万？（約60冊分の小説だね！）

└

2年くらい前からorg-modeを使い始めて、ヘッダーやフォーマット、ドキュメント間のリンク、コードセクションなどの基本機能を使って文書を書いてるけど、どのパワー機能に時間をかける価値があるのかまだわからないんだ。あなたの経験から、どの追加機能を掘り下げるべきだと思う？

└

PDFや画像、HTML/リッチテキストのスニペットはどう扱ってる？Evernoteはそれら全部をサポートしてたから聞いてみたんだ。あのアプリを使い続ける理由はそれなんだけど、開くたびにちょっと恥ずかしい気持ちになる。

私の知る限り、org-modeには仕様がないんだよね。未だに。数十年経っても。唯一の仕様は一つの実装だけ。それが多分、他のほとんどがサポートしてない理由だと思う。CommonMarkはその点、非常に広くサポートされていて、どれも一緒にうまく動くよ。私はCommonMarkにこだわるつもり。

└

Pythonについても同じことが言えるね。でも、そこでは逆の方向に力が働いてる。ほぼ同じ動作を提供する、でもパフォーマンスがいいPythonのランタイムがあっても、みんなCPythonにこだわってる。

└

正直、「仕様なし」ってバグよりもむしろ機能って感じだよね。仕様なしでここまで来たってことは、何か本質的に良いことが起こってるってことだと思う。

└

ああ、それは「Emacsを使わなくてもいい」っていう議論を完全に封じ込めるね。

└

CodebergはREADME用にOrgをサポートしてるよ！他のGitフォージもそうだったと思うけど、名前が思い出せない ;)

└

仕様がないからってOrgが進まないとは思わないな。Markdownは2004年に出て、CommonMarkは2014年に出た。CommonMarkが出た時にはMarkdownはすでにかなり人気があったと思う。もっと明らかな理由は、Markdownはシンプルすぎるくらい簡単で、Orgとは違って多くの人気プロダクトに統合されてたことだね。（余談だけど、正直言うと、RedditみたいなサイトがテキストフォーマットボタンじゃなくてMarkdownを選んだ理由がよくわからない。いいことだし、文句はないけど、標準のリッチテキストボタン（今のRedditにあるような）を追加する方がもっと自然な選択だった気がする。）

└

ほとんど何もサポートしていない。 それは単純に間違いだよ。AndroidやiOSのアプリでサポートしてるものはたくさんあるし、Emacs以外にもVimや他のエディタ用の実装もある。例えばGitHubもサポートしてるよ。オープンソースでプレーンテキスト、モバイルフレンドリーでローカル（クラウドじゃない）同期ができるMarkdownのノート取りに満足できる解決策は見つけてないな。（Logseqはデータベースを使う方向に進んでるみたいだけど、それを除いて。）Org-modeにはそういう解決策がいくつかあるよ。

└

これ、参考になるよ。https://orgmode.org/worg/org-syntax.html

└

それってPythonにも当てはまるんじゃない？GitHubがフォーマットにMarkdownを使うことにしたのが、他の用途に広まった最大の理由だと思う。コードを共有するためのシンプルなツールが世界を席巻したんだ。Microsoftがコパイロットで先行してるのに、LLMのコード生成市場を完全に抑えてないのには驚いてる。誰もが持ってない規模でソースコードにアクセスできるのにね。

今は全部の本にMarkdownを使ってるんだ。前はカスタムXMLフォーマットだったけど、あれはタイプするのがめっちゃ面倒だった。Vimのカスタムキー設定があってもね。Markdownがもっと機能豊かだったらいいなと思うけど、HTMLとPDFの共通の最低限としてはいい感じ。Pandoc風のMarkdownもなかなか良いよ。今の流れはこんな感じ：Markdown -> 前処理 -> pandoc -> HTML Markdown -> 前処理 -> pandoc -> HTML -> ページ分割 -> 分割HTML Markdown -> 前処理 -> pandoc -> LaTeX -> PDF 最後のは遅いから、Typstに置き換えたいと思ってる。多分、こんな感じ：Markdown -> 前処理 -> pandoc -> docbook -> xlstproc -> typst -> PDF Sphinxみたいな他のツールも試したけど、必要な条件を満たすものを見つけるのは難しいね。全体的にはTypstには結構感心してる。cmark-gfmからのXML出力を受け取って、xsltprocでTypstに変換するテストプログラムを書いたんだ。Pandoc/LaTeXよりもずっと早くPDFを生成してくれる。今はカジュアルなPDF文書にはそれを使ってるよ。https://github.com/beejjorgensen/xml2typ

└

リポジトリはいいね、ありがとう。ちょっとした要望だけど、test.mdの最終PDF出力もリポジトリに含めてくれたら嬉しいな。

└

Typstに置き換えたいと思ってる これ、ちょっとバカみたいだけど、--pdf-engine=typstを設定する代わりにdocbookとxsltprocを通す理由ってあるの？

ずっとこの考えに賛同してるよ！数年前に生産性やPKMツールのためのインターチェンジフォーマットとしてorgを提案したんだ。[0] Orgを使うと、ブックマークマネージャーとPKM、タスク管理を統一できるから、markdownではできないと思うんだ。ただ、AIが進化して、LLM向けにすべてをプレーンテキストで文書化するのがベストプラクティスになりつつあるから、状況が変わってきてる気がする。デフォルトのテキストフォーマットがmarkdown（GitHubやPKMツールのサポートのおかげで）だから、ますます多くの人がそれに触れるようになってる。だから、もしかしたら船は出てしまったのかもしれないし、orgは勝てない「いいフォーマット」の一例になるかも。逆に、LLMはorgのコンテンツもmarkdownと同じくらい簡単に取り込むから、むしろリッチな構文の分、もっと取り込むかもしれない。だから、両方の余地はまだあるかもね。どっちにしても、シェアポイントやコンフルエンス、Jiraなんかが負け組になると思う。今までの非標準的な方法で仕事を文書化してきた人たちがね。私たちorg派がずっと言ってきたように、プレーンテキストにこだわればいいんだ！[0] https://braintool.org/2022/04/29/Tools4Thought-should-use-Or...

org-modeで複雑なHTMLやLaTeXの構造を表現するのは、生のHTMLやLaTeXを書くよりも難しいんだ。だから、複雑なことに関しては、いつもHTMLやLaTeXを直接書くことに戻っちゃう。markdownは、結局HTMLに戻るだけ。markdownで表現できないことは、手動でHTMLを挿入すればいいからね。これらのマークアップ言語はシンプルなことには問題ないけど、複雑なことを表現するのは難しい。たぶん、typstみたいなエスケープメカニズムがあれば解決するかも。でも、org-modeはそうじゃない。ただ、org-modeというプログラム（org-modeの構文じゃなくて）は素晴らしいし、他には近いものがない。私にとっては、その問題を上回るものじゃない。Obsidianは十分な代替手段だし、最近ブログをorg-modeからmarkdownに移行したんだ。1000行のelispが200行のPythonに置き換わって、速度が50倍になった。去年は日記も同じことをした。ちょっと「離れる」のが寂しいけど、物事がシンプルになるからね。

└

最近ブログをorg-modeからmarkdownに移行したんだ。 俺もだ。Jekyllに移行したけど、orgが恋しくなるかと思ったら、全然そんなことなかった。しかも、elispと同じように遅いlisp風の言語（ruby）も使えるし。Orgはいいアイデアだけど、サポートしてるところがない。srcブロックでjupyterみたいな体験はできるけど、他のemacsユーザー以外と共有するのは大変だ。markdownは、個人的にはまあまあだけど、すべてがサポートしてるから、俺の中では明らかに選択肢だね。

└

逆転の日だ！markdown（hugo）から、手作りのpandoc + bashサイトメーカーを使ってorgのプレーンテキストに移行した。Emacsは必要ないよ。~350行のBashで、ホットビルドとホットリロードができる :) https://github.com/adityaathalye/shite （READMEにはGIFデモがあって、コードの設計も説明されてる）それに、orgファイルの中でリテラルHTMLエクスポートも使ってる。こんな感じで： #+begin_export html （ありがとう、Buttondown！） #+end_export これは便利で、C-'（M-x org-edit-special）を押すと、関連する構文に対応した編集モードがオンになったHTMLだけの一時バッファが開く。これは私にとって素晴らしい機能で、特定のHTMLが欲しい場所がたくさんあるから、org-exportやpandocでは思うようにorgプレーンテキストをコンパイルしてくれない（テンプレートシステムをいじるのに膨大な時間をかけない限り）。だから、そのエクスポートブロックを使って手動でHTMLを書いてるけど、全然問題ないよ。org-babelを使って、エクスポートされたHTMLブロックをインラインで更新するシェルスクリプトを呼ぶこともある。共通のHTMLフラグメント（例えばメールフォーム）を一箇所で調整して、必要なところにカスタムHTMLとして展開するためにこのトリックを使ってる。LaTeXも同様だけど、正直、あまり使ってないから、あなたが直面した問題にはほとんど遭遇してないと思う。でもHTMLに関しては、私が持ってるものは十分だと思ってる。

└

これにはコードブロックを使えるし、言語を指定すればEmacsが適切な構文ハイライトを提供してくれるよ： #+BEGIN_SRC html #+END_SRC 技術文書をたくさんのコードブロックで書く場合は、yasnippetを使ってキーボードショートカットでブロックを作成できる。

ここ10年間、プレーンテキストで人生を整理するためにOrg Modeを使ってる。iOSのBeorg [0] が素晴らしい。org-ql [1] やorg-super-agenda [2] みたいなものも使い始めて、さらに生産性が上がった。仕事では毎日のログ用のorgファイルも使ってる。これでやるべきことややったことを追跡できるし、年次レビューも楽になる！[0]: https://www.beorgapp.com/ [1]: https://github.com/alphapapa/org-ql [2]: https://github.com/alphapapa/org-super-agenda

└

こんにちは @cyrialize、これが自己宣伝として許容されるレベルだといいんだけど。私のブラウザ拡張機能、BrainToolが君のワークフローに役立つかもしれないよ。これはブックマークやタブ管理ツールみたいなもので、.orgファイルと同期して、タブをTODOとしてマークしたりできるんだ。それをorg-agendaで追跡することもできるよ。詳しい説明や動画はここにあるよ： https://braintool.org/2025/09/16/Browser-Workflows-with-Brai...

└

私は、日々の活動を日付ごとにログ/ジャーナルツリー方式で整理することを考えたことがあるよ（会議のメモや独立した作業のメモなど）。でも、最初に文脈に基づいた見出しを見て、その後に日付を確認する方が好きなんだ。君の日々のログは、1つのorgファイルの他の部分や、他のorgファイルにリンクしてるの？LLMに意見を聞いたことはあるけど、君の意見も気になるな！それと、denoteを試してみようとも思ってる。ファイル名は日付から始めて、タグやキーワードを使って繰り返しのトピックを整理する感じだよ。