Notionとkintoneの連携設計｜申請・承認と案件情報の二重入力を減らす

Notionとkintoneは、APIや外部の自動化サービスで連携できます。たとえば、kintoneで承認された案件の情報をNotionへ反映し、営業や制作担当者が関連資料と一緒に確認する構成です。

二重入力を減らすには、同じレコードを丸ごと複製するより、どちらで確定した情報を、どのタイミングで相手へ渡すかを決めます。この記事では、申請・承認と案件管理を題材に、項目、権限、変更時の扱いを設計例として説明します。

Notionとkintoneの役割を先に分ける

両方に案件名や金額があっても、その情報を変更する責任まで二つに増やす必要はありません。

情報	正本として管理する場所の例	相手に渡すもの
申請金額・申請者・承認状態	kintone	確定値と元レコードのリンク
案件の背景・議事録・制作メモ	Notion	案件ページのURL
顧客コード・案件コード	既存の顧客・案件マスタ	照合に使う固定ID
連携の成否	連携基盤の実行記録	最終反映日時と要確認の理由

たとえば、Notionの自由記述にある「先方と概ね合意」というメモを、kintoneの「承認済み」へ自動変換してはいけません。業務メモと正式な承認状態は、意味が違います。

既存ツールとAPIのどちらを使うか

新規レコードの追加や単純な項目の転記なら、既存の自動化サービスで対応できる場合があります。承認に応じた更新、複数の明細、独自の項目変換が必要なら、対応する操作を確認してから選びます。

方法	選びやすい条件	確認したい点
ノーコードの連携サービス	対応する項目と操作で業務を表せる	更新条件、利用回数、再試行、失敗通知
kintoneのカスタマイズ	利用者の操作に合わせて連携したい	利用者の権限と認証情報の扱い
外部のAPIプログラム	定期処理や複雑な変換が必要	実行場所、排他制御、監視、保守担当

Cybozuの公式開発者サイトには、Notionの情報をkintoneへ同期し、NotionのIDを更新キーに使う実装例があります。IDによる追加・更新の切り分けは、既に使える基本的な考え方です。

Cybozu公式：Notionとkintoneを連携するJavaScriptカスタマイズ例

その例を自社へ適用する際は、サンプルの同期対象と、自社で承認する対象が同じかを確認します。ブラウザーで動くカスタマイズと、外部で動く定期プログラムでは、権限や秘密情報の持ち方も変わります。

項目対応表には更新者と変更条件も書く

項目名の対応だけでなく、どちらが更新してよいかまで整理しましょう。次の表は、kintoneで承認した案件をNotionへ反映する例です。

項目	対応の例	更新ルール
案件コード	kintoneの案件コード→Notionの外部案件ID	一度割り当てた値を名前変更で変えない
承認金額	kintoneの確定値→Notionの参照用金額	Notionで自由に上書きする運用にしない
承認状態	kintoneの正式状態→Notionの表示	説明文から推測しない
案件の背景	Notionのページ本文	原則としてNotionで編集する
相互参照	kintoneレコードURLとNotionページURL	別案件へ誤って付け替えない
最終反映日時	連携が成功した時点	実行を開始した日時とは分ける

添付ファイルやkintoneのテーブルは、文字列や数値の項目とは別に確認します。ファイル本体をコピーするか、元の保管先へリンクするか、明細を別レコードにするかで実装と運用が変わります。

複数アプリに同じ顧客が存在する場合も、名称だけでは照合しません。会社名の表記揺れや同名企業があるため、既存マスタのコードと、各サービスのレコードIDの対応を持ちます。

承認後の変更・取消を例に流れを決める

架空の例として、kintoneで30万円の申請を承認し、Notionに案件ページを作った後、追加作業で35万円へ変わったケースを考えます。

1. 変更申請が承認される前は、Notionの確定金額を35万円に更新しない。
2. 新しい申請版が承認されたら、変更理由と新しい確定値を反映する。
3. Notion独自の制作メモや議事録は残す。
4. 関係者には「案件が更新された」だけでなく、金額・範囲の変更を確認できる通知を出す。

承認状態を変える操作は、通常の項目更新と同じ扱いにしません。kintoneのプロセス管理を使う場合は、実際のステータス遷移と実行者の権限を確認します。

Cybozu公式：レコードのステータスを更新するAPI

取消時も、連携先ページを即座に消す必要があるとは限りません。「取消」と理由を残し、進行中のタスクを誰が止めるかまで決める方が、対応漏れを見つけやすくなります。

接続設定とプログラムの実行場所

Notion側は、必要なページやデータソースに接続のアクセスを付与します。kintone側も、対象アプリと操作に必要な権限を設定します。接続できたことと、対象の承認・更新を行ってよいことは別です。

自作するなら、外部のクラウド関数や自社のジョブ基盤でプログラムを動かします。そこでNotionとkintoneを読み、項目を変換して更新し、結果を記録します。APIトークンなどを公開されるコードや案件メモへ貼らないようにしましょう。

Notionに結果を書けなかった場合も、kintone側の更新が失敗したとは限りません。案件コードと実行IDを記録し、作成済みのレコードを照合してから再処理します。

Notionインテグレーションの接続・権限・トークン管理

導入前に試したい6つのケース

確認するケース	期待する動き
通常の承認済み案件	正しい案件ページへ必要項目だけ反映する
同じ通知をもう一度処理	同じ案件が重複作成されない
承認前の金額変更	確定値へ勝手に反映されない
取消・差戻し	制作担当に状態と次の対応が伝わる
明細・添付・顧客IDの不足	誤った値で進まず、確認すべき内容が分かる
途中で通信が失敗	処理済み箇所を照合し、必要な部分だけ復旧する

最初は一つのアプリ・一つの案件種別から試し、転記と確認を含む作業時間を比較します。業務の例外が少ないうちは既存サービスを使い、必要な条件が表せなくなった段階で個別実装を検討しても遅くありません。

AIは案件の要約に使い、承認判断は分ける

AIで申請理由や関連議事録を短く整理すると、確認者が原文を読む前の準備を減らせます。ただし、要約に書かれた「承認」「確定」を、そのままシステムの正式状態として採用しません。

Notionには、AIの要約案と確認済みの案件情報を別項目で持たせます。営業担当には案件の経緯を、制作担当には確定した範囲を見せるなど、利用者の仕事に合わせて整えましょう。

ビットライトでは、申請と案件情報の分担、既存ツールで対応できる範囲、変更・取消時の運用まで含めて連携を相談できます。検討時には、今の入力項目と、同じ内容を転記している場面を持ち寄ると整理が進みます。

Notion AIの業務連携・費用・権限をまとめた資料を請求する

仕様確認：2026年10月21日。本文の項目表と運用は設計例です。利用プラン・対応API・権限は導入時の公式資料で確認してください。

Notionの業務連携について相談する