「雑草じゃなく、感謝される植物になれ。」
文章だけ見ると、朝礼で社長が従業員に放ちそうな謎の激励である。聞かされた側はたぶん「植物にも成果評価あるんかい」と思う。
ところがAIで記事を作り、公開し、観測し、直し、また次の記事を生やす仕組みを考えていると、このふざけた標語が妙に本質を突いてくる。ただ記事数を増やすだけなら雑草だ。検索した人の疑問に答え、別の記事へ自然につなぎ、古くなれば更新され、新しい疑問が生まれれば枝分かれするなら、それは少し植物に近い。
そして、この植物を育てる思想の根にあるのが「人がミスしたら人を責める」ではなく、「同じミスが起きるなら、まず仕組みを直す」である。
「気をつけます」で終わらせず、ミスできた構造を見る
人の失敗には、個人へ原因を寄せる見方と、仕組み側を見る見方がある。心理学者James Reasonは、人の忘却や不注意だけに焦点を当てる考え方と、事故が起きやすい条件や防御の穴まで見るシステム的な考え方を対比した。[1]
GoogleのSREでも、重大障害の振り返りは「誰が悪かったか」を探す罰ではなく、再発しにくい仕組みへ変える学習機会として扱われる。失敗を隠させるより、失敗からシステムを強くする方が長期的には信頼性が上がる、という発想だ。[2]
AI運用でも同じことが起きる。
AIが忘れるたびに「次はちゃんと覚えて」と言う。途中で止まるたびに「最後までやって」と言う。公開前に確認を忘れるたびに「今後は必ず確認して」と言う。これを百回繰り返すと、AIに説教する係が必要になる。
そこで発想を変える。
- 忘れるなら、正本を外部に置く。
- 途中で止まるなら、キューと再開地点を残す。
- 完了を勘違いするなら、実物の読み戻しを完了条件にする。
- 一件の失敗で全停止するなら、対象だけを隔離する。
- 同じ不良が再発するなら、検査ルールへ昇格させる。
「もっと優秀になれ」ではなく、「普通に動いても壊れにくい環境を作る」。この考え方は、AIが賢くなるほどむしろ効いてくる。
古いAIのポンコツさは、意外と優秀な先生だった
今のAIだけを触っていると、モデルが賢ければ自動化できるように見える。しかし、性能が低かった時代からAIを使っていると、別の景色が見える。
昔のAIはよく忘れた。途中で勝手に満足した。条件を一部だけ守った。テストしたのに実物を見なかった。「完了しました」と言ったあとに、普通に終わっていなかった。
面倒だが、これは設計者にとって教材になる。
忘れるから外部記憶を作る。止まるからcheckpointを作る。勝手に完了するからhard gateを作る。説明だけして修正しないから、「分析したなら実行まで」の契約を作る。公開したつもり事故が起きるから、本番HTMLまで読み戻す。
つまり、弱いAIとの格闘で作った柵、道路、倉庫、信号、検査工程へ、後から強いAIが入ってくる。
AIが急に天才になっただけではない。昔のAIが壊した場所へ一本ずつガードレールを置いた結果、今の強いAIが高速で走れるようになったのである。
NISTのAIリスク管理枠組みも、AIの信頼性をモデル単体の性能だけでなく、設計、運用、評価、監視を含むライフサイクル全体で扱う。[3] 2026年のNISTの報告でも、本番導入後の監視は、現実環境での信頼性確認や予想外の出力・影響を把握するため重要だと整理されている。[4]
工場から植物へ――記事は「作る」より「生える」に近づく
工場モデルでは、人が「次はこの記事を書け」と注文し、機械が作る。
植物モデルでは違う。
外で検索需要が伸びる。既存記事に新しい検索語が流れ込む。読者が特定の記事間をよく移動する。あるテーマから「料金は？」「なぜ？」「誰が使う？」という別の疑問が増える。
その刺激を受けて、必要な場所から芽が出る。
外界の変化
↓
種を発見
↓
既存記事で答えられる？
├─ はい → 既存記事を成長
└─ いいえ → 新しい芽を作る
↓
QA・公開
↓
読者が反応
↓
根と枝のつながりを更新
一つの記事を無限に太らせる必要もない。独立した疑問が育ったら子記事へ枝分かれする。逆に、同じ疑問へ収束した枝は統合できる。
ここで重要なのは「記事数が増えた」が成功ではないことだ。
雑草は増える。価値のある植物は、誰かの役に立つ。
だから「雑草じゃなく感謝される植物になれ」という、社長の朝礼みたいな言葉が急に設計要件になる。
ChatGPT、GitHub、Cloudflareは何の器官になるのか
植物型のメディアでは、全部を一つのAIへ押し込まない方がいい。役割を分けると生き物っぽくなる。
ChatGPTの定期実行は、脳と成長点
外界やサイトの状態を読み、「何を調べるか」「何を直すか」「新しい芽を出すか」を判断する。記事を書く担当もここにいる。
ただし、ChatGPT自身を唯一の記憶装置にしない。毎回、外部の正本を読み、判断し、結果を戻す。
GitHubは、DNAと長期記憶
記事、ルール、キュー、変更履歴、なぜその判断をしたか、どこまで終わったかを保存する。
モデルが入れ替わっても、DNAが残れば別のAIが続きを読める。
Cloudflareは、身体と循環器
記事を読者へ届け、どの記事が表示され、どこがクリックされ、次にどこへ移動したかを観測する。
重い思考を毎ページ表示時にやるのではなく、事前に作った候補や重みを高速に配る身体として使う。
Google Trendsや検索データは、外界の感覚器
Googleは、Trendsをコンテンツ戦略の参考に使える一方、「トレンドだから」という理由だけで書くべきではないと案内している。[5] 急上昇ページでは100以上の国や地域を切り替え、最近の検索急増を追える。[6]
つまり、Trendsは「書くべき答え」ではなく「何かが起きている」という匂いだ。
Codexのような実装エージェントは、設備工事
普段の発芽や成長ではなく、配管を変える、保存形式を変える、センサーを追加する、といった大工事を担当する。
こう分けると、記事工場ではなく、生態系に近づく。
「俺AI」がコピーすべきなのは、興味ではなく思考の動き
個人化AIを作るとき、ありがちな設計は「この人は旅行が好き」「AIが好き」「食べ物が好き」といった興味プロフィールを作ることだ。
でも、それだけだと価値が狭い。
本当に転用したいのは、知らないものを見たときの思考の動きだ。
「これ何？」 →「なぜこうなった？」 →「誰が得する？」 →「いくら動いてる？」 →「制度上はどうなってる？」 →「建前と実態がズレてない？」 →「普通の人が次に気になるのは？」 →「一次情報や研究ではどう説明できる？」
この順番を学べれば、本人が興味のない園芸、半導体、介護制度、昆虫、海外スポーツでも使える。
むしろ本人が興味のない分野こそ価値がある。人間の関心には時間も偏りもあるが、思考パターンだけなら世界中へ複製できるからだ。
欲しいのは「好みのコピー」ではない。
問題発見能力の横展開である。
チャットは原油、GitHubは精製した記憶
ここで、俺AIの材料をどこから取るかが重要になる。
完成記事だけを見ると、思考の途中が消える。
本当に濃いのはチャットだ。
最初に何へ引っかかったか。回答を見て「そこじゃない」とどこを修正したか。次に何を聞いたか。どこで笑ったか。何と何を突然つないだか。最後にどんな一般則へまとめたか。
たとえば、完成した記事には「植物型メディア」とだけ書かれていても、チャットにはこういう変化が残る。
記事を自動で増やしたい
↓
いや、工場より生き物っぽい
↓
植物みたいに勝手に生やしたい
↓
でも雑草は困る
↓
役に立つ植物だけ育ってほしい
↓
「植物にも成果評価あるんかい」
この遷移そのものが教師データだ。
だから役割はこうなる。
チャット = 原油
思考trace抽出 = 精製所
GitHub = 精製済みの長期記憶
チャット全文をそのまま公開リポジトリへ詰め込む必要はない。個人情報や私的内容を捨てて、「何に引っかかり、どう問いを変形し、何を採用・却下したか」だけを抽象化して残せばいい。
AI自身の回答は教師データとして弱く扱う。そうしないと、AIが自分で書いた文章を「本人の好み」と誤認し、自分自身をコピーし始める。
雑草化を防ぐには、最適化しすぎない
自動化すると、すぐ「一番クリックされたものをもっと出そう」と考えたくなる。
でも、それだけだと森はすぐ単一栽培になる。
人気記事へ流量が集中する。新しい記事は履歴がないので表示されない。表示されないから実績もつかない。結果として、昔から強い記事だけがさらに強くなる。
だから探索枠が必要になる。
大部分は実績のある経路を使う。ただし一部は、新記事、ロングテール、別クラスタ、まだ十分に試していない経路へ流す。
「勝っているものを全部固定する」のでも、「全部ランダムにする」のでもない。
実績を守りながら、未知の道を少し残す。
記事統合でも同じだ。似ているからといって何でも合体すると、妙な例え、独自の疑問、面白い観察まで消える。
統合前に「この記事で絶対残すもの」をArticle DNAのような形で持っておき、統合後にどこへ保存されたか確認する。削除ではなく、保存先を決めてから接ぎ木する。
植物にもKPIはある。ただし一個の数字でクビにしない
ここまで来ると、急に会社っぽくなる。
「今月の発芽数は？」
「回遊率が落ちています」
「この枝、収益貢献してませんね」
「新芽なので探索枠です」
「では次の観測期間まで様子を見ましょう」
もう植物に評価面談をしている。
ただし、本当に一つの指標だけで評価すると雑草化とは別の事故が起きる。クリック率だけ高くても、読者がすぐ戻る記事は良いとは限らない。検索流入は小さくても、別の記事へつなぐ橋として重要な記事もある。今は読まれなくても、季節や制度変更で後から必要になる記事もある。
見るべきなのは、少なくとも役立ち方の組み合わせだ。
- 読者の疑問に答えたか
- 次の記事へ自然につながったか
- 新しい検索需要を拾ったか
- 情報が古くなっていないか
- 特定記事へ流量が集中しすぎていないか
- 新しい芽にも探索機会があるか
- 独自の観察や面白さが残っているか
- 修正後に本当に良くなったか
つまり植物にもKPIはある。ただし「今月PV低いから伐採」で終わらせない。
森全体の健康を見る。
最後に残る社長の仕事は、植物を叱ることではない
この仕組みの面白いところは、人間の仕事が「一本ずつ記事を書く」から離れていくことだ。
人間がやるのは、目的を決める。面白い違和感を投げる。許してよい範囲を決める。仕組みがおかしいときに、個人へ説教するのではなく環境を直す。
そしてAI側は、その思想を別分野へ転用する。
失敗したら、失敗した個体を怒るのではなく、なぜその失敗が可能だったかを見る。新しい需要が出たら、新しい芽を出す。伸びた枝は太くする。伸びない枝も、十分に試す前には抜かない。似た枝を統合するときは、面白い特徴を失わない。
そうして最後に、社長が森を見回して言う。
「雑草じゃなく、感謝される植物になれ。」
従業員が人間ならだるい朝礼だ。
AI記事生態系の設計原則として読むと、なぜかかなり正しい。
生えることを目的にするな。読まれて、役に立って、次の芽を育てろ。
出典
- https://www.bmj.com/content/320/7237/768 bmj.com
- https://sre.google/sre-book/postmortem-culture/ sre.google
- https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10 nist.gov
- https://www.nist.gov/publications/challenges-monitoring-deployed-ai-systems-center-ai-standards-and-innovation nist.gov
- https://developers.google.com/search/docs/monitor-debug/trends-start developers.google.com
- https://support.google.com/trends/answer/3076011 support.google.com
