Microsoft Entra ID（旧Azure Active Directory）の条件付きアクセスを使うと、「特定ユーザーは職場の固定IPからだけサインイン可能」「社外（自宅・モバイル回線など）からのサインインはブロック」を実現できます。つまずきやすい“IP range（範囲）”の正しい入れ方、公開IPの確認方法、アプリ単位での適用、事故を防ぐテスト手順まで、運用目線でまとめます。
「職場の固定IPからのみログイン」をEntra IDで実現する考え方
条件付きアクセス（Conditional Access）は、サインインの条件（ユーザー・アプリ・端末状態・場所・リスクなど）に応じて、アクセスを許可したりブロックしたりできる仕組みです。固定IPを持つ職場回線がある場合は、「職場ネットワークの出口として観測される公開IP」を条件にして、社外からのサインインを止めるのが王道です。
ポイントは、職場を「許可する条件」として扱うよりも、「職場以外をブロック」として組む方がミスが少ないことです。職場のIPをNamed location（名前付き場所）として登録し、ポリシー側では「Any location を対象にして、職場のNamed locationを除外」→「Block」という形にすると、意図通り「職場以外が止まる」構成になります。
条件付きアクセスで指定するIPは「社内端末のIP」ではない
最初につまずきやすいのがここです。条件付きアクセスの「場所 / IP」は、社内LANの端末IP（10.xや192.168.xなど）ではありません。Entra IDがサインインを受け取るときに見える“送信元IP”、つまりインターネットに出るときの公開（グローバル）IPを使います。
| 項目 | 例 | 条件付きアクセスに使える？ | なぜ |
|---|---|---|---|
| プライベートIP（端末の社内IP） | 10.0.0.10 / 192.168.1.50 / 172.16.0.20 | 使えない | インターネット上で重複する前提のアドレスで、Entra ID側では見えない（NATで置き換わる） |
| 公開IP（職場回線の出口IP） | （例）203.0.113.10 | 使う | Entra IDのサインインログに「IP address」として記録され、場所条件の判断材料になる |
| VPN接続時の出口IP | （例）VPNゲートウェイの公開IP | 状況により使う | リモート端末がVPN経由で社内に出る設計なら、サインインはVPNの出口IPとして観測される |
| SASE/プロキシの出口IP | （例）クラウドプロキシのIPレンジ | 状況により使う | 全通信をクラウドプロキシに集約している場合、職場回線ではなくプロキシの出口IPが見えることがある |
社内端末がどれだけ固定IP（DHCP予約など）でも、インターネットに出る瞬間にNAT（変換）されるため、Entra IDが見るのは“変換後”の公開IPです。なので、条件付きアクセスで「職場の固定IP」を指定する場合の“固定IP”とは、回線契約（ISP）側で固定されている公開IPを意味します。
公開IPの調べ方：最短で確実に確認する手順
公開IPの把握方法はいくつかありますが、運用で失敗しないためには「一時的に見えたIP」ではなく「将来も変わらない契約上の値」を押さえるのが重要です。さらに、拠点に冗長回線や複数出口（FW/プロキシ/SD-WANなど）があると、外に出るIPが1つとは限りません。
手軽な確認（その場の出口IPを知る）
- 職場ネットワークにつないだ端末で、検索エンジンに「what is my IP」と入力して表示されたIPを確認する
- ブラウザの拡張機能やIP確認サイトでもよいが、まずはシンプルな方法でOK
ただしこの方法は、当日のルーティングやプロキシ経由状況によって結果が変わる場合があります。「表示されたIP＝必ず固定」ではありません。
確実な確認（条件付きアクセスに登録すべき固定IPを確定する）
- ISPとの契約書・開通資料・会員ページなどで、固定IP（または固定IPレンジ）として割り当てられている値を確認する
- 社内のFW/ルーター（インターネット境界機器）の設定画面で、WAN側IP（もしくは上流から払い出されるIP）を確認する
- Entra管理センターのサインインログで、職場から実際にサインインしたときの「IP address」を確認する（後述）
| 確認観点 | チェック内容 | 見落とすと起きがちなこと |
|---|---|---|
| 出口が1つか | 回線が複数・FWがHA・SD-WAN・プロキシ有無 | たまに別IPで出てしまい「職場なのにブロック」される |
| IPv6が有効か | 端末がIPv6で外に出る設計か（デュアルスタック等） | IPv4だけ登録していても、IPv6経由のサインインが想定外に通る/止まる |
| プロキシ経由か | HTTP/HTTPSがクラウドプロキシやオンプレプロキシを通るか | 「職場IP」ではなく「プロキシの出口IP」が見えてしまう |
| VPNの利用有無 | リモート端末がVPN経由で社内から出るか、スプリットトンネルか | 在宅・出先からサインインできなくなり業務停止（想定外） |
「他ネットワークと重複しないの？」という不安への答え
公開IP（グローバルIP）は、通常インターネット全体で重複しないよう管理・運用されています。つまり「同じ数字帯が他社にもあるのでは？」という不安は、“あなたの回線の出口として観測される公開IP”を正しく掴めていれば基本的に問題になりません。
ただし例外的に、固定IP契約ではなく共有型（CGNAT等）のサービスだと、同じ公開IPを複数契約者で共有することがあります。今回の前提が「職場の回線に固定（静的）IPがある」なら、まずはISPが提示する固定IP（または固定IPレンジ）を基準に設定しましょう。
「range（範囲）」入力の正体：CIDRで書けるから
条件付きアクセスのNamed locationでIPを登録する際に「範囲（range）」を求められるのは、1つのIPだけでなく、複数IP（レンジやCIDR）をまとめて扱えるためです。固定IPが1つでも、CIDR表記で「その1個だけ」を表現できます。
固定IPが1つだけの場合
IPv4が1つだけなら、/32を付けます。これは「そのIPだけ」という意味です。
203.0.113.10/32複数IPが割り当てられている場合
ISPからCIDRが提示されているなら、それをそのまま登録するのが最も安全です。CIDRが分からず「開始～終了」で提示される場合は、レンジとして登録できるケースもあります（画面仕様はテナントやUI更新で変わることがあります）。
| 状況 | 入力例（ドキュメント用の例） | 意味 | よくある使いどころ |
|---|---|---|---|
| 固定IPが1つ | 203.0.113.10/32 | 1個のIPv4のみ | 小規模オフィス、単回線 |
| 固定IPが複数（CIDRで提示） | 203.0.113.8/29 | 203.0.113.8～203.0.113.15（8個） | 複数グローバルIP、FWで用途分け |
| 固定IPが複数（非連続） | 198.51.100.10/32 198.51.100.25/32 | 離れたIPを個別登録 | 回線追加、経路変更で出口が複数 |
| IPv6も制御したい | 2001:db8:1234::/48（例） | IPv6レンジ | IPv6が有効な拠点・端末が多い |
「/32って何？」となりがちですが、難しく考える必要はありません。固定IPが1つなら“IP/32”と覚えてしまうのが一番早いです。
Named location（名前付き場所）に職場の公開IPを登録する
条件付きアクセスでは、まず職場のネットワークを「Named location」として定義しておくと運用が楽になります。拠点が増えたときも、ポリシーを大量に触らずにNamed locationだけ更新できるからです。
作成手順（基本）
- Entra管理センターで Conditional Access を開く
- Named locations を開く
- 新規作成で「IP ranges location（IP範囲）」を選択する
- 分かりやすい名前（例：Office-Network）を付ける
- 職場の公開IP（または公開IPレンジ）を登録する
- 必要に応じて「信頼済み場所（Trusted）」の扱いを検討する
命名と運用のコツ
Named locationは後から見返すことが多いので、名前に拠点情報と回線種別を含めると事故が減ります。
- Office-Tokyo-FixedIP（拠点＋固定IP）
- Office-Osaka-BackupLine（バックアップ回線）
- Office-Proxy-Egress（プロキシ出口）
| 設定項目 | 推奨の考え方 | 理由 |
|---|---|---|
| 登録するIP | 職場の公開IP（WAN側） | Entra IDが判断できるのは公開IP。プライベートIPは一致しない |
| IPv6 | 拠点でIPv6が使われるならIPv6も登録 | IPv4だけだと抜け道・誤ブロックの原因になる |
| 信頼済み場所 | 用途を理解してから設定 | MFAの挙動など他の制御と絡むことがあるため、安易にオンにしない |
「職場以外をブロック」する条件付きアクセスポリシーの作り方
ここからが本題です。狙いは「職場のNamed location以外からのサインインをブロック」です。構成はシンプルですが、Include/Excludeの組み方を間違えると“想定と逆”になるので、型として覚えるのが安全です。
ポリシーの基本形（推奨）
考え方は「全場所を対象にして、職場だけ除外し、ブロック」です。
| 項目 | 設定例 | 意図 |
|---|---|---|
| Users | Include：制限したいユーザー/グループ Exclude：緊急用（ブレークグラス） | 誤設定で全員ロックアウトしないための保険 |
| Target resources（Cloud apps） | All cloud apps もしくは特定アプリ | 全体にかけるか、アプリ単位にするかを決める |
| Conditions / Locations | Include：Any location Exclude：Office-Network（Named location） | 職場以外を対象にする |
| Grant | Block access | 社外を確実に止める |
| State | 最初は Report-only → 検証後に On | いきなり本番適用しない |
作成手順（実務向け）
- Conditional Access の Policies で新規ポリシーを作成する
- Users：対象ユーザー（または対象グループ）をIncludeに入れる
- Exclude：緊急用（ブレークグラス）アカウントを除外する
- Target resources（Cloud apps）：まずは影響範囲を小さくするなら特定アプリから開始する
- Conditions > Locations：IncludeをAny、Excludeに職場Named locationを指定する
- Grant：Block access
- StateをReport-onlyにして保存する
「Includeに職場を入れてBlock」だと、職場がブロック対象になってしまいます。職場を許可したいなら、“職場以外をブロックするために、職場をExcludeに入れる”が基本形です。
ブレークグラス（緊急用）アカウントを除外する理由
条件付きアクセスは強力な分、設定ミスの影響も大きくなります。たとえば職場IPを間違えたり、拠点の出口が切り替わったりすると、正しいユーザーでもサインインできなくなります。そんなときに復旧できるよう、緊急用アカウントを除外しておくのが定石です。
- 普段は使わない
- 強固なパスワード管理と監査（サインインが発生したら即検知）
- 運用ルールを決めて、定期的に動作確認する
アプリ単位で「職場IP以外はブロック」できる？
可能です。条件付きアクセスは、ポリシーごとに対象アプリ（Cloud apps / Target resources）を選べます。つまり「Microsoft 365は職場IPのみ」「一部の業務SaaSだけ職場IPのみ」といった分離運用ができます。
アプリ単位にするメリット
- 段階導入がしやすい（影響範囲を小さく始められる）
- 業務上、社外アクセスが必要なアプリは対象外にできる
- “本当に守りたいアプリ”にだけ強い制限を掛けられる
よくある対象アプリの例
| 目的 | 対象にしやすい例 | 補足 |
|---|---|---|
| 社内限定のデータを守りたい | SharePoint / OneDrive / Exchange Online | 情報漏えい対策として“社外からの閲覧”を止める設計でよく使う |
| 特定SaaSを社内限定にしたい | エンタープライズアプリ（SAML/OIDC） | アプリ単位にできるのが条件付きアクセスの強み |
| まずは小さく試したい | テスト用に影響の少ないアプリ | Report-onlyでログを見ながら詰めると安全 |
「All cloud apps」にすると、Microsoft 365だけでなく、連携している全SaaSに影響します。最初はアプリ単位で始め、運用が固まってから全体へ広げると失敗が減ります。
確認の近道：サインインログで“Entra IDが見ているIP”を確かめる
「what is my IP」で見えるIPと、Entra IDが記録するIPが一致するとは限りません（プロキシ、VPN、回線切替など）。確実にするなら、Entraのサインインログに出るIPを正として扱うのが最短です。
チェック手順
- 職場ネットワークから、制御対象ユーザーでサインインを実行する
- Entra管理センターでサインインログを開き、該当サインインを探す
- ログの「IP address」を確認する
- そのIPが、Named locationに登録したIP（またはレンジ）に含まれているか確認する
ここで一致しない場合は、次のような原因が多いです。
- 端末がVPNを張っていて、VPN出口IPになっている
- プロキシ経由でサインインしていて、プロキシの出口IPになっている
- 回線冗長やSD-WANで出口が切り替わり、別の公開IPで出ている
- IPv6経由になっていて、IPv4だけ登録している
テストと段階展開：いきなり「On」にしないための実務手順
固定IP制限は、うまくいくと強力ですが、ミスると業務停止に直結します。公開IPを登録して終わりではなく、検証から本番化までを“型”にしておくのが安全です。
推奨の進め方
- テスト用ユーザー/グループを用意し、まずはその範囲で適用する
- ポリシーはReport-onlyで作成し、想定通りブロックされるかログで確認する
- 職場（許可されるはずの場所）と社外（ブロックされるはずの場所）の両方でテストする
- 想定外の通信経路（VPN/プロキシ/モバイル回線）でも結果を確認する
- 問題がなければ対象グループを広げ、最後にポリシーをOnにする
確認ポイント（ログの見方）
- 社外からのサインインが、ポリシーによりブロックされているか
- 職場からのサインインが、ブロックされず成功しているか
- 意図しないユーザーまで影響していないか（Include/Excludeの設定）
- 想定していないIPが“職場”として扱われていないか
よくあるつまずきポイントと対処法
プライベートIPを入れてしまう
対処：10.x、172.16-31.x、192.168.xはプライベートIPです。条件付きアクセスは公開IPで判定するため、職場回線の出口IP（ISPが割り当てた固定IP）を登録します。
「職場をInclude」にしてしまい、意図と逆になる
対処：職場以外を止めたい場合は、LocationsでInclude：Any、Exclude：職場Named locationが基本形です。最終的にGrantでBlockにすることで「社外だけ止まる」になります。
職場なのにブロックされる（出口IPが複数ある）
対処：回線冗長や機器切替で出口IPが変わることがあります。サインインログで職場内の複数端末・複数時間帯のIPを確認し、必要な公開IPをNamed locationに追加します。バックアップ回線がある拠点は、平常時と切替時の両方をテストしておくと安心です。
在宅勤務や出張ができなくなる
対処：「職場IP以外はブロック」は“社外からのサインインを原則禁止”にする強い制御です。在宅勤務が必要なら、次のいずれかで設計を見直します。
- 在宅は社内VPN必須にし、VPN出口を職場IPに寄せる（社外でも職場IPとして扱える）
- 対象アプリを限定し、社外でも必要なアプリは対象外にする
- 職場以外でも許可すべき“例外拠点”をNamed locationとして別途定義する
IPv6が絡んで挙動が安定しない
対処：拠点や端末がIPv6で外に出る場合、IPv4だけ登録していると意図しない結果になりがちです。サインインログでIPv6が記録されているなら、IPv6レンジもNamed locationに登録して整合を取ります。
「固定IPのはずなのに変わる」ように見える
対処：固定IPは“契約として固定”であることが重要です。実際には、プロキシ・VPN・回線切替・上流の構成変更で「外から見えるIP」が変わることがあります。ISPの提示値を基準にしつつ、サインインログを合わせて確認し、ネットワーク担当と出口構成をすり合わせるのが確実です。
運用で差が出るポイント：拠点追加・回線変更・災害時の想定
固定IP制限は“設定して終わり”ではありません。回線の変更や拠点追加があると、突然全員がサインインできなくなる可能性があります。運用面で次の3つを押さえておくと、長期的に安定します。
変更管理を前提にする
- Named locationを「拠点ごと」に分けて管理する（1つに詰め込まない）
- 回線変更時の手順に「Named locationの更新」「ログ確認」を入れる
- ポリシー名にも目的を明記する（例：Block-Outside-Office-For-FinanceApp）
BCP（災害・停電・回線断）を想定する
- 職場回線が落ちたとき、バックアップ回線の出口IPが登録されているか
- 全社が在宅へ切り替わる可能性があるなら、例外運用（VPN必須化など）を決めておく
- ブレークグラスの利用手順と連絡フローを明文化する
「固定IP制限だけ」に依存しない
固定IP制限は強いコントロールですが、セキュリティは多層防御が基本です。たとえば、重要アプリにはMFA、端末準拠（コンプライアンス）、サインインリスクなど他条件も組み合わせると、より現実的な防御になります。逆に、固定IP制限だけに寄せすぎると、在宅やモバイルの利便性を大きく損なうため、業務要件とバランスさせるのが成功のコツです。
まとめ：公開IPをNamed locationに登録し、職場以外をブロックする
Entra IDの条件付きアクセスで「職場の固定IPからのみログイン」を実現する要点は、次の通りです。
- 指定すべきIPは社内端末のプライベートIPではなく、職場回線の公開IP（出口IP）
- 固定IPが1つならx.x.x.x/32で登録できる
- Named locationに職場IP（必要ならIPv6や複数出口分も）を登録する
- ポリシーはAny locationを対象にして職場をExcludeし、GrantでBlockする
- アプリ単位の制御も可能。最初はReport-only＋テストユーザーで安全に展開する
「rangeに何を入れるべき？」「公開IPってどれ？」「他と重複しない？」といった不安は、サインインログで“Entraが見ているIP”を確認し、ISPの提示する固定IP（レンジ）と突き合わせることで解消できます。運用まで含めて設計すれば、社外からの不正サインインを大幅に減らしつつ、業務影響も最小化できます。
コメント