Claude Code 超完全ガイド | エンジニアから投資家まで、すべてのユーザーのための実践マニュアル

2026年1月31日 05:27

私がClaude Codeを使い始めて10ヶ月が経った。

最初は「AIにコードを書かせる」という単純な使い方だった。でも、使い込むうちに気づいたことがある。このツールには、表面からは見えない深いカスタマイズの世界が広がっている。Skills、Hooks、Subagents、MCP、Plugins。それぞれが独自の役割を持っていて、組み合わせると別次元の生産性と執行力が手に入る。

以下の記事では「まるで別の並行世界に住んでいるようだ」というAnthropic共同創業者 Jack Clarkの言葉を取り上げたが、まさにそんな感覚だ。

「2026年夏までに、フロンティアAIを使って仕事をしている人々は、使っていない人々とはまるで別の平行世界に住んでいるかのように感じるだろう」

Anthropic共同創業者 Jack Clark

そして2026年1月、Anthropicが公式ベストプラクティスを発表した。そこには、私が試行錯誤で学んだことの多くが体系的にまとめられていた。同時に、まだ知らなかった視点も多く含まれていたのが正直なところだ。

本稿は、その公式ベストプラクティスと私自身の10ヶ月間の実践知を統合した「Claude Code 超完全ガイド」になる。

前半の無料部分では、エンジニアから投資家まで、プログラマーから非技術者まで、Claude Codeを使うすべての人が、このツールの潜在能力を100%引き出せるようになることを目指した私の知見と2026年1月現在の最新機能解説を盛り込んだ完全ガイドになる。

後半のサブスクメンバー限定セッションでは、以下のような投資家向けのアプリケーションを誰でも10分でさくっと作るための具体的な指示の紹介、私が実際に使っている投資分析ワークフローの解説など、より実践的な内容に踏み込んでいる。

全30章、3万字を超える長大な記事となってしまったが、これを読んで実際に実践していただければ、あなたも Claude Code マスターになれるはずだ。本稿があなただけのClaude Codeの使い方を見つける助けになれば幸いだ。

Part 1: Claude Codeとは何か

Claude Codeは、Anthropicが提供する公式CLIツールだ。

CLIというのは、Command Line Interfaceの略で、黒い画面（ターミナル）に文字を打ち込んで操作するインターフェースのことを指す。

でも、本質はそこじゃない。

Claude Codeの本質は「エージェント型コーディング環境」にある。

従来のAIチャットボット（ChatGPTやClaude.ai）は、質問に答えて待つだけで、あなたが次の質問をするまで、何もしない。完全に受け身の存在だ。

Claude Codeは違う。

ファイルを読み、コマンドを実行し、変更を加え、問題を自律的に解決する。あなたが見守っている間も、離れている間も、Claudeは動き続けている。

自分でコードを書いてClaudeにレビューしてもらうのではない。何が欲しいかを伝えれば、Claudeがどう作るかを自分で考える。探索し、計画し、実装する。これがAnthropicの公式ドキュメントが描くClaude Codeの姿になる。

これが「エージェント」と呼ばれる所以だ。

ローカルで動くことの意味

Claude Codeはあなたのパソコンの中で動く。

ブラウザ版のClaude.aiは、サーバーに質問を送り、回答を受け取るだけ。あなたのパソコンの中身には一切触れない。

Claude Codeは違う。

ファイルを読める。フォルダを整理できる。ブラウザを操作できる。プログラムを実行できる。Excelファイルを作れる。PowerPointも作れる。

要するに、あなたがキーボードとマウスでできること全てを、AIが代わりにやってくれるわけだ。

これは「コーディングツール」というより「超知的なローカルアシスタント」と呼ぶべきものだろう。

私はいつもこう言っている。

「Claude Codeという名前を忘れろ。Claude Agentだと思え」

と。

ツールコールの仕組み

Claude Codeには、以下のようなツールが組み込まれている。

Read: ファイルを読む
Write: ファイルを書く
Edit: ファイルを編集する
Bash: コマンドを実行する
Glob: ファイルパターンで検索する
Grep: ファイル内容を検索する
WebSearch: ウェブ検索をする
WebFetch: ウェブページの内容を取得する
Task: サブエージェントを起動する

AIはこれらのツールを自律的に使い分けながら、あなたの指示を実行していく。

「このバグを直して」と言えば、Claudeはまずファイルを読み（Read）、問題の箇所を特定し（Grep）、修正を加え（Edit）、テストを実行し（Bash）、結果を確認する。

この一連の流れを、人間が介入しなくても自律的にやってくれる。

Part 2: なぜコンテキストウィンドウが最重要か

Anthropicの公式ベストプラクティスは、こう断言している。

「ほとんどのベストプラクティスは、たった一つの制約に基づいている。Claudeのコンテキストウィンドウは急速に埋まり、埋まるほど性能が劣化する。」

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

AIに渡す入力を「コンテキスト」と呼ぶ。テキスト、画像、ファイルの内容。すべてがコンテキストになる。

「コンテキストウィンドウ」は、AIが一度に処理できるコンテキストの上限のこと。Claude Opus 4.5の場合、200,000トークン。約10万文字に相当する。

一見、十分に見える。でも、ここに落とし穴がある。

AIとの会話が長くなると、過去のやり取りがコンテキストに蓄積されていく。質問、回答、ファイルの内容、ツールの実行結果。すべてがトークンを消費する。

そして、コンテキストが埋まるほど、AIの「注意」が散漫になっていく。最近の指示よりも、過去の情報に引っ張られるようになる。

これを「Context Rot（コンテキスト腐敗）」と呼ぶ。

200kが70kになる現実

さらに厄介なのは、MCPやプラグインを多数有効にすると、各ツールの説明だけで大量のトークンを消費することだ。

200kのウィンドウが実質70k程度まで縮小することも珍しくない。

推奨される設定の目安はこうなっている。

設定済みMCP: 20〜30個
有効化MCP: 10個以下
アクティブツール: 80個以下

コンテキストウィンドウの管理は、Claude Codeを使いこなす上で最も重要なスキルになる。

本稿のPart 5「コンテキストエンジニアリング」で、この問題への対処法を詳しく解説する。

Part 3: エージェントという概念

「エージェント」とは何か。

Anthropicの定義を引用しよう。

「エージェントとは、LLMが自らのプロセスとツールの使用を動的に指示し、タスクの達成方法を制御するシステムである」

ポイントは「動的に」という部分だ。

あらかじめ決められた手順を実行するのではない。状況を判断し、次に何をすべきかを自分で決めるということになる。

ファイルを読んで、足りない情報があればウェブ検索をし、コードを書き、テストを実行し、エラーがあれば修正する。

この一連の流れを、AIが自律的に行うわけだ。

エージェント vs チャットボット

両者の違いを整理しておこう。

チャットボット

動作モデル: 質問→回答の往復
ツール使用: 限定的
状態管理: なし
作業の継続性: 単発
人間の介入: 毎ターン必要

エージェント

動作モデル: 目標→自律的行動
ツール使用: 動的・自律的
状態管理: あり
作業の継続性: 複数ステップ
人間の介入: 必要に応じて

Claude Codeは、チャットボットの延長線上にあるのではない。コーディングに必要となるあらゆるプロセスを処理する目的で設計された、根本的に異なるパラダイムだ。

自律性と制御のバランス

エージェントは自律的に動く。便利だけれど、リスクもある。

意図しない変更を加えるかもしれない。重要なファイルを削除するかもしれない。間違った方向に突き進むかもしれない。

Claude Codeは、このリスクを軽減するための仕組みを備えている。

権限管理: 危険な操作は事前に許可を求める
サンドボックス: OS レベルでファイルシステムとネットワークを制限
チェックポイント: 各操作前に状態を保存し、ロールバック可能

Anthropicはこう警告している。「任意のコマンドを実行させることは、データ損失、システム破損、プロンプトインジェクションによるデータ流出のリスクがある。」

だからこそ、権限管理とサンドボックスが重要になってくる。

Part 4: インストールと初期設定

サブスクリプション

Claude Codeを使うには、Anthropicのサブスクリプションが必要になる。

Proプラン: 月額20ドル

Claude Code含め、軽量安価なSonnet系モデルにアクセスできる。5時間ごとに約45メッセージ。軽い利用なら十分だろう。

Maxプラン: 月額100〜200ドル

高性能・高価なOpus系モデルを含む全モデルにアクセス可能。5時間ごとに225〜900メッセージ程度。本格的な開発に使うならこちらになる。

重要なのは、これらが定額制だということ。

従量課金ではない。「深く考えさせたいが、コストが心配」という不安がなくなる。API料金を気にして質問を控える必要もない。

月額20ドル。年間240ドル。

一つの誤った投資判断による損失を考えれば、安い保険だろう。

インストール方法

方法1: Desktop App（非開発者向け）

2025年11月から、Claude Desktopアプリ内でClaude Codeが使えるようになった。

ダウンロード: https://claude.com/ja-jp/download

Claude Desktopをダウンロード（Mac/Windows/Linux対応）
月額20ドルのサブスクリプションに加入
アプリ内で「Claude Code」タブを選択
フォルダへのアクセス権を与える
使い始める

方法2: ターミナル版（開発者向け）

ターミナルを開いて、以下のコマンドを実行する。

Mac:

curl -fsSL https://claude.ai/install.sh | bash

Windows（PowerShell）:

irm https://claude.ai/install.ps1 | iex

Windows（CMD）:

curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

インストール後、ターミナルで以下を実行：

claude

これだけで起動する。

ターミナルやIDEは好きなものを選んでいい。私のおすすめはGhosttyだ。軽量かつカスタム性が高くていい。

IDEであれば、VS CodeかZedだ。拡張機能としてインストールもできる。

方法3: Web版

2025年10月、Claude Code Web版がリリースされた。

https://claude.ai/code

claude.aiにログインし、GitHubリポジトリを接続するだけでいい。ターミナルの知識は不要。GitHubとの連携は必要だが、外出先でスマホからもアクセスでき非常に便利だ。

初期設定

適当なフォルダを作って起動。起動したら、まずはフォルダに移動して /init コマンドを実行してみよう。プロジェクト構造に基づいたCLAUDE.mdファイルが自動生成される。これがClaude Codeとの最初の対話になる。

Part 5: 基本操作とショートカット

キーボードショートカット

覚えておくべきショートカットは限られている。

Enter: メッセージ送信
Shift+Enter: 複数行入力
Tab: 思考表示のトグル
Esc: 現在の操作を中断
Esc Esc: コードの復元（rewind）
Ctrl+U: 行全体を削除
Shift+Tab: Planモードと通常モードの切り替え

特に重要なのは Esc だろう。Claudeが間違った方向に進んでいると気づいたら、すぐに止められる。コンテキストは保持されるので、方向転換を指示すればいい。

特殊文字プレフィックス

入力の先頭に特定の文字を置くと、特別な動作をする。

/: スラッシュコマンドの開始
@: ファイル参照
!: Bashコマンドの実行

例えば、@src/index.ts と入力すると、そのファイルをコンテキストに含めてClaudeに渡せる。

!npm run build と入力すると、Claudeを経由せずに直接Bashコマンドを実行できる。

基本的なスラッシュコマンド

頻繁に使うコマンドをリストアップしておこう。

/help: ヘルプを表示
/clear: 会話履歴をクリア
/compact: コンテキストを圧縮
/context: コンテキスト使用量を表示
/rewind: 以前の状態に戻る
/checkpoints: チェックポイント一覧
/permissions: 権限設定
/sandbox: サンドボックス設定
/statusline: ステータスライン設定
/fork: 会話を分岐
/rename: セッション名を変更

セッションの管理

Claude Codeのセッションは、ローカルに保存される。

# 直前のセッションを再開
claude --continue

# 過去のセッション一覧から選択
claude --resume

/rename でセッションに名前をつけておくと、後から見つけやすくなる。

/rename oauth-migration
/rename debugging-memory-leak

全スラッシュコマンドの一覧は公式ドキュメントを参照して欲しい。

Part 6: 検証の仕組みを与える

Anthropicの公式ベストプラクティスで、最も強調されているのがこれだ。

「テスト、スクリーンショット、期待される出力を含めて、Claudeが自己検証できるようにせよ。これが最もレバレッジの高い一手だ。」

なぜ検証が重要か

Claude Codeは自律的に動く。でも、自律的に動くからこそ、間違った方向に突き進む可能性がある。

明確な検証基準がなければ、「見た目は正しいが実際には動かない」コードを生成することがある。あなたが唯一のフィードバックループになり、すべてのミスにあなたの注意が必要になってしまう。

検証基準があれば、Claudeは自分でミスを発見し、修正できるようになる。

実践的な検証戦略

1. テストを書かせる

validateEmail関数を書いて。
テストケース:
- user@example.com は true
- invalid は false
- user@.com は false
実装後、テストを実行して。

2. スクリーンショットを比較させる

Claude in Chrome拡張機能を使えば、UIの検証も可能になる。

[スクリーンショットを貼り付け]
このデザインを実装して。
完成したらスクリーンショットを撮って、元のデザインと比較して。
差異をリストアップして修正して。

3. 根本原因を特定させる

ビルドが以下のエラーで失敗する: [エラーを貼り付け]
修正して、ビルドが成功することを確認して。
エラーを抑制するのではなく、根本原因に対処して。

検証の種類

使える検証手段はたくさんある。

単体テスト: Jest、Vitest、pytest
型チェック: TypeScript tsc --noEmit
リンター: ESLint、Prettier
E2Eテスト: Playwright、Cypress
ビルド: npm run build
視覚的比較: スクリーンショット

検証は「岩盤」であるべきもの。曖昧さがなく、合格・不合格が明確に判定できるものを用意することが大切になる。

Part 7: CLAUDE.md | プロジェクトの記憶

Claude Codeには「CLAUDE.md」という特別なファイルがある。

プロジェクトのルートディレクトリに置くと、AIが自動的に読み込んでくれる。プロジェクト固有のルール、禁止事項、作業手順を記憶させておける仕組みだ。

/init を実行すると、プロジェクト構造に基づいたスターターCLAUDE.mdが生成される。それを時間をかけて改良していく。これがAnthropicの推奨するスタート方法になる。

CLAUDE.mdに何を書くべきか

重要なのは、Claudeがコードを読むだけでは分からない情報を書くこと。

含めるべき内容

Bashコマンド: npm run lint、pytestなどの実行方法
コードスタイル: デフォルトと異なるルール
テスト指示: 優先するテストランナー、避けるパターン
リポジトリ慣習: ブランチ命名、PRコンベンション
アーキテクチャ決定: プロジェクト固有の設計選択
開発環境の癖: 必要な環境変数、特殊な設定
非自明な挙動: 知っておくべきゴッチャ

含めるべきでない内容

Claudeがコードを読めば分かること
標準的な言語規約（Claudeは既に知っている）
詳細なAPIドキュメント（リンクを貼るだけでいい）
頻繁に変わる情報
ファイル別の説明（コード自体が説明になるべき）
「クリーンなコードを書け」的な自明な指示

実践的なCLAUDE.md例

# CLAUDE.md

## コードスタイル
- ES modules (import/export) を使う。CommonJS (require) は使わない
- 可能な限り import を分割する (e.g. import { foo } from 'bar')

## ワークフロー
- コード変更が終わったら必ず型チェックを実行
- テストスイート全体ではなく、単一テストの実行を優先（パフォーマンスのため）

## 禁止事項
- モック・ダミー実装は禁止。必要なら許可を得ること
- 指示にない機能追加は禁止
- console.log を本番コードに残さない

## 注意点
- src/legacy/ 配下は触らない（リファクタリング対象外）
- 環境変数 DATABASE_URL が必要

CLAUDE.mdが長すぎると逆効果

Anthropicはこう警告している。

「すべてを詰め込みたくなるが、簡潔に保て。各行について『これを削除したらClaudeがミスをするか？』と問え。そうでなければ削除せよ。肥大化したCLAUDE.mdは、本当に重要な指示をClaudeに無視させる原因になる。」

つまり、書きすぎると逆効果ということだ。詰め込みたい気持ちはわかるけれど、ここはぐっと抑えたほうがいい。

CLAUDE.mdの配置場所

CLAUDE.mdは複数の場所に配置できる。

~/.claude/CLAUDE.md: 全セッションに適用
./CLAUDE.md: プロジェクトルート（gitにコミット）
./CLAUDE.local.md: プロジェクトルート（.gitignore推奨）
親ディレクトリ: モノレポで有用
子ディレクトリ: 必要に応じてオンデマンド読み込み

@構文でファイルを参照

CLAUDE.md内で他のファイルを参照できる。

プロジェクト概要は @README.md を参照。
利用可能な npm コマンドは @package.json を参照。

# 追加の指示
- Git ワークフロー: @docs/git-instructions.md
- 個人設定: @~/.claude/my-project-instructions.md

CLAUDE.md を含む各種指示書の最新の使い分け、記載方法については以下のnote記事でさらに詳しく書いた。4万字を超える分量となっているが、詳しく知りたい方は参考にしていただきたい。

Part 8: Skills | ワークフローの定義

Skillsとは何か

Skillsは、端的に言えば、特定のワークフローや作業手順を定義するマークダウンファイルとリソース（スクリプトなど）をセットにしたものになる。

プロジェクト、チーム、ドメインに特化した知識でClaudeの能力を拡張する仕組みになっている。Claudeはスキルを読み、タスクに応じて自律的に適用するかどうかを判断する。

重要なのは「自律的に判断する」という点だ。

スラッシュコマンドのように明示的に呼び出す必要はない。Claudeが「このタスクにはこのスキルが必要だ」と判断したら、自動的に読み込んでくれる。

Skillsの配置場所

# ユーザーレベル（全プロジェクト共通）
~/.claude/skills/

# プロジェクトレベル（特定プロジェクトのみ）
<project-root>/.claude/skills/

Progressive Disclosure

Skillsは「Progressive Disclosure（漸進的開示）」という設計原則に基づいている。

Claude Codeは起動時に、登録されているすべてのスキルのメタデータ（nameとdescription）だけを読み込む。スキルの詳細な指示（本文）は、実際にそのスキルが必要になったときに初めて読み込まれる仕組みになっている。

なぜこれが重要なのか。

コンテキストウィンドウには限りがあるからだ。もし、すべてのスキルの詳細を最初から読み込んでいたら、コンテキストの大部分を消費してしまう。

軽量なメタデータだけを常駐させ、必要なときに必要な情報だけを展開する。映画「マトリックス」でネオがカンフーをダウンロードするのに近いイメージだ。

Skillsの作成方法

シンプルなスキルは1つのマークダウンファイルで定義できる。

# ~/.claude/skills/coding-standards.md

---
name: coding-standards
description: プロジェクトのコーディング標準
---

# コーディング標準

## 基本原則
- イミュータビリティを優先する
- 副作用を最小限に抑える
- 関数は単一責任とする

## ファイル構成
- 1ファイル300行以下を目安とする
- 関連する機能は同じディレクトリに配置する

## 命名規則
- 変数名: camelCase
- 定数: UPPER_SNAKE_CASE
- クラス: PascalCase
- ファイル名: kebab-case

複雑なスキルは、ディレクトリ構造で管理することもできる。

~/.claude/skills/
├── tdd-workflow/
│   ├── SKILL.md          # スキルのメイン定義
│   ├── examples/          # 使用例
│   │   ├── unit-test.md
│   │   └── integration-test.md
│   └── templates/         # テンプレート
│       └── test-file.md
├── security-review/
│   ├── SKILL.md
│   └── checklist.md
└── refactor-clean.md      # 単一ファイルスキル

実用的なスキル例: TDDワークフロー

# ~/.claude/skills/tdd-workflow/SKILL.md

---
name: tdd-workflow
description: テスト駆動開発のワークフローをガイド
---

# TDD（テスト駆動開発）ワークフロー

## 基本サイクル

1. **Red**: 失敗するテストを書く
2. **Green**: テストを通す最小限のコードを書く
3. **Refactor**: コードを改善する（テストは通る状態を維持）

## テスト作成の順序

1. 正常系のテストを先に書く
2. 境界値のテストを追加する
3. 異常系・エラーハンドリングのテストを書く

## テストの命名規則
describe('対象の機能', () => { it('should 期待される動作 when 条件', () => { // Arrange（準備） // Act（実行） // Assert（検証） }); });

## 禁止事項

- テストを書く前に実装コードを書かない
- 一度に複数のテストを追加しない
- テストが通る前にリファクタリングしない

Skillsの呼び出し方

スキルは複数の方法で呼び出せる。

自動適用（Claudeが判断）:

「このコードをレビューして」
→ coding-standardsスキルが自動で適用される

明示的に参照:

「coding-standardsスキルに従ってこのコードをレビューして」

複数のスキルをチェーン:

「security-reviewとcoding-standardsを適用してこのPRをレビューして」

スラッシュコマンドとして呼び出す:

/fix-github-issue 1234
→ fix-github-issueスキルが起動する

スラッシュコマンド型のスキル

以前、Claude Codeには「Commands（コマンド）」という別機能があった。.claude/commands/ にマークダウンファイルを置くと、スラッシュコマンドとして呼び出せるという仕組みだ。

でも現在は、コマンドはスキルに統合されている。.claude/commands/ に置いたファイルは引き続き動作するが、公式にはSkillsに一本化された。スキルの name フィールドがそのままスラッシュコマンド名になる。

スラッシュコマンドとして明示的に呼び出したいスキルを作るには、frontmatterで disable-model-invocation: true を設定する。これにより、Claudeが勝手に自動適用することはなくなり、/skill-name で呼び出したときだけ実行されるようになる。

GitHub Issue修正スキル:

# ~/.claude/skills/fix-github-issue/SKILL.md

---
name: fix-github-issue
description: GitHub Issueを分析して修正する
disable-model-invocation: true
---

GitHub Issue: $ARGUMENTS を分析して修正する。

## 手順

1. `gh issue view` でIssueの詳細を取得
2. 問題を理解する
3. 関連ファイルをコードベースから検索
4. 修正を実装する
5. テストを書いて実行する
6. lint・型チェックをパスさせる
7. コミットメッセージを作成
8. プッシュしてPRを作成

/fix-github-issue 1234 と実行すれば、Issue #1234の修正ワークフローが起動する。

テストカバレッジ確認スキル:

# ~/.claude/skills/test-coverage/SKILL.md

---
name: test-coverage
description: テストカバレッジを確認し、不足箇所を特定
disable-model-invocation: true
---

# テストカバレッジ分析

## 手順

1. カバレッジレポートを生成

npm run test:coverage

2. カバレッジが低いファイルを特定

3. 不足しているテストケースを提案

4. 提案内容をユーザーに確認

## 目標カバレッジ

- ステートメント: 80%以上
- ブランチ: 75%以上
- 関数: 80%以上

Skillsの使い分け

スキルには大きく分けて2つのタイプがある。

自動適用型（Claudeが判断して読み込む）

用途: ドメイン知識、コーディング規約、API設計パターン
設定: デフォルト（disable-model-invocation なし）
例: coding-standards、security-review

明示呼び出し型（ユーザーが /skill-name で呼ぶ）

用途: 繰り返しのワークフロー、CI実行、PR作成、リファクタ
設定: disable-model-invocation: true
例: fix-github-issue、test-coverage、deploy

スキルの詳細について、こちらに本note記事の続編として書きました。参照ください。

Part 9: Hooks | 自動化トリガー

Hooksとは何か

Hooksは、特定のイベントが発生したときに自動的に実行されるスクリプトやコマンドのことだ。

Hooksを使えば、Claude Codeの振る舞いを決定論的に制御できる。Claudeがアクションを覚えていることを「期待する」のではなく、毎回確実に実行されることを「保証する」。この違いはかなり大きい。

Skillsが「このワークフローではこうする」というコンテキスト依存のアドバイスだとすれば、Hooksは「例外なく必ずこうする」という強制力を持つ存在だ。

Hookのタイプ

利用可能なHookは6種類ある。

PreToolUse: ツール実行前。バリデーション、リマインダー、ブロックに使う
PostToolUse: ツール実行後。フォーマッティング、型チェックに使う
UserPromptSubmit: ユーザーがメッセージ送信時。入力のプリプロセスに使う
Stop: Claudeが応答完了時。最終チェック、ログ記録に使う
PreCompact: コンテキスト圧縮前。重要情報の保存に使う
Notification: 権限リクエスト時。カスタム通知に使う

Hooksの設定場所

Hooksは~/.claude.jsonまたは/.claude.jsonのhooksセクションで定義する。

{
  "hooks": {
    "PreToolUse": [...],
    "PostToolUse": [...],
    "Stop": [...]
  }
}

実用的なHook例

1. TypeScriptファイル編集後に自動フォーマット

{
  "PostToolUse": [
    {
      "matcher": "tool == \"Edit\" && tool_input.file_path matches \"\\.(ts|tsx|js|jsx)$\"",
      "hooks": [
        {
          "type": "command",
          "command": "npx prettier --write \"$TOOL_INPUT_FILE_PATH\" 2>/dev/null || true"
        }
      ]
    }
  ]
}

2. 不要な.mdファイル作成をブロック

{
  "PreToolUse": [
    {
      "matcher": "tool == \"Write\" && tool_input.file_path matches \"\\.md$\" && !(tool_input.file_path matches \"(README|CLAUDE|CHANGELOG)\")",
      "hooks": [
        {
          "type": "command",
          "command": "echo '[Hook] READMEとCLAUDE.md以外の.mdファイル作成は禁止されています' >&2; exit 1"
        }
      ]
    }
  ]
}

3. TypeScriptファイル編集後に型チェック

{
  "PostToolUse": [
    {
      "matcher": "tool == \"Edit\" && tool_input.file_path matches \"\\.(ts|tsx)$\"",
      "hooks": [
        {
          "type": "command",
          "command": "npx tsc --noEmit --skipLibCheck 2>&1 | head -20 || true"
        }
      ]
    }
  ]
}

4. 長時間コマンド実行時のtmuxリマインダー

{
  "PreToolUse": [
    {
      "matcher": "tool == \"Bash\" && tool_input.command matches \"(npm|pnpm|yarn|cargo|pytest)\"",
      "hooks": [
        {
          "type": "command",
          "command": "if [ -z \"$TMUX\" ]; then echo '[Hook] 長時間コマンドです。tmuxの使用を検討してください' >&2; fi"
        }
      ]
    }
  ]
}

5. git push前の差分確認

{
  "PreToolUse": [
    {
      "matcher": "tool == \"Bash\" && tool_input.command matches \"git push\"",
      "hooks": [
        {
          "type": "command",
          "command": "echo '[Hook] プッシュ前に差分を確認:' && git diff --stat HEAD~1 HEAD"
        }
      ]
    }
  ]
}

Hooks vs CLAUDE.md

使い分けの原則はシンプルだ。

例外なく毎回必ず実行すべきこと（フォーマット、lint、機密ファイルへの書き込みブロック）にはHookを使う。判断が必要なガイダンス（コードスタイルの好み、アーキテクチャパターン）にはCLAUDE.mdを使う。

Hooksは決定論的指示。CLAUDE.mdはアドバイスと考えれば分かりやすい。

hookifyスキルによる簡易作成

Hooksを手書きするのが面倒な場合、hookifyスキルを使えば会話形式でHooksを作成できる。

# hookifyをインストール後
/hookify

「TypeScriptファイルを編集したら自動的にprettierを実行したい」と伝えれば、適切なJSON設定を生成してくれるという具合だ。

Part 10: Subagents | タスク委譲の仕組み

Subagentsとは何か

Subagentsは、メインのClaude（オーケストレーター）が特定のタスクを委譲できる専門エージェントのことだ。

スラッシュコマンドが「明示的に呼び出すプロンプトテンプレート」なのに対して、サブエージェントは独自のコンテキストと許可されたツールセットで動作する。スクリプト化されたワークフローではなく、委譲されたアシスタント。この違いが決定的に重要になってくる。

Subagentsの利点

なぜサブエージェントが重要なのか。4つの理由がある。

コンテキストの分離: 複雑なタスクを別プロセスで処理し、メインのコンテキストを節約
専門化: 特定の作業に最適化されたルールとツールを設定
並列実行: バックグラウンドでタスクを実行可能
サンドボックス化: ツールの権限を制限して安全に実行

Subagentsの配置場所

# ユーザーレベル
~/.claude/agents/

# プロジェクトレベル
<project-root>/.claude/agents/

Subagentsの作成方法

# ~/.claude/agents/security-reviewer.md

---
name: security-reviewer
description: コードのセキュリティ脆弱性をレビューする
tools: Read, Grep, Glob, Bash
model: opus
---

あなたはシニアセキュリティエンジニアです。以下の観点でコードをレビューしてください:
- インジェクション脆弱性（SQL、XSS、コマンドインジェクション）
- 認証・認可の欠陥
- コード内のシークレットや認証情報
- 安全でないデータ処理

具体的な行番号を参照し、修正案を提示してください。

実用的なSubagent例

1. プランナーエージェント

# ~/.claude/agents/planner.md

---
name: planner
description: 機能実装の計画を立案する
tools: Read, Grep, Glob, WebSearch
---

# プランナーエージェント

## 役割

新機能の実装計画を立案する。コードベースを分析し、最適な実装アプローチを提案。

## 計画立案の手順

1. **要件の明確化**: 何を実現するのか、制約条件は何か
2. **既存コードの分析**: 関連する既存機能、参考になるパターン
3. **実装ステップの分解**: タスクを細分化、依存関係を特定
4. **リスク評価**: 技術的リスク、破壊的変更の有無

## 出力形式

実装計画: [機能名]

概要

...

影響範囲

ファイルA: 変更内容

ファイルB: 新規作成

実装ステップ

[ ] ステップ1

[ ] ステップ2

リスクと対策

リスク1: 対策

2. コードレビュアー

# ~/.claude/agents/code-reviewer.md

---
name: code-reviewer
description: コードの品質とセキュリティをレビューする
tools: Read, Grep, Glob
---

# コードレビュアーエージェント

## レビュー観点

### 1. コード品質
- 命名の適切さ
- 関数の単一責任
- 重複コードの有無
- エラーハンドリングの適切さ

### 2. セキュリティ
- ハードコードされた秘密情報
- 入力バリデーション
- SQLインジェクション脆弱性

### 3. パフォーマンス
- 不要な再計算
- メモリリーク
- N+1クエリ

## 出力形式

問題点を [重要度: 高/中/低] でマーク
場所: ファイル:行番号
修正提案: ...

Subagentsの使い方

# プロンプトで指定
「security-reviewerエージェントでこのPRをレビューして」

# バックグラウンド実行
「security-reviewerエージェントをバックグラウンドで起動して、完了したら報告して」

# オーケストレーターからの自動委譲
「この機能を実装して」
→ plannerで計画 → 実装 → code-reviewerでレビュー

サブエージェントのコンテキスト問題と解決策

サブエージェントは、コンテキストを節約するために存在する。でも、重要な注意点がある。

オーケストレーター（メインClaude）は意味的コンテキストを持っている。一方で、サブエージェントは文字通りのクエリしか知らない。リクエストの目的や理由を知らないのだ。

結果として、サブエージェントの要約は、オーケストレーターが必要とする詳細を含んでいないことが多い。

解決策: 反復的取得パターン

オーケストレーターは:

サブエージェントの返答を評価する
受理する前にフォローアップ質問をする
サブエージェントがソースに戻り、回答を取得して返す
十分になるまでループ（最大3サイクルで無限ループ防止）

重要: クエリだけでなく目的コンテキストも渡す

サブエージェントを起動するとき、具体的なクエリと、より広い目的の両方を含めるのがコツになる。

Part 11: Tasks | セッションを超えるタスク管理

Todosの限界とTasksの登場

Claude Codeには以前から「Todos」というタスク管理機能があった。複雑な作業を分解し、進捗を追跡する仕組みだ。でも、致命的な弱点があった。

セッションが終わると、消える。

コンテキストウィンドウがいっぱいになって新しいセッションを始めると、それまでのTodoリストは跡形もなく消えていた。大きなプロジェクトでは、「どこまでやったか」を毎回伝え直す必要があったわけだ。

Tasks機能は、この問題を根本から解決する。Todosの進化系であり、ファイルシステムに永続化されるタスクリストになる。

Tasksの仕組み

Tasksの最大の特徴は、セッションを超えて生き残ること。

仕組みはシンプルで、タスクの状態が ~/.claude/tasks/ 配下にJSONファイルとして保存される。各タスクは個別のJSONファイルで管理され、ステータス（pending、in_progress、completed）が記録されるようになっている。

{
  "id": "タスク番号",
  "subject": "タスク名",
  "description": "タスクの概要",
  "activeForm": "進行状況の要約",
  "status": "in_progress",
  "blocks": [],
  "blockedBy": []
}

blocks と blockedBy フィールドに注目してほしい。タスク間の依存関係を定義できるようになっている。「タスクAが完了するまでタスクBには着手しない」という制御が可能になっている。

Tasksの基本操作

Tasksはユーザーが手動で作成するものではない。Claude Codeが作業フローに応じて自動的にタスクリストを生成してくれる。

タスクの表示: Ctrl+T でタスクリストの表示/非表示を切り替え
タスクの確認: /tasks コマンドで進行中のタスクを一覧表示
全タスクの表示: 「すべてのタスクを見せて」とClaudeに直接聞く
タスクのクリア: 「すべてのタスクをクリアして」とClaudeに伝える
表示上限: 一度に表示されるのは最大10件

重要なのは、タスクがすべて完了すると、JSONファイルは自動的に削除される点だ。完了済みのタスクリストを後から参照することはできない。長期的な記録が必要なら、CLAUDE.mdやドキュメントファイルに残す運用が必要になってくる。

セッション間のタスク共有

Tasksの真価は、複数セッション間での共有にある。

環境変数 CLAUDE_CODE_TASK_LIST_ID を設定することで、異なるClaude Codeセッションが同じタスクリストを参照・更新できるようになる。

設定方法1: 起動時に環境変数を指定

CLAUDE_CODE_TASK_LIST_ID=my-project claude

設定方法2: settings.jsonに記述

{
  "env": {
    "CLAUDE_CODE_TASK_LIST_ID": "my-project"
  }
}

この設定により、~/.claude/tasks/my-project/ 配下にタスクファイルが格納される。別のターミナルで同じIDを指定してClaude Codeを起動すれば、進行中のタスクがそのまま見える。

Tasksとサブエージェントの連携

Tasksの設計思想が最も光るのは、サブエージェントとの連携だろう。

同じ CLAUDE_CODE_TASK_LIST_ID を共有する複数のセッション（またはサブエージェント）が、それぞれ独立してタスクを取得し、更新し、完了させる。あるセッションがタスクAを進めている間に、別のセッションがタスクBを並行して処理していく。

この仕組みが実現するのは、ソフトウェア開発で言う「ワークスティーリング」に近いパターンだ。空いているワーカーが次のタスクを自動的に取得する。重複作業を避けながら、並列度を最大化できるわけだ。

実際のユースケースを考えてみよう。

# ターミナル1: メインのオーケストレーター
CLAUDE_CODE_TASK_LIST_ID=feature-auth claude

# ターミナル2: フロントエンド担当のサブエージェント
CLAUDE_CODE_TASK_LIST_ID=feature-auth claude

# ターミナル3: バックエンド担当のサブエージェント
CLAUDE_CODE_TASK_LIST_ID=feature-auth claude

3つのセッションが同じタスクリストを見ている。メインのオーケストレーターがタスクを分解し、フロントエンドとバックエンドの担当がそれぞれ自分の得意な領域を処理するという流れだ。

Todosとの違いを整理する

私がTasksを「Todosの進化系」と呼ぶ理由を明確にしておこう。

永続性: Todosはセッション内のみ。Tasksはファイルシステムに永続化
共有: Todosはセッション内のみ。Tasksは環境変数で複数セッション間共有
依存関係: Todosは単純なリスト。Tasksは blocks / blockedBy で依存関係を定義可能
コンパクション耐性: Todosはコンテキスト圧縮で消失するリスクあり。Tasksは外部ファイルなので影響なし
自動管理: どちらもClaude Codeが自動的にステータスを更新する

一方で、Tasksにも制約がある。現時点ではタスクリストは最大10件まで。大規模プロジェクトでは、粒度の調整が必要になってくるだろう。

Part 12: MCP | 外部サービス連携

MCPとは何か

MCP（Model Context Protocol）は、Claudeを外部サービスと接続するためのプロトコルのことだ。

MCPサーバーを使えば、イシュートラッカーから機能を実装し、データベースをクエリし、モニタリングデータを分析し、Figmaからデザインを統合し、ワークフローを自動化できる。Claudeの世界が、ローカルファイルの外に広がるわけだ。

MCPの設定場所

mcpは .claude.json に設定する。プロジェクトごとに設定したい場合は.mcp.jsonファイルをプロジェクトルートに配置すればいい。

// ~/.claude.json
{
  "mcpServers": {
    "server-name": {
      "command": "...",
      "args": [...]
    }
  }
}

主要なMCPサーバー

1. GitHub MCP

{
  "github": {
    "command": "npx",
    "args": ["-y", "@modelcontextprotocol/server-github"]
  }
}

用途: Issue、PRの作成・管理、リポジトリ操作、コードレビュー自動化

2. Supabase MCP

{
  "supabase": {
    "command": "npx",
    "args": [
      "-y",
      "@supabase/mcp-server-supabase@latest",
      "--project-ref=YOUR_PROJECT_REF"
    ],
    "env": {
      "SUPABASE_ACCESS_TOKEN": "your-token"
    }
  }
}

用途: データベースの直接クエリ、テーブル構造の確認、RLSポリシーの管理

3. Memory MCP

{
  "memory": {
    "command": "npx",
    "args": ["-y", "@modelcontextprotocol/server-memory"]
  }
}

用途: セッション間での情報の永続化、学習した内容の記憶

4. Vercel MCP

{
  "vercel": {
    "type": "http",
    "url": "https://mcp.vercel.com"
  }
}

用途: デプロイメント管理、環境変数設定

5. Firecrawl MCP

{
  "firecrawl": {
    "command": "npx",
    "args": ["-y", "firecrawl-mcp"],
    "env": {
      "FIRECRAWL_API_KEY": "your-key"
    }
  }
}

用途: Webスクレイピング、ドキュメント取得

プロジェクト単位でのMCP無効化

すべてのMCPをグローバルに設定し、以下のようにプロジェクトごとに不要なものを無効化する運用ができる。.mcp.jsonの配置する方法とどちらが良いかは構成によって選択して欲しい。

// <project>/.claude.json
{
  "disabledMcpServers": [
    "supabase",         // このプロジェクトでは使わない
    "cloudflare-docs"   // このプロジェクトでは使わない
  ]
}

CLIツールとMCPの使い分け

私がよくやるのは、MCPではなくCLIツールを使わせることだ。外部サービスとやり取りするときは、gh、aws、gcloud、sentry-cliなどのCLIツールを使うようにスキルに書いておく。

GitHub MCPを使う代わりに、gh コマンドを使わせる方がコンテキスト効率が良いからだ。MCPは便利だけれど、各MCPのツール説明がコンテキストを消費する。

Part 13: Plugins | 拡張パッケージ

Pluginsとは何か

Pluginsは、Skills、Hooks、MCPなどをパッケージ化して簡単にインストールできるようにしたものだ。

コミュニティやAnthropicが作った事前構築済みの機能でClaude Codeを拡張する仕組みになっている。Skills、Hooks、MCPを自分で一つ一つ設定する代わりに、プラグインをインストールすればすぐに動く。

Pluginsのインストール方法

# マーケットプレイスを閲覧
/plugins

# プラグインをインストール
/plugin install typescript-lsp@claude-plugins-official

推奨プラグイン

1. LSPプラグイン（コードインテリジェンス）

エディタなしでも型チェック、定義へのジャンプ、補完が可能になる。

typescript-lsp@claude-plugins-official（TypeScript）
pyright-lsp@claude-plugins-official（Python）

2. hookify（Hook作成補助）

会話形式でHooksを作成できるという、ありがたいプラグイン。

hookify@claude-plugins-official

3. context7（ライブドキュメント）

最新のドキュメントをリアルタイムで参照できる。

context7@claude-plugins-official

プラグインの有効/無効

MCPと同様、プラグインもコンテキストウィンドウを消費する。使わないプラグインは無効化しておくのが重要だ。

/plugins  # プラグイン管理画面を開く

Part 14: Context Rotとは何か

Claude Codeを使いこなす上で最も重要な概念が「Context Engineering（コンテキストエンジニアリング）」になる。

コンテキストエンジニアリングとは、LLMの固有の制約に対してトークンの有用性を最適化し、一貫して望ましい結果を達成する技術のこと。言い換えれば、「限られたコンテキストウィンドウをいかに賢く使うか」という問いに対する体系的なアプローチだ。

Context Rot（コンテキスト腐敗）の症状

コンテキストが埋まるにつれて、以下の症状が現れてくる。

記憶の欠落: 最初に指示したことを忘れる
応答品質の低下: 以前より雑な回答になる
Lost in the Middle: 先頭と末尾の情報には注意が向くが、中間部分を忘れる
レイテンシの増加: 応答が遅くなる

なぜ起きるのか

AIのコンテキストウィンドウには物理的な限界がある。情報を詰め込めば詰め込むほど、モデルの「注意」は分散していく。

研究によれば、コンテキストが長くなると「U字型のアテンション分布」が発生するらしい。先頭と末尾の情報には注意が向くが、中間部分の情報は無視されやすくなる。

これがContext Rotの正体だ。

Part 15: 4つの基本戦略

Anthropicはコンテキストエンジニアリングに4つの基本戦略を提唱している。企業の決算分析を例にして説明する。

1. Write（書き込み）: 情報の構造化

コンテキストに入れる前に、情報を最適化する。米国企業の決算情報が全て入っている10-Kドキュメントを元に説明する。

悪い例: 10-Kをそのまま読み込む
- 100ページの生データがコンテキストを埋める
良い例: 構造化したデータを読み込む

## 10-K要約: NVDA

### 財務ハイライト（FY2025）
- 売上高: 1,308億ドル（前年比+114%）
- 営業利益: 812億ドル（営業利益率62%）
- データセンター比率: 87%

### リスク要因（上位3つ）
1. 中国輸出規制の影響
2. 単一顧客依存
3. 供給制約

元の100ページが、数百文字に圧縮される。情報密度は高く、必要な情報は保持されたままとなる。

2. Select（選択）: 関連情報の抽出

必要な情報だけを選択的に読み込む。

悪い例: 全体を読み込む
- "10-K_full.pdf" を読んで
良い例: 必要なセクションだけ
- "10-K_risk_factors.txt" を読んで

「リスク要因だけを分析したい」なら、10-K全体ではなく、Item 1Aのリスクファクターセクションだけを読み込めばいい。

3. Compress（圧縮）: 情報の凝縮

冗長な情報を圧縮する。

決算説明会のトランスクリプトには、挨拶や繰り返しが多い。これらを削除し、実質的な情報だけを残す。

適切な圧縮により、同じ情報量で4-5倍のコンテンツを処理できるようになったという報告もある。

4. Isolate（分離）: サブエージェントの活用

複雑なタスクを、独立したサブタスクに分割する。

メインエージェント: 5銘柄の比較分析を指示
↓
サブエージェントA: NVDA分析 → 結果サマリー
サブエージェントB: AMD分析 → 結果サマリー
サブエージェントC: INTC分析 → 結果サマリー
サブエージェントD: AVGO分析 → 結果サマリー
サブエージェントE: QCOM分析 → 結果サマリー
↓
メインエージェント: 5つのサマリーを統合して比較表を作成

各サブエージェントはクリーンなコンテキストで動作する。そのため、Context Rotの影響を受けにくくなる。

Part 16: 戦略的コンパクト化

Claude Codeには自動コンパクト機能がある。コンテキストが上限に近づくと、過去の会話を要約して圧縮してくれる。

しかし、自動コンパクトには問題がある。タイミングが任意なのだ。タスクの途中で圧縮が発生すると、重要な文脈が失われることがある。

手動コンパクトのすすめ

自動コンパクトを無効化するには、設定で autoCompact: false を設定する。

論理的な区切りで手動コンパクト

/compact

特定の焦点を持ってコンパクト

/compact APIの変更点のみに注目

戦略的コンパクトのタイミング

いつコンパクトすべきか。4つのタイミングがある。

探索フェーズ終了後: 調査で得た大量のコンテキストを圧縮し、実装に集中
マイルストーン完了後: 次のタスクに移る前にコンテキストをリセット
エラー解決後: デバッグ中の試行錯誤を圧縮し、本筋に戻る
60%を超えたら: /context で確認し、必要なら新しいセッションを開始

/contextコマンドで使用量を可視化

/context

Context usage: 45% (90,000 / 200,000 tokens)
- System prompt: 5,000 tokens
- Conversation history: 65,000 tokens
- Tool results: 20,000 tokens

60%を超えていたら、新しいセッションを開始する頃合いだ。

Part 17: 探索→計画→実装→コミット

「調査と計画を実装から分離する」、この考え方は間違った問題を解決してしまうリスクを避けるために非常に重要となる。以前のnoteで書いた「計器」の話に通じるものだ。

Planモードの活用

Claude Codeには「Planモード」がある。

通常モードでは、AIは指示を受けると即座に実行に移る。Planモードでは、実行前に計画を立て、あなたの承認を求めてくる。

Shift+Tab でモードを切り替える。

推奨ワークフロー:

Phase 1: 探索（Planモード）

/src/auth を読んで、セッション管理とログインの仕組みを理解して。
シークレット用の環境変数の管理方法も確認して。

Phase 2: 計画（Planモード）

Google OAuthを追加したい。どのファイルを変更する必要がある？
セッションフローはどうなる？計画を立てて。

Phase 3: 実装（通常モード）

計画に基づいてOAuthフローを実装して。
コールバックハンドラーのテストを書いて、テストスイートを実行して、
失敗があれば修正して。

Phase 4: コミット（通常モード）

分かりやすいコミットメッセージでコミットして、PRを作成して。

Planモードが不要なケース

ただし、毎回計画する必要はない。スコープが明確で修正が小さいタスク（タイポ修正、ログ行追加、変数リネーム）は、直接やらせればいい。

Planモードを使うべきケース:

アプローチが不確実なとき
複数ファイルにまたがる変更
変更対象のコードに不慣れなとき

直接実行すべきケース:

diffを1文で説明できる
スコープが明確
修正が小さい

Part 18: 並列化戦略

基本原則: 最小限の並列化で最大の成果

目標は、最小限の並列化で最大限の成果を得ることだ。

常に5つのターミナルで5つのClaudeを走らせる。これは非推奨となる。

並列インスタンスを追加するのは、真の必要性と目的がある場合のみにすべきだ。

初心者は、単一インスタンスを使いこなすことから始めたほうがいい。

推奨パターン: 実装と調査の分離

メインチャットはコード変更に集中。フォークは以下の用途に使う。

コードベースに関する質問
外部ドキュメントのリサーチ
GitHubで関連OSSを探す
その他の調査タスク

/fork - 会話の分岐

別のClaude Codeインスタンスが起動する。元の会話のコンテキストを引き継ぐ。しかし独立して作業可能だ。

/fork

Git Worktrees - 並列コード変更

複数のClaudeインスタンスが同じコードベースを編集する場合、コンフリクトが発生しうる。

Git Worktreesで解決できる。

# 並列作業用のworktreeを作成
git worktree add ../project-feature-a feature-a
git worktree add ../project-feature-b feature-b

# 各worktreeで別々のClaudeを実行
cd ../project-feature-a && claude

メリットは明確だ。

インスタンス間でgitコンフリクトが発生しない
各インスタンスがクリーンなワーキングディレクトリを持つ
出力を簡単に比較できる

カスケードパターン

複数インスタンスを管理するときの整理法がある。

新しいタスクは右に新しいタブで開く
左から右へスイープ（古い順から新しい順）
同時に3-4タスク以上は持たない — それ以上は認知オーバーヘッドが生産性を上回ることになる

ヘッドレスモードとファンアウト

大規模な移行や分析では、ヘッドレスモードで並列実行できる。

for file in $(cat files.txt); do
  claude -p "Migrate $file from React to Vue. Return OK or FAIL." \
    --allowedTools "Edit,Bash(git commit:*)"
done

--allowedTools フラグで、Claude が使えるツールを制限する。無人実行時の安全策になる。

Part 19: 継続学習パターン

問題: 同じ失敗の繰り返し

「またこのエラーか」

「また同じ修正を指示するのか」

Claude Codeを使い込むと、この苛立ちを経験することがある。前のセッションで解決したはずの問題に、再び遭遇するのだ。

根本原因は、セッション間で知識が共有されないことにある。

解決策: 自己改善するスキルシステム

Claude Codeが何か非自明な発見をしたとき — デバッグテクニック、ワークアラウンド、プロジェクト固有のパターン — それを新しいSkillとして保存させるという方法がある。

知識抽出スキル /learn

# ~/.claude/skills/learn/SKILL.md

---
name: learn
description: 現在のセッションから知識を抽出してSkill化する
disable-model-invocation: true
---

# 知識抽出

## 手順

1. あなたがユーザーとの今回のセッションにおいて何を学んだかを調査して確認
2. Skill-Creatorスキルを使ってパターンを抽出し、Skillファイルをドラフト
3. スキル名はパターンの内容に基づいて決定する（例: `nextjs-cache-patterns`、`supabase-rls-guide`）
4. ユーザーに仕様の確認を取ってから `~/.claude/skills/<skill-name>/SKILL.md` に保存
5. 保存したSkillの概要を報告

/learn と打てば、セッション後に手動で知識を抽出してスキル化することができる。

/learn

Part 20: トークン最適化

なぜトークン最適化が重要か

Claude Codeの料金はAPI利用の場合は従量課金だ。
Opus 4.5の場合:

入力: $5 / 100万トークン
出力: $25 / 100万トークン

サブスクリプション契約の場合、各モデルのトークン料金比率に応じて1日の利用枠が削られていく。コストの大部分は入力トークンになる。ファイルを読むたびに、過去の会話を参照するたびに、入力トークンが消費されていく。そのため、タスクに応じて最適なモデルを使う必要がある。

（大富豪であれば、Opus一択だが…）

主戦略: サブエージェントアーキテクチャ

タスクに応じて最適なモデルを選択し、無駄を削減する。

---
name: quick-search
description: 高速ファイル検索
tools: Glob, Grep
model: haiku  # 安くて速い
---

モデル選択の指針:

Haiku: 反復タスク、明確な指示、ワーカー向け。安くて速い
Sonnet: 一般的なコーディング（90%のケース）。バランスが良い
Opus: 複数ファイルにまたがる設計、セキュリティ、アーキテクチャ向け。高品質

Opusにアップグレードするタイミング:

最初の試行が失敗した
5ファイル以上に変更が及ぶ
アーキテクチャの意思決定
セキュリティクリティカルなコード

Haikuにダウングレードするタイミング:

反復的なタスク
指示が非常に明確
マルチエージェント構成の「ワーカー」

ツール固有の最適化

MCPのCLI代替

多くのMCPには、対応するCLIが存在する。GitHub MCP → ghコマンド。Supabase MCP → Supabase CLI。

これらをSkillやコマンドでラップすれば、MCPと同等の機能を、より少ないトークンで実現できることになる。

Part 21: 非技術者向け編 | コードを書かない使い方

私はこう断言する。Claude Codeは、非技術者にとって最も過小評価されているAIツールだと。

Claude Codeという名前を見た多くの人はこう思っているだろう。

「プログラミングができない自分には関係ない」

その気持ちはよく分かる。黒い画面（ターミナル）に白い文字が流れる。見るからに技術者向け。

でも、ちょっと待ってほしい。

Claude Codeの本質は「コーディング」じゃない。ローカルで動き、実行する力があること。これが全てになる。

Anthropic社内での使われ方

興味深い事実がある。

Anthropic社内では、経理部門がClaude Codeを使っている。

テキストファイルにデータ処理のワークフローを書いて、Claude Codeに渡す。すると全自動で実行される。

「このダッシュボードをクエリして、情報を取得して、クエリを実行して、Excelで出力して」

コードは一行も書かない。

これがコーディングツールだろうか。

私は違うと思う。これは「言葉で指示を出せる、超優秀なアシスタント」だ。

Part 22: 50の非コーディング活用例

Lenny Rachitskyという人物をご存知だろうか。元Airbnbのプロダクトマネージャーで、現在はテック業界で良く読まれているニュースレターのひとつ「Lenny's Newsletter」を運営している。彼が500人以上の読者からClaude Codeのユースケースを集めた記事がある。その中から、非開発者の使い方として印象的だったものをプロンプトと一緒に紹介してみよう。何かしら使えそうなアイデアが浮かぶはずだ。

ファイル整理と自動化

「税金用のインボイスを整理するのにClaude Codeを使っている。各ファイルを読んで、『YYYY-MM-DD ベンダー名 - Invoice - 商品名.pdf』にリネームして、適切なフォルダに移動する」

試してみるプロンプト:

このフォルダにあるPDFファイルを全部読んで、
請求書の日付とベンダー名を抽出して、
「YYYY-MM-DD_ベンダー名.pdf」の形式にリネームして

ドメイン名のブレインストーミング

「プロジェクトを説明すると、複数のTLDでクリエイティブな選択肢を提案してくれる。しかも実際に登録可能かどうかを確認してくれる」

試してみるプロンプト:

AIを使った家計簿アプリを作ろうとしている。
キャッチーなドメイン名を10個提案して、
それぞれ .com と .io で取得可能かどうか確認して

通常のAIに「ドメイン名を提案して」と聞いても、存在するかどうかは分からない。Claude Codeはローカルで動くから、実際にwhoisを叩いて確認できるのがポイント。

会議の分析

「全ての会議録音をダウンロードしてフォルダに入れて、Claude Codeに『自分が微妙に対立を避けた全ての場面を教えて』と頼んだ」

試してみるプロンプト:

このフォルダにある会議の文字起こしファイルを全部読んで、
私が対立を避けている場面を全てリストアップして、
それぞれ何を避けていたか分析して

プレゼン資料の作成

「スライド作成は全てClaude CodeでHTMLとして作り、PPTにインポートしている」

試してみるプロンプト:

この2枚のスライド画像を見て、同じデザインシステムで
新しいスライドを10枚作って。HTMLで出力して。
内容は以下の通り：
- タイトル: Q4業績報告
- 売上推移のグラフ
- 主要KPIの比較表

経費精算の自動化

「出張後、クレジットカードの取引履歴をダウンロードして、フォルダに入れて、claudeと打って『経費精算レポートを作って』と言うだけ」

試してみるプロンプト:

このフォルダにあるクレジットカードの取引履歴CSVを読んで、
経費精算用のExcelファイルを作って。
カテゴリ分け（交通費、宿泊費、飲食費など）もして

散らかった考えを整理する

「朝の散歩中にアイデアをボイスメモで録音する。Claude Codeがそれを一貫した研究テーマに整理し、完全な記事を書き、LinkedInバージョンを自動作成」

試してみるプロンプト:

このフォルダのボイスメモを全部文字起こしして、
関連するテーマごとにグループ化して、
それぞれのテーマで記事のアウトラインを作って

Part 23: 非技術者向けの最初の5つのコマンド

いきなり複雑なことをやろうとしない。まずは簡単なことから始めていこう。

Step 1: フォルダの中身を確認

このフォルダの中身を教えて

Step 2: ファイルを並べ替え

このフォルダのファイルを更新日順に並べて

Step 3: 空き容量を確認

このパソコンの空き容量を教えて。
大きいファイルやフォルダがあれば上位10個リストして

Step 4: 画像の画質を上げる

screenshot.png の画質を上げて

Step 5: ダウンロードフォルダを整理

ダウンロードフォルダを見て、
1ヶ月以上前のファイルを「古いダウンロード」フォルダに移動して

Claude Codeは実行前に「これをやっていいですか?」と確認してくる。怪しいと思ったらnと打てばいい。

Step 6: Skillsを作成

Step 1〜5に慣れてきたら、よく使う作業をSkillとして保存してみよう。

今やってくれた経費精算の手順を、Skillとして保存して。
次から /expense-report と打つだけで同じことをやってほしい。

Claude Codeが自動的にスキルファイルを作成してくれる。これで、毎回同じ指示を打つ必要がなくなる。

こうやって、少しずつできることを広げていけばいい。

Part 24: よくある失敗パターン

Anthropicの公式ベストプラクティスで挙げられている、よくある失敗パターンを見ていこう。

1. キッチンシンク・セッション

一つのタスクから始めて、無関係な質問をし、また最初のタスクに戻る。コンテキストが無関係な情報で埋まっていくパターン。

対策: /clear を無関係なタスク間で実行する。

2. 繰り返しの修正

Claudeが何か間違える。修正する。まだ間違っている。また修正する。コンテキストが失敗したアプローチで汚染されていくパターン。

対策: 2回失敗した後は、/clear して学んだことを含めた良いプロンプトで再スタートするのがいい。

3. 肥大化したCLAUDE.md

CLAUDE.mdが長すぎると、Claudeは半分を無視する。重要なルールがノイズに埋もれてしまう。

対策: 容赦なく削る。Claudeが既に正しく行っていることは、指示を書く必要がない。

4. 信頼→検証のギャップ

Claudeがもっともらしい実装を生成するが、エッジケースを処理しないことがある。

対策: 常に検証（テスト、スクリプト、スクリーンショット）を提供する。検証できないなら、出荷しない。

5. 無限探索

「調査して」と言って、スコープを指定しないパターン。Claudeが数百ファイルを読み、コンテキストを埋めてしまう。

対策: 調査のスコープを狭めるか、サブエージェントを使う。

ここまでの整理

Part 1からPart 23まで、Claude Codeの基礎から機能詳細、Tipsまでを一気に駆け抜けてきた。

CLAUDE.md、Skills、Hooks、Subagents、Tasks、MCP、Plugins。コンテキストエンジニアリングにPlanモード。覚えることは多いが、すべてを一度にマスターする必要はない。まずは自分のワークフローに近い機能から試して、少しずつ広げていけばいい。

ここまでの内容は、すべてのClaude Codeユーザーに共通する「基盤」の部分だ。次のPartからは、この基盤の上に、投資分析という具体的なユースケースとして、私が実際に使っているSkills、サブエージェントを公開する。また、以下のようなアプリケーションを10分でさくっと作るための具体的な指示、Tasks、Subagents、Skillsの3つを組み合わせた私のワークフローを紹介する。

この内容を参考にして、あなただけの投資分析手法の構築、アプリケーションの作成に挑戦して見て欲しい。