Claudeに原始時代に行ってもらっては困る話

はじめに

最近、海外のLLMコミュニティで 「caveman prompt」「speak like a caveman」 と呼ばれるプロンプト技法がちらほら話題になっています。Claude Codeに「原始人のように喋れ」と指示することで、挨拶・クッション言葉・冗長な前置きを削って応答を短くする ― ひいてはトークン消費を削減できる、という主張です。Reddit や X の一部スレッドでは「出力が劇的に短くなった」「コストが大幅に下がった」といった体験報告が流れており、日本語圏にも「原始人プロンプト」として紹介・翻案される事例が出てきました。

代表的な実装である JuliusBrussee/caveman は、出力トークンを~65-75%削減すると謳っており、Claude Code・Codex・Gemini CLI などに広くプラグインを提供しています。

そのうえで、この手法を「Claude Code のトークン消費を大幅に削減する実用策」として受け取る前に、前提・効果・副作用について一度立ち止まって検討したい論点がいくつかあると感じています。筆者の立場を先に述べると、この種のプロンプトは「出力文字数を減らす」という狭い意味では確かに効きますが、「Claude Code のトークン消費を大幅に削減できる決定打」という強い主張には検討の余地があり、タスクによっては期待した節約効果が得られなかったり、出力品質にトレードオフが生じる可能性もある、というものです。

本稿では、この見方を以下の論点に分けて論じます。

1. caveman prompt は「ペルソナ付与」と「スタイル制約」の二面性を持つ
2. ペルソナ付与面としての性能低下リスク
3. スタイル制約面としての性能低下リスク
4. 「簡潔に」指示は幻覚率を最大20%悪化させうる
5. Claude Code のトークン消費構造と、出力削減の実コストインパクト
6. Claude Code はそもそも既に「concise」指示を受けている
7. benchmark の取り扱いに関する留保

同じ「トークンを節約したい」というゴールを共有する読者に、別の角度からの材料を提示することを意図しています。

---

1. caveman prompt は「ペルソナ付与」と「スタイル制約」の二面性を持つ

caveman prompt 系を検討する前に、まずその構造を正確に押さえておきます。代表的な実装 JuliusBrussee/caveman の SKILL.md を読むと、この技法には2つの異なる層が同時に含まれていることが分かります。

(a) ペルソナ付与層: 「原始人のように喋れ(speak like a caveman)」という指示自体が、「原始人」というキャラクター像を召喚します。英語圏における "caveman speech" は "me Tarzan, you Jane" に代表される fictional な話し方のレジスターで、モデルは事前学習で得たこのキャラクターの振る舞い全体を参照することになります。同リポジトリでは実際に "Classic caveman"・"grunt-level brevity" といったキャラクター呼称が使われています。

(b) スタイル制約層: そのキャラクターの話し方を具体的な削除ルールとして明文化しています。

• Drop articles (a, an, the)
• Drop filler (just, really, basically, actually, simply)
• Drop pleasantries (sure, certainly, of course, happy to)
• Short synonyms (big not extensive, fix not "implement a solution for")
• No hedging (skip "it might be worth considering")
• Technical terms stay exact. "Polymorphism" stays "polymorphism"
• Code blocks unchanged. Caveman speak around code, not in code
• Error messages quoted exact. Caveman only for explanation

興味深いのは、このスタイル制約層について、同リポジトリの eval harness に次の設計思想が明記されていることです。

Honest delta = skill vs terse, not skill vs baseline. Baseline comparison conflates skill with generic terseness — that cheating.

つまり「単なる簡潔指示との差分」を測る比較基準が組み込まれており、caveman 側もこの差分を取ろうとする誠実さは持っています。

しかし、評価の観点では、caveman prompt を採用するとこの2つの層が同時にモデルに適用されます。したがって副作用の議論も、(a) ペルソナ付与としての影響と (b) スタイル制約としての影響の、両方を考える必要があります。以下の2セクションでそれぞれ見ていきます。

---

2. ペルソナ付与面としての性能低下リスク

ペルソナ付与がモデル性能に中立どころか負の影響を与えうることは、近年の研究で繰り返し示されています。

Zheng et al. (2024, EMNLP Findings) 「When "A Helpful Assistant" Is Not Really Helpful」は、162のロールを4ファミリー(計9モデル)のLLM・2,410問のMMLU質問にわたって比較した大規模研究ですが、結論は明快です ― 「システムプロンプトにペルソナを追加しても、コントロール設定(ペルソナなし)と比べて性能は向上しない」。それどころか「最適なペルソナを選ぶのはランダム選択と大差ない」ことも示されました。

Gupta et al. (2023) 「Bias Runs Deep: Implicit Reasoning Biases in Persona-Assigned LLMs」(ICLR 2024) は、24のreasoningデータセット・19のペルソナ・4つのLLMで検証し、80%のペルソナで統計的に有意な性能低下、一部タスクでは70%超の精度ドロップを報告しています。GPT-4 Turboですら42%のペルソナで有意な性能劣化が観測されました。

Kim et al. (2024) 「Persona is a Double-edged Sword (Jekyll & Hyde)」も同様に、「ロールプレイ・ペルソナがLLMを混乱させ、reasoning問題で誤答を誘発する」と明示しています。彼らの解決策が「ペルソナあり/なしの両方で解かせてアンサンブルする」という、まさに「ペルソナだけでは信頼できない」ことの裏返しの設計になっている点は示唆的です。

さらに直近では ―

• 「Expert Personas Improve LLM Alignment but Damage Accuracy」(2026) は、MMLUにおいて「最小限のペルソナ」でも精度が71.6%→68.0%、「長いペルソナ」で66.3%まで低下することを報告しました。
• 「From Biased Chatbots to Biased Agents」(2026) はエージェント型タスクで最大26.2%の性能低下を観測しており、特に「戦略的推論や多段階プランニング」といった、まさに Claude Code が日常的に行う種類の作業で影響が大きいことを示しています。
• 「A Systematic Analysis of the Impact of Persona Steering on LLM Capabilities」(2026) はBig Five特性を神経細胞レベルで誘導する手法で、「特定の人格は複雑な推論を損ないうる」ことを定量化しました。

「原始人」というペルソナは、医師・犯罪者といった現実的役割とは違う fictional character ですが、「認知的に未熟である」「道具を使わない」「文字を持たない」といった強い含意を持つ原型的キャラクターです。モデルが事前学習で得た「原始人らしさ」の連想が、ユーザーが意図した「冠詞を落とす」だけでなく「複雑な論理的議論を避ける」「抽象概念を扱わない」方向にもバイアスをかけうる、というのは素朴に考えても不自然ではありません。とくに「戦略的推論や多段階プランニング」でのペルソナ誘起性能低下を報告した上記 2026 年の研究は、Claude Code 的ワークロードとの関係で気に留めておくべき結果です。

---

3. スタイル制約面としての性能低下リスク

caveman prompt の具体的な削除ルール群 ― 冠詞を落とす、filler を落とす、hedging を禁止する ― は、モデル出力に対するプロンプトレベルのスタイル制約として機能します。そして構文/フォーマット制約が reasoning 性能に非ゼロの影響を与えることは、別系統の研究で繰り返し示されています。

3.1 Format Tax — プロンプトレベルのスタイル指示だけで性能が落ちる

Lee et al. (2026) The Format Tax は、JSON・XML・LaTeX・Markdown などの出力フォーマット指示が reasoning と writing の性能を有意に下げることを示した研究です。ここで重要なのは原因分析で、著者らは次のように明確に述べています。

The dominant cost enters at the prompt: format-requesting instructions alone cause most of the accuracy loss, before any decoder constraint is applied.

つまりデコーダ制約(constrained decoding)をまったく使わなくても、プロンプトに書かれたフォーマット指示だけで性能劣化の大半が起きている。これは caveman prompt と同じ構造です。caveman prompt はモデル出力を物理的に制約するわけではなく、「こう書け」というスタイル指示だけをプロンプトに追加します。

同系統の研究として Tam et al. (2024) Let Me Speak Freely? は、「stricter format constraints generally lead to greater performance degradation in reasoning tasks」と報告しています。Park et al. (2025) の CRANE も「制約が reasoning expressivity を削る」ことを確認しています。

3.2 Brevity 指示が reasoning depth を犠牲にする

より caveman prompt に近い設定を検証した研究として、Fu et al. (2025) Scaling Reasoning, Losing Control があります。本研究は instruction-following と reasoning の相互干渉を系統的に分析し、強制的な簡潔化指示の代償を次のように明確化しています。

Enforcing brevity by limiting CoT length improves instruction-following performance, but at the cost of reasoning depth and accuracy.

つまり「短くせよ」という制約を強めると、モデルは指示への形式的な遵守を優先するようになる一方で、推論の深さと最終精度がその分犠牲になる。これはまさに caveman prompt 的な一律簡潔化が持つリスクです。

EMNLP 2025 の An Empirical Study of LLM Reasoning Ability Under Strict Output Length Constraints も同様の方向を示しており、厳しい出力長制約下では reasoning models が instruction-tuned models や math models に対して常に優位ではなくなる、と報告しています。出力長の予算を絞ると、モデルのアーキテクチャ由来の推論優位性そのものが失われうるということです。

3.3 Instruction-following と reasoning の注意リソース競合

Amazon Science の NeurIPS 2025 論文 The Pitfalls of Reasoning for Instruction-Following は、興味深い attention 解析を報告しています。reasoning が有効に働くケースと逆効果になるケースを比較すると、後者では answer phase における制約トークンへの attention が有意に低下していました。つまり「複数の制約を同時に満たそうとする」状況で、モデルの注意が分散する。

同論文が IFEval と ComplexBench で検証した結果は印象的で、14モデル中13モデルが IFEval で性能低下、全モデルが ComplexBench で性能低下を示しました(CoT適用時)。caveman prompt は典型的に、「この削除ルールに従え」「かつ技術的中身は正確に」「かつコード・エラーは引用せよ」といった複数制約をプロンプトに載せます。一つ一つは軽い制約ですが、合計するとモデルが同時に満たすべき形式上の制約数は増えます。これが reasoning 側の capacity を食う可能性は、理屈上も経験上も否定できません。

3.4 「No hedging」ルールの epistemic な副作用

caveman 系ルールで特に注意が必要なのは "No hedging (skip 'it might be worth considering')" です。この指示は、単に語彙を減らすだけでなく、モデルが確信の低さを表現する手段そのものを奪うことになります。

エンジニアリングの文脈で「これは実装Aでも実装Bでも解ける問題かもしれません」「ただし条件Xが満たされない場合は後者のほうが安全です」といった表現は、モデルの内部的な不確実性が外に出る大事なチャネルです。この hedging を一律禁止すると、モデルは内部で同じ確信度を保っているのに、外形上は確信している風の応答を出力する方向にバイアスされかねません。これは次節の Phare ベンチマークの議論と直結します。

---

4. 「簡潔に」指示は幻覚率を最大20%悪化させうる

Giskard・Google DeepMind・EU 合同プロジェクトの Phare ベンチマーク(公式ブログ)は、「答えを簡潔に」「briefly」といった指示が与えられたとき、ほとんどのモデルで事実的信頼性が低下し、最大20%の hallucination resistance の低下が観測されたと報告しています。

Instructions emphasizing conciseness specifically degraded factual reliability across most models tested. In the most extreme cases, this resulted in a 20% drop in hallucination resistance.

原因はシンプルで、正確な反論や誤前提の指摘には長めの説明が必要なのに、短く答えるよう強制されると、モデルは「誤りを指摘して長く説明する」より「誤った前提を受け入れて短く答える」ほうを選びやすくなる、というものです。Grok 2・DeepSeek V3・GPT-4o mini などで顕著な低下が見られました。

ここで caveman prompt 側の擁護論点は、「SKILL.md が技術用語・コード・エラーの正確性を明示的に保全している」というものです。これは有効な反論で、少なくとも事実の転記系のタスクでは影響が小さい可能性があります。

ただし、Phare が指摘する hallucination の多くは「ユーザーの誤前提を肯定してしまう」系のケースで、これは「語彙レベルで技術用語を残すかどうか」とは別のレイヤーの話です。たとえば「CORSエラーが出る」という相談に対して、本当の原因が認証 Cookie の SameSite 設定だったケースで、短縮モードでは "Access-Control-Allow-Origin 追加" とだけ答えて終わってしまう ― こうしたパターンは、技術用語を正確に保持していても起こりえます。むしろ 3.4 で述べた「no hedging」の副作用と合わさると、「誤前提を簡潔に肯定する」方向への圧力は強まる可能性があります。

「必ず悪化する」と強く言えるわけではありませんが、「技術用語が保全されているから大丈夫」では済まない副作用がある、とは言えそうです。

---

5. Claude Code のトークン消費構造と、出力削減の実コストインパクト

副作用の話を度外視したとしても、出力文の圧縮だけで総コストが大幅に下がるのは難しいと考えられます。Claude Code のトークン消費の構造と、Anthropic の料金体系を組み合わせて考える必要があります。

5.1 Claude Code の「デフォルト重量」

まず、Claude Code は単なるチャットではなく自律エージェントとして設計されており、毎リクエストで送られる固定的なコンテキストがそれなりに重量を持ちます。

サードパーティの詳細な分析(Inside Claude Code's System Prompt)と、Piebald-AI/claude-code-system-prompts の実測値によると、

• システムプロンプト本体: 約2,500トークン
• ツール定義(23+ built-in tools): 約14,000〜17,000トークン
• MCP サーバー: 接続サーバーが増えると数千〜数万トークン(5サーバーで~55,000トークンになる事例も報告)
• CLAUDE.md: ユーザー次第で数百〜数万トークン

つまり、ユーザーがメッセージを1文字書く前に、すでに20,000トークン弱がコンテキストに乗っています。bswen.com の体感レポートは「実際のメッセージはコンテキストのわずか4%、残りはオーバーヘッド」と報告しています。

5.2 会話が進むと cache read が大部分を占める

毎リクエストで固定のシステムプロンプトと会話履歴が再送される構造上、prompt caching が効けば効くほど、セッション全体のトークン数量内訳は cache read が支配的になります。

dev.to の詳細なトークン追跡記事では、157ターンのセッションを解析して「全トークンの98%が cache reads だった」と報告されています。同記事によれば、

• 通常動作中、cache_read は会話累積に従って14k → 167k まで線形に増える
• ターン1で約15k、ターン15で約100k、ターン30で約167k、そこで compaction が発動する
• 出力や新規入力(input_tokens)は各ターン数百〜数千程度

この内訳だけ見ると、「出力削減だけでは総トークン量は大して減らない」ように見えます。しかしここには2つの重要な補正が必要です。

5.3 補正①:数量比はコスト比ではない

Anthropic 公式 Pricing docs と Prompt caching docs で公表されている料金体系は以下のとおりです。

トークン種別	単価係数(base input を 1 として)
Base input	1.0×
Cache read	0.1×
Cache write (5分)	1.25×
Cache write (1時間)	2.0×
Output	約4〜5×(モデルによる)

同じ1トークンでも、Cache Read と Output ではコスト寄与が40〜50倍違います。数量ベースで「Cache Read が98%」だとしても、コストベースで重み付けし直すと出力の寄与はずっと大きくなります。ざっくり言えば、Cache Read 100万トークンと Output 約2万トークンが同程度のコストです。

5.4 補正②:出力削減は次ターン以降の入力に累積する

もうひとつの重要な事実は、出力の累積効果です。Anthropic 公式の Context windows documentation には次のように書かれています。

As the conversation advances through turns, each user message and assistant response accumulates within the context window. Previous turns are preserved completely.

Claude Code はステートレスな API を会話履歴の再送で使っているため、ターン N の出力は、ターン N+1・N+2・… 以降の全ての入力の一部になります。したがって、あるターンで出力を30%削減した場合、そのターンの出力そのものが減るだけでなく、以降のターンの会話履歴(=cache write → cache read として再利用される部分)の該当箇所も30%減ります。

5.5 では、どの程度効くのか

以上を踏まえて、caveman prompt の効果の期待値を冷静に見積もると:

• 効く: 出力そのものの削減(4〜5× coefficient)、およびその出力が次ターン以降の cache に乗る分(0.1× coefficient × 会話履歴内での滞在期間)
• 効かない: システムプロンプト2.5K、ツール定義14-17K、MCP サーバー、CLAUDE.md ― これらは caveman prompt では1文字も減らない
• 効かない: tool outputs(ファイル読み込みで数万トークンが一気に入る) ― ここも caveman prompt 対象外

つまり、caveman prompt は会話履歴のうち「アシスタントの説明テキスト部分」だけを対象とした施策です。Claude Code のトークン消費の大部分は、ツール定義・ツール出力・ファイル読み込み・CLAUDE.md などの入力側で発生するため、Anthropic 公式のコスト最適化ガイド や Best Practices は、subagent 活用・/clear・/compact・CLAUDE.md の縮小・.claudeignore 活用といった入力側最適化を第一の推奨としています。

「Claude Code のコストを決定打的に下げる」なら、まずレバレッジの大きい入力側に手を入れ、caveman prompt 的な出力圧縮は副次的な追加手段として位置付けるのが合理的です。

---

6. Claude Code はそもそも既に「concise」指示を受けている

公開されている Claude Code システムプロンプトの出力方針セクションには次のような文言があります。

You should be concise, direct, and to the point. You MUST answer concisely with fewer than 4 lines (not including tool use or code generation), unless user asks for detail. IMPORTANT: You should minimize output tokens as much as possible while maintaining helpfulness, quality, and accuracy.

「4行以内」「余計な前置き・後置き禁止」「出力トークン最小化」が既にビルトインされているわけです。さらに Claude Opus 4.7 では 公式ドキュメント に「タスクの複雑性に応じて応答長を自動でキャリブレート」「以前より直接的なトーン」と明記されています。

この点について、caveman 側からの反論としては「ビルトイン指示があっても、さらに追加の構文制約で削れる余地がある」というものが考えられ、JuliusBrussee 側の benchmark が示す追加削減率(output で22〜87%)はこの主張を一定程度支持します。したがって「重複だから無意味」ではなく、「追加 caveman 層の marginal gain は実在するが、2〜4節で述べた副作用との相殺で見るべき」という整理が正確です。

ただし、もし読者が応答が冗長すぎると感じているなら、まず疑うべきは「Claude 本体の振る舞い」ではなく「自分の CLAUDE.md やカスタム指示が冗長さを誘発していないか」「.claudeignore が不十分でファイル探索が暴走していないか」のほうです。これらを整備した後で初めて、caveman 系のさらなる圧縮の費用対効果が意味を持ってきます。

---

7. benchmark の取り扱いに関する留保

caveman 系の主張を検討する際、benchmark のメソドロジーも押さえておく必要があります。JuliusBrussee の benchmark は claude -p --system-prompt ... という CLI の one-shot モードで実行されています。これはステートレスな単発プロンプトに対する output token 削減を測っているもので、以下の評価はそこから分離する必要があります。

• 多ターンのコーディングセッションでの累積品質劣化(会話履歴の噪音が reasoning に与える影響)
• 実タスクでの正答率(単なる token 数ではなく、バグ修正の正しさ・設計提案の妥当性など)
• cache hit 率の差(ユーザーごとの CLAUDE.md 設計により大きくばらつく)

また、報告されている削減率「22%〜87%」という約4倍の幅自体、「プロンプトの種類によって大きく変動する」ことを示しており、特定ユースケースでの期待値設定は慎重に行うべきです。「平均で65%削減」というのは、試した prompt mix に対する平均であって、読者個人のワークロードに直接当てはまる保証ではありません。

さらに別の類似プロジェクトである drona23/claude-token-efficient のリポジトリ自身が、こう率直に認めています。

The CLAUDE.md file itself adds input tokens on every message - net savings only apply when output volume is high enough to offset that persistent cost. At low usage it costs more than it saves.

つまり、「conciseを強制する instruction file」を置くこと自体がコンテキストに恒常的な入力トークンを追加するので、出力ボリュームが十分に大きいワークロードでない限り、ネットでは逆効果になり得ます。この点は caveman prompt の実装においても同じ構造で、自己評価のフレームワーク自体に限界があることを示唆しています。

---

8. では何をすればよいのか

以上の論点をまとめると、caveman prompt 系の手法には:

• 出力文のテキストは確かに短くなる
• 設計自体はかなり考え抜かれており、技術用語やコードの正確性は保全される
• 会話履歴への累積効果を考慮すれば、出力削減の価値は単一ターンの比率で見るより大きい

という肯定面がある一方で:

• ペルソナ付与としての性能低下リスク(Gupta et al., Zheng et al., 2026年の3本)、特に戦略的推論・多段階プランニングでの劣化
• スタイル制約としての性能低下リスク(Format Tax・Tam・CRANE・Scaling Reasoning, Losing Control・Pitfalls of Reasoning)、特に「brevity強制 → reasoning depth低下」
• 「簡潔に」指示がもたらす20%の幻覚増加リスク(Phare ベンチマーク)
• hedging 禁止による epistemic calibration の抑圧
• Claude Code のトークン消費の大部分は入力側で発生するため、出力削減の総コスト寄与には構造的な上限がある
• 効果測定が single-turn CLI での output token reduction に偏っており、多ターンの実タスクでの品質劣化は未測定

という構図があります。「Claude Code のトークン消費が重い」という課題自体は実在しますし、そのモチベーションには共感します。そのうえで、同じ課題に対してはより副作用の少ない確立された手法が使えます。

Anthropic公式のコスト最適化ガイド や Best Practices に従えば、以下のような打ち手が有効です。

1. Subagent 活用:冗長な tool output を subagent のコンテキスト内に閉じ込め、サマリだけメインに戻す。公式ドキュメントが最優先で推奨している節約策。
2. CLAUDE.md の整備と縮小:毎セッション読まれるので、肥大化すると Cache Read を押し上げる。「1行ずつ、本当に必要か」を問い直す。
3. .claudeignore / skills の progressive disclosure:不要ディレクトリを探索させない。
4. /compact と /clear の積極的な使用:会話履歴を保持するコストは累積する。
5. モデル切替:Haiku / Sonnet / Opus を /model で使い分ける。Haiku は Opus の約1/5のコスト。
6. Effort パラメータの調整:effort: low や medium で thinking コストを抑制可能(ただし複雑タスクでは性能を落とす点に注意)。そこまで推論が必要ないタスクでは effort を調整する。
7. Prompt caching の活用:静的な文脈を cache_control で囲めば Cache Read は入力の10%コスト。公式プロンプトキャッシング・ドキュメント参照。
8. 不要な MCP サーバーの無効化:毎リクエストでツール定義が乗るので、使わないサーバーは切る。5サーバーで約55,000トークンのオーバーヘッドになる事例も報告されている。

caveman prompt 系もこのスタックに追加できる手段として検討する価値はあると思います。ただし、採用するなら:

• 自分のタスクで精度劣化が出ないかを skill vs terse の比較(JuliusBrussee 側が推奨するのと同じ比較)で手元検証する。ペルソナの比較ではなく、「普通に concise と指示した場合」との差分を見る。
• No hedging ルールが epistemic calibration を損なっていないか、確信度の低い局面(リファクタ提案、バグ原因推定など)での応答を特に観察する。
• 長いセッションでの累積品質を、出力トークン数だけでなく正答率・再修正回数で見る。

という姿勢で取り入れるのが健全だと思います。

---

おわりに

「言語ごとの冗長性構造に着目してプロンプトを最適化する」という caveman prompt 系の発想自体は、興味深い観察ですし、軽い雑談用途やデモ用途では面白い切り口だと思います。実装も考え抜かれており、技術用語やコードの正確性を保全するための工夫が随所に入っています。

ただ「Claude Code のトークン消費を大幅に削減できる決定打」として受け取る際には:

• ペルソナ付与の性能劣化(特に多段階プランニングで顕著)
• プロンプトレベルのスタイル制約だけでも reasoning 性能は低下しうる(Format Tax)
• 「brevity 強制 → reasoning depth 低下」というトレードオフ(Scaling Reasoning, Losing Control)
• 「簡潔に」指示がもたらす20%の幻覚増加リスク(Phare ベンチマーク)
• Claude Code のトークン消費は大部分が入力側(ツール定義・ツール出力・CLAUDE.md)で発生し、出力削減の総コスト寄与には構造的な上限があること
• Claude Code が既に「4行以内」指示を受けている事実
• benchmark が single-turn の output token reduction に偏っていること

といった点は、一度あわせて見ておくと判断材料が増えると思います。本稿はあくまで「海外で話題になっている手法を別角度から検証する」試みであり、こうしたプロンプトの工夫そのものの価値を否定するものではありません。読者のみなさまが自身のユースケースで何が効くかを判断する際の、ひとつの補助線になれば幸いです。

そして、「出力を縮める」だけでなく「入力とツール出力のほうを縮める」という別の角度から、公式ドキュメントに沿った節約術も試してみることをおすすめします。地味ではあるのですが、こちらのほうが実効的に効く場面が多いはずです。

---

主要参照一覧

caveman prompt の実装と benchmark について

1. JuliusBrussee/caveman リポジトリ SKILL.md https://github.com/JuliusBrussee/caveman
2. drona23/claude-token-efficient リポジトリ(同系プロジェクトの率直な限界認識)https://github.com/drona23/claude-token-efficient

ペルソナ付与と reasoning 性能について
3. Gupta et al. 「Bias Runs Deep: Implicit Reasoning Biases in Persona-Assigned LLMs」 arXiv:2311.04892 (ICLR 2024)
4. Zheng et al. 「When "A Helpful Assistant" Is Not Really Helpful」 EMNLP Findings 2024, arXiv:2311.10054
5. Kim et al. 「Persona is a Double-edged Sword (Jekyll & Hyde)」 arXiv:2408.08631
6. 「From Biased Chatbots to Biased Agents」 (2026)
7. 「Expert Personas Improve LLM Alignment but Damage Accuracy (PRISM)」 (2026)
8. 「A Systematic Analysis of the Impact of Persona Steering on LLM Capabilities」 (2026)

構文・スタイル制約と reasoning 性能について
9. Lee et al. 「The Format Tax: A Capability Cost of Structured Output」 arXiv:2604.03616 (2026)
10. Tam et al. 「Let Me Speak Freely? A Study on the Impact of Format Restrictions on Performance of LLMs」 arXiv:2408.02442 (2024)
11. Park et al. 「CRANE: Reasoning with constrained LLM generation」 arXiv:2502.09061 (2025)
12. Fu et al. 「Scaling Reasoning, Losing Control: Evaluating Instruction Following in Large Reasoning Models」 arXiv:2505.14810 (2025)
13. 「An Empirical Study of LLM Reasoning Ability Under Strict Output Length Constraints」 EMNLP 2025
14. Amazon Science 「The Pitfalls of Reasoning for Instruction-Following in LLMs」 NeurIPS 2025

簡潔指示と幻覚について
15. Giskard / Google DeepMind / EU 「Phare LLM Benchmark: Hallucination Analysis」 2025

Claude Code のトークン内訳とコスト構造について
16. Anthropic 公式 「Pricing」 https://platform.claude.com/docs/en/about-claude/pricing
17. Anthropic 公式 「Prompt caching」 https://platform.claude.com/docs/en/build-with-claude/prompt-caching
18. Anthropic 公式 「Context windows」 https://platform.claude.com/docs/en/build-with-claude/context-windows
19. Anthropic 公式 「Manage costs effectively」 https://code.claude.com/docs/en/costs
20. Anthropic 公式 「Best Practices for Claude Code」 https://code.claude.com/docs/en/best-practices
21. Piebald-AI 「Claude Code System Prompts」 https://github.com/Piebald-AI/claude-code-system-prompts
22. 「Inside Claude Code's System Prompt」 claudecodecamp.com
23. 「Where Do Your Claude Code Tokens Actually Go?」 dev.to
24. 「How Claude Code Counts Tokens: A Complete Guide」 bswen.com

Anthropic 公式プロダクト仕様
25. 「What's new in Claude Opus 4.7」 platform.claude.com