Claudeの回答が長すぎて疲れる人へ｜出力構造をPreferencesで制御して認知負荷を下げる

はじめに

AI時代になって、読まなければいけない文章量が増えていませんか。

私はデータエンジニアとして日常的にClaudeを使っているのですが、最近ある悩みが大きくなっていました。Claudeのデフォルト回答が網羅的すぎて、認知負荷が高いのです。

「で、結局どうすればいいの？」と聞きたいだけなのに、選択肢が平等に並べられ、メリット・デメリットが両論併記され、注意点と例外ケースまで丁寧に書かれた長文が返ってくる。読み終わる頃には、最初の疑問が霞んでしまう。

この記事では、userPreferences（カスタム指示）に「質問の意図によって回答構造を切り替える」というルールを書くことで、この問題を緩和するアプローチを紹介します。

これはベストプラクティスではなく、私個人の使い方の1つの事例です。LLMのデフォルト挙動が網羅的なのには合理的な理由があり、フィルタを強くかけすぎると重要な情報を見落とすリスクがあります。自分の用途に合わせて調整してください。

対象読者

• ClaudeやChatGPTを業務で日常的に使うエンジニア・知識労働者
• AIの回答が「長い・読みづらい・要点が掴みにくい」と感じている人
• カスタム指示やSystem Promptで出力を制御したい人

この記事で得られること

• なぜLLMのデフォルト回答が「長くなる」のか、その構造的な理由
• 「情報を求める質問」と「意見を求める質問」を分けて回答スタイルを切り替えるという発想
• 実際に使っているuserPreferencesの指示文サンプル

参考リンク

なぜLLMのデフォルト回答は認知負荷が高いのか

「網羅性バイアス」という構造的な問題

LLMは、デフォルトでは漏れなく・丁寧に・中立に答えようと設計されています。これは多くのユーザーにとって望ましい挙動です。一般的に「短い」よりも「網羅性が足りない」ことのほうが不満になりやすいため、設計としては自然な選択でしょう。

ただ、この設計が以下のような副作用を生みます。

• 選択肢を平等に並べる（推奨を明示しない）
• 両論併記が増える
• 例外ケースや注意点を漏れなく書く
• 前置きと文脈確認が長くなる

結果として、「結論はどこ？」が文章の中盤〜後半に埋もれます。これが認知負荷の正体です。

なぜプロンプトで挙動が変わるのか

そもそもLLMはなぜプロンプトの書き方で出力が変わるのか。技術的な背景として、Qiitaの解説記事¹では以下のように説明されています。

LLM は思考せず予測しています。そのため、予測しやすい形式を提示することによって出力結果(次トークン予測のパターン)を誘導することが出来ます。

つまり、カスタム指示はLLMの予測パターンを誘導する装置だと理解できます。「網羅的に答えるパターン」をデフォルトとして学習しているなら、こちらから明示的に別のパターンを提示すれば、出力構造を変えられるはずです。

「簡潔にして」だけでは不十分な理由

毎回「短く」「簡潔に」と指示するのは現実的ではないですし、そもそも「簡潔さ」の定義が会話によって異なるはずです。

• API仕様を調べているとき → 網羅的なほうがありがたい
• どのライブラリを選ぶか迷っているとき → 推奨を1つに絞ってほしい

つまり、質問の種類によって最適な回答構造は違うわけです。だからこそ、一律に「短くして」と指示するのではなく、質問の意図に応じて回答スタイルを切り替えるルールが必要だと考えました。

解決アプローチ：質問の意図で回答スタイルを切り替える

LLMの設定機能を使う

ClaudeやChatGPTには、毎回の会話に自動適用される指示を書く機能があります。Claudeでは設定画面の「カスタム指示」またはuserPreferences、Claude CodeではCLAUDE.mdやsettings.jsonが該当します²。

カスタム指示は「毎回同じ指示を繰り返す必要がない」というメリットがある一方、設計を間違えると逆に出力品質が下がります。今回のテーマでは、ここに「質問の意図判定」を組み込みます。

「情報を求める質問」と「意見を求める質問」を分ける

私が採用した分類は以下です。

質問の種類	例	求めるもの	最適な回答構造
情報を求める	「〜とは何か」「〜の仕様」「違いは何か」	事実・選択肢・仕様	網羅・中立・両論併記（デフォルトのまま）
意見・推奨を求める	「どうすればいい？」「おすすめは？」「どっちがいい？」	推奨・判断・次の一手	結論先頭・推奨明示・重要度フィルタ

ポイントは、情報を求める質問では網羅性が役に立つということです。API仕様を調べるときに「私の推奨は〇〇です」と書かれても困ります。フィルタを強くかけるのは、意思決定や次の一手を求めているときだけで十分です。

実装：userPreferencesに書いた指示

実際に私が使っているuserPreferencesの該当部分です。

userPreferences.md

## 回答スタイルの使い分け
質問の意図を判定して回答構造を切り替えること。

### 情報を求めている質問（デフォルトの網羅的な回答でよい）
- 「〜とは何か」「〜の仕様」「どんな選択肢があるか」「違いは何か」
- 事実確認、API仕様、機能比較、概念説明
- → 中立的に網羅し、両論併記でよい

### 意見・推奨を求めている質問（簡潔・推奨明示モード）
- 「どうすればいい？」「おすすめは？」「私ならどうする？」「どっちがいい？」
- 意思決定、選択、トラブルシュート時の次の一手
- → 以下のルールを適用:
  - 結論・推奨アクションを最初の2-3行に書く
  - 「私ならこうする」という推奨を明示し、選択肢を平等に並べない
  - 比較が必要なら表形式、推奨を太字で示す
  - アクションに直結しない補足は省略してよい
  - フィルタで落とした重要トピックは末尾に「※今回触れなかった論点: ◯◯」と1行残す

### 判定に迷う場合
冒頭で「情報整理として答えますか、意見として答えますか」と一度だけ確認すること。

設計上のポイント

判定キーワードを具体的に列挙する

「意見を求めている質問」を曖昧に書くと、Claudeが判定をミスります。「どうすればいい？」「おすすめは？」「どっちがいい？」のような実際に自分が使う言い回しを例示することで、判定精度を上げています。

「触れなかった論点」を末尾に残す

意見モードで情報をフィルタすると、抜け漏れのリスクが出ます。これに対処するため、フィルタで落とした重要トピックを末尾に1行だけ残すルールを入れています。

※今回触れなかった論点: コスト面の比較、長期運用時のメンテナンス性

こうすれば、深掘りしたい点があれば「コスト面詳しく教えて」と聞き直せます。透明性とコンパクトさのバランスを取ったつもりです。

判定に迷う場合のフォールバック

判定基準を書いても、境界線上の質問は必ず出ます。そのとき、無理に判定するよりも冒頭で1回だけ確認するほうが安全です。毎回確認されると鬱陶しいので「迷う場合」に限定しています。

判定精度が高まってきたら、この確認ルールは外してもよいと思います。私はまだ運用初期なので残しています。

類似アプローチ：指示を再利用可能な形に切り出す

似た発想として、Claude Codeのカスタムコマンドやスキル機能があります³。これは「毎回似たような指示を書くのが面倒」という課題に対して、指示そのものを再利用可能な形に切り出すアプローチです。

/review
→ 「セキュリティ、パフォーマンス、コーディング規約の観点でチェックして」を呼び出す

今回のuserPreferencesアプローチと方向性は同じで、「毎回プロンプトに書く負担をなくして、出力の質を安定させる」点で共通しています。違いは、カスタムコマンドが明示的な呼び出しなのに対し、userPreferencesは自動適用である点です。

想定される副作用と対策

正直に言うと、この設定にはトレードオフがあります。

副作用	対策
意見モードで重要情報を落とす	「触れなかった論点」の1行注釈で補う
判定ミスで噛み合わない回答が出る	「迷う場合は確認」ルールで吸収
思考プロセスが見えなくなる	必要なら「根拠も教えて」と追加で聞く

特に判断の根拠が見えなくなる点には注意が必要です。意見モードは「結論先頭」を強制するので、なぜその結論なのかが薄くなります。重要な意思決定では、追加で「なぜそう判断したか」を聞くようにしています。

まとめ

• LLMのデフォルト回答は網羅性バイアスにより情報過多になりやすい
• 一律に「簡潔に」と指示するのではなく、質問の意図で回答スタイルを切り替える設計が有効
• userPreferencesに「情報を求める質問」と「意見を求める質問」の判定基準を書き、後者だけ簡潔・推奨明示モードに切り替える
• フィルタで落とした論点は末尾1行で残し、抜け漏れリスクを軽減する

繰り返しになりますが、これは1つの使い方の事例です。網羅性が必要な場面もあるので、自分がどんな質問をすることが多いかを観察してから設計するのがおすすめです。

1. pyo2102氏「生成AI(LLM)を扱う上で何故プロンプトが重要なのかを技術的な観点から見てみた」より引用。LLMがSelf-Attentionによってトークンの重み付けを行う仕組みから、プロンプト設計が出力に影響する技術的背景が解説されている。 ↩

2. Claude Codeのsettings.jsonとCLAUDE.mdの役割分担については、makoto-ogata氏「Claude Codeのsettings.jsonの設定をしよう」が参考になる。「settings.jsonは権限・動作の制御、指示はCLAUDE.mdに書く」という整理が明快。 ↩

3. Claude Codeのカスタムコマンドの実装方法は、tmasuyama1114氏のZenn記事「Claude Codeカスタムコマンド完全ガイド」が詳しい。 ↩