Backlogの容量を正しく把握！確認方法と不足を防ぐ実務フロー

「まだ保存できるはずなのに、Backlogでファイルを添付できない」と困っていませんか。

原因は、スペース全体の保存容量と、課題・Wiki・Gitごとのファイル制限を同じものとして見てしまうことにあります。

この記事では、使用状況の確認方法から、不足する前に行う整理の流れ、Developer APIで容量を取得する際の注意点まで分かります。

上限に達してから慌てないために、まずはBacklogでいう「容量」が何を指すのかを整理していきましょう。

まず知りたいBacklogの「容量」が表すもの

Backlogで「まだ容量があるはずなのに、ファイルを付けられない」と感じたときは、見ている上限の種類が違うことがほとんどです。

容量という言葉には、スペース全体に保存できる量、現時点で使っている量、1回で扱えるファイルの大きさなど、複数の意味があります。

最初に言葉を分けておくと、通知を見たときやチームから質問されたときも慌てず判断できます。

総ストレージ容量・使用量・空き容量の違い

Backlogの容量を確認するときは、総ストレージ容量・使用量・空き容量を別々に読むことが出発点です。

この3つを混ぜると、「容量がある」という判断が、実際には「契約上の上限が大きい」という意味だけになり、保存可否の判断を誤りやすくなります。

用語	意味	確認時に見るポイント
総ストレージ容量	スペース全体で保存できるデータ量の上限	契約条件として設定される枠
使用量	すでに保存され、上限から消費しているデータ量	現在どの程度まで埋まっているか
空き容量	総ストレージ容量から使用量を引いた残りの量	新しいデータを保存する余地

たとえば総ストレージ容量が保存できる箱の大きさだとすれば、使用量は箱に入っている荷物、空き容量は残った場所です。

「容量が残っている」という言い方は空き容量を指す場合が多いものの、画面や会話では総ストレージ容量のことを指す人もいます。

社内で確認を頼むなら、「総量ではなく、現在の使用量と空き容量を見てください」と伝えると行き違いが減ります。

なお、保存したデータは課題に添えた資料だけとは限りません。

Backlog内で共有されるファイル群がストレージ使用量に関わるため、ひとつのプロジェクトだけを見て余裕があると判断しないほうが安心です。

残りが少ないかどうかは、数字そのものよりも、今後アップロードする資料の量と頻度を合わせて考える場面です。

添付ファイルの上限はストレージの残量とは別

空き容量が十分でも、添付しようとした1ファイルが大きすぎれば追加できないことがあります。

これはストレージ残量の問題ではなく、ファイル単位に設けられた上限に触れている状態です。

空き容量は「あと合計でどれだけ保存できるか」を判断する値であり、添付ファイルの上限は「1回の添付として受け付けられる大きさ」を判断する条件です。

たとえば空き容量が大きく残っていても、動画や高解像度のデザインデータ、圧縮前のログ一式などは、1ファイルの制限に収まらない場合があります。

このとき、不要なファイルを削除して空き容量を増やしても、添付できない原因は解消しません。

逆に、添付ファイルの大きさが上限内でも、スペース全体の空き容量が不足していれば保存できません。

似た表示に見えても、対応は正反対です。

• ストレージ残量が不足している場合：保存済みデータ全体との関係を確認する
• 1ファイルの上限に触れた場合：ファイルを分割・圧縮するか、共有方法を見直す

「何MBまで添付できるか」のような個別の制限は、利用中の機能や契約内容によって確認箇所が異なるため、公式の案内と管理画面の表示を基準にしてください。

容量が残っていてもファイルを追加できないケース

ファイル追加に失敗したら、空き容量だけを見て「Backlog側の不具合かも」と決めないことが大切です。

実務では、容量以外の条件が先に止まっていることも珍しくありません。

起こりやすい状況	考えられる原因	最初に確認したいこと
大きな資料だけ失敗する	ファイル単位の上限	対象ファイルのサイズ
特定の人だけ追加できない	権限や対象画面へのアクセス条件	そのユーザーの権限設定
ファイル選択後に処理が止まる	通信の不安定さ、ブラウザの状態	通信環境、再読み込み、別のブラウザ
特定の形式で失敗する	ファイル名、拡張子、破損など	別名保存やファイルを開けるか

特に見落としやすいのは、ファイル名です。

極端に長い名前や環境依存文字を含む名前は、扱いづらくなることがあるため、短い英数字や一般的な記号へ変更して再試行すると切り分けやすくなります。

アップロードの途中で画面を閉じたり、通信が切れたりした場合も、保存が完了していない可能性があります。

同じ操作を何度も繰り返す前に、ページを更新して対象のファイルがすでに登録されていないか確認すると、重複添付を防げます。

空き容量があることは、ファイル追加が必ず成功する条件ではありません。

「残量」「ファイルの大きさ」「権限」「通信」の順に分けて確認すると、原因に合わない対処で時間を使わずに済みます。

契約プランによって異なるストレージ容量

同じBacklogを使っていても、契約プランが違えば組織全体で使えるストレージ容量の前提は変わります。

「少人数だから低いプランで十分」と決めると、設計データや議事録の添付が増えた時点で見直しが必要になることもあります。

容量を比較する際は、現在の使用量だけでなく、契約形態と今後扱うファイルの種類を並べて確認するのが安心です。

プラン別の総容量は公式の料金・プラン情報で確認

Backlogのストレージ容量は、利用中の料金プランごとに設定されているため、まず公式サイトの料金・プラン情報を見るのが確実です。

古い比較記事や社内に残った導入時の資料は、現在の条件と一致しないことがあります。

確認したいのは、各ユーザーに割り当てられる容量ではなく、契約しているスペース全体で共有する総容量です。

たとえば、利用者数を増やしても、契約内容によっては保存できる容量そのものが同じとは限りません。

確認する項目	見る理由
現在の契約プラン	適用される標準ストレージ容量を判断するため
料金・プラン情報の更新日	旧条件との取り違えを避けるため
契約中のオプション	標準枠とは別の容量条件があるか確認するため
利用予定の人数と部署	将来のファイル増加を見積もるため

料金表の数字だけで判断しにくい場合は、契約管理者が受け取っている申込内容や請求情報も照合すると迷いにくくなります。

無料トライアル時の感覚をそのまま本契約に持ち込まないことも大切です。

大容量が必要な組織向けの特別容量プラン

動画、制作データ、図面、検証用ファイルなどを継続的に扱う組織では、標準的なプランの容量では足りなくなる場合があります。

そのようなときは、一般の料金表に載っている範囲だけで結論を出さず、Backlogの問い合わせ窓口や営業担当へ大容量利用について相談します。

特別な容量条件が用意されているか、契約できる単位、利用開始までの手続きは、申込み時期や契約形態で変わる可能性があります。

問い合わせでは「容量を増やしたい」とだけ伝えるより、現在の契約プラン、利用人数、保管したいファイルの種類、必要になりそうな時期を添えると話が早く進みます。

容量だけを増やしても、巨大なファイルを頻繁に共有する運用に向くとは限りません。

Backlogにはプロジェクトの記録として残す資料を置き、大容量の素材は用途に合う保管先を使う、と分ける考え方も現実的です。

エンタープライズ利用時に確認したい固有の制限

Backlog Enterpriseを利用している場合は、クラウド版の料金プランに書かれたストレージ容量を、そのまま自社環境へ当てはめないよう注意が必要です。

保存できる量は、導入先のサーバーやストレージ構成、社内の運用ルールに左右されます。

ディスクの空き容量があっても、バックアップ領域、監視設定、ファイル保管の社内規程によっては、実際に使える範囲が狭くなることがあります。

本番環境の空き容量だけを見て判断しないことが重要です。

管理担当者は、バックアップ先を含めた必要容量、保存期間、増設時の手順を事前に確認しておくと、急なファイル増加にも対応しやすくなります。

契約変更前に最新の適用条件を照合する

プラン変更や容量に関する追加契約を検討するときは、申請直前に公式の最新条件を確認してください。

容量の扱い、請求開始のタイミング、変更の反映時期、契約期間中に元のプランへ戻せるかは、判断に影響します。

特に年度末や新プロジェクトの開始前は、利用者追加と保存ファイルの増加が重なりがちです。

契約変更の判断は、容量が足りなくなった後より、数か月先に増える資料を想定して行うほうが落ち着いて選べます。

確認先に迷ったら、料金・プラン情報、契約管理画面、Backlogの公式サポート窓口の順で照合するとよいでしょう。

公開情報と自社の契約内容が異なる場合は、個別契約の内容を優先して扱います。

Backlogの容量使用状況を確認する方法

「空き容量がどれくらい残っているのか」を調べるときは、課題画面を一つずつ開く必要はありません。

Backlogでは、スペースを管理する画面から全体の使用状況を確認し、内訳をたどることで容量を使っているプロジェクトを絞り込めます。

ただし、表示される項目は権限や契約状態で変わるため、最初に閲覧権限を確認しておくと迷いません。

使用状況を閲覧できる権限を確かめる

容量の使用状況は、基本的にスペース全体を管理できる立場のユーザーが確認する情報です。

Backlogへログイン後、画面上部またはサイドメニューにあるスペース設定・管理メニューを開けるかを見てください。

設定画面に入れても、契約やストレージに関する項目が表示されない場合は、一般ユーザーまたはプロジェクト管理者の権限にとどまっている可能性があります。

プロジェクト管理者は担当プロジェクトの設定を扱えても、スペース全体の契約情報や容量まで見られるとは限りません。

確認を依頼するときは、「Backlogの容量を見たい」だけではなく、スペース全体のストレージ使用状況を確認したいと伝えると意図が通じやすくなります。

• スペース管理者：全体の使用量や契約に関する画面を確認する担当
• プロジェクト管理者：プロジェクト内の設定やメンバー管理を担う担当
• 一般ユーザー：参加中のプロジェクトで課題・Wikiなどを利用する担当

組織によって役割名の運用は異なりますが、容量確認は管理者に集約する形が安全です。

管理画面からスペース全体の使用量を見る

スペース管理者でログインしたら、スペース設定を開き、契約情報またはストレージ使用状況に関する項目を探します。

画面名やメニュー配置はBacklogの表示環境によって変わることがあるため、「契約」「プラン」「ストレージ」「使用状況」といった語を目印にすると見つけやすいでしょう。

ここで見るべきなのは、使用済み容量だけではありません。

確認項目	見る理由
現在の使用量	いま保存されているデータ量を把握するため
利用可能な容量	新しい添付ファイルを追加できる余地を知るため
容量の上限	契約内容と現在地を同じ基準で比べるため
更新日・集計時刻	直前に追加したファイルが反映済みか判断するため

たとえば使用量だけを見て「まだ余裕がある」と判断しても、上限との距離が分からなければ日常的なアップロードに耐えられるかは読めません。

使用率が高いと感じたら、数値をメモや社内の管理表に残し、確認日も添えておくのがおすすめです。

月末だけに確認するより、ファイル共有が増える案件の開始前後に見るほうが、急な不足に気づきやすくなります。

プロジェクト単位の内訳から消費箇所を探す

スペース全体の使用量が想定より大きいときは、プロジェクト別の内訳表示があれば、容量が偏っている場所を確認します。

使用量の大きい順に並べ替えられる画面なら、上位のプロジェクトから見ていくと短時間で候補を絞れます。

名前だけで古い案件と決めつけず、進行中か、保管目的か、ファイル共有が頻繁かを担当者に確認する流れが現実的です。

特に、設計資料、録画データ、成果物の圧縮ファイルを扱うプロジェクトは、課題数が少なくても使用量が増えやすい傾向があります。

一方で、Wiki本文やテキスト中心のプロジェクトは、閲覧数が多くても容量の主因とは限りません。

内訳を見る際は、次の順番で判断すると、不要な整理作業を始めずに済みます。

1. 使用量が大きいプロジェクトを確認する
2. 直近でファイル追加が続いているかを担当者に聞く
3. 保存されているデータの用途を確認する
4. 継続利用・保管・移管のどれに当たるかを区分する

容量が大きいこと自体は問題ではなく、今後もその場所に置く理由が説明できるかが判断のポイントになります。

確認項目が見つからない場合のチェックポイント

管理画面を開いても容量関連の項目が見当たらない場合、まずは権限不足を疑ってください。

別のスペースに切り替わっている、個人のログインアカウントで入っている、といった見落としもよくあります。

複数のBacklogスペースを利用している組織では、対象のスペース名を画面上で確認してから設定へ進むと安心です。

また、画面の表示名は変更されることがあるため、古い手順書にあるメニュー名と完全に一致しない場合があります。

そのときは、スペース管理者権限で契約・プラン周辺を確認し、それでも不明ならBacklogの公式ヘルプやサポート窓口で現行の確認場所を確かめましょう。

見えていない状態を「容量は問題ない」と判断しないことが大切です。

確認できる人、確認した日、全体使用量、使用量が大きいプロジェクトを記録するだけでも、次回の調査はかなり速くなります。

課題・Wiki・Gitで異なるファイル制限

Backlogで「添付できない」と出たとき、プロジェクト全体の空き容量だけを見ても原因は特定できません。

課題、Wiki、Gitリポジトリでは、対象となるファイルの数え方と上限の考え方が異なります。

作業を止めないためには、使う機能ごとに確認する項目を分けておくことが大切です。

課題とコメントに添付できるファイル数とサイズ

課題やコメントへの添付では、まず1回の操作で添付できるファイル数と、1ファイルごとの容量を分けて確認します。

複数の資料、画面キャプチャ、動画をまとめて登録しようとして失敗する場合、合計容量ではなく、添付数または大きすぎる単一ファイルが原因になっていることがあります。

同じ課題にファイルを追加する場合でも、コメントごとの添付として扱われるのか、課題全体の添付として扱われるのかは、操作画面と公式ヘルプで確認すると安心です。

とくに動画や高解像度のPDFは、見た目以上に容量が大きくなりがちです。

ファイルを分割して添付する前に、不要なページや重複した画像を除けないか確認すると、受け取る側も内容を追いやすくなります。

課題に残すべきなのは、その時点の判断に必要な資料です。

編集用の元データや何度も更新される制作ファイルは、ファイル共有サービスなどで管理し、課題には参照先を記載する運用のほうが混乱を減らせます。

Wikiで確認したい添付総数とファイル上限

Wikiは手順書や仕様メモを蓄積しやすい反面、ページごとに資料を増やし続けると、どこに何を置いたのか分かりにくくなります。

確認したいのは、Wikiページに添付できるファイル数、1ファイルの上限、そして添付分がプロジェクトの保存容量に含まれるかどうかです。

上限の数値だけを覚えるより、「1ページに画像を何十枚も置かない」「更新される資料は最新版だけを残す」といった基準を決めるほうが実務では役立ちます。

たとえば操作手順を説明する画面画像は、1枚ずつ大きな画像を並べるより、必要な箇所を切り出して説明文を添えるほうが読みやすいものです。

添付に失敗した場合は、画像形式、ファイル名、拡張子も見直してください。

容量に余裕があっても、対応していない形式や一時的な通信不良で登録できないケースがあります。

Wikiを社内の保管庫として使い切ろうとすると後で探す時間が増えるので、閲覧頻度の高い資料に絞る判断も必要でしょう。

Gitリポジトリ全体と単一ファイルの制約

Gitでは、添付ファイルとは別に、リポジトリ全体の容量と1ファイルあたりの制約を意識します。

ソースコード中心の運用では問題になりにくくても、動画、デザインデータ、書き出し済み成果物を履歴に入れ始めると、リポジトリは急に扱いづらくなります。

Gitは変更履歴を保存する仕組みのため、大きなファイルを削除しても、過去の履歴に残っていれば容量がすぐには軽くならない場合があります。

大容量ファイルを安易にコミットしないことが、後からの復旧作業を避けるいちばん確実な方法です。

公開用の画像や生成物を管理したい場合も、リポジトリに置く必要があるのか、外部ストレージへの参照で足りるのかを先に決めましょう。

開発チームでは、登録しないファイルを.gitignoreで指定するルールを共有しておくと、誤って巨大なファイルを含める事故を防げます。

すでに大きなファイルを履歴へ登録した可能性があるときは、自己判断で履歴を書き換えず、チームの管理者と手順を合わせるのが安全です。

機能別の最新仕様を公式ヘルプで調べる

Backlogの制限値は、契約プランや提供内容の更新によって変わる可能性があります。

検索結果の古い記事だけで判断せず、Backlog公式ヘルプのファイル添付・Wiki・Gitに関する案内を確認してください。

調べる順番は、使っているBacklogの契約プランを確認し、次に利用機能のヘルプを開き、最後に「ファイルサイズ」「ファイル数」「リポジトリ容量」の記載を照らし合わせる流れが分かりやすいです。

• 課題・コメント：添付可能な形式、1回の添付数、1ファイルのサイズ
• Wiki：ページへの添付条件、ファイル数、サイズ
• Git：リポジトリ全体の扱い、単一ファイルや送信時の制約

ヘルプを見ても判断に迷うときは、エラーメッセージ、操作日時、対象ファイルの容量と拡張子を控えてから問い合わせると、確認が早く進みます。

「容量不足だと思ったら、実はファイル数の制限だった」という行き違いは起こりやすいため、機能名と制限の種類をセットで確認する習慣をつけておくと安心です。

容量が上限に近づいたときに起こること

添付しようとしたファイルが通らない、メンバーから「保存できない」と連絡が来る――その段階で初めて容量不足に気づくと、対応はどうしても後手になります。

Backlogの容量は、上限に達する直前から確認と共有の優先度を上げるべき管理項目です。

日々の作業に大きな変化がなくても、資料の更新や画像付きの課題登録が重なる時期には使用量が伸びやすいため、表示と通知を見逃さない習慣が役立ちます。

使用率が高まった段階で確認したい通知や表示

容量の使用率が高くなると、スペースの管理画面や運営からの案内で、残り容量を意識する場面が増えます。

重要なのは、通知の有無だけで安心せず、「現在どれだけ使っているか」と「増加が一時的か」を分けて見ることです。

たとえば月末に納品資料をまとめて添付するチームでは、その週だけ使用量が動くことがあります。

一方、毎週の議事録、画面キャプチャ、設計資料が積み上がる運用なら、翌月以降も増加が続く前提で考えたほうが安全でしょう。

通知を受け取ったら、担当者ひとりで抱え込まず、次のような点を短時間で整理します。

• 現在の使用率と、業務上必要になる次の大きなファイル
• 直近で完了予定の案件や、添付が集中する予定
• 不要になったデータがありそうなプロジェクトの有無
• 容量に関する連絡を受け取る管理者が誰か

残り容量が少なく見えると焦りますが、その場でファイルを消し始める必要はありません。

削除は参照中の資料や証跡を失う原因になるため、まず状況を共有し、扱いを決める順番が無難です。

上限到達後に制限される可能性がある操作

容量が上限に達すると、新しいファイルの追加やアップロードに制限がかかる可能性があります。

課題への資料添付、Wikiの更新時に必要なファイル登録、ソース管理に関わる作業など、ファイルを伴う業務が止まると影響が広がります。

「課題の文章は書けるから大丈夫」と感じても、仕様書を添えられなければレビュー依頼が進まないことがあります。

デザイン確認用の画像を共有できない、障害報告にログを添付できない、といった小さな停止も、担当者の待ち時間を増やします。

締切当日に上限到達が判明すると、容量の問題がそのまま納期の問題になりかねません。

外部の保存先へ急に切り替える方法もありますが、閲覧権限、リンク切れ、保管場所の分散を同時に確認する必要があります。

一時しのぎの共有先が増えるほど、「最新版がどこにあるのか」を探す時間が発生しやすくなります。

そのため、上限到達後の対処よりも、余裕がある段階で判断できる状態を作るほうが、実務では負担が小さく済みます。

業務への影響が出る前に管理者へ共有する

容量が気になり始めた時点で管理者へ伝えるときは、「残りが少ないです」だけで終わらせないことが大切です。

使用率、増加した時期、今後アップロード予定の資料を添えると、契約やデータ整理の判断を進めやすくなります。

連絡文は、たとえば「容量使用率が上がっており、来週は検収資料の添付が集中します。業務停止を避けるため、対応方針を確認したいです」という程度で十分です。

ここで求められるのは、技術的な原因究明より、いつ何が止まりそうかを早めに伝えること。

管理者が不在の場合や判断に時間がかかりそうな組織では、プロジェクト責任者にも同時に共有しておくと、急な差し戻しを減らせます。

容量の警告は不便なお知らせではなく、チームの作業を止めないための予告として扱うのが安心です。

容量不足を解消・予防する実務フロー

容量が足りないと感じたとき、古いファイルを手当たりしだいに消すのは危険です。

必要な資料まで失うと、過去の経緯を確認したい場面で困ります。

使用量が大きい場所を見つけ、整理の判断をそろえ、それでも不足するなら契約を見直す。この順番なら、チームの作業を止めずに対処できます。

使用量の大きいプロジェクトから優先して調べる

最初に手を付けるべきなのは、更新頻度が高いプロジェクトではなく、容量を多く使っているプロジェクトです。

長期案件、画像や動画を添付しがちな案件、外部共有用の資料を置いている案件は、想像以上にデータがたまりやすい傾向があります。

管理者が使用状況を確認したら、上位のプロジェクトを3〜5件ほど候補にし、各プロジェクトの管理者へ「残すファイル」「移してよいファイル」「削除候補」を確認します。

いきなり全プロジェクトを対象にすると、確認依頼だけで疲れてしまうものです。

優先順位を付ける際は、次のように分けると判断がぶれません。

• 進行中で、今後も添付が増えるプロジェクト
• 終了済みで、参照頻度が低いプロジェクト
• 同じ資料が複数の課題や共有ファイルに重複しているプロジェクト

終了済みの案件でも、監査や契約上の保管が必要な場合は削除しません。

容量の大きさと、削除してよいかどうかは別の判断として扱うことが大切です。

不要な添付ファイルや共有ファイルを整理する

整理では「不要そう」に見えるかではなく、今後の業務で参照する可能性があるかを基準にします。

たとえば、作業途中の画像、差し替え前の資料、同内容の圧縮ファイルなどは候補になりますが、最終版や承認の根拠になる資料は残すのが無難でしょう。

削除前には、対象ファイルの一覧を作り、プロジェクト管理者が確認できる状態にしておくと後悔を減らせます。

「誰が」「いつまでに」異論を出せるかを決め、期限後に実行する流れなら、確認待ちで作業が止まりません。

ファイルの状態	主な対応
最新版として利用中	Backlogに残す
保管義務や参照予定がある	社内の保管先へ移すか、残す
重複・途中版・誤添付	確認後に削除する
大容量の成果物	用途に合う外部ストレージへの移管を検討する

外部へ移す場合は、課題やWikiに保存先のリンクとファイル名、最終更新日を残しておくと、情報が行方不明になりにくくなります。

削除作業そのものより、削除後に必要な人がたどり着ける状態を作ることが実務では重要です。

削減で足りなければプラン変更や容量拡張を検討する

整理しても使用量が増え続けるなら、運用だけで抑え込もうとしないほうが安心です。

添付資料が業務に欠かせず、今後もプロジェクト数や利用者が増える見込みなら、プラン変更や容量拡張を検討する段階です。

判断時は、現在の使用量だけを見るのでは足りません。

直近数か月の増え方、進行予定の大型案件、添付が発生する業務の種類を並べると、一時的な増加なのか継続的な不足なのかを見分けやすくなります。

たとえば、移行作業やイベント準備で一時的に資料が増えた場合と、毎月の制作物を継続して保管する場合では、選ぶ対応が変わります。

前者なら整理や保管場所の見直し、後者なら契約内容の見直しが現実的です。

利用できる容量や変更条件は契約内容で異なるため、決定前にBacklogの公式案内と管理画面の情報を確認してください。

管理者が定期確認できる運用ルールを決める

容量不足は、上限に近づいてから慌てるより、確認日を先に予定へ入れておくほうが負担が軽くなります。

管理者が月1回、または案件の区切りごとに使用状況を確認し、増加が目立つプロジェクトだけを担当者へ共有する運用がおすすめです。

毎回全員に通知すると読まれなくなるため、対応が必要な人へ絞るのがコツです。

ルールは複雑にせず、次の4点を文書化しておくと引き継ぎにも役立ちます。

• 確認する担当者と確認する時期
• 容量が増えた場合に連絡する相手
• 削除前に必要な承認の方法
• 外部保管へ移したファイルの記録場所

プロジェクト終了時に添付ファイルを確認する一手間を入れるだけでも、数年後の整理量はかなり変わります。

容量管理を特別な緊急作業にせず、終了処理の一部として定着させることが、無理のない予防策になります。

Developer APIでプロジェクト容量を取得する方法

管理画面を見に行かず、複数プロジェクトの使用量を定期取得したい場合は、Backlog Developer APIの「プロジェクトの容量情報を取得」を使います。

対象はスペース全体の契約容量ではなく、指定したプロジェクト内で使われている領域です。

認証情報の扱いと数値の単位を誤ると、監視の値そのものが信用できなくなるため、最初に公式リファレンスの仕様と権限を照らし合わせておきましょう。

APIを実行できる権限と事前確認

容量取得APIを呼び出すには、Backlogにログインできるだけでは足りず、対象プロジェクトを参照できる権限を持つユーザーの認証情報が必要です。

プロジェクトの容量情報は運用判断に使われるため、APIキーを発行するアカウントには、対象プロジェクトへの適切なアクセス権を付与しておきます。

プロジェクト管理者向けの情報として扱われるケースもあるため、一般メンバーの権限で取得できない場合は、プロジェクト管理者またはスペース管理者に確認するのが確実です。

APIキーはURLやソースコードに直接書き込まず、環境変数や秘密情報を管理する仕組みに保管してください。

キーを共有の表計算シートやチャットに貼る運用は避けるべきです。

取得前には、対象プロジェクトのプロジェクトIDまたはプロジェクトキーを確認します。

キーは人が識別しやすい一方、名称変更や運用ルールの影響を受ける可能性があります。

自動処理を長く動かすなら、内部的に変わりにくいプロジェクトIDを使うか、キー変更時の修正手順を決めておくと安心です。

リクエスト先と必要なパラメーター

プロジェクト容量の取得には、GETメソッドで/api/v2/projects/{projectIdOrKey}/diskUsageへリクエストします。

{projectIdOrKey}の部分に、確認したいプロジェクトIDまたはプロジェクトキーを入れる形です。

容量を取得するための任意の検索条件やページ番号は通常不要で、どのプロジェクトを指定するかが中心になります。

認証はBacklog Developer APIの公式仕様に従い、APIキーまたは利用中の認証方式を付与します。

実装前には、利用しているBacklogのドメインを含めた完全なURLを確認してください。

たとえば検証用スペースと本番スペースを取り違えると、エラーにならず別プロジェクトの値を取得してしまうことがあります。

• HTTPメソッド：GET
• エンドポイント：/api/v2/projects/{projectIdOrKey}/diskUsage
• 必須の指定：プロジェクトIDまたはプロジェクトキー、認証情報
• 確認先：Backlog Developer APIの「プロジェクトの容量情報を取得」公式リファレンス

最初はコマンドラインツールやAPIクライアントで1件だけ実行し、想定したプロジェクトIDが返ることを確認してから定期処理へ組み込むと、原因調査の手間を減らせます。

レスポンスから読み取れる容量情報

レスポンスにはプロジェクトIDと、用途別に集計された使用量が含まれます。

課題添付ファイル、Wiki添付ファイル、Subversion、Git、Git LFSなどの項目が返る構成が基本です。

各値は一般にバイト単位で扱うため、画面上のGB表示とそのまま見比べると桁を誤認しやすいところです。

監視やレポートでは、保存値はバイトのまま保持し、表示時だけMB・GBへ換算する方法が扱いやすいでしょう。

確認する値	読み取り方	運用での使い方
projectId	取得対象のプロジェクト識別子	想定外のプロジェクトを集計していないか照合する
issueAttachment	課題に添付したファイルの使用量	課題運用が多いチームの増加傾向を見る
wikiAttachment	Wiki添付ファイルの使用量	資料置き場化していないか確認する
git・gitLFSなど	リポジトリ関連の使用量	開発用データの増減を用途別に追う

返却項目はBacklog側の仕様更新で変わる可能性があるため、プログラムでは未知の項目が来ても失敗しない読み方にしておくと保守しやすくなります。

逆に、特定の項目が常に返ると決め打ちすると、API仕様の変更時に監視が止まりかねません。

エラー応答と利用上の制限

取得に失敗したときは、まずHTTPステータスコードとレスポンス本文をセットで記録します。

認証情報が無効または不足している場合は401、権限が足りない場合は403、プロジェクトIDやキーが見つからない場合は404が候補になります。

入力形式に問題があると400系の応答になるため、URLのプロジェクト指定と認証情報の渡し方を見直してください。

短い間隔で多数のプロジェクトへ連続アクセスすると、アクセス制限にかかることがあります。

失敗時に即時再試行を繰り返すのではなく、待機時間を置いて再試行する処理を入れるのが安全です。

容量は刻々と変わる値なので、毎分のように取得する必要は通常ありません。

日次または数時間ごとの取得から始め、添付やリポジトリ更新が多いプロジェクトだけ間隔を短くするほうが、API負荷と確認精度のバランスを取りやすい運用になります。

仕様、認証方式、制限値は変更されることがあるため、実装や改修のタイミングでメーカーの公式Developer APIページを確認してください。

Backlogの容量を正しく把握して不足前に対処しよう

Backlogの容量を管理するには、スペース全体の保存容量、現在の使用量、機能ごとのファイル制限を分けて確認することが大切です。

契約プランによって使える容量は変わるため、今の空き状況と資料が増える見込みを合わせて見ておきましょう。

課題・Wiki・Gitでは上限の考え方が異なるので、添付できないときは原因を切り分ける視点が役立ちます。

上限に達してから慌てないために、定期的な確認とチーム内での共有が欠かせません。

容量不足を感じたら、まず使用量の大きいプロジェクトや保存場所を確認し、必要な資料かどうかを判断して整理します。

手当たりしだいに削除するのではなく、残す基準をそろえることが安心につながります。

整理後も不足が見込まれる場合は、契約内容の見直しを検討する流れが自然です。

複数のプロジェクトを継続して確認したい場合には、Developer APIでプロジェクトごとの容量情報を取得する方法もあります。

ただし、取得できる数値はスペース全体の契約容量とは異なるため、用途を混同しないよう注意しましょう。

まずは管理画面でBacklogの容量使用状況を確認し、どこに保存量が集まっているかをチームで共有してみませんか。課題、Wiki、Gitの使い方を振り返り、残す資料と整理する資料の基準を決めておくと、急な添付エラーにも落ち着いて対応できます。定期確認の担当やタイミングを決め、必要に応じて契約も見直しながら、日々の作業を止めない運用を続けていきましょう。