なぜ大量の人が要ったのか
ソフトウェア開発は、なぜこんなに人が要るのか。
業務システムを一つ作るのに30人〜数百人。Webサービスを一つ立てるのに10人〜数十人。なぜか。
通説では「ソフトウェアは複雑だから」「業務要件が多様だから」「品質保証が必要だから」と説明される。全部、表面的な観察に過ぎない。
本当の理由は構造的だ。プログラミング言語の型が貧弱で、世界の構造を毎回手で翻訳する必要があったから——これが大量の人が要った根本原因である。
翻訳労働の正体
整数・実数・文字列しか扱えない言語で、現実のソフトウェアを作るには、世界の構造を細かく翻訳し続ける必要がある：
現実世界（顧客、注文、商品） → ドメインクラス（手で定義）
ドメインクラス ↔ DBの行 → ORM Entity（手で対応付け）
DBの行 ↔ HTTP API → DTO（Data Transfer Object、手で定義）
HTTP API ↔ JSON → シリアライザ／デシリアライザ（手で書く）
JSON ↔ フロントエンド状態 → ViewModel（手で定義）
フロントエンド状態 ↔ HTML/DOM → コンポーネント（手で書く）
各レイヤー間で「翻訳」が発生する。翻訳には：
- コードを書く労働
- 型を多重に定義する労働
- バリデーションを書く労働
- テストを書く労働
- スキーマを多重に管理する労働（DB、API、フロント、ドキュメント）
- 変更時に全レイヤーを揃える労働
- レイヤー間で齟齬が出ないか確認する労働
全てが「実装に必要な労働」ではなく、「型が貧弱だから必要な翻訳労働」である。
典型的プロジェクトの内訳
伝統的なJava／C#プロジェクトのチーム構成を見てみよう：
| 役割 | 主な仕事 | これは何の労働か |
|---|---|---|
| DB設計者 | テーブル設計、ER図 | DB ↔ ドメインの翻訳 |
| バックエンド開発 | ORM、REST API、サービス層 | DB ↔ APIの翻訳 |
| フロントエンド開発 | React、状態管理、UI結合 | API ↔ DOMの翻訳 |
| API設計者 | OpenAPI、契約書類 | 翻訳の規約管理 |
| QA | テストケース、シナリオテスト | 翻訳の整合性確認 |
| インフラ / DevOps | デプロイ、監視 | （これは正当な労働） |
| アーキテクト | 全レイヤー整合性 | 翻訳の俯瞰管理 |
| PM / SE | 上記の調整 | 翻訳労働者の調整 |
ほぼすべての役割が「型の貧弱さによる翻訳労働」から生まれている。本来やりたい仕事（業務の問題を解く）の周辺に、翻訳労働者が何十人も並ぶ構造である。
これが「ソフトウェア開発はなぜこんなに人が要るのか？」の答えだ。技術的に必要なのではなく、言語が貧弱だから必要だった。
工数の分解——70-80%が翻訳労働
実際のプロジェクト工数を経験的に分解すると：
| 工数の種類 | 比率（推定） |
|---|---|
| ドメインロジック本体（本当に解くべき問題） | 10-20% |
| 翻訳労働（DB ↔ API ↔ UI ↔ ファイル ↔ ...） | 40-50% |
| 翻訳労働のテスト | 15-20% |
| 翻訳労働の管理（meeting、レビュー、仕様書） | 15-20% |
| 本物のテストと運用 | 5-10% |
全体の70-80%が翻訳労働とその管理である。本当に価値を作っている部分（ドメインロジック）は10-20%しかない。
考えてみてほしい。30人プロジェクトのうち、21〜24人は翻訳労働をしている。本物の問題解決をしているのは6〜9人だけだ。
これがソフトウェア業界の生産性が異常に低い理由でもある。労働の8割が、実は問題解決と無関係だからだ。
AIネイティブな構造ではどうなるか
Python + AIネイティブ基層（前章で扱った段階4の型）で同じことをやると、翻訳労働がほぼ消える：
# DB → DataFrame → JSON → HTML が一本の流れ
df = pl.read_database("SELECT * FROM orders WHERE month = ?", params=[m])
summary = df.group_by("region").agg(pl.col("amount").sum())
data = summary.to_dicts() # JSON 化、即終了
html = template.render(rows=data) # HTML 化、即終了
ORMクラスもDTOもViewModelも要らない：
DB ↔ DataFrame → 1関数（read_database）
DataFrame ↔ JSON → 1メソッド（.to_dicts()）
JSON ↔ HTML → 1テンプレート
スキーマ管理 → DataFrameの.schemaが持っている、多重管理不要
テスト → 翻訳がないので、翻訳のテストも不要
さらに、AIに「データから月次合計を出すPythonを書いて」と頼めば、上のコードが数秒で出てくる。人間がやるのは「何を出したいか」を決めることだけ。
結果：30人プロジェクトが1〜3人で済む。Streamlit / Gradio / Flet を使えば、Web UI まで含めて Python 一つで完結する。
認知科学側からの呼称——これは「neurosymbolic」である
ここで使っているアーキテクチャには、認知科学・AI研究の世界で既に名前がある。neurosymbolic AI（神経シンボリック AI）——ニューラルネットワークの統計的パターン認識と、古典的シンボリック AI（ルール、ループ、条件分岐、定理証明）を組み合わせる構成だ。Gary Marcus（NYU 名誉教授）が 2012 年から一貫して主張してきた立場で、現実に最先端のシステムで起きていることでもある：
| 構成要素 | 役割 | 例 |
|---|---|---|
| 神経側（neural） | パターン認識・近似・自然言語理解 | LLM（Claude、GPT、Gemini） |
| 記号側（symbolic） | 厳密・検証可能・構造を持つ実行 | Python、pandas、Markdown、Parquet、SQL |
| 巻き合わせ（harness） | 両者を一つのワークフローに統合 | Claude Code、Jupyter、業務スクリプト |
つまり翻訳労働の消失は、純粋な LLM の進歩ではなく、neurosymbolic 構成の成熟によって起きている。
- 数学オリンピックで金を取った AI システムは、定理証明器（lean 等）を併用した neurosymbolic 構成
- Claude Code が優れているのも、LLM の周りに symbolic harness（Python インタプリタ、ファイルシステム、git）があるから
- LLM 単独では数千万行のコードベースを正確に扱えない——記号側が必要
我々が第二部 第4章で「AI 革命は二層同時の変化」と書いたのは、この neurosymbolic 構成のことだった。Layer 1（LLM）と Layer 2（Python / Markdown / DataFrame / Parquet）が揃って初めて翻訳労働が消える——Marcus 用語と我々の用語は、同じ構造を別の角度から記述している。
逆に言えば、「純粋な LLM をスケールすれば AGI に至り、すべてが解決する」というスケーリング仮説の上で待っているだけでは、翻訳労働は消えない。我々が必要なのは、Python という記号側を自分で書ける能力——それが第二部 第5章で扱った「Python は AI ネイティブ言語」の意味でもある。
なぜこの構造が見えていなかったか
「ソフトウェア開発に人が要る」は当然のこととして受け入れられてきた。誰も「翻訳労働」と「本物の労働」を分けて数えてこなかった。
理由は単純で、両方を区別する基準が無かったからだ。段階3の言語の世界では、クラス定義もORMもDTOもViewModelも「必要なコード」として扱われた。翻訳労働だと気づくには、段階4の世界を見る必要がある——比較対象がないと、自分が翻訳労働をしていることに気づけない。
これは、印刷術が登場する前の写本工房と同じだ。修道院の写本職人は、自分が「手で写す労働」をしているとは思っていなかった。本を作るとはそういうものだと思っていた。印刷術が出現して初めて、写本労働が「印刷で消える労働」だったと事後的に分かった。
ソフトウェアの翻訳労働も同じだ。AIネイティブ基層が出現して初めて、これまでの労働の70-80%が翻訳労働だったと分かる。
SIer業界の存在理由が見える
ここでSIer（システムインテグレーター）業界の経済的存在理由が、構造的に見える：
言語の型が貧弱（primitive型のみ）
→ 翻訳労働が大量に必要
→ 大量の労働者（プログラマ）が必要
→ 労働者を集約する組織が必要（SIer）
→ 組織を運営する階層が必要（PM、SE、リーダー、メンバー）
→ 階層管理を支える契約構造が必要（多重請負、人月計算、検収）
→ SIer業界の経済モデルが成立
全部、ステップ1（型の貧弱さによる翻訳労働需要）から派生している。SIer業界の存在理由は、この翻訳労働の需要にあった。
AIネイティブ基層 + LLMが翻訳労働を消すと、ステップ2〜6が全部不要になる。SIer業界が構造的に消滅する——これがその正確なメカニズムである。
「AIが仕事を奪う」議論の取り違え
世間でよく言われる「AIが仕事を奪う」は、構造的に取り違えている。AIが奪うのはコーディングではなく、翻訳労働である：
| 仕事の種類 | AI時代の運命 |
|---|---|
| ドメインを理解する（本物の仕事） | AIが手伝う、人間が中心で残る |
| 業務分析、要件整理 | 残る、AIが補助 |
| アーキテクチャ判断 | 残る、AIが補助 |
| DB ↔ API ↔ UI の翻訳コード | AIが書く、人間が確認 |
| DTO / ORM Entity / ViewModelの定義 | AIが書く |
| CRUDの繰り返しコード | AIが書く |
| テストの定型部分 | AIが書く |
| 上記を管理するPM / SE | 大半が不要 |
翻訳労働はAIネイティブ基層 + LLMで消える。本物の労働（問題を解く、意思決定する）は残るが、それは元々10-20%しかなかった。残りの70-80%が消える。
つまり「AIで仕事が減る」のではなく、「言語の貧弱さによって生まれていた人為的な労働需要が、本来の水準に戻る」——これが正確な記述である。
ビルダーの台頭——個人レベルでの帰結
翻訳労働が消えると、個人で完結できる範囲が劇的に広がる。
これまで30人で作っていたシステムが、1〜3人で作れる。これまで「専門家チームに発注」だった仕事が、「自分で作る」になる。AIネイティブな仕事の作法を持つ個人は、SIerに発注する顧客から、自ら作るビルダーへ転換できる。
業務担当者 + AI + Python で、業務システムが作れる。経理担当者 + AI + DuckDB で、会計分析ツールが作れる。一人の専門家 + AI で、複数の専門領域を兼ねられる。
これは前掲第二部 第1章「AIと個人事業」で書いた「1人＋AI = 大企業相当」の構造的な根拠でもある。型が拡張され、翻訳労働が消え、個人の能力範囲が拡張する——この三段で「個人＝企業」が成立する。
この章の結論——翻訳労働を見ない限りAI革命は理解できない
ソフトウェア開発の大量人員は、技術的必然ではなく、型の貧弱さによる人為的な需要だった。これを正確に認識しないと、AI時代の構造変化を正しく理解できない。
ソフトウェア開発の70-80%は翻訳労働だった。
ドメインロジック本体は10-20%しかない。
翻訳労働は、言語の型が貧弱だから人為的に発生していた。
AIネイティブ基層+LLMが翻訳労働を消すと、本物の労働だけが残る。
30人プロジェクトは1〜3人になる。
SIer業界の存在理由が消える。
これは「仕事を奪う」のではなく、「本来不要だった労働需要が消える」だけだ。
次章では、この翻訳労働需要が社会全体にどんな構造を作ってきたかを見る。IT革命の本当の社会的帰結は何だったのか——それは新しい封建制の建設だった、という構造分析に入る。