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

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 の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の個人知識グラフモデルにインスパイアされている。現在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で音声テキスト変換。音声が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 に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）のロジックは従来SEOと異なるから——Perplexity、Google AI Overview、ChatGPT Searchにあなたのコンテンツを読ませて、初めてユーザーの質問回答時にあなたを引用する。

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

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

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

このシステムは「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の記事で述べたように、個人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は無料枠内。