Granda | Ideas & Code

Sony PSPでLLMを動かす

Sat, 16 May 2026 00:00:00 +0000

Sony PSP-2000は2007年製の333MHz MIPSハンドヘルドで、RAMは64MB。今週、私のPSPは1500万パラメータのTransformerを動かし、毎秒1〜2トークンの速度で英語テキストをLCDに出力している。

モデルはKarpathyのstories15M（TinyStoriesチェックポイント）で、int8量子化により約17MB。ランタイムはDockerでpspdev/pspdevを使ってクロスコンパイルされた純粋なCコード約1100行。PythonもなければLibtorchもなく、デバイス上に便利なランタイムも存在しない——PSPはメモリースティックから単一のEBOOT.PBPをロードするシングルプロセスボックスで、sceIo*、フレームバッファ、VFPUが与えられるだけだ。それ以外はすべて自分で構築する。

この記事は予算の話だ。各バイトの行き先、カーネルの実装、そして残されている課題について。

ハードウェア


CPU	MIPS Allegrex @ 333 MHz、インオーダー
FPU	スカラーfp32 + 4×4 VFPU（ベクター）コプロセッサ
RAM	64 MB（PSP-2000/3000）；初代PSP-1000は32 MB
OS	XMB、仮想メモリなし、`mmap`なし、スワップなし
出力	480×272 LCD、ホストが読めるstdoutなし

「mmapなし」の行が最も痛い制約だ。Linuxボックスなら重みファイルをmmapしてページキャッシュに任せられる。PSPではsceIoLseek + sceIoReadと単一のmallocアリーナしかない。フォワードパス#1の前に17MB全体をRAMに読み込むか、USB 1.1フラッシュドライブ程度の速度でメモリースティックからストリーミングしてスループットの崩壊を見守るかだ。

PSP-1000の32MBでは、重みとKVキャッシュと作業バッファを合わせたヒープ領域が足りない。2000と3000は64MBを搭載している。64MBが必要だ。

モデル

stories15MはKarpathyのTinyStoriesチェックポイントの中で最小——Transformerレイヤー6、隠れ次元288、アテンションヘッド6、語彙32000。合計約1500万パラメータ。fp32で約57MB。int8 q80——対称的なグループ量子化、グループサイズ64、グループごとにfp32スケール1つ——で約17MB。

アーキテクチャ: Llamaスタイルデコーダー、RoPE、SwiGLU FFN
レイヤー: 6
隠れ次元: 288
ヘッド: 6 (head_dim 48)
語彙: 32000
コンテキスト: 256 トークン
量子化: int8 q80 (group=64、対称)
ディスクサイズ: 17 MB

モデルの準備は専用のDockerイメージで行う：python:3.11-slim + CPUのみのtorch + karpathy/llama2.cのピン留めコミット。stories15M.ptをダウンロードし、export.py --version 2を実行してq80のmodel.binを生成し、BPEのtokenizer.binをビルドする。そして——重要な点——-ffp-contract=off -fno-fast-mathでKarpathyのrunq.cリファレンスもビルドし、固定プロンプトで実行してtests/expected.txtを生成する。このファイルがPSPとのdiff対象となるバイト単位の正確なx86リファレンスだ。詳しくは後ほど。

xAIの新しいコーディングエージェント「Grok Build」がプロンプトをプレーンテキストで同梱

Fri, 15 May 2026 00:00:00 +0000

xAIは昨日Grok Buildをリリースした——Claude CodeとCodex CLIへの回答だ。インストールコマンドは1行、バイナリは最上位コンシューマープラン（月299ドル、入門価格99ドル）限定で、エージェント自体はOpenAI互換のHTTPインターフェースを通じてGrok 4と通信する。

どの言語で作られているか気になってバイナリをダウンロードしてみた。その結果、30本ほどのシステムプロンプト原文、すべての内部サブエージェント名、すべてのツール説明、そしてアーキテクチャのかなり完全な全体像を手に入れた。trとgrep以上のツールは何も必要なかった。

この記事はその発見をまとめたものだ。

抽出方法

https://x.ai/cli/install.shのインストーラーはGoogle Cloud Storageバケットへ302リダイレクトし、プラットフォーム向けに単一の静的リンク済み〜100MB ELFをダウンロードする:

$ curl -fsSL https://storage.googleapis.com/grok-build-public-artifacts/cli/stable
0.1.210
$ curl -fsSL https://storage.googleapis.com/grok-build-public-artifacts/cli/grok-0.1.210-linux-x86_64 -o grok-bin
$ head -c 4 grok-bin | xxd
00000000: 7f45 4c46 .ELF

コンパイラのシグネチャ: /rustc/<commit>デバッグパス、panicked at、RUST_BACKTRACE、さらにtokio::、hyper::、reqwest:: — Rustと標準の非同期HTTPスタックだ。Cargoのクレートごとのソースパスが<name>-<version>/src/<file>.rsとして焼き込まれており、バイナリから直接完全な依存関係ツリーを抽出できる:

$ LC_ALL=C grep -aoE '[a-zA-Z][a-zA-Z0-9_-]{2,40}-[0-9]+\.[0-9]+\.[0-9]+/src/' grok-bin \
 | sed 's|/src/||' | sort -u | wc -l
410

410個のユニークなクレート-バージョンペア。その中には: ratatui、crossterm、tree-sitter、フルgitoxide、async-lsp、lsp-types、rmcp（Model Context Protocol）、rusqlite、bm25、tokio-tungstenite、oauth2、jsonwebtoken、ring、rustls、async-openai、notify、arboard、portable-pty、tower、axum。文字列を見る前に依存関係だけでアーキテクチャが読める: ratatui+crossterm TUI、tree-sitterパーシング、組み込みLSPクライアント、フルgitoxide、BM25語彙検索付きSQLiteストア、OAuth/OIDC認証、OpenAI互換ワイヤーフォーマット、MCP、ファイル監視、クリップボード。

文字列が残りを教えてくれる。Rustの定数は.rodataにnull終端で埋め込まれる。grep可能にするには:

$ tr '\0' '\n' < grok-bin > strings.txt
$ LC_ALL=C grep -aE '^You are' strings.txt | head
You are a memory assistant. Extract ALL useful information from this...
You are a memory assistant performing an incremental update...
You are a technical lead orchestrating a team of senior-engineer subagents...
You are an expert software engineer acting as a code verifier.
You are a fast, read-only codebase exploration agent.
You are a read-only software architect. Explore the codebase and design...
You are a web browsing agent. You can navigate, interact with, and extract...
You are performing a dream — a reflective pass over memory files.
You are an AI coding agent. You operate in a workspace with a provided codebase.
You are Grok, made by xAI. Do not reference Cursor or suggest Cursor-specific...
You are a shell command autocomplete engine. Given a partial command, output...
You are tasked with generating the session title.
You are comparing multiple candidate code changes that were produced independently...
You are returning to plan mode after having previously exited it.

エージェントのアイデンティティのほとんどが、たった一つのgrepでそこに現れる。

ファイアウォール編集のためのデッドマンスイッチ

Tue, 05 May 2026 00:00:00 +0000

ホームラボの自動化で最も怖いのは、SSHで接続中のルーターのファイアウォールルールを編集する行だ。

それでも、Claude Codeと私がどのように編集するかを紹介する。

恐怖

UDM Proの “Block inter-VLAN traffic” というルールを accept から drop に変更する必要があった。このルールは長い間誤って設定されていた――accept に設定されており、その上にあるすべてのフロー別許可をショートサーキットしていた――そして、それを閉じ直すことが目的だった。変更を実行するオーケストレーターは、自宅ネットワーク上のNixOS VMだった。もし変更によってそのVM（または自分自身のSSH）が使用しているパスが切断されれば、コンソールのフォールバックもなく、自分のルーターから締め出されることになる。

解決策は「注意する」ことではない。解決策は、危険な編集を自動的に元に戻すようにすることだ――問題ないと確認しない限り。

このパターンはすでに見たことがあるはずだ。macOSやWindowsでモニターの解像度を変更すると、「この表示設定を維持しますか？」というカウントダウンダイアログとともに15秒間適用される。画面が真っ黒になった場合、何もクリックできない――それがポイントだ。デフォルトの結果はロールバック。確認はオプトインだ。

これがまさに、ルールを変更しようとしているルーターのファイアウォール変更に対して求めるものだ。

トリック

udm_set_firewall_rules.py --flip-with-revert 300 --apply

意味：「ルールを切り替えるが、300秒後に自動的に元に戻す――やめるよう指示しない限り。」

順番に何をするか：

スナップショット。 現在のルールをGETして、完全なJSONペイロードをUDMの /root/.udm-flip-revert/payload-<id>.json に保存する。
リバートの準備。 ペイロードの隣に小さなシェルスクリプトを書く。このスクリプトはスナップショットをUDM APIにPUTし直す。
リバートのスケジュール。 systemd-run --on-active=300s --unit=udm-flip-revert-<id> でスクリプトを一時タイマーとしてキューに入れる。
切り替え。 新しいルール（action: drop）をPUTする。

これで5分間の確認ウィンドウが得られる：

✓ flipped 'Block inter-VLAN traffic' to action='drop'
⏱ auto-revert scheduled (~300s)

TO KEEP THE FLIP: ssh udm 'systemctl stop udm-flip-revert-66c1d…timer'
TO ROLL BACK NOW: ssh udm 'systemctl stop …timer; bash /root/.udm-flip-revert/revert-….sh'
WAIT IT OUT: do nothing — timer will revert in ~300s

3つの結果：

LLMの重みを手で書き換える

Wed, 15 Apr 2026 00:00:00 +0000

torchとtransformersだけを使って、ROME（ランク1モデル編集）のゼロから実装を書いた。目標は、1つの行列加算でGPT-2 Mediumの中にある単一の事実を書き換え、モデルが知っている他のすべてに何が起きるかを観察することだ。

4回の編集を行った。3回は外科的に正確だった。4回目は、ROMEの「外科的精度」が、最初から考慮するとは限らない実装の細部に対して非常に敏感であることを露わにした。

4つの編集

4つの異なるドメインにわたり、GPT-2 Mediumが実際に自信を持って知っている事実（正解に対してP > 0.5）を選んだ：

主語	元の事実	変更後
Harvard University	マサチューセッツ州にある	カリフォルニア州
Google	カリフォルニア州にある	テキサス州
タコス	メキシコ発祥	日本
自由の女神	ニューヨークにある	ラスベガス

4つの編集はすべて目標を達成した。更新後、モデルは編集プロンプトに対して確率≥0.98で新しい答えを予測した。つまりROME自体は機能する。変わるのはそれ以外のすべてだ。

きれいな3つの編集

4つのうち3つは、ROMEの論文が予測するように動作した。各編集後に無関係な事実に何が起きたかを示す：

タコス → 日本（更新ノルム：重みノルムの9%）

コントロール	編集後
寿司は日本から	✓ 変化なし
ピザはイタリアから	✓ 変化なし
ラーメンは日本から	✓ 変化なし
ブリトーはメキシコから	→ 日本

メキシコ料理空間で最も近い隣人であるブリトーだけが引きずられた。

Harvard → カリフォルニア（更新ノルム：13%）

コントロール	編集後
MITはマサチューセッツ州	✓ 変化なし（依然としてあいまい）
マサチューセッツ州の州都 = ボストン	✓ 変化なし
ボストンはマサチューセッツ州	✓ 変化なし
Yaleはコネチカット州	→ カリフォルニア

Yale — アイビーリーグ空間でHarvardに最も近い隣人 — が連れていかれた。他は何も動かなかった。

自由の女神 → ラスベガス（更新ノルム：16%）

アナリティクス

Fri, 03 Apr 2026 00:00:00 +0000

Claude Codeで宇宙船コンピューティングシミュレーターを構築する

Mon, 30 Mar 2026 00:00:00 +0000

宇宙船のコンピューターがどのように動作するかを理解したかった。リアルタイムスケジューリング、放射線耐性、火星のローバーが地球と通信し続けるための遅延耐性ネットワーク。アルテミスII（50年以上ぶりの有人月面ミッション）が間近に迫る中、今こそ深く掘り下げるべき時だと感じた。そこでシミュレーターを構築した。ゼロから。Claude Codeをペアプログラマーとして。

物理ハードウェアは一切不要。すべてがラップトップ上のQEMUとDockerで動作する。コードはGitHub。

flowchart LR
 QEMU["QEMU (Cortex-M3)"] -->|UART socket| Bridge[uart_bridge.py]
 Bridge -->|bpsendfile| SC[Spacecraft Node]
 SC -->|LTP + 5s delay| GS[Ground Station]

 subgraph Docker
 SC
 GS
 end

flowchart TB
 QEMU["QEMU (Cortex-M3)"] -->|UART socket| Bridge[uart_bridge.py]
 Bridge -->|bpsendfile| SC["Spacecraft Node (Docker)"]
 SC -->|LTP + 5s delay| GS["Ground Station (Docker)"]

なぜこのプロジェクトか

本当に難しいことを学びたかった。概念が馴染みなく、ツールが容赦ないもの。ARMをターゲットにするCコンパイラ。リンカースクリプト。メモリマップドI/O。割り込みベクターテーブル。

Claude Codeがこれを可能にした。すべてのコードを書いてくれたからではなく、実際にリンカースクリプトを書きながらそれが何をするかを説明してくれたから。説明は私が解決しようとしている実際の問題に根ざしていた。volatile、FreeRTOSの優先度プリエンプション、LTP再送タイマーについても同様だった。

ロードマップ

プロジェクトを4つのフェーズに分け、それぞれ前のフェーズの上に構築した：

フェーズ	内容	主要概念
ベアメタル	ARMクロスコンパイル、UART出力、割り込みハンドラー	メモリマップドI/O、SysTick タイマー、起動アセンブリ
FreeRTOS	タスク、キュー、ウォッチドッグ、優先度逆転	決定論的スケジューリング、mutexプロトコル、プリエンプション
DTN	2ノードネットワーク、劣化リンク、CFDP、コンタクトグラフルーティング	Bundle Protocol、ストアアンドフォワード、LTP信頼性
統合	火星距離遅延を伴う完全テレメトリーパイプライン	UARTブリッジ、tc netem、同期されたION OWLT

各フェーズには自動テストがある。すべてのマイルストーンはCIが通過したPRである。

駐車中のテスラはデータセンターだ

Fri, 13 Mar 2026 00:00:00 +0000

あなたの車は95%の時間、駐車されている。その中には、毎秒300〜500兆回の演算が可能なチップが搭載されており、冷却システム、電力変換、そしてセルラー無線が備わっている。それは何もしていない。

テスラとxAIはそれを変えようとしている。3月11日、イーロン・マスクは「Macrohard」を発表した——内部では「Digital Optimus」と呼ばれる、テスラとxAIの共同プロジェクトだ。駐車中のテスラを個人AIエージェントへと変える。チャットボットではない。あなたの画面を監視し、マウスとキーボードを操作して、実際の作業をこなすエージェントだ。

この名前はマイクロソフトへの意図的な皮肉だ。このシステムは「企業全体の機能をエミュレートできる」と主張している。誇張ではある。しかし、その根底にあるアーキテクチャは本物であり、ハードウェアはすでに大規模に展開されている。

ハードウェアはすでにある

テスラはアメリカの道路上に、AI3（旧HW3）またはAI4チップを搭載した約400〜500万台の車両を持っている。AI3は144 TOPSを実現し、AI4は300〜500 TOPSを実現する。2026年末に予定されているAI5は2,000〜2,500 TOPSまで跳ね上がる。

これらは汎用CPUではない。自動運転のためのビジョンモデルを低消費電力でパッシブ冷却のまま実行するために設計された、専用のニューラルネットワーク推論アクセラレーターだ。渋滞中のカメラ映像処理に向いている特性は、駐車場でのAIモデル実行にも向いている。

マスクはテスラの2025年第3四半期決算説明会でこのアイデアを提案した：1kWの推論能力を持つ車両が1億台あれば、それは100ギガワットの分散コンピューティングになる。冷却と電力変換はすでに車両に組み込まれている。データセンターの新規構築は不要だ。

2台のコンピューター、1台ではなく

ほとんどの人はテスラに1台のコンピューターが搭載されていると思っている。実際には2台ある。

AIチップ（AI3/AI4/AI5）が推論アクセラレーターだ——ニューラルネットワークの順伝播専用に設計されている。これが脳だ。何をすべきかを決定するエージェントモデルを実行する。

インフォテインメントシステムはフルスペックのAMD Ryzenワークステーションだ：

AMD Ryzen Embedded、4コア Zen+ 3.8 GHz
8 GB RAM（Model 3/Y）または16 GB（Model S/X）
AMD Navi 23 GPU（RDNA 2）——10 TFLOPS、PS5と同じアーキテクチャファミリー
128〜256 GB ストレージ
水冷式

これはカーステレオではない。ディスクリートGPUを備えた水冷式Linuxマシンだ。テスラがNavi 23を搭載したのは、センターディスプレイでCyberpunk 2077をプレイできるようにするためだ。しかし、車が駐車されていて誰もゲームをしていないとき、それはアイドル状態のコンピューティングリソースだ。

エージェントはクラウドVMを必要としない。車そのものがサーバーだ。AIチップがモデルを実行する。AMDシステムがコンテナ内でヘッドレスブラウザを実行する——Gmail、Googleスプレッドシート、Slack、エージェントが作業しているものなど何でも。水冷式冷却が、サーマルスロットリングなしに終夜の継続的な作業負荷を処理する。

車両から出るのは、WebアプリへのHTTPSトラフィックだけだ——メールを確認するときにノートパソコンが生成するのと同じトラフィック。あなたのデータはテスラやxAIのサーバーを通過しない。推論はローカルで行われる。ワークスペースもローカルだ。

アーキテクチャ：システム1とシステム2

Macrohardは推論を2つのレイヤーに分割する：

システム1（テスラのAIチップ） ——高速でリアクティブな処理。車載モデルがリアルタイムの画面監視、マウス移動、キーボード入力を担当する。これが直感的なレイヤー——パターンマッチング、視覚的解析、即時応答だ。
システム2（xAIのGrok） ——高レベルの推論。計画立案、多段階の意思決定、文脈の理解。タスクがより深い思考を必要とする場合、xAIのクラウドで実行される。

車がローカルで安価で高速な推論を処理する。高価な推論はクラウドで行われる。これはFSDを機能させるのと同じハイブリッドアーキテクチャだ——車がカメラ映像をミリ秒の遅延でローカル処理しながら、複雑なルート計画はネットワークに委ねることができる。

コンピューター使用では、エージェントが画面の状態を追跡してローカルで日常的な操作を処理しながら、「この請求書を承認すべきか」や「このメールにどう返信すべきか」といった判断はGrokに委ねることができる。

チャットボットではない。ワーカーだ。

重要な違いは、このシステムが何をするかだ。質問に答えるのではない。タスクを実行するのだ。

テスラが駐車されているとき、Digital Optimusは以下のことができる：

メールを処理して返信を下書きする
スプレッドシートに入力する
Webアプリケーションを操作する
多段階のワークフローを完了する
繰り返しデータ入力を処理する

各車がオーナーのタスクを独立して実行する。1回の推論呼び出しを複数の車両に分散させる必要はない——コンピューター使用は自明な並列化が可能だ。1台の車、1つのエージェント、1つのタスク。スケールはインターコネクト帯域幅ではなく、フリートサイズから生まれる。

これが重要なのは、コンピューター使用の遅延許容度が大きいからだ。フォーム入力エージェントは1アクションあたり30秒かかっても有用だ。リアルタイムの応答を待っているのではなく——眠っている間に実行する作業を委任しているのだ。

実際の使い勝手

アーキテクチャ図は忘れよう。日常的な体験はこうなる。

テスラアプリがコントロールプレーンだ。 充電、気候、セントリーモードの既存コントロールの隣に「エージェント」タブが表示される。それを使って：

タスクをキューに追加 ——「受信トレイを処理して」、「先週の領収書を照合して」、または「毎朝6時にメールを仕分けする」といった定期的なルール
アカウントを接続 ——Gmail、Googleドライブ、Microsoft 365、SlackのOAuthフロー
制約を設定 ——バッテリーの最低閾値、WiFiのみ、作業時間
結果を確認 ——エージェントが何をしたか確認し、アクションを承認または拒否する

あなたはベッドに横になっている。テスラアプリを開いて「先週の出張の経費報告書を提出して」と入力し、送信して眠りにつく。車はガレージに駐車されており、WiFiに接続され、バッテリーは80%だ。タスクを受け取る。

CIパイプラインステージとしてのビジュアルQA

Fri, 06 Feb 2026 00:00:00 +0000

先月PRをマージした。コードレビューは問題なかった。テストも通った。それから携帯電話でサイトを開くと、サイドバーが完全に壊れていた。

修正は些細なものだった—メディアクエリの欠落。モバイルビューを実際に見れば、バグは明らかだった。誰も見なかった。

だから見るパイプラインステージを追加した。

GitHubイシューを開いて、こう書く:

クライアントを追加するための手動入力オプションを実装。クリックすると、新しいクライアントを作成するフォームを含む幅広いスライドオーバードロワーが開く。

1つのコミット後、すべてのビューポートで各状態が機能することを証明する30枚以上のスクリーンショットとともにPRが届く。手動テストはゼロ。唯一の労力は機能説明を書くことだった。

コンセプト

PRへのプッシュごとに、GitHub Actionsワークフローが:

PRブランチからDocker Composeスタック(Django + Postgres)を起動
マイグレーションを実行し、テストユーザーをシード
ローカルURLをPlaywright MCP(ヘッドレスChromium)を使用したClaude Codeに渡す
PR diffに基づいて対話要素を実行
3つのビューポートで各状態をスクリーンショット
結果をPRコメントとして投稿

Claude Codeがブラウザを制御する。Docker Composeがアプリを提供する。GitHub Actionsがそれらを結びつける。レビュアーはローカルで何も実行せずに機能の証明を見る。

%%{init: {"flowchart": {"subGraphTitleMargin": {"top": 3, "bottom": 10}}} }%%
graph TD
 A["PRプッシュ"] --> B

 subgraph GHA["GitHub Actions Runner"]
 B["Checkout + Docker Compose"] --> C["マイグレーション + シードデータ"]
 C --> Agent

 subgraph Agent["Claude Code + Playwright"]
 direction LR
 D["PR Diffを読む"] --> E["ファイル → URLをマップ"]
 E --> F["ログイン + ナビゲート"]
 F --> G["スクリーンショット ×3ビューポート"]
 end
 end

 Agent --> H["PRコメント"]

 style GHA fill:transparent,stroke:#888
 style Agent fill:transparent,stroke:#888

ワークフロー自体は単純:

Agent Traceは誰のためのものか?

Fri, 30 Jan 2026 00:00:00 +0000

CursorはAgent Traceをリリースした。これは、リポジトリ内のどのコードがLLMによって書かれたかを追跡するためのオープン仕様である。モデル、ツール、会話、正確な行範囲を記録し、すべてがプロジェクト内のJSONLファイルに追加される。

提案内容:「エージェントがより多くのコードを書くにつれて、AIと人間のどちらから来たかを理解することが重要になる。」

私は仕様とリファレンス実装を読むのに時間を費やした。エンジニアリングは堅実だ。クリーンなスキーマ、思慮深い拡張性、良好なパートナーリスト(Amp、Amplitude、Cloudflare、Cognition、Google、Vercel)。しかし、私は一つの疑問に何度も戻った:このデータで何をするのか?

何を捕捉するか

LLMがファイルを編集するたびに、フックが起動してトレースを記録する:どのモデル、どのツール、どの行、どの会話。リファレンス実装は、CursorとClaude Codeの両方からのイベントを処理する:

// リファレンスフックから — イベントはstdinを通じて流れ込む
appendTrace(createTrace("ai", input.file_path!, {
 model: input.model,
 rangePositions,
 transcript: input.transcript_path,
 metadata: { conversation_id: input.conversation_id, generation_id: input.generation_id },
}));

仕様は4つの貢献者タイプ(human、ai、mixed、unknown)を定義し、コンテンツハッシュによる行レベルの帰属をサポートして、移動するコードを追跡する。ベンダー中立で、VCSに依存せず、名前空間付きメタデータを介して拡張可能である。

データフォーマットとしては、よく設計されている。問題は、それが何を可能にするかである。

帰属の課題

仕様は著者権を分類としてモデル化している。しかし、LLM支援コーディングは会話である。あなたは欲しいものを説明する。LLMが何かを生成する。あなたはその半分を編集し、関数を却下し、修正を求め、2回目の試行を受け入れ、その後手動でエッジケースを修正する。後で、別のLLMがブロック全体をリファクタリングする。

そのコードを誰が書いたのか?人間とLLMの著者権の境界は曖昧であり、ますます曖昧になっている。ほとんどの実際のコードはmixedになり、ほぼすべてがmixedであれば、分類はあまり意味をなさない。

行レベルの帰属には賞味期限の問題もある。トレースは「Claudeがコミットabc123で10-50行を書いた」と言う。2つのコミット後、誰かがそのブロックを再フォーマットするか、そこから関数を抽出する。仕様の答えはgit blameを通じてチェーンすることであり、コンテンツハッシュは移動するコードの追跡に役立つ。しかし、リベースやスカッシュマージのあるワークフローでは、チェーンが壊れる。これらは難しい問題であり、初期のRFCが表面化すべき種類のものだ。

欠けているアクション

仕様は明示的に明白な用途を否認している:コード所有権のためではない、品質評価のためではない、トレーニングデータの出所のためではない。「透明性」と言っている。しかし、透明性は手段であり、目的ではない。

コードがレビューとテストを通過すれば、LLMが書いたからといって何が変わるのか?バグがあれば、とにかく修正する。仕様は帰属を具体的なアクションに結びつけることは決してない。データは入るが、答えを得るための定義された方法がない。それがギャップだ — フォーマットではなく、ユースケースである。

興味深くなるところ

これは、仕様がまだ言っていないとしても、Agent Traceが実際に指し示していると私が考えるものだ。

すべてのLLM生成関数の背後には、推論トークン、間違った方向、リトライ、コンテキストスイッチ、ツール呼び出しがある。エージェントは単にコードを生成するだけでなく、そこに到達するためのプロセスを経る。ファイルを読み、インターフェースを誤解し、バックトラックし、別のアプローチを試し、テストを実行し、失敗を修正し、解決策に到達する。そのプロセスは最終的な差分では見えない。

フックはすでに帰属以上のものを捕捉している。入力サーフェスを見てみよう:

interface HookInput {
 hook_event_name: string;
 model?: string;
 transcript_path?: string | null;
 conversation_id?: string;
 generation_id?: string;
 session_id?: string;
 file_path?: string;
 edits?: FileEdit[];
 command?: string;
 duration?: number;
 is_background_agent?: boolean;
 composer_mode?: string;
 tool_name?: string;
 tool_input?: { file_path?: string; new_string?: string; old_string?: string; command?: string };
 tool_use_id?: string;
}

モデル、セッション、会話、ツール、コマンド、期間、バックグラウンドエージェントかどうか、コンポーザーモード、その入力を持つすべてのツール呼び出し。これは単なる帰属データではない。これはプロセスデータである。そして、プロセスデータこそが真の価値が存在する場所である:

評価。 どのモデルがどのパターンで苦労するか?1回の試行で済んだ関数は、12回のリトライを要した関数とは異なる — 出力が同一であっても。「誰が書いたか」ではなく「生成するのがどれほど困難だったか」。
エージェントネイティブなコードベース。 エージェントがモジュールで一貫して苦労している場合(多くの間違った方向、高いリトライ率、繰り返されるコンテキスト混乱) — それは、コードがエージェントの動作方法に対して構造化されていないというシグナルである。明確性、より良いインターフェース、より明示的な契約のためにリファクタリングできる。トレースデータは、コードベースがLLMコラボレーションに敵対的である場所のマップになる。
プロセス最適化。 どのツール構成がより良い初回試行コードを生成するか?どのプロンプティングパターンがバックトラックを減らすか?行の帰属からこれらに答えることはできない。目的地ではなく、旅が必要である。

正しい問い

Agent Traceは初期段階である。帰属モデリング、範囲の耐久性、クエリセマンティクスに関する実際の課題を持つRFCである。しかし、直感は正しい — LLMがより多くのコードを書くにつれて、それがどのように起こるかについての構造化データが必要である。

この仕様の最も有用なバージョンは、「LLMが何を書いたか?」ではなく「LLMがどのようにそこに到達したか?」かもしれない。行レベルの台帳は出発点である。プロセストレース — 推論、反復、解決策に到達するコスト — こそが、これがチームがLLMでより良いコードを書くために実際に使用するものになる場所である。

怠惰な開発者のためのリッチリンク

Sat, 10 Jan 2026 00:00:00 +0000

ブログのリンクをTwitterやSlackで共有すると、プレーンテキストとして表示されます。プレビュー画像はありません。granda.org/en/2026/01/02/claude-code-on-the-go/のようなURLだけです。

Open Graph画像が必要でした。標準的なアプローチ:各投稿に対して手動で1200x630の画像を作成する。それは面倒です。Claudeに自動化を依頼しました。

flowchart LR
 Push[git push] --> GHA[GitHub Actions]
 GHA --> Hugo[Hugo Server]
 GHA --> PW[Playwright]
 PW -->|screenshot| Hugo
 PW --> IMG[OG Image]
 IMG --> Commit[git commit]
 Commit --> Deploy[Deploy]

flowchart TB
 Push[git push] --> GHA[GitHub Actions]
 GHA --> Hugo[Hugo Server]
 GHA --> PW[Playwright]
 PW -->|screenshot| Hugo
 PW --> IMG[OG Image]
 IMG --> Commit[git commit]
 Commit --> Deploy[Deploy]

セットアップ

Claudeに問題を説明しました:投稿にはソーシャルプレビュー画像が必要ですが、手動で作成したくありません。記事の内容をスクリーンショットし、OG画像として保存し、フロントマターを自動的に更新します。

Claudeが構築したもの

コンポーネント	目的
`generate-og-image.js`	投稿のスクリーンショットを撮るPlaywrightスクリプト
`generate-og-images.yml`	投稿の変更時にトリガーされるGitHub Action
`baseof.html`の変更	条件付きog:imageメタタグ

PlaywrightスクリプトはヘッドレスのChromeを起動し、投稿に移動し、ライトモードを強制し、ヘッダーとフッターを非表示にし、1200x630でスクリーンショットを撮ります:

配信停止

Sat, 10 Jan 2026 00:00:00 +0000

処理中...

私のQAエンジニアはLLMです

Fri, 09 Jan 2026 00:00:00 +0000

Claudeはボタンをクリックできます。

些細なことのように聞こえますが、UIの構築方法を変えます。Playwright MCPを使うと、Claudeは単にコードを書くだけでなく、ブラウザを開き、localhostに移動し、実際に動作することを検証します。コードレビューで見逃すバグを発見します。

セットアップ

Playwright MCPはClaudeにブラウザ自動化を提供します。ヘッドレスChromiumで実行しています:

{
 "mcpServers": {
 "playwright": {
 "command": "npx",
 "args": ["@anthropic-ai/mcp-server-playwright", "--headless"]
 }
 }
}

これでClaudeはナビゲート、クリック、タイプ、スクリーンショットができます。ユーザーが見るものを見ます。

flowchart LR
 Claude([Claude Code]) -->|browser_snapshot| PW[Playwright MCP]
 PW --> Browser[Headless Chrome]
 Browser --> App[localhost:1313]
 Browser -.->|screenshot| Issue[(GitHub Issue)]
 Issue -.->|visual history| PR[Pull Request]

flowchart TB
 Claude([Claude Code]) -->|browser_snapshot| PW[Playwright MCP]
 PW --> Browser[Headless Chrome]
 Browser --> App[localhost:1313]
 Browser -.->|screenshot| Issue[(GitHub Issue)]
 Issue -.->|visual history| PR[Pull Request]

フロー: Claude Code → Playwright MCP → ブラウザ → スクリーンショット → GitHub Issues → PR

Claudeで独自のニュースレターを作成

Wed, 07 Jan 2026 00:00:00 +0000

Hacker Newsのトラフィック急増の2日目。4万人の訪問者、彼らに再びリーチする方法がない。ニュースレターの登録フォームが必要だった。

Buttondown、Beehiiv、Substack、ConvertKitを調べた。すべて過剰だった。私はメールアドレスを収集するだけでよかった。キャンペーン、分析、購読者管理は必要なかった。そして、自分のデータを所有したかった。

そこで、Claudeに構築を依頼した。

flowchart LR
 User([User]) --> Form[Newsletter Form]
 Form -->|POST /api/subscribe| Worker[Cloudflare Worker]
 Worker --> KV[(Cloudflare KV)]
 KV -.->|Daily sync| GHA[GitHub Actions]
 GHA -.-> Repo[(subscribers.jsonl)]

flowchart TB
 User([User]) --> Form[Newsletter Form]
 Form -->|POST /api/subscribe| Worker[Cloudflare Worker]
 Worker --> KV[(Cloudflare KV)]
 KV -.->|Daily sync| GHA[GitHub Actions]
 GHA -.-> Repo[(subscribers.jsonl)]

セットアップ

環境変数を介してCloudflare APIトークンをClaudeに渡し、欲しいものを説明した：メールアドレスを収集し、私が管理する場所に保存するフォーム。

30分足らずで、動作するニュースレターができた。

Claudeが構築したもの

コンポーネント	技術
フォーム	HTML + vanilla JS
バックエンド	Cloudflare Worker
ストレージ	Cloudflare KV
同期	GitHub Actions

フォームは/api/subscribeにポストするHugo partialである：

外出先でのClaude Code

Fri, 02 Jan 2026 00:00:00 +0000

私は携帯電話から6つのClaude Codeエージェントを並列で実行しています。ノートパソコンもデスクトップもなく、iOSのTermiusとクラウドVMだけです。

セットアップ

flowchart LR
 A[Phone] -->|Termius + mosh| B[Tailscale VPN]
 B --> C[Vultr VM]
 C --> D[Claude Code]
 D -->|PreToolUse hook| E[Poke webhook]
 E -->|Push notification| A

サイクルは、タスクを開始し、電話をポケットに入れ、Claudeが入力を必要とするときに通知を受け取ることです。どこからでも非同期開発。

インフラストラクチャ

シリコンバレーのVultr VM:

Spec	Value
Instance	vhf-8c-32gb
Cost	$0.29/時間 (稼働時は~$7/日)
Access	Tailscaleのみ (公開SSHなし)

作業時のみ支払います。2つのスクリプトがライフサイクルを管理します:

vm-start # Start VM, wait for Tailscale, connect via mosh
vm-stop # Halt VM

また、Vultr APIを直接呼び出すiOS Shortcutも持っています。Termiusを開く前に、電話からVMを起動します。

VMの公開IPにはSSHリスナーがありません。すべてのアクセスはTailscaleのプライベートネットワークを経由します。多層防御: クラウドファイアウォールはTailscale調整以外のすべてをブロック、バックアップとしてのローカルnftables、念のためfail2ban。

モバイルターミナル

TermiusはiOS/AndroidでSSHとmoshを処理します。moshが鍵です。ネットワークの移行に耐えられます。WiFiからセルラーに切り替え、デッドゾーンを歩き、電話をスリープにします。接続は持続します。

mosh --ssh="ssh -p 47892" mgranda@100.100.100.100

1つの注意点: moshはSSHエージェントを転送しません。GitHub認証が必要なgit操作には、tmux内で通常のSSHを使用します。

セッション永続性

シェルはログイン時に自動的にtmuxにアタッチします。Termiusを閉じて、数時間後に再度開いても、すべてがそこにあります。

AIに任せる

Sun, 28 Dec 2025 00:00:00 +0000

開発サーバーが必要だった：SSHアクセスと開発ツールがインストールされたVM。Claude Codeに何が欲しいか説明して、セットアップを任せた。

プロンプト

8コアと32GBのRAMを持つVultr VMを要求した。Tailscale経由でのみアクセス可能で、ネットワーク切断に耐える永続セッション付き。

Claude Codeが構築したもの

1. Vultr API経由でVMをプロビジョニング

8コア/32GBのUbuntuインスタンスを作成し、IPを待ってから、rootとしてSSH接続した。

2. SSHを強化

Port 49152 # ランダムな高ポート
PermitRootLogin no
PasswordAuthentication no
ListenAddress 100.x.x.x # Tailscaleインターフェースのみ

鍵ベースの認証のみ、Tailscaleインターフェースのみでリッスン。

3. 3層のファイアウォールを設定

UFW: Tailscaleサブネット以外のすべての着信を拒否
fail2ban: ログイン試行失敗後にIPを自動ban
Vultrファイアウォール: ハイパーバイザーレベルですべてをブロック

4. SSHを有効にしてTailscaleをインストール

curl -fsSL https://tailscale.com/install.sh | sh
tailscale up --ssh --authkey=$TAILSCALE_KEY

これにより、OpenSSHとは独立したTailscaleのビルトインSSHサーバー経由で2つ目のSSHパスが作成される。

5. 開発スタックをインストール

Node.js（nvm経由）、Python（pyenv経由）、Docker、一般的なツール。Dockerをsudoなしで実行できるように設定。

6. tmuxで永続セッションを設定

既存のセッションに自動的に再接続する起動スクリプトで、ネットワーク切断が実行中のプロセスを終了しないようにした。

7. ローカル管理スクリプトを作成

私のラップトップに、Vultr API経由でVMを起動・停止するdev-startとdev-stopスクリプトを作成。

ロックアウト

終了後、Claude Codeはrootログインが無効になっていることを確認するため、rootとしてSSH接続を試みた。ログインは失敗した。fail2banが失敗した試行に気づき、私たちをbanした。

Claude CodeはセカンダリパスとしてTailscale SSHを設定していた。tailscale sshを使って戻り、以下を実行した：

fail2ban-client set sshd unbanip 100.x.x.x

セットアップ

必要なもの：

Claude Code（またはツール使用可能な同様のAI）
クラウドプロバイダーアカウント（Vultr、DigitalOcean、AWSなど）
Tailscaleアカウント

APIキーを環境変数として保存し、名前で参照する（例：$VULTR_API_KEY）ことで、シークレットが会話に現れないようにする。

ClaudeとGitHub Actionsによるブログの自動翻訳

Tue, 23 Dec 2025 00:00:00 +0000

私が書くすべての記事は自動的に翻訳されます。Claudeが翻訳を処理し、結果をmainにコミットし、翻訳版はオリジナルと一緒にデプロイされます。

フロー

翻訳ワークフローは、英語コンテンツがmainにマージされるとGitHub Actionsで実行されます：

on:
 push:
 branches: [main]
 paths:
 - 'content/**/*.en.md'

flowchart LR
 B[mainにマージ] --> C[翻訳が生成される]
 C --> D[mainにコミット]
 D --> E[全言語で本番デプロイ]

プロンプト

ワークフローはclaude-code-actionを使用します：

For each .en.md file that was added or modified:
1. Read the English content
2. Create translations for these languages: es, nl, de, it, fr, ja, zh, ru, hi
3. Save each translation as filename.{lang}.md (e.g., hello-world.es.md)
4. Preserve the frontmatter structure exactly, but translate the title
5. Translate the body content naturally
6. Keep code blocks, URLs, file paths, and technical terms unchanged

1つのプロンプトで9言語すべてを処理します。「自然に翻訳する」は「このテキストを翻訳する」よりも流暢な出力を生成します。コードブロックと技術用語は英語のままです。

このサイトについて

Mon, 22 Dec 2025 00:00:00 +0000

概要

この文書は、このブログで採用されている執筆方法論について説明します。

1. はじめに

このブログは、主にLarge Language Models(LLMs)の支援を受けて生成されています。著者は方向性、編集、品質管理を提供し、機械は初稿と翻訳を提供します。

2. 根拠

著者は、AIを活用したコンテンツ作成に関する透明性を信じています。使用しているツールを隠すのではなく、この開示は以下を目的としています:

読者に適切な期待を設定すること
AIコンテンツに関する正直な規範に貢献すること
現代の執筆における協働的な性質を認めること

3. これが意味すること

アイデア: 人間が創出
構造: 協働
文章: 主にAIが生成し、人間がレビュー
翻訳: 完全にAIが生成(人間によるレビューなし)

4. 品質保証

英語コンテンツは公開前に人間によるレビューを受けます。翻訳は自動的に生成されるため、エラーや不自然な表現が含まれる可能性があります。著者は最終的に公開される英語コンテンツについて責任を負います。

5. お問い合わせ

このポリシーに関する質問や懸念は、著者にお寄せください。

プロフィール

Mon, 22 Dec 2025 00:00:00 +0000

概要

このドキュメントでは、このブログの著者に関する背景情報を紹介します。

1. 経歴

ソフトウェアエンジニアとして15年の経験を持ち、うち10年を実務で費やしてきました。主な専門分野：

分散システム
バックエンド開発とインフラ
フルスタックおよびエンドツーエンドの製品開発
ユーザーインターフェースデザイン
セキュアで信頼性の高いシステムの構築

2. 連絡先

業界の方々との交流を歓迎します： @mtt

こんにちは世界

Sat, 20 Dec 2025 00:00:00 +0000

ブログへようこそ！これは私の最初の投稿です。

ここではアイデア、メモ、興味深いことを共有していきます。