AIエージェントのセキュリティ｜社内システムの権限設計と監査ログ

社内システムをAIに操作させる取り組みは、この1年で現実的な選択肢になりました。受信メールの分類、受注一覧への書き込み、見積書の下書きといった処理は、APIや連携ツールを使えば短い期間で組めます。

ただし、つなぐ前に決めておくことが二つあります。AIに何をどこまで触らせるか（権限の設計）と、AIが触った記録をどこに残すか（監査ログの設計）です。

この二つを後回しにして動かし始めると、問題が起きたときに原因をたどれず、元に戻すのも難しくなります。権限は一度広げると、あとから狭めるときに現場の業務が止まりやすいためです。

この記事では、AIエージェントに社内システムの権限を渡すときのセキュリティを、権限の設計と監査ログの設計に分けて整理します。製品の仕様は2026年9月時点の公式情報です。

AIの安全はプロンプトでは守れない

人に権限を渡すときと、AIに渡すときでは前提が違います。違いは大きく二つあり、どちらも指示の文面（プロンプト）の工夫だけでは防げません。

AIは違和感があっても止まらない

人に権限を渡すとき、私たちは無意識のうちに、その人の良識や現場での判断を当てにしています。

社員は、注文数量がいつもより二桁多いといった違和感に気づくと、手を止めて上司や前後の工程に確かめます。権限の上では実行できても、あえて実行しないという判断ができるのが人です。

一方、AIエージェントは違和感を覚えて立ち止まることがありません。疲れることもなく、渡された権限の範囲で、指示された処理を最後まで速く進めます。

誤ったデータや指示が入ると、外で止める仕組みがない限り、誤った処理がそのまま続きます。そのため、AIの安全は、AIの賢さではなく、システムの側で触れる範囲を絞ることで守ると考えてください。

Webの安全性に取り組むOWASPも、LLMの主なリスクの一つに「過剰な権限（Excessive Agency）」を挙げています。対策として、使える機能と権限を必要な分に絞ること、影響の大きい操作は人が承認することを勧めています（出典：OWASP Gen AI Security Project）。

同じ資料は、権限の判断をLLMに任せず、接続先のシステムの側で確かめることも勧めています。

外から届く文面が指示になる

AIエージェントは、受信メールや取引先のファイル、Webページを読んで仕事をします。その中に「この資料を次のアドレスへ送ってください」といった文が紛れていると、AIがそれを指示として実行してしまうことがあります。

これをプロンプトインジェクションと呼びます。OWASPは、Webサイトやファイルなど外から入る内容でモデルの動きが変わるものを「間接プロンプトインジェクション」と呼んでいます。

そのうえで、確実に防ぐ方法があるかは分からないとしています（出典：OWASP Gen AI Security Project）。

そこで、紛れ込んだ指示に従ってしまっても、被害が小さく済むように権限と承認で囲っておくのが現実的な対策です。メールを読むAIには送信の権限を持たせず、外に出る操作の前には人が確かめる、といった形です。

生成AI全体のリスクは、生成AIのリスクと対策で整理しています。

AIに渡す鍵は三種類ある

AIエージェントに社内システムを操作させるとき、技術的に渡している「鍵」は、次の三つのどれかです。

鍵	期限	漏れたとき	AIに渡すなら
ログイン用のアカウント（IDとパスワード）	なし（止めるまで使える）	止めるまで使われ続ける	人と共用しない。AI専用で作る
APIキー	ないものも多い（自分で切る）	期限がなければ長く使われる	用途ごとに分け、期限を自分で決める
アクセストークン（OAuthで発行）	あり（自動で切れる）	期限までで使えなくなる	いちばん向く。範囲と期限を指定できる

いちばん手軽なのは、社員が日ごろ使っているIDとパスワードをAIのツールに設定する方法で、その日のうちに動きます。しかし、これがいちばん危ない渡し方です。

理由は、誰が操作したかの記録が、人とAIで混ざってしまうことです。問題が起きたとき、人の誤操作かAIの誤処理かを後から見分けられず、原因をたどる手がかりがなくなります。

APIキーは、システムが機械どうしの通信のために発行する鍵で、ログには「どのキーが使われたか」が残ります。ただし、期限のないキーも多く、漏れると長い期間、不正に使われるおそれがあります。

アクセストークンは、OAuthという仕組みで発行され、期限があらかじめ付いています。更新の仕組みは要りますが、漏れても被害の続く期間を短くできます。

おすすめは、AI専用のアカウントを作り、そこに期限付きのアクセストークンを結び付ける形です。ログの上で人とAIの操作を分けられ、漏れたときの被害も小さく抑えられます。

アクセストークンで渡した権限は、発行した側の画面で確かめられます。たとえばGoogleアカウントの「リンク済みアプリ」では、どのアプリにどのデータへのアクセスを許したかが一覧になります。

使わなくなった連携は、ここからいつでもアクセス権を削除できます（出典：Google アカウント ヘルプ）。

触らせる範囲を三つに分ける

AIの権限を、SaaSやデータベースの細かい設定画面から考え始めると迷います。チェック項目が細かすぎて、実際の業務との対応が見えなくなるためです。

先に、業務の側で「読む」「書き換える」「外に出す」の三つに分けてから設定画面に向かうと、決めることが大きく減ります。

読ませてよいもの

読み取りだけの権限なら、AIが解釈を誤って出力を間違えても、元のデータは壊れません。後からやり直せる範囲です。

そのため、読む権限は比較的広めに渡して構いません。過去の受注履歴、図面の一覧、社内の手順書、受信メールの本文などは、AIが回答や提案を作る材料になります。

AIの出力の質は、読める材料の質と量で大きく変わります。

ただし、読める範囲は、AIが回答として外に出しうる範囲でもあります。顧客の連絡先などの個人情報や、取引先から秘密保持契約で預かっている資料は、読む対象から外すか、伏せ字にしてから渡してください。

AIに渡すデータの範囲の決め方は、生成AIの情報漏洩対策と社内データを渡していい範囲で整理しています。

書き換えさせてよいもの

書き込みや更新は、データに変更が残ります。ただし、影響が社内のシステムに閉じていれば、誤りがあってもバックアップから戻したり、手で直したりできます。

AIに書き込ませてよいのは、業務の中で日々たまっていく記録です。

• 受注一覧に新しい注文を一行足す
• 商談の状態を「聞き取り済み」から「見積り作成中」へ変える
• 日報や問い合わせの記録を登録する

逆に、AIに直接書き換えさせてはいけないのは、業務の基準になるマスターデータです。

• 製品の単価表（単価マスタ）
• 取引先の基本情報や口座情報（取引先マスタ）
• アクセス権限の設定やシステムの設定

マスターデータが誤って書き換わると、その後の自動処理や会計の計算、発注がまとめて狂います。

そのため、マスターを変える権限は日々の自動化の鍵とは分け、人が管理画面を開かないと変えられない形にします。

外に出る操作

社外への送信や支払いを伴う操作は、一度実行すると取り消せません。次のような操作が当てはまります。

• 見積書や請求書のPDFを、取引先へメールで送る
• 仕入先へ発注データを送る
• 納期の回答や、問い合わせへの返信を送る

送ったデータはすぐに相手の手元に届くため、誤りや漏えいがあれば会社の信用に関わります。そのため、外に出る操作はAIだけで完結させないと決めてください。

これが、権限の設計でいちばん大切な線引きです。

外に出る操作には人の承認を挟む

取り消せない操作の手前には、人が中身を確かめて許可する工程（Human-in-the-Loop）を入れます。外に出る操作では、AIが用意するのは送る内容までとし、送信や実行のボタンを押せるのは人の担当者だけにします。

AIと外部のツールをつなぐ共通の仕様であるMCPも、ツールの呼び出しを人が拒否できる状態を保つよう求めています。

重要な操作の前に確認を出すことも、アプリの側に勧めています（出典：Model Context Protocol）。

承認者は二人以上にする

承認を入れると業務が遅くなる、という心配はよく聞きます。確認の材料がそろっていれば、一件ごとの確認は短く済みます。

滞る原因の多くは、承認する人が席を外していることです。承認できる人は、同じチームに二人以上（主と副）決めてください。

承認者が一人だけだと、その人がいない日に業務が止まります。やがて、承認を飛ばす抜け道が常態化する原因になります。

承認画面に判断材料を並べる

承認の画面に「金額：1,200,000円」と「承認」「却下」のボタンだけが出ても、承認する人は正しいかを判断できません。その結果、中身を見ずに承認を押すようになります。

承認画面には、次の三つを同じ画面に並べます。

1. 元になった依頼：受け取ったメールの原文、FAXの読み取り結果など
2. AIが作った内容：見積書の明細や宛先
3. 判断の基準になる過去のデータ：同じ取引先の過去の実績、標準の単価との差

この三つを見比べられれば、確認は形だけにならず、短い時間で確かな確認になります。

下は受注承認の画面の例です。読み取った明細と信頼度を取引先ごとに並べ、差戻しか承認かを選べるようにしています。

送る前に止める設計の具体例は、送る前に止める業務自動化の設計で紹介しています。

最小権限を実際の設定に落とす

最小権限の原則は、業務に要る最小限の権限だけを渡すという考え方です。言うのは簡単ですが、設定に落とすには決めることがあります。

次の四つを、順に決めてください。

AI専用のアカウントを作る

社員のアカウントやAPIキーをAIに使い回さず、AI専用のアカウント（サービスアカウント）を新しく作ります。名前は、たとえば svc-ai-billing@company.com のように、AI用と分かるものにします。

これだけで、監査ログの上で人の操作とAIの操作を分けられます。AIのツールをやめたり替えたりするときも、そのアカウントを止めればアクセスを確実に切れます。

担当者の異動や退職で、前任者のアカウントを消したら自動化が全部止まった、という事故も防げます。

Microsoftも、エージェントごとに別のIDを持たせ、エージェントどうしでIDを共有しないよう勧めています。IDを分けると、一つのエージェントだけを止めたり直したりでき、動きもたどりやすくなるためです（出典：Microsoft Learn）。

触れる範囲を絞る

データベースやクラウドの保存先の全体に、AIの権限を渡さないでください。範囲はできるだけ狭くします。

対象	絞り方の例
ファイルの保存先	「営業部」の中の「見積り下書き」フォルダだけ読み書きできる
データベース	受注のテーブルだけ更新できる。取引先マスタや支払いの情報には触れない
期間	直近1年に作られたデータだけ読める

ツールの側で細かく絞れない場合は、AIが読むための複製のデータベースや、共有を限った専用のフォルダを間に置きます。そこへ必要なデータだけを写して、AIに見せる作りです。

鍵の期限と保管を決める

発行するAPIキーやトークンには、必ず期限を付けます。期限があれば、業務が変わって使われなくなった権限が、時間とともに自然に切れます。

期限のない鍵は、作った本人も存在を忘れ、何年も放置されがちです。更新のたびに、この権限はまだ要るか、範囲を広げすぎていないかを見直す機会にもなります。

鍵の保管場所も決めておきます。APIキーやトークンを、ChatworkやTeamsなどの社内チャット、メール、社内Wikiに貼るのはやめてください。

チャットに貼った時点で、そのチャンネルを見られる人全員が、事実上その権限を持つことになります。

保管は、会社で一元管理するパスワード管理ツールか、クラウドのシークレット管理サービス（AWS Secrets Managerなど）で行います。誰がいつ鍵を取り出したかの履歴が残る場所に置いてください。

パスワード管理ツールの選び方は、パスワード管理ツール法人比較で紹介しています。

各社のエージェント機能で絞る

AIエージェントの製品や仕様にも、権限を絞る設定が用意されています。主なものを、公式の説明からまとめました。

仕組み・製品	権限を絞る設定	出典
MCP（共通の仕様）	認証はOAuth 2.1の草案にもとづく。必要な範囲（スコープ）だけを求め、ほかのサーバー向けのトークンは受け付けない	Model Context Protocol
Claudeのコネクタ	Team・Enterpriseのオーナーが、ツールごとに「Always allow」「Needs approval」「Blocked」を組織全体で決める	Claude ヘルプセンター
Claude Code	操作ごとに許可・確認・拒否のルールを書ける。拒否のルールが最優先で、管理者が配る設定は利用者が上書きできない	Claude Code Docs
ChatGPT（ChatGPT Workのクラウドブラウザ）	取り消しにくい操作や、お金・契約が関わる操作の前に確認を求める。サイトごとの許可も設定できる。有料プランのみ（Free・Goは対象外）	OpenAI ヘルプセンター
Microsoft Entra Agent ID	エージェントごとに専用のIDを持たせ、必要な権限だけを渡す	Microsoft Learn

Claudeのヘルプでは、Claudeで書き込みを許しても、元のシステムでその人に権限がなければ変更できないと説明しています。製品の設定は、社内システムの側の権限と重ねて使うものです。

なお、MCPの認証の決まりは任意で、自分のPCの中で動かすMCPサーバーは、環境に置いた資格情報を使うとされています。その場合は、鍵の保管と期限の決まりがそのまま当てはまります。

監査ログに残す項目と保存先

監査ログは、事故が起きてから作ることはできません。本番で動かす前に、何をどこに残すかを決めておきます。

基準は一つの問いにまとめられます。半年後に取引先から、御社のAIが何をしたか説明してくださいと求められたとき、見せられる記録がそろっているかです。

残す項目は七つ

AIエージェントの記録には、少なくとも次の七つを残します。

項目	記録する内容の例
実行した日時	秒まで。時間帯（タイムゾーン）も書く
きっかけ	受信メールの件名、定時の実行、担当者の指示
操作の種類	読む、登録、更新、削除、外への送信
対象のデータ	顧客のID、見積番号、ファイルの場所
結果	成功、失敗、承認待ちで止めた、権限がなく拒否された
人の承認	承認した人と日時。自動で実行したかどうか
実行した主体	人のIDか、AI専用アカウントのIDか

とくに抜けやすいのが、実行した主体です。これがないと、何千行のログがあってもどれがAIの動きかをたどれず、監査の記録として役に立ちません。

失敗や、権限がなく拒否された記録も必ず残してください。運用を直すときに役立つのは、成功の記録より、失敗と修正の履歴です。

MCPの仕様も、アプリの側でツールの利用を監査のために記録するよう勧めています（出典：Model Context Protocol）。

できれば、使ったAIのモデルの名前も一緒に残してください。モデルが入れ替わった日を後から確かめられます。一方で、APIキーや個人情報そのものはログに書かないようにします。

ログの例を読む

下は、監査ログの記録の例です。

上から順に追うと、業務の流れが見えます。注文メールからAIが受注の下書きを作り、検査役のAIが過去の実績と比べて注意を出しています。

それを受けて人が単価を直して承認し、そのあとで初めて取引先へのメールが送られています。

失敗した行と、それを受けて人が手で入力した行が並んで残っているため、どこでAIが止まり、誰が引き継いだかを後からたどれます。

この例には「きっかけ」の列がありません。実際に組むときは、受信メールの件名や定時の実行などを記録する列を足してください。

自動で追記し、自社に残す

監査ログは人が手で書き写すものではなく、システムが自動で追記していく（書き換えずに足していく）仕組みにします。手で書く運用だと、忙しい時期やトラブルの最中など、いちばん大事な場面の記録が抜けます。

置き場所は、AIのアカウントからは消したり書き換えたりできない場所にします。記録する側と記録を直せる側を分けておかないと、誤った処理の跡ごと消えてしまうおそれがあります。

また、記録の保管をAIのツールやSaaSの履歴機能だけに頼るのは危険です。解約すると過去の記録が見られなくなることがあり、保存期間にも上限があります。

主なサービスで記録が残る期間は、2026年9月時点で次のとおりです。

サービス	記録が残る期間
Claude（Enterprise）	監査ログは直近180日分を書き出せる（監査ログはEnterpriseのみ）
Microsoft 365（Purview Audit Standard）	監査ログは180日
Google Workspace	管理のログ、ドライブのログなど多くは6か月
Power Automate	クラウドフローの実行履歴は30日
n8n Cloud	実行履歴はStarter 7日、Pro 30日

出典：Claude ヘルプセンター、Microsoft Learn（Purview）、Google Workspace ヘルプ、Microsoft Learn（Power Automate）、n8nの料金ページ

そのため、ツールの機能とは別に、自社で管理する保存先（クラウドの保存領域やスプレッドシートなど）へ記録を送って残す仕組みを作ってください。形式のきれいさより、自社で持ち続けて消えないことを優先します。

保存する期間は、取引先との契約や業界の決まり（医療・金融、ISOの認証など）で定めがあれば、それに合わせます。定めがなければ、上の表の期間より長く、年をまたいで説明を求められても答えられる期間を自社で決めてください。

月に一度の点検では、AIが処理した件数、人が直した件数、止まった件数を見ます。点検の進め方は、次の記事で紹介しています。

本番の前に確かめること

権限と監査ログを整えても、モデルの更新や想定外の入力で、AIが誤った処理を続けることはありえます。本番で動かす前に、止め方と、よくある失敗を確かめておきます。

止める・見える・戻れるをそろえる

トラブルのときにまず要るのは、すぐにAIを安全に止める手段です。次の三つを、同時にそろえてください。

• 止められる：管理画面のボタン一つか、コマンド一つで全体を止められる
• 見える：AIがいま何をしていて、どこまで進んだかが見える
• 戻れる：止めたあと、すぐに人の手作業へ切り替えられる

見落としやすいのが、戻れるです。AIを止めると業務も全部止まる作りだと、担当者は様子がおかしいと気づいても、止めるボタンを押せなくなります。

AIを入れる前の作業手順書や手入力の画面は、自動化したあとも捨てずに残してください。緊急時に手作業へ切り替えられる体制が、業務を続けるための備えになります。

止めたあと、何を確かめてから再開するかも決めておきます。原因が分からないまま再開すると、同じ誤りがまた起きます。

よくある設計の失敗を避ける

AIを業務につなぐときに起こりやすい失敗を、表にまとめました。自社の作りが当てはまっていないか、確かめてください。

よくある失敗	起きること	避け方
社員のアカウントを使い回す	人とAIの操作が混ざり、誰の操作か説明できない	AI専用のアカウントを作る
試しに管理者権限を渡す	検証用の広い権限が、見直されないまま本番に残る	本番の前に検証用の権限を消す
ログをツール任せにする	解約や保存期間の上限で、過去の記録が消える	自社の保存先へ送る
APIキーを社内チャットに貼る	過去のやり取りを見られる人全員が、鍵を持つことになる	パスワード管理ツールなどに置く
外への送信の承認者が一人だけ	不在の日に業務が止まり、承認を飛ばす運用になる	承認者を二人以上決める
退職者の権限でAIが動き続ける	辞めた社員のIDでAIが動き、監査で指摘を受ける	AI専用のアカウントに切り替える

どれも、急いで事前の設計を省いた結果として起こります。試しに動かしてみること自体はよいのですが、本番の前に、検証用の権限を消して本番用の権限に切り替える工程を挟んでください。

まとめ

AIエージェントに社内システムの権限を渡すときは、次の順で設計を進めてください。

1. 範囲を分ける：読む・書き換える・外に出すの三つに分ける
2. 承認を挟む：外に出る操作の前に、二人以上の承認者を置く
3. 専用の鍵にする：AI専用のアカウントを作り、範囲と期限を絞る
4. 記録を残す：七つの項目を、自社の保存先へ自動で送る
5. 止め方を決める：止める手段と、手作業への戻り道をそろえる

システムをつないでから権限を狭めようとすると、業務が止まり、直す手間も大きくなります。つなぐ前に設計を決めておくことが、安全と効率を両立させる近道です。

どこまでをAIに任せ、どこで人が確かめるかを一緒に決めたい場合は、当社にご相談ください。