「法令」×「デジタル」ハッカソン参加記録＆優秀賞受賞アプリのアーキテクチャ解説
こんにちは。エヌデーデーの金子です。
2025年2月5日から3月6日に開催されたデジタル庁主催の「法令」×「デジタル」ハッカソンに、弊社のチームで参加をしてきました。
ハッカソン初参加のメンバも多い中、山あり谷あり奮闘の1か月を過ごし、結果優秀賞を受賞することができました。
「まさか自分たちが！？」と、授賞式で名前を呼ばれたときに衝撃を受けたのはよく覚えています。
私たちは今回弁護士業務を支援する「リーガルカメラアシスタント」というサービスを作成しました。
本ブログではハッカソン1か月のリアルな進め方と、開発したサービスの概要の2点を綴っていきます。
これからハッカソン参加を考えている方の背中を後押しできるような記事になればと思います。
ハッカソンの取り組みと進め方
ハッカソン概要
本ハッカソンのテーマは「デジタル庁が提供する法令等データとAI等テクノロジーを活用した作品」でした。
デジタル庁が提供している法令の検索・閲覧システムであるe-Gov法令検索、法令を構造化形式で扱える法令XML、法令データ取得及び検索が行える法令APIなどを駆使して、新しいサービスを考えていきます。
日程はこのような形で進みました。
1月20日 申し込み締め切り
2月5日 イベント説明・ワークショップ
2月10日 デジタル庁職員等と相談
2月下旬 成果物提出締め切り
3月6日 結果発表
チーム編成・準備
私たちは今回5人のチームで参加しました。その全員がエンジニアです。
通常業務と並行して行うので、ハッカソンの作業時間は通常業務の隙間を縫って行っていました。
（結果日中帯は1人しかまともに作業時間が確保できていませんでしたが。。恐らく大半のチームはそんなものだろうと思います。お疲れさまでした。）
さてこのチーム、1つ問題がありました。
それは誰一人「法令にタッチした業務に深く携わっている者がいない」ということです。
法令に関する業務を行う企業と仕事をしているメンバはいましたが、やっていることはシステム周りの仕事なので、どうしてもその先のリアルな法令を活用している業務は見えづらいんですよね。
そのため、「法令って色々種類あるけどどう違うの？」という前提知識や、「法令を使ってどんな業務がされているの？」という業務感がない状態でスタートしました。
前者の法令知識は勉強会を開くことも検討しましたが、「各々調べましょう」といった形でひとまず進めました。
後者に関しては、「法令関連業務で困っていることはないか」「どんなサービスがあると嬉しいのか」といったところをチーム外および社外の人たちにヒアリングをしてネタ集めに奮戦することになります。
ネタ集め・アイディア出し
開発サービスを考えるにあたり、業務視点と技術視点の2軸でアイディア出しを行いました。
業務視点のアイディア例
- 「ここに荷物を置いてはいけない」「ここに設置してはダメ」等の消防法の点検の方曰く、全然守ってくれないお店にいちいち指摘するのは骨が折れる
- 竣工後の建物検査業務で、図面と建築物を照らし合わせて建築基準法違反がないかチェックできるといいかも
- 国会内閣提出法案によって変わる内容が業界ごとに見え、その影響をAIとかで予測する仕組みがあると便利？
- 薬事法や景品表示法のチェック業務を楽にしたい
- ライフプランを考える際に、国・行政・自治体からの支援・補助金がどれほど受けられるか一撃でわかると便利？
多方面の方々にヒアリングした甲斐もあって、業界ごとに沢山ネタがありそうだと分かりました。
技術視点のアイディア例
- e-Gov法令検索をセマンティック検索対応したようなサービス
- AIを使うにしても、テキスト入力でなくカメラや画面共有ができると便利
- 法令データをAIに勉強させて、法令に関して何でも聞けるAIモデルを作る
- 法令データの全量は膨大なので、ユーザによって扱う法令をカスタマイズできるような仕掛けを取り入れると便利かも
方向性としてはみんな「せっかくだしAI使いたいよね～」という方針で一致しました。
技術視点の議論では、最新のAI技術、特にマルチモーダルな入力への関心が高まりました。
ちょうどその頃、Google Cloudがマルチモーダル入力に対応したGoogle AI Studioを発表しており、画面共有しながら音声入力で仕事ができれば便利だし、AIに馴染みがない人でも使ってくれるのではないか、と話していました。
さてAIを使う上でネックとなったことは「既存のLLMサービスとの差別化」でした。
現在のChat GPTやGeminiは法令に関する質問をすれば、かなりの精度で正確な答えが返ってくるように感じました。例えば法令データをたくさん勉強させたAIモデルを作ったとして、「それ既存LLMでできるよね」となれば新サービスとして開発する意味があまりありません。この既存LLMサービスではできないことをどう見極めるか、というのがこの後も付きまとうことになります。
アイディアをサービスに昇華するうえでの壁
AIを使って業務視点の課題を解決できるサービスがあるか、それぞれを深堀していくにつれて、壁も見えてきました。
それは集めた課題や改善点の先で作るべきサービスを考えたときに、業務側の解像度が低いので「これが本当に使えるサービスになるのか」という判断が我々ではできないことです。
例えば消防法のチェックを楽にするために、「カメラで写した建造物内の映像で、消防法違反がないか教えてくれるサービス」を作るとします。これには以下のような問題がありました。
- 消防法違反にあたるかどうか判断するには、建物自体の情報（用途・規模・構造や建築図面など）が必要である
- e-Govで取得可能な消防法は概要的な記載にとどまり、詳細なチェック内容は別途公開されているガイドラインが必要
これらを考慮したサービスとする場合、「建物自体の情報とガイドラインをどこまで入れてどんなアウトプットをすればサービスとして実用的なのか」を判断するにはどうしたって現場の意見が必要でした。
今業務で困っていること・便利になったらいいなと思うこと は他業界でもある程度短時間で外部から調達ができます。
しかしハッカソン期間中にサービスとして昇華するには現場の意見を密なコミュニケーションで取り入れる必要があるなと感じました。
ここに行き詰まり、我々のチームは頭を抱えてしまうことになります。
開発するサービスの確定
なんとなく「画面共有やカメラの情報から法令に関する何かをアウトプットするサービス」を思い描きながら、2月5日のワークショップを迎えました。
デジタル庁のAI活用した条文案生成の取り組みなどが説明され、やはりAIへの関心が高まっていることが伺えます。
ワークショップでは実際に弁護士を経験しているデジタル庁職員さん（以下、Yさん）に話を聞くことができました。
ここでYさんが画面共有を使ったAIサービス、という1案に関心を示してくれて、「実際に弁護士業務であったら嬉しいかも！」と話が進んでいくことになります。
我々は実際の法令業務担当者に直接話を聞くまたとない機会だったので、その場でターゲットを弁護士と仮決定して以下をYさんにヒアリングしました。
- 実際の弁護業務の流れとAIサポートができそうなタイミング
- 法令違反チェックをする場合、法令をチェックすればOKなシーンと告示やガイドラインでないと具体的なチェックはできないシーン
- 法令条文を詳しく調べるタイミング、法令検索と判例検索の使い分け
- 弁護士業界のAIサービス普及率
- 弁護士に届く依頼内容や依頼人からのヒアリング事項
- …
話を進めていくうちに「街弁護士が依頼人からヒアリングしたメモを共有することで、調べるべき法令条文へのリンクを提供するAIサービス」が以下の理由でいいだろう、と決定しました。
- 普段馴染みのない法令が関わる依頼は、どの条文を調べればいいか教えてくれると助かる
- 具体的な法令要件を確認するために最終的には条文そのものを確認したい
- 依頼人からのヒアリングを書き起こすメモは人によってWord・手書きなど様々であり映像によって解釈できるメリットが大きい
- 法令条文へのリンクは法令IDや条項番号を正確に取得する必要があり、これは法令APIを使用して実現可能であるうえ、ChatGPT等既存LLMへの単純な質問では対応しきれない領域である
確実にこの日が運命の分かれ道だったと思います。
予定されていた時間を終えても、残って相談に乗っていただいたYさんに最大限の感謝を！
開発したサービス：リーガルカメラアシスタント
ここからは実際に開発したサービスの内容や、技術的な課題を記載していきます。
サービス設計・開発
作りたいものも無事決まったので、ここから「どのように作っていくか？」というフェーズに入ります。
ここはエンジニアの腕の見せ所ですね。
作っていくサービスは下図のイメージです。
システム形式と開発言語
場所や端末を選ばず使いたいから、Webアプリケーションでブラウザで使用する形にします。
ランタイムはGoogle CloudのフルマネージドでサーバレスなコンテナプラットフォームであるCloud Runサービスを使いました。
開発言語は、UI構築に強みを持つReactをクライアント側で、API連携やバックエンド処理に豊富なライブラリを持つPythonをサーバー側で採用しました。
これは、ハッカソンメンバーのスキルセットを最大限に活かしつつ、それぞれの言語の特性が今回の要件に合致すると判断したためです。
また意外と悩みどころなんじゃないかと思うのが開発環境ですね。
ローカルに開発環境を立てるには、ハッカソンのスピード感では間に合わないことが多いのではないでしょうか。
私たちは今回Cloud Shell EditorというGoogle Cloud が提供しているオンラインでアクセス可能な開発環境を使用しました。Webブラウザ上で開発できgit連携も可能なので、セットアップに時間を取られず、すぐにコーディングに取り掛かます。
マルチモーダル入力
まず肝となる画面共有などのストリーミングデータをAIサービスに渡す部分ですが、
Gemini APIのMultimodal Live APIを使うことにしました。
WebSocketによる双方向通信でマルチモーダルな入力をサポートします。
githubで公開されているデモアプリをベースに開発を進めました。
このリポジトリは本当に手軽にマルチモーダルAIを扱えるので、非常に助かりました。
※Live API自体が2025年4月現在プレビュー版であり、同時接続可能なセッションが3つまで等制限事項がありますので、実運用するサービスで使用するうえでは注意が必要です。
関連条文の提案とリンク生成
メモの内容から関連条文を提案しURLを生成する機能は、以下のステップで処理イメージを作りました。
（※以降出現する法令APIのエンドポイントのインタフェースは、法令APIVersion2を参照ください。）
① メモから検索すべきキーワードをGeminiがピックアップ
② 法令APIのキーワード検索エンドポイントをコール
③ レスポンスからURLを生成しクライアントに返却
実際に弁護士さんもe-Gov法令検索を使用する際はキーワード検索を使っている、という所から着想を得ました。
またe-Gov法令検索の法令条文URLは「https://laws.e-gov.go.jp/law/{法令ID}#Mp-At_{条番号}」の形式でリンクできそうだ、とアタリを着けました。
（※公式でURLの仕様が明示されていたわけではないです。もしかしたら一部の法令にしか当てはまらないかもしれません。）
しかしこれには大きく以下2点の問題がありました。
問題① キーワード検索の精度
一つのキーワード（例えば"著作権"）で法令APIのキーワード検索エンドポイントを使うと、本来関係ない条文がたくさんヒットしてしまいます。
これを防ぐためにある程度キーワードを増やしてAND検索をかけると、今度は何もヒットしなくなります。
このようにキーワード検索はリクエストパラメータを調整するのが難しく、意図する条文をヒットさせるには途方もない時間がかかるな。。と感じました。
問題② キーワード検索のレスポンスに条番号がない
URLの生成には法令IDと条番号の2つの情報が必要です。
しかしキーワード検索のレスポンスパラメータには条番号がありませんでした。
法令IDだけでもリンク自体は動きますが、もちろん当該法令ページのTOPに遷移します。
これでは使い勝手がかなり悪くなってしまいます。
条番号をどのように取得するのか、というのを考える必要がありました。
最終的な形
これらの問題点をいろいろ勘案し、最終的には以下の形としました。
まず「何の法令を見るべきなのか」はGeminiにある程度任せることにしました。
システムプロンプトで適切な指示を書くことで、ある程度弁護士さんが実際に行っているような法令の特定を再現できるのではないか、と思ったからです。
また調べるべき法令名と法令IDのマッピングは法令一覧取得のエンドポイントをコールし、結果から判断するようにしました。
例えば「著作権法」と検索すると、以下のような結果が出てきます。
- 万国著作権条約の実施に伴う著作権法の特例に関する法律（ID：aaa）
- 万国著作権条約の実施に伴う著作権法の特例に関する法律施行令（ID：bbb）
- 著作権法（ID：ccc）
- 著作権法施行令（ID：ddd）
- …
このうち欲しいのは「ID：ccc」のものだ、というのはAIに判断させます。
これもe-Gov法令検索の結果から、弁護士さんが意図している対象を選ぶのと同じイメージですね。
条番号の取得は法令本文自体のXMLデータから、プログラムで検索キーワードがないか探しに行き、ヒットしたノードの条番号を取得するようにしています。
※ここは条や項のような情報が法令XMLからでないと取れないにつき、苦肉の策でした。今後キーワード検索でヒットした条文が何処の何なのか、ということがわかるとアプリ側で検索ロジックを持つ必要はなくなりますね。
GeminiのFunction Calling
これらの処理を実現する上で鍵となったのが、GeminiのFunction Calling（関数呼び出し）を活用しています。
これはGeminiに特定の関数を呼び出すためのJSON形式の要求を生成させる機能で、これにより、Geminiの自然言語処理能力と、アプリケーション側のAPI連携処理を柔軟に組み合わせることが可能になります。
今回の連携例を以下に記します。
この実装のメリットは、関数の具体的な実装をアプリケーション側で行えるため、柔軟なサービスを実現できる点にあります。
例）
ユーザの画面共有
↓
Gemini「法令名hogehogeで法令一覧取得APIをコールしてね」
※Function Calling要求①
↓
アプリ側でhogehogeで法令一覧取得APIをコールし、結果をGeminiに渡す
↓
Gemini「法令IDhogeの法令の中で、キーワードを含む条文の条番号を教えてね」
※Function Calling要求②
↓
アプリ側で法令IDhogeで法令本文取得APIをコールし、レスポンスの中をキーワードで検索し、条番号をGeminiに返す
システムプロンプト
設計通りにAIに仕事をさせるために、システムプロンプトを丁寧に作り込んでいく必要がありました。
特に、提供された情報から確認すべき法令名とキーワードを抽出させる際には、まるでベテラン弁護士の思考回路を再現するように、非常に具体的な指示を記述する必要がありました。
・相談内容が未払い残業に関する問題であるときは、「付加金」「労働時間適正把握義務」「割増賃金」「遅延利息」の情報を抑える。
・相談内容が労働基準法に関する問題である場合、労働基準施行規則も参考にすること。
・相談内容が開示請求に関する問題であるときは、「発信者情報の開示請求」「著作者人格権」「同一性保持権」「引用の目的」「公衆送信権」の情報を抑える。
...当初は、もっと抽象的な指示を試みたのですが、AIが的外れな法令やキーワードを抽出してしまうことが多く、実際の弁護士業務の流れや着眼点を詳細にプロンプトに落とし込む必要性を痛感しました。
しかしプロンプトは長ければ長いほどAPIのトークン数を消費し、応答速度が遅くなるだけでなく、少し異なるケースに対して柔軟に対応できなくなるという課題も抱えています。
このシステムプロンプトをどう設計するのか、という点は改善の余地が大きいなと感じています。
まとめと振り返り
設計や実装においては、APIの挙動が想定外だったり、プロンプト作りに苦戦したりと、いくつか落とし穴がありました。しかし振り返ると「どのようなサービスを作るべきか」というサービスの根幹を納得いくまで議論し、方向性を明確にすることことが重要だったかなと感じました。初期のアイデアが曖昧なまま開発に着手していたら、きっと時間切れになって、中途半端なものが出来上がってしまっていたことでしょう。。
やはり開発するからには「実際に使ってもらえそうで」「業務的に役に立ちそうな」サービスを目指したいですよね。こういったサービスの価値を限られた期間の中で考えるのは非常にタフな作業ですが、これこそがハッカソンの醍醐味だと改めて感じています。
私自身も業務的に触る機会の少なかった生成AIアプリケーションの構築ができて非常に有意義な経験をさせてもらったなと感じています。これからの時代は、特定の業務に特化したAIエージェントを適切に活用し、それらを組み合わせることで、より高度で効率的なシステムを構築していくことが重要な選択肢になっていくことでしょう。今回の経験を活かし、AIのシステム活用を現場に生かせるように精進していきます。