【警察庁・総務省データ】LDAPとは｜ADとの関係、不正アクセス届出の33.7%はID・パスワード管理不備（2025年）

2026年10月27日

業務システムやVPN、複合機の設定画面で「LDAPサーバー」という項目を見かけることがありますよね。情シス担当者になったばかりだと、次のような疑問を持つ方も多いのではないでしょうか。

LDAPとActive Directoryは同じものなのか、違うものなのか分からない
設定画面の「ベースDN」「バインドDN」に何を入れればよいのか分からない
SaaSが増えてきて、社内のADだけでIDを管理し続けてよいのか迷っている

結論から言うと、LDAPはディレクトリサービスに情報を問い合わせるための通信の決まり（プロトコル）です。Active Directory（AD）は、そのLDAPに対応したMicrosoftのディレクトリサービス製品です。

この記事では、LDAPの仕組みとデータ構造、ADとの関係、認証連携での使われ方を解説します。あわせて、警察庁・総務省・IPAの公的データから、IDを一か所で管理する仕組みが求められる背景と、クラウドID基盤への移行の考え方を整理します。

この記事のポイント

LDAPはディレクトリサービスに問い合わせるための標準プロトコルで、Active DirectoryはLDAPに対応したMicrosoftのディレクトリサービス
2025年の不正アクセス届出では、被害原因の33.7%がID・パスワード管理の不備だった（警察庁・総務省・経済産業省「不正アクセス行為の発生状況及びアクセス制御機能に関する技術の研究開発の状況」）
クラウドサービスを使う企業のうち、認証システムを選んだ割合は2025年に16.0%（総務省「令和7年通信利用動向調査の結果（概要）別紙2」）。ただし、LDAPやADの利用率を示す公的統計はありません

＼　情シス専門オンラインスクール　／

🎁 今だけ特典！

【期間限定】
トライアル申込者全員に
「IT管理に使える4大テンプレート」
無料プレゼント！

💻 IT資産管理台帳
🧾 PC利用規定テンプレート
🔐 パスワードポリシーサンプル
🌐 IPアドレス管理表

＼無料で全部もらう／
👉 トライアルに申し込む

LDAPはディレクトリサービスに情報を問い合わせるための標準プロトコル

LDAPは、ディレクトリサービスに対して情報の検索や登録を行うための通信の決まり（プロトコル）です。LDAPそのものがユーザー情報を保存しているわけではありません。

情報を持っているのは、LDAPで問い合わせを受け付けるディレクトリサービス側です。この側のサーバーを「LDAPサーバー」と呼びます。

ポイント

LDAP: ディレクトリに問い合わせるための通信の決まり
ディレクトリサービス: ユーザーや端末の情報を持ち、問い合わせに答える仕組み
Active Directory: LDAPに対応した、Microsoftのディレクトリサービス製品

ディレクトリサービスは社員・端末・組織の情報を一か所にまとめて管理する仕組み

ディレクトリサービスは、社員や端末、組織の情報を一か所に登録し、社内のシステムから共通で参照できるようにする仕組みです。

情報を一か所にまとめる理由は、システムごとにIDを作る手間をなくすためです。業務システムやファイルサーバーが同じディレクトリを参照すれば、社員のIDとパスワードを1組だけ管理すれば済みます。

ディレクトリに登録される主な情報は次のとおりです。

ユーザーID、パスワード、氏名
所属部署、役職、メールアドレス
パソコンやサーバーなどの端末
部署やプロジェクト単位のグループ

ディレクトリサービスは、情報を読み取る・検索する処理が多く、書き換えは少ない用途に向いています。社員情報のように、頻繁に参照されるが変更は異動や入退社のときに限られるデータの管理に適した仕組みです。

LDAPは「Lightweight Directory Access Protocol」の略で、現在はバージョン3が標準

LDAPは「Lightweight Directory Access Protocol」の略です。日本語にすると「軽量なディレクトリアクセス用のプロトコル」という意味になります。

LDAPのもとになったのは、X.500というディレクトリの規格で定められたアクセス方式（Directory Access Protocol）です。これを扱いやすく軽量にしたものなので、「軽量」という名前が付いています。現在使われているのはバージョン3（LDAPv3）で、プロトコル本体は2006年6月に発行されたRFC 4511で定められています。

RFCは、インターネットの技術仕様をまとめた公開文書です。LDAPは特定のベンダーに依存しないオープンな規格なので、OSや製品が違っても同じ方法でディレクトリに問い合わせられます。この点が、さまざまな業務システムや機器がLDAPに対応している理由です。

LDAPの通信は標準で389番ポートを使い、暗号化にはLDAPSかStartTLSを使う

LDAPの通信は、標準では389番ポートを使い、そのままでは暗号化されません。暗号化するには、LDAPSかStartTLSのどちらかを使います。

方式	使うポート	暗号化の仕方
LDAP（暗号化なし）	389番	暗号化しない
StartTLS	389番	389番で接続した後、途中からTLSによる暗号化に切り替える
LDAPS	636番	最初からTLSで暗号化した状態で接続する

StartTLSは、LDAPの仕様の中で拡張操作として定められた方式です。一方、LDAPSは標準化文書で正式に規定された方式ではありませんが、業界で広く使われている方法です。

暗号化しない設定では、ログイン時のパスワードがネットワーク上をそのまま流れるおそれがあります。社内ネットワークの中であっても、LDAPの通信は暗号化して使うことを前提にしてください。

＼　情シス専門オンラインスクール　／

🎁 今だけ特典！

【期間限定】
トライアル申込者全員に
「IT管理に使える4大テンプレート」
無料プレゼント！

💻 IT資産管理台帳
🧾 PC利用規定テンプレート
🔐 パスワードポリシーサンプル
🌐 IPアドレス管理表

＼無料で全部もらう／
👉 トライアルに申し込む

LDAPのディレクトリは情報を木構造で持ち、DNで1件ずつ特定する

LDAPのディレクトリは、組織から部署、部署から個人へと枝分かれする木構造で情報を持っています。そして、その中の1件を指し示すのに「DN」という文字列を使います。

このセクションを読むと、業務システムのLDAP設定画面に出てくる「dc=」「ou=」「cn=」といった文字列の意味が分かるようになります。

ディレクトリの情報はエントリと属性の組み合わせで登録されている

ディレクトリの情報は、「エントリ」と「属性」の組み合わせで登録されています。社員1人や端末1台が、それぞれ1つのエントリになります。

エントリには、氏名・メールアドレス・所属部署などの情報が「属性」として付きます。たとえば社員のエントリであれば、「氏名＝山田太郎」「メール＝yamada@example.co.jp」のような形で、項目名と値の組が並びます。

エントリは、会社の下に部署、部署の下に個人というように階層を作って並びます。この階層全体をディレクトリ情報ツリー（DIT）と呼びます。

どのエントリにどの属性を持たせられるかは、「スキーマ」と呼ばれる定義で決まっています。ディレクトリの中身は、エントリ・属性・階層の3つで成り立っていると理解しておけば十分です。

DNはdc・ou・cnを組み合わせてエントリの位置を表す

DN（Distinguished Name、識別名）は、ディレクトリの中で1件のエントリがどこにあるかを示す文字列です。次のような略号と値の組をカンマでつないで書きます（架空の例）。

略号	意味	例
cn	個人名など、エントリそのものの名前	cn=Yamada Taro
ou	部署などの組織単位	ou=Sales
dc	ドメイン名を区切った構成要素	dc=example,dc=co,dc=jp

この3つをつなげると、cn=Yamada Taro,ou=Sales,dc=example,dc=co,dc=jp というDNになります。右に行くほど上位の階層を表し、「example.co.jpのSales部門にいるYamada Taro」と読みます。

LDAP設定の「ベースDN」は検索を始める階層のDN、「バインドDN」は接続に使うアカウントのDNです。どちらもこの形式で入力します。

LDAPの主な操作は認証（バインド）・検索・追加・変更・削除の5種類に分けて理解できる

LDAPでできることは、主な操作として「認証（バインド）」「検索」「追加」「変更」「削除」の5種類に分けると理解しやすくなります。

操作	英語名	内容
認証（バインド）	Bind	ディレクトリに接続し、DNとパスワードで本人確認を受ける
検索	Search	ベースDNと条件を指定して、合うエントリを探す
追加	Add	新しいエントリを登録する
変更	Modify	既存のエントリの属性を書き換える
削除	Delete	エントリを削除する

このほかにも、エントリの名前や位置を変える操作（ModifyDN）や、属性の値を照合する操作（Compare）があります。処理を取りやめる操作（Abandon）や、StartTLSのような拡張操作（Extended）、接続を終える操作（Unbind）もあります。

後で説明するLDAP認証では、バインドと検索の2つを組み合わせて使います。まずはこの2つの意味を押さえておくと、設定作業で迷いにくくなります。

LDAPはプロトコルで、Active DirectoryはLDAPに対応したディレクトリサービス製品

LDAPとActive Directory（AD）は、どちらが優れているかを比べる対象ではありません。LDAPは通信の決まりで、ADはその決まりで問い合わせを受け付ける製品という、層の違うものです。

両者が混同されやすいのは、AD環境でLDAPが使われる場面が多いためです。

ポイント

LDAP: ディレクトリに問い合わせるための通信の決まり（プロトコル）
ディレクトリサービス: ユーザーや端末の情報を管理する仕組みの総称
Active Directory／OpenLDAP: LDAPに対応したディレクトリサービスの具体的な製品

Active DirectoryはWindows環境のユーザーと端末をまとめて管理するMicrosoftのディレクトリサービス

Active Directoryは、Microsoftのディレクトリサービスです。Windows環境のユーザー・グループ・コンピューターをまとめて管理します。正式には、この中心となる機能を「Active Directory Domain Services（AD DS）」と呼びます。

ADでは、社内のWindows端末やユーザーを「ドメイン」という単位でまとめて管理します。ドメインの情報を持ち、ログインの要求に応えるサーバーが「ドメインコントローラー」です。

ADに参加したWindows端末では、社員は自分のドメインアカウントでログインします。退職者のアカウントをADで無効にすれば、ドメインに参加した端末に新たにログインすることはできなくなります。

ただし、Windowsはドメインコントローラーに接続できないときのために過去のログオン情報を端末に保存（キャッシュ）しており、社外に持ち出した端末などでは、その情報でログインできる場合があります。退職時は、アカウントの無効化とあわせて端末の回収も行ってください。

このほか、端末の設定を一括で配布する「グループポリシー」という機能もあります。

ADはLDAPで情報の読み書きを受け付け、Windowsへのログインには主にKerberosを使う

ADは、ディレクトリ情報の照会や管理にはLDAPを使い、Windowsドメインへのログオンには主にKerberosという別の認証方式を使います。

ADはLDAPに対応したディレクトリサーバーを持っています。そのため、Windows以外の業務システムやネットワーク機器も、LDAPでADに問い合わせてユーザー情報を参照したり、IDとパスワードを照合したりできます。

一方、社員がWindows端末にドメインアカウントでログインするときは、主にKerberosが使われます。LDAPは、ユーザーの所属やグループなどのディレクトリ情報を調べたり書き換えたりする場面で使われるのが中心です。

つまり、「AD＝LDAP」ではありません。ADは複数のプロトコルを組み合わせて動く製品で、その一つがLDAPという整理が正確です。

OpenLDAPなど、LDAPに対応したディレクトリ製品はAD以外にもある

LDAPに対応したディレクトリ製品は、ADだけではありません。オープンソースのOpenLDAPや389 Directory Serverなど、Linux系の環境で使われる製品もあります。

どれもLDAPに対応しているため、業務システムからは問い合わせ先がADでもOpenLDAPでも同じ方法で接続できます。

製品	主な対象環境	主な用途	ライセンスの考え方
Active Directory（AD DS）	Windows	Windows端末・ユーザーのドメイン管理、LDAPによる情報参照	Windows Serverの機能として提供される
OpenLDAP	Linuxなど	Linuxサーバーや業務システムのユーザー管理	オープンソース
389 Directory Server	Linuxなど	Linuxサーバーや業務システムのユーザー管理	オープンソース

ここでは、LDAPに対応した製品が複数あることを押さえておけば十分です。

＼　情シス専門オンラインスクール　／

🎁 今だけ特典！

【期間限定】
トライアル申込者全員に
「IT管理に使える4大テンプレート」
無料プレゼント！

💻 IT資産管理台帳
🧾 PC利用規定テンプレート
🔐 パスワードポリシーサンプル
🌐 IPアドレス管理表

＼無料で全部もらう／
👉 トライアルに申し込む

社内システムの認証連携では、LDAPがIDとパスワードの照合に使われる

「LDAP認証」とは、業務システムやVPN、無線LAN、複合機などが自分でパスワードを持たず、ADやLDAPサーバーに問い合わせて本人確認をする仕組みです。無線LANやVPNでは、RADIUSサーバーを間に置いて、そのRADIUSサーバーがADやLDAPサーバーに問い合わせる構成もよく使われます。

これにより、社員はどのシステムにも同じIDとパスワードでログインできます。情シスにとっては、IDをディレクトリ1か所で管理できるようになります。

LDAP認証では、システムがサービスアカウントでDNを検索してから本人のIDで照合する

LDAP認証は、多くの製品で「検索用のアカウントでDNを探す」→「本人のDNとパスワードで照合する」という順番で進みます。社員が入力するのはユーザー名だけで、DNまでは知らないためです。なお、ADの「user@example.co.jp」形式の名前で直接バインドするなど、検索を省く製品もあります。

社員が業務システムにログインするときの流れは、次の3ステップです。

システムが、接続用に用意したアカウント（サービスアカウント）でディレクトリにバインドする
社員が入力したユーザー名をもとに、ディレクトリを検索してその社員のDNを見つける
見つけたDNと社員が入力したパスワードで改めてバインドし、成功すれば本人と判断する

前のセクションで触れた「バインドDN」は、1つ目のステップで使うサービスアカウントのDNです。

この仕組みの利点は、ディレクトリ側でアカウントを無効にすれば、LDAPで認証している連携システムには新たにログインできなくなることです。退職者が出たときに、システムごとにIDを消して回る必要がなくなります。

LDAP認証は同じIDを複数のシステムで使える状態をつくり、SSOは認証を1回で済ませる状態をつくる

LDAP認証とシングルサインオン（SSO）は混同されやすいのですが、目的が違います。LDAP認証は「同じIDとパスワードを使える」状態をつくり、SSOは「ログインを1回で済ませる」状態をつくります。

LDAP認証では、IDとパスワードは共通でも、システムごとにログイン画面で入力する必要があります。3つのシステムを使えば、ログイン操作も3回です。

これに対して、1回のログインで連携する複数のシステムに入れるようにするのがシングルサインオン（SSO）です。SSOでは、認証を担う仕組み（IdP）が本人確認をまとめて行います。そのIdPが、裏側でLDAPのディレクトリを参照して本人確認をすることもあります。

両者は対立するものではありません。LDAPで「IDをそろえる」、SSOで「ログインの回数を減らす」と役割を分けて考えると整理しやすくなります。

LDAPの通信は暗号化と入力値のチェックをしないと、パスワードの盗聴やLDAPインジェクションにつながる

LDAP認証を安全に使うには、通信の暗号化と、入力値のチェックが欠かせません。設定時に確認したい点は次の3つです。

暗号化しない389番の通信はパスワードが読み取れるおそれがあるため、StartTLSかLDAPSを使う
入力値をそのまま検索条件に使うと「LDAPインジェクション」の原因になるため、システム側でチェックする
Windows Server 2022以前のADの既定では、LDAP署名とチャネルバインディングが必須になっていない。Microsoftは2019年8月のアドバイザリ（ADV190023）で、LDAP署名の必須化とチャネルバインディングの有効化を推奨している。Windows Server 2025で新しく構築したADでは、LDAP署名が既定で必須になった（既存環境をアップグレードした場合は設定が引き継がれる）

注意

「社内LANの中だから」という理由で、暗号化しないLDAP通信を安全とみなさないでください。社内ネットワークに侵入されると、平文で流れるパスワードを読み取られるおそれがあります。

IDを一か所で管理できていないことが、不正アクセスの主な原因の一つになっている

ここからは、公的データをもとに、IDを一か所で管理する仕組みが求められる理由を見ていきます。結論から言うと、2025年の不正アクセス届出では、被害原因の3分の1がID・パスワード管理の不備でした。

被害そのものも、一定の割合で起きています。総務省の通信利用動向調査は、常用雇用者100人以上の企業が対象です。この調査では、インターネットを利用する企業のうち、過去1年間に「不正アクセス」の被害があった企業は、2025年に4.1%でした。2024年は3.9%です。

注意

次の見出しで紹介する原因の割合は、IPAに自発的に届け出られた不正アクセスのうち、被害があった届出85件の原因を数えた内訳です。企業全体でどのような被害が起きているかを表す数字ではありません。

2025年の不正アクセス届出では、被害原因の33.7%がID・パスワード管理の不備だった

警察庁・総務省・経済産業省の公表資料によると、2025年の不正アクセス届出で、被害原因のうち「ID・パスワード管理の不備」が占める割合は33.7%でした。分母は、被害があった届出85件の原因を延べで数えた89件です。

IPAの届出状況の資料では、同じ原因が30件と集計されています。33.7%と同じ届出データの件数です。「古いバージョンの利用や修正プログラムなどの未導入」は18件でした。

この内訳から読み取れるのは、届出の中ではID・パスワード管理の不備が最も多い原因になっている点です。ただし、原因の順位は調査によって入れ替わるため、届出だけで不正アクセス全体の傾向を決めつけることはできません。件数で見ると、管理の不備は修正プログラムの未導入などの約1.7倍にあたります。

ここで言う「管理の不備」には、使われなくなったIDの放置や弱いパスワードでの運用が当てはまります。ディレクトリでIDをまとめれば停止や変更を1か所で行えますが、パスワードの強度や漏えいの問題はそれだけでは解決しません。

ID・パスワードによるアクセス制御を行う企業は2025年に60.4%で、2018年の51.6%から増えた

総務省の通信利用動向調査によると、セキュリティ対策として「ID、パスワードによるアクセス制御」を行う企業は、2025年に60.4%でした。2018年の51.6%からは増えています。

調査年	ID、パスワードによるアクセス制御を行う企業の割合
2018年	51.6%
2020年	63.1%
2021年	57.0%
2022年	57.2%
2023年	58.0%
2024年	58.9%
2025年	60.4%

表の出典: 総務省「平成30年通信利用動向調査の結果」／同「令和3年」／同「令和4年」／同「令和5年」／同「令和7年（概要）別紙2」（2019年は本記事のデータに未収録。2018年は「情報通信ネットワーク利用企業」、2020年以降は「インターネット利用企業」が対象）

この推移から読み取れるのは、2021年以降は毎年少しずつ伸びているものの、2025年でも2020年の水準には戻っていない点です。

なお、2020年の値だけが高い理由は公表資料からは特定できません。また、この項目を選ばなかった企業がアクセス制御をしていないとは限りません。ID・パスワードで制御する企業が増えるほど、そのIDをどこで管理するかが課題になります。

ID管理と本人確認を強化していると答えた割合は2022年で35.5%にとどまり、IDを発行した後の管理が手薄になりやすい

IPAが2022年に行った内部不正対策の調査では、「ID管理と本人確認（認証）を強化している」と答えた割合は35.5%でした。同じ2022年の総務省の調査では、ID・パスワードによるアクセス制御を行う企業は57.2%でした。

IPAの調査は回答者が勤め先の状況を個人として答えたもので、総務省の調査とは母集団が違います。そのうえで2つを並べると、目安として20ポイント余りの開きがあります。IDを発行して制御することと、発行後の棚卸しや停止まで管理することは、別の取り組みだと考えられます。ディレクトリサービスは、この発行後の管理を1か所で行うための仕組みです。

出典: 警察庁・総務省・経済産業省「不正アクセス行為の発生状況及びアクセス制御機能に関する技術の研究開発の状況」／IPA「コンピュータウイルス・不正アクセスの届出状況［2025年（1月～12月）］」／総務省「令和7年通信利用動向調査の結果（概要）別紙2」／IPA「企業の内部不正防止体制に関する実態調査報告書」／総務省「令和4年通信利用動向調査の結果」

＼　情シス専門オンラインスクール　／

🎁 今だけ特典！

【期間限定】
トライアル申込者全員に
「IT管理に使える4大テンプレート」
無料プレゼント！

💻 IT資産管理台帳
🧾 PC利用規定テンプレート
🔐 パスワードポリシーサンプル
🌐 IPアドレス管理表

＼無料で全部もらう／
👉 トライアルに申し込む

クラウドID基盤への移行は進みつつあるが、社内ディレクトリでIDをまとめている企業の割合は公的統計では分からない

最初にお伝えしておくと、LDAPやActive Directoryの利用率を測った公的統計はありません。そこでこのセクションでは、近い指標として、総務省の調査にある「クラウドの認証システム」の利用状況を紹介します。

インターネット上には、ディレクトリ製品の普及度を示すとされる数字が出回ることがあります。しかし、一次資料や調査年を確認できないものが多いため、この記事では使いません。

注意

このセクションで紹介する16.0%は、2025年の調査で「クラウドサービスを使う企業のうち、用途として認証システムを選んだ割合」です。LDAPやADからクラウドへ移行した企業の割合でも、SSOを導入している企業の割合でもありません。

クラウドの認証システムを使う企業は2025年にクラウド利用企業の16.0%で、前年の13.6%から増えた

総務省の令和7年通信利用動向調査（常用雇用者100人以上の企業が対象）によると、2025年にクラウドサービスを利用している企業は83.5%（無回答を除く集計）でした。クラウドサービスを使う企業のうち、用途として認証システムを選んだ割合は16.0%です。2024年の13.6%からは増えています。

これらを並べると、クラウドの認証システムの伸び率は、ほかの認証関連の対策と比べて大きいことが分かります。一方で、2025年の不正アクセス届出では被害原因の3分の1がID・パスワード管理の不備でした。それに対し、IDを一つの基盤に集めるクラウド型の認証システムを使う企業は、クラウド利用企業の中でも6社に1社程度にとどまります。

ただし、届出と通信利用動向調査は母集団が別で、この2つの数字の間に因果関係があることを示すものではありません。また、社内のADやLDAPサーバーでIDをまとめている企業は16.0%に含まれません。

なお、2024年の13.6%が2025年と同じ集計基準（無回答を除く）かどうかは確認できておらず、増加分の一部は基準の違いによる可能性があります。

社内ディレクトリでIDをまとめているのか、システムごとに分かれているのかを区別できる統計は無い

2025年の総務省の調査では、ID・パスワードによるアクセス制御を行う企業は60.4%でした。一方、クラウドの認証システムを使う企業は、83.5%×16.0%で全企業の約13.4%です（本記事での計算値で、総務省の公表値ではありません）。

図の出典: 総務省「令和7年通信利用動向調査の結果（概要）別紙2」／総務省「令和7年通信利用動向調査の結果（概要）別紙1」（約13.4%は本記事での計算値。LDAPやADの利用率を示す公的統計はありません）

これらを並べると、60.4%と約13.4%の間には約47ポイントの差があります。この差にあたる企業が社内のディレクトリでIDをまとめているのか、システムごとに別々なのかは、統計では区別できません。社内のADやLDAPサーバーでまとめている企業は16.0%に含まれず、各指標や不正アクセス届出とは母集団も一致しません。この差は目安で、因果関係を示すものでもありません。

この状況から読み取れるのは、ログインの基盤が社内側と個々のサービス側に分かれている点です。SSOの導入率を測った公的統計も無く、2022年のIPA調査の35.5%も条件が違うため、この空白は埋まりません。まずは自社がどちらの状態かを把握することが出発点です。

SaaS中心の環境では、LDAPに代わりSAMLやOpenID ConnectでクラウドのID基盤と連携する

SaaSとのID連携には、LDAPではなく、主にSAMLやOpenID ConnectといったWeb向けの方式が使われます。LDAPは、社内ネットワークのディレクトリへの問い合わせを前提にした仕組みだからです。

Microsoft環境のクラウドID基盤はMicrosoft Entra ID（旧Azure AD）です。ただし、Entra ID自体はLDAPやKerberosを提供しません。これらが必要な場合は、Microsoft Entra Domain Servicesか、自社で運用するAD DSを使います。

そのため移行は、LDAPでしか認証できないシステムや機器を洗い出し、社内に残す範囲とクラウドに寄せる範囲を決める作業になります。IDの発行から停止までの管理はID管理システムの記事で解説しています。認証を集めた入口には、多要素認証も置いてください。

出典: 総務省「令和7年通信利用動向調査の結果（概要）別紙2」／総務省「令和7年通信利用動向調査の結果（概要）別紙1」／警察庁・総務省・経済産業省「不正アクセス行為の発生状況及びアクセス制御機能に関する技術の研究開発の状況」／IPA「企業の内部不正防止体制に関する実態調査報告書」