1人で8プロジェクトを並列開発する「業務OS」— Claude Code worktree × Skill × 公開前ゲート × Obsidianミラーvault

Posted at 2026-07-06

対象読者:個人開発を複数並走させているエンジニア/守秘要件の厳しい領域(医療・金融など)でAIコーディング支援を使いたい人/Claude Codeのworktree運用に興味がある人

はじめに:個人開発は「開発」より「運用」で詰まる

筆者は医療系のバックグラウンドを持つエンジニアで、本業のかたわら、国家試験対策・授業支援・産業データベース・受託案件など8つのプロジェクトを1つのモノレポ+git worktreeで並列開発しています。

この規模になると、詰まるのはコードではなく運用です。

どのプロジェクトの文脈だったか、AIも自分も忘れる
ドキュメントが増殖して、どれが最新かわからなくなる
医療系は守秘要件が厳しく、クライアント名や関係者名が公開物に混入したら一発アウト

この記事では、この3つを解決するために組んだ「業務OS」——worktree分割・AIモデルの使い分け・公開前ゲート・Obsidianミラーvault——の構成を、実際のコード付きで紹介します。

先に全体像を1枚で:

🔰 基本編:worktreeで「部屋分け」する

なぜブランチ切り替えではなくworktreeか

git worktree は、1つのリポジトリを複数のディレクトリに同時にチェックアウトできる機能です。

git worktree add ../Portfolio.exam feat/exam-platform
git worktree add ../Portfolio.lessons main

ブランチ切り替え方式との決定的な違いは、AIコーディングエージェントの文脈が混ざらないことです。Claude Codeはディレクトリ単位でセッション・設定・スキルを持つため、worktree = 「案件ごとの部屋」になります。受託案件のコードと教材開発のコードが同じ作業ディレクトリに同居しない、というのは守秘の観点でも効きます。

筆者の構成(8部屋):

worktree	役割
main	統合・共有層の変更・PR mergeのホーム
exam / lessons	研究対策・授業プラットフォーム
invest	試験系の実験場
hokkaido	産業データベース・3D可視化
studio	コンテンツ・3D実験
研究A / 研究B	研究ワーク(名称は伏せます)

CLAUDE.md = AIが毎回読む「ルール書」

各worktreeのルートに置く CLAUDE.md に、そのプロジェクトの前提・禁止事項・参照先を書いておくと、セッションをまたいでAIの挙動が安定します。人間の新人に渡すオンボーディング資料と同じ発想です。

🔧 実践編1:モデルの使い分けを設定ファイルで固定する

Claude Codeは複数モデルを切り替えられますが、上位モデルは利用枠の消費が大きい。そこで**「統括業務のmainだけ上位モデル、他worktreeは標準モデル」**を設定で固定します。

ポイントは設定の優先順位です:

セッション内 /model > 起動フラグ --model > 環境変数 > プロジェクトローカル設定 > ユーザー設定

これを利用して、mainのworktreeにだけプロジェクトローカル設定を置きます:

// ~/AI/Portfolio/.claude/settings.local.json (git管理外)
{
  "model": "claude-fable-5"
}

# ユーザーデフォルトは標準モデルに戻しておく(Claude Codeセッション内で)
/model opus

これで、mainで起動すれば自動的に上位モデル、他の7部屋は標準モデル。「今日はどのモデルだっけ」という運用判断そのものを消すのが狙いです。settings.local.json は名前の通りローカル専用で、.gitignore 対象にして他のworktreeやコラボレーターに波及させません。

教訓:設定ファイルを書き換えるとき、既存の permissions 等を上書きで消さないこと。筆者は「modelキーだけ追加」をAI側が判断して既存設定を保持してくれたおかげで事故を免れました。

🔧 実践編2:公開前ゲート(fail-closed設計)

医療系の個人開発・技術発信で最も怖いのは、クライアント名・施設名・関係者名の公開物への混入です。人間の目視チェックは疲れている日に必ず抜けます。そこで、公開前に必ず通す検査スクリプトを作りました。

設計原則は3つ:

ERROR / WARN の2段階:固有名の検出=ERROR(公開不可)、誇張表現や要確認箇所=WARN(人間が目視)
NGリストは外部ファイル・git管理外:NGリスト自体が機密の塊(伏せたい名前の一覧)なので、リポジトリに入れない
fail-closed:NGリストが読み込めない場合は「検証できない=公開不可」で止める

# publish_gate.py の中核部(抜粋・簡略化)
from pathlib import Path

NG_LIST_PATH = Path.home() / ".config" / "publish-gate" / "ng_terms.txt"  # git管理外

def load_ng_terms():
    try:
        lines = NG_LIST_PATH.read_text(encoding="utf-8").splitlines()
        return [l.strip() for l in lines if l.strip() and not l.startswith("#")]
    except OSError:
        return None  # 読めない

def main(path: str) -> int:
    ng_terms = load_ng_terms()
    if ng_terms is None:
        print("NGリストを読み込めません。fail-closed: 公開不可")
        return 1  # ← 読めない=検証不能=止める。ここが要
    text = Path(path).read_text(encoding="utf-8")
    errors = [t for t in ng_terms if t.lower() in text.lower()]
    if errors:
        print(f"ERROR {len(errors)}件: 公開禁止")
        return 1
    print("PASS(最終目視のうえ公開可)")
    return 0

実際の版では、これに加えて誇張表現の正規表現チェック(「〇〇%削減」に出典があるか等)、法律系記事での免責文言の有無、著者プロフィール要素の有無も検査しています。

もう1つ重要なのが、AIのスキル(Claude CodeのSkill機能)としてこのゲートを登録し、「公開して」と言われたら自動発動するようにしたことです。人間が「ゲートを通す」ことを覚えておく必要すらなくす——覚えておく運用は、いつか忘れるからです。

正規表現ゲートの限界も明記しておきます。固有名がなくても「〇〇区の在宅クリニック」のような属性の組み合わせで特定できる記述(間接推知)は検出できません。最終判断は必ず人間が行う設計です。

🔧 実践編3:Obsidianは「ミラーvault」で繋ぐ

docs/ には236本のMarkdownがあり、これをObsidianで読み・リンクし・スマホでも参照したい。ただし docs/ には守秘情報を含むファイルも混在しています。「docs/をまるごとiCloudやObsidian Syncに乗せる」は、除外設定のミス1つで漏れるopt-out型なので採用しませんでした。

代わりに採用したのが**ミラーvault方式(opt-in型)**です:

全ドキュメントのfrontmatterに機密軸タグを付与する

---
tags: [knowledge, public-ok]   # public-ok / pii / review の3値
date: 2026-07-04
status: done
---

public-ok のファイルだけを、公開前ゲートを通したうえでミラー用vaultにコピーする

#!/bin/bash
# sync_mobile_vault.sh — public-okのみを抽出してモバイル用vaultへ
set -euo pipefail
SRC="$HOME/AI/Portfolio/docs"
DST="$HOME/ObsidianVaults/mobile-mirror"   # ここだけiCloud同期

mkdir -p "$DST"
count=0
while IFS= read -r f; do
  # frontmatterに public-ok を持つファイルのみ対象
  if head -n 10 "$f" | grep -q "public-ok"; then
    # 公開前ゲート(fail-closed)を通過したものだけコピー
    if python3 "$HOME/.claude/skills/publish-gate/publish_gate.py" "$f" > /dev/null 2>&1; then
      rsync -a --relative "${f#"$SRC"/}" "$DST/" 2>/dev/null || cp "$f" "$DST/"
      count=$((count+1))
    else
      echo "SKIP(gate): $f"
    fi
  fi
done < <(find "$SRC" -name "*.md" -not -path "*/_private/*" -not -path "*/inbox/*")
echo "synced: $count files"

iPhoneのObsidianは mobile-mirror だけを開く

この方式なら、ゲートを通過したファイルしかスマホ側に物理的に存在しない。Mac側ではdocs/全体をローカルvaultとして開き(同期なし)、リンクグラフやMOC(Map of Content=ハブノート)で思考する。役割分担は「docs=下書きと思考、Notion=運用情報の正本、Obsidian=読むレイヤー」で、第3の正本を作らないのが鉄則です。

🎯 応用編:業務OS自体を「棚卸し」する

この構成を組んだうえで、先日AI(Claude CodeのFable 5)にリポジトリ全体の棚卸しレポートを書かせました。読み取り専用で、worktree状態・ドキュメント数・命名規約遵守率・タグ運用・リンク構造を実測させたところ、耳の痛い数字が出ました。

命名規約の遵守率:58%
相互リンク(wikilink)があるファイル:236本中32本
AI向けルール書(CLAUDE.md)に記載のスキル6件が、すべて実体なし

つまり「地図(INDEX・ルール書)と現地(実態)がズレていた」わけです。規約を作った時点で満足し、運用が追いついていなかった。個人開発の業務OSは、作った瞬間から腐り始めます。だからこそ:

棚卸しはAIに定期実行させる(読み取り専用・レポートのみ、という制約付きで)
直すのは「作る」ではなく「地図を実態に合わせる」から
失敗や乖離はログとして残す(成功譚より、後から効くのはこちら)

長時間の網羅調査はまさにAIの得意領域で、上位モデルを「統括のmainだけ」に割り当てた投資が一番効いたのもこの棚卸しでした。

🎯 発展:vaultに「反証」させる

棚卸し(地図と現地のズレ検出)をもう一歩進めると、蓄積したノートに自分の主張へ反証させる運用になります。きっかけは @DamiDefi氏の「Obsidian vaultを共同創業者として扱う」という整理で、要は「vaultは決定の後に整理する場所ではなく、決定の前に相談する相手」という発想の転換です。

これを本記事の構成に載せると、公開前のゲートが2枚になります。1枚目は前述の機密の門番(固有名・誇張が混入していないか)。2枚目が知的誠実さの門番——「これから公開する主張は、過去に自分が集めた一次情報と矛盾していないか」をAIにdocs/横断で検索・照合させ、矛盾する記録が見つかったら本文で応答するか主張を直すまで公開しない。あわせて、自分の立場を変えたときは旧ノート冒頭に「→ [日付] 改訂済み」フラグを付けておかないと、古いノートが誤った反証として飛んでくる——このメンテ義務も含めて、frontmatterのライフサイクルタグ(#stale)がそのまま使えます。筆者はCLAUDE.mdにこの運用を「パートナーシップ条項」として書き込み、朝イチの自動レポート(直近7日のノートから、気づいていない繋がり・形成中のパターン・現行方針との矛盾だけを報告させる)をn8nで組む準備を進めています。

まとめ

課題	打ち手
文脈の混線	worktreeで部屋分け+CLAUDE.mdで記憶を外部化
モデルコスト	プロジェクトローカル設定でmainのみ上位モデル固定
守秘情報の混入	公開前ゲート(fail-closed・NGリストはgit外・Skill化で自動発動)
スマホ同期の漏洩リスク	opt-in型ミラーvault(タグ+ゲート通過分のみ同期)
業務OS自体の陳腐化	AIによる定期棚卸し(読み取り専用)

共通する思想は1つで、「人間が気をつける」を設計から消すことです。守秘は入らない設計に、モデル選択は設定に、チェックは自動発動に。医療のヒヤリハット対策で「個人の注意力に頼る対策は最も弱い」と教わりますが、個人開発の運用もまったく同じでした。

注意事項

本記事は筆者個人の環境での構成例であり、動作・安全性を保証するものではありません。副業・個人開発での情報の取り扱いは、所属組織の就業規則やクライアントとの契約条件によって求められる水準が異なります。これは筆者の現時点での個人的見解であり、法的助言ではありません。実運用の判断は、契約書・就業規則・必要に応じて専門家への相談のうえで行ってください。

著者プロフィール

臨床工学技士 × AIエンジニア / 11年間、病院の医療機器の現場に立ち続けてきました。
いまはAIエンジニアとしても活動しながら、酪農学園大学の研究生として論文博士の取得を目指しています。
研究テーマの主軸は遺伝子医療の未来。そのうえで、医療現場と地続きにある病院のIT・サイバーセキュリティ・医療AI導入についても、現場で起きている課題と一次情報を突き合わせながら調べ続けています。

質問・誤りの指摘・「うちの環境ではこうしている」という事例の共有、いつでも歓迎します。

X:@endoh_taichi / Qiita:@TaichiEndoh / https://taichiendoh.com

参考

Claude Code 公式ドキュメント(settings・モデル設定): https://docs.claude.com/en/docs/claude-code/settings
git worktree 公式ドキュメント: https://git-scm.com/docs/git-worktree

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up