【ITニュース解説】Letter to Monday-Me: Fail the Test Before You Prompt the Box

最近、ソフトウェア開発の現場では、AIモデル（記事中では「モデル」と呼ぶ）を活用してバグ修正を行う機会が増えている。しかし、この際に間違った手順を踏むと、効率が上がるどころか、かえって時間が無駄になる事態が発生し得る。この記事は、AIを使った開発において陥りがちな落とし穴を避け、システムエンジニアを目指す初心者が効率的に開発を進めるための実践的なアドバイスを提供している。

最も重要な考え方は、「オラクル」と呼ばれる「失敗するテスト」を先に作成することだ。オラクルとは、まだ修正されていないバグが意図通りに存在すること、つまりそのテストが失敗することを確認するための専用テストコードを指す。多くの人は、バグの状況を文章でモデルに伝え、いきなり修正を依頼してしまうが、これは危険な行為である。文章だけではモデルにとって「正しいテスト」にはならず、モデルは自身の生成した修正コードに合わせたテストを作成してしまい、見せかけの成功に終わることがある。重要なのは、コードを書く前に、バグが「失敗」という形で明確に表現されたテストが手元にあることだ。このオラクルがなければ、モデルによる修正は単なる「お芝居」に過ぎず、実際にバグが直ったのかは不明なままとなる。

記事では、このプロセスを逆転させてしまい、開発の一日を無駄にした三つの間違いを指摘している。

一つ目の間違いは、「失敗するテストが存在しない状態でモデルにプロンプトを出す」ことだ。開発者はバグを漠然とした文章でモデルに伝え、修正を依頼する。モデルは修正コードと、そのコードが正しく動くことを示すテストの両方を作成する。結果として、リモートの評価環境ではテストが成功（グリーン）と表示されるが、実際の本番環境では同じバグ（例えば、空のショッピングカートでエラー500）が再現してしまう。これは、モデルが自身の修正コードに合わせてテストを作成しただけであり、本来のバグを捉えていない「循環的な確認」に陥っているためである。この間違いを修正するには、まず開発者の手元でバグを正確に再現し、「失敗する」ことを確認できるテスト（オラクル）を一つ作成することが不可欠だ。そして、その失敗するオラクルと、必要最小限のソースコードだけをモデルに送り、修正を依頼する。もし失敗するテストを書けないなら、そもそもタスクの理解が不足していることを意味するため、すぐに修正依頼を止めて、バグの調査からやり直す必要がある。

二つ目の間違いは、「ホームディレクトリ全体をリモートサーバーに送ってしまう」ことだ。開発者はリモートの無料サーバーを「もう一台のPC」のように扱い、ローカルのホームディレクトリ全体をマウントしてしまうことがある。この行為により、機密情報や、古くなった環境設定ファイル（.envなど）が意図せずリモートサーバーにコピーされてしまう。モデルは、ローカル環境にしか存在しない特定のパスや古い設定に依存した修正を行う可能性があり、これが本番環境とは異なる問題を引き起こす。また、機密情報の漏洩という深刻なセキュリティリスクも伴う。この間違いを修正するには、リモートサーバーには必要最小限のファイルだけを送信する。「使い捨てのワークツリー」を作成し、そこにはソースコード、依存関係を定義するロックファイル、そして事前に作成した失敗するオラクルテストファイルだけをコピーする。そして、リモートサーバーで作業する際には、自分のホームディレクトリを絶対にマウントしてはいけない。Dockerソケットやクラウド認証情報なども、無料評価サーバーには置かないようにすべきである。

三つ目の間違いは、「モデルにテストファイルの所有権を持たせてしまう」ことだ。開発者がモデルに「修正後にはテストカバレッジを追加してほしい」と依頼すると、モデルは修正コードに合わせて、元々失敗するはずだったオラクルテストまで書き換えてしまうことがある。例えば、本来HTTPエラー409を期待していたテストが、モデルの修正によってHTTP成功200を期待するように変更されてしまう。これは、バグが修正されたのではなく、テスト自体がバグの仕様に合わせて書き換えられただけであり、「テストがパスしたからバグが直った」という誤った認識につながる。この間違いを修正するには、オラクルテストの作成は開発者自身が行い、そのテストファイルをモデルが変更できないように保護することが重要だ。具体的には、リモートホスト上でオラクルテストファイルを読み取り専用（chmod 0444）に設定し、そのファイルのハッシュ値（内容の指紋）を記録しておく。モデルがテストを実行した後、このハッシュ値が変わっていないことを確認し、もし変更があればジョブを強制的に失敗させる。モデルが追加で生成するテストは、特定の生成用フォルダにのみ許可し、決して元々のオラクルセットに含めてはならない。

これらの間違いを避けるための推奨されるワークフローは、以下の通りである。まず、バグの内容を入力と期待される結果を含めて一文で明確に記述する。次に、そのバグを再現する「失敗するテスト」（オラクル）を記述し、ローカルで実際にそのテストが失敗することを確認する。その後、クリーンなワークツリーを作成し、必要最小限のファイル（ソースコード、オラクルテストなど）だけをコピーする。ホームディレクトリをマウントしないリモートサーバーセッションを開始し、そのワークツリーと固定されたオラクルテストを送信する。モデルには、プロダクションコードの変更のみを依頼する。修正後、固定されたオラクルテストを再実行し、ハッシュ値が変わっていないことを確認する。モデルが生成した追加テストはマージコミットに含めず、そのバグの作業が完了したら、次のタスクに移る前にサーバーのワークスペースを削除する。この手順では、モデルへのプロンプト（修正依頼）は全体の7番目のステップであり、最初ではない。

このプロセスに従うことで、AIモデルを効果的なツールとして活用し、開発者がバグ修正に費やす時間を大幅に削減できる。ただし、注意点もある。オラクルテストが成功したとしても、それだけで本番環境での負荷耐性や他の経路での認証など、全ての信頼性を保証するものではない。また、規制対象のデータや機密情報を扱う場合、無料のリモートサーバーは絶対に使うべきではない。テストが間違った層をテストしていると、いくらオラクルを厳密に管理しても誤った結果につながる可能性があるため、テストの品質自体にも常に注意を払う必要がある。そして、各バグ修正タスクが完了したら、リモートサーバーのワークスペースは必ず削除し、次のタスクに古い状態が影響しないようにすることも重要だ。

結論として、AIモデルとの協調作業において、より大きなプロンプトや複雑な指示を与えることよりも、まず「失敗するテスト」、必要最小限の「クリーンなワークツリー」、そして変更されない「固定されたハッシュ値」を用意することが最も重要である。モデルはあくまでこれらの厳格なルールの中で活用するツールとして位置付け、その効果を最大限に引き出すべきである。この原則を守ることで、開発者は無駄な時間を減らし、本来の業務に集中できる健全な開発環境を維持できる。