Codexでニュースを定期的に受け取る方法：Discordに通知する設定例

Codexで最新ニュースを確認したいけれど、毎回収集を頼むのは手間です。決めた時刻に集めて、結果を通知で受け取るにはどう設定すればよいでしょうか。

一つの方法は、Codexのクラウドに収集から通知までを予約することです。この記事では、OpenAI側の実行環境でニュースを生成し、GitHubへ詳しい結果を保存して、Discordへ要約と保存ファイルへのリンクを送る設定例を説明します。

僕が手元のPCを動かさずにニュースを受け取る方法を調べた際は、Claudeを使う実践例は見つかりましたが、Codexの例は調べた範囲では見つけられませんでした。そこで、僕の環境で生成・GitHub保存・Discord受信まで確認できた方法をまとめます。確認したのは一回の予約実行です。

毎朝6:00にニュースを生成する1本を例に、準備、設定、動作確認、内容・時刻の変更先を順に説明します。この例を実行するには、利用できるCodexのクラウド環境、Codexから読み書きできるGitHubリポジトリ、Discordの通知先を用意します。

構成と試す前提は、ショート「Codexに毎回頼まず、ニュースを定期的に受け取る構成」にまとめています。この記事では、具体的な設定と確認手順まで説明します。

まず全体像

処理を実行するのはCodexのクラウド環境です。GitHubは指示書と詳しい結果を置く場所、Discordは朝に要約を読んで詳細へ進む入口になります。

クラウド環境は、リポジトリ・ツール・通信先などをまとめた実行用の設定です。その環境を選んで始める新しいタスクの会話を、この記事では「クラウドチャット」と呼びます。今回はそのチャットに、毎回行う作業と実行時刻を指定して予約しました。

詳しい結果をGitHubへ保存してから、そのファイルを開ける通知を送る構成です。

クラウド環境はOpenAI側の実行環境なので、自分のPCがスリープしていても作業を続けられます。手元のフォルダを使うローカル定期タスクには、PCとアプリの起動が必要です。この違いから、今回はクラウド環境のチャットに予約しました。Codex Cloud、定期タスクの公式説明

以下のリポジトリ名・パス・指示書は、構成を自分の用途へ置き換えるための公開用の例です。僕の実際の指示書をそのまま転載したものではありません。

指示書と保存先をGitHubに用意する

まず、自分が管理し、Codexから読み書きできるGitHubリポジトリを用意します。ここではリポジトリ名を daily-news、保存に使うブランチを main とします。ブランチは、Gitで変更を管理する作業系列です。後の依頼文に出てくる origin/main は、接続先のGitHubリポジトリのmainを取り込んだ参照名です。

コミットはファイルの変更を履歴へ記録する操作、pushはその履歴をGitHubへ送る操作です。force pushは、送信先の履歴を書き換え得る強制送信で、この例では使いません。commitの説明、pushの説明

main へ直接保存するのは、この例で選ぶ運用です。自分のリポジトリでもその方法を使うと決め、接続するGitHubアカウントが書き込めることを確認しておきます。

置き場を次のように分けると、読む指示と生成する結果を区別できます。

daily-news/
  README.md
  instructions/
    news.md
  output/
    news/
      YYYY-MM-DD.md
      index.md

news.md は、何を集め、どうまとめるかを書くMarkdownファイルです。Markdownは、見出しや箇条書きを付けられるテキスト形式です。README.md には、このリポジトリがニュース収集用であり、どの指示書と保存先を使うかを記しておきます。

ニュースの指示書の最小例は、次のようにできます。対象分野や収集期間は自分が読みたいものへ変えてから、instructions/news.md としてGitHubの main に保存します。

# ニュース収集の指示

## 日付と対象
実行時のAsia/Tokyoで今日の日付を取得する。
開発言語・開発ツールの公式発表から、直近3日以内の情報を集める。
一次資料を実際に開き、発表日と内容を確認する。
過去のoutput/news/index.mdを読み、紹介済みの情報を除く。
新しい情報を最大3件選ぶ。見つからなければ、その結果を記す。

## 詳しい結果
日本語で、各ニュースの題名、何が変わったか、
開発でどう関係するか、一次資料のURLをまとめる。
output/news/YYYY-MM-DD.mdへ保存する。
YYYY-MM-DDには、実行時に取得した日本時間の日付を使う。
同日のファイルがあれば内容を保持して追記・更新する。
output/news/index.mdへ日付・題名・記事への相対リンクを追加し、
以前の項目を消さない。

## 保存と通知
この2種類の生成物だけをmainへコミットし、origin/mainへpushする。
GitHubに反映されたことを確認してから、Discordへ通知する。
NEWS_DISCORD_WEBHOOK_URLを環境変数から読む。
通知は各ニュースの短い要約と、当日分MarkdownへのGitHubリンク。
Webhook URLの値は、記事・指示書・ログへ書き出さない。
通知が失敗しても保存した結果を消さず、失敗した工程を報告する。

## 変更範囲
指示書や他の作業中のファイルは変更しない。
他の変更を消す操作やforce pushはしない。
保存時に競合して自動で安全に解決できなければ、
通知を止め、状況を報告する。

GitHubに保存するMarkdownは詳しい結果、Discordへ送るのは短い要約です。この分担にしておくと、朝はDiscordで概要を読み、必要なニュースだけ保存ファイルから詳しく確認できます。

クラウド環境とDiscordの通知先を設定する

指示書を読むリポジトリと、外部へ送信する設定を同じクラウド環境に用意します。

アプリの切り替えメニューで Codex を選び、新しいタスクを開きます。ChatGPT が選ばれている場合は、先にCodexへ切り替えてください。Codexの実行場所の選択

ここからは、日本語表示の操作名で説明します。新しいタスクの入力欄にある 実行場所 メニューで クラウド を選びます。続いて 環境を選択 → 環境を作成 を開き、ニュース用リポジトリを選んで セットアップを開始 を選びます。

Codexによる準備とテストの結果を確認し、設定を保存して 保存して公開 から環境を公開します。公開が完了したら、その環境で新しいタスクを始められます。クラウド環境の作成手順

Discordへの送信にはWebhookを使います。Webhookは、専用URLへデータを送ると、指定したチャンネルへ投稿できる仕組みです。Discordの サーバー設定 → 連携サービス（Integrations）→ Webhook で作成し、ニュースを受け取るチャンネルを選んでURLをコピーします。Discordの公式手順

そのURLを、Codexの環境設定へ登録します。

設定 → Codex Cloud → 環境 で、対象環境の … → 編集 を開きます。セットアップ画面の 環境を編集 から設定パネルを開きます。
環境変数 → 環境変数を管理 で、名前を NEWS_DISCORD_WEBHOOK_URL、値をコピーしたWebhook URLにします。
インターネットアクセス の Codex のインターネットアクセスを許可 を有効にし、追加の許可ドメイン に discord.com を追加します。ニュース調査に使うサイトへシェルから通信する場合は、そのホストも許可します。
変更を保存し、設定パネルの公開で環境をもう一度公開します。

環境変数は、プログラムが名前を指定して値を読める設定です。僕はWebhook URLを直接読む処理だったため、この欄へ登録しました。変数を登録するだけでは通信先は許可されないので、通信設定も確かめます。環境変数と通信先の公式説明

Webhook URLには投稿に使える認証情報が含まれます。指示書には変数名だけを書き、URLの値をチャットや生成物へ表示しないようにします。送信結果はHTTPのステータス番号と、URLを取り除いたエラーの要約で報告させます。シェルのトレースや詳細なHTTPデバッグ出力にも、URLを出さないようにします。

新しいクラウドチャットで通知だけを試す

更新した環境を選び、新しいクラウドチャットを開きます。再公開した環境を新しいタスクが使う一方、既存のタスクは自分の作業状態を保持するためです。環境更新の公式説明

僕もこの順で通知を試しました。最初は保存済みのニュースを使うと、収集や生成が通らない問題と、Discordへの送信が通らない問題を切り分けられます。

OWNER/REPO とファイル名を自分のものへ直し、たとえば次のように依頼します。保存済みのニュースがまだなければ、動作確認用と明記した短いMarkdownを自分のリポジトリへ先に用意します。

このチャットに接続されたクラウド環境で、
GitHubのOWNER/REPOにあるoutput/news/YYYY-MM-DD.mdを使い、
Discordへの通知だけをテストしてください。

NEWS_DISCORD_WEBHOOK_URLを使い、要約とその保存ファイルへの
GitHubリンクを1通送ってください。記事の再生成は不要です。
Webhook URLの値は表示せず、送信したファイルのリンクと
HTTPステータス番号を報告してください。
失敗時はURLを除いたエラー要約だけを報告し、生ログは貼らないでください。

Discordを開き、要約が届き、リンクから指定した保存ファイルを読めることを確認します。GitHubのリポジトリが非公開なら、スマホ側でも閲覧権限のあるGitHubアカウントで開きます。

通知では、環境変数から読んだWebhook URLへ、Content-Type: application/json を指定してHTTP POSTします。たとえば次のJSONなら、content の文字列がチャンネルへ届きます。allowed_mentions は、本文中の文字が意図せずメンションとして通知されるのを防ぐ設定です。DiscordのWebhook実行仕様

これは説明用の架空のニュースです。実際の通知では、保存を確認した当日分のファイルへのリンクと、生成した要約へ置き換えます。

{
  "content": "本日のニュース\n・開発ツールAの更新：変更点と、自分の開発で確認したい点。\n詳細：https://github.com/OWNER/REPO/blob/main/output/news/YYYY-MM-DD.md",
  "allowed_mentions": {
    "parse": []
  }
}

一回の予約実行で生成・保存・受信を確かめる

登録できたことと、処理が最後まで通ることを分けて確認します。僕は毎朝の設定を維持したまま、一回限りの確認実行も予約しました。

毎朝の定期設定は変更せず、次に指定する日本時間に、
同じクラウドチャットで一回限りの確認タスクを予約してください。
実行日時：YYYY-MM-DD HH:MM（Asia/Tokyo）

毎朝のニュースタスクと同じ実行指示を使い、
ニュース生成、mainへの保存、Discord通知まで行ってください。
結果は生成物のGitHubリンク、保存結果、HTTPステータス番号で報告してください。
失敗時はURLを除いたエラー要約だけを報告してください。

日時はこれから実行できるものに置き換え、毎朝の実行と重ならない時間にします。同日にもう一度生成する場合も、指示書の「既存ファイルを保持して追記・更新する」条件を使います。

僕の確認では、当日分のニュースMarkdownと索引がmainに保存され、Discordへの送信はHTTP 200で成功していました。僕自身もDiscordに届いた内容を確認しました。ここで確かめたのは、予約した一回の処理が生成・保存・受信まで通ることです。

自分の設定では、次の順で現物を見ます。

確認する場所	成功を確認するもの	ここで止まったら見るもの
予約したクラウドチャット	指定時刻後の実行報告、実際に読んだ指示書	有効状態、実行時刻、タイムゾーン、使っている環境
GitHubのmain	当日分Markdownと索引が保存され、内容を開ける	保存先と書き込み権限、競合、実行報告の保存エラー
Discord	要約が届き、リンクから同じ当日分Markdownを開ける	通知先、変数名、通信先の許可、送信エラー、リンク先の閲覧権限

HTTPの成功応答は送信結果の確認であり、手元で通知内容を読めた確認も別に行います。保存したファイルがあるのに通知だけ届かない場合は、記事を作り直す前に通知工程を調べられます。

内容は指示書、時刻は予約で変更する

ニュースの対象分野・選定条件・出力形式は、GitHubの instructions/news.md を編集してmainへ保存します。予約が毎回その実ファイルを読み直すので、次回は更新後の指示を使う形になります。時刻を変えたい場合は、指示書ではなく定期タスクの予定を変更します。

Webhookや通信先など環境の設定を変えた場合は、再公開した環境の新しいチャットで通知を確かめ、そこに必要な予約を用意します。移行時には旧チャットの予約を止め、同じ処理が二重に実行されないようにします。

別の情報収集へ当てはめるときも、指示書の内容、保存先、通知先、時刻を読み替えられます。まずはニュース1本で、GitHubへ残した詳しい結果をDiscordから読めるところまで、一回の予約で確認するのが出発点です。