「GitHub」の投稿

結論

Codexに毎回ニュース収集を頼まず、定期的に結果を受け取るには、収集から通知までを予約します。僕は、CodexのクラウドでGitHubの指示書からニュースを生成・保存し、Discordへ要約と保存ファイルへのリンクを送る構成にしました。一回の予約実行で、生成・保存・受信まで確認しています。

この構成を試すには、GitHubの指示書と保存先、外部へ通信できるCodexのクラウド環境、Discordの通知先を用意します。

最新の開発情報を知るために、Codexへその日のニュース収集を頼む。これを繰り返す代わりに、集める条件と時刻を設定し、結果が通知で届くようにする使い方です。

ここでは、収集条件をGitHubの指示書に書き、Codexのクラウドへ毎朝の実行を予約します。届いた要約をDiscordで読み、気になるニュースの詳細はGitHubのMarkdownから開きます。Markdownは、見出しや箇条書きを付けられるテキスト形式です。

三つの役割を分けると、何を用意するかが見えます。

• Codexのクラウド環境：OpenAI側でニュース生成を実行する場所。GitHubの指示書を読み、指定時刻に処理を進めます。
• GitHub：収集条件を書いた news.md と、生成した詳しい結果の保存先。通知からそのファイルを開けます。
• Discord：要約と保存ファイルへのリンクを受け取る入口。専用URLへ送信するとチャンネルに投稿するWebhookを使います。

クラウドで動くので、自分のPCがスリープしていても処理を続けられます。手元のフォルダを使うローカル定期タスクにはPCとアプリの起動が必要なため、この用途では実行先をクラウドにします。クラウド環境、定期タスク

試す前の準備は、次のように分けられます。

• GitHubに、収集条件を書く news.md と結果の保存先を用意します。たとえば開発ツールの公式発表を集める、といった条件を指示書へ書きます。自分が管理し、Codexから読み書きできるリポジトリを使います。
• DiscordのWebhook URLを、処理が名前を指定して値を読める環境変数に登録します。
• そのリポジトリとDiscordへの通信を使えるクラウド環境を公開し、その環境を選んで新しいタスクの会話（クラウドチャット）を開きます。

僕はこのチャットで通知を試してから、ニュースの毎朝の予約を登録しました。その設定を維持したまま、同じ処理を一回だけ走らせる確認用の予約も追加しました。この確認用の予約では、ニュースのMarkdownとその一覧がGitHubへ保存され、Discordへの送信が成功し、僕自身も届いた要約とリンクを確認しています。

同じ構成を試すときは、予約が登録されたことだけで済ませず、生成物ができたか、GitHubに保存されたか、Discordで受け取ってリンクを開けたかを順に見ます。この三つがそろえば、収集を毎回依頼せずに、届いた通知から詳しいニュースを読める形を確かめられます。