企業向け / 補助金・実装

補助金でシステム開発した企業向け|監査証跡の保存期間・版管理・契約・納品台帳

補助金でシステムを開発した企業の経営者・事業責任者向けに、保存満了日の決め方、要件・契約・納品の版管理、証跡台帳、30分再現テストを解説します。

この記事の対象

補助金でシステムを開発した企業の経営者・事業責任者・兼任情シス(実績報告前後、または担当者・開発会社の変更を控える方)

公開日:2026-07-21

最終更新日:2026-07-21

編集:はたらく士業さん編集部(GXO株式会社)

ARTICLE BODY

記事本文

ここから、判断に必要な確認項目と実務の進め方を解説します。

補助金でシステムを作った企業にとって、実績報告の提出は証跡管理の終了ではありません。担当者の退職、開発会社の変更、クラウド契約の解約、共有ドライブの整理が重なると、数年後に『この請求はどの機能の対価か』『検収した版はどれか』を説明できなくなります。

経営者が避けるべき判断ミスは、PDFを一つのフォルダへ保存しただけで監査対応済みと考えることです。必要なのは、制度正本から保存満了日を算出し、交付決定、要件、見積、契約、変更、納品、検収、請求、支払いを同じ証跡IDでたどれる状態です。システム本体についても、検収時の版と稼働事実を再現できなければなりません。

この記事は、実績報告時に集める書類そのものを扱う証憑チェックリストの次工程です。保存期間、版管理、権限承継、30分再現テストを経営管理へ落とします。書類やアカウントに欠落がある交付決定済み案件は、実装を続ける前にレスキュー窓口で回収可能性を整理してください。

保存期間は『5年』だけ覚えず、自社案件の満了日を記録する

2026年7月21日に確認した中小企業省力化投資補助金(一般型)の実績報告手引きと、新事業進出補助金の補助事業の手引きは、いずれも帳簿・証拠書類を、補助事業完了日の属する年度の終了後5年間保存する旨を示しています。ただし、制度、公募回、交付規程、完了日、事業者の決算年度によって確認すべき正本と起算点が変わるため、別制度にも数字だけを流用してはいけません。

証跡台帳の先頭に、制度正式名、公募回、交付規程・手引きの版とURL、交付決定日、事業完了日、決算月、保存義務の根拠条項、保存満了日、確認者、確認日を置きます。『実績報告から5年』のような略記は避け、正本の文言から自社の満了日を計算し、根拠PDFも同じ台帳へ固定します。更新版が出たら旧版を消さず、どの版を自社案件へ適用したかを残します。

補助金の保存期間だけで廃棄日を決めるのも危険です。税務、会社法上の記録、契約、訴訟・瑕疵対応、個人情報、営業秘密、社内規程など、別の保存・削除要件が長い場合があります。最終廃棄は経理・法務・情報管理の各責任者が確認し、この記事だけで法的な保存年限を決めないでください。

  • 正本:制度名、公募回、交付規程、手引きの版・更新日・URL
  • 起算:事業完了日、完了日の属する決算年度、その年度の終了日
  • 満了:根拠条項から算出した日付、算出者、確認者、次回点検日
  • 重複要件:税務・契約・紛争・セキュリティ等の保存期間と削除条件

監査証跡台帳の10列:ファイル一覧ではなく因果関係を残す

フォルダに書類がそろっていても、どの計画・機能・金額に対応するかを説明できなければ調査に時間がかかります。台帳は一つの支出または成果物を一行とし、証跡ID、事業計画ID、要件ID、発注先、経費区分、金額、書類の流れ、成果物、保管先、確認状態を結びます。

たとえばEV-023を『受注データ連携機能』とし、申請時の効果仮説、見積項目、契約条項、変更承認、リリース番号、検収テスト、請求明細、振込記録へ同じIDを記載します。第三者が一行を選び、なぜ必要だったか、何を発注し、何が納品され、誰が合格とし、いくら支払ったかを順に開ける状態が目標です。

紙の原本、電子原本、事務局へ提出した変換版は別物として扱います。電子契約やメール原本を印刷物だけに置き換えず、原本の形式、取得元、取得日時、保管責任者を残します。省力化一般型の現行手引きは、経費別・発注先別に時系列で整理し、提出電子データと紙媒体を保管する方法を具体的に示しています。自社回次の手引きに従い、足りない独自列を追加します。

  • 1. 証跡ID 2. 計画・要件ID 3. 発注先 4. 経費区分 5. 金額
  • 6. 見積→契約→変更→納品→検収→請求→支払いの参照先
  • 7. 成果物・リリース番号 8. 原本種別 9. 保管先・権限 10. 確認者・確認日

3つの版を分ける:交付決定版・実装版・実績報告版

システム開発では、要件、画面、金額、工程が更新されます。最新版だけを残すと、交付決定時に何を作る予定だったか、どの変更を承認後に実行したか、実績報告ではどの範囲を申告したかを比較できません。交付決定版、承認済みの実装版、実績報告版を別の基準線として固定します。

変更台帳には変更ID、変更前後、理由、事業目的・効果・経費・期限への影響、申請・照会の要否、事務局回答、社内決裁、実装開始日を記録します。承認や確認が必要な変更は、回答前の実装を停止する条件も置きます。計画変更・ベンダー変更の確認順と同じ差分項目を使えば、制度側と開発側の変更履歴が分断しません。

システム本体はリリース番号、ソースコードのコミットまたは納品版、データベース変更、構成、外部サービス、設定、テスト結果を固定します。画面キャプチャだけでは裏側の版を示せないため、検収日時、環境、URL、テストデータ条件、実行者と対応させます。ハッシュ値は改変検知の補助になりますが、それだけで内容の真正性や制度適合を証明するものではありません。

  • 交付決定版:承認された計画、経費、見積、期限の基準線
  • 実装版:承認済み変更を反映した要件、契約、リリース、テスト
  • 実績報告版:実際に納品・検収・支払い・申告した範囲
  • 差分表:機能、金額、日付、効果、承認根拠を三版で比較

ベンダー退場後も開ける権限設計:会社が証跡を保有する

監査証跡を開発会社のGoogle Drive、個人メール、担当者だけが入れるクラウドへ置くと、契約終了後に取得不能になります。保管基盤は事業者名義とし、社内管理者を二名以上置き、MFAの復旧方法、退職・異動時の引き継ぎ、定期エクスポート、バックアップ復元を確認します。

契約・発注時には、納品対象、ファイル形式、原本の返却、ソース・設計・テスト・ログの引き渡し、利用権・第三者ライセンス、アカウント移管、質問対応期間、契約終了時の削除証明を定めます。技術成果物の回収項目はベンダー引き継ぎチェックリストを使い、補助金証跡IDとの対応も納品条件にします。

個人情報や認証情報を含むため、全社員が全証跡を閲覧できる状態も適切ではありません。閲覧、更新、承認、廃棄の権限を分け、アクセスログと年次棚卸しを残します。保持し続けるバックアップにも削除・暗号化・鍵管理のルールが必要です。保存義務は、無制限な複製を正当化するものではありません。

  • 事業者:保管基盤、保存満了日、アクセス承認、最終説明責任
  • 開発会社:技術成果物、版、テスト、納品一覧、移管手順
  • 士業・支援者:制度正本、申請・変更・報告書類、照会記録
  • 経理:契約・請求・支払い原本、経費区分、決算年度

30分再現テスト:10項目を0・5・10点で採点する

保管の品質はファイル数ではなく、担当外の管理者が30分以内に一件を説明できるかで測ります。無作為に一つの経費または機能を選び、正本、必要性、取引、変更、成果、検収、支払い、版、権限、満了日をたどります。各項目を0点=ない・開けない、5点=あるが対応や確認者が曖昧、10点=原本とIDで再現できる、で採点します。

80〜100点は通常運用、60〜79点は期限を決めて補修、59点以下は経営者へ報告し、新規変更・廃棄・ベンダー退場を一時停止します。総点が高くても、交付決定正本、契約・支払い原本、検収版、保存満了日のいずれかが0点なら赤判定です。平均点で重大欠落を隠さないためです。

会計検査院は、実地検査で関係帳簿や提出外の書類を調べ、担当者・関係者から説明を聞き、財産や事業の実態を確認する方法を案内しています。したがって、台帳を見せるだけでなく、担当者が同じ説明をし、システムの版と稼働実態へ到達できるかをテストします。結果は四半期ごとと、担当者・ベンダー・保管基盤の変更前後に残します。

  • 正本、事業上の必要性、見積・契約、変更承認、納品物
  • 検収結果、請求・支払い、システム版、保管権限、保存満了日
  • 80〜100点=運用継続/60〜79点=補修/59点以下または重大0点=停止・救済判断

欠落が見つかったとき:後付け作成ではなく事実と代替証拠を分ける

不足書類が見つかっても、過去の日付へ遡った発注書、検収書、議事録を作ってはいけません。何が存在しないか、いつ判明したか、誰に確認したかを欠落記録へ残し、メール原本、電子契約履歴、リポジトリ履歴、クラウド監査ログ、銀行記録、当時のバックアップなど、実在する代替証拠を集めます。後日作成した説明書は、当時の原本と区別し、作成日と根拠を明示します。

次に、制度事務局への照会、契約上の回収、技術的な復元を分けます。支援者は制度上必要な証拠と照会、開発会社は成果物と版の復元、事業者は決裁・原本・説明責任を担います。自己判断で『同じ内容だから問題ない』と結論づけません。

GXOの一次判定では、10項目スコア、重大欠落、残存アカウント、ベンダー連絡可否、制度と期限を確認し、回収、代替立証、再検収、事務局照会、停止のどれを先に行うかを整理します。案件受付へ制度名、公募回、交付決定日、欠けている証跡、保管先を送ってください。法務・税務・申請判断は該当専門家および事務局と連携します。

まとめ:保存ではなく『説明を再現できる状態』を経営資産にする

補助金システム開発の監査証跡は、PDFの倉庫ではありません。保存満了日、三つの版、証跡ID、事業者名義の権限、30分再現テストをそろえて初めて、担当者やベンダーが変わっても説明できます。

この管理は補助金対応だけでなく、保守会社の変更、追加開発、セキュリティ事故、M&Aや事業承継時の技術調査にも再利用できます。欠落がある場合は後付けで整える前に、事実を保全し、制度・契約・技術を分けて回収方針を決めてください。

交付決定済みで証跡や版が散在している企業はレスキュー窓口から現状を確認し、案件受付へ10項目の点数と重大欠落を送ってください。GXOは診断・整理・技術的な復元と実装支援を担当し、制度判断は支援者・事務局へ接続します。

よくある質問

補助金の書類はすべて5年間保存すれば十分ですか?

一律には判断できません。現行の省力化一般型と新事業進出の手引きには事業完了日の属する年度終了後5年間という記載がありますが、自社の制度、公募回、交付規程、決算年度を正本で確認し、税務・契約等の別要件も照合してください。

クラウドストレージへ保存すれば原本は捨てられますか?

自己判断で廃棄しないでください。紙・電子の扱いは制度の手引きと社内の文書管理、税務・法務要件で確認します。省力化一般型の現行手引きは提出電子データと紙媒体の保管方法を示しています。

システムは更新され続けます。どの版を残しますか?

少なくとも交付決定版、承認済み実装版、実績報告・検収版を固定し、変更ID、リリース番号、テスト、承認根拠を対応させます。最新版だけを残さないことが重要です。

過去の検収書が見つからない場合、いま作り直せますか?

過去の日付へ遡って作成してはいけません。欠落の事実を記録し、当時のメール、テスト、リポジトリ、監査ログ等を保全します。後日説明書は作成日と根拠を明示し、事務局・専門家へ扱いを確認してください。

出典・公式情報

制度の要件・金額・期限は年度や公募回で変わります。最終更新日(2026-07-21)時点の公式情報に基づいて執筆していますが、申請・契約の前に必ず公式サイトで最新情報をご確認ください。