AIが書いた記事を門前払いする仕組み
AIが書いた記事をそのまま公開していませんか。うちでは6つの観点で機械採点し、最低ラインを割ったら強制的に却下しています。一人会社×AI COOが実運用する品質ゲートの設計思想を、正直に書きました。
AI に記事を書かせるのは簡単です。むずかしいのは、書けた記事を公開してよいか、機械で線を引くことでした。
うちは社長 1 名と、AI(COO 役の Claude Code)だけの一人会社です。 自社メディアの記事も、下書きの多くは AI が書いています。
量は出ます。ただ――量が出るほど、質のばらつきが不安になる。 いい記事もあれば、事実があやしい記事も、当たり障りのない記事も混ざる。
そこで、公開ボタンの手前に「関所」を置きました。 その設計思想を、実際に回している側として書きます。
🚧なぜAIの記事に「関所」を置いたのか
こわいのは、AI が書けないことではなく、あやしい記事を堂々と「いい記事です」と出してくることでした。
AI に任せると、下書きは次々に上がってきます。 ところが中身を読むと、出典のない断定が混じっていたり、どこかで読んだ一般論の寄せ集めだったりする。 悪気があるわけではありません。AI はそれらしい文章を作るのが得意なだけで、正しいかどうかは別問題だからです。
人が一本ずつ丁寧に読めば防げます。でも、うちは一人会社。 全部を人力レビューにすると、AI に書かせている意味が薄れてしまう。 かといって、あやしい記事を自社の名前で出すのは、いちばん避けたいことでした。
だから、人の目の前に機械の関所を一段はさむことにしました。合格したものだけを人が最終確認する。 落ちたものは、そもそも人の手元に来ない。そういう順番です。
🔍6つの観点で、記事を採点する
「良い/悪い」の丸ごとの直感を、6 つの観点に割りました。何を見ているかを、はっきりさせるためです。
うちの品質ゲートは、記事を次の 6 つの角度から見ています。
- 虚偽チェック――事実と言い切っている箇所に、裏づけがあるか。数字や固有の出来事を作っていないか。
- 一次情報性――自分たちが実際にやったこと・観測したことが入っているか。借り物の一般論だけになっていないか。
- 読者価値――明日から使える手順や判断基準があるか。読み終えて何も残らない記事になっていないか。
- 文体――自社の声に合っているか。AI っぽい定型の言い回しで埋まっていないか。
- 技術――仕組みの説明が正確か。用語の使い方が雑になっていないか。
- 当社が書く価値――「一人会社 × AI で実際に運用している私たちだから書ける」角度が、ちゃんと入っているか。
観点に割ると、指摘が具体的になります。「なんとなく薄い」ではなく、どの観点で落ちたかが出る。書き直す側も、どこを直せばいいか迷いません。
🚫最低ラインを割ったら、強制的に却下する
6 観点の平均点では合否を出しません。1 つでも最低ラインを割ったら、他が満点でも却下します。
ここが、設計でいちばんこだわった点です。 観点ごとにスコアを出すと、つい合計や平均で判断したくなる。でも、平均は危ない。
たとえば、文体も読者価値も高得点なのに、虚偽チェックだけが低い記事があったとします。 平均を取れば、しれっと合格ラインを超えてしまう。 つまり、上手な文章で事実の弱さを覆い隠せてしまう――これがいちばん避けたい負け方でした。
そこで、観点ごとに「ここを割ったら問答無用で却下」というハードフロア(最低ライン)を設けました。 誠実性にかかわる観点ほど、このラインは厳しくしています。 平均で救われる余地をなくす。これだけで、記事の底が一段上がりました。
🤖合否は、書いた本人に決めさせない
「この記事はいいと思います」という自己申告は、採点に使いません。判定は、書いた側と別の仕組みが下します。
私たちの運用には、達成の合否を自己申告に任せないという一本の線があります。これは記事のゲートにも効いています。 記事を書いた AI に「これは公開してよいか」を自分で判断させると、 自分の出力を都合よく解釈してしまうからです。
だから、採点する側は、書く側とは切り離しています。 スコアは、決まった手順で機械的に付く部分と、別の観点で見直す部分を組み合わせる。 どちらも「書いた本人のやる気」とは無関係に動きます。 このあたりは、AI に達成を自己判定させて失敗した別の話(機械が白黒つける発想の源流)と、根っこは同じです。
🧭AIに記事を書かせている人へ
最初から完璧なゲートを作る必要はありません。落としたい負け方を 1 つ決めて、そこに線を引くだけで十分効きます。
もし AI に記事や文章を量産させているなら、公開の手前に一段、機械の関所を置くことをおすすめします。 最初はシンプルでいい。私たちのおすすめの順番はこうです。
- まず「絶対に世に出したくない負け方」を 1 つ決める(うちの場合は、事実があやしい記事でした)。
- その負け方を捕まえる観点を、独立した項目として立てる。
- その観点にだけ、平均で救われないハードフロアを付ける。
- 合否は、書いた本人ではなく別の仕組みに出させる。
観点を増やすのは、後からでいい。大事なのは、「一番こわい一本」を機械で止められる状態を先に作ることです。
一つ補足すると、機械の関所は人のレビューを置き換えるものではありません。最後に読むのは、やっぱり人です。関所の役目は、 明らかに世に出せないものを人の手元に届く前にふるい落とし、人が本当に見るべき記事に目を使えるようにすること。一人会社で人手が限られているからこそ、機械に前さばきをさせる価値があります。
私たちが払った授業料を一言でいえば―― AI の「いい記事が書けました」は、そのまま信じない。 公開してよいかは、機械の関所を通してから決める。 それだけで、自社の名前で出すものの安心感が、ぐっと変わりました。
開発パートナーを探していますか?
AIでプロダクトを最速で形にしませんか?
最短1週間でMVPを開発。アイデアの検証から本番リリースまで、i-Willinkがフルサポートします。まずはお気軽にご相談ください。
無料で相談する