Posts

外部ベンダーや受託開発者にDB接続情報（ID/パスワード）を渡す運用は、今すぐ替えられる。 Microsoft Entra ID のマネージドID・サービスプリンシパルを使えば、**パスワードなしに「身分認証・名前指定の最小権限・失効制御」**を組める。 4段の梯子（Basic → サービスアカウント → サービスプリンシパル → マネージドID）のどこに乗るかが判断の核心で、GUIツールの制限とライセンス条件がその判断を左右する。 共有パスワード運用の4つの構造問題DB接続情報（ユーザー名とパスワードの組み合わせ）を外部の作り手と共有する運用には、次の4つの問題が構造として組み込まれている。 追えない：誰がいつDBに接続したか、共有アカウントでは個人単位の追跡ができない。監査ログを取っても「account1というアカウントが接続した」としか見えない。 回せない：パスワードを複数人に渡した後で変更しようとすると、全員の接続設定を同時に更新する調整コストが発生する。「まあ変えなくていいか」が常態化する理由はここにある。 全権：接続情報を持っていれば、そのアカウントに紐づく権限を丸ごと使える。外部の作り手に「Read Onlyでいい」と思っていても、共有した接続情報がadminアカウントのものであれば全権が渡る。 気づけない：接続情報が漏洩しても、それが「内部者の流出」なのか「外部からの窃取」なのかを特定しにくい。被害規模の把握に時間がかかる。 認証情報の侵害を含む漏洩インシデントは、特定・封じ込めに平均292日を要し、1件あたり平均コストが481万ドルに達する（IBM「Cost of a Data Breach Report 2024」・2024年7月、認証情報侵害全般の数値）。また、Verizonの2025年版DBIRでは全侵害の22%が盗まれた認証情報を初期アクセスに使用しており、基本的なWebアプリ攻撃の88%で盗まれた認証情報が使われている（Verizon「2025 Data Breach Investigations Report」・2025年）。これらは共有パスワード専用の統計ではなく認証情報漏洩全般のデータだが、4つの構造問題を抱えたまま外部接続を続けることのリスク感覚として参照できる。 判断の核心：認証と認可は別物設計の前提として押さえておくべき区別がある。認証（Authentication）は「誰か」を確認すること、認可（Authorization）は「何ができるか」を決めること——この2つは別々の仕組みで制御できる。 Entra ID によるマネージドID接続を Azure SQL で設定する場合、まず Entra が身分を確認し（認証）、次に DB 側で CREATE USER [<app-service-name>] FROM EXTERNAL PROVIDER を実行して「この身分にはどの権限を開けるか」を個別に定義する（認可）。身分が確認できても、DB側で権限を開けていなければ触れる範囲はゼロだ（Microsoft Learn「Securely connect .NET apps to Azure SQL Database using Managed Identity」・2025年）。 ここが共有パスワード運用との決定的な違いで、共有パスワードは認証と認可が実質的に一体化している。パスワードを持っていること自体が全権の証明になってしまう。 4段の梯子：上段ほど漏れる秘密が減る接続設計には4段の梯子がある。Microsoft は「プログラムアクセスにはマネージドIDが第一選択。使えない場合のフォールバックとしてサービスプリンシパルを使用する」と明示している（Microsoft Learn「Managed identities for Azure resources overview」・2025年）。 段 方式 漏れる秘密 主な用途 1 Basic認証（ユーザー名＋パスワード） パスワードそのもの レガシー構成・削除推奨 2 サービスアカウント（専用アカウントのパスワード） パスワード（共有より管理しやすい） 人が管理できる範囲の小規模構成 3 サービスプリンシパル（SP） クライアントシークレット（最大24ヶ月・ローテーション必要）または証明書 非Azureホスト・GitHub Actions等 4 マネージドID なし（Azure が自動ローテーション） Azure上のリソース間接続の最上位 段4のマネージドIDは、Azure App Service・Azure Functions 等の Azure リソースに直接紐づく「システム割り当て」と、複数のリソースで共有できる「ユーザー割り当て」の2種類がある。システム割り当てはリソース削除時に自動削除されるため、権限の剥奪漏れが起きにくい。どちらも開発者がシークレットを保持する必要がなく、Azureが自動的にクレデンシャルを管理する。 ...

ビューで行を絞っても、Dataverse Web API を直接呼べばそのフィルターは無効になる。 本物のアクセス境界は、レコードの所有者（owner）・所属部門（owningBU）・ロールの深度（User / BU / Parent:Child / Org）の 3 つで決まる。 設計したら、Dataverse Web API を使って意図的に崩してみる。それが境界の実効性を確かめる検証手順だ。 ビューフィルターは化粧であり、アクセス制御ではないPower Apps でビューを作り、フィルター条件を設定すると、画面上の行は見事に絞られる。「これで見せてはいけないデータが隠れた」と判断するのは自然だ。しかし、それは正確ではない。 ビューのフィルター条件は、画面表示のための設定に過ぎない。Dataverse Web API（REST API）を直接呼び出した場合、ビューのフィルターは引き継がれない。返る結果は、ユーザーのセキュリティロールの深度設定に基づくものになる。ロールが Organization レベル（全件）で設定されていれば、ビューが何を絞っていても、全レコードが取得できる。 Microsoft Learn に明確な記述がある。 “The records that the user can see in the views are still governed by security privileges.” （ビューで見えるレコードの決定権はセキュリティ権限側にある） — Microsoft Learn「Security roles and privileges for Dataverse」（2025年12月9日更新） 2025年 Power Platform Release Wave 1 でビューへのセキュリティロール割り当て機能がプレビュー追加された。この機能追加が示す事実は「それ以前はパブリックビューはテーブルへのアクセス権を持つ全ユーザーに表示されていた」ということだ（Microsoft MVP Nishant Rana「Use Security Roles to manage access to views (preview)」2025年4月29日）。つまりビューの絞り込みは、長らくアクセス制御の外側に置かれていた。 ...

あなたのパソコンの画面に、いま何のツールが開いているだろう。 Power Apps のキャンバス画面かもしれない。あるいは Cursor のエディタ画面か、ふつうの Excel か。「コードを書けない自分」がずっと引っかかりながら、それでも何かを作り続けている人もいるだろう。逆に、「自分はプロコードで書いているから」と思っているエンジニアが、実は自分の立ち位置を測りかねている、という状況もある。 「ノーコード、ローコード、バイブコード、プロコード——これって難しい順に並んでるんじゃないの？」 その前提から一度離れてみる価値がある。 1. 「コードを書けるかどうか」という話ではないまず、失われた可能性の話を一つしておきたい。 Power Platform やノーコードツールを使って業務システムを作り続けてきた人が、ある日気づく。テーブル設計を間違えていたせいで、半年後にデータが整合しなくなった。権限設定を深く考えずに作ったせいで、後から全部作り直した。環境変数を使っていなかったせいで、本番環境への移行で丸一週間が飛んだ。 「コードを書かなくていいから簡単」と思って入ったローコードの世界で、プロコード的な設計知識が結局必要になる——この経験は、ローコード実務者の多くが通る道だ（これは筆者が現場で繰り返し見てきた観察に基づく）。 一方で、こんな可能性もある。バイブコード（AIと自然言語で対話しながらコードを生成・修正するスタイル）を使いこなせれば、これまで「自分には無理」と思っていたプロダクトを形にできるかもしれない。マイクロSaaSの一本が、今の仕事に依存しない収入の柱になるかもしれない。グローバルSaaS市場が年14.7%成長し続ける（Precedence Research, 2025年）なかで、個人が参入できる余地は確実に広がっている。 この二つの現実——「ローコードで設計知識が必要になる壁」と「バイブコードで開く扉」——を同時に見るための地図が、本記事の目的だ。 2. 4スタイルの実態——数値が示す「AIと開発者」の現在地「バイブコード（vibe coding）」という言葉を最初に使ったのは、OpenAIの創設エンジニアであるAndrej Karpathyだ。2025年2月2日のX（旧Twitter）投稿（原文）で、こう書いた。 “There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” この投稿は450万回以上閲覧され、Collins Dictionaryは同年11月に「2025年の言葉（Word of the Year）」に選出。Managing DirectorのAlex Beecroftは「ソフトウェア開発の大きな転換を示す言葉」と評している（Collins Dictionary公式ブログ, 2025年11月）。 これが空虚なバズワードではない証拠は、ツールの普及速度が示している。GitHub Copilotは2025年7月に累計2,000万ユーザーを突破（Microsoft CEO Satya Nadellaの決算発表、TechCrunch報道）。Cursorは2026年2月にARR（年換算収益）20億ドルを達成——1年前から3ヶ月で倍増というペースで（The Next Web）。 開発者コミュニティ全体でも、JetBrainsが2025年に194カ国2万4534人を対象に行った調査（State of Developer Ecosystem 2025）では、85%の開発者がAIツールを定期的に利用していると答えた。Stack Overflow Developer Survey 2025（一次ソース）でも、AIツールを「使用または使用予定」とした開発者は84%に達した（前年比8ポイント増）。 ...

GUIだけで作ったAIエージェントは、人格・会話フロー・ツール定義がプラットフォームの内部に閉じており、差分が追えない。前提：Copilot Studio / Azure AI Foundry / GitHub Copilot のいずれかを組織内で稼働させている環境。 結論を先に言う。エージェントの定義はYAMLでGitに乗せる。そして「設定できた」で終わらず、実機で6観点を突き合わせて初めて完了とする。 エージェントも「野良化」するノーコードアプリの野良化と、エージェントの野良化は同じ構造問題だ。 Power Platformのロールアウト18ヶ月後に組織内のアプリ数が4,000件規模に膨らみ、そのうち約半数でオーナーが不明になる——業界報告では、こうした事例が繰り返し記録されている。エージェントでも同じことが起きる。GartnerはFortune 500企業の平均エージェント数が2025年時点の15未満から2028年には150,000超へ急増すると予測し（2026年4月）、このスプロール（無秩序な増殖）をIT複雑性と管理コスト増大の主要因として正式に警告している。 問題の根はGUIにある。ポチポチ作ったエージェントは、次の5つが不透明な基層に埋まっている。 層 内容 GUIだけだと ①人格 システムプロンプト・インストラクション バージョン履歴なし ②会話フロー トピック分岐・応答パターン diffが取れない ③規律 禁止事項・出典厳守ルール 口約束のまま ④知識の接地 ナレッジソース・グラウンディング設定 変更者不明 ⑤ツール定義 MCPサーバー・アクション設定 誰が触ったか追跡不能 引き継ぎ・監査・障害対応のたびに、エージェントの「いまの状態」を読み解くところから始めることになる。 5層をYAMLでGitに乗せるこの問題への答えがconfig-as-code（設定のコード化）だ。エージェントの定義を人間が読めるテキストファイルとしてGitリポジトリに保存し、変更はPRレビューを通す。 2025〜2026年にかけて、Microsoftの主要プラットフォームはいずれも公式のYAML管理経路を整備した。 Copilot StudioVS Code拡張（GA済み） を使う。「Clone agent」機能でエージェントのトピック・インストラクション・ナレッジ・ツール定義がYAMLとしてローカルに展開される。IntelliSenseとスキーマバリデーション付きで編集でき、変更後はVS CodeのUIからCopilot Studioへ直接プッシュできる。 CLIでの操作も公式にサポートされている： # エージェント定義をYAMLでダウンロード pac copilot download --name "AgentName" # ローカル変更をCopilot Studioへ反映 pac copilot push （参照：Microsoft Learn — Visual Studio Code extension: edit agent components / PAC CLI copilot コマンドグループ） ...

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 は顧客が入力し、本番昇格は顧客が押す。開発者が渡すのは「どこに何を入力するかの定義」だけになる。 ...

ある朝、技術リーダーが会議でこう言った。「Claude Code があれば、もうローコードは要らないんじゃないか」。 その問いは正確なようで、実は間違った軸に立っている。「コードか、ノーコードか」という二択は、2つの全く別の問いを1つの選択に圧縮してしまっている。圧縮を解かないまま答えを出すと、判断は半分しか正しくならない。 1. 「もうノーコードは要らない」という感覚の根拠この感覚は、データに裏打ちされている。 JetBrains の State of Developer Ecosystem 2025（24,534人・194ヶ国）によると、開発者の85%が定期的にAIツールを使用し、62%が少なくとも1つのAIコーディングアシスタントに依存している。Stack Overflow Developer Survey 2025でも80〜84%がAIツールを使用または使用予定だ（2024年の76%から増加）。 GitHub Octoverse 2025では、Copilotのコーディングエージェントが5ヶ月で100万件以上のプルリクエストを作成している。学術論文（arXiv, 2025）がGitHub上の129,134プロジェクトを分析した結果、コーディングエージェントの採用率はすでに15〜22%に達している。 つまり「AIがコードを書く」は実験段階を終えた。「ノーコードでやっていたことをAIにコードで書かせればいい」という発想が現場に出てくるのは自然だ。 ただし、この感覚には盲点がある。 2. 「コード vs ノーコード」は2つの軸が束になっていたここからは筆者の分析モデルとして提示する。計測ベンチマークによる実証ではなく、考え方の枠組みだ。 「コード vs ノーコード」という対立は、実は2つの全く別の問いが1つに束ねられていた。 軸1：オーサリング手段——どう作るか（人間がコードを書くか、GUIで組み立てるか、AIに生成させるか） 軸2：成果物の基層——何として残るか（テキストファイルとして追跡可能な状態か、不透明なバイナリや独自形式か） エージェンティックコーディングの普及は、この2軸の束を引き裂いた。「コードを書く」というオーサリング手段のコストが急落したからだ。 しかし成果物の基層は、オーサリング手段とは独立した問題として残り続ける。 3. 「コードは質が高い」という直感の正体「やっぱりコードの方が管理しやすい」という直感は正しい。しかし、その正体は「プログラミング言語」そのものではない。 コードが管理しやすい理由は、成果物がテキストファイルに降りているからだ。差分（diff）が取れる。コードレビューができる。Gitでバージョン管理できる。AIが読んで解析できる。引き継ぎの際に「何がどこにあるか」が追跡できる。 これが「テキスト基層」という考え方の核心だ。 逆に言えば、コードであっても野良スクリプト——ドキュメントなし、バージョン管理なし、レビューなし、作った本人しか読めない——は、同じ引き継ぎ事故を起こす。「ノーコードだから野良アプリになった」のではなく、「テキスト基層に降りていなかったから管理できなくなった」のだ。 4. 引き継ぎ事故の犯人は「ノーコード」ではなかったPower Apps や kintone で作ったアプリが「誰も触れない遺産」になったとき、犯人はローコードツールではなく「不透明な基層 × ガバナンス欠如」の組み合わせだった。 Microsoft Learn のガバナンス考慮事項ドキュメントは、DLPポリシー・環境戦略・CoE Starter Kitを公式推奨している。これはMicrosoft自身が「ガバナンスなしには運用できない」と認識していることの証左だ。 Power Platform環境で正式ガバナンスを持たない組織では、CoE（Center of Excellence）を構築した組織と比較してアプリ乱立やセキュリティ違反が高頻度で発生するという報告がある（商業サイト経由の報告であり、一次ソースの独立検証はない）。またCisco Annual Cybersecurity Report 2025によると、企業セキュリティリーダーの65%がシャドーITをトップ3のセキュリティ懸念に挙げている。 ガバナンスを整えれば、ローコードは野良化しない。問題はツールではなく、基層の設計とガバナンスの有無だ。 5. エージェント時代に、ローコードは2層に分裂するここから先も筆者の分析モデルの話になる。 エージェンティックコーディングが普及した世界では、ローコードは均一に生き残るわけでも均一に消えるわけでもない。2つの層に分裂する、というのが筆者の見立てだ。 成り下がる層：テキスト基層に変換できない、不透明なローコード。GUI上でしか表現できない、差分も取れない、AIも読めない成果物を生む層。これはUIプロトタイプ（ワイヤーフレーム）の域を出ない。AIがコードで同等以上のものを速く安く作れるなら、この層の存在意義は薄れる。 残る層：テキスト基層に降ろせるローコード。成果物をファイルとして扱え、Gitで管理でき、AIが読んで改修できる形に変換できる。この層はむしろ価値が上がる。 Gartner予測（二次引用のため要検証）では、2026年に新規エンタープライズアプリの75%がローコード技術で開発されると言われている。「ローコードが消える」ではなく「分裂する」というのが現実に近い。 6. 「全部コードでやるべき」が損をする一点「エージェントがコードを書けるなら全部コードにしよう」という判断には、重要な盲点がある。 エージェンティックコーディングが安くしたのはbuildコストだ。アプリを作る手間は劇的に下がった。 ...

Power Platformを使い始めた人が最初に止まる場所がある。Dataverseにテーブルを作ってExcelデータを流し込んだのに、Lookup列が空のままになる。SQLで慣れているなら「JOINすれば取れる」と思うが、DataverseのLookupはそういう仕組みではない。 結論を先に言う。DataverseのLookup列は、クエリ実行時に別テーブルを動的に結合するものではなく、各レコードに参照先の識別子をあらかじめ保存しておく設計だ。 この発想の違いを補正しないまま進むと、Excelインポートのたびに参照が空になり、Power Automateで取得したレコードにLookupの情報が入らない謎に何度もぶつかる。 SQLのJOINと何が違うのかSQLのJOIN（テーブル結合）は、SELECTを実行する瞬間に「この列が一致するレコードを取ってくる」という処理をその場で走らせる。物理的なテーブル構造には何も追加されず、クエリを書いた人間が結合条件を都度指定する。 DataverseのLookup列は動きが根本的に違う。 観点 SQL JOIN Dataverse Lookup 結合のタイミング クエリ実行時（動的） データ保存時（事前） 保存される値 なし（結合条件のみ） 参照先レコードのGUID 設計の主役 SELECTを書く人 テーブルを設計する人 参照先が変わったとき クエリを書き直す 各レコードの値を更新する Lookup列を作成すると、Dataverseは2つのテーブル間にN:1（多対1）のリレーションシップを自動で生成する（出典：Microsoft Learn「Create a relationship between tables by using a lookup column」）。そして子テーブルの各レコードには、親テーブルの該当レコードを指すGUID（グローバル一意識別子：システムが自動生成する長い文字列の一意ID）が物理的に保存される。 ExcelのVLOOKUP（ブイルックアップ）と混同している場合も注意が必要だ。VLOOKUPはセルを参照するときに都度計算する。DataverseのLookupは計算ではなく保存だ。 Excelインポートで参照が空のままになる理由Excelインポートは「フラットな行データをDataverseに流し込む」操作にすぎない。ここでのポイントは、Lookup列に必要なのは表示名ではなく参照先レコードのGUIDだということだ。 Excelのセルには「株式会社◯◯」「田中太郎」などの表示名が入っている。Dataverseはその表示名から自動でGUIDを解決する機能を持たない。インポートの時点で「どのレコードのGUID」かが確定していないため、Lookup列は空のまま保存される。これはDataverseの欠陥ではなく設計の原則だ。 機能させるために必要な2段階Lookup列を使いこなすには、作業を2段階に分けて考える必要がある。 段階1：テーブル間のLookup列を定義する（設計フェーズ） Power AppsのMaker Portalで、子テーブル（参照する側）にLookup列を追加する。この操作でN:1リレーションシップが自動生成され、「このテーブルは別のテーブルを参照できる構造になった」という状態になる。 段階2：各レコードに参照先を実際に入れる（データ投入フェーズ） 構造を作っただけでは、各レコードのLookup列はまだ空だ。そこに参照先GUIDを入れる操作が別途必要になる。 SQL経験者がつまずくのはここだ。SQLではSELECT * FROM 注文 JOIN 顧客 ON ...と書けば、テーブルに追加保存しなくても結合した結果が得られる。Dataverseは違う。「構造を作る」と「値を入れる」は別の工程であり、設計後にデータを流し込む手順が必要になる。 Dataflowsで参照を自動解決する参照を入れる手段としてDataflows（データフロー）が使える。DataflowsはExcelインポートと異なり、取り込み時に「この列の値が一致する親テーブルのレコードを探して、そのGUIDをLookup列にセットする」処理ができる（出典：Microsoft Learn「Mapping fields with relationships in standard dataflows」）。 ただし、そのためには**Alternate Key（代替キー：業務コードやメールアドレスなど、GUIDの代わりにレコードを一意に特定できる別の列）**の設定が先に必要だ。 Dataflowsのセットアップ手順1. 親テーブルにAlternate Keyを設定する Power AppsのMaker Portalで親テーブルを開き、「Keys」タブからAlternate Keyを追加する。業務上の一意値（顧客コード、メールアドレスなど）を持つ列を選ぶ。1テーブルに最大10個まで定義できる（出典：Microsoft Learn「Define alternate keys to reference rows with Microsoft Dataverse」）。NULL値を含む列に設定すると一意制約が適用されないため、値が必ず入る列を選ぶこと。 ...

接続の切り替えは通るのに、新規作成だけ失敗する。このエラーの原因は画面操作の問題ではなく、Connection Reference という Dataverse テーブルへの書き込み権限が Environment Maker ロールに紐づいているという構造にある。この構造を理解せずに「既存接続への切り替えで凌ぐ」運用を続けると、新規接続が必要になった瞬間に必ず詰まる。 前提：本記事は Power Platform 環境（M365 または Dataverse あり）でフローの引き継ぎ・接続設定を担う立場の話。Basic User ロールのみ付与されたユーザー環境での動作が出発点。 接続と Connection Reference は別物——権限が分かれる場所Power Automate では「接続（Connection）」と「接続参照（Connection Reference）」が別の概念として動いている。この分離を把握していないと、エラーメッセージの意味がつかみにくい。 **接続（Connection）**は、コネクタへのサインインで生成される認証トークンのセット。Outlook や SharePoint へのサインインを完了した時点で、接続自体は作成される。この操作は Basic User ロールでも実行可能で、「接続の切り替え（既存接続を別の接続に変更する）」もここで完結する。 **接続参照（Connection Reference）**は、フローやアプリがコネクタに直接バインドせず間接的に参照するための中間レイヤーで、Dataverse の connectionreference テーブルに格納されるリソースだ（Microsoft Learn 公式エンティティリファレンス、2024年）。新規コネクタをフローに追加したとき、または新規フローを作成したときに、この Connection Reference が Dataverse テーブルへ新規書き込みされる。 Dataverse テーブルへの新規書き込みには、Environment Maker ロールが必要になる。接続トークンは作れる。しかし Connection Reference という Dataverse レコードを新しく作る権限がない——それが「切り替えは通るのに新規作成だけ弾かれる」現象の構造的な理由だ。 Environment Maker と Basic User、権限の実質的な差「Environment Maker（環境作成者）」という名称は直感的にわかりにくい。実態は「環境上で新しいリソースを作成できるロール」であり、接続・フロー・アプリ・カスタム API がすべてその対象に含まれる（Microsoft Learn「Role-based security roles for Dataverse」2024年）。 操作 Environment Maker Basic User フロー・アプリの新規作成 可 不可 接続（Connection）の新規作成 可 不可 Connection Reference の新規作成 可 不可 カスタムコネクタの作成 可 不可 既存接続への切り替え（更新） 可 可 Dataverse データへのアクセス 不可（別ロール要） 可（最小限） 表を見ると、Basic User は「既存リソースを動かす」ためのロールであり、「新しいリソースを作る」ためには設計されていない。一方で Environment Maker は「作成」に特化しており、皮肉なことに Dataverse データへのアクセス権は持たない（データアクセスには System Customizer や Business Unit 単位のセキュリティロールが別途必要になる）。 ...

Power Apps アプリを開いた瞬間、画面には「自分の担当分」だけが表示される。 この絞り込みは、Dataverse が裏で3段のクエリをつないで自動実行した結果だ。 ビューの設定が「正しい」のに動かない場合、どこかの段が欠けている。 3段クエリ（バケツリレー）の全体像Power Apps のモデル駆動型アプリがビューを描画するとき、Dataverse は次の論理的な3段処理を一連のクエリとして実行する。 【第1区間】ログインユーザー → SystemUser テーブルで GUID 特定 ↓ （eq-userid 演算子） 【第2区間】担当者マスタ の Lookup 列を逆引き → 所属 GAコード 取得 ↓ （FetchXML link-entity による結合） 【第3区間】代理店マスタ のビューフィルターで GAコード一致のレコードだけ通過 ↓ （同一テーブル内の Equal 条件） 【表示】ログインユーザーの所属代理店のレコードだけが画面に出る 「バケツリレー」と呼ぶのは、前の段の出力が次の段の入力になるからだ。 ただし、Dataverse は内部でこれをひとつのリクエストとして最適化実行する。順番に3回送信するのではなく、論理的な3段処理として理解しておく。 第1区間：ログインユーザーを SystemUser で特定するDataverse はすべての Power Apps ユーザーのアカウント情報を systemuser（SystemUser テーブル）で管理している。Microsoft Learn の公式仕様によると、このテーブルは削除不可の標準システムテーブルで、ログイン名（メールアドレス）を domainname 列として保持する。ユーザーごとに一意の systemuserid（GUID）が割り当てられており、これが以降の処理の照合基準になる。 FetchXML で「現在のユーザーに等しい」を表現するのが eq-userid 演算子だ。 <condition attribute="ownerid" operator="eq-userid" /> value 属性は不要で、Dataverse が呼び出し元ユーザーの GUID を自動的に埋める。OData Web API でも同機能が EqualUserId 関数として提供されている（Microsoft Learn「EqualUserId Function」）。 ...

「You don’t have permission to this view」——このエラーを見て、まず疑うのはロール設定やセキュリティロールかもしれない。だが原因がテーブル作成時の所有権設定にある場合、ロールをいくら見直しても解決しない。そして、その設定は作成後に変更できない。 結論を先に書く。Power Apps / Dataverse でログインユーザーごとのデータを表示したいなら、テーブル作成時に「Rows in this table」を User or Team（ユーザーまたはチーム） に設定しなければならない。Organization（組織）を選んだ場合、Current User フィルターは構造的に動作しない。そして一度作ったテーブルの所有権は変更できないため、唯一のリカバリ手段はそのテーブルを削除して作り直すことだ。 「Rows in this table」の2択が意味することDataverse でカスタムテーブルを作成するとき、「Rows in this table（テーブルの行）」という設定項目が表示される。選択肢は2つ。 設定値 意味 Owner 列 Organization 行の所有者は「組織」全体。個人別の制御は設計上存在しない 自動付与されない User or Team 各行に Owner 列（所有者列）が自動付与。レコード作成時にログインユーザーが自動入力される 自動付与される この2択はテーブルの性格を決める根幹設定であり、Microsoft の公式ドキュメントは次のように明示している。 “This is a choice that happens at the time the table is created and can’t be changed.” （これはテーブル作成時に決める選択であり、後から変更することはできない） — Microsoft Learn「Types of tables - Power Apps」 ...