作成者の退職後、AIエージェントは誰が管理する？ BetterCloudが引き継ぎをワークフローに

従業員の退職時には、アカウントの停止、セッションの無効化、文書の引き継ぎ、機器の回収といった定番のチェックリストがあります。AIエージェントが加わると、まだなじみの薄い問いが生まれます。その人が調査を自動化したり、モデルを業務ツールに接続したりしていた場合、本人がログインできなくなった後も何が動き続けるのでしょうか。

BetterCloudの2026年10月29日のリリースは、AIエージェントのライフサイクル管理とAI支出の追跡を結び付けます。BetterCloudは企業向けのSaaSガバナンス基盤で、従来から従業員のアクセス管理や退職時の処理を自動化しています。今回の更新は、その運用手法をエージェントと関連リソースに広げるものです。同社の発表は、エージェントの作成・更新・廃止、ツール利用の認可、所有者と消費量の関連付けを説明しています。

実用上の進展は、ID管理と、継続して動く機械の処理をつなぐ点にあります。本記事では、その連携に必要な役割、費用の可視化が役立つ場面、集中管理の台帳をすべてのAIシステムの完全な制御と取り違えずに評価する方法を解説します。

2014年の予算表の例。支出確認のイメージであり、BetterCloudのUIや実際のAI利用データではありません。画像：Smallbones、CC0。余白を付けてサイズを調整。画像の出典 · ライセンスと画像に関する注記。公式製品の参考情報。

一つのアカウントより長く責任を持てる管理者が必要

営業企画のアシスタントを例に考えます。ある従業員が顧客データベースに接続し、毎日のレポートを設定して、結果をチームに共有します。同僚が頼るほど便利になっても、認証情報、運用予算、訂正手順の責任者を見直す人はいないかもしれません。退職の時点で、小さな見落としが緊急の引き継ぎ課題になります。

本人のアカウントを無効にしても、解決するのは一部だけです。業務側では、アシスタントを継続するか、結果の受取人を誰にするか、どの接続を正当なものとして残すかを決める必要があります。エージェントに価値があっても、当初の権限がそのまま適切とは限りません。退職処理では、責任の移管とアクセス権の削除を別々に判断するべきです。

本稿では、エージェントをサービスアカウント、定期実行する連携処理、継続的なベンダー請求と同じ運用上の課題として扱うことを勧めます。業務目的、責任者、廃止の手順が必要です。たとえるなら、組織図に夜勤が加わったようなものです。人のログイン中に限らず仕事が続くなら、その責任も継続しなければなりません。

すべての自動処理に長い承認会議が必要という意味ではありません。影響の小さい社内要約と、顧客記録の変更を許されたシステムでは、制御を変えるべきです。共通して必要なのは、目的、アクセス権、責任者、期待する動作の基本的な記録です。それがなければ「動かし続ける」という判断も推測頼みになります。

独自作成のライフサイクル図。役割が変わるときは、責任者、権限、継続費用を明示的に見直します。BetterCloudの画面ではなく、評価のための枠組みです。

10月の更新は、既存の台帳を拡張するもの

BetterCloudは、2026年8月28日の更新でAI Governanceの検出画面を導入しています。当時の説明には、プロバイダーと所有者の情報を含むAIエンティティの台帳がありました。10月の発表は、この基盤にライフサイクルと消費量の機能を加えるものです。したがって、8月の更新に掲載された画像は以前の台帳画面であり、10月の操作画面を示す証拠として扱うべきではありません。BetterCloudの8月更新。

この区別は評価に関わります。検出は「何が見えるか」、ライフサイクル管理は「対応するどの変更を実行できるか」、監査履歴は「実際に何が起きたか」に答えます。リソースの一覧取得が得意なコネクターでも、望むすべての操作に対応するとは限らないため、個別に検証する必要があります。

AIガバナンスという抽象的な約束ではなく、具体的なリソースから始めてください。特定のアシスタントを識別し、所有者と関連するアクセス権を示し、承認済みの手順で廃止できるでしょうか。失敗した段階を管理者が確認し、何が未対応かを理解できるでしょうか。こうした問いが、見栄えのよい台帳と運用上の制御の違いを明らかにします。

コネクターの対応範囲によって「一元化」の意味も変わります。接続済みのプロバイダーを一望できることには価値がありますが、個人アカウント、未接続のテナント、SaaSアプリ内部のすべてのエージェントまで自動で見つかるわけではありません。10月の発表自体も、検出範囲のさらなる拡大を計画として記しています。台帳と並べて未対応事項を記録し、別の手順が必要なシステムを把握してください。

有用な仕事を残し、不適切なアクセスを外す退職処理

BetterCloudの10月発表では、Google Workspaceアカウントを停止し、Microsoft Entra IDのセッションを無効化し、AIツールへのアクセスを外す一方、従業員のエージェントを上司へ移管する例を示しています。実行は記録されると説明されています。いずれも対象連携についてベンダーが説明した機能であり、必要な権限とテナント設定は導入時の確認事項です。2026年10月29日のBetterCloud発表。

営業企画の例なら、有用な引き継ぎは退職日より前に始まります。次の責任者が、レポートの受取人、データ源、実行予定を説明できるようにします。誰も説明できなければ、廃止候補か、調査すべき作業です。名前を自動で付け替えるだけで運用知識が移るわけではありません。

エージェントが必要とするアクセスと、従業員が以前持っていたアクセスも区別します。責任を移すからといって、本人の全権限を新しいサービスIDに複製してよいわけではありません。継続する作業に必要な最小限のツールとデータを確認し、結果が引き続き権限のある相手に届くことを検証します。

財務アシスタントの例では、別の判断になるかもしれません。一時的な照合作業のために作ったものなら、廃止が適切です。業務上必要な承認済みの記録と実行証跡を保存し、新たな処理を止め、接続が利用できなくなったことを確認します。自動処理がまだ動くという理由だけで、完了したプロジェクトに予算を残し続けるべきではありません。

これは管理上の確認事項の提案であり、各行がBetterCloudの自動テンプレートとして用意されているという主張ではありません。自社の手順を検証し、自動処理の前に人の判断が必要な箇所を見つけるために使えます。

支出は責任者と結び付くと判断材料になる

10月のリリースは、請求元のベンダーとモデル提供元を区別し、ツールを月額費用と責任者に結び付けるAI消費量の表示を説明しています。ツール横断の従業員別AI支出についても言及しています。これらの製品機能の根拠は、2026年10月29日付のBetterCloudの発表です。

企業が仲介事業者経由でサービスを購入する場合、この区別は役立ちます。調達担当は支払先を知る必要があり、技術チームは実際に使うモデルやサービスを知る必要があります。両方の項目を残すことで、同じモデルへの二つの経路を、まったく別の技術選択のように比較する誤りを避けられます。

顧客サポート業務なら、費用の問いを業務の問いと結び付けてみてください。毎日の分類処理にいくらかかり、誰が管理し、その出力は今も確認・利用されているでしょうか。請求額の上昇には、正当な利用増、不要な重複実行、設定変更などの理由が考えられます。目的の仕事と結び付けられる人がいて初めて、費用の数値が対応につながります。

請求額の削減だけで成功を測るべきではありません。安い設定が、手戻り、対応の遅れ、誰も信頼しないキューを増やすこともあります。試験導入では、正しい相手へのレポート配信や適切な確認キューへの振り分けなど、定義した業務成果と費用を比べます。削減効果は画面を見て前提にするものではなく、実証すべき結果です。

承認済みの手順でAIが動ける範囲を定める

BetterCloudは、依頼を解釈し、ITチームが作成・承認したワークフローに実行を引き渡すITエージェントを説明しています。解釈が作業の選択を助け、承認済みの手順が許される工程を定めるという構成は重要です。発表は管理者とエージェントの役割に基づくアクセス制御にも触れています。10月29日のリリース。

自然言語の依頼にも曖昧さは残ります。「Alexのアクセスを外して」は、一つのプロジェクト、一つのツール、退職処理全体のどれを指すのでしょうか。影響の大きい操作の前に、その曖昧さを解消する設計が必要です。選んだ手順、対象者、範囲をプレビューし、適切な承認ルールを適用する操作が有効です。

決められた工程を実行する仕組みにも、失敗時の設計が必要です。プロバイダーが一つの操作を拒否したら、手順全体の部分的な結果を示すべきです。セッションの無効化、エージェントの移管、ライセンス削除の失敗は、それぞれ異なる事実です。すべてを緑の「完了」にまとめると、管理者が最も監査履歴を必要とする場面で自動化の価値が落ちます。

独自作成の評価図。一元的な可視化が運用上の制御になるには、対応する権限、実行の確認、残る課題が明確である必要があります。

ロールバックにも同じ注意が必要です。ワークフローの定義を戻すことと、完了したプロバイダー側の操作を取り消すことは異なります。変更によっては、元に戻すための別操作、新たな認可、手動復旧が必要です。自社に重要な連携を使って、関連する失敗と復旧の事例をベンダーに実演してもらってください。

監査履歴は、同僚が次に尋ねることに答える

実行記録は、別の管理者が業務上の出来事と結び付けられて初めて役立ちます。依頼の発端、対象ID、選んだ手順、結果として生じたプロバイダー側の変更を、一緒に理解できる記録が必要です。成功したAPI呼び出しの一覧だけでは、翌日に問い合わせを調べる担当者へ解釈の負担を残しすぎます。

退職者の例で、上司から「毎日の要約が届かなくなった」と相談されたとします。管理者は、意図的に廃止したのか、移管したが一時停止中なのか、エラーで設定が途中のままなのかを見分けられるべきです。理由ごとに修復方法は異なります。よい証跡は診断を速め、症状を消すために広い権限を戻してしまう誘惑を減らします。

この調査も試験導入に含めてください。実行の経緯を口頭で説明せず、同僚に記録だけを渡し、現在の責任者と残る対応を特定してもらいます。できなければ、対象を広げる前に、手順の命名、文書、報告を改善します。管理業務の自動化は、順調な実演中だけでなく、問題が起きている最中にも理解できてこそ成功です。

一つのプロバイダーと一つの退職事例から始める

発表によれば、10月の機能は当日からBetterCloudの顧客に提供されました。既存顧客は対象を絞った相談と対応済みの連携から始められ、導入を検討する企業は自社要件に沿った実演を依頼できます。ただし、基盤が提供されていることは、個々のテナントに必要な全権限が設定済みであることを意味しません。2026年10月29日のBetterCloud発表。

1. 一つのチームについて、既知のエージェント、責任者、目的、接続ツールを一覧にします。正しい状態を別途確認できる少数のリソースを含めます。
2. 現行コネクターが対応するプロバイダーのオブジェクトとライフサイクル操作を確認し、範囲外のリソースを記録します。
3. 適切なテスト環境で試験用IDと影響の小さいエージェントを選び、手順を作る前に移管または廃止の目標を定義します。
4. コネクターの管理権限を見直し、通常の操作担当者と、手順自体を変更できる人を分けます。
5. 合意した事例を実行し、実行履歴とプロバイダー側の結果を確認します。アクセス権の削除と所有者変更が実際に反映されたか検証します。
6. 試験リソースを利用不能にするなど、管理された失敗を加え、部分完了の報告と復旧方法を確認します。
7. 一定期間の接続済みサービスの支出を自社の請求記録と照合します。自動操作を広げる前に、責任者が不明な点を解消します。

最初の達成基準は狭く保ちます。「この退職テストで当該エージェントを移管し、この権限を外し、この失敗した段階を示せた」なら具体的です。「AIを統制できるようになった」では広すぎて、翌朝何を頼れるのかが分かりません。

次に担うのは、エージェントの生涯全体への責任

このリリースの実用上の狙いは、作成時だけでなく、その後もエージェントを管理可能にすることです。組織は、存在する理由、アクセス先、支払者、目的や責任者が変わったときの扱いを知る必要があります。仕事をする仕組みが新しくても、これは通常の運用業務です。

本稿では、責任者と費用を一つの継続的な記録として扱うことで、チームが最も価値を得られると考えます。支出の急増は目的の見直しへ、役割変更は権限の見直しへ、プロジェクトの終了は確認済みの停止へつながります。実際の判断を説明するたび、記録は役立つものになります。

従業員が去った後の責任は、次の自動処理が走る前に決まっているべきです。有用なエージェントのライフサイクル管理とは、意図した仕事を残し、意図しないアクセスを廃止できることです。

出典

• BetterCloud：AI支出追跡とエージェントのライフサイクル管理のリリース、2026年10月29日。2026年11月2日確認。
• BetterCloud：AI Governanceの導入、2026年8月28日。2026年11月2日確認。以前の検出機能と画面の背景を示す資料です。

ガバナンスの判断を、根拠となる資料と結び付けて残す

Telli.shは、利用を許可された資料と、ガバナンス判断の背景にあるメモを一緒に残すための選択肢です。ノート用ワークスペースを作成する。