Claude Codeの使い方、実測つき

Claude Code の記事はもう十分あります。足りないのは「で、その機能は実際どれだけ使うのか」です。

この記事は、インストールから上級機能まで一通り書いたうえで、そのすべてに使用実績を付けています。 数字の出どころは、このメディアを運用している環境のセッションログ全量です。

2026年8月5日から9月3日までの30日間、65セッション、ツール呼び出し8,126回。

先に全体像を出します。

紹介記事が節を立てがちな機能ほど、下のほうにあります。 順に見ていきます。

Claude Code とは何か、何ができるか

ターミナルで動く、Anthropic 公式のコーディング用エージェントです。チャット欄にコードを貼る道具ではなく、あなたのマシンでファイルを読み書きし、コマンドを実行します。

ブラウザ版の Claude との違いは、この一点に尽きます。

できること（実測の裏付けつき）

「何ができるか」は各社の記事が並べています。ここでは当メディアで実際に発生した回数を付けます。

「コードを書かせる」より「実行して結果を確かめる」が主用途でした。テストを流して落ちたら直す、ログを見て原因を絞る、という往復が本人だけで回るのが本体です。

向かない使い方

• 正解が1つに決まらない設計判断を丸投げする。 出力は返りますが、良し悪しを判断できないなら受け入れられません
• 出力を読まずにマージする。 実測で書き換えが677回ある以上、確認しない運用は事故になります
• 1回で終わる作業。 起動と説明のコストのほうが高くつきます

始め方（インストールから初回起動まで）

ここで詰まる人は多くありません。4手順です。

1. Node.js 18 以上を入れる

公式インストーラで構いません。入っているか確認します。

node -v
# v18.x.x 以上が出れば通っている

2. Claude Code を入れる

npm install -g @anthropic-ai/claude-code

3. 作業したいフォルダで起動する

cd path/to/your-project
claude

フォルダを間違えないでください。 起動した場所が作業範囲になります。いきなり本番のリポジトリで起動せず、コピーか作業用ブランチで試すほうが安全です。

4. ログインする

初回起動でブラウザが開くので、契約済みのアカウントで認証します。

最初に打つ1行

このプロジェクトの構成を説明して。まだ何も変更しないで

「まだ何も変更しないで」を付けるのは、初回に限っては本気で推奨します。 何を勝手に触る道具なのかを、読むだけの状態で先に把握してください。

CLI・VS Code・デスクトップの違い

中身は同じです。当メディアの8,126回はすべてターミナルからのもので、入口の違いで使用比率が変わるという実測は持っていません。 好みで選んで構いません。

Windows で最初に潰すところ

日本語環境の Windows では、この先で文字化け・外部CLIの解決・長いプロンプトの破損に当たります。当メディアは Windows 11 で運用していて、Python 58ファイル中41本で文字コードの明示指定が必要でした。踏む前に潰すならWindows で Claude Code を回すと詰まる4か所を先に読んでください。

基本操作 — 実測で本当に使われていたもの

ここが本題です。8,126回の内訳です。

シェル実行が突出しています。 残り全部を足しても、その半分ちょっとにしかなりません。

シェル実行 5,169件の中身

「置いてある .py を実行した」だけをスクリプト実行として数えています。 python -c "..."（その場で書き捨てるコード）や git show foo.py（ファイル名が引数に出ただけ）は別枠です。

この線引きを緩めると数字は2倍以上に膨らみます。 最初の集計は実際そうなっていて、公開前のレビューで指摘されて直しました。配布しているスクリプトも直したあとの定義で動きます。

そのうえで読むとこうです。

• 最大はファイル閲覧・検索の24.5%。専用の検索機能（1.3% + 0.5%）ではなく、シェルで探しています
• 次が置いてあるスクリプトの実行14.6%。単一の行為としては、書き換え（8.3%）も読み取り（8.1%）も上回ります

覚える操作は3つ

3つ目はコマンドですらありませんが、実務ではこれが一番使います。1セッションの操作が中央値73回・最大1,062回である以上、間違った方向に走られると被害が大きくなります。

頼み方の型

コマンドより、頼み方のほうが結果を左右します。何をしてほしいかと、何をしてほしくないかを両方書くのが型です。

このディレクトリのテストを実行して、落ちたものだけ原因を教えて。
まだ直さないで、原因の一覧だけ先に出して。

停止条件を先に書くのが要点です。実測で書き換えが677回ある以上、止め方を知らないと勝手に書き換わります。

長い作業を頼むときは、区切りを指定します。

3つ直したら一度止めて、何を変えたか報告して。
そこで私が確認するまで次に進まないで。

コマンド一覧（頻度は未計測）

3つ以外にもコマンドはあります。ただしスラッシュコマンドの使用頻度は、今回のログからは正確に取れませんでした。 ツール呼び出しとは別の形式で記録されており、抽出できたのは11行だけです。推測で数字を出さないため、ここは頻度なしの一覧として載せます。

覚えるのは最初の3つと Esc で足ります。 残りは必要になった時点で /help を見ればよく、先に暗記する価値はありませんでした。

指示の書き方でよく効いた3つ

実測の裏付けはありませんが、当メディアで繰り返し効果があった書き方を挙げます。

1. 先に読ませる

まず関係するファイルを読んで、変更が必要な箇所を一覧にして。
一覧を私が確認するまで、書き換えないで。

2. 完了条件を数字で書く

テストが全部通るまで直して。通ったらテストの出力を貼って。
「通ったはず」ではなく、実際の出力で示して。

「はず」を禁止するのが要点です。実行して確かめられる道具なので、確かめさせないと意味がありません。

3. 前回の失敗を渡す

前回この修正をしたとき、〇〇が壊れた。同じ壊し方をしないで。

同じ失敗を2回踏むのは、たいてい前回の情報を渡していないからでした。

勝手に書き換えさせない（権限と承認）

初心者向けの記事がいちばん軽く扱う一方で、事故になるのはここです。

実測で既存ファイルの書き換えが677回、新規作成が523回あります。合計1,200回、1セッションあたり18回のペースでファイルが変わっています。

承認の仕組み

既定では、ファイルの変更やコマンドの実行前に確認が入ります。この確認を面倒がって全部許可すると、確認そのものが機能しなくなります。

現実的な運用はこうです。

3行目は当メディアの運用規約でもあります。取り返しがつく操作と、つかない操作を分けるのが唯一の線引きです。

走り出したあとに止める

停止条件を書き忘れることはあります。そのときは Esc です。押した時点で止まります。

押すのを我慢しないでください。 間違った方向に30回ツールを呼ばれてから気づくと、そこまでの出力を全部読み直す必要が出ます。当メディアの最長セッションは1,062回でした。途中で止めていれば、確認の量は桁違いに減っていました。

情報を渡さない設定

社内コードを扱うなら、先に3つだけ確認してください。

1. 顧客名・認証情報を含むファイルを作業範囲に置かない（起動フォルダが作業範囲になります）
2. .gitignore に入れただけでは読み取り対象から外れない。読ませたくないものは別の場所に置く
3. 外部の文章を読ませるサーバーを繋いだまま、書き込み権限のある作業をしない（後述のMCPの項）

CLAUDE.md に何を書くか

プロジェクトの直下に置くと、毎回読まれる設定ファイルです。/init で雛形が作れます。

各社の記事が「プロジェクトの概要を書きましょう」と説明しているところですが、実測から言えるのは違うことでした。

実測から言える、書くべきもの

置いてある自作スクリプトの実行が全操作の14.6%、種類は255種ありました。この呼び分けを成立させているのが設定ファイルの記述です。

【この案件で使うスクリプト】

| やること | コマンド |
|---|---|
| 画面を撮る | python scripts/page_screenshot.py <URL> |
| 公開する | python cron/safe_publish.py --deploy |
| シートを読む | python scripts/sheets_io.py read --id <ID> |

**手で同じ処理を書かない。上の表にあるものは必ずこれを使う。**

この1枚があるかどうかで、毎回の説明量が変わります。 逆に、プロジェクトの歴史や設計思想を長く書いても、実行される操作は増えませんでした。

書かないほうがよいもの

• 長い前置き。 毎回読まれるので、増やすほど他の指示が薄まります
• その場で説明すれば済む一度きりの事情
• 守らせたいが破っても分からないルール。 破ったら止まる仕組み（後述のフック）に寄せるほうが確実です

置き場所

チームで使うならリポジトリに入れてください。設定ファイル自体をレビュー対象にすると、書きすぎが止まります。

最初の1週間でやると効く3つ

実測の構成比から逆算した着手順です。上級機能は入っていません。

1日目 — 読ませるだけの日にする

書き換えを一切させません。この道具が何を見るのかを把握する日です。

このプロジェクトの構成を説明して。
どのファイルが何をしているか、上位10個だけ。まだ変更しないで。

このリポジトリで、直近1ヶ月に一番変更が多かったファイルを教えて。
理由も推測して。変更はしないで。

読み取りと検索は実測で全操作の3割強を占めます。ここが速いだけでも元は取れます。

2〜3日目 — 小さい修正を1件だけ、最後まで通す

いきなり大きな改修を頼まないでください。戻せる範囲の1件を、確認しながら最後まで通します。

このテストが落ちている。原因を調べて、直す方針だけ先に出して。
方針を私が承認するまで、コードは変更しないで。

方針を読んで納得したら、初めて直させます。

その方針で直して。直したらテストを実行して、実際の出力を貼って。

「実際の出力を貼って」を必ず付けてください。 実行して確かめられるのがこの道具の本体なので、確かめさせないと使う意味が半減します。

4〜7日目 — 繰り返している説明をファイルにする

3日も使うと、毎回同じ説明をしていることに気づきます。そこが最大の改善点です。

ここまでの会話で、私が繰り返し説明した前提を洗い出して。
設定ファイルに書くべきものだけ、箇条書きで出して。

出てきたものを設定ファイルに移します。同時に、毎回同じ手順で叩いているコマンドがあればスクリプトにします。

この一連の手順をスクリプトにして。
Windows で文字化けしないように標準出力を UTF-8 にして。

実測でスクリプト実行が全操作の14.6%を占めていたのは、この作業を積み重ねた結果です。1週間目でここまで来ると、2週目以降の説明量が明確に減ります。

1週間で触らなくてよいもの

焦って上級機能を入れると、覚えることだけ増えて使用率は上がりませんでした。

上級機能は、実測ではどれだけ使われたか

ここが、他の記事といちばん違う節です。各機能の説明はどこにでもあるので、使用率を付けます。

合計しても3.2%です。 「上級機能」という名前ですが、実務の中心ではありませんでした。

MCP — 繋いだうち、毎日使ったものは0

外部サービスに接続する仕組みです。繋ぐとデザインカンプを直接読む、といったことができます。

実測は176回（全体の2.2%）、呼ばれたのは7サーバー・29ツール、うち8ツールは30日間で1回きりでした。

実際に作業した25日のうち、最頻の Figma でも8日です。毎日使ったサーバーは1つもありませんでした。

判断の基準は1つでした。そのサービスを、作業の途中で必ず見にいくか。 「見にいく」であって「操作する」ではありません。シェルから触れるもの（ファイル置き場など）を繋いでも、そちらは使われ続けます。

繋ぐ前に、誰が作ったサーバーか・どこまでの権限を渡すか・外部の文章を読ませるかの3つだけ確認してください。外部の文章を読むサーバーは、その中に書かれた指示をAIが命令として拾う危険があります。詳細はMCPの実測記事に書きました。

サブエージェント — 16体作って13体消した

別のAIに作業を委ねる仕組みです。実測は63回（0.8%）でした。

当メディアは108日間で16体作り、13体を消しています。 残した3体の理由は「独立性が要る」か「中間生成物を本体に載せたくない」のどちらかだけでした。役割の一覧から作ると使われません（詳細）。

最初から作らなくて構いません。 本体でやって困ったときに、困った理由を1行で書けたら1体足す、で足ります。

Skills — 0.2%

決まった手順をパッケージにして呼び出す仕組みです。実測は17回（0.2%）でした。

使われない理由ははっきりしています。呼び出す導線がないと起動しないからです。当メディアでは、同じ手順をスクリプトにして設定ファイルに1行書くほうが確実に呼ばれました（そちらは14.6%）。

フック — 回数では測れないが効く

特定のタイミングで自動的にスクリプトを走らせる仕組みです。回数では出ませんが、当メディアではこれが一番効いています。

理由は、守らせたいルールを「破ったら止まる」に変換できるからです。文章で「本番には勝手に触らない」と書いても読み飛ばされますが、フックで止めれば違反が存在しなくなります（実装例）。

上級機能に手を出す順番は、フック → MCP → サブエージェント → Skills が実測に合っています。

料金は「回数」ではなく「1回の長さ」で決まる

Free プランでは使えません。Pro 以上か API 従量課金が必要です。

各社の記事はプラン表を並べていますが、選び方の軸が抜けています。 実測がそこを埋めます。

「月に何回聞くか」で見積もると外します。 1回の依頼が中央値73回、長いものでは1,000回超の往復になるからです。

つまり判断はこうなります。

プラン別の金額と、当メディアがどう判断したかはClaude Code の料金にまとめています。

Codex とどう使い分けるか

比較記事の結論だけ書きます。優劣ではなく併用で成立しました。

当メディアは17日間の並走実測で、衝突したのは生成処理ではなく公開処理だけ（17日間で1回）でした。役割を分ければ同時に走らせられます。

詳細と実測はClaude Code と Codex、どっちを使う？にあります。

どこまで作り込むかの判断

実測で14.6%を占めていたスクリプト化ですが、全員が255本書く必要はありません。 判断はこの1点です。

その作業を、今月あと何回やるか。

スクリプトにする価値があるのは、判断がなく、手順が決まっていて、頻度が高いものだけです。当メディアで上位を占めたのは、画面を決まったサイズで撮る、決まった手順で公開する、決まったタブを読む、といった作業でした。

上位10本が全実行の46%を占めていたのは、この判断を繰り返した結果、頻度の高いものだけが残ったからです。最初から255本あったわけではありません。

実践：この手順で実際に作ってみる

ここまでの手順が実際に回るのかを、この記事で配布しているスクリプトを作った過程そのもので示します。所要は約1時間、途中で1回間違えています。

手順1 — 何をしてほしくないかを先に書く

いきなり「ログを集計して」とは頼みません。作業範囲と停止条件を先に渡します。

~/.claude/projects/ 配下の .jsonl を読んで、ツール呼び出しの回数を数えたい。
まずファイルの構造だけ調べて、どのキーに何が入っているか教えて。
この段階ではスクリプトを書かないで。

返ってきたのは構造の説明だけでした。ここでいきなりコードを書かせると、前提を間違えたまま100行書かれます。

手順2 — 小さく1回試す

構造が分かったら、その場書きで最小の集計だけ回します。ファイルにはまだしません。

tool_use の name だけ数えて、上位10件を表示して。
ファイルには保存しないで、その場で実行して結果だけ見せて。

実測で「その場書きの Python」が全操作の6.9%あるのは、この段階の試行です。書き捨てが前提なので、.py を作らせないほうが速くなります。

手順3 — 通ったらファイルにする

数字が出たら、そこで初めてスクリプトにします。

今の集計をスクリプトにして。
Windows で文字化けしないよう標準出力を UTF-8 にして、
--days で期間を絞れるようにして。

ここでWindows特有の指定を明示的に頼んでいるのが要点です。放っておくと CP932 のまま書かれて、日本語のパスが出た瞬間に落ちます。

手順4 — ここで間違えた

出てきた数字は「自作スクリプトの実行が全操作の37.2%」でした。これを信じて記事を書きかけました。

公開前に別のAI（Codex）へレビューを投げたところ、こう返ってきました。

これは python -c、py -m pytest、コマンド内に .py が出るだけのケースも含みます。実際に確認すると git show foo.py も Python 実行に分類されました。

分類が緩すぎました。 正しく数え直すと 14.6%、2.5倍の水増しです。

分類を直して。
インタプリタが .py ファイルを実行しているものだけを「スクリプト実行」と数えて、
python -c と、.py が引数に出るだけのものは別枠にして。

結果、内訳はこう変わりました。

この工程がなければ、2.5倍の数字を公開していました。

手順5 — 数字が動かないようにする

再レビューで次の指摘が来ました。--days 30 は当日を含むため、実行するたびに結果が変わります。

--since と --until を足して、期間を閉じられるようにして。
期間を閉じたときは「再現できる」と出力に明記して。

これで、この記事の数字は次の1行で誰でも再現できるようになりました。

python count_tool_calls.py --since 2026-08-05 --until 2026-09-03

この1時間で分かったこと

3行目が最大の収穫です。 自分で書いたものを自分で検算しても、同じ前提のまま同じ見落としをします。当メディアがサブエージェントを3体だけ残した理由もこれでした。

メリットとデメリット（実測つき）

紹介記事が並べる項目に、使用実績を付けます。

メリット

4行目が本体です。 「コードを書いてもらう」より「決まった手順を呼び分けてもらう」ほうが、回数として圧倒的に多く発生していました。

デメリット

4行目が一番重い制約です。 出力はもっともらしく、エラーも出ません。自分で検算できない領域には使えないという前提は変わりませんでした。

非エンジニアが使う場合の線引き

「プログラミング不要」と書かれることが多い機能ですが、実測を踏まえると条件付きです。

右列の3行目が理由です。「これは戻せる操作か」を判断できない状態で書き込み権限を渡すのは危険なので、最初は読み取りだけの作業から始めてください。

チームで使うとき

1人で使うのと、複数人・複数エージェントで使うのは別の問題です。当メディアはClaude Code と Codex を同じリポジトリで並走させていて、17日間の実測があります。

衝突したのは1回だけ、しかも生成処理ではなかった

同時にコードを書かせても、ほとんど衝突しません。 壊れるのは、同じ1つの出口を同時に通ろうとしたときでした。当メディアの場合は「サイトを公開する処理」です。

対処は排他ロック1つで済みました。公開処理の入口でロックを取り、取れなければ待つか終了する。生成の並列化を諦める必要はありませんでした。

分担の決め方

役割ではなく、触るファイルの範囲で分けるほうが機能しました。

社内に入れるときに先に決めること

技術より運用の合意が先です。当メディアで実際に必要になったのは3つでした。

1. 取り返しがつかない操作の一覧を作る。 本番反映・削除・外部送信・課金。ここは人が承認する
2. 設定ファイルをレビュー対象にする。 個人の好みが全員に効いてしまうため
3. 出力をそのままマージしない運用を明文化する。 実測で書き換えが677回発生する以上、確認の工程を省くと事故が起きます

1つ目が最重要です。 「戻せる操作」と「戻せない操作」を分けておかないと、どこまで任せてよいかを各自が勝手に判断することになります。

詰まったときの処方

30日間で実際に踏んだものだけを並べます。

3つ目が一番厄介です。エラーが出ないので、モデルが指示を無視したように見えます。 実際には文字列が到達していません。

この記事を書いている最中にも1回踏みました。長い指示をコマンドの引数で渡してシェルに壊され、まったく違う出力が返ってきています。

実測で否定された、よくある説明

最後に、紹介記事でよく見る説明のうち、当メディアの30日間では成り立たなかったものを並べます。どれも「間違い」ではなく、この環境では起きなかったという意味です。

なぜこうなるのか

共通しているのは1つです。名前の付いた機能より、既にある手段のほうが強い。

検索機能が使われないのは弱いからではなく、シェルから grep を打つほうが速いからでした。Skills が0.2%なのは、同じ手順をスクリプトにして設定ファイルに1行書くほうが確実に呼ばれるからです。

機能は「新しくできること」を増やしますが、「既にできること」とは競争になります。 そして多くの場面で、既にできることのほうが勝ちました。

だから最初にやることは変わらない

上位3つに機能名が1つも出てこないのが、この30日間の結論です。

この記事の数字の測り方と、その限界

数字を出す記事は、測り方を書かないと検算できません。 ここに全部書きます。

何を1回と数えたか

セッションログ（~/.claude/projects/ 配下の .jsonl）を読み、AIがツールを呼んだ記録を1回として数えています。人間の発言や、AIの文章による回答は数えていません。

つまりこの記事の「回数」は、画面の裏で実際に実行された操作の数です。会話の往復数ではありません。

分類の境界

いちばん誤差が出るのが、シェル実行の中身の分類です。境界をこう決めました。

cd foo && git status を取り逃がさないよう、先頭一致ではなく部分一致で判定しています。 そのため git の件数は、分類上の件数（279件）とコマンド文字列に git が現れた件数（288件）で少しずれます。本文ではどちらの数字かを明記しました。

測れなかったもの

出せない数字は出しません。 今回測れなかったのは次です。

この環境の偏り

1人・1環境・30日間の記録です。 一般化するには次の偏りを引いてください。

とくに用途の偏りが比率に効きます。 データベースを常時参照する開発なら MCP の比率は上がるはずで、逆にスクリプト化の比率は下がる可能性があります。

検算のしかた

配布しているスクリプトで、この記事の全部の表が出ます。期間を閉じてください。 開いたままだと当日ぶんが増え続け、同じ数字を二度出せません。

python count_tool_calls.py --since 2026-08-05 --until 2026-09-03

自分の環境で回して、比率がこの記事と違ったらあなたの環境ではあなたの数字が正しいです。この記事の使いどころは、比率そのものではなく「機能名ではなく使用率で優先順位を決める」という測り方のほうです。

まとめ

• シェル実行が63.6%。 中身の最大はファイル閲覧・検索24.5%、次が置いてあるスクリプトの実行14.6%
• 覚える操作は3つ（文脈のリセット・初期化・中断）。残りの時間はスクリプト化に使うほうが効く
• 上級機能の合計は3.2%（MCP 2.2% / サブエージェント 0.8% / Skills 0.2%）。後回しでよい
• 書き換えが677回。 止め方を先に覚える。取り返しがつかない操作は自動化しない
• 料金は「月に何回聞くか」ではなく「1回の作業がどれだけ長いか」で決まる（中央値73回・最大1,062回）

ただし、これは1人の環境の30日間です。用途はメディア運営とWeb制作なので、アプリ開発が中心なら比率は変わります。だからこそ自分のログで数えてください。

数字は次のコマンドで固定しています。期間を閉じないと当日ぶんが増え続け、実行するたびに答えが変わります。

python count_tool_calls.py --since 2026-08-05 --until 2026-09-03

数えたうえで「どの機能に時間を使うか」「どこまで自動化すると壊れるか」の線引きに迷う場合は、当メディアの運用設計をそのまま持ち込めます。