9月16日、InfoWorldが「How to keep AI-generated code aligned with your standards」と題した記事を公開した。AIコーディングツールが現場に浸透した今、多くのチームが直面しているのは「速く書けるが、自社の標準に合わない」という問題だ。この記事では、Pegasystemsのプロダクト戦略担当シニアディレクターMatt Healyの見解をもとに、AI生成コードを組織の品質基準に継続的に合わせ続けるための実践的なアプローチが解説されている。
「AIで速く作れる」は本当に問題の解決になっているか
GitHub CopilotやCursorといったAIコーディングアシスタントの普及により、コードの生成速度は劇的に向上した。しかし、Healyはその前提を問い直す。
「CIOたちはAIを使ってアプリを速く作ることを求めているが、多くの組織がすでに気づき始めている——コードが増えるだけでは、自動的にビジネス価値は生まれない」
— Matt Healy（Pegasystems）
速度そのものがボトルネックではない、という指摘だ。コードを書く前に、組織は以下を済ませておかなければならないと記事は強調する。
- ユーザーニーズの把握
- レガシーシステムのアセスメント
- 規制・ベストプラクティスへの準拠の確認
- エンタープライズアーキテクチャと統合の整理
- ビジネスとITの方向性の合致
AIツールはあくまでその後に登場する。この順序を逆にしたまま生成コードを積み上げても、後工程でのレビューコストや手戻りが膨らむだけだ。
なぜ「コンテキストの質」が生成コードの品質を決めるのか
ここで記事の核心となる主張を先に整理しておきたい。AIコードジェネレーターが出力するコードの品質は、入力されるコンテキストの質にほぼ比例する。
コンテキストウィンドウとは、AIモデルが一度に参照できる情報の範囲を指す。GitHub CopilotやCursorのようなツールは、開いているファイル・カーソル位置・コメント・関連ファイルなどをコンテキストとして自動的に取り込むが、組織固有の設計方針・命名規則・パフォーマンス要件・セキュリティ制約といった情報は、開発者が意識的に与えなければ伝わらない。
つまり、いかに高性能なモデルを使っても、渡すコンテキストが薄ければ「動くが、うちのコードではない」という出力になる。これはプロンプトエンジニアリング（AIへの指示設計）の問題であると同時に、要件定義・設計フェーズをどれだけ言語化できているかという組織的な問題でもある。
AI生成コードを「自社標準」に揃えるための3段階
元記事では、コンテキストを構築するためのプロセスを3つのフェーズで整理している。
フェーズ1：実装戦略の合意
ステークホルダーがビジネス価値と意図を定めたあと、開発者はまず実装戦略について合意する。この段階ではパフォーマンス、コスト、スケーラビリティ、セキュリティといったトレードオフを明示的に議論し、文書化しておく。
「とりあえず動くものを作ってからレビューで直す」というアプローチは、AI生成コードの文脈では特に危険だ。AIは与えられた指示に対して最もらしい答えを返すが、組織が暗黙的に持っているアーキテクチャの制約や技術的負債の文脈を自動的に考慮することはない。フェーズ1での合意内容が、後のプロンプト設計の骨格になる。
フェーズ2：ステークホルダーとの再確認
次に、開発者はステークホルダーと再度集まり、実装上のトレードオフを共有してレビューを行う。Healyはこの段階の重要性をこう語る。
「大規模プロジェクトでは、ソリューションと成功指標の定義に、実際の開発と同じくらいの時間がかかることがある。リーダーたちはAIを開発加速だけに使うのではなく、エグゼクティブ、ビジネスアナリスト、プロダクトオーナー、ITチームの間のコラボレーションをより効果的にするためにも活用している」
このフェーズは単なる承認作業ではない。ビジネス側が気づいていない技術的制約、IT側が把握していないビジネス優先度の変化を、コードを書く前にすり合わせる場だ。この議論で出てきたアウトカムが、AIへ渡すコンテキストの精度を直接左右する。
フェーズ3：AIへ渡すコンテキストの構築と継続的な更新
最後のフェーズは、ゴール・ユーザー要件・実装アプローチを開発特化のコンテキストとして整理し、AIコードジェネレーターへ入力する段階だ。
ここで重要なのは、コンテキストに含める情報の範囲だ。記事によれば、機能要件だけでなく以下も明示的に組み込む必要がある。
- データ要件（スキーマ設計、データフローの制約）
- 運用上の考慮事項（ロギング方針、エラーハンドリングの規約、監視要件）
- セキュリティ・コンプライアンス制約（業界規制への準拠、認証方式など）
また、これは一度設定して終わりではない。プロジェクトの進行に伴いコンテキストを継続的に更新し続けることが、生成コードの品質を維持するうえで不可欠だと記事は強調している。実際、GitHub Copilotでは.github/copilot-instructions.mdによるリポジトリ単位のカスタム指示機能が提供されており、組織標準をコンテキストとして恒常的に注入する仕組みとして活用できる。
AIコーディング時代に問われる「設計の言語化力」
GitHub CopilotやCursorの導入が現場レベルで急速に広がる中、「とりあえず動くコードが出てきた」状態で満足してしまうチームが増えている。レビュープロセスや設計指針との整合性が後回しになりがちなのは、多くのエンジニアが実感しているはずだ。
元記事が示す処方箋はシンプルだ。要件定義と設計の議論をAIの外側でしっかり言語化し、その成果物をコンテキストとしてプロンプトに組み込む。この一手間が、後工程のレビューコストと手戻りの量を大きく左右する。
AIが書くコードの品質は、AIの能力だけでは決まらない。それを使うチームの設計力と、設計を言語化する習慣が問われている。
詳細はHow to keep AI-generated code aligned with your standardsを参照していただきたい。
