1. はじめに
保守・運用の現場では、次のような問い合わせが頻繁に発生します。
- 過去に同じような障害は発生していないか
- 以前はどのような手順で復旧したか
- このエラーメッセージに対応した課題はあるか
- 似た構成で発生したトラブルはないか
- 既知の制約や暫定対応はないか
これらの回答に必要な情報は、すでにチケット管理システム等に蓄積されていることがありかと思います。
しかし、実際には次のような問題があります。
- 課題のタイトルや本文を一件ずつ確認する必要がある
- 担当者によって検索キーワードが異なる
- 過去の対応内容を読んで要点を整理するのに時間がかかる
- ベテランの記憶に依存している
- 新任メンバーが過去事例を活用しにくい
そこで今回は、ユーザーの問い合わせを自然言語で受け取り、チケット管理システム（今回はBacklog）の過去課題を検索し、関連事例を要約して返すワークフローをナレコムAI Agent Studio（詳細は本記事末尾に！）で作成しました。
2. 作成する問い合わせ対応エージェント
今回作成するエージェントの利用イメージは次のとおりです。
入力例
本番環境で、夜間バッチ実行時にデータベース接続エラーが発生しました。
過去に似た障害や対応事例があれば教えてください。
エージェントの処理
- 問い合わせ内容を受け取る
- Backlog検索に適した検索語を生成する
- Backlog APIの検索URLを生成する
- Backlogの課題を検索する
- 問い合わせと検索結果をLLMに渡す
- 関連する過去事例を要約する
- 回答を表示する
出力例
## 類似する過去事例
### 課題 #1234
- 概要：夜間バッチ実行時にDB接続数が上限に達していた
- 原因：バッチ処理の並列実行数が想定より増加
- 対応：接続プールの設定変更とバッチ実行数の制限
- 参考度：高
### 推奨される初動確認
1. DBの同時接続数を確認する
2. 対象バッチの並列実行数を確認する
3. 接続プールの設定値を確認する
4. 過去課題 #1234 の対応内容と環境差分を比較する
※上記は過去課題をもとにした参考情報です。
本番環境への変更は、通常の承認手順に従って実施してください。
3. 全体アーキテクチャ
今回のエージェントは、次のような構成です。
ワークフロー上のノード対応は次のとおりです。
| ノード | 役割 |
|---|---|
| ユーザー質問 | 問い合わせ本文を受け取る |
| BacklogベースURL | Backlog APIの接続先を受け取る |
| Backlog APIキー | 認証情報を受け取るための入力 |
| 検索語生成 | 問い合わせを検索向けの語句に変換する |
| Backlog検索URL | APIリクエスト用URLを組み立てる |
| Backlog課題検索 | Backlog APIを呼び出す |
| 結果統合プロンプト | 問い合わせと検索結果を統合する |
| 過去事例要約 | 関連課題を整理し、回答候補を作る |
| 検索結果表示 | 最終結果を表示する |
| Backlog認証ヘッダー | HTTPリクエスト用の認証ヘッダーを生成する |
4. 検索語生成
最初のポイントは、ユーザーの問い合わせをそのまま検索するのではなく、LLMで検索語に変換することです。
問い合わせには、検索に不要な背景説明や感情的な表現が含まれる場合があります。
たとえば、次の問い合わせを考えます。
昨日の夜から本番環境のバッチが失敗しています。
ログを見るとConnection refusedと出ています。
以前にも似たようなことがあった気がするので、関連する課題を探してください。
これを、そのまま検索するのではなく、次のような検索候補に変換します。
Connection refused
本番 バッチ DB接続
夜間バッチ 接続エラー
データベース 接続失敗
検索語生成用のシステムプロンプト例
あなたは保守・運用チケットの検索語を作成するアシスタントです。
ユーザーの問い合わせから、過去のBacklog課題を検索するために有効な
キーワードを抽出してください。
以下のルールに従ってください。
- エラーメッセージを優先する
- システム名、機能名、ジョブ名を抽出する
- 原因や症状を表す技術用語を含める
- 不要な敬語や背景説明は削除する
- 検索に使いやすい短い語句にする
- 可能であれば3〜5個の候補を出す
- 日本語と英語の両方が有効な場合は併記する
検索語生成用プロンプト例
以下の問い合わせから、Backlog検索用の検索語を生成してください。
問い合わせ：
{{input-1789014383462}}
出力形式：
- 検索語1
- 検索語2
- 検索語3
- 検索語4
ここで {{input-1789014383462}} は、ワークフロー上の「ユーザー質問」を参照しています。
5. Backlog検索URLの生成
検索語生成後は、Backlog APIを呼び出すためのURLを生成します。
今回の構成では、Backlog検索URL ノードが以下の値を利用します。
- BacklogベースURL
- 検索語生成LLMの出力
概念的には、次のようなURLを組み立てます。
{{input-1789014383562}}/api/v2/issues
実際には、Backlog APIの仕様に合わせて検索条件やクエリパラメータを追加します。
たとえば、構成例としては次のようになります。
{{input-1789014383562}}/api/v2/issues?keyword={{llm-1789014383762}}
ただし、実運用では検索語に空白、日本語、記号が含まれる可能性があるため、URLエンコードが必要です。
URL生成時の注意点
- 日本語をURLエンコードする
- 空白や改行を除去する
- 検索語をそのままURLに連結しない
- APIのページングに対応する
- 最大取得件数を制限する
- 検索結果が0件の場合を考慮する
6. Backlog APIの呼び出し
Backlog課題検索 ノードでは、生成したURLと認証ヘッダーを使ってBacklog APIを呼び出します。
このノードの主な入力は次のとおりです。
| 入力 | 内容 |
|---|---|
| URL | Backlog検索URLノードの出力 |
| headers | Backlog認証ヘッダーノードの出力 |
| body | 今回はGETリクエストのため使用しない |
HTTPレスポンスはJSONとして返されます。
{
"status": 200,
"statusText": "OK",
"headers": {
"contentType": "application/json"
},
"body": [
{
"id": 1234,
"issueKey": "PROJECT-123",
"summary": "夜間バッチでDB接続エラー",
"description": "接続プールの設定値を変更した。",
"status": {
"name": "完了"
}
}
]
}
ここで重要なのは、HTTPリクエストの結果をそのまま信頼しないことです。
たとえば、APIがエラーを返してもHTTPノード自体はレスポンスJSONを返します。そのため、次のような確認が必要です。
- HTTPステータスが200系か
- 認証エラーではないか
- 検索結果が配列になっているか
- 結果件数が上限を超えていないか
- 課題本文に機密情報が含まれていないか
7. 問い合わせと検索結果の統合
検索結果は、単にLLMへ渡すだけではなく、元の問い合わせとセットで渡します。
結果統合プロンプト では、次の2つの情報を統合します。
- ユーザー質問
- Backlog課題検索のレスポンス
統合プロンプトの例
あなたは保守・運用チームの問い合わせ対応アシスタントです。
以下の問い合わせについて、Backlogから取得した過去課題を参考に、
回答候補を作成してください。
## 問い合わせ
{{input-1789014383462}}
## Backlog検索結果
{{httpRequest-1789014384062}}
## 回答ルール
- 検索結果に含まれる情報だけを根拠として使用する
- 検索結果に根拠がない内容は推測しない
- 類似度の高い課題を優先する
- 課題キーやタイトルを可能な限り明記する
- 原因、対応、確認事項を分けて整理する
- 過去事例と今回の問い合わせが完全に同一とは断定しない
- 本番環境への変更を直接指示しない
- 必要に応じて担当者へのエスカレーションを提案する
- 日本語でMarkdown形式にする
このプロンプトで特に重要なのは、検索結果にない情報を推測させないことです。
AIドリブンな保守・運用では、もっとも避けたいのが「もっともらしい誤回答」です。
8. 過去事例の要約
最後に、過去事例要約 ノードで、統合したプロンプトをLLMに渡します。
出力は、単なる検索結果の羅列ではなく、運用担当者が次のアクションを判断しやすい形式にします。
推奨する回答フォーマット
## 回答概要
問い合わせに関連する過去事例が見つかりました。
## 類似する過去課題
### PROJECT-123：夜間バッチでDB接続エラー
- 発生事象：
- 原因：
- 実施した対応：
- 結果：
- 今回の問い合わせとの共通点：
- 相違点：
- 参照先：
## 今回確認すべき項目
1. ...
2. ...
3. ...
## エスカレーション判断
以下の場合は、担当チームへエスカレーションしてください。
- ...
- ...
- ...
## 注意事項
この回答は、過去のBacklog課題をもとに生成した参考情報です。
本番環境への変更は、承認済みの手順に従ってください。
このように回答の構造を固定すると、問い合わせ対応の品質をそろえやすくなります。
9. セキュリティと運用上の注意点
APIキーを直接プロンプトに埋め込まない
現在のワークフローには Backlog APIキー 入力ノードがありますが、キャンバス上ではHTTPリクエストへの直接接続は確認できません。
また、認証ヘッダーは Backlog認証ヘッダー ノードで生成されています。
そのため、実運用では次の点を確認する必要があります。
- APIキーが認証ヘッダー生成に正しく渡っているか
- APIキーがLLMのプロンプトに送信されていないか
- 実行ログにAPIキーが出力されていないか
- ユーザー入力としてAPIキーを毎回入力させていないか
理想的には、APIキーはエンドユーザー入力ではなく、環境変数や安全なシークレット管理機構で保持します。
検索結果の機密情報
Backlog課題には、次のような情報が含まれる可能性があります。
- 顧客情報
- 障害時のログ
- IPアドレス
- アクセストークン
- 内部システムの構成
- 個人情報
- セキュリティインシデントの詳細
そのままLLMへ渡すのではなく、必要に応じてマスキングを行います。
メールアドレス → [EMAIL]
IPアドレス → [IP_ADDRESS]
アクセストークン → [REDACTED]
顧客名 → [CUSTOMER]
AIの回答を最終判断にしない
このエージェントは、次の用途には適しています。
- 過去事例の検索
- 初動確認項目の整理
- 回答案の作成
- 担当者への引き継ぎ資料作成
一方で、次の処理は自動化せず、承認フローを残すべきです。
- 本番サーバーの設定変更
- データ削除
- 障害復旧操作
- 顧客への確定回答
- セキュリティインシデントの判断
- インフラリソースの停止・再起動
10.このエージェントの導入によって何が変わるか
今回のエージェントを導入することにより、問い合わせ内容を入力するだけで、AIがBacklogの過去課題を検索し、関連する事例や対応内容を整理して提示できるようになります。
これにより、問い合わせ対応は次のように変わります。
- 過去事例を探す時間を短縮できる
- 担当者ごとの検索方法のばらつきを抑えられる
- ベテラン担当者の経験をチームで再利用できる
- 新任担当者でも過去の対応履歴を活用できる
- 回答作成や初動調査の負担を軽減できる
- 問い合わせ対応の品質を一定に保ちやすくなる
導入前は、担当者がBacklogを検索し、課題の内容を読みながら必要な情報を整理していました。導入後は、AIが検索と要約を支援するため、担当者は検索作業そのものではなく、提示された事例が今回の状況に適用できるかを判断することに集中できます。
つまり、このワークフローは問い合わせ対応を完全に自動化するものではなく、担当者が必要な情報をより早く見つけ、より確実に判断するための支援基盤です。
11. まとめ
本記事では、ユーザーの問い合わせをもとにBacklogの過去課題を検索し、関連する障害事例や対応内容をAIが要約する「問い合わせ対応エージェント」を紹介しました。
このエージェントでは、LLMが問い合わせから検索語を生成し、Backlog APIで過去課題を取得します。その後、問い合わせと検索結果を再びLLMに渡すことで、類似事例や確認すべきポイントを整理して回答します。
ポイントは、AIに自由回答させるのではなく、Backlogの対応履歴を根拠として利用し、AIには検索と要約を担当させることです。これにより、担当者の経験に依存していたナレッジを、チームで再利用しやすくなります。
一方で、APIキーや課題内の機密情報の保護、検索結果の根拠表示、AIの誤回答対策は必要です。また、本番環境への変更や顧客への正式回答は自動化せず、担当者によって最終判断する運用が適しています。
今後は、検索結果の絞り込み、エラー処理、参照課題の明示、回答精度や対応時間の計測などを追加することで、より実用的な保守・運用支援基盤へ発展させられます。
12.最後に
ナレコムAI Agent Studioは、AIエージェントを誰でも“簡単に”作成できる法人向けSaaS型AIエージェントサービスです。従来の AI アプリ作成ツールでは、「操作画面が複雑で、直感的に使い方が分からない」、「コードやスクリプト作成のスキルが必須で、非エンジニアには敷居が高い」、「作成から公開までの工程が多く、作業時間が長引く」等の課題がありました。ナレコムAI Agent Studio は、エンジニアの経験がない社員の方が、自らの手でAIエージェントを簡単に作成できる環境を提供します。
詳細は以下をご参照ください。