top of page

委託先・SIer責任分界整理支援

Azure・Microsoft 365の運用責任を、契約・権限・証跡で説明できる状態へ

Azure、Microsoft 365、Microsoft Entra IDを利用する企業では、SIer、MSP、SOC、保守ベンダー、開発会社、クラウド運用代行会社との連携が欠かせません。

しかし、クラウド運用を外部に委託すると、次のような問題が起きやすくなります。

「どこまでがMicrosoftの責任で、どこからが自社の責任なのか」
「SIerが構築したAzure環境の運用責任は誰にあるのか」
「障害時の一次対応、原因調査、復旧判断、取引先報告は誰が行うのか」
「Entra IDの管理者権限を委託先に渡してよいのか」
「SOCは検知するだけなのか、初動対応まで行うのか」
「バックアップは取得しているが、復旧テストの責任者が決まっていない」
「契約書、SLA、運用手順書、実際の権限設定が一致していない」
「取引先チェックシートで“委託先管理”を聞かれたが、説明資料がない」

責任分界が曖昧なままでは、障害、情報漏えい、監査、取引先審査、契約更新の場面で説明ができません。

山崎行政書士事務所では、Azure、Microsoft 365、Entra IDを利用する企業向けに、委託先・SIer・MSP・SOC・保守ベンダーとの責任分界整理を支援します。

行政書士としての文書整理力と、Azureエンジニアとしての現場理解を組み合わせ、契約、権限、運用、ログ、証跡をつなぎ、情シス・法務・経営層が説明できるクラウド責任分界を整えます。

【お問い合わせボタン】
委託先・SIer責任分界を相談する

-post-ai-image-119079.png

責任分界は、契約書だけでは決まりません

AzureやMicrosoft 365の責任分界には、少なくとも4つの層があります。

・Microsoftと利用企業の責任分界
・利用企業とSIer、MSP、SOC、保守ベンダーの責任分界
・情シス、法務、経営層、現場部門の社内責任分界
・障害、インシデント、監査、取引先対応時の実務責任分界

Microsoft公式情報では、パブリッククラウドを評価する際には、クラウドプロバイダーが処理するセキュリティタスクと、利用者が処理するタスクを理解することが重要であり、責任範囲はSaaS、PaaS、IaaSなどのサービスモデルによって異なると説明されています。また、すべてのクラウド利用形態において、データとIDは利用者側が所有し、保護する責任を負う領域として示されています。

つまり、AzureやMicrosoft 365を利用しているからといって、すべてをMicrosoftやSIerに任せられるわけではありません。

特に、次の領域は委託元である企業側の説明責任が問われやすい領域です。

・データの分類と取扱い
・IDとアクセス権限
・管理者権限
・委託先アカウント
・外部共有
・バックアップ方針
・ログ取得方針
・障害時の判断
・インシデント時の報告
・取引先への説明
・監査証跡の提出
・再委託の把握
・契約終了時のデータ返還、削除、権限剥奪

責任分界整理とは、単に「甲の責任」「乙の責任」と書き分ける作業ではありません。

実際のAzure構成、Entra IDの権限、Microsoft 365の管理者ロール、ログ、運用手順、契約関連資料を照らし合わせ、「誰が、何を、いつ、どこまで実施し、どの証跡を残すのか」を明確にする作業です。

このような課題はありませんか

SIerに任せているが、何を任せているか説明できない

Azureの設計、構築、保守、監視、障害対応をSIerに依頼している。
しかし、契約書には「運用保守一式」としか書かれていない。

この状態では、障害時に次のような問題が起こります。

・一次切り分けは誰が行うのか
・Microsoftへのサポート問い合わせは誰が行うのか
・復旧判断は誰が行うのか
・バックアップから戻す判断は誰が承認するのか
・顧客や取引先への報告文は誰が作るのか
・原因調査レポートは誰が作成するのか
・再発防止策を誰が実装するのか
・費用負担や追加作業の扱いはどうなるのか

「SIerに頼んでいるから大丈夫」では、監査や取引先審査に耐えられません。
委託先に依頼している業務内容、権限、責任、証跡を整理する必要があります。

Azureの管理者権限が過剰になっている

構築時にSIerへサブスクリプション所有者権限を付与した。
保守ベンダーに全体管理者権限を渡した。
退職した担当者や契約終了した外部担当者の権限が残っている。

このような状態は、クラウド環境で非常に危険です。

Microsoft公式情報では、Azure RBACのベストプラクティスとして、ユーザーには職務に必要なアクセス許可のみを付与し、広範なスコープで広範なロールを割り当てることを避け、最小限の特権を付与することが推奨されています。また、特権管理者ロールの割り当て制限、PIMによるJust-In-Time特権アクセス、ユーザーではなくグループへのロール割り当ても推奨されています。

委託先・SIerの責任分界では、契約上の責任だけでなく、実際に付与されている権限を確認することが不可欠です。

MSP・SOC・保守ベンダーの役割が曖昧

SOCはアラートを検知するだけなのか。
MSPは復旧作業まで行うのか。
保守ベンダーは営業時間外に対応するのか。
SIerは設計責任を負うのか、構築後の運用責任も負うのか。

クラウド運用では、複数の委託先が関わることがあります。

・Azure構築SIer
・Microsoft 365導入ベンダー
・Entra ID設計ベンダー
・SOC
・MSP
・MDR事業者
・ネットワーク保守会社
・アプリ開発会社
・基幹システムベンダー
・ヘルプデスク委託先
・データセンター事業者
・クラウド請求代行事業者
・CSPパートナー

関係者が増えるほど、「誰が一次対応するのか」「誰が最終判断するのか」「誰が取引先へ説明するのか」が曖昧になります。

山崎行政書士事務所では、委託先ごとの役割、権限、作業範囲、連絡経路、証跡提出範囲を整理し、実務に使える責任分界表へ落とし込みます。

個人情報を扱う委託先管理が不安

AzureやMicrosoft 365で個人情報を扱う場合、委託先管理は情報セキュリティだけでなく、個人情報保護の観点でも重要です。

個人情報保護委員会のガイドラインでは、委託先の選定に当たり、委託先の安全管理措置が委託元に求められるものと同等であることを確認する必要があると説明されています。また、委託契約には、個人データの取扱いに関する安全管理措置と、委託元が委託先の取扱状況を合理的に把握できる内容を盛り込むことが望ましいとされています。さらに、定期的な監査等により委託契約で定めた内容の実施状況を把握し、再委託についても事前報告や承認、監査等による確認が望ましいとされています。

そのため、委託先・SIer責任分界整理では、次の観点も重要になります。

・委託先が個人データにアクセスするか
・委託先アカウントにどの権限を付与しているか
・ログで委託先操作を確認できるか
・再委託先の有無を把握しているか
・契約終了時に権限を削除しているか
・委託先の安全管理措置を確認しているか
・取引先チェックシートで説明できる資料があるか

山崎行政書士事務所が支援すること

1. 委託先・SIerの現状整理

まず、現在関与している委託先、SIer、MSP、SOC、保守ベンダー、CSPパートナーを洗い出します。

整理する主な項目は次のとおりです。

・委託先名
・契約種別
・委託業務の内容
・対象システム
・対象クラウドサービス
・Azureサブスクリプション
・Microsoft 365テナント
・Entra IDテナント
・付与されている権限
・利用している管理方式
・連絡窓口
・対応時間
・SLA
・再委託の有無
・契約終了時の処理
・監査時に提出できる証跡

現状を見える化することで、責任分界整理の出発点を作ります。

2. Microsoft・自社・委託先の三層責任分界整理

クラウドの責任分界では、Microsoft、自社、委託先の三層で整理する必要があります。

たとえば、Azure VMを利用している場合、基盤側の責任、OSやミドルウェアの責任、アプリケーションの責任、データの責任、IDの責任は分けて整理する必要があります。

Microsoft 365を利用している場合でも、Microsoftがサービス基盤を提供していても、ユーザー、ID、アクセス制御、情報分類、外部共有、データの取扱い、監査対応は自社側で整理すべき領域が残ります。

整理する主な観点は次のとおりです。

・Microsoftの責任
・自社の責任
・SIerの責任
・MSPの責任
・SOCの責任
・アプリ開発会社の責任
・保守ベンダーの責任
・CSPパートナーの責任
・取引先、委託元に説明すべき責任範囲
・責任が重複している領域
・責任が空白になっている領域

責任分界の目的は、責任逃れではありません。
障害、監査、情報漏えい、取引先対応の場面で、迅速に動ける体制を作ることです。

3. Azure・Microsoft 365の権限整理

委託先にどの権限を付与しているかを確認します。

確認する主な項目は次のとおりです。

・Azure RBAC
・サブスクリプション所有者
・共同作成者
・閲覧者
・リソースグループ単位の権限
・管理グループ単位の権限
・Entra ID管理者ロール
・Microsoft 365管理者ロール
・Exchange、SharePoint、Teams、Purviewの管理権限
・PIMの利用有無
・緊急アクセスアカウント
・委託先アカウント
・ゲストユーザー
・サービスプリンシパル
・アプリ登録
・マネージドID
・Key Vaultアクセス
・シークレット管理
・条件付きアクセス
・多要素認証
・権限棚卸し記録

権限は、契約上の責任分界と一致している必要があります。
「契約上は監視のみ」なのに「本番環境の変更権限がある」という状態は、監査上もセキュリティ上も問題になります。

4. Azure Lighthouse・GDAP・CSP関係の整理

AzureやMicrosoft 365では、委託先が自社テナント外から管理する方式が使われることがあります。

Azure Lighthouseでは、サービスプロバイダーが自社テナントから顧客のAzureリソースを管理でき、顧客はサブスクリプションやリソースグループを指定されたユーザーとロールに委任し、必要に応じてアクセス権を削除できるとMicrosoft公式情報で説明されています。

また、CSPパートナーのMicrosoft 365管理では、従来のDAPからGDAPへの移行において、時間制限付きの最小権限のセキュリティ契約を使用することがセキュリティリスク軽減のベストプラクティスとして説明されています。

当事務所では、次のような観点を整理します。

・Azure Lighthouseの利用有無
・委任されているサブスクリプション、リソースグループ
・委任先テナント
・委任ロール
・委任解除手順
・CSPパートナーの管理権限
・GDAPの有無
・DAPが残っていないか
・Microsoft 365管理者ロールの範囲
・パートナー権限の有効期限
・委託先担当者の実ユーザー管理
・委託終了時の権限削除手順

外部委託先に管理権限を付与する場合は、便利さよりも、可視化、最小権限、期限、削除手順、監査証跡が重要です。

5. 障害・インシデント時の責任分界整理

責任分界が最も問題になるのは、平常時ではありません。
障害、情報漏えい、ランサムウェア、認証障害、設定ミス、誤削除、サービス停止、取引先への影響が発生したときです。

整理する主な項目は次のとおりです。

・一次検知
・アラート確認
・一次切り分け
・影響範囲調査
・ログ保全
・証跡取得
・Microsoftサポート問い合わせ
・SIerへのエスカレーション
・SOCからの通知
・MSPの初動対応
・復旧方針の立案
・復旧作業の実施
・バックアップからの復元判断
・取引先、委託元への報告
・個人情報漏えい時の対応
・再発防止策の作成
・原因調査報告書
・経営層への報告
・監査資料化

Azure Well-Architected Frameworkのオペレーショナルエクセレンスでは、日常業務、アドホック業務、緊急業務の一貫性と予測可能性を高めるために標準化を利用すること、緊急タスクでは役割、責任、通信経路を明確にすることが示されています。

責任分界整理では、インシデント対応時の「誰が動くか」を文書化し、実際の連絡先、権限、ログ取得手順までつなげます。

6. 契約関連資料・運用手順・証跡の整合確認

責任分界は、次の資料が一致していなければ機能しません。

・業務委託契約
・保守契約
・クラウド運用契約
・SLA
・秘密保持契約
・再委託条項
・個人情報取扱いに関する条項
・責任分界表
・運用手順書
・障害対応手順書
・インシデント対応手順書
・変更管理手順
・権限管理手順
・バックアップ手順
・ログ取得手順
・監査証跡一覧
・取引先チェックシート回答
・社内規程
・クラウド利用規程
・情報セキュリティ規程

当事務所では、行政書士業務の範囲内で、契約関連資料、責任分界表、運用手順、チェックシート回答案、監査対応資料、説明資料の作成・整理を支援します。

責任分界整理で確認する主な領域

Azure構成・運用

・管理グループ
・サブスクリプション
・リソースグループ
・仮想マシン
・App Service
・Azure SQL Database
・Azure Storage
・Key Vault
・仮想ネットワーク
・VPN
・Firewall
・NSG
・Azure Backup
・Recovery Services Vault
・Log Analytics
・Azure Monitor
・Defender for Cloud
・Microsoft Sentinel
・Azure Policy
・タグ管理
・コスト管理
・サポート問い合わせ
・構成変更管理
・IaC、ARM、Bicep、Terraform
・CI/CDパイプライン

Microsoft 365・Entra ID

・Microsoft Entra ID
・条件付きアクセス
・多要素認証
・PIM
・全体管理者
・特権管理者ロール
・Microsoft 365管理センター
・Exchange管理
・SharePoint管理
・Teams管理
・OneDrive外部共有
・Microsoft Purview
・監査ログ
・保持ポリシー
・DLP
・秘密度ラベル
・ゲストユーザー
・外部共有
・委託先アカウント
・CSP、GDAP、パートナー管理権限

セキュリティ・監査

・監視責任
・アラート確認責任
・ログ保全責任
・ログ保存期間
・脆弱性対応
・パッチ適用
・EDR、MDR、SOC連携
・セキュリティ推奨事項の対応
・Defender for Cloudの確認
・Microsoft Sentinelの運用
・インシデント初動
・証跡提出
・監査対応
・取引先チェックシート回答
・NIST、ISMS、SOC、GDPR、SCCとの対応整理

契約・委託先管理

・委託業務の範囲
・成果物
・保守対象
・非保守対象
・対応時間
・SLA
・障害時の連絡体制
・復旧対応範囲
・原因調査範囲
・再発防止策
・秘密保持
・個人情報の取扱い
・再委託
・監査協力
・証跡提出
・損害発生時の対応
・契約終了時のデータ返還、削除
・権限削除
・引継ぎ
・ベンダーロックイン対策

 

成果物の例

委託先・SIer責任分界表

Azure、Microsoft 365、Entra ID、アプリケーション、ネットワーク、監視、バックアップ、インシデント対応について、誰が責任を持つかを一覧化します。

主な整理項目:

・業務項目
・Microsoftの責任
・自社の責任
・SIerの責任
・MSPの責任
・SOCの責任
・保守ベンダーの責任
・承認者
・作業者
・確認者
・証跡
・契約条項との対応
・未整備事項
・改善予定

 

RACI表

業務ごとに、Responsible、Accountable、Consulted、Informedを整理します。

・実行責任者
・最終責任者
・相談先
・報告先
・承認者
・緊急時の代替者
・社内外の連絡経路

特に、障害対応、構成変更、権限付与、インシデント報告、バックアップ復旧、取引先報告では、RACI整理が有効です。

 

委託先アカウント・権限台帳

委託先に付与しているアカウントと権限を一覧化します。

・アカウント名
・所属会社
・担当者
・付与理由
・対象システム
・対象サービス
・ロール
・権限スコープ
・付与日
・有効期限
・最終利用日
・MFA適用有無
・条件付きアクセス適用有無
・削除予定
・棚卸し結果
・承認者

 

監査・取引先説明資料

取引先、親会社、監査人、委託元へ説明するための資料を作成します。

・クラウド利用概要
・委託先管理概要
・責任分界概要
・Azure運用体制
・Microsoft 365管理体制
・Entra ID権限管理体制
・ログ・監査証跡整理
・インシデント対応体制
・バックアップ・BCP体制
・未対応事項・改善計画
・チェックシート回答根拠表

 

支援の流れ

Step 1 現在の委託関係を確認

まず、現在関与している委託先、SIer、MSP、SOC、保守ベンダー、CSPパートナーを確認します。

確認する主な資料:

・契約書
・注文書
・仕様書
・SLA
・保守範囲表
・運用手順書
・体制図
・緊急連絡先
・Azure構成資料
・Microsoft 365管理資料
・Entra ID権限一覧
・過去の監査資料
・取引先チェックシート

Step 2 技術構成と権限を確認

Azure、Microsoft 365、Entra IDの構成と権限を確認します。

確認する主な観点:

・誰が管理者権限を持っているか
・委託先アカウントが存在するか
・外部テナントから管理されているか
・Azure Lighthouseを利用しているか
・GDAP、CSP権限が残っているか
・PIMを利用しているか
・MFA、条件付きアクセスが適用されているか
・ログで委託先操作を追跡できるか
・契約終了時の削除手順があるか

Step 3 責任分界表を作成

契約上の役割、実際の権限、運用手順、監査証跡をつなぎ、責任分界表を作成します。

分類例:

・設計
・構築
・運用
・監視
・障害対応
・セキュリティ対応
・バックアップ
・復旧
・ログ管理
・権限管理
・変更管理
・委託先管理
・再委託管理
・監査対応
・取引先報告
・契約終了時対応

Step 4 不足事項・改善計画を整理

責任が曖昧な領域、契約と実態がずれている領域、証跡が不足している領域を整理します。

主な改善例:

・委託先権限の最小化
・不要な管理者権限の削除
・PIM導入検討
・MFA・条件付きアクセスの適用
・Azure Lighthouse委任範囲の見直し
・GDAP権限の見直し
・運用手順書の整備
・障害対応フローの明確化
・ログ保存期間の見直し
・バックアップ復旧テストの実施記録化
・再委託管理の明確化
・契約関連資料への反映
・取引先説明資料の作成

Step 5 監査・取引先提出に使える資料へ整備

最後に、責任分界を監査や取引先チェックシートに使える形へ整えます。

・提出用カバーメモ
・責任分界表
・RACI表
・委託先管理台帳
・権限一覧
・ログ取得方針
・インシデント対応フロー
・改善計画表
・チェックシート回答案
・証跡一覧

情シス、法務、経営層が同じ資料を見て説明できる状態を目指します。

 

このような企業におすすめです

・Azure、Microsoft 365、Entra IDを利用している企業
・SIerにAzure構築・運用を委託している企業
・MSP、SOC、MDR、保守ベンダーを利用している企業
・CSPパートナー経由でMicrosoft 365やAzureを契約している企業
・委託先アカウントや外部管理権限が整理できていない企業
・取引先チェックシートで委託先管理を問われている企業
・ISMS、Pマーク、SOC、NIST、GDPR、SCCへの対応を整理したい企業
・法務と情シスで契約・運用の認識がずれている企業
・障害時の責任範囲が不明確な企業
・契約更新前にSIerとの責任分界を見直したい企業
・監査前に委託先管理資料を整備したい企業
・一人情シス、少人数情シスでベンダー管理まで手が回らない企業

 

よくあるご相談

Q. SIerとの契約書はありますが、運用責任が曖昧です。相談できますか。

はい。
契約書、仕様書、SLA、運用手順書、実際のAzure・Microsoft 365の権限設定を照らし合わせ、責任分界を整理します。

単に契約文言を見るだけではなく、実際に誰が管理者権限を持っているか、誰がログを確認しているか、誰が障害対応するかまで確認します。

 

Q. Azureの管理者権限をSIerに渡しています。問題がありますか。

一律に問題とはいえませんが、権限の範囲、必要性、期間、承認、監査ログ、削除手順が整理されていない場合はリスクがあります。

特に、サブスクリプション所有者、全体管理者、特権管理者ロールを長期間付与している場合は、最小権限、PIM、グループ管理、定期棚卸しを検討する必要があります。

 

Q. MSPやSOCとの責任分界も整理できますか。

対応可能です。

SOCが検知する範囲、MSPが対応する範囲、自社が判断する範囲、SIerへエスカレーションする範囲を整理します。

アラート確認、初動対応、ログ保全、復旧作業、取引先報告、原因調査、再発防止策の作成まで、実務に沿って分解します。

 

Q. MicrosoftとSIerと自社の責任を分けて整理できますか。

可能です。

AzureやMicrosoft 365の共有責任モデルを前提に、Microsoft側の責任、自社側の責任、SIer・MSP・SOC側の責任を整理します。

特に、データ、ID、アクセス制御、設定、ログ、運用、監査対応は、自社と委託先の間で明確にしておく必要があります。

 

Q. 取引先チェックシートの「委託先管理」項目にも対応できますか。

対応可能です。

委託先選定、委託契約、再委託、アクセス権限、監査、ログ、インシデント報告、契約終了時の削除・返還などについて、回答案と根拠資料を整理します。

 

Q. 契約書の修正案も作成できますか。

行政書士業務の範囲内で、契約関連資料、条項案、責任分界表、運用手順、説明資料の作成・整理を支援します。

ただし、相手方との交渉代理、紛争対応、訴訟対応、法律上の最終判断が必要となる事項については、弁護士等の専門家と連携する形で対応します。

 

Q. 実際のAzure設定変更まで依頼できますか。

設定変更を含む場合は、作業範囲、責任分界、変更管理、バックアップ、ロールバック方針を明確にしたうえで進めます。

原則として、まずは現状確認、設計、手順作成、レビューを行い、お客様の管理者権限と承認のもとで慎重に対応します。

 

料金について

対応範囲、委託先の数、対象システム、Azure・Microsoft 365環境の規模、必要な成果物によって異なります。

まずは、現在の委託関係、契約資料、Azure・Microsoft 365の利用状況、取引先チェックシートや監査要求の有無を確認し、必要な作業範囲を整理します。

【料金表示例】
初回相談:お問い合わせください
委託先・SIer責任分界簡易レビュー:個別見積り
Azure / Microsoft 365権限・委託先整理:個別見積り
責任分界表・RACI表作成:個別見積り
取引先チェックシート対応・証跡整理:個別見積り
契約関連資料・運用手順整理:個別見積り
継続的なクラウド法務・委託先管理伴走:個別見積り

 

ご相談時にご用意いただきたい資料

可能な範囲で、次の資料をご用意ください。

・SIer、MSP、SOC、保守ベンダーとの契約書
・注文書、仕様書、SLA
・運用手順書
・保守範囲表
・障害対応手順書
・緊急連絡先
・Azure構成図
・Azureサブスクリプション一覧
・Microsoft 365利用状況
・Entra ID権限一覧
・委託先アカウント一覧
・Azure Lighthouse利用状況
・CSP、GDAP、パートナー権限に関する資料
・過去の障害対応記録
・過去の監査資料
・取引先チェックシート
・情報セキュリティ規程
・クラウド利用規程
・個人情報取扱規程
・委託先管理規程
・インシデント対応手順
・バックアップ方針
・ログ取得方針

すべて揃っていなくても問題ありません。
不足資料を洗い出すことも支援内容に含まれます。

 

責任分界は、クラウド運用の土台です

AzureやMicrosoft 365は、導入しただけでは安全な運用にはなりません。

誰が設計したのか。
誰が構築したのか。
誰が監視しているのか。
誰が復旧するのか。
誰が取引先へ説明するのか。
誰がログを出せるのか。
誰が委託先の権限を管理しているのか。

これらが曖昧なままでは、障害や監査の場面で判断が止まります。

委託先・SIer責任分界整理は、責任を押し付け合うためのものではありません。
クラウド運用を安全に継続し、取引先、監査人、経営層へ説明できる状態を作るためのものです。

山崎行政書士事務所は、Azureエンジニアとしての実務知見と、行政書士としての文書整理力を活かし、契約、権限、運用、ログ、証跡をつなぐ責任分界整理を支援します。

「SIerに任せているが、どこまで任せているか説明できない」
「委託先の管理者権限が残っているか不安」
「取引先チェックシートで委託先管理を問われている」
「Azure・Microsoft 365の責任分界を整理したい」

そのような企業様は、ぜひご相談ください。

【お問い合わせボタン】
委託先・SIer責任分界整理を相談する

 

対応エリア

全国対応可能です。
静岡県内の企業様はもちろん、オンラインで全国の企業様に対応しています。

Azure、Microsoft 365、Entra ID、委託先管理、SIer責任分界、MSP・SOC連携、取引先チェックシート、監査対応でお困りの場合は、お気軽にご相談ください。

 

 

注意事項

本サービスは、行政書士業務の範囲内で、契約関連資料、社内規程、説明資料、責任分界表、RACI表、チェックシート回答案、監査対応資料、証跡整理表等の作成・整理を支援するものです。

個別の紛争、相手方との交渉代理、訴訟対応、法律上の最終判断が必要となる事項については、弁護士等の専門家と連携する形で対応します。

本サービスは、監査合格、認証取得、取引継続、基準適合、第三者保証を約束するものではありません。
実際の監査判断、認証判断、取引先判断は、監査人、審査機関、取引先、関係機関の判断によります。

Microsoft、Azure、Microsoft 365、Microsoft Entra、Microsoft Defender、Microsoft Purview、Microsoft Sentinel、Azure Lighthouse は、米国 Microsoft Corporation の商標または登録商標です。
山崎行政書士事務所は独立したサービス提供者であり、Microsoft公式代理店、公式監査機関、公式認証機関であることを表示するものではありません。
本ページにMicrosoft Azureロゴ、Microsoftロゴ、Microsoft公式キャラクターは使用していません

Instagram​​

Microsoft、Azure、Microsoft 365、Entra は米国 Microsoft Corporation の商標または登録商標です。
本ページは一般的な情報提供を目的とし、個別案件は状況に応じて整理手順が異なります。

※本ページに登場するイラストはイメージです。
Microsoft および Azure 公式キャラクターではありません。

Microsoft, Azure, and Microsoft 365 are trademarks of Microsoft Corporation.
We are an independent service provider.

​所在地:静岡市

©2024 山崎行政書士事務所。Wix.com で作成されました。

bottom of page