AI/LLM

結論を先に CLAUDE.md と 4 つの SKILL.md を日本語から英語に書き換えた結果、毎セッション読み込まれる固定資産のトークン量が 13,538 → 8,441（-37.6%、絶対値で 5,097 トークン削減） になった。 文字数は逆に +49% 増えているのに、トークンは大幅に減るという一見矛盾した結果である。理由と内訳を以下に示す。 背景 CLAUDE.md 英語化の記事 と Skills 英語化 PR (#394) の続編。 前 2 つの作業で、ハーネスの「内側」（LLM だけが読む固定資産）を英語化し、「外側」（人間が読むブログ記事や許可プロンプト）は日本語のまま維持する部分英語化パターンを実装した。 ただし、その記事では「Anthropic 公開の日本語比率 1.94x」から 推定 48% 削減 とラフに見積もっていた。実際の効果は推定モデル次第で 2% 〜 48% と幅があり、本当の値を知るには実測しかない。 計測手法 tiktoken (cl100k_base) を採用 理由: オフラインで動く、API key 不要、結果が再現可能 限界: Anthropic Claude のトークナイザーではなく OpenAI GPT-4 系。ただし日本語のトークン化挙動は近似として広く使われる 対案: Anthropic SDK の count_tokens API が最も正確だが、API キーが必要 venv で隔離 PEP 668 で system Python が保護されているため、.claude/temp/venv-tiktoken/ に隔離した venv を作って tiktoken だけ入れた。 ...

海外で話題になっているある個人トレーダーの話が、X（旧Twitter）で拡散されている。彼はObsidianとN8Nを組み合わせて「自動トレーディングAI」を構築し、6ヶ月で$180,000（約2,700万円）を稼ぎ出したという。月のAPIコストはたった$120。クラウドサーバーも、アナリストチームも、Bloombergターミナルも不要だ。 元ネタのツイートは@browomoによるもので、4,500以上のいいね、90万回以上の閲覧数を記録している。 システムの全体像 このシステムの核心は、Obsidianのローカルvaultをナレッジの「中枢」として、N8Nの6本のワークフローパイプラインが情報を自動収集・分析・配信する構造にある。構成要素は次の通りだ。 ハードウェア: 自宅のMac Mini（ローカルでvaultを保管・パイプラインを常時稼働） モバイル: iPhoneでvaultにアクセス・アイデアをキャプチャ コスト: Readwise・Whisper API・N8Nホスティングのサブスクリプションで月約$120 伝統的なクオンツファンドが同等のインサイトフローのために8人のチームを雇っている一方、このシステムはその機能を個人レベルで再現している。 VAULT.md に書かれた「AIアナリストへの指示」 システムの起点となるのは、Obsidian vaultのルートに置かれた VAULT.md ファイルだ。ここにAIアナリストへの役割定義と行動指針が記されている： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 you are the AI analyst of a solo trader. you read his vault every morning at 6:00, find connections between fresh and old notes, and deliver 3 trading ideas he can verify in the hour before the market opens. pipelines: // Reader (pulls every article and highlight from Readwise, Twitter bookmarks, and Kindle into /notes) // Listener (transcribes podcasts through Airr and voice notes through Whisper, puts them in /notes) // Catcher (accepts any message from the Telegram bot and writes it to /inbox with a timestamp) // Connector (every night reads across the entire vault and updates the connection graph between 4,000 notes) // Briefer (at 6:00 AM writes a brief: 3 trading ideas for today plus the emerging thesis of the week, puts it in /inbox) // Mobile (lives in the iPhone, answers any question about the vault by voice, and confirms alerts while the owner is on the go). you wake the owner with a push notification only when a fresh note contradicts his active thesis or when 1 of the 3 morning ideas has a confidence score above 90%. この指示が秀逸なのは、AIに「何を自律的にやるか」と「いつ人間を介入させるか」の境界を明確に定義している点だ。 ...

TL;DR Redis 作者の Salvatore Sanfilippo（antirez）が、DeepSeek V4 Flash 専用のローカル推論エンジン ds4 (DwarfStar 4) を公開した（公開から数日で 7,700+ stars） Apple Silicon の Metal と Linux の CUDA をターゲットにした C 実装。GGML/llama.cpp にはリンクせず、DeepSeek V4 Flash 一本に特化した「narrow bet」設計 公式ベンチで Mac Studio M3 Ultra 512GB / Q4 / 12k context で 26.62 token/sec、Q2 なら 96/128GB の MacBook でも動作 OpenAI 互換 + Anthropic 互換 API を持ち、Claude Code から ANTHROPIC_BASE_URL を差し替えるだけでローカルモデルとして使える KV キャッシュをディスクに永続化するなど、ローカル推論の常識を更新する設計思想が随所に光る 実運用報告では コンテキスト 100K → 1M、KV ディスク 8GB → 64GB に拡張して Think Max モードを Claude Code 上でアンロック した例も登場 きっかけ: 「ds4 凄すぎるな」というツイート きっかけは @m_sigepon 氏のツイートだった。 ...

JS エンジニア・CTO として活動する hiroppy (@about_hiroppy) 氏が、James Shore のブログ記事「You Need AI That Reduces Maintenance Costs」を紹介するツイートを投稿した。AI エージェントによってコード生産性が向上しても、保守コストが同率で削減されなければ長期的には逆効果になるという主張だ。 ツイートの要点 hiroppy 氏は次のようにまとめている。 agent の導入でコード生産性が2倍になっても、保守コストが半分にならないと長期的には逆効果になるとのこと。AI 生成コードの保守コストが増加すると、5ヶ月程度で生産性向上分が消滅し、最終的には AI 未導入時より低い状態に陥る可能性があり、AI 活用では「速度向上率 × 保守コスト削減率 = 1」を満たすことが不可欠。 James Shore の保守コストモデル Shore は開発者 50 人を想定した試算として、次のような保守コストの見積もりを提示している。 期間 保守作業の目安 初年度 1ヶ月の開発につき 10日間 の保守 翌年以降 毎年 5日間 の保守 このモデルでは、保守コストを削減しないまま開発を続けると約 2.5 年後にチームの生産性の 50% 以上が保守に費やされる状態に達する。 AI 導入が裏目に出るシナリオ 仮に AI によって開発速度が 2倍 になっても、AI 生成コードが読みにくく保守コストが同じく 2倍 になってしまった場合を考える。 次の月の保守コストは 4倍 になる 5ヶ月後には生産性向上分が消滅する それ以降は AI 未導入時より低い状態に陥る Shore は、短期的な速度向上が保守コストの累積的な増加を生み、長期的な開発負債につながる危険性を警告している。 成功の条件：速度向上率 = 保守コスト削減率 Shore が指摘する根本的な条件は、AI が生産性を向上させた割合と同じ率で保守コストを削減することだ。 ...

Anthropic で Claude Code を担当するエンジニア Thariq Shihipar（@trq212）が X に記事「Using Claude Code: The Unreasonable Effectiveness of HTML」を投稿しました。公開からわずか16時間で440万ビュー・8,200いいね・15,700ブックマークを集め、開発者コミュニティで大きな議論を巻き起こしています。 その主張は一言で言えば「HTML is the new Markdown」。AI が出力するフォーマットとして、もう Markdown に縛られる必要はない、というものです。 背景：なぜ今 HTML なのか Markdown が AI 出力の事実上の標準になったのは GPT-4 の時代、コンテキストウィンドウが小さくトークン節約が最優先だったころの話です。 現在の LLM は百万トークン超のコンテキストを扱えます。トークン効率という制約が事実上消えたいま、出力フォーマットとして HTML を選ばない理由はほとんどありません。 Thariq はこの変化を踏まえ、Claude Code に依頼する成果物の多くを HTML で生成するよう切り替えました。その体験をまとめた記事と、20 の実例サイト を公開したのが今回の反響の発端です。 HTML が Markdown より優れている 5 つの理由 1. 情報密度（Information Density） HTML はテーブル・SVG・CSS・JavaScript・画像・インタラクションを 1 つの自己完結ファイルに収められます。Markdown には構造的な限界があり、複雑な情報表現には向きません。 2. 読みやすさの閾値（Readability Threshold） 「100 行を超える Markdown ファイルをちゃんと読んでいる人はほとんどいない」 HTML であればタブ切替・折りたたみセクション・レスポンシブレイアウトを使い、長大なドキュメントを人が実際に読める形にできます。 3. 共有の効率（Sharing Efficiency） ブラウザは HTML をそのままレンダリングします。Markdown ファイルは受け取った側が変換ツールを介さないと読めませんが、HTML は URL を共有するだけで即座に読める状態になります。 ...

海外トレーダーが Claude と仮想売買シミュレーターを組み合わせたBTC自動取引システムが話題になっています。モンテカルロ法で1万通りの市場シナリオを試した上で、勝率の高い戦略だけを実行するという仕組みで、AIと統計的アプローチを掛け合わせた実践的な取引戦略です。 話題のツイート @so_ainsight（Claude Codeで始めるAI自動化）さんがX でシェアしたツイートによると、海外トレーダーが Claude と仮想売買シミュレーターを組み合わせてBTCの自動取引システムを構築しているとのことです。 ポイントは次の3点です。 モンテカルロ法による市場シミュレーション リアルタイムの相場データを取り込む 1万通りのシナリオを回してから売買判断 「ほぼ全パターン試させた上で勝率の高い戦略だけを出させる」というアプローチが特徴的です。 モンテカルロ法とは モンテカルロ法とは、乱数を使ってシミュレーションや数値計算を行う手法です。金融分野では、資産価格の将来の変動をランダムウォークとして大量にシミュレーションし、リスクやリターンの確率分布を推定するために広く使われています。 BTC のような変動の大きい資産に対してモンテカルロ法を適用すると、次のようなことが可能になります。 「価格が10%上昇するシナリオ」「横ばいのシナリオ」「急落するシナリオ」など多数のパターンを一度に評価する 各シナリオでの損益を計算し、期待値と勝率を算出する 最もリスク調整後リターンが高い戦略を選択する Claude × BTC自動取引システムの仕組み 1. リアルタイム相場データの取り込み システムの入力は現在のBTCの価格データ、板情報、出来高などのリアルタイムデータです。Claude がこれらのデータを受け取り、市場の現在の状態を把握します。 2. 1万通りのシナリオ生成と評価 Claude は取り込んだ相場データをベースに、モンテカルロ法で1万通りの将来シナリオを生成します。各シナリオに対して仮想売買を実行し、利益・損失を計算します。 1 2 3 4 5 6 7 8 import numpy as np def monte_carlo_btc(current_price, n_simulations=10000, n_steps=24): """24時間先までの価格パスを1万通りシミュレーション（簡略化されたデモ用コード）""" # 0.02 は 1 ステップ（1時間）あたりの価格変動率の標準偏差（2%） returns = np.random.normal(0, 0.02, (n_simulations, n_steps)) price_paths = current_price * np.cumprod(1 + returns, axis=1) return price_paths 3. 高勝率の戦略だけを実行 1万通りのシミュレーション結果の中から、勝率が統計的に有意に高い戦略だけを実際の売買として実行します。Claude が戦略の選択と実行判断を担当し、「全パターンを試した上で最良の戦略だけを選ぶ」という仕組みを実現しています。 ...

Andrej Karpathy が2026年4月に公開した GitHub gist「LLM Wiki」が、公開から48時間以内に5000スターを超えた。コード一行も含まない、純粋にアイデアだけを記述したドキュメントがここまで反響を呼んだ理由はシンプルだ。「RAGの次」を具体的かつ実践的に示していたからである。 RAGとの決定的な違い 多くの人がLLMとドキュメントを組み合わせるとき、最初に試みるのが RAG（Retrieval-Augmented Generation） だ。ChatGPTのファイルアップロード、NotebookLM、LangChainで構築するベクトルDB検索 — これらはすべて「質問が来たときにドキュメントから関連部分を取ってきて回答する」という設計思想に基づいている。 この方式には根本的な問題がある。知識が蓄積されない。5つのドキュメントを横断する微妙な問いに対しても、LLMは毎回ゼロから関連箇所を探し出し、推論し直す。「矛盾」も「文脈」も「先週気づいた発見」も、次の質問では消えてしまう。 LLM Wiki が提案するのは根本的に異なるアプローチだ。 LLM が incrementally に永続的な wiki を構築・維持する。新しいソースを追加するたびに、LLM はそれを読み込んで既存 wiki に統合し、エンティティページを更新し、矛盾を記録し、進化する合成の全体を強化する。知識は毎回再導出されるのではなく、一度コンパイルされてから最新に保たれる。 この「コンパイルされた知識ベース」こそが LLM Wiki の本質である。 3層アーキテクチャ LLM Wiki は3つの層で構成される。 1. Raw Sources（生ソース） 記事、論文、画像、データファイルなど自分がキュレートしたソースドキュメントの置き場。不変（immutable） — LLMはここから読むだけで決して書き換えない。これが「真実の源泉」となる。 2. The Wiki（wiki本体） LLM が生成・維持するマークダウンファイルの集合。概要、エンティティページ、概念ページ、比較、合成。この層は LLM が完全に所有 する。あなたは読む側で、LLM が書く側だ。 3. The Schema（スキーマ） CLAUDE.md（Claude Code用）や AGENTS.md（Codex用）など、LLMに wiki の構造・規約・ワークフローを伝えるドキュメント。これが LLM を「汎用チャットボット」から「規律あるwikiメンテナ」に変える鍵だ。このファイルはあなたと LLM が協力しながら進化させていく。 3つの操作 Ingest（取り込み） 新しいソースを生コレクションに追加して、LLMに処理を依頼する。LLMはソースを読み込み、重要な情報を抽出し、wikiに統合する。一つのソースが10〜15のwikiページを更新することもある。一度に大量のソースをバッチ処理することも可能だが、Karpathy 自身は「一つずつ取り込み、要約を確認しながら進める」スタイルを好むと述べている。 Query（クエリ） wikiに対して質問する。LLMは関連ページを検索・読み込み、引用付きで回答を合成する。回答の形式は問いによって変わる — マークダウンページ、比較表、Marpスライド、matplotlibグラフなど。 重要な洞察: 良い回答はwikiに新しいページとして追記できる。「あの比較をお願いした結果」「見つけた新しい接続」— これらをチャット履歴に埋もれさせるのではなく、wikiに蓄積させることで探求が複利的に積み重なる。 ...

複数の AI コーディングエージェントを使い分けるのは手間がかかる。その課題を解決するのが oh-my-openagent（omo） だ。Claude Code・OpenAI Codex・Gemini CLI といった主要エージェントを一元管理し、タスクに応じて最適なモデルへ自動ルーティングするオープンソースのハーネスで、GitHub スター数は 5.7 万超（2026 年 5 月時点）に達している。 oh-my-openagent とは oh-my-openagent は、もともと oh-my-opencode という名称で 2025 年 12 月に登場し、その後マルチエージェント対応を強化するかたちでリブランドされたツールだ。 作者: code-yeongyu 言語: TypeScript ライセンス: SUL-1.0 公式サイト: ohmyopenagent.com キャッチフレーズは「the best agent harness」。単一のエージェントに何でも任せるのではなく、専門化されたエージェント群がタスクを分担し、並列実行することで開発速度と品質を両立させる設計思想を持つ。 対応エージェントとプロバイダー oh-my-openagent は以下のエージェント・モデルプロバイダーに対応している。 プロバイダー 主なモデル Anthropic Claude Code（claude-opus-4-6 / 4-7 等） OpenAI Codex、GPT-5.5 Google Gemini CLI GitHub Copilot その他 Kimi K2、DeepSeek V4 等 インストール時に利用中のサブスクリプションプラン（Claude Pro/Max、ChatGPT Plus など）を選択することで、利用可能なプロバイダーのみを有効化できる。 主要機能 マルチモデルオーケストレーション タスクの種類ごとに最適なモデルを自動選択する「カテゴリベースのモデル割り当て」が核心機能だ。 visual-engineering（フロントエンド・UI 実装）→ Gemini ultrabrain（高難度なアーキテクチャ設計）→ Claude Opus 4.7 artistry（クリエイティブな文章生成）→ GPT-5.5 deep（深い推論・リサーチ）→ Claude Opus / Kimi K2 コスト最適化の観点から、大量ファイル生成のような作業は DeepSeek V4-Flash などの安価なモデルに自動振り分けされる。 ...

香港大学データインテリジェンスラボ（HKUDS）が開発したオープンソースの動画生成フレームワーク ViMax が GitHub で急速にスターを伸ばしている（3,800超・MIT ライセンス）。1行のテキストアイデアを入力するだけで、脚本執筆・絵コンテ設計・キャラクター管理・最終動画レンダリングまでを自律的に実行するエンドツーエンドのマルチエージェントシステムだ。 ViMax とは ViMax（Video Maximizer）は「Director（監督）・Screenwriter（脚本家）・Producer（プロデューサー）・Video Generator（映像生成）をひとつに」という設計コンセプトで開発された動画生成フレームワークだ。従来、テキストから動画を生成するには複数のツールを組み合わせる必要があった。ViMax はそのパイプライン全体をマルチエージェント構成で自動化する。 GitHub: HKUDS/ViMax ライセンス: MIT 言語: Python 3.12+ Stars: 3,852+（2026年5月時点） 4つの生成モード ViMax には入力形式に応じた 4 つのモードが用意されている。 Idea2Video 1 行の概念・プロンプトを入力すると、ストーリーテリング・キャラクターデザイン・動画制作まで完全自動化される。「アイデアをそのまま映像に」したいユーザー向けのモードだ。 Novel2Video 小説の章や全文を入力すると、エピソード形式の動画に変換される。RAG（検索拡張生成）ベースのナラティブ圧縮機能でキャラクターの登場追跡とシーンごとの視覚的解釈を行う。長編小説の映像化に適している。 Script2Video ユーザーが書いたシナリオを動画化する。シーン・セリフ・スタイルを明示的に指定でき、映像表現への細かいコントロールが可能。 AutoCameo 自分の写真をアップロードすると、生成された動画に本人が一貫したキャラクターとして登場する機能。個人の顔や姿を主人公として組み込める。 主要な技術的特徴 インテリジェントな長編スクリプト生成（RAG ベース） 小説規模のテキストを解析し、マルチシーン形式に分割する。重要な伏線やキャラクターの台詞を保持しながら、映像に適した脚本へ変換する。 表現力豊かな絵コンテ設計 ショットレベルの絵コンテシステムに映画製作の語彙（カメラアングル・カット・テンポ・ナラティブリズム）を採用している。 マルチカメラ撮影シミュレーション 同一シーン内でのキャラクター配置・背景の一貫性を保ちながら、複数のカメラアングルをシミュレートする。 インテリジェントな参照画像選択 タイムライン上の過去の絵コンテを参照画像として自動選択し、長尺動画でもキャラクターや背景の整合性を維持する。 並列候補生成 + MLLM による一貫性チェック 複数の候補画像を並列生成し、マルチモーダル LLM（MLLM — テキストと画像を同時に扱える大規模言語モデル）が最も一貫性の高い画像を選択する。人間のクリエイターのレビューワークフローを自動化したアプローチだ。 並列ショット生成による高速化 同じカメラからの連続するショットを並列処理することで、生成時間を大幅に短縮する。 音声・映像バインディング 音声・効果音・映像を同期させ、没入感のある最終出力を生成する。 マルチエージェントパイプラインの構造 ViMax の処理パイプラインは以下の層で構成されている。 インストールと設定 動作環境: Linux または Windows / Python 3.12+ / uv（Astral パッケージマネージャー） ...

2026 年 3 月、Anthropic は Claude Code の思考深度（thinking effort）のデフォルト値を high から medium に静かに変更した。 リリースノートには目立つ記述がなく、多くの開発者は「最近 Claude の質が落ちた気がする」と感じながら原因を見つけられずにいた。 Claude Code の開発者である Boris Cherny 氏が Hacker News でこの変更を認め、その後 AI 開発者コミュニティで 15 の重要設定がまとめられて話題になった。 本記事ではそれらを日本語で解説する。 1. 思考深度（effort level）の復元 問題： 2026 年 3 月以降、デフォルトが medium に変更された。Claude の思考回数が減り、コードの質・ツール呼び出し数・コメントの充実度すべてが低下している。 修正方法： セッション内で一時的に変更する場合は /effort high、恒久的に変更する場合はシェル設定に追記する。 1 export CLAUDE_CODE_EFFORT_LEVEL=high 本格的なコーディング作業では high または max を設定することで、2026 年 2 月以前の品質に戻せる。 2. Adaptive thinking の無効化 問題： 2026 年 2 月以降、Claude はタスクの複雑さを自己判断して推論量を動的に調整するようになった。「簡単なタスク」と判断した場合はほぼ思考せず、バグを見逃すことがある。 ...