ShipStation Globalは2026年4月、Amazon Bedrock AgentCoreを基盤とするSlack上のAIヘルプデスク「Deckhand」を導入しました。社内ナレッジベースを検索してITや社内制度に関する質問に答え、エラー画面の画像を読み取り、Jira Service Managementのチケットを作成・更新します。最初の3カ月で1,935件のメッセージを処理し、1,221件の対話を開始して409件のチケットを作成しました。メッセージの97.5％に返信し、肯定的な評価は6月に96％でした。

導入前のSlackヘルプデスクには、12カ月で1,500件を超えるスレッドが寄せられ、問い合わせは増え続けていました。従業員は米国、英国、スペイン、ポーランド、オーストラリア、フィリピンで働き、質問の5分の1超は米国の営業時間外に届いていました。回答情報はConfluenceの記事、社内イントラネット、PDF、ITガイド、過去のSlackスレッドに分散し、定型的な質問への対応に時間がかかっていました。

DeckhandはSlackのスレッド全体と、依頼者の氏名、メールアドレス、タイムゾーン、上司などの情報を集め、隔離されたAmazon Bedrock AgentCoreの実行環境にあるエージェントへ渡します。エージェントはAmazon Bedrockのナレッジベースを検索し、依頼の分類、画像分析、Jiraチケットの作成・更新に使うツールを呼び出します。FastAPIとSlack Boltを使ったアプリケーションはAWS App Runnerで稼働します。Lambda関数は、エージェントとソフトウェアのツールを接続する標準規格「Model Context Protocol（エージェントとツールをつなぐ通信規格）」を使い、AgentCore Gateway経由でツールを提供します。Amazon S3は索引化した資料を保存し、DynamoDBは評価を保存します。AWS X-Rayはリクエストを追跡し、CloudWatchはサービスログを収集します。

ナレッジベースにはConfluenceの記事、社内イントラネットのページ、PDF、解決済みのSlack問い合わせスレッドが含まれます。チームは返信、タイムスタンプ、返信数を含むチャンネル履歴をエクスポートしてスレッドを抽出します。DSPyの「Recursive Language Model（言語モデルがデータを反復的に処理する方式）」がスレッドを解決済み、未解決、エスカレーション済みに分類し、告知や質問でない投稿を除外します。さらに、問題の要約、質問、解決策、自己解決手順などを抽出し、Pydanticのスキーマに照らして検証します。抽出データが検証に通らない場合は再試行し、完全で実行可能な解決策が示されたスレッドだけを解決済みと判定します。

Deckhandは告知、雑談、利用者同士の会話には返信せず、人間の担当者が対応を引き継いだ場合や、メッセージが別の人に宛てられている場合も応答を控えます。チケット作成には従業員による確認ボタンの選択が必要です。システムはチケット項目を検証し、画像のダウンロード先をSlackのファイルホストに限定します。1回の依頼で扱える画像は最大5枚で、各画像は5 MBまでです。SlackとJiraの認証情報はAWS Secrets Managerに保管され、各サービスには範囲を限定した個別のIAMロールが割り当てられています。プロンプトは、パスワードや多要素認証コードを尋ねること、チケットのコメントに認証情報を記載すること、チケット項目の入力に使うプロフィール情報を漏らすことも禁じています。

1日の利用は導入時の約30件から初夏までに最大100件へ増えました。質問の3分の1は営業時間外に届き、Deckhandはその94％に回答しました。チームが苦情を受けてシステムプロンプトとナレッジベースを改訂した後、肯定的な評価は4月の82％から6月の96％へ上昇しました。1,221件の対話のうち409件はチケットになり、812件はチャット内で解決しました。チームはチケット1件の起票、対応、完了に約30分かかると見積もり、812件の解決によって3カ月で約406時間、年間では約1,600時間分の作業を節約したと推計しています。

ShipStation Globalは2026年4月、Amazon Bedrock AgentCoreを基盤とするSlack上のAIヘルプデスク「Deckhand」を導入しました。社内ナレッジベースを検索してITや社内制度に関する質問に答え、エラー画面の画像を読み取り、Jira Service Managementのチケットを作成・更新します。最初の3カ月で1,935件のメッセージを処理し、1,221件の対話を開始して409件のチケットを作成しました。メッセージの97.5％に返信し、肯定的な評価は6月に96％でした。

導入前のSlackヘルプデスクには、12カ月で1,500件を超えるスレッドが寄せられ、問い合わせは増え続けていました。従業員は米国、英国、スペイン、ポーランド、オーストラリア、フィリピンで働き、質問の5分の1超は米国の営業時間外に届いていました。回答情報はConfluenceの記事、社内イントラネット、PDF、ITガイド、過去のSlackスレッドに分散し、定型的な質問への対応に時間がかかっていました。

DeckhandはSlackのスレッド全体と、依頼者の氏名、メールアドレス、タイムゾーン、上司などの情報を集め、隔離されたAmazon Bedrock AgentCoreの実行環境にあるエージェントへ渡します。エージェントはAmazon Bedrockのナレッジベースを検索し、依頼の分類、画像分析、Jiraチケットの作成・更新に使うツールを呼び出します。FastAPIとSlack Boltを使ったアプリケーションはAWS App Runnerで稼働します。Lambda関数は、エージェントとソフトウェアのツールを接続する標準規格「Model Context Protocol（エージェントとツールをつなぐ通信規格）」を使い、AgentCore Gateway経由でツールを提供します。Amazon S3は索引化した資料を保存し、DynamoDBは評価を保存します。AWS X-Rayはリクエストを追跡し、CloudWatchはサービスログを収集します。

ナレッジベースにはConfluenceの記事、社内イントラネットのページ、PDF、解決済みのSlack問い合わせスレッドが含まれます。チームは返信、タイムスタンプ、返信数を含むチャンネル履歴をエクスポートしてスレッドを抽出します。DSPyの「Recursive Language Model（言語モデルがデータを反復的に処理する方式）」がスレッドを解決済み、未解決、エスカレーション済みに分類し、告知や質問でない投稿を除外します。さらに、問題の要約、質問、解決策、自己解決手順などを抽出し、Pydanticのスキーマに照らして検証します。抽出データが検証に通らない場合は再試行し、完全で実行可能な解決策が示されたスレッドだけを解決済みと判定します。

Deckhandは告知、雑談、利用者同士の会話には返信せず、人間の担当者が対応を引き継いだ場合や、メッセージが別の人に宛てられている場合も応答を控えます。チケット作成には従業員による確認ボタンの選択が必要です。システムはチケット項目を検証し、画像のダウンロード先をSlackのファイルホストに限定します。1回の依頼で扱える画像は最大5枚で、各画像は5 MBまでです。SlackとJiraの認証情報はAWS Secrets Managerに保管され、各サービスには範囲を限定した個別のIAMロールが割り当てられています。プロンプトは、パスワードや多要素認証コードを尋ねること、チケットのコメントに認証情報を記載すること、チケット項目の入力に使うプロフィール情報を漏らすことも禁じています。

1日の利用は導入時の約30件から初夏までに最大100件へ増えました。質問の3分の1は営業時間外に届き、Deckhandはその94％に回答しました。チームが苦情を受けてシステムプロンプトとナレッジベースを改訂した後、肯定的な評価は4月の82％から6月の96％へ上昇しました。1,221件の対話のうち409件はチケットになり、812件はチャット内で解決しました。チームはチケット1件の起票、対応、完了に約30分かかると見積もり、812件の解決によって3カ月で約406時間、年間では約1,600時間分の作業を節約したと推計しています。