← Back to Blog
Journal

どの言語・どの設計がAIフレンドリーか――型・局所性・検証ループで読み解く

· Yuki Tachi
AIClaude Code型システムソフトウェア設計RustTypeScript

はじめに

Claude Codeのようなコーディングエージェントを日常的に使うようになると、「AIに優しいコード」という言葉をよく聞くようになります。しかしそれは具体的に何を指すのでしょうか。読みやすい命名、適切なコメント――人間にとっての「良いコード」と同じものなのでしょうか。

本記事では、AIフレンドリーさを漠然とした感覚ではなく、言語選択と設計パラダイムのレベルで捉え直します。結論を先に述べると、エージェント的開発で効くのは「意図が局所的に復元でき、機械が正しさを即座に検証できる」という二つの性質です。前半で定義を整理し、後半で「どの言語・どの設計が特に有利か」を、公式ドキュメントと研究を手がかりに掘り下げます。本テーマは技術トピックのため、論文に加えて公式ドキュメント・一次資料を中心に裏付けます。

背景・課題

エージェントが書くコードは、人間が一行ずつ考えて書くコードとは生成のされ方が違います。大規模言語モデル(LLM)はコードを「トークンの統計的なパターン」として生成しており、型規則のような言語の形式的な側面を内部で厳密にモデル化しているわけではありません(Du et al., 2025)。Du らはこれを「意味のギャップ(semantic gap)」と呼び、生成を統計的なパターンマッチングから正しさを保証できるプロセスへ引き上げるには、構造化された表現・形式的な保証・検証機構といったプログラミング言語側の技術を組み込む必要があると論じています(Du et al., 2025)。

この性質は、実際の数字にも表れます。Mündler らは、生成時に型規則を強制する「型制約デコーディング(type-constrained decoding)」を導入すると、コンパイルエラーを半分以上削減でき、コード合成・翻訳・修復のいずれのタスクでも機能的な正しさが向上したと報告しています(Mündler et al., 2025)。裏を返せば、何も制約しなければLLMはコンパイルすら通らないコードを相当数生み出すということです。

ここで重要なのは、エージェントは一度書いて終わりではない点です。エージェントは「変更する→検証する→失敗理由を読む→修正する」というループを回します。だとすれば、AIフレンドリーさを決めるのは、コードの見た目の美しさよりも、このループに乗せたときの信号の質だと言えます。以下では、この観点を①静的な明示性と②動的な検証可能性の二軸に分けて整理します。

本論

言語軸：型システムは「ハルシネーションの地面」になる

まず言語の選択です。型システムの強さは、AIにとって「踏み外したらすぐ分かる地面」として機能します。静的型付け言語(TypeScript、Rust、Go、Kotlinなど)では、コンパイラや型チェッカが、引数の取り違え・存在しないプロパティへのアクセス・null の混入といった誤りを、実行前に明確なエラーとして返します。前掲の型制約の研究が示すように、型情報はLLMの出力を正しさへ引き戻す手すりになります(Mündler et al., 2025)。コンパイラが即座に、かつ明確なエラーを返す言語ほど、検証ループは締まります。

その極北がRustです。Rustは所有権(ownership)と借用(borrowing)に基づく型システムで、メモリ安全性と並行安全性をコンパイル時に保証します(The Rust Project Developers, 2026)。LLMは熟練した開発者のように正しさを推論しているわけではありませんが、コンパイラが大きな誤りのクラスを機械的に弾いてくれるなら、「コンパイルが通れば一定の正しさが保証される」状態に近づきます。一方で、これはトレードオフでもあります。筆者の見立てでは、Rustの所有権はLLMにとって学習データ上の難所であり、借用規則の違反はLLM生成Rustのコンパイルエラーの大きな割合を占めるはずです。学習データの量とエコシステムの成熟度という観点では、TypeScriptやPythonのほうが「最初から通りやすい」場面も多く、言語の優劣を一概に決めることはできません。型の強さと「LLMが慣れているか」は別の軸だからです。

動的型付け言語であっても、検証ループを締める手はあります。Pythonは型ヒント(type hints)を後付けでき(PEP 484)、mypy のような静的チェッカが、プログラムを実行せずに型に起因するバグを見つけます(mypy, 2026)。漸進的型付け(gradual typing)により既存コードへ少しずつ注釈を足していけるため、動的型の柔軟さを保ちつつ、エージェントに返す失敗信号を増やせます。「動的型だからAIに不利」ではなく、「明確な失敗信号をどれだけ用意できるか」が本質です。

設計軸：局所性が高いほどAIは正しく辿れる

言語が同じでも、設計次第でAIフレンドリーさは大きく変わります。鍵は局所性(locality)です。小さく合成可能な単位、明示的なデータフロー、副作用の局所化、明示的な import と依存関係――これらは、変更しようとする箇所の意図を、その近傍だけ読めば復元できる状態を作ります。

逆に、継承の深い階層、実行時の動的ディスパッチ、重いメタプログラミングは、AIが静的に辿りにくい構造です。人間のベテランはフレームワークのイディオムを経験で知っているため「ここは裏でこう呼ばれる」と補完できますが、AIにとって明示されていない経路は曖昧さとして積み上がります。Du らが「構造化されたプログラム表現」を重視するのも、生成と検証の双方で、コードの意味を辿れることが効くからです(Du et al., 2025)。

筆者の経験でも、フレームワークレスで暗黙の規約に頼ったレガシーPHPは、エージェントが最も苦手とする部類でした。どの関数がどこから呼ばれるかがコード上に書かれておらず、AIは推測で埋めようとして外します。対照的に、TypeScriptとNext.jsで型と依存を明示したコードベースでは、同じエージェントでも修正の精度が目に見えて上がりました。これはあくまで一例ですが、局所性と明示性が信号の質を左右するという主張とは整合します。

検証可能性を設計に組み込む

三つ目は、言語非依存でありながら最も効く層――検証可能性そのものを設計に組み込むことです。具体的には、(1) テストを「実行可能な仕様書」として置く、(2) 型チェッカ・リンタ・フォーマッタをローカルとCIで即座に回す、(3) Docker などで再現性のあるビルドを用意する、の三つです。

Anthropic の公式ベストプラクティスは、第一原則として「Claudeに自分の作業を検証する手段を与える」ことを挙げ、検証手段がなければ「完了したように見える」ことが唯一の信号になり、人間自身が検証ループになってしまうと警告しています(Anthropic, 2026)。テストやビルドという合否を返す仕組みこそが、エージェントの自己修正を駆動します。

ただし、テストを置けば安心というわけではありません。Hora と Robbes は120万件超のコミットを分析し、エージェントが生成するテストはモックを過剰に使う傾向があると報告しています。エージェントによるコミットの36%がテストにモックを追加していたのに対し、非エージェントでは26%でした(Hora & Robbes, 2026)。過剰なモックは、実際のシステム間のやり取りを検証する力が弱く、「通っているのに守れていない」テストを生みかねません。検証の仕組みは、置くだけでなく、その質を人間が見張る必要があります。

実践への応用・考察

ここまでを踏まえると、AIフレンドリーな設計の多くは、実は「良いコード」一般の原則と重なります。局所性、明示的な依存、自動テスト――どれも人間にとっても読みやすく、保守しやすいコードの条件です。

そのうえで、固有のズレが二点あります。第一に、AIはベテランの人間より、少し冗長なくらいの明示性を好みます。人間なら文脈から補える省略も、AIには明示したほうが外しません。第二に、人間にとって「賢い」凝縮――イディオム的な省略や重いメタプログラミング――は、AIには人間以上に不利に働きます。人間は学習でイディオムを知っていますが、AIにとっては曖昧さが増えるだけになりやすいからです。

では、すでに不利な設計のコードベースはどうするか。言語や設計を一夜で変えることはできませんが、検証可能性は後付けできます。筆者は、フレームワークレスのレガシーPHPに対して、CLAUDE.md にコードから読み取れない規約を書き出し、PHPStan の baseline で型エラーの増加だけを監視し、lint をフックで強制し、現状の振る舞いを固定する特性化テストを足す、という形で「AIが正しさを検証できる地面」を後から敷きました。言語の型が弱くても、検証ループの信号は設計と運用で底上げできます。これは Du らの「形式的な保証と検証機構を組み込む」という主張(Du et al., 2025)を、レガシーの現場で実装する試みとも言えます。

まとめ

  • AIフレンドリーさは二軸で捉えられる――静的な明示性(局所性・型・命名・一貫性)と、動的な検証可能性(速いテスト・明確なエラー・再現性のあるビルド)。
  • 型システムはLLM出力を正しさへ引き戻す地面になる。型制約で生成時のコンパイルエラーは半減する(Mündler et al., 2025)。Rustは保証が強い一方、学習データ上は難所でもある。
  • 局所性の高い設計(小さな単位・明示的な依存)はAIが辿りやすく、深い継承や重いメタプログラミングは不利。
  • 検証可能性を設計に組み込むことが最も効くが、テストの「質」は人間が見張る必要がある(Hora & Robbes, 2026)。
  • 言語や設計を変えられなくても、検証ループの信号は後付けできる。

次に触るコードベースでは、「このリポジトリは、エージェントが変更の正しさをどれだけ速く・明確に検証できるか」という一点を測ってみてください。AIフレンドリーさは、最終的にこの検証信号の質に収束します。

参考文献

学術論文

  • Du, Y., Wang, C., & Wang, H. (2025). Position Paper: Programming Language Techniques for Bridging LLM Code Generation Semantic Gaps. arXiv:2507.09135. 2026年6月閲覧. https://arxiv.org/abs/2507.09135
  • Hora, A., & Robbes, R. (2026). Are Coding Agents Generating Over-Mocked Tests? An Empirical Study. Proceedings of the 23rd International Conference on Mining Software Repositories (MSR 2026). arXiv:2602.00409. 2026年6月閲覧. https://arxiv.org/abs/2602.00409
  • Mündler, N., He, J., Wang, H., Sen, K., Song, D., & Vechev, M. (2025). Type-Constrained Code Generation with Language Models. arXiv:2504.09246. 2026年6月閲覧. https://arxiv.org/abs/2504.09246

公式ドキュメント

← Back to Blog