kintone業務設計研究所 > kintoneとスプレッドシート連携の設計方法|集計・共有・同期を分ける構成

kintoneとスプレッドシート連携の設計方法|集計・共有・同期を分ける構成

2026年6月12日

19分で読めます

kintoneとGoogleスプレッドシートを連携するときに、集計、社外共有、一時加工、再取込、自動更新の用途を分け、CSV、GAS、プラグイン、iPaaS、同期方向、権限、ログをどう設計するか整理します。

kintone
Googleスプレッドシート
GAS
CSV
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アプリ、Googleスプレッドシート、GAS、プラグイン、iPaaS、片方向同期、双方向同期、集計、共有、再取込の関係を示すkintoneスプレッドシート連携設計図

スプレッドシートは正本にしない前提から考える

スプレッドシート連携では、まず正本を決めます。

多くの業務では、正本はkintone側に置いた方が安全です。

正本とは、業務上の正式な値として扱う場所です。

案件状態、請求金額、顧客情報、在庫数、承認状態、対応履歴などは、kintone側のアプリで管理します。

スプレッドシートは、そのデータを見たり、集計したり、一時的に確認したりする道具として使います。

データ 正本にする場所 スプレッドシート側の役割
顧客名、住所、担当者 顧客マスタ 参照、外部共有用の一部表示
案件名、状態、金額 案件アプリ 月報、確認表、分析
請求日、請求番号 請求アプリ 経理確認、提出用一覧
在庫数、入出庫履歴 在庫アプリ 集計、棚卸前の確認
承認状態 kintoneプロセス管理 参照のみ
社外コメント コメント用シートまたは別アプリ 戻す場合は確認後に登録

スプレッドシートを正本にすると、次の問題が出やすくなります。

誰がどのセルを変えたか、業務レコード単位で追いにくい。

行の追加、削除、並び替えで、kintoneのレコードとの対応が崩れやすい。

関数や手入力が混ざり、正式値と計算値の境界が曖昧になる。

共有先が増え、閲覧範囲や編集範囲の管理が難しくなる。

同じスプレッドシートのコピーが増え、どれが最新版か分からなくなる。

もちろん、スプレッドシートをまったく更新元にしない、という意味ではありません。

更新候補を集めるシート、外部提出ファイル、棚卸結果、月次補正など、スプレッドシートからkintoneへ戻すべき場面はあります。

ただし、その場合でも、戻す前に更新キー、対象項目、確認者、ログ、戻し方を決めます。

スプレッドシートを業務の中心に置くのではなく、kintoneの正本データを「見せる・集める・確認する」ための補助画面として位置づけます。

kintoneデータベース設計はこちら

集計・共有・一時加工・再取込の用途を分ける

スプレッドシート連携は、用途を分けると設計しやすくなります。

同じ「連携」でも、集計と再取込では必要な仕組みがまったく違います。

用途 同期方向 設計すること
集計 月報、売上表、ピボット kintoneから片方向 取得条件、列定義、更新頻度
社外共有 取引先、委託先、士業との共有 kintoneから片方向 共有項目、閲覧権限、期限
一時加工 修正候補、確認リスト 原則片方向、必要時だけ戻す 戻す項目、確認者、差分
再取込 棚卸、外部提出ファイルの回収 シートからkintone 更新キー、エラー処理、ログ
自動更新 毎日朝の一覧更新、定時集計 kintoneから片方向 実行権限、失敗通知、再実行
双方向同期 外部画面としてシートを使う 双方向 競合、更新責任、権限

集計なら、kintoneからスプレッドシートへ出すだけで足ります。

社外共有なら、出してよい列だけを選び、閲覧者と編集者を分けます。

一時加工なら、スプレッドシート上の変更をそのまま正式値にしないようにします。

再取込なら、どの行がどのkintoneレコードに対応するかを更新キーで固定します。

自動更新なら、GASやiPaaSが失敗したときに誰へ通知するかを決めます。

双方向同期なら、同期対象をかなり狭くする必要があります。

この用途分けをせずに、最初から「リアルタイム双方向同期」を目指すと、実装も運用も重くなります。

まずは片方向で済むものを片方向にします。

どうしてもスプレッドシートから戻す項目だけ、別ルールで扱います。

CSV出力・プラグイン・GAS・iPaaSの違い

kintoneとスプレッドシートの連携手段は複数あります。

どれが優れているかではなく、用途に合わせて選びます。

手段 向いている用途 注意点
CSV出力 月次集計、退避、手動共有 手作業が残る。列順と文字コードを固定する
CSVインポート 棚卸結果、更新候補の戻し 更新キー、検証取込、エラー一覧が必要
GAS 定期取得、簡易な自動更新、通知 実行権限、ログ、失敗通知、再実行が必要
プラグイン ノーコード寄りの連携、定型同期 同期範囲、権限、料金、運用条件を確認する
iPaaS 複数サービスをまたぐ同期 監視、リトライ、認証管理が必要
個別API連携 重要データの定期同期、複雑な分岐 設計、保守、監視を前提にする

標準機能だけで足りる場合もあります。

kintoneヘルプでは、レコード一覧をファイルに書き出す手順として、出力項目、文字コード、区切り文字などを指定してデータを書き出せることが説明されています。

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 Excel連携の設計方法はこちら

更新キー・競合・権限の設計

スプレッドシートから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が動くか
共有管理 リンク、外部共有、期限を誰が管理するか

kintone API制限の設計方法はこちら

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ドライブのヘルプでは、ファイル共有時に閲覧者、コメント可の閲覧者、編集者といった権限を管理できることが説明されています。

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に相談できること

Bitlightでは、kintoneとスプレッドシート連携を、単なる自動同期ではなく、正本データと共有範囲の設計として支援できます。

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

kintoneを正本にするアプリとフィールドを決める。

スプレッドシートを集計、共有、一時加工、再取込のどれに使うか分ける。

CSV、GAS、プラグイン、iPaaSの使い分けを決める。

スプレッドシートから戻す項目、更新キー、確認者を設計する。

GASの実行権限、ログ、失敗通知、再実行手順を整える。

外部共有用の列、権限、共有期限、解除ルールを作る。

更新前CSVやバックアップを含めて、失敗時の戻し方を決める。

スプレッドシートは、kintoneの代わりに正本を持つ場所ではありません。

ただし、集計、共有、確認、外部提出のための画面としては非常に使いやすい道具です。

役割を分ければ、kintoneを業務データの中心に置いたまま、スプレッドシートの使いやすさを現場に残せます。

kintone業務アプリ設計支援

kintone スプレッドシート連携を、権限・競合・失敗通知まで設計します

CSV、GAS、プラグイン、iPaaSを使い分け、社外共有、月次集計、再取込、定期同期まで運用に落とし込みます。

著者
守高 成悟
守高 成悟

代表取締役 CEO

千葉県出身。10歳の頃からプログラミングを始め、ゲーム、Webサイト、ロボット、スマホアプリなどを制作。大阪大学基礎工学部情報科学科で情報工学と統計学を学び、大学時代はAIを研究。大学在学中にWeb広告代理店でのインターンや人材系Webサービスの立ち上げを経験し、卒業後はフリーランスエンジニアとしてGISシステム、データ基盤構築、Webシステムの開発に従事。10年以上のWebアプリ開発・データ分析経験を基に、2023年9月に株式会社ビットライトを設立し、現場業務の仕組み化からデータ基盤構築、データ活用支援までを一気通貫で支援。

運営会社
株式会社ビットライト
株式会社ビットライト

顧客が本当に必要だった価値を、実装する。

現場業務の仕組み化からデータ基盤構築、データ活用支援までを一気通貫で支援しています。

コーポレートサイトを見る
kintone設計相談

アプリ構成・権限・連携範囲を相談できます

Excelからの移行、既存kintoneの見直し、外部サービス連携まで、業務に合わせた設計範囲を整理します。