製品ページに「電子申請に対応」と書かれていても、その一語が指す範囲は製品ごとに違います。比較検討で詰まるのは対応帳票の数ではなく、自社が義務化の対象なのか、e-Govとどの方式でつなぐのか、申請を誰の名義で行うのか、という三点です。この記事では社会保険・労働保険の電子申請という条件下でシステムに求められる要件を分解し、既製の労務管理システムで完結する条件と、既存の人事給与・勤怠システムへ連携開発が必要になる条件を分けて示します。e-Gov側の画面操作や事前準備の手順そのものはe-Gov電子申請の使い方と必要な準備で、労働基準監督署へ出す就業規則（変更）届の書き方と提出方法は就業規則変更届の書き方と電子申請の手順で扱っているため本記事では立ち入らず、機能全般や勤怠管理との違いは労務管理システムとはを参照してください。
まとめ：電子申請対応を製品比較の前に判断するための要点
- 義務の対象：資本金・出資金または銀行等保有株式取得機構への拠出金が1億円を超える法人、相互会社、投資法人、特定目的会社です。2020年4月以降に開始する各事業年度から適用されています。
- 義務の範囲：健康保険・厚生年金保険の3届、労働保険の申告書、雇用保険の5手続きに限られ、これ以外は義務ではありません。
- 例外：回線故障や災害で困難な場合、労働保険事務組合へ事務委託している場合などは電子申請によらない方法が認められています。
- 委託しても対象：社会保険労務士が代わって手続する場合も義務の対象に含まれます。
- 呼称の陳腐化：「外部連携API対応」という表記は古い情報です。外部連携APIは2024年1月31日でサポートが終了し、現行は電子申請APIに置き換わっています。
- 互換性なし：両者に互換性はなく、旧APIのソフトウェアID・利用者ID・アクセスキーは引き継げません。
- APIの構成：電子申請APIは電子申請・電子送達・アカウント間情報共有・利用者認証の4カテゴリで、利用者認証はOAuth2とOpenID Connectに準拠しています（2026年8月時点）。
- 認証の運用：GビズIDプライムとメンバーには有効期限が設けられ、有効期間はアカウント発行日から2年3か月です。切れるとログインできず申請が止まります。
- パッケージで足りる条件：対象手続きが義務範囲に収まり、従業員データの発生源が1系統で、申請名義を1つに統一できる場合です。
- 連携開発が要る条件：人事給与や勤怠が別ベンダー製で二重入力が残る、グループ複数法人で申請名義が分かれる、公文書を基幹側の台帳に自動保存したい、のいずれかに当たる場合です。
電子申請に対応が指す範囲：義務化された手続きと対象法人の線引き
製品選定の前に、自社が「必ず電子で出さねばならない立場」なのかを確定させます。ここが曖昧なままだと、義務ではない手続きまで含めた過大な要件を製品に求めることになり、比較の軸がぶれます。
特定の法人の判定：事業年度開始時の資本金等で決まる四類型の基準
義務の対象は「特定の法人」と呼ばれる四つの類型です。第一が、資本金の額、出資金の額または銀行等保有株式取得機構に納付する拠出金の額が1億円を超える法人。第二が保険業法の相互会社、第三が投資信託及び投資法人に関する法律の投資法人、第四が資産の流動化に関する法律の特定目的会社になります。
判定の時点は事業年度開始の時です。期中に増資して1億円を超えた場合、その事業年度ではなく次の事業年度の開始時点が判定対象です。適用は2020年4月以降に開始される各事業年度からで、この起算の違いが自社の対象年度を決めます。資本金1億円前後で推移している企業は、増資や減資の決議と同じ会議体で電子申請の体制も議題に載せておくと、期首の切り替えが間に合います。
義務化の対象手続き：健康保険・労働保険・雇用保険の区分別一覧
対象は保険制度をまたいで指定されており、担当部署が分かれている企業ほど全体像を見落とします。2026年8月時点で厚生労働省が示している対象手続きは次のとおりです。
| 区分 | 電子申請が義務となる手続き |
|---|---|
| 健康保険・厚生年金保険 | 被保険者報酬月額算定基礎届 |
| 健康保険・厚生年金保険 | 被保険者報酬月額変更届 |
| 健康保険・厚生年金保険 | 被保険者賞与支払届 |
| 労働保険 | 年度更新に関する申告書 |
| 労働保険 | 増加概算保険料申告書 |
| 雇用保険 | 被保険者資格取得届 |
| 雇用保険 | 被保険者資格喪失届 |
| 雇用保険 | 被保険者転勤届 |
| 雇用保険 | 高年齢雇用継続給付支給申請 |
| 雇用保険 | 育児休業給付支給申請 |
労働保険の欄にある年度更新の申告書は、概算保険料申告書・確定保険料申告書・一般拠出金申告書の総称で、継続事業（一括有期事業を含む）を行う事業主が提出するものが対象です。逆に言えば、入社時の被扶養者異動届や住所変更のような日常の届出は、この一覧に載っていません。義務の範囲は思われているより狭く、実務で件数が多い手続きと必ずしも一致しない点を押さえておきます。
電子申請によらない方法が認められる例外と、社労士へ委託した場合
例外は二系統あります。ひとつは電気通信回線の故障や災害などにより電子申請が困難と認められる場合。もうひとつは労働保険関係手続（保険料申告関係）に限った例外で、労働保険事務組合に事務を委託している場合、単独有期事業を行う場合、年度途中に保険関係が成立した事業で成立日から50日以内に申告書を提出する場合が挙げられています。
誤解が生じやすいのは委託時の扱いでしょう。社会保険労務士や社会保険労務士法人が対象法人に代わって手続する場合も義務に含まれます。顧問社労士に任せているから自社は無関係、という整理にはなりません。委託先がどの方式で提出しているかを確認し、システム側で申請データを渡す形にするのか、届出そのものを内製に戻すのかを決める必要があります。受託する社労士事務所側でどんな業務基盤が必要になるかは社労士ソフトの4系統と電子申請対応・個別開発の判断で整理しています。
e-Gov側の接続方式：画面申請とAPI連携の違いと現行仕様の確認
電子申請対応をうたう製品は、内部でe-Govとどうつながっているかが異なります。ここを製品資料の言葉のまま受け取ると、古い仕様のまま説明されている資料に当たることがあります。
外部連携APIは終了済み：電子申請APIへ移行して引き継げないもの
外部連携APIは2020年の更改を契機に電子申請APIへアップグレードされ、2024年1月31日でサポートが終了しました。両者に互換性はありません。加えて、外部連携APIで使っていたソフトウェアID、利用者ID、アクセスキーは電子申請APIでは利用できず、それぞれ取り直しになります。
実務上の意味は二つあります。比較資料や解説記事に「外部連携API対応」とある場合、その情報が2024年より前の記述である可能性を疑うべきだという点。そして自社で開発済みの連携がある場合、移行が終わっているかを開発ベンダーに確認しておく必要があるという点です。呼称だけを差し替えた説明も見かけるため、取得済みのID種別まで踏み込んで確かめると確実になります。
電子申請APIの四つのカテゴリと、公文書取得までカバーする範囲
電子申請APIは目的別に四つのカテゴリで構成されています。申請と事務処理状況の照会、発出された公文書の取得までを扱う「電子申請」。申請を前提とせず行政機関から発出される通知文書を取得する「電子送達」。gBizIDプライムとメンバーの間で申請案件や公文書を共有する「アカウント間情報共有」。そしてOAuth2とOpenID Connectに準拠した「利用者認証」です。
バージョンは1と2があり、アカウント間情報共有への対応にあわせて2が最新となりました。バージョン1の提供終了は予定されていません。製品を評価する際は、申請の送信だけでなく、状況照会と公文書取得まで自動化されているかを見ます。ここが手作業のまま残ると、電子化したのに担当者が毎日e-Govの画面を見に行く運用が続きます。
画面申請とAPI連携の分岐：申請件数と公文書の管理負荷で決める
接続方式は、件数と後処理の量で選びます。年間の対象手続きが数十件で、公文書を都度ダウンロードして共有フォルダに置く程度なら、e-Govの画面から出す運用でも回ります。従業員数が数百名を超え、算定基礎届のように一度に大量の被保険者を扱う手続きが年次で発生するなら、API連携のある製品が前提になるでしょう。算定基礎届を給与データから作るときに要る支払月・支払基礎日数などの判定材料は、4月から6月の給与で決まる定時決定と算定基礎届の判定要件を整理した記事で解説しています。
判断の分かれ目になるのは公文書の管理です。申請の送信そのものは画面でも数分ですが、返ってくる公文書を誰がどこに保存し、どの従業員の記録に紐づけるかは件数に比例して膨らみます。ここを人手で回している限り、電子申請の効果は送信時間の短縮にとどまります。
認証の設計：GビズIDと電子証明書の使い分けと有効期限への備え
システム選定と同じ比重で決めるべきなのが、誰の名義でe-Govにログインし、その資格を誰が管理するかです。ここは製品側で吸収できず、自社の体制として設計する部分になります。
GビズIDプライムとメンバーの権限差と、社会保険手続きでの位置
GビズIDは一つのIDで複数の行政サービスにログインできる共通認証の仕組みで、アカウントはプライム・メンバー・エントリーの三種類です。プライムは法人代表者または個人事業主が審査を経て作成し、利用できる行政サービスに制限がありません。メンバーはプライムが作成する従業員用で、利用できるサービスに制限があります。エントリーは審査なしで作成できる反面、制限が大きくなります。種別ごとの保証レベルや、自社システムからGビズIDを直接扱えるかどうかの線引きは、GビズIDの権限差とシステム連携の可否で公式資料に当たって確認しています。
公開されている行政サービス一覧では、日本年金機構の「社会保険手続きの電子申請」もe-Govも、プライムとメンバーの双方に対応しています（2026年8月時点）。実務ではプライムを代表者名義で1つ作り、日常の申請は労務担当者のメンバーで行う形が扱いやすくなります。代表者本人が毎回ログインする設計にすると、代表者の異動時に手続きが止まります。
有効期限の導入で増えた更新作業と、期限切れで止まるものの範囲
見落とされやすい変更点が、アカウントの有効期限です。GビズIDプライムとメンバーには有効期限が設けられ、有効期間はアカウント発行日から2年3か月とされています。導入日以前に発行されたアカウントは導入日を起算として2年3か月、公式の案内では2028年10月ごろまで有効という扱いです。
期限が切れると、行政サービスへのログイン、GビズIDメンバーの作成、委任・受任申請などができなくなります。プライム側が切れた場合、紐づくメンバーが期限内であっても同様の制限を受ける点は運用上の急所でしょう。通知は有効期限の3か月前・1か月前・2週間前および経過後に届きますが、更新手続きには本人確認を含む場合があり、最大1か月ほどかかることがあると案内されています。算定基礎届や年度更新の直前に期限が来る配置になっていないかを、あらかじめ確認しておきます。
電子証明書が引き続き必要になる場面と、失効管理の担当の決め方
GビズIDで電子証明書なしに申請できる手続きが広がった一方、電子証明書を使う経路が消えたわけではありません。委託先の社労士が代理で提出する場合や、GビズIDに対応していない経路を使う場合には、法人の電子証明書が引き続き必要になります。証明書には有効期間があり、更新を失念すると申請の当日に止まります。
ここで決めておくのは担当の所在です。GビズIDのアカウント管理は労務部門、電子証明書の取得と更新は総務や情報システム部門、という分かれ方をしている企業は少なくありません。期限管理の台帳を一本化し、更新の起票を誰が出すかまで決めておくと、担当者の異動でも引き継ぎが効きます。
パッケージで完結する条件と、連携開発に踏み込むべき条件の分岐
ここまでの要件を踏まえて、既製品で足りるのか、開発を伴うのかを判断します。判断材料は機能一覧ではなく、自社のデータと組織の形にあります。
既製の労務管理システムで完結する三つの条件と自社での確認手順
次の三つがすべて当てはまるなら、既製品の導入で完結する見込みが高くなります。第一に、電子で出したい手続きが義務化された範囲と入退社まわりの定型届出に収まること。第二に、従業員のマスタデータが1系統で管理されていて、給与や勤怠が同じ製品群または標準連携の範囲に収まること。第三に、申請の名義が一法人で、代理申請の階層を持たなくてよいことです。
確認は製品資料ではなく、自社の届出台帳から行います。直近1年に出した届出を手続き名で数え、上位を占める手続きが製品の対応帳票一覧に含まれるかを突き合わせます。対応帳票数の多さを売りにしていても、自社が年に一度も出さない手続きが並んでいるなら、その数字に意味はありません。費用の考え方は労務管理システムの費用相場で整理しています。
人事給与・勤怠システムとの連携開発が必要になる三つの典型パターン
一方、次のいずれかに当てはまると既製品だけでは収まりません。人事給与が基幹側にあり労務管理システムと別ベンダー製で、報酬月額の算定に使う支給データを毎回手作業で移している場合。グループ内に複数法人があり、法人ごとに申請名義と提出先が分かれていて、どの法人の従業員かでルーティングが要る場合。そして、取得した公文書を人事システムの従業員台帳へ自動で紐づけて保存したい場合です。
いずれも共通するのは、電子申請そのものではなくデータの受け渡しが詰まっている点にあります。申請の送信はe-Govの電子申請APIに対応した製品に任せ、社内側は支給データの生成と公文書の格納を自動化する。この線引きで組むと開発範囲は小さく収まります。既存システムとの接続や項目のマッピングを含めた設計はAPI開発・システム連携で対応しています。
開発範囲を絞る線引きと、費用が膨らむ要件を見分ける三つの観点
費用が膨らむのは、自社でe-Govとの通信そのものを実装しようとしたときです。電子申請APIの利用には利用者登録に加えて最終確認試験の実施が求められ、対象手続きごとに申請書様式の構造仕様と形式チェックルールへ合わせ込む作業が発生します。年に数十件の申請のためにこの実装を抱えると、保守が続く限りコストが残るでしょう。
採用してよいのは、申請件数が年間で数千件規模に達する場合、または自社が労務サービスの提供者として顧客の申請を代行する立場にある場合です。それ以外は、電子申請APIへの接続は対応製品に任せ、開発は社内システムとのデータ連携に限定する判断が費用に見合います。この線を引かないまま要件定義に入ると、行政側の仕様変更に自社で追随し続ける負債を抱えることになります。
製品比較の前に自社で固める項目と、切り替えを進める順序の決め方
最後に、製品比較の精度を上げるために自社側で先に決めておく項目を挙げます。この準備があると、デモや見積もりの依頼内容が具体になります。
対応帳票数より先に確認したい三項目と、社内で用意しておく資料
確認すべきは、申請の名義を何個持てるか、代理申請や委任の階層に対応するか、添付書類の形式と容量の制限がどうなっているか、の三項目です。特に添付は実務で詰まりやすく、証明書類の写しをどの形式で渡せるかが手続きの可否を左右します。
社内で用意しておくのは、直近1年の届出件数を手続き名別に集計した表、従業員データの発生源と流れを描いた1枚の図、そして申請名義と担当者の一覧です。この三点があれば、ベンダーとの会話は機能の有無ではなく自社の運用に沿った検証に移ります。
公文書を受領した後の扱いと、保存先・通知・原本性の決めどころ
電子申請で返ってくる公文書は、受け取って終わりではありません。誰が受領を検知し、どこに保存し、どの従業員の記録に紐づけるかを決めます。電子申請APIには公文書の取得に加え、申請を前提としない通知文書を受け取る電子送達の仕組みもあるため、両方の受け皿を用意しておくと後から慌てずに済みます。
保存先は、労務管理システム内で完結させるか、社内の文書管理へ移すかの二択です。退職者の記録を含めて長期に参照する前提なら、システムの契約が切れても残る場所へ複製しておく設計が安全でしょう。
切り替えの順序：件数の多い手続きから段階的に移していく進め方
一斉切り替えはおすすめできません。実務で件数の多い手続きから順に移し、公文書の受領まで一巡してから次に進むほうが、差し戻しの原因を切り分けやすくなります。多くの企業では雇用保険の資格取得届と資格喪失届が最も件数が多く、ここを先に通すと運用の型が固まります。行政への届出の手前にある雇用契約の締結と入社書類の回収については労務管理システムで雇用契約手続きを完結させる要件で扱っています。
年次の手続きでは別の扱いが必要です。算定基礎届や労働保険の年度更新は年に一度しか本番がないため、前年の申告内容を使った検証を事前に行い、期限の1か月前までに手順を確定させておきます。GビズIDの有効期限や電子証明書の期限がこの時期に重ならないかも、同じタイミングで点検しておきます。
よくある質問
資本金1億円以下の会社は電子申請しなくてよいのですか？
義務の対象ではありません。ただし義務がないことと、紙のほうが有利であることは別です。窓口や郵送の往復がなくなり、提出履歴と公文書がシステム上に残る利点は規模を問わず得られます。増資の予定がある企業は、対象になる事業年度の前に体制を整えておくと切り替えが穏やかに済みます。
顧問社労士に任せていても自社で電子申請の準備が要りますか？
社会保険労務士が代わって手続する場合も義務の対象に含まれます。準備が要るかは委託の範囲によります。届出の作成から提出まで完全に委託しているなら、自社側で必要なのは委託先が電子で提出しているかの確認と、渡すデータの形式の取り決めです。自社で作成し提出だけを委託している場合は、申請データの受け渡し方法を決めておきます。委託先の事務所が手続きをどの申請経路へ割り付けているかは、社労士事務所のシステム対応を扱った記事で確認できます。
外部連携APIに対応と書かれた製品は今も使えますか？
表記が古いだけの場合と、実態として移行が済んでいない場合があります。外部連携APIは2024年1月31日でサポートが終了しているため、現在も稼働している製品は電子申請APIへ移行済みのはずです。判断に迷う場合は、電子申請APIのどのバージョンに対応しているか、公文書取得と電子送達に対応しているかをベンダーに確認してください。
GビズIDのアカウントは代表者と担当者のどちらで作りますか？
プライムは法人代表者または個人事業主の名義で作成し、日常の申請は代表者が作成したメンバーで行う形が扱いやすくなります。プライムの有効期限が切れると紐づくメンバーも同じ制限を受けるため、代表者名義の更新期限を担当部門が把握しておく体制にしておきます。
電子申請に切り替えると処理はどのくらい速くなりますか？
審査そのものの所要日数は行政側の運用によるため、電子にしたから即日で済むとは限りません。短縮されるのは移動と郵送、控えの保管、進捗の問い合わせに費やしていた時間です。効果を実感しやすいのは、状況照会と公文書取得まで自動化した場合で、送信だけを電子化しても手元の作業量はあまり変わりません。
