AI駆動開発で増えるファイルを、共有用と個人用に分ける

こんにちは。AlgomaticでソフトウェアエンジニアをしているGo（@53able）です。

AIエージェントに調査や実装を任せると、実装計画、調査メモ、検証ログ、スクリーンショット、記事の下書きなど、ソースコード以外のファイルが増えます。

こうしたファイルをリポジトリ内に置くと、エージェントがソースコードと一緒に読み書きできます。作業を中断しても、残した計画やメモから再開できます。しかし、そのすべてをチームの成果物としてGitへ記録する必要はありません。

この記事では、チームの.gitignoreを変更せず、現在のリポジトリだけで個人用ファイルを除外する方法を説明します。

今回の要件は、次の三つです。

• outputs/を、このリポジトリに関する個人用の成果物置き場として使います

• チームの.gitignoreは変更しません

• 自分が扱うほかのリポジトリには影響させません

この条件には、.git/info/excludeが適しています。今回は次の1行を追加しました。

/outputs/

これで、現在のリポジトリ直下にあるoutputs/は、通常の未追跡ファイルとしてgit statusへ表示されなくなります。この設定はコミットされないため、ほかの開発者やリポジトリには伝わりません。

Gitの除外ルールは、まだ追跡されていないファイルを、通常のgit statusやgit addの対象から外す仕組みです。Gitの公式ドキュメントにあるとおり、すでに追跡されているファイルには効きません。

また、.git/info/excludeは個人用ファイルを安全に保管する機能ではありません。ファイルを削除せず、Gitの日常的な操作から見えにくくするだけです。バックアップや機密情報の保護は、別に考える必要があります。

• AI駆動開発では、コード以外の作業ファイルが増えます

• .gitignoreは、チームで共有する「追跡しない方針」です 三つの除外設定を共有範囲で使い分けます

• 個人成果物を除外する前に、寿命と共有範囲を確認します

• .git/info/excludeはどこにあるのか

• /outputs/のスラッシュには意味があります

• 複数の除外ルールには優先順位があります

• 並列エージェントとworktreeでは、共有範囲に注意します

• 追跡済みファイルには効きません

• 除外ルールは、バックアップや機密保護の代わりにはなりません

• Gitの歴史を見ると、excludeとignoreが混在する理由が分かります

• まとめ

• エンジニアを募集しています！

• Sources

ビルド結果やIDE設定などの未追跡ファイルは、AIエージェントを使う前から存在していました。AI駆動開発では、そこにエージェントの作業記録が加わります。

現在のコーディングエージェントも、計画、セッション履歴、ログ、チェックポイント、作業ファイルをコードとは分けて扱っています。たとえば、GitHub Copilot CLIの公式資料には、セッションごとのイベントログ、計画、チェックポイント、成果物を保存する構成が記載されています。OpenAIのCodex worktree資料でも、Git worktreeを使って作業を分離し、追跡済みファイルと無視されたローカルファイルを分けています。

保存先は、「AIが作ったか」ではなく「誰が何のために使うか」で決めます。

AIエージェントは、短時間に多くのファイルを作れます。出力先をoutputs/のような専用ディレクトリへまとめておけば、ソースコードの差分へ混ざりにくくなります。.git/info/excludeは、そのディレクトリを現在の作業環境だけで無視したい場合に使えます。

ただし、エージェントが作ったファイルでも、実装の前提となる計画や、PRの合否を支える検証結果は、個人用とは限りません。チームの判断や再現に必要になった時点で、Git、PR、CIの成果物、共有ストレージなど、ほかのメンバーが参照できる場所へ移します。

.gitignoreは、チームで共有する「追跡しない方針」です

.gitignoreを考えるとき、CI/CDはよい出発点になります。クリーンなcloneからビルドやテストを再現できるか、コマンドの実行後に不要な差分が残らないかを考えると、追跡する必要のない生成物を見つけやすくなるためです。

ただし、.gitignoreをCI/CD向けの設定だけに限定すると、対象を狭く捉えすぎます。.gitignoreは、開発者、レビュー担当者、CI/CD、リリース工程を含め、リポジトリを利用する人と仕組みに共通する除外ルールです。

たとえば、テストのカバレッジ出力やローカルサーバーのログは、CI/CDが生成しない場合でも、チーム全員が追跡しないのであれば.gitignoreへ書けます。反対に、CI workflow、デプロイ設定、lockfile、再現手順などはCI/CDと深く関係しますが、共有と再現に必要なのでGitで追跡します。

判断基準は、次のように整理できます。

.gitignoreには、標準的な開発、検証、ビルド、CI/CD、リリース工程で共通して発生し、Gitで共有・レビューする必要がないファイルを記述します。

追跡が不要だと判断したら、次に除外ルールを誰と共有するかを決めます。

三つの除外設定を共有範囲で使い分けます

Gitには、用途の異なる複数の除外設定があります。

Gitの`gitignore`ドキュメントは、リポジトリ固有でありながら、ほかのcloneへ共有する必要がないパターンを、$GIT_COMMON_DIR/info/excludeへ置くよう案内しています。

ここでいう「現在のclone」は、一つの作業ツリーだけを意味しません。同じ共通Gitディレクトリに属するlinked worktreeがある場合、.git/info/excludeはそれらにも適用されます。

今回のoutputs/は、この作業環境だけで必要です。ほかのリポジトリへ同じルールを適用する必要もないため、.git/info/excludeを選びました。

個人成果物を除外する前に、寿命と共有範囲を確認します

.git/info/excludeを使うと、個人の都合をチームの設定へ混ぜずに済みます。ただし、設定はコミットされないため、ほかの開発者には見えません。新しくcloneした環境にも引き継がれません。

AIエージェントが作るファイルには、現在は個人用でも、後から検証の証拠として必要になるものがあります。生成時に、次の三つへ分けておくと判断しやすくなります。

• チームで共有します：コード、テスト、共通の指示、再現手順

• 個人で一時的に保持します：調査メモ、候補案、再生成できるレポート

• リポジトリ外で保管します：機密情報、長期保存したい個人記録、大容量データ

.git/info/excludeに適しているのは、二つ目のファイルです。次の条件を満たすか確認します。

• 現在のリポジトリに固有で、ほかのリポジトリには適用しません

• ほかの開発者へ同じ除外ルールを配る必要がありません

• ビルド、テスト、レビュー、CIの再現性に影響しません

• 消失しても再生成できる、または別の場所にバックアップがあります

• まだGitに追跡されていません

• 機密情報の保護を除外ルールへ頼っていません

今回のoutputs/は、個人用の文章や調査結果を一時的に置く限り、この条件に合います。ただし、保存した検証結果がPRの承認根拠になった場合は、個人用のままにせず、チームが確認できる場所へ移します。

.git/info/excludeはどこにあるのか

通常のリポジトリでは、.git/ディレクトリにGitの管理情報が保存されています。コミットの実体、ブランチの参照、リポジトリ固有の設定などです。info/excludeも、この管理情報に含まれます。

Git repository layoutでは、info/excludeを、git statusやgit addなどが参照する除外パターンの保存場所として説明しています。

ただし、.git/info/excludeというパスを常に決め打ちできるとは限りません。linked worktreeなどでは、Gitディレクトリの配置が通常のcloneと異なるためです。スクリプトから設定ファイルを扱う場合は、Gitにパスを問い合わせる方が確実です。

git rev-parse --git-path info/exclude

現在の環境でこのコマンドを実行したところ、.git/info/excludeが返りました。

/outputs/のスラッシュには意味があります

追加したパターンは/outputs/です。

先頭の/は、リポジトリのルート、つまり最上位ディレクトリを基準にする指定です。末尾の/は、通常ファイルではなくディレクトリを対象にする指定です。

outputs/          # 無視されます
src/outputs/      # /outputs/ では無視されません

先頭の/を付けずにoutputs/と書くと、別の階層にある同名ディレクトリにもマッチする可能性があります。今回はリポジトリ直下だけを対象にするため、/outputs/としました。

複数の除外ルールには優先順位があります

Gitは、複数の場所から除外ルールを読み込みます。公式ドキュメントに記載された優先順位は、上から順に次のとおりです。

• 対応するコマンドへ直接指定したパターン

• 対象ファイルと同じディレクトリ、または親ディレクトリにある.gitignore

• $GIT_COMMON_DIR/info/exclude

• core.excludesFileで指定したユーザー共通ファイル

同じ優先度では、最後にマッチしたパターンが結果を決めます。

設定が意図どおりに働かない場合は、次のコマンドで判定理由を確認できます。

git check-ignore -v outputs/<確認したいファイル>

-vを付けると、マッチした設定ファイル、行番号、パターン、対象パスが表示されます。この出力形式は、`git check-ignore`の公式ドキュメントで確認できます。

今回のファイルでは、次の結果になりました。

.git/info/exclude:19:/outputs/  outputs/git-info-exclude.md

これは、.git/info/excludeの19行目にある/outputs/が、対象ファイルへ適用されたことを示します。

git status --short --ignored=matchingでも確認したところ、outputs/には!!が付きました。!!は、無視されているパスを表します。

並列エージェントとworktreeでは、共有範囲に注意します

複数のAIエージェントを同時に動かす場合、ファイルの衝突を避けるためにGit worktreeを使うことがあります。worktreeは、一つのリポジトリから複数の作業ツリーを作り、それぞれで異なるブランチや変更を扱う仕組みです。Codexの公式資料でも、並列作業を分離する方法としてworktreeを説明しています。

.git/info/excludeの正確な参照先は、$GIT_COMMON_DIR/info/excludeです。linked worktreeは、一部のGit管理情報を共有します。そのため、この除外設定は一つのworktreeだけでなく、同じ共通Gitディレクトリに属するすべてのworktreeへ適用されます。

エージェントごとに出力を整理する場合は、一つのディレクトリへすべて置くのではなく、次のように保存先を分けると確認しやすくなります。

outputs/<run-id>/
outputs/<agent-name>/

ただし、保存先を分けても.git/info/exclude自体は共通です。除外ルールまで完全に分ける必要がある場合は、別のclone、専用sandbox、リポジトリ外の一時ディレクトリを検討します。

追跡済みファイルには効きません

除外ルールは、追跡済みファイルをGitの管理対象から自動的に外しません。すでにコミット済み、またはgit addでインデックスへ登録済みのファイルは、.git/info/excludeへ追加しても追跡されたままです。

追跡状態は、次のコマンドで確認できます。

git ls-files --error-unmatch outputs/<確認したいファイル>

今回確認したMarkdownファイルは未追跡であり、.git/info/excludeの対象になっています。

追跡済みファイルを手元に残したままGitの管理対象から外すには、別の操作が必要です。その変更はチームにも影響する可能性があるため、意図を確認せずにgit rm --cachedを実行しないでください。

除外ルールは、バックアップや機密保護の代わりにはなりません

無視されたファイルは、Gitの変更履歴へ保存されません。cloneを削除した場合や端末が故障した場合は、ファイルを失う可能性があります。

また、除外ルールはファイルへのアクセスを制限しません。git add -fを使えば強制的に追加でき、別のツールがファイルを読み取ることもできます。トークン、秘密鍵、顧客データなどは、除外ルールへ頼らず、最初からリポジトリ外の適切な保管場所へ置く必要があります。

git cleanを使う場合にも注意が必要です。オプションによっては、無視されたファイルも削除対象になります。消失すると困る成果物をoutputs/へ置く場合は、別の場所にも保存してください。詳しい挙動は、Gitの`git clean`ドキュメントで確認できます。

Gitの歴史を見ると、excludeとignoreが混在する理由が分かります

Gitでは、excludeとignoreという二つの言葉が使われています。ファイル名は.gitignoreですが、設定名はcore.excludesFileで、ローカル設定のパスもinfo/excludeです。

Gitのメンテナーが2009年に説明した開発メーリングリストの記録によると、開発初期にはexclude patternsという言葉が先に使われていました。

• 2005年4月、フラットな除外パターンを扱う仕組みが追加されました

• 2005年7月、ディレクトリ単位の除外パターンを扱えるようになりました

• 2005年8月、作業ツリー内のファイル名として.gitignoreが定着しました

内部で使われていたexcludeという言葉に、利用者向けの.gitignoreという名前が後から加わりました。その名残が、現在の用語にも残っています。

2006年のGit本体のドキュメント更新では、例示を.git/ignoreから.git/info/excludeへ変更し、git status、git add、git rm、git cleanが参照することを明文化しています。

.gitignoreと.git/info/excludeは、目的の異なる別々の仕組みではありません。同じ除外パターンの仕組みに対して、異なる共有範囲からルールを渡すためのファイルです。

まとめ

AI駆動開発では、コードだけでなく、計画、調査、検証、レビューの記録もファイルとして残ります。すべてをコミットすると、プロダクトの変更と個人の作業過程が混ざります。反対に、共有すべきファイルまで個人用として扱うと、チームが判断の根拠や作業再開の手掛かりを参照できません。

.git/info/excludeが適しているのは、チームへ共有せず、そのリポジトリの作業環境だけで使うファイルです。チームの再現性に影響しないことに加え、消失しても再生成できるか、別の場所に保管されていることも確認します。

/outputs/

この設定では、リポジトリ直下のoutputs/だけを通常の追跡候補から外せます。ただし、追跡済みファイルには効きません。バックアップやアクセス制御の代わりにもなりません。

保存先に迷った場合は、次の順番で判断します。

• チームで共有・レビューするファイルは、Gitで追跡します

• チーム全員が追跡しないファイルは、.gitignoreへ書きます

• 現在のリポジトリ環境だけで使う一時的な個人ファイルは、.git/info/excludeへ書きます

• 自分のすべてのリポジトリで無視するファイルは、core.excludesFileへ書きます

• 機密情報や大容量データは、リポジトリ外の適切な保存先へ置きます

この判断基準は、CI/CDに関係するファイルにも当てはまります。共有と再現に必要な設定やスクリプトはGitで追跡します。再生成できるログ、キャッシュ、ビルド成果物は、Gitで共有する必要がなければ除外します。

保存先を決める基準は、AIが生成したかどうかではありません。誰が使うのか、再現に必要か、失ったときに困るかを確認します。

エンジニアを募集しています！

ここまで読んでいただきありがとうございました！

Algomatic では、「AI革命で人々を幸せにする」をミッションに、変化の速い領域でも 学びや試行錯誤を続けられる エンジニアを募集しています。

もし少しでもご興味をお持ちいただけましたら、カジュアル面談に足を運んでいただけるとうれしいです！

Sources

• Git — gitignore Documentation

• Git — gitrepository-layout Documentation

• Git — git-check-ignore Documentation

• Git — git-clean Documentation

• GitHub Docs — Copilot CLI configuration directory

• GitHub Docs — Managing and tracking coding agent sessions

• OpenAI Developers — Codex worktrees

• OpenAI Developers — Codex best practices

• Git開発メーリングリスト — exclude patternsと.gitignoreの成立順序

• Git commit ff4d780 — Documentation about exclude/ignore files