Suiko

Suiko

公開・共有する原稿について、読者が書き手の補足なしに意味を追えるように推敲する。依頼が点検だけなら診断を返し、改稿も求められたら意味・事実・著者の判断を保って直す。機械検出を読み直す入口として使い、文脈から採否と理由を決める。

モードを選ぶ

• quick（既定）: 日常の短い文書。該当する文書型を確認し、suiko lint と通読で仕上げる。
• full: 対外文書、経営向け文書、約1万字を超える文書。lint、outline、terms と目視レビューをすべて使う。
• score: 書き換えず自然度と理由だけを返す。最初に diagnose.md を読む。
• academic: 学術論文・研究報告・投稿用DOCX/PDF。最初にacademic-delivery.mdを読み、中心命題、説明対象、順序、用語、節間接続、注、成果物を監査する。

CLI が見つからない場合（suiko --version が失敗する場合）は、次の順で自分で導入する。

1. cargo があれば cargo install suiko を実行する（crates.io から取得。初回ビルドは形態素辞書の取得と埋め込みを含むため数分かかり、ネットワークが必要）。完了後に suiko --version で確認する。
2. cargo がない、またはインストールに失敗した場合は、導入手順（rustup で Rust 1.97 以降を入れてから cargo install suiko）をユーザーへ提示し、その回の診断は manual-checklist.md で手動診断する。

リポジトリが手元にある場合に限り、cargo run --release -- を suiko の代わりに使える。

1. 読者と骨格を決める

読者、読後に起きてほしいこと、主メッセージを一文で特定する。不明で結果が大きく変わる場合だけユーザーに確認する。

文書タイプに対応する型を読む。

• 議事録: minutes.md
• 調査・分析レポート: report.md
• 社内ガイド・マニュアル: guide.md
• リサーチメモ・企画書・提案書: memo.md
• スライド構成: slide.md

主メッセージを見出しへ落とし、見出しだけで論旨が通るようにする。重要な節を厚く、軽い節を短くし、全節を同じ型と長さに揃えない。素材が乏しい場合は言い回しを作る前に、固有名詞、数値、実例、一次情報を集める。

学術稿では、見出しを先に整えるより、academic-delivery.mdの順に、説明対象、中心命題、ユーザーが示した論理順序、形式的RQの要否、用語のstatusを固定する。文章を整えるために章順、概念、結論を変えない。対象を説明してから名称を導入し、既存語は出典、造語は造語であることを本文へ示す。

2. 文体制約の下で書く

新規執筆や大きな改稿では writing-constitution.md を読む。以下を基本とし、エッセイの結論の位置や意図した反復は ジャンル別の方針 に従う。

• 結論を先に置き、前置きで助走しない。
• 見出しを内容ラベルではなくメッセージにする。
• 箇条書きは真に並列な情報の圧縮にだけ使う。
• 専門用語は機能を説明してから名前を出す。
• 事実と意見、限界と推定を区別する。
• 固有名詞、数値、具体例で一般論を接地する。
• 同じ文型や対比構文を三度繰り返さない。

ユーザー指定の style-profile.md があれば優先する。文体の学習を明示的に求められた場合だけ、style-profile-template.md を使って過去文書3〜5本から傾向を抽出する。

3. 決定的な検査を行う

対象をファイルへ保存し、ジャンルが分かる場合は essay、tech、business を指定する。

suiko lint <file> --json
suiko lint <file> --genre tech --json

lint は既定で読解負荷レーン（reading_load）も返す（v0.3.10以降。v0.3.9以前は --reading-load が必要）。自然度の findings と混ぜずに読む。読みやすさを対象にしない依頼では --no-reading-load で外してよい。

reading_load は一文長、埋もれた列挙、疑問節の埋もれた列挙（buried_question_list）、連続漢字、二重否定、「の」連鎖、一つの名詞に前置された長い修飾節（long_attributive_span）を見るための指さしであり、自然度 finding やベースラインには含まれない。

表現の追加候補まで確認する依頼では--experimentalを付ける。v0.3.11では、全ジャンルでdecision_direction_metaphor（選択を「残さない側に倒す」等で表す）、short_object_comma（短い名詞句＋「を」の読点）、vague_sensory_term（理解や根拠の程度を「解像度」「腹落ち」「肌感」「温度感」で表す）、copy_fragment（「資料を、全員へ。」のように述語を書かない惹句）を確認できる。条件と動作を明記できるか、読点がつながりを助けるか、感覚語の指す内容や惹句の動作主を原文や提供資料から書けるかを判断し、説明済みの比喩や意図した間・標語は残す。原文から分からない内容は推測で補わず、書き手への確認事項にする。

full では構造と用語も抽出する。

suiko outline <file> --json
suiko terms <file> --json
suiko lexical-audit <file> --reference <lexical-reference.json> --json

学術稿では、段落第一文と節間の橋をoutlineで確認した後、監査契約を作る。契約がある場合は、契約違反を直すか理由を記録し、提出前にacademicを実行する。

suiko academic <paper.md> --contract <academic-contract.json> --json
suiko academic <paper.md> --contract <academic-contract.json> \
  --docx <submission.docx> --template <official-template.docx> \
  --pdf <submission.pdf> --export-record <delivery-record.json> --json

academicは意味の自動採点ではない。防御的留保、未登録ラベル、引用と参考文献、節間の共有対象、注分類、Markdown/DOCX/PDF同期、OOXML不変条件を確認する。注の本文・注・不要の判断と、段落・節の意味上の修正は、全文脈を読んで行う。

複数ファイルも指定できる。標準入力は <command> - で受け取る。CIで検出を失敗扱いにする必要がある場合だけ --fail-on warn などを使う。通常の finding は exit code 0、入力エラーは1、--fail-on 到達は2である。

lint はカレントディレクトリの .suiko.toml を自動検出する。プロジェクトに設定がある場合は、既定ジャンル、severity gate、無効化ルール、理由付きの個別許可をその方針として扱う。CLIの --genre と --fail-on は設定より優先される。設定を切り分ける必要があるときだけ --no-config、別の設定を使うときは --config <path> を指定する。設定の新規作成や許可項目の追加は、ユーザーがプロジェクト方針の変更を求めた場合に限る。

Node.js 20.18以降とnpmが使える場合は、Suikoと同じ対象へtextlintのAI文章presetも実行する。プロジェクトのtextlint設定が同じpresetを有効にしている場合は、ロックされた依存関係と既存の許可設定を尊重して、そのプロジェクトの検査コマンドを一度だけ使う。設定されていない場合は、Skillディレクトリを基準に次の同梱スクリプトを使う。

sh <skill-directory>/scripts/run-textlint-ai-writing.sh <file>

この検査は固定したtextlintとpresetをnpmの一時環境で実行し、プロジェクトの依存関係や設定を変更しない。--fixは使わない。終了コード1でもJSONにmessagesがあれば検出結果として扱う。Node/npmがない、ネットワークから取得できない、対象形式を処理できないなどJSONを取得できない場合は、理由を一言示してSuikoの検査だけを続ける。textlintの結果は別の検査結果として扱い、Suikoの自然度スコア、baseline、finding件数には加えない。

4. finding を判断する

finding は疑いであって命令ではない。該当行と周辺文脈を読み、各 finding を次のどちらかへ分類する。

• 直す: 意味と事実を保った修正案を作る。
• 残す: 固有名詞、技術用語、意図した反復、ジャンル上自然などの理由を一言記録する。

「AI臭い」「何が言いたいか分からない」という依頼では、検出の有無に加えて改稿ガイドの「意味の補完を読者へ押し付けていないか」を確認する。対象・条件・理由が本文にあるか、読み手の推測でつないでいないかを読む。省くと結論や次の行動が変わる情報を補い、共有済みの前提や意図した余韻は残す。補う根拠がなければ、読みが分かれる箇所と確認事項を示す。著者の判断や経験を作り足さない。

カテゴリ別の判断に迷った場合だけ、必要な参照を読む。

• 禁止語・LLM常套句: forbidden-patterns.md
• 抽象比喩: revision-guide.md
• 翻訳調・英語統語: translationese.md
• 修正方針と判断台帳: revision-guide.md
• 読みやすさの原則: readability-principles.md
• 読解負荷の詳細: readability-antipatterns.md
• ジャンル差: genre-notes.md
• エッセイで反復・迷い・語調の変化を残す判断: narrative-judgment.md
• Before/After: examples.md

outline では論旨、見出し、反復、節の濃淡、結論の位置を見る。terms の has_gloss_hint は説明済みという判定ではなく、初出付近に説明マーカーがあるという手掛かりとして扱う。一般名詞複合語や漢語・和語等の統制を確認するときはlexical-auditを使う。新奇複合語とレジスター共起はinfoの確認候補であり、参照資源にない意味上の同義性を推測せず、原稿を書き換えない。

既存の校正工程との境界

既存の校正設定や用語辞書はプロジェクト規約として尊重し、Suikoで置き換えない。Suikoは形態素列、文書内の反復、構造、読解負荷を受け持つ。textlintのAI文章presetはMarkdown AST上の定型表現、強調、箇条書き、コロン接続を補う。両方が同じ箇所を指した場合は、判断台帳では一つの修正として扱い、同じ修正を二重に適用しない。一般的な表記規則や製品名の正規化は既存の工程へ残す。

5. ベースラインで収束させる

修正前のJSONを作業用ファイルへ保存し、修正後に比較する。

suiko lint <file> --genre tech --json > /tmp/suiko-before.json
suiko lint <file> --genre tech --baseline /tmp/suiko-before.json --json

同じバージョン・ジャンル・--experimental指定・設定・ファイル名で比較する。v0.3.11へ更新したらbaselineを作り直す。newとpersistingは、直すか、意図して残す理由を判断する。resolvedも意味の改善を保証しないため、変更箇所を読み直す。reading_loadは比較に含まれないので今回の出力を別に確認する。同じ指摘の往復が続く場合は、文・段落の構造を見直すか理由を付けて残す。

改稿した箇所は、原文にあった条件・数値・例外の脱落と、原文にない主体・原因・効果の追加を別々に確かめる。手順や仕様では、依頼・可能・自動動作の区別も保つ。判断例は改稿ガイドの「改稿前後を双方向に照合する」を参照する。

最後に初見の読者として通読し、声に出して読めるリズムか、主語述語と事実関係が修正前から壊れていないか確認する。作業用JSONや中間稿は完成時に破棄する。ユーザーが保存を求めた場合だけ、指定された場所へ残す。

意味的な話題の平板さは、埋め込みモデルを使う自動findingへ含めない。各段落が観測、理由、結果、具体例、判断、限界のいずれかを前段へ追加しているかを目視で確認する。モデル実験では二つの構成例を安定して区別する根拠が弱く、初回取得、配布量、メモリ使用量がオフラインの単一バイナリという境界に見合わなかった。