今日のプロンプトチューニングの問題点
プロンプトは静的な設定ではありません。実際のプロジェクトで数か月以上LLM搭載エージェントを運用してきたのであれば、すでにこのことを知っています。前の四半期に完璧に機能していたプロンプトは、モデルの更新後にずれます。あるエージェント、例えば Cursor で信頼できる挙動を生み出したシステム指示は、Gemini や Claude へ移植すると異なる挙動を示します。そして、周囲の文脈が変化すると、同じプロンプトファイルでもプロジェクト間でわずかに一貫性のない結果を生むことがあります。
この状況への通常の対応は場当たり的です：何かがおかしいと気づき、作業中の会話を抜け、プロンプトファイルを編集し、エージェントを再実行し、以前の文脈を再現しようとします。その摩擦は蓄積します。会話の流れを失い、モデルが構築してきた中間の推論を失います。そして、スタックトレースのないシステム上でまるで print-statement デバッグをしているかのようです。
問題は、プロンプトチューニング自体が難しいことではありません。問題は、作業文脈の内部でそれを実行するための構造化された診断ループが存在しないことです。私にとって、この構造の欠如は繰り返しの痛点であり続けています。
ビデオウォークスルー：診断の実演
視覚的なディープダイブを好む場合、この投稿用のビデオがあります。リアルタイムで「ウェストワールド」の分析的雰囲気をたどり、モデルが実際のプロジェクトで「行う」から「報告する」へどのように転換するかを正確に示します。
クイックスタート: 診断モードの開始と終了
仕組みはシンプルです。.context/agent-diagnostics-mode.md に小さなファイルを置いています:
# Agent Diagnostics Mode
If user is referencing this prompt, you are in self-diagnostics mode. The goal of this mode is typically to understand your reasoning process, decision making, actions or results. Typically the user is trying to optimise your performance or behavior and tune their instructions to you.
The user may typically ask you something along with this prompt. You should analyse the user enquiry and report your findings based on the user enquiry.
**IMPORTANT:** You MUST NOT do any actions or modifications - just analyse and report your findings based on the user enquiry.
参照されるプロンプトファイルをサポートする任意のエージェントで診断モードに入るには、このファイルを私のメッセージに含めます（サポートしていないエージェントはあるのでしょうか？）。その効果は即座で顕著です：モデルは 行う から 報告する へ転換します。タスクの計画を停止し、推論を明確に説明し始めます。
Goプロジェクトの一つからの実例をここに示します。私の AGENTS.md には、2つの異なるタスク完了プロトコルが定義されています 例えば：コーディングタスク完了プロトコル（make lint を実行、make test を実行、カバレッジを確認、ステータスを報告）と 非コーディングタスク完了プロトコル（所見を要約、成果物を確認、リント/テスト不要）。意図は明らかです：コードの変更には検証が必要で、その他は不要です。
私にとって最も価値のある用途は、数か月前に書いて忘れていたプロンプトの仮定を思い出させてくれることでした。モデルはそれらを引用し、それを選んだ理由を正確に説明します。
フィードバックループとしてのプロンプトチューニング
全体のワークフローはタイトなループです：診断を入力 → 問い合わせ → アライメントのずれを特定 → 退出 → 変更を適用。エンジニアはその形を認識するだろう――それは REPL（対話型実行環境）、またはユニットテストの分離です。違いは、会話の文脈自体が作業記憶であり、あなたのプロンプトはコードファイルのようで、モデルを自分自身の挙動のデバッガとして使用していることです。
エッジケースと故障モード
モードのブリード。 一部のモデルは宣言を無視して行動を続けます。進行前に「診断モードにいることを確認してください」という明示的な確認ステップを追加すると、それ以上の操作を行う前に制約を処理するようモデルを強制します。
コンテキストウィンドウの枯渇。 長い診断スレッドはコストがかかります。応答が曖昧に聞こえたり再利用されたように感じられ始めたら、実質的な文脈は飽和している可能性があります。セッションは1つのプロンプトファイルに集中させ、異なる懸念には新しい文脈を開いてください。
モデル固有のばらつき。 指示に従うモデル――Claude Sonnet、GPT 系――は MUST NOT の制約をある程度信頼性高く守ります。私が使ってきた他のいくつかのモデルはそうでない場合があります。また、いくつかのモデルは非常に冗長な診断出力を生成する傾向があり、分析が難しいことがあります。私は grok-code-fast でこの挙動を見たことがあります。
参考資料
プロンプト設計と指示設計
- Anthropic: プロンプトエンジニアリング概要 — 信頼性の高いシステムプロンプトを構築するための実践的なリファレンス。 この技術で用いられるようなモード宣言指示の作成にも直接関連します。
- OpenAI: プロンプトエンジニアリングガイド — 指示の表現がモデルの挙動にどのように影響するかの仕組みを解説します。 これが「reorganize」のような語の選択がプロトコルの誤分類を引き起こす理由を説明します。
大規模言語モデルのアテンションと文脈挙動
- Attention Is All You Need (Vaswani ら、2017) — オリジナルのトランスフォーマー論文です。これを読むと、フレーミングとトークン順序がモデルが指示をどのように重み付けするかに影響を与える理由について、正確な直感が得られます。
エージェント指示パターン
- golang-backend-boilerplate AGENTS.md — 本投稿で参照されているタスク完了指示ファイルの実世界の例です。 自分のエージェントルールを構築する際のテンプレートとして有用です。
