kintone添付ファイルの設計方法｜保存・検索・容量・権限を崩さない構成

kintoneの添付ファイルフィールドは、現場ではとても使われます。

見積書を案件に添付する。

契約書を顧客レコードに添付する。

請求書PDFを請求レコードに添付する。

現場写真を作業報告に添付する。

申請書や証憑を申請レコードに添付する。

納品書、検収書、図面、本人確認書類を残す。

使い始めるだけなら簡単です。

しかし、設計せずに増やすと、次のような問題が起きます。

• どのレコードに最新ファイルがあるか分からない
• 同じファイルが顧客、案件、請求に重複して添付される
• ファイル名が人によって違い、検索できない
• 版管理がなく、最新版と提出済み版が混ざる
• 契約書や個人情報を見せてはいけない人が見られる
• 画像のサムネイルで一覧が重くなる
• 添付ファイルが増えてディスク容量を圧迫する
• 退職者や担当変更後に、保管場所が分からなくなる
• 外部共有がメール添付や個人ストレージに散らばる

添付ファイルは、ファイルそのものより「どの業務事実の証跡か」が重要です。

見積書なら、どの案件の、どの版の、いつ提出した見積か。

契約書なら、どの顧客の、どの契約期間の、締結済み文書か。

現場写真なら、どの作業日の、どの拠点の、何を示す写真か。

請求書なら、どの請求月の、発行済みPDFか。

kintone添付ファイルは、ファイル置き場ではなく、業務レコードに紐づく証跡として設計します。

この記事では、kintone添付ファイルフィールドの標準仕様、ファイル種別・版・提出日などのメタデータ設計、容量と保存期限、閲覧権限、外部共有、一括アップロード・一括ダウンロード、外部ストレージとの使い分けまで整理します。

kintoneバックアップの設計方法はこちら
kintoneセキュリティの設計方法はこちら

添付ファイルは業務レコードに紐づけて管理する

添付ファイル設計で最初に決めるのは、フィールドの配置場所です。

どのアプリに添付するか。

どのレコードに添付するか。

同じファイルを複数レコードに持たせるか。

外部ストレージのURLだけ持つか。

ここを決めないと、ファイルが散らばります。

ファイル	添付するレコードの例	理由
見積書	案件、見積レコード	提出版と案件状態を紐づける
契約書	契約レコード	契約期間、締結日、相手先と紐づける
請求書	請求レコード	請求月、金額、発行状態と紐づける
領収書	経費申請レコード	承認、支払、証憑確認と紐づける
現場写真	作業報告レコード	作業日、現場、担当者と紐づける
図面	案件または物件レコード	対象物と版管理を紐づける
本人確認書類	顧客確認レコード	閲覧権限と保存期間を厳密にする

ファイルを「顧客アプリに全部添付する」設計は分かりやすいように見えます。

しかし、見積、契約、請求、問い合わせ、作業報告がすべて顧客レコードに積み上がると、何のためのファイルか分からなくなります。

おすすめは、業務イベントごとに添付先を分けることです。

管理したいこと	添付先の考え方
どの見積を提出したか	見積レコードに添付
どの契約が締結済みか	契約レコードに添付
どの請求を発行したか	請求レコードに添付
どの申請の証憑か	申請レコードに添付
どの作業の写真か	作業報告レコードに添付

顧客アプリや案件アプリには、添付ファイルを直接集めるのではなく、関連レコード一覧で契約、請求、作業報告を見る形にすると、探しやすくなります。

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

添付ファイルフィールドの標準仕様

kintoneヘルプでは、添付ファイルフィールドを配置すると、レコードにファイルを添付でき、複数ファイルの添付や添付ファイルの並べ替えができると説明されています。

ファイル添付は、追加または編集画面でファイルを選択するほか、ドラッグアンドドロップでも行えます。

レコード詳細画面では、添付ファイルのファイル名とサイズが表示され、ファイル名をクリックするとダウンロードできます。

kintoneヘルプ：添付ファイル

標準仕様として、まず次を押さえます。

項目	内容
複数ファイル	1つの添付ファイルフィールドに複数ファイルを添付できる
並べ替え	追加・編集画面でドラッグアンドドロップにより並べ替えできる
表示	詳細画面でファイル名とサイズが表示される
ダウンロード	ファイル名をクリックしてダウンロードできる
画像サムネイル	条件を満たす画像はサムネイル表示される
必須設定	添付を必須項目にできる
フィールドコード	APIで指定するときに使う

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

また、サムネイルを表示できる画像サイズは10MBまで、画素数は5,000万画素までです。

kintoneヘルプ：制限値一覧

添付ファイルフィールドのページでは、サムネイルが表示される条件として、サイズ10MB以内、画素数5,000万画素以内、形式はBMP、GIF、JPG、PNGと説明されています。

kintoneヘルプ：添付ファイル

見るべき仕様	設計での意味
1ファイル1GBまで	大容量ファイルを置けるが、何でも置く判断にはしない
サムネイル条件	写真管理では一覧表示の見え方を確認する
ファイル名とサイズ表示	ファイル名ルールを決めないと探しにくい
ダウンロード可能	閲覧権限がそのままファイル取得に関わる
複数添付可能	版や種別を混ぜすぎると分からなくなる

添付ファイルフィールドは便利ですが、標準仕様だけでは、ファイル種別、版、保存期限、権限、容量の運用ルールまでは決まりません。

ファイル種別・版・提出日などのメタデータ設計

添付ファイルで一番崩れやすいのは、ファイル名だけで管理することです。

ファイル名は、人によって揺れます。

見積.pdf

見積_修正版.pdf

最終見積.pdf

最終_最新版.pdf

20260610_株式会社サンプル様_御見積書.pdf

どれが提出済みで、どれが社内確認中か、ファイル名だけでは判断しづらくなります。

そのため、重要な属性はフィールドとして持たせます。

メタデータ	例
ファイル種別	見積書、契約書、請求書、領収書、写真、図面
版	v1、v2、提出版、締結版、差替版
提出日	顧客へ送付した日
受領日	相手から受け取った日
有効期限	見積期限、契約終了日
保存期限	何年後に見直すか
作成者	誰が作成したか
確認者	誰が確認したか
状態	作成中、確認中、提出済み、締結済み、破棄
外部URL	外部ストレージや電子契約のURL

ファイル種別ごとに、必要なメタデータは違います。

ファイル種別	持つべき項目
見積書	見積番号、版、提出日、有効期限、提出先
契約書	契約番号、締結日、契約期間、相手方、原本種別
請求書	請求番号、請求月、発行日、金額、送付状態
領収書	支払日、支払先、金額、承認状態
現場写真	撮影日、現場、工程、撮影者、写真種別
図面	図面番号、版、対象物件、承認状態

1つの添付ファイルフィールドにすべて入れると、メタデータを分けにくくなります。

重要なファイルは、ファイル台帳アプリを作る方がよいです。

設計	向いているケース
業務レコードに直接添付	ファイル数が少なく、レコードの証跡として見る
ファイル台帳アプリを別に作る	種別、版、期限、権限、検索を細かく管理する
外部ストレージURLを持つ	大容量、共同編集、外部共有が多い

添付ファイルを探せるようにするには、ファイル名ではなく、ファイル種別・版・提出日・状態などのメタデータをフィールドとして持ちます。

容量と保存期限の運用

添付ファイルは、容量管理が後回しになりがちです。

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

kintone：料金

添付ファイルを多く扱う業務では、最初に容量を見積もります。

業務	例	容量が増えやすい理由
現場写真	1作業報告に写真20枚	画像が毎日増える
契約管理	契約書PDF、覚書、本人確認書類	長期保存が必要
請求管理	請求書、納品書、検収書	月次で増える
図面管理	図面PDF、CAD、修正版	1ファイルが大きい
問い合わせ	スクリーンショット、証跡	対応件数に比例する

簡単な見積もりは、次のようにします。

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

この計算をすると、写真や図面はすぐ大きくなることが分かります。

保存期限も決めます。

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

削除する場合も、いきなり消さない方がよいです。

削除候補一覧を作り、確認者、削除日、削除理由を残します。

kintoneレコード数上限の考え方はこちら

閲覧権限と外部共有の注意点

添付ファイルは、レコードやフィールドの権限と一緒に考えます。

ファイル単体で「この添付だけ特定の人に見せる」という設計に頼るより、どのアプリ、どのレコード、どのフィールドに置くかを分けます。

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

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

つまり、添付ファイルの権限は、レコード設計とフィールド設計に強く依存します。

ファイル	権限設計の例
見積書	営業担当、営業管理者、経理だけ
契約書	営業管理者、法務、経営だけ
請求書	経理、営業担当、管理者だけ
本人確認書類	限定された担当者だけ
現場写真	現場担当、管理者、顧客共有用は別管理

機密性が高いファイルは、同じアプリの同じ添付フィールドに混ぜない方がよいです。

たとえば、案件アプリに「添付ファイル」フィールドを1つだけ置き、見積書、契約書、本人確認書類、社内メモをすべて入れると、権限を分けにくくなります。

避けたい状態	改善案
1フィールドに全部添付	種別ごとにフィールドを分ける
機密書類と一般資料が混在	機密書類用アプリを分ける
社外共有ファイルが混在	社外共有用の保管場所を分ける
URL共有と添付が混在	外部URLフィールドと添付を分ける

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

外部共有が多いファイルは、kintone添付だけで完結させない方がよい場合があります。

外部ストレージ、電子契約、請求書発行システム、ファイル共有サービスのURLをkintoneに持たせる設計もあります。

その場合、kintoneには「どの業務レコードに紐づくファイルか」「状態は何か」「URLはどこか」「誰が確認したか」を持たせます。

一括アップロード・一括ダウンロードの判断

添付ファイルが増えると、一括アップロードや一括ダウンロードの要望が出ます。

ただし、これは単なる操作の問題ではありません。

一括で扱う前に、対象条件とファイル名ルールを決めます。

操作	先に決めること
一括アップロード	どのレコードに紐づけるか、キーは何か
一括ダウンロード	どの条件で対象を絞るか
一括削除	削除してよい根拠と承認者
一括移行	kintoneに残すか、外部へ移すか

APIでファイルを扱う場合は、fileKeyの扱いを理解します。

cybozu developer networkのファイルアップロードAPIでは、一時保管領域にファイルをアップロードし、レスポンスとして取得したfileKeyを、添付ファイルフィールドなどに関連付けるときに使うと説明されています。

cybozu developer network：ファイルをアップロードする

REST API共通仕様では、アップロードしたファイルは一時保管領域に保存され、レコード登録や更新APIでレコードに添付しない限り3日間で削除されると説明されています。

cybozu developer network：kintone REST APIの共通仕様

ファイルダウンロードAPIでは、添付ファイルフィールドのファイルキーを指定してファイルをダウンロードし、レスポンスボディにファイル内容が入ると説明されています。

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

API操作	注意点
アップロード	一時保管のfileKeyを取得する
レコード登録/更新	fileKeyを添付ファイルフィールドに設定する
ダウンロード	レコード取得で得た添付ファイルのfileKeyを使う
権限	ダウンロードにはレコード・フィールド閲覧権限が必要
期限	一時保管のまま放置しない

APIで添付ファイルを扱う場合は、アップロードしたfileKeyと、添付済みファイルをダウンロードするfileKeyを混同しないことが重要です。

一括処理では、ログも必要です。

ログ項目	目的
処理ID	一括処理を識別する
対象レコード	どのレコードに添付したか
ファイル名	何を処理したか
fileKey	API処理の確認
成功/失敗	再実行対象を分ける
エラー内容	権限、容量、ファイル形式の問題を切り分ける
実行者	誰が実行したか

kintone API制限の回避設計はこちら

外部ストレージに逃がすケース

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

次のような場合は、外部ストレージや専用システムとの分担を考えます。

状況	外部保管を検討する理由
大容量ファイルが多い	ディスク容量が急速に増える
動画や高解像度写真が多い	kintone上で扱うより専用保管が向く
外部共有が多い	共有権限やリンク管理が必要
共同編集が必要	ファイルの同時編集や履歴管理が必要
法務・契約管理が厳しい	電子契約や文書管理の機能が必要
長期保管が中心	現役業務アプリに置き続ける必要が薄い

kintoneに残すのは、ファイルそのものではなく、業務上の管理項目にしてもよいです。

kintoneに残す項目	外部側に置くもの
ファイル種別	ファイル本体
外部URL	版履歴
提出日/受領日	共有権限
状態	共同編集履歴
確認者	大容量データ
保存期限	アーカイブ

この分担にすると、kintoneでは案件、契約、請求、申請の状態を管理し、ファイル本体は外部で保管できます。

ただし、外部URLだけ貼る設計にも注意があります。

注意点	対策
URL切れ	定期確認や保管先ルールを決める
権限ずれ	kintone権限と外部権限を合わせる
個人フォルダ化	会社管理の共有領域に置く
ファイル名ばらつき	命名規則を決める
退職者依存	個人所有ではなく組織所有にする

外部ストレージに逃がすかどうかは、容量だけで決めません。

外部共有、共同編集、版管理、長期保管、検索、権限管理まで含めて判断します。

よくある失敗

kintone添付ファイルの運用でよくある失敗を整理します。

失敗	起きること	対策
1フィールドに全部入れる	種別も版も分からない	種別ごとに分ける
ファイル名だけで探す	命名が揺れて見つからない	メタデータを持つ
顧客アプリに全部集める	業務イベントとの紐づきが消える	見積、契約、請求などに分ける
機密ファイルを混ぜる	見せてはいけない人が見られる	アプリやフィールドを分ける
写真を大量添付する	容量が増え続ける	外部保管や保存期限を決める
一括処理のログがない	どこまで処理したか分からない	処理IDと結果ログを残す
APIのfileKeyを混同する	アップロード後に添付できない、または取得できない	一時保管と添付済みのfileKeyを分けて扱う
URLだけ貼る	URL切れ、権限ずれが起きる	外部保管ルールを決める

添付ファイル運用で守るべきなのは、ファイルそのものではなく、業務上の意味、探し方、見せてよい範囲、残す期間です。

実装前チェックリスト

添付ファイルフィールドを追加する前に、次を確認します。

チェック	内容
添付先	顧客、案件、契約、請求、申請、作業報告のどこに紐づけるか
ファイル種別	見積、契約、請求、領収書、写真、図面などを分けるか
メタデータ	版、提出日、受領日、状態、保存期限を持つか
ファイル名	命名規則を決めるか
権限	誰が見られるか、どのフィールドに置くか
容量	月間・年間の増加量を見積もったか
サムネイル	写真一覧の表示をどうするか
一括処理	アップロード、ダウンロード、削除のログを残すか
外部共有	kintone添付か外部URLかを分けたか
保存期限	削除候補一覧や退避ルールを作るか
バックアップ	誤削除や差替時に戻せるか

設計書には、添付ファイルフィールド名だけでなく、次を書きます。

設計書に書くこと	理由
ファイル種別一覧	何を保存するか明確にする
添付先アプリ	ファイルの所在を固定する
メタデータ項目	検索や期限管理に使う
権限設計	機密ファイルの漏れを防ぐ
容量見積もり	増え方を先に見る
外部保管ルール	kintoneに置かないファイルを決める
一括処理ログ	失敗時に戻せるようにする

Bitlightに相談できること

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

しかし、業務で長く使うには、ファイルの意味、探し方、権限、容量、保存期限、外部保管との境界を先に決める必要があります。

Bitlightでは、既存アプリやファイル運用を見ながら、次のような設計を支援できます。

• 添付ファイルを置くべきアプリとレコードの整理
• ファイル種別、版、提出日、保存期限などのメタデータ設計
• 見積書、契約書、請求書、写真、証憑の保管ルール作成
• レコード権限、フィールド権限、外部共有の整理
• 容量増加の見積もりと外部ストレージ連携の判断
• 一括アップロード、一括ダウンロード、API処理ログの設計
• 誤削除や差替に備えたバックアップ運用の整理

添付ファイルが増えてから整理すると、どれが正しいファイルか、誰が見てよいファイルかを後追いで判断することになります。

ファイルを使う業務が増える前に、kintone側で管理する範囲と、外部に任せる範囲を分けておく方が安全です。