Active DirectoryのobjectGUIDは変更できる？変更不可の理由と代替策（PowerShell確認手順つき）

Active DirectoryのユーザーやOUに付与されるobjectGUIDを「任意の値に変更したい」という相談は少なくありません。結論から言うと、objectGUIDは作成時に自動付与されるシステム管理属性で、運用中に書き換えることはできません。本記事では理由と、目的別の現実的な代替策を整理します。

結論：Active DirectoryのobjectGUIDは変更できない

objectGUIDは、Active Directory（AD DS）が各オブジェクトに自動で割り当てる128-bit（16バイト）の一意識別子です。ユーザー、グループ、コンピューター、OU、コンテナーなど、ディレクトリに存在するほぼすべてのオブジェクトが持ちます。

そして最重要ポイントは次のとおりです。

• objectGUIDは作成時に自動採番され、基本的にそのオブジェクトが存在する限り変わりません。
• 管理者権限があっても、通常の管理手段（ADUC、ADSI Edit、PowerShell、LDAP編集）で任意の値に書き換えることはできません。
• 「GUIDを変えたい」という要求を満たすには、別のID設計に切り替えるか、別オブジェクトとして作り直す必要があります。

言い換えると、objectGUIDは「変更できる属性」ではなく、ADの内部整合性を支えるための“生まれつきのID”に近い扱いです。

objectGUIDとは何か：名前やログオンIDとは別物の“内部キー”

ADを運用していると、ユーザー名やログオンIDのように、人が扱いやすい値に目が向きがちです。しかし、ADの世界には「人が変えられる属性」と「システムが保証する属性」が混在しています。objectGUIDは後者です。

識別子	例	変わりやすさ	主な用途	実務上の注意点
objectGUID	6f9619ff-8b86-d011-b42d-00c04fc964ff	原則変わらない	オブジェクトの一意識別、内部参照	移行で別オブジェクトになると別GUIDになる
distinguishedName（DN）	CN=Taro Yamada,OU=Sales,DC=example,DC=com	変わりやすい	LDAPパス、配置（OU）表現	移動・リネームで変わるため“キー”に不向き
sAMAccountName	yamada.t	変わり得る	従来互換のログオン名	命名変更・再利用で衝突や誤紐付けが起きやすい
userPrincipalName（UPN）	[email protected]	変わり得る	近年の主流ログオン名	メールアドレス変更やドメイン追加で変わる
objectSID	S-1-5-21-…	原則変わらない（ドメイン内）	アクセス権（セキュリティ）	別ドメイン/別フォレスト移行でSIDは変わる

この表のとおり、objectGUIDは「名前が変わっても追跡できる」ことを重視した識別子です。たとえば、ユーザーを別OUへ移動してDNが変わっても、同一オブジェクトとして追跡できます。

なぜobjectGUIDは変更できないのか：設計思想と運用リスク

「管理者なんだから書き換えられてもよさそう」と感じるかもしれません。しかし、objectGUIDは設計上“書き換えを許可しない”ことでディレクトリ全体の整合性を守っています。実務的に押さえるべき理由は次のとおりです。

システム管理属性（System-only）として扱われる

objectGUIDは、通常の属性のように「権限があれば編集できる」カテゴリではありません。ADはオブジェクトの作成時に自動で値を生成し、以後は読み取り専用のように扱います。PowerShellやLDAPから属性を書き換えようとしても、書き込み自体が拒否されます。

レプリケーションや参照整合性に影響する

ADはマルチマスターで動き、複数のドメインコントローラー間でオブジェクト情報を複製します。objectGUIDはオブジェクトの同一性を担保する重要な手掛かりの一つであり、任意変更を許すと「同一オブジェクトなのに別物に見える」「別オブジェクトなのに同じに見える」といった破綻が起こり得ます。

外部システム連携が“壊れる”可能性が高い

objectGUIDをキーにしているのはAD自身だけではありません。資産管理、ID管理、SSO、監査ログ、プロビジョニング、グループ管理、各種ディレクトリ連携など、「一生変わらない前提」で参照されていることが多いため、仮に改ざんできたとしても二次被害が大きくなります。

したがって、運用現場では「objectGUIDは変えられないもの」として設計・運用するのが原則です。

よくある誤解：OUの移動や名前変更でGUIDは変わる？

結論から言うと、同一ドメイン内での移動やリネームでは、通常objectGUIDは変わりません。変わるのはDNなど“場所や名前を表す属性”であり、オブジェクトそのものは同一のままだからです。

操作	objectGUID	補足
ユーザーの表示名変更	変わらない	cn/nameの変更。別人にはならない
ユーザーを別OUへ移動	変わらない	DNは変わるが同一オブジェクト
OU名の変更（リネーム）	変わらない	OU自体も同一オブジェクトとして扱われる
OUを別階層へ移動	変わらない	配置が変わるだけ
削除して新規作成（同じ名前で作り直し）	変わる	別オブジェクト。見た目が同じでもIDは別
AD Recycle Binで復元	変わらない	“同じオブジェクト”が戻るため
別フォレスト/別ドメインへ移行して新規作成	変わる	移行ツールは多くの場合「新規オブジェクト」を作る

特に注意したいのは「同じユーザー名で作り直したから同一人物として扱ってほしい」という要望です。AD視点では別人です。外部システムがobjectGUIDで紐付けている場合、作り直した瞬間に別ユーザーとして認識されます。

objectGUIDを確認する方法：PowerShellで“事実”を把握する

「変わった気がする」「移行後に一致しない」といった議論は、まず現物を確認すると整理が早いです。WindowsのActiveDirectoryモジュール（RSAT）を使い、PowerShellでobjectGUIDを確認できます。

ユーザーのobjectGUIDを表示する

Get-ADUser -Identity "yamada.t" -Properties objectGUID |
  Select-Object Name,SamAccountName,ObjectGUID,DistinguishedName

OUのobjectGUIDを表示する

Get-ADOrganizationalUnit -Identity "OU=Sales,DC=example,DC=com" -Properties objectGUID |
  Select-Object Name,ObjectGUID,DistinguishedName

GUIDをキーにオブジェクトを検索する（監査・照合に便利）

$guid = "6f9619ff-8b86-d011-b42d-00c04fc964ff"
Get-ADObject -Identity $guid -Properties objectGUID,distinguishedName |
  Select-Object Name,ObjectGUID,DistinguishedName,ObjectClass

この「GUIDから逆引き」ができると、ログや連携システム側にGUIDだけ残っている場合でも、AD上の実体を追跡できます。

連携でつまずきやすい：objectGUIDの「表記」と「型」の違い

objectGUIDは見た目が「xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx」の文字列ですが、AD内部では16バイトのバイナリとして保持されています。そのため、ツールやAPI、連携製品によって“見え方”が変わり、「同じはずなのに一致しない」というトラブルが起こりがちです。

見え方	例	どこで出会うか	注意点
標準のGUID文字列（ハイフン付き）	6f9619ff-8b86-d011-b42d-00c04fc964ff	PowerShell、GUIツール	人が読むのに最適。ログ保存もこの形が扱いやすい
ハイフン無し/大文字小文字違い	6F9619FF8B86D011B42D00C04FC964FF	一部のアプリ、ログ	文字列比較するなら正規化（ハイフン除去・小文字化）を検討
バイト配列（16 bytes）	System.Byte[]	LDAP/ADSI、各種SDK	文字列に変換してから比較しないと一致判定できない
Base64	/xmWb4aLEdC0LQDAT8lk/w==	クラウド連携やID管理製品の内部表現で採用されることがある	GUID→Base64変換は“バイト列”を元に行う。単純に文字列をBase64化しない

たとえば「GUIDを連携キーとして別システムに保存する」なら、どの表記で保存するかを統一し、変換ルールもドキュメント化しておくと後で助かります。

PowerShellでGUID⇔Base64を変換する例

# GUID → Base64（バイト列をBase64化）
$u = Get-ADUser -Identity "yamada.t" -Properties objectGUID
$b64 = [Convert]::ToBase64String($u.ObjectGUID.ToByteArray())
$b64

# Base64 → GUID

$bytes = [Convert]::FromBase64String($b64)
$guid  = New-Object Guid (,$bytes)
$guid.ToString()

この“表記揺れ”の理解は、移行時の突合や、ログ解析、外部ID管理のトラブルシュートで効いてきます。

「GUIDを変えたい」要望は、目的を分解すると解決しやすい

現場でobjectGUID変更の相談が出るとき、実は“GUIDそのものを変えたい”のではなく、次のような背景が隠れていることが多いです。

• 人事システムやID管理基盤のIDと揃えたい（GUIDがバラバラで困る）
• 移行や統合で、旧環境の識別子を引き継ぎたい
• 誤作成したユーザーを作り直したが、連携先が旧GUIDを参照している
• アプリがDNやユーザー名をキーにしており、移動・改名で壊れたため「変わらないIDが欲しい」

この場合の正攻法は「objectGUIDを変える」ではなく、目的に合う識別子を選び直すことです。

現実的な代替策：目的別に選ぶ

新しいユーザー／OUを作り直す（GUIDを変える唯一の“正常な”方法）

objectGUIDを変えたい理由が「別物として作り直したい」「誤作成をなかったことにしたい」であれば、新規作成が最も確実です。新しいオブジェクトは別のobjectGUIDを持ちます。

ただし、ユーザーを作り直すと副作用も大きいので、切り替え手順を設計してから実施します。

項目	作り直しで起きること	対策例
ファイルサーバー権限	新ユーザーは別SIDなのでアクセス不可になり得る	ACLの付け替え、必要に応じてSIDHistoryの活用
プロファイル/OneDrive	ユーザープロファイルの紐付けが変わる	移行手順・ツールの検討、周知
グループ所属	引き継がれない	既存所属を棚卸してスクリプトで移行
アプリ連携	旧GUID/旧SID参照だと切替が必要	連携側のキー設計を見直し、マッピングを用意

「GUIDだけ変えたいから作り直す」は本末転倒になりがちです。作り直しが本当に必要か、次の“別IDに切り替える”案と比較して判断するのが現実的です。

連携に使う識別子をobjectGUIDから別属性へ切り替える（おすすめ）

長期運用で効くのは、連携で使う“業務キー”をADの内部キー（objectGUID）に依存させない設計です。具体的には、社員番号や雇用IDのような「業務で一意」「再利用しない」「移行しても引き継げる」値を、ADの属性に保持して参照します。

ユーザーの場合、よく使われる候補は次のとおりです。

候補属性	用途イメージ	メリット	注意点
employeeID	社員番号	業務的に安定。連携キーにしやすい	未入力や重複を防ぐ運用ルールが必要
employeeNumber	雇用番号/人事ID	人事システムと合わせやすい	組織によっては運用されていない
extensionAttribute（拡張属性）	連携用の独自ID	既存スキーマで使える環境が多い	環境依存（Exchangeスキーマ等）
カスタム属性（スキーマ拡張）	自社専用の一意ID	要件に合わせた設計が可能	設計・審査・将来互換の責任が増える

OUの場合も同様で、「OU名（name）」やDNをキーにすると移動で壊れます。OUを外部連携のキーにしたいなら、OUに紐づく業務IDを別途持たせるか、そもそもOUを外部連携の主キーにしない設計に寄せるのが安全です（OUは運用都合で構造変更が起きやすいからです）。

移行・同期の文脈なら、SID/SIDHistory/msDS-ConsistencyGuidなど“別のID軸”を検討

「GUIDを変えたい」というより、移行や統合で“同一人物として継続したい”が本音のケースもあります。この場合は、用途に応じて別の軸を使います。

• SID（objectSID）：アクセス権の世界の主キー。ドメイン内では基本的に変わりませんが、別ドメイン/別フォレストへ移ると変わります。
• SIDHistory：移行時に旧SIDを保持し、旧権限を引き継ぐための仕組み。ファイルサーバー等のアクセスを段階移行する際に有効です。
• msDS-ConsistencyGuid：ディレクトリ同期や移行で“同一性の手掛かり”として利用されることがある属性。環境や設計次第で活用余地がありますが、同期基盤側の仕様・影響範囲を理解した上で扱う必要があります。

ポイントは、どのIDを“真のキー”として外部に公開するかです。ADの内部事情だけで決めると、将来の移行・クラウド連携・M&Aなどで痛い目を見ます。

実務で役立つ：ID設計の判断基準（チェックリスト）

「どの属性をキーにするべきか」で迷ったら、次の基準で評価すると失敗しにくくなります。

• 一意性：同じ値が二度と出ない（再利用しない）
• 安定性：組織改編・改名・OU移動で変わらない
• 移行耐性：別フォレスト移行やクラウド同期でも継続して使える
• 入力品質：空欄・重複・表記ゆれを運用で防げる
• 参照範囲：外部システムが参照しても問題ない（個人情報・秘匿性の観点）

この観点で見ると、objectGUIDは「AD内部では安定」ですが「別環境へ移すと継続しない」ため、長期の基盤連携キーにする場合は設計意図を明確にしておく必要があります。

トラブル回避：objectGUID依存で起こりやすい事故パターン

objectGUIDは便利な一方、使い方を誤るとトラブルになります。典型例を挙げます。

削除→同名で作り直し→連携システムが“別人”扱いになる

AD上では同じsAMAccountNameでも、オブジェクトが新規作成ならobjectGUIDは別です。連携側がobjectGUIDをキーにしていると、旧ユーザーのデータに紐付かず、二重アカウントや権限欠落が発生します。対策は「作り直し前に影響範囲を確認」「連携キーを業務IDへ寄せる」です。

DNをキーにしていたアプリが、OU移動で壊れる

DNは場所情報なので、OUの整理や組織改編で頻繁に変わります。DNをキーにしているアプリは、OU移動・リネームのたびに障害になります。対策は「DNではなくGUID/SID/業務IDをキーに」「検索条件はグループ/属性で持つ」です。

移行プロジェクトで“同一性の証明”ができず、手作業マッピングが増える

旧フォレストと新フォレストではobjectGUIDが一致しないのが一般的です。にもかかわらず旧環境の連携がobjectGUID依存だと、移行時に大量の突合作業が必要になります。対策は「移行前に業務キーをADへ格納しておく」「旧→新のマッピング表を自動生成できるようにする」です。

Q&A：objectGUIDに関するよくある質問

Enterprise AdminならobjectGUIDを書き換えられますか？

できません。権限で解決する話ではなく、objectGUIDはシステム管理属性として“書き込みを受け付けない”前提で設計されています。

ADSI Editで直接編集すればいけそうですが…

ADSI Editは強力ですが、編集できるのは“編集可能な属性”に限られます。objectGUIDは通常の方法では変更できず、無理に変更しようとする試みはサポート外で、ディレクトリ破損やレプリケーション不整合の原因になり得ます。

バックアップから復元したらGUIDは変わりますか？

同一オブジェクトとして復元されるなら、通常は同じobjectGUIDが維持されます。逆に、削除して新規に作り直す、別環境へ移行して新規に作られる、といったケースではGUIDは別物になります。

ExchangeのMailbox GUIDや、アプリ側のGUIDと混同していませんか？

現場ではよく混同が起きます。objectGUIDは“ADオブジェクト”のGUIDです。一方、Exchangeや他製品には別用途のGUID属性が存在します。どのGUIDを指しているのか（objectGUIDなのか、別属性なのか）を切り分けると、解決が早くなります。

まとめ：objectGUIDは“変えない前提”で設計する

• objectGUIDはADが自動付与する一意識別子で、通常の管理手段では変更できません。
• OU移動やリネームではGUIDは変わらず、削除して作り直す／別環境へ移行して新規作成すると変わります。
• 「GUIDを変えたい」要望は、作り直しか、連携キーを別属性（社員番号など）へ切り替えるか、移行なら別ID軸（SIDやmsDS-ConsistencyGuid等）を使う方向で解くのが現実的です。

最終的には、ADの内部キーに依存しすぎないID設計が、運用変更や将来の移行に強いディレクトリ基盤を作ります。まずはPowerShellで現状のobjectGUIDを棚卸しし、どこで参照されているかを把握するところから始めてみてください。