DeFiの損益計算｜複数ウォレット・チェーンで残高の差では合わない理由と集計方法

ある会社が、手元資金の一部をDeFiで運用しています。ウォレットは複数あり、使うチェーンもいくつかにまたがります。月末、経理から「今月の損益はいくらか」と聞かれた担当者が、各ウォレットの月初と月末の残高の差を足し合わせてみました。

出てきた数字は、実態とかけ離れていました。

• 自社のウォレットAからBへ移しただけなのに、Aでは損失、Bでは利益に見える
• ブリッジでチェーンをまたいだだけなのに、売買したように見える
• 借りたお金が、利益に見える

どれも、残高の差だけを見ていることが原因です。AからBへの移動が損益でないと分かるには、AもBも同じ会社のものだと知っていなければなりません。だから先に「誰の、何の損益か」を決めます。そのうえで、損益は持っているものの価値の変化から、外から入ってきた分と外へ出た分を差し引いて計算します。

もう一つ、分類や会計方針は、あとから変わることがあります。そのときも根拠から計算し直せるよう、取引の元の記録、ウォレット間の振替、プロトコルに預けた・借りたといった持ち高、値段の付け方を、別々に持っておきます。そうすれば、計算し直せる補助元帳になります。以下では、この会社の担当者が、データの取得から値段付け、確定、障害からの復旧までを順に組み立てていく流れで見ていきます。

この記事でわかること

• 残高の差ではなく、どんな式で損益を出すか
• 自社内の送金やブリッジを、損益から正しく除く方法
• 値段の根拠の残し方、障害時の止め方、受け入れ試験の進め方

まず「誰の、何の損益か」を決める

同じトランザクションでも、意味は場面によって違います。資産運用の収益なのか、顧客の預かり資産の移動なのか。手数料か、借入か、担保の差し入れか。APIやインデクサー（チェーンのデータを集めて検索しやすくするサービス）を選ぶ前に、集計の単位を次の4つの問いで決めます。

• 誰の分か：法人、事業、ファンド、顧客など、どのウォレットの集まりを1つの帳簿に入れるか。
• 何を数えるか：手元のトークンだけでなく、LPポジション、預けた資産の請求権、借入の債務、まだ受け取っていない報酬、ブリッジで移動中の資産を含めるか。
• どう値段を付けるか：円・ドルなどの基準通貨、どの時点の価格か、実現と未実現、ガス代の扱い。
• いつ確定とするか：チェーンごとのファイナリティ、日次の締め、あとからの訂正をどの状態で認めるか。

冒頭で見たとおり、単なる「期末残高－期首残高」では損益になりません。そこで基本の式では、持っているものの価値と、外部との入出金を分けて考えます。

期間損益 = 期末純資産 - 期首純資産
         - 外部入金 + 外部出金

純資産   = 現物資産 + プロトコルへの請求権
         + 未請求報酬 - 債務 - 未払費用

冒頭の例に当てはめると、自社のウォレットAからBへの移動は「外部」の入出金ではないので、損益に影響しません。借りたお金は手元の資産を増やしますが、同じだけ債務も増えるので、純資産は変わりません。

ただし、これは技術上の集計の模型です。収益を認識する時点、取得原価の計算方法、税務上の取引の区分は、会計・税務の方針として別に決めます。元帳には、採用した方針のバージョンを持たせます。

データを4つの層に分けて持つのは、なぜか

元のデータ、その意味、持ち高、値段を別々に持っておけば、分類や価格をあとで直しても、元のデータから計算し直せます。だから、取得した生のデータをいきなり「利益」に変えません。

分ける層は次の4つです。下の層を残しておき、上の層はいつでも作り直せるようにします。

正規化イベントで扱う取引の種類は、送付、交換、預入、引出、借入、返済、請求、手数料です。各層を一意に見分けるためのキーは、後半の「実装する人向けの詳細」にまとめています。

預けた・借りたといった中身を、どう読み取るか

DeFiでは、ウォレットのトークンの出入りと、実際に起きたことが一致しないことがあります。たとえばAaveでは、資産を預けると、それに対応するaTokenが利息を反映します。借り入れると、元本と利息を含む債務のポジションができます（Aave V3の公式説明）。Uniswap v3の集中流動性のポジションは、価格の範囲、流動性、まだ回収していない手数料を持ちます。ウォレットに見えるトークン残高だけでは、その価値を再現できません（Uniswap「Concentrated Liquidity」）。

つまり、ERC-20のTransferイベント（トークンが移動したことを示す記録）だけでは、何が起きたかは分かりません。そこで、プロトコルごとに読み取り部品（アダプター）を用意します。アダプターは、プロトコル、デプロイ先、コントラクトのバージョンごとに、次のことをはっきりさせます。

• 入力にするログと呼び出し
• 作り出すイベントと、ポジションの変化
• 対応していない条件

プロキシのアップグレードや新しいイベントの形は、アダプターが想定していない入力です。見つけたら、これまでの分類を自動で続けず、「未対応」の状態に送ります。

代表的な操作では、見かけのトークンの動きと、読み取るべき中身が次のように違います。

操作ごとに誤った分類を防ぐための確認項目は、後半にまとめています。たとえば借入なら「入金を収益にしない」ことです。

自社のウォレット間の送金とブリッジは、どう相殺するか

同じ会社のウォレットAからウォレットBへの送金は、外部との入出金ではありません。送った側と受けた側は別々の記録として持ちつつ、同じ振替のグループとして結び付けます。そして、会社全体の損益では相殺します。ガス代だけは、別の記録として残します。

ブリッジはもう少し複雑です。チェーンAでのロック・バーンと、チェーンBでのミント・リリースは、別のトランザクションになります。時刻も違い、数量が異なる場合もあります。そこで、メッセージID、送受信のコントラクト、トークンの対応表、数量、時刻の範囲を使って結び付け、次の4つの状態を持たせます。

1. 開始済み：送る側のチェーンで確定したが、受ける側をまだ確認していない。
2. 対応済み：送受信を結び付け、会社の中での移動として相殺した。
3. 期限切れ：想定した時間を過ぎたため、例外の待ち行列へ移した。
4. 返金済み：返金の記録まで結び付けて完了した。

金額や近い時刻だけで自動的に結び付けると、同じ額の送金が重なったときに取り違えます。プロトコル独自のメッセージIDがないブリッジでは、結び付けの信頼度を下げ、担当者が確かめた記録を残します。

ブリッジで移動中の資産を0円にすると、一時的に巨額の損失が出てしまいます。だから移動中の資産は「ブリッジ処理中」という別のポジションとして持ちます。

値段の根拠を、どう残すか

数量が正しくても、どの時点のどの市場の価格かを後から再現できなければ、損益は監査できません。そこで数量の元帳と価格の評価を分け、評価の記録に次のものを残します。

• 資産ID、基準通貨、価格
• 観測した時刻、データ源、市場・フィードID、取得した時刻
• 品質の印（フラグ）

価格データの提供元であるChainlinkのData Feedsでも、ラウンドのデータには値だけでなく更新時刻が含まれます。古い値をそのまま使わない作りが必要です（Chainlink Data Feeds API Reference）。

値段付けで決めておくことは、次の4つです。

• ステーブルコインを常に1ドルと決めつけない。使う価格源と、ペッグ（本来の価値との連動）が外れたときの規則を決める。
• 取引の少ないトークンは、最後の価格を持ち越さず「評価できない」と表す。
• LPや保管庫の持ち分は、中身の資産と債務を展開した純資産の価値と、実際に引き出せる価格を分ける。
• 日次の締めでは、UTCのブロック時刻と業務のタイムゾーンの対応を残す。

価格がないものを0円にすると、損失が大きく出すぎます。前日の価格をいつまでも使うと、損失が隠れます。品質の印を損益のAPIまで伝え、「確定値」「暫定値」「評価できない」を画面とエクスポートで見分けられるようにします。

チェーンの記録が置き換わったら、どう計算し直すか

チェーンでは、いったん記録された取引が再編成で置き換わることがあります。しかも、どの時点で確定とみなすかの規則はチェーンごとに違います。確定までの承認の数を、すべてのチェーンに同じ値で使い回してはいけません。

そこで集計の記録には、次の状態を持たせます。

• 観測 → 暫定 → 確定
• 訂正するときは、置き換え済み → 再生（計算し直し）
• 原因が分からないものは、隔離（未知のコントラクト、欠けたブロック、価格なし、対応できない送付など）

同じ原票と同じバージョンからは、必ず同じ結果が出るようにしておきたいところです。そのため訂正するときも、過去の記録は上書きしません。どれが正しいデータかの印と、読み取り部品・価格・方針のそれぞれのバージョンを残します。対象の期間だけを計算し直せる区切り（チェックポイント）も設けます。

Ethereumのデータの取り方や状態の名前は、後半の「実装する人向けの詳細」にまとめています。

障害が起きたら、どこを止め、いつ再開するか

障害が起きても、確かめたあとで計算し直せるよう、数量や記録は捨てずに残します。影響する範囲は暫定や隔離に回し、確かめられてから再開します。

ダッシュボードに総額が出ていても、裏に例外が隠れていることがあります。だからSLO（サービス水準の目標）には、「更新が速い」ことに加えて、次のものを入れます。

• チェーンごとの最後に取得したブロック、分類できていないイベントの数
• 価格が欠けている額、結び付けできていないブリッジの件数
• 計算し直しの遅れ、残高を突き合わせたときの差額

例外が隠れたままなら、総額が出ていても完了ではありません。

受け入れ試験は、どう進めるか

受け入れ試験は、小さな実際の取引の並びで正しさを確かめるところから始めます。そのあと、異常な場面を足していきます。ウォレットを最初からたくさん取り込む必要はありません。合格の条件は次の6つです。

PoC（本番前の小さな試験運用）の範囲は、2〜3チェーン、2ウォレット、代表的なプロトコル、1つのブリッジに絞ります。期待する仕訳・ポジション・損益を手で計算した試験データを作り、まず正常な場面で一致させます。一致したら、次の異常を加えます。

• チェーンの再編成、RPCのタイムアウト
• 見たことのないトークンの小数桁
• プロキシのアップグレード、価格の停止

計算結果をブロックチェーンにも記録すべきか

損益の根拠になるのは、ウォレットが誰のものか、社内の振替、価格、会計方針、手作業の訂正です。どれもチェーンの外の情報です。計算結果をブロックチェーンに書き込んでも、誤った結果が書き換えられなくなるだけで、根拠は強くなりません。損益の正しさは保証されないのです。

1つの会社の中で管理するなら、別の方法の方が扱いやすくなります。原票のハッシュ、バージョン、承認の履歴を、改ざんに気づける監査ログに残す方法です。訂正もプライバシーも扱いやすくなります。

チェーンへの記録を検討するのは、独立した複数の組織が同じ締めの結果に合意し、中央の運営者を信頼せずに確かめる必要がある場合だけです。そのときは、集計バッチのハッシュや署名済みのルートを記録します。それでも、ウォレットの帰属、価格の正しさ、会計・税務の判断は、チェーンの合意では決まりません。

集計した損益を会社の財務統制へつなぐ場合は、日次の突き合わせと職務の分離を企業のデジタル資産保有と内部統制で、DeFi運用の上限と回収の手順を企業財務のDeFi運用ポリシーで扱っています。ポジションの清算リスクを見張る側の設計はDeFiポジション監視と清算リスク対策をご覧ください。

実装する人向けの詳細

ここからは、さきほどの会社で取得・読み取り・元帳を実際に組む開発担当者の話です。

各層の一意キーと、アカウントの見分け方

層ごとに、次のキーで記録を一意に見分けます。

アカウントはアドレスだけで見分けません。同じ16進アドレスが別のチェーンに存在し得るからです。CAIP-10が定義するように、チェーン識別子を含む識別子が必要です（CAIP-10 Account ID Specification）。EVM系でも内部キーは少なくとも chain_id + normalized_address とし、プロトコルのコントラクトも同じ方法で見分けます。

操作ごとに誤分類を防ぐ確認

振替とブリッジの状態名

社内の振替は、送信側と受信側を別イベントとして保持し、transfer_group_idで対応付けます。ブリッジの4状態はinitiated（開始済み）、matched（対応済み）、expired（期限切れ）、refunded（返金済み）です。移動中の資産はbridge_pendingのポジションで保持します。

再編成の検知と、集計レコードの状態

Ethereum JSON-RPCのログには、チェーン再編成で除外されたことを示すremovedがあります。状態の照会にはsafeとfinalizedのブロックタグがあります（Ethereum JSON-RPC API）。EIP-234は、ブロックハッシュでログを取得する方法を示しています。対象のブロックがなければ、取得する側でロールバックして取り直します（EIP-234）。

observed   → provisional → finalized
    └───────────────→ superseded → replayed

quarantined: 未知のコントラクト / 欠損ブロック / 価格なし / 対応不能な送付

訂正時は、正規データを示すフラグとsuperseded_by、デコーダー・価格・方針の各バージョンを残します。

障害の見つけ方

XTELAができること

私たちは、チェーンデータの取得、プロトコルごとのアダプター、原票から評価までの4層の補助元帳、価格の根拠管理、照合と監視を設計・開発します。2〜3チェーンと代表的なプロトコルに絞ったPoC（概念実証）で、再編成や価格停止などの異常系まで貴社の実データで確かめてから広げます。集計の範囲を決めるところからのご相談はお問い合わせからどうぞ。

主要参考資料

• Ethereum.org: JSON-RPC API
• Ethereum Improvement Proposals: EIP-234
• Chain Agnostic Improvement Proposals: CAIP-10
• Aave: Introduction to Aave V3
• Uniswap Docs: Concentrated Liquidity
• Chainlink: Data Feeds API Reference
• 国税庁: 暗号資産に関する税務上の取扱い及び計算書

資料の確認日と注意

技術仕様の確認日は2026年8月12日で、Ethereum JSON-RPCとChainlinkの記述は2026年9月24日に確認し直しました。公開資料にもとづく技術設計上の整理です。プロトコル、コントラクト、チェーン、価格フィードは更新されるため、導入時に使用バージョンを確認し直してください。会計方針・税務区分・法的な主体帰属の判断は専門家へご確認ください。