---
title: "Concept Registry — 判断基準の型とライフサイクル"
description: "根拠付きのConceptを提案し、人間のレビューを経て判断基準にする。YAML例、意味軸、改訂、出典、リンクと競合時の復旧を説明します。"
---

# Concept Registry — 判断基準の型とライフサイクル

[Company](/ja/docs/company)の2つのRegistryのうち、Conceptはチームで再利用する判断基準を扱います。このページでは、根拠を付けて提案し、人間がレビューしてpublishedにするまでの操作と、採用後の読み方を説明します。Session agentは`aachat/teams/<team>/concepts/`の投影YAMLを読み、編集後に`chat registry`で提案します。

## kind — Vision・Issue・Policy

Conceptのkindは3種。最初に「どの問いへ答えるConceptか」で選ぶ。kindは内容の役割だけを表し、後述の意味軸（guidance_strength等）はkindから自動では決まらない。

| kind | 答える問い | 用途 |
|---|---|---|
| `vision` | 私たちは、どのような状態を実現したいか | 会社が実現したい未来や状態 |
| `issue` | 現在、何がVisionの実現を妨げているか | 継続して認識すべき重要な問題やギャップ。単一ProjectのtaskやbugはProjectで扱う |
| `policy` | 同じ種類の判断をするとき、何を優先するか | Visionへ向かいIssueへ対処するため、複数の仕事で再利用する判断・行動方針 |

## 意味軸 — 6種

Conceptにはkindとは独立に6つの意味軸がある。新規ConceptのYAMLは `scope`（domain・tags）・`abstraction_level`・`time_horizon`・`guidance_strength`・`maturity` を必須で指定する。`policy = governing` のようなkindとの自動対応はなく、review件数からの推測もしない。

| 軸 | 値 | 意味 |
|---|---|---|
| **guidance_strength**（判断への影響度） | `contextual` / `guiding` / `governing` | `governing` は標準前提として使われ、逸脱するなら理由が要る。`guiding` は原則として沿うが、より強い根拠があれば理由付きで変えられる。`contextual` は関連がある時だけ判断材料にする |
| **maturity**（確定度） | `exploratory` / `provisional` / `established` | `established` は再検討せず前提にできる。`provisional` は影響の大きい判断では出典や最新レビューを確認する。`exploratory` はpublished contextに含めてよいが、確定事実として言い換えない |
| **abstraction_level**（影響範囲） | `foundational` / `directional` / `structural` / `tactical` / `operational` | kindからは推測せず、その判断がどの範囲に影響するかで選ぶ |
| **time_horizon**（時間軸） | `today` / `one_week` / `one_month` / `three_months` / `one_year` / `three_years` / `ten_years` / `enduring` | `enduring` 以外は `expires_at`（期限）が必須。期限切れ後はcurrent published contextに含まれない |
| **domain**（適用領域） | `company` / `organization` / `product` / `marketing` / `sales` | そのConceptが適用される大枠を1つ選ぶ。product・顧客層・施策などteam内の分類は`scope.tags`（最大20件）に付ける |
| **applicability**（有効性） | `active` / `expired` | `expires_at` 由来の派生状態 |

`governing + established` は標準前提。`governing + provisional` は必ず考慮した上でsourceや最新レビューを確認する。`governing + exploratory` は必ず表面化させるが盲従しない。governing同士が矛盾する場合や未解決のconcernがある場合はスコアで勝者を決めず、リンク・出典・レビューを読んで衝突を明示する。

## revisionモデル

Conceptは不変のrevisionの積み重ねである。current revisionを直接書き換えることはなく、変更は常に新しいrevisionの提案として残る。

- revisionの `status` は `pending` / `published` / `declined` の3つ
- **1つのConceptにつきpending revisionは常に1件まで**。既存のpendingがある間は新しいproposalを出せない
- **publish / declineは人間（teamのOwner/Admin）だけが行える**。agentは提案までしかできない
- **declineには理由が必須**。次のsessionはその理由を読み、基準を較正してから再提案するかを判断する
- revision作成後の内容は不変。表現・出典・scope・時間軸を変える場合も新しいrevisionを積む

title は80文字、description は300文字までの入口であり、詳細な根拠は出典（下記）を通じて読む。要約ではなく入口として書く。

## レビュー

published / pendingどちらのrevisionにも `endorse`（賛同）・`concern`（懸念）の2種のレビューを付けられる。`concern` はコメント必須（`endorse` は任意）で、解決ノート付きでresolveできる。published revisionにopenな `concern` があっても前提として読んでよいが、そのConceptに強く依存する判断では `aachat_concept_reviews` でcurrent revisionのコメントを確認し、concernの存在を明示する。review投稿は`aachat_concept_review`を使い、projected `concepts/_index.yaml`は`open_concern_count`だけを持つ。

## Concept間のリンク

Concept同士は8種の有向関係でつながる。

| relation | 意味 |
|---|---|
| `realizes` | 実現する |
| `constrains` | 制約する |
| `addresses` | 対処する |
| `measures` | 測定する |
| `supports` | 支持する |
| `contradicts` | 矛盾する |
| `refines` | 精緻化する |
| `depends_on` | 依存する |

リンクにも `candidate` / `accepted` / `retired` / `rejected` のライフサイクルがある。agentはConcept YAMLのlinkを編集し`chat registry submit`することで `candidate` として提案でき、**acceptして初めてConcept Mapや判断で有効な関係として扱われる。accept / reject / retireは人間（teamのOwner/Admin）だけが行える**。

published Conceptが今後の判断を誤らせる場合、agentは`aachat_concept_removal_propose`でarchive案をReview queueへ送れる。accepted LinkはConcept YAMLから対象Linkを外して`chat registry submit --reason`するとretire案になる。承認されるまでMapは変わらず、承認後もConceptはarchive、Linkはretireとして履歴が残る。

## 提案時の類似ガード（similarity gate）

新規Conceptの`chat registry submit`は登録前に既存Conceptと自動で照合される。類似があると登録されず、`similar_found` として返る。

- **published の類似** — 既に判断基準として存在する。取り下げるか、関係があればリンク提案やレビューに切り替える。継続的なギャップを示す反証なら `issue` + `contradicts` リンクを検討する
- **declined の類似** — 過去に人間が却下している。却下理由（`status_reason`）を読み、同じ提案を繰り返さない
- **pending の類似** — 誰かのrevision proposalがレビュー待ち。重複提案しない
- 権限のない `pending` / `declined` の一致は内容やIDを返さず、`hidden_match_count` だけを返す
- 本当に別物だと判断した場合だけ、返ってきた `proceed_token` を付けて再送すると登録できる

## 出典（source）

提案は出典付きで出す。種類は4つ。

| kind | 指す先 |
|---|---|
| `shared_document` | Shared Document |
| `session` | session |
| `external` | 外部URL |
| `human_decision` | 人間の決定（ノート） |

Session agentの提案では最低1件は`--project`で指定したProjectに属する出典を指定し、他のProject出典も同じTeam内のSession coverageに含める。出典の可用性は `accessible` / `restricted` / `unavailable` の3段階で示され、`restricted` なsourceの中身を推測しない。`unavailable`は参照先を現在解決できない状態で、削除やSession coverageの変更などを確認する。

## アーカイブ / 復元

Conceptはアーカイブ・復元できる。この操作はWebUI/人間の操作であり、agent向けMCP toolには含まれない。archivedなConceptやpublished contentを持たないConceptへ新しくリンクしない。

## Concept Mapでの自由配置

WebUIのConcepts画面はマップビューを持ち、カードの位置（`free_position`）は人間の操作、またはagentがConcept YAMLを編集して`chat registry submit`することで動かせる。配置は共有のsoft contextであり、近いConcept同士の位置は関連を検討する手掛かりにはなるが、source・typed link・意味軸と矛盾する場合はそちらを優先する。配置だけに現れる関係を事実として断定せず、重要そうならリンク提案の候補として扱う。

## 根拠付きのConceptを提案する

まずTeam sidebarのConceptsを開き、既存のConceptとReview queueを確認します。同じ方針やpendingの改訂がある場合は、その内容とレビューを読んで重複を避けます。提案前に[Companyの権限表](/ja/docs/company)を確認してください。以下は、Projectの書込権限とcoverageを持つSession agent向けの手順です。

例では`acme/help-center` Projectの`docs/research/support-friction.md`に、利用者が答えを見つけられなかった事実と改善理由が記録されているものとします。自分の実在するTeam/Project、document kind、doc IDへ置き換え、出典を読んで内容を合わせます。架空の出典をそのままsubmitしないでください。

`chat registry refresh --all`を実行して`concepts/_index.yaml`を読んだ後、新しい`aachat/teams/acme/concepts/customer-self-service.concept.yaml`へ次の全文を保存します。

```yaml
format: aachat.team-concept/v1
id: null
kind: policy
title: Make answers easy to find
description: Prefer clear, searchable help before adding support channels.
scope:
  domain: product
  tags:
    - support
abstraction_level: directional
time_horizon: enduring
expires_at: null
guidance_strength: guiding
maturity: provisional
position: null
sources:
  - kind: shared_document
    project: "acme/help-center"
    document_kind: research
    doc_id: support-friction
restricted_source_count: 0
links: []
```

`id: null`は新規登録を表します。新規Conceptには`position: null`と`links: []`が必要です。位置とリンクはpublish後に別の操作で変更します。`enduring`以外の時間軸なら、将来の有効期限を引用符付きのRFC3339日時で指定します。入力するsourceは1〜20件で、`restricted_source_count`は新規では0です。

workspaceルートから次を順に実行します。

```sh
chat registry check aachat/teams/acme/concepts/customer-self-service.concept.yaml
chat registry plan aachat/teams/acme/concepts/customer-self-service.concept.yaml --project acme/help-center
chat registry submit aachat/teams/acme/concepts/customer-self-service.concept.yaml --project acme/help-center
chat registry refresh --all
```

`check`が検証するのはローカルYAMLで、出典の存在やserver権限の保証ではありません。`plan`が意図した単一操作であることを確認します。`submit`の提案受付後、Team Owner/AdminがConceptsのReview queueで出典と差分を読み、publishまたは理由付きdeclineを判断します。受付は採用ではありません。

投影YAMLはpublished currentだけを表します。提案後に旧本文へ戻ることや、新規pendingの本文がindexに現れないことを理由に再提案しないでください。結果のreceiptとReview queueを確認します。人間のpublish後にrefreshして、現在の本文が採用された内容になったことを確認します。

### 改訂と位置変更を分ける

既存Conceptはindexの`file`が示すファイルをrefreshして編集します。たとえば説明を改善するときは`description`を変更し、他の必須フィールドと既存IDを保ったまま上のcheck → plan → submitを使います。意味・出典・scope等の改訂は新しいpending revisionになります。既にpendingがあれば先にその採否を確認します。

位置だけを変えるときは、既存ファイルの`position: null`または現在のpositionを次に置き換え、それ以外のフィールドを変えません。この抜粋だけをファイル全体として保存しないでください。

```yaml
position:
  x: 240.0
  y: 120.0
```

同じcheck → plan → submit → refreshを実行します。positionだけの変更は直接反映され、Conceptの意味を承認したことにはなりません。座標は有限値で各軸-1000000〜1000000です。意味と位置を同時に編集すると`mixed_edit`になるため、分けて送信します。

### 人間として接続済みrepoから提案する

Team projectionが`aachat status`でhealthyであることを確認してから、同じYAMLに対して次を使います。

```sh
aachat registry check aachat/teams/acme/concepts/customer-self-service.concept.yaml
aachat registry plan aachat/teams/acme/concepts/customer-self-service.concept.yaml
aachat registry submit aachat/teams/acme/concepts/customer-self-service.concept.yaml
aachat registry refresh --all
```

このCLIには`--project`や`--proceed-token`はありません。Teamはrepo connectionから決まり、sourceに書いたProjectへのアクセスはserverが確認します。Owner/Adminがsubmitしても意味の変更は提案であり、publishは別の判断です。外側CLIでpositionをnullへクリアする操作は未対応です。また、accepted Linkの削除はagentのretire提案とは異なり、人間のretire操作としてOwner/Adminと`--reason`が必要です。

## 出典とレビューを実際に読む

Concept MapのカードのメニューからSourcesを開き、出典を辿ります。カードを開いた詳細では、現在の内容、レビュー、Historyを確認できます。Review queueのpending内容と、現在publishedの内容を区別して読みます。たとえば上の方針がpublishedでも、「検索しにくい言語が残る」というopen concernがあるなら、全利用者が自己解決できるという事実には言い換えません。

`restricted`は閲覧権限がない出典です。権限を持つ人間に必要な根拠の確認を依頼し、内容を推測しません。`unavailable`は参照先を現在解決できない状態です。削除やSession coverageの変更を確認し、読める根拠への改訂を検討します。WebUIでの改訂はすべての出典へアクセスできることが必要です。Session agentのYAML改訂では`restricted_source_count`を保持し、読める出典だけを編集します。serverは読めない出典を継承し、合計20件までの上限を確認します。indexの`open_concern_count`だけでは懸念の内容は分からないので、コメントまで読みます。期限切れは採用履歴の削除ではなく、現在の判断文脈から外れる状態です。

Conceptの出典モデルとRegistry YAMLの`sources`が受け付けるのは`shared_document`、`session`、`external`、`human_decision`の4種類で、`project_message`をYAMLへ書くことはできません。既存の投影で表示されない出典を自分で再構成せず、WebUIで確認してください。Session agentの提案は`external`や`human_decision`だけではProject出典の条件を満たしません。

## YAMLの制約と復旧

UTF-8・LF改行を使い、未知のキー、重複キー、タブ、anchor、alias、merge key、explicit tagを使いません。UUID、日時、ファイル参照は引用符付きで保ちます。新規は意味のあるASCII小文字slugと`id: null`を使い、既存のIDや割り当てパスを改名しません。`_index.yaml`は生成物なので編集しません。1回のsubmitは1ファイル・1操作です。保存だけではserver mutationにならず、ファイル削除もConceptのarchiveにはなりません。

| 状況 | 次の操作 |
|---|---|
| `mixed_edit` | 意味、位置、各リンクを分け、1操作ずつplanする |
| `similar_found` | 類似内容と却下理由を読む。異なる提案と判断したSession agentだけ、同じsubmitに`--proceed-token`を追加する |
| stale / OCC conflict | ローカル案を退避し、server currentを取得して変更を再適用する。自動mergeはない |
| `outcome_unknown` | ファイルを変えず、CLIが返した同じsubmit commandを再実行する。結果照合が終わるまで別のsubmitを始めない |
| projectionがunavailable / revoked / stopped | 残ったファイルをcurrentとして使わず、表示されたblockerに従ってruntimeまたはTeam accessを復旧する |

類似ガードの再送は、返された実際のtokenを使います。

```sh
chat registry submit aachat/teams/acme/concepts/customer-self-service.concept.yaml --project acme/help-center --proceed-token '<returned-proceed-token>'
```

競合時だけ、必要なローカル案を別の場所へ保管してから、対象ファイルを明示して破棄します。

```sh
chat registry refresh aachat/teams/acme/concepts/customer-self-service.concept.yaml --discard-local
```

このコマンドはローカル変更を捨てます。currentを読み直して必要な差分だけを再適用し、check → plan → submitへ戻ります。接続済みrepoなら`chat`を`aachat`に置き換えます。通常のrefreshはdirtyファイルを勝手に上書きしません。結果不明の再送ではCLIが保持するinflight情報から先にserverの結果を照合するため、そのファイルや内部stateを編集・削除しないでください。

## 関連ページ

- 2層の概要と依頼の仕方: [company](/ja/docs/company)
- Entityの型とライフサイクル: [company](/ja/docs/company)
- 用語: [glossary](/ja/docs/glossary)