2026.10.23 10:01 (更新: 2026.10.23)

AI時代の開発言語の選び方：12の選定基準と主要言語の解説

Taikai Hirose

はじめに

AIコーディングアシスタントやAIエージェントが、コードを書くだけでなく、テスト、修正、リファクタリングまで担うようになりました。そうなると言語選定の前提も変わります。

従来は「人間が速く書けるか」「人間が習得しやすいか」が重視されてきました。AI時代には、それに加えて次の2点が大きな比重を持つようになります。

AIが正しく書けるか
AIが書いたコードを、機械と人間が検証しやすいか

この記事では、まず選定基準を整理し、それぞれの論拠と、その基準で有利・不利になる言語を示します。そのうえで主要な開発言語を一つずつ解説します。

第1部：AI時代の言語選定基準

基準1：学習データの量（AIの習熟度）

論拠

大規模言語モデル（Large Language Model）は、公開されているコードを学習しています。学習データが多い言語ほど、慣用的で正しいコードを生成できます。複数言語でコード生成の正答率を比べた研究（MultiPL-Eなど）でも、利用者が少ない言語は正答率が下がる傾向が繰り返し報告されています。

優位：Python、JavaScript、TypeScript、Java、C#、Go
劣位：Elixir、Haskell、OCaml、Zig、Nim などのニッチな言語、社内独自言語、古い独自方言

基準2：静的型付けと型システムの強さ

論拠

AIはもっともらしい間違い、いわゆる「ハルシネーション」を起こします。たとえば、存在しないメソッドを呼ぶ、引数の順序を誤る、null（値がない状態）を考慮しない、といったものです。静的型付けの言語では、こうした誤りの多くを実行前にコンパイラ（型検査器）が機械的に検出します。AIエージェントはそのエラーを読んで自分で直せるので、自己修正のループが成り立ちます。

GitHubの年次レポート「Octoverse 2025」で、TypeScriptが利用者数でトップになった背景としてAI支援開発との相性が挙げられていることも、この流れを示しています。

優位：Rust、TypeScript、Kotlin、Swift、C#、Go、Java
劣位：型ヒントのないPython、素のJavaScript、Ruby、PHP（型宣言を使わない場合）

基準3：コンパイラ・ツールのエラーメッセージの質

論拠

AIエージェントは「書く→ビルドする→エラーを読む→直す」を繰り返して作業します。エラーメッセージが具体的で、修正案まで示してくれる言語ほど、この反復が速く収束します。

優位：Rust（修正案まで提示する丁寧なエラー）、Elm、TypeScript、Go
劣位：C++（テンプレート関連の膨大で難解なエラー）、動的言語の実行時エラー（実行してみないと分からない）

基準4：言語仕様とライブラリの安定性

論拠

AIの知識は学習時点で止まっています。仕様やフレームワークの変化が速い言語では、古い書き方や廃止されたAPI（Application Programming Interface、外部から呼び出すための窓口） が生成されやすくなります。後方互換性を重視する言語ほど、AIの出力が「そのまま動く」確率が上がります。

優位：Go（互換性の約束が強い）、Java、C
劣位：Swift（言語仕様の変化が比較的大きい）、JavaScriptのフロントエンドフレームワーク周辺（React、Next.jsなどの変化が速い）、Python 2と3の混在による生成ブレ

基準5：書き方の一意性（イディオムの統一度）

論拠

同じことを書く方法が少ない言語ほど、AIの出力が安定し、人間のレビューも楽になります。公式フォーマッタ（コード整形ツール）が事実上の標準になっている言語は、差分も読みやすくなります。

優位：Go（gofmtによる統一、言語機能を意図的に少なくしている）、Rust（rustfmt）、Python（「やり方は一つであるべき」という思想）
劣位：C++（世代ごとに書き方が大きく違う）、Perl、Scala（関数型とオブジェクト指向の流儀が混在）

基準6：可読性とレビューのしやすさ

論拠

AIが書く量が増えるほど、人間の仕事は「書く」から「読んで承認する」に移ります。最終責任を負うのは人間なので、読みやすさの価値は以前より上がっています。

優位：Python、Go、Kotlin、C#
劣位：C++、Haskell（読める人が限られる）、過度にメタプログラミングされたRuby

基準7：安全性（メモリ安全性と実行時エラー）

論拠

AIは境界チェックや解放処理の漏れのような、目に見えにくい不具合を混入させることがあります。メモリ安全でない言語では、それがそのまま脆弱性になります。米国の政府機関などがメモリ安全な言語への移行を推奨している流れもあります。

優位：Rust、Go、Java、C#、Kotlin、Swift
劣位：C、C++

基準8：エコシステムとパッケージの信頼性

論拠

ライブラリが豊富なほど、AIは「車輪の再発明」をせずに済みます。一方で、AIが存在しないパッケージ名をでっち上げ、攻撃者がその名前で悪意あるパッケージを公開する「スロップスクワッティング」という攻撃も確認されています。規模の大きさと、管理の厳格さの両方を見る必要があります。

優位（豊富さ）：Python（PyPI）、JavaScript/TypeScript（npm）、Java（Maven）
注意点：npmやPyPIは規模が大きいぶん、偽パッケージの危険も大きくなります。標準ライブラリが充実したGoや、.NET基盤が統一されているC#は依存を減らしやすいです。

基準9：テストと検証のしやすさ

論拠

AI時代の品質保証は「テストで縛って、AIに自由に書かせる」のが基本形です。テストフレームワークが標準で付いていて、すぐ実行できる言語ほど有利です。

優位：Go（go testが標準）、Rust（cargo testが標準）、Python（pytest）、TypeScript（Vitest、Jest）
劣位：C/C++（ビルドとテストの構成が環境ごとにばらばら）

基準10：実行性能と運用コスト

論拠

これまで「Rustは書くのが大変」「C++は難しい」という理由で避けられてきた言語も、書く負担の多くをAIが肩代わりすることで選びやすくなりました。「書きやすさ」の重みが下がった分、実行速度、メモリ効率、クラウド費用といった実行時の特性の重みが上がっています。

優位：Rust、Go、C++、C#、Java
劣位：Python、Ruby（性能が必要な部分は別言語や外部ライブラリに頼ることになる）

基準11：コンテキスト効率（記述量）

論拠

AIが一度に参照できる情報量（コンテキストウィンドウ）には上限があります。冗長な言語ほど、同じ機能を表すのに多くの量を使います。ただし、記述が明示的であることはAIの理解を助ける面もあり、一概に短ければよいわけではありません。

優位：Python、Kotlin、Go（簡潔さと明示性のバランスがよい）
劣位：Java（定型コードが多い。近年の版では改善が進んでいます）、C++

基準12：人材とチーム、既存資産

論拠

AIがあっても、障害対応、設計判断、レビューは人間が担います。チームが読めない言語をAIに書かせるのは、誰も保守できないコードを生み出す危険があります。既存のコード資産やドメイン知識との整合も、依然として重要です。

判断方法：「チームの誰かがその言語のコードを責任を持ってレビューできるか」を最低条件にする

第2部：主要開発言語の解説（AI時代の視点で）

Python

概要：データ分析、機械学習、自動化、Webのバックエンドなどで使われる汎用言語です。

優位
- 学習データが最も多い部類で、AIの生成品質が非常に高い
- 機械学習やAI関連のライブラリでは事実上の標準
- 読みやすく、人間のレビューが容易
劣位
- 動的型付けのため、型ヒントと型検査器（mypy、Pyright）を使わないと誤りが実行時まで見つからない
- 実行性能が低い
- 依存関係の管理が混乱しやすい（近年はuvなどで改善）
AI時代の使い方：型ヒントを必須にし、型検査器と自動テストを継続的インテグレーション（コードを変更するたびに自動で検証する仕組み）に組み込むことで、AIとの相性が一段上がります。

TypeScript

概要：JavaScriptに静的型を加えた言語です。Webのフロントエンド、バックエンド（Node.js、Deno、Bun）、デスクトップアプリまで幅広く使われます。

優位
- 学習データの豊富さと静的型付けを両立しており、AI時代の「最もバランスの良い言語」の一つ
- 型エラーを手がかりにAIが自己修正しやすい
- フロントエンドからバックエンドまで一つの言語で書ける
劣位
- フレームワークの変化が速く、AIが古い書き方を出しやすい
- npmの依存関係が深くなりやすく、サプライチェーン攻撃の危険がある
- any型を多用すると型の恩恵が消える
AI時代の使い方：strictモードを有効にし、anyを禁止する設定にしておくと、AIの出力品質が安定します。

JavaScript（型なし）

優位：学習データ量は最大級。どこでも動く
劣位：型がないため、AIの誤りを機械的に検出しにくい
結論：新規開発ならTypeScriptを選ぶ理由のほうがはるかに多いのが現状です。

Go

概要：Googleが開発したシンプルなコンパイル言語です。クラウド基盤、コマンドラインツール、マイクロサービスで広く使われています。

優位
- 言語機能が少なく書き方がほぼ一通りなので、AIの出力がぶれにくい
- 後方互換性が強く、古い知識でも動くコードが生成されやすい
- フォーマッタ、テスト、ビルドが標準で揃っており、AIエージェントの作業ループが速い
- コンパイルが非常に速い
劣位
- 表現力が控えめで、エラー処理などの記述が冗長になりがち
- 機械学習やGUI（画面を持つアプリケーション）の分野は弱い
AI時代の評価：「AIに書かせ、人間が読む」という分業に最も向いた言語の一つです。

Rust

概要：メモリ安全性と高い性能を両立したシステムプログラミング言語です。

優位
- 非常に強い型システムと所有権の仕組みにより、「コンパイルが通れば多くの不具合が消えている」状態を作れる
- エラーメッセージが丁寧で、AIの自己修正ループと相性が抜群
- 学習が難しいという最大の弱点を、AIがかなり補ってくれる
劣位
- 学習データはPythonやTypeScriptより少なく、複雑なライフタイム（参照の有効期間）の扱いではAIもつまずく
- コンパイルが遅い
- 人間側にもレビューできる知識が必要
AI時代の評価：AIの登場で最も「選びやすくなった」言語です。性能や安全性が必要な場面では第一候補になります。

Java

概要：企業システムの中核を長く担ってきた言語です。

優位
- 学習データが膨大で、企業向けの設計パターンをAIがよく知っている
- 静的型付けで、ツール（IntelliJ IDEAなど）も成熟している
- 後方互換性が高い
劣位
- 冗長で、AIのコンテキストを多く消費する
- AIが古い書き方（Java 8以前の流儀）を出しやすい
AI時代の使い方：既存資産の保守や近代化（古いバージョンからの移行）こそ、AIが大きな価値を出す領域です。

Kotlin

概要：Javaと互換性があり、より簡潔に書ける言語です。Androidの公式言語でもあります。

優位：簡潔さ、null安全性、静的型付けをバランスよく備え、Java資産も活用できる
劣位：学習データはJavaより少なく、マルチプラットフォーム関連の新しい機能ではAIの知識が追いついていないことがある

C#

概要：Microsoftの.NET基盤の言語です。業務システム、ゲーム（Unity）、Windowsアプリケーションで使われます。

優位
- 静的型付けで、標準ライブラリと公式ツールが統一されている
- 学習データが豊富で、Microsoft自身もAI支援ツールに力を入れている
- 依存関係が比較的整理されている
劣位
- バージョンごとの文法追加が多く、AIの出力が新旧混在しやすい
- .NET以外の基盤では存在感が薄い

Swift

概要：Appleのプラットフォーム（iOS、macOSなど）向けの言語です。

優位：Apple向け開発では事実上唯一の選択肢。型安全
劣位
- 言語仕様やフレームワーク（SwiftUI、並行処理の仕組み）の変化が速く、AIが古い書き方や存在しないAPIを出しやすい
- 学習データが比較的少ない
AI時代の使い方：最新の公式ドキュメントをAIに参照させる運用が特に重要です。

C / C++

概要：OS、組み込み機器、ゲームエンジン、高性能計算の基盤となる言語です。

優位
- 性能が最高水準で、ハードウェアに近い処理が書ける
- 既存資産が莫大で、学習データも多い
劣位
- メモリ安全でないため、AIの小さなミスがそのまま脆弱性になる
- C++は書き方の流派が多く、エラーメッセージも難解
- ビルド環境がばらばらで、AIエージェントが自律的に検証しにくい
AI時代の評価：既存資産の保守では必要ですが、新規開発ではRustなどへの置き換えを検討する価値が高まっています。

PHP

優位：Web、特にWordPressやLaravel周辺の学習データが膨大
劣位：古い書き方のコードが大量に学習されているため、AIが危険な書き方（SQLインジェクションに弱いコードなど）を出すことがある
使い方：型宣言と静的解析ツール（PHPStanなど）を必ず併用します。

Ruby

優位：Ruby on Railsによる高速なWebアプリ開発。Railsの規約が強いので、AIも構成を推測しやすい
劣位：動的型付けで、メタプログラミング（実行時にコードを生成する手法）が多く、AIも人間も挙動を追いにくい。学習データも相対的に減ってきている

ニッチな言語（Elixir、Haskell、Zig など）

優位：それぞれの領域（高い並行性、厳密な型、低レイヤー制御）で強力
劣位：学習データが少なくAIの精度が落ちる。仕様変更（Zigなど）に知識が追いつかない
判断：チームに専門家がいて、その言語でなければ得られない価値が明確な場合に限って選ぶのが無難です。

第3部：言語ごとの評価まとめ

◎＝非常に有利、○＝有利、△＝条件付き、×＝不利

言語	学習データ量	型による検証	仕様の安定性	書き方の統一	安全性	性能
Python	◎	△	○	○	○	×
TypeScript	◎	○	△	△	○	△
Go	○	○	◎	◎	○	○
Rust	○	◎	○	○	◎	◎
Java	◎	○	◎	○	○	○
Kotlin	○	◎	○	○	◎	○
C#	◎	○	○	○	○	○
Swift	△	◎	△	○	◎	○
C/C++	○	△	○	×	×	◎
PHP	◎	△	○	△	△	△
Ruby	△	×	○	△	○	×

第4部：用途別のおすすめ

ここでは用途ごとに、次の5つの観点で整理します。

第一候補：AI時代の基準で最も合理的な選択
理由：第1部のどの基準が効いているか
代替候補：条件によっては第一候補より良い選択
避けたい選択：AI時代に特に不利になりやすい選択
AIに書かせる際の注意点：その用途で起きやすい失敗と対策

1. Webフロントエンド

第一候補：TypeScript（React、Vue、Svelte など）
理由
- ブラウザで動く言語は事実上JavaScript系しかなく、その中で静的型を持つのはTypeScriptだけ（基準2）
- 学習データが最大級で、画面部品（コンポーネント）の生成はAIが最も得意とする分野の一つ（基準1）
- 画面の見た目はAIの出力を目で確認しやすく、修正の往復が速い
代替候補
- 小規模なサイトや静的なページなら、フレームワークを使わずHTMLと少量のTypeScriptで十分
- サーバー側で画面を組み立てる方式（Rails、Laravel、Django、htmxなど）は、フロントエンドを薄く保てるため、チームにフロントエンドの専門家がいない場合に有効
避けたい選択：型のないJavaScriptでの大規模開発
AIに書かせる際の注意点
- フレームワークの変化が速く、AIが古い書き方を出しやすい（基準4）。たとえばReactのクラスコンポーネント、Next.jsの古いルーティング方式（Pages Router）など
- 対策として、使用するフレームワークのバージョンと方針（「App Routerを使う」など）をプロジェクトのルールファイルに明記する
- 見た目の確認はAIに任せきりにせず、ブラウザで実際に操作して確かめる

2. Webバックエンド、API開発

第一候補：TypeScript（Node.js、Bun）または Go
理由
- TypeScript：フロントエンドと型定義を共有でき、APIの入出力の食い違いをコンパイル時に検出できる（基準2）
- Go：標準ライブラリだけでWebサーバーが書け、依存が少なく、書き方がぶれにくい（基準5、基準8）。実行性能とメモリ効率も高い（基準10）
使い分けの目安
- フロントエンドと同じチームで開発する、開発速度を優先する → TypeScript
- 長期運用、高負荷、少人数での保守を重視する → Go
代替候補
- Python（FastAPI）：機械学習の機能を組み込むAPIなら有力
- Kotlin、Java（Spring Boot）、C#（ASP.NET Core）：組織の標準や既存資産がある場合
- Ruby on Rails、Laravel（PHP）：管理画面中心の業務アプリを短期間で作る場合。規約が強く、AIも構成を推測しやすい
避けたい選択：型検査を入れない動的言語での大規模API
AIに書かせる際の注意点
- 認証、認可、入力値の検証、SQLインジェクション対策はAIが漏らしやすい。セキュリティに関わる部分は必ず人間がレビューする
- API仕様（OpenAPIなど）を先に定義し、そこから型やコードを生成する「仕様先行」の進め方にすると、AIの出力が仕様から外れにくい

3. データ分析、機械学習

第一候補：Python
理由
- pandas、Polars、NumPy、scikit-learn、PyTorchなど、主要なライブラリがほぼPythonに集中している（基準8）
- 学習データが最大級で、分析コードの生成精度が非常に高い（基準1）
- Jupyterノートブックで「AIに書かせる→すぐ実行して結果を見る」の往復ができる
代替候補
- SQL：データの集計や加工の多くはSQLで書くほうが簡潔で、AIの生成精度も高い。データウェアハウス（BigQuery、Snowflake、Redshiftなど）を使うならSQLが主役になる
- R：統計解析の専門分野では依然として強い
- Rust：Pythonライブラリの高速化部分を自作する場合
避けたい選択：分析のためだけにJavaやC#を選ぶ（ライブラリが乏しく、AIの支援も弱い）
AIに書かせる際の注意点
- 分析コードは「エラーなく動くが結果が間違っている」ことが多い。集計結果をサンプルデータで手計算と突き合わせる
- 実験用のノートブックを本番コードに昇格させる時点で、型ヒントとテストを追加する

4. AIを組み込んだアプリケーション（大規模言語モデルの活用）

第一候補：Python または TypeScript
理由
- 大規模言語モデルの各社の公式開発キット（SDK）は、PythonとTypeScriptが最優先で提供される（基準8）
- AIエージェント構築用のフレームワークや、AIと外部ツールをつなぐ規格（Model Context Protocol）の公式実装も、まずこの2言語で整備される
使い分けの目安
- モデルの評価、データ加工、検索拡張生成（社内文書などを検索してAIに渡す仕組み）の精度改善が中心 → Python
- Webアプリやチャット画面への組み込み、ストリーミング表示が中心 → TypeScript
代替候補：Go、C#、Java（各社の開発キットは揃いつつあるが、新機能の対応はやや遅れる）
避けたい選択：開発キットが公式に提供されていない言語で、APIを直接呼ぶ処理を自作すること
AIに書かせる際の注意点
- この分野は変化が特に速く、AIの知識が最も古くなりやすい。モデル名やAPIの書き方は必ず最新の公式ドキュメントで確認する
- APIキーをコードに直接書かせない。環境変数や秘密情報管理サービス（AWS Secrets Managerなど）から読み込む形にする

5. クラウド基盤、インフラのコード化

第一候補
- インフラ定義：Terraform（HCLという専用言語）、またはAWS CDK（TypeScript）
- サーバーレス関数（AWS Lambdaなど）：Python、TypeScript、Go
理由
- Terraform：記述が宣言的（「どうあるべきか」を書く）で、AIの生成精度が高い。実行前に変更内容を確認する仕組み（plan）があり、AIの誤りを人間が適用前に止められる
- AWS CDK（TypeScript）：型補完が効き、設定ミスをコンパイル時に検出できる（基準2）
- Python、TypeScript：サーバーレス関数の学習データが豊富
- Go：起動が速く、メモリ使用量が少ないため、実行回数の多い関数で費用を抑えやすい（基準10）
避けたい選択：管理画面での手作業の構築（AIもレビューも介在できない）
AIに書かせる際の注意点
- 権限設定を広くしすぎるのがAIの典型的な失敗。"Action": "*" のような全権限の付与がないか必ず確認する
- ランタイム（実行環境）のバージョンが古いまま生成されやすい。サポート終了済みのバージョン（たとえば古いPythonやNode.js）を指定していないか確認する
- 本番環境への適用はAIに直接実行させず、変更内容の確認を人間が行う

6. コマンドラインツール、業務自動化スクリプト

第一候補
- 社内の小さな自動化：Python
- 配布して多くの人に使ってもらうツール：Go または Rust
理由
- Python：書き捨てのスクリプトを最速で作れる。AIの生成精度も最高水準
- Go、Rust：実行ファイル1つで配布でき、利用者の環境にPythonなどを入れてもらう必要がない。起動も速い
代替候補
- シェルスクリプト（Bash、zsh）：数行で済む処理なら最適。ただし数十行を超えたらPythonなどに移す
- PowerShell：Windows環境やMicrosoft 365、Entra ID（旧Azure Active Directory）の管理なら第一候補
避けたい選択：長く複雑なシェルスクリプト。エラー処理や引用符の扱いでAIも人間も間違えやすい
AIに書かせる際の注意点
- ファイル削除や一括更新を含むスクリプトは、まず「実際には変更せず、何が起きるかだけ表示する」モード（ドライラン）を付けさせる
- Dockerなど既存の実行環境を前提にしたスクリプトは、AIが「簡略化」のつもりで構成を変えてしまうことがあるため、前提条件を明示しておく

7. モバイルアプリ

第一候補
- iOSのみ：Swift（SwiftUI）
- Androidのみ：Kotlin（Jetpack Compose）
- 両方を1つのコードで：Flutter（Dart）、React Native（TypeScript）、Kotlin Multiplatform
理由
- 各プラットフォームの公式言語は、新機能への対応が最も早く、性能と操作感も最良
- クロスプラットフォームの選択肢は、開発量をほぼ半分にできる
使い分けの目安
- Web開発の経験者が多い → React Native（TypeScriptの知識と学習データの多さを活かせる）
- 見た目の作り込みと動作の滑らかさを重視 → Flutter
- 既存のAndroidアプリやKotlinの資産がある → Kotlin Multiplatform
避けたい選択：アプリ用の機能が多いのに、Webページをアプリの枠で包むだけの方式を選ぶこと
AIに書かせる際の注意点
- SwiftUIやJetpack Composeは変化が速く、AIが古い書き方や存在しないAPIを出しやすい（基準4）
- 実機での動作確認、アプリストアの審査対応はAIでは代替できない。ここに十分な時間を確保する

8. デスクトップアプリ

第一候補
- Windows中心の業務アプリ：C#（.NET）
- 複数OS対応：Tauri（画面はTypeScript、内部処理はRust）または Electron（TypeScript）
- macOS専用：Swift
理由
- C#：Windowsとの統合が最も深く、業務アプリの学習データも豊富
- Tauri：Electronより配布サイズとメモリ使用量が小さい。画面部分はWeb技術なのでAIの支援を受けやすい
- Electron：実績が多く、学習データも豊富。ただし重くなりやすい
AIに書かせる際の注意点：OSごとの差異（ファイルパス、権限、署名と公証の手続き）でAIが誤りやすい。各OSで実際に動かして確認する

9. 大規模な企業システム、基幹業務

第一候補：Java、Kotlin、C#（組織の既存資産と標準に合わせる）
理由
- 静的型付け、成熟したツール、長期の後方互換性がそろっている（基準2、基準4）
- 企業向けの設計パターンの学習データが豊富（基準1）
- 人材を確保しやすく、長期保守の体制を組みやすい（基準12）
代替候補：Go（新規のマイクロサービス部分）、TypeScript（社内向けの画面部分）
避けたい選択：流行を理由に、チームが読めない言語へ全面移行すること
AIに書かせる際の注意点
- この領域でのAIの最大の価値は、新規開発より既存システムの理解と近代化にある。古いコードの解説、テストの追加、Javaのバージョンアップ、フレームワークの移行などで大きく効率が上がる
- 業務ルールはコードに書かれていない暗黙知であることが多く、AIは推測で補ってしまう。仕様書や業務担当者の確認を必ず挟む

10. 組み込み機器、IoT（ネットにつながる機器）

第一候補：C（既存資産がある場合）、Rust（新規開発の場合）
理由
- 使用できるメモリや処理能力が極めて限られ、ハードウェアを直接制御する必要がある
- Rust：C並みの性能でメモリ安全性を確保できる（基準7）。組み込み向けの仕組み（Embassyなど）も成熟しつつある
- C：対応する機器、開発環境、既存資産が圧倒的に多い
代替候補：MicroPython（試作や教育用途）、C++（既存の大規模資産がある場合）
AIに書かせる際の注意点
- 機器ごとの仕様（レジスタの番地、タイミングの制約）はAIの知識が不正確になりやすい。データシート（部品の仕様書）と必ず突き合わせる
- 実機でしか再現しない不具合が多く、AIの自己修正ループが回しにくい。シミュレーターやハードウェアを使わないテストの割合を増やす工夫が必要

11. ゲーム開発

第一候補
- Unity：C#
- Unreal Engine：C++（とブループリントという視覚的な記述方式）
- Godot：GDScript または C#
理由：ゲームではエンジンの選択が先にあり、言語はエンジンに従って決まる
AI時代の観点
- Unity（C#）は学習データが特に豊富で、AIの支援を受けやすい
- Unreal EngineのC++はエンジン独自の書き方が多く、AIの精度がやや落ちる
- Godotは利用者が増えているが、バージョン間の変化（3系から4系）でAIが古い書き方を出しやすい
AIに書かせる際の注意点：ゲームの面白さや操作感はテストで検証できない。AIにはロジックや道具作りを任せ、調整は人間が実際に遊んで行う

12. 高性能システム、ミドルウェア、データベースなどの基盤ソフトウェア

第一候補：Rust
理由
- 性能、メモリ安全性、並行処理の安全性を同時に満たせる（基準7、基準10）
- かつての「書くのが難しい」という弱点をAIが補うため、採用の障壁が下がった
代替候補
- Go：多少の性能より開発速度と保守のしやすさを優先する場合
- C++：既存の大規模資産がある場合、または特定のライブラリが必須の場合
- Zig：Cとの相互運用を重視する場合（ただし仕様が安定していないためAIの支援は弱い）
AIに書かせる際の注意点
- 並行処理や unsafe（安全性の検査を外すRustの機能）をAIが安易に使っていないか確認する
- 性能はAIの主張を信用せず、ベンチマーク（性能測定）で必ず確かめる

用途別の早見表

用途	第一候補	代替候補
Webフロントエンド	TypeScript	サーバー側で画面を作る方式
Webバックエンド、API	TypeScript、Go	Python、Kotlin、Java、C#
データ分析、機械学習	Python	SQL、R
AIを組み込んだアプリ	Python、TypeScript	Go、C#、Java
インフラのコード化	Terraform、TypeScript（AWS CDK）	Python（AWS CDK）
サーバーレス関数	Python、TypeScript、Go	Rust
自動化スクリプト	Python	シェルスクリプト、PowerShell
配布するコマンドラインツール	Go、Rust	Python
モバイルアプリ	Swift、Kotlin	Flutter、React Native
デスクトップアプリ	C#、Tauri	Electron、Swift
企業システム	Java、Kotlin、C#	Go、TypeScript
組み込み機器	C、Rust	C++、MicroPython
ゲーム	C#（Unity）	C++（Unreal Engine）、GDScript
高性能な基盤ソフトウェア	Rust	Go、C++

複数言語を組み合わせる場合の考え方

実際のシステムは1つの言語で完結しないことがほとんどです。AI時代の組み合わせ方には、次の原則があります。

言語の数は最小限にする
AIはどの言語でも書けますが、レビューと障害対応は人間が行います。チームが責任を持てる言語の数が上限です。目安として、主力言語2つとスクリプト用言語1つ程度に収めます。
言語の境界は型付きの仕様でつなぐ
たとえば「フロントエンドはTypeScript、バックエンドはGo」のように分ける場合は、OpenAPIやProtocol Buffers（データ構造の定義形式）でAPIを定義し、そこから両方の言語の型を自動生成します。AIが境界をまたいで食い違ったコードを書くのを防げます。
よくある組み合わせの例
- TypeScriptだけで統一：フロントエンド、バックエンド、インフラ定義（AWS CDK）をすべてTypeScriptで書く。小〜中規模のチームで最も効率が良い
- TypeScript＋Python：画面とAPIはTypeScript、機械学習やデータ処理はPython。AIを組み込んだサービスで定番の構成
- TypeScript＋Go：画面はTypeScript、バックエンドは性能と保守性を重視してGo
- Python＋Rust：処理の大半はPythonで書き、速度が必要な部分だけRustで書いてPythonから呼び出す

迷ったときの判断手順

用途から言語を絞り込むときは、次の順に確認します。

用途やプラットフォームで言語が事実上決まっていないか
ブラウザならTypeScript、iOSならSwift、UnityならC#のように、選択肢がほぼ決まる場合はそれに従う。
既存のコード資産とチームの得意言語は何か
既存資産を活かせる、またはチームがレビューできる言語を優先する。
静的型による検証が効く言語を選べるか
同じ用途で候補が複数あるなら、静的型を持つ言語（または型ヒントを必須にした運用）を選ぶ。
性能や安全性の要件は厳しいか
厳しければRustやGoを検討する。AIの支援により、以前より選びやすくなっている。
AIの知識が追いついているか
新しすぎる言語やフレームワーク、変化の速い分野では、最新ドキュメントをAIに参照させる運用を前提にする。

おわりに：AI時代の言語選定で押さえる3点

「AIが書けるか」より「AIの誤りを機械が捕まえられるか」
AIの生成速度はどの言語でも十分に速くなりました。差が出るのは、静的型、コンパイラ、テスト、フォーマッタといった検証の仕組みです。
書きやすさの重みは下がり、読みやすさと実行特性の重みが上がった
難しい言語の学習コストはAIがかなり肩代わりします。そのぶん、性能、安全性、レビューのしやすさで選ぶ余地が広がりました。
最後に責任を持つのは人間
チームが読めない言語をAIに書かせるのは危険です。「誰がレビューし、誰が障害対応をするのか」は、AI時代でも変わらない最重要の基準です。

この観点から見ると、現時点では TypeScript、Go、Rust、そして型ヒントを付けたPython が、AIと協働する開発の中心になっていくと考えられます。

タグ