はじめに
長い文章を書いていると、ふと怖さが立ち上がる瞬間があります。
自分では筋が通っていると思っていても、
第三者から見ればどこかで論理がねじれているかもしれない。
見出しや段落の構造は整っていても、
一文ごとの温度や流れが、微妙にずれているかもしれない。
そして何より、引用元の文脈を踏まえたつもりでも、
自分の所感だけが先走ってしまっていないか。
市販の日本語校正ツールは、そこまで踏み込んではくれません。
一般的なAI校正も、引用文脈と所感の混ざり方までは面倒を見れません。
対象としてはかなりニッチな需要です。
であれば、
いっそ「自分の認知判断を前提とした校正機」を作ってしまうほうが早いのではないか。
このプロジェクトは、そんな素朴な発想からAntigravityを使い始めました。
第1章 ツール選びではなく、役割を設計する
最初に決めたのは、「どのツールを使うか」ではありませんでした。
この校正機にどんな役割を持たせるか、その構造をどう設計するかでした。
やりたいことは、大きく三つに分かれました。
・一万字を超える日本語原稿を一気に校正できること
・自分の文体や思考のクセを壊さずに点検できること
・引用由来の文脈と、自分の所感が不自然に混ざらないよう監視すること
ここで重要だったのは、
「すべてを自動で直してくれるAIエディタ」を欲していたわけではないという点です。
求めていたのは、
・変な箇所に静かに付箋を置いてくれる
・ただし、採用するかどうかは最後までこちらに委ねてくれる
そんな、第二の視点に近い存在でした。
だからこそ、Antigravity に期待したのは、完璧なエディタではなく、
この役割に特化したワークフローと構造を一緒につくっていけるツールという姿でした。
第2章 既存の校正では足りなかった三つのポイント
実際に既存の校正ツールを試してみると、三つの物足りなさが残りました。
・1つ目 トークン区切りの限界
長文になるほど、チャンクの境目で文脈が分断されます。
違和感の多くは、前後の流れとの比較ではじめて気づけるものです。
しかしながら、その「境目」こそが既存ツールにとって最も抜け落ちやすい領域でした。
境目を見てくれない校正機はどうしても不安が残ります。
・2つ目 文体と用途のズレ
一般的な「読みやすい日本語」の基準は、ビジネス実務の文体とは必ずしも一致しません。ブログでも論文でもない独特の構造を持っています。
ところが、既存ツールはこの前提を理解しないまま、一般化された基準で文章を削りにきます。結果として、残したいギリギリの言い回しまで排除されてしまいます。
3つ目 音声起こし特有の歪みへの無関心
実務で扱うテキストは、ワープロ打ちばかりではありません。録音ベース、公述記録ベースの素材が多く、そこには特有の歪みが生じます。
・録音ベースでの想定されない「し1よう」 のような数字混入
・「行為消そうとする行為消そうとする行為」 のような重複
・妙な位置での句点
・比喩だけが残り、主旨が薄れる謎の挙動
こうした歪みは、一般の校正機では前提外です。
だからこそ、自分の用途に合った校正機が必要でした。
第3章 Antigravity にやらせたかったこと
Antigravity に期待したのは、
ただコードを生成することではなく、こちらの違和感の構造を一緒に育てていく相棒に近いものでした。
校正機をつくるという作業は、単に間違いを直す作業ではありません。
文章のどこで、どうして、違和感が生まれているのかを静かに可視化していき、真に伝えたい要素を紡いでいく作業です。
そこで最初に必要だったのは、自分が普段どのような違和感を拾っているのかを
言葉として取り出すことでした。
その際に大きな助けになったのが、戸田山和久先生の『論文の教室』で登場する
ゾンビ文、ゴースト文、いかめし文という三つの概念です。
これらは、文章の歪みを分類するための視点としてとても優れていました。
名著なので是非ご一読ください。
以下では、Antigravity に実装してもらう上で特に役立った
三つの型とその具体例をまとめます。
1. ゾンビ文
主語と述語がねじれ、
意味はあるように見えるのに、構造が破綻している文です。
文法的には成立しているようでいて、読み手の頭の中では正しく像が結びません。
主語が担っているはずの役割と、述語が求めている主体が別方向を向いてしまう状態です。
具体例1：主語と述語の役割がずれる
誤：
この問題の解決には、私が新しい視点が必要です。
どちらが何を必要としているのかがねじれています。
正：
①この問題の解決には、新しい視点が必要です。
②私がこの問題を解決するためには、新しい視点が必要です。
具体例2：述語の指す主体が不明確
誤：
私たちの会社の課題は、多くの企業がDX化を進めている。
会社の課題なのか、他社の状況なのかが交錯しています。
正：
私たちの会社の課題は、他社が進めているDX化への対応です。
具体例3：視点が途中で入れ替わる
誤：
顧客満足度を高めるには、店舗側の教育が不十分です。
何が不十分なのかを述べたいのに、
「満足度を高めるには」が主語のように見えてしまいます。
正：
店舗側の教育が不十分であることが、顧客満足度向上の妨げになっています。
ゾンビ文は、読み手に「うまくつかめない」という静かなストレスを与えます。
このパターンを検出するために、
Antigravity には主語と述語の照応を監査する機能を入れました。
2. ゴースト文
文章のどこかにいるはずの主体が抜け落ち、
読み手が補完しなければ意味がつながらない文です。
主語が曖昧、文脈上必要な対象が欠落、あるいは説明の起点が宙づりになっています。
具体例1：誰が実行するのか不明
誤：
検討した結果、改善が必要だと考えた。
誰が検討し、誰が改善を必要としたのかが消えています。
正：
私たちは検討した結果、改善が必要だと考えました。
具体例2：対象が突然切り替わる
誤：
データ分析を進めると、チームの課題が明らかになったが、
改善には時間がかかる。
「改善には時間がかかる」の主体が不明です。
正：
データ分析によってチームの課題が明らかになりましたが、
その課題を改善するには時間がかかります。
具体例3：前文とつながらない説明
誤：
このサービスは大きな価値があります。
ユーザーが増えることで成長が期待できる。
どの成長を指すのか、対象が飛んでいます。
正：
このサービスは大きな価値があります。
ユーザー数が増えることで、サービス自体の成長も期待できます。
ゴースト文は、曖昧なまま流れを進めてしまったときに
生まれやすい型でした。Antigravity には、主語の照応や省略の連鎖をトレースさせる仕組みを組み込んでいきました。
3. いかめし文
表現が過剰で、内容以上に言葉が膨らんでしまった文です。
イカの胴体にご飯を詰め込みすぎたように、
本質が見えにくくなります。
具体例1：修飾語が詰め込みすぎ
誤：
非常に重要であると同時に、極めて本質的な示唆を多く含む重要な論点です。
正：
本質的な示唆を含む重要な論点です。
具体例2：一文に情報を積みすぎる
誤：
今回の分析結果は、これまでの市場動向の流れを踏まえつつ、
新規参入企業の増加による競争圧力の高まりを示唆しながら、
同時に消費者の嗜好変化の影響も見逃せないという点で重要です。
正：
今回の分析結果は、
競争圧力の高まりと消費者嗜好の変化が同時に進んでいる点を示しています。
具体例3：比喩が過剰に働く
誤：
市場全体を揺るがす巨大な波が、今まさに押し寄せてきている状況です。
正：
市場に大きな変化が生じつつあります。
いかめし文は、文の温度が上がりすぎることで発生します。
Antigravity では、修飾の密度をスコア化し、一定の阈値を超えた文に軽く赤信号をつけるようにしました。
これら三つの違和感を、Antigravity には次の三層に分けて落とし込んでもらいました。
ルールベース層：
主語・述語の構造、修飾の密度、重複検出
LLM層：
文脈の補完、語彙の温度、場面に応じた言い回しの妥当性
UI/UX層：
どこに注意が必要か、読み手が迷わない形で提示する設計
この往復を続ける中で、重視したのは
いちいち聞かずに、自律的に手を動かしてもらうことでした。
実装方針は任せる。しきい値も暫定でよいから決めておいてもらう。
その上で、こちらは「そこは攻めていい」「そこは抑えてほしい」
とだけ伝える。
すると、自分の認知資源は「設計」と「評価」に集中できます。
Antigravity は「手と脚」として、仕様を現実にしていく。
そんな役割分担が自然にできていきました。
第4章 最初のMVPで決めた制約
この校正機を最初に形にする段階では、
MVPとしていくつかの制約を明確に置きました。
1. まずはルールベースを土台にする
最初から LLM の万能性に依存しないこと。
同音異義語、長文、主語欠落など、素朴なロジックで良いので確実に検出する。
2. LLM は差し替え可能な層として扱う
ローカルとAPIの両方が選択できるようにし、
ANALYSIS_MODE の切り替え構造だけ先に作る。
3. 基本線はオフライン完結
LLMもWeb検索もデフォルト無効。
それでも最低限動く校正機にする。
4. UIは最初から日本語前提
後から悩まないよう、ボタンやラベルは日本語で統一し、
「自分が迷わない用語」を選ぶ。
このMVPが動いた瞬間に、器としての輪郭が整った感覚がありました。
あとはここに、自分の判断軸をどれだけ流し込めるかという勝負になります。
おわりに
最初から、あえて実装の細かさには踏み込みませんでした。
なぜ「自分専用の校正機」を作ろうと思ったのか。
その背景と設計の起点だけを整理しました。
次からは、少し泥臭い話に入ります。
長文をどう分割し、どう重ねて見るか。
履歴やエクスポートをどこまで作り込むか。
ゾンビ文やゴースト文といった概念をどうコードに落としたか。
Transcript 特有の歪みとどう折り合いをつけたか。
フェーズごとの試行錯誤、
やって良かった点、足しすぎた点、
そのあたりを具体的な実装とあわせて記録していくつもりです。
積極的にやってみたことを記載してくださる皆様がいらっしゃるので、励みになります。