概要
以前、Time Columnsでは、日本語サイトを母艦にして英語版サイトを /en/ 配下へ増築しました。英語記事、英語トップ、英語版About、プライバシーポリシー、hreflang、sitemap、内部リンク、GitHub push、Cloudflare Pagesでの公開まで含めて、多言語サイトとして成立する形を作ったという話です。
今回は、その続きです。
英語版サイトの土台ができると、次に課題になるのは、日本語記事をどう英語版へ展開するかです。ここで単純に日本語記事を翻訳して終わりにすると、少し弱いと感じました。
SNSの自動翻訳であれば、元の投稿をその場で別言語として読めれば十分です。しかし英語版サイトの記事は、検索され、読まれ、内部リンクされ、sitemapに載り、canonicalやhreflangを持つ独立したWebページです。
つまり、英語版サイトへの展開は翻訳ではなく、英語版メディア運用です。
SNSの自動翻訳との違い
XなどのSNSでは、自動翻訳によって日本語投稿を英語で読むことができます。短い投稿や一時的な情報共有であれば、それだけでも意味は伝わります。
ただし、SNSの自動翻訳は基本的には元投稿の補助です。投稿そのもののURL構造、見出し、meta description、内部リンク、関連記事、sitemap、canonical、hreflangまでは持ちません。
一方で、英語版サイトの記事は英語用のURL、title、meta description、canonical、日本語版とのhreflang、sitemap.xml、英語トップからのリンク、関連記事を持ちます。検索エンジンやAIにもページ単位で認識されます。
ここまで含めると、これは翻訳機能ではなく、Webサイト運用です。
日本語原稿をまず確認する
Time Columnsでは、いきなりHTML化しないようにしています。まず日本語原稿を作り、内容を確認します。
この段階で見るのは、文章のきれいさだけではありません。一般論だけで終わっていないか、Time合同会社の実務判断に着地しているか、くどくなっていないか、公開して問題ない内容か、既存記事と重複しすぎていないかを確認します。
特に重要なのは、記事の芯です。SEOを意識すると入口は一般キーワードで構いません。しかし本文まで一般論で終わると、他のサイトと同じような記事になります。
日本語原稿の段階で芯を確認しておくと、英語版へ展開するときにも軸がぶれにくくなります。
英語版は直訳しない
日本語原稿が固まったあと、英語版を作ります。ただし、ここでも直訳はしません。
日本語の記事は、日本語の読者、日本国内の文脈、Time合同会社の実務感に合わせて書いています。一方で英語版は、英語圏の読者や検索意図に合わせて、タイトルや構成を少し変える必要があります。
日本語では体験談寄りのタイトルでも、英語ではトラブルシュート寄りにした方が検索意図に合うことがあります。日本語では自然な表現でも、英語にそのまま移すと説明不足になることもあります。
英語版は日本語版のコピーではありません。日本語原稿を元にしながら、英語版として読まれる目的に合わせて再構成します。
文体も目的によって変える
同じ内容でも、掲載先によって文体は変わります。Time Columns本体の記事では、落ち着いた実務コラムとして書きます。検索エンジンにも読者にも伝わるように、構造、見出し、内部リンク、meta descriptionを意識します。
一方で、Medium、DEV、Hashnodeのような外部媒体に出す場合は、英語圏の読者が読みやすい導入や言い回しに変える必要があります。SNSなら、さらに短く、反応されやすい形にします。
自動翻訳は、元の文章を別言語で読めるようにするものです。英語版メディア運用は、読者、検索意図、掲載先、サイト構造に合わせて文章を作り直すものです。
HTML化とSEO設定まで含めて進める
英語版の文章を作ったあと、HTML化します。ここで必要になるのは本文だけではありません。
- title
- meta description
- canonical
- hreflang
- visible breadcrumb
- BreadcrumbList JSON-LD
- article summary
- 目次
- 関連記事
これらを整えることで、英語版記事は単なる翻訳文ではなく、サイト内の正式なページになります。
sitemapと内部リンクまで更新する
記事を作っただけでは、サイト運用としては完了しません。Time Columnsでは、記事を追加したら、トップページ、カテゴリページ、記事一覧、英語トップ、関連記事、sitemap.xmlを更新します。
英語版記事も同じです。英語版トップから辿れるか、日本語版から英語版へ行けるか、英語版から日本語版へ戻れるか、sitemap.xmlにURLが入っているか、canonicalとhreflangが正しいかを確認します。
ここまで確認して、ようやく公開できる状態になります。
GitHub pushでCloudflare Pagesへ反映する
Time Columnsは、GitHubとCloudflare Pagesで運用しています。ローカルでHTMLを作成し、検証し、GitHubへcommit / pushすると、Cloudflare Pages側で自動的に反映されます。
重要なのは、AIが文章を書くところだけではなく、公開工程まで関われることです。日本語原稿を確認し、英語版へ再構成し、HTML化し、トップや一覧を更新し、sitemapを更新し、内部リンクを確認し、GitHubへpushする。
ここまでつながると、生成AIは単なる翻訳ツールではなく、Webメディア運用の実務パートナーになります。
それでも人間の確認は必要
もちろん、すべてを自動化すればよいわけではありません。特に確認すべきなのは、記事の方向性です。
AIは文章を整えたり、英語にしたり、HTMLへ落とし込んだりできます。しかし、その記事を出す意味があるのか、既存記事と重複していないか、Time合同会社の実務視点が入っているか、公開して問題ないかは、人間が判断する必要があります。
AIに任せるのは、翻訳そのものではなく、公開可能な形へ展開する作業です。人間は、何を出すか、どう見せるか、どの品質で公開するかを判断します。
Time合同会社での考え方
Time合同会社では、生成AIを文章を作る道具だけではなく、Web運用の工程をつなぐ道具として見ています。
記事を書く。原稿を確認する。英語版へ再構成する。HTML化する。SEOタグを入れる。内部リンクを整える。sitemapに追加する。GitHubへpushする。Cloudflare Pagesで公開する。
この一連の流れをAIと一緒に進めることで、少人数でもメディア運用の速度を上げられます。重要なのは、英語ページがWeb上の資産として成立しているかです。
まとめ
日本語原稿を英語にするだけなら、自動翻訳でもある程度できます。しかし、英語版サイトとして公開する場合は、それだけでは足りません。
日本語原稿を確認し、英語版として再構成し、HTML化し、canonical、hreflang、sitemap、内部リンク、関連記事、英語トップまで整える必要があります。
SNSの自動翻訳は、その場で意味を伝えるための機能です。英語版サイトの記事は、検索され、蓄積され、内部リンクされ、サイト全体の情報資産になります。
生成AIとCodexを使うことで、日本語原稿チェックから英語版サイト公開までの流れはかなり短くできます。ただし、最後に必要なのは人間の判断です。