公式ドキュメント翻訳ワークフローの開発 – Spring & MySQL 公式ドキュメントの翻訳と検索
(devrunner.dev)紹介
こんにちは。
今回、公式ドキュメントシリーズを翻訳するワークフローを作成し、MySQL と Spring Boot の翻訳結果を検索可能な形で公開しました。
私は面接の前後に公式ドキュメントをざっと読むことが多いのですが、同じような用途で使う方々にも役立てばと思います。
実際のプロンプト、サービスのリンク、そして今回 5.1 を使うにあたって参考にした OpenAI のブログ記事は、下のリンク集にまとめておきました。
GPT-5.1 以降、LLM 推論性能に対する体感
GPT-3.5 の時代から翻訳の自動化を試してきて、そこで感じた体感的な性能差を記録します。
GPT-3.5 基準では、5,000〜10,000字程度の比較的短いテキストでも、Markdown 形式の補正のような小さな作業ですら高品質に実行できないことがよくありました。
一方で GPT-5.1 では、次のような作業を比較的安定して実行できました。
- 10万字を超える HTML から、1,000件以上の TOC 情報（6カラム）を順序を保ったまま安定して抽出
- どの用語を英語のまま残し、どの用語を翻訳するかという判断を LLM に任せても、可読性の高いドキュメントが返ってくる（例: Spring ドキュメントでは bean は英語のまま、factory は日本語表記）
作業中に崩れたり補完が必要なケースでは、system prompt にルールを追加する形で対応しました。
system prompt が長くなっても結果品質が大きくぶれない点は、過去のモデルでは期待しにくかった部分でした。
リンク集
以下に、今回の作業に関連する参考資料を整理しておきました。
これほどヘビーなプロンプト要求でも、現在のサービス水準の結果が出せることを示す参考資料として意味があると思い、共有します。
（プロンプト自体がうまく書けているとは思っていません（笑）。こうしたプロンプトのコツは Anthropic や OpenAI のブログにたくさんあるので、代表的なものを 1 つ添えておきます）
2件のコメント
検索結果のドキュメント数が常に0のようです
おっと！ ご報告ありがとうございます。
今は私の環境では問題なく表示されています。それでも念のため、デプロイをもう一度確認しました。
それでも確認できるように、どの検索語を使ったのか教えていただけると助かります。
今は韓国語 <-> 英語の同義語辞書がないので、単純にマッチせず表示されなかった可能性もあります