研究開発部門が月次の技術報告書の原稿を、社内の表記の決まりと単位・記号の書き方に沿って校正し、数値を変えない指摘だけを執筆者に返す
月次の技術報告書の Word の原稿を、社内の用字用語の表と、単位・記号の書き方の決まりに照らして校正します。指摘は段落の番号と決まりの番号を付けて返し、数字が1つでも変わる指摘は出しません。
- 生成AI
- Azure OpenAI Service/Claude
- 連携・自動化
- Power Automate
- 対象業界
- IT・SaaS/建設/製造
- 対象部門
- 品質管理/研究開発
- 対象業務
- 内容確認・チェック
- 主な課題
- 属人化している/書類作成に時間がかかる/確認ミスが多い
- AIで行う処理
- 校正
- 主な効果
- 品質標準化/属人化解消/工数削減
- 導入難易度
- ★★☆☆☆
- 実装レベル
- 本格構成
- 費用感
- API連携(中)
- 人間の確認
- 条件付き
01導入前 / 導入後の業務フロー
- 研究員が報告書の原稿を書き、グループリーダーに出す
- グループリーダーが内容を確かめ、気づいた表記にも赤を入れる
- 研究員が直し、編集の担当に出す
- 編集の担当が、用字用語の表と単位・記号の決まりを横に置いて、1本ずつ読む
- 直すところに Word のコメントを付けて、研究員に戻す
- 研究員が直し、編集の担当がもう一度見て、文書ライブラリに登録する
- 人研究員が原稿を書き、文書ライブラリの「校正」のフォルダに保存する
- 自動Power Automate が保存をきっかけに動き、Azure Functions に原稿を渡す
- 自動Functions が原稿を段落・表のセル・図の説明に分け、斜体・上付き・下付きの書式を印にした文字にする
- 自動Functions が、文字の並びで決まる決まり(数値と単位の空白、単位記号の略し方、小数点の前の0など)を規則で拾う
- 自動Azure OpenAI が、文脈で決まる決まり(量の記号の斜体、用語の言い換え、単位に情報を付けた書き方など)を段落ごとに指摘する
- 自動Functions が、指摘の元の文字列が段落にあるか、指摘の前後で数字が変わっていないかを確かめ、合わない指摘を外す
- 自動段落の番号・元の文字列・直し方・決まりの番号を並べた指摘の一覧を作り、研究員に知らせる
- 人研究員が一覧を見て、原稿を直す。決まりに合わないと思う指摘は、理由を書いて残す
- 人グループリーダーが内容を確かめ、編集の担当が直した原稿と一覧の残りを見て登録する
各工程の詳しい説明を読む
- 研究員が報告書の原稿を書き、グループリーダーに出す
- グループリーダーが内容を確かめ、気づいた表記にも赤を入れる
- 研究員が直し、編集の担当に出す
- 編集の担当が、用字用語の表と単位・記号の決まりを横に置いて、1本ずつ読む
- 直すところに Word のコメントを付けて、研究員に戻す
- 研究員が直し、編集の担当がもう一度見て、文書ライブラリに登録する
(a)同じ指摘を毎月繰り返す。 「25℃」を「25 °C」に、「10sec」を「10 s」に。同じ研究員の同じ書き方に、毎月同じコメントを付けています。 決まりを覚えてもらえば済むことですが、研究員は毎月入れ替わりで報告書を書きます。
(b)直すところが人によって違う。 2番目でグループリーダーが直す範囲と、4番目で編集の担当が直す範囲が違います。グループリーダーが「5wt%」でよいと言い、編集の担当が「質量分率 5 %」に直すと、研究員はどちらに合わせればよいか分かりません。
(c)文字だけでは見えない誤りがある。 量の記号の斜体、下付きの文字、上付きの指数(m2 と m²)は、画面で読み流すと見落とします。 印刷して読めば気づきますが、80本を印刷して読む時間はありません。
(d)直したつもりで数値が変わる。 研究員が表記を直すときに、「1.50」を「1.5」と打ち直すことがあります。 書き方の指摘のつもりが、有効数字が変わったまま登録されます。
- 【人】 研究員が原稿を書き、文書ライブラリの「校正」のフォルダに保存する
- 【自動】 Power Automate が保存をきっかけに動き、Azure Functions に原稿を渡す
- 【自動】 Functions が原稿を段落・表のセル・図の説明に分け、斜体・上付き・下付きの書式を印にした文字にする
- 【自動】 Functions が、文字の並びで決まる決まり(数値と単位の空白、単位記号の略し方、小数点の前の0など)を規則で拾う
- 【自動】 Azure OpenAI が、文脈で決まる決まり(量の記号の斜体、用語の言い換え、単位に情報を付けた書き方など)を段落ごとに指摘する
- 【自動】 Functions が、指摘の元の文字列が段落にあるか、指摘の前後で数字が変わっていないかを確かめ、合わない指摘を外す
- 【自動】 段落の番号・元の文字列・直し方・決まりの番号を並べた指摘の一覧を作り、研究員に知らせる
- 【人】 研究員が一覧を見て、原稿を直す。決まりに合わないと思う指摘は、理由を書いて残す
- 【人】 グループリーダーが内容を確かめ、編集の担当が直した原稿と一覧の残りを見て登録する
4番目と5番目を分けるのは、規則で拾えるものをAIに任せないためです。 数値と単位の間の空白は、文字の並びを見れば決まります。AIに任せると、見落とすことも、直さなくてよいところを直すこともあります。 規則なら、何度流しても同じ結果です。
8番目で研究員が直すのは、原稿を書き換える権限を研究員に残すためです。 一覧は指摘で、原稿は書き換えません。この構成が原稿を直接書き換えると、第3章の(d)を機械が起こします。
02今回想定するシステム構成
技術報告書の原稿(Word、SharePoint の文書ライブラリ) ▼【トリガー】「校正」のフォルダに保存 Power Automate ── ファイルの中身を取り、Functions を呼ぶ ▼ Azure Functions ├──▶ 段落・表のセル・図の説明に分ける/書式を印にする ├──▶ 規則で拾う(数値と単位の空白、°C と % の空白、単位記号の略し方、小数点の前の0) ├──▶ 用字用語の表、単位・記号の決まりを読む ▼ Azure OpenAI(構造化出力、store=false) │ 段落ごとの指摘(元の文字列・直し方・決まりの番号・理由) ▼ Azure Functions ── 元の文字列があるか、数字が変わっていないか ▼ 指摘の一覧(段落の番号付き)── Teams で研究員に知らせる ▼ 【人】研究員が直す ── グループリーダーと編集の担当が登録
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| 生成AI | Azure OpenAI(Microsoft Foundry) | Claude API |
| 連携 | Power Automate(文書ライブラリのトリガー、ファイルの中身の取得、Teams への通知) | Azure Logic Apps |
| 連携 | Azure Functions(文書の分割、書式の印、規則の点検、照合、一覧の作成) | AWS Lambda |
| 決まりの表 | SharePoint のリスト(用字用語の表、単位・記号の決まり、社内の例外) | 共有の表計算のファイル |
| 文書の保管 | SharePoint の文書ライブラリ(原稿・指摘の一覧・登録した版) | 社内のファイルサーバー |
原稿は書き換えません。 一覧を返すだけで、Word のファイルにはこの構成から手を入れません。直すのは研究員で、直した結果を確かめるのは編集の担当です。
決まりの表は、編集の担当が持ちます。 用字用語の表と単位・記号の決まりに、それぞれ番号を振っておきます。指摘には必ずこの番号を付けさせ、番号の無い指摘は出しません(第7章「出力形式」)。
03どうやって実装するのか
処理の起点を決める
起点は、研究員が原稿を「校正」のフォルダに保存したときです。 グループリーダーに出す前に保存してもらいます。内容の確認より先に表記をそろえておけば、グループリーダーは内容だけを見られます。 第3章の(b)の、直す範囲が人によって違う状態を減らせます。
同じ報告書を何度保存しても、そのたびに一覧を作り直します。 直した後にもう一度保存すれば、残った指摘だけが一覧に出ます。ファイル名に研究テーマの番号と月を入れる決まりにし、前の回の一覧と比べて、消えた指摘と残った指摘を分けて出します。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 原稿 | 段落、表のセル、図の説明、それぞれの書式(斜体・上付き・下付き) | SharePoint の文書ライブラリ |
| 用字用語の表 | 番号、使わない書き方、使う書き方、例外(約400語) | SharePoint のリスト |
| 単位・記号の決まり | 番号、決まりの文、正しい例、誤りの例、社内の例外 | SharePoint のリスト |
| 前の回の一覧 | 同じ報告書の、前に保存したときの指摘 | SharePoint の文書ライブラリ |
質を決めるのは、単位・記号の決まりの「誤りの例」の列です。 決まりの文だけでは、AIはどこまでを誤りとするかを広く取ります。「25℃」「5wt%」「10sec」のような誤りの例と、「25 °C」「質量分率 5 %」「10 s」のような正しい例を並べておくと、指摘の範囲がそろいます。
社内の決まりは、国際単位系の書き方を土台にしています。 国際度量衡局(BIPM)の SI 文書(第9版、2026年6月の V4.01)は、たとえば次のことを定めています。
| 決まり | SI 文書の書き方 |
|---|---|
| 数値と単位の間 | 数値は単位の前に置き、必ず空白で分ける。例外は平面角の °、′、″ だけ |
| °C | 数値との間に空白を入れる(30.2 °C であり、30.2°C や 30.2° C ではない) |
| % | 数値との間に空白を入れる。「質量パーセント」のような書き方はせず、量の側で示す |
| 単位記号 | 立体で書く。略語ではないので、文の終わり以外でピリオドを付けず、複数形にしない |
| 略し方 | sec、sq. mm、cc、mps のような略し方は許されない |
| 接頭語 | 単位記号に空白なしで付け、単独で使わず、重ねて使わない |
| 量の記号 | 一般に斜体の1文字。情報は単位でなく量の記号の側に付ける(Umax = 1000 V であり、U = 1000 Vmax ではない) |
| 小数 | 1と−1の間の数は、小数点の前に必ず0を書く(−0.234 であり、−.234 ではない) |
| ppb、ppt | 言語によって意味が違うので避ける |
社内の例外は、この表と別の列に書きます。 「装置の仕様の引用に限り rpm を認める」のような例外を、SI の決まりと同じ列に混ぜると、AIは例外を一般の決まりとして扱います。
データの取得方法を決める
| 取るもの | どこから | どう取るか |
|---|---|---|
| 原稿のファイル | 文書ライブラリ | Power Automate のトリガーとファイルの中身の取得 |
| 段落・表のセル・図の説明と書式 | 原稿 | Functions で Word の文書を読み、文字ごとの書式を見る |
| 決まりの表 | SharePoint のリスト | 起動時に読み、更新日が変わったら読み直す |
| 前の回の一覧 | 文書ライブラリ | 研究テーマの番号と月で探す |
書式は、文字の印にしてから渡します。 生成AIに渡すのは文字だけなので、斜体・上付き・下付きは文字にしないと消えます。 斜体は <i>…</i>、上付きは <sup>…</sup>、下付きは <sub>…</sub> で囲みます。「m2」と「m<sup>2</sup>」が区別でき、量の記号が斜体かどうかを AI が判断できるようになります。 第3章の(c)は、この印が無いと拾えません。
段落には番号を振ります。 本文の段落は P-012、表のセルは T3-R2-C4(3つ目の表の2行目4列目)、図の説明は F5 のように振り、指摘の一覧はこの番号で返します。 研究員は番号で原稿の場所を探します。
AIへ渡す前に整形する
- 段落に分ける … 本文・表のセル・図の説明に分け、番号を振ります
- 書式を印にする … 斜体・上付き・下付きを
<i>・<sup>・<sub>で囲みます - 規則で拾う … 数値の直後に単位記号が空白なしで続くもの、「℃」の1文字、数値と % の間に空白が無いもの、「sec」「cc」「ppb」、小数点で始まる数を拾います。拾ったものは規則の指摘として一覧に入れ、AIには渡しません
- 社内の例外を当てる … 装置の仕様の引用の段落(「仕様:」で始まる段落など)では、rpm の規則を外します
- 段落をまとめる … 1回の呼び出しに渡す段落は、前後の段落を含めて2,000文字ほどにします
3番目の規則は、たとえば次のように書きます。
| 決まりの番号 | 拾うもの | 直し方の示し方 |
|---|---|---|
| U-01 | 数字の直後に、空白なしで単位記号の一覧(mm、kg、Pa、V、s など)が続く | 数字と単位の間に空白を入れる |
| U-02 | 「℃」の1文字、または数字と「°C」の間に空白が無い | 「 °C」にする |
| U-03 | 数字と「%」の間に空白が無い | 「 %」にする |
| U-04 | 「wt%」「vol%」「mol%」 | 量の側で示す(「質量分率」など)。直し方の文は執筆者が決める |
| U-05 | 「sec」「cc」「ppb」「ppt」 | 「s」「cm³」に。ppb・ppt は値の表し方を執筆者に確かめる |
| U-06 | 「.」で始まる数(「.5」) | 小数点の前に0を書く |
U-04 と U-05 の一部で直し方を決めないのは、値の表し方そのものが変わるからです。 「5wt%」を何に書き換えるかは、量の名前の付け方を決める執筆者の仕事です。一覧には「量の側で示す」という決まりだけを出します。
3番目で拾ったものをAIに渡さないのは、二重の指摘を避けるためです。 規則で拾った「25℃」をAIにも渡すと、AIも同じ指摘を書き、一覧に同じ箇所が2回出ます。規則で拾った箇所は、AIに渡す文字の中で印を付けて「指摘済み」とします。
「℃」の1文字を規則で拾うのは、SI 文書が °C を「°」と「C」の組み合わせとして書いているからです。 社内の決まりで「°C」の2文字で書くと決めていれば、1文字の「℃」は規則で直せます。どちらに寄せるかは、社内の決まりで先に決めます。
AIに処理させる
させるのは、規則で拾えない表記と単位・記号の書き方を、決まりの番号付きで指摘することだけです。
| させること | させないこと |
|---|---|
| 量の記号が斜体でないところを指摘する | 数値を変える直し方を示すこと(桁・小数点・有効数字) |
| 用字用語の表で、文脈で決まる言い換えを指摘する | 実験の方法や結果、考察の中身に意見を書くこと |
| 単位に情報を付けた書き方(Vmax、wt%)を指摘する | 文の言い回しを、決まりと関係なく直すこと |
| 同じ量に違う記号を使っているところを指摘する | 決まりの表に無い決まりで指摘すること |
| 指摘ごとに、元の文字列・直し方・決まりの番号・理由を返す | 規則で指摘済みの箇所を、もう一度指摘すること |
数値を変える直し方を示させないのが、この構成でいちばん大事な線です。 「1.50」は有効数字3桁で、「1.5」とは意味が違います。表記の校正で値に触れてはいけません。 有効数字や計算が正しいかは、別の確認(UC-0415 の数値の突き合わせなど)で見ます。
中身に意見を書かせないのも外せません。 校正の一覧に「この考察は根拠が弱い」と出ると、研究員は表記の指摘まで読まなくなります。内容はグループリーダーの仕事で、この一覧には入れません。
指示内容を固定する
あなたは研究開発本部の報告書の編集の担当で、表記と単位・記号の書き方を校正する立場です。
【段落】を、【用字用語の表】と【単位・記号の決まり】だけに照らして校正してください。
【段落の書き方】
- 各段落の先頭に番号(P-012、T3-R2-C4 など)があります。
- <i>…</i> は斜体、<sup>…</sup> は上付き、<sub>…</sub> は下付きです。
- 【指摘済み】の印のある箇所は、すでに指摘しています。指摘しないでください。
【指摘の書き方】
- 1つの指摘ごとに、段落の番号、元の文字列(段落の中の文字をそのまま)、
直し方、決まりの番号、理由を書いてください。
- 元の文字列は、段落の中に同じ文字の並びでそのまま現れるものにしてください。
【厳守事項】
- 数字を変える直し方を示さないでください。桁・小数点・末尾の0・有効数字を
変えないでください。数字の間の空白の入れ方も変えないでください。
- 決まりの表に無い決まりで指摘しないでください。決まりの番号が書けない指摘は
出さないでください。
- 実験の方法・結果・考察の中身について書かないでください。
- 文の言い回しを、決まりと関係なく直さないでください。
- 社内の例外の欄にある扱いは、誤りとして指摘しないでください。
- 迷う箇所は指摘にせず、uncertain に段落の番号と文字列を書いてください。
【用字用語の表】{terms}
【単位・記号の決まり】{unit_rules}
【段落】{paragraphs}
「元の文字列は段落の中にそのまま現れるものに」は、照合のための指示です。 AIは元の文字列を少し整えて書くことがあります。整えた文字列は原稿の中で見つからず、研究員が場所を探せません。 そのまま写させて、後で Functions が段落の中を探します。
「迷う箇所は uncertain に」を書かないと、AIは迷った箇所も指摘にします。 量の記号か、試料の名前の略号かが分からない「C」を、斜体にせよと指摘します。迷った箇所は編集の担当が見る欄に分けます。
出力形式を固定する
構造化出力で、次の形で受け取ります。
{
"report_id": "",
"findings": [
{ "para_id": "P-012",
"original": "Vmax = 4.2 V",
"suggestion": "<i>U</i><sub>max</sub> = 4.2 V",
"rule_id": "U-07",
"reason": "量の記号の側に情報を付ける。量の記号は斜体" } ],
"uncertain": [ { "para_id": "", "text": "" } ]
}
Microsoft の公式ページでは、構造化出力はすべての項目を必須にし、オブジェクトに常に additionalProperties: false を付けるとされ、文字列の pattern・format、配列の minItems・maxItems は使えないとされています。rule_id が決まりの表にある番号かは、enum に番号の一覧を入れて縛ります。 決まりの表が更新されたら、スキーマの enum も作り直します。
照合は次の順で行います。
| 確かめること | 合わないときの扱い |
|---|---|
original が para_id の段落にそのままある | 外して、編集の担当の欄へ |
original と suggestion から取り出した数字の並びが同じ | 外す(一覧に出さない) |
rule_id が決まりの表にある | 外す |
| 規則で指摘済みの箇所と重なる | 外す |
rule_id が社内の例外の対象で、段落が例外の条件に合う | 外す |
1つ目の理由は、数字の並びで値が変わっていないかを見られることです。 上の例では、original の数字は「4.2」、suggestion の数字も「4.2」で同じです。「1.50 g」を「1.5 g」とする指摘は、数字の並びが「1.50」と「1.5」で違うので外れます。 書式の印(<i> など)は、数字を取り出す前に除きます。
研究員に返す一覧は、規則の指摘とAIの指摘を段落の番号の順に並べた次の形です。
| 段落 | 元の文字列 | 直し方 | 決まり | 出どころ |
|---|---|---|---|---|
| P-004 | 25℃で24時間保持 | 25 °C で24時間保持 | U-02 | 規則 |
| P-012 | Vmax = 4.2 V | <i>U</i><sub>max</sub> = 4.2 V | U-07 | AI |
| P-015 | サンプルを乾燥 | 試料を乾燥 | Y-118 | AI |
| T3-R1-C2 | 圧力(kPa) | <i>p</i>/kPa | U-11 | AI |
表の見出しの「<i>p</i>/kPa」は、SI 文書の書き方に合わせた社内の決まり(U-11)です。 SI 文書は、量を単位で割った形(p/kPa)を表の列の見出しに使うと、表の中が数だけになるとしています。図の軸も同じ書き方です。
2つ目は、rule_id で研究員が決まりを引けることです。 一覧の決まりの番号から、決まりの文と正しい例・誤りの例を開けるようにします。同じ番号の指摘が毎月出る研究員には、その決まりだけを先に読んでもらえます。 第3章の(a)の、同じ指摘の繰り返しを減らす手がかりになります。
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| SharePoint の文書ライブラリ | Power Automate のトリガーと中身の取得 | 原稿の受け取り、一覧の保存 |
| Azure Functions | Power Automate から呼ぶ | 分割・書式の印・規則・照合・一覧 |
| SharePoint のリスト | 読み取り | 用字用語の表、単位・記号の決まり、社内の例外 |
| Azure OpenAI | Responses API(store=false) | 段落ごとの指摘 |
| Microsoft Teams | 研究員への通知 | 一覧の場所と、指摘の数 |
応答は Azure OpenAI の側に残しません。 公式ページでは、Responses API の応答は既定で30日保持されるとされているので、store=false にします。原稿と一覧は文書ライブラリに残します。
人が確認する
- 研究員が一覧を見て直す … 規則の指摘とAIの指摘を、段落の番号の順に見て原稿を直します
- 直さない指摘に理由を書く … 決まりに合わないと思う指摘は、一覧の欄に理由を書きます
- 編集の担当が
uncertainと理由の欄を見る … 迷った箇所と、研究員が直さなかった指摘を判断します - 編集の担当が、外した指摘を月に1回見る … 数字が変わるとして外した指摘が、本当に値を変えるものだったかを確かめます
4番目を省かないでください。 外した指摘の中に、「0.5」を「0.50」とする指摘のような、有効数字をそろえる意図の指摘が混ざることがあります。それは表記の校正の範囲を超えるので外して正しいのですが、同じ種類の指摘が多ければ、研究員の数値の書き方そのものを確かめる材料になります。
例外に対処する
| 起きること | 対応 |
|---|---|
| 原稿が Word でない(PDF、画像) | 校正せずに研究員へ戻す |
| 表が画像で貼られている | 表の中は校正せず、一覧に「画像の表は対象外」と出す |
| 数式が数式の機能で書かれている | 数式の中は校正しない。数式の前後の文だけを見る |
| 安全方針で入力が止まる | その段落だけ外し、一覧に「自動の校正の対象外」と出す |
| 指摘が1つの段落に20を超える | その段落を編集の担当の欄に回す |
| 決まりの表が更新された | スキーマの enum を作り直し、更新日を一覧に書く |
| 構造化出力が返らない | 規則の指摘だけで一覧を作り、AIの指摘は「未実施」と出す |
4行目の安全方針は、研究の報告書でも起きえます。 Microsoft の公式ページでは、既定の安全方針(DefaultV2)は入力と出力の両方で重大度「中」以上をブロックするとされています。爆発・燃焼の試験や、毒性の評価の報告書では、文の中身によって止まることがあります。 止まった段落は、編集の担当が読みます。
記録を残す
- 原稿の版と、段落の番号の対応
- 規則の指摘と、AIの指摘(
findings・uncertain) - 照合で外した指摘と、外した理由(数字の違い・元の文字列が無いなど)
- 研究員が直さなかった指摘と、書かれた理由
- 編集の担当の判断と、登録した版
- 使った決まりの表の更新日
最後の行は、決まりを変えたときのためです。 決まりを変えると、過去の報告書の書き方と食い違います。どの版の決まりで校正した報告書かが残っていれば、古い報告書を直すかどうかを決められます。
04実装レベルの3段階
最小構成では書式が見えません。 画面に貼ると斜体や上付きが消えるので、量の記号と指数の指摘は出せません。 確かめるための段階です。 半自動化で、1本45分が30分程度になります。 数値と単位の空白や略し方は規則で拾えますが、量の記号と用語の言い換えは編集の担当が読んで探す時間が残ります。 本格構成で18分になり、この段階が本記事の想定です。差が大きいのは、書式の印があって、文字だけでは見えない誤りまで一覧に出るからです。 段階を飛ばさないでください。 半自動化を1か月使うと、規則の指摘のうち研究員が直さなかったものから、決まりの書き方と社内の例外の足りないところが分かります。
05工数削減シミュレーション
導入後 80件 × 18分 ÷ 60 = 24 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 研究テーマが数十あり、テーマごとの技術報告書が毎月数十本出る製造業の研究開発部門。報告書を社内の技術の資産として残していて、表記と単位の書き方の決まりがあるのに、校正がグループリーダーや編集の担当の目に頼っている場合。報告書が Word で書かれ、社外の共同研究先や知財の部署にも回る場合。研究の情報を外部のサービスに渡す条件を、情報システムの部署と決められる場合。
- 報告書が月に数本で、1人の編集の担当が全部を読める場合。表記と単位の書き方の決まりが社内に無く、まず決まりを作るところから始める場合(先に決まりを作ります)。報告書が手書きの実験ノートの写しや、画像だけの資料の場合。なお、実験の結果が正しいか、数値の有効数字や計算が合っているか、結論が妥当かの判断は、この構成では代替できません。表記と単位・記号の書き方を決まりに照らして指摘するまでです。
07最小構成で試す方法
- 先月の報告書から5本を選ぶ(うち2本は、編集の担当のコメントが多かったものを入れる)
- その5本に付いた編集の担当のコメントを、決まりの番号ごとに数える
- 手元のAIサービスの画面に、単位・記号の決まりと用字用語の表、報告書の数段落を貼り、「決まりの番号付きで指摘する。数字を変えない。決まりに無いことで指摘しない」と指示する
- 出てきた指摘を、編集の担当のコメントと突き合わせる
- 数字を変える直し方が出ていないか、内容に意見を書いていないかを見る
5本は必ずやってください。 仕組みを作る前に、「決まりの表を渡せば、編集の担当と同じ指摘が出るのか」を確かめます。
| 出てきた内容 | 判断 |
|---|---|
| 編集の担当と同じ指摘が、決まりの番号付きで出た | 規則の点検と照合の作り込みに進む |
| 数字を変える直し方や、内容への意見が出た | 指示の書き方で直る。構成は有効 |
| 指摘の範囲が編集の担当と大きく違う | 決まりの表に誤りの例が足りない。 AIの問題ではない |
3行目が出ることは珍しくありません。 決まりの文だけでは、どこまでを誤りとするかが伝わりません。編集の担当のコメントから誤りの例を集めて表に足し、同じ5本で試してください。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 斜体や上付きの誤りが拾えない | 書式を <i>・<sup>・<sub> の印にして渡す |
| 「1.50」を「1.5」とする指摘が出る | 指摘の前後で数字の並びを比べ、違えば外す |
| 規則で拾った箇所をAIも指摘する | 規則の指摘済みの印を付けて渡す |
| 元の文字列が原稿に見つからない | 段落の中の文字をそのまま写させ、見つからなければ外す |
| 社内の例外(rpm)が誤りとして出る | 例外を別の列に書き、例外の条件の段落では規則を外す |
| 決まりに無いことで指摘が出る | 決まりの番号を enum で縛り、番号の無い指摘は出さない |
| 内容に意見が書かれる | 中身について書かないと指示し、理由の欄を短くする |
| 試料の略号を量の記号と取り違える | 迷う箇所は uncertain に分ける |
| 「℃」と「°C」のどちらに寄せるか決まらない | 社内の決まりで先に決める |
| 表の画像や数式の中が見えない | 対象外と一覧に出す |
| 安全方針で段落が止まる | その段落だけ外して、編集の担当が読む |
| 応答が30日残る | store=false にする |
上の2行が、この構成の失敗のほとんどです。 どちらも「文字として見れば正しく見える」ところから出ています。書式を印にして渡しているか、数字の並びを比べているかで、校正が値を守れるかが決まります。
下の2行も、早いうちに効いてきます。 表の画像や数式の中が対象外だと一覧に出ていないと、研究員は全部校正されたと思います。安全方針で止まった段落も、止まったことが見えないと、校正されないまま登録されます。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 技術報告書の原稿です。未発表の研究の結果、未出願の発明、共同研究先との取り決めのある情報が含まれます。
- 外部のサービスに渡す条件を先に決める … 研究の情報を Azure OpenAI に渡してよいかを、情報システムの部署と知財の部署と決めます。共同研究の報告書は、相手との取り決めで外部のサービスに渡せないことがあります。 その報告書は「校正」のフォルダに入れない運用にします
- 処理の場所を決める … 公式ページでは、プロンプトと応答は Global か DataZone の展開を除いて、指定した地域の中で処理されるとされています。標準の展開で日本の地域を選びます
- 不正使用の監視の扱いを確かめる … 公式ページでは、不正使用の兆候があるとプロンプトと応答の一部が自動と人によるレビューの対象になりうること、管理された顧客は監視の変更を申請できることが書かれています。研究の機密の程度に応じて、申請を検討します
- 応答を残さない …
store=falseにし、原稿と一覧は自社の文書ライブラリにだけ残します - 原稿を書き換えない … 一覧を返すだけにし、値を変える経路を作りません
- 内容の判断をさせない … 実験の結果や考察が正しいかは、グループリーダーが確かめます
誤りが起きた場合のリスクは、校正の指摘で値が変わることと、機密の情報が取り決めの外に出ることの2つです。 前者は数字の照合と原稿を書き換えない設計で、後者は渡す報告書を決める運用で防ぎます。どちらもAIの出来ではなく、仕組みの側で守ります。
10まず何から始めるか
1週目:決まりの表に誤りの例を足す
単位・記号の決まりの20項目に、誤りの例と正しい例の列を足し、番号を振ります。 先月の報告書の編集の担当のコメントから、誤りの例を集めます。社内の例外は別の列に書きます。
2週目:5本で試す
先月の報告書から5本を選び、手元のAIサービスに決まりと段落を貼って指摘させます。編集の担当のコメントと同じ指摘が出るか、数字を変える直し方が出ていないかを最優先で見ます。
3週目:規則で拾う決まりを決める
決まりのうち、文字の並びで決まるもの(数値と単位の空白、°C と % の空白、略し方、小数点の前の0など)を選び、規則にします。 あわせて、共同研究の報告書を外部のサービスに渡してよいかを、知財の部署と決めます。
4週目:保存から規則の一覧までをつなぐ
Power Automate と Functions をつなぎ、原稿を保存すると規則の指摘の一覧が出るところまで作ります。この時点ではAIを呼ばず、規則の指摘だけを研究員に返します。
2か月目: 書式の印とAIの指摘、元の文字列と数字の照合を足します。3か月目以降: 前の回との比較を足し、1本45分が何分になったかを実測します。同じ決まりの番号の指摘が毎月減り、締めの前の1週間に報告書が詰まらなくなった時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
| SI 文書(第9版、2026年6月の V4.01)で、数値は単位の前に置き必ず空白で分けること(例外は平面角の °、′、″)。°C も数値との間に空白を入れること。% も数値との間に空白を入れ、「質量パーセント」のような書き方をしないこと。単位記号は立体で、ピリオドを付けず複数形にしないこと。sec・sq. mm・cc・mps のような略し方が許されないこと。接頭語を単独で使わず重ねないこと。量の記号が一般に斜体で、情報を単位でなく量の記号の側に付けること。1と−1の間の数は小数点の前に0を書くこと。ppb と ppt を避けること。量を単位で割った形(p/kPa)を表の列の見出しと図の軸に使えること | BIPM: The International System of Units (SI) 9th edition, V4.01 | 2026-10-29 |
構造化出力ですべての項目を必須にし、オブジェクトに additionalProperties: false を付けること。文字列の pattern・format、配列の minItems・maxItems が使えないこと。enum が使えること | Microsoft Learn: 構造化された出力 | 2026-10-29 |
| プロンプトと応答が Global か DataZone の展開を除いて指定した地域の中で処理されること。不正使用の兆候があると、プロンプトと応答の一部が自動と人によるレビューの対象になりうること。管理された顧客が監視の変更を申請できること | Microsoft Learn: Data, privacy, and security for Models sold by Azure | 2026-10-29 |
Responses API の応答が既定で30日保持され、store=false で状態を持たない呼び出しにできること | Microsoft Learn: Azure OpenAI Responses API | 2026-10-29 |
| 既定の安全方針(DefaultV2)が入力と出力の両方で重大度「中」以上をブロックすること | Microsoft Learn: Default Guardrail policies for Microsoft Foundry | 2026-10-29 |
社内の表記と単位・記号の決まりは、自社の研究開発本部と品質保証の部署で決めてください。 本記事は BIPM の SI 文書と公開されている製品のドキュメントで確認できた範囲だけを扱っています。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-2257)についてのご相談はこちらから。
