NotionとBacklogを併用するなら、「何をどちらで更新するか」を先に決めます。例えば、決定の理由や仕様はNotion、作業の担当・期限・状態はBacklogへ記録し、互いのURLで参照する運用です。同じ期限や進捗を両方で編集すると、どちらが最新か分からなくなります。
2026年9月15日、公式情報を確認。この記事の役割分担・記入例はライトログ作成の運用案です。両サービスを接続して効果や自動同期を実測した記事ではありません。
併用するか、1つにまとめるかを決める
現在のツールで、必要な資料を読める・担当と期限を追える・完了を確認できるなら、すぐにもう1つ追加する必要はありません。人数だけで「5人以下は単独、それ以上は併用」と判断せず、困っている作業を具体的に挙げます。
| 現状 | 検討する順番 |
|---|---|
| Notionで作業も資料も見つかり、更新に困っていない | そのまま運用し、不足が出た項目を記録する |
| Backlogの課題と同じ場所に手順・仕様を置きたい | まずBacklogのドキュメント機能で足りるか確認する |
| 社内の資料はNotionに定着し、実行チームはBacklogで課題を管理している | 資料と課題を相互リンクする併用を試す |
| 同じ担当・期限・状態を2か所に入力している | ツールを増やす前に、項目ごとの更新先を1つにする |
Backlogにもドキュメント機能があります。「Backlogは文書管理ができないからNotionが必須」とは考えないでください。公式案内では、2026年7月14日以降の新規スペースではWikiを提供せず、ドキュメントを利用する方針です。既存スペースのWikiは継続利用でき、そこで新規作成するプロジェクトはWikiが初期状態でオフになる、という区別があります。Wiki提供方針の公式案内
二重入力を防ぐ役割分担の例

| 情報 | この例での更新先 | もう一方に置くもの |
|---|---|---|
| 決定事項・背景・仕様 | Notionの該当ページ | Backlog課題に参照URLと必要な要約 |
| 担当者・期限・作業の状態 | Backlogの課題 | Notionに課題キーと課題URL |
| 作業中の質問・確認結果 | 対象のBacklog課題 | 仕様が変わった場合だけNotionにも決定を反映 |
| 成果物 | チームで決めた保管先 | 両方から同じ成果物URLを参照 |
Notionに週次報告として状態を転記する場合は、「いつ時点の記録か」と元の課題URLを添えます。転記した表をもう1つの進捗管理表にしないことが大切です。仕様変更はNotionを直すだけで終えず、影響する課題の担当者が変更に気づける連絡方法も決めます。
会議の決定をBacklogの課題へ渡す手順
- Notionに決定と理由を残す。「問い合わせフォームに確認画面を追加する」だけでなく、対象ページと完了の判断に必要な条件も書きます。
- Backlogに実行する作業を登録する。件名・詳細・担当者・期限日を記入します。公式も、最初はこれらの基本項目を設定して進めるよう案内しています。Backlog公式:課題の分類と基本項目
- 課題にNotionページのURLを付ける。何を参照するリンクか分かる名前を添えます。機密資料の全文を別の共有範囲へコピーしないよう確認します。
- Notionに課題キーとURLを戻す。担当・期限・状態の最新値は課題で確認する、と明記します。
- 担当者の権限で両方のリンクを確認する。閲覧できることに加え、更新する必要がある場所で編集できるかも確認します。
- 完了条件を確認して課題を更新する。成果物へのリンクを残し、運用手順が変わった場合はNotion側の文書も更新します。
議事録をまだ用意していない場合は、Notionの議事録ひな形から決定事項と作業を分けて記録できます。
コピーして使える引き継ぎメモ
次は架空の例です。課題キー・担当名・日付・URLは実際の内容に置き換えてください。メモの担当・期限・状態はBacklogへ入力し、Notion側には最新値を重複管理せず課題URLを残す想定です。
件名:問い合わせフォームの確認画面を追加する 決定の理由:入力内容を送信前に見直せるようにする 仕様の参照先:[NotionページURL] 対象:[フォームのURL] 担当者:[担当名] 期限日:[合意した日付] 初期状態:[運用で決めた状態] 完了条件:入力内容を確認してから送信できる 確認方法:戻って修正した内容も送信結果へ反映されるか確認 成果物:[実装・検証結果の保管先URL] 課題キーとURL:[作成後に記入] Notion側へ戻す情報:課題キー・URL・仕様変更があればその内容
URLの貼り付けと自動連携を分けて考える
最初は通常のリンクで運用できます。NotionではURLをテキストリンクやブックマークとして置けますが、URLを貼っただけで担当・期限・状態が相互に自動更新されるわけではありません。Notion公式:埋め込み・ブックマーク
Notionの公式リンクプレビュー対応一覧では、今回の確認時点でBacklogの記載を確認できませんでした。Backlogの課題を、対応済みアプリと同じ同期プレビューで扱えるとは説明しません。通常リンクで遷移する運用と、APIや外部サービスでデータを転送する仕組みは分けて検討します。Notion公式:リンクプレビュー
自動化が必要になったら、先に次の仕様を決めます。サービス名だけで「簡単に双方向同期できる」「特定プランなら必ず使える」と判断しないでください。
- どの操作をきっかけに、どちらからどちらへ、何の項目を送るか。
- 同じ課題を重複作成しないため、元の課題IDをどこに保存するか。
- 更新が競合した場合の優先先と、失敗時に確認する担当者。
- 削除・権限変更・連携アカウント退職時の扱い。
- 接続先が対応する機能、利用条件、追加費用。
リンクが開けないときは共有範囲を確認する
URLを知っていることと、ページを閲覧する権限があることは別です。Notionの「共有」で対象者と権限を確認し、Backlog側でも対象プロジェクトへアクセスできるか確認します。社内文書を見せるためだけにWeb公開へ切り替えず、必要な人へ必要な権限を付けます。Notion公式:共有と権限
片方のサービスを使わない協力者がいる場合は、その人が必要な情報をどこで読めるか決めます。公開範囲の異なる場所へ文書やプレビューを移す際は、含まれる情報も確認してください。
併用費用は契約単位と必要機能から確認する
旧記事の「Backlogはプロジェクトごとの従量課金」「必要なプロジェクトだけ有料化する」という説明は訂正しました。Backlogの公式料金はプランごとの料金とユーザー・プロジェクト数の上限で示されます。例えばスターターは月払い2,700円(税抜)、30ユーザー・5プロジェクトです。これは1プロジェクトにつき2,700円という意味ではありません。フリープランと30日間の有料プラン試用も区別します。Backlog公式料金
費用の見積もりでは、Backlogの必要機能・上限、Notionの有料メンバー数、支払周期、税や外部連携の費用をそれぞれ確認します。Notion側の人数計算は、Notionの料金比較とメンバー・ゲストの確認表を参照してください。
導入前に1件の作業を最後まで試す
試験用の資料と課題を使い、「仕様を読む→担当と期限を設定→途中で仕様を変更→完了を確認」まで進めます。入力し直した項目、開けなかったリンク、変更に気づけなかった場面を記録してください。二重更新が残るなら分担を直し、1つのツールで十分ならその運用も候補に戻します。併用による工数削減は、実際の運用記録から判断します。
2026年9月15日訂正:課金単位と旧ドル料金、根拠のない機能の優劣・人数別推奨・効率改善の断定、未確認の連携プラン条件を見直しました。本文の重複タイトル、旧独自構造化データ、広告表記付きの旧案内枠を撤去しています。

