ども！最近はペインを何枚も並べてClaude Codeを転がしてる龍ちゃんです。
Claude Codeの返信、長くて読むのがしんどくないですか
聞いたことにはちゃんと答えてくれるんだけど、そこまで詳しく要らなかったな、ってなること。あれ、output styleで変えられます。
公式によると、output styleが変えるのは答え方だけで、知っていることのほうは変わらないそうです。詳しくは公式のOutput stylesドキュメントへ。
今日書くのは、これを作業ごとに、起動のタイミングでセットする運用です。僕は作業ごとにペインを立てていろんな種類の作業をやってるんですけど、「この作業のときはこう答えて」「こっちのときはこう聞くから」って毎回説明し直してたんですよ。それが起動時の一言で済むようになります。最後に、自分で書いた文言が実際の返答をどれくらい変えたかを測った結果も並べます。どのスタイルが正解かみたいな良し悪しの話はしません。（ちょっと遊んだだけなのでｗ）
そもそもoutput styleって、どこに何を書くやつなんでしょうか
変えるのは「答え方」で、「知ってること」じゃないです
output styleは、システムプロンプトを書き換える層です。公式にも「Output styles change how Claude responds, not what Claude knows」と書いてあって、日本語にすると「どう答えるかを変えるだけで、何を知っているかは変えない」ということですね。
CLAUDE.mdやskillに書くのは「この作業ではこれを見ろ」「この規約に従え」みたいな答えの中身を作る側の話で、output styleに書くのは出てきた答えをどう見せるかの話です。ここが混ざると「書いたのに効かない」になるので、僕の中ではこの2つで割り切ってます。
組み込みのスタイルは5つ入っています。
- Default: 今まで通りの、既定のシステムプロンプトです
- Concise: 結論を先に言って前置きを削り、短く返します
- Explanatory: 作業の合間に、学びになる説明を挟んでくれます
- Learning: 学習モードで、コードの一部を
TODO(human)にして自分で書かせてくれます - Proactive: 判断で立ち止まらず、実行を優先します
それぞれの性格とか向き不向きは公式のドキュメントによくまとまってるので、そちらに譲ります。
ずっと同じスタイルで使いたいなら、設定に書いて保存します
たぶんこれが一番よくやる形だと思います。
自作のスタイルファイルの置き場は3段階あります。自分のPC全体に効かせるなら~/.claude/output-styles/、このリポジトリだけに効かせるなら.claude/output-styles/、あとは組織が配るmanaged policyです。中身はfrontmatterにname・description・keep-coding-instructionsがあれば動きます（実物は記事の最後に丸ごと貼ってあります）。
置いたスタイルは/configから選べて、選んだ結果は.claude/settings.local.jsonに保存されて、そのまま効き続けます。ただしこれ、公式に local project level と明記されているとおり project 側の設定なので、自分のPC全体には効きません。全部のプロジェクトで効かせたいなら~/.claude/settings.jsonにoutputStyleを自分で書く必要があります。中身はこれだけです。
{
"outputStyle": "dialogue"
}
効くタイミングについては、公式にはっきり書いてあります。
Output style is part of the system prompt, which Claude Code reads once at session start. Changes take effect after
/clearor a new session.
訳すと「output styleはシステムプロンプトの一部で、Claude Codeはセッション開始時に一度だけ読み込む。変更を効かせるには/clearするか新しいセッションを始める必要がある」ですね。走ってる途中で書き換えても、そのセッションには反映されないってことです。
で、ここまでが「保存して、ずっとそれで使う」やり方なんですけど。この形だと全部の会話が同じスタイルになるんですよね。僕がやりたかったのは、そこじゃなかったんです。
作業ごとに変えたいので、僕は起動をやり直す方を選びました
さっきの公式の引用のとおり、/clearでも切り替わります。なので同じセッションのまま/configで選び直して/clear、という運用でも全然いけます。
ただ僕は作業ごとにペインを新しく立てるタイプなので、どうせ起動するなら起動時に渡してしまえ、という方を選びました。そのためのコマンドがこれです。
claude --settings '{"outputStyle":"structured"}'
さすがに毎回JSONを書くって運用はだるいので、スクリプトでラッパして起動時に選択するだけでoutput styleを選択できるようにしています。structuredは自分で書いたスタイルの名前で、中身は次の章で出てきます。
面白いのは、outputStyleってキー自体はさっきのsettings.jsonとまったく同じところです。設定ファイルに書けば恒久設定になって、起動時に--settingsで渡せばその起動限りの一時設定になる。同じキーを、置き場所だけで恒久にも一時にもできるのが、この運用の芯でした。
じゃあ保存済みの設定と--settingsが両方あったらどっちが勝つのか。ここは公式に書いてなかったので自分で試したんですけど、--settingsのほうが勝ちます。しかも設定ファイル自体は書き換わらなくて、効くのはその起動限りでした。/configで普段のスタイルを決めておいて、特定の作業のときだけ起動時に上書きする、が素直に成立します。
あとはClaude Codeに新規ペインを作らせるって運用もあります。これはtmux経由でClaude Codeを起動する必要があるんで、環境の用意は要りますね。
tmux側でペインを増やす話は前に書いたので、ここでは起動の一行だけにしておきます。tmuxの入れ方はDevContainer に tmux を入れて、設定ごと配る、その場でペインを増やす運用はClaude Codeをスマホでリモート、その場でペインが増えるにまとめてあります。ホスト側の~/.claudeをどう扱ってるかもClaude Codeの~/.claude、どれを共有してどれを分ける？に書いたので、そちらで。
あと公式に書いてあることをひとつだけ。output styleはsubagentには適用されません（forkのときだけ例外だそうです）。
自分で書いた文言は、ちゃんと形になって出てきました
ここからは実験です。実際どんだけ返信が変わるんかな、って気になったので。自分で書いた2枚と、何も置いていない既定の3条件に、同じ5問を各1回ずつ投げて、返ってきたものを数えました。モデルはOpusで固定しています。
書いた2枚はこういう性格です。
dialogue: 「散文で答えろ」という1枚。「つながった文で答えて、箇条書きや表は本当に構造が要るときだけ使え」と書きましたstructured: 「短い塊に刻め」という1枚。「まず結果を1文で出して、そのあとは1点1項目の短いブロックに割れ」と書きました
体感で語ると絶対に盛るので、確かめ方は少し工夫しました。まず「本当にスタイルが効いているか」自体を、乱数で作ったトークンを返信の末尾に必ず付けろという指示で二値判定します（トークンはシェル側で作って自分には見せていないので、システムプロンプト経由でしか出てきません）。そのうえで、1問1条件ごとに空っぽの使い捨てディレクトリを作って、その回に使うスタイルを1枚だけ置いて投げました。とはいえ、質問の内容自体が答えの形に効いてくる交絡はどうやっても残ります。
数えた結果がこれです。
| 既定（基準） | dialogue | structured | |
|---|---|---|---|
| 字数（5問平均） | 1582字 | 843字（既定比53%） | 1011字（64%） |
| 行数（5問平均） | 47.0行 | 9.6行 | 22.6行 |
| 箇条書き（5問合計） | 18 | 0 | 38 |
どれも5問の平均です。既定は質問によって振れて、今回の5問でも一番長い問い（2108字）と一番短い問い（998字）で2倍の開きがありました。平均を絶対値みたいに扱うと事故ります。
数字だけだとピンとこないので、実物も1組だけ置いておきます。「小規模なチームで、モノレポにするかリポジトリを分けるか迷っています。どちらがいいですか？」に対する、既定とdialogueの返答です。どちらも長いので冒頭だけの抜粋です。
既定はこうでした。
小規模チームなら、まずモノレポをおすすめします。理由は「人数が少ないほど、リポジトリを
分けるコストが相対的に重くなる」からです。
## モノレポを推す理由
**横断変更が1PRで済む**
APIのスキーマを変えたらフロントも直す、という変更が日常的に起きます。（略）
**環境構築とCIが一元化できる**
lint設定、フォーマッタ、tsconfig、CIワークフロー、依存バージョン。分けると必ずドリフトします。
## 分けたほうがいい場合
- **公開ライブラリ/OSS** — 外部にリリースするパッケージは、独立した履歴とIssueトラッカーが
あったほうが素直です
- **ライフサイクルが本当に無関係** — 社内ツールや実験用プロジェクトなど、本体と一緒に
ビルドする意味がないもの
（以下略）
dialogueはこうです。
小規模チームであれば、まずモノレポをおすすめします。
理由は単純で、リポジトリを分けたときのコストの大半が「人数が少ないほど重くのしかかる」
種類のものだからです。共通ライブラリのバージョン管理、複数リポジトリにまたがる変更の
PR調整、CI設定の重複、どこに何があるか分からなくなる問題――これらはチームが小さいほど、
一人あたりの負担として効いてきます。（略）
分けたほうがいいのは、次のどれかに当てはまるときです。デプロイ先も言語もライフサイクルも
まったく別物で、コードを共有する見込みがない場合。外部に公開する OSS やクライアントに
渡す成果物が含まれる場合。あるいは、アクセス権限を明確に分離する必要がある場合です。
結論の中身はどっちも同じです。変わったのは渡され方のほうでした。
一番はっきり出たのが箇条書きの行です。dialogueは5問通してゼロ、structuredは既定の倍以上刻んでます。「散文で答えろ」と書いた1枚が箇条書きを使わなくなって、「短い塊に刻め」と書いた1枚が刻む。書いた文言が、そのまま形になって出てきてるわけです。ここは素直に面白かったです。
で、もうひとつ。よく見ると2枚とも既定より短いんですよね。片方は散文で答えろとしか書いてないのに、です。種を明かすと、2枚には共通で書いた1行があります。
Keep responses focused, brief, and concise.
短くなったのはこの1行のぶんで、散文で答えろと書いたからではなかったです。
ここまで見えたのは、あくまで出てきた形の話です。中身の考え方まで変わったのかは、この測り方では見えていません。
それと、です・ます調まわりの日本語の文体は公式がカバーしてる範囲の外なので、そこは完全に自作で割り切って書いてます。
受け取る形だけは、自分で揃えられるんだなと思いました
触ってみて思ったのは、こっちが受け取る形は自分で揃えられるんだな、ということでした。作業ごとに「この時はこう答えて」って毎回説明し直してたのが、起動時の一行に置き換わったのは地味に嬉しいです。
とはいえ各条件1回ずつしか測ってないので、この形が毎回同じように出るとまでは言い切れません。
あと、output styleがAIの思考そのものに影響するのかどうかは、僕は確かめていません。同じことを疑った人は前からいるみたいで、GitHubにissueも立ってるんですが、誰も答えないまま自動で閉じられてました。公式は「どう答えるかを変えるだけで、何を知っているかは変えない」と言っているので、一旦はそちらに乗っかっておきます。そもそも仮に思考の側に差があったとして、それがoutput styleのおかげなのかモデル側の性質なのかも、この測り方だと切り分けられてないですしね。
ではまた！
付録：今回使ったoutput styleの全文
dialogue。
---
name: dialogue
description: 会話モード。散文で答え、リストは必要なときだけ使う
keep-coding-instructions: true
---
Keep responses focused, brief, and concise. Keep disclaimers and caveats short, and spend most of the response on the main answer. When asked to explain something, give a high-level summary unless an in-depth explanation is specifically requested.
Answer in prose, in connected sentences. Use bullets or a table only when the content is genuinely multi-dimensional and the structure is what makes it clear.
If you have to choose between short and clear, choose clear.
日本語で答えるときは、です・ます調で書く。
structured。
---
name: structured
description: 刻むモード。結果を1文で出し、以降を短い塊に分けて読ませる
keep-coding-instructions: true
---
Open with the outcome: one sentence on what happened or what the answer is, before any detail.
Keep responses focused, brief, and concise. Keep disclaimers and caveats short, and spend most of the response on the main answer. When asked to explain something, give a high-level summary unless an in-depth explanation is specifically requested.
Break what follows into short blocks: one bullet per point, and a heading when there are several groups of them. Keep each block to a few lines.
If you have to choose between short and clear, choose clear.
日本語で答えるときは、です・ます調で書く。
