自社で使うシステム（ソフトウェア）の耐用年数は、税法上5年です。
開発費は「無形固定資産（ソフトウェア）」として計上し、5年かけて減価償却するのが基本です。
ただし、これはあくまで会計上の年数です。
システムを動かしているフレームワーク、プログラム言語、OSには、それぞれ提供元のサポート期限があり、多くは5年より短い周期で更新が必要になります。
この記事では、前半でソフトウェアの耐用年数と勘定科目の基本を整理し、後半で「5年使い続けるために、途中で何が必要になるのか」を、当社が業務システムの開発で使っているLaravel・PHP・Ubuntuを例に解説します。
デモ画面公開中！
この記事に関連するサンプル画面
経理・支払管理システム画面を触ってみるソフトウェアの耐用年数は用途で決まる
税法上、ソフトウェアの耐用年数は用途によって次のように分かれています。
| 用途 | 耐用年数 |
|---|---|
| 自社で利用するソフトウェア（業務システムなど） | 5年 |
| 複写して販売するための原本 | 3年 |
| 研究開発用のソフトウェア | 3年 |
開発会社に依頼して作った社内の業務システムや、自社サイトの予約・会員管理の仕組みなどは、基本的に「自社で利用するソフトウェア」にあたり、5年で償却します。
金額が小さい場合の扱い
取得価額が小さい場合は、5年かけて償却せずに済む扱いもあります。
- 10万円未満：使い始めた年度に、全額を費用（損金）にできる
- 20万円未満：一括償却資産として、3年で均等に費用にできる
- 中小企業者等の少額減価償却資産の特例：一定の要件を満たす中小企業者等は、取得価額が一定額未満のものを、使い始めた年度に全額費用にできる（年間合計300万円まで）
少額減価償却資産の特例は、令和8年度の税制改正で、2026年4月1日以後に取得するものから、上限が「30万円未満」から「40万円未満」に引き上げられました。
あわせて、対象となる法人の従業員数の基準が「常時使用する従業員数500人以下」から「400人以下」に変わり、適用期限も3年延長されて2029年3月31日（令和11年3月31日）までとなっています。
2026年3月31日以前に取得したものは、改正前の「30万円未満」が基準になる点に注意してください。
SaaS・クラウドサービスは資産ではなく費用
月額や年額で利用料を払うクラウドサービス（SaaS）は、ソフトウェアを「取得」しているわけではないため、原則として資産には計上せず、支払った期の費用として処理します。
勘定科目は「支払手数料」「通信費」など、会社の方針に合わせて設定するのが一般的です。
個別開発とSaaSのどちらを選ぶかで、費用の計上のされ方が変わることは、導入を検討する段階で知っておきたい点です。
5年間の総額での比べ方はSaaSパッケージとスクラッチ開発の5年間コスト比較で解説しています。
導入後のバージョンアップや改修費用の扱い
開発後にかかる費用は、内容によって扱いが分かれます。
法人税基本通達（7-8-6の2）では、プログラムの修正などが不具合の除去や今の効用の維持にあたる場合は「修繕費」として費用に、新しい機能の追加や機能の向上にあたる場合は「資本的支出」として資産に計上する、という考え方が示されています。
フレームワークや言語のバージョン更新がどちらにあたるかは、作業の中身（今の機能を保つための対応か、機能追加を伴うか）によって変わります。
見積もりを受け取った段階で、作業内容の内訳を開発会社に出してもらい、顧問税理士に確認しておくと安心です。
でも、システムは「5年そのまま」では使い続けられない
会計上は5年で償却しますが、システムが5年間なにもせずに安全に動き続けるとは限りません。
業務システムは、次のような「部品」を組み合わせて動いています。
- フレームワーク：システムを効率よく作るための土台（例：Laravel）
- プログラム言語：システムを書いている言語（例：PHP）
- OS：サーバーを動かす基本ソフト（例：Ubuntu）
- データベース：データを保存する仕組み（例：MySQL）
それぞれに提供元のサポート期限があり、期限を過ぎると、新しく見つかった脆弱性（セキュリティ上の弱点）が修正されなくなります。
システムは急に止まるわけではありませんが、危険を抱えたまま使い続ける状態になります。
Laravel（フレームワーク）：セキュリティ修正は2年
Laravelは、公式のサポートポリシーで「各バージョンのバグ修正は18か月、セキュリティ修正は2年」と定めています。
新しいメジャーバージョンはおおむね毎年公開されており、2026年11月時点の最新はLaravel 13です。
| バージョン | 公開 | セキュリティ修正の終了 |
|---|---|---|
| Laravel 10 | 2023年2月 | 2025年2月 |
| Laravel 11 | 2024年3月 | 2026年3月 |
| Laravel 12 | 2025年2月 | 2027年2月 |
| Laravel 13 | 2026年3月 | 2028年3月 |
PHP（プログラム言語）：各バージョン約4年
PHPは、各バージョンが2年間のアクティブサポートと、その後2年間のセキュリティサポートを受けます。
以前はセキュリティサポートが1年（合計3年）でしたが、2024年に方針が変わり、当時サポート中だったPHP 8.1以降は合計約4年になりました。
サポート終了日も、その年の12月31日にそろえられています。
| バージョン | 公開 | サポート終了 |
|---|---|---|
| PHP 7.4 | 2019年11月 | 2022年11月 |
| PHP 8.0 | 2020年11月 | 2023年11月 |
| PHP 8.1 | 2021年11月 | 2025年12月31日 |
| PHP 8.2 | 2022年12月 | 2026年12月31日 |
| PHP 8.3 | 2023年11月 | 2027年12月31日 |
| PHP 8.4 | 2024年11月 | 2028年12月31日 |
| PHP 8.5 | 2025年11月 | 2029年12月31日 |
PHP 8.2は2026年12月31日でサポートが終わります。
8.2で動いているシステムは、早めに更新の予定を確認しておきたいところです。
古いPHPで動くシステムを直すか作り直すかの判断は、PHPのバージョンアップ｜古いシステムを直すか作り直すかで解説しています。
Ubuntu（OS）：標準サポートは5年
サーバーでよく使われるUbuntuは、長期サポート版（LTS）が2年ごとに公開され、標準のセキュリティサポートは5年です。
有料のUbuntu Proを使うと、さらに長くセキュリティ更新を受けることもできます。
| バージョン | 標準サポートの終了 |
|---|---|
| Ubuntu 20.04 LTS | 2025年5月 |
| Ubuntu 22.04 LTS | 2027年5月 |
| Ubuntu 24.04 LTS | 2029年5月 |
| Ubuntu 26.04 LTS | 2031年5月 |
例：2023年に作ったシステムは、5年の間に何が起きるか
たとえば、2023年の春に、その時点で新しかった組み合わせ（Laravel 10、PHP 8.1、Ubuntu 22.04）でシステムを作ったとします。
会計上は2028年まで、5年で償却していくシステムです。
| 時期 | 起きること |
|---|---|
| 2023年春 | システム稼働（Laravel 10／PHP 8.1／Ubuntu 22.04） |
| 2025年2月（約2年後） | Laravel 10のセキュリティ修正が終了 |
| 2025年12月末（約3年後） | PHP 8.1のサポートが終了 |
| 2027年5月（約4年後） | Ubuntu 22.04の標準サポートが終了 |
| 2028年春 | 会計上の5年が経過 |
このように、会計上の5年が終わるまでに、フレームワーク・言語・OSのすべてが一度はサポート切れを迎えます。
5年間安全に使い続けるには、途中で少なくとも1〜2回は更新作業が必要になる計算です。
年に1回の「バージョン点検」をおすすめする理由
サポート切れに慌てないためには、定期的に「今のシステムが何で動いているか」を確認しておくことが大切です。
目安として、次のような進め方をおすすめします。
年に1回：バージョンとサポート期限を確認する
フレームワーク、言語、OS、データベースのバージョンと、それぞれのサポート期限を一覧にしておきます。
保守を依頼している会社があれば、年に1回、この一覧を出してもらうだけでも十分です。
【バージョン点検メモ（例）】 □ フレームワーク：名称／バージョン／セキュリティ修正の終了時期 □ プログラム言語：名称／バージョン／サポート終了時期 □ OS：名称／バージョン／標準サポート終了時期 □ データベース：名称／バージョン／サポート終了時期 □ 次に更新が必要になる部品と、その時期
2〜3年に1回：更新作業を計画に入れる
上の例のとおり、フレームワークは約2年、言語は約4年で更新の時期がきます。
期限の直前に慌てて対応すると、作業が集中して費用も膨らみがちです。
2〜3年に1回は更新作業がある前提で、予算と時期をあらかじめ決めておくのが現実的です。
小さな更新をこまめに行うほうが、何年も放置してまとめて上げるよりも、一度の作業量とリスクを抑えやすくなります。
5年目：作り直すか、更新を続けるかを判断する
会計上の償却が終わるタイミングは、システムを見直すきっかけにもなります。
業務に合っていて、更新も問題なく続けられているなら、そのまま使い続けることもできます。
一方で、業務が変わってシステムの外での作業が増えている場合は、作り直しを検討する時期かもしれません。
作り直す場合の費用と進め方は基幹システムのリプレイス｜費用相場・進め方でまとめています。
開発費だけでなく「使い続ける費用」も予算に入れる
システムの導入を検討するときは、開発費と月々の保守費に目が向きがちです。
しかし実際には、2〜3年ごとのバージョン更新の費用もかかります。
- 開発費（会計上は5年で償却）
- 月々の保守費用（障害対応、問い合わせ対応など）
- 数年ごとのバージョン更新の費用
- サーバー費用などのランニングコスト
見積もりを受け取る段階で、「保守費用にバージョン更新は含まれているか」「含まれていない場合、どのくらいの周期で、どの程度の作業が想定されるか」を開発会社に確認しておくと、後から想定外の出費に悩まされずに済みます。
保守費用の相場はシステム保守費用の相場で、保守に含まれる作業はWebシステム保守とはで解説しています。
まとめ
- 自社で使うソフトウェアの耐用年数は、税法上5年
- 中小企業者等の少額特例は、2026年4月1日以後の取得分から40万円未満に引き上げ
- SaaSの利用料は資産ではなく、原則として費用で処理する
- 一方で、Laravelは約2年、PHPは約4年、Ubuntu LTSは5年でサポートが切れるため、システムは5年そのままでは使い続けられない
- 年に1回のバージョン点検と、2〜3年に1回の更新を計画に入れておくのが現実的
会計処理の個別の判断については、顧問税理士にご確認ください。
みんなシステムズでは、今お使いのシステムのバージョン確認や、サポート切れに向けた更新のご相談を承っています。
「自社のシステムが何で動いているか分からない」「他社が作ったシステムだが更新できるか知りたい」という段階でも構いません。
サーバーやソースコードを確認させていただいたうえで、現在のバージョンと更新が必要な時期を整理します。
お気軽にご相談ください。
デモ画面公開中！
実際の画面で、機能と操作感を確かめられます経理・支払管理システム画面を触ってみる 
