フォン・ノイマンから読み解くAI時代

はじめに

「AIが様々な職業を奪う」という話を、最近よく耳にします。事務職、ライター、デザイナー、翻訳者、そしてエンジニア。AIの進化が急だから、自分の仕事は本当に消えてしまうのではないかと、不安を感じている人も多いと思います。

そこで、私の身近な領域であるエンジニアという職業について、少し考えてみました。コードを書くAIの能力は、確かに目を見張るものがあります。

この問いを考えるとき、私はひとりの人物に立ち返ります。ジョン・フォン・ノイマン。コンピュータサイエンスを学んだ人なら、教科書の最初のあたりで必ず出会う名前です。

ただ、彼が何をした人なのかを語れる人は意外と少なく、「コンピュータの父」と呼ばれている、というあたりで止まっている人が多いのではないでしょうか。

実は彼が80年前に作った仕組みは、今私たちが使っているスマホもPCもデータセンターも、そして話題のChatGPTやClaudeを動かしているサーバーも、すべて同じ基本設計で動いています。AIがどれだけ進化しても、その土台は1945年にフォン・ノイマンが書いた一本の論文に行き着きます。

この記事では、フォン・ノイマンの功績を振り返りながら、コンピュータの歴史が「AIがエンジニアを不要にするか」という問いに何を教えてくれるかを考えてみたいと思います。エンジニアの話として書いていますが、ここで見えてくる構造は、おそらく他の職業にも通じるところがあるはずです。

フォン・ノイマンとは何者か

ジョン・フォン・ノイマン（1903–1957）はハンガリー生まれの数学者です。54歳で亡くなった短い生涯で、彼は驚くほど多くの分野に足跡を残しました。

フォン・ノイマンの主な業績を、分野別にまとめると次のようになります。

80年前の設計が、今もそのまま使われている

フォン・ノイマンが1945年に書いた「EDVACに関する報告書の第一草稿」という論文は、コンピュータの基本設計を示しました。「フォン・ノイマン型アーキテクチャ」と呼ばれるものです。

中身はとてもシンプルで、次の3点に集約されます。

1. プログラム（命令）とデータを同じメモリに置く
2. CPUがメモリから命令を順番に読み出して実行する
3. 入力・出力・計算・制御・記憶という5つの部品で構成する

「なんだ、当たり前のことじゃないか」と思うかもしれません。でも、それはこの設計が80年間あまりに当たり前すぎて、誰も疑わなくなっているからです。

驚くべきことに、

• 1945年の真空管コンピュータ
• 1980年代のパソコン
• 今手元にあるスマホ
• ChatGPTやClaudeを動かすデータセンターのGPUサーバー

これらすべて、この同じ基本設計で動いています。IBMの研究者も「フォン・ノイマン型は柔軟で、だから今も主流であり続けている」と語っています。

80年たっても置き換わらない設計図。これだけでも、ひとつの大きな事実だと思います。

AIだって、フォン・ノイマンの上で動いている

ここからが面白いところです。

ChatGPTやClaudeのような生成AIが普及し始めたのはここ数年です。でも、その中身を支えている理論を見てみると、フォン・ノイマンの仕事があちこちに顔を出します。

ハードウェア：GPUもフォン・ノイマン型の延長

AIの学習に使われるGPUは、NVIDIAの公式ドキュメントでも「フォン・ノイマン型アーキテクチャを起点にしている」と説明されています。GPUは元々グラフィックス処理のために生まれたチップで、並列計算が得意という特徴がありました。これがニューラルネットワークの行列演算にうまく合っていたため、AIブームの主役となったわけです。

並列処理という工夫は加わっていますが、根っこの設計はフォン・ノイマン型と同じ。GoogleのTPUやAppleのNeural Engineなど、AI専用に設計された新しいチップも、命令を順次実行するという基本構造は変わっていません。AIサーバーも、結局はフォン・ノイマン型のコンピュータです。

数学：ベクトルで考えるという発想

AIが言葉を扱う仕組みのひとつに、単語をベクトル（数字の並び）として表現するという考え方があります。2013年に登場したWord2Vecというモデルでは、「king − man + woman ≈ queen」という有名な計算が成り立つことが示されました。単語の意味を数字の組み合わせで表現することで、足し算引き算で関係性を計算できるわけです。

このベクトルで世界を表現する数学的な伝統は、もとをたどれば20世紀初頭にヒルベルトが整備した「ヒルベルト空間」の考え方に行き着きます。フォン・ノイマンはこのヒルベルト空間を量子力学に応用し、物理現象を線形代数の言葉で記述できることを示しました。

現代のAIで使われる埋め込みベクトルは、フォン・ノイマンが量子力学で扱ったヒルベルト空間とは形が違いますが、「対象をベクトル化して、線形代数で関係性を計算する」という発想は同じ系譜にあります。フォン・ノイマンが量子力学のために確立した数学的な考え方が、AI時代まで続いているわけです。

アルゴリズム：ゲーム理論の応用

AlphaGoや、画像生成で有名になったGAN（敵対的生成ネットワーク）の動作原理は、フォン・ノイマンが1928年に証明したミニマックス定理の応用です。「2人が対立するゲームでは、最悪の結果を最小にする戦略がお互いに必ず存在する」という定理ですね。

GANは「絵を作るAI」と「それが本物か偽物かを見破るAI」が戦って、結果として高品質な画像を生み出します。元論文（Goodfellowら、2014）でもはっきりと「two-player minimax game（2人ミニマックスゲーム）」と書かれていて、フォン・ノイマンの数学がそのまま使われています。

要するに、AIは突然空から降ってきた技術ではなく、20世紀前半に整備された理論の延長線上にあるわけです。

本題：AIはエンジニアを不要にするのか？

さて、ここから本題です。

「AIがコードを書けるなら、もうエンジニアはいらないのでは？」という話。これを歴史の文脈で考えてみると、過去にも何度も同じことが言われてきたことに気づきます。

抽象化の歴史を見てみる

コンピュータの世界は、「もっと簡単に書けるようにしよう」という方向に進化してきました。

特にCOBOLは「英語に近い構文だから業務担当者が直接書ける」と言われた言語でした。でも実際は、業務システムが大規模化・複雑化したことで、専門のプログラマーがますます必要になりました。このパターンが、ずっと繰り返されてきたわけです。

なぜプログラマーは消えなかったのか

道具が便利になると、扱える問題のサイズも大きくなります。

• 機械語の時代：数値計算プログラム
• 高級言語の時代：企業の業務システム
• フレームワークの時代：Webサービス
• クラウドの時代：数億人が使うグローバルサービス

道具が10倍便利になったら、解こうとされる問題のサイズも10倍になる。だからエンジニアは消えなかった。むしろ、より上の階層の問題に移動していったのです。

エンジニアの本当の仕事は「コードを書くこと」じゃない

ここで重要な事実を確認しておきましょう。

エンジニアの本当の仕事は、コードを書くことそのものではありません。コードを書くのはあくまで手段です。本当の仕事は、こういうことです。

• 曖昧な要望を、具体的な仕様に翻訳する
• 「この機能を入れたら他に何が壊れる？」を洗い出す
• 「障害が起きた、原因は？」を追跡する
• 「3年後にも保守できる設計か？」を判断する

どれも、人間の曖昧な世界とコンピュータの厳密な世界の間を翻訳する仕事です。

フォン・ノイマンは亡くなる前に書き残した『計算機と脳』（1958）で、機械と人間の構造的な違いを論じています。機械は正確だけれど脆い。脳は曖昧だけれど頑丈。両者の橋渡しは、誰かがしなければいけない。

AIはコードを書く部分（機械の世界の中）はとても速くなりました。けれど、現実の曖昧さを機械の厳密さに翻訳する仕事は、まだ人間の領域です。

「誰が決断して、誰が責任を取るか」問題

もうひとつ大事な視点があります。

フォン・ノイマンの量子力学の研究に、「観測の連鎖はどこかで切らないといけない」という考え方があります。難しい話を脇に置けば、要するに「無限に分析を続けることはできない、どこかで決断するしかない」ということです。

ソフトウェア開発も同じです。AIは選択肢をいくらでも生成できます。でも、誰かが決めなければいけない。

• 「このコードで本番に出す」
• 「ここで仕様を確定する」
• 「この設計で行く」

決めた人は結果に責任を負います。失敗したときに説明し、判断の理由を問われ、必要なら方針を変える。技術の問題ではなく、社会の仕組みの問題です。

現時点の法制度では、AIは責任主体になれません。法的にも社会的にも、AIに責任を問う仕組みがない。だから、最終的な決断と責任は人間に残ります。AIをめぐる法整備は世界各国で議論が進んでいますが、当面この構造は変わらないでしょう。

ゲーム理論で考えてみる

フォン・ノイマンが作ったゲーム理論で、別の角度から見てみましょう。

ゲーム理論にはプレイヤーとゲームデザイナーがいます。プレイヤーはルールの中で最善手を打つ。デザイナーはそもそものルールを決める。

AIは「与えられたルールの中で最善手を打つプレイヤー」としてはとても強い。チェスも囲碁もポーカーも、すでに人間より強いです。

でも、ソフトウェア開発で本当に大事な仕事は、ゲームデザイナー側にあります。

• どんなプロダクトを作るか（＝どのゲームをプレイするか）
• どんなアーキテクチャにするか（＝ルールをどう設計するか）
• どこに賭けるか（＝どこに資源を投下するか）

これは「与えられたゲームの最善手」ではなく、「そもそもどんなゲームを作るか」を決める仕事です。AIは前者は得意でも、後者はまだ人間の領域です。

ゲームのルールに正解はありません。何を作るかも、どう設計するかも、無数の選択肢があります。AIは選択肢を並べることはできても、その中から一つを選ぶ主体にはなれない。誰が選ぶのか。プロダクトオーナー、アーキテクト、エンジニアリングマネージャー、現場のエンジニア、立場は様々ですが、最終的に判断を下すのは人間です。

道具が変わるたび、より多くの人が上の階層に挑めるようになる

歴史を振り返ると、面白いパターンが見えます。

抽象化が進むたび、それまで一部の専門家にしかできなかった仕事に、より多くの人が手を伸ばせるようになってきました。機械語を書けるのは限られた人でしたが、高級言語が登場するとプログラミングの裾野が一気に広がりました。インフラ構築は専門家の領域でしたが、クラウドの普及でジュニアエンジニアでも環境を立ち上げられるようになりました。

AIもこの延長線上にあります。これまでベテランにしか書けなかったコード、設計できなかったシステムが、AIの支援を受けてジュニアやミドル層でも形にできる時代が来ています。つまり、道具の進化は「優秀な人しか生き残れない」ではなく、「より多くの人が上の階層に挑める」方向に働いてきたのです。

その上で、上の階層で何を判断するか、何を作るかを決める力は、変わらず人間に求められます。AIによって「コードを書く」ことが楽になるなら、相対的に重要になるのは「ユーザーが何を必要としているかを定義する」という力です。これは経験や肩書きを問わず、すべてのエンジニアが磨いていける部分です。エンジニアの仕事の核心は、ここにあります。

フォン・ノイマン自身が示した、エンジニアのあり方

最後に、興味深い事実をひとつ。

フォン・ノイマンは、EDVACの開発で実際に手を動かして実装をしていません。配線をしたり、真空管をはんだ付けしたのはEckertやMauchlyたちエンジニアです。フォン・ノイマンの仕事は、設計と数学的な定式化でした。

つまり彼の役割は、現代でいうソフトウェアアーキテクト（システムの設計を担う役割）に近いものでした。コードを書く人ではなく、全体を構想する人です。

そして80年経った今、AIに任せられない仕事として残っているのは、まさにこの構想する役割なのです。

• 問題を分解する力
• 適切な抽象化を選ぶ力
• トレードオフを判断する力
• 将来の変化に備える力

抽象化が進んでも、これらの能力は消えません。むしろ、抽象化が進むほど重要になっていく能力です。

ただし、個々のエンジニアにとっては別の話

ここまでは「エンジニアという職業全体」の話でした。集団としての職業は残る。けれど、それと「個々のエンジニアが自動的に救われる」かは別の問題です。

ここは正直に書いておきたいところです。過去の抽象化の波でも、すべての技術者が上の階層にうまく移れたわけではありませんでした。

過去、波に乗れなかった人たちもいた

たとえば1970年代まで活躍していたキーパンチャー（パンチカード入力の専門職）は、磁気テープと端末入力の普及で職を失いました。多くは別職種への転身ができず、業界を去っています。1990年代から2000年代にかけては、メインフレームのオペレーターやCOBOLしか書けなかったプログラマーの中にも、Java/.NETやWeb系の技術に頭を切り替えられず、現役を退いた人がいます。

「エンジニアという職業」は確かに残った。でも、個々の人にとっては、職を失ったり、収入が下がったり、別業界に移ったりした人もいたわけです。生き残ったのは、学習する習慣を持ち続けていた人、早めに次の波を察知して動いた人、特定の技術ではなく考え方そのものを身につけていた人でした。

つまり、集団の生存と個人の生存は別問題なんですね。

ここを正直に認めた上で、では個々のエンジニアは何をすればいいのか。私が大事だと思うのは、次の2つです。

T字型から「π字型」へ

世界的にみて、エンジニアという仕事はずいぶん一般化しました。一昔前のように「技術が好きで仕方ない」という人ばかりではなく、プロとして仕事をこなす職業として広く定着しています。これは職業として成熟した証で、良いことだと思います。

ただ、AI時代を考えるとき、ひとつ気をつけたい点があります。渡された仕様通りにコードを書くという部分は、AIがもっとも得意とする領域そのものです。コードを書くことだけで仕事が完結すると考えると、AIの守備範囲と重なってしまう。

だからこそ、自分が関わっているビジネスや業界そのものに踏み込んでいくことが、これからのエンジニアの差別化要素になります。自分が作っているシステムがどんな業務を支えているのか、ユーザーが本当は何に困っているのか。技術以外の部分に踏み込んで考えること。これは、どんなスタイルでエンジニアをやっている人にとっても、同じく大切な姿勢です。

AI時代に向けて、いちばん意識して取り組むべきことは何かと聞かれたら、私は「プログラムの世界から視野を広げて、ビジネスのドメイン知識を真剣に勉強すること」と答えます。これは現場の判断経験と並行して、いやむしろこちらの方を意識的に取りに行く必要があるくらいだと思っています。

ここで、エンジニアの能力モデルとして昔からよく語られる「T字型」の話をしておきます。1つの専門領域（縦棒）＋幅広い知識（横棒）というモデルですね。

これからのエンジニアには、π字型（パイ字型）の能力が必要になると私は考えています。縦棒が2本ある形です。

• 縦棒1：技術の専門性（コード、システム設計、アーキテクチャなど）
• 縦棒2：業界・ドメインの深い理解（金融、医療、製造、物流、士業・法務、教育、SaaS、フィンテック、HRテック、ゲーム、コンシューマーアプリなど、自分が関わる領域）
• 横棒：両者をつなぐ広い視野（ビジネス、マネジメント、コミュニケーション）

なぜ縦棒2本目が大事か。AIは技術領域では急速に強くなっています。コードを書く、設計のパターンを提案する、ベストプラクティスを示す。これらは加速度的にAIの守備範囲に入っていきます。

一方で、特定の業界の深い文脈は、AIには簡単に学習できません。

• 医療現場では、なぜこの業務フローになっているのか
• 製造業では、現場の作業者が本当に困っているのは何か
• ユーザーがこの機能をスキップする本当の理由は何か（数字だけでは見えない部分）
• このBtoBサービスで顧客が継続利用を判断する暗黙の基準は何か

こういうことは、現場に入り込んで、業界の人と長い時間をかけて対話して、初めて分かるものです。Web上のテキストデータから学習したAIには、簡単には到達できない領域です。

「コードが書けるだけのエンジニア」より、「医療システムを設計できるエンジニア」「製造業のDXを推進できるエンジニア」のほうが、AI時代には価値が高くなります。技術とドメインの両方に深く入り込むこと。これがπ字型の核心です。

具体的に何をすればいいか。

• 自分が今関わっている業界・顧客の業務を、技術以外の側面から学ぶ
• 業界の動向を継続的に追う（業界本、専門メディア、カンファレンス、勉強会、実務家のブログなど、領域に応じて）
• 自分の作るものを実際に使う人と関わる（顧客、ユーザー、現場担当者、PM、デザイナー、CSメンバーなど、立場に応じて）
• 1つの業界に最低5年は腰を据える（短期で渡り歩くと、業界固有の文脈や常識を体得するレベルに到達しない）
• その業界の「常識」「タブー」「歴史」を理解する

ドメイン知識は、5年、10年かけて積み上げるものです。これは技術の流行り廃りより、はるかに長持ちする資産になります。

現場の実体験の蓄積

ドメイン知識を深めることと並行して、もうひとつ大事なのが現場の実体験です。

両者は互いを深め合う関係にあります。ドメイン知識があると、現場で見えるものが変わる。「なぜこの障害が事業にとってクリティカルなのか」「どこまで止めていいのか」「誰に何を伝えるべきか」、こうした判断はビジネスの文脈を理解しているからこそできるものです。逆に、現場で何かが起きるたびに「なぜこの業務でこれが問題になるのか」を考えれば、ドメイン知識も深まっていく。両輪を回すように、両方を意識的に育てていくのが理想です。

その上で、なぜ現場の実体験が必要なのか。それは、上の階層の判断には「正解がない」からです。仕様書に書いていない、過去の事例にも書かれていない、ベストプラクティスにも書かれていない。そういう状況で「この場では何を優先すべきか」を判断するには、自分の身体に染み込んだ経験から推し量るしかありません。教科書で学べることではないのです。

たとえばこんな経験です。

• 本番環境で大規模障害を経験して、原因究明から復旧までを最後まで見届けた
• 失敗プロジェクトに巻き込まれて、何が悪かったかを自分の身で理解した
• 技術選定の判断ミスで痛い目にあって、なぜそれがダメだったかを骨身で覚えた
• 違う業界・違う規模の現場を渡り歩いて、何が本質で何が業界固有の話かを区別できる

こういう経験は、本を読んで身につくものではありません。1日や1ヶ月で身につくものでもない。5年、10年の積み重ねです。

そして重要なのは、こうした経験は待っていても自然には来ないということです。安全な場所にいれば、安全な仕事しか回ってこない。自分から取りに行く必要があります。

具体的には、

• 小さくてもいいから設計判断を任せてもらう
• 技術選定の議論に首を突っ込む
• 失敗してもいい範囲で、自分で決断を下す経験をする
• 障害対応の現場に手を挙げて入る
• 振り返りをして「なぜその判断が良かったのか・悪かったのか」を言語化する

困難な状況での判断経験を積んでいる人は、AIには簡単に置き換わりません。なぜなら、こうした判断は、過去のデータに正解が書かれていない判断だからです。AIが学習できるのは過去のパターンですが、現場の難局では「過去にない状況」での判断が求められます。ここは、ドメインへの理解と現場の経験の両方を持つ人間の領分です。

集団の話と個人の話を分ける

ここまで書いてきたことを、整理するとこうなります。

集団の話：エンジニアという職業は消えない。コンピュータの歴史を見れば、抽象化が進むたびにエンジニアの仕事は上の階層に移ってきた。AI時代もこの延長線上にある。

個人の話：しかし、すべてのエンジニアが自動的に上の階層に移れるわけではない。π字型の能力を磨き、現場の実体験を積み、学び続けない人は、波に置き去りにされていく。

楽観できる部分と、備えるべき部分を分けて考えることが大事です。「エンジニアは消えない」は集団の話で、「自分も大丈夫」は個人の話です。前者は歴史が示しています。後者は、自分で準備するしかありません。

キャリアステージごとに、見え方は違う

ここまで「個人の話」として書いてきましたが、その中身もキャリアステージで違います。

ジュニアやミドル層の方には、正直に書いておきます。コードを速く正確に書く力――今までエンジニアの主な評価軸だったものは、AIがどんどん得意になっています。「コードを書く力」を中心に自分の価値を組み立てていると、AIと同じ土俵で勝負することになります。これからは、シニア層が時間をかけて身につけてきた判断、設計、ドメイン理解の方を、自分の主軸として育てていく必要があります。後回しにしないことです。

シニアやスタッフ層の方は、たぶん今までやってきたことを続ければ大丈夫です。前例のない場面での判断、スケールに耐える設計、チーム間の技術的な調整。これらはAIが学習しにくい領域で、価値はむしろ上がっています。実装が速く安くなるほど、上のレイヤーで何を判断したかが結果を決めるからです。

まとめ：エンジニアは消えない、進化する

ここまでの話をまとめると、こういうことです。

歴史的事実として、抽象化の進歩はエンジニアを消さず、上の階層に押し上げてきました。エンジニアの本質はコードを書くことではなく、複雑性を制御し、判断を下し、責任を取ることにあります。AIは下のレイヤーを加速しますが、上のレイヤー、つまり何を作るか、誰が決めるかは人間に残ります。これは技術の問題ではなく、社会の仕組みに根ざした構造です。

「コードを書くだけ」のエンジニアは、たしかに役割が変わっていくでしょう。アセンブリ言語の専門職が高級言語の登場で姿を変えたように、職務は変化します。

一方で、複雑性を制御し、判断を下し、責任を取るエンジニアは、AIが進化するほど必要になります。AIが大量にコードを生み出すなら、それを統制し、方向づけ、責任を持つ人間がもっと必要になるからです。

おわりに

「AIがエンジニアを不要にする」という言葉は、エンジニアの仕事を「コードを書くこと」と単純に等しく見たときに成り立つ話です。実際のエンジニアリングは、人の言葉を仕様に翻訳すること、複雑なシステムを統制すること、トレードオフを判断すること、結果に責任を持つこと、といったもっと広い活動を含みます。これらはAIの普及によって、むしろ重要になっていくはずです。

フォン・ノイマンから始まったコンピュータの歴史は、「道具は人を不要にしない、人がより大きな問題を扱えるようにする」ということの繰り返しでした。AIもその延長線上にあります。

今コンピュータサイエンスを学んでいる学生のみなさん、今コードを書いているエンジニアのみなさん。あなたたちの仕事は消えません。形を変えながら、より上の階層へと進化していくだけです。

ここまでエンジニアの話として書いてきましたが、これは他の職業にも通じる話だと思っています。事務職、ライター、デザイナー、翻訳者、AIによる代替が語られているどの仕事にも、道具では代替できない核があるはずです。それを見つけて、意識的に育てていく。それは、あらゆる職業に共通する備えだと思います。

フォン・ノイマンが80年前に敷いた道は、今も続いています。そしてその道を歩いているのは、AIではなく、私たち人間です。