0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

個人開発で worktree が 5 個になったので、AI に自動でタスク管理させる仕組みを作った話

0
Last updated at Posted at 2026-06-07

はじめに

個人で複数のサービスを並行開発しているうちに、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 つの要素:

  1. Notion DB — 蓄積場所
  2. Notion MCP — AI が Notion を操作するための仕組み
  3. 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 は公式に用意されているので、それを有効化するだけ。

参考: Claude 公式 - 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 が以下のように動きます:

  1. ユーザーが「お疲れ」「マージしました」「完成です」みたいに言う
  2. AI が skill を見て「あ、Notion に書くタイミングだ」と判断
  3. ふさわしい種別・タグ・要約を AI が自動生成
  4. Notion DB に書き込み
  5. ユーザーには 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 つ:

  1. AI に書かせる — 人間の継続力に頼らない
  2. Skill で「いつ・どう書くか」を明文化 — AI の判断軸を揃える
  3. 公開禁止情報を skill に書く — AI が独自判断しないようガードレール

「ひとり並列開発」をしている個人開発者の方の参考になれば嬉しいです。


この記事で使ったもの

  • Git worktree (Git 標準機能)
  • Notion (無料枠で十分)
  • Claude Code (Anthropic 公式 CLI、Skill 機能あり)
  • Notion MCP (Claude から Notion を操作する公式拡張)

すべて個人開発レベルで使える組み合わせです。

補足: 「AI が勝手にやる」の安全性

AI が勝手に書き込む = 暴走しないか心配、という方もいるかと思います。

実運用ではこうしています:

  • 書き込み前に AI が「これから○○を Notion に記録します」と短く宣言する
  • ユーザーは数秒で「OK」「やめて」と返せる
  • 書き込んだ後の URL は別途確認できる
  • 全自動ではなく「半自動」(人間が止められる) にしている

慣れてきたら全自動にしてもいいですが、最初は半自動から始めるのがおすすめです。

ここまで読んでくださってありがとうございました。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?