Microsoft Entra External ID のユーザーで「ポータルからプロフィール画像をアップロードしようとしても失敗する」「メンバー／ゲストどちらでも同じ」と悩むケースがあります。結論から言うと、多くの場合は設定ミスではなく“サービスの前提が違う”ことが原因です。本記事では、仕様の見分け方と、要件を満たすための現実的な代替案を整理します。
結論：Entra External ID（外部構成テナント）のユーザーはプロフィール画像アップロードが非対応
Microsoft Entra External ID のうち、顧客ID（CIAM）用途を想定した外部構成テナント（external tenant configuration）では、ユーザーのプロフィール画像（写真）を Microsoft Entra 管理センターの画面からアップロードして保存する機能が、現時点ではサポートされていません。ポータル上に「写真の変更」やカメラアイコンが表示されていても、実際のアップロードは成功せず、分かりやすいエラーメッセージが返らないことがあります。
この挙動は、ネットワーク障害や画像サイズの問題といった“技術的な一時エラー”というより、External ID の設計目的（外部ユーザー／顧客向けのID管理）に起因する仕様上の制限として理解するのが現実的です。
まず整理：External IDは「B2B」と「CIAM（外部構成テナント）」を含む
「Entra External ID」という名称がやや紛らわしいポイントです。Microsoft のドキュメントでは、External ID は大きく次の2系統のシナリオを包含しています。
- 外部構成テナント（external tenant configuration）：アプリを消費者・顧客・社外利用者に公開するための CIAM 用テナント
- ワークフォース構成テナント（workforce tenant configuration）でのB2Bコラボレーション：社内テナントにゲストを招待し、Microsoft 365 や社内アプリへアクセスさせる
プロフィール画像の扱いは、このどちらのシナリオを使っているかで大きく変わります。外部構成テナントは「Microsoft 365 などの Microsoft のSaaSにSSOする用途ではない」前提で設計され、Microsoft 365 と密に統合されたプロフィール写真管理の仕組みが前提になりません。
| 観点 | ワークフォース（通常のEntra ID）/ B2B | External ID（外部構成テナント） |
|---|---|---|
| 主な用途 | 社内ユーザー＋取引先/ゲストのコラボ、Microsoft 365 連携 | 顧客・消費者向けアプリのCIAM（サインアップ/サインインの体験設計） |
| Microsoft 365 へのSSO | 想定される | 想定されない（Microsoftの一次SaaSへのSSOは対象外） |
| ポータルでのプロフィール画像 | 要件・設定次第で管理可能 | 現時点ではアップロードがサポートされない |
| おすすめの考え方 | 「社内ディレクトリの延長」として統一管理 | 「アプリがプロフィール体験を持つ」前提で設計 |
なぜ「変更ボタンが出るのに失敗する」のか
Microsoft Entra 管理センターのユーザー詳細画面では、サムネイルの右下にカメラアイコンが表示され、そこから写真をアップロードできるUIが用意されています。しかし、公式ドキュメントでも「プロフィール画像の更新で問題がある場合は Exchange Online のエンタープライズアプリが有効であることを確認してほしい」という注意が示されています。
この注意は、裏側のプロフィール写真がMicrosoft 365（特に Exchange Online など）と連動する前提で実装されていることを示唆します。一方、外部構成テナントの External ID は、そもそも Microsoft 365 へのSSOやメールボックス前提の統合が対象外のため、その前提を満たせず、結果として UI だけが見えて処理が成立しない（または失敗理由が一般化されて見えにくい）状態になりがちです。
| 見えている現象 | よくある誤解 | 実態（External ID外部構成テナントの場合） |
|---|---|---|
| ポータルに写真変更UIがある | 「設定すれば使えるはず」 | UIは共通部品でも、バックエンドがExternal IDでは非対応で失敗する |
| アップロードしても何も変わらない | 「画像サイズや形式が悪い？」 | 仕様制限のため、サイズ調整や権限付与で解決しないことが多い |
| メンバー/ゲスト種別でも同様 | 「ユーザー種別を変えれば解決？」 | External ID 外部構成テナントでは種別に関係なく非対応 |
「仕様かバグか」を切り分ける最短チェックリスト
プロフィール画像の要件があるときは、闇雲にトラブルシュートを始めるより、まず「今触っているテナントがどの構成か」を確定させるのが近道です。
| チェック項目 | 確認のしかた | 判定と次のアクション |
|---|---|---|
| テナントの目的 | 顧客向けアプリのサインアップ/サインイン、カスタム属性、ブランディング中心か | 該当するなら外部構成テナントの可能性が高く、写真はアプリ側管理を検討 |
| Microsoft 365 連携が前提か | Teams/Outlook/SharePoint など一次SaaSへSSOする設計か | 前提ならワークフォース/B2Bに寄せる方が要件を満たしやすい |
| 公式回答の有無 | Microsoft Learn / Microsoft Q&A で該当の明記があるか | External IDで写真が非対応である旨の回答が確認できる |
特に最後のポイントは重要です。Microsoft Q&A では「Entra External ID はプロフィール画像のアップロードをサポートしていない」という回答が明示されています。ポータル上の失敗が再現性高く起きる場合、まずこの前提を押さえるのが無駄な工数を減らします。
関連知識：Azure AD B2Cでも写真は長らく非対応だった
External ID は Azure AD B2C の後継として位置付けられる文脈が多く、写真まわりの制限も「B2Cで長く非対応だったものがExternal IDでも同様に扱われている」と理解すると腹落ちしやすいです。実際、Microsoft Graph のプロフィール写真更新 API の説明には「Azure AD B2C テナントではユーザー写真の更新がサポートされない」旨の注記があります。また、取得（GET）についても B2C テナントではサポートされない旨が記載されています。
つまり、External ID 外部構成テナントを「CIAMとして使う」場合、ユーザー写真を Entra の標準機能に依存する設計は、いまのところ避けた方が安全です。
代替案：プロフィール画像が要件に入る場合の現実的な選択肢
選択肢A：ワークフォース/B2Bコラボレーションを使う
プロフィール画像が「Microsoft 365（Teams/Outlook/SharePoint）上で表示されることが必須」「組織の顔写真台帳として統一したい」といった要件なら、External ID（外部構成テナント）ではなく、ワークフォース構成テナント側でユーザーを管理するのが王道です。具体的には次のどちらかを検討します。
- 社内ユーザー（member）として作成・管理する
- B2B ゲストとして招待し、必要なアプリ/グループに割り当てる
ワークフォース側では、MyAccount でプロフィール写真更新の機能拡張がアナウンスされているなど、写真の更新体験が整備されている流れがあります（※テナントや機能範囲は公式情報を確認してください）。
ただし、B2B/ワークフォースに寄せると「顧客向けに大量のアカウントを捌くCIAM」には運用・課金・UXの観点で向かない場合があります。次の表で、写真要件以外も含めた判断材料をまとめます。
| 判断軸 | ワークフォース/B2Bを選びやすいケース | External ID外部構成テナントを選びやすいケース |
|---|---|---|
| ユーザーの性質 | 取引先・協力会社など、少数〜中規模で“招待して使う” | 顧客・一般消費者など、不特定多数で“登録して使う” |
| 表示の主戦場 | Teams/Outlook/Microsoft 365 上での表示が重要 | 自社アプリ内のUI/UXが主戦場 |
| プロフィール画像 | Entra/M365の既存エコシステムに乗せたい | 自社アプリで任意項目として扱えれば十分 |
| サインイン体験 | 社内統制・条件付きアクセスを中心に設計 | ブランディング、属性収集、サインアップ導線を重視 |
選択肢B：アプリケーション側でプロフィール画像を管理する
External ID を継続利用しつつプロフィール画像が必要なら、現実解は「画像は自前ストレージに保存し、External ID のユーザーIDと紐付ける」方式です。External ID はサインアップ時に標準属性やカスタム属性を収集できるため、画像そのものではなく“画像URLや管理用キー”などのメタ情報を扱う設計と相性が良いです。
おすすめ構成（シンプルで運用しやすい）
| 要素 | 役割 | 設計ポイント |
|---|---|---|
| アプリのアップロード画面 | ユーザーが画像を登録/更新 | ファイル形式（JPEG/PNG）制限、サイズ上限、プレビュー |
| 画像処理（Function等） | リサイズ/サムネイル生成/検疫 | 正方形トリミング、複数サイズ生成、ウイルススキャン連携 |
| ストレージ（例：Azure Blob） | 画像の永続保管 | 公開範囲を明確化（社内限定/会員限定/公開） |
| メタデータDB | External IDのユーザーと画像を紐付け | objectId、etag、更新日時、削除フラグを保持 |
メタデータ設計例（DBの最小カラム）
| カラム | 例 | 目的 |
|---|---|---|
| entra_object_id | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | External ID のユーザー識別（主キー相当） |
| photo_url | （ストレージURL） | 表示用の画像参照先 |
| photo_version | 7 | キャッシュ破棄（更新のたびにインクリメント） |
| updated_at | 2025-12-01T10:00:00Z | 監査・問い合わせ対応 |
| deleted | false | 論理削除（誤削除復旧・監査に有効） |
実装でハマりやすいポイント（先回りチェック）
- キャッシュ問題：CDNやブラウザキャッシュで「更新したのに反映されない」が起きやすい。URLにバージョンを付ける、ETagで制御するなどの工夫が有効。
- サイズの多様性：ヘッダーの小アイコン、プロフィール詳細の大画像など用途が複数。アップロード時に複数サイズ（例：48px/96px/240px/480px）を生成しておくと表示が安定。
- セキュリティ：画像ファイルは攻撃ベクトルになり得る。MIME type の検証、拡張子だけに頼らない判定、ウイルススキャン、EXIF除去を検討。
- プライバシー：顔写真は個人情報として扱われやすい。利用目的、公開範囲、削除手続き、保持期間をポリシー化し、UIにも明記。
運用面の注意：UIが“使えるように見える”こと自体が混乱の元
External ID 外部構成テナントで写真が非対応だと、管理者や利用者は「選べるのに使えない」状態に遭遇します。Microsoft Q&A でも、選択肢が表示されること自体が混乱の原因になり得る旨が議論されています。
運用でのダメージを最小化するため、次のような“先回り”が効果的です。
- 管理者向け運用手順に「External IDではポータルからプロフィール画像は設定できない」を明記
- ヘルプデスク向けFAQに「仕様」「代替案（B2B/自前管理）」をテンプレ化
- 自社アプリでプロフィール編集画面を持つなら、写真機能もそこに寄せて“一貫した体験”にする
よくある質問
ポータルで失敗するだけで、Graph APIならアップロードできますか？
External ID 外部構成テナントでは「プロフィール画像アップロード自体が非対応」という回答が示されているため、ポータルだけでなく、標準的なアップロード経路（Graph含む）に期待するのはリスクがあります。加えて、Azure AD B2C では Graph による写真更新が非対応である旨が明記されています。
メンバー/ゲストの種類を変えれば解決しますか？
External ID 外部構成テナントの前提では、ユーザー種別の切り替えで解決するケースは多くありません。写真の要件が強い場合は、テナント構成（外部構成テナントか、ワークフォース/B2Bか）を見直すのが近道です。
“どうしてもEntraに寄せたい”場合の落としどころは？
おすすめは「認証は External ID に寄せるが、プロフィール体験（画像を含む）はアプリに寄せる」です。External ID はサインアップ時に属性収集ができるので、画像そのものではなく、アプリ内の画像キーやURLなど最小限の参照情報を扱い、本人確認・同意・削除も含めてアプリのポリシーで完結させると運用が安定します。
まとめ：External IDは“社内ディレクトリの延長”ではなく“アプリ中心”で設計する
Microsoft Entra External ID（外部構成テナント）でプロフィール画像のアップロードが失敗する場合、原因は設定不足ではなく、サービスの設計目的に起因する仕様制限である可能性が高いです。プロフィール画像が要件に入るなら、最初に「ワークフォース/B2Bに寄せるか」「External IDのままアプリで画像を持つか」を決めることで、遠回りのトラブルシュートを避けられます。
コメント