VBAで書かれたテスト作成支援ツールのWeb化 ― Claude Codeを活用した取り組み

Mr.APRESIA
2026/03/30 9:00
その他

はじめに

当社では、テストシナリオをExcelで作成すると自動テストを実行できるテスト作成支援ツールをVBAマクロで開発・運用しています（約16,000行）。Excel+VBAからWebブラウザ上で操作できる環境への移行を目指していましたが、工数の確保が難しく5年間実現できずにいました。それが、Claude Code（Anthropicが提供する生成AIベースの開発支援ツール）を活用することで、8日間でPython+Reactへの移植の試作を完了させることができました。

この取り組みでは、もう一つ確認したいことがありました。生成AIがいかに優れていても、正解データなしに最初から正確なコードを生成することは難しいのではないか、という予想です。本稿では移植の進め方を紹介するとともに、正解データの有無による品質の観察結果と、生成AIとの協働で得られた教訓、また残された課題と今後の改善方針について共有します。

なお、今回の取り組みではAgentic Engineering、SDD（仕様駆動開発）、TDD（テスト駆動開発）の考え方を取り入れており、第4章でそれぞれの位置づけを整理します。

1. 背景: ビジネス課題 ― Excel+VBAで構築したシステムのWeb化

対象は、5年前にVBAで作成したテスト作成支援ツール「E2F（Excel2Feature）」です。E2Fは、プログラム経験が限定的なテストエンジニアでもテスト自動化に参加できるよう開発したツールです。Excel上で、実行したいテスト内容を独自のDSL（ドメイン固有言語）にて記述すると、本ツールによって、テスト自動化フレームワーク用のテストスクリプト（Featureファイル）とテスト環境設定ファイルに自動変換することが可能です（E2Fの詳細はこちら）。

本ツールの開発当初からWeb化の構想がありましたが、工数と人材の確保に課題があり、断念していました。というのも、ツールのWeb化のためには、VBA解析、Python、React、さらにネットワークテスト自動化のドメイン知識が必要であり、人材の採用からドメイン知識の学習だけでも、1年近くかかると見込んでいたためです。

また、本ツールのVBAによる変換処理に数十秒から3分弱要しており、処理速度の高速化もWeb化の重要な課題の一つでした。

こうした状況の中で、生成AIを活用すれば少人数・短期間でWeb化を実現できるのではないかと考え、今回試作に踏み切りました。開発環境はAnthropicのTeamプラン（上位モデルを利用可能なpremiumシート1席、モデル: Claude Opus 4.6）を使用し、基本的に筆者一人とClaude Codeで作業を進めました。

参考までに、以下に、今回の試作で作成したWeb化したE2Fの操作画面の例を掲載します。

テスト記述

E2F-Web-DSL

ポート構成などのエイリアス情報

E2F-Web-env

生成されたFeatureファイル

E2F-Web-Feature

2. 背景: 検証目的 ― 正解データの有無は品質を変えるか

ビジネス課題の解決に加えて、もう一つ確認したいことがありました。生成AIがいかに優れていても、正解データなしに最初から正確なコードを生成することは難しいのではないか、という予想です。

既存VBAの移植には、7,593件のDSL入力→期待出力ペア（リグレッションテストデータ）と設計仕様書（約190シート）が存在します。生成AIにとって「何を作るか」も「正しく作れたか」も明確に定義された条件です。この条件下で、生成AIがどの程度の品質を達成できるかを確認しました。

一方、将来的には生成AIにテストスクリプトを生成させる使い方も考えていました。その生成結果が妥当かどうかを検証するには、テストスクリプトからテスト記述（DSL）に戻す逆変換が必要です。この逆変換は既存VBAに対応する実装がなく、テスト項目書も存在しません。品質は往復テスト（下図）で事後的に確認するしかありませんでした。

往復テスト

この2つの状況―正解データが潤沢にある移植と、正解データのない新機能開発―を同一プロジェクト内で進めることで、それぞれの品質を観察しました。

3. アーキテクチャ ― 16,000行の分析と移植対象の選別

16,000行の分析

移植にあたり、まずVBA全体の構造を把握する必要がありました。全52モジュール・約16,000行をClaude Codeに読ませて分析した結果、2つのパイプラインが存在することが分かりました。バッチ変換（DSLからテストスクリプトへの一括変換）とGUI入力支援（Excel上でのセル編集補助）です。これらに加え、フォームUIやユーティリティを含むVBAスクリプトの内訳は以下の通りです。

カテゴリ	行数	割合	機能
バッチ変換	約4,700行	29%	DSL→テストスクリプト一括変換（移植対象）
GUI入力支援	約6,100行	38%	セル編集UI補助（将来対応）
フォーム/シートUI	約3,000行	19%	Excelダイアログ等（Web UIで置換）
ユーティリティ	約2,400行	14%	デバッグ等（一部移植）

バッチ変換パイプラインのコア約4,700行と、ユーティリティからテスト環境設定ファイル出力等の約600行、合わせて約5,300行を移植対象としました（以降、移植後のPython実装を「コア変換エンジン」と呼びます）。残り約10,800行（67%）は移植対象外としました。

Claude Codeによって、短期間で全モジュールを分析し、パイプライン構造を特定し、モジュール間の依存関係から移植に必要な最小セットを導出することができました。この「全体を読んで移植対象を絞り込む」分析工程自体がClaude Codeとの協働の成果です。

コア機能のリストアップ

次に、移植対象のコードからClaude Codeの分析によって36個のコア機能をリストアップし、難易度を3段階に分類しました。簡単なものから順に着手する方針とし、優先順位を決定しました。

設計方針: コア処理とインターフェイスの分離

もう一つの設計判断として、Excel側のインターフェイスとコア処理を分離しました。Web化を見据えていたのはもちろんですが、コア処理をExcelに依存しない形にすることで、将来的にどのような入力ソースにも対応できる汎用性を確保する狙いがありました。

アーキテクチャ

フェーズ設計

上記を踏まえ、移植作業全体を8フェーズに分割しました。

フェーズ	作業対象
1-5	コア変換エンジン（36機能を難易度順に移植）
6-7	Interface層分離 + テスト環境設定ファイル生成
8	Web UI（FastAPI+React）
8.5	逆変換（新機能、VBAに対応なし）

4. 開発手法 ― AI方法論における本取り組みの位置づけ

本プロジェクトでは、生成AIに実装を任せつつ、仕様書とテストデータという2つのガードレールで品質を担保し、人間はPL（プロジェクトリーダー）として意思決定に集中しました。

本プロジェクトの位置づけ

Agentic Engineering

生成AIにコードを書かせる開発スタイルは「Vibe Coding」と呼ばれ、AIの出力をそのまま受け入れる手軽さで注目されました。一方、2026年2月にAndrej Karpathyが提唱した「Agentic Engineering」は、生成AIに実装を委ねつつも、人間がアーキテクト・レビュアー・意思決定者として振る舞うスタイルです。本プロジェクトはこのAgentic Engineeringに近い進め方をしています。

SDD（仕様駆動開発）

SDD（Specification-Driven Development）は、仕様書をAIへのインプットとして開発を駆動する手法です。今回は新たに仕様書をゼロから作成したのではなく、既存の外部仕様書・詳細設計書をそのままAIへのインプットとして活用しました。

TDD（テスト駆動開発）

厳密なRed-Green-Refactorサイクルではありませんが、7,593件のリグレッションテストデータが「この移植は正しいか？」の判断基準として常に機能しました。生成AIが出力したコードをテストデータと照合することで、品質を段階的に確認できました。

5. 進め方 ― コンテキスト管理と軌道修正

2層メモリモデル

8日間・約120コミットにわたるプロジェクトでは、生成AIに与えられる情報量の管理が重要な課題でした。生成AIが一度に参照できる情報量（コンテキストウィンドウ）には上限があり、プロジェクトが大きくなるほど「何を覚えさせておくか」の取捨選択が必要になります。Claude Codeには、プロジェクトの指示書にあたる CLAUDE.md と、セッション間の引き継ぎメモにあたる MEMORY.md という2つのファイルがあります。この2つを2層構造で運用しました。

CLAUDE.md（安定層）: アーキテクチャ、テスト手順、キーパスなど、プロジェクト全体で不変の情報
MEMORY.md（可変層）: Phase進捗、過去の教訓、設計メモなど、セッション間で変化する情報

これにより、セッション再開時のコンテキスト復元コストがほぼゼロになりました。Phase 1で発見した移植上の注意点がMEMORY.mdに記録され、後続Phaseでも自動的に参照されました。

ただし、プロジェクトが進むにつれてCLAUDE.mdが392行に肥大化し、コンテキストウィンドウの約7%を消費した問題もあります。次回は200行以下に抑え、Phase固有の情報は別ファイルに分離する予定です。

運用ルール

ドキュメントはフェーズごとにコミットし、設計の意図と変更の経緯を追跡可能にしました
ソースコードはテストが通った後にClaude Codeにレビューさせ、その結果を筆者が判断しました。重要な箇所は筆者が直接コードを確認しました
影響の大きい箇所を優先し、すべてを完璧にすることは目指しませんでした

6. 成果 ― 正解データの有無で何が見えたか

定量的な成果

8日間の作業で得られた定量的な成果をまとめます。

指標	値
移植元VBA	約16,000行 → うち約5,300行が移植対象
生成したPython	約12,000行（移植約9,100行 + 新規機能約2,900行）
自動テスト	15,500件超（通過）
変換速度	約40秒 → 1秒未満
作業期間	8日間、約120コミット

移植の品質 ― 正解データがある場合

既存VBA 36機能のPython移植では、7,593件のリグレッションテストデータと設計仕様書がありました。正解データとの照合が「テストが失敗すれば即座に修正が必要になる仕組み」として機能し、品質が安定しました。Anthropicの公式ベストプラクティスでも、「Claudeに自身の作業を検証する手段を与えること（Give Claude a way to verify its work）」を最もレバレッジの高い実践と位置づけ、「検証できないなら出荷するな（If you can’t verify it, don’t ship it）」と明言しています。ただし、Web UI構築時にはテスト全通過後の手動確認で、テーブル表示の崩れやボタンの動作不備など数件の不具合が見つかりました。自動テストはデータの正確性を保証しましたが、表示崩れには手動確認で初めて気づきました。

逆変換の品質 ― 正解データがない場合

逆変換（Feature→DSL復元）は既存VBAに対応する実装がなく、そもそもテスト項目書も存在しませんでした。生成AIでも最初から正確には作れず、テストスクリプトの記述パターンを認識するための定義が不十分で、未対応のパターンに遭遇するたびに追加・修正が必要でした。往復テストの自動化が実装されないまま残り、手動レビューで数件のバグが見つかりました。いずれもコンポーネント間の暗黙の前提が原因でした。生成AIは各コンポーネントの単体テストは正確に生成しますが、コンポーネント間の接合面は自発的にはテストしません。正解データがない場合でも、人間が一から書くよりは開発速度で優位ですが、品質の担保には人間による確認が不可欠だと実感しました。

仕様書の有効度 ― フェーズによる差異

正解データだけでなく、仕様書の有効度もフェーズによって大きく異なりました。

作業対象	主たる情報源	仕様書の有効度
コア変換エンジンの移植（フェーズ1-5、工数の60%以上）	VBAソース + テストデータ	低
テスト環境設定ファイル生成（フェーズ6-7）	仕様書	高
Web UI（フェーズ8）	仕様書	中

コア変換エンジンの移植では、VBAソースが「実装の正解」、テストデータが「出力の正解」として機能し、仕様書は追加的な価値を生みませんでした。一方、テスト環境設定ファイルの構造仕様の設計では仕様書が不可欠でした。SDDは万能ではなく、ソースコード（How）と仕様書（What/Why）は相補的です。

今後の課題

今回の試作では、コア変換エンジンの移植、Web UI、逆変換までを8日間で完了しました。ただし、現時点では運用レベルには達していません。GUI入力支援パイプライン（全体の約38%）が未移植であり、テストも限定的な環境でのみ実施しています。以下に、8日間の作業とその後の振り返りを通じて得られた実践知と課題をまとめます。

確認できた事項

リグレッションテスト7,593件がガードレールとして機能（コア変換エンジン99.0%パス）
2層メモリモデルにより、セッション間のコンテキスト復元コストがほぼゼロに
Interface層とコア処理の分離により、Web UIへの移行がスムーズに完了
5年間の仕様書・テストデータの蓄積が、生成AIへのインプットとして有効に活用できた

残された課題

GUI入力支援パイプラインが未移植: 今回移植したバッチ変換は全体の約29%であり、GUI入力支援（約38%）は未対応
コンテキスト管理の改善: プロジェクト指示ファイルが392行に肥大化し、コンテキストウィンドウの約7%を消費。情報の階層化が必要
生成AIによるテスト記述（DSL）の提案: 順変換と逆変換の両方が揃ったことを活かした、生成AIによるテスト記述（DSL）の提案と人間による承認モデルへの移行

得られた教訓

正解データによる検証が不可欠
統合テストの「何を検証するか」は人間が、「どう網羅するか」はAIが担う
「テスト全通過」の後こそ人間の目で確認する
バグは単発で終わらない―類似ケースの横展開を指示する

次のステップ

残された課題については、GUI入力支援パイプラインの移植は必要に応じて対応する予定です。また、コンテキスト管理の改善と合わせて、生成AIによるテスト記述（DSL）の提案についても検討を進めていきます。

今回の開発でも、生成AIがタスクを一気に進め、途中で立ち止まらずに完了まで到達してしまうことがありました。計画段階で「往復テストの自動化が必要」と分析していたにもかかわらず、実装の勢いの中で後回しになり、手動レビューで初めてバグが顕在化しました。

対策としては、CLAUDE.md（プロジェクト指示ファイル）にフェーズの完了条件を明示することが有効だと考えています。例えば「統合テストがgreenであること」「往復テストを実行済みであること」を完了条件に含めておけば、生成AIが単体テスト通過だけで完了と判断することを防げます。また、Claude CodeのHooks機能を使えば、ファイル編集時にテストを自動実行し、失敗時に処理を停止させることも可能です。

5年間手がつけられなかった課題が8日間で前に進んだのは、仕様書・テストデータの蓄積があったからこそです。残された課題への対応を進め、進展がありましたら別途記事にまとめる予定です。

商標について

Claude、Claude CodeはAnthropic, PBC.の商標です。Excel、VBAはMicrosoft Corporationの商標または登録商標です。ReactはMeta Platforms, Inc.の商標です。その他記載の会社名、製品名は、各社の商標または登録商標です。