行政と技術の融合を目指して—法令Deep ResearchツールLawsyの開発記録

こんにちは！普段は国家公務員として勤務しつつ、PolicyGarage（ポリガレ）でデータ分析やAIを担当している鈴木宏和です。デジタル庁が主催した「法令」×「デジタル」ハッカソンに出場し、最優秀賞を受賞しました！

このハッカソンでは、法令調査業務を支援する法令特化型のDeep Researchツール「Lawsy」を開発し、OSS（オープンソースソフトウェア）として公開しました。Lawsyは、民間事業者・公務員・政治家の皆さんが、より効率的に法令を調査できるようにするためのツールです。

今回のプロジェクトはポリガレの活動ではなく、友人の白川達也さん、神代洋明さんと私の3人で取り組みました。しかし、多くの行政関係者に知ってもらいたいという思いから、ポリガレの場を借りて発信させていただきます。

以下ではLawsyの開発記録を私の目線から紹介していきたいと思います。なお、技術面を中心に開発メンバーの白川さんもnoteで記事を公開していますので、合わせてご覧ください。

Lawsyとは？

Lawsyは、法令に詳しくない人でも簡単に法令の論点を調査できる法令特化型Deep Researchツールです。Law＋Easyで、法令業務を楽にしたいという想いから名付けました。

プロダクトとしては、例えば、「AIで遠隔医療サポート。症状の提案は医療行為？」と入力すると、Webや法令情報をもとにレポートを自動生成します。

すると、約1分で以下のようなレポートが生成されます。

検索の対象にはe-govのすべての法令データのほか、Web情報も含まれています。Webからの情報を取り込むことで、法令情報を政策・判例・国会などの関連情報と統合しつつ、情報収集・整理・解説を容易にすることが可能になります。

また、デジタル公共財とすべく、MITライセンスでLawsyをOSS公開することにしました。皆さんで自由に活用いただき、法令×デジタルのコミュニティ活性の一助になればと思っています。

せっかく参加するなら志高く

ハッカソンのテーマは「法令等データとAI等のテクノロジーを活用した作品の開発」で、具体的には、「法制事務の効率化」、「法令等データの整備、社会への提供」、「法令等データの利活用促進、ビジネス創出」の3つの方向性が提示されていました。

我々のチームには、「せっかく参加するなら、政府の基幹システムとして採用されるものを作りたい」という想いがありました。実は、ちょうどその頃、知人でもある情報処理推進機構の登大遊さんのプレゼンを聞き、特に以下の言葉に感銘を受けました。今回のハッカソンは行政課題の解決に資するだと思い、謎に志高く取組むことにしました。

プロダクト設計

課題の洗い出し

プロダクト設計のために、デジタル庁が示した3つの方向性を念頭に置きつつ、まずは法令の利用者の課題を把握するところからはじめました。国家公務員、地方公務員、弁護士、大企業、ベンチャー企業、政治家など法令業務に関連する方にヒアリングを実施。課題は以下のようなものでした。

• 公務員：法令・条例改正では法令の適用範囲や関係性の調査が大変。また、一般的な政策立案時にも法令調査が必要だが、調査作業が大変。特にDX推進が叫ばれる中、法令・条例の改正もセットで検討されることが多く、今後も作業が増加見込み。

• 弁護士：法令調査の際、読むべきドキュメント（法令、解説本、判例等）が多く、整理するのが大変。

• 企業：新規事業の企画時に、どの法令が関係するか調査するのに時間とコストがかかる。専門家に依頼するのも一苦労。

• 政治家：市民からの要望に対し、どの法令・条例が障壁になっているかの特定・対応可否を即座に判断できない。

これらを整理し、法令調査＝情報収集・整理には手間・時間・コストがかかるという共通の課題が浮かび上がりました。

プロトタイピングとイテレーション

共通課題に対して、RAG（Retrieval-Augmented Generation）を活用できるのではと考え、ハッカソンの割と早い段階で白川さんに法令をベクトルデータベースにした簡単なRAGのプロトタイプを実装してもらいました。

このプロトタイプを試してみると、法令担当の公務員や弁護士が行うレベルの法令調査には、ハッカソン期間内では到達できないのではないかという課題が見えてきました。そこで、ペルソナを「法令の専門家ではない人」に絞ることにしました。具体的には、法令担当外の一般公務員、民間企業の事業担当者、政治家で、これらの人々が、専門家の手を借りなくても法令調査をスムーズにできるツールを目指しました。

プロトタイピングとイテレーションを繰り返すことで、「専門家に依存せずとも、適切な法令やその周辺の情報収集・整理・解説を可能にすることで、法令調査業務の効率化させる」というプロダクトの方向性が明確に定まりました。開発の初期段階でこの方針を固められたことで、以後の開発がスムーズに進みました。

プロダクト開発

先行事例研究

RAGを活用した法令リサーチツールを開発することを決定しましたが、既にPerplexityやFeloなど、LLMを活用した高度なリサーチツールが存在しています。そのため、差別化を図るためにも、まずは既存のプロダクトを徹底的に試し、Lawsyに必要な機能を明確にすることから始めました。

特に参考にしたのが、スタンフォード大学が開発した「STORM」 というOSSのリサーチツールです。STORMは、ユーザーのクエリーに基づいて、Wikipedia風の記事を自動生成するLLMベースのシステムで、質の高いレポートを生成できる点が特徴です。

STORM では以下のような流れで記事を作成します。

1. ユーザーから与えられたクエリーを展開

2. 記事執筆者のペルソナを複数生成

3. ペルソナ役とナレッジエキスパート役に分かれ、対話を行いながら、情報を収集

4. 収集された情報からアウトラインを生成

5. 記事のドラフトを作成

6. ドラフトにリード文をつけ推敲

なお、STORMではDSPyが使用されています。

ワークフローの構築

STORMをベースにしつつ、法令検索に特化し、より軽量で素早く結果を得られる検索体験を目指しました。開発期間後半にChatGPTやPerplexity等でDeep Researchが公開され始めたこととの差別化という意味合いもあります。このため、Lawsyでは以下のワークフローを採用しました。

1. ユーザーから与えられたクエリーをWeb検索用に最適化

2. 最適化されたクエリーを用いてWeb検索（ドメイン指定なし＆ドメイン指定あり）

3. Web検索結果をもとにクエリーを展開

4. 各クエリーに対して法令ベクトル検索

5. Web検索結果と法令ベクトル検索結果をリランキング

6. 引用する文献を整理しながらアウトライン生成（タイトル、セクション、サブセクション）

7. サブセクションの内容を記載

8. 結論の生成

9. リード文の生成

STORMのアプローチを応用しつつ、Lawsyでは検索の軽量化と法令特化型の情報整理に重点を置きました。特に、レポート生成に時間がかかるSTORMに対し、Lawsyでは検索対象を法令データ＋信頼性の高いWeb情報に絞ることで、より素早く、精度の高い検索体験を提供することを目指しました。

なお、ハッカソンの本番用の LLM には OpenAI の GPT-4o を使いました。GPT-4o-mini でも割と安定的にレポート生成できることは確認しています。

次のセクションでは、Lawsyの各ワークフローの詳細について紹介します。

1. ユーザーから与えられたクエリーをWeb検索用に最適化

試作段階では、ChatGPTのような感覚で長文のクエリーを入力してしまい、Web検索の上限に引っかかるという問題が発生しました。例えば、Tavilyでは最大400文字の制限があり、それを超えると検索できません。この問題を解決するため、クエリーを簡潔にしつつ、検索精度を落とさないようにする最適化ワークフローを導入しました。

class RefineQuery(dspy.Signature):
    """
    あなたはWebの扱いに長けた優秀な法律家です。
    下記のユーザーのクエリーにたいして、法令観点からの回答を与えてくれそうな簡潔なクエリーを一つ作ってください。
    なお、作成にあたっては下記を守って下さい。

    - 法令観点からの回答を与えてくれそうなクエリーをつくること
    - あなたの作ったクエリーは可能な限りユーザーが作ったクエリーの意図と過不足なく一致させること
    - クエリーは日本語で作成すること
    - Web検索に最適化すること
    - 簡潔であること
    """

    query = dspy.InputField(desc="ユーザーのクエリー", format=str)
    refined_query = dspy.OutputField(desc="あなたの作成したクエリー", format=str)

例えば、以下のように変換されます

2. 最適化されたクエリーを用いてWeb検索

最適化したクエリーを使い、Web検索を実施して最新情報を取得します。この際、ドメイン指定あり/なしの両方の検索を組み合わせることで、精度と鮮度の両方を確保しました。なお、指定するドメインはConfigページで修正可能です。

ドメイン指定なしの検索（一般Web検索）
・メリット：最新のニュースや技術的な解説を取得できる
・例：八潮市道路陥没事故など、新しい事例の検索に対応

ドメイン指定ありの検索（政府・国会・裁判所サイト等）
・メリット：公式情報や信頼性の高い政策情報を取得できる
・使用するドメイン：
　　go.jp（中央省庁・政府機関） → 法令や政策情報
　　shugiin.go.jp / sangiin.go.jp（国会） → 審議情報
　　courts.go.jp（裁判所） → 判例情報

これまで公務員として勤務してきた経験から、「go.jp」ドメインで公表する情報は、高い品質が求められることを実感しています。誤りがあってはならないという意識のもと、厳格なチェックを経て公開される情報は、政策や法令を理解する上で非常に信頼性が高いものです。Lawsyでは、こうした政府機関の日々の取組みに支えられた質の高い情報を活用することで、精度の高いレポート生成を実現しています。

また、ドメイン指定検索を導入したことで、信頼性の高い情報ソースを効率的に取得できるだけでなく、検索時間も大幅に短縮できました。テクノロジーだけではなく、実務経験に基づく「どの情報を信頼すべきか」の知識と組み合わせることで、より実用的なプロダクトを作れると改めて感じました。

3. Web検索結果をもとに、クエリーを展開

ユーザーが入力したクエリーを、そのまま法令検索にかけるだけでは十分な精度が得られません。そのため、得られたWeb検索結果をもとに、関連するリサーチトピックを抽出し、法令検索向けのキーワードを展開します。

ポイントとしては、ユーザーの意図をより深く反映ためにリサーチすべきトピックを増やす、法令で使われる専門用語に置き換えることで検索精度を向上させるために法令用語に変換させるという点にあります。

class GenerateDetailedTopics(dspy.Signature):
    """あなたは日本の法令に精通した専門家です。
    下記のクエリーに関して、事前にWeb検索をして簡単に下調べしてあります。
    Web検索結果もふまえ、クエリーに関する法令の解説・解釈文書を作成するために必要な法令を検索しようとしています。
    法令検索はセマンティックサーチできるのでキーワード・短文などで検索可能です。

    解説・解釈に必要な法令を適切にヒットさせきるための検索トピックを以下の形式でリストアップしてください。

    出力フォーマット：
    - xxx
    - yyy
    - ...
    - zzz

    検索トピックをリストアップするにあたり、以下の条件を遵守してください。

    - クエリーの意味を十分汲み取ること
    - クエリーに対する法令解説・解釈を行うのに必要な法令が揃うように検索トピックをリストアップしてください
    - 一般的な用語は法令での専門用語を優先してください。法令用語が含まれていない場合は、該当しそうな法令用語や関連用語を補完してください
    - 検索トピックは可能な限り互いに重複せず、個別に調査可能な形にしてください。 **self-contained** であるべきです
    - 検索トピックは法令コーパスに準拠した具体的なものにしてください（短文または具体的な法令用語）
    - 検索精度を高めるため、法令での使用が想定される具体的な専門用語や関連する条文番号を含めてください
    - 検索トピックをナンバリングする必要はありません。検索トピックの内容のみ記載してください
    - 検索トピックの個数は多くても10個までにしてください。多ければよいというわけではないです
    """  

    query = dspy.InputField(desc="クエリー", format=str)
    web_search_results = dspy.InputField(desc="Web検索結果", format=str)
    topics = dspy.OutputField(desc="リストアップされた検索トピック", format=str)

例えば、「AIで遠隔医療サポート。症状の提案は医療行為？」というクエリーの場合は、以下のような展開が行われます。

4. 各クエリーに対して法令ベクトル検索

法令のベクトル検索を実行するにあたり、法令のXMLデータはそのままでは扱いにくく、ベクトル検索に適した形式に変換する必要がありました。この処理には多くの課題がありましたが、開発メンバーの白川さんの尽力により、スムーズに検索できる形に整えることができました（デジタル庁から法令のベクトル検索用のデータベースなどが提供されていれば車輪の再発明を行わず、もっと柔軟なプロダクト開発ができたのではと思いましたが…）。

特に判断が難しかったのはチャンク化です。条文ごとに区切ると文脈が失われ、逆に法令全体を1つの単位にすると長すぎて処理が困難になります。そこで、文脈を保持しながらも適切な長さを維持できるよう、法令の構造を考慮してチャンクを作成しました。この調整により、検索の精度を保ちつつ、効率的に情報を取得できるようになりました。

金融商品取引法
  本則
    第一章　総則
      第一条 （目的）
      この法律は、企業内容等の開示の制度を整備するとともに、金融商品取引業を行う者に関し必要な事項を定め、金融商品取引所の適切な運営を確保すること等により、有価証券の発行及び金融商品等の取引等を公正にし、有価証券の流通を円滑にするほか、資本市場の機能の十全な発揮による金融商品等の公正な価格形成等を図り、もつて国民経済の健全な発展及び投資者の保護に資することを目的とする。

なお、今回は使用しませんでしたが、法令XMLのパーサーにはLawtextのようなものもあり、法令×デジタル分野が先人たちの積み上げによってここまで来ているということを実感しました。

5. Web検索と法令ベクトル検索の結果をリランキング

Web検索と法令ベクトル検索で取得した情報を、より関連性の高いものが上位に来るように再整理します。Web検索のスニペットはリアルタイムでベクトル化し、クエリーとの類似度を計算。法令検索の結果も同様に処理し、最も適切な情報を優先的に表示できるよう調整しました。このリランキングにより、必要な情報を効率よく取得できる仕組みを実現しました。

以下の内容に関する法令解説文書を作るにあたって参考になるWebページや法令がほしい

主題となるクエリー:  {{入力クエリー}}
関連するトピック: {{展開されたトピック}}

6. アウトライン生成

プロトタイプでは、取得した情報をそのまま使って記事を生成していましたが、この方法では長文のレポートを作れず、参照する情報に偏りが出るという問題がありました。そこで、STORMの手法を参考にアウトライン生成のレイヤーを挟んだところ、情報の整理がスムーズになり、より質の高いレポートが作成可能になりました。

特に、アウトライン生成のプロンプト設計は、記事の精度や内容を大きく左右する重要な部分です。どのように情報を引用するか、どう整理するかを細かく調整することで、適切な構成と内容を実現しました。

考えてみれば、私も資料を作るときも、いきなり文章を書き始めるのではなく、まず構成を決めていきます。AIにもこのプロセスを取り入れることで、より自然な流れのレポートを生成できるようになりました。

class CreateOutline(dspy.Signature):
    """あなたは、ニュースを常にフォローしつつ、日本の法令に精通している専門家です。収集された情報源をもとに、下記のクエリーに対するレポートとして適切なアウトラインと簡潔なタイトルを作成してください。また、最後にレポートのタイトルを作成してください。結論パートは絶対に作成しないでください。

    アウトラインは以下のMarkdownフォーマットに従って作成し、次のルールを厳守すること。
    1. クエリーに対して、法令観点での解説・解釈を含む回答を目的とした構成にする。
    2. "# Title" をレポートのタイトルに用いる。
    3. "## Title" をセクションのタイトルとして用いる。
       - 各セクション ("## Title") に対して、必ず2～3個以上のサブセクション ("### Title") を生成すること
       - セクション数はクエリーに応じて5～20個の間で作成すること。網羅的な回答が必要な場合、セクション数は多い方が好ましい
    4. "### Title" をサブセクションのタイトルとして用いる。
       - 各サブセクションには、収集された情報源をできるだけ多く含めるようにし、必ず最低3～5個以上の異なる引用番号を使用すること
       - サブセクション同士で内容が類似しそうな場合（情報源の法令・条文が同じ、タイトルが酷似）、サブセクションは統合し、他の論点のサブセクションを追加すること
       - サブセクションの引用番号が他と重複する場合、より多様な情報源を取り入れるために、アウトライン全体を統合・再編成すること
       - 必要に応じて、さらに下位の階層も同様に2つ以上生成すること。
    5. 引用情報の記載方法
       - 今後必要となるので、"### Title"のサブセクションタイトル作成の際には参照した条文の引用番号を記載
       - 引用番号はサブセクションの次の行に記載すること。セクション、サブセクションの行には引用番号はつけない。
       - "### Title [3][4]" のように同じ行に引用番号を記載してはならない
    6. Markdownフォーマットに関するルール
       - "## 結論"という結論パートは絶対に作成してはいけない
       - 出力には "# Title", "## Title"、"### Title"、"#### Title" などのMarkdown形式のタイトル以外のテキストを一切含めないこと
       - "#### Title"というサブサブセクションは作成しないこと
       - ナンバリングは不要
       - "#", "##", "###" の階層のみ作成すること
    7. 各行はタイトル、セクション、サブセクション、引用番号のいずれかでそれ以外の情報を記載してはならない

    【出力例】
    # レポートタイトル
    ## セクション1
    ### サブセクション1
    [4][67]
    ### サブセクション2
    [30][28][1][27][102]
    ## セクション2
    ### サブセクション1
    [14][25][9][96]
    ### サブセクション2
    [2][24][51]
    ### サブセクション3
    [29][11][4][56]
    ...

    【不適切な出力例】
    # レポートタイトル: xxx    // 「レポートタイトル: 」という修飾はNG
    ## セクション1
    ### サブセクション1 [4][67]    // 引用はサブセクションの行にはつけない
    [4][67]
    このサブセクションでは...    // 説明文など要求していない不要な行は削除
    ### サブセクション2 [30][28][1][27][102]    // 同上
    [30][28][1][27][102]
    ## セクション2
    [2][24][29][11][4]    // セクション自体に引用がついている
    ### サブセクション1
    ### サブセクション: yyy    // 「サブセクション: 」という修飾はNG
    [2][24][51]
    ### サブセクション3
    [29][11][4][156]     // （引用が例えば110までしかない場合）156は存在しない引用
    """

7. サブセクションの内容を記載

各サブセクションごとに独立して文面を生成します。Lawsyでは並行処理でストリーム生成を行い、アウトラインの段階で指定された情報だけを参照することで、無駄な処理を削減しました。この方法により、生成プロセスの軽量化と高速化を実現し、短時間で質の高いレポートを作成できるようになりました。

class WriteSection(dspy.Signature):
    """あなたは日本の法令に精通し、適切な法令解釈を行い、分かりやすい解説を書くことに定評のある信頼できる粘り強いライターです。
    下記のクエリーに関する調査をしており、クエリーをもとにレポートのアウトラインを作成しました。
    アウトラインの中にある引用番号は漏れることなく必ず参照し、収集された情報源の内容を適切に解釈しながら各セクションの内容を記載してください。必ず各サブセクションごとに400字以上記載してください。
    解説は緻密かつ包括的で情報量が多く、情報源に基づいたものであることが望ましいです。法令に詳しくない人向けにわかりやすくかみ砕いて説明することも重要です。必要に応じて、用いている法令の概要、関連法規、適切な事例、歴史的背景、最新の判例などを盛り込んでください。
    なお、内容の信頼性が重要なので、必ず情報源にあたり、下記指示にあるように引用をするのを忘れないで下さい。
    1. アウトラインの"# Title"、"## Title"、"### Title"のタイトルは変更しないでください。
    2. 必ず情報源の情報に基づき記載し、ハルシネーションに気をつけること。
       記載の根拠となる参照すべき情報源は "...です[4][1][27]。" "...ます[21][9]。" のように明示。
       その記述に対しての関連性が高そうな順に付与してください。
    3. 正しく引用を明示されているほどあなたの解説は高く評価されます。
       引用なしの創作は論拠が明確でない限り全く評価されません。
    4. 情報源を解説の末尾に含める必要はありません。
    5. 日本語のですます調で解説を書いてください。
    6. 引用は文面を引用する論理的な必要性がない限り、引用番号の引用のみにしてください。
    7. 「収集された情報源と引用番号」にない番号を引用しないでください。それは創作になってしまい価値を既存します。
    """

    query = dspy.InputField(desc="クエリー", format=str)
    references = dspy.InputField(desc="収集された情報源と引用番号", format=str)
    section_outline = dspy.InputField(desc="セクションのアウトライン", format=str)
    section = dspy.OutputField(desc="生成されたセクション", format=str)

8. 結論の生成

各サブセクションで作成した文面をもとに、全体をまとめる結論を生成します。ここでは、単なる要約にとどまらず、今後の展望や対応策も含めた総括を行うことで、レポートとしての価値を高めるようにしました。

class WriteConclusion(dspy.Signature):
    """あなたは日本の法令に精通し、分かりやすい解説を書くことに定評のある信頼できるライターです。
    レポートのドラフトを踏まえて、レポート全体の要約を本文とはできるだけ異なる表現で記載しつつ、今後の方向性や対応策を含んだ結論部の中身を生成します。
    最低でも400字以上、可能なら600字以上記載してください。
    結論の文章部分のみ生成し、"## 結論" のようなヘッダは入れないでください。
    """

    query = dspy.InputField(desc="クエリー", format=str)
    report_draft = dspy.InputField(desc="レポートのドラフト", format=str)
    conclusion = dspy.OutputField(desc="生成された結論", format=str)

9. リード文の生成

最後に、レポート全体の要点を簡潔にまとめたリード文を作成します。ワークフローの最終段階でリード文を生成することで、最初に読むだけでレポートの内容が一目で把握できるようにしました。

class WriteLead(dspy.Signature):
    """あなたは日本の法令に精通し、分かりやすい解説を書くことに定評のある信頼できるライターです。
    下記のクエリーに関する調査をしており、レポートを作成しました。レポートタイトルの直後に表示する簡潔なリード文を生成してください。
    リード文とは、レポート全体のabstractとなる、レポート全体の論旨の展開や主要トピックを含めた簡潔な文章です。

    リード文の生成にあたって次のルールを厳守すること
    - リード文では、レポート全体の文脈やレポートで扱われている主要なトピックに対する簡潔な概要を提示し、それ単独でも読める内容にすること
    - リード文の文字数は140〜280文字程度とすること
    - リード文の文面のみ生成すること。
    """

    query = dspy.InputField(desc="クエリー", format=str)
    title = dspy.InputField(desc="レポートのタイトル", format=str)
    draft = dspy.InputField(desc="レポート内容", format=str)
    lead = dspy.OutputField(desc="リード文の文面", format=str)

UI・UXでの工夫

マインドマップで全体を把握しやすく

Deep Researchツールの課題として、レポートが長すぎて全体像を把握しづらいという問題があるのかなと思います。これを解決するために、Lawsyではレポート冒頭にマインドマップ形式でセクションとサブセクションのタイトルを掲載しました。視覚的に整理されることで、レポートの構造が一目でわかり、読者の負担を軽減できます。また、色を取り入れることで、見た目の印象も向上しました。

引用情報の即時表示

レポートの最後に引用情報をまとめて表示する仕様にすると、本文と引用を行き来する手間が発生してしまいます。そこで、引用番号にマウスを重ねると、引用元情報がその場で表示されるツールチップ機能を実装しました。これにより、スムーズに情報を確認できるようになり、リサーチの効率も向上しました。

デザインの最適化

フロントエンドの専門メンバーがいなかったため、streamlitをベースにCSSで可能な範囲で調整しました。今回はデジタル庁のデザインシステムを読み込み、フォント、フォントサイズ、行間、ハイパーリンクの色など、視認性を考慮したデザインを適用し、長文のレポートを快適に読めるような工夫を重ねました。なお、デザインシステムを実装するのが難しく、四苦八苦しながら進めていましたが、とあるデザイナーからデザイン語を読めるようになったんですねと言われたときは嬉しかったです。

ロゴの作成

プロダクトとしての完成度を高めるため、ロゴも重要な要素だと考えました。当初はAIでロゴを自動生成できるツールがあるのでは？と思いましたが、意外にも適切なものが見つからず、自分で試行錯誤しながら作成しました。

行政ドメインと技術の融合を目指して

今回の開発で特に良かったのは、ドメイン知識と技術がうまく噛み合ったことだと思っています。技術があればすべての課題が解決するわけではなく、業務フローに即した技術の実装が必要になります。逆に、どれほど優れたドメイン知識があっても、適切な技術がなければ解決できない問題もあります。Lawsyの開発では、この両者がぴったりと噛み合い、プロダクトの改善につながった瞬間が何度もありました。

最先端の技術に熟知している白川さんと、フロント含めてなんでも拾ってくれる神代さんがいたのは本当によく、私も気兼ねなく実務での課題や改善点を投げることができました。その際、私自身もコーディングをしてプロトタイプを作るなどし、極力技術的に不可能でないことは投げないようにも心掛けました。論文やGitHubコードを楽しいと言いながら、消化し実装していけるメンバーで本当に勉強にもなりました。

また、開発中のプロダクトを実際の業務で試し、同僚からフィードバックを得ながらPDCAサイクルを短期間で回し続けたことも、大きな成果の一つです。Lawsyを試した方々からは、「霞が関の業務経験を根本から変える可能性がある」、「ゼロから法令を勉強する手間がなくなるのでありがたい」といった、非常に前向きな評価をいただきました。プロダクトが実務から乖離していないという手応えとともに、開発を続ける励みになりました。

行政におけるAI活用は以前から注目されていますが、業務特有の専門知識が不可欠なため、単に委託や外部人材の活用だけでは十分に進めることが難しい領域です。そのため、行政官とエンジニアが互いに歩み寄り、共通言語を持つことが重要になります。特に、行政用語と技術用語を橋渡しできる人材の発掘・育成が、今後の行政DXを進めるうえで欠かせないと感じています。これは行政でのAI活用だけでなく、EBPMや幅広くデータ利活用といった分野でも当てはまると考えています。今回の取り組みは、その可能性を示す良い事例となったかと思います。

また、今回のハッカソンを通じて得られた学びやつながりが、単発のイベントに終わるのではなく、コミュニティとして継続的に成長していってほしいと強く思います。法令分野に限らず、他の行政領域でも同様の取り組みが広がっていくことを期待しています。

最後に、行政のデジタル化、EBPMやデータ利活用に少しでもご関心のある方がいらっしゃれば、ポリガレまでご連絡いただければ幸いです。日本の行政をもっとよくしていければ、公務員が楽しく働けるようになればと思っています。

PolicyGarage研究会でのプレゼン資料

2025年4月9日にPolicyGarage研究会でプレゼンを行いましたので、その際の資料をアップします。