テスト環境の再現性を確保する：相対パス問題と絶対化の実装パターン

あるコードを別環境にコピーしてテストを走らせたら、実行するディレクトリを変えただけで結果が変わってしまう——そんな経験はないでしょうか。これは「たまたま動いた」「たまたま落ちた」で片付けられがちですが、実は原因を一箇所に絞り込める典型的な不具合です。今回はローカルLLMを使った自動修理システムで実際に遭遇した、相対パスに起因するテスト全滅とその直し方を扱います。

何が起きていたか

自動修理システムでは、対象プロジェクトをそのまま解析するのではなく、「サンドボックス」としてコピーしてから起動テストやブラックボックステストを走らせる構成をとっています。このサンドボックスを生成する関数が、渡されたパスを相対パスのまま処理していました。相対パスは「どこを基準にするか」が呼び出し元のカレントディレクトリ次第で変わるため、同じ引数を渡しても実行位置が違うとパスの連結結果がずれてしまいます。

実測での発覚経緯

複数の別プロジェクトに対して同じパイプラインを実行したところ、起動テストとブラックボックステストが揃って失敗するケースがありました。ここで大事なのは、推測でコードを疑って直しにいくのではなく、実際に失敗したログを確認し、同じ条件で再現できることを先に確かめた点です。再現できない「たぶんここだろう」という修正は、往々にして的外れに終わります。

修正方針

直し方自体はシンプルです。サンドボックスへのパスを受け取った直後に絶対パス化する一行を入れるだけで、パス連結ロジック自体には手を加えません。パスを扱う処理を作り替えるのではなく、「入口で正規化する」ことで、以降のすべての処理が一貫した絶対パスを前提にできるようにする——これが今回のポイントです。

効果の確認

修正後、同じ条件で再度実行し、起動テスト・ブラックボックステストの双方が解消したことを確認しています。「直したつもり」で終わらせず、実際にもう一度動かして結果の変化を見る、という検証まで含めて一つの作業です。

実装チェックリスト / 調査順

• 「同じコードなのに実行環境で結果が違う」現象を見たら、まずパスの扱いを疑う。
• 再現できないうちは直しにいかない。実際のログ・実際の失敗条件で再現してから着手する。
• 外部から渡されるパスを扱う関数の入口では、早い段階で絶対パス化しておく。
• パス連結ロジックそのものより先に、まず「入口の正規化漏れ」を疑う。
• 修正後は同じ条件でもう一度実行し、結果が安定したことを確認してから完了とする。

この手のバグは地味ですが、環境依存という性質上、気づかれにくく再現性も低いため見落とされがちです。パスを扱う関数の入口を絶対パス化しておくという習慣だけで、かなりの割合を未然に防げます。

次の一歩として、自分のプロジェクトでも「相対パスのまま外部から受け取っている関数」がないか、一度棚卸ししてみることをお勧めします。