Claude Code100本ノック（初心者向け）

Claude Codeを使いこなすためのTipsを100本ノック形式で紹介します。
やり方はもちろん、メリットも記載しているので使えるところを参照してもらえばと思います。

Transcript

1. 実 践 ガ イ ド — 2 0 2 6 Claude Code 100本ノック スキル・CLAUDE.md・MCP・Hooks・エージェント設計を体系的に学ぶ実践課題 集。全100問に「やり方」と「なぜ使うか（メリット）」付き。AIを「使う」から 「設計する」レベルへ。 100 実 践 課 題 6 カ テ ゴ リ Q+A 全 問 解 答 付 き Claude Code 100本ノック — 一般公開版
2. O V E R V I E W Claude Codeとは、なぜ100本ノックか Claude Codeはターミナルから動くAI開発アシスタントです。単にコードを書くだけでなく、CLAUDE.mdに記述 したルール・スキルファイルのペルソナ・MCPによる外部ツール連携・Hooksによる自動化を組み合わせること で、AIが自律的にプロジェクトを推進するパートナーになります。本100本ノックは、その全機能を体系的・実践 的に習得するための課題集です。 「AIを使う人」と「AIを設計する人」の差は、これからの10年で決定的な競争優位になる。 — 本ノックの前提となる問い カテゴリ 問番号 問数 内容概要 🟢 環境構築 #001〜 #015 15 問 インストール・設定・GitHub連携・Auto Memoryで「AIと働く土台」を整 える 🟣 CLAUDE.md設計 #016〜 #035 20 問 AIへの「指示書（憲法）」を設計。TDDルール・プロジェクト文脈・禁止 事項を定義 🟠 MCP連携 #036〜 #055 20 問 GitHub・Google Calendar・Notion・SlackをAIに繋ぎ、情報収集〜タスク 作成を自動化 🟡 Hooks活用 #056〜 #065 10 問 AI行動の前後にスクリプトを挟む。危険コマンドブロック・自動通知・ Handover生成 🩷 エージェント・スキ ル #066〜 #080 15 問 スキルファイルでAIにペルソナを付与。モバイルから非同期で指示するフ ロー完成 🔵 上級編 #081〜 #100 20 問 全機能統合。PR自動化・ROI分析・CI/CD統合・チーム展開・記事化まで K E Y L E A R N I N G S 取り組みを通じた重要な学び Claude Code 100本ノック | 2
3. 💡 学び 01 「指示」より「意図」を伝える 細かくタスクを命令するより「完了したら次の候補を提案し て」のように意図・目的を伝えると、AIが自律的に動き出 す。人への指示と同じ原理。 💡 学び 02 CLAUDE.mdが「プロジェクト憲法」になる セッションごとに説明を貼り付けるのは非効率。 CLAUDE.mdに一度書けば以降は自動適用。これだけで生産 性が大きく変わる。 💡 学び 03 コンテキスト引き継ぎが最大の課題 セッション終了で記憶がリセットされる。GitHub Issueを Handoverドキュメントとして使い、スマホからの非同期指示 で翌朝引き継ぐフローが実践的な解決策。 💡 学び 04 MCPが「AI秘書」を実現する GitHub・カレンダー・NotionをMCPで繋ぐと、AIが朝のブ リーフィング生成・タスク作成・通知まで一気通貫で行える ようになる。 💡 学び 05 「スキル」でAIを育て続ける スキルファイルに現在の状況・役割・プロジェクト背景を書 き込むと、毎回の前提説明が不要になる。新人研修マニュア ルを書く発想と同じ。 💡 学び 06 投資対効果は数値で計測できる APIログからコストを算出し、人件費換算と比べるとROIが明 確になる。月数万円の投資で数十〜百万円相当の工数削減に なるケースも出始めている。 Claude Code 100本ノック | 3
4. 🟢 第1章：環境構築 #001〜#015 — AIと働く土台を整える Claude Codeを最大限に活用するための初期セットアップです。インストールから始まり、設定の最適化・GitHub 連携・Auto Memory設定まで、一度整えれば以降の全作業の効率が跳ね上がります。 ▶ releaseChannel:"latest" 設定で常に最新機能を先取りできる ▶ Auto Memoryで有用な情報がナレッジベースに自動蓄積される ▶ GitHub Issue × モバイルで「外出先で指示→帰宅後に実装済み」の非同期ワークフローが確立できる # 課 題 ・ や り 方 ・ メ リ ッ ト 001 Claude Codeをインストールし `claude` コマンドを実行する ▶ やり方 Node.js 18以上が必要。npm install -g @anthropic-ai/claude-code でインストール後、claude と入力し てAPIキー認証を完了させる。 メリット ターミナルから直接AIと会話しながらコードを書ける環境が整う。GUIを開かなくても開発作業の大半をAIと共同で進 められるようになる。 002 `releaseChannel:"latest"` に設定して最新機能を有効化する ▶ やり方 ~/.claude/settings.json で "releaseChannel": "latest" を設定。または claude config set releaseChannel latest コマンドで設定できる。 メリット 新機能が一般公開される前に使えるようになる。Claude Codeは頻繁にアップデートされるため、最新チャンネルに 乗っておくことで競争優位を保てる。 003 `language:"ja"` でUI日本語化を確認する ▶ やり方 settings.jsonに "language": "ja" を追加。コマンドプロンプト・エラーメッセージ・ヘルプが日本語化される。 メリット 英語でのやり取りに慣れていない場合でもスムーズに操作できる。チーム全員が迷わず使える環境を作れる。 004 GitHub PATを設定してリポジトリに接続する ▶ やり方 GitHub Settings → Developer settings → Personal access tokens でrepo/issues権限のPATを発行し、環境変数 GITHUB_TOKEN またはMCPサーバー設定に記述する。 メリット CCがGitHubのIssue・PR・コードを直接読み書きできるようになる。「IssueをもとにPRを自動作成する」などの自動 化フローの前提条件。 005 Planモードで既存プロジェクトの構造を分析させる ▶ やり方 「このプロジェクトを分析して実装計画を立てて。実行はまだしないで」とCCに指示するか /plan コマンドを使 用。計画を確認してから実行を承認できる。 メリット 大規模な変更やリファクタリング前に、AIが何をしようとしているかを事前に把握できる。思わぬファイル削除や大幅 な変更を防ぐ安全弁になる。 006 グローバル `~/.claude/CLAUDE.md` を作成する Claude Code 100本ノック | 4
5. # 課 題 ・ や り 方 ・ メ リ ッ ト ▶ やり方 mkdir -p ~/.claude && touch ~/.claude/CLAUDE.md で作成。ここに書いた内容は全プロジェクトで共通し て自動読み込みされる。名前・役割・共通ルール・よく使うコマンドを記述する。 メリット 「あなたは〇〇という開発者です」「コミット前にテストを必ず実行して」など、全プロジェクトに共通する指示を一 箇所で管理できる。プロジェクトをまたいでも毎回説明不要。 007 プロジェクト個別 `CLAUDE.md` を作成し動作確認する ▶ やり方 プロジェクトルートに CLAUDE.md を作成。CCを起動すると自動で読み込まれる。/context コマンドで現在読み込 まれているコンテキストを確認できる。 メリット プロジェクト固有の技術スタック・禁止事項・テストコマンドをAIに覚えさせられる。「このプロジェクトは React+TypeScriptです」を毎回説明しなくて済む。 008 `CLAUDE_CODE_AUTO_MEMORY_PATH` を設定しナレッジベースと連携する ▶ やり方 環境変数 CLAUDE_CODE_AUTO_MEMORY_PATH=~/notes/cc-memory.md を設定（ObsidianなどのMarkdownファ イルに向けてもOK）。CCが有用な情報をこのファイルへ自動書き込みする。 メリット 「今日学んだこと」「よく使うコマンド」「トラブルシューティング記録」がAIとの会話の中で自動的に蓄積される。 手動でメモしなくてもナレッジベースが育っていく。 009 `CLAUDE_CODE_ENABLE_TASKS=true` でタスクシステムを有効化する ▶ やり方 環境変数またはsettings.jsonで設定。エージェントチーム（Agent Teams）用の並列タスク管理が有効になる。 メリット サブエージェントへのタスク委任が可能になり、「テスト生成は別エージェントに任せて、自分は実装に集中」といっ た並列作業ができるようになる。開発速度が大幅に向上する。 010 `includeGitInstructions:false` でトークン消費を削減する ▶ やり方 settings.jsonに "includeGitInstructions": false を追加。デフォルトで毎回挿入されるGit操作の説明文が省 略される。 メリット Gitの使い方説明は熟練者には不要。この設定だけで1セッションあたり数百トークン節約でき、月単位で積み重なると 無視できないコスト削減になる。 011 Codex CLIをインストールしてClaude Codeと並走させる ▶ やり方 npm install -g @openai/codex でインストール。CCで実装→Codexでレビュー、またはCodexで実装→CCでレ ビューの「相互レビュー体制」を作る。 メリット 一つのAIに依存しない「ダブルチェック体制」が組める。特定のAIが見落とすバグや設計の問題を別のAIが発見するこ とが多く、コード品質が大幅に向上する。 012 GitHub Issueをモバイルで作成しPC帰宅後にCCが読み込む流れを確認する ▶ やり方 スマホのGitHub appでIssueを作成 → PC帰宅後に「Issue #XX を実装して」とCCに指示。GitHub MCPが設定済みで あれば自動でIssueを読み込んで実装を開始できる。 メリット 移動中・会議中など「PCの前にいない時間」に思いついたタスクをIssueに書いておくだけで、帰宅後すぐにAIが実装 に着手できる。非同期で開発が進む。 013 新しいプロジェクトフォルダでCCを起動し初期セットアップを行う Claude Code 100本ノック | 5
6. # 課 題 ・ や り 方 ・ メ リ ッ ト ▶ やり方 mkdir new-project && cd new-project && claude で起動。「このプロジェクトのCLAUDE.mdを対話形式 で作って」と指示すれば初期設定が完了する。 メリット プロジェクト開始時にCCが最適なCLAUDE.mdの構成を提案してくれる。0から考えるより効率的で、必要な項目の抜 け漏れも防げる。 014 `.gitignore` にClaude固有ファイルを追加する ▶ やり方 .claude/・.claude_code_history・Auto Memoryのパスを.gitignoreに追加する。 メリット 個人の設定・会話履歴・APIキーがリポジトリに混入するのを防ぐ。チームで同じリポジトリを使う場合に特に重要 で、セキュリティ事故の予防になる。 015 APIキーを誤ってチャットに貼り付けた場合の対処手順を確認する ▶ やり方 即座にAnthropicコンソール → API Keys → 該当キーを「Revoke（失効）」→ 新規キーを発行。漏洩したキーは絶対 に使い続けない。.envファイルへの保存を習慣にする。 メリット APIキー漏洩は不正利用・高額請求につながる重大インシデント。対処手順を知っておくことで、万が一の際に被害を 最小化できる。「知っておくだけ」で損失ゼロにできる。 Claude Code 100本ノック | 6
7. 🟣 第2章：CLAUDE.md設計 #016〜#035 — AIへの「憲法」を書く CLAUDE.mdはAIが毎セッション自動で読み込む指示書です。プロジェクトの目的・禁止事項・TDDルールをここに 書けば、毎回説明しなくても前提を共有できます。「優秀な新人への引き継ぎ資料」を整備するイメージです。 ▶ グローバル（全プロジェクト共通）とプロジェクト個別の2階層で管理する ▶ 「完了したら次の候補を提案せよ」など意図ベースの指示でAIの自律性が上がる ▶ DBスキーマ・仕様書のパスを記載するとAIが実装に必要な情報を自動参照する # 課 題 ・ や り 方 ・ メ リ ッ ト 016 CLAUDE.mdにプロジェクト概要（目的・技術スタック）を記述する ▶ やり方 「## プロジェクト概要」セクションに目的・対象ユーザー・技術スタック（例：Next.js / TypeScript / PostgreSQL） を簡潔に記述する。CCはここを最初に読む。 メリット 「このプロジェクトはReactです」「TypeScriptで書いて」を毎回言わなくて済む。セッションをまたいでもAIが常に 正しい技術スタックでコードを生成してくれる。 017 TDDサイクル（RED→GREEN→REFACTOR）をCLAUDE.mdに明記する ▶ やり方 「## 開発ルール」に「必ずRED（テスト失敗確認）→GREEN（最小実装）→REFACTOR（整理）の順で進めること」 と記述する。 メリット CCがコードを変更するたびにこのサイクルを遵守するようになる。テストなしの「動けばいい」実装を防ぎ、長期的 にバグが少なく変更に強いコードベースを維持できる。 018 コーディング規約（命名規則・インデント）をCLAUDE.mdに追加する ▶ やり方 「変数名はcamelCase」「インデントは2スペース」「型はTypeScriptで必ず明示」など具体的なルールを箇条書 き。.eslintrcがあれば「eslintrcの設定に従うこと」と一言書くだけでも有効。 メリット チームの全員が同じルールでコードを書くように、AIも一貫したスタイルで出力するようになる。レビューで「命名規 則が違う」「インデントが違う」という指摘が激減する。 019 DBスキーマファイルのパスをCLAUDE.mdに記載する ▶ やり方 「DBスキーマ：./docs/schema.sql または ./prisma/schema.prisma」と記述。「コード変更時は必ずスキー マを参照すること」という指示も添える。 メリット CCがマイグレーションやクエリ生成時にスキーマを自動参照するようになる。「存在しないカラムへのクエリ」「型 の不一致」といったDBに関するバグが大幅に減る。 020 仕様書・READMEのパスをCLAUDE.mdに追記する ▶ やり方 「仕様書：./docs/spec.md、API仕様：./docs/api.md」のように列挙。「機能追加前に必ず仕様書を確認する こと」という指示を添えると効果的。 メリット 仕様と違う実装をAIが勝手に作ってしまうリスクを防げる。「仕様書にはこう書いてある」という根拠をAIが自分で確 認しながら実装するようになる。 Claude Code 100本ノック | 7
8. # 課 題 ・ や り 方 ・ メ リ ッ ト 021 禁止事項セクション（削除禁止ファイル等）をCLAUDE.mdに追加する ▶ やり方 「## 禁止事項」セクションに「.envファイルは絶対に編集・削除しない」「mainブランチへの直接pushは禁止」 「本番DBへの直接操作禁止」など明確に箇条書きする。 メリット AIが「便利だから」と思わぬ操作をしてしまうリスクを防ぐ。「一度やってしまったら取り返しのつかない操作」をリ ストアップして禁止しておくことで、重大事故を未然に防げる。 022 テスト実行コマンドをCLAUDE.mdに記述し実際に動かす ▶ やり方 「テスト：npm test、カバレッジ確認：npm run test:coverage」と記述。CCはコード変更後にこのコマンド を自動で実行するようになる。 メリット 「実装した、テストも書いた、でもテストを実行し忘れた」が起こらなくなる。CCが毎回テストを実行してREDを確 認してからGREENに進む習慣が身につく。 023 ビルド・デプロイコマンドをCLAUDE.mdに整理する ▶ やり方 「ビルド：npm run build、本番デプロイ：vercel --prod（要確認）」と記述。デプロイは「実行前に必ず確 認を求めること」という指示を付ける。 メリット 誤って本番環境にデプロイする事故を防げる。ビルドコマンドを覚えていなくても、CCが正確なコマンドを把握して実 行してくれる。 024 グローバルCLAUDE.mdに自分の役割・背景コンテキストを追記する ▶ やり方 ~/.claude/CLAUDE.mdに「私は[役割]として[複数のプロジェクト]を並行運営している。AIは私の意図を先読みして、 タスク完了後に次の候補を必ず提案すること」と記述する。 メリット 全プロジェクトで「私が何者か」「何を優先すべきか」をAIが常に把握した状態で動く。毎回自己紹介する手間がなく なり、AIのアドバイスがより的確になる。 025 CLAUDE.mdの内容をCCに読み込ませ、理解度を確認する質問をする ▶ やり方 CCに「CLAUDE.mdの内容を要約して、あなたが守るべきルールをTop3で挙げて」と質問する。正確に答えられない 場合はCLAUDE.mdの記述が曖昧なサインなので加筆修正する。 メリット 「書いたけど読まれていなかった」「曖昧で誤解された」を事前に検出できる。AIが正確に理解したことを確認してか ら作業を始めると、手戻りが激減する。 026 CLAUDE.mdを更新したら `/reload` で反映確認する ▶ やり方 CCセッション中にCLAUDE.mdを編集した場合、/reload コマンドまたはセッション再起動で新しい内容を読み込ま せる。更新後に「何が変わったか」を確認する習慣を付ける。 メリット 「CLAUDE.mdを更新したのに反映されていない」という状態を防げる。リアルタイムで指示を更新しながら作業でき るため、試行錯誤しながらCLAUDE.mdを育てやすい。 027 複数プロジェクト間でCLAUDE.mdの共通部分を抽出してグローバル化する ▶ やり方 各プロジェクトのCLAUDE.mdを比較して共通部分（TDDルール・セキュリティ方針・連絡先）を抽出 → ~/.claude/ CLAUDE.mdに移動 → 各プロジェクトファイルはプロジェクト固有事項のみに絞る。 メリット 「TDDルールを変えたら全プロジェクトのCLAUDE.mdを修正する」という管理コストをゼロにできる。共通ルールは 一箇所だけ管理すればよくなる。 Claude Code 100本ノック | 8
9. # 課 題 ・ や り 方 ・ メ リ ッ ト 028 アプリのAPI仕様（エンドポイント一覧）をCLAUDE.mdに追加する ▶ やり方 「APIドキュメント：./docs/api.yaml（OpenAPI形式）」と参照先を記載するか、主要エンドポイントを直接列 挙する。 メリット フロントエンドからのAPI呼び出しコードをCCが正確に生成できるようになる。「このエンドポイントは存在しない」 「パラメータ名が違う」というミスが激減する。 029 エラーハンドリング方針をCLAUDE.mdに定義する ▶ やり方 「Errorは必ずcatchしてユーザー向けのメッセージを表示」「APIエラーはSentryに送信」「console.errorは本番 コードに残さない」など方針を明文化する。 メリット CCが生成するコードのエラーハンドリングが一貫したスタイルになる。「このコードはエラー処理がない」というレ ビュー指摘がなくなり、本番障害時のデバッグもしやすくなる。 030 GitHub Issueのラベル運用ルールをCLAUDE.mdに記述する ▶ やり方 「Issue作成時は bug/feature/docs/refactor のいずれかのラベルを必ず付ける」「セッション引き継ぎ用Issueには handoverラベルを付ける」と記述する。 メリット MCPでIssueを自動作成する際にラベルが統一される。ラベルで絞り込んだIssue一覧をCCに渡せるようになり、「今週 のバグ修正Issueだけ実装して」などの絞り込み指示が効くようになる。 031 CLAUDE.mdに「完了したら次の候補を提案せよ」の指示を追加する ▶ やり方 「タスク完了後は必ず次にやるべき候補を3つ提案すること」とCLAUDE.mdに追記する。これだけでCCの振る舞いが 大きく変わる。 メリット 「次は何を指示しよう」と考える時間がなくなる。CCが受け身から能動的なパートナーに変わる。費用対効果で見る と、CLAUDE.mdへの1行追記として最も高いリターンを得られる可能性がある。 032 セキュリティ方針（シークレット管理）をCLAUDE.mdに記載する ▶ やり方 「APIキー・パスワードは.envファイルのみに記述し、コードにハードコードしない」「.envは.gitignoreに含める」 「シークレットをチャットや公開チャンネルに貼らない」を明記する。 メリット CCが生成するコードにシークレットが直接書き込まれるリスクを防ぐ。セキュリティ方針をAIに守らせることで、レ ビューでの「シークレットがハードコードされている」指摘がなくなる。 033 多言語対応方針をCLAUDE.mdに記述する ▶ やり方 「UIテキストはi18nライブラリ経由で管理」「UIコードへの日本語文字列の直書き禁止」「翻訳ファイルは./ locales/に格納」など方針を記述する。 メリット CCが生成するUIコードが最初から多言語対応の構造になる。後から「全部のテキストをi18n対応に書き直す」という 大規模リファクタリングが不要になる。 034 CLAUDE.mdのサイズを最適化しトークン消費を確認する ▶ やり方 wc -c CLAUDE.md でバイト数を確認。目安は2000トークン（約4000文字）以下。重複記述・冗長な説明を削除 し、詳細はファイルパスへの参照に置き換える。 メリット CLAUDE.mdはセッションごとに毎回トークンを消費する。サイズを半分にすれば月次コストも実質半分に近づく。不 要な記述を削ぎ落とす「ダイエット」は定期的に行う価値がある。 Claude Code 100本ノック | 9
10. # 課 題 ・ や り 方 ・ メ リ ッ ト 035 チームメンバーにCLAUDE.mdをレビューしてもらうフローを作る ▶ やり方 CLAUDE.mdをGitリポジトリで管理し、変更時はPRを立てて他メンバーがレビュー。月1回の定期見直し会議を設け てもよい。 メリット 「AIへの指示書」をチームで共同管理することで、特定の人だけが使いこなせる状態を防げる。組織全体のAI活用品質 が均一に向上し、個人依存リスクを下げられる。 Claude Code 100本ノック | 10
11. 🟠 第3章：MCP連携 #036〜#055 — AIにツールを持たせる MCP（Model Context Protocol）は、Claude CodeをGitHub・Google Calendar・Notion・Slackなどの外部ツール に接続する仕組みです。AIが情報を「読む」だけでなく「書く・作る・通知する」ことができるようになります。 ▶ GitHub MCPでIssue作成→実装→PRの全サイクルをAIが完結できる ▶ Google Calendar MCPで今日のスケジュールを前提にしたデイリーブリーフが自動生成される ▶ 複数MCPサーバーを組み合わせると「情報収集〜実行〜通知」が一気通貫で自動化される # 課 題 ・ や り 方 ・ メ リ ッ ト 036 GitHub MCP Serverを設定しIssue一覧を取得する ▶ やり方 claude_desktop_config.jsonに {"mcpServers": {"github": {"command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"], "env": {"GITHUB_PERSONAL_ACCESS_TOKEN": "..."} }}} を追 記。CCに「未完了のIssueを一覧して」と指示するだけで取得できる。 メリット ブラウザでGitHubを開く必要がなくなる。ターミナル上のCCとの会話の中でIssueを確認・作成・クローズが全て完結 する。「今日取り組むIssueをAIが選んで実装を開始する」自動化の起点になる。 037 GitHub MCPでIssueを作成してみる ▶ やり方 GitHub MCPが設定済みの状態でCCに「リポジトリXXXに『ログイン機能のバグ修正』というIssueを作成して、bug ラベルを付けて」と指示する。MCPが自動でGitHub APIを呼び出してIssueを作成する。 メリット 「気づいたらすぐIssue起票」の障壁がほぼゼロになる。ブラウザを開かなくてもターミナルから一言でIssueが作れる ため、思いついた改善・バグの記録漏れが減る。 038 GitHub MCPでPRを作成しレビュー依頼を出す ▶ やり方 「実装が完了したらPRを作成して、タイトルはfeat: XXX、レビュアーに@usernameを指定して」とCCに指示。 GitHub MCPが実装ブランチからPRを自動作成し、レビュー依頼まで完結する。 メリット 実装完了からPR作成・レビュー依頼まで、今まで手作業で数分かかっていた作業がゼロになる。PRの説明文もCCが実 装内容をもとに自動生成するため、品質の高いPRが簡単に作れる。 039 Google Calendar MCPを設定し今週のスケジュールを取得する ▶ やり方 Claude.aiのコネクターからGoogle Calendarを接続するのが最も簡単。または専用MCPサーバーをconfig.jsonに追加 する。「今週の予定を取得して」と指示するだけでカレンダー情報が得られる。 メリット 「今日は14時から会議があるので、それまでに完了できるタスクを提案して」のような、スケジュールを考慮したタス ク管理が自動でできるようになる。 040 Google Calendar MCPでイベントを作成する ▶ やり方 「来週月曜10時に週次MTGのイベントを作成して、場所はZoomリンクXXX」とCCに指示。MCPが自動でカレンダー にイベントを登録する。 Claude Code 100本ノック | 11
12. # 課 題 ・ や り 方 ・ メ リ ッ ト メリット 「Issueの期限をカレンダーに登録する」「開発完了後に振り返りMTGを自動登録する」など、開発イベントとカレン ダーを連動させた自動化が可能になる。 041 Google Drive MCP（またはGAS）で最近更新ファイルを取得する ▶ やり方 Claude.aiのGoogle Driveコネクターを接続するか、Google Apps ScriptでDriveファイル一覧をメール送信するスクリ プト（todo-bot）を活用。Gemini API制限がある場合はAI不使用のGASが現実解。 メリット 「最近更新した仕様書をCCに読ませて実装に反映する」フローが自動化される。ドキュメントと実装の乖離を防ぐこ とができる。 042 Notion MCPを設定しデータベースを読み込む ▶ やり方 Claude.aiのNotionコネクターを接続するか、@notionhq/clientを使ったMCPサーバーを設定。「タスクDBの未 完了アイテムを一覧して」と指示するとNotionのデータをCCが直接取得できる。 メリット NotionとGitHubのタスクを横断してCCが管理できるようになる。「NotionのタスクをGitHub Issueに変換して」のよ うな連携作業が一言の指示で完了する。 043 Notion MCPでタスクページを作成する ▶ やり方 「NotionのタスクDBに『新機能の提案資料作成』ページを追加して、ステータスは進行中で期限は今週金曜」とCC に指示。MCPがNotion APIを呼び出してページを自動生成する。 メリット 「Notionを開く → DBに移動 → 新規ページ作成 → 項目入力」という一連の作業が、CCへの一言の指示に集約される。 タスク起票の心理的コストが大幅に下がる。 044 GitHub + Calendar MCPを組み合わせてデイリーブリーフを生成する ▶ やり方 「今日のカレンダー予定とオープンなGitHub Issueを統合して、今日やるべき優先タスクTop3を提案して」とCCに指 示。2つのMCPを同時に使った朝ブリーフが自動生成される。 メリット 「今日何をすべきか」を朝に自分で考える時間が不要になる。会議の合間にできるタスクと、集中時間が必要なタスク をCCがスケジュールを見て自動的に振り分けてくれる。 045 MCPサーバーの設定ファイル（claude_desktop_config.json）を整備する ▶ やり方 macOSの場合 ~/Library/Application Support/Claude/claude_desktop_config.json を整備。各サー バーをコメントで整理し、環境変数は直接書かず.envから参照する構成にする。 メリット 設定ファイルを整備することで、新しいMCPサーバーの追加・削除が簡単になる。チームメンバーへの展開時も設定 ファイルを共有するだけで同じ環境を再現できる。 046 MCPサーバーの認証エラーをデバッグする ▶ やり方 CCのログ（~/.claude/logs/）を確認。よくある原因：①トークン期限切れ→再発行 ②スコープ不足→PATの権限 を追加 ③JSON設定ミス→バリデーターで確認。claude mcp list で接続状況を確認。 メリット MCPの障害は「なぜか動かない」で詰まりがち。ログの見方を知っておくと原因特定が10分以内にできる。認証エラー のパターンを覚えておくと同じ問題を繰り返さなくなる。 047 カスタムMCPサーバーを自作し簡単なAPIをラップする ▶ やり方 @modelcontextprotocol/sdkを使い、社内APIや独自サービスをMCPサーバーとしてラップ。 server.tool("tool_name", schema, handler) でツールを定義するだけで、CCから呼び出せる。 Claude Code 100本ノック | 12
13. # 課 題 ・ や り 方 ・ メ リ ッ ト メリット 既存のMCPサーバーでカバーされていない社内システムでもAIと連携できるようになる。自社固有のAPIや業務システ ムをCCから直接操作できる環境を作れる。 048 MCP経由でSlackにメッセージを送信する ▶ やり方 Slack MCP Serverを設定（@modelcontextprotocol/server-slack）。CCに「#generalに『本日のデプロイが 完了しました』とSlack通知して」と指示するだけでSlackにメッセージが投稿される。 メリット 「実装完了→Slack通知→PR作成」をCCが全部やってくれるようになる。報告のための手作業がゼロになり、チームへ のコミュニケーションも自動化できる。 049 MCPを使ってGitHub IssueとNotionタスクを双方向同期する ▶ やり方 「GitHub Issueを取得し、対応するNotionタスクが存在しない場合は作成して」とCCに定期実行させる。または両 MCPを使ったカスタムスクリプトをHooksで定期実行する。 メリット 「GitHubはエンジニアが見る、NotionはPMが見る」という状況でも、二重管理なしに両方を常に同期した状態を保て る。情報の一元管理が実現する。 050 `daily-brief` スキルにMCPを組み込み自動朝ブリーフを実現する ▶ やり方 daily-briefスキルファイルに「起動時：GitHub Issue取得 → カレンダー確認 → 優先度付けして朝ブリーフ生成 → 今 日のアジェンダを提案」というフローを記述。朝 /daily-brief と打つだけで全自動化。 メリット 毎朝の「今日何をすべきか考える時間」が不要になる。CCが複数ソースを統合して最適な一日のプランを提案してくれ る。スタンドアップMTGの準備時間もゼロになる。 051 複数MCPサーバーを同時利用して情報を統合するプロンプトを書く ▶ やり方 「GitHub・Calendar・Notionから情報を取得して、週次振り返りレポートを生成して。フォーマット：完了PR / 来 週の予定 / 積み残しIssue / 次週優先タスク」のような統合プロンプトを作成・テンプレート化する。 メリット 週次レポートの作成が「プロンプト一発」で完了する。今まで1時間かかっていた情報収集・整理・報告書作成がゼロ になる。経営・マネジメント報告の工数が大幅に削減できる。 052 MCPサーバーのレート制限対策を実装する ▶ やり方 カスタムMCPサーバーにexponential backoff（指数バックオフ）を実装。リクエスト間に await sleep(delay) を挿入し、429エラー時は自動でリトライ間隔を延ばす。GitHub認証済みは5000req/h上限。 メリット 「突然MCPが動かなくなった」というトラブルを防げる。自動リトライにより、一時的なレート制限でもフローが止ま らず継続して動く頑健なシステムになる。 053 MCPのツール一覧を確認し使っていないツールを無効化する ▶ やり方 claude mcp list で接続中のサーバーを確認。使用頻度の低いMCPはconfig.jsonからコメントアウトして無効化す る。 メリット MCPツール数が多いとCCのコンテキスト（記憶領域）を消費する。使わないMCPを無効化するだけで、CCが本当に重 要な情報に集中できるようになり、応答品質が上がる。 054 Figma MCPを設定しデザインデータを取得する ▶ やり方 Figma公式MCP（またはコミュニティ製サーバー）を設定。FigmaファイルIDとAPIトークンを設定し、「このFigma フレームをReactコンポーネントに変換して」とCCに指示できるようになる。 Claude Code 100本ノック | 13
14. # 課 題 ・ や り 方 ・ メ リ ッ ト メリット デザインと実装の橋渡しが自動化される。デザイナーからFigmaファイルを受け取ったら、CCにURLを渡すだけで Reactコンポーネントが自動生成されるフローが作れる。 055 MCP経由のデータをCLAUDE.mdのコンテキストに自動反映するフローを作る ▶ やり方 MCPで取得した「現在の未完了Issue数」「今週の予定」などをAuto MemoryのファイルにCCが書き込むフローを作 成。次回セッション起動時にCLAUDE.mdがそのファイルを参照し状況を自動把握する。 メリット 「昨日の続きから」がいつでも自動でできる。セッションが変わるたびに「現在の状況」を説明し直す手間がなくな り、CCが常に最新状態を把握した状態で作業を再開できる。 Claude Code 100本ノック | 14
15. 🟡 第4章：Hooks活用 #056〜#065 — 見えないガードレールを設置する HooksはAIがツールを使う直前・直後にカスタムスクリプトを実行する仕組みです。「危険なコマンドを自動ブロッ ク」「テスト成功時にSlack通知」「セッション終了時にサマリー自動生成」など、AIの行動に安全弁を設置できま す。 ▶ PreToolUseフックで rm -rf などの危険コマンドを事前にブロックできる ▶ PostToolUseでテスト成功時にチームへ自動通知できる ▶ セッション終了時のHandover自動生成で、翌日のコンテキスト復元コストがゼロになる # 課 題 ・ や り 方 ・ メ リ ッ ト 056 PreToolUseフックを作成しコマンド実行前にログを残す ▶ やり方 settings.jsonの hooks.preToolUse にシェルスクリプトを設定。echo "$(date) - TOOL: $TOOL_NAME" >> ~/.claude/tool-log.txt のようにCCが何のツールをいつ実行したか記録する。 メリット 「CCが何をしたか」の履歴が残るようになる。問題が起きた際に「どのタイミングで何が実行されたか」を遡れるた め、デバッグが大幅に楽になる。監査ログとしても活用できる。 057 PostToolUseフックでテスト成功時に通知を送る ▶ やり方 postToolUseフックでテストツール実行後の終了コードを確認。if [ $EXIT_CODE -eq 0 ]; then osascript -e 'display notification "テスト成功！"'; fi でMac通知センターに通知。Slack通知版はcurlでWebhookを叩く。 メリット CCに作業を任せている間、別の作業に集中できる。「テスト完了したら知らせて」が自動化されるため、定期的に画 面を確認する「ポーリング作業」がなくなる。 058 危険コマンド（rm -rf）を検知してブロックするフックを書く ▶ やり方 preToolUseフックで $TOOL_INPUT を検査し、rm -rf / や DROP TABLE などのパターンをgrepで検出したら exit 1（ブロック）を返す。CCが危険操作を試みると自動で阻止される。 メリット 「AIが良かれと思ってやった操作」による取り返しのつかない事故を防げる。一度設定すれば自動で機能するため、AI に作業を任せても安心して別の作業に集中できる。 059 コード変更後に自動でlintを実行するPostToolUseフックを作る ▶ やり方 postToolUseでファイル書き込みツール実行後に npx eslint $MODIFIED_FILE --fix を実行するフックを設 定。CCがコードを書いた直後に自動でlintが走り、修正まで完了する。 メリット 「CCが書いたコードにlintエラーがある」という状態がなくなる。コードレビューで「スタイルの指摘」だけに費やす 時間がゼロになり、レビュアーはロジックの確認に集中できる。 060 セッション終了時にHandoverドキュメントを自動生成するフックを設定する ▶ やり方 sessionEndフックでCCに「このセッションのHandoverドキュメントをGitHub Issueとして作成して。形式：完了事 項/残課題/次のアクション/技術的な決定事項」と自動指示するフックを設定する。 Claude Code 100本ノック | 15
16. # 課 題 ・ や り 方 ・ メ リ ッ ト メリット 翌日のセッション開始時に「どこまでやったか」を確認するためのIssueが自動で作られる。記憶のリセット問題が解 決され、「昨日の続きから」がいつでも正確にできる。 061 フックのエラーハンドリングを実装しログに記録する ▶ やり方 フックスクリプトに trap 'echo "HOOK ERROR: $?" >> ~/.claude/hook-errors.log' ERR を追加。フッ ク自体が失敗した場合もログが残るようにし、set -e で予期しない継続を防ぐ。 メリット 「フックが動いていない」「なぜか通知が来ない」という謎のトラブルを素早く特定できる。ログがなければ原因不明 で終わるところを、ログがあれば数分で解決できる。 062 環境変数によってフックの動作を切り替える（開発/本番） ▶ やり方 フックスクリプト内で if [ "$NODE_ENV" = "production" ]; then で分岐。本番ではより厳しいガードを適 用し、開発では警告のみにするなど、環境に応じて安全レベルを変える。 メリット 開発時の「ちょっと試したい」という柔軟性を保ちながら、本番では万全のガードを適用できる。「開発で試したこと が本番で事故になる」リスクを構造的に防げる。 063 フックのユニットテストを書く ▶ やり方 bashスクリプトのテストにはBATSフレームワーク（npm install -g bats）を使用。各フックの入力・出力パ ターンをテストし、危険コマンドブロックが正しく機能するかCIで自動検証する。 メリット 「ガードが実は機能していなかった」という最悪の事態を防げる。フックを変更するたびにテストが自動で走るため、 「修正したら別のフックが壊れた」という問題も早期発見できる。 064 git commitの前にテストを自動実行するフックを作る ▶ やり方 CCのpreToolUseフックでgitツール使用時を検知。コミット操作の場合に npm test を先に実行し、失敗したらコ ミットをブロックする。Gitのpre-commitフックと組み合わせると二重の安全弁になる。 メリット 「テストが失敗したままコミット・プッシュしてしまった」という事故がゼロになる。CIで失敗して気づく前に、ロー カルで自動検出してくれるため開発サイクルが速くなる。 065 フック実行時間を計測しボトルネックを特定する ▶ やり方 time コマンドをフックスクリプトに仕込むか、SECONDS 変数で実行時間を計測してログに記録。実行時間が3秒を 超えるフックはCCの操作全体を遅延させるため最適化が必要。 メリット フックが多くなると「CCの応答が遅い」という問題が起きやすい。どのフックが遅いかを特定して最適化すること で、自動化の恩恵を受けながらもストレスのない作業速度を保てる。 Claude Code 100本ノック | 16
17. 🩷 第5章：エージェント・スキル設計 #066〜#080 — AIチームを設計する スキルファイルはAIへのペルソナ設定書です。「プロジェクトの文脈を常に把握したAI」「TDDを守るAI」「セッ ションを引き継ぐAI」を個別のスキルで定義し、組み合わせることで目的に応じたAIチームを設計できます。 ▶ コンテキストスキルにプロジェクトの背景・役割・優先事項を書き込むことで、毎回の前提説明が不要になる ▶ handoverスキルでGitHub Issue形式のセッション引き継ぎを標準化できる ▶ モバイル→GitHub Issue→CC実装→PR→スマホ承認の非同期ワークフローを完成させられる # 課 題 ・ や り 方 ・ メ リ ッ ト 066 コンテキストスキルを作成しプロジェクト背景を自動注入する ▶ やり方 ~/.claude/skills/project-context.md を作成。「現在担当しているプロジェクトの概要・優先事項・技術ス タック・注意すべき制約」を記述。CCが常にこの前提で動くようになる。 メリット 「私はXという立場で、YとZのプロジェクトを担当しています」という説明を毎回しなくて済む。AIが常に正しいコン テキストを持った状態で提案・実装してくれる。 067 開発ルールスキルにTDDルールを定義する ▶ やり方 ~/.claude/skills/dev-rules.md に「必ずRED→GREEN→REFACTORで進む」「実装前に必ずテストを書く」 「テストなしのコミットは禁止」を記述。プロジェクト起動時にこのスキルを参照させる。 メリット TDDルールをCLAUDE.mdにも書けるが、スキルとして独立させることで「このプロジェクトではTDD、あのプロジェ クトでは別のルール」というプロジェクト別の使い分けが簡単になる。 068 handoverスキルでセッション引き継ぎを標準化する ▶ やり方 handoverスキルに「セッション終了時のHandoverフォーマット：①完了事項 ②残課題と理由 ③次のアクション3選 ④重要な技術的決定事項」を定義。このフォーマットでGitHub Issueが自動生成される。 メリット 翌日のセッションで「どこまでやったか」が構造化されたIssueとして残っているため、5秒でコンテキストを復元でき る。チームメンバーへの引き継ぎ資料としても活用できる。 069 daily-briefスキルでモーニングブリーフを自動生成する ▶ やり方 daily-briefスキルに「起動時にGitHub Issue（open）・Googleカレンダー（今日）・Notionタスク（未完了）を取 得し、優先度順に今日のアジェンダを生成。所要時間の目安も付けること」を記述。朝 /daily-brief で起動。 メリット 毎朝「今日何をすべきか」を自分で考える時間がゼロになる。複数ソースの情報を横断集計してAIが最適な順序を提案 するため、重要なタスクの見落としが減る。 070 スキルファイルのプレースホルダーを実際のデータで埋める ▶ やり方 スキルファイルにあった「[プロジェクト名]」「[技術スタック]」などのプレースホルダーを実際の情報で埋める。 CCに「既存スキルのプレースホルダーを洗い出して一覧にして」と依頼するのが効率的。 メリット プレースホルダーが残ったままのスキルは機能しない。実際のデータで埋めて初めてスキルが「生きた指示書」にな る。定期的に見直して最新情報に更新し続けることで効果を維持できる。 Claude Code 100本ノック | 17
18. # 課 題 ・ や り 方 ・ メ リ ッ ト 071 GitHub IssueをインプットにCCが自動実装するパイプラインを作る ▶ やり方 「GitHub MCP経由でIssue一覧を取得 → 最優先Issueを選択 → Planモードで実装計画 → 承認後に実装 → テスト実行 → PR作成」のフロー全体をCCにオーケストレートさせるマスタープロンプトを設計する。 メリット 「Issueを書いてPCを離れる → 帰ったらPRができている」という完全非同期の開発が実現する。1日あたりの実装量が 飛躍的に増える。 072 コードレビューをCCに依頼しCodexが修正するクロスレビューフローを作る ▶ やり方 CC（実装）→Codex（レビュー・指摘）→CC（修正）のサイクルをシェルスクリプトで自動化。またはCCに「Codex のレビュアー視点で自分のコードを批評して修正点を挙げよ」とセルフレビューを指示する。 メリット 人間のレビュアーに渡す前にAIが二重チェックを行う体制が構築できる。「AIが書いたコードをAIがレビューする」こ とで、人間レビューでの指摘が明らかに減り、レビューが軽くなる。 073 サブエージェントにテスト生成を委任するプロンプトを書く ▶ やり方 CLAUDE_CODE_ENABLE_TASKS=true有効化後、CCに「実装は私が行う。テストコード生成はサブエージェントに委 任して、単体テスト・統合テスト・エッジケースを網羅させて」と指示する。 メリット 実装とテスト生成を並列で進められるため、開発速度が理論上2倍になる。サブエージェントが思わぬエッジケースの テストを生成することで、バグ発見率も上がる。 074 Planモードで大きな機能の実装計画を立て承認後に実行する ▶ やり方 「まず実装計画だけ立てて、実行はしないで」とCCに指示。計画を確認・修正してから「計画通り実装して」と承認 する。大きな機能変更やリファクタリング前に必ず使う。 メリット 「AIが思わぬ方向で実装してしまった」「後戻りできない変更をされてしまった」というリスクをゼロにできる。事前 に計画を確認する習慣が、手戻りによる時間ロスを大幅に削減する。 075 スキルファイルのバージョン管理をGitで行う ▶ やり方 ~/.claude/skills/ ディレクトリをGitリポジトリとして初期化し、GitHubにpush。スキルの変更履歴を管理し、 複数マシンや複数人での共有が可能にする。 メリット 「このスキルを変更したら動かなくなった」ときに前のバージョンに戻せる。チームでスキルを共同開発・共有するこ とで、組織全体のAI活用レベルを統一できる。 076 スキルの効果測定（トークン削減量）を記録する ▶ やり方 スキル導入前後のセッション平均トークン数をAPIログから比較。「毎回手動で入力していた説明文」のトークン量を 計算し、スキル化による削減量を月次でスプレッドシートに記録する。 メリット 「スキルへの投資が本当に価値を生んでいるか」を数値で確認できる。ROIが見えることでスキル改善のモチベーショ ンが上がり、継続的な改善サイクルを回せるようになる。 077 新しいスキルのアイデアをGitHub Issueに起票するフローを作る ▶ やり方 「CCと作業中に『このコンテキストを毎回入力している』と気づいたらその場でGitHub Issueを作成する」習慣を設 ける。Issueテンプレートに「スキル名・解決したい問題・想定する効果」を設定する。 メリット スキル改善のアイデアを流さずに蓄積できる。「毎回同じことを入力している」という非効率に気づいたその場で記録 するため、改善機会の見落としがなくなる。 Claude Code 100本ノック | 18
19. # 課 題 ・ や り 方 ・ メ リ ッ ト 078 複数スキルを組み合わせて複合タスクを処理するプロンプトを設計する ▶ やり方 「/project-context /dev-rules を前提に、今週の進捗をNotionから取得し、未完了Issueと合わせて週次優先度レポー トを生成して」のような複合プロンプトを作成・テンプレート化する。 メリット 「コンテキスト注入＋ルール適用＋情報取得＋レポート生成」を一発のコマンドで完結できる。複雑な定型業務が「プ ロンプトを実行するだけ」に集約される。 079 モバイル→GitHub Issue→CC実装→スマホ通知の非同期フローを完成させる ▶ やり方 スマホでGitHub IssueにTODOを書く → PC帰宅後に claude "最新Issueを実装して" → 実装完了後にHookが Slack/メール通知 → スマホでPR確認・マージ承認。 メリット 「PCの前にいる時間」だけが開発できる時間ではなくなる。外出中に思いついたアイデアをIssueに書けば、帰宅後す ぐにAIが実装に着手し、外出中にも開発が進む完全非同期体制が完成する。 080 エージェントの出力品質を評価するルーブリックをCLAUDE.mdに追加する ▶ やり方 「良いアウトプットの基準：①テストが全てパスする ②PR説明が1画面に収まる ③次のアクションが明示されている ④コードレビューコメントが最小限」をCLAUDE.mdに追記する。 メリット CCが自己評価しながら作業するようになり、アウトプットの品質が底上げされる。「なんとなく良いコードを書い て」ではなく、具体的な基準を持って作業するため、成果のばらつきが減る。 Claude Code 100本ノック | 19
20. 🔵 第6章：上級編 #081〜#100 — ビジネスに組み込む 環境構築・CLAUDE.md・MCP・Hooks・スキルを全て統合し、実際の業務プロセスをAI自律化します。ROI計測・ CI/CD統合・チームへの展開まで完遂することで、Claude Codeが「試してみた」ではなく「業務インフラ」になり ます。 ▶ Issue→実装→PR→承認の全自動パイプラインでリリース工数を劇的に削減できる ▶ CCセッションコストのROI分析で投資対効果を経営数値として可視化できる ▶ Zenn記事投稿でコミュニティに知見還元しながら採用ブランドも高められる # 課 題 ・ や り 方 ・ メ リ ッ ト 081 PR自動生成パイプライン（Issue→実装→PR→承認）を構築する ▶ やり方 「GitHub MCPでIssueを読む → 実装ブランチを作成 → コードを実装 → テスト実行 → PR作成（説明文・レビュアー 指定付き） → Slack通知」の全フローをCCに1コマンドでオーケストレートさせるプロンプトを作成する。 メリット Issueを書いてPCから離れるだけで、帰ったときにはPRが完成している状態を作れる。人間が担当するのはIssueの記 述と最終承認だけになり、実装作業の大半をAIが担う体制が完成する。 082 CCとCodexをCI/CDに組み込みPRレビューを自動化する ▶ やり方 GitHub ActionsのPRトリガーでCCを呼び出し「このPRをバグ・セキュリティ・可読性の観点でレビューして、コメ ントをPRに投稿して」と指示。Codexと組み合わせて二重チェック体制を構築する。 メリット 人間のレビュアーがPRを見る前にAIが一次スクリーニングを完了する。明らかなバグ・スタイル違反はAIが指摘するた め、人間のレビュアーはビジネスロジックと設計の確認に集中できる。 083 技術記事のドラフトをCCに生成させてGitHubにプッシュするフローを作る ▶ やり方 「今週学んだことをZenn/Qiita記事のドラフトにまとめて。対象読者は中級エンジニア。Zenn CLIのmarkdown形式 でarticles/フォルダに保存してGitHubにpushして」と指示する。 メリット 「記事を書きたいが時間がない」問題が解決する。執筆の最大障壁である「書き始め」をCCが担当し、人間は内容の 確認・補足・公開判断だけに集中できる。アウトプットの量が大幅に増える。 084 テスト失敗時にCCが自動修正し再テストするループを実装する ▶ やり方 PostToolUseフックでテスト失敗を検知 → CCに「テストが失敗しました。原因を分析して修正して、再度テストを実 行して」と自動指示を送る。最大リトライ回数を設定してループを制御する。 メリット 「テストが失敗したので修正して → また失敗した → また修正して」という単純な繰り返し作業がゼロになる。人間は 修正ループをCCに任せ、最終的なGREEN状態だけを確認すればいい。 085 セキュリティスキャン結果をCCが分析しIssueに起票するフローを作る ▶ やり方 CI/CDでnpm audit / Snyk / Trivyを実行 → 結果をCCに渡して「CVSSスコア7以上の脆弱性を優先度付きでGitHub Issueに起票して」と指示する。セキュリティ対応のトリアージを自動化する。 Claude Code 100本ノック | 20
21. # 課 題 ・ や り 方 ・ メ リ ッ ト メリット セキュリティスキャン結果を「見て終わり」ではなく「自動でIssue化して対応漏れなし」に変えられる。脆弱性対応 の抜け漏れがなくなり、セキュリティ品質が継続的に維持される。 086 依存パッケージのアップデートをCCが判断・実行するフローを作る ▶ やり方 週次でCCに「npm outdatedの結果を確認して、メジャーアップデートはリスク評価してIssue起票、マイナーはPR自 動作成、パッチは自動マージ可とするPRを作成して」と指示する自動化スクリプトを設定。 メリット 「依存関係の陳腐化」を放置するリスクが減る。パッケージ更新の判断・実行を週次で自動化することで、古いバー ジョンに起因するセキュリティリスクと互換性問題を常に最小化できる。 087 複数リポジトリをまたぐ変更をCCにオーケストレートさせる ▶ やり方 「フロントエンド・バックエンド・インフラの3リポジトリを横断してAPIの変更を実装して」とCCに指示。各リポジ トリにブランチを作成し、変更の依存順序を管理しながらPRを3つ同時に作成するフローを設計する。 メリット マイクロサービスやモノレポ構成で「全リポジトリを整合性を保ちながら変更する」という最も難しい作業をCCに任 せられる。人間が担当するのは最終的な動作確認とマージ承認だけになる。 088 CCの出力コストを週次レポート化するスクリプトを書く ▶ やり方 Anthropic APIの使用量エンドポイントを週次で取得し、プロジェクト別・日別のトークン使用量とコストをスプレッ ドシートに自動記録するスクリプトを作成する。 メリット 「AIにいくらかけているか」が可視化される。月次のAI投資対効果分析の基礎データになり、「どのプロジェクトへの AI投資が最も効率的か」という経営判断ができるようになる。 089 CLAUDE.mdとスキルの定期見直しカレンダーイベントを作成する ▶ やり方 毎月第1月曜に「CLAUDE.md月次見直し」の定期イベントをカレンダーに設定。チェックリスト：①古い情報の更新 ②使っていないルールの削除 ③新しいプロジェクト情報の追加。 メリット CLAUDE.mdは「書いたら終わり」ではなく「育て続けるもの」。定期見直しをカレンダーに入れることで、情報が古 くなったまま放置されることを防ぎ、AIへの指示が常に最新状態を保てる。 090 業務プロセスの一部をCCエージェントで半自動化する設計をする ▶ やり方 自分の業務フロー（例：提案資料作成・顧客フォローアップ・週次報告）をCCにオーケストレートさせる設計図を作 成する。「手動でやっていること」を洗い出し、CCが担当できる部分を特定する。 メリット 「繰り返しの多い業務」「テンプレートが決まっている業務」はCCが最も得意とする領域。半自動化することで、人間 は判断・関係構築・創造的な業務に集中できる時間が生まれる。 091 プロジェクト課題トラッキングをCC+GitHub Issueで構築する ▶ やり方 専用のGitHubリポジトリを作成し、課題・改善タスク・進捗をIssueで管理。CCがIssueの分析・優先度付け・解決策 提案を担当する。非エンジニアもGitHub IssueのUIで参加できる。 メリット 課題管理にGitHubを使うことでCCとの連携が自然になる。「この課題についてCCに分析させる」「解決策を提案させ る」がワンクリックで実行できる、AIネイティブな課題管理体制が作れる。 092 リリースノートをCCが自動生成するフローを作る ▶ やり方 「前回リリースタグから今回タグまでのgit logとマージされたPRを取得し、ユーザー向けリリースノートを markdownで生成して。技術用語を使わずに機能・改善・バグ修正の3セクションで書いて」とCCに指示する。 Claude Code 100本ノック | 21
22. # 課 題 ・ や り 方 ・ メ リ ッ ト メリット リリースのたびに必要だった「技術的な変更をユーザー向けに翻訳する」作業がゼロになる。CCがコミット・PRの内 容を読んで、ユーザーが理解できる言葉に自動変換してくれる。 093 本番障害発生時のCCアシスト手順書をCLAUDE.mdに整備する ▶ やり方 「## 障害対応手順」セクションに「①Slackで報告 ②CCに『本番障害：[症状]を調査して』と指示 ③ログをCCに貼り 付けて原因分析 ④修正PRを緊急作成 ⑤ポストモーテムIssueを起票」を記述する。 メリット 障害時はパニックになりがち。手順書があることで「次に何をすべきか」を考える必要がなくなる。CCがログ分析・ 原因特定・修正案の提示を担当するため、障害対応時間が大幅に短縮される。 094 CCを使ってドキュメント（.docx/.pdf）を自動生成するスクリプトを作る ▶ やり方 docxライブラリ（npm: docx）とWeasyPrint（Python）を使ったスクリプトをCCに生成させ、CLAUDE.mdや仕様 書の内容をWord・PDF文書として自動出力するフローを作成する。本レポート自体がその実例。 メリット 「資料を作る」という作業がコマンド一発になる。仕様書・報告書・提案資料などを定型フォーマットで自動生成する ことで、ドキュメント作成コストが大幅に削減される。 095 スキル・フック・MCPを全部使った理想のワークフローを記事化する ▶ やり方 CCに「私のClaude Code活用ワークフロー（スキル・フック・MCP・CLAUDE.md）について、Zenn記事を書いて。 読者は中級エンジニア、文字数4000字目安、具体的なコード例を含めて」と指示し、CCが記事化。 メリット 「記事を書く」という行為がAI普及に貢献するだけでなく、自分の思考を整理し「本当に理解しているか」を確認する アウトプット学習になる。採用ブランドの向上にもつながる。 096 CCセッションのコストとアウトプットをROI分析する ▶ やり方 月次API利用料を計算 → 「CCが生成したコード行数・PR数・節約された作業時間」を記録 → 人件費（時給換算）と 比較してROIを算出する。 メリット 「AIへの投資を続けるべきか」という判断が感覚ではなく数値でできるようになる。ROIが可視化されることで、AI活 用への投資を組織として継続・拡大する合理的な根拠が生まれる。 097 後輩や同僚向けのCC入門ハンズオン資料をCCに作らせる ▶ やり方 CCに「私のCLAUDE.mdとスキルファイルを参照して、エンジニア未経験者でも3時間でClaude Codeの基本を習得で きるハンズオン資料を作成して。各ステップに確認課題を入れて」と指示する。 メリット 自分が習得したClaude Code活用ノウハウを組織に展開できる。研修資料の作成自体をCCに任せることで、「知識を教 えるコスト」を大幅に下げながら組織全体のAIリテラシーを底上げできる。 098 複数プロジェクト横断のCLAUDE.md継承構造を設計する ▶ やり方 ~/.claude/CLAUDE.md（共通）← 各プロジェクトルートのCLAUDE.md（個別）の2階層を整備。共通にはTDDルー ル・セキュリティ方針を、個別にはプロジェクト固有の技術スタックと仕様を記述する。 メリット プロジェクトが増えるほど管理コストが増大する問題を構造的に解決できる。共通ルールは1箇所だけ更新すれば全プ ロジェクトに反映されるため、「このプロジェクトだけルールが古い」という状態がなくなる。 099 CCエージェントの「自律性レベル」を段階的に上げるロードマップを作る ▶ やり方 「Lv1：確認しながら実装 → Lv2：計画承認後は自律実行 → Lv3：Issueを自律的に選択して実装 → Lv4：週次目標か ら逆算してIssue起票から実装まで完結」のロードマップをCLAUDE.mdに記述し段階的に権限移譲する。 Claude Code 100本ノック | 22
23. # 課 題 ・ や り 方 ・ メ リ ッ ト メリット 一気に自律性を上げると事故リスクが高まる。段階的に信頼と権限を委譲することで、安全にAIの自律度を上げていけ る。各レベルで動作確認してから次のレベルに進む構造が安全なAI活用を実現する。 100 Claude Code 100本ノックを完走した知見をブログ記事にまとめる ▶ やり方 CCに「100本ノックを完走した体験をZenn/Qiita記事にまとめて。特に印象的だった問題Top5・失敗から学んだこ と・ROIの数値・次の100本に向けての展望を含めること」と指示する。 メリット 完走の達成感だけで終わらず、学んだことをアウトプットすることで知識が定着する。あなたの知見が次の挑戦者の道 標になり、技術コミュニティへの貢献とともに自分の信頼性・存在感が高まる。 R E C O M M E N D E D P A T H 次のステップ — 推奨する取り組み順 全てを一度にやる必要はありません。ビジネスインパクトの大きい順に優先度を付けた推奨パスです。 01 まず環境を整える（#001〜 #015） インストールからGitHub連携まで。全 ての土台。1日で完了できます。 優先度：最高 02 CLAUDE.mdを育てる（#016〜 #035） AIへの投資で最もリターンが大きい。 毎週少しずつ追記する習慣を。 優先度：高 03 GitHub MCPを繋ぐ（#036〜 #044） これだけでIssue管理とPR作成が劇的に 楽になる。最初の1MCPとして最適。 優先度：高 04 スキルで文脈を覚えさせる （#066〜#070） コンテキストスキルを作るだけで毎回 の前置き説明がゼロになる。 優先度：中〜高 05 Hooksで安全弁を設置（#056〜 #060） 危険コマンドブロックとHandover自動 生成の2つだけで十分な価値がある。 優先度：中 06 ROIを計測して展開（#088・ #096〜#098） コスト削減を数値化し、チームへの展 開根拠を作る。完走後に必ず。 優先度：完走後 Claude Code 100本ノック — 一般公開版 — 2026 Claude Code 100本ノック | 23