1. 主要ページへ移動
  2. メニューへ移動
  3. ページ下へ移動

QES ブログ

記事公開日

【Microsoft Entra】「アクセス権の申請・承認」を自動化!エンタイトルメント管理入門

  • このエントリーをはてなブックマークに追加

この記事のポイント

Microsoft Entra ID Governanceの「エンタイトルメント管理」について、基本概念から必要な要件、具体的な機能、代表的な運用シナリオまでをご紹介します。

  • アクセス権を「アクセスパッケージ」単位で受け渡せる:
    業務に必要なグループ・アプリケーション・SharePoint Onlineサイトをひとまとめにし、申請・承認・有効期限のルールに沿って自動的に付与できます。
  • カタログ・アクセスパッケージ・ポリシーの3つで構成される:
    カタログが管理と委任の単位、アクセスパッケージが渡すリソースの束、ポリシーが「誰が・どうやって・いつまで」を定めるルールです。
  • Microsoft Entra ID P2 または Microsoft Entra ID Governance が必要:
    基本機能はMicrosoft Entra ID P2で動作し、自動割り当てポリシーなどの高度な機能はMicrosoft Entra ID Governanceが前提になります。
  • 社外ユーザーへの受け渡しも同じ仕組みで扱える:
    「接続されている組織」を設定すれば、外部パートナーからの申請を受け付け、承認と同時にディレクトリへの招待とアクセス付与を自動化できます。

新しいプロジェクトが始まる度に参加メンバーへ必要なアクセス権を付与したり、人事異動や入社が発生する度に対象アカウントへ必要なアクセス権を付与したり…
申請はメールやチャットで行い、承認は関係者間の調整で個別に済まされ、アクセス権の付与はIT部門が手作業で行う。
そんな手間のかかる権限設定作業に心当たりはありませんか?

アクセス権の申請・承認・付与をこういった形で運用していると、次のような課題が生じます。

  • 必要な権限を一式でまとめて渡せない:
    業務に必要なグループ・アプリケーション・サイトを、担当者が1件ずつ依頼し、管理者が1件ずつ付与する必要がある
  • 申請と承認の流れが属人的になる:
    何を申請すればよいか本人が分からず、誰が承認すべきかもその都度の調整になり、IT部門への問い合わせが集中する
  • 期限付きでの受け渡しが定着しない:
    申請時にアクセス権の期限を設定するという考え方が定着せず、一時的に渡したつもりのアクセス権が、いつまでも残り続けてしまう

Microsoft Entra ID Governanceの「エンタイトルメント管理」は、このアクセス権の受け渡しそのものを仕組み化する機能です。
本記事では、エンタイトルメント管理の基本概念・構成要素・必要なライセンスや権限・具体的な機能・代表的な運用シナリオをご紹介します。

Microsoft Entra エンタイトルメント管理とは?

エンタイトルメント管理は、グループ・アプリケーション・SharePoint Onlineサイト等へのアクセス権付与を一元的に管理する機能です。
アクセス権の要求ワークフロー・割り当て・レビュー・有効期限の管理を、社内のIDだけでなく他組織のIDに対しても自動化できます。

ポイントは、アクセス権を1件ずつ手作業で付与するのではなく、業務に必要なリソースをまとめた「アクセスパッケージ」という単位で扱う点にあります。
誰が申請できるか、誰の承認が必要か、いつまで有効かというルールをあらかじめ決めておくことで、個別対応に頼らない一元的な運用へ切り替えられます。

【Point】エンタイトルメント管理とアクセスレビューの違い
Microsoft Entra ID Governanceには、エンタイトルメント管理とよく似た文脈で語られる「アクセスレビュー」という機能もあります。
エンタイトルメント管理は、アクセスパッケージを介した「申請・承認・付与」というアクセスの入り口を管理する仕組みで、付与したアクセス権には有効期限を設定でき、期限が来ると自動的に失効します。
一方アクセスレビューは、エンタイトルメント管理で付与したアクセス権に限らず、既存のグループメンバーシップやゲストユーザーなども含めた、既に付与されているアクセス権を定期的に点検し、「今も本当に必要か」を承認者に確認させたうえで、不要と判断されたアクセス権を取り消す仕組みです。
つまり、エンタイトルメント管理が「入り口の管理」、アクセスレビューが「棚卸し(出口の管理)」という役割分担になっており、アクセスパッケージのライフサイクル設定で両者を組み合わせて使うこともできます。

アクセスレビューの機能概要については以下の記事で詳しく解説していますので、こちらもあわせてご覧ください。

この「アクセスパッケージ」を理解するには、「カタログ」と「ポリシー」という2つの要素をあわせて押さえる必要があります。

エンタイトルメント管理を構成する3つの要素

エンタイトルメント管理は、「アクセスパッケージ」「カタログ」「ポリシー」という3つの要素で構成されています。
具体的な機能を見ていく前に、この3つの関係を整理していきましょう。

中心にあるのは「アクセスパッケージ(必要なリソースが1つに束ねられたパッケージ)」という考え方です。
アクセスパッケージは、グループ・アプリケーション・SharePoint Onlineサイトといったリソースを、それぞれの役割(メンバー・所有者など)付きで束ねたものです。
たとえば「グループAのメンバー権限」とそのメンバーがアクセスする「アプリBの利用権限」をまとめて1つのアクセスパッケージにする、といった形です。

アクセスパッケージには、1つ以上の「ポリシー(アクセス権を利用・申請するための条件)」を設定します。
ポリシーは、誰がこのアクセスパッケージを要求・利用できるか、承認が必要か、いつまで有効かを定めるルールです。
たとえば同じアクセスパッケージに対して、「社内のユーザー向けのポリシー」と「接続されている組織(社外)のユーザー向けのポリシー」を別々に用意し、内部・外部それぞれに異なる条件でアクセスを許可する、という使い方が可能です。

そして、アクセスパッケージとポリシーをひとまとめにし、管理する単位が「カタログ(アクセス権の管理単位、プロジェクトや部署/チームといった枠組み)」です。
1つのカタログには、複数のアクセスパッケージとそれに内包するリソース群、複数のポリシーを含めることができ、1つの管理単位の中で多様なアクセスの受け渡し方をまとめて扱えます。

これら3つの要素間における関係性をまとめると、以下の図のような形になります。

カタログの中に2つのアクセスパッケージがあり、一方はグループとアプリケーション、もう一方はSharePointサイトのリソースを束ねている。左のアクセスパッケージには社内向け・社外向けの2つのポリシーが、右のアクセスパッケージには1つのポリシーが紐づいていることを示す構成図

【Point】カタログ・アクセスパッケージ・ポリシーを分けて考える理由
アクセスパッケージは「何に対するアクセスか(リソースの束)」、ポリシーは「誰が・どうやって・いつまでアクセスできるか(条件)」、カタログは「それらをまとめて管理・委任するための単位」を、それぞれ表します。
この3つを分けることで、1つのアクセスパッケージに複数の入り口(ポリシー)を用意しつつ、部門やプロジェクトごとにカタログを分割して、各カタログの管理を別々の担当者に委任する、という運用ができます。

エンタイトルメント管理の基本要件

エンタイトルメント管理の利用には、一定のライセンスと管理権限が必要です。導入を検討する際は、事前に以下の要件を確認しておく必要があります。

利用に必要なライセンス

エンタイトルメント管理を利用するには、Microsoft Entra ID P2 または Microsoft Entra ID Governance のライセンスが必要です。
アクセスパッケージの作成やユーザーによるアクセス要求といった基本機能はMicrosoft Entra ID P2でも動作しますが、自動割り当てポリシーなどの高度な機能はMicrosoft Entra ID GovernanceまたはMicrosoft Entra Suiteが前提になります。

ライセンス エンタイトルメント管理で利用できる範囲
Microsoft Entra ID P2 アクセスパッケージの作成、ユーザーによるアクセス要求、グループ・アプリケーション・SharePointサイトのリソース割り当て、多段階承認、有効期限の設定など、基本的な機能
Microsoft Entra ID Governance 上記に加えて、自動割り当てポリシー、Microsoft Entra ロール(プレビュー)の管理、カスタム拡張機能、検証済みIDとの統合などの高度な機能
Microsoft Entra Suite Microsoft Entra ID Governanceと同等のID Governance機能を含む、より包括的なライセンス

【Point】必要なライセンスの「種類」と「数」の決まり方
種類は、使う機能によって決まります。ユーザーが自分でアクセスパッケージを申請する運用であればMicrosoft Entra ID P2の範囲で動作し、自動割り当てポリシーのような高度な機能を使う場合は、その機能を使う範囲についてMicrosoft Entra ID Governance(またはMicrosoft Entra Suite)が必要です。
は、実際に使った人数ではなく、その機能を使える状態にした人数で決まります。
たとえば、全従業員2,000人が申請できるアクセスパッケージを公開した場合、実際に申請したのが150人であっても、2,000人分のライセンスが必要です(申請させるだけの運用であれば、Microsoft Entra ID P2の範囲で動作します)。
一方、営業部門の350人に自動割り当てポリシーでアクセスを付与する場合は、その350人分についてMicrosoft Entra ID Governanceが必要になります。
なお、ライセンスは対象者ひとりずつに割り当てる必要はなく、必要な数を保有していれば問題ありません。

ここまでは社員(メンバーユーザー)に必要なライセンスの話です。取引先などの社外ユーザーについては、これとは別の考え方が用意されています。

前提として、エンタイトルメント管理で社外ユーザーにアクセスを渡す場合、そのユーザーはMicrosoft Entra B2Bの仕組みで自社のディレクトリにゲストとして登録されます
そのうえで、そのゲストに対してどこまでの機能を使うかによって、追加の課金が発生するかどうかが決まります。

具体的な課金方式は以下の表の通りです。簡潔にまとめると、「P2に含まれる範囲の基本的な動作をゲストに適用する場合は追加課金はない」「高度な機能をゲストに適用する場合は毎月の利用ユーザー数に応じた追加課金が発生する」となります。

ゲストに対して使う機能 追加の課金
Microsoft Entra ID P2 に含まれる範囲
(アクセスパッケージの申請・承認・有効期限など、本記事で紹介している基本的な操作)
発生しない。Azureサブスクリプションのリンクも不要
Microsoft Entra ID Governance 固有の機能
(自動割り当てポリシー、スポンサーによる承認、カスタム拡張機能、検証済みIDとの統合など)
ゲスト向けアドオンとして、月間アクティブユーザー(MAU)単位の従量課金が発生する。この課金にはAzureサブスクリプションのリンクが必要

MAU課金は、その月に1回以上ガバナンス機能の対象となったゲストの人数で計算されます。
同じゲストが1か月のうちに複数の操作の対象になっても課金は1人分で、前月に割り当てたアクセスを保持しているだけで当月に何の操作もなければ、その月は課金されません。なお、このゲスト向けアドオンの課金には無料枠がありません。

つまり、社員は「使える状態にした人数」をあらかじめ数え、ゲストは「その月に実際にガバナンス機能の対象になった人数」を後から支払う、という違いがあります。
社外との協業を想定する場合は、この2つの数え方が併存する点を押さえておくとよいでしょう。

詳細は、Microsoft公式ドキュメントに実例を交えた解説が掲載されています。こちらもご確認ください。

管理に必要な権限(ロール)

エンタイトルメント管理の管理権限には、2つの種類があります。
1つはテナント全体に対するMicrosoft Entra IDのディレクトリロール、もう1つはエンタイトルメント管理の中だけで有効な固有のロールです。
後者を使うことで、テナント全体の管理権限を持つディレクトリロールを付与せずに、管理者以外の担当者へ管理を委任できます。
なお、エンタイトルメント管理のロールには、テナント全体に適用されるもの(カタログ作成者、接続された組織管理者)と、カタログごとに割り当てるもの(カタログ所有者、アクセスパッケージマネージャーなど)があります。

ロール 種別 概要
グローバル管理者 Entra ID ディレクトリロール テナント全体の管理者。エンタイトルメント管理のすべての側面を作成・管理できる
ID ガバナンス管理者 Entra ID ディレクトリロール ID ガバナンス機能の管理を担うロール。エンタイトルメント管理のすべての側面を作成・管理できる
カタログ作成者 エンタイトルメント管理のロール 新しいカタログを作成できる。作成したカタログの最初の所有者になる
カタログ所有者 エンタイトルメント管理のロール カタログ内のアクセスパッケージやリソースを編集・管理できる
カタログリーダー エンタイトルメント管理のロール カタログ内の既存のアクセスパッケージを参照できる(編集・管理は不可)
アクセスパッケージマネージャー エンタイトルメント管理のロール カタログ内の既存リソースから新しいアクセスパッケージを作成し、管理できる
アクセスパッケージ割り当てマネージャー エンタイトルメント管理のロール 既存のアクセスパッケージへのユーザーの割り当て・削除ができる(パッケージ自体の作成・編集は不可)
接続された組織管理者 エンタイトルメント管理のロール 接続されている組織(外部の提携先ディレクトリ)を作成・管理できる

このように、管理者以外の担当者にも段階的に権限を委任できる仕組みが用意されています。
IT部門がすべてのアクセス管理を抱え込むのではなく、各部門の担当者にカタログ単位で管理を任せる、という運用が可能です。

エンタイトルメント管理の具体的な機能一覧

エンタイトルメント管理では、アクセスパッケージの作成から、ユーザーによる要求、承認、割り当ての確認まで、一連の操作をMicrosoft Entra管理センターで行えます。
アクセスパッケージを作成してから実際に使われるまでの流れに沿って、主な機能を紹介します。

なお、Microsoft Entra管理センターでは、左側のメニューは日本語で表示される一方、エンタイトルメント管理の設定画面は英語で表示されます。
本記事でも画面と突き合わせやすいよう、設定画面のタブ名・項目名は画面上の英語表記を使い、初出で日本語の意味を併記しています。
利用者側のマイアクセスポータルは日本語で表示されるため、こちらは日本語表記のまま記載しています。

アクセスパッケージの作成

アクセスパッケージの作成は、Microsoft Entra管理センターの「ID ガバナンス」>「エンタイトルメント管理」>「アクセス パッケージ」から行います。
操作するには、ID ガバナンス管理者などの管理者ロールか、カタログ所有者・アクセスパッケージマネージャーのいずれかの権限が必要です。
まず「Basics」タブ(基本情報)で、名前(Name)・説明(Description)と、このアクセスパッケージを所属させるカタログ(Catalog)を指定します。

アクセスパッケージ作成画面の「Basics」タブ。NameとDescriptionの入力欄と、所属させるカタログを選択するCatalogのドロップダウンが表示されている

次に「Resource roles」タブ(リソースとロール)で、このパッケージに含めるリソースを追加します。
「Groups and Teams」(グループとチーム)、「Applications」(アプリケーション)、「SharePoint sites」(SharePoint Onlineサイト)といった種別ごとにリソースを選び、それぞれに付与するロール(メンバー・所有者など)を指定します。

アクセスパッケージ作成画面の「Resource roles」タブ。Groups and Teams、Applications、SharePoint sites、Azure Resourcesなど、追加できるリソース種別のボタンが並んでいる

要求ポリシーとライフサイクル(有効期限)の設定

ポリシーの設定は、「Requests」タブ(要求)と「Lifecycle」タブ(ライフサイクル)で行います。

「Requests」タブでは、まず「Who can get access」(誰がアクセスを取得できるか)で対象を選びます。選択肢は次の3つです。

  • For users, service principals, and agent identities in your directory:
    自社ディレクトリ内のユーザーを対象にする
  • For users not in your directory:
    接続されている組織など、自社ディレクトリ外のユーザーを対象にする
  • None (administrator direct assignments only):
    ユーザーからの要求は受け付けず、管理者による直接割り当てだけを認める

1つ目を選んだ場合は、さらに「Select specific scope」(対象範囲)で、「Specific users and groups」(特定のユーザーとグループ)、「All members (excluding guests)」(すべてのメンバー、ゲストを除く)、「All users (including guests)」(すべてのユーザー、ゲストを含む)などから範囲を指定します。

あわせて「Who can request access」(誰が要求できるか)で、要求できる人を「Self」(本人)、「Admin」(管理者)、「Manager」(マネージャーによる代理申請)、「Users in your directory (Preview)」(ディレクトリ内のユーザーとグループ)の4つから選びます。
このうち「Admin」は、管理者が常にユーザーを割り当てられるため、オフにできません。

ポリシーの「Requests」タブ。Who can get accessとして、ディレクトリ内のユーザー・ディレクトリ外のユーザー・管理者の直接割り当てのみという3つの選択肢が並び、その下にSelect specific scopeの具体的な範囲の選択肢が表示されている

同じ「Requests」タブの下部にある「Approval」(承認)で、承認の設定を行います。
承認を必須にするか(Require approval)、承認を何段階にするか(How many stages、最大3段階)、誰を承認者にするかを指定します。
承認者には特定のユーザーだけでなく「Manager as approver」(要求者のマネージャー)を指定することもでき、マネージャーが不在の場合に備えた代替の承認者(Fallback)も設定できます。
承認の期限(Decision must be made in how many days?)もここで決めます。設定できるのは最大14日です。

ポリシーのApproval(承認)設定。Require approvalによる承認の要否、How many stagesによる承認の段階数、承認者としてManager as approverを指定した状態、Fallback、判断までの日数が表示されている

「Lifecycle」タブでは、「Expiration」(有効期限)で割り当ての期限を設定します。
日数での指定(Number of days、例:365日)のほか、特定の日付(On date)、時間単位(Number of hours)、期限なし(Never)も選べます。
「Extensions」(延長)では、ユーザー自身が期間の延長を要求できるか(Allow users to extend access)、延長にも承認を必要とするか(Require approval to grant extension)を設定します。
この有効期限の設定が、アクセス権が期限なく残り続けることを防ぐ仕組みになります。

ポリシーの「Lifecycle」タブ。Expirationの有効期限の指定方法と日数、Extensionsのユーザーによる延長の許可と延長時の承認の要否、Access Reviewsの設定項目が表示されている

この「Lifecycle」タブには、有効期限に加えて「Require access reviews」(アクセスレビューが必要)という設定項目もあります。
これは、割り当てられたアクセスが今も業務上必要かどうかを、定期的に確認する「アクセスレビュー」という別機能と連携する設定です。
アクセスレビューの具体的な設定方法については以下の記事で詳しく解説していますので、こちらもご覧ください。

マイアクセスポータルからのアクセス要求

要求者は、「マイアクセスポータル」と呼ばれる画面から、自分が要求できるアクセスパッケージの一覧を確認し、そこからアクセスを要求します(画面の左メニューでは「マイ アクセス」と表示されます)。
パッケージを選ぶと、含まれているリソースの一覧や、自分自身の分として要求するのかを確認する画面が表示されます。

マイアクセスポータルのアクセスパッケージ一覧と、要求内容を確認するダイアログ。自分の分として要求するかの選択と、パッケージへのリンクをコピーするボタンが表示されている

ポリシーで要求者の理由入力を必須にしている場合は、続けて業務上の理由を入力する画面が表示されます。
一定期間だけアクセスを要求することもでき、ここで入力した理由は承認者が判断する際の材料になります。

マイアクセスポータルの要求入力画面。一定期間の要求にするかの切り替えと、業務上の正当な理由を入力するテキストエリア、要求を送信するボタンが表示されている

送信した要求の履歴やステータス(承認待ち・配信済みなど)も、同じポータルから確認できます。

要求の承認

承認が必要なポリシーの場合、承認者にはメールで通知が届き、マイアクセスポータルの「承認」画面に要求が表示されます。
承認者は要求元・要求日・期限を確認し、要求を開いて承認または拒否を選択します。
ポリシーで承認者の理由入力を必須にしている場合は、判断の理由も入力します。

マイアクセスポータルの承認画面。保留中の要求が1件表示され、要求されたパッケージ名・要求日・期限・要求元が一覧になっている

割り当ての確認

承認されると、アクセスパッケージがそのユーザーに割り当てられます。
管理者は、アクセスパッケージの「Assignments」画面(割り当て)から、誰にどの状態で割り当てられているかを確認できます。
正常に付与されていれば「Status」が「Delivered」(配信済み)となり、ポリシーで設定した有効期限にもとづく終了日も表示されます。

アクセスパッケージのAssignments画面。割り当てられたユーザーの状態がDeliveredとなり、適用されたポリシー名と終了日が表示されている

要求者側のマイアクセスポータルでも、「アクティブ」タブに割り当てられたアクセスパッケージが表示され、開始日と終了日を確認できます。
この時点で、パッケージに含まれるグループやアプリケーションへのアクセス権が実際に付与されています。

マイアクセスポータルのアクセスパッケージ一覧の「アクティブ」タブ。割り当てられたアクセスパッケージの開始日と終了日が表示されている

カタログとロールの管理

カタログの管理は、「ID ガバナンス」>「エンタイトルメント管理」>「カタログ」から行います。
カタログの画面では、そのカタログに含まれるリソース(グループ・アプリケーション・SharePoint Onlineサイト)の追加と削除、カタログ所有者やアクセスパッケージマネージャーの割り当て、そして外部ユーザーに対してこのカタログを有効にするかどうかの設定ができます。
外部ユーザーが要求できるのは、この「外部ユーザーに対して有効」がオンになっているカタログ内のアクセスパッケージに限られます。

ロールの委任は、カタログの「Roles and administrators」から行います。
カタログ所有者・カタログリーダー・アクセスパッケージマネージャー・アクセスパッケージ割り当てマネージャーを、それぞれ追加できます。
下の画面では、1人をカタログ所有者、もう1人をアクセスパッケージマネージャーとして割り当てています。

カタログのRoles and administrators画面。カタログ所有者とアクセスパッケージマネージャーがそれぞれ割り当てられ、ロール名が一覧に表示されている

代表的な運用シナリオ

実際にここまでの機能をどのように業務シーンで利用していくか、具体的な運用シナリオを数点ご紹介します。自社でどこから着手するかを考える際の参考にしてください。

業務シーン エンタイトルメント管理での実現方法
入社・異動のたびに発生する権限付与をなくしたい 部署や職種といった属性に応じて、必要なグループ・アプリケーション・サイトを自動割り当てポリシーでまとめて付与する。異動で属性が変われば、以前の部署のアクセスは自動的に外れる
※自動割り当てポリシーの利用には、対象者の人数分のMicrosoft Entra ID Governance(またはMicrosoft Entra Suite)が必要です
プロジェクト参加者に、必要な権限を自分で申請してもらいたい プロジェクトで使うリソースを1つのアクセスパッケージにまとめて公開し、参加メンバーがマイアクセスポータルから自分で申請する。承認者はプロジェクトの責任者に設定しておく
現場の権限管理をIT部門から各部門へ移したい 部門ごとにカタログを分け、各部門の担当者をカタログ所有者に任命する。IT部門は基盤の管理に専念し、日々の権限付与は現場で完結させる
協力会社のメンバーに、契約期間だけアクセスを許可したい 取引先を「接続されている組織」として登録し、申請用のリンクを共有する。承認されると自動的にゲストとして招待され、設定した有効期限が来ればアクセスも失効する

使い分けのポイント:すでに部署全員が対象になっているような恒常的なアクセスであれば、グループベースのライセンスや動的グループで足りるケースもあります。
「期間限定」「承認が必要」「組織をまたぐ」といった要素があるアクセスから、エンタイトルメント管理の活用を優先的に検討するとよいでしょう。

まとめ

本記事では、Microsoft Entra ID Governanceの機能である「エンタイトルメント管理」について、基本概念・構成要素から必要な要件、具体的な機能、代表的な運用シナリオまでをご紹介しました。
エンタイトルメント管理を導入することで、主に次の3つのメリットが期待できます。

  • アクセス権の一元管理:
    内部・外部を問わず、グループ・アプリケーション・SharePoint Onlineサイトへのアクセスを、アクセスパッケージという単位で一元的に管理できます。
  • 有効期限による自動的なアクセス解除:
    ポリシーで有効期限を設定することで、期限が来たアクセス権は自動的に失効し、不要な権限が残り続けるリスクを抑えられます。
  • 管理業務の委任:
    カタログ・ロールの仕組みにより、IT部門以外の担当者にもアクセス管理の一部を委任できます。

なお、本記事の内容は2026年9月時点の情報にもとづいています。機能やライセンス要件は今後変更される可能性があるため、最新の情報はMicrosoft公式ドキュメントもあわせてご確認ください。

次回のブログでは、エンタイトルメント管理の機能の中から、より詳細な設定や応用的な使い方を掘り下げて解説する予定です。

本記事は Microsoft Entra ID のガバナンス・権限管理に関する内容でした。関連するテーマは、QESブログの「Microsoft Entra ID Governance」カテゴリでもまとめて発信していますので、あわせてご覧ください。

QUICK E-Solutionsでは、AIを活用した業務効率化や、Microsoft Entra IDをはじめとした高度なセキュリティシステムの導入・設計をお手伝いしております。
それ以外でも様々なアプリケーションの開発・導入を行っております。提供するサービス・ソリューションにつきましては こちら に掲載しております。
システム開発・構築でお困りの問題や弊社が提供するサービス・ソリューションにご興味を抱かれましたら、ぜひ一度 お問い合わせ ください。

※このブログで参照されている、Microsoft、Microsoft Entra、Microsoft Entra ID、Microsoft Entra ID Governance、Microsoft Entra Suite、Microsoft Entra B2B、Microsoft 365、Microsoft Teams、SharePoint、SharePoint Online、Azureは、米国Microsoft Corporationの米国およびその他の国における商標または登録商標です。

  • このエントリーをはてなブックマークに追加

お問い合わせ

Contact

ご質問やご相談、サービスに関する詳細など、何でもお気軽にご連絡ください。下記のお問い合わせフォームよりお気軽に送信ください。

お問い合わせ

資料ダウンロード

Download

当社のサービスに関する詳細情報を掲載した資料を、下記のページよりダウンロードいただけます。より深く理解していただける内容となっております。ぜひご活用ください。

資料ダウンロード