Runesleo

Polymarket の自動戦略を作るとき、みんな慎重に一度は展開しますが、停止するときはほとんど誰も話さない —— 今日はこの盲点に教訓を受けて14時間過ごしました。
3週間前、私は Polymarket で動いている戦略ロボットを停止しました。pm2 stop を実行し、状態が stopped に変わったのを見て、事態は終わったと思ったのです。
今日はついでに10分間サーバーの掃除をして、プロセスマネージャーを再起動しました。その「死んだ」はずの戦略が復活し、静かに14時間リアルマネーで動き続けました。
原因を調べたところ —— pm2 stop は単に状態を「停止済み」とマークするだけで、実際には削除していませんでした。 一度一括起動をかけると、「一時停止」されたすべてのプロセスが引き戻されてしまいます。この落とし穴は pm2 に特有のものではなく、systemd、docker、k8s も同じ問題を抱えています：停止したと思っても、実は停止していないのです。
予測市場の自動戦略を作るとき、どんなツールを使っていても、戦略を停止させるには5つのことを行う必要があります：
1. プロセスマネージャーレベルでこのサービスを完全に削除する ( 一時停止ではなく )
2. 設定ファイルからこの定義を削除する ( 次回一括起動時に自動的に復活しないように )
3. コードの入

看 @predictionindex 这期最新预测市场数据周报告：Polymarket + Kalshi 合计约 75% 成交量，其余所有平台累计 <$30B。
报告里没讲的两个细节，对预测市场玩家其实更关键：
Kalshi 正在追上甚至反超 Polymarket
DeFiRate 最新一周：Kalshi $2.9B（60%），Polymarket $2.0B（40%）。两家在周度数据里互有拉锯——上周 Poly 刚反超过 Kalshi，这周又被追回去。
アメリカ市場はさらに極端だ。BofA 4/9-10 のレポート：Kalshi 89%、Polymarket 7%、4%。規制とKYCはKalshiの構造的優位性であり、Polymarketはオンチェーンプロトコルで、アメリカの個人投資家へのカバレッジでは一時的に不利で、短期的には逆転しない。
"双寡頭"という言葉は、Polyが依然リーダーだと思わせやすいが、実際のアメリカ市場はほぼKalshi一社になっている。
"その他 25%" の中にもより大きなアルファが潜んでいるかもしれない
Week 15レポートで触れた小規模プラットフォーム：Opinion / Limitless / Myriad / / Probable / / Chain）...

本質的には、新しい予測市場が立ち上がり、競争が十分になるまでのウィンドウ期間

また一件あまり役に立たないけどとても気持ちいいこと：今日はClaudeを使って3.7万件のGmail受信箱を1.1万件に整理した。全て自分でメールを見ずに、たった2回クリックしただけ：App Passwordを送信し、フィルターをインポートしただけ。
Python + IMAPを使い、4つのステップで行った：
1. 送信者を頻度別にエクスポート
2. 555の迷惑ドメインを一括でArchive-Junkにアーカイブ
3. 自ら停止して「誤って317通の銀行/証券会社/Coinbase/Claudeの安全メールを削除したので、取り戻しますか」と呼びかけ
4. Gmailフィルターを作成し、今後これらのドメインのメールを受信トレイに表示しないように設定
第三ステップは予想外だった。本来は自分でいくつかメールを抽出して分類の正確さを確認しようと思っていたが、AIが先にリスクポイントを列挙してきた。

最近、多モデルの相互対戦を行ったところ、面白い発見がありました。
同じアーキテクチャの課題について、私はClaudeとCodexにそれぞれ独立して解決策を書かせました。
Codexは一つ見落としがありました：私の戦略は20以上の独立したプロセスに分散しているのに、彼の書いた解決策は「すべてのコンポーネントが同じ場所で動作する」と仮定していて、そのままでは無効でした。Claudeは一目でその問題を見抜きました。
逆にClaudeは別の見落としをしていました：彼は新しい独立モジュールを作ることに固執していましたが、実は私の手元には既存のフレームワークがあり、ちょっとしたフィールド追加だけで対応できるものでした。Codexはその点を拾い上げました。
最も面白かったのは、その後のステップです：私は二つのモデルにお互いの最終案をレビューさせましたが、双方とも「相手が既に書いたフレームワーク」を前提にしてしまい、結果的に一つの境界条件を見落としました。最終的には私が手動で本番データを動かして気づきました。
今の習慣は、各ラウンドの相互対戦ごとに成功基準を設定し、一方のモデルにもう一方の下書きを見せないことです。手に入るのは、重複しない盲点を持つ二つの独立した下書きで、それらを組み合わせて初めてほぼ完全な解決策となるのです。

量化戦略を構築する際によく犯しがちな誤り：信頼できそうな「見た目が信頼できる」データを信じて、上流のデータソースを確認しないこと。
私の天気予報戦略は以前、34都市をカバーしており、過去の数回の拡張で徐々に追加してきましたが、長い間見直していませんでした。先日、定例の監査としてPolymarket公式APIから全市場を一通り取得したところ、実際には44個あったことに気づきました——自分が10個見落としていたのです。
さらに面白いことに、業界で皆が引用している天気ツールサイトと比較したところ、その中で最大の都市であるPanama Cityを漏らしていることが判明しました。Polymarket上には66のイベントオプションがあり、2つの「見た目が信頼できそうな」データともにそれを含んでいませんでした。
教訓：自分が1年前に整理したリストは期限切れになるし、他人が整理した「業界リスト」も漏れることがある。唯一正確なのは原始的なAPIです。もう一度取得するのにコストはほとんどかかりません——今回は一度に数分で全て取得できました。

Claudeはこっそりと $200 のクレジットを送っており、バックエンドの Settings → Usage で確認できます。
Code、Claude Desktop、サードパーティアプリで使用可能で、4月17日に期限切れになります。
注意：Claimを直接クリックするとエラーになる場合があるので、まず下にスクロールしてExtra usageのスイッチをオンにし、その後もう一度受け取ればOKです（App Storeのサブスクリプションやカード登録なしでも成功します）。
これでまた楽しくトークンを使えます！

天気做市戦略をしばらく運用してきましたが、最近リトレースが不自然だと気づきました。調査した結果、問題は確率モデルの二つの仮定にありました。
一つ目は：校正に使ったのはグリッド再分析データですが、Polymarketの決済には空港の実測値を用いています。二つのデータソース間にはシステム的な偏差があり、校正されたσは根本的に正確ではありません。
二つ目はより隠れた問題：モデルは予報に偏りがないと仮定しています。しかし実際には、各都市の予報には方向性の偏差があります。ある都市は系統的に冷偏り、別の都市は熱偏りがあります。モデルはこの事実を知らず、誤った方向に繰り返し賭けてしまいます。
例えば、ある都市の予報が実際よりも約2°C低い場合、モデルは「温度はXに到達しない」確率が高いと判断し、多くのNOを買います。しかし実際には温度は毎回予報より高くなります。
最初の直感は、パフォーマンスの悪い都市を切り捨てることでした。ところが、切り捨てた結果、3分の1が禁止されてしまいました。その時に気づいたのは：3分の1をカバーする戦略が必要であり、問題は都市側ではなくモデル側にあるということです。
校正データソースを変更し（決済と同じ出典の空港観測に切り替え）、確率計算に偏り補正を加えました。その後、切り捨てた都市をすべて復元し、高σの都市はモデル自身が信号を減らすため、人工的に禁止する必要がなくなり

クロードコードの51万行のソースコードが漏洩し、GitHubには一夜にして十数個のバックアップリポジトリが登場し、最高11.8万スターを獲得した。
中国の開発者コミュニティは一斉に盛り上がり、アーキテクチャの解体、隠された機能の掘り起こし、フラグの発見に夢中になった。
しかし最も直感に反するのは、Anthropicの反応だ。
npmパッケージは撤回されていない。緊急のPRも出ていない。最高執行責任者のPaul Smithはこう言った：「絶対に違反やハッキングはない」——安全事故ではなく、プロセスの問題だ。
比較してみよう：もしTeslaの自動運転ソースコードが漏洩したら、マスクは「プロセスの問題」だけで済ますだろうか？
Anthropicがこれほど冷静でいられるのは、心の中で理解しているからだ。Claude Codeの競争力は、あの51万行のTypeScriptにあるのではない。ハーネスは外殻であり、モデルは魂だ。外殻を手に入れても、その魂を入れることはできない。
GitHubにあるフォークはすでに証明している——大部分は「どうやってAnthropic APIを回避して動かすか」ということに集中しており、「このアーキテクチャを使ってより良い製品を作るにはどうすればいいか」ではない。
開発者はソースコードを手に入れたら、Claude Codeも手に入れたと思い込んでいる。しかし、An

私はClaude Codeを少し触ってみたところ、全体で12個のMCPが常駐していることに気づきました。
各MCPのツール説明は常駐するシステムプロンプトに含まれており、調整の有無にかかわらず、常にコンテキストを消費しています。
14日間の呼び出しデータを集計した結果、6つのMCPは2週間で合計わずか10回未満の呼び出ししかありませんでした。そこで、これらを6つに減らすことにしました。
削減後に考えたのは、どのツールをMCPで使い、どれをCLIだけで十分に済ませるべきかということです。
MCPの利点は構造化にあります。Claudeはパラメータのスキーマを見て直接呼び出すことができ、複雑なインタラクション（ログイン状態、長期接続、多段階操作）もより安定して処理できます。
しかし、その代償として常駐コンテキストが必要です。10個のMCPを設定すれば、数十個のツール説明が常にそこに存在し続けることになります。
一方、CLIにはこのオーバーヘッドはありません。コマンドは実行時にだけコンテキストに入り、実行後は消えます。
私の現在の方針は、Claudeが積極的に発見・呼び出す必要のあるもの（記憶システム、TGメッセージ）だけをMCPに残し、それ以外は可能な限りCLI化することです。
全体のMCPは5〜6個以内に抑え、その他はプロジェクトごとに必要に応じてロードします。

毎日GitHubの人気プロジェクトを一巡し、自分のワークフローを最適化できるものを探しています。今日見つけた中で半分はClaude Codeエコシステムに関するもので、特におすすめの3つを紹介します：
claude-code-best-practice（+2407⭐）
87のCC使用テクニックと8種類のコミュニティワークフローの比較を整理。初心者や一定期間使った方が体系的に理解したい場合に最適です。
oh-my-claudecode（+1126⭐）
複数エージェントの編成フレームワークで、19のプリセットエージェントと自動モデルルーティングを搭載（簡単なタスクはHaikuでコスト削減、複雑なものは自動的にOpusに昇格）。最も面白いのは、デバッグ過程から再利用可能なスキルを自動抽出できる点で、手動で書く必要がありません。既にCCを使って仕事をしているチームやコラボレーションを考えている方に適しています。
superpowers（+2620⭐、総星数128K）
Jesse Vincentによるエージェントスキルフレームワークで、テスト駆動とGitワークツリーの隔離を核としています。コード品質にこだわり、エージェントによるコードの乱改を避けたい方に最適です。
段階別の選び方：入門はbest-practice、実務はsuperpowers、チーム運営はoh-my-claudecode。

新しい期のマスクの給与が振り込まれました、$551
2週間、274万回表示
累計受取額は$2060。3年間は$1508 がほぼ追走期間で、最近2週間の$551 が総収入の27%
3ヶ月で930万回表示、36.4万回のインタラクション、6.3万回の保存
成長曲線は収入自体よりも良く見える