契約書が見つからない問題の解決｜検索性を高める管理設計
リーガルテック
契約管理シリーズ 第6話
契約書が見つからない問題の解決｜検索性を高める管理設計
「あの契約書、どこに保存したっけ？」——この一言が出た瞬間、それは単なる整理不足ではありません。契約管理が機能していないサインです。
契約書が見つからないことは、更新漏れ・監査対応遅延・紛争時の証拠滅失といった実務リスクに直結します。内部統制の観点からも、「保管している」と「探せる」は全く別物です。
本記事では、ファイル命名ルール・フォルダ構成・契約台帳との紐付け・OCR・タグ設計・権限管理まで、契約書の検索性を体系的に高める実務設計を整理します。契約管理シリーズ第5話「保管方法」から一歩進んで、「見つける」ための設計を保存版として解説します。
リーガルテック
補足：
法務部や総務部の作業は、
この無料ツールを使うと便利に処理できます
（一次整理・マスキング・論点整理など）
まず結論｜契約書は「保管」ではなく「検索できる状態」にする
🔑 この記事の3つの核心
- 「保管している」と「探せる」は別物——ファイルがあっても見つからなければ存在しないに等しい。
- ファイル命名・フォルダ・台帳紐付け・OCR・タグ・権限の6層設計が必要——どれか一つの対策では検索性は上がらない。
- 監査・紛争・更新対応で「5分以内に契約書を提出できる」を実務上の目標基準にする——電子帳簿保存法の検索要件対応も含めた実務設計の起点にしてください。
本記事の設計は、Excel＋共有フォルダでの運用でも実行可能です。ただし契約件数・部署数が増えた場合の限界も明示します。
なぜ契約書が見つからなくなるのか
契約書が見つからない問題は、「整理していないから」だけでは説明できません。担当者が替わった、システムを乗り換えた、電子契約と紙契約が混在しているなど、構造的な原因が複合的に重なることで発生します。
| 原因 | 起きる問題 | 改善策 |
|---|---|---|
| 紙原本の保管場所が分からない | 監査・訴訟時に原本提出できない | 台帳にキャビネット番号・棚番号を記録 |
| PDFが個人PCに保存されている | 担当者退職後に完全消失するリスク | 共有フォルダ/クラウドストレージへの保存を義務化 |
| 共有フォルダの階層が深すぎる | ファイルの場所を覚えていないと探せない | フォルダ階層を3層以内に設計する |
| ファイル名が統一されていない | ファイル名検索・並び替えが機能しない | 命名規則を策定し入力フォームで統制 |
| 契約相手方名の表記ゆれがある | 同じ取引先の契約が分散して見つからない | 正式社名の統一リストを作成・プルダウン化 |
| 契約類型が分類されていない | 「何の契約か」で絞り込めない | 契約類型マスタを作成して統制 |
| 原契約と覚書が別フォルダにある | 変更内容の追跡ができない | 覚書は原契約番号で紐付けて同一文脈で管理 |
| 電子契約サービス内だけに保存されている | 全社検索できない・サービス切替時に喪失リスク | 完了書類を別途ダウンロードして台帳に記録 |
| スキャンPDFがOCR化されていない | 全文検索がヒットしない | OCRツールで処理してテキスト情報を付与 |
| アクセス権限が不適切 | 必要な人が探せない／機密情報が漏洩 | 役割ベースで権限設計（RBAC） |
| 契約台帳とファイルが紐付いていない | 台帳を見てもファイルにたどり着けない | 台帳にPDF保管場所URLを記録・リンク化 |
| 担当者退職後に所在不明になる | 引き継ぎが機能せず契約管理が断絶する | 個人依存ではなく組織単位での管理を徹底 |
契約書が見つからないことは、内部統制・監査・紛争対応上の重大リスクです。「たぶんどこかにある」では、税務調査や紛争時に取り返しのつかない事態になりえます。
契約書検索性の基本設計
契約書の検索性を高めるには、ファイル命名・フォルダ構成・台帳紐付け・OCR・タグ・権限の6層を体系的に設計する必要があります。どれか一つだけ対応しても限界があります。
検索性を高める管理項目一覧
| 管理項目 | 検索に使う場面 | 入力例 | 注意点 |
|---|---|---|---|
| 管理番号 | ファイル名との紐付け・特定 | CTR-2026-001 | 採番ルールを統一し欠番を出さない |
| 契約名 | 案件名・業務内容での検索 | 〇〇システム開発業務委託契約 | 略称・通称を使わず正式名称で登録 |
| 契約相手方 | 取引先名での横断検索 | 株式会社〇〇（法人番号記載推奨） | 正式名称で統一。旧社名・略称との対応表を別管理 |
| 契約類型 | NDA・委託・請負など類型での絞り込み | 業務委託契約（準委任型） | プルダウン候補を決めて自由入力禁止 |
| 締結日 | 時系列での確認・版管理 | 2026-04-01 | YYYY-MM-DD形式で統一 |
| 契約開始日 | 有効期間の起算点確認 | 2026-04-01 | 締結日と開始日が異なる契約に注意 |
| 契約終了日 | 更新期限管理・失効管理 | 2027-03-31 | 自動更新の場合は終了日を「更新通知期限」で管理 |
| 自動更新の有無 | 更新アラートの要否判断 | あり（通知期限：3か月前） | 通知期限を別項目で管理するとアラート設計が容易 |
| 担当部署 | 部署別の契約一覧・権限設計 | 営業部第二課 | 組織改編時にマスタ更新を忘れない |
| 契約責任者 | 確認・問い合わせ先の特定 | 田中太郎（営業部長） | 退職・異動時の更新ルールを設ける |
| 原本保管場所 | 紙原本の提出・確認 | 法務室 キャビネットA-3段目 | 「法務部保管」では不十分。棚番号まで特定 |
| PDF保管場所URL | 台帳から直接ファイルを開く | SharePoint/契約書/2026/…へのリンク | リンク切れ定期確認が必須 |
| 電子契約URL | 電子契約サービスの当該契約ページ | 電子契約サービスの契約URL（例：サービス内の当該契約ページ） | サービス外でも証明書類をダウンロード保存する |
| 原契約管理番号 | 覚書・変更契約の原契約特定 | CTR-2026-001 | 原契約との親子関係を明確にする |
| 覚書番号 | 変更履歴の管理 | CTR-2026-001-M01 | 何回目の変更かを番号で管理 |
| 最新版フラグ | 覚書・変更後に有効な版の特定 | 最新版 / 旧版 | 覚書締結後に旧版フラグを必ず更新 |
| 契約ステータス | 有効・終了・交渉中での絞り込み | 有効 / 終了 / 審査中 / 保留 | ステータス変更時のトリガーを定める |
| キーワード・タグ | 属性・特徴での自由検索 | NDA / 個人情報あり / 自動更新あり | タグの統制は後述のタグ設計表を参照 |
ファイル命名ルール
ファイル名だけで契約書を探す時代は終わっています。しかし、ファイル名が乱れていると台帳との紐付けが崩れ、フォルダ検索も機能しません。命名ルールは「台帳管理番号との一致」を最優先に設計します。
推奨命名形式
# 基本形式
管理番号_締結日_相手方名_契約類型_版数.pdf
# 例①：業務委託契約
CTR-2026-001_2026-04-01_株式会社〇〇_業務委託契約_v1.pdf
# 例②：第1覚書
CTR-2026-001-M01_2026-08-01_株式会社〇〇_業務委託契約_第1覚書_v1.pdf
# 例③：NDA
CTR-2026-002_2026-04-15_△△株式会社_秘密保持契約_v1.pdf
命名ルール詳細
| ルール | 内容 | 理由・注意点 |
|---|---|---|
| 管理番号を先頭に置く | CTR-2026-001 など台帳番号と完全一致 | ファイル名ソート時に管理番号順に並ぶ。台帳との突合が容易 |
| 日付はYYYY-MM-DD形式 | 2026-04-01（ハイフン区切り） | 日本式（令和〇年〇月〇日）や20260401形式は混在を生む |
| 法人名は正式名称で統一 | 株式会社〇〇（略称・英語表記禁止） | 表記ゆれは台帳検索を崩す最大の原因。正式名称マスタを活用 |
| 契約類型はプルダウン候補と一致 | 業務委託契約 / 秘密保持契約 / 基本取引契約 など | 自由入力を許すと「委託契約」「業務委託」「BPA」が混在する |
| 版数はv1/v2で管理 | 審査中の修正版はv1→v2と増分する | 締結後の正式版をv1とし、審査中ドラフトはdraft_v1等で区別する |
| 「最終」「最新版」「FIX」は禁止 | 使用禁止ワードとして明示的にルール化 | 「最終版FIX」より新しいファイルが必ず出現し混乱を招く |
| 覚書は原契約番号＋M01形式 | CTR-2026-001-M01、M02と連番管理 | 覚書単体で保存すると原契約との関係が不明になる |
フォルダ構成の設計
フォルダ構成は「どの軸で整理するか」が設計の核心です。一つの軸だけでは限界があるため、階層型＋検索型のハイブリッド設計が現在の標準です。ただし、ファイル実体を複数フォルダに重複保存することは厳禁です（混乱と容量増大の原因になります）。
フォルダ構成比較表
| 構成タイプ | メリット | デメリット | 向いている会社 | 注意点 |
|---|---|---|---|---|
| 年度別フォルダ | 締結年が明確。時系列で管理しやすい | 取引先・類型では探せない | 契約件数が少ない小規模組織 | 年度をまたぐ長期契約の扱いを決める |
| 契約類型別フォルダ | NDA・委託・請負など類型で一覧しやすい | 取引先・年度では探しにくい | 法務部門が一元管理する場合 | 類型マスタが崩れると分類が乱れる |
| 取引先別フォルダ | 取引先との全契約を横断確認しやすい | 社名変更・合併時に再整理が必要 | 取引先数が少ない・深い取引先がある | 表記ゆれ対策が必須 |
| 部署別フォルダ | 各部署が自分の契約を管理しやすい | 全社横断検索ができない | 分権型組織・部署自己完結型 | 法務部がレビューできない死角が生まれやすい |
| 管理番号別フォルダ | 台帳との紐付けが最も明確 | 番号を知らないと探せない | 台帳管理が確立している組織 | 台帳なしでは使いものにならない |
| ハイブリッド型 | 複数の軸で探せる・柔軟性が高い | 設計の複雑さ・ルール維持コスト | 中規模以上・部署数が多い組織 | ファイル実体は一か所に置き、リンクで参照する |
推奨フォルダ構成例
/契約書（ルートフォルダ）
/有効契約
/2026
/01_業務委託
CTR-2026-001_2026-04-01_株式会社〇〇_業務委託契約_v1.pdf
CTR-2026-001-M01_2026-08-01_株式会社〇〇_業務委託契約_第1覚書_v1.pdf
/02_秘密保持
/03_基本取引契約
/04_請負契約
/05_その他
/2025
/終了契約
/2024以前
※ファイル実体は年度×類型フォルダに一つだけ置く
※取引先別ビューは台帳の検索機能で代替する
ファイル実体を「取引先フォルダにも、年度フォルダにも」と二重保存すると、覚書や最新版の更新漏れが必ず発生します。ファイルの場所は一か所に統一し、台帳の検索機能で複数軸の検索を実現することが基本原則です。
契約台帳との紐付け
フォルダ設計とファイル命名がいくら整っていても、契約台帳とPDFファイルが紐付いていなければ、台帳を見てもファイルにたどり着けません。台帳は「索引」として機能させることが設計の目的です。
契約台帳との紐付けルール
| ルール | 具体的な実装方法 | チェックポイント |
|---|---|---|
| 管理番号とファイル名を完全一致させる | 台帳の管理番号欄＝ファイル名の先頭番号 | 台帳登録時に即ファイル名を確定する運用にする |
| 台帳にPDF保管場所URLを記録する | SharePoint/Drive等のファイルパスまたはURL | クリック一発でファイルが開けるリンクにする |
| 紙原本の保管場所も台帳に記録する | 「法務室 キャビネットA 3段目」など詳細に | 「法務部保管」のような曖昧表記は不可 |
| 電子契約サービスURLも台帳に記録する | 電子契約サービスの契約URLを台帳に記録 | 完了書類・署名証明書は別途ダウンロード保存必須 |
| 原契約と覚書を管理番号で紐付ける | 覚書レコードに「原契約管理番号」列を設ける | 原契約から覚書一覧を確認できる設計にする |
| 最新版フラグを設ける | 覚書締結後、旧版に「旧版」フラグを付与 | 「最新版」が一意に特定できる状態を維持 |
| 契約ステータスと保管状態を連動させる | 「終了」ステータスになったら終了フォルダへ移動 | 有効契約フォルダに終了済みファイルが残らないようにする |
| 台帳から1クリックでPDFを開ける状態にする | ExcelのHYPERLINK関数またはシステムのリンク機能 | URLのパス変更時にリンク切れしないか定期確認 |
| リンク切れ確認を定期実施する | 四半期に1回、台帳のリンクを全件確認 | フォルダ移動・ファイル名変更後に必ず確認 |
OCR・全文検索の活用
紙でかわした契約書をスキャンしてPDF化するだけでは不十分です。スキャンPDF（画像PDF）は全文検索の対象になりません。OCR（光学文字認識）処理を施してテキスト情報を付与することで初めて「全文検索できるPDF」になります。
OCR・全文検索チェック表
| 確認項目 | 状態 | 対応策 |
|---|---|---|
| スキャンPDFが画像PDFのままになっていないか | 要確認 | Adobe Acrobat・DocuWorks等でOCR処理を実施 |
| OCR処理されているか（テキスト選択できるか） | 確認済 | PDF上でCtrl+Aでテキスト全選択できれば完了 |
| 文字検索でキーワードにヒットするか | 確認済 | 「秘密保持」等のキーワードでCtrl+F検索して確認 |
| 押印ページ・別紙もOCR対象に含まれているか | 要確認 | 別紙・添付書類も同一PDFに結合してOCR処理する |
| 契約相手方名で検索できるか | 確認済 | OCRの文字認識精度が低い場合は再スキャン |
| 契約条項名（例：損害賠償・秘密保持）で検索できるか | 確認済 | — |
| 金額・期限で検索できるか | 確認済 | 数字はOCRエラーが出やすいため目視確認推奨 |
| PDFの画質が低すぎないか（200dpi以上推奨） | 要確認 | 200dpi以下では文字認識精度が著しく低下する |
| 電子契約の署名証明書も保存されているか | 要確認 | 電子契約サービスからダウンロードして台帳と紐付ける |
| 全文検索ツール・クラウドストレージと連動しているか | 確認済 | SharePoint・Boxの全文検索機能がOCR済みPDFで機能するか確認 |
SharePoint・Google Drive・Boxなどの主要クラウドストレージは、アップロードしたPDFを自動でOCR処理する機能を持っています。ただし日本語の認識精度にばらつきがあるため、重要な契約書は事前にAdobe Acrobat等でOCR処理してからアップロードすることを推奨します。
電子帳簿保存法（電帳法）は、スキャン保存した書類について「取引年月日・金額・取引先」での検索ができることを要件としています（同法第7条等）。法令上の要件という観点からも、OCR化と台帳項目の整備は義務的な対応です。契約書が税務調査の対象になった際に「検索できない」状態は、法令違反のリスクを伴います。経理担当者とも連携して設計してください。
タグ・メタデータ設計
ファイル名・フォルダ・台帳項目だけでは表現できない「属性情報」を補完するのがタグです。「自動更新あり」「個人情報あり」「反社条項なし」など、レビュー時に気づいた属性をタグ化しておくことで、後から「問題のある契約を抽出する」作業が格段に速くなります。
タグ・メタデータ設計表
| タグ | 目的 | 使う場面 | 注意点 |
|---|---|---|---|
| NDA | 秘密保持契約の横断抽出 | 情報開示範囲の確認・更新管理 | 契約類型と重複するが検索速度向上のために残す |
| 業務委託 | 委託契約の一覧抽出 | 取適法対応・印紙税確認 | 請負型か準委任型かをサブタグで区別推奨 |
| 基本契約 | 基本取引契約書の一覧 | 個別契約との紐付け確認 | 第7号文書の印紙税対象確認に使う |
| 請負 | 請負契約の抽出 | 印紙税額確認・工事完成責任の確認 | 準委任と請負の混在に注意 |
| 準委任 | 委任型業務委託の抽出 | 成果物責任の有無確認 | 契約審査時に請負と混同しやすい |
| 個人情報あり | 個人データを扱う契約の一覧 | 個人情報保護法対応・DPA確認 | 委託先の安全管理措置確認義務（個人情報保護法24条）に対応 |
| 自動更新あり | 自動更新条項がある契約の抽出 | 更新通知期限管理・アラート設定 | 通知期限の日数（例：3か月前）を台帳に必ず記載 |
| 高額契約 | 一定金額以上の契約の管理強化 | 稟議・承認フロー確認・役員報告 | 金額しきい値の社内基準を定める（例：1,000万円超） |
| 反社条項なし | 暴力団排除条項が入っていない契約の特定 | コンプライアンス対応・再審査 | 旧来の契約には未記載が多い。更新時に追加する |
| 印紙税確認済 | 印紙税の要否確認が完了した契約 | 監査対応・税務調査対応 | 確認者・確認日も台帳に記録するとより確実 |
| 電子契約 | 電子契約で締結した契約の一覧 | 印紙税不要確認・証明書管理 | 電子→紙に変換した場合は印紙税が発生する |
| 紙原本あり | 紙原本が存在する契約の特定 | 原本提出・保管場所確認 | 紙原本の保管場所を台帳に必ず記録する |
| 覚書あり | 変更覚書が存在する原契約の特定 | 最新版の確認・変更内容の追跡 | 覚書締結後に原契約レコードにフラグを追加する |
| 更新注意 | 更新期限が近い契約の優先確認 | 更新要否の判断・通知送付 | 通知期限の60日前にフラグを立てる設計が有効 |
| 要再審査 | 条件変更・法改正対応が必要な契約 | 取適法・個人情報法改正への対応 | 再審査完了時にフラグを解除するルールを設ける |
権限管理と検索性のバランス
「検索できること」と「セキュリティ」は相反するように見えますが、設計次第で両立できます。権限を全開放すれば誰でも探せますが情報漏洩リスクが生じ、絞りすぎると必要な人が探せなくなります。役割ベースの権限設計（RBAC）が基本原則です。
権限管理設計表
| ロール | 閲覧権限 | 編集権限 | ダウンロード可否 | 注意点 |
|---|---|---|---|---|
| 法務管理者 | 全件・全類型 | 全件 | 可 | 変更操作の監査ログが必須 |
| 法務担当者 | 全件（機密区分除く） | 自担当分のみ | 可（機密除く） | 他部署の秘密条件付き契約は要別設定 |
| 営業担当者 | 自部署分のみ | 不可 | 可（自部署分） | 他社との契約条件を誤開示しないよう注意 |
| 所管部署責任者 | 自部署全件 | 不可 | 可 | 部署管理者権限で範囲を定義する |
| 経理担当者 | 金額・支払条件関連のみ | 不可 | 条件次第 | NDA・知財条項は経理業務に不要なため非表示推奨 |
| 監査担当者 | 全件（閲覧のみ） | 不可 | 可（監査目的） | 監査目的でのダウンロードはログ記録必須 |
| グループ会社担当者 | 当該グループ会社分のみ | 不可 | 条件次第 | グループ間の秘密区分を設計段階で決定する |
| 外部共有不可 | 社内限定（外部共有リンク禁止） | — | 不可（外部） | M&A関連・競合他社情報含む契約に設定 |
権限設計の実務ポイント：監査ログ（誰がいつ何を閲覧・ダウンロードしたか）は必ず記録する設計にしてください。SharePoint・Boxは標準機能で監査ログが取れます。権限変更の申請・承認フローも文書化しておくと内部統制に有効です。
よくある失敗パターン
| 失敗パターン | 何が起きるか | 正しい対策 |
|---|---|---|
| ファイル名が「契約書.pdf」だけ | 何の契約かすら分からない。検索不能 | 命名規則を策定しシステム・フォーム側で強制 |
| 「最終版」「最新版」「FIX」が乱立する | どれが本当の最新版か判別不能になる | v1/v2形式の版数管理に統一。禁止ワードを明記 |
| 相手先名が略称・旧社名・正式名で混在する | 同一取引先の契約が分散して見つからない | 正式名称マスタを作成・プルダウン管理に移行 |
| 契約台帳にはあるがPDFが見つからない | 台帳として機能しない。紛争時に致命的 | 台帳登録時にファイルリンクを必須入力にする |
| PDFはあるが紙原本が見つからない | 原本提出が必要な場面で詰まる | 原本保管場所を台帳に記録し棚番号まで特定 |
| 覚書だけ別フォルダにある | 原契約と覚書の関係が追跡できない | 覚書は原契約番号で紐付けて同一文脈で管理 |
| 電子契約サービスごとに検索が分断される | 複数サービスを横断検索できない | 全電子契約の完了書類を一元保存先にDL保管 |
| OCR化されておらず全文検索できない | 条項名・金額・期限で検索がヒットしない | スキャンPDFは全件OCR処理を実施 |
| アクセス権限が厳しすぎて現場が探せない | 「法務に聞かないと探せない」が常態化 | 部署単位で閲覧権限を設計し自己完結できる設計に |
| 権限が広すぎて機密契約が見えてしまう | M&A・競合他社情報の漏洩リスク | 機密区分を設け、機密契約は法務管理者のみ閲覧可 |
| 退職者の個人フォルダに契約書が残る | 退職後に所在不明・アクセス不能になる | 個人フォルダへの保存禁止と退職時チェックを徹底 |
| リンク切れで台帳から開けない | 台帳が使い物にならない。信頼性が失われる | 四半期ごとのリンク切れチェックを定例化 |
検索できる契約管理チェックリスト
📋 Checklist｜今すぐ確認できる14項目
- 契約台帳に管理番号がある
- PDFファイル名に管理番号が入っている
- 相手方名が正式名称で統一されている
- 契約類型がプルダウン候補で統一されている
- PDF保管場所URLが台帳にあり1クリックで開ける
- 紙原本の保管場所（棚番号まで）が台帳にある
- 原契約と覚書が管理番号で紐付いている
- 「最新版」が一意に特定できる
- スキャンPDFがOCR化されてテキスト検索できる
- 電子契約の完了書類・署名証明書が別途保存されている
- 役割ベースのアクセス権限が設定されている
- 閲覧・ダウンロードの監査ログが残る
- リンク切れチェックを四半期ごとに実施している
- 5分以内に任意の契約書を提出できる
システム化による解決
Excel＋共有フォルダでの運用は、契約件数50件程度・担当者1〜2名の範囲では十分機能します。しかし、契約件数が100件を超え、複数部署が関与し、覚書が増え、グループ会社も対象になってくると、Excelの限界が顕在化します。
Excel管理とシステム管理の限界比較
| 課題 | Excel＋共有フォルダ | 契約管理システム（LegalOS等） |
|---|---|---|
| 台帳からPDFへのリンク | HYPERLINK関数で可能。リンク切れリスクあり | システム内で一体管理。リンク切れなし |
| 全文検索 | 不可（台帳の入力項目内検索のみ） | 台帳項目（相手方名・類型・期限・タグ等）での多軸検索に対応。OCR済みPDFへのリンクから全文確認も容易 |
| 更新期限アラート | 手動管理。カレンダー連携は別途設定が必要 | 自動アラート・メール通知が標準機能 |
| 原契約と覚書の紐付け | 列管理で可能だが視覚的に把握しにくい | 親子構造で直感的に管理・一覧表示 |
| 権限管理 | フォルダ権限で大まかな制御のみ | 契約単位・項目単位の細かな権限設定 |
| 監査ログ | なし（SharePoint等で補完可能） | 操作ログが自動記録される |
| グループ会社横断管理 | 別ファイルで管理。統合は手作業 | グループ全社を一元管理・横断検索 |
| 契約審査ワークフロー | メール・Teamsで代替。証跡管理が難しい | 申請・承認・差し戻しフローを内包 |
🔍 Contract Management Tool
LegalOS｜契約書を「探せる状態」にする法務DXツール
契約台帳管理・契約書ファイルとの紐付け・契約書検索・更新期限アラート・原契約と覚書の紐付け・契約審査ワークフロー・契約ステータス管理・証跡保存・監査ログ・グループ会社横断管理を一体的に支援します。
「5分以内に任意の契約書を提出できる」状態を実現するための設計で、Excel管理から卒業する最初の一歩に最適です。
よくある質問
Q1契約書が見つからない原因は何ですか？
主な原因は、①ファイル名が統一されていない、②個人PCや電子契約サービス内だけに保存されている、③契約台帳とPDFが紐付いていない、④スキャンPDFがOCR化されていない、⑤アクセス権限が不適切、の5つです。これらが複合的に重なることで「保管しているのに見つからない」という状態が生まれます。
「保管している」と「探せる」は別物です。管理設計の見直しから始めてください。
Q2契約書のファイル名はどう付けるべきですか？
推奨形式は「管理番号_締結日_相手方名_契約類型_版数.pdf」です。例：CTR-2026-001_2026-04-01_株式会社〇〇_業務委託契約_v1.pdf。「最終版」「最新版」「FIX」などのファイル名は禁止し、版数はv1/v2形式で管理します。覚書は原契約番号＋M01/M02で管理します。
ファイル名の先頭に管理番号を置くことで、契約台帳との突合が容易になり、ソート時にも管理番号順に並びます。
Q3契約書は取引先別と契約類型別のどちらで保管すべきですか？
フォルダ構成は「年度＋契約類型」のハイブリッド型が実務上最も使いやすいです。ただし取引先別の検索は、台帳に相手方名を記録して台帳検索で実現する設計が合理的です。ファイル実体を複数フォルダに重複保存することは、更新漏れの原因になるため厳禁です。
フォルダは「ファイルを格納する場所」として最低限の構成にし、多軸の検索は台帳・システムで実現するのが現代の設計原則です。
Q4紙契約はどう検索できるようにすべきですか？
スキャンしてPDF化したうえで、必ずOCR処理を施してテキスト検索できる状態にします。スキャン時は200dpi以上で取り込み、押印ページ・別紙も同一PDFに結合してOCR処理します。紙原本の保管場所（キャビネット番号・棚番号）は契約台帳に必ず記録します。
スキャンした画像PDFをそのまま保存しても全文検索できません。OCR処理は「デジタル化」の完了条件と考えてください。
Q5スキャンPDFはOCR化すべきですか？
必須です。スキャン直後の画像PDFは「画像ファイル」と同じで、キーワード検索のヒット対象になりません。Adobe Acrobat・DocuWorks・スキャナ付属ソフトウェア等でOCR処理することで、条項名・金額・期限・相手先名での全文検索が可能になります。
既存の紙契約書のOCR化は一括処理サービスを活用すると効率的です。今後のスキャン時はOCR処理を標準フローに組み込んでください。
Q6電子契約サービスに保存していれば十分ですか？
十分ではありません。電子契約サービス内だけに保存すると、①全社的な一元検索ができない、②サービスを切り替えた際に過去契約へのアクセスが困難になる、③複数サービスを使っている場合に横断検索できない、という問題が生じます。完了書類・署名証明書は別途ダウンロードして共有フォルダや契約管理システムにも保存し、台帳にURLを記録することが必要です。
電子契約サービスは「締結ツール」であり「契約管理システム」ではありません。両者を区別して設計することが重要です。
Q7覚書は原契約と同じフォルダに置くべきですか？
原則として同一フォルダに置くことを推奨します。ファイル名に原契約管理番号＋M01/M02の形式を使い、台帳では「原契約管理番号」欄で親子関係を記録します。覚書だけが別フォルダに存在する状態は、「原契約と覚書を合わせて最新の契約条件を把握する」という基本操作ができなくなります。
覚書締結後は、原契約レコードの「覚書あり」フラグと「最新版フラグ」も更新することを忘れないでください。
Q8アクセス権限はどう設計すべきですか？
契約類型・部署・機密度の3軸で権限を設計します。全開放は情報漏洩リスクがあり、絞りすぎると現場が探せなくなります。基本は、①所管部署担当者は自部署分を閲覧可・編集不可、②法務担当者は全件閲覧可・自担当分編集可、③監査担当者は全件閲覧のみ・監査ログ記録、という3層設計から始めます。
権限変更の申請・承認フローと監査ログの記録は内部統制上必須です。SharePoint・Boxは標準機能で対応できます。
Q9LegalOSで契約書検索はできますか？
はい。LegalOSでは契約台帳の管理番号・相手方名・契約類型・期限・タグなどで検索でき、PDFファイルへのリンク・原契約と覚書の紐付け・契約ステータス管理・更新期限アラートを一体的に管理できます。監査ログ・権限設計・グループ会社横断管理にも対応しています。
Excel管理から移行する際の設計サポートも提供しています。詳細はLegalOSの詳細ページをご確認ください。
まとめ
本記事では、「契約書が見つからない問題」を単なる整理不足ではなく、管理設計の問題として体系的に整理しました。
📌 この記事のまとめ
- 「保管している」と「探せる」は別物——検索できる状態にして初めて契約管理が機能する
- ファイル命名・フォルダ・台帳紐付け・OCR・タグ・権限の6層設計が検索性向上の基本構造
- ファイル名は「管理番号_締結日_相手方名_契約類型_版数.pdf」で台帳と完全一致させる
- スキャンPDFは必ずOCR処理——画像PDFのままでは全文検索できない
- 電子契約サービスへの保存だけでは不十分——完了書類の別途保存と台帳記録が必要
- 権限は全開放でも絞りすぎてもいけない——役割ベースの3層設計から始める
- 監査・紛争・税務調査で「5分以内に契約書を提出できる」を実務上の目標基準にする——電帳法の検索要件対応も含めた設計の起点として活用してください
次の第7話では、契約審査フロー設計｜属人化を防ぐワークフローの作り方を解説します。「検索できる」状態が整ったら、次は「審査プロセスを属人化しない」設計に進みます。
関連記事｜契約管理シリーズ
第1話
契約管理とは何か｜なぜExcel管理では限界なのかを実務視点で解説
契約管理 / Excel / 属人化
第2話
契約台帳の作り方｜最低限必要な項目一覧と実務で使える設計
契約台帳 / 管理項目 / 設計
第3話
契約台帳テンプレート｜Excel運用の限界とよくある失敗例
テンプレート / 失敗例 / 改善
第4話
契約更新管理の実務｜更新漏れを防ぐ仕組みとアラート設計
更新管理 / アラート / 自動更新
第5話
契約書の保管方法｜紙・PDF・電子契約の整理と実務対応
保管方法 / 電子契約 / 紙原本
第7話
契約審査フロー設計｜属人化を防ぐワークフローの作り方
審査フロー / ワークフロー / 属人化防止
第8話
契約変更・覚書管理｜原契約との紐付けと履歴管理の実務
覚書 / 変更契約 / 履歴管理
第11話
契約管理システムの選び方｜比較ポイントと導入判断
システム選定 / 法務DX / 比較
関連シリーズも合わせてご活用ください
関連シリーズ
契約審査シリーズ｜Legal GPT
契約審査 / チェックポイント / 実務
関連シリーズ
印紙税シリーズ｜Legal GPT
印紙税 / 課税文書 / 電子契約
関連シリーズ
業務委託契約シリーズ｜Legal GPT
業務委託 / 請負 / 準委任
有料コンテンツ
実務プロンプト集｜契約管理・台帳設計・契約審査対応
プロンプト / AI活用 / 法務DX
📋 Legal DX Tool
契約書管理は「保管」から「検索できる」へ
契約書管理では、「保管している」だけでは不十分です。必要なときに、必要な人が、正しい最新版をすぐに見つけられることが重要です。
LegalOSでは、契約台帳管理・契約書ファイルとの紐付け・契約書検索・更新期限アラート・原契約と覚書の紐付け・契約審査ワークフロー・契約ステータス管理・証跡保存・監査ログ・グループ会社横断管理を一体で支援します。
また、有料プロンプト集では、契約書検索性改善・契約台帳設計・契約審査・社内稟議作成に使える実務プロンプトを提供しています。
🔍 関連ガイドへ進む
この記事と関連度の高い実務ガイドをまとめています。次に読むならこちら。
