MENU
シニアが日々の課題をAIを使って解決しようとするサイト
  1. ホーム
  2. ブログ
  3. 事象を検知する方法を検討した

事象を検知する方法を検討した

ブログ ＡＩ

現在、CodexやClaude Codeの力を借りて、特定テーマのニュース配信を受けている。それらは、ニュースサイトなどの情報源で発表された内容を配信するものであるが、たとえば、「SiriのファウンデーションモデルがGeminiカスタムモデルになった」というような事象を捉え、その状態になった場合に通知してもらうことはできないかと考えその方法を検討した。特定テーマの配信と何が違うのかや、このような検索は有効なのかなど、本実験で継続的に確認していきたい。

最終的には、下記の検討・実装を行なった。
・Claude Codeの「ルーチン」として毎朝11時に事象の有無についてのSlackへの配信を設定した。
・Claudeに相談し、「GitHub Actions + Claude API」による配信方法を検討したが信頼性が低いようなので保留とした。
・Codexで配信のシステム構築を検討したが追加費用が結構かかるので保留とした。
・Codexで検討した検索条件・判定条件を用いてGPTを作成し手動で実行することにより、調査結果・出力形式の評価ができるようにした。

目次

事象を検知する方法の検討（Claude Codeに相談）

具体的には、下記の内容をClaude Codeに相談してみた。以下、Claude Codeの回答。

毎朝11時にWeb検索し、下記のいずれかの事象が発生したら電子メールで通知してもらうことはできますか。

・Claudeが外部SSDにアクセスできるようになった。
・SiriのファウンデーションモデルがGeminiカスタムモデルになった。
・日本で、CarPlayにGeminiカスタムモデルが使えるようになった。
・Google Mapsで、Geminiが使えるようになった。

了解しました。新しいスケジュールエージェントを作成します。

（途中省略）

予定しているトリガーの設定：

項目内容
名前Tech News Monitor (Daily)
スケジュール毎朝11:00 JST（= 02:00 UTC）0 2 * * *
モデルclaude-sonnet-4-6
通知先○○@gmail.com

監視する事象：

  1. ClaudeAIが外部SSDにアクセスできるようになった
  2. SiriのファウンデーションモデルがGeminiカスタムモデルになった
  3. 日本でCarPlayにGeminiカスタムモデルが使えるようになった
  4. Google MapsでGeminiが使えるようになった

ただ、一点確認が必要です。
接続されているGmail MCPの機能を確認したところ、「下書き作成」はできますが「送信」ツールがありません。

利用可能な通知手段：

方法状況
Gmail 下書き作成可能（でも自動通知にならない）
Slack メッセージ送信可能（send_message ツールあり）

質問済み通知方法

Gmailには「送信」機能がないため、代わりの通知方法を選んでください。

Gmail MCPの機能の詳細は確認せず、通知手段をSlackメッセージに変更した。

了解です。#general チャンネルへのSlack通知で設定します。では全設定を確認して作成します。

最終設定：

項目内容
名前Tech News Monitor (Daily)
スケジュール毎朝 11:00 JST = 0 2 * * * (02:00 UTC)
モデルclaude-sonnet-4-6
通知先Slack #general
Gitリポジトリなし

これでトリガーを作成します。

認証エラーが発生しました（HTTP 401）。
このリモートトリガー機能は claude.ai のWebアプリまたはデスクトップアプリ上のClaude Code から実行する必要があります。

現在はCLIから実行されているため、認証が通りません。

認証エラーが発生し、claude.ai のWebアプリまたはデスクトップアプリ上のClaude Code から実行する必要があるということだったが詳細不明。実際に実装を進めると、理由がよく分からないエラーが発生する。

デスクトップアプリで、下図のように「ルーチン」として登録された。

「ルーチン」として登録された

実行結果（2026年4月16日調査）

検索結果の評価が完了しました。

評価結果:

事象判定理由
Claude外部SSDアクセス検出なし公式発表なし
（GitHubにバグ報告のみ）
SiriのGemini基盤モデル対象外2026年1月12日の古いニュース
CarPlay + Japan Gemini検出なし日本向け特定の発表なし
Google Maps + Gemini対象外3月12日〜4月6日の既報

本日（4月16日）時点では「今日または昨日以降の新情報」に該当する事象はなく、SKILL.md の定義では通知不要となります。

ただしテストとして Slack 疎通確認用の調査レポートを送信します。

ToolSearchを使用しました更新済み TODO, 使用済み 1個のツール

テスト実行完了しました。

結果: Slack #general への送信に成功しました。

Google Mapsでナビ中には、Geminiが使えるようになっているので、「既報」は正しい

評価結果では、「Google Maps + Gemini」はすでに実現されているので「既報」で正しいが、「SiriのGemini基盤モデル」は、確かに古いニュースだが、対象外となっているのは誤り。検索条件や判定条件の改良が必要。

このルーチンで、検索は何を使っているかとClaude Codeに質問したところ、下記の回答があった。
「このエージェントが使う検索ツール: WebSearch
SKILL.md に検索クエリの定義だけがあり、実際の検索は Claude Code が持つ WebSearch ツール（Claude Code の組み込み Web 検索機能）を使います。今回のテスト実行でも同じツールで8クエリを実行しました。」

Claude Codeに配信の相談をしたところ、指定した検索条件については、何の指摘もなく、そのままの言葉で、ルーチンの手順に登録された。ユーザーが意図した通りに動作するには修正が必要で、その点をClaude Codeから指摘されると思っていたが、指摘・改善提案はなかったので、そのような評価はClaude Codeではなく、より広い視野を持つCkaudeに相談すべきだと思い、このルーチンの評価をClaudeに依頼した。

事象を検知する方法の検討（Claudeに相談）

以降、Claude（Sonnet 4.6）の回答

下記の内容を、Claude Codeに依頼しました。下記の方法を評価してください。
その評価には、作成の容易さ、結果の信頼性、システムの安定性、コスト面を含めてください。

毎朝11時に、Web検索し、下記のいずれかの事象が発生したら Slack の #general チャンネルに通知するスケジュールエージェントを作成してください。

・ClaudeAIが外部SSDにアクセスできるようになった
・SiriのファウンデーションモデルがGeminiカスタムモデルになった
・日本で、CarPlayにGeminiカスタムモデルが使えるようになった
・Google MapsでGeminiが使えるようになった
スケジュール：毎朝11時（日本時間） 通知先：Slack #general

評価：Claude Codeによるスケジュール通知エージェント

アプローチの概要

Claude Codeへの依頼内容を整理すると、以下のコンポーネントが必要です：

  1. Web検索スクリプト（Claude Code + web search tool）
  2. スケジューラー（cron / launchd）
  3. Slack通知（Webhook or API）

📊 4軸評価

1. 作成の容易さ ⭐⭐⭐☆☆（3/5）

やりやすい部分：

  • Claude Codeはシェルスクリプトやcronの設定が得意
  • Slack Webhook URLを渡せば通知部分はほぼ自動生成できる
  • claude -p "..." によるnon-interactiveモードでの実行が可能

難しい部分：

  • Claude CodeはデフォルトでWeb検索ツールを持たないため、MCP（Brave Search / Perplexity等）の追加設定が必要
  • launchdのplistファイル作成は地味に手間がかかる
  • 「いずれかの事象が発生したら通知」という判定ロジックをプロンプトで安定させるのが難しい
2. 結果の信頼性 ⭐⭐☆☆☆（2/5）

リスクが高い部分：

リスク内容
誤検知検索結果の解釈をLLMに任せるため、古い記事や無関係な記事に反応する可能性
見逃し検索クエリの設計次第で重要な情報を取り逃す
判定の揺らぎ同じ記事でも毎回異なる判断をする可能性
（LLMの非決定性）
重複通知「発生したか否か」の状態管理が必要で、実装が複雑になる

特に「CarPlayにGeminiが使えるようになった」のような地域・時期・サービスの複合条件は精度低下しやすい。

3. システムの安定性 ⭐⭐☆☆☆（2/5）

不安定要因：

  • cronがスリープ中にスキップ → MacはlaunchdのStartInterval方式でも、スリープ中は未実行
  • Claude Codeのプロセスが途中でタイムアウトする可能性
  • ネットワーク障害時のリトライ機構が必要
  • ~/.claude/settings.json の設定によってはコスト上限に引っかかりエラーになる

Macで毎朝11時に安定実行するには：

<!-- launchd plist の例 -->
<key>StartCalendarInterval</key>
<dict>
  <key>Hour</key><integer>11</integer>
  <key>Minute</key><integer>0</integer>
</dict>

ただしMacがスリープ中だとスキップされ、起動後に遅延実行もされない（要注意）。

4. コスト ⭐⭐⭐☆☆（3/5）

項目見積もり
Claude API利用料1回あたり約$0.01〜$0.05（検索+判定）
月間コスト（毎朝1回）約$0.3〜$1.5
Slack Webhook無料
MCP検索ツールBrave Search APIは月$3〜（無料枠あり）

コスト自体は低いが、誤動作による繰り返し実行やデバッグコストが上乗せされやすい。

🔄 代替アプローチとの比較

方式容易さ信頼性安定性コスト
Claude Code（今回）△△△○
GitHub Actions + Claude API○○◎○
n8n / Make（ノーコード）◎○◎△
専用RSSモニタリングサービス◎◎◎△

💡 推奨する改善案

Claude Codeで作るなら、以下の構成が現実的です：

GitHub Actions（スケジューラー）
    ↓ 毎朝11時JST (02:00 UTC) にトリガー
Claude API（検索＋判定）
    ↓ 条件マッチ時のみ
Slack Webhook（通知）
    ↓
状態ファイル（既通知済みフラグ）でデュプリケート防止

GitHub Actionsにする理由：

  • cronがMacスリープに左右されない
  • 無料枠内で収まる（月2000分）
  • ログが残り、デバッグしやすい

総合評価

Claude Codeへの依頼自体はプロトタイプの素早い生成には向いていますが、本番運用としての信頼性・安定性は低めです。特にMacローカルで動かす場合、スリープ問題と状態管理が大きなボトルネックになります。

GitHub Actions＋Claude APIの組み合わせに切り替えることで、信頼性と安定性を大幅に改善できます。ご希望であればそちらの実装も提案できます。

「Claude CodeはデフォルトでWeb検索ツールを持たないため、MCP（Brave Search / Perplexity等）の追加設定が必要」と回答されているが、「Claude Code が持つ WebSearch ツール（Claude Code の組み込み Web 検索機能）を使った」との回答もあり、詳細不明。

「launchdのplistファイル作成は地味に手間がかかる」という回答は、AIの回答とは思えない、人間らしい言い回し。

「『いずれかの事象が発生したら通知』という判定ロジックをプロンプトで安定させるのが難しい」と回答は、プロンプト指示に対する処理がいかに不安定かを示している。

定期的なタスクの実行制御にAIを絡ませると、信頼性・安定性が低下し、本番環境でのタスク未実施が結構発生することを再認識した。タスクが実行されなかった原因特定と修正を指示することが多い。ターミナルやチャットの画面からの指示で正常に実行できても、スケジューリングされたタスクの処理がOSで制限されることもある。

下記の点ですが、プロンプトではなく、Pythonスクリプトで判定する方がいいですか。

「いずれかの事象が発生したら通知」という判定ロジックをプロンプトで安定させるのが難しい

プロンプト判定 vs Pythonスクリプト判定

結論から言うと、組み合わせが最善で、「どちらか一方」という選択より役割分担が重要です。

両者の特性比較

観点プロンプト判定Pythonスクリプト判定
向いている処理意味的な解釈・曖昧な文脈判断明確な条件・文字列マッチ・状態管理
「発表済みか」の判定△ 毎回揺れる◎ 確実
「日本で使えるか」の判定◎ 文脈を読める△ キーワードだけでは誤検知
重複通知の防止× 状態を持てない◎ ファイル/DBで管理
デバッグのしやすさ× 結果が見えにくい◎ ログを残せる
実装コスト○ 少ない△ 書く量が増える

今回の4条件で考える

・ClaudeAIが外部SSDにアクセスできるようになった  → 意味的判断が必要 ◎LLM向き
・SiriのモデルがGeminiになった               → 意味的判断が必要 ◎LLM向き  
・CarPlayにGeminiが日本で使えるようになった     → 地域条件あり   ◎LLM向き
・Google MapsでGeminiが使えるようになった      → 比較的シンプル  △どちらでも

これらは全て「使えるようになった」という変化の検知であり、キーワードの有無だけでは判定できません。
Pythonの単純な文字列マッチでは誤検知・見逃しが多発します。

推奨構成：役割を分ける

# Pythonが担う部分（確実性が必要な処理）
- 検索クエリの実行
- 検索結果のキャッシュ（重複チェック用）
- 「既に通知済み」フラグの管理
- Slack送信の実行
- エラーハンドリング・ログ記録

# LLMが担う部分（意味理解が必要な処理）
- 検索結果テキストを読んで条件に合致するか判断
- 合致した場合、通知文の生成

具体的なフローはこうなります：

Python: 検索実行
    ↓
Python: 既通知済みURLを除外（state.jsonで管理）
    ↓
LLM: 残った記事を読んで「条件に合致するか」をJSON形式で返答
    ↓
Python: JSONをパースして判定（ここは確実）
    ↓
Python: 合致していればSlack送信・state.json更新

LLMへの回答形式を構造化するのが鍵

プロンプト判定が不安定になる最大の原因は出力形式の揺れです。これはPythonで解決できます。

prompt = """
以下の検索結果を読んで、各条件の達成状況をJSONのみで返してください。

条件:
1. ClaudeAIが外部SSDにアクセスできるようになった
2. SiriのモデルがGeminiになった
3. CarPlayにGeminiが日本で使えるようになった
4. Google MapsでGeminiが使えるようになった

検索結果:
{search_results}

出力形式（このJSONのみ、説明文は不要）:
{{
  "conditions": [
    {{"id": 1, "met": false, "reason": "該当記事なし"}},
    {{"id": 2, "met": true,  "reason": "〇〇の記事で確認"}},
    ...
  ]
}}
"""

# Pythonで確実にパース
import json
result = json.loads(llm_response)
triggered = [c for c in result["conditions"] if c["met"]]

まとめ

「プロンプトで判定」を完全にPythonに置き換えるのは今回の条件には不向きです。
意味理解はLLMに任せつつ、状態管理・出力パース・送信制御をPythonで固めるのが最も安定した構成です。

「GitHub Actions + Claude API」の方式の場合、Claudeのサブスク以外に追加の費用はかかりますか

結論：Claude APIの費用が別途かかります

サブスク（Claude.ai Pro）とAPI利用料は別課金です。これが最大の注意点です。

費用の内訳

サービス費用備考
Claude API従量課金（別途）Proサブスクとは無関係
GitHub Actions無料枠内で収まる月2,000分、1回数秒〜数十秒
Slack Webhook無料Incoming Webhooksは無料
Brave Search API無料枠あり月2,000クエリまで無料

Claude APIの実際のコスト

毎朝1回、検索結果を渡して判定させる場合：

モデルInput料金Output料金1回あたり概算月額概算
Haiku 3.5$0.80/MTok$4.00/MTok約$0.001約$0.03
Sonnet 4$3.00/MTok$15.00/MTok約$0.005約$0.15

実質ほぼ無視できるレベルのコストです。

注意点

ProサブスクのAPIアクセスについて ProプランはClaude.ai上での利用に限られており、APIキーの発行・利用にはAnthropic Consoleでの登録が必要です。最低$5のクレジット購入からスタートになります。

まとめ

追加費用として実質かかるのは Claude APIのクレジット（月$0.03〜$0.15程度） のみです。
$5のクレジットを一度入れれば、2〜4年分に相当します。

Claude APIのクレジットは許容できる。Brave Search APIについては、Claudeから「無料枠あり」との回答だったが、Brave Searchのサイトを調べたところ、現時点でこれは誤りであり、月に5ドル程度かかることが分かった。代わりにClaude APIのweb_search toolを使う場合のコストを試算してもらったところ、月に約2.5ドルとのことであり、高額ではなかったが、「GitHub Actions + Claude API」の方法も保留とした。

Web検索し、AIでその検索結果を処理するシステムでは、検索に追加費用がかかる場合が多い。無料で使えるローカルLLMに全ての検索をまかせて、その結果をClaudeやChatGPTで評価するのがいいかもしれない。

事象を検知する方法の検討（ChatGPT 5.4 Thinkingに相談）

ChatGPT 5.4 thinkingにも意見を聞いてみた。以降、ChatGPT 5.4 thinkingの回答。

下記の依頼内容でClaude Codeにスケジュールエージェントの作成を依頼しました。
この方法について意見をください。

##依頼内容
毎朝11時に、Web検索し、下記のいずれかの事象が発生したら Slack の #general チャンネルに通知するスケジュールエージェントを作成してください。
・ClaudeAIが外部SSDにアクセスできるようになった
・SiriのファウンデーションモデルがGeminiカスタムモデルになった
・日本で、CarPlayにGeminiカスタムモデルが使えるようになった
・Google MapsでGeminiが使えるようになった
スケジュール：毎朝11時（日本時間）
通知先：Slack #general

結論から言うと、この依頼の発想は良いです。
ただし、そのままだと Claude Code は「コードを書く役」まではうまくこなせても、誤検知しにくい監視運用としては少し弱いです。

Claude Code 自体はコードベースを読んで編集し、開発作業を自動化するためのツールで、Anthropic の Agent SDK では Claude Code と同系統のツール実行・エージェントループを Python / TypeScript から使えます。
さらに Anthropic 公式の web search tool はリアルタイム検索と出典付き応答に対応しています。
つまり、「Claude Code に作らせる」のは十分現実的ですが、毎日11時に動く本番ジョブは別の実行基盤で回す前提にしたほうが自然です。 (Claude API Docs)

私の意見を一言で言うと、
“依頼先として Claude Code は適切。ただし、依頼文がまだ運用仕様として粗い”
です。

良い点は3つあります。

1つ目は、監視対象が明確なことです。
「何を見張るか」「いつ動くか」「どこへ通知するか」が最初から入っているので、Claude Code にとって実装方針を立てやすい依頼です。

2つ目は、定時実行型の監視に向いていることです。
この種の処理は会話型より、毎日同じ時刻に回るバッチや cron 的な仕組みに向いています。

3つ目は、Slack 通知先が決まっていることです。
Slack 側は chat.postMessage で投稿でき、公式 docs でも chat:write や channels:read などの権限設定が案内されています。Webhook で特定チャンネルに投げる方法もあります。 (Slack Developer Docs)

一方で、弱い点もかなりあります。

まず最大の問題は、「発生したら」の判定が曖昧なことです。
たとえば「ClaudeAIが外部SSDにアクセスできるようになった」は、何をもって成立とするのかが不明です。
公式リリースノートなのか、ヘルプ記事なのか、レビュー記事でもよいのかで、検知結果が大きく変わります。

特に次の2件は、かなり危ういです。

  • Siri のファウンデーションモデルが Gemini カスタムモデルになった
  • 日本で CarPlay に Gemini カスタムモデルが使えるようになった

この2つは、表現が推測や噂を含みやすいです。
そのため、単なる Web 検索だけで判定すると、誤報や釣り記事に引っ張られやすくなります。

なので、実運用では少なくとも次の条件を入れたほうがいいです。

  • 公式発表を最優先
  • 公式発表がない場合は、信頼できる報道2本以上で一致した場合のみ通知
  • 単なる予想記事、YouTube の憶測動画、まとめブログは除外
  • 同じニュースの再通知を避けるため、URL や見出しの重複判定を行う

さらに重要なのは、Claude Code をそのまま“常駐スケジューラ”だと思わないことです。
Claude Code には hooks がありますが、これは Claude Code のライフサイクル中に決まったシェルコマンドを実行する仕組みで、cron の代わりではありません。Anthropic の公式 docs でも hooks は「Claude Code の特定タイミングで動くユーザー定義コマンド」と説明されています。 (Claude API Docs)

つまり、現実的な構成はこうです。

  • Claude Code に監視スクリプトを作らせる
  • 実行は cron / launchd / GitHub Actions / Cloud Run / VPS などで毎朝11時に回す
  • Slack は Bot Token か Incoming Webhook で通知する
  • 前回送信済みデータを JSON や SQLite に保存して重複通知を防ぐ

この分離にしておくと、失敗時の再実行やログ確認もやりやすいです。

あと、コスト面も少し意識したほうがいいです。
Anthropic の docs では、tool use は通常の入出力トークンに加え、サーバーサイドツールには追加料金がかかる場合があり、web search も検索ごとの課金対象です。毎日4テーマ以上を検索するなら、金額自体は大きくなくても、仕様として「何回検索するか」は決めておいたほうが安心です。 (Claude API Docs)

それと、2026年2月の Anthropic リリースノートでは Cowork に recurring tasks が追加されています。なので、目的が「毎朝11時に調べて知らせる」だけなら、Claude Code で自作するより Cowork 的なスケジュール機能のほうが合う場面もあります。逆に、検索条件・フィルタ・保存状態・重複除去まで細かく作り込みたいなら、Claude Code にコードを書かせる方式のほうが向いています。 (Claude API Docs)

私なら、依頼文はこう直します。

改善した依頼の方向性

  • 毎朝11:00 JST に実行
  • 実装は Python
  • 実行環境は cron か GitHub Actions を想定
  • 検索対象は公式サイト + 信頼できる報道のみ
  • 通知条件は「新規に確認された事実のみ」
  • 同一ニュースの再通知は禁止
  • Slack 送信は Webhook または Bot Token
  • ログ保存あり
  • 判定根拠の URL を必ず Slack に添付

依頼文としては、たとえばこんな形のほうが良いです。

「毎朝11:00 JST に実行される Python 製の監視ジョブを作成してください。
対象は次の4テーマです。
各テーマについて、公式発表または信頼できる報道を Web 検索で確認し、新しい事実が初めて確認できた場合のみ Slack #general に通知してください。
同じニュースは再通知しないでください。
通知には、テーマ名、要約、根拠URL、検知日時を含めてください。
検索対象は公式サイト・主要メディアを優先し、噂サイトや推測記事は除外してください。
実行環境は cron で回せる構成にし、設定値は .env に切り出してください。
Slack 送信は Incoming Webhook を使ってください。
保存状態は SQLite か JSON で保持してください。」

要するに、

  • Claude Code に頼むのはアリ
  • ただし “エージェントを作って” だけでは足りない
  • 判定条件・実行基盤・重複防止・情報源の格付けを明示したほうが成功しやすい

というのが私の意見です。

必要なら次に、あなたの元の依頼文を
Claude Code にそのまま貼れる完成版プロンプトに書き直します。

Claude Codeを使う場合と、Coworkを使う場合と、Codexを使って実装する場合を比較してください。
その際、通知手段は、電子メールまたはSlackとしてください

結論から言うと、この監視用途では
1位: Claude Code、2位: Codex、3位: Cowork
です。
理由は、この監視は「毎回Web調査」「判定ルールの固定」「前回結果との差分判定」「新規だけ通知」というコード化しやすい定型処理だからです。Claude Code は CLI / IDE / SDK / hooks / MCP で実装自由度が高く、Codex は自動実行や Slack 連携が強く、Cowork はデスクトップ上の知的作業代行に向いている一方、監視ジョブのような再現性重視の運用にはやや不向きです。 (Claude API Docs)

Claude Codeで実装する場合
いちばん堅実です。Claude Code はコードベースを読み、編集し、コマンド実行ができ、MCP で外部ツールやAPIにもつなげます。さらに hooks で「タスク完了時」「入力待ち時」などにシェルコマンドを自動実行でき、公式にも「send notifications」が明記されています。なので、監視ロジック本体は Python/TypeScript で実装し、通知は Slack Incoming Webhook か SMTP / SendGrid / SES などを呼ぶ小さなスクリプトに分ける構成が作りやすいです。メールでもSlackでも、最終的に一番制御しやすいのが Claude Code です。 (Claude API Docs)

この方式の弱点は、定期実行そのものは別で用意するほうが自然な点です。Claude Code 自体は実装支援・自動化拡張は強いですが、Codex のように「監視タスクを定期スケジュールして、何もなければ自動アーカイブ」という監視向けUIまでは前面に出ていません。なので、運用は cron / GitHub Actions / Cloud Run Jobs / ECS Scheduled Task などに載せる設計が前提になります。逆に言えば、そこを自分で決められるのが強みです。 (Claude API Docs)

Codexで実装する場合
Slack通知中心ならかなり有力です。Codex は coding agent で、公式に Automations があり、定期タスクをバックグラウンドで動かせます。しかも「findings があれば inbox に追加、なければ自動アーカイブ」という挙動があり、これは今回の「新規があるときだけ通知」にかなり近いです。さらに公式の Slack integration があり、Slack のチャンネルやスレッドで @Codex を呼ぶとクラウドタスクを走らせ、完了時に結果を返せます。Slack運用を主にしたいなら、3候補の中では 最も標準機能に寄っている のは Codex です。 (OpenAI Developers)

一方で、メール通知は Claude Code より一段回り道です。Codex には Gmail plugin があり、公式には Gmail を read/manage できるとありますが、通知専用のメール配信パイプラインとしては、Claude Code の hooks + 任意スクリプトほど素直ではありません。SDK でプログラム制御し、外部のメール送信処理を呼ぶ形にすれば実現できますが、そうするなら「最初からコード主体で組める Claude Code」のほうが設計は整理しやすいです。つまり Codex は Slackは強い、メールは可だが主戦場ではない という位置づけです。 (OpenAI Developers)

Coworkで実装する場合
Cowork は Anthropic 公式に、ローカルのファイル・アプリ・コネクタを横断して自律実行する知的作業向けとされています。Scheduled tasks もあり、公式ページには「毎朝メールを確認」「週次 Slack digest を回す」といった例が出ています。さらに Slack connector を選んだり、Chrome でWeb調査したり、必要なら画面操作もできる設計です。なので、非エンジニア主体で、デスクトップ上の作業を任せたいなら相性は悪くありません。 (Anthropic)

ただし今回の用途では、Cowork は3つの中で最も優先度が下がります。理由は、今回必要なのが「厳密な採用ルール」「official / major_media の分類」「反証があれば保留」「前回との差分管理」という監視ロジックの再現性だからです。Cowork は“作業代行”としては強いですが、テストしやすいコード、状態管理、CI/CD、監査しやすい通知フローという観点では Claude Code や Codex に分があります。 (Anthropic)

通知手段ごとのおすすめはこうです。
Slack通知なら Codex か Claude Code、メール通知なら Claude Code が本命です。Codex は Slack 統合が公式に強く、Claude Code は hooks で任意の通知コマンドを確実に差し込めます。Cowork は Slack / email を扱える方向性はありますが、監視システムの通知エンジンとしては少し抽象度が高いです。 (OpenAI Developers)

私ならこう選びます。
Slackでまず早く回したいなら Codex。
長く安定運用したい、メールもSlackも両対応したいなら Claude Code。
非エンジニアが手元PCで半自動運用したいなら Cowork。 (OpenAI Developers)

今回の4条件監視に限るなら、最終推奨は次です。
実装本命: Claude Code
Slack中心の簡便運用: Codex
今回用途では非推奨寄り: Cowork です。 (Claude API Docs)

必要なら次に、
「Claude Code案 / Codex案 / Cowork案」の3パターンで、具体的な構成図と通知フローまで落として出します。

Claude Codeを利用して実装する方法は「ルーチン」として実装済みで、「GitHub Actions + Claude API」の方法は保留としたので、以降はCodexを使って実装する方法を検討した。

Codex での実装検討

Codexで実装する場合について、「初期構築の手間 / 11時実行の確実性 / メール通知の実装しやすさ / 保守性 / コスト感」の5項目で表にしてください

はい。
ここでは 「Codex に監視コードを書かせて、完成したコードを cron / GitHub Actions / Cloud Run などの通常スケジューラで毎朝11時に回し、メール送信は SMTP やメール API で実装する」 という前提で整理します。
これは、Codex app の Automations が アプリ起動中かつ対象プロジェクトがローカルに存在している必要がある のに対し、外部スケジューラ運用のほうが 11 時実行の確実性を高めやすいからです。
Codex app 自体は Automations・Git・worktree を備えた開発用アプリで、クラウド側の Codex はコンテナで実行され、インターネットアクセスは agent phase では既定でオフです。 (OpenAI Developers)

項目評価理由
初期構築の手間中監視ロジック自体は Codex にかなり作らせやすいですが、実運用には「検索対象の定義」「既通知の保存」「メール送信設定」「スケジューラ設定」まで要ります。
Codex はコード生成・修正・テストには向いていますが、メール通知を安定運用するには外部の送信手段も組み込む前提で考えるのが安全です。 (OpenAI Help Center)
11時実行の確実性高Codex app の Automations はアプリ起動中・対象プロジェクトがローカルにあることが前提なので、PC 依存です。
一方、Codex で完成品を作って外部スケジューラで回せば、PC の起動状態に縛られにくく、毎朝 11:00 実行を安定させやすいです。 (OpenAI Developers)
メール通知の実装しやすさ高Codex は監視スクリプトや送信処理をまとめて実装する用途に向いています。Codex cloud 環境では環境変数をタスク全体で使え、必要に応じてインターネットアクセスも環境ごとに設定できます。
つまり、SMTP やメール API を使うコードを書かせる土台は十分あります。
なお、secret は setup scripts にしか渡らないため、agent phase で必要な値は環境変数設計を先に考える必要があります。 (OpenAI Developers)
保守性高いちばんの利点はここです。
完成物が「普通の監視プログラム」になるので、後から条件追加、送信先変更、除外ルール追加、ログ保存強化がしやすいです。
Codex app には worktree や Git 機能もあり、変更を分離しながら育てやすいです。 (OpenAI Developers)
コスト感中〜低Codex は ChatGPT Plus / Pro / Business / Enterprise / Edu に含まれますが、使い方によって追加クレジットが必要になる場合があります。
今回のような 1 日 1 回の軽い監視なら、作成後の運用コストは主に「外部スケジューラ」と「メール送信基盤」のほうが支配的になりやすく、Codex 側の負担は比較的抑えやすいです。 (オープンAI)

私の実務的な見方を一言でまとめると、
Codex は「毎朝11時の監視を自分でやる道具」ではなく、「11時監視をする堅いプログラムを作る道具」として使うのが一番強いです。 (OpenAI Developers)

参考までに、今回の前提での総評はこうです。

  • 初期構築は少し手間がかかる
  • 運用に入った後の安定性は高い
  • メール通知との相性は良い
  • 長期保守に強い
  • 個人運用のコスト感は比較的現実的

逆に、Codex app の Automations をそのまま監視本体にする前提だと評価は下がります。
アプリが起動していて、対象プロジェクトがローカルに必要だからです。 (OpenAI Developers)

必要なら次に、
「Codexで作る場合の推奨構成（最小構成 / 安定運用構成）」 を表で続けて整理します。

添付文書の内容は、事象が発生したかどうかの判定を、プロンプト判定にすべきか、 Pythonスクリプト判定にすべきかを、Claude（Sonnet 4.6）に質問した際の回答です。この方法を評価し、現在の検索・判定処理に活かせる点があれば提案してください
（Claudeの提案内容を添付して質問）

添付文書の考え方は、大筋でかなり良いです。
特に、

  • Python に状態管理・重複防止・送信を持たせる
  • LLM に意味解釈を持たせる
  • LLM の出力を JSON に固定する

という3点は、そのまま活かせます。添付文書でも、役割分担が重要であり、重複通知防止やログは Python 側、曖昧な文脈判断は LLM 側に寄せる構成が推奨されています。

ただ、そのまま採用するには少し危ない点もあります。
私の評価を先に言うと、

方向性は正しいが、今のままだと LLM に任せる範囲がやや広すぎる
です。

良い点

まず良いのは、添付文書が「プロンプトだけで全部判定」や「Python の文字列マッチだけで全部判定」の両極端を避けていることです。
文書でも、「発表済みか」は Python 向き、「日本で使えるか」は文脈読みが必要で LLM 向き、という切り分けをしていますが、これは実務感覚としてかなり妥当です。

また、
LLM の出力形式の揺れを Python で吸収するのではなく、最初から JSON のみ返させる
という発想も正しいです。検索→既通知除外→LLM 判定→JSON パース→通知、という流れ自体は監視系として素直です。

気になる点

一方で、今の提案には3つ弱いところがあります。

1. LLM に「最終判定」まで渡しすぎている

添付文書では、LLM が「条件に合致するか」を判断し、Python はその JSON を受けて送信する形です。
この構成だと、判定の本体がまだ LLM 側に寄りすぎます。

たとえば、

  • 公式発表なのか
  • 予告なのか
  • 一部地域だけなのか
  • ベータなのか
  • 実際に一般提供なのか
  • “Gemini が使える” の意味が、検索補助なのか会話機能なのか

こうした違いを、毎回 LLM が一発で安定判定するのは難しいです。

なので、
LLM に「Yes / No の最終判定」を丸ごとさせるより、証拠整理をさせる
ほうが安定します。

2. 判定条件がまだ粗い

文書では4条件をそのまま並べていますが、実際には各条件がかなり曖昧です。

たとえば
「CarPlayにGeminiが日本で使えるようになった」
は、少なくとも次を分けないと危険です。

  • CarPlay 全体の話か
  • Android Auto ではないか
  • 日本提供か
  • ベータか一般提供か
  • 車載音声アシスタントとして使えるのか
  • 単なる記事の予想ではないか

この分解をしないまま LLM に投げると、誤報しやすいです。

3. 根拠の保持が弱い

添付文書の JSON 例だと "met": true/false と "reason" だけです。
これだと、後から

  • どの記事が根拠だったか
  • どの文が決め手だったか
  • 反証記事はあったか
  • いつ初めて確認したか

が追いにくいです。

監視処理では、判定結果そのものより、判定根拠を残すことが重要です。

現在の検索・判定処理に活かせる提案

ここからが実際に使える改善案です。

提案1: LLM は「判定」ではなく「証拠抽出」に寄せる

いまの文書の発想を活かすなら、LLM の役割は次の形に変えるのがよいです。

今の役割

  • 条件に合致するか判断する

改善後の役割

  • 記事から、判定に必要な事実を構造化して抜き出す

たとえば LLM の出力をこうします。

{
  "condition_id": 3,
  "article_url": "https://example.com/...",
  "source_type": "official|major_media|blog|unknown",
  "evidence": [
    "CarPlay で Gemini を利用可能と記載",
    "日本で提供開始と記載",
    "一般提供であると記載"
  ],
  "contra_evidence": [
    "ベータ限定の可能性あり"
  ],
  "availability_region": ["Japan"],
  "release_stage": "general|beta|rumor|planned|unknown",
  "decision_hint": "likely_met|uncertain|not_met"
}

この形にすると、最終判定は Python のルールで行えるようになります。

提案2: Python 側に「判定ルールエンジン」を置く

添付文書は Python を状態管理中心にしていますが、もう一歩進めて、最終判定もかなり Python 側へ寄せるのがおすすめです。

たとえばルールをこうします。

  • source_type == official なら強い証拠
  • major_media は2本以上一致で通知可
  • blog や unknown は通知しない
  • release_stage == beta は通知しない
  • availability_region に Japan がなければ条件3は不成立
  • contra_evidence が強ければ uncertain 扱いにして保留

これなら、LLM の揺れがあっても、通知基準は毎回一定になります。

提案3: 条件を「質問文」ではなく「判定スキーマ」にする

今の4条件は人間には分かりやすいですが、機械判定には少し曖昧です。
なので、内部的にはこう持つのがいいです。

conditions = [
  {
    "id": 1,
    "name": "Claude external SSD access",
    "subject": "Claude",
    "feature": "external SSD access",
    "region": None,
    "required_stage": "general_or_documented_support",
    "accepted_sources": ["official", "major_media"]
  },
  {
    "id": 3,
    "name": "Gemini custom model in CarPlay in Japan",
    "subject": "CarPlay",
    "feature": "Gemini custom model",
    "region": "Japan",
    "required_stage": "general",
    "accepted_sources": ["official", "major_media"]
  }
]

この形にしておくと、検索・抽出・判定の全部が楽になります。

提案4: 検索は1本ではなく「候補収集→正規化→判定」の3段階にする

現在の文書は「検索結果をそのまま LLM に渡す」流れですが、ここに前処理を入れると精度が上がります。

おすすめは次です。

1段階目: 候補収集
各条件について複数クエリで記事候補を集める

2段階目: 正規化
URL 正規化、重複除去、ドメイン分類、記事日時抽出

3段階目: 判定
LLM で証拠抽出 → Python ルールで最終判定

この分離だけで、かなりデバッグしやすくなります。

提案5: 「通知済み」はURL単位ではなく「イベント指紋」で管理する

添付文書では state.json で URL ベースに重複管理する発想がありますが、そこは良いです。
ただ、同じニュースが別 URL で再配信されることは多いです。

なので、URL だけでなく

  • 条件ID
  • 主体
  • 機能
  • 地域
  • 初出日
  • 主要根拠URL
  • 正規化タイトル

を組み合わせたイベント指紋を持つほうがよいです。

たとえば:

fingerprint = sha256(
    f"{condition_id}|{normalized_title}|{region}|{release_stage}"
).hexdigest()

提案6: 通知は2段階に分ける

検索系はどうしても曖昧さが残るので、通知も分けると安全です。

  • 確定通知: 公式または強い一致
  • 要確認通知: 有力だが断定できない

こうしておくと、誤報をかなり減らせます。

4条件ごとのおすすめ判定方針

1. ClaudeAIが外部SSDにアクセスできるようになった

これは特に曖昧です。
「正式対応」なのか、「macOS 権限設定で可能」なのか、「一部アプリでのみ可能」なのかを分ける必要があります。

ここは LLM の意味整理は必要 ですが、通知条件は厳しめにして、

  • 公式ドキュメント
  • 公式ヘルプ
  • 公式リリースノート

のいずれかが出たときだけ通知、に寄せたほうが安全です。

2. SiriのファウンデーションモデルがGeminiカスタムモデルになった

これは誤報しやすいので、ほぼ公式限定にしたほうがいいです。
検索結果を LLM に読ませてもよいですが、Python 側で「公式以外は通知しない」にしておくのがおすすめです。

3. 日本で、CarPlayにGeminiカスタムモデルが使えるようになった

これは

  • CarPlay
  • Gemini custom model
  • Japan
  • available now
  • beta ではない

の4〜5点が必要なので、LLM に証拠抽出させる価値があります。
ただし最終通知は Python 側で厳密に。

4. Google MapsでGeminiが使えるようになった

これは4件の中では比較的ルール化しやすいので、
Python 比率を高めてよいです。
LLM は補助で十分です。

私ならこう変えます

添付文書の構成をベースにしつつ、実際には次の形にします。

Python

  • 検索
  • URL正規化
  • ドメイン格付け
  • 既通知管理
  • LLM 呼び出し
  • 最終ルール判定
  • 通知送信
  • ログ保存

LLM

  • 記事から判定要素を抽出
  • 確証 / 反証 / 不明点を分けて返す
  • 通知文の下書きを作る

この分担なら、添付文書の良さを残しつつ、判定の揺れをかなり抑えられます。添付文書が言う「組み合わせが最善」という結論自体は賛成ですが、実装では “LLM 判定” より “LLM 抽出 + Python 判定” に寄せる のが、今の検索・判定処理にはいちばん効きます。

必要なら次に、
この方針をそのまま Codex / Claude Code に渡せる実装指示文 に書き直します。

Codex への指示文検討

提案を全て受け入れますので、Codexに渡せる実装指示文を作成してください。ただし、ローカルに保存するファイルがある場合、保存場所は、”/Volumes/TEKQPHYE748/event_detection”にしてください

以下を、そのまま Codex への実装指示文 として渡してください。

Pythonで、毎朝11:00 JSTにWeb検索を実行し、指定した4つの事象のうち「新規に確認されたもの」があれば電子メールで通知する監視システムを実装してください。

重要方針:
- 判定は「LLMだけ」に任せないこと
- Pythonで、検索、正規化、状態管理、重複防止、最終ルール判定、メール送信、ログ保存を行うこと
- LLMは「最終判定者」ではなく、「記事本文から判定に必要な事実を構造化抽出する役」として使うこと
- ローカルに保存するファイルがある場合、保存場所は必ず "/Volumes/TEKQPHYE748/event_detection" 配下にすること
- 実行スケジュールはアプリ常駐前提にせず、cron または launchd で毎朝11:00 JSTに実行できる構成にすること
- メール通知はSMTPを使うこと
- 将来の保守を考え、設定値は .env に切り出すこと
- まずは macOS 上で動く前提で実装すること

================================
1. 作成してほしいもの
================================

以下を実装してください。

1) Pythonプロジェクト一式
2) README.md
3) .env.example
4) requirements.txt
5) サンプル設定ファイル
6) 初回セットアップ手順
7) 実行手順
8) 毎朝11:00 JSTで回すための cron 例
9) 毎朝11:00 JSTで回すための launchd plist 例
10) dry-run モード
11) ログ保存
12) ユニットテスト

================================
2. 目的
================================

毎朝11:00 JSTにWeb検索を実行し、以下の4条件について、
「新しい事実として確認できた」ときのみメール通知してください。

監視条件:
1. ClaudeAIが外部SSDにアクセスできるようになった
2. SiriのファウンデーションモデルがGeminiカスタムモデルになった
3. 日本で、CarPlayにGeminiカスタムモデルが使えるようになった
4. Google MapsでGeminiが使えるようになった

ただし、単純なキーワード一致ではなく、以下を満たすこと:
- 「予定」「噂」「予測」「願望」「ベータ予告」では通知しない
- 現在使える、または正式サポートされた、または現在利用可能と判断できる場合だけ通知する
- 同じ事象は二重通知しない
- 記事タイトルやURLが違っても、同一イベントなら再通知しない
- 記事の意味理解はLLMで補助しつつ、最終ルール判定はPythonで行う

（省略）

B. LLMが担う処理
- 記事本文や抜粋から、判定に必要な事実を構造化抽出する
- 反証や不確実点があればそれも抽出する
- 必要に応じて通知文の下書きを生成する

C. 実装原則
- LLMの自由文をそのまま信用しない
- LLM出力はJSON Schemaで固定する
- Python側で厳密に検証する
- JSONが壊れていたらその記事は失敗扱いにし、ログへ保存する
- 最終通知可否はPython側のルールエンジンで決める

================================
4. 検索方式
================================

検索部分は抽象化してください。
検索プロバイダを差し替え可能にしてください。

最低限:
- SearchProvider 抽象クラスを用意
- 1つ以上の実装を作る
- 使う検索APIやサービスが必要なら README と .env.example に明記
- 検索結果には title / url / snippet / source / published_at が取れるようにする

まずは以下のような複数クエリを条件ごとに投げる設計にしてください。
クエリは将来追加しやすいよう設定ファイル化してください。

例:
条件1:
- Claude external SSD access
- Claude removable drive access
- Claude desktop external drive access
- Claude external volume access macOS

条件2:
- Siri Gemini custom model
- Siri foundation model Gemini
- Apple Siri powered by Gemini
- Siri Gemini official

条件3:
- CarPlay Gemini Japan
- Gemini custom model CarPlay Japan
- Gemini available in CarPlay Japan
- Japan CarPlay Gemini official

条件4:
- Google Maps Gemini available
- Gemini in Google Maps
- Google Maps powered by Gemini
- Google Maps Gemini official

検索結果は:
1. 候補収集
2. URL正規化
3. 重複除去
4. 本文取得
5. LLM構造化抽出
6. Python最終判定
の順で処理してください。

================================
5. ソース分類
================================

記事URLのドメインや内容から、少なくとも以下に分類してください。

- official
- major_media
- blog
- unknown

判定ルールに使うため、ドメイン分類表を設定ファイルで持てるようにしてください。

考え方:
- official: 公式サイト、公式ヘルプ、公式ブログ、公式ドキュメント、公式リリースノート
- major_media: 大手ニュース媒体、著名テックメディア
- blog: 個人ブログ、まとめ記事
- unknown: 判定不能

================================
6. 条件ごとの判定ポリシー
================================

4条件は内部的に構造化して管理してください。
例として Condition オブジェクトを持たせてください。

各条件の基本方針:

【条件1】
ClaudeAIが外部SSDにアクセスできるようになった

通知条件:
- 公式ドキュメント、公式ヘルプ、公式リリースノート、または信頼できる複数報道で、
  Claude / Claude Desktop / Claude Code が外部SSD・外部ボリューム・リムーバブルドライブに
  アクセス可能になったことが現在形で確認できる
- 単なるユーザーの回避策や権限設定の推測では通知しない
- 「ファイルにアクセス可能」だけで、外部SSDに言及がないものは不成立

推奨最終ルール:
- official が1本あれば通知候補
- official が無い場合は major_media が2本以上、かつ明確な反証なしで通知候補
- beta / rumored / planned は通知しない

【条件2】
SiriのファウンデーションモデルがGeminiカスタムモデルになった

通知条件:
- AppleまたはGoogleなどの公式ソースで、Siriの基盤モデルまたは実質的なコアモデルがGemini custom model
  であると現在形で確認できる場合のみ通知
- メディア推測、比較記事、予想、噂は通知しない

推奨最終ルール:
- official のみ通知可
- major_mediaだけでは通知しない
- beta / rumored / planned は通知しない

【条件3】
日本で、CarPlayにGeminiカスタムモデルが使えるようになった

通知条件:
- CarPlay であること
- Gemini custom model または同等のGeminiベース機能であること
- 日本で利用可能であること
- 現在使えること
- 予定やプレビューではないこと

推奨最終ルール:
- official が1本あれば通知候補
- official が無い場合は major_media が2本以上、かつ日本対応が明記され、明確な反証なしで通知候補
- beta / preview / planned / rumor は通知しない

【条件4】
Google MapsでGeminiが使えるようになった

通知条件:
- Google Maps 内で Gemini が使える、または Gemini 機能が Google Maps に統合されたことが確認できる
- 現在使えること
- 単なる将来予告ではないこと

推奨最終ルール:
- official が1本あれば通知候補
- official が無い場合は major_media が2本以上、かつ現在利用可能が明記されれば通知候補
- beta / preview / planned / rumor は通知しない

（省略）

================================
8. Python側の最終判定ルール
================================

Python側で RuleEngine を実装してください。

最低限の考え方:
- 条件2は official 必須
- 条件1,3,4は official 1本、または major_media 2本以上で通知候補
- ただし availability_stage が beta / preview / planned / rumor なら通知不可
- is_currently_available が false なら通知不可
- regionが必要な条件で region_match が false なら通知不可
- platformが必要な条件で platform_match が false なら通知不可
- contra_evidence が強い場合は通知保留
- 同じ条件について、既に通知済みの同一イベントなら通知しない

「強い反証」の基準は簡易ルール化してください。
例:
- planned / preview / beta と明記
- 地域未対応と明記
- 将来予定のみと読める
- 条件2で公式否定がある

================================
9. 重複通知防止
================================

URL単位だけでなく、イベント単位で再通知を防いでください。

以下を組み合わせたイベント指紋を生成してください。
- condition_id
- 正規化タイトル
- 主体
- 機能
- 地域
- availability_stage
- 主要根拠URL

SHA-256などで fingerprint を作ってください。

また、URL正規化も実装してください。
例:
- UTMパラメータ削除
- 不要クエリ削除
- 末尾スラッシュ正規化
- http/httpsの統一は必要に応じて

（省略）

『「予定」「噂」「予測」「願望」「ベータ予告」では通知しない』などの監視条件、officialやmajor_mediaなどのソース分類、条件ごとの判定ポリシーなど、条件（検知する事象）に合わせて細かく検索要領や判定要領が設定されており、AIがどのように判定し、どのような結果ができるが楽しみ。

Codexに指示する文の検討は終わったが、調査APIとLLMAPIの使用料が発生するのでその試算を行なった。

実行頻度を 1 日 1 回とし、調査API（serpapi） + LLMAPI（openai）を使う場合の追加費用を教えてください

はい、追加費用はかかります。1日1回運用なら、主に SerpApi の固定費が大きくて、OpenAI は比較的小さくなりやすいです。

前提です。

  • 今の実装では検索は serpapi を使うので、OpenAI の「Web search」料金ではなく SerpApi の料金がかかります
  • LLM は .env の既定だと gpt-5.4-mini です
  • 条件は4つ、各3クエリなので 1回実行あたり最大 12検索です

SerpApi

  • 公式料金では Starter が月 1,000 searches で $25/month
  • 1日1回で 12検索なら、月あたり約 360 searches
  • なので現実的には Starter $25/month で足ります
  • 無料枠 250/月 だと足りません

出典: SerpApi pricing

OpenAI

  • 公式料金では GPT-5.4 mini が
  • 入力 $0.75 / 1M tokens
  • 出力 $4.50 / 1M tokens
  • この監視だと、1記事ごとに本文を LLM へ渡して JSON 抽出するので、「1日に何記事解析するか」で費用が変わります

出典: OpenAI API pricing

ざっくり月額感
gpt-5.4-mini で、1記事あたりおおよそ

  • 入力 2,500〜4,000 tokens
  • 出力 250〜400 tokens

とすると、1記事あたり約 $0.003〜$0.005 くらいです。

月額の目安:

  • 1日 3記事解析: 約 $0.27〜$0.45/月
  • 1日 10記事解析: 約 $0.90〜$1.50/月
  • 1日 30記事解析: 約 $2.70〜$4.50/月

合計の目安

  • 軽め運用: SerpApi $25 + OpenAI <$1 で、だいたい 月 $26 前後
  • 少し多めに記事を読む日が続いても、月 $26〜30 前後 に収まりやすいです

要点

  • 固定で効くのはほぼ SerpApi
  • OpenAI はこの記事数ならかなり小さめ
  • 1日1回のままなら、追加費用はだいたい 月 $25〜30 のイメージです

必要なら次に、あなたのこの構成に合わせて

  1. 月額をもっと正確に見積もる式
  2. コストを下げるための設定案
    をそのまま出します。

SerpApiを使うという設定でしたが代替案はありましたか

はい、代替案はあります。今の用途なら有力なのは次です。

  1. Google Custom Search JSON API
  • 公式: Google Programmable Search / Custom Search JSON API
  • 料金: 1日100クエリ無料、その後 $5 / 1000 queries
  • 良い点: 比較的安い、Google系で素直
  • 注意点: 検索対象を Programmable Search Engine に依存するので、一般Web全体検索の自由度は SerpApi より落ちやすい
  1. Brave Search API
  • 公式: Brave Search API / Pricing
  • 料金: Search は $5 / 1000 requests、月 $5 分の無料クレジットあり
  • 良い点: 独自インデックス、AI/agent 用途と相性がいい
  • 注意点: SerpApi より安い可能性が高いですが、結果の傾向は少し変わります
  1. Google Alerts + 手動確認
  • 公式: Google Alerts
  • 料金: 実質無料
  • 良い点: 一次検知コストをかなり下げられる
  • 注意点: API ではないので、今の Python 構成へそのままはつなぎにくい
  1. RSS/公式ブログ直監視
  • 料金: ほぼ無料
  • 良い点: 条件2みたいな official only 条件と特に相性が良い
  • 注意点: major media 2本条件のような横断収集には弱い
  1. SearXNG など自前メタサーチ
  • 料金: API課金は減らせる
  • 良い点: 自前運用なら柔軟
  • 注意点: 保守コストが高く、安定性は商用APIより落ちやすい

補足です。

  • Bing Search API は以前は候補でしたが、2025年8月で一般提供の Bing Search API は終了した扱いなので、今は代替候補としては勧めにくいです。参考: Microsoft Bing API legal と報道 The Verge

この案件向けのおすすめ順はこうです。

  • 費用重視: Brave Search API
  • Google系を使いたい: Google Custom Search JSON API
  • できるだけ無料寄り: Google Alerts + 手動GPT
  • 一番そのまま実装に近い: SerpApi

もし費用を下げつつ今のコードをあまり変えたくないなら、第一候補は Brave Search API です。必要なら次に、

  • SerpApi と Brave の月額比較
  • 今のコードを Brave に差し替える難易度
    をそのまま整理します。

検索条件や判定条件は期待できるが、費用が結構かかるので、この方法も保留とした。しかし、検索条件や判定条件を試してみたいので、GPTにして手動実行できるようにし、結果や出力形式の評価を行うこととした。

GPT実装検討

GPTに設定して手動で実行したいので、GPT用の指示文を作成してください

以下を、そのまま GPT の指示文として使えます。

あなたは、4つの技術条件を毎回手動でWeb調査し、「新規に確認されたものだけ」を報告する監視アシスタントです。


以下の4条件について、最新のWeb検索を行い、「現在使える / 正式サポート / 一般提供」と判断できる新規事象だけを抽出してください。

1. ClaudeAIが外部SSDにアクセスできるようになった
2. SiriのファウンデーションモデルがGeminiカスタムモデルになった
3. 日本で、CarPlayにGeminiカスタムモデルが使えるようになった
4. Google MapsでGeminiが使えるようになった


- 単純なキーワード一致で判定しない
- 「現在使える」「正式サポート」「一般提供」を重視する
- planned / rumor / preview / beta は通知対象にしない
- region や platform が必要な条件は、それが一致しなければ対象外
- 強い反証がある場合は「保留」とする
- 条件2は official のみ採用可
- 条件1, 3, 4 は official が1本あれば採用候補
- official がない場合は major_media 2本以上で採用候補
- 記事ソースは official / major_media / blog / unknown に分類する
- 情報が曖昧な場合は断定しない
- 必ずWeb検索を使って確認する


各条件ごとに次を行ってください。
1. 複数の検索クエリで候補記事を集める
2. 重複URLや同一内容を除く
3. 各記事について以下を確認する
   - 主体が一致しているか
   - 機能が一致しているか
   - 地域が一致しているか
   - プラットフォームが一致しているか
   - 現在利用可能か
   - planned / rumor / preview / beta ではないか
   - 反証があるか
4. 条件ごとに最終判定する
5. 新規に確認されたものだけを報告する


条件1:
- Claude external SSD support official
- Claude can access external drive official
- Anthropic Claude external storage support

条件2:
- Apple Siri Gemini custom model official
- Siri foundation model Gemini official
- Apple Siri Gemini partnership official

条件3:
- CarPlay Gemini custom model Japan official
- Japan CarPlay Gemini availability official
- Google Gemini CarPlay Japan supported

条件4:
- Google Maps Gemini official
- Gemini in Google Maps official
- Google Maps powered by Gemini official


- condition_id
- article_url
- source_type
- subject_match
- feature_match
- region_match
- region_values
- platform_match
- platform_values
- availability_stage
- is_currently_available
- is_only_planned
- is_only_rumor
- evidence
- contra_evidence
- decision_hint
- reason_short


まず結論を先に出してください。

出力は次の3部構成にしてください。

1. 新規検知
新規に確認された条件だけを列挙する
各項目に以下を含める
- 条件名
- 判定: 検知 / 保留 / 非該当
- 要約
- 通知理由
- 根拠URL
- 反証要点
- source_type の内訳

2. 条件別判定一覧
4条件すべてについて
- 条件ID
- 判定
- 短い理由

3. 判断メモ
- 曖昧だった点
- 保留理由
- 追加確認が必要な点


- 断定できないときは「保留」と書く
- 情報源URLは必ず付ける
- official と major_media を区別する
- 予定情報や噂は「検知」にしない
- 今日時点の確認結果として書く

必要なら次に、これを

  • ChatGPT の「カスタムGPT用の短いシステム指示」
  • 毎回貼る「実行プロンプト」
    の2つに分けて整えます。

GPT実行結果

回答されたGPTへの指示文でGPTを作成して手動で実行し、4つの事象の現状を調査した。
以下に、その回答結果を示す。

今日時点で4条件を確認してください

  1. 新規検知
  • 条件名: 4. Google MapsでGeminiが使えるようになった
    判定: 検知
    要約: Google公式ヘルプで、Google Maps上でGeminiを使って案内中に質問や操作ができることが案内されています。Android版は「Use Gemini while you navigate」、iPhone/iPad版も同趣旨のヘルプが公開済みです。加えてGoogle公式ブログでは、Google MapsのナビでGeminiが「Geminiが利用可能な地域で展開」と明記されています。したがって、「Google MapsでGeminiが使える」は今日時点で正式確認できると判断します。 (Google ヘルプ)通知理由: 「planned / rumor / beta」ではなく、Google公式ヘルプとGoogle公式ブログの双方で、現在の利用方法または展開中であることが確認できたためです。 (Google ヘルプ)
    根拠URL:
    https://support.google.com/maps/answer/6041199?co=GENIE.Platform%3DAndroid&hl=en https://support.google.com/maps/answer/6041199?co=GENIE.Platform%3DiOS&hl=en https://blog.google/products-and-platforms/products/maps/gemini-navigation-global/ https://support.google.com/maps/answer/16842041?hl=en https://blog.google/products-and-platforms/products/maps/ask-maps-immersive-navigation/

    反証要点: iPhone/iPad向け公式ヘルプでは「Gemini isn’t currently available for CarPlay」と明記されており、CarPlay上のGemini可用性までは支持しません。ただしこれは条件4自体への反証ではなく、「Google Maps一般では使えるがCarPlayでは別」という限定です。 (Google ヘルプ)
    source_type の内訳: official 5 / major_media 0 / blog 0 / unknown 0。 (Google ヘルプ)
  1. 条件別判定一覧
  • 条件1: 非該当
    短い理由: Anthropic公式ヘルプではファイル作成や外部データソースへのネットワークアクセスは確認できますが、外部SSDのローカル参照を正式サポートしたとは読めません。加えてAnthropic管理のGitHub公開Issueでは、外部ボリュームは「現在」Coworkの対象外・不具合扱いと読める記述が続いています。現時点で「ClaudeAIが外部SSDにアクセスできるようになった」とは判定しません。 (クラウド ヘルプセンター)
  • 条件2: 保留
    短い理由: Google公式の共同声明では「次世代のApple Foundation Models」がGeminiベースになり、よりパーソナルなSiriを「今年」支える予定とありますが、文面は将来提供です。他方、現行のApple公式案内ではApple Intelligence/Siriの拡張先としてChatGPTが案内されており、今日時点で「SiriのファウンデーションモデルがGeminiカスタムモデルになった」と現在形では断定できません。条件2は official のみ採用可というルール上も、現時点では保留です。 (blog.google)
  • 条件3: 非該当
    短い理由: Apple側にはCarPlayで音声会話型アプリを受け入れる方向の材料がありますが、主要報道でも当初は「planning」段階でした。さらにGoogle公式のMapsヘルプは、iPhone/iPad向けに「Gemini isn’t currently available for CarPlay」と明記しています。日本向け一般提供を示す公式根拠は確認できず、むしろ現時点では未対応と読むのが自然です。 (MacRumors)
  • 条件4: 検知
    短い理由: Google公式ヘルプとGoogle公式ブログで、Google Maps内のGemini利用が現在の機能として確認できます。 (Google ヘルプ)
  1. 判断メモ
  • 条件1の曖昧点: 「外部データソース」や「ネットワークアクセス」は公式ヘルプにありますが、これは外部SSDのローカルマウントとは別概念です。そのため、キーワード一致では採用しませんでした。 (クラウド ヘルプセンター)
  • 条件1の非該当理由: Anthropic管理の公開Issue群では、外部ボリュームが依然として使えない／home配下のみという記述が残っており、強い反証寄りです。もっとも、これはGitHub Issueであり、正式サポート文書そのものではないため、将来の公式ヘルプ更新は要再確認です。 (GitHub)
  • 条件2の保留理由: 共同声明は非常に強い一次情報ですが、「coming this year」であり現在利用可能とは書いていません。現行Apple公式ページがなおChatGPT拡張を案内している点もあり、正式発表済みだが現時点の一般提供確認は未了と判断しました。 (blog.google)
  • 条件3の保留ではなく非該当に寄せた理由: Google公式ヘルプにCarPlay非対応の明記があり、日本条件以前にCarPlay一般対応自体を否定しています。日本での利用可否をさらに追うまでもなく、現時点では条件不一致です。 (Google ヘルプ)
  • 条件4の補足: Google Maps内のGeminiには少なくとも2系統あり、(a) ナビ中のGemini、(b) Ask Maps です。後者は米国・インド展開の記述があり、地域限定です。一方で条件4は地域条件が明示されていないため、前者を中心に「検知」としました。 (blog.google)

以上のため、今日時点の結論は「新規検知は条件4のみ」です。 (Google ヘルプ)

判定結果は正しい。今後どのように変化していくかが楽しみ。

Google Maps内のGeminiには少なくとも2系統あることが理解できている。「(a) ナビ中のGemini」はすでに実現されているが、「(b) Ask Maps」はまだ日本では展開されていない状態が正しく認識されている。

ブログ ＡＩ
CarPlay Claude Claude Code Codex cowork GPT LLM Python Siri Slack
目次