論文を探し、ブログに向いた切り口を提案してもらう仕組みが止まっていました。以前の検索結果は良かったので、検索の方向性を全面的に変えたいわけではありません。必要だったのは、止まった原因を取り除き、良かった部分を継続できる形に戻すことでした。
調べてみると、停止の原因は論文検索そのものではなく、すでに削除した仕組みを必須とする古い指示でした。今回はホスト側のChatGPTで仕様を整理し、日次の検索・提案とKnowledgeへの保存を中心に組み直しました。サーバー側ではCodexの開発が進んでいるため、今回の作業で新しい検索用の常駐プログラムをサーバーへ追加してはいません。
検索まで止めてしまった古い依存関係
以前のシステムは、ChloroQuest向けの新着論文に加え、理系猫凛とOrdinary Japanの記事候補も提案していました。Knowledgeとして蓄積する価値と、読者を集める記事としての価値を分けて示す点も気に入っていました。
ところが、旧仕様にはLoop Engineという別の基盤への記録が必須として残っていました。その基盤を削除した後も、タスクは存在しない記録機能を要求し続け、必要な機能を確認できないことを理由に定期実行を停止していました。
当時の結果を見ると、候補探索や提案までは進んでいる日もありました。つまり、検索できないから止まったのではなく、後段の記録処理が成立しないために、検索を含むタスク全体を止めていたのです。依存先を削除するときには、その機能を呼ぶ側の指示も更新する必要があります。今回はコードだけでなく、AIに渡す運用指示にも古い依存関係が残ることを実感しました。
必要な仕事を検索と提案と保存に絞る
再設計で最初に決めたのは、何を毎日してほしいかです。今回は検索と提案までを対象にし、結果を後から探せるようにKnowledgeへ保存します。記事の作成・公開・SNS投稿は、この日次タスクには含めません。
ChloroQuestでは、直近に公開された論文から10〜15件を目標に提案します。主要誌や注目度の高い雑誌を重点的に調べつつ、専門誌や小規模な雑誌も対象にします。インパクトファクターだけで足切りすると、視点や切り口が面白い論文を取りこぼすためです。
理系猫凛では、実際の開発ログ、失敗、設計判断、過去記事の改善から5候補。Ordinary Japanでは、直近の話題を入口に、日本人には当たり前でも海外の読者には説明が必要な生活・文化・制度から5候補を探します。
この件数は、水増しして埋めるためのノルマにはしませんでした。良い未提案候補が不足した日は、実数と不足理由を示します。毎日検索することと、毎日同じ数の新規候補が見つかることは、別の話です。
Knowledge価値と集客価値を分けて残す
以前の仕組みから引き継いだのが、Knowledge価値と集客価値の二軸です。例えば、植物の細胞壁が環境変化をどう感知するかという総説は、すぐに多くの読者を集める記事にはしにくくても、後の記事を書く際の基礎資料として役立つ可能性があります。一方、身近な植物を使った意外な研究は、短い記事でも読者の関心を引きやすいかもしれません。
両方を一つの点数にまとめると、どちらかの価値が見えにくくなります。今回はそれぞれを高・中・低と理由で示し、長く使える資料と、今記事にする面白さを別々に判断できるようにしました。集客価値は検索量や収益を測定した結果ではなく、編集上の仮説として扱います。
保存するのも、論文の題名だけではありません。出典、公開日、要旨、記事の切り口、評価理由、確認できた範囲、関連する記録を残します。「前にあの論文を見たな」と思ったときに、DOIや題名だけでなく、日本語の主題からも探せるようにするためです。
検索時の提案を、そのまま確定した科学知識として扱わないことも大切です。抄録まで読んだのか、全文を確認したのか、公開日が未確認なのかを残しておけば、後で記事化するときに必要な確認が分かります。
毎回新しいチャットでも仕事を継続する
日次運用では、結果をどこに出すかも見直しました。同じチャットに結果を積み続ける構成から、毎回新しいチャットで開始する独立タスクへ切り替えています。
新しいチャットでは、以前の会話を前提にしすぎない指示が必要です。そこで、最初にKnowledgeに保存した仕様書を読み、前回の検索記録や関連候補を確認するようにしました。仕様書が読めない場合にも、タスク内に保存した指示で検索・提案を続け、参照失敗を明記する設定にしています。
ここでいう独立は、過去の結果を忘れるという意味ではありません。仕事の進め方は仕様書から、既出候補はKnowledgeから読み直します。チャットは結果を受け取って相談する場とし、継続に必要な情報は別に残す構成です。
この考え方は、将来の推論エンジンの変更にもつながります。ただし、別のAIへ移すときには、Knowledgeを読む手段やツールの接続も整える必要があります。仕様を保存しただけで自動的に移行できるわけではありませんが、会話の中にしか手順がない状態より、引き継ぐべき内容は明確になります。
設定できたことと動いたことを分けて確認する
今回の検証では、初回の手動処理で3メディア合計23候補を保存し、別の検索語で再発見できることと、保存後の再読で内容のハッシュが一致することを確認しました。
その後、日次タスクの実行経路でも3ブランドの検索・保存結果を確認できました。ChloroQuestは記事候補11件とKnowledge専用1件、理系猫凛とOrdinary Japanは各5件です。ただし、ChloroQuestで出版社の公開日まで確認できた新着記事候補は6件でした。日付保留の5件を確定新着として数えず、この回は一部未達として記録しています。
「タスクの設定を保存できた」「実行が起動した」「結果が保存された」は、それぞれ別の確認です。実行要求が受け付けられただけで、最後まで成功したことにはできません。保存も受領だけで終わらせず、読み直して確認するようにしました。
2026年10月7日時点で、毎回新しいチャットに出す設定、毎日8時の日本時間、GPT-6.1 SolのMedium設定を保存後の画面で確認しています。旧タスクは停止し、二重実行を防いでいます。一方、切り替え後の新タスクが翌朝に起動し、新しいチャットへ結果を届けるところは、まだ確認前です。連日安定して動くかどうかも、今後の実行記録で判断します。
ブログのための検索を将来の材料にもする
今回、良かった検索の方向性は残し、不要になった基盤への依存と、古い運用指示を整理しました。新しい大きなシステムを作るより、既存の日次タスクとKnowledge保存を組み合わせる構成を選んでいます。
ブログに使う論文や開発記録は、その日に記事にしなくても価値があります。後から別の資料とつながることも、過去記事を更新する根拠になることもあります。記事候補を使い捨てず、出典と判断理由を一緒に残しておけば、その時点での検索が次の作業の材料になります。
今回の開発記録も、その一つです。検索が止まった経緯、残す機能の判断、設定と実行を分けた検証を記録しておくことで、次に自動化を作り直すときに同じ問題を調べ直す手間を減らせます。ブログを充実させる仕組みと、その過程をKnowledgeとして残す仕事を、今後は一緒に進めていきたいと思っています。
コメント