はじめに：2026年9月、Claude Codeを触らない日はない
毎日Claude Codeを使って開発している。2026年9月27日現在、手元のプロジェクトはほぼ全部.claude/ディレクトリを持っていて、CLAUDE.md、settings.json、カスタムスラッシュコマンド、サブエージェント定義まで揃っている状態だ。
最初は「AIにコード書かせるだけの便利ツール」くらいの認識だったが、半年以上毎日触っていると、設定次第で生産性も安全性も全然違うことに気づく。今回は盛らずに、実際に自分の環境で動いているコマンドと設定をそのまま共有する。
Qiitaのトレンドを見ても、この温度感は自分だけではなさそうだ。直近14日でストック20を超えた記事は「AI」タグ付き13本、「ClaudeCode」タグ付き12本、「生成AI」タグ付き11本（Qiita、2026年9月26日時点の観測）。設定周りのつまずき（拒否ルール、permissions、キャッシュ挙動）がテーマになっている記事が多く、自分が普段ハマっているポイントとかなり重なる。
実務で使っているClaude Code設定・コマンド集
1. CLAUDE.mdはプロジェクトごとに「薄く」書く
最初はCLAUDE.mdに何でも書き込んでいたが、情報過多だと逆にAIの判断がブレることに気づいた。今は「このプロジェクト固有のルール」だけに絞っている。
# CLAUDE.md
## コーディング規約
- テストは vitest。新規ロジックには必ずユニットテストを書く
- APIレスポンスの型は src/types/ に集約する（型の重複禁止）
## 禁止事項
- .env ファイルへの直接書き込み禁止
- main ブランチへの直接push禁止
汎用的な「コメントは書くな」「YAGNI」みたいなルールはグローバル設定（~/.claude/CLAUDE.md）に寄せて、プロジェクト側は本当に固有の制約だけにする。これだけで指示の再現性が上がった実感がある。
2. permissionsとhooksで「事故る前に止める」
--dangerously-skip-permissionsを常用するのは怖いので、代わりにsettings.jsonのpermissionsとhooksを組み合わせている。
{
"permissions": {
"allow": [
"Bash(git status)",
"Bash(git diff *)",
"Bash(npm test)",
"Bash(npm run build)"
],
"deny": [
"Bash(rm -rf *)",
"Bash(git push --force*)",
"Bash(git reset --hard*)"
]
},
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{ "type": "command", "command": "scripts/guard-dangerous-command.sh" }
]
}
]
}
}
guard-dangerous-command.shは渡ってきたコマンド文字列を見て、危険そうなパターン（本番DBへの直接接続文字列など）を検知したら非ゼロ終了でブロックするだけの薄いシェルスクリプト。allowリストに書いた分は許可プロンプトが出ずに実行されるので、日常的なgit操作やテスト実行のたびに確認を求められるストレスがなくなった。
3. サブエージェントで文脈を汚さない
大きめのリファクタや調査タスクをメインのコンテキストでやると、すぐウィンドウが埋まる。今は用途別にサブエージェントを.claude/agents/配下に置いている。
---
name: code-reviewer
description: 変更差分のバグ・簡略化ポイントをレビューする。コミット前に必ず使う
tools: Read, Grep, Bash
---
あなたはシニアエンジニアとしてコードレビューを行う。
差分に対して正確性・再利用性・パフォーマンスの観点で指摘する。
調査系のタスクはExploreエージェント、レビューはcode-reviewer、実装は自分（メインループ）、という役割分担にしてから、メインのコンテキストが変な調査ログで埋まることがなくなった。
4. カスタムスラッシュコマンドで定型作業を圧縮
デプロイ前チェックや週次レポートみたいな「毎回同じ手順」は.claude/commands/にMarkdownで置いている。
---
description: デプロイ前の最終チェックを実行する
---
1. git status で未コミットの変更がないか確認
2. npm run build が通るか確認
3. .env に本番キーが紛れ込んでいないか確認
4. 問題なければユーザーにデプロイ実行の可否を確認する
/deploy-checkと打つだけでこの手順を毎回一字一句同じように実行してくれる。人間がチェックリストを目で追うより漏れが減った。
5. Plan Mode は「非同期タスク」でこそ使う
3ステップ以上のタスクは基本Plan Modeに入れているが、これは単に「丁寧にやる」ためではなく、実装着手前にファイル構成のズレに気づけるから。特にモノレポでどのパッケージを触るべきか曖昧なとき、計画段階で間違いに気づけると手戻りがゼロになる。
6. モデル選択はタスクの重さで変える
2026年9月時点で使えるのはOpus 5、Sonnet 5、Haiku 4.5の3系統。自分は基本Sonnet 5固定で、設計判断が絡む重いタスクだけ/modelでOpus 5に切り替えている。単純な文字列置換や大量ファイルの機械的な変更はHaiku 4.5に投げてコストを抑える。Fast modeはOpus系をベースに出力を速くする機能で、モデルを落とすわけではないので、精度を落とさずスピードだけ欲しいときに使っている。
7. MCPサーバーで外部ツールを繋ぐ
ブラウザ操作が必要な検証はPlaywright MCPを繋いでいる。
claude mcp add playwright -- npx @playwright/mcp@latest
追加後は/mcpで接続状態を確認できる。UI変更のときは実際にブラウザを操作して確認させることで、「コードは通ったが画面は崩れている」という事故を減らせる。
保存版：Claude Code設定チェックリスト
毎回思い出しながら設定するのは非効率なので、新規プロジェクトを立てるたびに以下を上から確認している。ブックマークか保存推奨。
| # | チェック項目 | 目的 |
|---|---|---|
| 1 | CLAUDE.mdにプロジェクト固有ルールのみ記載したか | 指示のブレを防ぐ |
| 2 | settings.jsonにdenyリスト（rm -rf, force push等）を設定したか | 事故防止 |
| 3 | allowリストに日常コマンド（git status, npm test等）を追加したか | プロンプト疲れの軽減 |
| 4 | 危険コマンド用のPreToolUse hookを用意したか | 二重の安全網 |
| 5 | レビュー用サブエージェントを用意したか | コンテキスト分離 |
| 6 | 定型作業をスラッシュコマンド化したか | 再現性の担保 |
| 7 | .envなど機密ファイルがcommit対象に入っていないか | 情報漏洩防止 |
| 8 | モデル選択の基準（軽作業/重作業）を決めたか | コスト最適化 |
失敗談：やらかしたClaude Code運用アンチパターン3選
成功談ばかり書いても実態からズレるので、実際にやらかした失敗も書いておく。
アンチパターン1：permissionsを全部allowにして楽をしようとした
プロトタイプ段階で「いちいち確認されるのが面倒」という理由でallowを緩めすぎた結果、想定外のディレクトリでファイルを大量生成されたことがある。allowリストは「よく使う安全なコマンドをピンポイントで許可する」ものであって、面倒だからと丸ごと緩める運用にすると本末転倒になる。
アンチパターン2：CLAUDE.mdに情報を詰め込みすぎた
「念のため」であらゆるルールを書き込んだ結果、指示同士が矛盾し、AIがどちらを優先すべきか迷うような出力を返すようになった。ルールは薄く、本当に必要なものだけに絞るべきだった。
アンチパターン3：サブエージェントの出力を無検証で信用した
調査系サブエージェントの「完了しました」という報告を鵜呑みにして、実際のファイル変更を確認せずに次の作業に進んだことがある。サブエージェントの報告は「意図」であって「実行結果そのもの」ではないので、重要な変更は必ず差分を自分の目で見るようにしてから、この手のすれ違いはなくなった。
フリーランスエンジニアのキャリアガイド：AI時代の市場データ分析
ここからは少し毛色を変えて、SES・フリーランス双方の立場で見えている市場の話をする。
自分の稼働データをClaude Codeで分析する
フリーランスエンジニアとして案件の単価やスキルセットの需要を追うとき、感覚だけで判断するのはリスクが大きい。自分はgitのコミットログや稼働時間を簡単なスクリプトで集計し、Claude Codeに分析させることを月次でやっている。
git log --since="1 month ago" --author="自分の名前" --pretty=format:"%ad %s" --date=short > monthly_log.txt
このログをClaude Codeに読み込ませ、「どの技術領域に時間を使っているか」「単価の高い案件と低い案件で作業内容にどんな違いがあるか」を可視化させると、次にどのスキルに投資すべきかの判断材料になる。これは勘に頼らないデータ分析としてのエンジニアキャリアガイドの一部だと考えている。
市場データ分析の視点：SESとフリーランスの違い
SES企業に所属するエンジニアと、フリーランスとして直接契約するエンジニアでは、AIツール活用の自由度が大きく違う。SES常駐先ではセキュリティポリシー上Claude Codeのようなツール導入自体が制限されるケースがあり、逆にフリーランスは自分の裁量でツールチェーンを最適化できる。経済産業省が公表しているIT人材白書でも、AIツールを使いこなせるかどうかがエンジニアの市場価値を左右する時代になってきていると指摘されており、この差は今後さらに開いていく可能性がある。
キャリアの選択肢として「AIツールを自由に使える環境かどうか」を契約前に確認する価値は、単価交渉以上に重要になりつつあると感じている。
まとめ
今回紹介したのは、盛らずに実際に自分の環境で動いている設定とコマンドだけだ。
- CLAUDE.mdは薄く、プロジェクト固有ルールに絞る
- permissions/hooksで事故を二重に防ぐ
- サブエージェントで役割分担し、出力は必ず自分の目で確認する
- 定型作業はスラッシュコマンド化する
- モデルはタスクの重さで使い分ける
- 自分の稼働データを定期的に分析し、勘ではなくデータでキャリアを判断する
AI、フリーランス、データ分析、この3つを掛け合わせた働き方は、今後のエンジニア市場データ分析においてますます重要になっていくはずだ。
関連記事
- 【2026年最新】AIコーディングツール完全比較｜Claude Code・Copilot・Cursor・Codeium・Windsurfどれを使うべきか
- OpenClaw×Claude Code連携実践ガイド：思考と実行を分けるAI開発フロー
- OpenClawで9体のAIエージェント経営OSを作った話｜Claude Code実践ログ
AI駆動塾 — AIを使ったスモビジの作り方を学ぶ
Claude Code、OpenClaw、AI経営OSの実践ノウハウを毎週公開中。
月額¥4,980で過去記事すべて読み放題。
書いた人: 合同会社Radineer（フリーランス向け案件サイト FreelanceDB を運営）