AI・外部コーディングの導入が止まるとき、問題は技術力ではなく「経営層・株主に説明できないこと」だ。
答えの構造は単純で、**「定義（config）は渡せる、認証・接続・組織データは顧客側にしか構造的に存在しない」**設計にすれば、説明できる。
外部の開発者が鍵もデータも持たず、全変更が差分で残り、権限が時限・撤収できるなら、経営層が求めているのはその証明だけだ。
止まっている壁の正体
IPA「情報セキュリティ10大脅威2026」（2026年1月公表）では、「AIの利用をめぐるサイバーリスク」が組織編で初選出され3位にランクインした（2025年版は圏外）。同時に「サプライチェーン・委託先を狙った攻撃」は4年連続2位。AIに対する警戒感が急速に制度化されつつある。
IPA の中小企業調査（2025年5月公表）では、委託先からセキュリティ要求を受けた企業のうち「機密保護措置を実施した」のは79.6%。なお、この数値はAI外部委託に特化した設問ではなく委託先全般の数値であり、AI外部委託に限定した調査データは現状では整備されていない。
PwCの「生成AIに関する実態調査 2025春」によると、企業の懸念の軸が「競争劣位」（27%・前回比-16pt）から「コンプライアンス・企業文化上の脅威」（44%・前回比+23pt）に大きくシフトしている（PDF未直接確認・出典明示で参照）。
つまり、AI導入の壁はいま「速く使えるか」ではなく「コンプライアンス上説明できるか」に移っている。外部委託で企業のAIを動かしたいなら、この問いに構造で答える必要がある。
「渡せる層」と「渡せない層」を切り分ける
設計の出発点はここだ。
| 層 | 内容 | 誰が持つか |
|---|---|---|
| 渡せる（定義層） | フロー設計・UI テンプレート・設定値（config）・コードファイル | 開発者が成果物として渡す |
| 渡せない（認証・接続層） | API キー・接続文字列・Entra ID トークン・環境変数の実値 | 顧客テナントにしか存在しない |
| 渡せない（データ層） | 顧客組織の個人情報・業務データ・Dataverse レコード | 顧客テナントにしか存在しない |
「渡せる」のはあくまで「設計の定義」だ。認証情報と組織データは、構造として顧客のテナント側にしか存在しない。外部開発者がアクセスできる権限を持つとしても、それは「一時的な作業権限」であり、仕事が終われば撤収する。
この切り分けを最初に明示することで、「外部委託 = データが外に出る」という混同を解消できる。
build と bind の役割分離——last-mile config 4ステップ
実務の動きを具体的に整理するための軸として「build / bind」の役割分離がある。
- build（開発者側）：フロー・UI・ロジックをコードや設計ファイルとして作る
- bind（顧客側）：作られた定義を顧客テナントに接続し、実際の環境に紐付ける
顧客テナントへの最終的な組み込み（last-mile config）は、4ステップで構成される。
| ステップ | 内容 | 誰が実行するか |
|---|---|---|
| 1. 認証 | Entra ID でゲストユーザー追加 or PIM 昇格リクエスト | 顧客側の管理者が承認 |
| 2. Secret | Key Vault または環境変数に実際の接続情報を設定 | 顧客側が入力 |
| 3. 接続 | フロー・コネクタを顧客の認証情報に紐付け | 顧客または共同作業 |
| 4. 本番昇格 | Solution を Dev → Test → Prod に昇格 | 顧客側の承認が必要 |
ポイントは4ステップ全体を通じて、開発者は認証情報の実値を受け取らない設計にすることだ。Secret は顧客が入力し、本番昇格は顧客が押す。開発者が渡すのは「どこに何を入力するかの定義」だけになる。
Dataverse の監査ログは管理者設定により30日から無期限（Forever）まで保持できる（Microsoft Learn 公式仕様・2026年時点）。設定変更が差分として記録されるため、「何がいつ変わったか」は追跡可能な状態になる。
アクセス4方式と監査ログ——設計で詰める判断軸
外部開発者に付与するアクセス方式には、大きく4種類ある。
| 方式 | 概要 | 監査性 | 撤収のしやすさ |
|---|---|---|---|
| なし | 環境に一切アクセスしない | — | — |
| 時限（PIM） | 申請→承認→時間制限付きで一時的に昇格 | 全活動がログ記録 | 期限後に自動失効 |
| ゲスト（B2B） | Entra B2B でゲスト招待。特定リソースのみアクセス | サインイン・リソースアクセスをログ追跡 | 管理センターまたは PowerShell から即時削除 |
| 常時（反パターン） | 常設の高権限アカウントを付与 | ログは残るが撤収の仕組みがない | 属人的になり、退場後も残りやすい |
「常時」方式は運用が楽に見えるが、説明責任の観点では最も問題が多い。
PIM（Privileged Identity Management）の時限昇格を使う場合、アクセス有効化時間は30分〜最大24時間の範囲で管理者が設定できる（デフォルトは8時間）。指定時間後は自動失効し、対話操作は不要。全ての有効化・失効・承認アクティビティが監査ログに記録される。
ただしPIM の利用には Microsoft Entra ID Premium P2 ライセンスが必要（Microsoft 365 E5 に含まれる）。申請者・承認者・アクセスレビュアー全員にP2が必要になるため、顧客側のライセンス環境を事前に確認することが前提条件となる。すべての顧客がM365 E5環境を持つわけではない点に注意が必要だ。
監査ログの保存期間は、顧客のライセンスに応じて変わる。
| ライセンス | Entra ID 監査ログ保存期間 |
|---|---|
| Entra ID Free | 7日 |
| Entra ID P1 / P2 | 30日 |
| Microsoft Purview Audit (Standard)・E3等 | 最長180日（カスタムポリシーで1年まで延長可） |
| Microsoft Purview Audit (Premium)・E5等 | 1年（最長10年アドオン） |
Azure Monitor（Log Analytics）への診断設定エクスポートを使えば、無期限保存も可能だ（2026年時点の仕様）。
役員・株主への説明フレーム——「問い × 統制 × 証跡」一枚表
経営層・株主が求めるのは「大丈夫か」の一言ではなく、「何がどう制御されているか」の構造的説明だ。以下の一枚表を会議資料の1ページとして使える。
| 問い | 統制（設計で担保していること） | 証跡（実際に確認できるもの） |
|---|---|---|
| 「外部の人が組織データにアクセスできるか？」 | データ層は顧客テナントにのみ存在。開発者は定義ファイルのみ持つ | Dataverse 監査ログ（30日〜Forever） |
| 「作業中に何を見ていたか記録が残るか？」 | PIM 有効化中の全操作・B2B ゲストのアクセスを Entra ID 監査ログで追跡 | Entra 監査ログ（P2：30日 / E5：1年） |
| 「仕事が終わったらアクセスを止められるか？」 | PIM は期限後自動失効。ゲストは即時削除可 | PIM 失効ログ・ゲスト削除ログ |
| 「変更が勝手に本番に入らないか？」 | 本番昇格は顧客の承認が必要（Solution の Dev→Test→Prod フロー） | Solution 変更履歴・昇格承認ログ |
| 「何かあったとき遡って調べられるか？」 | 保存期間は顧客ライセンスに依存。E5 なら1年、Azure Monitor 連携で無期限も可 | Entra + Dataverse の監査ログ |
「証跡」の列は、顧客の実際のライセンス構成に応じて数値を書き換えて使う。M365 Free のまま「1年分のログが残る」とは言えない——正確な保存期間を確認してから表を完成させることが誠実な対応になる。
「完全セキュア」とは言わない
「完全セキュア」と言った瞬間に、説明責任は崩れる。
IPA「情報セキュリティ10大脅威2026」が指摘する懸念の筆頭が「理解不足に起因する意図しない情報漏洩」だ。完全セキュアを標榜することは、理解不足を宣言するのと構造的に近い。
正確な言い方はこうだ：
- 「鍵と組織データは顧客環境の外に出ない設計になっています」
- 「権限は時限付きで、作業後は自動失効します」
- 「全操作は監査ログに記録され、保存期間はお客様のライセンスに応じて〇日です」
- 「想定外の事態が起きたときに、何がいつ起きたかを遡れる証跡があります」
完全な安全を保証することは構造的に不可能だが、経営層・株主が本当に求めているのは「何かあったときに説明できる構造があること」だ。この誠実な開示が、顧客側の信頼継続につながりやすい。
→ 個人 PC に M365 Developer 検証環境を持ち、この設計パターンを手元で動かしてから提案に持ち込む方法については「関連記事：個人 PC 開発戦略（M365 検証環境の作り方）」を参照。
まとめ
AI 外部委託の説明責任は、「完全セキュア」という言葉ではなく「渡せる層と渡せない層の設計」「時限昇格と即時撤収の仕組み」「操作ログの保存期間の明示」という構造で担保する。
次の一歩
まず顧客環境のライセンスを確認する（Entra ID Free / P1 / P2 / E3 / E5）。保存期間が決まれば、「問い × 統制 × 証跡」一枚表の「証跡」欄を埋められる。PIM を使うなら Premium P2 の有無を先に確認する。
関連リンク
- [Power Automate と Logic Apps、3年後の保守者で決める]（関連記事リンク予定）
- [本番データのマスキング設計境界——外部委託で詰めるチェックリスト]（関連記事リンク予定）
- Microsoft Learn「What is Privileged Identity Management?」https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure
- Microsoft Learn「Microsoft Entra data retention」https://learn.microsoft.com/en-us/entra/identity/monitoring-health/reference-reports-data-retention