【ITニュース解説】Pin the Fixture, Not the Vendor: A Take-Home for Swap-Safe Eval Runners

システムエンジニアを目指すあなたが採用選考で「持ち帰り課題」に取り組む際、自分の書いたプログラムが「自分のパソコンでは動くのに、評価担当者の環境では動かない」という経験をしたことはないだろうか。これは「Swap drift（スワップドリフト）」と呼ばれる問題で、プログラムが特定の環境やサービス提供者（ベンダー）に過度に依存してしまい、本来の意図とは異なる結果をもたらす現象だ。この問題を解決し、より公平で信頼性の高い評価を実現するためのアプローチが提案されている。

この問題の本質は、プログラムが特定の「モデルID」、特定の「ベースURL」、あるいは特定の「入力データ（フィクスチャ）」など、開発者がテストした環境に強く結合してしまっている点にある。もし評価担当者が、あなたが使ったものとは異なるURLやモデル、あるいは少しだけ異なる入力データでテストした場合、プログラムはすぐに失敗してしまう可能性がある。評価担当者はこれをあなたのプログラムの問題ではなく、ネットワーク障害やシステム障害だと誤解してしまうことも少なくない。これでは、あなたの本来の実力やプログラムの品質を正しく評価することができない。

この課題を克服するための中心的な考え方が、「フィクスチャを固定する（Pin the Fixture）」というものだ。ここで言う「フィクスチャ」とは、プログラムが処理する入力データ、例えばJSONファイルなどを指す。この入力データが、開発者と評価担当者の間で完全に同じであることを保証するために、データの「ハッシュ値」を利用する。ハッシュ値とは、元のデータが少しでも変わると全く異なる値になる、いわばデータの「指紋」のようなものだ。具体的には、フィクスチャのファイル内容からSHA-256というアルゴリズムでハッシュ値を計算し、それを記録しておく。プログラムがフィクスチャを読み込む際、そのハッシュ値が記録された値と一致するかを確認する。もし一致しなければ、プログラムはすぐに処理を停止する。これにより、両者が常に同じ入力データを使って評価を行っていることが保証され、「異なる入力データで結果が変わる」というスワップドリフトの問題を防ぐことができる。

次に重要なのは、「アダプターの切り替え可能性（Swappable Adapter）」という考え方だ。これは、プログラムが外部サービス（例えば、AIモデルのAPIなど）と連携する部分を、ネットワーク接続が不要な「スタブモード」と、実際にネットワーク越しに外部サービスと接続する「ライブモード」の両方で動作するように設計することを意味する。スタブモードでは、外部サービスからの応答を模倣した仮のデータ（モックデータ）を使って処理を進めるため、ネットワーク環境がなくてもプログラムの基本的なロジックをテストできる。一方、ライブモードでは実際の外部サービスに接続して、より実践的な動作を検証する。この際、どちらのモードであっても、プログラムが検証する「アサーション」（期待される結果や条件）は変更しないことが重要だ。もし両モードでアサーションが異なると、それはアダプターの切り替えではなく、全く異なるテストになってしまうからだ。この切り替え可能な設計により、評価者はまずスタブモードで基本ロジックを迅速に確認し、その後必要に応じてライブモードで外部連携の検証を行うことができる。

その他にも、いくつかの重要な原則がある。まず、APIキーや外部サービスのURLといった機密情報や環境固有の設定は、プログラムのソースコードに直接書き込まず、「環境変数」から読み込むようにする。これにより、機密情報が誤って公開されたり、特定の環境にプログラムが縛られたりするのを防ぐことができる。

また、プログラムには「不変条件（Invariants）」を強制することが求められる。これは、プログラムが常に満たすべき最低限のルールだ。例えば、「プログラムが出力するレポートでは、参照するIDは必ずフィクスチャに記載されているものだけを使う」「入力データに含まれる、プログラムが認識しない余分なフィールドは無視するか、エラーとして処理する」「同じ入力（キー）を与えた場合、常に同じ決定ID（結果ID）が返される（これを「冪等性」と呼ぶ）」といった条件だ。これらの不変条件を守ることで、プログラムの信頼性と予測可能性が高まる。

さらに、「未検証の主張（Claim Hygiene）」を適切に扱うことも重要だ。例えば、AIモデルの「利用制限（allowance）」、データ保持の「期間（retention）」、利用可能な「リージョン」といった情報は、外部サービスの利用規約や契約内容によって変動する商業的な情報であり、プログラムのテストで検証すべきものではない。これらの情報をテストのアサーションに含めてしまうと、外部サービスの仕様変更があった場合に、あなたのプログラムが不当に失敗する原因となる。したがって、これらの情報はテストコードから除外し、必要であればREADMEファイルなどに「これらの情報は外部サービスの提供者によって保証されているが、本プログラムでは直接検証していない」といった形で明記すべきだ。

候補者（つまり、あなた）がこのような持ち帰り課題を受ける場合、具体的にどのようなことを求められるのだろうか。要約すると、与えられたローカルのfixture.jsonファイルを読み込み、指定されたアダプター（処理ロジック）を呼び出し、その結果をreport.jsonというファイルに書き出すプログラムを開発することだ。この際、前述の通り、MODEL_BASE_URLやMODEL_API_KEYといった設定は環境変数からのみ読み込み、フィクスチャのハッシュ値を検証し、不変条件を満たし、スタブモードとライブモードの両方で動作するようにする。また、ライブモードは必須ではなく、APIキーが提供されない場合はネットワーク経由の処理をスキップし、スタブモードの結果だけを報告できるようにする必要がある。

評価担当者は、あなたのプログラムの「行動（Behavior）」のみを採点する。製品の説明文や、ハッシュ値が確認できないスクリーンショットなどは評価の対象外だ。特に、フィクスチャのハッシュ値が一致しない場合は、自動的に不合格となる。なぜなら、入力データが異なれば、他のどんなに素晴らしいプログラムも正しい結果を出せないからだ。採点基準には、フィクスチャピンの正確さ、スタブとライブモード間でのスキーマの一貫性、未知のフィールドの扱い、冪等性の確保、機密情報の適切な取り扱い、そして未検証の情報の分離といった項目が含まれる。

この評価アプローチの背景には、候補者が陥りやすい典型的な失敗パターンがある。例えば、ユニットテストの中で特定のモデルIDを固定してしまい、他のモデルでは動作しないプログラムを書いてしまうこと。あるいは、フィクスチャを一度取得したら、その内容を勝手に変更してしまい、評価者と異なるデータでテストを進めてしまうこと。さらに、APIキーのような機密情報を誤ってレポートファイルに出力してしまうといったケースも含まれる。これらの失敗は、プログラムの動作そのものだけでなく、設計思想やセキュリティ意識の欠如を示すものと見なされる。

この課題は、AIモデルの性能比較やレイテンシ（応答速度）測定、費用見積もり、顧客記録や機密情報の公開を目的としたものではない。また、特定のライセンスモデルやネットワーク環境を前提としたチームには、スタブモードのみの利用が推奨される。この評価方法は、あなたが開発するプログラムが、変化する環境やサービスプロバイダーに対してどれだけ柔軟に対応でき、堅牢な設計がなされているかを測るためのものなのだ。評価の公平性を高め、あなたの真のエンジニアリングスキルを正確に把握するために、このようなアプローチが提案されている。