この記事は2026年7月時点のモデルの能力と製品の状況を前提に書いています。モデルの能力が変われば、前提も結論も変わります。

先に結論だけ

コーディングエージェントが仮説の立案・最適化・テスト作成を自発的にこなす現在、最適化を任せる処理では、ソースコードを「動作の完全な定義」ではなく「人間の意図した設計を宣言する要求仕様」として扱う手法が選べるようになりました。エージェントはこの意図を保つ限り挙動の細部を自分で決めてよく、越えてはならない一線だけをテストが契約として守ります。

その処理の周りでは、git管理の対象が正準ソース・最適化方針・テスト・生成コードの4点に広がります。この構成は現時点のモデル能力に合わせたスナップショットであり、能力が変われば構成も変わります。

はじめに

前回の記事「テストやルールになにを書くかは、なにをエージェントに任せるかで変わる」では、エージェントへ委任できる工程の境界線が動くとテストやルールといった知識の置き場所の設計も引き直しになる、という一般論を述べました。

この記事はその一断面です。2026年7月時点の能力を前提に置いたとき、「最適化をエージェントに任せるリポジトリ」は具体的にどのような形になるのか。そのなかでソースコードはどのような役割を担うのかを描きます。

対象読者は、コーディングエージェントにパフォーマンス改善やリファクタリングを任せ始めた開発者です。特定ツールのセットアップ手順と、テスト理論の背景説明は扱いません。

チューニングセッションで見えたソースコードの新しい役割

前回の記事と同じパフォーマンスチューニングのセッションを、今回は別の角度から振り返ります。処理速度の改善を目的に、「同じ結果を保てるならロジックごと変更してよい」と指定して、エージェント（モデルはFable）に作業を任せたセッションです。エージェントは改善の仮説を複数提案し、比較のための検証テストを自分で作成して、計測まで走り切りました。

前回はこの体験から「任せられる範囲の変化」を読み取りました。今回注目したいのは、そのとき既存のソースコードとテストがどんな役割を果たしたかです。

このセッションで、既存のソースコードはエージェントにとって「書き換える対象」ではなく「保つべき結果を定義する参照」でした。エージェントは既存実装の挙動から「同じ結果」の判定基準を導き、複数の実装仮説をその基準で比較しました。人間が最後まで握っていたのは、「同じ結果」を判定するテストが妥当かどうかの確認だけです。

このときのソースコードは、動作の完全な定義というより、「実現したいことを実行可能な形で書いた文書」として使われていました。この役割の変化を推し進めると、リポジトリの標準的な構成が変わって見えてきます。以下、順に説明します。

ソースコードは意図を宣言する要求仕様として扱える

従来の見方では、ソースコードに書かれたとおりの挙動が、そのまま動作の定義でした。

エージェントが最適化を担う構成では、人間が読み書きするソースコード（この記事では「正準ソース」と呼びます）に別の役割を与えられます。正準ソースを、人間の意図した設計を宣言する文書として扱えるようになります。エージェントは正準ソースを参照し、対象環境や性能要件に合わせた最適化コードを生成します。

この転換は、リポジトリのすべてのコードに一律で起きるわけではありません。要求仕様として扱われるのは、環境や性能要件に合わせた最適化を必要とする一部の処理だけです。最適化を必要としないコードは、従来どおり書かれたものがそのまま実行されます。1つのリポジトリの中に、要求仕様としての正準ソースと従来どおりのソースコードは混在します。

ソフトウェアテストの世界には、既存実装の出力を正解と見なして新実装を検証するゴールデンマスターと呼ばれる手法がありますが、正準ソースはこのゴールデンマスターの位置に立ちます。

ただし、古典的なゴールデンマスターと違い、挙動を完全に模倣することは求めません。保存すべきは意図された挙動であり、全挙動ではないからです。たとえば正準ソースにメモリリークがあったとして、最適化コードがそのリークまで忠実に再現する必要はありません。クラッシュやリークのように、誰が見ても異常とわかる挙動は、宣言しなくても「直してよい差異」として扱えます。

この線引きはプロジェクトの選択でもあります。「リークしてはならない」とテストに書けば、それは明示された仕様になります。書かなければ、直すかどうかはエージェントの裁量に委ねられます。明示しなかった挙動の扱いに余地が残るため、正準ソースは「動作の完全な定義」ではなく「要求仕様」となります。

テストは越えてはならない一線を守る契約になる

挙動の細部がエージェントの裁量に開かれた分、越えてはならない一線を守る仕組みが必要になります。それがテストです。テストを通過しない最適化は、どれだけ性能が良くても採用されません。この意味で、テストは人間とエージェントのあいだの契約として働きます。

契約としてのテストには、2つの条件があります。

境界の宣言であること: テストの役割は挙動の網羅ではなく、「どの差異は許されないか」の宣言です。数値の精度、外部へ公開するインターフェイス、応答の順序など、意図的に線を引くべき箇所だけを固定します
ゲートとして強制されること: CIやフックのように、通らなければマージできない仕組みに接続されて、はじめて契約になります。実行されないテストは助言にとどまります

網羅的に挙動を固定すると、契約はエージェントの提案を潰す足枷に変わります。本質と関係のない差異までテストが失敗し、最適化の余地を狭めるからです。テストは薄く、そのかわり一本ごとに「破られては困る理由」を持たせます。

最適化の方針も文書としてgit管理する

正準ソースとテストだけでは、エージェントに渡す情報として足りないものがあります。最適化の方針です。どの環境を対象にするか、実行速度とメモリのどちらを優先するか、どのトレードオフを許容するか。こうした知識は正準ソースにもテストにも書ききれません。

方針をその場かぎりのプロンプトで毎回指示していると、出力が再現しません。セッションが変われば消え、指示した本人にしか経緯がわからなくなります。

だから方針は文書としてリポジトリに置き、git管理します。方針の変更もコミットとして履歴に残り、レビューの対象になります。

置き場所には2つの形が考えられます。

正準ソースのコメントブロック: 方針がソースと同じファイルにあるため、参照が切れません。関数単位・モジュール単位の局所的な方針に向きます。一方で、方針だけを更新したい場合もソースファイルへの変更になり、ソースの変更履歴と方針の変更履歴が絡み合います
独立したMarkdownファイル: ソースの変更と独立に方針を更新できます。複数のファイルやモジュールにまたがる方針を1箇所に書けます。一方で、対応するソースが消えたり動いたりしても文書が残り続けるため、参照を保つ手入れが必要です

局所的な方針はコメントブロックへ、横断的な方針は独立ファイルへ、という使い分けが出発点になります。大事なのは、どちらの形でも方針がgit管理されて、レビューと履歴の対象になることです。

エージェントの生成コードもコミットして固定する

最適化コードはエージェントが出力します。そして、この出力もgit管理します。

ビルド成果物をgitに入れない、という従来の習慣からすると奇妙に見えるかもしれません。ビルド成果物を管理しなくてよいのは、同じソースから同じ結果が決定論的に再現できるからです。エージェントの出力はこの前提を満たしません。同じ正準ソースと同じ方針を渡しても、出力は毎回変わりえます。再現できないものは、採用した時点の実物をコミットして固定するしかありません。

生成コードを人間が直接修正しない、という規律も、ここから出てきます。生成コードに手を入れても、次の再出力で修正は消えます。直したいことがあるなら、修正すべきは上流です。意図が違うなら正準ソースを、守るべき一線が増えたならテストを、優先順位が変わったなら方針の文書を直して、エージェントに再出力させます。

再出力のきっかけは3つあります。正準ソースの変更、方針の変更、そしてモデルの世代交代です。同じ正準ソースと方針でも、より能力の高いモデルならより良い最適化コードを出せる可能性があります。生成コードは一度作って終わりの成果物ではなく、上流の変化に応じて作り直され続ける中間生成物になります。

この構成の利点は、人間が管理するものが正準ソースの側にまとまることです。最適化後のコードを人間が管理しようとすると読解の負担が大きく、かといって最適化前のソースだけを管理すると環境ごとの最適化を毎回やり直すことになります。正準ソースを起点にエージェントが生成コードを作り直す関係に置けば、人間が読み書きするのは正準ソース・最適化方針・テストの3点で済みます。

BunのZigからRustへの移植に見る4点の構成

この構成に近い形は、実例としてすでに観測できます。JavaScriptランタイムであるBunのコア部分は、GitHub PR #30412でZigからRustへ移植されました。追加行数は約100万行（1,009,257行）、PR作成は2026年5月8日、mainへのマージは5月14日です。BunチームはAnthropic傘下にあり、移植にはClaude Codeが大規模に使われています。

移植と最適化は目的が違いますが、「既存実装を参照として、等価な実装をエージェントが生成する」という構造は同じです。前回の記事では境界移動の実例としてこのPRを紹介しました。今回は、リポジトリに何が置かれたかという角度で見ます。

正準ソース（参照）: 既存のZig実装。PR本文には「アーキテクチャもデータ構造も元と同じ」とあり、Zig実装が保つべき設計の参照として機能しました
方針の文書: 移植の進め方を定めた移植計画書が、リポジトリ内の文書としてgit管理されています
契約としての検証: 既存テストスイートの通過に加え、移植計画書にはZig実装とRust実装の出力を突き合わせるshadow-diff検証が記されています
生成コード: Claude Codeが生成したRust実装が、コミットとしてmainへマージされています

4点がすべてリポジトリ上の管理対象になっている点が、この記事の構成と重なります。

一方で、生成コードの採用判断は人間側に残っています。2026年7月時点で、安定版はZigベースのv1.3.14のままで、Rust版はcanaryでのみ提供されています¹。契約を通過した生成コードを最終的に受け入れるかどうかは、まだ人間の仕事です。

この構成も現時点のスナップショット

正準ソース・最適化方針・テスト・生成コードの4点をgit管理する。この構成は普遍的な結論ではなく、2026年7月時点のモデル能力と権限設定に合わせたスナップショットです。前回の記事の言葉を使えば、委任の境界線が今の位置にあるあいだだけ成立する知識集約構造です。境界線が動けば、この構成も引き直しになります。

引き直しの方向も予測できます。今は「実行可能なソースコード」が意図を宣言する形式として使われています。実行できることには、挙動に曖昧さがないという利点があります。しかし同時に、意図していない偶発的な挙動まで固定してしまう、過剰な制約でもあります。

モデルの能力がさらに上がれば、参照として渡すものは実行可能なコードである必要すら薄れるかもしれません。処理系に似せて書かれた実行不可能なモックコードや自然言語の要求仕様書、その混合へ移っていく可能性があります。これは検証された事実ではなく、筆者の予測です。

おわりに

エージェントに最適化を任せ始めたら、リポジトリの構成を一度見直すことをオススメします。

ソースコードを「守るべき現物」として扱っているか、「宣言した意図」として扱っているか
越えてはならない一線はテストとして書かれ、ゲートで強制されているか
最適化の方針はその場かぎりのプロンプトで消えていないか
エージェントの出力は再現できる前提で捨てられていないか

4点が揃っているかの点検は、エージェントへの委任を「その場かぎりの作業依頼」から「リポジトリに根づいた分業」へ変える最初の一歩になると考えます。

安定版とcanaryの状況は2026年7月5日に確認した時点のものです。 ↩