Posts

「共同所有者として共有したのに、なぜメールが送れない？」 この問いに答えるには、権限の問題が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 月の自分の不勉強の結果でしかない。 ...

「Power Platform に投資する価値があるか」を、求人広告でも誰かの体験談でもなく、公的データから自分で判断するための話 毎朝、貸与 PC を起動して、いつもの Microsoft 365 を開く。 Outlook、Teams、Excel、SharePoint。同じ画面、同じ手順、同じ一日。 その並んだアイコンの片隅に、しばらく前から Power Apps や Power Automate のアイコンが増えている。社内の誰かが「これからはローコードだ」と言っていた。研修案内も回ってきた。 そして、あなたの頭の片隅には、ずっと同じ問いがある。 「これ、自分が時間を賭ける価値はあるのか」 会社にはまだ不満も不安もある。けれど辞められない。起業のアイデアもない。それでも、惰性で老いていく上司や同僚を見ていると、何か一つ、自分の足場になるスキルを持っておきたい気持ちがある。 問題は、その「何か一つ」に Power Platform を選んでいいのか、誰も保証してくれないことだ。だから、保証ではなく、判断材料を並べる。広告の言葉ではなく、決算とリサーチ会社の数字で。 1. 「賭けたのに外れた」とは、具体的に何が起きることかスキルへの投資が外れる、というのは抽象的に聞こえる。だから、起こりうる二つの具体を先に置いておきたい。 ひとつ目。あなたが今後 3 年、平日の夜に少しずつ時間を積んで、Power Platform を「人に教えられる」水準まで持っていったとする。3 年後、それを足場に社内で頼られる人になり、あわよくば独立の選択肢も視野に入れていた。ところが、その 3 年が終わる頃、市場の主役が別の技術に移っていた——そうなれば、積んだ時間そのものは消えないにせよ、「足場」として期待した価値は目減りする。3 年という時間は、戻ってこない。 ふたつ目。逆に、あなたが「どうせ流行りものだ」と判断を見送ったとする。3 年後、Power Platform を扱える人が社内で重宝され、内製化の中心にいる。あなたはその輪の外で、相変わらず同じ画面、同じ手順の一日を続けている。賭けて外す痛みと、賭けずに外す痛みは、どちらも実在する。 だから必要なのは、「流行っているらしい」でも「どうせすぐ廃れる」でもない、第三の態度だ。伸びている市場なのか、伸びているとして自分が乗れる余地が残っているのか、そして将来をどう削る要因があるのか——これを数字で見て、自分の頭で決める。以下はそのための材料を、順番に並べていく。 2. まず、市場は本当に伸びているのか最初に、いちばん大きな絵から。 Microsoft の FY2025 Q3 決算（2025 年 4 月 30 日発表）によれば、Power Platform のグローバル月間アクティブユーザーは 5,600 万人、前年比 27% 増。すでに普及しきった製品の数字ではなく、いまも 2 桁台後半で伸びている最中の数字だ。 国内に目を移すと、調査会社 2 社が別々の集計で同じ方向を指している。 IDC Japan の予測（2024 年 11 月 25 日）では、国内のローコード/ノーコード/生成 AI 開発テクノロジー市場は 2023 年度の 1,225 億円から、2028 年に 2,701 億円へ。年平均成長率（CAGR）にして 17.1%、5 年でおよそ 2.2 倍の規模になる見通しだ。 ...

Power Platform で社内の問い合わせ・申請を仕組み化するとき、ツールではなく「進め方」をどう設計するかの話 社内の経費申請が、いまだに紙とハンコで回っている。 ヘルプデスクへの問い合わせが、特定の人の Outlook に溜まり続けている。 休暇申請の集計のために、毎月末、誰かが Excel を手で突き合わせている。 これらをデジタル化したい、という相談は、Microsoft 365 を導入した組織なら必ず出てくる。 そして、その多くが、Power Apps や Power Automate という「ツールの話」から始まる。 ところが、社内デジタル化の成否を分けるのは、ツールの選定ではない。進め方の設計だ。同じ Power Platform を使っても、定着する組織と頓挫する組織がある。その差は機能の差ではなく、最初にどう設計したかの差にある。 ここでは、手段としての Power Apps / Automate / BI の操作手順は扱わない。扱うのは、社内の申請・問い合わせ業務をデジタル化するとき、働く人が「失敗しないために」どこで判断を間違えやすいか、という判断軸だ。 1. ツールを選ぶ前に、ひとつだけ確認しておきたいこと仮に、いま手元にある「紙の経費申請」と「Outlook に溜まる問い合わせ」を、何も設計せずにそのままツールに載せ替えたとする。 起きやすいのは、次の二つだ。 ひとつ目は、作った人にしか分からないツールが、ひとつ増えること。最初は便利に動く。だが、作った担当者が異動・退職した瞬間、誰も中身を把握していない申請フローが本番で回り続ける。修正もできず、止めることもできず、ただ動いている。これは「デジタル化が進んだ」のではなく、属人化の形が紙からアプリに変わっただけだ。集計の手作業が消えた代わりに、保守できない資産がひとつ増えている。 ふたつ目は、最初は問題なかった設計が、データが溜まった頃に壊れること。後で §3 で具体的な数字を挙げるが、SharePoint リストを安易にデータ置き場にすると、件数が一定の閾値を超えた時点で一覧の挙動が変わる。運用 1 年目は快適でも、2〜3 年分のデータが溜まった頃に、ある日突然「申請一覧が全部は出てこない」事態になる。そのとき作った人がもういなければ、原因の特定から始めることになる。 どちらも、ツールの機能不足が原因ではない。進め方を設計しなかったことが原因だ。 逆に言えば、この二つは設計段階でほぼ回避できる。本記事の残りは、その設計の判断軸を順番に整理していく。 2. デジタル化は、なぜこれほど進まないのかまず、自分の組織がどの位置にいるのかを、公的データで確認しておきたい。「うちだけ遅れている」という焦りも、「もう手遅れだ」という諦めも、たいてい数字を見ると不要になる。 総務省「令和 7 年版情報通信白書」によると、大企業の約 25%、中小企業の約 70% が、デジタル化を「未実施」と回答している。半数以上の中小企業は、まだ着手すらしていない段階にある。 一方で、市場は着実に動いている。ITR の調査では、国内のローコード/ノーコード開発市場は 2023 年度実績で 812 億 2,000 万円（前年度比 14.5% 増）、2023〜2028 年度の年平均成長率（CAGR）は 12.3% で、2028 年度には 1.8 倍規模になると見込まれている。IDC Japan のノーコード開発市場の集計でも、2023 年の 1,225 億円から 2028 年に 2,701 億円（CAGR 17.1%）への拡大が予測されている。 ...

Power Automate と Logic Apps の使い分けは、機能比較表を眺めるほど判断が遅くなる。 結論は単純で、**「3年後にこれを誰が触っているか」**が決まれば、ツールも決まる。 業務部門が3年後も自分で触る → Power Automate 3年後の保守オーナーが見えない → Logic Apps これだけで、9割の判断は片付く。 なぜ機能比較表では決められないか両者の機能比較は、調べれば10行でも20行でも書ける。だが、機能はどちらでも8割重なっている。残りの2割の違いは、現場のほとんどで誤差だ。 決定的に違うのは、運用の主語だ。 観点 Power Automate Logic Apps 運用の主語 業務部門 IT/インフラ部門 ライセンス起点 M365 ユーザー / Premium Azure サブスクリプション 統制と監査 Power Platform 管理センター + Purview Azure Monitor + Defender for Cloud Power Platform の本質は「業務部門が自分で直せる」ことであり、その前提が崩れた瞬間、Power Automate を選ぶ理由は半分消える。 逆に、IT 部門が SLA を持って運用する世界に Power Automate を置くと、Premium ライセンス費用と運用統制の不整合で、3年後に必ず揉める。 ツール選定とは、3年後の組織図を予想する作業だ。 中規模・部門横断のときだけ迷う判断が割れるのは、たとえばこういうケース。 経理部が起点だが、人事と情シスにもまたがる承認ワークフロー 月数万件のトランザクション データソースが Dataverse + SharePoint + 外部 SaaS API このとき、Power Automate Premium で攻めるか、Logic Apps Standard で攻めるか。 ...

環境前提：M365付帯ライセンス（標準コネクタのみ）。プレミアムコネクタ・RPA・AI Builder は有料プランが必要。 結論は単純で、月に27分以上の作業削減が見込めるかどうかで、プレミアムプラン（月額約2,248円）への移行判断は片付く。 Salesforce・kintone・HTTP APIなど外部システム連携が主目的なら、その時点で計算は終わっている。 無料枠で何ができて、何ができないかまず境界線を確認する。「無料でどこまでいけるか」は、コネクタ分類で決まる。 機能 Power Automate Free M365付帯（シード） Premium（有料） 標準コネクタ（Outlook/OneDrive/Teams/Forms等） ○ ○ ○ プレミアムコネクタ（Salesforce/SQL/HTTP/kintone等） × × ○ カスタムコネクタ × × ○ Dataverse（データベース） × × ○（250MB / 2GB） AI Builder（名刺読み取り・GPTモデル等） × × ○（5,000クレジット/月） アテンド型RPA（有人ボット） × × ○（1ボット） フローの他者への共有 × △（条件あり） ○ 出典：Microsoft Learn「Power Automateライセンスの種類」2026年3月更新 M365付帯ライセンスで実現できる代表的なシナリオは、以下の通りだ。 Outlookで受信した添付ファイルをOneDriveに自動保存 SharePointリストが更新されたらTeamsに通知送信 Formsの回答をExcelオンラインに自動記録 ExcelデータをWordテンプレートに差し込む定型レポート生成 すべてMicrosoft 365のサービス内で完結する処理であれば、追加費用なしで動く。 Power Automate Desktop（デスクトップ版）について Windowsアプリ操作の記録・再生、Excelの読み書き、Webブラウザ操作の自動再現は、Power Automate Desktop（Windows 11標準搭載）で無料実行できる。ただし手動実行のみ。スケジュール自動実行には有料プランが必要になる。クラウドフローの有料移行判断とは別軸の話なので、混同しないことが肝要だ。 いつ有料に移行するかの判断軸有料プランへの移行は、コスト回収ができるかどうかの問題だ。 Power Automate Premiumの月額は約2,248円（税込換算、為替により変動。出典：Microsoft「Power Automate 価格」公式ページ）。 損益分岐の計算は単純だ。 削減できる作業時間（月） × 時給 > 2,248円 なら移行する 時給5,000円のフリーランスであれば、月に27分以上の作業削減が見込めれば元が取れる。 ...

結局どこも似ているが、選ぶ価値のある 2 社の見極め方 「フリーランスになろう」と決めた瞬間、最初に直面する問いは、これだ。 どのエージェントに登録すべきか。 レバテックフリーランス、ITプロパートナーズ、HiPro Tech、テクフリ、ココナラテック、クラウドワークステック——名前だけで 20 社以上ある。 どこも「業界最大」「高単価」「リモート 9 割」と謳っている。 ただ、率直に言うと、Power Platform エンジニアの視点で各社を比較すると、機能としてはほぼ同じだ。差は表面的な数字ではなく、運用品質に出る。 この記事は、その前提に立った上で、あなたが選ぶ側に立つためのエージェント選定ガイドだ。 1. 結論——レバテックと ITプロパートナーズの 2 社で十分長くなるので、先に結論を書く。 Power Platform エンジニアでハイブリッド型を目指すなら、以下の 2 社の併用で十分。 推奨 エージェント 強み 1 レバテックフリーランス 業界最大手・案件母数が圧倒的・運用が安定 2 ITプロパートナーズ 週 2〜3 日案件と直請が強み・副業期にも適合 3 社目以降は、特定のニーズが明確になってから追加すればいい。 「とりあえず 5 社登録」のような戦略は推奨しない。担当者対応で消耗する。 なぜこの 2 社なのか。順を追って説明する。 2. 「結局、どこも同じじゃないの?」これは多くの人が薄々気づいている疑問だろう。実際、その通りだ。 主要エージェントの公開情報を並べると、表面的な差はほとんどない： 項目 レバテック ITプロパートナーズ HiPro Tech テクフリ 公開案件数 11 万件 9,000 件 6,400 件 18,000 件 Power Platform 取扱 あり あり あり あり リモート対応 高 高 高 高 中間マージン 非公開 非公開（直請多） エンド直 一部 10% これらの数字を眺めて選ぶのは、本質的でない。 本当に違いが出るのは、登録後の担当者の運用姿勢だ。 ...