Claude Codeのoutput styleが効かない・反映されない原因を、公式ドキュメントとGitHub Issue実例で整理した
output styleを設定したのに反映されない、`/output-style`コマンドが見当たらない、カスタムスタイルを作ったらコーディング規約ごと消えた——といった症状を、公式ドキュメントと未修正のGitHub Issue実例から原因別に整理。Concise styleの追加(v2.1.237)まで含めて2026年8月時点の状況をまとめた。
エンジニアのゆとです。
Claude Codeのoutput styleを設定したのに応答の口調が変わらない。/output-styleと打ってもコマンドが見つからない。あるいはカスタムスタイルを作ったら、なぜかコードの品質確認や差分の説明までしなくなった——output styleを触るとこの手の「設定したはずなのに」に高確率で当たる。
結論から言うと、原因は大きく3つに分かれる。ひとつは/output-styleコマンド自体が2026年に廃止されて/configに統合されたという仕様変更、もうひとつはカスタムスタイルが既定でClaude Codeの標準的なエンジニアリング指示を丸ごと上書きしてしまうという設計上の罠、そして残りはまだ直っていない複数のGitHub Issueで報告されているバグ群だ。この記事では公式ドキュメントの情報と、Anthropicのリポジトリで実際に報告されている未修正・修正待ちのIssueを突き合わせて、症状別に切り分けた。
結論 — 症状別の原因早見表
| 症状 | 原因 | 状態 |
|---|---|---|
/output-styleと打ってもコマンドが存在しない | v2.1.73で非推奨化、v2.1.91で削除済み | 仕様変更（/configを使う） |
/configのOutput styleメニューに自作スタイルが出てこない | ~/.claude/output-styles/のスタイルはピッカーに表示されない既知バグ | 未修正（Issue #85246） |
| YAMLフロントマターを付けたスタイルの本文が全く効かない | フロントマター解析後、本文がシステムプロンプトに注入されないバグ | 未修正・報告多数（Issue #47482） |
| カスタムスタイルにしたらコード確認や差分説明をしなくなった | keep-coding-instructionsが既定でfalseのため標準指示ごと上書きされる仕様 | 仕様（明示的にtrue指定で回避） |
| カスタムエージェント（サブエージェント委任）を使うとスタイルの内容が消える | agent設定がアクティブな時にoutput styleの本文がシステムプロンプトに読み込まれない | 未修正（Issue #88592） |
| 設定を変えた直後は反映されず、しばらくすると効いたり効かなかったりする | カスタムスタイルには組み込みスタイルにあるturnReminder（毎ターン再注入）の仕組みがない | 仕様上の制約（Issue #88189） |
| スタイルで指示したはずの口調・NGワードを結局使ってくる | モデルがoutput style自体の指示に従わないケース | 未修正・報告あり（Issue #86490, #89083） |
| サブエージェントに投げた作業だけスタイルが効かない | サブエージェントは自分のシステムプロンプトで動くため、output styleは適用対象外 | 仕様（forkのみ例外） |
自分の症状がどれに近いか分かったら、該当の見出しまで飛んでもらって構わない。
そもそも/output-styleコマンドが消えている
2026年8月時点でもまだ「/output-styleが使えない」で検索している人が一定数いるが、これはバグではなく仕様変更だ。単体の/output-styleコマンドはv2.1.73で非推奨化され、v2.1.91で完全に削除された。代わりに次のどちらかを使う。
- ターミナルで
/configを実行し、「Output style」の項目からメニューで選ぶ。選択結果は.claude/settings.local.json（プロジェクトのローカルスコープ）に書き込まれる - デスクトップアプリの場合は設定ファイル（同じく
.claude/settings.local.jsonなど）のoutputStyleフィールドを直接編集する。デスクトップから/configを開いた場合はメニューではなく通常の設定画面（Settings > Claude Code）に遷移する
メニューを使わず直接指定したい場合は、該当スコープの設定ファイルに次のように書けばいい。
{
"outputStyle": "Explanatory"
}ここで見落としやすいのが、output styleはシステムプロンプトの一部としてセッション開始時に一度だけ読み込まれるという点だ。設定ファイルを書き換えただけでは今動いているセッションには反映されない。/clearするか、新しいセッションを開始しない限り古いスタイルのままになる。「設定を保存したのに変わらない」と感じたら、まずここを疑ったほうがいい。
設定した「はず」なのに反映されない — 未修正のバグ実例
古いバージョン情報や勘違いを除外した上で、それでも反映されない場合、以下はいずれも2026年8月時点でAnthropicのGitHub Issueに報告されている、ユーザー側の設定ミスではない既知の不具合だ。バージョンを最新にしても直っていない場合、自分の環境固有の問題ではないと判断していい。
/configのピッカーに自作スタイルが出てこない（Issue #85246）
~/.claude/output-styles/にカスタムスタイルを置くと、そのスタイル自体は正しく読み込まれてアクティブになるにもかかわらず、/configのOutput styleピッカーには組み込みの4つ（Default / Proactive / Explanatory / Learning）しか表示されないという報告がある。/config outputStyle=まで打って補完を出しても、選択肢に自作スタイルの名前が出てこない。実際には効いているのにピッカー上は選べないように見えるため、「設定できていない」と誤解して延々と原因を探してしまうケースがある。
YAMLフロントマターを付けると本文が注入されない（Issue #47482）
公式ドキュメントは「カスタムoutput styleはフロントマターと、システムプロンプトに追加される本文で構成されるMarkdownファイル」と説明しているが、実際にはフロントマターの解析後、---以降の本文がシステムプロンプトに注入されないという報告がある。スタイル名自体はステータスラインや/configには正しく表示されるため一見動いているように見えるが、肝心の指示内容が読み込まれていない。このIssueは38件のコメントが付くほど再現報告が多い。フロントマターを丸ごと外すと直るという回避策が報告されているが、その場合nameやkeep-coding-instructionsが指定できなくなる。
カスタムエージェントを併用するとスタイル本文が消える（Issue #88592）
~/.claude/settings.jsonでagent（カスタムサブエージェントへの委任設定）とoutputStyleを同時に設定していると、セッションはoutput styleがアクティブだと報告し続けるのに、実際のシステムプロンプトにはそのルール本文が含まれない、という組み合わせ限定のバグが報告されている。単体では正常に動くため、複数のカスタマイズ機能を重ねて使っている人ほど気づきにくい。
カスタムスタイルは組み込みスタイルより「弱い」(Issue #88189)
組み込みのoutput style（Concise・Proactiveなど）は、セッション開始時に注入されるpromptに加えて、ユーザーの発言やツール結果のたびに再注入されるturnReminderという2段構えの仕組みを持っている。一方でファイルベースのカスタムスタイルはpromptだけしか持てず、turnReminderを設定する手段がない。つまり会話が長くなるほど、カスタムスタイルの指示は薄れていきやすい構造になっている。これはバグというより設計上の非対称性で、Issue上でも「バグを修正するというより、カスタムスタイルにもturnReminderを持たせる機能追加として扱うべき」という議論になっている。
スタイルの指示自体を無視される(Issue #86490, #89083)
スタイルが正しく読み込まれていることが/context等で確認できても、モデルがその指示に従わないという報告も複数ある。あるIssueでは、禁止用語の指定や簡潔な応答を求める設定をしても、モデルが結局同じ言い回しを使い続けたと報告されている。読み込みの問題ではなく遵守の問題なので、設定ファイルをいくら見直しても解決しない。現状では「効かないことがある」という前提で、重要な制約は出力後にレビューする運用でカバーするしかない。
カスタムスタイルを作ったらコーディング規約ごと消えた話
バグではなく、仕様を知らずに踏む罠としてはこれが一番影響が大きい。
カスタムoutput styleは、指定した指示をシステムプロンプトに追加するだけでなく、Claude Codeが標準で持っている「変更範囲を適切に絞る」「コメントの付け方」「作業内容を検証する」といったソフトウェアエンジニアリング向けの指示を、既定では丸ごと除外してしまう。keep-coding-instructionsというフロントマターのデフォルト値がfalseだからだ。
これによって実際に起きる症状が、「差分が中途半端なまま終わる」「変更の検証をしない」「コメントの付け方が雑になる」「変更範囲が広がりすぎる」といった、口調やフォーマットの問題ではなくエンジニアリング品質そのものの劣化だ。「カスタムのoutput styleを入れてからClaude Codeの仕事が雑になった」と感じたら、口調の好みの問題ではなくこの仕様が原因である可能性が高い。
回避策はシンプルで、フロントマターに1行足すだけで直る。
---
name: Diagrams first
description: 説明の前にMermaid図を出す
keep-coding-instructions: true
---
コード・アーキテクチャ・データフローを説明するときは、必ず最初にMermaid図（flowchart TDまたはsequenceDiagram、15ノード以内）を出してから文章で説明する。判断基準は公式ドキュメントの言い方がそのまま使える。「Claudeのコミュニケーションの仕方を変えたいだけで、コーディング作業自体は続けさせたい」ならkeep-coding-instructions: trueを付ける。「Claudeにそもそもソフトウェアエンジニアリングをさせるつもりがない」（文章作成アシスタントやデータ分析役として使う場合など）なら付けない。プロジェクト固有の規約そのものを常に読ませたいなら、output styleではなくCLAUDE.mdに書くべき情報だという切り分けも重要になる。
組み込み5スタイルの使い分けとConciseの追加
2026年8月20日リリースのv2.1.237で、組み込みスタイルにConciseが追加され、選択できる組み込みスタイルは5つになった。それぞれの役割は次の通り。
- Default: 既存の標準システムプロンプトそのもの。ソフトウェアエンジニアリングタスクを効率よくこなすためのデフォルト
- Concise（v2.1.237以降）: 前置きや実況を省き、結論から答える。ただしエンジニアリングの丁寧さはDefaultと同水準を維持し、エラー報告・セキュリティ警告・破壊的操作の確認など重要な情報は省略しない。詳しい説明を求めれば通常通り詳しく答える
- Proactive: 定型的な判断で立ち止まらず、妥当な仮定を置いてすぐ実行する。Auto Modeより踏み込んだ自律実行の指示だが、パーミッションモード自体は変更しないため、実際に何が実行されるかはパーミッションモードの設定に従う
- Explanatory: 作業の合間に「Insights」として実装判断やコードベースのパターンを解説してくれる
- Learning: Explanatoryに加えて、コードの一部を
TODO(human)として自分で書かせる、協働学習型のモード
Conciseが追加された背景には、「Claude Codeの応答は前置きと実況が長すぎる」という不満が以前からコミュニティで多く上がっていた事情がある。結論を急ぎたい実務ではConciseを既定にし、コードベースへの理解を深めたい場面だけExplanatory/Learningに切り替える、という使い分けが現実的だ。
なお出力トークン量への影響も一様ではない。Explanatory・Learningは設計上Defaultより長い応答を生成するため出力トークンが増え、Conciseは逆に短くする方向に働く。カスタムスタイルの場合はどちらに転ぶかは指示内容次第になる。
CLAUDE.md・--append-system-prompt・Agentsとの使い分け
output styleと役割が近い機能が複数あるため、公式ドキュメントの比較表をもとに整理しておく。
| 機能 | 仕組み | 向いている場面 |
|---|---|---|
| Output styles | システムプロンプトを直接書き換える | 毎回のやり取りで役割・口調・出力フォーマットを変えたい時 |
| CLAUDE.md | システムプロンプトの後にユーザーメッセージとして追加される | プロジェクトの規約やコードベースの文脈を常に知っていてほしい時 |
--append-system-prompt | 既存のシステムプロンプトに何も削除せず追記する | 1回の実行だけ一時的に指示を追加したい時 |
| Agents（サブエージェント） | 独自のシステムプロンプト・モデル・ツールを持つ別セッションを走らせる | 特定タスクだけ切り離して任せたい時 |
| Skills | 呼び出された時・関連する時にタスク固有の指示を読み込む | 再利用可能なワークフローを持ちたい時 |
ここで重要なのが、output styleはメインの会話にしか適用されないという点だ。サブエージェントは自分自身のシステムプロンプトで動作するため、output styleの影響を受けない。例外はfork（現在の会話を分岐させる形の実行）で、これは親のシステムプロンプトをまるごと引き継ぐためoutput styleも維持される。「サブエージェントに投げた作業だけスタイルが違う」と感じたら、バグではなくこの仕様通りの挙動になる。
プラグイン経由でoutput styleを配布することもできる。output-styles/ディレクトリにスタイルファイルを含めれば、プラグインを有効にしただけで自動的にそのスタイルを強制するforce-for-plugin: trueという仕組みもある（複数のプラグインが同時に指定した場合は最初に読み込まれたものが優先される）。
自分の状況を確認する手順
原因を推測で決めつける前に、次の順番で確認すると早い。
claude --versionで現在のバージョンを確認する。/output-styleが使えないだけならv2.1.91以降が原因で仕様通りなので、/configに切り替える/contextを実行し、システムプロンプトの内訳にoutput styleの内容が実際に含まれているかを確認する。ここに現れていなければ、読み込み自体に失敗している/statusで有効な設定ソースを確認し、settings.local.json・settings.json・管理者設定のどのスコープが優先されているかを確認する（ローカル＞プロジェクト＞ユーザーの順で上書きされる）- 設定ファイルを直接編集した場合は、
/clearするか新しいセッションを開始してから再確認する。編集直後の同一セッションには反映されない claude --safe-modeでCLAUDE.md・スキル・プラグイン・フック・MCPサーバーをすべて無効化した状態を試す。この状態でも症状が再現するなら、output style機能自体か組み込みスタイルの問題である可能性が高い- ここまでで解決しなければ、バージョンを明記した上で同じ症状の報告がないかGitHub Issueを検索する
FAQ
/output-styleが非推奨になったのはいつ?
v2.1.73で非推奨化の警告が出るようになり、v2.1.91で完全に削除された。2026年半ばのビルドを使っている場合、コマンド自体がもう存在しない。
カスタムスタイルと組み込みスタイルを両方少しずつ使いたい場合は?
公式にはその仕組みは用意されていない。カスタムスタイルを作る際にkeep-coding-instructions: trueを付けてDefaultのエンジニアリング指示を残しつつ、自分の追加指示を上乗せする形が一番近い。組み込みのConciseやExplanatoryの指示文自体をコピーしてカスタムスタイルに混ぜ込むことも可能だが、turnReminderは再現できないため、組み込みスタイルほど指示が強く効き続けるわけではない点は割り切る必要がある。
output styleを変えるとコストは増える?
ケースによる。カスタムスタイルの指示をシステムプロンプトに足す分、入力トークンは増えるが、セッション内ではプロンプトキャッシュが効くため2回目以降のリクエストへの影響は小さい。出力トークンについては、Explanatory・Learningは設計上長い応答になりやすく、Conciseは逆に短くなる。カスタムスタイルの出力トークン量は指示内容次第で変わる。
途中でoutput styleを変えても平気?
技術的には可能だが、変更が反映されるのは/clearか新規セッションからになる。長時間の作業セッションの途中でスタイルを切り替えても、その場では反映されない点に注意したほうがいい。
まとめ
「Claude Codeのoutput styleが効かない」とひとくくりにされがちな症状は、実際には(1)/output-styleコマンドの廃止という仕様変更、(2)keep-coding-instructionsの既定値による意図しない上書き、(3)フロントマター注入・ピッカー表示・カスタムエージェント併用まわりの複数の未修正バグ、という性質の異なる3系統に分かれている。特に(2)は設定ミスというより仕様の理解不足で踏みやすく、コード品質の劣化という分かりにくい形で症状が出るぶん厄介だ。
反映されないと感じたら、まず/contextでシステムプロンプトに実際に読み込まれているかを確認し、それでも駄目ならclaude --versionを確認した上でこの記事の早見表と照らし合わせてほしい。それでも該当しない場合は、同じバージョンでの報告がないかGitHub Issueを検索するのが結局一番早い。
