kintoneでできること・できないこと｜導入前に分ける業務設計

kintoneでできることを調べると、アプリ作成、レコード管理、一覧、グラフ、通知、コメント、アクセス権、プロセス管理、ルックアップ、関連レコード、プラグイン、API連携など、多くの機能が出てきます。

どれも重要です。

ただし、導入前に見るべきなのは、機能が存在するかどうかだけではありません。

その業務をkintoneに任せてよいかです。

たとえば、問い合わせ管理、案件管理、申請管理、日報、作業依頼、見積前の確認、契約後のタスク、台帳管理は、kintoneと相性がよいことが多いです。

一方で、会計仕訳、給与計算、複雑な在庫引当、全社共通の承認基盤、厳密な販売管理、顧客接点を深く追うCRMを、すべてkintoneだけで作るのは慎重に考えるべきです。

できるかどうかより、壊れずに運用できるか。

変更できるか。

誰が責任を持つか。

外部システムとどちらを正本にするか。

ここを決めないまま「kintoneでできますか」と聞くと、答えは曖昧になります。

kintoneでできること・できないことは、機能一覧ではなく「どの業務データをkintoneの正本にし、どこから外部システムに任せるか」で判断します。

この記事では、kintoneに向く業務、向かない業務、プラグインで補う範囲、API連携でつなぐ範囲、外部システムに残す範囲を、導入前の業務設計として整理します。

kintoneアプリ作成の設計方法はこちら
kintoneデータベースの設計方法はこちら
kintone Excel読み込みの設計方法はこちら
kintone連携サービス選定の設計方法はこちら
kintone API連携の設計方法はこちら

先に結論：kintoneは「変わり続ける業務台帳」に向く

kintoneは、現場で項目や一覧を変えながら使う業務台帳に向いています。

顧客。

案件。

問い合わせ。

作業依頼。

申請。

見積前の確認。

契約後のタスク。

日報。

設備台帳。

備品台帳。

こうした業務では、入力項目、一覧、通知、コメント、アクセス権、ステータスが日常的に変わります。

Excelでは、列の追加、色分け、ファイル分岐、最新版管理、コメントの散在が起きやすくなります。

専用システムでは、少しの変更にも改修費用やベンダー調整が必要になることがあります。

kintoneは、その中間に置きやすい道具です。

標準機能でフォームを作り、レコードを登録し、一覧で絞り込み、グラフで集計し、コメントでやり取りし、通知で次の担当者へ渡し、アクセス権で見せる範囲を制御できます。

サイボウズの基本機能でも、アプリで統一したフォーマットのデータ登録、グラフ、コメント、プロセス管理、一覧、検索、アクセス権、アプリ同士の連携、変更履歴、通知などが紹介されています。

サイボウズ：kintoneの基本機能

ただし、向いているからといって、何でもkintoneに集めればよいわけではありません。

判断は次のように分けます。

判断	kintoneに任せやすいこと	注意すること
標準機能で作る	台帳、一覧、通知、コメント、軽い承認、簡単な集計	アプリを増やしすぎない
プラグインで補う	帳票、フォーム、入力補助、集計、バックアップ	製品ごとの保守責任を決める
API連携でつなぐ	外部システムとの登録、更新、通知、参照	正本、更新方向、失敗時対応を決める
外部システムに任せる	会計、給与、厳密な在庫、複雑なCRM、全社承認基盤	kintoneには確認用データだけ持つ
作らない	使う人が少ない、変化しない、責任者がいない業務	Excelや既存画面のまま残す判断もある

導入前の判断は、「kintoneで再現できるか」ではなく、「kintoneを正本にしたときに、入力、確認、変更、監査、連携まで説明できるか」です。

kintoneでできることを4層に分ける

kintoneでできることは、ひとまとめにしない方がよいです。

導入設計では、標準機能、プラグイン、API連携、外部システムの4層に分けます。

層	主な役割	例
標準機能	業務データを登録し、一覧、通知、権限、状態で回す	顧客台帳、案件管理、申請、作業依頼
プラグイン	標準機能で足りない入力、出力、集計、表示を補う	帳票出力、フォーム連携、集計、バックアップ
API連携	外部システムとデータを受け渡す	会計ソフト、CRM、基幹システム、チャット
外部システム	専門領域の正本や処理エンジンを持つ	会計、給与、在庫、販売管理、契約管理

標準機能で十分な業務に、最初から外部連携を入れると重くなります。

逆に、外部システムに任せるべき処理を、kintoneのアプリと手入力で再現しようとすると、二重管理や転記ミスが増えます。

たとえば、見積前の社内確認はkintoneに向いています。

案件、顧客、見積条件、承認状態、コメント、差し戻し理由をレコードにまとめられるからです。

しかし、正式な請求書、売掛、入金消込、仕訳は会計ソフトに残す方が自然です。

kintoneには、会計ソフトへ渡す前の確認情報や、会計ソフトから戻す結果だけを持たせます。

この分担を先に決めると、「できること」はかなり明確になります。

標準機能でできること

kintone標準機能で扱いやすいのは、次のような業務です。

できること	実務での使い方
アプリ作成	Excelや紙の台帳を、入力フォームとレコードに分ける
一覧	未対応、期限超過、自分の担当、承認待ちを切り替える
グラフ	件数、金額、状態別、担当者別の集計を見る
コメント	レコード単位で確認事項や判断理由を残す
通知	登録、更新、期限、作業者変更を知らせる
プロセス管理	申請、確認、差し戻し、完了の状態を進める
アクセス権	アプリ、レコード、フィールド単位で閲覧や編集を制御する
ルックアップ	顧客、商品、担当者などのマスタ情報を参照する
関連レコード	顧客に紐づく案件や履歴を同じ画面で見る
変更履歴	誰がいつ何を変更したかを確認する

これらは、特定部署の業務や、部門をまたぐ軽い確認フローに向いています。

たとえば、次のようなアプリは標準機能から始めやすいです。

• 問い合わせ管理
• 顧客管理
• 案件管理
• 日報
• タスク管理
• 備品申請
• 見積前確認
• 契約後の作業管理
• セミナー申込管理
• 設備点検記録

kintone顧客管理の設計方法はこちら
kintone案件管理の設計方法はこちら
kintoneタスク管理の設計方法はこちら

標準機能で作る場合も、最初に決めることがあります。

1レコードが何を表すのか。

誰が登録するのか。

誰が確認するのか。

どの状態になったら完了なのか。

どの項目は後から変更してよいのか。

誰が見てよいのか。

どのデータを外部システムへ渡すのか。

この設計がないまま作ると、入力はできても業務が進まないアプリになります。

アクセス権でできることと、できないこと

kintoneでは、アプリ単位、レコード単位、フィールド単位でアクセス権を設計できます。

公式ヘルプでも、アプリのアクセス権では、レコード閲覧、追加、編集、削除、アプリ管理、ファイル読み込み、ファイル書き出しを制御できると説明されています。

kintoneヘルプ：アプリにアクセス権を設定する

アクセス権は、kintoneでできることの中でも重要です。

ただし、アクセス権で何でも解決しようとすると危険です。

やりたいこと	kintoneでの考え方
部署ごとに閲覧範囲を分ける	アプリ、レコード、フィールド権限を使う
担当者だけ編集できるようにする	ユーザー選択フィールドやレコード権限を使う
承認後に編集を止めたい	プロセス管理、権限、必要ならカスタマイズを検討する
監査向けに厳密な履歴を残す	変更履歴で足りるか、外部の監査基盤が必要かを見る
例外権限を細かく増やす	運用で追える粒度に抑える

権限は増やすほど管理が重くなります。

部署、役職、担当者、ステータス、申請種別、金額条件をすべて組み合わせると、誰が何を見られるかを説明しづらくなります。

その場合は、1つのアプリに詰め込むのではなく、受付アプリ、管理アプリ、公開用アプリ、履歴アプリに分ける設計も検討します。

kintoneのアクセス権は強力ですが、権限設定で業務の曖昧さを隠すものではありません。誰が正本を更新するかを決めてから設定します。

Excelとの使い分け

Excelをkintoneに移すべきかは、表の見た目ではなく、業務の使われ方で判断します。

Excelに残してよいもの	kintoneへ移した方がよいもの
個人の一時メモ	複数人で更新する台帳
1回きりの集計	継続的に増える履歴
印刷用の表	期限や担当者で追う業務
数式検証用のシート	申請、確認、差し戻しがある業務
変化しない参考資料	コメントや変更履歴を残したい業務

Excelの強みは、自由に表を作れることです。

横に月を並べる。

セル結合で見やすくする。

一時的な計算列を足す。

ピボットで試算する。

これはExcelに向いています。

一方で、複数人が同じデータを更新し、担当者や期限があり、状態が変わり、履歴を残し、後から探す必要がある業務は、kintoneに移す価値があります。

ただし、Excelをそのまま読み込めばよいわけではありません。

Excelの1行が業務上の1件を表しているか。

マスタと取引が混ざっていないか。

履歴が横並びになっていないか。

色やコメントで状態を表していないか。

数式でしか意味が分からない列がないか。

これを整理してからアプリにします。

kintone Excel連携の設計方法はこちら
kintone CSV読み込みの設計方法はこちら

基幹システムとの使い分け

基幹システムをkintoneで置き換えたい、という相談はよくあります。

ここは慎重に見るべきです。

kintoneは、現場の周辺業務や確認フローには向いています。

しかし、会計、販売管理、購買、在庫、給与のような領域では、法令、締め処理、伝票番号、残高、同時更新、監査、外部提出、専門帳票が絡みます。

この領域を、kintoneだけで作ると、最初は動いても後から重くなりやすいです。

業務	kintoneに向く範囲	外部システムに残す範囲
会計	請求前確認、経費申請、売上見込み、承認前データ	仕訳、決算、税区分、入金消込
販売管理	見積前確認、案件別の進捗、社内メモ	受注、出荷、請求、売掛
在庫	棚卸依頼、入出庫予定、現場メモ	引当、原価、在庫評価、同時更新
購買	購買申請、見積比較、承認	発注、検収、支払、仕入計上
人事労務	申請、面談記録、提出物管理	給与計算、勤怠締め、社会保険

基幹システムの周辺にある「確認」「申請」「補足情報」「社内調整」をkintoneに置くのは有効です。

一方で、金額や残高の正本を二重に持つと危険です。

この場合は、kintoneを入力前の確認場所にするのか、外部システムから結果を受け取る場所にするのかを決めます。

freeeとkintone連携の設計方法はこちら
kintone在庫管理の設計方法はこちら

CRMとの使い分け

kintoneでも顧客管理や案件管理は作れます。

顧客情報。

案件情報。

商談メモ。

問い合わせ履歴。

見積状況。

契約後作業。

こうしたデータは、kintoneに向いています。

ただし、専用CRMやSFAと同じものを再現しようとすると、設計が重くなります。

項目	kintoneに向く使い方	専用CRMに向く使い方
顧客台帳	取引先情報と社内対応履歴を管理する	マーケティング施策や接点履歴を深く追う
案件管理	案件状態、担当、期限、見積前確認を管理する	リード、商談確度、パイプライン予測を細かく扱う
問い合わせ	受付、担当割当、回答状態を管理する	複数チャネルの顧客対応を一元管理する
契約後作業	契約後のタスクや社内引き継ぎを管理する	契約、請求、サポートまで統合管理する

営業部門だけで使う軽い案件管理なら、kintoneで十分なことがあります。

一方で、リード獲得から商談、メール、広告、カスタマーサクセス、売上予測まで一体で見るなら、専用CRMを正本にした方が自然です。

kintoneは、専用CRMの後ろにある契約後作業、申請、請求前確認、個別対応の管理に置くと相性がよいです。

kintone CRM設計はこちら
kintone SFA設計はこちら
kintone Salesforce連携の設計方法はこちら

ワークフローとの使い分け

kintoneにはプロセス管理があります。

申請、承認、差し戻し、完了のような状態管理は標準機能で作れます。

小さな申請、備品購入、見積確認、社内確認、作業依頼であれば、kintoneから始める価値があります。

ただし、全社共通の承認基盤をkintoneだけで作るかは別問題です。

要件	kintoneに向く範囲	専用ワークフローに向く範囲
固定ルート	少数部署、少数条件の承認	全社共通ルール
条件分岐	金額や種別による簡単な分岐	複雑な組織階層、役職、代理承認
承認後処理	kintoneレコードの状態変更	契約、購買、会計への厳密な連動
履歴	レコードコメントや変更履歴で追える範囲	監査向けの厳密な承認履歴

「kintoneでワークフローを作れるか」ではなく、「人事異動、組織変更、代理承認、差し戻し、監査、例外処理まで運用できるか」を見ます。

承認が複雑な場合は、申請データはkintone、承認基盤は外部、承認結果をkintoneへ戻す構成もあります。

kintoneワークフローの設計方法はこちら
kintoneワークフローでできないことはこちら
kintoneプロセス管理の設計方法はこちら

プラグインで補えること

kintone標準機能で足りない部分は、プラグインや連携サービスで補えます。

サイボウズの解説でも、プラグインはkintoneに適用してアプリ機能を拡張できるものとして紹介されています。

kintoneの歩き方：カスタマイズ・プラグイン・連携サービスの違いと使い方

プラグインで補いやすいのは、次のような範囲です。

補う範囲	例	注意点
入力補助	自動採番、入力制御、ルックアップ補助	承認済みデータを上書きしない
帳票出力	見積書、請求書、申請書PDF	出力してよい状態を制御する
外部フォーム	社外入力、申込、問い合わせ	受付後の確認フローを作る
集計	複数アプリの集計、クロス集計	正本と再計算タイミングを決める
バックアップ	レコード、添付、アプリ設定の保全	復元手順まで確認する
表示拡張	ガント、カレンダー、ダッシュボード	表示だけで業務責任を置き換えない

プラグインは便利ですが、入れれば入れるほど管理対象が増えます。

どのアプリに入っているか。

誰が設定できるか。

更新時にどこを確認するか。

ライセンス費用は誰が見るか。

サポート窓口はどこか。

この管理がないまま増やすと、作った時点では便利でも、半年後に誰も直せない状態になります。

プラグインは「kintoneでできないことを全部足す道具」ではなく、標準機能で足りない特定の役割を短く補う道具として選びます。

API連携でできること

API連携を使えば、外部システムとデータを受け渡せます。

外部フォームからkintoneへ登録する。

kintoneの状態変更をチャットへ通知する。

会計ソフトへ請求前データを送る。

CRMの商談から、kintoneの契約後作業を作る。

基幹システムのマスタをkintoneへ参照用に取り込む。

こうした構成は、kintoneの実務利用でよく出ます。

ただし、API連携は「つながる」だけでは足りません。

次の項目を決めます。

設計項目	決めること
正本	どちらのシステムが正式データか
更新方向	片方向か、双方向か
キー	顧客コード、案件番号、外部IDなど
差分	何を更新対象にするか
失敗時	再実行、保留、通知、手動修正
権限	APIトークン、ユーザー認証、操作範囲
量	件数、頻度、上限、実行時間

kintoneヘルプの制限値一覧では、ファイル読み込み、プラグイン、APIトークン、REST API同時アクセス数、1日に実行できるAPIリクエスト数など、設計時に確認すべき上限が整理されています。

kintoneヘルプ：制限値一覧

連携を作る前に、想定件数、実行頻度、失敗時の戻し方を見ます。

小さな連携なら、夜間バッチやボタン実行で十分です。

件数が多い場合や、リアルタイム性が必要な場合は、外部側にキューやログを持たせる設計も考えます。

kintone外部連携の設計方法はこちら
kintoneデータ連携の設計方法はこちら
kintone API制限の設計方法はこちら

kintoneに向かない業務

kintoneに向かない業務もあります。

正確には、kintoneで作れなくはないが、作ると運用が重くなる業務です。

向かない業務	理由
会計の正本	税区分、仕訳、締め、決算、入金消込が専門領域
給与計算	法令、社会保険、勤怠締め、支給控除が複雑
厳密な在庫引当	同時更新、原価、ロット、棚卸差異が絡む
高度なCRM	リード、メール、商談予測、施策履歴が深い
全社承認基盤	組織階層、代理、議決、監査が重い
大量データ分析	専用DBやBIに任せた方が見通しがよい
外部公開サイト	公開権限、SEO、表示速度、ログ管理が別領域
複雑な帳票基盤	帳票版管理、電子保存、配信、再発行が重い

この表に入る業務でも、kintoneを完全に使わないわけではありません。

たとえば、会計の正本は会計ソフトに置きます。

しかし、請求前の社内確認や、部門別の売上見込みはkintoneに置けます。

在庫の正本は販売管理システムに置きます。

しかし、棚卸依頼、出荷前確認、現場メモはkintoneに置けます。

CRMの正本は専用CRMに置きます。

しかし、契約後の個別作業、請求前確認、社内申請はkintoneに置けます。

重要なのは、置き換えではなく分担です。

導入前の判断フロー

導入前には、次の順番で判断します。

順番	問い	判断
1	その業務の1件は何か	顧客、案件、申請、作業、履歴を分ける
2	kintoneを正本にしてよいか	金額、残高、在庫、法定情報は慎重に見る
3	標準機能で回るか	フォーム、一覧、権限、通知、プロセス管理を見る
4	足りない部分は限定的か	帳票、フォーム、集計などをプラグインで補う
5	外部システムとつなぐ必要があるか	正本、更新方向、キー、エラー対応を決める
6	kintoneに向かない処理が混ざっていないか	専門システムへ残す
7	誰が保守するか	管理者、棚卸し、変更ルールを決める

この順番を飛ばすと、よくある失敗につながります。

標準機能で十分なのに、最初から重い連携を作る。

会計や在庫の正本までkintoneに持たせる。

Excelの列をそのままアプリ化して、マスタと履歴が混ざる。

プラグインを増やしすぎて、誰も構成を説明できなくなる。

外部システムとの更新方向を決めないまま、双方向連携を作る。

導入後に困るのは、機能不足だけではありません。

責任分界が曖昧なまま使い始めることです。

まとめ

kintoneでできることは多いです。

しかし、導入前に必要なのは、機能の数を覚えることではありません。

kintoneに向く業務を選び、標準機能で作る範囲、プラグインで補う範囲、APIでつなぐ範囲、外部システムに残す範囲を分けることです。

kintoneは、変わり続ける業務台帳、現場の確認フロー、部門間の作業管理に向いています。

Excelは一時的な試算や個人作業に残せます。

基幹システムは会計、在庫、販売、給与の正本として残すべき範囲があります。

CRMやワークフローも、専門領域が深い場合は無理に置き換えず、kintoneと役割を分けます。

最後に見るべき問いは、シンプルです。

この業務の正本を、kintoneに置いてよいか。

置くなら、誰が入力し、誰が確認し、誰が直し、どこへ連携するか。

そこまで説明できる業務から、kintone化するのが安全です。

Bitlightに相談できること

Bitlightでは、kintoneでできること・できないことを、機能名ではなく業務の分担として整理します。

相談できる内容は次の通りです。

• Excel、基幹システム、CRM、ワークフローの棚卸し
• kintoneを正本にするデータと、外部へ残すデータの整理
• 標準機能、プラグイン、API連携、外部システムの役割分担
• 顧客、案件、申請、履歴、マスタのアプリ分割
• アクセス権、通知、プロセス管理の設計
• API連携時の更新方向、キー、失敗時対応の設計
• 導入後に社内で直す範囲と、外部へ任せる範囲の整理

「kintoneでできますか」という問いだけでは、導入判断は曖昧になります。

どの業務をkintoneに載せ、どの業務をExcelや専用システムに残し、どこを連携するか。

この分担を先に決めることで、無理に作り込まないkintone導入にできます。