技術記事

micomia株式会社の畑井です。
以前、FlutterFlowでできること100選 という記事で、FlutterFlow で作れるものを幅広く紹介しました。
当社は FlutterFlow を使った開発を数多く手がけており、得意な範囲では非常に強力なツールだと考えています。
一方で、開発を依頼する立場からすると、むしろ知りたいのは「何ができないのか」「どこでつまずくのか」ではないでしょうか?

この記事では、当社が実際の開発でぶつかった『FlutterFlowでできない・苦手なこと』を、機能面・安定性の両面からお伝えし、ノーコード開発とはどのようなものなのか助けになればと思います。

「できない」の多くは「標準ではできない／フルコードなら可能」

最初に整理しておくと、これから挙げる項目は「FlutterFlowでは絶対に不可能」という意味ではありません。
FlutterFlowはローコードでもあるため、コードを書き足したり、サーバー側の処理を追加したりすれば実現できるものも多くあります。
ただしそれは「ノーコードのまま、簡単に」とはいかず、エンジニアによる実装が必要になります。つまり“ノーコードの手軽さ”という最大のメリットが薄れる、ということです。
この前提を踏まえて、まずは機能面の「できない・苦手」を見ていきます。

機能面でできない・苦手な6つのこと

実際の開発現場でぶつかりやすい順に、決済・機能・セキュリティ・デザインの観点から整理します。

① Stripeでのサブスクリプション（継続課金）に標準対応していない

FlutterFlowにはStripe決済の連携機能がありますが、現状、Stripeを使ったサブスクリプション（継続課金）には標準で対応していません。
都度の支払いはできても、「月額・年額で自動的に課金し続ける」仕組みは、そのままでは作れないということです。
Webでのサブスクを実装したい場合は、Stripe側の処理をコードやサーバー（Cloud Functionsなど）で組む必要があり、ノーコードだけでは完結しません。

② モバイルのアプリ内課金は RevenueCat 依存で、単発購入ができない

iOS／Androidアプリ内の課金は、FlutterFlowではRevenueCatとの連携で実装するのが基本です。
しかしこの連携で対応できるのは、サブスクリプションと買い切り（ライフタイム）購入が中心で、消費型の単発購入（その都度購入して使い切るタイプ）には対応していません。
「ポイントを都度購入する」「アイテムを1回ずつ買う」といった課金モデルを考えている場合は、標準機能だけでは実現できない点に注意が必要です。

③ PDF・Excelなどの帳票生成（コードを書けば可、ノーコードでは不可）

請求書や帳票のPDF生成、Excelファイルの出力といった機能は、ノーコードの標準機能だけでは作れません。
コードを書く（外部ライブラリやサーバー側処理を使う）ことで実現は可能ですが、これも「ノーコードで手軽に」とはいかない領域です。
業務システムやBtoB向けアプリでは帳票出力の要件が頻出するため、検討初期に「これはコード開発が必要」と見込んでおくと、見積もりのズレを防げます。

④ APIキーがハードコードされ、セキュリティ的に不安が残る

外部サービスと連携する際、FlutterFlowではAPIキーがアプリ側に埋め込まれる（ハードコードされる）形になりやすく、セキュリティ的に望ましくありません。
クライアントに埋め込まれた鍵は、技術的には抜き取られる可能性があり、悪用されると不正利用や情報漏えいにつながります。
機密性の高い鍵を扱う処理は、本来サーバー側に逃がすべきです。これを徹底しようとすると、結局サーバー（Cloud Functionsなど）の実装が必要になります。

⑤ 本格的なセキュリティ対策をすると、実装が一気に重くなる

小規模なアプリなら問題になりにくいのですが、DoS攻撃対策をはじめとした本格的なセキュリティ対策まで踏み込むと、実装の負担が大きく増します。
レート制限、不正アクセス検知、堅牢な認証・認可など、守りを固めるほどサーバー側の作り込みが増え、ノーコードの手軽さからは離れていきます。
「とりあえず動くもの」と「攻撃に耐えられる本番品質」のあいだには大きな差があり、後者を求めるほどフルコード開発の比重が高まります。

⑥ デザインの自由度が低い

FlutterFlowは用意された部品を組み合わせて作るため、細かなUIの作り込みや独自性の高い表現には限界があります。
ピクセル単位の繊細な調整、複雑なアニメーション、独自のインタラクションなどを突き詰めたい場合、ツールの枠が制約になります。
「ブランドの世界観をデザインで徹底的に表現したい」といったこだわりが強いプロダクトでは、フルコード（Flutterなど）のほうが理想に近づけます。

見落とされがちな壁：FlutterFlow特有のバグと、大規模開発の難しさ

機能の話とは別に、当社が実感しているもう一つの大きな壁が「ツール自体の安定性」と「規模の限界」です。

あまりインターネット上に情報として出ておらず、FlutterFlowを主力技術として利用してきた当社だから認知しているものもあります。

FlutterFlow特有の不可解なバグ

FlutterFlowでは、コード開発では起きないような“ツール特有のバグ”に遭遇することがあります。
たとえば、何度ビルドし直しても意図しない位置にボタンが表示されてしまう、といった不可解な挙動です。
原因がコードではなくツール側にあるため、解決の糸口がつかみにくく、原因究明に時間を取られることがあります。

画面が複雑になると、開発画面そのものが重くなる

1つの画面に情報やwidget（部品）が増えてくると、FlutterFlowの開発画面（エディタ）自体が重くなり、固まってしまうことがあります。
作り込むほどエディタの動作が不安定になるため、リッチで複雑な画面ほど開発効率が落ちる、というジレンマが生じます。

正直なところ、大規模開発はかなり難しい

これらが積み重なると、大規模なアプリをFlutterFlowだけで作り切るのは、正直なところかなり難しいというのが当社の実感です。
経験上、フリマアプリ程度の規模が一つの目安（実質的な上限）でした。
実際、フリマアプリとクラウドソーシングを組み合わせたような複合的なアプリでは、「FlutterFlowで作る」という前提を優先するために、本来やりたかった実装要件の一部を落とさざるを得ないケースも出てきました。

これは“ツールに合わせて要件を妥協する”状態であり、プロダクトの価値を考えると本末転倒になりかねません。

規模や複雑さが見込まれるなら、早い段階でフルコード開発を検討する価値があります。

できないことにぶつかったら、どうするか

ここまでの6つに当てはまる要件がある場合、取れる選択肢は大きく3つです。

1つめは、要件を見直してFlutterFlowの得意な範囲に収めること。MVPや初期検証なら、これで十分なケースも多くあります。
2つめは、ローコードとして必要な部分だけコードやサーバー処理を足すこと。ただし足しすぎると、技術が散らばって保守が重くなる点に注意が必要です。
3つめは、最初からフルコード（AIを活用したFlutter開発）で作ること。複雑な決済・セキュリティ・デザイン要件が中心なら、結果的にこちらが速く・安くなることもあります。

詳しくは ノーコードの限界をAI駆動開発で突破する で、自社事例を交えて解説しています。
重要なのは、要件ごとに「これはFlutterFlowの得意分野か？」を見極め、ツールを正しく使い分けることだと思います。

まとめ

FlutterFlowは、得意な範囲ではスピードもコストも圧倒的に有利なツールです。
一方で、Stripeのサブスク、消費型の単発課金、帳票生成、APIキーの安全な管理、本格的なセキュリティ対策、デザインの作り込み——こうした領域は標準では難しく、フルコードでの実装が必要になります。
さらに、ツール特有のバグや、大規模・複雑なアプリでの開発効率の低下も、見落とされがちな現実的な壁です。
「できること」と「できないこと」の両方を知ったうえで選べば、ノーコードは強力な武器になります。

micomiaでは、FlutterFlowを使ったスピード重視の開発から、フルコードでの本格開発まで、要件に合わせて最適な作り方をご提案しています。
「自分のアプリはFlutterFlowで作れるのか、それともフルコードにすべきか」を相談したい方は、まず料金シミュレーションで規模感を把握したうえで、お気軽にご相談ください。