はじめに こんにちは、コーポレートエンジニアリング部ITサービスブロックの高塩です。2026年2月に入社し、社内の共通システムやIdP、SaaSの管理、日々のオペレーション自動化などを担当しています。 ZOZOでは入社者のマスタデータをkintoneで管理しています。入社のたびに、Active Directory（以下、AD）を起点にMicrosoft 365・Google Workspace・Boxなどでアカウントを作成し、利用できる状態まで整えています。この作業は長らく手作業で運用してきましたが、工数や属人化、そしてCSVの受け渡しに課題を抱えていました。 オンプレADやLDAPサーバーを長く運用してきた組織では、それが自動化の足枷になっているケースも少なくないと思います。かといって、すべてをクラウドへすぐに寄せられるとも限りません。本記事では、この一連のアカウント作成を、kintoneを起点にGitHub Actions（self-hosted runner）で自動化した取り組みを紹介します。閉域にあるオンプレADの操作までGitHub Actionsに載せ、コードレビュー・実行ログ・再現性といったCI/CDの利点をアカウント運用に持ち込みました。 目次 はじめに 目次 背景：手作業時代のフローと課題 全体アーキテクチャ オンプレADをGitHub Actionsから操作する kintoneから翌月の入社予定者を取得し、業務ロジックで判定してADに作成する 同期待ちを能動的に潰して即時反映する AD → Entra ID：デルタ同期を要求して完了までポーリング Entra ID → SaaS：Graph APIのオンデマンドプロビジョニング 運用：前日にdry-runで予定を流し、翌日に本番で作成する 導入の効果 まとめ 背景：手作業時代のフローと課題 自動化前のアカウント作成は、おおよそ次のような流れでした。 GASでkintoneから入社者のレコードを取得する スプレッドシートに転記し、関数で表示名やグループなどの値を加工する 加工した結果をCSVでエクスポートし、オンプレミスの作業サーバーへ手動で転送する 作業サーバー上で複数のPowerShellスクリプトにCSVを読み込ませ、順次実行してアカウントを作成する 途中、Microsoft Entra Connectのデルタ同期を手動で実行し、各SaaSへの反映を待つ 反映後、各SaaSの個別設定を、設定用スクリプトの実行や手作業で投入する 一見すると回っているように見えますが、運用を続けるうちに次のような課題が積み重なっていました。 業務ロジックが散在している ：誰が・どの雇用形態で・どのグループに入るのか、その判断ロジックがスプレッドシートの関数と作業サーバー上のスクリプトに分散していました。そのため全体像の把握が困難でした。 手作業でのCSV転送 ：スプレッドシートからCSVをエクスポートし、作業サーバーへ人手で転送していました。 ログの視認性が低い ：実行は作業サーバーのコンソールで行うため、いつ・誰が・何を流したのかが後から追いにくい状態でした。 スクリプトのドリフト ：Gitリポジトリ上のスクリプトと、作業サーバーに置かれた実際に動くスクリプトが少しずつ乖離していき、「リポジトリのコード＝実際に動いているコード」と言い切れなくなっていました。 これらをまとめて解決するために、フロー全体を作り直すことにしました。 全体アーキテクチャ 新しい仕組みでは、データはkintoneから直接取り、全工程をGitHub Actionsから動かすことにしました。 手作業のころから大きく変えたのは、次の3つです。 CSVの受け渡しをやめ、kintone APIを直接呼び出す ：人の手によるエクスポートと加工を排除しました。 散在していた業務ロジックをコードに集約する ：判断ロジックをすべてPowerShellスクリプトにまとめ、Gitリポジトリで管理するようにしました。 オンプレADの操作にself-hosted runnerを使う ：GitHub Actionsの仕組みに乗りながら、オンプレミスのADコマンドレットをそのまま実行できるようにしました。 ワークフローは schedule によるcron実行で動きます。kintoneからはデフォルトで翌月の入社者を取得するので、毎月決まった日に翌月分の作成予定をSlackへ自動投稿し、その翌日にまとめて作成する、という運用にしました。 ここからは、土台となるself-hosted runner、kintoneからのアカウント作成、クラウドへの即時反映を、順に見ていきます。 オンプレADをGitHub Actionsから操作する この仕組みで一番頭を悩ませたのが、オンプレミスのADをどう自動化に組み込むかでした。 ADはオンプレミスの閉じたネットワークの中にあります。操作するには、次の3つが必要です。 ドメインコントローラへ通信できるネットワーク（オンプレ内）にいること リモート サーバー管理ツール（ RSAT ）の ActiveDirectory モジュールが入った実行環境 対象OUでユーザー作成とグループ追加ができるドメイン権限 最初に検討したのは、この処理を自前でオーケストレーションせず、Entra ID Governanceのようなマネージド機能に寄せる形でした。たとえばオンプレADへのユーザー作成は、 API 駆動型インバウンド プロビジョニング に任せられます。 ただ、今回の要件には合いませんでした。アカウント作成にはオンプレADのグループ操作が含まれますが、属性ベースの動的グループが扱うのはクラウドのグループで、オンプレADのグループメンバーシップまでは管理しません。ここはマネージド機能だけでは実現できません。 さらに、出し分けの業務ロジックは、手作業時代のPowerShellスクリプトへある程度作り込まれていました。これを一から組み直すより、既存の資産をそのまま流用したい事情もありました。そこで今回は、自前でオーケストレーションする方針にしました。 自前で組むなら、ADを操作する方法はいくつかあります。検討した選択肢の長所と短所を、次の表にまとめました。 実行方式 長所 短所・見送り理由 タスクスケジューラ＋スクリプト 追加インフラが不要 時刻起動のみ・コードがサーバーに残りドリフト再発・ログやSecrets、レビューが弱い 自前でAPIを建てる オンデマンド実行・自由度が高い 着信ポートの開放が必要・認証や可用性、監視を自前運用 Azure Automation（Hybrid Runbook Worker） Power Automate/Microsoft Formsから起動しやすい・Azure/M365中心の組織に馴染む GitのPR/CIと一体化しにくい・別基盤の学習/運用コスト self-hosted runner（採用） 既存のGitHub・PR・CIにそのまま乗る・チェックアウトでドリフトなし・手動/定期の両対応 runnerの保守が必要・信頼できるコードのみ実行する配慮が要る 自前API以外の3方式は、オンプレからのアウトバウンド通信だけで動作し、外部に着信ポートを開ける必要がありません。 最終的に self-hosted runner を選びました。ADドメインに参加したWindows Server上でrunnerを動かし、PowerShellを実行しています。 コード・トリガー・ログがすべてGitHub側へ移り、サーバー上では実行時にチェックアウトされた最新のスクリプトが動くだけです。背景で挙げたドリフトは、これで自然に消えます。 ほぼ同じ仕組みは、AzureのHybrid Runbook Workerでも実現できます。私たちはGitHubを使った業務フローが根付いていたため、self-hosted runnerを選びました。 ただし、この構成では強い権限を持つrunner自体が攻撃対象になります。runnerを侵害させないことと、万一侵害されても被害を広げないことの両方に注意を払う必要があります。 runnerに任意のコードを実行させる入口はGitHubなので、次のような基本的な制御を入れています。 リポジトリをprivateにし、権限は必要なメンバーだけに限定する ログインはSSOを必須とし、MFAの登録を義務づける mainはbranch protection ruleでCODEOWNERのレビュー承認を必須にする 認証は原則OIDC（Workload Identity連携）を使い、やむを得ずシークレットを使う場合もEnvironmentシークレットに置いてmainのワークフローからのみ参照できるようにする self-hosted runnerのサービスを動かすアカウントに過剰な権限を与えないことも重要です。runnerはオンプレADからクラウドまで触れる強い実行主体なので、万一侵害されたときの影響範囲を抑えるため、アクセスできるOUを絞るなど、必要最低限の権限だけを与えています。 kintoneから翌月の入社予定者を取得し、業務ロジックで判定してADに作成する 土台ができたら、次はアカウントを作る処理です。 まず取得です。kintoneの Cursor API を使い、クエリで対象者を絞り込みます。条件は3つで、入社月・入社区分（中途や新卒など）・雇用形態（社員やアルバイトなど）です。対象月は、定期実行では NEXT_MONTH() で翌月分を自動的に対象にします。 # 入社区分・雇用形態・入社月で対象者を絞り込む $categoryFilter = 'Category in ("中途", "新卒", "社員登用", ...)' $contractFilter = 'Contract in ("社員", "出向", "CSアルバイト", ...)' $query = " $categoryFilter and $contractFilter and Date = NEXT_MONTH() order by Date desc" # カーソルを作成し、レコードを取得し切るまで繰り返す $cursorId = ( Invoke-RestMethod -Uri $cursorEndpoint -Method Post -Headers $headers -Body $utf8Body ).id $nextCursorId = $cursorId while ( $nextCursorId ) { $res = Invoke-RestMethod -Uri " $cursorEndpoint `? id= $nextCursorId " -Method Get -Headers $getHeaders $allRecords += $res .records $nextCursorId = $res .next } CSVのエクスポートと手動転送がなくなり、「どんな条件で対象者を抽出しているか」がクエリを見れば分かるようになりました。 ただ、取得したデータをそのままADに流し込めるわけではありません。雇用形態や所属によって、どのOUに作り、どのグループに入れるかが変わります。以前はこの出し分けがスプレッドシートの関数に埋もれていましたが、今回コード側の分岐に移しました。判定しているのは、たとえば次のような内容です。 雇用形態に応じた、アカウントの配置先OUの決定 所属に応じた、各種グループへの追加 その他のユーザーアカウント属性の設定 判定が終わったら、self-hosted runnerの上で ActiveDirectory モジュールのコマンドレットを実行し、ADにアカウントを作成します。あとは次に述べる同期で、クラウド側へ反映されていきます。 同期待ちを能動的に潰して即時反映する ADにユーザーを作っただけでは、クラウド側のアカウントはすぐには使えません。間に2つの同期が挟まるためです。 1つ目はAD → Entra IDです。オンプレADのユーザーは、Microsoft Entra Connectが同期して初めてEntra ID側に現れます。この同期は通常、30分間隔のサイクルでしか走りません。 2つ目はEntra ID → 各SaaSです。Entra IDからGoogle WorkspaceやBoxへは、エンタープライズアプリのプロビジョニングで連携されます。この自動プロビジョニングのサイクルは最大40分待つことがあります。 手作業のころは、この待ちを人がこなしていました。同期サイクルが回るのを待つか、待ちきれなければデルタ同期を手動で叩き、クラウドにアカウントが現れたのを確認してから次の設定に進む、という具合です。 ところが、これをそのまま自動化に持ち込むと厄介でした。AD作成の先には、Entra IDのライセンスやグループ設定、Google WorkspaceやBoxへのプロビジョニング、その後の各SaaS個別の設定が続きます。どれも前の結果を前提にした処理です。定期サイクル任せだと全部終わるまでに1時間近くかかるうえ、まだ存在しないアカウントを触って空振りするステップも出てきます。 そこで、2つの同期をワークフローから自分でトリガーし、完了を見届けてから次へ進むようにしました。 AD → Entra ID：デルタ同期を要求して完了までポーリング 1つ目の同期は、Microsoft Entra Connectの同期サーバーに対してデルタ同期を要求し、完了するまで待ちます。runnerから Invoke-Command で同期サーバーに入り、 Start-ADSyncSyncCycle でデルタ同期を開始したあと、同期が進行中でなくなるまでポーリングします。 Invoke-Command -ComputerName $syncServer -ScriptBlock { Import-Module ADSync Start-ADSyncSyncCycle -PolicyType Delta | Out-Null # 同期が完了するまで待つ do { Start-Sleep -Seconds 10 $inProgress = ( Get-ADSyncScheduler ).SyncCycleInProgress } while ( $inProgress ) } ポーリングで完了を待つので、後続の処理に進む時点では、新入社員が必ずEntra ID側に存在します。 この Invoke-Command によるPowerShell Remotingは、runnerが侵害されたときに同期サーバーへの横移動の足がかりになりかねません。そこで、同期サーバーへ接続できる元をrunnerに限定し、接続に使うアカウントの権限も同期の実行に必要な分だけに絞っています。 Entra ID → SaaS：Graph APIのオンデマンドプロビジョニング 2つ目の同期は、Entra IDの自動プロビジョニングのサイクルを待たず、Graph APIの provisionOnDemand を使ってユーザー単位で即座にプロビジョニングをトリガーします。 このリクエストには、対象アプリのサービスプリンシパルID（ $spId ）・同期ジョブID（ $jobId ）・同期ルールID（ $ruleId ）の3つが必要です。ただ、こちらで用意するのは1つ目だけです。 $spId はエンタープライズアプリの「オブジェクトID」で、Entra管理センターのアプリのプロパティ画面に表示されます。 残りの $jobId と $ruleId は、実行時に $spId からGraphで取得します。ユーザーの同期ルールはアプリごとに1つしかないので、同期ジョブのスキーマを覗けば、それがそのまま使うルールです。IDを手で管理する必要はありません。 # $spId から同期ジョブを取得（Quarantine以外を優先） $jobs = Invoke-MgGraphRequest -Method GET ` -Uri "https://graph.microsoft.com/v1.0/servicePrincipals/ $spId /synchronization/jobs" $jobId = ( $jobs .value | Where-Object { $_ .status.code -ne "Quarantine" } | Select-Object -First 1 ).id # ジョブのスキーマから、ユーザーが対象の同期ルールを選ぶ $schema = Invoke-MgGraphRequest -Method GET ` -Uri "https://graph.microsoft.com/v1.0/servicePrincipals/ $spId /synchronization/jobs/ $jobId /schema" $ruleId = ( $schema .synchronizationRules | Where-Object { $_ .objectMappings.sourceObjectName -contains "User" } | Select-Object -First 1 ).id あとは、取得した $jobId と $ruleId 、そしてプロビジョニング対象のユーザーを指定してリクエストを投げます。 $body = @{ parameters = @( @{ ruleId = $ruleId subjects = @(@{ objectId = $userObjectId ; objectTypeName = "User" }) } ) } Invoke-MgGraphRequest -Method POST ` -Uri "https://graph.microsoft.com/v1.0/servicePrincipals/ $spId /synchronization/jobs/ $jobId /provisionOnDemand" ` -Body ( $body | ConvertTo-Json -Depth 10 ) ` -ContentType "application/json" この2つで同期待ちを潰すと、AD作成・各SaaSへのプロビジョニング・その後のSaaSごとの設定までが一本につながります。プロビジョニングのサイクルを待たずに済むので、後続の設定も同じ実行の中で流し込めます。終わった時点で、結果がSlackとジョブログに残ります。 運用：前日にdry-runで予定を流し、翌日に本番で作成する 毎月の作成は、dry-runと本番の2段階で回しています。 前日に走るのはdry-runです。AD作成やプロビジョニングといった変更は実際には行わず、「何をするか」（翌月入社者の作成予定）をSlackに流します。チームはこの通知で対象者を確認できるので、kintoneのデータに不備があっても、本番の前に気づけます。 翌日に本番が走ります。処理の開始から各ステップ、完了までを1本のSlackスレッドに流し、完了サマリーと、失敗したときのエラーだけはチャンネルにもブロードキャストして気づけるようにしています。作業サーバーのコンソールを覗かなくても、SlackとGitHub Actionsのログだけで実行状況を追えます。手作業時代に困っていた「ログの視認性の低さ」は、これで解消しました。 もう1つ効いているのが冪等性です。アカウント作成は既存ユーザーをスキップし、グループ追加も「すでにメンバー」を無視します。途中のステップが失敗しても、直して同じワークフローを流し直せば、できているところはそのまま、足りないところだけが埋まります。 また、プロビジョニングの後に各SaaSで行う個別の設定は、SaaS側の状態によっては失敗することがあります。これらは失敗しても全体を止めず、結果をSlackに残して先へ進む設定にしています。気づいたら、その部分だけ後で流し直せば済みます。 導入の効果 一番大きいのは、毎月の新入社員アカウント作成がほぼ無人で回るようになったことです。これまで人がCSVを受け渡し、スクリプトを手で実行し、同期を待っていた一連の作業が、1回のワークフロー実行にまとまりました。 業務ロジックもコードに集まり、「どの条件で何が付与されるか」をリポジトリで追えます。リポジトリのコードと実際に動くコードが一致するので、ドリフトも起きません。 まとめ 本記事では、新入社員のアカウント作成を、kintoneを起点にGitHub Actionsで自動化した取り組みを紹介しました。オンプレADの操作はself-hosted runnerで担い、散らばっていた業務ロジックはコードにまとめ、同期待ちはGraph APIのオンデマンドプロビジョニングで潰しました。手作業で属人化していた運用を、コード化して実行を追える形にできました。 オンプレミスとクラウドが混在する環境でアカウント運用を自動化したい方の参考になれば幸いです。今後は、退職時のアカウント無効化など、入社から退職までのライフサイクル全体へ自動化を広げていく予定です。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

2026 年 7 月 6 日に公開された “ Announcing support for VCF 9.0 and 9.1 on Amazon EVS ” を翻訳したものです。 VMware Cloud Foundation (VCF) 9.0 および 9.1 が Amazon Elastic VMware Service (EVS) で利用可能になり、VCF インストールを完全に制御できるようになったことをお知らせいたします。Amazon EVS における私たちの焦点は、お客様が現在お持ちのツール、運用プロセス、スキルを使用して、ニーズに合わせて VCF をデプロイおよび構成できる柔軟性を提供することです。 Amazon EVS での VCF 9 エクスペリエンス VCF 9.x では、AWS インフラストラクチャのプロビジョニングを VCF ソフトウェアから分離します。Amazon EVS は、ESX 9.x を実行する EC2 ベアメタルインスタンスをお客様の Amazon Virtual Private Cloud (VPC) にデプロイし、VCF デプロイメントのアンダーレイとして機能するプライベート VLAN に接続します。そこから、Broadcom の VCF Installer をダウンロードしてデプロイし、Broadcom のネイティブワークフローを使用して VCF インストールを完了します。 評価モードでの VCF 9.x のデプロイ VCF 9.x を有効化する一環として、Amazon EVS は VCF 評価モードをサポートするようになりました。ライセンスキーを事前に提供することなく、EVS 環境を作成して VCF のデプロイを開始できます。これにより、サブスクリプションを適用してワークロードの移行を開始する前に、環境を構築し、設計を検証し、実装をテストする余地が生まれます。評価モードを超えて使用する際には、適切な VCF サブスクリプションカバレッジを維持する責任はお客様にあります。 Solutions for EVS GitHub リポジトリ エンドツーエンドのデプロイをより簡単にするため、開始を支援するサンプル、テンプレート、Infrastructure as Code アーティファクトを含む新しい Solutions for EVS GitHub リポジトリ を公開します。今後、このリポジトリを拡張し、追加のリファレンスアーキテクチャ、新しいベアメタルインスタンスおよびストレージ構成、ネイティブ AWS サービス統合を含める予定です。AWS CloudFormation や HashiCorp Terraform などの Infrastructure as Code ツールを使用している場合、これらのアーティファクトを、AWS インフラストラクチャから稼働中の VCF 環境までの経路を自動化するための基盤として使用できます。 EVS コネクタを使用した VCF の接続 VCF がインストールされ、VCF 管理アプライアンスに到達可能になったら、2026 年 4 月に Windows Server ライセンス機能 で初めて導入した EVS コネクタ を使用して、VCF デプロイメントを Amazon EVS コントロールプレーンに接続します。コネクタは、AWS Secrets Manager に保存された認証情報を使用して、EVS から VCF 管理アプライアンスへの永続的で認証された接続です。この接続により、EVS はお客様のデプロイメントを継続的に把握し、VCF ソフトウェアの運用上に介在することなく、環境状態の監視、Windows ライセンスエンタイトルメントの有効化、ライセンス使用状況のレポートを可能にします。 クラウドへのファーストパス 多くのお客様にとって、Amazon EVS はクラウドへ移行する最も高速な方法の 1 つであり、特にデータセンター契約の満了やインフラストラクチャの更新サイクルといった時間的制約に直面している場合に有効です。 Aeroméxico のようなお客様は、最大のメリットは VMware ワークロードを AWS へいかに迅速かつ容易に移行できるかにあると語っています。オンプレミスと同じように VCF をデプロイ、構成、運用することで、ソース環境とデスティネーション環境のアーキテクチャ上の差異を最小限に抑え、大規模な移行を簡素化・加速できます。 速度と制御の組み合わせこそが、今回のリリースの本質です。Amazon EVS 上の VCF 9.x は、最新の VMware Cloud Foundation ソフトウェアを現在と同じ方法で実行できる能力を提供しながら、AWS グローバルインフラストラクチャのスケールと信頼性を兼ね備えています。組織で VMware を使用している場合、私たちは Amazon EVS が VMware ベースのワークロードを実行する世界最高の場所となることを目指しています。 Amazon EVS の詳細については、 製品詳細ページ および ユーザーガイド をご覧ください。 著者について Andy Reedy Andy Reedy は EC2 Commercial Applications のシニアプロダクトマネジメントマネージャーで、VMware、SAP、Red Hat OpenShift ワークロードに注力するチームを率いています。IT インフラストラクチャ、ネットワーキング、セキュリティ、クラウド戦略、エンタープライズソフトウェアにおいて 25 年以上の経験を持ち、お客様のビジネスクリティカルなアプリケーションの移行とモダナイゼーションを支援することに情熱を注いでいます。 Spiros Tsitsonis Spiros Tsitsonis は AWS のシニアテクニカルプロダクトマネージャーで、インフラストラクチャ移行と Amazon Elastic VMware Service に注力しています。以前は Amazon Elastic Container Service とサーバーレスの Fargate チームを管理しており、AWS サービスを使用してお客様がビジネス成果を達成できるよう支援することに情熱を注いでいます。休日は、旅行やさまざまな場所、人々、文化を体験することを楽しんでいます。 翻訳はソリューションアーキテクト齋藤が担当しました。原文は こちら です。

G-gen の今村です。当記事では、Google Cloud（旧称 GCP）の仮想マシンサービスである Compute Engine で Windows Server VM を起動し、リモートデスクトップでログインするまでの手順について解説します。 はじめに VM の起動 新規 VM の設定画面へ遷移 VM の設定 概要 マシンの構成 OS とストレージ データの保護 ネットワーキング オブザーバビリティ セキュリティ 詳細 設定を確認して作成 管理者アカウントとパスワード 初期パスワードの発行 初期パスワードの変更 リモートデスクトップ接続の設定 ファイアウォールルールの構成 RDP での接続確認 接続経路の保護 その他の設定と Tips Windows Server の日本語設定 Windows Server のライセンス費用 はじめに Compute Engine の基本的な概念や操作方法、およびマシンタイプやネットワークなどのその他設定については、以下の記事を参照してください。当記事では Windows Server 固有の手順に絞って解説します。 blog.g-gen.co.jp blog.g-gen.co.jp VM の起動 新規 VM の設定画面へ遷移 Google Cloud コンソール上部の検索窓で「Compute Engine」を検索し、「VM インスタンス」をクリックします。 次に、遷移した先で「インスタンスを作成」をクリックします。 Compute Engine を検索 インスタンスを作成 インスタンスの作成には、Compute インスタンス管理者（v1）（ roles/compute.instanceAdmin.v1 ）の IAM 権限が必要です。作業するユーザーに対して、当該のロールが付与されていることを確認してください。 IAM については以下の記事を参照してください。 blog.g-gen.co.jp VM の設定 概要 VM インスタンスの設定画面は大きく、マシンの構成、OS とストレージ、データ保護、ネットワーキング、オブザーバビリティ、セキュリティ、詳細の7セクションに分かれています。 当記事では、それぞれのセクション内での設定項目については詳細な説明を割愛します。細かい設定や推奨される利用方法など、公式ドキュメントを参照しながら利用要件に合わせて適切な設定を行ってください。 なお、設定項目及び UI は2026年6月現在のものであり、当記事で解説する内容は変更される可能性がある点に留意してください。 マシンの構成 リージョンやゾーン、マシンタイプ等を設定します。 マシンの構成セクション OS とストレージ 使用する OS やディスクサイズを設定します。 OS とストレージセクション デフォルトでは Windows 以外の OS が選択されているため、以下の手順で「Windows Server」に切り替えます。使用するバージョンは、利用要件に合わせて適切なものを選択してください。 オペレーティングシステムを変更 Windows Server を選択 バージョンを選択 選択をクリック データの保護 バックアップのスケジュールやレプリケーションの設定を行います。 データの保護セクション ネットワーキング ファイアウォールルールや使用するネットワークを個別に設定できます。ただし、本来ネットワーク関連の権限を持たないユーザーが、個別のネットワーク設定を行えることはセキュリティ上の懸念となります。 そのため、通信を許可するファイアウォールルール等の設定は、後述の Virtual Private Cloud（以下、VPC）で一元的な管理を行うことが推奨されます。 ネットワーキングセクション オブザーバビリティ ログや指標の収集、アプリケーション監視についての設定を行います。 オブザーバビリティセクション セキュリティ アタッチするサービスアカウントや VM の保護設定等を行います。 デフォルトのサービスアカウントには、編集者（ roles/editor ）という強力な権限が付与されています。セキュリティリスクを回避するため、必要なロールのみに絞ったサービスアカウントをアタッチすることが推奨されます。 セキュリティセクション Compute Engine にアタッチするサービスアカウントの考え方については、以下の記事を参照してください。 blog.g-gen.co.jp 詳細 VM を削除から保護する設定や起動スクリプト、メタデータの設定を行います。 詳細セクション 設定を確認して作成 セクション内の項目を一通り確認し、要件通りの設定になっているか、エラーがないか、などをチェックします。確認が終わったら画面下部の「作成」ボタンをクリックして、VM の作成処理を開始します。VM が完全に起動して接続可能になるまでは数分ほどかかります。 作成 管理者アカウントとパスワード 初期パスワードの発行 Windows Server インスタンスの作成が完了した直後は、OS にログインするための管理者アカウント（Administrator）やパスワードが用意されていません。 ログインするためには、Google Cloud コンソールの VM インスタンス詳細画面から「Windows パスワードを設定」を実行する必要があります。この操作を行うことで、指定したユーザー名のアカウントが作成され、ランダムな初期パスワードが生成されて画面に表示されます。なお、VM の起動命令を出した直後はこの操作が行えない場合があります。数分後に再度、実施してください。 このパスワードは一度画面を閉じると再確認できないため、必ず安全な場所に控えてください。 参考 : Windows VM のアカウントと認証情報を管理する - 認証情報を生成する VM 編集画面 ユーザー名を設定 自動でパスワードが生成される 初期パスワードの変更 Google Cloud コンソールで生成した初期パスワードも強力ですが、会社としてセキュリティガバナンスを定めている場合、その規定に沿ったパスワードへの変更を推奨します。ログイン後は Windows の管理機能を使用して変更できます。 参考 : Windows VM のアカウントと認証情報を管理する - パスワードを変更する リモートデスクトップ接続の設定 ファイアウォールルールの構成 Windows Server へログインするには、リモートデスクトッププロトコル（以下、RDP）を使用します。 RDP 接続を許可するために、対象の VPC ネットワークでポート番号「3389」（TCP）のインバウンド通信を許可するファイアウォールルールを追加してください。セキュリティリスクを低減するため、送信元 IP アドレス範囲はすべての通信（ 0.0.0.0/0 ）とはせず、接続元のオフィスや環境のグローバル IP アドレスのみに制限することを強く推奨します。 VPC ネットワークやファイアウォールルールの詳細については、以下の記事を参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp RDP での接続確認 ファイアウォールルールの設定が完了したら、ローカル PC の RDP クライアントを起動します。 接続先として VM インスタンスの外部 IP アドレスを指定し、先ほど発行したユーザー名とパスワードを入力することで、Windows Server へログインできます。 操作方法や UI は、使用する RDP クライアントアプリケーションにより異なる点に留意してください。 RDP クライアントアプリケーションでアカウントを追加 RDP クライアントアプリケーションで Windows Server に接続 参考 : RDP を使用して Windows VM に接続する 接続経路の保護 前述のように、ファイアウォールルールによって外部からの RDP 接続を特定の IP アドレスに制限することは有効なアプローチであり、Google Cloud から非推奨とされているわけではありません。 しかし、インターネット経由の直接接続よりもさらにセキュリティを高めたい場合は、Identity-Aware Proxy（以下、IAP）という機能を使用して、よりセキュアな RDP 接続を構成できます。IAP の詳細や、RDP で利用する方法については、以下の記事を参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp また、Cloud VPN を経由することで、自組織のネットワークと VPC ネットワークを接続し、内部 IP アドレスを使ったプライベート接続を確立することもできます。Cloud VPN については、以下の記事を参照してください。 blog.g-gen.co.jp 参考 : Identity-Aware Proxy の概要 参考 : Cloud VPN の概要 その他の設定と Tips Windows Server の日本語設定 起動した Windows Server のデフォルトの言語設定は英語となっています。言語設定を英語のまま運用した場合、導入したアプリケーションによっては文字化けや不整合が発生する可能性がある点に留意してください。 こうした意図しない挙動を防ぐため、Windows Server を日本語設定に変更する必要があります。Windows Server の日本語化手順については、以下の記事を参照してください。 blog.g-gen.co.jp Windows Server のライセンス費用 当記事の手順は、 プレミアムイメージ と呼ばれる、Google が用意したライセンス埋め込み型のイメージから Windows Server を起動する手順です。この場合、ライセンス費用は VM インスタンスの利用料金に含まれ、時間単位で課金されます。ライセンス費用は、VM インスタンスに割り当てられた vCPU 数に応じて変動します。 なお既に自組織で Windows Server の OS ライセンスを所有している場合は、ライセンスの持ち込み（BYOL）が可能な 単一テナントノード を使用することもできます。大規模かつ長期の運用では独自のライセンスを使用することで費用を削減できる可能性がありますが、単一テナントノードの追加費用が発生します。また、ライセンスの持ち込み条件などについては、公式ドキュメントを十分に確認してください。 参考 : Google Cloud での Microsoft ライセンス 今村 壱生 (記事一覧) クラウドソリューション部 ソリューションアーキテクト課 2026年3月にG-genへ入社。約7年間 Web 広告運用やウェブ解析に携わり、その後は社内 SE として開発業務に従事。広告運用の現場感と技術的な視点、その双方を併せ持つ経験をベースに、現在は Google Cloud のスキルアップに注力。データ活用とクラウド技術を融合させ、お客様のビジネス成長を支えるエンジニアを目指している。 Follow