AIに毎朝コラムの下書きを書かせる。ただし公開ボタンは渡さない — 中小企業 × AI 経営(2026年8月)
以前、AIに書かせた記事73本のうち65本が事実と違っていました。それでも今回、下書きの作成をAIに任せることにしました。何を機械に渡し、何を渡さなかったか。その線の引き方の話です。
結論から言うと、自動化するかどうかは「できるか」ではなく「間違えたとき誰が困るか」で決める——今回いちばん整理できたのは、この一点でした。
弊社では、このコラムを私が書いています。書く材料は、日々の作業記録に溜まっています。ところが記録は毎日溜まるのに、記事は書ける日にしか書けません。溜まる一方でした。
そこで「記録から記事を作る流れを自動化できないか」を考えました。ただし弊社には、これをやって派手に失敗した過去があります。
前科:73本のうち65本が事実と違っていた
以前、社内の記録からAIに記事を自動生成させていた時期があります。結果はひどいものでした。生成された73本を点検したところ、65本が事実と異なる内容でした。日付が違う、やっていない作業が書かれている、数字が架空——といった具合です。全部捨てました。
このときの詳細は以前のコラムに書きました。読み返すと、失敗の構造ははっきりしています。
- 材料(記録)が薄いのに、記事の分量だけ求めた
- AIは足りない部分を**「もっともらしく」埋める**
- 出来上がったものを、誰も一本ずつ確認していなかった
- 公開まで自動でつながっていた
つまり、間違いが誰にも止められないまま外に出る形になっていたわけです。
それでも、もう一度自動化する
普通ならここで「AIに書かせるのはやめよう」となります。実際しばらくそうしていました。
しかし今回、もう一度やることにしました。理由は、前回の失敗の原因が「AIが書いたこと」ではなかったと考え直したからです。
原因は3つに分解できます。
| 前回の問題 | それは何の問題か |
|---|---|
| 材料が薄いのに書かせた | 材料の問題 |
| 事実と違うことを書いた | 確認の問題 |
| 誰も見ないまま公開された | 仕組みの問題 |
「AIが書いた」こと自体は、実はどこにも出てきません。人間が同じ条件(材料が薄い・確認しない・そのまま公開)で書いても、結果は似たようなものになります。
だとすれば、直すべきは書き手ではなく、その前後です。そう考えて設計し直しました。
3つに分けて、真ん中だけ任せた
今回作ったものは、3つの部分に分かれています。
1. 材料を集める(機械にやらせる/AIは使わない)
毎朝、前日の作業記録を機械が読んで、「コラムになりそうな題材」を候補として並べます。ここでAIは一切使いません。見出しと課題の一行を、そのまま運ぶだけです。
点数の付け方だけ工夫しました。高い点が付くのは、失敗と、その後始末の話です。「壊れた」「漏れた」「止まった」といった言葉が入っている記録を上位にしています。次に高いのが「作らないことにした」という判断の記録です。
うまくいった話より、失敗と、作らなかった話の方が読まれる——これは過去の記事の反応から学びました。だから機械にもそう探させています。
2. 下書きを書く(ここだけAIに任せる)
候補の上位から1本選んで、AIに下書きを書かせます。指示には、前回の失敗を踏まえて次のことを明記しました。
- **記録に無いことは書かない。**推測で補いそうになったら、その段落ごと落とす
- 数字は記録にあるものだけを使う
- 書くことが無い日は、書かない(無理に1本ひねり出さない)
- 最後に「ここは未確認」という自己申告を必ず付ける
最後の項目が地味に効いています。下書きの末尾に「この部分はまだ裏が取れていない」と書かせるので、読む側はどこを疑えばいいかが分かった状態で受け取れます。
3. 公開前に検査する(機械/絶対に人任せにしない)
これが今回いちばん力を入れた部分です。記事を公開する直前に、機械が全文を検査します。
- 取引先の名前が入っていないか(自社の顧客名簿と突き合わせます)
- 売上や粗利の実額が書かれていないか
- 社員の実名、社内の管理番号、機器やサービスの内部情報が漏れていないか
- 「社内向けメモ」の消し忘れが残っていないか
引っかかると、そもそもサイトを組み立てる処理が止まります。公開したくても公開できない、という形にしました。
この検査が正しく働くかどうかも確かめています。わざと機密を書き込んだ偽の記事を用意して通したところ、6件を検出してきちんと止まりました。検査は「作った」ではなく「本当に止まるか試した」まででワンセットです。
公開ボタンだけは渡さなかった
ここまで自動化しておきながら、公開の判断は自動にしていません。
下書きは「下書き」の状態で置かれるだけです。私が読んで、良ければ公開する。読まなければ、いつまでも公開されません。
なぜ最後の一歩を残したかというと、間違えたときに困るのが自分ではなく読者だからです。
- 材料集めを間違えたら → 候補の並びが変なだけ。私が困る
- 下書きを間違えたら → 私が読んで直す。私が困る
- 公開を間違えたら → 読んだ人が誤った情報を受け取る。相手が困る
自動化してよい範囲は、ここで線が引けます。**間違いの被害が社内で止まるなら自動化してよい。社外に出るなら人が判断する。**この基準は広告でも請求でも同じように使えるはずです。
「書かない日」を作れるようにした
もう一つ、地味ですが大事な設計があります。記録が無い日は、記事を作らせないことです。
先日、実際にこういう場面がありました。ある日の記録を探したところ、日記も作業記録も無く、残っていたのは毎朝自動で走る処理の履歴だけ。つまりその日は何もしていないわけです(夏季休業の期間でした)。
このとき、仕組みは何も出力せずに終わります。「候補なし」で静かに止まる。
毎日1本という目標を立ててしまうと、こういう日に書くことを探しに行くことになります。探しに行った先にあるのは、たいてい薄い話か、盛った話です。前回65本を捨てた原因のひとつは、まさにこれでした。
だから、空いた日は空いたままにすると決めました。記事の日付も、公開した日ではなく実際に作業した日に合わせています。休んだ日に記事が無いのは、不都合ではなく事実です。
中小企業にとっての意味
AIに仕事を任せるかどうかで迷ったとき、私は今後この順で考えることにしました。
| 問い | 答えが「はい」なら |
|---|---|
| 材料は十分にあるか | 任せる価値がある |
| 間違いを機械で検出できるか | 任せてよい |
| 間違いの被害は社内で止まるか | 自動化してよい |
| 被害が社外に出るか | 最後は人が判断する |
よく「AIをどこまで信用するか」という聞き方をしますが、これは実は問いの立て方が良くないと思っています。信用の度合いではなく、間違えたときの被害の届く範囲で決める方が、判断がぶれません。
そして、この考え方はAIに限りません。新しく入った社員に任せる範囲を決めるとき、外注先に渡す範囲を決めるときも、まったく同じ問いが使えます。**「できるか」ではなく「間違えたとき誰が困るか」。**私はこれを、今回のコラム自動化を通じて言語化できました。
この記事について
最後に、正直なことを書いておきます。
**この記事自体、今回作った仕組みの流れに沿って書かれています。**材料は機械が拾った候補、下書きはAI、機密の検査も機械。そして今、公開するかどうかを私が決めて、この文章が世に出ています。
仕組みを作った当日に、その仕組みの話を書くというのは、少し出来すぎた話に見えるかもしれません。ただ、これも記録に残っている当日の作業なので、そのまま題材になりました。明日は明日の記録から、別の話が上がってくるはずです。
RELATED — 関連コラム
こちらもどうぞ
- HANDS-ON
70個の自動処理を点検したら、壊れていたのは点検する側だった — 中小企業 × AI 経営(2026年8月)
毎朝ひとりでに動く処理が70個まで増えました。全部が本当に動いているのか、初めて一つずつ確かめた記録です。最初に見つけた異常は誤報で、本当の問題は「月6回のはずが月23回動いていた」設定でした。
- HANDS-ON
担当が途中で消えても仕事は終わる——報告ではなく成果物で受け取る設計(中小企業 × AI 経営シリーズ)
一晩で9本のツールを同時に作らせたら、9体の作り手のうち8体が途中で力尽きました。それでも仕事は終わりました。理由は「報告」ではなく「成果物」で受け取る設計にあった、という話です。
- HANDS-ON
「コピーが効かない」の一報から、壊れていた13箇所が見つかった — 中小企業 × AI 経営(2026年8月)
エラーも出ない・ビルドも通る・見た目も正常。それでも利用者には壊れている——そんな「静かに壊れる」バグが、1件の報告をきっかけに13件見つかりました。テストが緑でも安心できない理由と、検査を三層に重ねた話です。