Claude Platform on AWS の GA を Amazon Bedrock との比較で整理。ネイティブ API フル機能と AWS IAM・請求の両立がもたらす意味を解説。

結論を先に 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に「何を自律的にやるか」と「いつ人間を介入させるか」の境界を明確に定義している点だ。 ...

Raspberry Pi を遠隔地に何台もデプロイすると、いつも頭を悩ませるのが「文鎮化」と「OS アップデート」だ。SSH で 1 台ずつ繋いで作業するのは現実的ではなく、現地に出向くのはさらに困難だ。 balenaCloud は、まさにこの問題を解くために作られたマネージド IoT エッジプラットフォームだ。ひと言で言えば、IoT デバイスを Web サーバーのように運用管理できる仕組みだ。Raspberry Pi のような SBC（シングルボードコンピュータ）や産業用 PC を、クラウド経由でフリート単位に一括管理できる。 balenaCloud の仕組み — balenaOS と balenaEngine balenaCloud の最大の特徴は、アプリケーションを Docker コンテナとして動かす点にある。 コンポーネント 役割 balenaOS Raspberry Pi にインストールする専用の軽量 OS。OTA（Over-The-Air、ネットワーク経由の更新）に特化している balenaEngine Docker を IoT 向けに軽量化したコンテナエンジン 管理コンソール ブラウザで全拠点のデバイスを状態確認、ログ閲覧、再起動、アプリのデプロイ 開発者は手元の PC で書いたコードを balena push するだけで、世界中のフリートに一斉配信できる。Docker Compose 形式（docker-compose.yml）でマルチコンテナ構成を定義することも可能だ。 なぜ Raspberry Pi 運用で選ばれるのか 1. OTA 更新で「文鎮化」を防ぐ A/B パーティション balenaOS は A/B パーティション方式を採用している。デバイス内に OS が入る領域が 2 つあり、新しい OS は常に現在動いていない方のパーティションに書き込まれる。 ...

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 氏のツイートだった。 ...

Claude Code をはじめとする AI エージェントの運用で 「シークレットをどこにどう置くか」 は避けて通れない設計判断になります。Git リポジトリに暗号化したまま置ける SOPS（旧 Mozilla SOPS、現在は CNCF Sandbox プロジェクト）は GitOps と相性がよく、小〜中規模のチームや個人開発では有力な選択肢の一つです。 ただし、シェルやファイル操作の権限を持つ AI エージェントと組み合わせる場合、「AI が自分で復号して中身を覗き見・漏洩させない」 ための3つのガードレール設計が前提になります。本記事では SOPS のメリットと AI エージェント特有のリスク、そして推奨構成をまとめます。 SOPS を AI エージェント運用で使うメリット SOPS は「Git リポジトリに暗号化したまま秘匿情報を保存できる」シンプルなツールです。AWS KMS、GCP KMS、Azure Key Vault、age、PGP など、環境に合わせた暗号化バックエンドを選べます。 AI エージェントとの相性で見ると、特に次の3点でメリットがあります。 構成管理の簡素化 — 開発環境（.env など）とデプロイ環境の秘密情報を、同じ Git ワークフローで一貫管理できる diff が読みやすい — SOPS は YAML / JSON の 値だけを暗号化 し、キー（変数名）は平文で残せるため、AI エージェントが「どんな設定項目があるか」を構造として理解できる 柔軟なバックエンド — クラウド KMS から手元の age キーまで、用途に応じて使い分けられる 特に「キー名は平文・値だけ暗号化」という設計は、AI エージェントに「設定の存在は知らせるが値は見せない」運用と非常に親和性が高い構造です。 なお、マネージド型のクラウドサービスでシークレットを集中管理したい場合は、Infisical のような選択肢もあります。「Git で持つか／サービスで持つか」は採用判断のポイントになります。 AI エージェント特有のリスク 一方で、Claude Code のように Bash 実行権限を持つエージェントに SOPS を扱わせると、以下のリスクが顕在化します。 ...

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に蓄積させることで探求が複利的に積み重なる。 ...