基礎・全体像

案件が決まってから、最初に手を動かせるまで何をしていただろう。 アカウントの発行を待つ。貸与パソコンの到着を待つ。VPN の設定手順書を待つ。情報システム部門の承認を待つ。契約は成立しているのに、環境が揃うまで着手できない。その待ち時間に、報酬を払ってくれる人はいない。 この待ち時間を、多くの人が「仕方のないもの」として受け入れている。環境を用意してもらわないと開発は始まらない、という前提があるからだ。 その前提を、一度外してみる。 「触らない」は制約ではなく設計になった顧客のテナントに一切接続せず、自分の開発環境だけでアプリを組み上げ、ファイル1つで納品する。この形は以前から理屈のうえでは可能だったが、2026年に入って土台のほうが追いついてきた。 Microsoft の権限設計が、この形を推奨する側に回った。 開発者が AI エージェントに Dataverse を触らせようとすると、テナント全体の管理者同意と環境ごとの許可リスト登録という2段の関門を通る必要がある。この関門は迂回できない。顧客のグローバル管理者にとっては、テナント全体に効く同意を外部の委託先のために出す判断になる。承認のハードルは高い。 顧客のテナントに AI を入れる道は、技術のほうが先に閉じている。 開けようとすること自体が、無理筋になった。 もうひとつ、ゲストアカウントで呼んでもらう抜け道も細くなった。新しく作られた環境では、既定でゲストの Dataverse アクセスが遮断される 設定になっている。「ゲストで招待するから作業して」は、Power Platform では成立しない。 残る道は2つになる。顧客が正規のアカウントを発行してくれるのを待つか、そもそも触らずに作るか。 触らないと決めると、何が起きるか自分の側にすべてが返ってくる。 顧客の環境には、業務で使われている本物のテーブルがある。実際のデータが入っていて、動いているフローがあり、誰がどこまで見られるかの設定が積み上がっている。そこに入れてもらえるなら、現物を見て真似ればいい。 入らないと決めた瞬間、それが全部なくなる。渡された仕様書と、自分の頭のなかにある構造の知識だけで、同じものを組み立て直すことになる。 ここが分かれ目になる。この働き方が成立するかどうかは、契約でも交渉でもなく、構造をどれだけ正確に再現できるかで決まる。 再現しようとすると、必ず詰まる場所がある。しかもその場所は、驚くほど毎回同じところだ。 詰まる場所は4つに分かれる自分の環境で作り直すとき、つまずきは4つの層のどれかで起きる。 第1層：データの形。 テーブルとテーブルをどう繋ぐか。Lookup 列は SQL の JOIN とは違う挙動をするし、Excel から取り込んだ参照は静かに空のまま入る。名前の列を突合キーに使うと、あとから壊れる。 第2層：誰に何が見えるか。 一覧画面から隠すことと、権限で守ることは別物だ。ビューのフィルターはアクセス制御ではない。フォームから列を外しても、その列の中身は守られていない。ビジネスユニットを無効化しても、権限は切れていない。この層の誤解は、納品してから発覚すると信頼の問題になる。 第3層：認証と鍵。 鍵を渡さずに繋ぐ方法。認証は通っているのに拒否されることがあり、401 と 403 を切り分けられるかで原因が変わる。承認する人に本番権限が要らない仕組み。個人PCで作る働き方は、この層を説明できることが前提条件になっている。 第4層：コストと性能。 従量課金は誰に開かせるかで決まる。並列を増やすと遅くなることがある。検証できれいな数値が出たら、まず計器を疑う。 この4層が、「顧客の環境に入らなくても作れる」を実際に支えている中身だ。 環境をもらえば現物を見て済むものを、もらわないと決めたぶん、原理で知っておく必要がある。 それぞれの層で、何を先に読むか以下は、詰まったときに開く場所として並べてある。上から順に読む必要はない。 第1層 データの形 DataverseのLookup列はSQLのJOINではない——Excelインポートで参照が空のままになる理由 DataverseのName列をUpsertの突合キーに使ってはいけない理由と、代替キー設定の3ステップ Dataverse 代替キーで Lookup を張る——取込時正規化と親→子ロードオーダーの作法 フロント入力データをSoRに昇格させるか——判断は「他システムが書き足すか」の一点 Power Platform のローコードは行を作れる。多対多の繋ぎは作れない 第2層 誰に何が見えるか Dataverse のビューフィルターはアクセス制御ではない——ロール深度×BU 構造で守り、API で壊して確かめる Dataverse の列セキュリティ——フォームから外すだけでは列の機密は守れない Dataverse で owner と owningBU をどう使い分けるか——2語に分けると設計判断が言語化できる Dataverse ビジネスユニットの「無効化」は権限を切らない——廃止設計に失効工程を組み込む判断軸 役職名でアクセスを設計すると例外で壊れる――判定軸を「管理範囲」に移す3つの設計パターン 第3層 認証と鍵 Microsoft Entra ID で AI 外部委託を止めずに進める——鍵もデータも渡さない設計の判断軸 Azure SQL への接続情報を外部ベンダーと共有しない——Entra ID の認証梯子で「鍵を渡さない設計」を組む Microsoft Entra クロステナント：同意しても 401 が返る理由と 403 との切り分け方 Power Platform 委任デプロイ：なぜ承認者に本番権限が要らないのか Power Platform 認可設計：そのアプリが消えても残る環境×グループ 3 層の分け方 第4層 コストと性能 Power Platform 従量課金（PAYG）有効化で踏む2つの壁 Power Apps PAYG のコストは「誰に開かせるか」で決まる 並列を増やすと遅くなる理由と、直列ボトルネックを解消する3つの対策 検証で「きれいな数値」が出たら計器を疑え――4種の測定ミスと確かめる手順 作る場所を3つに分ける知識が揃っても、置き場所を間違えると台無しになる。AI に手伝わせるなら、なおさら線を引いておく必要がある。 ...

SharePoint の「プロンプト集」フォルダを開く。 最終更新日は 8 ヶ月前。投稿者の名前は、すでに別の部署に異動している。 「使えるかもしれない」とクリックしたプロンプトの説明文には、退役済みのモデル名が書いてあった。 Teams のチャットを立ち上げて、「誰かこの業務で使えるプロンプト持ってませんか」と打つ。 こういう経験が、1 度や 2 度ではない人は多いはずだ。 1. 3 年分の蓄積が、なぜ一晩で使えなくなるのか具体的な場面を想像してほしい。 あなたのチームが、3 年かけてプロンプトを積み上げたとする。毎月の定例でメンバーが持ち寄り、担当者が週 2 時間を費やして整理した。200 件に達したとき、「ナレッジ資産」として経営報告に記載された。 2026 年 2 月、OpenAI が GPT-4o の退役を発表した。リリースからわずか 21 ヶ月だった（OpenAI 公式）。 GPT-4o 特有の挙動——長めのシステムプロンプトで安定する、特定の言い回しで精度が上がる——に最適化されたプロンプトは、次世代モデルで同じように動かない。GPT-4.1 は GPT-4o より「指示に文字通り忠実に従う」設計に変わったため、同じプロンプトでも挙動が変わることが OpenAI のプロンプトガイドに明記されている。200 件のうち何件が影響を受けるか。1 件の再テストに 30 分かかるとすれば、100 件で 50 時間だ。これが 1 回のモデル交代で発生する。 もし最初から「動作確認日」と「対象モデル」の 2 列をテンプレートに設けていたなら、どうなっていたか。 モデル更新のたびに「この日付より前・このモデル向けのプロンプト」として絞り込める。全件再テストの代わりに、影響範囲の特定から始められる。「GPT-4o の退役が出た。確認が必要な候補は 18 件」——そう絞り込める設計になっていれば、50 時間が 9 時間になっていた。差の 41 時間で、チームは次の業務自動化に着手できていた可能性がある。 「ポータルがある組織」と「ポータルが機能している組織」の差は、設計前の一手で生まれる。 2. ナレッジが腐る構造は、AI に限った話ではないAI ポータルの形骸化は AI 固有の問題に見えるが、ナレッジ管理全般の失敗パターンと重なる部分が大きい。 ナレッジ管理施策の 55% は変革管理の不足や経営層のサポート不足で失敗する（Helpjuice「Knowledge Management Trends and Statistics in 2025」2024-25 年）。能動的な管理がなければ、ナレッジベースの 20〜40% は無関連・陳腐化コンテンツを含むようになる（同調査）。デジタルワーカーの **47% が「業務上必要な情報を見つけるのが困難」**と感じる（Gartner 2023 年調査、二次引用）という実態は、「溜まってはいるが使えない」状態が広く常態化していることを示す。 ...

あなたのパソコンの画面に、いま何のツールが開いているだろう。 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ポイント増）。 ...

ある朝、技術リーダーが会議でこう言った。「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コストだ。アプリを作る手間は劇的に下がった。 ...

「作れること」を安くする同じ波が、判断を持つ個人を武装させる。一人＋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 年目（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%）への拡大が予測されている。 ...

「会社員かフリーランスか」の二択に迷う人のための、第三の道の土台 毎朝、貸与 PC が起動するまで 5 分。 帰り道、スマホで求人サイトを開いて、また閉じる。 「やめたい」と思う。けれど、すぐにはやめられない。起業もできない。アイデアもない。それでも、何かしたい。 この宙吊りの状態に、あなたは何ヶ月、あるいは何年いるだろうか。 「会社員のまま、成長が止まっていく不安」と「フリーランスになって、収入が不安定になる恐怖」。 この二つの間で、毎晩のように天秤が揺れて、結局どちらにも踏み出せないまま、また月曜の朝、貸与 PC の起動を待つ。 この記事は、その天秤を「どちらに傾けるか」の話ではない。 天秤そのものを置き換える話だ。 1. 二択で迷っている間に、起きていないことまず、想像してほしい。あなたが「会社員」と「フリーランス」の二択で迷い続けた、この 3 年間のことを。 もし 3 年前、あなたが「辞めるか辞めないか」を悩む代わりに、会社に在籍したまま、月に 1 件だけ業務委託の小さな案件を受けていたとしたら、どうなっていただろうか。 最初の半年は、月 3 万円程度だったかもしれない。だが、案件を 1 つこなすたびに、あなたには「会社の看板ではなく、自分の名前で受けた実績」が積み上がる。3 年も続ければ、業務委託の月収は 10 万円前後で安定し、取引先は 2〜3 社になっていた可能性がある。 そのとき、あなたは「いつでも辞められるが、辞めない」という立場に立てている。会社の評価面談で理不尽なことを言われても、心のどこかで「最悪、こちらには別の収入がある」と思える。その余裕は、交渉のテーブルでのあなたの姿勢を変える。 あるいは、その 3 年間、平日の夜に 1 時間ずつ、Power Platform や AI ツールで自分の作業を自動化する練習をしていたとしたら。 3 年後、あなたは本業を定時で終え、空いた時間で副業案件をさばける「時間の余白」を手に入れていたかもしれない。 これらは、起きなかった。 「辞めるか、辞めないか」という二択の問いに、あなたの 3 年が吸い込まれていったからだ。 問題は、辞める勇気がないことではない。 問いの立て方そのものが、あなたを動けなくしていることだ。 2. 「会社員かフリーランスか」は、もう二択ではないここから、公的データで構造を確認していく。あなたの感覚ではなく、数字で。 総務省「就業構造基本調査」（2022 年）によると、日本の副業者数は約 332 万人で、就業者全体の 5.0% にあたる。10 年前と比べて副業者数は 4 割強増加し、副業比率も約 1.4 ポイント上昇している（財務省「副業の実態把握」2025 年経由）。 注目すべきは、その中身だ。 厚生労働省の調査（2024 年 11 月）によれば、本業が正社員の副業者のうち、「自由業・フリーランス（独立）・個人請負」として副業している割合は 21.2〜21.7%。これはパート・アルバイト（39.6%）に次いで 2 番目に多い副業形態だ。 ...

日本のホワイトカラーが OECD で 21 位に沈み続ける構造の話 毎朝、貸与 PC が起動するまで 5 分。 週 1 回のグループ会で 1 時間。 半期に一度の評価面談シートを書くために、日曜の夜に 2 時間。 コンプラ研修、社員総会、勤怠申請。 これらが「仕事」として労働時間にカウントされていることを、あなたは知っている。 そして、これらが「あなたの成長」にどれだけ寄与しているかも、薄々わかっている。 けれど、誰もそれを口に出さない。口に出した人は浮く。だから黙って、また月曜の朝、貸与 PC の起動を待つ。 1. 数字を見る前に、ひとつだけ想像してほしい仮に、あなたが「グループ会」「報告会」「評価面談シート作成」「社員総会」「コンプラ研修」「勤怠申請」のすべてから解放され、年間 325 時間が手に入ったとする。 その時間で、あなたは何ができただろうか。 たとえば、平日の夜、毎日 1 時間を英語学習に充てたなら、3 年で TOEIC は 700 点を突破していた。 今頃あなたは、ひとりで海外出張の交渉を任され、合間にバンコクで休暇を取ることが、年に 2 回くらいは普通のことになっていたかもしれない。 あるいは、その時間で個人プロダクトの開発に充てていたなら、副業として月 5 万円の収入が立っていた可能性がある。それは、あなたの将来の選択肢を 1 つ増やすには十分な金額だ。家を買うか買わないか、転職するかしないか、子どもの進学先を絞らずに済むか。それらの判断が、この月 5 万円で変わってくる。 これらは、起きなかった。 グループ会と評価面談シートが、あなたから先回りで奪っていったからだ。 2. 日本のホワイトカラーは、世界で何位なのか公益財団法人日本生産性本部の発表によると、日本の一人当たり労働生産性は OECD 加盟国中 21〜22 位の水準で長期低迷している。1970 年以降、ほぼ毎年この順位帯から抜け出せていない。 ここで重要なのは、日本の製造業（ブルーカラー）は世界トップ級の生産性を誇っているという事実だ。トヨタのカンバン方式やカイゼンに象徴されるように、現場の作業効率は世界の手本になっている。 つまり、日本全体の生産性を 21 位まで引き下げているのは、ホワイトカラー側ということになる。 営業、企画、管理、間接部門——あなたが今働いている領域だ。 KDDI の法人向けメディア「be CONNECTED.」では、日本企業のホワイトカラー生産性低迷の最大要因として「会議に長い時間を費やしている点」が挙げられている。レイヤーズ・コンサルティング社の分析でも、「同じパフォーマンスを行うのに、日本企業が投入している労働者数と労働時間が、米国・ドイツに比べて多すぎる」と指摘されている。 つまり、あなたの労働時間のかなりの部分は、**「同じ成果を出すために、よその国より多くかかっている時間」**だ。 これは、あなたの能力の問題ではない。構造の問題だ。 出典：公益財団法人日本生産性本部「労働生産性の国際比較」、OECD 統計、KDDI「be CONNECTED.」、リコー「働き方改革ラボ」、レイヤーズ・コンサルティング 3. 「でも、コンプラは必要だろう」ここで、誠実な反論が来る。 ...