長い会話ではClaudeのシステムプロンプト遵守が低下する
Redditユーザーが報告するところによると、Claudeのシステムプロンプト遵守は長い会話で著しく低下し、特に特定の書式設定ルールや制約を持つAIコーディングエージェントに影響を与えています。
問題の詳細
ユーザーは内部ツール用に複数のClaudeベースエージェントを運用しており、各エージェントには出力形式、避けるべきトピック、エッジケース処理に関する具体的なルールを含むシステムプロンプトが設定されています。これらは最初の20〜30回のやり取りでは完璧に機能しますが、メッセージ40〜50付近で遵守が緩み始めます。
観察された具体的な問題：
- エージェントが書式設定ルールに従わなくなる
- システムプロンプトで明示的に禁止されている方法で「親切に」なりすぎる
- 開始時には明確だった制約を忘れてしまう
ユーザーは、これはバグではなく、コンテキストウィンドウが圧力下でどのように機能するかによるものであり、システムプロンプトが40以上のメッセージの会話履歴と注意の重みを競合していると指摘しています。
回避策と解決策
ユーザーが共有した実用的なアプローチ：
- 重要なルールを再提示する：15〜20メッセージごとに、失うことが許されない上位3つのルールを要約して再提示する（完全なシステムプロンプトではない）
- 会話を短く保つ：タスクに30回以上のやり取りが必要な場合は、何が起こったかの要約を添えて新しいセッションを開始する
- 戦略的なプロンプト配置：最も重要な制約をシステムプロンプトの最初と最後の両方に配置する。モデルは両方の位置により注意を払うため
- 大規模なテスト：エージェントをメッセージ5だけでなくメッセージ50でもテストする。順調なデモではこの問題は明らかにならないため
ユーザーは、この問題が十分に議論されていないことを強調し、長時間実行されるセッションで指示遵守を維持するための信頼性の高いパターンを共有するよう他のユーザーに呼びかけています。
📖 詳細はこちら： r/ClaudeAI
👀 See Also
ブラム・コーエンが「雰囲気コーディング」とAI支援開発手法を批判
ブラム・コーエンは、開発者がAIアシスタントを使いながらコードを見ない『バイブ・コーディング』はソフトウェアの品質低下を招くと主張し、Claudeのソースコード流出を例に、過度なドッグフーディングの問題点を示しています。
シンプルな自己蒸留法がLLMのコード生成を改善
研究者らは、大規模言語モデル（LLM）を自身のサンプリング出力でファインチューニングする（シンプルな自己蒸留）ことで、コード生成性能が向上することを示した。Qwen3-30B-Instructでは、LiveCodeBench v6におけるpass@1が42.4%から55.3%に向上した。
AIエージェント時代における「構築と購入のパラドックス」
時給100ドルの開発者が、月額30～50ドルの既存製品を避けて、Claudeとn8nで10時間以上かけて自作するという、1,000ドル以上の機会損失を無視した行動が広がっている。
GLM-5.1がリリースされ、コーディング性能がClaude Opus 4.5に匹敵
Zhipu AIのGLM-5.1モデルが、すべてのCoding Planユーザーに利用可能になりました。このモデルは、SWE-bench-Verifiedで77.8ポイント、Terminal Bench 2.0で56.2ポイントを達成しています。特徴として、200Kのコンテキストウィンドウ、128Kの最大出力、744Bパラメータ（40Bアクティブ）を備えています。