Web APIをつないできた経験と、フォーム実装で培った設計力。引越しワンストップ化の案件情報を目にしたとき、この経験がそのまま生きるのか、それとも行政の制度知識が別に要るのか、判断がつきにくいところです。デジタル庁は、民間の引越しポータルからも市区町村の行政手続につながる電子申請等API仕様書を事業者向けに提供しており¹⁰、この案件が求めているのは行政知識の量ではなく、人によって変わる手続を漏れなく束ねる設計力です。積み上げてきたAPI連携の経験は、ここでこそ形になります。

1. 引越しの手続はなぜ漏れるのか｜相手方の多さと人による違い

氏名や新住所は相手ごとに届け出る必要がある

引越しをすると、氏名や新住所といった同じ情報を、電気やガス、自治体など相手ごとに個別に届け出る必要があり、その都度手続の負担が生じます²。1つの情報を何度も入力し直す構造そのものが、まず最初のつまずきになっています。

入力の手間よりも重いのは、どこにまだ届け出ていないかを本人が覚えておかなければならない点です。抜けに気づくタイミングは決まっておらず、忘れた頃に督促や請求という形で表面化します。

必要な手続は人によって異なる

必要な手続は人によって異なり、かつ手続を行うべき相手方が多岐にわたります³。単身か世帯かでも変わり、契約している事業者の組み合わせでも変わるため、共通の手順書だけでは対応しきれません。

つまりこの領域は「決まった手順を早く回す」仕事ではなく、「人ごとに違う条件を読み取り、必要な手続の組み合わせを組み立てる」仕事です。フォーム1枚を作る発想とは、求められる視点が異なります。

網羅的な把握が難しく、手続漏れが起きやすい

相手方の多さと人による違いが重なった結果、必要な手続を網羅的に把握できず、手続漏れが発生しやすい状況が生まれています⁴。これは個人の不注意ではなく、仕組みの側に空白があるために起きる漏れです。

だからこそ、この案件で問われるのは操作の速さよりも、漏れが起きる構造そのものを設計で埋められるかどうかです。次の章では、この構造に対して何が変わったのかを見ていきます。

この構造を踏まえると、必要なのは行政手続の知識を先に覚えることではなく、分岐が多い入力をどう1つの形に整理するかという設計の視点です。フォームやAPIをつないできた経験は、この視点にそのまま接続します。

相手ごとに分かれた届け先と、1つの入力に束ねた状態の違いを図にすると、負担がどこで生まれ、どこで解消されるのかが見えてきます。

図の作成：Remogu編集部。デジタル庁「引越し手続オンラインサービス」が示す課題を整理したもので、統計データではありません

2. 何が変わったのか｜マイナポータルからの転出届と来庁予定の連絡

従来は転出元への来庁が前提だった

これまでは、転出元の市区町村に来庁して転出証明書を受け取った上で、転入届とともに提出する必要がありました⁵。転出と転入という2つの手続の間に、来庁という物理的な制約が挟まっていた形です。

結果として、住民が複数回来庁することになっていました⁶。平日の日中に窓口へ足を運べるかどうかが、手続を滞りなく終えられるかを左右していたことになります。

マイナポータルからの転出届と来庁予定の連絡

現在は、マイナポータルから転出届と来庁予定の連絡ができるようになっています⁷。転入予約にあたるこの連絡があることで、転入先の窓口も来庁前に事情を把握しやすくなります。

ここで押さえたいのは、来庁そのものがゼロになったわけではないという点です。経路は増えましたが、置き換わったのは一部であり、案件を設計する側は両方の経路が存在する前提で組み立てることになります。

変化が意味するもの

デジタル庁は、民間手続を含めた引越しに関する手続のオンライン化・ワンストップ化を推進しています¹。行政側の窓口を増やすだけでなく、民間サービス側からつながる経路まで含めて設計されている点が特徴です。

行政の窓口が変わったことよりも、民間のサービス側からその窓口につながる道ができたことのほうが、Web API経験を持つ人にとっては意味を持ちます。この経路をどうつなぐかは、次の章で扱います。

行政側の制度そのものを追いかけるよりも、民間ポータルという接点からどう連携を組み立てるかを追うほうが、現実的な近道になります。制度の網羅よりも、つなぐ設計の正確さが評価される領域です。

従来の流れと新しい経路を、来庁の要否と提出物の観点で並べると、変わった部分と変わっていない部分の両方が見えてきます。

項目	従来の流れ	新しい経路
来庁の要否	転出元に来庁し転出証明書を受け取る必要があった	マイナポータルから転出届と来庁予定の連絡ができる
提出物	転出証明書を転入先の窓口へ持参して提出	電子的な手続を介して情報が連携される
来庁の回数	住民が複数回来庁することになっていた	連絡済みの来庁予定に沿って窓口対応が進む

案件を設計する側にとっては、来庁が要る経路と要らない経路の両方を同じ画面の中でどう案内するかが実装上の分かれ目になります。片方だけを想定した設計では、もう一方の利用者を取りこぼします。

従来の経路と新しい経路が並行している状態を図にすると、来庁という制約がどこで残り、どこで軽くなったのかが分かりやすくなります。

出典：デジタル庁「引越し手続オンラインサービス」をもとに作成

3. 民間ポータルからつなぐという選択肢｜API連携と仕様書の提供

民間ポータルで完結する手続の広がり

民間の引越しポータルでは、電気・ガス・水道等の民間手続を実施できるサービスがすでに提供されています⁸。利用者からすれば、こうしたポータルは引越しに関する窓口を1つにまとめてくれる入口です。

ここまでは民間対民間の話であり、Web APIの経験がある人にとってはなじみのある領域です。話が変わるのは、この入口から行政の手続へもつながる場合です。

民間ポータル側の設計は、契約している事業者との連携が中心になりがちです。そこに行政手続という別の相手が加わることで、束ねる対象そのものが広がり、設計の難度が一段上がります。

行政手続につなぐAPIと仕様書

API連携によって、市区町村への行政手続も行うことが可能となっています⁹。民間ポータルという1つの入口から、民間手続と行政手続の両方につながる経路が用意されている形です。

この経路を実装するために、引越しポータルを運営する事業者向けに電子申請等API仕様書が提供されています¹⁰。仕様書という形で公開されている以上、ここは推測ではなく読み込んで実装する対象です。

つなぐ側に立つという案件の性質

この案件は、行政の窓口業務を代わりに担う仕事ではありません。民間ポータル側に立ち、そこから仕様書に沿って行政手続へ正しくつなぐ設計を担う仕事です。担う範囲を見誤らないことが、最初の分かれ目になります。

操作の経験よりも、仕様書を読み解いて連携を組み立てる経験のほうが差になります。Remoguでは、案件の90%以上がフルリモート可能です。場所を選ばずに手を動かせる領域だからこそ、まず登録して自分の経験に合う条件を確かめる価値があります。

民間ポータルから行政手続へつながる流れを図にすると、どこまでが民間の領域で、どこからAPI連携が始まるのかが見えてきます。

出典：デジタル庁「引越し手続オンラインサービス」をもとに作成

4. 5つの設計のうち前半3つ｜束ねる・判定する・経路を分ける

ここからは、この案件を成り立たせている5つの設計を順に見ていきます。前半の3つは、届け先を束ね、条件を判定し、経路を分けるという、入り口に近い部分を支える設計です。

設計1：相手ごとに違う届け先を1つの入力に束ねる

氏名や新住所を相手ごとに個別に届け出る負担を解くには²、入り口となる入力を1つにまとめ、そこから各相手に振り分ける設計が要ります。フォームを1つ減らすのではなく、背後の分岐を引き受ける設計です。

つまずきやすいのは、相手ごとに必要な項目や様式がわずかに違う点です。1つの入力に見えても、内部では相手の数だけ変換の道筋を用意しておく必要があります。

設計2：人によって変わる手続の組み合わせを判定する

必要な手続は人によって異なります³。単身か世帯かといった条件を早い段階で読み取り、その人に必要な手続の組み合わせを判定する設計が、束ねる設計とセットで求められます。

ここでのつまずきは、条件を1つ見落とすと組み合わせ全体が崩れる点です。判定のロジックは一度作って終わりではなく、条件が増えるたびに見直す前提で組む必要があります。

設計3：来庁が残る経路と、残らない経路を分ける

転出証明書の受け取りのように、来庁が前提となる経路は今も残っています⁵。すべてがオンラインで完結するわけではないため、来庁が必要な経路と不要な経路を分けて案内する設計が欠かせません。

従来は住民が複数回来庁することになっていた背景を踏まえると⁶、経路を分けずに一律で案内してしまうと、不要な来庁を利用者に強いる結果になります。分岐の設計は、負担を減らす設計そのものです。

5. 5つの設計のうち後半2つ｜仕様の変化に耐える・漏れを利用者に戻す

束ねる・判定する・経路を分けるという前半3つの設計は、いずれも今の仕様を正しく実装できているかという話でした。後半の2つは、その先の話です。仕様そのものが動き続けることと、それでも漏れを残さないことに向き合う設計になります。

前半3つの設計を一度組み上げただけでは、この案件は完成しません。仕様が変わり続ける前提で保守する視点と、それでも漏れを残さず利用者に伝える視点が加わって、初めて実運用に耐える形になります。

設計4：仕様が動く前提でAPI連携を保つ

マイナポータルは、利用者の意見を基に機能の拡大や使いやすさの改善に継続して取り組んでいます¹³。一度つないだ連携が、次の改善でそのまま通用するとは限らないという前提で保守を組む必要があります。

マイナポータルには、住民の情報や行政手続を組み込むことのできるAPIサービスが用意されています¹²。組み込める範囲が広い分、仕様の変更を早く察知し、影響範囲を切り分けられる設計かどうかが問われます。

設計5：手続漏れを可視化して利用者に戻す

相手方の多さと人による違いが重なると、必要な手続を網羅的に把握できず、手続漏れが発生しやすくなります⁴。この漏れは裏側で吸収するのではなく、利用者に「まだ済んでいない手続」として戻す設計が要ります。

束ねて判定して経路を分けるだけでは、漏れそのものは消えません。何が残っているかを利用者自身に見せて初めて、この案件が掲げる「漏れの解消」という目的にたどり着きます。

5つの設計が担う役割を、入力・判定・経路・仕様変化・可視化という位置関係で図にすると、それぞれの設計がどこを支えているのかが整理できます。

図の作成：Remogu編集部。5つの設計は本記事が整理した構成であり、統計データではありません

5つの設計を並べて、それぞれでつまずきやすい点を整理すると、案件に入る前に何を確かめておくべきかが見えてきます。

設計	内容	つまずきやすい点
設計1	相手ごとに違う届け先を1つの入力に束ねる	相手ごとにわずかに違う項目や様式の吸収
設計2	人によって変わる手続の組み合わせを判定する	条件を1つ見落とすと組み合わせ全体が崩れる
設計3	来庁が残る経路と残らない経路を分ける	一律の案内が不要な来庁を利用者に強いる
設計4	仕様が動く前提でAPI連携を保つ	改善のたびに連携が通用しなくなる可能性
設計5	手続漏れを可視化して利用者に戻す	裏側で吸収するだけでは漏れ自体が消えない

6. 単価につながるスキルの整理｜つなぐ側に立てるかで変わります

つなぐ側に立つ経験をどう伝えるか

マイナポータルは個人向け行政サービスのオンライン窓口であり¹¹、そこに住民の情報や行政手続を組み込むことのできるAPIサービスが用意されています¹²。組み込む側に立った経験があるかどうかが、まず問われる分かれ目です。

「APIをつなぎました」で止まる説明よりも、「相手ごとの分岐をどう判定し、どの経路に振り分けたか」を語れるほうが伝わります。5つの設計のどこを担ったかで、実績の言葉は具体的になります。

担当した範囲を、束ねる・判定する・経路を分ける・仕様変化に耐える・可視化するという5つの言葉に当てはめて振り返ると、これまで漠然と語っていた実績が、案件の要件と対応づいた具体的な経験に変わります。

報酬をどう考えるか

報酬は案件によって異なり、担う設計の範囲によっても変わります。入力を受け取るだけの立場よりも、判定や経路分けまで担う立場のほうが、協議の材料は増えます。断定はできませんが、担う範囲を明確に語れることが交渉の起点になります。

報酬の幅を測る前に、まず自分の経験がどの設計に対応しているかを言葉にしておくと、条件を協議する場面で立ち位置がぶれません。関わり方ごとの考え方を整理しておきます。

担当範囲を狭く見せてしまうと、協議の材料も狭くなります。判定や仕様変化への対応まで担っているなら、その部分こそ具体的に言葉にして伝えたほうが、条件の交渉では有利に働きます。

関わり方	生きる経験	単価の考え方
入力と判定を担う	フォーム設計、条件分岐の実装経験	判定ロジックの複雑さを言葉にして協議材料にする
API連携を担う	外部API仕様書を読み解いて実装した経験	連携先の数と保守の見通しを条件に含めて協議する
利用者への通知を担う	状態管理やお知らせ機能の実装経験	可視化する項目の幅を担当範囲として明示する

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

Remoguは、リモートワーク案件に特化したエンジニアマッチングサービスです（株式会社LASSIC運営）。仕様書を読み解いて設計する仕事は、常駐でなくとも進めやすい領域であり、場所に縛られずに力を発揮できる案件が並びます。

API連携の経験を、行政の窓口へつなぐ設計という新しい文脈で語れるようになると、案件の見え方そのものが変わります。次の一歩は、その経験を実際の案件情報と照らし合わせてみることです。

電子申請等API仕様書はどこで確認できますか

デジタル庁が、引越しポータルを運営する事業者向けに電子申請等API仕様書を提供しています¹⁰。参画する前に、まずこの一次情報に目を通しておくと、案件で扱う範囲のイメージがつかみやすくなります。

この案件は行政のシステムそのものを扱いますか

扱う中心は、行政システムそのものではなく、民間ポータル側でAPI連携によって市区町村への行政手続を可能にする部分です⁹。担う範囲を最初に確認しておくと、案件選びの判断がしやすくなります。

Web APIの経験だけで参画できますか

行政の制度知識を先に積み上げる必要はありません。求められているのは、人によって変わる手続の組み合わせを漏れなく束ねる設計力であり、これはWeb API連携やフォーム設計で積み上げてきた経験の延長にあります。

在住地に関係なく参画できますか

Remoguはリモートワーク案件に特化したエンジニアマッチングサービスであり、仕様書を読み解いて連携を組み立てる工程は、離れた場所からでも進めやすい性質を持ちます。まず登録して、自分の経験に合う条件を確かめてみましょう。

単価はどのくらいを見込めばよいですか

案件によって条件は異なり、担う設計の範囲によっても変わります。断定はできませんが、束ねる・判定する・経路を分けるといった設計のどこまでを担うのかを言葉にできると、協議の起点がはっきりします。

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

出典・参考情報

＊1 デジタル庁「引越し手続オンラインサービス」取組の範囲（2026年3月）
＊2 デジタル庁「引越し手続オンラインサービス」今の負担（2026年3月）
＊3 デジタル庁「引越し手続オンラインサービス」手続の違い（2026年3月）
＊4 デジタル庁「引越し手続オンラインサービス」漏れの理由（2026年3月）
＊5 デジタル庁「引越し手続オンラインサービス」従来の流れ（2026年3月）
＊6 デジタル庁「引越し手続オンラインサービス」来庁の回数（2026年3月）
＊7 デジタル庁「引越し手続オンラインサービス」新しい経路（2026年3月）
＊8 デジタル庁「引越し手続オンラインサービス」民間の経路（2026年3月）
＊9 デジタル庁「引越し手続オンラインサービス」連携の方法（2026年3月）
＊10 デジタル庁「引越し手続オンラインサービス」仕様書の提供（2026年3月）
＊11 デジタル庁「マイナポータル」位置づけ（2026年7月）
＊12 デジタル庁「マイナポータル」APIの範囲（2026年7月）
＊13 デジタル庁「マイナポータル」改善の姿勢（2026年7月）