新規記事を作る試験が既存記事更新になった――dotの重複判断と実験目的がぶつかった記録

最初に試したかったのは「採掘から新規公開まで」だった

dotローンチ直後、可児波起はそれまで人間が行っていたKnowledge制作の流れを、自動化できるか試していました。

従来は、過去のChatGPT会話へ採掘指示を入れ、候補を別の制作チャットへ移し、既存Knowledgeと比較し、記事を書き、画像を作り、Wixへ公開し、公開後にセルフレビューする流れを繰り返していました。

可児波起がdotへ求めたのは、素材を渡した後だけを自動化することではありません。過去会話の採掘から担当し、まず1本を記事化・公開まで進め、その学びを次へつなぐことでした。

最初の一周では、既存119記事との照合後に「更新」が選ばれた

最初の一周でdotは、このdot会話内で起きたWix修正体験を素材にし、既存Knowledgeとの照合を行ったと報告しました。

その報告では、既存119記事と比較した結果、同じ問いを扱う既存記事があるため、新規Knowledgeではなくその記事への追記を選んだとされています。

重複した問いを新しいURLで増やさず、既存記事へ統合する判断は、Knowledge運用としては不自然ではありません。

しかし、それでは「新規記事を作れるか」の試験になっていなかった

可児波起は結果を見て「今回は、新記事じゃなくて更新にしたの？」と確認しました。

この問いで明らかになったのは、今回の試験が単なる編集作業ではなかったことです。

確認したかったのは、新規記事の本文を作れるかだけではありません。新しいKnowledgeレコードを作り、新しいメイン画像を用意し、Wixへ登録し、公開ページまで成立させられるかという、新規制作工程そのものを試していました。

既存記事更新では、本文修正の能力は試せても、新規レコード作成や新規Hero画像の制作・登録は検証できません。

編集上の「正解」と、実験上の「正解」が分かれた

この場面では、二つの判断基準が同時に存在していました。

編集判断：同じ問いの既存Knowledgeがあるなら、新規記事を増やさず既存記事へ統合する。

実験判断：今回は新規記事・新規画像・Wix登録まで一連の新規制作能力を試す。

dotは前者を優先しました。可児波起は後者を試したかったため、同じ結果を見ても「成功」の意味が一致しませんでした。

新規記事とメイン画像を、別の試験として明示した

可児波起はその後、「メイン画像とかを本当に作れるか試したい」と、新規記事と画像制作を明示的に要求しました。

dot側は、会話の文脈を知っていることと、最新資料本文を実際に取得できることの違いを題材に、新規Knowledgeを作成し、メイン画像を用意し、Wixへ登録・公開したと報告しています。

可児波起はこの試験について「大成功」と評価しました。

新規制作を試したことで、既存更新では見えなかった工程が表に出た

新しい記事を1本作ると、既存記事の文章修正だけでは発生しない工程があります。

新しいURLキー、CMSの新規レコード、Primary Cluster、関連記事、メイン画像、画像ALT、SEO説明、公開URLなど、新しい記事固有の要素をそろえる必要があります。

後の試験では、こうした新規制作工程の中で画像アップロード許可待ちや、公開後の表示確認など別の問題も見つかりました。最初から既存記事更新だけを成功例としていたら、その段階までは確認できませんでした。

だから「重複するなら更新」というルールを捨てたわけではない

この出来事の後も、既存Knowledgeとの重複照合は制作工程に残っています。

可児波起が求めたのは、重複していても必ず新規記事を作ることではありません。

通常のKnowledge制作では、同じ問いなら既存更新にする判断を維持しつつ、「今回は何の能力を試しているのか」という実験目的を先に確認する必要がある、という整理になりました。

試験目的を明示しないと、AIは別の合理的な成功条件を選べる

AIへ「一連の作業を試したい」と伝えても、その中に複数の判断基準があれば、AIが最も合理的だと考える経路へ進むことがあります。

この実例では、重複を避けるというサイト運用上のルールが、新規制作工程を試すという一時的な実験目的より前に出ました。

そのため、試験では「通常運用なら更新でよいが、今回は新規作成工程を検証する」と、普段の最適化ルールと今回だけの検証目的を分けて示す必要がありました。

このKnowledgeで言える範囲

本記事が記録しているのは、2026年9月30日のdotローンチ直後に、採掘から新規Knowledge公開までを試したかった一周目が、既存記事更新へ置き換わった具体例です。

既存119記事という数、更新内容、新規記事の公開結果は、当時のdot側の報告として扱います。本記事制作時にその時点の119記事一覧や全操作ログを再取得したわけではありません。

確認できるのは、既存更新の判断自体を否定せず、実験で検証したい工程を先に固定したことで、新規記事・新規画像・Wix公開の試験へ切り替わったことです。

このKnowledgeの関連知識

採掘と重複判断の前提：過去のChatGPT会話からKnowledge・Experimentsの一次素材を発掘する方法。採掘後に既存Knowledgeと照合し、新規・更新などを判断する基本工程です。

その後の新規0件の実例：3スレッドを約49分で採掘して新規Knowledgeが0件だった――処理量と新しい知の発見は別だった。通常運用の重複判断と、新規記事を増やす目的の違いを別の試行で扱います。

新規記事として成功した題材：過去の話を知っていても資料を読めたとは限らない――dotへ10ファイルを添付して原文を確認した実例。新規記事・メイン画像まで試すために作られたKnowledgeです。