ClaudeCodeで生成したコードをClaudeCodeにテストしてもらった
はじめに
僕は今年の7月ごろにClaudeCodeのProプランに課金して、何ができるかよく分からないまま、アプリを作ってみました。仕事だとGithub Copilotを使っていますが、その時は変数名考えてもらったり、メソッドのテンプレートを作ってもらったりとあまり有効活用しているとは言えませんでした。それなのになぜClaudeCodeを使ってコード生成をはじめたのか?簡単な話で。流行りに乗っかったこと、そしていろんな記事で使っている人をよく見かけたからです。技術選定としてはかなり適当ですが、新しいツールを試してみたい気持ちに正直になりました。
そんな感じの行き当たりばったりでClaudeCodeを使ってアプリを作ってみたのですが、少しずつ機能を説明し、動いたものをデバッグしているとなんかよく分からないけど、動くものが出来上がってきました。
迷走の経緯
当初の野望
最初にClaudeCodeに投げた要求は、こんな感じでした:
自分専用のメモ帳アプリを作ろうと思います。これから一緒に仕様を考えて欲しいです。現時点での要求は以下の通りです。
・開発言語はSwift、SwiftUIを使います。
・編集方法はMarkdown記法を使用します。
・編集したデータの保存方法は一緒に考えて欲しいです。
・編集したデータはMarkdownのまま出力したり、整形された状態で出力したりしたいです。
・エクセルのような表形式のデータをペーストする場合にはMarkdown形式に直す機能が必要です。
シンプルで明確な要求...のはずでした。
現実:仕事終わりの少しずつ開発
仕事終わりに少しずつ開発を進めていくうちに、当初の仕様はどこか遠い記憶となっていきました。ClaudeCodeとの対話を経て、機能がどんどん追加され、気がつくとこんなアプリになっていました:
実装された機能:
- ✅ Swift + SwiftUI
- ✅ Markdown記法対応(リアルタイムプレビュー付き)
- ✅ データ保存(Swift Data採用)
- ✅ Markdown/テキスト/PDF出力
- ✅ グループ管理機能(追加)
- ✅ ゴミ箱機能(追加)
- ✅ 検索機能(追加)
未実装の機能:
- ❌ 表形式データのペースト→Markdown変換機能
作った本人問題
開発が一段落した頃、ふと気づいたことがありました。
「あれ?このアプリ、結局何ができるんだっけ?」
当初の要求を見返すと、表形式データの変換機能を実装していないことに気づきました。
作ることそのものを忘れていました。しかも、実装された機能の詳細も曖昧になっていました。
問題の整理:
- 作った本人が全機能を把握できていない
- 「完成」の定義が曖昧
- 日々の合間に作っているので仕様を忘れがち
- ClaudeCodeが正しく実装したか評価できない
これでは完成とは言えません。せっかくClaudeCodeにコードを生成してもらっても、正しくできたか、欲しいものができたか評価できないのです。
逆転の発想
そこで思いついたのが、テストから仕様を逆算するというアプローチでした。
発想の転換:
- 仕様書→実装→テストの順番ではなく
- 実装→テスト→仕様書の順番で進める
- ClaudeCodeにテストコードを生成してもらう
- 生成されたテストから「実際に何ができるアプリなのか」を明確にする
- テスト結果から正式な仕様書を作成する
ここまできたらテストもClaudeCodeに任せつつ、テストコードを見ながら仕様を整理しよう、という作戦です。
実践編:ClaudeCodeによるテスト生成
ClaudeCodeにテスト生成を依頼しました。プロジェクト構成を読み取ってもらい、包括的なテストスイートの作成をお願いしました。
# ClaudeCodeに依頼した内容(概要)
「既存のiOSアプリプロジェクトを分析して、
包括的なユニットテストとUIテストを生成してください」
生成されたテストの内容
ClaudeCodeが生成してくれたテストは、以下のような内容でした:
Model層のテスト:
- Memoモデルの基本操作(作成、更新、削除)
- Groupモデルの基本操作
- DataManagerのCRUD操作
Markdown関連のテスト:
- 各種Markdown記法の表示確認
- 見出し、太字、斜体、リスト、コードブロック等
- MarkdownToHTMLConverterの変換テスト
UI操作のテスト:
- メモの作成、編集、削除のユーザー操作
- グループ管理の操作
- ゴミ箱機能の動作確認
// 例:生成されたテストコードの一部
class MarkdownTests: XCTestCase {
func testHeadingConversion() {
let converter = MarkdownToHTMLConverter()
let markdown = "# 見出し1"
let html = converter.convertToHTML(markdown)
XCTAssertTrue(html.contains("<h1>見出し1</h1>"))
}
func testBoldTextConversion() {
let converter = MarkdownToHTMLConverter()
let markdown = "**太字テキスト**"
let html = converter.convertToHTML(markdown)
XCTAssertTrue(html.contains("<strong>太字テキスト</strong>"))
}
}
期待と現実:テスト実行結果
正直なところ、「ClaudeCodeなら何か凄いテストケースを考えてくれるのでは?」という期待がありました。
現実:ありふれた基本機能のテスト
蓋を開けてみると、生成されたテストは非常にオーソドックスなものでした:
- Markdown表示の基本的なテスト
- メモのCRUD操作テスト
- 一般的なUI操作テスト
特別驚くような項目はありませんでした。
しかし、この「地味さ」こそが重要だったのです。
地味だけど重要だった成果
基本機能の動作確認
当たり前だと思っていた機能が、実際にテストによって動作することが証明されました。vibe codingで作ったアプリでも、基本機能はしっかりと実装されていたことがわかりました。
仕様の再確認
テストコードを読むことで、「結局何ができるアプリなのか」を客観的に整理できました:
MyMemoAppの実際の仕様(テストから逆算):
-
Markdown対応メモアプリ
- H1-H3見出し、太字、斜体、取り消し線
- インラインコード、コードブロック
- 箇条書き、番号付きリスト
- 引用、リンク、画像、テーブル
-
データ管理機能
- メモの作成、更新、削除
- グループによるカテゴリ分け
- 論理削除によるゴミ箱機能
-
エクスポート機能
- Markdown形式での出力
- テキスト形式での出力
- PDF形式での出力
-
検索機能
- タイトルと本文の全文検索
忘れていた機能の再発見
テストを通して、実装していない機能も明確になりました:
- 表形式データのペースト→Markdown変換機能:完全に実装を忘れていました
- 高度な検索機能:基本検索のみで、タグ検索等は未実装
vibe coding + テスト生成の評価
メリット
基本機能の動作保証
- 思い込みではなく、実際にテストで動作確認
- バグの早期発見と修正
仕様の客観視
- 実装者の記憶に頼らない仕様確認
- テストコードという形で仕様を文書化
実装者の記憶曖昧問題の解決
- 「何を作ったか忘れた」問題の解決
- 機能追加時の影響範囲の把握
開発効率の向上
- ClaudeCodeがテスト設計から実装まで自動化
- 手動テストの工数削減
デメリット・限界
革新的なテストケースは期待薄
- AIが生成するテストは基本機能中心
- エッジケースや複雑なシナリオは人間の設計が必要
基本機能中心のカバレッジ
- 一般的な機能テストが中心
- 業務特有の要件やユーザビリティは考慮されにくい
テスト品質の限界
- 生成されたテストが本当に十分かは別途検証が必要
- テストのテストが必要な場合もある
まとめ
「ClaudeCodeで生成したコードをClaudeCodeにテストしてもらう」という実験は、派手な成果はありませんでしたが、実用的な価値がありました。
得られた教訓:
-
vibe codingでも基本品質は保てる:AIとの協業により、思った以上にしっかりしたアプリが作れる
-
テストは仕様書になる:実装から仕様を逆算する手法として有効
-
AIテストは基本機能に強い:革新性はないが、確実性がある
-
忘却対策として優秀:作った本人の記憶曖昧問題を技術的に解決
今後の展望:
- 未実装機能(表形式データ変換)の追加実装
- より高度なテストケースの人間による補完
- 継続的インテグレーションでの自動テスト実行
vibe codingというアプローチは一見いい加減に見えますが、適切なテスト戦略と組み合わせることで、実用的な開発手法になり得ることがわかりました。ClaudeCodeのようなAIツールは、この「テスト補完」の役割で特に威力を発揮するのかもしれません。
Discussion