掲載済み (2026-01-06号)
#098 474文字 • 3分

## やってみたら思った以上にエンジニアだった公務員の奮闘記― 区職員×都庁ICT職が挑む、生成AIプロジェクト(前編)

日本語

掲載情報

概要

https://zenn.dev/govtechtokyo/articles/493cda92ae44fc

詳細内容

## やってみたら思った以上にエンジニアだった公務員の奮闘記― 区職員×都庁ICT職が挑む、生成AIプロジェクト(前編) https://zenn.dev/govtechtokyo/articles/493cda92ae44fc 非エンジニアの公務員がDifyを用いて法令検索AIのプロトタイプを構築し、実務者視点でのRAG設計とデータ構造化の重要性を説く。 **Content Type**: 📖 Tutorial & Guide **Language**: ja **Scores**: Signal:5/5 | Depth:3/5 | Unique:4/5 | Practical:4/5 | Anti-Hype:4/5 **Main Journal**: 78/100 | **Annex Potential**: 78/100 | **Overall**: 80/100 **Topics**: [[Generative AI, GovTech, Dify, RAG, データ構造化]] 練馬区からGovTech東京へ派遣された非エンジニアの公務員が、ノーコードLLMアプリ開発プラットフォーム「Dify」を活用し、自治体実務の核心である「法令検索」を自動化するプロトタイプを開発した過程を報告している。著者は、専門家への「丸投げ」から脱却し、現場職員自らが生成AIツールを使いこなして業務課題を解決することの意義を強調している。 技術的な側面では、RAG(検索拡張生成)の実装において直面した具体的な課題とその解決策が示されている。まず、ワークフロー設計においては、ユーザーの知識量による分岐をあえて排除し、現場の「何がわからないかわからない」という実態に即したシンプルな構成を採用した。次に、検索精度の向上策として、法令・通達・FAQという性質の異なるナレッジを単一のノードにまとめると、平易な表現のFAQばかりが参照される「検索の偏り」が発生することを指摘。これを解決するため、各ナレッジをパラレル(並列)で取得し、最終的なLLMノードで回答を統合する手法を導入した。 さらに、RAGの精度を左右する「チャンク分割」の課題についても深く言及している。Difyの自動分割機能では法令の条文が意味をなさない単位で分断されてしまうため、Excel VBAを用いて「条・項・号」の構造に基づいたCSVデータを作成し、意味単位での構造化を実現した。著者は、最新のAIツールを単体で使うだけでなく、既存のExcel等のツールを組み合わせてデータを「整える」作業こそが、実務に耐えうるAI開発の鍵であると主張している。 エンジニアの視点から見れば、本記事はローコードツールを用いた「現場主導のDX」の具体像を提示するものである。開発ベンダーに依存せず、ドメイン知識を持つ実務者が自ら試行錯誤してロジックを組み上げるプロセスは、真の業務改善を実現するための強力なアプローチとして評価されている。著者は、こうした「自ら作る」経験が、単なる効率化を超えて、自身の業務フローを解体し再構築する「問い直し」の機会になると結論付けている。