ドメイン不変条件とエージェント方針
このページの目的は、relqis エンジンが守る不変条件と、AI エージェントがユースケース別に採用する運用ルールを分離して明文化することです。
重要なのは次の 1 点です。
新しいユースケースを追加するとき、まず増やすべきものは
AGENTS.mdテンプレート、プロファイル、サンプルであり、Relqis 本体の機能切替ではない。
1. 分離原則
エンジン不変条件
relqisが常に守る- CLI、DB、use case が変わっても崩れない
- 破るには実装変更が必要
エージェント方針
- AI エージェントが「どう案内し、どう質問し、どこで止まるか」を決める
- 法人、個人事業、家計簿などの差分を吸収する
- プロファイル /
AGENTS.md/ 対話例で変更できる
2. エンジン不変条件一覧
| 不変条件 | 所有者 | AI エージェントへの含意 |
|---|---|---|
| ledger entry が単一の会計 truth | engine | スプレッドシートや import 元ではなく、最終的には entry show journal show ledger show で確認する |
| posted entry は immutable | engine | posted 後に update しない。reverse / void を使う |
| closing / carryforward / reopen は明示操作 | engine | 月次・年次の状態変更は必ず明示コマンドと承認を通す |
| money は integer minor units | engine | 小数 UI から受けた値を変換してから渡す。負数で方向を表さない |
| manual entry も PostingRequest semantics を通る | engine | SQLite を直接更新しない。entry create も postreq と同じ再試行規律で扱う |
| posting policy は master が支配する | engine | required dimension 不足は agent が勝手に埋めず、master または人に戻す |
| opening / closing は explicit entry type、carryforward も non-zero 残高がある場合は explicit entry type | engine | 隠れた残高更新を想定しない。zero-balance carryforward だけは explicit ClosingRun + audit を読む |
| system-generated ID は application が生成する text ID であり、標準方式は UUIDv7 | engine | close carryforward depreciation reconcile などの run/batch 系 ID を timestamp 直書きや DB auto-increment に依存させない |
manual/import の posting_request_id と validate-time entry_id は v1.0 では caller-managed boundary ID のまま維持する | engine | 同じ論理 request の retry では同じ ID を再利用する。system-generated UUIDv7 と混同して毎回新しい値を振らない |
| posted-only が標準帳票の既定 | engine | reversal / closing / carryforward を含めるかは flags で明示する |
| year close と carryforward は別操作 | engine | year close 完了だけで翌期繰越済みとはみなさない |
| carryforward target は source の直後 fiscal period に限る | engine | source と同一期や飛び先 period への carryforward を前提にしない |
| carryforward は target period の opening month が open のときだけ実行できる | engine | target 側が先に閉じているなら、reopen や manual adjustment 方針を決めてから動く |
| carryforward 後の reopen-year は rollback 条件付きで可能 | engine | linked carryforward entry があれば rollback し、zero-balance carryforward なら completion state だけを解除する |
| fixed asset に登録した source entry line は fixed-assets workflow-owned | engine | generic entry reverse ではなく、まず asset void-registration など fixed-assets 側の訂正フローを使う |
| fixed asset registration の取消は depreciation history / retirement 前に限る | engine | registered line を戻したいなら、先に downstream activity の有無を確認する |
3. エージェント方針一覧
| 方針 | 所有者 | 不変条件ではない理由 |
|---|---|---|
個人事業では 事業主貸 / 事業主借 を優先候補にする | agent | これは業務案内上の優先順位であり、engine の必須ルールではない |
| 家計簿では tax code を前面に出しすぎない | agent | 家計用途の UX 方針であり、engine は tax code の存在可否を決めない |
| 法人では counterparty / department を積極確認する | agent | posting policy 次第で required/optional は変わる |
| 私費混在時は expense で即断せず事業 / 家計 判定を先に問う | agent | どこで止まるかは運用方針であり、engine は入力された結果を検証する |
| close / carryforward / export run の前に人間承認を必須とする | agent | engine は command を受ければ実行するが、承認フローは運用側の責任 |
| duplicate 疑いでは自動 post しない | agent | duplicate 検知ロジックは完全には engine invariant ではない |
| 家事按分は ratio と根拠の確認を先に行う | agent | ratio は業務判断であり engine には埋め込まない |
4. 境界が曖昧になりやすい論点
| 論点 | invariant 側 | agent policy 側 |
|---|---|---|
| 勘定科目 | account が存在し、postable であり、dc_type や required dimension が正しいこと | どの account を候補提示するか、どの質問順にするか |
| ID 生成 | system-generated ID が UUIDv7 などの安定した application policy に従うこと。manual/import の posting_request_id と validate-time entry_id は caller-managed retry anchor として維持すること | manual/import でも internal ID と external correlation key を二層化するか、いつ移行するか |
| 税区分 | tax code が存在し、entry date 上で有効であること | 家計簿では税質問を簡素化する、法人では根拠提示を強める |
| 訂正方法 | posted を直接更新できないこと | reverse と void のどちらを先に提案するか |
| 家事按分 | 金額と line balance が合うこと | 配賦率の聞き方、証跡の残し方 |
| export | selection と profile capability の整合 | 下流システムごとに include flags をどう案内するか |
5. ユースケースごとの方針差分
法人
- tax code、counterparty、department、subaccount を優先確認
- 月次・年次・export は承認前提
- 売掛/買掛、固定資産、bank reconciliation を積極利用
個人事業
事業主貸/事業主借を「私費混在」「個人口座利用」の第一候補に置く- 家事按分は ratio 未確定のまま post しない
- 境界を強く分けたい運用では、家計専用の動きを事業帳簿から除外する
- 青色申告や税務最終判断は人間確認に戻す
家計簿
- 税務厳密性より、二重計上防止と振替判定を優先
- category は少なく保ち、tax code は原則使わないか簡素にする
- クレカ利用時点と口座引落時点を別イベントとして扱う
6. ドキュメント拡張ルール
新しいユースケースを追加するときは、次の順で検討します。
- 既存 invariant で十分か確認する
- まずプロファイル /
AGENTS.mdテンプレート / サンプルデータ / 対話例で吸収する - それでも吸収できないときだけ、engine invariant や CLI 契約の変更を検討する
この順序を崩すと、relqis がユースケースごとの mode を増やして壊れやすくなります。