自己紹介
お世話になっております。
練馬区区政改革担当部区政改革担当課区政改革担当係（GovTech東京派遣研修）のイケダと申します。
「いきなり誰だお前は」「なんだその仰々しい肩書きは」となると思いますが、肩書のとおりわたしは練馬区役所の職員として今年１年間GovTech東京へ研修という形でお邪魔している身分でございます。
なんの変哲もない文系大学を卒業し練馬区へ入庁、福祉部で窓口業務を４年間、そのあと教育委員会にて補助金給付業務に２年間携わり、７年目になる今年、GovTech東京へ派遣、という職歴となっております。
「GovTech（ガブテック）」とは「Government」と「Technology」が掛け合わさった言葉です。そう、わたしは「GovTech東京」の”Gov”と”東京”の部分はぼちぼちの経験がありますが”Tech”の部分は全くの門外漢です。今の肩書きこそ強そうですが、これまでは窓口業務や申請処理などの事務仕事がメイン。デジタル化なんてまったく縁がなく、使えるツールはせいぜいExcelのCOUNTIF関数くらい。
そんないわゆる「普通の公務員」が”Tech”ブログに執筆するなんて、自分自身が一番驚いているところです…。
そんなわたしは現在生成AIプラットフォームを使って法令AI検索チャットボットを作成しています。
昨今はローコード・ノーコードツールでRAGを使った業務アプリが作れる、ということで非技術者界隈でも話題ですが、これがなかなか一筋縄でいかない。とくに、「普通の公務員」にとっては。
今回は「やってみたら思った以上にエンジニアだった公務員の奮闘記― 区職員×都庁ICT職が挑む、生成AIプロジェクト」の顛末をお伝えできればと思います。
生成AIプラットフォームとの出会い
GovTech東京の中にいくつかあるグループの中で、わたしは区市町村DXグループに所属しています。ここではその名のとおり、区市町村のDX推進に関する支援を行うことを主な業務としています。
各種支援のうち、わたしが区職員時代に関わっていた業務が対象のプロダクト開発事業にアサインされましたが、新年度一発目で招かれたチームの会議室には、GovTech東京の専門職の面々と東京都のICT職員がずらり。途方もない場違い感に包まれつつ始まった会議ですが、飛び交う未知の単語の数々に圧倒され、何が何だかよくわからない日々がしばらく続きました。
ある日、唐突にプロジェクトリーダーが一言。
「イケダさんにDifyでプロトタイプ作ってもらうので、勉強を始めてください」
「で、でぃふぃー？？ぷろとたいぷ？？」
プロジェクトリーダーから命じられたのは、「自治体向けに、生成AIを利用した法令検索サービスのプロトタイプを作れ」というものでした。公務員の仕事は多岐に渡りますが、そのどれもに共通しているのは法令に基づいて業務を執り行うことです。頻度の多寡こそあれ、法令集や大量の通知類を手繰りながら、法律特有の言い回しの解釈に日々頭を悩ませています。
プロジェクトリーダから紹介された生成AIプラットフォームは、都庁各局や区市町村の職員が安全かつ効果的に生成AIを活用するためにGovTech東京がオープンソースソフトウェアを利用して内製で整備・構築した、アプリ開発がノーコードでできる基盤で、Difyというサービスを活用しています。GovTech東京では、昨年度から区市町村への試験運用を開始しており、まさにホットな代物でした。
初学者にはなかなか厳しいかと思われましたが、職員向けの動画研修講座や財団の貸出書籍、専門職の助言を頼りに勉強を始め、なんとか１か月で基本のワークフローを組めるように。今回は法令検索を取り扱うということで、ハルシネーション対策としてRAGを使うことになりました。
試行錯誤の日々
設計書を書く
プロジェクトリーダーからはまずは「設計書」を書いてみようと提案がありました。
「せ、せっけいしょ？？いきなりシステムの設計書なんて無理では？」
と怖気づきましたが、プロジェクトリーダー曰く目的や対象を整理するメモ程度でOKとのこと。
なるほどそれなら、と書いてみて出来上がったものはこちら。
Difyワークフロー設計書
こんなメモ書きが果たして設計書と呼べるのかと疑心暗鬼だったのですが、これが意外にも役に立つ。誰に向けて、何のために作るのかを文章に落とすことで、自分がぼんやり思っていたことがはじめて形になりました。
加えて、この設計書を人に見せると、初めて読む人にも意外と伝わりやすい。思考を可視化して共有するツールとしても使えたのです。
最初のつまずき：「質問の分岐」って必要？
設計書を眺めながら、最初に悩んだのが「質問の難易度によってナレッジを変えるべきか？」という疑問でした。
たとえば、「基本的な質問」と「応用的な質問」では、参照すべき資料やその粒度が異なるのではないか？であれば別のフローにして分岐させた方が良いのでは？と考えました。
ですが、いざ現場を思い返すと、新人時代は基本だろうが応用だろうが、どちらも等しく「よくわからない」ものです。新人時代、何気なく先輩に聞いた質問が応用的すぎて、課長まで巻き込んでしまったことを思い出しました。
つまり、職員の経験の有無、知識量だけで「基本／応用」を判定することはむずかしい。
そこで、すべての質問を同じフローで処理する設計に変更。属性による分岐を排除し、生成された回答をユーザーが必要に応じて噛み砕くスタイルにしました。
これは、現場経験があるからこそできた判断だと思っています。
ナレッジが偏る問題：Difyの“かたより癖”に悩む
次なる壁は、ナレッジの組み込み方。
今回格納するナレッジは以下の３つです。
- 根拠となる法令
- 1に関連して国や都道府県から発出される通達
- 実運用に関する質問をまとめたQA集
当初は、まず法令・通達・QA集を一つの知識取得ノードに入れて走らせてみました。
一つの知識取得ノードに入れてみる
それだけでもそれっぽい回答が生成されて個人的には感動したのですが、何回か試すうちに、出てくる答えが「QA集の内容ばかり」になってしまっていることに気づきました。
一つの知識取得ノードに複数のナレッジを含む場合、QA集がそのなかでもっとも平易で具体的な表現が多く、類似度検索で上位に来やすいためです。
ですが、現場の感覚としては、QAだけでなく関連する「通達」や「法令」も併せて確認することが必要です。
たとえば、
「この特例についてはこうやって事務処理を行う（＝QA集）」
→「〇月△日の通達にて特例適用が認められたことが示されている（＝通達）」
→「根拠は元の法律の第■条。ここで原則が定められている（＝法令）」
といったかたちです。
そこで、複数の知識取得ノードをパラレルで走らせて、最後に回答を統合する方式に変更しました。そして最後のLLMには「各ノードの内容を精査し、矛盾のない回答を生成せよ」と指示しました。
知識取得をパラレルで走らせる
これにより、具体的な運用方法と根拠をセットで回答に示すという、より現場でのやり方に近い方法が叶いました。
チャンク問題：意味の「かたまり」ってどう作る？
そして最も苦戦したのは、「文書の分け方（＝チャンク分け）」です。
Difyには、文書を自動でチャンク分けして取り込める機能があります。その際は区切り文字や指定の字数で指定ができるのですが、
- そもそも法令に区切り文字はない
- 字数で区切ると条文の途中で切れてしまったり、QA集のQAが別チャンクになる
- かと言って字数を長めに取ると１つのチャンクに問いと答えが２セット入ってしまう
これでは意味単位での検索ができず、RAGの精度が落ちます。
良い方法はないかとネットで調べたり、専門職の方に尋ねたりした結果、やはりナレッジはデフォルトのチャンク分けではなくきちんと構造化することが好ましいことがわかりました。そのためにはQAや条文を「問い＋答え」「条単位」などに分割し、CSVとして取り扱えばよいそうです。
さて、COUNTIF関数しか使えないわたしにとってこれはかなりの難問でした。手作業でコピペしてCSV形式にすることがよぎりましたが、それではいくら時間があっても足りませんし、何よりDXを標榜している団体なのに手作業コピペはさすがにダサすぎる…！
良策が一向に思いつかない日々のなか、救いの手を差し伸べてくれたのが別事業のエンジニアでした。世間話のついでにこの悩みをこぼしたところ、「マクロを使えば良いのでは？」とのアドバイス。
くわしく聞けばむしろそういったパターンが決まっている反復処理は、プログラミングで自動化するのが向いているようです。もちろん、ひとりでは到底できなかったので、エンジニアに手助けしていただきながら試行錯誤した結果がこちら。
一例です。A列に章番号、B列に章名、C列に条番号、D列に条文名、E列に項、F列に号、G列に本文が記載されています。
元の法令文はただのテキストデータですが、VBAで「条」「項」「号」など見出しを元にブロックを分割しその内容部分を抽出することで項目ごとに整理しています。文書ごとに書式や見出しパターン、例えば使われる数字が漢数字、全角数字、半角数字など異なるため、通知形式・法令形式・FAQ形式など、それぞれの表記仕様に合わせて処理ロジックを分けています。表記仕様に合わせてロジックを分けるのはかなり骨の折れる作業でしたが、こうすることによって、今後の改正時にも対応しやすくなったと思います。
10種類近くのてんでバラバラ形式の文書がこのように一律で美しく構造化されました。
新しいツールや技術を追いかけるのも大事ですが、それらは既存のツールと組み合わせてこそさらに便利になる。今まで四則演算くらいにしか使っていなかったExcelをちゃんと使いこなせるようになりたい…と決意した瞬間でした。
開発だけじゃなく、問い直しの連続だった
こうして振り返ると「Difyを触ること」も大変ではありましたが、より役に立つものを作るために、
- 現場の判断はどういうフローだったのか？
- それは他者にとっても合理的なのか？
- AIにどう指示すれば再現できるのか？
ということを心がけ、一歩進むごとに自分に問い直す必要がありました。
まるで、自分がこれまで当たり前にやってきた「調べる」という行為を一度バラバラにして再構築するような、不思議な作業でした。
未だプロトタイプは発展途上。現在ユーザーテストを実施しているところですが、現場の方の忌憚のない意見を受けて日々改善中です。
自分がその事業に携わっていたときにこれが無かった悔しさは脇に置いておいて、新しく着任する方々が苦労のないように、お役に立てるプロダクトを目指していきたいと思っています。
現場職員が自分でプロダクトを作ることの意義
区役所の職員を始めとする地方公務員は、数年たてば慣れ親しんだ部署から異動になります。公務員の異動は転職並みと言われるくらい、異動の前後ではまったく違う業務を担うこともあります。わたしも福祉部から教育委員会へ、教育委員会からGovTech東京へ異動になったときは、今まで培ってきた知識がなんの役にも立たなくて戸惑いました。
なぜそんな異動を繰り返すのかと言えば、一般的に地方公務員の事務職は「スペシャリスト」ではなく「ゼネラリスト」を目指すべきとされるからです。なので、専門的なことは専門家へ依頼するのが定石です。これまでシステムはシステムベンダーにまるっとお任せというのが当たり前でした。
しかし生成AIやノーコード・ローコードツールの登場で、状況は大きく変わりました。素人のわたしでも法令検索AIチャットボットのプロトタイプを形にできたように、専門家に丸投げしなくても現場の自分たちの手で形作れる時代になったと思います。さすがにベンダーさんにお願いするような大規模なシステムを作ることは難しいですが、それでは解決しないちまちました面倒ごとが日々の業務の中にはあふれています。みなさんの周りでもきっとそうだと思います。
これは単なる効率化にとどまりません。現場の人間だからこそ知っている、本当に欲しい機能、より実務で使えるプロダクトが実現できる。これこそが真の業務改善と言えると思います。
ぜひ多くの方に「現場職員自ら作る」ことを試してみてほしい。意外と面白いかもしれないから。
――それが、このプロジェクトを通じて一番感じたことです。
衝撃の事実が発覚
さて、ある程度のプロトタイプが完成したところで、いざ設計開発フェーズへ！
ここからは同じプロジェクトチーム内のishigeさんにバトンタッチし、API連携を試すことになりました。
ですが、このときのわたしはまだ知りませんでした。衝撃の事実が待ち受けていることに…（後編へつづく）
東京都が設立した外郭団体「GovTech東京」のテックブログです。GovTech（ガブテック）は、Government×Technologyの融合させた言葉。このブログでは、行政DXへの技術的挑戦、現場で得た知見、そして組織のカルチャーを発信していきます。govtechtokyo.or.jp
Discussion