Posts

Genspark は複数の AI を束ねて使い分けるプラットフォームだ。だからどのモデルが賢いかを選ばなくていい。 AI ツールは数が多い。どれが賢いか。どれに課金するか。賢いモデルが出るたびに乗り換えるのか。考えるほど手が止まる。 その迷いを Genspark が消す。これはその完全ガイドだ。 公開 45 日で利用者 200 万人作ったのは MainFunc という新興企業だ。主力の Super Agent は 2025 年 4 月に公開され、45 日で利用者 200 万人、年換算売上（ARR）3,600 万ドルに達したと共同創業者が語っている（インタビュー, 2025）。 数字は会社の公表や調査会社の推計で、第三者が完全に検証したものではない。それでも短期間でこれだけ集まるのは、それだけ使われているからだ。中身を見ていく。 どのモデルが賢いか気にしなくていいこれが Genspark の一番の価値だ。 個人で働く人にとって、ツールの優劣を調べる時間は成果を生まない。課金先を吟味して乗り換える時間も同じだ。Genspark に寄せればその時間が消える。 浮いた時間を本業に回せる。これが効く。 何ができるのかここからは Genspark でできることを順に見ていく。知らない言葉も出てくる。ひとつずつ意味を添える。 相談相手になるGenspark のチャットは相談相手に向いている。中で複数の AI が答えを出すから視点が偏らない。 やりたいことの輪郭をここで詰める。考えがまとまったら、そのまま計画書の形に書き起こせる。 調べて形にするまで任せられるGenspark には Super Agent という機能がある。仕事を任せられる相棒だと思えばいい。 指示を一回投げると、調べる・整理する・資料にする、を自分で順に進める。「このテーマを複数のサイトで調べて比較表にして」と頼めば、調査から表作りまで通してくれる。一番腰が重い「最初の形を作る」が軽くなる。 作ったものが貯まるGenspark で作った資料や集めた情報は、AI Drive という置き場に残る。 先週の調べ物を今週の提案に使い回せる。一度作ったものが消えずに積み上がる。Pro 版なら gsk というコマンドで AI Drive を外からも操作できる。Claude から呼び出して中身を使うこともできる。 一次情報まで調べられるDeep Research という機能を使うと、要約で終わらず元のソースまで調べにいく。 数字や事実を出どころごと確かめたいときに効く。又聞きの要約で終わらせない。 構想は Genspark 作り込みは Claude Code使い分けをひとつ勧めたい。構想を固めるまでは Genspark が速い。実際のコーディングや細かい作り込みは Claude Code に分がある。 ...

SharePoint の「プロンプト集」フォルダを開く。 最終更新日は 8 ヶ月前。投稿者の名前は、すでに別の部署に異動している。 「使えるかもしれない」とクリックしたプロンプトの説明文には、退役済みのモデル名が書いてあった。 Teams のチャットを立ち上げて、「誰かこの業務で使えるプロンプト持ってませんか」と打つ。 こういう経験が、1 度や 2 度ではない人は多いはずだ。 1. 3 年分の蓄積が、なぜ一晩で使えなくなるのか具体的な場面を想像してほしい。 あなたのチームが、3 年かけてプロンプトを積み上げたとする。毎月の定例でメンバーが持ち寄り、担当者が週 2 時間を費やして整理した。200 件に達したとき、「ナレッジ資産」として経営報告に記載された。 2026 年 2 月、OpenAI が GPT-4o の退役を発表した。リリースからわずか 21 ヶ月だった（OpenAI 公式）。 GPT-4o 特有の挙動——長めのシステムプロンプトで安定する、特定の言い回しで精度が上がる——に最適化されたプロンプトは、次世代モデルで同じように動かない。GPT-4.1 は GPT-4o より「指示に文字通り忠実に従う」設計に変わったため、同じプロンプトでも挙動が変わることが OpenAI のプロンプトガイドに明記されている。200 件のうち何件が影響を受けるか。1 件の再テストに 30 分かかるとすれば、100 件で 50 時間だ。これが 1 回のモデル交代で発生する。 もし最初から「動作確認日」と「対象モデル」の 2 列をテンプレートに設けていたなら、どうなっていたか。 モデル更新のたびに「この日付より前・このモデル向けのプロンプト」として絞り込める。全件再テストの代わりに、影響範囲の特定から始められる。「GPT-4o の退役が出た。確認が必要な候補は 18 件」——そう絞り込める設計になっていれば、50 時間が 9 時間になっていた。差の 41 時間で、チームは次の業務自動化に着手できていた可能性がある。 「ポータルがある組織」と「ポータルが機能している組織」の差は、設計前の一手で生まれる。 2. ナレッジが腐る構造は、AI に限った話ではないAI ポータルの形骸化は AI 固有の問題に見えるが、ナレッジ管理全般の失敗パターンと重なる部分が大きい。 ナレッジ管理施策の 55% は変革管理の不足や経営層のサポート不足で失敗する（Helpjuice「Knowledge Management Trends and Statistics in 2025」2024-25 年）。能動的な管理がなければ、ナレッジベースの 20〜40% は無関連・陳腐化コンテンツを含むようになる（同調査）。デジタルワーカーの **47% が「業務上必要な情報を見つけるのが困難」**と感じる（Gartner 2023 年調査、二次引用）という実態は、「溜まってはいるが使えない」状態が広く常態化していることを示す。 ...

「ローコードでどこまでやれるか」——その境界は難しいかどうかではなく、操作の種類で決まる。行の作成・更新・読み取りはローコードの射程内。多対多の関連付け（所属・権限割り当て）だけは、通常のローコード操作では届かない。Patch 関数での直接書き込みは構造的に不可で、専用の Relate アクションを使うにはプレミアムライセンスと制限の確認が前提になる（2026 年 7 月時点）。 難易度ではなく、操作の種類で境界を引くPower Platform で業務ロジックを組むとき、ほとんどの処理はローコードで通る。Patch 関数でレコードを作成・更新し、Filter 関数で読み取り、条件分岐で制御する——これは難易度の問題ではなく、標準の道具が揃っているということだ。 壁になるのは多対多の「繋ぎ」だ。 比喩にすると：付箋に文字を書く・書き直す・読むことは自在にできる。このカードとあのカードを糸で結ぶ——多対多の関連付け——だけは、道具箱に入っていない。 Dataverse（マイクロソフトのクラウドデータプラットフォーム）の多対多関係には交差テーブル（junction table：テーブル間の関連を管理する中間テーブル）が存在するが、Canvas Apps の Patch / Collect 関数からは内部管理テーブルとして直接露出していない。Microsoft Learnのドキュメントには “the intersecting table is not available to use directly”（交差テーブルは直接使用できない）と明記されている。 操作 種類 Patch / 標準アクション直書き 専用の Relate 手段 レコードを作る / 直す 行の作成・更新 ○ — 階層の追従・廃止判定 行の更新・読み取り ○ — 所属させる 多対多の繋ぎ ✕ △（ライセンス・制限あり） 権限を割り当てる 多対多の繋ぎ ✕ △（ライセンス・制限あり） 覚え方：作れる・直せる・読める。ただ、繋げない（通常操作では）。 「できない」と「制限付きで可能」は別の話Patch 以外の手段として、Relate / Unrelate という専用の関数・アクションが用意されている。ただし、使える範囲は限られている。 手段 ステータス ライセンス要件 主な制限 Power Automate：Relate rows / Unrelate rows GA（正式版） Power Automate Premium フロー経由のみ Canvas Apps：Relate / Unrelate 関数 Preview（2024 年 3 月時点） Power Apps Premium オフライン非対応・フラグ有効化必要 Patch 関数で交差テーブルに直接書き込む 不可 — 構造的制約 設計判断として押さえておきたいのは 2 点。 ...

APIキーや署名鍵をローカルに置くほど、守るべき対象は増え、管理は難しくなる。 専用の保管サービス（以下「金庫」）に移すと、守るものが「秘密の値そのもの」から「誰が触れるか（権限）」へ変わる。 懸念は消えない。より守りやすい場所へ移動する。それが金庫導入で起きる設計上の変化だ。 手元保管の4弱点APIキーや認証トークンをローカル（.envファイル・ソースコード・PCのテキストファイル等）に置くことは、直感的には「手元にあるから安全」に見える。構造上は逆だ。 弱点 内容 複製が散る コード・設定ファイル・ドキュメントに貼るたびに同じ値が複数箇所に存在する 回収不能 一度コミット・共有した秘密は完全には回収できない 追跡不能 「誰がいつ使ったか」を後から確認する手段がない 失効不能 漏洩を疑っても、鍵の更新（ローテーション）の影響範囲が掴めない NIST SP 800-204（Security Strategies for Microservices-based Application Systems、2019年）は「トークンのシークレットキーはライブラリコードに含めてはならない。キー値はデータボルトソリューションに保管すべきである」と明記している（出典PDF）。 NSA/CISA「Defending CI/CD Environments」（2023年6月）も「パイプライン内のいかなる箇所でもシークレットをプレーンテキストで渡してはならない」と規定し、IaCテンプレートへのアクセスキーのハードコードをリスク事例として明示している（出典PDF）。 CISA/FBI「Product Security Bad Practices」v2（2025年1月）は「ソースコード内にハードコードされた認証情報は国家安全保障・経済安全保障・公衆衛生に対するリスクを著しく高める」と踏み込んでいる（出典PDF）。 複数の独立した公的ガイドラインが同じ結論に至っている。「ローカルに持つほど弱くなる」は直感と逆だが、構造的に正しい。 金庫が変えること：守る問いの場所が移動する専用保管サービスを導入すると、秘密の値を日常的に扱う必要がなくなる。代わりに「誰がこの金庫を開けられるか」という権限の管理が日常の守り方になる。 NIST SP 800-57 Part 1 Rev.5（Recommendation for Key Management、2020年5月）は「鍵を暗号境界の外部にプレーンテキスト形式で保管してはならない」原則を規定しており、同文書は鍵のライフサイクル全体（生成・配布・保管・更新・廃棄）を通じた保護要件を定めている（出典PDF）。「廃棄」が含まれている点が重要で、権限（アクセスポリシー）には取り消し・有効期限設定が存在する。ローカルの平文ファイルにそれはない。 守る対象が変わると、何が実現できるか。 ローカル保管：秘密の値を守る → 値が散らばり追跡・失効が困難 専用金庫：金庫を開ける権限を守る → 権限は集中管理でき、取り消し・更新がしやすい Azure Key Vault はすべての認証済みREST API呼び出しを AuditEvent カテゴリとして記録する（ログ仕様）。AWS Secrets Manager は CloudTrail 経由で GetSecretValue・CreateSecret・DeleteSecret 等の操作を記録する（CloudTrail統合）。「誰がいつ金庫を開けたか」を後から確認できる状態は、ローカル保管では再現できない。 秘密管理とは、守る問いをどこに置くかの選択だ。 ただし、金庫が保護するのは「保管中」と「取り出す瞬間まで（API輸送中）」に限定される。取り出した後のAPIキーの平文（生の値）は金庫の管轄外だ。AWS CloudTrail の仕様も「ログ内にシークレット値は含まれない」と明示している——取り出した後の使われ方は追跡対象ではない。この限界があるからこそ、「人が直接鍵を取り出さない（後述のManaged Identity）」方式が推奨される設計になる。 設計で詰めるチェック3点金庫を導入した後、以下3点を確認しないと設計が片手落ちになる。 1. 監査ログを有効化したかAzure Key Vault の AuditEvent ログはデフォルト無効だ。診断設定から手動で有効化しないと「誰がいつ開けたか」が記録されない（設定手順）。 ...

Dataverseで階層アクセス制御（BU単位でのデータスコープ設定）を設計すると、セキュリティロールの行数が数万〜十万に膨らむことがある。 管理できないと感じた場合、数え方が違っている可能性が高い。実際に管理すべきは行数ではなく、定義の数——より正確には RoleTemplate（ロール定義の実体エンティティ）の数だ。 BU（Business Unit：ビジネスユニット、組織単位）がいくつ増えても、RoleTemplate は一セットだけ存在する。行数が膨らんでも、管理対象の定義数は環境規模にかかわらず百数十件の範囲に収まる。 なぜ行数が「BU数×定義数」に膨らむのかDataverse のセキュリティロール（特定のテーブルへの操作権限をまとめた権限グループ）は、BU ごとに個別の行として発行される仕組みになっている。BU が 10 あり、ロール定義が 20 あれば、行数は 200 になる。BU が数十〜数百規模の組織では、行数が数万を超えることも珍しくない。 Microsoft の公式ドキュメント（Security roles and privileges、2024 年更新）には次のように明示されている。 “A security role can exist in the root business unit (BU) and replicated to different BU’s, and therefore the role ID is not unique across environments.” Dataverse は内部で Role エンティティ（行として BU ごとに複製される側）と RoleTemplate エンティティ（ロール定義の実体）を分離して設計している。この二層構造が行数の爆発を生む一方で、管理の複雑さを大幅に抑えてもいる。 複製された行が「空の殻」とはどういう意味か複製された Role 行が格納しているのは次の 3 点だけだ。 格納情報 内容 roleId この行固有の識別子（BU ごとに異なる GUID） BusinessUnitId この行がどの BU に属するかの参照 roleTemplateId どの RoleTemplate を参照するか（全環境・全 BU で固定の GUID） 権限の中身——どのテーブルへの読み書き・削除が可能か、という情報——は Role 行に存在しない。それは参照先の RoleTemplate が保持する。 ...

Dataverse でビジネスユニット（BU：データレベルの境界を形成する組織区画）を「無効化」しても、配下ユーザーの権限は一つも切れない。累積加算式のアクセスモデルでは、ロールを明示的に除去しない限り有効な権限として機能し続ける。廃止設計における「無効化」と「権限剥奪」は、独立した 2 工程だ。 無効化フラグの正体——アクセス評価に参加しない状態変数Microsoft の公式ドキュメント（delete-business-unit.md、2026 年確認）は無効化の効果をこう記述する。 “All users and teams associated with the business unit or child business units won’t be able to sign in.” 遮断されるのは「サインイン」だ。セキュリティロールは削除されない。 Dataverse のアクセスモデルは累積加算式で構築されている（Security concepts in Dataverse）。 “all privilege grants are accumulative with the greatest amount of access prevailing” 複数ロールを持つユーザーはすべての権限の和を持つ。無効化フラグはこの評価ロジックの外にある。BU が無効になっても、配下ユーザーのロールは削除されず、アクセス評価エンジンはそのロールを有効として扱い続ける。 無効化とは表示上の印であり、アクセス制御のスイッチではない。 この構造は公式ドキュメント自身が示している。BU を削除する前の手順として「ユーザーとチームを別の BU に移動し、セキュリティロールを再割り当てせよ」と指示していること自体が、無効化操作だけではロール除去が起きないことを前提にしている。 無効化後に通ってしまう操作以下は Dataverse 開発者テナントを用いた検証環境での確認結果だ。公式ドキュメントに明示された記述は見つかっておらず、実測を根拠とする記述であることを最初に断る。 無効化済みの BU 配下に対して次の操作を確認した。 操作 確認結果 配下 BU への新規メンバー追加 完了（セキュリティロール付きで追加できる） 配下 BU を所有者とするレコード作成（Dataverse Web API 経由） 完了 配下 BU の下に子 BU を新規作成 完了 ロールが残存している限り、権限評価はフルに機能する。無効化フラグが権限評価エンジンに影響を与えていないことが、こうした動作を可能にしている構造だ。 ...

フラットな Excel や CSV を Dataverse の関連テーブルに載せるとき、Azure Data Factory（ADF）のような重い基盤は必要か。答えは条件付きで「否」だ。単一の Dataflows（Power Platform の ETL ツール。Power Query で変換ロジックを定義し、Dataverse へデータを投入する）で設計上の安全性を担保できる——ただし「自己正規化」という設計原則と、Dataflows の fail-open 挙動（エラーが出ても処理を続け、失敗行だけを落とす動作）を正しく理解している場合に限る。 環境前提として確認しておく：Dataflows 単独では削除の自動検知はできない。デルタ同期・変更検知の設計は別途必要だ。 なぜ自己正規化は孤児を消せるのか参照整合性エラー——いわゆる「孤児」——が生まれる原因は単純だ。子テーブルのレコードが指す親が、まだ存在していない。これだけだ。 自己正規化の設計は、この問題を構造で封じる。手順は 3 ステップだ。 移行対象のフラット表から、親テーブル相当の列を重複排除して抽出する 抽出した親マスタを Dataflows で先に投入する 同じフラット表から子レコードを投入する この順序を守る限り、子が指す親は必ず存在する。なぜなら、親マスタは同じフラット表の重複排除から作っているからだ。フラット表に存在しない親を子が参照する、という事態は原理的に起きない。これは論理の帰結であり、ツール依存の話ではない。 欠損が生じる場合は「順序のズレ」だけが原因になる。親の投入が終わる前に子を流してしまった場合だ。対処は親→子の順で再実行するだけで収束する。「本物の孤児」——設計上解決できない孤児——は、この構成では原理的に生まれない。 判断が分かれる境界線とはいえ、Dataflows 1 本で完結できる条件には限界がある。以下で対照する。 観点 Dataflows で十分 ADF 等が必要になる 規模感 数万〜10万件（後述の速度実測を参照） 数百万件の継続的デルタ同期 データ鮮度要件 初回移行・週次バッチ リアルタイム / 1 分以内 変換の複雑さ Power Query M で表現できる範囲 複数システム横断の複雑なジョイン・集計 監査・ガバナンス 手動モニタリングで許容できる SLA・自動アラート・再実行の完全自動化が必須 保守体制 業務担当者または情シス 1 名が触れる 専任インフラチームが SLA を持って管理 上記の左列すべてに当てはまる初回移行であれば、ADF を持ち出す必要はない。 速度の正体——固定費を畳む速度に関して、よく聞く「Dataflows は遅い」という印象は比較対象次第だ。 ...

「基幹に持たせよう」という一言は善意で出る。ただし、判断基準が利用者数でも設計の美しさでもないとすれば、何なのか。 答えは一点だけだ。「他システムがそのデータを取り込んで書き足す共有物に育ったかどうか」——これがSoR（System of Record：組織のデータ管理における権威的ソース）への昇格の唯一の引き金だ。この一軸で判断できれば、会議での問いに根拠を持って返せる。 受益者の有無が唯一の判断軸SoRという概念の産業界定義は、Geoffrey MooreとAIIMが2011年に策定した白書が原典だ。「組織の重要マスターデータを管理するトランザクション処理の権威的ソース」——核心条件は、他システムがそのデータを取り込んで書き足す「共有物になっているかどうか」だ。 利用者数・設計の美しさ・担当者の熱意は、この定義に入らない。「月1,000人が参照する」と「他システムから書き込まれる」は別の概念だ。前者はアクセス頻度、後者はデータ所有権の問題だ。 Microsoftの公式参照アーキテクチャ「Synchronize data across Dataverse environments」（2024年）も「一方をプライマリ（権威的ソース）と定め、他はセカンダリ（コピー）として設計する」と明示している。SoRを定めることは自然に決まるものではなく、明示的な意思決定だ。 データ設計の判断とは、受益者を先に確認する作業だ。 2つの取り違えを潰す会議でよく起きる取り違えは2つある。 利用者が多い ＝ 共有物 「多くの部門が参照している」は昇格の引き金でない。読み取り専用の利用がいくら増えても、他システムからの書き込みが発生しなければSoRの条件を満たさない。 コピーを基幹に流す ＝ 正本が基幹に移った 「基幹DBにデータをコピーして同期している」と「基幹が正本（SoR）になった」は別の意思決定だ。どちらが権威的ソースかを明示的に決めなければ、障害時・更新競合時に「どちらが正しいか」の判断がつかなくなる。 Microsoft公式ドキュメント「Data ownership models for synchronization」（2024年、DataverseとBusiness Centralの統合設計）はこう規定している——「どちらかをSoR（正本）と定め、他はコピーとして扱う」。写しがいくら出回っても、正本は動いていない。 昇格に付く4つの恒久コスト昇格を選んだ瞬間から、以下4つのコストが恒久的に積み上がる。 コスト 内容 同期コスト 2システム間のデータを常に一致させるための配管メンテナンス 維持コスト スキーマ変更・バージョンアップのたびに統合コードを更新する工数 責任分界 障害時・更新競合時に「どちらが正しいか」の所管整理（担当部門間の調整） 部門間調整 マスタ変更・スキーマ変更の影響範囲を関係部門と合意し続けるコスト IPAが示す業界慣行では、システム保守費用は初期開発費の15〜20%が目安だ。Fivetranの調査（参考値・商業調査機関）によれば、エンジニア時間の53%がデータパイプライン・統合のメンテナンスに費やされるという。Ampersandの調査（参考値・商業調査機関）では、統合1件あたりの年間保守コストは構築コストの2倍以上に達するとされている。 昇格した日から始まる構造的なコストだ。 受益者がいなければ、コストだけが積み上がる他システムが書き足す受益者がいない状態で昇格すると、便益はゼロのままこれらのコストが恒久的に積み上がる。 経産省のDXレポート（2018年）は「既存システムの集約が必ずしもサイロ化を解消するわけではなく、新たな統合コストを生む」と指摘している。「あった方がいい」という根拠だけで昇格する場合、この指摘は直接当てはまる。 受益者の有無という一軸で判断できれば、「昇格しておけば将来使えるかもしれない」という根拠のない期待を機械的に排除できる。 データ種別で答えが変わるSoR定義（Geoffrey Moore/AIIM 2011）から整理すると、判断が異なるデータ種別が2つある。この判断フレームが主な対象とするのはフロント入力データ（ユーザー入力・業務記録・申請フォームへの回答等）だ。 参照データ（コード表・マスタ等）は、通常すでにSoRが存在している。問いは「どこのSoRから取るか」になる。フロント入力データは「そもそも昇格すべきか」から判断が必要だ。 Microsoftも「バーチャルテーブル（参照のみ）とデータ同期（コピーを持つ）の選択肢」を公式に並べており、どちらが適切かは状況に依存すると示している。この種別の区別を持っておくと、「なぜ基幹に集約しないのか」という問いに対して、まずデータ種別から答えを絞り込める。 → M365 Developer Tenant でのローカル検証環境構築：顧客テナントに時間を吸わせる構造へ、資産を渡すな まとめフロント入力データをSoRに昇格させるかどうかは、他システムが書き足す受益者がいるかどうかだけで決まる。受益者がいなければ、昇格は4つの恒久コストを無償で積む選択だ。 次の一歩：会議で「基幹に持たせよう」と言われたら、まず「そのデータを書き足す他システムが今あるか、3ヶ月以内に現れるか」を確認する。Yesなら昇格を検討する。Noならコピー運用の設計を選ぶ。ただしコピー運用には写しのライフサイクル管理と参照タイムラグの許容範囲の合意が別途必要になる。 関連記事 認可の恒久資産——アプリが消えても残す設計の選択（「アプリが消えても残すか」という引き金の考え方が共通） 取込時の正規化と代替キーLookup——昇格しないと決めたあとの設計 Power Automateで写しを安全に運ぶ疎結合設計

サーバーレス DB は「停止中コストゼロ」が前提だが、監視クエリや接続プールが DB を起こし続けると provisioned（常時起動）より高くつく。課金の主役は保存容量ではなく**起きている時間（計算 vCore）**であり、稼働率が上がるにつれてコストが逆転する構造を持つ。Azure SQL Serverless と Amazon Aurora Serverless v2 の課金構造、稼働率 48% のクロスオーバー試算、keep-alive の正体と監査手順を整理する。 課金の主役は「起きている時間」Azure SQL Database Serverless の課金は vCore 秒（per-second billing）単位で動く。DB が起きている間は vCore単価 × 使用vCore数 が積み上がり、停止中は計算コストがゼロになる。ストレージは起動・停止にかかわらず消費分だけ課金が続くが、実際の PoC 請求を分解すると計算 vCore が約 8 割、ストレージが約 1 割だった。節約効果の大半は「起きている時間を削る」ことで生まれる。 Amazon Aurora Serverless v2 も同じ構造で、$0.12/ACU-hour 課金・停止中は計算コストゼロ。2024 年 11 月からは最小 ACU を 0 に設定できるゼロスケール対応になり、完全停止によるコストゼロが可能になった。 Azure Cosmos DB は別モデル。 消費した RU（Request Unit: データ操作の処理量の単位）の実量に対して課金される（$0.25 / 100 万 RU）ため、接続がなければ RU 消費ゼロ = 請求ゼロとなる。自動一時停止の設定自体が不要で、以降で説明する keep-alive（DB を起こし続ける動作）の問題は Cosmos DB には直接当てはまらない。主軸は Azure SQL Serverless と Aurora Serverless v2 の話になる。 ...

フローが「オン」でも、Dataverse 側の webhook 購読が登録できていなければ、イベントは永久に届かない。実行履歴が空でエラーも出ない場合、ロジックより先に「購読レコードが実在するか」を確かめる。とくにサービスプリンシパル（機械 ID）接続では、業務権限と購読登録権限は独立した別レイヤーにあり、権限不足で静かに失敗する。 「オン」は「購読が開通した」を意味しないDataverse の「行が追加されたとき」などのイベントトリガーは、フローを有効化した時点で Dataverse 側に購読（webhook）を登録しにいく。内部的には ServiceEndpoint テーブル（エンドポイント本体・contract = 8 が webhook を示す）と SdkMessageProcessingStep テーブル（どのテーブル・イベント・ステージで発火するかの設定）の 2 テーブルにレコードが立つ。この登録が成功してはじめて、回線が開通した状態になる。 フローの「オン」表示は、購読の登録成否とは独立して維持される。権限不足で登録が失敗してもステータスは ON のまま残り、エラーメッセージはユーザーに提示されない。Microsoft 公式ドキュメントには次の一文がある。 “Missing permissions or an invalid connection can silently cause triggers to not fire.” （権限不足または無効な接続により、トリガーは静かに発火しない） 結果として、フローは ON のまま実行履歴は空のまま残る。健康診断ツールが「◯日間、一度も実行されていません」と表示するだけで、ログもエラーも出ない。 「フローがオン」と「購読が開通した」は、独立した別の事実だ。 サービスプリンシパル接続で静かに失敗する理由Dataverse コネクタはサービスプリンシパル接続を公式にサポートしている。ただし、この構成では権限の二層構造に注意が必要だ。 サービスプリンシパルを Dataverse 接続として使う場合、Entra ID にアプリ登録を作成し、Dataverse 環境に Application User（Dataverse 側の機械 ID）として追加したうえで、セキュリティロールを割り当てる。このロールに 2 つのレイヤーがある。 レイヤー 内容 典型的なロール 業務データ層 対象テーブルへの読み書き（CRUD） カスタムセキュリティロール プラットフォーム層 購読登録（ServiceEndpoint / SdkMessageProcessingStep の作成） System Customizer / System Administrator 業務データ層の権限だけを付与した Application User は、テーブルへのアクセスはできる。しかし購読の登録は失敗する。この 2 レイヤーは独立しているため、業務ロジックが動作する別の接続で確認済みであっても、機械 ID での購読登録成功を意味しない。 ...