ローコード開発のセキュリティリスクと対策｜権限設計・野良アプリ・発注時の確認項目

ローコード基盤そのものが破られて情報が漏れた事例より、権限設定と公開範囲を間違えたまま業務に乗ってしまった事例のほうが、実務では圧倒的に多く見つかります。OWASPがまとめたCitizen Development Top 10も、上位に並ぶのは基盤の脆弱性ではなく、権限の誤用と設定不備です。この記事では、基盤事業者と自社の責任範囲の切り分けから始め、kintoneの3階層アクセス権とPower Platformのデータポリシー・共有制限という製品ごとの設定範囲、野良アプリを止める棚卸しの手順、監査要件から見送るべき3条件、委託時の契約条項と受入検査項目までを、発注する側の判断材料としてまとめました。

まとめ：ローコード開発のセキュリティは製品選びより権限設計と棚卸しで決まる

主要なローコード基盤は、通信の暗号化やインフラの堅牢性を事業者側が持ちます。事故が起きるのは、その上に載せたアプリの権限設定・公開範囲・外部連携という、作った側の責任範囲です。

結論は3つです。守る対象は基盤ではなくアプリの設定なので、製品選定より先に「誰が作れて、誰に配れて、どこまで見られるか」を決める組織側の設計が要ります。次に、権限の粒度は製品差が大きく、kintoneはアプリ・レコード・フィールドの3階層で条件行を上から評価する方式、Power Platformはコネクタ単位のデータポリシーと共有人数の上限で絞る方式と、設定できる場所そのものが違いました。そして効くのは作った直後の設定より半年後の棚卸しです。担当者が異動した後も動き続けるアプリと、無効化されずに残った接続の資格情報が、実際の漏洩経路になります。

採用しない判断も必要です。操作ログの保全と保持年数を監査で問われる領域、権限が計算ロジックで決まる領域、基盤の改版時期を自社で決められないと困る領域。この3つは受託開発で切り出したほうが安く収まります。

ローコード開発で事故が起きる層と、基盤事業者と自社に分かれる責任の範囲

「ローコードは危ないのか」という問いに答えが出ないのは、危険の所在が2つの層に分かれているためです。

基盤側が守る範囲と、アプリを作った側が負う設定・権限・データの責任

クラウド型のローコード基盤では、データセンターの物理セキュリティ、OSやミドルウェアの更新、通信路の暗号化、基盤自体の脆弱性対応は事業者が担います。ここは利用者が手を出せない代わりに、責任も負いません。

利用者側に残るのは、アカウントの発行と停止、アクセス権の設計、アプリの公開範囲、外部サービスとの接続、入れたデータそのものの扱いです。cybozu.comのIPアドレス制限やクライアント証明書によるセキュアアクセスも、設定するかどうかは利用者が決めます。機能の存在と、それが有効になっている状態は別物です。

スクラッチ開発とパッケージ・ローコードの違いで言えば、全層が自社と開発会社の責任だった状態から下半分が事業者へ移り、上半分だけが残ります。この上半分の設計を誰もやらないまま業務が動き出す構図が、事故の温床です。

スクラッチ開発と比べて増えるリスクと、逆に減るリスクの実際の内訳

減るリスクははっきりしています。SQLインジェクションやクロスサイトスクリプティングのような実装起因の脆弱性は、コードを書かない範囲では基盤の実装に吸収され、ライブラリの更新漏れも事業者側の更新に含まれました。

増えるのは、開発の訓練を受けていない人が権限を設定する状況そのものです。業務部門の担当者がアプリを1本作るのに、承認も設計レビューもいらない。速さの正体はそこにありますが、同じ速さで「全社員が閲覧できる状態の顧客名簿」も生まれます。外部サービスへ簡単につながる点も同じで、Power Platformではコネクタを1つ追加するだけで社外のSaaSとデータをやり取りできてしまいます。制約全般の整理はローコード開発のデメリットと採用可否へ分けてまとめました。

OWASPが整理したローコード固有の10類型と、国内案件で先に潰す4類型

リスクを網羅的に洗い出すなら、業界標準の分類から入ると漏れが減ります。

CD-SEC-01から10までの類型一覧と、2025年版で広がった対象範囲

OWASPは市民開発向けのリスク分類として Citizen Development Top 10 を公開しています。旧称は OWASP Low-Code/No-Code Top 10（2022年版）で、現行の2025年版はAI支援コーディングやAIエージェントを含む範囲まで対象を広げました（2026年8月時点）。10類型は次のとおりです。

先頭が Blind Trust、つまり「基盤事業者を無検証で信じること」から始まる並びは示唆的です。認証を取得した事業者だから安全、という前提で自社の設定を点検しない姿勢を、OWASPは最初のリスクとして置きました。

権限の誤用・データ流出・設定不備・資産管理という頻出4類型の中身

10類型すべてに同じ手間をかける必要はありません。国内の社内システム案件で実際に問題化しやすいのは、CD-SEC-03（権限の誤用）、CD-SEC-04（機微データの流出）、CD-SEC-07（設定不備）、CD-SEC-09（資産管理の失敗）の4つに集中します。

この4つの共通点は、技術的な攻撃ではなく設定と運用の抜けから起きる点にあります。高度な手口は不要で、正規のアカウントで正規の画面を開いたら見えてはいけないものが見えた、という形で表面化しました。対策の主戦場は脆弱性診断ではなく権限設計と棚卸しです。

残る6類型のうち、CD-SEC-06（出所不明の部品）は非公式のプラグインやカスタムコネクタを許可する場合に、CD-SEC-02（アカウント偽装）は作成者の権限でフローが動く仕組みを使うときに効いてきます。

アカウント偽装と権限の誤用を止めるアクセス権の階層と認証の設定範囲

ここからは具体的な設定です。「どこまで細かく絞れるか」は製品差が大きく、選定段階で確認しておく項目でもあります。

kintoneのアプリ・レコード・フィールド3階層と上の行が優先される評価順

kintoneのアクセス権は3階層です。アプリのアクセス権がすべてのレコードに対する権限を決め、レコードのアクセス権が特定のレコードだけの権限を、フィールドのアクセス権が特定の項目だけの権限を上書きします。人事評価アプリで「本人と直属の上長だけが評価コメント欄を見られる」といった要件は、この3階層を組み合わせて表現します。

実装で間違えやすいのが評価順です。レコードのアクセス権は条件を複数行並べられますが、上の行の設定が優先され、順位は並び替えアイコンのドラッグで変えます。広い条件を上に置くと、下に書いた厳しい制限は効きません。設定対象はユーザー・組織・グループのほか、ユーザー選択フィールドや作成者・更新者、プロセス管理が有効な場合の作業者も使えます。組織指定では下位組織への継承設定が別にあり、「部を指定したのに課のメンバーに見えない」という食い違いはここで起きました。

Power Platformのデータポリシーと共有制限で絞るコネクタと配布先

Power Platformの制御軸は、権限の階層ではなくコネクタと配布範囲です。データポリシーはコネクタ単位でアクセスを制御し、設計時（作成者がそのコネクタを使うアプリを保存できない）と実行時（既存の接続が切れる）の双方に効きます。違反と判定されたアプリ・フロー・チャットボットは「中断」または「検疫」の状態に置かれて操作不能になり、コネクタ全体をブロックした場合は接続そのものが「無効」状態になりました。

反映には時間差があります。Microsoftのドキュメント（ms.date 2026-04-07・更新2026-07-11）は、完全な適用までの待ち時間を「最も極端なケースで24時間、ほとんどの場合は1時間以内」と記載しました。インシデント対応でポリシーを締めても、即時に全環境へ効くわけではありません。

配布範囲を絞るのは共有制限です。マネージド環境では、キャンバスアプリについて「セキュリティグループとの共有を除外する」を選んだうえで、共有できる個人の合計数に上限を設定できます（公式のPowerShell例は20人）。ただし働くのは設定後の共有操作に対してで、ルール適用前からアクセス権を持つ既存ユーザーには遡及せず、違反状態のアプリは準拠するまで共有解除だけが許可されました。既に配ったアプリを後から絞るには、制限の設定だけでは足りません。

IPアドレス制限・クライアント証明書・多要素認証を重ねる接続元の絞り方

アカウントの乗っ取りに対しては、認証と接続元の両方を絞ります。cybozu.comの場合、IPアドレス制限で接続元ネットワークを限定し、社外から使う端末にはクライアント証明書を入れてセキュアアクセスで例外的に通す構成が基本形です。営業担当のスマートフォンのように接続元IPが変わる端末を、社内限定の運用へ無理に合わせずに済みます。

Basic認証は簡便ですが、公式ヘルプ自体が「セキュリティのレベルは低い」と明記し、IPアドレス制限と組み合わせる位置づけにしています。これ単体を社外アクセスの入口にする設計は避けてください。Power Platform側では、マネージド環境の機能としてIPファイアウォールとIP Cookieバインドが提供され、セッションの持ち出しに対する制御まで含みます。使える手札は製品ごとに違うため、扱うデータの機微度が高い案件では選定段階でこの範囲を比べておくと後戻りが減ります。製品ごとの向き不向きはローコードツールの用途別比較と選定基準に整理しました。

野良アプリと権限の穴を残さない棚卸しの手順と外部連携の遮断ライン

設定を正しく入れたアプリでも、1年放置すれば状況は変わります。運用の型を先に決めておく必要があります。

作成できる人を絞る環境分離と、業務利用へ昇格させる申請の線引き

野良アプリの全面禁止は、ローコードを入れた意味を消します。現実的なのは、個人の試作を許す場所と業務で使う場所を分けることです。Power Platformの環境やkintoneのスペースで領域を分け、試作用には社外コネクタや機密データを持ち込めない設定を入れます。

そのうえで、業務利用へ昇格させる線引きを文書で決めます。判断軸として使いやすいのは次の3点です。

• 個人情報・与信情報・人事評価など、閲覧範囲を限定すべきデータを扱うか
• 作成者以外の3人以上が日常業務で使うか
• 止まると他部署の業務が滞るか

1つでも当てはまるなら情報システム部門のレビューを通してから業務領域へ移し、当てはまらないうちは個人の試作のまま置いておく。この線引きがないと、レビュー対象が全アプリに膨らんで運用が破綻します。無断利用が広がる構図はシャドーAIの情報漏洩リスクと対策と同じで、禁止一辺倒では地下に潜るだけです。

未使用アプリを止める週次の棚卸し手順と、担当者を決める運用の型

棚卸しは仕組みで回します。マネージド環境には週次の使用状況の分析情報が含まれ、どのアプリが使われているかを定期的に把握できます。手順は次の流れが実務に乗りました。

1. 月次で、90日間アクセスのないアプリを一覧化する
2. 作成者へ継続利用の要否を確認し、応答がなければ無効化予告を出す
3. 2週間の予告期間を経て無効化し、データはバックアップを残す
4. 半年後にデータごと削除する

担当は情報システム部門に置き、止めてよいかの判断は使う部署へ返します。棚卸しが形骸化する最大の原因は、情報システム部門が可否を判断できず結局すべて残す結末です。「応答がなければ止める」という既定動作を先に決めておくと、この停滞は起きません。

退職者アカウントと接続に保存された資格情報の引き継ぎで起きる事故

見落とされがちなのが、アプリに紐づいた接続の扱いです。Power Platformでは、作成者がコネクタを追加したときに確立した接続が、保存された資格情報として環境内に格納されます。その作成者が退職してアカウントを削除すると接続が切れてフローが止まり、逆にアカウントを残せば退職者の権限で動く自動処理が残りました。

どちらも避けるには、業務領域のアプリを個人アカウントではなくサービスアカウントや共有の所有者で持たせます。そのうえで、アカウント停止手続きのチェックリストに「所有アプリと接続の移管」を入れる。人事異動の申請フローに組み込めれば、抜け漏れはほぼ消えます。

セキュリティ要件からローコードを見送る3条件と、スクラッチへ寄せる境界

ここは判断を言い切ります。次の3条件のいずれかに当たる業務は、ローコードに載せません。設定と運用でどうにかしようとすると、かえって費用と事故確率が上がります。

操作ログの保全と保持年数を監査で問われる領域を外すという判断基準

金融・医療・上場企業の内部統制対象など、「誰がいつ何を見たか」を数年分そろえて外部監査に提出する義務がある領域は外します。基盤が出力するログの粒度と保持期間は事業者の仕様に従うしかなく、自社の監査要件へ合わせる交渉は個別対応になるためです。マネージド環境にはApplication Insightsへデータをエクスポートする機能があり、長期保管の経路自体は存在しますが、それを監査に耐える形で設計し維持する作業は結局のところ開発案件になります。ログ要件が主目的の業務なら、最初から自社側で保全設計ができる作り方を選んだほうが総額でも下回りました。

権限がレコードではなく計算結果で決まる業務を切り出す線引きの根拠

2つ目は、閲覧可否が「誰が作ったか」「どの組織か」ではなく計算結果や複合条件で決まる業務です。「取引先の与信ランクがBかつ自部門の担当案件で、受注確度が70%以上のものだけ見せる」という要件は、kintoneのレコードアクセス権が扱うユーザー・組織・グループ・特定フィールド値の枠に収まりません。無理に載せると、条件行の優先順位で表現しようとした結果、上の行が広すぎて下の制限が効かない事故につながります。権限が動的な計算で決まる業務は、切り出して受託開発に回す。これが線引きの根拠です。

基盤の改版時期を自社で決められない前提が受け入れられない場合の判断

3つ目は、基盤側の変更を自社の都合で止められない点を受け入れられないケースです。ローコード基盤はSaaSとして更新され、コネクタの仕様変更や機能の廃止も事業者の計画で進みます。Microsoftも高度なコネクタポリシーについて、仮想コネクタを今後もサポートしない方針を明記しました。統制手段が同じ形で残る保証はありません。

繁忙期に一切の変更を許容できない業務や、法令対応で改修時期が固定されている業務では、この不確実性が現実の障害になります。判断としては、基幹に近い領域をスクラッチで作り、周辺の申請・集計・照会をローコードに寄せます。費用面から見た同じ線引きはローコード開発の費用相場と5年総額の比較で扱いました。

委託時にセキュリティ要件を担保する契約条項と受入検査で見る項目の型

開発会社に構築を頼む場合、成果物の見た目だけを検査しても設定の穴は見つかりません。契約と検査の両方に項目を立てます。

責任分界点・脆弱性対応の期限・基盤改版時の費用負担という契約の3項目

契約書とRFPに最低限書くのは3点です。1点目は責任分界点で、基盤事業者・開発会社・自社の責任をそれぞれ列挙し、アクセス権の設計は開発会社、アカウントの発行と停止は自社、という粒度まで落とします。

2点目は、脆弱性や設定不備が見つかったときの対応期限です。基盤起因なら事業者の対応待ちになるため、開発会社に求めるのは「回避策の提示までの日数」に限定するのが現実的でした。3点目は、基盤の仕様変更でアプリの改修が必要になった場合の費用負担です。ここを空欄のまま契約すると改版のたびに交渉が発生します。保守契約に年間の改修工数枠を含める形が、揉め事の少ない書き方です。この条項をどこまで詰められるかは相手によって差が出るため、ローコード開発会社の選び方と発注前の確認項目もあわせて確認してください。

権限マトリクスの突き合わせと公開範囲の実機確認という受入検査の手順

受入検査は設計書ではなく実機の画面で確認します。手順は次のとおりです。

1. 役割ごとのテストアカウントを用意し、権限マトリクスの想定と突き合わせる
2. 各役割で実際にログインし、見えてはいけないレコードとフィールドが隠れているか目視する
3. アプリの共有先一覧を出力し、全社グループや外部ゲストが含まれていないか確認する
4. 使われているコネクタを一覧化し、承認していない外部サービスへの接続がないか照合する
5. CSVエクスポートと添付ファイルのダウンロード可否を、役割ごとに確認する

特に効くのは3番目と4番目です。設計書に「営業部のみ」と書かれていても、実装時のテストで全社共有にしたまま戻し忘れている状態は、実際に見つかる類の抜けでした。

内製と外注の分担を決める、セキュリティ設定の設計と運用の切り分け方

費用を抑えつつ設定の質を保つ分担は、設計を外部に、運用を自社に置く形です。権限マトリクスの設計、環境分離の方針、棚卸しの手順書までを開発会社に作らせ、日々のアカウント管理と月次の棚卸しは自社で回します。設計の質は経験に依存する一方、運用は手順書があれば社内で回せるためです。

一創ではノーコード・ローコードアプリ開発として、この設計部分とスクラッチ開発を組み合わせた構成の相談を受けています。基幹に近い部分を受託開発で作り、周辺をローコードで内製する構成では、責任分界点をどこに引くかで運用負荷が変わりました。自社にどこまで運用を残せるかは、内製化の進め方と外注との使い分けを踏まえて決めてください。

よくある質問

ローコード開発のセキュリティについて、発注検討時に相談の多い5点をまとめました。

ローコード開発はスクラッチ開発よりセキュリティ面で劣りますか？

層によって答えが逆になります。基盤のインフラ・通信の暗号化・脆弱性対応は事業者が担うため、自社で構築するより堅い場合もありました。一方でアプリの権限設定・公開範囲・外部連携は利用者の責任で、訓練を受けていない担当者が設定する分だけ穴が生まれます。実際の事故は後者に集中するため、「基盤は堅いが運用は脆い」という理解が実態に近いといえます。

野良アプリを防ぐには全面禁止にするしかないのでしょうか？

全面禁止は推奨しません。禁止すると個人のクラウドサービスや表計算ソフトへ流れ、把握できない場所へ業務データが移るだけです。試作を許す領域と業務利用の領域を分け、機微データを扱う・作成者以外の3人以上が使う・止まると他部署が困る、のいずれかに当たったらレビューを通す運用にすると、把握できる範囲に収まります。

ローコード基盤の認証取得状況を確認すれば安全と判断できますか？

基盤の認証は事業者側の責任範囲が管理されている証拠にはなりますが、自社が設定するアプリの安全性は保証しません。OWASPのCitizen Development Top 10がCD-SEC-01に Blind Trust（基盤への無検証の信頼）を置くのは、この誤解が起点になるためです。認証の確認は選定の入口として使い、権限設計と公開範囲の点検は別途行ってください。

アクセス権を設定したのに想定外のユーザーに見えてしまう原因は何ですか？

頻度が高いのは条件の評価順です。kintoneのレコードアクセス権は上の行が優先されるため、広い条件を上に置くと下の制限が効きません。次に多いのが組織の継承設定で、部を指定したときに下位組織へ継承するかは別設定です。3つ目はアプリの共有先で、実装中に全社共有にしたまま戻していない状態。この3点を実機で確認すれば大半は特定できます。

セキュリティ要件が厳しい業務でも部分的にローコードを使えますか？

使えます。基幹に近い部分と、その周辺の申請・集計・照会を分けるのが定石です。監査で操作ログの保全を問われる処理と、権限が計算結果で決まる処理をスクラッチ側へ置き、参照や入力補助をローコード側へ置く。分界点の設計さえ最初に固めれば、厳しい要件を満たしつつ開発スピードの利点も残せます。

関連記事

• ローコード開発のデメリット7つ｜スクラッチとの使い分けと導入判断：セキュリティ以外の制約と採用可否の判断材料です
• ローコード開発の費用相場｜初期費・ライセンス費の内訳とスクラッチ5年総額比較：総額の観点から見た採用ラインを試算しています
• ローコードツールとは？用途別の比較と選定基準・スクラッチ開発との使い分けを解説：製品ごとの向き不向きと選定の順序を整理しています
• スクラッチ開発とは？パッケージ・ローコードとの違いと発注判断を解説：開発方式そのものを決める段階の判断材料です
• 内製化とは？外注との違い・メリットとデメリット・進め方を解説：運用を自社で回す体制づくりの前提を解説しています