kintoneは、誰でも簡単に業務システムを作成できるため、単一部門で利用されているケースが多くあります。
そのため、情報管理部門では、「すでに導入済みのドメインを統合したい」と考えることもあるかと思います。
この記事では、ドメインを統合する際の具体的なデータ移行手順や考慮点を説明します。

ドメイン統合では、統合作業の前に対象ドメインを本当に統合できるのか評価することが非常に重要です。
そこで、まずは統合可否を判断する際の代表的な考慮点を紹介します。

kintoneにおいて、考慮したいポイントを紹介します。

上限値

kintoneにはアプリ数やスペース数など上限値がいくつか存在します。
上限値は、 制限値一覧 に記載されています。 ドメインを統合することで、これらの上限値を超えることがないか考慮しましょう。

高負荷環境

kintoneでは、 性能上の考慮点と改善策 に記載されているとおり、「①データ量x ②複雑度x ③アクセス数」これらが複合的に影響し合った際、性能上のリスクになります。
そのため、現状の運用状況で次のケースに当てはまる場合、統合後ドメイン全体へ影響が及ぶ可能性を注意しましょう。

• 性能上のリスクとなる利用方法で運用されている。
• 外部システムとの連携を高頻度で実施している。

認証

統合先のドメインで次のような認証を利用している場合は、統合後全体でも利用可能か考慮する必要があります。

• SAML認証
• 2要素認証
• セキュアアクセス

ゲストユーザーの再招待

ゲストユーザーを利用している場合、統合先のドメインに再招待する必要があります。
ゲストユーザーとの関係性によってはご案内が難しいケースも考えられるので、あらかじめ確認しましょう。

次に、プラグインを利用されている場合に、考慮したいポイントを紹介します。

プラグインの再設定

アプリテンプレートには、プラグインの利用有無は含まれます。
ただし、プラグインの設定は再度実施しなければなりません。

上限値

プラグインによっては、上限値が設定されているものもあります。
ドメインを統合することにより、上限値を超えないか考慮しましょう。

契約閾値の変更

プラグインの契約形態はさまざまです。
ユーザー数で課金される場合や利用数によって契約プランが異なるプラグインもあるので、あらかじめ確認が必要です。
また、同様の機能をもつプラグインを使っている場合は、どちらかに統合することも検討しましょう。

管理者

プラグインの中には複数の管理者を想定していない製品もあります。
設定画面を同時に操作することを想定していない製品の場合、正常な動作が保証されない場合もあるため、注意してください。

次に、カスタマイズや連携サービスを利用されている場合に、考慮したいポイントを紹介します。

連携サービスの再構築

アプリテンプレートには、JavaScriptのカスタマイズも含まれます。
ただし、次のような場合では、カスタマイズが正常に動作しなくなるかもしれません。

• プログラム内でkintoneのドメイン、アプリIDなどドメイン統合前の情報を使用していた場合
• 連携サービス側でkintoneのドメイン、アプリIDなどを指定して連携をしていた場合
• APIトークンの再生成をした場合

ドメイン統合後も正常に動くよう、プログラムや連携サービス側の設定修正も忘れずに考慮しましょう。

kintoneは、多言語に対応しています。
最後に、kintoneをグローバルに利用している場合、考慮したいポイントを紹介します。

リージョン

異なるリージョンから統合する場合、同じカスタマイズ・ソリューションが使えるとは限りません。
統合先のリージョンとの機能差異を確認することが必要です。

言語

同じアプリについて異なる言語のユーザーが使用する場合、次の考慮が必要です。

• アプリの説明やフィールド名など言語ごとの名称を設定する。
• 連携ソリューション側で多言語対応されているかどうか確認する。

ここであげた考慮点は、代表的なものです。
ドメイン統合時には思わぬ事象が発生することもあるので、余裕をもった移行スケジュールで実施することも大切です。

統合前のアセスメントが済んだら、統合前の準備をします。

統合後のドメインへの影響をテストできる開発環境を準備しましょう。
いきなり移行するのではなく、本番環境とは別に開発環境を用意し、そこで開発・テストを行う方が安全に運用できます。

運用中のドメインは、それぞれ 自分たちのガバナンス設計 をされていると思います。
統合後、そのガバナンスをどのように変更する必要があるか検討しておきましょう。

統合前のアセスメントに記載されている考慮点や各ドメインでの利用状況を確認したうえで、統合先ドメインを決定します。

ここでは例として、次の2つのドメインが運用されている状況を仮定します。
統合先ドメインは、ドメイン2です。

• 移行元ドメイン：ドメイン1 sample-domain1.cybozu.com
• 統合先ドメイン：ドメイン2 sample-domain2.cybozu.com

ドメイン統合に伴うデータ移行の全体的なイメージは次のとおりです。

ここからは、ドメインを統合する際の具体的なデータ移行手順を説明します。

まずは、cybozu.com共通管理にあるデータのうち、CSV形式やTSV形式などのテキストファイルで入出力できるデータを移行します。
必ず、 ファイルを使ってデータを変更する場合の注意事項 を事前に確認してください。

1. sample-domain1.cybozu.com、sample-domain2.cybozu.comの両方で、 ユーザーや組織などの情報をファイルに書き出す の手順を参考に、組織のデータをファイルに書き出す。

   

2. 書き出した2つのファイルを確認する。
   ドメイン1から出力されたファイルは次のとおりです。

   

   ドメイン2から出力されたファイルは次のとおりです。

   

3. 2の2つのファイルのデータを統合し、1つのcsvファイルにまとめる。
   新組織コードの列には、新しい組織コードを入力します。

   

4. ドメイン2のcybozu.com共通管理画面で、 ファイルを使ってユーザーや組織などを追加または変更する の手順を参考に、組織のデータをファイルから読み込む。
   このとき、先頭行に項目名が含まれている場合は、「先頭行をスキップする」にチェックを入れます。

   

5. 1〜4を他のデータでも同様に行う。

   • グループ（ロール）
   • ユーザー
   • ユーザーの利用サービス
   • ユーザーが所属する組織
   • ユーザーが所属する静的グループ（ロール）

1. ドメイン1のkintone上にある、移行したいスペースを棚卸しする。
2. スペースをテンプレート化する手順 にしたがって、移行したいスペースをテンプレート化する。
3. ドメイン1のkintoneシステム管理画面で、 スペーステンプレートをファイルに書き出す の手順で、作成したテンプレートをファイルに書き出す。
4. ドメイン2のkintoneシステム管理画面で、 ファイルからスペーステンプレートを読み込む の手順で、ファイルからテンプレートを読み込む。
5. スペーステンプレートに含まれないもので必要な設定は、スペース移行後に設定する。

1. ドメイン1のkintone上にある、移行したいアプリを棚卸しする。
2. アプリをテンプレート化してkintoneに登録する の手順で、移行したいアプリをテンプレート化する。
3. ドメイン1のkintoneシステム管理画面で、 アプリテンプレートをファイルとしてkintoneの外に保存する の手順で、作成したテンプレートをファイルに書き出す。
4. ドメイン2のkintoneシステム管理画面で、 アプリテンプレートをkintoneに登録する の手順で、ファイルからテンプレートを読み込む。
5. アプリテンプレートに含まれないもので必要な設定は、アプリ移行後に設定する。

アプリ内データの移行方法は2種類あります。

• ファイル入出力での移行
• コマンドラインツール「cli-kintone」での移行

どちらの移行方法で行うかは、移行データの内容やデータ量に応じて検討します。

移行方法	適しているケース
ファイル入出力	データ量が少ない 添付ファイルの移行が不要
cli-kintone	データ量が制限値（100MB）を超えている 添付ファイルの移行が必要

1. ドメイン1のkintoneで、 ファイルにデータを書き出す の手順で、移行したいアプリのデータをファイルに書き出す。
2. Step3で移行したドメイン2上のkintoneにて、 ファイルからレコードのデータをアプリに読み込む の手順で、ファイルからデータをアプリに読み込む。

注意事項

ルックアップフィールドにファイルから値を読み込むときは、あらかじめ、関連付ける元のアプリで、以下の条件を満たす必要があります。

• 「コピー元のフィールド」となるフィールドに、値の重複禁止が設定されている。
• アプリのアクセス権で、レコード閲覧権限がファイルを読み込むユーザーに付与されている。

上記の条件を確認する方法は、 ルックアップフィールドにファイルから値を読み込むことはできますか？ を参照ください。

1. データをエクスポートするの「CSVファイルにエクスポートする」の手順で、移行したいアプリのデータをcsvファイルにエクスポートする。
2. Step3で移行したドメイン2上のkintoneにて、 データをインポートするの手順で、データをアプリにインポートする。

ここまでで、主なデータの移行作業は終了です。
ここからは、製品の仕様上、データ移行できないものやデータ移行とは別に別途対応が必要なことについて説明します。

製品の仕様上、次のデータはファイル入出力やAPIでのデータ取得ができないため、移行できません。
証跡としてデータ保管が必要な場合は、移行元ドメインにてデータを保管しておく必要があります。

• レコードの変更履歴
• プロセス管理のステータス履歴
• 作成時に⾃動採番される番号・ID
• レコードのコメント
• 定期レポート

各種セキュリティ設定（IPアドレス制限・セキュアアクセス等）は移行できません。
統合先ドメインの設定情報に準じます。
変更が必要な場合は、統合先ドメインで設定変更をしてください。

移行元のドメインのリンクを任意の場所に貼って活用していた場合、差し替え対応が必要になります。
カスタマイズでリンクを使⽤していた場合も差し替え対応が必要です。

大量データを一括移行すると、インデックス作成に時間がかかります。
その結果、該当データを検索する際に正確な情報を見つけられない可能性があります。
この懸念点については、 kintoneの検索のしくみと注意事項を参照ください。

それぞれ独自に運用している環境をドメイン統合する場合は、アクセス権を設定するなどの対応が必要になります。
運⽤フロー・アプリ作成ルール等ガバナンス策定については、 kintone ガバナンスガイドライン を参考にしてください。

ドメインを統合する際の具体的なデータ移行手順や考慮点を紹介しました。
ドメイン統合を検討する場合は、統合可否を判断するアセスメントを行い、考慮点を事前によく検討しておくことが大切です。