🤖 AI運用ルール

Claude_動き方ガイド_状況限定ルール

最終更新 2026年06月15日 ／ 22_AI運用ルール/動き方ガイドアーカイブ/Claude_動き方ガイド_状況限定ルール.md

Claude_動き方ガイド 状況限定ルール

2026-06-15 にメイン Claude_動き方ガイド.md から切り出し。
セッション開始時の必読対象から外れ、該当状況時のみ明示Read。

戻る: Claude_動き方ガイド

Claude Code / Codex 並列運用ルール（2026-05-09更新・衝突防止の鉄則）

大串は Claude Code / Codex / 複数AIセッションで同じGoogle Driveフォルダを共有運用する前提。

鉄則：1システム = 1セッション

ルール 内容
鉄則 1つのシステム/ファイルには、Claudeセッションを1つだけ割り当てる
NG A・B両方が同じシステム/ファイルに同時に手を入れる
並列OK 違うシステム同士なら並列OK（A=scale-base / B=Vault整理 等）

衝突するパターン（やったら破滅）

シナリオ 何が起きる
同じファイルを両方が編集 後保存が勝つ → 先に書いた変更が消える
両方がVault .md 同時更新 Drive側で「競合コピー」生成 → ファイル分裂
両方が MEMORY.md 自動更新 インデックス壊れる
両方がSCALE Baseデプロイ Cloudflare race condition / changelog食い違い
両方が同じdevサーバー起動 ポート衝突
両方が同じgit repoで操作 中途半端なコミット / 未コミット変更上書き

共通ロック運用（Claude Code / Codex 必須）

Claude Code と Codex が同じ Obsidian / Google Drive / システムを触る時は、作業前に共通ロックを確認・取得する。

# 作業前に全ロック確認
~/Obsidian/scripts/ai_session_lock.sh list

# Vault全体を触る時
~/Obsidian/scripts/ai_session_lock.sh acquire vault codex 180 "AI運用ルール更新"

# システムを触る時
~/Obsidian/scripts/ai_session_lock.sh acquire scale-base claude-code 120 "KPI画面修正"

# 作業終了時
~/Obsidian/scripts/ai_session_lock.sh release vault
ルール 内容
作業開始 list で他セッションの作業中対象を確認
編集前 対象ごとに acquire <target> <tool> <ttl_minutes> "<note>" を実行
ロック中 ロック取得に失敗した対象は編集しない。読むだけにする
完了後 Vault反映・Drive同期・handoff作成まで終えてから release
迷う時 広い方をロックする。AGENTSや複数ノートなら vault

ロック実体は Google Drive 直下の _ai_work_locks/。Vaultの一方向rsyncに巻き込まれない場所に置く。

→ 詳細: 90_Meta/AI作業ロック/README

推奨分担（デフォルト）

セッション / ツール 担当領域 触っていい場所
Claude Code: デスクトップ版 実装・デプロイ専任 /scale-base, /scale-lead, デプロイ系, MEMORY.md更新
Claude: Chrome版 思考・ナレッジ・文章専任 Vault 21_ナレッジベース, 10_Daily, X記事生成
Codex 実装・検証・Vault更新補助 依頼された対象のみ。作業前にAI作業ロック必須

→ 物理的にファイルパスがカブらないよう分担する。

AIが守ること

  1. ユーザー依頼を受けたら、対象システムが「他セッションで同時進行している可能性」を意識する
  2. 怪しい時は「これ別セッションでもやってませんか？」と確認（同じ依頼を2セッションでやらされかけた疑いがある時）
  3. 共有ファイル（MEMORY.md / changelog.ts）の更新は片方からのみに統一
  4. デプロイは実装担当セッションから一本化（同じシステムを複数セッションからデプロイしない）
  5. ナレッジ担当セッションはコードを編集しない（/scale-base/ /scale-lead/ 等を触らない）
  6. 実装担当セッションのVault更新は最小限に（システム関連メモのみ。ナレッジ整理は別セッションに任せる）

最大の落とし穴

「両方に同じタスクをやらせる」 → 絶対NG

例: A・B両方に「SCALE BaseのKPI画面修正して」と頼む
→ 同じファイルを別の方向に書き換えて、片方の作業が消える / 退化が起きる

→ タスクは必ず片方だけに振る。両方使うのは「並列に違うことをする時」のみ。

新規事業・新規サービスの命名ルール（2026-04-29決定）

原則：SCALE 〇〇 で統一する。独立ブランドは「3条件全部満たす時だけ」例外的に許可。

命名フロー（Claudeが自動判定）

新規事業・新規サービス立ち上げ
        ↓
独立ブランド3条件チェック
   ① 領域が大きく異なる（営業 / HP制作 / エンタメ / 全く別市場）
   ② 既にブランドが温まってる or 独自に温める明確な意図あり
   ③ 将来スピンアウト・子会社化を視野
        ↓
3つ全部 YES？
  ├─ YES → 独立ブランド可（例: TERASU）
  │       + ただし「by SCALE」表記でファミリー所属を明示
  └─ NO  → SCALE 〇〇 で統一（強制）

既存判定（2026-04-29時点）

サービス 種別 判定根拠
TERASU 独立ブランド維持 3条件すべて満たす（HP制作・既に温まってる・スピンアウト視野）
SCALE CRM / Form / Call / CRM / List / Coach / Insight / Track / Script / Report / Match / Voice / Proposal SCALE 統一 営業領域
SCALE Base / Pilot SCALE 統一 業務オートメ領域
SCALE Sales Salon / AI Salon SCALE 統一 コミュニティ領域
SCALE Build SCALE 統一 システム開発領域・営業の延長

NG パターン（独立ブランド化を却下する判断）

  • 「カッコいい名前思いついた」→ ブランド分散のデメリット大
  • 「SCALEだとつまらない」→ 統一の複利を捨てる損失大
  • 「個性出したい」→ 個性は中身で出す
  • 「3条件のうち1つしか満たさない」→ 例外不可

Claude の振る舞い

新規事業・新規サービスの命名相談が来たら：

  1. 上記3条件を即チェック（聞き返さない）
  2. デフォルト「SCALE 〇〇」を提案（候補3-5案）
  3. 3条件満たすときのみ独立ブランド候補も含めて提示
  4. 判定した結果を依頼書に明記（命名タイプ: SCALE統一 / 独立ブランド フィールド）

既存サービス改名の扱い

  • 改名は コスト > メリット になりがち
  • 改名提案を受けたらメリット・デメリット表を出す
  • 最終判断は大串（このガイドで自動判断しない）
  • 改名決定したら本ガイドの「既存判定」テーブル更新

新規施策・新規システム時の依頼書作成ルール（2026-04-29追加）

大串が「新規事業やる」「新規施策やる」「新規システム作る」と言ったら、Claudeは必ず別セッション用の依頼書セットを先に作る。

対象トリガー

以下のキーワード・状況のいずれかが出たら自動でこのフローを実行：

  • 「新規事業」「新サービス」「新規施策」「事業構想」と言われた
  • 「新しいシステムを作る」「新規プロダクト」と言われた
  • 「別セッションで進めたい」「セッション分けたい」と言われた
  • ユーザーが「これは大きい話」というニュアンスで切り出した

必ず作る3点セット

# ファイル 役割
1 <該当フォルダ>/<NAME>_事業構想依頼書.md or <NAME>_開発依頼書.md 別セッション用のメイン依頼書。テンプレ準拠
2 <該当フォルダ>/_<NAME>_現在状態.md セッション切替対応・進捗管理
3 チャットに コピペ用依頼文 を提示 別セッションの最初のメッセージとしてそのまま貼れる形

テンプレート参照

22_AI運用ルール/Claude_開発依頼書テンプレート の14セクション構成に準拠：

  1. 概要
  2. スコープ（含む / 含まない）
  3. 必読ノート
  4. 議論したいトピック（チェックリスト）
  5. 守るべきこと
  6. 出力先（フォルダ構成）
  7. 完了基準
  8. 完了報告フロー
  9. 関連ノート
  10. 更新履歴

コピペ用依頼文の必須要素

<サービス名>（<カテゴリ>）の<目的>を進めます。

【依頼書】
<依頼書フルパス>

【現在状態】
<現在状態ノートフルパス>

【作業前に必ず読むもの】
1-N. <パス列挙>

【ゴール】
<1-3行>

【議論したいトピック】
A-N. <主要トピック列挙>

【守るべきこと】
- <制約列挙>

【出力先】
<フォルダ>

【完了基準】
<受け入れ条件>

【最初の一手】
<最初に議論したい項目>

【完了報告】
slack_post.sh: /Users/oogushiyuuki/株式会社SCALE/scale-company/slack_post.sh shirei "メッセージ"

このルールの目的

  • 別セッションで前提共有なしで即動ける状態を作る
  • 大串が「あれどうなった？」と何度も説明する必要をなくす
  • 依頼書のクオリティを毎回担保する（テンプレ準拠）
  • Vault に「事業ポートフォリオ」が自動で蓄積される

Claudeが NG な振る舞い

  • 「依頼書つくりますか？」と聞き返す → ❌ 作るのが標準動作なので聞かない
  • 依頼書なしで議論を進めようとする → ❌ 先に依頼書セットを作ってから
  • コピペ用依頼文を出さない → ❌ チャット応答に必ず含める