Granda | Ideas & Code

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

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

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

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