技術記事

ローコード開発をビジネスで本格的に導入しようとすると、ほぼ必ず経営層や情報システム部門から問われるのが「セキュリティは大丈夫なのか？」という問いです。

スピードと低コストが魅力のローコード開発ですが、コードを書く量が少ない＝セキュリティリスクも自動的に低くなる、というわけではありません。むしろ、設定の自由度がプラットフォーム任せになる分、「何を自社で守らなければならないのか」が見えにくく、リスクが潜在化しやすい側面もあります。

本記事では、micomia 株式会社が FlutterFlow と Firebase を用いた多数のローコード開発を手がけてきた実務経験をもとに、ローコード開発でとくに発生しやすいセキュリティリスクと、安全に運用するための具体的な対策を整理してお伝えします。

1. ローコード開発のセキュリティの基本構造

ローコード開発で扱うセキュリティは、大きく次の2層に分かれます。

1つめは、プラットフォーム側が担保する層です。

FlutterFlow や Firebase のような主要プラットフォームは、通信の暗号化（TLS）、サーバー基盤の物理セキュリティ、ID・パスワードの基本的な暗号化保管など、一般的なセキュリティ要件をデフォルトで担保しています。ここは開発者が自前で実装する必要はありません。

2つめは、開発者・運用者が自社で設計する層です。

具体的には、データベースのアクセスルール、API キーの公開範囲、認証・認可の実装、入力検証、運用時のログ・監視などです。この層は「ローコードだから自動的に安全」とはならず、 適切に設計しないと重大な情報漏えいにつながる領域です。

ローコード開発で起こる事故のほとんどは、この2層目の設計不備によるものです。

逆に言えば、ここを正しく設計できれば、ローコード開発でも業務基幹システムやコンシューマー向けアプリに耐えるセキュリティを実現できます。

2. ローコード開発で発生しやすい7つのセキュリティリスク

実際の開発現場で頻出する代表的なリスクを整理します。自社のプロジェクトを見直すチェックリストとしてもご活用ください。

① データベースのアクセスルール不備

Firestore や Realtime Database を利用する際、初期設定のままだと「誰でも読み書きできる」状態になっているケースがあります。

テスト段階のルールを本番にそのまま持ち込み、全ユーザーの個人情報や決済データが第三者からも読み取れる、という事故は世界中で繰り返し起きています。

② API キー・認証情報の漏えい

クライアント側に埋め込まれた API キーや Firebase 設定情報は、ビルド成果物の解析やネットワーク監視で容易に取り出せます。

これ自体は通常想定の運用ですが、API キーに「使用できるドメイン」や「呼び出せる API 種別」の制限を設定していないと、第三者に無制限に呼び出され、課金や情報取得に悪用される可能性があります。

③ 認証・認可の実装ミス

「ログインしているユーザーかどうか」しかチェックしておらず、「ログインしているユーザーが、その情報を見る権限を持っているか」まで判定できていないケースは非常に多く見られます。

たとえば、自分の URL の ID を書き換えると他人の請求書が表示される、といった脆弱性につながります。

④ 入力検証の不足（XSS・インジェクション）

ローコードツールが自動で生成する入力フォームでも、HTML を埋め込めるフィールドや、外部 API への問い合わせに利用される値については、入力検証とエスケープを開発者側で意識する必要があります。検証が抜けると、ユーザーが投稿した内容が他ユーザーの画面で実行されたり、外部システムへの不正な命令につながる恐れがあります。

⑤ 第三者ライブラリ・カスタムコードの脆弱性

ローコードでも、Custom Function や Custom Action として一部のコードや外部ライブラリを組み込むのが一般的です。

組み込んだライブラリに既知の脆弱性があると、ローコード基盤自体が安全でも、アプリ全体としては危険にさらされます。

⑥ クラウドサービス側の設定不備

Firebase Storage の公開設定、Cloud Functions の認証設定、メール送信サービスの送信制限など、クラウド側の設定値が一つでも甘いと、それが攻撃の入口になり得ます。

複数のクラウドサービスをまたいで利用するローコードアプリでは、設定の抜け漏れが起きやすい点に注意が必要です。

⑦ ログ・監視体制の欠如

事故が起きた際に「いつ・どこから・何が起きたか」を追跡できなければ、影響範囲の特定もできず、再発防止策も打てません。

ローコード開発はスピード優先で進みがちですが、本番運用に入る段階ではアクセスログ・操作ログ・異常検知の仕組みが必須です。

3. 安全に運用するための具体策

ここからは、micomia が FlutterFlow + Firebase 構成で実際に採用している、再現性のある対策を紹介します。

3-1. Firestore / Storage のセキュリティルールを必ず本番用に書き換える

Firestore や Storage のセキュリティルールは、もっとも事故が起きやすく、もっとも効果の大きい防衛ラインです。

「認証済みユーザーだけが書き込める」「自分が所有するドキュメントだけ読める」といった条件を、コレクション単位で明確に書き分けます。

テスト用の allow read, write: if true; を本番に残さない、という当たり前の運用を仕組み化することが第一歩です。

3-2. API キーにドメイン・IP 制限と Make Private を設定する

Google Cloud Console から API キーごとに「呼び出し元のドメイン」「呼び出せる API 種別」を絞り込みます。

FlutterFlow では、API キーに対して「Make Private」の設定を有効化することで、クライアント側にキーを露出させずに API を呼び出す経路も用意されています。

これらを組み合わせることで、たとえキーが取得されても悪用範囲を大きく狭められます。

3-3. 認証・認可の二重チェック

UI 側の表示制御だけに頼らず、Firestore セキュリティルールやサーバー側関数（Cloud Functions）でも「このユーザーがこの操作を行ってよいか」を必ず再確認します。

クライアント側のチェックは利便性のため、サーバー・データベース側のチェックは安全性のため、と役割を分けて二重化することが、事故防止の基本です。

3-4. HTTPS の徹底と、機密データの最小化

外部 API との通信はすべて HTTPS に統一し、平文通信が混在しないようにします。

あわせて、そもそも「クライアントに渡す必要があるか」を一つひとつ見直し、不要な機密データはサーバー側で完結させることで、漏えい時の影響を最小化します。

3-5. ログ・異常検知の仕組み化

Cloud Logging で操作履歴を蓄積し、想定外のアクセス（短時間に大量の読み取り、深夜の管理操作など）を検知するアラートを設定します。

本番リリース後の早い段階で、最低限のログ・監視を一通り組み込んでおくと、運用後の安心感が大きく変わります。

4. ローコード導入時に確認したいセキュリティチェック5項目

ローコードの導入を検討する段階で、最低限社内で確認しておきたい項目をまとめます。

① 利用するプラットフォームの第三者監査・準拠規格：SOC2 / ISO 27001 / 業界別ガイドライン等への対応がどう整理されているかを確認します。

② データの保存場所と所有権：自社データがどのリージョンに保存され、エクスポート・削除がどの程度の柔軟性で可能か。

③ アクセス制御の粒度：行・列レベルのアクセス制御や、役割（ロール）ベースの制御がどこまで実装できるか。

④ 監査ログとアラート：誰が・いつ・どのデータに触れたかを追跡できる仕組みが用意されているか。

⑤ 退役・引き継ぎ時の安全性：開発を別社に引き継ぐ場合、コードや設定を持ち出せるか、データを完全に削除できるか。

これらは、ローコードであってもフルスクラッチであっても問われる観点ですが、ローコード採用時はとくに「プラットフォームに何を委ね、自社が何を担うか」を整理する起点として有用です。

5. 【実コード解析】FlutterFlow エクスポートコードから見える設計の実態

本記事の内容を裏付けるため、micomia で実際に FlutterFlow からエクスポートしたサンプルプロジェクト（SNS 型アプリのテンプレート）のソースコードを精査しました。

ここから、ローコード開発のセキュリティ設計でとくに見逃されがちな3つの構造が浮かび上がります。

5-1. Firebase の API キーは生成された Dart コードに直接書き込まれる

FlutterFlow からエクスポートしたコードを開くと、lib/backend/firebase/firebase_config.dart に Firebase プロジェクトの API キー・プロジェクト ID・アプリ ID・送信者 ID などが Dart コードとしてそのまま埋め込まれています。Web ビルドではこれらの値はそのまま JavaScript バンドルに含まれ、ブラウザの開発者ツールから誰でも確認できる状態になります。

Firebase の API キーは「秘密鍵」ではなく「公開しても良いプロジェクト識別子」として設計されているため、それ自体に直接的な漏えいリスクはありません。

ただし、API キーに対して Google Cloud Console 側で「呼び出し元ドメインの制限」や「呼び出せる API 種別の制限」を一切設定しないまま運用すると、第三者から無制限に API を呼び出され、課金や情報取得に利用される可能性があります。

「エクスポートしたら自動的に安全」ではなく、API キーごとの制限設定をクラウド側で必ず行うことが前提です。

5-2. 画面コードは手続き型で容易に 500 行を超える

FlutterFlow が生成する画面の Dart ファイルは、UI 構築・状態管理・データ取得・画面遷移が StatefulWidget の中に手続き型で詰め込まれる構造になりやすい傾向があります。

解析したサンプルでは、メイン画面の home_widget.dart 1ファイルだけで 561 行 に達していました。

これは機能数が増えるほど顕著になり、認証チェックや権限制御の処理が画面コードの中に分散すると、「あるはずの検証が実は抜けていた」「同じチェックが複数箇所に異なる書き方で散在し、片方だけ修正漏れがあった」といったセキュリティバグの温床になります。

重要な検証ロジックは、画面コードからユーティリティ層やサーバー側関数に切り出して再利用する設計を、エクスポート後のリファクタリングとして組み込むことをおすすめします。

これらは「FlutterFlow からエクスポートした状態の出発点」を示すものであり、本番運用ではエクスポート後にどれだけ整えられるかが品質を決めます。

プラットフォームが安全を担保している領域と、開発者が自分で書き換えなければならない領域を切り分け、後者を確実に詰めていく姿勢が、ローコード開発のセキュリティ運用の核心です。

6. micomia のローコード開発における安全設計の考え方

micomia 株式会社では、FlutterFlow と Firebase を中心としたローコード開発において、すべてのプロジェクトで以下を必須の前提として設計しています。

Firestore セキュリティルールはユニットテストレベルで検証可能な形で書き、テスト用ルールが本番に残らない運用を徹底します。API キーは Google Cloud Console での制限と FlutterFlow 側の Make Private の両方を活用します。

認証・認可は UI、サーバー、データベースの三段階で二重・三重にチェックします。本番リリース時には、必ずログ収集と異常検知の最低構成を組み込みます。

ローコード開発はスピードと品質のバランスが取りやすい開発手法ですが、その魅力を引き出すには「セキュリティを後付けにしない」設計が欠かせません。

micomia では、設計の初期段階からセキュリティ要件を一緒に整理しながら開発を進めるご支援を行っています。

まとめ

ローコード開発は、プラットフォーム側が基礎的なセキュリティを担保してくれている一方で、「アクセスルール」「認証・認可」「API キーの管理」「ログ・監視」など、開発者・運用者が自社で設計すべき領域が明確に存在します。

これらを後回しにしてしまうと、せっかくのスピードが事故対応で帳消しになりかねません。

ローコードを安全に運用するための鍵は、特別な高度技術ではなく、地味な設定と運用ルールを一つひとつ抜けなく実装することにあります。本記事でご紹介した観点を、社内のプロジェクトチェックリストとして活用していただければ幸いです。

「自社のローコード開発でセキュリティが心配」「これから FlutterFlow や Firebase を使った開発を始めたい」とお考えの方は、設計段階のご相談からお気軽にお問い合わせください。