校正AIプロジェクト キャッチアップブリーフ

対象:慶應研究室×出版社 共同の校正AIプロジェクト(PM兼開発)着任前の予習 / 想定読了時間:2時間 / 作成:2026-07-04(改訂版) / 特徴:専門用語はすべて初出時に説明し、各概念に具体例を付けた

第1部 LLMの基礎知識35分

1-1. LLMは何をしているか:「続きを予測する」だけの機械

ChatGPTやClaudeのようなLLM(大規模言語モデル)の中身は、驚くほど単純な一つの機能でできている。「ここまでの文章の続きとして、次に来る言葉は何か?」を確率で予測する。これだけだ。

「予測しているだけ」という一点から、実務で重要な性質が3つ導ける。

性質① 出力は確率的で、揺れる。同じ質問でも毎回微妙に違う答えが返りうる。サイコロを振っているのに近い(振り方を固くする設定は後述)。校正のように「同じ原稿には同じ指摘」が求められる用途では、この揺れをどう抑えるかが設計課題になる。

性質② ハルシネーション(もっともらしい嘘)は故障ではなく、仕組み上の必然。モデルは「正しいこと」を出そうとしているのではなく「続きとして自然なこと」を出している。知らないことを聞かれても、自然な続きは作れてしまう。

性質③ 「数える・照合する」が苦手。LLMは計算機ではなくパターン補完機なので、機械的な正確さが要る作業を平気で間違える。

最後に、LLMの内部構造について一つだけ。中身はTransformer(トランスフォーマー)という仕組みで、その心臓部がattention(注意機構)。乱暴に言えば「文中のすべての語のペアについて、どれとどれが関係しているかを計算し、文脈全体を踏まえて次の語を決める仕組み」だ。

1-2. トークンとコンテキストウィンドウ:LLMの「読み方」と「作業机の広さ」

LLMは文章を1文字ずつではなく、トークンという単位で読み書きする。トークンは「よく出る文字のかたまり」で、単語より少し細かい。

コンテキストウィンドウは、モデルが一度に扱える(読める+書ける)トークン数の上限。モデルの「作業机の広さ」だと思えばいい。机に載らない資料は読めないし、載せた資料の分だけ料金がかかる。2026年時点の主要モデルは20万〜100万トークン級まであり、「本1冊が机に載る」時代にはなった。ただし丸ごと載せることには罠が2つある。

• 長い入力の真ん中は注意が薄くなる(「lost in the middle」と呼ばれる既知の現象)。10万トークン渡して「誤字を全部指摘して」と頼むと、序盤と終盤は拾うのに中盤の見逃しが増える。人間が分厚い資料の真ん中を流し読みしてしまうのに似ている。
• 入力量に比例して課金される。全文を何度も投げる設計は無駄に高くつく。

結論として、実務では長文を数千字の「チャンク」(かたまり)に分割して処理するのが基本になる(3-4で設計論をやる)。

1-3. モデルはどう作られるか:3段階の学習と、その副作用

会話できるLLMは3段階で作られる。人材育成にたとえると分かりやすい。

1. 事前学習:ウェブ・書籍などの膨大なテキストで「続きの予測」をひたすら訓練する。たとえるなら、図書館の本を全部読ませて言葉と世界知識を叩き込む段階。数百億円かかるのはここで、これをやれる会社は世界に数社しかない。
2. SFT(教師あり微調整):「質問→模範回答」のペアを見せて、指示に従う振る舞いを教える。新人研修で接客マニュアルを覚えさせる段階。
3. RLHF(人間のフィードバックによる強化学習):複数の回答に人間が優劣をつけたデータで「好まれる答え方」に寄せる。顧客アンケートで応対を矯正する段階。

実務への含意は2つ。

① モデルには知識カットオフ(学習データの締め日)があり、それ以降の出来事・新語・新刊は知らない。

② RLHFの副作用で、モデルは「親切な書き換え」をしたがる。「読みやすくしてあげよう」という方向に訓練されているので、校正だけ頼んでも文体まで直してくる。この「過剰修正」癖が校正AI最大の地雷になる(3-3で正面から扱う)。

1-4. APIの基本設定:校正ではtemperature=0

LLMをプログラムから使うときはAPI(プログラム用の窓口)を呼ぶ。1回の呼び出しは「設定+指示文を送る→出力が返る」という単純なやりとりで、主要な設定は3つだけ覚えればいい。

1-5. プロンプトの書き方:魔法ではなく仕様書

「プロンプトエンジニアリング」と大層な名前がついているが、実態は優秀だが初日のアルバイトに渡す作業指示書を書く技術だ。効くパターンは実質5つに集約される。

1. 役割と文脈を与える:「あなたは出版社の校閲者です。対象は一般向けビジネス書で、読者は社会人です」。前提を与えるほど判断がブレなくなる。指示なしだと、小説の会話文の「ら抜き言葉」(わざとかもしれない)まで直そうとする。
2. few-shot(実例を見せる):望ましい入出力の例を2〜5個プロンプトに含める。言葉で説明するより例を見せる方が、粒度が正確に伝わる。
3. 「やらないこと」を明記する:やることのリストより効く。「文体の好み・言い回しの改善には踏み込まない。明白な誤りのみ指摘する」。
4. 工程を分ける:「①まず固有名詞を全部リストアップ→②本文と照合」のように分解する。1回の呼び出しに全部やらせるより、単機能の呼び出しを直列につなぐ方が精度も検証のしやすさも上がる。
5. 出力形式を固定する:自由な文章で返させない(次項)。

## 指摘する例
原文: 「シュミレーションの結果を検証した」
指摘: 「シュミレーション」→「シミュレーション」(誤表記)

## 指摘しない例
原文: 「結果はまあまあだった」
理由: 口語的だが誤りではない。文体には踏み込まない

1-6. 構造化出力とツール呼び出し:開発者として最重要のAPI機能

構造化出力(JSONモード):出力を、あらかじめ指定した型(スキーマ)どおりのJSON(プログラムで扱いやすいデータ形式)に強制する機能。主要なAPIは「指定した型に100%従った出力」を保証するモードを持っている。

ツール呼び出し(tool use / function calling):モデルに「使っていい関数の一覧」を渡しておくと、モデルが「この関数をこの引数で実行してほしい」と返してくる仕組み。実行するのはこちらのコードで、結果をモデルに返すと続きを考える。LLMが苦手な正確な処理(数える・検索する・照合する)を外部に逃がすための仕組みだと理解すればいい。

エージェントとは、このツール呼び出しをループさせて(呼ぶ→結果を見る→次を決める)、多段のタスクを自律的に進めさせる構成のこと。君が日常使っているcodexやClaude Codeがまさにこれ。MCP(Model Context Protocol)は、ツール群をモデルにつなぐ配線の標準規格で、2025年以降のデファクト。

1-7. RAGとembeddings:モデルに「資料を持ち込ませる」技術

embeddings(埋め込み):テキストを「意味を反映した数値の座標」に変換する技術。意味が近い文章は座標も近くなる。

RAG(Retrieval-Augmented Generation:検索拡張生成):質問に関連する文書をまず検索で取ってきて、それをプロンプトに同梱してから答えさせる構成。モデル自体を再学習させずに、手元の資料を「読ませて」答えさせられる。

1-8. ファインチューニング:モデル自体を追加訓練する(たぶん最初は不要)

ファインチューニング(FT)は、既存モデルに自前のデータで追加学習させ、振る舞いを恒久的に変えること。プロンプトが「指示書を渡す」なら、FTは「研修を受けさせる」。LoRAという低コストな方式(モデル全体ではなく小さな追加部品だけ学習する)が主流。

1-9. reasoningモデル:「考えてから答える」モデル

2024年末以降、回答の前に内部で長い下書き(思考)を書いてから答えるreasoningモデルが主流化した。即答させると間違える複雑な問題(論理・数学・長い推論の連鎖)に強い。

1-10. モデル地図とコスト感(2026年前半時点・要最新確認)

• クローズドAPI勢:OpenAI(GPT系)、Anthropic(Claude系)、Google(Gemini系)。品質の最上位はこの3社。いずれも高性能・高価格から軽量・低価格まで数段階のラインナップを持ち、日本語品質はどれも実用域。
• オープンモデル勢:Llama、Qwen、DeepSeek等。モデルのデータ自体が公開されており、自前のサーバーで動かせる=原稿を外部に一切出さない構成が可能。品質はクローズド最上位に一歩劣るが、差は縮み続けている。日本語特化の国産モデルもある。
• 価格の桁感:APIは読み書きしたトークン数の従量課金。軽量モデルで100万トークンあたり数十〜数百円、最上位モデルで数千円のオーダー。

第2部 周辺知識 — 校正・校閲の実務とNLPの先行研究20分

出版社の人と話すとき、ここを知らないと一発で素人認定される。逆にここを押さえていれば「分かっている外部PM」として扱われる。時間あたりの費用対効果が最も高いパート。

2-1. 校正と校閲は別の仕事

2-2. 出版の校正ワークフロー:相手の日常を知る

• 工程:原稿整理→組版(誌面の形に組む)→初校→再校→念校→校了→印刷。各段階でゲラ(校正用の試し刷り)に赤字(修正指示。JIS規格の校正記号がある)を入れて著者・編集・校正者の間を往復する。
• 読み方は2種類:突き合わせ(元原稿とゲラを一字ずつ照合する)と素読み(元原稿なしで通読し、引っかかる箇所を拾う)。AIが代替を狙うのは主に素読み側。
• 表記の拠り所はハウスルール:各社が持つ用字用語集・スタイルガイド。業界の有名どころは共同通信社『記者ハンドブック』。

2-3. 先行プロダクト:競合と参照点

初回MTGまでにTypolessとShodoは触っておく(無料枠やデモがある)。「既存製品で足りないのはどこか」がこのプロジェクトの存在理由のはずで、それを自分の言葉で言えるのはPMの信用になる。

2-4. NLPの先行研究:GECという分野がある

• 文法誤りの自動訂正はGEC(Grammatical Error Correction)という確立した研究分野で、英語圏では10年以上コンペが行われ、評価手法も整備されている。研究室の人はこの文脈・語彙で話す可能性が高いので、名前だけは知っておく。
• 日本語の主な公開データ:日本語Wikipedia入力誤りデータセット(JWTD、京大)=Wikipediaの編集履歴から「誤り→修正」ペアを抽出したもの。Lang-8コーパス=語学学習SNSの添削データ。ただし、これらは「Web文章や学習者の誤り」であって、プロの書き手の原稿に出る誤りとは種類も頻度も違う。だからこそ、出版社が持つ実データ(赤字入りゲラ)がこのプロジェクト最大の資産になる。
• GEC研究の重要な教訓:訂正の正解は一つではない。同じ誤文に対して直し方が複数ありうる。これが評価を難しくしており、3-5の評価設計に直結する。
• 形態素解析(けいたいそかいせき):日本語文を単語に区切って品詞を付ける伝統的なNLP技術。ツールはMeCab、Sudachi、GiNZAなど。
  「すもももももももものうち」→「すもも/も/もも/も/もも/の/うち」と正確に区切れる。LLM時代でも「表記ゆれを全数調査する」「用語の出現回数を数える」ような網羅的・機械的な処理では現役の主力。LLMで全部やるより「形態素解析で数えて、LLMに判断させる」のが筋のいい設計(3-2)。

2-5. 研究室サイドが持ち込みそうな観点

大学の研究室が共同研究に求めるのは、通常論文になる新規性(新しい評価手法、データセット構築、モデル比較)とデータ。出版社が求めるのは動く道具と省力化。この2つは目的も締切(学会 vs 年度予算)も違う。PMの仕事はこの翻訳で、定石は「両方の利害が重なる作業に工数を寄せる」こと。その筆頭が評価データセットの構築(研究室には論文の材料、出版社には品質保証の根拠、会社にはプロダクト資産になる)。詳しくは4-1。

第3部 校正AIの設計論 — 本体45分

3-1. タスク分解:「校正して」は一つの仕事ではない

着任後まずやるべきは、「校正AI」というふわっとした要望を種類別のタスク表に分解すること。種類ごとに、最適な技術も、難しさも、間違えたときの被害も全く違うからだ。

3-2. アーキテクチャ:ルール層+LLM層のハイブリッド

2026年時点の校正AIの筋のいい構成は、ほぼ以下に収束している。

原稿(テキスト抽出・正規化)
   │
   ├─ [A] 決定的処理層(プログラム)……「そろばん担当」
   │     形態素解析→表記ゆれ集計、用語辞書との照合、
   │     数字・単位の抽出、正規表現ルール(textlint/prh的なもの)
   │     → 高精度・ほぼゼロ円・毎回同じ結果。機械的な指摘はここで刈り取る
   │
   ├─ [B] LLM層(チャンクごと)……「文脈担当」
   │     文脈依存の誤字脱字、文法、呼応、意味の通らなさ
   │     入力: チャンク本文+文書全体の情報(用語表・登場人物表)
   │     出力: 構造化された指摘リスト(3-3)
   │
   ├─ [C] 文書横断層……「通しで読む担当」
   │     [A][B]の結果を突き合わせ、章をまたぐ不整合
   │     (固有名詞・数字・設定)を照合
   │
   └─ [D] 検証層……「ダブルチェック担当」
         [B][C]の指摘を別の呼び出しで再検証(3-7)
         → 確信度つきで人間のレビュー画面へ

設計思想は一言で、「LLMは文脈判断だけに使い、数える・照合する・網羅するはプログラムにやらせる」という分業。安くなり、正確になり、「なぜこの指摘が出たか」の説明もつく。

3-3. 出力設計:「書き換えるな、指摘せよ」

校正AIで誰もが最初に踏む地雷が過剰修正(overcorrection)。LLMに全文を渡して「校正して」と頼むと、誤りの修正の「ついで」に文体まで直した全文を返してくる。

これが致命的な理由は3つ。①著者の文体は商品そのもの。②全文書き換えで返されると「どこを変えたのか」の差分検証をこちらでやる羽目になる。③書き換えの過程で、触るべきでない箇所を壊す(意味の改変・文の欠落)リスクがある。

正解は、全文を返させず、「指摘のリスト」だけを構造化出力(1-6)で返させること。

{
  "issues": [
    {
      "quote": "会議の資料を準備しま した。",  // 原文の該当箇所を一字一句そのまま引用させる
      "category": "typo",            // 誤字脱字|表記ゆれ|文法|整合|事実|表現
      "severity": "must_fix",        // 必須修正|修正推奨|提案
      "suggestion": "準備しました。",
      "reason": "「しま した」に不要な空白(衍字)",
      "confidence": "high"           // モデル自身の確信度
    }
  ]
}

3-4. 長文の扱い:チャンク設計

本1冊をどう分割してLLMに渡すか。設計ポイントは4つ。

• 切る位置:段落・節の境界で数千字ごと。文の途中でぶった切らない。境界付近の誤りを取りこぼさないよう、隣のチャンクと少し重ねる(オーバーラップ)。
• 全体情報の同梱(2パス構成):チャンクだけ読んでも「この本では『サーバ』ではなく『サーバー』と表記する」「主人公・佐藤ハルカは17歳」といった全体の約束事は分からない。そこで先に全文から用語表・固有名詞表・設定メモを抽出する下準備のパスを走らせ、その要約を全チャンクに添付する。
  1パス目:「この小説の登場人物と年齢・関係を表にして」→ 佐藤ハルカ(17)、兄・タケル(20)…という表を得る。2パス目:各チャンクにこの表を添えて校正させる。すると6章の「ハルカの兄タケル(19)」に対して「1章の設定(20歳)と矛盾」というチャンク単体では絶対に出せない指摘が出せるようになる。
• 並列処理:チャンク同士に依存がなければ同時に投げられる。本1冊を数分で処理できるかはここで決まる。
• 表記ゆれはチャンク処理では原理的に見つからない(3-2の例の通り、全体の分布の問題だから)。[A]プログラム層の担当。この切り分けを知らないと「LLMが表記ゆれを見逃す!」と的外れな悩み方をすることになる。

3-5. 評価(eval):このプロジェクトの本体はここ

断言するが、校正AIの成否はモデル選定でもプロンプトでもなく、評価の設計で決まる。理由は単純で、プロンプトを変えた・モデルを替えた・ルールを足した——そのたびに「良くなったのか悪くなったのか」を数字で判定できなければ、開発は感想の言い合いになって前に進まないからだ。かまのさんの会社がLLM品質保証をプロダクトにしていることからも、ここが商売の核であることは明らか。

評価の組み立て方(5ステップ)

① ゴールドセット(正解つき評価データ)を作る。最良の素材は出版社の過去の赤字入りゲラ——「実際の原稿に、実際に出た誤りと、プロの直し」がセットになった完璧な教材。もらえない場合は、きれいな文章にスクリプトで誤りを混入して人工的に作る(誤変換・脱字・表記ゆれを機械的に注入)。人工データは誤りの種類が偏る欠点があるが、開発サイクルを回し始めるには十分。

② 指標を2つに分けて測る。ここが最重要概念。

③ カテゴリ別に集計する。全体スコア1本だと「どこを直せばいいか」が分からない。3-1の分解表がそのまま評価の軸になる。

④ 「正解は一つではない」問題に対処する。「彼が学校行った」の直し方は「学校へ行った」でも「学校に行った」でも正しい。提案が正解と完全一致したかで採点すると厳しすぎるので、「検出できたか(誤り箇所を当てたか)」と「提案が妥当か」を分けて採点する。後者の判定はLLM-as-judge(別のLLMに審判をさせる手法)で自動化できるが、審判にも癖がある(自分に似た文章を高く評価しがち等)ので、定期的に人間の判定と突き合わせて審判自体を検品する。

⑤ 回帰テストとして自動化する。プロンプトやモデルを変えるたびにゴールドセット全体を自動で流し、スコアの変化を見る。ソフトウェア開発の自動テストと完全に同じ思想で、君のエンジニアリング感覚がそのまま活きる。

3-6. コスト試算の型:会議で即答できるように

前提: 単行本1冊 10万字 ≒ 13万トークン

チャンク4,000字 × 約25本
+ オーバーラップと共通の指示文で入力は1.5倍ほどに膨らむ
+ パスは「下準備(用語抽出)→本チェック→検証」で実質2.5周

→ 1冊あたり 入力≒50万トークン、出力≒8万トークン 規模

軽量〜中位モデル: 1冊 数十円〜数百円
最上位モデル:     1冊 数百円〜数千円
(比較: 人間の校正は1冊 数万〜十数万円)

含意:APIコストは事業の障害にならない。制約はコストではなく精度と信頼。だから「安いモデルで節約」を早期に頑張る意味は薄く、まず最上位モデルで精度の天井を確認→届くと分かってから安いモデルに置き換えられるか試す、の順番が正しい。逆をやると「精度が出ないのはモデルが安いからか、設計が悪いからか」が切り分けられなくなる。

3-7. ハルシネーション対策:多層の防波堤

1. 引用一致チェック(3-3の再掲):指摘のquoteが原文に実在するかをプログラムで照合。実在しない指摘は自動で捨てる。最も安くて最も強い1枚目の防波堤。
2. 検証パス:1回目の指摘を、別のプロンプト(または別のモデル)に渡して「この指摘は妥当か?この修正で原文の意味は変わらないか?」と再判定させる。たとえるなら、校正者の指摘を校閲部長がもう一度見る体制。体感でprecisionが大きく上がる。コストは倍近くなるが、3-6の通り問題にならない。
3. 確信度の閾値運用:モデル自身に確信度を申告させ、低いものは画面上で区別する(または出さない)。
4. 事実確認カテゴリには検索ツールを持たせ、出典URLを必ず添付させる。出典のない事実指摘は表示しない。「富士山の標高が違います」という指摘は、国土地理院のページを添えて初めて画面に出る。
5. 最終判断は人間(human-in-the-loop):AIの役割は「指摘の提案」まで。原稿に反映するかは編集者が決める。品質の問題であると同時に、出版社との信頼関係と、事故時の責任設計の問題。

3-8. モデル選定の考え方

• カテゴリで使い分ける:単純な誤字=軽量モデル、文法・整合=中位、校閲的な推論や検証パス=上位またはreasoningモデル。
• 選定は「ネットの評判」ではなく自前のゴールドセットのスコアで決める。3-5があれば選定会議は10分で終わる。なければ宗教論争になる。
• そして何より:未公開原稿を外部APIに送れるかという契約上の制約が、全技術選定に優先する(4-3)。送れないなら、手元で動かすオープンモデル構成が本命になる。技術選定の前に法務確認。

第4部 PMとしての立ち回り15分

4-1. 三者の利害マップ

PMの仕事はこの3つの時間軸の通訳。定石は「評価データセットの構築」を最初の共同成果物に置くこと——3者の利害が一点で重なる稀有な作業だからだ(研究室:論文の材料/出版社:品質の根拠/会社:資産)。

4-2. eval-firstのPoC進行(最初の1か月の型)

1. W1:要件の言語化。対象文書(単行本?雑誌?小説?実用書?)、対象カテゴリ(3-1の表を見せて指させる)、成功の定義。サンプル原稿とハウスルールの受領。
2. W2:ゴールドセットv0(数十ページ分で十分)+ベースライン計測。既存ツール(Just Right!等)と素のLLMのスコアを並べる。ここで出る数字がその後の全議論の土台。
3. W3:ハイブリッド構成(3-2)の最小実装でスコアを改善。カテゴリを絞る勇気を持つ。
4. W4:編集者に触ってもらうデモ。見た目はCLIでもスプレッドシート出力でもいい。現場の「使う/使わない」の生の反応が、precision目標値を決める。

アンチパターン:初月にUIを作り込む(中身の精度が出る前の画面は無意味)/全カテゴリ同時着手/デモ用に都合のいいサンプルを選んで期待値を吊り上げる(次のデモで必ず自分の首を絞める)。

4-3. データ・法務:最初に確認しないと全部やり直しになる

• 未公開原稿は機密の塊(発売前の商品であり著作物)。外部のLLM APIに送信してよいかは、技術ではなく契約の問題。主要APIには「送信データを学習に使わない」規約があるが、出版社がそれで納得するかは別問題。NDAとデータの取り扱いは初週に確認。
• ダメだった場合の代替案:国内リージョンでの処理/自前サーバーのオープンモデル/開発は公開済み作品・人工データで進める。
• 赤字データ(過去の校正記録)の権利:研究利用(論文化)の可否は研究室の死活問題なので早期に確認。
• 成果物の帰属:コード・評価データが誰のものか。会社のLLM品質保証プロダクトへの転用可否。

4-4. 成功指標を数字で定義する

「いい感じの校正AI」は指標ではない。例:「誤字脱字のrecall 85%以上・全体のprecision 75%以上(ゴールドセット計測)」「1冊あたりの校正時間を30%削減」「編集者の指摘採用率50%以上」。着任時点でこうした目標値は存在しない可能性が高い。存在しないこと自体を最初の論点にするのがPMの初仕事。

4-5. 初回MTGで聞くべき質問リスト

• □ 「校正」と「校閲」のどこまでがスコープか(3-1の表を見せて指させるのが早い)
• □ 対象文書の種類・分量・ファイル形式(InDesign?Word?PDF?——テキスト抽出の難しさが全然違う)
• □ ハウスルール(用字用語集)は存在するか、もらえるか
• □ 過去の赤字入りゲラ(誤り→修正のペア)はもらえるか ← 最重要の資産
• □ 未公開原稿を外部APIに送ってよいか。ダメならどんな構成なら許されるか
• □ 想定ユーザーは校正者か編集者か。既存ワークフロー(初校〜念校)のどこに挟むのか
• □ 既存ツール(Just Right!等)は使っているか。何が不満か
• □ 研究室側の関心テーマと学会締切、担当者の稼働時間
• □ 成功の定義。誰が「これは使える」とジャッジするのか
• □ 自分の権限範囲:技術選定・スコープ調整・関係者への直接連絡の可否

用語集(リファレンス)通読不要

トークン

LLMが読み書きする最小単位。日本語1文字≒1〜1.5トークン。課金と上限の単位。

コンテキストウィンドウ

1回の呼び出しでモデルが扱えるトークン数の上限。「作業机の広さ」。

system prompt

会話全体に効く役割・制約の指示。「業務命令書」。

temperature

出力のランダム性。0=毎回ほぼ同じ。校正では0。

few-shot

望ましい入出力の実例を2〜5個見せて挙動を合わせる手法。

ハルシネーション

もっともらしい嘘の生成。「続きの予測」という仕組みの必然的な副産物。

lost in the middle

長い入力の中間部への注意が落ちる現象。長文一括処理の敵。

構造化出力 / JSONモード

出力を指定した型のJSONに強制するAPI機能。

tool use / function calling

モデルが外部の関数の実行を要求できる仕組み。「判断はLLM、計算はコード」の分業を実現する。

エージェント

ツール呼び出しをループさせ、多段のタスクを自律的に進める構成。

MCP

ツール・データ源をLLMにつなぐ標準規格。

embeddings

テキストを意味の座標(数値ベクトル)に変換する技術。意味検索の基盤。

RAG

関連文書を検索してプロンプトに同梱してから生成させる構成。「資料の持ち込み」。

ファインチューニング / LoRA

自前データでモデルを追加学習させること。LoRAは低コストな部分学習方式。

reasoningモデル

答える前に内部で長い思考を回すモデル。複雑な推論に強いが高くつく。

GEC

Grammatical Error Correction。文法誤り訂正の研究分野。研究室側の共通言語。

形態素解析

日本語を単語に区切り品詞を付ける伝統NLP。網羅的な集計では今も主力。

ゴールドセット

正解つきの評価データ。開発の羅針盤。

precision / recall

適合率(指摘の正しさ=信頼)と再現率(誤りの捕捉率=価値)。

LLM-as-judge

出力の良し悪しを別のLLMに審判させる評価手法。審判自体の検品が必要。

human-in-the-loop

最終判断に人間を挟む運用設計。

過剰修正(overcorrection)

頼んでいない文体改変までモデルがやってしまうこと。校正AI最大の地雷。

PoC

Proof of Concept。小さく作って価値を実証する試作。

校正 / 校閲

表記の正しさを見るのが校正、内容の正しさを見るのが校閲。

ゲラ / 赤字

校正用の試し刷り/そこに書き込む修正指示。

初校・再校・念校・校了

ゲラ往復の工程名。

突き合わせ / 素読み

原稿との逐字照合/通読による違和感検出。

ハウスルール

出版社ごとの表記統一基準。正誤ではなく方針。

降車前の課題5分

読んで終わりにしない。降りる前に、この資料を見返さずに、Obsidianに自分の言葉で書く:

1. 初回MTGで自分が最初に提案すること(1文)
2. このプロジェクトが失敗するとしたら最も可能性が高いシナリオ(1文)
3. 初週に自分が作る成果物の仮説(3行以内)

ヒントは本文中にすべてある。書けなければ読めていないので、該当セクションだけ読み直す。