Jamfを活用する様々な手法 Infrastructure as Code（IaC）とJamfのプラットフォームAPIゲートウェイ
Appleデバイスの管理を思いどおりに。
プラットフォームAPI
1つのゲートウェイからすべてのJamf製品へアクセス。Jamf製品を単体で運用している組織は、ほとんどありません。たいてい、Jamf Pro、Jamf Protect、Jamf Security Cloudを組み合わせて運用し、それぞれにAPI、認証、ベースURLが使用されています。プラットフォームAPIゲートウェイは、このような状況を変革します。Jamfプラットフォームの前面に配置されるこのゲートウェイは、スコープがお客様のテナントに限定され、きめ細かな権限で管理される、OAuth 2.0認証対応のエントリーポイントです。
AIを活用する開発向けの設計
AIにも扱いやすい
プラットフォームAPIゲートウェイは、開発者だけでなくAIツールにとっても使いやすいよう設計されており、高い一貫性と予測可能性を備え、人間と言語モデルの双方が解析できる方法でドキュメント化されています。
ライブデータクエリ
Jamfは開発者ドキュメントのllms.txtインデックスを公開し、ホスト型MCP（Model Context Protocol）サーバを運用しています。これにより、Claude CodeやGitHub CopilotなどのAIコーディングアシスタントツールは、古くなった学習データから推測するのではなく、ソースから直接、リアルタイムで正確なAPI仕様をクエリできます。
IaC（Infrastructure as Code）
Appleデバイスをコードとして管理。ほとんどのデバイス管理は、10年前から方法が変わっていません。つまり、ログインし、クリックし、設定する。その繰り返しです。数十台のデバイスを管理するのであれば問題ありませんが、数百のポリシー、複数の拠点、複数のJamf Proインスタンスほどの規模になると、管理の信頼性は低下します。
組織の成長に伴うクリック操作運用のデメリット：
- 意図が記録されない：ログには誰が設定を変更したかは記録されますが、変更の理由が記録されることはまれで、事前のテスト内容は記録されません。
- 構成のずれ：ある管理者の変更が別の管理者の変更と競合し、6ヶ月後には「標準の状態」がどのようなものだったかは誰にもわからなくなります。
- 知識の流出：構成に関する暗黙知が管理者の頭の中にしかなく、その担当者が退職すると、コンテキストも失われてしまいます。
- 監査対応の遅れ：コンプライアンスを証明するのに、履歴を提示するのではなく、スクリーンショットや散在するエクスポートデータからタイムラインを再構築することになります。
- 事後対応型の体制：コンソールでの反復作業に時間を奪われ、より価値の高いプロジェクトに時間を費やせなくなります
JamfによるIaCのサポートのポイント
IaCに対するJamfのアプローチはTerraformを基盤としており、（あえて）単一のクローズドなファーストパーティツールとしては提供していません。Jamfが構築したプロバイダとコミュニティが構築・維持しているプロバイダからなる階層構造になっており、これらを組み合わせて、Apple環境全体をコードとして記述し、同じプラットフォームAPIゲートウェイを通じて管理できるようになっています。また、既にお客様が運用しているJamf Pro環境を基盤としているため、導入にあたってMDMを切り替える必要がありません。
Jamfのパートナーとエコシステム
- Jamf Proプロバイダ：Deployment Theoryが構築：現在は、Lloyds Banking Groupをはじめとする、Jamfを利用されているエンジニアからのコントリビューションによって維持されています。
- Jamfプラットフォームプロバイダ：Jamfが構築：プラットフォームAPIの拡張に伴い、対応範囲も拡大。最新のリリースでは、1つの認証済み接続で、Jamf Proのすべての機能にシームレスにアクセスできます。
- Jamf Protectプロバイダ：Jamfが構築。
- jamformer：既に構成済みでコンソールで管理されているテナントをコード化するためのJamf Conceptsツール。
Jamfのプロバイダとツールの機能
Jamf Proプロバイダ
Classic APIとJamf Pro APIを介して、ポリシー、スクリプト、構成プロファイル、スマートグループ、スタティックグループ、事前登録、パッケージなどを管理します。
Jamfプラットフォームプロバイダ
ブループリント、コンプライアンスベンチマーク、デバイスグループ、デバイスアクション、統合インベントリのデータソースなど、プラットフォームAPIのを通じて提供されるリソースを管理します。
Jamf Protectプロバイダ
Jamf Protect独自のGraphQLベースの構成をコードとして（CaC）管理します（プラン、アクション構成、例外セットなど）。
jamformer
Jamfインスタンスに含まれているものを検出し、4つのプロバイダすべてにわたるTerraform構成の草稿を生成します。移行作業を空のファイルから始める必要がありません。
ワークフロー：
-
Terraform設定ファイルで、理想とする状態（必要な設定、プロファイル、ポリシーなど）を定義します。
-
稼働中のデバイスに変更を加える前に、terraform planコマンドを実行して、変更内容（作成、修正、削除）を差分形式で正確に確認します。
-
プルリクエストを提出します。レビュー担当者が差分を確認して承認すると、terraform applyコマンドが実行され、Jamf環境がGitの状態と同期されます。
-
ロールバックする場合も、コミットを元に戻すだけで済み、焦りながらコンソールで手動で再クリックする必要はありません。
Jamfの独自の価値
既存システムの置き換えが不要
既存のAppleプラットフォーム上でIaCを導入できます。
Appleネイティブ、Appleファースト
Apple OSの実際の構成要素にマッピングされます。
重要な部分はオープンで
核心の部分はJamfが提供します。
監査で実証済み
複数のお客様が既に規制・監査対象のAppleデバイスをコードとして管理しています。
業界標準のTerraform
自社で既に利用しているツールを使用できます。
設計段階からAI対応
AIコーディングアシスタントが直接クエリできます。
よくあるご質問 (FAQ)
Jamf Pro APIとJamfプラットフォームAPIの違いは何ですか？
Jamf Pro APIは、Jamf Pro製品に特化したREST APIで、テナントごとに異なります。これに対して、JamfプラットフォームAPIは、1つのOAuth 2.0エントリポイントでJamf Pro、Jamf Protect、Jamf Security Cloudのすべてにアクセスできる新たな一元的窓口です。また、Jamf Proの各種リソースとの連携も始まっています。
IaC（Infrastructure as Code）を使用するには、Jamf Proから何か別のツールに移行する必要があるのでしょうか？
いいえ。お客様が既に運用しているJamf Proについては、JamfのTerraformプロバイダで管理できます。コードベースのワークフローの採用に際して、MDMの移行は必要はありません。
IaC（Infrastructure as Code）とは何ですか？ また、Appleデバイスの管理でIaCがなぜ重要なのですか？
IaC（Infrastructure as Code）とは、デバイス管理の構成（ポリシー、プロファイル、グループなど）をコンソールを通じた手作業で進めるのではなく、バージョン管理されたファイルに定義していくことを指します。AppleデバイスにIaCを利用すると、変更の一つひとつを実際のデバイスに配信する前に確認および監査できるようになるほか、必要に応じて元に戻すこともできます。
現在コンソールで管理しているJamf Proテナントがある場合にはどうすれば良いのでしょうか？
jamformerを使えば、既存のテナントの構成状況を検出し、Terraformの構成案を自動で生成できます。そのため、コードで管理する体制に移行する場合でも、まったくゼロからのスタートになるわけではありません。