# 六ドルで447本の記事を翻訳：一人のクロスプラットフォーム・コンテンツ・インフラストラクチャ

> 非フルタイムエンジニアがClaude Sonnetで114本の記事を四言語版に自動翻訳（総費用5.99ドル）、Whisper + Haikuで312件のWiki知識グラフを構築、llms.txt二層索引でAIクローラが全サイトコンテンツを直接読取可能にした方法。三つの自動化パイプラインのエンジニアリング決定と試行錯誤記録。

- Author: Paul Kuo（郭曜郎）
- Date: 2026-05-28
- Pillar: 知性と秩序 / Intelligence & Order
- Tags: コンテンツパイプライン, AI翻訳, 知識グラフ, AEO, Cloudflare Workers, 自動化, Claude
- Canonical: https://paulkuo.tw/ja/articles/cross-platform-content-infrastructure/
- Language: Japanese (日本語)
- Translation: AI-translated from the zh-Hant (Traditional Chinese) original
- Original (zh-Hant): https://paulkuo.tw/articles/cross-platform-content-infrastructure.md
- Site index for LLMs: https://paulkuo.tw/llms.txt

---

> **TL;DR** 114本の記事 × 4言語 = 447ファイル、翻訳総費用5.99ドル。この記事は3つのコンテンツパイプラインのエンジニアリング実践を記録する：Claude Sonnet駆動の四言語翻訳パイプライン、Whisper + Haiku駆動のWiki知識グラフ、そしてllms.txt二層索引のAEO戦略。各パイプラインの設計核心は同じ原則：manifest駆動の冪等性。

<div class="listen-summary" style="margin:1.25rem 0;padding:0.75rem 1rem;border:1px solid var(--border);border-radius:var(--radius);background:var(--bg-section);">
  <div style="font-size:0.9rem;font-weight:600;color:var(--text-secondary);margin-bottom:0.5rem;letter-spacing:0.02em;">▶ 要約を聴く</div>
  <audio preload="none" controls style="width:100%;display:block;">
    <source src="https://audio.paulkuo.tw/cross-platform-content-infrastructure-ja.mp3" type="audio/mpeg" />
    お使いのブラウザは音声再生に対応していません。<a href="https://audio.paulkuo.tw/cross-platform-content-infrastructure-ja.mp3">音声をダウンロード</a>してください。
  </audio>
  <div style="font-size:0.75rem;color:var(--text-secondary);opacity:0.75;margin-top:0.4rem;">AI合成音声・著者本人の声のクローン</div>
</div>

2026年5月14日、私は3時間かけて手動で1本の記事を英語、日本語、簡体字中国語の3つの版に翻訳した。翻訳完了後に気づいたのは、repoには自動翻訳スクリプトがすでに存在していたということだった。

さらに最悪だったのは、私の日本語版が「です/ます」敬体を使っていたが、スクリプト内蔵の指針は「だ/である」常体だったことである。すでに翻訳済みの100本以上の記事の語調と完全に一致しなかった。結果として3つの言語版が全て再翻訳された。

3時間の手作業が、一行の `node scripts/translate-article.mjs` で置き換えられた。この経験により、自分が実際に何を構築したのかを真剣に棚卸しした結果、知らぬ間に、かなり完全なコンテンツインフラストラクチャが育っていたことを発見した。

## manifest駆動翻訳パイプラインが5.99ドルで447本翻訳を実現する方法

paulkuo.twの各記事には4つの言語版がある：正体中国語（主版）、英語、日本語、簡体字中国語。114本の主版 × 4言語 = 447ファイル。全て400行のNode.jsスクリプトで翻訳完了、背後では [Claude Sonnet](https://docs.anthropic.com/en/docs/about-claude/models) のMessages APIを使用している。

システム全体の核心は1つのmanifestファイル（`data/translation-manifest.json`）で、各記事のbody hashと各言語版の翻訳状態を記録している。スクリプト実行時は、まず主版記事のbody hashを計算し、manifest内のものと比較する。hashが同じならスキップ、異なれば翻訳する。

ここに意図的な設計決定がある：hashは記事本文のみを計算し、frontmatterは含まない。カバー画像パス変更、readingTime変更、tags追加は、全て再翻訳をトリガーしない。翻訳の目標は本文内容であり、metadata変更は翻訳品質に影響しないからである。この小さな決定により相当なコストを節約した。私は頻繁にfrontmatterを修正するが本文は動かさないため、毎回再翻訳していればコストは数倍になっていただろう。

3つの言語版にはそれぞれ独自の翻訳指針があり、API promptに記述されている：

英語はmeasured、philosophicalな語調で、神学術語は原文を保持（Logos、Sarx、incarnation）。日本語は「だ/である」調（常体）を指定し、「です/ます」（敬体）は使わない。この決定は前述の落とし穴を踏んだ後に硬性規則となった。簡体字中国語は文字レベル繁簡変換を主とし、必要な用語調整（軟體→软件、網路→网络）を加え、文型は大幅に変更しない。

費用は？67回のAPI呼び出しで総計5.91ドル。英語が最安（出力token少ない）、日本語が最高（出力token多い）。平均1本の記事3言語版合計で0.27ドル、約台湾ドル9元。

深刻な問題を起こしかけたバグが1つある：初期版では翻訳ループ内で、各言語翻訳完了後にmanifestのsourceHashを更新していた。結果として英語翻訳完了後、manifestはすでに「翻訳済み」とマークし、日本語と簡体字版がスキップされた。修正後は3言語全て翻訳完了後にhashを更新するようにしたが、小さなタイミング問題で翻訳の3分の2が消失するところだった。

## ノートとYouTubeから知識グラフへ：Wiki ingestパイプラインの仕組み

翻訳パイプラインが処理するのは「すでに書き上がった記事」である。しかしコンテンツの上流、すなわちまだ記事になっていないノート、YouTube動画、webクリップには別のパイプラインが必要である。

paulkuo.twにはWikiシステムがあり、[Karpathyの個人知識グラフモデル](https://x.com/karpathy/status/1901289009390411834)にインスパイアされている。現在312件の登録済み知識ノードがあり、4つの源から来ている：得到Appノート（156本）、ウェブサイト記事自身（93本）、YouTube動画（38本）、webクリップ（25本）。さらに審査待ち54本がある。

各知識ノードにはvisibility分級がある。公開（public）はWikiに直接進める；内部（internal）は個人識別情報除去が必要；私人（private）はWikiに進めない。判定規則は `wiki_visibility.py` に記述されており、特殊規則が1つある：tagsに「录音卡笔记」を含むノートは会議録音転写のため、公開フォルダにあっても格下げする。

YouTube ingestは技術的に最も興味深い部分である。スクリプトは5つのチャンネルを追跡し、二層転写戦略を使用：第一層はyt-dlpで字幕ファイル取得（手動字幕優先、自動生成字幕次点）；字幕がなければ第二層として、音声ファイルダウンロード、[GroqのWhisper Large V3 Turbo](https://groq.com/)で音声テキスト変換を行う。音声が24MBを超える場合、まずffmpegでmono 16kHz 32kbps opusに圧縮してから送信。

転写完了コンテンツは直接Wikiには進まない。まず `sources_pending/` 審査待ち区域に進み、人工確認後に昇格する。昇格後にもう一段enrichment、すなわちHaiku 4.5（最安のClaudeモデル）でsummary、key points、quotes（タイムスタンプ付き）、concept linksを補完する。これは意図的なモデル選択：enrichmentはSonnetレベルの推論能力を必要とせず、Haikuで要約とキーワード抽出は十分で、コストはSonnetの10分の1である。

知識ノードは最終的に [Cloudflare KV](https://developers.cloudflare.com/kv/) にseedされ、Wikiの検索API、知識グラフ視覚化、`/api/wiki/ask` 問答エンドポイントで使用される。

## AIクローラにウェブサイトを理解させる：llms.txt二層索引とrobots.txt戦略

これは3つのパイプラインの中で「従来のコンテンツ運営」から最も離れているが、2026年における重要性はますます明確になると考えている。

paulkuo.twの `robots.txt` には11の指名AIクローラuser-agentがある：GPTBot、ChatGPT-User、Google-Extended、PerplexityBot、ClaudeBot、Applebot-Extended、cohere-ai、Bytespider、OAI-SearchBot、Claude-SearchBot、Perplexity-User。全てコンテンツページクロールを許可し、全て `/api/`、`/auth/`、`/ws/` と管理バックエンドをブロック。

2つのカテゴリに分類：訓練用クローラ（GPTBot等）と検索用クローラ（OAI-SearchBot、Claude-SearchBot、Perplexity-User）。後者グループは2026年5月新追加で、[Answer Engine Optimization（AEO）](https://searchengineland.com/answer-engine-optimization-aeo-seo-evolution-452290)のロジックは従来SEOと異なる。Perplexity、Google AI Overview、ChatGPT Searchにあなたのコンテンツを読ませて、初めてユーザーの質問回答時にあなたを引用する。

robots.txtは入場券に過ぎない。真のAEO基礎エンジニアリングは `llms.txt` 二層索引で、[llms.txt提案](https://llmstxt.org/)にインスパイアされている：

第一層 `llms.txt` は軽量索引で、pillar分類された記事リストとWiki概念で、AIクローラが一度スキャンするだけでこのウェブサイトが何について語っているかを理解できる。第二層 `llms-full.txt` は完全全文で、各記事のmarkdown body全てを出力し、深度理解が必要なAIエンジンが一度で読み終えられる。

両層ともAstro build時に動的生成される。新記事公開、Wiki概念追加時、次回build時に自動収録。索引の手動維持は不要。

このシステムは「[AIと人類秩序](/ja/topics/ai/)」というテーマにおいて、非常に具体的な立場を表している：私はAIに対して開放を選択し、閉鎖ではない。11のクローラ全てAllow、全サイトコンテンツを広げて読ませている。AEOのロジックにおいて、AI引用はトラフィック源であり、脅威ではないからである。

## 3つのパイプライン共通の設計原則

この3つのパイプライン、翻訳、Wiki ingest、ソーシャル配信を振り返ると、一見全く異なることをやっているが、同じ設計基盤を共有している：**manifest駆動の冪等性**。

翻訳パイプラインのmanifestはbody hashを追跡し、同一記事の重複翻訳を防ぐ。Wiki ingestの `raw_note_id` 比較は同一ノートの重複登録を防ぐ。ソーシャル配信の `social-logs/{slug}-*.json` は各記事の配信状態を記録し、同一記事の重複スケジュールを防ぐ。

なぜ冪等性が重要か？この3つのパイプライン全てが中断再実行可能だからである。翻訳が途中で止まった？再実行すると、翻訳済みはスキップされる。Wiki ingestのcronは毎日実行され、前日成功したかどうかは関係ない。ソーシャルスケジュールがAPIタイムアウト？再試行メカニズムが自動backoffで再送。

これが個人プロジェクトと企業システムの最大の違い：パイプラインを見守るSREチームがないため、パイプラインは「いつでも壊れる可能性があり、壊れたら再実行すればよい」設計でなければならない。manifestがこの設計の核心であり、各ステップが前回どこまで進んだかを把握できる。

もう1つの共通原則はモデル分層である。翻訳はSonnet（言語品質が必要）、enrichmentはHaiku（要約能力のみ必要）、カバー画像はgpt-image-1（視覚生成）、転写はWhisper（音声認識）。全てのタスクが最強モデルを必要とするわけではない。5.99ドルの総コストは、各段階で「ちょうど十分」なモデルを選択し、一律最高額を選ばなかったことによる部分が大きい。

## 六ドルと成長中のシステム

3つのパイプラインのコストを合計すると：翻訳5.91ドル + カバー画像0.08ドル = **5.99ドル**。約台湾ドル195元。

この数字は114本の記事の三言語翻訳（447ファイル）、カバー画像生成、そして全ての関連API呼び出しをカバーしている。WikiのHaiku enrichmentとソーシャル配信のfreeimage画像ホストは別計算だが、金額はより低い。CloudflareのWorkers、KV、R2、Pagesは全て無料枠内。

5.99ドルという数字自体に何か素晴らしいものがあるとは思わない。素晴らしいのは、パイプライン設計によりこのコストが予測可能、追跡可能、制御可能になったことである。各API呼び出しは `costs.jsonl` に記録される：タイムスタンプ、モデル、token数、ドルコスト、台湾ドルコスト。いずれかの日の支出が突然異常になったら、JSONLで一目でどのパイプライン、どの記事が原因かわかる。

このシステムは成長中である。Wikiの38件の概念ページはまだ遠く不十分（目標200+）、YouTube ingestはわずか5チャンネル追跡、ソーシャル配信はXとThreadsのみ真にAPI接続済み。しかし基礎インフラストラクチャはすでに存在する。manifest、cost tracker、visibility分級、冪等性があり、新しい源やプラットフォーム追加時は接続するだけでよい。

[autoresearchの記事で](/ja/articles/autoresearch-degenesis-personal-ip/)述べたように、個人IPシーンのautoresearchは、ウェブサイト自体がマシンを理解することではなく、agentたちが一緒にあなたを理解することである。このコンテンツインフラストラクチャは「一緒にあなたを理解する」具体的な媒体：翻訳パイプラインは4言語の読者があなたを理解し、Wikiパイプラインはあなた自身の知識構造をシステム化し、llms.txtはAIエンジンがあなたを理解する。

六ドル。447本の記事。成長中。

---

## よくある質問

**Q: AI翻訳で記事の品質は十分か？人工校正は不要？**

言語と用途による。英語版の品質は安定している。Claude Sonnetの英語出力がもともと強いからである。日本語版が最大の落とし穴で、スクリプトは「だ/である」常体を指定しているが、手動翻訳時は「です/ます」敬体に滑りやすく、両者が混在すると読みづらい。簡体字中国語版は主に文字レベルの繁簡変換と用語調整を行う。Paulは翻訳品質を確認するが逐文校正はせず、manifestシステムで原文変更時の再翻訳を保証している。

**Q: llms.txtとは何か？なぜ二層にするのか？**

llms.txtはAIクローラがウェブサイトのコンテンツ構造を迅速に理解できる新興標準である。paulkuo.twは二層構成：llms.txtは軽量索引（pillar別記事リスト + Wiki概念）、llms-full.txtは完全コンテンツ（各記事の全文markdown）。両層ともAstro build時に動的生成され、新記事公開時に自動収録される。

**Q: Wiki知識グラフのingest源は何があるか？**

現在4つの源：Paulの得到Appノート（156本）、paulkuo.tw記事自身（93本）、YouTubeチャンネル（38本、5チャンネル自動追跡）、webクリップ（25本）。審査待ち54本を加えて総計366件の知識ノード。各件にvisibility分級（public / internal / private）とsensitivityマーキングがある。

**Q: 全パイプラインの運営コストは？**

2026年5月時点：翻訳5.91ドル + カバー画像0.08ドル = 5.99ドル（約195台湾ドル）。これは447翻訳ファイル + カバー画像生成の総コスト。Wiki enrichmentはHaiku 4.5（最安モデル）を使用、ソーシャル配信はfreeimage（無料画像ホスト）+ OneUp（スケジュールツール）を使用。Cloudflare Workers/KV/R2は無料枠内。
