Claude Codeのシステムプロンプトを80%以上削減――AIエージェントは「教え込む」から「判断できる環境を設計する」へ

本記事は、生成AI・テクノロジー分野のニュースを取り上げ、中小企業の業務自動化の視点から考察する解説記事である。

80%以上の削減。AnthropicはClaude Codeのシステムプロンプトを、Claude Opus 5やClaude Fable 5向けに80%以上削減したと発表した。AIの性能を引き出すには詳細な指示やルールを書き込むほどよい、と考えられがちだが、本質はプロンプトの長さでも指示の数でもない。問われているのは、AIに何を覚えさせるかではなく、AIが自分で判断できる環境をどう設計するかである。

本稿では「上からルールを与える設計」と「現場で必要な情報を段階的に開く設計」の対比を軸に、この発表を中小企業の業務自動化へ引き寄せて考える。鍵になるのは、長い指示書を書く技術ではない。情報をどこに置き、どのタイミングで開くかという設計こそが、これからのAI活用を左右する。

システムプロンプトを80%削っても性能が落ちなかったのは、AIが賢くなったからだけではない

“We removed over 80% of Claude Code’s system prompt for models like Claude Opus 5 and Claude Fable 5 with no measurable loss on our coding evaluations.”

「Claude Opus 5やClaude Fable 5のようなモデルでは、コーディング評価において測定可能な損失がないまま、Claude Codeのシステムプロンプトを80%以上削減した」

Claude Opus 5やClaude Fable 5といった新世代モデルでは、従来のシステムプロンプトの大部分を削っても、Anthropicのコーディング評価で測定できる性能低下は確認されなかった。事実は明確だが、「指示が不要になった」わけではない。Claudeが受け取る文脈は、ユーザーの入力だけではなく、システムプロンプト、Skills、CLAUDE.md、メモリ、ツール定義、参照ファイルなどが組み合わさっている。

Anthropicはこの全体をコンテキストエンジニアリングと呼ぶ。平たく言えば、AIに何を・いつ・どの順で見せるかを設計する営みである。日常的にClaude Codeを使う人には馴染み深いが、そうでなくても発想は同じで、新人に分厚いマニュアルを一度に渡すのではなく、必要な資料を必要な場面で開けるようにしておくことに近い。

私はこの変化を、マニュアルのページ数が減った話とは見ていない。熟練者に「すべての例外を最初から説明する」必要がなくなり、必要な情報へ自力で到達できる導線の設計こそが重要になった、と見ている。中小企業のAI導入でも、長大な社内ルールを一つのファイルに詰め込む方法には限界がある。情報が増えるほど、重要なルールと古いルール、例外と原則が同じ場所に並び、かえって判断を難しくするからだ。

「コメントを書くな」と「必要なら書け」が同時に存在する問題

“Generally, Claude can interpret the user’s intent to get to the right answer, but Claude must think more carefully about these overlapping and conflicting messages before deciding what to do.”

「一般にClaudeはユーザーの意図を解釈して正しい答えへ到達できるが、重複したり衝突したりするメッセージがあると、何をすべきか決める前により慎重に考えなければならない」

Anthropicは、内部でClaude Codeを使った記録を読み返すと、一つのリクエストの中で「適切にドキュメントを残す」と「コメントを追加してはならない」といったメッセージが衝突していたと説明する。古いモデルでは、危険な操作を避けるために強いガードレールが要った。ファイル削除や不適切なコード変更を防ぐため、細かな禁止事項を書き込む合理性があったが、モデルの判断能力が上がると、過剰な制約は別の問題を生む。

これは自社でも実感している。画像生成のプロンプトを書くエージェントで、「文字を入れるな」という固有ルールと、対象の段落から生まれた「58%と書かれた用紙」という具体的な指示が衝突したことがある。議事録から抽出した人物の思想データベースを参照する記事執筆エージェントが、相反する思想を一本の記事に同居させてしまったこともある。抽象的なルールと、より具体的な指示が一つのプロンプトに同居すると、具体的な指示が優先される――そうした挙動は実際に確認されており、だからこそ指示や情報のクリンナップは本当に重要だ。

ここには、AI運用で見落とされがちな「意思決定コスト」がある。人間の業務でも、社内規程が増えすぎると、担当者は顧客対応より規程の確認に時間を使う。AIも同じで、相反する指示が増えれば、回答生成よりも指示の優先順位付けに文脈を消費する。

とはいえ「ルールを減らせばよい」という単純な話ではなく、安全上不可欠な制約、会社固有の判断基準、モデルがファイルを見れば分かる一般論を切り分ける必要がある。たとえば請求書処理のエージェントなら、消費税率の一般的な説明は外部知識や参照資料で足りる。一方「金額が50万円を超える場合は代表承認が必要」といった社内固有のルールは明示的に保持すべきで、この切り分けが曖昧なまますべてを一つの指示書へ入れると、保守性も監査性も落ちる。

情報を最初から全部渡さない――必要なときだけ開く「段階的開示」

“Since then, Claude Code has gotten very competent at using progressive disclosure- loading the right context at the right times.”

「それ以来、Claude Codeは段階的開示、つまり適切なタイミングで適切な文脈を読み込むことに非常に長けるようになった」

progressive disclosure（段階的開示）とは、すべての情報を最初から渡すのではなく、タスクに応じて必要な情報を後から読み込ませる仕組みである。Anthropicは、コードレビューや検証の情報をシステムプロンプトから切り離し、必要なときにClaude Codeが呼び出せるSkillsへ移したと説明する。比喩でいえば、病院の受付で患者全員に全診療科の専門書を渡すのではなく、症状に応じて必要な診療科の情報だけを開く設計だ。情報を隠すのではなく、使う場面に合わせて出す考え方である。

中小企業でも、営業、採用、経理、顧客からの問い合わせ対応など、部門ごとに参照すべき情報は違う。それを全社規程、過去の議事録、商品資料、例外処理まで一つのナレッジベースへ押し込むと、AIは必要な情報を探すために余計な推論を強いられる。Anthropicは、CLAUDE.mdやSkill.mdも一枚の巨大な文書にせず、適切なタイミングで読み込めるファイルのツリーとして構成することを勧めている。

この設計は自社の情報基盤でも中心に据えている。会議の文字起こしや音声メモから抽出される人物の個性や製品情報は、放っておけば無限に増える。そこで情報を「開示してよい情報／ノウハウ／営業秘密／個人情報／プライベート」といったレベルで判定し、そのまま出力へ入れるのが望ましくないものは人間の評価を経てから有効化する。加えて、鮮度による重み付け、似た情報の統廃合、週次での棚卸しも仕組み化している。実際、考えなしに運用すると索引ファイルはあっという間に肥大化するが、どこに何があるかをAIが素早く辿れるツリー構造にするほど、結果的に出力の品質は上がる。

だからこそ、AI導入の成否を「どれだけ多くの資料を登録したか」で測るのは危険だと考えている。登録量を増やすほど、重要な情報が古い情報や重複に埋もれ、AIが正しい一件へ辿り着けなくなるからだ。本当に重要なのは、どの問い合わせでどの情報が参照され、どれが参照されなかったかを記録できる構造であり、空欄や未確認の情報を無理に埋めず、未整備のまま識別できる設計のほうが、実運用では信頼できる。

例を増やすほど自由度が下がる――AIエージェントのツールは「使い方」より「表現力」で設計する

“Instead of using examples, think more about the design of your tools, scripts and files- what parameters does Claude have and how can they be more expressive?”

「例を使うのではなく、ツール、スクリプト、ファイルの設計について考えるべきである。Claudeにはどのようなパラメータがあり、それらをどれだけ表現力豊かにできるかを考える」

従来のツール設計では、「この場合はこう呼び出す」という利用例を多く与えることが有効とされた。しかしAnthropicは、新しいモデルに例を与えすぎると、探索範囲が例の周辺へ狭まると説明する。たとえば、業務の状態を持つデータ構造が「pending」「in_progress」「completed」の三択しかなければ、エージェントはその枠内でしか状態を表現できず、差し戻し中の案件も承認待ちの案件も同じ「in_progress」に丸められてしまう。逆に、担当者、期限、差し戻し理由、承認者まで扱える構造なら、業務の現実に近い判断ができる。

つまりAIエージェントの品質は、プロンプトだけでなく、接続される業務インターフェースの質で決まる。受注処理ツールに「注文を登録する」機能しかなければ、AIは登録前後の在庫確認や与信確認を、別の曖昧な手段で補おうとする。必要な業務状態をデータ構造として表現できれば、判断の余地と検証可能性が増す。

この領域では、既存のSaaSやワークフロー製品を買うか、自社向けに作るか（Build versus Buy）の判断も重要だ。業務が標準化されているなら、既存ツールの権限管理や監査ログを使うほうが堅実である。競争力の源泉が独自の承認条件や顧客対応にあるなら、その重要な部分だけを薄く作る意味がある。

ただし、実際の出力精度を測らずに「表現力の高いツール」を作っても意味はない。処理時間、誤登録率、人による差し戻し率、最終承認までの時間など、導入前後で比較できる指標がなければ、改善かどうかを判断できないからだ。まず測れる指標を決め、次に構造を設計する順番を崩さないことだ。

「AIが賢くなったから任せればよい」は危険――判断と検証は別の仕事である

“But newer models have better judgement and can handle these decisions well without explicit rules.”

「しかし新しいモデルはより優れた判断力を持ち、明示的なルールがなくてもこうした判断をうまく処理できる」

この主張は、今回の発表でもっとも期待を集めやすい。しかし、そのまま経営判断へ移植することには慎重であるべきだ。モデルが判断できることと、その判断を無条件に採用できることは別だからである。Anthropicの説明は、Claude Codeのコーディング評価と同社の利用環境に基づく知見であり、営業承認、医療、法務、給与計算など失敗コストの高い業務で同じ結果が出るとは、本文からは言えない。

「モデルが賢くなったのだから、細かな評価や確認も減らせるのでは」という反論もある。しかし構造的には、モデルの判断能力が上がるほど、人間はその出力を監督する役割へ移る。ルールを書く作業が減っても、何を成功とみなすか、どの失敗を許容しないか、どの時点で人間へ戻すかという設計は残る。

私はこの主張に同意する。とりわけクリエイティブの領域では、方向性を示さなければ、毒にも薬にもならない平均点のアウトプットに落ち着く。生成AIの急速な普及で、そうした無味無臭の文章や画像はすでに溢れており、AI臭さに気づいた瞬間、読み手の心は動かなくなる。仮にモデルの判断力が人間を超えても、人間の監督設計が消えた世界のアウトプットに、私たちは何の価値を感じるだろうか。一方で、クリエイティブ要素のない業務――信頼性が担保されたうえでの反復的な売買や書類のやり取り、低リスクの取引――なら、承認プロセスを減らしても成り立つ。任せてよい領域と、方向づけが要る領域を見極めることだ。

Anthropicは、ルーブリック（評価基準を項目ごとに定めた採点表）を使って特定分野の「よい設計」の基準を試し、検証エージェントを動かす方法にも触れている。これは正解例を与えるのではなく、評価基準と検証ループを組む発想である。中小企業に現実的なのは、最初から完全自動化を目指すことではない。AIが作った回答案を人間が承認する、一定金額以上の取引だけ人間へ戻す、判断に必要な資料が足りなければ処理を止める、といった境界を設けることだ。

AI導入で本当に削るべきなのは、作業時間だけではない。確認漏れ、判断の属人化、繰り返される差し戻しといった構造的な停滞である。そこを切り分けずに自動化すれば、間違った結果を速く量産するだけになる。

システムプロンプトを短くする前に、会社の知識をどこへ置くか

“Keep your CLAUDE.md lightweight and briefly describe what your repo is for, but spend most of the tokens on gotchas inside of the codebase.”

「CLAUDE.mdは軽量に保ち、リポジトリの目的を簡潔に説明する一方で、トークンの大部分はコードベース内の落とし穴に使うべきである」

Anthropicは、CLAUDE.mdにはリポジトリの目的を簡潔に書き、ファイル構成を見れば分かる「明白なこと」よりも、コードベース固有の落とし穴に情報を割くべきだと説明する。この考え方は業務ナレッジにもそのまま当てはまる。会社案内のような一般論を大量に渡すより、「この顧客群では例外的にこの条件を適用する」「この数値は速報値であり請求には使わない」「この担当者の承認が必要」といった、通常の資料からは読み取りにくい情報のほうが価値を持つ。

ただし情報を段階的に分けるには、誰が更新するのかを決めねばならない。営業資料と契約条件が食い違うとき、AIにどちらを優先させるかが不明確なら、プロンプトを短くしても問題は解決しない。AIの自動メモリに任せれば知識管理が不要になる、というわけでもなく、自動保存された記憶は便利だが、誤った情報や古い前提が残りうる。重要な契約条件、価格、法令対応は、出所と更新日を確認できる正式な参照資料として管理すべきだ。

最後に、業務を「検索」「判断」「実行」に分解しておくことを勧めたい。分解できれば、どこは検索拡張生成（RAG、社内文書を検索して回答に使う仕組み）で足り、どこにエージェントとツール設計が要り、どこを人間が担うかを、投資前に見極められる。分解しないまま高価なエージェント基盤を導入すると、検索で済む処理に過剰な仕組みをかけ、判断が要る処理を自動化しすぎ、結局どこが効いているのか分からないまま費用だけがかさむ。

まとめ

今回の発表が示す対比は明快である。以前は「ルールを与える」「例を与える」「すべてを最初に渡す」「同じ指示を繰り返す」ことが重視された。新世代モデルでは、「判断に任せる」「インターフェースを設計する」「段階的に開示する」「簡潔なツール説明にする」方向へ重心が移っている。ただし、これはAIを放置するという意味ではなく、ルールの量ではなく、情報の配置、ツールの表現力、検証の仕組み、失敗時の人間への引き継ぎが問われる段階に入ったということだ。

要点は次の3つである。

• 長いプロンプトは、性能を保証しない
• 必要な情報を必要なタイミングで開く設計が、文脈の品質を左右する
• AIの判断力と、業務で無条件に任せられることは別である

あなたの会社で同じ業務が何度も差し戻され、担当者が毎回同じ説明をしているなら、まず一つの業務を選び、AIへ渡している指示と参照資料を棚卸しすることから始めたい。長い指示書をさらに増やすのではなく、古いルール、重複したルール、例外条件、実測できていない前提を分けて記録する。それだけで、AIが迷う原因の多くは見えてくる。

AI導入の最初の問いは、「どれだけ自動化できるか」ではない。何をAIに判断させ、何を人間が検証し、どの情報を必要なときだけ開くのか。この問いを自社の業務へ置き換えられるかどうかが、これからのAI活用の差を生む。