プロンプト設計とナレッジ（ドキュメント）活用

AI Agent Studio のプロンプトは、システム・プロンプト（エージェントの Prompt）、トピック、要約プロンプト、LLM ノードのプロンプトの 4 種類に分けて設計します。最終回答の見せ方は要約プロンプトで整えます
複数のエージェントで共通のルールはトピックに書きます。トピックの変更は、そのトピックを使う全エージェントに反映されます。システム・プロンプトの変更は、編集したエージェントだけに効きます
社内規程などの文書は**ドキュメント・ツール（Document）**で RAG のナレッジにします。状態を Ready to Publish にすると Process Agent Documents が動き、Published になって初めて検索の対象になります
誤回答（ハルシネーション）を減らす基本は、①公開前の評価、②正しいナレッジの供給、③「与えた情報以外を付け足したり推測したりしない」という明示的な指示、の 3 つです

全体像

4 種類のプロンプト

LLM に送られるプロンプトは、画面の複数の場所で書いた内容を組み合わせて作られます。どこに何を書くかを決めておくと、指示の重複や矛盾を防げます。

種類	設定する場所（26C）	書く内容
システム・プロンプト	エージェントの Prompts タブ（Agent Role、Prompt）、スーパーバイザーの System Prompt	人格（ペルソナ）、担当範囲、使うツールと呼ぶ順番、制約
トピック	エージェントの Available Topics で追加	検証、前提チェック、手順、ガードレール。複数のエージェントで再利用する
要約プロンプト	Prompts タブの Summarization Mode（Default／Custom／Disabled）と Summarization Prompt	ツールの処理が終わった後の、最終回答の見せ方
ワークフローのプロンプト	LLM ノード	分類や意図の抽出など、1 つの狭いタスク

公式ブログでは「出力の形式はシステム・プロンプトではなく要約プロンプトで設定する」と説明されています。また、LLM ノードは判断が必要な分岐点で使い、決まった処理は Code ノードに任せることが勧められています。

トピックとシステム・プロンプトの使い分け

トピック：専門領域ごとの指示のまとまりです。システム・プロンプトから $topic.<トピックのコード> の形で参照します。変更はトピックを使う全エージェントに反映されるため、公式 FAQ は「プロンプトではなくトピックを更新する」ことを推奨しています
システム・プロンプト：そのエージェント固有の役割と振る舞いを書きます。変更はそのエージェントだけに効きます
挨拶、エラー時の対応、範囲外の質問への対応など、どのエージェントにも必要な指示は共通トピックにします

トピックは「具体的に・簡潔に・中立な言葉で・1 トピック 1 テーマ」で書きます。複数の手順がある場合は「手順 1 に失敗したら、手順 2 と 3 に進まない」のような検証ゲートを入れます。

設定・実装の手順

1. システム・プロンプトを書く（役割・範囲・ツール・制約）

公式ブログは、システム・プロンプトを 5 つの層で組み立てる方法を紹介しています。

人格（Persona）：誰として、誰に対して答えるか
範囲（Scope）：答える領域と答えない領域、範囲外の質問への対応
ツール（Tools）：どのツールを、いつ、どの順番で呼ぶか。依存関係は「〜の前に必ず〜を呼ぶ」と明記する
制約（Constraints）：ツールの応答に基づいて答える、データを作り出さない、ツールのエラーは正直に伝える
トピック参照（Topic References）：使うトピックを $topic.<コード> で参照する

書き方のコツは次のとおりです。

「分類する」「要約する」「抽出する」「検証する」など、動作がはっきりした動詞を使う
長く書くより具体的に書く。まず短く書き、テストしながら足す
必須の入力がそろわないときは、ツールを呼ばずに利用者へ聞き返すよう指示する
個人情報をプロンプトに書かない。必要な情報は実行時にツールで取得する
業務ルールや前提（例：金額は税込、日付は計上日基準）を書いておく

2. 出力形式と言語を決める

回答の構成（結論 → 根拠 → 次の行動など）と長さは要約プロンプトで指定します。長さを指定すると冗長な回答を防げ、応答も速くなります
後続のノードに渡す値は、エージェントの Output タブで構造を決めます。上流の出力をまるごと渡さず、必要な項目だけを渡すとトークンが減ります
単純な後処理しかない場合は、要約プロンプトを使わずに指示をプロンプト本体へ入れると、LLM の処理が 1 段減って速くなります
利用者の言語で答えさせるには、ワークフローの Settings > Chat Experience で Answer in user’s language を有効にします。LLM ノードや Agent ノード単位でも設定できます

3. 説明文（Description）を書く

エージェント、ツール、トピックの説明文は、組み立てられたプロンプトに差し込まれ、振り分けやツール選択の判断材料になります。公式ブログは「説明文は契約書のように扱い、用語を厳密に定義する」よう勧めています。

対象	説明文に書くこと
スーパーバイザー	振り分けの方針と、どのワーカーに何を任せるか
ワーカー（エージェント）	担う機能、入力、出力、担当範囲
ツール	目的、入力、出力の構造、前提条件（いつ使うか）
トピック	対象領域、扱う意図、どんな質問で使うか

4. ドキュメント・ツールでナレッジを用意する

ドキュメント・ツールは AI Agent Studio の RAG（検索拡張生成）機能です。文書は アップロード → 解析とチャンク分割 → 埋め込み（ベクトル化） → 公開 の順に処理され、ベクトルは Fusion のテナント内のベクトル DB に保存されます。実行時は、質問に意味が近いチャンクを検索して回答の根拠にします。

Resources タブ > Tools サブタブ > Add で、Tool Type に Document を選ぶ
ツール名、説明、Family、Product を入力する（Code は自動入力）
Document セクションで Add Document を選び、文書の名前と説明を入力する
ファイルをドラッグ・アンド・ドロップするか Browse files で追加する
Status を Ready to Publish にして Create を選ぶ
スケジュール済プロセス Process Agent Documents が自動で動き、完了すると状態が Published になる
公開されたツールは、エージェントの Available Tools に表示される。ワークフローでは RAG Document Tool ノードでも使える

文書の作り方と上限は次のとおりです（26C の公式ドキュメント）。

見出し・小見出しで構造化する。見出しは続く内容の意味を表す言葉にし、1 つのセクションには意味的に関連する内容だけを入れる。見出しのレベルは見た目で区別できるようにする
画像やスキャンしたページは 1 文書あたり 5 つまで。超える場合は文書を分ける
1 ファイル 25 MB 以下にする。1 つの Document に入れるファイルは 20 個までを目安にし、多い場合は同じツールの中で Document を分ける
対応形式は PDF、DOCX、PPTX、TXT、HTML、MARKDOWN、JSON、XML、XLSX、CSV、JPG、PNG、ZIP（ZIP は RAG Document Tool でのみ利用可）
古い版の規程は削除する。文書は 1 つの業務領域に絞り、関連する文書を同じ領域にまとめる

ファイルの扱い方は目的によって使い分けます。

目的	使う機能	主な制限
会話中に 1 回だけファイルを読ませる	チャットのファイル・アップロード	1 会話 5 ファイル、合計 50 MB まで
規程・FAQ・手順書を繰り返し検索させる	ドキュメント・ツール	1 ファイル 25 MB、1 Document あたり 20 ファイルが目安
添付ファイルをバックグラウンドで処理する	Document Processor ノード	1 ファイル 25 MB
決まった項目を確実に抜き出す	Document Processor ＋ドキュメント・スキーマ	スキーマの定義が必須

業務データ（請求書の状況など）はビジネス・オブジェクト・ツールで取得します。SharePoint や Web ページは Connector、外部のシステムは外部 REST・MCP でつなぎます。文書と業務データを混同しないことが、正確な回答への近道です。

5. 誤回答を減らす工夫

公開前に評価する：Monitoring and Evaluation タブで、代表的な質問と境界ケースを評価します。ドキュメント・ツールを使う場合は、根拠への忠実さ（Groundedness）、回答の的確さ（Answer Relevance）、検索結果の適切さ（Context Relevance）も測れます
正しいナレッジを渡す：ビジネス・オブジェクト、RAG の文書、API やコネクタ経由の社内外の情報で、正確で最新の情報を参照させます
推測しないよう指示する：与えた情報以外を付け足したり推測したりしないよう、明示的に指示します
見つからないときの答え方を決める：該当する規程が見つからない場合は「見つからなかった」と伝え、問い合わせ先を案内させます
26D のガードレール：26D では LLM ノードで instruction guardrails を有効にでき、根拠に基づく回答と、範囲外・安全でない入力のかわし方を LLM に指示できます

コード例

システム・プロンプトの例

あなたはサンプル商事株式会社の経費精算規程に関する問い合わせ担当です。
回答する相手は社内の従業員です。

# 範囲
- 経費精算規程・旅費規程に関する質問だけに答えます。
- 給与・人事評価・個別の承認状況など、範囲外の質問には担当範囲を説明して丁寧に断ります。

# ツール
- 規程に関する質問には、必ず ExpensePolicyDocs ツールで規程を検索してから答えます。
- 検索結果に根拠がない場合は、推測で答えず「規程に記載が見つかりませんでした」と伝えます。

# 制約
- 回答はツールの検索結果に書かれている内容だけに基づきます。数値や条件を作り出しません。
- 金額の上限や締め日など数値を答えるときは、根拠となる条番号を添えます。
- 個人の経費明細や承認状況には答えません。

# トピック
$topic.XX_COMMON_OUT_OF_SCOPE

トピックと要約プロンプトの例

対象：担当範囲外の質問、規程に記載のない質問
1. 質問が担当範囲外であれば、担当範囲を一文で説明する。
2. 規程に記載がない場合は、推測せずに「経理部 経費精算窓口」への問い合わせを案内する。
3. 手順 1 または 2 に該当した場合は、ツールの結果を使った回答を作らない。

次の形式で、300 字以内の日本語で回答してください。
1. 結論（1〜2 文）
2. 根拠（規程の条番号と要点）
3. 次に取る行動（申請画面や問い合わせ先）
根拠が見つからなかった場合は、1 と 3 だけを書いてください。

ドキュメント・ツールの説明と文書の構造

サンプル商事の経費精算規程・旅費規程（2026年4月改定版）を検索する。
従業員が経費の上限、精算の期限、必要な証憑、精算できない費用を尋ねたときに使う。
個人の申請状況や承認状況の確認には使わない。

経費精算規程
  第1章 総則
    第1条 目的
    第2条 適用範囲
  第2章 交通費
    第5条 精算できる交通費
    第6条 タクシーを利用できる場合
  第3章 宿泊費
    第8条 宿泊費の上限額（地域別）
  第4章 精算の手続き
    第12条 精算の期限
    第13条 必要な証憑（領収書）

落とし穴とベストプラクティス

文書が Published になっていない：エージェントは Published の文書しか検索できません。5 分たっても変わらない場合は、権限 oraCommonFusionAISecurityAuthorization_create_Rag_OraResource を確認し、状態を Draft に戻して保存し、再び Ready to Publish にして保存します
1 つのセクションに複数のテーマを混ぜる：チャンクの意味がぼやけ、関係のない条文が検索されます。見出しごとに 1 テーマにします
出力形式をシステム・プロンプトに詰め込む：見せ方は要約プロンプトで指定し、システム・プロンプトは役割と振る舞いに集中させます
トピックとシステム・プロンプトで指示が矛盾する：どちらが優先されるか分からなくなります。共通のルールはトピックに一本化します
旧版の規程を残したまま新版を追加する：古い条文で回答されます。改定時は旧版を削除して再公開します

1 ツールごとに少なくとも 1 つのテスト・シナリオを作り、1 つのシナリオにつき言い回しを 10 通り以上変えて試すことが、公式ブログで勧められています
文書を更新・再公開したら、評価セットを再実行して回答の品質を確認します
振る舞いがおかしいときは、「現在のプロンプト」「誤った振る舞いをした質問」「期待する出力」を LLM に渡して改善案を求める方法が、公式ブログで紹介されています
26D では LLM の種類として Basic・Balanced・Frontier が用意されています。モデルが変わると指示の効き方も変わるため、モデルを変えたら評価をやり直します

試験対策ポイント

対応する試験：AI Agent Studio 模擬テストの「効果的なプロンプトの作成」「エージェントの構築」
4 種類のプロンプトの役割と、出力形式を要約プロンプトで整えることを覚えます
トピックとシステム・プロンプトの変更が及ぶ範囲の違い（全エージェント／そのエージェントのみ）がよく問われます
ドキュメント・ツールの状態遷移（Ready to Publish → Process Agent Documents → Published）と、Published でないと検索されないことを押さえます
文書の作り方（見出し、1 セクション 1 テーマ、画像は 5 つまで、25 MB）と、チャット・アップロード／ドキュメント・ツール／Document Processor の使い分けを区別します
ハルシネーションを減らす 3 つの方法（評価、ナレッジ、明示的な指示）を説明できるようにします