課内のチケット業務と生成AI

こんにちは。EDUCOM に25年4月に中途入社のかどげんです。
課内のチケット業務にて生成AIを使って効率化しようとしたらRAGやMCPのような新しい技術よりも焦点をあてるべきポイントが現れ、結果として満足いく出来になったので紹介します。

先にまとめ

まずは、まとめます。
課題：繁忙期に課内のチケット対応業務負荷が高い。
対策：データを集約し、生成AIに必要な情報へアクセスさせる環境を整えた。
結果：データ集約を行ったことからファクトチェック機能が実装できたため、業務効率に寄与できた。

課題と対応策

弊社における課題を簡単に記載し、どのように対応したかを説明します。

チケット業務とRAG（検索拡張生成）

私が入社してすぐにチケット業務という言葉を聞いた時、
コールセンターの問い合わせ業務をRAG（検索拡張生成）で効率化している事例が頭に思い浮かびました。
そのため、過去のチケット業務の履歴を用いて生成AIが回答案を作成することで業務負荷を抑えることができるのではと考えました。

しかし、基本的にチケット業務は以下のフェーズを経て対応をしています。

1. 必要な情報を集める
2. 考察する
3. 回答案を作成する

ここで生成AIによるRAG（検索拡張生成）を活用して業務効率化を図ろうとしても、実際には以下のようなカバー範囲となり、あまり効率化につながりません。
むしろ、生成AIを使わずに必要な情報を収集するアプリケーションを作成する方が効率化へつながる可能性があります。

そこで、チケット対応業務において必要な情報を集めるフェーズに着眼しファクトチェック機能をアプリケーションに持たせることを考えました。

対応チケット例

ここから具体例を提示します。
弊社の製品がとある閉域のオンプレミス環境にて運用されており、
特定の期間まで利用しても問題ないか問い合わせがあったとします。
エンジニア観点で必要な情報は大きく2点考えられます。

1. OSの保守期限
2. ディスク容量

1のOSの保守期限に関してはお客様のサーバーのバージョンを確認し、そのOSがいつまでサポートしているのかを確認します。
2のディスク容量については、リソース情報を取得して容量推移を予測し、問題がないかを確認します。
しかし、この2の対象は閉域のオンプレミス環境であるため、サーバーにログインしてリソース情報を取得し、データを整形して計算していました。
さらに、この閉域のオンプレミス環境は物理的に複数の場所に点在しており、VPNを含めた接続方法も様々であることから手軽にリソース情報を取得するツールを導入することが難しい状況です。

リソース情報の集約

一方で、運用保守業務としてバックアップ通知メールの確認を行っており、ディスク容量がひっ迫した際には、その通知を原因調査や対応のトリガーとして活用していました。
このメールには各サーバのパーティション情報が記載されていたため、Google Apps Scriptを使ってDynamoDBへ転送することを検討しました。
お客様環境ごとにいくつか差異があったものの、データの格納に成功しました。
これにより、生成AIが各地のオンプレミス環境のリソース情報にアクセスすることができます。

作成したアプリケーションについて

アーキテクチャ選定を行う上で考慮に入れたことは以下です。

• インフラ課のメンバーが少しでもコードが読みやすいこと
• 自身もアプリケーション開発が個人学習レベルのみである
• 課内メンバーが使用する想定で多くても2,3人がアクセスするレベルである
• 本アプリケーション作成時はBedrock AgentCoreがプレビュー版である

上記を踏まえてAWS上の構成図はこのようになっています。

• 言語：Python
• フロントエンド：Streamlit
• バックエンド：Strands Agents, boto3, etc...

生成AIによる回答案作成機能

先ほどの例と同様にOSの保守期限と容量推移予測が必要な観点だとします。
プロンプトにはOSの保守期限と容量推移予測の観点で判断してくださいと仕込みます。
そのうえで生成AIにツール（スクリプト）を持たせることで必要な情報を取得できるようにしました。
ただし、必要なデータにたどりつくまでにいくつかのステップを踏む必要があったので今回はワークフロー型のAI Agentとすることにしました。

1. ユーザーの入力からOSの保守期限を確認するツールを実行
2. ユーザーの入力から対象地域のディスク使用量を取得
3. 取得したディスク使用量から線形回帰処理（近似直線）を行い、1.2倍バッファでディスク使用率が100%に到達する日を算出
4. 上記の結果を踏まえてOSの保守期限と容量推移予測の観点から特定の期間まで利用できるか回答

実行した結果の一部が以下となります。

その他、実行結果をMarkdownのテキストをダウンロードしてチケット管理ツールへ貼りつけるのを楽にするなど細かい機能を付けてみました。

    # ダウンロードボタンを表示
    if st.session_state.get("raw_responses"):
        raw_text = "\n\n---\n\n".join(st.session_state.raw_responses)
        timestamp = datetime.now().strftime("%Y%m%d_%H%M%S")
        st.download_button(
            label="回答案ドラフトをダウンロード",
            data=raw_text.encode('utf-8'),
            file_name=f"draft_{timestamp}.txt",
            mime="text/plain"
        )

容量推移確認機能

生成AI機能に線形回帰処理（近似直線）を搭載してしまったため、根拠があまりにもブラックボックスなので容量推移を可視化する機能を搭載しました。
これにより線形回帰処理（近似直線）で算出した結果が確からしいか簡単に判断でき、これまでサーバーへログインしてデータ整形を行うまでの手間を排除できています。
また、フレームワーク（Streamlit）にはダウンロードする機能がついているのでグラフは画像保存、表データはcsvとしてダウンロードすることができます。
これにより、生成AIによるデータ解釈に違和感があると担当者が判断した場合でも、
元データをもとに再加工・再確認を行い、担当者が回答根拠を作成できます。

所感とまとめ

最初にまとめた通り、以下の通りです。
課題：繁忙期にチケット対応業務の負荷が高い。
対策：データを集約し、生成AIに必要な情報へアクセスさせる環境を整えた。
結果：データ集約からファクトチェックを行う機能も追加できたので、明確に業務フローが改善された。

自身の作成したものが以下のカバー範囲になっているから業務負荷が軽減されたと感じています。

また、課内のチケット業務はチケットツールへの起票がトリガーとなっていることもあり、
そのまま自動でAIによるリコメンドとして起票するのが理想と考えています。
そのためにはBedrock AgentCoreを用いてバックエンドを分離することで、チケット管理ツールと今回作った画面の両方から同じロジックで生成AIを使えるようにしたいですね。

おまけ 線形回帰処理

課内で作成したドキュメントの抜粋ですが線形回帰処理が何をやっているのかを記載します。

NumPyのnumpy.polyfitを使って線形回帰を行っています。
x,yを配列宣言し、容量のデータを入れておき以下の要領で使用しています。

a, b = np.polyfit(x, y, 1)
a_buffered = a * 1.2

これだけで傾きaと初期定数bが決定し、1.2倍バッファも簡単に実装できるのはいいですね。

おまけ Q&A

本編では余談だなと思ったことを以下に記載します。

質問	回答
Q:なぜGCP使わなかったの？	A:案件の片手間しか時間がなかったこと、自分の周りにほぼ経験者がいないことなどを踏まえて採用を見送りました。
Q:"線形回帰処理（近似直線）で算出した結果が確からしいか簡単に判断できる"って何？	A:線形回帰処理（近似直線）はデータ個数が増えると正確さが増すのですが、ディスク使用量/使用率はアプリケーションのアップデート作業やNASの増強などを行うと簡単に増減します。そのため、グラフで可視化することで明らかなディスク増減を確認し、線形回帰処理（近似直線）による予測の確からしさが判断できます。
Q:RAGは使ってないの？	A:使わなかったです。プロンプトに仕込んで何とかなる規模感だったので使わずに済みました。