PLP: プロンプトをデプロイせずに差し替える標準仕様

PLP: プロンプトをデプロイせずに差し替える標準仕様 cover image

LLM（Large Language Model、大規模言語モデル）アプリケーションを本番運用していると、プロンプトの管理が意外と厄介です。「プロンプトを1行変えるだけなのに、フルデプロイが必要」「ドメイン専門家がプロンプトを直接編集できない」「どのバージョンがどの結果を出したか追跡できない」——こうした課題に対して、Prompt Library Protocol （PLP）という標準仕様が登場しました。

本記事では、PLPが提案する「Prompt Registry」（プロンプトを一元管理し、APIで配布する仕組み）という考え方と、その設計思想を解説します。

プロンプト管理の4つの痛み

まず、現場で実際に起きている課題を整理します。

1. コラボレーションの断絶

プロンプトの品質を最も改善できるのは、ドメイン知識を持つ非エンジニア（プロダクトマネージャー、ドメイン専門家）です。しかし、プロンプトはコードに埋め込まれているため、彼らは直接編集できません。

結果として、Googleスプレッドシートで30タブ以上のプロンプトをやり取りする、という事例も報告されています（Agenta社の調査より）。

2. デプロイとプロンプト変更の結合

プロンプトを1行変えるだけで、以下のプロセスが必要になります：

エンジニアにプロンプト変更を依頼
コードを修正してコミット
CI/CD（継続的インテグレーション/継続的デリバリー）パイプラインを通してデプロイ
本番環境で動作確認

この「デプロイ結合」により、プロンプトの反復改善サイクルが極端に遅くなります。A/Bテストも事実上不可能です。

3. バージョンカオス

LLMアプリケーションでは、プロンプト、モデル、パラメータの組み合わせが結果を左右します。しかし、これらのバージョン管理が適切に行われていないと：

どのプロンプトがどの結果を出したか追跡できない
ロールバックが「勘」に頼る
チームメンバーが変わると知識が消える

4. 障害時の原因特定困難

複雑なLLMチェーン（RAG: Retrieval-Augmented Generation、検索拡張生成 / エージェント: ツール呼び出し等を自律的に繰り返す実行形態）で問題が起きた場合、どこで失敗したかを特定するのが困難です。プロンプトのバージョン、モデルの選択、パラメータ設定——これらの組み合わせ爆発により、デバッグに膨大な時間がかかります。

Prompt Registryという発想

これらの課題を解決するために、PLPは「プロンプトは設定である」という考え方を提案します。

プロンプト = 設定

従来、プロンプトはコードの一部として扱われてきました。しかし、プロンプトは本質的に設定（Configuration）であり、以下と同じ性質を持ちます：

環境変数（.env）: アプリケーションの動作を環境ごとに切り替える
Feature Flags（LaunchDarkly 等）: 機能の有効/無効を動的に制御
設定ファイル（config.yaml）: パラメータを外部化して管理

これらはすべて「コードとデータの分離」という古典的な設計原則に基づいています。PLPは、この原則をプロンプトに適用したものです。

Prompt Registryの役割

Prompt Registryは、プロンプトを一元管理し、アプリケーションがランタイムで取得できるようにする仕組みです。これにより：

非エンジニアが直接編集: UIを通じてプロンプトを更新
デプロイ不要: アプリケーションを再起動せずにプロンプトを差し替え
バージョン管理: 各プロンプトの履歴を追跡し、ロールバック可能
環境分離: 開発、ステージング、本番で異なるプロンプトを使用

PLPの設計思想

PLPは、Prompt Registryを実現するためのプロトコル標準です。特定の実装を強制せず、相互運用性を重視しています。

3つのコアエンドポイント

PLPは、最小限のREST API（HTTPでリソースを操作するAPI設計）として設計されています：

1
2
3
GET  /v1/prompts/{id}           # プロンプトを取得
PUT  /v1/prompts/{id}           # プロンプトを作成/更新
DELETE /v1/prompts/{id}         # プロンプトを削除

「検索」「認証」「実行」といった機能は、意図的に仕様から外されています。これは、HTTPが認証を仕様に含めないのと同じ設計判断です。

Envelope構造

プロンプトは、以下の「Envelope（封筒）」構造で表現されます：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
{
  "id": "marketing/welcome-email",
  "content": "Hello {{name}}, welcome to {{product}}!",
  "meta": {
    "version": "1.2.0",
    "author": "shimon",
    "description": "Sent on user signup",
    "model_config": {
      "temperature": 0.7,
      "max_tokens": 500
    }
  }
}

id: プロンプトの一意な識別子（/で階層化可能）
content: プロンプト本体（変数{{name}}を含められる）
meta: 拡張可能なメタデータ（バージョン、作者、モデル設定等）

metaオブジェクトは拡張可能で、カスタムフィールドを追加できます。これにより、特定の実装に依存せず、将来の拡張にも対応できます。

Discovery機構

PLPサーバーは、/.well-known/plpエンドポイントで自身の機能を公開します：

1
2
3
4
5
6
7
8
9
{
  "plp_version": "1.0",
  "server": "my-plp-server",
  "capabilities": {
    "versioning": true,
    "list": false,
    "search": false
  }
}

これにより、クライアントは実行時にサーバーの機能を検出し、適切に動作を調整できます。

実装例: JavaScript SDK

PLPの公式SDKを使うと、プロンプトの取得は以下のように書けます：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
import { PLPClient } from '@goreal-ai/plp-client';

const plp = new PLPClient('https://prompts.example.com', {
  apiKey: 'optional-key'
});

// 最新バージョンを取得
const prompt = await plp.get('marketing/welcome-email');
console.log(prompt.content); // "Hello {{name}}..."

// 特定バージョンを取得
const v1 = await plp.get('marketing/welcome-email', '1.0.0');

Python SDKも同様のインターフェースを提供しています。

PLPが「しないこと」

PLPは、以下の機能を意図的に仕様から外しています：

認証・認可

認証方式（Bearer Token、OAuth等）は実装依存です。内部ネットワークで動作するサーバーは認証を省略できます。

検索・フィルタリング

プロンプトの検索機能は、実装によって大きく異なります（全文検索、タグ検索、メタデータ検索等）。PLPは最小限のCRUD（Create/Read/Update/Delete、作成/読み取り/更新/削除）操作のみを定義し、検索は拡張機能として扱います。

プロンプトの実行

PLPはプロンプトの管理に特化しており、LLMへの送信や結果の取得は含みません。これは、アプリケーション側で自由に実装できるようにするためです。

既存ツールとの関係

PLPは、既存のプロンプト管理ツールと競合するものではありません。むしろ、これらのツールが実装すべき共通インターフェースを提供します。

SaaS製品との関係

Langfuse 、PromptLayer 、Amazon Bedrock Prompt Management といったSaaS製品は、それぞれ独自のAPIを持っています。PLPに準拠することで、これらのツール間でプロンプトを移行しやすくなる可能性があります。

自前実装との関係

PLPのExpress middleware を使えば、最小限のコードでPrompt Registryを構築できます：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
import express from 'express';
import { plpMiddleware } from '@goreal-ai/plp-express-middleware';

const app = express();

// ファイルベースのストレージでPLPエンドポイントを追加
app.use('/v1', plpMiddleware({
  storage: './prompts-db'
}));

app.listen(3000);

これにより、SaaSに依存せず、社内でPrompt Registryを運用できます。

まとめ: プロンプトを"設定"として扱う

PLPは、プロンプト管理の課題を「コードとデータの分離」という古典的な設計原則で解決しようとしています。

Prompt Registry: プロンプトを一元管理し、ランタイムで取得
デプロイ不要: プロンプトの変更にアプリケーションの再デプロイが不要
標準化: 複数のツール間でプロンプトを移行可能

PLPはまだ新しい仕様（仕様書の更新は2026年1月、SPEC.md 参照）ですが、プロンプト管理の標準化という方向性は、LLMアプリケーションの成熟に伴って重要性を増していくでしょう。

興味のある方は、公式リポジトリで仕様を確認してみてください。

Fragments of verbose memory

冗長な記憶の断片 - Web技術のメモをほぼ毎日更新