【連載④】動作確認とテストの最低ライン：Claude Codeと一緒に「壊れていないか」を確かめる方法
連載ナビ
- 前回：[【連載③】Claude Codeに実装させる対話術](https://maahsachi.com/claude-code-implementation)
- 次回：【連載⑤】commit & pushでGitHubに送る（近日公開）
- 連載一覧：Claude Code × GitHub 運用フロー（全8回）
—
Claude Codeで実装したコードのテストや動作確認、どこまでやればいいのか迷っていませんか。
「実装が終わった。でも、これって本当に動いているのか、どうやって確かめればいいんだろう」
連載第3回で実装の指示の出し方をまとめましたが、実装が終わってからが正直いちばん不安でした。
Claude Codeが「できました」と言っても、コードが読めない私には何が変わったのか見えない。「信用していいのか、確認するとしたら何をすればいいのか」という疑問が残ったまま、恐る恐るファイルを保存していました。
Claude Codeのテストや動作確認をどこまでやればいいのか。この記事では、非エンジニアでもできる最低限の確認手順を正直に書きます。テストの専門知識がなくても、Claude Codeと対話しながらできる方法です。
—
Claude Code テスト・動作確認の結論：まずこの3ステップだけやれば十分
先に結論を言ってしまいます。
「ローカルで動かす → Claude Codeにチェックさせる → 想定外の動作を一緒に潰す」この3ステップが最低ラインです。
個人開発や小さな改善であれば、最初から本格的なテストコードを書いたり、CI/CD（コードを自動でチェック・公開する仕組み）を整えたりする必要はありません（それは連載の後半でやります）。まず「壊れていない」を確認する習慣をつけることが先決です。
以下で、それぞれの具体的な手順を解説します。
—
実装後に必ずやること①：ローカルで動かして目視確認する
当たり前に聞こえるかもしれませんが、これが一番重要です。
実装が終わったら、まずローカル環境でその機能を実際に動かしてみます。Webアプリであればブラウザで開く、スクリプトであればターミナルで実行する、というシンプルな確認です。
私が最初に詰まったのは、「どうやってローカルで動かすのか」でした。Pythonスクリプトなのか、Node.jsのサーバーなのか、実行方法がプロジェクトによって違うので、最初のうちは毎回Claude Codeに確認していました。
このプロンプトがそのまま使えます：
今の実装を確認したいです。
ローカルで動作確認するために何を実行すればいいか教えてください。
コマンドを順番に教えてください（初心者なので一行ずつ説明つきでお願いします）。
Claude Codeが「まずターミナルで `npm run dev` を実行してください」のようにステップを教えてくれます。それをそのまま実行して、ブラウザやターミナルで結果を見る。これだけです。
—
実装後に必ずやること②：Claude Codeに自分でチェックさせる
動かすことができたら、次はClaude Codeに「自分が書いたコードに問題がないか見直してもらう」ステップです。
実はClaude Code自身に「さっきの実装、改めて確認してください」と頼むと、自分で書いたコードの問題点を見つけてくれることがあります。
使っているプロンプトはこれです：
先ほど実装した機能について、以下の観点で確認してください。
1. 基本的な動作に問題はないか（エラーが出やすい箇所）
2. 想定外の入力が来たときにどうなるか（例：空の入力、大きな数値など）
3. 自分で実装して「ここは少し不安」と感じた部分があれば正直に教えてください
コードを修正する必要がある場合は、修正理由を先に説明してから修正してください。
「自分で実装して不安な部分があれば正直に」という指示が意外と効きます。Claude Codeが「ここはエラーハンドリングが弱い可能性があります」と自分から申告してくれることがあって、それを直してもらうと確実性が上がります。
—
実装後に必ずやること③：「壊れるケース」を一緒に考える
3つ目は、「どうすれば壊れるか」を一緒に考えてもらうことです。
実装した機能を「普通に使う」分には動くのに、「変な使い方」をすると壊れる——これが最初に体験したトラブルのパターンでした。
たとえば、商品名の入力欄に何も入れずに「送信」を押したときにエラーが出た。文字数が極端に多いときに画面が崩れた。こういったことが本番後に出てくると対応が大変です。
これを事前に発見するために使っているプロンプトがあります：
この機能を「わざと壊そうとしたら」どんな操作をすれば壊れますか？
考えられるパターンを5つ挙げてください。
修正が必要なものは、どのファイルをどう変更するか説明した上で、私の確認を待ってから修正してください。
「わざと壊そうとしたら」というひと言が大切です。Claude Codeが意地悪な使い方を想定してコードを見てくれるので、普通の確認では見落としていた箇所が出てきます。
全部のケースに完璧に対応する必要はありません。「これは起きにくいから後回し」「これは必ず対処する」とClaude Codeに優先順位もつけてもらいながら進めると、無限に詰めすぎることもなくなります。
—
正直に言うと：まだわかっていないこと
ここまで書いてきた3ステップで、私は「致命的な問題が本番後に出る」という事態はだいぶ減りました。でも、正直まだわかっていないことがあります。
テストコードを書くべきかどうかです。
エンジニアの友人に話すと「自動テスト書いたほうがいい」と言われます。でも、そもそも何をテストすればいいのか、テストコードの書き方がわからない。Claude Codeに「テスト書いて」と頼むとそれらしいコードは書いてくれるんですが、何をテストしているのかが理解できないまま使うのは不安があります。
今は「まずテストなしで動かして、後でClaude Codeに『テストコードも一緒に書いて解説してください』と頼む」という順番でやっています。テストコードがどんなものかを見ながら理解を深めている段階です。
ただし、ログイン・決済・データ削除のような「失敗したときの影響が大きい機能」については、Claude Codeにテストコード作成まで頼むようにしています。ここだけは例外として最初から厳しく確認するようにしました。
この連載でも、後の回でテストについてもう少し深く掘り下げるつもりです。
—
動作確認チェックリスト（コピペ用）
毎回同じことをClaude Codeに確認するのが面倒だったので、自分用のチェックリストをプロンプトとして用意しました。実装が終わるたびにこれを送っています：
実装が完了したので、以下の順番で動作確認を手伝ってください。
【ステップ1】ローカル実行
- この機能をローカルで確認するコマンドを教えてください
【ステップ2】セルフチェック
- 実装したコードで気になる点・不安な点があれば教えてください
- エラーが起きやすい箇所を特定してください
【ステップ3】壊れやすいケースの確認
- 空の入力・長すぎる文字・特殊文字（@や!など）などを試した場合の挙動を確認してください
- 実行できるコマンドがある場合は実際に実行し、実行結果をもとに判断してください
- 問題があれば変更ファイルと修正内容を説明して、私の確認を待ってください
各ステップが完了したら「ステップ○完了」と報告して次に進んでください。
3ステップを一度に依頼しているので、最初に送ってしまえばあとはClaude Codeが順番に進めてくれます。途中で「ステップ1完了。ブラウザで http://localhost:3000 （開発用のアクセス先）を開いて確認してください」のように報告が来るので、それに従って確認しながら進められます。修正が必要な場合も、ファイル名と変更内容を先に教えてくれるので確認してから先に進められます。
—
まとめ
- **最低限の動作確認は3ステップ**：ローカル実行 → Claude Codeにセルフチェックさせる → 壊れるケースを一緒に潰す
- 「わざと壊そうとしたら」というプロンプトが想定外のバグを見つけるのに有効
- テストコードはまだ試行中。「書いて解説してください」で理解を深めている段階
- チェックリストをプロンプトとして用意すると毎回の確認が楽になる
動作確認は「完璧にやろう」とするとキリがありません。まず「明らかに壊れていない状態」を確認することを最初のゴールにすると、ハードルが下がります。完璧は最初から目指さなくていいです。
次回は、確認が終わったコードをGitHubに送る「commit & push」の流れをまとめます。
—
連載一覧：Claude Code × GitHub 運用フロー（全8回）
