DNAの解読：Claude Opus 4.7のシステムプロンプト変更を分析する

Hero

#はじめに

急速に進化する大規模言語モデル（LLM）の領域において、システムプロンプトはAIの性格、制約、動作指示を決定づけるDNAとして機能する。これは、単純なテキスト生成から複雑な複数ステップのツール実行に至るまで、あらゆる応答を導く「見えざる手」である。先日、Simon Willison氏がAnthropicのClaude Opus 4.6と新たにデプロイされたOpus 4.7間のシステムプロンプトの差分（diff）を詳細に分析して公開し、AIコミュニティはその内部の興味深い変化を目の当たりにした。

基盤モデルのバージョンアップといえば、ベンチマークスコアの向上やコンテキストウィンドウの拡大をうたうプレスリリースが伴うのが常である。しかし、システムプロンプトへの密かなアップデートは、開発者がAPIとどのように対話するかに、より即座で直接的な影響を与えることが多い。本記事では、実際に何が変更されたのか、Anthropicがなぜそのような調整を行ったのか、そしてOpus 4.7のポテンシャルを最大限に引き出すために開発者がエンジニアリングのアプローチをどう適応させるべきかを解説する。

#何が起きたのか：4.6と4.7の差分

Anthropicはこれまで、安全性、有用性、そして運用効率の絶妙なバランスを取りながら、システムプロンプトを非常に反復的に改善してきた。Opus 4.7への移行では、明確な優先順位の変化がうかがえる。抽出されたプロンプトに基づくと、以下の重要な変更点が際立っている。

思考の連鎖（CoT）の強制化: 4.6のプロンプトでは、モデルが「回答の前に<thinking>タグを使用してもよい（may use）」と緩やかに提案されていた。4.7では、これが複雑な分析タスクに対する厳格な指示へと格上げされ、最終的な出力を行う前に推論のステップを外部化することが強制されている。
ツール使用スキーマの洗練: 関数呼び出し（Function Calling）のための定型的な指示が大幅に簡略化された。JSONペイロードのフォーマットに関する長々とした例示の代わりに、4.7ではより抽象的なスキーマ駆動の指示に依存している。これは、モデルが持つ生来の構造理解能力が大幅に向上しているという前提に基づいている。
過剰な同調や謝罪の削減: 以前のClaudeモデルに対する根強い不満の一つに、過剰に謝罪したり同調したりする傾向があった。4.7のシステムプロンプトには、新たな条項が明記されている。「以前の誤りに対して謝罪してはならない。ユーザーにへつらってはならない。直接的で客観的な修正を提供せよ。」
時間的・文脈的グラウンディング: 日付の注入メカニズムが合理化された。現在の日付や知識のカットオフに関する冗長な説明の代わりに、4.7ではよりトークン消費が少なく、かつ同等のグラウンディングを提供する、高密度で機械可読なヘッダーフォーマットが採用されている。

#なぜこれが重要なのか

チャットインターフェースを利用する一般ユーザーにとっては、これらの変更は単に「少し直接的で、会話っぽさが減った」程度にしか感じられないかもしれない。しかし、Claude APIの基盤上に堅牢なアプリケーションや自律型エージェントを構築する開発者にとって、これらの変更は極めて重要な意味を持つ。

第一に、過剰な同調の削減はトークン効率に直結する。LLMが「混乱を招き申し訳ありません、全くその通りです」と出力するたびに、貴重な出力トークンが浪費され、レイテンシが増加する。この振る舞いをシステムレベルで明示的に禁止することで、Opus 4.7は高スループットの自動化タスクにおいて、構造的により高速かつ安価に利用できるようになる。

第二に、<thinking>タグの強制使用は、モデルのエラー率を根本的に変える。最終的な回答を生成する前に、計算リソースを推論に割り当てることを強制することで、Anthropicは人為的に回答の生成を遅らせ、正答の確率を高めているのである。これはプロンプトエンジニアリングにおける古典的なトレードオフであるが、今やモデルのデフォルト状態として直接組み込まれている。

#開発者に対する技術的な影響

Claude Opusに依存するインフラストラクチャを保守している場合、下流のパース処理のロジックを直ちに見直す必要がある。

#1. XMLタグのパースは必須

アプリケーションがXMLタグを除去していたり、適切に処理できていなかったりする場合、Opus 4.7はパイプラインを破壊する可能性が高い。<thinking>や<search_results>タグへの依存度が高まったことは、モデルの内部的な思考のノイズの中から最終的な回答を抽出できる堅牢なパーサーが求められることを意味する。ストリーミングXMLパーサーを実装し、エンドユーザーには<thinking>ブロックを隠しつつ、デバッグ用にログとして記録することを推奨する。

#2. ツール呼び出しのレイテンシ

システムプロンプト内のツール使用に関する指示が簡略化されたため、コンテキストウィンドウに読み込まれる全体の「プレフィックス」が小さくなった。これにより、Time-to-First-Token（TTFT）がわずかに短縮される。さらに、プロンプト内でのゼロショットの例示ではなく、モデルの内部的な重みに依存するようになったため、モデルがパラメータをハルシネーションする可能性も低くなっている。関数呼び出しを多用するワークフローでは、より低いレイテンシが期待できる。

#3. 独自のシステムプロンプトの調整

多くの開発者は、API呼び出し時に独自のシステム指示を追加している。もしカスタムプロンプトに「簡潔に答えよ」や「謝罪するな」といった指示を含めていたのであれば、それらは削除してしまって構わない。重複する否定的な制約を重ねると、モデルを混乱させたり、過剰補正を引き起こしたりすることがある。基盤モデルの新たなデフォルト設定を信頼し、カスタムプロンプトはドメイン固有のロジックに厳密に集中させるべきである。

#今後の展望

4.6から4.7への進化は、業界全体のより広範なトレンドを浮き彫りにしている。システムプロンプトは、人間が読める行動ガイドラインから、高度に最適化された疑似コードの実行環境へと移行しつつある。我々はAIに「どのような人格になるべきか」を指示する段階から離れ、「データをどのように処理すべきか」という厳密な操作マニュアルを提供する方向へと進んでいる。

将来的には、呼び出されるAPIエンドポイントに応じて動的に調整されるシステムプロンプト（例えば、/completeと/toolsで異なるプロンプトが使われるなど）や、ユーザーのコンテキストウィンドウの長さに応じて変異するプロンプトが登場することが予想される。

#おわりに

プロプライエタリなLLMのシステムプロンプトの変更を追跡することは、ドキュメント化されていないAPIをリバースエンジニアリングすることの現代版である。Claude Opus 4.7における、推論の強制、冗長性の排除、そしてツール使用の合理化へのシフトは、開発者向けツールや自律型エージェントのエンジンとして、このモデルを劇的に優れたものにしている。モデルの「DNA」におけるこれらの微妙な変化を理解することで、エンジニアはより高速で、回復力があり、コスト効率の高いAIアプリケーションを構築することができる。パースロジックに細心の注意を払い、<thinking>タグを受け入れ、トークンオーバーヘッド削減の恩恵を存分に活用しよう。