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 が返したレポートを受け取り、ユーザーに以下の形式で提示:

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