海外の規格・技術文書を訳して、社内の用語にそろえた要点にする

処理の起点を決める

設計・営業からの確認依頼が起点です。

最小構成では、担当者が依頼を受けたときに文書を貼ります。半自動化では、Googleフォームからの依頼をきっかけに Apps Script が動きます。Apps Script のインストール可能なトリガーには「フォーム送信時」があり、回答が入るたびに関数を実行できます。

依頼時に「対象製品」と「確認したい点」を必ず書いてもらってください。 これがないと、40ページ全体を訳すことになり、絞り込みが効きません。「この搬送装置に、この規格の非常停止の要求が当てはまるか」といった形で依頼を受けるのが理想です。

入力データを集める

「社内の技術用語集」が、この構成の効き目を決めます。

1行に1語を持ちます。

200語もあれば、訳文の読みやすさが大きく変わります。 過去に訳した資料から拾えます。

「要求の強さの表記ルール」も先に決めてください。

この4区分を訳文の中で視覚的に区別することが、この構成の中心です。

データの取得方法を決める

テキストの抽出： 形式ごとに扱いが違います。

規格文書では表が重要です。 「表3 絶縁距離」のような表が要求の本体であることがあり、表が崩れると要求が読めません。 表の抽出結果を必ず確認してください。

著作権に注意してください。 規格文書は著作物であり、購入したものであっても、複製や外部への送信の範囲が利用条件で定められていることがあります。 外部の生成AIに全文を送ることが許されるかを、設計の前に確認してください。 これは技術より先の確認事項です。

過去の訳の蓄積： 同じ規格の同じ条項を過去に訳していれば、それを参照します。訳語がぶれないための材料です。

AIへ渡す前に整形する

1. 対応するJIS等の確認 … 規格番号から、対応する日本語版があるかを確認します。あればそれを使い、この構成の対象外とします
2. 条項構造の分解 … 規格文書を「章 → 条 → 項」の構造に分解します。条項番号を保持することが必須です
3. 参照関係の保持 … 「5.3項による」「附属書Bを参照」といった参照を記録します。分割して渡すときに、参照先も一緒に渡します
4. 関係する条項の絞り込み … 対象製品の特性（電源方式、設置環境、可動部の有無）と照らし、関係しそうな条項を選びます
5. 表の抽出 … 表を構造として取り出します。崩れた表は人に回します
6. 用語集の引き当て … 文書中に現れる語のうち、用語集にあるものを抽出します

AIに処理させる

AIに次のことをさせないでください。

「この条項は当てはまりません」を書かせないことが、特に重要です。 適用範囲の判断を誤ると、必要な試験が抜けたまま製品が完成します。AIは「関係しそうな条項」を挙げるだけで、除外の判断はしません。

指示内容を固定する

あなたは、海外規格を読む技術者を支援する担当者です。
指定された条項を訳し、要求事項の一覧を作ってください。

【厳守事項】
- 要求の強さを必ず区別してください。
  shall は【必須】、should は【推奨】、may は【許容】、can は【可能】と
  訳文の冒頭に付けてください。
  原文にこれらの語がない記述は【記述】としてください。
  区別できない場合は【要確認】とし、needs_review に入れてください。
- すべての訳文に、対応する原文を original として併記してください。
  原文を省略しないでください。
- 社内の技術用語集にある語は、社内の呼び方に置き換え、
  初出時に原語をカッコで併記してください（例：筐体（enclosure））。
  用語集にない語は原語のままにし、unmapped_terms に入れてください。
  あなたが訳語を決めないでください。
- 自社製品が規格に適合しているかを判断しないでください。
  「適合しています」「この条項は当てはまりません」と書かないでください。
  適用の有無が疑わしい条項は、applicability_uncertain に挙げてください。
- 規格の解釈を書かないでください。
  「これは〜という意味だと考えられます」と補足しないでください。
  原文が曖昧な箇所は、そのまま訳して needs_review に入れてください。
- 他の条項への参照（「5.3項による」など）は、参照先の条項番号を
  references に記録してください。参照先の内容を推測して書かないでください。
- 数値・単位・許容差は、原文のまま転記してください。
  単位の換算をしないでください。

【要求の強さの表記ルール】
{modal_verb_rules}

【社内の技術用語集】
{glossary}

【対象製品の情報】
{product_info}

【確認したい点】
{inquiry_point}

【対象の条項】
規格番号・版: {standard_id}
{clause_text}

【過去の訳（同じ規格の旧版がある場合）】
{previous_translation}

「要求の強さを必ず区別してください」の1行が、この構成の中心です。 これがないと、汎用の機械翻訳と変わりません。

「訳語を決めないでください」も重要です。 用語集にない語にAIが訳語を当てると、その語が社内に広まります。用語は技術部が決めるものです。

「単位の換算をしない」も入れてください。 インチからミリへの換算で丸め誤差が入ると、公差の議論が狂います。

出力形式を固定する

{
  "standard_id": "",
  "standard_version": "",
  "product": "",
  "requirements": [
    {
      "clause_no": "",
      "strength": "必須 | 推奨 | 許容 | 可能 | 記述 | 要確認",
      "translation": "",
      "original": "",
      "references": [],
      "values": [
        { "label": "", "value_as_written": "", "unit_as_written": "" }
      ],
      "table_included": false
    }
  ],
  "unmapped_terms": [
    { "term": "", "context": "", "suggested_by_ai": false }
  ],
  "applicability_uncertain": [],
  "version_diff": [],
  "needs_review": [],
  "extraction_warnings": []
}

original（原文）を必ず併記します。 訳文だけでは、担当者が確かめられません。規格の適合判断は原文に基づくため、原文が手元にあることが前提です。

values に数値を原文のまま隔離するのは、換算による誤りを防ぐためです。訳文の中に数値を埋め込むと、単位が変わっていても気づきません。

unmapped_terms の suggested_by_ai は常に false であるべきです。true が入っていたら、AIが訳語を決めてしまっています。

applicability_uncertain には、「この製品に当てはまるか判断がつかない条項」を入れます。これが空なら、絞り込みが緩すぎる可能性があります。

なお、Claude API のような構造化出力の機能が使える場合は、形の崩れを防げます（Claude API では2026-09-16時点でベータ機能として提供）。

システムへ連携する

最小構成では連携はありません。担当者が生成AIの画面で作業します。

半自動化では、次をつなぎます。

訳した結果を、規格番号・版・条項番号で検索できる形で登録してください。 これがこの構成の効果を積み上げる部分です。同じ条項を2度訳さないだけで、月の負荷が変わります。

人が確認する

すべての訳を担当者が原文と照らして確認します。

見る優先順位は次のとおりです。

訳文だけを設計に渡さないでください。 要点の一覧には、必ず条項番号と原文を併記します。設計者が疑問を持ったときに原文に戻れる状態にしておくのが、この構成の最低条件です。

例外に対処する

記録を残す

• 対象の文書（規格番号・版・入手日）
• 訳した結果（条項番号・要求の強さ・訳文・原文）
• 担当者が修正した訳と、修正前後
• 用語集への追加履歴
• 依頼元・依頼日・対象製品
• 版が変わったときの差分

「担当者が修正した訳」の蓄積が、この構成を育てます。 「この語はこう訳す」という判断が貯まれば、用語集に追加できます。修正が減っていくことが、育っている指標です。

規格文書の原本の保管は、購入時の利用条件に従ってください。 社内での共有範囲が制限されていることがあります。