はじめに
この１年間、私は筑波大学学園祭実行委員会 情報メディアシステム局、通称 jsys で局長をしていました。この記事は jsys Advent Calendar 2025 1日目の記事です。（12/2執筆）
代表アドレス１つで多くのメールを処理していると、担当者への割り振りやステータス管理が課題になると思います。今回は、実験的に運用してきたメール分類＋チケット管理についてご紹介します。
（読むにあたって、具体的な組織について書いたものでも、それを代表して書いたものでもありませんことをご承知おきください。）
構成
今回したいことは、
- 届いたメールをチケットにして追いたい
- 内容に応じて部門を振り分けたい
の２つ！
普通このようなことをしたいときは、ヘルプデスクツールを導入するのが一番素直な選択かと思います。有名なところだと Zendesk などがありますが、全員だともちろん、各部門の偉い人に割り当てようとするとかなり高額になってしまいます。（LLM モデルも使えるやつはそこそこ高いので、、というところはあります。ただデスクツールって内容による割り振りができるのか知らないので、LLM のコストは結局発生するのかもしれません。）
そこで、最近流行りのノーコードワークフローと LLM を組み合わせることで試してみました。
ワークフロー自体は単純で分かりやすいのですぐに作成できると思いますが、調整しないといけないポイントをまとめておきます。
調整しないといけないポイント
引用がついてくる
メールには過去のスレッドの引用がごっそりついてくるので、５回くらいやり取りをするとかなり長くなります。
背景情報を集めるときもスレッドを検索せずに済むのでいいのですが、、そのままメール本文として突っ込むとデメリットもかなりあり、
- LLM に渡すときのコンテキストも埋まってしまう
- 別の部門にリダイレクトされた場合に元の宛名が担当者になり続けてしまう
- リダイレクトなのか、単に関係者が増えただけなのか、内容まで見ないと分からない
- トークンを消費するのでお金がかかる
といった感じです。
これを解消するために、「要約」の部分で、
- 引用の区切り文字の生成
- スレッド全体の要約生成、本文の要約生成、本文の宛名部分の生成
と段階に分けて行っています。
勘違いやプロンプトエンジニアリングで Agent が動くと困る
「～の皆様」という宛名で送られたとき、Agent が「じゃあ全員かな」と全員を担当者にして Slack でメンションしまくったことがありました。こうならないように、ある程度のプロンプトエンジニアリングが必要で、担当者が明示的に宛名に含まれない場合は、まずは部門が含まれればそこの責任者に、含まれなければ本文から業務内容をコンテキストに含めて生成させ、それでも部門が分からない場合は、管理者をアサインするようにしました。
また、メールは誰でも送れるため、これをプロンプトに含めるからにはプロンプトエンジニアリングされる可能性があります。つまり、Agent が使用できるツールやアクセス先は限定して、外部ツールとの連携は Agent の外で行う必要があります。（まあ必要がないなら全て Agent にさせてワークフローは必要ないので、それはそうという感じですね。）
CC など処理できないメールが現れる
担当部門が分からないなど、処理できないメールが現れます。結局は人が見ないといけないこともありますが、その数は 1/30 程度（体感）で、意味はあると思います。
また、間違えることもあり人間による再アサインが必要になることもありますが、こっちは体感 1/100 程度とさらに精度が高い印象があります。
とはいっても、LLM モデル自体の性能にもかなり依存するので、コストと精度のバランスを取りながら監視して、どんどん改善していくといいと思います。
まとめ
対応漏れを防ぐ点でこの仕組みはかなり効果があり、今回はあまり紹介できなかったチケット管理を進めていくと、管理ももっと楽になると思います。
便利なものを使いつつ、各自の業務に専念できるようにするのも情報を所管する部門、いわゆる情シスの大事な業務だと思いました。
こういった the 情シス業務から、公式ウェブサイト・独自ウェブアプリケーションの作成、生配信システムの構築、ファイバー敷設、映像制作、ライブ撮影まで幅広く活躍する情報メディアシステム局はメンバーを大募集中です！
興味のある筑波大生は info@sohosai.com までご連絡ください！！
Discussion