非エンジニアのためのGitHub管理 - Claude Codeで実現するAIエージェント時代のワークフロー

この記事で伝えたいこと

この記事では、PMやデザイナーがGitの細かい操作を覚えなくても、要件定義書やmockupの変更をGitHub上の変更として扱えるようにした取り組みを紹介します。

ポイントは、Gitをなくしたことではありません。Gitの履歴、Pull Request、CI、レビュー可能性は残しつつ、branch切り替え、commit、push、PR作成、auto-mergeといった操作をAIエージェントとスクリプトの裏側に寄せたことです。

近年、AIエージェントはコードを書くためだけの道具ではなくなってきました。 自然言語で作業を依頼し、ローカルファイルの読み取りやコマンド実行、GitHub連携まで進めることで、これまでエンジニアだけが担っていた「変更を安全に届ける」作業の一部を肩代わりできます。

一方で、何でもAIに任せればよいわけではありません。 今回の取り組みでは、AIエージェントが判断する部分と、shell scriptやCIで機械的に守る部分を分けました。 この分担こそが、非エンジニアにもGit管理の恩恵を広げる上で重要だったと考えています。

想定読者

• PM、デザイナー、PdMなど、Gitを日常的には使わないがプロダクト開発の成果物を更新する人
• 非エンジニアの作業成果を、GitHubの履歴やPRに載せたいエンジニア
• AIエージェントを、単なるコード生成ではなくチームワークの基盤として使いたい人

目次

• はじめに
• 対象リポジトリで実際に起きていたこと
• 何ができるようになったのか
• 利用者から見える体験
• 裏側で起きていること
• 同じ仕組みを作るなら何を実装するか
• なぜこれが嬉しいのか
• 実際の利用者コメント
• AIエージェント時代の非エンジニアの作業はどう変わるのか
• エンジニアとして気をつけたこと
• 作りながら感じたこと
• 今後やりたいこと
• まとめ

はじめに

こんにちは、Insight Edgeの古野です。

プロダクト開発では、ソースコードだけでなく、要件定義書、画面mockup、仕様メモ、検証結果など、多くの成果物が日々更新されます。 これらはエンジニアだけのものではありません。 PMが要件を更新し、デザイナーが画面案を調整し、それをもとにエンジニアが実装します。

ところが、成果物をGitHubで管理しようとすると、非エンジニアにとって急にハードルが上がります。

• cloneとは何か
• branchはいつ切り替えるのか
• commit messageには何を書くのか
• pushしてよいbranchはどれか
• PRを作ったあと何を見ればよいのか
• conflictと表示されたら何をすればよいのか

これらはエンジニアにとっては日常的な操作です。 しかし、要件やデザインを更新したい人にとっては、本来の仕事とは別の認知負荷です。

そこで、PMとデザイナーが担当領域の変更をGitHubに反映するためのAIエージェント向けコマンドを整備しました。

PMは次のように実行します。

/pm merge

デザイナーは次のように実行します。

/dsn merge

これだけで、裏側ではcommit、push、Pull Request作成、auto-merge設定まで進みます。ユーザーはbranchを切り替えません。git add や git push も打ちません。

対象リポジトリで実際に起きていたこと

この仕組みは、思いつきで作ったものではありません。 対象リポジトリでは、PMが扱う要件と、デザイナーが扱うmockupの更新が継続的に発生していました。

執筆時点で、2026年6月以降の履歴を確認すると、mockup更新のcommitは34件、要件定義書や要求機能一覧の更新commitは8件ありました。

確認には、例えば次のようなログを見ています。

git log --since=2026-06-01 --oneline --grep='chore(mockup)' | wc -l
git log --since=2026-06-01 --oneline --grep='docs(requirements)' | wc -l

つまり、これは単発の手作業を楽にするための仕組みではなく、今後も繰り返し発生する「content更新」を安全に回すための仕組みでした。

実装の変遷も、最初から完成形だったわけではありません。

• 2026年6月3日: 非エンジニア向けの /d skillとcontent PR gateを追加
• 同日: /d をcheckとmergeに分け、mergeを引数不要に変更
• 同日: Figma / AI Studio exportの取り込みをmergeに内包
• 同日: developer向けのdev roleを追加し、要件とmockupの両レーンを自動判定
• 2026年6月4日: recoverコマンドやallowlist検証の強化
• 2026年6月17日: 一時worktreeベースに変更し、利用者の作業branchを切り替えない形へ補正
• 2026年7月3日: /d を役割別窓口の /pm と /dsn に分離し、共通処理をcontent-coreへ集約

この履歴から分かるのは、単にGitコマンドをラップしただけでは足りなかったということです。 実際に運用しながら、利用者が覚える手順を減らし、エンジニアが安全性を担保しやすい形へ寄せていきました。

何ができるようになったのか

今回の仕組みでは、役割ごとに触れる領域を分けました。

役割	主に扱うもの	コマンド	反映先 branch
PM	要件定義書、要求機能一覧	/pm merge	content/requirements
デザイナー	mockup	/dsn merge	content/mockup
エンジニア	PM / デザイナーの代行、両レーン対応	/d git-merge	変更内容に応じて自動判定

PMは要件の変更を、デザイナーはmockupの変更を、それぞれ自分の窓口から反映します。

デザイナー向けには、FigmaやAI Studioからexportしたmockupの取り込みも /dsn merge の中に含めました。 別途importコマンドを覚える必要はありません。 新しいexportがあればその場所を伝え、なければ「なし」と答えるだけです。

この設計にした理由は、非エンジニア向けの導線では「手順を増やさない」ことが重要だからです。 便利なコマンドが複数あっても、どの順番で打つのかを覚える必要があるなら、結局Git操作を覚えるのと同じ構造になってしまいます。

利用者から見える体験

初回セットアップでは、GitHub CLIへのログインやリポジトリのcloneは必要です。 この部分は残しています。GitHubに安全にpushするための認証は必要だからです。

具体的には、最初に次のような準備をします。

• 対象リポジトリへのGitHub招待を受け、write権限を持つ
• Claude Codeを使える状態にする
• git と gh をインストールする
• gh auth login でGitHubにログインする
• 対象リポジトリをcloneする

例えば、macOSであれば次のような流れです。

brew install git gh
brew install --cask claude-code
gh auth login
gh repo clone <repository>
cd <repository>

今回の仕組みで重要なのは、反映用の merge だけを用意することではありませんでした。

実際にチームで使うには、最初に必要なものがそろっているかを確認する導線、しばらく触っていない間にエンジニアが更新したスキルや手順を取り込む導線、途中で止まったときに状態を診断する導線も必要になります。

そのため、利用者に見せる入口は次のように整理しました。

タイミング	PM	デザイナー	何をするか
初回セットアップ	/pm check	/dsn check	必要ツール、GitHub認証、push権限、役割設定を確認する
作業前の最新化	/pm sync	/dsn sync	最新のmainを取り込み、エンジニアが更新したスキルや手順に追従する
反映	/pm merge	/dsn merge	担当領域の変更をcommit、push、PR作成、auto-mergeまで進める
困ったとき	/pm recover	/dsn recover	状態を診断し、エンジニアに渡せる情報を出す

init と呼びたくなる初期化の領域は、今回の実装では check に寄せました。 初回だけ使う入口を別に増やすより、「準備OKかどうかを見る」という言葉に寄せた方が、PMやデザイナーにとって意味が伝わりやすいと考えたためです。

sync も地味ですが重要です。エンジニアが /pm や /dsn の中身を直したり、安全性のチェックを強くしたりしても、利用者がGitのpullやrebaseを理解する必要はありません。 作業前に /pm sync や /dsn sync を実行すれば、最新のmainを取り込み、更新されたレールに乗り直せます。 ここでもpushは行わず、あくまで手元を最新化するだけにしています。

つまり、日々の運用ではGitの詳細を意識しません。

初回だけ、PMまたはデザイナーの窓口で準備状態を確認します。

/pm check
# または
/dsn check

しばらく作業していない場合や、エンジニアがスキル側を更新したあとには、作業前に最新化します。

/pm sync
# または
/dsn sync

担当ファイルを編集したあとの反映は、mergeだけです。

/pm merge
# または
/dsn merge

実行後は、反映されたファイル一覧とPR URLが表示されます。 CIが通れば自動でmainに取り込まれます。

裏側で起きていること

利用者からは /pm merge や /dsn merge の1コマンドに見えますが、裏側では複数のGit操作が動いています。

処理の大枠は次の通りです。

PMとデザイナーがGit操作を意識せずPRまで進む処理フロー（図：筆者作成）

特に重視したのは、次の3点です。

1つ目は、一時worktreeを使うことです。

ユーザーの作業branchは切り替えません。PMやデザイナーがmain上で作業していても、反映処理は裏側の一時worktreeで進みます。 これにより、「今どのbranchにいるか」を利用者が意識しなくて済みます。

2つ目は、allowlistです。

PMは要件ディレクトリ、デザイナーはmockupディレクトリだけを反映できます。 対象外のファイルが混ざっていても、スクリプトはそれをcommitしません。

簡略化すると、裏側では次のような考え方で対象を絞っています。

# 実際のコードを説明用に簡略化した例
case "$role" in
  pm)       allow="docs/product/requirements" ;;
  designer) allow="mockup" ;;
esac

git -C "$worktree" add -- "$allow"
git -C "$worktree" diff --cached --name-only

3つ目は、CIで同じ制約をもう一度確認することです。

ローカルスクリプトだけでは、将来の変更や想定外の操作に弱くなります。 そのため、GitHub Actions側でも content/requirements branchは要件ディレクトリだけ、content/mockup branchはmockupディレクトリだけ、というルールを検証しています。

# 実際の workflow を説明用に簡略化した例
case "$HEAD_REF" in
  content/requirements) ALLOW="docs/product/requirements/" ;;
  content/mockup)       ALLOW="mockup/" ;;
  *) exit 0 ;;
esac

git diff --name-only "origin/${BASE_REF}...HEAD"

AIエージェントに任せる部分はありますが、最終的な安全性はpromptの約束ではなく、shell scriptとCIで担保します。

同じ仕組みを作るなら何を実装するか

ここまでだと考え方の紹介で終わってしまうので、同じような仕組みを作るなら何を実装すればよいかも整理します。

最小構成は、次のように分けるのが扱いやすいです。

.claude/skills/
  pm/SKILL.md
  dsn/SKILL.md
  content-core/
    scripts/
      check.sh
      sync.sh
      merge.sh
.github/workflows/
  content-pr-guard.yml

ポイントは、AIエージェント側のskillにGit操作を直接書きすぎないことです。 /pm や /dsn は利用者向けの入口にして、実際のGit操作はshell scriptへ寄せます。

例えば、skill側はこのくらい薄くできます。

# /pm

- `/pm check` は `bash .claude/skills/content-core/scripts/check.sh pm` を実行する
- `/pm sync` は `bash .claude/skills/content-core/scripts/sync.sh` を実行する
- `/pm merge` は `bash .claude/skills/content-core/scripts/merge.sh` を実行する
- Gitが途中で止まったら、利用者に直接 `reset` や `stash pop` を案内せず、エンジニアへ共有する

デザイナー向けの /dsn も同じで、roleだけを designer に固定します。 /pm init や /dsn init という名前を用意してもよいですが、今回の実装では「初回に準備OKかを見る」という意味を優先して check に寄せました。 大事なのは名前ではなく、初回検証、最新化、反映、復旧の入口が分かれていることです。

check: 必要ツールと権限を確認する

check では、利用者がGitの状態を読めなくても、作業できる前提がそろっているかを機械的に確認します。

#!/usr/bin/env bash
set -euo pipefail

role="${1:?role is required: pm or designer}"
ok=1

pass() { printf '  ✅ %s\n' "$1"; }
fail() { printf '  ❌ %s\n' "$1"; ok=0; }

command -v git >/dev/null 2>&1 && pass "git found" || fail "git not found"
command -v gh  >/dev/null 2>&1 && pass "gh found"  || fail "gh not found"

git rev-parse --is-inside-work-tree >/dev/null 2>&1 \
  && pass "inside git repository" \
  || fail "run this in cloned repository"

gh auth status >/dev/null 2>&1 \
  && pass "gh authenticated" \
  || fail "run gh auth login"

can_push="$(gh api 'repos/{owner}/{repo}' --jq '.permissions.push' 2>/dev/null || echo false)"
[ "$can_push" = "true" ] && pass "push permission ok" || fail "no push permission"

case "$role" in
  pm|designer) printf '%s' "$role" > "$(git rev-parse --git-dir)/content-role" ;;
  *) fail "unknown role: $role" ;;
esac

[ "$ok" = "1" ] || exit 1
echo "準備OK。以降は sync / merge を使えます。"

ここで .git/content-role のようなファイルにroleを保存しておくと、merge 側で毎回「PMですか、デザイナーですか」と聞かずに済みます。

sync: エンジニアが更新したレールに追従する

sync は地味ですが、運用上かなり重要です。 エンジニアがskillやscriptを更新しても、利用者に git pull や rebase を説明したくありません。

そこで、利用者には /pm sync や /dsn sync だけを見せ、裏側で最新の main を取り込みます。

#!/usr/bin/env bash
set -euo pipefail

repo_root="$(git rev-parse --show-toplevel)"
cd "$repo_root"

git fetch origin --quiet

stashed=0
if [ -n "$(git status --porcelain)" ]; then
  git stash push -u --quiet
  stashed=1
fi

if ! git rebase origin/main --quiet; then
  git rebase --abort >/dev/null 2>&1 || true
  [ "$stashed" = "1" ] && git stash pop --quiet >/dev/null 2>&1 || true
  echo "最新mainの取り込みで衝突しました。エンジニアに連絡してください。" >&2
  exit 1
fi

if [ "$stashed" = "1" ]; then
  git stash pop --quiet || {
    echo "退避した変更の復帰で衝突しました。エンジニアに連絡してください。" >&2
    exit 1
  }
fi

echo "最新mainを取り込みました。pushはしていません。"

sync はpushしません。あくまで手元を最新化するだけです。 反映は次の merge に寄せます。

merge: allowlistだけを一時worktreeへ転送する

merge が一番重要です。利用者の作業branchは切り替えず、一時worktree上でcontent用branchを作り、担当領域だけをstageします。

説明用に簡略化すると、中心は次のような処理です。

#!/usr/bin/env bash
set -euo pipefail

repo_root="$(git rev-parse --show-toplevel)"
git_dir="$(git rev-parse --git-dir)"
role="$(tr -d '[:space:]' < "$git_dir/content-role")"

case "$role" in
  pm)
    branch="content/requirements"
    allow="docs/product/requirements"
    type="docs(requirements)"
    ;;
  designer)
    branch="content/mockup"
    allow="mockup"
    type="chore(mockup)"
    ;;
  *)
    echo "unknown role: $role" >&2
    exit 1
    ;;
esac

git fetch origin --quiet

base="origin/main"
if git show-ref --verify --quiet "refs/remotes/origin/$branch"; then
  base="origin/$branch"
fi

tmp="$(mktemp -d)"
wt="$tmp/worktree"
git worktree add --detach "$wt" "$base" --quiet

cleanup() {
  git worktree remove "$wt" --force >/dev/null 2>&1 || true
  rm -rf "$tmp"
}
trap cleanup EXIT

if [ "$base" = "origin/$branch" ]; then
  git -C "$wt" merge --no-edit origin/main
fi

while IFS= read -r -d '' entry; do
  xy="${entry:0:2}"
  path="${entry:3}"
  case "$xy" in
    *D*) rm -f "$wt/$path" ;;
    *)
      mkdir -p "$wt/$(dirname "$path")"
      cp -p "$repo_root/$path" "$wt/$path"
      ;;
  esac
done < <(git status --porcelain -z -uall --no-renames -- "$allow")

git -C "$wt" add -- "$allow"

この時点では、まだcommitしません。 先にstageされたファイルがallowlist配下だけかを確認します。

outside="$(
  git -C "$wt" diff --cached --name-only |
    while IFS= read -r file; do
      case "$file" in
        "$allow"|"$allow"/*) ;;
        *) printf '%s\n' "$file" ;;
      esac
    done
)"

if [ -n "$outside" ]; then
  echo "対象外の変更が含まれています:" >&2
  echo "$outside" >&2
  exit 1
fi

if git -C "$wt" diff --cached --quiet; then
  echo "反映する変更はありません。"
  exit 0
fi

ここまで通って初めてcommit、push、PR作成へ進みます。

summary="$(
  git -C "$wt" diff --cached --name-only |
    head -5 |
    awk 'NR == 1 { out = $0; next } { out = out ", " $0 } END { print out }'
)"

git -C "$wt" commit -m "$type: 更新: $summary" --quiet
git -C "$wt" push --force-with-lease origin "HEAD:$branch" --quiet

if [ "$(gh pr list --head "$branch" --base main --state open --json number --jq 'length')" = "0" ]; then
  gh pr create \
    --base main \
    --head "$branch" \
    --title "$type: 更新" \
    --body "content mergeによる自動作成。対象は $allow/ のみ。"
fi

gh pr merge "$branch" --auto --squash
gh pr view "$branch" --json url --jq .url

この実装で、利用者はbranchを切り替えず、git add や git push を打ちません。 一方で、GitHub上にはPRと履歴が残ります。

CI: ローカルと同じ制約をサーバ側でも見る

ローカルのshellだけに寄せると、将来の変更で抜け道ができます。 GitHub Actionsでも同じallowlistを確認します。

name: content-pr-guard

on:
  pull_request:
    branches: [main]

jobs:
  content-scope-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Check content scope
        run: |
          case "${GITHUB_HEAD_REF}" in
            content/requirements) allow="docs/product/requirements/" ;;
            content/mockup) allow="mockup/" ;;
            *) exit 0 ;;
          esac

          git diff --name-only "origin/${GITHUB_BASE_REF}...HEAD" |
            while IFS= read -r file; do
              case "$file" in
                "$allow"*) ;;
                *)
                  echo "out of scope: $file"
                  exit 1
                  ;;
              esac
            done

このように、AIエージェントに任せるのは「どの入口を呼ぶか」までに留めます。 安全性は、shell scriptとCIで同じルールを二重に確認します。

なぜこれが嬉しいのか

この仕組みで嬉しかったことは、単に「Git操作を自動化できた」ことではありません。

一番大きいのは、PMやデザイナーの成果物を、エンジニアの成果物と同じ流れで扱えるようになったことです。 履歴・レビュー・CIの対象として確認できます。

これまでは、要件やmockupの受け渡しが次のようになりがちでした。

• Slackにファイルを貼る
• zipを共有する
• 「最新版はこちらです」と口頭で伝える
• エンジニアが手元で取り込んでcommitする

この形だと、どれが最新版なのか、いつ何が変わったのか、なぜその変更が入ったのかが追いにくくなります。 エンジニアが代理でcommitする場合も、変更の主体とGitHub上のauthorがずれやすくなります。

今回の仕組みでは、PMやデザイナーが自分の作業として変更を反映できます。 PRが残るため、後から差分を確認できます。 CIも通るため、対象外ファイルやsecret混入を防げます。

PMやデザイナーにとってのモチベーションは、「GitHubを使えるようになること」そのものではありません。 自分が責任を持つ成果物を、自分の作業として履歴に残せることです。

PMであれば、要件変更の背景や優先順位を、実装と同じ場所で追えるようになります。 あとから「この要件はいつ、どの判断で変わったのか」を確認しやすくなります。

デザイナーであれば、mockupの更新をzipや画像共有で終わらせず、実装側が追える変更として渡せます。 「この画面を更新しました」という連絡だけでなく、GitHub上のPR URLを起点に会話できます。

使ってみて感じたのは、価値の中心が「Git操作が簡単になった」ことよりも、「変更の置き場所がチームでそろう」ことにあるという点です。 Gitの知識が少ない人でも、PRという同じ単位で変更を共有できると、会話が「誰が取り込むか」から「何が変わったか」「どう確認するか」に移ります。

エンジニアにとってもメリットがあります。

非エンジニアの作業を毎回手作業で取り込む必要が減ります。 さらに、取り込まれた変更はPRとして見えるため、必要なときにレビューできます。 GitHub上に履歴が残るので、後から実装との対応関係も追いやすくなります。

実際の利用者コメント

この記事では、仕組みを作った側だけでなく、実際に使う側の目線も入れたいと考えました。

そこで、PMやデザイナーに「本プロジェクトでGit操作をしてみた感想」を一言ずつもらいました。 次の画像では、氏名、アイコン、メンション、投稿時刻をマスキングしています。

PMとデザイナーからもらった利用者コメントのスクリーンショット（図：利用者コメントをもとに筆者作成）

この画像を入れる目的は、「便利になりました」という感想を載せることだけではありません。GitHub上に変更を届ける体験が、PMやデザイナーにとって本当に本来業務の邪魔にならないかを見るためです。

Git操作を覚えることが目的になってしまうと、非エンジニアにとっては負担が増えます。一方で、「自分の成果物を自分の責任範囲で届けられる」「変更の所在がチームで共有される」という実感があれば、GitHubを使う理由が自然に伝わります。

AI エージェント時代の非エンジニアの作業はどう変わるのか

AIエージェントが入ると、非エンジニアができることは増えます。

以前なら、GitHubに変更を載せるにはGitの操作を覚える必要がありました。今は、AIエージェントに「この変更を反映して」と依頼すると、裏側でコマンドを実行できます。

ただし、ここで大切なのは「非エンジニアもエンジニアと同じことを全部やる」ことではないと考えています。

PMは、要件の妥当性、業務上の優先順位、ユーザー価値に責任を持つ。

デザイナーは、画面体験、情報設計、操作性、表現品質に責任を持つ。

エンジニアは、実行境界、権限、CI、rollback、保守性に責任を持つ。

AIエージェントは、その間にある手作業や翻訳作業を支援する。

この分担を崩さないことが重要です。AIエージェントが使えるからといって、PMやデザイナーにconflict解消やbranch戦略の判断まで任せる必要はありません。逆に、エンジニアがすべてを代行し続ける必要もありません。

役割の境界を曖昧にするのではなく、それぞれが責任を持つ領域を明確にした上で、境界をまたぐ作業をAIエージェントに手伝ってもらう。この考え方が、今回の取り組みの中心にあります。

エンジニアとして気をつけたこと

非エンジニア向けの仕組みを作るとき、つい「簡単にする」ことばかり考えがちです。

しかし、簡単に見える導線ほど、裏側の安全設計が必要です。

今回、特に気をつけたことは次の4つです。

1つ目は、対象ディレクトリの外を絶対に反映しないことです。

AIエージェントへの指示だけで「対象外は触らないで」と書いても十分ではありません。誰であっても間違える可能性があります。そこで、スクリプトでは対象だけをstageします。CI側でも対象外変更を落とすようにしました。

2つ目は、利用者にGitの復旧操作をさせないことです。

stash、checkout、reset、rebase --abort などは、慣れていない人にとって危険です。途中で止まったときは、利用者が自分で直す必要はありません。診断結果をエンジニアへ渡せるようにしました。

3つ目は、手順を増やさないことです。

デザイナー向けにはmockup exportの取り込みもmergeに含めました。アーカイブ、import、commit、pushのようにコマンドを分けすぎると、利用者は結局オペレーションを覚える必要があります。

4つ目は、エンジニア向けの代行ルートも用意することです。

PMやデザイナーだけでなく、エンジニアが要件やmockupの反映を代行する場面もあります。そのときに通常の開発branchから直接対象ディレクトリを触ると、CIの条件や必須チェックの設計と衝突することがあります。そのため、エンジニア用の /d git-merge も同じcontent branch経由に寄せました。

作りながら感じたこと

この取り組みを進めていて感じたのは、AIエージェントによって「誰がリポジトリに変更を届けられるか」の範囲が広がっているということです。

これまでは、GitHubに変更を載せること自体がエンジニア寄りの作業でした。今後は、PMが要件を更新し、デザイナーがmockupを更新し、それが自然にPRとして現れる状態が増えていくと思います。

一方で、AIエージェントがいるからこそ、エンジニアリングの重要性はむしろ上がります。

自然言語で依頼できる体験を作るには、裏側に明確な実行境界が必要です。どのファイルを触ってよいのか。どのbranchにpushしてよいのか。どのCIを通すのか。失敗したときに誰が対応するのか。

こうした境界を設計するのは、やはりエンジニアの仕事です。

AIエージェント時代のチームワークでは、エンジニアがすべてを直接作業するのではなく、他の職種が安全に作業できるレールを作る場面が増えるのではないかと思います。

今後やりたいこと

今後は、次のような改善が考えられます。

• PR上のレビューコメントをもとに、AIエージェントが修正候補を出す
• mockupと実装の差分を自動で検出する
• 要件変更と実装タスクの対応関係を追えるようにする
• テックブログやドキュメント更新にも同じ考え方を広げる

特に、mockupと実装の差分検出は重要です。デザイナーがmockupを更新できるようになると、次に必要になるのは「その変更が実装に反映されたか」を追う仕組みです。GitHubに変更履歴が残っていれば、そこを起点に自動レビューや差分検出を組み合わせやすくなります。

まとめ

PMやデザイナーがGitを知らなくてもGitHubに変更を届けられるようにする取り組みを紹介しました。

今回実現したことは、Gitを使わない世界ではありません。 むしろ、Gitの履歴、PR、CI、レビュー可能性を活かすために、Git操作の難しさをAIエージェントとスクリプトの裏側へ移した取り組みです。

AIエージェントは、非エンジニアの作業範囲を広げます。ただし、そのためには安全な実行境界が必要です。 AIに任せる部分と、shell scriptやCIで機械的に守る部分を分けることで、チーム全体がGitHubをより自然に使えるようになります。

Gitを覚えてもらうのではなく、Gitの価値をチーム全員が使えるようにする。

今回の仕組みは、そのための小さな一歩だったと思います。