会社情報
採用情報
お問い合わせ
Article

無料で使える契約書管理サービス

高田晃太郎
無料で使える契約書管理サービス

World Commerce & Contracting（旧IACCM）の分析では、契約管理の不備が平均で約9%の価値損失を招くと報告されています¹。さらに、情報労働者が資料検索に費やす時間は勤務時間の2〜3割に達するという研究もあります²。各種の公開レポートと現場の観察を照らし合わせると、多くの企業で「契約書は存在するが、発見性と更新管理が弱く、監査対応に時間がかかる」状態が常態化しています。クラウドと電子署名の普及で解決策は増えましたが、「無料で使える契約書管理サービス」の現実解は、現場の制約次第で変わります。無料で始める選択肢は、無料SaaS（クラウドの無料プラン）、OSS（オープンソース）、自前スタックの三系統。どこまで無料でいけるのか、どこから有料（CLM: Contract Lifecycle Management）に舵を切るべきか。CTO視点で、実装と運用の手触りまで具体的に掘り下げます。

無料で始める契約書管理の現実解

無料で成立する範囲は明確に線引きできます。保管と検索はクラウドストレージやオープンソースの文書管理でほぼカバーできます。期限アラートや軽いワークフローはスクリプトとWebhook（SaaSが発火するイベント通知）で付けられます。電子署名は、無料プランがあるSaaSやオープンソースのeSignを組み合わせる発想が現実的です。逆に、条文テンプレートの高度な組版、承認マトリクスの複雑な分岐、締結後の義務管理ダッシュボード、監査対応の証跡一式などをノーコストで完全に満たすのは難しく、どこかで手作業か設計上の妥協を受け入れる必要があります。重要なのは「無料」の定義を誤解しないこと。無料プラン、無料枠、無料トライアル、OSS自前運用はコスト構造が異なります。前者は機能や件数に上限があり、後者はインフラ・保守・セキュリティの運用工数がコストとして顕在化します。

ここでの現実的な出発点はシンプルです。例えば従業員50名規模、月10〜30件の締結頻度なら、共有ドライブの秩序化＋軽量台帳＋無料eサイン＋Slack通知で、まずは「探せる・忘れない」を実現できます。要件が見えてきた段階で、CLMや有料プランに拡張するのが無駄の少ない動線です。

無料で成立する機能カバレッジと代表選択肢

リポジトリはGoogle DriveやOneDriveの組織アカウントで始められます。フォルダ構造を年度・相手方・契約種別で規律し、ファイル名規約とメタデータ台帳を持てば、検索の再現性が上がります。スキャンPDFの全文検索は、Paperless-ngxのようなOSSとTesseract OCR（画像から文字を起こす技術）で補えます。電子署名は、PandaDocのFree eSign（執筆時点の公式ガイドに「無制限のeサイン」等の記載）³、SignWellのFree（毎月の送信数に上限）、Zoho SignのFree（月間上限あり）⁴など、件数の少ないチームなら実務投入可能な選択肢があります。自前運用なら、DocuSealのようなオープンソースeサインをコンテナで立ててWebhook連携する方法もあります⁵。期限アラートはGoogle Apps Scriptや小さなCloud Run/Lambdaで日次バッチを回せば十分に機能します。アクセス制御はIdP（Identity Provider）連携でフォルダ単位に絞り込み、台帳側の閲覧権限を合わせます。無料枠に依存する運用では、監査証跡（署名プロセスのタイムライン、IP、ハッシュ）と長期署名の保持が落とし穴になりやすいため、事前に出力形式と保管方針を確認しておくと安全です。

法的有効性と注意点を先に押さえる

日本の電子署名法や各国のESIGN/EU eIDASに適合するかは前提条件です⁶。多くの無料プランは基礎的な適合要件への対応を表明しますが、長期検証可能なタイムスタンプ（PAdES LTV等。将来にわたり署名の有効性を検証できる拡張）や高度な本人確認（KYC/IDVの強い本人確認）は上位プランに限定されることがあります。締結証跡のエクスポート可否、データ所在地、バックアップ方法、退会時のデータ持ち出し条件は必ず事前に確認し、社内規程に落とし込んでから運用を開始してください。無料だからこそ、やめ方まで決めるのがコスト最小化の近道です。

エンジニアが最短で構築する無料スタック

ここからは、無料SaaSとOSSを組み合わせた最小構成と、運用を回すためのコード例を示します。前提として、契約書PDFは ./contracts/<year>/<counterparty>/<type>/ファイル.pdf に格納し、台帳はSQLiteかGoogleスプレッドシートのどちらかに持ちます。署名は無料のeサインSaaSを使い、完了Webhookで台帳を更新し、期限が近い契約はSlackに通知します。実装は小さく、可視性は高く、責務は分離するのが肝です。

コード例1：ファイルのハッシュと基本メタ生成（Python）

import os
import hashlib
import sqlite3
from datetime import datetime
from pypdf import PdfReader

DB = "contracts.db"
ROOT = "./contracts"

conn = sqlite3.connect(DB)
cur = conn.cursor()
cur.execute(
    """
    CREATE TABLE IF NOT EXISTS contracts (
      id TEXT PRIMARY KEY,
      path TEXT NOT NULL,
      counterparty TEXT,
      ctype TEXT,
      effective_date TEXT,
      end_date TEXT,
      sha256 TEXT NOT NULL,
      pages INTEGER,
      created_at TEXT
    )
    """
)

for dirpath, _, files in os.walk(ROOT):
    for f in files:
        if not f.lower().endswith(".pdf"):
            continue
        fp = os.path.join(dirpath, f)
        with open(fp, "rb") as fh:
            data = fh.read()
        sha256 = hashlib.sha256(data).hexdigest()
        reader = PdfReader(fp)
        pages = len(reader.pages)
        parts = fp.split(os.sep)
        # ./contracts/2025/Acme/NDA/file.pdf
        counterparty = parts[-3]
        ctype = parts[-2]
        cid = f"{counterparty}:{ctype}:{sha256[:16]}"
        cur.execute(
            "REPLACE INTO contracts(id, path, counterparty, ctype, sha256, pages, created_at) VALUES (?,?,?,?,?,?,?)",
            (cid, fp, counterparty, ctype, sha256, pages, datetime.utcnow().isoformat()),
        )

conn.commit()
conn.close()
print("indexed")

このスクリプトはファイルパスの規約とSHA-256で同一性を担保します。監査時はハッシュ値で原本性を示し、パス規約で人間の探索効率を担保します。

コード例2：スキャンPDFに対するOCR（Python）

import tempfile
from pdf2image import convert_from_path
import pytesseract

def ocr_pdf_to_text(pdf_path: str) -> str:
    images = convert_from_path(pdf_path, dpi=300)
    texts = []
    for img in images:
        txt = pytesseract.image_to_string(img, lang="jpn+eng")
        texts.append(txt)
    return "\n".join(texts)

if __name__ == "__main__":
    print(ocr_pdf_to_text("./contracts/2025/Acme/NDA/scan.pdf")[:1000])

OCRはCPUとメモリ消費が大きく、全文OCRを常時行うとコストと時間が膨らみます。まずは必要箇所（1ページ目や署名ページ）に限定する、夜間バッチに寄せるなどで現実的な運用に落とし込みます。

コード例3：更新期限の抽出と台帳反映（Python）

import re
import sqlite3
from dateutil import parser as dparser

DATE_PATTERN = re.compile(r"(\d{4})年(\d{1,2})月(\d{1,2})日")
TERM_PATTERN = re.compile(r"有効期限|満了日|更新日")

def extract_dates(text: str):
    dates = []
    for m in DATE_PATTERN.finditer(text):
        y, mth, d = m.groups()
        dates.append(f"{y}-{int(mth):02d}-{int(d):02d}")
    return dates

def infer_end_date(text: str):
    if TERM_PATTERN.search(text):
        dates = extract_dates(text)
        if dates:
            return dates[-1]
    try:
        dt = dparser.parse(text, fuzzy=True)
        return dt.date().isoformat()
    except Exception:
        return None

conn = sqlite3.connect("contracts.db")
cur = conn.cursor()
cur.execute("SELECT id, path FROM contracts WHERE end_date IS NULL")
for cid, path in cur.fetchall():
    # テキスト化はOCR済みまたはpypdf抽出結果を想定
    with open(path + ".txt", "r", encoding="utf-8", errors="ignore") as f:
        txt = f.read()
    end_date = infer_end_date(txt)
    if end_date:
        cur.execute("UPDATE contracts SET end_date=? WHERE id=?", (end_date, cid))
conn.commit()
conn.close()

抽出精度は契約種別や表現に左右されます。早期効果を狙うなら、まずは重要契約だけ人手で確認し、抽出ロジックは徐々に賢くする戦略が現実的です。

コード例4：期限接近をSlack通知（Python）

import os
import sqlite3
import requests
from datetime import date, timedelta

WEBHOOK = os.environ.get("SLACK_WEBHOOK_URL")
DAYS = int(os.environ.get("ALERT_DAYS", "60"))

conn = sqlite3.connect("contracts.db")
cur = conn.cursor()
cur.execute("SELECT id, counterparty, ctype, end_date FROM contracts WHERE end_date IS NOT NULL")
rows = cur.fetchall()

today = date.today()
msg_lines = []
for cid, cp, ctype, end_date in rows:
    d = date.fromisoformat(end_date)
    if 0 <= (d - today).days <= DAYS:
        msg_lines.append(f"{cid} | {cp} | {ctype} | 満了予定: {end_date}")

if msg_lines:
    text = "契約満了が近いもの:\n" + "\n".join(msg_lines)
    requests.post(WEBHOOK, json={"text": text})

conn.close()

アラートは「過剰」と「遅延」の戦いです。部門チャネルに投げっぱなしではなく、担当アサインと承認の最短経路を合わせて設計すると、通知疲れを避けられます。

コード例5：署名完了Webhookの受信（Node.js/Express）

import crypto from "crypto";
import express from "express";
import sqlite3 from "sqlite3";

const app = express();
app.use(express.json());
const SECRET = process.env.WEBHOOK_SECRET || "change-me";

function verify(sig, payload) {
  const hmac = crypto.createHmac("sha256", SECRET).update(payload).digest("hex");
  return crypto.timingSafeEqual(Buffer.from(sig), Buffer.from(hmac));
}

app.post("/webhook/esign", (req, res) => {
  const raw = JSON.stringify(req.body);
  const sig = req.header("x-hook-signature") || "";
  if (!verify(sig, raw)) return res.status(401).send("invalid signature");
  const { document_id, status, metadata } = req.body;
  if (status === "completed") {
    const db = new sqlite3.Database("contracts.db");
    db.run(
      "UPDATE contracts SET effective_date = COALESCE(effective_date, date('now')) WHERE id = ?",
      [metadata?.contract_id || document_id],
      () => db.close()
    );
  }
  res.send("ok");
});

app.listen(8080, () => console.log("listening on :8080"));

多くのeサインSaaSはWebhookと任意メタデータの往復をサポートします。テンプレート送信時にcontract_idを埋め、完了時に台帳側のキーで更新すれば、無料プランでも台帳整合性を保てます。

ベンチマークの現実感と運用の工夫

ローカルCPUでのパースは軽く、OCRは重い、が経験則です。手元検証の一例（Apple M2 Pro、Python 3.11）では、pypdfによるテキスト抽出のみの場合は1,000ファイル規模でも概ね1分あたり30〜50件、OCR有効時は1分あたり2〜3件が目安でした。スループットを上げるには、OCR対象を必要ページに限定し、夜間バッチに寄せ、そして新規ファイルの差分処理に絞ることが効果的です。無料枠内でのクラウド実行では、GCF/Cloud RunやAWS Lambdaのタイムアウトとメモリ上限に注意し、長時間のOCRはキューイングで分割してください。

セキュリティとコンプライアンスの落とし穴

契約書は個人情報、価格条件、秘密保持の塊です。無料構成でも守るべき原則は変わりません。保存時暗号化、転送時暗号化、最小権限、監査可能性、削除ポリシー、退出計画を明文化し、技術的統制に落とし込むことが必要です。無料SaaSを使う場合は、組織のIdPでSSO（シングルサインオン）を強制し、多要素認証を必須にします。OSSや自前ストレージの場合は、鍵管理、バックアップ、誤削除対策を自前で担います。

インフラの最小安全設定（Terraform例：S3）

resource "aws_s3_bucket" "contracts" {
  bucket = "acme-contracts"
}

resource "aws_s3_bucket_server_side_encryption_configuration" "this" {
  bucket = aws_s3_bucket.contracts.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

resource "aws_s3_bucket_public_access_block" "this" {
  bucket = aws_s3_bucket.contracts.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_lifecycle_configuration" "this" {
  bucket = aws_s3_bucket.contracts.id
  rule {
    id     = "noncurrent-cleanup"
    status = "Enabled"
    noncurrent_version_expiration {
      noncurrent_days = 365
    }
  }
}

まずはサーバーサイド暗号化とパブリックブロックを標準化します。削除保護は要件次第ですが、誤删除に備えたバージョニングと一定期間の保護は低コストで効果が高い対策です。加えて、CloudTrail/CloudWatchやData Access Logsでダウンロード・削除の痕跡を残し、アラートに結びます。

監査証跡と改ざん耐性を高める小技

無料プランでは監査証跡の保持に制限があることがあります。そこで、締結完了時にPDF本体のハッシュ、署名イベントの時刻、送信者・受信者の識別情報をJSONでまとめ、社内の不変ストレージに保管する運用が効きます。Gitにコミットするだけでも履歴の可視性は上がりますし、S3のオブジェクトロックやバージョニングで改ざん耐性を補強できます。ハッシュはSHA-256で十分ですが、台帳とは別系統に複製し、退会時にも持ち出せる形にします。

スケールと有料化の分岐点

無料で始めるべきです。ただし、どこかで「無料のままが高くつく」転換点が来ます。分岐のサインは明確です。月間締結件数が数十から百を超え、承認マトリクスが部門横断で複雑化し、契約義務の追跡やレポーティングに人手が戻り始めたら、CLM（Contract Lifecycle Management）の有料製品を検討する価値があります。研究データでは、契約管理の標準化と可視化が交渉時間の短縮やリスク低減に寄与することが示されています¹。電子署名は締結時間を日単位から分単位に圧縮する事例が多く報告されています⁷。無料の自前スタックは、要件の発見とデータの整備に適しています。有料化の前段で台帳、分類、期限、相手方マスタが整っていれば、移行はスムーズで、ROIも見えやすくなります。

移行時は、APIのあるCLMを選び、既存の台帳をインポートし、WebhookやSSOの設計を踏襲します。もしカスタムの抽出や分類が効いているなら、それを前処理として残し、CLM側ではワークフローと権限・監査に集中させるのが整合的です。無料で始めた積み上げは無駄になりません。むしろ、要件を自分たちの言葉で説明できるようになっているはずです。

まとめ：今日から無料で、やめ方まで設計する

契約管理の本質は、探せること、締結できること、忘れないことの三点に尽きます。無料SaaSとOSS、自前の薄い実装を組み合わせれば、小さく始めて価値を出すことは十分に可能です。ファイル規約とハッシュで原本性を担保し、簡素な台帳で期限を可視化し、Webhookで状態を自動更新すれば、日常の運用は回り始めます。セキュリティは基本設定を外さず、監査証跡は自分たちで保全する意識を持てば、無料構成でもリスクは管理できます。

無料で始め、有料で拡張するという方針は現実的です。今ある契約ファイルの棚卸しから着手し、上のコードを社内リポジトリに置いて小さく回してみてください。最初の一週間で、どの機能が「手間のわりに効くか」、どこが「無料の限界か」が見えてきます。その気づきが、次の意思決定の最短路です。

参考文献

  1. World Commerce & Contracting (IACCM). Overcoming the 10 pitfalls of contracting
  2. IDC. The High Cost of Not Finding Information
  3. PandaDoc. Free eSign guide
  4. Zoho Sign. Pricing
  5. DocuSeal. Document Signing for Everyone
  6. 海外の電子契約制度概要（ESIGN/eIDAS等の解説）. https://www.c-a-c.jp/abroad/system.html
  7. PR TIMES. 電子契約の導入効果に関する報道（事例・効果の概説）. https://prtimes.jp/main/html/rd/p/000000029.000037527.html