最近考えていることがある。
世界には二つの文書観がある。一つは「文書とは最終成果物である」という見方。もう一つは「文書とは変更の累積であり、最終形は単なるスナップショットにすぎない」という見方。
前者が圧倒的多数派で、後者はGit文化圏のごく一部の人々だけが共有している。しかし、AIとの協働が日常化する時代、この溝を埋めなければ未来はない――というのが今日の話である。
ただし、これは技術の話ではない。言葉の話である。
「差分可能性を一級市民として扱う」という設計思想をdiffable-firstと呼ぶことにする。
具体的には次の三つが揃っていることを指す。
プレーンテキストとGitは、この三つを同時に成立させた歴史的な発明だった。ソースコードの世界では当たり前すぎて空気のようになっているが、一歩外に出ると、これが成立している領域は驚くほど少ない。
Word文書は差分が取れない。Excelはもっと取れない。PDFに至ってはそもそも「編集」という概念がない。これらのファイル形式で協働している限り、人類は「メールに添付した最新版_最終_v3_修正済み.docx」から永遠に逃れられない。
答えは単純で、個人の生産性ではdiffable-firstは得をしないからである。
一人で書く文書に差分管理は不要だ。差分管理の真の価値は、複数人の非同期協働で初めて顕在化する。ところが人類の大半の文書作成体験は「自分が書いて、誰かに見せて、フィードバックをもらう」という直列モデルで完結しているように見えている。並列編集の痛みを感じた瞬間にはもう締切が来ていて、Wordの変更履歴機能で凌ぐ。
そして学習コストの非対称性がある。MarkdownやGitを覚えるコストは最初の一本目で発生する。diffable-firstの便益は三本目以降の協働でようやく出始める。個人の時間割引率では、この投資は合わない。
さらに日本の場合、文書の「見た目」そのものが意味を持つ文化がある。フォントサイズ、余白、押印の位置、罫線の太さ。これらは単なる装飾ではなく、制度的な意味を担っている。diffable-firstの「意味と表示の分離」という思想は、この文化と正面衝突する。「最初から完成形が見えていないと不安」という感情に、正論は勝てない。
そしてもう一つ、あまり語られない最大の障害がある。名前の問題である。
Markdownという名前は、2004年にJohn Gruberが個人ブログ用に作った軽量マークアップ言語である。語源は「markup(マークアップ)」に対する軽量版というダジャレで、つまり技術者コミュニティの内輪ジョークだった。
これが悪い。
興味深いことに、世の中で成功したMarkdownベースのプロダクトは、"Markdown"という名前を隠している。Notionは「ブロック」と呼び、Slackは記法を使わせるが名前を出さず、Dropbox Paperに至ってはMarkdownだと気づかせない設計になっている。
Notionが一般層を獲得できたのは、Markdownの思想を保ちつつ名前を捨てたからである。ユーザーは「#で見出しになる」ことを体験的に学ぶが、「自分はMarkdownを書いている」とは認識していない。名前を説明する時点で負け、というのがこの20年の実証的帰結だと私は考えている。
ではMarkdownを何と呼ぶべきか。
私の提案は「AI原稿形式」である。
「Markdownで書きましょう」と言うと「なぜ?」という抵抗が生まれる。「AI原稿形式で書きましょう」と言うと「ああ、AIに渡すならそうだよね」という納得が生まれる。この動機づけの差が大きい。
現代のLLMは構造化された入力を圧倒的に好む。同じ契約書を「この部分とこの部分を比較して」とAIに頼んだ場合、docxバイナリを渡すよりMarkdownを渡したほうが結果の精度が桁違いに高い。ユーザーはdiffable-firstの思想を理解する必要すらなく、「AIと仕事するならこの形式のほうが結果がいい」という実利からMarkdownに流れる。
「AI原稿形式」という名前は、この実利を名前の中に埋め込んでいる。
「原稿」という日本語には、完成形ではない、編集可能な中間物というニュアンスが組み込まれている。これが決定的に効く。
この対比が、diffable-firstの思想を名前だけで伝えている。「原稿」と呼んだ瞬間、ユーザーは無意識に「これは変更されるもの」と認識する。差分・バージョン管理・PR的ワークフローが、名前のレベルで正当化される。
「箇条書き書式」のように見た目で名付けると、形式の本質とズレた時に破綻する。「原稿形式」のように役割で名付けると、実装が変わっても名前は生き残る。将来Markdownを超える新記法が出ても、「AI原稿形式」という概念的名前は継承できる。
なお「AI」という語は10年後には空気化する可能性がある。しかしこれはむしろ好都合で、普及期には「AI原稿形式」として入って、定着後に「原稿形式」に縮約される、というライフサイクルが想定できる。時代を示す部分(AI)と本質を示す部分(原稿形式)が分離されているので、風化に強い構造である。
Markdownだけ翻訳しても片手落ちで、Git/GitHub系の用語は全部「内輪用語」のまま外に出てきてしまった。以下、翻訳辞書の試案である。
| 原語 | 翻訳案 | 翻訳の理由 |
|---|---|---|
| Markdown | AI原稿形式 | 役割を名前に。実利(AI)を入口に。 |
| pull request | 変更提案 | 「プル」も「リクエスト」も日本語として機能していない。「変更の提案」こそが本質。 |
| commit | 保存ポイント | 「コミット」は英語圏でも比喩。ゲームのセーブポイント的な直感のほうが通じる。 |
| branch | 作業コピー | 「枝」のメタファーは美しいが、実務的には「別の作業用のコピー」と言ったほうが伝わる。 |
| merge | 取り込み | 「マージ」はビジネス日本語に定着しているが、誤解も多い。事務語彙の「取り込み」のほうが中立。 |
| repository | 作品フォルダ / 原稿フォルダ | 「リポジトリ」は何も喚起しない。用途に応じて「作品」「原稿」「プロジェクト」と訳し分けてよい。 |
| diff | 変更箇所 | 技術者以外に「差分」は通じにくい。「どこが変わったか」を素直に表現する。 |
この翻訳は厳密ではない。厳密さは目的ではないからである。目的は、Git/GitHubの文化圏の外にいる人が、違和感なく最初の一歩を踏み出せる語彙を用意することにある。
慣れてきたら、ユーザーは自然に原語を使うようになる。英語の正式名称は、技術コミュニティと接続するための第二言語として後から学べばよい。最初の入り口で原語を要求するから、多くの人が入り口で脱落していく。
歴史を振り返ると、名前一つで世界が動いた例は意外と多い。
「リサイクル」という言葉が普及する前、日本人は「廃品回収」という言葉で同じ行為を認識していた。しかし「廃品」は貧困の匂いがする言葉で、積極的に関わりたい行為にならない。「リサイクル」と呼び変えた瞬間、それは環境意識の表明行為になった。行為そのものは同じなのに、意味が変わった。
「働き方改革」も似た構造で、「残業削減」と呼んでいた時代には進まなかった議論が、名前を変えた瞬間に制度改革にまで至った。名前が認識の枠組みを変え、認識が行動を変え、行動が制度を変える。
diffable-firstの普及も、同じ経路を通ると私は考えている。「Markdownで書きましょう」では10年動かない議論が、「AI原稿形式で書きましょう」と呼び変えた瞬間に動き出す可能性がある。技術は既に揃っている。足りないのは語彙だけだ。
もう一つ、時代的な追い風がある。LLMの普及である。
先に述べたように、LLMは構造化された入力を好む。これは単なる好みではなく、技術的必然である。トークン化された平文のほうが、バイナリのdocxより情報密度が高く、文脈保持も効く。
この技術的必然が、ユーザーの行動変容を説得なしに引き起こしている。「MarkdownのほうがAIと相性がいい」という体験が、「構造化された文書のほうが協働に向いている」という認識に、知らないうちに接続する。ユーザーはdiffable-firstの思想を学ばずに、diffable-firstの恩恵を受けるようになる。
これは行政文書や学術論文の世界でも同じことが起きるはずである。AIレビュー、AI要約、AI翻訳――これらを日常的に使う層が増えれば増えるほど、「最初からAIが読める形式で書いておく」という慣習が生まれる。その慣習の名前が「AI原稿形式」である。
diffable-first文化を広めるために、正論で啓蒙する必要はない。啓蒙は10年経っても動かない。
動かすのは、名前を変えることと、AIという実利の組み合わせである。
という設計をすればよい。これは技術者の仕事ではなく、翻訳者の仕事である。技術の側にいる人間が、技術の外の語彙を真剣に考える。それが次の10年の普及を決めると、私は思っている。
「Markdown」を「AI原稿形式」と呼び変えるだけの、小さな一歩から始めてみてはどうだろう。
名前が変われば、世界の見え方が変わる。世界の見え方が変われば、未来が変わる。
