生成AIの活用が自治体の業務にも広がる中、AIエージェントが扱うデータの安全性と、住民サービスに直結する信頼性の高いシステム設計が求められています。本稿では、Difyを中心とした生成AI基盤に、Railsアプリケーション、RAG（Retrieval-Augmented Generation）、API連携を組み合わせる構成を取り上げ、技術的観点から全体像を整理します。さらに、自治体が抱える「データベースダンプの危険性」「SQLインジェクション」「大量APIリクエストの検知困難性」などの技術リスクを専門的に解説しつつ、より安全なアーキテクチャやガードレールの実装手法を提示します。最後に、自治体でのAI活用を想定した応用事例として、問い合わせ応答システム、条例・文書検索AI、住民サービス支援エージェントなどの設計ポイントを示します。本稿が、行政システムにAIを導入したい開発者の参考となれば幸いです。
自治体向けAI基盤の全体像
本章では、自治体が生成AIを活用する際の「全体アーキテクチャ」を示します。特に、Difyを中心としたマルチLLM基盤、Railsによるアプリケーション層、RAGによる文書検索、APIガードレールの組み合わせがどのように役割分担されるかを説明します。ポイントは、AI自身に生データへ直接アクセスさせないことと、プロキシ層による制御、そしてRAGによる限定的な文書提供です。
AI基盤を支える3層構造
自治体向けの生成AI基盤は、大きく次の3層に分かれます。
AI推論層（LLM・Dify）
アプリケーション層（Rails）
データ層（RDB／検索基盤／ファイルストレージ）
この3層構造を採用することで、AIは“すべてを知る存在”ではなく、**必要な情報だけを安全に引き出す「司書」**のように振る舞わせることができます。
Difyを中心にしたマルチLLM基盤
Dify は以下の役割を担います。
LLMの推論管理（OpenAI / Anthropic / Llama 系含む）
ワークフローによるガードレール設定
プロンプト管理
マルチモデルの切り替え
API経由での推論サービス提供
Rails から見ると、Dify は 「プロンプトを送ると答えが返るLLMゲートウェイ」 として扱われます。
Railsアプリケーション層の役割
Rails は自治体の業務フローに合わせた UI・API・認証基盤を提供します。
住民問い合わせ UI
職員向けダッシュボード
認証／認可（Devise / JWT）
監査ログ
Dify との API 連携
“RAG の前処理”
Rails では AIへの入力は必ずバリデーションし、
「直接DBに触る」「危険な API を叩く」要求を抑止します。
RAG（検索拡張生成）の安全運用
自治体の条例・議会資料・FAQ文書などを RAG データとして扱います。
ポイントは：
1件ずつチャンク化
ベクトルDBに保存（Milvus / Chroma / PGVector）
Rails から検索 → AIへ安全に渡す
AIが“生データに直接触らない”構造にする
自治体のように、秘匿情報が多い領域ほど RAG の“選別された検索結果”が重要となります。
自治体が直面する技術リスク
本章では、自治体が生成AIシステムを導入する際に懸念すべき技術リスクを整理します。特に、近年問題となっている データベースダンプの危険性、SQLインジェクション、大量APIリクエストの検知困難性 など、AIとの組み合わせで深刻化しやすい脆弱性を解説します。ここでは、それぞれの攻撃が「なぜAI連携で危険度が増すのか」を重点的に説明します。
データベースダンプとは何か
「データベースダンプ（DB Dump）」とは、
データベース全体を丸ごとエクスポートする操作 を指します。
攻撃者に成功されると：
住民情報
申請情報
閲覧ログ
システム内部情報
が一括で流出する、極めて重大なインシデントになります。
■AI連携で危険性が増す理由
AIは自然言語で命令できるため、
悪意ある指示が UI から入り込みやすくなります。
こうした命令を、ガードレールが弱いと AIがそのまま内部APIに変換しようとする ことが起き得ます。
SQLインジェクションとAIの関係
SQLインジェクションは、
入力欄に悪意あるSQL文を仕込む攻撃 です。
例：
AIを組み合わせたシステムでは、次のようなリスクが出ます。
AIが“ユーザーの意図を推定”して危険なSQLを組み立てる
LLM の補完により攻撃文字列が“整形されてしまう”
“ユーザーの自然言語指示→SQL化”のワークフローで誤動作する
AI経由のSQL生成は必ず安全SQLクライアントを通すことが必要です。
API連続リクエストを自動化した攻撃
APIを大量に叩くスクリプトは、非常に検知が難しい攻撃の1つです。
AIを使うと、自然言語で簡単にスクリプト生成が可能
住民向け問い合わせシステムは“攻撃者が混ざりやすい”
組織の境界を越えるアクセスが多いため検知しにくい
■防御のポイント
レートリミット（IP・トークン単位）
監査ログ
しきい値検知
CAPTCHA or turnstile
LLM による“攻撃的意図検知”
AI自身に“攻撃判定”させる構成は有効です。
安全設計としてのガードレールとアーキテクチャ
本章では、生成AIを行政システムに組み込む際に必須となる安全設計（ガードレール）を詳細に解説します。ポイントは、AIを万能にしないこと、アクセス経路を限定すること、Rails側で必ず検証すること の3点です。また、RAG・プロキシ・監査ログ・網羅的テストなど、複数の技術を組み合わせて安全性を担保するアーキテクチャを提示します。
AIを直接DBに触らせない構造
AI が直接データベースに触れられる構成は、最も危険です。
■安全な構成例（文章による設計図）
AIはあくまで 文章を返すだけ の存在にし、
すべてのデータアクセスは Rails に集約します。
プロキシ層による安全制御
OpenAIやAnthropicなど外部APIを使う場合は、
外部APIへ直接行かせないためのプロキシ層 を挟みます。
役割：
モデル切り替え
トークン制限
プロンプトフィルタ
出力制限
監査ログ化
Dify のワークフローはこのプロキシ層として非常に適しています。
RAGによる“安全な文書提供”
RAGでは以下の処理が必須です。
文書チャンク化
メタデータ（分類・公開範囲）を付与
機密文書は別クラスタに隔離
Railsが適切な文書だけを検索
AIに“提示できる部分のみ”を渡す
「AIが勝手に検索して勝手に回答する」のではなく、
Railsが“渡して良い情報だけ”を選別する構造が重要です。
ログとテストによる継続的な安全保証
生成AIシステムは“完成”がなく、
常に振る舞いを監査する必要があります。
プロンプトの出力ログ
RAG命中率ログ
Rails内部APIの呼び出しログ
攻撃的指示の頻度分析
回答の正確性テスト
回帰テスト
AIモデルのバージョンアップに合わせて、
「動作保証テスト」を一定周期で行うことが重要です。
自治体におけるAI応用事例と技術的ポイント
本章では、自治体が生成AIを使う具体的な領域を取り上げ、どのような技術構成で安全に実現できるかを紹介します。問い合わせ応答、条例検索、住民向けガイドなど、RAG と Rails と Dify の組み合わせが特に強みを発揮するパターンを整理します。
問い合わせ回答AI（FAQエージェント）
構成：
Rails：問い合わせUI
RAG：FAQ文書データ
Dify：LLM回答生成
ガードレール：禁止情報のフィルタリング
キャッシュ：回答高速化
住民が入力した内容をAIが誤解すると誤回答になるため、
「意図解析」と「質問分類」をワークフローに挟むと安定します。
条例・議会資料検索AI
このケースは RAG の典型的な得意領域です。
処理の流れ：
条例PDF → テキスト抽出
チャンク化 & メタデータ付与
PGVector に格納
Rails が検索 → AIへ提示
AI が要約・解説
条例は文章が長く専門性が高いため、
AIによる読み替え・要約が効果を発揮します。
住民サービス支援AI（申請ガイド）
用途：
申請書の選択
必要書類の案内
手続きの分岐判断
説明文の生成
誤案内が重大なトラブルに直結するため、
Rails側で「回答を検証するルール」を作ります。
例：
まとめ
本稿では、自治体で生成AIを活用するための基盤構成、技術リスク、安全設計、応用事例を包括的に紹介しました。ポイントは、AIを万能にしないアーキテクチャと、Railsを中心に据えた堅牢な制御構造、そしてRAGによる限定的な安全情報提供です。自治体のシステムは住民生活に密接に関わるため、AIの利便性を活かしつつ、過剰な自動化や不正アクセスのリスクを確実に抑制する設計が求められます。今後は、自治体の業務に適合した“AI運用ガイドライン”が整備されることで、より安全かつ効果的なAI活用が進むことが期待されます。
〆最後に〆
以上、間違い・ご意見は
次のアドレスまでお願いします。
最近は全て返信出来てませんが
適時、返信して改定をします。
nowkouji226@gmail.com
【全体の纏め記事へ】
