多重下請け構造は原因ではなく結果。その上流には、会計上の「資産」と、経営として残すべき「作り続けられる能力」のズレがある。会計には完成があるが、ソフトウェアにもセキュリティにも完成はない。AI時代の競争力を分けるのは、何を会社の資産として残すかという経営判断だ。
日本のITについて、多重下請け構造が問題だとよく言われる。その指摘は正しいと思う。
ただ、多重下請けは原因というより「結果」なのではないか。そのさらに上流には、会社として何を「投資」と考え、何を「コスト」と考えるのかという、経営と会計の問題がある。
最初に会計上の事実を整理しておきたい。
日本でも、自社利用ソフトウェアは一定の条件を満たせば無形固定資産として資産計上できる。外部のベンダーに作ってもらった場合だけではない。社員が自社で開発した場合でも、そのソフトウェアの制作に直接かかった人件費などは取得原価に含めることができる。
したがって、「内製＝OPEX、外注＝CAPEX」という単純な話ではない。
それでも、経営から見える景色には大きな違いがある。
例えば、100億円で基幹システムを外注するとする。経営から見ると非常に分かりやすい。
予算を取る。ベンダーを選ぶ。契約する。プロジェクトを開始する。開発する。最終テストを行う。検収する。完成したソフトウェアを資産計上する。そして数年かけて償却する。
「100億円のシステム投資」という一つの案件になる。プロジェクトには始まりと終わりがある。完成すれば、プロジェクトも終わる。
一方、自分たちで作る場合はそう単純ではない。
エンジニアを採用する。給与を払う。育成する。新しい技術を学ばせる。PoCをする。失敗する。作り直す。運用する。
一つのシステムが完成しても、その人たちは残る。
もちろん、開発に直接対応する人件費は資産化できる。しかし、採用、教育、研究、探索、組織運営、保守など、すべてをソフトウェア資産にできるわけではない。
経営から見ると、システムを買うことは「投資」に見えやすい。一方で、システムを作れる組織を持ち続けることは「固定費」に見えやすい。
ここには、かなり大きな経営インセンティブがある。
外注なら、プロジェクトが終われば契約を終了したり縮小したりできる。社員を100人抱えれば、事業環境が変わったからといって簡単に100人をゼロにはできない。日本の雇用慣行を考えれば、なおさら長期のコミットになる。
経営からすれば、必要なときだけ外から人と技術を調達する方が柔軟だった。その判断自体には合理性がある。
そして、その合理性を何十年も積み重ねれば、元請けがいて、その下にベンダーがいて、さらにその下に開発会社がいる、という構造ができるのも不思議ではない。
多重下請けだけを批判しても、その上流にある経営のインセンティブを変えなければ、同じ構造はまた生まれる。
もう一つ、大きな問題がある。
ソフトウェアを作るときには、大型投資として予算が付く。ところが完成すると、経営から見える景色が変わる。
今度は、運用費、保守費、監視費、改修費、人件費、教育費、セキュリティ費、といった毎年のOPEXになっていく。
そこで始まるのが、「来年度の運用費を10％削減できないか」「保守費を20億円から15億円にできないか」という議論だ。
しかし、ソフトウェアは本当に完成しているのだろうか。
使って初めて分かる問題がある。顧客の行動を見て変える。障害を直す。依存ライブラリを更新する。アーキテクチャを変える。新しい機能を追加する。セキュリティを改善する。そして、また使う。
現代のソフトウェアは、
作る → 使う → 学ぶ → 直す → また作る
というループそのものが競争力になっている。
それでも会計には「完成」が必要になる。ここに大きなズレがある。
会計には完成がある。ソフトウェアに完成はない。
この構造を続けた結果、奇妙なことが起きる。
貸借対照表には「ソフトウェア」という資産が載っている。しかし、そのソフトウェアを作った人は社内にいない。なぜその設計にしたのか分かる人もいない。
どこで失敗したのか。どの方法を試して駄目だったのか。どこを変更すると壊れるのか。次はどう作ればもっと良くなるのか。
そうした学習は帳簿には載らない。
外注していれば、その多くはベンダー側に蓄積される。発注側に残るのは、ソフトウェア資産、仕様書、検収記録、稟議書だ。
つまり、資産を買い続けた結果、資産を作り続ける能力を持たなかった。
これが、これまでの日本企業のITを考えるうえで重要な問題なのではないかと思う。
ただし、ここは誤解してはいけない。日本の会計基準だけが特殊だから、この問題が起きているわけではない。
米国でも、自社利用ソフトウェアの一定の開発費や、それに直接従事する社員の給与などは資産化できる。IFRSでも、研究段階は費用、一定の条件を満たした開発段階は資産化するという考え方を取っている。韓国の上場企業が採用するK-IFRSも、基本的にはIFRSの枠組みに立っている。
それでも各国で、ソフトウェアを内製する能力や、それを競争力として維持する経営には差がある。
つまり問題は、会計上の「資産」と「費用」を、そのまま経営上の「投資」と「コスト」に置き換えてしまうことなのだと思う。
実際、米国では2025年、内部利用ソフトウェアの会計基準が改正された。背景の一つには、従来の「企画→開発→完成」という段階的なモデルが、アジャイルや反復型のソフトウェア開発に合わなくなってきたことがある。IASBでも、SaaSやアジャイル開発を含む無形資産会計の見直しが議論されている。
ソフトウェアの作り方が変われば、会計も変わらざるを得ない。
しかし、本当に変える必要があるのは会計基準だけではない。経営の見方そのものだ。
そして、これからはもっと難しくなる。AIだ。
AIも従来のITプロジェクトと同じ形で導入することはできる。
予算を取る。ベンダーを選ぶ。PoCをする。システムを作る。検収する。「AI導入プロジェクト完了」とする。
しかし、AIの価値はそこでは生まれない。
AIを使う。間違える。人が評価する。データを直す。プロンプトを変える。エージェントを変更する。業務のやり方そのものを変える。また使う。
その繰り返しによって、初めて会社固有のAI活用能力が蓄積される。
つまりAIでは、従来以上に価値の中心が、「完成した資産」から「継続的に学習できる組織能力」へ移っていく。
ところが、この能力の大部分はB/Sには載らない。人件費、教育費、運用費、評価費、改善費。経営から見ればOPEXに見えるものが多い。
100億円のAIシステムなら「大型投資」と説明できる。しかし、100人が毎日AIを使い、失敗を記録し、業務を変え、モデルやエージェントを評価し、改善し続けることは、「毎年かかるコスト」に見えてしまうかもしれない。
これまでのIT以上に、この経営判断の差が企業の競争力を分けると思う。
セキュリティは、この構造を理解するよい例だ。
新しいシステムを作り、リリース前に脆弱性診断やペネトレーションテストを行う。その検査がシステムを事業利用できる状態にするために直接必要なものであれば、開発プロジェクトの一部として扱える場合がある。「安全なシステムを作るためのセキュリティ」だ。
しかし、システムが稼働した瞬間から事情が変わる。
継続的な脆弱性診断。監視。パッチ適用。依存ライブラリの更新。新しく公開されたCVEへの対応。設定変更。インシデント対応。
こうした活動は基本的に毎年の運用コストとして現れる。
そこで、先ほどと同じことが起きる。
作るためのセキュリティにはプロジェクト予算が付く。しかし、安全であり続けるためのセキュリティは、OPEXとして削減対象になりやすい。
ところがセキュリティにも完成はない。
昨日安全だったシステムに、今日新しい脆弱性が公開される。安全だった依存パッケージに、明日サプライチェーン攻撃が起きるかもしれない。攻撃手法も変わる。AIによって攻撃と脆弱性発見の速度も上がっていく。
だから必要なのは、一度の「セキュリティ検査プロジェクト」ではない。
見つける。判断する。直す。確認する。また監視する。
このループを継続して回すことだ。
ソフトウェアに完成がないのと同じように、セキュリティにも完成はない。
これまで日本企業は、ITに金を使ってこなかったわけではない。大型のシステム投資はしてきた。
しかし、「作ること」には投資し、「作った後に育て続けること」をコストとして扱ってきた。
その結果、ソフトウェアという資産は残っても、作る能力、直す能力、守る能力、そして失敗から学ぶ能力。そうしたものを自社の経営資産として残しにくい構造ができた。
これが、これまでの課題だった。
そしてAI時代には、その問題がさらに大きくなる。AIでは、完成したシステムそのものより、使いながら学び続ける能力の方が重要になるからだ。
だから問われるのは、CAPEXかOPEXかという仕訳だけではない。
会計上は費用であっても、人、技術、データ、設計思想、セキュリティ、失敗から得た知識、学習を続けられる組織。
これらを、「削るべきコスト」ではなく「会社に残すべき資産」と経営が考えられるか。
デジタル敗戦の次にAI敗戦が来るとすれば、それはAIモデルの性能差から始まるのではないと思う。
何を会社の資産として残すのか。その経営判断の差から始まるのではないだろうか。
Aikido Community Japan
公開日: 2026/8/19
最終更新: 2026/8/19
セキュリティの最新情報をお届けします。