Basecampからデータを移す｜持ち出せるものと手で作り直す部分
道具を移すと決めたあと、最初に詰まるのはデータです。3年分の会話と資料とファイルがそこにあって、それをどう持ち出すのか。持ち出したものが、次の道具でそのまま使えるのか。この2つが見えないまま移行の日程を引くと、当日になって止まります。
この記事では、2026年9月12日時点で公開されているヘルプ文書の記述だけを使って、Basecampからデータを持ち出すときの実際を整理します。扱うのは、書き出しの形式と権限、私的なやり取りをどう扱うか、解約までに残されている日数、構造を保ったまま取り出す方法、そして移行のたびに必ず手で作り直すことになる項目です。
書き出しはHTMLで、読める形ではあるが取り込める形ではない
公式の書き出しは、Webページの形式で一式が出てきます。ヘルプには、アカウントの所有者が、案件を1つずつ、あるいは選んだ分だけ、あるいはアカウント全体を、いつでも書き出せると書かれています。
この形式が何を意味するのかを、先に押さえておく必要があります。書き出したものはブラウザで開いて読めます。過去の投稿も、コメントの並びも、添付されたファイルも、当時の見た目に近い形で残ります。記録として保存する目的なら、これで十分です。
一方で、別の道具に取り込むことは想定されていません。他の道具の取り込み機能は、たいていCSVか、その道具専用の形式を受け付けます。Webページの形式を読み込んで、やることと担当と期限を復元してくれる仕組みは、一般的ではありません。
つまり、書き出しの用途は2つに分かれます。過去を読める形で保管することと、いま動いている仕事を次の道具へ運ぶこと。前者はこの書き出しで足ります。後者には別の手が要ります。
移行の計画を立てるとき、この区別を最初に置いてください。「書き出せるから大丈夫」と考えて日程を引くと、書き出したファイルを開いた瞬間に計画を組み直すことになります。
もうひとつ、書き出したものの置き場も先に決めておく価値があります。Webページの形式は、フォルダとファイルの集まりとして届きます。これを個人のパソコンに置いたままにすると、その人が辞めた時点で記録ごと失われます。社内の共有の場所に置き、誰がいつ取ったものかを添えておいてください。
移行の前に、いま何が入っているかを数える
計画を立てる前に、運ぶ量を把握する必要があります。ここを飛ばすと、日程がまったく当てになりません。
数えるものは5つです。動いている案件の数、それぞれの案件に入っている人の数、やることとカードの総数、資料の数、そしてファイルの総量です。
案件の数は、管理の画面か案件の一覧で分かります。保管したものと動いているものを分けて数えてください。運ぶのは動いているものだけです。
やることとカードの数は、レポートの画面から近い数字が取れます。担当が決まっていない作業、期限を過ぎた作業、期間ごとの追加と完了の件数を見ると、いま抱えている量の感覚がつかめます。正確な総数が要るなら、公開されているAPIから数えるのが早いです。
ファイルの総量は、管理の画面の容量の項目に出ます。大きいファイルの一覧も同じ画面にあります。移行先の容量の上限が、いまの使用量より小さくないかを、この時点で確かめてください。ここで引っかかると、移行そのものが成立しません。
人の数は、区分ごとに数えます。自社の人、社外の協力者、依頼主。移行先では、この区分の考え方が違うことがほとんどなので、どの人をどの扱いにするかを決める作業が発生します。
書き出せるのは所有者だけで、操作は管理の画面から行う
権限の条件がはっきり書かれています。書き出しができるのはアカウントの所有者だけです。管理者ではありません。
操作は、ホームの画面の左側にある管理の入口から、このアカウントのデータを書き出す、という項目を選びます。ヘルプには、この項目が見えない場合はアカウントの所有者ではないという意味なので、管理の画面で現在の所有者の一覧を確認して直接連絡するように、と書かれています。
書き出しの画面には、アカウント上のすべての案件が並びます。動いているものも保管したものも、そして自分が参加していない案件も表示されるとあります。所有者の権限は、自分が入っていない案件の中身にも及ぶということです。必要なものに印を付けて、書き出しを実行します。
実行してもその場では完了しません。アカウントの規模によっては時間がかかり、準備ができたらメールで知らせが届く仕組みです。3年分のファイルを抱えたアカウントなら、当日に終わらないことも想定しておくべきです。
ここから導かれる実務上の注意は単純です。移行の作業日に書き出しを始めてはいけません。少なくとも数日前に着手して、ファイルが手元に届いて中身を確認できた状態で当日を迎えてください。
私的なやり取りの書き出しには、別の判断が要る
書き出しの画面には、案件のデータとは別に、1対1と少人数の私的なやり取りを書き出す項目があります。すべてを書き出すことも、特定の会話だけを選ぶこともできます。
この項目には、ヘルプ文書としては珍しく強い調子の注意書きが添えられています。
Pings are private, one-on-one and group conversations. Exporting them means reading correspondence that people reasonably expected to stay private. 出典: 5.basecamp-help.com
私的な会話であり、書き出すということは、当事者が私的なままだと考えていたやり取りを読むことを意味する、という記述です。続けて、アカウントの所有者は法的にはアカウント内のすべての内容を所有しているが、所有していることが、どんな状況でも書き出してよい理由にはならない、と書かれています。
書き出してよい場面として挙げられているのは、係争中の法的な案件、正式な人事の調査、裁判所の命令がある場合です。そして、これらの状況以外で従業員を監視したり個人的な会話を見たりするために書き出すことは、信頼に対する重大な裏切りだ、とはっきり書かれています。
移行の作業をする立場だと、つい「全部書き出しておけば安心」と考えがちです。ここはその判断が通らない場所です。案件のデータと私的なやり取りは、別の判断として扱ってください。移行のために必要なのは前者であって、後者が要る場面はまずありません。
なお、日本で従業員の私的な通信を扱う場合の法的な位置づけについては、公開されているヘルプの記述の範囲を超えます。人事上の調査などで必要になったときは、社内の規程と、必要なら弁護士や所管の窓口に確認してから進めてください。
解約の順番を間違えると、書き出しが途中で止まる
移行でいちばん取り返しがつかない失敗が、書き出す前に解約してしまうことです。ヘルプには、この点について複数の場所に警告が置かれています。
書き出しの項目には、解約する予定があるなら先にデータを書き出し、ダウンロードが完全に終わるまで待ってから解約するように、と書かれています。ダウンロードの途中で解約すると書き出しが完了せず、取り出すには問い合わせが必要になるとも書かれています。
解約そのものの挙動も具体的です。解約は即座に、かつ取り消せない形で効力が生じます。確認した瞬間から、アカウントには入れなくなります。以後の請求は発生しません。そして、すべてのデータは30日後に完全に削除されます。その前に戻る必要が生じた場合は、問い合わせるようにと案内されています。
運営元の方針のページには、さらに細かい期限が書かれています。サーバーからの削除が解約から30日後、バックアップからの削除が60日以内です。そして、ひとつのアカウントの内容だけをバックアップから取り出すことはできないと明記されています。つまり、実質的に戻れるのは最初の30日だけです。
支払いが滞って凍結された場合の期限も押さえておく価値があります。凍結が180日続くと自動的に解約されます。無料のアカウントは、365日使われていないと解約の対象になります。移行の途中で旧いアカウントの支払いを止めると、この時計が回り始めます。
構造を保ったまま取り出したいなら、別の入口がある
Webページの形式では足りない、つまり次の道具に取り込める形が要る場合、公式に用意されている入口があります。
公開されているAPIに加えて、コマンドラインから操作する道具が配布されています。案件、やること、投稿などを端末から扱えると説明されています。さらに、Go、Ruby、TypeScript、Swift、Kotlin向けの開発用の部品も公式に配布されています。
これを使えば、やることの本文と担当と期限を、構造を持った形で取り出せます。取り出したものを、移行先が受け付ける形式に変換すれば、手で打ち直す作業を減らせます。
ただし、この道を選ぶ前に量を数えてください。やることが200件なら、手で打ち直したほうが早い可能性が高いです。仕組みを作る時間、動かして確かめる時間、取りこぼしを見つけて直す時間を足すと、1日仕事になります。数千件の規模になって初めて、仕組みを作る側が有利になります。
もうひとつ、取り出せるものとして時間の記録があります。こちらはCSVで直接取り出せて、そのとき適用していた絞り込みと期間が反映されます。請求の根拠として過去の記録を保存しておく必要があるなら、書き出しとは別にこれを取っておいてください。書き出しの一式に含まれている保証はありませんし、CSVのほうが後から集計しやすい形です。
外部の道具を使っている場合は、もうひとつ確認する項目があります。ヘルプの外部連携の項目には、連携を切りたいときはパスワードを再設定する、と書かれています。この操作を行うと、いま繋がっている外部の道具の権限が、ひとつ残らず同時に切れます。移行にあたって旧い側の連携を止めるなら、この操作ひとつで済みますが、逆に言えば、移行の途中でパスワードを変えると、まだ使っている連携も同時に止まります。順番に注意してください。
連携そのものについても、一覧に載っているものはすべて第三者が作って保守しているもので、運営元が作っているわけではないと明記されています。連携経由でデータを取り出す仕組みを組んでいる場合、移行後にその道具が移行先に対応しているかは、提供元に直接確かめることになります。
移すときに、必ず手で作り直すことになる項目がある
道具を移すと、何かは必ず落ちます。何が落ちるのかを事前に知っていれば、当日の混乱を避けられます。
参考になるのが、同じ運営元が古い版から現行版へ案件を移す仕組みについて公開している文書です。ここには、移るものと移らないものが具体的に列挙されています。
移るものとして挙げられているのは、案件に参加している人とその所属、投稿、やること、ファイル、資料、転送されたメール、繰り返しではない予定、そしてこれらに付いたコメントです。
移らないものとして挙げられているのは、次の項目です。
・管理者の役割と請求に関する権限 ・人をまとめた集団の設定 ・資料の過去の版（最新の版だけが移る） ・繰り返しの予定 ・ファイルに付けた札 ・案件に属さない独立したカレンダー ・案件のひな型 ・依頼主が入っている案件
この並びは、同じ運営元の製品どうしの移行での話ですが、移行という作業で落ちるものの種類としては、他の道具へ移る場合にもそのまま当てはまります。権限の設定、集団の定義、過去の版、繰り返しの規則、分類のための札、ひな型。これらは道具ごとに考え方が違うので、自動では運べません。
移行の日程を引くときは、この6種類を洗い出して、誰がいつ作り直すかを決めておいてください。特にひな型と繰り返しの予定は、移行の直後ではなく数週間後に「そういえば無い」と気づくことが多く、そのときには誰も手が空いていません。
ひな型については、移行の機会に見直す価値があります。何年も使っているひな型には、すでに誰もやらなくなった手順が残っていることがよくあります。作り直す作業が発生するのは面倒ですが、白紙から組み直せる機会でもあります。直近3本の案件で実際に使われた項目だけを残す、という決め方をすると、たいてい半分に減ります。
繰り返しの予定は、一覧にして数えておいてください。週次の定例、月次の報告、四半期の振り返り。これらは移行先で作り直すことになります。誰も作り直さないと、移行の翌月に定例が静かに消えます。
資料の過去の版が移らない点も、仕事によっては重い制約です。契約書の案や、依頼主と何度もやり取りした仕様の変遷を追う必要がある場合、最新の版だけが残ると経緯が失われます。この場合は、移行の前にWebページの形式で書き出して保管し、過去を追う必要が出たらそちらを開く、という運用に切り替えることになります。
ファイルに付けた札が移らないという点も、量が多いと効きます。札で分類していたファイルは、移行先ではフォルダの構成か、名前の付け方で分類し直すことになります。移行の前に、札の一覧とそれぞれの件数を出しておくと、移行先でどういう構成にするかを決めやすくなります。
人の区分は、移した先で必ず引き直すことになる
もうひとつ、移行で確実に手作業になるのが人の設定です。
先ほどの文書には、移行したときに人がどう扱われるかが書かれています。案件に参加していた全員が移行先のアカウントに追加され、自社の人は従業員の区分で、それ以外は社外の協力者の区分で入ります。移行後に管理の画面から区分を調整することになります。
依頼主が入っている案件については、そもそも自動では移せないと明記されています。移す前に、旧い側で依頼主を外し、依頼主の機能を切ってから移行し、移行先で改めて招き直す、という手順が案内されています。
さらに細かい挙動も書かれています。外した依頼主が過去に何かを投稿していた場合、その人は社外の協力者として移行先に現れますが、案件には入っていない状態になります。必要なら依頼主の区分に変えて、案件に追加することになります。
これが意味するのは、依頼主との関係は自動では運べないということです。どの案件にどの依頼主が入っていて、何が見えるように設定されていたか。この一覧は、移行の前に手で書き出しておく必要があります。画面を1つずつ開いて記録する作業になるので、案件が20本あるなら半日を見積もってください。
なお、移行によって参加者に通知が飛ぶことはない、とも書かれています。移った瞬間に相手が気づくわけではないので、いつからどちらを見るのかは、こちらから案内する必要があります。
案内の文面も、移行の作業として数えておいてください。社内向けと、社外の協力者向けと、依頼主向けで、書く内容が変わります。社内向けには新しい場所の使い方を、協力者向けには招待が届くことと最初にやることを、依頼主向けには「これまでのやり取りは旧い側に残っていて、今後は新しい側で行う」ことを伝えます。
依頼主への案内は特に慎重に扱う価値があります。依頼主から見れば、こちらの都合で場所が変わるだけです。移行を理由に相手の手間が増えると、それ自体が信頼の問題になります。依頼主が入っている案件については、進行中の案件が終わってから次の案件で新しい場所を使う、という切り替え方も検討してください。案件の途中で場所を変えるのは、社内だけにとどめるのが無難です。
権限の設計も、移行のついでに見直せます。誰が案件を作れるか、誰が人を招けるか、誰が消せるか。旧い側で運用のうちに崩れていることがよくあります。移行先で設定し直すときに、いまの体制に合わせて引き直してください。
移す前に、容量とゴミ箱を片づけておく
移行の作業量は、運ぶ量に比例します。運ぶ前に減らせるものは減らしておくと、書き出しにかかる時間も、移行先で整理する時間も短くなります。
容量については、管理の画面に現在の使用量と、大きいファイルの一覧が出ます。ヘルプには、容量に数えられているのに一覧に出てこないものが2種類あると書かれています。私的なやり取りと会話に添付したファイル、そして投稿しなかった下書きに付けたファイルです。思ったより容量を食っているときは、まずこの2か所を疑えという趣旨の案内が添えられています。
保管した案件も容量を消費します。容量を空けたいなら、保管ではなくゴミ箱へ入れる必要があると明記されています。移行の前に「もう二度と見ない案件」を決めて片づけておくと、書き出しの対象が減ります。
ゴミ箱には期限があります。入れたものは25日で完全に消えるか、その前に中身を空にした時点で消えます。移行の直前に大量に捨てると、判断を間違えたときに戻せる期間が短くなります。捨てるなら、移行の1か月以上前に済ませておくのが安全です。
捨てる判断をするときは、所有者の権限が役に立ちます。所有者は、全案件を横断してゴミ箱の中身を見られるので、誰かが誤って消したものを移行の前に拾い直せます。片づけの作業を複数人で分担するなら、最後に所有者がゴミ箱を一度見渡す工程を入れておいてください。
片づけの副産物として、案件の棚卸しもできます。「終わったのか終わっていないのか分からない案件」は、どの組織にも必ずあります。移行はそれを決める良い機会です。移す対象に入れるかどうかを決める作業が、そのまま棚卸しになります。
旧いものを、読める場所として残しておくという選択
移行を「全部運んで旧い側を消す」と考えると、作業が重くなります。実際には、運ぶのは動いている案件だけで、終わった案件は旧い側に置いたまま読める状態を保つ、という形が現実的です。
同じ運営元の製品どうしでは、この考え方が仕組みとして用意されています。古い版のアカウントを、無料の保存用の段に移せる仕組みです。条件は、現行版のアカウントを持っていて、両方のアカウントの所有者が同じ人であることです。この段では、既存の案件はそのまま残り、参加者も引き続き見たり作業したりできますが、新しい案件は作れません。
他の道具へ移る場合、こうした無料の置き場が用意されているとは限りません。その場合の選択肢は2つです。いちばん安い段に落として読める状態を保つか、Webページの形式で書き出して社内のファイルサーバーに置くかです。
判断の材料は、過去の記録をどれくらいの頻度で見るかです。契約や検収に関わるやり取りを年に数回掘り返す仕事なら、検索できる状態を保つ価値があります。ほぼ見ないなら、書き出して保管するほうが安く済みます。
いずれにしても、旧い側を止める日は、移行の当日ではなく、移行から数か月後に置いてください。移った直後は、必ず「あれはどこに書いてあったか」が発生します。
並行して動かす期間の長さは、案件の周期で決めます。1か月で終わる案件を回しているなら2か月、半年の案件なら1年を目安にしてください。この期間の費用は移行の費用として最初から見込んでおきます。2つ払う期間があることを稟議の段階で書いておかないと、後から説明が要ります。
並行期間で必ず決めておくべきなのが、書き込む場所を1つにすることです。両方に書いてよいことにすると、どちらが正しいか分からない状態が生まれ、移行そのものが失敗します。旧い側は読むだけ、新しい側に書く、という線を初日に引いて、全員に伝えてください。旧い側を読むだけの状態にする設定が用意されているなら、それを使うのがいちばん確実です。
移行の当日に何が起きるかを、先に決めておく
移行は、データを移す作業より、人が迷う時間のほうが長くかかります。当日に何が起きるかを先に決めておくと、その時間が減ります。
決めておく項目は4つです。いつから新しい場所に書くのか。旧い場所はいつまで読めるのか。分からないことを誰に聞くのか。そして、うまくいかなかったときにどこまで戻すのか。
最後の項目が見落とされがちです。移行の途中で「やはり無理だ」となったときに、旧い側がまだ生きていれば戻れます。旧い側を解約していたら戻れません。ここでも、旧い側を当日に止めないという判断が効いてきます。
聞く先を決めておくのも効きます。移行の直後は、同じ質問が何十回も来ます。1人に集中させると、その人の仕事が止まります。よくある質問を先に書いて共有の場所に置き、そこを見てから聞いてもらう形にすると、負担がかなり減ります。
移行の作業を1日で終える必要はありません。動いている案件を1本だけ先に移して1週間動かし、問題が無ければ残りを移す、という進め方のほうが安全です。最初の1本は、期限が遠くて、参加者が少なくて、依頼主が入っていない案件を選んでください。
進行をとりまとめる立場から、何から始めるか
段取りを順に並べます。
最初に、運ぶ対象を決めます。動いている案件だけです。終わった案件を運ぼうとすると、作業量が数倍になり、移行が終わりません。
次に、依頼主の一覧を作ります。どの案件にどの依頼主が入っていて、何が見えていたか。ここは自動では運べないので、手で記録します。
三番目に、書き出しを実行します。所有者の権限が要ります。所有者が自分でないなら、この時点で依頼するか、所有権を移してもらいます。私的なやり取りは、必要な理由が無いなら書き出しません。
四番目に、書き出したファイルが手元に届いて、実際に開けることを確認します。ここまで終えてから、移行の当日を設定します。
五番目に、手で作り直す項目を割り振ります。ひな型、繰り返しの予定、人の集団、権限の設定。これらは移らないので、誰がいつ作るかを決めます。
六番目に、旧い側をいつ止めるかを決めます。当日ではなく、数か月後です。止めた瞬間から、解約なら30日、凍結なら180日の時計が回り始めます。
そして最後に、移った先で入力が続く形になっているかを見ます。データが運べても、更新する人が増えなければ同じことの繰り返しになります。移行の受け口としてどういう作りになっているかはTrelloからの移行に手順があり、板の上で工程も会話もまとめて扱う形についてはできることに整理があります。移った先のデータをどう扱うかの考え方は安全性の考え方に、人数と板の数だけで区切る料金は料金にまとめてあります。移す先の候補を並べたい場合は比較の一覧から、板の型が近いものとしてTrelloとの比較やJootoとの比較、課題の管理を軸にするならBacklogとの比較を見てください。細かい疑問はよくある質問にあります。
Q1. Basecampのデータはどんな形式で書き出せますか？
ヘルプ文書によると、Webページの形式で一式が出てきます。案件を1つずつ、選んだ分だけ、あるいはアカウント全体を書き出せます。ブラウザで開いて読める形なので記録の保管には向きますが、他の道具が取り込める形式ではありません。構造を保ったまま取り出したい場合は、公開されているAPIやコマンドラインの道具を使うことになります。
Q2. 書き出しは誰でもできますか？
できません。ヘルプには、書き出しができるのはアカウントの所有者だけだと明記されています。管理者ではできません。書き出しの項目が管理の画面に見えない場合は所有者ではないという意味なので、管理の画面で現在の所有者を確認して直接連絡するように案内されています。書き出しの対象には、自分が参加していない案件も含まれます。
Q3. 解約するとデータはいつ消えますか？
解約は即座に効力が生じてアカウントに入れなくなり、すべてのデータは30日後に完全に削除されます。運営元の方針のページでは、バックアップからの削除は60日以内で、ひとつのアカウントの内容だけをバックアップから取り出すことはできないと書かれています。書き出しを終えて、ダウンロードが完全に済んでから解約してください。途中で解約すると書き出しが完了しません。
Q4. 移行で手作業になるのはどこですか？
同じ運営元が公開している移行の文書では、移らないものとして、管理者の役割と請求の権限、人をまとめた集団、資料の過去の版、繰り返しの予定、ファイルに付けた札、独立したカレンダー、ひな型、依頼主が入っている案件が挙げられています。依頼主については、移す前に旧い側で外し、移行先で招き直す手順が案内されています。誰がどの案件で何を見ていたかは、事前に手で記録しておく必要があります。