AIプレゼンテーションエージェント用のシステムプロンプト: 開発者ガイド (2026)

AIプレゼンテーションエージェント用のシステムプロンプトは、ユーザープロンプトとは異なります — エージェントの役割、制約、出力契約を、特定のタスクではなくエンコードします。適切に作成されたシステムプロンプトは、汎用LLMを信頼性の高いスライド生成エージェントに変えます: 一貫した音声、予測可能な構造、呼び出し可能なツール使用。この開発者ガイドでは、2Slidesの独自エージェントパイプラインで本番環境で使用されている7セクションのシステムプロンプトテンプレート、Claude、GPT-4o、またはDeepSeekでスライドエージェントを構築するためのすぐに使えるシステムプロンプト、信頼性の低い出力を生成する3つのアンチパターン、そして2Slides V1 API(generate、create-pdf-slides、create-like-this、generate-narration、jobs/:id、themes/search)とシステムプロンプトを統合する方法について説明します。ガイドの最後には、3つの実例が紹介されています: 創業者のメモを投資家向けデッキに変換するピッチデッキエージェント、経営幹部向けに四半期メトリクスをフォーマットするボードデッキエージェント、PDFをプレゼンテーションに変換するインジェストエージェントです。

チャットボット、スライド出力を提供するコーディングアシスタント、またはレポート作成を自動化する社内ツールを構築している場合、デモと本番環境の違いは、ほぼ完全にシステムプロンプトにあります。このガイドは開発者向けに書かれています: マーケティングの誇大広告はなく、実際のコード、実際のエンドポイントのみです。

システムプロンプト vs ユーザープロンプト：実際の違いとは？

ユーザープロンプトはタスクです。システムプロンプトは操作マニュアルです。

プロダクトマネージャーが「Q3の収益について10枚のスライドを作って」と入力する場合、それはユーザープロンプトです。あなたのエージェントが一貫して有効なJSONを返し、スライドの予算を決して超えず、常にスピーカーノートで出典を引用し、ユーザーがファイルをアップロードした際に

create-pdf-slides

エンドポイントを呼び出す場合 — その動作はシステムプロンプトによるものです。

OpenAI、Anthropic、GoogleのAPIでは、システムプロンプトは独立したフィールドです(Anthropicでは

system

、OpenAIのチャット補完では

system

ロール、Geminiでは

systemInstruction

)。モデルはこれをユーザーのターンよりも高く重み付けし、後続のメッセージでは上書きできないものとして扱うよう訓練されています。これにより、以下の用途に適した場所となります:

ロール定義 — このエージェントがどのような種類のものか
出力契約 — JSONスキーマ、markdown形式、またはツール呼び出しの形式
ハード制約 — 文字数制限、トーンのルール、禁止コンテンツ
ツール/APIインベントリ — どの関数が呼び出し可能で、いつ呼び出すか
エスカレーションルール — いつ拒否し、明確化を求め、または引き継ぐか

これらすべてをエンコードしようとするユーザープロンプトは、ユーザーのタスクテキストが長くなった瞬間に破綻します。システムプロンプトはすべてのターンで機能し続けます。

7セクション・システムプロンプト・テンプレート

2Slidesで出荷または監査したすべての信頼性の高いスライド生成エージェントは、この7セクション構造のいずれかのバリエーションを使用しています。順序は重要です — LLMは初期の指示により大きな重みを置くため、役割と契約が最初に来ます。実例は最後です。

アイデンティティと役割 — エージェントが誰で、何をするかについての1段落の説明
出力契約 — エージェントが返さなければならない正確なスキーマまたは形式
ハードな制約 — 交渉の余地のないルール(長さ、トーン、禁止パターン)
ツールインベントリ — 利用可能な各APIまたは関数、呼び出しタイミングのガイダンス付き
推論ポリシー — エージェントがどのように考えるべきか(chain-of-thought、自己チェック、エスカレーション)
失敗処理 — 入力が曖昧、形式不良、またはトピックから外れている場合の対処法
実例 — 正しい動作を示す2〜4つの完全な入力/出力ペア

このテンプレートは意図的に意見を持っています。本番環境で誤動作するエージェントを監査する際、原因はほぼ常に不適切なセクションではなく、欠落したセクションにあります。ツールインベントリのないエージェントはエンドポイントを幻覚します。失敗処理セクションのないエージェントは、入力が不十分な場合にデータを捏造します。実例のないエージェントは、長い会話の中でトーンが変化します。

アイデンティティと役割

あなたはSlideAgentという、プレゼンテーション生成アシスタントです。あなたの仕事は、構造化されていないユーザー入力(メモ、トランスクリプト、PDF、生データ)を受け取り、2Slides V1 APIでレンダリング可能な構造化されたスライドデッキ仕様を返すことです。あなたは汎用チャットボットではありません。トリビアに答えたり、コードを書いたり、長い会話をしたりしません。スライドデッキを作成したら、停止します。

出力契約

作成するデッキを説明するすべてのユーザーターンに対して、次のスキーマに一致する単一のJSONオブジェクトを出力する必要があります:

{
  "title": string,              // 3-10単語、タイトルケース
  "audience": string,           // 例: "series-a investors"、"exec staff"
  "tone": "formal" | "conversational" | "technical",
  "slide_count": integer,       // 5 <= n <= 40
  "language": string,           // ISO 639-1コード、デフォルトは"en"
  "theme_hint": string,         // 自由記述、themes/searchに渡される
  "slides": [
    {
      "layout": "title" | "content" | "two-column" | "quote" | "chart" | "image",
      "heading": string,        // <= 12単語
      "bullets": string[],      // 0-5項目、各項目 <= 18単語
      "speaker_notes": string,  // 30-80単語、完全な文章
      "image_prompt": string?,  // オプション、imageレイアウト用
      "chart_data": object?     // オプション、chartレイアウト用
    }
  ],
  "api_call": {
    "endpoint": "generate" | "create-pdf-slides" | "create-like-this",
    "reasoning": string         // 1文: このエンドポイントを選んだ理由
  }
}

JSONの前後に説明文を入れないでください。JSONの周りにmarkdownフェンスを付けないでください。ユーザーがデッキリクエストではない質問をした場合は、次を返してください:

{ "error": "not_a_deck_request", "suggestion": string }

厳格な制約

40スライドを超えないでください。ユーザーがそれ以上を要求した場合は、40でキャップし、スライド1のspeaker_notesにその旨を記載してください。
すべてのスライドにspeaker_notesが必要です。空のspeaker_notesはバグです。
箇条書きは文法的に並列である必要があります(すべて動詞で始まる、またはすべて名詞句 — 混在は不可)。
統計を捏造しないでください。ユーザーが数字を提供しなかった場合は、数字を書かないでください。プレースホルダーとして「[要出典]」を使用してください。
ユーザーが明示的に提供しない限り、連絡先情報、電話番号、メールアドレスを含めないでください。
タイトルはタイトルケース。箇条書きは文頭大文字。すべて大文字は禁止。
名誉毀損的な内容、またはユーザーが出典を示していない医療、法律、財務上の主張を含むコンテンツの作成を拒否してください。

ツールインベントリ(2Slides V1 API)

これらのエンドポイントを呼び出すよう呼び出しコードに指示できます。あなた自身が呼び出すのではなく、"api_call"フィールドで名前を指定します。

generate — デフォルト。テキスト入力、デッキ出力。ほとんどのリクエストで使用。
create-pdf-slides — ユーザーがPDF URLをアップロードまたは貼り付けた場合。ユーザープロンプトでPDF URLを渡します。
create-like-this — ユーザーが「前回のデッキのように」と言った場合、または参照デッキURLを提供した場合。テーマ+構造を再利用。
generate-narration — デッキ構築後、各スライドにTTS音声を追加する場合。ユーザーが明示的にビデオまたはナレーションを要求した場合のみ呼び出します。
download-slides-pages-voices — レンダリングされたページと音声を一括ダウンロード。ビデオワークフローの最後に呼び出します。
jobs/:id — 非同期ジョブのステータスをポーリング。呼び出しコードがポーリングを処理します。あなたは処理しません。
themes/search — キーワードでテーマを検索。あなたの"theme_hint"フィールドが呼び出しコードによってここに渡されます。

推論ポリシー

JSONを出力する前に、タグ内でステップバイステップで考えてください:

ユーザー入力を解析。実際のデッキは何についてか?
オーディエンスを特定。投資家?エンジニア?取締役会?営業チーム?
コンテンツの密度に基づいてslide_countを選択(ユーザーのお世辞ではなく)。
エンドポイントを選択: generate(デフォルト)| create-pdf-slides | create-like-this。
アウトラインを下書きし、自己チェック: 箇条書きは並列?数字は出典あり?

の後、JSONオブジェクトを出力してください。最終出力に思考を含めないでください — 呼び出しコードはレンダリング前にブロックを削除します。

失敗処理

曖昧なトピック: エラーレスポンスの"suggestion"フィールドで1つの明確化質問をしてください。複数の質問をしないでください。
不正な形式の入力(ユーザーがでたらめを貼り付けた): { "error": "unintelligible_input", "suggestion": "..." }を返してください。
矛盾する指示(ユーザーが5分で50スライドを望む): 厳格な制約(最大40)を守り、スライド1のspeaker_notesに矛盾を記載してください。
無効に見えるPDF URL: それでもapi_call = create-pdf-slidesでJSONを出力してください。 URLを取得できない場合、バックエンドが明確なエラーを返します。

実例

例1: 最小限の入力

ユーザー: "Q3の収益について資料を作って。420万ドル達成、前年比30%増。対象は取締役会"

取締役会が対象 -> フォーマルなトーン。収益資料 -> 標準的に8-12スライド。数値は提供されている(ユーザーが提供)。エンドポイント: generate。 { "title": "Q3収益レビュー", "audience": "取締役会", "tone": "formal", "slide_count": 10, "language": "ja", "theme_hint": "minimal corporate finance", "slides": [ { "layout": "title", "heading": "Q3収益レビュー", "bullets": [], "speaker_notes": "オープニングスライド。..." }, ... ], "api_call": { "endpoint": "generate", "reasoning": "テキストのみの入力。参照資料やPDFなし。" } }

例2: PDF取り込み

ユーザー: "このホワイトペーパーをエンジニア向けに12スライドの要約にして: https://example.com/whitepaper.pdf"

PDF URLあり -> create-pdf-slides。エンジニアが対象 -> 技術的なトーン。ユーザーが12スライド指定 -> それに従う。 { "title": "ホワイトペーパー要約", "audience": "ソフトウェアエンジニア", "tone": "technical", "slide_count": 12, "language": "ja", "theme_hint": "technical documentation dark", "slides": [ ... ], "api_call": { "endpoint": "create-pdf-slides", "reasoning": "ユーザーがPDF URLを提供。" } }

例3: デッキリクエストではない場合

ユーザー: "what is the capital of France?"

{ "error": "not_a_deck_request", "suggestion": "I build slide decks. Try: 'make a 5-slide briefing on France'." }


上記のプロンプトは約1,800トークンです。これが推奨される上限です。それ以上長くすると、8kまたは16kのコンテキストウィンドウを持つモデルでは、ユーザーの実際の入力を圧迫し始めます。200kコンテキストのモデルでは、より多くのエッジケースをカバーするために、実例を安全に拡張できます。

## 2Slides V1 API との統合

システムプロンプトはエンドポイントを指定し、呼び出しコードがそれらを実行します。以下は各エンドポイントの機能と、エージェントがそれらを使用すべきタイミングの説明です。

- **`POST /api/v1/slides/generate`** — 主力エンドポイント。テキストプロンプトとオプションの構造化ヒント(スライド数、言語、テーマID)を受け取り、ジョブIDを返します。エージェントトラフィックの90%がこのエンドポイントを使用します。
- **`POST /api/v1/slides/create-pdf-slides`** — PDF URLを受け取り、デッキに変換します。ユーザーがドキュメントをアップロードした際に使用します。抽出、チャンク化、要約をサーバー側で処理するため、エージェント側でPDFパーサーは不要です。
- **`POST /api/v1/slides/create-like-this`** — 参照デッキのURLまたはIDと新しいトピックを受け取ります。参照のビジュアルテーマと構造的リズムを再利用します。「前回の取締役会資料と同じ見た目にして」というワークフローに使用します。
- **`POST /api/v1/slides/generate-narration`** — 既存のデッキにTTSボイスオーバーを追加します。スライドごとの音声URLを返します。出力が動画の場合、`generate`の後にチェーンして使用します。
- **`GET /api/v1/slides/download-slides-pages-voices`** — レンダリングされたページ画像とナレーション音声を1つのレスポンスで返すバッチエンドポイント。動画エクスポートパイプラインの最終ステップで使用します。
- **`GET /api/v1/jobs/:id`** — ポーリングエンドポイント。エージェントではなく、呼び出しコードが使用します。`pending`、`processing`、`success`、または`failed`のステータスと、完了時の最終デッキURLを返します。
- **`GET /api/v1/themes/search?q=...`** — 公開テーマライブラリ全体でキーワード検索を行います。`generate`を呼び出す前に、システムプロンプト出力の`theme_hint`フィールドをここに渡して、具体的なテーマIDに解決します。

完全なエージェントループは、疑似コードで次のようになります:

```ts
const completion = await llm.messages.create({
  system: SYSTEM_PROMPT,           // 上記の7セクションテンプレート
  messages: [{ role: "user", content: userInput }],
});

const spec = JSON.parse(stripThinking(completion.content));
if (spec.error) return handleError(spec);

const theme = await fetch(`/api/v1/themes/search?q=${spec.theme_hint}`);
const job = await fetch(`/api/v1/slides/${spec.api_call.endpoint}`, {
  method: "POST",
  body: JSON.stringify({ ...spec, themeId: theme.id }),
});

const result = await pollJob(job.id); // /api/v1/jobs/:id を呼び出す
return result.deckUrl;

APIの構造に不慣れな場合は、AIプレゼンテーションエージェント構築のための開発者ガイドで、動作するTypeScriptを使用した完全なフローを確認できます。システムプロンプトが複数のスキルの1つに過ぎない、より高度なスキルベースアーキテクチャについては、AIスライドエージェントスキルの概要をご覧ください。

スライドエージェントを壊す3つのアンチパターン

何十もの本番環境エージェント(内部分析ツールから顧客向けセールスコパイロットまで)をレビューした結果、同じ3つの失敗パターンが繰り返し現れています。

アンチパターン1: 無制限のアウトプット契約

症状: エージェントは時にはJSONを、時にはMarkdownを、時には丁寧な段落を返します。パーサーが50リクエストに1回の頻度で

SyntaxError: Unexpected token

をスローします。

原因: システムプロンプトが「スライドデッキを返す」とだけ言っていて正確な形式を指定していない、または形式を指定しているがその周りに散文を許可しています。

修正方法: システムプロンプトにスキーマを書きます。明示的に言います:「JSONの前後に散文を入れないこと。JSONの周りにMarkdownフェンスを入れないこと。」次に、すべての出力をバリデーター(Zod、Pydantic、io-ts)に通し、失敗時には再試行します。スキーマ準拠を、あれば良いものではなく、厳格なプロダクト要件として扱います。

アンチパターン2: ツールインベントリーのドリフト

症状: エージェントが自信を持ってユーザーに「

refine-deck

エンドポイントを呼び出します」と伝えます。そのエンドポイントは存在しません。ユーザーのデッキは届きません。

原因: システムプロンプトがツールを構造化されたインベントリーではなく散文で言及しているため、モデルがバリエーションを幻覚します。または、新しいエンドポイントをリリースした後にインベントリーが古くなっています。

修正方法: システムプロンプト内に単一の正規ツールインベントリーを維持し、APIが変更されるたびに更新します。APIに7つのエンドポイントがある場合は、正確に7つをリストし、それぞれに呼び出すタイミングを説明する1行を記載します。モデルが他の何かに名前を付けることを禁止します。「上記のエンドポイントのいずれも該当しない場合は、

api_call: null

を返してエスカレーションしてください。」

アンチパターン3: 統計の幻覚

症状: ユーザーが数値を提供せずに「Q3の数字についてデッキを作成して」と言います。エージェントは陽気に「売上高は47.3%成長して820万ドルに達しました」と書きます。CFOは激怒します。

原因: データの捏造を禁止する厳格な制約がありません。モデルは、仕様が不十分な場合に、ほとんどのLLMが行うように、もっともらしく聞こえる虚構をデフォルトにします。

修正方法: 明示的なルールを追加します:「統計を捏造しないこと。ユーザーが数値を提供しなかった場合は、プレースホルダーとして

[source needed]

を使用すること。」次に、正規表現または別のLLMチェックで疑わしい具体性を探して出力をスキャンします。この1つのルールは、私たちのレビューにおいて、他のどのルールよりも多くの顧客エスカレーションレベルのバグを検出しています。

実例1: ピッチデッキエージェント

ピッチデッキエージェントは、創業者のメモを10スライドの投資家向けプレゼンテーションに変換します。ベースとなるシステムプロンプトに以下の行を追加してください:

# 専門化: ピッチデッキモード
ピッチデッキを作成する際は、正確に以下の構成を使用してください:
1. タイトル
2. 課題
3. ソリューション
4. 市場規模(TAM/SAM/SOM)
5. プロダクトデモ / スクリーンショット
6. トラクション指標
7. ビジネスモデル
8. 競合
9. チーム
10. 資金調達の依頼(調達金額 + 資金使途)

slide_count = 10 を固定する。tone = "conversational but confident" を固定する。
ユーザーが市場規模、トラクション、または調達額の数値を提供しなかった場合は、
「[要情報源]」を使用する — 数値を捏造しないこと。

サンプル入力: "歯科医院向けB2B SaaS、保険請求の自動化を支援、有料顧客12社、シードラウンドで150万ドル調達中。"

サンプル出力(抜粋): 固定構成に従った10スライドのJSON、

api_call.endpoint = "generate"

、

theme_hint = "pitch deck modern gradient"

、トラクションスライドには架空の数値ではなく

["有料顧客の歯科医院12社", "[要情報源] — MRR", "[要情報源] — リテンション率"]

を表示。

実例 2: ボードデッキエージェント

ボードデッキには異なる要件があります。フォーマルなトーン、密度の高い表、絵文字ゼロ、そしてCFOが期待する特定のスライド順序です。次のように追加します:

# 専門化: ボードデッキモード
取締役会用に以下の構造を厳密に使用:
1. エグゼクティブサマリー(箇条書き3項目)
2. 財務情報(収益、利益率、ランウェイ)
3. KPIスコアカード(表形式レイアウト)
4. 戦略的施策(ステータス + リスク)
5. 採用計画
6. リスクと緩和策
7. 取締役会への依頼事項

tone = "formal" を強制。言語はユーザーのロケールに合わせる。
すべての数値には speaker_notes にソースを記載必須。
画像スライドなし — ボードデッキはテキストと表のみ。

ボードデッキエージェントは、取締役会が過去の四半期デッキを見ている場合、

create-like-this

とよく組み合わせられます。以前のデッキのURLを渡せば、新しいデッキはテーマとペーシングを継承します。

実例 3: PDF-to-Deck 取り込みエージェント

このエージェントは、顧客のホワイトペーパー、リサーチPDF、またはRFPを理解しやすいサマリーデックに変換します。2Slides の

create-pdf-slides

エンドポイントが大部分の処理を行うため、最も構築が簡単です。

# 専門分野: PDF取り込みモード
トリガー: ユーザーが .pdf で終わるURLを提供する、または明示的に
「このPDF/ホワイトペーパー/レポートをスライドにして」と言う。

常に api_call.endpoint = "create-pdf-slides" に設定。
PDFの長さに基づいて slide_count を設定:
  - < 5ページ -> 5スライド
  - 5-20ページ -> 8-12スライド
  - 20-50ページ -> 15-20スライド
  - > 50ページ -> 25-30スライド(上限30)

デックのタイトルにはPDFのタイトルを抽出。ユーザーがPDFの
元の対象者とは異なる対象者を指定した場合、スライド1の
speaker_notes にそれをフラグ付けして、レンダラーがトーンを
適応できるようにする。

Claude Desktop または同様のMCPホスト内で動作するエージェントの場合、PDF取り込みフローは1時間以内に配線できます — 完全なウォークスルーについてはClaude MCPを使用してプレゼンテーションを生成する方法をご覧ください。

よくある質問

システムプロンプトはコードに含めるべきか、データベースに保存すべきか?

本番環境のエージェントでは、バージョン管理システムに含め(ビルド時にインポートする

.md

ファイルとして)、リリースごとにタグを付けましょう。データベース保存型のプロンプトは柔軟に見えますが、ロールバックが困難になり、ログ内でどのプロンプトがどの出力を生成したかが不明瞭になります。テナントごとのカスタマイズが必要な場合は、テナント固有のオーバーライドをデータベースに保存し、リクエスト時にベースプロンプトとマージしましょう。

システムプロンプトはどのくらいの長さが適切か?

スライド生成エージェントの場合、1,500〜2,500トークンが最適です。短すぎるプロンプトは制約を見逃し、エッジケースで失敗します。長すぎるプロンプトは、コンテキストが小さいモデルでユーザーの実際の入力を圧迫し、同じ内容を繰り返しがちです。3,000トークンを超える場合は、冗長性を監査しましょう — 同じルールが2回記述されている可能性があります。

Claude、GPT-4o、DeepSeekでそれぞれ異なるシステムプロンプトが必要か?

軽微な調整のみで十分です。7セクション構成のテンプレートは3モデルすべてで機能します。ClaudeはXMLタグによる構造化(

<thinking>

、

<output>

)に良好に反応します。GPT-4oはクリーンなMarkdownと番号付きルールを好みます。DeepSeekは両方に対応しますが、より明示的な例があると効果的です。1つのベースプロンプトを作成し、モデルごとに小規模なフォーマットバリエーションをA/Bテストしましょう。

システムプロンプトを再デプロイせずに更新できるか?

はい — そして、高速な反復のためにできるようにすべきです。プロンプトを環境変数やフィーチャーフラグサービスに保存することで、SREが問題のあるプロンプトを数秒でロールバックできるようにします。問題のあるプロンプトは問題のあるデプロイと同様に扱いましょう:本番インシデントであり、同じ影響範囲制御が必要です。

システムプロンプトをどうテストするか?

実際のユーザー分布をカバーする50〜200の入出力ペアからなるリグレッションセットを構築します:正常系のデッキ、敵対的入力、不正なJSON試行、トピック外のリクエストなど。プロンプト変更ごとに全セットを実行し、スキーマ準拠性と人間による品質評価をスコアリングします。これはエージェントの信頼性向上において最も費用対効果の高いエンジニアリング投資です。

まとめ

システムプロンプトはインフラストラクチャであり、コピーライティングではありません。これは汎用的なLLMを、既知の出力契約、固定されたツールインベントリ、予測可能な障害モードを持つ信頼性の高いスライド生成エージェントに変換するものです。システムプロンプトを製品アーティファクトとして扱う開発者、つまりバージョン管理、テスト、監視を行う開発者は、実際のユーザーとの接触に耐えるエージェントを出荷します。これを一度限りのプロンプトエンジニアリング演習として扱う開発者は、デモを出荷するだけです。

このガイドで紹介した7セクションテンプレートと本番環境対応の例は、終着点ではなく出発点です。それらをフォークし、ユースケースに特化させ、2Slides V1 APIに接続し、そして最も重要なことに、出荷前にリグレッションハーネスを構築してください。2026年に勝利するエージェントは、コードと同じ厳密さでプロンプトが設計されたものです。

スライドエージェントを本番環境で出荷しましょう — 2Slides APIキーを取得するか、MCPサーバーを探索してください。