💨

Mac/Windowsキッティング自動化の進め方 〜手動地獄からの脱出、その第一歩〜

に公開
テーマ「2025年の最も大きなチャレンジ」
Intune
Jamf Pro
Entra ID
tech

この記事はcorp-engr 情シスSlack（コーポレートエンジニア x 情シス） Advent Calendarの24日目の記事です。

はじめに

みなさん、キッティングしてますか？
情シスにとって、PCキッティングは「終わりのない戦い」です。入社者が増えれば増えるほど、その負荷は指数関数的に増大します。

今回は、私が過去の 「手動パソコンキッティング手順書30ページ超えの手動地獄」 から、どのようにして自動化・省力化を進めていったのか、その「自動化への進め方の第一歩」について、MacとWindowsそれぞれの実例を交えて書きたいと思います。

いきなりJamfやIntuneを完璧に使いこなすのではなく、まずは「どこから手を付けるべきか」という思考プロセスの共有になれば幸いです。

前提：かつての手動地獄

自動化の話をする前に、まずは「自動化前」の状態を供養させてください。
かつてのキッティング手順書は、総務部門から引き継いだ「秘伝のタレ」状態でした。

手動でアカウント作成、手動でプリンタドライバインストール、手動でChrome拡張機能を入れる、Chromeのブックマークを入れる、会社のWi-Fi のパスワードを入れる...

手順書には「ここでエンターキーを押す」「この画面が出たら5分待つ」といった職人芸が事細かに記されており、1台あたりのセットアップ時間は優に2〜3時間を超えていました。これを月何台もやるのは、まさに苦行です。

通常の月であればまだ良いのですが、年度末や4月の新入社員さんが入ってくるタイミングですと、月に20台を超えるパソコンをキッティングする必要があり、他にも業務があるため 「パソコンを家にお持ち帰りして、深夜3時までキッティング、そのまま出社して後続に引き渡し」 というデスマーチを行っていました。

キッティング自動化の3ステップ

私が進めた自動化のアプローチは、大きく分けて以下の3段階です。

  1. 標準化（Standardization）: 手順の棚卸しと断捨離
  2. 半自動化（Scripting）: コマンドラインによる省力化
  3. 全自動化（MDM/Zero Touch）: ゼロタッチデプロイへの移行

いきなり「3」を目指すと挫折します。まずは「1」と「2」で足元を固めることが重要でした。

Step 1: 標準化（手順の棚卸し）

自動化する前に、「何を設定しているのか」を明確にする必要があります。
旧手順書を読み解くと、以下のような「謎ルール」が大量に見つかりました。

  • 「マシン名は taro.suzuki にする」 → なぜ？固定資産番号やシリアル番号管理で良くない？
  • 「Siriは無効化する」 → 本当に必要？
  • 「Dockの配置を手動で直す」 → ユーザーに任せれば良くない？

ここで 「情シスが制御すべき必須項目」と「ユーザーに任せて良い項目（またはデフォルトで良い項目）」 を仕分けました。
これだけで、手順書の厚さは半分になります。

Step 2: 半自動化（スクリプト化）

MDM（Mobile Device Management）を入れる予算や準備が整う前でも、「GUIポチポチ」をやめることは可能です。これが自動化の第一歩です。

1. Wi-Fi設定の自動化（Mac）

毎回、会社のWi-Fiのパスワードを手入力するのは大変ですよね。
数台だけであればそこまで大変ではないですが、量が多いとタイピングゲームのようになってしまいます。
そこで、キッティング担当者は、ターミナルを開いて以下のコマンドを叩くだけにします。

networksetup -setairportnetwork en0 your_ssid xxxxxxxxxxxxxxx

2. アプリインストールの自動化（Mac）

Macのセットアップで最も時間がかかるのは「アプリのインストール」です。 1つずつ公式サイトからdmgファイルをダウンロードしてドラッグ＆ドロップ……なんてやっていられません。

そこで導入したのが Homebrew による管理です。 キッティング担当者は、ターミナルを開いて 「魔法の呪文（ワンライナー）」 を1行叩くだけ。これだけで、ChromeもSlackもNotionもOfficeも、勝手に入ります。

実際のキッティングで使っていたイメージ

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
brew install --cask google-chrome slack notion microsoft-office

これだけで、アプリインストールの工数が「30分」から「コマンド実行して放置」に変わりました。

3. Chrome管理の自動化（共通）

Chrome のブックマーク（お気に入り）を個別で登録するのは意外と時間がかかりませんか？ 全社で使うツールのブックマーク登録は、1個2個であればよいですが、複数あったりすると大変です。また、ツールが追加・廃止された際に管理者側で一括対応できず、ユーザーに変更を依頼しなくてはなりません。

そこで、 Chrome Enterprise Enrollment を利用し、会社管理型の Chrome ブラウザとして登録することで、ブックマークや拡張機能を遠隔で管理するようにしました。

Macの場合

touch CloudManagementEnrollmentToken
echo xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx > CloudManagementEnrollmentToken
sudo mv CloudManagementEnrollmentToken /Library/Google/Chrome/

Windowsの場合

Windowsも同様です。「Chromeへのポリシー適用」などは、GUIの設定画面を深く潜るのではなく、コマンドやレジストリで解決します。

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome" /v "CloudManagementEnrollmentToken" /t "REG_SZ" /d "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" /f

このように、「GUI操作をCUI（コマンド）に置き換える」 という作業が、後のMDM運用の基礎体力になります。

Step 2.5: 【重要】Microsoft アカウント(Entra ID)のドメインを変更

ここで一つTipsです。 Microsoft 365 は、初期ドメインとして @yourdomain.onmicrosoft.com が付与されます。 そのドメインをそのまま使うと、会社メールアドレスとMicrosoft アカウント(Entra ID)が別となるため、管理がとても難しくなります。

アカウント管理の意味でも、MDM移行にする前に会社ドメイン（カスタムドメイン）へ移行することをおすすめします。

Step 3: 全自動化（MDMへの移行）

Step 2で「何をコマンドで流せばいいか」が分かっていれば、MDMへの移行はスムーズです。スクリプトをMDMから配信すれば良いだけだからです。

Mac：Jamf Pro / ADE

現在は、AppleのADE (Automated Device Enrollment) と Jamf Proを組み合わせています。

旧: 箱を開ける → 初期設定 → コマンド叩く

新: 箱を開ける → Wi-Fi繋ぐ → Jamfが降りてきて勝手に設定完了

Step 2で作ったスクリプト類は、JamfのPolicyとして移植しました。

Windows：Intune / Autopilot

Windowsも同様に、IntuneとAutopilotを目指します。 手動で行っていた「Windows Updateの設定」や「BitLockerの有効化」は、Intuneの構成プロファイルに置き換わります。

特に効果が大きかったのはアカウント管理です。

旧: ローカルアカウント作成 → Azure AD（Entra ID）登録 → パスワードリセット

新: OOBE（初期セットアップ画面）でEntra IDの一時アクセスパス（TAP）でログイン → Intuneによる設定ファイルのダウンロード → WHfB (Windows Hello for Business) PIN のリセット

Entra IDの一時アクセスパス（TAP）

Windows の場合、Intune でセットアップするとしてもWindows Update など時間がかかる処理があるため、キッティングを行ってからお渡しします。 キッティングするにあたり、Entra ID の初期パスワードを使わず一時的に別のパスワードでログインする方法が、Entra IDの一時アクセスパス（TAP）となります。 これを行うことで、キッティング作業後のパスワードリセット忘れを防ぐことができます。

Windows Helloコンテナの削除

Entra IDで多要素認証の設定を強制している場合、事前キッティングを行う際も多要素認証の設定が必要です。手動で解除も可能ですが、コマンドラインで実施したほうがミスが少なくなります。

certutil -deletehellocontainer

これにより、「個人アカウントと職場アカウントが混在する問題」や「引き渡し用の一時パスワード管理」から解放されました。

自動化を進める上でのポイント

最後に、これからキッティング自動化を進める方へのアドバイスをまとめます。

  • 「減らす」ことから始める
    • 自動化スクリプトを書く前に、その設定が本当に必要か疑ってください。何もしないのが一番のコスト削減です。
  • 「引き継ぎ手順書」をスクリプトにする
    • 手順書を更新する暇があったら、その手順をスクリプト化しましょう。手順書は陳腐化しますが、コードは動きます。
  • 小さく始める
    • いきなりゼロタッチを目指さなくて良いです。まずは「Chromeのインストールだけ自動化する」でも立派な進歩です。

終わりに

キッティングの自動化は、単に「楽をする」ためだけではありません。 「誰がやっても同じ品質（Security & Configuration）の状態を作り出す」 ことこそが、エンジニアリングの本質だと思います。

かつて手動で30ページの手順書と格闘していた日々を思うと、今の環境は天国です（それでもトラブルはありますが……）。 作業時間も1/3 ~ 1/6 程度に減少し、パソコンの故障があっても在庫があればすぐに対応できましたし、他の人への引き継ぎもスムーズになりました。

この記事が、手動キッティングと戦う誰かの「最初の一歩」のきっかけになれば幸いです。

それでは、良いお年を！

Discussion