BacklogとNotionを連携する方法｜課題を週次報告へまとめる取得設計

開発チームはBacklogで課題を更新し、定例会議ではNotionに進捗をまとめる。この運用で、毎週同じ課題をコピーしているなら、課題一覧の取得と転記を自動化できます。

おすすめの始め方は、課題の正式な状態はBacklogに置き、Notionには報告用の情報を渡す構成です。実装担当者がBacklogで更新すれば、Notion側で参照する情報も追従するようにします。Notionで課題管理そのものを始める方法とは分けて考えましょう。

連携するのは、報告で使う課題の情報

架空のプロジェクト「DEMO」を例にします。課題本文や全コメントを毎回複製するより、会議で使う項目とBacklogへのリンクを持たせます。

Backlogの項目	Notionでの用途
スペース識別子＋課題の内部ID	同じ課題かを判定する
課題キー・件名	DEMO-123 のように人が識別する
プロジェクト・状態	プロジェクト別の進捗を分ける
担当者・期限日	担当未設定、期限未設定、期限超過を確認する
最終更新日時	前回取得から変わった課題を探す
課題URL	詳細やコメントの根拠へ戻る
取得日時	Notionがいつの状態を表しているか示す

課題キーは人が読むために残し、照合には内部IDも保存します。プロジェクトキーや表記が変わっても、別課題として重複登録することを避けるためです。

Notionで担当者が書く「会議で聞きたいこと」「管理者判断」は、同期する列とは分けます。Backlogからの取得のたびに、会議用メモまで上書きしないようにします。

APIで課題を取得する5つの手順

連携には、対象プロジェクトを閲覧できるアカウントのAPI認証を使います。APIキー等は連携基盤で保管し、Notionページや実行ログへ含めません。

1. 対象プロジェクトのIDを確認する。
2. プロジェクトで使われている状態一覧を取得する。
3. 対象条件を決め、課題一覧を最後まで取得する。
4. 課題IDでNotionと照合し、同期対象の列を反映する。
5. 取得件数・対象条件・取得開始／終了時刻を記録する。

課題一覧は /api/v2/issues で取得します。projectId[]、statusId[]、並び順などを指定でき、count は最大100件、offset で取得位置を指定します。Backlog公式：課題一覧の取得

たとえば count=100 で取得し、100件返ったら次は offset=100、さらに必要なら offset=200 と進めます。初回の100件だけをNotionに登録して、全件同期できたと判断しないことが大切です。

状態の名前と意味は、プロジェクトごとに対応付ける

「処理済み」「確認待ち」「完了」がどう使われているかは、チームによって違います。状態IDや名前だけで、顧客の確認まで終わったと決めつけないようにします。

Backlogには、プロジェクトの状態一覧を取得するAPIがあります。連携先のプロジェクトから実際の状態を取り出し、報告上の区分へ対応付けます。Backlog公式：プロジェクトの状態一覧

次の表は、業務側で合意する対応例です。実在するプロジェクトの状態を示したものではありません。

Backlog側の状態例	報告上の区分	会議で確認すること
未対応	着手前	担当と着手予定が決まっているか
処理中	作業中	進められない原因がないか
レビュー待ち	確認待ち	誰の確認を待っているか
完了	チーム定義上の完了	納品・リリース・顧客承認も含む定義か

対応表にない新しい状態が現れたら、「その他」として完了扱いにせず、未分類にします。プロジェクトの運用が変わったことを、報告側でも確認できるようにするためです。

「今週更新された課題」と「今週完了した課題」は違う

週次報告で間違いやすいのが、更新日時の扱いです。更新日時が今週でも、コメントを追加しただけかもしれません。現在の状態が完了だからといって、今週完了したとは限りません。

「今週完了した件数」を出すには、状態が変わった履歴を追うか、週ごとの取得結果を保存して比較する必要があります。現在の一覧だけしかない場合は、「取得時点で完了の課題数」「期間内に更新された課題数」と表現を分けます。

報告したい数字	必要な情報
現在の未完了数	現在の状態と、完了に含める状態の定義
期限超過数	期限日、現在の状態、基準日・タイムゾーン
今週新しく作られた課題数	作成日時と集計期間
今週完了へ移った課題数	状態変更の履歴、または比較可能な前回記録

期限未設定の課題は、期限超過に混ぜず別枠にします。「期限超過0件」とだけ書くと、全件が期限未設定でも順調に見えてしまうためです。

Notionの最新台帳と、週次報告の保存版を分ける

NotionにBacklogの最新状態を反映する台帳を作り、その台帳を見ながら週次報告をまとめます。ただし、過去の週次報告に最新台帳のビューを置くだけでは、翌週には表示内容が変わります。

報告時点の数字や課題一覧を残したいなら、週次報告へ次の情報を固定して保存します。

集計対象：DEMOプロジェクトの対象課題

取得日時：2026年10月22日 09:00〜09:02（日本時間）

状態区分：チームで確認した対応表に基づく

未完了・確認待ち・期限未設定の件数と、会議で扱う課題URL

数字は取得結果から計算し、AIを使う場合はその数字と課題情報をもとに文章を下書きさせます。AIに課題の雰囲気から完了数や遅延理由を推測させないようにします。

議事録との照合では、期限や担当の食い違いを出す

Notionに定例会議の議事録がある場合は、課題キーで関連付け、会議での発言とBacklogの現在値を比較できます。たとえば議事録に「DEMO-123は金曜までに確認」とあっても、Backlogの期限が空欄なら、未反映の候補です。

議事録にある内容	Backlogの状態	報告に出す確認事項
担当を変更する予定	担当が以前のまま	変更は確定したか、登録が必要か
今週中にレビューする	期限が未設定	具体的な期限と確認者は誰か
顧客への確認待ち	チーム内では完了	完了の意味が同じか

食い違いを見つけても、議事録の一文だけを根拠にBacklogを書き換えません。仮の発言だったのか、その後に方針が変わったのかを担当者へ確認します。Notionには「議事録の該当箇所」「課題URL」「確認したい点」を並べると、次の会議で決めることが明確になります。

件数が合わないときは、取得条件から確認する

Backlogには、条件に合う課題数を確認するAPIもあります。同じ条件で件数を照合すると、ページ分割の途中で止まったことなどに気づけます。Backlog公式：課題数の取得

ただし、一覧と件数は同じ瞬間の状態を保証するものではありません。取得中に課題が追加・更新されると、結果が動きます。取得した内部IDの重複を除き、差がある場合は条件と取得時間帯を見直します。厳密な時点比較が必要なら、履歴データや保存方式の設計も必要です。

更新分だけを取得する処理では、取得失敗時に「前回取得済み時刻」を進めないようにします。多少重ねた期間を再取得してIDで照合し、定期的に全体を突き合わせると、境界付近の取りこぼしを見つけやすくなります。

まず1プロジェクトを対象に、Backlogの一覧とNotionの件数・状態が合うことを確かめてください。そのうえで、報告に必要な判断や次の確認事項をNotionへ追加すれば、課題管理を二重化せずに定例会議の準備を減らせます。