ソフトウェア産業は結局どうなるのか。
民主化・リスク・スマイルカーブ。
コードを書くコストがゼロに近づいても、ソフトウェア産業は簡単にはならない。たぶん価値が消えるのではなく、ボトルネックと、引き受けるべきリスクの種類が変わる。
01 — DRUG DISCOVERY
薬をたくさん試せるようになった後
ハイスループットスクリーニングという仕組みがある。雑にいうと、たくさんの化合物を、同じ条件で、自動的に試すための実験工場である。96個の小さな穴が並んだプレートと自動化によって、Pfizerのあるグループでは、1980年代後半に週800化合物だった処理が週7,200化合物まで増えたという記録がある。
これは「薬を探す」という行為の一部を、職人仕事から大量処理へ変えた。以前なら人間が一つずつ試していた組み合わせを、機械がどんどん試せる。少なくとも、候補を見つける入口は大きくなった。
しかし、試せる数が10倍になれば、新薬もそのまま10倍になるわけではない。ヒットした化合物が、本当に病気の仕組みに効いているのか。人間の体内でも届くのか。毒性はないのか。既存薬より意味があるのか。候補が増えるほど、逆に「どれを信じて次へ進めるか」という判断が重くなる。
探索
多数の化合物を機械で試す。ここは自動化によって大きく速くなった。
選別
見つかった反応が再現し、薬として成立する候補かを見極める。
翻訳
細胞や動物での結果が、人間の病気にも当てはまるかを確かめる。
臨床
有効性と安全性を人で検証し、資金・組織・規制を含めて完遂する。
実際、創薬では標的と疾患の選び方が後工程の成功率に影響し、臨床開発では有効性や安全性を理由とする失敗が残ると報告されている。つまり、ハイスループットスクリーニングは創薬を不要にしたのではない。探索のボトルネックを緩めたことで、設計、選別、資金調達、組織運営、臨床試験の重さを露出させたとも取れる。
速く試せるようになることと、正しい賭けを選べることは違う。
02 — MEDIA
誰でも動画を出せるようになった後
同じ構造はYouTubeにもある。テレビの時代には、カメラ、編集機材、電波、放送枠を持つこと自体が参入障壁だった。スマートフォンと動画配信サービスは、その多くを個人に開放した。理論的には、今日から誰でも撮影して、編集して、世界へ公開できる。
では、全員がYouTuberとして成功したかというと、もちろんそうではない。動画をアップロードする機能は大衆化したが、人が見たい企画を考えること、最初の数秒で興味を引くこと、毎週作り続けること、視聴者との信用を積むことは大衆化していない。
例えば、スマートフォンの比較動画なら、カメラを回すだけでは足りない。どの機種を、誰の悩みに対して、どんな条件で比較するのかを決める必要がある。スペックを読み上げる人ではなく、「子どもの運動会を撮りたい人なら、ここを見る」と編集できる人に価値が残る。
逆に、何万人にも受ける必要はない。非常に狭い登山道具、特殊な製造装置、特定のゲーム攻略でも、その人にしか説明できない文脈があり、それを必要とする人へ届けば成立する。大衆化によって勝者が一人になるのではなく、共感を集める競争と、ニッチを深く掘る競争が同時に増えた。
テレビからYouTubeへの変化は、「映像がなくなった」話ではない。映像を作る権利が広がった結果、企画、人格、編集、流通、信用へボトルネックが移った話なのだと思う。
03 — SOFTWARE
誰でもコードを書けるようになった後
生成AIによるコーディングも、たぶんこれに近い。ログイン画面、顧客一覧、CSV出力を持つ社内ツールなら、既存のフレームワークとAIエージェントを使って、以前よりずっと速く形にできる。ここでは確かに、「コードを書ける人だけがソフトウェアを作れる」という制約は弱くなる。
一方で、同じ「画面が動く」でも、工場の設備停止を判断するシステムは違う。センサー値が欠けたときに止めるのか動かすのか。誤検知一回の損失はいくらか。現場はAIの判定を取り消せるのか。誰がいつ判断したかを監査できるのか。既存の制御装置とどう接続するのか。コードを生成した時点では、重要な問題はほとんど解けていない。
決済でも同じである。「支払いボタンを作る」ことと、二重請求を防ぎ、途中で通信が切れても金額を一致させ、不正利用を検知し、問い合わせ時に取引を追跡できることは別の仕事である。医療なら、さらに入力データの意味、見逃しの損失、説明責任、承認手順が加わる。
別の言い方をすれば、誰でもコーディングできるという主張は、境界が決まり、失敗の影響が小さく、正解を自動で確認できるハーネスの内側ではかなり正しい。既存APIを呼び、決まったデータを表示し、テストで合否が出る仕事は急速に安くなる。
しかし、現実の顧客の構想は、最初からその形をしていない。「この検査を楽にしたい」「この判断を自動化したい」という曖昧な言葉から、例外と責任を含む仕様を作らなければならない。そして最後には、顧客の現場で本当に使われ、壊れず、期待した結果を出したことを保証しなければならない。
04 — VALUE CURVE
価値はスマイルカーブに移る
この変化を雑に図にすると、価値は工程の左端と右端へ寄る。口角が上がった笑顔のように見えるので、ここではスマイルカーブと呼びたい。
| 位置 | 仕事 | 具体例 | AI時代の変化 |
|---|---|---|---|
| 左端 | 問いと賭けを決める | 誰の、どの損失を、どこまで減らすか。例外時の責任を誰が持つか。 | 選択肢が増えるほど重要になる |
| 中央 | 境界内で実装する | 画面、API接続、定型的な変換、既知のパターンのテスト。 | 生成と再利用で急速に圧縮される |
| 右端 | 動くことと届くことを保証する | 統合、セキュリティ、運用、監査、顧客受入、KPIの実現。 | 失敗コストが残る限り重要になる |
左端は、単なるアイデア出しではない。薬でいえば、どの疾患のどの標的へ賭けるか。YouTubeでいえば、誰が何を見たいか。ソフトウェアでいえば、顧客の業務のどこに損失があり、何を変えれば価値になるかを決める仕事である。
右端も、単なるテストではない。薬なら臨床試験を完遂し、効果と安全性を示すこと。YouTubeなら公開した動画が実際に見られ、次も見たいと思われること。ソフトウェアなら、本番のデータと例外の中で動き、顧客が受け入れ、業務指標が変わることまでを引き受ける。
もちろん中央がゼロになるわけではない。むしろ、左と右をつなぐために実装は必要である。ただ、コードを書いた量だけでは価値を説明しにくくなる。何を作るべきかを決めたことと、作ったものが価値を生んだと証明したことの比重が上がる。
05 — COMPLEXITY
部品が増えるほど、全体は難しくなる
製薬との違いもある。ソフトウェアでは、AIがコードを書くと同時に、使えるソフトウェア部品そのものも増えていく。OSS、クラウドサービス、モデル、エージェント、各種MCPやAPIが増え、昨日なかった組み合わせが今日には作れる。
例えば、顧客メールを読んで、契約情報を調べ、返信案を作るエージェントを考える。メールAPI、顧客DB、検索、LLM、権限制御、監査ログをつなげば、デモはすぐにできる。一方で、本番ではこうなる。
権限
誰のメールを読めるか。下書きまでか、送信まで許すか。
状態
途中で失敗した処理を再開すると、二重送信や二重更新が起きないか。
評価
もっともらしい返信と、契約上正しい返信をどう区別するか。
変更
モデルやAPIの更新で挙動が変わったとき、どこまで再検証するか。
責任
間違って送信したとき、誰が検知し、止め、顧客へ説明するか。
一つひとつの部品は使いやすくなる。しかし組み合わせが増えると、設計空間はむしろ広がる。ドメイン知識も、業務だけでなく、モデル特性、データ、権限、セキュリティ、運用まで肥大する。
だから「誰でもコードを書ける」と「誰でもソフトウェアシステムを設計し、運用できる」は同じ意味ではない。前者が正しくなるほど、後者の難しさが見えるようになるのかもしれない。
06 — RISK
堀ではなく、リスクを見る
ここで「では、何が参入障壁になるのか」と考えると、すぐにデータ、フィジカル、リアルな顧客接点といった答えへ行きたくなる。これらは確かに強い。ただし、何でもデータを集めればよいわけでも、ハードウェアを持てばよいわけでもない。
誰でも撮影できるYouTubeで、カメラを所有していること自体は大きな堀にならない。大量に実験できる製薬で、化合物を数多く試したこと自体が薬の価値を保証しない。同様にソフトウェアでも、データを持っているだけでは、そのデータが正しく生成され、顧客の判断を改善し、使い続けられるとは限らない。
見るべきなのは資産の名前ではなく、どの不確実性を引き受けているかだと思う。
| リスク | 問い | 成功したときに生まれる価値 |
|---|---|---|
| 構想 | そもそも解くべき問題なのか。顧客は行動を変えるのか。 | 不要な機能を作らず、本当に効く場所へ賭けられる |
| 設計 | 増え続ける部品を、壊れにくい境界で組み合わせられるか。 | 複雑な技術を顧客が使える一つのシステムにできる |
| 運用 | 例外、攻撃、変更、障害の中でも責任を持てるか。 | デモではなく継続して任せられる |
| 受入 | 顧客の現場で使われ、成果が出たと検証できるか。 | コードを業務成果へ変換できる |
今までは、ソフトウェアスタックをゼロから実装できること自体が大きなリスクテイクだった。これからは、その部分が安くなる一方で、問題選択、全体設計、本番運用、顧客成果のリスクを誰が持つかが前に出る。リスクが消えるのではなく、種類が変わる。
07 — CONCLUSION
ソフトウェア産業とは何になるのか
ソフトウェア産業は、コードを書く産業から、複雑な可能性の中で賭けを選び、その賭けが現実で機能するところまで保証する産業へ近づくのだと思う。
薬の探索が自動化されても、病気を理解し、候補を選び、臨床を完遂する人と組織は必要だった。映像制作が民主化されても、何を誰に届けるかを考え、信用を積むYouTuberは必要だった。コード生成が民主化されても、顧客の曖昧な構想を受け、複雑な部品を設計し、動作と成果を保証する仕事は残る。
全然違うゲームになることは確かである。限られたハーネスの中で、決まったものを実装するだけの仕事は減る。一方で、作れるものが爆発的に増えるほど、何を作らないかを決める仕事と、作ったものに責任を持つ仕事は増える。
自分なら、これからのソフトウェアエンジニアリングを「コードを書く能力」だけでは定義しない。構想を仕様へ変える。技術を全体として組む。壊れ方を想像する。顧客が受け取れるところまで持っていく。その一連のリスクを、どこまで引き受けられるかで考えたい。
作ることが安くなった世界では、何に賭け、どこまで責任を持つかが高くなる。
ただ、どこからどこまでを人が担い、どこをAIエージェントへ渡すべきかは、まだよくわからない。たぶんその境界自体が、これからのソフトウェア産業の設計対象になる。