GateUser-cc6abff6

めっちゃ笑った。以前、声のクローンを作るために音声を録音して、AIに動画制作のパイプラインを走らせてもらったんだけど。今、CCで作業している最中に突然、コンピューターが自分の声で話し始めて、びっくりした😂

Crazy, three Claude Code terminal windows just got 529 overloaded at the same time, thought my account got banned again, scared out of my mind 😅

Simon Willison（Djangoの共同創設者であり、現在はAIエンジニアリングの実践に専念）によるsubagentのエンジニアリングパターンガイドが公開され、LLMサブエージェントを3つのモードに分類しました：Serial（シリアル探索）、Parallel（並列実行）、Specialist（スペシャリスト役割）。核心的な問題は、コンテキストウィンドウの制限であり、サブエージェントは独立したウィンドウを使って負荷を分散させることです。
実際に使ってみると、Parallelは過小評価されがちです。軽量モデルのグループを並列に動かして探索を行い、メインウィンドウは結果が返ってくるのを待つだけで済み、体験と効率の差は顕著です。しかし、最大のアンチパターンは過度な分解ではなく、過信です—サブエージェントから返された結果は、メインエージェントによるクロスバリデーションを経る必要があり、直接採用してはいけません。
最大の利益は速度ではなく、コンテキストの保護です。メインウィンドウをクリーンに保つことで、複雑なタスクも最後まで完遂できるのです。
Simonの原文リンク：

$370 で予測市場の価格を操ることができる。
LessWrong の記事ではいくつかのケースを取り上げている：Scott Alexander が Polymarket の Anthropic の評価市場を引用し、「市場は90%の確率で $500B に達すると考えている」と述べている。著者がオーダーブックを確認したところ、YES側の総流動性はわずか $370 だった。この程度の資金で、価格を90%から76%に引き下げることができる。
さらにひどいのは、同じイベントで Kalshi は37%、Polymarket は22%を示していることだ。差は15ポイントもあり、両側の流動性が非常に乏しいため、参考にならない。Manifold の市場も、1週間まったく取引がなくても引用されている。
自分が Polymarket で取引した感覚も同じだ — 多くの市場は価格があるように見えるが、オーダーブックが薄いため、数十ドルの取引一つで価格が数ポイント動く。価格が存在することと、価格に意味があることは別の話だ。
原文は一読の価値がある：

YCのCEO、Garry Tanは彼のClaude Codeワークフローをオープンソース化し、24時間でGitHubのスター数は4Kを超えました。
8つのスラッシュコマンド、それぞれが異なる役割に対応しています：CEOは製品の方向性をレビューし、エンジニアマネージャーはアーキテクチャを審査し、Staff Engineerは本番事故を検出し、リリースマネージャーはワンクリックでリリースし、QAは自動でスクリーンショットを撮ってバグをテストします。
核心は一つだけ：AIを万能の助手とみなすのではなく、役割を与えることです。
最も印象に残ったのは /plan-ceo-review です。「画像アップロードを追加したい」と言っても、AIは急いでコードを書き始めるのではなく、まず逆に問い返します：「これが本当に必要な機能ですか？本当のニーズは、売り手が自動的に商品説明を生成できるようにすることかもしれません」。つまり、「どうやってやるか」から「何をやるか」へと視点を戻すのです。
/reviewも非常に強力です。意図的に本番事故をシミュレートします：N+1クエリ？並列競合？アップロード失敗で孤立したファイル？バグが爆発する前に、すべての落とし穴を事前に考え抜きます。
根底にある原則：AIを雑多に使うよりも、専門的に使う方が効果的です。

To register a new platform and get an API key, at minimum you need to: open a webpage, fill in email and password, switch to Gmail to find the verification code, paste it back, find the API key page, create it, and copy it. One platform takes 5 minutes, ten platforms take all morning.
I built a Claude Code Skill that, when you say "help me register xxx", handles the rest automatically.
Two-layer architecture:
First layer leverages login state — inject cookies directly from Chrome using Playwright. No need to re-login to already-authenticated services. About 200 lines of Python.
Second layer fu

Claude CodeにX検索エンジンを接続しました。Grokを基盤にしたローカルブリッジサービスを構築し、常駐させており、Claude CodeがXを検索する必要があるときに自動的に呼び出されます。端末の一行コマンドで、数秒以内に要約と関連するユーザーの発言を返します。二つの重要な利点は、X公式APIを使わない（毎月の$200 のBasicプランを節約できる）ことと、リアルタイムの動向も検索できることです。API検索は遅延やインデックス制限がありますが、Grokは最新の情報を直接取得します。（前提：X Premium+/PremiumのGrok権限が必要な場合があります）最も典型的なシナリオは、Claude Codeを使って作業しているときに、X上の特定の話題の最新議論を知りたいとき—誰が話しているのか、どんな意見か、落とし穴はあるかです。以前はブラウザを切り替えて手動で検索していましたが、今はClaudeが自動で調べて、要約を持ち帰って作業を続けられます。これを導入したら元に戻れません。情報収集が「自分で探す」から「彼に探させる」へと変わり、体感がまったく異なります。

Claude Codeを使い始めて3ヶ月、ディレクトリは増え続け、rules/、docs/、memory/、skills/といったさまざまな階層構造を作ったが、自分が何を構築しているのかはっきりと説明できなかった。
そのとき、「Everything is Context」という論文を読んで、私のフォルダ構造を学術的な言葉に翻訳してみた：
→ 論文はScratchpad（仮置き作業領域）と呼ぶ
→ Fact Memory（プロジェクトレベルの事実記憶）
→ Experiential Memory（プロジェクトを跨ぐ経験）
rules/の自動ロードとdocs/の必要に応じたロードは、→ Context Constructor（トークン予算内で選択的にロードする）
最も共感したのは、トークンウィンドウの制約に関する部分だった。以前はrules/を全てロードしていたため、コンテキストが一気に膨れ上がった。後に二層構造に分けて安定させた。論文ではこれを「bounded reasoning capacity（制約された推論能力）」と呼んでいる—つまり、私が解決しようとしていたのはこの問題だった。
実践を先に行い、命名は後からつける。まずは失敗を経験し、その後論文を読んで、失敗に名前がついていることに気づいた。