実務ハック

「持ち主を設定したのに課長から見えない」「チームを作るべきか、作らなくていいのか」——この判断がぶれるのは、owner（誰の責任か）と owningBU（どこに属すか）を1本の概念として扱うからだ。 2語に分けるだけで、Dataverse のアクセス制御設計は自分の言葉で説明できるようになる。 そして、純粋な階層要件であれば、チームは必要ない。 owner は名札、owningBU は番地——2語の役割を分けて定義するDataverse の行レベルアクセスは、2つの独立したフィールドで動いている。 **owner（名札）**は「このレコードは誰の責任か」を指す。設定できるのは1人のユーザーか1つのチームだけだ。 **owningBU（番地）**は「このレコードはどこに属すか」を指す。owning business unit（所有ビジネスユニット）の略で、常に1つのBU（ビジネスユニット：組織の管理単位。課・部・事業部などに対応させる）に紐づく。 Microsoft Learn「Security concepts in Microsoft Dataverse」（2026年時点）は次のように明示している。 “Data access to records is granted based on the owning business unit.” — Microsoft Learn: Security concepts in Microsoft Dataverse アクセスの開口部を決めるのは owningBU であり、owner ではない。ここが混同の出発点だ。 名札（owner）は「誰のものか」という属人的な指し示しであり、番地（owningBU）は「どのBU配下に置かれているか」という場所の指定だ。この2語は別のフィールドとして独立して存在し、別の経路でアクセス評価に効く。 2軸の効き先が違う——名札は本人経路で、番地は階層経路で効く名札（owner）が効くのは「本人経路」だ。ユーザーが自分自身のsystemuserid（Dataverse内部のユーザーID）と、レコードのownerIdフィールドを突き合わせることでアクセスが成立する。User深度のセキュリティロールがあれば、自分が名札に入っているレコードは見える。 番地（owningBU）が効くのは「階層経路」だ。レコードのowningBUと、アクセスしようとするユーザーのBU位置関係を評価する。セキュリティロールの深度設定がBU以上であれば、owningBUの属するBU内のレコードが見えるようになる。 この2つの評価経路は独立して動く。だから「持ち主が1人（name=担当者）なのに、課長からも見える」という状態が成立する。名札経路は本人しか通らないが、番地経路はBU階層を通して開口部を開けるからだ。 Microsoft Learn「How access to a record is determined」は、チーム所有経路について次のように記述している。 “In both cases, any access level will suffice to have access regardless of the business unit the record belongs to.” — Microsoft Learn: How access to a record is determined ...

「担当者ごとに見え方を変えたい」という要件が来たとき、最初にフィルター条件を書き始めると詰まる。 Dataverse は毎クエリ、ログイン時のトークン情報から「あなた」に対応する内部ユーザーを自動で特定し、レコードの持ち主と突き合わせて表示範囲を決める。 作り手がやるべき準備は、ログインする人とレコードの持ち主を正しく結びつけることだけだ。 3つのIDを整理するDataverse の担当者管理を理解するには、3種類のIDを別物として扱う必要がある。 1. ログインID（Azure AD Object ID） Entra ID（旧称 Azure Active Directory）がログイントークンに乗せる識別子。azureactivedirectoryobjectid という列名で Dataverse の内部に保持される。ユーザーがアプリを開いた瞬間、このIDがトークンの中に含まれている。 2. 内部ユーザーID（systemuserid） Dataverse 環境内部で割り当てられるGUID（グローバル一意識別子）。レコードの ownerid（所有者）欄に実際に入るのはこのIDだ。外部システムには存在しない、Dataverse 固有の識別子になる。 3. 職場アカウント（UPN / domainname） [email protected] 形式の文字列。Dataverse では domainname 列として保持される。人間が読める識別子だが、文字列なのでそのままでは Lookup（関連テーブルへの参照）として機能しない。 この3つを混同して設計すると、データ取込時に ownerid がnullになったり、フィルターを書いても動かない状態が発生する。 利用者登録が3つのIDを橋渡しする3つのIDをつなぐ場所は1か所だけ、systemuser（SystemUser テーブル）だ。 Microsoft Learn のシステムユーザーテーブル定義（2024年–2026年）によると、このテーブルの1レコードには次の3列が同居している。 列名 内容 systemuserid Dataverse 内部の GUID（主キー） azureactivedirectoryobjectid Entra ID から同期されたログインID domainname UPN（[email protected] 形式） M365 管理センターや Entra ID との同期で利用者を登録すると、この1レコードに3つのIDが書き込まれる。橋は1か所だけで完結する。逆に言えば、この連携が成立していないと——たとえばユーザーが未登録だったり、UPNが変更されて不一致になっていたりすると——後続のすべての処理が機能しない。 毎クエリ自動で突き合わせる（フィルターを書かない）Power Apps のモデル駆動型アプリや Dataverse Web API にリクエストが来るたびに、Dataverse サーバーは次の処理を自動で実行する。 トークンの azureactivedirectoryobjectid → systemuser テーブルの azureactivedirectoryobjectid 列で照合 → systemuserid（内部 GUID）を解決 → レコードの ownerid と突き合わせ → 行レベルセキュリティを評価 セキュリティロールの深度が「User（Basic）」に設定されている場合、ownerid がログインユーザーの systemuserid と一致するレコードだけが返却される。この評価は画面・API・Power Automate のすべてに共通して適用される（Microsoft Learn「Security concepts in Microsoft Dataverse」）。 ...

基幹から来る支社コード・課コードは、テキストのまま流せば取り込みは通る。だが、後で階層クエリや集計に使おうとして詰まる。取り込みながら Lookup 関係へ変換する——その判断を先送りにすると、後工程のコストになって返ってくる。 結論から言う。代替キー（Alternate Key）を使えば、内部 GUID なしに Lookup を張れる。 親→子の順序を守り、「変換ジョブが緑（成功）」と「関係が張れた」を別物として確認する。この 3 点で、横長テキストコードは取込時に関係データに変わる。 コードと関係は別物——なぜ後回しにすると詰まるかDataverse に支社コード「A001」を文字列として格納しても、その行は「支社テーブルの A001 レコード」を参照していない。文字列の一致と Lookup 関係は別物だ。 文字列のままでは、Dataverse のリレーションシップ機能（階層ナビゲーション・関連レコード展開・ロールアップ集計）が一切使えない。基幹から来る横長コードを「いったんコードのまま流す」設計は、後で Lookup を張り直す移行コストとセットになる。 Microsoft 公式は代替キーを「外部システムとの統合で GUID を保持していない場合に一意識別する仕組み」として定義している（Define alternate keys to reference rows）。つまり、内部 GUID を知らなくても業務コードで関係を張る経路は、公式に用意されている。 代替キーで Lookup を張る——前提条件と実装の骨格代替キーとはDataverse のテーブルは、行を一意に識別する主キーとして内部 GUID を持つ。代替キー（Alternate Key）は、業務コード等の外部識別子を GUID と等価な参照先として登録する仕組みだ。代替キーを定義した列は、Lookup を張る際の解決キーとして使える。 前提条件 3 点1. 参照先テーブルに代替キーを定義する Dataflow のマッピング画面で Lookup フィールドが選択できない場合、参照先テーブルに代替キーが未定義であることがほとんどだ。まず親テーブル（支社テーブル、課テーブル等）に対して代替キーを追加し、Dataflow のマッピングを再設定する（Field mapping considerations for standard dataflows）。 2. 代替キーの型は Text 型または Number 型のみ Dataflow マッピングで利用できる代替キーの型は Text 型または Number 型に限られる。日付型・選択肢型等を代替キーとして定義している場合、Dataflow マッピングでエラーになる。業務コードが日付型フィールドで管理されている場合は Text 型で定義し直す（Field mapping considerations for standard dataflows、コミュニティ報告: Fabric Community）。 ...

フォームから列を外しても、その列は API・エクスポート・レポートから普通に読める。 列の機密を守るのはフィールドセキュリティプロファイル（列ごとに「許可した身分だけ可視」と設定するプロファイル）の仕事であり、フォーム編集とは別のレイヤーで動く。 「行は読めるのに、その列だけ null が返る」という状態を設定後に API で確認するまでが、設計の完了だ。 「フォームから外す」と「列を隠す」は別の操作フォームから列を外すのは、画面（UI）からその欄を取り除く操作だ。モデル駆動アプリやキャンバスアプリのフォームデザイナーで列を削除すれば、その画面には表示されなくなる。 しかしそれは、Dataverse テーブルの列そのものが隠れたわけではない。別のビュー・別のフォーム・Web API・Excel エクスポート・Power BI レポート——どの経路からも当該列は依然として読める。 操作 対象 別の画面・API からの読み取り フォームから列を外す 特定のフォーム画面のみ 読める フィールドセキュリティプロファイルで保護 テーブルの列単位・全入口 許可がなければ null が返る Microsoft Learn（2025年6月更新）には「列セキュリティの適用範囲は組織横断であり、クライアントアプリ・Web サービス呼び出し・フィルタービューを使ったレポートを含む全データアクセス要求に適用される」と明記されている。フォームを触っただけではこのレイヤーには一切届かない。 行の鍵と列の鍵は独立した 2 軸Dataverse のアクセス制御には、独立した 2 つの軸がある。 行の軸：どのレコードが見えるか（セキュリティロール、行レベルアクセス制御で制御） 列の軸：見えるレコードの中でどの欄を読ませるか（フィールドセキュリティプロファイルで制御） 2 軸は直交する。行を読める権限を持つユーザーでも、列セキュリティが設定されていればその列の値は返ってこない。与信スコア・年収帯・人事評価コメントなど、同じテーブルの中に機密度の異なる列が混在する業態では、この 2 軸を意識した設計が必要になる。 フィールドセキュリティプロファイルの設定手順（4 ステップ）設定は Power Apps と Power Platform 管理センターの 2 箇所を行き来する。 ステップ 1：列のセキュリティを有効にする Power Apps > Dataverse > テーブル > 対象の列 > 詳細オプション > 「列のセキュリティを有効にする」をオン。この設定をした時点で、プロファイルが割り当たっていないユーザーはシステム管理者ロールでなければ当該列にアクセスできなくなる（既定は不可視）。 ステップ 2：列セキュリティプロファイルを作成 Power Platform 管理センター > 設定 > ユーザー + アクセス許可 > 列のセキュリティ プロファイル > 新規作成。プロファイルには任意の名前をつける（例：「与信閲覧者」「本部専用」）。 ...

AIで何か作ってみたい。でも、何から手をつければいいか分からない。 ここで止まる人は多い。止まる理由は、たいてい「最初の一手が大きすぎる」ことにある。 結論から書く。最初に選ぶのは、半日から一日で最後まで動く、誰にも頼まれていない、自分が少し欲しい小さなものだ。立派さは要らない。一個の小さなものを、最後まで自分の手で回す。それだけでいい。 何を作るか——最小の「最後まで動く」を選ぶ最初に詰まるのは「何を作るか」だ。大きいものを思い浮かべると、そこで動けなくなる。だから題材は次の4つで選ぶ。 誰にも頼まれていない。仕事でも課題でもない。締め切りも評価もない。 半日から一日で最後まで動く。途中で力尽きない大きさにする。 自分が少しだけ欲しい。欲しいから、最後まで付き合える。 立派さは要らない。人に見せるためのものではない。動けば十分だ。 具体例を一つ挙げる。手元に CSV ファイルが一つあるとする。月ごとの数字がバラバラに並んでいて、月別に合計を見たい。これを読み込んで、月ごとに集計して、結果を出すだけの小さなツール。これなら半日で最後まで動く。 別の題材でもいい。フォルダの中のファイルをまとめてリネームする小道具でも、ブックマークを整理する小さなスクリプトでもいい。共通しているのは、入口から出口まで、自分一人で一周できる大きさであること。ここを外すと、途中で止まって「結局できなかった」だけが残る。 選ぶときの基準は一つだ。「これは半日で最後まで動くか」。動かないと思ったら、もっと小さく削る。削れるだけ削った先に、最初の一手がある。 回し方——投げて、分解して、もう一周する題材が決まったら、回し方に入る。ここがこの記事の中心になる。 ループは3つの段でできている。 (1) やりたいことを、自然言語で投げる。 作りたいものを、言葉でそのまま書いて、AIに書かせて動かせる手元の環境に渡す。「このCSVを読んで、月ごとに合計を出して」と書けばいい。先に文法や仕組みを勉強する必要はない。学習はいったん先送りして、まず形を出す。これが今の一番の強みだ。何時間もかけて入門書を読み終えてから動き出す、という順番を踏まなくていい。 (2) 出てきたものを、分解して、なぜ動くのかを理解する。 ここを飛ばしてはいけない。一番外せない段だ。 形が出たら、それで終わりにしない。出てきたものを上から一行ずつたどって、「ここは何をしているのか」「なぜこれで動くのか」を自分で説明できるところまで噛み砕く。分からない部分が出たら、その場でAIに聞いて埋める。「この行は何をしている?」と聞けばいい。 なぜこの段を外せないか。投げて形を出すだけを繰り返すと、動くものは増えても、自分の中には何も積み上がらない。触っただけで、なぜ動くかを語れない。それは経験のように見えて、薄い経験だ。後から振り返ったとき、「やったことはあるが、説明できない」ものばかりが残る。分解して理解する段が、その薄さを防ぐ唯一の場所になる。 (3) 少しだけ難しい課題を、自分に課して、もう一周する。 一周回って理解できたら、自分でハードルを一段だけ上げる。「月別だけでなく、項目別にも集計したい」「結果をファイルに書き出したい」。少しだけ難しくして、また(1)に戻る。投げて、分解して、理解する。 このループの目的は、成果物を完成させることではない。ループを回し始めることだ。一つ目が完璧に仕上がる必要はない。回り始めれば、二周目、三周目で自然と手触りがついてくる。最初の一個は、その回転の起点でしかない。 AIは差を縮めるが、理解は自分で踏むこのやり方が今できるのは、AIがあるからだ。現場で手を動かしている人たちが、それを書き残している。 ある人はこう言う。「AI is raising individual capability to a level that once required a full team … a democratizing force rather than monopolizing（AIは、かつてチーム全体を必要とした水準まで、個人の能力を引き上げている。これは独占ではなく、民主化の力だ）」。別の人は、もっと素っ気なく書く。「AIを使えば、誰でもアプリが簡単に作れるようになりました」。そして、こう付け足す。「知っていても、それを実行している人は少数派です」。 道具はもうある。知っている人も多い。それでも、実際に手を動かす人は少ない。 ここを正直に書いておく。AIは魔法ではない。投げれば形は出る。だが、形が出ることと、自分が分かることは別だ。丸投げして理解を飛ばすと、薄い経験が積み上がるだけになる。AIは差を縮めるが、ゼロにはしない。縮まった差を自分のものにするには、分解して理解する過程を、自分の手で踏むしかない。 道具は使う。ただし、魔法だと思って使わない。この距離感が、ループの(2)を外さない理由とつながっている。 なぜ会社ではなく、自分の場所なのかこのループは、会社の環境では回せない。 会社はまだAIに慎重で、セキュリティの整理でもたついている。何を試すにも稟議が要る。貸与された環境では、ツールに触れることすら制限されることが多い。試す前に止まる。制約だらけの場所では、このループは回らない。 自分の個人の場所には、その制約がない。何を試してもいい。壊してもいい。壊して、直して、また壊す。誰にも止められないし、稟議も要らない。失敗が誰かに迷惑をかけることもない。 最小の一手を回すには、この「何でも試せる場所」が要る。会社の制約の外側、自分の手元の環境。そこが、最初の一手を踏む場所になる。 作るから、自信がつく最後に、まとめる。 最初に選ぶのは、半日で最後まで動く、誰にも頼まれない小さなもの。自然言語で投げて形を出し、出てきたものを分解して理解し、少し難しくしてもう一周する。目的は完成ではなく、ループを回し始めることだ。 これを繰り返した先に、本物のスキルと、本当の自信がある。順番は逆だ。自信があるから作れるのではない。作るから、自信がつく。誰かに「あなたは大丈夫」と言ってもらって得るものではなく、自分の手で一個ずつ作って得るものだ。 正直なことを一つ置いておく。この道で一番ぶつかるのは、孤独だ。一人で、自分の場所で、一つのことに向き合い続ける。隣に誰もいない。だからみんな、やらないのかもしれない。回し始めること自体は難しくない。難しいのは、誰にも頼まれないことを、一人で続けることのほうだ。 一手を回し始めたら、その先に、作ったものを資産として積み上げていく話がある。顧客の仕事に時間を吸われるなかで、どうやって自分の側に成果を残すか。道具の使い方だけでは届かない、続け方の話だ。 次に：顧客テナントに時間を吸わせず、個人PCの側に資産を貯める

外部ベンダーや受託開発者に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日）。つまりビューの絞り込みは、長らくアクセス制御の外側に置かれていた。 ...

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

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値を含む列に設定すると一意制約が適用されないため、値が必ず入る列を選ぶこと。 ...