kintone業務設計研究所 > kintoneとスプレッドシート連携の設計方法|集計・共有・同期を分ける構成
2026年6月12日
•約19分で読めます
kintoneとGoogleスプレッドシートを連携するときに、集計、社外共有、一時加工、再取込、自動更新の用途を分け、CSV、GAS、プラグイン、iPaaS、同期方向、権限、ログをどう設計するか整理します。
kintoneのデータをGoogleスプレッドシートと連携したいです。リアルタイム同期にすればよいでしょうか。
リアルタイム同期が必要な場面はあります。ただし、最初に決めるべきなのは同期速度ではなく、スプレッドシートを集計、共有、一時加工、再取込のどれに使うかです。
kintoneとGoogleスプレッドシートを連携したい、という相談はよくあります。
kintoneの案件一覧をスプレッドシートで集計したい。
月報やピボット表を自動で更新したい。
kintoneアカウントを持たない社外メンバーに一部のデータを共有したい。
上長確認用にスプレッドシートへ出して、コメントを入れてもらいたい。
部門ごとの修正候補をスプレッドシートで集めて、kintoneへ戻したい。
Google Apps Scriptで定期的にkintoneのレコードを取得したい。
プラグインやiPaaSで、kintoneとスプレッドシートを同期したい。
こうした要望は自然です。
スプレッドシートは、共有しやすく、集計しやすく、現場が触りやすい道具です。
しかし、kintone連携で扱いを誤ると、Excel連携よりも早く運用が崩れます。
理由は、同じファイルを複数人が同時に編集でき、共有範囲も広がりやすいからです。
よくある失敗は、次のような状態です。
kintoneから出した一覧をスプレッドシートで編集し、そのファイルがいつの間にか正式な台帳になる。
スプレッドシートで修正した担当者や金額が、kintoneに戻ったり戻らなかったりする。
外部共有用のシートに、社内向けの項目まで残っている。
GASの定期実行が失敗しているのに、誰も気づかない。
編集時トリガーで二重登録が起きる。
行の並び替えやフィルタ操作で、更新対象のレコードがずれる。
列名が変わり、次回の取込や同期が壊れる。
共有リンクを知っている人が見られる状態になり、閲覧範囲を追えなくなる。
kintoneとスプレッドシート連携で最初に決めるべきなのは、「リアルタイムにするか」ではなく、「スプレッドシートを正本にしないための役割分担」です。
この記事では、kintoneとGoogleスプレッドシートを連携するときに、集計、社外共有、一時加工、再取込、自動更新の用途を分け、CSV出力、プラグイン、GAS、iPaaS、REST APIの使い分け、片方向同期と双方向同期、更新キー、競合、権限、ログ、失敗通知まで整理します。
kintone Excel連携の設計方法はこちら
kintone CSV出力の設計方法はこちら
kintone CSVインポートの設計方法はこちら
スプレッドシート連携では、まず正本を決めます。
多くの業務では、正本はkintone側に置いた方が安全です。
正本とは、業務上の正式な値として扱う場所です。
案件状態、請求金額、顧客情報、在庫数、承認状態、対応履歴などは、kintone側のアプリで管理します。
スプレッドシートは、そのデータを見たり、集計したり、一時的に確認したりする道具として使います。
| データ | 正本にする場所 | スプレッドシート側の役割 |
|---|---|---|
| 顧客名、住所、担当者 | 顧客マスタ | 参照、外部共有用の一部表示 |
| 案件名、状態、金額 | 案件アプリ | 月報、確認表、分析 |
| 請求日、請求番号 | 請求アプリ | 経理確認、提出用一覧 |
| 在庫数、入出庫履歴 | 在庫アプリ | 集計、棚卸前の確認 |
| 承認状態 | kintoneプロセス管理 | 参照のみ |
| 社外コメント | コメント用シートまたは別アプリ | 戻す場合は確認後に登録 |
スプレッドシートを正本にすると、次の問題が出やすくなります。
誰がどのセルを変えたか、業務レコード単位で追いにくい。
行の追加、削除、並び替えで、kintoneのレコードとの対応が崩れやすい。
関数や手入力が混ざり、正式値と計算値の境界が曖昧になる。
共有先が増え、閲覧範囲や編集範囲の管理が難しくなる。
同じスプレッドシートのコピーが増え、どれが最新版か分からなくなる。
もちろん、スプレッドシートをまったく更新元にしない、という意味ではありません。
更新候補を集めるシート、外部提出ファイル、棚卸結果、月次補正など、スプレッドシートからkintoneへ戻すべき場面はあります。
ただし、その場合でも、戻す前に更新キー、対象項目、確認者、ログ、戻し方を決めます。
スプレッドシートを業務の中心に置くのではなく、kintoneの正本データを「見せる・集める・確認する」ための補助画面として位置づけます。
スプレッドシート連携は、用途を分けると設計しやすくなります。
同じ「連携」でも、集計と再取込では必要な仕組みがまったく違います。
| 用途 | 例 | 同期方向 | 設計すること |
|---|---|---|---|
| 集計 | 月報、売上表、ピボット | kintoneから片方向 | 取得条件、列定義、更新頻度 |
| 社外共有 | 取引先、委託先、士業との共有 | kintoneから片方向 | 共有項目、閲覧権限、期限 |
| 一時加工 | 修正候補、確認リスト | 原則片方向、必要時だけ戻す | 戻す項目、確認者、差分 |
| 再取込 | 棚卸、外部提出ファイルの回収 | シートからkintone | 更新キー、エラー処理、ログ |
| 自動更新 | 毎日朝の一覧更新、定時集計 | kintoneから片方向 | 実行権限、失敗通知、再実行 |
| 双方向同期 | 外部画面としてシートを使う | 双方向 | 競合、更新責任、権限 |
集計なら、kintoneからスプレッドシートへ出すだけで足ります。
社外共有なら、出してよい列だけを選び、閲覧者と編集者を分けます。
一時加工なら、スプレッドシート上の変更をそのまま正式値にしないようにします。
再取込なら、どの行がどのkintoneレコードに対応するかを更新キーで固定します。
自動更新なら、GASやiPaaSが失敗したときに誰へ通知するかを決めます。
双方向同期なら、同期対象をかなり狭くする必要があります。
この用途分けをせずに、最初から「リアルタイム双方向同期」を目指すと、実装も運用も重くなります。
まずは片方向で済むものを片方向にします。
どうしてもスプレッドシートから戻す項目だけ、別ルールで扱います。
kintoneとスプレッドシートの連携手段は複数あります。
どれが優れているかではなく、用途に合わせて選びます。
| 手段 | 向いている用途 | 注意点 |
|---|---|---|
| CSV出力 | 月次集計、退避、手動共有 | 手作業が残る。列順と文字コードを固定する |
| CSVインポート | 棚卸結果、更新候補の戻し | 更新キー、検証取込、エラー一覧が必要 |
| GAS | 定期取得、簡易な自動更新、通知 | 実行権限、ログ、失敗通知、再実行が必要 |
| プラグイン | ノーコード寄りの連携、定型同期 | 同期範囲、権限、料金、運用条件を確認する |
| iPaaS | 複数サービスをまたぐ同期 | 監視、リトライ、認証管理が必要 |
| 個別API連携 | 重要データの定期同期、複雑な分岐 | 設計、保守、監視を前提にする |
標準機能だけで足りる場合もあります。
kintoneヘルプでは、レコード一覧をファイルに書き出す手順として、出力項目、文字コード、区切り文字などを指定してデータを書き出せることが説明されています。
また、Excel、CSV、TXT、TSVからレコードを登録・上書きするためのファイル記載形式も説明されています。
kintoneヘルプ:レコード登録・上書き用ファイルの記載形式
毎月1回の集計なら、CSV出力で十分なことがあります。
毎朝シートを更新したいなら、GASや連携サービスを検討します。
外部共有先が多く、リアルタイム性が必要なら、プラグインやiPaaSの方が合うこともあります。
Clickのリリースでは、2026年1月9日からkintone・Googleスプレッドシート連携機能が正式版として提供され、Clickとkintoneの双方向同期、ClickからGoogleスプレッドシートへのリアルタイム反映などが説明されています。
Click:kintone・Google スプレッドシート連携機能が正式版としてリリース
こうしたサービスを使う場合も、設計すべきことは変わりません。
どのデータを出すか。
どの項目を戻すか。
誰が編集できるか。
同期が失敗したら誰が気づくか。
同じ行を複数人が変えたらどちらを優先するか。
ここを決めないまま連携すると、ツールは動いていても業務は崩れます。
スプレッドシート連携では、片方向同期を標準にします。
片方向とは、kintoneからスプレッドシートへ出すだけ、またはスプレッドシートからkintoneへ取り込むだけ、という設計です。
多くの用途は片方向で足ります。
| 用途 | 推奨する同期方向 | 理由 |
|---|---|---|
| 月報、集計 | kintoneからシート | 集計結果をkintoneへ戻す必要がない |
| 社外共有 | kintoneからシート | 社外編集で正本を変えない |
| 確認表 | kintoneからシート、必要時だけ戻す | コメントと正式更新を分けられる |
| 棚卸結果 | シートからkintone | 現場入力結果を履歴として取り込む |
| 外部提出ファイル回収 | シートからkintone | 提出値を検証して登録する |
| 外部画面としての利用 | 双方向 | 競合と権限設計が必須 |
双方向同期は、必要な場合だけ使います。
たとえば、外部スタッフがスプレッドシートで作業進捗を更新し、その値をkintoneへ戻したい場合です。
この場合でも、すべての項目を双方向にしません。
戻してよい項目を限定します。
| 項目 | 双方向にしてよいか |
|---|---|
| 作業メモ | 条件付きで可 |
| ステータス候補 | 確認後に可 |
| 担当者 | 権限次第で限定 |
| 金額 | 原則不可、承認前だけ可 |
| 顧客マスタ | 原則不可 |
| 承認状態 | kintone側だけ |
| 請求済み情報 | 原則不可 |
双方向同期は「便利な共有」ではなく、複数の画面から同じレコードを更新する仕組みです。対象項目を絞らなければ、上書き事故の入口になります。
スプレッドシートからkintoneへ戻すなら、更新キーが必要です。
更新キーとは、スプレッドシートの1行がkintoneのどのレコードに対応するかを判断する値です。
| 業務 | 更新キー候補 | 注意点 |
|---|---|---|
| 顧客管理 | 顧客番号 | 空欄、重複、先頭ゼロ |
| 案件管理 | 案件番号 | 採番ルール、削除済み案件 |
| 請求管理 | 請求番号、対象月 | 締め後更新を止める |
| 在庫管理 | 商品コード、倉庫、対象日 | 同日複数更新の扱い |
| 作業報告 | 作業ID、日付、担当者 | 履歴として追加するか更新するか |
更新キーがないまま戻すと、新規登録と既存更新の判定ができません。
同じ行を何度も取り込んで重複する。
別のレコードを上書きする。
削除済みのレコードを復活させる。
こうした事故が起きます。
競合も考えます。
たとえば、朝9時にkintoneからスプレッドシートへ出した後、10時にkintone側で担当者が更新されたとします。
その後、11時にスプレッドシート上の古い担当者を戻すと、kintone側の新しい更新が消えます。
これを避けるには、スプレッドシートに更新日時や更新者を持たせます。
| 競合対策 | 内容 |
|---|---|
| 更新日時を持つ | 出力時点のkintone更新日時をシートに残す |
| 更新者を持つ | 誰が最後に更新したかを確認する |
| 差分を確認する | 取込前に変更項目を一覧で見る |
| 締め状態を持つ | 承認済み、請求済み、締め後は戻せない |
| 戻す項目を限定する | コメント、作業メモなどに絞る |
| エラー行を分ける | 競合した行は登録せず確認に回す |
kintone REST APIを使う場合、レコード取得やレコード更新のAPI仕様を理解しておく必要があります。
Kintone Developer Programでは、レコード取得APIやレコード更新APIのリクエスト、パラメータ、レスポンスが説明されています。
Kintone Developer Program:Get Records
Kintone Developer Program:Update Records
APIを使うかどうかに関係なく、権限は分けます。
| 権限 | 決めること |
|---|---|
| kintone閲覧 | どのアプリ、どのフィールドを出すか |
| kintone更新 | どの項目を更新できるか |
| シート閲覧 | 誰が見られるか |
| シート編集 | 誰がセルを変えられるか |
| スクリプト実行 | 誰の権限でGASが動くか |
| 共有管理 | リンク、外部共有、期限を誰が管理するか |
Google Apps Scriptを使うと、スプレッドシートからkintone REST APIを呼び出したり、定期的にデータを取得したりできます。
GoogleのApps Scriptドキュメントでは、UrlFetchAppを使って外部URLへリクエストを送れることが説明されています。
Google for Developers:UrlFetchApp
また、インストール型トリガーでは、時間主導トリガーやスプレッドシート操作に応じたトリガーを設定できることが説明されています。
Google for Developers:Installable Triggers
GASを使うと、次のような連携を作れます。
毎朝、kintoneから案件一覧を取得してシートを更新する。
シートの入力内容を検証し、kintoneへ登録する。
エラー行を別シートへ出す。
実行結果をSlackやメールへ通知する。
特定の列が更新されたときだけ処理する。
ただし、GASは小さく始めやすい反面、運用設計が抜けやすいです。
| 観点 | 決めること |
|---|---|
| 実行者 | 個人アカウントか、管理用アカウントか |
| 認証情報 | APIトークンや認証情報をどこに置くか |
| トリガー | 時間主導、編集時、手動実行のどれか |
| 二重実行 | 同時実行や連打を防ぐか |
| ログ | 開始時刻、終了時刻、対象件数、結果 |
| 通知 | 失敗時に誰へ知らせるか |
| 再実行 | 全件再実行か、失敗行だけか |
| 保守 | 作成者が退職したときに誰が見られるか |
特に危ないのは、個人のGoogleアカウントで作ったGASが、その人の権限で動き続ける状態です。
作成者の異動、退職、権限変更で止まることがあります。
また、失敗通知がないと、シート上のデータが古いままでも気づけません。
GASを業務で使うなら、最低限、実行ログ、失敗通知、再実行手順を用意します。
スプレッドシート連携で強いのは、共有のしやすさです。
同時に、共有のしやすさはリスクにもなります。
Googleドライブのヘルプでは、ファイル共有時に閲覧者、コメント可の閲覧者、編集者といった権限を管理できることが説明されています。
kintoneからスプレッドシートへ出す場合、共有前に次を決めます。
| 観点 | 決めること |
|---|---|
| 共有目的 | 何を確認してもらうのか |
| 共有相手 | 会社、部署、個人、外部パートナー |
| 共有項目 | 出してよい列、隠す列 |
| 権限 | 閲覧、コメント、編集 |
| 期限 | いつまで見られるか |
| 保存場所 | 個人ドライブか、共有ドライブか |
| コピー | ダウンロードやコピーを許すか |
| 更新方法 | コメントだけか、セル編集も許すか |
社外共有では、kintoneの一覧をそのまま出さない方がよいです。
社内メモ、粗利、担当者メモ、承認コメント、内部ステータスなどが混ざることがあります。
共有用のビューを作るか、共有用のシートに必要項目だけ出します。
また、外部メンバーに編集権限を渡す場合は、編集できる列を制限します。
スプレッドシートの保護範囲だけに頼らず、kintoneへ戻す処理側でも対象列を限定します。
ここでは、よくある3つのパターンで整理します。
月次レポートでは、スプレッドシートを集計ビューとして使います。
| 項目 | 設計 |
|---|---|
| 正本 | kintoneの案件、受注、請求アプリ |
| 同期方向 | kintoneからスプレッドシートへの片方向 |
| 手段 | CSV出力、GAS、プラグイン |
| 更新頻度 | 月次、日次、手動更新 |
| 戻し込み | 原則しない |
| 管理 | テンプレート版、取得条件、更新日 |
この場合、スプレッドシート上のピボットや関数は分析用です。
金額や状態を修正する必要があるなら、kintone側で修正してから再取得します。
社外共有では、出す項目を絞ります。
| 項目 | 設計 |
|---|---|
| 正本 | kintoneの案件アプリ |
| 同期方向 | kintoneからスプレッドシートへの片方向 |
| 共有範囲 | 相手に必要な案件だけ |
| 権限 | 原則閲覧またはコメント |
| 更新 | コメントを確認してkintone側で反映 |
| ログ | 共有先、共有日、解除日を残す |
外部に編集権限を渡す場合は、編集列を限定します。
さらに、スプレッドシートの変更を自動でkintoneへ戻すのではなく、確認者を置く方が安全です。
棚卸や月次補正では、スプレッドシートを再取込元として使います。
| 項目 | 設計 |
|---|---|
| 正本 | kintoneの在庫アプリ、棚卸履歴アプリ |
| 同期方向 | スプレッドシートからkintone |
| 更新キー | 商品コード、倉庫、対象日 |
| 入力制限 | 数値、必須、選択肢 |
| 取込前確認 | 差分、空欄、重複 |
| エラー処理 | 失敗行だけ修正して再実行 |
| 退避 | 更新前CSVを残す |
このパターンでは、スプレッドシートの行をそのまま正本にしないことが重要です。
検証してからkintoneへ登録し、登録後はkintone側の履歴で追えるようにします。
kintoneとスプレッドシート連携でよくある失敗をまとめます。
| 失敗 | 起きること | 対処 |
|---|---|---|
| シートを正本にする | kintoneと値がずれる | kintoneを正式値にする |
| 双方向を広く許す | 上書きや競合が起きる | 対象項目を限定する |
| 更新キーがない | 既存更新と新規登録を判定できない | 番号や対象月を固定する |
| 共有範囲が広い | 社内項目まで外に出る | 共有用ビューや列制御を作る |
| GAS失敗に気づかない | 古いデータを見続ける | ログと失敗通知を入れる |
| 個人アカウントで動く | 異動や退職で止まる | 管理用権限と引き継ぎを決める |
| 列名変更で壊れる | 同期や取込が止まる | 列定義とテンプレート版を管理する |
| 手修正をそのまま戻す | 正式な変更履歴が残らない | 差分確認後に登録する |
特に危ないのは、共有しやすいからという理由で、スプレッドシートを外部画面として扱いすぎることです。
外部メンバーがセルを編集できる状態にするなら、どの列が正式な更新対象か、誰が確認するか、いつkintoneへ戻すかを決めます。
連携を作る前に、次の項目を確認します。
| チェック | 内容 |
|---|---|
| 用途 | 集計、社外共有、一時加工、再取込、自動更新のどれか |
| 正本 | kintone、スプレッドシート、外部システムのどこか |
| 同期方向 | 片方向か、双方向か |
| 対象アプリ | どのkintoneアプリを使うか |
| 対象列 | どのフィールドを出す、戻すか |
| 更新キー | どの値でレコードを特定するか |
| 権限 | 誰が閲覧、編集、実行できるか |
| 共有 | 外部共有の相手、期限、解除方法 |
| ログ | 同期件数、差分、失敗理由を残すか |
| 通知 | 失敗時に誰へ知らせるか |
| 戻し方 | 更新前CSV、バックアップ、再実行手順があるか |
| 保守 | GASや連携設定を誰が管理するか |
このチェックが埋まれば、連携手段は選びやすくなります。
月次集計だけならCSV出力で足りるかもしれません。
毎朝の更新ならGASでよいかもしれません。
社外共有や双方向同期を安定させたいなら、プラグインやiPaaSを検討する価値があります。
重要なのは、手段を先に決めないことです。
Bitlightでは、kintoneとスプレッドシート連携を、単なる自動同期ではなく、正本データと共有範囲の設計として支援できます。
たとえば、次のような整理ができます。
kintoneを正本にするアプリとフィールドを決める。
スプレッドシートを集計、共有、一時加工、再取込のどれに使うか分ける。
CSV、GAS、プラグイン、iPaaSの使い分けを決める。
スプレッドシートから戻す項目、更新キー、確認者を設計する。
GASの実行権限、ログ、失敗通知、再実行手順を整える。
外部共有用の列、権限、共有期限、解除ルールを作る。
更新前CSVやバックアップを含めて、失敗時の戻し方を決める。
スプレッドシートは、kintoneの代わりに正本を持つ場所ではありません。
ただし、集計、共有、確認、外部提出のための画面としては非常に使いやすい道具です。
役割を分ければ、kintoneを業務データの中心に置いたまま、スプレッドシートの使いやすさを現場に残せます。
千葉県出身。10歳の頃からプログラミングを始め、ゲーム、Webサイト、ロボット、スマホアプリなどを制作。大阪大学基礎工学部情報科学科で情報工学と統計学を学び、大学時代はAIを研究。大学在学中にWeb広告代理店でのインターンや人材系Webサービスの立ち上げを経験し、卒業後はフリーランスエンジニアとしてGISシステム、データ基盤構築、Webシステムの開発に従事。10年以上のWebアプリ開発・データ分析経験を基に、2023年9月に株式会社ビットライトを設立し、現場業務の仕組み化からデータ基盤構築、データ活用支援までを一気通貫で支援。