法令データの案件は、紙の条文をそのまま電子化する仕事だと思われがちです。しかし現場で動いているのは、施行日や改正のたびに中身が入れ替わるデータを、時間軸ごとの構造で保持し続ける仕事です。e-Gov法令検索は2024年度に約2億4,000万回参照されており⁵、この基盤を止めない設計が前提になっています。構造化データやAPIの経験を積んできたエンジニアにとって、公共・リーガル領域はこれまでの経験を試す新しい舞台になります。

1. 法令データの案件はどこにあるのか｜9,354件が毎日更新される前提

「法令データの案件」と聞いて思い浮かべるのは、行政システムの受託開発や検索機能の実装かもしれません。画面の見た目や検索の速さが評価されると考えがちですが、案件を任せる側が実際に見ている評価の軸は、まったく別の場所にあります。

実際に問われているのは、施行日や改正のたびに書き換わる条文を、過去と未来の両方の状態で保持し続ける設計力です。ここを外すと、どれだけ画面を整えても、案件としての評価にはつながりません。まず押さえておきたいのは、この前提そのものです。

画面の作りではなく、変わり続けるデータの持たせ方を問われる仕事

法令は公布された時点で固定される文書ではありません。改正が決まれば施行日を境に条文が入れ替わり、旧規定が一定の条件で残る場合もあります。この切り替わりを壊さずに持たせられるかどうかが、案件の評価を分ける最初の分岐点になります。

「見やすい画面を作る経験」よりも、「変化する構造をデータのまま壊さずに持たせる経験」のほうが、この領域では重く評価される傾向があります。

法令の種別ごとの内訳を数字で見る

法令の登録数は、2025年4月1日現在で合計9,354件です⁷。この母数を支えているのがe-Gov法令検索で、2024年度のアクセス数は約2億4,000万回に上ります⁵。これだけの参照が日常的に発生している基盤である以上、法令データは止めずに更新し続ける前提で設計が求められます。

搭載されている法令数は種別ごとに公表されており⁶、憲法・法律・政令の順で示された内訳を含め⁸、種別ごとの登録数は次の表のとおりです。数の偏りそのものが、どの領域に案件が集まりやすいかを映しています。

種別	登録数
憲法	1
法律	2,143
政令	2,383
勅令	71
府省令	4,313
規則	443
合計	9,354

出典：法制事務デジタル化（デジタル庁、2025年6月）をもとに作成

この内訳をどう構造で保持しているのか、次章では法令データが公開されるまでの流れと、法令XMLの位置づけを見ていきます。母数の姿を知ったところで、次は仕組みの中身に踏み込みます。

2. 書類から構造化データへ｜法令XMLとベース・レジストリという土台

法令データの案件と聞くと、紙の条文をそのまま電子データに置き換える作業を想像しがちです。しかし現場で進んでいるのは、書類を中心にしたやり取りから、構造化データを中心にしたやり取りへの移行そのものです。

その中心にあるのが法令XMLです。機械可読性の高い構造化データを共通言語として扱う方向が示されています⁴。この一文の意味は小さくありません。書類として読むためのデータと、機械が処理するためのデータでは、設計そのものの起点が変わるからです。

法令XMLが担う「共通言語」としての役割

条文をXMLで構造化すると、条番号・項番号・改正履歴といった要素をプログラムから直接扱えるようになります。ここを理解しているかどうかで、設計の初速が変わります。

e-Gov法令検索が持つ法令データは、ベース・レジストリとして指定されています²。行政のさまざまな仕組みが同じデータを参照する前提であるため、品質への要求は一般的な業務システムより重くなります。壊れれば影響が及ぶ範囲も広いためです。

出典：法制事務デジタル化（デジタル庁、2025年6月）をもとに作成

すでに動き出している機能もある

構造化データへの移行は構想段階だけの話ではありません。2025年3月から、開発された機能がe-LAWS上に順次サービスインしています¹。すでに動いている仕組みの上に、これから積み上がっていく案件だという理解を持てるかどうかが、初動の差になります。

告示についても、官報電子化の取り組みを踏まえて整備が進められています³。法律や政令だけでなく、周辺の文書も同じ構造化の流れに合流しつつあり、対象範囲は今後も広がっていくと見込まれます。

出典：法制事務デジタル化（デジタル庁、2025年6月）をもとに作成

次章では、この構造化がなぜ単純にいかないのか、技術検証で見えている難所を見ていきます。土台が整っても、変化そのものを扱う難しさは別に残っています。

3. 技術検証で見えている難所｜施行順・ハネ改正・参照条文

構造化データにすれば案件が単純になるわけではありません。技術検証では、法令が「変わる」ときに起きる複雑さが、いくつものテーマに分けて扱われています。ここからが、この領域の本当の難しさです。

5つの検証テーマを一覧で見る

挙がっているテーマは、施行順変更に伴う編集内容の更新、なお効・なお従に関する経過措置の扱い、条件によって内容が変わる読替、ハネ改正が必要な箇所の自動検知、参照条文の自動作成の5つです。名前だけを見ると地味ですが、どれも「今の条文をどう見せるか」ではなく「変化をどう追い続けるか」を問う難所です。

テーマ	内容	実装で難しくなる点
施行順変更	施行順が変わると条文の編集内容そのものが更新される	適用順序が入れ替わっても矛盾のない状態を保つ設計9
なお効・なお従	改正前の規定を条件付きでなお有効・なお従前の例によるとする経過措置	新旧どちらの規定が有効かを条件ごとに切り分ける設計
読替	条件によって内容が変わる読替表の作成	数百ページ13になる量や、4段以上14になる階層の構造を保持する設計
ハネ改正	ある改正が離れた条文に及ぼす影響の検知	波及関係を人手に頼らず自動で検知する設計10
参照条文	条文間の参照関係の自動作成	参照関係を機械的に維持し続ける設計11

出典：法制事務システムの高度化に向けた技術検証（デジタル庁、2025年3月）をもとに作成

共通しているのは、今の状態だけでなく変化の過程そのものを扱う視点です。次のH3では、この中でも判断が分かれやすい「なお効・なお従」を掘り下げ、なぜここに時間がかかるのかを見ていきます。

「なお効・なお従」が示す経過措置の複雑さ

「なお効・なお従」は、改正前の規定を一定の条件で残す経過措置の表現です。条文の見た目は新しくなっていても、対象や時期によっては古い規定がなお適用される場面があり、この見えない条件をデータの中でどう区別するかが問われます。

「今の条文をきれいに表示する経験」よりも、「見えない適用条件を構造で追い続ける経験」のほうが、この検証では重く扱われる傾向があります。

読替表という、いまも手作業が残る領域

読替表の作成は、いまも職員の手作業に頼っている部分が残っています¹⁵。数百ページ・4段以上に及ぶ量を、人が確認しながら反映させている状態です。ここに構造化の余地が大きく残っています。

読替規定を自動で特定して表示する機能は、試作の段階にあります¹⁶。ここに、構造化データやルールベースの処理を扱ってきた経験が生きる余地があります。次章では、この中でもとりわけ設計が難しい「施行期日が確定していない」場面を掘り下げます。

4. 未確定の施行期日という、時間軸の設計

施行期日は、法律の成立と同時に確定するとは限りません。公布の日を起点に一定の範囲内で政令が日を定める、という形で後から確定する場合も珍しくありません。この「決まっていない」状態こそが設計の対象です。

この「まだ決まっていない期日」をどう構造として持たせるかが、技術検証のテーマになっています。未確定施行期日に対応した法令データ構造の構築が挙げられています¹²。時間そのものを設計対象にする発想です。

「いつから効力を持つか」が決まっていない状態を扱う

通常のシステム設計では、日付は確定した値として扱うのが前提です。しかし法令データでは、「未定」という状態そのものを正式なデータの一部として持たせる必要があります。確定後にどう置き換わるかも含めて、あらかじめ設計しておく発想が求められます。

この視点は、一般的な業務システムの開発ではあまり意識されません。だからこそ、構造化データやスキーマ設計の経験を積んだエンジニアが、公共・リーガル領域で力を発揮しやすい場面だといえます。

このデータ構造は、使う側の設計にも波及する

未確定の期日を扱う設計は、法令データを提供する側だけの課題ではありません。この構造を前提にAPIやサービスを組み立てる側にも、同じ発想が求められます。確定前と確定後で表示や処理をどう切り替えるかは、利用する側の設計にも直接影響します。

参画の前段では、このような「まだ決まっていない状態をどう扱ったか」を、過去の案件から具体的に言葉にできるかが問われます。画面の完成度よりも、変化を前提にした設計の判断根拠を説明できることのほうが、クライアントとの協議では重視されやすくなります。

時間軸を設計に組み込む経験は、法令データに限った特殊技能ではありません。予約が確定するまでの状態や、契約が発効するまでの猶予期間など、他分野でも形を変えて現れる考え方です。次章では、この構造化データを実際に使う側の案件を見ていきます。

5. 法令APIを使う側の案件｜リーガルサービスの開発で問われること

ここまでは、法令データを整備する側の難しさを見てきました。しかし案件はそれだけではありません。整備されたデータを使って、リーガルサービスや業務システムを組み立てる側の案件も、少しずつ広がりを見せています。

法令データ・法令APIに関するニーズ調査が行われており¹⁷、民間側からの利用を前提にした検討が進んでいます。データを持つ側だけでなく、使う側の視点も検討の対象になっている点が重要です。

データを提供する側と、利活用する側

利活用する側の案件では、法令XMLやAPIから取得したデータを、実務で使える形に変換する設計が中心になります。条文そのものをそのまま表示するだけでなく、業務の文脈に合わせて条項を抽出し、改正の影響範囲を利用者に分かりやすく示す工夫が問われます。

「データを取得できる経験」よりも、「取得したデータを利用者の意思決定に結びつける経験」のほうが、この領域では評価されやすくなります。API連携そのものは手段であり、目的は利用者が正しく判断できることです。

ニーズ調査が示す、民間からの入口

法令データ・法令APIへのニーズ調査は¹⁷、行政の内部だけでなく民間の利活用を見据えて行われているものです。ここに、構造化データやAPI連携を扱ってきたエンジニアが参画できる入口があります。

民間側の入口が広がっているということは、案件そのものの種類も一様ではないということです。データ提供元との連携方法を設計する案件もあれば、利用者向けの画面や通知の仕組みを作る案件もあり、自分の得意な工程に寄せて関わり方を選べる余地があります。

リーガルテック領域は、条文の知識よりも先に、変化するデータをどう安定して届けるかという設計力が問われる領域です。これまでWebサービスやAPI基盤の開発で培ってきた経験は、この領域でもそのまま生かせます。

6. 単価につながるスキルの整理｜どこまで踏み込めるかで評価が変わります

法令データやリーガルテックの案件は、ひとつの職種にまとまっているわけではありません。データを整備する側、APIとして提供する側、それを使ってサービスを作る側では、問われる経験がそれぞれ異なります。

単価の考え方も、この関わり方の違いに沿って整理すると分かりやすくなります。どこまで踏み込んで設計に関わったかが、評価の分かれ目になります。

関わり方によって問われる経験が変わる

データ整備に関わる案件では、構造化データのスキーマ設計や、改正・施行に伴う変化をデータモデルに落とし込む経験が問われます。目に見える画面がない分、評価されるのはデータ構造そのものの設計力です。

API提供に関わる案件では、安定した性能と、利用者が扱いやすいインターフェース設計が問われます。利活用サービスの案件では、そのデータを使って利用者の意思決定を助ける工夫が問われます。「APIを呼び出せる経験」よりも、「呼び出した結果を業務にどう組み込むかを設計した経験」のほうが、単価の交渉材料になりやすい傾向があります。

関わり方	求められる経験	単価の考え方
データ整備	構造化データのスキーマ設計、改正・施行に伴う変化のモデル化	設計の深さに応じて協議の材料が増える
API提供	安定した性能設計、利用者が扱いやすいインターフェース設計	提供範囲の広さや保守への関わり方に応じて変わる
利活用サービス	取得したデータを利用者の意思決定に結びつける設計	サービス全体への関与度に応じて協議する

経験をどう言葉にして伝えるか

これまでの案件で「データを整理しました」「APIを実装しました」で説明を止めていると、経験の重さが伝わりにくくなります。どの変化に対応する設計だったのか、何を壊さずに保持する必要があったのかまで言葉にすると、この領域での評価につながりやすくなります。

言葉にする作業は、案件が始まってからでは間に合わないことがあります。参画前の面談に近い場面で、過去の経験のどこが今回の案件に効くのかを尋ねられることが多いため、あらかじめ整理しておくほうが話が進みやすくなります。

報酬の水準は案件や関わる範囲によって幅があり、時点によっても変わります。具体的な金額を決め打ちにするより、自分がどこまで踏み込んだ経験を持っているかを整理し、クライアントと協議する材料にする進め方が現実的です。

7. リモートでの進め方と、よくある質問

法令データやリーガルテックの案件は、常駐が前提だと思われがちな領域です。しかし実際には、構造化データやAPI開発が中心になる設計寄りの仕事が多く、リモートで進めやすい性質を持っています。

Remoguでは、案件の90%以上がフルリモート可能です。場所に縛られず、構造化データやAPI設計の経験を生かせる案件を探しやすい環境が整っています。

公共・リーガル領域は特殊に見えても、問われている技術そのものは、これまで積み上げてきたデータ設計やAPI開発の経験と地続きです。まずは自分の経験がどの関わり方に近いかを確かめながら、案件の情報に触れてみることから始められます。

法令データの案件は未経験でも始められますか

法令の専門知識がまだ少ない状態からの参画は簡単ではありませんが、構造化データやAPI設計の経験があれば、そこを起点に踏み出せる領域です。最初はデータ整備やAPI連携など、これまでの経験に近い関わり方から始め、条文特有の難所は案件を通じて理解を深めていく進め方が現実的です。

条文や法令の知識がなくても対応できますか

求められているのは条文を読み解く法律知識そのものよりも、施行順やなお効・なお従、読替のような「変わり方」を構造で扱う設計力です。法令の細かな知識は、クライアントと協議しながら案件の中で補っていける部分です。

常駐が必要になることが多いのでしょうか

案件によって条件は異なりますが、構造化データやAPI開発を中心にした案件は、リモートで進めやすい設計です。Remoguで扱う案件も90%以上がフルリモート可能で、場所に縛られずに参画先を探せます。

この領域の経験は、単価にどうつながりますか

報酬は案件や関わる範囲、時点によって幅があります。データ整備・API提供・利活用サービスのどこまで踏み込んだ経験を持っているかを整理して伝えることが、条件を協議する材料になります。まずは自分の経験に近い案件がどんな形であるのか、登録して確かめてみることが最初の一歩になります。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 デジタル庁「法制事務デジタル化」実装の段階（2025年6月）
＊2 デジタル庁「法制事務デジタル化」位置づけ（2025年6月）
＊3 デジタル庁「法制事務デジタル化」告示の整備（2025年6月）
＊4 デジタル庁「法制事務デジタル化」設計の方向（2025年6月）
＊5 デジタル庁「法制事務デジタル化」参照の規模（2025年6月）
＊6 デジタル庁「法制事務デジタル化」時点（2025年6月）
＊7 デジタル庁「法制事務デジタル化」総数（2025年6月）
＊8 デジタル庁「法制事務デジタル化」種別の内訳（2025年6月）
＊9 デジタル庁「法制事務システムの高度化に向けた技術検証」検証テーマ（2025年3月）
＊10 デジタル庁「法制事務システムの高度化に向けた技術検証」検証テーマ（2025年3月）
＊11 デジタル庁「法制事務システムの高度化に向けた技術検証」検証テーマ（2025年3月）
＊12 デジタル庁「法制事務システムの高度化に向けた技術検証」難所（2025年3月）
＊13 デジタル庁「法制事務システムの高度化に向けた技術検証」作業の量（2025年3月）
＊14 デジタル庁「法制事務システムの高度化に向けた技術検証」表の構造（2025年3月）
＊15 デジタル庁「法制事務システムの高度化に向けた技術検証」現状（2025年3月）
＊16 デジタル庁「法制事務システムの高度化に向けた技術検証」試作の中身（2025年3月）
＊17 デジタル庁「法制事務システムの高度化に向けた技術検証」需要の把握（2025年3月）