執筆・翻訳ワークフローの設計

この記事の目的

長文の執筆・翻訳を、品質を管理しながら量産できるワークフローとして設計できるようになります。長文生成の分割統治・スタイルと用語の統制・翻訳工程(機械翻訳後編集)の設計・人が見る箇所の絞り込み・スタイル準拠の自動評価を、実務の判断として持ち帰れる状態を目指します。

対象読者

• ドキュメント・記事・マニュアル・翻訳を、品質を保ちながら量産する仕組みを作るエンジニア・コンテンツ責任者
• 単発の生成はできるが、それを「レビューと統制のあるパイプライン」に組み上げたい実装者

前提知識

• プロンプトエンジニアリングの基礎技法 — 生成の指示・例・形式の設計
• プロンプト資産の管理 — スタイルガイド・用語集をプロンプト資産として管理する
• LLM-as-a-Judge — 開放的な出力の自動評価
• 日本語品質の評価 — 日本語の文体・自然さの評価

本文

概要: 品質は「一発生成」ではなく「工程」で作る

長文の執筆・翻訳を LLM で量産しようとすると、「1 回の生成で全部書かせる」やり方はすぐ頭打ちになります。長くなるほど一貫性が崩れ、用語がぶれ、後半で失速します。品質は一発の賢さではなく、分割統治と工程設計で作ります。

このライブラリ自身が、その一例です。テンプレート(templates/doc-template.md)で構造を固定し、執筆規約(AGENTS.md / CLAUDE.md)でスタイルを統制し、独立レビューと lint で検証する、という工程で品質を保っています。以下では、この「工程で品質を作る」考え方を、執筆と翻訳のワークフローとして一般化します。

長文生成の分割統治(アウトライン駆動)

長文は、一度に書かせず、アウトライン → セクション → 統合の順で分割して作ります。

• アウトラインを先に確定する: 全体の構成(見出しと各節の要点)を先に生成・確定し、それを骨格にします。骨格があると、各節を独立に生成でき、抜けや重複が見えます
• セクション単位で生成する: 各節を、アウトラインと「隣接する節の要約」を文脈として個別に生成します。全文を毎回コンテキストに載せるより、必要な文脈だけを渡すほうが安定します(コンテキストの圧縮と隔離)
• 一貫性を後段で担保する: 分割生成は、節ごとに用語・トーン・主張がぶれる弱点があります。統合の段で、用語の統一・重複の除去・つなぎの調整をします。分割で速く書き、統合で揃える、が基本形です

スタイル・用語の統制(スタイルガイド・用語集)

品質の量産には、「良い文章とは何か」を明文化して機械に渡すことが要ります。人の頭の中の基準では、量産で必ずぶれます。

• スタイルガイドを資産として持つ: 文体(敬体か常体か)・表記ルール・禁止事項を明文化し、プロンプト資産として一元管理します。各生成はこれを参照するので、改訂を以後の生成に適用できます。既存成果物へ反映するには、再検査・必要な修正や再生成を行います
• 用語集を適用し、検証する: 訳語・製品名・専門用語の対応表を用意し、生成後に用語集どおりか自動チェックします。「適用を指示する」だけでは守られないことがあるため、生成と検証の両方に用語集を効かせます
• 例が仕様として働く: 望ましい文章の実例を数個渡すと、スタイルガイドの文字だけより伝わります(プロンプトエンジニアリングの基礎技法の少数例)。ただし例の偏りは出力の偏りになるため、代表的な例を選びます

翻訳ワークフロー(文脈保持・用語統一・MTPE)

翻訳は、執筆と共通点が多い一方、原文への忠実さという固有の制約があります。品質を管理する定番が、機械翻訳後編集(MTPE / Machine Translation Post-Editing)です。

• 文脈を保持して訳す: 文を 1 文ずつ孤立して訳すと、指示語・敬語・専門用語の一貫性が崩れます。段落・文書単位の文脈を渡し、前後関係を保った訳にします
• 用語を統一する: 用語集(グロッサリ)と、過去訳の対訳メモリAgent が「覚えている」ように見えるデータの総称。短期記憶(コンテキスト)・作業状態・長期記憶(外部ストレージ)の 3 層に分けて設計する。を適用し、同じ語が文書内・文書間でぶれないようにします。これは翻訳品質の体感を最も左右する要素です
• MTPE の工程を設計する: 「機械翻訳 → 人による後編集」の工程で、人がどこをどこまで直すかを決めます。必要な品質、契約、用途に応じて後編集の範囲を決めます。ISO 18587 の公開概要 は、完全な人による後編集と担当者の能力を対象にしています。軽い修正で足りる用途と全文確認が必要な用途を区別し、全文確認を採る場合も工程全体の品質・所要時間で効果を測ります
• 後編集の負担を減らす前処理: 訳しにくい原文(曖昧・長すぎる文)は、前処理で整えると後編集が軽くなります。工程全体で人の手を減らす設計をします

レビュー工程の設計(人が見る箇所の絞り込み)

生成・自動検査・人のレビューの時間を測り、品質要件を満たす工程を選びます。リスクや契約上、全文のレビューが必要な場合もあります。機械検査で定型的な確認を減らし、人が意味や根拠を確認する時間を確保します。

• 機械で落とせるものは機械で落とす: 用語違反・表記ゆれ・リンク切れ・スタイル違反は、自動チェック(lint)で先に落とします。人はそこに時間を使いません
• 人はリスクの高い箇所に集中する: 事実の正しさ・機微な表現・重要な結論など、間違えると被害が大きい箇所に人のレビューを寄せます。機械による低確度の印付けは振り分け候補になりますが、自己申告の確信度を過信しません。高確度と判定した箇所も抜き取り、見逃しを測ります
• レビュー結果を還流する: 人が直した箇所は、スタイルガイド・用語集・プロンプトの改善材料です。同じ指摘を繰り返さないよう、工程に戻します(フィードバックループの運用)

評価(judge + 人手・スタイル準拠の自動チェック)

執筆・翻訳の品質は、正解が 1 つでないため評価が難しいドメインです。自動チェックと judge と人手を組み合わせます。

• 決定的チェックを先に: 用語集の文字列照合・定義済みの表記ルール・リンク到達性などはコードで検査できます。ただし文脈依存の用語の適否や、リンク先が主張を支えるかは別途確認します。ここは自動化を厚くします
• 開放的な品質は judge + 人手: 自然さ・一貫性・原文への忠実さは、基準を与えたLLM-as-a-Judgeで一次判定し、judge 自体の信頼性を人手ラベルとの一致で検証します。日本語の文体・自然さは日本語品質の評価の観点を使います
• 人手評価を賢く使う: 人にも誤りや評価の揺れがあるため、評価基準を共有し、判断が割れた例を調整します。リスクや品質要件に応じ、全数確認またはサンプリングと重点評価を選びます。judge の低確度箇所だけを見ず、高確度と判定した箇所の誤りも測ります

実務での注意点

アンチパターン

チェックリスト

関連トピック

• プロンプトエンジニアリングの基礎技法 — 指示・例・形式の設計
• プロンプトの上級パターン — スタイル強制・出力形式の制御
• プロンプト資産の管理 — スタイルガイド・用語集の一元管理
• コンテキストの圧縮と隔離 — 長文生成での文脈の渡し方
• LLM-as-a-Judge — 開放的な品質の自動評価
• 日本語品質の評価 — 日本語の文体・自然さの評価
• フィードバックループの運用 — レビュー結果の工程への還流

参考資料

• ISO 18587:2017, Post-editing of machine translation output  — 公開要旨で完全な人手後編集と担当者の能力を対象とすることを確認。本文の工程案を規格適合手順とは位置づけません(アクセス日: 2026-09-10)

TODO・未確認事項

なし