ケイブマンプロンプトとは何か

ケイブマンプロンプトとは何か：AIエージェントの「口数」を減らすプロンプト術

はじめに

最近、Claude Code などのAIコーディングエージェント界隈で「Caveman Prompt」、日本語で言うと「ケイブマンプロンプト」や「原始人プロンプト」という言葉を見かけるようになりました。

名前だけ聞くとネタっぽいのですが、考え方としてはかなり実用的です。

一言でいうと、

AIに「原始人のように短く話せ」と指示して、出力を圧縮する

というプロンプト技法です。

ただし、私はこの手法をそのまま「原始人キャラ」として使うよりも、
技術メモ圧縮モードとして使う方が実用的だと思っています。

ケイブマンプロンプトとは

ケイブマンプロンプトは、AIの回答から次のような要素を削るための指示です。

• あいさつ
• 前置き
• 丁寧すぎる説明
• 重複表現
• 意味の薄い接続詞
• 長い背景説明
• 「もちろんです」「以下に説明します」などの定型文

つまり、AIにこう言わせるイメージです。

通常の回答:

このエラーは、Azure AI Search のマネージド ID に対して
Storage Blob Data Reader ロールが付与されていないことが原因です。
Azure Portal でストレージアカウントを開き、
アクセス制御からロールを追加してください。

ケイブマン風:

原因:
Search の Managed ID に Blob 読取権限なし。

対処:
Storage Account
→ IAM
→ Storage Blob Data Reader
→ Search の Managed ID を追加

かなり短くなります。

何がうれしいのか

ケイブマンプロンプトの主な目的は、AIの「考える力」を変えることではありません。
あくまで、AIの「出力の仕方」を短くすることです。

代表的な caveman 実装では、Claude APIでの実測として、10個のプロンプト平均で出力トークンが約65%削減されたと説明されています。また同じREADMEでは、これは reasoning / thinking tokens を減らすものではなく、見える出力だけを短くするものだと説明されています。(GitHub)

つまり、

ケイブマンプロンプトは、AIの脳を小さくする技術ではなく、口を小さくする技術

です。

典型的なプロンプト

英語なら、例えばこうです。

Talk like caveman.

Rules:
- Short sentences.
- No greetings.
- No filler.
- No long explanation.
- Keep technical terms.
- Keep code exactly.
- Use bullets.
- Say only useful things.

日本語で使うなら、私はこの形の方が安全だと思います。

以後の回答は「技術メモ圧縮モード」で。

ルール:
- 前置き不要
- あいさつ不要
- 結論を先に書く
- 箇条書き中心
- 冗長な丁寧語を避ける
- 技術用語、コード、コマンド、エラー文は省略しない
- 不確実な点は「不明」「要確認」と明記
- 重要な注意点は削らない
- 複雑な話は「結論 / 理由 / 手順 / 注意点」に分ける

私は「原始人として話せ」よりも、このように具体的な出力制約を書く方が好きです。

理由は、原始人キャラを入れると、AIが妙なロールプレイに引っ張られる可能性があるからです。

向いている用途

ケイブマンプロンプトが向いているのは、次のような場面です。

• エラー原因だけ知りたい
• コマンドだけほしい
• 手順だけほしい
• AIエージェントの作業ログを短くしたい
• Claude Code / Codex などの応答を読みやすくしたい
• 長い説明を技術メモに圧縮したい
• 議事録からアクションだけ抜きたい
• Qiita記事の下書きから冗長表現を削りたい

たとえば、AIにこう頼みます。

次の説明を技術メモとして圧縮してください。

条件:
- 前置き不要
- 結論を先に
- 手順は箇条書き
- 注意点は削らない
- コードとエラー文は正確に残す

向いていない用途

逆に、向いていない場面もあります。

• 初学者向けの丁寧な説明
• 設計判断
• セキュリティレビュー
• 本番障害対応
• 医療、法務、税務などの高リスク領域
• 複雑なコード修正
• なぜそうなるのかを深く理解したい場合

短くするということは、判断材料も落ちやすいということです。

実際に、Business Insider の記事では、Claude に caveman speak を使わせた開発者が、重要な作業では出力品質が落ちたため、 serious work には信用しづらかったという趣旨の体験を語っています。(Business Insider)

「短い」は正義か？

ここが大事です。

短い回答は読みやすいです。
しかし、短ければ常に良いわけではありません。

特にAIの回答では、次の情報が重要になることがあります。

• 根拠
• 前提
• 例外
• 失敗パターン
• 判断理由

ケイブマンプロンプトを使うと、これらが削られすぎることがあります。

なので私は、次のように使い分けるのがよいと思っています。

用途	ケイブマン向きか
エラー原因の一次切り分け	向いている
コマンド確認	向いている
作業ログの圧縮	向いている
記事構成メモ	向いている
初学者向け解説	あまり向かない
設計方針の検討	注意が必要
セキュリティ判断	向かない
本番障害対応	単独では危険

私が使うならこうする

私は「ケイブマンプロンプト」をそのまま使うより、次の3種類に分けて使います。

1. エージェントログ圧縮モード

Claude Code や Codex のようなAIコーディングエージェントに向いています。

以後、作業ログは短く出してください。

形式:
- やったこと
- 見つけた問題
- 次の対応
- 注意点

制約:
- 前置き不要
- 1行を短く
- コマンドとファイル名は省略しない
- 不確実な点は「要確認」と書く

2. 技術メモ圧縮モード

調査メモや検証メモに向いています。

次の内容を技術メモとして圧縮してください。

条件:
- 結論を先に
- 重複を削る
- 箇条書き中心
- 技術用語は残す
- 注意点は削らない
- 判断理由を1行で残す

3. Qiita構成メモモード

記事を書く前の中間工程に向いています。

次の内容をQiita記事の構成メモにしてください。

条件:
- 見出し案を作る
- 読者が知りたい順に並べる
- 冗長表現を削る
- コード例は残す
- 注意点と落とし穴は残す
- 最後にタグ候補を出す

Qiita記事を書くときの使い方

Qiita用の記事を書く場合、私は次の流れがよいと思います。

1. まず普通に詳しく書かせる
2. 内容の漏れを確認する
3. ケイブマン風に要点だけ圧縮する
4. 圧縮結果を見出し構成にする
5. 最後に人間向けの自然な文章に戻す

ポイントは、最初からケイブマン風で本文を書かせないことです。

最初から短くさせると、背景説明や注意点が抜けやすくなります。
いったん詳しく出してから、あとで圧縮する方が安全です。

悪い使い方

たとえば、こういう使い方は危ないです。

全部短く。説明不要。コードだけ直して。

この指示だと、AIは判断理由やリスクを出さなくなります。

コードが動くかどうかだけならよいかもしれません。
しかし、なぜその修正が必要なのか、他に副作用がないのかが見えません。

よい使い方

私なら、こう書きます。

回答は短くしてください。

ただし:
- 正確性を優先
- 重要な注意点は削らない
- 代替案がある場合は1行で示す
- コード、コマンド、エラー文は省略しない
- 不確実な点は「要確認」と書く

形式:
結論:
理由:
手順:
注意:

これなら、短くしつつ、必要な情報は残せます。

実例

例えば、Azure AI Search の権限エラーについて聞いた場合。

通常の回答:

このエラーは、Azure AI Search のマネージド ID に対して、
対象のストレージアカウントを読み取るための権限が
付与されていないことが原因で発生している可能性があります。

Azure Portal でストレージアカウントを開き、
アクセス制御 IAM から Storage Blob Data Reader ロールを追加してください。

圧縮後:

原因:
Search の Managed ID に Blob 読取権限なし。

対処:
Storage Account
→ IAM
→ ロール追加
→ Storage Blob Data Reader
→ Azure AI Search の Managed ID を指定

注意:
反映に数分かかることあり。

読みやすいです。
しかし、初心者向けの記事なら、通常の説明も必要です。

まとめ

ケイブマンプロンプトは、AIに「短く話させる」ためのプロンプト技法です。

ただし、本質は原始人ロールプレイではありません。

本質は、

最大の意味を、最小の出力で返す

ことです。

なので、私は次のように捉えています。

ケイブマンプロンプト
= AIを賢くする技術ではない
= AIの出力を圧縮する技術

実務で使うなら、原始人キャラよりも、

技術メモ圧縮モード
エージェントログ圧縮モード
Qiita構成メモモード

として使う方が安全です。

最後に、私がよく使いそうなテンプレートを載せておきます。

回答は短く。ただし、正確性を優先。

ルール:
- 前置き不要
- 結論を先に
- 箇条書き中心
- 重要な注意点は削らない
- コード、コマンド、エラー文、固有名詞は省略しない
- 不確実な点は「要確認」と書く

形式:
結論:
理由:
手順:
注意:

これくらいが、普段使いにはちょうどよいと思います。

参考

• JuliusBrussee/caveman
  Claude Code向けのcaveman実装。READMEでは平均65%の出力削減と、thinking / reasoning tokens には影響しない点が説明されています。(GitHub)

• Business Insider: I taught Claude to talk like a caveman to save my AI tokens
  caveman speak によるトークン節約を試したものの、重要な作業では品質面で厳しかったという体験談が紹介されています。(Business Insider)

---

タグ候補:

AI
プロンプトエンジニアリング
生成AI
Claude
ClaudeCode
LLM

おすすめタグ:

AI
プロンプトエンジニアリング
生成AI
ClaudeCode
LLM