新しいアカウントを用意しました。いま動いている仕組みを、そちらへ移したい。移行の案内を読むと、思ったより多くのものが移ると書いてあります。
移行のときによく言われるのは、事前に控えを取っておくこと、そして移らないものを把握しておくことです。どちらも正しい助言です。
この記事が立てる問いは違います。移らなかったものと、移ったもの。あとで問題を起こすのは、どちらでしょうか。
まず、移行の経路があるかどうかで話が変わる
移行できるかどうかは、2つのアカウントの関係で決まります。
個人のアカウントと組織のアカウントが同じメールアドレスであれば、正式な移行の経路が用意されています。組織に参加するときに選ぶか、設定の中から自分で始めるかのどちらかです。Enterpriseの場合は、管理者が対象ドメインのアカウントをまとめて移す方法もあります。
メールアドレスが違う場合、この経路は使えません。用意されているのは個人から組織への移行だけで、個人のアカウント同士を繋ぐ手段はありません。この場合、移すという作業は手でファイルをコピーすることを指します。
以降の話は、どちらの場合にも当てはまります。程度が違うだけで、起きることは同じだからです。
移行しても、移らないものがある
正式な経路を使った場合、何が移るかは公表されています。
移るのは、チャット、チャットの中で作った成果物、プロジェクトとその指示とファイル、アップロードした添付、タスク、プロジェクトの同期設定、そして記憶です。Cowork経由で作ったプロジェクトも含まれます。かなり広い範囲です。
移らないものも、はっきり書かれています。自分で作ったスキルには移行の経路がありません。外部サービスへのサインインは全部無効になり、繋ぎ直しになります。自分で追加した接続先も、入れ直しです。公開していた成果物と、チャットの公開リンクは使えなくなります。
そして、Coworkのタスクとセッションの履歴は移りません。Coworkがパソコンの中に保存したものも、そのマシンに残ります。移行が終わったあと、自分でコピーする必要があります。
私の場合、動かしていた仕組みがこの領域に集中していました。だから、移行の経路があっても、実際に手で作り直す部分がかなり残りました。
作り直したものは、必ず新しい環境に合う
ここで、意外なことが起きました。
手で作り直した部分は、どれも問題なく動きました。当たり前に聞こえますが、理由があります。新しい環境で、一から作ったからです。
予約を組むときは、新しいアカウントの画面を見ながら組みます。だから、その画面にある選択肢しか選べません。使えない機能は、そもそも表示されないのです。
接続も同じでした。繋ぎ直すとき、新しいアカウントで使える接続先だけが並びます。組織のポリシーで許可されていないものがあれば、認証の途中で分かります。
理屈にすると、こうなります。手で作り直す作業は、その環境が差し出してくる選択肢の中から選ぶ作業です。選択肢を用意しているのは環境の側なので、環境の制約は最初から織り込まれています。私が制約を覚えている必要すらありません。
しかも、合わないことが分かるのは作業の最中です。走らせる前に分かる。予約の画面に目的の項目がなければ、その場で立ち止まって別の方法を考えることになります。
手で作り直すのは面倒です。ただし面倒な代わりに、環境に合わないものが入り込む余地がありません。
移ったものだけが、古い前提を抱えたまま入ってくる
問題は、そのまま移った側で起きました。
手順を書いたファイルには、処理の結果をどこへ保存するかが書いてありました。パソコンの中の、決まった場所です。前の環境では、そこへ問題なく書き込めていました。
新しいアカウントのほうは、ブラウザだけで動かす予定でした。ブラウザからは、パソコンの中のその場所に手が届きません。
ファイルは無事に移っています。中身も1文字も変わっていません。変わったのは、書いてある宛先が実在するかどうか、その一点だけです。
同じことが、もう1か所で起きていました。手順の中に、画面を直接操作させる指示が入っていたのです。この機能は、個人向けのProとMaxでしか提供されていません。移した先が法人向けのアカウントであれば、そこに書いてある指示は実行できません。
前の環境では、どちらも正しい記述でした。使える機能を使い、届く場所へ書き込んでいた。移した先で通用しなくなっただけです。
そして、この種の食い違いは移した時点では見えません。ファイルを開けば、正しいことが書いてあるように見えるからです。おかしいと分かるのは、実際に走らせたあとになります。
作り直しとの違いは、ここに出ます。作り直すときは環境が選択肢を絞ってくれますが、移ってきたものは何も絞られていません。前の環境で書いた文字列が、そのまま新しい環境に置かれます。
移す前に、書き換える場所を先に洗い出す
ですから、移行の作業でいちばん重いのは、移すことではありません。書き換える場所を探すことです。
探す対象は3つあります。保存先の指定。実行する場所についての前提。そして、使う機能の名前です。
保存先は、パソコンの中を指しているものを全部拾います。新しい環境がそこへ届かないなら、オンラインの置き場所に書き換えます。
実行する場所の前提とは、アプリが起動していることや、パソコンが起きていることを当てにした記述です。ブラウザだけで動かすつもりなら、この前提は成り立ちません。
機能の名前は、プランによって使えるかどうかが変わるものです。個人向けのプランでしか提供されていない機能を手順に書いていた場合、法人向けのアカウントでは動きません。
この3つを潰してから移せば、走らせた初日から動きます。潰さずに移すと、動かない理由をあとから探すことになります。
一方通行であることを、先に把握しておく
正式な経路を使う場合、もう1つ知っておくことがあります。
個人のアカウントから組織へ内容を移すと、戻せません。公式に一方通行だと明記されています。移したあとで、やはり個人のほうに残しておきたかった、とはできない仕組みです。
移すことを選ぶと、個人のアカウントは閉じられます。有料の契約をしていた場合は解約され、購入方法に応じて日割りで返金されます。ただしApp Store経由で契約した場合は自動で解約されないので、自分で手続きが必要です。
だからこそ、移す前に控えを取っておくことが要ります。スキルは書き出しておく。公開していた成果物は保存しておく。公開リンクで人に渡していたものは、別の方法で渡し直す。接続していたサービスは一覧を控えておく。この4つは、移行を始める前でないとできません。
作り直しのコストを、正直に書いておく
公平を期すために、逆の側も書きます。
作り直しには時間がかかります。予約の設定、接続の認証、ログイン。それぞれは数分で終わりますが、数が増えれば積み上がります。
それから、作り直したものが前と同じとは限りません。細かい設定を覚えていなければ、違う設定で組んでしまいます。これは正式な経路を使わない場合、つまり手で移す場合には、前の環境をしばらく残して見比べられるようにしておくと防げます。正式な経路を使う場合は個人のアカウントが閉じるので、その手は使えません。控えを取る作業が、その代わりになります。
もう1つ。ここに書いた仕様は執筆時点のものです。移行の対象は広がることもあれば、条件が変わることもあります。読んでいる時点での案内を、公式で確認してください。
よくある疑問
Q：メールアドレスが違う場合は、どうすればいいですか。
A：正式な移行の経路は使えません。ファイルを手でコピーし、それ以外は新しいアカウントで作り直すことになります。会話の履歴を渡したい場合は、前のアカウントに引き継ぎの文章を書かせて、新しいほうの最初の発言として貼る方法があります。何十本の会話を1本ずつ運ぶより、この1本のほうが役に立ちます。
Q：移行の前に、何を控えておけばいいですか。
A：公式に4つ挙げられています。自分で作ったスキル。公開していた成果物。公開リンクで共有していたもの。そして、接続していたサービスの一覧です。どれも移行が始まると取り出せなくなります。
Q：Coworkで組んだ仕組みは移りますか。
A：プロジェクトとして作ったものは移りますが、Coworkのタスクとセッションの履歴は移りません。パソコンの中に保存されたものも、そのマシンに残ります。移行後に自分でコピーしてください。
Q：組織に移したあと、やっぱり個人に戻せますか。
A：戻せません。一方通行だと公式に明記されています。判断は移す前に済ませてください。
移せるものほど、中身を疑う
まとめます。
アカウントを移すとき、移らないものは目立ちます。スキルも、接続も、Coworkの履歴も持っていけない。だから、そこに気を取られます。
けれど、移らないものは新しい環境で作り直すことになるので、必ずその環境に合います。合わないものは、作る時点で選べないからです。
危ないのは、そのまま移ってしまうもののほうです。中身は変わらないまま、前の環境を前提にした記述を抱えて入ってきます。そしてそれは、走らせるまで見えません。
移す前に、手順や設定の中にある保存先と、前提にしている環境と、使う機能の名前を洗ってみてはいかがでしょうか。移行でいちばん時間がかかるのは、運ぶ作業ではなく、この3つを書き換えるところです。
