「ノーコードで作れたから安心」は危険──広がるセキュリティの死角
Power AppsでSharePointのデータを表示する社内ポータルを作った、BubbleでCRMを自作した、MakeのシナリオでGmailと社内DBを自動連携した──。2025〜2026年にかけて、コードを書かずに業務システムが作れるノーコード・ローコードツールの普及が一段と加速しています。さらにCopilotやGPT-4oなどのAI機能がこれらのツールに組み込まれ、「自然言語でアプリを生成する」ことすら当たり前になりました。
しかし、この利便性の裏で深刻な問題が静かに広がっています。それがセキュリティの後回しです。
従来のシステム開発では、要件定義→設計→開発→セキュリティレビュー→テスト→本番、という工程を経るのが一般的でした。ところがノーコードツールは「試しに作って、使えそうならそのまま本番」という流れになりがちです。IT部門が関与しないまま業務部門が構築したシステムが、個人情報や顧客データを含む重要な業務基盤になっているケースも珍しくありません。
本記事では、ノーコード・ローコード+AIシステムに特有のセキュリティリスクを具体的なツール名・設定項目名を交えて解説し、自社でできるチェックリストと専門家診断が必要なケースをまとめます。
ノーコード・ローコードシステムに特有の5大セキュリティリスク
リスク① アクセス制御の設定ミス
ノーコードツールで最も多く報告されているのがアクセス制御(誰が何を見られるか)の設定漏れです。
Power Appsを例に挙げると、SharePointリストに接続するアプリを作る際、データソース側の行レベルセキュリティ(RLS)を設定していないと、アプリのUI上では表示を絞っていても、APIを直接叩くと全レコードが取得できてしまいます。「アプリが非表示にしているから見えない」は誤りで、データソース側で制御しなければ意味がありません。
Bubbleでも同様の問題が頻発します。Bubbleのデータ権限設定(Privacy Rules)を未設定のまま放置すると、/api/1.1/obj/[データタイプ] というAPIエンドポイントに対して外部から全データが取得できる状態になります。これは「Bubble Privacy Ruleの設定漏れ」として2022年ごろからセキュリティ研究者が繰り返し指摘している典型的な問題です。
リスク② 過剰なデータアクセス権限
「とりあえず全員に共有すれば動く」という手軽さから、全社員が全レコードを参照できる状態で運用されているシステムが散見されます。
たとえば以下のようなケースです。
- 人事評価データが入ったSpreadsheetをGlideアプリのデータソースにし、社員全員にアプリ共有リンクを送った
- AppSheetで在庫管理アプリを作り、ロールを分けずに全ユーザーが全拠点のデータを編集できる状態にした
- Power Appsのコネクターに管理者権限のサービスアカウントを使い回している
最小権限の原則(Principle of Least Privilege)はノーコードツールでも適用しなければなりません。
リスク③ APIキー・Webhookシークレットの平文保存
ノーコードツールではさまざまな外部サービスとAPI連携するのが当たり前ですが、APIキーやWebhookシークレットの管理が甘いケースが多く見られます。
具体的には:
- MakeやZapierのシナリオ内にAPIキーをテキストフィールドで直接入力している
- BubbleのWorkflow内で使用するHTTPリクエストにAPIキーをハードコードしている
- Power Automateのフローの「コンポーズ」アクションや変数に秘密情報を平文で格納している
- GitHubやNotionにノーコードアプリの設定ファイルを保存し、そこにAPIキーが含まれている
APIキーが漏洩すると、外部サービス(SendGrid・Stripe・Twilio・Slack等)を不正利用され、多額の費用請求や情報漏洩につながります。適切なシークレット管理機能(Power AutomateのAzure Key Vault統合、BubbleのEnvironment Variables等)を使うことが必須です。
リスク④ ワークフローを通じた機密データの外部流出
MakeやZapierは複数のサービスを「シナリオ」や「Zap」でつなぎ、データを自動転送する仕組みです。この自動化ワークフローが機密データを意図しない外部サービスに送り続けているリスクがあります。
たとえば:
- 顧客の個人情報(氏名・メールアドレス・電話番号)が入ったスプレッドシートのデータを、Slackチャンネルに自動投稿するワークフローが動いている
- CRMの商談データをGoogle Sheetsに転送するフローが、パブリック共有設定のシートに書き込んでいる
- Make内で処理した従業員の給与データが、エラーログとして外部のログ収集サービスに送信されている
「どのデータがどこに流れているか」を可視化するデータフロー図の作成と定期的な棚卸しが、コンプライアンス上も重要です。
リスク⑤ 退職者・異動者のアカウント放置
ノーコードアプリは「作った人がいなくなってもそのまま動き続ける」のが便利な点でもありますが、退職者や異動者のアカウントが削除されずに残っていることで深刻なリスクが生まれます。
特に問題になるのが以下の状況です:
- Bubbleやビルダー側の管理者権限アカウントを持つ担当者が退職後もアクセス可能な状態
- Make・Zapierのオーナーが退職者のメールアドレスのまま、引き継ぎなし
- Power Apps/Power Automateのアプリ・フローのオーナーが退職者になっており、ライセンスの棚卸しもできていない
- AppSheetやGlideのアプリ共有先リストに元社員・元パートナーが残っている
内部不正や情報持ち出しのリスクだけでなく、ビジネスメール侵害(BEC)攻撃で元社員のメールアカウントが乗っ取られた場合に、そのままノーコードシステムへの侵入経路になります。
ツール別 代表的なリスクと確認ポイント
Power Apps / Power Automate
確認ポイント | リスク内容 |
|---|---|
SharePointリスト・Dataverseの行レベルセキュリティ(RLS)設定 | UI非表示でもAPI経由で全データ取得可能 |
環境(Environment)の分離 | 開発・テスト・本番が同一環境で混在している |
コネクターのサービスアカウント権限 | 管理者権限の共用アカウントを使い回している |
Power Automateフローの共有設定 | 「組織全体に共有」になっているフローが機密データを処理 |
Azure Key Vaultの利用有無 | APIキー・パスワードが変数にハードコードされている |
DLP(データ損失防止)ポリシー | ビジネスデータとコンシューマーサービスの混在接続 |
重点チェック: Power AppsはMicrosoft 365のライセンスで手軽に使い始められるため、IT部門未承認の「シャドーIT」として増殖しているケースが多い。まずM365管理センターで稼働中のアプリ・フロー数を把握することから始める。
Bubble
確認ポイント | リスク内容 |
|---|---|
Privacy Rulesの設定(全データタイプ) | 未設定の場合、外部APIから全レコードが取得可能 |
APIワークフローの認証設定 | Publicに設定されたAPIが無認証で実行可能 |
ユーザーロールと権限設計 | ロール未設定で全ユーザーが全データを編集可能 |
環境変数(Environment Variables)の利用 | APIキーがワークフロー内に直書きされている |
ファイルアップロードの制限 | 任意のファイルタイプがアップロード可能(マルウェア等) |
プラグインのメンテナンス状態 | 更新が止まった脆弱なサードパーティプラグインの使用 |
重点チェック: BubbleはSQLインジェクション相当のリスクがワークフロー設計の誤りから生まれることがある。「Search for」アクションでユーザー入力を直接フィルター条件に使う場合、想定外のデータが参照される可能性がある。
Make(旧Integromat)/ Zapier
確認ポイント | リスク内容 |
|---|---|
シナリオ・Zapのオーナー管理 | 退職者がオーナーのままになっている |
接続(Connection)の認証情報管理 | 個人アカウントで接続しているサービスが多数ある |
Webhookの認証設定 | Webhookシークレット未設定で誰でもトリガー可能 |
エラー通知・ログの保存先 | エラーログに個人情報・機密データが含まれる |
データのルーティング先 | 機密データが想定外の国・リージョンのサーバーを経由 |
組織アカウントでの管理 | 個人アカウントで作ったシナリオが会社管理外になっている |
重点チェック: MakeはデータがMake社のサーバー(EU)を経由する。個人情報保護法・GDPR観点でのデータ越境移転の確認が必要。組織プランでの一元管理と、退職者アカウントの定期棚卸しを行う。
Glide / AppSheet
確認ポイント | リスク内容 |
|---|---|
アプリの公開設定 | 「Anyone can use」設定で外部からアクセス可能 |
データソース(Spreadsheet)の共有設定 | Googleスプレッドシートがパブリック共有になっている |
ユーザー認証の有無 | メール認証・SSO未設定でアクセス制御ゼロ |
行レベルのフィルタリング | ユーザーごとのデータ分離が設定されていない |
アプリのバージョン管理 | 変更履歴がなく、誰がいつ何を変えたか追跡不能 |
重点チェック: Glideは無料プランでもアプリが公開可能なため、「社内向けのつもりが外部公開になっていた」というミスが起きやすい。パブリッシュ設定と共有リンクの定期確認が必要。
自社でできる10項目セキュリティチェックリスト
以下のチェックリストを、ノーコード・ローコードシステムの担当者(IT部門・業務部門を問わず)が定期的(最低でも年1回、重要システムは四半期ごと)に実施することを推奨します。
# | チェック項目 | 確認方法 | リスクレベル |
|---|---|---|---|
1 | ノーコードアプリ・フローの棚卸し一覧を作成している | M365管理センター、Make組織設定等で全体把握 | 高 |
2 | 退職者・異動者のアカウントをすべて削除・無効化している | IDプロバイダー(Entra ID等)との突き合わせ | 高 |
3 | 本番データにアクセスできるユーザーを最小化している | アプリの共有設定・ロール設定を確認 | 高 |
4 | データソース側(SharePoint・DB・Spreadsheet)にアクセス制御が設定されている | RLS・Privacy Rules・権限設定を直接確認 | 高 |
5 | APIキー・Webhookシークレットが平文保存されていない | フロー・ワークフロー内の変数・テキストフィールドを確認 | 高 |
6 | Webhookに認証(シークレット・IPホワイトリスト等)が設定されている | Make・Zapier・Power AutomateのWebhook設定を確認 | 中 |
7 | どのデータがどの外部サービスに送られているか把握できている | データフロー図の作成・更新 | 中 |
8 | 個人情報・機密データを処理するフローがIT部門に届出・承認されている | シャドーITの洗い出し | 中 |
9 | アプリ・フローの変更履歴(誰がいつ何を変えたか)を記録している | 監査ログ設定の確認 | 中 |
10 | セキュリティインシデント発生時の対応手順(連絡先・手順書)がある | BCP・インシデント対応計画の整備 | 中 |
重要: 上記チェックで「高リスク」の項目にひとつでも「×」がある場合、今すぐ対処が必要です。特に個人情報・顧客データ・決済情報を扱うシステムで「高リスク」項目に問題があれば、個人情報保護法違反・情報漏洩インシデントに直結します。
専門家診断が必要なケース
自社チェックは重要ですが、以下に該当する場合は専門家によるセキュリティ診断を強く推奨します。
ケース① 個人情報・顧客データを扱うシステム
氏名・メールアドレス・住所・電話番号など、個人情報保護法上の個人情報を扱うノーコードシステムは、安全管理措置の義務(個人情報保護法第23条)の対象です。「ノーコードで作ったから対象外」ではなく、システムの種類にかかわらず適用されます。
万が一漏洩した場合、個人情報保護委員会への報告義務(1,000件以上の漏洩等の場合は72時間以内)が発生します。
ケース② 取引先・パートナーのデータを扱うシステム
B2Bビジネスで取引先の情報を処理するシステムは、サプライチェーンセキュリティの観点から問題になることがあります。取引先から「セキュリティ診断報告書の提出」を求められるケースも増えています。
ケース③ 決済・金融情報を扱うシステム
StripeやPAY.JPとAPI連携する決済処理、銀行口座情報の取り扱いがある場合は、PCI DSSの適用範囲に注意が必要です。ノーコードツールのワークフロー内でクレジットカード情報を処理・保存していると、PCI DSS違反になる可能性があります。
ケース④ 社員数100名以上・システム利用者が多い場合
利用者が多いほど、セキュリティ設定ミスの影響範囲が大きくなります。また、攻撃者から見た「価値あるターゲット」になりやすい規模でもあります。
ケース⑤ 外部からアクセス可能なシステム(インターネット公開)
Bubbleで作った顧客向けポータル、GlideのBtoCアプリなど、インターネット上に公開されているノーコードアプリは、自動スキャナーによる攻撃を受け続けています。定期的な脆弱性診断が必要です。
費用目安:ノーコードシステムのセキュリティ診断
ノーコード・ローコードシステムのセキュリティ診断は、従来のWebアプリケーション診断と同様のアプローチで実施します。ツール特有の設定ミス(Privacy Rules、RLS、Webhook認証等)と一般的なWebセキュリティ(認証不備、入力バリデーション、APIセキュリティ等)の両面から評価します。
診断の種類 | 対象規模の目安 | 費用目安 | 期間目安 |
|---|---|---|---|
簡易設定レビュー | 小規模アプリ(画面数5〜10程度) | 15万〜30万円 | 1〜2週間 |
標準セキュリティ診断 | 中規模アプリ(画面数10〜30程度) | 30万〜80万円 | 2〜4週間 |
包括的ペネトレーションテスト | 大規模・複合システム | 80万〜200万円以上 | 4〜8週間 |
定期診断(年1〜2回) | 継続的セキュリティ確保 | 20万〜60万円/回 | 1〜2週間 |
費用に影響する主な要素:
- 画面数・フロー数・API数
- 扱うデータの機密性(個人情報・決済情報等)
- 対象ツール(Power Appsはエンタープライズ環境の複雑さ、Bubbleはカスタム設定の多様性等)
- 診断後のレポート詳細度と改善サポートの有無
上記はあくまでも目安であり、システムの実態によって大きく変わります。まずは無料相談で概算見積もりを取ることをお勧めします。
安全なノーコード開発のためのベストプラクティス
1. 「作り始める前」にセキュリティを設計する
ノーコードでも、誰が何のデータにアクセスできるか(権限設計)を最初に定義してください。後から追加するのは難しく、設定漏れが生まれやすくなります。
2. IT部門への届出・承認フローを作る
業務部門が独自にノーコードシステムを構築する場合でも、IT部門への事前申請・承認を義務化してください。シャドーITを「見える化」することが最初のステップです。
3. 個人アカウントでなく組織アカウントで管理する
Make・Zapier・Bubbleなど、できるだけ組織プラン・チームプランで一元管理し、個人のアカウントに依存しない運用にしてください。退職時の引き継ぎ漏れを防ぎます。
4. 最小権限の原則を徹底する
データソース・コネクター・サービスアカウントの権限は、「そのシステムが動くために最低限必要な権限だけ」に絞ってください。Power AppsのコネクターにはSharePointの「読み取り専用」権限を使う、BubbleのPrivacy RulesでCurrent Userのデータのみ参照可能にする、などです。
5. APIキーはシークレット管理機能に保存する
APIキー・Webhookシークレット・パスワードは、各ツールのシークレット管理機能(Power AutomateのAzure Key Vault統合、BubbleのEnvironment Variables、Makeのカスタム変数等)を必ず使ってください。ワークフロー内のテキストフィールドに直書きしてはいけません。
6. 退職者・異動者の定期棚卸しを自動化する
人事システムと連携し、退職・異動時に自動でノーコードアプリのアクセス権を剥奪する仕組みを作ることが理想です。少なくとも月1回の手動棚卸しを義務化してください。
7. 重要な変更はステージング環境でテストする
「ちょっと変えたら本番が動かなくなった」「設定を変えたらデータが漏れた」というリスクを避けるため、本番環境と分離したテスト環境(ステージング環境)で動作確認する習慣をつけてください。
8. 定期的な診断・レビューを計画に組み込む
年1回以上の設定レビューと、2〜3年に1回の専門家によるセキュリティ診断を計画に盛り込んでください。システムが「育って」機能が増えるほど、当初の設定では想定していなかったリスクが生まれます。
まとめ
ノーコード・ローコード+AIの組み合わせは、業務改善の強力な武器です。しかし、「誰でも作れる」ことと「セキュリティが確保されている」ことはまったく別の話です。
本記事で解説した5大リスク──アクセス制御の設定ミス、過剰なデータアクセス権限、APIキーの平文保存、ワークフローによるデータ外部流出、退職者アカウントの放置──は、いずれも今日から確認・修正できるものです。まずは10項目チェックリストで現状を把握することから始めてください。
個人情報・顧客データ・決済情報を扱うシステムについては、自社チェックだけでは見つけられない脆弱性が残るリスクがあります。専門家によるセキュリティ診断を年間計画に組み込むことが、長期的なリスク管理の観点から有効です。
AEVUSへのご相談
AEVUSでは、Power Apps・Bubble・Make・Glide・AppSheetをはじめとするノーコード・ローコードシステムのセキュリティ診断・ペネトレーションテストを提供しています。
- 設定レビュー: アクセス制御・権限設計・APIキー管理の現状調査
- 脆弱性診断: ノーコードシステムに特有のリスク+OWASP Top 10ベースの包括診断
- ペネトレーションテスト: 実際の攻撃手法で侵入可能かを検証
- 改善コンサルティング: 発見された問題の優先順位付けと修正サポート
「まずどのくらい費用がかかるか知りたい」「うちのシステムが対象になるか確認したい」という段階でのご相談も歓迎です。
👉 セキュリティ診断・ペネトレーションテストのご相談はこちら