税務申告システム開発の発注/外注/依頼/委託方法について

税務申告システムの発注・外注では、申告書を作れるかだけでなく、会計データの取込からレビュー、電子署名、e-Tax・eLTAXへの送信、受信通知の保存までを自社の業務に合わせて設計できる委託先を選ぶことが重要です。

税務申告システムは法改正や様式変更の影響を受けるため、価格だけで発注先を決めると、導入後の追加費用や運用負担が膨らみやすくなります。この記事では、パッケージ導入・クラウド利用・個別開発の選び方、RFPと要件整理、契約形態、費用相場、委託先の比較方法を、発注担当者がそのまま使える観点で解説します。

▼全体ガイドの記事
・税務申告システム開発の完全ガイド

税務申告システムを発注・外注する前に知っておきたい全体像

税務申告システムは、申告書の入力画面だけを指すものではありません。会計・ERP、給与、固定資産、請求などのデータを税務計算に利用できる形へ変換し、申告前の確認、承認、送信、受信結果の管理、証憑と過年度データの保存までを支える業務基盤です。

発注時に「法人税の申告書を作るシステム」とだけ伝えると、会計データの連携方式、税区分の変換、税理士や上長のレビュー、電子署名、送信エラーへの対応が見積もりから抜ける可能性があります。最低限、仕訳や残高試算表の取込、税額計算、別表・明細書の作成、国税・地方税の送信、受付通知の確認、申告関連証憑の検索と保存を一つの業務シナリオとして整理します。

国税庁のe-Tax APIは民間ソフトから基本情報や税目情報を取得するインターフェースを提供していますが、利用者識別番号によるログインや送信方式は別途仕様確認が必要です。APIに対応しているという説明だけで判断せず、認証、電子証明書、送信、受付結果の取得、障害時の再送までを実際に確認することが大切です（出典: 国税庁「国税電子申告・納税システムAPI」）。

税務領域では、画面が完成しても税額計算や帳票の整合性が確保されなければ運用できません。発注前に、どの税目と帳票を対象にするか、誰がレビューして承認するか、どの操作をログへ残すか、過年度データを何年分保持するかを決めます。正しい申告を支えるのは機能数ではなく、入力データの出所と計算根拠をたどれる仕組みです。

また、2026年時点では、2026年4月1日以後に開始する事業年度から防衛特別法人税の申告・納付が必要になる案内が国税庁から出ています。制度改正のたびに様式や計算ロジックが変わるため、法改正情報を誰が収集し、いつまでに検証環境へ反映し、どのテストを通過させるかまでを契約と運用設計に含めます（出典: 国税庁「令和7年版 法人税のあらましと申告の手引」）。

税務申告システムの発注形態はどれを選ぶべきですか？

結論として、標準的な税目と業務であれば既製品またはクラウドを第一候補にし、会計連携やワークフローだけを導入支援会社へ委託する形が現実的です。独自の税務計算、複雑なグループ通算、複数ERPとの深い連携が競争力や統制に直結する場合は、既製品の拡張やスクラッチ開発を検討します。

既製品は、法人税、消費税、地方税、償却資産、法定調書など、既に整理された申告業務を早く使い始めたい企業に向いています。法改正へのアップデート、バックアップ、基本的な帳票、電子申告機能をサービス側へ寄せられるため、自社で全てを保守する負担を抑えられます。一方で、標準画面に業務を合わせる必要があり、独自の承認経路や複雑なデータ変換は追加費用になりやすい点に注意が必要です。

会計やERPを入れ替える必要がない企業は、既存システムを残し、税務申告ソフトとCSV・API・標準ファイルで連携するハイブリッド方式を選べます。全社基盤の刷新を避けながら二重入力を減らせるため、予算とリスクを抑えやすい方法です。ただし、勘定科目、税区分、法人コード、事業所コード、会計期間の対応表を誰が管理するかを明確にしないと、連携後の手修正が増えてしまいます。

特殊な税務計算、独自のグループ管理、複数の海外・国内ERP連携、社内の職務分掌に合わせた承認など、標準機能では業務の正確性や統制を確保できない場合は個別開発を検討します。自由度が高い反面、税制改正の影響範囲を自社で持ち続けることになります。税務ロジックをコードへ埋め込むだけでなく、適用税率、対象期間、計算式、根拠資料、改定日を管理できる設計にし、税理士や業務責任者がレビューできる状態を作ります。

RFPと要件整理はどこまで準備して発注すべきですか？

RFPは、開発会社に希望機能を並べて送るだけの文書ではありません。対象範囲、現状の課題、データ、業務上の制約、検収条件、保守条件を同じ前提で比較するための発注資料です。完成した要件定義書がなくても発注できますが、現状業務と必須条件を整理しておくほど、見積もりのばらつきと後からの追加請求を抑えやすくなります。

対象税目は法人税、地方法人税、消費税、地方税、事業所税、償却資産、法定調書などに分け、どの申告書・別表・明細書まで作成するかを書きます。法人・事業所数、年間の申告件数、利用者の職種、税理士や外部専門家の関与、会計・給与・固定資産・請求システムの製品名と連携方式も必要です。さらに、e-TaxとeLTAXのどちらを使うか、電子署名の担当者、受信通知の保存方法、紙提出を含む代替手順も明記します。

機能要件は「できること」だけでなく「業務を完了できる条件」で書くと比較しやすくなります。例えば「会計データを取り込む」ではなく、「前月から追加された勘定科目と税区分のエラーを一覧で確認し、担当者が修正した履歴を残してから税額計算へ進められる」と記載します。この粒度なら、開発会社ごとの解釈の差を小さくできます。

税務データには給与や取引先情報などの機密情報が含まれるため、MFA、最小権限、職務分掌、通信・保存時の暗号化、バックアップ、監査ログ、脆弱性対応、再委託先の管理をRFPに入れます。クラウドの場合は、データの保管場所、障害時の復旧目標、ログの保存期間、サービス終了時のデータ返却形式と消去証明も確認します。

電子帳簿保存法については、クラウドであれば自動的に要件を満たすわけではありません。国税庁は、優良な電子帳簿の要件として訂正削除履歴の保存、帳簿間の相互関連性、取引年月日・金額・取引先による検索などを示しています（出典: 国税庁「優良な電子帳簿の要件」）。システム機能だけでなく、証憑の紐付け、運用規程、担当者教育、税務調査時のダウンロード対応を一体で確認します。

税務申告システムの検収は、画面をクリックして表示を確認するだけでは不十分です。過年度の実データまたは匿名化したデータを使い、税額、帳票、会計連携、権限、承認、電子署名、送信、受信通知、エラー時の再送を一連のシナリオで確認します。税理士や経理責任者が計算根拠を確認し、旧システムとの結果差分を説明できることを合格条件にすると、稼働後の不具合を減らせます。

税務申告システム開発の契約形態はどう選びますか？

契約形態は、作業の内容と成果物の確定度に合わせて選びます。要件が固まり、完成させる機能や検収条件を定義できる工程は請負、検討や調査、要件定義のように作業を通じて成果を決める工程は準委任が基本です。最初から全工程を一つの契約に押し込まず、要件定義、設計・開発、テスト・移行、運用保守を分ける多段階契約も選択肢になります。

請負契約では、何を完成させれば検収できるかを明確にします。対象画面、帳票、連携仕様、税務計算の対象範囲、テスト結果、操作マニュアル、移行データ、ソースコードや設計書の引渡し条件を成果物として定義します。仕様変更が発生した場合は、変更依頼の起票、影響範囲、納期と費用の再見積もり、承認者を決めておきます。税制改正による変更と、発注者都合の機能追加を同じ扱いにしないことも重要です。

準委任契約では、特定の完成物だけでなく、誰が何時間・何人日でどの作業を行うか、会議体、報告内容、成果の確認方法を定義します。要件定義では発注者側の業務担当者が判断を出さなければ進まないため、ベンダーへ丸投げせず、週次の意思決定者と回答期限を決めます。成果物の著作権、ノウハウの利用範囲、秘密情報の管理、再委託の承認条件も契約書と個別契約で確認します。

税務申告システムは稼働して終わりではありません。法改正対応、様式の更新、電子申告接続の変更、脆弱性修正、問い合わせ、障害対応、バックアップ復元を保守契約で定めます。年間保守費が初期開発費の一定割合になる見積もりもありますが、これは公的な標準料率ではないため、含まれる作業と時間、法改正の追加請求条件を確認します。

クラウドでは、契約終了時にデータをどの形式で何日以内に返却するか、バックアップをいつ消去するか、消去証明を発行できるかを明記します。特定ベンダーから移行できない状態は、将来の料金改定や事業方針変更への対応力を弱めます。データ項目一覧、API仕様、帳票定義、マスタ、操作ログの取り出し可否まで確認しておくと安心です。

税務申告システムの発注から稼働までの進め方

発注後は、要件定義、設計・開発、テスト・移行、稼働後の安定化という順で進めます。税務システムでは申告期限が動かせないため、機能の完成日だけでなく、過年度データでの検証日、利用者教育、並行運用、法改正時の確認日を逆算して計画する必要があります。

最初に、決算開始から申告・納税・証憑保管までの業務フローを時系列で書き出します。会計データをいつ締めるか、税区分を誰が確認するか、税理士へどの資料を渡すか、差し戻しをどう管理するか、送信後の受付結果をどこへ保存するかを整理します。担当者へのヒアリングだけでなく、実際に使っているExcelやチェックリスト、エラー対応メモを確認すると、属人化した手順を要件へ落とし込みやすくなります。

テストでは、正常系だけでなく、税区分が未設定の仕訳、修正申告、還付、複数事業所、グループ法人、締め後の訂正、電子署名の期限切れ、送信エラー、e-TaxやeLTAXの受付結果未取得などを扱います。過年度の申告データと新システムの計算結果を税目・別表・金額単位で照合し、差分の理由を説明できるようにします。計算ロジックをAIに任せる場合も、候補提示にとどめ、人による承認とログを残す設計にします。

本番稼働の直後に申告期限を迎える計画は避けます。可能であれば一つの法人や税目を先行対象にし、旧システムと新システムで同じデータを処理して差分を確認します。利用者教育では、通常操作だけでなく、差し戻し、修正、再送、担当者変更、障害時の連絡先まで訓練します。稼働判定会議では、未解決不具合、手作業の残り、代替提出手順、保守窓口を確認してから切り替えます。

税務申告システムの費用相場とコスト内訳

税務申告システムの費用は、既製品の利用料、導入支援、データ移行、連携開発、個別機能、テスト、保守を分けて考えます。公開価格は製品のライセンス部分に限られることが多く、受託開発の金額には標準価格がありません。以下はリサーチノートと公開価格、類似する会計・基幹システム開発の情報から整理した目安であり、特定の案件でそのまま適用できる確定価格ではありません。

公開価格の例では、PCAクラウド法人税は1ソフトのみのモデルで月額16,200円、会計と組み合わせたモデルで1ソフトあたり月額10,200円です。いずれも税抜で、導入指導・構築・データ移行は含まれないと案内されています（出典: ピー・シー・エー株式会社「PCAクラウド法人税 価格」）。また、NTTデータの達人シリーズでは、法人税、消費税、内訳概況書、電子申告の主要4タイトルをProfessional Editionでそろえたモデルが年間163,700円です（出典: 株式会社NTTデータ「達人シリーズ」）。

このため、1法人・少人数・主要税目に絞った既製品の利用料は年10万円台から数十万円が一つの目安になります。ただし、追加法人、同時接続数、税目、会計連携、データ移行、研修、保守を加えると総額は変わります。安い利用料だけでなく、5年間のライセンス、導入支援、保守、法改正対応、解約・移行にかかる費用まで合算します。

既製品の初期設定、会計連携、マスタ整備、過年度データ移行、操作研修などを含む導入支援は、案件の規模によって100万円から500万円程度が目安になります。複数法人、承認ワークフロー、周辺システムとの連携まで統合する場合は500万円から2,000万円程度、独自の税務計算や複数ERP、e-Tax・eLTAXとの個別連携を含むスクラッチ開発では1,500万円から5,000万円超のレンジも想定されます。

これらは税務申告システム単体の公的な標準価格ではなく、類似する会計・財務・基幹システムの開発規模から推定したレンジです。要件定義が全体の約10%、設計が10%から20%、開発が40%から60%、テストが10%から20%という工数配分を参考にしつつ、データ移行、法改正対応、税務専門家レビューの費用を別項目で出してもらいます。見積書に「一式」しかない場合は、作業単位と前提条件を追加で確認します。

初期費用が小さくても、毎年の保守、法改正対応、ユーザー追加、法人追加、ストレージ、サポート時間、連携先の仕様変更対応が積み上がることがあります。保守・運用費は初期開発費の年5%から15%程度とする推定がありますが、これも標準料金ではありません。障害対応の時間帯、復旧目標、改修の対象範囲、税制改正による対応が基本料金に含まれるかを必ず確認します。

比較表は、初期費用、年間利用料、導入支援、データ移行、連携、追加開発、教育、保守、法改正、解約時のデータ返却を同じ列でそろえます。例えば1年目だけでなく、3年目と5年目の累計を計算すると、クラウドとスクラッチ、標準運用とカスタマイズの差が見えやすくなります。金額が未確定の項目は、上限・算定条件・見直し時期を記載してもらいます。

委託先の選定と見積比較で確認すべきポイント

委託先は、製品を持つベンダー、導入支援会社、業務コンサルタント、個別開発に強いSI会社に分けて比較します。大切なのは知名度や機能数だけでなく、税務担当者と会計・IT担当者の間に入り、要件・データ・テスト・保守を一貫して進められる体制です。3社以上へ同じRFPを渡し、提案書だけでなくデモと質疑応答で確認します。

実績を確認するときは、「税務システムの経験があります」という説明で終わらせません。対象税目、法人・事業所数、利用者数、会計やERPとの連携方法、過年度データの移行量、e-Tax・eLTAXの送信、法改正後のリリース手順を質問します。NTTデータ、PCA、TKC、ミロク情報サービス、日本ICSなどの製品を候補にする場合も、自社の業務範囲に対応できる導入パートナーと保守担当を分けて確認します。

提案会社には、税理士や税務実務に詳しい担当者がプロジェクトへどの頻度で参加するか、計算ロジックのレビュー責任者は誰か、障害時に誰が判断するかも聞きます。営業担当だけでなく、プロジェクトマネージャー、アーキテクト、移行担当、保守担当と面談すると、提案時と稼働後の体制差を見つけやすくなります。

見積比較では、総額の安さよりも、同じ範囲を見積もっているかを確認します。要件定義、設計、開発、連携、データ移行、テスト、教育、稼働支援、保守を行単位に分け、工数、単価、期間、担当者、成果物を記載してもらいます。特に、会計データのクレンジング、税区分のマッピング、帳票の差分検証、電子署名や送信テスト、法改正対応を除外していないかを確認します。

提案内容の評価は、価格30%、要件適合30%、税務・電子申告の実績20%、体制と保守10%、セキュリティと移行性10%のように、社内で重み付けしておくと議論がぶれにくくなります。この割合は一例ですので、自社が重視する正確性、期限、複数法人、運用負荷に合わせて変更します。デモでは代表的な一つの申告書だけでなく、入力エラー、差し戻し、修正、再送、担当者交代のシナリオを実演してもらいます。

注意が必要なのは、「すべて対応できます」と言いながら対象税目や帳票、法改正対応の条件が書かれていない提案です。公開価格だけを強調し、導入・移行・保守を別見積もりにしている場合や、e-Tax対応を送信までではなくデータ出力だけで表現している場合も、比較条件をそろえ直します。税務計算をAIで完全自動化できると断定する提案も、レビューと責任分界を確認する必要があります。

契約前には、再委託先、個人情報の取扱い、脆弱性対応、インシデント通知、知的財産、契約終了時のデータ返却、損害賠償の範囲を法務・情報システム部門と確認します。税務部門だけで意思決定せず、経理、IT、セキュリティ、法務、利用現場を含む選定チームを作ると、導入後に問題になりやすい条件を早く発見できます。

よくある質問

税務申告システムの発注では、費用だけでなく、自社の税目・法人構成・既存システム・法改正への対応力を確認することが重要です。ここでは、発注前によく寄せられる質問へ直接回答します。

標準的な税目と業務であれば、法改正対応や電子申告機能を持つパッケージ・クラウドを第一候補にするのが現実的です。独自計算や複雑な連携が業務の正確性に不可欠な場合だけ、個別拡張やスクラッチを検討し、保守と法改正対応の費用まで含めて判断します。

既製品の利用料は、公開価格の例では年10万円台から数十万円が一つの目安です。導入支援・連携・移行は100万円から500万円程度、複数法人や周辺システムの統合は500万円から2,000万円程度、独自計算を含む大規模開発は1,500万円から5,000万円超のレンジが想定されますが、いずれも案件条件に基づく推定であり、確定価格ではありません。

現状の業務、対象税目、利用者、データ連携、困っている作業、必須条件、希望時期を整理すれば、最初のRFPは作成できます。税額計算や電子申告の細部は、税理士や導入候補へ確認しながら補い、発注後の要件定義で確定します。重要なのは、未確定事項を隠さず、質問事項と回答期限として管理することです。

必ずしも任せられるとは限りません。データ作成だけでなく、利用者認証、電子証明書、署名、e-Tax・eLTAXへの送信、受付通知の取得、エラー修正、再送、納付、証跡保存まで対応するかを確認します。デモや受入テストでは、正常な送信だけでなく、送信失敗と再送の手順も実演してもらいます。

まとめ

税務申告システムの発注・外注を成功させるには、まず既製品・クラウド・個別開発のどこまでが自社に必要かを見極めます。そのうえで、対象税目、会計・ERP連携、レビューと承認、e-Tax・eLTAX送信、証憑とログの保存、法改正対応をRFPへ落とし込みます。

発注前には、対象税目と法人・事業所数、既存システムとの連携、レビューと承認の流れ、法改正時の対応責任を決めます。未確定の事項は質問事項としてRFPに残し、候補会社から同じ条件で回答を集めることが、後からの追加費用を抑える近道です。

委託先の比較では、初期価格だけでなく、移行・テスト・保守・法改正・契約終了時のデータ返却まで含めた総保有コストを見ます。税務とITの双方を理解する体制、具体的な受入テスト、障害時の再送手順が提案に含まれているかを確認します。

費用は、公開されている製品利用料と、導入支援・移行・連携・追加開発・保守を分けて比較します。見積もりは3社以上から取り、価格だけでなく、税務実績、担当者の体制、受入テスト、変更管理、契約終了時のデータ返却まで同じ条件で確認することが大切です。申告期限から逆算した検証と並行運用を計画し、正確な申告を継続できる仕組みとして導入します。

▼全体ガイドの記事
・税務申告システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。