本記事に登場する
HUMAN_INPUTマーカーとは、AI 執筆 skill が記事本文に残す「ここは人間が後で確定値を埋めるべき」を示すプレースホルダー（形式例:<!-- HUMAN_INPUT: 数値を記入 -->）。
本記事はテックリード / シニアエンジニア / アーキテクト向けに、Claude Code を非エンジニアに安全に展開するための設計パターンを整理する。経営判断（何を委ねるか・投資の意思決定・ROI の測り方）は sister pillar 「非エンジニアが Claude Code を使う組織設計」 に委ねる。ここでは tech-lead が設計・実装できるレベルの技術的担保 を扱う。
非エンジニアへの Claude Code 展開は、3 軸で技術的に担保できる:
- CLAUDE.md の 3 層スコーピング — global / project / directory で責務境界を分離する
- skill の I/O 制約 — 入力・出力・禁止操作を宣言して scope creep を機械的に防ぐ
- permission model の 3 レイヤー — read-only zone / write guard / bash 禁則でファイル操作の安全網を張る
この 3 軸が揃っていない状態で非エンジニアに Claude Code を渡すと、何が起きるかを先に示しておく。
Key takeaway 3 点:
- CLAUDE.md は「書けばよい」ではなく「どの層に何を書くか」の責務設計が本質だ。global / project / directory の 3 層を混同すると、制約が衝突して非エンジニアが混乱する
- skill の I/O contract（入力・出力・禁止操作の宣言）は、scope creep の機械的な遮断装置だ。宣言がなければ LLM は文脈から「良かれと思って」範囲外を実行する
- permission model のミスはサイレントに発生する。read-only zone を設定せずに「触らないよう指示した」だけでは、非エンジニアが Claude Code の操作範囲を理解しないまま使い続ける
なぜ非エンジニアへの Claude Code 展開を設計するのか — 八雲の dogfooding 文脈
非エンジニアが Claude Code を使う業務場面の実例
八雲では、Claude Code を使う主な担当者が「エンジニアではない代表（PM 兼事業責任者）」だ。具体的には以下の業務で Claude Code が稼働している。
- コーポレートサイト運用: Astro + React + Tailwind で構築したサイトの記事更新・デザイン調整。HTML/CSS の読み書きはできるが、アーキテクチャ設計は外部エンジニアのレビューが必要なレベルの担当者が日常的に操作している
- Synapse（業務横断エージェント組織）の skill 運用: Claude Code の
.claude/skills/に定義した提案書作成・議事録生成・週次レポートの各スキルを PM が直接呼び出す - 記事パイプライン（mcluhan エンジン）の操作: brief YAML を渡してエージェントが記事を生成する一連のフローを、コードを書かずに Claude Code 経由で操作する
具体的には、代表（PM 兼事業責任者）が 2025 年 7 月から daily で Claude Code を触り続けている。コーポレートサイトの記事更新、synapse の skill 呼び出し、mcluhan の記事パイプライン操作——いずれもコードを直接書かず、Claude Code を「業務インタフェース」として運用している。
これらは「Claude Code を使わせている」のではなく「Claude Code に渡せる環境を tech-lead が設計した」結果として成立している。設計がなければ、非エンジニアが Claude Code を操作した瞬間に scope 逸脱が起きる。
tech-lead が設計しないと何が起きるか
設計なしで非エンジニアに Claude Code を渡した場合、以下の 3 種類の問題が順番に発生する。
第 1 段階: scope 逸脱（最初の数日以内） Claude Code は「意図を伝えると実装まで完結させるエージェント」だ。非エンジニアが「このページのレイアウトを直して」と指示すると、Claude Code は関連すると判断した CSS ファイル、コンポーネント、時には設定ファイルまで書き換える。「直接触ってほしくなかったファイルが変わっていた」が第 1 段階の症状だ。
第 2 段階: 事故の無音進行（数週間以内） scope 逸脱が繰り返されても、非エンジニアにはどのファイルが変わったか判断できない。Git の diff を見ても意味が理解できないため、「動いているように見える」状態で積み上がっていく。
第 3 段階: 影響範囲の爆発（数週間〜数ヶ月後） 積み上がった変更の影響が本番で顕在化する。原因の特定が難しく、修正に通常の数倍の工数がかかる。
八雲では、このサイクルを最初の synapse 構築期に経験した。「制約は後で追加すればいい」という考えで始めて、権限を与えすぎた結果、エージェントが設定ファイルを書き換えて別業務に影響が出た。具体的には、Chrome の設定（タブグループ・固定タブ）をエージェントが勝手に削除し、日常業務の作業環境が一度リセットされる事態になった。並行して system-developer エージェントを ClaudeCode 上に構築済みだったため、原因特定 → 設定復元 → CLAUDE.md への scope 制約追加までを 約 3 日で完了させたが、もし system-developer が無ければもっと長引いた事故だ。
この体験が 3 軸設計の出発点だ。
CLAUDE.md の責務分離 — global / project / directory の 3 層スコーピング
global CLAUDE.md: 全プロジェクト横断で守らせるルール
~/.claude/CLAUDE.md（macOS では ~/.claude/CLAUDE.md）は、ユーザーが操作する全プロジェクトに適用される。ここに書いた制約は、プロジェクトを問わず常に有効だ。
global に書くべき内容:
# ユーザー共通設定
## ハードコード禁止（全プロジェクト共通）
- マジックナンバー禁止: 色・フォントサイズ・スペーシングは設定ファイルから参照する
- フォント直接指定禁止: loadFont を個別コンポーネントで呼ばない
## コミット規約
- コミットメッセージは英語
- 1 コミット = 1 論理単位global に書いてはいけない内容:
- プロジェクト固有のディレクトリ名・ファイル名
- 特定プロジェクトの禁止操作（例:
src/content/magazineを直接編集禁止） - 業務ドメイン固有のルール（「提案書は Google Drive に保存」など）
プロジェクト固有のルールを global に書くと、他プロジェクトでの操作を意図せず制限する。非エンジニアが「別のプロジェクトで動いていたのにここでは動かない」という混乱を起こす。
project CLAUDE.md: プロジェクト固有の制約
プロジェクトルートに置く CLAUDE.md は、そのプロジェクト内での全操作に適用される。非エンジニアが操作する前に tech-lead が整備すべき、最も重要な層だ。
project に書くべき内容:
# Corporate Site
## 参照先ドキュメント（判断前に読む）
| 参照先 | 内容 |
|---|---|
| `src/_docs/ARCHITECTURE.md` | SSOT マップ・ハードコード禁止一覧 |
| `src/_docs/DESIGN.md` | 視覚言語（色・タイポグラフィ・余白） |
## 不変規約
- Git: コミットメッセージは英語。作業は `develop` ブランチ（main 直 push 禁止）
- ハードコード禁止: 値は SSOT に置いてから参照する
- `src/` 配下を編集する前に該当ディレクトリの `_README.md` を読む
## 実装の委譲
- コード・config・YAML/JSON の構造化編集は原則として `web-developer` / `system-developer` に委譲project で必ず定義する 3 要素:
- 参照先の明示 — どのドキュメントを読んでから作業するか
- 不変規約 — 違反が即座に問題になる制約（Git ブランチ・ハードコード禁止）
- 委譲ルール — 何を誰に委ねるか（非エンジニアが直接実行すべきでない操作の明示）
directory _README.md: ディレクトリ単位のスコープ制限
CLAUDE.md の指示だけでは「プロジェクト全体の制約」しか表現できない。ディレクトリ単位でスコープを絞るために、各ディレクトリに _README.md を置く。
八雲の corporate-site では、src/content/magazine/_README.md に以下を定義している:
# Magazine Content
記事は `{cluster}/{category}/{slug}.md` のパスに置く。
ファイル名規約: `{YYYY-MM}-{kebab-case-slug}.md`
## 操作可否
- slug frontmatter フィールドは変更禁止（URL に直結する）
- cluster・category は物理パスと frontmatter が一致していること
- draft: true の記事は直接編集可。draft: false は blog-gate を通すClaude Code は src/content/magazine/ 配下のファイルを操作する前に、この _README.md を読む。非エンジニアが「記事を追加して」と指示すると、エージェントは _README.md の規約に従ったパスに適切なフォーマットで記事を配置する。
3 層の優先順位と衝突解決ルール
3 層の優先順位は directory _README.md > project CLAUDE.md > global CLAUDE.md だ。より具体的な制約が優先される。
衝突の典型例:
| 衝突パターン | 解決 |
|---|---|
| global「コミットメッセージは英語」vs project「コミット前に CHANGELOG を更新する」 | 衝突ではなく補完関係。両方を守る |
| global「ハードコード禁止」vs directory「このファイルの数値は固定値でよい」 | directory の制約が global より具体的なので directory 優先 |
| project「develop ブランチで作業」vs directory「このディレクトリは直接 main へ」 | 矛盾するため、どちらかを削除するか directory を更新する |
設計の原則: 下位層（directory）が上位層（global/project）を override できるが、矛盾はエラーとして認識できないまま動作する。tech-lead は 3 層間に矛盾がないか定期的にレビューする必要がある。
八雲での事例は 2026-05-18 の Opus 過剰実行だ。global CLAUDE.md の例外節とプロジェクト CLAUDE.md の委譲ルールが矛盾し、YAML 構造化 retrofit を main thread Opus が直接実行した（blog-ops/retros/2026-05-18-opus-mechanical-edit-overreach.md に記録）。
skill の入出力スコーピング — scope creep を機械的に防ぐ設計
I/O contract の書き方 — 入力・出力・禁止操作を SKILL.md に宣言する
skill（.claude/skills/{skill-name}/SKILL.md）は「作業手順の定義ファイル」だが、I/O contract がなければ LLM の自由裁量実行が始まる。I/O contract は以下の 3 要素で構成する。
# SKILL.md の I/O contract セクション
## 入力
- `slug`: 記事の識別子（string）
- `brief`: `blog-ops/articles/{slug}.yaml` のパス
## 出力
- `draft_md`: `blog-ops/output/rewrite/{slug}/draft_v{n}.md`
- `_state.json` の `current_version` フィールドのみ更新
## スコープ制限（禁止操作）
- `src/content/magazine/` 配下への直接書き込み禁止（出力は `blog-ops/output/` のみ）
- Git コミット・push 禁止
- 対象 slug 以外のファイルへの書き込み禁止この I/O contract が SKILL.md に存在することで、Claude Code は skill の実行範囲を事前に宣言された境界で制限する。非エンジニアが skill を呼んだとき、LLM は「I/O contract に書かれていないファイルは触れない」と解釈して動く。
運用上の手応えとして、I/O contract を SKILL.md で明示している skill（blog-tech-write / blog-case-write / blog-review 等）は、運用開始以降「contract に書かれていない場所への書き込み」が観測されていない。ただし違反試行を機械的にカウントするロギング基盤は未整備で、「遵守率 X%」のような定量データはまだ持っていない。次フェーズで gate のログから違反試行を自動集計する仕組みを組み込み、「I/O contract が機能している」ことを観測可能な指標に昇格させる予定だ。
I/O contract 設計の 3 原則:
- 出力先は具体的なパスで宣言する —
output/のような抽象パスではなくblog-ops/output/rewrite/{slug}/draft_v{n}.mdのように具体化する - 禁止操作は「何をしてはいけないか」ではなく「どこには書いてはいけないか」で書く — 範囲を正確に伝える
- Git 操作は明示的に禁止する — 指示しなければ「コミットしておこう」と判断することがある
scope creep パターン 3 つとその遮断方法
tech-lead が把握すべき scope creep の頻出パターンを整理する。
パターン A: 関連ファイルへの連鎖書き込み
症状: 「A ファイルを直して」という指示で、関連する B・C ファイルも「改善」される
原因: I/O contract に出力先が宣言されておらず、LLM がコンテキストから判断して「関連しそうなもの」も更新する
遮断方法: ## スコープ制限 に「対象ファイル以外への書き込み禁止」を明記する
パターン B: Git 操作の自動実行
症状: skill の実行後、自動的にコミット・push が行われる
原因: I/O contract に Git 操作の禁止が書かれておらず、「変更を保存するのは当然」という LLM の判断で実行される
遮断方法: ## スコープ制限 に「コミット・push 禁止」を明記する。加えて project CLAUDE.md に「コミットは明示的に指示されたときのみ」を書く
パターン C: 依存ファイルの自動更新
症状: config を変更する skill が、config を参照しているコンポーネントも「整合させるために」書き換える
原因: 変更の波及を「補完行動」として LLM が実行する
遮断方法: ## スコープ制限 に「参照先コンポーネントの書き換え禁止」を明記する。依存する変更が必要なら、別 skill として切り出して独立した I/O contract で管理する
skill の呼び出しスコープを CLAUDE.md に宣言する設計
skill の I/O contract だけでは不十分な場合がある。CLAUDE.md 側から「この skill はこのスコープで使う」を宣言する設計を追加する。
# project CLAUDE.md の skill スコープ宣言セクション
## skill の使用スコープ
- `blog-tech-write` は `blog-ops/articles/` に valid な brief が存在する場合のみ呼ぶ
- `web-developer` は `src/` 配下の実装のみ担当（Git 操作・config 変更は不可）
- `system-developer` は `scripts/` と `blog-ops/config/` の編集のみ担当この宣言により、非エンジニアが「blog-tech-write を呼んで」と指示したとき、CLAUDE.md 側の制約が先に適用される。brief が存在しない状態で skill が起動しようとしても、CLAUDE.md の制約が止める。
permission model の設計 — read-only zone / write guard / bash 禁則
read-only zone の設計 — 参照は許可・書き込みは禁止するファイル群
Claude Code の permission 設定（.claude/settings.json）の denyList を使い、特定ファイル・ディレクトリへの書き込みを禁止する。
// .claude/settings.json
{
"permissions": {
"allow": [
"Read(**)",
"Write(src/content/magazine/**)",
"Write(blog-ops/output/**)"
],
"deny": [
"Write(src/_docs/**)",
"Write(.claude/**)",
"Write(src/config/**)",
"Write(package.json)",
"Write(tsconfig.json)"
]
}
}read-only zone として設定すべきファイル群:
| ファイル / ディレクトリ | 理由 |
|---|---|
src/_docs/ | SSOT ドキュメント。変更すると全エージェントの挙動が変わる |
.claude/ | エージェント定義・skill 定義。変更は必ず tech-lead が行う |
src/config/ | brand.ts・seo.ts など。設計変更なしに書き換えるべきではない |
package.json / tsconfig.json | 依存関係・コンパイル設定 |
非エンジニアが「DESIGN.md の色定義を変えて」と指示したとき、read-only zone が設定されていれば Claude Code は「このファイルへの書き込みは許可されていません」と応答する。設定なしでは、意図せず視覚言語定義が書き換わる。
write guard の設計 — 書き込み可能範囲を最小化する方針
read-only zone の反対概念が write guard だ。「書き込んでよいのはここだけ」という allowList 方式で、書き込み範囲を最小化する。
write guard の設計方針は以下の 2 段階で考える。
段階 1: ロール別の書き込み可能範囲を定義する
非エンジニアが操作するロール（web-developer・system-developer）ごとに、書き込み可能範囲を分ける。
# CLAUDE.md の委譲ルールと write guard の対応
| ロール | 書き込み可能範囲 |
|---|---|
| `web-developer` | `src/components/`・`src/pages/`・`src/content/` |
| `system-developer` | `scripts/`・`blog-ops/config/`・`blog-ops/output/` |
| 非エンジニア直接操作 | `src/content/magazine/**/*.md`（記事本文のみ） |段階 2: 書き込み可能範囲はプロジェクトの進行とともに変更する
初期は最小 write 権限から始め、実績に応じて徐々に広げる。「全部書き込み可能にしておいて後で絞る」は機能しない。人間は「設定を変えるのが面倒」という理由で放置するからだ。最初から最小権限で始めることを原則とする。
八雲では .claude/settings.local.json の permission allow エントリを段階的に追加してきた。corporate-site / synapse 両リポジトリの settings.local.json の git history（git log --follow .claude/settings.local.json）で具体的な追加タイミングと判断の流れが確認できる。
bash 禁則の設計 — 非エンジニアに bash 実行を渡さないための設定
bash コマンドの実行は、非エンジニアに渡すにはリスクが高い。rm -rf・git push --force・データベースへの直接操作——これらを「意図せず実行させてしまう」設計上の欠陥は、permission model で防ぐべきだ。
// .claude/settings.json の bash 禁則設定
{
"permissions": {
"deny": [
"Bash(git push*)",
"Bash(git commit --amend*)",
"Bash(rm -rf*)",
"Bash(git reset --hard*)",
"Bash(git checkout --*)"
]
}
}bash 禁則の 3 カテゴリ:
| カテゴリ | 禁則例 | 理由 |
|---|---|---|
| 破壊的 Git 操作 | git push --force・git reset --hard | 履歴を消去・リモートを破壊する |
| ファイル削除 | rm -rf・find ... -delete | 取り消しできない削除 |
| インフラ操作 | gcloud・aws 系コマンド | 課金・本番環境への影響 |
代替パターン: bash を直接渡す代わりに、許可された操作を skill として定義する。「Git add・commit・push を一連でやって」という操作を skill に封じ込め、I/O contract で「push は禁止」を宣言する。bash ではなく skill 経由にすることで、禁止操作のゲートが通る。
事故防止パターン 3 つ — 八雲での実例から
パターン 1: CLAUDE.md 未整備によるスコープ逸脱
状況: synapse の初期構築時、CLAUDE.md に write guard も scope 制限も書いていない状態で非エンジニアが作業を依頼した。
何が起きたか: 「提案書スキルを改善して」という指示を受けたエージェントが、スキルファイルだけでなく、関連する config ファイル・他スキルとの依存部分を「整合させる」という判断で複数ファイルを書き換えた。直接依頼した変更は正しかったが、波及した変更が別業務に影響した。
原因の構造: CLAUDE.md に「対象ファイル以外は変更しない」という制約がなかった。LLM は「整合性を保つ」ことを合理的な判断として実行した。
設計的な解決: project CLAUDE.md に以下を追加した。
## 実装の委譲スコープ
- 依頼されたファイル以外は変更しない
- 「関連するから」という理由での追加変更は禁止
- 複数ファイルに影響が及ぶ変更は、事前に影響範囲を列挙してからユーザー確認を取る当時は影響ファイル数・復旧時間を systematic に記録していなかったが、CLAUDE.md に「依頼されたファイル以外は変更しない」というスコープ制約を加えた以降、同パターン（関連ファイル自動編集による波及）は観測されていない。「設計で潰せた」ことが可視化された最初のケースだ。
パターン 2: permission 過剰付与によるファイル破壊
状況: 開発中に「全ファイルへの Read/Write 権限を付与しておけば作業がしやすい」という理由で、settings.json の denyList を空にした。
何が起きたか: 非エンジニアが「サイトの設定を整理して」という曖昧な指示を出した。エージェントは src/config/brand.ts（ブランド設定の SSOT）の禁則語配列を「古そうなものを削除」という判断で書き換えた。すぐには気づかず、後続の blog-gate で禁則語チェックが正常に通過するようになり（本来 NG であるべき表現が通過していた）、複数記事が公開された後に発覚した。
原因の構造: write guard がなく、「整理」という曖昧な指示に対して LLM がファイルの目的を誤解した。SSOT ファイルへの write 権限があったことで、設計者が意図しなかった変更が行われた。
設計的な解決: src/config/ を read-only zone に設定した。設定ファイルの変更は tech-lead が直接行うルールを CLAUDE.md に明記し、非エンジニアによる操作対象から除外した。
2026-05-18 朝の blog-audit で発覚した。magazine-reset-timeline の一斉公開（48 本）で HUMAN_INPUT 漏出 4 本・内部リンク 76 本死滅が確認され、同日中に記事を撤退させた（commit 086bb9b7）。
パターン 3: skill 未定義による LLM 自由裁量実行
状況: 「週次レポートを作って」という業務を、skill として定義せずに直接 Claude Code に指示していた。
何が起きたか: 最初の数回は意図した形式のレポートが出力された。しかし LLM は毎回「どのファイルから情報を取得するか」「どの形式で出力するか」を自律的に判断するため、出力が一定しなかった。あるときは Google Drive へ直接保存しようとし（外部 API の操作が発生）、あるときは参照してはいけない顧客データのファイルを開いて情報を取得した（意図しないファイルアクセス）。
原因の構造: I/O contract がなかったため、「週次レポートを作る」という目的に向かって LLM が自律的に入力・出力・操作手段を選んだ。目的は正しかったが、手段が毎回異なり制御できなかった。
設計的な解決: weekly-report skill を定義し、I/O contract に以下を書いた。
## 入力
- 参照ファイル: `data/weekly-metrics.json`（このファイルのみ）
## 出力
- `reports/weekly/{YYYY-MM-DD}.md`（このパスのみ）
## スコープ制限
- 外部 API 呼び出し禁止（Google Drive・Sheets への直接操作禁止）
- `data/` 配下の `weekly-metrics.json` 以外のファイルへのアクセス禁止.claude/skills/ 配下に skill 定義が集約されている。主要なものは .claude/skills/blog-tech-write/SKILL.md、.claude/skills/blog-review/SKILL.md、.claude/skills/blog-plan/SKILL.md、.claude/skills/blog-fact-check/SKILL.md、.claude/skills/blog-fill-ssot/SKILL.md などだ（find .claude/skills -name 'SKILL.md' で一覧確認できる）。
3 パターンの共通構造と事前設計でどう防ぐか
3 つのパターンに共通する構造がある。
| パターン | 欠けていた設計要素 | 設計的な対応 |
|---|---|---|
| スコープ逸脱 | project CLAUDE.md のスコープ制限 | 「対象以外は変更禁止」を CLAUDE.md に宣言 |
| ファイル破壊 | read-only zone の設定 | settings.json の denyList で SSOT を保護 |
| 自由裁量実行 | skill の I/O contract | 入力・出力・禁止操作を SKILL.md に宣言 |
共通するのは「LLM は指示の空白を自律的に埋める」という性質だ。設計の空白は LLM の自由裁量実行を招く。tech-lead の仕事は「制約の設計」ではなく「空白の撲滅」として理解するとよい。
事前設計のチェックリスト:
- CLAUDE.md の 3 層（global / project / directory）に矛盾がないか
- 各 skill に I/O contract（入力・出力・禁止操作）が宣言されているか
- settings.json の denyList に SSOT ファイル・インフラ設定が含まれているか
- bash 禁則に破壊的操作（force push・rm -rf）が含まれているか
八雲での dogfooding — Synapse で実際に動いている設計
八雲では Synapse（Claude Code 上に組んだ業務横断エージェント組織。.claude/agents/ の責任者エージェント群 + .claude/skills/ のスキル群）を、この 3 軸設計の上で運用している。
具体的な構成例:
global CLAUDE.md: ハードコード禁止・一人称ルール・GitHub アカウント切り替え規約
project CLAUDE.md（corporate-site）: 参照先ドキュメント一覧・develop ブランチ規約・委譲ルール・ハードコード禁止のプロジェクト固有版
directory _README.md（src/content/magazine/）: 記事の物理構造・frontmatter 必須フィールド・slug 変更禁止
settings.json denyList: src/_docs/・src/config/・.claude/・package.json
skill I/O contract（blog-tech-write）: 入力は brief YAML のみ、出力は blog-ops/output/ のみ、コミット禁止・src/content への直接書き込み禁止
この設計により、非エンジニアの代表が日常的に Claude Code を使って記事管理・サイト更新を行っても、設計者（tech-lead）が意図した範囲を逸脱しない状態が維持されている。
非エンジニアの代表が daily で Claude Code を操作している直近 3 ヶ月、scope 逸脱由来の事故は 0 件で運用できている。「設計で防げている」ことの傍証として捉えているが、件数を機械的に集計する仕組みはまだない。今後は gate のログから「防御が発火した回数」を自動カウントする計装を入れて、0 件で運用できている を N 件の試行を gate が止めた のように観測可能にする予定だ。
sister 記事への接続 — 経営判断の narrative
本記事は「tech-lead が設計・実装する側の技術論」だ。CLAUDE.md の構造設計・skill の I/O contract・permission model の設定——これらは全て「設計として書ける」具体的なパターンを扱った。
この設計を「誰に渡すか」「何の業務から始めるか」「どの段階で権限を広げるか」という意思決定の軸は、経営者・PM 側の判断だ。
sister pillar 「非エンジニアが Claude Code を使う組織設計」 では、同じ設計環境を「使う側（非エンジニア）」の narrative で書いている。skill 委譲の段階的な進め方・Stage 1〜3 の移行条件・KPI の設定——tech-lead が整えた環境をどう使うかの意思決定軸を扱う。
役割分担の整理:
| 役割 | 担当記事 |
|---|---|
| 環境を設計・整備する | 本記事（tech-lead 向け） |
| 環境を使う意思決定をする | sister pillar（非エンジニア / PM / 経営者向け） |
tech-lead が本記事の 3 軸設計を実装し、非エンジニアが sister pillar の stage 移行判断に従って使い始める——この役割分担が、Claude Code の組織展開を技術的・組織的に担保する。
汎用設計論（ハーネスのアーキテクチャ原則）は 「AI エージェントハーネスの設計原則」 で扱っている。本記事は Claude Code 固有の「非エンジニアに渡す」文脈に特化したパターンであり、ハーネス設計の一実装として位置付けられる。
まとめ — tech-lead が持ち帰る 3 軸設計の原則
非エンジニアへの Claude Code 展開は「渡すだけ」では機能しない。以下の 3 軸を設計した上で渡すことが、技術的担保の最小要件だ。
CLAUDE.md の 3 層スコーピング:
- global: 全プロジェクト横断の制約（ハードコード禁止・コミット規約）
- project: プロジェクト固有の参照先・委譲ルール・不変規約
- directory
_README.md: ファイル・ディレクトリ単位のスコープ制限
skill の I/O contract:
- 入力: 受け取るパラメータ・参照可能ファイルを明示
- 出力: 書き込み可能なパスを具体的に宣言
- 禁止操作: Git 操作・範囲外ファイルへの書き込みを明示
permission model の 3 レイヤー:
- read-only zone: SSOT ファイル・インフラ設定を denyList で保護
- write guard: 書き込み可能範囲を最小化した allowList
- bash 禁則: 破壊的操作（force push・rm -rf・インフラ操作）を明示的に禁止
3 つ全てが揃ったとき、初めて非エンジニアへの委譲が「設計として安全」になる。どれか一つが欠けていると、LLM が指示の空白を自律的に埋め始め、設計者が意図しない副作用が静かに積み上がる。
設計の完成は「最初に全部書く」ことではない。最小の制約から始め、事故から学んで追記し続ける——この改善サイクルを回す仕組みそのものが、非エンジニアへの安全な Claude Code 展開の本質だ。