AIに任せる作業・任せない作業 — git commitを人間がやる理由

Geoアプリ群のブログ記事は、この記事も含めてAIエージェントが下書きから公開判断の一歩手前まで作っています。文章を書く、既存記事と重複していないか調べる、内部リンク用の実URLをWordPressから取得する——ここまでは日常的にAIへ任せています。ところが「git commitとpushだけは、必ず人間（Mac側）が行う」というルールを一貫して守っています。今回はその線引きの理由を書きます。

サンドボックス環境でgit書き込みをしない理由

AIエージェントの作業環境（このブログ運用ではCoworkのサンドボックス）は、リポジトリのファイルを読み書きできますが、そこから直接 git commit や git push を実行すると、.git/index.lock のようなロックファイルの残骸が残ることがあります。ロックファイルが残った状態でMac側から通常どおりgit操作をしようとすると、「別のプロセスがロックを保持している」というエラーで作業が止まってしまいます。

これを避けるため、Geoエコシステムの運用では次のように役割を分けています。

git操作より前の工程はすべてファイルの読み書きで完結するため、サンドボックス環境で安全に行えます。一方でgit操作はリポジトリの内部状態（.git/配下）を書き換える処理であり、ここだけは環境の制約が現実的な壁になっています。

「技術的にできるか」と「任せてよいか」は別の話

面白いのは、この線引きが「AIにgit commitの実行権限がない」という技術的な制約だけでは説明しきれない点です。実際、権限さえあればコマンド自体は実行できてしまいます。それでも人間の作業として残しているのは、次のような理由もあります。

• 公開タイミングの最終確認を人間の判断に残したい。 commit・pushはGitHub Actions経由でWordPress公開に直結する操作です。記事の下書きが「公開してよい状態」かどうかの最終チェックポイントとして、意図的に人間の手を挟んでいます。
• 分割コミットの判断が必要な場面がある。 例えば既存記事へ一括で定型文を追記するような変更は、一度に全記事をpushするとGitHub Actionsの実行が長時間化するため、10〜20記事ずつに分けてコミットする運用にしています。この「どう分けるか」は状況判断が絡み、機械的にルール化しにくい部分です。
• 失敗時の切り戻しコストが高い。 ロックファイル残骸のような環境起因のトラブルは、発生してからサンドボックス側で復旧するより、そもそも発生させない設計にしておく方が安全です。

似たような線引きは、アイキャッチ画像の生成でも採用しています。人間と対話しながら作業しているセッションでは、AIがブラウザ拡張でGemini画像生成を操作し、生成した画像をFinder経由で記事フォルダに配置するところまで代行できます。しかし、この記事のように毎朝無人で自動実行されるスケジュールタスクの中では、ブラウザ拡張やFinder操作にその都度アクセス許可の承認が必要になるため実行できません。無人実行時は、画像生成コマンドをチャット本文に提示するところまでに留め、実際の生成・配置は人間が行います。「対話中に人がその場にいるかどうか」で、AIに任せられる範囲そのものが変わるわけです。

AIに任せる基準をどう決めているか

これまでの運用から、線引きの基準を整理すると次のようになります。

• 可逆かどうか。 ファイル編集は何度でもやり直せますが、git pushやWordPressへの公開は取り消しにくい（できなくはないが手間が大きい）操作です。可逆性が低い操作ほど人間側に残す。
• 環境の制約があるかどうか。 サンドボックスのgit書き込み制限のように、技術的な理由で「そもそも安全にできない」操作は、無理に自動化を試みず人間の作業として確定させる。
• その場に人間がいるかどうかで結果が変わるかどうか。 対話セッション中か無人実行中かで、同じ「画像生成」というタスクでも任せられる範囲が変わる。無人実行では常に保守的な側（コマンド提示のみ）に倒す。

AIに作業を任せる範囲を広げていくこと自体は効率化として自然な流れですが、「技術的に実行できる」と「安全に任せてよい」は別の軸だと考えています。この記事のような毎朝の自動記事作成タスクも、最終的なgit commit・pushは今日も人間の手に委ねてこの下書きを終えます。

まとめ

• 記事の下書き・重複チェック・内部リンクの実URL確認・画像プロンプト作成はAIに任せ、git commit・pushは人間（Mac側）が行う運用にしている
• 直接の理由はサンドボックス環境でのgit書き込みがロックファイル残骸を生むという技術的制約
• ただし「技術的にできるか」と「任せてよいか」は別の判断軸であり、可逆性・環境制約・対話の有無を基準に線引きしている
• 同じ理由で、アイキャッチ画像生成の代行範囲も「対話セッション中か、無人の自動実行中か」で変わる

関連記事

• 「同じような記事は書かない」をAIに守らせる — 重複チェックを執筆前工程に組み込む運用（GeoPrism JP）
• 1人開発にAIレビュアーを置く（GeoPrism JP）
• 正典ファイル1枚でAIに文脈を渡す — レジストリ方式のドキュメント運用（GeoPrism JP）
• なぜWordPressブログを3つに分けたのか — 製品別マルチサイト運営の判断（GeoDiveExa）

開発者より: アプリ・Kindle本・オープンソースの一覧は GitHub: amru195704 にまとめています。

お願い
本記事の情報は参考目的で掲載しており、正確性・完全性を保証するものではありません。誤記・不正確な情報がございましたら、コメント欄よりご指摘いただければ、確認のうえ修正いたします。