うまく機能していた特定のプロンプトが、突然機能しなくなった経験はありませんか？
結果を改善しようとシステムプロンプトを何度も修正しても、何もうまくいかないという悪循環に陥ったことはありませんか？
そんなときに必要なのが、システムプロンプト学習かもしれません。
システムプロンプト学習（SPL）は、AI コミュニティで注目を集めつつある分野であり、5 月に Andrej Karpathy 氏が X で広く普及させました。
システムプロンプト学習は、固定的なシステムプロンプトや扱いにくいファインチューニング構成に依存する、柔軟性に欠け壊れやすい AI システムの限界に対処します。AI システムの継続学習を支える新たな方法となります。
詳しく見る前に、プロンプト設計の基本を簡単に振り返りましょう。
エージェントやカスタムモデルを開発する際は、まず次の 2 つの主要要素を設計する必要があります。
システムプロンプト
ユーザープロンプト
システムプロンプトは、モデルの動作に関する基本ルールを定めます。カスタム AI ソリューション向けの場合、多くは次のような書き出しになります。
「あなたは知的なアシスタントです。あなたの役割は <ここにタスクを挿入> を実行することです。
（A）、（B）、（C）を行ってはいけません」
一方、ユーザープロンプトには通常、ユーザーの質問に加え、タイムゾーンや好みなどの関連情報が含まれます。ユーザープロンプトの例は次のとおりです。
ポルトガルの首都にいます。今夜できることをいくつか提案してもらえますか？
大手 AI 研究機関が新しいモデルを公開した後、ユーザーがチャットボットをジェイルブレイクして内部の指示を暴くことで、システムプロンプトが流出する事例が一般化しています。現在では、人気の GitHub リポジトリに、こうしたシステムプロンプトが多数まとめられています。そこからは、適切なモデル動作を促すために AI 研究機関が長年かけて培った「秘伝の工夫」が分かります。たとえば、最近流出した GPT-5 のシステムプロンプト（ChatGPT 内で露出）は約 6,000 語に及び、システムの動作を形作るために、いかに多くの知識と指針を組み込む必要があるかを示しています。
こうした包括的なシステムプロンプトは通常、次のような主要分野を網羅します。
検索に関する指示
ツールの定義
ユーザーの好み
引用に関する指示
既知の問題に対する応急修正
実際には、カスタム AI システムの開発者はアプリケーションをテストして改良する中で、主に評価を指針として、システムプロンプトを手作業で繰り返し修正しています。
モデルの動作を導くその他の方法には、次のものがあります。
モデルに提供する内容を制御する、検索拡張生成（RAG）を含むプロンプトエンジニアリング
ファインチューニング（モデルの基盤となる重みを直接変更）
モデルの動作に影響を与える別の方法があるとしたら、どうでしょうか？過去に生成した思考、計画、戦略を活用し、自らのシステムプロンプトを動的に学習・改良するシステムを想像してみてください。ユーザーからのフィードバックと LLM-as-a-judge 評価の両方を利用して、出力を評価できます。
エージェント型システムで自動化したい、長年のビジネス課題を考えてみましょう。効果的な解決策には、基本的なワークフロー自動化を超える推論能力が必要です。そのような場合、AI システムに計画生成機能を組み込むことが不可欠です。これにより、タスクに応じて複数のエージェントをさまざまな形で連携させられます。個々の手順には、サブタスクを完了するために別のエージェントへアクセスする指示や、ツールの使用が含まれる場合があります。
注：エージェントのツールとは、AI エージェントが呼び出すことで、テキスト処理の範囲を超えて実際のアクションを実行できる外部関数、API、リソースのことです。
人間が踏む論理的な手順に沿った計画をモデルのシステムプロンプトへ「種」として与えることもできます。ただし、LLM には通常、ツールの使用法、出力形式、関連要件について、より具体的な指針が必要です。最適な戦略が不明な場合もあれば、以前は解決済みと考えられていたため、再評価されていない問題に取り組む場合もあります。そこで役立つのが、システムプロンプト学習（SPL）です。
SPL は、過去に生成した戦略を取り込みながら、システムプロンプトを繰り返し改善します。新たな問題が生じるたびに知識が蓄積され、システムは徐々に堅牢になります。自社の領域で問題を解決するための手引きを作るようなものです。
SPL は、ユーザーからのフィードバックで得た知見をシステムプロンプトへ徐々に取り込みます。システムが成熟すると、繰り返し発生する問題を抽出し、より汎用的な上位原則へまとめられる場合があります。
プロセスの仕組みを手順に沿って詳しく見てみましょう。
まずユーザーのクエリから始め、特定のタスクを実行するようシステムに依頼します。
システムが 1 つの問題だけを扱う場合は、過去の実行で最もスコアが高かった戦略を選ぶ「貪欲法」を採用できます。一方、高評価の戦略を優先しつつ、低評価のものも時折含める分布からサンプリングすれば、探索を促せます。これは、戦略を集め始めたばかりの段階で特に役立ちます。
多様な問題群を扱うシステムでは、分類レイヤーを追加するか、埋め込みとコサイン類似度（RAG で一般的に使われるものと同じ手法）を使用して、関連するアプローチを特定することを検討します。これにより、コーディングタスク向けの戦略など、特定の問題に適した戦略を選択できます。
注：埋め込みとコサイン類似度を組み合わせると、2 つの情報がどの程度密接に関連しているかを測定できます。そのため、表現が完全には一致しなくても、文書、クエリ、アイデアを対応付けやすくなります。
コーディング問題に取り組むための簡略化した戦略ストアの初期例
注：ここに示す「シード戦略」は一例です。実際のコーディングでは、さらに改良します。ニッチなビジネス課題では、時間をかけて追加の知見を収集する必要があります。
Generation_id（降順） | テーマ | スコア | Strategy_text | 説明 |
|---|---|---|---|---|
4 | コーディング | 1 | 問題、制約、エッジケースを理解する。 適切なデータ構造を使ってアルゴリズムを設計する。 例と不変条件を用いて計画を検証する。 簡潔で読みやすいコードを実装する。 リファクタリング、最適化、最終的な書式調整で仕上げる。 ツールの使用：ツールを使用する際は、必要だった理由を簡潔に説明する。 | 以下の 3 つの戦略から、最も優れた要素を取り入れて組み合わせています。 |
3 | コーディング | 1 | 問題、制約、エッジケースを理解する。 適切なデータ構造を使ってアルゴリズムを設計する。 例と不変条件を用いて計画を検証する。 簡潔で読みやすいコードを実装する。 リファクタリング、最適化、最終的な書式調整で仕上げる。 | よりバランスの取れた戦略ですが、ツールの使用に関する指針がありません。 |
2 | コーディング | -1 | 問題、制約、エッジケースを理解する。 適切なデータを使ってアルゴリズムを設計する。 簡潔で読みやすいコードを実装する。 ツールの使用：ツールへアクセスする際は、そのツールを使用した理由を短くまとめる。 | ツールの使用に触れた、より優れた戦略ですが、まだ改善の余地があります。 |
1 | コーディング | -1 | 問題にざっと目を通す。 問題を解く。 最小限のテストを作成する。 動くものをそのまま提出する。 | テストには触れていますが、全体として不十分な戦略です。 |
3. N 個をサンプリングした後、システムプロンプトに取り込みます。これにより、最小限の指針だけでモデルに計画を作らせるのではなく、過去の専門家によるフィードバックを土台として計画を生成できます。モデルには、戦略の例をそのままコピーするのではなく、「既成概念にとらわれずに考え」、必要に応じて手順を追加するよう促します。
4. 動的に作成したシステムプロンプトを使い、ユーザーの依頼に対応する新しい戦略を生成します。このプロセスでは、最終出力を改善する追加タスクが生成されます。目標は創造性です。過去の戦略の優れた要素を組み合わせ、重複する手順を統合し、必要に応じて有用な新しい手順を追加します。
注：temperature は、出力の多様性を高めて決定論的な傾向を弱めるために調整できるパラメーターであり、創造性が求められる場合に役立ちます。temperature をゼロ以外にすると、生成される計画は毎回異なる可能性があります。
5. モデルの出力を受け取ったら、問題に対する優れた解決策の条件を示す具体的な基準に基づき、人間の評価者または LLM ジャッジで評価します。前述のポルトガルでのアクティビティの例では、次のような評価基準が考えられます。
簡潔さ（回答を 1 文に限定）
提案したアクティビティの関連性
場所の正確さ
6. この評価に基づき、別のモデルで戦略を改良します。必要に応じて、人間の意見を取り入れ、共同での改善を支援するフィードバックループも追加できます。バージョンと変更を追跡できるよう適切なメタデータを付け、改良した戦略をデータベースに保存します。
では、なぜここまで手間をかけるのでしょうか？出力を手作業で確認し、それに応じてシステムプロンプトを調整することもできます。しかし、高性能な推論モデルなら、出力のコンテキストと人間のフィードバックの両方を使って戦略を改良できます。単純な手法の欠点は人間でも容易に見つけられますが、より広範な問題群を扱う複雑なシステムでは、欠点の特定が難しく退屈な作業になります。
人間なら自然に問題へ持ち込める背景知識を収集するために、LLM には詳細な指示や追加の手順が必要になることがよくあります。より広範な問題群に対応するようシステムを拡張すると、必要なタスクの数は急速に増える可能性があります。たとえば、コーディング問題に取り組む人間は周辺のコードベースを直感的に理解できますが、LLM は最初に複数のファイルを「読む」必要があるかもしれません。
役立つ場合：カスタマーサポートチームを運営し、AI エージェントが問い合わせチケットを振り分けているとします。SPL により、チームが考慮していなかった分類方法が徐々に見つかり、エスカレーション率が低下する可能性があります。
役立たない場合：財務報告など、コンプライアンス要件や規制によってワークフローがすでに定められている場合、創造性は利点ではなくリスクになるため、SPL の価値は限定的です。
役立つ場合：市場情報分析や製品戦略など、調査が中心となる職務では、AI の計画を改良し、出力を充実させ、その改善内容を将来の利用に反映することで AI と協働できます。やり取りを重ねるたびに、システムの有効性が高まります。
役立たない場合：請求書処理など、人間の関与が少ない単純なワークフローで AI を主に使用する場合、連携に伴う負担が利点を上回る可能性があります。
役立つ場合：新しい地域に進出し、AI が現地の税務に関する問い合わせへ急きょ対応する必要が生じたとします。SPL なら、新しいルールや経験則が生まれるたびに素早く組み込み、同じ誤りの繰り返しを防げます。
役立たない場合：会議の文字起こしを標準形式の要約に変換する場合など、環境が変化しないなら、継続的に適応しても得られる効果はわずかです。
理論上は有望に思えますが、SPL の導入には現実的な課題があります。主な課題を以下で説明します。
戦略生成の初期段階では進展が止まりがちです。新しい出力が以前の出力を発展させられず、改善の勢いが鈍ります。通常、その主な原因は次の 2 点です。
解決策：利用可能なビジネス知識を最初からすべて組み込み、システムが十分な知識を活用できるようにします。
解決策：正確さ、明確さ、関連性など、回答の複数の側面を採点する精緻な評価基準を設計し、そのシグナルを反映するようサンプリングを調整します。
システムが数百もの戦略を生成しても、良し悪しを区別するフィードバックがほとんどなければ、サンプリングはすぐに管理不能になります。解決の鍵は枝刈りです。
戦略ストアを改良する際は、次の点を検討してください。
寿命：定めた期間または生成回数を超えた戦略は廃止します。
スコア：評価基準を使用し、一貫して成果の低い戦略を除外します。これを寿命と組み合わせることで、長期的に価値を実証した手法だけを残せます。
LLM による判定：戦略を定期的に評価し、独自の知見をもはや加えていないものを特定します。その有用な要素は、すでに新しいバージョンへ取り込まれている可能性が高いためです。
解決策：戦略データベースを生きたシステムとして扱い、関連性が高く価値のある知識だけが残るよう定期的に枝刈りします。
システムプロンプト学習はまだ黎明期ですが、大きな可能性を秘めています。固定的なプロンプトや際限のないファインチューニングだけに頼る企業は、壊れやすいシステム、増大するコスト、無駄な労力という、従来からの限界に直面します。SPL は、個別の応急修正ではなく上位原則を組み込み、時間とともに改善するシステムを構築することで、この悪循環から抜け出す道を開きます。
SPL はまだ発展途上ですが、進む方向は明確です。自ら学習できるシステムは、学習できないシステムを上回るようになります。今こそ、小さく実験を始め、知見を蓄積し、やり取りのたびに改善する AI システムの基盤を築くときです。