ある朝、技術リーダーが会議でこう言った。「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コストだ。アプリを作る手間は劇的に下がった。
しかしoperateコストは下がっていない。
認証・権限管理（RBAC）・監査トレイル・承認ワークフロー・バックアップ・ディザスタリカバリ・コンプライアンス対応。これらはアプリを「作る」フェーズではなく「運用する」フェーズに属するコストだ。AIがコードを生成してくれても、これらの実装・維持・更新のコストは変わらない。むしろコードで実装するということは、これらすべてを自前で抱えるということだ。
定量的なTCO比較の公式ベンチマークは存在しないため、数値での比較は避ける。ただし構造として言えることは、マネージドプラットフォームはこれらのoperateコストを最初から「込み」で提供している、ということだ。
7. 「運用負荷を償却するマネージド基層」という考え方
テキスト基層とは別に、もう1つの軸がある。「運用負荷を償却するマネージド基層」だ。
Dataverse のようなマネージドプラットフォームは、データモデル・権限設定・承認フロー・監査ログといった「宣言的なドメイン」を、プラットフォーム側で吸収する。コードではなく設定として管理できる領域だ。
この基層はAI時代に価値が上がる、というのが筆者の見方だ（これも分析モデルであり実証データではない）。なぜなら、AIがbuildコストを下げれば下げるほど、operateコストの比重が相対的に増すからだ。「作ること」が安くなった時代に、「運用すること」を誰が担うかが設計の核心になる。
ワイヤーフレームに成り下がるローコードの正反対にある存在、それがこのマネージド基層だ。
8. テキスト基層に降ろせるか——Power Platformの具体例
「テキスト基層に降ろす」は抽象論ではなく、具体的な操作として存在する。
Power Platform / Dataverseのソリューションは、pac solution unpack コマンドでXML形式に展開できる。PAC CLI 2.4.1以降ではYAML形式のソースコントロールもサポートされており、XMLより可読性が高い。
キャンバスアプリも同様だ。pac canvas unpackを使えば .msapp ファイルをYAMLに展開でき、差分レビューとGit管理が可能になる。
「ローコードはテキスト基層に降りられない」は、少なくともPower Platformにおいては過去の話だ。降ろす意志と設計があれば、ローコードも追跡可能な成果物として管理できる。
テキスト基層への変換方法の実践的な手順については、[「テキスト基層に降ろす」を実機でやる]（公開予定）で詳しく扱う。
9. 設計指針：層で切れ
2つの問いを分けたまま判断する。これが今の技術選定に必要な姿勢だ。
問い1「オーサリング手段」——コードで書くか、GUIで組み立てるか、AIに生成させるか。これはコストと速度の問題だ。エージェントが安くなった今、柔軟に選んでいい。
問い2「成果物の基層」——テキスト基層に降りているか。マネージド基層を担えるか。これは長期の保守性と運用コストの問題だ。ここでは妥協しない。
宣言的なドメイン（データモデル・権限・承認フロー）はマネージド基層に任せる。命令的なロジック（条件分岐・計算・外部API呼び出し）はコードで書く。そして両方をテキスト基層に降ろす。
層で切れ。コードかノーコードかではなく、何が基層に残るかで選ぶ。
「ローコードはワイヤーフレームに成り下がったのか」という問いへの答えは、半分イエス・半分ノーだ。テキスト基層に降りられない層については、イエスに近づいている。だが、運用負荷を償却するマネージド基層については、ノー。むしろ逆——AI時代に最も価値が上がる「基層」として、設計の中心に置くべきだ。
10. 関連リソース
Power Platformの将来性を投資判断の角度から見たい場合は、そのスキルは、5年後も価値が残るのかが補足になる。
野良アプリを防ぎながら市民開発を進める実践的な進め方は、社内の申請業務を「失敗しないように」デジタル化するで扱っている。
テキスト基層への変換を実機で試したい場合の手順は、「テキスト基層に降ろす」を実機でやる（公開予定）を参照。