AIエージェントを利用した仕様駆動開発

はじめに

データアナリティクス部（以下、DA部）の柏木です。昨今、IT業界ではClaude CodeやGitHub Copilotなど生成AIを活用したコーディングが活発になっています。そこで、有志でメンバーを募り、Sentinel Analytic Packagesという医療データ解析プログラムのSASからPythonへのコード移行を通してAIの業務活用を検討する、というプロジェクトを行いました。

このプロジェクトにおいて、移行作業は仕様駆動開発に基づいて実施しました。仕様駆動開発とは、開発前に仕様書を作成しその仕様書に沿って開発を行っていく手法のことで、AIエージェントが事前に作成した仕様書の通り作業を進めるため、手戻りが少なく、仕様書と実装内容を照らし合わせてレビューが行いやすいといった利点があります。

本記事では、仕様駆動開発に基づいて移行作業を実施していく中で感じた難しさや利便性を共有したいと思います。
本プロジェクトはこちらの記事でも紹介している「20%ルール」を利用して実施したプロジェクトになります。DA部のカルチャーである「能動的に挑戦する」に即して新しい技術を試すプロジェクトになっています。

Pythonコードの実装まで

今回の移行対象となったプログラムは、患者の分類や傾向スコアマッチングといった機能ごとに、約50本のSASマクロ（関数に相当するモジュール）で構成されていました。 そこで本プロジェクトでは、AIエージェントを活用して以下の一連のプロセスを自動化し、全50本のプログラムに対して適用しました。

1. 既存のSASコードの解析
2. 仕様書の自動生成
3. Pythonコードへの移行（実装）
4. 単体テストの生成と実施

移行を始めた当初は、なかなか思うように作業が進みませんでした。まず、AIエージェントに全てのSASプログラムを読み込み仕様書を作成するよう指示したのですが、勝手にプログラムをスキップして網羅的に仕様書が作成されませんでした。そこで、仕様書を作成する前にSASプログラムの一覧表を作成し、仕様書が作成済みかどうかを表で管理することで漏れなく仕様書を作成し、Pythonプログラムへ移行することができました。

また、プログラムの一覧表を作成する際にプログラム同士の依存関係も調べることで、プログラム全体の構造を素早く把握することができました。プログラム全体の構造を把握するという点は実業務でも非常に役立つと感じました。

品質保証と今後の課題

ひとまずPythonコードを実装はできましたが、品質保証に関しては課題を感じています。今回のプロジェクトでは仕様書の作成から単体テストの実装までAIに実行させているため、

1. 仕様書が正確に書かれているか
2. 仕様書の内容について実装漏れがないか
3. 単体テストの内容に問題はないか

といったレビューを行う必要があります。特に、仕様駆動開発では仕様書の内容がそのまま実装されるコードの品質に直結するため、曖昧な仕様や矛盾がないよう厳密かつ正確な仕様書になるようレビューしなければなりませんが、このレビューの負荷がかなり高いと感じました。今回、時間が足りず仕様書とコードのレビューはあまりできていないのですが、簡単な例を紹介したいと思います。

DeathDt=Coalesce(DDate,ADate); #移行元SASコード

df_enc_death["DeathDt"] = df_enc_death["DDate"].combine_first(df_enc_death["ADate"]) #移行後Pythonコード

上記のSASのコードに対する仕様書の内容は、「死亡日 (DeathDt) は DDate があればそれを使用し、なければ ADate を使用する (Coalesce)。」となっています。この場合、DDateとADateのどちらも欠損の場合どうするかという内容が仕様書に書かれていないことになります。Coalesce関数の使用上、引数が全て欠損なら欠損を返すのですが、ドキュメントとして正確を期すのであれば「死亡日 (DeathDt) は DDate があればそれを使用し、なければADateを使用する。どちらも欠損の場合は欠損とする。」とすべきでしょう。もちろん、かっこ書きではあるもののSASコードでCoalesce関数が使用されていることは記載されており、死亡日に使用する値が欠損なら死亡日も欠損（=生存している）と推測することは容易だと思います。

しかし、人間にとって容易に推測できることがAIにとって容易とは限らないため、内容を推測しなければいけない仕様書というのは不完全だと思います。このように、重箱の隅をつつくようなレビューは人間も見落としがちですし、人によってどこまで修正が必要か意見が分かれることも多いと思います。実際、上記の例で移行後はcombine_firstを使用しており挙動としてはSASのCoalesce関数と同じになります。しかし、結果として正しく実装されることと仕様書が厳密に記載されていることは別の話だと私は考えています。

例示したような簡単な処理ですら、その内容を正確に仕様書に起こすことは難しく、処理そのものが難解な場合は尚更です。さらに、負荷の高い仕様書のレビューが終わった後に待っているのは実装されたコードのレビューです。仕様書のレビュー後であり、質の高い仕様書から作成されたコードのためまだ多少負荷は軽いと思いますが、AIによって高速・大量に作られたコードのレビューはなかなかに骨が折れるでしょう。

解決策のアイデア

上記の課題に対して、実務で仕様駆動開発を利用するためのアプローチを3つ考えてきたので紹介したいと思います。

アイデア１：テストコードで設計書を補完する

自然言語の仕様書でコードを完璧に記述することは諦め、テスト設計にリソースを割きコードの品質を担保するアプローチです。現実的な解決策である一方、それはもはや仕様駆動開発ではないのでは？という感じがします。

アイデア２：AI同士の「相互レビュー」を活用する

コードを書くAIとは別に、厳しいレビュアー役のAIを用意し、仕様書の抜け漏れを指摘させるアプローチです。この手法の場合、レビューの質をコントロールするのが難しい点と、実装とレビューがどちらもAIである点がネックになりそうです。

アイデア３：データの比較でコードの品質を保証する

移行などで正解となる既存データが存在する場合に、そのデータと同じデータが作られることを確認しコードの品質を保証するアプローチです。使える場面が限定的かつ、例外処理など必ずしも網羅的に確認できるわけではない点はネックですが、顧客と合意できるなら現実的な解決策かと思います。

おわりに

仕様駆動開発を利用しても品質保証がネックになる一方で、既存データとの比較でコードの品質がある程度担保できる移行作業は、業務適用へのハードルは低いと考えています。また、仕様駆動開発に関しては、コード実装のための仕様書にどこまでリソースを使うかのバランスが難しいと感じました。