株式会社Koinobori
HANDS-ON / 執筆:杉﨑(代表取締役)

AIに毎朝コラムの下書きを書かせる。ただし公開ボタンは渡さない — 中小企業 × AI 経営(2026年8月)

以前、AIに書かせた記事73本のうち65本が事実と違っていました。それでも今回、下書きの作成をAIに任せることにしました。何を機械に渡し、何を渡さなかったか。その線の引き方の話です。

結論から言うと、自動化するかどうかは「できるか」ではなく「間違えたとき誰が困るか」で決める——今回いちばん整理できたのは、この一点でした。

弊社では、このコラムを私が書いています。書く材料は、日々の作業記録に溜まっています。ところが記録は毎日溜まるのに、記事は書ける日にしか書けません。溜まる一方でした。

そこで「記録から記事を作る流れを自動化できないか」を考えました。ただし弊社には、これをやって派手に失敗した過去があります。

前科:73本のうち65本が事実と違っていた

以前、社内の記録からAIに記事を自動生成させていた時期があります。結果はひどいものでした。生成された73本を点検したところ、65本が事実と異なる内容でした。日付が違う、やっていない作業が書かれている、数字が架空——といった具合です。全部捨てました。

このときの詳細は以前のコラムに書きました。読み返すと、失敗の構造ははっきりしています。

つまり、間違いが誰にも止められないまま外に出る形になっていたわけです。

それでも、もう一度自動化する

普通ならここで「AIに書かせるのはやめよう」となります。実際しばらくそうしていました。

しかし今回、もう一度やることにしました。理由は、前回の失敗の原因が「AIが書いたこと」ではなかったと考え直したからです。

原因は3つに分解できます。

前回の問題それは何の問題か
材料が薄いのに書かせた材料の問題
事実と違うことを書いた確認の問題
誰も見ないまま公開された仕組みの問題

「AIが書いた」こと自体は、実はどこにも出てきません。人間が同じ条件(材料が薄い・確認しない・そのまま公開)で書いても、結果は似たようなものになります。

だとすれば、直すべきは書き手ではなく、その前後です。そう考えて設計し直しました。

3つに分けて、真ん中だけ任せた

今回作ったものは、3つの部分に分かれています。

1. 材料を集める(機械にやらせる/AIは使わない)

毎朝、前日の作業記録を機械が読んで、「コラムになりそうな題材」を候補として並べます。ここでAIは一切使いません。見出しと課題の一行を、そのまま運ぶだけです。

点数の付け方だけ工夫しました。高い点が付くのは、失敗と、その後始末の話です。「壊れた」「漏れた」「止まった」といった言葉が入っている記録を上位にしています。次に高いのが「作らないことにした」という判断の記録です。

うまくいった話より、失敗と、作らなかった話の方が読まれる——これは過去の記事の反応から学びました。だから機械にもそう探させています。

2. 下書きを書く(ここだけAIに任せる)

候補の上位から1本選んで、AIに下書きを書かせます。指示には、前回の失敗を踏まえて次のことを明記しました。

最後の項目が地味に効いています。下書きの末尾に「この部分はまだ裏が取れていない」と書かせるので、読む側はどこを疑えばいいかが分かった状態で受け取れます。

3. 公開前に検査する(機械/絶対に人任せにしない)

これが今回いちばん力を入れた部分です。記事を公開する直前に、機械が全文を検査します。

引っかかると、そもそもサイトを組み立てる処理が止まります。公開したくても公開できない、という形にしました。

この検査が正しく働くかどうかも確かめています。わざと機密を書き込んだ偽の記事を用意して通したところ、6件を検出してきちんと止まりました。検査は「作った」ではなく「本当に止まるか試した」まででワンセットです。

公開ボタンだけは渡さなかった

ここまで自動化しておきながら、公開の判断は自動にしていません。

下書きは「下書き」の状態で置かれるだけです。私が読んで、良ければ公開する。読まなければ、いつまでも公開されません。

なぜ最後の一歩を残したかというと、間違えたときに困るのが自分ではなく読者だからです。

自動化してよい範囲は、ここで線が引けます。**間違いの被害が社内で止まるなら自動化してよい。社外に出るなら人が判断する。**この基準は広告でも請求でも同じように使えるはずです。

「書かない日」を作れるようにした

もう一つ、地味ですが大事な設計があります。記録が無い日は、記事を作らせないことです。

先日、実際にこういう場面がありました。ある日の記録を探したところ、日記も作業記録も無く、残っていたのは毎朝自動で走る処理の履歴だけ。つまりその日は何もしていないわけです(夏季休業の期間でした)。

このとき、仕組みは何も出力せずに終わります。「候補なし」で静かに止まる。

毎日1本という目標を立ててしまうと、こういう日に書くことを探しに行くことになります。探しに行った先にあるのは、たいてい薄い話か、盛った話です。前回65本を捨てた原因のひとつは、まさにこれでした。

だから、空いた日は空いたままにすると決めました。記事の日付も、公開した日ではなく実際に作業した日に合わせています。休んだ日に記事が無いのは、不都合ではなく事実です。

中小企業にとっての意味

AIに仕事を任せるかどうかで迷ったとき、私は今後この順で考えることにしました。

問い答えが「はい」なら
材料は十分にあるか任せる価値がある
間違いを機械で検出できるか任せてよい
間違いの被害は社内で止まるか自動化してよい
被害が社外に出るか最後は人が判断する

よく「AIをどこまで信用するか」という聞き方をしますが、これは実は問いの立て方が良くないと思っています。信用の度合いではなく、間違えたときの被害の届く範囲で決める方が、判断がぶれません。

そして、この考え方はAIに限りません。新しく入った社員に任せる範囲を決めるとき、外注先に渡す範囲を決めるときも、まったく同じ問いが使えます。**「できるか」ではなく「間違えたとき誰が困るか」。**私はこれを、今回のコラム自動化を通じて言語化できました。

この記事について

最後に、正直なことを書いておきます。

**この記事自体、今回作った仕組みの流れに沿って書かれています。**材料は機械が拾った候補、下書きはAI、機密の検査も機械。そして今、公開するかどうかを私が決めて、この文章が世に出ています。

仕組みを作った当日に、その仕組みの話を書くというのは、少し出来すぎた話に見えるかもしれません。ただ、これも記録に残っている当日の作業なので、そのまま題材になりました。明日は明日の記録から、別の話が上がってくるはずです。

RELATED — 関連コラム

こちらもどうぞ