Claude Codeのoutput styleを業務別に選ぶ

結論：まず/configで選び、共有範囲はsettingsと分けて決める

根拠はClaude Code公式changelog、公式Output styles、公式settingsです。この記事は新しい見た目の紹介ではなく、開発・レビュー・教育でどの形式を選び、どの範囲へ配るかを決める手順に絞ります。

5つの組み込みstyleを比較する

style	向く場面	確認するリスク
Default	通常の実装と調査	人によって説明量がぶれる
Proactive	定型的な作業を先へ進める	自動実行を許可する機能ではない
Concise	結果・差分・次の一手を短く読む	前提や注意の読み落とし
Explanatory	設計理由を学習・共有する	長文化と出力tokenの増加
Learning	学習者が小さく実装する	納期作業には確認往復が増える

公式文書では、Output styleはClaudeが知っている内容を変えず、指示・役割・出力形式を変えると説明されています。Proactiveはpermission modeを変えず、Conciseでもエラー、セキュリティ警告、破壊的操作の確認は省略されません。LearningはTODO(human)を含めて共同作業を促すため、教育には便利でも緊急修正の既定値にはしません。

設定の保存先と優先順位を確認する

ターミナルの/configで選択すると、公式文書上はプロジェクトローカルの.claude/settings.local.jsonへ保存されます。直接設定する場合は{"outputStyle":"Concise"}のように記述します。共有プロジェクトの.claude/settings.json、ユーザー設定、managed settings、コマンドライン指定が同じキーを持つ時は、どのsourceが勝つかを現在のバージョンで確認します。ローカル設定をGitへ不用意に含めると、個人の実験がチームの標準になるためです。

styleファイルを自作する場合はMarkdownのfrontmatterと指示文で構成します。開発を続けながら口調だけ変えるならkeep-coding-instructions: trueを検討します。開発者ではない文書作成へ転用するなら組み込みのcoding instructionsを残すか、完全に外すかを明示します。ネストした.claude/output-styles/では、作業ディレクトリに近い定義が同名styleを上書きするため、同名ファイルの存在も検査対象です。

導入手順：業務別にstyleを選ぶ8ステップ

1. claude --versionと/configの表示を記録し、2.1.269以降のchangelog記載と手元の実装差を確認します。
2. 対象業務を実装、レビュー、障害対応、教育の4分類に分け、求める回答の長さと必須警告を一文で定義します。
3. 各分類へDefault・Concise・Explanatory・Learningの候補を一つずつ割り当て、Proactiveは作業の承認境界を別に記録します。
4. 個人のsettings.local.jsonで一件の非破壊タスクを実行し、回答量、判断の抜け、次の操作、入力tokenを保存します。
5. 同じprompt、同じrepository、同じpermission modeでstyleだけを変更し、結論・警告・差分説明を比較します。
6. 共有する場合は.claude/settings.json、managed settings、custom output-stylesのどこが正本かを決め、変更承認者を置きます。
7. 長文のExplanatoryと短文のConciseを同じ費用・品質指標で一週間測り、出力文字数だけで優劣を決めません。
8. rollbackとしてDefaultへ戻す方法、styleのversion、適用日、例外申請、レビュー担当をREADMEへ残します。

既存の組織ポリシー診断やsystem promptの検証と同じく、設定が読めたことと、意図した回答が得られたことを分けて判定します。subagentは別のsystem promptで動くため、親のOutput styleがそのまま全subagentの動作を決めると仮定しません。必要ならsubagent指示のファイル化で別の正本を作ります。

料金・制限・レビューを混同しない

Output style固有の固定料金があるという公式情報は確認できません。公式文書はstyleの指示文が毎回のrequestに送られ、入力tokenへ影響し、prompt cachingで初回以降のコスト影響が変わることを説明しています。ExplanatoryやLearningは回答が長くなりやすい一方、Conciseでも作業内容そのものは省略されません。モデル料金、利用プラン、Gatewayやproviderの請求条件は別の公式pricingを公開直前に確認し、styleを選ぶだけで費用が一定割合下がるとは書きません。

制限面では、Output styleはpermission modeを昇格させず、ファイル変更や外部送信の承認を自動で付与しません。style内の指示がチームの安全ルールと衝突しないよう、秘密情報を出力しない、破壊操作には停止する、検証結果を記録する、といった規約をCLAUDE.mdやmanaged policyへ置きます。styleで権限の代わりをしようとする設計はHOLDです。

チェックリスト：チーム標準へ入れる前に

□対象業務と読者が定義されている　□versionと対応commandを記録した　□styleは回答形式の変更だと説明した　□permissionとstyleを別管理した　□保存先と優先順位を確認した　□同じpromptで比較した　□警告と破壊操作の確認を検証した　□入力・出力tokenを実測した　□subagentとforkの挙動を確認した　□共有正本・承認者・rollback日を決めた。

よくある質問

Output styleはどこに保存されますか？

ターミナルで選ぶ場合は公式文書上、プロジェクトローカルの.claude/settings.local.jsonです。共有設定へ移す時は、個人の実験をそのままcommitしないでください。

Output styleは権限を広げますか？

広げません。回答の指示と形式を変える機能で、permission modeやmanaged settingsによる制御とは別です。

Conciseなら必ず安くなりますか？

必ずではありません。styleの指示文、キャッシュ、作業量、出力内容を同じ条件で測定します。

公式情報と無料診断

正式名称、command、対応versionは公式changelog、利用方法はOutput styles、適用範囲はsettingsを公開直前にreadbackしました。Miraigentの無料診断では、style、権限、レビュー、費用計測を業務単位の導入表へ整理します。