Claude Code 導入ロードマップ

あなたは私のClaude Code環境を「安全 ＋ 最適」にセットアップする専属アシスタントです。 私はプログラミングにあまり詳しくない前提で、専門用語は都度かみ砕き、各ステップは 「何を・なぜやるか」を一言説明してから実行してください。既存ファイルの上書きや削除など 戻せない操作は、必ず現状を見せて確認を取ってから行ってください。 各ステップの完了時は、やったことを1〜2行で報告してから次へ進んでください。 ※会社で使う場合：既に社内ルール（Gitの保管先、秘密情報の保管場所、作業フォルダの位置、 　命名規則など）があれば、それを最優先してください。本手順は不足を補う用途に留め、 　既存ルールと衝突する箇所は勝手に変えず、先に確認してください。 ■前提：目指す完成形（あなた＝AIがこの地図を基準に作業する） 以降のステップはすべて、次の構造を作るためのものです。この階層と流れを頭に入れ、 各ステップが「この地図のどこを作っているか」を意識して進めてください： 【PCの中】 ~/.claude（AIの設定・脳）… CLAUDE.md（指示書）／memory（記憶）／skills（道具） 作業フォルダ（例 C:\dev\）… プロジェクトごとに1フォルダ（各フォルダの中に .gitignore） 【GitHub側・すべてPrivate】 記憶用リポ／スキル用リポ（CLAUDE.mdの控えも同居）／各プロジェクトのリポ（別々の箱） 【流れ】 memory・skills → 2時間ごと自動push／各プロジェクト → 手動push／.env・鍵 → どこにも上げない 【会社・チームで使う場合の違い】 「各プロジェクトのリポ」の置き場所が「会社のOrganization」になり、共有脳リポ（会社の共通 ナレッジ・1つ）が加わって、メンバーはそれを clone して読む。記憶用・スキル用リポ（＝自分の 脳の控え）は会社利用でも本人の個人アカウントのまま（手帳は人に付く・成果は会社に付く）。 この振り分けはステップ1の質問4→ステップ6で行う ■ステップ0：まず環境を調べて報告 次を調べ、結果を箇条書きで報告してから先へ進んでください。 - OSの種類（Windows / Mac / Linux）とホームフォルダの場所。以降パスはこれに合わせる - 設定フォルダ（~/.claude）の有無。settings.json / CLAUDE.md / memory フォルダが既にあるか （あれば要点だけ要約） - 既存の作業フォルダやプロジェクトがあるか - 記憶(memory)が複数の場所（~/.claude/projects/*/memory）に散らばっていないか - git がインストールされているか（バックアップに必要。無ければ該当ステップで軽く案内） → これらから「新規セットアップ」か「既存環境の整理」かを判断して教えてください。 ■ステップ1：4つだけ質問 1. 作業用の親フォルダをどこにするか（提案：Windowsは C:\dev\、Mac/Linuxは ~/dev/） 2. 記憶のまとめ方はどちら？（ほとんどの人は(A)。迷ったら(A)） (A) 自分（自社）の仕事で使う → 記憶を1冊にまとめる。どの案件でも「あなた専属の秘書が 1人」いる状態になり、教えたことを全部覚えてくれる (B) 複数のお客さんから預かる仕事（受託・代行）が中心 → 一本化をしない（ステップ5を 飛ばすだけ。他のステップは(A)と全部同じ。バックアップも実施。対象の違いはステップ6に記載） ※(A)を選んでも“全部”が混ざるわけではない：各プロジェクトの記録・決めごとはそのフォルダ 内の.mdにまとまるので混ざらない。混ざり得るのは“AIが会話から自動で覚える記憶”だけで、 (A)のままだと「A社の案件で教えたことを、B社の案件の会話でもAIが覚えている」状態になる。 その文脈のうっかり混在も避けたい人だけ(B)を選ぶ ※(B)の正直な注意：記憶が分かれるのは「その案件のフォルダでClaude Codeを開いた時」だけ。 いつも親フォルダでまとめて開く使い方だと1つに混ざっていくので、(B)は「案件ごとに そのフォルダを開いて作業する」習慣とセットで初めて効く 3. バックアップ用のGitHubアカウントを持っているか（無くても他は進められる） 4. Claude Code等で開発するのは、あなたひとりか、他のメンバーもいるか： ・「1人」＝開発するのは自分だけ（会社に他の社員がいてもOK） → 箱は全部自分の個人アカウント ・「管理人」＝開発するメンバーが自分以外にもいて、あなたが会社の箱（Organization）を 作って管理する側（共有リポの用意と、そこへの自動バックアップも受け持つ役） ・「メンバー」＝管理人に招待されて、組織の一員としてClaude Code等で開発する側 →メンバーも、“自分専用の脳”のバックアップ（ステップ6・7）は自分の個人アカウントのPrivate リポで実行する（会社のOrganizationには脳リポを作らない。Organizationは共有脳と業務 プロジェクト用）。やらないのは“会社の共有リポ”への自動pushだけ（共有リポは clone して 「使う前に git pull」で参加。詳細はステップ6の分岐で案内） ※応答言語などの好みがあれば教えてください（デフォルト：日本語・非エンジニア向けに平易） ■ステップ2：作業フォルダを整える - 親フォルダ（例 C:\dev\）の下に、プロジェクトごとに独立したフォルダを作る方針にする - デスクトップやドキュメント直下で作業しない理由（散らかり・誤削除・バックアップ漏れ）を説明 - 「共有で使う資産（ナレッジ・素材）」と「個別プロジェクト」を分ける簡単な指針を示す ■ステップ3：セキュリティ設定（最重要・二重の守り） 「AIに読ませない」と「gitに上げない」は別物です。両方やります。 (a) AIに読ませない ＝ ~/.claude/settings.json の permissions.deny に 秘密ファイルの読み書き禁止を追記（公式推奨の書き方）： Read(//**/.env) Read(//**/.env.*) Read(//**/*.key) Read(//**/*.pem) Read(//**/*credentials*.json) Read(//**/.credentials*) Read(//**/secrets/**) Read(~/.ssh/**) Read(~/.aws/**) Edit(//**/.env*) Edit(//**/*.key) Edit(//**/*.pem) Edit(//**/*credentials*.json) Edit(//**/.credentials*) ※★先頭の「//」は必須。これが無い `**/.env` は「いま開いているフォルダの配下」しか 　守らず、デスクトップや別ドライブに置いた .env は素通りする（公式のdeny表に明記）。 　`//**/` と書くと「パソコン全体（全ドライブ）」が対象になる。 　`~/.ssh/**` のような `~/` 始まりはホーム基準で正しく効くので、そのままでよい。 　※Windowsのパスは照合前に `C:\Users\…` → `/c/Users/…` の形に直される ※Edit行は「読めないファイルを、中身を確かめないまま上書きして壊す」事故を防ぐため 　（読み取り禁止だけでは、書き込みまでは止まらない） ※既存の設定は消さず追記のみ。既存 settings.json があれば中身を見せてから統合する。 ※この設定後、.env の作成・編集はAIでなく自分で行う運用になる（キーがAIに渡らず安全） ※AIには「.envに必要な項目名の一覧」をREADMEやセットアップ手順に書かせる（キーの中身は渡さない）。 プログラムが実行時に .env を読むのはこの禁止の対象外なので、自動化は問題なく動く ※秘密でない設定値（モード切替・モデル名など）は .env に混ぜず config ファイル等に分けて置く。 こうするとAIが設定を確認でき、.env は「秘密だけの箱」として安心して封印できる (b) gitに上げない ＝ 各プロジェクトに .gitignore を作り、次を除外： .env .env.* node_modules/ output/ *.key *.pem .credentials* *credentials*.json settings*.json *.token .DS_Store *.mp4 *.mov *.wav （動画・音声。GitHubは100MB超のファイルを拒否するため素材は入れない） ※`.credentials.json`（認証トークン）はドット始まりなので `credentials*` では拾えない点に注意 (c) 鍵の“保管場所”＝暗号化された金庫（パスワードマネージャー）に大元を置く。 大元（マスター）は金庫に置き、各プロジェクトの .env には“実働コピー”だけを貼る、という型。 ※製品はどれでもよい。**既に使っている金庫（1Password・会社支給のもの等）があれば、 それをそのまま使う**（乗り換え不要）。会社にパスワード管理の規定があればそれが最優先。 まだ何も無い人への例：Bitwarden（無料枠あり）。 ※金庫アプリの導入はあなた自身（AIは代行しない）。この運用なら、PCが壊れても鍵が消えず、 共有・失効もでき、属人化しない。deny(a) と組み合わせると最も堅い（撮影・配信する人／お金が動く鍵／会社は必須）。 ※新規プロジェクト作成・キー更新のときだけ「金庫から値をコピーして .env に貼る」。渡し方自体は今まで通り。 (d) 危険な操作を“設定”で止める ＝ 同じ permissions.deny に次も追記（既存は消さない。 追記前に settings.json をバックアップし、追記後に JSON が壊れていないか確認）： Bash(rm -rf *) Bash(git add .) Bash(git add -A) Bash(git push --force*) Bash(git push * --force*) PowerShell(Remove-Item *) PowerShell(git add .) PowerShell(git add -A) PowerShell(git push --force*) PowerShell(git push * --force*) ※Windowsでは、コマンドがBashではなくPowerShellという別の仕組みで実行されることがあるため、 　両方のぶんの禁止を入れておく（PowerShell(Remove-Item *) は del・rm・rmdir の別名もカバー） ※`Bash(git push --force*)` だけでは、ブランチ名が先に来る書き方（例：git push origin main --force）を拾えない。 　ルールは位置ごとに照合されるため、真ん中に `*` を入れた行も一緒に入れる ※どの守りも万能ではないため、最後の砦は習慣：APIキーやパスワードをチャットに貼らない、 settings.json や CLAUDE.md に直書きしない。キーは必ず .env に置く。 ■ステップ4：AIへの指示書 CLAUDE.md を作る 置き場所は ~/.claude/CLAUDE.md（＝どのフォルダから起動しても必ず読まれる“全体共通の指示書”）。 ※作業フォルダ側（例 C:\dev\CLAUDE.md）に置く方法もあるが、その場合「そのフォルダの下で 　起動した時しか読まれない」ことを一言説明すること。迷ったら ~/.claude 側でよい。 最低限これを含める（簡潔に。長すぎるとAIが読み飛ばす）： - 応答は日本語・非エンジニア向けに平易に - APIキー/パスワードはコードに直書きせず必ず .env を使う - APIキーは“いま作業中のプロジェクトの.env”からだけ読む（別プロジェクトの.envを参照しない。 .envが無ければ作業を止めて「.envがありません。作成してください」と報告する） - 削除・外部へのデータ送信・設定変更の前に確認を取る - 新しいプロジェクトを作るときは、必ず最初にステップ3(b)と同じ内容の .gitignore を作る （＝この約束をCLAUDE.mdに書いておくことで、今後の全プロジェクトに自動で効く） - git add はファイル個別指定（git add . を使わない）、コミット前に .gitignore を確認 - .env を含むファイルがステージングされそうな場合は自動でブロックして報告する - GitHubに新しくリポジトリを作るときは、指示がない限り非公開（Private）で作る - プロジェクトの決まりごと・計画・進行メモは、そのプロジェクトのフォルダ内の .md ファイルに 記録する（AIの記憶(memory)だけに任せない。memoryは本人のPCにしかなく、チームでは他の人に 見えないため。リポ内の.mdならプロジェクトと一緒にGitHubへ上がって残る） ※既存 CLAUDE.md があれば上書きせず、内容を見せて統合案を出してから反映する。 ■ステップ5：AIの記憶を1か所にまとめる ※ステップ1で(A)を選んだ場合のみ - Claude Codeの記憶は「起動したフォルダごと」に別々に作られる仕様。放置すると散らばり、 「昨日教えたのに今日は知らない（＝別のノートに書いただけ）」が起きる - settings.json に "autoMemoryDirectory": "~/.claude/projects/<集約先>/memory" を設定して集約 - 既に散らばった memory があれば、中身を集約先フォルダへ移す提案をする（移動は確認後） ■ステップ6：バックアップ ※GitHubがある場合 【複数人の分岐（ステップ1の4で確認済み）】 - ひとり／脳の管理人 → このステップ6と次のステップ7をそのまま実行 - チームのメンバー → “自分専用の脳（自分のmemory/skills）”のバックアップは、 自分の「個人アカウント」のPrivateリポでステップ6・7を実行する（会社のOrganizationには 脳リポを作らない＝手帳は人に付く。箱が別々なので衝突もしない）。 実行しないのは“会社の共有リポ”への自動pushだけ（同じ箱に複数PCが自動pushすると 衝突の温床になる）。共有リポは管理人のものを clone し「使う前に git pull」で参加、 追加したい知識は管理人に渡す（＝個人の脳は各自が自動で守る／共有の脳はハブ1台、の二本立て）。 渡す知見は“それだけ読めば分かる完結した形”に整える（「◯◯リポを見ろ」という付箋型は、 そのリポを読む権限がない人に届かないため） - 会社で使う場合の共有リポの持ち主：理想は GitHubの Organization（会社所有の団体 アカウント・無料プランあり）。社員はメンバー招待（Readロール＝pull専用を強制できる） → 退職時はメンバーから外すだけで箱（脳）は会社に残る。 ただし、社長（トップ）本人の個人アカウント所有なら、リポの Settings → Collaborators で 招待する形でも開始してよい（注意：個人アカウントの非公開リポは全員に書き込み権限が付き 「読み取り専用」にできないため、「メンバーはpushしない」はルールで守る。あとから Transfer ownership で Organization へ移行できる）。 管理人の交代は「新PCで clone → スケジューラ登録」だけ（数分） - Private リポジトリを用意（記憶用・スキル用）。置き場所は1人でも会社利用でも 「本人の個人アカウント」（会社のOrganizationに入るのは共有脳と各プロジェクトのリポだけ）。 事業の制作物は各プロジェクトのリポジトリで別管理 リポ名の付け方：「memory-〈名前〉」「skills-〈名前〉」（例：memory-tanaka）＝誰の脳の 控えか一目で分かる形を推奨。1人の場合は任意（例：memory-backup / skills-backup）でもよい ※ステップ1で(B)を選んだ（＝記憶を一本化していない）場合：記憶は ~/.claude/projects/ の下に 案件ごとに分かれているので、その場合は projects 配下の memory をまとめて記憶用リポの バックアップ対象にする（散らばったままで問題ない。利用者が場所を意識する必要はない） - CLAUDE.md（AIへの指示書）も、記憶・スキルと同じくバックアップ対象に含める。 リポの外にある単体ファイルの場合は、その控え（コピー）をスキル用リポに入れて一緒に上げる （＝脳の3要素 memory・skills・CLAUDE.md が全部“消えない”状態になる） - 絶対に含めない：.env、鍵ファイル、.credentials.json（＝認証トークン）、 そして APIキーが混ざり得る settings.json（含めるなら鍵を消してから） - 安全のため ~/.claude 直下そのものは Git リポジトリにしない（settings.json・ .credentials.json＝認証情報が同居するため）。リポにするのは中の memory/ と skills/ だけ - git push の前に git status で秘密ファイルが混ざっていないか必ず確認する ■ステップ7：自動バックアップ（放置で守る）※GitHubがある場合 - 記憶・スキル（＋CLAUDE.mdの控え）に変更があれば、2時間ごとに自動でGitHubへ送る仕組みを、 OSの定期実行機能（Windows=タスクスケジューラ／Mac=launchd／Linux=cron）に登録する - 対象は memory/・skills/（＋CLAUDE.mdの控え）だけ。コードのフォルダは対象外 - スクリプトの作法：「*.md と .gitignore だけをステージ（git add . は使わない＝秘密が構造的に混入しない）」 「成功時は何もせず、失敗した時だけログ＋デスクトップに警告」（非エンジニアが一目で異常に気づける） - 初回だけ、スケジューラに登録する前に「送る対象の一覧（*.mdのみ・秘密なし）」を見せて OKをもらってから有効化する（何がGitHubに上がるのか本人が分かる状態にする） - 肝：アプリを1つも開いていなくてもOSが実行すること。ノートアプリのプラグインは“開いている間だけ”なので放置に不向き - ※これは「判断のいらない決まった処理」なのでOSに任せる。ニュース要約のような“頭を使う自動化”はAIのcron（別物） ■ステップ8：第二の脳に“最初の記憶”を入れる ※ステップ0の診断でmemoryが実質空だった場合のみ - 既にmemoryにメモが溜まっている人は、このステップは飛ばす（聞き直すと重複メモになるため） - 私に2〜3個だけ質問して（例：どんな仕事をしている人か／大事にしている進め方／今の主な案件）、 その答えを memory/ に「最初のメモ」として書き込み、MEMORY.md（目次）にも1行足す - ※パスワード・APIキー・個人を特定する秘密は聞かない・書かないこと - 狙い：空の脳のままだと効果を体感できない。最初のメモが入ると、次の会話からあなたの 前提を踏まえた返答になる（＝“分身の芽”） ■最後に：やったことを要約 - 作成/変更したファイルの一覧 - 「PCの外(GitHub)に置くもの / 絶対に置かないもの」の対応表 - 次にやること（最初のプロジェクトの作り方）を3行で