>
>
公開日
企業のITインフラを管理する上で、避けて通れないのがユーザーIDや各種リソースの一元管理です。その中核を担う技術として長年使われているのがLDAP（Lightweight Directory Access Protocol）です。しかし、名前は聞いたことがあっても、「LDAPとは何のために使うプロトコルなのか」「Active Directory（AD）とは何が違うのか」といった基本事項を明確に説明できる方は意外と少ないのではないでしょうか。
現在、企業ではゼロトラストセキュリティへの移行やクラウド化が急速に進んでいます。その一方で、複合機やVPN、オンプレミスのレガシーシステムなど、依然としてLDAPによる認証を必要とする機器やシステムは数多く残されています。そのため、現代の情シス担当者には、レガシーとモダンを融合させたハイブリッドなID管理の知識が求められます。
本記事のポイント（この記事でわかること）
LDAPとは、ネットワーク上の情報を一元管理するディレクトリサービスにアクセスするための「標準的な通信プロトコル（規約）」である。
LDAP（プロトコル）とActive Directory（製品）は全くの別物であり、Active DirectoryはLDAPを利用したディレクトリサービス製品である。
セキュリティ強化の観点から、Windows Server 2025では「平文LDAP通信」が既定で拒否され、「LDAP署名」が必須化されている。
クラウドIDaaS移行時も、社内レガシーシステムや複合機の認証用にLDAP連携は不可欠であり、ハイブリッドな運用設計が求められる。
LDAPとは？仕組みとデータベースとの違いを解説
LDAP（Lightweight Directory Access Protocol）とは、ネットワーク上のユーザー情報や端末情報を一元管理する「ディレクトリサービス」にアクセスするための業界標準プロトコルです。
ディレクトリサービスは、ネットワーク内のあらゆるリソース（ユーザー、パスワード、メールアドレス、部署名、サーバー、共有ディレクトリなど）を「電話帳」のように整理して集中管理する仕組みです。LDAPはこの電話帳を開き、必要な情報を探し出したり、新規ユーザーの情報を書き込んだりするための「手順や言語」を定めたものです。名称に「Lightweight（軽量）」とある通り、元々は非常に複雑であったX.500プロトコルを簡略化し、TCP/IPネットワーク上で高速かつ軽快に動作するよう設計された歴史を持っています。
LDAPとデータベース（RDBMS）の違い
情報の保管庫という意味で、LDAPはデータベース（RDBMS）と同じものと誤解されがちですが、内部構造と得意とする処理が根本的に異なります。一般的なRDBMS（関係データベース）が、縦横の「テーブル構造（表形式）」で複雑な書き込みやトランザクション処理を得意とするのに対し、LDAPは「ツリー構造（階層形式）」を採用しています。
LDAPは、頻繁なデータの書き換えよりも「大量のデータから特定の情報を瞬時に探し出す」という読み取り（検索）処理に特化して設計されているのが最大の特徴です。そのため、社員の認証処理など、大量かつ瞬時の検索レスポンスが求められるアイデンティティ管理に適しています。
比較項目 | LDAP（ディレクトリサービス） | RDBMS（一般的なデータベース） |
|---|---|---|
データ構造 | ツリー構造（階層形式） | テーブル構造（表形式） |
適した処理 | 検索・読み取り（圧倒的に高速） | 書き込み・更新・トランザクション処理 |
データの更新頻度 | 低い（ユーザー追加・人事異動時など） | 極めて高い（秒間多数のデータ更新） |
主な用途 | 認証、アカウント情報、端末の一元管理 | 販売管理、購買データ、会計データなど |
LDAPサーバーとは？代表的な種類と役割
LDAPサーバーとは、LDAPプロトコルを用いてディレクトリ情報を提供するサーバーシステムそのものです。
一般に現場で「LDAP」という用語が使われる際、プロトコルそのものではなく「LDAPサーバー」を指していることが多々あります。LDAPサーバーは、ユーザーアカウントやPCなどのIT資産の情報をデータベースとして内部に保持し、各種アプリケーションや機器（クライアント）からのLDAPリクエスト（検索や認証要求）を受け取って応答する役割を担います。
LDAPサーバーを一元化して運用することにより、従業員は利用するシステムごとに別々のアカウントを作成・管理する必要がなくなります。管理者にとっても、1箇所のサーバー情報を書き換えるだけで、すべての連携システムにアカウント情報（異動、退職、パスワード変更など）が瞬時に反映されるため、運用工数が劇的に削減されます。代表的なLDAPサーバー製品には、オープンソースで広く使われている「OpenLDAP」や、Microsoftが提供するWindows Serverの「Active Directory」などがあります。
日本におけるLDAP・統合ID管理の市場規模と現状
近年、ゼロトラストセキュリティの実装加速や、経済産業省が主導する「SCS評価制度」などのセキュリティガイドライン強化を背景に、日本国内における統合ID管理市場は急速な広がりを見せています。デロイト トーマツ ミック経済研究所が2025年12月に発表した調査データ（エクスジェン・ネットワークス社プレスリリース2026年5月に引用）によると、統合ID管理パッケージ市場は以下のように成長を続けています。
2025年度国内市場規模（見込み）：173億円（前年対比125.4％）
2026年度国内市場規模（予測）：212億円（前年対比122.5％）
この成長を牽引する日本市場のデファクトスタンダードとして知られるのが、エクスジェン・ネットワークス社の統合ID管理パッケージ「LDAP Manager」です。同製品は、2024年度において18年連続で国内出荷本数トップを達成しており、2025〜2026年時点の累計出荷本数は900本以上に達しています（出典：エクスジェン・ネットワークス社公式発表）。このデータが示す通り、クラウド化が進む現代においても、日本特有の複雑な組織構造（部課制、兼務、役職など）を緻密に管理する上で、オンプレミス環境におけるLDAPをベースにした認証基盤は、依然として企業インフラの極めて強固な土台となっています。
LDAPとActive Directory（AD）の違いと関係性
Active DirectoryはLDAPを通信言語として利用するMicrosoft社のディレクトリサービス製品であり、プロトコルと製品という関係にあります。
企業の情シス担当者が最も混同しやすいのが、LDAPとActive Directory（AD）の違いです。結論から言えば、「LDAP」は通信を行うための共通ルール（プロトコル、つまり言語）であり、「Active Directory」はLDAPという言語を解釈し、Windowsネットワーク環境に特化して様々な管理機能を追加したソフトウェアパッケージ（製品・サービス）です。したがって、「LDAPとADのどちらを導入すべきか」という比較自体が本来は誤りであり、ADを導入すると、内部で情報の問い合わせを行う通信としてLDAPが使われる、という関係性になります。
クラウド時代（脱オンプレAD）におけるLDAPの重要性
現在、多くの企業が従来のオンプレミスADを廃止、あるいは縮小し、Microsoft Entra ID（旧Azure AD）やOktaなどの「IDaaS（クラウド型ID管理）」への移行を進めています。しかし、社内ネットワークに目を向けると、VPN機器、ファイアウォール、複合機、オンプレミスで構築された自社基盤システムなどは、SAMLやOIDCといったモダンなクラウド向けプロトコルに対応しておらず、認証方式として依然「LDAP認証のみ」をサポートしている現実があります。
このため、完全にオンプレミスのADやLDAPサーバーを停止してしまうと、社内機器の認証が全滅してしまいます。そこで2025〜2026年現在の主流となっているのが、クラウド上にマスタIDを置きながら、オンプレミスの機器に向けてLDAP通信を中継する「Cloud LDAP」や「LDAPインターフェース」を活用した、ハイブリッドなID管理手法です。LDAPというプロトコルは、クラウド時代であっても、レガシー機器とクラウドIDaaSをつなぐ通信手段として、今もインフラの現場で使われ続けています。
LDAPとActive Directoryの比較表
比較項目 | LDAP | Active Directory (AD) |
|---|---|---|
概念・分類 | 通信プロトコル（規約・言語） | ディレクトリサービス（ソフトウェア・製品） |
提供元 | 標準規格（IETFが策定） | Microsoft社 |
対応OS | OSに依存しない（Linux, macOS、各種ルーター等） | 主にWindows環境に最適化（ドメイン機能等） |
主な機能 | 情報の検索、書き込み、認証の通信処理 | ユーザーの一元管理、グループポリシー、PCの設定強制など |
認証プロトコル | LDAP認証のみ | Kerberos認証（ADの標準）、LDAP認証、NTLM認証 |
▲ 通信プロトコル（LDAP）と製品（Active Directory）の違いと関係性
LDAP認証とは？AD認証との違いとアクセス手順
LDAP認証は、入力されたアカウント情報をLDAPサーバーに問い合わせて検証を行う認証プロセスです。
「LDAP認証」とは、ユーザーがシステムやアプリケーションにログインする際、LDAPプロトコルを利用してLDAPサーバーにアカウントの真偽を問い合わせ、アクセスの可否を判断する仕組みを指します。これにより、別々のシステムであっても裏側で同一のLDAPサーバーを参照し、共通のID・パスワードで認証を通すことができます。
LDAP認証のアクセス手順（フロー）
システムにおけるLDAP認証は、以下の4つの手順で処理が進行します。
ログイン要求の送信: ユーザーがアプリケーションの画面から、ユーザーIDとパスワードを入力して送信する。
バインド要求（接続）: アプリケーションがLDAPプロトコルを用いて、LDAPサーバーに対して認証のための「Bind（バインド）」要求を送信する。
照合処理: LDAPサーバーが、ディレクトリデータベースの中から該当するユーザー情報を検索し、入力されたパスワードと一致するか照合する。
認証結果の応答: 照合の結果、一致していれば「認証成功（Success）」、不一致であれば「認証失敗」をアプリケーションに返し、ログインを許可または拒否する。
AD認証（Kerberos）とLDAP認証の違い
Windows Server環境下において利用される「AD認証」と「LDAP認証」も、実務で混同されやすい要素です。Active Directoryを構築したWindowsドメイン環境における標準的な認証方式は「Kerberos（ケルベロス）認証」であり、これはチケット情報を用いた極めて堅牢なシングルサインオン（SSO）を提供します。しかし、社内にあるLinuxサーバーや、SaaSなどの非WindowsシステムからAD内のリソースを参照して認証させたい場合、Kerberos認証の適用が難しいため、ADがサポートする通信窓口である「LDAP認証」を仲介してユーザー情報の検証を行うのが一般的です。
日本企業におけるLDAP／統合ID管理の導入・成功事例
国内の企業や組織が、LDAPを活用してID管理やガバナンス強化を実現した具体的な事例を紹介します。
事例1：株式会社HITOWA（ライフサービス）（事例詳細はこちら）
業種・規模： 介護・保育・家事支援等のライフサービス（グループ全体）
導入時期： 近年
課題： 従業員のID登録・削除・異動に伴うアカウント管理が完全に属人化しており、手作業による大きな運用負荷とアカウントの削除漏れに伴うセキュリティリスクが課題だった。
施策： 統合ID管理パッケージ「LDAP Manager」を中核に据えた、独自のID認証基盤を構築。
成果： ID運用の自動化に成功し、手作業による属人的な運用から完全に脱却。現場スタッフを含むグループ全社員が、不要なアカウントの削除漏れがない安全かつスムーズな情報ポータルへのアクセス環境を手に入れた。
事例2：高田製薬株式会社（製薬メーカー）（事例詳細はこちら）
業種・規模： ジェネリック医薬品メーカー（中堅規模）
導入時期： 近年
課題： 社員の業務生産性向上を図りつつ、法改正や内部ガバナンス強化に伴うシステムアクセス権限の統制およびセキュリティの厳格化が強く求められていた。
施策： シングルサインオン（SSO）基盤の導入と並行し、統合ID管理基盤として「LDAP Manager」を導入。
成果： 各部門で異なる様々なシステムへのID自動連携とメンテナンス業務を効率化。同時に、IDの棚卸しとライフサイクル管理を自動化することで、運用の透明性とセキュリティガバナンスを大幅に向上させた。
事例3：公立大学法人 熊本県立大学（高等教育機関）（事例詳細はこちら）
業種・規模： 公立大学法人
導入時期： 近年
課題： 学内システムの更新に伴い、学術認証フェデレーション（学認）のIdP（アイデンティティプロバイダー）をクラウド化したいが、Microsoft Entra ID単体では、学認が求める日本固有の複雑な認証要件や属性マッピングを完全にカバーしきれないことが判明。
施策： Entra IDとスムーズに連携可能であり、かつ強固なLDAP連携機能を保持する国産IDaaS「Extic」を導入。
成果： 既存のLDAP/ADの確かなIDデータを最大限に有効活用しつつ、学認IdPのクラウド化を安全かつ大幅にコストを抑えて実現することに成功した。
▲ ユーザーログインから完了までのLDAP認証の4ステップ
LDAPの仕組み：ツリー構造によるデータ管理
LDAPは階層的な「ツリー構造」でデータを整理し、識別名（DN）を用いて特定のリソースを一意に特定します。
LDAPサーバー内のデータは通常、LDIF（LDAP Data Interchange Format）と呼ばれるテキスト形式で表現され、組織図のように「国（C）」「ドメイン（DC）」「組織・部署（OU）」「ユーザー個人（CN）」といった形で階層化された「ツリー構造」として整理・格納されます。
データの階層表現と識別名（DN）の構成要素
LDAP内で個々のオブジェクトの場所を正確に指定するため、以下の略号を組み合わせた住所情報を作成します。これをDN（Distinguished Name：識別名）と呼びます。
DC（Domain Component）： ドメイン名の構成要素。インターネット上のドメインを切り分けたもの（例：
dc=example,dc=com）OU（Organizational Unit）： 組織単位。ファイルシステムのフォルダに類似した役割（例：
ou=sales,ou=tokyo）CN（Common Name）： 共通名。人、PC、ネットワーク機器などの具体的なオブジェクト名（例：
cn=Taro Yamada）
これらをツリーの下位から上位へカンマ区切りでつなぎ合わせたフルアドレスがDNになります（例：cn=Taro Yamada,ou=sales,dc=example,dc=com）。これにより、大規模な組織構造であっても、全社の中で特定のユーザーを「世界で一意のオブジェクト」として瞬時に検索し、アクセスを高速化できるのが特徴です。
LDAPを活用するメリットと導入時のセキュリティ対策
LDAPはマルチプラットフォームで一元管理を可能にしますが、平文通信による盗聴を防ぐセキュリティ対策が必須です。
企業システムにおけるLDAPプロトコル適用の主なメリットは、Linux・Windows・macOSといったOSに依存せず、ネットワーク内の様々な周辺機器やレガシーシステムとシームレスに認証連携ができる高いマルチプラットフォーム性、および検索処理に特化した高速な認証応答にあります。しかし、標準の通信方式には重大な弱点も潜んでいます。
平文通信リスクとセキュリティ対策
標準のLDAP通信（TCPポート389）は、暗号化が施されない「平文」の状態でデータがやり取りされます。このため、社内LAN内であっても盗聴が行われれば、ユーザーのパスワードなどの機密情報がプレーンテキストで漏洩する脆弱性リスクが存在します。企業インフラでLDAPを使う場合、通信の暗号化は必須と考えてよいです。
【最新】Windows Server 2025における「LDAP署名の既定化」
この通信セキュリティをめぐり、近年大きな環境変化が起きています。Microsoft社がリリースしたWindows Server 2025のActive Directoryでは、これまでの平文通信を許容していた初期設定が廃止され、セキュリティ強化のために「LDAP署名」が既定で必須化（有効化）されました。また「LDAPチャネルバインディング（CBT）」については、既定値が「サポートされている場合（When supported）」に設定されており、強制必須化ではありません（参照：Microsoft Learn – LDAP セキュリティの既定値）。これにより、従来の「暗号化なしの簡易バインド（Simple Bind）」でADに接続していた古いレガシーシステムや複合機、自社アプリなどが、サーバーアップデートと同時に「強力な認証が必要です」というエラーを出して一斉に認証拒否される実務上のトラブルが続出しています。サーバー更改時には、必ずクライアント側が暗号化接続に対応しているか検証しなければなりません。
「LDAPS（ポート636）」と「StartTLS（ポート389）」の違い
LDAPの通信を暗号化（SSL/TLS化）する方法には、大きく分けて2種類のアプローチがあります。ファイアウォールの設定変更時などに混乱しやすいため、以下の違いを正しく理解する必要があります。
比較項目 | LDAPS (LDAP over SSL/TLS) | StartTLS |
|---|---|---|
デフォルトポート | TCP 636 | TCP 389（標準平文と同じ） |
接続の確立プロセス | 接続開始時から暗号化トンネルを確立（HTTPSと同様） | 最初は平文で接続。その後に「StartTLSコマンド」を送って暗号化へ移行 |
通信セキュリティ | 極めて高い。暗号化されない通信は最初から通らない | 高いが、切り替えコマンドに失敗すると平文のまま接続されるリスクがある |
Webアプリ連携における「LDAPインジェクション」と対策
社内のWebポータルなどからLDAPサーバーにユーザー検索クエリを発行するようなアプリケーションを独自実装する場合、SQLインジェクションと同様に「LDAPインジェクション」の脆弱性対策が必須です。これは、攻撃者が入力フォーム等に特殊な文字（*や(、)、&、|など）を入力し、アプリケーション内のLDAPクエリ構文を書き換えて、意図しない管理者権限でのバイパスログインや、全社員の個人情報の一括抽出などを引き起こす攻撃手法です。対策として、プログラム側で入力値のサニタイズ（エスケープ処理）を徹底するか、クエリ連結時にプレースホルダーを使用するライブラリを採用し、実装ライブラリのドキュメントおよびOWASPのガイドラインを参照し、入力値のサニタイズを確認してください。詳細は、セキュリティガイドラインであるOWASP（Open Worldwide Application Security Project）の情報を参照し、脆弱性のないコード実装を徹底してください。
実務でよくあるLDAPの失敗・エラーパターン
社内インフラのクラウド化や最新OSへのアップデートに伴い、検証不足によるLDAP接続エラーやレガシー機器の認証停止トラブルが頻発しています。
実務の現場において、システム刷新を契機に予期しないエラーでネットワーク内の業務がマヒする事例が増えています。ここでは、特に注意すべき2大失敗パターンと具体的な対処法について解説します。
失敗パターン①：クラウドIDaaS（Entra ID等）移行に伴いオンプレLDAPを即時停止して破綻する
オンプレミス管理からの脱却を急ぐあまり、Active DirectoryやOpenLDAPサーバーを完全停止してIDaaSへ完全移行した結果、数日後に「社内の複合機の宛先検索（LDAP連携による社員名簿の引き出し）ができない」「レガシーなファイルサーバーやVPN装置、工場の生産ライン端末に一切ログインできない」といった問題が発生し、インフラ部門がパニックに陥るトラブルが後を絶ちません。これらはモダンなSAML/OIDCプロトコルに対応していないハードウェア・ソフトウェアを事前に棚卸ししきれなかったことによるものです。事前にすべての依存機器を洗い出し、Okta LDAP Agentなどの「IDaaS中継プロキシ」を設置するか、あるいは移行完了期までオンプレミスにLDAP通信のみを橋渡しする連携手段を一部残すといったハイブリッド設計をあらかじめ組み込んでおく必要があります。
失敗パターン②：Windows Server 2025へ移行した途端「強力な認証が必要です」エラーで動かなくなる
前述のWindows Server 2025の仕様変更に伴い、従来のレガシー機器からのLDAPシンプルバインド接続が拒否される問題です。接続テストの段階、あるいは本番切り替えの直後に、ADが平文接続を拒否し認証エラーとなります。対策は接続元の対応状況に応じて以下の2段階で検討してください。
LDAPS/StartTLSに対応している場合：接続元の機器やアプリ側で「LDAPS（ポート636）」または「StartTLS（ポート389）」を有効化し、証明書をインストールして暗号化通信へ切り替えます。
ハードウェアがLDAPS非対応の場合（暫定対応）：AD側のグループポリシー（GPO）で「ドメイン コントローラー: LDAP サーバー署名の要件」を一時的に「なし」に設定し、クライアント側の署名要件も解除して接続を回復させます。セキュリティリスクが生じるため、あくまで暫定対応に限定し、速やかに恒久対策へ移行してください。
▲ クラウドIDaaS移行時におけるオンプレLDAP停止判断フロー
LDAPの関連重要用語7つ
構築・連携設定時にドキュメントや管理画面で必ず目にする用語を以下にまとめます。
スキーマ (Schema): ディレクトリにどのようなデータを保存できるか、ルールを定めた規則。社員番号やメールアドレスなど、属性にどのような形式（文字列、数値など）を用いるかを厳格に定義します。
識別名 (DN: Distinguished Name): ツリー構造の中で、ある特定のオブジェクトがどこに存在するかを「カンマ区切り」で指し示す一意のアドレス（住所）です。
相対識別名 (RDN: Relative Distinguished Name): DNのパスを構成する各要素（例：
CN=Taro Yamadaの部分）を単独で指す言葉です。データモデル: オブジェクトクラス（ユーザー、グループ、コンピューターなど）を規定し、どのオブジェクトにどのようなスキーマ（属性値）を持たせることができるかを決めるデータ構造の基本ルールです。
バインド (Bind): クライアントがLDAPサーバーに接続する際に行うログイン（認証）手続きです。認証情報のない匿名（Anonymous）バインドや、ID・パスワードを使用するシンプルバインドがあります。
変更要求: LDAPサーバーのデータに対して、値の追加（Add）、削除（Delete）、編集（Modify）などを命令するための変更操作コマンドのことです。
URL / URI: システムからLDAPサーバーの接続先を指定するためのアドレス指定表記です。平文通信なら
ldap://ldap.example.com:389、暗号化通信ならldaps://ldap.example.com:636のように表記します。
よくある質問
Q：LDAPサーバーとは何ですか？
A：LDAPプロトコルを用いてディレクトリサービス（ユーザーや端末情報などの組織資産）のデータベースを提供するサーバーシステムです。代表的な製品に、オープンソースのOpenLDAPやMicrosoft社のActive Directory（AD）があります。
Q：Active DirectoryとLDAPの違いは何ですか？
A：LDAPは情報の検索や照合を行うための「通信プロトコル（標準規格・言語）」です。これに対してActive Directoryは、そのLDAPプロトコルを内部のデータ通信言語として採用しているMicrosoft社製の「ディレクトリサービスパッケージ製品」です。
Q：LDAPとデータベース（RDBMS）の違いは何ですか？
A：RDBMSが表形式で頻繁なデータ書き込みや複雑な処理を得意とするのに対し、LDAPは階層形式（ツリー構造）でデータを管理します。LDAPは大量のデータから特定の情報を高速に探し出す「読み取り処理」に特化しており、アカウント認証処理に最適です。
Q：クラウドIDaaS（Entra ID等）移行に伴い、オンプレのLDAPサーバーをすぐに停止しても大丈夫ですか？
A：非常に危険です。社内のVPN、複合機、レガシーな業務システムなどがLDAP認証のみに依存している場合、サーバー停止により一斉にそれらの機器が利用できなくなります。必ず事前に社内機器を棚卸しし、連携をIDaaSのLDAPエージェント経由などに移行するか、ハイブリッド運用を構築してから停止してください。
Q：Windows Server 2025へ移行した途端、LDAP認証でエラーが発生するようになりました。原因と対策は何ですか？
A：Windows Server 2025から「LDAP署名」が既定で必須となったため、暗号化されていない平文接続がAD側で遮断されている可能性が高いです。対策として、接続元アプリ側で「LDAPS（TCP 636）」または「StartTLS（TCP 389）」を有効化し暗号化通信へ切り替えるか、GPOで一時的に署名ポリシーを緩和させるかの対応が必要になります。
まとめ
本記事では、LDAPの基礎からActive Directoryとの違い、最新のセキュリティ環境変化であるWindows Server 2025の仕様、そして実務上の導入事例や失敗パターンについて網羅的に解説しました。LDAPは旧来のプロトコルではなく、クラウドとオンプレミスが混在する現在でも認証基盤の中核を担い、レガシー機器とクラウドIDaaSをつなぐ現役の通信手段として使われ続けています。明日からのアクションとして、まずは社内で使われている各システムや複合機のLDAP連携状況を点検し、安全なSaaSとの連携を構築すべく、LDAPS（ポート636）への移行計画や、暗号化対応の有無の確認から始めてみてください。
✅ 社内のLDAP依存機器（複合機・VPN・レガシーシステム）を棚卸し済みか
✅ LDAPSまたはStartTLSへの切り替え計画が存在するか
✅ Windows Server 2025移行前にLDAP署名の影響を検証済みか
✅ IDaaS移行後のハイブリッド運用設計が完了しているか
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
橋爪兼続
ライトハウスコンサルタント代表。2013年海上保安大学校本科第Ⅲ群（情報通信課程）卒業。巡視船主任通信士を歴任し、退職後、大手私鉄の鉄道運行の基幹システムの保守に従事。一般社団法人情報処理安全確保支援士会の前身団体である情報処理安全確保支援士会の発起人。情報処理安全確保支援士(第000049号)。
