前回のおさらい
前回でCursorのインストールが終わりました。
軽く操作感を試すなどして、歩み寄り中です。
実際にやってみた
今回のサイト構築に向けて、まず改めてプロジェクトのフォルダを作ります。
名前は『news-digest』にしました。
開いて、Ctrl + L で、試しにこんな指示を出してみました。
どんな感じになるかを試す目的なので、詳細な要件を詰めたプロンプトは、後ほど作成して指示することにします。
Pythonで毎朝6時に実行されるニュース取得スクリプトを作りたい。
まずどういう構成にすればいい？
すると、ファイル構成の提案と、それぞれのファイルで何をすべきかの説明が返ってきました。
いきなり大ボリュームな内容が返ってきて焦ります。
（優秀過ぎて、逆に情報量にビビってしまう……これもAIを扱う上でうまく向き合っていかないといけないんだよなとぼんやり感じたりしました）
以下方針で設計するといいよ、とのことでした。
- 「1本の巨大スクリプト」ではなく、取得 → 整形 → 保存 を分けた小さなモジュール構成にする
確かにさきほど痛感したように、いきなりたくさんの情報がかえってくると、精査が難しすぎる。何がなんだかわかりません。今回の目的が理解しながら、ということもあるので、少しずつやっていくのが吉ですね！
提案されたディレクトリ構成
news-digest/
├── pyproject.toml # または requirements.txt
├── .env.example # APIキー等（.env は git 除外）
├── config.yaml # ソース一覧・件数・カテゴリ等
├── src/
│ └── news_digest/
│ ├── __init__.py
│ ├── __main__.py # python -m news_digest
│ ├── cli.py # エントリポイント
│ ├── config.py # 設定読み込み
│ ├── models.py # Article などの dataclass
│ ├── fetchers/ # ソースごとの取得
│ │ ├── base.py
│ │ ├── rss.py
│ │ └── ...
│ ├── processors/ # 重複除去・フィルタ・要約（将来）
│ │ └── dedupe.py
│ ├── storage/ # 保存先の抽象化
│ │ ├── jsonl.py
│ │ └── sqlite.py # 必要なら
│ └── notifiers/ # メール / Slack 等（任意）
│ └── ...
├── data/ # 出力（gitignore）
│ └── digest-2026-05-18.json
├── logs/ # 実行ログ（gitignore）
└── scripts/
└── register_task.ps1 # タスクスケジューラ登録用
正直、初見では「何これ……」という感じです。
ファイルが多くて何から手をつければいいかわかりません。
「このファイルはどういう意味だろう？」「あ、この間少しやった__main__.pyいるわ」「なんでこんな構成なんだろう？」などなど……。
実際に現場で使われているような構成と比べれば、こんなのはまだまだ少ない方なのでしょうけれども、理解が大変怪しいです。
それもしっかり落とし込みながら、進めて行けるようにしたいと思います。
提案された各層の役割
| 層 | 役割 |
|---|---|
| fetchers | RSS/APIから生データ取得のみ |
| processors | 重複除去、キーワードフィルタ、ランキング |
| storage | JSON / SQLite など保存形式を差し替え可能に |
| notifiers | 朝の「読む場所」（メール、Markdown、Notionなど） |
各層は、プログラムの役割ごとに分けた担当エリアとのこと。
fetchers（取得）、processors（加工）、storage（保存）、notifiers（通知）でわけることで、他の部分を触らずに直したい部分を直すことができるメリットがあるようです。
提案された実行の流れ（1回分）
- 設定読み込み（
config.yaml+ 環境変数） - 各ソースを fetcher で取得
- Article に正規化（title, url, published_at, source）
- 重複除去・古い記事の除外（例：24時間以内）
-
data/digest-YYYY-MM-DD.jsonに保存 - （任意）メールやファイルを開く通知
環境変数、正規化……よく出てくるけどあんまり理解してない強者達が出てきてしまいました……。
少し調べたので、備忘録として以下に。
《環境変数》
「プログラムが使う、秘密の情報をあらかじめ用意しておく仕組み」
重要なキーをコードに直接書いてどこかにそのコードを公開したら、重要なキーが見られてしまう。
そのため .env というファイルに書いて取り出すようにする。「環境（パソコンの中）にあらかじめ用意しておく変数」ということ。
因みにconfig.yamlには「コードに直接書きたくない設定をまとめておく場所」です。
変更するときに直接コードを触るとリスクがあるので、極力触りたくない。
そんな時に、設定だけ外に出す。
URLを変えたいとか、そういう時にこのファイルの書き換えだけすればいいようです。
……はて。
config.yaml と 環境変数、2つとも設定ファイルだけど、具体的に何が違うんだ？？となりませんか？
表にまとめると以下の通りです。
| config.yaml | .env | |
|---|---|---|
| 何を書く？ | URL・件数・フィルター条件など | APIキーなど秘密の情報 |
| GitHubに上げる？ | ✅ 上げてOK | ❌ 絶対NG |
| 見られても困る？ | 困らない | 困る（お金がかかる） |
**config.yamlは「設定の指示書」、.envは「秘密のメモ帳」**なんて例えがされていました。しっくりきますね。
「URLを変えたい」→ config.yamlだけ触ればいい
「APIキーを変えたい」→ .envだけ触ればいい
コード本体は触らなくて済む、というのがどちらも大きなメリットです。
《正規化》
それぞれのニュースサイトからデータを取得したとき、サイトによって返ってくるデータが違うことがある。
日時とか、よくありそうですよね。
18 May 2026と2026-05-18みたいなことだと思います。
ですので、全部同じ形に揃える必要があります。
つまり「どこのメディアから取ってきても同じ形にする」のが正規化となります。
提案されたまとめ：まずMVP(最小限）のゴールから始める
全部一気に作ろうとすると確実に詰むので、少しずつ進めます。
- ニュースを2〜3ソースだけ取得する
- 取得 → 正規化 → 日付ファイルにJSON保存
- タスクスケジューラで毎朝6時実行
- 通知・要約・DBは動いてから考える
通知や要約は後から足す形にして、まず「ニュースを取得して保存できる」状態を目指す。
まだAIの指示出しをしてみただけですが、少しイメージが湧きました。
返ってきた内容を含めながら、実際に何が必要なのかを改めて考えていきます。
詳細な要件を詰めていけたら良いなと思います。
【必要なことを整理する】
少しずつやりたいことは見えてきました。
でも「どうやって実現するのか」がまだ全然わかっていません。
一つずつ疑問を整理しておきます。
① 見る場所：どこからアクセスできるようにする？
隙間時間にスマホでもチェックしたいので、外出先からも見られるようにしたい。
でも、家の中だけと外出先でも見られる、は、構成が変わってくるはず。
→ 難易度が上がるなら、まずは家の中だけで動かすところから始めるべき？
② ニュース取得：どこから・どうやって取る？
どのニュースサイトから取得するかを精査したい。
でもそもそも、Webサイトのニュースってどうやってプログラムで取得するの？
→ APIを使う？RSSを使う？それぞれ何が違う？
③ 保存：過去のニュースはどこまで残す？
過去3ヶ月分のまとめをリスト一覧で見られるようにしたい。
→ どこに・どんな形式で保存すればいい？
④ 単語説明：難しい言葉に自動で説明をつける
まとめの中で難しい単語が出てきたら、自動で説明を付けてほしい。
勝手に判定して勝手に説明してくれると理想。
→ これはAIにやってもらう？どうやって組み込む？
⑤ 読み上げ：音声で聞けるようにする
朝の忙しい時間に耳だけで聞けると便利。
→ 音声読み上げには何を使えばいい？有料・無料の選択肢は？
⑥ 自動実行：毎朝6時に勝手に動かす
手動で実行するのは自動化とは言えない。
→ Windowsで定期実行するにはどんな仕組みが必要？
⑦ エラーが出たらどうする？
自動実行中にエラーが出たとき、気付ける仕組みは必要？
→ 誰も見ていない朝6時に動くので、失敗してもわからないのでは……？
⑧ スマホで見たときのデザインは？
パソコン向けに作ったページをスマホで見ると崩れることがある。
→ スマホでも見やすくするには何が必要？
素人が思いつく限りでは、こんな感じです。
他にも作成していく内にどんどん疑問が出てきそうな気がしますが、一旦はこれらを解消し、要件を組み立てていきます。
次回は……
次回からは疑問を掘り下げていきます。