AIエージェントを複数使っていると、便利な反面、だんだん困ることがあります。

それは、前のエージェントが何を見て、何を判断して、どこまで作業したのかが散らばることです。

Codexでコードを直し、Claude Codeで確認し、ChatGPT側で方針を整理し、また別のエージェントがVPSやブログを見る。こういう運用を続けていると、会話ログだけでは足りなくなってきます。

そこで今回は、ローカルに置いていたエージェント用の作業ハブを、Private GitHubリポジトリとして同期してみました。

この記事は、その実録です。

「AIが自律的に全部連携してくれるようになった」という話ではありません。
実際にやったのは、もっと地味で、もっと大事なことです。

  • 引き継ぎ用の文書をGitHubから読めるようにした
  • 秘密情報や重いログを入れないように除外した
  • 他のAIエージェントにIssueでレビュー依頼を出した
  • 指摘を受けて、READMEやインデックスを改善した

派手ではありませんが、こういう地味な整備は、AIを長く使うほど効いてきます。

何を解決したかったのか

一番の目的は、作業の文脈を失わないことです。

AIエージェントとの作業では、次のような情報がよく発生します。

  • どのリポジトリを触ったか
  • 何を調査したか
  • 何を変更したか
  • どのコマンドで確認したか
  • どこは触ってはいけないか
  • 次のエージェントに何を見てほしいか

これらが会話ログだけに残っていると、次に別のAIを使ったときに再確認が増えます。

もちろん、会話ログを読み返せば分かることもあります。でも、作業用の文書として残しておくほうが、次のAIにも人間にも優しいです。

そこで、ローカルの共有作業場所にあった handoff や AGENTS.md のような文書を、Private GitHubリポジトリに置くことにしました。

ただし、丸ごとアップロードはしなかった

ここはかなり大事です。

ローカルの作業ハブには、引き継ぎ文書だけでなく、ログ、バックアップ、生成物、一時ファイルなども混ざっていました。

そのままGitHubに上げると危ないものが入る可能性があります。

たとえば、次のようなものです。

  • APIキーやトークンの痕跡
  • SSH鍵や認証ファイル
  • VPSや取引所まわりの生ログ
  • 重いzipやモデルファイル
  • 個人的なメモや検証用の一時ファイル

Privateリポジトリであっても、こういうものは基本的に入れないほうが安全です。

今回は、最初にファイル数や大きいファイルを確認し、秘密情報っぽい文字列が混ざっていないか検索しました。その結果、古いバックアップやartifact側に、公開対象にしたくない候補がかなりあることが分かりました。

なので、最初の同期対象は絞りました。

Phase 1で入れたもの

最初にGitHubへ入れたのは、主に次のような軽量な文書です。

  • README.md
  • AGENTS.md
  • handoff/ 配下の引き継ぎメモ
  • 軽量な補助スクリプト
  • GitHub公開用の方針メモ

逆に、次のディレクトリは除外しました。

  • artifacts/
  • backup/
  • logs/
  • scratch/
  • 独立したGitリポジトリとして存在していた研究用フォルダ

この判断は、かなり保守的です。

でも、AIエージェントの連携ハブは「何でも入れる場所」ではなく、次の作業者が安全に文脈を読める場所にしたかったので、このくらい絞ってちょうどよかったと思います。

Private GitHubにした理由

今回のリポジトリはPrivateにしました。

理由は単純で、引き継ぎ文書にはローカルパスや運用文脈が含まれるからです。

たとえば、Windowsのローカルパス、作業ディレクトリ名、VPSやbot運用の概要、AIエージェント向けの注意書きなどです。これらは公開記事にそのまま載せるものではありません。

一方で、Private GitHubに置くと、GitHub連携できるAIやツールから参照しやすくなります。

ここで大事なのは、Privateだから何でも入れていいわけではないことです。

今回は、公開用の方針メモにも次のような注意を入れました。

これはPublic公開方針ではなく、Privateリポジトリ向けのpublish planである。もしPublic化するなら、別途redaction passが必要。

この一文を入れておくと、将来うっかり「これ公開できるんじゃない？」となったときに、立ち止まりやすくなります。

他のAIにIssueでレビューしてもらった

リポジトリを作ったあと、他のAIエージェントにも確認してもらうため、GitHub Issueを立てました。

お願いした観点は、だいたいこんな内容です。

  • READMEとAGENTSから迷わず辿れるか
  • handoffの粒度は引き継ぎに使いやすいか
  • 除外方針は安全か
  • Privateでも入れないほうがいい情報が残っていないか
  • GitHubだけ読めるAIにとって入口が足りているか
  • 独立した研究用フォルダをどう扱うべきか

Claude Code側からは、Private運用ならローカルパスが残っていても許容できるが、Public化時は注意、という確認がありました。

ChatGPT側からは、GitHubだけ読めるエージェント向けに、ローカルパスを読めない場合のfallbackを書いたほうがいい、という提案がありました。

これはかなり実務的でした。

ローカルにいるAIは C:\Users\... や H:\... を読めるかもしれません。でも、GitHub経由で見るAIは、そのパスの実体にはアクセスできません。

だから、次のようなルールを追加しました。

GitHubリポジトリは読めるがローカルパスを読めない場合、ローカルファイルを読んだと主張してはいけない。読める範囲は、リポジトリにコミット済みのREADME、AGENTS、FILE_INDEX、handoffだけである。

これは地味ですが、かなり大切です。

AI運用で危ないのは、「見ていないものを見たように扱う」ことです。そこを防ぐための一文です。

FILE_INDEXを追加した

GitHub上で検索が効くとはいえ、AIやツールによってはリポジトリ全体のtreeをうまく辿れないことがあります。

そこで、トップレベルに FILE_INDEX.md を追加しました。

これは、簡単に言うと「最初に読むべきファイル一覧」です。

中身はこんな感じです。

  • README.md は全体概要
  • AGENTS.md は運用ルール
  • GITHUB_PUBLISH_PLAN.md はPrivate運用と除外方針
  • 最近のhandoffはどれか
  • 移行・バックアップ関連はどこか
  • GitHubに載せないlocal-only領域はどこか

人間にとっても便利ですが、AIにとってもかなり便利です。

「このリポジトリ、まず何を読めばいいの？」に答えられるからです。

バックアップスクリプトの小さなバグも見つかった

レビューの中で、バックアップスクリプトの -IncludeLogs オプションについても指摘がありました。

スイッチとしては「ログも含める」指定があるのに、グローバルな除外正規表現で logs ディレクトリを常に除外している可能性があったのです。

これは大きな事故ではありませんが、実装としては気持ち悪い状態です。

そこで、次のように直しました。

  • -IncludeLogs がないときだけ通常ログを除外する
  • ただし、重いDBログや危険そうなログは引き続き除外する

修正後は、-WhatIf -IncludeLogs で実行確認しました。

こういう小さい不整合は、放っておくと後で「オプションを付けたのになぜ含まれない？」という混乱になります。早めに直せてよかったところです。

今回やらなかったこと

今回、あえてやらなかったこともあります。

まず、ローカルの作業ハブを丸ごとGitHubに上げることはしませんでした。

重いファイルや秘密情報の可能性があるためです。

次に、研究用の独立フォルダは、外側のリポジトリには入れませんでした。中に別の .git があり、無理に入れると「埋め込みGitリポジトリ」扱いになってしまうためです。

これも、後で別Privateリポジトリにするか、必要な部分だけ抜き出すほうが安全だと判断しました。

また、AIエージェントが勝手に全作業を判断して進めるような自動化もしていません。

今回の目的は、あくまで引き継ぎの見通しをよくすることです。

実際にやって良かったこと

やってみて良かったのは、次の3つです。

  1. 作業ログの置き場所がはっきりした
  2. 他AIからのレビューをIssueとして受け取れるようになった
  3. 「読めるもの」と「読めないもの」を明示できた

特に3つ目は重要です。

AIエージェントを複数使うと、誰がどこまで見えているかが曖昧になりやすいです。

ローカルAIはローカルパスを読める。
GitHub経由のAIはリポジトリ内だけ読める。
チャットだけのAIは、貼られた情報しか読めない。

この差を曖昧にすると、引き継ぎの精度が落ちます。

だからこそ、GitHub-only fallbackのようなルールを置いておく意味があります。

注意点。Privateでも油断しない

Private GitHubは便利ですが、万能の秘密箱ではありません。

少なくとも、次のものは入れないほうがいいです。

  • APIキー
  • トークン本体
  • SSH秘密鍵
  • OAuthセッション
  • 取引所や証券口座に関わる認証情報
  • 生のVPS接続情報
  • 個人情報や健康ログの詳細
  • 家計の具体的すぎる数字
  • 公開できないスクリーンショットや生成物

Privateでも、後で権限を増やしたり、別ツールと連携したり、うっかりPublic化を検討したりする可能性があります。

だから、最初から「Privateでも入れないもの」を決めておくほうが安全です。

まとめ

今回やったことは、派手なAI自動化ではありません。

でも、複数のAIエージェントを実務で使うなら、かなり効く整備でした。

  • ローカルの作業ハブをPrivate GitHubに同期した
  • 重いファイルや秘密情報候補は除外した
  • 他AI向けにレビューIssueを作った
  • 指摘を受けてREADME、AGENTS、FILE_INDEXを改善した
  • GitHubだけ読めるAI向けのfallbackも書いた

AIを使うほど、「AIに何をさせるか」だけでなく、AI同士が迷わない地図をどう置くかが大事になります。

その地図は、いきなり完璧でなくていいです。

まずはREADME、AGENTS、handoff、FILE_INDEX。
そして、秘密情報を入れないための .gitignore と確認手順。

このくらいから始めるだけでも、次のAIに渡す作業の見通しはかなり良くなります。

大事なのは、AIに任せきることではなく、人間が確認できる形で、AIが迷いにくい道を作ることだと思います。