CodexでFlutterのテストを自動生成する

はじめに

Flutter 開発では Widget テスト と ゴールデンテスト が品質確保の鍵を握りますが、手作業で書くには時間がかかります。そこで注目したのが OpenAI Codex です。Codex はChatGPTのようなインターフェースで自然言語でコーディング作業を処理できるAIエージェントです。本記事では、Codex を利用して Flutter プロジェクトのテストコードを自動生成した実体験を共有し、得られたメリット・課題・ベストプラクティスをまとめます。
ここでお話しする内容は、あくまで私個人の経験に基づいたものであり、私が所属する組織の公式な見解や実験結果ではありません。

Codex とは & Flutter テストへの適用理由

• Codex は膨大な公開コードを学習したプログラミング特化型モデルで、自然言語プロンプトから Dart / Flutter コードも生成できます。
• テストコードは「型が決まった繰り返し作業」が多く、AI に委譲しやすい領域です。
• 特に Flutter の Widget テストやゴールデンテストはボイラープレートが多く、Codex で生成時間を短縮できれば開発サイクルが加速します。

実体験: うまく行ったこと / 行かなかったこと

成功例

1. ユニットテストの自動生成

   • 「MyUtil クラスの境界値を含むユニットテストを書いて」と指示 → 6 本のテストが自動生成。
   • 微修正だけでコンパイル・テスト通過。

2. シンプルな Widget テスト

   • カウンター画面のインクリメントテストを即時作成。
   • testWidgets, WidgetTester, find.text など正しい API を使用。

課題・制限

1. 大規模一括生成は不安定

   • 100タスク程度試した範囲では、500 行を超えるテストを一度に生成すると内容が薄くなったり、依頼したスコープを狭くなったりする傾向が見られた。
   • コンテキスト長制限が原因か？　タスクのスコープを絞ったり、ファイル単位に分割すると安定。

2. Codex VM で Flutter CLI が動かない

   • Codex のクラウド環境には Flutter SDK がなく、flutter test 等の実行は不可。
   • 生成後はローカル or CI で実行が必要。

Codex 活用で得られたメリット

効果	詳細
テスト作成時間の大幅短縮	単純なユースケースはプロンプトとPR作成ボタンを押すだけの数十秒でドラフト生成。(処理時間は5分程度かかる。)人間はレビューと微修正のみ。
カバレッジ向上	"面倒だから後回し" になりがちな UI テストも容易に追加でき、CI で常時検証可能に。
テストコードの統一	Codex は公開リポジトリのパターンを学習しているため、記述スタイルが揃いやすい。
学習コストの低減	初学者でも Codex が書いたテストを読むことで Flutter テスト API を学べる。
アプリでも実装が進む	散歩中に思いついたアイデアを実装でき、CDを使うと結果まで確認できてしまう。ローカルMacなしで一定の作業が進む。

制限とリスク

• 100% 正確ではない: 識別子ミス・ import 漏れなど小さなバグが混入する。必ず人間レビューを実施。
• 実装意図までは理解しない: 重要なビジネスロジックのテスト観点は開発者が設計する必要。
• コード共有ポリシー: 内部コードを外部 AI サービスに送信することへの社内規定を確認。プランがデフォルトオンでも設定でオフにできる。
• バイナリファイルのPR作成ができない 空のファイルが生成されたがPR作成しようとするとエラーが出て作成できないことがあった。
• 外部URLやアップロード画像を参照できない 画像をプロンプトUI上でアタッチする方法がない。URLを与えると直接アクセスできない結果になった。

例: Codex が生成したテストのサンプル

Widget テスト

import 'package:flutter_test/flutter_test.dart';
import 'package:flutter/material.dart';
import 'my_app.dart';

void main() {
  testWidgets('カウンターが 0 → 1 に増える', (WidgetTester tester) async {
    await tester.pumpWidget(MyApp());

    expect(find.text('0'), findsOneWidget);
    await tester.tap(find.byIcon(Icons.add));
    await tester.pump();

    expect(find.text('1'), findsOneWidget);
  });
}

ゴールデンテスト (要調整)

testWidgets('MyWidget ゴールデン', (tester) async {
  await tester.pumpWidget(const MyWidget());
  await expectLater(
    find.byType(MyWidget),
    matchesGoldenFile('my_widget.png'),
  );
});

golden_toolkit を使う場合は screenMatchesGolden に置き換え、フォントロード設定を追加。

ツールチェーン統合

1. flutter_test: Codex 出力は標準 API を利用。即実行可能。

2. golden_toolkit: 複数デバイス・フォント固定などゴールデン安定化に必須。AI 生成コードを軽く修正して利用。

3. GitHub Actions:

   • ubuntu-latest でユニット／Widget テスト。
   • macos-latest でゴールデンテスト。
   • flutter test --coverage でカバレッジ収集。

ベストプラクティス & 推奨ワークフロー

1. 小さく試し、大きく育てる: ファイル単位で生成→実行→レビューのループを回す。依頼タスクの粒度を最適化する。
2. 並行作業を意識してタスクを計画: 待ちが発生しないように&競合解消地獄にならないように。
3. プロンプトを明確に: 「LoginForm のバリデーションエラーをテスト」など具体的に指示。
4. 生成後すぐCI実行: コンパイル & テスト失敗を即修正。失敗が本物のバグかも確認。
5. チームでナレッジ共有: 良いプロンプト例・注意点をドキュメント化し、新メンバー教育に活用。AGENTS.mdのルールを改修する。

つらさ

１つの機能開発に専念してしまうと、指示出し、レビューまでAgent処理待ちが生まれる。そのため、待ち時間で別の機能の開発を始める体験が多かった。すると、フィードバックを与えたり、結果を確認するときに、全く関係ないタスクを短時間に扱う体験にんsる。短時間に大量のコンテキストスイッチが生まれ、脳負荷が高いと感じた。

未来の想像

これまで「実装エンジニア」と呼ばれてきた職種は、純粋なプログラミング作業が大幅に減り、代わりにプロダクトマネージャー（PdM)、デザイナー、プロジェクトマネージャー（PjM）やエンジニアリングマネージャー（EM）、品質保証（QA）の業務の比重が増していくでしょう。

一方で、設計や複雑な実装の問題を解決する業務は残ると思うので、実装エンジニアがなくなるわけではないと考えています。

これからの実装エンジニアには、単にコードを書く技術だけでなく、より高度な設計力や問題解決力はもちろんのこと、PMやデザイナー、QAの専門知識がより求められるようになるはずです。

(単位時間あたりに実装できる量が増えるので、PdMなどの周辺領域がボトルネックになるはずで、そこを補うために実装エンジニアの業務が変化していくという感覚です。)

AIが自律的にプロジェクトを管理できるようになるまでは、実装エンジニアが「AI（エージェント）に指示を出す → 結果を確認する → 必要に応じて修正指示を出す」というサイクルを回すことが増えます。この際、技術的な視点だけでなく、PM、QA、デザイナーの視点も持ち合わせ、多くのタスクを並行してこなしながら、プロジェクトを推進していくことになるでしょう。

QAコーナー

Q: 画像でレイアウト指示を出せるか？
A: 現時点では画像をGUIで与えることができない。リポジトリに含まれる画像を評価することができるかもしれないが、要検証です。この点は、O3などの画像認識がすでに提供されているので、そう遠くない将来に統合して提供されるのではないかと期待しています。

Q: URLで外部サイトを読ませることはできますか？
A: 実験した範囲では直接読んで理解できませんでした。必要なコンテキストは、リポジトリの内部に格納する必要がありそうです。この点も、マルチリポジトリ参照と同様に、開放されるのではないかと期待しています。

Q: テストのスタイルをどう指定するか？
A: リポジトリに手本となるコードを書いて指示できる。AGENTS.mdでルールを書けるのでそこで制御してもよい。

Q: いくらかかるか？
A: 現時点では費用体系が発表されていない。Proプランのみで開放されています。もしかしたら基本回数はプランに含めて、一定回数を超えた利用は従量制になるかもしれないですね。

Q: PR承認率は？
A: 自分の実験では100件くらい試して90%程度でした。残り10%はバグっているというよりも、プロンプトの意思疎通齟齬によって意外なアウトプットになったケースや、出力結果を見てより本質的な依頼をするといったケースがほぼでした。

Q: 実行時間は？
A: 5,6分くらいになることが多かったです。粒度が大きな依頼をしてもそのくらいの時間で終わる実装になるので、その時間で十分終わる粒度に依頼を分割することが大事そうです。DevinやClaude Codeはもっと長時間の作業を依頼できるので、そこの違いがワークフローに影響しそうです。

まとめ

Codex は Flutter テスト自動化の強力なブースターです。単純テストはエージェントに進めてもらい、重要テストは人間が設計という役割分担で、テスト網を短時間で拡充できます。ただし環境制約や精度の限界もあるため、人間のレビューと CI 連携を前提に導入しましょう。適切に運用すれば、開発速度と品質の両立が実現できます。ぜひ小さく試し、効果を定量的に計測しながら社内に展開してみてください。🚀