はじめに

この記事では、AIエージェントにコードを書かせる「AI駆動開発」と相性の良い技術スタックを整理します。
技術スタックの相性は、もちろん開発するアプリの仕様や実行環境、チーム体制などにもよります。
今回はそのなかでも、あくまで「AI駆動開発との相性」を全面に置いて調査しました。
公開されている統計・研究・公式ドキュメントの原典を確認しつつ、私自身が複数のサービスを並行して開発・運用するなかで感じている感覚を混ぜて書いています。

対象読者は、次のような方を想定しています。

これから個人開発や社内SaaSの技術選定をするエンジニア
すでにClaude CodeやCursorなどでコードを書かせていて、「どの言語・構成が一番エージェントと噛み合うのか」を言語化したい方
「AIが詳しい言語」だけで選んで、あとから型崩れやハルシネーションに悩まされている方

技術選定は事業のフェーズ・チームの習熟度・運用体制にも左右されるため、この記事の内容が唯一の正解というわけではありません。
本文の統計・バージョンはすべて2026年7月時点のもので、この領域は数ヶ月で状況が変わります。

要点（最初に結論）

現時点で私が最有力だと考える構成は、用途ごとに3系統に分かれます。Web・業務システムはTypeScript、AI・データ処理はPython、Gateway・常駐サービスはGoです。
汎用的なWeb開発では、TypeScriptを中心に据えて、必要な部分だけPythonやGoへ切り出す構成が一番バランスよく感じています。
AI駆動開発との相性は「LLMがその言語を知っているか」だけでは決まりません。型・LSP・コンパイラ・テスト・規約の明確さといった「AIの誤りを機械的に検出できるか」が同じくらい効きます。
Pythonは最もLLMが詳しい言語のひとつですが、素のままでは生成された誤りを実行前に発見しにくいです。型ヒント・Pydantic・Pyright・Ruff・pytestとセットで「型付きPython」として運用する前提で選んでいます。
技術の名前選びよりも、リポジトリ側で検証コマンドを1つに固定しておくことのほうが、体感では効果が大きいです。
最初からTypeScript・Python・Go・Rustを全部入れるのは避けています。まずTypeScriptでモジュラーモノリスを作り、計測結果が出た箇所だけ他言語へ分離していく段階的な拡張を基本方針にしています。

AI駆動開発との相性は何で決まるのか

まず前提の整理からです。
「AIが詳しい言語を選べばよい」という話をよく聞きますが、実際に長くエージェントに書かせていると、それだけでは足りないと感じます。

私の中では、相性を次のような掛け算で捉えています。

AI駆動開発との相性
＝ LLMの言語理解度
× 型・LSPによる意味解析
× コンパイラ／テストの検証能力
× 規約の明確さ
× ドキュメントとコード量
× フィードバック速度

掛け算なので、どれか1つでも極端に低いと全体が崩れます。
たとえばLLMがどれだけ詳しくても、生成した誤りを実行前に検出できない言語だと、レビューコストが跳ね上がります。
逆に、多少コード量が少ない言語でも、コンパイラとテストで「正しいかどうか」を毎回機械的に確かめられるなら、修正ループはむしろ安定します。

この視点で見ると、AI駆動開発の技術選定は「LLMが知っているか」から「AIの間違いをどれだけ早く・確実に潰せるか」へと軸が移ります。

LLMが詳しい言語を総合評価する

商用LLMは、言語ごとの学習トークン数を公開していません。
そのため以下は、公開コード量・ドキュメント量・利用者数・コード生成研究・ツールの成熟度からの総合的な見立てです。

コード生成の研究でも、Python・Java・JavaScriptのような「高リソース言語」は、コードやドキュメントが少ない言語よりLLMの生成性能が高くなりやすいことが指摘されています。

次の表は、私の主観を含む総合評価です。
これは汎用的な言語性能の順位ではなく、Web・SaaSを中心に、生成後の検証ループまで含めて評価した主観ランクです。
機械学習研究ならPython、組み込みやシステム開発ならRustやC++、大規模な既存業務システムならJavaやC#が上位に来る場面もあります。
「AI駆動開発適性」の S / A といったランクはあくまで感覚的な整理なので、参考程度に見てください。

言語	LLMの知識量	型・静的検査	LSP成熟度	AI駆動開発適性（Web/SaaS中心）	主な用途
TypeScript	非常に高い	非常に高い	非常に高い	S	Web、SaaS、Node.js
Python	非常に高い	中〜高	高い	S-	AI、データ、API
Go	高い	非常に高い	非常に高い	S-	API、Gateway、CLI、インフラ
Java	非常に高い	非常に高い	非常に高い	A+	大規模業務システム
C#	高い	非常に高い	非常に高い	A+	.NET、Azure、業務システム
SQL	非常に高い	DB依存	高い	A+	データモデル、検索、集計
PHP	高い	中	高い	A	Laravel、CRUD
Rust	中〜高	極めて高い	非常に高い	A-	高信頼・高性能処理
Kotlin	中〜高	非常に高い	高い	A-	Android、Spring
Ruby	高い	低〜中	中〜高	B+	Rails、CRUD
新興・独自DSL	低い	技術依存	低いことが多い	C	特殊用途

GitHubのOctoverse 2025では、月間コントリビューター数ベースで2025年8月時点に、TypeScriptが初めてPythonを抜いて最も使われた言語になりました。
GitHubは、主要フレームワークがTypeScriptを既定にしていることに加えて、AI支援開発と型付き言語の伸長に相関が見られると分析しています。
ただし、これはあくまで観察上のシグナルで、AIがTypeScriptへの移行を引き起こしたと因果関係まで実証したものではありません。
同レポートが引用している研究では、複数のオープンLLMにTypeScriptでコードを生成・変換・修復させた実験で、発生したコンパイルエラーの平均94%が型チェックの失敗だったと報告されています。
実開発でのすべてのLLMエラーに一般化できる数字ではありませんが、生成時に出る機械的なエラーの多くを型検査で受け止められる可能性を示す例だと感じます。
一方で、PythonはAI・データサイエンス領域で引き続き中心的な存在です。
Stack Overflowの2025年調査でも、JavaScript・SQL・Pythonといった言語が上位に並び、TypeScriptも主要言語のひとつとして定着しています。

TypeScriptが総合1位になる理由

LLMがJavaScript・TypeScript・Reactのコードを大量に学習していることに加えて、TypeScriptには次の利点があります。

型がコード中に明示される
フロントエンドとバックエンドを同じ言語で書ける
JSON・HTTP・ブラウザとの対応が自然
型チェックが速い
React・Node.js・テスト・UIライブラリが充実している
AIが修正した直後に、エラーを機械的に検出できる

この「修正直後に機械が誤りを教えてくれる」という点が、AI駆動開発では特に効きます。
ただし、anyや型アサーションを多用すると、この利点は簡単に消えます。
最低限、次のような設定で型の穴をふさいでおくのが前提だと考えています。

tsconfig.json

{
  "compilerOptions": {
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "exactOptionalPropertyTypes": true,
    "noImplicitOverride": true
  }
}

Pythonは「詳しいが、壊れやすい」

PythonはLLMが最も詳しい言語のひとつです。
一方で動的型付けなので、素のままではAIが生成した誤りを実行前に見つけにくいという弱点があります。
私が過去に痛い目を見たのも、たいていはPythonの「型を書いていない層」でした。

そのためAI駆動開発では、Pythonを単体で使うのではなく、次のセットで「型付きPython」として運用しています。

Python
+ 型ヒント
+ Pydantic
+ Pyright（strict）
+ Ruff
+ pytest

Pyrightは、コマンドラインの型検査とLanguage Serverの両方を提供します。
生成されたコードに対して型検査を毎回走らせることで、動的型付けの弱点をかなり埋められます。

GoはAgent実装との相性が良い

GoはTypeScriptやPythonほどコード量が多いとは限りません。
それでも、次の特性のおかげで、実際のAI修正ループが安定しやすいと感じています。

言語仕様が比較的小さい
標準フォーマッタが統一されている
コンパイルが速い
暗黙的なメタプログラミングが少ない
標準ライブラリが充実している
単一バイナリにしやすい
goplsが非常に成熟している

暗黙の魔法が少ないぶん、AIが読んでも実行時の挙動が想像しやすいです。
特にLLM Gateway・MCPサーバー・CLI・デーモン・バックグラウンドワーカーのように、「速くて壊れにくい常駐サービス」を作りたい場面では、有力な選択肢になります。

なぜLSPがAI駆動開発で効くのか

言語選びの話をすると型やLSPが繰り返し出てくるので、ここで一度LSPの役割を整理します。
LSP（Language Server Protocol）は、エディタやエージェントに対して、次のような「意味情報」を提供する仕組みです。

定義へ移動
参照箇所の列挙
シンボル検索
型情報
インターフェース実装
リネーム
診断エラー
コードアクション
補完

LSPはエディタとLanguage Serverの通信方式を標準化したものです。
これにより、異なるエディタやAIツールから同じ意味解析機能を使えます。

LLMだけでコードを探すと、基本的には文字列検索になります。
それぞれの手段で「コードをどう見ているか」を並べると、違いがはっきりします。

LLM + grep
→ 文字列としてコードを見る

LLM + Tree-sitter
→ 構文構造としてコードを見る

LLM + LSP
→ 型、定義、参照、シンボルとしてコードを見る

LLM + compiler + tests
→ 変更が正しいかを検証する

この積み上げを踏まえると、私が理想とするコーディングエージェントの動きは次の順番になります。

言語を選ぶときに「LSPが成熟しているか」を気にするのは、この5〜9のフィードバックが速く・正確になるからです。

主なLanguage Serverを整理すると次の通りです。

言語	Language Server	評価・注意点
TypeScript	`tsserver`	VS Code標準。厳密には独自プロトコル
TypeScript	`typescript-language-server`	`tsserver`をLSPとして公開するアダプター
Python	Pyright	CLI型検査とLanguage Serverを提供
Go	`gopls`	Goチーム公式。診断・解析・リファクタリング対応
Rust	`rust-analyzer`	Rustの意味解析に強い
Java	Eclipse JDT Language Server	Eclipse JDTベース
C#	Roslyn系Language Server	型・参照・リファクタリングが成熟
C/C++	`clangd`	Clangベースの強力な意味解析
Kotlin	Kotlin Language Server／IDE連携	IntelliJ系が特に強い

GoのgoplsはGoチーム公式で、ナビゲーション・補完・診断・解析・リファクタリングを提供します。
さらにgoplsはv0.20（2025年7月）から実験的なMCPサーバーを内蔵し、Claude CodeのようなAIアシスタントから意味解析機能を呼び出せるようになっています。
goplsが持つ機能の一部をMCPツールとして公開し、エージェントから使えるようにする方向に進んでいるわけです。
typescript-language-serverは、VS Codeが内部で使うtsserverを、LSP対応エディタ向けにラップする非公式アダプターです。

用途別の推奨スタック

ここからは、実際に組むときの構成を用途別に書いていきます。
繰り返しになりますが、私の現時点での組み方であって、唯一解ではありません。

Web SaaS・業務システム

Web寄りのサービスでは、TypeScriptを中心に次のような構成を基本にしています。

Language        TypeScript
Frontend        React
App設計          Next.js App Router / React SPA
Build Tool      Vite（React SPAの場合）
UI              Tailwind CSS + shadcn/ui
Validation      Zod
API             Hono / Fastify / Next Route Handlers
Database        PostgreSQL
ORM             Drizzle / Prisma
Contract        OpenAPI / JSON Schema / tRPC
Unit Test       Vitest
E2E Test        Playwright
Package Manager pnpm
CI              GitHub Actions
Environment     Docker Compose
Deployment      Vercel / Cloud Run / Railway / VPS

Next.jsとViteの使い分け

Next.jsとViteは、どちらが優れているという話ではなく、向き不向きで選んでいます。

Next.jsが向いていると感じるのは、次のような場面です。

SEOが重要
SSRやビルド時生成が必要
LP・メディア・SaaSを一体化したい
Server ComponentsやServer Actionsを使いたい
Vercelで運用する

一方、Vite＋Reactが向いていると感じるのは、次のような場面です。

管理画面や社内業務アプリ
SEOが不要
バックエンドAPIを明確に分離したい
SSR・キャッシュ・Server／Client境界を持ち込みたくない
構成を単純にしたい

AI駆動開発という観点だけで言えば、SEOが不要な業務アプリではVite＋Reactのほうが単純で壊れにくいことがあります。
Next.jsはLLMが詳しい一方で、次のような取り違えが起きやすいからです。

App RouterとPages Routerの混同
Server ComponentとClient Componentの混同
Route HandlerとServer Actionの混同
キャッシュ仕様のバージョン差
Node RuntimeとEdge Runtimeの差
古いAPIの生成

とはいえ、これはNext.jsが劣っているという話ではありません。
機能の広さゆえに選択肢が多く、AIが世代の違うAPIを混ぜやすい、というだけです。
Next.jsを使う場合は、利用バージョンを固定し、現在の公式ドキュメントをエージェントへ渡すようにしています。

ORMはPrismaかDrizzleか

ORMもよく聞かれるので、私の整理を書いておきます。
結論から言うと、どちらもAIと相性は良く、チームのSQL習熟度で選ぶのが素直だと考えています。

Prismaの長所は、LLMがよく知っていて、ドキュメントと事例が多く、スキーマが明確で、生成される型が強く、CRUDを高速に作れる点です。
短所は、独自スキーマ言語が増え、生成クライアントの理解が必要で、複雑なSQLで抽象化が漏れやすく、マイグレーションの挙動を把握する必要がある点です。

Drizzleの長所は、TypeScriptとSQLの対応が明示的で、抽象化が薄く、AIがSQLへ変換しやすく、型とテーブル定義が近く、生成コードを追いやすい点です。
短所は、Prismaより事例が少なく、高度な処理ではSQL知識が必要で、ライブラリ更新時の情報が混ざりやすい点です。

私の使い分けは、おおよそ次の通りです。

一般的なCRUD中心のSaaS
→ Prisma

SQLを理解していて、透明性を重視したい
→ Drizzle

複雑な分析・検索・性能最適化
→ SQL直接記述、Kysely、sqlc など

ただ、AIにとって本当に重要なのはORMの名前ではありません。
スキーマ・マイグレーション・制約・テストがリポジトリ内に明示されていることのほうが、はるかに効きます。

AI・LLM機能を持つシステム

AI機能があるからといって、システム全体をPythonにする必要はないと考えています。
私はむしろ、言語を役割で分ける構成を好んでいます。

Python側は、次のような構成でまとめています。

FastAPI
Pydantic
SQLAlchemy
Pyright（strict）
Ruff
pytest
uv
OpenTelemetry

このとき大事なのは、TypeScript側とPython側の境界にスキーマを置くことです。
OpenAPIまたはJSON Schemaを単一の正として、両側の型を生成します。

このとき、OpenAPIを正とする「契約ファースト」と、Python実装からOpenAPIを出力する「コードファースト」を混在させないことも大事です。
手書きで型を二重管理すると、片側だけ直して壊れる事故が起きます。
AIは特にこの二重管理を静かに壊しがちなので、境界の型は生成に寄せています。

LLM Gateway・MCPサーバー

LLM Gatewayや常駐プロキシのようなサービスでは、Goを有力候補にしています。

Language        Go
Language Server gopls
HTTP            net/http / chi
Streaming       SSE / WebSocket
Database        PostgreSQL
DB access       pgx + sqlc
Cache           Redis
Observability   OpenTelemetry
Metrics         Prometheus
Dashboard       Grafana
Contract        OpenAPI / Protobuf
Test            go test + testcontainers
Deployment      Docker / Kubernetes / 単一バイナリ

Goを選ぶ理由は、生成能力そのものよりも、生成後の検証が単純だからです。
次の4段階を毎回エージェントに実行させれば、構文・型・静的解析・テスト・ビルドを短時間で確認できます。

gofmt -w .
go vet ./...
go test ./...
go build ./...

このループの短さが、常駐サービスの安定運用にそのまま効いてきます。

避けたほうがよいと感じる技術選定

ここは特に好みが分かれる部分なので、「私はこう避けている」という書き方にします。

新しすぎるフレームワークは、LLMが旧バージョンのAPIを生成しやすく、検索結果や学習データも混ざりがちです。
独自DSLや社内フレームワークは、公開コードやドキュメントが少なく、モデルが推測で実装してしまいます。
動的メタプログラミングへの過度な依存も、コードを読んでも実行時の動作が分かりにくく、LSPや静的解析が弱くなります。
初期段階からのマイクロサービス化は、リポジトリ・契約・デプロイ・ログ・認証・テストが分散し、エージェントのコンテキスト消費を増やします。

同じTypeScriptでも、Serverless・Edge・Nodeを無秩序に混ぜると、利用可能なAPIやランタイム制約が変わって混乱のもとになります。
似た役割のライブラリを併用するのも、できるだけ避けています。

Jest + Vitest
Prisma + Drizzle
Express + Fastify + Hono
Zod + Valibot + Yup
ESLint + Biome の役割重複

AIは「どの流儀を使うべきか」を判断できず、既存コードと異なるパターンを足しやすくなります。
新しすぎる技術や独自規約の多い技術を避けるという考え方は、参考にしたZenn記事の指摘とも重なります。

技術スタック以上に効く「リポジトリ設計」

長く運用してきて一番実感するのは、技術そのものよりも一貫性のほうが効く、ということです。
AIが扱いやすいのは、次のように役割が整理され、検証コマンドが固定されたリポジトリです。

repo/
├── apps/
│   ├── web/
│   ├── api/
│   └── worker/
├── packages/
│   ├── contracts/
│   ├── database/
│   ├── ui/
│   └── config/
├── docs/
│   ├── architecture.md
│   ├── domain-model.md
│   ├── api.md
│   └── adr/
├── AGENTS.md
├── Makefile
└── package.json

そのうえで、エージェントに渡すコマンドを固定しておきます。

make format
make lint
make typecheck
make test
make test-integration
make test-e2e
make check

理想は、make checkやpnpm checkの1コマンドで、最低限次を実行できる状態です。

format check
→ lint
→ typecheck
→ unit test
→ build

AIに複雑なコマンドを毎回考えさせるのではなく、リポジトリ側で「正しい検証方法」を固定します。
このひと手間が、生成→検証→修正のループを何倍も安定させてくれます。

まとめ

現時点で私がたどり着いている構成を、最後にもう一度整理します。

汎用的なSaaS・業務アプリの標準は、次の構成です。

TypeScript（strict）
React
Next.js または Vite
Tailwind CSS
shadcn/ui
Zod
Fastify または Hono
PostgreSQL
Drizzle または Prisma
OpenAPI
Vitest
Playwright
pnpm
Docker Compose
GitHub Actions

Python固有のML・データ処理ライブラリが必要になった箇所は、Python系（FastAPI・Pydantic・Pyright strict・Ruff・pytest）への分離を検討します。
LLM API呼び出しやRAG、SSEストリーミング、一般的なGatewayはTypeScriptでも十分に書けるので、まずはTypeScriptで実装します。
そのうえで、負荷計測や運用要件から並行処理性能・メモリ効率・単一バイナリ配布などが必要になった段階で、Go系（gopls・pgx・sqlc・OpenTelemetry）への分離を検討します。
言語を増やすほどAPI契約・デプロイ・監視・障害対応のコストも増えるので、分離の条件は「機能カテゴリ」ではなく「TypeScriptでは満たせない具体的な要件」に置くのが安全だと考えています。

一番避けたいのは、最初からTypeScript・Python・Go・Rustを全部入れてしまうことです。
基本方針は次の段階的な拡張です。

AI駆動開発の技術選定は、「LLMがその言語を知っているか」から「AIの間違いをどれだけ早く・確実に潰せるか」へと軸が移っている、というのが今回のいちばん伝えたい点です。
型・LSP・コンパイラ・テスト・そしてリポジトリの一貫性をそろえておくと、同じLLMでも生成の安定度がまるで変わってきます。
ここに書いたのはあくまで私の現時点の組み方であり、事業のフェーズやチームの習熟度が変われば最適解も変わります。