ロールと認可
ユーザーはそれぞれロールを持ち、実行できる操作がそれで決まります。ロール同士に上下関係はありません。例外が一つだけあります。スーパー管理者はロールによるチェックをすべて素通りします。そのため、ほかのどのロールとも排他です。あるユーザーはスーパー管理者であるか、残る 5 つのロールの組み合わせを持つかのどちらかで、両方ということはありません。この素通りには意図的な例外が 2 か所あり、いずれも所有者レベルのチェックです。どちらも後述のセッションへのアクセスの表に出てきます。ロールを一つも持たないユーザーも有効です。自分のアカウント(アバター)は管理できますが、それ以外は何もできません。
実効ロール
ロールがユーザーに届く経路は 2 つあり、認可のチェックはすべてその和集合、つまりユーザーの実効ロールを見ます。
グループ経由でしか持っていないロールも、直接付与されたものとまったく同じ価値があります。同じゲートを通過し、承認者として指名できるようになり、なりすましからも同じように守られます。キャッシュは一切なく、和集合はリクエストのたびに解決するので、グループへの追加や削除は再同期の手順なしにその場で効きます。
グループ自体を宛先にすることもできます。承認は個人ではなくグループに送れて、approver を持つメンバーなら誰でも決裁できます。
グループが super_admin を付与することはできません。UI に選択肢が出ず、API も拒否し(HTTP 422)、データベースの CHECK 制約が両方を裏打ちしています。スーパー管理者はプラットフォーム全体を対象とし、グループはちょうど 1 つのテナントに属するので、スーパー管理者がグループのメンバーになることもありません。
ロール一覧
| ロール | 権限 |
|---|---|
super_admin | すべて(ロールによるゲートをすべて素通りします。ただし後述の表にある、指名された承認者のチェック 2 つは素通りしません) |
admin | ユーザーの CRUD、シークレットの CRUD、ワークフロー実行の削除、そして自テナント内のすべてのワークフロー実行とそのタスク、チャット履歴、すべての承認への読み取り(後述のワークフロー実行とそのワークフローセッションを参照。削除を除けば、管理者は実行のエージェントを動かしたり、タスクのステータスを変えたり、承認を決裁したりはできません) |
developer | シークレットの CRUD、MCP サーバーの CRUD、ツールモックの CRUD、エージェントスキルの CRUD、ワークフローの生成・編集(AI が生成した生成プロンプトの再生成を含みます。ただしこのフィールドを直接編集できるのはスーパー管理者だけです)、タスクテンプレートの CRUD、設計セッションのチャットを動かすこと、ワークフローの実行(POST /workflows/{id}/execute。公開前テストのため draft のワークフローと、modified のワークフローの未公開の編集内容も実行できます)。公開と無効化は含まれません。それは reviewer の仕事です |
reviewer | ワークフローの公開と無効化。developer がもう行わなくなった、この 2 つの操作です。ワークフローに対する developer と同じ読み取り範囲を共有します。draft のワークフロー、modified のワークフローの未公開の編集内容、設計セッションのチャット履歴は、レビュアーにも開発者と同じように見えます。ワークフローやそのタスクテンプレートの編集、設計セッションを動かすことはできません |
requester | 公開済み(および modified)のワークフローの実行(POST /workflows/{id}/execute)。常に最後に公開した設計に対して実行されます |
approver | ワークフロー承認の指名先になれること(個人として、または承認の宛先となったグループのメンバーとして)と、自分宛の承認を決裁すること |
初期投入される root ユーザーは super_admin を持ち、プラットフォーム全体を対象とします(テナントなし)。Default テナントに初期投入される admin ユーザーは admin を持ち、そのテナントに閉じます。それ以外のユーザーはロールなしから始まります。
ロールが制限するもの
読み取りは開いたままです。 ロールで制限されるのは書き込みとワークフロー実行と承認だけで、認証済みのユーザーなら誰でもコレクションを GET できます(名前の解決、承認者の選択、ワークフローの一覧表示に UI が必要とするためです)。シークレットの値は、ロールに関係なく API から返りません。
ワークフローの Prompt と Generated prompt(実行に渡される指示)が見えるのは、Admin、Developer、Reviewer、Super Admin だけです。それ以外の人がワークフローやその実行を読むと、これらのフィールドは空になっています。ワークフローの版の履歴も同じロールに限られ、Requester や Approver は開けません。ワークフローの Description は、ワークフローを開ける人なら誰でも見られます。
唯一の例外はロールではありません。アクセス制御タグの付いたレコードは、自分のグループが合わせてそのタグをすべて持つユーザー、そして Admin と Super Admin(両者ともこれを素通りします)にしか見えません。それ以外の人には、レコードもその存在の手がかりも見えません。
ロールの割り当てはユーザーの管理ページから、まとめて割り当てる場合はユーザーグループのページから行います。super_admin を付与・剥奪できるのはスーパー管理者だけです。拒否されたリクエストは HTTP 403(FORBIDDEN)を返します。
UI が隠すもの
管理画面はロールで許されない操作やナビゲーション項目を隠すので、拒否されるリクエストはふつう「断られる」より前に「たどり着けない」ようになっています。
| 画面 | ロールがないときの見え方 |
|---|---|
| 一覧ページ | 追加ボタンと行ごとの操作列が消えます。削除と、MCP サーバーの「レジストリを見る」(作成フォームに進むだけの導線です)がそれにあたります |
| 詳細ページ | 読み取り専用で描画されます。各フィールドは入力欄ではなく沈んだ表示の値になり、保存と削除は消え、キャンセルは戻るに変わります |
作成フォーム(/<section>/new) | アクセス拒否の画面になります。そこへ導く追加ボタンはすでに隠れているので、たどり着くのは直リンクの場合だけです |
読み取りが開いているため、書き込み権限のない人が詳細ページを開くこともあります。エージェントスキル、MCP サーバー、ツールモック、シークレット、テナント、ユーザー、ワークフロー、タスクテンプレートは、いずれも上の読み取り専用の描画になります。シークレットのエントリはキーだけが並び(値はそもそも返りません)、ユーザーのパスワード欄は完全に省かれます。テナントの name やユーザーの username のように誰にとっても変更できないフィールドは、ロールに関係なく同じ見た目になります。作成フォームには読み取り専用の姿がないので、フォームではなく画面のほうを返します。
セッションへのアクセス
A2Flow のチャットには 2 種類あり、ゲートの掛け方が違います。
- 設計セッションはワークフローを設計するチャットです。アクセスはロールで決まります。設計は開発者の仕事なので、そのテナントの開発者どうしで共有し、動かせます。レビュアーも、公開前に設計を確認するために読むことはできますが、動かすことはできません。
- ワークフローセッションは 1 回の実行が行われるチャットです。アクセスは参加関係で決まります。実行を始めた人と、その中で何かの承認を頼まれた人が、ロールに関係なく共有します。
設計セッション
ワークフローの設計チャット(GET /workflows/{id}/messages、POST /workflows/{id}/agent)は、レコードごとの参加関係ではなくロールで共有されます。チームで設計を練り上げられるようにするためです。
| 対象 | 履歴を読む | エージェントを動かす |
|---|---|---|
| そのテナントの開発者なら誰でも | ✅ | ✅ |
| そのテナントのレビュアーなら誰でも | ✅ | ❌ 403 |
ワークフローの作成者(createdBy)。developer を失ったあとも | ✅ | ✅ |
| スーパー管理者 | ✅ | ✅ |
| それ以外 | ❌ 403 | ❌ 403 |
作成者を明示的に通しているので、自分が始めたチャットから締め出される人は出ません。他テナントのワークフロー ID は 403 ではなく 404 になります。例外はスーパー管理者が全テナントを選んでいるときの GET .../messages で、この場合ワークフローはテナントに関係なく解決され、いま説明したロールと作成者とスーパー管理者のチェックが、テナント境界の代わりを務めます。
ワークフロー実行とそのワークフローセッション
ロールとは別に、ワークフロー実行に対する各操作には、呼び出し元がその実行の開始者(ワークフローを実行したユーザー)であるか、その実行の承認のいずれかで指名された承認者であることが必要です。指名された承認者とは、名指しされたユーザーか、承認の宛先となったグループのメンバーで approver を持つ人です(人による承認を参照)。承認者がチャットを共有する設計(承認者が開始者のチャットに加わる)を保ちつつ、第三者を締め出すためです。読み取りはもう少し広く、行動を伴う操作はもっと狭くなっています。
| 操作 | エンドポイント | 開始者 | 指名された承認者 | 管理者(同テナント) | スーパー管理者 |
|---|---|---|---|---|---|
| 実行を読む | GET /workflow-executions/{id} | ✅ | ✅ | ✅ | ✅ |
| タスクを一覧・閲覧する | GET .../workflow-tasks | ✅ | ✅ | ✅ | ✅ |
| ワークフローセッションの履歴を読む | GET .../messages | ✅ | ✅ | ✅ | ✅ |
| エージェントを動かす | POST .../agent | ✅ | ✅ | ❌ | ✅ |
| タスクのステータスを変える(手動でもエージェント経由でも) | PATCH /workflow-tasks/{id} | ✅ | 自分宛の承認が覆うタスクのみ | ❌ | どの承認も覆わないタスクのみ |
| 承認を決裁する | PATCH /approvals/{id} | ❌ | その承認の承認者のみ | ❌ | ❌ |
| 実行を削除する | DELETE /workflow-executions/{id} | 管理者であれば ✅ | 管理者であれば ✅ | ✅ | ✅ |
この列に入らないユーザーには HTTP 403 が返ります。同じ GET /approvals の一覧は、管理者にはテナント内のすべての承認を見せます。上の読み取りの行と揃っています。
ある実行のタスク一覧は、ワークフローを実行した時点で固定されます。タスクはワークフローの公開済みテンプレートから複製され、その後は status(と失敗時の原因)だけが変わります。実行のタスクを API から追加・削除したり、タイトルや説明、依存関係を書き換えたりする人はいません。ステップを変えたいときはタスクテンプレートを編集して、もう一度実行します。
最後の 3 行は二度読む価値があります。
ステータスの行と決裁の行が、このページの冒頭で予告した所有者レベルの例外、つまりスーパー管理者の素通りが効かない箇所です。承認を決裁できるのは指名された承認者だけで、タスクのステータスを動かせるのは実行の開始者か、そのタスクを覆う承認の宛先である承認者だけです。その実行の承認者なら誰でもよいわけではなく、承認がそのタスクを覆っている場合はスーパー管理者や管理者も通りません。承認者が動かせるのは、自分が承認を求められた範囲(承認が名指しするタスクと、その先の次の承認までのステップ)だけです。これが承認によって実行を再開させつつ、承認者が無関係なステップを進めることを防ぎます。そうしないと、タスクをいきなり completed にすることで誰でも宛先の代わりを務められてしまいます(人による承認を参照)。手動で変えても、ワークフローセッションのチャットで実行エージェントに頼んでも、ルールは同じです。エージェントは、依頼者が直接は行えないステータス変更を拒否します。
実行の削除は逆の形をしています。所有者のチェックが一切ない、素のロールゲートです。そのため管理者はテナント内のどの実行でも削除できる一方、管理者ロールを持たない開始者は自分の実行すら削除できません。削除すると、その実行のタスクとワークフローセッションも一緒に消えます。
プラットフォーム全体のセクション
テナントとシステム設定の 2 つは、スーパー管理者が自分のものとして抱えている管理セクションです。ほかと違って読み取りも制限されます。どちらもテナントのデータではなくプラットフォームレベルの設定を持つため、サイドバーの項目も、ウェルカム画面のカードも、背後のエンドポイントもすべて、ほかのロールには閉じています。
承認者の適格性は時間とともに変わる
⚠️ 承認者として適格かどうかは、承認を作成する時点で検証します。list_users と list_user_groups は実際に承認できる宛先しか返さず、request_approval はそれ以外を拒否します(適格なメンバーがいないグループも含みます)。そのあとどうなるかは宛先によって違い、この違いは意図したものです。
- 宛先がユーザーの場合 — あとから
approverロールを剥奪しても、すでにそのユーザー宛になっている承認は無効になりません。引き続き決裁できるので、進行中のワークフローが止まってしまうことはありません。 - 宛先がグループの場合 — 所属とロールを決裁時に再チェックします。「そのグループ」は固定の個人ではなく、動く集合だからです。だからこそ新しく加わったメンバーが保留中の依頼を拾えるのですが、逆にも働きます。グループから
approverの付与を外したり、適格なメンバーが一人もいなくなったりすると、保留中の依頼は誰にも決裁できなくなり、その実行はいつまでも待ち続けます。ロールを付け直すか、メンバーを戻せば、すぐに解けます。