ジュニアもベテランも、同じ Claude Code の設定でいいんだろうか。
チームに Claude Code を展開したとき、ふとそう思った人はいるはずだ。ベテランエンジニアには余計な解説は不要で、速度優先が正解。一方で入社したばかりのジュニアには、コードを書きながら「なぜこの実装を選んだか」を同時に学んでほしい。同じ AI をチーム全員に配っているのに、その使い方が人によってバラバラでは、せっかくの投資が個人の努力で終わってしまう。
Output Styles は、その問いへの回答として設計された機能だ。単純な「カスタマイズ機能」ではなく、チームの中で Claude の振る舞いを統一する仕組みとして使える。EM 視点でその設計思想と使い方をまとめた。
Output Styles とは何か
Output Styles は Claude Code の応答スタイル（役割・トーン・出力フォーマット）をシステムプロンプトレベルで切り替える仕組みだ。CLAUDE.md がプロジェクトのルール・コンテキストを読み込む仕組みなのに対して（CLAUDE.md 設計の詳細はこちら）、Output Styles は Claude 自体の「人格」をまるごと差し替える。
組み込みスタイルは4種類ある。
| スタイル | 特徴 |
|---|---|
| Default | ソフトウェアエンジニアリングタスクを効率的にこなす標準モード |
| Proactive | 即実行・推測で進む積極的モード。Auto Mode 相当の判断をするが permission mode は変わらない |
| Explanatory | コードを書きながら "Insights"（実装選択の理由・パターン解説）を挟む学習支援モード |
| Learning | Claude がコードに TODO(human) マーカーを残し、ユーザーが穴埋めする協調学習モード |
Proactive は Auto Mode との関係がよく混同される。Auto Mode の詳細にある通り、Auto Mode は承認プロンプト自体を減らすパーミッション設定だ。Proactive は承認プロンプトは出たままで、Claude 側の判断を積極的にする、というちがいがある。
/config で切り替える、次のセッションから反映される
切り替え方は /config を開いて「Output style」から選ぶだけだ。設定は .claude/settings.local.json に保存される。直接書く場合はこうなる。
{
"outputStyle": "Explanatory"
}ひとつ押さえておきたいのが反映タイミングで、変更は次のセッション起動時に反映される。セッション途中で切り替えても反映されない。
これは意図的な設計だ。Output Styles はシステムプロンプトに書き込まれる。セッション中にシステムプロンプトが変わるとプロンプトキャッシュが破棄されるため、コストが跳ね上がる（プロンプトキャッシュの仕組みはこちら）。次のセッション起動まで変更を遅らせることで、キャッシュを安定させている。
カスタム Output Style を作る
組み込み4つで足りない場合は、Markdown ファイルを置くだけでカスタムスタイルを定義できる。
---
name: Strict Reviewer
description: セキュリティと可読性を最優先にするコードレビュアー
keep-coding-instructions: true
---
When reviewing code, prioritize security vulnerabilities, edge cases,
performance implications, and readability — in that order.
End every review with a numbered list of action items.
（レビュー時は、セキュリティの脆弱性・エッジケース・パフォーマンス・可読性の順に優先する。
最後に番号付きのアクションリストで締める）配置場所はユーザースコープなら ~/.claude/output-styles/、プロジェクトスコープなら .claude/output-styles/ だ。チームで共有するなら後者をリポジトリに置けば全員が使える。
frontmatter の keep-coding-instructions は重要なフィールドだ。true にすると Claude Code 本来のコーディング指示を残しつつ、スタイルを上書きする。コードレビュアー・ダイアグラム優先など「コーディングはするが口調やフォーマットを変える」場合は true。一方、ドキュメント執筆支援やデータ分析専用など「ソフトウェアエンジニアリング自体をしない役割」に切り替える場合は false（省略するとデフォルトで false）を選ぶ。
CLAUDE.md / --append-system-prompt / Skills / Subagent との使い分け
Output Styles は Claude Code のカスタマイズ手段の中でも「システムプロンプトをまるごと差し替える」という点でユニークだ。他の手段との関係を整理しておく。
| 手段 | 仕組み | 向いている用途 |
|---|---|---|
| Output Styles | システムプロンプトを書き換える | 役割・トーン・デフォルトフォーマットを毎回変えたい |
| CLAUDE.md | システムプロンプト後にユーザーメッセージとして追加 | プロジェクト規約・コードベース文脈を毎回読ませたい |
--append-system-prompt | 既存のシステムプロンプトに追記（何も削除しない） | 単発の起動で1回限りの追加指示を渡したい |
| Skills | 必要なときにタスク固有の指示をロード | 再利用可能なワークフローを使い分けたい（Skill 設計の詳細） |
| Subagent | 専用システムプロンプト・モデル・ツールで独立実行 | フォーカスしたタスクを別スコープで走らせたい |
判断の分岐点は「セッション全体を通して有効にしたいか」だ。役割ごとに Claude の振る舞いそのものを変えたい場合が Output Styles、特定の指示をその場だけ追加したい場合は Skills、プロジェクト固有のルールを常に読ませたい場合は CLAUDE.md、という分け方がしっくりくる。
EM がチームで使う想定シナリオ
Output Styles を「個人設定」で終わらせないために、EM がチームに展開する具体的な使い方を考えてみた。
ジュニアメンバーへの Explanatory 標準化
オンボーディング期間中、ジュニアメンバーのローカルに .claude/settings.local.json を配布して "outputStyle": "Explanatory" に固定する。Claude がコードを書きながら「なぜこの実装を選んだか」を Insights として差し挟んでくれるので、手動でペアプログラミングをしなくても学習効果が出る。ベテランは Default のまま速度優先、という使い分けが自然にできる。
Learning モードはさらに踏み込んで、Claude が TODO(human) マーカーを残してユーザーに穴埋めを求める。受動的に AI に任せるのではなく「自分で手を動かす」学習スタイルを強制できる点が特徴だ。
チームリポジトリに Strict Reviewer を置く
.claude/output-styles/strict-reviewer.md をリポジトリに追加してチーム全員で使えるようにする。コードレビュー依頼のたびに毎回プロンプトを書き直すのではなく、スタイルを切り替えるだけで「セキュリティ・エッジケース・可読性を優先した厳格なレビュアー」として動かせる。
ドキュメント執筆専用スタイル
技術文書を書かせるときはコーディング指示が邪魔になることがある。keep-coding-instructions: false にした Tech Writer スタイルを置いておけば、アーキテクチャ設計書や ADR を書かせる際に「コードを書こうとする」挙動を抑えられる。
コストと運用上の注意
Explanatory と Learning は設計上、Default より長い応答を返す。入力トークンはシステムプロンプト追加分で増え、出力トークンも増える。
ただしプロンプトキャッシュの恩恵はしっかり受けられる。セッション内では2回目以降のリクエストからシステムプロンプト分がキャッシュに乗る。Output Style を切り替えるとキャッシュはリセットされるが、1日中同じスタイルで使う運用なら初回の1リクエスト分しか余分なコストはかからない。
チーム展開時に気をつけたいのは「全員が同じスタイルでいい」という前提を疑うことだ。ジュニアに Explanatory は有効でも、ベテランに同じ設定を押しつけると「余計な解説が邪魔」という不満が出る。ユーザースコープ（~/.claude/output-styles/）とプロジェクトスコープ（.claude/output-styles/）を使い分けながら、個人が上書きできる余地を残す設計が無難だ。
まとめ
Output Styles は一見「見た目の調整ツール」に見えるが、実態はシステムプロンプトを差し替えて Claude の人格を変える仕組みだ。
EM として使うなら、「誰のために、どの人格が必要か」という問いを起点にするといい。ジュニアには学習を促す Explanatory、コードレビューには批評的な Strict Reviewer、ドキュメント作業には Tech Writer。用途ごとに切り替えられる環境をチームに整えておくと、Claude への指示コストが下がり、成果の品質も揃いやすくなる。
まずは .claude/output-styles/ にひとつカスタムスタイルを書いてリポジトリに置いてほしい。それだけで「チームの Claude」が少し統一される。
参考リンク
- Output styles — Claude Code 公式ドキュメント
- Permission modes — Claude Code 公式ドキュメント（Proactive と Auto Mode の関係）
- Skills — Claude Code 公式ドキュメント（使い分け比較）
コメント