IAM（ID・アクセス管理）

IAMとは、誰がどのシステムに入れて、そこで何をしてよいかを管理する仕組みのことです。 Identity and Access Managementの略で、アイアムと読みます。

別表記：IAM／ID・アクセス管理／アイデンティティ管理／ID管理／アクセス管理／Identity and Access Management

何を管理しているのか

会社には、メール、ファイル共有、会計システム、顧客管理など、たくさんのシステムがあります。そのすべてについて、誰が使えるのか、使える人は何をしてよいのかを決めておかなければなりません。この「誰が」と「何を」を一か所で管理するのがIAMです。

社員が入社すると、IAMにその人のIDが登録されます。IDに所属部署や役職が紐づき、それに応じて使えるシステムと権限が決まります。異動すれば権限が変わり、退職すればIDが止まります。人事の動きに合わせてIDの一生を管理する、というのが基本の姿です。

認証と認可は別のものです

IAMを理解するうえで、最初に押さえておきたい区別があります。

認証は、「あなたは誰ですか」を確かめることです。パスワード、スマートフォンへの通知、指紋などで本人であることを確認します。ログイン画面でやっていることが認証です。

認可は、「あなたは何をしてよいですか」を決めることです。ログインできたとしても、経理のフォルダを開けるかどうか、顧客データを書き換えられるかどうかは別の話です。これを決めるのが認可です。

ログインできることと、何でもできることは違います。IAMはこの両方を扱いますが、AIエージェントの文脈で問題になるのは、ほとんどの場合、認可のほうです。

日々の業務の中で、どう動いているか

朝、パソコンを開いてひとつのIDとパスワードでログインすると、メールもチャットもファイル共有も、それぞれ別にログインしなくても使えます。これはシングルサインオン（SSO）と呼ばれる機能で、IAMが各システムに「この人は本人です」と伝えています。

営業部の人が人事部のフォルダを開こうとすると、開けません。IAMがその人の所属を見て、権限がないと判断しているからです。

ある人が課長に昇進すると、承認システムで部下の申請を承認できるようになります。IAM上の役職が変わり、役職に紐づく権限が付いたからです。

退職すると、翌日からどのシステムにも入れなくなります。IAMでIDを止めると、各システムへの入口が一斉に閉じます。

こうした動きは、普段は意識されません。意識されないほど、きちんと機能しているということでもあります。

人以外のIDもあります

IAMが管理するのは、人だけではありません。システム同士が自動で連携するときにも、IDが必要です。夜間に自動で動くバッチ処理、別のシステムからデータを取りに来るプログラム、クラウド上で動くアプリケーション。こうしたものにも、サービスアカウントやAPIキーといった形でIDと権限が割り当てられます。

人のIDに比べると、人以外のIDは管理が緩くなりがちです。誰が作ったのか分からない、いつから使われているのか分からない、権限が必要以上に広い、という状態になりやすい領域です。AIエージェントは、この「人以外のID」の仲間として入ってきます。

AIエージェントを入れると、何が足りなくなるのか

既存のIAMで対応できる部分は多くあります。AIエージェントにIDを割り当て、使えるシステムを限定し、ログを取る。ここまでは、サービスアカウントの管理と同じです。

ただ、AIが業務を実行するようになると、IAMが前提にしていなかった性質がいくつか出てきます。

主体が人ではありません。 社員一人ひとりに割り当てる前提で設計されているため、必要に応じて生成され、役目を終えれば消えるAIは、人事システムと連動した棚卸しの対象になりません。誰も管理していないIDが増えていく原因になります。

「誰の代理か」を表現できません。 人のアカウントであれば「本人が操作した」で話は終わります。AIの場合、そのAIが誰の委任を受けて動いているのかが分からなければ、実行の正当性を判断できません。「このAIは購買担当」といった役割を割り当てることはできても、「誰が、いつ、何を委任したか」までは表せません。

環境をまたぐと届きません。 AIが別のAIに作業を渡す、取引先のシステム上で処理が続く、といった構成では、自社のIAMの外側に権限の情報が出ていきます。渡された側は、こちらのIAMの設定を知りません。

期限の感覚が違います。 人のアカウントは年単位で運用しますが、AIに与える権限は、本来もっと短くてよいものが多くなります。1件の業務のためだけに数時間だけ有効な権限を出す、という運用が現実的ですが、IAMは年単位の運用を前提に作られています。

VCとの関係

VC（Verifiable Credentials）は、IAMの代わりになるものではありません。AIエージェントがシステムに接続するには、結局IAM上のIDが必要です。

VCが足すのは、IAMが表現できなかった「誰の代理で、何をどこまで、いつまで」という委任の情報を、AIエージェント自身に持たせて、受け取った側が検証できるようにする層です。IAMが「このAIは誰か」を扱い、VCが「このAIは誰から何を任されているか」を扱う、という分担になります。

社内で完結し、既存のIAMが届く範囲であれば、IAMだけで足りる場面もあります。足りなくなるのは、委任の内容を証明する必要が出たとき、環境をまたぐとき、権限を短い期限で細かく出し入れしたいときです。

よくある誤解

IAMがあればAIエージェントも安全か。 そうとは言えません。ただし「IAMでは何もできない」わけでもありません。IDの割り当てと基本的な権限の限定はIAMで行い、足りない部分を見極めることが実務上の判断になります。

IAMとはログイン画面のことか。 ログインは認証の部分で、IAMの一部です。IAMの本体は、誰にどの権限を与えるかを決め、変更し、記録する仕組みのほうにあります。

IAMを入れれば権限は自動的に最小になるか。 なりません。IAMは権限を管理する道具であって、どこまで絞るかを決めるのは運用です。多くの企業で、権限は入れるときに広めに付けられ、その後見直されないまま残ります。IAMがあることと、権限が適切に絞られていることは別です。

一覧に戻る