こんにちは、オクヤスです。
「発信したほうがいいのは分かっている。でも、書く時間がない」——経営者の方と話すと、ほぼ必ずこの話になります。
そこで私は、逆向きに考えました。書く時間を作るのではなく、日常の仕事そのものを、勝手に発信のネタに変える仕組みを作れないか。会議で決めたこと、試して失敗したこと、社内システムを直したこと。それらは全部、本来なら情報として価値があるのに、終わった瞬間に消えていきます。
3日間、AIと組んでその骨組みを作りました。結論から言うと、骨組みは動きました。そして3箇所で派手に止まりました。 この記事は、その両方を数字つきで出します。うまくいった話だけを読んでも、たぶん役に立たないので。
なお、この記事の数字はすべて、私の手元の開発記録から出典をたどれるものだけを使っています。盛っていません。
3日で「骨組み」まではできる。ただし完成品はできない
3日間でやったことを、まず結果だけ。
- 変更をまとめて本体に取り込んだ回数（プルリクエスト＝作業単位のこと）が24回
- コードの自動検査（プログラムが自分で自分を試す仕組み）が754件から1,543件へ
- 自社メディアの記事の中に、検索結果に出る説明文が空のまま放置されていたページを812件発見
「3日で24回も本体を書き換えたのか」と驚かれるかもしれませんが、これは私が高速でタイピングしたからではありません。AIが実装し、私は「どこで止まるか」を決める側に回ったからです。経営でいえば、私は作業者ではなく承認者の位置にいました。
ただし、はっきり言っておきます。3日でできたのは骨組みだけで、完成品ではありません。 むしろ3日目の終わりに私が手にしたのは、動くシステムというより「どこが壊れるかの地図」でした。そして経営判断としては、こちらのほうが価値がありました。
いちばん効いたのは、出口に「元栓」を1つ置いたこと
最初にやったのは、機能追加ではありません。出口に検査を1つ置いたことです。
私の自社メディアは、AIが毎朝1本、記事の下書きを作る仕組みで動いています。便利ですが、量が増えるほど品質のばらつきも増える。そこで、記事が世に出る手前に、機械が必ず通す検査を置きました。見るのはたった4項目です。
- URLが英数字だけでできているか（日本語URLは共有時に文字化けの塊になります）
- 検索結果に出る説明文（メタディスクリプション）が空でないか
- 本文が2,000字以上あるか
- タイトルが全角28〜60字に収まっているか
地味です。AIらしさは1ミリもありません。でも、この4項目を置いた直後に既存記事を数え直したら、説明文が空のページが812件出てきました。あわせて、中身が薄すぎるページが278件。これは新機能では絶対に見つからなかった数字です。
経営に翻訳すると、こうなります。AIを入れて生産量を増やす前に、出口の検査を1つ作るほうが先に効く。 検査がないまま量を増やすと、負債も同じ速度で増えます。今回の812件は、まさにその「増えてしまった後」の姿でした。
失敗その1：AIが書いた返信案が、全部「質問」だった
ここから失敗の話です。
私はSNS上で、他の人の投稿に返信（リプ）する案をAIに作らせる仕組みを動かしていました。ところが、出てくる候補が全件、質問形式。「〜ではないでしょうか？」「どう思われますか？」ばかり。当然、返信は伸びません。
原因を調べたら、拍子抜けするほど単純でした。AIへの指示文（プロンプト）の中に「問いかけ中心で」という趣旨の一文が入っていたのです。それだけ。しかも、生成した後に文章を検査する工程はあったのに、そこに「疑問形かどうか」を見る項目が無かった。つまり指示のミスを、下流の検査が誰も止められない構造になっていました。
対策は2つ入れました。指示文から該当の一文を外すこと。そして、疑問形を機械的にはじく検査を後段に足すこと。ここで大事なのは後者です。指示文だけ直すと、次に誰かが指示文をいじった瞬間にまた同じ事故が起きます。
経営で言えば、マニュアルを直すだけでは再発は止まらず、検品を足して初めて止まる、という当たり前の話でした。AIを使うと、この当たり前を忘れがちになります。
失敗その2：引用できる材料が「0件」だった
次はもっと痛い失敗です。
返信案の質を上げるために、「自分が実際に測った数字を引用する」機能を作りました。他人の意見の言い換えではなく、一次情報で語るためです。設計としては正しい。
そして材料を集計したら、引用できる在庫は0件でした。
内訳がひどい。手元の開発記録1,829件を機械で判定したところ、ほぼ全部が不合格。理由の最大は「単位つきの実測値が入っていない」でした。次に、形式は通ったのに「社外の人が読んで意味が分かる文になっていない」もの。要は社内メモは、そのままでは一次情報として使えないのです。
さらに、私が承認用に上げた第1バッチ21件は、読んでみたら全部却下しました。自分で作った仕組みに、自分で不合格を出した形です。その後、公開済みの自社ブログ176本も材料に足してみましたが、採用はゼロ。1,554件の文が「単位つきの数字がない」ではじかれました。自分のブログの文体に、測った数字が一切乗っていなかったということです。
最終的に、在庫は1件まで増えました。1,829件から、1件です。
これは失敗であると同時に、いちばん大きな発見でした。「AIに語らせる材料が社内にある」という前提が、そもそも成り立っていなかった。 記録は大量にあるのに、外に出せる形をしていない。これは私の会社だけの話ではないはずです。
失敗その3：動くようになっても、2回とも切り替えをやめた
3つ目は、技術ではなく判断の話です。
新しい仕組み（v2）が動くところまで来ました。実際に本番のAIを呼び出す試験もしました。結果は、4件を読み取り、4件の候補を生成し、3件が採用ラインに乗りました。数字だけ見れば成功です。
しかし中身を読んだら、3件とも同じ1件の在庫を使い回していて、内容がほぼ重複していました。しかも1件は日本語自体が崩れていた。当然です。在庫が1件しかないのだから、構造上そうなるしかない。
ここで私は、旧システムから新システムへの切り替えを見送りました。これで2回目です。1回目は、その前の試験で停止条件に当たったときでした。
見送りの代わりにやったのは、「どうなったら切り替えるか」を数字で先に書くことでした。在庫30件以上、出典10件以上、重複率50%未満、認証情報の確認済み。この4つが揃うまで切り替えない。今はまだ3つが未達です。
正直に言えば、切り替えたい誘惑はありました。動いているものを止めておくのは、気分が悪い。でも「動いた」と「任せてよい」は別です。この線引きを数字で書いておかないと、その日の気分で決めてしまいます。
費用と、導入でハマる落とし穴
費用感について。今回、新しい有料サービスは1つも増やしていません。使ったのは、すでに社内にある自動化ツール、サーバー1台、そしてAIの利用料だけです。ただし正直に書くと、今回の3日間でAI利用料が具体的にいくらだったかは記録していません。ここは私の運用の不備で、次に測ります。数字がない部分を「安かった」と書くわけにはいかないので、そのまま書いておきます。
落とし穴は3つ、実際に踏みました。
1つ目。自動化ツールの中に書いたチェック処理が、何のエラーも出さずに一度も動いていませんでした。そのツールの実行環境には、私が使ったつもりの命令が最初から存在しなかったのです。エラーが出ないので、正常に見える。「チェックを入れた」と「チェックが動いている」は違う。これは一度は必ず確認すべきです。
2つ目。設計書の初版で、私はすでに停止していたワークフローを「現役」だと思い込んで、その上に安全条件を組み立てていました。実機を読みに行って初めて、停止中だと分かりました。さらに別の1本は、記憶していた識別番号のものがそもそも存在していませんでした。AIも人も、記憶で語ると平気で嘘をつきます。
3つ目。同じデータなのに、レポート上の数字とデータベースを直接見た数字が食い違いました（クリック数で8対12、表示回数で154対220）。どちらかが間違っているのではなく、集計の途中で二重に数えていた。ダッシュボードの数字は、一度は元データと突き合わせる。これをやらないと、間違った数字で経営判断をします。
明日からできること3つ
エンジニアがいなくてもできる順に並べます。
1. 手元の記録を10件だけ「社外に出せるか」で判定する
議事録でも日報でもかまいません。10件選んで、「この文章を、事情を知らない人が読んで意味が通るか」「測った数字が単位つきで入っているか」だけを見てください。私は1,829件やって0件でした。10件で3件通れば、あなたの会社の記録は相当優秀です。
2. 出口に、人が見ない機械チェックを3項目だけ置く
タイトルの長さ、説明文の有無、URLの形。この3つで十分です。AIに書かせているなら、なおさら必要です。項目を増やすと運用されなくなるので、最初は3つに絞ってください。
3. 「切り替える条件」を、始める前に数字で書く
新しい仕組みを試すとき、必ず「どうなったら本番にするか」を先に紙に書きます。曖昧なら、動いた瞬間の高揚感で切り替えてしまいます。私は2回、この紙に助けられました。
最後に：この記事自体を、自分で作った検査に通しました
この記事は、冒頭で紹介した「出口の検査」を、そのまま自分に適用して書いています。URLは英数字だけ、説明文は空でない、本文は2,000字以上、タイトルは全角28〜60字。
そして、記事を書き終えたあとに検査を実行し、合格を確認してから出しています。実行ログも記録に残しました。
ついでに白状すると、この記事の要約を仕組みに流した1回目は不合格でした。理由は「本文に、出典が登録されていない数字が混ざっている」。日付や通し番号まで含めて、数字は出典に紐づいていないと通らない作りにしてあったからです。自分で作った規則に、自分が最初に引っかかりました。
さらに言うと、この記事を仕組みに流したとき、システムは最後にこう返してきました。「著者本人の意見がまだ承認されていない」——だから公開手前で止まる、と。自分で作った門に、自分が止められたわけです。
正直、少し笑いました。でも、これでいい。勝手に公開されない仕組みだけが、任せられる仕組みです。AIに任せるというのは、AIを信じることではなく、止まる場所を自分で決めておくことなのだと思います。
3日でできたのは、繰り返しますが骨組みだけです。ただ、止まる場所の地図は手に入りました。次は在庫30件を作るところから始めます。
9d9合同会社では、中小企業のAI活用・DX・マーケティングのご相談を受け付けています。「自社なら何から始めるべきか」を知りたい方は、お問い合わせからお気軽にどうぞ。
