Claude Code 導入ロードマップ

あなたは私のClaude Code環境を「安全 ＋ 最適」にセットアップする専属アシスタントです。 私はプログラミングにあまり詳しくない前提で、専門用語は都度かみ砕き、各ステップは 「何を・なぜやるか」を一言説明してから実行してください。既存ファイルの上書きや削除など 戻せない操作は、必ず現状を見せて確認を取ってから行ってください。 各ステップの完了時は、やったことを1〜2行で報告してから次へ進んでください。 ※会社で使う場合：既に社内ルール（Gitの保管先、秘密情報の保管場所、作業フォルダの位置、 　命名規則など）があれば、それを最優先してください。本手順は不足を補う用途に留め、 　既存ルールと衝突する箇所は勝手に変えず、先に確認してください。 ■前提：目指す完成形（あなた＝AIがこの地図を基準に作業する） 以降のステップはすべて、次の構造を作るためのものです。この階層と流れを頭に入れ、 各ステップが「この地図のどこを作っているか」を意識して進めてください： 【PCの中】 ~/.claude（AIの設定・脳）… CLAUDE.md（指示書）／memory（記憶）／skills（道具） 作業フォルダ（例 C:\dev\）… プロジェクトごとに1フォルダ（各フォルダの中に .gitignore） PC全体の除外リスト（~/.config/git/ignore）… 秘密のファイル名。このPCの全プロジェクトに効く 【GitHub側・すべてPrivate】 記憶用リポ／スキル用リポ（CLAUDE.md・PC全体の除外リストの控えも同居）／各プロジェクトのリポ（別々の箱） 【流れ】 memory・skills → 2時間ごと自動push／各プロジェクト → 手動push／.env・鍵 → どこにも上げない 【会社・チームで使う場合の違い】 「各プロジェクトのリポ」の置き場所が「会社のOrganization」になり、共有脳リポ（会社の共通 ナレッジ・1つ）が加わって、メンバーはそれを clone して読む。記憶用・スキル用リポ（＝自分の 脳の控え）の置き場所は立場で分ける：社長・個人事業主と、副業・業務委託の人は本人の個人アカウント／ 社員（会社のPCで会社の仕事だけ）は会社のOrganizationの中の本人専用リポ（理由はステップ6）。 この振り分けはステップ1の質問4→ステップ6で行う ■ステップ0：まず環境を調べて報告 次を調べ、結果を箇条書きで報告してから先へ進んでください。 - OSの種類（Windows / Mac / Linux）とホームフォルダの場所。以降パスはこれに合わせる - 設定フォルダ（~/.claude）の有無。settings.json / CLAUDE.md / memory フォルダが既にあるか （あれば要点だけ要約） - 既存の作業フォルダやプロジェクトがあるか - 記憶(memory)が複数の場所（~/.claude/projects/*/memory）に散らばっていないか - git がインストールされているか（バックアップに必要。無ければ該当ステップで軽く案内） → これらから「新規セットアップ」か「既存環境の整理」かを判断して教えてください。 ■ステップ1：4つだけ質問（このほか、ステップ3で「AIに見せたくないフォルダ」を1つ聞く） 1. 作業用の親フォルダをどこにするか（提案：Windowsは C:\dev\、Mac/Linuxは ~/dev/） 2. 記憶のまとめ方はどちら？（ほとんどの人は(A)。迷ったら(A)） (A) 自分（自社）の仕事で使う → 記憶を1冊にまとめる。どの案件でも「あなた専属の秘書が 1人」いる状態になり、大事そうなことをAIが選んで覚えていく（毎回すべてを覚えるわけではない） (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等で開発する側 続けて、全員にもう1つ聞く（記憶とスキルの控えの置き場所が、これで決まる。ステップ6）： あなたは「社長・個人事業主」か、「社員（会社のPCで、会社の仕事だけに使う）」か、 「副業・業務委託（自分のPCで、ほかの会社の仕事もする）」か。 ※1人で使う人や管理人でも、雇われているなら「社員」 ※会社に置き場所のルールがあるか（管理人から言われているか）も聞く。あればそちらに従う →どの立場でも、“自分専用の脳”のバックアップ（ステップ6・7）は実行する。置き場所はステップ6の推奨 どおり。やらないのは“会社の共有リポ”への自動pushだけ（共有リポは clone して「使う前に git pull」で 参加。詳細はステップ6の分岐で案内） ※応答言語などの好みがあれば教えてください（デフォルト：日本語・非エンジニア向けに平易） ■ステップ2：作業フォルダを整える - 親フォルダ（例 C:\dev\）の下に、プロジェクトごとに独立したフォルダを作る方針にする - デスクトップやドキュメント直下で作業しない理由（散らかり・誤削除・バックアップ漏れ）を説明 - 「共有で使う資産（ナレッジ・素材）」と「個別プロジェクト」を分ける簡単な指針を示す ■ステップ3：セキュリティ設定（最重要・二重の守り） 「AIに読ませない」と「gitに上げない」は別物です。両方やります。 (a) AIに読ませない ＝ ~/.claude/settings.json の permissions.deny に 秘密ファイルの読み書き禁止を追記（公式推奨の書き方）： Read(//**/.env) Read(//**/.env.*) Read(//**/*.env) Read(//**/*.key) Read(//**/*.pem) Read(//**/*credentials*.json) Read(//**/.credentials*) Read(//**/secrets/**) Read(~/.ssh/**) Read(~/.aws/**) Edit(//**/.env*) Edit(//**/*.env) Edit(//**/*.key) Edit(//**/*.pem) Edit(//**/*credentials*.json) Edit(//**/.credentials*) Read(//**/token.json) Read(//**/client_secret*.json) Read(//**/.dev.vars*) Edit(//**/token.json) Edit(//**/client_secret*.json) Edit(//**/.dev.vars*) ※token.json・client_secret*.json＝Google（YouTube・Gmail など）の認証ファイル。.dev.vars＝Cloudflare の秘密置き場 ※★先頭の「//」は必須。これが無い `**/.env` は「いま開いているフォルダの配下」しか 　守らず、デスクトップや別ドライブに置いた .env は素通りする（公式のdeny表に明記）。 　`//**/` と書くと「パソコン全体（全ドライブ）」が対象になる。 　`~/.ssh/**` のような `~/` 始まりはホーム基準で正しく効くので、そのままでよい。 　※Windowsのパスは照合前に `C:\Users\…` → `/c/Users/…` の形に直される ※Edit行は「読めないファイルを、中身を確かめないまま上書きして壊す」事故を防ぐため 　（今の版の Claude Code では読み取り禁止だけでも同じ場所の書き換えは止まるが、ノートブックの編集と 　古い版では止まらないので、Edit も入れておく） ※既存の設定は消さず追記のみ。既存 settings.json があれば要点を見せてから統合する（秘密の値は伏せて見せる）。 ※この設定後、.env の作成・編集はAIでなく自分で行う運用になる（キーがAIに渡らず安全） ※AIには「.envに必要な項目名の一覧」をREADMEやセットアップ手順に書かせる（キーの中身は渡さない）。 プログラムが実行時に .env を読むのはこの禁止の対象外なので、自動化は問題なく動く ※秘密でない設定値（モード切替・モデル名など）は .env に混ぜず config ファイル等に分けて置く。 こうするとAIが設定を確認でき、.env は「秘密だけの箱」として安心して封印できる ※AIに見せたくないフォルダも封印できる（「何かを探して」と頼んだだけでも、AIは探す途中でフォルダの中を 通るため）。ステップ1の質問4の答えで分ける： ・「1人」：お客さんの資料、Dropbox・OneDrive・Googleドライブなどの同期フォルダ、ダウンロードなど 「AIに見せたくないフォルダ」があるか私に聞く。あれば Read(<フォルダ>/**) と Edit(<フォルダ>/**) の セットで同じ deny に足す（封印すると、AIにそのフォルダの資料を使う作業を頼めなくなることも一言添える） ・「管理人」：会社のフォルダは、会社として配る設定で守る（教材「会社としてClaude Codeを配るとき」）。 自分個人のダウンロードや同期フォルダは、「1人」と同じく足してよい ・「メンバー」：会社のフォルダは管理人の方針に従い、自分では足さない。個人のダウンロードや個人の 同期フォルダは足してよい 書き方：ホームの中は ~/ で始まる形（例 Read(~/Downloads/**)）。別のドライブは //ドライブ文字/… の形 （例 Read(//g/マイドライブ/**)）。同じ種類のファイルが別の場所にも散らばっていないかも確かめる (b) gitに上げない ＝ 各プロジェクトに .gitignore を作り、次を除外： .env .env.* *.env node_modules/ output/ *.key *.pem .credentials* *credentials*.json settings*.json *.token .DS_Store token.json client_secret*.json .dev.vars* （(a) の ※ と同じ、Google の認証ファイルと Cloudflare の秘密置き場） secrets/ （名前では拾えない鍵＝Google のサービスアカウント鍵のようなランダムな名前の鍵は、このフォルダに置く。 　(a) の Read(//**/secrets/**) と対になる） ※会社が .claude/settings.json（封印などの共通設定）を Git で配る場合は、settings*.json の次の行に 　!.claude/settings.json と書く（その1つだけを Git に入れる） *.mp4 *.mov *.wav （動画・音声。GitHubは100MB超のファイルを拒否するため素材は入れない） ※`.credentials.json`（認証トークン）はドット始まりなので `credentials*` では拾えない点に注意 ※同じ理由で `.env` だけでは `prod.env`・`本番.env` が素通りする。`*.env` も必ず入れる 　（前に文字が付いても拾えるよう、`*` で前後を囲めるものは囲む） さらに、PC全体に効く除外リストを作る（＝.gitignore を作り忘れたプロジェクトや、これから作るプロジェクトも、 このPCでは自動で守られる）。手順： ・まず git config --global --get core.excludesFile で、今の登録先を確かめる - 登録先が既にあれば、そのファイルを使う（場所は変えない。中身を見せて、足りない行だけ足す） - 無ければ ~/.config/git/ignore を使う（フォルダが無ければ作る。ファイルが既にあれば中身を見せて合流する） ・入れるのは秘密の名前だけ：.env .env.* *.env .dev.vars* *.key *.pem .credentials* *credentials*.json token.json client_secret*.json *.token secrets/ **/.claude/settings.local.json （settings*.json・node_modules/・動画などは入れない。全プロジェクトで隠れると困ることがあるので、 　各プロジェクトの .gitignore 側にだけ入れる） ・Claude Code が自動で書いた「**/.claude\settings.local.json」のような \ 区切りの行は git では効かないので、 上の一覧の最後の / 区切りの行に置き換える ・登録する：git config --global core.excludesFile "<使うファイルの場所>"（~/.config/git/ignore の場合も、念のため明示する） ・効いているか確かめる：どこかのプロジェクトで git check-ignore -v --no-index prod.env を実行し、 除外リストのファイル名と行番号が出れば合格 ※効くのはこのPCだけ。各プロジェクトの .gitignore も引き続き作る（他のPCやクラウドで作業するときのため） ※すでに Git に入っているファイルには効かない（これから足すファイルを止めるもの） ※~/.codex フォルダがある（Codex も使っている）Windows の人で、このあと git のたびに 　「unable to access … ignore」と警告が出るようになったら、自分で権限を変えずに講師に相談する (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へ上がって残る） - 記憶（memory）に、お客さんの個人情報・パスワード・APIキーを書かない ※既存 CLAUDE.md があれば上書きせず、内容を見せて統合案を出してから反映する。 ■ステップ5：AIの記憶を1か所にまとめる ※ステップ1で(A)を選んだ場合のみ - Claude Codeの記憶は「起動したフォルダごと」に別々に作られる仕様。放置すると散らばり、 「昨日教えたのに今日は知らない（＝別のノートに書いただけ）」が起きる - settings.json に "autoMemoryDirectory": "~/.claude/projects/<集約先>/memory" を設定して集約 - 既に散らばった memory があれば、中身を集約先フォルダへ移す提案をする（移動は確認後） ■ステップ6：バックアップ ※GitHubがある場合 【複数人の分岐（ステップ1の4で確認済み）】 - ひとり／脳の管理人 → このステップ6と次のステップ7をそのまま実行 - チームのメンバー → “自分専用の脳（自分のmemory/skills）”のバックアップも、ステップ6・7を実行する （置き場所は下の「立場ごとの推奨」。箱が人ごとに別々なので衝突もしない）。 実行しないのは“会社の共有リポ”への自動pushだけ（同じ箱に複数PCが自動pushすると 衝突の温床になる）。共有リポは管理人のものを clone し「使う前に git pull」で参加、 追加したい知識は管理人に渡す（＝個人の脳は各自が自動で守る／共有の脳はハブ1台、の二本立て）。 渡す知見は“それだけ読めば分かる完結した形”に整える（「◯◯リポを見ろ」という付箋型は、 そのリポを読む権限がない人に届かないため） - 会社で使う場合の共有リポの持ち主：理想は GitHubの Organization（会社所有の団体 アカウント・無料プランあり）。社員はメンバー招待（Readロール＝pull専用を強制できる） → 退職時はメンバーから外すだけで箱（脳）は会社に残る。 ただし、社長（トップ）本人の個人アカウント所有なら、リポの Settings → Collaborators で 招待する形でも開始してよい（注意：個人アカウントの非公開リポは全員に書き込み権限が付き 「読み取り専用」にできないため、「メンバーはpushしない」はルールで守る。あとから Transfer ownership で Organization へ移行できる）。 管理人の交代は「新PCで clone → スケジューラ登録」だけ（数分） - 管理人が Organization を作ったら、ブラウザの Settings → Member privileges で次の3つを、 管理人（私）が自分で設定する（AIは手順を案内するだけ。教材「はじめてのGitHub設定」補足D）： ①Base permissions を None（招待しただけでは、どのリポも見えない） ②Repository deletion and transfer の「Allow members to delete or transfer repositories for this organization」のチェックを外す（リポを消す・よそへ移すのはオーナーだけ。社員が辞めるときに、 自分の手帳リポを消したり個人アカウントへ移したりできないように） ③Repository visibility change の「Allow members to change repository visibilities for this organization」のチェックを外す（公開・非公開の切り替えはオーナーだけ） - Private リポジトリを用意（記憶用・スキル用）。置き場所はステップ1の4で聞いた立場ごとの推奨に従う （会社に置き場所のルールがあれば、そちらに従う）： ・社長・個人事業主 → 本人の個人アカウント（個人と会社がほぼ同じため） ・社員（会社のPCで、会社の仕事だけに使う）→ 会社の Organization の中に、本人が Private で作る 本人専用のリポ（Organization の名前は私に聞く。見られるのは本人と、Organization のオーナー＝管理人など）。作ったら、 Private になっているか・会社の Organization の中にあるかを確かめる（無料プランでは、 公開で作ってしまうのを会社の設定で止められないため）。記憶には仕事の話が書かれることが多いので、 辞めても会社に残り、会社が消すこともできるようにするため。 作ろうとして断られたとき（会社の設定でメンバーは作れない）や、会社の Organization がまだ無いときは、 個人アカウントにも作らず、管理人に送る依頼文「memory-〈名前〉と skills-〈名前〉を Private で 作って、私（GitHub名：〇〇）に書き込み権限を付けてください」を用意する。ステップ6・7は 後回しにして先へ進み、最後の要約に「バックアップは未完了」と書く。リポが届いたら、 このプロンプトをもう一度貼って「ステップ6から」と伝えれば続きから進む ※すでに個人アカウントへ自動バックアップしている社員は、勝手に止めたり消したりせず、 管理人に相談するよう伝える ・副業・業務委託（自分のPCで、ほかの会社の仕事もする）→ 本人の個人アカウント （ほかの会社の話が混ざるので、会社の箱には置かない。会社がそれを認めていることが前提なので、 管理人に一言確かめる）。そのかわり「契約が終わったら、この会社の分の記憶・スキルは消す」と 約束しておく（GitHub は過去の履歴にも残るので、消すときは講師か管理人に相談） ※社員の場合、辞めても持っていけるのは、会社の情報が入っていない「自分の進め方」（口調・確認のしかた・ 好きな手順など）だけ。これは ~/.claude/CLAUDE.md の自分用の部分に書いておけば、次の職場でも使える （持ち出す前に、会社の情報が入っていないか確かめる。CLAUDE.md を丸ごと持ち出さない） ※どこに置く場合も、記憶にお客さんの個人情報やパスワードを書かせないよう CLAUDE.md に書いておく （AIが自動で書く分は完全には防げないので、業務の決めごとはプロジェクトの .md に書くのが基本） 事業の制作物は各プロジェクトのリポジトリで別管理 リポ名の付け方：「memory-〈名前〉」「skills-〈名前〉」（例：memory-tanaka）＝誰の脳の 控えか一目で分かる形を推奨。1人の場合は任意（例：memory-backup / skills-backup）でもよい ※ステップ1で(B)を選んだ（＝記憶を一本化していない）場合：記憶は ~/.claude/projects/ の下に 案件ごとに分かれているので、その場合は projects 配下の memory をまとめて記憶用リポの バックアップ対象にする（散らばったままで問題ない。利用者が場所を意識する必要はない） - CLAUDE.md（AIへの指示書）も、記憶・スキルと同じくバックアップ対象に含める。 リポの外にある単体ファイルの場合は、その控え（コピー）をスキル用リポに入れて一緒に上げる （＝脳の3要素 memory・skills・CLAUDE.md が全部“消えない”状態になる） - PC全体の除外リスト（ステップ3(b)）も同じく、控え（コピー）をスキル用リポに入れて一緒に上げる。 控えの名前は gitignore-global.md に固定する（.md でないとステップ7の自動バックアップの対象に入らない。 中身は元のファイルそのまま。見出しなどを足さない） （新しいPCでは、その控えを元の場所に戻し、ステップ3(b) の登録を1行やり直せばよい。 　新しいPCに既に別の除外リストがあれば、消さずに中身を合流する） - 絶対に含めない：.env、鍵ファイル、.credentials.json（＝認証トークン）、 そして APIキーが混ざり得る settings.json（含めるなら鍵を消してから） - 安全のため ~/.claude 直下そのものは Git リポジトリにしない（settings.json・ .credentials.json＝認証情報が同居するため）。リポにするのは中の memory/ と skills/ だけ - 最初に GitHub へ送る（git push）前に、git status で秘密ファイルが混ざっていないか確かめ、 送るファイルの一覧を私に見せて OK をもらってから送る（何が GitHub に上がるのか本人が分かる状態にする） ■ステップ7：自動バックアップ（放置で守る）※ステップ6が終わった場合（後回しにしたら、ここも後回し） - 記憶・スキル（＋CLAUDE.md・PC全体の除外リストの控え）に変更があれば、2時間ごとに自動でGitHubへ送る仕組みを、 OSの定期実行機能（Windows=タスクスケジューラ／Mac=launchd／Linux=cron）に登録する - 対象は memory/・skills/（＋CLAUDE.md・PC全体の除外リストの控え）だけ。コードのフォルダは対象外 （控えは、毎回送る前にスクリプトが元のファイルをスキル用リポへコピーして作る。元のファイルは読むだけで書き換えない） - スクリプトの作法：「*.md と .gitignore だけをステージ（git add . は使わない＝.env や鍵のファイルは入らない。 ただし .md の本文に書いた秘密は送られるので、メモに秘密の値を書かない）」 「成功時は何もせず、失敗した時だけログ＋デスクトップに警告」（非エンジニアが一目で異常に気づける） ※スキルの中にプログラム（.py など）を入れると、自動バックアップには入らない。そのプロジェクトだけで 使うならプロジェクトのリポの .claude/skills/ に、どこでも使うならプログラムを GitHub のリポに 入れておく（このことを私に一言伝える） - 初回だけ、スケジューラに登録する前に「送る対象の一覧（*.mdのみ・秘密なし）」を見せて OKをもらってから有効化する（何がGitHubに上がるのか本人が分かる状態にする） - 肝：アプリを1つも開いていなくてもOSが実行すること。ノートアプリのプラグインは“開いている間だけ”なので放置に不向き - ※これは「判断のいらない決まった処理」なのでOSに任せる。ニュース要約のような“頭を使う自動化”はAIのcron（別物） ■ステップ8：第二の脳に“最初の記憶”を入れる ※ステップ0の診断でmemoryが実質空だった場合のみ - 既にmemoryにメモが溜まっている人は、このステップは飛ばす（聞き直すと重複メモになるため） - 私に2〜3個だけ質問して（例：どんな仕事をしている人か／大事にしている進め方／今の主な案件）、 その答えを memory/ に「最初のメモ」として書き込み、MEMORY.md（目次）にも1行足す - ※パスワード・APIキー・個人を特定する秘密は聞かない・書かないこと - 狙い：空の脳のままだと効果を体感できない。最初のメモが入ると、次の会話からあなたの 前提を踏まえた返答になる（＝“分身の芽”） ■最後に：やったことを要約 - 作成/変更したファイルの一覧 - 「PCの外(GitHub)に置くもの / 絶対に置かないもの」の対応表 - 次にやること（最初のプロジェクトの作り方）を3行で - 後回しにしたことがあれば、その一覧と再開のしかた（例：バックアップ＝管理人への依頼文と「ステップ6から」）