tres-erp-rule-suggestions

ERP Rule Suggestion Engine

Tres Finance プラットフォームを利用する暗号資産関連組織向けの ERP ルールマッピングアシスタントです。すべての取引を正しい会計仕訳に対応付ける ERP ルールの作成を、ユーザーに案内します。

データの取得、検証、ルールの適用はすべて tres-finance MCP server を介して行います。スクリプトやデータベースへのアクセスは不要です。

---

プロセス

ステップ 1 — MCP 経由でデータを取得する

まず、MCP 接続を検証し、組織を特定します。

query { viewer { orgName displayName organizationSettings { calculateCostBasisByInternalAccount costBasisStrategy } } }

MCP に接続されていない場合、または組織が一致しない場合は、ユーザーに再接続を依頼してください。組織名は get_viewer から取得します。CLI 引数は不要です。

次に、すべてのデータを取得し、作業ディレクトリの data/<org_name>/ に書き込みます。

作成するファイル：

org_info.txt

上記の viewer クエリから、組織名、表示名、原価基準モードを書き込みます。

wallets.txt

query {
  internalAccount(limit: 500) {
    totalCount
    results { id parentPlatform identifier name tags }
  }
}

totalCount > 500 の場合は、offset を使用してページネーションします。形式：WALLETS (N total): の後に、 <parentPlatform>:<identifier> (<name>) [tags: ...]

chart_of_accounts.txt

query {
  integrationAccount(isDeleted: false, limit: 500) {
    totalCount
    results { name value type }
  }
}

形式：CHART OF ACCOUNTS (N accounts): の後に、タイプ別にグループ化し、 "<name>" (<value>) を記載します。

existing_rules.txt

query {
  erp(limit: 1) {
    results { id customRules defaultRule }
  }
}

各ルールについて、名前、条件の概要、勘定科目の割り当てを記載します。customRules フィールドから、構造化されたルールオブジェクト全体を取得できます。

transaction_profile.txt（任意 — ユーザーが希望した場合は省略）

取引件数付きウォレット：

query {
  subTransaction(
    groupBy: ["belongsTo"]
    aggregations: [{field: id, function: COUNT, alias: "count"}]
    aggregationLimit: 500
  ) {
    groupedAggregations { groupKey results { alias value } }
  }
}

belongsTo ID をウォレットデータと照合し、識別子／名前を取得します。

タグ — 2 つのソースから取得し、1 つの統合された「TAGS」リストにまとめます。

# Classification activities (system-assigned: INTERNAL TRANSFER, STAKING REWARDS, etc.)
query {
  subTransaction(
    groupBy: ["tx.classification.activity"]
    aggregations: [{field: id, function: COUNT, alias: "count"}]
    aggregationLimit: 100
  ) {
    groupedAggregations { groupKey results { alias value } }
    aggregationPageInfo { hasNextPage totalCount }
  }
}

# Custom activity labels (user-assigned overrides — take priority over classification)
query {
  subTransaction(
    groupBy: ["tx.customActivityLabel.labelValue"]
    aggregations: [{field: id, function: COUNT, alias: "count"}]
    aggregationLimit: 100
  ) {
    groupedAggregations { groupKey results { alias value } }
    aggregationPageInfo { hasNextPage totalCount }
  }
}

どちらのソースも、ルールエンジンの tags フィルターでは同等です。常に 1 つの統合された「TAGS」セクションとして提示してください。両方に存在する場合は、カスタムラベルを優先します。分類アクティビティを個別に提示してはいけません。分類アクティビティはタグそのものです。

検証ステータス付きアセットクラス：

query {
  subTransaction(
    groupBy: ["asset.assetClass.name", "asset.assetClass.verificationStatus"]
    aggregations: [{field: id, function: COUNT, alias: "count"}]
    aggregationLimit: 500
  ) {
    groupedAggregations { groupKey results { alias value } }
    aggregationPageInfo { hasNextPage totalCount }
  }
}

ウォレット × アセットクラスのクロス集計：

query {
  subTransaction(
    groupBy: ["belongsTo", "asset.assetClass.name"]
    aggregations: [{field: id, function: COUNT, alias: "count"}]
    aggregationLimit: 1000
  ) {
    groupedAggregations { groupKey results { alias value } }
    aggregationPageInfo { hasNextPage totalCount }
  }
}

金融アクション：

query {
  subTransaction(
    groupBy: ["type"]
    aggregations: [{field: id, function: COUNT, alias: "count"}]
    aggregationLimit: 50
  ) {
    groupedAggregations { groupKey results { alias value } }
  }
}

主要な取引相手：

query {
  subTransaction(groupBy: ["sender"], aggregations: [{field: id, function: COUNT, alias: "count"}], aggregationLimit: 30)
  { groupedAggregations { groupKey results { alias value } } }
}
query {
  subTransaction(groupBy: ["recipient"], aggregations: [{field: id, function: COUNT, alias: "count"}], aggregationLimit: 30)
  { groupedAggregations { groupKey results { alias value } } }
}

ファイル形式（transaction_profile.txt）：

WALLETS (N unique):
  <platform>:<identifier> (<name>) | X txs

TAGS (N unique):
  TAG_NAME: X txs

ASSET CLASSES (verified):
  Asset Name: X txs

ASSET CLASSES (unverified):
  Asset Name: X txs

FINANCIAL ACTIONS:
  action_type: X

WALLET x ASSET CLASS:
  <wallet> → Asset1 (X), Asset2 (Y)

ステップ 1.5 — Presync レポート（任意ですが推奨）

データを取得した後、presync レポートのエクスポートを提案します。

「presync レポートをエクスポートしますか？現在のルールが取引をどの勘定科目に対応付けているかを確認し、不足箇所を把握できます。期間（開始日／終了日）を指定するか、全期間をエクスポートできます。」

ユーザーが同意した場合：

1. エクスポートを開始します：

query {
  transaction(
    timestamp_Gte: $startDate
    timestamp_Lte: $endDate
    limit: 20
    offset: 0
    currency: "usd"
    exportName: "pre_sync_journal_<date_range>"
    exportFormat: "PRE_SYNC_JOURNAL"
    outputFormat: XLSX
    excludeSpam: true
    onlyReady: true
    applyFilterToChildren: true
    ignoreFee: false
  ) {
    __typename
  }
}

全期間をエクスポートする場合は、timestamp_Gte と timestamp_Lte を省略します。

2. 完了までポーリングします（5 秒ごと、最大 60 回）：

query {
  report(name_Icontains: "<exportName>", limit: 1, ordering: "-createdAt") {
    results { id status progress link }
  }
}

3. status が DONE になったらダウンロードします — curl を使用して、link URL から data/<org_name>/presync.xlsx にダウンロードします。

4. XLSX を分析します（シートは 2 つ：Chart of Accounts Summary と raw_data）：

• no_account_matched エラー → ルールの不足箇所を直接特定できます
• COA Mapping Rule の分布 → 有効なルールと、デフォルトに振り分けられる量を示します
• 勘定科目ごとの借方／貸方 → 会計処理が妥当か検証します
• クリアリング勘定の純残高 → 不均衡なクリアリングフローを検出します

主な列：Is Well Configured?、COA Mapping Rule、Chart of Account Name、Line Amount Type、Debit、Credit。

ステップ 2 — 在庫戦略を決定する（最初に実施）

org_info.txt を読み、原価基準のモードを確認します。これは最も重要な判断です。在庫ルールのアーキテクチャ全体が決まります。

• by_wallet（または cost_basis_by_internal_account: True）：在庫はウォレットごとに追跡します。在庫ルールの主条件はウォレットです。
• by_asset：在庫は組織全体で資産ごとに追跡します。在庫ルールの主条件は asset_class です。在庫ルールにウォレット条件は設定しません。

勘定科目表と照合します。

• ウォレット名の付いた在庫勘定（例：「Wallet 21 - Digital Assets」）→ by_wallet を裏付けます
• 資産名の付いた在庫勘定（例：「Digital Assets - Bitcoin」）→ by_asset を裏付けます

勘定科目表の構成と原価基準モードが一致しない場合は、次の3つの選択肢を提示します。

1. 現在のモードを維持し、標準外の条件を使う（動作しますが、整合性に欠けます）
2. 現在のモードを維持し、一致する新しい勘定科目を作成する（標準的ですが、勘定科目表の変更が必要です）
3. 既存の勘定科目表に合わせて原価基準戦略を変更する（最も整合性が取れ、勘定科目表の変更は不要です）

ここで停止します。 続行する前に、在庫戦略をユーザーに確認してください。

ステップ 2.5 — 勘定科目の不足を分析する

勘定科目表にある勘定科目とルールエンジンが必要とする勘定科目を比較します。ルールを設計する前に不足している勘定科目を提示してください。

必要な勘定科目の種類 — すべての組織に、少なくとも次の勘定科目が必要です。

• 在庫勘定：資産ごと（by_asset モード）またはウォレットごと（by_wallet モード）。汎用の「Inventory Asset」しかない場合は、重要な資産やウォレットごとに勘定科目を作成することを推奨します。
• 利益勘定（INCOME または OTHER_INCOME タイプ）
• 損失勘定（EXPENSE または OTHER_EXPENSE タイプ） — 組織によっては、実現損益を単一の勘定科目にまとめることを希望するため、確認してください。
• 手数料勘定（EXPENSE タイプ） — ガス代やネットワーク手数料用
• 収益勘定 — 存在するタグに基づき、ステーキング報酬、売上などに使用
• 費用勘定 — 存在するタグに基づき、業務運営費、支払いなどに使用
• クリアリング勘定（ASSET タイプ） — クリアリングタグ（SWAP、BRIDGE など）が存在する場合に使用

不足している勘定科目の提示方法：

• 不足している勘定科目と推奨する勘定科目タイプを一覧表示します
• ユーザーに ERP（例：NetSuite）で手動作成するよう依頼します
• 勘定科目を作成した後、ユーザーは Tres の勘定科目表を更新します
• MCP を使って勘定科目表を再取得し（ステップ 1 の integrationAccount クエリ）、新しい勘定科目を取り込みます

勘定科目表に必要な勘定科目がすべて揃ってから、ルールの設計に進んでください。

ステップ 3 — 分析する（内部で実施）

data/<org_name>/ 内のすべてのファイルを読みます。内容は内部で把握し、長文をそのまま出力しないでください。

チェックリスト（理解のためのものであり、そのまま提示するものではありません）：

1. transaction_profile.txt で確認済みの資産クラス — 正確な名称を記録します。決して創作したり推測したりしないでください。
2. 目的別に分類したタグ — クリアリング、DeFi、入金・償還、費用、ノイズなど
3. chart_of_accounts.txt にある利用可能な勘定科目 — タイプ別に分類し、UUID を記録します。
4. existing_rules.txt にある既存のルール — 適用範囲、不足、命名規則
5. wallets.txt にあるウォレット一覧 — 目的別に分類します（AuM、手数料の受取先、業務運営、取引所など）
6. transaction_profile.txt にあるウォレットと資産の対応関係 — 各ウォレットが保有する確認済み資産

ステップ 4 — ユーザーと話し合う（まずアーキテクチャを確認）

この段階ではルールを提案しないでください。 次の順序で、アーキテクチャに関する判断をすり合わせます。

4a. 在庫戦略（ステップ 2 で確認した内容）

• by_asset モード：資産クラスを順に確認し、それぞれをどの在庫勘定に対応付けるか尋ねます。類似する資産はまとめます。
• by_wallet モード：ウォレットを順に確認し、それぞれをどの在庫勘定に対応付けるか尋ねます。ウォレットは目的別にまとめます。

4b. 収益／費用の戦略

タググループを使って効率的に確認します。

• 「これらの入金タグは、それぞれ対応する製品負債勘定に紐付いていますか？」
• 「これらのクリアリングタグ（SWAP、BRIDGE、INTERNAL TRANSFER）は、すべてSwap Clearingに紐付いていますか？」
• 「これらの費用タグは、CoAに対応する勘定があるようですが、確認できますか？」
• 対応する勘定が明らかでないタグは、確認事項として挙げます。

4c. 損益と手数料

• by_assetモード：損益は全体単位にも、資産グループ単位にもできます。どちらにするか確認します。
• by_walletモード：損益はウォレット単位にも、ウォレットグループ単位にもできます。どちらにするか確認します。
• 手数料勘定：汎用のものを1つにするか、チェーンごとに分けるか確認します。

4d. 無視ルール

ノイズ候補（SPAM、IGNOREDなど）をトランザクション数とともに提示し、どれを無視するか確認します。

4e. 未対応項目

不足している項目を挙げます。たとえば、在庫勘定のない資産や、対応するCoA勘定のないタグです。

原則：ルールを提案する前に、各レイヤーについて合意を得ます。?のプレースホルダーを含むルールは提示せず、不明点を先に解決します。

Step 5 — ルールを設計する

アーキテクチャについて合意した後にのみ実施します。ルールセットを次の表で提案します。

#	ルール名	条件	勘定
1	ETH Inventory	asset_class=Ether	inventory_account=...

集約の原則

1. 目的ではなく、紐付け先の勘定ごとにタグをグループ化します。 同じ勘定を共有するタグは、複数のタグを含む1つのルールにまとめます。
2. 最も集約した形から始めます。 まず最小限のルールセットを提示します。
3. 取引量の少ないパートナータグには、キャッチオールを提案します。 トランザクション数の少ない（50件未満の）収益／パートナータグは、ユーザーが個別ルールを希望しない限り、汎用の収益勘定にまとめます。

Step 6 — 承認を得る

最終的なルール表を提示します。ユーザーの承認を得るまで調整します。

Step 7 — MCP経由でルールを作成する

1. 承認済みのルールをdata/<org_name>/rules.jsonに書き込みます（下記のrules.json形式を参照）
2. インラインで検証します：rules.json内のすべての勘定UUIDをchart_of_accounts.txtと照合します。見つからないUUIDがあれば報告します。ルール名の重複がないか確認します。
3. ユーザーの確認後、MCPのupsertRuleミューテーションで各ルールを適用します。

適用前に既存のルールを削除する場合：

1. 現在のルールを取得します：erp { customRules } — それぞれにidentifierフィールドがあります
2. 削除する各ルールに対して実行します：mutation { deleteRule(identifier: "rule_id") { status } }
3. 削除前にユーザーの確認を得ます。

ルールを適用するには、まずエンリッチメントデータを取得します：

query {
  erp(limit: 1) {
    results {
      assetClassNames { id name symbol isVerified assetClassId }
      wallets { id address name parentPlatform }
      allAccounts { name value type }
    }
  }
}

次に、各ルールについて以下を呼び出します。

mutation { upsertRule(rule: $ruleInput) { status } }

$ruleInputの構造とマッピングについては、下記のupsertRule入力形式セクションを参照してください。

Step 7.5 — ルールを検証する（任意ですが推奨）

ルールを適用した後、presyncレポートを再エクスポートするよう提案します。

「ルールを適用しました。仕訳が正しく見えるか検証するために、新しいpresyncレポートをエクスポートしましょうか？」

はいの場合は、エクスポートして分析します（Step 1.5と同様）。次の点を確認します。

• no_account_matched = 0（すべてを網羅）
• クリアリング勘定の純額がほぼゼロ
• 予期しない勘定が出現していない
• デフォルトルールの適用量が妥当（エッジケースのトランザクションのみ）

---

ルールアーキテクチャ

ルールエンジンの仕組み

1つのトランザクションに複数のルールが一致し、それぞれ異なる勘定フィールドを設定できます。エンジンは一致したすべてのルールから勘定を集約します。たとえば、トランザクションのinventory_accountは資産ルールから、income_accountはタグルールから、fee_accountはウォレットルールから設定される場合があります。同じ勘定フィールドについては、より具体的なルール（条件が多いルール）が、より広範なルールより優先されます。

ルールはレイヤーとして機能します。

• デフォルトレイヤー（type: "DEFAULT"）：すべての勘定フィールドを対象とするキャッチオールのフォールバックです。1つのインテグレーションにつき1つのみ設定できます。
• 在庫レイヤー：資産単位またはウォレット単位のルールで、inventory_accountを設定します。
• 動作レイヤー（タグルール）：トランザクションタイプに基づいて収益／費用を設定します。
• 手数料／損益レイヤー：手数料、利益、損失の勘定を設定します。
• オーバーライドレイヤー（特定の組み合わせ）：エッジケースに対応する範囲の狭いルールです。

デフォルトルールは、upsertRuleミューテーションでtype: "DEFAULT"を使用します。rules.jsonでは、デフォルトルールに"is_default": trueを指定します。

在庫レイヤー — 取得原価モードに基づく

重要：デフォルトでは、各在庫ルールの対象とする資産クラスは必ず1つだけにしてください。 1つの在庫ルールに複数の資産クラスを含めると、照合が機能しなくなります。クライアントが明確な理由を示して明示的に依頼した場合に限り、1つのルールに複数の資産クラスを組み合わせてください。取引量の少ない関連資産に独自のルールを設ける必要がない場合は、デフォルトの包括ルールに振り分けてください。

by_asset モード（資産クラス別の在庫）

在庫ルールでは、asset_classを主条件として使用します。ウォレット条件は不要です。

• 資産ごとの在庫：asset_class=Ether → inventory_account=<ETH account> — 重要な資産クラスごとに1つのルール
• デフォルトの在庫：DEFAULTルールでinventory_account=<generic account>をフォールバックとして設定し、取引量の少ない資産に適用します
• 同じ資産を保有する複数のウォレットは、1つの在庫勘定を共有します（取得原価プールに一致します）

勘定科目表（CoA）に汎用の在庫勘定（例：「Inventory Asset」）しかなく、資産ごとの勘定がない場合は、その旨をユーザーに伝え、重要な資産について資産ごとの在庫勘定を作成するよう推奨してください。すべてを1つの包括ルールに黙って割り当ててはいけません。

by_wallet モード（ウォレット別の在庫）

在庫ルールでは、walletを主条件として使用します。ウォレットが異なる勘定を使用する複数の資産タイプを保有している場合は、asset_classと組み合わせることもできます。

• ウォレット＋資産の在庫：wallet=0x... + asset_class=Ether → inventory_account=<ETH account>
• ウォレットごとの包括ルール：wallet=0x... → inventory_account=<default for this wallet>

行動レイヤー（タグベース、ウォレット条件なし）

収益／費用ルールは通常、タグベースで、すべてのウォレットに適用されます。

• 入金ルール：tag=PRODUCT DEPOSIT → income_account=<liability account>
• 償還ルール：tag=PRODUCT REDEMPTION → expense_account=<liability account>
• クリアリングルール：tag=SWAP/BRIDGE/etc. → 同じ勘定に対する対称的なincome_account＋expense_account
• 費用ルール：tag=MARKETING/etc. → expense_account=<expense account>

レンディングタグには個別のクリアリングが必要です。 LENDING LOCKUP/RETURNには、SWAP/BRIDGEとまとめず、専用の「Staked Asset」クリアリング勘定を割り当ててください。これにより、レンディングプロトコルに預けられた資産を確認できます。

手数料・損益レイヤー

条件の設定方法は、取得原価モードによって異なります。

• by_asset モード：CoAの構成に応じて、グローバル（条件なし）、資産ごと、またはウォレットグループごとに設定できます。ユーザーに確認してください。
• by_wallet モード：通常はウォレットごとに設定します。wallet=0x... → fee_account, gain_account, loss_account

存在するデータのみを使用する

• asset_class名は、transaction_profile.txtの検証済みリストから取得する必要があります。表記を正確に一致させてください
• tagsはタグのセクションから取得する必要があります。タグが存在しない場合は、タグベースのルールを作成しないでください
• 勘定科目UUIDはchart_of_accounts.txtから取得する必要があります
• ウォレット識別子はwallets.txtから取得する必要があります

網羅性

すべてのトランザクションが、少なくとも次のルールに該当する必要があります。

• 在庫ルール（資産固有または包括ルール）1つ
• 収益ルールまたは費用ルール1つ
• 手数料ルール
• 損益ルール

ルール名

名前は連携ごとに一意である必要があります。組織に既存の命名規則がある場合は、それに従ってください（existing_rules.txtを確認してください）。一般的なパターン：

• ウォレット番号別：「21」、「56 (VERSE)」、「54 - BS」
• 用途別：「Swap Clearing」、「Gas Fees」、「Staking Rewards」
• 資産別：「ETH Inventory」、「BTC Main Ledger」

既存の命名規則がない場合は、内容がわかる名前を使用してください。

---

技術リファレンス

勘定科目フィールド

ルールでは、次の勘定科目フィールドを設定できます。

• inventory_account
• income_account
• expense_account
• fee_account
• gain_account
• loss_account
• unrealized_gain_loss_account

勘定科目の割り当てには、chart_of_accounts.txtのUUID（勘定科目名の後の括弧内の値）を使用します。

勘定科目を検索する際は、アカウント以外のタイプであるsubsidiary、netsuite_class、netsuite_departmentを必ず除外してください。同じ内部IDが、アカウントとアカウント以外のエンティティの両方に存在する場合があります。

rules.json の形式

[
  {
    "name": "Default",
    "is_default": true,
    "conditions": {},
    "accounts": {
      "inventory_account": "128",
      "income_account": "54",
      "expense_account": "58",
      "fee_account": "235",
      "gain_account": "233",
      "loss_account": "234"
    },
    "is_ignore": false
  },
  {
    "name": "ENA Inventory",
    "conditions": {
      "asset_class": [{"name": "Ethena", "verification_status": "verified"}]
    },
    "accounts": {
      "inventory_account": "019cb750-28f8-72b7-8af0-8c9fba1d7555"
    },
    "is_ignore": false
  },
  {
    "name": "Clearing",
    "conditions": {
      "tags": ["SWAP", "BRIDGE", "INTERNAL TRANSFER"]
    },
    "accounts": {
      "income_account": "131",
      "expense_account": "131"
    },
    "is_ignore": false
  },
  {
    "name": "Spam",
    "conditions": {
      "tags": ["SPAM"]
    },
    "accounts": {},
    "is_ignore": true
  }
]

• "is_default": true を指定してデフォルトルールとしてマークします。これにより、upsertRule を介して type: "DEFAULT" として作成されます
• 値がある条件キーのみを含めます
• is_ignore: true はルールを無視ルールとしてマークします（一致するトランザクションはジャーナルから除外されます）

upsertRule の入力形式

MCP を介してルールを適用する際は、rules.json を次の形式にマッピングします。

{
  "type": "CUSTOM_RULE",
  "identifier": null,
  "name": "ETH Inventory",
  "accounts": {
    "inventory": {"name": "Digital Assets", "value": "uuid", "type": "asset"},
    "income": null,
    "expense": null,
    "fee": null,
    "gain": null,
    "loss": null,
    "unrealizedGainLoss": null
  },
  "filters": {
    "assetClassNames": [{"id": "Ethereum#verified", "name": "Ethereum", "symbol": "ETH", "isVerified": true, "assetClassId": null}],
    "wallets": [],
    "senders": [],
    "recipients": [],
    "platforms": [],
    "tags": [],
    "actions": [],
    "contracts": [],
    "specificIds": [],
    "walletTagsSenders": [],
    "walletTagsRecipients": [],
    "financialActionGroups": [],
    "contactGroupsSenders": [],
    "contactGroupsRecipients": [],
    "isInternalTransfer": null,
    "fromDate": null,
    "toDate": null
  },
  "isIgnore": false
}

rules.json → upsertRule のマッピング

rules.json	upsertRule
is_default: true	type: "DEFAULT"
is_default: false/absent	type: "CUSTOM_RULE"
conditions.asset_class	filters.assetClassNames — erp.assetClassNames から id（Name#verified／Name#unverified）、symbol、isVerified を補完します
conditions.wallets	filters.wallets — erp.wallets から id、address、parentPlatform を補完します
conditions.tags	filters.tags — [{"id": "TAG", "name": "TAG"}] の形式にします
accounts.inventory_account: "uuid"	accounts.inventory: {"name": "...", "value": "uuid", "type": "..."} — erp.allAccounts から補完します
accounts.income_account	accounts.income（同様に補完）
accounts.expense_account	accounts.expense（同様に補完）
accounts.fee_account	accounts.fee（同様に補完）
accounts.gain_account	accounts.gain（同様に補完）
accounts.loss_account	accounts.loss（同様に補完）
accounts.unrealized_gain_loss_account	accounts.unrealizedGainLoss（同様に補完）
is_ignore: true	isIgnore: true

未使用のフィルターフィールドはすべて空の配列にします。未使用のアカウントフィールドはすべて null にします。

---

学んだこと

これらを先回りして適用し、ユーザーが同じ問題に直面するまで待たないでください。

原価基準モードと CoA の不一致：勘定科目表の構造が原価基準モードと一致しない場合は、既存の CoA に合わせて原価基準の方針を変更する選択肢を必ず提示します。多くの場合、これが最もすっきりした解決策です。

在庫ルールごとに 1 つの資産クラス：1 つの在庫ルールに複数の資産クラスを含めないでください。照合が壊れます。重要な資産クラスごとに、それぞれ独自のルールを設定します。

損益は 1 つの勘定科目にまとめられます：ユーザーは、損益勘定科目を分けるのではなく、実現損益をまとめた単一の勘定科目（通常は other_expense タイプ）を好む場合があります。ギャップ分析の際は必ず確認します。

タグはアクティビティです：分類アクティビティとカスタムアクティビティラベルは、ルールエンジンでは相互に置き換え可能です。両方のソースを必ず 1 つの「TAGS」リストに統合します。別々のカテゴリとして提示しないでください。

検証には presync レポートを使用します：presync レポートが正解の基準です。ルールの設計前（現状の把握）と適用後（網羅性の検証）にエクスポートします。重要なシグナルは、no_account_matched エラー、COA Mapping Rule の分布、クリアリング勘定の純残高です。

---

セットアップ

前提条件

• Claude Code がインストールされ、正常に動作していること
• tres-finance MCP サーバーが設定され、対象の組織に接続されていること

MCP の設定

このスキルには、Tres Finance API への GraphQL アクセスを提供する tres-finance MCP サーバーが必要です。MCP の設定には、次の権限を持つ tres-finance サーバーを含める必要があります。

• get_viewer — 接続先の組織を特定します
• graphql_query / graphql_mutation — GraphQL クエリとミューテーションを実行します
• internalAccount、integrationAccount、erp、subTransaction、transaction、report エンティティへの読み書きアクセス

インストール

このファイルを Claude Code のスキル保存先にコピーします。

# Project-level
mkdir -p /path/to/project/.claude/skills/erp-rule-suggestions/
cp SKILL.md /path/to/project/.claude/skills/erp-rule-suggestions/

# Or user-level
mkdir -p ~/.claude/skills/erp-rule-suggestions/
cp SKILL.md ~/.claude/skills/erp-rule-suggestions/