AIっぽさを直す例
AIっぽさを直すの手順を、下書きから書き直したあとの確かめまで通した例を 3 つ載せます。どの文書もこのページのために書いたもので、画面はどれも chaff が実際に出したものです。
| 例 | 直し方 | 見られること |
|---|---|---|
| 直す計画から書き直して確かめる | 全面 | chaff fix-plan の計画、書き直し、計画にある 3 つの確かめ |
| 技術記事を節ごとに書き直す | 節ごと | 構成を残して節の文を書き直し、compare と ai-score で確かめる |
| ブログ記事を全面的に書き直す | 全面 | 控え、先に見せる新しい構成、書き直し、前後の outline と compare |
直す計画から書き直して確かめる
生成文の書きぶりで書いた短い記事を、chaff fix-plan の計画に沿って直した例です。どちらの文書も、このページのために書いたものです。
書き直す前の記事です（draft.md）。
# 夜間バッチの失敗を通知するまで
現代社会において、夜間バッチは業務を支える重要な役割を果たすと言えるでしょう。本記事では、私たちのチームが夜間バッチの失敗に気づけるようにした取り組みについて、深く掘り下げていきます。
重要なのは、失敗が単なるエラーではなく、業務の止まる合図だという点です。以前の夜間バッチは、ディスクが一杯になると静かに壊れる作りでした。朝になって売上の集計が空だと気づき、原因の調査に毎回半日ほど時間を溶かしていました。
さらに、ログは 7 日で消える設定でした。加えて、失敗してもバッチは終了コード 0 を返していました。このように、気づく手がかりがどこにもなかったのです。
そこで 2026 年 4 月に三つの変更を入れました。終了コードを正しく返すようにし、失敗したら Slack の #batch-alerts に通知を送り、ログの保存期間を 30 日に延ばしました。変更後の三か月で失敗は 4 回あり、どれも始業前に気づけています。
いかがでしたか？夜間バッチの監視は地味に効く改善です。参考になれば幸いです。chaff fix-plan が出した計画です。最初のルールより後は略しています。
$ npx chaffjs fix-plan draft.md
# 直す計画: draft.md
言語 ja、ジャンル blog/tech
chaff が機械で見つけた箇所と、それぞれの直す方向です。chaff は書き直しません。書き直すのは、この計画を読む人か AI です。直したら、最後の確かめのコマンドを実行してください。
## 守ること
1. 事実、数、日付、条件、名前を変えない。
2. 元の文書に無い事実、人、数、原因、例を足さない。
3. 直すのに文書に無い具体（誰が、いつ、どれだけ）が要るときは、作らずに［ ］で空けて書き手に聞く。
4. 書き直しは 2 回まで。指摘を消すためだけに書き直しを繰り返さない。
## 勧める直し方: 全面書き直し（Full）
ブログやエッセイは、構成から書き直すほうが書き手の望みに合います。
書き直しの深さ: structure（節・見出し・段落を組み替える）。
- 軽く直す（深さ light）: 指摘された箇所だけ。
- 大胆に直す（深さ light）: 見出しの構成は残し、節ごとに文を書き直す。
- 全面書き直し（深さ structure）: 事実と主張を控えてから、構成から書き直す。頼まれた内容が「全面的に」「一から」なら、これを選ぶ。
- 文体を変える（深さ register）: 全面書き直しに加えて、文体も変える（です・ます → である など）。chaff からは勧めません。--depth register で選びます。
## 文書全体の目印
- `ai-tell`: 「現代社会において、重要な役割を果たす、と言えるでしょう、深く掘り下げる、本記事では、地味に効く、時間を溶かす、静かに壊れる」が揃っています（点 47、18 まで）
- `closing-cliche`: 「いかがでしたか」で締めています
- 構成: 見出し 1、節の平均 434 字、箇条書き 0%、太字 0
## 構成の目標
構成の AI らしさ: 0（人の記事の 9 割を超えた項目の数。比べた 3 項目のうち）。3 以上なら構成から書き直します。
構成の項目は、どれも人の記事の範囲にあります。
## ルールごとの直し方
### `ai-tell` 生成文にありがちな言い回し
**直す方向**: 決まった言い回しを、その文が実際に言っている中身（誰が、何を、どれだけ）に置き換えてください。中身の無い文は消してください。
**変えないもの**
- 数字、日付、名前、条件
- 書き手の確かさ（言い切りか、推量か）
**やりがちな間違い**
- 書き手が書いていない例や数字を作る
- 決まり文句を別の決まり文句に替える（「重要な役割を果たす」を「欠かせない存在だ」に）
- どの段落も同じ形に書き揃える
**例**
前:
> 現代社会において、在庫データは発注の判断で重要な役割を果たしています。
後:
> 発注は在庫データを見て決めています。
**言い回しごとの手がかり**
- 「現代社会において」 → 消して、本題から書く
- 「重要な役割を果たす」 → 何をするのかを書く（「発注の判断に使う」）
- 「と言えるでしょう」 → 言い切れるなら「です」。言い切れないなら、何が分かれば言えるのかを書く
- 「深く掘り下げる」 → 説明する
- 「地味に効く」 → 何に、どれだけ効いたのかを書く
- 「時間を溶かす」 → 時間がかかった（何に、どれだけ）
- 「静かに壊れる」 → エラーを出さずに失敗する
**見つけた箇所**
- 3 行目: 「現代社会において、夜間バッチは業務を支える重要な役割を果たすと言えるでしょう。」
「現代社会において、重要な役割を果たす、と言えるでしょう、深く掘り下げる、本記事では、地味に効く、時間を溶かす、静かに壊れる」が揃っています（点 47、18 まで）
…
## 動かなかったルール
試験中のルールは動かしていません。--experimental を付けると見ます。
- `abstract-length`: ジャンル blog/tech では見ないため
- `adverb-without-negation`: ジャンル blog/tech では見ないため
- `agentless-passive`: ジャンル blog/tech では見ないため
- `ai-structure`: 表題より下の見出しが無いため
- `attachment-not-attached`: ジャンル blog/tech では見ないため
- `citation-reference-mismatch`: ジャンル blog/tech では見ないため
- `citation-style-mix`: ジャンル blog/tech では見ないため
- `colloquial-opener`: ジャンル blog/tech では見ないため
- `cushion-phrase-density`: ジャンル blog/tech では見ないため
- `defined-name-repeated`: ジャンル blog/tech では見ないため
- `defined-term-form`: ジャンル blog/tech では見ないため
- `email-greeting-closing`: ジャンル blog/tech では見ないため
- `email-subject-length`: ジャンル blog/tech では見ないため
- `figure-reference-order`: ジャンル blog/tech では見ないため
- `obligation-without-deadline`: ジャンル blog/tech では見ないため
- `party-order`: ジャンル blog/tech では見ないため
- `party-role-name`: ジャンル blog/tech では見ないため
- `request-without-deadline`: ジャンル blog/tech では見ないため
- `toki-as-condition`: ジャンル blog/tech では見ないため
- `undefined-term`: ジャンル blog/tech では見ないため
- `vague-deadline`: ジャンル blog/tech では見ないため
- `yori-as-from`: ジャンル blog/tech では見ないため
## 直したあとの確かめ
書き直したものを draft.rewritten.md に保存して、次を実行します。
```bash
npx chaffjs draft.rewritten.md
npx chaffjs compare draft.md draft.rewritten.md --distinct --allow-dropped heading --allow-added heading
npx chaffjs outline draft.md draft.rewritten.md
```
1 つめは書き直した文書の指摘、2 つめは事実が落ちていないか・足されていないか、3 つめは構成の変化です。数は chaff の出力から取り、形容詞で言わないでください。計画は全面書き直しを勧めています。理由は、ジャンルが blog/tech（ブログ）だからです。「言い回しごとの手がかり」に沿って、「静かに壊れる」は「エラーを出さずに失敗する」に、「時間を溶かす」は「時間がかかった」にしました。「現代社会において」で始まる書き出しと「いかがでしたか」の結びは、中身が無いので消しました。
書き直した記事です（draft.rewritten.md）。
# 夜間バッチの失敗を通知するまで
以前の夜間バッチは、ディスクが一杯になるとエラーを出さずに失敗していました。朝になって売上の集計が空だと気づき、原因の調査に毎回半日ほどかかっていました。
失敗してもバッチは終了コード 0 を返し、ログは 7 日で消える設定でした。失敗に気づく手がかりが残らなかったのです。
2026 年 4 月に三つの変更を入れました。終了コードを正しく返すようにし、失敗したら Slack の #batch-alerts に通知を送り、ログの保存期間を 30 日に延ばしました。変更後の三か月で失敗は 4 回あり、どれも始業前に気づけています。計画の確かめのコマンドを実行した結果です。
$ npx chaffjs draft.rewritten.md --compact
draft.rewritten.md blog/tech · 日本語 ジャンルは既定から
指摘 0 件、動いていない rule 60 件$ npx chaffjs compare draft.md draft.rewritten.md --distinct --allow-dropped heading --allow-added heading
draft.md → draft.rewritten.md
照合した事実 12 件 → 12 件: 数 8→8、日付 1→1、時刻 0→0、URL 0→0、コード 0→0、固有名詞 2→2、引用 0→0、見出し 1→1、条項の参照 0→0、脚注 0→0
落ちた事実も足された事実もありません$ npx chaffjs outline draft.md draft.rewritten.md
draft.md の構成: 見出し 1、節の平均 434 字、箇条書き 0%、太字 0
# 夜間バッチの失敗を通知するまで (draft.md:1) 434 字
構成の AI らしさ: 0（人の記事の 9 割を超えた項目の数。比べた 3 項目、人の記事 2779 本と比べて）
· 人の記事でふつう: 3 つの小見出しに分けた見出し 0 か所、太字の見出しで始まる項目 0 項目、絵文字の付いた見出し 0 個
測っていない: 見出しの多さ（文書が短い）、1〜2 段落の節（中身のある節が少ない）、節の長さのばらつき（中身のある節が少ない）、決まった形の見出し（見出しが少ない）、はじめに・まとめの見出し（見出しが少ない）、まとめが本文を言い直す割合（まとめの節が無い）、3 項目の箇条書き（箇条書きが 3 つ未満）、メリットとデメリットの対（見出しが少ない）
draft.rewritten.md の構成: 見出し 1、節の平均 249 字、箇条書き 0%、太字 0
# 夜間バッチの失敗を通知するまで (draft.rewritten.md:1) 249 字
構成の AI らしさ: 0（人の記事の 9 割を超えた項目の数。比べた 3 項目、人の記事 2779 本と比べて）
· 人の記事でふつう: 3 つの小見出しに分けた見出し 0 か所、太字の見出しで始まる項目 0 項目、絵文字の付いた見出し 0 個
測っていない: 見出しの多さ（文書が短い）、1〜2 段落の節（中身のある節が少ない）、節の長さのばらつき（中身のある節が少ない）、決まった形の見出し（見出しが少ない）、はじめに・まとめの見出し（見出しが少ない）、まとめが本文を言い直す割合（まとめの節が無い）、3 項目の箇条書き（箇条書きが 3 つ未満）、メリットとデメリットの対（見出しが少ない）
構成の変化（draft.md → draft.rewritten.md）
見出し: 1 → 1
節の平均: 434 字 → 249 字
箇条書き: 0% → 0%
太字: 0 → 0
構成の AI らしさ: 0 → 0
3 つの小見出しに分けた見出し: 0 か所 → 0 か所
太字の見出しで始まる項目: 0 項目 → 0 項目
絵文字の付いた見出し: 0 個 → 0 個最初に書き直したときは、「三つの変更」の「三つ」を落とし、元に無い「理由は二つあります」を足していました。
compare がそれを見つけた結果です。
draft.md → draft.rewritten.md
✗ 落ちた事実 1 件（draft.md にあって draft.rewritten.md に無い）
数: 三つ (draft.md:9)
✗ 足された事実 1 件（draft.rewritten.md にだけある）
数: 二つ (draft.rewritten.md:5)
照合した事実 12 件 → 12 件: 数 8→8、日付 1→1、時刻 0→0、URL 0→0、コード 0→0、固有名詞 2→2、引用 0→0、見出し 1→1、条項の参照 0→0、脚注 0→0
落ちた事実 1 件、足された事実 1 件「二つ」は書き手が言っていない数です。消して、「三つの変更を入れました」を戻しました。上の結果は、その後にかけたものです。
技術記事を節ごとに書き直す
生成文の書きぶりで書いた技術記事を、節ごとの書き直しで直した例です。どちらの文書も、このページのために書いたものです。
書き直す前の記事です（ai.md）。
# CI のテストがたまに落ちる問題を解決した話——時差という見えない罠
本記事では、CI でだけテストが不安定になる問題について、原因の特定から修正までを詳しく解説していきます。
## 何が起きていたのか
社内の在庫管理 API のテストが、CI でだけ**約 30 回に 1 回**落ちていました。手元では再現しません。
これは単なる不安定なテストではありません。**チームの時間を静かに奪う問題**です。
正直に言うと、私たちは三週間この問題を放置していました。再実行すれば通るからです。
しかし、再実行は 1 回 12 分。これが地味に効いてきます。気づけば時間を溶かしていました。
## 原因の調査
ポイントは、落ちた回のログを並べることです。
調査で分かったことは次の通りです：
- 落ちた回は**すべて日本時間の 0 時〜9 時**に実行されていた
- CI のランナーは **UTC** で動いている
- テストは `new Date()` で今日の日付を取り、期日を「今日から 7 日後」として計算していた
つまり、日本時間では月曜でも、ランナーの上ではまだ日曜だったのです。
重要なのは、エラーが黙って無視されていたことです。日付のずれは例外を出さず、テストは静かに壊れていました。
## 解決策
修正は以下の 3 つです：
- **テスト**：`jest.useFakeTimers` と `setSystemTime` で時刻を固定
- **ワークフロー**：`TZ=Asia/Tokyo` を追加
- **本番コード**：`Intl.DateTimeFormat` に `timeZone: "Asia/Tokyo"` を渡して日付の境目を決定
さらに、本番コードまで直したことが鍵となります。テストだけでなく、本番のサーバーが UTC で動いた場合にも備える必要があるからです。
## 結果
修正後の二週間、このテストは**一度も**落ちていません。
## まとめ
時刻に依存するテストは、単なるバグではなく、環境そのものの問題です。不安定なテストを一つずつ潰していくことが、チームの生産性を大きく向上させる鍵となるでしょう。
いかがでしたでしょうか。この記事が皆さんのお役に立てれば幸いです。書き直す前に chaff をかけた結果です。
$ npx chaffjs ai.md --genre blog/tech --compact
ai.md blog/tech · 日本語 ジャンルは --genre から
3:1 info 「詳しく解説していきます、鍵となる、本記事では、地味に効く、効いてくる、時間を溶かす、一つずつ潰す、静かに壊れる、黙って無視される」が揃っています（点 39、18 まで）
ai-tell
3:1 warning 「ai-tell、closing-cliche、contrast-framing、announcing-opener、colon-lead-in」が同じ文書にそろっています（5 種、3 種から）
ai-generated-composite
9:1 info 「単なる」など、対比の枠が 1000 字あたり 4.4 個あります（1.5 個まで）
contrast-framing
11:1 info 「正直に言うと」など、予告で始まる文が 3 個あります（3 個から）
announcing-opener
17:1 info 「ポイントは」など、予告で始まる文が 3 個あります（3 個から）
announcing-opener
19:1 info コロンで箇条書きへ渡す文が 1000 字あたり 2.9 個あります（2 個まで）
colon-lead-in
27:1 info 「重要なのは」など、予告で始まる文が 3 個あります（3 個から）
announcing-opener
31:1 info コロンで箇条書きへ渡す文が 1000 字あたり 2.9 個あります（2 個まで）
colon-lead-in
37:25 info 「だけでなく」など、対比の枠が 1000 字あたり 4.4 個あります（1.5 個まで）
contrast-framing
45:1 info 「単なる」など、対比の枠が 1000 字あたり 4.4 個あります（1.5 個まで）
contrast-framing
47:1 warning 「いかがでしたでしょうか」で締めています
closing-cliche
47:13 warning 「お役に立てれば幸いです」で締めています
closing-cliche
指摘 12 件、動いていない rule 59 件書き直した後の記事です（rewritten.md）。
# CI のテストがたまに落ちる問題は時差が原因だった
社内の在庫管理 API のテストが、CI でだけ約 30 回に 1 回落ちていました。手元では再現しません。この記事では、原因を突き止めて直すまでを書きます。
## 何が起きていたのか
三週間ほど、私たちはこの問題を放っておきました。再実行すれば通ったからです。ただ、再実行には 1 回 12 分かかり、その待ち時間が積み重なっていきました。
## 原因の調査
落ちた回のログを並べると、すべて日本時間の 0 時から 9 時に実行されていました。CI のランナーは UTC で動いています。テストは `new Date()` で今日の日付を取り、期日を「今日から 7 日後」として計算していたので、日本時間では月曜でも、ランナーの上ではまだ日曜でした。
日付がずれても例外は出ないので、エラーとして表に出ることはありませんでした。
## 直したこと
直したことは 3 つあります。テストでは `jest.useFakeTimers` と `setSystemTime` で時刻を固定し、ワークフローには `TZ=Asia/Tokyo` を足しました。本番のコードも、`Intl.DateTimeFormat` に `timeZone: "Asia/Tokyo"` を渡して日付の境目を決めるように変えています。テストだけ直しても、本番のサーバーが UTC で動けば同じずれが起きるからです。
## 結果
直してからの二週間、このテストは一度も落ちていません。時刻に触るテストは、走る時間と場所で結果が変わります。たまに落ちるテストを見つけたら、まず落ちた時刻を並べてみてください。書き直した後に chaff をかけた結果です。
$ npx chaffjs rewritten.md --genre blog/tech --compact
rewritten.md blog/tech · 日本語 ジャンルは --genre から
1:28 info 節の長さのばらつきが 32% しかありません（35% 以上ほしい）
section-length-uniformity
指摘 1 件、動いていない rule 59 件変えたことと、その理由です。
| 変えたこと | 理由 |
|---|---|
| 題の「——時差という見えない罠」を消し、原因を題にしました | 予告ではなく、分かったことを題にするためです |
| 「本記事では〜詳しく解説していきます」を、記事が書くことの一文にしました | 決まり文句の書き出しで、中身がありません |
| 太字をすべて外しました | 数と事実だけで伝わり、強調する語がありません |
| 「単なる不安定なテストではありません」の対比を消しました | 誰も言っていない X を打ち消していました |
| 「正直に言うと」「ポイントは」「重要なのは」を消しました | 予告をやめ、中身から書き始めるためです |
| 「地味に効いてきます」「時間を溶かしていました」を「待ち時間が積み重なっていきました」にしました | 比喩をやめ、起きたことを書くためです |
| 「黙って無視されていた」「静かに壊れていました」を「例外は出ない」と言い換えました | 何が起きたのかを書くためです |
| 2 つの箇条書きを文に戻しました | 原因は 3 つの事実の繋がりで、並べるだけでは繋がりが書けません |
| 「いかがでしたでしょうか」「お役に立てれば幸いです」を消しました | 締めの決まり文句です |
数（30 回に 1 回、三週間、12 分、二週間）、コマンド、設定の値はすべて残しています。書き直した後に残った section-length-uniformity は、節の長さが揃っていることを言っています。中身のある節を足すと事実を足すことになるので、そのままにしました。
最後に、事実が落ちていないかを chaff compare で確かめた結果です。
$ npx chaffjs compare ai.md rewritten.md
ai.md → rewritten.md
✗ 落ちた事実 2 件（ai.md にあって rewritten.md に無い）
見出し: まとめ (ai.md:43)
数: 一つ (ai.md:45)
i 書き方だけ変わった事実 2 件
見出し: CI のテストがたまに落ちる問題を解決した話——時差という見えない罠 → CI のテストがたまに落ちる問題は時差が原因だった (1 行目 → 1 行目)
見出し: 解決策 → 直したこと (29 行目 → 15 行目)
照合した事実 33 件 → 30 件: 数 12→11、日付 0→0、時刻 0→0、URL 0→0、コード 6→6、固有名詞 8→7、引用 1→1、見出し 6→5、条項の参照 0→0、脚注 0→0
落ちた事実 2 件、足された事実 0 件最初にかけたときは、「修正は以下の 3 つです」の「3 つ」も落ちていました。書き直しで箇条書きを文に戻したときに、数を言う文が消えていたためです。「直したことは 3 つあります。」を足して戻し、もう一度かけた結果が上のものです。残った 2 件は、事実ではないので戻していません。
| 落ちた事実 | 戻さなかった理由 |
|---|---|
| 見出し「まとめ」 | 締めの決まり文句と一緒に、節ごと消しました |
| 数「一つ」 | 「一つずつ潰していく」という比喩の一部で、数ではありません |
この書き直しでは、見出しの構成はほとんど動いていません。npx chaffjs outline ai.md rewritten.md で測ると、見出しは 6 から 5 に減っただけです。構成から変えたいときは、次の例のように全面書き直しを選びます。
AI らしさの簡易判定（ai-score）で、書き直す前と後を比べます。
$ npx chaffjs ai-score ai.md rewritten.md --genre blog/tech
ai.md
AI らしさ: 高（人が書いた文書（ブログ）と比べて目印が多い）
目印 7 個（比べた 28 項目のうち、人の文書の 9 割には出ないもの）。中は 3 個から、高は 5 個から
※ 書いたのが AI かどうかの判定ではありません。生成文に多い目印が、人の文書と比べてどれだけ出ているかです。
言い回しと形
✗ 生成文にありがちな言い回し: 1 件 人が書いた文書（ブログ）23 本のうち 0 本
✗ 予告で始まる文が多い: 3 件 人が書いた文書（ブログ）23 本のうち 0 本
✗ 定型の結び: 2 件 人が書いた文書（ブログ）23 本のうち 0 本
✗ コロンで箇条書きへ渡す文が多い: 2 件 人が書いた文書（ブログ）14 本のうち 0 本
✗ 対比の枠が多い: 3 件 人が書いた文書（ブログ）23 本のうち 0 本
✗ 生成文の特徴がそろっている: 5 種（生成文にありがちな言い回し、定型の結び、対比の枠が多い、予告で始まる文が多い、コロンで箇条書きへ渡す文が多い）。厳しめの段階の 2 種から、目印 1 個に数えます
· ほかの 16 項目は出ていません
構成（人の記事と比べて）
✗ 太字の見出しで始まる項目: 3 項目 人の記事の 95% より多い
· ほかの 9 項目は人の記事でふつうの値です
rewritten.md
AI らしさ: 低（人が書いた文書（ブログ）と比べて同じくらい）
目印 1 個（比べた 27 項目のうち、人の文書の 9 割には出ないもの）。中は 3 個から、高は 5 個から
※ 書いたのが AI かどうかの判定ではありません。生成文に多い目印が、人の文書と比べてどれだけ出ているかです。
言い回しと形
✗ 節の長さが揃いすぎている: 1 件 人が書いた文書（ブログ）23 本のうち 0 本
· ほかの 20 項目は出ていません
構成（人の記事と比べて）
✗ 節の長さのばらつき: 32% 人の記事の 95% より揃っている（「節の長さが揃いすぎている」と同じ形なので 1 つに数えます）
· ほかの 8 項目は人の記事でふつうの値です書き直す前は、言い回しの目印が 5 つと、太字の札の構成が人の記事から外れて「高」です。書き直した後に残った目印は、節の長さの揃い方だけで「低」です。どちらも、書いたのが誰かは言っていません。
ブログ記事を全面的に書き直す
生成文の書きぶりで書いたブログ記事を、全面書き直しで直した例です。どちらの文書も、このページのために書いたものです。
書き直す前の記事です（study.md）。
# 社内勉強会を半年続けて見えてきた、本当に大切なこと——継続の秘訣とは
本記事では、私たちのチームが半年間続けてきた社内勉強会について、その取り組みと学びを詳しく解説していきます。
## はじめに
エンジニアにとって、学び続けることは非常に重要です。技術の進化は速く、昨日の常識が今日には古くなっています。
そこで私たちは、2025年10月に社内勉強会を始めました。
## 勉強会の概要
勉強会の概要は以下の通りです：
- **頻度**：毎週木曜日 17:00〜17:30
- **参加者**：開発チームの 12 人
- **形式**：1 人が 15 分話し、残りの時間で質疑
## 直面した課題
### 参加者が減った
始めて 2 か月で、参加者は 5 人に減りました。これは単なる忙しさの問題ではありません。**勉強会の価値が伝わっていない**という問題です。
### 話す人が偏った
最初の 8 回のうち 6 回は、同じ 2 人が発表していました。
### 内容が業務と離れていた
取り上げた題材の多くは、Rust や新しいフレームワークなど、日々の業務では使わない技術でした。
## 実施した改善策
ポイントは、続けられる形に作り替えることです。改善策は次の通りです：
### 題材を業務から選ぶ
**発表の題材を、その週に詰まったことに限定しました。** たとえば、本番で起きた障害の振り返りや、レビューで指摘が多かった書き方です。
### 発表を短くする
**発表を 5 分に縮めました。** 準備の負担が減り、発表した人は半年で 9 人になりました。
### 記録を残す
**発表の内容を Notion に残すようにしました。** 欠席した人も後から読めます。
## 結果
さらに、これらの改善によって、参加者は 11 人に戻りました。重要なのは、数字だけではありません。チームの雰囲気そのものが変わったことです。
正直に言うと、ここまで効果が出るとは思っていませんでした。
## 学んだこと
学んだことは以下の通りです：
- **継続には仕組みが必要**：意志だけでは続きません
- **小さく始めることが鍵**：短い発表なら誰でも話せます
- **業務とのつながりが大切**：役に立つと分かれば人は集まります
## まとめ
本記事では、社内勉強会を半年続けた経験から、継続のためのポイントを紹介しました。継続には仕組みが必要であり、小さく始めることが鍵であり、業務とのつながりが大切です。勉強会は単なる学びの場ではなく、チームの成長において重要な役割を果たす場なのです。
いかがでしたでしょうか。この記事が、皆さんのチームで勉強会を始めるきっかけになれば幸いです。書き直す前の chaff の結果です。ai-generated-composite が出ているので、全面書き直しを選びます。
$ npx chaffjs study.md --genre blog/tech --compact
study.md blog/tech · 日本語 ジャンルは --genre から
5:1 info 構成の 3 項目が、人の記事の 9 割を超えています（3 項目から）。見出しの多さ、3 つの小見出しに分けた見出し、太字の見出しで始まる項目
ai-structure
5:1 warning 「closing-cliche、contrast-framing、announcing-opener、colon-lead-in、ai-structure」が同じ文書にそろっています（5 種、3 種から）
ai-generated-composite
7:1 warning 「非常に重要」は、中身を言わずに強調だけしています
empty-intensifier
13:1 info コロンで箇条書きへ渡す文が 1000 字あたり 2.3 個あります（2 個まで）
colon-lead-in
15:1 info 「頻度」など、太字の札で始まる項目が 6 個あります（5 個から）
bold-label-list
23:26 info 「単なる」など、対比の枠が 1000 字あたり 3.5 個あります（1.5 個まで）
contrast-framing
35:1 info 「ポイントは」など、予告で始まる文が 3 個あります（3 個から）
announcing-opener
51:32 info 「重要なのは」など、予告で始まる文が 3 個あります（3 個から）
announcing-opener
51:32 info 「だけではありません」など、対比の枠が 1000 字あたり 3.5 個あります（1.5 個まで）
contrast-framing
53:1 info 「正直に言うと」など、予告で始まる文が 3 個あります（3 個から）
announcing-opener
57:1 info コロンで箇条書きへ渡す文が 1000 字あたり 2.3 個あります（2 個まで）
colon-lead-in
65:83 info 「単なる」など、対比の枠が 1000 字あたり 3.5 個あります（1.5 個まで）
contrast-framing
67:1 warning 「いかがでしたでしょうか」で締めています
closing-cliche
指摘 13 件、動いていない rule 59 件控えを取ります。npx chaffjs facts study.md の一覧には、数 11 件、日付 1 件、時刻 2 件、固有名詞 2 件（Rust、Notion）、見出し 14 件が並びます。書き手の主張と経験は、一行に一つずつ書き出します。
- 始めて 2 か月で、参加者が減った
- 発表する人が、同じ 2 人に偏っていた
- 題材が、日々の業務から遠かった
- 題材をその週に詰まったことにし、発表を短くし、Notion に残したら、人が戻った
- ここまで変わるとは思っていなかった
元の構成です。
$ npx chaffjs outline study.md
study.md の構成: 見出し 14、節の平均 67 字、箇条書き 15%、太字 10
# 社内勉強会を半年続けて見えてきた、本当に大切なこと——継続の秘訣とは (study.md:1) 54 字
## はじめに (study.md:5) 83 字
## 勉強会の概要 (study.md:11) 67 字
## 直面した課題 (study.md:19) 0 字
### 参加者が減った (study.md:21) 63 字
### 話す人が偏った (study.md:25) 26 字
### 内容が業務と離れていた (study.md:29) 47 字
## 実施した改善策 (study.md:33) 34 字
### 題材を業務から選ぶ (study.md:37) 63 字
### 発表を短くする (study.md:41) 39 字
### 記録を残す (study.md:45) 37 字
## 結果 (study.md:49) 97 字
## 学んだこと (study.md:55) 88 字
## まとめ (study.md:63) 169 字
構成の AI らしさ: 3（人の記事の 9 割を超えた項目の数。比べた 10 項目、人の記事 2779 本と比べて）
✗ 見出しの多さ: 1000 字あたり 15 人の記事の 95% より多い（人の中央 4.3、上から 1 割の境 10.2）
· 1〜2 段落の節: 100%（平均 1.3 段落） 人の記事の 85% より多い
· 節の長さのばらつき: 54% 人の記事の 70% より揃っている
✗ 3 つの小見出しに分けた見出し: 2 か所 人の記事の 90% より多い（人の中央 0、上から 1 割の境 1）
· はじめに・まとめの見出し: 2（前と後） 人の記事の 75% より多い
· まとめが本文を言い直す割合: 27%（「まとめ」） 人の記事の 70% より多い
✗ 太字の見出しで始まる項目: 6 項目 人の記事の 95% より多い（人の中央 0、上から 1 割の境 0）
· 人の記事でふつう: 決まった形の見出し 0%、絵文字の付いた見出し 0 個、メリットとデメリットの対 0 組
測っていない: 3 項目の箇条書き（箇条書きが 3 つ未満）構成の AI らしさは 3 で、見出しの多さ、3 つに分けた小見出し、太字の札の 3 項目が人の記事の 9 割を超えています。fix-plan の「構成の目標」も、この 3 項目を挙げます。見出しが 14 あり、本文の無い見出し（「直面した課題」）もあります。課題が 3 つ、改善策が 3 つ、学んだことが 3 つと、3 点の対称が続きます。「まとめ」は「学んだこと」を言い直しているだけです。書く前に見せた新しい構成は、次のとおりです。
| 元の構成 | 新しい構成と、その節に書くこと |
|---|---|
| はじめに、勉強会の概要 | 題「社内勉強会は、発表を短くしたら人が戻ってきた」の下に見出しを置かず、始めた時期と形と、人が減ったことを書く |
| 直面した課題（3 つの小見出し） | 「人が減ったのは、話が遠かったから」。話す人の偏りと題材の遠さを、一つの理由として書く |
| 実施した改善策（3 つの小見出し）、結果 | 「その週に詰まったことを、短く話す」。題材、発表の長さ、記録を一続きの話にし、人が戻ったところまで書く |
| 学んだこと、まとめ | 消す。言いたいことは前の節の最後の一段落に入れる |
書き直した後の記事です（study-full.md）。
# 社内勉強会は、発表を短くしたら人が戻ってきた
2025年10月に、開発チームで社内勉強会を始めました。毎週木曜日の 17:00 から 17:30 まで、1 人が 15 分話して、残りの時間で質疑をする形です。チームの 12 人で始めましたが、2 か月たつと、来るのは 5 人になっていました。
## 人が減ったのは、話が遠かったから
振り返ると、まず話す人が決まっていました。最初の 8 回のうち 6 回は、同じ 2 人が発表しています。題材も、Rust や新しいフレームワークのように、ふだんの業務では使わない技術が多くを占めていました。聞く側にとっては、面白くても明日の仕事には関わらない話です。忙しい週に足が遠のくのは、無理もありませんでした。
## その週に詰まったことを、短く話す
そこで、題材をその週に詰まったことに限りました。本番で起きた障害の振り返りや、レビューで何度も指摘された書き方です。どれも誰かが実際に困った話で、聞けば次の週の仕事に役立ちます。
発表は 5 分に縮めました。長い資料を用意するのは負担でしたが、その長さなら、どこで詰まり、どう直したかを話せば終わります。半年で、発表した人は 9 人になりました。話した内容は Notion に残しているので、休んだ人も後から読めます。
参加者は 11 人まで戻りました。ここまで変わるとは思っていませんでした。
続かなかった原因は、意志の弱さより、話す側の準備の重さと、聞く側から見た題材の遠さにありました。どちらも仕組みで軽くできます。書き直した後の結果です。
$ npx chaffjs study-full.md --genre blog/tech --compact
study-full.md blog/tech · 日本語 ジャンルは --genre から
指摘 0 件、動いていない rule 59 件構成の変わり方を outline で測った結果です。見出しが減って節が長くなり、箇条書きと太字は無くなりました。
$ npx chaffjs outline study.md study-full.md
study.md の構成: 見出し 14、節の平均 67 字、箇条書き 15%、太字 10
# 社内勉強会を半年続けて見えてきた、本当に大切なこと——継続の秘訣とは (study.md:1) 54 字
## はじめに (study.md:5) 83 字
## 勉強会の概要 (study.md:11) 67 字
## 直面した課題 (study.md:19) 0 字
### 参加者が減った (study.md:21) 63 字
### 話す人が偏った (study.md:25) 26 字
### 内容が業務と離れていた (study.md:29) 47 字
## 実施した改善策 (study.md:33) 34 字
### 題材を業務から選ぶ (study.md:37) 63 字
### 発表を短くする (study.md:41) 39 字
### 記録を残す (study.md:45) 37 字
## 結果 (study.md:49) 97 字
## 学んだこと (study.md:55) 88 字
## まとめ (study.md:63) 169 字
構成の AI らしさ: 3（人の記事の 9 割を超えた項目の数。比べた 10 項目、人の記事 2779 本と比べて）
✗ 見出しの多さ: 1000 字あたり 15 人の記事の 95% より多い（人の中央 4.3、上から 1 割の境 10.2）
· 1〜2 段落の節: 100%（平均 1.3 段落） 人の記事の 85% より多い
· 節の長さのばらつき: 54% 人の記事の 70% より揃っている
✗ 3 つの小見出しに分けた見出し: 2 か所 人の記事の 90% より多い（人の中央 0、上から 1 割の境 1）
· はじめに・まとめの見出し: 2（前と後） 人の記事の 75% より多い
· まとめが本文を言い直す割合: 27%（「まとめ」） 人の記事の 70% より多い
✗ 太字の見出しで始まる項目: 6 項目 人の記事の 95% より多い（人の中央 0、上から 1 割の境 0）
· 人の記事でふつう: 決まった形の見出し 0%、絵文字の付いた見出し 0 個、メリットとデメリットの対 0 組
測っていない: 3 項目の箇条書き（箇条書きが 3 つ未満）
study-full.md の構成: 見出し 3、節の平均 187 字、箇条書き 0%、太字 0
# 社内勉強会は、発表を短くしたら人が戻ってきた (study-full.md:1) 111 字
## 人が減ったのは、話が遠かったから (study-full.md:5) 151 字
## その週に詰まったことを、短く話す (study-full.md:9) 300 字
構成の AI らしさ: 0（人の記事の 9 割を超えた項目の数。比べた 6 項目、人の記事 2779 本と比べて）
· 見出しの多さ: 1000 字あたり 3.6 人の記事の 35% より多い
· 人の記事でふつう: 3 つの小見出しに分けた見出し 0 か所、はじめに・まとめの見出し 0、太字の見出しで始まる項目 0 項目、絵文字の付いた見出し 0 個、メリットとデメリットの対 0 組
測っていない: 1〜2 段落の節（中身のある節が少ない）、節の長さのばらつき（中身のある節が少ない）、決まった形の見出し（見出しが少ない）、まとめが本文を言い直す割合（まとめの節が無い）、3 項目の箇条書き（箇条書きが 3 つ未満）
構成の変化（study.md → study-full.md）
見出し: 14 → 3
節の平均: 67 字 → 187 字
箇条書き: 15% → 0%
太字: 10 → 0
構成の AI らしさ: 3 → 0
見出しの多さ: 1000 字あたり 15 → 1000 字あたり 3.6
1〜2 段落の節: 100%（平均 1.3 段落） → —
節の長さのばらつき: 54% → —
決まった形の見出し: 0% → —
3 つの小見出しに分けた見出し: 2 か所 → 0 か所
はじめに・まとめの見出し: 2（前と後） → 0
まとめが本文を言い直す割合: 27%（「まとめ」） → —
太字の見出しで始まる項目: 6 項目 → 0 項目
絵文字の付いた見出し: 0 個 → 0 個
メリットとデメリットの対: 0 組 → 0 組最初の下書きで compare をかけたときは、「5 分なら、どこで詰まり」の「5 分」が足された事実として出ました。元の記事には「5 分」が一度しか無いので、二度目は足したことになります。「その長さなら」と言い換えて、もう一度かけた結果です。
$ npx chaffjs compare study.md study-full.md --allow-dropped heading --allow-added heading
study.md → study-full.md
✗ 落ちた事実 11 件（study.md にあって study-full.md に無い）
見出し: 直面した課題 (study.md:19)（--allow-dropped で許可）
見出し: 参加者が減った (study.md:21)（--allow-dropped で許可）
見出し: 話す人が偏った (study.md:25)（--allow-dropped で許可）
見出し: 内容が業務と離れていた (study.md:29)（--allow-dropped で許可）
見出し: 実施した改善策 (study.md:33)（--allow-dropped で許可）
見出し: 題材を業務から選ぶ (study.md:37)（--allow-dropped で許可）
見出し: 発表を短くする (study.md:41)（--allow-dropped で許可）
見出し: 記録を残す (study.md:45)（--allow-dropped で許可）
見出し: 結果 (study.md:49)（--allow-dropped で許可）
見出し: 学んだこと (study.md:55)（--allow-dropped で許可）
見出し: まとめ (study.md:63)（--allow-dropped で許可）
i 書き方だけ変わった事実 3 件
見出し: 社内勉強会を半年続けて見えてきた、本当に大切なこと——継続の秘訣とは → 社内勉強会は、発表を短くしたら人が戻ってきた (1 行目 → 1 行目)
見出し: はじめに → 人が減ったのは、話が遠かったから (5 行目 → 5 行目)
見出し: 勉強会の概要 → その週に詰まったことを、短く話す (11 行目 → 9 行目)
照合した事実 30 件 → 19 件: 数 11→11、日付 1→1、時刻 2→2、URL 0→0、コード 0→0、固有名詞 2→2、引用 0→0、見出し 14→3、条項の参照 0→0、脚注 0→0
落ちた事実も足された事実もありません落ちた事実は見出しだけで、わざと作り直した構成なので --allow-dropped heading と --allow-added heading で外しています。数、日付、時刻、固有名詞はすべて残っています。
変えたことと、その理由です。
| 変えたこと | 理由 |
|---|---|
| 14 の見出しを 3 つにしました | 一段落ごとの見出しと本文の無い見出しをやめ、節を中身のある単位にするためです |
| 課題、改善策、学んだことの 3 点ずつの対称をやめました | 中身は一続きの話で、3 つずつに分かれてはいません |
| 「まとめ」と「学んだこと」を消し、言いたいことを最後の段落に入れました | 本文の言い直しで、新しいことを言っていません |
| 題を、分かったことにしました | 「本当に大切なこと」「継続の秘訣とは」は予告で、中身がありません |
| 「本記事では〜解説していきます」「エンジニアにとって〜非常に重要です」を消しました | どの記事にも書ける書き出しです |
| 太字と箇条書きをすべて文に戻しました | 並べた項目は、理由と結果で繋がっています |
| 「単なる〜ではありません」「だけではありません」を消しました | 誰も言っていない X を打ち消していました |
| 「チームの雰囲気そのものが変わった」を消しました | 裏付ける場面が元の記事に無く、足すと事実を作ることになります |
| 「いかがでしたでしょうか」「幸いです」を消しました | 締めの決まり文句です |
最後に、前と後を chaff の数で並べます。
| 測ったもの | 前 | 後 |
|---|---|---|
| 指摘 | 13 件 | 0 件 |
ai-generated-composite | 5 種がそろう | 出ない |
構成の AI らしさ（chaff outline） | 3（見出しの多さ、3 つに分けた小見出し、太字の札） | 0 |
| 見出し | 14 | 3 |
| 節の平均 | 67 字 | 187 字 |
| 箇条書き | 15% | 0% |
| 太字 | 10 | 0 |
compare（見出しを除く） | — | 落ちた事実も足された事実も無し |