宣言的AIコーディングのススメ

こんにちは。CTO室の村主です。

Claude Codeを日々使う中で思っていることをGeminiに言語化してもらいました。

Gemini製作物ですので、超最新トレンドを掴んでいなかったり、書き味がイマイチなところも敢えて残していますので、読み物として楽しんでください。

宣言的AIコーディングのススメ

AIがコードを書く時代が本格的に到来しつつあります。しかし、「AIにコードを書かせたけどうまくいかない」「毎回指示の仕方に悩む」といった声も聞かれるのではないでしょうか。その問題の根底には、AIへの「指示の出し方」があるのかもしれません。

この記事では、AIコーディングの効率と品質を劇的に向上させる「宣言的AIコーディング」というアプローチについてご紹介します。

AIコーディングの落とし穴：「命令的指示」の限界

私たちは普段、人間に対して何かを依頼する時、「まずこれをして、次にこうして、もしこの条件ならあれをして、それからこれを返す」といった具合に、手順を細かく指示しがちです。この「どうやるか」を具体的に教えるスタイルは、命令的（Imperative）アプローチと呼ばれます。

AIへのコーディング指示でも、つい同じように「この関数のif-elseをネスト解消して、早期リターンを使って、変数名ももっと分かりやすくして」といった命令を出したくなります。

しかし、ここに落とし穴があります。

AIは人間の意図を完全に理解しているわけではありません。指示の「表面的な言葉」を解釈し、学習データから最も一般的なパターンを生成しようとします。そのため、指示が少しでも曖昧だったり、具体的な手順が欠けていたりすると、

実装のブレ: 毎回異なる結果が生成され、品質にばらつきが出る。
非効率な修正サイクル: 意図と違うコードが生成されるたびに、人間が手動で修正したり、指示を練り直したりする手間が発生する。
隠れたバグ: 「どうやるか」に集中しすぎると、「何を達成すべきか」の定義が曖昧になり、バグや仕様漏れに気づきにくい。

といった問題が生じがちです。「リファクタリングして」という指示では、AIは毎回異なる観点（例：可読性、パフォーマンス、保守性）で適当にコードを変更し、人間が求める結果にならないことも珍しくありません。

救世主となる「宣言的AIコーディング」

では、どうすれば良いのでしょうか？その答えが「宣言的（Declarative）AIコーディング」です。

これは、AIに対して「どうコードを書くか」という手順ではなく、「何を実現したいか」「どのような状態が望ましいか」という結果や制約を「宣言」するアプローチです。プログラミングにおけるSQLやHTML、Reactのコンポーネント定義をイメージすると分かりやすいでしょう。私たちはSQLで「こういうデータが欲しい」と宣言し、HTMLで「ここにこういう要素が欲しい」と宣言します。

AIコーディングにおいても、この「何を達成したいか」という「普遍の定義」を明確にすることで、AIは迷うことなく、その定義を満たすための最適なコードを自律的に生成・探索するようになります。

「普遍の定義」がAIを導く

AIコーディングにおける「普遍の定義」とは、AIが目指すべきゴールや制約を実行可能・検証可能な形で示したものです。プロジェクトの様々な品質観点において、この「普遍の定義」を設定することが、AIの精度と信頼性を高める鍵となります。

1. 運用品質（テスト）の観点

ソフトウェアがリリース後も安定して稼働し続けることを保証します。

普遍の定義:
- ユニットテスト: 「このテストコード（ユニットテスト）をすべてパスする実装を生成してください。」
- カバレッジ率: 「生成するコードは、指定されたカバレッジ目標（例: ユニットテストで90%以上のステートメントカバレッジ）を満たすようにしてください。」
- TDD（テスト駆動開発）: 「まずこの機能のテストコードを記述し、次にそのテストをパスする実装コードを生成してください。」

2. 機能要件の観点

ユーザーやビジネスの要求を正確に満たすことを保証します。

普遍の定義:
- BDD（振る舞い駆動開発）: 「以下のユーザーシナリオ（BDD形式）を満たす機能コードを生成してください。」
- 明確な仕様書/ユーザー要件: 「この仕様書に記載されている要件をすべて満たすように実装してください。」

3. コード品質の観点

コードが理解しやすく、保守しやすく、拡張しやすい状態であることを保証します。

普遍の定義:
- Linter/Formatterの設定: 「生成するコードは、このLinter/Formatterの設定（例: ESLint, Prettier）に準拠するようにしてください。」
- 静的解析ツール（SAST含む）のルール: 「指定された静的解析ツール（例: SonarQube, SASTツール）の品質ゲートをパスするコードを生成してください。」
- コーディング規約ドキュメント: 「このコーディング規約に従ってコードを記述してください。」
- 既存のコードベースのパターン: 「既存のコードベースのスタイルとパターンに沿って、この機能を実装してください。」

4. セキュリティの観点

ソフトウェアが脆弱性を持たず、不正アクセスやデータ漏洩から保護されていることを保証します。

普遍の定義:
- SAST（Static Application Security Testing）ツールのルール: 「SASTツールで検出される脆弱性がないようにコードを記述してください。」
- セキュリティコーディングガイドライン: 「OWASP Top 10の脆弱性がないように、セキュアなコードを生成してください。」
- 認証・認可の仕様: 「この認証・認可の仕様に厳密に従って、ユーザー管理機能を実装してください。」

宣言的AIコーディングのメリット

「宣言的AIコーディング」を採用することで、以下のような大きなメリットが得られます。

コミュニケーション効率の最大化: 人間は「どう書くか」という煩雑な手順を指示する手間から解放され、「何をしたいか」という本質的な要件定義に集中できます。
実装のブレを抑制し、品質を向上: 「普遍の定義」という明確なゴールがあるため、AIが生成するコードは一貫性が保たれ、期待通りの品質に近づきます。
AIの探索能力を最大限に活用: AIは、与えられた「宣言」を満たすために、自身の学習データと推論能力をフル活用し、人間が思いつかないような効率的・最適なコードを生成する可能性も秘めています。
迅速なフィードバックと修正サイクル: 普遍の定義（例：テストの失敗、Linterのエラー）があれば、AIが生成したコードが「不合格」であることが明確になり、即座に修正や再生成を指示できます。仮に初めに生成されるコードが多少ブレていても、この「宣言された定義」に照らして不足している部分が明確になります。AIは、この定義を完全に満たすまで、自律的にコードの修正を繰り返してくれるため、最終的には定義通りの高品質なコードに収斂していきます。