特権IDの管理とは何を守る？｜AIに渡す権限の線引き

「管理者の権限を持つアカウントは3つまで減らしました。特権IDの管理としては、これで足りているという理解で合っていますか」「作業のたびに申請して承認を待つ形にすると、夜間の障害対応が回らなくなります」。情報システム部門にこの話が持ち込まれるとき、論点はたいていアカウントの本数と申請の手間の2つに寄っていきます。どちらも現場としては切実ですが、守ろうとしている対象が少しずれています。特権IDの管理が守るのは、強い権限を持つアカウントの本数ではなく、その権限が使える状態にあった時間と、その間に誰が何をしたかの記録です。本数を3つに減らしても、残った3つが常時使えるままなら、危ない時間の長さは何も変わっていません。この記事では、常時付けたままの権限を必要な時間だけ貸す形へ移す道筋と、記録の残し方、棚卸しの回し方を順に見ていきます。強い権限をAIエージェントに持たせたときに何が変わるかは、後半に独立した項を置いて扱います。

「アカウントを減らせば済む」で止まると、危ない時間は減らない

特権IDとは、設定そのものを変えられる、他人の記録を読める、記録を消したり止めたりできるといった、通常の利用者には与えられていない操作ができるアカウントの総称です。現場での呼び方は割れていて、管理者アカウント、システム管理者、上位権限、といった言い方が同じものを指していることがあります。呼び方が割れたまま議論を始めると、対象の範囲が人によって違うまま話が進むので、最初に何ができるアカウントを特権と呼ぶのかを一枚に書き出すところから始めるのが早道です。

本数を減らす取り組み自体は正しい方向です。ただ、減らしたあとに残った数個が担当者の手元に常時付いたままなら、攻める側から見た的の大きさは変わりません。むしろ、本数が少ないぶん「その1つを取れば全部が開く」状態に寄っていきます。減らす作業と、使える時間を短くする作業は、別々に進めるものです。前者だけを終えて安心してしまうのが、この分野でいちばんよくある止まり方です。

数字の側から見ても、力点は内部の悪用より外からの持ち込みに寄っています。米国の通信会社が毎年出している侵害調査報告の2025年版は、22,052件の事案と、そのうち確認された12,195件の侵害を139か国から集めて分析したものですが、そこでは侵害の入口として最も多いのは今も認証情報の悪用で、脆弱性の悪用が20%まで伸びてそれに迫った、と書かれています。一方で、権限の乱用そのものを類型とする侵害は6%で、前年の8%から下がっています。つまり、内部の人が悪意をもって権限を使う場面より、外から誰かの資格情報を手に入れて、その人の正規の権限で入ってくる場面のほうがずっと多い。常時付いたままの強い権限は、そのまま外から見た入口の価値になります。

特権の強さは3つに割れる。守る対象はそこで変わる

特権をひとかたまりで扱うと、対策も一律になって重くなります。実務では、消せる・他人になれる・記録を止められるの3つに割ると、先に手を付けるべき場所がはっきりします。この3つは危険の性質が違うので、同じ承認の重さで扱う必要もありません。

強さの種類	できてしまうこと	外れたときに起きること	扱いの重さ
消せる	データや設定を削除する。初期化する。上書きする	元に戻せない。復元できても、止まっていた時間は戻らない	最も重い。単独では出さない
他人になれる	他の利用者の資格でそのまま操作する。代理でログインする	操作記録がその人の名前で残り、後から本人と区別できない	重い。使うたびに理由を残す
記録を止められる	監査記録を消す。取得を止める。保存期間を短くする	ほかの2つを使った証拠ごと消える。調査が成立しなくなる	最も先に切り離す

3つのうち、真っ先に日常の権限から切り離すのは記録を止められる力です。記録を消せる人が同時に消せる人でもあると、事故が起きたときに何が起きたかを再現できません。監査記録の設定を変えられる権限は、業務の運用担当ではなく、監査や内部統制の側に置くのが原則です。小さな組織で人を分けられない場合でも、記録の保存先だけは書き換えのできない場所に写しておくと、同じ効果の一部は得られます。

数えるのは本数ではなく、強い権限が使えていた時間

特権IDの状態を報告するとき、多くの現場が出すのは「管理者アカウント数」です。この数字は減らしても頭打ちになり、ある時点から動かなくなります。代わりに置くとよいのが、月あたりに強い権限が有効だった延べ時間です。付与記録の開始時刻と終了時刻の差を全件足すだけで出ますし、常時付与のアカウントが1つ残っているだけで、この数字は月に720時間ほど積み上がるので、残っていることが数字の側から見えるようになります。

この測り方に替えると、議論の中身も変わります。本数で語ると「減らせない理由」の話になりますが、時間で語ると「この作業に何分必要か」の話になります。後者のほうが現場と合意しやすく、30日ずっと開けておく必要はないが、40分は要る、という形で落とせるようになります。国際規格の管理策でも、特権的なアクセス権は出来事ごとに割り当てることと、有効期限を付けることが求められています。（情報セキュリティの管理策集ISO/IEC 27002:2022の8.2「特権的アクセス権」）

測り始めた最初の月は、数字がひどく大きく出ます。そこで慌てて全部を止めにいくと業務が止まるので、最初の3か月は数字を下げることではなく、記録が取れている状態を作ることを目標にします。取れていない経路（機器に直接入る回線、保守業者が使う経路、緊急時用のアカウント）を洗い出し、そこから記録が出るようにするだけで、翌月の数字の意味がまったく変わります。

常時付与と都度付与。運用の重さがどこへ移るか

常時付与は、担当者のアカウントに強い権限を付けたままにする形です。平時の手間はほぼゼロで、障害のときにすぐ動けます。そのかわり、事故が起きたときの調査が重くなります。誰がいつその権限を使ったのかを、操作記録の山から探し出すところから始まるからです。都度付与は逆で、平時に申請と承認の手間がかかり、そのぶん事故のときに誰が、いつからいつまで、何のために開けていたかが最初から一覧になっています。

つまり選んでいるのは「楽か大変か」ではなく、手間を平時に払うか、事故のときにまとめて払うかです。この言い方に置き換えると、決裁の場での話が早く進みます。監査や取引先の点検を受ける予定がある組織、外部の委託先が作業に入る組織では、都度付与に寄せたほうが総量としては軽くなります。

よくある反論は「夜間や休日に承認者がつかまらない」です。これは都度付与そのものへの反論ではなく、非常時の経路を別に用意していないことへの反論です。平時の申請と、非常時に封を切って開ける手順は、別の仕組みとして分けて設計します。分けずに「夜間もあるから常時付与のままで」とすると、非常時のための余裕が365日ぶん常時開いている状態になります。

申請・承認・期限・記録。4つそろって初めて運用になる

都度付与を始めた組織でよく起きるのが、申請だけを作って残り3つを作らない形です。申請書は増えたのに権限は返ってこない、承認は上長が押すだけで中身を見ていない、という状態になり、手間だけが残ります。4つは互いに補い合っているので、1つでも欠けると運用として成立しません。

• 申請に書く4項目：どのシステムの、どの強さの権限を、何のために、いつからいつまで
• 承認するのは作業者の上長ではなく、そのシステムの持ち主。上長は業務の必要性、持ち主は影響範囲を見る
• 期限は作業予定時間に余裕を足した長さで、既定で自動的に切れる。延長は再申請にする
• 記録は申請・付与・操作の3つを同じ番号でひもづける。あとから1本の線として読めるようにする

国際規格の管理策8.2には、使っている間その人が特権を持っていることを本人に明示する、特権を使う直前にもう一度本人確認をするという項目もあります。地味ですが、これは「うっかり強い権限のまま普段の作業をする」事故に効きます。権限を上げたことを本人が忘れている時間が、いちばん事故が起きやすい時間帯です。

承認を形だけにしないための小さな工夫として、承認画面に「この権限で何ができてしまうか」を短く出しておく方法があります。強さの3分類のどれに当たるかを1行で見せるだけでも、消せる権限の申請だけは承認者が止まるようになります。承認者が判断できる材料を渡さないまま押させると、記録上は承認があるのに、実質は誰も見ていない状態が積み上がります。

共用のアカウントが消えない理由と、棚卸しの回し方

共用アカウントは、なくすべきだと分かっていても残ります。残る理由はだいたい4つで、機器やソフトが個人ごとのアカウントに対応していない、夜間の交代で引き継ぐ運用が固まっている、設定を変えると業務が一時的に止まる、作った当人がもういない、のどれかです。理由が分かれば、消せるものと消せないものを分けて扱えます。国際規格の管理策8.2でも、共用の資格情報を使わせないことと、特権には個人ごとの別のアカウントを割り当てることが求められています。

棚卸しで見落とされやすいのが、業務ソフトの中に埋め込まれた資格情報です。夜間に自動で走る処理や、他システムとつなぐための設定に、強い権限のアカウントが直接書き込まれていることがあります。人が使う共用アカウントを消しても、機械が使っている分が残っていれば、鍵は開いたままです。

作業の記録は「誰の判断だったか」までひもづけて残す

記録が取れていない現場は、実はあまり多くありません。多いのは、記録は取れているのにつながっていない現場です。申請の記録は業務システムに、付与の記録は認証の仕組みに、操作の記録は各サーバーに、それぞれ別々の形式で残っている。事故が起きてから3つを突き合わせようとすると、時刻の基準がずれていたり、アカウント名の表記が違っていたりして、そこで数日を使うことになります。

防ぎ方は単純で、申請に採番した番号を、付与と操作の記録にも一緒に載せることです。番号が通っていれば、あとから1本の線として読めます。番号を通せない仕組みが混ざっている場合は、せめて時刻の基準を全部そろえておくと、突合の手間が桁で変わります。

保存期間は、何のために残すのかで決まります。社内の調査だけなら数か月で足りますが、取引先の点検や監査の対象になっているなら、その周期を1回またぐ長さが要ります。国際規格の管理策8.2でも、特権的なアクセスの活動はすべて記録することと、特権的アクセス権を定期的に見直すことが求められています。見直しの結果を残しておかないと、次の点検で同じ説明をゼロから作り直すことになります。

非常時に開ける口を、平時のうちに決めておく

障害が起きた深夜に、承認者がつかまらない。この場面のために、国際規格の管理策8.2は非常時の開封手順を置くことを求めています。封をした形で保管しておいた資格情報を、決められた条件のときだけ取り出して使い、使ったら必ず入れ替える、という組み立てです。重要なのは、これを非常時に考えないことです。非常時に考えると、その場の判断で常時付与に戻す、という結論になります。

• 開けられる人を決める（1人ではなく、2人以上のうち誰かが開けられる形にする）
• 置き場所を決める（封をした紙の金庫か、専用の保管の仕組みか。担当者の引き出しは不可）
• 開けたあと何時間以内に、誰に報告するかを決める
• 使ったあとの入れ替えを、誰がいつまでに実行するかを決める
• 開けたこと自体が自動で通知される状態にしておく（事後に気づく形にしない）

この5つを紙1枚にして、夜間の連絡網と同じ場所に貼っておくのが実務としては現実的です。年に1度、実際に開けてみる訓練をしておくと、封の場所が変わっていた、書いてある人がもういない、といった綻びが先に見つかります。非常用の手順は、使わないまま古くなるのがいちばんの故障です。

委託先に強い権限を渡すときに増える確認

先ほどの侵害調査報告の2025年版では、第三者が関わった侵害の割合が前年の15%から30%へ倍増したと報告されています。同じ報告で、外部に漏れた秘密情報が直るまでにかかった期間の中央値は94日でした。自社の中だけで特権IDを締めても、委託先の側が緩ければ、そこが同じ扉の別の入口になります。

委託先に渡すときに追加で決めるのは4つです。個人が特定できるアカウントを人数分配ること（会社単位で1つにしない）、契約の終了日と権限の失効日を同じ日にそろえること、再委託先の作業者にも同じ扱いが及ぶことを契約に書くこと、作業の記録を自社側でも受け取れる形にしておくこと。委託先の担当者が交代したことを、自社が知る仕組みがないのが典型的な穴です。

国内では、独立行政法人情報処理推進機構（IPA）の「組織における内部不正防止ガイドライン」第5版が参照されることが多く、10の観点のもとに33項目の対策が並んでいます（2022年4月公開、2025年5月更新）。委託先の管理と資産の管理はそれぞれ独立した観点として置かれているので、社内向けの規程を作るときの目次としても使えます。ただし、ここに書かれているのは考え方であって、自社の業務にどう当てはめるかは自分たちで決める必要があります。

付与と操作の記録を突き合わせる作業は、AIに渡してよい

特権IDの運用がしんどいのは、判断が難しいからではなく、突き合わせる量が多いからです。ここは生成AIに渡して構いません。渡してよいのは、申請・付与・操作の3つの記録の突合、90日間まったく使われていない権限の洗い出し、申請文と月次の報告文の下書き、例外として認めたものの一覧化のあたりです。どれも、答えが記録の中にあり、人が読めば確認できる種類の仕事です。

一方で、人の手元に残すものもはっきりしています。権限を出すかどうかの承認、非常時に封を切るかどうかの判断、権限を取り上げる実行の3つです。とくに最後は、間違えると業務が止まります。AIが出した「不要と思われる権限の一覧」は候補であって決定ではないので、そのまま実行に流す作りにしないでください。洗い出しは自動でよいが、剥奪は人が押す。ここを分けておかないと、月末の締めの日に止まります。

運用の決まりとして1行だけ足しておくと効くのが、根拠の書かれていない指摘は採用しないです。「この権限は不要と思われます」だけの出力は差し戻し、どの記録の何日から何日までを見てそう言っているのかを必ず添えさせます。根拠を書かせると、AIの側も曖昧な断定をしにくくなり、人が確認する時間も短くなります。確認できなかったものは「判断できない」と出させる形にしておくと、無理に埋めた答えが混ざらなくなります。

AIエージェントに強い権限を持たせると、人と3つ違う

ここからが、従来の特権ID管理と決定的に違う部分です。同じ強さの権限でも、持たせる相手がAIエージェントになると、危険の形が3つの点で変わります。1つ目は24時間動くこと。人は寝ますが、自動で走り続ける仕組みは寝ません。同じ権限を1週間渡した場合でも、実際に使われうる時間は人の数倍になります。

2つ目は失敗しても止まらないことです。人は違和感で手が止まります。「この件数はおかしい」と思った時点で確認に行く。AIエージェントは同じ手順を同じ速さで繰り返すので、間違った条件で走り始めると、間違ったまま全件を処理し終えます。人の権限は事故を1件で止められるが、AIの権限は最後の1件まで走り切る。だからこそ、件数の上限を権限の側に付けておく必要があります。

3つ目は誰の指示だったかが残らないことです。担当者のアカウントで動かすと、記録にはその人の名前だけが並び、本人が指示した分と、仕組みが自動で動いた分の区別がつきません。アプリの安全性を扱う国際的な非営利の取り組みが2025年に公表した、大規模言語モデルを使うアプリ向けの危険度一覧では、この種の問題が「与えすぎた裁量」として整理され、原因を余分な機能・余分な権限・余分な自律の3つに分けています。対策として挙げられているのも、機能を減らす、権限を減らす、影響の大きい操作は人の承認を必須にする、利用者の資格で動かす、といった順番です。

AIに渡す権限は読む・書く・消すで分け、消すは渡さない

実務に落とすときは、権限をまとめて渡さず、読む・書く・消すの3つに割って考えます。読むは参照だけ。書くは作成と更新で、あとから戻せる範囲。消すは削除・上書き・設定変更で、戻せない操作です。先の危険度一覧にも、商品の表を参照するだけの用途ならその表への読み取りだけを与え、ほかの表には触らせない、という例が載っています。

渡し方	できること	渡してよい場面	付ける条件
読むだけ	既存のデータや記録を参照する。集計する。要約する	調査・下書き・突合。最初はここから始める	対象を必要な範囲に限る。件数の上限を付ける
書くまで	下書きを作る。作業用の場所に結果を置く。起票する	人がそのあと確認して確定する工程	本番ではなく下書きの置き場に書かせる。確定は人
消すは渡さない	削除する。上書きする。設定を変える。権限を配る	原則として渡さない	どうしても必要なら、人の承認を必ず挟む形に限る

「書く」も一枚岩ではありません。下書きの置き場に書くのと、本番のデータに直接書くのは、まったく違う操作です。多くの現場では、下書きの場所までを渡し、本番へ移すところに人を置くだけで、実務の速さはほとんど落ちません。承認を挟む位置は「重要そうな作業」ではなく、戻せなくなる一歩手前に置きます。この基準なら、どの工程に人を置くかで議論が割れません。

実務仕様：期限・保存期間・例外の扱い

運用として決めておくと、あとで揉めない項目をまとめます。数字は組織の規模や監査の周期で変わるので、そのまま使う値ではなく、決め方の目安として読んでください。大事なのは値そのものより、誰が決めて、いつ見直すかが決まっていることです。

• 権限の有効期限：作業予定時間に余裕を足した長さ。既定で切れて、延長は再申請
• 使われていない権限の判定：直近90日の操作記録がないもの。年末年始をまたぐ期間は除いて数える
• 記録の保存期間：社内調査だけなら数か月。取引先の点検や監査があるなら、その周期を1回またぐ長さ
• 例外の扱い：期限を決めて認める。無期限の例外は作らない。一覧にして四半期ごとに読み直す
• 見直しの周期：共用アカウントの棚卸しは四半期、非常用手順の訓練は年1回、規程の見直しは年1回

例外の扱いだけは、少し強く決めておくことをおすすめします。特権IDの運用が崩れるときは、たいてい「今回だけ」で認めた例外が期限なしのまま残り、翌年には誰もその経緯を説明できなくなる、という順番で崩れます。例外を認めた日、認めた人、いつまでか、その後どうするかの4項目を書いた行を1つ足すだけで、1年後の棚卸しの手間がまったく変わります。

定着しない運用に共通する形

特権IDの管理は、仕組みを入れた時点では動いていて、半年から1年かけて静かに崩れることが多い分野です。崩れ方には決まった形があります。下に並べたものは、どれも「入れた直後は問題がなかった」ものばかりです。

• 管理者アカウントの本数だけを報告し、使えた時間を測っていない
• 申請の仕組みだけ作り、期限で自動的に切れる作りにしていない
• 承認者に、その権限で何ができるかの材料を渡さないまま押させている
• 非常時の手順を作らないまま都度付与に移し、結局は常時付与へ戻している
• 共用アカウントを人の分だけ消し、仕組みの中に埋め込まれた分を残している
• 記録を消せる権限を、運用の担当者が同時に持っている
• 委託先に会社単位で1つのアカウントを渡し、担当者の交代を把握していない
• AIが出した「不要と思われる権限」の一覧を、人の確認なしで剥奪に流している

並べてみると、共通しているのは入口（付与）だけを整えて、出口（返却・失効・剥奪）を作っていないことです。特権IDの運用は貸し借りなので、返してもらう側の仕組みがないと、貸した分だけ積み上がります。新しく何かを入れるより、いま貸したままになっているものを1つ返してもらうほうが、危ない時間の合計は早く減ります。

よくある質問

小さな組織で、人を分けられません。どこから手を付ければよいですか

人を分けられないときに最初にやるのは、記録の分離です。操作記録の保存先だけを、その人が書き換えられない場所に写します。権限そのものが分けられなくても、あとから何が起きたかを再現できる状態は作れます。そのうえで、消せる権限を使う作業だけ、作業の前後に別の人へ一報を入れる運用にすると、実質的な二人体制に近づきます。

都度付与にすると、障害対応が遅くなりませんか

平時の申請と非常時の開封を分けていれば、遅くなりません。遅くなるのは、非常時にも平時と同じ申請を通させている場合です。非常時の手順では、承認を事前に済ませておき（この条件が起きたらこの人が開けてよい、という形で先に決めておく）、実際に開けたときは事後に報告させます。順番を入れ替えるだけで、待ち時間はほぼ消えます。

AIエージェントに、人の担当者アカウントを使わせてはいけませんか

避けたほうがよい、というのが実務の答えです。人のアカウントで動かすと、記録がその人の名前に化けて、本人の操作と自動の操作を後から分けられなくなります。また、その人が異動や退職でいなくなった瞬間に仕組みが止まります。AIエージェント側の資格情報の設計そのものは別の記事で詳しく扱っていますが、本記事の範囲で言えば、人と同じ権限を丸ごと渡さないという一点だけは外さないでください。

使われていない権限は、すぐ消してよいですか

すぐには消さず、いったん止めてから消すのが安全です。年に1回しか動かない業務が、90日の判定では「使われていない」に見えることがあります。止めた状態で1か月置き、誰からも申し出がなければ消す。この一段を挟むだけで、決算や年次の処理を止める事故はほぼ防げます。止めた履歴を残しておけば、戻すときも早く済みます。

記録はどこまで細かく残せばよいですか

目安は、誰が・いつからいつまで・どの権限で・何のためにの4つが1行で読めることです。操作の1つ1つを全部残すと量が膨らみ、かえって読まれなくなります。細かい操作記録はシステム側に任せ、特権IDの運用として管理するのは貸し借りの記録に絞ると、月次の確認が現実的な時間に収まります。

まとめ

特権IDの管理は、管理者アカウントを何本に減らしたかを競う作業ではありません。見るべきなのは、強い権限が使える状態にあった時間と、その間に誰が何をしたかを後から再現できるかどうかです。権限を消せる・他人になれる・記録を止められるの3つに割り、記録を止められる力から先に日常の権限と切り離す。申請・承認・期限・記録の4つをそろえ、非常時に開ける口は平時のうちに封をした形で用意しておく。AIエージェントに強い権限を渡すときは、24時間動くこと、失敗しても止まらないこと、指示の主が記録に残らないことの3点を前提に、読む・書く・消すで分けて、消すは渡さない。突合と洗い出しはAIに任せ、出す判断と取り上げる実行は人が持つ。次の棚卸しでは、本数の代わりに延べ有効時間を1行だけ足してみてください。議論の中身が変わります。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。