Chef Infra Serverを運用しているインフラエンジニアの皆さん、大きな転換期がやってきました。長年、企業の構成管理を支え続けてきたChef Infra Serverですが、2026年11月をもって完全にEOL（End of Life：サポート終了）を迎えます。
「え、じゃあ今使っているCookbookやノードはどうなるの？」
「新しく出たChef 360って、これまでのサーバーと何が違うの？」
そんな疑問を抱えているChefユーザーに向けて、本記事では次世代プラットフォーム「Chef 360 Platform」の位置付けや、従来のInfra Serverとの違い、オンプレ企業がこれから取るべき移行戦略について分かりやすく整理します。
1. 【重要】Chef Infra Serverが2026年11月にEOLへ
まず押さえておくべき最大のトピックは、Chef Infra Serverの製品寿命（EOL）です。
- サポート終了時期： 2026年11月
- アップデート終了： 2026年10月末（オープンソース版含む）
この期限を過ぎると、セキュリティパッチの提供やバグ修正が完全に停止します。そのため、現在Chef Infra Serverを利用している企業は、早急に次世代システムへの移行計画を立てる必要があります。
そして、その公式な移行先としてProgress社（Chefの開発元）が打ち出したのが、今回ご紹介する「Chef 360 Platform」です。
2. Chef 360 Platformとは？従来のChef Infra Serverとの違い
「Chef 360」は、単なるChef Infra Serverのバージョンアップ版ではありません。構成管理、コンプライアンス（InSpec）、アプリケーションデプロイ（Habitat）、そしてジョブオーケストレーションを1つに統合した「次世代のDevOps統合プラットフォーム」です。
では、具体的に何が変わったのでしょうか？
構成管理の中核は「Chef DSM」へ
従来のChef Infra Serverが担っていた「Cookbook、ポリシー、環境変数、ノードのメタデータ管理」というコア機能は、Chef 360 Platform内の内部サービス「Chef DSM（Declarative State Management）」に引き継がれました。
従来のInfra Serverとの主な違い
従来のサーバー単体運用に比べ、以下のようなアーキテクチャ上の進化を遂げています。
- 基盤のコンテナ化（Kubernetesベース）：Chef 360はKubernetes上で動作します。これにより、万が一サービスがダウンしても自動で再起動する「自己修復力」や、負荷に応じた「柔軟な水平スケーリング」が可能になりました。
- エコシステムの継続：サーバー側の仕組みは変わりますが、ノード側で動く Chef Infra Client、InSpec、Chef Workstationなどの既存ツールはそのまま継続してサポートされます。これまでに書き溜めたCookbookやポリシーの資産を無駄にすることはありません。
3. Chef 360はSaaS？オンプレ？
多くのエンタープライズユーザーが気になるのが「提供形態」でしょう。結論から言うと、Chef 360は「SaaS」と「オンプレミス（セルフマネージド）」の両方に対応しています。
| 提供形態 | 特徴 | 向いている企業 |
| Chef 360 SaaS | Progress社がホスト・運用・アップデートをすべて管理する完全マネージドサービス。 | 運用負荷を極限まで減らし、インフラのコード化（IaC）に集中したい企業。 |
| Chef 360 Self-Managed | 自社のインフラ環境に構築するタイプ。既存のKubernetes環境を利用する BYOK（Bring Your Own Kubernetes） や、完全に外部から隔離された エアギャップ（Air-Gapped）環境にも対応。 | 厳しいセキュリティポリシーがあり、データを外部に出せないオンプレミス中心の企業。 |
4. 「SaaS化・プラットフォーム化」4つのメリット
Chef 360がプラットフォーム化（特にSaaS化）したことで、運用者には多くのメリットがもたらされます。
- 管理負担のゼロ化（SaaSの場合）これまで苦労していたChef Server自体のOSアップデート、パッチ適用、バックアップ運用から完全に解放されます。
- リアルタイムな可観測性（Observability）インフラの設定ドリフト（意図しない変更）やコンプライアンス違反の状態を、洗練されたWeb UIから一目でリアルタイムに確認できるようになります。
- ClickOps（GUI操作）の強化テンプレート化されたUIから、安全かつガバナンスが効いた状態でインフラタスクをスケジューリング、または即時実行（単発実行）できます。
- ゼロトラストに準拠したセキュリティ強固なロールベースのアクセス制御（RBAC）が組み込まれており、大規模な組織でもチームごとに安全な隔離環境を維持できます。
5. クラウドとオンプレが混在する「Hybrid環境」での活用
現代のエンタープライズインフラは、すべてがクラウドにあるわけでも、すべてがオンプレミスにあるわけでもありません。Chef 360は、このハイブリッド環境でこそ真価を発揮します。
Chef 360（SaaSまたはオンプレの中央管理拠点）から、AWS、Azure、GCPなどのパブリッククラウドはもちろん、社内データセンターの物理サーバーや仮想マシン、さらにはエッジロケーションまで、あらゆる環境のノードを一元的に横断管理できます。
環境ごとに管理ツールを分ける必要がなくなり、「どこにあっても、同じポリシーで安全に構成管理とコンプライアンス確認を行う」という理想的な運用が実現します。
6. オンプレミス企業はどう移行すべきか？
現在Chef Infra Serverをオンプレミスで運用している企業は、2026年11月に向けてどのように移行を進めるべきでしょうか。推奨されるステップは以下の通りです。
ステップ1：移行先のプランを選択する
- 第一推奨：Chef 360 SaaSまずは運用の複雑さを最小化するためにSaaSへの移行を検討しましょう。
- 第二推奨：Chef 360 Self-Managed社内レギュレーションでSaaSが使えない場合は、社内Kubernetes環境（BYOK）への構築プランを選択します。
ステップ2：移行ツールの活用
Progress社からは、従来の環境からスムーズに移行するためのツールが提供されています。基本的には以下のワークフローでデータをインポートします。
- 従来のChef Infra Serverで
knife-ec-backupツールを使い、組織、ユーザー、Cookbook、ポリシー、ノードなどのデータをエクスポート。 - Chef 360が提供する移行用コマンドラインツール
chef-import-cliをダウンロード。 - バックアップファイルをChef 360にアップロードすると、データが自動処理され、新しいChef DSMへとデータがリストアされます。
- 既存ノードの接続先（
config.rbやclient.rb）をChef 360のURL（FQDN）に切り替える。
長年運用して溜まった不要なデータや古いCookbookがある場合は、この移行のタイミングでクレンジング（整理）を行うのがベストです。
7. まとめ
Chef Infra Serverの2026年11月EOLは、一見すると大きな課題に思えますが、運用の近代化を進める絶好のチャンスでもあります。
単なる「設定管理サーバー」から、ハイブリッド環境を安全に統制する「DevOpsプラットフォーム（Chef 360）」へとシフトすることで、今後のインフラ運用はより強固で効率的なものになるはずです。
まだ国内での情報が少ないChef 360ですが、公式ドキュメントや移行ツールはすでに整備されています。EOL直前に慌てないよう、まずは既存のChef環境の棚卸しと、SaaS/オンプレどちらに舵を切るかの社内ディスカッションから始めてみてはいかがでしょうか？
おわりに：技術サポート・移行支援のご案内
弊社では、今回のようなChef Infra Serverからの移行に不安を抱えるお客様に対し、現在の環境の構成やInSpecの活用状況を詳細にアセスメントし、最適な移行ロードマップをご提案するサポートを実施しております。
- 「自社環境ではSaaS版とSelf-Managed版のどちらが最適か」
- 「具体的な移行手順や必要な期間を知りたい」
といったご相談がございましたら、お客様のDevOps推進を支援する弊社の専門チームまで、ぜひお気軽にお問い合わせください。