AIがコードを書く時代に、なぜ「お気に入りの言語」を持つのか
AIでコードを生成し、実装の細部を一行ずつ追わなくても開発を前へ進められる場面が増えた。そうであれば、プログラミング言語へのこだわりは薄れていくのだろうか。
私は最近、むしろ逆なのではないかと考え始めた。
AIがコードを書く今だからこそ、自分の思考や品質感覚の基準点になる「お気に入りの言語」を持つ意味がある。そして組織にとっても、言語選択の重要性が消えるのではなく、選ぶ理由が変わっていくのではないか。
なお、私はGo言語の専門家ではない。複数言語を同じ条件で比較したわけでもなく、本稿はGoの優位性を主張する記事ではない。GoとAI駆動開発についての記事を読んだことをきっかけに、言語選択を考える軸が変わった、という実務家としての仮説を整理する。
別言語の採用は、組織にとって大きな決断だった
ほんの数年前まで、新しいプログラミング言語を導入しようとすれば、まず学習コストが問題になった。
チームメンバーが文法や標準ライブラリを覚えるまで、生産性が下がる。レビューできる人が限られる。採用や引き継ぎが難しくなる。既存のCI/CD、監視、クラウド基盤に載せられるかも確認しなければならない。
そのため、別言語の採用は単なる技術上の好みではなく、組織としての大きな決断だった。言語やエコシステムに魅力があっても、「いま使っている言語で実現できるなら変えない」という判断には合理性があった。
この事情をAIが部分的に変えつつある。
未知の文法の説明、APIの使用例、既存コードからの変換、テストの生成、コンパイルエラーの修正を、AIが支援できる。新しい言語で最初の動くコードへ到達するまでの距離は、以前より短くなった。
ただし、言語導入のコストがなくなったわけではない。コストの重心が、「人間が書き方を覚えること」から、「生成物を検証し、本番で運用し、問題が起きたときに答えられること」へ移っている。
コードを読まないなら、言語の制約がもっと重要になる
AIが大量のコードを書く環境では、プログラミング言語は人間が実装するための表現手段だけではない。AIの出力を制約し、誤りを機械へ返すための装置にもなる。
型検査、コンパイラ、フォーマッタ、静的解析、テストランナーが明確なフィードバックを返せれば、AIは「生成する→検査する→修正する」というループを回しやすい。人間も、すべての行を目視する代わりに、どの制約を通過したか、どのテストで振る舞いを確認したかを判断材料にできる。
これは、人間がコードを理解しなくてよいという意味ではない。理解の単位が、一行ごとの著作から、構造・振る舞い・失敗条件・採否へ移るということである。
コードの詳細を常に追わないのであれば、言語とツールチェーンが何を自動的に拒否し、何を見逃すかを知る必要は、むしろ大きくなる。
Goの記事が、言語を見る軸を変えた
きっかけは、GoのプロダクトマネージャであるCameron Balahanと、Google CloudのRichard Seroterが2026年8月に公開した「Why Go is an Ideal Language for AI-Assisted Software Engineering」だった。
記事は変化を、次の小見出しで表現している。
“From Writing to Reviewing”
人間が手でコードを書く速さより、AIが生成したコードをレビューし、検証し、保守する能力が重要になる、という主張である。そのうえで記事は、Goの価値を文法の簡潔さだけに置かない。統一的な書式、テスト、依存関係管理、セキュリティ検査を標準ツールチェーンから利用できること、予測しやすいコードの形、互換性と長期保守性を、一つのソフトウェアエンジニアリング基盤として論じている。
特に印象に残ったのは、AIを単なるコード生成器ではなく、監督と制約を必要とする新しいチームメンバーとして捉えている点だった。コードの表現が揃い、コンパイラやテストが明確な結果を返せれば、AIは生成と自己修正を反復しやすく、人間は意図や異常を確認しやすくなる。私が言語を見る軸を考え直したのは、この「言語そのもの」から「人間とAIが共同作業するためのプラットフォーム」への視点の移動である。
Goには、コードを標準形式へ整える gofmt、パッケージ単位でテストを実行する go test、疑わしい構造を検査する go vet など、公式ツールチェーンの中に共通の入口がある。公式サイトも、主要クラウド事業者がGo向けAPIを提供していると案内している（Go command documentation、Add a test、Go for Cloud & Network Services）。
もっとも、これはGoの開発責任者らによる公式ブログ上の提案であり、複数言語を同条件で比較した独立評価ではない。記事中の強い優位性主張を、そのまま私自身の結論にはできない。私も「Goを採用すべきだ」と判断できるほどGoに習熟していない。ただし、そこで挙げられた性質は、AIとの開発ループを評価する観点の候補にはなる。
- 書き方の自由度を機械がどこまで整えてくれるか
- コンパイルやテストの結果を、修正可能な形で返せるか
- 標準的な進め方が共有され、AIと人間の判断が分岐しにくいか
- 依存関係、実行環境、クラウドサービスとの接続を管理できるか
- 障害時に、人間が調査と復旧を引き受けられるか
これからの言語選択では、「チームがすでに書けるか」に加えて、「AIの出力をどの程度、機械的かつ運用可能な形で検証できるか」が重要になるのではないか。
「お気に入りの言語」は、判断の基準点になる
では、AIが複数の言語でコードを書けるなら、人間は特定の言語を深く学ばなくてもよいのだろうか。
私は、少なくとも一つは深く付き合う言語を持ったほうがよいのではないかと思う。
お気に入りの言語は、単なる嗜好ではない。設計の良し悪し、読みやすさ、例外処理、テスト可能性、抽象化の程度を判断するための基準点になる。一つの言語と深く付き合って得た感覚があれば、AIが別の言語で提示した設計についても、「なぜこの構造なのか」「どこで失敗するのか」を問いやすい。
AIが学習摩擦を減らしてくれるからこそ、どこかには意図的に摩擦を残す必要もある。すべてをAIに説明・生成・修正させていると、異常を感じ取るための物差しまで育たない可能性がある。お気に入りの言語を持つことは、自分が引き受けて理解する領域を一つ確保することでもある。
ただし、個人のお気に入りを、そのまま組織の標準にしてよいわけではない。組織の採用判断では、対象領域、既存資産、運用体制、人材市場、依存ライブラリ、セキュリティ、クラウドの対応を検討する必要がある。個人の「好き」は探究の入口になりうるが、採用の根拠は別に示さなければならない。
これまでの研究と、言語選択の接点
私はこれまで、AIに認知作業を任せることを、単なる効率化ではなく、外部化と人間の責任の再配置として考えてきた。
『AIによる認知スキャフォールディングとアイデア発散傾向の構造化』では、低い層の認知負荷をAIへ外部化しながら、主張の強さや採否を人間に残す実践を扱った。
『地頭至上主義の系譜と認知資源の多元主義』では、頭の中だけで処理したか、外部資源を使ったかによって成果の正当性を決めるのではなく、外部資源を検証し、統合し、その使用に責任を持てるかが重要だと論じた。
続く『答え責任と外部化の線引き：AI協働における認知作業の委譲原理』では、AIへ外部化できる範囲を、人間が成果の根拠を示し、誤りを検出・訂正し、採否を決定できる範囲として整理した。
この枠組みで考えると、AI時代の言語選択も「AIがコードを書けるか」だけでは決まらない。
人間がその成果について答えられるように、言語とエコシステムが検証の足場を提供できるか。AIが生成したコードを、型、テスト、静的解析、実行証跡へ落とせるか。そして、ゲートが通ったという事実を、人間が理解して採用できるか。
プログラミング言語は、生成対象であると同時に、答え責任を支える設計資源になる。
言語の乗り換えは軽くなっても、採用判断は軽くならない
AIによって、新しい言語を試す費用は下がる。小さなサービスや検証環境であれば、以前より気軽に比較できるだろう。複数言語で同じ仕様を実装させ、テスト、可読性、運用、クラウド対応を比べることもできる。
その意味では、「別言語の採用＝後戻りできない大決断」という感覚は弱まるかもしれない。
しかし、試しやすくなることと、本番採用の責任が軽くなることは同じではない。AIが移植を手伝ってくれても、障害対応、長期保守、依存関係、セキュリティ、撤退可能性への答えは必要である。
これから必要なのは、言語にこだわらないことではない。好みだけにも、過去の慣性だけにも閉じず、AIと人間が検証可能な形で仕事を進められる言語を選ぶことだと思う。
私はまだ、Goが自分のお気に入りの言語になるかどうかを知らない。だからこそ、専門家のように結論を語るのではなく、実際に小さな題材を作り、AIとの生成・検査・修正ループがどう変わるかを確かめてみたい。
AI時代の言語は、人間がコードを書くためだけでなく、AIが書くコードを制約し、人間がその結果に答えるために選ぶものになるのかもしれない。