ソフトウェアの定義と3つの区分｜コンテンツとの線引きと会計処理の出発点

執筆　公認会計士・税理士 鈴木佑也

※本記事は2026年10月7日時点の公表資料に基づきます。

会計上の「ソフトウェア」とは：プログラムと関連文書まで含む

研究開発費等に係る会計基準では、ソフトウェアを、コンピュータに仕事をさせる命令の組合せとして表されたプログラムなどと位置付けています。日々の会話で「ソフト」というと画面に表示されるアプリだけを思い浮かべがちですが、会計ではもう少し広く捉えます。

実務の詳細を定めた移管指針第8号「研究開発費及びソフトウェアの会計処理に関する実務指針」（旧会計制度委員会報告第12号）は、ソフトウェアの範囲を次の2つとしています。1つ目はコンピュータに特定の処理を実行させるプログラム、2つ目はシステム仕様書やフローチャートなどの関連文書です。つまり、要件定義書や設計書を作るための作業時間も、ソフトウェアの原価を構成しうるということです。

図1　プログラムと関連文書はソフトウェアに含め、処理されるデータや他の無形資産は別に扱います

ここで押さえたいのは、のれんや特許権のような他の無形資産は、この基準の対象ではないという点です。特許を取得したアルゴリズムを組み込んだプログラムであっても、特許権そのものは特許権として、プログラム部分はソフトウェアとして、それぞれ判断します。

また、家電や工作機械の中に組み込まれて、その機械と一体となって動く制御用のプログラムは、独立したソフトウェアではなく機械装置などの一部として扱います。この論点は購入時の取得価額を扱う記事で詳しく説明します。

関連文書まで範囲に含めることには実務上の意味があります。たとえば、ある会社が自社利用の販売管理システムを作るために、要件定義に300時間、設計に500時間、プログラミングとテストに1,200時間をかけたとします。資産計上の要件を満たした後の作業であれば、要件定義や設計の時間も「文書を作っただけ」として除くのではなく、ソフトウェアの原価として集計の対象になります。設計書を軽視して費用に落としてしまうと、資産の金額が過小になり、その後の償却費の計算も狂ってしまいます。

反対に、要件や設計を固める前の検討、つまりそもそも作るかどうかを決めるための調査や比較の費用は、自社利用であれば確実性が認められる前の段階に当たることが多く、資産には入りません。範囲に含まれることと、資産に計上できることは別の問題だと意識しておくと、判断がぶれにくくなります。

図2　仕様書や設計書もソフトウェアの一部として原価を集めます

用語	この記事での意味
プログラム	コンピュータに処理をさせる命令の集まり
関連文書	仕様書・設計書・フロー図など、プログラムと一体で作る文書
コンテンツ	処理される情報の中身（データ・画像・音楽・映像など）
製品マスター	複写して製品を作るための元になるソフトウェア
ソフトウェア仮勘定	制作途中のソフトウェアの原価を集める無形固定資産の勘定

コンテンツは別物：データ・映像・音楽はソフトウェアに含めない

ソフトウェアとよく混同されるのがコンテンツです。ソフトウェアは「処理する側」の道具で、コンテンツは「処理される側」の情報そのものです。たとえば、データベースソフトが管理している商品情報、動画配信サービスで流れる映像、ゲームの中で鳴る音楽は、いずれもコンテンツに当たります。

実務指針も、コンテンツはソフトウェアとは別のものとして扱い、ソフトウェアの規定の対象には含めないとしています。コンテンツの価値はプログラムの機能ではなく情報の中身から生まれるため、将来の収益との結び付き方も違うからです。

図3　「処理する側」か「処理される中身」かで見分けます

身近な例で考えてみます。ある通販会社が、商品検索の仕組み（データベースソフト）と、そこに登録された約12万件の商品情報を持っているとします。検索の仕組みはソフトウェアとして資産計上の要否を判断しますが、商品情報はコンテンツであり、ソフトウェアの資産計上要件をそのまま当てはめることはしません。

図4　同じシステムの中でも、器（ソフト）と中身（データ）は区別して考えます

この区別は、決算書の数字にも影響します。ソフトウェアとコンテンツでは、資産として持つかどうかの判断基準、償却の期間、減損の考え方が変わりうるためです。最初の段階で「どちらの原価なのか」を分けて記録しておくと、後で按分に悩まずに済みます。

もう一つの注意点は、コンテンツだからといって必ず費用になるわけではないことです。コンテンツは別の資産として、その性質に応じた基準や会計慣行で扱われます。たとえば販売用の映像や楽曲であれば棚卸資産などとして処理されることがありますし、社内で使うデータの整備費用であれば多くは発生時の費用になります。この記事ではソフトウェア側の判断に絞って説明しますが、コンテンツを「ソフトウェアではない」と判断した後にも、別の検討が待っていることを覚えておいてください。

一体不可分のときの扱い：主な性格でどちらかに寄せる

とはいえ、現実のサービスではソフトウェアとコンテンツが分かちがたく結び付いていることもあります。そこで実務指針は、両者が経済的にも機能的にも一体不可分といえる場合には、まとめて1つのものとして扱ってよいとしています。

一体不可分かどうかの目安は、「一方の価値がなくなると、もう一方の価値もなくなる関係にあるか」です。たとえば、特定の診断データがなければ全く動かない診断ソフトで、データだけを取り出しても他に使い道がないような場合は、一体と考えやすくなります。

図5　片方の価値がなくなるともう片方も価値を失うなら、一体として主な性格で判断します

一体として扱う場合も、何となく合算するのではなく、その組合せの「主な性格」がソフトウェアなのかコンテンツなのかを判断し、どちらか一方とみなして処理します。主な性格は、価格の構成、制作にかかった原価の割合、顧客が何に対して対価を払っているかといった観点から判断するのが自然です。たとえば、診断ソフトの制作原価がプログラム1,500万円、診断データの整備500万円で、顧客も診断の機能に対価を払っているなら、主な性格はソフトウェアと考えます。判断の根拠とした数字や理由は、メモでよいので決算資料と一緒に保管しておきます。主な性格の判断は一度決めたら終わりではありません。追加開発でデータ整備の比重が大きくなるなど、構成が大きく変わったときは、判断を見直す必要がないかを確認します。

ゲームのように、プログラムとキャラクター・シナリオ・音楽などのコンテンツが同時に高度に組み合わされて作られる商品もあります。この場合でも、制作の工程でプログラム開発とコンテンツ制作がチームや工程として分かれているなら、制作費の集計も分けておくのが合理的と考えられています。ゲーム特有の論点は、ゲーム制作費の会計処理｜計上科目・制作費の範囲・資産計上の開始時点で扱います。

図6　ゲームは両者が同時に作られますが、工程が分かれていれば制作費も分けて集めます

ベンダーとユーザーで線引きの考え方が違う理由

ソフトウェアとコンテンツの線引きは、作る側（ベンダー）と使う側（ユーザー）とで、求められる精度が異なります。

ベンダーは自ら制作しているので、通常はプログラムとコンテンツを別々に把握でき、原価計算の単位も分けるのが一般的です。たとえば、ある開発会社がプロジェクトP-205で総額5,000万円をかけたとします。作業報告にプロジェクトコードと「プログラム」「コンテンツ」の区分を入れておけば、プログラム制作3,600万円、画像・データ制作1,400万円と自然に分けられます。どうしても分けられない場合に限り、主な性格でどちらかとみなします。

ベンダーに厳しめの区分が求められるのは、作り手として原価の中身を一番よく知っている立場だからです。区分が曖昧なまま全額をソフトウェアに入れてしまうと、コンテンツ部分まで同じ年数で償却したり、資産性を同じ基準で判断したりすることになり、利益の期間配分がずれます。作業報告の入力項目を1つ増やすだけで防げることが多いので、開発の初期に仕組みを決めておくのが効率的です。

図7　作業報告にプロジェクトコードとともに「ソフト」「コンテンツ」の区分を持たせると集計が楽になります

一方、ユーザーにとっては、購入した製品のどこまでがプログラムで、どこからがデータなのかを見極めるのは簡単ではありません。概念上は線を引けても、実際に当てはめようとすると混乱しやすいため、ユーザーは一体として扱い、主な性格を見てソフトウェアかコンテンツのどちらかで処理する方法が実務上認められています。ただし、契約で価格が分かれているなど、両者の経済価値をはっきり分けられるなら、区分して処理することもできます。

図8　ユーザーは主な性格で一体処理するのが通常で、価値を明確に分けられるときだけ区分します

架空の例で確認します。ある会社が、翻訳エンジンと専門用語の辞書データがセットになった翻訳ソフトを総額1,200万円で購入しました。見積書の内訳では翻訳エンジン部分が960万円、辞書データが240万円です。価格の8割がエンジン部分であり、利用者も主に翻訳機能に価値を見いだしているので、主な性格はソフトウェアと判断し、全体を自社利用のソフトウェアとして検討します。もし辞書データが独立して他の用途にも使え、価格も明確に分かれているなら、区分して処理する選択肢もあります。

ユーザー側で区分処理を選ぶ場合は、按分の根拠となる見積書や契約書の内訳を保存し、翌期以降も同じ考え方で処理を続けることが大切です。年度によって一体処理と区分処理を使い分けると、期間比較ができなくなり、恣意的な処理だと受け取られるおそれもあります。迷ったときは、まず一体処理を前提に主な性格を判断し、明確な内訳があるときだけ区分を検討する、という順番で考えると無理がありません。

図9　架空の数値です。価格の大半が翻訳エンジン部分なので、主な性格はソフトウェアと判断します

区分は「制作目的」で決める：3区分と主な担い手

ソフトウェアに当たると判断できたら、次は区分です。会計基準は、自社で作ったか外部から買ったかという取得形態ではなく、制作目的によって3つに分けています。目的が違えば、将来の収益への結び付き方が違うからです。

図10　作り方（自社制作か購入か）ではなく、何のために作るかで区分します

市場販売目的は、製品マスターと呼ばれる元のソフトウェアを作り、それを複写して不特定多数の顧客に販売するものです。パッケージソフトが典型で、通常はベンダーだけが該当します。自社利用は、販売以外の目的で、自社の事業のために使うソフトウェア全般です。社内業務を効率化する基幹システムのほか、ベンダーがそれを使って顧客向けのサービスを動かすSaaSのような仕組みも含まれます。受注制作は、特定の顧客から注文を受けて作るもので、請負工事に準じて処理します。

図11　市場販売目的では、元になる製品マスターが無形固定資産、売る複製品が棚卸資産です

3区分のうち、受注制作だけは性格が大きく異なります。受注制作で作ったソフトウェアは最終的に顧客に引き渡すものなので、ベンダーが自社の無形固定資産に載せることはありません。制作途中の原価を棚卸資産（仕掛品）として持つ場合や、進捗に応じて収益と原価を計上する場合があるだけです。逆に、発注したユーザー側から見れば、完成品を受け取った時点で購入したソフトウェア（多くは自社利用）として扱います。

図12　自社利用はベンダー（サービス提供用）とユーザー（社内業務用）の両方に現れます

図13　受注制作の制作途中の原価は棚卸資産（仕掛品）として持つことがあります

なお、3区分のどれに当たる場合でも、研究開発に当たる費用は資産にならず、発生した期の費用（研究開発費）として処理するのが大前提です。区分は「研究開発が終わった後の費用をどう扱うか」を決めるための枠組みと考えると分かりやすいでしょう。市場販売目的と自社利用とで、研究開発が終わったと判断する目印が異なるのは、そのためです。

同じ機能のソフトウェアでも、目的が変われば区分も変わります。たとえば在庫管理の機能を開発する場合、製品化して多くの会社に販売するなら市場販売目的、自社倉庫で使ったり自社のSaaSとして提供したりするなら自社利用、取引先1社の注文で作るなら受注制作です。なお、作り始めた後に目的が変わることもあります。社内用に作ったツールを後から外部に販売することにした場合などは、変更を決めた時期と理由を記録し、新しい目的の要件を満たすかどうかを改めて確認します。SaaSを提供するベンダーの判断についてはSaaSを作るベンダーの会計処理｜自社利用か市場販売目的かの判断と実務で詳しく扱います。

図14　架空の会社の例です。機能が同じでも、売るのか使うのか請け負うのかで処理が分かれます

区分を決めたら次に読む記事

区分が決まると、資産計上をいつ始めるか、どう償却するかの考え方が決まります。市場販売目的なら、販売の意思が明らかになった最初の製品マスターの完成時点までが研究開発費で、それ以降の制作費を資産にします。自社利用なら、将来の収益獲得または費用削減が確実と認められる時点から資産にします。受注制作は、収益認識基準に沿って進捗度などを見ながら処理します。

図15　区分ごとに、資産計上の開始点と償却の考え方が変わります

区分	最初に確認すること	次に読む記事
市場販売目的	最初に製品化された製品マスターの完成時点	市場販売目的のソフトウェアの資産計上｜製品マスター完成時点と改良費の扱い
自社利用	将来の収益獲得または費用削減が確実か	自社利用ソフトウェアの資産化要件｜収益獲得・費用削減の確実性と証憑
全体像	3区分と税務・収益認識のつながり	ソフトウェア開発の会計・税務・リスク管理まとめ｜3分類から税額控除、ゲームまで

自社利用ソフトウェアの資産計上の開始時点や、SaaS時代の論点を移管指針とIFRSの両面から整理した記事として、自社利用のソフトウェアの資産計上はいつからか｜SaaS時代の会計処理を移管指針とIFRSで整理するもあわせてご覧ください。

誤分類の多くは、「外注したから受注制作」「契約書の名前が開発委託だから」といった形式面だけで判断することから生じます。発注した側にとって、外部に作らせたソフトウェアは受注制作ではなく、購入した自社利用のソフトウェアです。また、画像素材や楽曲をソフトウェアとして一緒に資産計上してしまう誤りも見られます。

図16　取得の仕方や契約書の名前だけで判断すると誤りやすくなります

判断に迷ったときは、範囲、中身、目的、証拠の順に確認すると整理しやすくなります。特に目的は、開発を始める前の稟議書や事業計画に書いておくことが大切です。後から「売るつもりだった」「社内で使うつもりだった」と説明しても、当初の資料がなければ監査や税務調査で説得力を持ちません。

具体的には、開発の稟議書に「制作目的」「主な利用者」「コンテンツ制作の有無」「原価を集めるプロジェクトコード」の4つの欄を設けておく方法がおすすめです。経理担当者は四半期ごとに進行中の案件の一覧と照らし合わせ、目的の欄が空欄のもの、コンテンツが混ざっているのに区分されていないものを開発部門に確認します。小さな会社でも、この程度の仕組みがあれば決算のときに慌てずに済みます。

図17　範囲→中身→目的の順に確かめると、区分のぶれが減ります

よくある質問

最初の一歩は、進行中の開発案件を一覧にして「目的」の欄を埋めることです

いま動いている開発案件を一覧にして、それぞれが売るためのものか、使うためのものか、請け負ったものかを1行で書いてみてください。あわせて、コンテンツ制作が混ざっている案件にはその旨を書き添えます。これだけで、資産計上の判断を誤りやすい案件が見えてきます。

一覧ができたら、目的が「使う」の案件については、効果（売上の増加や費用の削減）を説明する資料があるかも確認しておくと、次の自社利用の資産計上の判断にそのままつながります。

まとめ

会計上のソフトウェアはプログラムと関連文書であり、データや画像・音楽などのコンテンツは原則として別に扱います。両者が一体不可分なら主な性格でどちらかに寄せ、ベンダーは原価計算の単位を分け、ユーザーは一体処理が基本です。そのうえで、取得の仕方ではなく制作目的によって市場販売目的・自社利用・受注制作の3つに区分し、それぞれの資産計上の考え方に進みます。区分と目的を開発開始時の資料に残しておくことが、その後のすべての判断の土台になります。

本記事の根拠

• 研究開発費等に係る会計基準（企業会計審議会）
• 移管指針一覧（企業会計基準委員会）
• 移管指針第8号「研究開発費及びソフトウェアの会計処理に関する実務指針」
• 移管指針第11号「研究開発費及びソフトウェアの会計処理に関するQ&A」

免責：本記事は一般的な情報提供を目的とし、個別案件に対する法務、会計、税務その他の専門的助言を構成するものではありません。実際の対応は、最新の法令・取引所規則・公表資料を確認し、必要に応じて専門家へご相談ください。