タグ・アノテーション リファレンス

English · 日本語（このファイル）

タグ（[...]）

タグはアーキテクチャ上の意味を宣言する。スタイルはタグを受けて変わる。 タグは意味の宣言であり、見た目の直接指定ではない。見た目の制御は .krs.style で行う。

名前は kebab-case 識別子として lex される。 [my-team-internal-tag] は my-team-internal-tag という 1 つのタグであり、open vocabulary を受けるすべてのポジション — annotation 名（@my-mark）、capability 名、legend の ref 対象 — で同じ規則が成り立つ。断片が keyword と同綴りでもよい（[legacy-system] は 1 つのタグ）。.krs.style はハイフンを識別子に natively 含めるので、.krs に書いたタグと .krs.style に書いたセレクタは同じ名前に着地する。（#2509）

Related TPLs: TPL-2509 — kebab-case 名ポジションは 1 つの字句ヘルパーを共有する。新しい名前ポジションは .krs / .krs.style 両面でハイフン入り名を検証する。

タグ	意味	デフォルト描画への影響
[external]	システム境界の外側	枠線を破線、色をグレー系に
[index]	正本を高速に検索するために導出された二次インデックス（役割。正本そのものには付けない — vector DB / ElasticSearch でも正本なら不要）	database ノードに index バッジを付与
[cache]	正本ではなく、失っても再構築（再計算・再取得・再ログイン）で回復できるストア。TTL を持つのが典型	database / storage ノードに cache バッジを付与
[analytics]	分析・集計のために正本から取り込んだ派生ストア（DWH / データレイク）	database / storage ノードに analytics バッジを付与
[async]	非同期通信（エッジ用）	破線矢印
[sync]	同期通信（エッジ用、デフォルト）	実線矢印（デフォルト）
[human]	人間の利用者	user ノードにのみ使用。デフォルトスタイルへの影響なし
[ai]	AIエージェント	user ノードにのみ使用。デフォルトスタイルへの影響なし
[mobile]	モバイルネイティブアプリ（client）	client ノード用の認識済み form-factor タグ
[web]	ブラウザ SPA（client）	client ノード用の認識済み form-factor タグ
[desktop]	デスクトップアプリ（client）	client ノード用の認識済み form-factor タグ
[cli]	コマンドラインツール / SDK（client）	client ノード用の認識済み form-factor タグ
[device]	IoT / 専用端末 / KIOSK（client）	client ノード用の認識済み form-factor タグ
[extension]	ホストアプリのプラグイン — Chrome / VS Code / Figma 等（client）	client ノード用の認識済み form-factor タグ
[embed]	第三者サイトに埋め込まれるウィジェット / SDK（client）	client ノード用の認識済み form-factor タグ
[table]	テーブル系リソース（シェイプ: cylinder）	cylinder シェイプで描画
[queue]	キュー系リソース（シェイプ: queue）	queue シェイプで描画
[api]	API系リソース（シェイプ: hexagon）	hexagon シェイプで描画
[storage]	ストレージ系リソース（シェイプ: cloud）	cloud シェイプで描画

client 用の 7 つの form-factor タグは karasu が 認識 している。将来的に kind 固有のアイコン（#823 Phase 2）やレイアウトヒント（Phase 6）に反応する予定。組み込み表の外のタグは v1.x では受理されるが非推奨 — 下記「非 builtin のタグ名は非推奨（v1.x）」を参照。

shape タグは infra ブロックキーワードをミラーする — 別物ではなく対応関係にある。 infra ブロックの キーワード（database 配下の table、queue 配下の queue-item、storage 配下の bucket）は、system 図上の 共有ストアノード（実体）を宣言する。usecase の resource は、その usecase が読み書きする対象への 操作参照であり、resource が dot 記法で infra leaf を参照する（resource OrderDB.OrderTable）と、karasu は 参照先 infra sub-resource の kind から対応する shape タグを推論する（table → [table]/cylinder, queue-item → [queue], bucket → [storage]）。つまり参照は、指し示すストアと同じ形で描画される。だから shape タグ [table] / [queue] / [storage] は infra sub-resource kind を意図的にミラーしている。参照する infra leaf が無い resource には、純粋な shape ヒントとして手書きで付けることもできる。[api]（hexagon）だけは infra 側に対応 kind が無く、API 系 resource 用の手書き専用 shape。同じ語が 2 つの位置に現れても 衝突しない: キーワードは 宣言の先頭でノードの kind を決め、[...] タグは resource への 接尾辞で shape だけを決める — 両者は resource 参照で結ばれた相補的なレイヤーである。syntax.md の Infra layer 節も参照。

Related TPLs: TPL-1415 — infra sub-kind → shape タグの推論（INFRA_SUB_KIND_TO_TAG）と shape タグ表は、同じ語彙の 2 つの表現であり整合し続けなければならない。

database [index] は database ノードを、正本（system of record）ではなく 派生の検索 / 二次インデックス — ElasticSearch / OpenSearch クラスタ、あるいは pgvector / Pinecone / Weaviate などの vector store — として印付ける。cylinder はそのままに index バッジを付与する。具体的な技術は物理層の store { type "ElasticSearch 8"; realizes SearchIndex } に置き、エンジンを載せ替えても論理モデルが揺れないようにする。同じストアが正本かつ index を兼ねる場合（例: Postgres + pgvector）は [index] タグを付けないだけでよい。[index] は技術ではなく役割を表す: 正本（system of record）を高速に検索するための index として導出した二次ストアにタグ付けする。Vector DB / ElasticSearch 等を使っている場合でも、それが正本なら [index] は付けない。背景: ADR-316, Issue #1718。

Related TPLs: TPL-1503 — [index] はラベルだけでなく効果（index バッジ）を伴う必要がある、受理されるタグである。

ストアの役割タグ — 1 つの軸、4 つの状態

[index] / [cache] / [analytics] は 1 つの軸を成す。そのストアがどういう意味で正本（system of record）ではないかである。タグ無しは正本そのものを指すので、4 状態でストアの役割は言い切れる。

タグ	どういう非正本か	適用先
(タグ無し)	正本（system of record）	すべてのストア
[index]	検索のための導出	database
[cache]	失っても再構築（再計算・再取得・再ログイン）で回復できる	database / storage
[analytics]	分析のために正本から取り込んだ	database / storage

[cache] の判定は 1 問に畳まれる — このストアが消えたら業務データが失われるか。 失われるならそれは正本なのでタグを付けない。セッションストア、Redis キャッシュ、Cloudflare KV はいずれも該当する。CDN のオリジンキャッシュ、生成済みサムネイルやレンダリング済み成果物、エクスポートの一時置き場も同じく該当する（[cache] が storage にも適用できるのはこのためである）。判定軸が導出ではなく揮発性である点に注意する: セッションストアは何かの写しではなくそのセッションの正本であり、導出コピーに限定するとこの最も典型的な用途が漏れる。[index]（導出 ∧ 検索用）はこの定義の内側に矛盾なく収まる。

[analytics] は DWH / データレイク側を指す。正本から分析・集計のために取り込んだストアである。データレイクはオブジェクトストレージ（S3 / GCS 上の Parquet 等）で実現されるのが典型なので storage にも適用できる。他システムから取り込んだ、この system 内に正本を持たないデータを含む場合も「この system の正本ではない」ことに変わりはなく、付与してよい。名前が製品カテゴリではなく役割なのは意図的である — [warehouse] は物（Snowflake / BigQuery）の言い換えに寄り、[analytics] は何のための導出かを名指す。[index] と同じ語形である。

3 つとも共有ストア系の診断の対象外になる。 shared-infra-fan-in と cross-domain-store-access が述べているのは共有された正本についてであり、1 つの検索インデックス・1 つのキャッシュ・1 つの DWH を複数サービスが読むのは通常の形であって Database-per-Service の smell ではない。

この軸はどこで止まるか。 役割タグが表すのは同一 kind 内での、正本かどうかの違いだけである。技術の違い（graph / time-series / column-oriented）は物理層の store { type "…" } に、運用配置の違い（read replica / シャード）は物理層に置くかモデル化しない。[kv] / [graph] / [timeseries] / [replica] が組み込みタグでなく tag-not-builtin の警告対象であるのはこのためである。新しい役割タグの可否も [cache] と同じ 1 問に畳まれる — それは正本かどうかの話か。

Related TPLs: TPL-2172 — 上記の停止規則は builtin 追加要望が通る 3 問の 3 番目であり、そこで生じた却下は議論をやり直さずに済むよう記録される。TPL-1503 — タグの appliesTo に挙げた kind はすべてバッジを持つので、自分の kind の内側で受理・無効果になることがない。

非 builtin のタグ名は非推奨（v1.x）

bare [<identifier>] は v1.x では引き続き任意の名前を受理する（v1.0 freeze — ADR-1314 — が parse 挙動を凍結している）。ただしツール語彙（上記の組み込み表 + 下記のシステム自動付与タグ）の外のタグは非推奨であり、karasu は使用のたびに tag-not-builtin warning を出す。抑制条件は意図的に設けない — .krs.style のセレクタや legend の ref は名前が意図的である証跡になるが、意図があっても結果は変わらない: 構文 v2.0 はツール語彙のみを受理する（enforcement は warning のままで、parse error にはしない — 既存ファイルはパースされ続ける）。移行先:

• 所属やモデル固有のラベリング（PCI スコープ、PII、「認証必須」）→ facet 構文: 集合を top-level で 1 度宣言し、要素に facets <id> を書く。
• 足りないアーキタイプ → 組み込みタグの追加要望。非推奨タグはその間も動き続ける — 警告されるだけで、既定描画への効果は持たない。この経路の実例が #2172 で、[cache] / [analytics] は採用、[kv]（役割ではなく技術）と [bff]（delivers <ClientId> が構造として表現済み）は理由を記録して却下した。

.krs.style 側でそうした名前を狙っているルール（[pci] { … }）も同じ条件で非推奨になり（style-tag-selector-not-builtin）、facet セレクタへ書き換える。両方が警告されるのは、ノード側のタグとシート側のセレクタが別々の編集だからで、片方しか報告しないと残った方が見つからない。

どの構文を選ぶかは下記「語彙の register」を参照。

Related TPLs: TPL-1503 — 非 builtin のタグ名はかつて禁止された第 4 状態（受理・無効果・文書化なし）にあった。tag-not-builtin はそれを状態 (2)「unknown として警告」に解消する。TPL-2172 — この経路で来た builtin 追加要望は 3 問（register / 既存表現の有無 / 停止規則）で裁き、却下も記録する。

記述例

system Shop {
  service Payment [external] {
    label "決済サービス"
  }
  service ECommerce {}
  service Inventory {}
  user Customer [human] {
    label "顧客"
  }
  user AIAgent [ai] {
    label "注文自動化エージェント"
  }

  ECommerce --> Inventory "在庫を同期する" [async]
}

---

アノテーション（@...）

アノテーションはライフサイクル・状態を表すメタ情報。タグとは別の概念。

アノテーション	意味	デフォルト描画
@deprecated	廃止予定	⚠バッジ、ノードを半透明に
@new	新規追加	✦バッジ
@experimental	実験的	⚗バッジ
@migration_target	移行先	→バッジ
@planned	設計上そこに置くが、まだ実在しない	◇バッジ
@draft	主張されているが人手で確認されていない	✎バッジ

記述例

複数付与可。タグとの併用も可。

service Legacy [external] @deprecated @migration_target {
  label "旧システム"
}
service NewAPI @new @experimental {
  label "新API"
}

domain の移行期共存

@deprecated または @migration_target を domain に付与すると、 同一システム内で同じ ID を持つ domain の共存が許容される（移行期のモデリング）。 @migration_target が付いている方がナビゲーションの優先先になる。

system OrderSystem {
  service LegacyService {
    domain Contract @deprecated {   // 移行元 — 廃止予定
      -> Billing
    }
  }
  service NewService {
    domain Contract @migration_target {  // 移行先 — ナビゲーション優先
      -> Billing
    }
  }
}

@deprecated 単独、または @migration_target 単独、どちらか一方が付いていれば重複を許容する。 どちらにも付いていない場合はエラーのまま。

非 builtin のアノテーション名は非推奨（v1.x）

@<identifier> は v1.x では引き続き任意の識別子を受け付ける（open set であること自体を ADR-1314 が凍結している）。ただし上記の組み込み表の外の名前は非推奨であり、karasu は使用のたびに annotation-not-builtin warning を出す。抑制条件は設けない（スタイルシートのセレクタは意図の証跡になるが、意図があっても結果は変わらない: 構文 v2.0 はツール語彙のみを受理する。enforcement は warning のままで parse error にはしない）。非 builtin アノテーションにデフォルト描画はなく、v1.x では .krs.style のアノテーションセレクタのターゲットとして引き続き機能するが、その用法も非推奨になった（style-annotation-selector-not-builtin）— styling フックは facet セレクタへ移った（移行前後の書き換え例もそこにある）。移行先:

• 所属やモデル固有のラベリング（チーム所有マーク、audience ラベルなど）→ facet 構文。
• 足りない lifecycle 状態 → 組み込みアノテーションの追加要望。実例は #2172 で、@planned は採用、@canary（数時間で終わる runtime のロールアウト状態であり karasu が扱う slowly-changing な構造の外側。@experimental とも重なる）と @sunset（@deprecated が既に言っている）は却下した。長期併存する canary は @new @experimental、新旧併存は @migration_target で書ける。

near-miss のタイポヒント（annotation-possible-typo、info）も引き続き発火する: 組み込み名のタイポ（例: @depracated）は放置すると「バッジが出ない」という形でしか表面化しないためである。ヒントはスタイルシートのアノテーションセレクタに現れる名前について従来どおり抑制される。両診断は v1.x の間共存し（near-miss には両方が付きうる）、v2.0 で整理される。

service Billing @team_alpha   // 非推奨: annotation-not-builtin warning
service Legacy  @depracated   // 二重に警告: タイポヒント (info) + not-builtin (warning)

Related TPLs: TPL-1503 — deprecation により非 builtin 名は、従来の文書化なき open set 受理ではなく状態 (2)「unknown として警告」に保たれる。TPL-2172 — builtin アノテーションの追加要望にも同じ 3 問の gate を適用し、lifecycle register が最初のフィルタになる。

アノテーションのパラメータ

組み込みのライフサイクルアノテーションは、移行 intent を記録するパラメータを @name(key: "value"[, key: "value"]*) の形で持てる:

service Legacy @deprecated(until: "2026-Q3")
service NewSvc @migration_target(from: LegacyMonolith)

認識されるキー（組み込み限定）:

アノテーション	キー	意味
@deprecated / @experimental	until	廃止 / 安定化の目標時期
@migration_target	from	移行元のノード
@draft	confidence	その記述にどれだけ自信があるか — low / medium / high

• 精度による graceful degradation: until の値が日付（YYYY-MM-DD）/ 年月（YYYY-MM）/ 四半期（YYYY-Qn）としてパースできれば machine-usable（ソート / filter 可能）。それ以外の文字列（例: "来年あたり"）はそのまま opaque な表示専用値として保持する。opaque 値にバリデーションエラーは出さない。
• 実行時評価はしない: until は記録された intent であって期限ではない — karasu は現在日付と比較しない（「期限超過」診断は出さない）。job.schedule（保持するが simulate しない）や warn-don’t-error の立場と整合。
• 未対応パラメータは黙殺せず warn: それ以外のアノテーションへのパラメータ、または未認識キーは annotation-param-unsupported 警告とともに破棄する（TPL-1503 — 受理する語彙は効果を持つか警告される）。独自アノテーションは当面パラメータ非対応。
• パラメータはアノテーションの名前リストを変えないため、.krs.style のアノテーションセレクタ（@deprecated）や継承には影響しない。

Related TPLs: TPL-1503 — 未認識キー/アノテーションへの @name(key: …) は warn され、黙って受理されない。

@draft — 主張されているが未確認

@draft は、モデルがそう言っているが誰も確認していない記述に付ける印である。手で書いていないモデルのための正直さの層で、karasu-nest は LLM でリポジトリを .krs に reverse する（ADR-1990 決定 4）。どこが推測かを自分で言えない生成モデルは、読み手に全体を同じ確度で信じさせてしまう。

system Payments {
  service Ledger {
    label "Ledger"
    domain Posting
  }
  service Reconciliation @draft(confidence: "low") {
    label "Reconciliation"
    // posting と reconciliation の継ぎ目は判断が割れた
    domain Settlement @draft
  }
}

• 印が単位で、水準は refinement。 裸の @draft で完結する。confidence は任意で low / medium / high を取り、それ以外の文字列は until と同じく opaque な表示専用値として保持する。レビュアーが confidence: "ここは議論が割れた" と書くのは実在の情報であり、弾けばその注記は機械の読めないコメントへ逃げる。

• 文書単位ではなくノード単位。 決定 4 の裏付けとなった spike は、生成された分解の誤りが全体に散らばらず人間でも判断の割れる継ぎ目に集中することを示した。有用なのは「どの継ぎ目が怪しいか」であり、文書単位のスコアはそれを平均で消してしまう。

• ゲートにしない。 karasu は低確度ノードの描画を拒まないし、警告も降格もしない。until が期限ではなく intent であるのと同じく、水準は記録された判断である。

• 消されることが目的。 @draft は人手レビューが削除するものであり、その削除が ADR-1990 決定 4 の人手ラチェット（#2228）そのものになる。だから 1 トークン消すだけで済み、構造の変更を要求しない形にしてある。

• 印が無い = 確認済み、ではない。 karasu はレビュー状態を追跡しない。@draft の無いノードは単に誰も印を付けなかったノードであり、手書きモデルではそれが通常である。生成モデルでは、生成器が付けた印だけがそのモデル自身についての唯一の信号だと考える。どこにも @draft の無い生成モデルは強い主張をしているので、疑ってよい。

@draft は tag でも facet でもなく lifecycle アノテーションである。レビュー過程における記述の状態を表しており、@new / @experimental と同じ register に属し、ユーザー宣言の集合ではなくツール所有の語彙である。

Related TPLs: TPL-1995 — 生成物は不確かな場所で不確かさを述べ、解決した人が印を消せる形にする。TPL-1503 — @draft は名前を受理するのと同じ PR で既定バッジを持つ。TPL-2172 — builtin アノテーション追加の 3 問 gate。

@planned — 設計済み、まだ存在しない

@planned は、設計上そこに置くがまだ実在しない要素に付ける印である。他の lifecycle 状態はいずれも実在を前提にしている: @new は実在する新規追加、@experimental は実在するが不安定、@deprecated は実在していて廃止に向かう。「まだ無い」を言う語彙がどれにも無かった。

system Payments {
  service Ledger {
    label "Ledger"
    domain Posting
  }
  service Reconciliation @planned {
    // 設計レビューで合意済み。コードはまだ無い
    label "Reconciliation"
    domain Settlement
  }
}

• 図を描く瞬間はたいてい判断の瞬間であり、判断が描くのは to-be の姿である。「ここは計画である」と言えないアーキテクチャ記録は、計画を落とす（＝その図を描いた理由ごと失う）か、出荷済みのように描くかのどちらかになる。
• @planned は実在の話、@draft は確度の話。 @planned はまだ作られていないと言う（何であるかについて書き手は確信している）。@draft は誰も確認していないと言う（それが正しいかについて書き手が確信していない）。両立する — @planned @draft なサービスは、LLM が推測してまだ誰もレビューしていない提案である。
• ゲートにしない。 他の lifecycle アノテーションと同じく、karasu は印を記録するだけで、描画を拒んだり降格したり診断から除外したりしない。どの deploy unit も realize していない @planned なサービスは unassigned-service を出す。それはモデルの記述についての真であり、黙らせればこのアノテーションは穴を隠す手段になってしまう。
• 印を消すことが出荷。 @draft と同じく、削除は 1 トークンで済む。

Related TPLs: TPL-2172 — @planned は 3 問 gate（lifecycle register / 「まだ無い」を言う既存表現の不在 / 状態の数え上げに広げない停止規則）を通り、同じ PR でバッジを持つ。TPL-1503 — その効果が ◇ 予定 バッジである。

---

client capability

capability <name> は client が利用許可を要求する デバイス / ブラウザの capability を宣言する。構文は docs/spec/syntax.ja.md を参照。

identifier セットは オープン — 任意の kebab-case 識別子を受け付け、推奨セット外の名前でも警告は出さない。これにより業界固有デバイスや社内専用機能など、ドメイン固有の capability も自由に表現できる。下記の推奨セットは、バリデータやエディタツールが想定する最も典型的なケースを網羅する。

推奨 capability 識別子

グループ	識別子
Web / browser	camera, microphone, geolocation, notification, push, clipboard, webauthn, bluetooth, usb, midi, screen-wake-lock, accelerometer, gyroscope, storage-access
Mobile（追加分）	contacts, calendar, photo-library, face-id, touch-id, background-processing, local-network, bluetooth-le-peripheral
Desktop（追加分）	file-system-access, global-shortcuts, auto-launch, screen-recording
IoT / device（追加分）	gpio, serial, zigbee, lora, nfc, rfid

命名規約

• kebab-case を使用（screen-wake-lock, face-id）。
• 該当する Web Permissions API / W3C 名がある場合はそちらを優先（geolocation, notification）。
• OS 固有の識別子（android.permission.CAMERA 等）は避け、抽象的な機能名を使う。
• 推奨セット外の名前を使う場合は description を添えて、他の読者が何を指すか把握できるようにする。

capability ではないもの

概念	記述する場所
操作に紐づくストレージ（localStorage, indexedDB, keychain）	resource <storageKind> "<name>"
HTTP セッション / 認証クレデンシャル	別語彙。#834 で追跡
実行時の認可（RBAC permission bundle、ライセンス / フィーチャーフラグ）	karasu はモデル化しない — ADR-832 参照。user.role プロパティは actor-archetype ラベルであり authz primitive ではない — ADR-1281 参照

---

語彙の register — boundary / annotation / tag / facet

karasu は「このラベルはどの種類か」を 4 つの register に分離する。tag と annotation の語彙はツール所有であり、ユーザー拡張点は facet 構文（experimental）に一本化される。

Register	構文	語彙	答える問い
アーキタイプ	tag [...]	ツール所有（上記の組み込み表）	この要素はアーキテクチャ上何であるか？（[external]、[index]）
lifecycle	annotation @...	ツール所有（上記の組み込み表）	どの開発状態にあるか？（@deprecated、@new）
view 内グルーピング	boundary	ユーザー宣言 id	この view で peer をどうまとめるか？（syntax.ja.md 参照）
集合所属	facet 構文（experimental）	ユーザー宣言 id	外部で定義されたどの集合に属するか？（PCI スコープ、PII、認証必須）

分解の実例 — PCI 対応と認証を、タグを誤用せずにモデリングする:

関心事の成分	Register	置き場
要素のアーキテクチャ上の役割（検索インデックス、外部ストア）	tag	組み込みタグ — [index]、[external]
「この table はカード会員データを持つ」「この entity は PII」（規制上の所属）	facet	top-level の facet 宣言に対して facets pci / facets pii
「この usecase は認証必須」（ポリシーの適用範囲）	facet	facets requires_auth。ポリシー本文は宣言の description / link に置く
誰が・どのプラン / 条件で呼べるか（ルールの内容）	prose	description + ポリシー文書への link — モデル化しない（ADR-832）

register を分ける理由は、所属のセマンティクスがアーキタイプと異なるからである: database は PCI スコープに入っていようがいまいが database であり、対象 10 要素中 9 要素にしか所属タグが付いていない図は、監査文脈で偽の保証として読まれてしまう。したがって所属はタグの名前空間を借りず、宣言メタデータ（label / description / link）を持つ専用構文を得る。

Related TPLs: TPL-1503 — どの register でも、受理される語彙は効果を持つか警告される必要がある。v1.x の deprecation 診断（tag-not-builtin / annotation-not-builtin）はツール所有 register を状態 (2) に保つ。

---

タグとアノテーションの違い

	タグ	アノテーション
表す内容	アーキテクチャ上の位置・役割	ライフサイクル・開発状態
例	[external]（境界の外）	@deprecated（廃止予定）
スタイルへの影響	.krs.style のタグセレクタで制御	.krs.style のアノテーションセレクタで制御

---

システム自動付与タグ（System-assigned tags）

以下のタグはユーザーが .krs ファイルに記述するものではなく、ツールが自動的に付与する。 .krs.style のタグセレクタで参照・上書きできる。

エッジへの自動タグ

タグ	付与条件	デフォルトスタイル
[implicit]	domain エッジから派生した暗黙のサービス間エッジ	アンバー（#F59E0B）。線種は元のドメインエッジの kind に従う（[async] で破線、[sync] で実線）
[async]	--> で宣言されたエッジ	破線
[sync]	-> で宣言されたエッジ	実線
[cyclic]	循環依存検出時	赤（#EF4444）実線
[write]	usecase→resource の合成エッジで、対象 resource の operations に create / update / delete が含まれる場合	stroke-width: 2、ラベル "W"
[read]	usecase→resource の合成エッジで read-only と分類される場合（write 動詞なし、または operations 省略）	stroke-width: 1.5、ラベル "R"

[implicit] は色（アンバー）で「派生」を表し、線種は同期/非同期の区別に使う。 同一サービスペア間に sync と async の両方のドメインエッジがある場合は、kind ごとに別の暗黙エッジとして派生される。

[write] / [read] は usecase→resource の合成エッジに対してのみ自動付与される。明示的なエッジに手で書かないこと — 構文上はパーサが受け付けるが、意味（対象 resource の operations を write-dominates 分類した結果）は合成エッジに対してしか成立しない。線幅の階層は意図的に read (1.5) < write (2) < cyclic (2.5) の順で、循環依存が最も目立つ軸として残るようにしている。

カスタマイズ例

edge[implicit] {
  color: purple;
  border-style: dotted;
}

---

チーム連絡先コンベンション（owns + link）

組織クエリ（「このサービスのオーナーチームは？」「影響するチームに連絡したい」）を AI チャットで利用するには、 organization ブロックでチームを宣言し、owns でサービス / ドメインを所有させ、team ブロックに連絡先 link を添える。

旧仕様の service / domain に直接書く team "..." プロパティは 削除された（ADR-14 の廃止計画に基づく）。オーナーチームは organization / owns から導出する。

organization Corp {
  team fintech {
    label "Fintechチーム"
    owns Payment
    link "https://slack.com/archives/C..." "Fintechチーム Slack"
    link "https://notion.so/..."          "チームページ"
  }
}

system Shop {
  service Payment { label "決済" }
}

オーナーシップ（owns）

team が owns で所有する service / domain を列挙する。AI はこの所有関係（パース時に構築される ownerIndex）を組織クエリの回答に使う。

チームアノテーションと移行中の主オーナー

team ブロックは、service / domain と同じく { の前にアノテーションを書ける。

organization Corp {
  team legacy @deprecated {
    owns Payment
  }
  team payments @migration_target(from: "legacy") {
    owns Payment
  }
}

@migration_target / @deprecated は組織ビューでチームのバッジとして描画される（システム図のノードバッジと同じ仕組み）。

逆コンウェイの引き継ぎ中は、1 つのノードを複数の team が owns することが正当に起こりうる。ownerIndex は 1:1 なので、主オーナーを 1 つだけ移行優先度で選ぶ — @migration_target（移行先）が勝ち、無印が次、@deprecated（移行元）が負ける。同優先度の場合は最初の宣言を保持する。これは domain の移行共存ルール（上記 Migration annotations で @migration_target ドメインがナビゲーション先になる）と対称である。共同所有そのものは許容される事実で、duplicate-owner-assignment の info 診断で surface される — error にはならない。

Related TPLs: TPL-1583（@migration_target 優先 / first-wins の規則は全 1:1 index で一貫させる）、TPL-1386（共同所有は事実、info register に置く）。

link プロパティ（チーム連絡先）

team ブロックに link "<url>" "<label>" を添える。 ラベルに以下のキーワードが含まれる場合、AI はチーム連絡先として認識する：

キーワード例	用途
Slack	Slack チャンネル
Teams	Microsoft Teams チャンネル
チームページ	Notion や Confluence などのチームページ
Runbook	オンコール・運用手順書

使用例（AI チャットでのクエリ）

モデルに上記の情報を記述しておくと、Chat タブで以下のようなクエリが可能になる：

Q: "Order サービスに依存しているチームを教えて"
A: - Fintechチーム（Payment サービス）
     → https://slack.com/... (Fintechチーム Slack)
   - Platformチーム（Notification サービス）
     → https://slack.com/... (Platformチーム Slack)

Q: "オンボーディングで最初に会うべき人は？"
A: ECommerce（最もエッジが多い）: ECチーム
     → https://notion.so/... (チームページ)