GEML — a plain-text document format built to be edited in place, one section at a time

GEML — General Expressive Markup Language

English | 中文

GEML は 均一でアドレス指定可能なブロックと標準の動詞を備えた軽量マークアップ言語です。
人間にとっては読みやすく、エージェントにとっては安全に変更できます。 エージェント主導の開発やナレッジワークでは、プレーンテキストや Markdown には決定的なブロック境界がありません。プログラムとモデルはファイル全体を渡してファイル全体を受け取り直します。せいぜい行ウィンドウで探り、書き換えるために元の内容をそのまま復唱する程度です。トークンコストはドキュメントの長さに比例して増大し、操作は肥大化していきます。何度か書き換えを繰り返すうちに、他所で抜粋されたコピーは少しずつずれ始めます。

何も変えずに始められます。 geml list、geml find、geml get は、すでにお持ちの Markdown をそのまま対象にします。変換は一切なく、新しいファイルも作らず、あなたの .md は .md のままです。

geml list    README.md                          # every section, as an address
geml get     README.md '#key-features'          # read ONE section, not the file
geml set     README.md '#key-features' --body   # write one section back
geml replace README.md 'old text' 'new text'    # swap a string, told which block held it
geml history save README.md -m 'tighten intro'  # a revision into README.md.gemlhistory, beside the file

そのセクションだけがエージェントのコンテキストに入ります。ファイルがどれほど長くなっても、ファイル全体ではなく数 KB だけです。そして保存するたびに、ブロック単位でもファイル全体でも読み返したりロールバックしたりできるリビジョンになります。

▶ Playground で試す — インストール不要、事前に読むものもありません。

セクションより細かい単位が必要ですか — 1 つのブロック、1 つのグラフ、1 つのテーブル? そんなときは .geml を中間の形式として使ってください。その粒度で編集すれば、出力する --to md がそれからずれることはありません。

ブロックには名前があり、その中身には座標があります。 テーブルのセル、data ブロックのリーフ、meta のキー — それぞれに構造がすでに与えている座標があり、get と set はまさにその値に作用します。

geml get doc.geml '#fy[2]["Q1"]'                     # one cell
geml set doc.geml '#intake["fields"][1]["name"]'     # one leaf in the JSON

人間にとっては、すっきり読めるプレーンテキストです。エージェントにとっては、アドレス指定可能で、検証可能で、追跡可能で、元に戻せる "Doc-as-a-Base" です。

---

GEML はミニマルです。 プレーンテキストであり、レンダラーがなくてもすっきり読めます。 言語全体で 1 つのブロック構文。 アドレス指定可能で、検証可能で、参照可能な構造をネイティブに備えています。

コンテンツの種類ごとに別々のミニ構文を用意する代わりに、GEML はあらゆる種類を 1 つのコンテナ、つまり型付きブロックで扱います。コードはブロックです。テーブル、図、数式、コールアウト、さらにはメタデータも同様です。そして散文の連なりも、アドレス指定可能にしたいときは 1 つのブロックにできます(=== text)。後から拡張するのも同じくらいシンプルです。形は毎回同じなので、言語は覚えやすく、間違えにくいものになっています。

=== code {#hello lang=python}
print("hi")
===

geml get doc.geml '#hello'   # by name, just this block

ブロックには名前があるので、動詞の作用する場所があります。完全な構文は 1 分でわかるフォーマットにあります。

目次: 何を解決するのか · なぜ今なのか · 何が違うのか · 1 分でわかるフォーマット · プロファイル · 実際に使ってみる · LLM と使う · 成熟度とバージョン · 設計 · ロードマップ · 参加する · ライセンス

何を解決するのか

解決する課題

1. コンテキストの負荷とトークンの肥大化

   • 現状: JSON/XML のようなデータ形式は、重いラッパータグと構文記号を伴います。Markdown には厳密な構造メタデータや参照の仕組みがありません。
   • アプローチ: マークアップの密度と構文のオーバーヘッドを調整し、対象ブロックだけを読み書きします — コンテキストのコストはドキュメントの長さに応じて増大しなくなり、エージェントの読み書きを軽量に保ちます。

2. AST レベルの精度とパースの決定性

   • 現状: 非構造化テキストは、LLM による複数回の読み書きを経て劣化します — フォーマットの破損、意味のずれ、パースのハルシネーション。
   • アプローチ: 抽象構文木（AST）に直接対応する決定論的な文法により、プログラムと LLM がブロック単位の作成・読み取り・更新・削除をアトミックに実行できます。

3. ドキュメントコピーの断片化

   • 現状: マルチエージェントの協調や共有パイプラインでは、コピー＆ペーストでコンテンツを受け渡すため、多数の切断されたコピーが残ります。
   • アプローチ: 設計段階からの単一の真実の源（Single Source of Truth） — 標準化されたモジュール参照とデータバインディングにより、冗長なコピーとバージョンの乖離を排除します。

主な機能

1. AST レベルの構造化操作

• 統一されたノード定義。ドキュメントは型付きのドキュメントツリー（AST）へ直接パースされます。
• エージェントは対象のセクション、属性、コンポーネントを正確に特定します。部分的なパッチと冪等な更新により、ファイル全体の書き換えを置き換えます。書き込みはバイト単位のスプライスとして行われ、ドキュメント全体の再検証を伴います — ツリーは読み取りと検証に用いられ、触れられていないすべてのバイトは変更されないことが保証されます。

2. 低トークンの読み書き

• 節約されるのはマークアップ文字ではなく、決して読み取られない部分です。#id は意味的に完全な 1 つのブロックをヒットし、残りはコンテキストに入りません。
• 同じ意味に対して、プロンプトトークンのコストが著しく低減します。モデルのスループットが向上し、推論コストが下がります。

3. 単一の真実の源、モジュール参照

• ドキュメント横断、フラグメント横断のコンポーネント参照をネイティブにサポートします。
• ソースノードを一度変更すれば、すべての参照が追従します — バージョンのずれはありません。

4. 堅牢な双方向の読み書き

• 言語全体で 1 つのブロック形状 — 生成しやすく、間違えにくく、主流の LLM の出力分布によく適合します。
• 正確なエラー位置と実行可能な修復フィードバックを備えた厳格なバリデータ。

5. プロファイルベースのドメイン拡張性

• 方言の混乱はゼロ。宣言的な profile メタデータを通じてドメイン語彙（例: デザインスタイル、インタラクティブフォーム、コードグラフ、メディアタイムライン）を拡張でき、新しい構文を発明したりパーサーを壊したりしません。
• 静的型と制約のチェック。未知の環境では標準ブロックへ安全にフォールバックします。

比較

観点	Markdown	JSON / YAML	GEML
コンテキストコスト（ブロック単位の I/O）	高い（ファイル全体を入出力）	高い（ファイル全体 + 構文ノイズ）	最小（対象ブロックのみ）
精密な AST 操作	弱い（厳密な意味ノードなし）	強い	強い（エージェントの読み書き向けに設計）
人間の可読性	高い	中程度	高い
単一ソース参照	非対応	プロトコル拡張が必要	ネイティブ（モジュール埋め込み）
ドメイン拡張性	断片化（独自構文のハック）	スキーマ依存	ネイティブプロファイル（新しい構文ゼロ + 検証済み）
書き込みの安全性	弱い	中程度	強い（不正な書き込みは反映前に拒否 + 単一ブロックのロールバック）

---

LLM 時代にまったく新しいテキストフォーマットが必要な理由

なぜなら、ドキュメントの生産者と消費者の両方が変わったからです。

従来のソフトウェアエンジニアリングでは、ドキュメントは人が読むための静的な説明か、プログラム向けにシリアライズされたデータファイルのどちらかでした。

今日では、人と AI エージェントが同じドキュメントを高頻度で共同編集します。エージェントがドキュメントの「第二の読者であり共著者」になると、従来のバランスは完全に崩れます：

1. コンテキストは希少な計算資源: ドキュメント全体を読み書きするたびに、エージェントの限られた注意ウィンドウと推論予算を消費します。
2. 人と機械の協働には同型的なキャリアが必要: 人は一目で読める必要があり、エージェントはブロック単位で正確に読み書きする必要があります。
3. ナレッジには単一の信頼できる情報源が必要: 散在するプロンプトやコピー＆ペーストされた Markdown は、イテレーションのたびに劣化する運命にあります。

しかし、既存のテキストインフラはどれもこの場面のために設計されていません：

• Markdown（人のために組版）: 安定した構造ブロックもマシンキーもありません。1 つのパラメータを変更するには、エージェントがテキスト全体を読み書きする必要があり、マルチターンのループでコンテキスト予算を浪費し、フォーマットと意味の両方にドリフトを招きます。
• JSON / XML（マシンのためにシリアライズ）: ラッパー構文と構造ノイズだらけで、人の自然な読解を妨げ、長いコンテキストでは高価なトークンを静かに消費します。
• スクラッチメモリと散在するファイル（単一の信頼できる情報源がない）: コンテキストはチャット履歴とそこら中の Markdown コピーに引き裂かれます。コピーは作られた瞬間からドリフトであり、バージョンのずれと幻覚による歪みが続きます。

これら 3 つの失敗の根源は、各ツールの美点そのものです。Markdown の「決してエラーを出さず、何でも書ける」という性質は、人に書く自由を与える一方で、まさにマシンが読み戻した構造を信頼できない理由でもあります。JSON/XML の厳格なスキーマは、マシンに確実性を与える一方で、まさに誰もその中に散文を書かない理由でもあります。美点が欠陥であり、だからこそパッチでは修正できないのです: 「壊れた参照はビルドを失敗させるべき」という仕組みを Markdown にボルト留めするのはその契約に背くことであり、JSON からラッパー構文を剥ぎ取るのはその本質を否定することです。人とエージェントが同じテキストを高頻度で共著し始めるとき、必要とされるのは二つの極の間の妥協ではなく、「人が読める」と「マシンが操作できる」を初日から一つの設計制約として扱うフォーマットなのです。

答え: "Doc-as-a-Base"

GEML は重厚な新しいランタイムを発明しません。Roy Fielding 博士の論文にある REST アーキテクチャスタイルから借りて、プレーンテキストのドキュメントに 1 つの標準的な操作セマンティクスを与えます。

従来の課題	対応する能力（4 つの法則）	開発者とエージェントにもたらすもの
1 箇所を変えると全文を書き直すことになる	アドレッシングの法則	すべてのブロックが #id を持ち、get/set はそのブロックだけを読み書きします。読み込まれないものは壊れようがない — コンテキストウィンドウはあなたのものです。
コピーが至る所にあり、すべてがずれていく	投影の法則	=== embed はコピー＆ペーストではなく動的に評価します。ソースでの 1 つの定義が、コピーを同期する手間を終わらせます。
不正なフォーマット / 壊れた参照が下流を汚染する	検証の法則	参照と構文はビルド時にチェックされます。不正な書き込みは反映される前に止められ、人間のレビューを待つ必要はありません。
1 つの悪い編集がファイル全体のロールバックを強いる	ロールバックの法則	コンパニオンの .gemlhistory が単一のブロックをアトミックに元に戻します — ページを破棄する必要はなく、エージェントのための軽量なバージョンセーフティネットです。

ドキュメントにもはや必要なのはフォーマットだけではありません — 必要なのは動詞のセットです。 GEML はプレーンテキストの可読性を保ちながら、決定論的なブロックレベルの操作を追加します。

💡 深掘り: LLM 時代におけるエンジニアリングドキュメントのジレンマと、なぜプレーンテキストフォーマットを根本から再設計する必要があるのかに興味があれば、ブログの全文記事をお読みください: 「LLM 時代に新しいテキストフォーマットが必要なのはなぜか？」

---

GEML の違いとは

GEML は意図的に小さく保たれています — その思考、何を拒否するか、そしてまだ未解決のことは設計をどのように考えたかにあります。

4 つの能力は 1 章前で確立されました — アドレッシング、投影、検証、ロールバック。この章では、各フォーマットがそれらに対してどこに位置するのか、そして GEML がどこに境界線を引くのかを示します。

他のフォーマットとの比較

4 つはいずれもそれぞれの分野に成熟したソリューションがありますが、珍しいのは、この 4 つすべてが 1 つのプレーンテキストフォーマットで実現されている点です:

ファミリー	状態の実体	アドレス指定 / 参照可能	投影 / 埋め込み可能	検証可能	履歴 / トレーサビリティ
Word / Docs	不透明な状態	❌ ブロックレベルのキーなし。プラットフォーム API 経由でのアクセス	❌ コピー＆ペーストのみ	❌ チェックは一切なし	⚠️ プラットフォームのサーバー側であり、ファイル内にはない
Markdown / AsciiDoc	文字のストリーム	⚠️ 見出しアンカーまたは方言の id。読み書きの動詞はなし	⚠️ 方言の埋め込み (Obsidian ![[…]]、include::) — 黙って壊れる	❌ 壊れたリンクは黙って失敗する	❌ フォーマット内にはなし — 外部の git が必要
JSON / XML	データのシリアライゼーション	✔️ (id / schema)	⚠️ XML のみ (XInclude、外部)	✔️ 外部ツールチェーン経由	❌ フォーマット内にはなし — 外部の git が必要
GEML	プレーンテキスト + ブロック構造	✔️ ブロックごとに一意の #id (ネイティブに参照可能)	✔️ === embed: 参照はルックアップ (ネイティブ)	✔️ ビルド時のエラー	✔️ ファイルの隣の .gemlhistory (ネイティブにトレース可能)

項目別: CommonMark との比較 · XML と JSON との比較 · 7 フォーマットの機能マトリクス · awesome-markdown にある Markdown のバリアントとツール (中国語、HTML ページ)。

Markdown との共存: GEML は**編集における信頼できる情報源 (source of truth)**であり、Markdown は納品される成果物です。geml <file> --to md|html で一方向に投影し、これまでどおり .md または .html を出荷します。ロックインではなく協働です。 (投影は不可逆です: ブロック id とテーブルに紐づくチャートは投影後も残りません。)

表の言葉を鵜呑みにしないでください — もう一度実行してみてください。 これが私がモデルに尋ねた内容です:

先ほど README を編集したあなた自身の経験に基づいて、ドキュメント上でたどるコマンドの手順 (grep などを使っているのを見ました) と、トークンを節約するためにドキュメントをキャッシュするかどうかを説明してください — 比較して、そこから GEML のどの部分が実際にその価値を持つのかを見てみましょう。

返ってきたもの: 1 回の編集にかかるコスト と ある実際の 1 日の再現。ご自身のモデルにこの質問を貼り付けて、何と答えるか見てみてください。 PS: codemap が生成する上流チェーン (これを呼び出すもの) と下流チェーン (これが呼び出すもの) が、関数と呼び出し箇所を特定し — プロジェクトのコードを変更する — ことを同じようにできるのかどうか、まだ解明しようとしています。レポートができたら投稿します。

1 分でわかるこのフォーマット

型付きブロック

1 つの形で、あらゆる型に対応。 ブロックの基本構文は === type [attributes] … === です (ここで {#id .class key=val} のような属性は省略可能)。変わるのは type (およびその本体の読み方) だけです:

=== code {lang=python}
print("hi")
===

=== note {.intro}
Parsed prose with *emphasis* and a [[#budget]] reference.
===

=== meta
title = "Budget plan"
===

= の連続 (3 つ以上) がブロックを開き、同じ長さの連続がそれを閉じます。長いフェンスは短いものの中に入れ子にできます。#id を持つブロックは、ラベル付きフェンス === #id で閉じることもできます — フェンスの長さを数える必要がなくなり、長いブロックではるかに間違いにくくなります (入れ子には依然としてより長い外側のフェンスが必要です。本体内の同じ長さの裸の === は、ラベル付きであれなかれ、ブロックを早期に閉じてしまいます)。型が本体の読み方を決めます — raw (そのまま: code、diagram、math、table)、flow (インラインマークアップを含む解析済みの散文: note、text)、data (1 行につき 1 つの key=val: meta) です。embed は本体を一切持ちません — その src= が、それが代理するブロックを指定します — そしてすべてのブロックは属性オブジェクト {#id .class key=val} を持つことができます。ここで .class は意味論的なラベルであり、決してスタイリングのフックではありません。完全なインライン文法 (強調、リンク、[[#id]] 自動参照、メディア、脚注、インライン $math$) は仕様にあります。

テーブル — 2 つの本体、1 つのモデル

テーブルを視覚的に記述します。

=== table {#budget caption="Annual cost"}
| Plan  | Months | Rate |
|-------|-------:|-----:|
| Basic |      1 |   30 |
| Pro   |      2 |   30 |
===

…またはデータとして記述します。テーブルは事実を保持し、その上の view が 計算列 と 集計行 を導出します。

=== table {#fy25 format=csv header=1}
Segment,  Q1, Q2, Q3, Q4
Cloud,     8, 10, 12, 14
Platform,  5,  6,  7,  9
Services,  3,  4,  4,  5
===

=== view {#fy25-report src=#fy25 compute="FY [%.1f] = Q1 + Q2 + Q3 + Q4; n = 1" summary="Segment = 'Total'; FY [%.1f] = sum(FY); n = sum(n)"}
===

どちらのテーブル形式も同じモデルを記述しています。FY 列と Total 行はビルド時に view によって計算されます。

Segment	Q1	Q2	Q3	Q4	FY	n
Cloud	8	10	12	14	44.0	1
Platform	5	6	7	9	27.0	1
Services	3	4	4	5	16.0	1
Total					87.0	3

compute は行ごとに列に対して + - * / ( ) を実行します。summary は集計関数 sum / avg / min / max / count から脚行を追加します（それらに対する算術、たとえば加重比率も可能です）。末尾の [printf] は数値の表示形式を設定します。上記の n は行数カウントのイディオムです — count は 1 つの列内の空でないセルを数えるため、定数列を合計したものが行数を数えることになります。

テーブルは src="regions.csv" を介して外部 CSV からデータを取得することもできます。

数式

=== math {#gauss caption="Gaussian integral"}
\int_{-\infty}^{\infty} e^{-x^2} dx = \sqrt{\pi}
===

$$\int_{-\infty}^{\infty} e^{-x^2} dx = \sqrt{\pi}$$

ダイアグラムとチャート — DSL をホストするか、テーブルをチャート化する

GEML はダイアグラム本体を決して解釈しません。プラグ可能なレンダラーにルーティングします（未知の format は警告となり、本体は保持されます）。

=== diagram {#flow format=mermaid caption="Review flow"}
graph LR
  A[Draft] --> B{Review} -->|ok| C[Publish]
===

graph LR
  A[Draft] --> B{Review} -->|ok| C[Publish]

ダイアグラムは テーブルをチャート化 することもできます — 単一の信頼できる情報源であり、列参照はビルド時にチェックされ、データのコピーは発生しません。

=== diagram {format=geml-chart data=#fy25-report type=bar x=Segment y=FY}
===

上記の #fy25-report view から描画されます — FY は計算列であるため、チャートはそれを導出する view にバインドされ、ベーステーブルにはバインドされません。

xychart-beta
  title "FY by segment"
  x-axis [Cloud, Platform, Services]
  y-axis "FY"
  bar [44, 27, 16]

データ — 単なるテキストではなく値

すべてのブロック型は、何を保持するかを示します。code はコードの領域、table はグリッド、math は数式です。data は データ値 を保持し、データフォーマットが存在する場所です — json（デフォルト）、jsonl、および宣言されたサブセット向けの yaml、toml は予約済みです。型付けされているということは、本体が表示されるだけでなく読み取られることを意味します。カンマが欠けていればビルドが失敗し、geml get --json は値そのものを返し、チャートはそれを直接読み取ることができます。

=== data {#log format=jsonl}
{"ts":"09:00","p95":41}
{"ts":"09:10","p95":58}
===

jsonl の本体は 1 行につき 1 レコードを保持し、プログラムはファイル末尾にブラインドで追記できます。レコードは独自のファイルに置くこともできます。src=ops/latency.jsonl#L900-999 はファイル名と、オプションで行ウィンドウを指定します — これにより、ログはこれまでどおり追記および tail され続ける一方、ドキュメントはその 検証済みで、アドレス可能で、チャート化可能な view となります。

埋め込み — コピーではなく動的参照

1 つのブロックが別のブロックを表すことができます。同じドキュメント内では src=#id、ドキュメントをまたぐ場合は src=other.geml#id によります。埋め込みはレンダリング時のソースの 動的ルックアップ です — ソースを一度変更すればすべての埋め込みが追従し、削除すれば geml check はその場でビルドを失敗させます。

=== embed {src=#fy25}
===

本体は空のままです。ターゲットは src= にあります。

Markdown ではその投影を表示できません。実際に動作を見るには、ブラウザ拡張機能をインストールし、sample.geml への raw リンクを開き、Transclusion セクションまでスクロールしてください — 同一ドキュメント内の投影（src=#roadmap）、ドキュメントをまたぐ投影、さらには連鎖的な解決（ある埋め込みがチャートを取得し、そのチャート自体が別のファイル内のテーブルにバインドされる）まですべてがその場でレンダリングされます。そこには何も書き込まれていませんが、ソースを一度編集すれば投影が追従します。

Profiles — Lego ブロックのように組み立てられるドメイン語彙

インタラクティブなフォームをオーサリングしたり、デザイントークンシステムを定義したり、コードベース全体のコールグラフをドキュメント内にマッピングしたいと思いませんか？ 従来の Markdown では、これには独自のプラグイン（:::note、カスタム JSX タグ）が必要であり、必然的に互換性のない方言のサイロへと分裂してしまいます。

GEML はこれを Profiles（アプリケーション層の語彙、仕様 §8.6） で解決します。ドメイン固有の構造化されたスーパーパワーをオンデマンドで解放する、1 行の宣言です。

=== meta
profile = "geml-style/v1 geml-form/v1"
===

==== form {#signup handler=subscribe}
=== form-field {name=email label="Work email" type=text required pattern="[^@]+@acme\\.com"}
===
====

=== style-rule {#cta match="button.cta" bg="{{brand}}" radius="6px"}
===

断片化のない拡張

• 🧩 レゴブロックのように組み合わせてマッチング コア構文は最小限で固定されたまま、ドメイン機能は無限に拡張されます。コールグラフ、デザイントークン、フォームバリデーション、バージョン履歴... 複数のドメイン語彙を 1 行の profile = "..." で組み合わせられます。

• ⚡ ゼロプラグインのオーバーヘッドで、即座にツールがサポート 新しいドメインブロックの追加にはパーサーのフォークやカスタムプラグインが一切不要です。カスタムブロックはインフラストラクチャ全体を即座に継承します: 決定論的な #id アドレッシング、geml get/set によるブロック単位の変更、CLI 動詞、MCP プロトコル、そして自律型 AI エージェントによる制御です。

• 🛡️ 自然にポータブルで、決してロックインされない 相互運用性を損なうことなく機能を拡張できます。サードパーティ製や未知のプロセッサであっても、ドキュメントは 100% の構造的整合性とブロックレベルのアドレス指定可能性を維持し、ツールを切り替えたときのフォーマット崩れという悪夢を終わらせます。

標準公開プロファイル

プロファイル (ガイド)	ステータス	用途	採用されているスーパーパワー	CLI	ライブデモ / 例
geml-codemap/v1	stable	コードベースのコールグラフを GEML ドキュメントとして生成します。メソッドごとに 1 ブロックなので、誰がそれを呼び出しているか、それが何を呼び出しているかを確認できます。フロントエンドとバックエンドが 1 つのグラフに統合されます	code ブロック: anchor、name、entry-via	geml codemap build|verify|serve	インタラクティブなコールグラフ · sample.geml
geml-media/v1	draft	動画のタイムラインを 1 つのドキュメントで記述します。アセット、クリップ、字幕、ボイストラックを扱い、Web プレーヤーとしてエクスポートしたり、ffmpeg で MP4 をレンダリングしたりできます	media、media-asset、media-clip、media-text	geml media build|export|lay|todo	ドキュメントから動画へ (ffmpeg 経由でドキュメントから MP4 へ)
geml-style/v1	draft	色、間隔、レイアウトは、コンテンツに適用されるルールを持つ別のスタイルシートドキュメントに記述します。コンテンツドキュメント自体は変更されません	style-rule、style-state、style-screen、style-frame	geml style check	GitHub Blob ページの 1:1 レプリカ
geml-history/v1	stable	過去のバージョンをドキュメントの隣の .gemlhistory ファイルに保持します。任意の古いバージョンを読み取ったり、単一のブロックを復元したり、ファイル全体をロールバックしたりできます	history-revision、history-keyframe、history-blob	geml history save|get|restore	アトミックなブロックロールバックのワークフロー
geml-form/v1	draft	フォームをドキュメントで記述します。フィールド、その型、どれが必須か、許可される範囲などを扱い、ブラウザ拡張機能とプレイグラウンドがプレビューを描画します	form、form-field、form-group、form-options、form-note、form-field の制約属性 pattern、min、max…	—	インタラクティブな複雑フォームの例
geml-translator/v1	draft	翻訳ドキュメントには翻訳されたテキストは含まれません。ソースを埋め込み、対象言語を指定するだけで、ブラウザ拡張機能が開いたときに機械翻訳するため、ソースへのあらゆる変更に追従します	embed および meta 属性 translate-to	—	—

💡 プロファイルを実際に動かしてみたいですか? • geml-media ライブデモ: 1 つのカットドキュメントと 1 つのコマンド (geml media build ep01-cut.geml --out ep01.mp4 --burn-subs) で、ffmpeg をオーケストレーションし、音声と映像を同期させ、トラックをミックスし、字幕を焼き込んで完成した動画を作成します (見る)。 • geml-style ライブデモ: コンテンツは page.geml 内で純粋なテキストのまま、スタイルとレイアウトは github.style.geml に記述します。CSS にロックインされることなく、GitHub の Blob ページを 1:1 でピクセル単位まで正確に再現してレンダリングします (見る)。 • 表内のすべてのプロファイル名をクリックすると、その 1 ページガイドが開きます — 何をするのか、最初のコマンド、日常的な使い方。コードを書くなら、geml-codemap から始めましょう。また、独自のカスタムドメインプロファイルを作成するのも簡単です。

次に — すぐに実際に試す

▶ Playground で GEML を書いてみる — 左側で編集すると、右側にライブでレンダリングされ、参照が壊れた瞬間にビルド判定が赤に変わります。インストール不要、事前に読むものもありません。

次に、あなたに合った順序で:

1. ブラウザーでレンダリングを確認する。 拡張機能 をインストールし、生の .geml リンク (GitHub の blob ページではなく生ファイルです — あちらは HTML です) を開きます: GEML 仕様そのもの (ドッグフーディング — 仕様は GEML ドキュメントであり、大規模にレンダリングされます)、ショーケース (計算された表、4 つのグラフ、Mermaid フロー、数式)、またはインタラクティブなコードグラフ用の playground/sample.geml。

2. ドキュメントから ページ 全体がレイアウトされるのを確認する。 スタイルデモ は GitHub の blob ページの 1:1 レプリカです — トップバー、ファイルツリー、パンくずリスト、Preview/Code/Blame、ドロップダウンメニュー — ここでは page.geml がすべての文字列を保持し、github.style.geml がすべての色と長さを保持し、ビューアーはそのどちらも知りません。どのブラウザーでも開きます — ビューアー自身のコードがそれを描画します — そしてそれを成立させる GEML がすぐ下にあります。

3. ローカルで実行する。 npm i -g @geml/geml (Node 22+)、次にドキュメントに対して geml check を実行するか、geml codemap build で自分のリポジトリを指定します。

4. Claude Code をセットアップする — コマンド 1 つ。 npx -y @geml/geml skill install は、オーサリングスキル、CLI、MCP サーバーを、すべてのプロジェクトに対してユーザーグローバルに配置します。設定を編集せず、フックもインストールしません。詳細。

5. 文法を読む。 完全な仕様 (EN / 中文) は規範的で、一度に読み切れる長さです。

6. または、ルールごとに通して見る。 GEML, illustrated (EN と 中文) — 11 の自己完結したページで、ブロックタイプごと、プロファイルごと、そして CLI 用に 1 ページ: 左側に GEML、右側にプロセッサーが 実際に 行うこと (geml check の診断、geml list のアドレス、--to html のマークアップ)、各ルールにはその出典とステータスがタグ付けされています。

LLM で GEML を使う

目標は 1 つです: あなたのモデルが 一度に 1 ブロックを編集し、検証する — 1 つの段落を変更するためにファイル全体を再読み込みして再出力することは決してありません。そこに到達するには 1 ステップで済みますが、どのステップかは何を使うかによって異なります。

Claude Code、Gemini、Qwen を使っている場合 — これを実行する

npx -y @geml/geml skill install

これはオーサリングスキル、geml CLI、MCP サーバーを、すべてのプロジェクトに対してユーザーグローバルにインストールします。settings.json の編集もフックもありません。アップグレード後に再実行してください。 (プラグインのほうがよいですか? claude plugin marketplace add geml-spec/geml、次に /plugin install geml@geml — 同じスキルで、MCP サーバーがバンドルされています。)

DeepSeek Harness を使っている場合 — このバンドルを追加する

同じセットアップを dsh バンドルとしてパッケージ化したものです — geml MCP サーバーに加えて、オーサリングスキルとコードグラフスキル:

dsh plugin --profile web add @geml/dsh-plugin   # web = the profile dsh boots by default; use your own profile name if you run another

dshmarket と awesome-dsh-plugin に掲載されています。ソースは integrations/dsh-plugin/ にあります。

Codex を使用する — プラグインをインストールする

同じペイロードをもう一度、Codex 向けにパッケージ化したものです。両方のスキル、MCP サーバー、そして SessionStart フックが含まれます。このリポジトリのチェックアウトで Codex を起動すると、/plugins に表示されます（マーケットプレイスのソースは .agents/plugins/marketplace.json にコミットされています）。クローンせずに追加する場合、git-subdir エントリは integrations/codex-plugin/ にあります。

あとはセッションで一度こう言えば、プロジェクトは切り替わります：

このプロジェクトは GEML をベースドキュメント形式として使用し、必要に応じて他の形式をそこから生成します。

それ以外を使用する — これを貼り付けて、出力を確認する

読むべきスキルを持たないモデルには、ルールを一度伝える必要があります。以下のプロンプトを貼り付けて、書き戻されたものに対しては geml check をゲートとして維持してください — CLI は npm i -g @geml/geml です（Node 22+）。

ドキュメントを GEML として書いてください：すべてのブロックは === type [attributes] … === です（1 分でわかる形式に型の一覧があります）。モデルが間違えやすい 4 つのルールがあります：閉じフェンスは開きフェンスと正確に同じ長さの = の連続でなければならず、本文に === を含む場合はより長い外側のフェンスが必要です。見出しは ATX の # のみで、--- フロントマターはありません（メタデータは === meta）。すべての #id は一意で、すべての参照（[[#id]]、[text](#id)、[^id]、data=#id）が解決できなければなりません。生の HTML はありません。規範仕様は GEML-spec.md です。

それをどう扱うか

geml list   doc.geml                                     # CALL FIRST: every block, its address, kind, lines
geml find   "words" doc.geml                             # search block content -> an address, not a line number
geml get    doc.geml '#hello'                            # read ONE block (a heading id = its whole section)
geml get    doc.geml '#hello' --intro                    # a section cuts three ways: --head | --intro | --body
geml set    doc.geml '#license' --in template.geml#mit   # replace that block, forking another
geml add    doc.geml --after '#intro' --in snippet.geml  # insert a fragment (keeps its own ids)
geml revert doc.geml '#plan' --rev -1                    # roll ONE block back
geml check  doc.geml                                     # validate only: diagnostics + exit code

どのセクションも、get と set のどちらでも 3 通りに切り分けられます：--head は見出し行、--intro は最初のサブ見出しより前に書かれている内容、--body はその下のすべてです — つまり --body は常に --intro を含み、サブ見出しがなければそれと等しくなります。セクションの冒頭は、サブセクションをコンテキストに引き込むことなく編集できます。

すべての変更は書き込む前に再パースされ、ドキュメントを壊すものであれば拒否されます — これが無人での編集を安全にしている理由です。残りの動詞（delete、rename、history、--to md|html|geml 変換、型やコンテンツハッシュによるブロックの指定）は parser README にあります。

MCP サーバー

標準の Model Context Protocol サーバーがパッケージに同梱されているため、エージェントはファイル全体を書き換えるのではなく、一度に 1 つのブロックを編集します — Markdown でも GEML でも同様です。これは Windows、macOS、Linux 上でローカルに動作します。--root はサーバーがアクセスを限定するディレクトリです（. または ${workspaceFolder} を使うと、アクティブなプロジェクトにバインドできます）。

インストールは不要 — 同じツールが Cloudflare 上の https://geml-mcp.supermarket.workers.dev/mcp でも動作します。そこではドキュメントが各呼び出しで送信され、書き込みはテキストとして返されます。詳しくは Worker の README をご覧ください。

Claude Code — コマンド 1 つでセットアップ（スキル、CLI、MCP サーバーをインストール）:

npx -y @geml/geml skill install

（または CLI で手動登録: claude mcp add --scope user geml -- npx -y @geml/geml mcp --root .）

Cursor — プロジェクトに .cursor/mcp.json を追加します:

{
  "mcpServers": {
    "geml": {
      "command": "npx",
      "args": ["-y", "@geml/geml", "mcp", "--root", "${workspaceFolder}"]
    }
  }
}

（または Cursor の Settings → Features → MCP で: 名前 geml、コマンド npx -y @geml/geml mcp --root .）

VS Code — 設定は不要です: GEML 拡張機能 がチャットに両方のサーバーを提供します。ホストされたサーバーと、各ワークスペースフォルダー用の geml mcp --root . です。エディターが確認してきたら、好きな方を承認してください。

Claude Desktop — claude_desktop_config.json に追加します:

{
  "mcpServers": {
    "geml": {
      "command": "npx",
      "args": [
        "-y",
        "@geml/geml",
        "mcp",
        "--root",
        "/absolute/path/to/your/docs"
      ]
    }
  }
}

あとは望む変更を伝えるだけです —「FY26 テーブルの Q3 行を修正して」— するとエージェントはその 1 つのブロックに対処します。ツール名を覚える必要はありません。それぞれが CLI の動詞を反映しているため（geml set → geml_set）、1 つの語彙がターミナルとエージェントの両方をカバーします。

このことが、モデルにファイルを書き換えさせるよりも優れている点は 2 つの保証にあります。書き込みはディスクに届く前に解析され、ドキュメントを壊すものであればその診断情報とともに拒否されます。そしてすべての書き込みはまず .gemlhistory リビジョンを記録します — つまり、不正な編集は防止され、かつ元に戻せます（geml_revert は 1 つのブロックを復元し、ファイルの残りの部分はバイト単位で同一のままです）。パスは --root に限定され、クライアントがこれを広げることはできません。

コードグラフを持つリポジトリ（geml codemap build）に --root を向けると、同じサーバーが「誰がこれを呼び出しているか」にも答えます — 4 つの読み取り専用 geml_codemap_* ツールで、2 つではなく 1 つのクライアントエントリで済みます。すべてのツールとオプション: docs/mcp-guide.md。

エコシステムと成熟度

GEML は小さく若い仕様です — しかし安定しています: 1.0 がリリースされ、実際のドキュメントに使用できます（このリポジトリ自身の仕様もその 1 つです）。厳格な適合テストスイート、それを通過するリファレンス実装 (仕様とは独立してバージョン管理されています)、そしてオープンな提案プロセスを備えています。

仕様は1 つあり、それはバイリンガルです。.gemlhistory サイドカーは geml-history/v1 プロファイルによって定義されています — これは仕様の一部ではなく、その上に乗るアプリケーション層です。これが、これが MIT で仕様が CC-BY である理由でもあります（LICENSE-spec.md に理由が書かれています）:

ドキュメント	英語	中文
仕様	GEML-spec.md	GEML-spec_CN.md
geml-history/v1 プロファイル	geml-history-profile.md	geml-history-profile_CN.md

このプロジェクトが公開するすべてのプロファイル: spec/profiles/。

バージョンと互換性

• セルフホスト — GEML-spec.geml はGEMLで記述された仕様で、すべてのテスト実行でクリーンに解析される必要があります。
• **適合性テストスイート**により、個別の実装間の互換性が保たれます。
• パーサーの参照実装。 現在、1,700件以上のユニットテストに加え、適合性コーパス、ラウンドトリップシリアル化、エンドツーエンドのCLI実行があり、カバレッジはCIで行／ステートメント／関数／分岐の**95%**以上にゲートされています。
• 前方互換性は文法に組み込まれています。 プロセッサーは認識できない構文を適切に処理する必要があります（仕様 §8.2）。そのため、ブロックタイプやダイアグラム形式を追加しても、後方互換性を損なう変更にはなりません。タイプレジストリはオープンです。未登録のタイプ名にはハイフンを含める必要があります（acme-invoice）。ハイフンを含まない名前は、仕様の将来のバージョン用に確保されます（§8.5）。
• 適合性の表明。 実装は、適合性テストスイートの各ケースを再現できれば、GEML 1.0に適合すると表明できます（§8.5）。許可は不要で、このリポジトリからの承認も必要ありません。
• ワイヤ上の形式。 拡張子は .geml（バージョンのサイドカーファイルは .gemlhistory）、メディアタイプは text/vnd.geml です。ベンダーツリーにIANA登録済み（2026-10-26）です。仕様がIETFを通じて公開される場合は、標準ツリーの text/geml を申請できます。
• .geml URLのフラグメント識別子は、そのIDを持つブロックを指定します（§0.6）。これはHTMLページでの #tag の意味とは異なります。

設計の考え方

設計が従うもの

1. 人間とエージェントの同型性、妥協ではなく 人間が読める Markdown と機械が読める JSON の間で折衷案を取るのではなく、GEML は人間の可読性と機械の決定性を単一の妥協のない制約として扱います。人間はクリーンで気が散らない散文を得て、エージェントは強く型付けされた AST を得ます。これにより、2 つの別々のフォーマット間での翻訳損失を排除します。

2. 文字のストリームではなく、基盤としてのドキュメント 従来のドキュメントは壊れやすい文字のストリームであり、1 つの文を編集するだけでファイル全体の書き換えがしばしば強制されます。GEML はドキュメントを、安定した主キー（#id）を持つ構造化レコードのアドレス可能なデータベースとして扱います。すべてのブロックは独立したライフサイクル、空間座標、そしてエージェントの O(1) の読み取りと書き込みに適したアトミックな CRUD インターフェースを持ちます。

3. 単一の構文プリミティブ、無限のドメイン語彙 あらゆる新しい種類のコンテンツに対して構文パッチを発明することを拒否します。GEML は単一の型付きブロックプリミティブ（=== type）を使用して、コード、データ、テーブル、数式、レイアウトを運びます。ドメイン機能はプロファイル（profile = "..."）を通じて無限に拡張されます。文法は 100% 凍結されたまま、語彙は開かれたままであり、方言の断片化を根本から終わらせます。

4. 複製ではなくトランスクルージョン：コピーの誘因を排除する 従来のハイパーリンクは別の場所を指す道標であり、コピーアンドペーストを促し、コピーが必然的に同期から外れてしまいます。GEML の参照は動的なビューポート（=== embed）です。ソースで一度定義すれば、どこでもライブで投影されます。コピーの動機を取り除くことで、単一の信頼できる情報源を維持します。

5. コンパイラ級の完全性：ドキュメントをコードのように扱う Markdown の精神は「決して失敗せず、何かをレンダリングする」であり、エージェントのハルシネーションとサイレントなドキュメントの腐敗の主要な温床です。GEML は厳格なビルド時の静的検証を強制します。壊れた #id、無効な属性、循環参照は、非ゼロの終了コードでビルドを失敗させます。エラーが下流のシステムを汚染する前に捕捉します。

6. ローカルファーストの履歴、クラウドロックインでも Git のオーバーヘッドでもなく データはローカルファイルシステムに属し、バージョン管理はブロック粒度に属します。GEML はバージョン履歴を独自のクラウドプラットフォーム（Notion や Google Docs など）の背後にロックすることを拒否しつつ、マイクロ編集に対する Git の重いリポジトリ全体のコミットオーバーヘッドを回避します。コンパニオンの .gemlhistory はプレーンテキストにローカルファーストのアトミックなスナップショットと外科的なロールバック（geml revert doc.geml '#id'）を提供し、真のデータ主権と安全性を確保します。

したがって拒否するもの

拒否するもの	理由
独自のダイアグラム言語	外部 DSL はホストされる（Mermaid、Graphviz、D2 など）。フォーマットはホスティングプロトコルのみを定義する
生の HTML エスケープハッチ	セマンティクスは移植可能なままで、バックエンドやレンダラーに縛られない
Setext 見出し / --- frontmatter	ATX # のみ。テーマティックブレークと衝突しないため
完全なスプレッドシートエンジン	行ごとの数式と集計サマリーで十分。セルアドレッシング、ルックアップ、マクロは不要

ロードマップ

• 英語版と中国語版のGEML 1.0仕様、および適合性テストスイート — さらに.gemlhistoryサイドカーを定義するgeml-history/v1プロファイル
• メディアタイプtext/vnd.gemlがIANAに登録されました（2026-10-26）。公開仕様は仕様書で、変更管理者はプロジェクトです
• 参照実装@geml/geml：パーサー、CLI、ブロック単位の.gemlhistory追跡
• Claude Code、Cursor、CodexなどのMCPホスト向け公式MCPサーバー（geml mcp）
• codemap — GEMLで記述されたコードベース全体の呼び出しグラフ
• Visual Studio Marketplaceで公開されているVS Code拡張機能（パブリッシャーはgeml）
• エコシステムとの統合：VS Codeのハイライト表示と参照チェック、tree-sitter、Obsidian、Logseq（稼働中のDBグラフとの双方向同期）、ブラウザービューアー、GitHub Action、LangChain / LlamaIndex、エージェントハーネスのプラグイン — Claude Code、Codex、Grok、DeepSeek Harnessに加え、Gemini CLIとKimi Code向けのルートマニフェスト
• LogseqマーケットプレイスへのLogseqプラグインの掲載（PR #893）と、xai-org/plugin-marketplaceへのGrokプラグインの掲載
• 2つ目の実装geml-parser-rs/ — Rust製でWebAssemblyにコンパイルされ、参照パーサーを読まずに、仕様と適合性テストスイートだけをもとに作成
• 他の開発者による実装 — Pythonでも、お好きな言語でも構いません。仕様と適合性テストスイートは公開されており、連携を喜んでお手伝いします

---

参加する

GEMLは1.0ですが、「安定」とは、すでに定められたルールが変更されないという意味であり、設計が確定したという意味ではありません。これまでに2つの実装がありますが、どちらも同じ作者によるものです。つまり、仕様を支えているのはまだ1人分の意見です。皆さんの考えによって、仕様そのものを変えられる余地があります。 参加したい方は、ぜひご検討ください。

現在草案段階にある提案について議論しましょう：

• GEP-0008 · form型ブロック — アドレス指定可能なフィールド、不活性な出力先
• GEP-0010 · 言語軸に沿ったプロジェクション — 翻訳されたドキュメントはコピーではなくビュー

ほかにも気になることがありますか？ディスカッションを始める。

または、担当してみませんか：

課題	現状	必要なこと
ほかのエージェントツールへのスキルのインストール	Gemini CLI、Qwen Code、AGENTS.mdはすでに検出によってインストールされます。MCPサーバーはあらゆるクライアントで動作します	残りも同様に追加します：Cursor、GitHub Copilot、Cline — それぞれのルールファイルの規約は頻繁に変わるため、作成前に最新のドキュメントを確認してください
ほかのモデルでの入門ガイドの有効性	Claudeでのみ試されています	GPT / Gemini / ローカルモデルにそれぞれ入門ガイドを使ってGEMLをまとめて作成させ、初回にgeml checkを通過する数を数え、繰り返し間違えるルールを報告してください — 入門ガイドで明示すべきなのは、そうしたルールです
Obsidianとのより深い統合	描画できますが、まだコミュニティストアにはありません	CodeMirrorレイヤーでの編集とシームレスな双方向描画に加え、ストアへの登録が必要です。Obsidian APIに詳しい方を求めています。
ほかのブラウザーへのビューアー対応	Chromeでは動作します	Firefox / Safariへの移植。
RAG統合のパッケージ化	LangChain / LlamaIndexは参照実装です	PyPIへの公開、およびほかのフレームワーク（Haystack、DSPy、…）との連携。

• お使いの言語で仕様を実装する — 仕様だけをもとに新しいGEMLパーサーを作成します（パーサーの書き方）。geml-parser-rs/はその方法で作成されており、比較用の実例です
• 仕様が曖昧な箇所を見つけること自体が貢献です。そのパーサーが公開されるかどうかは問いません。

または、新しいアイデアを提案してください：

• GEP：提案、仕様の編集、適合性テストケースをまとめて追加します（プロセス）

または、活用してみましょう：

シナリオ	場所	状態
コマンドラインから使う — 検証、変換、ブロック単位の編集、バージョン履歴を、すべて1つのコマンドで実行	@geml/geml（ソース geml-parser/）	利用可能
ブラウザーで読む — 任意の raw .geml リンクを開くと、その場でレンダリングされます。計算テーブル、グラフ、Mermaid、数式に加え、診断結果がバナーで表示されます	Chrome ウェブストア · ソース	利用可能
エージェントにブロック単位で編集させる — MCP サーバーを使うと、ファイルを書き換える代わりにエージェントが1つのブロックを変更し、すべての書き込みがディスクに反映される前に検証されます	docs/mcp-guide.md	利用可能
DeepSeek Harness から使う — geml MCP サーバーにオーサリングスキルとコードグラフスキルを加えた、インストール可能なバンドルです	@geml/dsh-plugin · dshmarket · ソース	利用可能
Codex から使う — 同じ内容を再びまとめたものです。両方のスキル、MCP サーバー、SessionStart フックを /plugins からインストールできます	integrations/codex-plugin/	このリポジトリから利用可能です。公開プラグインディレクトリにはまだ掲載されていません
Grok から使う — 同じ内容をさらにまとめたものです。両方のスキルとMCP サーバーが含まれます	integrations/grok-plugin/	このリポジトリから利用可能です。xai-org/plugin-marketplace の PR はまだ作成されていません
Logseq グラフをプレーンテキストに同期する — Logseq 2.0 の DB グラフを、アドレス指定可能で Git に適した GEML ファイルとして継続的に同期し、元に戻すには restore を使います	@geml/logseq-sync · ソース	npm ではウォッチャーを利用できます。プラグインはリリース zip からインストールします。マーケットプレイスの掲載（PR #893）はまだマージされていません
コードベースをドキュメントにする — 呼び出しグラフ全体を、閲覧可能な GEML ドキュメントのツリーにします	geml codemap build（ガイド · 設計）	利用可能
エディターで記述する — 構文ハイライトとビルド時の参照チェックに対応します	Visual Studio Marketplace · ソース	利用可能
Android Studio / IntelliJ で記述する — ハイライト、入力中の診断、プレビュー、構造ビュー、.gemlhistory からのブロック復元に対応します	integrations/intellij+androidstudio-plugin/	ビルド済みです。ビルドした zip からインストールします（Install Plugin from Disk）。JetBrains Marketplace には掲載されていません
Obsidian でレンダリングする — 参照パーサーとビューアーのレンダラーを使い、ウェブと同じコードパスで処理します	integrations/obsidian/	ビルド済みですが、コミュニティストアにはありません
RAG / エージェントフレームワークに取り込む — ブロック単位のローダー（ブロックごとに1チャンクを作成し、block_id を保持）と、エージェント編集ツールを利用できます	integrations/langchain+llamaindex/	リファレンス実装
何もインストールせずに試す — 左側で編集し、右側でリアルタイムにレンダリングを確認できます	プレイグラウンド	利用可能

まず読むべきファイルは3つです。意思決定の方法については GOVERNANCE.md、作業の提出方法については CONTRIBUTING.md、そして人に関する唯一のルールについては CODE_OF_CONDUCT.md をご覧ください。設計にはどれほど厳しく異議を唱えてもかまいませんが、人ではなく設計に向けてください。

リポジトリの構成

spec/                  The specification as .md (EN / 中文) and the CC-BY spec
                       license, with profiles/ (application layers — geml-history,
                       geml-codemap, geml-style, geml-form, geml-media,
                       geml-translator — each a reference beside a one-page usage
                       guide) and proposals/ (GEPs), both MIT
spec/in_geml_format/   The dogfood: the specification written in GEML, with its
                       .gemlhistory sidecar
geml-parser/           Reference parser, renderer, CLI + codemap toolkit (TypeScript, Node 22)
geml-parser-rs/        The second implementation: the same spec in Rust, compiled to
                       WebAssembly, written from the spec and the conformance suite alone
integrations/          Everywhere GEML plugs in: chrome-geml-viewer (browser extension),
                       geml-check-action (CI), vscode, intellij+androidstudio-plugin,
                       obsidian, logseq (two-way vault sync + the watcher), tree-sitter (brief),
                       langchain+llamaindex (RAG loaders), windows-icon
                       (Explorer file icons), the agent-harness plugins —
                       claude-plugin, codex-plugin, grok-plugin, dsh-plugin — and
                       website (what this repository pushes to the site)
.agents/, .claude-plugin/   Plugin marketplace manifests, so the plugins show up
                       from a checkout (Codex `/plugins`, Claude Code `/plugin`)
docs/                  Guides (MCP, writing a parser), design records, the release
                       runbook, assets (logos)
.claude/skills/        Claude skills: GEML authoring, and the code graph
.github/               CI, security-scan, release and site workflows (npm, MCP
                       registry, VS Code, viewer, website), issue templates (bug,
                       GEP, new implementation) and the PR template
(website)              The homepage, playground, demos, blog, comparisons,
                       benchmarks, manifesto and illustrated pages live in their
                       own repository, geml-spec/geml-spec.github.io, which links
                       here for the spec and guides; the website workflow pushes it
                       the playground bundle, code graph and logos. What
                       this repository publishes at geml-spec.github.io/geml/ is
                       site/ — a forward to the same path on the new site.

ライセンスとガバナンス

コードは MIT (LICENSE): このリポジトリ内のすべて — geml-parser/、geml-parser-rs/、integrations/ のすべて、.claude/skills/、docs/、 spec/profiles/ 内のプロファイル、spec/proposals/ 内の GEP — ただし仕様書を除きます。

仕様書は CC-BY-4.0 (LICENSE-spec.md、 そこに正確に列挙されています): spec/GEML-spec* および spec/in_geml_format/*。仕様は 1 つであり、 spec/profiles/ 以下のプロファイルはアプリケーション層であり、MIT です。 仕様はソフトウェアではないため、誰でも許可なく適合する 実装を構築できます — そして 適合性テストスイート に合格すれば、 それを GEML 1.0 に適合 と呼ぶことができます。

名称の使用。 GEML を実装するために、フォーマットにちなんで実装を命名するために（geml-rs、pygeml、お使いの言語のレジストリ上の geml パッケージ）、あるいはあなたのツールが GEML を読み書きすると述べるために、許可は必要ありません。2 つのお願いがあり、いずれも法的な制限ではありません: 実装を GEML 1.0 に適合 と呼ぶのは適合性テストスイートに合格してからにすること、そしてこのプロジェクトがその実装を作成、承認、または保守していると示唆しないことです。仕様文書自体の帰属表示は、CC-BY-4.0 がすでに求めているとおりです。