> ## Documentation Index
> Fetch the complete documentation index at: https://docs.starfort.io/llms.txt
> Use this file to discover all available pages before exploring further.

# 組織階層

> Starfortがテナントをどのように構造化するか: Company › Organization › Project と、Guardianおよびキーがプロジェクトに紐づく仕組みです。

Starfortは、テナントのリソースを4階層の構造のもとに整理し、その最上位（**Global**）にはプラットフォームそのものが位置します。

```
Global              ← システム全体
└── Company         ← 会社 / 顧客テナント
    └── Organization
        └── Project ← Guardian、API キー / Agent User はここに存在する
```

<CardGroup cols={3}>
  <Card title="Company" icon="building">
    最上位の**テナント**です。**Control Profile**、**Agent User**、Desktop Agentの**Access Key**、クォータなど、全社的な設定を保持します。
  </Card>

  <Card title="Organization" icon="building-user">
    チームや事業部門のための、Company内のグループです。
  </Card>

  <Card title="Project" icon="cube">
    **Guardian**を登録し、認証情報を管理する場所です。各プロジェクトには固定の**タイプ**があります。
  </Card>
</CardGroup>

**Global**はCompanyの上位に位置し、プラットフォーム運用者（System Admin）が管理する、システム全体に及ぶスコープであり、個々の会社のデータからは分離されています。

## AccountとMulti-Company

**Account**は、コンソールにログインする認証主体です — トラフィックが統制対象となる*Agent User*や*API End User*とは区別されます。1つのAccountは**複数のCompanyに同時に**所属できます（Multi-Company）。ログイン時に会社を選んでコンテキストを切り替えます。アイデンティティと権限は分離されています — Accountが認証を行いますが、その権限は`(Account, Company)`コンテキストで解決され、1つのコンテキストが複数のロールを保持できます。

テナントは分離されています。ポリシー、ログ、権限のデータが、CompanyやProjectの境界を越えて公開されることはありません。

## プロジェクトタイプ

プロジェクトを作成する際にそのタイプを選択します。タイプは**後から変更できません**。

* **API** — 自社アプリケーションに[Guard API](/ja/v1.2/api/quickstart)を組み込むためのものです。**API キー**を管理します。
* **Desktop Agent** — Windowsの[Desktop Agent](/ja/v1.2/desktop/how-it-works)を通じて、従業員のAIツール利用を保護するためのものです。**Control Profile**と**Agent User**を通じて管理されます。

## ロール

アクセスは**RBAC**によって統制されます。**Role**は**IAM Policy**（システムアクセスのルール）をまとめたものであり、Accountにロールが付与されます。標準のロールは次のとおりです。

| ロール        | 権限                          |
| ---------- | --------------------------- |
| **Owner**  | Companyレベルの設定を含む、すべての制御。    |
| **Admin**  | 組織、プロジェクト、Guardian、ポリシーの管理。 |
| **Member** | 割り当てられたプロジェクト内での作業。         |
| **Viewer** | 読み取り専用。                     |

OrganizationとProjectは、4つのロールすべてを自動作成します。**Company**は**Owner**と**Viewer**のみを自動作成します。IAM Policyを組み合わせて**Custom Role**を定義することもできます。

<Note>
  **IAM Policy ≠ Guard Policy。** *IAM Policy*は、誰がシステムにアクセスできるかを統制します（RBAC、Account → Role）。[*Guard Policy*](/ja/v1.2/concepts/guard-policy)は、コンテンツを統制します（Project Guardian → 入力/出力のフィルタリング）。どちらもConsoleで管理されますが、目的は異なります。
</Note>

## 階層に従うガバナンス制御

### Kill Switch（3階層）

**Kill Switch**は、**Organization**、**Project**、**Project Guardian**という3つのリソース階層における緊急用の切り替えスイッチであり、いずれの階層も独立して切り替えられます。有効化すると、その階層配下のすべてのProject Guardianを停止する一方で、**各リソース自身の状態は保持**します。解除すると、保持された状態から再開します。注意点:

* **Companyには独自のKill Switchがありません** — 代わりに、上位の権限がその配下のすべてのリソースをトリガーできます。
* これはAPI Keyの状態（Active / Inactive / Revoked）とは**直交**します。Bastionはリクエストごとに両方を検証します。
* マスターである**System Guardian**は、Kill Switchの対象外です。

[Kill Switchの使用](/ja/v1.2/admin/kill-switch)を参照してください。

### Audit Logとモニタリング

* **Audit Log**は、**ガバナンスの変更のみ** — 管理上/運用上の操作 — を記録します。ランタイムのリクエスト/レスポンスのトレース、システムの自動イベント（ハートビート、ヘルスチェック）、単純な読み取り、拒否された試行は記録*しません*。Audit Logには2つの階層があります。**Company** Audit Logと、`/aim` **System** Audit Logです。これは改ざん不可能です。[監査ログ](/ja/v1.2/admin/audit-log)を参照してください。
* **モニタリング**（Opticon）は、プロジェクトごとのランタイムの**トレース** — Audit Logとは別の記録レイヤー — を表示します。[トレースのモニタリング](/ja/v1.2/admin/monitoring-opticon)を参照してください。

<Note>
  初めての方は、[Account Admin向けクイックスタート](/ja/v1.2/admin/quickstart)で、Company、Organization、Project、Guardian、キーの作成までを一通り順を追って説明しています。
</Note>