SeaTicket、GitHub/Discord問題を統一管理するAIエージェント公開

Seafileはファイル同期の開source ソフトウェアとして2012年から保守されてきたプロジェクトですが、その過程で「誰か既に報告していないか確認してくれ」がチャットで最も頻繁に出る言葉となりました。同じバグが複数回報告される問題に直面した開発チームは、既存の別ツールではなく自分たちの内部で使うために SeaTicketを構築し、その後一般公開しました。

SeaTicketの基本的な仕組みは、GitHub Issues、Discord、Notion、Confluence、Linear、Jiraなど複数のプラットフォームを一つのワークスペースに接続することです。新しい課題が入ると、AIエージェントが関連する過去の課題、過去の解決方法、ナレッジベース内の関連情報を収集し、次のステップを提案します。ただしこの提案は自動で送信・返信・クローズされることはなく、ユーザーの承認を待ってから実行されます。開発チームが強調しているのは、「自分たちのユーザーと無監視でやり取りするツールは提供したくない」という設計哲学で、そのため SeaTicket自体も同じ原則で動作します。

開発チームが「本当に難しかった部分」と指摘しているのが、異なるプラットフォーム間で用語がほぼ共有されていない課題の照合です。例えば2行のDiscordコメントと10行のGitHubバグレポートが同じバグを報すしていても、キーワードがほぼ重ならない場合があります。この照合ロジックが SeaTicketの最大の技術的課題となっています。

SeaTicketはオープンソース保守者をはじめ、複数のリポジトリや複数のDiscordサーバーを管理するプロダクトチーム・サポートチームを想定しており、既存の Zendesk や Fin のような「サポートチームが共有チケット队列で作業する」モデルではなく「チームは既に GitHub を中心に動いており、そこで課題を処理したい」という前提で設計されています。料金体系には1ユーザーあたりのコスト（シート単価）がなく、無料プランを含むすべてのプランに適用されます。

Seafileの14年の保守経験から生まれたSeaTicketは、オープンソース開発の現場で繰り返し発生する「同じバグ報告の重複」という実務的な課題に直面した開発チームの解決策です。GitHubとDiscordを中心に問題がばらばらに報告される構造は、特にオープンソース保守者やプロダクト・サポートチームに共通ですが、既存のZendeskやFin（いずれもサポートチーム向けの統一チケット管理を前提）とは異なり、チームが既に使っているGitHubベースのワークフローを変えないことを設計の中心に据えています。技術的な難題として開発チームが指摘しているのが、用語がほぼ異なるプラットフォーム間の同一課題の照合です。料金にシート単価を設けない仕様も、複数の課題トラッキングツールを使う分散チーム向けの戦略と言えます。

まだコメントがありません。最初のコメントを投稿しましょう！