非エンジニアが転職活動を教材に、RSSとGemini APIで「集めて要約する」Botを作ってみた #2

この記事はマガジン ”非エンジニアが転職活動を教材に『作って学ぶ』記録” の#2です。

0. この記事で伝えたいこと

前回(#1)は、スプレッドシート、GAS、Notion API をつないで、転職活動の企業リストを管理する仕組みを作った話でした。

今回は、その次に取り組んだ Phase 2 の前半です。Python を使って情報を集め、生成AI(Gemini API)で「読みやすい形」に加工するところまでを書きます。

先に、この記事の立ち位置を書いておきます。私の第一の目的は、プログラミングや AI ツール、API連携を浅く広く触って、何ができるかを知ることです。ここで作ったものは、検証用の段階で、実用化はこれからです。「完成させた話」ではなく、「触ってみて分かったこと」の記録として読んでもらえたらと思います。

この記事で書くことは、次の4つです。

1. Python の環境構築で、最初に詰まったこと

2. 情報の取得元を2つ(スクレイピングと RSS)試して、どう使い分けると考えたか

3. 取得したデータを Gemini API で加工する流れ

4. AI のモデル選びで出たエラーと、その対処

5. 同じ記事を読ませても、AI の判断(重要度)が毎回変わったこと

1. なぜ Phase 2 に進んだのか

Phase 1 では、GAS(Google Apps Script)で、スプレッドシートと Notion をつなぎました。GAS は、Google のサービスの中で動くので、環境の準備がほとんど要りません。

次は、もう少し自由度の高い Python を触ってみたいと思いました。理由は、エンジニアが使う「手段」を、浅くでも体験しておきたかったからです。

題材は、「AI や最新ツールの情報を自動で集めて、要約して届ける情報収集Bot」にしました。自分が情報収集を続けたいテーマで、実際に役立つ可能性があり、学習の題材としてちょうどよいと考えたためです。

全体の流れは、次のようになります。今回の記事は、前半(取得と加工)です。

取得(Extract)
  Webページ(スクレイピング) / RSSフィード
        ↓
重複排除(既読のものは除く)
        ↓
AIによる加工(Transform)
  3行要約 / 重要度(1〜5) / タグ
        ↓
配信・保存(Load)   ← 次回(#3)
  Slack / Gmail / Notion

データ分野では、この流れを ETL(抽出・加工・格納)と呼びます。今回は、E(抽出)と T(加工)です。

2. 環境構築で、最初に詰まったこと

ターミナルも分からない状態から始めたので、プログラムを書く前の「準備」が最初の壁でした。

仮想環境(venv)は、「プロジェクト専用の小部屋」

Python では、便利な部品(ライブラリ)を追加して使います。ただ、部品を PC 全体に入れすぎると、バージョンが衝突して動かなくなることがあります。

そこで、プロジェクトごとに、専用の「小部屋」を作ります。これが仮想環境(venv)です。必要な部品の一覧を書き出せば、他の PC やクラウドでも、同じ環境を再現できます。

業務に置き換えると、「自分の PC では動くのに、同僚の PC では動かない」という事故を防ぐ考え方です。

PowerShell の権限は、最小限だけ許可した

Windows の初期設定では、スクリプトの実行がすべて禁止されています。そのままでは、仮想環境も起動できません。

かといって、「何でも実行を許可する」設定にするのは危険です。そこで、次の範囲だけを許可しました。

• 対象は、いま使っている自分のユーザーだけ(PC 全体は変えない)

• 許可するのは、自分の PC で作ったスクリプト

• 外部から取得したスクリプトは、署名があるものだけ(RemoteSigned という設定)

これは、IT の権限設計でいう「最小権限の原則」を、小さく体験できた場面でした。

3. 取得元を2つ試す: スクレイピングと RSS

Python で情報を取得する方法として、次の2つを試しました。

• スクレイピング: Web ページの HTML を取得し、必要な部分だけを抜き出す

• RSS: サイトが、新着情報をコンピュータ向けに配信している仕組み(XML 形式)を読む

目的は、この2つの手法に触れて、違いを体験することでした。

スクレイピング: 仕組みは分かったが、実用化はしない

SaaS 企業の導入事例ページを題材に、スクレイピングを試しました。流れは次のとおりです。

1. requests というライブラリで、ページの HTML を取得する

2. BeautifulSoup というライブラリで、HTML を「木の枝のような構造」(DOM ツリー)に分解する

3. 事例のカードを探して、企業名と詳細ページのリンクを取り出す

4. 相対パス(「/case/…」のような省略形)を、完全な URL に直して、ターミナルに表示する

アクセスが拒否されないよう、ブラウザに近い User-Agent(通信の「名刺」のようなもの)も付けました。AI に、この付け方を教えてもらったとき、正直、「これは大丈夫なのだろうか」と不安になりました。ブラウザのふりをして取得することに、少し怖さを感じたからです。

取得は、一覧ページ1つ、最大10件で、ターミナルに表示するだけです。保存も、再配布も、公開もしていません。

不安を、確認に変えて、「実用化しない」と決めた

その不安を放置せず、取得先の利用規約と robots.txt を確認しました。(2026年10月11日時点)

• robots.txt: サイト全体のアクセスを許可していた

• 利用規約: スクレイピングを禁止する項目は、サービスの契約者向けの規約の中にありました。私はそのサービスを使っていません。公開の事例ページの閲覧について、サイト全体を対象にスクレイピングを禁止する文言は、私が調べた範囲では見つかりませんでした

とはいえ、法的な判断ができるわけではなく、グレーな部分が残る可能性もあります。そこで、次のように決めました。

• 動作確認の範囲(少量・手動・個人の学習用)にとどめる

• 実用化(定期実行)は、しない

• 取得先の企業名は、記事にも出さない

学んだことは、2つです。1つ目は、スクレイピングは「できる」ことと「やってよい」ことが別だという点です。取る前に、規約と robots.txt を確認するのが先だと、あらためて思いました。2つ目は、公式に提供されている手段があるなら、そちらを優先するべきだという点です。

RSS: 公式に配信されている手段

もう1つの取得元は、技術記事サイト Zenn の RSS フィードです。Cursor というトピックの新着記事を取得しました。

RSS は、サイト側が、新着記事のタイトル、URL、公開日、概要を、整った形式で公式に配信しているものです。Python では、feedparser というライブラリで読みます。

import feedparser

feed = feedparser.parse("https://zenn.dev/topics/cursor/feed")
for entry in feed.entries[:3]:   # 最新3件を順に取り出す
    print(entry.title, entry.link)

スクレイピングと比べると、違いは次のとおりです。

• スクレイピング: サイトのデザインが変わると、コードが壊れやすい

• RSS: 配信側が、読ませる前提で整えているので、壊れにくく、取得も簡単

4. Gemini API で、集めたデータを「読める形」にする

記事のタイトルや概要を、そのまま全部読むのは大変です。そこで、生成AI(Google の Gemini API)に、次の3つを依頼しました。

• 3行の要約

• 重要度スコア(1〜5の整数)

• タグ(2〜3個)

視点は、「Ops職やエンジニアの生産性向上・業務効率化」にしました。自分にとって役立つ記事かどうかを、AI に判断してもらう形です。

構造化データ(JSON)で受け取る理由

AI の返事を、普通の文章で受け取ると、プログラムは中身を使えません。そこで、JSON という決まった形式で返してもらいます。

{
  "summary": ["要約1", "要約2", "要約3"],
  "score": 4,
  "tags": ["#Cursor", "#生産性向上"]
}

こうしておくと、「スコアが4以上なら、通知する」のような条件分岐ができます(次回、使います)。自由な文章を、プログラムが扱える項目に変換する。これが、データに付加価値をつける(エンリッチメント)ということだと理解しました。

プロンプトの要点

AI への指示(プロンプト)には、次のことを書きました。

• 役割: Ops職・エンジニアの生産性向上の観点で記事を分析するアシスタント

• 出力の形式: JSON だけを出力する。前置きや説明は書かない

• 各項目のルール: 要約は3行で50文字程度、スコアは1〜5の整数、タグは2〜3個

ただ、AI が指示を守らず、JSON を```で囲んで返してくる場合もありえます。そのため、プログラム側にも、返事の中から JSON の部分だけを取り出す処理を入れました。

# 最初の { から、最後の } までを、JSON とみなして取り出す
start = cleaned.find("{")
end = cleaned.rfind("}")
data = json.loads(cleaned[start : end + 1])

AI の出力は、毎回きれいとは限りません。「AI は、指示どおりに返さないことがある」ことを前提に、受け取る側で守りを入れる。これも、学んだことの1つです。

実行結果

ターミナルには、1記事ごとに、重要度、タイトル、URL、公開日、タグ、3行要約が表示されます。

5. つまずきログ

AI のモデル選びで、エラーが続いた

今回は、無料の範囲で動かしたいと考えていました。要約の精度は、そこまで高くなくてよいという前提です。

• 最初は、Gemini 3.8 Flash を使おうとしました。しかし、利用者が多く、503(サーバーが混雑している)のエラーが出ることがありました

• そこで 3.7 Flash に変更しました。それでも、503 が出ました

• 次に、3.5 Flash-Lite に変更しました。503 は出なくなりましたが、今度は 429(短時間にリクエストを送りすぎ)のエラーが出ました

• そこで、リクエストの間隔を空けるコードを入れました。すると、エラーは出なくなりました

503 などへの対処法は、2つあると学んだ

この過程で、一時的なエラーへの対処法として、2つあることを学びました。

• スロットリング: リクエストの間に、あらかじめ待ち時間を入れる。そもそも、送りすぎないようにする

• 指数バックオフ: エラーが出たら、2秒、4秒、8秒と、待ち時間を倍にしながら、自動でやり直す

今回のコードで採用したのは、前者のスロットリングです。加えて、一時的なエラーのときに、一定の時間(3秒)待って、最大3回までやり直す、簡易的な再試行も入れました。待ち時間を倍にしていく指数バックオフまでは、実装していません。

# 記事を1件処理するたびに、2秒待つ(続けて送りすぎない)
SLEEP_BETWEEN_ARTICLES_SECONDS = 2

# 503 や 429 のような一時的なエラーのときは、3秒待って、最大3回までやり直す
MAX_RETRIES = 3
RETRY_WAIT_SECONDS = 3

学んだことは、3つです。

• 目的(無料、精度は高くなくてよい)に合わせて、軽いモデルを選ぶ

• モデルを替えるだけでなく、通信の間隔を設計することも効く

• 外部サービスのモデルやルールは、変わる。作って終わりではなく、保守が必要になる

業務でいえば、外部の SaaS や API に依存した仕組みは、「相手の変更や混雑に備える」設計が要る、ということです。

Windows の文字化け

記事のタイトルに、特殊な記号(長いダッシュなど)が含まれていて、ターミナルに表示しようとするとエラー(UnicodeEncodeError)になりました。

文字コードを指定し、表示できない文字があっても、止まらないようにして解決しました。小さな問題ですが、「自分の PC では動くのに、環境によって動かない」ことの、身近な例でした。

6. AIとの付き合い方: 同じ記事でも、AIの判断は毎回変わった

動作確認のために、同じ記事を何度も実行しました。そのとき、印象に残ったことがあります。

• 3行の要約は、毎回、あまり変わりませんでした

• 一方、重要度のスコアは、毎回違いました。同じ記事なのに、4になったり、3になったり、5になったりしました

• タグも、似たニュアンスではあるものの、少しずつバラついていました

使っているのは、Gemini の中でも軽いモデル(Flash-Lite)です。精度の高いモデルなら結果が変わるのかどうかは、試していないので分かりません。ただ、「同じAIモデルに、同じ記事を読ませても、判断の結果が変わる」ことは、体験として、とても面白かったです。

設計にも関わる

次回書く通知の仕組みは、「スコアが4以上なら通知する」という条件で動かしています。スコアが毎回ゆれるなら、境目にある記事は、通知されたりされなかったりするはずです。

業務に置き換えると、AI に判断をさせる仕組みでは、次のことを考える必要がありそうです。

• 判断基準を、プロンプトの中で、もっと具体的に書く(例: 「具体的なコード例があれば5」など)

• 1回の判断で決めず、複数回の結果を見る

• AI の判断は「目安」として使い、最終判断は人間がする

これらは、まだ試していない案です。今後の課題として、メモしておきます。

7. Ops実務への翻訳

今回の仕組みは、次のような業務に置き換えられます。

• 競合や業界の動きの監視: 競合のニュースリリースや、業界サイトの新着を、RSS で集める。重要なものだけを要約して共有する

• 問い合わせや商談メモの整理: 自由に書かれた文章に、AI で重要度とタグをつけ、優先順位をつける

• 社内の情報収集: 社内ポータルの更新情報を集約する

どれも、「集める」「読める形にする」「判断のための材料にする」という流れで、共通しています。

また、スクレイピングの件は、業務でも同じです。外部のデータを自動で取得するときは、規約の確認と、公式の手段の優先が先、という考え方は、そのまま使えます。

8. 現状と、次回予告

• 現状: 取得と AI での加工まで動き、結果はターミナルに表示されます。実行は手動です

• スクレイピングは、実用化しません

• 次回(#3)は、この結果を Slack、Gmail、Notion に届ける仕組みと、同じ記事を二度通知しない工夫(既読管理)、そして APIキーなどの秘密情報を守る方法について書きます

この学習をどこまで続けるかは、転職先が決まる時期や、活動を続けられる期間次第です。「完成させる」ことよりも、「何ができるかを知り、基礎を広く掴む」ことを優先して進めていきます。