LLMの応答を制御するPrompt Engineeringの基本

Prompt Engineeringの再定義

Prompt Engineeringは、AIにうまくお願いする文章術という考え方から、LLMに渡す入力、役割、制約、例、出力形式を設計する作業へと見方が変わりました。これは、LLMの出力が想定外に揺れることや、表現がばらつくといった課題に対処するために重要です。特に、NMS(Network Management System)やチケットシステムのように、後続処理で利用するために一定の形式や精度が求められる場合に、この設計作業が不可欠となります。

背景：NMSにおけるLLM活用の課題

NMSの現場では、SNMP Trapやsyslogのような短いメッセージが大量に発生します。これらのメッセージから、重要度、顧客影響、一次対応で確認すべき事項、関連アラートの把握、チケットへの記載といった情報を効率的に抽出する必要があります。LLMに単に「このTrapを説明して」と依頼するだけでは、これらの業務要件を満たすことは困難です。出力を業務で使える形にするためには、Prompt Engineeringによる設計が求められます。

悪いプロンプトと良いプロンプトの違い

悪いプロンプトの例として「このログを分析して。」が挙げられます。これでは、分析の範囲、出力形式、対象者、重要度の基準が不明確なため、回答が自然文になったり、長すぎたり短すぎたりします。一方、良いプロンプトは業務要件を具体的に落とし込みます。例えば、「あなたはネットワーク運用センターの一次対応担当者です。以下のSNMP Trapまたはsyslogを読み、障害対応の初動判断に使える形で分類してください。重要度は high, middle, low のいずれかにしてください。過度に断定せず、ログから推測できる範囲で書いてください。出力はJSONのみとし、キーは severity, event_type, target, reason, first_actions にしてください。」のように、役割、分類ラベル、断定の可否、出力形式、必要なキーなどを明確に指定します。これは、単なる丁寧な指示ではなく、仕様書に近いものと言えます。

System MessageとHuman Messageの分離

LLMへの指示は、System MessageとHuman Messageに分けて考えることが重要です。System Messageは、処理全体の前提や振る舞いを定義する場所であり、例えば「NOC一次対応担当者として振る舞う」「断定しすぎない」「重要度ラベルは固定する」「出力はJSONにする」といったルールを記述します。一方、Human Messageは、その時々の具体的な入力（実際のTrapやログなど）を入れます。この分離により、毎回変わる入力と、毎回変えてはいけないルールを明確に区別でき、LLMの入力を扱いやすくします。これはバックエンド開発におけるサービス設定やポリシーとリクエストデータの関係に似ています。

SNMP Trap重要度分類器の例

具体的な例として、SNMP Trapやsyslogをhigh, middle, lowに分類する分類器を作成します。まず、分類基準を以下のように定義します。

• high: core router, firewall, gatewayなどの重要装置のDown、BGP neighbor down、複数サービスに影響しそうな到達性低下
• middle: access switchや一部interfaceの障害、CPU, memory, diskなどのしきい値超過、冗長構成が残っているが確認が必要なもの
• low: informational trap、一時的なwarning、直接のサービス影響が低いもの

これらの基準をSystem Messageに含め、実際のイベントをHuman Messageとして渡すことで、業務で利用可能なJSON形式での出力を目指します。期待される出力例は以下の通りです。

{
  "severity" : "high",
  "event_type" : "BGP neighbor down",
  "target" : "router-edge-03 / peer 10.10.0.2",
  "reason" : "BGP neighbor の状態変化は経路到達性に影響する可能性があるため。",
  "first_actions" : [
    "router-edge-03 の BGP neighbor 状態を確認する",
    "peer 10.10.0.2 への疎通と回線アラートを確認する",
    "直近の設定変更またはメンテナンス予定を確認する"
  ]
}

この出力は、severityを画面の色分けに、event_typeをチケット分類に、targetを対象抽出に、first_actionsを一次対応チェックリストとして活用できます。LLMの回答を単なる「読む文章」から「後続処理に渡せるデータ」へと近づけることが、Prompt Engineeringの重要な目的です。

出力の揺れとOutput Parserの必要性

しかし、プロンプトでhigh, middle, lowと指定しても、LLMが毎回その通りに返すとは限りません。例えば、”critical”や”high”のような異なる表現が使われたり、キー名が”target_device”や”actions”のように変わったりする可能性があります。このような出力の揺れは、アプリケーション側で厳密な形式を前提としている場合に問題となります。そこで、JsonOutputParserやPydanticOutputParserのようなOutput Parserの仕組みが重要になります。これらを利用することで、LLMの出力を期待されるJSONや型付きデータとして確実にパースし、業務システムで利用可能な形に整えることができます。

出典: https://qiita.com/bahamutra/items/c1a473ad35c1f61d4f54