文章編集Agent Skillで意味を変えないためにしたこと

こんにちは。AlgomaticでソフトウェアエンジニアをしているGo（@53able）です。

AIに文章を整えさせたら、読みやすくなった代わりに意味が変わっていた。文章編集、要約、校正のAgent Skillを作る開発者にとって、これは表現の好みではなく仕様違反です。

たとえば、「関係者へ共有できます」を「関係者へ共有します」と直すと、可能だった行為が実施予定の行為へ変わります。「重要です」を「実行します」と直せば、評価が約束へ変わります。数値や固有名詞を加えていなくても、原文の主張は別物です。

今回は、日本語向けのAgent Skillとして、No AI Slop JAを作りました。公開前レビューでこの失敗が見つかったため、編集の優先順位、例文の作り方、テスト、モデル評価を設計し直しました。この記事では、公開前の失敗と検証記録をたどり、文章編集Agent Skillで意味を守るために何を変えたかを説明します。

github.com

• 21パターンを定義しても、意味は守れなかった

• 公開前レビューで見つかった4つの意味変更

• 意味保持、誤読防止、定型感の順に直す

• 例文も仕様としてレビューする

• 検出モードは、出典不足や曖昧な主体を返す

• 反例で「直さない判断」を試す

• CIの成功と文章品質を分けて測る

• 文章編集Agent Skillで守る5つの基準

• まとめ：文章編集では、変えなかったものも測る

• エンジニアを募集しています！

• Sources

21パターンを定義しても、意味は守れなかった

No AI Slop JAは、Peter Yang氏のno-ai-slopを基にした日本語版です。原版には、二項対立、前置き、出典のない権威づけ、抽象的な締めなど、英語圏のAI文章で繰り返されやすいパターンが整理されています。

日本語版では、原版の考え方に加えて、日本語固有の問題を定義しました。

• 主体のない受け身と、段落内での無言の主語交代

• 「変更することができます」のような「こと」の殻

• 「チームの開発の速度の改善」のような「の」の連鎖

• 漢語サ変名詞の渋滞と修飾先の迷子

• 「確認させていただく形となっております」のような、責任を隠す過剰敬語

最終的な`SKILL.md`には、日本語固有の10パターンと、言語をまたいで現れる11パターンを収録しています。それぞれに悪い例、修正方針、誤検知を避ける条件を付けました。

ところが、パターンを増やしても安全な編集にはなりませんでした。不自然さを見つける規則はあっても、意味を保って直す規則が弱かったからです。

公開前レビューで見つかった4つの意味変更

初回コミット前のレビュー稿には、次のような修正が含まれていました。この段階の文章は公開Git履歴には残っていませんが、公開前レビューの記録から差分を確認しました。

確認することが重要です。
共有することが重要です。
記録することが重要です。

これを短くするために、次のような修正例を置いていました。

確認し、共有し、記録します。

反復は消えています。一方で、「三つの行為が重要だ」という評価が、「三つの行為を実施する」という表明へ変わりました。

同じ問題は、ほかの例にもありました。

答えは？ シンプルです。自動化。以上です。

を、

自動化します。

に変えると、名詞による回答が実施の約束へ変わります。

議事録の例では、次の入力を、

決定事項と担当者を記録して関係者への共有を実施することができます。

次のように変えていました。

会議が終わったら、運営担当が議事録を確認して関係者へ共有します。

ここでは可能が予定または意志へ変わっただけではありません。原文になかった時点、主体、確認という行為、議事録という対象も加わっています。

さらに、一文を分割する例では、「効率化につながると考えられます」という結論を削っていました。この文には、効率化という命題だけでなく、「考えられます」という不確実さも含まれます。文章を簡潔にするために、書き手の結論と確度を同時に消していました。

これらは、原文にない会社名や数値を作るような分かりやすい捏造ではありません。それでも、原文の主張は変わっています。文章編集では、語句の追加だけでなく、可能、義務、予定、実績、推測の変化も検査しなければなりません。

意味保持、誤読防止、定型感の順に直す

レビューで同じ種類の問題が続いたため、個々の例文に加え、編集規則の順序も変えました。

現在のスキルは、次の順番で文章を扱います。

• 意味を守る

• 誤読を防ぐ

• 定型感を減らす

下位の目的のために、上位の目的を壊してはいけません。文章を短くした結果、可能が約束へ変わるなら、その修正は採用しません。曖昧な主語を明示した結果、原文にない担当者を作るなら、書き換えずに確認を求めます。

「意味を守る」では、次の要素を不変条件として確認します。

• 主体と対象

• 行為

• 過去、現在、未来と、完了、継続、反復

• 可能、義務、予定、意志、実績

• 断定、推測、伝聞、保留の強さ

• 原因、条件、結果、目的

• 数値、単位、日時、順序

• 引用と出典

この優先順位と不変条件は、`SKILL.md`と、出力前に使う`eval.md`の両方に入れています。

例文も仕様としてレビューする

SKILL.md内の例文は、モデルが参照し得る実行仕様です。補足説明と考えず、本文の規則と同じ慎重さで点検します。

本文で「事実を作らない」と書いていても、直後の例が主体や機能を補っていれば、同じ種類の変換を誘発するリスクがあります。今回の評価では例文あり・なしを比較していないため、影響の強さまでは測っていません。

ただし、例文自体が意味を変えていないかは点検できます。すべての悪い例と修正例を、次のように命題単位で比較しました。

誰が行うか
何を行うか
いつ行うか
実施済みか、可能か、予定か
断定か、推測か
原因と結果は何か
数値、引用、出典は残っているか

たとえば、主体のない受け身を直す場合でも、勝手に「運営チーム」を主語にしません。

新しい方針が決定されました。

主体が本文から分かる場合だけ、次の形にします。

[決定者]が新しい方針を決めました。

分からない場合は、推測で埋めずに確認します。具体的で自然な例文を作ろうとするほど、存在しない主体や仕組みを足しやすくなるためです。

検出モードは、出典不足や曖昧な主体を返す

主体や出典を推測で補うと、原文にない情報が加わります。これを避けるため、No AI Slop JAには改稿モードに加えて検出モードを用意しました。検出モードは、文章がAI製かどうかを判定せず、確率や点数も出しません。原文中の該当箇所を引用し、パターン名、理由、修正方向を返します。

パターン名: 根拠のない帰属
該当箇所: 「専門家はこの方法が有効だと指摘しています」
理由: 専門家が誰なのか、出典が示されていない
直し方: 専門家と出典を明示し、確認できなければ主張を削る

AI文体の特徴は、モデル、時期、文章のジャンルによって変わります。執筆者を推測せず、出典不足や曖昧な主体など、読者が確認できる問題を編集規則にしました。

反例で「直さない判断」を試す

`tests/cases.json`には、21パターンの正例、誤検知を防ぐ反例、保持条件を確認するケースを入れました。以下の文章と数値は評価用に作成した架空入力であり、実測値や公開実績ではありません。

反例には、次のような文章があります。

APIレスポンスをRedisへキャッシュし、p95レイテンシを120ミリ秒まで下げました。

カタカナ語が複数あっても、API、Redis、キャッシュ、p95レイテンシは対象読者に通じる技術用語です。測定値を模した具体的な数値も含めています。カタカナ語の多さだけを理由に言い換えたり、具体的な数値を変えたりしてはいけません。

文学的な短文も反例にしています。

雨。まだ雨。駅の時計だけが、昨日と同じ速さで動いている。

短文の反復は、説明文では機械的に見えることがあります。この例では、リズムと停滞感を作っています。文章の役割を確認せずに短文を連結すれば、書き手の意図を消します。

保持ケースでは、日付、人数、問い合わせ件数、くだけた表現をまとめて固定しました。

2026年4月3日、私たちは試験版を17人に公開しました。
正直、初日の問い合わせ8件にはびびりました。

「びびりました」を「驚きました」に変えれば整った文章になりますが、書き手の声は弱くなります。この表現は保持対象として明示しました。

CIの成功と文章品質を分けて測る

現在のテストスイートは、メタデータ、リンク、ライセンス、パッケージ内容、21パターンの網羅、評価ケースのスキーマを検証します。2026年8月30日時点のCIでは、24件のテストとプラグインパッケージ検証が成功しています。実行結果はGitHub Actionsで確認できます。

構造テストが成功しても、モデルの出力品質は分かりません。cases.jsonの期待値は、モデルがそのとおりに振る舞った証拠にはならないためです。

そこで、構造テストとは別に単発パイロット評価の手順を作りました。

手順は次のとおりです。

• 評価対象のコミットとSKILL.md、cases.jsonのハッシュを固定する

• 対象ケースを結果を見る前に選ぶ

• ケースごとに新しい会話でモデルを実行する

• 生出力を加工せず保存する

• 生成とは別の会話で12項目を判定する

• 生出力と判定結果のハッシュを結び付ける

• 検証スクリプトで件数を集計する

最初のパイロットでは、openai-codex/gpt-5.6-sol:highを使い、事前に選んだ8ケースを個別に実行しました。判定にも同じモデルを使いましたが、生成とは別の新規会話で実施しています。判定では、いずれかの確認項目がfailになったケースは0件でした。生出力、判定、集計はパイロット記録に保存しています。

この結果は、選んだ8ケースと一回の実行にしか適用できません。反復実行、複数モデル比較、実利用文からの標本抽出、人による判定を行っていないため、成功率や誤検知率ではありません。同じモデルによる判定には、生成側と評価側で傾向を共有する可能性も残ります。

初回パイロットで確認できたのは、評価手順が動くことまでです。今後は、同じケースの反復、複数モデル、実際の記事や業務文書、書き手本人による判定を使い、主体、モダリティ、確度を保持または変更した件数を記録します。

ここまでの設計変更と評価上の注意を、五つの基準にまとめます。

• 自然さより先に、意味の不変条件を置く。 「自然な文章」は評価者によって揺れます。主体、時制、可能、義務、確度、因果、数値は原文と比較できます。

• 例文もテストする。 本文の規則だけでなく、悪い例と修正例の間で命題が変わっていないかを確認します。例文は具体的な行動例として参照され得るため、実行仕様と同じ慎重さで扱います。

• 直す能力と、直さない判断を両方評価する。 受け身、専門用語、短文、箇条書きは、存在するだけでは問題になりません。21パターンの各説明に誤検知条件を置き、ケース集には独立した反例を5件用意しました。

• 構造テストとモデル評価を分ける。 JSONスキーマ、ファイル構成、リンク、CIの成功は、モデルが意味を守る証拠にはなりません。モデル出力は加工せず保存し、生成とは別の会話で判定します。

• 単発評価をベンチマークと呼ばない。 8件すべてに失敗がなくても、一般的な成功率は分かりません。対象コミット、モデル、ケース、実行回数を結果と一緒に示します。

まとめ：文章編集では、変えなかったものも測る

No AI Slop JAの開発では、定型表現を見つける規則だけでは安全な改稿にならないと分かりました。文章を短く整えても、可能が予定へ、推測が断定へ変われば、原文とは別の主張になります。

文章編集Agent Skillでは、意味保持、誤読防止、定型感の削減の順に編集します。例文も仕様としてレビューし、正例と反例で「直す能力」と「直さない判断」を試します。構造テストとモデル評価は分け、単発の結果を一般的な成功率として扱いません。

「関係者へ共有できます」を「関係者へ共有します」に変えない。No AI Slop JAで重要だったのは、修正規則を増やすことより、直してはいけない箇所で止まる基準を持つことでした。文章編集Agent Skillの品質は、直した件数ではなく、必要な修正と不要な修正を分けられるかで測ります。

エンジニアを募集しています！

ここまで読んでいただきありがとうございました！

Algomatic では、「AI革命で人々を幸せにする」をミッションに、変化の速い領域でも 学びや試行錯誤を続けられる エンジニアを募集しています。

もし少しでもご興味をお持ちいただけましたら、カジュアル面談に足を運んでいただけるとうれしいです！

Sources

• 53able/no-ai-slop-ja

• No AI Slop JA SKILL.md

• No AI Slop JA eval.md

• No AI Slop JA evaluation cases

• No AI Slop JA pilot record

• No AI Slop by Peter Yang