ベンダー契約の満了を追跡するWebアプリを作る

契約満了トラッカーが解決すべきこと

契約満了トラッカーは「予期せぬ出来事」を防ぐためのツールです：脅威となる自動更新、通知期限の見落とし、そして署名済みPDFが誰かの受信箱に埋もれているための直前のバタバタを防ぎます。

解消すべき問題

多くのチームが同じ失敗パターンに陥ります：

• 更新や通知期限の見落とし：多くの契約は更新の30～90日前にキャンセルを通知する必要があります。それが過ぎると拘束されます。
• 自動更新条項：契約が知らないうちに別の期間に繰り越され、場合によっては値上げが起きます。
• ファイルが散在し条項が不明瞭：署名済みの正本が見つからない、修正条項が別の場所にある、どの日付が拘束力を持つかわからない。

誰が使うか（なぜ必要か）

有用なトラッカーは各ロールをサポートし、彼らを契約専門家にすることを強制しません：

• **調達（Procurement）**は更新を把握して交渉のタイミングを確保し、支出を管理します。
• **法務（Legal）**は最新の署名済み契約、主要条項、修正を参照します。
• **財務（Finance）**は予測を立て、支払い条件を確認します。
• 部門オーナー（IT、マーケ、HR等）は、リマインダーと文脈を受け取り「更新・再交渉・終了」の判断を行います。

目指す成果

トラッカーが機能すると、次が得られます：

• 驚きが減る（静かな自動更新の回避）。
• 交渉タイミングの改善（通知期限前に議論を開始）。
• 明確な責任（各契約に担当者とバックアップがいる）。

初日から追うべき成功指標

測定可能なシグナルを選んで採用と信頼性を示します：

• 担当者が設定されている契約の割合（および部署）
• リマインダー配信率（送信済み対バウンス/失敗）
• 通知期限前に決定された更新の割合（決定が通知日より前に記録される）
• 主要日付が入力されている契約の割合（終了日、通知期限、更新期間）

MVPがこれらを一貫して解決できれば、高度な機能を追加する前に最も費用のかかるミスを防げます。

MVPの範囲と機能チェックリスト

MVPは瞬時に答えられるようにしておくべき質問は一つ：「何が間もなく満了するのか、誰が担当で次は何をすべきか？」v1は早く出荷できる小さな範囲に留め、実際の使用に基づいて拡張します。

早期にフルカスタムスタックを構築せずに速く動きたい場合、チャットベースの仕様からコア画面とリマインダーフローをプロトタイプでき、必要になれば実運用用のエクスポート可能なソースコードを生成するようなプラットフォーム（例：Koder.ai）を検討すると良いでしょう。

コアMVP機能（必須）

• 契約一覧：ベンダー名、契約名/ID、開始日、満了日（expiration date）、ステータス（Active/Expired）。
• 担当者フィールド（責任者）と必要に応じたバックアップ担当者。
• 満了日に紐づくリマインダー設定（例：90/60/30/7日）と「次のリマインダー」指標。
• 基本的な検索とフィルター：ベンダー、担当、"X日以内に満了"、ステータス。
• シンプルな契約詳細ページ：主要日付、更新タイプ（自動/手動）、メモ、添付ドキュメントへのリンク。

余裕があれば追加する機能（v1後）

• 条項のタグ付けと構造化メタデータ（例：「解約」「価格改定」「データ処理」）。
• 電子署名とソースリンク（DocuSign/Dropbox/DriveのURL）で原本ワークフローに飛べるようにする。
• ベンダースコアカード（更新リスク、パフォーマンスノート）で更新判断を支援。

v1で明示的に除外するもの

プロジェクトがフルの契約ライフサイクル管理に変わるのを防ぐため、次はv1から除外します：

• 多段階承認や法務レビューのワークフロー
• 赤字差分表示（redlining）による交渉ツール
• 単純なメモを超える複雑な義務管理（納品物、SLA等）

役割別の簡単なユーザーストーリー

契約担当者：「自分の担当契約の満了が近いものを見られて、交渉に十分な早さでリマインダーを受け取れる」。

調達/管理者：「契約を追加/編集して担当者を割り当て、未割当が出ないようにできる」。

財務/経営（閲覧のみ）：「今後の更新を見て支出を予測し、驚きの自動更新を避けられる」。

これらをクリーンな画面と確実なリマインダーで実現できれば、堅実なMVPです。

データモデル：ベンダー、契約、条件、日付

契約トラッカーは、収集するデータの良し悪しで成功が決まります。モデルが薄すぎるとリマインダーが信頼できず、複雑すぎると入力が止まります。90%のケースをカバーする「コアレコード＋いくつかの構造化フィールド」を目指してください。

コアエンティティ

**Vendor（ベンダー）**は支払先の会社です。検索とレポートで使う基本を保存します：法的名称、表示名、ベンダー種別（ソフトウェア、施設、エージェンシー等）、社内ベンダーID（あれば）。

**Contract（契約）**は追跡する合意です。1つのベンダーが複数の契約を持つ場合がある（例：ライセンスとサポートで別契約）ので、ContractはVendorに紐づく独立レコードにします。

所有権と連絡先

全ての契約には明確な契約担当者（更新判断の責任者）と、休暇や離職に備えたバックアップ担当者を必須で設定します。

主要な連絡先もキャプチャします：

• ベンダー担当者名/メール
• 社内の関係者（任意）

条項と重要な日付

多くのアプリは「開始」「終了」しか保存せず、なぜ更新が見逃されるか分からなくなります。複数の日付を明示的に追跡します：

• 開始日（契約期間の開始）
• 終了日（更新がない限りサービスが停止する日）
• 通知期限（非更新を伝える最終日）
• 更新/次期開始日（次の期間が始まる日）

自動更新と月次ルール

一般的な更新パターンをカバーする構造化フィールドを追加します：

• 更新タイプ：fixed-term、auto-renew、month-to-month
• 更新期間：例：12か月、1か月
• 自動更新有効：はい/いいえ

月次契約では“終了日”が不明な場合があるため、その場合は通知期限ルール（例：「次の請求サイクルの30日前に通知」）でリマインダーを駆動します。

各契約のステータスルールとライフサイクル

ステータスは単なるラベルではなく、ダッシュボードのカウント、リマインダーのスケジュール、レポートの論理を動かすものです。早期に定義し、シンプルに保ち、全ベンダー契約で一貫させます。

コアステータス（相互に排他的に）

MVPには実用的なセットがあります：

• Active：契約は有効で「間もなく満了」ウィンドウに入っていない。
• Expiring Soon：まだ有効だが更新アクションが近づいている。
• Renewed：新しい期間が実行された（新しい契約レコードや新しいバージョンにリンクすることが多い）。
• Terminated：契約が期間満了前に終了した、または通知によって終了した。
• Archived：履歴レコードでありリマインダーを生成しない（更新完了後や終了長期後）。

「間もなく満了」の定義

「間もなく」の閾値は固定にしておくと分かりやすいです。一般的には30/60/90日前。組織（または契約タイプ）ごとに閾値を設定可能にしてツールを柔軟にします。

終了日が変更された場合はステータスを自動再計算して、古い「間もなく満了」フラグが残らないようにします。

レポートのための理由コード

契約がTerminatedやArchivedに移るときは、次のような理由コードを必須にすると四半期レポートやベンダーリスクレビューが楽になります：

• Canceled
• Replaced（別の契約に置き換えられた）
• Vendor merge（相手方が変更された）
• Non-renewal

すべてのステータス変更を記録する（監査対応）

ステータスは監査可能なフィールドとして扱い、誰が、いつ、何を変えたか（旧ステータス→新ステータス、理由コード、任意のメモ）をログに残します。これにより通知が止まった理由や更新が見逃された経緯を説明できます。

リマインダーエンジンと通知設計

トラッカーが役に立つのは、人がリマインダーに基づいて行動するときです。目的は「通知数を増やすこと」ではなく、チームの働き方に合ったタイムリーで実行可能な促しを出すことです。

チャネル選び（まずはシンプルに）

まずはメールをデフォルトにします：普遍的で監査が容易、追加の管理作業が不要です。ワークフローが安定したら、オプションでSlack/Teamsを追加します。

チャネルはユーザー（または部署）ごとに設定できるようにし、財務はメール、調達はチャット、など好みに合わせます。

サプライズを防ぐリマインダースケジュール

終了日に紐づく予測可能なカレンダーを使います：

• 満了の90 / 60 / 30 / 7日前

さらに通知期限用の別クラスのアラート（例：「キャンセルには45日前必要」）を用意し、これは満了日よりも高優先度に扱います。

リマインダーを実行可能に：確認とスヌーズ

通知には2つのワンクリック操作を含めます：

• Acknowledge（確認済み）：「見た。対応する」を記録し、そのステップの繰り返しを止めます。
• Snooze（スヌーズ）：短期間（例：3日、1週間）だけ延期してノイズを減らします。

操作は監査ログに記録し、誰がいつ確認したか・コメントしたかを残します。

放置時のエスカレーション

担当者が定義されたウィンドウ（例：営業日3日）で承認しない場合、マネージャーやバックアップ担当者にエスカレーションします。エスカレーションは限定的かつ明確に：「まだ応答がありません。担当を確認するか再割り当てしてください。」のようにします。

ノイズ制御と信頼性

リマインダーを重複させない、静かな時間帯を尊重する、失敗時はリトライする。メッセージが遅延したり二重で届いたりすると、どんなに設計が良くても失敗します。

UXフロー：ダッシュボード、検索、契約詳細ページ

契約トラッカーは「速さ」で成功するか失敗するかが決まります：正しい合意を見つけて、更新日を確認し、1分以内に更新できるかどうか。最頻出アクション（次に何が来るかの確認、検索、軽微な編集）にUXを最適化します。

含めるべきコアページ

ダッシュボードは「何に注意すべきか？」に答えるページにします。先に今後の更新（次の30/60/90日）といくつかのKPI（今月満了件数、自動更新間近、ドキュメント欠落）を表示します。二つの主要ビューを提供します：

• テーブルビュー：スキャンと一括操作向け（満了日、担当、ベンダーでソート）
• カレンダービュー：計画と定期確認向けの「更新カレンダー」

契約詳細は「単一の真実の源」です。上部に必須情報を置きます：ベンダー、ステータス、満了日、更新条件、担当者、通知設定。補助情報（メモ、タグ、リンク済みドキュメント、関連連絡先）は下に配置します。

ベンダー詳細はそのベンダーに紐づく全てを集約します：アクティブ契約、履歴契約、主要連絡先、更新パターン。ここで「このベンダーから他に何を買っているか」を答えられます。

設定は簡素に：通知デフォルト、ロール、Slack/メール接続、標準タグ/ステータス。

検索、フィルター、保存ビュー

検索を常に使えるようにし、ベンダー、担当者、ステータス、日付範囲、タグでフィルターできるようにします。ダッシュボードにクイックフィルター（例：「14日で自動更新」「担当者未設定」「下書き」）を置き、繰り返すフィルターは「私の更新」「財務承認」等の保存ビューとして残せるようにします。

迅速な更新のための設計

多くの編集は小さな変更です。テーブル上や契約詳細の上部でインライン編集を可能にし、変更時には控えめなフィードバックと「元に戻す」オプションを用意します。ナビゲーションは一貫させ、ダッシュボード→検索結果→契約詳細、戻るパスと持続するフィルターを明確にしてユーザーが文脈を失わないようにします。

ドキュメント保管とバージョン管理

契約トラッカーは書類なしでは完結しません。重要な書類を主要日付の横に保管することで、「署名済みの正本がどこ？」という場面を防げます。

何をアップロードするか（理由付き）

まずは人が実際に探す最小限を：

• 署名済み契約PDF（真の参照元）
• 修正条項・付属文書（価格や期間、通知を変えることが多い）
• 更新や解約のメール/書簡（通知の証拠とタイミング）

MVPではアップロードを任意にしておき、"ドキュメントなし"状態を契約詳細で目立たせます。

保存方式：オブジェクトストレージ＋DBリンク

ほとんどのチームにとって単純かつ信頼性の高いセットアップは：

• ファイルはオブジェクトストレージ（例：S3互換）に保存
• DBにはメタデータのみ保存：ファイルURL/キー、元ファイル名、サイズ、コンテンツタイプ、チェックサム、uploaded_by、uploaded_at、紐付く契約/バージョン

DBを軽く高速に保ち、PDF等の大きなファイルはオブジェクトストレージに任せます。

バージョニング：最新と過去のドキュメント

ドキュメントは不変レコードとして扱います。PDFを"置き換える"のではなく、新しいバージョンをアップロードします。

実用的なモデル：

• document_group（例：「マスター契約」）
• document_version（v1, v2, v3…）

契約ページでは既定で最新バージョンを表示し、短い履歴（誰がいつアップロードしたか、“更新された更新条項”のようなメモ）を示します。

ダウンロード／置換／削除の権限

ドキュメントアクセスはロールベースで：

• Viewers：ダウンロードのみ
• Editors：新バージョンのアップロード（任意で注記）
• Admins：権限管理、削除は本当に必要な場合のみ

削除を許す場合は「ソフトデリート」（UIからは非表示だがストレージに残す）を検討し、すべての操作を監査ログに記録します。詳細は /security-and-audit を参照してください。

セキュリティ、権限、監査ログ

契約データには価格や交渉内容、署名済み文書が含まれます。MVPでもセキュリティをコア機能として扱います。

ロールと権限レベル

現実の責務にマッピングされる小さなロールセットから始めます：

• Admin：ユーザー、ロール、グローバル設定、連携を管理
• Editor：ベンダー／契約の作成・更新、ファイルのアップロード、リマインダー管理
• Viewer：閲覧専用（更新カレンダーのみ必要なステークホルダー向け）
• Legal-only：法務フィールドとドキュメントは見られるが、財務フィールドは不可
• Finance-only：価格・請求条件・更新コストは見られるが内部の法務メモは不可

ロールはシンプルに保ち、例外はレコードレベルのルールで処理します。

レコードレベルのアクセス（誰が何を見られるか）

ルールはベンダー単位で定義し、関連契約へ継承します。一般的なパターン：

• ベンダーは全社員、特定チーム、または指定ユーザーに表示
• 特に機密性の高い契約は契約単位で可視性を上書き
• ファイルダウンロードは契約を閲覧可能かつ「ファイルダウンロード権」を持つユーザーに限定

これにより偶発的な情報漏洩を防ぎつつ、チーム横断の契約追跡をサポートします。

認証：SSOまたはメール＋MFA

組織にIDプロバイダがある場合は**SSO（SAML/OIDC）**を有効にして雇用状態に紐づけます。ない場合はメール/パスワード＋MFA（TOTPやパスキー）を使い、セッション制御（タイムアウト、デバイス取り消し）を強化します。

実用的な監査ログ

レビューや紛争時に役立つログを残します：

• ファイルのダウンロード／アップロード／削除
• 契約の編集（旧値→新値）、特に満了日や自動更新条項
• 権限とロールの変更

監査エントリはベンダー／契約で検索可能にし、コンプライアンス用にエクスポートできるようにします。

既存契約の取り込みと連携

トラッカーが有用になるのは実際の契約が入ったときです。2つの道筋を計画します：すばやく取り込んで使い始めるためのインポートと、手作業を減らすための深い連携です。

クイックスタート：CSVインポート

スプレッドシートや共有ドライブから既存契約を読み込む最も簡単な方法はCSVインポートです。最初のバージョンは寛容で、リマインダーに必要なフィールドに集中します：

• ベンダー名（任意でベンダーID）
• 契約名/タイプ
• 開始日、終了/満了日、自動更新フラグ
• 更新通知ウィンドウ（例：30/60/90日）
• 担当者（人またはチーム）

ダウンロード可能なテンプレートと、カラム名のマッピングステップ、保存前にエラーをハイライトするプレビューを提供します。

期待すべきデータクリーンアップ

インポートは汚れたデータを露呈します。最初のアップロードがサポートチケットにならないよう、簡単なクリーンアップワークフローを作ります：

• 重複ベンダー："Acme Inc." vs "ACME" のような差を検出してマージ提案または既存ベンダーの選択を促す
• 日付フォーマットの不一致：01/02/2026のような曖昧さを検出し、解析結果の確認を要求
• 欠落する担当者や日付：インポートは続けられるが不完全行は「要確認」キューへ送る

オプションの連携（再入力を減らす）

基本が動いたら、連携で情報を最新に保ちます：

• Google Workspace / Microsoft 365の連絡先：ベンダー担当や請求メールを取り込む
• カレンダー同期：満了日や通知日をカレンダーイベントとして作成し既存ワークフローに表示

ベンダーシステム（ERP/調達）との同期

既にERPや調達ツールがある場合は、それをベンダー情報の信頼できる情報源として扱います。夜間にベンダーとIDを軽量に同期し、契約固有の日付はアプリ側で管理する運用が現実的です。競合した場合の優先ルールと「最終同期日時」を表示してユーザーがデータを信頼できるようにします。

連携は管理画面（例：/settings/integrations）から見られるようにし、エンジニア限定のプロセスに隠さないことを推奨します。

スケジューリングと信頼性のためのバックエンドロジック

トラッカーは"単純"に見えて、リマインダーが動かない・二重で動く・異なるタイムゾーンで間違って届くと途端に問題になります。信頼できるスケジューリング層を作り、予測可能でデバッグ可能、リトライに安全な設計にします。

リマインダーとエスカレーションのバックグラウンドジョブ

通知ロジックをWebリクエスト内で実行せず、ジョブキュー（例：Sidekiq/Celery/BullMQ）を使います。2つのジョブパターンが有効です：

• 日次スケジューラジョブ：毎時（または1日1回）実行して、間もなく発生するリマインダー用のジョブをエンキューする
• 契約ごとのリマインダージョブ：各契約・各リマインダーウィンドウ（90/60/30/7/1日等）につき1ジョブ、承認がない場合のエスカレーションジョブも含む

エスカレーションは段階的に：まず「担当者へ通知」、次に「マネージャーまたはバックアップへ」、と遅延を挟んで関係者を増やしていきます。

タイムゾーンと営業日

全てのタイムスタンプはUTCで保存し、リマインダーの"期日"は契約担当者のタイムゾーン（または組織のデフォルト）で計算します。例：「満了の30日前の午前9時（現地時間）」。

営業日ルールをサポートするなら手作りロジックを避け、いずれかを使います：

• ビジネスカレンダーライブラリを利用、または
• 小さな "会社カレンダー" テーブル（週末 + 祝日）を保持し、リマインダーを前の営業日にシフト

このルールはログや契約詳細に表示して、なぜ金曜に通知が来たのか等を説明できるようにします。

冪等性（重複通知の防止）

リトライは普通に起きます（ネットワーク、プロバイダタイムアウト等）。通知送信を冪等に設計します：

• contract_id + reminder_type + scheduled_for_date + channel のようなユニークキーで notification_outbox レコードを作る
• そのキーにユニーク制約を置く
• 挿入が成功したときだけ送信し、既に存在すれば安全に終了する

これによりジョブが2回走っても「高々一度」の送信が保証されます。

変数入りメッセージテンプレート

ビジネスユーザーが文言をコード変更なしで調整できるようテンプレートを集中管理します。サポートする変数例：

• {{vendor_name}}
• {{contract_title}}
• {{expiration_date}}
• {{days_remaining}}
• {{contract_url}}（相対リンク例：/contracts/123）

テンプレートはサーバー側でレンダリングし、最終レンダー済みテキストを outbox に保存して監査/デバッグに使います。メールとSlackは同じペイロードから送信します。

テスト、パイロット導入、ローンチチェックリスト

テスト不足で契約トラッカーは静かに失敗します：日付ルールが1日ずれている、ある自動更新が誤解された、通知は送信されたが配信されていない。リマインダーエンジンは請求ロジック同様に高インパクトで、驚きは許されません。

テストするべき項目（方法）

まずはUIの磨きより「契約の真実」に関する自動化テストを重視します。

• 日付ルール：終了日、"有効期限まで"の扱い、タイムゾーン、包含/排除ロジック（例：契約は2026-03-31 23:59まで有効かどうか）
• 通知期限：30/60/90日の算出テスト、週末/祝日処理を含む場合はその検証
• 自動更新ロジック："キャンセルが45日前必要なら"次サイクルの算出が正しいか

現実的なサンプル契約セットを用意して、各々に対して生成される正確なリマインダースケジュールをアサートします。

通知信頼性チェック

ステージング環境で実際の受信箱（Gmail、Outlook等）を使い、メール到達性を検証します：

• SPF/DKIM/DMARCの整合性（またはプロバイダの相当設定）
• バウンス処理とサプレッション動作
• 非必須アラートのオプトアウト/退会挙動

Slack通知をサポートする場合はレート制限、チャンネル権限、チャンネルアーカイブ時の挙動を確認します。

パイロットローンチ：小さく、実運用で、測定可能に

調達＋財務など小さいグループで実際の契約を使ったパイロットを実施します。成功指標を定義："見逃しゼロ"、"誤通知率<5%"、"全契約が10秒以内で検索可能"等。毎週フィードバックを取り、ルールの穴を修正してからスケールします。

Koder.aiのような初回構築ツールを使う場合、スナップショット／ロールバックを活用してリマインダーロジックや権限ルールを安全に反復できます。

ローンチ準備チェックリスト

ローンチ前に確認すること：

• 各チームの管理者ロールとアクセスが正しいこと
• バックアップ/リストアのテストを実施済みであること
• リマインダージョブがスケジュール通りに動き、監視があること
• サポート経路が存在すること（失敗したインポートや誤った日付の対応先）
• 短い内部ガイドが公開されていること（例：/blog/contract-tracker-playbook）

分析、レポート、継続的メンテナンス

契約トラッカーが価値を発揮するのは人が早期に行動できるようにする時です。つまり明快なレポート、軽量なエンゲージメント指標、データを信頼可能に保つ運用が必要です。

実務でよく使われるレポート

最初は以下の“常時オン”ビューを用意します：

• 月別の今後の更新：次の30/60/90日の契約数を月ごとに表示する更新カレンダー
• 担当者別：誰が何を担当しているか。マネージャーが締め切り前に負荷を調整可能にする
• ベンダー別：あるベンダーに紐付く全契約を表示し、統合の機会を探る

エクスポートはシンプルに：スプレッドシート用CSVと、アプリ内で共有可能なフィルタ付きリンク（例：/reports/renewals?range=90&group=owner）

エンゲージメント指標：確認と見逃し

"リマインダーを見ていない"という問題を避けるため、少数のイベントを追跡します：

• 確認（Acknowledgements）：受信者が「確認」をクリックしたか
• 期限切れの更新：通知日を過ぎて決定が記録されていない契約
• 見逃された通知：配信失敗（メールバウンス、Slackエラー）や未確認のリマインダー

これらは懲罰的に使うのではなく、どこにフォローが必要か、通知設定が機能しているかを可視化するためです。

継続的改善の計画

MVPが安定したら、実際に価値を生む次の改善は：

• タグ（例：「自動更新」「セキュリティレビュー要」）による高速フィルタリングとレポート
• テンプレート：標準条項やリマインダー日程のテンプレート
• 軽量な承認ワークフロー：依頼者→承認者→記録決定 のようなシンプルな流れ

データを保つためのサポートプロセス

いくつかの簡単なルンブックを作成し、内部ページ（例：/help/admin）からリンクします：

• データ修正：主要日付を誰が編集できるか、変更理由の記録方法
• アクセス申請：ロール付与の流れと権限レビュー頻度
• バックアップと復元：バックアップ頻度、保存場所、復元テスト方法

これらが整えば、アプリはローンチ後も長く使えるツールとなり、レポーティングは更新計画の信頼できる情報源になります。