このブログは「マーケティングエンジニア」という軸で発信を統一するため、全記事の文体をリブランディングすることにしました。技術的な正確さは保ちつつ、読者に伝わりやすい「ですます調」に統一するという判断です。しかし、ブログ記事は52本・約15,000行。手作業で変換するのは現実的ではありません。
Claude Codeのサブエージェント（Agent tool）を7バッチ並列で実行した結果、52記事・約15,000行の文体変換をビルドエラーなしで完了できました。この記事では、並列エージェントの具体的な使い方と、設計を改善していった過程を共有します。
問題：15,000行の文体変換をどうやるか
規模感
このブログ（Astro製の静的サイト）には、技術記事が52本ありました。
1ブログ記事: 52ファイル2合計行数: 約15,117行3文体: 全て「だ・である調」（常体）4目標: 全て「ですます調」（敬体）に統一さらに、その前段として Obsidian で管理していた草案33本を Astro のフォーマットに変換する作業も必要でした。草案にはObsidian固有の記法（[[wiki-links]]やメタデータ行）が含まれており、これも一括で処理したいタスクでした。
なぜ手作業ではダメか
文体変換は単純な文字列置換ではありません。「〜だ。」→「〜です。」のような変換でも、文脈によって適切な敬体表現が異なります。
- 「〜だが、」→「〜ですが、」
- 「〜できる。」→「〜できます。」
- 「〜していた。」→「〜していました。」
- 「〜だろう。」→「〜でしょう。」
しかも、コードブロック内やテーブル内、見出し、frontmatter は変更してはいけません。1記事ずつ手で直すと、52記事 x 平均30分 = 約26時間。週末しか作業できない環境では、1ヶ月以上かかる計算です。
何を作ったか：並列エージェントによるバッチ変換
Claude Code の Agent tool とは
Claude Code には「Agent tool」という機能があります。メインのClaude Codeセッションから、独立したサブエージェントを起動できる仕組みです。重要なのは run_in_background: true オプションで、これを指定するとサブエージェントがバックグラウンドで実行されます。つまり、複数のサブエージェントを同時に走らせることが可能です。
設計：52記事を7バッチに分割
52記事を7-8本ずつ、7つのバッチに分割しました。
1バッチ1: 記事 1-7 → サブエージェントA（バックグラウンド実行）2バッチ2: 記事 8-14 → サブエージェントB（バックグラウンド実行）3バッチ3: 記事 15-21 → サブエージェントC（バックグラウンド実行）4バッチ4: 記事 22-29 → サブエージェントD（バックグラウンド実行）5バッチ5: 記事 30-37 → サブエージェントE（バックグラウンド実行）6バッチ6: 記事 38-44 → サブエージェントF（バックグラウンド実行）7バッチ7: 記事 45-52 → サブエージェントG（バックグラウンド実行）7バッチが同時に走るため、直列で処理する場合と比べて大幅に時間を短縮できます。
各サブエージェントへの指示内容
各サブエージェントには、以下のような明確な変換ルールを渡しました。
変更するもの：
- 本文の地の文を常体→敬体に変換
- 「〜だ。」→「〜です。」
- 「〜する。」→「〜します。」
- 「〜した。」→「〜しました。」
- 「〜ている。」→「〜ています。」
- 「〜だが、」→「〜ですが、」
- その他、文脈に応じた自然な敬体変換
変更しないもの：
- frontmatter（
---で囲まれた部分） - コードブロック（
```で囲まれた部分） - テーブル内のテキスト
- 見出し（
##や###） - 箇条書きの体言止め
- 引用（
>で始まる行）
この「変更するもの / 変更しないもの」を明確に分けたことが、精度を保つ上で最も重要でした。
設計の改善ポイント
Obsidian草案の変換で学んだ教訓
52記事の文体変換の前に、Obsidian草案33本のAstro変換を実施しました。この工程で得た教訓が、後の文体変換の成功につながっています。
Obsidian → Astro変換では、以下の処理が必要でした。
# タイトル行を削除（frontmatter の title が使われるため）- メタデータ行（作成日/カテゴリ/対象読者/注目度）を削除
## 概要見出しを削除（本文は残す）[[wiki-links]]を通常のMarkdownリンクに変換- Astro 用の frontmatter を付与
最初の問題は 指示の粒度 でした。「Obsidian記法をAstro形式に変換してください」という曖昧な指示では、サブエージェントごとに変換ルールの解釈がばらつきます。あるエージェントは ## 概要 を残し、別のエージェントは削除する、という不整合が発生しました。
解決策: 変換ルールを箇条書きで厳密に定義し、全バッチに同じ指示テキストを渡す方式にしました。
文体変換での落とし穴
文体変換でも、最初のバッチで一つ問題がありました。「既にですます調で書かれている記事」の扱いです。52記事のうち5本は、もともとですます調でした。これらに対して変換をかけると、二重変換（「〜します。」→「〜しますます。」のような破壊）のリスクがあります。
解決策: サブエージェントの指示に「既にですます調の記事はスキップすること」を明記しました。各エージェントが記事を読み込んだ時点で文体を判定し、変換不要であればそのままにする、というルールです。
結果：15,000行を変換、230ページのビルド成功
定量的な成果
1変換対象: 52記事（うち5本はスキップ）2合計行数: 約15,117行3バッチ数: 7（並列実行）4ビルド結果: 230ページ、6.92秒、エラー0件ビルドが通ったことで、frontmatter の破損やMarkdown構文の破壊がないことを確認できました。Astro のビルドは構文エラーがあると即座に失敗するため、全230ページが正常に生成されたことは品質の担保になります。
所要時間の比較
| 方法 | 推定時間 |
|---|---|
| 手作業（1記事30分） | 約26時間 |
| Claude Code 直列（1記事ずつ） | 約3-4時間 |
| Claude Code 7並列バッチ | 約16分 |
並列実行の威力は明確です。ただし、並列にすること自体よりも、全バッチに同じ品質の指示を渡す設計が成功の鍵でした。
並列エージェントの実践的なコツ
1. 指示テンプレートを1つ作り、ファイルリストだけ差し替える
7バッチそれぞれに異なる指示を書くと、微妙な表現の違いから変換品質がばらつきます。実際に使った方法は、変換ルールのテンプレートを1つ作成し、対象ファイルのリストだけをバッチごとに差し替えるというものです。
1テンプレート:2 - 変換ルール（変更する / しない の定義）3 - 処理手順（Read → Edit → Read で確認）4 + 対象ファイルリスト（バッチごとに異なる）2. 変更してはいけない領域を明確に定義する
文体変換で最も危険なのは、コードブロックや frontmatter を壊すことです。「変更しないもの」のリストを具体的に列挙することで、サブエージェントが判断に迷う場面を減らせます。
3. ビルドで最終確認する
静的サイトジェネレーターの利点は、ビルドが通れば構文的には正しいと言えることです。52記事を変換した後、pnpm build を実行して230ページが全てエラーなしで生成されたことを確認しました。これが人間によるレビューの代替になるわけではありませんが、明らかな破壊がないことの保証にはなります。
4. サブエージェントの処理手順を「Read → Edit → Read」にする
各サブエージェントには、「ファイルを読む → 編集する → 再度読んで確認する」という3ステップを指示しました。最後のRead（確認読み）により、意図しない変更が入っていないかをサブエージェント自身がチェックします。
この手法が使える場面
並列エージェントによるバッチ変換は、以下のような場面で有効です。
- 大量のファイルに同じ変換ルールを適用する場合: 文体変換、コーディングスタイルの統一、import文の書き換えなど
- 変換ルールが明確に定義できる場合: 曖昧な指示では並列化の恩恵が薄れます
- ビルドやテストで品質を検証できる場合: 変換後の正しさを機械的に確認できることが前提です
逆に向かないのは、記事ごとに異なる判断が必要な作業（例：記事の内容を大幅にリライトする）です。並列エージェントの強みは「均質な処理を大量に」実行することにあります。
まとめ
Obsidian草案33本のAstro変換と、既存52記事の文体統一を、Claude Codeの並列エージェント機能で実行しました。約15,000行の変換を7バッチ並列で処理し、230ページのビルドがエラーなしで成功しています。
最大の学びは、並列化の成功は「指示の精度」で決まるということです。7つのサブエージェントが同じ品質で作業するには、変換ルールを曖昧さなく定義する必要があります。「変更するもの」と「変更しないもの」を明確に分けたテンプレートを用意できれば、あとはバッチに分けて並列実行するだけです。
手作業なら26時間、直列実行でも3-4時間かかる作業が、約16分で完了しました。Claude Codeの並列エージェントは、大量の定型変換タスクにおいて強力な武器になります。