Claude Code でブログ全体を作り直した話

2023〜2024年頃までは、従来の技術ブログにはまだそれなりの価値があったと思っている。自分のメモを整理できるし、面接の経験や出くわした問題、踏んだ地雷の細かいところまで記録できる。

でも2025年の半ばを過ぎたあたりから、モデルのイテレーション速度がどんどん上がって、性能もどんどん上がって、2025年前半には「けっこう使えるな」と思っていた Cursor みたいな AI Code Editor でさえ、後半には明らかに Claude Code に太刀打ちできなくなっていた。これはもう時代に合わせてブログ全体を作り直すしかないな、と悟った（価値が残せることを祈りつつ）。

データ

まずデータから。この量を純粋に人力でやったら、果てしなく時間がかかる。そして断言できるけど、自分の先延ばし癖に完全に負けていたと思う。でも AI ツールの力を借りたら、10日で完了した（しかも旧正月の休み中に）。品質もまあまあ。ちょっとした奇跡だ。

Metric	Value
Duration	10 days (Feb 8–18, 2026)
Total commits	104
Files changed	1,078
Lines inserted	263,000+
Lines deleted	21,000+
Locales	4 → 10
Docs translated to English	89
Translation files generated	801 (89 docs × 9 locales)
Blog posts with full i18n	5
Tools used	Claude Code

実際にやったこと

Phase 1：基盤作り（Feb 8–9）— 8 commits

ホームページと About ページをゼロからリデザインした。CLAUDE.md をプロジェクトの憲法として整備——commit フォーマット、i18n ルール、ファイル構成の規約を定義。ロケールを4から6に拡張。全部 Claude Code との対話で進めた。

このフェーズは主にアーキテクチャの意思決定。ホームページはどうあるべきか？About ページの構成は？プロジェクト全体の規約は？こうした問いは Claude とのやり取りの中で詰めていった。特に実行計画の策定は Claude 任せで、自分は Review と調整だけ。

Phase 2：スケールアップ（Feb 11–12）— 14 commits

4つのロケール（pt-BR、de、fr、vi）を追加して合計10に。テーマ翻訳ファイルを生成。navbar と sidebar をリデザインしてコンテンツの整理を改善。defaultLocale を en に切り替えて Vercel の i18n routing を設定。依存パッケージもアップグレード。ロケール拡張はほぼ完全に機械的な作業で、まさに AI が得意とする領域だ。Token の消費はすごいけど、人力でこれを短期間でやるのはほぼ不可能。

Phase 3：コンテンツ（Feb 13–14）— 14 commits

古いブログ記事を整理。年末振り返り記事を執筆。全ブログ記事を10ロケールに翻訳。Projects ショーケースページを構築。ホームページの i18n を完了。UI コンポーネントのバグ修正（ShowcaseCard のボタン位置ズレ、dropdown のクリッピング問題）。

このフェーズで分かったのは、AI は破版（UI の崩れ）を一発で見つけるのが実は苦手だということ。何度もやり取りして、人間（つまり自分）が修正の方向を指し示し続けて、ようやく画面が正しくなる。

Phase 4：Sidebar + Blog（Feb 15）— 7 commits

docs の sidebar 構造を全面的に再編成。sidebar カテゴリラベルを全10ロケール分翻訳。過去のリファクタで残っていた206個の不要な翻訳キーを削除。レイオフ交渉のブログ記事を書いて全ロケールに翻訳。

Phase 5：Docs i18n（Feb 16–17）— 14 commits

最大のバッチ：89件のドキュメントを英語以外の9ロケールに翻訳し、801個の翻訳ファイルを生成。対象は Knowledge（JavaScript、TypeScript、CSS、Vue、React、Browser、Security、Engineering）、Experience、Coding セクション。

このフェーズと次のフェーズは、Token の消費が凄まじい。高度に機械的な翻訳作業を全部 AI に投げて、存分にやってもらった（だってほとんどの言語は自分では読めないし）。

Phase 6：品質修正（Feb 17–18）— 24 commits

このフェーズが存在するのは、Phase 5 の出力が十分にクリーンじゃなかったから。まるまる24 commits、AI が生成した翻訳の修正だけに費やした：

• ドイツ語：ウムラウトが ASCII 表記になっていた（ü じゃなくて ue、ä じゃなくて ae）
• フランス語：アクセント記号が脱落（é じゃなくて e、à じゃなくて a）
• ベトナム語：声調記号が完全に消滅（声調なしのベトナム語はほぼ読めない）
• スペイン語/ポルトガル語：全体的にアクセント記号が欠落
• 簡体字中国語：繁体字が混入（AI は時々この2つの書記体系を区別できない）
• CJK 残留：es、pt-BR、ja、ko、vi のコードブロック内に中国語のコメントが未翻訳のまま残存

1つ直すたびに新しい問題が湧いてくる。ポルトガル語のアクセント修正をしたら、過剰修正で frontmatter の id と slug フィールドが壊れた。ベトナム語の声調修正では1ファイル漏れた。スペイン語のアクセント修正には誤検知があって、追加の修正 commit が必要になった。

正直なところ、このフェーズはその言語を理解していない限り、人力での介入は本当に無理で、異なるモデルによるクロスバリデーションに頼るしかない。

AI が苦手なこと：

// Example：

- 1回目でウムラウト・アクセント・声調記号を正しく処理すること
- 繁体字と簡体字を安定して区別すること
- コード内のコメントを原文のまま残すか翻訳するかの判断
- コンテンツ変換の過程で frontmatter フィールドを壊さないこと

踏んだ地雷

アクセントと声調の大惨事。 AI は5言語にわたって非 ASCII 文字を ASCII の近似値で出力した。これが24件の修正 commits を生んだ——全体のほぼ4分の1。最悪だったのはベトナム語で、声調記号がないと言語全体がほぼ判読不能になる。

繁体字/簡体字の混在。 zh-cn の翻訳で、コードコメントやインライン引用に繁体字が混入していた。AI はこの2つの書記体系を安定して区別できなかった。

frontmatter の破損。 ドキュメント翻訳時に、AI が frontmatter の id と slug フィールドを書き換えてしまい、Docusaurus の routing が壊れることがあった。ポルトガル語のアクセント修正中に壊れた id と slug の修復だけで1 commit 使っている。

過剰修正の連鎖反応。 1つの問題を直すと、別の問題が生まれることが多い。ポルトガル語のアクセント修正が一部の技術用語まで過剰に修正した。ベトナム語の声調修正は1ファイルを見落とした。どの「修正」commit にも、新たな問題を生むリスクがゼロではなかった。

人間がまだ介入できるところ

アーキテクチャの意思決定。 どの10ロケールをサポートするか。sidebar をどう組織するか。何を navbar の dropdown に入れて、何をトップレベルに置くか。こうした決定がすべての下流の作業に影響する。

品質の判断。 UI が崩れていないか、設計通りになっているか。言語の翻訳に明らかな間違いがないか、たとえばデフォルトロケールの切り替えが正しく反映されているか。

CLAUDE.md ファイル。 本質的には Repo の憲法で、AI にプロジェクトの規約を教えるためのもの。commit フォーマット、ファイル構成、i18n ルール、絶対にやってはいけないこと。このファイルが充実するほど AI のミスは減り、人力介入の必要も減る。だから頻繁にイテレーションと更新が必要だ。

振り返り

まず充実した CLAUDE.md を用意する。 ここに書いた規約の一つ一つが、後の修正サイクルを何十回と減らしてくれる。数行から始まって、最終的には commit フォーマット、i18n ルール、プロジェクト構成、明確な禁止事項を網羅する完全なドキュメントに育った。

似たような作業はバッチ化して、レビューもバッチでやる。 1ファイルずつ翻訳しない。似たファイルを15個まとめて AI に渡して、出力をまとめてレビューする。細かいところをいちいち人力で承認する手間が省ける。

ツールはできるだけ並列で使う。 Claude Code で対話型の作業を進めつつ、Gemini や Codex にバッチ作業を引き渡す——これが一番の効率改善だった。並列化できる作業を直列にしてはいけない。

すべてを記録する。 commit メッセージ、フェーズの区切り、修正の経緯——全部が履歴に残っている。大規模な AI 支援プロジェクトをやるなら、commit 履歴がそのままドキュメントになる。