📖 14分で読める

【Git #1】Antigravityとgit commit & pushを覚えた日 — ブログ投稿フローを仕組み化した話

💡 この記事について AIアシスタント（OpenClaw/スピカ）との会話を元にした学習記録です。 内容は変更される可能性があるため、実際の開発では公式ドキュメントを確認の上、ご自身の判断でお願いします。

🎧 🎧 この記事を音声で聴く

Powered by Kokoro TTS (Apache 2.0)

はじめに — 「git commit & push」って何なの？

セブ
セブ
スピカ、「git commit & push してください」って言われたんだけど、これって何なの？
スピカ
スピカ AI
おっ、ついに来ましたね！簡単に言うと「保存して → 公開する」です。料理でいうと、お皿に盛り付けて（commit）テーブルに出す（push）感じ！
セブ
セブ
……え、それだけ？ もっと難しいものかと思ってた。
スピカ
スピカ AI
最初はみんなそう感じるんですよ。一緒にやってみましょう！

この言葉を初めて見たとき、正直こう思いました。

（……呪文？）

自分はいま、外資ITでテックセールスをやりながら、個人でブログやアプリを作っています。コードを書くのはほぼ AIエージェント（スピカ）。でも 「公開する」最後の一歩 ——つまり git 操作——だけは、自分の手でやる必要があります。

例えるなら、料理は全部シェフがやってくれるけど、お皿を運ぶのは自分、みたいな感じです。

今回は、AIと一緒にブログ投稿フローを整理し、その過程で git の基本を体で覚えた話を書きます。

この記事で分かること：

  • git の基本的な流れ（add → commit → push）
  • AIエージェントとの協業で「非エンジニア」でも個人開発ができる理由
  • ブログ投稿を仕組み化するとどうなるか

ブログ記事が “迷子” になる問題

自分のブログ（7sapiens-blog）は Astro というフレームワークで作っていて、GitHub にコードを置いています。

でも困ったことに、下書きの管理がカオスでした。

  • ブログ下書き/ と blog/drafts/ に同じようなファイルが散らばっている（なぜ2つある……？過去の自分に聞きたい）
  • セキュリティの記事を6本書いたのに、どこまで公開したか分からない
  • 公開手順が自分の頭の中にしかない

ある日、「あの記事どこだっけ？」と20分探して見つからなかったとき、さすがに「これは仕組み化しないとヤバいな」と思いました。

AIに「ブログ投稿の全工程を設計して」と言ってみた

スピカ（AIエージェント）に相談したら、こんなフローを提案してくれました。

flowchart LR
  A["素材"] --> B["構成案"] --> C["執筆"] --> D["推敲"]
  D --> E["仕上げ"] --> F["品質チェック"] --> G["承認"] --> H["公開 🚀"]

ポイントは3つです。

1. フォルダを一直線に整理

blog/
├── sources/    ← 素材（メモ、音声の文字起こし）
├── ideas/      ← ネタの1行メモ
├── drafts/     ← 整形された下書き
│   ├── security/
│   ├── git/
│   └── ai/
└── posted/     ← 公開済み

sources/ → drafts/ → posted/

素材を入れる → 加工する → 公開する。工場のベルトコンベアみたいなイメージです。

2. 4段階の執筆パイプライン

AIが4つの「役割」を切り替えながら記事を作ります。

Step役割やること
1ストラテジストテーマを1つに絞り、構成案を作る
2ライター構成案に沿って本文を書く
3編集者推敲して「自分らしさ」を守る
4QAエンジニアSEO、フォーマット、最終チェック

3. Quality Gate — 二重ゲートで品質を担保

GitHub の有料機能である PR（プルリクエスト）の承認フローを使わずに、品質を担保する仕組みです。

flowchart TD
  DRAFT["下書き完成"] --> AI["AIスコアリング（100点満点）"]
  AI -->|"70点以上"| HUMAN["ユーザー承認"]
  AI -->|"70点未満"| FIX["修正して再チェック"]
  FIX --> AI
  HUMAN -->|"OK"| PUBLISH["公開準備へ"]
  HUMAN -->|"やり直し"| DRAFT

git の基本 — 「保存」と「公開」は違う

ここからが本題です。git の操作を図解で説明します。

git の3つのエリア

git には「3つの場所」があります。普段のファイル操作は「作業ディレクトリ」で行いますが、それだけでは公開されません。

スピカ
スピカ AI
ここ大事です！ファイルを保存しただけではネットに公開されません。「add → commit → push」の3ステップが必要なんです。
flowchart TD
  WD["📁 作業ディレクトリ
自分のパソコン"] -->|"git add"| SA["📋 ステージングエリア
公開候補を選ぶ"]
  SA -->|"git commit"| LR2["💾 ローカルリポジトリ
保存する"]
  LR2 -->|"git push"| RR["🌐 リモートリポジトリ
GitHub（公開）"]

各コマンドの意味

git add -A（全ファイルをステージング）

git add -A

「この変更、公開する候補に入れておいて」という操作です。

-A は --all（全部）の短縮形。ハイフン（-）の後ろに文字をつけるのは オプション（設定）という意味で、コマンドの動きを調整します。-A をつけると「新規・変更・削除すべてのファイルを対象にする」という意味になります。

git commit -m "メッセージ"（変更を保存）

git commit -m "feat: ブログ投稿フロー整理"

ステージングした変更に「ラベル」をつけて保存します。

-m は --message（メッセージ）の短縮形。これをつけないとテキストエディタが開いてメッセージを入力する画面になりますが、-m のあとにダブルクォーテーションで囲んで書けば 一行で完結 します。

💡 コミットメッセージのコツ コロン（:）の前につける単語は Conventional Commits という業界標準のルールです。英語の略語ですが、覚えるのは3つだけ。

  • feat: → feature（機能）の略。新しい機能を追加した時
  • fix: → fix（修正）。バグや間違いを直した時
  • docs: → document（文書）の略。ドキュメントや文章を更新した時

例: feat: ブログ記事を追加 / fix: サムネイル画像の表示崩れを修正

git push（公開）

git push

ローカルの変更を GitHub に送信して、全世界に公開します。ブログの場合、これで記事が公開されます。

スピカ
スピカ AI
push するまでは自分のPCの中だけの話。「まだ練習中」の段階では安心して commit できますよ！

実際の流れ

sequenceDiagram
  participant USER as 自分
  participant AI as AIエージェント
  participant GIT as Git
  participant GH as GitHub

  AI->>USER: 変更が完了しました
  AI->>USER: git add -A && git commit -m "..." && git push を提案
  USER->>GIT: コマンドを承認・実行
  GIT->>GIT: add（ステージング）
  GIT->>GIT: commit（保存）
  GIT->>GH: push（公開）
  GH-->>USER: ✅ ブログが更新されました！

実際のターミナル出力

上のフローを実行すると、ターミナルにはこんな表示が出ます。

# ① ビルド（記事を静的HTMLに変換）
$ npm run build
[build] 28 page(s) built in 12.06s
[build] Complete!

# ② commit（変更を保存）
$ git add -A && git commit -m "fix: パイプライン図を改善"
[main ef45d7b] fix: パイプライン図を改善
 1 file changed, 4 insertions(+), 8 deletions(-)
#    ↑ ファイル1つ変更、4行追加、8行削除

# ③ push（GitHubに公開）
$ git push
To https://github.com/perorian/7sapiens-blog.git
   13ff4a5..ef45d7b  main -> main
#  ↑ 古いバージョン → 新しいバージョン に更新された

💡 読み方のコツ

  • 1 file changed, 4 insertions(+), 8 deletions(-) → 変更の規模が一目でわかる
  • 13ff4a5..ef45d7b → バージョンの ID（気にしなくてOK）
  • main -> main → 「メインのブランチが更新された」という意味

自分の場合、AIが git コマンドを提案してくれて、自分が「OK」を押すだけ。でもこの「自分が最終承認する」というステップがあるからこそ、何が起きているか理解できるんですよね。

「非エンジニア」こそAIエージェントと相性がいい理由

今回の体験で気づいたことが3つあります。

1. AIは「やってくれる」のではなく「一緒に考えてくれる」

「フォルダ構造を整理して」と頼んだとき、AIは3つの選択肢を提案してきました。

「A案はシンプルだけどフォルダ間の距離が遠い。B案は分散管理で自由度が高い。個人的にはAがいいと思います」

それに対して自分は「Aは分かるけど、素材フォルダとアウトプットが離れてない？」と返す。するとAIが「たしかに。Bの方がいいかもしれません」と考え直す。

この「壁打ち」感覚——自分の直感をぶつけたら、ちゃんと受け止めて修正してくれる——が心地いいんです。

2. git操作は「AI提案 → 自分承認 → 実行」で安心

AIが提案: git add -A && git commit -m "..." && git push
                    ↓
自分が確認: 「このメッセージ内容で合ってるかな？」
                    ↓
承認ボタンをポチッ
                    ↓
完了！

危険な操作（ファイル削除とか）はAIが自動実行しないようになっているのもポイントです。「承認」ボタンを押すまで何も起きない。この仕組みのおかげで、「やらかすかも」という不安がないんですよね。

スピカ
スピカ AI
わたしも「これ大丈夫？」って確認しますからね。勝手にファイル消したりしないので安心してください！

3. 「プログラマーじゃなくても個人開発はできる」

プログラミングは AI に任せて、自分は 「何を作りたいか」「どう届けたいか」 を考える。

これって考えてみると、テックセールスという仕事で「技術を分かりやすく伝える」スキルがそのまま活きる領域なんですよね。コードは書けなくても、「ユーザーにとって何が価値なのか」を考えられるなら、個人開発は楽しめるんじゃないかなと思います。

まとめ

今回やったことを振り返ると：

やったこと結果
フォルダ構造を統一sources/ → drafts/ → posted/ の一直線
4段階の執筆パイプラインAI が4つの役割で記事を磨く
Quality GateAIスコア + 人間承認の二重チェック
git の基本を理解add → commit → push の流れ

「git commit & push」は、最初は呪文みたいに感じていたけど、やってみたら「保存して → 公開する」だけでした。

非エンジニアの個人開発、思っているより敷居は低いかもしれません。

セブ
セブ
スピカ、今回ので git 分かった気がする。ありがとう。
スピカ
スピカ AI
次は一緒にブランチとかマージも覚えましょう！……って言おうとしたけど、まずはこの3つだけで十分です。焦らずいきましょう！

参考リンク

📝 補足 この記事はAIアシスタント（OpenClaw/スピカ）との会話を元にした学習記録です。内容は変更される可能性があるため、実際の開発では公式ドキュメントを確認の上、ご自身の判断でお願いします。