Posts

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 を有効化しておく必要がある 既定（デフォルト）環境では使えない。米国・オーストラリア・アジア・インドのいずれかのリージョンにある環境が要る 利用できるのは、いまのところ英語のみ これらは小さな注記ではない。「言葉でアプリが出てくる」という見出しと、「ただし英語で、特定リージョンで、デフォルト環境は不可で、本番には使うな」という条件は、セットで読まなければならない。 ...

「共同所有者として共有したのに、なぜメールが送れない？」 この問いに答えるには、権限の問題が2つの独立したレイヤーに分かれていることを理解する必要がある。 Exchange Online 側の Send As 権限と、Power Platform 側の Environment Maker ロール——この2つが揃ってはじめて、フローの完全な引き継ぎが成立する。 2つの権限レイヤーが存在する理由Power Automate のフローが「共有メールボックスからメールを送信する」動作をしている場合、権限は2か所で管理されている。 レイヤー 管理場所 必要な権限 Exchange Online（メール送信） Exchange 管理センター (EAC) Send As（代理送信） Power Platform（フロー操作） Power Platform 管理センター Environment Maker ロール Exchange Online の Send As（代理送信）は、あるユーザーが共有メールボックスから「その共有メールボックスが送ったもの」としてメールを送れる権限だ（公式定義）。これは Power Platform の権限体系とはまったく独立した管理系で動いており、Power Platform 側でどれだけ権限を付与しても、Exchange 側の Send As がなければ共有メールボックス経由の送信は機能しない。 Power Platform 側の Environment Maker ロールは、環境内でアプリ・接続・フローを作成する権限を付与する（公式定義）。「共同所有者として共有」の操作だけでは、このロールは付与されない。 「共同所有者として共有」だけで止まってしまう落とし穴2025年6月以降、環境メンバーでないユーザーと共有されたフローはそのユーザーからアクセスできなくなった（Microsoft Learn）。つまり「共有しただけ」の引き継ぎは、制度上も機能しなくなっている。 しかし問題が表面化しにくい理由がある。共同所有者の権限では、フローの実行履歴閲覧・起動・停止・デザイン編集が可能だ（公式）。軽微な文言修正程度なら動いてしまう。だから「引き継ぎできた」と誤解したまま運用が続き、接続切れや本格的な構造変更が必要になったタイミングで初めて問題が露出する。 Connection Reference（接続参照）と Environment Maker の関係ソリューションとして管理されている Power Automate フローは、接続を「Connection Reference（接続参照）」というソリューションコンポーネントを通じて参照する（公式）。非ソリューションフローとの根本的な違いはここだ。 引き継ぎ担当者が Connection Reference に対する接続を設定・更新するには、Connection Reference テーブルへの書き込み権限が必要になる。Environment Maker ロールのみではこのテーブルへの「ユーザーまたはチームレベル」のアクセス権にとどまる（公式）。 ...

SQL からエクスポートした Excel ファイルを Dataflows（Power Query ベースのデータフロー）経由で Dataverse（Power Platform のクラウドデータベース）に投入するとき、必ずといっていいほど4つの同じ壁にぶつかる。電話番号の0落ち・Lookup列のマッピングエラー・Choice型の内部値不一致・Upsert用の代替キー設定だ。 この4つはどれも「構造を知っていれば避けられる」種類のつまずきだ。本記事は、各難所の「なぜそうなるか」と「どう設定するか」を1本に収めた逆引きバイブルとして書いた。次の投入作業の前にブックマークしておくと、そのたびに調べ直す時間が不要になる。 なぜ「SQL → Excel → Dataflows」が有効なルートなのかDataverse にデータを投入する方法はいくつかある。SQL から直接連携するパイプライン、Power Automate による行単位の書き込み、そして Dataflows 経由のルート。 Dataflows が実務でよく選ばれる理由は3つだ。 可視性：Power Query エディターで変換内容を列ごとに確認しながら作業できる。何が起きているかが目に見える。 ノーコード操作：M言語の知識がなくても、GUIで型変換・列の追加・フィルタリングが完結する。 クラウド完結型：OneDrive for Business または SharePoint Online にファイルを置けば、オンプレミスデータゲートウェイが不要になる。 行数の上限については、公式ドキュメント（Microsoft Learn「Power Query Online Usage Limits」）で「制限なし」と明記されている。大規模な移行案件でもルートを変える必要はない。ただし1回の実行時間上限は4時間（Power Apps / Power Platform ライセンス）のため、数十万行を超えるような場合はバッチ分割を検討する。 Excel前処理——0落ちと型崩れを事前に防ぐDataflows に読み込む前の Excel ファイルで起きる型崩れを防ぐ。ここを飛ばすと、投入後に意図しないデータが静かに混入する。 電話番号・コードの「0落ち」対策Excel はデフォルトで数値として認識できる列を自動変換する。0901234567 は 901234567 になり、0001 は 1 になる。 対策は、列のセルを文字列フォーマットに設定してからデータを入力または貼り付けることだ。 手順： 対象列を選択 → ホームタブ → 「数値」グループのドロップダウン → 「文字列」に変更 この状態でデータを貼り付ける（既に数値化されている場合は再入力が必要） Dataflows 側で Power Query の「データ型」を「テキスト」に変更しても、Excel ファイル側で既に0が落ちていれば後の祭りだ。前処理の段階で封じる。 ...

Copilot を入れるべきか迷ったとき、機能の派手さを比べても判断は前に進まない。 見るべきは月額固定費の重さと、抜くときの摩擦だ。そしてこの二つは、Copilot 単体ではなく、その下にある基底ライセンス側に効いてくる。 結論から言う。Copilot は基底ライセンスへのアドオンであり、止めにくいのは Copilot ではなく基底ライセンスの方だ。この構造を最初に置くと、判断はだいぶ軽くなる。 入口の置き換え：「抜いたら何が残るか」で見るMicrosoft 365 Copilot は、Business Standard や E3 といった基底ライセンスの上に乗せる AI 機能のアドオンだ。だから Copilot を抜いても、Office アプリ・OneDrive・Exchange のデータは、基底ライセンスの契約が続く限りそのまま残る。 逆に、基底ライセンスそのものを解約すると話は変わる。後で触れる解約後のデータ保持期間を過ぎれば、データは消える。つまり「毎月いくら払うか」を入口にすると判断を間違える。Copilot 部分は身軽に外せるが、基底ライセンス側は外した瞬間にデータの残り方が問題になる。 「抜いても残るもの」と「抜くと消えるもの」を分けて見る。これが固定費を冷静に扱う最初の一歩になる。 独立クリエイターの最低構成と総額——3 ルートを並べる個人事業主が実務に組み込むときの最低構成を、3 つのルートで並べてみる。為替は本文を通して 150 円/USD 換算で示す（実際の請求は契約時のレートに依存する）。価格はいずれも 2026 年 5 月時点・年払い・税抜・ユーザー 1 名の前提だ。 ルート 構成 月額の目安 位置づけ A Business Standard + Copilot Business 約 ¥5,024／月 最も現実的な最低構成 B E3 + Microsoft 365 Copilot 約 ¥9,897／月 契約可だが約 2 倍の固定費 C Personal/Family + Copilot Pro 月額 3,200 円（Copilot Pro 単体・日本） 参考。事業利用はグレー ルート A は、Business Standard の日本価格 ¥1,874／月に、Copilot Business の $21／月（150 円/USD 換算で約 ¥3,150）を足した約 ¥5,024／月になる。ここで一点、誠実に書いておく。Copilot Business の日本円の公式月額は、2026 年 5 月時点で Microsoft の日本サイトに直接の掲示が確認できない。上の金額は USD 表示を為替換算したものだという前提で受け取ってほしい。日本円の確定値は要検証だ。 ...

氏名をアスタリスクに置き換えた。日付も丸めた。それで「マスク完了」として開発環境にデータを流している——この判断に、識別子レベルの穴が開いていることがある。 個人情報保護法が「匿名加工情報」に求める要件は、「特定の個人を識別できず、かつ復元不可能」（第2条第6項・2017年5月30日施行）だ。支社コードや担当者コードが残った状態では、その要件を満たさない。 結論から言う。境界線は「氏名を消したか」ではなく、「識別子レベルで設計されているか」に引かれる。 判断軸の核心：「誰であるか」より「どのコードか」氏名・住所・生年月日は、誰もがマスク対象だとわかる。見えている。 問題は見えていない識別子だ。支社コード、担当者コード、部門コード、顧客番号——これらは「個人名ではない」という認識から、マスク対象として見逃されやすい。 経済産業省の「匿名加工情報作成マニュアル」（Ver1.0・2016年8月）は、k-匿名性（k≧2）という技術基準を示している。k-匿名性とは、あるレコードが少なくとも k 個の他のレコードと区別できない状態を指す技術要件だ。支社コードが「BR-07（東京第7支社）」のように実コードのまま残れば、社員名簿と突き合わせるだけで個人が絞り込める。これが間接識別子の再識別リスク（経産省技術基準（2016年）では k-匿名性として定式化されており、業界では「モザイク効果」とも通称される）だ。 識別子の設計こそが、安全な境界線の実体だ。 判断が割れるケース：「社内データだから大丈夫」開発環境への本番データ持ち込みが曖昧になりやすいのは、次のようなシナリオだ。 ケース1：社内申請システムの開発 Power Apps で社内の経費申請システムを開発する。テストデータに実際の社員情報を使えば動作確認が楽だ。「社内限定だし」という判断が走る。しかし開発環境は、本番環境と比べてアクセス制御が甘い。Microsoft の ALM（Application Lifecycle Management：アプリのライフサイクル管理）原則は、「環境はセキュリティ境界として機能する」（Environments act as security boundaries）と明示している。開発環境は本番環境と同等のセキュリティを持たない前提で設計されている。 ケース2：外部委託プロジェクトでの引き継ぎ 委託先に動作確認してもらう必要があり、「実データに近いものを渡す」判断をする。この時点で、担当者コードや顧客コードが混入していると、法人の営業秘密に該当し得る情報が外部に渡る構造が生じる。不正競争防止法上の論点が発生しうるが、コード類が「営業秘密」に当たるかは個別判断であり、法的断定はできない。ただし、リスクが生じうる構造であることは確かだ。 ケース3：Power Automate フローのテスト 接続先エンドポイントが開発と本番で切り替わっていない状態で実コードを流すと、本番環境への誤通信・誤通知が発生しうる。Microsoft の ALM basics ドキュメントは「Solutions don’t contain any business data.」と明示している。この設計思想は、開発ソリューションにビジネスデータを持ち込まない前提を前提としており、識別子が実コードのまま残った状態でのフロー実行はその前提を崩す。 設計時に詰める識別子チェックリスト開発環境へデータを持ち込む前に、以下を確認する。 識別子の種類 リスク 対策 支社コード・部門コード 名簿と突き合わせで個人特定が可能 連番（BR-001, BR-002）に置換 担当者コード・社員番号 直接的な個人識別子として機能 ハッシュ化または連番化 顧客番号・取引先コード 営業秘密・機密情報に該当しうる 開発用ダミー番号で差し替え 日付・期間データ 出来事との組み合わせで個人特定が可能 丸め処理（月単位・四半期単位） 金額・数量の実値 特定案件の特定が可能 ランダム化または範囲での丸め このチェックを通過したデータが、法令上の「仮名加工情報」（第2条第5項・2022年4月施行）の要件に近づく。仮名加工情報は、他の情報と照合しない限り特定の個人を識別できない状態に変換したデータであり、開発・テスト用途への活用可能性が認められている（PPC「ガイドライン（仮名加工情報・匿名加工情報編）」）。マスクの目的地として、この要件を基準に設計するのが合理的だ。 対策 A：コード類のハッシュ化・連番化支社コード「BR-07」を「BR-001」のような連番に置き換える。担当者コード「EMP-12345」は、ハッシュ関数を通した文字列か、連番の仮コードに変換する。 重要なのは、変換ルールの台帳を開発環境とは別管理にすることだ。変換台帳が開発環境に置かれると、復元が可能になり、匿名加工情報・仮名加工情報の要件を満たさなくなる。 Power Platform / Dataverse 固有のハッシュ化・連番化の実装手順は、2026年時点では Microsoft 公式ドキュメントで直接提供されていない。実務での観察では、Power Query の変換ステップか、Python スクリプト等の前処理ツールで変換してから Dataverse にインポートするパターンが確認されている。詳細は続編（「Dataverse 投入前の落とし穴」）で扱う予定だ。 ...

インボイス制度 2 年目（2025〜2026 年）の経過措置・特例・請求書実務を、公的原典から自分で判断するための話 毎月の請求書を切るとき、画面の右上に並ぶ「T」から始まる 13 桁の番号を、あなたはもう何度も眺めている。 取引先から「インボイスの登録、どうされてますか」とメールが届くようになって、しばらく経った。 今年もまた、来年 10 月から経過措置（仕入税額控除を段階的に縮小する移行措置）の控除率が下がるという話を、税理士のメルマガで見かけた。 会社員のままでは漠然と気になっているだけだった話題が、独立を視野に入れた途端、毎月の数字として降りてきた人もいるだろう。すでに独立した人なら、2023 年に免税のまま据え置いた判断を、来年もう一度問われていることに気づいているはずだ。 問題は、誰も「あなたの場合はこう」とは言ってくれないことだ。会計ソフトの広告は「登録しましょう」と言い、SNS では「登録するな」という声も流れてくる。そのどちらに乗っても、3 年後の請求書を切るのはあなただ。 だから、ここでは保証ではなく、判断材料を並べる。SNS の言葉ではなく、国税庁の原典と、商工会議所の調査と、税制改正大綱の数字で。 1. なぜ今、この判断を一度しておくのかインボイス制度は 2023 年 10 月に始まり、3 年が経った。最初の 3 年間は経過措置として、免税事業者からの仕入れでも消費税額の 80% を控除できる扱いだった。これが、2026 年 10 月から 70% に下がる。さらに数年かけて段階的に縮小していくことが、令和 8 年度税制改正大綱（2025 年 12 月 19 日 与党公表）で確定見込みになっている。 ここで二つの「もし」を、先に置いておきたい。 ひとつ目。あなたが今、免税のまま据え置いているとする。来年 10 月から取引先側の控除率が 80% から 70% に下がる。その差 10% を、取引先が黙って負担し続けるとは限らない。値下げ交渉の打診が来たとき、原典を読んでいない状態で受け答えをすれば、あなたは「言われたまま」の値段を呑むことになる。10% は、月に 30 万円の取引なら年間 36 万円分の交渉余地に相当する。これを 5 年間、毎年やり直す。 ふたつ目。あなたが今、2023 年に登録して 2 割特例（売上税額の 2 割だけを納める負担軽減措置）で乗り切ってきた個人事業主だとする。この 2 割特例は 2026 年 9 月 30 日で終了する。終わったあと、何が起きるのか。後継の措置はあるのか。あるとして、自分は対象になるのか。これを知らずに 2026 年の確定申告期を迎えると、3 月の自分が困るのは、12 月の自分の不勉強の結果でしかない。 ...