kintone Excel連携の設計方法｜現場Excelと正本データを分ける構成

kintoneとExcelを連携したい、という相談は多いです。

現場が使い慣れたExcel入力画面を残したい。

見積書や請求書は、既存のExcel様式を使い続けたい。

月報やピボット分析はExcelで見たい。

kintoneの一覧をExcelへ出して、上長確認後に戻したい。

外部から届くExcelを、毎月kintoneへ取り込みたい。

部署ごとのExcel台帳を、kintoneの共通データベースにつなぎたい。

Excelを完全になくす必要はありません。

むしろ、帳票、分析、入力補助、一時加工の道具としてExcelを残した方が、現場に合うこともあります。

問題は、Excelを残すことではありません。

問題は、Excelとkintoneの両方で同じ項目を更新できる状態にしてしまい、どちらが正式な値なのか分からなくなることです。

よくある失敗は、次のような状態です。

kintoneの案件金額を直した後、古いExcelから再取込されて上書きされる。

Excelで担当者を変更したが、kintone側の通知やプロセス管理には反映されない。

帳票Excelだけ手修正され、kintoneの請求金額とずれる。

Power Queryで取得したExcelを誰かが加工し、その加工済みファイルが正式版として回り始める。

CSV出力したファイルを別部署が修正し、更新キーなしでkintoneへ戻そうとする。

Excelアドインで登録・更新できる範囲が広すぎて、更新責任が曖昧になる。

エラー時に、どのレコードを戻せばよいか分からない。

kintone Excel連携で最初に決めるべきなのは、連携ツールではなく、「kintoneを正本にするデータ」と「Excelに残す役割」です。

この記事では、kintoneとExcelを連携するときに、Excelを入力画面、帳票、分析、一時加工のどれとして残すか、kintone側で正本にするデータ、CSV、Excelアドイン、Power Query、帳票出力の使い分け、双方向同期の競合、更新権限、ログ、エラー時の再取込まで整理します。

kintone Excel取り込みの設計方法はこちら
kintoneエクセル出力の設計方法はこちら
kintone CSVインポートの設計方法はこちら

Excelをなくす前に役割を分ける

kintone導入時に「Excelをやめるか、残すか」と考えると、判断が粗くなります。

Excelは1つの役割だけを持っているわけではありません。

同じExcelでも、現場では次のように使われています。

Excelの役割	例	kintone連携で決めること
入力画面	見積入力、点検表、勤務表	入力結果をどのアプリへ登録するか
帳票	見積書、請求書、報告書	kintoneのどの状態を出力対象にするか
分析	月報、売上集計、ピボット	kintoneから片方向で参照するか
一時加工	確認リスト、補正前データ	kintoneへ戻すか、戻さないか
外部受領	取引先フォーマット、部門提出ファイル	更新キーと取込ルールをどう固定するか
移行補助	旧台帳、差分確認表	初回だけ使うか、定期運用にするか

この分類をせずに「Excel連携」とまとめると、必要以上に複雑になります。

帳票として残すだけなら、kintoneからExcelへ片方向で出す設計にできます。

分析だけなら、Power Queryでkintoneを参照する形が合うことがあります。

外部から届くExcelを取り込むなら、CSV化、項目マッピング、更新キー、検証取込が重要です。

現場入力画面としてExcelを残すなら、Excelからkintoneへ登録・更新する項目を絞る必要があります。

Excelを残すかどうかではなく、Excelを「入力」「帳票」「分析」「一時加工」のどれとして残すかを決めると、連携手段を選びやすくなります。

kintoneを正本にするデータ

Excel連携で崩れないためには、kintone側で正本にするデータを決めます。

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

たとえば、案件金額の正式値はkintoneに置く。

帳票Excelの金額は、kintoneの値から出力する。

Excel側で試算した金額は、承認前の一時値として扱う。

このように決めておくと、手修正や再取込で迷いにくくなります。

データ	正本にする場所	Excel側の扱い
顧客番号、顧客名、住所	顧客マスタ	参照、取込前確認
案件番号、案件名、状態	案件アプリ	入力補助、確認表
見積金額、請求金額	kintoneまたは会計システム	帳票表示、試算
商品コード、単価	商品マスタ	選択肢、計算補助
対応履歴、作業履歴	履歴アプリ	一時記入、取込元
承認状態、差戻し理由	kintoneプロセス管理	参照のみ
提出済み帳票	kintone添付または保管先	出力ファイル

kintoneを正本にする項目は、次のように設計します。

観点	決めること
更新キー	顧客番号、案件番号、請求番号など
入力者	誰が登録・更新できるか
更新方法	kintone画面、CSV、Excelアドイン、API
更新タイミング	随時、月次、承認後、締め後
変更履歴	どの項目をログとして残すか
戻し方	更新前CSV、バックアップ、再取込手順

正本データを決めないまま双方向にすると、現場は便利に見えます。

しかし、数か月後に「どのExcelが正しいのか」「kintoneの値はいつ更新されたのか」「上書きしてよいのか」が分からなくなります。

kintoneデータベース設計はこちら
kintoneバックアップ設計はこちら

Excelを入力画面として残すケース

Excelを入力画面として残すべき場面はあります。

たとえば、次のようなケースです。

既存のExcel入力フォームに複雑な計算や入力補助がある。

現場がkintone画面よりExcelフォームに慣れている。

社外から決まったExcel様式で提出される。

1件の入力に多数の明細や確認欄があり、kintone画面だけでは入力しづらい。

オフラインに近い環境で一時的にExcelへ記入し、後で取り込む。

この場合、Excelを残しても構いません。

ただし、Excelを自由編集ファイルとして残すのではなく、kintoneへ渡す入力画面として設計します。

設計項目	決めること
入力対象	どのアプリ、どのフィールドへ入れるか
更新対象	新規登録だけか、既存更新も許すか
更新キー	顧客番号、案件番号、レコード番号など
入力制限	選択肢、日付、数値、必須項目
計算	Excel側の試算か、kintone側の正式計算か
添付	Excel内のファイルをどう扱うか
実行者	誰が登録・更新ボタンを押せるか
ログ	ファイル名、実行者、件数、結果

サイボウズの連携サービス掲載ページでは、NCSサポート＆サービスのExcel連携アドインが、利用中のExcelとkintoneデータベースをつなぎ、データの検索・登録・更新を行う連携プログラムを作れるツールとして紹介されています。

また、Excelの自由な入力画面や独自帳票フォームを使いながらkintoneとデータ連携できること、添付ファイルのアップロードやダウンロードにも触れています。

サイボウズ：Excel連携アドイン

NCSサポート＆サービスの製品ページでも、Excelシートとkintoneの対応を設定し、データの取得、登録、更新を行えることが説明されています。

NCSサポート＆サービス：Excel連携ソリューション

こうしたアドインは便利です。

ただし、業務設計なしで導入すると、Excelから何でも更新できる状態になりがちです。

Excel入力画面を残すなら、まず更新してよい項目を絞ります。

項目	Excelから更新してよいか
下書きの数量、メモ	更新可にしやすい
顧客名、住所	顧客マスタ担当だけに限定
見積金額	承認前だけ更新可
承認状態	kintone側だけで更新
請求済み金額	原則としてExcelから戻さない
締め後データ	更新不可、差戻し申請にする

Excelを入力画面として残すときは、kintoneの画面を捨てるのではありません。

kintoneは正本、権限、履歴、検索、状態管理を担い、Excelは入力しやすい表面だけを担う、と役割を分けます。

Excelを帳票・分析として使うケース

Excelを帳票や分析として使う場合は、基本的にkintoneからExcelへの片方向を標準にします。

帳票では、kintoneの正式データをExcelテンプレートへ差し込みます。

分析では、kintoneのレコードをExcelから参照します。

この2つは、似ているようで設計が違います。

Excelの使い方	主な目的	戻し込みの有無
帳票	見積書、請求書、報告書を作る	原則戻さない
分析	月報、ピボット、管理表を見る	原則戻さない
確認表	修正候補を一覧で見る	必要なら更新キー付きで戻す
提出用ファイル	取引先や監査へ出す	戻さない

帳票Excelを手で直して、そのまま提出する運用は避けます。

金額、品目、宛先、日付を直す必要があるなら、kintone側のレコードを直して再出力します。

どうしてもExcel上で差し替える場合は、手修正版として保存し、kintoneの正式値とは別扱いにします。

kintone帳票出力の設計方法はこちら
kintoneエクセル出力の設計方法はこちら

分析では、Power Queryを使ってExcelからkintoneのデータを取得する方法もあります。

Kintone Developer Programでは、Microsoft ExcelのPower Queryからkintoneアプリのレコードを取得する手順が紹介されています。

APIトークン、アプリID、フィールドコードを使い、Excel側でkintoneデータを読み込む例です。

Kintone Developer Program：Export Records to Excel using Power Query

Power Queryを使う場合は、次を決めます。

観点	決めること
取得対象	どのアプリ、どのフィールドを読むか
更新頻度	手動更新か、定期更新か
認証	APIトークン、権限、管理者
ファイル配布	個人PCに置くか、共有場所に置くか
加工範囲	Excel内で足す列、ピボット、グラフ
正式値	Excelの集計結果を業務判断に使う範囲

分析用Excelは便利ですが、配布後にコピーが増えやすいです。

古いPower Queryファイルが残り、列定義が古いまま使われることもあります。

月次資料として使うなら、テンプレート版、更新日、取得条件、保管先を決めておきます。

CSV・アドイン・Power Query・帳票プラグインの使い分け

kintoneとExcelの連携手段は、1つに決めるものではありません。

用途ごとに使い分けます。

手段	向いている用途	注意点
CSV出力	一覧、退避、外部連携、再取込前の確認	列順、文字コード、先頭ゼロを固定する
CSVインポート	初回移行、定期取込、一括更新	更新キー、検証取込、エラー処理が必要
Excelアドイン	Excel画面から検索・登録・更新	更新対象と権限を狭く設計する
Power Query	Excelからkintoneを参照して集計	認証、列定義、テンプレート版を管理する
帳票出力プラグイン	Excel様式の見積書、請求書、報告書	出力条件、再発行、保存先を決める
API連携	定期同期、外部システム接続	ログ、再実行、API制限を設計する

標準機能のCSV出力・読み込みだけで足りる業務も多いです。

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

kintoneヘルプ：ファイルにデータを書き出す

また、レコード登録・上書き用ファイルの記載形式では、Excel、CSV、TXT、TSVからの読み込みや、フィールドタイプごとの記載方法が説明されています。

kintoneヘルプ：レコード登録・上書き用のファイルの記載形式

連携手段を選ぶときは、次の順で考えると整理しやすいです。

1. Excelは入力、帳票、分析、一時加工のどれか。
2. kintoneへ戻す必要があるか。
3. 戻すなら、新規登録か既存更新か。
4. 更新キーは何か。
5. 失敗したときに、どこからやり直すか。
6. 誰が実行できるか。
7. 実行結果をどこに残すか。

Excel連携の手段は、先に選ばない方がよいです。先に決めるのは、Excelからkintoneへ戻すかどうか、戻すなら何を誰の責任で更新するかです。

kintone CSV出力の設計方法はこちら
kintone CSVインポートの設計方法はこちら

双方向同期の競合と更新責任

Excel連携で最も注意が必要なのは、双方向同期です。

双方向同期そのものが悪いわけではありません。

ただし、同じ項目をkintone画面とExcelの両方から更新できる場合、競合が起きます。

たとえば、次のような場面です。

営業担当がkintoneで見積金額を修正した。

同じ日に事務担当が古いExcelを開き、見積金額を修正して登録した。

どちらも操作としては正しい。

しかし、最後に更新した方だけが残ると、業務上の正しさとは別の結果になります。

双方向同期を使うなら、項目ごとに更新責任を分けます。

項目	更新責任	連携ルール
顧客名、住所	顧客マスタ担当	Excelからは原則更新しない
見積明細	営業担当	承認前だけExcel更新可
承認状態	kintoneプロセス	Excelから更新しない
請求日、請求番号	経理担当	締め後は更新不可
社内メモ	担当者	Excelから戻すなら履歴へ入れる
集計用コメント	管理部門	Excel内だけに残すかを決める

競合対策として、次のようなルールを入れます。

ルール	内容
更新日時を見る	Excel取得後にkintone側が更新されていたら止める
更新者を見る	自分以外が更新していたら確認に回す
更新対象を限定する	Excelから戻せるフィールドを絞る
締め状態を持つ	承認後、請求済み、締め後は戻せない
差分一覧を出す	登録前に変更内容を確認する
エラーを別表に出す	失敗行だけ直して再実行する
実行ログを残す	誰が、いつ、何件、どのファイルで更新したか残す

kintone側のアクセス権も見直します。

Excel連携だけで強い権限を持たせると、kintone画面では更新できない項目をExcelから更新できてしまうことがあります。

APIトークンやアドインの認証で更新する場合も、必要なアプリと項目に絞ります。

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

エラー時の再取込・戻し方

Excel連携は、成功したときより失敗したときの設計が重要です。

次のような失敗は必ず起きます。

顧客番号が空欄だった。

同じ更新キーが2行あった。

日付形式が部署ごとに違った。

数値にカンマや単位が混ざっていた。

先頭ゼロが消えていた。

選択肢にない値が入っていた。

Excel取得後にkintone側のレコードが更新されていた。

ファイルを間違えて古い版で実行した。

エラー時の設計では、次の流れを用意します。

手順	内容
1. 更新前に退避	対象レコードをCSV出力して残す
2. 検証取込	少数件または検証アプリで試す
3. 実行ログ	ファイル名、実行者、件数、対象期間を残す
4. エラー一覧	行番号、項目、理由、修正担当を残す
5. 失敗行だけ再実行	全件やり直しではなく対象を絞る
6. 戻し方	更新前CSV、バックアップ、手戻し手順を決める

たとえば、月次のExcel取込なら、実行前にkintoneから対象月のCSVを出力しておきます。

そのうえで、取り込みファイル、整形後ファイル、エラー一覧、実行ログを同じ単位で保管します。

こうしておくと、失敗時に「どのExcelを使ったか」「何件成功したか」「どこまで戻すか」を追えます。

kintoneバックアップ設計はこちら

連携パターン別の設計例

ここでは、よくある3つのパターンで考えます。

既存の見積Excelを残す

見積Excelを残す場合、Excelは入力画面と帳票の両方を持ちがちです。

この場合は、入力用と出力用を分けます。

項目	設計
正本	kintoneの見積アプリ、顧客マスタ、商品マスタ
Excel入力	承認前の明細、数量、備考だけ更新可
Excel帳票	承認済み見積を出力する
戻し込み	承認後は不可
ログ	見積番号、版、出力者、更新者を残す

既存のExcelを1枚で使い続ける場合でも、入力用のシートと提出用の帳票シートを分けた方が安全です。

月報をExcelで見たい

月報や売上集計では、Excelを分析として使います。

この場合は、kintoneからExcelへ片方向にします。

項目	設計
正本	kintoneの案件、受注、請求データ
Excel	Power QueryやCSVで取得して集計
更新	Excelからkintoneへ戻さない
テンプレート	月報ファイルの版を管理する
権限	取得できるフィールドを限定する

Excel上のピボットやコメントは、分析資料として扱います。

正式な案件状態や金額を変える場合は、kintone側で更新します。

外部から届くExcelを毎月取り込む

取引先や部署から届くExcelを毎月取り込む場合、Excelは外部受領ファイルです。

この場合は、入力ルールと再取込ルールが重要です。

項目	設計
正本	kintoneの取引アプリまたは履歴アプリ
更新キー	取引先コード、対象月、明細番号など
整形	列名、日付、数値、選択肢を固定する
検証	本番取込前にチェックする
エラー	取引先へ返す修正表を用意する
保管	受領ファイル、整形後ファイル、取込ログ

このパターンでは、Excelファイルの様式が少し変わるだけで取込が止まります。

相手に渡すテンプレート、必須列、入力例、戻し方を先に決めます。

よくある失敗

kintone Excel連携でよくある失敗をまとめます。

失敗	起きること	対処
Excelを正本にし続ける	kintoneが検索用コピーになる	正式データをkintoneへ寄せる
双方向を広く許す	上書きや競合が起きる	項目ごとに更新責任を分ける
帳票Excelを手修正する	kintoneと提出版がずれる	kintoneを直して再出力する
更新キーがない	同じレコードを特定できない	顧客番号、案件番号などを固定する
古いExcelを使う	旧列、旧計算式で登録される	テンプレート版を管理する
エラー行を全件再取込する	正しい行まで重複更新する	失敗行だけ再実行する
実行ログがない	誰が何を更新したか分からない	ファイル名、件数、結果を残す
権限が広すぎる	Excel経由で重要項目が変わる	アプリ、項目、実行者を絞る

特に危ないのは、「一度Excelへ出して、人が直して、またkintoneへ戻す」運用です。

これは確認作業として便利に見えます。

しかし、戻す項目、更新キー、競合検知、実行ログがないと、手作業の上書き装置になります。

確認表としてExcelを出すなら、戻す項目を限定し、更新前に差分を見せる設計にします。

実装前チェックリスト

Excel連携を作る前に、次の項目を確認します。

チェック	内容
Excelの役割	入力、帳票、分析、一時加工、外部受領のどれか
正本データ	kintone、Excel、外部システムのどこか
更新方向	片方向か、双方向か
更新対象	どのアプリ、どのフィールドか
更新キー	新規登録と既存更新をどう判定するか
権限	誰が出力、登録、更新できるか
競合	取得後にkintone側が変わったらどうするか
ログ	実行者、ファイル名、件数、結果を残すか
エラー	失敗行、理由、再実行手順があるか
戻し方	更新前CSVやバックアップがあるか
テンプレート	Excel様式、列、関数の版を管理するか

このチェックが曖昧なままツールを入れると、短期的には便利でも、運用で崩れます。

逆に、このチェックを先に済ませれば、標準CSVで足りるのか、Excelアドインが必要なのか、Power Queryでよいのか、帳票プラグインを使うべきかを判断しやすくなります。

Bitlightに相談できること

Bitlightでは、kintoneとExcel連携を、単なるツール導入ではなく業務データの責任分界として設計できます。

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

Excel台帳を、顧客マスタ、案件、請求、履歴へ分ける。

Excelを入力画面として残す範囲を決める。

kintoneを正本にする項目と、Excelに残す計算・書式を分ける。

CSV入出力、Excelアドイン、Power Query、帳票出力の使い分けを決める。

双方向同期が必要な項目だけ、競合検知と更新権限を設計する。

月次取込、外部提出、帳票再発行、更新ログ、戻し方まで運用に落とす。

kintoneとExcelは、対立する道具ではありません。

役割を分ければ、Excelは現場に馴染んだ入力・帳票・分析の道具として残せます。

そのうえで、kintoneを正本データ、権限、履歴、状態管理の中心に置くと、属人的なExcel運用から業務アプリへ移しやすくなります。