---
title: "Company — Concept・Entity"
description: "Conceptで判断基準を、Entityで会社を構成する実体を共有する。登録・提案の手順、権限、階層とMeetingとの使い分けを説明します。"
---

# Company — Concept・Entity

aachatのteamは、個々の仕事（project）の外側に、会社そのものの共有された文脈を持つ。2つの層がある。Conceptの内部モデル（kind・意味軸・revision・レビュー・リンク・類似ガード）は [concept-registry](/ja/docs/concept-registry) が正本。Entityの内部モデルはこのページが正本。

| 層 | 内容 | WebUIの場所 | 詳細 |
|---|---|---|---|
| **Concept** | チームが合意したVision・Issue・Policy。全agentと人間が判断の前提として読む | teamサイドバー「Concepts」 | [concept-registry](/ja/docs/concept-registry) |
| **Entity** | 会社を実際に構成する継続的な対象の地図。独立して構築・改善・維持・終了を判断できる粒度へ分解する | teamサイドバー「Entity」 | このページ下記 |

## どこで依頼するか

**専用の場所は要らない。** どのprojectのsessionでも通常の依頼と同じようにagentへ頼めるほか、connected repoで動く外側agentにも頼める。session agentはsession authorityを使い、外側agentは同じ投影YAMLを読んで、sign-in中の人間のTeam roleでsubmitする`aachat registry`を使う。

- **読む**: agentはpublish済みのConceptや現在のEntityを読み、判断の前提として使える
- **Conceptの提案**: agentは新しいConceptや既存Conceptの改訂・リンクを**提案（propose）**として登録する。提案はpendingとして残り、**人間がWebUIのConcepts画面でレビューして採否を決める**。承認されて初めてチームの判断基準になる（詳細は [concept-registry](/ja/docs/concept-registry)）
- **Entity**: agentはEntity（通常kindのみ、下記参照）の登録・更新をsessionから直接行える。提案とレビューを経ずその場で反映される点がConceptと異なる

connected repoでは最初に`aachat status`のTeam projectionが`healthy`であることを確認し、2つのindex、必要な個別YAML、該当するMeeting本文を読む。YAMLの保存はlocal staged editにすぎず、`aachat registry submit`が明示的なmutation境界である。serverは人間WebUI操作と同じ認可を適用するため、Owner/Adminはsensitive Entity operationをsubmitでき、Memberは403を受け取る。

## 使い分け

- 目指す状態・継続的な問題・繰り返す判断方針を残したい → **Concept提案**
- 会社を実際に構成する対象と、改善の焦点を明確にしたい → **Entity**

会社の文脈はagentの仕事の入力であり出力でもある。projectで働いたagentが発見をConcept提案として返し、人間が承認すると、次のすべてのsessionがその判断基準の上で働く。これが会社そのものが資産として育つ流れである（[concepts](/ja/docs/concepts) のcompany assetsの流れの会社版）。

## Entityモデル — kind・sensitive境界・階層

Entityは、会社を実際に構成する、識別可能で継続的な対象の地図（Company map）を構成する。何を作り、何を改善し、何を維持または終了するかを具体的にし、改善対象を独立して選べる粒度へ分解する。

**Entityにはproperty・評価・目標・KPI・担当者・進捗を保存しない**。それらはConcept（判断基準）・Project/Session（実行中の仕事）・Message/Shared Document（根拠や詳細）が持つ。

### Entity化の基準

Entityには、単独で構築・改善・維持・終了を判断できる対象を登録する。子Entityは、分けることで改善対象を独立して選べる場合だけ作る。

新規登録前に既存Entityを確認し、既存Entityでは改善対象が粗すぎる場合だけ追加する。目標、仕事、抽象的な責任領域、機能分類、UI / API / Worker / CLI / DB tableなどの実装部品は、それ自体が独立して改善する会社の実体でない限りEntityにしない。

### kind — 9種

| kind | 備考 |
|---|---|
| `organization` | 通常 |
| `offering` | 通常。プロダクト・サービス |
| `media` | 通常。チャネル・媒体 |
| `community` | 通常 |
| `system` | 通常。社内外のシステム |
| `facility` | 通常 |
| `person` | **sensitive** |
| `partner` | **sensitive** |
| `agreement` | **sensitive** |

### sensitive kindの境界（重要）

`person` / `partner` / `agreement` の3種は**agentから登録・変更できない**。agentがこれらの登録・改名・status変更・move・Conceptリンクを試みると、サーバーは次のメッセージで拒否する。

> person / partner / agreement Entity の変更は human の操作が必要です。Project の human member に依頼してください。

agentはsensitive kindを**読むこと**はできる（Company mapの一部として名前・構造を見る）。書き込みができるのは**teamのOwner / Adminの人間だけ**で、一般メンバーの人間も拒否される。読んだ情報からEntityの意味や評価を推測しない — 保存されているのはname・kind・status・parentだけである。

### status — 会社構成上の位置

`planned` / `current` / `retired` は会社構成上の位置だけを表し、仕事の進捗（未着手/進行中/完了）ではない。

- `planned`: 会社構成として計画中
- `current`: 現在の会社構成に存在する
- `retired`: 会社構成として終了した

**階層制約**: activeなEntity（`planned` / `current`）をretiredな親の下に置けない。Entityを`retired`にする前に、activeな子を移動するかretireする必要がある。

### 階層（parent/child）

Entityは木構造を持つ。parentは同じteam内のEntity1つだけ、自己参照・循環・team跨ぎのparentは作れない。付け替えはmove操作で行う。複数の構造上の関わりをparentで表現しない（依存・提供・担当などの未定義の関係をhierarchyやnameに埋め込まない）。

### Concept link

EntityはpublishedなConceptに対して`realizes`（実現する）でリンクできる。v1のrelationはこの1種のみ。archivedや未publishのConceptへはリンクしない。

### 変更履歴

Entityの変更は追記専用のイベントとして残る: `registered`（登録） / `renamed`（改名） / `status_changed`（状態変更） / `moved`（親の変更） / `concept_link_added`（Conceptリンク追加） / `concept_link_removed`（Conceptリンク削除）。

## 最初のEntityを登録する

Team sidebarのEntityを開き、Entityの地図と既存の名前を確認します。たとえば継続的に運営する顧客向けヘルプセンターは`media`の候補です。その公開作業自体はProjectにします。以下はSession agentが登録する例です。`acme`を自分のTeam slug、`acme/help-center`をSessionがcollaborator/adminとして参加し、coverageに含むProjectへ置き換えます。既存の同名ファイルには上書きしないでください。

1. `chat registry refresh --all`で最新のRegistryを取得し、`aachat/teams/acme/entities/_index.yaml`を読みます。indexの`file`から必要な個別ファイルを開きます。
2. 未登録の実体なら、`aachat/teams/acme/entities/help-center.entity.yaml`に次の全文を保存します。

```yaml
format: aachat.team-entity/v1
id: null
name: Help center
kind: media
status: planned
parent: null
realizes: []
```

3. workspaceのルートから、構文、変更内容、送信結果の順に確認します。

```sh
chat registry check aachat/teams/acme/entities/help-center.entity.yaml
chat registry plan aachat/teams/acme/entities/help-center.entity.yaml --project acme/help-center
chat registry submit aachat/teams/acme/entities/help-center.entity.yaml --project acme/help-center
chat registry refresh --all
```

`check`はローカル検証です。`plan`で登録という単一の操作になることを確かめてから`submit`します。正常に反映されると、serverがIDを付けた現在のEntityを取得でき、Entity画面にも表示されます。以後はindexが示すファイルを使い、割り当てられたIDやパスを変えません。`planned`の登録だけでサービスが公開されたとは判断できません。

### 親を変更する、Conceptへつなぐ

既存の`help-center.entity.yaml`をrefreshしてから、`parent`だけを、同じディレクトリに実在する親の相対参照、たとえば`parent: "./customer-services.entity.yaml"`に変えます。上と同じcheck → plan → submit → refreshを実行し、planがmoveだけであること、画面で親子関係が変わったことを確認します。ルートへ戻すには`parent: null`にします。親を動かす際にnameやstatusも一緒に変えず、別々にsubmitします。

Conceptへの関連付けは、publishedな対象ファイルを確認してから、`realizes`に`"../concepts/customer-self-service.concept.yaml"`のような参照を1件追加します。この操作も単独でsubmitします。ファイル名は例なので、必ずindexから実在する名前をコピーしてください。Entityの`kind`は登録後に変更する編集項目ではありません。

## 操作者と権限

| 操作 | Session agent | 人間のTeam Member | 人間のOwner / Admin |
|---|---|---|---|
| 通常kind Entityの登録・変更 | Projectの書込権限とcoverageの範囲で可能 | 可能 | 可能 |
| sensitive Entityの変更 | 不可 | 不可 | 可能 |
| Conceptの新規・改訂・リンク提案 | 提案まで | 提案まで | 提案と採否の判断 |
| Conceptのpublish / decline、リンクの採否 | 不可 | 不可 | 可能 |

人間として接続済みrepoから操作する場合は、`aachat status`でTeam projectionがhealthyであることを確認します。上のEntity例は次のコマンドに置き換えられます。こちらは接続先とファイルからTeamを決め、`--project`、`--team`、`--via`は受け付けません。

```sh
aachat registry check aachat/teams/acme/entities/help-center.entity.yaml
aachat registry plan aachat/teams/acme/entities/help-center.entity.yaml
aachat registry submit aachat/teams/acme/entities/help-center.entity.yaml
aachat registry refresh --all
```

外側agentにこのCLIを使わせる場合も、権限はsign-in中の人間のTeam roleです。Session agentの権限と同一視しないでください。planの成功はserverでの認可成功を保証しません。

## RegistryとMeetingの保存先

Registryのindexは`concepts/_index.yaml`と`entities/_index.yaml`の2つです。Conceptは判断基準、Entityは会社を構成する実体を表します。[Meeting](/ja/docs/meetings)は、議論・決定・フォローアップのMarkdown記録であり、3つ目のRegistryではありません。Project内の作業成果は[Shared Documents](/ja/docs/shared-documents)へ保存します。

SessionのMeetingは`aachat/meetings/`に渡される読み取り専用の開始時点のsnapshotです。RegistryのようなYAML submitでは作成・訂正できません。Team全体で読む内容をMeetingに残し、継続的な判断基準へ昇格させたい部分は根拠を整理してConceptへ提案します。

## 反映できないとき

- `mixed_edit`なら、1ファイルで複数操作を混ぜています。元の内容を保管し、nameだけ、parentだけのように分けます。
- sensitive kindの拒否は、Projectのhuman memberからTeam Owner/Adminへつなぎます。agentの資格情報では回避できません。
- retiredな親やactiveな子のエラーは、上記の階層制約に合わせて移動・終了の順を見直します。
- staleや結果不明への対処は[Registryの復旧手順](/ja/docs/concept-registry)を使います。YAMLを消してもEntityは削除されません。`retired`を使って会社構成からの終了を表します。

生成された`aachat/teams/`と`aachat/.state/`をworkspace repositoryにcommitしないでください。ファイル保存だけではserverへ反映されません。

## 関連ページ

- Conceptの型とライフサイクル: [concept-registry](/ja/docs/concept-registry)
- projectと仕事の文脈: [projects](/ja/docs/projects)
- WebUIの画面全体: [webui](/ja/docs/webui)
- 用語: [glossary](/ja/docs/glossary)