カンリーテックブログPublicationへの投稿
🧑‍🎓

カンリー社内Claude Code勉強会の資料を公開します

ryu fukuda
に公開
AI駆動開発
Claude Code
idea

本記事について

株式会社カンリーでは、2025年6月頃から全エンジニア向けにClaude Codeを導入しています。
それ以前にDevinやCursorなども導入しており、現在ではこれら3ツールを個人の裁量で使い分けて業務をしています。
その中においてツールの理解度・習熟度は個人でばらつきがあり、組織として活用レベルを一段上げたいと考えて勉強会を実施しました。

本記事はその際の資料をほぼそのまま掲載したものとなります。
Claude Codeを使ったことはある、しかし使いこなす余地が残されている方向けの資料です。

なぜ今Claude Codeを学ぶのか

「人間がコードを書く時代は終わった」

「人間がコードを書く時代は終わった」—この主張は以前から様々な開発者によって語られてきた。
2026年1月には、Node.js作者でありDeno Land Inc. CEOのRyan Dahl氏もXで同様の見解を示している。

よって、エンジニアはAIエージェントを利用したコーディングを身に着けることが急務である。

📎 参考: 人間がコードを書く時代は終わった

技術記事投稿数から見る、日本におけるClaude Codeの勢い

AIコーディングツールは多数存在する。
その中でもClaude Codeは実質的なデファクト・スタンダードになりつつあり、日本でもその勢いは顕著である。


青線がQiitaにおけるClaude Codeの月間記事投稿数。Maxプラン開始の6月以降、常にトップ


Zenn, Qiita累計の記事投稿数も圧倒的に多い

カンリー内の普及状況

  • 3か月前
    • 過半数がメインツールとして使用、うち熟練者は数名
      • Cursor併用者が多く、ほぼ同数の利用状況
  • 現在
    • エージェント・スキルを自作しているメンバーは数名
      • 新たな技術を取り入れ、「まずやってみろ」を体現していく必要性がある

この勉強会の目的と進め方

AIコーディングが当たり前になるほど、個人の“書く力”だけでは差がつきにくくなる。
この勉強会では、Claude Codeを正しく理解し、チームで再現性のある形で運用できる状態を目指す。
その結果として、開発生産性とソフトウェア品質を飛躍的に向上させる。

持ち帰ってほしいこと

  • コンテキスト設計: 何を渡せば期待通りに動くか（トークン・auto-compact含む）
  • ルール化: CLAUDE.md / rules / skills で品質と速度を安定させる
  • 共有できる型: 標準化・プラグイン化で、個人の工夫をチーム資産にする
    進め方
  • 最初から全編をしっかり理解する必要はない。「これ知らなかった」「あとで深く調べてみよう」 という気付きが1つでも持ち帰れればOK。
    余談
  • この記事作り終えた直後に公式からもベストプラクティス出ていたので、ぜひご一読を（被る部分もあり）
    Best Practices for Claude Code - Claude Code Docs

概要

項目 内容
対象者 Claude Code初心者〜中級者（技術レベル・スタック混在）
形式 座学（スクリーンショットで補足）
時間 約90分
前提 Claude Code導入済み、基本操作は既知

構成

Part 内容 本編 Q&A 合計
1 Claude Code基礎 10分 2分 12分
2 コンテキストウィンドウ運用 10分 2分 12分
3 拡張機能 15分 2分 17分
4 並列処理 12分 2分 14分
5 フィードバックループ 10分 2分 12分
6 SDD（仕様駆動開発） 5分 2分 7分
7 Teamプラン環境 10分 2分 12分
8 まとめ 5分 - 5分 
【基礎】→【拡張】→【応用】→【補足】

Part 1-2: Claude Codeを正しく理解する
Part 3-4: カスタマイズ手段を知る
Part 5-6: 実践で活かす
Part 7-8: Teamプラン環境 + まとめ

Part 1: Claude Code基礎（10分 + Q&A 2分）

1.1 CLAUDE.mdの役割と書き方

CLAUDE.mdとは

プロジェクトのルート（または任意のディレクトリ）に置くMarkdown形式の設定ファイル。
Claude Codeが毎回自動で読み込み、プロジェクト固有の指示として利用する。

配置場所と読み込み順序

~/.claude/CLAUDE.md          # ユーザーレベル（全プロジェクト共通）
./CLAUDE.md                  # プロジェクトルート
./.claude/CLAUDE.md          # プロジェクトルート（上と同じ挙動）
./src/CLAUDE.md              # サブディレクトリ（そのディレクトリ以下で有効）

Note: ./CLAUDE.mdと./.claude/CLAUDE.mdは同じ挙動。.claude/に設定ファイルをまとめたい場合は後者を使う。
読み込み順序: ユーザーレベル → プロジェクトルート → サブディレクトリ（後から読み込まれたものが優先）

📎 ソース: Claude Code Docs - メモリ

書くべき内容

カテゴリ 例
プロジェクト概要 「このプロジェクトはNext.js + TypeScriptのWebアプリ」
コーディング規約 「関数はアロー関数で書く」「コメントは日本語」
禁止事項 「anyは使わない」「console.logはコミットしない」
ファイル構成 「src/components/にUIコンポーネント」
よく使うコマンド 「テストはnpm test」「ビルドはnpm run build」

書き方のコツ

# プロジェクト概要
Next.js 14 + TypeScript + Prismaで構築されたECサイト

# コーディング規約
- 関数はアロー関数で統一
- 型定義は`types/`ディレクトリに集約
- コンポーネントはnamed exportを使用

# 禁止事項
- `any`型の使用禁止
- `console.log`のコミット禁止

# テスト
テスト実行: `npm test`
テストファイルは`__tests__/`に配置

ポイント:

  • 簡潔に、箇条書きで
  • Claudeが理解しやすい明確な指示
  • 長すぎると毎回のトークン消費が増える（後述）

1.2 .claude/rules/（プロジェクトルール）

プロジェクトルールとは

CLAUDE.mdを複数ファイルに分割して管理する仕組み。プロジェクトが大きくなるとCLAUDE.mdが肥大化するため、トピックごとにファイルを分けられる。

⚠️ 対応バージョン: Claude Code 2.0.64以降（2025年12月10日リリース）で利用可能

配置場所

.claude/rules/
├── coding-style.md      # コーディング規約
├── testing.md           # テスト方針
├── api-design.md        # API設計ルール
└── security/            # サブディレクトリも可
    └── auth.md

paths指定の重要性

YAMLフロントマターでpathsを指定すると、特定のファイルパターンにのみルールを適用できる。

---
paths:
  - src/api/**/*.ts
  - src/services/**/*.ts
---

# API設計ルール
- エラーハンドリングは必ずtry-catchで囲む
- レスポンスは統一フォーマットを使用

重要: paths指定と初期コンテキスト消費

paths指定 読み込みタイミング 初期コンテキスト
なし セッション開始時に読み込み 消費する
あり 該当パスのファイルを読み書きするときに読み込み 消費しない

paths指定がない場合、そのルールはセッション開始時に自動で読み込まれ、初期コンテキストを消費する。ルールが増えるほど、何もしていなくてもトークンが消費される。
一方、paths指定があるルールは該当パスのファイルに対してRead/Edit/Write等のツールが実行されたときに動的に読み込まれる。使わないルールでコンテキストを圧迫しないため、多くのルールを定義しても効率的。

ベストプラクティス: 特定のディレクトリやファイル種別にしか使わないルールには、必ずpathsを指定する。

まとめ

CLAUDE.mdに何でも詰め込むのではなく、ルールを適切に分割し、pathsを指定することが重要。これにより必要なときに必要なルールだけが読み込まれ、コンテキストを効率的に使える。

📎 ソース: Claude Code Docs - メモリ

1.3 設定ファイルの配置場所

3層構造

レベル 配置場所 用途
プロジェクト .claude/ プロジェクト固有の設定
ユーザー ~/.claude/ 個人の全プロジェクト共通設定
エンタープライズ 管理者設定 組織全体のポリシー

主要な設定ファイル

.claude/
├── settings.json        # プロジェクト設定
├── settings.local.json  # ローカル設定（.gitignore）
├── rules/               # プロジェクトルール
├── commands/            # カスタムコマンド
├── skills/              # スキル
├── agents/              # サブエージェント
└── output-styles/       # 出力スタイル

📎 ソース: Claude Code Docs - 設定

1.4 入出力の流れ

Claude Codeの処理フロー

┌─────────────────────────────────────────────────────┐
│  入力                                               │
│  ┌───────────┐  ┌───────────┐  ┌───────────┐       │
│  │ プロンプト │ + │ CLAUDE.md │ + │  rules/   │       │
│  └───────────┘  └───────────┘  └───────────┘       │
└─────────────────────────────────────────────────────┘
                      ↓
┌─────────────────────────────────────────────────────┐
│  Claude Code（LLM）                                  │
│  - ツール実行（ファイル読み書き、コマンド実行等）  　　　　　 │
│  - 必要に応じてスキル/サブエージェント呼び出し   　　　　　  │
└─────────────────────────────────────────────────────┘
                      ↓
┌─────────────────────────────────────────────────────┐
│  出力                                               │
│  - コード生成・編集                                　 │
│  - コマンド実行結果                                 　│
│  - 説明・提案                                       │
└─────────────────────────────────────────────────────┘

※簡略図。実際にはスキル・MCP・出力スタイル等も状況に応じて読み込まれる。
重要: CLAUDE.mdやrules/の内容は毎回のリクエストに含まれる。つまり、設定が多いほどトークンを消費する。
使用中のトークンは/contextで確認可能。

カスタマイズしたステータスラインを設定しておくと分かりやすい。

📎 ソース: Claude Code ベストプラクティス

1.5 許可プロンプトでのTab操作

許可プロンプトとは

Claude Codeがファイル編集やコマンド実行など、重要な操作を行う前に表示されるYes/Noの確認ダイアログ。

Tabキーで追加指示

許可プロンプトでTabキーを押すと追加指示を入力できる。承認（Yes）でも拒否（No）でも、単純な選択ではなく追加の指示を与えられる。

Do you want to make this edit to README.md?
  > 1. Yes, バリデーション用の関数も追加して  ← Tabで入力中
    2. Yes, allow all edits during this session (shift+tab)
    3. No

ユースケース

状況 入力例
承認して追加変更を依頼 Yes, [Tab] 他のファイルにも同じ変更を適用して
承認して修正を指示 Yes, [Tab] 10行目のタイポも直して
承認して条件を追加 Yes, [Tab] エラーハンドリングも入れて
拒否して代替案を指示 No, [Tab] 代わりにこのファイルは変更せずに新しいファイルを作って
拒否して方針変更 No, [Tab] この方法ではなく○○のアプローチで実装して

部分的に正確・部分的に不正確な提案に対して、全体を承認/拒否するのではなく、追加指示で調整できる。

📎 ソース: bcherny's tweet

1.6 与えるべきコンテキスト

ファイルパス

@path/to/file と与えることで、該当ファイルをコンテキストとして与えることができる。

> @README.md に冗長な表現が無いか調べて

画像

コピー＆ペーストやドラッグ＆ドロップすることで、マルチモーダルの入力を利用することができる。

 [ Image #1] (↑ to select)
> このボタンの色を赤色に変えて

Claudeに質問させる ＆ AskUserQuestionツール

抜け漏れを無くすために、Claudeに対し指示をするだけではなく、Claudeに質問をさせるのも有効。
その際はAskUserQuestionツールを使わせると便利。

> ユーザー認証の新機能を実装しようと思います。仕様を決めたいので、AskUserQuestionツールを使って質問して。

AskUserQuestionツールとは、実行中にユーザーへ質問を提示するツール。

質問形式:

  • 2〜4個の選択肢を提示
  • マルチセレクト対応（複数選択可）
  • 「その他」で自由入力可能

**CLAUDE.md**での活用:
明示的に呼び出さなくても使われることがあるが、CLAUDE.mdに指示を書くことで、積極的にAskUserQuestionツールを使って質問させることができる。

# 対話方針
- 曖昧な指示があれば、実装前にAskUserQuestionで確認する
- 複数の実装方法がある場合は、選択肢を提示してユーザーに選ばせる

Part 2: コンテキストウィンドウ運用（10分 + Q&A 2分）

2.1 トークンの仕組み

トークンとは

LLMが処理するテキストの最小単位。単語や文字の一部がトークンに分割される。

日本語 vs 英語

言語 同じ意味の文 トークン数 tokenizer図
英語 Canly Inc. has the mission of "creating a global infrastructure that supports store management," and provides "Canly," a comprehensive management service for MEO measures and Google Maps. 36トークン
日本語 株式会社カンリーは「店舗経営を支える世界的なインフラを創る」というミッションを掲げ、MEO対策・Googleマップの一括管理サービス「Canly（カンリー）」の提供を行っています。 55トークン

日本語は英語よりもトークン消費が多い。これはコストと処理時間に直結する。

📎 参考: OpenAI Tokenizer

トークン増加の影響

トークン数が増えると：

  • 処理時間が増加する場合がある
  • 精度が低下（Lost in the middle等、後述）
  • auto-compactによる文脈喪失（コンテキスト上限に達すると自動圧縮され、指示を忘れる。2.3で詳述）
  • Bedrock（従量課金）: コストが増加、後述
  • Teamプラン（サブスク）: Rate Limitに到達しやすくなる

2.2 コンテキストウィンドウとは？

Claudeの「作業記憶」

コンテキストウィンドウは、Claudeが一度に処理できる情報量の上限。

  • 会話履歴
  • 読み込んだファイル
  • ツール呼び出しの結果
  • CLAUDE.md / システムプロンプト
    → これらの合計に上限がある

上限に達したら？（auto-compact）

コンテキストウィンドウの95% を超えると、auto-compactが自動発動。会話履歴が要約・圧縮されて作業継続可能になる。
注意点:

  • 圧縮時に詳細情報が失われる可能性がある
  • 指示やコードの一部が「忘れられる」ことも
  • 手動で /compact や /clear を使う方が制御しやすい

auto-compactをオフにする設定:

# Claude Code上で設定（推奨）
> /status → Auto-compact → false を選択

# または settings.json で設定
{
  "autoCompact": false
}

💡 ベストプラクティス: auto-compactに頼らず、こまめに /clear や新セッションで区切る。また、指示を遡って別指示にしたい場合は/rewind を使う。

2.3 トークン増加の悪影響（雪だるま式）

LLM APIはステートレス

重要な事実: LLM APIはステートレス。つまり、会話の履歴をAPI側で保持していない。

リクエスト1: [メッセージ1] → レスポンス1
リクエスト2: [メッセージ1 + レスポンス1 + メッセージ2] → レスポンス2
リクエスト3: [メッセージ1 + レスポンス1 + メッセージ2 + レスポンス2 + メッセージ3] → レスポンス3

毎回、全履歴を再送信している。これがトークン消費が「雪だるま式」に増える理由。

📎 ソース: OpenAI - Conversation state

悪影響1: 精度低下

Lost-in-the-middle現象

長いコンテキストの中間部分が無視されやすい。LLMは最初と最後の情報を重視する傾向がある。

📎 ソース: Lost in the Middle 論文

悪影響2: Rate Limit到達の加速

Teamプラン/サブスクリプションでは、一定時間内のトークン使用量に制限がある。

コンテキストが肥大化
    ↓
1リクエストあたりのトークン消費が増加
    ↓
同じ回数の会話でもRate Limitに早く到達
    ↓
「使用量上限に達しました」で作業中断（もしくは従量課金に移行しコスト増加）

悪影響3: コスト増加

Bedrock等の従量課金では、トークン数がそのままコストに反映される。
Claude Opus 4.5の料金（Bedrock）:

種別 料金
入力 $5 / 100万トークン
出力 $25 / 100万トークン

具体例: 同じ10回のやり取りでも、コンテキストサイズで大きく変わる

シナリオ 入力トークン消費 入力コスト
軽量（10K × 10回） 100Kトークン 約$0.50
肥大化（50K × 10回） 500Kトークン 約$2.50
放置（100K × 10回） 1Mトークン 約$5.00

1日の作業で考えると: 100回のやり取りなら、軽量 vs 放置で $5 vs $50 の差になる。

📎 ソース: Amazon Bedrock Pricing

悪影響4: auto-compactによる文脈喪失

コンテキストウィンドウの95%を超えると、auto-compactが自動発動し、会話履歴が要約・圧縮される。
圧縮時に失われやすい情報:

失われやすい 残りやすい
初期の細かい指示 直近のやり取り
修正したコードの詳細 大まかなタスクの目的
「〜しないで」等の禁止事項 最後に言及した内容

具体例:

あなた: 「TypeScriptで、エラーハンドリングを丁寧に書いて」
Claude: （指示通りに実装）
# ... 長い会話 ...
# ... auto-compact発動 ...
あなた: 「次の関数も同じ方針で」
Claude: （JavaScriptで、エラーハンドリングなしで実装）← 指示を忘れている

重要: Lost in the middleは「薄まる」だが、auto-compactは「消える」。より深刻な影響がある。

2.4 対策: /clear, /compact, 新セッション

/clear - 会話履歴をクリア

会話履歴を完全にリセット。新しいタスクを始める前に実行すると効果的。

/compact - 履歴を要約して圧縮

これまでの会話を要約し、トークン数を削減。文脈は維持しつつコンテキストをスリム化。
引数で指示を追加できる:

> /compact TypeScriptの型定義に関する議論を重点的に残して

引数を渡すと、圧縮時に何を重視して残すかを指示できる。重要な文脈が失われるのを防ぐのに有効。

新セッション

ターミナルを新しく開いてclaudeを起動。最もクリーンな状態で開始できる。

使い分けの目安

状況 推奨アクション
新しいタスクを始める /clear または 新セッション
長い会話の途中で重くなった /compact
全く別の作業に移る 新セッション
デバッグが堂々巡りしている /clearして最初から

📎 ソース: Claude Code Docs - スラッシュコマンド

2.5 Planモード

Planモードとは

計画を立ててから実行するモード。複雑なタスクで精度を上げるのに効果的。

使い方

Shift+Tab  # Planモードの切り替え
> /plan    # コマンドでも可

または、プロンプトに「まず計画を立てて」と指示。

Planモードの流れ

  1. タスクの分析（ファイル探索、コード調査等）
  2. 実行計画の提示（ファイル変更、コマンド実行等）
  3. ユーザーの承認（下記の選択肢から選択）
  4. 計画に沿って実行

承認時の選択肢

計画が完成すると、以下の選択肢が表示される：

選択肢 動作
Yes, clear context and auto-accept edits コンテキストをクリアして自動実行
Yes, auto-accept edits そのまま自動実行
Yes, manually approve edits 編集ごとに承認しながら実行
Type here to tell Claude what to change 計画の修正を指示

「Yes, clear context and auto-accept edits」の効果:
Planモードでは、計画を立てるために多くのファイルを読み込んだり、コードを調査したりする。これらの調査で蓄積した情報はノイズになりやすい。
この選択肢を選ぶと：

  • 調査中に読み込んだファイル内容等をクリア
  • 計画だけを残して最小限のコンテキストで実行開始
  • Part 2.3で解説した「コンテキスト肥大化」を防げる
┌─────────────────────────────────────────────┐
│  Planモード中のコンテキスト               　　   │
│  ・調査で読んだファイル（多数）             　　  │
│  ・試行錯誤のやり取り                      　   │
│  ・最終的な計画 ← これだけあれば実行可能    　　　 │
└─────────────────────────────────────────────┘
         ↓ Yes, clear context...を選択
┌─────────────────────────────────────────────┐
│  実行開始時のコンテキスト                    　　│
│  ・最終的な計画のみ ← 軽量！                 　　│
└─────────────────────────────────────────────┘

ベストプラクティス: 基本的には「Yes, clear context...」を選んでOK。計画に必要な情報は要約されて引き継がれるため、調査内容が失われる心配はない。

いつ使うか

状況 Planモード
複数ファイルにまたがる変更 ○ 推奨
大規模なリファクタリング ○ 推奨
新機能の実装 ○ 推奨
簡単なバグ修正 △ 不要な場合も
質問への回答 × 不要

📎 ソース: Claude Code ベストプラクティス

Part 3: 拡張機能（15分 + Q&A 2分）

3.1 カスタマイズ手段の全体像

Claude Codeには複数のカスタマイズ手段がある。それぞれの役割と使い分けを理解しよう。

比較表

機能 トリガー ローカル配置 プラグイン配置 主な用途
スラッシュコマンド 手動 /cmd .claude/commands/ commands/ 定型タスクの実行
スキル 自動検出 .claude/skills/ skills/ 特定ドメインの知識提供
サブエージェント 自動委譲 .claude/agents/ agents/ 専門タスクの分担
Hooks イベント駆動 .claude/settings.json hooks/hooks.json 自動チェック・変換
MCP 外部連携 settings.json / .mcp.json .mcp.json※ 外部サービスとの統合
出力スタイル /output-style .claude/output-styles/ output-styles/ 出力形式のカスタマイズ
GitHub Actions PR/Issue GitHub設定 - 自動コードレビュー、自動実装
マーケットプレイス /plugin - 設定 プラグインの配布・共有

命名空間の違い

ローカルとプラグインでは、呼び出し時の名前が異なる:

種類 ローカル プラグイン
コマンド /review /plugin-name:review
スキル /security-audit /plugin-name:security-audit
エージェント 自動選択 自動選択（内部で識別）

プラグインからインストールした機能は、プラグイン名がプレフィックスとして付く。

選び方フローチャート

何をしたい？
    │
    ├─ 定型作業を呼び出したい → スラッシュコマンド
    │
    ├─ 特定の状況で自動的に知識を使ってほしい → スキル
    │
    ├─ 複雑なタスクを分担させたい → サブエージェント
    │
    ├─ ツール実行前後に自動チェックしたい → Hooks
    │
    ├─ 外部サービスと連携したい → MCP
    │
    ├─ 出力のスタイルを変えたい → 出力スタイル
    │
    ├─ PRやissueイベントで自動作業してほしい → GitHub Actions
    │
    └─ プラグインをまとめてインストールしたい → マーケットプレイス

3.2 スラッシュコマンド

役割

手動で呼び出す定型タスク。繰り返し使うプロンプトをコマンド化できる。

配置場所

.claude/commands/
├── review.md        # /review で呼び出し
├── test.md          # /test で呼び出し
└── deploy/
    └── staging.md   # /deploy:staging で呼び出し

例: レビューコマンド

<!-- .claude/commands/review.md -->
以下のファイルをレビューしてください:
$ARGUMENTS

チェック項目:
- 型安全性
- エラーハンドリング
- パフォーマンス

使い方: /review src/components/Button.tsx

ポイント

  • $ARGUMENTSで引数を受け取れる
  • ディレクトリで名前空間を作れる（/deploy:staging）
  • チームで共有可能（Gitにコミット）

📎 ソース: Claude Code Docs - スラッシュコマンド

3.3 スキル

役割

Claudeが自動的に検出して使う知識。特定のドメインやライブラリの使い方を教える。
フロントマター（冒頭の —- で囲まれた領域）のみ初期コンテキストとして読まれるため、肥大化しづらい。適切に自動ロードされるようにするため、descriptionの書き方が重要。

配置場所

.claude/skills/
├── prisma/
│   └── SKILL.md
└── testing/
    └── SKILL.md

SKILL.mdのフォーマット

---
name: Prisma ORM
description: Prismaを使ったデータベース操作のベストプラクティス
---

# Prismaの使い方

## クエリの書き方
- findManyには必ずtakeでlimitをつける
- includeの深さは2階層まで

## マイグレーション
- 本番環境では`prisma migrate deploy`を使用

自動適用の仕組み

Claudeは会話の内容から関連するスキルを自動検出し、必要に応じて参照する。

エージェントスキルのオープンスタンダード化

  • 2025年10月: Anthropicが導入
  • 2025年12月: OpenAI, GitHub等も採用

📎 ソース: Skills for organizations, partners, the ecosystem \| Claude

補足: スラッシュコマンドとスキルの統合

両者は機能が類似してきており、スキルも /skill-nameで直接呼び出せるようになった。
公式ドキュメントでも「Skillツール（以前のSlashCommand）」と記載されており、内部的には統合が進んでいる。

3.4 サブエージェント

役割

専門タスクを別のエージェントに委譲。メインのClaudeが必要に応じて呼び出す。

ビルトインエージェント

エージェント モデル 用途
Bash inherit Bashコマンド実行スペシャリスト。git操作、コマンド実行等のターミナルタスク
general-purpose sonnet 汎用エージェント。複雑な質問の調査、コード検索、マルチステップタスク実行
statusline-setup sonnet ユーザーのステータスライン設定を構成
Explore haiku コードベース探索に特化した軽量エージェント。文脈効率を最適化しながらファイル検索・コード検索を実行
Plan inherit 計画生成に特化。Planモード内で動作し、実装戦略を設計
claude-code-guide haiku Claude Codeの機能に関する質問に対し、公式ドキュメントを参照し回答

カスタムエージェントの配置

.claude/agents/
└── security-reviewer.md

例: セキュリティレビューエージェント

---
name: Security Reviewer
description: セキュリティ観点でのコードレビュー
tools:
  - Read
  - Grep
  - Glob
---

# セキュリティレビュー担当

以下の観点でコードをレビューしてください:
- SQLインジェクション
- XSS
- 認証・認可の漏れ
- 機密情報のハードコード

ポイント

  • 並列度上限は10（超過分はキュー）
  • スキルからcontext: forkでサブエージェントを呼び出すと、分離コンテキストで実行可能
    context: fork + agentの使用例（SKILL.md内）:
---
name: Heavy Analysis
description: 大規模な分析を分離コンテキストで実行
context: fork
agent: security-reviewer
---

# 分析用スキル
このスキルはforkされた独立コンテキストで、
指定したサブエージェント（security-reviewer）によって実行されます。

context: forkとagentを組み合わせることで、特定のサブエージェントに分離コンテキストでタスクを実行させられる。メインのコンテキストを圧迫せず、専門エージェントの知識を活用できる。

📎 ソース: Claude Code Docs - サブエージェント

3.5 Hooks

役割

ツール実行の前後に自動で処理を挟む。品質チェックや自動変換に使える。

Hookの種類（一部抜粋）

Hook タイミング 用途例
PreToolUse ツール実行前 危険な操作のブロック
PostToolUse ツール実行後 フォーマット自動適用
SessionStart セッション開始時 環境チェック
UserPromptSubmit プロンプト送信時 入力の検証
Stop 停止時 クリーンアップ

設定場所（ローカル）

// .claude/settings.json または ~/.claude/settings.json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "command": "npx prettier --write $CLAUDE_FILE_PATH"
      }
    ]
  }
}

プラグイン配布時

プラグインではhooks/hooks.jsonに配置

// hooks/hooks.json
{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "${CLAUDE_PLUGIN_ROOT}/scripts/check.sh"
      }]
    }]
  }
}

使用例: ファイル保存時に自動フォーマット

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "command": "npx prettier --write $CLAUDE_FILE_PATH"
      }
    ]
  }
}

📎 ソース: Claude Code Docs - フック

3.6 MCP（Model Context Protocol）

役割

外部サービスとClaude Codeを連携。GitHub、Slack、Notion等と統合できる。

設定場所（ローカル利用時）

方法1: settings.json

// .claude/settings.json
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
    }
  }
}

方法2: .mcp.json

// .mcp.json（プロジェクトルート）
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
    }
  }
}

連携可能なサービス例

  • GitHub（Issue、PR操作）
  • Backlog（Issue操作）
  • Notion（ドキュメント操作）

以前はMCPを設定するだけで未使用でも大量のコンテキストが消費されていたが、現在は10%を超える場合は自動的に初期ロードされず、必要に応じて追加ロードされるようになった。

📎 ソース: Claude Code Docs - MCP連携

3.7 出力スタイル

役割

Claudeの出力スタイルをカスタマイズ。説明の詳しさや口調を変更できる。

ビルトイン

スタイル 特徴
Default 標準的な出力
Explanatory 教育的、詳しい説明
Learning 協調学習、一緒に考える

使い方

> /output-style explanatory

カスタムスタイルの作成（ローカル）

<!-- .claude/output-styles/concise.md -->
---
name: Concise
description: 簡潔な出力
keep-coding-instructions: true
---

- 説明は最小限に
- コードにはコメントを入れない
- 箇条書きを多用

CLAUDE.mdとの違い

項目 出力スタイル CLAUDE.md
適用方法 システムプロンプト置換 ユーザーメッセージ追加
影響範囲 全体的な振る舞い プロジェクト固有のルール
切り替え /output-styleで随時 自動適用

📎 ソース: Claude Code Docs - 出力スタイル

3.8 GitHub Actions

役割

PRやIssueでClaude Codeを自動実行。コードレビューや修正提案を自動化。

セットアップ

> /install-github-app

機能

機能 説明
自動コードレビュー PR作成時に自動でレビュー
@claudeコメント コメントで指示を出せる
修正コミット 指示に基づいて修正をコミット

使い方

PRのコメントで:

@claude このPRをレビューして、セキュリティ上の問題があれば指摘してください

@claude エラーハンドリングを追加して

応用: 定期実行・イベントフック

GitHub Actionsのワークフロー設定を工夫すれば、PR以外のトリガーでもClaude Actionを実行できる：

  • 定期実行（cron）: 毎朝の依存関係チェック、週次のコード品質レポート
  • Issue作成時: Issueの内容から自動で実装してPR作成
  • 特定ラベル付与時: auto-fixラベルで自動修正を実行

📎 ソース: Claude Code Docs - GitHub Actions連携

3.9 マーケットプレイス プラグイン

役割

プラグインを配布・共有する仕組み。カスタムスラッシュコマンド、スキル、エージェント、MCPサーバーを1つのパッケージとしてインストールできる。

インストール方法

# マーケットプレイスの追加
/plugin marketplace add owner/repo

# プラグインのインストール
/plugin install {plugin-name}@{marketplace-name}

# UI から発見・インストール
/plugin > Discover

当社のマーケットプレイス

カンリーではprivateリポジトリで、自作のマーケットプレイスを運用している。
当社マーケットプレイスの概要はこちら

https://speakerdeck.com/rfdnxbro/claude-codegabao-su-jin-hua-sitepuraguinzhui-cong-gaturainodeban-zi-dong-hua-sitahua

Part 4: 並列処理（10分 + Q&A 2分）

LLMは調査や返答に時間がかかる処理も多いため、必要に応じて並列処理を活用することで開発生産性を高めることが可能。
今回はバックグラウンドタスク、サブエージェント、git worktreeについて解説する。

4.1 バックグラウンドタスク化

概要

メインの会話を続けながら、別タスクをバックグラウンドで実行できる。

使い方

タスク実行中にCtrl+b 

> サブエージェントを使ってコードベースを理解して 

[Ctrl+b]
（バックグラウンドで実行開始）

> 別の質問...
（メインの会話を続けられる）

↓でタスク状況を確認できる

4.2 サブエージェント並列実行

概要

Claude Codeは内部で複数のサブエージェントを並列実行できる。

並列度の上限

  • 最大10個のサブエージェントが同時実行可能
  • 超過分はキューに入り順次実行

コンテキストの独立性

メインエージェント
    │
    ├─→ サブエージェント1（新しいコンテキストで開始）
    │       └─ 独立して実行
    │
    └─→ サブエージェント2（新しいコンテキストで開始）
            └─ 独立して実行
  • 各サブエージェントは新しい独立したコンテキストで開始（親のコピーではない）
  • 詳細な出力はサブエージェント内に留まり、要約のみが親に返される
  • 権限は親から継承される

プロンプトでの指示

並列実行を促すには、プロンプトで明示的に指示する:

issue最新50個を、5個ずつサブエージェントで並列取得して

📎 ソース: Claude Code Docs - サブエージェント

4.3 サブエージェントのトレードオフ

メリットと注意点

観点 効果
メインのコンテキスト ✅ 軽くなる（詳細はサブエージェント内に留まり、要約のみ返される）
作業時間 ✅ 並列実行で短縮できる
作業衝突 ⚠️ 変更を伴う場合は作業が衝突したり、同じ作業を各エージェントが重複実行することがある
トータルのトークン消費 ⚠️ 増える可能性がある（複数エージェントが同じファイルを読む場合など）

注意: トークン消費が必ず増えるわけではない。調査範囲が重複しなければ、順次実行と大差ないケースもある。

Rate Limit影響

プラン 影響
Teamプラン（サブスク） 並列実行でRate Limit消費が加速する可能性
Bedrock（従量課金） 重複読み込みがあればコスト増加

使い分けの目安

状況 推奨 理由
独立した複数タスク ○ 並列実行 時間短縮
大量の調査（依存関係なし） ○ 範囲分割して並列 時間短縮
依存関係のあるタスク × 順次実行 結果を待つ必要
軽いタスクの連続 × 順次実行 オーバーヘッドが大きい
重いタスク（テスト、ビルド） ○ 並列実行 待ち時間削減

ベストプラクティス

  1. 時間短縮が見込める時に並列化 - 独立した重いタスクや大量調査に有効
  2. メインのコンテキストは軽く保つ - サブエージェントの結果要約を受け取るため
  3. 依存関係を意識 - 結果を使うタスクは順次実行

📎 ソース: Claude Code ベストプラクティス

4.4 git worktreeによる並列実行

サブエージェントとの違い

サブエージェントは1つのセッション内での並列化。git worktreeはセッション自体を分割する並列化。

方式 特徴
サブエージェント 1セッション内で複数タスクを分担
git worktree 複数セッションで別々のブランチを同時作業

git worktreeとは

同じリポジトリの複数のブランチを別ディレクトリで同時にチェックアウトできるGitの機能。

my-project/              # mainブランチ
my-project-feature-a/    # feature-aブランチ（worktree）
my-project-feature-b/    # feature-bブランチ（worktree）

ユースケース

  • 複数機能の同時開発: 機能Aの実装中に、別セッションで機能Bも進める
  • レビュー対応しながら新規開発: PRのフィードバック対応と新機能開発を並行
  • 大規模リファクタリング: 影響範囲ごとにworktreeを分けて並列作業

使い方

ターミナルから手動で:

# worktreeを作成
git worktree add ../my-project-feature-a feature-a

# 別ターミナルでClaude Codeを起動
cd ../my-project-feature-a && claude

Claude Desktopなら自動管理:
Claude Desktopはgit worktreeを自動で作成・管理する。複数セッションを開くだけで、それぞれ独立したworktreeで作業できる（Part 7.4参照）。

サブエージェントとの使い分け

やりたいこと 推奨
1つのタスク内で調査を分担 サブエージェント
別ブランチで別機能を同時開発 git worktree
ファイル編集の競合を避けたい git worktree

📎 ソース: Git - git-worktree Documentation

Part 5: フィードバックループ（10分 + Q&A 2分）

5.1 フィードバックループとは

Claude Codeを使っていると、期待と違う出力が返ってくることがある。その修正のやり取りをどう活かすかがフィードバックループの考え方。

タスク実行 → 期待と違う → 修正指示 → 期待通りに
                              ↓
                    この経験をどう活かす？

核心の問い: 「次に同じタスクが来たとき、一発で期待通りの出力を出すには？」
この問いを意識することで、作業が「その場限り」から「資産」に変わる。

5.2 4つの段階

フィードバックの活かし方には段階がある。どこから始めても良いし、状況に応じて使い分けられる。

段階1: その場で修正（初期対応）

今すぐ直したいときの対処

段階2: 人間が考えてルール化（仕組み化）

同じ問題を繰り返さないための仕組みづくり

段階3: Claudeに考えさせてルール化（仕組み化の進化）

AIが最適なルールを提案して追記

段階4: 自動でルールが改善される（完全自動化）

使うほど品質が向上する自己改善ループ

5.3 段階1: その場で修正

やり方

期待と違う出力が返ってきたら、その場で追加指示を出す。

あなた: 「このコードをレビューして」
Claude: （期待と違う観点でレビュー）
あなた: 「セキュリティ観点でお願い」
Claude: （まだ足りない）
あなた: 「あと型安全性も見て」
Claude: （やっと期待通り）

特徴

  • 手軽: 今すぐできる
  • 課題: 次回も同じやり取りが発生する、品質が安定しない

5.4 段階2: 人間が考えてルール化

やり方

「なぜこの修正が必要だったか」を考え、CLAUDE.mdやrules/に追記する。

修正のやり取り
    ↓
「セキュリティと型安全性を毎回指示している...」
    ↓
CLAUDE.mdに追記

<!-- CLAUDE.mdに追記 -->
# レビュー方針
コードレビュー時は以下を必ずチェック:
- セキュリティ（インジェクション、認証漏れ）
- 型安全性（any禁止、型定義の適切さ）
- パフォーマンス（N+1、不要な再レンダリング）

特徴

  • 効果: 同じプロジェクトでは同様の問題が起きにくくなる
  • 課題: 人間が考えて言語化する必要がある

5.5 段階3: Claudeに考えさせてルール化

やり方

修正が必要だったとき、どういう指示があればこのミスが起きなかったかをClaude自身に考えさせ、CLAUDE.mdに追記させる。

あなた: 「今の修正について、最初からこの出力を出すには
        CLAUDE.mdにどんな指示があれば良かった？
        考えて追記して」

Claude: （分析して、より本質的なルールを提案・追記）

特徴

  • 効果: 人間が気づかない観点も含めた、より効率的なルールが得られる
  • 効率: 言語化の手間が省ける
  • 課題: 追記内容のレビューは必要

具体例

あなた: 「今の修正について、最初からこの出力を出すにはどんな指示があればよかった？
        次から自動で考慮されるようにCLAUDE.mdに追記して」

Claude: 以下を追記しました:
        # エラーハンドリング方針
        - 外部API呼び出しは必ずtry-catchで囲む
        - エラーはカスタムエラークラスでラップ
        - ユーザー向けメッセージと開発者向けログを分離

5.6 段階4: 自動でルールが改善される

やり方

GitHub Actions等を使い、PRレビューやコード生成の結果から自動的にルールが更新される仕組みを作る。

PRでClaudeがレビュー
    ↓
人間が修正指示をコメント
    ↓
「この指摘を次回から自動で行うにはどんなルールが必要か」を自動分析
    ↓
CLAUDE.mdへの追記PRを自動作成

特徴

  • 効果: 使うほど品質が自動的に向上する
  • 効率: 人間の介入が最小限
  • 課題: 仕組みの構築が必要

イメージ

┌─────────────────────────────────────────────────────┐
│  自己改善ループ                                     　 │
│                                                     │
│  コード生成 → レビュー → 修正指摘 → ルール抽出     　　　  │
│       ↑                            　　↓ 　　　       │
│       └──────────── CLAUDE.md更新 ←────┘     　　   　│
└─────────────────────────────────────────────────────┘

5.7 段階の選び方

状況 推奨
今すぐ直したい 段階1: その場で修正
同じ問題が2回以上起きた 段階2〜3: ルール化
言語化が難しい 段階3: Claudeに考えさせる
チーム全体で品質を上げたい 段階4: 自動化

ポイント: どの段階が「正解」ということではない。状況に応じて使い分け、徐々に仕組み化を進めていくのが現実的。

5.8 ルールの肥大化に注意

なぜ注意が必要か

ルールを追加し続けると、CLAUDE.mdやrules/が肥大化する。Part 2で解説した通り、これらは毎回のリクエストに含まれるため、コンテキストウィンドウを圧迫する。

モデルの性能限界かもしれない

期待と違う挙動が返ってきたとき、それは現時点のモデルの性能限界が原因かもしれない。

期待と違う挙動
    ↓
ルールを追加して補う
    ↓
モデルがアップデート
    ↓
そのルールは不要に？

モデルは進化し続けている。以前は必要だったルールが、新しいモデルでは不要になることもある。

定期的なリファクタリング

ルールも定期的に見直しが必要。

観点 アクション
重複 似たルールを統合
不要 モデル性能向上で不要になったルールを削除
効果検証 本当に効いているか確認

ベストプラクティス: ルールを追加するだけでなく、定期的に「このルールはまだ必要か？」を問い直す。コンテキストは有限なリソースとして意識する。

Part 6: SDD（仕様駆動開発）（5分 + Q&A 2分）

6.1 バイブコーディングの限界

バイブコーディングとは

バイブコーディングとは: 「いい感じにして」「なんかこんな感じで」と曖昧な指示でAIに任せる開発スタイル。

「ログイン機能作って」
    ↓
Claude: （何となく作る）
    ↓
「違う、こうじゃなくて...」
    ↓
何度も修正のやり取り

問題点:

  • 期待と出力のズレが大きい
  • 修正のやり取りでトークン消費
  • 「なんか違う」の繰り返し

6.2 SDDとは

SDD（Spec-Driven Development＝仕様駆動開発） = 仕様を先に定義してから実装するアプローチ。

基本の流れ

┌─────────────┐
│   要件定義   │  ← まずここをしっかり
└──────┬──────┘
       ↓
┌─────────────┐
│   設計確認   │  ← 実装前に合意
└──────┬──────┘
       ↓
┌─────────────┐
│    実装     │  ← 仕様通りに実装
└─────────────┘

6.3 SDDの流れ

Step 1: 仕様を書く（人間 or Claude）

# ログイン機能仕様

## 機能要件
- メールアドレスとパスワードで認証
- JWTトークンを発行（有効期限24時間）
- ログイン失敗は5回でロック（30分）

## API仕様
- POST /api/auth/login
- リクエスト: { email, password }
- レスポンス: { token, user }

## エラーハンドリング
- 401: 認証失敗
- 429: レート制限
- 423: アカウントロック

Step 2: 設計を確認

「この仕様でログイン機能を実装する設計を提案して」

Claudeが設計案を出す → 確認・修正

Step 3: 実装

「この仕様と設計に基づいて実装して」

仕様が明確なので、一発で期待通りの実装が出やすい。

6.4 背景: AIコーディング時代の開発手法

SDDは、AWSのAI IDE「Kiro」が2025年7月に発表された際に、同時に提唱された概念。Kiroは「Spec（仕様）」を中心に開発を進めるワークフローを採用しており、これがSDDの考え方を広めるきっかけとなった。
Claude Codeでも同様のアプローチが有効であり、仕様を明確にすることでAIの出力精度が大幅に向上する。

6.5 使い分け

状況 アプローチ
新規機能（中〜大規模） SDD推奨
複数人で開発 SDD推奨
小さなバグ修正 バイブコーディングでOK
プロトタイプ・実験 バイブコーディングでOK
仕様が曖昧なまま進めたい バイブコーディング（ただし手戻り覚悟）

6.6 SDDを支援するツール

SDDを実践するためのツールが登場している。

ツール 概要
Kiro AWSから提供されている、SDDに沿ったUI/UXを提供するIDE
spec-kit GitHubが公開した仕様駆動開発のためのスターターキット
OpenSpec AI時代の仕様記述フォーマットを標準化するプロジェクト
cc-sdd 日本発のSDD実践ツール

これらのツールを活用することで、仕様の書き方やワークフローを標準化しやすくなる。

Part 7: Teamプラン環境（10分 + Q&A 2分）

7.1 Bedrock vs Teamプラン

比較表

項目 Bedrock（従量課金） Teamプラン（サブスク）
課金方式 トークン従量課金 月額基本料金$125 + 超過分従量課金
コスト予測 使った分だけ（変動） 基本は予測しやすい（超過時は変動）
Rate Limit なし（コストで制限） あり（プランによる）
共通機能 CLI、VSCode/Cursor Extension CLI、VSCode/Cursor Extension
追加機能 - Desktop, Web, Slack, Chrome

7.2 料金プラン概要

個人向けプラン

プラン 月額 Rate Limit目安
Pro $20 基本的な使用
Max 5x $100 Proの5倍
Max 20x $200 Proの20倍

企業向けプラン

プラン 月額 Rate Limit目安
Team $125 Max 5xと同等
Enterprise 要問合せ カスタム

Rate Limit超過時

Rate Limitを超過すると、管理者設定次第で自動的に従量課金モードに切り替わる。

Rate Limitの種類

種類 リセット間隔
Daily 5時間ごと
Weekly 1週間

確認方法: Teamプラン利用中は /usage コマンドで現在のRate Limit消費状況を確認できる。

  • 5時間ごとにリセットされるCurrent Session
  • 1週間ごとにリセットされるCurrent week（all models）
  • 1週間ごとにリセットされるCurrent week（Sonnet only）

📎 ソース: Anthropic 料金ページ

Rate Limitを理解した、稼働の最大化

Rate Limitは「使うな」という制約ではなく、使い方を最適化するための前提条件。
上限に引っかかること自体は珍しくないし、引っかかったからといって過度に使用を控える必要はない。
一方で、TeamプランではRate Limitがそのまま作業継続性とコストに効く。だから、Rate Limitの時間窓に合わせて仕事を並べ替えるという発想を持っておくと便利。

例：

  • 調査→タスク化→自動実装の順に寄せる（まずAIに渡せる形を作って、次に実装を回す）
  • Rate Limitに到達したら、無理に押し切らず、Claude Codeを使わない業務に切り替え → リセット後に再開する
    もちろん強制ではなく、状況に応じて「押し切る／切り替える」を選べればOK。

特におすすめは、最初の5時間を“調査とタスク化”に集中し、そこで作ったタスクリストを、次の5時間以降は自動実装に流し込む運用。
※この「5時間」は、セッション開始タイミングからカウントされる。
なので、午前は人間が手作業で業務をして、午後からClaude Codeを触り始めると、残り時間が少なくなって1タームで走り切れずに終わることがある。

  • もし「調査→タスク化→自動実装」を1タームで回したい日は、できるだけ早めにClaude Codeを起動して“時計”をスタートさせる
  • 逆に、午後から触る日は「今日は調査・タスク化まで」と割り切る、などターム前提で組み立てる
    こういう運用にすると、5時間制限の中でもブレなく回しやすい。
  • 起きている時間は「判断と設計」に集中
  • 業務時間外は「実装と検証」が回り続ける
    という形になり、理論上は24時間稼働に近い開発サイクルを作れる。
    ただし注意点として、Daily（5時間）を上手く回せても、Weeklyの上限で詰まることがある。
  • 週次の消費量は蓄積される
  • 並列化や長文コンテキストの放置は、週次消費の加速要因になる
    だからこそ、Dailyの区切り（5時間）を意識して「調査→タスク化→自動実装」を設計しつつ、週次の残量も/usageで定期的に見て、無理のないペース配分をするのが現実的な運用になる。

7.3 利用可能な環境

┌─────────────────────────────────────────────────────────────┐
│  共通（Bedrock / Teamプラン両方で利用可能）                　　  │
├────────────────────────────┬────────────────────────────────┤
│           CLI              │    VSCode / Cursor Extension   │
│       (ターミナル)          │          (IDE統合)            　 │
└────────────────────────────┴────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│  Teamプラン追加機能                                          　│
├──────────────┬──────────────┬──────────────┬────────────────┤
│   Desktop    │     Web      │    Slack     │    Chrome      │
│    (GUI)     │  (Browser)   │   (Chat)     │ (Browser Auto) │
└──────────────┴──────────────┴──────────────┴────────────────┘

7.4 各環境の特徴と使い分け

共通環境（Bedrock / Teamプラン両方）

Claude Code CLI

特徴:

  • ターミナルで claude コマンドを実行
  • 最も基本的な利用方法
  • カスタマイズ性が高い（Hooks、MCP等）

ユースケース:

  • 日常的な開発作業
  • 自動化スクリプトとの連携
  • 細かい設定を活用したい

VSCode / Cursor Extension

特徴:

  • IDE内でClaude Codeを利用
  • エディタと統合された体験
  • ファイル操作がシームレス

ユースケース:

  • IDE中心の開発スタイル
  • コードを見ながら指示を出したい
  • ターミナル操作を減らしたい

Teamプラン追加環境

Claude Desktop

特徴:

  • GUIアプリケーション
  • git worktree自動管理
  • 複数セッションを一元管理

ユースケース:

  • 並列で複数ブランチの開発
  • ターミナルに慣れていないメンバー
  • セッション管理を視覚的に行いたい

Claude Code on the web

特徴:

  • ブラウザで動作
  • サンドボックス環境（安全）
  • ターミナルから&プレフィックスで送信可能

ユースケース:

  • 緊急時の一次調査（手元にPCがないやむを得ない場面）
  • 安全な環境で実験し

ターミナルからの送信:

&このコードをレビューして

→ Web版に送信される

Claude in Slack

特徴:

  • Slackで@Claudeと呼び出し
  • チームメンバーと共有しながら使える
  • SlackからClaude Code on the webへ送信可能

ユースケース:

  • チーム内での質問対応
  • 複数リポジトリにまたがる調査
  • 非エンジニアとのコラボレーション

使い方:

@Claude このエラーの原因を調べて

Claude in Chrome

特徴:

  • ブラウザ操作の自動化
  • claude --chromeで起動
  • Webページの操作・スクレイピング

ユースケース:

  • Webアプリのテスト自動化
  • ブラウザ上のデータ収集
  • UIの動作確認
  • 開発に限らない業務の定期実行

起動方法:

claude --chrome

使い分けまとめ

やりたいこと 環境 利用可能プラン
普段の開発（ターミナル） CLI 共通
IDE中心の開発 VSCode / Cursor 共通
並列ブランチ開発 Desktop Teamプラン
リモート/スマホから Web Teamプラン
チームで共有しながら Slack Teamプラン
ブラウザ操作自動化 Chrome Teamプラン

※この記事ではBedrockとTeamプランのため、上記比較表となる。個人契約ならProやMaxでも使える

📎 ソース: Claude Code Docs - Web版Claude Code

Part 8: まとめ（5分）

今日の結論

Claude Codeは「使う」だけでも便利だが、運用（設定・型化・共有）までやると伸びる。
大事なのは、自分だけ上手くなるより、チームに再利用できる形にすること。

今日のポイント（Part 1〜7の要点）

1. 設定で再現性を作る

CLAUDE.md / rules/ / skills/ に寄せると、毎回の指示が減り、出力が安定しやすくなる。

2. コンテキストを設計する

長く回し続けるほど、精度・速度・安定性が落ちやすい。

3. 拡張機能を使い分ける

  • コマンド（commands）: 手動で呼ぶ定型作業を短縮（例：レビュー、テスト、調査テンプレ）
  • スキル（skills）: 特定ドメインの知識を自動適用（description設計が重要）
  • サブエージェント（agents）: 専門タスクの分担（レビュー専用、調査専用など）
  • Hooks: ツール実行の前後で自動チェック（フォーマット、危険操作ブロック等）
  • MCP: 外部情報とつなぐ（GitHub/Slack/Notion等）
  • GitHub Actions: PR/Issue起点の自動化（レビューや修正提案を運用に乗せる）
  • プラグイン（組織で再利用）: コマンド/スキル/エージェント/Hooks/MCP設定をパッケージ化して配布し、「個人の工夫」を「組織の標準」にする

4. フィードバックを資産化する

ズレた経験は、その場の修正で終わらせず、次に効く形に戻す。

5. 大きい作業はSDDで進める

中〜大きい変更は 仕様→設計→実装 の順に寄せると、手戻りが減る。

6. Teamプラン前提を理解する

Rate Limit前提で運用を組む（無理に節約するのではなく、途切れない設計を意識する）。

今日から始めること（最小セット）

A. 作業単位で区切る（調査→計画→実行）

  • 原則: 調査フェーズと実行フェーズは、同じセッションでズルズル続けない
  • auto-compactで回し続けるのは非推奨: コンテキストが欠落して指示・制約が落ちるリスクがある
  • Planモードの活用: 調査で読み込んだ情報はノイズになりやすいので、計画を作ったら「計画だけ残して」実行に入る

B. ズレた経験を“次に効く形”で還元する

  • プロジェクトで繰り返す → CLAUDE.md / rules/
  • 手動で何度も呼ぶ → コマンド
  • 自動で効かせたい → スキル
  • 実行前後で守りたい → Hooks
  • 外部情報が必要 → MCP
  • 組織全体に配りたい → プラグイン化

C. 個人の工夫を“共有可能な形”に寄せる

チームで回すなら、最終的に「配れる形（プラグイン、運用ルール、テンプレ）」へ寄せる。

D. 勉強会だけでは完結しないこと

今日の内容はスタート地点で、実運用ではチームごとに整備が必要な領域が残る。

  • rules/ の整備ルール
  • Cursor向けのコンテキストとどう共存させるか
  • SDDで進める場合の、採用するライブラリ
    等⋯
    これらがプロダクトチーム内で統一できていないと、個人の工夫が組織全体に広がりにくい。
    ここは各チーム内でオーナーシップを持って、チーム内で話し合って決め、運用に乗せていくことが大切。
    困ったことがあれば気軽に相談を！

チートシート

よく使うコマンド

コマンド 説明
/clear 会話履歴をクリア
/compact 履歴を要約して圧縮
/plan Planモードに切り替え
/rewind 過去会話に戻って継続
/tasks バックグラウンドタスク一覧
/usage Rate Limit確認

ショートカット

キー 説明
Shift+Tab Planモード切り替え
Ctrl+B バックグラウンドで実行
Ctrl+C 実行を中断
Esc 入力をキャンセル
Tab 許可プロンプトで追加指示を入力
Ctrl+G 外部エディタで長文入力

お疲れ様でした!

カンリーテックブログ
カンリーテックブログPublication

株式会社カンリーは「店舗経営を支える、世界的なインフラを創る」をミッションに、店舗アカウントの一括管理・分析SaaS「カンリー店舗集客」の開発・提供、他複数のサービスを提供しております。 技術系以外のnoteはこちらから note.com/canly

Discussion