kintoneファイル管理の設計方法｜フォルダ発想から業務レコード管理へ移す構成

kintoneでファイル管理をしたい、という相談はよくあります。

契約書を探せるようにしたい。

請求書PDFを保管したい。

現場写真を案件別に見たい。

図面や仕様書の最新版を共有したい。

申請書や領収書の証憑を残したい。

メール添付で散らばった資料を集めたい。

社内共有フォルダでは、どれが最新版か分からない。

個人フォルダに重要ファイルが残っている。

ファイル名の付け方が人によって違う。

権限を変えるたびにフォルダ単位で調整している。

こうした課題に対して、kintoneは有力な選択肢です。

ただし、kintoneを単なるファイル置き場として使うと、別の問題が起きます。

• 顧客レコードに資料が大量に添付され、何のファイルか分からない
• 契約書、見積書、本人確認書類、社内メモが同じ添付フィールドに混ざる
• ファイル名だけで管理しており、版や提出日が追えない
• 同じPDFが案件、顧客、請求に重複して添付される
• 権限がレコードやフィールドと合っておらず、見せてはいけない人が見られる
• 大量の写真や図面で容量が増え続ける
• 外部ストレージへの退避後、kintone側から探せなくなる

ファイル管理で大事なのは、ファイルそのものではありません。

そのファイルが、どの顧客、どの案件、どの契約、どの申請、どの作業に紐づく証跡なのかです。

kintoneファイル管理は、フォルダを再現するのではなく、ファイルを業務レコードに紐づける設計として考えます。

この記事では、kintoneでファイル管理を設計する方法を、フォルダ発想の限界、業務レコードとの紐づけ、ファイル種別・カテゴリ・版の項目設計、案件・契約・申請別の例、権限・保存期限・容量、一括ダウンロード、外部ストレージとの境界まで整理します。

kintone添付ファイルの設計方法はこちら
kintoneデータベース設計はこちら

フォルダ管理をそのまま移すと崩れる

社内共有フォルダの構造を、そのままkintoneに移そうとするケースがあります。

たとえば、次のような構造です。

共有フォルダの例	起きやすい問題
顧客別フォルダ	顧客内に見積、契約、請求、写真が混ざる
案件別フォルダ	契約期間や請求状態がファイル名頼みになる
年月別フォルダ	顧客や案件との関係が追いにくい
部署別フォルダ	部署をまたぐ案件で所在が分かれやすい
担当者別フォルダ	異動や退職で引き継ぎにくい

kintoneは、フォルダ階層を深く作る道具ではありません。

レコード、フィールド、一覧、関連レコード、権限を組み合わせて、業務データとして探せる状態を作る道具です。

サイボウズのkintone文書管理ページでも、紙書類、メール添付、提案資料などを一元管理し、添付ファイルだけでなく、作成者や更新日などの項目を自由に設定できることが紹介されています。

kintone：文書管理

つまり、kintoneでファイルを扱うときは、フォルダ名ではなく、フィールドで意味を持たせます。

フォルダ発想	kintone発想
顧客別フォルダに置く	顧客レコードや契約レコードに紐づける
ファイル名で種別を判別する	ファイル種別フィールドを持つ
最新版をファイル名で表す	版、状態、承認日を持つ
年月フォルダで探す	提出日、受領日、締結日で検索する
フォルダ権限で制御する	アプリ、レコード、フィールド権限で制御する

kintoneでファイルを探せる状態にするには、フォルダ階層ではなく、ファイル種別、業務キー、日付、状態をフィールドとして持たせます。

ファイルを業務レコードに紐づける

ファイル管理の最初の設計は、「どのアプリに置くか」ではなく、「どの業務事実に紐づけるか」です。

契約書は、顧客ではなく契約に紐づける。

請求書は、顧客ではなく請求に紐づける。

現場写真は、案件ではなく作業報告に紐づける。

領収書は、担当者ではなく経費申請に紐づける。

図面は、案件、物件、設備など、対象物に紐づける。

ファイル	紐づけるレコードの例	理由
見積書	見積レコード	版、提出日、有効期限を持てる
契約書	契約レコード	契約期間、締結日、相手先を管理できる
請求書	請求レコード	請求月、発行日、金額と紐づく
領収書	経費申請レコード	承認、支払、証憑確認と紐づく
現場写真	作業報告レコード	作業日、現場、工程、撮影者と紐づく
図面	案件または物件レコード	対象物と版を紐づけられる
本人確認書類	顧客確認レコード	権限と保存期間を厳密にできる

顧客アプリに全部添付する設計は、入口では分かりやすく見えます。

しかし、顧客レコードに契約書、請求書、写真、申請書、問い合わせ資料が積み上がると、あとから探しにくくなります。

おすすめは、業務イベントごとにアプリを分け、顧客や案件から関連レコード一覧で参照する形です。

見たい画面	表示する関連情報
顧客詳細	契約、請求、案件、問い合わせ、保管ファイル
案件詳細	見積、作業報告、図面、顧客提出資料
契約詳細	契約書、覚書、更新履歴、解約通知
請求詳細	請求書PDF、納品書、検収書
作業報告	現場写真、報告書、顧客確認ファイル

この構成にすると、ファイルが業務データと一緒に残ります。

ファイルだけを探すのではなく、「どの契約のファイルか」「どの請求の証憑か」「どの作業日の写真か」から探せます。

ファイル種別・カテゴリ・版の項目設計

ファイル管理アプリを作る場合は、添付ファイルフィールドだけでは足りません。

ファイルを探し、確認し、更新し、保存期限を管理するための項目が必要です。

項目	例	用途
ファイル種別	契約書、請求書、写真、図面、証憑	一覧や検索で絞り込む
カテゴリ	顧客提出、社内確認、法務保管	利用目的を分ける
業務キー	顧客番号、案件番号、契約番号	元レコードへ戻る
版	v1、v2、提出版、締結版	最新版と過去版を分ける
状態	作成中、確認中、承認済み、破棄	利用可否を判断する
提出日	顧客へ送付した日	顧客対応履歴に使う
受領日	相手から受け取った日	証跡として残す
承認者	誰が確認したか	正式版か判断する
保存期限	いつ見直すか	退避や削除の判断に使う
外部URL	Box、Drive、電子契約など	外部保管先へ飛ぶ

ファイル名だけで管理すると、すぐに揺れます。

契約書.pdf

契約書_最新版.pdf

契約書_再修正.pdf

契約書_先方確認済.pdf

20260611_株式会社サンプル_契約書_締結済.pdf

どれが正本で、どれが確認中か、ファイル名だけでは判断しづらくなります。

正式な意味を持つものは、フィールドとして分けます。

ファイル名に任せない項目	理由
版	文字列が揺れやすい
承認状態	ファイル名だけでは正本か分からない
提出日	送付履歴として使う
保存期限	後から削除候補を抽出する
外部共有可否	持ち出し判断に必要

ファイル名は補助情報です。業務で判断に使う属性は、kintoneのフィールドとして持たせます。

案件・契約・申請別の設計例

ファイル管理は、業務ごとに設計を変えます。

すべてのファイルを1つのファイル管理アプリに集めるより、業務の重さに応じて分ける方がよい場合があります。

案件資料

案件資料では、見積書、提案書、仕様書、図面、議事メモなどが混ざりやすいです。

項目	設計例
紐づけ先	案件レコード
ファイル種別	見積、提案、仕様、図面、議事メモ
版	v1、v2、提出版
状態	作成中、社内確認中、提出済み
提出日	顧客へ送付した日
顧客共有可否	顧客へ渡してよいか

案件では、作成中のファイルと顧客提出済みのファイルを分けることが重要です。

契約書

契約書は、権限と保存期間が重要です。

項目	設計例
紐づけ先	契約レコード
ファイル種別	契約書、覚書、注文書、解約通知
原本種別	電子契約、PDF、紙原本
状態	確認中、締結済み、更新済み、終了
契約期間	開始日、終了日
閲覧範囲	営業管理者、法務、経営、経理

契約書は、顧客アプリに添付するより、契約レコードとして独立させる方が管理しやすいです。

申請・証憑

申請書や領収書は、承認と支払に紐づきます。

項目	設計例
紐づけ先	申請レコード
ファイル種別	領収書、見積、請求書、申請書
状態	申請中、承認済み、差戻し、支払済み
金額	証憑と照合する
承認者	誰が確認したか
保存期限	会計証憑としての保管ルールに従う

申請では、添付ファイルが承認済みか、差戻し後に差し替えられたかを追える設計にします。

権限・保存期限・容量の運用

ファイル管理では、見える範囲を慎重に決めます。

cybozu developer networkのファイルダウンロードAPIでは、ダウンロードに必要なアクセス権として、アプリのレコード閲覧権限、ファイルが添付されたレコードの閲覧権限、ファイルが添付されたフィールドの閲覧権限が挙げられています。

cybozu developer network：ファイルをダウンロードする

つまり、ファイル管理の権限は、アプリ、レコード、フィールドの設計と一緒に考える必要があります。

ファイル	権限設計の例
提案書	案件担当、営業管理者
契約書	営業管理者、法務、経営、経理
請求書	経理、営業担当、管理者
本人確認書類	限定された担当者だけ
現場写真	作業担当、管理者、顧客共有用は別管理
社内メモ	社内限定、外部共有対象から除外

保存期限も決めます。

ファイル	保存ルール例
見積書	失注後2年で見直し
契約書	契約終了後も社内ルールに従って保管
請求書	会計証憑として定められた期間保管
現場写真	完了後一定期間で外部保管へ移す
一時確認用ファイル	確認完了後に削除または退避

容量も最初に見ます。

kintoneの料金ページでは、ディスク容量は5GB×ユーザー数、ディスク増設は10GB単位で追加可能と案内されています。

kintone：料金

また、kintoneヘルプの制限値一覧では、添付ファイルは1ファイルにつき1GBまでと説明されています。

kintoneヘルプ：制限値一覧

写真や図面を扱う場合は、月間増加量を見積もります。

項目	例
1ファイル平均サイズ	5MB
1レコードあたりファイル数	10個
月間レコード数	200件
月間増加量	5MB × 10個 × 200件 = 10GB
年間増加量	120GB

この規模になると、すべてをkintone添付に置き続ける判断は重くなります。

ファイル管理では、添付できるかどうかだけでなく、誰が見られるか、いつまで残すか、どれくらい増えるかを先に決めます。

kintoneセキュリティの設計方法はこちら

一括ダウンロードとバックアップ

ファイル管理では、一括ダウンロードやバックアップの要件も早めに決めます。

あとから「全部落としたい」と言われると、対象条件、ファイル名、フォルダ構成、権限、ログを後追いで作ることになります。

要件	決めること
一括ダウンロード	対象一覧、対象フィールド、出力形式
監査提出	取得者、取得日時、提出先、対象条件
月次保管	請求月、顧客、ファイル種別
外部退避	保管先URL、退避日、削除可否
バックアップ	誤削除や差替時に戻せるか

一括ダウンロードするなら、ファイル名も設計します。

ファイル	ファイル名例
契約書	契約_契約番号_顧客名_締結日_ファイル名.pdf
請求書	請求_請求月_請求番号_顧客名_ファイル名.pdf
現場写真	写真_案件番号_作業日_写真区分_連番.jpg
見積書	見積_案件番号_見積番号_版_ファイル名.pdf

取得ログも必要です。

ログ項目	用途
実行者	誰が取得したか
実行日時	いつ取得したか
対象条件	どの範囲を取得したか
ファイル件数	取得数を確認する
合計容量	保管先や分割判断に使う
出力先	どこに保存したか
失敗件数	再実行対象を分ける

kintone添付ファイル一括ダウンロードの設計方法はこちら
kintoneバックアップの設計方法はこちら

外部ストレージや文書管理システムとの境界

すべてのファイルをkintoneに置く必要はありません。

むしろ、次のようなファイルは外部ストレージや文書管理システムと分担する方がよい場合があります。

状況	外部保管を検討する理由
動画や高解像度写真が多い	容量が増えやすい
CADや図面ファイルが大きい	kintone上で扱いにくい
共同編集が必要	ファイル本体の履歴管理が必要
外部共有が多い	リンク権限や期限付き共有が必要
長期保管が中心	現役業務アプリに置き続ける必要が薄い
電子契約や法務管理が必要	専用システムのワークフローが向く

この場合、kintoneに残す情報と、外部側に置く情報を分けます。

kintoneに残す情報	外部側に置く情報
顧客、案件、契約、申請との紐づき	ファイル本体
ファイル種別	版履歴
状態、提出日、承認者	共同編集履歴
保管先URL	大容量ファイル
保存期限	アーカイブ
外部共有可否	共有リンクと権限

外部URLだけを貼る設計にも注意が必要です。

注意点	対策
URL切れ	定期確認や再発行手順を決める
個人フォルダ化	会社管理領域に固定する
権限ずれ	kintone権限と外部権限を合わせる
ファイル名の揺れ	命名規則を決める
退職者依存	個人所有ではなく組織所有にする
二重管理	kintone側の正本/写しの扱いを決める

外部ストレージは、kintoneの代替ではなく分担先です。

kintoneでは業務上の意味を管理し、外部側ではファイル本体や大容量データを管理する、という分け方が安定します。

よくある失敗

kintoneファイル管理でよくある失敗を整理します。

失敗	起きること	対策
共有フォルダをそのまま再現する	深い階層を作れず、探し方が曖昧になる	業務レコードと項目で探せるようにする
顧客レコードに全部添付する	契約、請求、写真、申請が混ざる	業務イベントごとに添付先を分ける
ファイル名だけで管理する	版、状態、提出日が分からない	メタデータをフィールドにする
1つの添付フィールドに全部入れる	権限や一括取得を分けにくい	種別ごとにフィールドやアプリを分ける
機密ファイルを混ぜる	見せてはいけない人が見られる	アプリ、レコード、フィールド権限を設計する
容量を見積もらない	写真や図面で容量が増え続ける	月間増加量と外部退避を決める
外部URLだけ貼る	URL切れや権限ずれが起きる	保管先ルールと確認手順を作る
一括取得を後回しにする	監査や移行時に取り出せない	命名、フォルダ、ログを先に決める

kintoneファイル管理で守るべきなのは、ファイルを置く場所ではなく、業務上の意味、探し方、権限、保存期間です。

実装前チェックリスト

ファイル管理アプリや添付フィールドを作る前に、次を確認します。

チェック	内容
管理対象	契約書、請求書、写真、図面、証憑など
紐づけ先	顧客、案件、契約、請求、申請、作業報告のどれか
ファイル種別	一覧や検索で絞れる分類になっているか
版管理	最新版、提出版、締結版を分けるか
状態	作成中、確認中、承認済み、破棄などを持つか
権限	誰が見られるか、どのフィールドに置くか
容量	月間・年間の増加量を見積もったか
保存期限	いつ退避、削除、見直しするか
外部保管	kintone添付か外部URLかを分けたか
一括取得	ダウンロード時の命名とログを決めたか
バックアップ	誤削除や差替時に戻せるか

設計書には、次を書きます。

設計書に書くこと	理由
ファイル種別一覧	管理対象を固定する
添付先アプリ	ファイルの所在を決める
業務キー	顧客、案件、契約などへ戻れるようにする
メタデータ項目	版、状態、日付、保存期限を管理する
権限設計	機密ファイルの混入を防ぐ
容量見積もり	増え方を先に見る
外部保管ルール	kintoneに置かないファイルを決める
一括取得ルール	監査、保管、移行に備える

Bitlightに相談できること

kintoneのファイル管理は、添付ファイルフィールドを置くだけなら簡単です。

しかし、業務で長く使うには、ファイルをどの業務レコードに紐づけるか、どの項目で探すか、誰が見られるか、いつまで残すかを決める必要があります。

Bitlightでは、既存の共有フォルダやkintoneアプリを見ながら、次のような設計を支援できます。

• 契約書、請求書、写真、図面、証憑の管理対象整理
• 顧客、案件、契約、請求、申請、作業報告との紐づけ設計
• ファイル種別、カテゴリ、版、状態、提出日、保存期限の項目設計
• 添付ファイルフィールド、ファイル管理アプリ、関連レコード一覧の構成
• レコード権限、フィールド権限、外部共有の整理
• 容量増加の見積もりと外部ストレージ連携の判断
• 一括ダウンロード、バックアップ、外部保管ログの設計

ファイルが増えてから整理すると、何が正本で、どれを見せてよく、どこへ保管すべきかを後追いで判断することになります。

ファイル管理を始めるタイミングで、kintoneに持つ業務データと、外部に任せるファイル本体を分けておく方が、あとから直しやすい構成になります。