# AI Tone Check

> 大学業務文書 (広報原稿 / 研修教材 / 申請書 / 学生向け案内等) のドラフトを 読み取り、subagent dispatch で「AI 臭度」「業務文書適切性」「読者負荷」の 3 軸評価を返す。「この広報原稿、AI っぽくない？」「研修資料が硬すぎないか 気になる」「職員が書いたふうに仕上げたい」と問われた時に起動する。 mizchi-blog-style の評価ワークフローを大学業務文書向けに翻訳、職員 / 学生 / 学外読者の 3 ロールのいずれかで subagent がドラフトを読み、 冗長敬語 / 空虚強調 / 両論併記等を行番号付きで指摘する。反復改善は 呼び出し側判断、本 skill 自体はシングル実行。

- Skill: `gmoriki/ai-tone-check` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add gmoriki/ai-tone-check`
- Raw SKILL.md: https://api.skillmd.com/api/skills/gmoriki/ai-tone-check/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: CC BY-SA 4.0
- Author: gmoriki (https://skillmd.com/u/gmoriki)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/gmoriki/ai-tone-check

---


# ai-tone-check

大学業務文書のドラフトを subagent に読ませ、AI 臭度・業務文書適切性・読者負荷の 3 軸で評価する Task skill。`mizchi-blog-style` の評価ワークフローを大学業務文書向けに翻訳したもの。指摘は行番号付きで返す。反復改善は呼び出し側判断、本 skill は 1 回で完結する。

## いつ使うか

- 広報原稿 (Web / 広報誌 / プレスリリース) を公開前に最終チェックしたい時
- 研修配布資料 (職員研修 / 新任研修 / AI リテラシー研修) のトーンを確認したい時
- 学生向け FAQ / 窓口案内 / 履修ガイドの読みやすさを検証したい時
- AI で下書きさせた文面を「職員が書いたふう」に寄せたい時
- 「何かしっくり来ない」が言語化できない時 (指摘があれば改善しやすい)

使わない場面:
- 規程本文 / 契約書 / 法的文書 (定型表現の縛りが強い、本 skill の判定軸は不適)
- 学術論文 / 研究報告 (ジャンル固有のスタイル、別軸)
- 短文 (Twitter / Slack メッセージ等、評価の旨味がない)
- 本文に機密情報 (Level 2-3) を含むドラフト (subagent dispatch 前に `check-info-level` で判定、必要なら匿名化)

## What This Does

ユーザーが提示したドラフト (ファイルパスまたはテキスト) を読み取り、指定ロール (職員 / 学生 / 学外読者) の subagent を `Task` tool で 1 体 dispatch する。subagent は本 skill に定める 3 軸で採点し指摘 Top 5 を返す。親 skill は結果を整形してユーザーに提示する。

## Required Inputs

`$ARGUMENTS` として以下を受け取る:

- **第 1 引数 (必須)**: ドラフトのファイルパス、または本文テキスト
- **第 2 引数 (任意)**: 読者ロール `staff` / `student` / `public` のいずれか (省略時は `public` = 学外一般読者)

例:

```
/ai-tone-check /tmp/press-release-draft.md public
/ai-tone-check /tmp/training-material.md staff
```

引数空の場合: ガイダンスを返して終了。

## What It Produces

以下を構造化 Markdown で出力:

1. **総合スコア**: 3 軸各 0-10 点、合計 0-30
2. **軸別スコア**:
   - A. 業務文書適切性 (過度な口語 / 絵文字 / 軽口による減点)
   - B. AI 臭度 (冗長敬語 / 空虚強調 / 両論併記等の検出、少ないほど高得点)
   - C. 読者負荷 (1 文の長さ / 専門用語の説明 / 主語省略の曖昧さ)
3. **指摘 Top 5**: 行番号 + 引用 + 改善案 (subagent からの直抜粋)
4. **総評**: 1-2 段落でロール視点の読後感
5. **次のアクション候補**: ドラフト修正の優先順位 (最大 3 件)

反復は行わない。ユーザーが修正して再度 `/ai-tone-check` を呼ぶ流れを想定する。

## 手順

### 0. 実行環境チェック (起動直後の最初の動作)

本 skill は内部で `Task` tool を使って subagent を 1 体 dispatch する設計。top-level Claude Code セッションでは利用可能だが、既に subagent として起動している文脈 (親エージェントから Task dispatch された状態) では `Task` tool が注入されず、ネスト dispatch できない。

起動直後に以下を確認する:

- `Task` tool が利用可能か (tool インベントリ確認 / deferred tools での検索)
- 利用不可の場合、以下のメッセージを返して終了:

  ```
  本 skill は top-level Claude Code セッションから起動する設計です。
  現在のセッションは既に subagent 実行環境のため、内部 dispatch が
  できません。Claude Code のトップレベルで `/ai-tone-check` を
  直接呼んでください。
  ```

- 代替として親エージェント自身がロールプレイで代行する挙動は採らない。subagent バイアス排除が本 skill 設計の前提であり、代行すると評価値が信用できなくなるため、明示失敗の方が誠実

### 1. 入力種別の判定

`$ARGUMENTS` の第 1 引数を解析:

- ファイルパスらしき文字列 → ファイル処理へ
- それ以外 → 本文テキストとして扱う
- 引数空 → ガイダンスを返して終了

第 2 引数でロール指定を受ける。`staff` / `student` / `public` 以外は `public` にフォールバック。

### 2. 機密度チェック (事前防衛)

`check-info-level` 観点を自前で簡易確認:

- 本文に学籍番号らしき文字列 (`Y202X-XXXX` 形式等)、個人メールアドレス、氏名と役職の組合せが出ていないか
- 上記が検出された場合、dispatch 前に警告:「本文に機密情報が含まれる可能性があります。Level 判定を `/check-info-level` で先に行うことを推奨します。続行しますか？」
- ユーザー確認なしで続行しない (subagent 経路でも本文がログに残るため)

### 3. subagent dispatch

`Task` tool で新規 subagent を 1 体 dispatch。subagent_type は `general-purpose`。渡すプロンプトは下のテンプレートを `$ROLE` / `$DRAFT_REF` で埋めて使う:

````
あなたは大学業務文書のドラフトをレビューする読者です。今回のロール:
<$ROLE の説明>

## 対象ドラフト
<$DRAFT_REF>

## 評価観点 (3 軸、各 0-10 点)

### A. 業務文書適切性 (0-10)
大学公式利用に耐えるトーンか。以下を減点要素として評価:
- 過度な口語 (「めっちゃ」「シュッと」「〜っぽい」「〜っス」)
- 絵文字 / 顔文字 / 過剰な記号装飾 (❗️ ✨ 等)
- 軽口 / 読者いじり / 身内ノリ
- 個人名義の主観 (「筆者は〜」「私見では〜」— 大学広報の場合は特に NG)
- 商業コピー調 (「驚異の」「革命的」「遂に実現」)

- 10 点: 大学公式として出せるトーン
- 5 点: 読み物としては読めるが公式利用は要調整
- 0 点: 公式利用不可

### B. AI 臭度 (0-10、少ないほど高得点)
AI 生成文書の典型パターンを以下から検出:
- 冗長な丁寧表現 (「〜することができます」「〜することが重要です」)
- 空虚な強調語 (「素晴らしい」「画期的な」「革新的な」「重要な」)
- 両論併記の無意味な中立 (「〜という見方もあれば〜という見方もある」)
- 章冒頭の前章要約 (「前章では X について述べました。本章では...」)
- 一般論の締め (「重要なのはバランスです」「適切に使い分けましょう」)
- 過剰な箇条書き (文章で書けることを全部 bullet)
- 結論部の繰り返し (「以上、本記事では〜について解説しました」)
- 抽象的な仮想例 (「例えば、ある大学では〜という事例」— 実在の事例で置換すべき)
- 対称的な見出し階層 (すべての節に「概要 / 意義 / 方法 / まとめ」)
- 主語の一般化 (「一般的に〜とされている」「〜と言われている」)

- 10 点: 該当ゼロ
- 5 点: 該当 5-6 件
- 0 点: 該当 10 件以上

### C. 読者負荷 (0-10)
指定ロールの読者が読み通せるか:
- 1 文の長さ (60 字を超える文が連続していないか)
- 専門用語の説明 (初出時に注釈 / 言い換えがあるか)
- 主語省略の曖昧さ (「それ」「これ」の指示対象が明瞭か)
- 段落の論理接続 (前後の段落がつながっているか)
- 箇条書きと文章の混在が読み手を疲れさせないか

- 10 点: 指定ロールがスムーズに読める
- 5 点: 何度か読み返しが必要
- 0 点: 指定ロールにとって理解困難

## タスク

1. ドラフトを指定ロールの視点で通読する
2. 3 軸それぞれ 0-10 点で採点、根拠を該当行の引用で示す
3. 最も気になる指摘 Top 5 を行番号 + 引用 + 改善案 の形で抽出する
4. ロール視点での読後感を 1-2 段落で書く
5. 次に修正すべき優先順位 (最大 3 件) を提示する

## レポート構造

```
## 総合スコア: X/30

### 軸別
- A. 業務文書適切性: X/10 (内訳...)
- B. AI 臭度: X/10 (内訳...)
- C. 読者負荷: X/10 (内訳...)

### 指摘 Top 5
1. L<行番号>: "<引用>" → <改善案>
2. ...

### 総評
<1-2 段落、ロール視点での読後感>

### 次のアクション候補
1. <最優先の修正>
2. <2 番目>
3. <3 番目>
```
````

### 4. ロール別プロンプト調整

`$ROLE` に応じて subagent プロンプト冒頭の「ロール」欄を以下で埋める:

| $ROLE | ロール説明 |
|---|---|
| `staff` | 受講する大学職員 (事務職員 20-50 代、AI に触れた経験は個人差が大きい、情報セキュリティには敏感) |
| `student` | 読む学部学生 (1-4 年、日本語ネイティブ想定、大学の定型文言には不慣れ、スマートフォンで読む前提) |
| `public` | 大学 Web を訪問した学外読者 (受験生の保護者 / 地域住民 / 企業担当者など、大学特有の用語は前提にしない) |

### 5. 結果の整形

subagent が返したレポートを受け取り、ユーザーに以下の形式で提示:

```markdown
## AI Tone Check 結果

**ドラフト:** <path or "直接テキスト">
**ロール:** <staff / student / public>
**総合スコア:** X/30 (A: X/10, B: X/10, C: X/10)

### 指摘 Top 5
1. L<行番号>: "<引用>" → <改善案>
2. ...

### 総評
<subagent の総評をそのまま>

### 次のアクション候補
1. <優先 1>
2. <優先 2>
3. <優先 3>

---
※ 本 skill は単発実行。修正後の再評価が必要なら再度 `/ai-tone-check` を呼んでください。
```

## 品質基準

- 3 軸スコア + 指摘 Top 5 が必ず揃う (一部欠落で返さない)
- 指摘は行番号 + 引用 + 改善案の 3 要素揃い (「気をつける」等の曖昧な改善案は NG)
- 総評は指定ロール視点で書く (「学生として読むと」「職員として読むと」等の主語が必要)
- 機密情報検出時は dispatch 前に警告、ユーザー確認を取る
- subagent は使い捨て、同一セッション内で再利用しない (学習バイアス防止)

## 落とし穴

| 出てくる合理化 | 実態 |
|---|---|
| 「ロール指定なしで public 固定で OK」 | 職員向け研修資料を public で評価すると「専門用語が多い」と減点されるが、職員向けは専門用語 OK。ロールで評価軸の重み付けが変わる |
| 「スコアが 25/30 だから十分」 | スコアは参考、指摘 Top 5 の質を見る。スコア 25 でも致命的な指摘 (個人情報露出等) が 1 件あれば修正 |
| 「subagent の指摘を全部反映する」 | subagent は過剰反応することがある (大学広報で必要な定型表現を「空虚強調」と判定するケース等)。ユーザーが採用 / 棄却を判断 |
| 「反復評価を本 skill 内で回す」 | 本 skill はシングル実行設計。反復は呼び出し側 (ユーザー or 親 agent) 判断。複雑化させない |
| 「広報原稿にもカジュアルさを入れた方が学生に刺さる」 | 大学広報の公式性を崩すと所属 / 同僚 / 上司からの信頼に影響。読者負荷を下げる方法は他にある (1 文短縮、用語注釈、具体例追加) |
| 「AI 臭ゼロを狙う」 | AI 臭ゼロを追うと「大学らしい硬さ」まで削れる。B 軸 7-8/10 で十分、残る AI 臭は構造的に許容する |
| 「機密情報チェックは skip してよい、検査だけだから」 | subagent dispatch は本文をログに残す経路。Level 2-3 の情報が含まれていたら事前匿名化が必須 |
| 「Task tool が使えないから、親が代わりにロールプレイで採点すればいい」 | subagent バイアス排除が本 skill の前提。親エージェントが自分で評価を書くと、自分の指摘を自分で採点することになり結果が信用できない。Task tool 不可なら明示失敗して top-level 再起動を促す方が正解 |

## Available Tools

- **Read**: ドラフトファイルの読み込み
- **Task**: subagent dispatch (`general-purpose` 型を 1 体)

## 関連

- [`skills/check-info-level/`](../check-info-level/SKILL.md) — dispatch 前の機密度チェックに使用
- [`skills/staff-ai-literacy-primer/`](../staff-ai-literacy-primer/SKILL.md) — 職員研修教材の内容検討、本 skill はトーン検査、staff-ai-literacy-primer は内容設計
- [`references/skill-format-guide.md`](../../references/skill-format-guide.md) — v0.6 標準形式、本 skill の準拠先
- `mizchi-blog-style` (外部) — 本 skill の評価ワークフロー参照元、mizchi 個人 blog 文体を判定するもの
- `empirical-prompt-tuning` (外部) — subagent dispatch + 両面評価のメタスキル、反復改善を行うならこちら