システム開発に使える補助金 ── 申請の現実と、使わない方がいい場合

「補助金は使えますか」。見積もりをお出ししたあと、かなりの確率で聞かれます。使える可能性はあります。ただ、制度の説明よりも手前に、知っておいたほうがいいことがあります。

この記事では、補助率が何分の幾つとか、上限が何百万円とか、そういう数字は書きません。書いた時点で古くなるからです。代わりに、申請すると実際に何が起きるかを書きます。

先に結論めいたことを書くと、補助金を使うかどうかの判断を分けるのは金額ではありません。日程に余裕があるかと、書類仕事をやる人が社内にいるか。この2つです。ここが揃っていないと、補助された額より失うもののほうが大きくなります。

先に、この記事の限界を書いておきます

3つ断っておきます。読み飛ばさないでください。

これは2026年9月時点の一般的な情報です。 システム開発に使える可能性がある制度には、IT導入補助金、ものづくり補助金、事業再構築の系統、自治体が独自に出しているものなどがあります。どれも年度ごとに要件が変わります。枠の名前が変わることも、なくなることもあります。

最新の要件は、必ず公募要領でご確認ください。 制度の公式サイトに出ている公募要領が、すべての根拠です。この記事を含め、解説記事は要約なので細かい条件が落ちています。判断の前に原文を読むか、認定経営革新等支援機関、商工会議所、自治体の窓口に確認してください。

採択を保証するものではありません。 申請すれば通るものではなく、審査があります。この記事にも、通るためのコツのようなことは書きません。

そのうえで、発注側の実務として知っておくと判断が変わることを並べます。制度の解説ではありません。制度がどうであれ共通して起きる、時間とお金と手間の話です。

なぜここまで慎重に書くかというと、補助金の解説記事は古い情報がそのまま残りやすいからです。検索で上位に出てくる記事が2年前の要件のまま、という状況は普通にあります。金額や補助率を覚えて相談に来られると、話が噛み合いません。数字は原文で、というのが一番確実です。

申請から入金まで、時間の順に並べる

補助金でいちばん誤解されているのは、金額ではなく時間の感覚です。

まず公募が出ます。要領を読み、事業計画を作ります。ここが軽く見られがちですが、何を作って、それで何がどう良くなるのかを、書類の形にする作業です。開発会社の見積書や構成資料も添付物として要ります。

計画書に何を書くかは制度ごとに違いますが、共通して聞かれるのは「いま何に困っていて、導入後に何がどう変わるか」です。ここは開発会社が代わりに書ける部分ではありません。自社の業務の話だからです。相談前に整理しておくことは開発会社に相談する前に、決めておくと話が早い3つのこととほぼ同じ内容になります。

出したあとは審査です。結果が出るまでの期間は制度によりますが、待ちます。この間に開発を先に始めていいかどうかは制度側のルール次第で、こちらの都合では動かせません。

採択されたら、交付決定という手続きがあります。ここがひとつの分岐点です。多くの制度では、交付決定より前に発注・契約した費用は対象外になります。「先に作り始めて、あとから申請する」ができない、ということです。

そして開発して、使い始めて、実績報告を出して、その審査が通って、ようやく入金です。最初の公募から入金まで、半年を超えることも普通にあります。

この間、誰が何をするのかを分けて書いておきます。制度によって細かい違いはありますが、役割の分かれ方はだいたい共通です。

段階	発注側（自社）がやること	開発会社に頼めること
申請の準備	公募要領を読む。事業計画を書く。社内の決裁を通す	見積書を出す。画面構成の資料を出す
審査・採択	待つ。落ちた場合の進め方を決めておく	着手できる時期を空けておく
交付決定・着手	交付決定を確認してから契約・発注する	決定を待ってから開発を始める
実績報告・入金	証拠書類を揃えて提出する。差し戻しに対応する	請求書や納品の記録を求められた形で出す

表の左の列は、代わりにやってくれる人がいません。ここを誰が担当するかが、実質的に一番大きな論点です。

「後払い」の意味は、全額を先に払うということ

ここがいちばん効きます。補助金は原則として後払いです。

つまり、開発費は先に全額を自社で支払います。補助されるのは、そのあとです。100万円のシステムを作るなら、100万円を先に用意する必要があります。手元の現金が要らなくなるわけではありません。

これを「実質の負担が減る」とだけ受け取ると、資金繰りの計画がずれます。減るのは最終的な負担であって、必要な運転資金ではない。ここを取り違えたまま話が進むと、交付決定のあとで支払いの相談が始まります。

出ていくお金の組み立て方は、1年目の総額で見るのが分かりやすいです。初期にいくら、月額にいくら。考え方はMVP開発の費用は、何で決まるのかに書きました。初期を抑えて月額に配分すると、一度に出ていく現金は小さくできます。

もうひとつ。入金のタイミングは読めません。実績報告に不備があれば差し戻されますし、再提出になればさらに先になります。入金を前提にした支払い予定は立てにくい、と考えておくほうが安全です。

資金繰りで見るなら、3つの数字を並べてください。開発費の総額。そのうち補助される見込み額。そして、支払いから入金までの月数。3つ目が抜けている計画書をよく見ます。1つ目を先に用意できるかどうかが、実際の可否を決めます。

つなぎ資金を借りるという選択肢もあります。ただ、その利息は補助の対象になりません。補助される額から利息を引いて、それでも見合うかを確認してください。制度によっては、条件を満たすと前払いに近い扱いが認められることもありますが、これも年度ごとに変わるので、公募要領で確認するしかありません。

採択されないことがある

審査があるということは、落ちることがあるということです。

採択率は制度によっても回によっても違います。公開されている数字も回ごとに動くので、ここでは挙げません。挙げたところで、次の回には当てはまりません。

実務として効くのは、落ちた場合にどうするかを先に決めておくことです。選択肢は3つあります。自己資金でそのまま進める。次の回に出し直して、その分だけ着手を遅らせる。今回は見送る。

出し直す場合、次の公募がいつ出るかは制度の側が決めます。年に数回ある制度もあれば、年度に一度の制度もあります。出し直しを前提にするなら、次がいつかを先に調べておいてください。半年待つことになるなら、それは実質的に「見送る」と同じです。

いちばん困るのは、決めないまま結果を待つことです。落ちた瞬間に「じゃあどうする」を考え始めると、そこからまた1ヶ月が消えます。

社内で稟議を通すときも、「採択されたら実施」ではなく「採択されなくてもこの範囲はやる」という形にしておくと、あとの意思決定が速くなります。決裁者が稟議書のどこを見ているかはシステム開発の社内稟議、何を書けば通るかに書きました。自己資金で進める場合の比べ方は社内システムは内製か外注かに、1年の総額で並べた表があります。

採択されたあとに増える仕事と、動かせない日程

採択は終わりではありません。ここから増える仕事があります。申請前には、あまり説明されない部分です。

実績報告。 何にいくら使ったかを、証拠書類と一緒に提出します。見積書、発注書、契約書、請求書、振込の控え。書類どうしの名称や日付の整合が見られるので、開発会社とのやり取りも、あとから説明できる形で残しておく必要があります。

導入後の報告。 制度によっては、導入から一定期間、効果の報告が続きます。年1回、数年にわたるものもあります。担当者が異動したあとも続く、という点に注意が要ります。引き継ぎ書に「この報告が何年まで残っている」と書いておかないと、忘れた頃に事務局から連絡が来ます。

対象にならない費用がある。 何が対象になるかは制度ごとに違いますが、ハードウェア、既存システムの改修、社内の人件費、リリース後の運用費などは、対象外になったり別枠になったりします。見積もりの全額が対象だと思って計画を立てると、差額が出ます。見積もりを項目に分けておくと判断しやすくなるので、分け方は業務システムの開発費用を、自分で見積もる方法を使ってください。

日程が制度の側に縛られる。 公募の締切、交付決定の時期、事業を終える期限。どれも制度が決めます。自社の都合で「来月から始めたい」と思っても、交付決定が2ヶ月先ならそれまで待つことになります。逆に、事業完了の期限が近い回に申請すると、そこから逆算した詰まった日程になることもあります。

書類の整合について、ひとつだけ具体的に書きます。見積書の日付が交付決定より前でも問題にならないことは多いのですが、契約書や発注書の日付が交付決定より前だと、そこで引っかかることがあります。見積もりをもらってから稟議を回し、承認が下りた日で発注書を作る、という普段どおりの流れが、そのまま不備になりうるということです。発注の日付をいつにするかは、申請を決めた時点で窓口に確認しておいてください。

事務の工数は、社内の誰かの時間です。誰がやるかを決めずに申請だけ決めると、たいてい一番忙しい人のところに落ちます。経理でも総務でも構いませんが、名前で決めてください。「みんなで」は、誰もやらないという意味になります。

使わない方がいい3つの場合

正直に書きます。次のどれかに当てはまるなら、補助金を使わないほうが早くて安いことがあります。

急いでいる場合。 交付決定を待つ数ヶ月のあいだ、業務の問題はそのまま残ります。今月困っていることを来月から改善したいなら、待つ時間のほうが高くつきます。残業代や、手作業で起きているミスの手直しに、毎月いくらかかっているか。その金額に待つ月数を掛けて、補助される見込み額と比べてください。

金額が小さい場合。 補助される見込み額と、申請・報告にかかる社内の工数を並べてください。担当者が合計で何十時間か使うなら、その人件費と見比べる価値があります。

事務をやる人がいない場合。 書類を集めて、期限を管理して、報告を出す。これを片手間でやると、本業のほうが止まります。専門家に頼む選択肢もありますが、その費用も計算に入れてください。

逆に、もともと来期に予定していた投資で、日程に余裕があって、社内に書類仕事を引き受けられる人がいるなら、使わない理由はありません。要は、急ぎかどうかと、人がいるかどうかの2点です。

判断を分ける聞き方をひとつ挙げます。「補助金が一切なかったとしたら、このシステムは作りますか。」答えが「作る」なら、制度は使っても使わなくても構いません。日程と人を見て決めればいい。答えが「作らない」なら、いったん止めたほうがいいと思います。補助を前提にした投資は、採択されなかった瞬間に宙に浮きます。

もうひとつ、よくある誤解を書いておきます。補助金が出ても、自己負担はゼロにはなりません。制度には補助されない部分が必ず残りますし、対象外の費用も出ます。「実質タダになる」という説明を受けたら、その根拠になっている公募要領の該当箇所を見せてもらってください。

ニカゲツはどうしているか

先に書いておくと、私たちは補助金の申請代行をしていません。申請書の作成も、事務局とのやり取りの代行も、業務として行っていません。

できるのは、申請に添える見積書や画面構成の資料を、必要な粒度でお出しすることです。「何画面で、何をするシステムか」を書面にする作業は通常の見積もりの過程で行っているので、そのまま使っていただけます。

もうひとつ、正直に書きます。IT導入補助金のように、あらかじめ登録された事業者のツールが対象になる制度があります。私たちはその登録をしていないため、その枠では対象になりません。他の制度で対象になるかどうかは制度側の要件次第で、私たちが判断できることではありません。

資料を作るときに気をつけているのは、あとで説明できる形にしておくことです。見積書は「システム開発一式」ではなく、画面や機能の単位で分けます。対象になる費用とならない費用が分かれているほうが、報告の段階で楽になります。この分け方は補助金のためというより、そもそも見積もりとしてそうあるべきだと考えています。

申請を検討している場合は、認定経営革新等支援機関、商工会議所、自治体の相談窓口に先に当たるのが確実です。そのうえで見積もりや資料が必要になったら、お問い合わせからご連絡ください。料金のページには、初期費用に含まれるものと含まれないものを分けて出しています。対象外になりやすい費用を切り分けるときの材料になります。何画面でいくらになるかの目安は、費用シミュレーターでも出せます。

最後にひとつだけ。補助金が出るかどうかで、作るかどうかを決めないでください。制度に合わせて要件を膨らませたシステムは、たいてい使われません。困っていることが先にあって、たまたま制度が合えば使う。その順番のほうが、1年後に振り返ったときに納得できます。