tres-cost-basis

TRES Finance — 取得原価管理

TRES Finance における取得原価計算、戦略の設定、再評価、財務上の問題の確認、および関連する操作をエンドツーエンドで行うスキルです。

---

MCP サーバー

すべての呼び出しでは、user-tres-finance MCP サーバー（TRES Finance MCP コネクター）を使用します。

すべての変数キーとネストされた入力フィールドは、camelCase を使用する必要があります（例：assetClassId。asset_class_id ではありません）。

---

ステップ 1 — 認証して組織を確認する

引数なしで get_viewer を呼び出します。組織名が曖昧な場合は、ユーザーに確認します。

---

ステップ 2 — 取得原価戦略が設定されていることを確認する（計算前の必須条件）

取得原価計算を実行する前に、組織で戦略を定義しておく必要があります。このステップは必須の確認ゲートです。ユーザーが取得原価の計算（セクション D）を希望した場合、または取得原価について初めてサポートを求めた場合は、必ず自動的に実行します。

1. セクション B のクエリを使用して、現在の戦略を取得します。

2. defaultStrategy が返された場合（FIFO、LIFO など、有効な値であればどれでも）、戦略はすでに設定されています。先に進み、ユーザーに次のように伝えます。

   「取得原価戦略は [STRATEGY] に設定されています。続行します。」

3. 戦略が設定されていない場合（クエリの結果が null またはエラー）、利用可能なすべての方式を提示して、選択してもらいます。

   「取得原価を計算する前に、原価計算方式を選択する必要があります。 利用可能な戦略は次のとおりです。

   1. FIFO — 先入先出法。最も早く取得したロットから先に処分します。最も一般的な方式です。
   2. LIFO — 後入先出法。最も最近取得したロットから先に処分します。
   3. AVG — すべてのロットの加重平均原価です。
   4. MAX_GAINS — 原価の最も低いロットから処分し、実現益を最大化します。
   5. MAX_LOSSES — 原価の最も高いロットから処分し、実現損を最大化します（税務上の損失確定に役立ちます）。
   6. FIFO_IMPAIRMENT — 減損会計に対応した FIFO です（減損による評価損を適用する組織向け）。

   どの方式を使用しますか？」

4. ユーザーが戦略を選んだら、セクション C のミューテーションを使用して設定します（デフォルトを 1 つだけ使用する場合は、空の strategyPeriods 配列を指定します）。

5. その後、依頼された操作に進みます（通常はセクション D の計算の実行です）。

このゲートにより、戦略を明示的に選択しないまま計算が実行されることを防ぎます。

---

ステップ 3 — 取得原価計算を実行する

戦略を確認した後、現在の計算ステータス（セクション A）を確認し、計算を実行または再実行するかユーザーに確認します。

1. セクション A のクエリを使用してステータスを取得します。
2. status が IN_PROGRESS の場合、すでに実行中であることを伝え、完了まで待つか尋ねます。

   「取得原価計算は現在実行中です（開始時刻：[time]）。完了まで待ちますか？」

3. status が DONE の場合、前回の実行日時を伝え、次のように尋ねます。

   「取得原価は [lastFinishedAt] に最後に計算されました。今すぐ再計算しますか、それとも既存の結果を表示しますか？」

4. status が ITEM_NOT_FOUND の場合、この組織ではこれまで計算が実行されていません。すぐに実行に進みます。
5. ユーザーの確認後（または初回実行時）、セクション D のミューテーションを使用して計算を実行します。
6. status = "DONE" になるまで、約 10 秒ごとにステータスを確認します。
7. 完了したら、自動的に資産ごとの結果（セクション E）と財務上の問題（セクション F）を表示します。

このステップにより、データを確認する前に、常に最新の結果を得られ、計算状況を把握できます。

---

利用可能な操作

ユーザーの依頼に応じて、以下の該当するセクションに従ってください。 「取得原価について教えてほしい」のような一般的な質問をするユーザーも多くいます。その場合は、ステップ 1～3（認証、戦略の確認、計算の実行）を行ってから、結果を表示します。

---

A. 取得原価の計算状況を確認する

取得原価の計算が実行中か、完了しているか、または最後に実行された日時をユーザーが尋ねた場合に使用します。

query CostBasisGetStatus {
  costBasisGetStatus {
    status
    firstStartedAt
    lastFinishedAt
    updatedAt
  }
}

status の値：DONE、IN_PROGRESS、ITEM_NOT_FOUND（未計算）。

ステータスを明確に伝えます。IN_PROGRESS の場合は、まだ実行中であることをユーザーに伝え、完了まで待つよう案内します。DONE の場合は、最後に完了した日時を伝えます。

---

B. 現在の取得原価戦略を確認する

デフォルトの戦略と、期間ごとの戦略の上書きを取得します。

query GetCostBasisStrategyByDate {
  getCostBasisStrategyByDate {
    response {
      strategyPeriods {
        startDate
        endDate
        strategy
      }
      defaultStrategy
    }
  }
}

デフォルトの戦略と、期間ごとの上書きを明確に提示します。戦略： FIFO、LIFO、AVG、MAX_GAINS、MAX_LOSSES、FIFO_IMPAIRMENT。

ユーザーから尋ねられた場合は、それぞれの意味を説明します：

• FIFO — 先入先出。最も早く取得したロットから売却します。
• LIFO — 後入先出。最も最近取得したロットから売却します。
• AVG — すべてのロットの加重平均原価です。
• MAX_GAINS — 原価の最も低いロットから売却し、実現益を最大化します。
• MAX_LOSSES — 原価の最も高いロットから売却し、実現損失を最大化します（タックスロス・ハーベスティング）。
• FIFO_IMPAIRMENT — 減損会計に対応した FIFO です。

---

C. 取得原価戦略を更新する

ユーザーがデフォルトの戦略を変更する、または戦略の適用期間を設定する場合に使用します。

実行する前に、必ずユーザーの確認を得てください — 戦略を変更すると、今後の取得原価計算すべてに影響し、再計算が必要になります。

mutation UpdateCostBasisStrategyByDate(
  $defaultStrategy: CostBasisStrategy!,
  $strategyPeriods: [CBStrategyPeriodInput]!
) {
  updateCostBasisStrategyByDate(
    defaultStrategy: $defaultStrategy,
    strategyPeriods: $strategyPeriods
  ) {
    success
    message
  }
}

変数の例：

{
  "defaultStrategy": "FIFO",
  "strategyPeriods": [
    {
      "startDate": "2024-01-01T00:00:00Z",
      "endDate": "2024-12-31T23:59:59Z",
      "strategy": "LIFO"
    }
  ]
}

CostBasisStrategy の列挙値：FIFO、FIFO_IMPAIRMENT、LIFO、AVG、MAX_GAINS、MAX_LOSSES。

期間ベースの設定に更新する場合、既存の期間を誤って上書きしないよう、最初に（セクション B で）既存の期間を取得します — このミューテーションはすべての期間を置き換えます。

戦略の変更が正常に完了したら、取得原価の再計算を実行するかユーザーに確認します（セクション D）。

---

D. 取得原価の計算を開始する

前提条件：計算を開始する前に、戦略が定義されていることを確認するため、ステップ 2（戦略の確認）を実行します。設定されていない場合、ユーザーは最初に戦略を選択する必要があります。

取得原価の計算を開始（または再開）します。特定の資産を対象にすることも、すべてを再計算することもできます。

mutation TriggerCostBasis($assetClassIds: [Int]) {
  triggerCostBasis(assetClassIds: $assetClassIds) {
    success
  }
}

• すべてを再計算するには、assetClassIds: null を渡します（または省略します）。
• 特定の資産を再計算するには、資産クラス ID の配列（例：[42, 88]）を渡します。

資産クラス ID を確認するには、最初に assetBalance または assetClass をクエリします：

query AssetClasses($limit: Int) {
  assetClass(limit: $limit) {
    results { id symbol name }
  }
}

開始後 — 完了までポーリングする

正常に開始された後（success: true）、セクション A のクエリを使用してステータスをポーリングします。小規模な組織では通常 10～60 秒かかりますが、大規模な組織では数分かかることがあります。

1. Trigger → success: true
2. Poll costBasisGetStatus every ~10 seconds
3. When status = "DONE" → proceed to show results (Section E)

ステータスが DONE になるまでは、結果を提示したり、レポートのダウンロードを案内したりしないでください。IN_PROGRESS の間は、ユーザーに簡潔な待機メッセージを表示します。

---

E. 資産ごとの取得原価の結果を確認する

資産とウォレットのペアごとに、取得原価の内訳（総原価、実現益、売上原価、現在の在庫など）を表示します。

重要：organizationBalance ではなく、assetBalance クエリを使用します。assetBalance クエリは、各資産にネストされた FifoCostBasisQuery 由来の costBasis フィールドを持つ、ウォレットごとの資産行を返します。

query AssetBalanceWithCostBasis($limit: Int, $offset: Int) {
  assetBalance(limit: $limit, offset: $offset) {
    totalCount
    results {
      asset {
        symbol
        name
      }
      belongsTo {
        name
      }
      calculatedBalance
      assetFifoCostBasis
      totalProfitLoss
      costBasis {
        costBasis
        totalRealizedGains
        totalShortTermRealizedGains
        totalLongTermRealizedGains
        totalCost
        totalRunningInventoryQuantity
        cogs
        proceeds
        runningBalance
      }
    }
  }
}

変数：{"limit": 50, "offset": 0}

totalCount が 50 を超える場合は、offset を 50 ずつ増やしてすべての結果を取得するまで再度フェッチします。

主なフィールドの説明

• assetFifoCostBasis — この資産とウォレットのペアに対する取得原価の合計（最上位の簡易フィールド）。
• totalProfitLoss — 実現損益の合計（最上位の簡易フィールド）。
• costBasis — 詳細を含むネストされたオブジェクト（未計算の場合は null）：
  • costBasis / totalCost — 現在の在庫の総原価。
  • totalRealizedGains — 実現益／実現損の純額。
  • totalShortTermRealizedGains / totalLongTermRealizedGains — 保有期間別の内訳。
  • cogs — 処分にかかる売上原価。
  • proceeds — 処分による収入の合計。
  • totalRunningInventoryQuantity — 現在の在庫数量。
  • runningBalance — トークン残高の推移。

結果の提示 — 全体像

すべてのページを取得したら、結果を次の2つのグループに分けます。

グループ1 — 取得原価データがある資産（costBasis が null ではない）： 実現損益の絶対値が大きい順に並べた表で提示します。列は次のとおりです。 資産、ウォレット、保有量、取得原価（$）、実現損益（$）。 色分けを使用します。利益は緑色／「+」、損失は赤色／「-」で示します。

グループ2 — 取得原価がない資産（costBasis が null かつ calculatedBalance != 0）： これらは、取得原価が計算されていない資産です。通常、法定通貨価格の欠落、取引がないこと、または未検証／スパム資産が原因です。次のような明確な見出しの下に分けて提示します。

取得原価データがない資産： 以下の資産には残高がありますが、取得原価は計算されていません。通常、取得原価を計算する前に解決が必要な法定通貨価格が欠落していることを意味します。

資産、ウォレット、保有量、考えられる原因についての注記（スパムトークン、NFT、法定通貨価格の欠落など）を表示します。

ユーザーが全体像を把握できるよう、常に両方のグループを表示します。 グループ2に重要な資産（スパム／仮想資産ではないもの）が含まれる場合は、財務上の問題のクエリ（セクションF）も重大度を HIGH に絞り込んで実行し、missing_fiat の問題を確認して、併せて報告します。

法定通貨価格の欠落に関する問題が見つかった場合は、価格クエリ（セクションG.1）を使用して、該当する各資産の取引時点の過去価格を自動的に検索します。検索した価格をユーザーに提示し、一括法定通貨編集（セクションG.2）で適用することを提案します。

推奨：両方のグループのスタイル付きテーブルと財務上の問題の概要を含む HTML ダッシュボードファイルを生成します。outputs フォルダーに保存し、ユーザーにリンクを共有します。

標準の数値書式を使用します。

• 法定通貨の値が $1M 以上：「$X.XXXM」、$1K 以上：「$X.XXK」、それ未満：「$X.XX」
• 正の利益：「+」を付ける、負の値：「-」を付ける

---

F. 財務上の問題を確認する

財務上の問題とは、取得原価の計算中に検出される問題です。残高のマイナス、法定通貨価格の欠落、循環送金などが該当します。

query FinancialIssues($limit: Int, $offset: Int, $severity: String) {
  financialIssue(limit: $limit, offset: $offset, severity: $severity) {
    totalCount
    results {
      id
      type
      severity
      message
      balanceImpact
      assetClass {
        id
        symbol
        name
      }
      assetClassId
      internalAccount {
        name
      }
      internalAccountId
      tx {
        identifier
        timestamp
      }
      subTx {
        id
        amount
      }
    }
  }
}

フィルターオプション

重要：フィルターの値は小文字にする必要があります。API は DB に保存されている値を使用します。

• severity：「high」、「medium」、「low」
• クエリで type によるフィルタリングは行わないでください。代わりに、すべての問題を取得してから、表示時にフィルタリング／グループ化します。type フィルターでは、表示名と一致しない可能性がある内部 DB 値が使用されます。

実際に返される問題の種類

type フィールドは、次のような小文字の文字列を返します。

• missing_fiat — サブ取引に法定通貨価格がありません。取得原価の正確性に影響します。一括法定通貨編集で解決できます（セクションG）。
• negative_balance — 在庫がゼロを下回りました（取得量より売却量が多い状態）。通常、流入取引が不足していることを意味します。
• result_was_rounded — 計算中に軽微な丸めが行われました。重大度は低です。
• ignored — サブ取引がスキップされました（例：同一アカウントへの内部送金）。
• no_opposite_tx — 内部送金に対応する取引がありません。
• circular_internal_sbxs — 内部送金の照合で循環依存が発生しています。

結果を重大度別にグループ化し、重大度 HIGH の問題を先に提示します。最もよくあるパターンは、重大度 HIGH の missing_fiat が少数と、重大度 LOW の result_was_rounded が多数あるケースです。LOW の問題は一つずつ列挙するのではなく、件数を要約します。

---

G. 法定通貨価格の欠落を修正する

これは2段階のフローです。まず過去価格を検索し、その後適用します。

G.1 — 過去のトークン価格を検索する

TRES MCP の価格クエリを使用して、法定通貨額が欠落しているトークンの過去の価格を取得します。これは、CoinGecko、CoinMarketCap、取引所などの情報を集約する、プラットフォームの価格エンジンを利用します。

特定の時刻における単一の資産の場合：

query GetStatelessPricing(
  $platform: Platform!,
  $assetIdentifier: String!,
  $currencies: [Currency]!,
  $timestamp: DateTime
) {
  getStatelessPricing(
    platform: $platform,
    assetIdentifier: $assetIdentifier,
    currencies: $currencies,
    timestamp: $timestamp
  ) {
    prices
    assetClassId
    symbol
  }
}

変数の例：

{
  "platform": "ETHEREUM",
  "assetIdentifier": "0x...contractAddress",
  "currencies": ["USD"],
  "timestamp": "2020-11-24T09:01:26Z"
}

複数の資産を一度に取得する場合（資産クラス ID による指定）：

query GetBatchPricing($requests: [GetBatchPricesByAssetClassRequest]!) {
  getBatchStatelessPricingByAssetClass(requests: $requests) {
    prices
    assetClassId
    symbol
  }
}

変数の例：

{
  "requests": [
    {
      "assetClass": "4272",
      "currencies": ["USD"],
      "timestamp": "2018-06-18T19:13:45Z"
    },
    {
      "assetClass": "4272",
      "currencies": ["USD"],
      "timestamp": "2020-11-24T09:01:26Z"
    },
    {
      "assetClass": "9082",
      "currencies": ["USD"],
      "timestamp": "2020-11-27T20:06:54Z"
    }
  ]
}

prices フィールドは、{"usd": 0.015} のような JSON オブジェクトを返します。

法定通貨額の欠落を解消するフローでの使用方法：

1. 財務上の問題（セクション F）から、各 missing_fiat の問題について assetClass.id と tx.timestamp を収集します。
2. 問題ごとに 1 つのリクエストを指定して、getBatchStatelessPricingByAssetClass を呼び出します。
3. 結果をユーザーに提示します：

   「法定通貨額が欠落している取引について、過去の価格が見つかりました：

   • 2018-06-18 の CHSB：トークンあたり $0.015
   • 2020-11-24 の CHSB：トークンあたり $0.085
   • 2020-11-27 の vBUSD：トークンあたり $0.021

   これらの価格を適用しますか？」

4. ユーザーが確認したら、セクション G.2（一括法定通貨額編集）を使用して適用します。

試す価格ソース：デフォルトのソースが空の結果を返した場合は、次の apiSource 値を順番に試します：COINMARKETCAP、CRYPTO_COMPARE、REGULAR_FLOW、COINBASE、BINANCE、KRAKEN。リクエストで apiSource フィールドを渡します：

{
  "requests": [
    { "assetClass": "4272", "currencies": ["USD"], "timestamp": "2020-11-24T09:01:26Z", "apiSource": "COINMARKETCAP" }
  ]
}

重要：価格クエリで価格データが利用できない場合、prices: {}（空のオブジェクト）が返されます。これは、知名度の低いトークン、上場廃止されたトークン、DeFi でラップされたトークンではよくあることです。諦める前に、複数のソースを試してください。

すべての価格ソースでトークンの結果が空の場合は、その旨をユーザーに伝え、手動で価格を指定するよう依頼します。トークンについて把握している場合は、おおよその値を提案してください（例：BUSD に連動するトークン ≈ $1.00）。

G.2 — 法定通貨額の一括編集

日付範囲を指定して、資産の法定通貨建て単価を上書きします。MISSING_FIAT の問題を修正したり、OTC 価格を訂正したりする場合に便利です。

実行前に、必ずユーザーにパラメーターを確認してください。この操作では、多数のサブ取引に法定通貨額を書き込みます。

mutation BulkFiatEdit(
  $assetClassId: Int!,
  $currency: Currency!,
  $startDate: Date!,
  $endDate: Date!,
  $unitPrice: Float!,
  $updateExistingFiat: Boolean
) {
  bulkFiatEdit(
    assetClassId: $assetClassId,
    currency: $currency,
    startDate: $startDate,
    endDate: $endDate,
    unitPrice: $unitPrice,
    updateExistingFiat: $updateExistingFiat
  ) {
    success
    message
  }
}

変数の例：

{
  "assetClassId": 42,
  "currency": "USD",
  "startDate": "2024-01-01",
  "endDate": "2024-01-31",
  "unitPrice": 1.0,
  "updateExistingFiat": false
}

• updateExistingFiat: false（デフォルト）— 法定通貨額が欠落している値のみを補完します。
• updateExistingFiat: true — 範囲内のすべての法定通貨額を上書きします。

assetClassId を調べるには、まずシンボルで assetClass をクエリします。

G.1 で検索した価格を適用する場合は、検索した単価を使用し、他の取引の価格を上書きしないよう、取引日付を中心に日付範囲を狭く設定します（startDate と endDate は同じ日付にします）。

法定通貨額を一括編集した後は、ユーザーに原価基準の再計算（セクション D）を実行するよう提案してください。

---

H. 再評価と減損

再評価では、特定の時点における在庫ロットの公正市場価値（FMV）を調整します。減損は、FMV が取得原価を下回る場合の特殊なケースです。

H.1 — 再評価の一覧表示

query GetReevaluations($limit: Int, $offset: Int, $assetClassId_In: [ID]) {
  reevaluation(
    limit: $limit,
    offset: $offset,
    assetClassId_In: $assetClassId_In,
    ordering: "-timestamp"
  ) {
    totalCount
    results {
      id
      timestamp
      unitPrice
      currency
      isImpairment
      assetClass {
        id
        symbol
      }
      appliedCostBasis {
        id
        totalCost
        revaluedCostAdjustment
        internalAccount {
          id
          name
        }
      }
    }
  }
}

H.2 — 再評価の作成

実行前に、必ずユーザーに確認してください。

mutation CreateReevaluation($reevaluations: [ReevaluationObjectType]!) {
  createReevaluation(reevaluations: $reevaluations) {
    reevaluationIds
  }
}

変数の例：

{
  "reevaluations": [
    {
      "unitPrice": "45000.00",
      "timestamp": "2024-12-31T23:59:59Z",
      "assetClassId": 1,
      "currency": "USD",
      "isImpairment": false
    }
  ]
}

• isImpairment: false — 通常の再評価（時価評価）。
• isImpairment: true — 減損処理。

再評価を作成すると、調整を台帳に反映するための手動取引も作成されます。この副作用をユーザーに伝えてください。

作成後は、原価基準の再計算（セクション D）を実行するよう提案してください。

H.3 — 再評価の更新

mutation UpdateReevaluation(
  $reevaluationId: Int!,
  $unitPrice: Decimal!,
  $timestamp: DateTime!,
  $assetClassId: Int!,
  $currency: Currency!
) {
  updateReevaluation(
    reevaluationId: $reevaluationId,
    unitPrice: $unitPrice,
    timestamp: $timestamp,
    assetClassId: $assetClassId,
    currency: $currency
  ) {
    status
  }
}

H.4 — 再評価の削除

mutation DeleteReevaluation($reevaluationId: Int!) {
  deleteReevaluation(reevaluationId: $reevaluationId) {
    status
  }
}

削除すると、関連する手動取引も台帳から削除されます。

---

I. Spec-ID ルール（特定ロットの処分）

Spec-ID ルールを使うと、資産を処分する際に、使用する取得ロットをユーザーが正確に指定できます。これにより、特定の取引についてデフォルトの戦略（例：FIFO）を上書きできます。

I.1 — Spec-ID ルールの表示

query CostBasisSpecIdRules(
  $limit: Int,
  $offset: Int,
  $outflowSubTransaction_In: [String]
) {
  costBasisSpecIdRule(
    limit: $limit,
    offset: $offset,
    outflowSubTransaction_In: $outflowSubTransaction_In
  ) {
    totalCount
    results {
      id
      outflowSubTransaction {
        id
        amount
        timestamp
        asset { symbol }
        belongsTo { name }
      }
      disposedLotSubTransaction {
        id
        amount
        timestamp
      }
      amountToDispose
      priority
    }
  }
}

I.2 — spec-ID ルールを設定する

実行前に必ずユーザーに確認してください。 これにより、指定したアウトフローのサブトランザクションに関する既存のルールはすべて置き換えられます。

mutation SetSpecIdRules(
  $subTransactionId: ID!,
  $specIdRules: [SpecIdRuleInput]!
) {
  setSpecIdRules(
    subTransactionId: $subTransactionId,
    specIdRules: $specIdRules
  ) {
    success
  }
}

変数の例：

{
  "subTransactionId": "12345",
  "specIdRules": [
    {
      "disposedLotSubTransactionId": "67890",
      "amount": 1.5,
      "priority": 1
    },
    {
      "disposedLotSubTransactionId": "67891",
      "amount": 0.5,
      "priority": 2
    }
  ]
}

• subTransactionId — アウトフロー（処分）のサブトランザクション
• disposedLotSubTransactionId — 原価ロットとして使用するインフロー（取得）のサブトランザクション
• amount — そのロットから処分する数量
• priority — 処理順序（1 = 最初）

ルールを設定した後、原価基準の再計算を実行するよう提案してください（セクション D）。

I.3 — spec-ID ルールを削除する

mutation DeleteSpecIdRules($subTransactionId: ID!) {
  deleteSpecIdRules(subTransactionId: $subTransactionId) {
    success
  }
}

---

J. 在庫の完全保存の設定

デフォルトでは、TRES はストレージを節約するため、古い在庫ロットをトリミングします。ユーザーが在庫キュー全体を表示する必要がある特定のトランザクションでは、在庫の完全保存を切り替えます。

mutation SetFullCostBasisInventoryConfiguration(
  $subTransactionId: ID,
  $enableFullInventory: Boolean
) {
  setFullCostBasisInventoryConfiguration(
    subTransactionId: $subTransactionId,
    enableFullInventory: $enableFullInventory
  ) {
    success
  }
}

これにより、対象資産の既存の原価基準レコードが削除され、自動的に再計算が実行されます。

---

K. 原価基準レポートをエクスポートする

TRES では、複数の種類の原価基準レポートを利用できます。availableReportTypes クエリで利用可能なエクスポートを確認してから、organizationBalance で実行します：

query AvailableReports {
  availableReportTypes {
    name
    exportType
    entitiesType
    llmDescription
  }
}

原価基準関連のレポートタイプは次のとおりです：

• COST_BASIS_STACK_PER_ACCOUNT — ウォレットごとにグループ化した在庫ロット
• COST_BASIS_STACK_PER_ASSET — 資産ごとにグループ化した在庫ロット
• COST_BASIS_INVENTORY — 在庫の詳細全体
• COST_BASIS_ROLL_FORWARD — 期間ごとの繰越明細
• REEVALUATION — 再評価レコード

エクスポートするには、エクスポートパラメーターを指定して organizationBalance を使用します：

query ExportCostBasisReport(
  $exportName: String,
  $exportFormat: String,
  $currency: String,
  $outputFormat: ReportOutputFormat
) {
  organizationBalance(
    exportName: $exportName,
    exportFormat: $exportFormat,
    currency: $currency,
    outputFormat: $outputFormat
  ) {
    totalCount
  }
}

変数の例：

{
  "exportName": "Cost Basis Stack Per Asset - April 2024",
  "exportFormat": "COST_BASIS_STACK_PER_ASSET",
  "currency": "usd",
  "outputFormat": "XLSX"
}

次に、status = "DONE" になるまで report クエリをポーリングし、ダウンロードリンクを提示します：

query Reports($limit: Int, $offset: Int) {
  report(limit: $limit, offset: $offset, ordering: "-created_at") {
    totalCount
    results {
      id
      name
      status
      downloadUrl
      createdAt
    }
  }
}

重要：ステータスが IN_PROGRESS の間は、ダウンロードリンクを提示しないでください。ファイルはまだ S3 に書き込まれていないため、リンクを開くと NoSuchKey エラーが返されます。ステータスが "DONE" になるまで約 10 秒ごとにポーリングし、その後 downloadUrl をユーザーに提示してください。

---

ガードレール

• 書き込み前に確認する：変更操作（戦略の変更、再評価、spec-ID ルール、一括法定通貨編集、計算の実行）を行う前に、必ずユーザーに確認してください。
• 再計算に関するリマインダー：設定変更（戦略、再評価、spec-ID、法定通貨編集）の後は、変更を反映するために原価基準の再計算が必要であることをユーザーに伝えてください。
• ロックされた期間：変更操作が「locked period」エラーで失敗した場合は、タイムスタンプがロックされた会計期間内にあること、先にロックを解除する必要がある場合があることをユーザーに伝えてください。
• 実行前にステータスを確認する：再計算を実行する前に現在のステータスを確認してください。すでに IN_PROGRESS の場合は、まだ処理中であることをユーザーに知らせてください。

---

制限事項 — MCP では利用できません

以下の取得原価機能はバックエンドに存在しますが、MCP GraphQL API では公開されていないため、このスキルでは実行できません。

1. ウォレットごとの再割り当てフロー — 2 段階の再割り当てプロセス （統合インベントリ -> ウォレットごとの分割）は、API から直接呼び出せる操作ではなく、 組織の設定によってトリガーされる内部バックエンド操作です。

2. 未加工のインベントリキューの詳細表示 — assetRunningQueueFifo フィールドは FifoCostBasisQuery で利用できますが、大きな JSON データを返します。キューデータは、 TRES ダッシュボード、またはエクスポートしたレポート （COST_BASIS_STACK_PER_ACCOUNT / COST_BASIS_STACK_PER_ASSET）で確認するのが最適です。

3. ショートポジション／ローンキューの管理 — ショートポジションの追跡（ローン キュー）は組織設定のレベルで構成され、自動的に計算されます。ローンキューを表示または 操作するための直接的な API はありません。

4. 取得原価計算の内部処理 — 実際の計算エンジン （CostBasisCalculator、CostBasisManager）はサーバー側で実行されます。計算をトリガーして 結果を読み取ることはできますが、内部の計算フロー、キャッシュ、S3 キューの永続化を 制御することはできません。

5. 内部振替の取得原価マッピング — 内部振替においてウォレット間で取得原価をどのように引き継ぐかは 自動処理され、API を通じてトランザクションごとに設定することはできません。

これらの機能を利用する場合は、TRES Finance ダッシュボードを案内するか、 オフライン分析用に該当する取得原価レポートをエクスポートするよう提案してください。