sepia レビュー: 語彙ではなく物語構造を直す De-AI スキル
De-AI writing skill for any Agent Skills-compatible agent (77+ via the Skills CLI), with native plugins for Claude Code, Codex, Grok Build, and Antigravity. Narrative-architecture repair for fiction, venue-matched rules for professional prose. Based on StoryScope (arXiv:2604.03136).
ひと目でわかる
- これは何？
- sepia は Agent Skills 規格に準拠したライティング修正スキルで、AI らしさの原因を語彙ではなく物語構造と談話の流れに置く。StoryScope の測定結果を三つのパスに落とし込み、フィクションと実務文書で別のルールを当てる。
- 誰に向いている？
- 採用を検討すべきなのは、AI 生成のフィクションや定型化した実務文書を日常的に扱い、Claude Code や Codex などの対応エージェントをすでに使っている書き手だ。逆に、対応エージェントを持たない環境や、単発の校正しかしない用途では、SKILL.md を読み込む経路そのものが無駄になる。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
sepia が狙う「語彙の先」という層
多くの humanizer は語彙と構文を置き換える。sepia の README はこの層を第三パスとして最後に置き、その手前により効く層があると主張する。根拠として引かれるのは StoryScope (arXiv:2604.03136, Russell et al., 2026) で、61,608 本の物語を人間と 5 つのフロンティア LLM で比較した研究だ。README によれば、物語構造の特徴量だけで学習した分類器はマクロ F1 93.2% で AI フィクションを検出する。同じ研究の LAMP-edited 条件、つまり人間の編集者が表層の文体を書き直した条件でも、検出率は 95.5% から 93.9% へしか下がらなかった。ここから sepia が引き出す結論は明快で、生き残る痕跡は建築的だという点である。テーマを地の文で説明してしまうこと、因果が一本道で整いすぎたプロット、感情が身体感覚としてしか描かれないこと、実在世界への参照がないこと、読者の存在がないこと、時間が一直線であること、主人公の成長と受容で終わる結末。これらは語を差し替えても消えない。対象読者は、AI で書いた小説や実務文書を、読者に AI 臭いと見抜かれない形にしたい人である。
三つのパスと 30 特徴の診断ルーブリック
sepia の書き換え手順は三層に分かれる。第一パスは物語構造で、テーマの説明をやめる、因果の連鎖を緩める、開示を後ろにずらす、感情のモードを混ぜる、人物ネットワークを疎にする、実在の固有名を出す、といった操作が並ぶ。第二パスは談話の流れで、段落と問いのテンプレート的な順序を崩し、中盤の失速を直し、リズムと位置を変える。第三パスが従来型の表層スタイル、つまり決まり文句、構文テンプレート、語彙、レジスターである。診断側には 30 特徴のルーブリックがあり、モデル指紋は二層で管理される。物語上の痕跡は StoryScope が測定した Claude、GPT、Gemini、DeepSeek、Kimi のもの。文単位の痕跡は各ベンダー自身のプロンプトガイドから取られ、書き手または実行モデルが判明している場合にだけ適用される。README はベンダー名として Claude Fable 5.1 と Mythos 5.1、Fable 5 と Mythos 5、Opus 5、Opus 4.8、GPT-5.6、GPT-6 Astra、Gemini 3 系を挙げる。ガイドを公開していないベンダーについては、推測せず「参照済み」として記録するという方針が明記されている。
実務文書はフィクションとは別のルールファイルで動く
sepia の設計で見落としやすいのは、プロ向け文章をフィクションと同じ手順で扱わない点だ。README は、実務文書の失敗は情報を持たない埋め草、判断すべき箇所での過剰なヘッジ、チャットボットの残骸、場に合わないレジスター、型で押したような整形に出ると説明する。そこで共有チェックリストの上に、文書種別ごとの薄いルールファイルを重ねる。リリースノートと告知ではユーザー影響を先に書き、主張ごとに成果物を示し、マーケティング的な誇張を避ける。PR や issue への返信では結論を先に置き、file:line を引用し、反射的な称賛をやめ、長さを案件の重さに比例させる。ポストモーテムでは人に対しては非難せず、仕組みに対しては容赦なく、タイムスタンプ、行き止まり、担当者のあるアクションアイテムを書く。チケットや作業指示ではタイトルを成果にし、検証可能な受け入れ条件を置き、繰り返さずリンクする。技術記事では問題から始め、実際の行き止まりを一つ入れ、コミットした意見を一つ持ち、数値には条件を添える。会場が文体を決めるという原則は、プロ向けの経路でも維持される。
インストールと操作エントリの実際
sepia は Agent Skills 規格に準拠したポータブルなスキルで、README によれば規格を話す任意のエージェントが読み込める。77 以上のエージェントに対応する Skills CLI を使えば一行で入る。加えて Claude Code、Codex、Grok Build、Antigravity にはネイティブのプラグインパッケージが用意される。正典となる SKILL.md は一つだけで、プラットフォームごとのフォークは存在しない。操作は write、review、refactor、recreate の四つに、組み込みの Hemingway ボイスを当てる hemingway を加えた五つの入口がある。呼び出し記法はプラットフォームで異なり、Claude Code、Grok Build、Antigravity では /sepia-write、/sepia-review、/sepia-refactor、/sepia-recreate、/sepia-hemingway、Codex では $sepia-write のようにドル記号が付く。汎用ルータは Claude Code、Grok Build、Antigravity では /sepia、Codex では $sepia である。README はここで重要な制約を明示している。操作ラッパーは隣接する正典スキルに依存するため、ラッパー単体のインストールはサポート外で、完全なプラグインパッケージとして入れる必要がある。各プラットフォームで何を検証済みかは Install の節に書かれているという記述にとどまり、本稿ではその中身を確認していない。
較正という原則と、それを破る誘惑
sepia の統治原則は「人間の分布に較正せよ、AI の分布を反転させるな」というものだ。README の表現を借りれば、人間は中庸の値に位置し、すべてのルールを適用した物語は新しい指紋になる。このためスキルは一つの物語につき 3 から 5 の操作を選び、余白を残す。ここは sepia の設計思想が最もはっきり出る箇所であり、同時に最も運用が難しい箇所でもある。どの 3 から 5 を選ぶかは書き手の判断に委ねられ、スキルは判断を代行しない。ルールを全部盛りした結果として生まれる均質な文章は、AI らしさを消した代わりに別の型を刻む。ボイススキルとの合成も同じ原則で動く。v0.4.0 以降、ミニマリズムの手法、ブランドボイス、ペルソナガイドなどを重ねるインターフェースが定義されているが、これはオプトインである。ボイススキルが使われていると伝えた場合にだけ references/voice-skills.md が通常経路の上に読み込まれる。契約では sepia の構造上の決定が先に来て、ボイスの操作は選択的に、作品ごとに 3 から 5 のシグネチャ操作だけが適用される。
ボイス合成の証拠の薄さと Hemingway プロファイル
ここは率直に書いておく。ボイス合成インターフェースの根拠は、厳格なミニマリズムの見本に対する一つのブラインドレビュー実験だけであり、README 自身が「worked example であって measured evidence ではない」と認めている。つまりこの機能は、sepia の中でも測定に裏打ちされていない部分である。references/voices/ 以下には Hemingway プロファイルが一つ同梱される。内容はフィクション向けの氷山理論的な省略と、プロ向け文章向けの Kansas City Star のルールで、各操作は出典に紐づけられる。組み込みプロファイルも同じ規則に従う。フィクションのレビューでは、テキストから記録された所見が Hemingway プロファイルに合致する場合にだけ報告し、何も読み込まない。強い De-AI を物語に対して求めること自体がオプトインとして扱われ、その場合 sepia はどのプロファイルを適用しているか、どう断るかを示す。ボイスの既知のコストは、修正して消すのではなく報告される。一方で均一性の所見は全力のまま残る。ボイスはメトロノームを免罪しない、というのが README の言い方である。
sepia が向かない場面と、代わりになる選択
sepia は語彙レベルの humanizer ではないので、単発の校正や言い回しの多様化だけをしたい用途には過剰である。また SKILL.md を読み込む経路が前提なので、Agent Skills 規格を解釈できない環境では、同梱のルーブリックやルールファイルを人手で読む以外に使い道がない。ラッパー単体のインストールが非対応である点も、既存のスキル管理に独自の仕組みを持つチームには摩擦になる。対照的な選択として、表層だけを扱う従来型の humanizer がある。こちらはパスが一つで済み、エージェントを介さずともテキストを貼れば結果が返る。差はどこを直すかに出る。従来型は語を置き換えるが、StoryScope が示した LAMP-edited 条件の下では、表層を人間が書き直しても検出率はほとんど下がらなかった。sepia はその数字を根拠に、より上流の因果や開示順序に手を入れる。逆に言えば、構造を触られたくない文章、たとえば事実関係が固定された法務文書や監査記録では、sepia の第一パスは害になりうる。README が用意するプロ向けルートはリリースノート、PR 返信、ポストモーテム、チケット、技術記事に限られており、それ以外の文書種別に対するルールファイルの存在は示されていない。
ライセンスと保守の見取り図
ライセンスは MIT で、リポジトリの LICENSE ファイルとバッジがそれを示す。MIT である以上、改変と再配布の条件は緩く、商用利用を禁じる条項もコピーレフトも含まれない。ただし同梱の research/ 以下に要約された研究や、references/voices/ の Hemingway プロファイルには、それぞれ原典の権利が別に存在しうる。ここは法的助言ではなく、導入時に自組織の法務に確認すべき論点として挙げておく。保守の面では、直近のリリースが v0.9.0、その前が v0.8.0 と v0.7.0 で、いずれも短い間隔で切られている。バージョン間隔が短いということは、ルーブリックやルールファイルの記述が動きやすいということで、プロンプトやルールを自前でフォークしていると差分の追従コストが発生する。リポジトリには behavioral-eval.yml と version-consistency.yml の二つの GitHub Actions ワークフローがあり、README のバッジはそれぞれ行動評価とバージョン整合性に対応する。バージョン整合性のワークフローが存在するのは、SKILL.md とプラグインパッケージの版ずれを防ぐ意図だと読める。
編集部の結論
採用を検討すべきなのは、AI 生成のフィクションや定型化した実務文書を日常的に扱い、Claude Code や Codex などの対応エージェントをすでに使っている書き手だ。逆に、対応エージェントを持たない環境や、単発の校正しかしない用途では、SKILL.md を読み込む経路そのものが無駄になる。導入前に確認すべきは、自分のエージェントが Agent Skills 規格を読めるか、そして wrapper 単体ではなく完全なプラグインパッケージとして入るかどうかの二点である。
コミュニティノート