ハニーポット検知と資金防衛の実務——トークン購入前に必ず行う12のチェックリスト

暗号資産の世界ではハニーポット（Honeypot）と呼ばれる、買えても売れない設計のトークンや、売却時だけ高額手数料を抜き取る悪質コントラクトが後を絶ちません。この記事では、投資家が初歩から実務レベルまで使える「検知フロー」を体系化し、実際のツール操作・判断基準・想定損益影響・回避オペレーションまで具体的に解説します。目的はただ一つ、資金を守ることです。

1. ハニーポットの基本構造と動機
2. 基本フロー（買う前に必ず通す）
3. コードで見る「売れない」仕掛けの典型
4. ツール別・実務オペレーション
5. 12のチェックリスト（保存版）
6. 実損を減らすサイズ設計とエグジット設計
7. ケーススタディ（仮想例）
8. よくある反論と反証
9. 実務テンプレ（コピペ運用OK）
10. 運用ガイドライン（失敗前提の設計）
結論

1. ハニーポットの基本構造と動機

典型的なハニーポットは、売却制限（sell tax の極端化／特定関数の条件分岐／ブラックリスト）、トランスファー制御（transferFrom の改変）、ミント権限の濫用などで投資家の出口を塞ぎます。開発者の動機は、短期での資金吸い上げと足抜けです。コードに直接フラグが埋め込まれているケースもあれば、後からオーナー権限で設定を切り替えるタイムボム型もあります。

2. 基本フロー（買う前に必ず通す）

コントラクト確認：公式X/サイトが示すCAをEtherscan等で開き、検証済みコードか確認します（未検証＝即撤退推奨）。
オーナー権限：Ownable/AccessControl の有無、owner()の現在値、renounceOwnership()実行履歴。transferOwnership()の直近履歴も要チェック。
売買税（tax）：buy/sell で差があるか、上限値、setTax()等の変更権限保持者。
ブラックリスト：関数名に blacklist / isBot / antiMEV などがあれば赤信号。条件分岐で任意アドレスを弾けるかを読む。
流動性（LP）の状況：どのDEX/ペアに流動性があるか、LPがLock/Burnされているか。所有者が回収可能なら抜かれる前提でサイズを絞る。
供給・配分：ミント／バーン権限、maxTxAmountやmaxWallet制限、チーム・トレジャリーのベスティング実装。
依存コントラクト：ブリッジ、オラクル、税計算モジュールに外部権限が残っていないか。
テストスワップ：最小額で buy→sell を実行し、実際に売れるかと実効スリッページ/手数料を確認。
チェーン選定：EVM互換でもチェーンごとにスキャム文化が違います。新興チェーンは監視密度が低く、初動は特に慎重に。
情報対称性：監査報告・GitHub・デプロイ者履歴を確認。履歴が薄い匿名チームはディスカウント前提。

3. コードで見る「売れない」仕掛けの典型

検証済みコードを開いたら、以下のシグナルを探します。

可変税：function setSellTax(uint256 _t) のように上限なく変更可能。
条件付きトランスファー：売り時のみ require(whitelist[sender]) を通すなど、実質売却禁止。
ブラックリスト：mapping(address => bool) blacklist; と require(!blacklist[msg.sender])。
ミント無制限：_mint(owner, amount) を随時実行可能。価格希薄化リスク。
LP引き出し：Router 経由で LP トークンを回収できる所有権が残存。

これらは単体でも危険ですが、複合すると脱出確率が急落します。少額テストで実測し、異常があれば即撤退します。

4. ツール別・実務オペレーション

Etherscan/各種ブロックエクスプローラ

「Contract」タブで Read/Write 関数を確認し、owner()や税率 getter、ブラックリスト関連の状態を読み取ります。「Analytics」ではトークン保有者分布、「Holders」はデプロイヤーやLPの比率を把握。上位5アドレスで80％超の集中は典型的危険シグナルです。

DEXツール

Dexscreener などで流動性・FDV・FDV/TVL を比較。FDV/TVL > 80などは価格の脆弱性が高いサイン。板が薄い場合、売れるが価格が滑って結果的に実現損、という罠も多いです。

ミント/バーン監視

トランザクションログで Transfer(address(0), ...)（ミント）や Transfer(..., address(0))（バーン）を監視。ミント連発は即撤退の合図です。

5. 12のチェックリスト（保存版）

コードは検証済みか（未検証は原則不参加）。
オーナー権限は放棄済みか、少なくとも多人数のマルチシグか。
売買税の最大値・変更権限は？
ブラックリスト／ボット判定の恣意性は？
maxTx・maxWallet の設定で出口が塞がれないか。
LP は Lock/Burn 済みか。解除時刻は？
トークン配分の集中度（上位5で80％超は危険）。
ベスティング／クリフの実装と実動作の整合。
依存コントラクトの外部権限の有無。
最小額テストで本当に売れたか（手数料実測）。
チェーンごとの文化・監視密度を考慮してサイズ調整。
開発者の過去実績・監査有無・コミット履歴。

6. 実損を減らすサイズ設計とエグジット設計

新品トークンへのエントリーは初回は1〜3回に分割し、各回ごとに売却テストを通します。売れなければ損失を最小化、売れても実効コストが高い場合は以降の追加は見送り。想定スリッページ×サイズ＝実効手数料として見積り、期待値 < 0なら撤退が鉄則です。

7. ケーススタディ（仮想例）

ある新規トークンX：コード検証済み、owner 未放棄、setSellTax()あり、LP未ロック。テスト買い0.01 ETH→売却時に 35% の sell tax＋価格滑りで 0.0065 ETH 回収。実効損失 35％超が確認されたため不参加判断。後日、LPが引き上げられ価格は90％下落。事前オペで資金を守れた事例です。

8. よくある反論と反証

「税は後で下げると言っている」：下げる権限があるなら上げる権限もある、が原則。文言ではなくコードと履歴で判断します。
「監査済みだから安全」：監査はバグの存在可能性を低減するもので、悪意ある設計や後からの権限変更までは保証しません。
「コミュ人数が多い」：ボットで水増し可能。オンチェーンの事実のみを拠り所にします。

9. 実務テンプレ（コピペ運用OK）

1) CAをエクスプローラで開く → 検証済みか
2) owner() 確認、renounce / transfer の履歴
3) setTax / setFee 類の上限・権限
4) blacklist/antiBot フラグの存在と条件分岐
5) maxTx/maxWallet の数値と売却時挙動
6) LP Lock/Burn 状態と解除時刻
7) Holders 上位分布（Top5 > 80% は警戒）
8) ベスティング・クリフの実装確認
9) ミント/バーンの最近の発火
10) 少額 buy→即 sell テスト（実効手数料測定）
11) FDV/TVL の過熱度、板厚
12) 最後にサイズ決定（期待値マイナスなら見送り）