AIに、誰の権限で何をさせるか。Tines 3B の権限とガードレールを読み解く

Last updated at 2026-10-25Posted at 2026-10-22

連載「Tines 3B を読み解く」の第4回です。

はじめに

AI にメールを送らせ、チケットを作らせ、ワークフローを書き換えさせる。そこまで任せるなら、先に決めておきたいことがあります。その AI は誰の権限で動くのか。人はどこで止められるのか。

この記事では、AI ネイティブのワークフロー基盤「Tines 3B」の権限とガードレールの設計を、公式ドキュメントに沿って整理します。

こんな方に向けて書いています。

AI や自動化に、業務の操作を任せることを検討している
部署や役割ごとの権限をどう設計するかで悩んでいる
「承認」がいつ、どこで入るのかを正確に知りたい

先に結論です。3B の権限は「誰が、どのロールで、どこに対して」という1つの形（グラント）に統一されています。AI は固有の権限を持たず、呼び出した人の権限で動きます。そして 3B の「承認」は、本番へ出すまでの構築時のものです。

第1回（全体像）はこちらです。

こんな場面、ありませんか

AI に書かせた自動化が誰の権限で動いているのか、説明できない。
同僚には見えるものが自分には見えない。権限の問題なのか不具合なのか、判断がつかない。
管理者が何人もいて、誰が何を変えられるのか把握しきれない。

どれも根っこは「権限の形が複雑で、説明できない」ことです。

結論：3つの設計

3B の設計は、次の3つに整理できます。

設計	何をするか	得られるもの
権限を1つの形に揃える	すべてのアクセスを、誰×ロール×どこのグラントで表す	判定が一貫し、説明できる
AI を人の権限に縛る	AI は呼び出した人として動き、その人が届く範囲にだけ届く	AI が人を超えない
本番へは人が出す	ドラフトは自動で動かず、ライブへの反映は権限を持つ人が行う	AI が作ったものが、勝手に本番で動かない

設計1：権限を1つの形に揃える

グラントと判定の順序

あらゆるアクセスの判断は、「グラント」という1つの形で表されます。グラントは次の3つでできています。

部品	答え	例
プリンシパル（誰が）	誰が動くか	メンバー、グループ、サービスアカウント
ロール（どこまで）	何ができるか（権限の束）	Space editor、Connector user
スコープ（どこに）	何に対してか	スペース、コネクタ、スキル、ネットワーク、テナントなど

たとえば「Alice に、Security スペースの Space editor を付ける」が1つのグラントです。ワークフローやチャットなどは、所属するスペースのアクセスを引き継ぐので、ワークフローごとのグラントはありません。

操作を試みると、3B は次の順に調べます。

拒否のとき、3B は「アクセス拒否」と表示せず、そのリソースが無いかのように振る舞います。存在を探られないための設計です。同僚には見えるものが自分に見えないときは、不具合ではなく権限の問題であることが多い、と公式では説明されています。

なお、画面のアクセス表示は利便性のためのもので、セキュリティの境界ではありません。すべての操作は、実行時にサーバー側でもう一度検査されます。

テナント管理者は少数に

テナント管理者はすべてのチェックを迂回し、カスタムロールでは再現できません。公式では、管理者を少数にするよう繰り返し述べられています。

一部の権限だけを渡したいときは、次の3段階を使います。

段階	内容
フルのテナント管理者	すべてを持つ。個人に付ける
組み込みの作成系ロール	スペース、コネクタ、ネットワークなどの作成。グループに付ける
カスタムのテナントロール	全スペースの閲覧、メンバーの管理、監査ログの閲覧など。フルのアクセスは含められない

ID の入口と同期モード

ID の入口は、招待、SSO（OIDC、SAML）、JIT、SCIM、サービスアカウントです。外部の ID 基盤（IdP）との同期モードは4つから選びます。

モード	ユーザー	グループ
Off	手動で招待	手動
JIT（ユーザーのみ）	初回の SSO ログインで作成	手動
JIT（ユーザーとグループ）	初回のログインで作成	ログインごとに IdP の groups クレームから同期
SCIM	IdP が作成・更新・停止	IdP が同期

IdP がユーザーやグループを持つと、3B は対応する手動の操作をロックします。つまずきやすい点なので、最初に「どこが正か」を決めるのが大切です。公式で示されている設計の順序も、SSO と同期モード、メンバー、グループ、ロール、共有リソース、スペースの順です。スペースが最後なのは、すべてがスペースに集まるからです。

設計2：AI を人の権限に縛る

3B 自身は固有の ID を持ちません。UI、API、3B の AI アシスタントのどれを通しても、操作は何らかのプリンシパルとして実行されます。AI は呼び出した人として動き、その人が届く範囲にしか届きません。「側面の扉」はありません。

チャットは、本人が使えるコネクタだけを使えます。読むだけでなく、メッセージの下書き、チケットの作成、コードの実行もできます。
MCP（外部の AI クライアントとの接続）は、新しい特権を足しません。OAuth ならクライアントは本人として、サービスアカウントのトークンならそのアカウントとして動きます。
サービスアカウントは独立したプリンシパルで、自分のグラントで判定されます。

裏を返せば、管理者が使う AI は管理者の範囲まで届きます（筆者の整理です）。作り手に広い権限を渡すほど、AI が生成するコードやチャットの届く範囲も広がります。

スペースでは「全員の条件」

コネクタ、スキル、ネットワークは、そのスペースにアクセスできる全員が必要な権限を持つときだけ、そのスペースで使えます。1人でも欠けていると誰にも使えません。スペースを作れる人なら誰でもコネクタの認証情報を使えてしまう、という事態を防ぐためです。

直し方は3つあります。スペースにリソースを追加する、リソースにスペースを追加する、同じグループを両方に付ける、のどれかです。公式では、グループで付けて両側に同じグループを使うのがいちばん簡単だとされています。

設計3：本番へは人が出す

3B のワークフローには、ドラフトとライブ（main）があります。ドラフトは cron や webhook のような自動のトリガーでは動かず、手動の実行か、ブランチの URL でのプレビューで確かめます。

ライブへの反映（push live）には、スペースでの権限が要ります。権限がない人にはボタンが無効になります。Git と同期するスペースでは Push live の代わりに Sync が出て、リモート側でマージします。

Autofix（失敗の自動の修正案）も新しいブランチでの提案にとどまり、ライブを直接変更しません。

「承認」は構築時のもの

ここは区別が必要です。3B の承認は構築時のものです。

仕組み	いつ	内容
Plan mode	構築時	AI の提案を、実行の前に確認する（ユーザーの設定）
副作用のあるステップの確認	構築時	メール送信など。公式では、確認するよう構成されていると説明されている（管理者が強制する設定の記載はない）
push live	本番に出すとき	権限を持つ人が行う
コネクタ共有の承認	権限の付与	sharer か管理者が承認する

ライブのワークフローが動いている最中に人の承認を挟む公式の仕組みは、確認できていません。

守ってくれないこと

ガードレールは、AI が正しく判断する保証ではありません。仕組みがしているのは、届く範囲を狭め、反映を人に残すことです。
同期モードの選び間違い。IdP が持つ操作はロックされます。SCIM の有効後は、SCIM 由来でも引き継ぎでもないグループをアプリ内で削除できなくなります。
カスタムロールは、作成後に編集できません。変えるときは新しく作って付け替え、古いものを消します。
事前チェックの失敗は、通せます。push live のときにステップのテストが失敗しても、確認のうえでそのまま反映できます。
管理者と Watchtower の権限。管理者は他人の個人チャットも読めます。Watchtower の権限も慎重に付ける必要があります。

他のやり方との違い

「承認」の位置づけを、一般的な分類で比べてみます（特定の製品の仕様ではなく、考え方の整理です）。

方式	人が入る場所	向く場面
構築時の承認（3B）	AI の提案、本番への反映	作る人が多く、本番へは慎重にしたい
実行時の承認	動いている最中の、重要な操作の直前	実行のたびに、人の判断が必須
承認なし（権限だけで縛る）	入らない	影響の小さい、内部向けの自動化

どれが良いかは、何を守りたいかで決まります。実行時の承認を求める場合は、3B でどう実現するかの確認が必要です。

おわりに

権限は、誰×ロール×どこのグラントに揃える。
AI は、呼び出した人の権限で動く。
本番へは人が出す。ただし、承認は構築時のもの。

「AI に何をさせるか」は、「誰の権限を渡すか」と同じ問いです。

連載の他の回

連載「Tines 3B を読み解く」（全11回）:

第1回 AIが作るコードの乱立に、どう備えるか。Tines 3B の全体像と5つの強みを読み解く
第2回 AIが書いたコードを、動かして大丈夫か。Tines 3B の実行とネットワークの分離を読み解く
第3回 AIエージェントに、APIキーを渡さない。Tines 3B の認証情報の設計を読み解く
第4回 AIに、誰の権限で何をさせるか。Tines 3B の権限とガードレールを読み解く（この記事）
第5回「誰が何をしたか」と「いくらかかったか」を、どう見るか。Tines 3B の監視・監査・費用を読み解く
第6回 AI にチャットで作らせても、実体はコード。Tines 3B の「コードファースト」を読み解く
第7回本番を壊さずに直す。Tines 3B のドラフトと本番、自己修復（Autofix、Autotune）を読み解く
第8回「ベンダーに縛られない」は、どこまで本当か。Tines 3B の接続口と、持ち出せる範囲を読み解く
第9回自社環境で動かすなら、何を引き受けるか。Tines 3B のセルフホストを読み解く
第10回契約の前に、何を書面で確かめるか。Tines 3B の導入・契約・費用を読み解く
第11回 Tines 3B か、他の製品か。8つの軸で見分ける

参考

公式ドキュメント（docs.3b.tines.com）:

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up