ChatGPTのdotをローンチ直後から3日間使った――Knowledge制作で失敗しながら役割分担を作った記録

dotの提供開始直後、「どこまで任せられるのか」を試し始めた

OpenAI Help CenterはdotをDevDayで発表した新機能の一つとして案内し、段階的にロールアウトしていると説明しています。また、dotをChatGPT内で常時稼働し、会話していない間も継続的な役割を担えるエージェントとして説明しています。OpenAIのDevDay 2026公式ページでは、イベント開催日を2026年9月29日、開催地をサンフランシスコとしています。

日本時間9月30日、可児波起は利用できるようになったdotをすぐに試し始めました。最初に試した音声通話は、本人の報告では「呼出中のまま」で接続できませんでした。その直後、関心は音声機能より実務へ移ります。

対象に選んだのは、自身が運営する「海辺の部屋｜デジタルと波の音」のKnowledge制作でした。それまで可児波起は、過去約3年間のChatGPTとの会話から実体験、失敗、訂正、測定、試行錯誤を採掘し、既存Knowledgeとの重複確認、記事化、画像制作、Wix公開、レビュー、修正を分けて行っていました。この一連の作業をdotへ連続して任せられないか、という実験が始まりました。

最初の一周では、「新しく作る」が「既存を直す」に変わった

最初に任せた実作業は既存Knowledgeの修正でした。その後、可児波起は過去会話の採掘から新しいKnowledgeを作るところまで進めるよう求めました。

ところが最初の一周では、dotは既存記事との重複を判断し、新規記事ではなく既存Knowledgeへの追記を選びました。編集判断だけを見れば、同じ問いの記事があるなら既存記事を改善することは不自然ではありません。しかし、このとき試したかったのは「新規Knowledgeを作り、新しいメイン画像を制作し、Wixへ公開するところまでdotが実行できるか」でした。

可児波起は「今回は、新記事じゃなくて更新にしたの？」と確認し、新規記事とメイン画像を実際に作る試験へ軌道修正しました。ここでは、AIが合理的な編集判断をしたことと、実験の目的を達成したことが別になりました。

新規記事を公開できても、人間には何の話か分からなかった

新規Knowledgeの作成、画像制作、Wixへの登録まで進み、可児波起から「大成功」という反応も出ました。しかし記事を増やすと、文章そのものについて「人間が読めない。文章の構造が破綻してる」という指摘が入りました。

当時の文章は、根拠や確認範囲を慎重に残そうとするあまり、「何を確認したか」「何は未確認か」という制作側の説明が前面へ出ていました。初めて読む人には、誰が、いつ、何のために、何をした話なのか、そしてそこから何がKnowledgeとして分かるのかが伝わりにくい状態でした。

可児波起はここでKnowledgeを「生成AIに引用してもらうための振り切った記事。さらに人間が読んでもわかるもの」と再定義し、「どの記事を読んでも初見の人でも意味がわかる」ことを完成条件として明示しました。

読みやすくしても、「何が答えなのか」がまだ弱かった

文章を初見で読める形へ直しても、それだけでは完成しませんでした。過去のChatGPT利用を扱った記事では、可児波起が「めちゃくちゃ良くなった。これこそ当時の記録」と評価した直後に、「そこからknowledgeとして何がアンサーなのか？が弱い」と再度指摘しています。

例えば2023年6月の長文記事制作では、単に「当時は出力が短かった」と説明するのではなく、「当時、GPT-4で長い記事を作るとき、人間はどんな仕事を担っていたのか？」という問いへ置き換えました。保存記録と本人回想から、文章条件だけでなく、生成する単位と順番を人間が組み立てていたという答えへ整理され、この改稿が歴史Knowledgeの見本として承認されました。

歴史Knowledgeの中心は「当時のAIの限界」と「人間がどう補ったか」になった

可児波起は、過去のAI利用を現在の基準から採点するのではなく、「当時の生成AIの限界と、それに対して人間がどのような工夫をしたのかの記録」として残す方針を明確にしました。

そのため、歴史記事では当時の原会話、当時の公式情報、後年の本人回想、保存された出力、現在の記事制作時の分析を分ける工程が追加されました。長文記事の過去記録では、本人が求めた文字量と保存された回答に大きな差があったことを確認する一方、その直接原因までは確定しませんでした。観察できた結果と原因推定を分けることも、この試行錯誤から追加された条件でした。具体的な文字数や当時のモデル環境は、個別の歴史Knowledgeで扱います。

dot自身が問題を見つけても、修正版が直っているとは限らなかった

文章品質を上げるため、通常Chatで本文を書き、その次のメッセージでセルフレビューする方法も試しました。最初の一本では可児波起から「抜群に読みやすい」という評価が出ました。

しかし別の音楽記事では主旨逸脱が再発しました。さらに、AI自身がセルフレビューで「記録方法の話に寄りすぎた」と問題を指摘しているのに、修正版の題名と結論はそのままだったという報告も残っています。

ここから、問題を説明できたことと、実際の本文が修正されたことを別に扱うようになりました。「直しました」という説明ではなく、レビュー後の全文そのものを再確認する工程が必要になりました。

この3日間の終盤では、dotが全部を書く形から役割を分ける運用へ変わった

途中では、通常Chatと別の作業環境、プロジェクト内外、ソース参照の有無など、複数の執筆条件も比較しました。場面説明が改善した条件はありましたが、事実表現のずれ、反復、記事の焦点の取り違えは残りました。条件を完全に固定した反復比較ではないため、この記録から特定モデルやモードの優劣を結論づけることはできません。

この3日間の終盤で採用した役割分担では、dotが過去会話の採集、材料整理、既存Knowledgeとの照合、事実確認、外部操作を担当し、Knowledge本文はプロジェクト内の通常Chatで執筆する形になりました。同じChatの次のメッセージでセルフレビューし、さらに原資料照合と初読確認を分けます。確認を通った原稿は固定し、CMSへの登録途中で別の文章へ書き換えない運用へ変わりました。

「続行する」と返事しただけでは、外部処理は再開していなかった

新規Knowledge5本を一気通貫で作る試験では、本文5本が執筆・レビューを通過した後、Wixへのメイン画像アップロードで作業が止まりました。可児波起が「公開した？」と確認して初めて、公開工程が停止していることが明示されました。

さらに「続けて」という指示に対してdotは「続行するね」と返しましたが、その後の報告では画像登録の実際の再開はまだ確認できていませんでした。ここから、人間から続行指示を受け取ったこと、AIが続行すると返答したこと、外部ツールの処理が実際に再開したことを別々に扱う必要が生まれました。

途中には人間の追加操作なしで進んだ試行もあり、改善後の別の5本では追加許可を求めず完了したとの報告があります。一方、別試行ではWixの画像アップロード許可で停止しているため、この記録だけから「完全無人で常に動く」とは結論できません。

3日間で形成されたのは、dotの評価ではなく使い方だった

この約3日間では、新規を作りたいのに既存更新へ進む、公開できたのに文章が理解できない、読みやすくするとKnowledgeとしての答えが弱くなる、ルールを作っても制作判断へ適用されない、AI自身が問題を指摘しても本文が直らない、外部操作では続行の返答と実際の再開がずれる、といった問題が順番に現れました。

そのたびに可児波起が目的を戻し、工程を分け、確認方法を増やしました。この一次記録から確認できるのは、ローンチ直後のdotをKnowledge制作へ投入した際、単に「何ができるか」だけでは運用方法を決められなかったことです。何をKnowledgeとして残すのかという目的、原資料との一致、初読理解、問いへの答え、レビュー後の実際の修正、外部操作の現在状態を別々に確認する形へ使い方が変化しました。

これはdot一般が必ず同じ失敗をするという主張ではありません。2026年9月30日から10月3日に、可児波起が提供開始直後のdotを実際のKnowledge制作へ投入し、使い方そのものを試行錯誤した記録です。

このKnowledgeの関連知識

資料アクセスの具体例：過去の話を知っていても資料を読めたとは限らない――dotへ10ファイルを添付して原文を確認した実例。今回の3日間から、会話の文脈を知ることと特定版の原文を取得することを切り分けた事例です。

レビューの具体例：AIのセルフレビューで見つけた修正点は、次の原稿にも入っているか。AIが問題を説明できたことと、次稿へ実際に反映されたことを分けて確認します。

外部操作の確認：AIに外部サービスを操作させるとき「送信した・保存された・表示された」を分けて確認する。Wixへの画像登録、CMS保存、公開、表示確認を同じ完了状態にしないための関連Knowledgeです。