スキルの口調をそろえる｜参照ファイルと2段の検査工程の作り方

「先週と同じ依頼をしたのに、返ってきた文章の感じが違う」。スキルを何本か動かしていると、この違和感が出てきます。

書いてある中身は合っている。事実の誤りもない。ただ、話し方だけが揺れている。社外へ出す文であれば、その揺れはそのまま媒体の印象になります。

この記事は、口調を参照ファイルとして書き出す手順と、公開の手前で止める検査工程の作り方を扱います。素材は公式ドキュメントの記載と、自社で動かしているスキルの実情です（2026-08-03時点）。

進行役は3人です。若葉さんが言葉の意味から聞き、高梨課長が自分の手で動かす側から聞きます。答えるのは鈴木さん（本誌監修）です。

01AIエージェントのスキルが出す文章は、なぜ実行のたびに口調がずれるんですか？

若葉さん

若葉さんの発言

同じスキルを呼んでいるはずなのに、返ってくる文章の感じが違うことがあります。わたしの呼び方が悪いんでしょうか。

鈴木さん

鈴木さんの発言

呼び方というより、机の上に開いておける資料の量の話に近いと思っています。作業が長引くと、古い資料から順に片づけられていく。そんな感じです。

Claude Codeの公式ドキュメントは、スキルが持てる参照コンテンツの一種として、規約やパターンと並べてスタイルガイドを挙げています（出典: Claude Code公式ドキュメント）。口調のルールをスキルに持たせること自体は、想定された使い方です。

ずれる原因は、ルールを書いていないことではありません。書いて読ませたものが、途中で手元から外れることです。会話が長く続いて自動要約が働くと、優先度の低い呼び出しから外れていきます（出典: Claude Code公式ドキュメント）。

つまり、読み込んだ直後の出力と、20往復ほど経った後の出力が同じ話し方だと決めつけないことになります。これが、参照ファイルとは別に検査工程を置く理由です。

02スキルの口調をブランドボイス統一へ寄せるのに、AIエージェントには何を持たせるんですか？

装置は2つです。読ませる参照ファイルと、公開前に判定する検査工程。効く場面が違うので、片方で両方をまかなうことはできません。

以降は、この2つを次の順で扱います。口調の参照ファイルをスキルに持たせる手順、口調のずれを公開前に止める検査工程の作り方、そして、できたかどうかを読者自身が判定する動作確認の方法です。

何をスキルにして、どう分割するかという設計判断は『AIエージェントのスキル設計｜呼ばれる単位に分ける4つの型』にまとめています。スキルが発火する条件そのものは『Claude Codeのスキルが発火しない｜descriptionを直す4層』で扱っています。本記事は、発火した後に生成する文章の口調という1つの品質軸だけを掘り下げます。

03口調の参照ファイルは、AI社員に任せるスキルへどう持たせるんですか？

高梨課長

高梨課長の発言

実際のところ、どこに何を書けばいいんでしょう。特別な権限を通す必要はありますか。

鈴木さん

鈴木さんの発言

権限は要りません。置く場所と、そこへ書ける状態があれば足ります。ただ、始める前に整えておくと迷わない準備が3つあります。

整えておくのは次の3つです。

• 対象のスキルが、すでにSKILL.mdとして存在すること
• 口調を統一したいシーンを2〜3個には切り分けられること（社外向けの告知文、問い合わせへの返信、社内向けの共有メモ、など）
• 参照ファイルと検査結果を置くディレクトリ名を決めていること

Anthropic公式は、スキルが持てるコンテンツの一種として「規約・パターン・スタイルガイド・ドメイン知識」を挙げています。この種の内容は、会話に沿って読み込まれます（出典: Anthropic公式）。口調のルールは、この参照コンテンツとして書きます。

新しくblog-post-drafterという、自社ブログの下書きを作るスキルを例にします。SKILL.mdの本文から、口調の参照ファイルを指し示します。

---
name: blog-post-drafter
description: 自社ブログ記事の下書きを、指定のテーマから生成する。ブログ記事を書きたいとき、下書きが欲しいときに使う。
---

# ブログ記事ドラフト作成

指定されたテーマで、ブログ記事の下書きを作る。

## 口調

出力の口調は references/voice-guide.md に従う。
書き終えたら、voice-guide.md の禁止表現チェックリストと突き合わせてから提示する。

指し示す先のreferences/voice-guide.mdには、抽象的な形容詞ではなく、OK・NG例文のペアを並べます（下記は説明用の架空の例文）。

# 口調ガイド（ブログ記事用）

## トーン
- 一文は60字を目安に区切る
- 断定より先に根拠を置く

## 禁止表現
- 「絶対に」「必ず」などの言い切り
- 二人称の命令形の多用

## OK例文・NG例文
- OK: 導入後、対応時間は平均3日短縮しました（自社実測）。
- NG: 導入すれば誰でも劇的に楽になります。

04OK例文とNG例文は、生成AIが書くスキルの口調にどこまで効くんですか？

Anthropic公式も、出力の質が見本に左右されるスキルでは、入出力の例を示す方が説明だけより明確に伝わると述べています（出典: Anthropic公式）。

たとえばblog-post-drafterが「導入すれば誰でも劇的に楽になります」という一文を出したとします。禁止表現の「誰でも」に一致するため、次の生成では「導入後、対応時間は平均3日短縮しました」のように、根拠つきの言い方へ置き換わることを期待します。

ただし、その置き換えが起きるかどうかは、参照ファイルを読ませただけでは分かりません。期待と結果は別ものです。確かめる場所は、この後の検査工程になります。

05参照ファイルを分ける目安は、AI活用のシーンが増えたときのスキル運用ですか？

シーンが増えたら、1つのファイルに詰め込まず、シーン別に分けます。Anthropic公式も、複数ドメインを扱うスキルでは、ドメインごとにファイルを分けて無関係な内容を読ませないことを勧めています（出典: Anthropic公式）。

voice-guide-external.mdとvoice-guide-internal.mdのように分ければ、余計な制約を持ち込みません。社内メモを読むときに、告知文向けの言い回し制約まで引きずらずに済みます。

分ける判断そのものは単純です。相手が変われば分ける。同じ相手にしか出さないなら分けない。それだけで足ります。

判断が単純でも、運用の本数が増えると話は変わります。自社で運用するスキルは2026-07-28時点で59本あり、この規模になると口調のズレを毎回目視で追う運用は成立しません。1本ずつ人力で読み比べる確認は、本数が増えるほど追いつかなくなります。

06検査工程の1段目は、AIエージェントのスキルが書いた文章から何を機械で見つけるんですか？

検査工程は、機械的な検知と、文脈を読む判定の2段に分けます。1段目は禁止表現の有無をスクリプトで検知し、2段目は書き手と別の文脈に置いたスキルが、全体の話し方を判定します。

高梨課長

高梨課長の発言

1段目は、具体的に何を動かすことになりますか。

鈴木さん

鈴木さんの発言

実行するだけの単純なチェックです。ここでは判断させません。当たった場所を教えてもらうところで、いったん止めます。

python3 scripts/check_voice.py draft.md references/voice-guide.md

このスクリプトは、禁止表現に一致した行番号と文字列だけを返し、良し悪しの判断はしません。判断ではなく検知に徹することで、結果は毎回同じになります。先ほどの「誰でも」であれば、行番号と一致文字列だけが返り、それ以上の解釈は加えません。

機械的な検知には限界もあります。禁止表現の一覧に無い言い回しは、そのまま通ります。「誰でも」は拾えても、遠回しに同じ意味を持つ新しい言い回しまでは拾えません。この隙間を、2段目の判定で埋めます。

07検査工程の2段目は、なぜ別のエージェントにスキルの出力を判定させるんですか？

2段目は、context: forkを付けたスキルとして作ります。Claude Codeの公式ドキュメントによると、この設定を付けたスキルは独立したサブエージェントとして動きます。会話の履歴は引き継ぎません（出典: Claude Code公式ドキュメント）。書き手と同じ文脈で自己採点させないための仕組みです。

---
name: voice-guide-check
description: 下書きの口調がvoice-guide.mdの基準を満たすかを判定する。記事や告知文の下書きができたときに使う。
context: fork
background: false
---

## 判定対象
$ARGUMENTS

## 判断基準
references/voice-guide.mdの禁止表現とOK例文に照らし、一致しない箇所を指摘する。

## 出力形式
- 判定: PASSまたはFAIL
- 理由: 該当箇所と、voice-guide.mdのどの項目に反するか

background: falseを付けているのは、判定が終わるまで公開の手前で待たせるためです。付けない場合、判定は裏側で進み、結果が戻る前に次の作業へ移ってしまいます（出典: Claude Code公式ドキュメント）。

判定結果は、たとえば「FAIL・理由：断定の言い切りが根拠なしに続いている・該当箇所は3段落目」のように、合否と場所と理由の3点を返す形にします。合否だけを返すと、書き手はどこを直せばよいか分からず、同じ理由で差し戻しが繰り返されます。

見つかった新しい禁止表現の候補は、その場限りで直すのではなく、voice-guide.mdの禁止表現リストへ足し戻します。そうしないと、同じ言い回しが次回また2段目まで進んでから見つかることになり、1段目の役割が育ちません。

公開前に検査で止めるという考え方自体は、この媒体の記事そのものの制作でも使われています。段階の中身は『AI記事の品質管理｜5段階で差し戻された15件と、漏れた数字』にまとめています。

08スキルの口調がブランドボイス統一からずれるのは、AI導入の現場で何が起きているからですか？

ずれ方には型があります。運用の現場で見かけるのは、次の3つです。

参照ファイルを最初に読ませただけで安心する

一度読み込んだスキルの内容は、そのまま会話に残り続けるわけではありません。自動要約が働くと、直近に呼んだスキルほど優先され、古い呼び出しは丸ごと落ちることがあります（出典: Claude Code公式ドキュメント）。長いセッションほど、途中でもう一度呼び直すか、検査工程で下支えする必要があります。

検査を同じ文脈のまま自己採点させる

書き手自身に「この下書き、ガイドに沿っていますか」と聞くと、直前まで自分が書いた理由づけごと肯定しがちです。context: forkで会話履歴を切り離し、判定材料を下書きと参照ファイルだけに絞ることで、この偏りを避けられます。

抽象的な形容詞だけで口調を定義する

「親しみやすく」「誠実に」といった形容詞は、実行のたびに解釈が割れます。前段の表で示したように、OK・NG例文のペアに置き換えるほうが、比較できる分だけずれが小さくなります。

09口調を守らせる仕組みができたかは、AIエージェントのスキルでどう確かめるんですか？

高梨課長

高梨課長の発言

できた、と言える基準はどこに置けばいいですか。

鈴木さん

鈴木さんの発言

わざと外れた下書きを流して、止まるかどうかを見ます。うまくいく例だけを試すと、何も判定していない状態を見逃します。

口調を守らせる仕組みができたかどうかは、次の3点で判定します。

2つ目のチェックが特に重要です。合格するケースだけを試すと、検査工程が実際には何も判定していない状態を見逃します。わざと違反させた下書きを用意し、FAILとその理由が返ることを確認してから、次に進みます。

10明日からAI社員のスキルの口調を整えるには、どこから手をつけるんですか？

手をつける順番は決まっています。書き出す、読ませる、確かめる。この順を入れ替えると、確かめる材料が無いまま運用だけが始まります。

まず、いま出ている出力から、避けたい言い回しを拾います。頭の中の理想像ではなく、実際に出た文章から拾うほうが早く決まります。次に、拾った言い回しを禁止表現として書き、対になるOK例文を添えます。最後に、わざと外れた下書きで検査工程を動かします。

順番を守ると、途中で止まっても手戻りが小さくなります。書き出しただけで終わっても、次に読ませるところから再開できます。逆に、確かめる工程を先に作っても、判定するよりどころが無いままでは動きません。

11よくある質問

12まとめ｜今日やる3つのこと