副業・個人事業

AIエージェントにデジタル商品の原稿を渡す前に、Git worktreeで作業場所を分ける見本を試した

約7分で読めます
#AI副業#デジタル商品#AIエージェント#Git#Git worktree
AIエージェントにデジタル商品の原稿を渡す前に、Git worktreeで作業場所を分ける見本を試した

販売前のテンプレートを直している最中に、別の依頼で説明文も直したくなることがあります。AIエージェントへ修正を頼む場面も同じです。1つのフォルダでブランチを切り替えると、まだ見ていない原稿が作業画面から消えてしまいます。見落としたくないのは、原稿の置き場所です。

そこで、販売用の原稿とレビュー用の修正を別フォルダに置く見本を作りました。使ったのはGitに標準で入っているgit worktreeです。空のGitリポジトリで、作業ツリーがどう並ぶかを確かめました。対象は見本だけ。実在する商品、販売実績、顧客データは使っていません。

フォルダを増やす前に、ぶつかる場所を決める

デジタル商品の原稿、配布用ZIPのREADME、販売ページの説明文は、同じリポジトリに置きやすいファイルです。AIエージェントには「この説明を短くして」と頼み、人は販売条件を確認します。どちらも単独なら簡単です。

問題は、同じ作業フォルダで別々の変更を始めるときです。git switchは作業ツリー、つまり今開いているファイル群を切り替えます。未コミットの変更が残っていれば、Gitは切り替えを止めることがあります。強引に退避や破棄を選ぶと、販売前の原稿を取り違える入口になります。

git worktreeは、同じリポジトリの履歴を共有しつつ、別の作業ツリーを追加する機能です。商品そのものを複製して管理する話ではありません。変更の置き場所を分けるための機能です。

[商品リポジトリ]
       │
       ├─ main
       │   └─ 販売前の原稿を確認する作業フォルダ
       │
       └─ content/catalog-copy
           └─ AIエージェントへ渡すレビュー用フォルダ

この分け方なら、AIへ渡す範囲をレビュー用フォルダに限定できます。人が販売条件を確認しているフォルダを、エージェントの作業対象から外せます。ただし、別フォルダは別の承認ではありません。公開前の確認と、変更内容のレビューは両方に必要です。

空のリポジトリで追加してみる

まずは一時ディレクトリで空のリポジトリを作り、mainからレビュー用ブランチを持つ作業ツリーを追加します。catalog-copyは見本のブランチ名です。実際には、商品名や目的が分かる名前へ置き換えます。

TMPDIR="${TMPDIR:-/tmp}"
mkdir -p "$TMPDIR/night-worktree-proof"
cd "$TMPDIR/night-worktree-proof"
git init -q
git config user.name 'draft-proof'
git config user.email '[email protected]'
git commit --allow-empty -qm 'initial sample'
git branch -M main
git worktree add -b content/catalog-copy ../catalog-copy main
git worktree list
printf 'CURRENT_BRANCH='; git -C ../catalog-copy branch --show-current
git status --short

最後の3つの確認コマンドの実行結果は次のとおりでした。作業ツリーのパスは、一時ディレクトリとして表記しています。

$TMPDIR/night-worktree-proof  5f51c66 [main]
$TMPDIR/catalog-copy          5f51c66 [content/catalog-copy]
CURRENT_BRANCH=content/catalog-copy

git worktree listには、mainとcontent/catalog-copyが別の場所として並びました。CURRENT_BRANCHの行も、追加したフォルダがレビュー用ブランチを見ていることを示しています。作業ツリーはmainの中ではなく隣の../catalog-copyに置いたので、main側のgit status --shortは何も出力しません。mainの中に作ると、main側に?? catalog-copy/が未追跡として表示されます。

ここで最初に想定していた失敗は、既存のフォルダでgit switch content/catalog-copyを繰り返すことでした。worktreeを追加すると、その切り替え自体が不要になります。私は、フォルダが増えると管理対象も増えるので大げさではないかと考えていました。しかし、確認中の販売原稿を画面から退避しない利点は、少人数の作業でも分かりやすいと感じます。

AIに渡す範囲を小さくする

追加した../catalog-copyへ移動したら、AIエージェントには対象を具体的に渡します。例えば、テンプレートの説明文だけを見直すなら、依頼の対象をそのファイルに絞ります。

cd ../catalog-copy
printf 'BRANCH='; git branch --show-current
git status --short

この確認で、AIが触る前に「どのブランチか」と「未コミットの変更があるか」を人が読めます。出力が空であれば、git status --shortは変更なしを表します。

BRANCH=content/catalog-copy

実行前に決めるのは、次の3点で十分です。

  • 販売用の確認を続けるフォルダは、AIの作業対象に含めない
  • AIへ渡すフォルダでは、対象ファイルと完了条件を依頼文に書く
  • 変更後は、git diffで差分を人が確認してからコミットする

この順序は、AIの出力が正しいと仮定しないためのものです。商品説明の言い換えが良く見えても、価格、返金条件、配布URLまで変わっていないかは別に見ます。

worktreeを増やしたときの小さな落とし穴

同じブランチを、複数の作業ツリーで通常は同時にチェックアウトできません。Gitはブランチごとの作業場所を記録し、誤った場所で同じ変更を進める事故を避けようとします。

もう1つは、作業が終わったフォルダを放置することです。git worktree listを定期的に見ると、どのフォルダがどのブランチに対応するかを確かめられます。不要になった作業ツリーを削除する前には、そのフォルダでgit status --shortを実行し、未コミットの原稿がないことを確認します。

AIエージェントに任せるほど、作業場所の名前と境界が重要になります。作業ツリーを分けるだけで品質が上がるわけではありません。それでも、販売前の原稿を守りながら、小さな修正を並行に試せる状態は作れます。

用語

用語この見本での意味
作業ツリー今開いているファイル群と、そのファイルを置くフォルダです。
ブランチ変更の履歴を分けるための名前付きの流れです。
Git worktree1つのGitリポジトリに追加できる、別の作業ツリーです。
git status --short変更されたファイルを短い形式で表示する確認コマンドです。

出典

この記事をシェア
hibana
この記事を書いた人
hibana

技術ブログを運営しています。日々の学びや発見を発信中。

関連記事