「何を書くか」より「どう並べるか」

プレイブック、例外台帳、絶対NG集、事例集——自社の判断知を言語化しても、それらを「どう並べるか」が雑だと、生成AIに「この案件に適用される基準の全体」を正しく渡せません。余計なファイルを渡せばノイズになり、不足すれば基準が抜けます。

フォルダ設計は、地味ながら自社基準レビューの品質を左右します。本記事では、業務委託・NDA・売買・ライセンスの4類型を例に、類型ごとに適したフォルダの粒度と、全体を貫く設計原則を整理します。なお、「そもそもなぜ判断知を言語化して手元に置くのか」という上位の考え方（～4つの器・3つの置き場）は、本シリーズのピラー記事で整理しています。

設計原則：類型×立場のベース＋差分

フォルダ設計の骨格は、プレイブック設計と同じ「ベース×差分」です。類型×立場でベースを持ち、全類型共通の条項は_commonに分離し、個別の上乗せは差分ファイルで持ちます。

_common/
  一般條項.md（反社・準拠法・完全合意など全類型共通）
  秘密保持_基本.md
業務委託/
  業務委託_受託.md
  _発注.md（類型ベース）
  + 開発委託_受託.md（差分）
NDA/
  NDA_双務.md
  _受領側.md
  _開示側.md
売買/
  売買_買主.md
  _売主.md
  + 継続的売買基本取引.md（差分）
ライセンス/
  ライセンス_ライセンシー.md
  _ライセンサー.md

この原則を押さえた上で、類型ごとに「どの粒度まで深く作るか」を見ていきます。ポイントは、類型の複雑さに応じて粒度を変えることです。

類型別：適した粒度の違い

4類型を並べると、「ベースと差分をどこまで作るか」が類型ごとに明らかに違います。

業務委託は請負／準委任、部署の違い、偽装請負やフリーランス新法といった論点が多く、バリエーションが最も大きいため、差分を厚く作る価値があります。一方でNDAは、双務か片務か、開示側か受領側かという軸が主で、比較的シンプルです。売買は買主／売主の立場と、継続取引の場合の下請法・独禁法の発火が重要な軸になります。ライセンスは独占／非独占、改変・再許諸の可否が中心軸です。

このように、フォルダの深さは類型の複雑さを反映してばらつきます。「全類型を同じテンプレートで揃える」という発想は、むしろ運用を重くします。類型ごとに、必要な粒度だけ作るのが原則です。

「全部CLMに入れる」ではなく、手元に軽く持つ

ここでよくある誤解が、「フォルダをCLMの中に作ればよい」というものです。しかしプレイブックや例外台帳といった判断知は、特定のCLMツールの中だけに閉じ込めると、そのツールを乗り換えたときに資産が死にます。

現実的な設計は、次の役割分担です。

• フォルダ（判断知）は手元のテキストに軽く持つ：Markdownファイルでバージョン管理し、生成AIにそのまま渡せる状態にしておく
• 契約データの正本はCLMに一元化：契約書本体・関連契約・取引先マスタは、案件ごとに動く「事実」としてCLMで管理する
• 案件IDで両者を紐づける：レビュー時に、生成AIが「案件の事実（CLM）＋該当するフォルダ（手元）」を連結して読み込む

この「データは一元・判断知は手元・AIは自社で選ぶ」という設計は、オープン型CLMの考え方そのものです（詳細はOpenCLMとは？ChatGPT/Claude時代のCLM選定基準）。一例としてContractS CLMは、この設計を採用しています。

フォルダをAIに渡すときの選択ロジック

フォルダを作ったら、レビュー時に「どのファイルをAIに渡すか」の選択ロジックが必要になります。これもシンプルに設計できます。

1. 類型を判定：案件が「業務委託」か「売買」かを判定（AIに一次判定させてもよい）
2. 立場を確定：自社が発注か受注か、買主か売主かを確定し、対応するベースを選ぶ
3. 差分を加える：「開発委託」など該当する差分ファイルを上乗せする
4. 共通を連結：_commonの一般條項を加える
5. 本体を渡す：CLMから取得した契約書本文と、上記をまとめてAIに渡す

この順序でファイルを連結すれば、AIには「この案件に適用される基準の全体」が過不足なく渡ります。類型・立場ごとのレビュー手順やプロンプトの具体例は、生成AIで「業務委託契約」をレビューする手順とプロンプト集もあわせて参照してください。

フォルダ設計でよくある誘惑と回避策

最後に、フォルダ設計で険りがちな3つの誘惑を、回避策とともに整理します。

一つ目は、「とりあえず類型だけで分ける」。業務委託を一枚にまとめると、発注／受注の「あるべき姿が反転する論点」が混ざり、AIがチューニングしにくくなります。類型だけでなく「類型×立場」でベースを分けるのが原則です。

二つ目は、「全部の類型を一気に作ろうとする」。類型を網羅しようとして锨折するより、頪度が高くバリエーションの大きい類型（業務委託・売買）から着手し、効果を確かめてから拡げるのが現実的です。

三つ目は、「共通条項を各ファイルにコピーする」。反社や準拠法などを類型ごとに書き込むと、一つの法改正で全ファイルを直すことになります。必ず_commonに分離し、連結して使います。

まとめ：フォルダは「類型の複雑さ」に合わせて設計する

契約タイプ別のフォルダ設計は、自社基準を生成AIに正しく渡すための「並べ方」の設計です。

原則は「類型×立場のベース＋差分」。その上で、業務委託・売買のようにバリエーションが大きい類型は差分を厚く、NDAのように定型的な類型は軽く。そしてフォルダはCLMの中に閉じ込めず、手元のテキストに軽く持ち、案件IDでCLMの契約データと紐づける。

この設計によって、プレイブック・例外台帳・絶対NG集・事例集という判断知が、類型ごとに整理され、生成AIがレビュー時に正しく参照できる状態になります。「AIは選び、契約は1箇所に集める」——フォルダ設計は、その「集めた契約」と「手元の判断知」を、AIが迷わずに突合できるようにするための、地味だが効く土台です。

本記事はContractS株式会社のコンテンツマーケティングチームが、エンタープライズ企業の法務・調達・管理部門向けに執筆したものです。フォルダ設計の具体化にあたっては、必ず自社の業務特性・取扱う契約類型に応じて検討してください。本記事はリーガルアドバイスではありません。

ContractS編集部

ContractSは、契約プロセスの構築や契約管理・案件管理を通じて、契約業務を最適化するシステム「ContractS CLM」を開発・販売しています。大企業から中小企業、スタートアップまで、幅広い企業の契約業務改善を支援してきた実績があり、そのコンサルティング経験を活かして、契約業務に関わる読者が参考にできる情報を発信しています。

私たちについて