ITインフラ専門家の私でも、もうAIには勝てない――「Active Directory」障害対応をAIに丸ごと任せてみた結果：Microsoft MVP胡田のAI検証ラボ――情シス業務、AIにどこまで任せられるか（1）

AIにメールや資料を書かせるのではなく、システムを変更できる管理者権限を渡し、ITインフラ障害の調査から対処まで任せたら、何が起きるのでしょうか。本連載「Microsoft MVP胡田のAI検証ラボ――情シス業務、AIにどこまで任せられるか」の第1回では、AIにActive Directoryの障害対応を丸ごと任せました。原因も調査手順も教えません。AIはどこまで自力で原因にたどり着き、どのようにシステムを変更したのか。実際の操作記録とともに検証します。

[胡田昌彦, 編集：鳥越武史，＠IT]

連載目次

　私は「Windows 3.1」の頃から「Windows」を使い続け、20年以上ITインフラの仕事に携わってきました。2014年からはMicrosoftの表彰制度「Microsoft Most Valuable Professionals」（Microsoft MVP）をITインフラ領域で連続受賞しています。それでも率直に言えば、ITインフラの技術力で勝負しようとしても、私はもうAIにかなわないと思っています。

Microsoft MVPでも、もうAIにはかなわない

　構築から日常運用、障害対応まで――。AIは、インフラエンジニアが専門性を築いてきた分野にまで入ってきました。その実力は、文書作成や要約の延長という段階ではありません。知識量や調査の速度、複数領域を横断する力を見ると、自分が長年携わってきた分野でさえ、もう技術力で張り合う相手ではない。今回の検証で、その思いがさらに強くなりました。

　だから今、私はAIと技術力を競うことではなく、AIの力をどう使うかに時間を使っています。どの業務を渡すのか、どの権限を与えるのか、何を禁止し、どの証拠を確認するのか――。この連載では、構築や日常運用、障害対応などのITインフラ業務をAIに実際に任せて、どこまでできるのか、そして人間は何をすべきかを実機で確かめていきます。

　第1回で用意したのは、「Active Directory」（以下、AD）およびその標準的な認証プロトコル「Kerberos」を理解したインフラエンジニアでなければ、簡単には見抜けない障害です。AIに与えたのは「社内ポータルに全員ログインできない」という一次報告と、ADを含む検証環境を変更できる、ドメイン（ADの管理単位）管理者権限でした。

　AIは何を調べ、何を原因だと判断し、どのようにシステムを変更したのか。人間の介入は必要だったのか。そして長年ADを扱ってきた私が「もうかなわない」と感じたのは、どの部分だったのか――。実験の全記録を順に見ていきましょう。

AIに伝えたのは、あいまいな一次報告だけ

　第1回の舞台は、「Windows Server 2025」で構築した検証ラボです。この検証ラボは、以下の3台で構成しました。

• dc01：ADを管理するドメインコントローラー兼DNS（ドメインネームシステム）サーバ
• mem01：Webサーバの「Internet Information Services」（以下、IIS）で社内ポータルを動かすメンバーサーバ
• admin01：調査および管理用の仮想マシン（VM）

　admin01はドメインに参加済みで、AnthropicのAIコーディングツール「Claude Code」（バージョン2.1.197）とMicrosoftの「Word」をインストールしています。使用モデルは「Claude Opus 4.8」（claude-opus-4-8）です。

　症状は単純です。社内ポータル「http://intranet/」にアクセスすると、正しい資格情報を入力しても「401エラー」（Unauthorized：認証に失敗）になる、というものです（画面1）。特定の利用者だけではなく全員が失敗し、Webブラウザを変更しても症状は変わりません。

画面1　正しい資格情報でも社内ポータルが401エラーとなる《クリックで拡大》

　AIに渡したのは、この一次報告に加えて、3台のホスト名と役割、検証用の接続情報です。原因や調査手順は教えていません。その上で、次の業務を依頼しました。

1. 自分で調査し、根本原因を特定する
2. 暫定回避ではなく、恒久対処を実施する
3. 同じ確認方法で変更前後の結果（Before／After）を示す
4. 調査コマンドと根拠、影響範囲、再発防止策を含む障害報告書をWord形式で作る

　破壊的操作は禁止し、変更対象はdc01とmem01、ADだけに限定しました。変更は最小限かつ可逆的にして、実行前に変更内容を説明するという制約も設けています。Claude Codeはインストール直後で、特別なMCP（Model Context Protocol：外部ツール連携プロトコル）サーバや「Skills」（作業手順を再利用するための機能）などの導入もなし。AIに指示やルールを与える「CLAUDE.md」ファイルも書いていません。AIが自律的に判断して進めるオートモードに動作モードを切り替え、実行時の確認を求めない自動承認も有効にした後は、人間は手を触れませんでした。

2分18秒で「重複SPN」に到達

　Claude Codeは、まずDNSによる名前解決（ホスト名からIPアドレスを調べる処理）と、対象サーバへの到達性を確認しました。次に利用者と同じ資格情報を使って401エラーを再現して、IISで構成したWebサイトと認証設定を調べました。ここまでは、障害対応の定石通りです。

　状況が動いたのは、開始から約1分20秒後でした。Claude Codeは以下の2つを確認すると、すぐにSPN（Service Principal Name：サービスプリンシパル名）の登録状況を調べました。SPNは、PCなどのクライアントが接続するサービスを、Kerberosが一意に識別するための名前のことです。

• IISのアプリケーションプール（Webアプリケーションを実行する仕組み）の実行アカウントが、ドメインサービスアカウント（ADのサービス実行用アカウント）の「svc-webapp」であること
• IISが認証時に、アプリケーションプールの資格情報を使う設定になっていること

　そして開始2分18秒後、根本原因はSPNの重複（「Root cause found: duplicate SPN」）だと宣言しました。HTTPサービス用のSPNである「HTTP/intranet」と、そのFQDN（完全修飾ドメイン名）版のSPNが、本来のsvc-webappだけではなく、旧システムからの移行用ドメインサービスアカウントの「svc-legacy」にも登録されていたのです。

　SPNが重複すると、Kerberosの認証を管理するキー配布センター（KDC：Key Distribution Center）は、サービスチケット（SMBやHTTPなどのサービスへの接続に利用する認証チケット）を発行する際に、どのドメインサービスアカウントの暗号鍵を使うべきかを判断できません。Microsoftも「KDC_ERR_PRINCIPAL_NOT_UNIQUE」などのKerberosエラーが発生した際は、重複SPNや誤ったドメインサービスアカウントへの割り当てを確認するように説明しています（Microsoftの技術文書サイト「Microsoft Learn」の情報「Kerberos でKDC_ERR_S_PRINCIPAL_UNKNOWNまたはKDC_ERR_PRINCIPAL_NOT_UNIQUE エラーが生成される」）。

　Claude Codeは、1つのコマンドの実行結果だけで結論を急ぎませんでした。SPNの重複を検出するコマンド「setspn -X」による重複検出、Kerberosのサービスチケット取得を試すコマンド「klist get HTTP/intranet」による取得の失敗、ドメインコントローラーが記録したKDCの「イベント ID 11」（SPNの問題を示すイベント）という、3つの独立した証拠をそろえました（画面2）。

画面2　重複SPNを根本原因だと特定して、独立した証拠を集めた《クリックで拡大》

　私が意図的に仕込んだ障害も、まさにこの重複SPNだったのです。

4分41秒で復旧、検索はゼロ

　Claude Codeが選んだ恒久対処は、誤登録先のsvc-legacyから2つのHTTPサービス用のSPNだけを削除し、本来の登録先であるsvc-webappだけにSPNを登録した状態に戻すことでした。

　利用者の認証なしにアクセスを許可する「匿名認証」を有効にしたり、KerberosではなくWindowsの認証方式「NTLM」を代わりに使ったりといった、“取りあえず動かす”ための回避策は採用しませんでした。こうした回避策は、本来修正すべきKerberosの問題を残したまま運用することになり、セキュリティ面で望ましくありません。

　何らかの設定を変更する際、Claude Codeはどの設定をどのような理由で変更するのかを事前に説明しました。変更後には、以前に取得して一時保存していたKerberosのサービスチケットを削除。その後、同じコマンドでもう一度サービスチケットの取得を試し、正常に取得できることを確認しました。社内ポータルへのアクセスも401エラーから、正常にアクセスできたことを示すHTTPステータスコード「200 OK」に変わり、setspn -Xで検出する重複SPNのグループ数も2から0になりました（画面3）。調査開始から、障害の復旧を確認するまでに要した時間は4分41秒です。

画面3　401エラーや重複SPNなど、障害に関わる問題の解消を確認《クリックで拡大》

　ここまでClaude Codeは、少なくとも実行ログを確認する限り、インターネット検索を一度も使っていません。実行ログに残っていたのは、Windowsのコマンド実行ツール「PowerShell」と、Windowsに標準で備わる管理用コマンドだけです。ADの設定やIISの設定、Kerberosによる認証の状態、SPNの登録状況、KDCのイベントログを横断的に確認し、次に確認すべき証拠を選び続けました。

　今回の障害は「今のAIであれば簡単に解けるだろう」と予想はしていました。それでもADおよびKerberosに習熟したエンジニアでなければ、原因を見抜くことが難しい障害にもかかわらず、迷いなく一直線に原因にたどり着く速さには驚かされました。20年以上ITインフラに携わってきた私でも、この速さには全くかないません。

技術よりWordでつまずいた

　復旧後、Claude Codeは日本語の障害報告書をWord形式で作り始めました。ここで初めて、少しだけ“足踏み”します。日本語版Wordのスタイル（見出しや本文などの書式）をスタイル名で指定する処理が失敗したことから、組み込みスタイルID（スタイル識別のためにWordが内部で利用するID）を使って指定する方法に変更。続いて「PowerShell 7」からWordの「SaveAs」メソッド（ファイルを保存する操作）に渡す引数の指定方法でも失敗し、引数の渡し方を修正しました。どちらもエラーメッセージから失敗原因を読み取り、処理を修正して再実行し、突破しました。

　最終的にClaude Codeは、「事象概要」「実行コマンドと根拠」「恒久対処」「Before／After」などを含む8章構成の調査報告書を生成しました（画面4）。作成の全工程にかかった時間は8分38秒でした。

画面4　Claude Codeが作成したWord形式の障害報告書《クリックで拡大》

　内容はかなり良好です。重複SPNの定期検査やKDCのイベントID 11の監視、廃止予定アカウントの棚卸しに加えて、通常のドメインサービスアカウントからgMSA（グループ管理サービスアカウント：パスワード管理をADに任せられるサービス実行用アカウント）への移行の検討なども提案しました。一方で見出しに不要な番号を付けてしまうなど、文書の体裁には人手で整えたい部分が残っていました。

　つまり技術的な原因究明は優れていた一方で、「読み手に合わせて文書を仕上げる」部分には改善の余地が見えました。AIにとって、人間が読みやすいように文書の見た目を整えることの方が、ADの重複SPNによる障害を見つけて修正することよりも難しいというのは、なかなか面白いことですね。

　もちろん、あらかじめ人間が「心地よい」「読みやすい」と感じるようにスタイルを整えたテンプレートファイルを用意した上で、それを使うようにClaude Codeに指示したり、既定で使うように設定したりしておけば、Word文書の見た目は読みやすくなります。事前にこうした工夫をしておけば、余分な手間をかけずに完成度の高い文書に仕上げてくれることは申し添えておきます。

5段階評価：人間の介入はゼロ、でも人間の仕事はゼロではない

　本連載では、各回の検証結果を基に、それぞれのテーマでAIがどこまでできたのかを項目別に5段階で評価します。今回は次のような結果となりました。

第1回（AD障害対応）の検証結果

評価軸	評価	理由
自律性	★★★★★	調査経路を自分で選び、介入なしで完遂
原因究明	★★★★★	引き金と根本原因を分け、3系統の証拠で裏付け
安全性	★★★★☆	制約を守り最小変更を選択。本番では権限と承認の設計が必要
実行力	★★★★★	恒久対処と同一経路のBefore／Afterまで実施
報告品質	★★★★☆	内容は充実。体裁に修正余地

　今回、人間は調査中に一度も介入しませんでした。AIが担える仕事の幅は想像以上に広く、その質も高いことが分かりました。今回の結果を見る限り、AIは少なくとも技術的には、障害調査だけではなくインフラエンジニアのさまざまな仕事を担える可能性があります。

　それでも「人間の仕事がなくなった」と結論付けるのは早計です。今回は本番環境と切り離した検証ラボだからこそ、Claude Codeにドメイン管理者権限と自動承認を与えられました。本番環境であれば、誰が変更を承認するのか、どの範囲の権限を一時付与するのか、失敗した場合の責任を誰が負うのかを決めなければなりません。今回の実行ログには検証用とはいえ、本来は保護が必要な資格情報もそのまま残りました。技術的に実行できることと、組織として実行を許可できることは別問題なのです。

　ITインフラの構築や運用でもAIの成果は急速に上がっています。技術的にAIができないことは、もうほとんど残っていないのではないか――。今回の結果を見て、私はあらためてそう感じました。だからこそ、この連載でも「こんなコマンドも書けた」といった技術的な成果を示すだけでは物足りません。問うべきなのは、責任の所在や変更の承認、価値判断、関係者との合意形成といった、技術以外の意思決定におけるAIと人間の境界線です。

　AIに作業を任せられるかどうかを試す段階から、AIをどのようなルールで働かせるかを設計する段階へ――。インフラエンジニアの役割は「手を動かす人」から「目的と制約をAIに与えて、証拠を評価し、最終責任を持つ人」へと変わりつつあります。AIと人間の役割の境界がどこまで動くのか。次回以降も実際にAIを動かしながら確かめていきます。

おまけの考察：AIは原因を直し、人間は「なぜ今、壊れたのか」を考えた

　最後に、今回の検証の本筋ではないのでここまで触れていなかった、興味深いことを一つ紹介します。

　WindowsはKerberosによる認証を利用できない場合、構成や失敗の仕方によっては、代わりの認証方式としてNTLMを利用します。NTLMによる認証に切り替われば、利用者はアクセスを継続できます。

　今回は、正しいIDとパスワードを入力しても、全利用者が401エラーとなりました。セキュリティ強化のために、検証対象のmem01に対して、NTLMによる認証を拒否する設定を入れていたからです。Kerberosによる認証は重複SPNによって失敗し、代わりに使うはずだったNTLMによる認証もサーバが拒否する――。2つの条件が重なったことで、利用できる認証方式がなくなっていたのです。

　Claude Codeは、このうち重複SPNを正確に見つけました。しかも複数の証拠で裏付けた上で、不要なSPNだけを削除し、Kerberosによる認証を正常に復旧させています。障害対応として見れば、ほぼパーフェクトです。一方で「一般的な構成であればNTLMによる認証に切り替わりそうなのに、なぜ今回は全員が一斉にログインできなくなったのか」「この検証環境には何か特殊なセキュリティ設定があるのではないか」といった点については、そこまでは掘り下げませんでした。

　ここから先は、今回の検証で確認したことではありません。実環境で同じ障害が起きていたと仮定すると、人間であれば点と点をつないで次のようなストーリーを組み立てるのではないでしょうか。

1. 重複SPNは、実は以前から存在していた
2. Kerberosによる認証は失敗していたものの、NTLMによる認証に切り替わっていたことから、利用者には正常に動作しているように見えていた
3. その後、セキュリティ強化のために、NTLMによる認証を拒否する設定が加わった
4. 逃げ道がなくなったことで、以前から潜んでいた“半分壊れた状態”が完全な障害として表面化した

　このストーリーを基に考えると、重複SPNが障害の根本原因であり、NTLM禁止はそれを表面化させた最後の引き金ということになります。セキュリティ強化が障害を作ったのではありません。セキュリティ強化によって、それまでNTLMによる認証に隠されていた、Kerberosの不具合が見えるようになったと考える方が自然です。

　もちろん今回は検証ラボですので、私が意図的に条件を組み合わせました。実際に「昔から重複SPNがあり、後からNTLM禁止が入った」という時系列を示す変更記録やログはありません。上記のプロセスは事実として障害報告書に書ける内容ではなく、あくまでも今回の検証結果を基に、人間が組み立てた仮説です。

　AIが余計なストーリーを作らず、現在の証拠から確実に言える根本原因だけを報告したことは、むしろ正確さの表れでもあります。一方で人間は、組織の変更履歴や過去の運用記録、さらには現場の「以前は動いていた」という記憶まで結び付けて、「なぜ今、この障害が表面化したのか」という背景を推測できます。

　事実に忠実で、最短距離で原因を直すAI。点と点をつないで仮説を組み立てて、出来事をストーリーとして理解する人間。どちらが優れているという話ではなく、両方を組み合わせることで、障害対応を「直して終わり」ではなく、「なぜ起きたのかを理解し、次を防ぐ」仕事に変えやすくなるのではないでしょうか。

実際のAIの仕事ぶりは動画で

　「本当にAIだけで、ここまでできたのか」と思った方や、Claude Codeがどのような順番で調査し、重複SPNへたどり着いたのかを実際に見てみたい方に向けて、今回の検証の様子を「YouTube」動画として公開しています。

　この動画は、＠ITの本記事と連動する内容です。あいまいな一次報告を受け取ったところから、原因の特定や恒久対処、復旧確認、Word形式の障害報告書を作成するまで、AIが操作する実際の画面と時間の流れを確認できます。記事で紹介した「2分18秒で原因特定」「4分41秒で復旧」「8分38秒で報告書まで完了」が本当なのかどうか、ぜひご自身の目で確かめてみてください。

＠ITの本記事と連動したYouTube動画を見る

• AIはインフラ障害を直せるのか？Claude Codeに調査から報告書まで丸投げしてみた（YouTube）

筆者紹介

胡田昌彦（えびすだ・まさひこ）

日本ビジネスシステムズに勤務。幼少期からコンピュータ大好きで歴は40年以上。インフラから、クラウド、アプリ、生成AIまで幅広く取組中。2014年からMicrosoft MVPアワードを連続受賞中。Windows、Windows Server、Microsoft Azure、Microsoft 365など、Microsoftソリューションを中心に情報発信中。YouTuberとしても活動中（https://www.youtube.com/@ebibibi）。