結論：Backlog と Paqut はチーム形態と業務内容で選ぶ。Backlog は開発主体のチーム、Paqut は開発を伴わない制作・運用案件と越境チーム向け。制作会社が「とりあえず Backlog」を選ぶと、開発機能が活きずユーザー課金だけ積み重なるミスマッチが起きやすい。
制作会社の代表が、Backlog の管理画面を開いて、ユーザー追加の確認ボタンの前で 3 秒迷っている。今月のクライアント担当者を 2 人呼ぶか、メールで済ますか、ライセンス費とにらめっこをしている。
その代表に向けて、Backlog と Paqut を機能・料金・対象チームで客観比較し、それぞれが向くケースと、制作会社が陥りがちな選択ミスを整理します。Backlog は国産で日本語ドキュメントが厚く、第一候補に挙がりやすいツールですが、もともと開発チーム向けの設計です。
結論：チーム形態と業務内容で選ぶ
| Backlog | Paqut | |
|---|---|---|
| 開発元 | 株式会社ヌーラボ | 株式会社オルアナ |
| メイン用途 | ソフトウェア開発 | 越境チームの案件運営 |
| Git/SVN 連携 | あり | なし |
| ガントチャート | あり | なし（シンプル特化） |
| ゲスト課金 | ユーザー単位の課金対象 | 無料 |
| 課金体系 | スペース単位の月額（人数に応じてプラン変動） | 自社メンバー数の月額（ゲスト無料） |
| 学習コスト | 1〜2 時間 | 15 分程度 |
| 月額（参考） | ¥2,640〜（5 名まで） | ¥2,980〜（メンバー 10 名まで） |
※ Backlog の価格・機能は執筆時点（2026 年 5 月）の公式サイト記載内容を弊社で確認したものです。プラン構成・価格は変更される可能性があるため、最新情報は Backlog 公式サイト をご確認ください。
Backlog が向いているケース
Backlog の本領は、ソフトウェア開発プロジェクトの統合管理にあります。課題管理・Wiki・Git/SVN リポジトリ・ガントチャート・バーンダウンチャートが 1 つのスペースで完結します。
次のようなチームには Backlog が適しています。
- エンジニア中心の開発プロジェクト
- Git/SVN との連携が必要
- ガントチャート・バーンダウンチャートが必要
- バグトラッキング機能が必要
- 開発の課題・タスク・コミットを 1 ヶ所で追いたい
これらは、Paqut があえて持っていない領域です。開発主体のチームには、Backlog の機能の一体感が価値を発揮します。
Paqut が向いているケース
Paqut は、開発以外の制作・案件管理、特に外部メンバー（クライアント・外注先・フリーランス）が日常的に入る越境チーム向けに設計されたツールです。
次のようなチームには Paqut が適しています。
- 開発以外の制作・案件管理が中心
- クライアントを同じタスクボードに招待したい
- 外注フリーランスを案件ごとに入れ替える
- シンプルな UI で誰でも使えることが優先
- ガントチャートや Git 連携は不要
ポイントは、機能をコアに絞っていること。Backlog のような開発機能はない代わりに、設計や学習コストがほぼゼロです。クライアントや外注先を招待リンク 1 つで呼べ、相手は 30 秒程度でタスクを操作できます。
ゲスト課金がないので、外部メンバーを何人招いても料金は動きません。料金の仕組みは Paqut の料金体系を解説：なぜゲスト無料が成立するのか を参照してください。
制作会社が陥りがちな選択ミス
開発要素が薄い制作会社が Backlog を導入した結果、次のような事態が起きがちです。
1 つ目は、開発機能が使われないまま課金される。Git 連携・課題状態のワークフロー・マイルストーン管理は、エンジニアがいないチームでは活用されません。それでも機能込みの料金が発生します。
2 つ目は、外注デザイナーやライターが UI に馴染めない。「課題」「マイルストーン」「優先度」など開発用語が多く、非エンジニアの外部メンバーにはハードルが上がります。説明工数が積み重なり、結局メールに戻る運用になりがち。
3 つ目は、ユーザー追加のたびに課金が増える。Backlog はユーザー数でプランが変動するため、クライアントや外注先を多数招くと上位プランが必要になります。「呼ぶか・呼ばないか」を経費で判断する場面が増え、本来共有すべき相手を呼ばない運用になります。
これらは Backlog の欠陥ではなく、開発向け設計を制作業務に当てはめたミスマッチです。
シート・ユーザー単位課金がチームに合わない症状は シート課金タスク管理ツールが向かないチームの特徴 で詳しく扱っています。
開発と制作を両方抱える会社の選び方
社内に開発と制作の両方のチームを抱える会社では、どちらかに統一するより、業務形態で分けるのが現実的です。
開発チームは Backlog で、Git 連携・課題管理・コードレビューを 1 つで運用。 制作チームは Paqut で、クライアント・外注デザイナー・ライターを同じボードに招いて軽く運用。
両者を行き来する PM はそれぞれにアカウントを持ち、業務形態に応じて使い分ける。1 つにまとめようとして無理な設計を組むより、業務に合うツールをそれぞれで使う方が、運用負荷が小さくなります。
Backlog から Paqut への移行を検討すべきサイン
すでに Backlog を使っているチームが移行を検討する判断軸：
- 開発要素が減り、純粋な制作・運用案件が中心になっている
- 外部メンバー（クライアント・外注先）が増え、ユーザー課金が運用判断に影響している
- 「課題」「マイルストーン」など開発用語が、外部メンバーにとってハードルになっている
- ガントチャート・Git 連携を実際は使っていない
これらに該当するなら、タスク部分だけ Paqut に切り出す併用、もしくは完全移行が選択肢になります。
逆に、開発案件が継続している、Git 連携が業務に組み込まれている、ガントチャートで進捗管理しているなら、Backlog を続ける方が合います。
まとめ
Backlog と Paqut は、対象とするチーム形態が違います。
Backlog はソフトウェア開発主体のチームの統合管理ツール。Git/SVN 連携・ガントチャート・バーンダウンが価値を発揮します。
Paqut は開発を伴わない制作・運用案件と越境チーム向けの軽量ツール。ゲスト無料で外部メンバーとの運用が軽く、UI もシンプルで非エンジニアでも迷いません。
判断軸はチームに開発要素があるかどうか。開発主体なら Backlog、制作・運用主体で外部メンバーが多いなら Paqut。両方抱える会社は、業務形態で使い分けるのが現実的です。
関連記事
主要 5 ツールの横断比較：外注向けタスク管理ツール 5 選を比較
Asana との比較：Asana と Paqut の違いを、機能・料金・対象チーム規模で比較
Notion との比較：Notion と Paqut の違いを、運用負荷の視点で比較
クライアントから Backlog を指定されたフリーランス向け：クライアントから Backlog を指定されたフリーランスの選択肢
Paqut で、Backlog との運用感覚を比べる
Paqut なら 3 ステップで、Backlog との運用感覚の差を試せます。
- 無料プランで自分のワークスペースを 3 分で作る
- クライアントか外注先を 1 人、招待リンクで呼ぶ（追加料金 0 円）
- 「リンクを送ってから相手がタスクを見るまでの時間」と「招待時に発生したコスト」を Backlog と並べて実測する
3 分で立ち上がります。