同じClaude Code、役職で使い方が変わる — EM/シニア/ジュニア/QAの活用マップ

なぜ役職で使い方が変わるのか

Claude Codeの解説記事を読んでいると、どれも「全エンジニア向け」の内容になりがちです。機能の説明はある、使い方のサンプルもある。でも実際に手を動かそうとしたとき、「自分の仕事に当てはめたらどうなるんだろう」と止まった経験はないでしょうか。

EMとジュニアエンジニアでは、そもそも「片づけたいジョブ」が違います。EMはチーム全体のコスト感や権限設計を気にしますが、ジュニアエンジニアは目の前のエラーをどう読み解くかに集中しています。同じ道具でも、用途が違えば使い方は変わる。それは当然です。

EM・シニアエンジニア・ジュニアエンジニア・QAという4つの役割を起点に、それぞれがどの機能を使うべきか、逆に何を避けるべきかを見ていく。「自分の役職」のセクションだけ読んでもらえれば、今日から具体的なアクションに落とし込めるはずです。

EM（エンジニアリングマネージャー）— 個人ではなくチームに設定を効かせる

EMがClaude Codeを使うとき、自分だけが上手く使えても組織への投資対効果は出ない。関心はチーム全体への展開に向くのが自然です。

Managed Settings でポリシーを配布する

Managed Settingsは、組織単位でClaude Codeの権限設定を配布できる機能です。.claude/settings.json をリポジトリ管理することで、メンバーが個別にいじれない設定を強制できます。「誰かが --dangerously-skip-permissions を有効にしてしまった」というトラブルを防ぐには、この仕組みを最初に設計するのが先です。セキュリティ運用の詳細はこちらの記事で解説しています。

Auto Mode でチームの操作ミスをガードする

個人開発では「YOLO Mode」的な使い方も選択肢に入りますが、チーム展開では Auto Mode を標準にする方が安全です。Auto ModeはClaudeが自律的に動く範囲をコントロールしつつ、毎回の確認ステップを省けるため、チームの習熟度が揃っていない時期に適しています。

/cost と /usage でコストを可視化する

Claude Codeのチーム利用は、使い方次第でコストが膨らみます。/cost コマンドで現在のセッションコストを確認し、/usage でプロジェクト全体の消費量を把握する習慣をチームに根付かせましょう。Statuslineに常時表示する設定を入れておくと、メンバー自身が意識しやすくなります。

「自分が便利だから」という理由で --dangerously-skip-permissions をチームに展開するのだけは避けてほしい。EM個人の経験値と、チーム全体のリスク許容度は別物です。

シニアエンジニア — AIをペアプログラマーに育てる

シニアエンジニアにとって、Claude Codeは「コードを書いてもらう道具」よりも「自分の思考を整理する相手」として機能しやすい。ただし、AIの出力を批判的に評価する目を手放すと、その価値は一気に下がります。

1M Context でモノレポ全体を読み込む

大規模なコードベースを扱うシニアエンジニアにとって、1Mコンテキストウィンドウは実用的な武器になります。モノレポ全体を読ませながらアーキテクチャの質問をすると、個別ファイルを渡したときとは質の違う回答が返ってきます。「このサービス全体でどこに密結合が生じているか」という問いは、コンテキストが広いほど精度が上がります。

Plan Mode で設計フェーズを分離する

大規模なリファクタリングをClaude Codeに依頼するとき、いきなりコード変更をさせるのはリスクがあります。Plan Modeを使えば、Claudeは変更計画だけを返し、実際のファイル操作は行いません。計画を確認してから実行に移す、という手順を守るだけで、想定外の変更が紛れ込む可能性を大きく減らせます。

ultrathink で深い思考を引き出す

設計判断の分岐点で使いたいのが ultrathink キーワードです。プロンプトに含めると、そのターンだけ深い推論を引き出すin-context指示を追加する公式の制御方法です。セッションのエフォートレベル設定自体は変わらないため、「このAPIの設計、どちらのアプローチが長期的に持続可能か」といった問いで一度だけ深く考えさせたい場合に有効です。Effort制御の詳細はこちら。

Subagent で探索と実装を分ける

PlanモードのSubagentを活用すると、「まずコードベースを探索するだけ」というフェーズを別コンテキストで走らせられます。探索結果を受け取ってから実装方針を決める、というワークフローはシニアエンジニアの設計プロセスに合いやすいです。

「自分の経験でわかるから」とAIの提案を深読みせずに承認する癖がつくと、シニアとしての判断力が鈍る。AIの出力はドラフトです。最終的にドメイン知識を介在させるのが、シニアがいる理由です。

ジュニアエンジニア — 依存ではなく成長のツールとして使う

ジュニアエンジニアがClaude Codeで最も気をつけたいのは、「考える機会を奪われること」です。コードを生成してもらって動いた、で終わらせると、次に似た問題が出たとき一人で対処できない。使い方を工夫すれば、Claude Codeは成長を加速する道具になります。

Output Styles の Learning モードで穴埋め式に学ぶ

Output StylesのLearningモードを設定すると、Claudeは完成したコードを渡す代わりに TODO(human) のプレースホルダーを差し込んだ形で出力します。「ここは自分で実装してみて」という状態を作り出せるため、コードを読んで理解するだけでなく、自分の手で動かす機会が生まれます。

Plan Mode で実装前に計画を確認する

ジュニアエンジニアにとってPlan Modeの価値は、「実装の全体像を先に見渡せること」にあります。Claudeに計画を作ってもらい、それを自分の言葉で説明できるか確認してから実装に入る。このステップを挟むと、コードの意図を理解した上で進められます。

Auto Memory でプロジェクト知識を蓄積する

同じ説明を毎回しなくて済むように、CLAUDE.mdとAuto Memoryを活用しましょう。「このプロジェクトのコーディング規約」「よく使うAPIのエンドポイント」「テストの実行方法」を記録しておくと、Claudeが文脈を保持した状態で応答してくれます。先輩への質問を減らしたいなら、まず自分の作業パターンを言語化してCLAUDE.mdに書き落とすことから始めると効果的です。

AIが書いたコードを動作確認なしにコミットすること、「なぜそうなるか」を理解せずに次へ進むこと。この2点は本当に気をつけてほしい。Claude Codeはコードを書いてくれますが、そのコードへの責任はコミットした人間が持ちます。

QA — テスト自動化とバグ追跡に使う

QAエンジニアがClaude Codeを使うなら、テストケース生成とE2E自動化の効率化から入るのが一番早い。ただし、生成されたテストをそのまま採用する運用は危険です。

Chrome MCP でブラウザE2Eを自動化する

Chrome MCPを使うと、ブラウザ操作をClaude Codeから直接制御できます。フォームの入力、ボタンのクリック、画面遷移の確認といった手動E2Eテストの手順をClaudeに実行させ、その結果をテストスクリプトとして書き出す、というワークフローが組めます。

Hooks でコミットごとにテストを走らせる

PostToolUse Hookを設定すると、Claudeがファイルを変更するたびにテストを自動実行できます。「変更 → 自動テスト → 結果確認」のサイクルを手動で回す必要がなくなり、回帰バグの早期発見につながります。

/goal コマンドで自動修正ループを回す

「すべてのテストがGreenになる」という条件を /goal コマンドで設定すると、Claudeは目標を達成するまで修正と実行を繰り返します。バグ修正の試行錯誤をClaudeに任せつつ、最終的な修正内容を人間が確認する、という分業が可能になります。

AI生成テストはコードの「形」を見ると整っているが、エッジケースが薄い。ハッピーパスは書いてあっても、境界値や異常系が抜けがちなのはAI生成テストの典型的な弱点なので、そこを重点的に確認してほしい。

役職横断の共通ルール

役職が違っても、Claude Codeを使う上で変わらないルールがあります。

権限設計は最初に決める

--dangerously-skip-permissions は後から使い始めると組織に定着しやすいため、最初の段階でAuto Modeを標準にする設計をしておきましょう。権限設計の後付けは手間がかかります。

CLAUDE.md は200行以下に保つ

CLAUDE.mdに書けば書くほど良い、というわけではありません。コンテキストが膨らみすぎると、Claudeの応答品質が下がります。役職や用途別の設定は別ファイルに分離し、CLAUDE.md本体は核となる情報だけを置くのが原則です。

/cost を習慣にする

コスト意識は個人レベルでも重要です。セッション開始時と終了時に /cost を確認し、どの作業がどの程度のコストを発生させているかを把握することが、適切な使い方への近道です。

AIの出力を鵜呑みにしない

これはどの役職でも共通です。Claude Codeは優秀な補助者ですが、最終判断は人間が下すという原則は変わりません。AIの提案を受け入れる前に、「自分の言葉で説明できるか」を確認する習慣を持つと、依存度を適切にコントロールできます。

まとめ — 役職別のスタートポイント比較

各役職ごとの使い方を下にまとめました。自分の役職の行だけ確認してもらえれば十分です。

EMなら、まずManaged Settingsでチームのポリシーを固めてから個別機能に手を伸ばしてください。シニアエンジニアは次の設計レビューでPlan Modeを試すだけでいい。ジュニアエンジニアはOutput StylesをLearningモードに変えてみると、翌日から使い方が変わります。QAは既存のE2Eテスト1本をChrome MCPで再現するところから始めると、やり方がつかめます。

「Claude Codeを導入した」の次は、「自分の役職で何をどう使うか」を決めるだけです。全部の機能を使いこなす必要はありません。自分のジョブに刺さる機能を1つ選んで、手を動かしてみてください。