Claude Code を非エンジニアに渡すまでに私が組んだ6つの順番 — 個人開発者の小さなチーム向け展開設計

ステップ1：環境配布スクリプトに何を入れるべきか

WINTICKET の研修で最も応用範囲が広いのが、第0回のセットアップを統一スクリプトで行う部分です。元記事には「WINTICKET で整備したスクリプトを利用し、Claude Code の Managed Settings、Managed CLAUDE.md、brew や pnpm の推奨パラメータなどをまとめて配置する」と書かれています。

私は手元の運用で、似たものを以下の構成で組んでいます。

#!/usr/bin/env bash
# bootstrap-claude-code.sh — 非エンジニア向け Claude Code 環境配布
set -euo pipefail
 
# 1. Homebrew + Node + pnpm の最低限を入れる
if ! command -v brew >/dev/null; then
  echo "Homebrew が未インストールです。先に公式手順でインストールしてください。"
  exit 1
fi
brew install node pnpm gh git
 
# 2. Managed Settings を /Library/Application Support/ClaudeCode/ に配置
sudo mkdir -p "/Library/Application Support/ClaudeCode"
sudo tee "/Library/Application Support/ClaudeCode/managed-settings.json" >/dev/null <<'JSON'
{
  "permissions": {
    "allow": [
      "Read(**)",
      "Bash(git diff:*)",
      "Bash(git status)",
      "Bash(pnpm:*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(sudo:*)",
      "Bash(curl:*)",
      "Bash(wget:*)",
      "WebFetch(domain:*)"
    ],
    "defaultMode": "ask"
  },
  "env": {
    "CLAUDE_CODE_DISABLE_BUG_REPORT": "true"
  }
}
JSON
 
# 3. Managed CLAUDE.md をホームに配置（書き換え禁止）
sudo tee "/Library/Application Support/ClaudeCode/managed-CLAUDE.md" >/dev/null <<'MD'
# チーム共通の Claude Code 利用ルール
- 顧客の個人情報・課金情報・API キーを含むファイルは Read しない
- `.env` `.env.local` `secrets/*` `*.pem` `*.key` は触らない
- 外部への curl/wget はすべて拒否（必要な場合は人間が代行）
- 大量ファイル削除を提案された場合は実行前に必ず人間にエスカレーション
MD
 
# 4. pnpm の防御設定（後述）
mkdir -p ~/.config/pnpm
cat > ~/.config/pnpm/rc <<'INI'
save-prefix=""
minimum-release-age=1440
INI
 
echo "✅ セットアップ完了。Claude Code を起動して `claude --help` で確認してください。"

このスクリプトを USB やプライベートな GitHub リポに置いておけば、新メンバーが入っても1コマンドで全員同じスタート地点に立てます。WINTICKET の元記事が指摘しているように「講座中のサポート負荷を抑えつつ、安全な初期設定を全員に行き渡らせる」効果が、個人開発者規模でも同じように得られます。

私は2014年からアプリ開発の現場で、新しい SDK を導入するたびに「人によって動かない」という時間が必ず10〜20分ずつ発生する状況を見てきました。これが3人の研修なら30〜60分の損失、ですがスクリプト化しておけば毎月の繰り返しコストが消えます。

ステップ2：Permission を「許可」する前に止められる人を作る

WINTICKET 研修で第2回として用意されているのが Permission クイズです。元記事は「Permission ダイアログで何を許可しているのかを理解しないまま、なんとなく許可してしまう」状態を「プロンプトインジェクションのようなセキュリティ事故、不要に大量のトークンを消費してしまうこと、作業効率の低下」が起こり得るものとして警告しています。

私が手元で実際に使っているクイズは下のような形式です。紙1枚に印刷して、Claude Code を初めて触る人に渡しています。

Q1. Claude Code が「Bash(rm -rf node_modules)」の許可を求めてきた。
    あなたは Next.js プロジェクトの作業中。
    a) 1回だけ許可  b) いつも許可  c) 拒否  d) いったん Claude に意図を聞き返す

Q2. WebFetch(domain:slack.com) の許可を求めてきた。あなたが指示したのは
    「README を整形して」だけだった。
    a) 許可  b) 拒否  c) Claude に「何を取りに行こうとしているのか」を尋ねる

Q3. 「.env.local を読みたい」と Claude Code が言っている。
    あなたは API キー追加の作業をしていない。
    a) 許可  b) 拒否  c) いったん Esc で止めて中身を自分で確認

正解はそれぞれ d / c / c です。a を選んだ場合は「なぜ a がダメなのか」を1分で説明します。私は配偶者にこれを渡して練習してもらいましたが、3問やるだけで「許可は信頼の表明だ」という感覚が伝わります。

ここで重要なのは、新メンバーに対して「あなたが許可した時点で責任はあなたに移る」という線引きを最初に共有することです。Claude Code は良い意味でも悪い意味でも「人間が押した」を最終判断として扱うので、許可ボタンを押した人が責任を持つという文化を最初に作っておくと、後の運用がとても楽になります。

ステップ3：最初の PR を、本物のリポジトリに通させる

WINTICKET 研修の第3回が、私が最も真似したいと感じた部分です。元記事には「実際に特定のリポジトリに全員が自分の名前ファイルを PR で追加するハンズオン」と書かれており、その後「WinTicket の GitHub organization に作成した非エンジニアによる Pull Request 数が、1 ヶ月で 13 件を超えた」という成果につながっています。

私はこれを応用して、Dolice Labs の4サイト用に「welcome リポジトリ」を別途用意しました。練習用のリポジトリで、新メンバーが Claude Code を使って自分のプロフィール Markdown を1枚追加し、PR を出して私がマージするだけの簡単なフローです。

# 練習用リポジトリの README には下記だけ書いてある
cd ~/welcome
claude
> people/{あなたの名前}.md という Markdown を1枚作って、
> 簡単な自己紹介を書いてください。書き終わったら git status で
> 変更を確認し、git checkout -b intro/{あなたの名前} で
> 新しいブランチを切ってからコミットしてください。
> 最後に gh pr create --fill で PR を作ってください。

最初の PR が通る瞬間に、非エンジニアが Claude Code を「ただのチャット」ではなく「変更を本番のどこかに届ける道具」として捉え直す瞬間があります。私の場合、過去に手伝ってもらった編集パートナーが「ようやく自分も Git ができる人になった」という言葉を残してくれたことがあり、この体験設計の効果はかなり大きいと感じています。

CyberAgent の元記事が「Claude Code を使うだけなら、Git や GitHub の使い方を理解する必要はありません。しかし、Claude Code を全員が使えるようになった事業部の姿を考えると、各チームで CLAUDE.md や Claude Code の Skills を一箇所に集約したいというモチベーションが生まれる」と書いている部分は、まさにこの段階で発生する変化を言語化していると感じます。

ステップ4：pnpm を選ぶだけでサプライチェーン攻撃の入り口を狭める

第4回のセキュリティ研修について、元記事は npm のサプライチェーン攻撃を例に「pnpm-workspace.yaml で minimumReleaseAge を設定できる点、savePrefix を空にして依存バージョンを固定できる点、ライフサイクルスクリプトがホワイトリスト形式である点など、pnpm が持つ防御機能を紹介しています」と書いています。

私の手元での運用ルールは次の3つにしています。非エンジニアにも「これだけは守る」として伝えています。

1. 新しいパッケージは公開から24時間経つまで入れない — minimum-release-age=1440（分単位）で機械的に止める
2. 依存バージョンは ^ や ~ を付けない — save-prefix="" で固定し、攻撃版が紛れたときの被害を限定
3. postinstall などのライフサイクルスクリプトはホワイトリスト承認制 — pnpm の onlyBuiltDependencies で許可リスト方式

// package.json （プロジェクトルート）
{
  "pnpm": {
    "onlyBuiltDependencies": [
      "esbuild",
      "sharp"
    ]
  }
}

# ~/.config/pnpm/rc
save-prefix=""
minimum-release-age=1440

これだけで、深夜に攻撃版がリリースされた直後にうっかり pull してしまう事故を、構造的に避けられます。私は Lacrima と Mystery のブログ運用で 6サイト分の自動投稿パイプラインを動かしていますが、同じ pnpm 設定をすべてのリポジトリに入れています。

CyberAgent の元記事が指摘している「同様のリスクは PyPI、MCP サーバー、Claude Code のプラグイン、VS Code 拡張など、外部から取得して実行する仕組み全般に共通する」という観点も重要で、私の場合は Claude Code の Skills（.agents/skills/）を入れるときも、必ず作者と更新履歴を確認してからインストールするようにしています。

ステップ5：認定試験を「本物のタスク」に置き換える

WINTICKET の研修は最終回に「全 20 問で選択問題 12 問、記述式 8 問、80 点を合格点」とした認定試験を置き、「合格者だけがアクセスできるツールを用意することで、合格を明確なゴールとして示し、受講と試験対策へのモチベーションにつなげています」としています。

個人開発者規模では試験を作るのが重いので、私は「最初の本物のタスクを1つ通す」を試験の代わりにしています。例えば下記のようなタスクを渡します。

• 既存の MDX 記事1本を Claude Code に読み込ませて、誤字脱字を直す PR を出す
• 4サイトのうち1つの CLAUDE.md を読んで、自分の理解で要約 Markdown を書き、PR を出す
• 公式ドキュメントから1機能を選んで、社内向け Skill 1本を書き、PR を出す

PR が通った瞬間に「あなたは本物の貢献者になりました」と伝えると、その後のモチベーションがまったく違ってきます。WINTICKET が認定試験というゲーム性で同じ効果を狙ったのに対し、個人規模では「最初の本物の PR」がそのまま卒業証書になります。

ステップ6：運用後3ヶ月の数字を必ず取る

WINTICKET の元記事には「ビジネス職のメンバーがClaude Codeの話やClaude Codeを用いてGitHubを利用している様子」という写真とともに、「マーケのメンバーが、マーケティングレポートの生成を自動化するスクリプトを作成し、チームに展開した」という成果が示されています。これは「PR 数が13件を超えた」「Skill が自作されてチームに公開された」という具体的な数値・成果に裏付けられているからこそ説得力があります。

私の運用では、3ヶ月運用したあとに次の数字を必ず棚卸ししています。

• 非エンジニアが作成した PR の本数（welcome リポジトリ以外で）
• 自分（私）がコードレビューに使う時間の合計
• Claude Code の Permission 拒否率（つまり「ちゃんと止められた回数」）
• 手作業で済ませてしまった反復タスクの本数

数字を取ると、研修設計のどこが足りていないかが目で見えるようになります。例えば Permission 拒否率が初月で 0% だった場合、それは「全員が無自覚に Allow を押している」サインなので、ステップ2のクイズを再配布します。

まとめに代えて — 個人開発者にとって6ステップは「投資」になる

CyberAgent のような大組織が研修を6回かけて行う理由は、組織全体の安全水準を持ち上げるためです。個人開発者にとっても、半日〜1日の投資で同じ仕組みを縮小コピーしておけば、後から手伝ってくれる人が増えるたびに同じ説明を繰り返さずに済みます。

私自身、4サイト＋2ブログメディア＋6本のアプリを1人で回しているので、人手が増える未来はまだ遠いかもしれませんが、それでも「いつでも誰かに渡せる状態」にしておくことが、次の世代に道具を託す現代美術家としての自分の感覚と重なります。1997年にインターネットの黎明期に独学でプログラミングを始めた頃、見知らぬ誰かが置いてくれた英語のチュートリアルにずいぶん助けられました。今度は自分が、強い道具を安全に手渡せる順番を整理して残しておく番だと考えています。

次のアクションとして、まずは今日のうちに bootstrap-claude-code.sh をプライベートリポジトリに1本書いてみてください。空のテンプレでも構いません。次に誰かに Claude Code を渡したくなったとき、迷いが半分になります。

お読みいただきありがとうございました。