「Claude Codeを本当に使いこなせているか自信がない」——SESの現場で同僚から聞くたびに、自分の設定ファイルを見せると驚かれる。今回は、実際に毎日使っている設定・コマンド・パターンを全部公開する。嘘なし、盛りなし。
なぜClaude Codeを毎日使うようになったか
SESエンジニアとして複数の現場を経験するなかで、「データ分析」業務の依頼が年々増えてきた。Pythonでの集計スクリプト作成、SQL最適化、可視化ダッシュボード構築——これらを毎回ゼロから書くのが純粋に苦痛だった。
ChatGPTやGitHub Copilotも試したが、コンテキストが途切れる問題と、ローカルファイルへの直接アクセスが弱い点がどうしても気になった。Claude Codeはローカルファイルを直接読み書きできるし、シェルコマンドも実行できる。「エディタとターミナルを行き来しなくていい」——これが決め手だった。
最初にやること：CLAUDE.mdの設定
Claude Codeで最初に効果があったのは、プロジェクトルートにCLAUDE.mdを置くことだ。これを設定するかどうかで、毎回の指示コストが劇的に変わる。Claude Codeはセッション開始時にこのファイルを自動で読み込み、以降の会話のコンテキストとして使う。
実際に使っているCLAUDE.mdの抜粋：
# プロジェクト概要
Pythonによるデータ分析パイプライン。pandas + SQLAlchemyで社内DBを集計する。
# コーディング規約
- Pythonはblack + ruffでフォーマット
- 型ヒントを必ず付ける
- コメントは書かない（変数名で意図を伝える）
# よく使うコマンド
- テスト実行: pytest tests/ -v
- フォーマット: black . && ruff check . --fix
- データ確認: python scripts/validate_data.py
# 鉄則
- secrets/フォルダは絶対に読み書きしない
- 本番DBへの直接接続は禁止（testDBのみ可）
- 重要な変更の前は必ず確認を取ること
これだけで「毎回プロジェクトの説明をしなくていい」状態になる。CLAUDE.mdはグローバル設定（~/.claude/CLAUDE.md）とプロジェクト設定の2層構造になっており、両方が読み込まれる。
データ分析業務での実際の使い方
ケース1：CSVの前処理を一気に書かせた
現場で渡されたCSVが文字コード・日付フォーマット・欠損値の処理が全部バラバラだった。「このCSVを見て前処理スクリプトを書いて」と頼んだら、ファイルを読んで実際に実行して確認まで自動でやってくれた。
具体的な流れ：
- CSVをプロジェクトフォルダに置く
- 「このCSVの品質チェックをして、問題点を洗い出してからクリーニングスクリプトを書いて」と指示
- Claude Codeがファイルを読み込み、実際にPythonを実行して分析
- 問題点をリストアップして確認を取る
- スクリプト生成→実行→結果確認まで完結
ポイントは「確認を取る」ステップを入れさせることだ。これをしないと暴走することがある。CLAUDE.mdに「重要な変更の前は必ず確認を取ること」と書いておくと安定する。
ケース2：SQLクエリの最適化
EXPLAIN ANALYZEの出力を貼り付けて「このクエリのボトルネックを見つけて修正して」と頼むのが定番になった。
-- こういうボトルネック満載のクエリを貼り付ける
SELECT u.*, o.*, p.*
FROM users u
JOIN orders o ON u.id = o.user_id
JOIN products p ON o.product_id = p.id
WHERE o.created_at > '2026-01-01'
EXPLAINの出力も一緒に渡すと、インデックス追加の提案まで出してくれる。「N+1クエリになっているのでサブクエリに書き直せ」という指摘が来ることもある。現場で使うSQLは複雑なケースが多いので、これは実際に時間が浮いた。
ケース3：Jupyter Notebookの整理
データ分析系の現場では、前任者が書いたJupyter Notebookが散乱していることが多い。「このNotebookを見てスクリプトに変換して、再現性を高めて」と頼むと、乱雑な分析コードをきれいなPythonスクリプトに整理してくれた。
Notebookの整理では特にこのプロンプトが効いた：
「このNotebookを分析して：
1. どんな前処理をしているか要約
2. ハードコードされている値を設定ファイルに外出し
3. 再実行できる形でスクリプト化
確認してから実行すること」
サブエージェント機能：並列作業が変わる
2026年現在、Claude Codeの「Agentツール」を使ったサブエージェント機能が最もインパクトが大きい変化だと感じる。
使ったパターンはこれ：
「以下の3つのタスクを並列で実行してください：
1. sales_2025.csv のデータ品質チェック
2. sales_2026.csv のデータ品質チェック
3. この2つのスキーマの差分レポート作成」
逐次処理なら3倍かかるところが、並列で走るので実質1タスク分の時間で終わる。データ分析のバッチ処理設計でこれを覚えてから、見積もりの出し方が変わった。
サブエージェントが特に効くパターン
| ユースケース | 効果 |
|---|---|
| 複数ファイルの並列分析 | ファイル数に依らず処理時間がほぼ一定 |
| 複数環境でのテスト実行 | dev/staging/prod環境の並列確認 |
| 競合サービスの並列調査 | 複数サービスの仕様を同時調べ |
| コードレビューの観点分割 | バグ・セキュリティ・パフォーマンスを同時 |
ただし、サブエージェントはトークン消費が多い。使いどころを絞らないと費用対効果が合わなくなる。「3つ以上の独立したタスクが同時にある」場合だけ使うのが自分のルールだ。
実際に「動く設定」を公開する
.claude/settings.json のhooks設定
プロジェクト単位で入れているhooksの設定：
{
"hooks": {
"PostToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "echo '[Bash実行] '$(date '+%Y-%m-%d %H:%M:%S') >> /tmp/claude_audit.log"
}
]
}
],
"PreToolUse": [
{
"matcher": "Write",
"hooks": [
{
"type": "command",
"command": "echo '[ファイル書込み前] '$CLAUDE_TOOL_INPUT_FILE_PATH >> /tmp/claude_write.log"
}
]
}
]
}
}
これでどのファイルをいつ操作したかのログが残る。現場に納品するコードを書かせるときは特に安心感がある。ログが残ることで「何をしたか」の説明責任も果たしやすい。
/code-reviewスキルで差分を自動レビュー
GitのdiffをClaude Codeにレビューしてもらう機能も毎日使っている。
/code-review # 通常レビュー（コミット前の確認）
/code-review high # 厳しめのレビュー（PR前）
/code-review ultra # クラウドの複数エージェントによる最高精度レビュー
/code-review ultraはトークン消費が多いので、大きなPRや本番リリース前だけ使う。普段は/code-reviewで十分。
実際にこれで防いだバグ：
- SQLのパラメータ結合でインジェクションになりかけていた箇所
- pandasのDataFrame操作で
inplace=Trueを間違って使っていた箇所 - 非同期処理で
awaitを忘れていた箇所
コードレビューは「バグを見つけること」より「自分が気づいていない問題のカテゴリを知ること」に価値がある。
使っていてわかった本当の限界
正直に書く。向いていないことを知らずに使うと時間を浪費する。
向いていないこと：
- UIのビジュアル確認が必要な作業（最終確認は人間が必要）
- 複雑なビジネスロジックの判断（ドメイン知識が必要な意思決定）
- 大量のレガシーコードのリファクタ（コンテキストウィンドウに収まらないことがある）
- リアルタイム系のデバッグ（ログをひたすら貼り付ける運用になりがち）
よくあるハマりポイントと対策：
1. コンテキストが長くなると精度が落ちる
→ 長いセッションは/clearでリセット。CLAUDE.mdで重要情報は常に参照可能にしておく
2. 「できます」と言って実際はできないことがある
→ 「本当にこのコマンドで動くか確認してから実行して」と追加指示する
3. ファイルを意図せず上書きする
→ settings.jsonのhooksでWriteの前にログを取る。重要ファイルはgitでバックアップ必須
4. macOSでtimeoutが使えない
→ gtimeoutを使う（CLAUDE.mdにも明記しておく）。これを知らずにcronが死んだ経験がある
フリーランス転向を考えたときに気づいたこと
SES案件を複数経験して「フリーランスに転向すれば単価が上がるのでは」と考えるのは自然だ。実際にフリーランスの知人から話を聞いたり、SES単価相場と直接契約の相場を調べたりして気づいたのは、スキルより契約交渉力と案件獲得ルートが単価を決めるという現実だった。
フリーランス転向前に準備したこと（と失敗したこと）を書く。
フリーランス契約書テンプレートで学んだこと
最初はWebで拾ったフリーランス契約書テンプレートをそのまま使おうとした。Claude Codeに「この契約書のリスクを洗い出して」と頼んだら、問題点が複数出てきた。
主なリスクポイント：
- 知的財産権の帰属が曖昧：「成果物の著作権は甲に帰属する」だけでは作業中間物（ライブラリ・ツール）の扱いが未定義
- 瑕疵担保期間が長すぎる：「納品後1年間」はエンジニア個人には過大なリスク
- 再委託禁止条項がない：クライアントが勝手に別会社に再委託できてしまうケース
- 支払条件が曖昧：「検収後30日以内」の「検収」の定義がない
Claude Codeを使った契約書レビューの手順：
1. 契約書をテキストとしてプロジェクトフォルダに保存
2. 「フリーランスエンジニアの立場からこの契約書のリスクを洗い出して。
特に知財・支払・瑕疵担保・守秘義務の4点を重点的に」
3. 出てきたリスクに対して「この条項を受注者に有利に書き直して」
4. 修正案を弁護士（スポット相談）に最終確認
Claude Codeのレビューは出発点として優秀だが、最終判断は専門家に。これは実際に使って感じた限界だ。契約書は「AIに任せて終わり」にしてはいけない。
SES単価相場とAIスキルの関係
2026年7月時点で正直に言えることを書く。AIツールを使いこなせるかどうかは、それ自体では単価に直結しない。「Claude Codeが使えます」で案件単価が上がるかというと、そうではない。
ただし、AIツールによって個人の生産性が上がることで間接的な効果はある：
- 短い工数で同じ成果物が完成 → 実質的な時間単価が上がる
- より複雑・上流の業務を受注できるようになる → 案件単価が上がる
データ分析案件でいえば、Pythonスクリプトをさっと書けることより、「要件定義・設計・レビューができる」という上流スキルの方が単価に効く。AIツールは「速く書く」ためではなく「上流に上がる」ための時間を作るために使うのが正解だと思っている。
まとめ：毎日使うための最低限の準備
Claude Codeを毎日使うための最低限の準備をコマンドで書く：
# 1. グローバルCLAUDE.mdを作る
touch ~/.claude/CLAUDE.md
# 2. プロジェクトごとのCLAUDE.mdを作る（各リポジトリルート）
touch ./CLAUDE.md
# 3. プロジェクト設定フォルダとhooks設定ファイル
mkdir -p .claude
touch .claude/settings.json
# 4. hooksのログ確認（設定後に動作確認）
tail -f /tmp/claude_audit.log
データ分析エンジニアとして現場に入るなら、最初の1週間でこの設定を整えるだけで体感の作業効率が変わる。SESでも直接契約でも、AIツールを道具として使いこなせる状態を作ることが先で、フリーランス転向はその後でいい。
焦って転向してAIツールも使いこなせないまま案件を受けると、品質が落ちて評判を落とす。道具を整えてから動く——それが2026年7月現在の正解だと感じている。
関連記事
- SESつらいエンジニアが2026年にフリーランスへ転身する最短ルート【データ分析×AI活用】
- 【2026年最新】フリーランスエンジニアのAI業務効率化ツール完全まとめ｜結局どれを使えばいいのか徹底解説
- OpenClaw×Claude Code連携で爆速開発【2026年最新】SESやめたいエンジニアのAI駆動独立準備術
AI駆動塾 — AIを使ったスモビジの作り方を学ぶ
Claude Code、OpenClaw、AI経営OSの実践ノウハウを毎週公開中。
月額¥4,980で過去記事すべて読み放題。
💼 フリーランスエンジニアの案件をお探しですか？
SES解体新書 フリーランスDBでは、高単価案件を多数掲載中です。
- ✅ マージン率公開で透明な取引
- ✅ AI/クラウド/Web系の厳選案件
- ✅ 専任コーディネーターが単価交渉をサポート