作ってから何か月も使い続けているプロンプトが、私にもいくつかあります。最初は確かに効きました。回答が散らかれば「段階的に考えて」と足し、形式が崩れれば例と手順を増やしました。モデルが変わっても、その一文だけは保険のように残していました。
ところが、いつからか様子が変わりました。答えは間違っていないのに、簡単な修正でも計画から始まり、説明ばかりが長くなります。ツールで確認できることまで言葉でなぞり、肝心の判断が埋もれていました。
最初はモデルの問題だと思いました。試しに新しいスレッドで依頼を4文に縮めてみると、その方が結果を確認しやすくなりました。そこで気づきました。古さそのものではなく、プロンプトが今も昔の役割を抱え込んでいることが問題だったのです。
まずモデルの劣化を疑った
見直したのは、障害ログを読み、再発原因を絞り、次に実行する確認コマンドを残す仕事です。従来のプロンプトは40行を超え、役割、思考手順、出力順、ツールの例まで書いてありました。
返答は一見丁寧でしたが、確認には時間がかかりました。ログで確かめた事実と推測が長文の中で混ざり、使っていないツールまで次の候補に挙げています。同じログに対して、目的、根拠の範囲、完了条件だけを残して依頼し直すと、原因候補は減り、確認コマンドは具体的になりました。
一度の結果で「短ければ正解」とは考えていません。文書確認、原因調査、表データの検品でも同じ比較を行い、確認時間を増やすだけだった指示から順に外しました。
見直すべきは日付より役割の重なり
今は文章ではなく、何を担当させているかで分けます。
Promptは目的と境界、Contextは今回必要な資料、Harnessは反復実行と検証を担当します。一つの文書に三つを詰めると、失敗した時の原因も見えにくくなります。
Promptに置くのは目的、制約、根拠の水準、完了条件です。Contextは作業対象のファイル、プロジェクト固有の規則、最新の証拠。Harnessは計画、ツール実行、テスト、再試行、人に戻す条件を扱います。
初期のAIアシスタント向けに作ったプロンプトは、この三つを一枚で背負っていることが少なくありません。結果が悪い時、指示が曖昧なのか、資料が古いのか、検証が動いていないのかを切り分けられないのです。
最初に外した文
一つ目は、行動基準のない役割設定です。「10年経験の専門家として」は、何を危険と見なし、どの根拠で決めるかがなければ雰囲気しか作りません。今は優先するリスクと、人に戻す条件を書きます。
二つ目は、思考過程を長く説明させる指示です。必要なのは隠れた推論の実況ではなく、ログや原文で確認できる根拠です。「全ての推論を示す」ではなく、「結論ごとに確認できる根拠を付け、不明な部分は推測と明記する」と変えました。
三つ目は、システム側に定義済みのツール説明の繰り返しです。例を残すのは、それが出力や行動を本当に固定する時だけです。
日付の固定も外しました。「今日は2025年8月」のような文は、コピーした瞬間から更新漏れの種になります。時点が重要なら実行日の値を渡し、出典には公開日と確認日を残します。
最後は、安心感のためだけに増えた詳細な手順と出力形式です。別システムが機械的に読む場合は固定します。社内規定で順序が決まっている場合も残します。それ以外は経路を縛るより、結果と停止条件を検査します。
消してはいけない情報
モデルが新しくなっても、こちらが書かなければ分からないことがあります。
- 顧客に誤った結果を出した時の損失
- 自動実行できる範囲と承認が必要な範囲
- 成功とみなす数値、途中で止める条件
- 契約や社内規定など推測してはいけない制約
- 次のシステムへ渡す時に必要な形式
これはプロンプトのテクニックではなく、仕事の知識です。古い指示を短くする目的は説明を減らすことではありません。人にしか分からない条件を、かえって目立たせることです。
プロンプトの役割を実行環境が引き取った
OpenAIのHarness Engineeringの記事は、AGENTS.mdを千ページの手順書にせず、必要な資料へ進むための短い地図にする考え方を示しています。文章で何度も頼むより、lintやテスト、CIで実際に確認できる制約にするという方向です。
出典: OpenAI, Harness engineering: leveraging Codex in an agent-first world、2026年2月11日。短い案内文書、段階的な情報開示、実行環境で守らせる制約を扱っています。
これは文書整理だけの話ではありません。「テストして」「失敗を直して」「この依存関係は使わないで」を毎回お願いするのではなく、環境がテストを実行し、違反なら止める。Promptが依頼内容を示すものなら、Harnessはそのルールを実際に動かす仕組みです。
同じ確認を人が何度も繰り返しているなら、テスト、スクリプト、権限、チェックリストへ移せないかを考えます。移せるものをプロンプトに残しておく必要はありません。
Contextは多いほど良い、でもなかった
規程、議事録、過去の会話を全部入れれば安全に見えます。しかし今回の作業に必要な情報が埋もれることがあります。AnthropicはContextを有限な資源と捉え、情報を詰め込みすぎると必要な情報を十分に活用しにくくなる「context rot」を指摘しています。
出典: Anthropic, Effective context engineering for AI agents、2025年9月29日。システム指示、ツール、外部データ、履歴を含めたContext管理を説明しています。
私は常時読み込ませる情報と、必要な時に取りに行く資料を分けました。常駐文書には目的、絶対に破れない規則、資料の場所だけを置きます。細かな規程、過去の振り返り、ツール別の説明は別ファイルにし、該当する仕事でだけ読ませます。捨てるのではなく、探せる状態にしておくのです。
同じ依頼をどう書き直したか
以前の文はこうでした。
あなたは経験10年の専門家です。段階的に考え、各段階の推論を説明してください。まず計画を作り、承認を待ってから作業を始めてください。
丁寧には見えますが、対象も根拠も完了条件も書かれていません。次のように変えました。
添付した障害記録から再発原因の候補を探し、可能性の高い順に根拠を付けてください。ログで確認できない原因は断定しないでください。運用担当者が次の確認コマンドを実行できる状態になれば完了です。
新しい文は考え方を演出しません。使う資料、根拠の境界、終わりの状態を示します。計画が必要ならエージェントが作り、承認が必要ならHarnessがそこで止めます。
新しいモデルが出た時の確認方法
モデルが更新されるたびに全てを書き換えることはしません。代表的な業務を三つ選び、現行版と短縮版を同じ条件で動かします。
- 利用者が受け取る結果は良くなったか
- 根拠のない断定は減ったか
- 人が確認する時間は短くなったか
- 修正依頼の回数は減ったか
- 失敗をPrompt、Context、Harnessのどこに戻せるか
一度の見栄えの良い回答では決めません。文書なら長さと難易度を変え、データなら欠損や形式崩れも入れます。特定の仕事だけ悪化した時は、削除した規則を狭い条件付きで戻します。削除にも履歴が必要です。
古いプロンプトをやめる、ということ
1年前の文が全て悪いわけではありません。顧客との約束や停止条件は、今も一番大切な一行かもしれません。ただ、モデルが既にできること、ツールで確実に検査できること、必要な時に読めばよい資料まで、毎回のプロンプトに抱えさせる必要はありません。
私がプロンプトに残すのは四つです。欲しい結果、越えてはいけない境界、採用する根拠、完了とみなす状態。 作業資料は必要な時に読み、反復できる処理はHarnessに任せます。
整理後に一番変わったのは回答の口調ではありません。失敗した時、依頼文を直すのか、資料を差し替えるのか、検査を追加するのかが見えるようになりました。その違いは、新しい決まり文句を一つ覚えるより大きいものでした。
