kintone業務設計研究所 > kintoneスケジュール管理の設計方法|カレンダー表示・予定DB・通知の使い分け
2026年6月8日
•約20分で読めます
kintoneでスケジュール管理を作る前に決めるべき、予定アプリ、会議、案件、タスク、参加者、通知、繰り返し予定、Garoon・Google Calendar・カレンダーPlusとの使い分けを整理します。
kintoneでスケジュール管理をしたいです。予定アプリを作って、カレンダー表示にすればよいでしょうか。
予定を見るだけなら始められる。ただし、kintoneのカレンダー表示は、一般的なスケジュール帳とは少し違う。予定を業務レコードとして扱うなら強いが、個人の空き時間管理や全社予定の調整まで抱えると重くなる。
kintoneでスケジュール管理を作るとき、最初に考えるのはカレンダー表示です。
予定名、日時、担当者、場所、メモ。
これらをアプリに入れて、カレンダー形式の一覧を作れば、予定は見えるようになります。
ただし、業務で使うスケジュール管理にするなら、カレンダー表示だけでは足りません。
スケジュール管理で本当に困るのは、予定をカレンダーに出せないことではなく、次のような状態です。
kintoneでスケジュール管理を作るなら、最初に設計すべきなのは「カレンダー」ではありません。
予定を、案件、会議、タスク、参加者、通知とつながる業務レコードとしてどう扱うかです。
kintoneスケジュール管理で最初に決めるべきなのは、カレンダー表示の見た目ではなく、「その予定がどの業務に紐づき、何を次の行動につなげるか」です。
この記事では、カレンダー表示の設定手順ではなく、kintoneでスケジュール管理を崩れにくい業務システムとして設計する方法を整理します。
kintone案件管理の設計方法はこちら
kintoneタスク管理の設計方法はこちら
kintoneでスケジュール管理を作るとき、予定アプリ1つだけでも始めることはできます。
ただし、実務で使うなら、最初から次の情報を分けて考えます。
| 分けるもの | 1レコードの意味 | 役割 |
|---|---|---|
| 予定 | 1つの日時を持つ業務イベント | 会議、訪問、作業日、納期、シフトなどを管理する |
| 参加者・担当 | 予定に関わる人 | 参加者、準備担当、確認者、社外参加者を分ける |
| 会議 | 1回の打ち合わせ | 議題、決定事項、議事録、次アクションを持つ |
| 案件・顧客 | 予定の紐づき先 | 商談、訪問、納期、顧客対応とつなぐ |
| タスク | 予定から発生する作業 | 準備、フォロー、期限、レビューへつなぐ |
| 繰り返し・シフト | 定期的に発生する予定 | 月次処理、週次会議、勤務枠を扱う |
| 一覧・通知 | 見るべき状態 | 当日予定、未確認、期限超過、議事録未作成を拾う |
| 連携ログ | 1回の外部連携 | カレンダー、会議URL、プラグイン連携の成否を追う |
kintoneの強みは、予定をレコードとして扱えることです。
予定が1レコードであれば、案件とつなげる、顧客とつなげる、会議後のタスクを作る、参加者別に一覧化する、未確認だけ通知する、といった設計ができます。
一方で、kintoneをGoogle CalendarやGaroonと同じスケジュール帳として使おうとすると、無理が出ます。
個人の空き時間調整、全社予定、会議室予約、ドラッグ操作、色分け、繰り返し予定などは、外部カレンダーやプラグインの方が向くことがあります。
重要なのは、kintoneで予定を表示することではなく、予定を業務データとして扱うかどうかです。
kintoneには、アプリのレコードをカレンダー形式で表示する機能があります。
kintone公式ヘルプでは、アプリのトップページをカレンダー形式で表示する手順が説明されています。
kintoneヘルプ:アプリのトップページをカレンダー形式で表示する
ここで大事なのは、kintoneのカレンダー表示は「アプリのレコード一覧の表示形式」だということです。
予定帳そのものではありません。
| できること | 設計上の意味 |
|---|---|
| 日付や日時のフィールドをもとに予定を表示する | 予定をレコードとして扱える |
| 予定名や担当者をタイトルとして見せる | 業務に必要な情報を表示できる |
| 絞り込み条件を使う | 自分の予定、部署別予定、案件別予定を分けられる |
| 一覧やグラフと併用する | カレンダー以外の見方も作れる |
| 関連レコードやルックアップとつなぐ | 案件、顧客、タスクと紐づけられる |
一方で、標準カレンダー表示だけで、一般的なスケジュールツールの使い勝手をすべて満たすとは限りません。
| 標準カレンダーだけでは弱いこと | 代替案 |
|---|---|
| ドラッグ操作で予定を動かしたい | カレンダーPlusなどのプラグインを検討する |
| 予定を色分けしたい | プラグイン、または一覧条件で分ける |
| 複数日の予定を自然に扱いたい | 開始日・終了日設計、プラグインを検討する |
| 個人の空き時間調整をしたい | Google CalendarやGaroonに任せる |
| 全社予定、会議室、設備予約を管理したい | Garoonなどグループウェアを検討する |
| 繰り返し予定を大量に作りたい | くりかえし系プラグインやバッチを検討する |
ロケットスタートの記事でも、kintoneのカレンダー表示はレコードと一対一で対応する点や、標準機能では色分け、祝日表示、ドラッグ操作に制限がある点が整理されています。
ロケットスタート:kintoneのカレンダー表示でスケジュール管理をしよう
kintoneのカレンダー表示は、予定をきれいに並べるためだけでなく、予定を案件・会議・タスクとつなぐために使うと価値が出ます。
予定アプリで最初に決めるべきなのは、予定名ではありません。
1レコードを何の単位にするかです。
| 予定の単位 | 向いているケース | 注意点 |
|---|---|---|
| 1予定1レコード | 会議、訪問、作業日、納期を管理する | 種別を分けないと混ざる |
| 1会議1レコード | 議題、参加者、議事録とつなぐ | 議事録やタスクの置き場所を決める |
| 1案件イベント1レコード | 商談、訪問、納期、検収を追う | 案件アプリとの関係を明確にする |
| 1シフト1レコード | 勤務枠や担当枠を管理する | 繰り返し作成や変更履歴が必要 |
| 1タスク期限1レコード | 作業期限をカレンダーで見る | タスク本体と二重管理になりやすい |
予定アプリには、最低限次の項目を持たせます。
| フィールド | 型 | 設計意図 |
|---|---|---|
| 予定名 | 文字列 | カレンダー上で識別する |
| 種別 | ドロップダウン | 会議、訪問、作業、納期、シフト、期限などを分ける |
| 開始日時 | 日時 | 予定の開始を表示する |
| 終了日時 | 日時 | 所要時間や終了を持つ |
| 終日 | チェック、選択肢 | 納期や終日予定を分ける |
| 主担当 | ユーザー選択 | 誰が責任を持つか |
| 参加者 | 複数ユーザー、文字列 | 誰が参加するか |
| 関連案件 | ルックアップ、関連レコード | 案件や顧客とつなぐ |
| 関連タスク | 関連レコード | 準備やフォローへつなぐ |
| 場所・URL | 文字列、リンク | 会議室、訪問先、オンラインURLを持つ |
| 状態 | ステータス、ドロップダウン | 予定、実施済み、延期、取消、未確認 |
小さく始める場合でも、種別、開始日時、主担当、状態は持たせます。
種別がないと、会議、作業期限、納期、シフトが同じ予定として混ざります。
状態がないと、延期、取消、実施済みが分かりません。
予定は、未来の予定だけではありません。
実施後の記録としても使います。
実施済みになった予定から、議事録、活動履歴、次回タスク、請求前確認へつなげると、予定が業務の流れに乗ります。
スケジュール管理で崩れやすいのは、予定を孤立させることです。
予定だけを見ると、日時は分かります。
しかし、なぜその予定があるのか、どの案件に関係するのか、会議後に何が必要なのかは分かりません。
| つなぐ先 | つなぐ理由 |
|---|---|
| 顧客 | 訪問、商談、打ち合わせの相手を明確にする |
| 案件 | どの商談やプロジェクトの予定かを追う |
| 活動履歴 | 実施後の接点として残す |
| 議事録 | 会議の決定事項やメモとつなぐ |
| タスク | 準備、フォロー、次回アクションへつなぐ |
| 契約・納期 | 契約更新、納品、検収などの期限を追う |
たとえば、商談予定を作るなら、予定アプリだけで完結させない方がよいです。
| 情報 | 置き場所 |
|---|---|
| 顧客名 | 顧客マスタ |
| 商談の進捗 | 案件アプリ |
| 商談予定日時 | 予定アプリ |
| 面談メモ | 活動履歴、会議アプリ |
| 次回対応 | タスクアプリ |
| 見積や請求 | 見積確認、会計ソフト |
会議予定も同じです。
予定アプリに「会議」と書くだけでは、会議後に何も残りません。
議題、決定事項、未決事項、次アクションを残す場所を決めます。
| 会議で残すもの | 置き場所 |
|---|---|
| 日時、参加者、場所 | 予定アプリ |
| 議題、決定事項 | 会議アプリ、議事録 |
| 宿題、次回対応 | タスクアプリ |
| 関連案件 | 案件アプリ |
| 顧客接点 | 活動履歴 |
予定を起点に、会議、案件、タスクへつなぐ。
これが、kintoneでスケジュール管理をする意味です。
予定には、参加者がいます。
しかし、参加者と担当者は違います。
| 役割 | 意味 |
|---|---|
| 主担当 | 予定の実行責任者 |
| 参加者 | 会議や訪問に参加する人 |
| 準備担当 | 資料、会場、事前確認を行う人 |
| 確認者 | 実施後の記録や議事録を確認する人 |
| 社外参加者 | 顧客、外部パートナー、ゲスト |
主担当を決めない予定は、流れます。
参加者が複数いても、誰が準備し、誰が実施後の記録を残すのかを決めます。
通知も、すべての予定変更を送ればよいわけではありません。
| 通知する状態 | 通知しすぎない方がよい状態 |
|---|---|
| 今日の予定が近い | メモ欄の軽微な修正 |
| 主担当が未設定 | 参加者の参考追加 |
| 議事録が未作成 | 実施済み予定の閲覧 |
| タスク未作成 | 予定名の修正 |
| 延期、取消 | 通常の予定作成すべて |
| 連携エラー | 連携成功ログ |
スケジュール管理で通知すべきなのは、行動が必要な状態です。
当日予定、未確認、未担当、議事録未作成、期限超過、延期、取消。
こうした例外を拾うために通知を使います。
一覧も同じです。
| 一覧 | 条件 | 見る人 |
|---|---|---|
| 今日の予定 | 開始日が今日 | 担当者 |
| 自分の予定 | 参加者または主担当に自分を含む | 各ユーザー |
| 未担当予定 | 主担当が空 | 管理者 |
| 実施済み・議事録なし | 状態が実施済み、議事録URLが空 | 主担当、確認者 |
| 延期・取消 | 状態が延期、取消 | 関係者 |
| 今週の案件予定 | 種別が商談、関連案件あり | 営業 |
| 期限超過タスク | 関連タスクが未完了 | 責任者 |
スケジュール管理では、繰り返し予定が出てきます。
週次会議。
月末処理。
定期点検。
勤務シフト。
定例訪問。
これらを毎回手作業で作ると、必ず漏れます。
ただし、繰り返し予定を最初から複雑に作りすぎるのも危険です。
| 予定の種類 | 設計方針 |
|---|---|
| 少数の定例会議 | 手動コピー、または簡単なテンプレートで足りる |
| 月末処理や定期点検 | 予定生成ルールを持たせる |
| 勤務シフト | シフト専用アプリやプラグインを検討する |
| 店舗や拠点ごとの繰り返し | 拠点、担当、例外日を持たせる |
| 祝日や営業日を考慮する予定 | 外部カレンダーやプラグインを検討する |
くりかえしPlusのような連携サービスは、勤務シフト、週次ミーティング、月末処理など、定期予定レコードを作る用途で使えます。
繰り返し予定で決めるべきことは、次の通りです。
| 決めること | 例 |
|---|---|
| 作成単位 | 1週間分、1か月分、四半期分 |
| 例外日 | 祝日、休業日、担当者不在 |
| 変更方法 | 個別予定だけ変えるか、以後すべて変えるか |
| 重複防止 | 同じ予定を二重作成しないキー |
| 取消方法 | 削除ではなく取消状態にするか |
| 確認者 | 作成後に誰が確認するか |
繰り返し予定は、一度作ると大量のレコードを生みます。
だからこそ、作成漏れより、二重作成や変更漏れも問題になります。
最初は対象を絞り、業務上本当に必要な定期予定から自動化する方が安全です。
kintoneでスケジュール管理を設計するときは、kintoneに持たない範囲を決めます。
| 領域 | kintoneで持ちやすいもの | 外部に任せやすいもの |
|---|---|---|
| 業務予定 | 案件、会議、作業日、納期、点検、訪問 | 個人の細かい予定 |
| 会議予定 | 案件や議事録に紐づく会議 | 空き時間調整、会議室予約 |
| 全社予定 | 業務アプリと関係する期限 | 会社行事、休暇、全社共有予定 |
| 個人予定 | 業務レコードに紐づく作業日 | プライベート予定、空き時間 |
| 繰り返し | 定例処理、点検、シフト | 複雑な営業日・祝日判定 |
| 表示UI | 標準カレンダー、一覧、グラフ | 色分け、ドラッグ操作、週日表示の高度なUI |
Garoonは、社内グループウェアとして予定、施設、社内共有を扱う用途に向きます。
Google CalendarやOutlook Calendarは、個人予定、空き時間、外部招待、オンライン会議との連携に向きます。
カレンダーPlusなどのプラグインは、kintoneの予定レコードをよりカレンダーらしく操作したい場合に向きます。
ここで大事なのは、二重管理にしないことです。
| 悪い状態 | 起きること |
|---|---|
| Google Calendarにもkintoneにも同じ予定を手入力 | 片方だけ変更される |
| Garoon予定を見ながらkintone予定も別で登録 | 参加者や時間がずれる |
| kintoneの予定を手でプラグイン表示用に加工 | 更新漏れが起きる |
| 個人予定までkintoneに登録 | 入力負荷が上がり、使われなくなる |
kintoneは、業務予定の正本にするか、業務予定の確認画面にするかを決めます。
Google CalendarやGaroonを正本にするなら、kintoneには業務に必要な予定だけを持たせる。
kintoneを正本にするなら、外部カレンダーへ出す範囲や同期失敗時の戻し方を決める。
どちらかを曖昧にすると、予定が信用できなくなります。
予定は、複数人で見る情報です。
しかし、全員が自由に直せると、予定が信用できなくなります。
| 役割 | 閲覧 | 追加 | 編集 | 削除 |
|---|---|---|---|---|
| 主担当 | 自分の予定、関連予定 | 予定 | 自分の予定、実施結果 | 原則不可 |
| 参加者 | 参加予定 | コメント、確認 | 自分の参加可否、補足 | 原則不可 |
| 確認者 | 確認対象予定 | 確認コメント | 実施確認、差し戻し | 原則不可 |
| 管理者 | 全体 | 全体 | 全体 | 制限付き |
| 外部連携ユーザー | 連携対象のみ | API対象のみ | API対象のみ | 原則不可 |
削除権限は慎重に扱います。
予定を削除できると、なぜ会議がなくなったのか、訪問が延期されたのか、作業が実施されなかったのかが残りません。
間違えた場合は、削除ではなく、延期、取消、重複、無効として扱う方が安全です。
kintoneでは、アプリ、レコード、フィールド単位でアクセス権を設定できます。
スケジュール管理では、特に日時、主担当、状態、関連案件、議事録URLを誰が直せるかを決めます。
予定時刻を参加者が自由に変えられるのか。
主担当だけが変更できるのか。
実施済み後に日時を直せるのか。
ここを決めないと、予定と実績の差が分からなくなります。
kintoneスケジュール管理の失敗は、機能不足より設計不足で起きます。
| 失敗 | 起きること | 設計で直すこと |
|---|---|---|
| 予定アプリだけ作る | 案件、会議、タスクとつながらない | 関連先を持たせる |
| 会議、納期、作業日を混ぜる | 種別ごとの見方ができない | 種別と一覧を分ける |
| 参加者と担当者を混ぜる | 誰が準備・実施責任を持つか曖昧になる | 主担当、参加者、確認者を分ける |
| 実施後の記録を残さない | 会議後の決定事項や宿題が流れる | 議事録、活動履歴、タスクへつなぐ |
| 繰り返し予定を手作業で作る | 作成漏れ、重複が起きる | 生成ルールやプラグインを検討する |
| すべてkintoneで予定管理する | 個人予定や全社予定まで重くなる | GaroonやGoogle Calendarと分ける |
| 通知を増やしすぎる | 当日予定や未確認が埋もれる | 未担当、未確認、期限、例外だけ通知する |
| 削除権限を広く渡す | 取消や延期の履歴が消える | 状態で取消・延期を残す |
| プラグインを先に入れる | 見た目は良いが予定DBが崩れる | データ設計を先に決める |
特に危ないのは、カレンダー表示を作っただけでスケジュール管理ができたと思うことです。
予定が見えていても、関連案件、参加者、担当、実施後の記録、次アクション、通知がなければ、業務は回りません。
最初から完全なスケジュール管理を作る必要はありません。
小さく始めるなら、1週間で次の順番で設計します。
| 日 | やること | 成果物 |
|---|---|---|
| 1日目 | 予定の種類を整理する | 会議、訪問、作業日、納期、シフト、期限 |
| 2日目 | 予定アプリを作る | 予定名、種別、開始日時、終了日時、主担当 |
| 3日目 | 案件・会議・タスクとつなぐ | 関連案件、議事録URL、次回タスク |
| 4日目 | 一覧とカレンダー表示を作る | 今日の予定、自分の予定、未担当、議事録なし |
| 5日目 | 通知とリマインドを設計する | 当日通知、未確認、期限超過、延期・取消 |
| 6日目 | 権限と更新責任を決める | 主担当、参加者、確認者、管理者 |
| 7日目 | 外部カレンダーとの境界を整理する | Garoon、Google Calendar、カレンダーPlus、くりかえしPlus |
この段階で、複雑な双方向同期や高度なカレンダーUIまで入れなくて構いません。
まず作るべき状態は、次です。
ここまでできれば、次にプラグイン、繰り返し予定、Google Calendar連携、Garoon連携、会議URL連携へ進めます。
逆に、この状態を作らないままカレンダー表示だけ整えると、きれいに並んだだけの予定表になります。
kintoneでスケジュール管理を作る前に、最低限次の質問に答えます。
| 質問 | 決めること |
|---|---|
| 予定の種類は何か | 会議、訪問、作業日、納期、シフト、期限 |
| 1予定の単位は何か | 1会議、1訪問、1作業日、1シフト、1納期 |
| 予定の正本はどこか | kintone、Garoon、Google Calendar、プラグイン |
| 主担当は誰か | 実施責任者、準備担当、確認者 |
| 参加者はどう持つか | 社内ユーザー、社外参加者、部署、グループ |
| 実施後に何を残すか | 議事録、活動履歴、決定事項、次回タスク |
| 繰り返し予定を扱うか | 週次会議、月末処理、シフト、定期点検 |
| 何を通知するか | 当日予定、未担当、議事録なし、期限超過、延期・取消 |
| どの表示を使うか | 標準カレンダー、一覧、グラフ、カレンダーPlus |
| 誰が編集できるか | 主担当、参加者、確認者、管理者、外部連携ユーザー |
| 何をkintoneに持たないか | 個人予定、空き時間、全社会議室予約、複雑なシフト管理 |
このチェックリストに答えられない状態で予定アプリを作ると、あとからフィールド追加、一覧変更、外部カレンダーとの二重管理、権限変更が続きます。
小さく始めることはできます。
ただし、小さく始める範囲と、最初から設計しておく範囲は分けます。
予定種別、主担当、参加者、関連案件、実施後の記録、通知、外部カレンダーとの境界は、最初に決めた方がよいです。
kintoneでスケジュール管理を作るときは、「カレンダー表示を1つ作る」と考えない方がよいです。
予定アプリ、参加者、会議、案件、タスク、繰り返し予定、一覧・通知、連携ログを分けます。
そのうえで、予定を業務レコードとして扱うのか、個人予定や全社予定は外部カレンダーに任せるのかを決めます。
kintoneスケジュール管理の設計で大事なのは、予定をカレンダーに並べることではなく、予定から会議記録・案件進捗・タスク・通知へつながる状態にすることです。
案件に紐づく訪問、会議、作業日、納期、定期点検、シフトのような業務予定なら、kintoneで十分に始められます。
一方で、個人の空き時間、会議室予約、全社スケジュール、複雑な繰り返し予定まで含むなら、Garoon、Google Calendar、プラグインと役割分担する判断も必要です。
カレンダー表示やプラグインを選ぶ前に、まず予定を何の業務レコードとして扱うのかを決める。
それが、kintoneスケジュール管理を崩れにくくする一番の近道です。
千葉県出身。10歳の頃からプログラミングを始め、ゲーム、Webサイト、ロボット、スマホアプリなどを制作。大阪大学基礎工学部情報科学科で情報工学と統計学を学び、大学時代はAIを研究。大学在学中にWeb広告代理店でのインターンや人材系Webサービスの立ち上げを経験し、卒業後はフリーランスエンジニアとしてGISシステム、データ基盤構築、Webシステムの開発に従事。10年以上のWebアプリ開発・データ分析経験を基に、2023年9月に株式会社ビットライトを設立し、現場業務の仕組み化からデータ基盤構築、データ活用支援までを一気通貫で支援。