ソフトウェアエンジニアリングを改善するためにAIプログラミングエージェントを活用する5つの実践

AIプログラミングエージェントは、単なるコード作成を超えて、ソフトウェアチームがアーキテクチャ上の問題に対処するのを支援できる。ただし、その有用性は、チームが定める目標と制約の明確さに左右される。InfoQに掲載された、Pierre Pureur、Kurt Bittner、Todd Millerが執筆し、Daniel Bryantがレビューしたこの記事は、エージェントに機能要件だけを与えても、スケーラブルで安全、かつ保守しやすいアーキテクチャが保証されるわけではないと警告している。

提案されているアプローチは、パフォーマンス、セキュリティ、スケーラビリティなどの品質属性要件（Quality Attribute Requirements、QARs）と、エージェントが考慮すべきトレードオフの明確化に基づいている。また、エージェントが生成したものを、コードを確認したり推奨事項を信頼したりするだけでなく、明確な測定指標によってテストする必要があると記事は強調している。

1. 依存する前にレガシーサービスを文書化する

現代的なアーキテクチャは、IMSデータベース上に構築されたレガシーシステムから保険証書データを取得するなど、特定の機能を担うレガシーサービスに依存することがある。こうしたサービスには正確な文書が不足している場合があり、データフローの理解や、開発の後期段階または本番環境への移行後に現れる可能性のある論理的・セキュリティ上の欠陥の発見が困難になる。

エージェントはサービスの設計を図示し、データフローを文書化したうえで、コードを調査し、そのサービスが理解しにくく保守しにくい場合には修正やリファクタリングを提案できる。ただし、この利用方法によって、サービスを維持可能か、それともリスクのために置き換える必要があるかという人間によるエンジニアリング上の判断が不要になるわけではない。

2. アーキテクチャ上の欠陥を探す

エージェントに、アーキテクチャ標準からの逸脱、劣化したソフトウェアプラクティス、またはリファクタリングが必要な箇所を見つけるよう指示できる。検査の例には、API設計、複雑、安全でない、または非効率なインターフェース、ドメイン駆動設計（DDD）の境界への違反が含まれる。

記事は、エージェントが多くの改善点を見つけることが多いため、チームは重要な問題と価値の低い提案を区別しなければならないと指摘している。エンジニアが、必要な機能を記述するだけでなく、測定可能な目標、既知の代替案、明確なトレードオフを定めると、結果の品質は向上する。

3. エージェントを隔離してセキュリティ監査を行う

エージェントを使用して、データフローの図示、高リスクファイルの特定、複雑な論理的欠陥の検査、悪用の試みを模倣するテストやスクリプトの作成、発見された問題へのパッチの提案を行える。記事では、セキュリティリスクを表すと分類されたnpmパッケージを対象とした実験を紹介している。そこでは2つのパッケージが更新され、1つのパッケージが置き換えられ、別の1つはアラートが誤検知と判断されたため維持された。

ただし、この利用には明確な運用上の制約が必要である。エージェントのアクセスを承認済みファイルに限定し、データベースのパスワードと秘密情報を隠し、隔離されたネットワークでテストを実行し、変更を統合する前に人間によるレビューを必須にしなければならない。

4. プロトタイプのためのアーキテクチャ基盤を作成する

エージェントの速度によってプロトタイプを迅速に構築できるが、アーキテクチャ上の目標を定めなければ、生成されたプロトタイプは一時的なものとなり、使用に適さない可能性がある。記事は、コード記述方式、データベース設計、インターフェース、推奨するプラットフォームとフレームワークに加え、Markdown形式で記述したQARsを含む、あらかじめ構造化されたアプリケーションを準備することを提案している。

また、GitHubテンプレートを使用してアプリケーションの初期構造を標準化し、チームの標準を最初から組み込むこともできる。エージェントに詳細な解決策をあらかじめ押し付けるのではなく、目標、制約、それらの達成を検証する方法を記述するのが望ましい。

5. テスト可能な初期アーキテクチャを生成する

記事は、エージェントを使ってMinimum Viable Architectures（MVA）を作成することを提案している。MVAは、機能を実証するコードだけでなく、QARsを検証するために必要なテスト、テストデータ、実行環境も含む。エージェントはテストツールやコンテナ設定を生成できるが、チームはテストが実際に必要な属性を測定していることを確認しなければならない。

また、MVAがアーキテクチャ上の変更ケースを受け入れられる能力も評価すべきである。自動生成されたアーキテクチャを拡張することは、進化を想定して設計されていなければ、コストが高くなる可能性がある。

実務上何が変わるのか？

この記事の基本的なメッセージは、プログラミングエージェントによってコードの生産は速くなるが、要件、制約、テストを策定する重要性は高まるということだ。コードを書くスキルがなくなるわけではない。しかし、何を構築すべきか、何を許容可能な品質とみなすか、そしてそれをどのように測定するかの定義は、より慎重に扱う必要がある。したがって、エージェントはアーキテクチャ上の監督下にあるツールとして扱い、エンジニアリング上の判断の代替とみなしてはならない。