借入金の返済予定と契約の条件を毎月点検して、期限と財務制限条項の抵触を洗い出す

処理の起点を決める

毎月の起点は、月次試算表の確定です。 Apps Script のインストール型トリガーのうち、時間主導型トリガーを使います。時間主導型トリガーは1分ごとから月1回までの頻度で設定できます。

ここで注意が要るのは、開始時刻が正確ではないことです。9時のトリガーを作ると、Apps Script は9時から10時の間の時刻を選びます。「試算表が確定した直後に必ず動く」という組み方はできません。

対策は単純です。毎営業日の朝に動かし、試算表の確定フラグを見て、確定していなければ何もせずに終える形にします。これなら時刻のずれは問題になりません。

初回の台帳化は、担当者が手で実行します。契約書が新しく増えたときも同じです。月45本の点検に対し、新規の契約は年に数本しかありません。

入力データを集める

前期末の確定値を台帳に持つことを忘れないでください。 「前期末比75％」という条項は、前期末の数字が固定されていないと計算できません。決算が確定した時点で台帳に書き込む運用を入れます。

データの取得方法を決める

契約書のPDF： 金融機関から受け取る契約書は、テキスト情報を持つPDFであることが多いものの、製本して押印したものをスキャンしている場合もあります。スキャンPDFはAIの画像入力で読めますが、100ページを超えると枚数の上限に当たります。 その場合は財務制限条項と定義条項の章だけを抜き出して渡します。

試算表： 会計システムから月次でエクスポートします。CSVで足ります。連結と単体の両方を取り出してください。 条項がどちらを見るかは契約ごとに違います。

期限の管理： 返済日、利払日、報告義務の期日を台帳に日付として持ちます。契約書の「決算確定後3か月以内」のような相対的な表現は、台帳に入れる時点で具体的な日付に直します。

AIへ渡す前に整形する

1. 契約書の章の切り分け … 「定義」「財務制限条項」「報告義務」「期限の利益喪失」の章を特定します。見出しの表現は契約ごとに違うので、AIに探させます
2. 数値の定義の紐づけ … 条項に出てくる「純資産」が、定義条項でどう定義されているかを対応づけます。定義がなければ「定義なし」として記録し、人が判断します
3. 試算表の科目の対応づけ … 契約書の用語（「有利子負債」）と、試算表の科目（短期借入金＋長期借入金＋社債＋リース債務）を対応づける表を作ります。この表は人が作ります
4. 相対期日の絶対化 … 「決算確定後3か月以内」を、今期の決算確定日から計算した日付に直します
5. 点検対象の絞り込み … 月次で見る条項と、四半期・年次で見る条項を分けます

3番目が最も重要で、最も手間がかかります。ここを自動化しようとしないでください。 「有利子負債」にリース債務を含むかどうかは、契約書の定義と自社の会計処理を照らして人が決めることです。一度決めれば変わりません。

AIに処理させる

AIと計算処理で役割を分けます。

計算処理にさせること： 条項の式の計算、余裕度の算出、期限までの日数。すべて四則演算と引き算です。

AIにさせること：

AIの出番は、ほぼ初回の台帳化に集中します。 毎月の点検でAIが使われるのは、余裕度が小さい条項について「何が起きているか」の説明文を作るところだけです。この構成は、AIを常時動かす構成ではありません。

指示内容を固定する

あなたは企業財務の担当者を支援する立場です。
以下の借入契約書から、財務制限条項・報告義務・期限の利益喪失事由を
抽出してください。

【厳守事項】
- 契約書に書かれていない条件を補わないでください。
  一般的な契約に「よくある」条項を推測で足さないでください。
- 各条項について、原文をそのまま original_text に入れてください。
  要約した文を original_text に入れないでください。
- 条項に出てくる財務指標（純資産、有利子負債など）について、
  定義条項での定義を definition に入れてください。
  定義条項に記載がない場合は null にし、needs_review に理由を書いてください。
- 連結・単体の別が契約書から読み取れない場合は、
  scope を "unclear" にしてください。推測で "consolidated" としないでください。
- 判定のタイミング（各決算期末／各四半期末／各月末）を明記してください。
  記載がなければ null にしてください。
- 抵触しているかどうかの判断はしないでください。
  条件を構造化して返すことだけが役割です。

【契約書の本文】
{contract_text}

最後の指示が重要です。 抵触の判断をAIにさせません。判断は、台帳に入った式と試算表の数値を使って計算処理が行います。AIに判断させると、なぜその結論になったかを後から説明できません。

「一般的な契約によくある条項を推測で足さない」も必須です。 財務制限条項の抽出でこれが起きると、実際には付いていない条項を毎月点検することになります。逆に危険な方向の誤りではありませんが、無駄な作業と誤った安心を生みます。

出力形式を固定する

Gemini API の構造化出力を使います。スキーマは properties でプロパティを定義し、required で必須項目を列挙します。契約書1本あたりの条項は多くても10個程度なので、深くネストしない浅い構造で返させます。

{
  "contract_id": "",
  "covenants": [
    {
      "covenant_type": "net_assets | profit | debt_ratio | other",
      "original_text": "",
      "formula": {
        "metric": "",
        "operator": ">= | <= | > | <",
        "base": "",
        "ratio": 0
      },
      "scope": "consolidated | standalone | unclear",
      "definition": null,
      "timing": null,
      "needs_review": ""
    }
  ],
  "reporting_obligations": [
    {
      "document": "",
      "recipient": "",
      "due_expression": "",
      "original_text": ""
    }
  ],
  "acceleration_events": [],
  "extraction_confidence": "high | medium | low"
}

毎月の点検結果は、計算処理が作ります。

{
  "as_of": "",
  "results": [
    {
      "contract_id": "",
      "covenant_type": "",
      "threshold": 0,
      "actual": 0,
      "headroom": 0,
      "headroom_ratio": 0,
      "status": "ok | watch | breach | not_calculable",
      "reason": ""
    }
  ]
}

headroom_ratio（余裕の割合）を必ず持たせます。「抵触していない」だけでは、余裕が10％なのか100％なのかが分かりません。

システムへ連携する

会計システムへの書き込みはありません。 この構成は読み取り専用です。金融機関への報告書の送信も自動化しません。

台帳をスプレッドシートにする理由は、人が直せるためです。 契約書からの抽出には必ず誤りが混ざります。パッケージのデータベースに入れてしまうと、担当者が直せなくなります。年に数本しか増えない台帳を、専用システムで管理する必要はありません。

人が確認する

確認は2段階あります。

1段階目は、台帳化のときです。 AIが抽出した条項を、担当者と法務が契約書と1条ずつ照合します。ここは省略できません。 45本で2〜3日かかりますが、一度だけの作業です。この確認を飛ばすと、以後の点検がすべて誤った前提の上に乗ります。

2段階目は、毎月の点検結果です。 余裕度が小さいもの、status が watch breach not_calculable のものを担当者が確認します。ok のものは一覧で確認するだけです。

確認を速くするための設計が重要です。

• 余裕度の小さい順に並べる
• not_calculable（計算できなかった）を必ず上に出す。ok と混ぜない
• 前月・前々月の余裕度を横に並べ、推移が見えるようにする
• 条項の原文を一覧の中に展開しておく

not_calculable を ok と区別することが最も重要です。 数値が取れなかったために計算できなかったものを「問題なし」と表示すると、抵触に気づけません。

例外に対処する

記録を残す

• 契約書PDFの版（変更契約を含む）
• AIが抽出した条項と original_text、extraction_confidence
• 人が確定した台帳の内容と、AIの抽出からどこを直したか
• 毎月の点検結果（基準値・実績値・余裕度・使った試算表の日付）
• 金融機関へ提出した報告書と、提出日
• breach または watch が出たときの通知先と対応

4つ目で「使った試算表の日付」を残すのが要です。後から「この月はなぜ余裕があると判断したのか」を問われたときに、当時の数値を再現できる必要があります。

余裕度の推移を残すことに、この構成のもうひとつの価値があります。 12か月分並べれば、余裕が減り続けているかどうかが一目で分かります。抵触してから対処するのでは遅く、半年前に傾向が見えていれば、金融機関との事前相談ができます。