やってみたラボ へようこそ

本記事は個人の検討記録であり、投資助言・特定の取引や商品の推奨を目的としたものではありません。投資判断はご自身の責任で行ってください。 きっかけ：資金分散の壁 複数取引所間の裁定取引（アービトラージ）は、価格差のある両方の取引所にあらかじめ資金を置いておく必要がある。取引所間送金には数分〜数十分かかるため、片方にしか資金がない状態では実質的に機会を活かせない。つまり資金力がそのまま参入障壁になる。 自分の場合、bitFlyerでCrypto CFD（BTC/JPY）のみをAPI連携で運用しており、複数取引所に資金を分散する余裕はない。そこで「単一取引所内で完結する戦略」として、現物とCFDの価格差（ベーシス）を使ったファンディングレート戦略を検討した。 bitFlyer Crypto CFDの仕組み 2024年3月にLightning FXが廃止され、現行のbitFlyer Crypto CFDには以下の仕組みがある。 ファンディングレート：CFD価格（BTC-CFD/JPY）と現物価格（Lightning現物 BTC/JPY）の乖離に基づき、建玉数量に応じて8時間おき（1日3回）に授受される金額 レバレッジポイント：CFDポジションを18時に決済せず翌営業日に持ち越す（ロールオーバー）たびに発生するコスト。以前の「スワップポイント」を置き換えたもの 現物とCFDは連動しておらず、需給差で価格が乖離することは公式FAQでも明言されている。 戦略の骨子 現物でBTCを買う（スポットロング） 同量をbitFlyer Crypto CFDでショート 価格変動リスクを相殺（デルタニュートラル）しつつ、CFDがプレミアム状態が続けばファンディングレートを受け取り続ける 他の取引所の無期限先物でよく使われる「ファンディング刈り取り」と同じ発想を、bitFlyer単体で完結させる設計だった。 見送った理由 検討の結果、Bot化は見送った。理由は大きく2つ。 1. 収支計算に不確実性が残る 収支は「ファンディング受取 − レバレッジポイント（持ち越しコスト） − 現物/CFD双方の取引手数料・スプレッド」で決まる。特にレバレッジポイントの実際の負担額は、事前に手動で数週間程度実績を観察しないと精度よく見積もれない。 2. 資金制約が別の形で残る 複数取引所への分散は不要になったが、現物側はレバレッジが効かないため、ヘッジしたい数量分の現物購入資金をフルで用意する必要がある。「まとまった資金が必要」という制約自体は解消されなかった。 いきなりBot化するのではなく、まず少額での手動検証から始めるべき戦略ではあるが、優先度を見直した結果、今回は着手を見送り、他の取り組み（本ブログの運営や自宅サーバーの活用など）にリソースを振ることにした。 まとめ 「複数取引所の資金分散問題」は解決できても、「現物保有のための資金」という別の壁にぶつかる、という点が今回の検討で一番の学びだった。単一取引所内で完結する戦略を考えるときは、レバレッジが効く側と効かない側の非対称性に注意したい。

サーバー環境 HP ProDesk 400 G6 DM CPU: Core i5-10500T メモリ: 16GB ストレージ: M.2 SSD 256GB OS: Ubuntu Server 26.04 LTS このサーバーでは仮想通貨自動売買Botを常時稼働させているが、CPU・メモリともに余力があったため、家中の広告ブロック用にPi-holeを追加導入することにした。 Docker導入とポート53の競合 Ubuntu 24.04以降はデフォルトでsystemd-resolvedがローカルDNSキャッシュとして動いており、127.0.0.53/127.0.0.54をリッスンしている。Pi-holeをDockerで-p 53:53公開しようとすると、ここが競合しやすい。 対処として、/etc/systemd/resolved.confのDNSStubListenerを無効化し、ホスト自体の名前解決先を/run/systemd/resolve/resolv.conf（スタブを経由しない実際のアップストリーム）に向け直した。 sudo sed -i 's/#\?DNSStubListener=.*/DNSStubListener=no/' /etc/systemd/resolved.conf sudo rm -f /etc/resolv.conf sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf sudo systemctl restart systemd-resolved これでポート53が解放され、Pi-holeのコンテナは無事起動できた。管理画面（http://<サーバーIP>:8080/admin）にもアクセスでき、ここまでは順調だった。 ルーターのDNSを向けた瞬間、全端末で名前解決が死んだ ルーターのDHCP設定でプライマリ/セカンダリDNSを両方ともPi-holeのIPに変更したところ、PCもスマホも検索すらできなくなった。DNSサーバーのアドレス自体はipconfig /allで正しく切り替わっているのに、何も引けない。 コンテナ内部からのテストは問題なかった。 docker exec pihole dig google.com @127.0.0.1 # → 正常にAレコードが返る つまりPi-hole自体、そしてアップストリームDNSへの転送は正常に機能している。おかしいのは「LANの外部端末からの問い合わせ」だけだった。 原因：Pi-holeが自分のLANを認識していなかった コンテナのログを見て原因が判明した。 WARNING: dnsmasq: ignoring query from non-local network 192.168.0.64 Pi-holeの内部（dnsmasq/FTL）には「ローカルネットワークとみなす範囲」を判定するロジックがあり、デフォルトのLOCALモードでは、コンテナ自身のネットワークインターフェース情報から自動判定する。ところがDockerのブリッジネットワーク経由で動かしていたため、Pi-holeが認識する「自分のネットワーク」はDockerの内部サブネットになってしまい、実際のLAN（192.168.0.0/24）から届く問い合わせを「よそのネットワークからの怪しい問い合わせ」として黙って無視していた。 これはPi-hole＋Docker構成で比較的よく起きる既知の挙動らしい。 解決策 docker-compose.ymlの環境変数で、DNSのリスニングモードをALLに変更する。 ...