管理者ガイド

管理ワークスペース（/ws/*）では、担当する操作に応じてロールの権限を使います。ownerとadminは管理操作を行えます。catalog_adminはカタログ、member_adminはメンバー・上長・承認グループ、auditorは可観測性・監査・レポートを扱えます。設定と台帳の回収はownerとadminだけが行えます。

ロールを付与できるのはownerとadminです。adminはownerを付与できず、最後のownerは降格できません。Slackを連携する場合は、メンバー情報を同期します。

カタログ（申請の型）を育てる

「カタログ」= フォーム + 承認経路 + 承認後の実行 + コスト、の 4 点セットです。ここが設計の中心です。

作成・編集はワークスペースの「カタログ」から。フォーム項目、承認ステップ（上長 / グループ / 個人、同一ステップに複数置けば並列）、実行方法、コストを設定します
カテゴリ（account / access / saas / expense / other）を選ぶと、ポータルのホームでカテゴリ別に集計されます
承認ステップには条件を付けられます。数値項目は > >= < <=、選択式項目は == / in を使います。例: 金額 > 50000 のときだけ directors の承認を追加します。条件のないステップを最低1つ残してください
条件は申請作成時の入力値で一度だけ評価され、不成立のステップはその申請の経路から除かれます。任意項目が未入力なら条件は不成立です
経路は申請時に固定されます。カタログや組織を後から変えても、進行中の申請には影響しません
よくある依頼が「汎用申請」やスタンプで繰り返されていたら、専用カタログ化のサインです

メンバーと承認グループ

「メンバー」画面で、各メンバーの上長設定と、承認グループ（it-admins など）の作成・メンバー管理ができます。グループはカタログの承認経路と実行タスクの宛先に使われます。

メンバーの招待

Slack を繋いでいなくても、「メンバー」画面の「メンバーを招待」からメールアドレス（複数可、改行区切り）で招待できます。招待された人には Web へのログインリンクがメールで届き、初回ログインの前から上長や承認グループの設定ができます。

既に登録済みのメールアドレスは重複して作られません
退職者などは行の「無効化」でログイン不可・承認者候補から除外にできます。進行中の承認段はそのまま残ります
各行の「Slack」列で、その人が Slack アカウントに紐づいているかが分かります

実行の接続（自動化）

承認後の作業は、接続済みのシステムなら自動実行されます（Google Workspace のアカウント作成、AWS Identity Center の権限付与など）。未接続・API の無い作業は 手順書タスクとして担当グループに届き、完了報告と証跡が台帳に残ります。接続は後から足せます。可観測性の「実行内訳」で手作業の比率を見て、次に接続すべきシステムを判断してください。

台帳と回収

「台帳」/ws/ledger には発行済みのすべて（所有者・月額・期限・根拠の承認）が載ります
一覧は 有効 / 期限間近（7 日以内）/ 回収済み のセグメントで切り替えられます。行を選ぶと右に発行物レコード（対象者・付与・根拠・承認者・月額・回収方法）が開きます
回収：不要になったものはレコードの操作列から回収（revoke）できます。理由は必須で、本人に通知され、監査記録に残ります
期限付きの発行物は、期限 3 日前に本人へ予告が届き、期限が切れると自動回収（接続済みシステム）または回収タスク（手作業）が走ります
CSV エクスポートで棚卸し資料をそのまま作れます

ダッシュボードと監査

「可観測性」/ws/dashboard で申請量・承認リードタイム（p50/p95）・滞留・コストの推移を確認できます。監査対応には、期間を指定した監査ログの CSV エクスポートを使ってください。すべての操作（承認・実行・回収・設定変更）は追記専用の監査ログに残ります。記録は足すだけです。書き換えも削除もしないので、監査のときに「この行はあとから直したのではないか」という疑いが入り込む余地がありません。

Slack 連携

Slack は「あれば使う連携」です。繋ぐと、承認カード・催促・完了通知が Slack の DM で届き、チャットのスタンプ記録（L0）と宣言（L1）が使えるようになります。状態はワークスペースの「設定」の「Slack 連携」カードで確認できます。

Bot をインストールする — Slack アプリを作成し、必要なスコープ（メッセージ投稿、リアクション読取、ユーザー情報、ユーザーグループ読取、コマンド）を付けてワークスペースにインストールします。 Bot トークン（SLACK_BOT_TOKEN）と App トークン（SLACK_APP_TOKEN）、署名シークレット、 Sign in with Slack 用のクライアント ID / シークレットを環境変数に設定し、Bot と Web を再起動します
同期する — Bot が起動するとワークスペースを取り込みます。「設定」の「いま同期する」でも同じ取り込みを手動で走らせられます。取り込みでは Slack のメンバーとユーザーグループを読み、 メールアドレスが一致する既存メンバーを Slack アカウントに紐づけます（監査に user.linked_slack）。一致しない人は新しいメンバーとして作られます
確認する — 「設定」のカードにワークスペース名・連携日時・最終同期が出ます。「メンバー」画面の Slack 列で紐づきを確認し、必要なら本人に /actagate setup @上長 を案内してください

連携後は通知経路が自動で Slack の DM に切り替わります（メールアドレスしか無い人には引き続きメール）。

シングルサインオンの接続

ownerとadminは「設定」のセキュリティ画面（/ws/settings/security）で、OIDCまたはSAML 2.0の接続を追加できます。接続を下書きで保存し、同じ管理者のブラウザーで接続テストを通してから有効にしてください。

SAMLはIdPのメタデータXMLを貼り付けるか、ファイルから取り込みます。表示されるSPメタデータとACSのURLをIdPに登録します。IdP起点のログインは既定で無効です。証明書などの認証設定を変えた場合は、再度テストして有効化してください。既存ユーザーの統合はメンバー画面で行います。

ドメインを検証してからJITと必須化を設定する

/ws/settings/security の「ドメインの検証」でドメインを追加します。表示されたTXTレコード名 _actagate-challenge.<domain> と値 actagate-domain-verification=<token> をDNSに登録し、「確認する」を押してください。トークンは組織ごとに共通です。検証はこの操作時だけ行い、5秒でタイムアウトします。TXTレコードが分割されていても、同じレコード内の文字列を連結して照合します。同じドメインを複数の組織が検証済みにはできません。

接続ごとに振り分けるドメインを指定し、必要なら初回ログインでの自動登録（JIT）を有効にします。JITの既定は無効で、作成するロールは member 固定です。メール先行の振り分けとJITは、接続に指定したドメインのうち、この組織で検証済みのものだけを使います。ドメインの検証を削除すると、振り分けとJITに使えなくなります。再確認に失敗しても、以前の検証は維持します。

SSOの必須化は、有効な接続があり、操作する管理者自身がその接続でSSOログインしている場合だけ設定できます。接続テストやログイン方法の追加だけでは、この条件を満たしません。必須化するとメールのリンクとSlackのログインを拒否します。所有者（owner）だけはメールのリンクを非常口として使えます。IdPの障害や設定ミスでは、この方法でログインして必須化を解除してください。既存のセッションは失効させません。

必須化中は、最後の有効な接続を無効化できません。認証設定の変更で下書きへ戻す操作も拒否します。先に必須化を解除してください。メールの応答は登録済み・未登録で同じです。必須化中の所有者以外にはメールログイン用のリンクを送らず、振り分ける場合は登録の有無にかかわらずIdPへ進みます。

ユーザー統合とログイン方法の削除

統合元・統合先・統合後のいずれかが管理者（admin）なら、ユーザー統合は所有者（owner）だけが行います。メール・外部ID・Slack IDが統合先のログイン入口へ移るためです。統合後に申請者と承認者が同じ人となる段は、自己承認できません。

SSO必須化中は、最後の使えるSSOログイン方法を削除できません。無効な接続の外部IDは代わりの入口に数えません。所有者のメールだけは非常口として使えます。

SSO必須化中の招待メールは、ログイン画面へのリンクを案内します。メールだけでログインするトークンは発行しません。