Slackの問い合わせ97.5%をAIが自動解決 — ShipStationが3ヶ月で406時間を節約したAI ITヘルプデスクの設計

10月14日、AWSが「How ShipStation Global built an AI IT help desk on Amazon Bedrock AgentCore」と題した記事を公開した。ShipStation GlobalがAmazon Bedrock AgentCore上にSlack連携のAI ITヘルプデスク「Deckhand」を構築し、問い合わせの97.5%を自動解決・3ヶ月で406時間を節約した実装事例だ。サーバーレス設計、Slackの過去ログを知識ベースに変換する仕組み、そして「答えない判断」のロジックまで、実運用に耐える設計の詳細が惜しみなく公開されている。

何を作ったのか

ShipStation Globalは、中小規模の出荷・物流向けプラットフォームを運営する企業だ。そのIT部門が頭を抱えていたのは、Slackのヘルプチャンネルに毎日流れ込む「同じ質問」だった。過去12ヶ月で1,500件超のスレッドが投稿され、質問の5分の1以上が米国営業時間外に届いていた。答えはConfluenceやイントラネットのどこかに必ずあるのに、探すのが手間だった。

そこで構築したのが「Deckhand」――Slack上で動くAI ITヘルプデスクエージェントだ。

アーキテクチャ：サーバーを持たないエージェント設計

Deckhantのアーキテクチャは4層で構成される。

Slack service：FastAPI + Slack Boltで実装し、AWS App Runner上でホスト。Slackイベントを受け取り、ユーザーのプロフィール（名前、メールアドレス、タイムゾーン、マネージャー）からコンテキストを組み立てる。
Agent service：Strands Agents SDKを使ったエージェントを、Amazon Bedrock AgentCore Runtimeのコンテナとしてデプロイ。サーバーもセッション管理も不要で、需要に応じた自動スケーリング・使用量ベースのコスト構造・運用負荷の大幅な軽減を実現できる点がこの設計を採用した主な理由だ。
Tools & Knowledge：単一のAWS Lambda関数をAgentCore GatewayがMCPツールとして公開。Jiraチケットの作成・更新、画像解析、リクエスト分類を担う。知識ベースはAmazon Bedrock Knowledge BasesとS3で管理。
Operations：DynamoDBがフィードバックを保存、AWS X-RayとOpenTelemetryでトレース、CloudWatchでログ管理。

エージェント本体のコードは非常に簡潔だ。

from strands import Agent
from strands.models import BedrockModel
from strands.tools.mcp import MCPClient
from strands_tools import retrieve
from mcp.client.streamable_http import streamablehttp_client

model = BedrockModel(
    model_id=MODEL_ID,
    max_tokens=2048,
    temperature=0.3,
)

gateway = MCPClient(lambda: streamablehttp_client(url=GATEWAY_URL))

agent = Agent(
    model=model,
    tools=[gateway, retrieve],
    system_prompt=SYSTEM_PROMPT,
)

モデルIDは環境変数で差し替え可能な設計にしており、コードを修正せずにモデルを切り替えられる。

最も面白い実装：Slackの会話履歴を知識に変える

技術的に一番興味深いのが、過去のSlackスレッドを知識ベースに変換する仕組みだ。

ITチャンネルには何年分もの「誰かが問題にぶつかり、ITが解決した」履歴が眠っている。ただしノイズも多い――雑談、自動アラート、結局解決しなかったスレッド。これを無検証でインデックスすると、誤った回答が正しい回答と同じ確度で出てきてしまう。

ShipStationはDSPyのRecursive Language Model（RLM）を使って3段階のパイプラインを組んだ。DSPyはStanfordが開発したLLMプログラミングフレームワークで、プロンプトの最適化や複雑なLLM処理フローの構造化を得意とする。RLMはDSPy上でLLM呼び出しを再帰的にネストできる仕組みで、今回のように「スレッドの分類→解決策の抽出→スキーマ検証」といった多段処理を一貫して記述するのに用いられている（DSPy公式ドキュメントも参照）。

Slack APIでチャンネルの全履歴をエクスポート。スレッドマーカー、タイムスタンプ、返信数を含む構造化ダンプを生成。
RLMがClaudeを使い、Pythonのサンドボックス型REPL上でエクスポートを「検索可能なメモリ空間」として扱う。各スレッドを「解決済み・未解決・エスカレーション済み」に分類し、お知らせや質問でないスレッドを除外。スレッド内に完全な解決策が存在する場合のみ「解決済み」と判定する厳格な基準を設けている。
解決済みスレッドに対し、RLMが再帰的なサブLLM呼び出しを行い、問題の要約・元の質問・解決策・自己解決ステップ・関連アプリケーション・エラーメッセージ・タグなどをPydanticモデルで検証しながら抽出。スキーマ検証に失敗した場合はインタプリタ上でキャッチしてリトライ。最終的にマークダウン文書としてS3に保存し、知識ベースでインデックス化する。

このアプローチによって、過去に同僚が解決した問題を従業員が尋ねた際、Deckhantは番号付きの手順として提示できる。

「答えない判断」のロジック

共有チャンネルで動くボットとして、いつ黙るかの設計も重要だ。Deckhantは以下のルールで応答を抑制する。

メッセージがアナウンス・雑談・人同士の会話なら「SKIP」を出力してSlack serviceが返信を止める
スレッド内では元投稿者にのみ返信
直前の返信が別の人間ヘルパーからであれば沈黙（人間が対応に入ったと判断）
返信が特定の人物への@メンションで始まる場合はボット宛てでないと判断

結果：3ヶ月で406時間を節約

Deckhantは2026年4月に本番稼働を開始し、約半年の運用実績を持つ。1日30件程度から始まり夏には最大100件まで増加した。最初の3ヶ月の実績は以下の通りだ。

指標	数値
処理メッセージ数	1,935件
エージェント会話数	1,221件
作成Jiraチケット数	409件
応答率	97.5%
時間外クエリの解決率	94%
従業員の肯定的フィードバック	96%（4月の82%から改善）

最大の成果はチケット削減だ。1,221件の会話のうち812件はチャット上で完結し、Jiraチケットにならなかった。チケット1件あたりの処理時間を約30分と見積もると、3ヶ月で406時間、年間換算で約1,600時間の節約になる。

セキュリティ設計

チケット作成には明示的な確認ボタンが必要で、コードレベルで強制
リクエスト分類はAmazon Bedrock Converse APIへの別呼び出しで実行し、Pydanticで検証後にのみJiraへ連携
画像解析ツールはSlackのファイルホストからのダウンロードのみ許可、1リクエストあたり最大5枚・5MBまで
Slackトークン、署名シークレット、Jira認証情報はすべてAWS Secrets Managerで管理
システムプロンプトでパスワードやMFAコードの要求を明示的に禁止

詳細はHow ShipStation Global built an AI IT help desk on Amazon Bedrock AgentCoreを参照していただきたい。