この記事は、現場主導のAI・ローコード開発が増え始めた段階で「禁止せずにガバナンスをどう効かせるか」を検討している情報システム部門・DX推進担当・経営企画の方を対象にしています。
調査機関ITRの報道ベースの情報によると、市民開発を実施している企業は全体の約3分の1まで拡大傾向にあるとされています。さらに生成AIとの組み合わせにより、プログラミング経験のない社員が外部APIを呼び出すAIエージェントや自動回答フォームを作れるようになっています。
現場の生産性は上がる一方、情シスが把握していないAI連携が増え、個人情報処理・API費用・セキュリティ設定の不備が後から発覚するケースが増えています。「市民開発を禁止する」方針は定着しにくく、禁止しても水面下で続きます。現実的な解は、承認プロセスを整備して「届け出があれば許可する」仕組みに変えることです。
なぜ「禁止」より「軽量レビュー」が機能するか
禁止が機能しない理由は、現場にとっての利益(業務効率化・即時成果)が管理側のリスク懸念より具体的に見えるからです。一方、承認に時間がかかりすぎると抜け道が増えます。
委員会設計の原則は次の3点です。①軽量(申請から承認まで3営業日以内)、②明確(リスクが高いか低いかを申請者自身が判断できる基準)、③停止不要(低リスクは即時許可、高リスクだけ審査に回す)。
AI ASSESSMENT
PoC の前に「そもそも使えるか」を30分で見極めませんか?
情シス部門の稟議書作成をサポートする無料の30分壁打ち。ROI 試算シート・失敗要因チェックリストをその場で共有します。
レビュー委員会の設計:3層構造
市民開発AIのレビューは、リスクの大きさに応じて審査の深さを変える3層で設計します。
| レイヤー | リスク水準 | 対象ツールの例 | 承認方法 | 審査者 |
|---|---|---|---|---|
| L1(自己申告・即時許可) | 低:外部データ連携なし・社内データのみ・個人情報不扱い | 社内文書の要約ツール・テンプレート生成・会議メモ整理 | 申請フォーム提出→自動通知(人手レビューなし) | 不要(申請者が自己判断) |
| L2(情シス確認・2営業日) | 中:社内システムとAPI連携・個人情報を含まない業務データ処理 | 社内DBと連携した検索ツール・Slack連携ボット | 情シス担当1名のレビュー | 情シス担当者 |
| L3(委員会審査・5営業日) | 高:個人情報・顧客情報・外部API経由のデータ送受信・費用が月5万円超 | 顧客問い合わせ対応エージェント・外部SaaS連携の自動処理 | 委員会(情シス・法務・業務部門リード)の合議 | 委員会(3名以上) |
委員会の構成と役割
委員会は専任を置かず、既存の担当者が兼務する形で運用します。
| 役割 | 担当部門 | 主な判断軸 | 必要な判断時間 |
|---|---|---|---|
| セキュリティ審査 | 情報システム部門 | API接続の設定・データアクセス権限・ログ取得の有無 | L2: 0.5時間、L3: 1〜2時間 |
| 法務・コンプライアンス審査 | 法務・総務 | 個人情報保護法・外部サービス利用規約・秘密保持 | L3のみ: 1〜2時間 |
| 業務妥当性確認 | 申請部門の上長 | 業務目的・利用範囲・停止条件の妥当性 | L3のみ: 0.5時間 |
| CoE(推進・教育) | DX推進・情シス | 申請者へのガイダンス・ベストプラクティス共有・類似案件の横展開 | 随時 |
FREE DOWNLOAD
AI導入チェックリスト(PoC 失敗要因 10項目)
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
申請フォームに含める項目
申請フォームはシンプルに保ちます。以下の7項目が揃えば、L1〜L3の振り分けと審査が可能です。
| 項目 | 入力内容 | レイヤー判断への使われ方 |
|---|---|---|
| ツール名・目的 | 何のためのツールか1〜2文 | 審査の出発点 |
| 処理するデータの種類 | 社内情報のみ・個人情報含む・顧客情報含む | L分類の主判断軸 |
| 外部API・SaaS連携の有無 | 連携先サービス名と接続データ | L2/L3の判断 |
| 推定月額費用 | APIコスト・ツール利用料の見積 | L3の費用基準 |
| 利用範囲 | 自分のみ・部署内・部署外(複数部署) | 影響範囲の確認 |
| 停止手順 | 問題が起きたときに誰がどう止めるか | L2/L3の必須確認 |
| ログ保存の設定 | 操作ログ・出力ログを残す手段 | 監査対応の確認 |
運用で陥りやすい3つのパターンと回避策
1. 委員会が月1回しか開かれず申請が滞留する:L3案件が月5件以上になる前に週次開催に切り替えます。L1は自動許可にすることで、委員会に上がる件数を減らせます。
2. 申請者が「L1でいいか」を過小申告する:判断基準が曖昧だと申請者はリスクを低く見積もります。申請フォームに「個人情報を含む」「外部API連携あり」の2択が両方Noなら自動的にL1になるロジックを組み込みます。
3. 承認後の変更がレビューなしに進む:承認時の申請内容から変更が生じた場合は再申請が必要というルールを明文化します。変更の定義(連携先の追加・処理データの変更・利用範囲の拡大)をリストで示します。
市民開発のガバナンスはAIエージェント特有のリスクと重なる部分が多く、AIエージェント導入の事前チェックと合わせて整備することで承認フローの重複を避けられます。生成AIに関するガバナンス全体の設計は生成AIガバナンス設計ガイドが参考になります。
GXOはどう支援するか
GXOでは、申請フォームのひな形、3層レイヤーの判断基準表、委員会の役割分担とアジェンダ設計を提供しています。既存の規程・組織体制に合わせてカスタマイズし、「委員会を設置したが形骸化した」を避けるための運用設計まで含めて支援します。DX推進部門と情シスと法務が初めて一緒に座るきっかけとして、委員会立ち上げのキックオフから伴走できます。
よくある質問
Q1. 小規模な会社でも委員会は必要ですか
専任委員会を設置しなくても、「誰に申請するか」「何を確認するか」の2点が明確であれば機能します。情シス1名・法務兼務者1名の2名体制でも、L1自動許可・L2情シス確認・L3の場合のみ経営者判断という構成で回せます。
Q2. AIが絡まないローコード開発も対象にすべきですか
外部APIや個人情報を扱う場合はAI有無にかかわらず同じフローを適用することを推奨します。生成AI利用だけを審査対象にすると、AIを使っていない外部連携ツールが野放しになります。
Q3. 委員会設置にどれくらいの準備期間が必要ですか
申請フォームと判断基準表の作成に1〜2週間、キックオフと試行に1か月を想定します。最初から完璧なルールを作ろうとせず、「試行期間3か月で申請20件を処理してから見直す」と期限を決めることで動き出しやすくなります。
参考情報
- ITR「市民開発のビジネス価値と成果獲得の秘訣」(市民開発を実施する企業は全体の約3分の1と拡大傾向・報道ベース):https://www.itr.co.jp/report-library/c-26010184
- AI事業者ガイドライン第1.1版(総務省・経産省、2025年3月28日):https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/pdf/20250328_2.pdf
- IPA「AI利用者のためのセキュリティ豆知識」:https://www.ipa.go.jp/digital/ai/security/ai_security_tips.html
市民開発AIのレビュー委員会を一緒に立ち上げませんか
GXOでは、申請フォームのひな形・3層判断基準・委員会アジェンダの設計から、情シス・法務・DX推進が参加するキックオフのファシリテーションまで、委員会の実働開始まで伴走します。
