劇場・ホールが公演の当日のプログラムの原稿を Azure OpenAI で校正し、出演者・曲目・時間を公演の資料と突き合わせて食い違いを拾う

処理の起点を決める

「校正」のフォルダにファイルが作られたときに動かします。 SharePoint のコネクタの「ファイルが作成されたとき（プロパティのみ）」で受け、「ファイル コンテンツの取得」で中身を取ります。「フォルダーにファイルが作成されたとき」は非推奨で、サブフォルダでは動かないため使いません。公演ごとのフォルダの下に「校正」を置く形なので、ライブラリ全体で受けてパスで絞ります。

ファイルの列には「公演の番号」と「初校・再校の別」を持たせます。 公演の番号が空なら、処理の最初で止めて知らせます。再校のときは、初校の指摘の一覧を引いて、直ったかを並べて出します。

公演の資料が更新されたときにも、もう一度動かします。 曲目の差し替えや出演者の交代で名簿・曲目の一覧が直ったら、最後に校正した原稿を新しい資料で突き合わせ直します。 変更が原稿に届かない（c）の失敗を、ここで止めます。

入力データを集める

質を決めるのは、名簿の氏名が「指定の字体」で入っているかです。 名簿を表計算のファイルに打ち込むときに、「髙」を「高」に、「﨑」を「崎」にしてしまうと、突き合わせの正がすでに誤っています。 名簿の氏名は、マネジメントから届いたプロフィールの文字を貼り付けて作り、確認の日付の列を持たせます。

曲目の一覧には、確定の状態を持たせます。 「確定」「仮」の列を設け、仮の曲目と突き合わせて出た指摘は、区別して出します。 アンコールの曲は当日まで決まらないことが多いので、一覧に載せず、原稿にアンコールの曲名が書かれていたら「事前に掲載してよいか」を確かめる指摘にします。

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

Word の原稿は、Functions で段落と表に分けます。 段落には P-031、表のセルには T1-R4-C2 のような番号を付けます。校正刷りの PDF は、文字の層から文字を取り出し、ページ番号を付けます。 文字の層が無い PDF は、取り出せないことを一覧に出します。

公演の資料は、公演の番号で引きます。 名簿・曲目の一覧・タイムテーブルは、ひな形の列名で値を取り、人の番号・曲の番号・区切りの番号 を付けます。

AIへ渡す前に整形する

1. 段落と表に番号を付ける … 見出し、本文、表のセル、キャプションを分けます
2. 氏名の文字そのものを探す … 名簿の氏名を原稿の中から文字そのままで探し、見つかったかを記録します
3. 字体の違いを見つける … 名簿の氏名と、読みが同じで字体だけが違う並び（髙／高、﨑／崎、邊／辺）を原稿の中から探します
4. 異体字セレクタを確かめる … 名簿の氏名に異体字セレクタ（見た目の字体を指定する付加の文字）が付いていれば、原稿の側にも同じ符号があるかを確かめます
5. 時刻を計算する … 開演の時刻に前半の長さと休憩の長さを足し、原稿の「休憩」「終演予定」の時刻と比べます
6. 表記の決まりで調べる … 時刻の書き方、カタカナの表記、作品番号の書き方（Op. の後の空白など）を拾います
7. クレジットを比べる … 指定の表記を、原稿の中から文字そのままで探します
8. 欧文の符号を確かめる … 欧文の表記の作曲者名・出演者名で、名簿にある発音区別符号（Dvořák の ř、Saint-Saëns の ë など）が原稿にもあるかを確かめます

8番目は、欧文の表記を載せる公演で効きます。 発音区別符号は、Word からレイアウトのソフトへ移す途中や、フォントに字形が無いときに落ちたり別の字に置き換わったりします。原稿の段階では正しくても、校正刷りで落ちることがあるので、初校と再校の両方で調べます。

2番目から4番目を生成AIにさせないのは、生成AIが字体の違いを「同じ字」として扱いやすいからです。 生成AIは意味で読むので、「髙橋」と「高橋」を同じ人として結び付けるのは得意でも、違いを指摘するのは苦手です。 字体の比較は、文字の符号で行います。

4番目の異体字セレクタは、コピーと貼り付けの途中で落ちることがあります。 名簿では「葛」の字体が指定されていても、原稿に貼る途中で符号が落ちると、画面では同じに見えて、印刷すると違う字体になることがあります。符号の有無はプログラムで見ます。

AIに処理させる

させるのは、原稿の記述の1つずつに、「名簿のどの人か」「曲目の一覧のどの曲か」「タイムテーブルのどの区切りか」を付けることです。

4行目の「書かれた値の写し」が、この構成の要です。 生成AIに原稿の作品番号を写させるとき、知っている正しい番号に直して写すことがあります。そうなると、プログラムの比較では一致してしまい、原稿の誤りが消えます。 写した値は、プログラムが原稿の文字の中にそのまま存在するかを確かめ、無ければ捨てます。

2行目も同じ理由です。 編曲版や改訂版の演奏では、作品番号や曲名の表記が一般に知られた形と違うことがあります。曲目の一覧が正で、生成AIの知識は正ではありません。

指示内容を固定する

あなたは文化ホールの事業課で、公演の当日のプログラムの原稿を
印刷の前に校正する立場です。原稿の記述1つずつについて、
出演者の名簿のどの人、曲目の一覧のどの曲、タイムテーブルのどの
区切りに当たるかを結び付けてください。

【結び付けるもの】
- person_ref：名簿の人の番号（例 A-03）
- piece_ref：曲目の一覧の曲の番号（例 M-02）
- slot_ref：タイムテーブルの区切りの番号（例 S-02）
- written_value：原稿に書かれた作品番号・楽章・肩書・役名・時刻。
  原稿の文字をそのまま写す
- kind：person／piece／time／credit／other

【厳守事項】
- 一致しているか、誤っているかを書かないでください。
- written_value は、原稿に書かれた文字をそのまま写してください。
  あなたが知っている正しい作品番号・曲名・作曲者の表記に
  直さないでください。
- 氏名の字体をそろえないでください。「髙」を「高」に、
  「﨑」を「崎」にして写さないでください。
- 当てはまる人・曲・区切りが無いときに、近いものを選ばないで
  ください。status を no_person／no_piece／no_slot にしてください。
- 曲の解説の内容が正しいかを書かないでください。
- evidence には、結び付けの根拠にした原稿の語句をそのまま写して
  ください。

【出演者の名簿】{performers}
【曲目の一覧】{pieces}
【タイムテーブル】{timetable}
【原稿の記述（番号付き）】{statements}

「知っている正しい作品番号に直さない」を明記しないと、写しが直されます。 生成AIは親切のつもりで直しますが、この構成では、直された写しは誤りを隠すだけです。 指示で禁じ、写しが原稿に存在するかをプログラムで確かめる、の2段で止めます。

「近いものを選ばない」は、曲目の差し替えを見つけるためです。 原稿に古い曲名が残っていると、生成AIは曲目の一覧の中から似た曲を選びたがります。当てはまる曲が無いことこそ、差し替えが原稿に届いていない印です。

出力形式を固定する

{
  "program_id": "P2026-1115-A",
  "proof_round": "first",
  "links": [
    {
      "statement_id": "P-031",
      "text": "シベリウス：ヴァイオリン協奏曲 ニ短調 Op. 74",
      "kind": "piece",
      "person_ref": "",
      "piece_ref": "M-02",
      "slot_ref": "",
      "written_value": "Op. 74",
      "status": "ok",
      "evidence": "ヴァイオリン協奏曲 ニ短調"
    }
  ]
}

JSON にする1つ目の理由は、比較を機械にできることです。 piece_ref が M-02 なら、曲目の一覧の M-02 の作品番号と written_value を比べます。一覧が Op. 47 なら、「作品番号の食い違い」として指摘にします。 written_value が原稿の P-031 の文字の中に無ければ、写しを捨てて人に回します。

2つ目は、番号で原稿の場所に戻れることです。 指摘には statement_id と校正刷りのページ番号が付き、赤字をそのまま書けます。

スキーマは、Azure OpenAI の決まりに合わせます。 すべての項目を必須にし、すべてのオブジェクトに additionalProperties: false を付けます。pattern や format は使えないので、番号の形はプログラムで確かめます。

指摘の一覧は、次の形で事業担当に渡します。

システムへ連携する

原稿と校正刷りには書き込みません。 PDF に赤字を自動で入れることもしません。赤字を作るのは事業担当で、デザイン会社に返すのも人です。 誤った指摘が赤字になってデザイン会社に届くと、正しかった箇所が直されます。

公演の資料にも書き込みません。 名簿の誤りが疑われるときは、マネジメントに確かめるのは担当者です。

人が確認する

1. 氏名の字体と肩書を先に見る … 名簿と原稿のどちらが正しいかを、名簿の確認の日付で確かめます。名簿が古ければ、マネジメントに確かめ直します
2. 曲目と「曲が見つからない」を見る … 差し替えが原稿に届いていないのか、名簿や一覧の側が古いのかを確かめます
3. 時刻を見る … 舞台の担当の最新のタイムテーブルと並べます
4. クレジットと表記をまとめて直す … 機械の指摘なので、まとめて赤字にします
5. 採らなかった指摘を記録する … どの指摘を、なぜ採らなかったかを残します

1番目を先に置くのは、出演者に直接届く誤りだからです。 氏名の字体の誤りは、刷り上がった後では差し込みの紙でしか直せず、出演者と観客の両方の目に触れます。

演劇の配役の表は、行ごとに役名と俳優名の組を見ます。 プログラムは組ごとに名簿と比べるので、1行ずれていれば全部の行が指摘に出ます。 指摘が並んだら、まず行のずれを疑ってください。

目標は、1件25分で一覧を見終えることです。 再校では初校の指摘が直ったかを並べて見るので、新しく出た指摘だけを確かめれば済み、初校より短く終わります。

例外に対処する

6行目は、作品の中の出来事であっても起きえます。 既定の安全方針は、暴力・自傷などの区分を重大度で判定し、「中」以上を入力でも出力でも止めます。 公式のページは、架空の文脈の描写を低い重大度の例に挙げていますが、分類には誤検知がありうるともしています。あらすじの段落が止まっても、ほかの段落の校正は続けます。

記録を残す

• 原稿・校正刷りの版ごとのファイルと、取り出した段落と表
• そのとき使った名簿・曲目の一覧・タイムテーブルの版（確認の日付）
• 規則の検査（字体・時刻・表記）の結果
• 生成AIの入力と出力の全文
• 照合の結果（指摘の一覧）
• 事業担当が採った指摘と、採らなかった指摘と理由
• 刷り上がった後に見つかった誤りと、そのとき一覧に出ていたか

最後の行が、この構成を育てる材料になります。 刷り上がった後に見つかった誤りが一覧に出ていなかったなら、規則か資料の形のどこかに穴があります。

生成AIの入出力は、事業課の側に残します。 Responses API を使う場合は、サービスの側に保存させない設定にし、記録は公演のフォルダの側だけに置きます。