kintoneゲストユーザーの設計方法｜社外共有・権限・費用を崩さない構成

kintoneで社外の人と情報を共有したいとき、候補に上がるのがゲストユーザーです。

取引先と案件進捗を共有したい。

協力会社に作業報告を登録してほしい。

代理店から月次報告を集めたい。

顧客に問い合わせ対応状況を見せたい。

外部スタッフに担当案件だけ編集してほしい。

メール、Excel、チャット、ファイル共有が分散しているので、kintone上にまとめたい。

こうした場面で、ゲストユーザーは便利です。

ただし、ゲストユーザーは「外部に見せるURLを作る機能」ではありません。

社外の人を、kintoneの限定された共同作業場所に招待する仕組みです。

そのため、次のような設計がないまま招待すると、あとから困ります。

• どの取引先を、どのゲストスペースに入れるか決まっていない
• 社外に見せてよいアプリと、社内だけで使うアプリが混ざっている
• 社内メモ、原価、審査コメント、添付資料まで見えてしまう
• ゲストに追加・編集・削除のどこまで許すか決めていない
• 招待したゲストの退職・契約終了を誰も追っていない
• 30日間の試用後に有料化する人数を見ていない
• ゲストスペースに作ったアプリを、あとで通常スペースへ移せると思っている
• IPアドレス制限を入れていればゲストにも効くと思っている
• 外部フォームやkViewerで足りるケースまでゲストユーザーにしている

ゲストユーザーは、社外共有を広げるためではなく、共有範囲を狭く保つために使うべきです。

kintoneゲストユーザーの設計で最初に決めるのは、「誰を招待するか」ではなく、「社外に見せない情報をどこに残すか」です。

この記事では、kintoneのゲストユーザーを、ゲストスペース、共有アプリ、通常ユーザーとの違い、権限、通知、利用できない機能、費用、停止・削除、外部フォームやkViewerとの使い分けまで含めて整理します。

kintoneセキュリティの設計方法はこちら
kintone IPアドレス制限の設計方法はこちら

先に結論：ゲストユーザーは「限定された共同作業場所」を作る機能

kintoneゲストユーザーは、社外メンバーにkintone全体を使わせるためのユーザーではありません。

招待されたゲストスペースと、そのゲストスペースに所属するアプリだけを使うユーザーです。

kintoneヘルプでは、ゲストスペースはkintoneの利用ユーザー以外の人がゲストとして参加できるスペースであり、ゲストユーザーは招待されたスペースと、そのスペースに所属するアプリだけにアクセスできると説明されています。

kintoneヘルプ：ゲストスペース

つまり、設計の中心はゲストスペースです。

社外の人を入れる前に、次を決めます。

決めること	設計の考え方
誰を入れるか	取引先、協力会社、代理店、外部スタッフなど
どこに入れるか	会社別、案件別、プロジェクト別のゲストスペース
何を見せるか	進捗、提出物、共有資料、問い合わせ状況
何を見せないか	原価、社内メモ、他社情報、審査コメント
何を編集させるか	報告、添付、回答、確認ステータス
いつ止めるか	契約終了日、案件完了日、最終ログイン
費用をどう見るか	試用、無料、有料、アカウント共通化

ゲストユーザーは、社外メンバーをkintoneに入れる機能ではなく、社外に見せる業務だけを切り出す設計です。

通常ユーザーとの違い

通常ユーザーとゲストユーザーは、同じ「ユーザー追加」の感覚で考えない方がよいです。

比較項目	通常ユーザー	ゲストユーザー
主な対象	自社社員、常駐メンバー	取引先、協力会社、代理店、外部スタッフ
アクセス範囲	権限に応じて通常スペースやアプリを利用	招待されたゲストスペースと所属アプリのみ
管理単位	cybozu.com共通管理、組織、グループ	ゲストユーザー管理、ゲストスペース
使う場面	社内業務全般	社外との限定された共同作業
費用	kintone本体のユーザー契約	ゲストユーザー契約またはアカウント共通化
権限設計	組織・グループを使いやすい	個別ユーザー指定が中心
終了管理	退職・異動に連動しやすい	契約終了・案件終了を別に追う必要がある

サイボウズ公式のゲストスペース・ゲストユーザーページでも、通常ユーザーは全体のポータルや複数のスペースにアクセスできる一方、ゲストユーザーは招待されたゲストスペース内の環境のみを利用すると説明されています。

kintone公式：ゲストスペース・ゲストユーザー

通常ユーザーにすべきか、ゲストユーザーにすべきかは、次のように判断します。

ケース	推奨
自社社員として複数業務を使う	通常ユーザー
常駐メンバーとして社内業務に深く入る	通常ユーザーまたは権限を絞った通常ユーザー
取引先に案件単位で共有する	ゲストユーザー
協力会社に報告だけ入力してもらう	ゲストユーザーまたは外部フォーム
多数の顧客に閲覧だけさせたい	kViewerなど外部公開ビュー
不特定多数から問い合わせを受けたい	外部フォーム

ゲストユーザーに向くのは、相手が特定できていて、継続的に共同作業する場合です。

不特定多数への公開、単発の回答収集、閲覧だけのページ公開なら、別の手段を検討します。

ゲストスペースと共有アプリを分けて設計する

ゲストユーザーの設計では、ゲストスペースとアプリを一体で考えます。

ゲストスペースは、社外メンバーとの共同作業場所です。

共有アプリは、その場所に置く業務データです。

よくある分け方は、次の3つです。

分け方	向いているケース	注意点
取引先別	代理店、協力会社、顧客ごとに情報を分ける	取引先が多いとスペース管理が増える
案件別	大型案件、共同プロジェクト、工事、開発	案件終了時の停止・保管ルールが必要
業務別	報告受付、資料共有、問い合わせ対応	複数社が入る場合は他社情報に注意

ゲストスペースの分け方を雑にすると、権限が複雑になります。

たとえば、複数の取引先を1つのゲストスペースに入れると、他社のレコードが見えないようにレコード権限を細かく設定する必要があります。

少人数なら運用できますが、取引先が増えると管理が重くなります。

一方で、取引先ごとにゲストスペースを分けると、共有範囲は分かりやすくなります。

ただし、同じアプリを何度も作ることになり、フォーム変更や一覧変更の横展開が必要になります。

ゲストスペースは、あとから権限で無理に分ける場所ではありません。取引先別、案件別、業務別のどれで切るかを先に決めます。

また、kintoneヘルプでは、ゲストスペースに作成したアプリは所属するスペースをあとから変更できず、ゲストスペース以外で作成したアプリもあとからゲストスペース内に移動できないと説明されています。

kintoneヘルプ：ゲストスペース

これは重要です。

通常スペースにある既存アプリを、あとからそのままゲストスペースへ移す前提で設計しない方がよいです。

社外共有用のアプリは、最初からゲストスペース用として作るか、必要な項目だけを切り出して作り直します。

kintoneデータベース設計はこちら
kintoneフォーム連携の設計方法はこちら

ゲストに見せる情報と編集させる情報

ゲストユーザー設計で最も危ないのは、社内アプリをそのまま社外共有しようとすることです。

社内アプリには、社外に見せない情報が混ざっています。

社内アプリに混ざりがちな情報	社外共有時の扱い
原価、粗利、見積内訳	ゲストアプリには入れない
社内判断メモ	別アプリまたは非公開フィールドに分ける
他社名、他社案件	レコード分離、スペース分離で避ける
審査コメント	社内用アプリに残す
契約条件の内部メモ	ゲストスペース外で管理する
担当者の評価、注意事項	ゲストには見せない
API連携用フィールド	ゲストの画面から隠す

社外共有用アプリは、最初から項目を減らします。

たとえば、案件進捗を共有する場合は、次のように分けます。

情報	ゲストに見せるか	理由
案件名	見せる	共同作業の識別に必要
担当者	見せる	連絡先を明確にする
進捗ステータス	見せる	作業状況を共有する
依頼内容	見せる	相手が作業するために必要
提出期限	見せる	期限管理に必要
添付資料	条件付き	見せる資料だけに分ける
原価	見せない	社内管理情報
社内レビュー	見せない	社内判断情報
請求前の金額調整	見せない	社内確認が必要

編集権限も分けます。

操作	ゲストに許すか	設計例
レコード追加	報告受付なら許可	報告アプリ、問い合わせアプリ
レコード編集	自社担当分だけに限定	自分が作成した報告だけ編集
レコード削除	原則許可しない	取消ステータスで残す
添付ファイル追加	必要な場合のみ	ファイル種別と期限を決める
コメント	連絡に使うなら許可	宛先指定と通知を確認する
CSV書き出し	原則許可しない	データ持ち出しを避ける

ゲストユーザーだから安全、ではありません。

ゲストスペース内で見えている情報は、社外に見えている情報です。

フィールド権限、レコード権限、アプリ権限を、通常ユーザーと同じように設計します。

招待・通知・更新責任を決める

ゲストユーザーの運用は、招待から始まります。

kintoneヘルプでは、ゲストスペースの管理者がゲストに招待メールを送信でき、招待メールの有効期間は1週間と説明されています。

kintoneヘルプ：ゲストユーザーの管理（ゲストの招待）

招待前に、次を決めます。

項目	決めること
招待者	誰がゲストを招待するか
承認者	招待前に誰が確認するか
招待理由	どの案件・契約・業務で招待するか
ゲスト所属	どの会社、どの部署、どの役割か
利用開始日	いつから使うか
利用終了日	いつ止めるか
通知先	誰に通知が飛ぶか
問い合わせ先	ゲストが困ったとき誰に聞くか

通知も設計対象です。

ゲストスペース内のコメント、メンション、アプリ通知、リマインダーを使う場合、社外メンバーにどの文面が届くかを確認します。

kintone通知カスタマイズの設計方法はこちら

通知文面に、社内メモや他社名が入っていないか。

担当者だけでなく、社外の誰に届くか。

退職者や契約終了者に通知が残らないか。

一時的なゲストをいつ削除するか。

これを決めます。

利用できない機能と注意点

ゲストユーザーには、通常ユーザーと同じようには使えない機能があります。

kintone公式ページでは、ゲストユーザーはモバイルアプリ「kintone モバイル」を利用できず、スマートフォンではWebブラウザーからアクセスすると説明されています。

kintone公式：ゲストスペース・ゲストユーザー

kintoneヘルプでも、ゲストはモバイルアプリを使用できないこと、ゲストユーザーがアクセスするkintone環境にIPアドレス制限が設定されていてもゲストユーザーのアクセスは制限されないことが説明されています。

kintoneヘルプ：ゲストスペース

また、ゲストスペース内のアプリでは、cybozu.com共通管理で設定した組織や任意のグループを利用できず、ゲストスペースの利用者を1名ずつ指定すると説明されています。

kintoneヘルプ：ゲストスペース内のアプリで「組織」や「グループ」を利用できますか？

設計時に特に注意する点は次のとおりです。

注意点	設計への影響
ゲストは招待されたスペースと所属アプリだけ利用	共有したい業務をゲストスペースに切り出す
ゲストスペースのアプリはあとで通常スペースへ移せない	作成前にアプリの置き場所を決める
モバイルアプリを使えない	スマホ利用はWebブラウザー前提で確認する
IPアドレス制限がゲストに効かない	ゲスト側の認証、権限、停止管理を重視する
組織・任意グループを使えない	個別ユーザー指定で管理できる粒度にする
ゲストの人数が増える	ライセンス、棚卸し、停止処理が必要になる

ここを知らずに設計すると、あとから「通常ユーザーならできたのに」「ゲストスペースでは使えない」という差分が出ます。

ゲストユーザーを使う前に、通常ユーザーで作るべき業務なのか、ゲストスペースへ切り出すべき業務なのかを確認します。

費用とアカウント管理

ゲストユーザーは、費用管理も設計に含めます。

kintone公式ページでは、ゲストユーザーを契約するにはkintone本体の契約が必須で、2026年6月10日時点の税抜料金として、ライトコースは月額700円、スタンダード・ワイドコースは月額1,440円と案内されています。

kintone公式：ゲストスペース・ゲストユーザー

同ページでは、ゲストユーザーとして招待する相手がすでにkintoneを契約中の場合、アカウントを共通化するとゲストユーザーの利用料が無料になることも説明されています。

アカウント共通化については、kintoneヘルプでも、契約中のkintoneと招待されたゲストスペースとでアカウントを共通化でき、シングルサインオンと利用料無料のメリットがあると説明されています。

kintoneヘルプ：ゲストアカウントをkintoneアカウントと共通化する

費用管理では、次を見ます。

項目	管理方法
試用中ユーザー	初回ログイン日、試用期限、継続判断を記録する
有料ユーザー	契約数、利用目的、所属ゲストスペースを確認する
無料ユーザー	アカウント共通化の有無を確認する
未使用ユーザー	最終ログイン日を見て停止候補にする
契約終了ユーザー	停止または削除の担当者を決める

kintoneヘルプでは、ゲストユーザーの一覧でステータス、最終ログイン日時、所属するゲストスペース、ライセンスを確認できると説明されています。

kintoneヘルプ：ゲストユーザーの一覧を確認する

また、試用期間はゲストスペースに招待され、ゲストユーザーとして初めてログインした日から30日間で、試用期間が終了すると有料に切り替わると説明されています。

kintoneヘルプ：ゲストユーザーのライセンスの使用状況を確認する

ゲストユーザーは、招待した瞬間よりも、試用期限・最終ログイン・契約終了を見られる状態を作った後に増やすべきです。

外部フォーム・kViewer・通常ライセンスとの使い分け

ゲストユーザーは便利ですが、社外共有のすべてをゲストユーザーで扱う必要はありません。

使い分けは次のように考えます。

方法	向いているケース	向かないケース
ゲストユーザー	特定の会社や担当者と継続的に共同作業する	不特定多数、閲覧だけ、単発回答
通常ユーザー	社内メンバーとして複数業務を使う	社外の一部情報だけ見せたい
外部フォーム	問い合わせ、申請、報告を外部から受ける	相手と継続的にコメントや資料共有をする
kViewer	kintone内の情報を外部向けページとして見せる	相手にkintone内で直接作業してほしい
メール・ファイル共有	単発の資料送付	履歴、権限、担当、進捗を残したい

FormBridgeは、kintoneと連携するWebフォームを作成するサービスです。

FormBridge：トヨクモのkintone連携サービス

kViewerは、kintone内の情報を外部公開するWebページを作成するサービスとして紹介されています。

kViewer：トヨクモのkintone連携サービス

たとえば、次のように分けます。

やりたいこと	選択肢
顧客から問い合わせを受ける	外部フォーム
代理店に毎月報告を入力してもらう	ゲストユーザーまたは外部フォーム
協力会社と案件進捗を共有する	ゲストユーザー
会員に自分の情報だけ見せる	kViewerの個別ページ系機能
在庫や予約状況を見せる	kViewer
社外メンバーが複数アプリを横断して作業する	通常ユーザーまたはゲストユーザー

判断の軸は、相手にログインして共同作業してほしいかどうかです。

ログインして、コメントし、添付し、状態を更新し、継続的にやり取りするならゲストユーザーが向きます。

入力だけなら外部フォーム。

閲覧だけならkViewer。

社内メンバーと同じ範囲で使うなら通常ユーザー。

このように分けます。

kintoneフォームブリッジの設計方法はこちら

よくある失敗

失敗1：社内アプリをそのままゲストスペースに作る

社内アプリには、社外に見せない情報が混ざっています。

ゲスト用アプリは、見せる項目だけに絞って作ります。

原価、社内メモ、審査コメント、他社情報を混ぜないようにします。

失敗2：取引先を1つのゲストスペースにまとめすぎる

複数社を1つのゲストスペースに入れると、他社情報を見せないための権限が難しくなります。

会社別か案件別で分けた方が安全な場合があります。

ただし、分けすぎるとアプリ管理が増えるため、横展開するテンプレートや変更手順も決めます。

失敗3：ゲストユーザーの停止日を決めない

案件が終わってもゲストが残る。

委託契約が終わってもアカウントが残る。

相手先の担当者が退職しても気づかない。

これはよく起きます。

利用終了日、最終ログイン確認、契約終了時の停止を運用に入れます。

失敗4：費用を見ないまま招待する

ゲストユーザーは、試用期間のあとに有料へ切り替わる場合があります。

アカウント共通化できる相手か。

継続利用する相手か。

閲覧だけならkViewerで足りるか。

入力だけなら外部フォームで足りるか。

招待前に確認します。

失敗5：IPアドレス制限で守れていると思い込む

ゲストユーザーは、IPアドレス制限の扱いに注意が必要です。

kintoneヘルプでは、ゲストユーザーがアクセスするkintone環境にIPアドレス制限が設定されていても、ゲストユーザーのアクセスは制限されないと説明されています。

kintoneヘルプ：ゲストスペース

ゲストの安全性は、ゲストスペース、アプリ権限、レコード権限、フィールド権限、停止管理、通知内容で守ります。

IP制限だけに寄せない方がよいです。

kintoneゲストユーザー設計チェックリスト

最後に、ゲストユーザーを招待する前のチェックリストです。

チェック	確認すること
目的	なぜ社外メンバーを招待するのか
範囲	どの業務だけをゲストスペースに切り出すのか
分け方	取引先別、案件別、業務別のどれで分けるか
見せない情報	原価、社内メモ、他社情報、内部コメントを除外したか
編集権限	追加、編集、削除、添付、コメントを分けたか
通知	社外に届く文面と宛先を確認したか
スマホ	Webブラウザーで使える画面か
IP制限	ゲストには別の制御が必要だと理解しているか
費用	試用、無料、有料、共通化を確認したか
停止	契約終了日、案件終了日、最終ログインを見られるか
代替手段	外部フォームやkViewerで足りるケースを除外したか

ゲストユーザーは、社外との共同作業をkintoneに寄せられる強い仕組みです。

ただし、強い仕組みほど、事前に共有範囲を狭く決める必要があります。

社外に見せるアプリを分ける。

見せない項目を残さない。

編集できる操作を絞る。

招待と停止の担当を決める。

費用と試用期限を見る。

外部フォームやkViewerで足りるものは、ゲストユーザーにしない。

ここまで整理してから招待すると、kintoneのゲストユーザーは社外共有の仕組みとして安定します。

Bitlightに相談できること

Bitlightでは、kintoneゲストユーザーを、単なる招待設定ではなく、社外共有の業務設計として整理します。

たとえば、次のような支援ができます。

相談内容	支援できること
ゲストユーザーを使うべきか分からない	通常ユーザー、ゲストユーザー、外部フォーム、kViewerの使い分けを整理する
社外に見せる情報が不安	ゲスト用アプリ、社内用アプリ、非公開項目を分ける
取引先ごとに権限を分けたい	ゲストスペース、レコード権限、フィールド権限を設計する
招待後の管理が不安	招待承認、試用期限、最終ログイン、停止・削除の運用を作る
費用が読めない	有料ゲスト、無料ゲスト、共通化、代替手段を整理する
既存アプリを社外共有したい	そのまま共有せず、ゲスト用アプリへ切り出す設計を行う

ゲストユーザーは、設定画面だけを見ても判断しづらい領域です。

社外との業務、共有するデータ、契約終了時の管理まで見て、kintoneの中に安全な共同作業場所を作る必要があります。