IBM Power の ppc64le（PowerPC 64bit Little Endian）で動く SUSE Linux Enterprise Server 15.2 に、Microsoft Defender for Endpoint（旧 MDATP / mdatp）を入れようとして「No provider of ‘mdatp’ found.」で詰まった方向けに、対応状況の結論、公式情報の確認点、代替策をまとめます。
結論：SUSE Linux Enterprise 15.2（ppc64le）では Defender for Endpoint を導入できない
先に結論から言うと、現時点の Microsoft Defender for Endpoint（Linux 版）は ppc64le アーキテクチャをサポートしていません。そのため SLES 15.2（ppc64le）環境で mdatp パッケージが見つからず、zypper が「No provider of ‘mdatp’ found.」を返すのは、設定ミスというより “提供物が存在しない” ことが原因です。
Microsoft Learn の前提条件ページでは、Linux 版 Defender for Endpoint の対象を x64（AMD64/EM64T） と ARM64 に分けて列挙しており、ppc64le は記載がありません。また「明示的に列挙されていないディストリビューション／バージョンは未サポート」と注記されています。PowerPC 系の記載がない以上、公式サポートとしては「未対応」と判断するのが安全です。
なぜ「No provider of ‘mdatp’ found.」が出るのか
このエラーは、SUSE 系のパッケージ管理でよく出る “候補が見つからない” 系メッセージです。zypper install mdatp（または zypper install packages-microsoft-com-prod:mdatp）を実行したとき、有効化されているリポジトリのどこにも、現在の CPU アーキテクチャ向けの mdatp パッケージが存在しない場合に発生します。
重要なのは、Linux の RPM/DEB パッケージは基本的にアーキテクチャ別（例：x86_64、aarch64、ppc64le）にビルドされるという点です。SLES 15（x86_64）向けに提供されている mdatp-...x86_64.rpm を、ppc64le に “そのまま” 入れることはできません。つまり、ppc64le で mdatp を入れたいなら、ppc64le 用 RPM が公式に提供されていることが前提になりますが、現状それがありません。
公式ドキュメントで確認すべきポイント
「対応しているか？」を最短で判断するには、Microsoft Learn の情報を次の順で確認するのが確実です。現場では、ここを押さえるだけで “インストール手順の迷子” を大幅に減らせます。
| 確認ポイント | 見るべき内容 | 今回（SLES 15.2 / ppc64le）の結論 |
|---|---|---|
| サポート対象アーキテクチャ | Linux 版が x64/ARM64 など、どの CPU を対象にしているか | ppc64le の記載なし → 未サポート |
| サポート対象ディストリビューション | SLES 15.x など “OS 名とバージョン” が列挙されているか | SLES 15.x 自体は記載あり（ただし x64 前提） |
| ARM64 の扱い | ARM64 は “一部のみ” のことが多い（SLES も SP 指定がある） | ARM64 は対応が拡大中だが、ppc64le とは別問題 |
| 未記載の扱い | 「明示されないものは未サポート」等の注記 | ppc64le は未記載 → 公式には頼れない |
x64（AMD64）でサポートされている主な Linux（参考）
前提条件ページには、x64（AMD64/EM64T）でサポートされるディストリビューションとして、RHEL / Ubuntu / Debian / SLES 12.x・15.x / Oracle Linux / Amazon Linux / Fedora / Rocky / Alma / Mariner などが挙げられています。“SLES 15.x” と書かれていても、それは x64 の話である点が落とし穴です。
x64/ARM64/ppc64le：SLES だけ抜粋した対応イメージ
同じ「SUSE Linux Enterprise Server 15」でも、CPU アーキテクチャによって扱いが分かれます。とくに ARM64 は “SLES 15.x 全体” ではなく、サービスパックが限定される点が重要です。例えば SLES 15.2（SP2）は、ARM64 の一覧には含まれていません（x64 の SLES 15.x としては対象範囲に入ります）。
| CPU アーキテクチャ | SLES の記載例 | 読み替えのコツ |
|---|---|---|
| x64（AMD64/EM64T） | SUSE Linux Enterprise Server 12.x / 15.x | “15.x” は SP2（15.2）などを含む広い表現。まずは uname -m が x86_64 かを確認 |
| ARM64（aarch64） | SUSE Linux Enterprise Server 15（SP5, SP6）ARM64 | ARM64 は SP 指定がある。対象 SP に合わない場合は未サポート扱いになり得る |
| ppc64le | 記載なし | 公式の対応表に出てこない時点で、サポート対象としては期待しない |
ARM64 は GA になったが、SLES は SP 指定がある
近年は ARM サーバーが普及したこともあり、Defender for Endpoint は ARM64 Linux サーバー対応を GA（一般提供）として発表しています。ただし、ARM64 の対応範囲はディストリビューション・バージョンが限定され、SLES についても “特定 SP のみ” といった指定があります。ppc64le 対応の話とは切り分けて考える必要があります。
手元でできる：ppc64le で導入不可を切り分けるチェックリスト
「本当に未サポートが原因か？」を社内説明するには、端末上の事実を揃えるのが近道です。以下は SLES でよく使う確認手順です（すべて読み取りのみ、システム破壊のリスクが低い順）。
| 観点 | コマンド例 | 見るべきポイント |
|---|---|---|
| CPU アーキテクチャ確認 | uname -m / arch | ppc64le になっているか（x86_64 や aarch64 ではないか） |
| OS バージョン確認 | cat /etc/os-release / SPident | SLES 15.2（SP2）など、運用要件に合うか |
| Microsoft リポジトリ有効化 | zypper lr -u | microsoft-prod 等が入っているか |
| mdatp の検索 | zypper se -s mdatp | 候補が 0 件なら “提供なし” が濃厚 |
| 依存関係より前に止まるか | zypper in mdatp | 依存関係エラーではなく “provider 不在” なら未提供の可能性が高い |
もし Microsoft リポジトリが未設定なら、Microsoft Learn の手順に沿って SLES 向けリポジトリを追加します。例えば “prod チャネル” を追加する場合は次のような流れになります（distro/version は環境に合わせて読み替えます）。
# 例：SLES の prod チャネル（リポジトリ設定）
sudo zypper addrepo -c -f -n microsoft-prod https://packages.microsoft.com/config/sles/15/prod.repo
# GPG キーの取り込み
sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
# リポジトリ更新
sudo zypper refresh
zypper で「リポジトリにはあるが、このCPUでは出ない」を確認する
社内で説明するなら、「リポジトリ設定の誤りではなく、アーキテクチャ不一致で候補が出ない」ことを示すのが効果的です。zypper は対象リポジトリを絞って検索できるので、microsoft-prod だけに対して mdatp を検索し、結果が空になることを確認します。
# どのリポジトリが有効か（URL付き）
zypper lr -u
# microsoft-prod だけを対象に mdatp を検索（候補が出なければ提供なし）
zypper se -s -r microsoft-prod mdatp
# 利用可能なパッケージのアーキテクチャを表示（候補がある環境では x86_64/aarch64 が見える）
zypper se -s mdatp
上記で候補が 0 件なら、「リポジトリに接続できているのにパッケージが存在しない」ことが明確になります。逆に、x86_64 の SLES 15.x で同じ手順を実行すると、mdatp の RPM が候補として列挙されるため、原因がアーキテクチャであることを比較で示せます。
問い合わせや稟議で役立つ“添付情報”
将来の対応可否を Microsoft 側に確認したい場合や、監査向けに例外申請を出す場合は、次の情報を最初から揃えておくと話が早くなります。
- CPU アーキテクチャ：
uname -mの結果（例：ppc64le） - OS 情報：
/etc/os-releaseと Service Pack（例：SLES 15 SP2） - リポジトリ一覧：
zypper lr -uの結果 - 検索結果：
zypper se -s mdatpが 0 件であること - プロキシ/FW の有無（将来 x86_64 へ更改する場合の事前確認にもなる）
ここまで実施しても ppc64le では mdatp が見つからないケースがほとんどです。実際、SLES 15 向けのパッケージ公開場所を見ると、mdatp は x86_64 と aarch64 の RPM が中心で、ppc64le が並んでいないことが確認できます。つまり “リポジトリは正しいが、ppc64le 用が存在しない” という状態です。
ppc64le は今後サポートされる？ロードマップの考え方
多くの方が気にするのが「将来 ppc64le 対応が来るのか？」ですが、公開情報として ppc64le 対応の具体的な計画（ロードマップ）を断言できる材料は見当たりません。Microsoft Q&A でも “現時点では ppc64le をサポートしていない” 旨が述べられるに留まっています。
一方で ARM64 は GA 化が発表され、実際に前提条件ページにも ARM64 対応のディストリビューション一覧が追記されています。つまり、アーキテクチャ対応は拡大する可能性があるものの、ppc64le が対象になるかは別問題です。期待値調整としては「将来は不明。最短で追うなら “前提条件” と “What’s new” を定期的に見る」が現実的です。
“エージェントを入れられない” 前提で防御力を落とさない代替策
ppc64le 環境は、基幹系（SAP、DB、レガシー連携）や IBM Power の都合で残ることがあります。ここで大切なのは「Defender for Endpoint を入れられない＝何もできない」ではなく、守る対象を分解して、別レイヤーで補うことです。
現実的な打ち手を “レイヤー別” に整理する
| レイヤー | 狙い | 具体策（例） | ポイント |
|---|---|---|---|
| 境界・ネットワーク | 侵入経路を減らす | セグメンテーション、NW ACL、L7 プロキシ、IDS/IPS、踏み台経由の運用 | “直接到達できない” 状態を作ると、エージェント不在の弱点を補いやすい |
| 認証・権限 | 横展開を止める | SSH 鍵の棚卸し、特権 ID 管理、sudo 権限制御、多要素認証（可能なら） | Power 環境は運用者が固定化しがち。権限の棚卸し効果が大きい |
| OS 設定 | 攻撃面を狭める | 不要サービス停止、最小パッケージ、カーネル/ミドル更新、CIS ベースのハードニング | “更新できない” 前提なら、露出ポート削減と設定固定が効く |
| 監視・検知 | 発見を早める | syslog 集約、audit ログ収集、プロセス監視、ファイル改ざん検知（FIM） | EDR がなくても “兆候” を拾う設計はできる |
| バックアップ/復旧 | 被害最小化 | オフライン/イミュータブルバックアップ、リストア訓練、RTO/RPO 設計 | ランサム対策は “検知” と同じくらい “復旧” が重要 |
“Defender for Endpoint を使いたい” を実現する現実解
要件として「Microsoft Defender for Endpoint を導入したい」が強い場合、技術的に確実なのは サポートされるアーキテクチャへ寄せることです。例えば次のような分割が現場では取りやすいです。
- インターネット到達性がある/外部公開するサーバー：x86_64（または対応する ARM64）へ更改して MDE を導入
- Power でないと動かない基幹系：ppc64le のまま、ネットワーク分離＋踏み台＋ログ集約で補強
- 運用端末/踏み台：MDE を入れて操作監査・侵害時の封じ込めを強化
“サーバー全台に同じエージェント” は理想ですが、アーキテクチャ制約がある環境では、守る優先度が高いゾーンから順に MDE を適用し、適用できないゾーンは境界で固めるのが、監査対応としても説明しやすい落とし所です。
運用でハマりやすい注意点
プロキシや SSL インスペクションの影響
Defender for Endpoint（Linux 版）は、ネットワーク要件が意外と厳しいことがあります。PAC/WPAD や認証付きプロキシ、SSL インスペクション（中間者型の検査）に制約があるため、社内の標準プロキシ設計と衝突しやすいです。導入できるアーキテクチャへ更改する場合でも、事前にネットワーク要件を確認しないと “入ったがクラウド接続できない” で詰まります。
fanotify 系セキュリティ製品との競合
Linux のリアルタイム保護は fanotify を使うことが多く、同種の製品を併用すると競合（最悪の場合ハング）が起こり得ます。既存のウイルス対策を入れている環境では、併用可否と除外設定を必ず設計に入れてください。
アップデートの前提（“放置すると期限切れ” があり得る）
Defender for Endpoint（Linux 版）は定期的に更新され、バージョンには有効期限の考え方もあります。導入後に “更新できないネットワーク” に閉じ込めると、セキュリティ上も運用上もリスクになります。更改計画を立てるときは、更新経路（ミラー/プロキシ/オフライン更新）の設計まで含めて考えるのが安全です。
ppc64le 環境での意思決定を速める判断フレーム
「いつか対応するかもしれないから待つ」では、セキュリティ要件の説明が難しくなりがちです。そこで、ppc64le 環境では次の 3 つの質問で整理すると意思決定が速くなります。
| 質問 | YES の場合 | NO の場合 |
|---|---|---|
| このサーバーは外部に露出しているか？ | 更改（x86_64/対応 ARM64）＋MDE 導入を優先 | 内部限定なら境界強化＋監視強化でも妥協しやすい |
| Power 固有の理由で ppc64le から動かせないか？ | “入れない前提” で多層防御（ログ・境界・権限）へ投資 | 移行可能なら、次期更改でサポートアーキテクチャへ寄せる |
| 監査・ガバナンスで「EDR 必須」が明文化されているか？ | 例外扱いの承認プロセス（リスク受容）を整備 | 代替統制（ネットワーク/監視/復旧）で要件を満たす |
この整理をしておくと、「なぜ ppc64le だけ MDE が入っていないのか？」という指摘に対して、“未サポートだから入れない” だけでなく、代替統制まで含めて説明できます。
まとめ
SUSE Linux Enterprise Server 15.2（ppc64le）で mdatp が見つからないのは、現時点で Microsoft Defender for Endpoint（Linux 版）が ppc64le をサポートしていないことが主因です。ロードマップは公開されていないため、公式の前提条件ページや更新情報を定期確認しつつ、短期的には “入れられない前提” の多層防御（境界・権限・監視・復旧）でカバーするのが現実的です。MDE 導入が必須要件なら、サポートされるアーキテクチャへの更改も含めて、システム全体の設計として判断しましょう。
コメント