AI駆動開発でプログラム移行してみました ～AIはコーディングをどこまで楽にしてくれる？～

こんにちは、データアナリティクス部のmorishitaです。

最近は「AIで開発効率が何倍になった！」という話をよく見かけます。
一方で、実際の業務で使うとなると、

「セキュリティ面は大丈夫？」
「本当に品質は担保できる？」
「再現性はどう確保する？」
「実際の開発ではどう使えばいい？」

といった疑問も多いのではないでしょうか。

そこで今回は、実際の業務で長年運用されてきたSASプログラム群をAIを用いてPythonに移行できるのか、検証してみました。
ちなみに本記事は、データアナリティクス部のカルチャーである「チームとして成長する」ための活動の一環として発信しています。

カルチャーについては下記の記事で紹介しているので、気になった方は覗いてみてください。

データ分析のプロ集団が大切にしている「カルチャー」についてDA部が日々の業務で大切にしている価値観、「カルチャー」について

テーマはシンプルです。
AIを駆使すると、どこまで開発をラクにできるのか？

今回の開発スタイル

ここで、今回の開発スタイルについて少し整理しておきます。
今回取り組んだのは、広い意味ではAI駆動開発です。

AI駆動開発は、AIを単なる「コードを書くための道具」として使うのではなく、設計、コーディング、テスト、修正など、開発そのものにAIを組み込んでいく考え方です。

その中には、いくつか異なる進め方があります。
たとえば、AIとの対話を繰り返しながら「まず動くものを作ってみる」というスタイルがバイブコーディングです。

一方で、コードを書く前に仕様を明文化し、「この仕様を満たすものを作って」とAIに実装させるのが仕様駆動開発（SDD）です。

ざっくり整理すると、

という関係です。

今回のお題

今回は、臨床データ解析や疫学データ解析向けにオープンソースとして公開されているSASプログラムを検証対象に選びました。
全部で102個のSASマクロがあり、コホート定義や包含・除外条件、妊娠・出産アウトカムなど、医療特有の複雑なロジックが詰め込まれています。
この解析基盤をAIを活用してPythonへ移行してみる、というのが今回のお題です。
これを人間だけでやろうとすると、依存関係の洗い出しからコードの書き換え、等価性検証、ドキュメント作成まで、気が遠くなるような大仕事になります。
もし私がこの作業をAIを使用せずに行うとしたら、SASコードを解析する段階で涙目になりそうですが、今回はAI駆動開発の中でも、AIと対話しながらどんどん作ってみる「バイブコーディング」のスタイルで挑みました。

使用したツール

Gemini Code Assist

Gemini Code Assistは、Googleが提供するAIコーディングアシスタントです。VS CodeなどのIDEに拡張機能として導入でき、コード補完やコード生成、リファクタリング、コードレビューなどを対話形式で支援してくれます。
エディタ上で「この関数を書いて」「この処理をPythonで実装して」といった指示をそのまま実行できるため、日常的な開発を効率化するのに適したツールです。

Gemini CLI

今回メインで使用したのは Gemini CLI です。
Gemini CLIは、ターミナル上で動作するAIエージェントです。単にコードを生成するだけではなく、プロジェクト全体を理解しながらファイル操作やコマンド実行まで行えるのが特徴です。
例えば、

• プロジェクト内の複数ファイルをまとめて解析する
• 関連コードを検索・修正する
• pytestを実行する
• エラー内容を解析して修正する
• Git操作やドキュメント更新を支援する

といった一連の作業を対話形式で進めることができます。
当初はGemini Code Assistを使っていましたが、102個のマクロを一括解析しようとするとコンテキスト上限でフリーズしてしまったため、大量のファイルを一括で扱えるCLI版に切り替えました。

Conductor

Conductorは、AIエージェントによる開発を支援するためのプロジェクト管理フレームワークです。
開発ルールや技術スタック、タスク、仕様などをMarkdownファイルとして管理し、それらをAIが参照することで、プロジェクト全体の状況やルールを理解した状態で開発を進められます。

今回の検証では、

• ▶ プロジェクトの技術スタックやコーディングルールの管理
• ▶ 移行計画や進捗管理
• ▶ レビュー・テスト状況の管理

に利用しました。
複数日にわたって開発を進める場面も多くありましたが、Conductorによってプロジェクト全体の状態をAIと共有できたため、「前回の続きから作業する」「未完了タスクを洗い出す」といった作業をスムーズに進めることができました。
Gemini CLI単体でも開発は可能ですが、Conductorを組み合わせることで、AIが設計方針や進捗を踏まえながら一貫性のある開発を行えるようになり、大規模な移行プロジェクトとの相性の良さを実感しました。

開発の進め方

Conductorを使用し、以下の流れで進めました。

• ① プロジェクト概要の作成
  • /conductor:setup を実行すると、Gemini CLIがディレクトリをスキャンし、プロジェクト概要を推論してくれます。
  • その後は対話形式でプロジェクトに関するヒアリングが行われ、その内容をもとに以下のファイルが自動生成されます。
    • product.md：プロジェクト概要
    • product-guidelines.md：コーディング規約・機能要件
    • tech-stack.md：使用言語やライブラリ
    • workflow.md：標準開発フロー
  • これらを明文化してConductor配下へ配置することで、毎回プロンプトで細かなルールを説明しなくても、一貫した方針で開発を進められるようになります。
• ② 作業単位（トラック）の定義
  • /conductor:newTrack を使用して、トラックを作成します。トラックとは、機能やテーマごとに分けた作業単位です。
  • 各トラックには「何を作るか」「どう進めるか」を定義したファイルが作成され、Conductorはチェックリスト形式で進捗を管理してくれます。
• ③ レビュー
  • /conductor:review を実行すると、プロジェクト全体のステータスや設計基準を評価できます。
  • 各フェーズ終了時にもレビューは実施されますが、プロジェクト全体を通して確認することで、設計方針から逸脱していないかを確認できます。

この②〜③を、すべてのSASコードがPythonへ移行されるまで繰り返しました。

結果は？

• 人間の作業時間：約10時間（会話履歴から算出）
• AI稼働時間：約8時間

結果として、102個のSASマクロすべてを15個のPythonモジュールへと移行し、等価性テストも100%合格させることができました。

もし人手だけで対応していたらどれくらい掛かっていたのでしょうか……100時間？200時間？
概算ですが、人の工数は約90〜95%削減できたと考えてよさそうです。
ただし、今回の評価指標はあくまで「すべてのSASコードがPythonへ移行され、動作すること」です。
業務でそのまま利用できる品質かどうかは別の話なので、その点も含めて実際に使って感じたことを紹介します。

AIを使って感じたこと

一番驚いたのはスピード感です。
たった一行のコマンドを入力するだけで大量のコードを解析し、概要を理解してくれる。数百行のコードを書き上げるのも一瞬です。
デバッグも、人間なら「エラー箇所の特定 → 原因調査 → 修正」という流れになりますが、AIはこれを一気に進めてくれます。このスピード感は人間には再現できない、AIならではの強みだと感じました。

一方で、

• 非効率的なコードやハードコーディング
• ルールに明記していない事項はすぐ忘れる
• ドキュメントの不備
• テストが甘くても通ってしまうケース

など、「AIあるある」も少なくありませんでした。

今回工夫したこと

今回特に効果があったのは次の2つです。

• 指示を明確にする
  • AIは与えられた設計をよく守ってくれますが、与えられていない情報を補完するのは苦手です。
  • 抽象的な指示、いわゆるバイブコーディングだと「なんでそうなる？！」という仕様になりがちで、何度かAIと喧嘩をする羽目になりました（笑）。
  • まだまだ日本語特有の曖昧なニュアンスを完全に理解するのは難しいため、
    • 何を実装するのか
    • どのファイルを対象にするのか
    • 期待する出力は何か

    をできるだけ具体的に伝えるようにしました。

• 定量的な指標を渡す
  • ある日、AIが「Pythonへの移行作業はすべて完了しました！」と報告してきました。どれどれ、と成果物を見てみると……あれ？コード少なくない？
  • 私「SASコードは全部移行できたんだよね？」
    AI「はい！特殊な解析群とレポート作成以外の主要なコードは移行済みです！」
    ……いや、それ「全部」じゃないじゃん（笑）。
  • AIは重要そうな部分を要約・省略する癖があるようで、それが移行漏れの原因でした。
  • そこで「すべて移行した？」ではなく、「移行率は何％？」という定量的な指標で評価するように変更しました。移行率100%になるまで評価と移行を繰り返させることで、漏れを防ぐことができました。

実感したバイブコーディングの限界

AIは非常に便利ですが、万能ではありません。
今回のようなAIに主導権を委ねるやり方では、実務で利用する上で特に注意すべき3つのポイントも見えてきました。

• 仕様・前提環境の事前定義
  • AIは、指示されたその場の文脈だけでコードを生成するため、事前に「コーディングルール」「使用するライブラリと具体的なバージョン」などの前提条件を定めておく必要があります。
• 生成コードの品質とテストの形骸化
  • 「テストの合否」だけを指標にAIを走らせると、「テストは通るけれど、ハードコーディングだらけでAny型が多用されている」という最悪な品質のコードが頻発します。
  • さらに、テストコード自体もAIに任せると、AIは「自分が書いたバグのあるコード」が通るようなガバガバなテストを書いてセルフパスさせてしまいます。
  • 自動生成されたコードはそのままにせず、必ず「人間によるコードレビュー」を挟むことが不可欠です。
• OS・Git操作権限の付与に伴うリスク
  • Gemini CLIのような強力なエージェントは、人間からの指示を達成するためにOSコマンドやGit操作、ファイル削除などを自律的に実行できます。これは便利である反面、一歩間違えれば取り返しのつかないミスを引き起こす危険な刃です。
  • 実際、他社の類似AIエージェントツールにおいて、「再帰的な探索ロジックのループや誤った指示により、ローカルワークスペースのファイルを全削除してしまう事件」がコミュニティで報告されています。
  • ディレクトリ移動やファイル書き換えを伴うOSコマンドを実行する際は、必ず事前に人間がコマンドの内容を確認・承認するプロトコルを挟むことが重要です。

結論：実務で行うなら「仕様駆動開発」が望ましい

今回の検証を経て強く感じたのは、仕様を定義せずに何を作るかの判断や進め方までAIへ委ねる（いわゆるバイブコーディングのような）開発にはリスクがあるということです。
実務で安全に品質と生産性を担保するためには、AIを活用しながらも、人間が定義した仕様を主軸に置く「仕様駆動開発」のアプローチが適していると感じました。

まとめ

AIエージェントの使い心地は、想像以上に良いものでした。
今回のような移行案件では、最も工数が掛かる既存コードの解析や実装を数時間でこなしてしまうのは、本当に強力だと感じます。
だからこそ、実務においては感覚任せに開発を進めるのではなく、人間が教官となって『仕様』という指示を明確に出し、AIを適切にコントロールしていく必要があると思いました。

これからの開発では、
人間は設計・レビュー・ガバナンスを担当し、AIが実装を高速で回す。
そんな役割分担が、現時点では最も現実的で強力な開発スタイルなのではないでしょうか。

今回の検証を通して、「AIを使うと楽になる」ということ以上に、
「AIをどう使えば、安全に生産性を最大化できるのか」
という視点の重要性を実感できた、とても面白い取り組みでした。