管理者ガイド

InfiniCloud® AI 管理者ガイド

InfiniCloud® AI の Web インターフェイスを使って、ユーザー・グループ・ロール（権限）・知能ドメインを運用する管理者向けガイドです。InfiniCloud AIのブラウザから操作できる管理機能にフォーカスしています。

1. このドキュメントについて

1.1 対象読者

InfiniCloud® AIのWeb画面にログインし、利用ユーザーや知能ドメイン（RAG対象）を運用する立場の方
情報システム部門、AIプロジェクトの管理担当者
将来的にRBAC設計やテナント設計を見直す方

1.2 前提

InfiniCloud® AIが起動済みであり、管理用アカウント（管理者ロール）が付与されていること
基本的な画面操作（チャットの使い方など）は「InfiniCloud® AI 利用者向けマニュアル」を一読、済みであること
本ドキュメントに記載されない内容は、下記の通りです。
- sshログインしてroot権限で操作するシステム設定(config.ini)など。
- このドキュメントでは上記管理者のことを「サーバ管理者」と記します。

2. 画面構成と管理者メニュー

2.1 基本画面

InfiniCloud® AIにログインすると、チャット画面が表示されます。

左側：スレッド一覧
右側：チャット本文
下部：メッセージ入力欄
左下：設定（オプション）ボタン

管理者が主に操作するのは、左下の「設定⚙」ボタンから開く管理モーダルです。

2.2 管理モーダルで扱う主な機能

権限に応じて、次のようなタブが表示されます。

知能ドメイン管理
知識の投入
知識情報の編集
ユーザーとグループ管理
ロールと権限管理
テナント管理
タスクログ
インフォメーション

ユーザーにどのタブが見えるか。

操作できるかは、RBAC（ロール／権限キー）とドメインACLで決まります。

テナント管理の有効無効に関しては、サーバ管理者によりconfig.iniで設定されています。

3. 認証とステップアップ認証

3.1 ログイン

ログイン画面でユーザー名とパスワードを入力
メールによるワンタイムコード（有効な場合）を入力
認証に成功すると、ユーザーに関連する権限セットがクライアントに渡されます

3.2 ステップアップ認証（重要操作の再認証）

ユーザー／グループ／ロール／テナントなど、システム全体に影響する操作については、ログイン済みであっても「パスワード再入力」などのステップアップ認証を要求できます。

概念としてはDynamic RBACに近いもので、サーバのAPI層で動的にロールを昇格する実装になっています。しかしWeb UIの場合は、サーバ側でRoleが昇格、降格が行われると、UIの途中で操作が不能になったりするケースがあるため、利便性を保つため、関係する箇所で先に昇格処理(ステップアップ認証)が行われるようになっています。

要求対象の例
- ユーザーの凍結・削除
- ロールの変更・削除
- テナントの作成・削除
管理ポリシに応じて、要求の有無を設定ファイル側で制御します

本設定の有効無効に関しては、サーバ管理者によりconfig.iniで設定されています。

4. 権限モデルの全体像

InfiniCloud® AI の権限は、次の 2 層で構成されています。

機能としてのDynamic RBAC（ロール／権限キー）
- 「どの設定画面を開けるか」「どの種類の操作ができるか」を決める
- 例：ユーザー管理画面の表示、ロール作成、ログ削除など
知能ドメイン毎のACL（各知能ドメイン単位のアクセス制御）
- 「どのドメインに対して、どこまで触れるか」を決める
- 例：知能ドメインに対して、利用可能か、知識追加まで可能か、ACL 変更まで可能かなどを決めるもの。

5. 権限キーと UI でできること

この章では、代表的な「権限キー」と、その権限を持つと Web UI 上で何ができるのかを整理します。

※ 権限キー名は実装上のキー名称をもとにした例です。運用環境に合わせて読み替えてください。

5.1 設定画面・ドメイン操作関連

権限キー（例）	できること（UI 上の操作）
options.view	右上の「設定」ボタンで管理モーダルを開ける。ゲストユーザはこの機能が無効になっています。たとえばDefault Userのロールからこの機能を落とすと、新規ユーザ作成後の一般ユーザが、オプション画面をが開けなくなります。
domains.create	新しい知能ドメインを作成できる
domains.transfer_owner	知能ドメインの所有者（owner）を別ユーザーに変更できる
domains.delete	知能ドメインを削除できる（ACL / 依存関係に応じて制約あり）

作成した知能ドメインのアクセス権限は、それ毎に先に挙げたACLを設定します。

5.2 タスクログ関連

権限キー（例）	できること
logs.view.list	「タスクログ」タブが表示され、ジョブのログ一覧を閲覧できる
logs.view.detail	各ジョブの詳細ログを参照できる
logs.delete	完了済みタスクのログを削除できる ※監査ログは、デフォルトでは、サーバ管理者のみが参照できるディレクトリに保存されています。

5.3 ユーザー／グループ管理関連

権限キー（例）	できること
users.view	「ユーザーとグループ管理」タブを開き、一覧を閲覧できる
users.manage.add_to_group	ユーザーをグループに追加・削除できる
users.manage.freeze	ユーザーアカウントを凍結（ログイン不可）にできる
users.manage.delete	ユーザーアカウントを削除できる
groups.create	新しいグループを作成できる
groups.edit	グループ名・説明・所属ユーザーを変更できる
groups.assign_role	グループにロールを割り当て／解除できる

5.4 ロール・権限管理関連

権限キー（例）	できること
role.view	「ロールと権限管理」タブを開き、既存ロールの定義を閲覧できる
role.create	新しいロールを作成し、権限キーの組み合わせを定義できる
role.edit	既存のロールの説明や権限セットを編集できる（システムロール除く）
role.delete	カスタムロールを削除できる（利用状況により制約あり）

5.5 テナント管理関連（導入形態による）

権限キー（例）	できること
tenant.view	「テナント管理」タブを開き、テナント一覧を閲覧できる
tenant.create	新しいテナントと、その配下のルートグループを作成できる
tenant.edit	テナント名・説明などを変更できる
tenant.delete	テナントを削除できる（利用状況により制約あり）

6. ロール（役割）と想定ユースケース

ロールは、「よく使う権限キーのセット」に名前を付けて管理しやすくする仕組みです。

6.1 代表的なロール例

ロール名	主な権限のイメージ	想定する利用者
admin	ほぼ全ての権限キーを含む	システム全体の管理者。ユーザー／グループ／ロール／テナント／ドメインを統括 ※削除はできません
domain_tutor	ドメイン作成・ACL 調整・JSONL 編集・ログ閲覧など	部門ごとの「知能ドメイン」運用担当者
user	設定画面の閲覧（限定的）、ドメイン利用、ログ参照など	一般ユーザー（社内利用者全般） ※アカウント作成直後のユーザのグループが、このロールを持ちます。
viewer	ログ閲覧、ユーザー／グループの参照のみ	監査担当、情報システム部門の閲覧用アカウント

admin ロールはシステムロールとして、権限セットが固定されます。通常、編集や削除はできません。

6.2 ロール運用の考え方

まず、ロールとグループは別の概念です。

ロールは、権限キーを持つセットであり、ロールに権限キーが与えられています。例えばadminはグループではなく、管理能力を持つロールということになります。

実際に管理能力を持つadminロールが機能を発揮するためには、ユーザーグループAdminに対して、ロールadminがバインドされます。

そして、ユーザーはグループに属すため、結果的に、ユーザに管理権限を持つという枠組みです。

この枠組みにより、想定している権限セットと、ユーザーのグループを割ることができ、フレキシブルにRBACを設定することが可能になっています。

7. ユーザー & グループ管理のベストプラクティス

7.1 推奨グループ構成

システム管理者グループ
- グループ名例：`Admin`
- 付与ロール：`admin`
- メンバーは最小限（2～3 名程度）に絞る
ドメイン運用担当グループ
- 例：`HRPC Domain Tutors`, `Finance Domain Tutors`
- 付与ロール：`domain_tutor`
- 各知能ドメインの ACL で、このグループに `admin` レベルを与える
一般ユーザーグループ
- 例：`All Employees`
- 付与ロール：`user`
- 利用可能なドメインには、`use` または `view` レベルを付与する
監査／閲覧専用グループ
- 例：`Auditors`
- 付与ロール：`viewer` ＋必要な `logs.view.*` など
- 設定を変更させずにログを確認させたい場合に利用

7.2 よくあるつまずきと対策

つまずきパターン	問題点	対策
個人ユーザーに直接ロール／権限を付与	どこに権限が付いているか把握しづらい	まずグループを設計し、権限はグループに付与する
`admin` ロールの乱用	誤操作時の影響が大きい	`Admin` グループを限定し、通常運用は `domain_tutor` などへ委譲
グループ構成が部署構造と乖離	どのドメインを誰が管理するか曖昧	部門／プロジェクト単位のグループを用意し、ドメイン ACL も合わせて設計

8. 知能ドメインと ACL（アクセス制御）

8.1 ドメインとは

「ドメイン」は、RAG 用の知識や、ファインチューニング対象データをひとまとまりにした単位です。

例：`製品マニュアル`, `社内規程`, `FAQ`, `特定顧客プロジェクト` など
ドメインごとに異なる ACL を設定し、「誰がどこまで触れるか」を制御します

8.2 ACL のレベル

各ドメインには、次の 4 段階の ACL レベルがあります。

`use`
- チャットで RAG の参照先として利用できる（質問にそのドメインが使われる）
`view`
- `use` に加え、ドメインの概要（件数・更新状況など）を閲覧できる
`edit`
- `view` に加え、URL／ファイルの追加、JSONL の編集・削除などができる
`admin`
- ACL の変更、所有者変更、ドメイン削除などが行える

ACL は次の 4 つの対象に対して設定できます。

`owner`（ドメイン所有者）
`groups`（グループ単位）
`users`（特定ユーザー単位）
`guest`（その他すべてのログインユーザー）

8.3 ACL と RBAC の組み合わせ

RBAC で `options.view` や `domains.*` を持っていても、
そのドメインで `use` 以上の ACL が付与されていなければ実際の操作はできません
逆に、ドメイン ACL で `admin` を与えても、
そもそも設定画面を開く権限（例：`options.view`）がなければ UI が表示されません

9. JSONL データ管理とベクトルストア

9.1 JSONL データ管理タブ

「JSONL データ管理」では、ドメインごとに次の操作が可能です（ACL と RBAC に依存）。

JSONL レコードの検索・一覧表示
レコード内容の閲覧・編集・ソフト削除
複数行選択による一括削除
ドメイン単位での JSONL エクスポート（バックアップ・移行用途）
ベクトルストア（Chroma 等）との同期

9.2 管理者視点でのポイント

JSONL は **「RAG の元データ」**、ベクトルストアは **「検索用インデックス」** と捉える
大規模な削除や修正を行った場合は、必ず「同期」操作を実行し、
ベクトルストアを最新状態に保つ
重要なドメインは、定期的に JSONL をエクスポートしておくと
別環境への移行や再学習時に便利です

10. タスクログ（ジョブログ）の管理

10.1 タスクログ一覧

「タスクログ」タブでは、以下の情報を確認できます。

知識のインポートや変換ジョブの履歴
Fine-tune（LoRA 学習）のジョブ履歴（対応バージョンの場合）
各ジョブの状態（実行中／成功／失敗）
実行開始／終了時刻、対象ドメイン等

10.2 ログの詳細と削除

`logs.view.detail` を持つユーザーは、ジョブごとの詳細ログを開き、
エラー理由や処理経過を確認できます
`logs.delete` を持つユーザーは、完了したジョブのログを削除できます

監査用途のログが別に保全される前提で、タスクログは「一定期間で整理する」運用も可能です。

11. テナント管理（導入形態による）

11.1 テナントとは

マルチテナント運用の場合、テナントは「組織の大枠」を表します。

例：`本社`, `子会社A`, `グループ会社B` など
テナントごとにルートグループを持ち、その配下に部門／プロジェクトごとのグループを作成します

11.2 テナント管理タブでできること

テナントの新規作成・名称変更・説明の編集
テナント配下のルートグループの確認
利用されていないテナントの削除（制約あり）

単一組織内での利用のみを想定する場合は、テナントを 1 つに固定して運用することも可能です。

12. ステップアップ認証の運用ポリシ

管理者としては、次のような方針でステップアップ認証の利用を検討してください。

**必ずステップアップを要求したい操作**
- ユーザー凍結・削除
- ロール定義の変更
- テナント作成・削除
**通常認証のみでよい操作**
- 一般ユーザーによる RAG 利用
- 自分が owner のドメインへの軽微な編集　など

システム設定（バックエンド側）のフラグと組み合わせて、「誤操作時の影響」と「操作頻度」のバランスを取るのがポイントです。

13. 運用チェックリスト

13.1 初期セットアップ時

初期ユーザー(初めて作成するユーザー)
- 初期ユーザー作成時に「Admin」グループを持った形でユーザー作成される。
- 「Admin」グループは、admin ロールが付与されているため、初期ユーザは全ての権限を利用することが出来る。
- Adminグループにいるユーザは、他のユーザーをAdminグループに入れることができる。
- 最後の一人にAdminグループユーザは、無効化できない。
一般ユーザー(全てのユーザ)のデフォルトグループ
- Default Userというグループに属している。
- Default Userは、userというロールが割り当てられている。
- userというデフォルトロールを切り替えることで、アクセス初期状態のユーザーにどのような権限を与えることができるのかが設定できる。
Tutor用の`Domain Tutors` グループが作成されている

13.2 知能ドメインのACL 設計

各知能ドメインに対してowner が明確にしておくこと
groups に適切な `利用(use)/閲覧(view)/編集(edit)/管理(admin)` を割り当てていること
guest に不要な権限を付けていない（原則 `利用(use)` 未満）こと

13.3 RBAC 見直し時

`options.view` を持つユーザーが多すぎないか確認すること
`users.manage.*` や `role.*` を持つユーザーが適切か確認すること
ステップアップ認証が必要な操作と設定が一致していること

14. デフォルトのロールと権限キー対応表

実際の環境に合わせて、ロール名・権限キーは適宜読み替えてください。

ロール名	主な権限キー例
admin	`options.view`, `domains.`, `logs.view.`, `logs.delete`, `users.view`, `users.manage.`, `groups.`, `role.`, `tenant.` などほぼ全て
domain_tutor	`options.view`, `domains.create`, `domains.transfer_owner`, `logs.view.list`, `logs.view.detail`, `users.view`, `groups.assign_role`, `role.view`, `role.create`, `role.edit`, `role.delete` など
user	`options.view`, `logs.view.list`, `logs.view.detail`, `users.view` など、閲覧中心
viewer	`logs.view.list`, `logs.view.detail`, `users.view` など、参照専用

この表をベースに、自社のポリシに合わせたロール定義・命名・説明文を追加していくことで、ユーザーに「自分のアカウントで何ができるのか」をわかりやすく伝えることができます。