【ITニュース解説】AI Code Provenance: How to Track AI-Generated Code in Git

ソフトウェア開発の世界では、コードの変更履歴を管理するためにGitというツールが広く使われている。誰が、いつ、何を、どこで変更したのか、といった情報をGitが記録することで、開発者はプロジェクトの状態を把握し、協力して作業を進めてきた。しかし、近年AI（人工知能）がコード生成や修正を手助けするようになり、この従来のGit履歴だけでは捉えきれない、新しい問題が生じている。

開発者がAIの助けを借りてコードを書くことが日常的になると、「このコードは人間が手書きしたのか、それともAIが生成したのか？」「どのAIモデルを使ったのか？」「AIにどんな指示（プロンプト）を与えた結果、このコードが生まれたのか？」といった疑問が重要になってくる。Gitは最終的なコードの変更だけを記録し、その変更に至るまでのAIとのやり取りや、AIがどのようにコードを生成・修正したかというプロセスは記録しない。この情報が欠けている状態を「AIコードプロベナンス」が埋める役割を果たす。

AIコードプロベナンスとは、AIを使ってコードがどのように作られたか、そしてそのAIによる活動が最終的なソースコードにどう結びついているかを記録することである。これは単に「このコードはAIが書いたように見えるか？」というAIコード検出とは異なる。プロベナンスは「このコードを生成したAI活動は何か？」という、より具体的で実用的な問いに答えることを目的とする。開発現場では、AIの提案をたまに利用する段階から、Claude Code、Cursor、Codex、Gemini CLIといったツールを使ったAI主導のワークフローへ移行しつつあるため、AIが生成したコードを追跡する能力はますます重要になる。

AIコードプロベナンスがなぜ重要なのか、いくつかの側面から説明する。

まず「コードレビュー」の場面で役立つ。AIの助けを借りて大規模なプルリクエスト（コード変更の提案）が行われた場合、変更されたコードを見るだけでは、開発者がAIに何を求めたのか、AIがどのような仮定に基づいて変更を行ったのかが分かりにくい。関連するプロンプトやAIセッションの記録があれば、レビュアーはコードの意図と背景を理解しやすくなる。AIコードプロベナンスはレビューを置き換えるものではなく、それを補完する情報を提供する。

次に「デバッグ」においてもその価値を発揮する。もし数週間前に導入されたバグが見つかり、Gitの履歴が特定のコミットと開発者を指しても、その開発者がどのAIツールを使い、どのようなプロンプトでコードを生成したかを覚えているとは限らない。AIコーディング履歴がコードと結びついていれば、エンジニアは影響のあるコードをAIセッションやプロンプトまでたどることができ、どのように実装されたかを再構築して、バグの原因究明を効率化できる。

「セキュリティと監査」も重要な側面だ。AIは設定ファイル、認証フロー、インフラ定義など、コードベースの機密性の高い部分を変更する可能性がある。AIコードの追跡可能性は、開発者、AIエージェント、モデル、プロンプト、影響を受けるファイル、そして最終的なコードの間にはっきりとした経路を提供する。AIが生成したコードを本質的に危険視するのではなく、その起源を検査可能にすることが目標だ。これにより、後で特定の機能がどのように実装されたかを問われた際に、コミットハッシュだけでは不十分だった監査証跡が補完される。

さらに「コスト管理」にも貢献する。AIコーディングツールの利用コストは、それがどの開発作業に貢献したのかが分からなければ、その効果を評価しにくい。AIコーディングセッションを実際の開発作業と結びつけることで、「モデルにいくら費やしたか」だけでなく、「その費用でどのような作業がサポートされたか」を明確にできるようになる。

効果的なAI生成コードの追跡は、すべての行動を永遠に保存する必要があるわけではない。重要なのは、関連する開発コンテキストを、リポジトリにコミットされたコードと結びつけることである。Gitは引き続きソースコードの記録システムであり、AIコードプロベナンスはその記録を、コミット以前に作成されたコンテキストで拡張する。

AIコードをGitで追跡する方法として、開発者にAIの使用をコミットメッセージに書かせたり、チャット履歴を別途保存したり、プルリクエストにラベルを付けたりする方法が考えられる。しかし、これらの方法では情報が分散してしまい、後で変更を再構築するのが難しくなる。より有効なアプローチは、開発中にAIとのやり取りを捕捉し、それらのやり取りと生成されたコードとの関係を維持することだ。

Originのようなツールは、既存のGitワークフローにAIコーディング履歴のレイヤーを追加することで、この問題に対処する。開発者が通常使うAIコーディングエージェント（Claude Code、Cursor、Codex、Gemini CLI、GitHub Copilotなど）を使い続ける中で、プロンプトテキスト、モデル情報、変更されたファイル、差分、トークン使用量、コスト、セッションメタデータといった情報を自動的に捕捉する。その結果、コードの出所情報がリポジトリに直接結びつき、後でGitと照合する必要がある個別の履歴として存在することはない。

従来のGitのgit blameコマンドは、「この行を最後に変更したコミットはどれか？」という問いに答える。AIを使った開発では、「この行を生成したAIとのやり取りはどれか？」という新たな質問が加わる。Originは行レベルでAIの出所を特定する機能を提供し、開発者がソースコードからそれに関連するプロンプトやAIセッションへとたどれるようにする。例えば、origin why src/auth.ts:42のようなコマンドを使うと、特定のコード行に関連するAIエージェント、モデル、プロンプトなどのコンテキストを表示できる。これにより、単にどの開発者がファイルをコミットしたかを知るよりも、はるかに詳細な情報を得てデバッグを進めることができる。

また、AIコーディングセッションを再構築する機能も重要だ。特定のコード行の調査だけでなく、「AIエージェントがこのタスクで実際に何をしたのか？」という広範な疑問に答えることができる。セッション履歴は、プロンプト、影響を受けたファイル、モデル情報、中間的な変更、そして最終的な結果に至るまでのコンテキストを示す。Originを使えば、開発者は個人の記憶やローカルのチャット履歴に頼ることなく、捕捉されたセッションを検査できる。OriginはGitリファレンスとノートを使ってセッション情報をGitワークフローと共に保存し、AIコーディング履歴がリポジトリに結びついた状態を維持する。

Originを導入しても、既存のGitワークフローを変更する必要はない。これは、開発プロセスに追加の履歴レイヤーを加えるようなものだと考えれば良い。Originを有効にすることで、サポートされているAIコーディング活動の捕捉が開始される。開発者は引き続き普段使っているAIコーディングツールを利用し、Originがプロンプト、セッション、変更ファイル、モデル使用量、関連メタデータを自動で捕捉する。必要に応じて、セッション履歴でAIによるタスク全体をレビューしたり、行レベルの属性で特定のコードを調査したりできる。個人での利用では、自身のAI開発履歴（セッションのリプレイ、トークンやコストの追跡など）に焦点を当て、チームでの利用では、一元化された可視性、ポリシー管理、プルリクエストチェック、予算管理、監査ログなどを提供する。

ガバナンスが開発の妨げになっては意味がない。AIとのやり取りをすべて手動で記録したり、プロンプトをプルリクエストにコピーしたり、生成されたファイルにラベルを付けたりする作業は、継続が難しい。代わりに、自動的な捕捉と必要な場合の選択的な検査がより現実的である。開発者はGitと好みのコーディングエージェントを使い続け、レビュアーやセキュリティチームは、必要なときにだけより深いコンテキストを取得する。これは、AIエージェントの利用が増加するにつれて、ますます重要になる。

AIコーディングエージェントが登場しても、Gitの重要性が低下することはない。むしろ、その周辺のコンテキストがより重要になる。コミットは永続的なリポジトリの変更を記録し続け、プルリクエストは主要なレビューの場であり続ける。Git blameは、コードがいつ変更されたかを理解するのに役立つ。しかし、コミット以前には、プロンプト、モデル、AIコーディングセッション、中間変更、エージェントの判断、利用データといった別の履歴が存在する。AIコードプロベナンスは、これら二つの履歴を結びつける。これにより、エンジニアリングチームはGitを放棄したり、開発者に全く新しいワークフローを強いたりすることなく、AIが生成したコードを追跡できるようになる。レビュアー、開発者、セキュリティエンジニア、または監査担当者が「このコードはどこから来たのか？」と尋ねたとき、その答えはもはやユーザー名とコミットハッシュで終わることなく、コードを作成したAIセッションまでたどれるようになる。