夜、個人開発しているアプリの小さな修正をpushしようとして、コミットメッセージとPR本文を書く段になって手が止まる——この数分の停滞が、私は長いこと地味に苦手でした。差分は頭に入っているのに、それを他人（未来の自分を含む）に伝わる文章へ翻訳する作業に、毎回わずかな摩擦があります。
Antigravity を日々の開発に組み込んでから、この摩擦がかなり減りました。ポイントは「GitHub 連携」を魔法の機能として期待するのではなく、統合ターミナルの git と gh CLI、そしてエージェントの下書き能力を、自分の手元で組み合わせることにあります。ここでは、私が実際に回している手順を、動くコマンドとともに整理します。派手な自動化ではなく、毎日の小さな摩擦を削るための現実的な流れです。
Antigravity から GitHub を触る3つの経路
最初に、経路を整理しておきます。ここを曖昧にしたまま「AIが全部やってくれる」と期待すると、必ずどこかで肩透かしを食らいます。
| 経路 | 担当 | 向いている作業 |
|---|---|---|
| 統合ターミナル + git | 自分 | clone / branch / commit / push などの確定操作 |
| 統合ターミナル + gh CLI | 自分 | PR 作成・一覧、Actions ログ確認、Issue 操作 |
| エージェント | 下書き係 | 差分の要約、コミット文・PR本文の草案、レビュー前の指摘出し |
私の使い分けはシンプルで、リポジトリの状態を変える操作（commit・push・merge）は必ず自分の手でコマンドを打ち、文章を書く作業と差分の一次チェックをエージェントに任せます。判断と実行は人間、翻訳と下読みはAI、という線引きです。
最初のセットアップ — gh CLI で認証を通す
統合ターミナルを開いて、まず gh CLI が使えるようにします。ブラウザ認証が一番手早く、スコープの取りこぼしも起きにくいです。
# gh がなければ導入（macOS の例）
brew install gh
# ブラウザ経由で認証。プロトコルは SSH を選ぶと以後トークン入力が不要になる
gh auth login
# ? What account do you want to log into? GitHub.com
# ? What is your preferred protocol for Git operations? SSH
# ? Authenticate Git with your GitHub credentials? Yes
# 通ったか確認
gh auth statusHTTPS を選ぶと push のたびにトークンを求められて地味に消耗するので、常用マシンでは SSH をおすすめします。認証が通れば clone もそのまま gh に任せられます。
# gh 経由なら組織名/リポジトリ名だけで clone できる
gh repo clone your-org/your-app
cd your-appAntigravity のエージェントにプロジェクトを理解させたいときは、clone した直後に「このリポジトリの構成と主要なエントリポイントを3行で説明して」と頼むのが手早いです。README とディレクトリ構造を読んで要約してくれるので、初見のコードベースへ入る時間が短くなります。
ブランチ運用 — 命名だけエージェントに相談する
ブランチの作成・切り替えは git の担当です。ここはAIに任せるより自分で打った方が速く、事故も起きません。
# 最新の main を取り込んでから作業ブランチを切る
git switch main
git pull --ff-only
git switch -c feature/oauth-apple-signin命名で迷ったときだけ、エージェントに「変更内容はこう。チームの慣例に沿ったブランチ名の候補を3つ」と相談します。feature/・fix/・docs/ といった接頭辞を踏まえた案を返してくれるので、命名の一貫性を保ちやすくなります。実際に作るのは自分の手で、というのは変えていません。
コミットとPR本文の下書きをエージェントに任せる
ここが一番、日々の摩擦が減る部分です。差分をステージしたら、エージェントに要約させます。
git add -p # 変更を意図ごとに小さくステージ
git diff --staged # ステージ済みの差分を確認この git diff --staged の出力をエージェントに渡して、「この差分から Conventional Commits 形式のコミットメッセージと、PR本文（概要・変更点・テスト手順）を下書きして」と頼みます。返ってきた草案を自分の言葉で削り、そのまま使います。
# コミット（メッセージは草案を編集したもの）
git commit -m "feat(auth): Apple サインインを追加"
git push -u origin feature/oauth-apple-signin
# PR 作成。本文はエージェントの草案を整えたファイルを渡す
gh pr create \
--title "feat(auth): Apple サインインを追加" \
--body-file .git/PR_BODY.md \
--base main--body-file に草案を書いたファイルを渡す形にしておくと、エージェントの出力→ファイル→PR という流れが固定され、毎回ゼロから本文を考えずに済みます。私はこの .git/PR_BODY.md を使い捨てのメモ帳として扱っています（.git/ 配下なのでコミットには含まれません）。
レビュー前の自己チェックをAIに一次委任する
PR を出す前に、エージェントに一次レビューを頼みます。人間のレビュアーの時間を、設計や仕様の議論に使ってもらうための下ごしらえです。
# ブランチ全体の差分をレビュー材料として確認
git diff main...HEADこの差分をエージェントに渡し、「バグの可能性・境界値の抜け・エラーハンドリングの漏れを、確信度の高い順に」と指定します。抽象的な「LGTM」ではなく、具体的な行を指す指摘が返ってくるように条件を絞るのがコツです。指摘を潰したうえで、CI の状態も確認しておきます。
# この PR に紐づくチェックの状態を一覧
gh pr checks
# レビュー依頼を出す
gh pr edit --add-reviewer teammate-handleエージェントの指摘はあくまで一次フィルタで、最終判断は自分とレビュアーが持ちます。ここを取り違えると、AIの誤検知に振り回されて逆に時間を失うので、「消してよい指摘か」を必ず自分で判定します。
GitHub Actions のログを読む
CI が落ちたとき、ブラウザでポチポチ辿るより、ターミナルからログを引いてエージェントに読ませる方がずっと速いです。
# 直近の実行を一覧
gh run list --limit 5
# 失敗したランのログを取得（RUN_ID は上の一覧から）
gh run view <RUN_ID> --log-failed--log-failed は失敗したステップのログだけを絞って出してくれるので、そのままエージェントに貼り付けて「この失敗の原因と、まず試すべき対処を1つ」と尋ねます。長大なログ全体を人間が読む前に、当たりをつけられるのが利点です。
つまずきやすいポイント
認証スコープの不足: gh は通っているのに Actions や特定操作で権限エラーになる場合、認証時のスコープが足りていないことがあります。gh auth refresh -s workflow のように必要なスコープを追加すると解決します。
SSH と HTTPS の取り違え: clone は HTTPS、push は SSH のように混在していると、push だけ認証で弾かれます。git remote -v で URL を確認し、git remote set-url origin git@github.com:your-org/your-app.git で統一しておくと安定します。
エージェントに実行権を渡しすぎない: 便利だからと push や merge までエージェントの提案任せにすると、意図しないブランチへの反映が起きえます。状態を変える操作は自分でコマンドを打つ——この一線だけは崩さないのが、結局いちばん安全でした。
なお、ローカルLLMを絡めた開発環境の整え方に関心があれば、Gemma 4 を Mac でファインチューニングする実践ガイドも合わせて読むと、Antigravity 周辺の環境構築の勘所が掴めるはずです。
次の一手
まずは今開いているリポジトリで、git diff --staged の出力をエージェントに渡してコミットメッセージを下書きさせる——この一点だけ試してみてください。効果を実感しやすいのはここです。慣れてきたら PR 本文、レビュー前チェック、Actions ログの順に委任範囲を広げていくと、無理なく自分の流れに馴染みます。
私自身まだ運用を調整し続けている途中ですが、文章を書く摩擦をAIに肩代わりさせて、判断と実行は手元に残す——この配分が、いまのところ最も気持ちよく回っています。お読みいただきありがとうございました。