はじめに
毎朝 5 時に Mac が勝手に動き出し、Claude Code が Web を巡回し、2 本のディープリサーチレポートを生成して Obsidian に保存する。起きたらコーヒーを淹れながら iPhone で読む。
この仕組みを、Python コード 0 行で作りました。シェルスクリプト 1 本とプロンプトファイル 2 つだけです。
使ったのは Claude Code の非対話モード（claude -p）。Max プラン定額内なので追加コストはゼロ。表示上は毎回 $2.15 かかっていますが、財布は痛みません。
この記事では、このシステムの設計と実装を紹介します。ただし、「どう作ったか」だけでなく、そこに至るまでの計画プロセスにこそ伝えたいことがあります。
計画に時間をかけるのが最速の近道だった
3 セッションかけて「何を作らないか」を決めた
このプロジェクトは単発のセッションで生まれたものではありません。実装に入るまでに 3 セッション、計画と調査を繰り返しました。
これまで何本かのプロジェクトを Claude Code で実装してきた経験から、ひとつの確信がありました。
最初のプランニングにいちばん時間を費やすべきだ。
実装は Claude Code が速い。コードを書く速度はもはやボトルネックではありません。ボトルネックは「何を作るか」「何を作らないか」の意思決定です。ここを曖昧なまま実装に入ると、途中で方針転換が起き、書き直しが発生し、結局遅くなる。
だから今回は、納得のいく計画ができるまで一行もコードを書きませんでした。
セッション 1: 選択肢を全部並べて潰す
最初のセッションでは、リサーチエンジンの技術選定をしました。
| 選択肢 | 品質 | コスト | 複雑性 | 判定 |
|---|---|---|---|---|
| OpenAI Deep Research API | 高 | $1.3〜$3.4/回（月$78〜$204） | 中 | コスト不可 |
| GPT Researcher (OSS) | 中 | API コスト同等 | 高 | 同上 |
| Gemini CLI + Claude Code | 高 | ゼロ | 中（認証2箇所、Python必要） | 過剰 |
| Claude Code 単体 | 中 | ゼロ | 低 | 採用 |
OpenAI の Deep Research は品質が高いですが、月$200 近くかかります。毎日自動実行する用途には合いません。Gemini CLI との組み合わせも検討しましたが、認証管理が 2 箇所に分散し、Python のグルーコードが必要になります。
最小構成でまず動かし、品質に不満があれば拡張する。 この判断が結果的に正解でした。
セッション 2: プロンプト設計が全てを決めると気づく
2 回目のセッションで気づいた重要なことがあります。
テーマ選定とプロンプトの品質がシステム全体の価値を決める。
単に Hacker News や GitHub Trending のスコアが高い記事を拾ってくるだけでは、表面的なレポートが量産されるだけです。「次に自分が何を作るべきか」のヒントを得るには、テーマ選定に意思を込める必要がありました。
そこで 3 つのスコアリング基準を設計しました。
- ウィスパートレンド度: まだ多くの人が気づいていない変化か
- 変化の兆し: 静的な知識ではなく、今まさに動いている領域か
- 開発可能性: 自分のスキル（Python/Swift/TypeScript）で作れそうか
あるポッドキャストで、AI リサーチの達人が「情報収集・生成は自動化できるが、人間の理解・消化がボトルネックだ」と語っていたのが印象に残っていました。だからこそ、量ではなく質を制御する仕組みが必要でした。
セッション 3: 詳細仕様書を作り、実装は一瞬で終わった
3 回目のセッションでは Plan A（Claude Code 単体）の詳細仕様書を作成しました。
- 全ファイルの構成と役割
- CLI フラグの選定理由（なぜ
--append-system-prompt-fileであって--system-prompt-fileではないか） - リサーチプロトコルの 8 ステップ
- テーマスコアリングの重み配分
- 環境サニタイズの手順
この仕様書が完成した時点で、やるべきことは完全に明確でした。
実装セッションでは「plan-a-implementation.md を実装して」の一言で、全 8 ファイルが一気に生成されました。CLI フラグの実在確認、認証チェック、フル実行テストまで含めて、特筆すべきエラーはゼロ。
計画を 3 回繰り返したから、実装が一瞬で終わった。 これは逆説のように聞こえますが、Claude Code での開発を何本かやってきた実感です。
完成したシステムの全体像
プロジェクト構成
daily-research/
├── config.toml # テーマソース・スコアリング基準
├── past_topics.json # テーマ履歴（重複防止）
├── prompts/
│ ├── research-protocol.md # リサーチプロトコル（本体）
│ └── task-prompt.md # 実行指示（7行）
├── templates/
│ └── report-template.md # レポートフォーマット
├── scripts/
│ ├── daily-research.sh # launchd から呼ばれるラッパー
│ └── check-auth.sh # OAuth 認証チェック
├── com.shimomoto.daily-research.plist # launchd 設定（毎朝 AM 5:00）
└── logs/ # 実行ログ
Python ファイルはありません。シェルスクリプトがインフラ、プロンプトがアプリケーションロジック。
実行フロー
launchd (AM 5:00)
↓
daily-research.sh（環境サニタイズ + 認証チェック）
↓
claude -p "$(cat prompts/task-prompt.md)" \
--append-system-prompt-file prompts/research-protocol.md \
--allowedTools "WebSearch,WebFetch,Read,Write,Glob,Grep" \
--dangerously-skip-permissions \
--max-turns 40 --model sonnet \
--output-format json --no-session-persistence
↓
Claude Code が research-protocol.md に従い自律実行:
[1] config.toml + past_topics.json 読み込み
[2] WebSearch でテーマソース巡回 → スコアリング → 2 テーマ選定
[3] テーマごとに「知るべき重要な問い」を 5 つ自己生成
[4] 多段階リサーチ（WebSearch × 20 回 + WebFetch）
[5] レポート 2 本生成 → Obsidian vault に保存
[6] past_topics.json 更新
↓
macOS 通知で完了を通知
核心: --append-system-prompt-file という設計判断
CLI フラグの選択で最も重要だったのが、--append-system-prompt-file と --system-prompt-file の使い分けです。
| フラグ | 動作 | リスク |
|---|---|---|
--system-prompt-file |
デフォルトのシステムプロンプトを全置換 | Claude Code のツール利用能力が失われる可能性 |
--append-system-prompt-file |
デフォルトに追記 | Claude Code の判断力を維持しつつプロトコルを注入 |
全置換すると、Claude Code の持つ WebSearch や Write の使い方に関する知識を失うリスクがあります。一方、追記ならデフォルトの能力をそのまま活かしつつ、リサーチプロトコルを注入できます。
これが「プロンプトがコード」の設計思想です。Claude Code 自体がすでに Web 検索、ファイル読み書き、パターン検索の能力を持っている。Python でオーケストレーションコードを書く代わりに、プロンプトで判断ロジックを制御するだけで済みます。
環境サニタイズ: 見落とすと課金される落とし穴
daily-research.sh の冒頭で行う処理が地味に重要です。
# APIキーが設定されていると従量課金になるため確実に除去
unset ANTHROPIC_API_KEY
# launchd 環境は PATH が最小限。ユーザー環境を読み込む
export PATH="/opt/homebrew/bin:/usr/local/bin:$PATH"
[ -f "$HOME/.zshrc" ] && source "$HOME/.zshrc" 2>/dev/null || true
ANTHROPIC_API_KEY 環境変数が存在すると、Claude Code は Max プランの OAuth 認証ではなく API キーによる従量課金モードに切り替わります。開発環境に API キーを設定している人は多いはずです。unset を忘れると、毎朝 $2.15 が実際に請求されます。
もうひとつ、launchd は最小限の環境変数で起動するため、claude コマンドが PATH に含まれません。シェル環境の読み込みが必須です。
テーマ選定のスコアリング設計
config.toml でスコアリング基準を定義し、Claude に自律的に採点させます。
テックトレンド:
| 基準 | 重み | 意図 |
|---|---|---|
| 新規性 | 30% | past_topics.json に類似テーマがないか |
| 変化の兆し | 25% | 静的知識ではなく動いている領域か |
| 開発可能性 | 25% | 自分のスキルで何か作れそうか |
| ウィスパートレンド度 | 20% | まだ多くの人が気づいていない変化か |
パーソナル関心（ここでは刃牙関連としておく）:
上記に加えて「テック × 個人の関心領域の交差点」（20%）を追加。テクノロジーと自分の趣味領域の接点があるテーマを優遇しています。
人間がやるのは基準の設計だけ。採点と選定は Claude が自律的に行います。
実行結果
初回のフル実行テストの結果です。
| 項目 | 結果 |
|---|---|
| 所要時間 | 約 10 分（588 秒） |
| ターン数 | 51 回 |
| WebSearch 実行回数 | 20 回 |
| 表示上のコスト | $2.15 |
| 実質コスト（Max プラン内） | $0 |
2 本のレポートが生成されました。
テックトレンド: 「OpenAI Frontier — エンタープライズ AI エージェント管理の新時代」
2026 年 2 月 5 日発表の最新情報を捕捉。出典 10 件。AI エージェントが「構築」から「管理・統合」フェーズへ移行する転換点を分析し、マルチエージェント統合ダッシュボード等の開発アイデアを 3 件提案。
パーソナル関心: 「範馬刃牙の握力は実在するか — 生体力学シミュレーションの最前線」（※実際のテーマとは異なります）
技術トレンドとは別に、個人的に関心のある領域のリサーチレポートも生成されます。出典 12 件。趣味領域でも同じ品質のレポートが出てくるのは嬉しい誤算でした。
各レポートには「開発アイデアへの示唆」セクションがあり、技術的実現性・需要の見込み・自分のスキルとの相性が評価されています。「次に何を作るべきか」のヒントが毎朝届きます。
エージェントが計画を超えてくる瞬間
ひとつ面白い現象がありました。past_topics.json（テーマ履歴）のスキーマです。
計画で定義したスキーマ:
{
"date": "2026-02-14",
"track": "tech",
"topic": "MCPサーバーエコシステムの急成長",
"tags": ["AI", "MCP", "開発ツール"],
"filename": "2026-02-14_tech_mcp-server-ecosystem.md"
}
Claude が実際に生成したスキーマ:
{
"date": "2026-02-14",
"track": "tech",
"title": "OpenAI Frontier - エンタープライズAIエージェント管理の新時代",
"slug": "openai-frontier-enterprise-ai-agent-management",
"keywords": ["OpenAI", "Frontier", "AIエージェント", "エンタープライズ"],
"summary": "OpenAIが2月5日に発表した..."
}
topic → title、tags → keywords、filename → slug に変わり、summary が追加されています。Claude がプロトコルを解釈して「より良い」スキーマを自律的に選択した例です。
詳細仕様書の粒度が「何を達成するか」に集中し、「どう実装するか」を縛りすぎなかったことが要因でしょう。計画の粒度設計も、何本かプロジェクトをやってきた中で学んだことです。
運用上の課題: OAuth トークンの寿命
現状の唯一の課題は、Claude Code の OAuth トークンが約 4 日で期限切れになることです。
対策として check-auth.sh で認証状態を事前確認し、切れていれば macOS 通知で知らせます。週 2 回程度、ターミナルから claude を起動してトークンをリフレッシュすれば問題ありません。
完全な無人運用ではありませんが、「朝コーヒーを淹れながらレポートを読む」体験は十分に成立しています。
Max プランの経済性
| 項目 | 数値 |
|---|---|
| 表示上のコスト | $2.15/回 |
| Max プラン内での実質コスト | $0 |
| 月 30 日実行しても追加課金 | なし |
| 5 時間ローリングウィンドウ | AM 5:00 完了 → 午前中にリセット |
AM 5:00 に実行が完了すれば、5 時間ウィンドウは午前中にリセットされます。日中の対話利用にはまったく影響しません。
まとめ: 3 つの設計原則
- 計画に最も時間をかける。 実装は Claude Code が速い。ボトルネックは「何を作るか」の意思決定。3 セッションかけてリサーチと計画を繰り返し、詳細仕様書を作ったから、実装は一発で通った。
-
プロンプトがコード。 Python のオーケストレーションを書く代わりに、プロンプトに判断ロジックを委ねる。
--append-system-prompt-fileでデフォルト能力を殺さずにプロトコルを注入する。 - 最小構成で動かし、後から拡張する。 Plan A（Claude Code 単体）で十分な品質が得られた。検索品質に不満が出れば Gemini CLI との組み合わせに拡張できる余地は残してある。
Max プランを持っていて、claude -p を使ったことがない方は、ぜひ試してみてください。Python コード 0 行でも、思った以上のことができます。
ソースコード
この記事で紹介したシステムの全コードは GitHub で公開しています。git clone してすぐに試せます。