はじめに
個人で複数のサービスを並行開発しているうちに、Git worktree が 5 個 に増えました。
- 試験対策プラットフォーム
- 授業プラットフォーム
- 別の業務支援アプリ
- 投資/補助金関連の資料
- 実験用
それぞれで AI ペアプログラミング (Claude Code) を別ウィンドウで動かしているのですが、ある日気づきました。
「あれ、どの worktree で何やったか分からなくなってきた」
PR 履歴を見れば事実は分かります。でも、
- なぜその変更をしたのか
- 何を学んだのか
- 次に何を改善したいのか
- どのステークホルダーに何を伝えたか
これらは PR には残らないんですよね。コードを見ても、何の連絡をしたかは分からない。
そこで 「作業がひと段落したら、AI が自動で Notion DB にタスクを記録する」 仕組みを作りました。
この記事はその記録です。初心者の方でも追えるように、専門用語からゆっくり書きます。
この記事の前提となるツールは個人開発レベルで使える組み合わせです:
Git worktree (Git 標準機能) + Notion (無料枠で OK) + Claude Code (有料、AI ペアプロ)。
特別な環境は不要です。
TL;DR
| Before | After |
|---|---|
| worktree 5 個でどこで何やったか分からない | Notion DB に全部記録される |
| AI セッションごとに記憶が分断 | DB 経由で他セッションも参照可能 |
| 連絡 / 障害 / PR / 記事ドラフトが散らばる | 全部 1 つの DB に集約 |
カギは Claude Code の「Skill」という仕組みです。
1. そもそも Git worktree って何
知ってる人は飛ばしてください。
普通の Git だと、1 つの作業ディレクトリで git checkout してブランチを切り替えますよね。これだと:
- 別のブランチに切り替えると、今やってた作業が見えなくなる
- 並行で 2 つの機能を開発しにくい
これを解決するのが Git worktree です。
# メイン作業ディレクトリ
~/AI/Portfolio ← ブランチ: main
# worktree を追加すると、別ディレクトリで別ブランチを並行展開できる
git worktree add ../Portfolio.exam feature/exam-bootstrap
# こうなる
~/AI/Portfolio.exam ← ブランチ: feature/exam-bootstrap
ファイルが物理的にコピーされるわけではなく、Git の内部で繋がっています。同じリポジトリを別ブランチで並行作業できる仕組み です。
個人開発でこれを使うと、
- 試験対策の新機能を
Portfolio.examで - 授業プラットフォームの UI 改修を
Portfolio.lessonsで - 投資家向け資料を
Portfolio.investで
それぞれ別のターミナルで並行進行できます。便利。
2. ところが、worktree が 5 個になると...
最初は「すごい便利!」だったのが、3 個を超えたあたりからカオスになります。
カオスの正体
各 worktree でそれぞれ AI ペアプログラミング (Claude Code) を動かしているのですが、
-
AI セッションは独立している —
Portfolio.examのセッションはPortfolio.lessonsのセッションが何やったか知らない - PR は履歴に残るが、判断や背景は残らない — 「なぜこの実装にしたか」が消える
-
連絡やドラフトはローカルメモに散る — Slack 文面ドラフト、note 記事下書き、連絡などが各 worktree の
docs/にバラバラに
具体的に困った例:
私: 「先週、試験対策で何の PR 出したっけ?」
私 (記憶): 「えーっと... maxDuration の修正と、AI ボタンの位置変更と... あと 1 個何かあったような...」
GitHub: (15 個の PR をスクロール)
これ毎日やってると消耗します。
既存の解決策と限界
- TODO アプリ: 自分で書く必要がある (続かない)
- GitHub Projects: PR と紐付けやすいけど、連絡や障害メモは入れにくい
- Notion (手動): 続かない (人間の限界)
- Discord/Slack ログ: 自分とだけ会話してる気持ちになる
結論: AI に書かせよう。
3. アイデア: AI が自動で Notion DB に記録する
ゴールはシンプル:
「作業がひと段落したら、AI が勝手に Notion DB に行を追加してくれる」
人間がやることは「お疲れ」と言うだけ。AI がよしなにタスクの中身・種別・タグ・要約を書いて DB に投入する。
これを実現する 3 つの要素:
- Notion DB — 蓄積場所
- Notion MCP — AI が Notion を操作するための仕組み
- Skill — Claude Code に「いつ・どう書くか」を教える仕組み
順に説明します。
4. 仕組みの全体像
[ Portfolio.exam ターミナル ] [ Portfolio.lessons ターミナル ]
│ │
│ Claude Code セッション │ Claude Code セッション
▼ ▼
┌─────────────────────────────┐
│ notion-knowledge-hub Skill │ ← 全 worktree 共通
│ ・いつ書くか │
│ ・スキーマ │
│ ・公開禁止情報の判断基準 │
└─────────────┬───────────────┘
│ notion-create-pages
▼
┌─────────────────────────────┐
│ Notion「開発ナレッジハブ」DB │
│ - 名前 / 種別 / ステータス │
│ - 日付 / worktree / タグ │
│ - 要約 / 関連リンク │
└─────────────────────────────┘
ポイント:
- AI セッションは独立だが、Skill と DB は共通 → 知識が一箇所に集まる
- どの worktree も同じ手順で書く → 統一されたフォーマット
- 書くタイミングは AI が判断 → 人間は何もしない
5. ステップ 1: Notion DB を作る
Notion で空の DB を作ります。Notion 公式の「データベース - インライン」を選ぶだけ。
スキーマ (列の構成) はこんな感じにしました:
| 列名 | 種類 | 用途 |
|---|---|---|
| 名前 | タイトル | "PR #66: RAG 精度向上" のような短いタイトル |
| 種別 | セレクト | 開発状況 / 意思決定 / タスク / 案件 / ナレッジ / 障害 / メモ |
| ステータス | セレクト | 着手中 / レビュー中 / 完了 / 保留 |
| 日付 | 日付 | 着手日 or 完了日 |
| worktree | セレクト | どの worktree での作業か (exam / lessons / hn-medic / invest / main) |
| 関連リンク | URL | PR URL や記事 URL |
| タグ | マルチセレクト | AI / RAG / セキュリティ / UI/UX / インフラ / DB / CI/CD など |
| 要約 | テキスト | 2-4 行サマリ |
「種別」がポイントです。コードの変更だけでなく、連絡や障害も同じ DB に入れる ので、種別で分類します。
6. ステップ 2: AI が Notion を操作できるようにする
Claude Code には MCP (Model Context Protocol) という仕組みがあって、外部サービスを AI から操作できます。Notion 用 MCP は公式に用意されているので、それを有効化するだけ。
設定が済むと、AI から notion-create-pages という関数で DB にレコードを追加できるようになります。
// AI が内部で実行する処理 (擬似コード)
notion.createPage({
parent: { data_source_id: "378b5646-..." },
properties: {
"名前": "PR #66: RAG 精度向上 (HNSW + ef_search)",
"種別": "開発状況",
"ステータス": "レビュー中",
"worktree": "exam",
"タグ": ["RAG", "DB", "AI"],
"要約": "DiscussionPostEmbedding に HNSW index 追加..."
}
})
7. ステップ 3: Skill を作る (← ここが鍵)
ここが今回のキーポイントです。
Claude Code には Skill という機能があります。
ざっくり言うと「特定の状況になったら、AI がこの手順書を参照する」仕組み。
.claude/skills/{skill 名}/SKILL.md というファイルを置くと、Claude Code が自動で読み込みます。
今回作った skill はこんな構成です:
---
name: notion-knowledge-hub
description: 作業がひと段落したら Notion DB に記録する
---
# notion-knowledge-hub
## いつ書くか
- PR を出した / マージされた
- 機能を 1 つ完成させた
- 障害事象が起きた・解決した
- ステークホルダー (合田先生など) に連絡用の文章を作った
- 運用ルールが変わった
## 書きすぎない目安
- 1 commit ごとに 1 件は多すぎる
- 進捗報告ページの日次サマリと重複させない
## DB 情報
- URL: https://...
- Data Source ID: 378b5646-...
## スキーマ
(列の説明)
## 書き込み手順
(notion-create-pages のテンプレ)
## 公開禁止情報
- API キー / Bearer トークン
- 実ドメイン (→ 仮名に置換)
- 個人情報 (組織名 / 教師名 / 生徒情報)
- 「仕組みは書く、具体仕様は書かない」原則
これで AI が以下のように動きます:
- ユーザーが「お疲れ」「マージしました」「完成です」みたいに言う
- AI が skill を見て「あ、Notion に書くタイミングだ」と判断
- ふさわしい種別・タグ・要約を AI が自動生成
- Notion DB に書き込み
- ユーザーには 1 行報告
8. ステップ 4: 全 worktree に展開する
ここがちょっと工夫が必要です。
Skill ファイルは .claude/skills/ 配下に置きますが、worktree ごとに別物 になります (Git の作りから当然)。
私のリポジトリではメインの Portfolio ディレクトリを skill の本拠地 にしていて、各ドメイン worktree (Portfolio.exam 等) で main ブランチを git merge すれば、skill ファイルも一緒に取り込まれる構成にしました。
# 各 worktree でやる
git fetch origin main
git merge origin/main --no-edit
これで全 worktree の AI セッションが同じ skill を参照するようになります。
さらに、各 worktree 専用の domain skill (domain-exam, domain-lessons 等) の末尾に 1 行追記:
## 作業完了時の記録
PR を出したり、機能を 1 つ完成させたら、`notion-knowledge-hub` skill に従って Notion DB に記録する (`worktree: "exam"` を指定)。
worktree ごとに自動で「worktree」列に正しい値が入る形にしました。
9. やってみてどうなったか
実際に運用を開始した日 (2026-06-07) に、過去の作業を 10 件 backfill (遡って登録) しました。AI が全部書いてくれました。
- 3-tier LLM フォールバック設計 (開発状況)
- AI 機能の GPU-PC 完全ローカル化 (開発状況)
- PR #50: 白テーマ色修正 (開発状況)
- PR #56: AI 質問ボタンを解説画面のみに (開発状況)
- PR #58: maxDuration 漏れ修正 (開発状況)
- PR #66: RAG 精度向上 (開発状況)
- Zenn 記事ドラフト (ナレッジ)
- ステークホルダーへの連絡文 (メモ)
- 6 時間 deploy 障害 (障害)
- 短命ブランチ運用への移行 (意思決定)
10 件投入する手間は 10 分くらい。1 件 1 件考えて書いてたら 2 時間コースだったと思います。
効いたところ
- 検索性: 「先週何やったっけ?」が DB を見るだけで分かる
- 横断視点: worktree ごとの作業頻度の偏りが見える
- AI セッション間の知識移転: 別 worktree のセッションが「あ、exam で先週これやったのね」と理解できる
- 手間ゼロ: AI が書くので人間の継続力に依存しない
- 連絡履歴も残る: 「合田先生にいつ何送ったか」が辿れる
効かなかったところ (正直に書く)
- 書きすぎ問題: AI が「書くタイミングです」と頻繁に提案してくる → skill に「書きすぎない目安」を追記して調整
- 個人情報の判定: 一度「実ドメインを書いていいか?」と確認してきた → 公開禁止情報リストを skill に明文化
- タグの揺れ: 似たタグ (例:「ドキュメント」と「Docs」) が混ざる → 選択肢を固定で持つ列にすることで解決
10. 設計判断と気をつけたこと
判断 1: なぜ「種別」を 7 つにしたか
最初 5 つで始めましたが、運用してて足りないことに気づき:
- 開発状況: PR や実装
- 意思決定: 運用ルール変更などの方針判断
- タスク: まだ着手してない作業
- 案件: 補助金応募などの外部関係案件
- ナレッジ: 記事ドラフト / 学んだこと
- 障害: インシデント
- メモ: その他
7 つあると「えっと、これどれ?」と迷うのですが、5 つだと「メモ」に逃げすぎてしまう。バランス重要です。
判断 2: 公開禁止情報を skill に明文化
AI に任せると「気を利かせて」実ドメイン名や個人情報を書こうとすることがあります。これは厳禁。
skill ファイルに次のリストを書きました:
- API キー / Bearer トークン / Webhook URL → 書かない
- 実ドメイン (
gpu.taichiendoh.com等) →gpu.example.comに - 生徒個人情報 → 書かない
- 内部 DB ID / Tunnel ID → 書かない
そして根本原則を 1 行で:
「仕組みは書く、具体仕様は書かない」
これがあれば AI が迷ったときに判断できます。
判断 3: 「進捗報告ページ」と「DB」を並行運用
実は「進捗報告」という日付別の自由記述ページも別途あります。
DB に統合する案もありましたが、
- 進捗報告: 日記 (自由記述、流れがあるストーリー)
- DB: 構造化レコード (検索・フィルタしやすい)
役割が違うので両方残しました。日記と台帳の関係です。
11. これから
- 過去 1-2 ヶ月分のさらなる backfill (覚えてる範囲で各 worktree が思い出した順に)
- 月次レビューの自動化 (DB から先月の振り返りを AI が要約)
- 公開可能なものだけ抽出して note や Zenn にダイジェスト
まとめ
worktree が 5 個になっても破綻しない仕組みを、Notion + Skill で作りました。
ポイントは 3 つ:
- AI に書かせる — 人間の継続力に頼らない
- Skill で「いつ・どう書くか」を明文化 — AI の判断軸を揃える
- 公開禁止情報を skill に書く — AI が独自判断しないようガードレール
「ひとり並列開発」をしている個人開発者の方の参考になれば嬉しいです。
この記事で使ったもの
- Git worktree (Git 標準機能)
- Notion (無料枠で十分)
- Claude Code (Anthropic 公式 CLI、Skill 機能あり)
- Notion MCP (Claude から Notion を操作する公式拡張)
すべて個人開発レベルで使える組み合わせです。
補足: 「AI が勝手にやる」の安全性
AI が勝手に書き込む = 暴走しないか心配、という方もいるかと思います。
実運用ではこうしています:
- 書き込み前に AI が「これから○○を Notion に記録します」と短く宣言する
- ユーザーは数秒で「OK」「やめて」と返せる
- 書き込んだ後の URL は別途確認できる
- 全自動ではなく「半自動」(人間が止められる) にしている
慣れてきたら全自動にしてもいいですが、最初は半自動から始めるのがおすすめです。
ここまで読んでくださってありがとうございました。