Posts

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」 ...

Lookup列でテーブルを繋いだのに、チーム共有の要件が出てきた瞬間に設計が崩れる——この問題は、Dataverseで業務アプリを内製化するときに必ず一度ぶつかる。 判断軸は単純だ。「誰と共有するか」が個人（1対1）ならLookup列でいい。組織やチーム（1対多）になるなら、テキストコード突合に切り替える。 この切り替えを設計段階で決めていれば、人員増加も組織変更も無修正で吸収できる。逆に、Lookup列のまま複数人共有を試みると、テーブル構造の手戻りが発生する。 連載の前提知識：代替キー（Alternate Key）の設定と安全なUpsertの手順は、連載第1回「Dataverseの代替キーで安全にUpsertする」で解説しています。本記事はその続きとして、設計判断の軸を扱います。 Lookup列が崩れるメカニズムLookup列（検索列）は、Dataverseの公式仕様で次のように規定されている。 All custom lookups can only allow for a reference to a single row for a single target row type. 訳すと「すべてのカスタム検索列は、単一のターゲット行の種類に対して、単一の行への参照しか持てない」。つまり、1つのLookup列に入るのは常に1行だけだ（Microsoft Learn「Column data types in Microsoft Dataverse」2024年）。 Lookup列を使うと、DataverseはN:1（多対一）リレーションシップを自動生成する。「案件テーブルの担当者列 → 社員テーブルの1行」という構造は、担当者が1人固定のうちは問題なく機能する。 問題は、「この案件を3人で担当する」「営業グループ全員が見られるようにしたい」という要件が出たとき。Lookup列は構造上それを受け取れない。1つのセルに複数の行を詰め込む設計は、Dataverseのスキーマが許していない。 なお、メールのToフィールドのような「PartyList型」は複数値を持てるが、これはシステム列の例外扱いであり、カスタム列には適用できない（公式確認済み）。 テキストコード突合の原理解決策は「直接繋がない設計」に切り替えることだ。 具体的には、双方のテーブルに共通のテキストコード（例：GA001、GA002 といった組織コード）を持たせ、Lookup列による直接結合を使わない設計にする。ビューフィルターでこのコードを照合することで、1対多の共有が実現できる。 たとえば「案件テーブル」と「担当グループテーブル」の両方に group_code 列（テキスト型）を作り、同じ GA001 を持つ行同士を参照させる。担当者が増えても、グループが変わっても、テーブル設計には手を加えずに対応できる。 このテキストコード突合は、Dataverseの代替キー（Alternate Key）仕様を技術的な土台にしている。代替キーは、主キー（GUID）とは別に「業務上の一意識別子」として列を定義する機能で、Microsoftが公式に仕様化している（Microsoft Learn「Work with alternate keys」2024年）。ただし、「組織共有のためにテキストコード突合を使う」という設計パターンそのものの公式ガイドは存在しない。この設計パターンの公式ガイドは存在しない。代替キー仕様を土台にした設計判断として提示する。 役割分解の判断軸設計の出発点として、次の分解を使うと判断が早い。 共有の単位 向いている設計 典型的なケース 個人（1対1） Lookup列 担当営業、承認者、作成者 組織・チーム（1対多） テキストコード突合 担当グループ、部門、担当エリア 未定・変動する テキストコード突合 組織再編が見込まれる、兼任が多い Lookup列が最も力を発揮するのは、「この行を担当するのは常に1人」という前提が成立する場面だ。担当者が交代しても「前任者→後任者」と1対1で置き換わるなら、Lookup列で問題ない。 組織単位の共有が必要な場合は、設計段階でテキストコード突合に切り替える。後から変えようとすると、既存のビューやフォームへの影響範囲が広くなる。 代替キー設定の制約——設計前に知っておく数値テキストコード突合を代替キーとして設定する場合、次の制約が2026年時点の仕様として存在する（Microsoft Learn「Work with alternate keys」2024年）。 ...

DataflowsでExcelや基幹システムのデータをDataverseに定期同期するとき、突合キーに何を使うかで設計の安全性が決まる。 結論を先に言う。DataverseのデフォルトName列は突合キーに使ってはいけない。 使うたびに同名他社・表記ゆれ・社名変更の3トラップが確実に発動する。 解法は、基幹システム側で一意管理されている業務コード列（代理店コード・顧客IDなど）を専用に用意し、代替キー（Alternate Key）として設定することだ。 Name列をVLOOKUPのキーにしてしまう典型ミスExcelのVLOOKUPを長く使ってきた人ほど、DataverseのName列を自然な突合キーとして使いたくなる。「会社名が一致したら同じレコード」という感覚は、スプレッドシートの世界では合理的だ。 Dataverseの画面を開くと、Name列が最も目につく場所にある。Dataflowsのフィールドマッピング設定でもName列は真っ先に候補に上がる。だから直感的に選んでしまう。 ただし、DataverseのName列は「人間がアプリ画面で見るためのラベル」として設計されている。Microsoft Learnの公式ドキュメント（Work with alternate keys、2026年3月更新）が代替キーの設計思想として示している通り、データベース上の一意性保証はName列の責務ではない。突合キーに使うと、以下の3つのトラップが確実に発動する。 3つのトラップ：同名他社・表記ゆれ・社名変更トラップ1：同名他社（重複・誤上書き）異なる企業が同じ名称を持つケースは珍しくない。「山田商事」「東西商事」のような名前は地域をまたげば複数存在する。Name列で突合すると、別の会社のレコードが上書きされる。気づいたときには、どちらが正しいレコードか判断できない状態になっている。 トラップ2：表記ゆれ（別レコード扱い）「株式会社〇〇」「（株）〇〇」「㈱〇〇」は、人間には同じ会社に見える。Dataverseは文字列として比較するため、すべて別のレコードとして追加し続ける。定期同期のたびにレコードが増殖する。 トラップ3：社名変更（突合機能不全）社名変更が起きると、Excelや基幹システム側の名称が更新される。Name列を突合キーにしていると、変更後の名称がDataverse上に見つからず、既存レコードの更新ではなく新規レコードの作成として処理される。過去の取引履歴との紐付けが切断される。 3つとも、「いつか起きるかもしれないリスク」ではない。データが蓄積されるほど確実に発動する構造的な問題だ。 設計の判断軸：「人間が見るデータ」と「システムが判別するデータ」を切り離すデータベース設計の基本原則として、「人間が見るデータ」と「システムが判別するデータ」は別の列に持つ。Name列は前者に属する。突合キーには後者が必要だ。 具体的には、基幹システム側で一意管理されている業務コード列を使う。代理店コード・顧客番号・取引先ID——企業が社名を変えても、コードは変わらない。同名の別企業が存在しても、コードは異なる。表記ゆれは最初から発生しない。 この業務コード列をDataverseに専用列として追加し、代替キー（Alternate Key）として登録することで、DataverseがこのコードをName列と並ぶ「第2の主キー」として扱えるようになる。Dataflowsはその列を使ってUpsert（既存行の更新 + 新規行の追加）を安全に実行できる。 代替キーの仕様と制約（設定前に確認する数値）代替キーを設定する前に、以下の制約を把握しておく。数値はすべてMicrosoft Learnの公式ドキュメント（Work with alternate keys、2026年3月更新）からの直接引用だ。 制約項目 上限値 テーブルあたりの代替キー数 最大10個 1キーあたりの列数（複合キー） 最大16列 キーサイズの合計 900バイト以下（SQLインデックス制約準拠） 加えて、以下の列は代替キーとして設定できない（Define alternate keys to reference rows、2025年8月更新）： 列セキュリティが有効な列：設定不可 NULL値を含む列：一意性が強制されない（重複レコードのリスクがある） 仮想テーブルの列：代替キー非対応（外部システム側の一意性を強制できないため） もう一つ注意点がある。代替キーとして設定する列の値に特殊文字（ /,<,>,*,%,&,:,\,? ）が含まれると、GET/PATCH（Upsert）操作が機能しなくなる。 業務コードに記号を使っている場合は事前に確認が必要だ。 サポートされるデータ型は6種（Decimal Number・Whole Number・Single line of text・Date Time・Lookup・Option Set）。業務コード列に推奨するのは**Single line of text（1行テキスト）**で、英数字IDであれば問題なく使える。 代替キーの設定手順3ステップ設定はPower Appsのメーカーポータルから行う（Define alternate keys using Power Apps、2025年5月更新）。 ステップ1：業務コード列を作成する対象テーブルに新しい列を追加する。データ型は「Single line of text（テキスト）」を選択。列のプロパティで「必須（Required）」に設定しておく。NULL値が入ると一意性が保証されないため、必須設定は省略しない。 ...

「作れること」を安くする同じ波が、判断を持つ個人を武装させる。一人＋AIで戦える余地が、静かに開きつつある ある朝、いつもの環境を開いて、Power Apps の画面に「新しいエクスペリエンスを試す」というボタンが増えていることに気づく。 押してみる。テキスト入力欄が一つ。「やりたいことを言葉で書いてください」とある。 試しに「部署の備品の貸出を管理するアプリ」と打ち込む。少し待つ。すると、データの設計、画面、入力フォーム、ちょっとした集計のロジックまでが、まとめて出てくる。あなたがこれまで何時間もかけて積み上げてきた手順を、それは数分で通り抜けていく。 最初に来るのは、たぶん感心ではない。手が止まる感覚のほうだ。「自分がやってきたことは、これだったのか」という。 ただ、その感覚の裏側には、まだ言葉になっていないもう一つの面がある。あなたが何時間もかけていた工程を機械が肩代わりするということは、これまで「作れる手」を何人もそろえないと届かなかった範囲に、業務の分かる一人が手を伸ばせるようになる、ということでもある。手が止まったその先で、何が開くのか。それを見ていきたい。 1. あなたが時間をかけて身につけたものは、どこへ行くのか少し、具体的に想像してみてほしい。 あなたは数年かけて Power Apps と Power Automate を実務で扱えるようになった。最初は数式の書き方が分からず、画面遷移が思うように動かず、フローのエラーで半日溶かした夜もあった。そうやって少しずつ、社内で「あの人に頼めば作ってくれる」と言われる立場になった。会議で誰かが「こういう申請を電子化したい」と言ったとき、頭の中に画面が浮かぶようになった。それが、あなたの足場だった。 その足場で、あなたは何を手に入れていただろうか。 たとえば、頼られることそのものだ。「作れる人」は社内で席を確保できる。評価面談で書ける成果があり、異動の話があっても「あれは彼がいないと回らない」と引き留められる。手で作る力は、そのまま社内での立ち位置に変換されていた。 あるいは、独立を考えるときの武器だ。Power Platform で案件を取る人は実際にいて、「作れること」はそのまま単価になる。あなたがこの先フリーランスを検討するとき、最初に数えるカードはこれだったはずだ。 その二つのうち、前者がいま揺れている。揺れているのは「作れること」の希少性のほうだ。言葉で書けば初稿が出てくるなら、初稿を作れること自体の値段は下がっていく。これは、あなたの努力が無駄だったという話ではない。努力の成果が乗っていた台座が、動き始めたという話だ。 だが、もう一つのカード——独立を考えるときの武器のほうは、少し事情が違う。後で詳しく見るが、初稿づくりの重荷が軽くなるということは、独立に踏み出すときの一番重い荷物の一つが軽くなる、ということでもある。台座が動くなら、その上に何を置き直すかを、こちらから考えたほうがいい。そして置き直し方によっては、揺れは追い風にもなり得る。 2. いま実際に起きていること（事実だけ先に）不安を判断に変えるには、まず何が起きているのかを正確に知る必要がある。憶測ではなく、公式が出している事実から始める。 2026 年 4 月、Microsoft は Power Apps の新しい「vibe」エクスペリエンスを公開した（ドキュメントの日付は 2026-04-16、プレリリース表記）。vibe.powerapps.com にサインインして、作りたいものを自然言語で書く。すると AI が、要件の整理、データモデル、業務ロジック、ユーザーインターフェイスまでをまとめて生成する。公式の説明では「アイデアから動くアプリまで、数週間ではなく数分で」とある。 注目すべきは、生成される範囲だ。公式ドキュメントは、裏側で実際の React コードを書いていると明記している。あなたがそのコードに触る必要はないが、開いて中を覗くこともできる。つまり、画面の見た目だけでなく、その下の生成コードまでが射程に入っている。これは従来のローコードが「コードを書かせない」方向だったのとは、向きが少し違う。コードは生成される。ただ、人がそこに常駐しなくてよくなる、という設計だ。 並行して、もう一つの流れがある。Power Apps には「Code Apps」という、本格的なコードで作るアプリの枠があり、こちらを AI で支援する「Vibe Apps」という位置づけも整理されつつある。さらに Power Platform の 2026 年 5 月の更新では、Copilot Studio のマルチエージェント機能、エージェントの評価（evaluations）、エージェントフィードが一般提供（GA）に入っている。生成は単発の便利機能ではなく、プラットフォーム全体の前提になりつつある、という流れだ。 もう一つ、品質に関わる事実がある。より質の高いアプリのためには、管理センターで Anthropic のモデルを有効化することが公式に推奨されている。生成の中身を支えるモデル選択が、アプリの出来に効くところまで来ている。 ここまでが、確認できる事実だ。煽る材料でも、安心する材料でもない。ただ、向きを知るための座標として置いておく。 3. 「では、もう手で作る仕事はなくなるのか」ここで多くの人が一足飛びに進みたくなる。手で作る仕事は終わったのか、と。 結論から言うと、そう読むのは早い。同じ公式ドキュメントが、この機能の現在地をかなり率直に書いているからだ。 この vibe の作成体験は、いま **public preview（公開プレビュー）**だ。そして公式は、プレビュー機能について「本番運用を想定していない」「機能が制限されている場合がある」と明記している。さらに前提条件として、いくつもの制約がある。 テナント管理者が、テナントに対して Copilot を有効化しておく必要がある 既定（デフォルト）環境では使えない。米国・オーストラリア・アジア・インドのいずれかのリージョンにある環境が要る 利用できるのは、いまのところ英語のみ これらは小さな注記ではない。「言葉でアプリが出てくる」という見出しと、「ただし英語で、特定リージョンで、デフォルト環境は不可で、本番には使うな」という条件は、セットで読まなければならない。 ...