こんにちは︕私は アーカーシュ マラシニです。
ネパール出⾝のエンジニアで、Media Fusion Co.Ltd. で Microsoft365 および Power Platform（Power Apps/Automate/BI）の構築・カスタマイズエンジニアとして働いています。
MS365 と Power Platform に関するブログを通じて、私が学んだことや経験を皆さんと共有していきます
１．はじめに
2026年以降、ローコードおよびノーコードプラットフォームは、組織が内部システムを構築し、業務を自動化し、業務をデジタル化する方法を大きく変えてきました。Power Apps、Power Automate、n8n、Power Pages、kintone、Zapier、Make、といったツールは、それぞれビジネス要件に応じて異なる強みを持っています。
しかし、これらのプラットフォームを使って実際のシステムを構築・運用してみると、重要な事実が明らかになります。プラットフォームの選択は、機能だけでは決まりません。拡張性、保守性、ライセンス、柔軟性、統合機能、ガバナンス、そして長期的な運用コストなど、さまざまな要素がソリューションの成否を左右します。PoCを短期間で構築できることだけでなく、長期的な運用やビジネスの観点からプラットフォームを選択することが重要です。特に、PoCから本番環境へ移行する段階になると、その違いはより顕著に表れます。
実際、多くのプロジェクトでは共通したパターンが見られます。PoC（概念実証）やアルファ版をローコードで作って現場が触り始めます。使い勝手が良いため、そのまま本番環境へ移行しようとします。しかし、そのタイミングで「これ、本当に使い続けられるのか？」という問いから逃げてはいけません。
ローコードを選んだなら：コストの上限をどう引き下げるか
PoC段階でのスピードや手軽さを評価してローコードを選んだとします。次の課題は「そのままスケールしたときのコストをどう抑えるか」です。以下、よく直面する3つの壁と、その乗り越え方を整理します。
２．知っておくべき弱点
壁①：データが増えると遅くなる（Power Apps Basic・kintone）
Power Apps BasicはSharePoint Listsをデータソースとして使いますが、委任できないクエリでは最大2,000件、SharePoint自体も5,000件超でパフォーマンスが低下します。
kintoneも同様に、レコード数が増えてデータ構造が複雑になるほど処理が重くなります。Kintoneはこれとは事情が違います。 データ件数自体は100万件規模まで動くと言われていて、単純な件数だけならそこまで心配する必要はありません 。問題になるのはレコード数ではなく、データ構造の複雑さです。テーブル間の関連が増えてくると、標準機能だけでは対応できず、JavaScriptでのカスタマイズが必要になります 。しかもこれを解決してくれる外付けツールは特にありません 。複雑なリレーションを組みたくなったら、Kintoneの設計そのものを見直すしかありません 。もう一つ、Kintoneには社外公開の標準機能がありません。
顧客やパートナーに見せたいというニーズが出てきたら、自分で外部公開用の仕組みを作るか、別の外部サービスに頼る必要があります。アプリの読み込みが遅くなると、ユーザーは使わなくなります。ローコードを選んだ最大の理由だった「スピード」が失われます。
乗り越え方：SharePoint Listsを分散させます。
Dataverseへの移行は一つの選択肢です。Dataverseはリレーショナルデータベース（RDB）であるため、リレーションシップを作成でき、レコード内にテーブルを作成できるため、SharePoint Lists よりもはるかに簡単に作成できます。ただし、ユーザーごとにプレミアムライセンスが必要になります。ユーザー数が多い環境では、Dataverseに移行するよりも、Webシステムをゼロから構築する方が費用対効果に優れる 場合があります。
多くの現場では、SharePoint Listsを機能・部門ごとに分散させてデータを管理し続ける方が現実的です。正規化の代わりに分散で対処する、という割り切りです。Dataverseを本格的に使う判断をするなら、全ユーザー分のPremiumライセンス料と、スクラッチ開発の初期コスト・5年間の運用コストを比較してから決めてください。なお、Dataverseを実質無料で使えるのはTeamsアプリとして構築する場合に限られます。Dataverse導入で実績が多いのは、「Power Appsで複数のアプリを組織的に展開すると決めた企業」がほとんどです。当社として、Teams用途以外でのDataverse採用は推奨していません。
壁②：外部連携でコストが急増 する（Power Automate・Zapier）
Power AutomateはMicrosoft 365内の連携には強力ですが、Salesforceや外部APIなどMicrosoft 365外のシステムと繋ごうとすると、Premiumコネクタが必要になります。Zapierは8,000以上のアプリと繋がれますが、タスク実行ごとの課金モデルのため、自動化が実際に動き出すと費用が想定の2〜3倍になることがあります。
乗り越え方：外部連携をn8n（オープンソース）に分担させます。
外部APIやSaaS間の連携をn8nに移す構成が有効です。自社サーバーで運用するため、実行ごとの課金がありません。ただし、接続の設計がポイントです。Power AutomateからWebhookでn8nを呼ぶHTTPアクションはPremiumコネクタに該当します。コストを抑えるには2つのアプローチがあります。
Premiumを最小化する場合は、Webhook送信を専用のサービスアカウント1つに集約し、そのフローのみがn8nと通信する設計にします。Premiumをゼロにする場合は、Power AutomateはSharePoint Listsへの書き込みにとどめ、n8nがその SharePoint Lists をポーリングして取得する設計にします（リアルタイム性はやや低下）。整理すると、Microsoft 365内のフローはPower Automate、外部連携はn8nという役割分担です。すべてを一つのツールで完結させようとするより、コスト効率は大幅に高くなります。
壁③：社外向けポータルが必要になったとき（Power Apps・kintone）
社内業務アプリとして動いていたシステムに、「顧客やパートナーにも見せたい」という要件が加わることがあります。このとき、ツールの選択肢は大きく3つです。
- Power Pagesで拡張する： Power PlatformのDataverseと統合されているため、社内アプリとデータを共有できます。ただしライセンスコストが加わります。コストとユーザー数を再度試算した上で判断してください。
- 公開部分だけスクラッチで作る： 社内の管理・処理部分はローコードのまま残し、外部公開のフロントエンドだけをスクラッチ開発する構成です。
- 全部スクラッチで作り直す： 利用者数や機能要件によっては、この選択が5年コストで最も安くなることもあります。
３．クイックリファレンス：ギャップとそのギャップを埋める方法
| 弱点補完 | ツール | 対象ツール | 技術レベル | コスト |
| データの複雑化・大規模化（5,000件超のレコード、リレーショナル構造） | 複数のSharePoint Listsにデータを分散する | Power Apps Basic/Kintone | 初級〜中堅エンジニア | 有償（ユーザー課金） |
| 外部連携コストの急騰（Premiumコネクタ、Zapierのタスク課金） | n8n（オープンソース） | Power Automate / Zapier | サーバー管理ができるエンジニア | 無料（セルフホスト） |
| 社外向けWebポータル（顧客・パートナーアクセス、外部URL公開） | Power Pagesで拡張する／公開部分のみをゼロから構築する／完全にゼロから再構築する | - | ITリテラシーのある社内スタッフ | 有償（プラン別） |
| Dataverseのライセンスコスト （ユーザー単位のPremium） | Teamsアプリ以外では採用を見直し、5年コストでスクラッチと比較 | Power Apps Premium / Dataverse | 中堅エンジニア〜DX担当 | 有償（ユーザー課金/高額） |
４．実践的なポイント
- コスト急増のポイントを事前に特定する
各ツールには、コストが急増する可能性のあるポイントが存在します。例えば、SharePointListsの容量が不足した場合のDataverse、Power Automateが外部サービスと連携する必要がある場合のプレミアムコネクタ、Zapierがスケーリングを開始した際のタスク制限、n8nのメンテナンスが必要になった際のサーバー時間などが挙げられます。これらは予測可能な要素です。請求額に驚かないように、ロードマップに早期に組み込んでおきましょう。
- 置き換えではなく、役割分担を検討する
すべてを置き換える必要はありません。ツールを分割する、例えばMicrosoft 365の内部フローにはPower Automateを、外部API連携にはn8nを使用するなど、すべてを1つのツールで処理するよりもコスト効率が高くなります。Dataverseの代わりに、Power Apps Basicを複数のSharePoint Listsと組み合わせて使用 することも可能です。Power AppsのバックエンドとしてDataverseを使用するのは非常に限定的で、通常はアプリのユーザー数が少ない場合、またはTeamsアプリとして構築する場合に限られます。Dataverseを検討する際には、すべてのユーザーに対してユーザーごとのプレミアムライセンスを支払う場合と、Webシステムをゼロから構築する場合のコストを比較検討することが重要です。
５．まとめ
ローコードの話をするとき、本当に大事なのはツールの機能比較ではなくて、判断の順番です 。
最初に「5年コストでローコードかスクラッチか」を試算します。ローコードで進めると決めたら「Premiumライセンスをどこまで使わずに済ませられるか」を設計します。どうしてもPremiumが必要な場面では、OSSや別ツールとの組み合わせで吸収できないかを考えます 。
PoC段階でローコードから始めることは良い選択だと思います 。ただ、「PoCを抜け出すとき」に一度立ち止まってコストを見直すこと見直すことが重要です。それだけで、後の大きな問題のほとんどは防げます 。
メディアフュージョンのDXシステム
- Microsoft 365を活用して既存業務システムのサーバレス化・コストダウン
MS365活用でサーバ不要・運用コスト削減｜既存業務システムのサーバレス化・コストダウン： Premiumライセンスを最小限にしてサーバレスシステムを構築することを目的としています。 - ローコード・ノーコードツールが持つ課題を解決するツール開発
APPS自動画面生成ツール： ローコードを使っても現場管理者がデータ項目を変更したり、追加したりしたときに開発者に修正してもらわないといけないのが現状です。本ツールは現場の運用管理者がExcel設計書で画面のデータ項目や入力規制の変更を簡単に出来る仕組みです。さらに、このツールは複数のSharePoint Lists 間でのデータ同時配信と、構造化データの保存もサポートしています。
