はじめに
/config を開くと「Output style」という項目があり、Default・Proactive・Concise・Explanatory・Learning の 5 つから選べます。
説明文だけ読んでも「Proactive は実行優先」「Concise は簡潔」くらいの違いしかわからず、実際にどのくらい応答が変わるのか気になったので、同じお題・同じモデル・同じ権限設定で 5 パターンとも実行し、応答を見比べてみました。
Output styleとは
Output style は、Claude Code の応答の口調・粒度・進め方を切り替える設定です。
どう答えるか（システムプロンプトに追加される指示）が変わります。
| スタイル | 公式の説明（意訳） |
|---|---|
| Default | 効率よくタスクを終わらせ、簡潔に応答する |
| Proactive | 計画より実行を優先し、確認や中断を最小限にする |
| Concise | 結果から先に述べ、前置きや説明を省いて簡潔に答える |
| Explanatory | 実装の選択やコードベースのパターンについて解説する |
| Learning | 人が手を動かして学べるよう、小さな実装を依頼して一時停止する |
検証方法
同じお題を、outputStyle だけを変えた 5 回の非対話実行（claude -p）に投げて比較しました。
モデル・権限設定・作業ディレクトリ（毎回まっさらな空リポジトリ）はすべて揃えています。
お題は「設計判断が 1 つ含まれる小さな実装」にしました。判断の余地がないと差が出にくく、逆に大きすぎると比較しづらいためです。
TASK="utils.py に retry_with_backoff というリトライ用デコレータを実装して。失敗時のリトライ間隔をどう決めるかも考えて。"
for STYLE in Default Proactive Concise Explanatory Learning; do
claude -p "$TASK" \
--model sonnet \
--permission-mode acceptEdits \
--allowedTools "Bash" \
--settings "{\"outputStyle\":\"${STYLE}\"}"
done
outputStyle は /config から選ぶ値がそのまま --settings に渡せるキーになっています。
結果
| スタイル | ターン数 | コスト | 所要時間 |
|---|---|---|---|
| Default | 6 | $0.146 | 24.4秒 |
| Proactive | 5 | $0.140 | 21.1秒 |
| Concise | 4 | $0.124 | 14.9秒 |
| Explanatory | 5 | $0.147 | 29.3秒 |
| Learning | 4 | $0.152 | 36.4秒（実装未完了） |
Learning だけは「解説と質問だけして実装を完成させずに止まった」ため、他の 4 つとは単純比較できません。
Default: 必要なところだけ一言添える
最初の調査コマンドは無言で実行し、ファイル作成のような判断が伴う箇所だけ短く理由を添えていました。
utils.pyを新規作成します。リトライ間隔は「指数バックオフ＋ジッター」を採用します（固定間隔だと再試行が集中して負荷をかけやすく、単純な指数バックオフだけだと複数クライアントが同期して同時にリトライする「サンダリングハード問題」が起きるため）。
Proactive: 動く前に一言宣言してから進む
「実行優先・中断最小限」という説明の割に、Defaultより先に「これから何をするか」を一言宣言してから動く場面が目立ちました。非対話実行では元々確認を挟まないため、Proactiveの違いは「止まらない」ことより「宣言してから進む」ことの方に表れていたようです。
utils.py の現状を確認します。
Concise: 常体・最短ターン
他の4つは「です/ます」調でしたが、Conciseだけ「〜する」「〜した」という常体で、説明も箇条書き中心に削られていました。ターン数・コスト・所要時間のいずれも最小だったのも、この徹底した簡潔さが素直に表れた結果に見えます。
utils.pyにretry_with_backoffを実装した。
Explanatory: 実装の前後に解説が挟まる
コードを書く前に選択肢の比較、書いた後に実装判断の解説と、★ Insight ブロックが2回挟まりました。最後には次の一手まで提案してきます。
★ Insight ─────────────────────────────────────
固定間隔／指数バックオフ／指数バックオフ+ジッターの3つを比較し、AWSの推奨パターンであるジッター付きを選定した理由を説明
─────────────────────────────────────────────────次は実際に使う箇所（HTTPリクエストなど）にこのデコレータを適用しますか？
Learning: 唯一、実装を完成させない
デコレータの骨格だけ実装し、リトライ間隔を決める _compute_delay 関数を TODO(human) のまま残して停止しました。
def _compute_delay(attempt, base_delay):
# TODO(human)
...
その上で、固定間隔／指数バックオフ／ジッター付きの 3 択と、それぞれの特性をガイダンスとして示し、実装を人間に委ねる形でメッセージを終えていました。他の 4 つのスタイルが自動でジッター付き指数バックオフを選んだのに対し、Learning だけはその「選ぶ」という工程自体を渡してきます。
判断フロー
今回の観測結果を分岐条件にすると、こういう判断フローになりそうです。
- Learning は唯一「動くコードを渡さない」スタイルなので、自動化スクリプトに混ぜるとそこで止まります。ハンズオン学習用途に限定した方がよさそうです
- Explanatory は
★ Insightの分だけターンとコストが増える代わりに、実装意図がそのまま会話に残るのでレビュー向きです - Concise はターン数・コスト・所要時間のすべてで最小でした。任せて終わらせたいだけの作業はConciseが効率的です
- 迷ったら Default か Proactive で十分。今回の検証では、Proactive の違いは「動く前に一言宣言する」程度で、非対話実行では体感差は小さめでした
まとめ
同一お題・同一モデルで比較すると、公式説明だけでは分からなかった実際の口調やターン数の違いが見えました。