「生成AIがここまで進化したのであれば、ローコードは要らないのではないか」
IT部門でDXを進めている方なら、一度は考えたことがあるのではないでしょうか。生成AIは自然言語で開発をこなすだけでなく、業務そのものを実行する「AIエージェント」という形でも定着しつつあるからです。
結論から言えば、ローコードは必要です。後述しますが、特にエンタープライズ企業のDXにとっては欠かせない存在です。ローコードはコードの手書きを最小限に抑え、GUI中心にアプリを開発する手法です。しかし今はそれだけでなく、企画からコーディング、アプリ実装後の運用・メンテナンスまでを1つの基盤で支えるものが登場しています。こうした「ローコードプラットフォーム技術」は、エンタープライズ企業では速さに加えて統制（ガバナンス）を効かせられる点が特徴です。
そのうえで問うべきは、生成AIとローコードのどちらを取るかではなく、どう使い分けるかです。生成AIは業務を実行する役、ローコードはその生成AIを組み込んだ業務アプリをつくり、統制を維持しつつ既存システムとつなげる役。エンタープライズの現場では、両者は競合ではなく、分業の関係といえます。
先端技術の商社であるマクニカは、この分業を自社の見積業務の改革で実践しました。マクニカがどんな業務効率化を行い、そして生成AIの時代になぜローコードを選んだのかをご紹介します。
なお、本記事は、マクニカ・イノベーション戦略事業本部 刀禰の講演をもとに再構成したものです。
AIエージェントで見積業務はここまで変わった
マクニカのある事業部門では、見積業務が悩みの種でした。顧客から届く見積のExcelは、必要な項目もフォーマットもばらばらです。受け取った営業やオペレーターが、その中身を人力でシステムへ打ち直していました。当然、漏れが出ます。業務によっては、見積のデータが社内に残らないことさえありました。
この課題を持ち込んだのは、事業部門のマネージャーでした。持ち込み先は、マクニカ全社のDX案件を束ねる社内組織「CoE（Center of Excellence）」。マクニカのCoEには1年で70超のアイデアが集まり、すでに9つの業務改善システムと2つの新サービスがリリースされています。この見積業務の課題も、その1つでした。
なお、このCoE組織作りの詳細は、次の記事で詳しく解説しています。
当時このマネージャーに、生成AIの最先端の知識はありませんでした。そこでCoEのメンバーが、「いまAIで何ができるのか」を伝えるところからこのプロジェクトがスタート。その後も、マネージャーとCoEはコミュニケーションを重ね、「人が判断していた部分をAIエージェントに任せる」という方向性で進めることが決まりました。
実装では、3体のエージェントが仕事を分け合います。
1体目は、ばらばらなフォーマットのExcelから情報を抜き出す係。人の感覚に頼っていた作業の肩代わりです。
2体目は、社内システムへ自動で転記する係。顧客ごとに異なるルールは、プロンプトの調整で吸収します。
3体目は、答え合わせの係です。エージェントの回答のどこが合っていて、どこをなぜ間違えたのかを見極めます。
AIエージェントに完全に業務を丸投げするというのは、今の段階では難しいです。そこで、精度100%は出ない前提で、3体目がつけた答え合わせの結果を頼りに、人が最後のひと目で確定させる。いわゆるHuman in the Loop（AIの処理に人の確認を組み込む形）で設計しました。このひと工程が、単価や品名の登録ミスを防ぎます。
この仕組みで作業時間が大幅に減りました。それだけでなく、Excelを延々と見比べ続けるストレスからの解放も大きな効果でした。
もともと起案の時点では、事業部門に「エージェントを使おう」という発想はありませんでした。業務に詳しい事業部門側と、技術に詳しいCoE側とが議論を重ねるなかで、このTo-Be（あるべき業務の姿）が生まれたのです。
生成AIとローコードをどう使い分けたか：スクラッチ・コード生成AIとの分岐点
イメージの共有が難しいものを、起案から5日で形にできる
では、このTo-Beをどうやって形にしたのでしょうか。答えは、イメージがつくものを素早くつくり、事業部門とCoEでイメージをすり合わせながら進めることでした。
今回のケースではマクニカは、開発者1名・案件の起案から5日間で、見積業務のAIエージェントをモックアップレベルまで形にしました。素早く形にならないと、忙しい事業部門側で本件の優先順位がどんどん下がります。DXへの期待値も上がりません。速さにこだわるのは、そのためです。
すり合わせにこだわったのにも、理由があります。
事業部門にとってAIエージェントは馴染みが薄く、業務でどう使うかのイメージがわきません。さらに、事業部門側のやりたいことは抽象度が高い場合もあり、そのままでは齟齬なく要件に落とし込むことが難しい。それだけでなく、作っても現場で利用されないケースもあります。この事態を防ぐには、触れるものを前にイメージをすり合わせながら、アジャイルで開発することが重要でした。
マクニカのCoEでは、Power PlatformやUiPathなど複数のツールを、案件の性質に応じて使い分けています。そのなかで今回の案件に選ばれたのが、「イメージの共有」と「形になるまでの速さ」に強みを持つローコード開発基盤「Mendix」でした。なお、前半で見た3体のAIエージェントは、Mendixでつくった業務アプリに組み込まれて動いています。
選択肢の中から、マクニカは2つの軸で選定
市場に目を移すと、ローコードは依然として成長を続けており、次の論点はAIとの組み合わせに移りつつあります。
Mendixもその流れの中にいます。MendixはIT部門とビジネス部門が共通の基盤上で協業し、エンタープライズ水準の中核システムを構築できるローコード開発プラットフォームで、近年はデータ分析・AIプラットフォームと連携するなど、「ローコード × Agentic AI」のAI統合基盤へ進化しています。
では、当時のマクニカはどう選んだのでしょうか。Mendixのほかにあった選択肢は、スクラッチ開発、Power Platform、そして話題のコード生成AI（Claude Codeなど）です。コード生成AIに担わせるのは、業務ではなくシステム開発そのものです。
マクニカが判断の軸に置いたのは2つ。まずは先にもご紹介した「イメージを共有しながら素早く形にできるか」です。加えて重視したのが「エンタープライズの拡張性と統制を満たせるか」です。拡張性とは、基幹システムなど既存の社内システムとつなげて広げられること。統制とは、全社のセキュリティ基準や運用ルールのもとで開発・運用を管理できることです。この軸で見ると、いま挙げた選択肢は、現時点でどれも難しいのではないか。それがマクニカの見立てでした。
スクラッチは、画面を見ながらのレビューがすぐにはできません（イメージの共有と速さの壁）。Power Platformは、そもそも今回のようにMicrosoft 365系以外のシステムとつなぐ用途では制約があります（拡張性の壁）。コード生成AIも、今ではたくさんのことができます。ただし、コード生成AIが受け持つのは、アプリづくりのうちコーディングの部分です。エンタープライズのアプリには、開発・テスト・本番といった環境の分離、実行環境の運用、利用者のアクセス制御など、コーディングの外側の仕組みが欠かせません。ここはコード生成AIの守備範囲の外にあり、すべて自社で構築・運用することになります（統制の壁）。
Mendixで基幹システムとも連携するアプリを内製
2つ目の軸のうち、まず「拡張性」ですが、マクニカではMendixで基幹システムと連携したアプリを開発した実例があります。
マクニカのIT部門は、IT予算の管理に使っていた、サブスクリプション費用が高額だったSaaSを、Mendixで内製したアプリに置き換えました。SAPとの連携が必要な領域です。それでも1つのプロダクトとしてリリースし、いまも運用が続いています。
ローコードでつくれるのは、簡単なアプリまでではない。基幹と連携する本格的な領域まで担うことができる。これがMendixの「拡張性」の強さです。
| 選択肢 | 軸1：イメージ共有と速さ | 軸2：拡張性・統制 | マクニカの見立て |
|---|---|---|---|
| スクラッチ開発 | ×（画面を見ながらのレビューがすぐできない） | − | イメージ共有と速さの壁 |
| Power Platform | ○ | ×（Microsoft 365系以外との接続に制約） | 拡張性の壁 |
| コード生成AI （Claude Code等） |
− | ×（全社ガバナンス・セキュリティ担保は体制面含めハードル） | 統制の壁 |
| Mendix | ○ | ○ | 採用 |
ただし、ツールの選定は「5分の1」でしかない
先の2つの事例は成功しましたが、マクニカにも、うまくいかなかった時期があります。
かつては各部門が、ばらばらのツールを活用したり、独自のプロセスでの開発を進めたりしていました。いわゆる「野良プロジェクト」の状態です。この状態では、会社全体の力を生かしたスピーディーな変革はできていませんでした。
この状態を抜け出すためにマクニカが推進のキーに据えたのが、Mendixの親会社であるシーメンス由来の「5P」という考え方です。5Pとは、欧米での膨大なDXの実践知をベストプラクティスにまとめ、Platform、People、Portfolio、Process、Promotionの5つに体系化したものです。
「ツールは、DX変革のごく一部である」。つまり、Platform（ツール）は5つのPの1つにすぎず、People、Portfolio、Process、Promotionがそろってはじめて変革が進む、という発想です。
マクニカは、この考えを仕組みに落とし込んでいます。CoE組織もここから生まれました。
*上図の「Digital Execution Factory」はCoE組織構築支援を含めた、継続したDXを生み出すための製造業向けDX支援サービスです。
CoEは、全社のDXや新規事業のアイデアを受ける窓口です。先の見積業務のような業務改善や新サービスといった、アウトカムを出す役割を担います。そのために、開発環境と企画開発プロセスを整備しています。推奨ツールを選定し、会社のデザイン基準に沿ったテンプレートやセキュリティモジュールを全プロジェクトに配る。先ほどの2つ目の軸に含まれる「統制」は、プラットフォームが備えるセキュリティや環境管理の機能と、それを全社で運用するこの体制の、両輪です。この体制づくりのノウハウを、Mendix側も持っています。これが非常に強力でした。
加えて、DX人財の育成支援や、プロジェクトのプロモーションも実施します。そして、全プロジェクトを通して得たノウハウを一箇所に集め、次のプロジェクトに活かす。
つまり、ツールだけでなく、5Pすべてを活かした体制を構築する。これが、先の事例を生み出せた要因です。
なお、DX推進者のタイプごとに不足しがちなPが存在し、それがDX推進の壁になることが多いです。詳しくはこちらの記事でご紹介しています。
生成AIの時代に、なぜローコードか
マクニカ自身、かつては外部のパートナー企業にシステム開発を依頼していました。しかし、生成AIの登場をはじめ、これだけビジネスの変化が激しい時代には、このやり方が通用しなくなってきました。
時代の変化に合わせるには、事業部門の頭にある抽象度の高い業務をIT部門が素早く可視化し、すり合わせながらプロセスを具体化していく。見積業務の事例でご紹介した、あの進め方が必要です。
ここで重要な役割を担うのが、ローコードです。事業部門とIT部門が認識を揃えながらスピーディに形にできる、そしてエンタープライズの拡張性と統制を満たせる。この2つの軸で選んだマクニカの答えが、Mendixでした。
コード生成AIは今後も進化し、できることも増えていきます。一方のローコードも、生成AIを取り込みながら進化していきます。
生成AI時代でも、ローコードは必要。むしろ生成AI時代だからこそ、業務を実行するAIを素早く形にし、統制を効かせながら現場に届け、既存システムと問題なく連携させることが重要です。それが、「なぜローコードなのか」という冒頭の問いへの、マクニカが実践から得た答えです。
さらに、マクニカ社内にこれだけの事例が生まれたのは、Mendixだけでなく5Pのノウハウや実行できる組織体制があってのことです。
全社規模で継続的にDXを推進しようとすると、仮に非常に優秀なAIが生まれたとしても、それだけでは壁にぶつかります。どれほど優れたAIも、5PでいえばPlatform（ツール）の1つにすぎないからです。ツールの導入は始まりで、むしろ重要なことは残りの5分の4にあります。
そしてMendixには、この5Pのノウハウがあります。
マクニカは自社の実践や多くのクライアントを支援してきた経験を通して、そのベストプラクティスに沿えば再現性高くDX推進ができることを実感しています。開発効率の向上はもちろん、その先の「継続する」DXまで見据えると、Mendixという選択はマクニカにとって非常に良いものでした。