はじめに：2026年10月、Claude Codeは「書くAI」から「動くAI」になった
普段は常駐のSES案件でバックエンドを書きながら、空いた時間で自分のツールをClaude Codeで作っている。2026年10月2日現在、Claude Code(CLI)は毎日起動しないと落ち着かないレベルで常用ツールになっていて、git logを見るより先にclaudeと打つ癖がついた。
この記事では「Claude Codeをこう使うと効く」という実務Tipsを、実際に動くコマンドと設定ファイルの中身込みで出す。後半では、同じエンジニアがSESからフリーランスへ転向を考えるときに何を比較すべきかを、盛らずに整理する。Qiitaでは直近2週間で「AI」「Security」関連タグの記事がストック20超を複数本出していて、AIコーディングと安全な権限設計への関心が明らかに上がっている。この記事もその延長線上の話だと思ってほしい。
1. CLAUDE.mdは「指示書」ではなく「憲法」として書く
最初に失敗したのが、CLAUDE.mdに「これをやってください」という単発の依頼文を書いていたこと。これは毎回のセッションで再利用されないので意味がない。正しい使い方は、プロジェクト直下のCLAUDE.mdに恒久的なルールだけを書くこと。
## コーディング規約
- 型は any を使わない。unknown + 型ガードで絞る
- テストはVitest。モックはDBアクセス層のみ許可
- コミットメッセージは Conventional Commits 形式
## 絶対にやってはいけないこと
- .env ファイルをgit addしない
- 本番DBのマイグレーションは必ずdry-runしてから実行
さらに、別ファイルに切り出した詳細ルールは@記法でインポートできる。
@docs/testing-policy.md
@docs/deploy-checklist.md
これをやってからは、毎回同じ注意をチャットで繰り返す回数が明確に減った。
2. permissionsは「許可リスト」を先に作ってから触らせる
claude --dangerously-skip-permissionsで全部許可するのは一番やってはいけないパターン。代わりに.claude/settings.jsonに許可コマンドを明示的に書く。
{
"permissions": {
"allow": [
"Bash(git status)",
"Bash(git diff:*)",
"Bash(npm test:*)",
"Bash(npm run lint:*)"
],
"deny": [
"Bash(git push --force:*)",
"Bash(rm -rf:*)"
]
}
}
こうしておくと、危険な操作だけ毎回確認プロンプトが出る状態になる。全許可でストレスフリーにするより、deny側を厚くする方が長期的に事故が減る。実際、rm -rfやgit push --forceをdenyに入れてから「あ、危なかった」と思う場面が明確に減った。
3. Hooksでコミット前チェックを自動化する
PreToolUseフックを使うと、Claudeが特定のツールを呼ぶ直前にシェルコマンドを挟める。たとえばEditツールが走る前にlintを強制するとこうなる。
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit",
"hooks": [
{ "type": "command", "command": "npx eslint --fix $CLAUDE_FILE_PATH" }
]
}
]
}
}
ファイルを編集した直後に自動でlint修正が走るので、「直したつもりが崩れていた」という事故が減る。Hooksは地味だが、人間が毎回言わなくていいルールを機械的に強制できるのが強い。
4. Subagentsでコンテキストを汚さない
調査系のタスク(「このリポジトリのAPI一覧をまとめて」など)をメインのやり取りでやると、コンテキストが調査結果で埋まって肝心の実装の質が落ちる。.claude/agents/以下にエージェント定義を置いて分離するとこれが解決する。
---
name: api-explorer
description: APIエンドポイントの調査専用。読み取りのみ。
tools: Read, Grep, Glob
---
リポジトリ内のAPIエンドポイントを列挙し、認証方式とレスポンス型をまとめて返す。
/agentsコマンドで管理・呼び出しができる。調査結果だけが要約されて返ってくるので、メインのやり取りがきれいなまま保たれる。これをやる前と後で、長時間セッションでの「あれ、何してたんだっけ」という迷子感が全く違う。
5. ヘッドレスモードでCIに組み込む
claude -pでワンショット実行ができる。これをCIのPRチェックに組み込むと地味に効く。
claude -p "この差分にSQLインジェクションのリスクがあれば指摘して" \
--output-format json > review.json
JSON出力をそのままGitHub Actionsのステップに食わせられるので、人間のレビュー前に一次フィルタをかけられる。ただしこれは「人間レビューの代替」ではなく「一次フィルタ」として使うのが安全。最終承認は必ず人間が見る、という運用ルールにしている。
6. 実際にハマった失敗：権限を絞りすぎて自動化が止まった話
良いことばかり書いたので、ちゃんと失敗談も書く。denyリストを厚くした直後、定期実行のバッチ処理でBash(curl:*)まで巻き込んで拒否設定にしてしまい、外部APIを叩く処理が毎回止まるようになった。原因は「危険そうなコマンドは全部deny」という雑な発想で、本来許可すべきcurlの中でも社内API向けの固定ホストだけは通すべきだった。
{
"permissions": {
"allow": ["Bash(curl https://internal-api.example.com/*)"],
"deny": ["Bash(curl:*)"]
}
}
こう直してから解決した。学びは「denyは広く、allowはピンポイントに」の順で書くこと。順番と粒度を間違えると、安全にしたつもりで業務が止まる。これはAI活用の「あるある」として、今Qiitaで伸びているSecurityタグの記事群でも同じ論点が繰り返し出ている印象がある。
7. Claude Code / GitHub Copilot / Cursor、実務でどう違うか
同じプロジェクトで3つとも使った感触を正直に書く。
| 観点 | Claude Code | GitHub Copilot | Cursor |
|---|---|---|---|
| 得意なこと | 複数ファイルにわたる大きめのリファクタ、CLI常駐での自律タスク | エディタ内の1行〜数行の補完、既存コードの延長入力 | エディタ統合のチャット型編集、差分プレビューの見やすさ |
| 権限制御の細かさ | settings.json/hooksで細かく制御できる | ほぼ補完提案の採用/不採用のみ | プロジェクト単位の設定はあるが粒度はCLIほど細かくない |
| CI/自動化への組み込み | ヘッドレスモード(-p)で組み込みやすい |
基本は組み込み向きではない | ベータ機能あり、CLI単体での柔軟さはやや劣る |
| 向いている人 | ターミナル常駐で大きめの作業を任せたい人 | とにかく書くスピードを上げたい人 | エディタのUIでAIと対話しながら書きたい人 |
どれが「上位互換」という話ではなく、常駐して大きめの作業委任をしたいならClaude Code、エディタでの補完速度重視ならCopilot、UIで対話しながら細かく直すならCursor、という役割分担で併用するのが実際のところ一番効率が良い。
8. SESとフリーランス、単価と年収をどう比較するか
ここからは記事の本題から少し外れるが、SESで働きながらClaude Codeのような自律的に動くツールを使えるようになると、「このスキルセットなら独立しても案件は取れるのでは」と考える瞬間が増える。SESフリーランス転向を考えるときに整理すべき軸を、具体的な数字を盛らずに並べる。
正確な単価や年収の相場は時期・スキル・契約形態で大きく変わるので、この記事では固定の数字は出さない。代わりに、転向前に自分で確認すべき比較項目を挙げる。
- SESの年収は「固定給+昇給ペース」で決まる。会社の評価制度に依存するため、個人の市場価値と給与が一致しないことがある。
- フリーランスの単価は「契約ごとの月額」で決まる。スキルと直近の実績が単価にそのまま反映されやすいが、稼働率が落ちると年収も落ちる。
- 比較するなら、SESの年収を「月額換算」に直し、フリーランスの単価から税金・保険・稼働していない月のリスクを引いた「実質月額」と並べるのが公平。
- 現在の相場感を知りたい場合は、レバテックフリーランス・ミッドワークス・PE-BANKなど複数のフリーランスエージェントが公開している単価レンジを、同じ職種・同じ年数条件で比較するのが一番確実。1社だけの提示額を相場だと思わない。
SESフリーランス比較で一番やってはいけないのは、「SESの基本給」と「フリーランスの最高単価」を比べること。見るべきは、1年を通した実質的な年収ベースの比較であり、ここを揃えないと判断を誤る。
9. 保存用：SESからフリーランス転向を考える前のチェックリスト
後で見返せるように、チェックリスト形式でまとめる。
| # | 確認項目 | チェック |
|---|---|---|
| 1 | 直近3つの案件で使った技術スタックを棚卸しできているか | ☐ |
| 2 | 複数のフリーランスエージェントに単価の目安を聞いたか(1社だけで判断しない) | ☐ |
| 3 | 稼働が途切れた月の生活費を何ヶ月分確保できているか | ☐ |
| 4 | 確定申告・インボイス対応の実務フローを理解しているか | ☐ |
| 5 | 現在のSESの年収を月額換算し、フリーランス単価の実質月額(税・保険・空白月込み)と並べて比較したか | ☐ |
| 6 | 契約形態(準委任/請負)の違いと自分の責任範囲を理解しているか | ☐ |
| 7 | 自分が得意なのは「要件に沿って書く」か「要件から設計まで任される」か把握しているか | ☐ |
| 8 | 今の常駐先がフリーランス転向後も発注元になり得るか確認したか | ☐ |
| 9 | AIコーディングツール(Claude Code等)の活用で、一人でもチーム分の生産量を出せる自信があるか | ☐ |
| 10 | 転向後1年目は収入が安定しない前提でキャッシュフローを組んでいるか | ☐ |
この表は保存して、エージェントとの面談前に埋めてから話すと、相場の話が具体的になりやすい。
10. 年次別スキルロードマップ：1年目/3年目/5年目で何が変わるか
SESでの経験年数によって、フリーランス転向時に武器になるスキルは変わる。これも一般化した型として整理する。
| 経験年数 | 強み化すべきスキル | フリーランス転向時の立ち位置 |
|---|---|---|
| 1年目 | 言われた仕様を正確に実装しきる力、テストを書く習慣、Gitフローの理解 | まだ早い。SES内で複数プロジェクトを経験してから検討 |
| 3年目 | 要件の曖昧な部分を自分で詰められる設計力、AIツールを使った開発速度の最大化 | 単価勝負に乗れる最低ライン。得意領域(インフラ/フロント/データ)を一つ明確にする |
| 5年目 | チーム全体の生産性を上げる仕組み作り(レビュー基盤、CI、AIエージェント運用) | 技術顧問・PM的な役割も含めた単価設定ができる段階 |
経験が浅いうちに単価だけを見て転向すると、案件が切れたときの立て直しが難しい。逆に5年目以降は、年収ではなく「どれだけの裁量と単価で仕事を選べるか」が比較の軸になっていく。
まとめ
Claude CodeはCLAUDE.md・permissions・hooks・subagents・ヘッドレスモードを組み合わせると、単なる補完ツールから「自律的に動く開発メンバー」に近づく。ただし権限設計を雑にやると、安全にしたつもりで自動化が止まるような事故も起きる。SESからフリーランスへの転向も同じで、単価や年収を一面だけ切り取って比較すると判断を誤る。どちらも「仕組みを雑に作らない」という一点に尽きる。
関連記事
- Cloudflareでほぼ0円のページ内検索を作る｜SESからフリーランス転向で年収を上げる方法
- OpenClaw×Claude Code連携実践ガイド｜SESエンジニアの独立準備と単価戦略
- 月商250万円の3人会社、Claude CodeでAI経営OSを内製した記録
AI駆動塾 — AIを使ったスモビジの作り方を学ぶ
Claude Code、OpenClaw、AI経営OSの実践ノウハウを毎週公開中。
月額¥4,980で過去記事すべて読み放題。
💼 フリーランスエンジニアの案件をお探しですか？
SES解体新書 フリーランスDBでは、高単価案件を多数掲載中です。
- ✅ マージン率公開で透明な取引
- ✅ AI/クラウド/Web系の厳選案件
- ✅ 専任コーディネーターが単価交渉をサポート