論文要約：Co-Located Tests, Better AI Code

タイトル: 共配置テスト、より良い AI コード：テスト構文構造が基盤モデルによるコード生成に与える影響
著者: Éric Jacopin (Cosmic AI)
発表: AIware 2026 (プレプリント)

1. 研究の背景と問題提起

基盤モデル（Foundation Model, FM）の時代において、AI コーディングアシスタントは実装コードだけでなくテストコードも生成するようになっています。しかし、開発者がテストコードをどのように構造化するか（実装コードに埋め込む「インライン」か、独立したブロックやファイルに分離する「分離」か）は、従来のテスト哲学やチームの慣習に依存しており、AI のコード生成品質にどのような影響を与えるかは未解明でした。

本研究は、**「テストコードの配置と構文が、AI によって生成されるコードの品質に影響を与えるのか？」**という問いに答えることを目的としています。特に、Python のドキュメント内テスト（doctests、インライン）と Rust の #[test] ブロック（分離）の対比を通じて、この構造的な選択が AI の性能に与える影響を調査しました。

2. 研究方法 (Methodology)

2.1 実験設計

• タスク: 実用的なデータ構造である「d-ary ヒープ（優先度キュー）」の実装。6 つ以上の公開メソッド、ジェネリック型、エッジケースの処理など、中程度の複雑さを持つタスクを選択。
• 言語と構文:
  • Python (インライン): 関数の docstring 内に >>> マーカーでテストを埋め込む形式（最大限の共配置）。
  • Rust (分離): 実装ファイル内の mod tests {} ブロックに #[test] 関数を記述する形式（構造的に分離）。
• モデル: 3 社提供の 12 モデル（主に Claude 系列の 9 モデル：Haiku, Sonnet, Opus の各世代、および Mistral, Devstral などの他社モデル）。
• データ量: 830 以上の生成ファイル、12 モデル、3 社プロバイダ。

2.2 評価フレームワーク：SEGA

コード生成の品質を 3 つの直交する次元で評価する「SEGA (Statistical Evidence for Generative Accuracy)」フレームワークを導入しました。

1. Determinism (決定性): 温度パラメータ 0 での出力の安定性（同一出力の割合）。
2. Preservation (保存性): プロンプトで指定されたテストが生成出力にどの程度残存しているか。
3. Correctness (正しさ): 生成されたテストが実際に実行して通過する割合。

これらを 2 次元（保存性×正しさ）または 3 次元（決定性も加える）の「品質領域」にマッピングし、モデルの適性を可視化しました。

2.3 メカニズム解釈可能性 (Mechanistic Interpretability, MI)

なぜ構文構造が結果に影響するのかを解明するため、7 つのオープンソースモデル（6 つのトランスフォーマーと 1 つのゲート付き線形 RNN: RWKV-6）の内部動作を分析しました。

• アテンション分析: テストマーカー（>>> や #[test]）から関数トークンへのアテンション強度を測定。
• 因果検証: 「ノックアウト実験」（アテンションや recurrent state を遮断）と「ステアリング実験」（アテンション強度を操作）を行い、因果関係を立証。

3. 主要な結果 (Key Results)

3.1 構文構造による品質への劇的な影響 (RQ1)

• インラインテスト (Python doctests): ほぼすべてのモデルで**保存率 100%、正解率 92-100%**という近接した完璧な結果を示しました。
• 分離テスト (Rust #[test]): モデルのティア（性能レベル）によって結果が極端に分かれました。
  • 上位モデル（Opus 4/4.1/4.5）は、**テストをすべて削除（保存率 0%）**して実装のみを生成する傾向がありましたが、生成されたコード自体は正しくコンパイル・実行されました（正解率 100%）。
  • 一方、下位モデル（Haiku 3）はコンパイルすら失敗しました。
  • 重要な発見: 「テストの保存」と「コードの正しさ」は独立した次元であり、AI はテストを削除しても正解を生成できることが示されました。

3.2 言語難易度ではなく構文構造が原因 (RQ2)

• Opus 4/4.1/4.5 は Rust 言語そのものは正しく扱える（コンパイル可能なコードを生成）ため、問題点は「Rust の難易度」ではなく、「#[test] という構文の扱い方（テストを仕様として解釈し、出力から除外する）」にあることが判明しました。
• 下位モデル（Haiku 4.5）が Rust テストを保存する一方、上位モデルが削除するという「ティア逆転」現象は、言語能力ではなく構文処理の挙動の違いを反映しています。

3.3 モデルの進化と挙動の不安定性 (RQ3)

• モデル進化: 3 世代連続（Opus 4, 4.1, 4.5）で「テスト削除」挙動を示したモデルが、Opus 4.6 で突然「テスト保存」に戻りました。これはトレーニングレベルでの行動変化です。
• 回帰: Haiku 3 はテストを保存しますが、Haiku 3.5 はすべて削除し、Haiku 4.5 で再び保存するようになりました。モデルのアップデートがテスト処理挙動に回帰をもたらす可能性があります。
• 決定性の誤解: 温度パラメータを 0 に設定しても、出力が完全に決定論的（同一）であるとは限りません（Mistral Medium は 50 回実行で 50 通りの出力）。しかし、この非決定性は「見た目（変数名など）」の差であり、機能的な正しさには影響しない場合が多いことが示されました。

3.4 メカニズム的証拠 (RQ4)

• アテンション強度: 5/7 のモデルで、インラインテストマーカー（>>>）は関数トークンへのアテンション強度が、分離テストマーカー（#[test]）よりも2.8〜4.4 倍強かった（統計的有意性あり）。
• アーキテクチャの一般化: この効果はトランスフォーマーだけでなく、RNN である RWKV-6 でも確認されました。これは「共配置の利点」が特定のアーキテクチャに依存せず、シーケンス処理の根本的な性質であることを示唆しています。
• 因果関係: ノックアウト実験により、テストマーカーへのアテンションが生成結果に因果的に寄与していることが確認されました。

4. 主要な貢献 (Contributions)

1. 実証的発見: テスト構文構造が AI コード生成品質に測定可能な影響を与えること。インラインテストは全モデルで高品質な結果を生むが、分離テストはモデルの能力差を露呈させ、保存性と正しさが独立であることを明らかにした。
2. 評価フレームワーク SEGA: 決定性、保存性、正しさを統合した 3 次元評価フレームワークと、モデルの適性を可視化する「品質領域」の概念を提案。
3. メカニズム的証拠: 7 つのアーキテクチャ（トランスフォーマーと RNN）におけるアテンションパターンの分析と、因果検証（ノックアウト/ステアリング）により、インライン構文が優位である理由を解明。
4. 設計ガイドライン: AI 支援開発におけるテストフレームワーク設計、モデル選定、CI/CD パイプライン設計のための具体的な指針を提供。

5. 意義と提言 (Significance & Guidelines)

本研究は、基盤モデル時代において「テストの構文構造」は単なる開発者の好みや哲学の問題ではなく、AI の生成品質に直結する重要なソフトウェア設計上の課題であることを示しました。

実用的な提言:

1. テストの実装コードとの共配置: AI アシスタントを使用する際、テスト仕様を実装コードの直近（ドキュメント内や同じファイルの隣接ブロック）に配置する「共配置（Co-location）」原則を採用すべきです。これは AI がテストと実装の文脈的結びつきを強く認識できるためです。
2. テストの実行と検証: 「テストが保存されたか」だけで満足せず、生成されたテストを実行して正しさを確認する必要があります（保存≠正解）。
3. モデルと言語の組み合わせによる評価: モデルの性能ティアや言語（特に Rust のような厳格な型システムを持つ言語）によってテスト処理の挙動が異なるため、自社のコードベースと特定のモデル・言語の組み合わせで挙動を検証する必要があります。
4. CI/CD への反映: 生成コードの評価には、単一のファイルレベルのパス/フェイルだけでなく、個々のテストの粒度での評価と、複数回の実行（非決定性の考慮）を取り入れるべきです。

結論として、AI 支援開発の時代において、テストをどこに配置するかは、AI の性能を最大限に引き出すための重要な設計判断となります。