AIエージェントの非人間IDとアカウント管理を安全に行う方法

監査ログ上は「人の操作」に見えてしまう

個人IDでAIエージェントが操作すると、監査ログにはその個人の操作として記録されます。

たとえば、山本さん（仮名）のアカウントでAIがCRMの商談ステータスを変更した場合、ログ上は「山本さん（仮名）が変更した」と見えます。実際にはAIが自動で判断したのか、山本さん（仮名）が明示的に指示したのか、別の担当者が山本さん（仮名）経由で依頼したのかが分かりません。

これでは、問題が起きたときに説明が難しくなります。

確認すべき論点は、少なくとも次の4つです。

• 誰がAIに指示したのか
• AIはどのアカウントで操作したのか
• 操作前に人間の承認はあったのか
• どのデータや判断根拠に基づいて操作したのか

この4つが分離されていないと、AIエージェントの利用は便利である一方、監査・法務・内部統制の観点では不安が残ります。

責任所在が曖昧になる

AIエージェントが誤った操作をした場合、責任は誰にあるのでしょうか。

個人IDを貸した担当者でしょうか。AIエージェントを設計した情報システム部門でしょうか。AIに業務を任せる判断をした事業部門でしょうか。それとも、AIの出力を確認しなかった承認者でしょうか。

この問いに答えられない状態で運用を広げると、現場はAIを使いにくくなります。事故が起きたときに自分だけが責任を負うのではないか、という不安が残るためです。

AI活用を進めるには、「AIを使う人を増やす」だけでは不十分です。誰がどの範囲で責任を持つのかを、アカウント設計と運用ルールの両方で明確にする必要があります。

権限が過剰になりやすい

個人アカウントには、その人の業務に必要な権限が付与されています。管理職であれば承認権限を持っているかもしれません。情シス担当であれば、設定変更やユーザー管理の権限を持っていることもあります。

そのアカウントをAIに使わせると、AIエージェントは本来必要のない権限まで持ってしまいます。

たとえば、本来は問い合わせチケットの分類だけをさせたいAIが、顧客情報の編集やユーザー権限変更までできる状態になるかもしれません。これは、AIに過剰な特権アクセスを与えている状態です。

AIエージェントには、業務に必要な最小限の権限だけを与えるべきです。そのためには、人間の個人IDではなく、用途ごとに設計された非人間IDを使うことが現実的です。

人間IDと非人間IDの違い

人間IDは、社員や業務委託者など、実在する個人に紐づくIDです。ログイン、メール、チャット、業務システムなどを使うために発行されます。

一方、非人間IDは、人ではなく業務プロセスやシステムに紐づきます。たとえば、次のようなものです。

• 問い合わせ分類AIエージェント用アカウント
• CRM更新AIエージェント用アカウント
• 請求書チェックAIエージェント用アカウント
• 社内FAQ回答AIエージェント用アカウント
• データ連携用サービスアカウント
• API実行用トークン
• バッチ処理用アカウント

重要なのは、非人間IDは「誰かの代わりに使う共有アカウント」ではないという点です。

非人間IDは、特定の業務目的、操作範囲、責任者、承認者、停止条件を持つ管理対象です。単にログインできればよいのではなく、ライフサイクル管理の対象として扱う必要があります。

サービスアカウントAIとは何か

サービスアカウントAIとは、AIエージェントが外部システムや社内システムを操作するために使う専用アカウントを指す実務上の呼び方です。

たとえば、問い合わせ対応のAIエージェントがヘルプデスクツールにログインし、チケットのカテゴリを変更する場合、そのAI専用のサービスアカウントを使います。

このアカウントには、次のような情報を紐づけます。

• 何のAIエージェントが使うのか
• どの業務に使うのか
• どのシステムにアクセスするのか
• 読み取りだけなのか、書き込みもできるのか
• 操作結果を誰が確認するのか
• 問題発生時の責任者は誰か
• いつ棚卸しするのか
• いつ停止するのか

このように定義しておくことで、AIエージェントを「誰かのアカウントを借りて動く存在」ではなく、「管理された業務実行主体」として扱えるようになります。

AIエージェントごとに専用IDを発行する

1つの非人間IDを複数のAIエージェントで使い回すと、監査ログを見ても、どのAIが何をしたのか分からなくなります。

たとえば、「AI-agent-common」という共通アカウントを作り、問い合わせ分類、CRM更新、社内FAQ回答のすべてに使わせると、ログは残っていても用途の切り分けが難しくなります。

非人間IDは、AIエージェントごと、少なくとも用途ごとに分けるべきです。

望ましい例は、次のような命名です。

• ai-helpdesk-ticket-classifier
• ai-crm-update-assistant
• ai-internal-faq-reader
• ai-invoice-checker
• ai-marketing-report-drafter

名前だけで、何のAIがどの業務に使うアカウントなのか分かる状態にしておくと、棚卸しや監査がしやすくなります。

最小権限から始める

AIエージェントには、最初から広い権限を与えないことが重要です。

「後で困らないように」と考えて広めの権限を付けると、AIが想定外の操作をしたときの影響範囲が広がります。まずは読み取り専用、または限定された書き込み権限から始める方が安全です。

たとえば、問い合わせ対応AIであれば、初期段階では次のように分けることができます。

• FAQや過去チケットの閲覧は可能
• 顧客への返信送信は不可
• チケット分類の下書きは可能
• ステータス変更は人間の承認後のみ可能

このように、AIができることと人間が確認すべきことを分けます。

AIエージェントは自律的に動くほど便利になりますが、すべての操作を最初から任せる必要はありません。段階的に権限を広げることが、現実的な運用です。

承認が必要な操作を明確にする

AIエージェントの操作には、承認なしで実行してよいものと、人間の確認が必要なものがあります。

たとえば、次のような操作は、比較的低リスクな領域として扱いやすい場合があります。

• 社内資料の検索
• 議事録の要約
• チケット分類案の作成
• メール文面の下書き
• FAQ回答案の生成

一方で、次のような操作は人間の確認を挟むべきです。

• 顧客へのメール送信
• 契約条件の変更
• 見積金額の確定
• 顧客情報の上書き
• ユーザー権限の変更
• 支払い、返金、請求に関わる操作

AIエージェント用アカウントの設計では、単に権限を付けるだけでなく、「AIが実行できる操作」と「AIは下書きまで、人間が承認する操作」を分けることが大切です。

責任者と運用者を分けて記録する

非人間IDには、必ず責任者を設定します。

ただし、責任者は必ずしも日々の技術運用者と同じではありません。たとえば、問い合わせ分類AIエージェントであれば、業務責任者はカスタマーサポート部門の責任者、技術運用者は情報システム部門、利用者は現場メンバーという形になります。

この関係を台帳で管理します。

最低限、次の項目を記録しておくとよいです。

• 非人間ID名
• 利用するAIエージェント名
• 利用目的
• 対象システム
• 権限範囲
• 業務責任者
• 技術運用者
• 承認者
• 作成日
• 最終レビュー日
• 停止予定日または見直し予定日

この台帳がないと、半年後に「このアカウントは何のために作ったのか」が分からなくなります。

作成時は目的と権限を明確にする

非人間IDを作るときは、まず目的を明確にします。

避けたいのは、「AI検証用」「自動化用」「共通アカウント」のような曖昧な名前で作ることです。これでは後から見ても、どの業務に必要なのか分かりません。

作成時には、少なくとも次の問いに答えられるようにします。

• 何の業務を実行するAIなのか
• なぜ個人IDではなく非人間IDが必要なのか
• どのシステムにアクセスするのか
• 読み取り、作成、更新、削除のどこまで許可するのか
• 人間の承認が必要な操作は何か
• いつ見直すのか

この時点で曖昧なアカウントは、運用後も曖昧なまま残ります。

利用中は監査ログと実行ログを確認する

AIエージェントが実際に動き始めたら、ログを確認します。

ここで見るべきなのは、単にエラーが出ていないかだけではありません。AIが意図した範囲で動いているか、想定外の操作が増えていないかを確認します。

たとえば、問い合わせ分類AIであれば、次のような観点があります。

• 想定外のカテゴリ変更が増えていないか
• 夜間や休日に不自然な操作がないか
• 同じチケットに何度も変更を加えていないか
• 権限エラーが頻発していないか
• 人間の承認を飛ばした操作がないか

AIエージェントの監査では、「何が成功したか」だけでなく、「何が拒否されたか」「何が失敗したか」も重要です。拒否や失敗のログは、権限設計やプロンプト設計の改善材料になります。

変更時は用途変更と権限追加を分ける

AIエージェントの運用が進むと、現場から「この操作もやらせたい」という要望が出ます。

このとき、単純に権限を追加していくと、アカウントの目的が広がりすぎます。問い合わせ分類用に作ったAIが、いつの間にか顧客返信、ステータス変更、レポート作成、CRM更新まで行うようになるかもしれません。

用途が変わる場合は、既存の非人間IDに権限を足すのではなく、新しいAIエージェントや新しい非人間IDとして分けるべきかを検討します。

権限追加のたびに、次の問いを確認します。

• これは当初の利用目的に含まれるか
• 既存IDに追加すべきか、新しいIDに分けるべきか
• 追加する権限は読み取りか、書き込みか
• 承認フローは必要か
• 監査ログで区別できるか

この確認を挟むことで、非人間IDの肥大化を防げます。

停止時は不要なIDを放置しない

PoCが終わったAIエージェント、使われなくなった自動化、担当者が異動した業務の非人間IDは、放置されがちです。

しかし、使われていないIDほどリスクになります。誰も見ていないアカウントに権限やAPIキーが残っていると、情報漏えいや不正利用に気づきにくくなります。

停止時には、次の処理を行います。

• AIエージェントの実行停止
• APIキーやトークンの失効
• 対象システムからの権限削除
• 関連するスケジュール実行の停止
• ログ保存期間の確認
• 台帳のステータス更新

「使っていないが、念のため残す」は避けるべきです。再利用の可能性がある場合でも、権限はいったん外しておく方が安全です。

キーを個人端末やチャットに置かない

最も避けたいのは、APIキーやトークンを個人端末、メモアプリ、チャット、スプレッドシートなどに置くことです。

一度チャットに貼られたキーは、誰が見たか分かりにくくなります。スクリーンショットやログに残る可能性もあります。

キーは、シークレット管理ツールやクラウド環境の安全な保管機能で管理します。AIエージェントの実行環境から必要なときだけ参照し、コードやプロンプト本文には直接書かないようにします。

ローテーション周期を決める

キー管理では、ローテーションも重要です。

周期は組織のセキュリティポリシーやシステムの重要度によって異なります。重要なのは、「どの条件で更新するか」を事前に決めておくことです。

たとえば、次のような条件が考えられます。

• 一定期間が経過したとき
• 担当者が異動・退職したとき
• AIエージェントの用途が変わったとき
• 権限範囲を広げたとき
• 漏えいの疑いがあるとき
• 利用システム側のポリシーが変更されたとき

ローテーションで大切なのは、手順を事前に用意しておくことです。

1. 新しいキーを発行する
2. AIエージェントの設定を更新する
3. 動作確認を行う
4. 古いキーを失効する
5. 台帳に更新日を記録する

この流れが決まっていないと、更新時にAIエージェントが停止したり、古いキーが残ったりします。

情報漏えい時の失効手順を決めておく

キーやトークンが漏えいした可能性がある場合、すぐに失効できる状態にしておく必要があります。

重要なのは、情報漏えいが確定してから考えるのではなく、事前に手順を作っておくことです。

たとえば、次のような項目を定めます。

• 誰が失効判断をするのか
• どの画面またはAPIで失効するのか
• 失効後にどのAIエージェントが止まるのか
• 代替キーの発行手順は何か
• 関係者への通知方法は何か
• 監査ログをどこまで確認するのか

AIエージェントの自律性が高くなるほど、キーの情報漏えい時の影響も大きくなります。平時の管理と同じくらい、有事の手順が重要です。

人間の指示とAIの実行を紐づける

AIエージェントの操作ログだけを見ても、なぜその操作が行われたのか分からないことがあります。

たとえば、CRMの商談ステータスが変更されたログだけでは、AIが何を根拠に変更したのか分かりません。人間が「この商談を確認して更新して」と指示したのか、AIが定期処理で自動更新したのかも区別できません。

そのため、AIの実行ログには、人間の指示やワークフローIDを紐づけることが望ましいです。

記録したい項目は、次のようなものです。

• 指示したユーザー
• 指示時刻
• 指示内容の概要
• AIエージェント名
• 使用した非人間ID
• 対象システム
• 実行内容
• 実行結果
• 承認者
• エラーまたは例外処理

すべてを最初から完璧に残す必要はありませんが、少なくとも重要な業務では、後から説明できる粒度を決めておく必要があります。

失敗・拒否・例外もログに残す

監査ログでは、成功した操作だけでなく、失敗した操作や拒否された操作も重要です。

たとえば、AIエージェントが権限不足で顧客情報の更新に失敗した場合、それは権限設計が正しく機能した証拠でもあります。一方で、同じ失敗が何度も起きているなら、プロンプトやワークフローが誤っている可能性があります。

拒否ログや失敗ログは、AIエージェントの安全性を高めるための改善材料です。

「何を実行したか」だけでなく、「何を実行しなかったか」も見えるようにしておくことで、運用改善が進みます。

プロジェクト単位で利用範囲を分ける

AIエージェントを全社共通で1つにまとめると、権限やデータの境界が曖昧になります。

たとえば、営業部門のCRM情報、人事部門の評価情報、法務部門の契約情報を同じAIエージェントが扱う状態は、管理が難しくなります。

業務領域ごとにプロジェクトを分け、利用者、学習データ、プロンプト、アプリを整理することで、AIエージェントが参照してよい情報の範囲を明確にできます。

具体的には、次のような分け方が考えられます。

• 営業支援プロジェクト
• カスタマーサポート支援プロジェクト
• 人事問い合わせ対応プロジェクト
• 契約レビュー支援プロジェクト
• 経営会議資料作成プロジェクト

プロジェクトを分ける基準は、「関係者が同じ情報を見てよいか」です。これは、AIエージェントのアクセス範囲を考える上でも重要です。

学習データと操作権限を混同しない

AIエージェントが「参照できる情報」と「操作できる権限」は分けて考える必要があります。

たとえば、契約書レビューAIが契約書を読めることと、契約管理システム上で契約ステータスを変更できることは別です。

学習データとして参照できる範囲が広いからといって、操作権限まで広げる必要はありません。

AI活用基盤を設計するときは、次の2つを分けて考えることが重要です。

• AIが回答や判断のために参照してよいデータ
• AIが業務システム上で実行してよい操作

この2つを混同すると、AIエージェントの権限が過剰になります。

ライブラリ管理者とID管理者を連携させる

AI活用が進むと、現場はプロンプトや学習データを増やしていきます。一方で、情報システム部門やセキュリティ部門は、ID、権限、ログ、キー管理を見ます。

この2つが分断されると、現場は便利なAIを作ったつもりでも、管理側から見ると説明しにくい運用になることがあります。

そのため、ライブラリ管理者とID管理者の連携が必要です。

たとえば、新しい業務実行AIエージェントを作るときには、次のような確認を行います。

• どの業務領域で使うのか
• どの学習データを参照するのか
• どのプロンプトを標準にするのか
• どの非人間IDを使うのか
• どの操作権限を与えるのか
• 監査ログはどこで確認するのか
• 誰が定期レビューするのか

AI活用の推進とID管理は、別々の活動ではありません。AIエージェントが業務を実行する段階では、同じ運用設計の中で扱う必要があります。

AIが使っているアカウントを洗い出す

最初に確認するのは、AIエージェントや自動化ツールがどのアカウントで動いているかです。

次のような観点で洗い出します。

• 個人IDで動いているAIエージェントはあるか
• 共通IDで動いている自動化はあるか
• APIキーの所有者が個人になっていないか
• 退職者や異動者のアカウントに紐づく自動化が残っていないか
• PoC時に作った検証用アカウントが残っていないか

この段階では、完璧な台帳がなくても構いません。まずは現状を可視化することが大切です。

リスクの高い操作から優先順位を付ける

すべてのAI利用が同じリスクではありません。

文章の下書きや社内FAQ検索と、CRMの更新や顧客への自動返信では、リスクが異なります。まずは、書き込みや外部影響のある操作から優先して見直します。

優先度が高いのは、次のような操作です。

• 顧客情報を更新する
• 顧客に通知やメールを送る
• 契約、請求、支払いに関わる
• ユーザー権限を変更する
• 社外に公開される情報を生成する
• 法務、監査、規制対応に関わる

これらの領域では、個人ID貸与を早めにやめ、非人間IDと承認フローを整える必要があります。

非人間ID台帳を作る

次に、非人間ID台帳を作ります。

最初はスプレッドシートでも構いません。ただし、将来的にはID管理システムや特権アクセス管理の仕組みと連携できる形が望ましいです。

台帳には、次の項目を入れます。

この台帳があるだけで、監査や棚卸しの負荷を下げやすくなります。

監査ログの最低要件を決める

AIエージェントのログをどこまで残すかも決めます。

すべての詳細を残すのが理想ですが、最初は重要操作に絞っても構いません。最低限、次の項目を追えるようにします。

• AIエージェント名
• 使用した非人間ID
• 操作対象
• 操作内容
• 操作日時
• 指示者
• 承認者
• 実行結果
• エラー内容
• 参照した主要データ

特に、外部への通知、顧客情報の変更、金額や契約条件に関わる操作は、後から説明できる形で残すべきです。

月次または四半期で棚卸しする

非人間IDは定期的に棚卸しします。

棚卸しでは、次の項目を確認します。

• まだ使われているか
• 利用目的は変わっていないか
• 権限が過剰になっていないか
• 責任者は変わっていないか
• キーやトークンは更新されているか
• 監査ログは取得できているか
• 不自然な操作はないか

頻度は業務の重要度によって変わるので、顧客情報や契約情報に関わるAIエージェントは月次、読み取り中心のAIエージェントは四半期など、リスクに応じて決めるとよいです。

名前だけ非人間IDにしている

個人IDをやめてAI専用アカウントを作ったものの、実態としては広い権限を持つ共有アカウントになっているケースです。

これでは、非人間IDを作った意味が弱くなります。重要なのは、名前ではなく、用途、権限、責任者、ログ、停止条件が定義されていることです。

AIの判断と人間の承認が混ざっている

AIが提案した内容を人間が承認したのか、AIが自動で実行したのかがログ上で分からないケースです。

この状態では、問題発生時に原因を追いにくくなります。AIの提案、承認、実行は分けて記録する必要があります。

PoC用の設定を本番で使い続ける

検証段階では、スピードを優先して個人IDや広い権限を使うことがあります。問題は、そのまま本番運用に移ってしまうことです。

PoCから本番に移るタイミングでは、必ずアカウント、権限、ログ、キー管理を見直します。

「動いたからそのまま使う」は、AIエージェント運用では危険です。

現場だけ、または情シスだけで設計する

現場だけで設計すると、便利さは高くても監査性が弱くなりがちです。一方、情シスやセキュリティ部門だけで設計すると、現場が使いにくいルールになることがあります。

AIエージェントの非人間ID管理は、現場、情シス、セキュリティ、法務、監査が一緒に設計する必要があります。

それぞれの関心は違います。

• 現場は、業務が止まらないことを重視します。
• 情シスは、運用できることを重視します。
• セキュリティは、権限とキー管理を重視します。
• 法務は、責任と契約上のリスクを重視します。
• 監査は、後から説明できることを重視します。

この違いを前提に、共通のルールを作ることが重要です。