Claude CoworkのLive Artifactsで「Backlog通知トリアージ」を作ってみた

はじめに

こんにちは、クラスメソッドの長澤です。

複数のBacklogスペース（Classmethod／A社／B社）を掛け持ちしていると、Gmailの受信トレイがBacklog通知だらけになって、「これは自分宛のメンションなのか」「自分が作った課題の話なのか」を都度開いて確認するのが地味に手間でした。

以前、社内の記事（ClaudeCoworkの新機能『Live Artifacts』を使って業務効率化してみた）でメールの仕分けダッシュボードが自然言語だけで作れると知り、「これBacklog通知でもできるのでは」と思い立って、Claude Coworkに相談しながら作ってみました。

この記事はこんな人向けです

• 複数のBacklogスペースを掛け持ちしていて、通知メールの仕分けに時間を取られている方
• Claude CoworkのLive Artifactsに興味はあるけど、実際どこまでやってくれるのか気になる方
• Backlogのメール通知設定を細かくカスタマイズしたことがない方
• Live Artifactsを共有したときにデータがどう扱われるか気になる方

今回作ったもの

Gmailに届く未読のBacklog通知メールを開くたびに自動取得し、以下のカテゴリに仕分けて表示するダッシュボードです。

• 🔴 メンション・お知らせ
• 🟠 担当：新規アサイン
• 🟠 クローズ
• 🟡 コメント
• 🔵 状態変更
• ⚪ 自分の操作（対応不要・ノイズとして除外）
• ⚪ マイレポート（週次サマリ、別タブに分離）

タブ切り替え・検索・並び替え・カテゴリ別ドーナツグラフに加えて、行ごとに「対応済みにする」ボタンを押すとその場でGmail側を既読化できるようにしました。

実際にやってみた

STEP1：まずは「Backlog通知を仕分けたい」とだけ伝えてみる

最初のリクエストはシンプルに、こんな感じでした。

Backlogの通知を仕分けしてくれるツールを作りたいです。とりあえずプランを立ててみて。
私宛の通知はもちろん、私が作成したチケットにコメントが記載されたり、
クローズされたりしたら知りたいです。また、私が担当者のチケットが作られた場合や、
私が担当者のチケットにコメントがついたりしても知りたいです。

Claudeはいきなり作り始めるのではなく、先に確認質問をしてきました。

• Backlogの通知メールはGmailに届いているか
• 出力形式はLive Artifactでよいか
• 対象期間・Backlog上の表示名
• カテゴリの優先度付け

この時点でGmailの実データも見に行ってくれて、「あなたのBacklog表示名は"長澤"、通知は複数スペース（Classmethod／A社／B社、それに関係のなさそうな別スペース名も1つ）から届いています」と報告してきました。

ちなみにこの「関係のなさそうな別スペース名」は誤検出で、実際には別チケットの本文中にリンクが含まれていただけでした。指摘するとすぐに訂正し、対象は3スペースに絞られました。AIの一次情報だけを鵜呑みにせず、軽くファクトチェックするのは大事だと感じたポイントです。

STEP2：Backlogのメール受信設定が「メンションのみ」だったことが発覚

いざ仕分けロジックを作ろうとしたところで、大きな壁にぶつかりました。そもそも自分宛メンション以外の通知がGmailに届いていなかったのです。

Claudeが調べてくれた結果、Backlogのメール受信設定にはプロジェクトごとに「対象」という項目があり、初期設定または個人設定次第で「自分宛のお知らせのみ」に絞られてしまうことがあると分かりました。

対処法はシンプルで、Backlogの個人設定 → メール設定 → 「プロジェクトに関するメール」で「メールの種類やプロジェクトで指定する」を選び、対象を 「あなたが担当または登録」 に変更するだけです。これで担当課題・作成課題の追加／コメント／完了がすべてメールで届くようになりました。

STEP3：Live Artifactの構築

設定変更後、数日分の通知が溜まったタイミングで本体を作ってもらいました。分類ロジックは実際のメール文面（スニペット）に含まれる日本語パターンをそのまま正規表現で判定する方式です。

「Gmailを検索して仕分けるだけ」ではなく、開くたびにGmailへ再アクセスして最新の未読を取り直してくれる点がLive Artifactsらしいところです。

STEP4：使い込んで見つかった改善ポイント

作って終わりではなく、実際に触りながら何度か手直ししました。

① 自分自身の操作がノイズとして混ざっていた

Backlogのメール設定を「担当または登録」に変えた結果、自分が作った課題や自分が書いたコメントの通知まで自分に返ってくるようになりました。「長澤さんが◯◯さんに新しい課題を追加しました」のようなメールです。これは対応不要なので、「自分の操作」という専用タブに分離してもらいました。

② グラフがリストより不自然に大きく見える

カテゴリ別のドーナツグラフが、通知が少ない日にはリストよりも目立って大きく表示されてしまう問題がありました。リストパネルの高さを都度測定し、グラフパネルの高さをそれに追従させる（最小180px〜最大420pxでクランプ）ことで解消しました。

③ Gmail上で既読にしないと消えない

最初はGmailへの直リンクを開いて手動で既読にする必要がありましたが、「対応済みにする」ボタンを追加し、GmailのUNREADラベルをその場で外せるようにしました。

1件ずつのボタンに加えて、表示中を一括で対応済みにするボタンも用意しています。

④ スペースの表示がときどき間違っていた

一覧に表示する「どのBacklogスペースの通知か」の判定を、最初は送信元メールアドレスのドメインだけで行っていました。
ところが実際には同じドメイン（notifications-XXXX@backlog.com）が複数のスペースで使い回されており、B社の通知がA社と誤表示されるケースがありました。

本文中に含まれるBacklogのURL（スペースごとのサブドメイン）から判定するよう修正し、あわせて週次レポートメールは本文の「◯◯マイレポート」という文言からスペース名を直接取得するようにしました。

⑤ スレッドに新着があると、対応済みのはずの通知が復活して見える

Gmail上で同じ課題への通知がスレッドにまとまる設定にしていたため、「すでに対応済みにした古い通知」と「新しく届いた未読通知」が同じスレッドに同居することがありました。
Gmail検索のis:unreadはスレッド単位でヒットするため、スレッド内に1件でも未読があると、既読済みの古いメッセージまで一覧に含まれてしまっていたのです。

実際にはGmail側は正しく既読化されていたのですが、見た目上「対応済みにしたはずなのに戻ってきた」ように見えてしまう不具合でした。
取得したメッセージに実際にUNREADラベルが付いているかを個別にチェックするよう修正し、解消しました。

STEP5：一括処理で気づいたCowork自体の制約

ここが今回一番の学びでした。「表示中を全て対応済みにする」を実行すると、1件ごとに「Allow / Deny」の許可ポップアップが出てしまい、結局手動で何度もクリックする羽目に。

公式ヘルプには承認ポップアップの詳しい条件は書かれていませんが、Anthropic公式リポジトリの類似の不具合報告によると、データを変更するツール呼び出しは同一セッション内の初回だけ確認され、アーティファクトを開き直すとまた確認が必要になるようです。今回の挙動も同様のセッション単位の仕組みが関係していそうですが、公式仕様として明記されたものではなく、推測の域を出ません。

番外編：共有したら自分のBacklog通知が他人に見える？

Live Artifactは「Team/Enterpriseプランでのみ組織内共有が可能」で、共有してもデータは開いた本人の連携情報を使って取得されるため、他の人に自分のBacklog通知が見えることはありません。ただし共有リンクは受信者を個別指定できず、リンクを知っている組織内の誰でも開ける点は注意が必要です。

実際に共有してみると、共有先の画面ではまず必要なコネクタの承認を求められました。

Gmailのコネクタを承認すると、無事に共有されました。

共有先の画面には共有先自身のGmailが読み込まれていたので、「共有しても自分の通知が相手に見えることはない」という点を実際に確認できました。

やってみて感じたこと

良かった点

① 自然言語で要件を伝えるだけで、確認すべき点を先回りして聞いてくれる

いきなり作り始めず、Backlog表示名や優先度付けなど、仕分けロジックに必要な情報を先に確認してくれたので、手戻りが少なく済みました。

② 実データを見ながら設計してくれる

「メンションしか届いていない」という、こちらも把握していなかった問題を、実際のGmailデータを確認する中で見つけてくれました。プランだけで終わらせず、実データ検証まで踏み込んでくれるのは心強いポイントです。

③ 使いながらの改善が早い

グラフのサイズ調整や既読化ボタンの追加など、触ってみて気になった点をその場でフィードバックすればすぐに反映してくれるので、「一発で完璧なものを作る」のではなく「触りながら育てる」使い方がしやすいと感じました。

気になった点

• Backlogの通知メールは文面パターンに依存した仕分けになるため、Backlog側の文言が変わると分類ロジックの調整が必要になります
• データを変更する操作（既読化など）は、アーティファクトを開き直すと再び1件ずつ許可ポップアップが出るため、大量一括処理には不向きです（公式仕様ではなく推測）
• Live Artifactの共有は個人単位で権限を絞れず、社内共有の範囲設計は工夫が必要です

まとめ

こちらのLive ArtifactsのおかげでBacklogの確認が容易になりました。BacklogのAPIキーを払い出さす時に構築できたため、セキュリティ的にも安心です。

一方で、書き込み系操作の承認まわりは今回の環境ではネックとして残りました。セッション単位の挙動が関係していそうだとは分かったものの、公式仕様として明記されたものではないため、今後のアップデートで変わる可能性も含めて、現時点では詳細は分かっていません。

Backlog通知の管理に悩んでいる方は、まず「Backlogのメール受信設定」を見直すところから始めてみると、Live Artifacts抜きでも改善するかもしれません。