kintoneカレンダーの設計方法｜標準表示・プラグイン・予定DBの使い分け

kintoneでカレンダーを使いたい相談では、最初に表示方法の話になりやすいです。

月表示にしたい。

週表示にしたい。

日表示にしたい。

色分けしたい。

ドラッグで予定を動かしたい。

会議室や車両の空きを見たい。

Google Calendarと連携したい。

たしかに、カレンダーは見た目の分かりやすさが重要です。

ただし、実務で崩れるのは、カレンダーが表示できないことだけではありません。

本当に困るのは、次のような状態です。

• 予定名と日付だけで、開始時刻と終了時刻が分からない
• 担当者、参加者、確認者が同じ項目に混ざっている
• 会議室、車両、設備などのリソース予約が予定と分かれていない
• 終日予定、複数日予定、移動時間、準備時間の扱いが曖昧
• 繰り返し予定を手で複製し、例外日や変更履歴が追えない
• 案件、タスク、問い合わせから発生した予定なのに、元データとつながらない
• Google CalendarやGaroonと二重管理になり、どちらが正しいか分からない
• 非公開予定、顧客名を含む予定、社外共有してはいけない予定が同じ見え方になる

カレンダーは、予定をきれいに並べる画面ではありません。

「いつ、誰が、何を、どのリソースを使って行うか」を、業務データとして扱う仕組みです。

kintoneカレンダーで最初に決めるべきなのは、月表示か週表示かではなく、「予定レコードをどこまでkintoneの正本にするか」です。

この記事では、カレンダー表示の操作説明ではなく、kintoneで予定管理を崩れにくい業務システムとして設計する方法を整理します。

kintoneスケジュール管理の設計方法はこちら
kintoneタスク管理の設計方法はこちら
kintone案件管理の設計方法はこちら
kintoneシフト管理の設計方法はこちら

先に結論：カレンダーは表示ではなく予定DBとして設計する

kintoneの標準機能でも、アプリのレコードをカレンダー形式で表示できます。

ただし、標準カレンダー表示は、あくまでレコード一覧の見せ方の1つです。

予定管理として使うなら、まず予定レコードの意味を決めます。

分けるもの	1レコードの意味	役割
予定レコード	1つの予定、作業、予約	件名、種別、状態、関連業務を持つ
開始日時・終了日時	予定の時間範囲	いつからいつまでかを決める
担当者・参加者	人の関与	主担当、参加者、確認者を分ける
リソース	会議室、車両、設備、機材	空き状況や重複を確認する
関連データ	案件、タスク、問い合わせ、顧客	予定の発生元を追う
繰り返し設定	定期予定の親子関係	毎週、毎月、例外日を扱う
公開範囲・権限	誰に見せるか	非公開、社内限定、担当部門などを分ける
通知・確認	期限前、未確定、未参加回答	放置や見落としを防ぐ
連携ログ	外部カレンダーとの同期	二重登録、未同期、エラーを追う

予定アプリは、予定の中心です。

しかし、予定アプリにすべてを詰める場所ではありません。

案件から発生した商談予定は案件とつなぐ。

タスクから発生した作業予定はタスクとつなぐ。

会議室や社用車はリソースとして分ける。

個人の空き時間調整や招待はGoogle CalendarやGaroonに任せる。

この分け方にすると、kintoneカレンダーは単なる予定表ではなく、業務データとつながる予定管理になります。

kintone公式ヘルプでは、カレンダー形式の一覧で日付に使うフィールドとタイトルとして表示するフィールドを選ぶことが説明されています。

kintoneヘルプ：kintoneでスケジュールを管理するには

重要なのは、表示する前に、どのフィールドを予定の正本として使うかを決めることです。

標準カレンダー表示でできること

kintone標準のカレンダー表示は、シンプルな予定確認に向いています。

標準機能では、日付フィールドをもとに、レコードをカレンダー形式で表示します。

向いているのは、次のような用途です。

向いている用途	理由
納期一覧	日付ごとに対象レコードを見られる
提出期限	期限が近いものを月単位で把握できる
訪問予定の簡易表示	1日単位で予定を確認できる
イベント日程	開催日や締切日を一覧化できる
作業予定の月次確認	月内の予定量をざっくり見られる

一方で、標準カレンダーだけでは重くなる用途もあります。

標準だけでは弱い用途	理由
時間帯の細かい調整	週表示・日表示・ドラッグ調整が必要になりやすい
会議室や車両の空き確認	リソース別の横並び表示や重複チェックが必要
複数人の予定調整	人別・参加者別の見え方が必要
繰り返し予定	親予定、例外日、変更範囲の設計が必要
外部カレンダーとの同期	二重登録や同期エラーの管理が必要

標準カレンダーは悪い選択ではありません。

むしろ、納期、期限、イベント、月次予定の確認には十分なことがあります。

ただし、予定調整そのものを行いたい場合は、標準カレンダーだけで無理をしない方がよいです。

標準カレンダーは「予定を月単位で見る」用途に向いています。時間帯調整、リソース予約、繰り返し予定まで扱うなら、予定DBとプラグイン・外部カレンダーの分担を先に決めます。

予定アプリの必須項目

カレンダー表示を作る前に、予定アプリの項目を決めます。

最低限必要なのは、件名と日付だけではありません。

実務で使うなら、次の項目を検討します。

フィールド	型	設計意図
予定ID	文字列、採番	外部連携や重複判定に使う
件名	文字列	カレンダーに表示する
予定種別	選択肢	商談、作業、会議、訪問、休暇などを分ける
状態	ステータス、選択肢	仮予定、確定、変更待ち、取消を分ける
開始日時	日時	予定の開始を持つ
終了日時	日時	予定の終了を持つ
終日フラグ	チェックボックス	時間帯なしの予定を分ける
主担当	ユーザー選択	責任者を明確にする
参加者	ユーザー選択、複数選択	関係者を表示する
関連顧客	ルックアップ	顧客予定とつなげる
関連案件	ルックアップ	商談や作業の発生元を残す
関連タスク	ルックアップ	作業予定とタスクをつなぐ
リソース	ルックアップ、選択肢	会議室、車両、設備を分ける
公開範囲	選択肢	全体、部門、担当者のみなどを分ける
外部予定ID	文字列	Google CalendarやGaroon連携に使う
連携状態	選択肢	未連携、同期済み、エラー、再同期待ち

予定アプリを作るとき、最初から全項目を必須にする必要はありません。

ただし、次の4つは最初から決めます。

• 開始日時
• 終了日時
• 主担当
• 状態

この4つがないと、カレンダー表示はできても、予定調整や未確定予定の管理に使いづらくなります。

予定名だけが並んだカレンダーは、見た目は分かりやすくても、業務判断には弱いです。

開始日時・終了日時・担当者・リソース

予定管理で一番重要なのは、時間の持ち方です。

日付だけでよい予定と、時間帯まで必要な予定を分けます。

予定の種類	必要な時間情報
納期	日付
提出期限	日付、必要なら時刻
商談	開始日時、終了日時
作業予定	開始日時、終了日時、担当者
会議室予約	開始日時、終了日時、リソース
出張	開始日時、終了日時、移動時間、終日扱い

日付だけで足りる予定を、無理に時間帯まで入力させる必要はありません。

一方で、会議、訪問、作業、リソース予約は、開始日時と終了日時が必要です。

終了日時がない予定は、時間帯の重複や空き状況を判断できません。

担当者と参加者も分けます。

人の項目	役割
主担当	予定の責任者
参加者	同席、参加、共有対象
確認者	承認や確認をする人
代理担当	主担当不在時に動く人

リソースは、人とは別にします。

会議室、社用車、備品、撮影機材、作業スペースなどです。

リソースを参加者欄に混ぜると、空き状況や重複チェックがしづらくなります。

リソース	管理する理由
会議室	二重予約を防ぐ
社用車	使用時間と返却予定を見たい
設備	利用可能時間、準備、故障を把握する
機材	貸出、返却、点検を管理する
作業場所	現場や部屋の利用枠を管理する

kintoneカレンダーでリソース管理をするなら、人の予定とリソースの予約を同じ項目に混ぜず、予定・担当者・リソースを分けます。

色分け・期間表示・繰り返し予定

カレンダーを使いやすくするには、色分けが重要です。

ただし、色分けは見た目の好みではありません。

業務判断に必要な分類を色にします。

色分けの軸	向いている用途
予定種別	商談、作業、会議、移動、休暇
状態	仮、確定、変更待ち、取消
担当部門	営業、サポート、管理、現場
リソース	会議室、車両、設備
優先度	重要、通常、低

最初から色を増やしすぎると、誰も読み取れません。

初期は3から5種類程度に絞ります。

期間表示も設計が必要です。

1日の予定。

複数日にまたがる予定。

終日予定。

移動を含む予定。

準備時間を含む予定。

これらを同じ扱いにすると、カレンダー上では見えても実務では使いづらくなります。

繰り返し予定はさらに注意が必要です。

たとえば、毎週月曜の定例会議を作る場合です。

単純に同じレコードを複製するだけだと、次の問題が出ます。

• 祝日だけ中止したい
• 今週だけ時間を変えたい
• 来月から参加者を変えたい
• 過去分は変えず、未来分だけ変えたい
• 親予定と各回の予定の関係が分からない

繰り返し予定をkintoneで扱うなら、親予定と子予定を分けます。

データ	役割
繰り返し親予定	毎週、毎月などのルールを持つ
各回の予定	実際の日付、参加者、状態を持つ
例外日	中止、変更、追加開催を持つ
変更範囲	今回だけ、今回以降、全件を分ける

ただし、繰り返し予定が多い会社では、Google CalendarやGaroonを正本にした方がよいです。

kintoneは、業務データと紐づく予定、案件由来の予定、リソース予約、社内確認予定に寄せると設計しやすくなります。

カレンダーPlusなどプラグインの判断

カレンダー表示を強化したい場合、プラグインを使う選択肢があります。

テクバンの記事でも、カレンダーPlusでは週・日単位の表示、ドラッグ操作、色分け、モバイル対応、リソース表示などが紹介されています。

テクバン：kintoneのカレンダー表示機能

また、カレンダーPlusの製品ページでは、月別・週別・日別表示やリソース管理などの機能が訴求されています。

ラジカルブリッジ：カレンダーPlus

プラグインを入れるかどうかは、見た目ではなく、運用要件で判断します。

要件	標準カレンダー	プラグイン検討
月単位で日付を見たい	向いている	不要なことが多い
週・日単位で時間帯を見たい	弱い	検討する
ドラッグで予定を変更したい	弱い	検討する
色分けを細かくしたい	弱い	検討する
会議室や車両を横並びで見たい	弱い	検討する
モバイルで予定調整したい	要件次第	検討する
業務データと予定をつなぎたい	向いている	標準でも設計可能

プラグインを使う場合でも、予定DBの設計は先に必要です。

開始日時。

終了日時。

表示タイトル。

予定種別。

担当者。

リソース。

状態。

これらが曖昧なままプラグインを入れても、見やすいカレンダーにはなりますが、運用は安定しません。

特に、ドラッグで予定変更できる場合は、変更権限を決めます。

操作	誰に許可するか
仮予定の作成	担当者
確定予定の時間変更	主担当、管理者
リソース予約の変更	予約者、管理者
他人の予定変更	マネージャー、管理者
取消	主担当、管理者
繰り返し予定の一括変更	管理者

カレンダーは操作しやすいほど、誤変更も起きやすくなります。

そのため、プラグイン導入時は、見た目だけでなく、誰が何を変更できるかまで設計します。

Google Calendar・Garoon連携の境界

予定管理では、外部カレンダーとの境界が重要です。

kintoneを予定管理の正本にするのか。

Google CalendarやGaroonを正本にするのか。

ここを決めないと二重管理になります。

kintone公式ヘルプでも、Garoonやサイボウズ Officeのクラウド版とkintoneを併用している場合に、プラグインを利用してkintoneアプリのデータを予定と紐付けられることが案内されています。

kintoneヘルプ：kintoneでスケジュールを管理するには

外部カレンダーとの使い分けは、次のように考えます。

領域	kintoneを正本にしやすい	外部カレンダーを正本にしやすい
案件由来の訪問予定	顧客、案件、活動履歴と紐づく	個人の空き時間調整が必要
作業予定	タスク、担当、期限と紐づく	個人予定として通知したい
会議室予約	リソースDBと紐づく	組織カレンダーに統合したい
社内会議	議題やタスクと紐づく	招待、参加回答、個人予定が中心
繰り返し予定	業務データの親子管理が必要	毎週・毎月の予定調整が多い
個人予定	原則向かない	Google CalendarやGaroonが向く

Bitlightとしては、個人の予定表をkintoneで置き換える設計はあまりおすすめしません。

個人予定、招待、参加回答、空き時間確認、繰り返し予定は、Google CalendarやGaroonの方が自然です。

kintoneは、予定が業務レコードと強く紐づく場合に使う方が向いています。

たとえば、案件訪問、作業予約、点検予定、設備予約、問い合わせ対応予定です。

これらは、予定だけでなく、顧客、案件、タスク、リソース、対応結果とつながるからです。

よくある失敗パターン

kintoneカレンダーでは、次の失敗がよく起きます。

失敗1：予定名と日付だけで作る

予定名と日付だけでもカレンダーには表示できます。

しかし、開始時刻、終了時刻、主担当、状態がないと、予定調整には使いづらくなります。

失敗2：担当者と参加者を混ぜる

担当者は責任者です。

参加者は関係者です。

同じ項目に入れると、誰が予定を管理するのか分からなくなります。

失敗3：リソースを人と同じ欄に入れる

会議室や車両をユーザー選択のように扱うと、空き状況や重複チェックがしづらくなります。

リソースはリソースとして分けます。

失敗4：繰り返し予定を手で複製する

手で複製すると、例外日、変更範囲、中止、参加者変更が追えなくなります。

繰り返しが多いなら、外部カレンダーを正本にする判断も必要です。

失敗5：外部カレンダーと二重管理になる

kintoneとGoogle Calendarの両方で予定を編集できると、どちらが正しいか分からなくなります。

正本と同期方向を決めます。

失敗6：色分けを増やしすぎる

色が多いほど見やすくなるわけではありません。

業務判断に使う分類だけに絞ります。

失敗7：権限を決めずに予定変更を許す

ドラッグで予定を動かせるようにすると便利です。

しかし、確定予定や他人の予定を誰でも動かせると、現場が混乱します。

変更できる状態と担当者を決めます。

1週間で始めるならこの順番

最初から高度なカレンダーを作る必要はありません。

まずは、予定の正本と表示範囲を決めるところから始めます。

1日目：予定の種類を棚卸しする

現在扱っている予定を分類します。

• 商談予定
• 社内会議
• 作業予定
• 納期
• 点検予定
• 会議室予約
• 社用車予約
• 休暇や不在
• 繰り返し予定

全部を同じ予定アプリで扱う必要はありません。

2日目：kintoneに置く予定を決める

業務データと紐づく予定をkintoneに寄せます。

個人予定や招待中心の予定は、Google CalendarやGaroonに任せる判断をします。

3日目：予定アプリの必須項目を決める

開始日時、終了日時、主担当、状態を決めます。

必要に応じて、予定種別、関連案件、関連タスク、リソースを追加します。

4日目：標準カレンダーで足りるか確認する

月単位で見るだけなら、標準カレンダーで始めます。

週・日表示、ドラッグ変更、リソース表示が必要ならプラグインを検討します。

5日目：リソース管理を分ける

会議室、車両、設備、機材を使う場合は、リソースマスタを作ります。

予定レコードとは別に、何を使う予定なのかを紐づけます。

6日目：外部カレンダー連携を決める

Google CalendarやGaroonと連携する場合は、正本、同期方向、外部予定ID、エラー時の確認者を決めます。

7日目：一覧と通知を作る

未確定予定、今日の予定、担当者別予定、リソース別予定、同期エラー一覧を作ります。

カレンダー表示だけではなく、例外を拾う一覧も作ります。

予定管理で重要なのは、きれいなカレンダーを作ることだけではありません。

予定の抜け、重複、未確定、同期エラーを見つけられることです。

実装前チェックリスト

kintoneカレンダーを作る前に、次の項目を確認します。

チェック項目	確認内容
予定の正本	kintone、Google Calendar、Garoonのどれを正本にするか
予定単位	1予定、1作業、1予約、1期限のどれを扱うか
開始・終了	日付だけか、日時まで必要か
終日予定	終日の扱いをどうするか
主担当	誰が予定の責任者か
参加者	参加者、確認者、共有対象を分けるか
リソース	会議室、車両、設備を別管理するか
色分け	予定種別、状態、担当部門のどれで分けるか
繰り返し	親予定、子予定、例外日を扱うか
公開範囲	非公開、部門限定、全社公開を分けるか
権限	誰が作成、変更、取消できるか
通知	予定前、未確定、期限超過を誰に通知するか
外部連携	同期方向、外部予定ID、エラー時の運用があるか
プラグイン	標準で足りるか、カレンダーPlus等が必要か

この表が埋まらないままカレンダーを作ると、見た目は整っても、予定管理としては不安定になります。

特に、予定の正本、開始・終了日時、リソース、外部連携は先に決めます。

Bitlightに相談するなら、最初に見たいもの

kintoneカレンダーの相談では、最初に次の情報があると設計が早くなります。

用意してほしいもの	見る理由
現在の予定表	予定の種類と粒度を見る
Google CalendarやGaroonの運用	外部カレンダーの正本を確認する
案件・タスク管理の画面	予定の発生元を確認する
会議室・車両・設備の管理方法	リソース設計を決める
繰り返し予定の例	kintoneで持つか外部に任せるかを見る
権限の希望	誰が予定を見て、誰が変更できるかを見る
使いたい表示	月、週、日、担当者別、リソース別を確認する

完成した要件定義書は不要です。

実際の予定表、会議室予約、案件予定、作業予定、外部カレンダーの使い方が分かる方が、実務に合う設計にできます。

Bitlightでは、kintoneにカレンダー表示を追加するだけではなく、予定管理として次の論点を整理します。

• 標準カレンダーで足りるか
• カレンダーPlusなどのプラグインが必要か
• 予定アプリの必須項目
• 開始日時・終了日時・終日予定の扱い
• 担当者、参加者、リソースの分け方
• 繰り返し予定と例外日の扱い
• Google Calendar・Garoonとの正本分担
• 権限、通知、同期エラー一覧の設計

ここまで決めると、kintoneカレンダーは単なる月表示ではなく、業務データとつながる予定管理になります。

まとめ

kintoneでカレンダー表示を使うことはできます。

ただし、予定名と日付を並べるだけでは、チームの予定管理としては弱いです。

予定レコードを設計する。

開始日時と終了日時を分ける。

担当者と参加者を分ける。

人とリソースを分ける。

標準カレンダーとプラグインの役割を分ける。

繰り返し予定をkintoneで持つか外部に任せるかを決める。

Google CalendarやGaroonとの正本を決める。

これらを整理すると、kintoneカレンダーは、予定を眺める画面ではなく、案件、タスク、リソース、外部カレンダーをつなぐ予定管理になります。

kintoneカレンダーは、予定を表示するためだけではなく、業務データに紐づく予定・リソース・通知・外部連携を管理するために設計します。

最初に作るべきなのは、きれいなカレンダー画面ではありません。

予定レコード、開始・終了日時、担当者、リソース、外部連携の分け方です。

その土台ができてから、標準カレンダーで足りるか、プラグインを入れるか、Google CalendarやGaroonへ逃がすかを判断します。