情報収集→蓄積→取引ブロック→振り返り→可視化のパイプラインを一気通貫で作った

2026-07-14の作業記録(後半)。前回の記事(較正測定と正則化)に続き、「銘柄のニュースを取引判断に繋げる」パイプラインを構築しました。

きっかけ: BONKの損切り2連発には理由があった

直近2日でBONK/USDTが2回損切りされ、合計-16.76 USDTの損失を出していました。当初は「荒れ相場での事故」と見ていましたが、ニュース収集の仕組みを作って最初に走らせた瞬間、こう出ました。

$BONK Falls 8% After Governance Attack Drains $20M From BonkDAO (ガバナンス攻撃でBonkDAOから$20Mが流出) — 判定: exploit / negative / 確度1.0

事故ではなく、検出可能な予兆のある損失でした。 ニュースを見ていれば避けられた取引だったということです。

パイプラインの構成

全銘柄(129)を漫然と監視するのではなく、対象を絞りました。

1. 収集(6時間ごと): 「保有中の銘柄」と「直近24時間の最大損失銘柄」だけを対象に、ニュース検索RSSを巡回。1日あたり数銘柄×5記事程度
2. 蓄積: SQLite 1ファイルに「1事実=1行」で保存。全事実に有効期限を持たせる(悪材料24時間、その他72時間)。期限切れの事実は判断材料から自然に消える
3. 取引ブロック: ハッキング・上場廃止級の悪材料(確度0.6以上)が出た銘柄は、24時間新規エントリー自動停止。BONKは現在このブロック下にある
4. 振り返り材料: クローズした取引の自動検死に、その銘柄の有効なニュースを添付。「事故」と「予兆ありの損失」をLLMが区別できるようになった
5. 可視化: ダッシュボードに「銘柄ニュース」セクションを追加。ブロック中の銘柄は赤いカードで表示

ナレッジ蓄積のフレームワーク(Graphiti/Mem0等)も検討しましたが、1日数銘柄の規模にグラフDBは過剰と判断し、SQLite+有効期限の最小構成にしました。事実が数千件を超えて関係クエリが必要になったら移行を検討します。

副産物: 眠っていたバグの発見

この作業中、既存のニュース分類パイプラインに重大なバグを見つけました。LLMの出力から JSON を取り出すパーサが、単一要素の配列を「中身の辞書」として誤って解釈し、配列を期待する検証で弾かれて、全てのニュース分類が単純なキーワードマッチにフォールバックしていたのです。

つまり、毎時動いていたニュース監視は、LLMが正しく「exploit/確度1.0」と判定していたのに、その結果を捨てて「neutral/other」に劣化させていました。BONKのブロックが効かなかった一因です。修正済みで、回帰テストも追加しました。

正直な注意書き

• 誤検知はあります。例えばTIA(Celestia)に、同名の人物の逮捕記事が紐付いてブロックされました。ただしコストは「その銘柄の新規エントリーを24時間見送る」だけなので、安全側に倒れる誤検知として許容しています(検索クエリの改善で今後潰します)
• 「ニュースを判断材料にすると成績が良くなるか」は未検証です。ポジティブ材料は取引に直結させず、まず記録だけ貯めて、数週間後に「予兆のあった損失を何件防げたか」を実測してから次を判断します

同日のもう一つの採用: 流動性キャップ

板の薄い銘柄への発注サイズを「直近24時間出来高の0.1%」で上限する制御も本番に入れました。検証の過程で、バックテスト上の利益(+1,100 USDT)の大部分が「板の薄い銘柄でのフルサイズ理想約定」由来だと判明したためです。見かけの成績は地味になりますが、実弾で再現できない利益を数字から排除し、dry-runの成績を「本当の実力」に近づける判断です。

本システムはドライラン(ペーパートレード)で運用中です。実資金の取引は行っていません。