「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月現在の正解だと感じている。

関連記事

AI駆動塾 — AIを使ったスモビジの作り方を学ぶ

Claude Code、OpenClaw、AI経営OSの実践ノウハウを毎週公開中。
月額¥4,980で過去記事すべて読み放題。

noteメンバーシップに参加する →

💼 フリーランスエンジニアの案件をお探しですか？

SES解体新書フリーランスDBでは、高単価案件を多数掲載中です。

✅ マージン率公開で透明な取引
✅ AI/クラウド/Web系の厳選案件
✅ 専任コーディネーターが単価交渉をサポート

▶ 無料でエンジニア登録する