Posts

役職名をもとにアクセスグループを設計しているなら、例外が増えるたびに設計が崩れていく構造に入っている。 同じ「課長」でも決裁権限が違う人がいる。部門によって「支社長」と呼ぶポジションが、別部門では「部長」と呼ばれる。 この2つの問題を役職名で解こうとすると、例外グループが増え続けるか、手動判断が常態化するかのどちらかに向かう。 判定軸を役職名から「その人が管理する範囲（スコープ）」に移すことで、例外を構造の外に出せる。以下、破綻のパターンと修正設計を整理する。 役職名が「表示」である理由アクセス設計で役職名を使う発想は自然だ。人事システムやMicrosoft 365（以下M365）のユーザー属性に役職名は入っているし、「課長以上はこのリソースへアクセス可」というルールは口頭でも伝わりやすい。 ただし、役職名は名刺の文字——つまり表示のための情報であって、アクセスを決める判定軸ではない。 アクセスを決めるべきは管轄地図の区画だ。「その人がどの範囲の業務・データを担当しているか」という情報は、役職名から計算では導けない。同じ「課長」でも、担当課が違えば見るべきデータは違う。同じ「部長」でも、特定プロジェクトの都合で一段上の権限を持つケースがある。この差は人事システムの役職コードには含まれていない。 NIST SP 800-162（Guide to Attribute Based Access Control、2014年・2023年更新）は、役職・職責を軸にするRBAC（Role-Based Access Control：役割ベースアクセス制御）が、兼務・例外・部門横断業務に対応しようとするとロール数が増加し続ける構造的問題を公式に認識している。また、Gartner IAM Summit 2024の場では「誰が何にアクセスできるか？そもそもアクセスすべきか？」という基本問を答えられないIAM（Identity and Access Management：アイデンティティとアクセスの管理）担当者が多いという指摘がなされた（Axoniusブログ経由・2次ソース）。名前軸の設計が崩れるのは運用の問題ではなく、設計の構造上の必然だ。 破綻が起きる3つのパターン役職名ベースの設計が壊れるとき、たいていこの3パターンのどれかが起きている。 パターン1: 同じ役職名で権限が違う「課長グループ」にアクセス権を設定した後、「A課長は経営企画も兼務しているので一段上の権限が必要」という依頼が来る。グループに例外フラグを付けるか、別グループを作るか——どちらを選んでもその場しのぎになる。次の例外が来るたびに同じ判断を繰り返す。 パターン2: 部門ごとに呼称が揃わない営業部門では「支社長」、本社管理部門では「部長」、製造部門では「工場長」——これらが同じ権限スコープを持つとき、呼称の等級を比較して共通グループに収める作業が発生する。組織変更のたびにこの比較表が更新の対象になる。 パターン3: 異動・兼務のたびに設定変更が必要になる役職名軸の設計では、異動や兼務が発生するたびに「旧グループから削除して新グループに追加する」という手作業が伴う。作業が常態化し、設定漏れが権限の過不足を生む。業界の実務知見として、1,000名規模の組織でもロール（グループ）定義が数千に達するケースが広く認識されている（Evolveum IAMドキュメント・2次ソース）。 設計パターン3点セット判定軸を管理範囲に移すとき、以下の3点を設計に組み込む。 1. 名前→範囲の対応表を1枚に隔離する役職名と管理範囲の対応関係を、権限グループとは別の1枚のテーブルに切り出す。 [ユーザー] → [名前→範囲対応表] → [スコープ定義] → [リソース権限] 権限グループ側は「スコープA担当」「スコープB管理者」という管理範囲ラベルを持ち、役職名は対応表の入力値になるだけで権限グループ側には現れない。 組織変更や呼称変更があったとき、更新するのは対応表だけでよく、権限グループ側は無改修になる。 設計の比較 役職名軸 管理範囲軸 例外対応 新グループを追加 対応表に1行追加 呼称変更 グループ名も変更 対応表だけ変更 組織変更 グループ構成を再設計 スコープ定義のみ見直し 異動処理 複数グループを更新 対応表のエントリを更新のみ 2. 例外は「人ごとの上書き」データで吸収する同じ役職名でも権限が違うケースをスコープ計算で解こうとすると、ルールの置き場所がなくなる。「この人だけ一段上」という例外は、計算ロジックではなく人ごとの上書きエントリで持つ。 実装上は、ユーザーに紐づく「スコープオーバーライド」テーブルを対応表の隣に用意し、上書き値がある場合はそちらを優先する構造にする。 [ユーザーID] × [上書きスコープ] × [有効期限] × [申請理由] 有効期限と申請理由を必須フィールドにしておくことで、いつ・なぜ付与された例外かを追跡できる状態を保てる。過剰権限が放置されるとセキュリティインシデントにつながる経路は実際にある（IDSA「Trends in Securing Digital Identities」2024：過去の調査データで不適切な権限管理が侵害の36%、過剰権限が21%に関与）。上書きデータは定期的にレビューし、不要になった時点で削除する運用とセットにする。 ...

「タイムアウト0件、合格」という結果が出た。だが、その数値は本当に測りたいものを測っていたか。 実機検証でもっとも見落とされがちなのは、対象システムの不具合ではなく計器（測定の前提）の誤りだ。 きれいな結果ほど疑われず、そのまま結論に変わりやすい。 「計器を疑う」という視点パイロットが視界ゼロの気象条件で飛行するとき、コックピットの計器だけを根拠に操縦する。FAA（米連邦航空局）はこの飛行方式をIFR（Instrument Flight Rules）と定義している（FAA Pilot/Controller Glossary 2024年）。計器が正しいことを前提とした運用だ。 この話を逆にすると、ソフトウェア検証への応用になる。「計器が正しい」という前提を意識せずに検証結果を読むと、計器が狂っていても気づかない。「計器を先に疑う」というのは著者が航空のアナロジーを逆転させた言い方で、正式な学術用語ではない。ただ、実機検証の現場で繰り返しぶつかった構造を説明するのに、航空のアナロジーを逆転させた視点が有効だった。 SREやDevOpsのオブザーバビリティ文脈では、instrumentation（計器化）は「センサー・ゲージ・アラームの集合体でシステム状態を観測可能にする行為」を指す（SRE School 2026年）。その計器自体が誤った値を出していたら、オブザーバビリティは機能しない。 以下で、実機検証で実際に踏んだ4種類の計器の嘘と、それぞれへの対処を整理する。 計器の嘘1: 環境の汚染前回の検証データが環境に残留していて、新しい測定が汚染される。典型的なのは「解決済み件数が投入件数を上回る」という数値が出るケースだ。物理的にあり得ない値なので、見た瞬間に気づけば問題ない。だが、きれいな数値の場合はそのまま通過してしまう。 対処：サニティチェックを先に走らせる。 サニティチェックとは、「主張や計算結果が正しい可能性があるかを素早く評価する基本テスト」（Wikipedia – Sanity check 2024年）だ。明らかに誤った結果クラスを除外するための確認で、IEEEやSEIの正式標準用語ではなく業界慣用語にとどまるが（Software Testing Help 2024年）、実務では有効なファーストステップになる。 チェック観点 確かめること あり得ない値 件数の逆転、マイナス値、100%超え 前回データの残存 ジョブテーブルに旧データが混在していないか 環境の初期化 本当にクリーンな状態から始めているか 測定を始める前に、「この環境は本当に前回と切れているか」を確かめる。これが最初の手続きだ。 計器の嘘2: 指標の取り違え「処理時間を測った」という記録が、実際には「キュー待ち時間＋実行時間」の合計だったというケースがある。見たかったのは実行時間だけなのに、待機時間が混入していると、数値の意味が変わる。 たとえばキューが詰まっている状況では総経過時間が長くなるが、実行自体は速い場合がある。反対に、キューが空いていれば見かけ上速く見えるが実行処理が重いこともある。指標の定義を事前に明示せずに測ると、「速い/遅い」の結論が的外れになる。 対処：測定対象の定義を測定開始前に書き留める。 「どこからどこまでを時間とするか」「何個のジョブを対象とするか」「並列度はいくつか」——これらを検証レポートの冒頭に書いておく。指標の定義は後付けにしない。 なお、このパターンの技術的な詳細（Dataverse非同期ジョブのキュー構造とタイムアウトの関係）は関連記事「async-timeout-diagnosis」を参照。 計器の嘘3: データ消失（成功ジョブの自動削除）Power Platform（Dataverse）の非同期ジョブ処理で遭遇する、見落としやすい仕様がある。 Microsoft Learnの公式ドキュメントによれば、Dataverse AsyncOperationテーブルの成功済みシステムジョブは、デフォルトで30日後に自動削除される（Microsoft Learn 2025年）。失敗・キャンセルの場合は60日間保持されるが、成功ジョブの保持期間はそれより短い。 “All environments are configured with out-of-box bulk delete jobs to delete successfully completed workflow system jobs that are older than 30 days.” — Microsoft Learn, Delete completed system jobs and process log ...

特定の PoC 環境で、Dataverse 非同期ジョブのキュー待ちが最大13分に達したとき、タイムアウトは1件も発生しなかった。「2分制限のはずでは」と思ったとしたら、診断の起点が間違っている。 タイムアウトは実行時間にしかかからない。ログで見ている「総経過時間」は、キューに放り込んでから完了するまでの wall-clock であり、その大半が「拾われ待ち（ディスパッチ待ち）」である可能性がある。この区別が曖昧なまま診断すると、問題のないジョブを危険視するか、本当に問題のある実行時間の長さを見逃す。 結論を先に示す。Dataverse の AsyncOperation テーブルには CreatedOn / StartedOn / CompletedOn の3時刻フィールドがある。これを分離して計測すれば、総経過時間の内訳がわかり、タイムアウト診断が正確になる。 13分待っても、タイムアウトしないDataverse の非同期サービスは FIFO（先入れ先出し）のマネージドキューを持つ。ジョブが登録されると、キューに投入され、非同期サービスが「拾いに来る」まで待つ。この待ち時間はタイムアウトのカウントに含まれない。 Microsoft Learn の公式ドキュメント（Asynchronous service (Microsoft Dataverse)、2025年確認）には次の記述がある。 sending the request asynchronously doesn’t provide more execution time 非同期登録にしても、実行タイムアウト（プラグイン・ワークフロー共通で2分＝120秒）は変わらない。制限されているのはあくまで「実行時間」であり、「キューに入ってから拾われるまでの待ち時間」は制限の対象外だ。 レストランの席待ちに例えると、タイムアウト2分は「席に着いてから注文・食事・会計までの時間制限」だ。席待ちで40分並んでいても、それはタイムアウトに数えられない。13分のキュー待ちがあっても、その後の実行が2分以内に収まれば、タイムアウトは発生しない。 ただし、上記の「最大13分のキュー待ち」は特定の PoC 環境での観察値であり、本番環境や他製品での再現を保証するものではない。 判断軸：拾われ待ちと実行時間は別物だ非同期ジョブの経過時間は、大きく2つに分解できる。 区間 内容 タイムアウト対象か 拾われ待ち キュー投入 → 実行開始 対象外 実行時間 実行開始 → 実行完了 対象（2分・120秒） タイムアウト診断で見るべきは、右列が「対象」の実行時間だけだ。ログの総経過時間を見ていると、拾われ待ちの長さがそのまま「危険なシグナル」に見えてしまう。逆に、実行時間が2分に近づいていても、総経過時間が短ければ見過ごす可能性がある。 計測の単位を間違えると、診断の方向が最初から狂う。 AsyncOperation テーブルで3時刻を分離するDataverse の AsyncOperation テーブル（System Job (AsyncOperation) table/entity reference、2025年確認）には、以下のフィールドが存在する。 フィールド 意味 診断での役割 CreatedOn ジョブ作成（キュー投入）時刻 拾われ待ちの開始点 StartedOn 実行開始時刻 拾われ待ちの終点・タイムアウトカウント開始 CompletedOn 実行完了時刻 実行時間の終点 ExecutionTimeSpan 実行時間（数値） タイムアウト評価の直接対象 計算式はシンプルだ。 ...

並列ワーカーを増やしたのに処理が遅くなった、あるいは不安定になった——そういう状況で真っ先に疑うべきは、ボトルネックが「容量の問題」ではなく「通り道の渋滞」になっている可能性だ。 この2つは別の病気であり、治療法が逆になる。容量不足なら並列化は効く。だが渋滞が原因なら、並列を増やすほど状況が悪化する。どちらの病気かを見分けることが、チューニングの出発点になる。 規模を倍にしたら、裏処理が6倍遅くなった実機での観測を出発点として示す。 処理対象レコードを5万件から10万件——規模を2倍——に増やした。書き込み自体はほぼ線形にスケールした。ところが、書き込み後に走る裏処理（プラグイン・同期処理）の1件あたりの処理時間が約6倍に膨らんだ。 レコード数は2倍なのに、1件あたりのコストが6倍。これは容量不足で起きる線形のスケール超過とは異なる動きだ。「通り道」に何かが詰まって、ピタゴラスイッチ的に連鎖悪化していた。 環境前提の確認：チューニング対象はリクエスト制限のあるプラットフォームで動く同期処理。スペックアップで解決する問題ではない。 2種類の遅さの病気——型Aと型B処理が遅い原因には2種類あり、対策が逆になる。 観点 型A（容量不足） 型B（直列渋滞） 症状 エラーではじかれる・OOM・タイムアウト じわじわ遅くなる・不安定 限界の形 硬い壁（急激に落ちる） なめらかな遅延爆発（利用率が上がるにつれ非線形に悪化） 並列を増やすと 速くなる 遅くなる 診断の手がかり ログにリソース不足の記録が残る ログは正常・ただしキューの待ち時間が長い 対策の方向 スケールアップ / スケールアウト 1単位の仕事量を絞る・通り道を太くする・時間分散 冒頭の6倍膨張は型Bの典型だ。エラーは出ていない。ただ、ある1本の共有資源への書き込み競合がひたすら積み上がっていた。 待ち行列の経済——利用率が上がると待ち時間は非線形に爆発する型Bの「なめらかな遅延爆発」の数学的な構造は、待ち行列理論で説明できる。 コーヒーショップを想像してほしい。レジは1台、客は次々と来る。客が少ないうちは注文してすぐ受け取れる。客が増えてレジの処理能力の80%くらいに達しても、多少の列はできるが許容範囲だ。ところが90%を超えたあたりから、列が急激に伸び始める。99%に近づくと、列は事実上無限に長くなる。 これはコーヒーショップだけの話ではなく、1つの共有資源に複数のワーカーが書き込みを競合させる構造すべてに当てはまる。 Kleinrock の教科書（Queueing Systems, Volume 1: Theory, 1975年, Wiley）が示す M/M/1 キューイングモデルの公式がその理由だ。 W ∝ 1 ÷ (1 − ρ) W が待ち時間、ρ（ロー）が利用率（到着率 ÷ 処理率）。利用率が1に近づくほど、待ち時間は際限なく膨らむ。 利用率 ρ 待ち時間の倍数（基準比） 50% 約2倍 80% 約5倍 90% 約10倍 99% 約100倍 並列ワーカーを増やすということは、1本の共有資源への到着率 λ を上げることだ。λ が上がれば ρ が上がり、待ち時間は非線形に爆発する。「並列を増やしたのに遅くなった」は、数学的な必然になる。 なぜDBのトランザクションログが「1本の直列資源」なのかバッチ処理や同期処理の文脈で、この「1本の共有資源」の実体になりやすいのがDBのトランザクションログだ。 ...

Azure や Power Platform の管理画面でつまずく場所には、だいたい共通した理由がある。 ボタンの存在・押す順序・固定された名前・エラーメッセージ——これらは設計者の気まぐれではなく、システムが守る「不変条件」を画面に物理化したものだ。 環境前提：Azure ポータル / Power Platform 管理センターの操作権限があること。GUI は更新が速いため、以下の実例はいずれも 2026 年時点の確認情報として読むこと。 GUIでつまずく場所には「理由」があるクラウドの管理画面を触り始めた頃、ボタンがグレーアウトしている理由が分からず、手順を最初から読み直した経験はないだろうか。エラーメッセージを Google に貼り付けて、それっぽい Stack Overflow の回答を試す——という作業を繰り返した日数を足し合わせると、それなりの時間がかかってきたのではないか。 だが、ほとんどの詰まりには構造的な理由がある。 ボタン・順序・既定値・固定名・エラーは、すべて「不変条件の物理化」だ。 不変条件とは、システムが設計上必ず守る制約のこと。名前の衝突禁止、権限の分離、リソースの依存関係——これらを画面の操作制約として見えるようにしたのが、GUI の「詰まりポイント」の正体だ。 このフレームで読むと、暗記していた操作手順が「必然」として理解できるようになる。 不変条件5型：ボタン・順序・エラーはここから来る以下の5型は、クラウド GUI で頻繁に現れる不変条件のパターンを筆者がまとめた分類だ（公式分類ではない）。個々の事例は後述の Microsoft Learn 一次ソースで裏付け済みだが、5型としての体系化は提案書起点の整理であることを断っておく。 型 名称 一言での意味 ① 一意性 システムが専有する名前・文字列は使えない ② 所有と権限の分離 身分の管理者（誰を管理するか）≠ 資源の所有者（何を操作できるか） ③ 依存リソースの存在順 先に作るものが決まっている。順序を逆にすると詰まる ④ 安全の二要件 「昇格する」と「解除する」は別の操作。どちらかだけでは安全は成立しない ⑤ レイヤー切り分け どの層が止めているかで、対処者も意味も変わる この5型を頭に入れておくと、初見のエラーでも「この詰まりは③番だな」と当たりをつけられるようになる。 4事例で読む：不変条件はこう画面に出てくる(A) PIMの昇格ボタン → 解除ボタン ＝ 安全の二要件（型④）Azure PIM（Privileged Identity Management：特権 ID 管理）では、高権限ロールは「Eligible（適格）」状態で休眠している。使うときだけ Activate（昇格）し、作業後は Deactivate（解除）する。 「なぜ昇格後に解除ボタンが出てくるのか」——これは UI の癖ではない。JIT（Just-In-Time）アクセスという設計意図が画面の操作制約として現れた形だ。 公式ドキュメントには次のように明記されている： “Privileged Identity Management provides just-in-time privileged access to Microsoft Entra ID and Azure resources.” “Eligible assignments require the member to activate the role before using it.” ...

CreateMultiple（バルク作成 API）を使ったのにジョブが大量に積まれる。あるいは処理速度が単発と変わらない。原因の多くは受け手にある。 送る側がバルクになっても、受け取るプラグインが「1件ずつ処理」のままなら、Dataverse は内部でバルク要求を件数分の単発イベントに分解し、既存プラグインを N 回個別に発火させる。この挙動が「縮小発火」（公式呼称：message pipelines merged の逆方向動作）だ。 結論を先に言う。受け手のプラグインを CreateMultiple イベントに登録し直し、EntityCollection をまとめて処理するロジックに書き替えて初めて、バルク化の効果が出る。 天井は消えない——ただし、正直に言えば「移る」だけだ。それも含めて説明する。 なぜ受け手が「1件ずつ」だと遅いのかMicrosoft Learn 公式ドキュメント（2026年時点）には次の一文がある： “When you use a bulk operation message, the respective Create and Update event occurs for each Entity instance in the Targets parameter.” N 件を CreateMultiple で送ると、Create に登録されたプラグインは N 回個別に呼び出される。バルク API を叩いた送り側からは 1 リクエストに見えていても、受け手の世界では N 回のプラグイン実行サイクルが回る。 これが「縮小発火」（message pipelines merged の逆方向）と呼ぶ挙動の正体だ。公式ドキュメントで明示されており、仕様通りの動作——つまり、バグではない。 この構造で問題になるのは、同期プラグインの実行時間だ。公式は「同期プラグインが 2 秒を超えると深刻なパフォーマンス低下につながる」と明記している。100 件のバルク要求で縮小発火が起きていれば、同期プラグインは合計で最大 200 秒分のサイクルを費やすことになる。送る側だけをバルクにしても、ここが律速だ。 受け手の直し方——CreateMultiple への移行手順プラグインを CreateMultiple イベントに対応させる方向は任意だが、公式ドキュメントは「パフォーマンス向上はバルク版に書き換えたプラグインのみが享受できる」と明示している。実質、書き替えが必要になる。 移行の手順は次の流れで踏む。 ステップ 1：既存の単発プラグインを無効化（または削除）してから移行する これを省くと二重実行のリスクがある。公式は次のように明記している： ...

Lookup（関連レコードへの参照）を埋めるとき、内部 GUID を自前で取りに行くか、業務コードのままサーバーに委ねるかは、設計の細部に見えて環境移行の成否を決める。 結論を先に述べると、委譲が既定・自前は例外だ。 内部 GUID は dev/test/prod で別値になる環境ローカルな値であり、移送側が抱え込んだ瞬間に「build once, deploy many」の可搬性は失われる。 開発では動いたのに、本番で関係が空になったDataverse への取込定義を開発環境で完成させ、テストに展開した途端に Lookup フィールドが空になる。原因の多くは、開発環境で取得した内部 GUID をそのまま成果物に焼き込んでいることだ。 Dataverse の内部 GUID（レコードの主キー）は、レコードが作成された環境内で自動発番される。dev で a1b2c3... だったものが、test の同じ取引先レコードでは d4e5f6... になる。環境をまたぐたびに別の値になるため、GUID を直接参照した取込定義は他の環境で動かない。 Microsoft Learn の OData dataflow 移行ガイド（Migrate Data Between Dataverse Environments Using the OData Connector）は次のように明言している。 代替キーが必須。親テーブルの代替キーがないと子テーブルの Lookup カラムを設定できない。 業務コードは環境が変わっても同じ値を持つ。社内の取引先コード・品番・従業員番号——これらは dev でも prod でも変わらない。環境ローカルな GUID ではなく、環境不変の業務コードで Lookup を張るのが自然な理由はここにある。 責任分界：サーバーが ID を解決するのが自然「業務コード → 内部 GUID」の変換をどちらが担うか。移送側がこれを担うとは、自分が所有していない ID を引きに行って管理下に置くことを意味する。これは**漏れた抽象（leaky abstraction）**と呼ばれる設計上の問題だ——本来サーバーが担うべき責任を移送側に漏らしている状態を指す。 内部 GUID を所有しているのは Dataverse のサーバー側だ。業務コードを受け取り、該当レコードの GUID を探して Lookup を解決する作業は、そのまま「ID の所有者」であるサーバーが担うのが責任分界として自然になる。 ...

Power Automate も Power Apps も Azure Logic Apps も、Dataverse に対しては同じ Web API を叩いている。 「このツールではできない」と止まるとき、問題は API に届いていないことではなく、そのコネクタが必要な機能を露出しているかどうかに 9 割ある。 壁の正体を理解すれば、問い直すべき場所が変わる。 全ツールが同じ API に届いているDataverse の入口は、すべてのツールで共通だ。Power Automate のコネクタも、Power Apps のフォームも、Azure Logic Apps のアクションも、最終的には Dataverse Web API（OData v4 実装） を経由してサーバーと通信する。 この構造は公式ドキュメントで裏付けられている。Dataverse Web API は「Organization service のすべてのメッセージを functions/actions として露出している」（Microsoft Learn: Web API types and operations, 2025 年時点）。コードで直接 Web API を呼べば、サーバーが持つ全操作にアクセスできる。 コネクタの内部も同様だ。「Connectors create a proxy or wrapper around an API that allows the underlying App Service Environment to talk to Microsoft Power Automate, Power Apps, Azure Logic Apps and Power BI」（dev.to/wyattdave: The 4 APIs of the Power Platform）。コネクタは直接の接続ではなく、Azure APIM（API Management）を経由した OpenAPI ラッパーとして機能する。すべてのコネクタホストは、この APIM 経由で同一の Dataverse バックエンドに到達している。 ...

Dataverse への取込ツールは、好みや習熟度で選ぶと後で詰まる。 判断軸は 2 つだけ——代替キーで Lookup を解決できるか、secretless Managed Identity（MI）で繋げるか。 この 2 軸を両方満たすツールは、2026 年 6 月時点で Azure Functions（SDK for .NET）と Azure Data Factory（ADF）に限られる。 2 軸で絞る——なぜ「Lookup 解決力 × MI secretless」なのかDataverse の行レベルセキュリティ（Row-level Security）は、レコードの「所有者（owner）」フィールドを起点に動く。 この所有者は、取込レコードに Lookup 列（参照列）が正しくセットされているとき、初めて自動設定が発火する。 つまり、取込ツールが Lookup 列を解決できなければ、所有者は設定されず、行セキュリティはそもそも機能しない。 認証が Managed Identity（secretless）でない場合は、シークレット管理の運用負荷と漏洩リスクが別途発生する。 2 軸を分けて評価しても意味が薄い。取込ツールの選定は、この 2 軸の同時達成で決まる。 ツール能力マトリクス環境前提：Dataverse への書き込み、代替キー（Alternate Key）によるインライン Lookup 解決、secretless MI 認証の 3 要件で評価する（2026 年 6 月時点）。 ツール 代替キー Lookup 解決 MI secretless 接続 両軸評価 Power Automate（Dataverse コネクター） △ 行操作は可、複雑な Lookup 解決は制限あり △ SP + Secret は対応済み。secretless MI は標準コネクターでは未対応。HTTP / Custom Connector 経由で実現可能だが設計コスト増 △ Power Apps Dataflows（Power Query ベース） △ 代替キー設定済みテーブルなら解決可 △ 公式ドキュメントに MI 接続手順の記載なし（2026 年 6 月時点）。SP + Secret が一部利用可 △ Azure Functions（SDK for .NET） ✓ EntityReference + 代替キーで GUID 不要 ✓ ManagedIdentityCredential で secretless 対応 ✓ Azure Data Factory（ADF） ✓ Lookup Activity 等で対応 ✓ MI 対応コネクター ✓ 注意：Azure Data Factory の Mapping Dataflows は MI 接続に対応しているが、Power Platform の Power Apps Dataflows とは別製品。Power Apps Dataflows（Power Query ベース）と ADF Dataflows を同一視しないこと。 ...

顧客の開発案件を受けていれば、一度は似た場面に出くわしているはずだ。 「個人PCでの開発はセキュリティ上NGです」。「本番データをそのまま使わないと動作確認できません」。「弊社の開発環境に入ってもらわないと進めようがありません」。 こちらとしては、本番データを一切受け取らず、構造（スキーマや設計ファイル）だけを外に出してもらい、成果物をファイルで納品する方が、データ漏洩のリスクは構造的に低い——と説明する。だが、話が通りにくい。賛同の声もほとんど届いてこない。 「外から内へ」という設計は、技術的には成立している。ISO/IEC 27002:2022のControl 8.33は「合成データを本番データよりも優先して使用すること」を明示しており、日本でも経産省が令和7年改正版の情報セキュリティ管理基準でこれを引用している。個人情報保護法第25条の委託先監督義務も、本番データを外に出さない設計であれば根本から負担が消える。制度的にも技術的にも、筋は通っている。 それでも公の声が上がらない。なぜか。 安心感と安全は、同じではないセキュリティ研究者のBruce Schneierは2003年の著書『Beyond Fear』の中で、「security theater（保安劇場）」という概念を定義した。「安全を実質的に向上させることなく、より安全と感じさせるセキュリティ対策」のことだ。Schneierは後年のブログでも補足している——「security theaterが完全に無意味だとは言っていない。愚かな攻撃者を追い払う効果はある。だが、形式的な安心感と実質的な安全改善は、別物として理解する必要がある」と。 日本の企業セキュリティによく見られる「持込PC禁止」「入館時に誓約書」「外部委託先に本番データコピーを渡してアクセス管理」という形式は、この視点で見ると興味深い位置に立つ。 本番データへのアクセス経路を構造的に絶つのではなく、「誰がどの端末で触るか」という人・機器の管理で安心感を作っている。委託先に本番データを渡しながら、渡した後の取り扱いを誓約書で縛る。これは「データを外に出さない」設計ではなく、「出した後のリスクを証書で管理する」設計だ。 形式的な安全と実質的な安全の混同——Schneierの言葉を借りれば、これがsecurity theaterの構造に近い。禁止系のルールが全く無意味だと言いたいわけではない。ただ、「見た目で勝つが実質で負ける」と「実質で勝つが見た目で負ける」の二択を迫られたとき、どちらが選ばれやすいかは、もう少し考える必要がある。 なぜ採用を罰する構造になっているのか「外から内へ」の設計を採用しようとした方針決定者を想像してみてほしい。 もし本番データが漏洩したとき、その決定者は責任を問われる。採用前のやり方と違うことを選んだ判断として、批判の的になる。一方で、設計が機能してデータ漏洩が「起きなかった」場合、その成果は目に見えない。ゼロのままだ。生産性が上がっても、その恩恵は現場エンジニアか事業部門が受け取り、方針決定者のパフォーマンス評価には反映されにくい。 下振れリスクは決定者が個人で負い、上振れの果実は組織に拡散する——こうした誘因の非対称があるとすれば、「前例のないやり方を採用しない」という判断は、個人として合理的だ。構造的に推測できる話として、公の賛成表明が出にくいのはここに原因の一端があると見ている。 加えて、セキュリティ業界そのものの経済構造も関係している。本番データへのアクセス管理・暗号化・通信監視といったソリューションは、「本番データが外に出ることを前提とした上で、どう守るか」というモデルで設計されている。「そもそも本番データを外に出さない」設計が普及すると、このモデルの一部は需要を失う。逆説的だが、「本番データを出さない」方向の需要は急速に膨らんでいる。合成テストデータの市場規模は2024年時点で18億ドル超、2029年には82億ドルへの成長が予測されており（GlobeNewsWire, 2026年1月）、NVIDIAが合成データスタートアップのGretel.aiを2025年3月に買収したことも、その潮目を示している。技術の方向性は変わりつつある。制度的な慣性が、そこへの移行を遅らせている。 多重下請けの構造が、ファイル一個を拒む日本で特にこの設計が普及しにくい理由が、もう一層ある。 公正取引委員会が2022年6月に発表した「ソフトウェア業の下請取引等に関する実態調査報告書」は、約4,700社の回答と大手・中堅ITベンダー16社へのヒアリングに基づく調査だ。この報告書は、ソフトウェア開発業務において4次下請け・準委任契約（SES）で最大5社が中間に入るケースを確認している。エンドユーザーへの質問が途中の業者で止まる、メール連絡がたらい回しになる——こうした実態が記録されている。 この構造の中で、「個人が構造ファイル1個を直接顧客に納品する」というモデルはどうなるか。中間に入るベンダーにとって、それは自社の存在意義を問い直す話になる。人月で工数を積み上げ、複数社が中間で利益を抜く商習慣は、「一人がファイル1個を直接届ける」モデルとは利益構造として相性が悪い。 啓蒙や説明では動かないのは、ここに理由がある。情報が届いていないのではない。構造が動くことへのインセンティブが、関係する多くのプレイヤーに存在していないのだ。 技術が先行し、制度が追いつかない一方で、開発の技術環境は別のスピードで変わっている。 元OpenAIのAndrej Karpathyが「vibe coding」という言葉をXに投稿したのは2025年2月のことで、「自然言語で開発の意図を渡し、コードの存在を忘れる」という開発スタイルを描いたその投稿は4,500万回以上閲覧された。彼は同年6月のYCombinator講演でも「自然言語が新しいプログラミングインターフェース」になるというパラダイムを論じた。ソロ開発者のPieter Levelsは月収25万ドル超のポートフォリオを一人で運営し、Sam Altmanは「AIなしでは不可能だった一人で10億ドル企業が生まれる」という予測を2024年に語っている。 技術的な可能性は急速に現実に近づいている。「外から内へ」設計——本番データを受け取らず、構造だけを持ち出し、成果物をファイルで納品する——はそのモデルと親和性が高い。障壁は技術にない。制度的な誘因と慣行の慣性にある。 律速は理解ではなく前例だでは、どう動くか。 「正しいと思うなら声を上げればいい」という話ではない。構造を前にして個人が声を上げても、現状の誘因構造では個人が批判のリスクを引き受けるだけになる可能性が高い。 有効なのは、小さく実証し、前例を作ることだ。「見た目の安全」チェックも通る形で実装する——別名スキーマで設計し、納品前の出庫スクラブ（本番識別子の除去確認）を記録に残し、完了後の削除証明を添える。ISO 27002:2022 Control 8.33が要求する「別途承認手続き・監査証跡」の仕組みは、まさにこの見た目の安全チェックと重ねて使える。 制度的チェックをクリアした上で、実質的な安全も確保する——その組み合わせの前例が積み上がったとき、慣行は動く。 Schneierの言葉を引き返せば、安心感と安全は同じではない。だが、動き出すためには安心感も必要だ。実質だけを主張して動かないより、見た目のチェックも添えて前例を一つ作る方が、律速は早く解除される。 今週末の1時間：自分が関わっている案件で「本番データを受け取らなくても設計できる部分」を一つ特定してみる。スキーマだけ外に出して構造を組む試作を、個人PC上で動かしてみる。前例は説明から生まれるのではなく、動いた実績から生まれる。 関連記事：顧客環境に拘束された時間は、あなたの資産にならない——「外から内へ」設計の実務戦略版 関連記事：開発環境への本番データ持ち込み、氏名マスク済みで安全と言い切れるか——本番データ識別子設計の技術版 関連記事：AIを使った成果物納品、キーもPIIも渡さない設計——build/bindの実務 how