AI時代の開発言語と開発フレームワークーー人間の自由を広げてきた半世紀から、AIの自由を適切に削る時代へ

＜２０２６年７月２２日以前のコンテンツ一覧はこちら＞

はじめに――AIがコードを書くようになって、言語選びは重要でなくなったのか

　生成AIがプログラムを書けるようになったとき、最初に出てきた予想の一つは、「プログラミング言語の違いは、だんだん重要ではなくなる」というものだった。

　人間がJavaを書くのか、Pythonを書くのか、Goを書くのかを悩んでいたのは、人間自身がコードを書かなければならなかったからだ。AIに頼めば、どの言語でも書いてくれる。そうであれば、言語はAIの内部事情になり、人間は自然言語で要求だけ伝えればよい。

　一見すると筋が通っている。

　ところが2026年になって、むしろ逆のことが起こり始めた。

　GoogleのGoチームは2026年8月、「Why Go is an Ideal Language for AI-Assisted Software Engineering」という記事を公開し、AI時代には言語選択が以前より重要になると主張した。その理由は単純である。AIが大量のコードを書くようになると、開発のボトルネックが「書くこと」から「読むこと、検証すること、修正すること、そして長期間維持すること」へ移るからだ。［出典1：Google Developers Blog］

　これはかなり大きな転換である。

　これまでのプログラミング言語史は、かなり乱暴にまとめれば、人間により多くの表現力を与える歴史だった。

　これから始まる歴史は、少し違うかもしれない。

　AIにどこまで自由を与え、どこから先をコンパイラ、型、テスト、規約、フレームワーク、CI、品質ゲートによって禁止するのか。

　言い換えれば、AI時代の開発基盤を考えるときの問いは、

　「AIが一度、上手なコードを書ける言語はどれか」

　ではなく、

　「AIが10万回変更しても、そのコードベースが腐りにくい言語と開発基盤はどれか」

　へ変わっていく。

　そしてもう一つ。

　本稿では、AI時代に有力な開発基盤の条件として、「最も表現力の高い言語」であることより、「自由度を適切に削り、生成→検証→修正の閉ループを短くできること」を仮説として置く。

　本稿では、この二つを軸に、プログラミング言語とWeb開発フレームワークの歴史を振り返ってみたい。

1　AIのための開発言語小史――もちろん最初からAIのためだったわけではない

　FORTRAN、COBOL、C、C++、Java、JavaScript、PHP、Python、Ruby、C#、Go、Rust、TypeScript。

　当然ながら、これらの言語の大半は生成AIのために作られたものではない。

　しかし現在から振り返ると、各時代の設計思想の中に、AIと相性のよい性質と、AIに大量変更させると問題になりそうな性質が見えてくる。

　初期の高級言語が解決しようとしたのは、人間と機械の距離だった。

　機械語やアセンブリ言語を直接扱うのではなく、計算、帳票、業務処理、データ構造といった人間側の概念でプログラムを書く。その後、構造化プログラミング、オブジェクト指向、ガベージコレクション、例外処理、豊富な標準ライブラリなどが登場し、人間が機械の細部を意識しなくても大きなソフトウェアを構築できる方向へ進んでいった。

　つまり長い間、進歩とは、

　「人間が考えたことを、なるべく自由に、なるべく少ない労力で表現できるようにすること」

　だった。

　この方向をさらに押し進めたのが、Python、Ruby、JavaScriptなどの動的言語である。

　厳密な型宣言や大量の定型記述を減らし、少ないコードでアイデアを実行できる。Python、Ruby、JavaScriptなどの動的言語は、Webサービス、スタートアップ、データ分析、機械学習など多くの領域で広く利用されてきた。ただし、その普及と各領域の発展との因果関係を本稿だけで証明するものではない。

　そしてWeb開発では、npmやPyPIをはじめとする巨大なパッケージ生態系によって、「自分で全部作らない」ことも生産性の一部になった。

　人間がコードを書く世界では、これは非常に合理的だった。

　ところがAIがコードを書くようになると、この「自由」が別の顔を見せる。

　同じ処理を十通りに書ける。

　似たパッケージが百種類ある。

　プロジェクトごとにformatter、linter、test framework、build tool、package manager、directory layoutが違う。

　人間にとっては選択肢であったものが、AIにとっては探索空間になる。

2　GoはAI時代を予言していたのか

　そこで改めて面白く見えてくるのがGoである。

　Goは生成AIを想定して作られた言語ではない。

　Google内部の大規模ソフトウェア開発で、多数の開発者が巨大なコードベースを長期間共同で扱う問題から生まれた。Goの設計思想についてRob Pikeは2012年の時点で「Language Design in the Service of Software Engineering」と表現している。つまり「プログラムを書くための言語」というより、「ソフトウェアを組織で長く育てるための言語」という発想だった。［出典2：Go］

　ここがAI時代になると、突然違う意味を持ち始める。

　Goには標準formatterがある。標準test frameworkがある。module管理がある。静的型検査がある。脆弱性検査がある。そしてGo 1系には非常に強い互換性思想がある。

　さらに2026年のGo 1.26ではgo fixが大幅に作り直され、古いコードパターンを新しいidiomへ機械的に更新する「modernizers」が導入された。これはLLMに「このコードを今風に書き直して」とお願いするのとは意味が違う。同じ規則をコードベース全体へ決定論的に適用できる。［出典3：Go Blog］

　AI時代には、この差が大きい。

　LLMによるrefactoringは確率的である。

　同じ要求を二回出しても、二回とも同じ修正になるとは限らない。

　一方、compiler、formatter、linter、modernizerは決定論的である。

　という循環を高速で回せる。

　これはGoがAIに一番賢くコードを書かせる言語だ、という意味ではない。

　むしろ、

　AIが多少間違えても、間違いを早く発見して元の道へ戻しやすい。

　ここにGoの強さがある。

　ただし、一つ注意がいる。本稿の問題設定そのものがGoと相性がよい。統合されたtoolchain、標準化された書き方、決定論的な検査、長期互換性を重視して評価すれば、当然Goは高く評価されやすい。これは欠陥というより、「何を良い開発基盤と定義するか」が結果を左右する反射性である。本稿はGoが万能に一位だと主張するのではなく、AIの大量変更を収束させるという条件を置いたとき、Goの古い設計思想が急に現代的な意味を持つ、と見る。

3　Rust――自由を与える前に、危険な道を閉鎖する

　Rustはまた違う。

　Goが「皆が似たコードを書く」ことで分散を抑える方向だとすれば、Rustはさらに強く、

　「危険な状態そのものをコンパイル時に成立させない」

　方向へ進んだ。

　Rust 1.0は2015年に公開され、低レベルの性能制御と高い安全性を、ガベージコレクタなしで両立することを大きな目的としていた。現在もRust公式は、型システムとownership modelによってメモリ安全性やthread safetyを保証し、多くのバグをコンパイル時に排除することを主要な特徴としている。［出典4：Rust Blog］

　AIとの組み合わせを考えると、これは非常に興味深い。

　AIが存在しないmethodを呼ぶ。

　型を間違える。

　所有権を壊す。

　寿命が合わない。

　不正な共有を行う。

　Rustでは、そのかなりの部分をcompilerが門前払いする。

　さらにCargoにはcheck、test、fixがあり、cargo fixはrustcが提示した修正候補を実際のソースへ適用する。［出典5：Cargo Book］

　つまりRustは、

　AIに道路を自由に走らせ、事故が起きたら後で探す

　のではなく、

　そもそも危険な道路へ入るゲートを閉めておく

　思想に近い。

　もちろん代償もある。

　AIがRust compilerと何度も格闘する可能性がある。

　複雑なlifetimeを回避するために、不必要に入り組んだ実装を生成する可能性もある。

　したがってGoとRustの比較を「どちらがAI向きか」の一言で片づけるのは難しい。

　Goは収束しやすさ。

　Rustは拒否能力の強さ。

　両者は異なる方法で、AIの自由度を削っている。

4　TypeScriptとPython――自由な世界を後から囲う

　ではPythonやJavaScriptはAI時代に不利なのか。

　そこまで単純でもない。

　世界中に巨大なコード資産があり、ライブラリがあり、開発者がいる。こうした既存資産の厚みはAI coding toolにとって利用可能なcontextや既存patternを増やし得るが、その効果を本稿では直接測定していない。

　その代わり、「言語そのものを固くする」以外の方法で周囲を固める必要が出てくる。

　JavaScriptにTypeScriptを重ねるのは代表的な例である。

　Pythonでも同じことが起きている。

　2026年にはAstralのuvがPythonのproject/package管理を統合し、クロスプラットフォームのuniversal lockfileを提供している。言語そのものをRust化するのではなく、依存関係や開発環境の揺れを外側から減らそうとしている。［出典6：Astral uv］

　Denoはさらに面白い。

　TypeScript/JavaScriptという巨大な生態系を利用しながら、formatter、linter、type check、test、lockfile、CI向けinstallなどを一つのruntime/toolchainへ寄せている。2026年のdeno ciはlockfileを必須とし、同一commitから同一dependency treeを再現することを明示的に狙っている。［出典7：Deno Docs］

　ここから見えてくるのは、AI時代の勝敗が単純な静的言語対動的言語にはならないということである。

　柔らかい言語を、どれだけ固いtoolchainで包めるか。

　これも有力な設計になる。

5　開発フレームワーク小史――フレームワークとは「自由を捨てることで速くなる」仕組みだった

　言語の歴史以上に、AI時代との関係が面白いのがフレームワークである。

　フレームワークの歴史には多くの側面があるが、本稿では「毎回自由に設計する範囲を減らし、共通の作法へ寄せる仕組み」という側面に注目する。

　毎回自由に設計するのをやめる仕組みだった。

　Web開発の初期には、HTTP requestを受け、DBを読み、HTMLを生成し、responseを返す処理を各開発者が組み立てていた。

　やがてRailsやDjangoが登場する。

　Railsは「Convention over Configuration」を重要な原則として掲げた。

　名前はこう付ける。

　directoryはこう置く。

　DB tableはこうする。

　controllerとmodelはこう関係する。

　一般的なやり方を採用するなら、いちいち設定しなくてよい。

　Rails公式はいまもこれを設計原則として掲げている。［出典8：Ruby on Rails］

　Djangoも2005年に最初の公式releaseを公開し、認証、form、ORM、adminなど、Webアプリケーションに繰り返し必要になる仕組みを統合していった。［出典9：Django］

　当時は「開発者の生産性」のための仕組みだった。

　しかしAI時代から見ると、別の意味になる。

　Convention over Configurationとは、

　AIに毎回設計させない

　ことである。

　AIにdirectory構成を考えさせない。

　AIにORMの組み方を考えさせない。

　AIにroutingの流儀を考えさせない。

　一つの正解をあらかじめフレームワーク側が強く提示する。

　これはAI時代にはものすごく重要な性質になる。

　実際、2026年のRails公式サイトは、トップページで「Accelerate your agents with convention over configuration」とAI agentを前面に出している。二十年前から存在するRailsの思想が、そのままAI agent向けの利点として再解釈され始めたわけである。［出典10：Ruby on Rails］

6　そしてWebは複雑になった

　その後のWebは別の方向へ大きく進む。

　ブラウザが単なるHTML viewerではなく、application runtimeになった。

　JavaScriptの能力が増し、React、Vue、Angularなどを使って、ブラウザ内部へ大きなアプリケーションを構築するようになった。

　サーバーはJSONを返す。

　ブラウザが状態を持つ。

　client側でroutingする。

　API schemaがある。

　DTOがある。

　serializationがある。

　client cacheがある。

　state synchronizationがある。

　bundlerがある。

　package managerがある。

　hydrationがある。

　これはGoogle Maps、Figma、オンラインeditorのような高度なアプリケーションを成立させた大きな進歩だった。

　一方で、顧客管理や受発注のような比較的定型的な業務システムでも、独立したfrontend applicationとbackend applicationを採る構成は存在する。ただし、その構成が過剰かどうかは用途、組織、既存資産によって異なる。

　顧客検索。

　受注入力。

　承認。

　在庫照会。

　経費精算。

　ユーザー管理。

　マスタ保守。

　本来は「表示する、入力する、検証する、DBへ保存する」が中心の画面でも、独立したfrontend applicationとbackend applicationを持つことが珍しくなくなった。

　人間中心の開発では、この複雑さをfrontend engineerとbackend engineerの分業や規約によって管理してきた。

　だがAIが大量変更する世界では、境界が増えるほど、一般にAIが扱う必要のある契約、同期点、例外条件も増えやすい。

　自由度だけでなく、境界の数そのものがAI時代のコストになる。

7　Server-driven Webへの回帰

　そこで近年、Web開発には面白い揺り戻しが起きている。

　Hotwireは「JSONではなくHTMLを送る」ことを明確に掲げ、server-side templateを再利用しながらSPAに近い操作感を実現する。［出典11：Hotwire］

　Phoenix LiveViewも、stateをserver側へ置きながら、server-rendered HTMLでrichなreal-time UIを提供する。［出典12：Phoenix LiveView］

　これは昔のWebへ単純に戻ったのではない。

　server renderingの単純さを残しながら、現代的な部分更新とreactivityを取り戻す

　試みである。

　React自身もServer ComponentsやServer Functionsを持つようになり、「すべてをclientへ送る」単純なSPAモデルからserver/clientの役割を再配分する方向へ進んでいる。［出典13：React］

　つまり、少なくともここで挙げた複数の主要系統では、

　「どこまでをbrowserでやるべきなのか」

　をもう一度考え直している。

8　そこへTopcoatが現れた

　2026年7月に発表されたRustのTopcoatは、この流れをかなり極端な形で表現している。

　TopcoatはHTMLをserverで生成しながら、browser上の局所状態更新とserver処理もRustで記述する。frontend専用directoryやnpmを必須とせず、server-side rendering、部分的なreactivity、sessionのtransport layerまでを一つのRust世界へ集約する。

　特に興味深いのはreactivityの分割である。

　Topcoatは大きなclient applicationをそのままbrowserへ持っていくのではなく、局所状態を扱うsignal、server処理を呼ぶprocedure、server側で再描画してHTML断片を交換するshardという限定された実行形態に整理している。

　これは単に「Rustだけでfrontendも書けます」という話ではない。

　むしろ、

　frontendという独立した巨大サブシステムを、本当に毎回作る必要があるのか

　という問いである。

　Topcoatの公式発表も、server-renderedを基本とし、reactivityをHTMXに近いmetadataとして追加する設計を説明している。［出典14：Tokio Blog］

　もちろんTopcoatは2026年8月現在まだ実験的な段階である。

　ここには、本稿全体を象徴する少し面白いねじれがある。Topcoatのsignal、procedure、shardという限定された実行モデルは、「適切な不自由」「境界を減らす」「型で止める」という意味では、本稿がAI時代に有力だと考える思想そのものに近い。一方で、0.5系は破壊的変更を予告する実験段階であり、互換性と長寿命という今回もっとも重視する軸では、現時点ではむしろ弱い。思想は未来側、成熟度はまだ現在以前――その両方を同時に見る必要がある。

　認証、migration、backup、observability、deploymentまで消えるわけではない。

　フルスタックとは「企業システムの面倒な問題が全部消える魔法」ではない。

9　AI時代には「フルスタック」の意味も変わる

　これまでフルスタックという言葉は、おおむね、

　frontendからbackendまで一人、または一つの技術体系で扱える

　という意味だった。

　本稿では、AI時代の分析概念として、この言葉をさらに広く捉えてみる。

　までが一つの循環になっていることだ。

　本稿ではAI時代の「full-stack platform」を、UIからDBまでを扱えることだけではなく、

　コードの一生を一つの閉ループとして扱えること

　まで含む分析上の概念として用いる。

　このように捉えると、プログラミング言語、framework、CI/CD、security scanner、repository、observabilityを横断して設計する必要が強まり、従来の製品境界だけでは開発制度を説明しにくくなる可能性がある。

10　「10万回変更」で考えると景色が変わる

　ここで改めて明記しておきたい。「10万回」は測定済みの耐久試験回数ではない。100回、1,000回、1万回、10万回と変更が積み重なったときに、どの種類の小さな誤差が蓄積し、どの仕組みならそれを途中で止められるかを考えるための構造的ストレス思考実験である。

　AIコーディングの評価では、一つのtaskを何％成功させたかというbenchmarkがよく使われる。

　だが企業システムには、単発taskの成功率とは別に、反復変更による劣化を観察する評価の観点が必要なのではないか。

　同じcodebaseへAIが100回変更する。

　1,000回変更する。

　1万回変更する。

　そして10万回変更する。

　そのとき、何が起きるか。

　変更回数がまだ少ない段階では表面化しない問題が、反復とともに見えやすくなる可能性がある。

　しかし回数が増えると、

　似たutilityが増える。

　dependencyが増える。

　命名が揺れる。

　異なるarchitecture patternが混ざる。

　例外ruleが増える。

　testがflakyになる。

　「この部分だけ特別」が増える。

　誰も全体を説明できなくなる。

　そして最終的には、

　動いている。しかし誰も理解できない。

　というcodebaseになる可能性がある。

　これはAIが馬鹿だから起きるのではない。

　各変更の局所評価が高くても、未検出の微小な偏差が修正されず残れば、反復の中でarchitecture driftとして蓄積する可能性があるからである。

　AI時代の重要な問題は、生成品質だけではない。

　未検出の偏差が累積することも、その一つである。

11　そこで「閉ループの短さ」が効いてくる

　AIが間違えてから、人間のcode reviewで三日後に見つかる。

　これは長いloopである。

　AIが間違えた瞬間にcompilerがrejectする。

　これは短いloopである。

　AIがdependencyを追加した瞬間にlockfileとsecurity scannerが検査する。

　短い。

　PRを作った瞬間にquality gateが落とす。

　短い。

　productionでperformance regressionが起き、profile情報が次の修正へ戻る。

　これも閉ループである。

　2026年には、SonarQubeがAI-generated codeを対象にAI Code Assuranceと専用quality gateを提供し、AIコードに通常より明示的な品質条件を適用する方向へ進んでいる。［出典15：SonarQube］

　AtlassianのBitbucket Agentic Pipelinesはさらに象徴的だ。

　AI agentをCI/CDの外側で自由に動かすのではなく、既存pipelineの中へ直接入れ、失敗したpipelineの調査やflaky testの修正を行わせる。agentのpermissionもscoped tokenやMCP側で制約する構造になっている。［出典16：Atlassian］

　これは、

　AIに仕事を任せる

　から、

　AIを工程の中へ拘束する

　への変化である。

　企業システムでは、この方向が有力な設計候補の一つだと本稿では考える。

12　AI時代には「退屈なコード」が価値を持つ

　人間のプログラマー文化では、巧妙なcodeが評価されることがある。

　高度な抽象化。

　美しいmetaprogramming。

　極端に短い記述。

　巧妙なDSL。

　もちろん、それ自体が悪いわけではない。

　だがAIが10万回変更する世界では、別の価値観が強くなる。

　誰が書いても似ている。

　どこに何があるか分かる。

　formatterをかければ同じになる。

　同じ処理は同じ書き方になる。

　compilerが多くの間違いを拒否する。

　frameworkがdirectoryと責任分界を決めている。

　これは人間から見ると少し退屈である。

　本稿の仮説では、同一パターンへ収束しやすいコードはAIが変更方針を選ぶ際の分岐を減らしやすい。

　また、大量のAI生成コードをreviewする人間にとっても、比較対象を揃えやすくなると考えられる。

　AI時代には、

　boring is beautiful

　がかなり強い原則になるのではないか。

13　フレームワークにも「意見の強さ」が戻ってくる

　この観点から見ると、長い間嫌われることもあった「opinionated framework」が復権する可能性がある。

　自由に選べない。

　directoryも決められている。

　ORMも決まっている。

　routingも決まっている。

　test方法も決まっている。

　昔なら「窮屈だ」と言われた。

　AI時代には、

　AIが迷わない

　という利点に変わる。

　RailsのConvention over Configurationが再評価される理由もここにある。

　Djangoのbatteries-includedも同じである。

　Frappeのように認証、ORM、workflow、formまで業務アプリケーションに必要な多くの部品を一つのplatformへまとめる方式も、AIにとっては非常に理解しやすい可能性がある。

　逆に、無数のlibraryを組み合わせて独自stackを作る自由は、AI agentを多数投入する開発では、選択肢・契約・例外を増やして統制コストになり得ると本稿では考える。

14　ただしServer-drivenがすべてを征服するわけではない

　だからといって、ReactやSPAやWASMが消えるわけではない。

　ここは用途が分かれるだろう。

　Figma。

　CAD。

　動画編集。

　IDE。

　高度な地図。

　offline-first application。

　大量のlocal stateを長時間保持するapplication。

　こうした用途では、browserまたはclient側へ大きなruntimeやlocal stateを持たせる必要が生じる場面が多い。

　一方、

　顧客管理。

　受発注。

　在庫。

　承認。

　経費精算。

　契約。

　人事。

　マスタ管理。

　こうした業務アプリケーションでは、

　Server-side HTML + 部分更新 + 小さなlocal state

　を採用する余地があると本稿では仮説を置く。これは市場シェア予測ではなく、用途と責任分界から見たアーキテクチャ仮説である。

　したがって未来は一つへ収束するのではなく、二極化するのではないか。

　本当にclient applicationである必要があるものは、より高度なclientへ。

　本質的にはserver applicationであるものは、よりserverへ。

　中途半端に全部SPAにする時代が終わる可能性がある。

15　今後、言語とフレームワークはどうなるか

　ここから先は予想である。

　まず、AI時代の言語比較ではsyntaxの優劣が相対的に小さくなる。

　代わりに、

　compilerがどこまで拒否するか。

　formatterが統一されているか。

　標準testがあるか。

　dependencyを再現できるか。

　security scannerとつながるか。

　機械的refactoringができるか。

　compatibility promiseが強いか。

　AI agentがCLIから一貫して操作できるか。

　といったtoolchain全体が評価される。

　第二に、frameworkでは「何ができるか」より、

　何をさせないか

　が重要になる。

　serverとclientの実行場所を明示する。

　DBへ触れる場所を制限する。

　認証を通る経路を限定する。

　副作用の発生地点を限定する。

　agentが変更可能なdirectoryを限定する。

　つまりframeworkや周辺platformにarchitecture ruleの一部を埋め込む方向が、有力になる可能性がある。

　第三に、AI生成側とAI検証側を分ける設計が有力になると予想する。

　一つのLLMに、

　「作って」

　「自分で検査して」

　「問題ない？」

　と全部聞く方式から、

　生成agent。

　compiler。

　static analyzer。

　security scanner。

　AI reviewer。

　test。

　人間の承認。

　という異質なJudgeを重ねる方式へ進むだろう。

　第四に、deterministicな道具の価値が上がる。

　LLMへ全部書き直させるのではなく、compilerが理解できる変更はcompilerへ、formatterができるものはformatterへ、codemodでできるものはcodemodへ渡す。

　役割分担の一案として、compilerやcodemodでは処理しにくい、「意味を理解しなければ変えられない部分」をLLMへ残すことが考えられる。

　これはかなり健全な役割分担だと思う。

16　最終的には「言語」ではなく「開発制度」の競争になる

　そう考えると、数年後に「AIに最適な言語は何ですか」と聞くこと自体が、少し古い質問になっているかもしれない。

　Goなのか。

　Rustなのか。

　TypeScriptなのか。

　Pythonなのか。

　もちろん重要である。

　しかし企業が実際に評価すべき対象は、言語単体だけではなく、

　をまとめた開発制度である。

　AI時代には、プログラミング言語の外側にあるbuild、test、security、repository、権限、approvalまで含めて「開発制度」として設計する必要がある。

　何を書けるかだけではない。

　何を書いてはいけないか。

　何をすれば自動的に拒否されるか。

　何を通過すればproductionへ行けるか。

　誰が例外を認められるか。

　そこまで含めて、AIが働く環境になる。

おわりに――最も自由な言語ではなく、最も上手に自由を削った環境へ

　プログラミング言語の歴史は一つの見方をすれば、機械の細部を人間から隠し、人間側の概念で記述できる範囲を広げてきた歴史でもあった。

　frameworkの歴史にも多くの系譜があるが、本稿が注目する一面では、毎回同じものを自由に組み立てる範囲を減らし、定型作業を共通化してきた。

　そしてAIがコードを書くようになった。

　今度は少し立場が逆転する。

　AIには驚くほど大きな生成能力がある。

　だからこそ、必要なのはさらに大きな自由ではない。

　適切な不自由である。

　型に従え。

　このformatで書け。

　このdirectoryへ置け。

　dependencyはlockせよ。

　testを通せ。

　security gateを通せ。

　勝手にmainへmergeするな。

　productionの結果を見てから次を直せ。

　こうした一見地味な仕組みは、AIモデルの知能の高さとは別に、開発の安定性を左右する重要な設計要因になる。

　だから私は、これからの競争を、

　「最も賢いAIにコードを書かせる競争」

　だけだとは考えていない。

　むしろ、

　「モデルの賢さだけに依存せず、大量の反復変更でも壊れ方を局所化できる開発環境を作る競争」

　も、重要な競争軸になるのではないかと思う。

　GoもRustもRailsもDjangoもHotwireもLiveViewもTopcoatも、それぞれ全く違う時代に生まれた。

　しかし2026年の地点から、本稿が採用した「自由度を適切に削り、早く検証する」という補助線で眺めると、異なる系譜の間にも共通点が見えてくる。

　自由を無制限に増やすのではなく、良い道を選びやすくし、悪い道へ入りにくくする。

　人間のために作られたその思想が、巡り巡ってAIのためのソフトウェア工学になろうとしている。

参考Excelについて

　今回の検討では、二つの比較表を使った。一つは、Go、Rust、Deno、Python周辺toolchain、CI、quality gate、agentic development環境などを、「AIが大量に変更したときの腐りにくさ」と「生成→検証→修正の閉ループ」という観点から比較した世界アトラスである。

　もう一つは、Topcoatを起点に、htmx、Hotwire、Phoenix LiveView、Rails、Django、Vaadin、ZK、Leptos、Dioxus、Next.js、Frappeなど、世界72件のWeb framework／企業開発基盤を比較したアトラスである。「ライブなUI状態がどこに常駐するか」と「常時接続をUI成立条件にするか」を軸に加え、server-resident UIとbrowser局所状態型を分けて見られるようにした。

　二つのExcelはいずれも製品の優劣を決めるリーグ表ではなく、「どこで自由度を削り、どこへ状態を置き、どこで間違いを止めるのか」を見るための配置図である。

参考資料・出典URL

noteへ貼り付けた際にリンク属性が失われても確認できるよう、URLを可視文字列で記載しています。

［出典1］ Google Developers Blog — https://developers.googleblog.com/why-go-is-an-ideal-language-for-ai-assisted-software-engineering/

［出典2］ Go — https://go.dev/talks/2012/splash.article

［出典3］ Go Blog — https://go.dev/blog/gofix

［出典4］ Rust Blog — https://blog.rust-lang.org/2015/05/15/Rust-1.0/

［出典5］ Cargo Book — https://doc.rust-lang.org/cargo/commands/cargo-fix.html

［出典6］ Astral uv — https://docs.astral.sh/uv/concepts/projects/layout/

［出典7］ Deno Docs — https://docs.deno.com/runtime/reference/cli/ci/

［出典8］ Ruby on Rails — https://rubyonrails.org/doctrine

［出典9］ Django — https://www.djangoproject.com/weblog/2005/nov/16/firstrelease/

［出典10］ Ruby on Rails — https://rubyonrails.org/

［出典11］ Hotwire — https://hotwired.dev/

［出典12］ Phoenix LiveView — https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html

［出典13］ React — https://react.dev/reference/rsc/server-components

［出典14］ Tokio Blog — https://tokio.rs/blog/2026-07-22-announcing-topcoat

［出典15］ SonarQube — https://docs.sonarsource.com/agent-centric-development-cycle/ai-code-standards/ai-code-assurance

［出典16］ Atlassian — https://support.atlassian.com/bitbucket-cloud/docs/agentic-pipelines/