kintoneとBox連携の設計方法｜添付ファイルと業務データを分ける

kintoneで案件、契約、工事、申請、顧客対応を管理していると、添付ファイルが増えます。

見積書、契約書、図面、写真、検収書、請求書、議事録、メール添付、承認資料。

最初はkintoneの添付ファイルフィールドで足ります。

しかし、運用が長くなると次の問題が出ます。

• 添付ファイルが大きくなり、kintoneのディスク使用量が増える
• 同じ資料が複数レコードに添付され、最新版が分からなくなる
• ファイル名がばらばらで、後から探せない
• Boxにもkintoneにも同じファイルがあり、どちらが原本か分からない
• kintoneレコードを削除したとき、Boxフォルダを残すのか消すのか決めていない
• kintoneの閲覧権限とBoxの共有権限がずれる
• 共有リンクが外部に開きすぎる
• 保管期限、版管理、監査ログの扱いがアプリごとに違う
• ファイルはBoxにあるが、業務ステータスや担当者がkintoneに戻っていない

kintoneとBox連携は、単にファイル置き場を移す話ではありません。

業務レコードと文書原本をどう結びつけるかの設計です。

kintoneには、案件番号、顧客、担当者、ステータス、期限、承認状態、文書種別、保管期限、BoxフォルダURL、送受信履歴を持たせます。

Boxには、原本ファイル、版、プレビュー、共有リンク、フォルダ権限、保持ポリシー、ダウンロード制御を持たせます。

この分担が曖昧なまま連携すると、容量は逃がせても、文書管理としては崩れます。

kintoneとBox連携で最初に決めるべきなのは、Boxへファイルを置く方法ではなく、kintoneに残す業務データとBoxに置く文書原本の責任分界です。

この記事では、kintoneとBox連携を、添付ファイル対策ではなく、業務データと文書管理をつなぐ設計として整理します。

kintone添付ファイル設計はこちら
kintoneファイル管理の設計方法はこちら
kintone外部連携の設計方法はこちら
kintoneセキュリティ設計はこちら

添付ファイルをkintoneに置き続ける限界

kintoneの添付ファイルフィールドは便利です。

レコードに資料を直接添付でき、一覧や詳細画面から確認できます。

小さな画像、申請書、PDF、作業報告の証跡を持つだけなら、標準機能で十分な場面もあります。

ただし、文書量が増える業務では、添付ファイルフィールドだけに寄せすぎないほうがよいです。

kintone公式ヘルプでは、kintoneを含むcybozu.comサービスで使えるディスク容量は「契約ユーザー数 × 5GB」と説明されています。また、ディスク使用量には添付ファイル領域、監査ログ保存領域、データベース領域が含まれます。

kintoneヘルプ：ディスク容量とディスク使用量

添付ファイルが増えると、単に容量の問題だけでなく、次のような管理の問題も起きます。

問題	起きる理由	設計で決めること
原本が分からない	同じファイルを複数レコードへ添付する	原本をBoxに置き、kintoneには文書情報とリンクを持つ
最新版が分からない	ファイル名に日付や版が統一されていない	版管理ルール、承認済み版、差し替え手順を決める
容量が読めない	写真、図面、PDFが増え続ける	Boxへ置く文書種別とkintoneに残す添付種別を分ける
検索しづらい	ファイルの中身と業務項目が分かれている	kintoneに文書種別、顧客、案件、保管期限を持つ
権限が崩れる	kintone権限だけで見える前提にする	Box側のフォルダ権限と共有リンクを別途設計する
削除時に迷う	レコード削除とファイル削除の関係がない	削除禁止、アーカイブ、保管満了のルールを決める

Box Japanのkintone連携ページでは、kintoneのディスク容量、ファイル探索、書類内容の確認といった課題に対して、Box連携でレコードに紐づくフォルダ表示や文書要約支援を利用できることが紹介されています。

Box Japan：kintone連携

ただし、ここで大事なのは、Boxに置けば自動的に整理されるわけではないことです。

Boxは文書を保存・共有・プレビューする場所です。

kintoneは業務の状態、担当者、期限、承認、一覧、検索条件を管理する場所です。

両方をつなぐキーがないと、Box内のフォルダとkintoneレコードが別々に増えていきます。

kintoneに持つデータとBoxに置くファイルを分ける

kintoneとBox連携では、まず「どの情報をどちらに持つか」を決めます。

情報	kintoneに持つ	Boxに置く
案件番号、顧客名、担当者	持つ	フォルダ名やメタデータに反映する場合がある
ステータス、期限、承認状態	持つ	原則としてkintoneで管理する
文書種別、提出日、受領日	持つ	ファイル名やフォルダ分類にも反映する
原本ファイル	必要最小限にする	持つ
プレビュー、共同編集、共有リンク	URLや状態を持つ	実体と権限を持つ
保管期限、廃棄予定	業務判断の項目として持つ	Box Governanceなどの保持設定と合わせる
送受信履歴、監査ログ	連携ログや業務履歴を持つ	Box側の操作履歴やアクセス管理を持つ

基本形は、kintoneに文書の「意味」を持ち、Boxに文書の「実体」を置くことです。

たとえば契約管理アプリであれば、kintoneには次の項目を持たせます。

• 契約番号
• 顧客名
• 契約種別
• 契約開始日
• 契約終了日
• 自動更新有無
• 契約ステータス
• 担当者
• 契約書BoxフォルダURL
• 承認済み版ファイルURL
• 保管期限
• 削除禁止フラグ

契約書PDF、押印済みファイル、修正履歴、相手先から受領した資料はBoxに置きます。

レコード詳細画面には、Boxフォルダや主要ファイルへのリンクを表示します。

この形にすると、kintoneの一覧で「契約終了90日前」「承認待ち」「保管期限満了予定」を管理しつつ、ファイルの実体はBoxで扱えます。

Boxにはファイルを置き、kintoneにはそのファイルを業務で扱うための意味、状態、期限、担当者を残します。

レコードとフォルダの紐づけ設計

Box連携で最も重要なのは、kintoneレコードとBoxフォルダをどう紐づけるかです。

サイボウズの連携サービス掲載ページでは、kintoneのレコード作成時にBoxフォルダを自動作成したり、レコード添付ファイルをBoxへ連携・保管したり、Box側で更新された情報をkintoneアプリ画面に反映できることが紹介されています。

サイボウズ：Box連携サービス

このような自動作成を使う場合でも、フォルダ設計を先に決めます。

設計項目	決めること
親フォルダ	アプリ単位、部門単位、年度単位、顧客単位のどこに置くか
フォルダ名	レコード番号、案件番号、顧客名、日付をどう組み合わせるか
一意キー	同名フォルダを作らないために何をキーにするか
kintone側フィールド	BoxフォルダID、共有リンク、主要ファイルURLをどこに持つか
作成タイミング	レコード作成時、ステータス変更時、文書登録時のどこで作るか
名前変更	顧客名や案件名が変わったとき、Boxフォルダ名も変えるか
削除時	kintoneレコード削除時にBoxフォルダを残すか、アーカイブへ移すか
失敗時	フォルダ作成失敗、リンク保存失敗、重複作成をどう検知するか

kintone.devのBoxプラグインサンプルでは、重複禁止のテキストフィールドをキーにしてBoxフォルダを作成し、Box共有リンクをリンクフィールドまたはテキストフィールドに表示する構成が示されています。また、新規レコード作成時にBoxフォルダを作成すること、共有リンク権限を設定することも説明されています。

Kintone Developer Program：Box Plug-in

このサンプルは実装理解に役立ちますが、業務で使う場合は追加で決めるべき点があります。

たとえば、レコード番号をフォルダ名にするだけでは、Box側で見たときに何の案件か分かりにくくなります。

一方で、顧客名だけをフォルダ名にすると、同名顧客や案件分岐で重複します。

実務では、次のような命名が扱いやすいです。

案件番号_顧客名_案件名
契約番号_取引先名_契約種別
YYYY_部門_申請番号_申請名

ただし、顧客名や案件名が変わることもあります。

その場合、フォルダ名を自動で変えるのか、kintone側に表示名だけ持つのかを決めます。

BoxフォルダIDをkintoneに保持しておけば、フォルダ名が変わっても紐づけを維持しやすくなります。

命名規則・保管期限・版管理

Box連携では、ファイル名とフォルダ構成を軽く見ないほうがよいです。

ファイル名が自由すぎると、Box上で探せません。

kintoneから見ても、どれが承認済み版か分かりません。

文書種別ごとに、次のようなルールを決めます。

文書種別	フォルダ	ファイル名	承認済み版の扱い
契約書	顧客/契約番号	契約番号_契約書_v01.pdf	kintoneに承認済み版URLを持つ
見積書	顧客/案件番号/見積	案件番号_見積書_YYYYMMDD.pdf	採用版だけを主要ファイルにする
図面	顧客/案件番号/図面	案件番号_図面種別_版数.pdf	差し替え履歴を残す
作業写真	顧客/案件番号/写真	撮影日_工程_連番.jpg	写真一覧はBox、分類はkintone
請求書	顧客/請求年度	請求番号_請求書.pdf	会計連携の状態をkintoneで持つ

保管期限も同じです。

kintone側に保管期限日、廃棄予定、削除禁止、法定保管区分を持たせます。

Box側では、Box Governanceや保持ポリシーの利用可否を確認します。

Box Supportでは、保持ポリシーによって一定期間コンテンツを保持し、期間終了後に削除または保持解除する考え方が説明されています。

Box Support：About Retention and Retention Policies

保持ポリシーは便利ですが、kintoneのステータスと無関係に設定すると、業務判断と保管ルールがずれます。

たとえば、契約が終了しても、係争中なら削除してはいけないかもしれません。

逆に、案件が失注しても、一定期間は見積書を残す必要があるかもしれません。

Boxの保持設定と、kintoneの業務ステータスを対応させておく必要があります。

Boxの保管ルールは、kintoneのステータス、文書種別、削除禁止フラグと対応させて設計します。ファイル単体の期限だけで決めると実務とずれます。

Box権限とkintone権限のズレ

kintoneとBox連携で見落としやすいのが、権限の二重管理です。

kintoneでレコードが見える人が、Boxフォルダも見えるとは限りません。

逆に、Boxフォルダの共有リンクを知っている人が、kintoneレコードを見られるとは限りません。

このズレを放置すると、次の問題が起きます。

• kintoneでレコードは見えるが、Boxファイルが開けない
• Box共有リンクからファイルだけ見えて、kintoneの文脈が分からない
• 退職者や異動者がBoxフォルダに残る
• 外部共有リンクが残り続ける
• kintoneのアクセス権を変えてもBox側が変わらない

Box Supportでは、共有リンクはコラボレーター招待とは別の方法であり、権限レベル、有効期限、パスワード保護などのセキュリティ設定を構成できると説明されています。

Box Support：Creating Shared Links

また、Boxのコラボレーター権限では、フォルダに招待する際に権限レベルを選び、それぞれ可能な操作が異なります。

Box Support：Understanding Collaborator Permission Levels

設計時には、次の表で整理します。

利用者	kintone権限	Box権限	注意点
担当者	自分の案件を閲覧・編集	対象フォルダを編集	異動時にBox権限を外す
上長	部門案件を閲覧・承認	閲覧または編集	承認済み版の差し替えを制限する
経理	請求関連のみ閲覧	請求書フォルダを閲覧	案件全体の資料を見せすぎない
外部協力会社	kintone権限なし、またはゲスト	必要フォルダのみ共有	共有リンクの有効期限を決める
監査担当	閲覧のみ	閲覧のみ	監査ログと保管期限を確認できるようにする

重要なのは、kintoneとBoxの権限を「同じもの」と考えないことです。

kintoneは業務データへのアクセス権。

Boxは文書原本へのアクセス権。

両方を別々に設計し、ずれたときの確認手順を持ちます。

プレビュー・検索・文書要約支援の考え方

Box連携を入れると、kintone画面からBoxフォルダやファイルを確認できるようにする構成があります。

Box Japanのkintone連携ページでは、kintone画面内にレコードに紐づくフォルダを表示できること、Box AIで文書の要約、翻訳、分析を行えることが紹介されています。ただし、利用できる機能は連携ソリューションの提供元・製品により異なるとされています。

この種の機能は便利ですが、設計上は次のように分けます。

機能	便利な場面	設計上の注意
kintone内プレビュー	レコードを見ながら契約書や図面を確認する	表示権限とBox権限の両方を確認する
Box検索	ファイル名や文書内の語句で探す	kintoneの案件番号や文書種別も合わせる
文書要約支援	長い契約書、議事録、仕様書の一次確認	要約だけで承認判断をしない
翻訳支援	海外取引先の文書確認	原文と承認済み訳の扱いを分ける
共有リンク	社外へのファイル共有	有効期限、ダウンロード可否、パスワードを決める

文書要約や検索支援は、文書確認の入口としては有用です。

しかし、承認、契約締結、請求、監査の判断は、kintone側のステータスと担当者確認に戻します。

「Boxで見られる」「要約できる」ことと、「業務上承認した」ことは別です。

承認済み版、確認者、確認日、差し戻し理由はkintoneに残します。

プラグイン・個別開発の使い分け

kintoneとBoxをつなぐ方法は、プラグイン、連携サービス、個別開発に分かれます。

方法	向いているケース	注意点
既存プラグイン	Boxフォルダ表示、ファイル保管、基本的な自動作成	対応範囲、スマートフォン対応、権限、ログを確認する
連携サービス	複数アプリ、帳票保存、クラウドストレージ横断	料金、対象ストレージ、運用ログを確認する
kintone JavaScriptカスタマイズ	レコード画面にBox導線を出す	認証、ブラウザ制約、保守担当が必要
個別API連携	フォルダ作成、権限付与、メタデータ同期、再実行が必要	開発、監視、エラー処理、API制限の設計が必要
手動運用	件数が少なく、文書管理ルールを先に試したい	命名規則とフォルダURL入力を徹底する

kintone.devのBoxプラグインサンプルには、スマートフォンでは動作しないこと、kintoneレコード削除イベントは関与せず、kintoneでレコードを削除してもBoxフォルダは削除されないことが制限として記載されています。

これはサンプルの話ですが、実務でも重要な論点です。

「レコードを消したらファイルも消える」と思い込むと危険です。

削除は自動化しすぎないほうがよい場面もあります。

契約書、請求書、監査資料、顧客提供資料などは、レコード削除と連動して消してはいけない場合があります。

そのため、次のように状態を分けます。

状態	kintone側	Box側
作成中	下書き、確認待ち	作業フォルダ
承認済み	承認済み版URLを保持	承認済みフォルダまたはファイル
運用中	案件・契約ステータスに紐づく	関係者に共有
終了	保管期限を設定	アーカイブフォルダ
保管満了	廃棄候補一覧に出す	保持ポリシーや削除申請に従う
係争・監査	削除禁止	保持またはリーガルホールド

プラグインで足りるのは、レコードとフォルダの基本連携が中心です。

権限同期、保管期限、削除申請、複数アプリ横断、監査対応まで必要なら、個別開発や運用アプリを組み合わせます。

kintone API連携の設計方法はこちら

よくある失敗

kintoneとBox連携では、次の失敗が起きやすいです。

Boxを単なる容量退避先にする

ファイルをBoxへ置くだけでは、文書管理にはなりません。

どの案件の、どの文書種別の、どの版で、誰が確認したファイルなのかをkintoneに残します。

kintone添付とBox原本が二重になる

同じファイルをkintoneにもBoxにも置くと、どちらが正しいか分からなくなります。

移行期間を除き、原本をどちらに置くかを決めます。

フォルダ名に業務キーが入っていない

「資料」「契約書」「2026年」だけのフォルダ名では、後から追えません。

案件番号、契約番号、顧客名、文書種別など、業務キーを入れます。

レコード削除時の扱いを決めていない

kintoneレコードを消したらBoxフォルダも消すのか、残すのか、アーカイブへ移すのか。

このルールがないと、監査や問い合わせ時に困ります。

原則として、文書原本は削除よりもアーカイブや保管満了の手続きを優先します。

Box権限を共有リンクだけで済ませる

共有リンクは便利ですが、社外共有、社内限定、招待者限定、有効期限などを設計しないと開きすぎます。

重要資料は、共有リンクではなくコラボレーター権限で管理するほうがよい場面もあります。

文書要約だけで承認する

Box上で文書要約や検索支援を使っても、最終確認は業務上の責任者が行います。

kintoneに確認者、確認日、承認ステータス、差し戻し理由を残します。

連携エラーを見ない

フォルダ作成、リンク保存、ファイル移動、権限付与は失敗することがあります。

失敗したレコードを一覧化し、再実行担当と対応期限を持たせます。

実装前チェックリスト

kintoneとBox連携を始める前に、次の項目を確認します。

確認項目	判断すること
対象業務	契約、案件、工事、申請、請求、顧客対応のどれか
対象文書	原本をBoxに置く文書、kintoneに添付する文書
正本	業務状態はkintone、ファイル原本はBoxでよいか
一意キー	レコード番号、案件番号、契約番号など何で紐づけるか
フォルダ構成	親フォルダ、年度、顧客、案件、文書種別の階層
命名規則	ファイル名、フォルダ名、版数、日付形式
権限	kintone権限とBox権限をどう合わせるか
共有リンク	社外共有、有効期限、ダウンロード可否、パスワード
保管期限	文書種別ごとの保管年数、削除禁止、廃棄手順
削除時	レコード削除、案件終了、保管満了時のBox側処理
連携ログ	フォルダ作成、ファイル保存、権限付与、失敗一覧
スマートフォン	現場利用時にプレビューやアップロードが必要か

この表が埋まらないうちは、プラグインを入れても運用で詰まります。

逆に、ここを先に決めれば、既存プラグインで足りるのか、個別連携が必要なのか判断しやすくなります。

Bitlightに相談できること

Bitlightでは、kintoneとBox連携を、ファイル置き場の移行ではなく、業務データと文書原本の設計として整理します。

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

• kintoneに残す項目とBoxに置くファイルの責任分界
• 案件、契約、工事、申請ごとのフォルダ構成
• Boxフォルダ自動作成とkintone側URL保持の設計
• ファイル名、文書種別、版管理、承認済み版のルール
• kintone権限とBox権限のズレの整理
• 共有リンク、有効期限、社外共有の運用ルール
• 保管期限、削除禁止、アーカイブ、廃棄候補一覧の設計
• 連携プラグイン、JavaScript、API連携の選定
• 連携エラー、再実行、監査ログの設計

kintoneとBox連携は、容量対策から始まることが多いです。

しかし、実務で価値が出るのは、文書が後から探せて、正しい版が分かり、権限が崩れず、保管期限まで追える状態になったときです。

kintoneとBox連携は、ファイルを外に出す設定ではなく、業務レコードから文書原本、権限、保管期限、監査ログへ迷わずたどれる設計にします。

Boxには文書原本を置く。

kintoneには業務判断に必要な項目を残す。

この分担を決めてから連携方法を選ぶと、ファイルが増えても、案件や契約の運用が崩れにくくなります。