DocID管理設計書

Section 1

背景と目的

発生した問題

根崎氏の業務委託契約書で、ヘッダーのDocIDが旧IDのまま残っていた。契約書を流用して新規作成する際、DocIDの更新が漏れた。

この設計書では以下を定義する。

命名規則 — DocIDのフォーマットと各フィールドの意味
採番ルール — 番号の割り当て方法と重複防止
ヘッダー埋め込み — 契約書のどこにどう記載するか
管理台帳 — 採番済みDocIDの一覧管理
自動化方針 — 現状の手動運用から段階的に自動化する計画

Section 2

命名規則

MNML-YYYYMMDD-NN

プレフィックス — 契約日 — 同日連番

フィールド	説明	例
`MNML`	固定プレフィックス。合同会社MNMLの文書であることを示す	MNML
`YYYYMMDD`	契約日（契約書に記載される契約開始日）。作成日ではない	20260401
`NN`	同日連番。同じ契約日の文書が複数ある場合に区別する。01から開始、ゼロ埋め2桁	01, 02, 03

契約日の定義

「契約日」とは、契約書本文に記載される契約の効力発生日を指す。文書を作成した日やSharePointにアップロードした日ではない。更新契約の場合は更新後の契約開始日を使う。

連番ルール — 要決定事項

同日に1件しかない場合でも連番 -01 を付けるかどうか。現状は混在している。

案A: 常に連番を付ける（推奨）推奨

同日1件でも必ず -01 を付ける。例: MNML-20260316-01

メリット

フォーマットが常に固定（MNML-XXXXXXXX-XXの16文字）
正規表現やソートが単純になる
後から同日に2件目が出ても1件目の番号を変えなくて済む

デメリット

1件しかないのに -01 が冗長に見える

案B: 1件なら連番省略代替案

同日1件なら連番なし。2件目が出たら -01 と -02 に振り直す。例: MNML-20260316

メリット

見た目がすっきりする

デメリット

2件目追加時に1件目のIDも変わる（既存文書の修正が必要）
フォーマットが2種類になり、検索・バリデーションが複雑化
過去に振ったIDが変更されると追跡が困難

既存IDの扱い

過去に連番なしで採番されたID（例: MNML-20260316）は、案Aを採用した場合も遡って修正しない。今後の新規採番から統一する。既存IDは管理台帳にそのまま記録する。

DocIDの実例

DocID	文書	契約日
`MNML-20250925-02`	（既存契約書）	2025-09-25
`MNML-20260316`	森屋氏業務委託契約書	2026-03-16
`MNML-20260401-01`	（既存契約書）	2026-04-01
`MNML-20260401-03`	（既存契約書）	2026-04-01

Section 3

採番ルール

採番の流れ

契約日を確定する — 契約書に記載する契約開始日を確認
管理台帳を参照する — 同じ契約日のDocIDが既にあるか確認
連番を決定する — 同日の最大連番 + 1を採番（なければ01）
台帳に記録する — 採番したDocIDを台帳に即座に記録

重複防止

ルール	説明
台帳への即時記録	DocIDを決めたら、文書完成前でも台帳に「仮採番」として記録する。これにより同日の別文書と番号が衝突しない
欠番の扱い	採番後に文書が不要になった場合、そのDocIDは欠番とする。再利用しない。台帳には「欠番」と記録
修正・更新時	既存文書の内容を修正してもDocIDは変更しない。契約の更新（新期間）は別のDocIDを新規採番する

ステータス遷移

ステータス	意味	許可される遷移先
仮採番	番号を確保した段階。文書は未完成	確定 / 欠番
確定	文書が完成し、ヘッダーにDocIDが埋め込まれた	—（最終状態）
欠番	採番したが文書が不要になった	—（最終状態）

Section 4

ヘッダー埋め込み仕様

配置場所

契約書（Word/PDF）の全ページの右上ヘッダーにDocIDを記載する。

契約書ヘッダーイメージ

MNML-20260401-01

業務委託契約書

...

項目	仕様
位置	ヘッダー右寄せ
フォント	本文と同じフォント、9pt
色	グレー（目立ちすぎない程度）
対象ページ	全ページ（表紙含む）

現在の運用（手動）

m-legalまたはCEOがSharePoint上のWordファイルを開く
ヘッダー領域を編集し、DocIDを手入力する
PDF出力時もヘッダーが引き継がれる

今回の問題の原因

既存契約書をコピーして新規作成した際、ヘッダーのDocIDを更新し忘れた。手動運用では「コピー元のIDが残る」リスクが常にある。

将来の自動化方針

自動化する場合、以下の方式で実装する。

項目	方針
使用ライブラリ	`python-docx` — Wordファイル（.docx）のヘッダー操作に対応
処理の流れ	1. SharePointからWordファイルをダウンロード 2. `python-docx`でヘッダーのDocIDを書き換え 3. SharePointにアップロード（上書き）
PDF出力	ヘッダー書き換え後のWordからPDF変換（LibreOffice CLIまたはMS Graph API）
入力バリデーション	DocIDが `MNML-\d{8}-\d{2}` の正規表現に合致するか検証
冪等性	同じDocIDで再実行しても結果が変わらない。既にヘッダーが正しければスキップ

自動化の前提条件

SharePoint上のWordファイルにアクセスするため、MS Graph API（ops/shared/のOAuth基盤）が必要。既にops/で同基盤を利用しているため、追加のOAuthセットアップは不要。

Section 5

管理台帳

採番済みのDocIDを一元管理する台帳を運用する。

台帳の管理場所 — 要決定事項

案A: SharePoint上のExcelファイル（推奨）推奨

SharePointのシェアドドキュメントにExcel台帳を配置。手動でもプログラムからでも更新可能。

メリット

CEOがブラウザから直接閲覧・編集できる
MS Graph APIで自動更新が可能（将来の自動化と相性が良い）
契約書と同じSharePoint内に一元管理できる

デメリット

Excelの同時編集で競合する可能性（一人法人なのでリスクは低い）

案B: リポジトリ内のJSONファイル代替案

ops/ 配下にJSONファイルとして管理。Gitで履歴管理。

メリット

バージョン管理（Git）で変更履歴を追跡できる
プログラムからの読み書きが容易

デメリット

CEOがGitリポジトリを見に行く必要がある
契約書の保管場所（SharePoint）と台帳が分離する

台帳のカラム定義

カラム	型	説明	例
DocID	文字列	採番されたDocID	MNML-20260401-01
文書名	文字列	契約書のタイトル	業務委託契約書（根崎）
契約日	日付	契約書に記載された契約開始日	2026-04-01
相手方	文字列	契約の相手方の名前	根崎太郎
ステータス	文字列	仮採番 / 確定 / 欠番	確定
SharePointパス	文字列	SharePoint上のファイルパス	30_VDU/consulting/20_suppliers/...
備考	文字列	自由記述	—

Section 6

自動化ロードマップ

Phase 0

手動運用（現在）

ルール整備のみ。採番・ヘッダー記載は手動

Phase 1

台帳管理

Excel台帳をSharePointに配置。手動記録

Phase 2

採番自動化

m-legalが台帳参照→次番を自動計算

Phase 3

ヘッダー自動埋め込み

python-docxでWord書き換え。端から端まで自動

Phase	内容	自動化範囲	前提条件
Phase 0	この設計書でルールを定義。今後の契約書作成時はこのルールに従う	なし（全て手動）	なし
Phase 1	SharePointにExcel台帳を配置。採番時に手動で台帳を更新する	台帳のみ整備	CEO承認
Phase 2	m-legalが契約書作成時に台帳を参照し、次の連番を自動計算。台帳への登録も自動	採番 + 台帳登録	Excel台帳のMS Graph API連携
Phase 3	Wordファイルのヘッダーを`python-docx`で自動書き換え。採番→ヘッダー埋め込み→SharePointアップロードまで一気通貫	全工程	Phase 2 + python-docx実装

推奨

まずPhase 0〜1（ルール整備 + 台帳配置）を実施し、運用で問題がないことを確認してからPhase 2以降に進む。自動化は頻度とコストのバランスで判断する。契約書作成が月数件なら手動運用で十分な可能性もある。

Section 7

未決事項

#	項目	選択肢	推奨
1	同日1件の連番ルール	A: 常に `-01` を付ける / B: 省略可	案A
2	管理台帳の配置場所	A: SharePoint Excel / B: リポジトリJSON	案A
3	既存DocIDの遡及修正	連番なしの既存IDを修正するか / しないか	しない
4	自動化の優先度	Phase 1で止める / Phase 2以降に進む	頻度次第