パターン実践ガイド

社外やり取りを行う場合の設計

はじめに

Index
当ガイドは、「同一ドメインから」パターンとあわせてご利用ください。

異なる組織間で共にkintoneを利用する際に、セキュリティを担保しつつ利便性を求めるには、どのような構成が考えられるでしょうか。
親パターン「同一ドメインから」の通り、一つのkintone環境で完結する構成から順番に4つの構成を紹介します。

また構成を紹介するにあたり、それぞれの立場を以下の言葉で説明しています。
・自社ユーザー … kintoneを契約している自らの会社の人・組織
・外部ユーザー … 今回新たにやり取りしたい社外の人・組織

(※この記事は2024年9月1日時点のkintoneをもとに執筆しています。)

想定読者

IT部門・現場部門の方向け

内容

下記 4 つの構成におけるメリット・デメリットを記載しています。
・ゲストスぺースでの運用
・組織間のアクセス権を有効にする
・外部連携サービスを利用する
・別ドメインを用意する

ゲストスぺースでの運用:

kintoneのゲストスペース機能を利用し、外部ユーザーをkintoneにゲストとして招待する方法です。

1:1でのやりとり 共有のやり取り
ゲストスペース

1:1の簡易的なコミュニケーションとデータの共有であれば、この機能のみで完結します。
さらに、外部ユーザーも自社でkintoneを契約している場合、アカウントの共通化を行えば、ゲストユーザーの費用も掛かりません。

ただし、複数組織とのやり取りが発生する場合に、ゲストユーザー同士でやり取りをさせないためには、別のゲストスペースを作成する必要があり情報が分散してしまいます。
また、ゲストスペースでは組織やグループ単位での指定が利用できないので、1:1のやり取りでも外部ユーザーが多数参加する場合には、アクセス権設定や通知設定をユーザー単位で設定する必要があり、メンテナンスが煩雑になり易いというデメリットがあります。
ゲストスペース外のアプリとルックアップ・関連レコードでアプリ連携することも出来ない為、セキュアではあるものの機能制約が多い構成となります。

組織間のアクセス権を有効にする:

「組織間のアクセス権」を利用し、自社ユーザーと外部ユーザーを同一のkintone環境内で管理する方法です。

上記のゲストスペース構成で記載のように、複数組織とのやり取りが発生する際にも、外部ユーザー同士で個人情報を見せたくない/やり取りをさせたくないシーンがあります。
この場合は外部ユーザーを自社ユーザーと同じく、kintoneのユーザーアカウントとして登録し、「組織間のアクセス権」を有効にすれば、外部ユーザー同士のやり取りを防ぎつつ、自社ユーザーと外部ユーザーでのやり取りが可能となります。

組織間のアクセス権

「組織間のアクセス権」を設定した場合、cybozu.com共通管理の組織設定で最上位層(Root直下)で並列設定した組織に属するユーザー間は、ユーザー情報が閲覧できなくなります。
これにより、ゲストスペースのように外部ユーザー毎にスペースを分けることなく、一つのアプリで複数の外部ユーザーとやり取りすることが可能になります。

ただし、単に組織を並列設定した場合、自社ユーザーからも外部ユーザーが表示されなくなってしまうので、「組織間のアクセス権」を有効にした状態で、複数の外部ユーザーとやり取りする場合には自社ユーザーがやり取りをしたい外部ユーザーの組織にも属する組織設定が必要となります。

外部連携サービスを利用する:

外部連携サービスを利用し、自社ユーザーはkintone、外部ユーザーは外部連携サービスを利用する方法です。

上記の「組織間のアクセス権」を有効にすれば、ある程度一つのkintone環境でセキュリティを担保しつつ、利便性を保った状態で複数の外部ユーザーと情報共有をすることが出来ます。
しかし、自社ユーザーで既に別の用途でkintoneを利用している場合には、社内用途と社外用途が一つのkintone環境で混在してしまうので、万が一アクセス権の公開範囲を誤ってしまった場合には、外部ユーザーが社内情報を閲覧できる状態となるリスクがあります。

またライセンス料についても確認が必要です。
コースごとのライセンス費用はこちらをご確認ください。

そこでやり取りをkintone環境外で行う構成として考えられるのが、外部連携サービスを利用した構成です。

外部連携サービス

外部連携サービスを利用することで、自社ユーザーはkintone環境を使いつつ、外部ユーザーは必要な入出力部分のみを外部連携サービスに切り出して利用することが可能になります。連携サービスによって料金形態は様々ですが、kintoneの本ライセンスに比べるとコストは下がります。

ただし、kintone環境の外にデータを渡すことになり、kintone環境以外にセキュリティや可用性を懸念する要素が増えるので、やり取りする情報の機密性で選択することをお勧めします。

別ドメインを用意する:

最後に完全にkintone環境を分けて管理する方法です。

別ドメイン

自社ユーザーのみで利用するkintone環境と、外部ユーザーと情報共有するkintone環境を別ドメインで構築する方法です。ここまで明確に分けておけば、社内情報が外部ユーザーに漏洩するリスクも低く出来ます。

ただし、別ドメインにあるアプリ同士を基本機能を利用して連携することはできません。
また、kintoneアカウントのライセンス費用やプラグインの契約費用などが重複するため、プラグイン契約が多い場合、コスト面で割高となる懸念もあります。

おわりに

外部ユーザーに見せたい情報・見られたくない情報はどの会社にもあります。社内で利用しているアプリと外部ユーザーに見せたい情報の関連性や、情報共有する外部ユーザーとの関係性などから、上記のどの構成がよいのか検討して選択しましょう。 うまくkintone環境の中で外部ユーザーともやり取りができれば、より便利にkintoneを利用できるでしょう。

まとめ表

見にくい場合は横画面にしてご覧ください。

ゲストスぺースでの運用 組織間のアクセス権 外部サービス連携 別ドメイン
アプリ連携性
  • 社内業務で利用しているアプリとゲストスペース内のアプリでは、ルックアップ・関連レコードなどのアプリ連携機能が利用出来ない
  • 社内業務で利用しているアプリとやり取りを行うアプリで、ルックアップ・関連レコードなどのアプリ連携が利用出来る
  • kintone側では社内業務で利用しているアプリとやり取りを行うアプリで、ルックアップ・関連レコードなどのアプリ連携が利用出来る
  • 連携サービス側で同等の機能を持ち合わせているかは利用する連携サービス次第となる
  • 社内業務で利用している本環境側のアプリと別ドメイン内のアプリでは、ルックアップ・関連レコードなどのアプリ連携機能が利用出来ない
ユーザー管理
  • ゲストスペース内で「組織」「グループ(ロール)」が利用できないので、参加しているゲストユーザー数が多いとメンテナンスが煩雑になる
  • 外部ユーザーも「組織」「グループ(ロール)」で管理ができるただし、やり取りする外部ユーザーが多い際にはやり取りを分ける外部ユーザーごとに「組織」を作成し、自社ユーザーもその「組織」に属する必要があるので複雑になる
  • kintone側は自社ユーザーの組織管理だけで済むので管理が簡易
  • 連携サービス側での組織管理の機能がどこまで柔軟・豊富かはサービス次第となる
  • 普段の業務で利用する環境側は、自社ユーザーの組織管理だけで済むので管理が簡易
  • 外部ユーザーとやり取りする環境は、やり取りする外部ユーザーが多い際にはやり取りを分ける外部ユーザーごとに組織を作成し、自社ユーザーもその組織に属する必要があるので組織管理が複雑になる
セキュリティ性
  • 本環境とゲストスペースは完全に分断されているので情報が混在する恐れは少ない
  • 万が一設定を誤った際に、社内業務で利用しているアプリが外部ユーザーに閲覧できる状態になる危険性がある
  • kintone以外の部分にデータを一時的に預ける構成となる為、連携サービス側のセキュリティについても懸念する必要がある
  • 用途によって環境は完全に分断されているので情報が混在する恐れは少ない
想定される利用ケース
  • やり取りする外部ユーザーが1、ないしは少数のケース
  • kintoneユーザー同士でやり取りするケース
  • 複数の外部ユーザーとやり取りしつつ、社内利用のアプリとやり取りを行うアプリを連携させて利用したいケース
  • 不特定多数の外部ユーザーとやり取りが発生し、やり取りの内容・流れが比較的シンプルなケース
  • 複数の外部ユーザーとやり取りしつつ、セキュリティ性は担保したいケースまたはkintoneの機能を利用したいケース

社外やり取りを行う場合のkintone環境の構成については、利用ケースごとに検討ポイントが上記の他にも存在します。また、利用ケースごとに各運用のメリット・デメリットの捉え方も変わるため、比較検討される場合にはご自身の利用ケースにあわせてメリット・デメリットをご判断ください。

ページトップ