AIが書いたテストを鵜呑みにしない ── 丸投げせずに、まず自分で考える

はじめに

はじめまして。リチェルカでクライアントアドバイザーを担当している浦と申します。平たく言えばカスタマーサクセスです。リチェルカのCSは少し変わっていて、お客様対応だけでなく、PdMとしての役割も担っています。エンジニアと一緒にプロダクトを作る側にも関わるので、CSメンバー自身もコードを書きます。いわゆる「非エンジニア」ですが、コーディングも仕事のうちです。

コードを書く際にはClaude Codeを活用しています。AIと一緒にコードを書き、レビューしてもらいながら実装を進めていくスタイルです。この記事は、非エンジニアの自分が初めてPRを出し、レビューを通じて得た気づきを書いたものです。AIコーディングを実践している方、あるいはこれから始めようとしている方に、何か1つでも持ち帰ってもらえたらうれしいです。

やったこと｜フォルダ名検索のバグ修正

取り組んだのは、自社プロダクト「RECERQA Scan」のバグ修正です。内容は「フォルダ名で検索したときに、フォルダ内のルールが表示されない」という問題でした。

進め方はシンプルで、事象を再現してバグを確認したあとは、AIと一緒にissue作成 → 原因分析 → 設計 → テスト → 実装まで一気に進めていきます。AIがいることで、「次に何をすべきか」「このコードで合っているか」を都度確認しながらテンポよく進められるのが、AIコーディングの強みだと感じています。

もらったフィードバック｜「何を入力したらどうなるか」から考える

PRに対して、CTOとエンジニアからフィードバックをもらいました。

私が書いたテストは、正常系が1ケースだけ。「ルール名を検索したら、そのルール名が返ってくる」─バグとして再現していた事象が直ることは確認していましたが、それだけでした。

フィードバックはこうです。

「何を入力したときに、フォルダとルールそれぞれに何が表示されるか。そこから考えたとき、どんなテストが必要か考えてみよう」

たとえば、以下のようなケースがすべて抜けていました。

言われてみれば、どれも当然考えるべきケースです。でも自分では気づけていませんでした。

ここで重要なのは、AIも同じようにこれらのケースを提案しなかったということです。AIが出してくれたテストは、自分が確認していた正常系をなぞったものでした。つまり、自分の思考が浅いまま進めると、AIのアウトプットもそれに引っ張られるのです。

気づき｜AIのテストを鵜呑みにしない

ここから得た気づきは、一言で言えばこうです。

AIが考えたテストをそのまま使うのではなく、自分の頭で一度考えてから、AIと壁打ちする。この順番が大事だと気づきました。

AIコーディングは、AIに丸投げすれば進むわけではありません。AIのアウトプットの質は、こちらの入力の質に左右されます。だからこそ、AIと作業を始める前に、自分の思考をある程度整理しておくことが大切です。

具体的に、今回の経験を踏まえて整理したフローはこうなりました。

① issueを起票する前に、自分で事象を言語化する

issueの起票自体は簡単です。AIがいくつか質問をしてくれて、それに答えていくだけで、AIが内容を整理してissueを作ってくれます。

ただ、その質問に答えるためには、自分の中で「何が起きているか」「どこがおかしいのか」がある程度言語化できていないといけません。事象がぼんやりしたままだと、AIの質問にもうまく答えられず、結果としてissueの精度が下がります。AIはissueをもとに問題を特定・分析するので、ここが出発点の質を決めます。

だからこそ、AIとのやりとりを始める前に、自分の頭で事象を整理しておく。この準備が、その後の工程すべてに効いてきます。

② テストケースは、ローカルで検証できるタイミングで「自分で」考える

リチェルカでは、実装コードを書く前にまずテストを書く流れで進めています。つまり、テストケースの設計が、そのまま実装の方向性を決めるということです。

AIがissueをもとにテストケースの候補を出してくれますが、この段階ではまだわからないことも多いので、一旦先に進みます。テストケースをしっかり考えるのは、ローカル環境で検証できるタイミングです。

先にテストを書くからこそ、ここで手を抜くと実装そのものがズレます。実装の前に、「どんな入力パターンがありうるか」「それぞれのパターンで何が返るべきか」をまず自分で列挙します。

今回で言えば、「フォルダ名がマッチしなければ何も返さない。ならば、マッチしたときに正しく返ることも確認すべきだ。部分一致はどうか。複数フォルダがあるときはどうか」─こうした思考を自分で一巡させます。

③ 自分のケースをAIに投げて、壁打ちする

自分で考えたテストケースをAIに渡し、「これで抜け漏れはないか」を確認します。AIは自分が見落としていた「こういう入力が来たらどうなる？」という想定外のパターンを指摘してくれることがあります。

大事なのは、この壁打ちが「AIの提案を受け入れるかどうか」ではなく、「自分の思考を検証する」プロセスになっていることです。先に自分で考えているからこそ、AIの指摘が「なるほど、それは抜けていた」なのか「いや、それは今回のスコープ外だ」なのかを判断できます。

なぜこの順番が大事なのか

振り返ると、これはテストの話に限りません。

私はこれまでマーケターとして、そしてPdMとして働いてきました。どちらの仕事でも、「後工程を意識する」ことが求められます。マーケターがリードを獲得するとき、そのリードを受け取るインサイドセールスのことを考えなければ、質の低いリードが大量に流れるだけです。PdMが要件定義書を書くとき、曖昧な記述はエンジニアの認知負荷を上げ、コミュニケーションコストを増やします。

コーディングも同じでした。PRを出した先には、レビューしてくれる人がいます。「このテストケースで、何を確認したかったのか伝わるかな」「読んだ人が迷わないかな」。そこまで想像してから出すのが、後工程への最低限の責任だと考えています。

AIのおかげでコーディングのスピードは上がりました。でもスピードが上がったからこそ、考えることを省略すると「意図の薄いPR」が溜まっていきます。速く動けるからこそ、丁寧に考える。 AIが出したものをそのまま使わず、自分で一度考える。その手間をかけることで、PRの質が変わり、レビュアーの負担が変わり、チーム全体の開発スピードが変わる。

それが、最初のレビューから得た一番の学びです。

おわりに

非エンジニアの自分がコーディングへ踏み出してから、まだ日が浅いです。 PRを出すときは、テストケースを考える段階で「レビュアーに聞かれたら何と答えるか」を自分に問いかけてから出すことを意識しています。AIと上手く付き合うために必要なのは、AIを信頼しながらも、考えることを手放さないこと。スピードが上がった分だけ、丁寧に考える余裕も生まれるはず。