ADR-0127: 顧客向け認証と取込を IdP・ソース非依存の M365 ネイティブ統合で確定する

• Status: Proposed
• Mode: Standard
• Kruchten Type: Existence/Property
• Scope: product
• Implementation Status: Not Started
• 起案者: [email protected]
• 起案日時 (JST): 2026-06-08 17:06
• 承認日時 (JST): -
• Deciders: [email protected] (単独)

コンテキスト

§1.1 背景

JTBD-012 をはじめとする顧客向けプロダクト群(証憑管理・管理会計・審査パイプライン DRP)で「顧客がどうサインインし、証憑をどう取り込むか」の方式が未決。顧客 IT 環境は Microsoft 365 中心であり、「顧客が自社の M365 アカウントでそのままサインインする」シームレス認証が製品の絶対制約(顧客側の認証管理工数 8 割減)。同時に、メール添付・OneDrive 上の証憑を顧客作業ゼロで取り込めることが電帳法③電子取引スライスの成立条件になる。

§1.2 現状 (As-Is)

顧客向け認証・取込方式は未確定のゼロベース。独自 ID 管理を採った場合の恒常運用負荷の概算 = 退職・異動の手動失効棚卸しが 1 社あたり月 ~0.5〜1 時間(従業員 10〜50 名・月次想定)、100 社で月 ~50〜100 時間。SSO(顧客テナント委任)ならこれが 0(=「8 割減」の実体)。取込も現状ゼロで、Graph 連携が無ければ証憑は手動アップロード相当(1 件 ~1 分 × 月 500 枚 = 1 社あたり月 ~8 時間)。いずれもオーダーマグニチュード推定(根拠=従業員規模・証憑枚数の想定値)。

§1.3 課題

顧客の MFA・条件付きアクセス・退職時の失効を顧客テナント側ポリシーにそのまま委ねられれば、ベンダー側で顧客ごとに ID を発行・管理・失効する恒常運用がゼロになる。逆に独自 ID 管理を採ると、退職者の失効漏れ(顧客テナントのライフサイクルと非連動)が監査リスクになり、SMB では運用が破綻しやすい。

§1.4 制約・要件

• 顧客側の恒常的 IT 運用作業ゼロ(初回 admin consent は導入工程として許容)
• 顧客が普段の M365 セッションでシームレス SSO できること
• IdP・取込ソースに非依存(将来 Google Workspace 等を後付け可能)
• scope isolation(製品別の過剰権限を生まない)・失効の即時反映
• 電帳法③電子取引スライスの成立(受領日からの速やかな保存・検索要件)

§1.5 目標 (To-Be)

顧客向け認証・取込を M365 ネイティブ統合として確定しつつ、IdP・ソース非依存の pluggable 抽象で実装する。Non-Goals: day-1 での Google Workspace 等の第 2 アダプタ実装、Entra アプリ登録の共通/分離方針の確定(実装 ADR へ委任)。

決定

顧客向け認証と取込を「M365 ネイティブ統合」として確定するが、特定 IdP・特定取込ソースに固定しない pluggable な抽象で実装する。具体的には、認証は IdP 非依存の認証ゲートウェイ越しに行い day-1 はマルチテナント Entra ID OIDC(organizations エンドポイント + 顧客 IT 管理者の admin consent 1 回 + verified publisher 表示)を実装、取込はソース非依存のアダプタインターフェイス越しに行い day-1 は Microsoft Graph API(Outlook/OneDrive)アダプタを実装する。Google Workspace 等の他 IdP・他ソースは同じインターフェイスへの後付けアダプタとし、day-1 実装は不要だが設計でロックインしない。3 プロダクト共通の認証だが、Entra アプリ登録を「共通 1 登録」とするか「製品ライン別に分離」するかは下記リスクを踏まえ実装 ADR で比較判定する。

判断基準 (Decision Drivers)

3.1 評価軸

K.O. criterion: Must 軸の score < 3 は不採用。

3.2 評価軸 × 案スコア表

加重和は K.O. 通過候補のタイブレーク用 (Suhr 1999 CBA 準拠)。案 A は K.O. 通過するが #flexible で IdP 非依存要件を毀損するため不採用。

検討した代替案 (Alternatives Considered)

• 案 A: 単一 IdP 固定(Entra 直結・抽象なし): 実装は最小だが、将来 Google Workspace 顧客に対応できず製品の IdP 非依存要件を毀損する。day-1 実装が Entra のみなのは抽象採用案と同じで、抽象を挟むコスト差は小さいため不採用(抽象を採る)。
• 案 B: 独自 ID 管理(自社で ID 発行・パスワード運用): 顧客の退職失効・MFA・条件付きアクセスと非連動になり、恒常運用ゼロ(Must①)とシームレス SSO(Must②)の双方を毀損。SMB での失効漏れが監査リスク。不採用。
• 案 C: 取込を Graph 固定(アダプタ抽象なし): 認証を pluggable にする以上、取込だけ固定すると Google 顧客で取込経路が欠落し非対称。アダプタ抽象に統一する。

影響 (Consequences)

§5.1 正の影響 (Good)

• 顧客は普段の M365 アカウントで SSO。MFA・条件付きアクセス・退職失効が顧客テナント側ポリシーで自動的に効く。
• ADR-0110 OQ-3(DRP 製品期の認証 = アプリ層マルチテナント Entra OIDC)と同一制約で整合。
• pluggable 抽象により Google Workspace 等の第 2 アダプタを破壊的変更なしに追加可能(設計上)。

§5.2 負の影響 (Bad) / リスクと緩和

• admin consent の商談ブロッカー: 実行にグローバル/クラウドアプリ管理者ロール要。IT リテラシー最低層の建設・土木中小では consent 担当者の特定・調整が技術的ブロッカーになりうる(SMB SaaS で初回商談〜consent 取得 2〜4 週間の事例)。緩和: ①consent 取得をセールスフローの正式工程(IT 管理者特定 + 2〜4 週リードタイムを導入計画に織込)に位置づける ②ユーザー単位 consent・Azure AD B2B 等の代替フローの実現可能性を PoC 前に調査。
• 【盲点 1: critical】Entra グローバル管理者ロール社内非保有顧客の構造的失注リスク: ターゲット顧客(従業員 10〜50 名規模 SMB・建設/土木/製造)では Entra グローバル管理者またはクラウドアプリ管理者ロールを社内保有する専任担当者が存在せず、外部 IT 業者にも通常付与されていない。Microsoft 調査では中小企業約 40% が Entra 管理者ロール社内非保有。緩和: ターゲット顧客セグメントのうち管理者ロール社内保有割合を既存商談履歴またはパイロット 5 社へのヒアリングで事前計測し、結果を PoC Confirmation① の合否判定基準として追記。計測結果が 50% 未満 であれば、ユーザー単位 consent・B2B 招待フローを「代替ではなく主経路」として実装 ADR で再設計する判断基準を明示する。
• 【盲点 2: critical】Graph delta token 無効化による複数テナント同時フルスキャンと電帳法保存期限超過: Microsoft は delta token をテナント側大規模インデックス再構築・ストレージ移行時に 410 Gone で無効化しフルスキャンへ fallback を要求する。100 社が同タイミングで影響を受けた場合、queue 処理が数時間〜数日単位で遅延し電帳法③受領日起算保存期限を超過しうる。緩和: 実装 ADR に「delta token 無効化時のフルスキャン量上限(テナントあたり最大処理件数/時)とバックプレッシャー設計」および「取込遅延が X 時間超過時の顧客通知 SLA(電帳法 7 営業日基準を上限)」を必須要件として追記。50 テナント同時フルスキャンシナリオ を PoC 負荷シミュレーション必須テストケースとして本 ADR Confirmation に追加(下記 Confirmation⑤)。
• Microsoft によるマルチテナントアプリ Client Secret 強制失効: 不審マルチテナントアプリに通知 30 日未満(即日も)で失効させた実績(consent phishing 対策)。発動時は全顧客・全プロダクトが同時に認証不能になり復旧に全顧客の再 consent(2〜4 週)が必要。緩和: プロダクト別登録分離の判断期限(例: β 顧客 5 社到達前)を実装 ADR への委任条件として拘束し、強制失効時の顧客向け SLA と復旧フロー骨格(誰が何を何時間以内に)を実装 ADR に含める。
• 【盲点 3: high】verified publisher 即日失効による全顧客同時ブロックと 200〜400 時間の復旧工数: Microsoft の不審行動検知による verified publisher 即日失効(予告なし)では「90 日前アラート」緩和策が機能しない。条件付きアクセス標準テンプレ「未確認発行元アプリブロック」が普及しており、100 社規模では復旧工数が顧客数 × 再 consent 所要時間で 200〜400 時間 に達し「ベンダー側恒常運用ゼロ」前提が崩壊。緩和: 即日失効シナリオを最悪ケースとしてコスト試算に追加(下記コスト試算参照)。プロダクト別アプリ登録分離の判断期限を 「β 顧客 5 社到達前」から「本番投入前」に前倒し する根拠を実装 ADR の委任条件として追記し、失効時の影響範囲を製品ライン単位に限定する設計原則を明示。
• 顧客テナント側の条件付きアクセス変更による無予告 SSO 障害: IT 委託ベンダーがポリシー一括テンプレ適用で本アプリの除外設定を上書きすると SSO 失敗。エラーは顧客側ログのみに残る。緩和: Entra サインインログ(Graph API 経由)で特定テナントの認証失敗率が閾値超過時にアラート発火する監視を実装 ADR の必須要件とする。除外維持作業が年次棚卸しを要求し恒常運用ゼロ Must に抵触する場合は、抵触判定の閾値を撤退条件に置く。
• 【盲点 5: high】SSO 障害テナントのサインインログ取得不能(循環依存): Entra サインインログ取得には AuditLog.Read.All または Directory.Read.All の委任権限が必要だが、SSO 失敗時は当該テナントのアクセストークン取得不能でログ取得権限も同時喪失。「障害が起きたまさにそのテナントのログだけが参照不能」という循環依存。緩和: 実装 ADR に「サインインログ取得用サービスプリンシパル権限が SSO 障害と独立して維持される設計(アプリケーション権限での別登録、または Entra 診断設定を Event Hub 経由で自社 SIEM に転送する構成)」を Confirmation③ 必須要件として追加し、PoC フェーズで動作確認手順を記載。
• 【盲点 6: high】IT 管理者不在の超零細顧客でのセールス非公式回避策によるセキュリティポリシー違反常態化: 従業員 10 名未満の顧客では「IT 管理者」が経営者本人または外部 IT 業者でセルフサービスでの consent 取得が困難。受注圧力下でセールス担当者が「顧客 PC 上での管理者ログイン代行」等の非公式手順を編み出すと、顧客テナント認証情報の第三者操作=重大セキュリティ違反(契約解除・監査指摘対象)。緩和: ADR の緩和策に「IT 管理者が存在しない顧客への対応フロー(外部 IT 業者への委任手順書・consent 取得の上限リードタイムと超過時の商談クローズ基準)」を追記し、セールス担当者が非公式手順に頼らなくて済む公式エスカレーションパスを実装 ADR 起案前に確定。
• scope isolation: 単一アプリ登録だと DRP のみ契約した顧客が証憑管理・管理会計のスコープまで admin consent する過剰権限が生じる。緩和: 「独立して販売される製品ラインは登録を分離する」を scope isolation policy として原則化。
• verified publisher / MPN 失効(年次更新): MPN は年次更新でステータス喪失リスク。verified publisher 失効が既存 consent に影響しうる。緩和: 有効期限監視(失効 90 日前アラート)を CI/CD に組込み必須化(即日失効は別途上記参照)。
• 【盲点 7: medium】顧客起因 consent 取消による電帳法検索索引メタデータ喪失: ロールバック手順② は「正本は RecordStore に保全」とするが、電帳法③ は正本保存に加え「日付・金額・取引先」検索機能を義務付け。検索索引メタデータが Graph 取込時にのみ生成される設計だと、consent 取消後の再取込不能で索引欠落のまま正本だけ残る。顧客起因 consent 取消(競合乗換・担当者誤操作)はベンダー主導撤退と独立。緩和: 顧客起因 consent 取消時のメタデータ索引保全方針(Graph 取込時に索引を自社 DB へ永続化するか否か)を実装 ADR 必須決定事項として追記し、電帳法顧問への確認スコープに「consent 取消後の検索要件継続充足可否」を明示的に含める。

§5.3 中立・トレードオフ (Neutral / Trade-offs)

• 【盲点 4: high】pluggable 抽象 IF 設計の day-1 実装前確定: Confirmation④ で「抽象 IF を介していること」を検証するが、IF 自体の型定義・契約テスト成果物確定期限が未記載。Entra 固有概念(tenantId・deltaToken・subscription 有効期限・admin consent コールバック状態管理)は OIDC 標準フローに存在しない概念で、吸収層設計を後回しにすると day-1 実装が実質的な IF の既成事実化。Auth0/Okta 差替で ID トークンクレーム構造差異が抽象層に漏れ込み全セッション管理書き直しになった先行事例多数。緩和(本 ADR に追記): 認証ゲートウェイのアダプタ IF を OpenID Connect 標準クレームのみで表現できる型定義として実装 ADR 起案前に文書化し、Entra 固有概念(tenantId・adminConsentState・deltaToken)の正規化責任をアダプタ側に閉じ込める設計原則を採用。型定義完成を PoC 開始の前提条件 として Confirmation⑥ に明示。
• 【盲点 8: medium】第 2 アダプタ着手判断 governance: 「Review After = 第 2 アダプタ着手時または 12 か月後」は意思決定プロセス未定義。day-1 実装稼働で工数が張り付き、抽象 IF 負債警告(1 件検出で警告)が厳しすぎて「再設計が必要」と判断され先送りされ続けるパターンが多い。Google Workspace 顧客を抱える競合参入時の 6〜12 か月遅延は競合優位喪失に直結。追記: 「第 2 アダプタ(Google Workspace)の着手判断権限者・判断期限 = 本番顧客 20 社到達から 3 か月以内 に Go/No-go を決定」を明記し、判断先送りを防ぐ governance 条項とする。
• 3 プロダクト共通の Entra アプリ登録を「共通 1 登録」とするか「製品ライン別分離」とするかは実装 ADR で比較判定(上記 verified publisher 即日失効リスク・scope isolation を踏まえ「本番投入前」までに確定)。
• pluggable 抽象は day-1 では「Entra/Graph 1 実装+スタブ」のみで実証され、真の IdP 非依存性は第 2 アダプタ実装時にしか検証されない不確実性が残る。

撤退条件 (Rollback Plan)

• Entra マルチテナント PoC で「外部アプリをブロックする条件付きアクセスポリシー有効テナント」での SSO 成功(Confirmation 1)が不成立 → B2B invitation 等の補完方式を別 ADR で検討。本番展開を待たず PoC フェーズで判定。
• admin consent 取得が初期商談の 50% 以上 で 4 週間を超えるブロッカーになる → ユーザー単位 consent / B2B 代替フローの本実装を判断。
• ターゲット顧客の Entra 管理者ロール社内保有割合が事前計測で 50% 未満 → ユーザー単位 consent・B2B 招待を主経路として実装 ADR で再設計。
• 顧客テナント側の条件付きアクセス除外設定の維持作業が「恒常的 IT 運用作業ゼロ」Must 制約に抵触する閾値(作業頻度・工数 — 実装 ADR で確定)を超過 → 認証方式の再評価 ADR を起案。

本番投入後のロールバック手順(認証方式を撤退・切替する場合):

• ①consent 取消: 影響顧客の admin consent を取消(verified publisher アプリの権限剥奪手順を顧客 IT 管理者へ通知)。自社側はアプリ登録を無効化。
• ②取込済データの取扱: 証憑正本は ADR-0126 の RecordStore 側に保全されるため、認証・取込経路を撤退しても 正本は失われない(認証撤退と正本保全が疎結合)。取込中の未確定キューは冪等キー(受領イベント ID)で再投入安全。ただし 検索索引メタデータが Graph 取込時にのみ生成される場合は consent 取消後の再取込不能で電帳法検索要件を毀損するため、索引永続化方針を実装 ADR で確定(§5.2 盲点 7)。
• ③代替認証への移行: ユーザー単位 consent / Azure AD B2B 招待 / 手動アップロードのいずれかへ切替。移行猶予を 90 日 確保し、その間は旧経路を read-only で並走。
• ④セッション切替: 既存 SSO セッションを失効させ、新認証経路へ再ログイン誘導(顧客への事前通知 30 日)。
• 発動条件: 上記撤退条件のいずれか、または Microsoft の Client Secret 強制失効/verified publisher 即日失効が復旧不能になった場合。

Review After / 長期影響の負債判定:

• Review After = 第 2 アダプタ(Google Workspace 等)実装着手時 または 本決定から 12 か月後のいずれか早い方。pluggable 抽象が実際に 2 実装を保持できたかをこの時点で検証する。第 2 アダプタの Go/No-go 判断は本番顧客 20 社到達から 3 か月以内 に意思決定権限者が確定(§5.3 盲点 8)。
• pluggable 抽象の負債化判定指標(定量): ①抽象 IF に Entra/Graph 固有概念(テナント ID・デルタトークン・subscription 更新間隔等)が漏れ込んでいる箇所が 1 件でも検出 されたら負債警告 ②第 2 アダプタ実装で IF の 破壊的変更(メジャーバージョン相当)が必要 になったら「抽象の前提が誤り」と判定し抽象設計の再 ADR を起案。

コスト試算

PoC・登録系(確定度高)

• Entra マルチテナントアプリ登録 + PoC(検証用外部テナントから admin consent → SSO 成功まで)~1.0 人日。
• MPN 登録 + verified publisher 設定 ~0.5 人日(登録費 0 円)。

本番実装の概算(オーダーマグニチュード推定・実装 ADR 起案時に再見積)

• 認証ゲートウェイ(マルチテナント OIDC・state/nonce のテナントスコープ分離・cross-tenant 注入の自動テスト含む)~3〜5 人日。※当初「薄いラッパ ~0.5 人日」は単一テナント OIDC 相当の過小評価(盲点指摘)であり上方修正。
• Graph 取込アダプタ(delta query・Exponential Backoff・テナント別 queue 分離・delta token 無効化時のフルスキャンバックプレッシャー設計)~3〜5 人日。
• スタブ IdP アダプタ(Google Workspace 模擬・抽象 IF 検証用)~1〜2 人日。
• 監視基盤(Graph 経由サインインログの認証失敗率アラート・MPN/verified publisher 失効監視・SSO 障害と独立したログ取得経路)~2 人日。
• PoC 50 テナント相当の負荷シミュレーション環境構築(delta token 無効化同時フルスキャン含む)~1〜2 人日。
• 標準契約書条項(障害時ログ共有 SLA・consent 撤退手順)の法務レビュー ~0.5 人日。
• 電帳法顧問(税理士・公認会計士)への Graph 取得タイムスタンプ証跡適合性 + consent 取消後の検索要件継続充足可否の文書確認 ~0.25 人日 + 顧問費 ~数万円規模(オーダー)。
• 本番実装の小計 ~12〜18 人日 + 顧問費数万円規模(根拠=アダプタ 1 実装ぶん + 横断対応の積上げ、実装 ADR 起案時に再見積する)。
• 運用ランニング: Cloudflare Workers + 監視は既存 DRP 基盤に相乗りのため増分は小さい(月オーダーで数千円未満想定)。

最悪ケース復旧コスト(verified publisher 即日失効・盲点 3)

• 全顧客同時ブロック発生時の復旧 = 顧客数 × 再 consent 所要時間。100 社 × 2〜4 時間 = 200〜400 時間(ベンダー側調整・顧客 IT 管理者対応含む)。プロダクト別アプリ登録分離を本番投入前に完了させれば製品ライン単位に影響を限定可能。

Confirmation

• 検証手段:
  • ①Entra マルチテナント PoC: 検証用外部テナント(外部アプリブロックの条件付きアクセス有効)から admin consent → SSO 成功を確認。回避が必要なら回避手順の顧客側所要工数を計測し恒常作業ゼロ制約への抵触を判定。追加: ターゲット顧客の Entra 管理者ロール社内保有割合事前計測(パイロット 5 社ヒアリング)を合否判定基準に含める(§5.2 盲点 1)。
  • ②MPN 登録・verified publisher ステータスの有効期限監視(失効 90 日前アラート)が CI/CD に組込まれていること。
  • ③Entra サインインログ(Graph 経由)による特定テナント認証失敗率の閾値監視・アラート発火設計が実装 ADR に記載されていること。追加: サインインログ取得用サービスプリンシパル権限が SSO 障害と独立して維持される設計(アプリケーション権限別登録または Event Hub→自社 SIEM 転送)を PoC フェーズで動作確認(§5.2 盲点 5)。
  • ④認証・取込が IdP/ソース非依存の抽象 IF を介していること(Entra/Graph 直結のハードコードがないこと)。
  • ⑤追加: PoC 負荷シミュレーションで 50 テナント同時 delta token 無効化フルスキャン シナリオを必須テストケースとして実施し、queue 処理遅延が電帳法 7 営業日基準内に収まることを確認(§5.2 盲点 2)。
  • ⑥追加: 認証ゲートウェイのアダプタ IF 型定義(OpenID Connect 標準クレームのみで表現・Entra 固有概念はアダプタ側に閉じ込め)の文書化完了を PoC 開始の前提条件 とする(§5.3 盲点 4)。
• 実行頻度: PoC 実施時(①⑤⑥)/ 実装 ADR 起案ごと(②③④)。
• 違反時対応: §撤退条件の該当項目を発動。Confirmation① 不成立は PoC フェーズで判定し本番展開を停止して補完方式を別 ADR で検討。
• KPI: PoC テナントの SSO 成功率 100%(条件付きアクセス有効テナント含む)/ 顧客側の恒常的 IT 運用作業 0 項目(初回 admin consent は導入工程として除外)/ admin consent ブロッカー化率(初期商談に占める割合、目標 50% 未満)/ ターゲット顧客の Entra 管理者ロール社内保有割合 50% 以上。

参照 (References)

• 関連 ADR:
  • ADR-0110 OQ-3(DRP 製品期の認証 = アプリ層マルチテナント Entra OIDC): 並立・同一制約で整合。
  • ADR-0108(M365/Entra 顧客の自前 ID で GAS 会計を使わせる方式・Proposed): JTBD-012 方針(GAS は社内/プロトタイプへ降格・顧客向けは新規 SaaS)と本方針で前提が変わるため、本方針受理時に Supersede。
  • ADR-0118(取下げ済): 共通基盤 5 決定の束を分解。本方針はその決定②(認証)+ ③(取込)を継承しつつ、IdP/ソース非依存の pluggable 抽象へ建付けを修正。
  • ADR-α(法的正本 = 自社集約): 並立(「認証・取込は M365 ネイティブ、保存正本は自社」の分担を構成)。
  • ADR-0126(RecordStore による正本保全): ロールバック手順② で参照。
• 関連 PR/Issue: -
• 外部資料: -