PR駆動の変更、CI/CDでOS設定を自動反映 — Terraformで実現するJamf ProのIaC＋GitOps基盤

こんにちは。メルカリのセキュリティエンジニアの@yuです。

この記事は、Mercari Advent Calendar 2025 の20日目の記事です。

従業員の業務端末 (MacBook) に利用しているデバイス管理ツールである Jamf Pro の構成管理に Terraform を活用し始めた際の所見について紹介します。

概要

Jamf Pro の構成変更は、macOS, iOS デバイス管理の改善に欠かせません。一方で、変更が手作業中心だと、レビューが重くなったり、作業ミスの余地が残ったり、変更の根拠や履歴が散らばったりしがちです。特にセキュリティの観点では「何時、誰が、何故、どのようなプロセスで、何を変更できるのか」のような 5W1H を明確にし続けることが重要になります。

そこで本記事では、Open Source Community が開発・保守している Terraform provider (※)を用いて Jamf Pro のリソースを IaC (Infrastructure as Code:コードとしてのインフラストラクチャ)化し、さらに GitHub 上の PR (Pull request:プルリクエスト) を起点に terraform plan をレビューしてから terraform apply を実行する、PR 駆動の GitOps フローへ移行した取り組みを紹介します。

※: https://registry.terraform.io/providers/deploymenttheory/jamfpro/latest/docs

この手法自体は主要なクラウドサービスの構成管理では一般的な手法ではありますが、本件の様なデバイス管理ツール上での適用については例が少ないのが現状です。本記事では、この試みをいかにして実現したのかを紹介します。

この仕組みによって、変更内容はコード差分と plan 出力として事前に確認できるようになり、適用は自動化されます。結果として「手順書ベースのレビューや手作業変更」から、「差分と plan を一次情報としてレビューし、承認後に安全に反映する」形へ移行できました。

背景：なぜ“セキュアな変更管理”が必要だったのか

もともと Jamf Pro の変更は、手順書に沿った手作業が中心でした。この方法は丁寧に運用すれば回りますが、変更のたびに設計から実装までのリードタイムが伸びやすく、オペミスの余地も残ります。また、Jamf Pro のリソースによっては変更履歴が十分に追えず、申請フローと実際の変更を機械的に突合できない、といった課題もありました。さらに、従来の申請フローでは「何をどう変えるか」が自然言語やスクリーンショットで記述されることが多く、変更内容が曖昧になりやすいという問題もありました。申請者・承認者・作業者の間で解釈が分かれた結果、意図と異なる設定変更やレビュー漏れが起きる余地が残ります。

（こちらの課題の一例については昨年の mSCPとJamf Pro APIによるmacOSセキュリティ設定の手動IaC化の試行 | メルカリエンジニアリング も併せてご参照下さい）

さらに運用が進むにつれて、リソースの所管や背景（なぜこの設定が必要か）が 変更管理ツール、Slack や Notion、Google Docs などに散在し、後から辿るコストが増えていきます。結果として、定常メンテナンスのために高い操作権限を人に付与し続ける必要が出やすく、攻撃面管理の観点でも悩ましい状態になりがちです。一方で、私たちはお客さま向けのプロダクト環境へ設定しているものと同じ高いセキュリティ及び管理基準を当社のコーポレート環境に対しても適用したいと考えております。

この状況を改善するために、私たちは Jamf Pro の変更を「コード化」し、「PR とレビューのプロセスに載せる」、そして「承認後に自動適用する」構造へ切り替えました。以降の章では、この GitOps フローをどう設計し、どのように権限分離・承認・変更範囲のコントロールを実現したかを中心に説明します。

コードオーナーで「変更範囲」と「承認責務」を結びつける

GitOps では、構成変更の入口が PR になります。つまり、レビューと承認の設計が、そのまま変更管理の統制になります。Jamf Pro のように、設定変更が端末群に広く影響し得る仕組みでは、誰がどの範囲を見て、どの基準で承認するかを、運用ルールだけでなく“仕組み” に落とすことが重要です。

そこで有効なのが コードオーナー (Code Owner) です。コードオーナーを使うと、特定のディレクトリやファイルに変更が入った際に、指定したロール（チーム）がレビューに入ることを、リポジトリのルールとして強制できます。これにより「所管が曖昧」「気づいた人が見る」状態から、「この範囲はこのロールが責任を持つ」状態へ寄せられます。

※: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners

（掲載例）

CODEOWNERS (example)

Policies: local admin management

/terraform/sandbox/policies/local-admin/** @sec-reviewers

Application update settings: owned by IT Dept.

/terraform/sandbox/configuration-profiles/update-settings/** @endpoint-admins

Production: require multiple approvers

/terraform/prod/** @sec-reviewers @endpoint-admins

Workflows

/.github/workflows/** @sec-reviewers

ここでのポイントは、ディレクトリ構造自体をレビュー境界に合わせることです。

GitHub Actions workflow の統制：apply の実行条件を絞る

PR 駆動の GitOps では、terraform plan が“事前確認”で、terraform apply が“本番反映”です。この 2 つを分けて考え、apply が実行され得る条件を狭くすることで、変更管理をセキュアにできます。

本件での設計の要点は terraform plan と terraform apply の実行ワークフローを分離し、承認前に本番反映 (apply) が起きない状態を Branch Protection で担保することです。

具体的には PR 作成時には plan を実行し、レビュワーはコード差分と plan 出力を一次情報として確認します。一方で apply は main ブランチへのマージ後にのみ実行されるようにし、「承認済みの変更だけが反映される」状態をワークフロー条件とします。Branch Protection に関わるセキュリティ上の論点については、補足として「GitHub の Branch Protection の突破方法 | メルカリエンジニアリング」も併せて参照ください。

さらに、ワークフロー自体を保護することも重要です。GitOps において CI/CD は実質的に“実行主体”であり、ここが最重要の保護対象になります。そのため、本件では plan と apply のワークフローを分離し、それぞれが参照できる API 権限も分離します。具体的には、plan は読み取りに必要な範囲に限定し、apply は反映に必要な範囲に限定します。加えて、認証情報は特定のワークフローが特定の GitHub イベントで実行された場合にのみ、CI 上で一時的に参照できるようアクセス制御を適用し、不要な露出を避けます。

最後に、.github/workflows/**配下の変更についても勿論レビューを必須にすることで、CI/CD の改変による統制の迂回を防ぎます。

この設計によって、「強い操作権限を常に人へ配り続け、手動での変更管理」状態から、承認プロセスに通った変更だけが自動で反映される状態への移行準備が整いました。Jamf Pro は端末に対して大きな影響を与え得るため、変更管理をこの構造に乗せること自体がリスク低減になります。

移行：既存 Jamf リソースを IaC へ取り込む

Import block / generate-config-out で「ゼロから書かない」移行にする

Jamf Pro には既に多くの設定が存在しているため、IaC 化を“ゼロから書く”方式で始めると、次の問題が起きがちです。

• 現行設定の再現に時間がかかる

• 再現ミス（設定の抜け漏れ）が起きる

• 結果として、移行プロジェクトが止まりやすい

そのため、本取り組みでは Terraform の Import block と -generate-config-out を活用し、既存の Jamf リソースを起点に tf ファイルを生成し、state に取り込む流れを中心に据えました。

（コマンド例）

terraform plan -parallelism=1 -generate-config-out=.tf

このアプローチの利点は、移行を“正確性”と“スピード”の両立で進めやすい点です。運用移行では、最初から完璧な整理（理想のディレクトリ構成やモジュール化）を目指すより、まず「plan が安定して読める状態」まで持っていく方が、その後の GitOps 運用に繋がりやすいと考えています。

なお、メルカリでは 100 を超える Jamf Pro リソースがあるため、手動で import ブロック書くのも一定時間を要する可能性があり、事前に「Jamf Pro のリソース情報を取得して import ブロックを自動生成する」プログラムを準備して臨みました。但し、こちらは Terraform provider 側で将来 terraform query へ対応した場合は、該当コマンドへ置き換えが可能となります。

つまずきどころ 1：構成プロファイルの差分が毎回出る問題

構成プロファイルでは、初回に*.mobileconfig をペイロードとして Jamf Pro へ作成した際に、Jamf Pro 側で PayloadIdentifier などの付加情報が追加されることがあります。結果として、次回の terraform plan で差分が必ず出る、という状況が起こり得ます。

例えば、GitHub プロジェクト側の mSCP (macOS Security Compliance Project) 側で自動生成される mobileconfig ファイルをそのまま使う場合は本事象が発生します。

この差分は“危険な変更”というより、管理システム側の正規化（自動付加）により起きているため、運用としては次のように整理しておくと混乱が減ります。

• 「差分が出る＝即 apply」ではなく、まず差分の性質を分類する。

• 既存リソースは import を起点に扱い、変更時に差分を取り込む方針に寄せる

• 新規登録リソースも既存の正規化（自動付加）を sandbox 環境などで検証の上、正規化された状態で本番へ適用。

これにより、GitOps の価値である「plan を一次情報としてレビューする」を維持しつつ、ノイズ由来の差分で運用が疲弊することを避けられます。

つまずきどころ 2：Policy 更新時の差分の見え方

Policy 更新時は、plan/apply で例えば Self Service に関する属性差分が表示されるなど、UI 上の変更と一致していても“コード上の差分”として表現されることがあります。将来的に Terraform provider 側の改修に伴い解消する可能性がありますが、それまでは差分が「意図した変更か」を判断するためのチェック観点を押さえ、Terraform を利用する関係者で共有出来る形にすることで、円滑な運用に繋げることが出来ます。

運用：属人性を減らすために“プロセスで残す”

PR が「背景・差分・plan」をまとめた一次情報になる

従来、変更の背景（なぜ必要か）や手順、結果は Slack や Google Docs、Notion などに散らばりがちでした。GitOps へ寄せると、少なくとも変更の入口が PR に集約されるため、

• PR 記述 (なぜ変えるのか)

• コード差分 (何を変えるか)

• plan 出力 (何が起きるか)

が、1 つの場所に残ります。これは、コンテキスト散在や所管不明瞭の改善に直結します。

コードオーナー＋レビューにより「気づいた人」から「責務」へ

コードオーナーは単に“レビューを依頼する仕組み”ではなく、責務境界をコードに埋め込む仕組みとして機能します。結果として、特定のリソースに対して「どのロールが見るべきか」を継続的に維持しやすくなります。

変更履歴の可視化（通知）で“あとから追える”を当たり前にする

GitOps では main ブランチが事実上の“唯一の正”になるため、main の変更履歴を関係者が追える形にするのが重要です。main の変更履歴をポストするチャンネルを用意して GitHub にアクセスせずともどのような変更が行われているかについてリーチし易い環境を用意しました。

導入効果

ここまでの取り組みを経て、私たちの運用が具体的にどのように変わったのかを紹介します。

1. ClickOpsからの解放

これまでの変更手順書に対するレビューでは、手順の Web UI を頭でトレースしてレビューを行っていました。「この操作で意図した設定に変わるのかな？」「前提のステップや併せて変更するべきリソースはどこだろう？」という、ある意味想像力を働かせたレビュー必要でした。仮に sandbox 環境でのテストをパスしていたとしても本番環境との僅かな差異によって予期せぬ挙動を招くリスクがあり、手順書作成からテスト、本番実装までのリードタイムも膨らんでいました。また、仮に完璧な手順書があったとしても、手作業中心では最後の最後でのオペミス（クリックやコピペ内容）というヒューマンエラーのリスクを内包していました。

移行後は PR のコード差分と terraform plan の出力結果という一次情報が目の前にあるため、レビュー品質とスピードがあがりました。また、変更の反映も手作業では無く「プログラムによる確実な実行」がもたらした安心感はとても良いです。

2.監査・トラブルシューティングが容易に

PR そのものが「変更背景・差分・実行結果」をすべて内包するログとなっています。いつ、誰が、何の目的・背景で変更したのかが main ブランチの履歴と紐付いて残るため、監査やトラブルシューティングの際も、迷わず一次情報へ辿り着けるようになりました。

3.仕組みで責任と権限の担保

コードオーナーによって、ディレクトリ構造とレビュー（承認）責務が紐付いています。また、「承認された変更のみが自動適用される」フローを構築したことで、将来的に「最小権限の原則」の実現に向けたよい準備となりました。

今後の展望

1. 管理対象リソースの拡大

Jamf Pro の Terraform provider は有用ですが、開発途上の側面もあり、リソースタイプやリソースの構成によっては"差分ノイズ"と継続的に付き合う可能性があります。ノイズが多いと plan レビューの焦点がぶれ、レビュワーが疲弊する状況になりますので、まずは sandbox での検証を継続しつつ、本番での管理 (import) は段階的に広げる運用を継続予定です。

2. Jamf の機能追加に伴う拡張

将来的には通常の Jamf Pro リソース管理に加え、Jamf 社が公式で開発している別 provider (※) で扱える領域 (例: blueprint や compliance benchmark) を含めて、デバイスの管理運用やセキュリティコントロールを改善できる余地があります。

※: https://registry.terraform.io/providers/Jamf-Concepts/jamfplatform/latest/docs

2025 年 12 月上旬現在、この機能を用いる Jamf Platform API は public beta のアナウンス待ちとなり、それまでは Web UI での変更管理となります。

https://developer.jamf.com/platform-api/reference/getting-started-with-platform-api

3. 運用メンバー向け Onboarding

日常的に開発を行っているメンバーは GitOps の活用が容易ですが、そうでないメンバーや別チームの関係者に対しても「使ってみようかな」と考えてもらえる仕掛けや、取りかかりし易い環境は大切です。エディタや GitHub の使い方や、Terraform 特有の記法のガイドなど、一方的なドキュメントの連携だけで終わらせるのではなく、メンバーからのフィードバックによる改善など、関係者で利用促進のポイントを継続検討予定です。

まとめ

• Jamf Pro の変更管理を、手順書・手作業中心の運用から、Terraform による IaC＋PR 駆動 GitOps (plan レビュー→承認→apply) へ移行しました。

• 変更は PR の差分と terraform plan 出力を一次情報としてレビューできるため、レビューの質と速度を上げつつ、適用は自動化することでオペミスの余地を減らす設計にできました。

• コードオーナーやワークフローの実行条件で「変更範囲」と「承認責務」を結びつけ、所管の曖昧さやコンテキスト散在に対しても、プロセスと履歴が残る形で改善を狙えるようになりました。

• 一方で、差分ノイズが出やすいリソース（例: 構成プロファイル）などの課題もあるため、import の方針や運用ルールを整備しながら、段階的に改善していきます。

近年、Jamf Proだけでなく法人向け他製品についても前述のようなセキュリティやガバナンス上の利点から GitOps や IaC に関わる要素技術（API や Terraform provider）へ多大な投資が行われています。将来の製品選定基準の一つとして本要素を含めるのも良いかもしれません。

本記事が各組織の macOS, iOS 構成管理の課題検討の一助になれば幸いです。

最後に、メルカリで GitOps を Policy as Code として活用し、セキュリティとガバナンスを拡張することにご興味がありましたら、セキュリティチームの採用情報について mercari careersをご覧ください。

明日の記事は akkie さんです。引き続きお楽しみください。