サーバーが巻き戻ったとき、Azureはどうなる？ ─ Arcのエージェント・マシン構成・Policyを実機で戻してみた

バックアップから復元した、スナップショットで巻き戻した。そのとき Azure Arc のエージェント、マシン構成、Azure Policy はどうなるのか。実機（Windows Server 2025）をセッション中に4日前へ巻き戻し、何が自力で戻り、何が戻らないかを測ります。持ち帰りは「復元・巻き戻しのあとに回す5つの手順」。戻し方が確立していれば、Azure Update Manager でパッチを当てるのは怖くない、というところまで。HCCJP 第77回勉強会（2026-09-11）の進行スライド。

サーバーが巻き戻ったとき、Azureはどうなる？

HCCJP第77回勉強会を始めます。今日のテーマは「サーバーが巻き戻ったとき、Azureはどうなるのか」です。前回まででArcを使うとオンプレの管理が楽になることはお見せしました。今日はその先です。バックアップから戻した、スナップショットで巻き戻した。そのときAzure側で何が起きるのか。エージェント、マシン構成、Azure Policyの3つに絞って、実機で確かめた結果をお話しします。 しかも今日は、このセッションの途中で実際に巻き戻します。戻したあとの15分を、そのまま結果を見る時間に使います。 【開始前の仕込み・13:45】(0) **`mstsc /v:192.168.1.253:13389` で L1（nested-lab-01）に RDP し（ユーザー `Administrator`・資格情報は事前保存）、Hyper-V マネージャーを開いたまま置いておく**。arcwin01 の［チェックポイント］に `T1-hccjp77` と `T6-demo-ready` が見えることを確認する（無いとデモが成立しない）。(1) Update Manager の評価を arcwin01 / arclnx01 にかけておく（2〜4分かかる）。(2) **Run Command を1回空打ちしておく** ─ 初回は約9分かかるので、温めないと本番で必ず待たされる。(3) ブラウザのタブを左から［Arc マシン一覧］［arcwin01 Overview］［arcwin01 マシン構成］［Policy コンプライアンス］［Update Manager］［Resource Graph エクスプローラー］［Hyper-V マネージャー（nested-lab-01 へRDP）］の順に固定。(4) ターミナル1枚・18pt以上、`export SUB=...` を通しておく。詳細は presentations リポジトリの HCCJP_77/run-of-show.md。

本日の流れ

本日の流れです。14時5分から45分ほど私のセッション、そのあとQ&A、15時から高添さんのAdaptive Cloud最新動向、最後にクロージングという構成です。 【画面なし】口頭のみ。ここは30秒で抜ける。

話す人

胡田昌彦です。日本ビジネスシステムズ株式会社に所属し、Microsoft MVPを14年連続で受賞しています。HCCJPの主幹事もしています。

前回のおさらい ─ Arcで繋ぐと、ここまで楽になる

前回、第76回では、オンプレのサーバーをその場で壊して、AIエージェントに直してもらいました。誰もそのサーバーにログインせず、VPNも踏み台もなしで、Azure越しに調査から復旧まで通しました。Arcで繋いでおけば、オンプレの面倒くささはかなり消える、というところまではお見せできたと思います。 ポイントは右側です。Azure側の入口が az コマンドに統一されているので、AIエージェントがそのまま運用の手を持てる。これは今日の最後にもう一度出てきます。 【画面・15秒】第76回のアーカイブ（https://www.youtube.com/@hccjp）のサムネイルを一瞬だけ見せて「これです」と言う。再生はしない。

今日の登場人物 ─ どこにいるサーバーなのか

今日巻き戻すサーバーが、どこにいるのかを先に共有させてください。3層になっています。一番外側のL0が事務所の物理サーバー。その中で動いているL1が、ネストされたHyper-Vホスト。そのさらに中にいるL2が、Arcに繋いであるarcwin01とarclnx01です。 ここで押さえていただきたいのは、**戻す人と戻される人が別の層にいる**ということです。チェックポイントを持っているのはL1で、Azureから見えているのはL2だけ。つまりAzureは、自分の管理下のサーバーが巻き戻されたことを、直接には知りようがない。この構造が、今日の結果のほとんどを説明します。 【画面・40秒】**すでに開いてある L1（nested-lab-01）の Hyper-V マネージャー**に切り替え、arcwin01 / arclnx01 と、そこに刺さっているチェックポイント（T1-hccjp77 / T6-demo-ready）を見せる。**この画面はAzureポータルではなく、Azureからは触れない場所**だと言う。あとでここに戻ってきて巻き戻す、と予告しておく。「この画面はAzureポータルではありません。Azureからは触れない場所です」と言う。

まず棚卸し ─ Arc経由で何が手に入るのか

本題の前に、Arcで繋ぐと何が手に入るのかを整理します。公式は統制・保護・構成・監視の4つに分けています。エージェント1本入れるだけで、この全部が使えるようになります。 【画面・40秒】ポータルの arcwin01 のページを開き、左メニューを上から下へゆっくりスクロールして指す。「このスライドの4分類は、実はこの左メニューそのものです」— 拡張機能／更新／マシン構成／インサイト／SSH が並んでいるのを見せる。スライドに戻る。

無料の範囲で、どこまで・どのくらいの速さでできるか

一覧で見せるだけでは意味がないので、実際に動かして時間を測りました。ここに並べたのは全部、**Arc に繋いだだけで使える（追加課金のない）機能**です。 Arc経由のコマンド実行は42秒で返ってきます。ただし**初回だけは別で、実測で約9分かかりました**。初回セットアップが走るためで、2回目からは数十秒です。デモや障害対応で使うなら、**先に1回空打ちして温めておく**のが正解です。 SSHは、NATの内側にいる10.10.0.41のサーバーに、ポートを1つも開けずに到達できました。マネージドIDのトークンもゲストの中から取れます。拡張機能の配布も2分以内。Resource Graphなら全台まとめて1クエリです。全部、インバウンドの穴なしです。 なお、**マシン構成をこの一覧から外しました**。マシン構成はArc接続マシンだと1台あたり月6ドルの有料機能なので、「ここまで課金ゼロ」の枠には入りません。課金の線引きはあとのスライドでまとめて話します。 【デモ①・実機・2〜3分】Run Command をその場で流す（**開始前に空打ちで温めてあること**）。コマンドは run-of-show.md のデモ①から。待っている間に「インバウンドのポートは1つも開けていません。エージェントが外向き443だけで取りに来ています」と話す。 **保険**: 40秒で返らなければ深追いしない。既存の実行結果（runCommands/hccjp77-check）を GET して見せるか、スライドの「42秒」に戻す。

今日確認する3つのこと

ここからが今日の本題です。機能の紹介はここまでにして、残りの時間は3つの問いだけを追いかけます。 パッチで壊れた。スナップショットで巻き戻した。バックアップから復元した。そのとき、1つ目、エージェントはどうなるのか。Azureとの繋がりは切れるのか、切れたら現地に行かずに戻せるのか。2つ目、マシン構成はどうなるのか。配ったOS設定は当然巻き戻りますが、Azureは気づいて自分で直してくれるのか。3つ目、Policyはどうなるのか。割り当ては残るのか、そしてポータルに出ている準拠・非準拠の表示は、いつ本当のことを言っているのか。 この3つの答えを、手順書の形にして持ち帰っていただきます。 【画面なし】ここはスライドのまま、ゆっくり。3つを指で数えながら話す。

「Azure Policy」と「マシン構成」は、評価するレイヤーが違う

その前に、1つだけ用語を整理させてください。ここを混ぜると、このあとの話が全部ぼやけます。実は前回の私が混ぜていました。 Azure Policyが見るのは、Azureリソースの「形」です。このArcマシンに拡張機能が入っているか、といった話。一方マシン構成が見るのは、OSの「中身」です。タイムゾーンが東京か、TLS 1.2が有効か。 動く場所が違います。Policyの評価はAzure側で、OSの中身を実際に見に行くのは、実機の中にいるMachine Configuration agentです。**ここがArcならではのポイントで、Azure VMだと拡張機能を1つ入れる必要があるんですが、Arcの場合はConnected Machine agentに最初から内蔵されています。**実際、うちのarcwin01の拡張機能一覧を見ても、Guest Configurationの拡張は入っていません。Windowsだと gcarcservice というサービスがそれです。 直し方も違います。Policyは Modify や DeployIfNotExists で修復できますが、既に存在するリソースには修復タスクを回す必要があります。マシン構成は ApplyAndAutoCorrect なら直す、Audit は直さない。 そして下の行が今日の伏線です。**名前が紛らわしいのですが、マシン構成は別サービスではありません。**旧称を Azure Policy Guest Configuration といって、Policy から配って、その結果を Policy が読み取る、という関係です。だから準拠状態は両方に出ます。しかも、**同じタイミングでは更新されません**。マシン構成は15分ごと、Policyの標準評価は24時間ごと。この時計のズレが、あとで効いてきます。 【画面なし】スライドのまま。ここは急がない。「評価するレイヤーが違うだけで、別物ではない」「時計が違う」の2つだけ持って帰ってもらえれば十分。

戻す手段は、二段構え

戻す手段の整理です。チェックポイントとバックアップは役割が違います。チェックポイントは同じホストの同じストレージに乗るので、ホストごと死んだら一緒に消えます。速く戻せるかわりに、保険にはならない。ランサムウェアにもほぼ無力です。 よく「本番でスナップショットを使うな」と言われますが、公式ドキュメントには、ソフトウェア更新を当てる前にチェックポイントを作るとよい、と書かれています。ダメなのはバックアップの代わりに使うことです。 それから、これは今回の検証中に踏んだ罠なので共有します。本番チェックポイントを使えという話はよく聞きますが、**Get-VMSnapshot の SnapshotType では本番と標準を見分けられません**。実測で、VMのCheckpointTypeがProductionOnlyになっているのに、作られたチェックポイントのSnapshotTypeはStandardと表示されました。確認したいときは Get-VM の CheckpointType を見てください。 復元先の話も1行入れてあります。MABSで戻す場合、元のVMに戻すのは公式にサポート内。別ホストに戻すと管理対象外のVMになります。つまり**元の場所に戻す設計にすれば、全部サポート内で回ります**。パッチ失敗のロールバックは、まさにこのケースです。 【画面・20秒】必要なら Microsoft Learn のチェックポイントのページを開いて「applying a software update」の一文を指す。時間が押していたら開かずに口頭だけでよい。

実際にチェックポイントに戻して挙動を確認しましょう

では、やります。ここから先はライブです。手順は D1 から D8 まで番号を振ってあるので、番号順にコマンドを打つだけです。 作業は全部 **L1（nested-lab-01）の1画面**で完結します。Hyper-V マネージャーもここ、PowerShell もここ。画面を行き来しません。接続は `mstsc /v:192.168.1.253:13389`、ユーザーは `Administrator`、**パスワードは事前に mstsc へ保存しておく**（本番で打たない。値は Obsidian `09_Outputs/2026-09-11_HCCJP77_当日デモ手順.md` にある。このリポジトリは public なので書かない）。13389 は NAT で L1 の 3389 へ転送されます。**arcwin01 は L0 の Hyper-V マネージャーには出てきません** ─ 持ち主は L1 です。 **開始前に `C:\hccjp77\demo\D0-precheck.ps1`** を流して、VM の状態・チェックポイント・Arc の接続を確認しておく。ブラウザで Azure ポータル ＞ arcwin01 ＞［マシン構成］も開いておく。 【D1】`C:\hccjp77\demo\D1-before.ps1` ─ 巻き戻す前の正常な姿。OS の実値と、**このマシンが持っている割り当て**が出る。`C:\ProgramData\GuestConfig\Configuration\` の中身です。モードと評価間隔（適用型15分／監査型60分）が**実データとして**並ぶので、ここは指差して読む。推定ではなく設定ファイルの中身だと言い切ってよい。 **準備中はここに5つ目がいました。**テナント既定のベンチマーク監査です。それが評価キューを占有して全部を止めていたので、**今日のデモに限って一時的に無効にしてあります**（イニシアチブのパラメータ `windowsGuestConfigBaselinesMonitoringEffect` を Disabled に）。**これはデモの都合であって、本番でやることではありません。**なぜそうしたのか、そこから何が分かったのかは、後のスライドで話します。 【D2】**Hyper-V マネージャーで巻き戻す。ここが山場。** (1) `arcwin01` を選ぶ (2) 下の［チェックポイント］で **`T7-demo-start` を右クリック →［適用］** (3) ダイアログは **［適用］**（［チェックポイントの作成と適用］は選ばない） (4) **⚠️ VMが「オフ」になる** ─ チェックポイントは State=Off で保存されているので、適用しただけでは起動しない (5) **`arcwin01` を右クリック →［起動］** (6) 起動を確認したら `D2-mark.ps1` を叩く。以降の経過時間の基準になります。 【D3】`D3-status.ps1` ─ 起動直後。**ポータルは全部グリーン、でも OS の値はもう壊れている。** 2つの画面を並べて見せる。今日いちばん伝えたいのはここです。 【D4〜D6】待ち時間に中を見せる。`D4-assignments.ps1` で「割り当ては巻き戻しても消えていない」、`D5-timeline.ps1` でエージェントのログ、`D6-queue.ps1` で**誰が順番待ちしているか**。10〜20分で赤が3つ灯るので、そのたびにポータルを更新する（**実測では9分・17分・18分とばらついた。早ければ10分、遅いと20分超**と言っておくと安全）。 【D8】`D8-verify.ps1` を数分おきに叩いて、OS の値が書き戻されるのを待つ。**重い監査を外してあるので、順番待ちで数十分待たされることはない。** 【待ち時間を詰めたいとき】`restart.ps1`（エージェント再起動）を打つと、**次の評価サイクルに強制的に突入できる**。実測で約3分で Set まで到達した。1回目の評価は Test だけで Set は次の評価なので、これを知っていると待ち時間が15分→3分になる。すでに直っていれば Set はスキップされるので、何度打っても安全。 **ただしこれは、重い監査を一時的に無効にしてあるから素直に効いている。**無効にする前に同じことをやったら41分かかった（キューは空くが、空いたあとの順番までは制御できない）。**「だから外せ」という話ではない**ので、そこは ghost と recovery-runbook のスライドで丁寧に言う。 **戻りきるまで待てなくても構いません。** このあとのスライドは全部、事前に実測した結果です。時間が押していたら D7 まで見せて、数字はスライドで話す。**保険**: GUI が固まったら L0 の `C:\hccjp77\2-rollback.ps1`（約12秒）。環境の復旧は `C:\hccjp77\9-restore.ps1`。

事前テスト時の記録

ここから先のスライドは、**事前テスト（9月5日〜9日）で同じ手順を回したときの実測**です。いま巻き戻したばかりの実機は、まだ結果が出そろっていません。走らせたまま、先に答えを見ていきます。 【画面なし】区切りの1枚。10秒で抜ける。

①エージェントは ─ 落ちませんでした

1つ目の問い、エージェントです。結論から言うと、**落ちませんでした**。 いま巻き戻したばかりですが、ポータルは Connected のままです。実測では70分間、一度も Disconnected になりませんでした。復元して起動するまで11.5秒。実機は4日前に戻っていて、OSも再起動して、設定も過去のものなのに、Azureから見ると何も起きていないように見えます。 これは私の想定の訂正でもあります。準備段階では「巻き戻したらエージェントを再接続するコマンドが要るだろう」と思っていました。要りませんでした。エージェントが死ぬのは**Azure側のリソースを消したとき**で、そのときは実測22日間ずっとDisconnectedのままでしたが、巻き戻し単体では起きません。 なぜ気づかないかというと、ハートビートは5分ごとで、15分途切れて初めてDisconnectedになるからです。巻き戻しはその猶予に収まる。さらにL0/L1/L2の話に戻ると、巻き戻しはAzureの外側で起きているので、通知が飛ぶ経路がそもそもありません。lastStatusChangeだけは9分後に動きましたが、状態はConnectedのままでした。 【画面・40秒】ポータルの arcwin01 Overview を見せる。「今まさに巻き戻した直後ですが、この画面はこの色です」と言う。

②適用型は直る。監査型は、直さない

2つ目、マシン構成です。ここは割り当てのモードできれいに分かれました。 左のApplyAndAutoCorrect、適用型。これは**自力で直りました**。しかも表示が戻っただけではなくて、実機のレジストリにTLS 1.2が書き戻されているのを確認しています。Enabled=1。ちゃんと直っています。所要は、エージェントを再起動してから4〜6分。 右のAudit、監査型。こちらは**直りません**。ずっと非準拠のままです。ここは言い方が大事で、「自己修復に失敗した」のではありません。**監査型はSetを持っていない**んです。元から何も適用しない仕組みなので、直す気がない。割り当てモードを見ないまま「構成が効いていない」と言ってはいけない、というのがここの教訓です。 ただし ─ ここからが今日いちばん面白いところです。そこに辿り着くまで、**40分以上かかりました**。最初はずっと非準拠のままで、私は「適用型も復元後は直らないんだ」と結論しかけました。前回とまったく同じ間違いをするところだった。犯人は、この構成の外にいます。 【デモ③・実機・1分】ポータル ＞ arcwin01 ＞［マシン構成］。割り当ての一覧と、それぞれの種類（ApplyAndAutoCorrect / Audit）が並んでいるのを見せる。

【犯人】5つ目の割り当ては、自分で入れたものではない

犯人はこれでした。 私が入れた割り当ては4件です。ところが実機は**5件持っています**。5つ目は `AzureWindowsBaseline` ─ 重いセキュリティベースラインの監査です。誰が入れたかというと、**私ではありません**。テナントの一番上、Tenant Root Group に既定で割り当てられている「**Azure セキュリティ ベンチマーク**」です。Defender for Cloud を有効にすると入るあれです。除外スコープは空、つまり配下の全部に効いています。 そして**マシン構成の評価は、1台につき1本ずつしか動きません**。順番待ちです。この監査は1周が **2321秒、38分41秒**。その間、他の構成のタイマーは時間どおりに鳴っているのに、順番が来ないので実行されない。自己修復すらできない。 ここ、ログの読み方が大事です。「Run Consistency」という行は出るんです。タイマーは鳴っている。でもその次に来るはずの「Starting consistency」が出てこない。**この2行の間が開いていたら、それが順番待ちのサインです。** 正直に申し上げると、私は準備中にここで**3回間違えました**。 1回目は「適用型は復元後に自己修復しない」と結論しかけた。2回目は「割り当てを消せば直る」と思った ─ 消しても Policy が作り直すので直りません。**消えないのではなく、消しても戻ってくる。** そして3回目。「じゃあエージェントを再起動すればキューが空いて速く直る」と思いました。1回試したら4分半で直ったので、そう書きかけた。**でもこれが間違いでした。**もう一度測ったら、**再起動しても41分かかった**んです。再起動でキューは確かに空になる。でも**空になったあとの順番は運任せ**で、重い監査が2番目に入り直せば、結局その1周を待つことになる。最初の4分半は、たまたま監査が後ろに回っただけでした。放置した場合の約43分と、実質変わりません。 **答えは1つだけです。重い監査を、そのマシンの評価対象から外す。**除外スコープを設定する。今日のラボはそうしてあります。その場しのぎの再起動では解決しません。 ここで**誤解していただきたくないこと**があります。**このベースライン監査は、外すべきものではありません。**セキュリティベースラインの監査は必要なものです。今日のデモでは、45分のセッションの中で自己修復をお見せするために一時的に無効にしていますが、**これはデモの都合です**。本番環境で真似しないでください。 持ち帰っていただきたいのは「外せ」ではなく、**仕組みを知っておくこと**です。評価は1台につき1本ずつ。重い監査が走っていると、その1周が終わるまで他の割り当ての順番は来ない。**これを知っていれば「直らない＝壊れた」と誤診しません。**逆に知らないと、私が準備中にやったように「機能が効いていない」と結論してしまいます。 どうしても急ぐ障害対応の場面で、一時的に効果を無効化する選択肢はあります。ただしそれは**セキュリティとのトレードオフとして意識的に判断するもの**であって、日常の運用手順ではありません。 **自己修復が効いていないように見えたら、まず順番待ちを疑ってください。**そして、自分で入れた覚えのない重い監査が1件混ざっているかもしれない、ということも。 【デモ⑤・実機・1分】`C:\hccjp77\demo\D6-queue.ps1` を実行し、**誰が実行中で、誰が順番待ちか**の表を出す。5つ同時にタイマーが鳴って、1つだけが走っている絵になる。

③緑には、2種類あります

4つ目、準拠の表示そのものの話です。これが今日いちばん持ち帰っていただきたいことかもしれません。 復元したあとポータルを見ると、緑と赤が並びます。ところがこの緑には2種類あるんです。ひとつは、復元後に評価されて本当に準拠している緑。もうひとつは、**巻き戻す前の判定が残っているだけの緑**です。 実測です。ExploitGuardは非準拠で、最終評価は41分前。一方SetWindowsTimeZoneは準拠と出ていますが、最終評価は**72分前**。これは巻き戻すより前の時刻です。つまり復元後に一度も評価されていない。中身を保証していません。 そして画面上、この2つの緑は**見分けがつきません**。だから復元後に見るべきなのは「緑かどうか」ではなくて、「**いつ評価されたか**」です。 時計が3つあるのも効いてきます。適用型は15分ごと、監査型は60分ごと、そしてAzure Policyの準拠評価は既定で24時間ごと。監査型の非準拠は最大1時間見えないし、Policyの表示は再スキャンを打つまで前の判定のままです。 【デモ④・実機・1分】ポータルのマシン構成一覧で「最終評価」の列を指す。ターミナルで `az policy state trigger-scan --resource-group rg-hccjp76-arc` を打っておく。

【地雷】日本語Windowsでは、この組み込みポリシーが準拠にならない

待っている間に、今回いちばん驚いた話をさせてください。**どのポリシーで、何が起きて、なぜなのか**を具体的に話します。 使ったのは組み込み定義「**Configure time zone on Windows machines**」、定義ID は 6141c932-9384-44c6-a395-59e4c057d7c9 です。中身はマシン構成の `SetWindowsTimeZone` で、ApplyAndAutoCorrect で割り当てました。ところが**24時間たっても実機のタイムゾーンは変わらず**、ずっと NonCompliant のまま。割り当てのレポートには毎回「Cannot bind argument to parameter 'Id' because it is null」が出ていました。 原因は、配られたDSCリソースの中身にありました。タイムゾーンを**IdではなくDisplayNameで照合**しているんです。実機（日本語Windows）のDisplayNameは「(UTC+09:00) 大阪、札幌、東京」。一方、組み込みポリシーの許容値（allowedValues）は英語の「(UTC+09:00) Osaka, Sapporo, Tokyo」しか持っていません。一致しないので変数がnullになり、`Set-TimeZone -Id $null` がパラメータ束縛で落ちる。**Testも同じ比較なので、評価も永久に非準拠**です。 つまり**日本語UIのWindowsでは、この組み込みポリシーは設定だけではどうやっても準拠にできません**。しかもApplyAndAutoCorrectなので、15分ごとに永久に失敗し続けます。 【画面なし】スライドのまま。次のスライドで回避策を3つ話す。

全部を自作する必要はない ─ 回避は3通り

「じゃあ組み込みは使えないのか、全部自作なのか」というと、そんなことはありません。回避は3通りあります。 1つ目。**マシン構成を直接割り当てるなら、組み込みのままでいい**。configurationParameter の値に、実機の表示名 ─ `(Get-TimeZone).DisplayName` で出てくる「(UTC+09:00) 大阪、札幌、東京」 ─ をそのまま渡すだけで通ります。**Idを渡してはいけません**、ここが引っかかりどころです。 2つ目。**Azure Policy から配る場合**は、ポータルの許容値に日本語表示名がないので選べません。この場合だけ、組み込み定義をコピーして `TimeZone` の allowedValues を外したカスタム定義を作ります。DeployIfNotExists なので、マネージドIDと Guest Configuration Resource Contributor ロールが必要です。**直すのは1か所だけで、ロジックを書き直すわけではありません**。 3つ目。**新規構築なら、そもそもOSを英語UIで揃える**。ロケール依存の照合を踏まないのがいちばん安く済みます。日本語UIが要件なら1つ目か2つ目で回避します。 トラブルシュートの順番も持ち帰ってください。①割り当てのレポート（reports API）の reasons を読む ─ 「効かない」ではなく具体的な失敗理由が出ます。②実機の `gc_worker.log` で Test か Set か、何秒かかったかを見る。③配られたDSCモジュール本体（`C:\ProgramData\GuestConfig\Configuration\<割り当て名>\Modules\...psm1`）を読む。**実体は全部、実機のディスクにあります**。 一般化すると、**組み込みが効かないときは「ロケール依存の文字列照合」を疑ってください**。タイムゾーン、地域名、言語名、組み込みグループ名は日本語OSで名前が変わります。「Policyが効かない」の原因が、Policyの外にあることがある、という話です。 【画面なし】スライドのまま。ここは笑いどころでもあるので、ゆっくり話す。

復元・巻き戻しのあとの5つのチェックポイント

まとめて、持ち帰っていただく手順です。 1つ目、Arcの接続を見る。たぶん無事です。切れていたら再接続2コマンドですが、巻き戻しでは切れませんでした。2つ目、**実機の割り当てを数える**。Azureの件数と一致しなければ、復元で蘇ったゴーストがいます。**これを消すまで他が直りません**。3つ目、割り当てモードで期待値を分ける。適用型は待てば直る、監査型は待っても直らない。4つ目、緑を見ずに最終評価時刻を見る。5つ目、Policyとパッチは再評価を打ってから判断する。 2番だけが今回の新発見です。ここを飛ばすと、1から5まで全部やっても直りません。逆に言うと、この5つを順番に回せば戻せます。 【デモ⑤・実機・2分・巻き戻しの答え合わせ】experiment から約17分。(1) ポータルで Connected を確認 (2) マシン構成の準拠と**最終評価時刻の列** (3) L0 で `C:\hccjp77\1-status.ps1` を流し、**実機が持っている割り当ての件数**をポータルの件数と見比べる (4) 必要なら `C:\hccjp77\3-evict-ghost.ps1`。 **17分たっても全部緑だった場合**: それも結果。「17分たってもポータルは緑のままでした」と言えば今日の主張はむしろ強くなる。慌てて掘りに行かない。 クエリ: `resources | where type =~ 'microsoft.hybridcompute/machines' | project name, status=properties.status, agent=properties.agentVersion, lastSeen=properties.lastStatusChange` **保険**: 戻っていなくてもそれが結果。「15分では戻りませんでした、理由はさっきのゴーストです」と言えば筋が通る。 **後始末（配信後）**: `C:\hccjp77\9-restore.ps1` で T6-demo-ready へ戻す。 **4番と5番は、順番が大事です。** 4番。赤くなったのを見て「壊れた」と思わないでください。**1回目の評価は Test だけ**です。「値が違う」と気づいて非準拠を報告するところまでで、実際に書き戻す Set は次の評価で走ります。実機の `metaconfig.json` が `configurationMode=ApplyAndMonitor` になっていて、自動修正はその上のレイヤーが担当しているからです。待てば15分。**急ぐなら `Restart-Service gcarcservice` で次のサイクルに強制的に突入できます。実測で3分。**すでに直っていれば Set はスキップされるので、何度打っても安全です。 5番。**再起動が効かない場合があります。**再起動でキューは空きますが、空いたあとの順番までは制御できません。重い監査が先に入り直せば、結局その1周（実測2321秒＝38分41秒）を待つことになります。準備中、実際に41分かかりました。 ここで「じゃあ重い監査を外せばいい」と言いたくなりますが、**それは違います。**ベースライン監査は必要なものです。今日のデモでは時間の都合で一時的に無効化していますが、本番でやることではありません。 **5番で持ち帰っていただきたいのは、対処法ではなく判断材料です。**「直らない」ときに、それが故障なのか順番待ちなのかを見分けられること。順番待ちなら、待てば必ず来ます。`W-worker.ps1` や `D6-queue.ps1` で、いま誰が動いていて誰が待っているかが分かります。**焦って余計なことをしないための知識**だと思ってください。

だから、ガンガン当てていい

ここまでが今日の中身です。最後に、じゃあ何が嬉しいのかという話をします。 Azure Update Managerを使うと、WindowsもLinuxも、AzureのVMもオンプレのサーバーも、同じ1つの画面に並びます。メンテナンス時間を決めて定期適用もできるし、適用の前後に自分のスクリプトを挟むこともできる。オンプレ側はArcで繋ぐだけで、通信はアウトバウンドの443だけです。 課金は右のとおりです。Arcに繋ぐこと自体、拡張機能を配ること、Run Commandを流すことは全部無料。課金されるのはその上のサービスで、Update Managerが1台あたり月5ドル、マシン構成が月6ドル。どちらもAzure VMなら無料で、オンプレを混ぜた瞬間に有料になります。 そして下の行です。パッチを当てるのが怖いのは、壊れたときに戻せるか分からないからです。今日、**壊れても戻せる手順**ができました。だから先延ばしにしなくていい。当てないことのほうが、いまはリスクだと思います。 【画面・40秒】ポータル ＞ Azure Update Manager ＞［マシン］。**Azure VM とオンプレが同じ一覧に並ぶところ**が主役。開始前に流しておいた評価の結果も、ここで一緒に見せる。

そもそも再起動を減らす、という手もあります

もう1つ、ぜひ知っていただきたいことがあります。2026年5月19日から、Windows Server 2025のHotpatchが、Arc接続マシンで追加費用ゼロになりました。GAした2025年7月時点ではコアあたり月1.5ドルの有償でしたが、per-coreのメーターごと廃止されています。 再起動を減らせる選択肢が、オンプレの資産にタダで降りてきています。戻し方を持ったうえに、そもそも止める回数も減らせる。 【画面・20秒】Microsoft Community Hub の該当記事を開いて、費用の記述を指すだけ。時間が押していたらスライドのまま口頭で。

どこに何が記録され、何が動いているのか

今日の話を自分の環境で再現できるように、**どこを見ればいいのか**をまとめておきます。 実機で動いているサービスは3つです。`himds`（Azure Hybrid Instance Metadata Service）がArc本体で、ハートビートとトークンを担当します。`gcarcservice`（Guest Configuration Arc Service）が**マシン構成を評価しているサービス**、そして `ExtensionService`（Guest Configuration Extension Service）が拡張機能の配布と実行です。今日「エージェントを再起動する」と言っていたのは、真ん中の `gcarcservice` のことです。 ファイルはこうです。割り当ての実体は `C:\ProgramData\GuestConfig\Configuration\<割り当て名>\` にあって、同じ場所の `<名>.metaconfig.json` にモードと評価間隔が**設定値として**書いてあります。推定ではありません。ログは `arc_policy_logs\gc_agent.log` に評価の発火と開始・完了 ─ 順番待ちが見えるのはここ ─ 、`gc_worker.log` に Test か Set か、1件あたり何秒かかったかが出ます。Arcエージェント自身のログは `C:\ProgramData\AzureConnectedMachineAgent\Log\` の `himds.log` と `azcmagent.log` です。 今日叩いていたスクリプトは、Hyper-Vホスト（L1）の `C:\hccjp77\demo\` にある D0 から D8 と restart.ps1 です。PowerShell Direct で arcwin01 の中を読んでいるだけで、**特別なエージェントは何も入れていません**。スクリプトは GitHub に置いてあるので、そのまま持って行ってください ─ github.com/ebibibi/presentations/tree/main/HCCJP_77/scripts です。 【画面なし】スライドのまま。GitHubのURLは口で1回言えば十分。

だから、運用に入れていい

まとめます。巻き戻しても、Azure側の割り当ては消えません。戻ってくるのは実機の側だけです。ただし時計が3つあります。エージェントの15分、マシン構成の15分、そしてPolicyの24時間。この3つがズレているので、画面を見た瞬間の色は当てになりません。 そして5つの手順を手元に持っておけば、それだけで、怖さがただの作業に変わります。 Azure Update Manager、使っていきましょう。 【画面なし】スライドのまま話す。共有画面がポータルのままにならないよう注意。

ここまで全部、AIにやらせています

最後にもう1つだけ。今日お話しした検証、実はほとんど私が手を動かしていません。 割り当てと準拠状態を横断で取ってくるのも、「効かない」の原因をDSCリソースの中身まで降りて特定したのも、カスタムのポリシー定義を書いて当てて準拠を確認したのも、そして今日お見せした5つの手順書に起こしたのも、AIエージェントです。最初のスライドで言った「Azure側の入口がazコマンドに統一されている」というのは、こういうことです。手が届く形になっているので、そのまま任せられる。 ただし、正直に申し上げておきたいことがあります。**今日いちばんの学びは、前回の私が間違っていたことでした**。そもそも適用できていない構成を見て、「この機能は使えない」と結論していたんです。AIも、私も、実機で測るまでは間違えます。だから測りに行く。それが今日やったことです。 【画面なし】スライドのまま。ここは正直に、ゆっくり。ここで信頼を作る。

ありがとうございました（胡田セッション終了）

私のセッションはここまでです。ありがとうございました。質疑はこのあとまとめて受けます。 【画面なし】区切りの1枚。ここで一度息を継いで、高添さんへ渡す準備をする。

続いて ─ Microsoft "Adaptive Cloud" 最新動向

それではここからは高添さんに、Microsoft Adaptive Cloudの最新動向をお話しいただきます。高添さん、よろしくお願いします。

質疑応答

質疑応答の時間です。チャットにいただいた質問にお答えしていきます。 【画面】質問が出たら、該当するポータル画面へ戻って答えてよい。タブは開いたままにしておく。答えに詰まったら「そこは測っていません」と正直に言う（今日の趣旨に合う）。

【告知】10月3日、ITと音楽の文化祭やります

最後に個人的な告知をさせてください。10月3日の土曜日、千葉県南柏のライブバー「ケサラ」で、胡田昌彦のITと音楽の文化祭2026というイベントをやります。前半はIT勉強会、後半は東京事変のコピーバンドでライブをやります。私はバンドのメンバーでもあります。参加は無料、connpassで募集しています。ITと音楽、両方好きな方はぜひ遊びに来てください。 【画面・20秒】connpass のイベントページを開いて見せる。QRコードをスライドに出しているなら、読み取り時間として5秒静止する。

ありがとうございました

本日はご参加ありがとうございました。次回は10月9日、第2金曜日の14時からです。またお会いしましょう。 【画面】最後に hccjp.org（https://www.hccjp.org/）を開き、次回10月9日の枠と過去回アーカイブを見せてから配信を終える。 **配信終了後にやること**: arcwin01 を `T6-demo-ready` へ戻す（巻き戻したままにしない）。L1 の Hyper-V マネージャーで適用 → 起動、または L0 で `C:\hccjp77\9-restore.ps1`。

ありがとうございました！

締めの1枚です。質疑があればここで受けます。

Ebisuda Presentations のトップへ