1.はじめに
1年ほど前、こんな記事を書きました。
当時は、クラウド(以降、Azure)関連の情報をどうキャッチアップしているか、そのやり方と対象にしていた情報源を紹介する記事でした。
そこで大事にしていたスタンスが、こちらです。
「全部は追いきれないから、選択と集中が大事」
当時は、メール購読や RSS で1つずつチェックし、チェックする情報源を絞ってキャッチアップするアプローチでした。
それから1年。生成 AI の進化によって、状況はもうすっかり変わりました。
「情報源を絞る」から「必要な情報源は全部拾って、AI に要約・整理してもらう」へ
具体的には、Azure 関連の情報を自動収集し、AI が要約・整理までしてくれる Web サイトを作成してみました。
1ヶ月ほど運用を続け、安定して利用できるレベルになったため、本記事では「AI に何を任せ、何を任せないか」の判断基準や AI に実際に任せていることを中心に紹介します。
こんな方に向けた記事です。
- AI を使ったキャッチアップの考え方・アイデアを参考にしたい方
- Azure のキャッチアップの仕方に悩んでいる方
- 情報収集・要約の自動化に興味がある方
Azure・AI の用語は登場しますが、予備知識がなくても読める内容です。
細かな実装手順やコードは掲載していません。
再現手順ではなく、仕組みやアイデアの共有として読んでいただけると嬉しいです。
2.「1年前」と変わったこと
まずは、1年前と現在で、キャッチアップの方法がどう変わったのかを整理します。
2-1.「探して読む」から「集まった情報を読む」へ
以前は、メール購読や RSS などを使い、優先度の高い情報源を自分でチェックしていました。
今は対象にする情報源を幅広くして、毎週月曜に前週(月〜日)の情報をまとめて自動収集。
また、収集情報は一つのサイトに自動的にまとめて、要約や読む情報の選別を AI に任せています。
情報を探して読むのではなく、集まった情報を読む方針に変わりました。
2-2.実際に集めているもの
以前は、情報源単位にチェックする頻度を変えていました。
| 頻度 | 主な情報源 | 目的 |
|---|---|---|
| 毎日 | 公式情報、SNS(X) | 速報をおさえる |
| 毎週 | 有志情報、イベント情報 | 技術情報を取り込む |
| 毎月 | 企業ブログ情報 | 深掘り・俯瞰する |
この方法では、情報源単位に自分でタイミングを判断しながら、必要な情報を探しにいく必要があります。
そのため、今回は対象にする情報源を広げ、すべての情報源を毎週1回、前週(月〜日)の情報としてまとめて収集する方式に変えました。
| 以前 | 今回 | |
|---|---|---|
| 情報源 | 重要なものを選んでチェック | 必要な情報源を幅広く対象化 |
| チェック頻度 | 毎日・毎週・毎月 | 毎週1回 |
| 収集範囲 | 情報源単位に確認 | 前週1週間分をまとめて収集 |
| 情報量 | 必要なものを選んで確認 | より多くの情報をまとめて収集 |
| 読み方 | 自分で探して読む | AI に要約・整理してもらって読む |
ここからは、Azure の情報収集をしている方向けの少し細かい話ですが、今回対象にしている情報源は次の7カテゴリです。
| カテゴリ | 内容 |
|---|---|
| 公式アップデート | Azure Updates |
| 公式ブログ | 国内系(IaaS、PaaS、Identity)、グローバル系の数十サイト |
| テックブログ | JBS Tech Blog、NRI atlax blogs |
| コミュニティブログ | Qiita(Azure タグ)、Zenn(Azure トピック) |
| イベント情報 | Microsoft公式、JAZUG、すきやねんAzure!! などの Azure 関連イベント |
| 資格情報 | The Skills Hub Blog、資格まとめ |
| ビジネスニュース | Publickey(Azure)、TECH+(Microsoft Azure) |
一部の情報源は、API の利用条件などの都合で自動収集の対象外としています。
その場合は、サイトにリンクのみ掲載し、必要に応じて自分で確認しています。
SNS(X)も候補にしていましたが、収集に必要な API 利用料が高額だったため、今回は対象から断念しました…
日々の隙間時間に自分でチェックしています。
以前よりも、集める情報は増えました。
その分、人力では収集が難しいので、AI に一部を任せるようにしました。
3.AIに任せること、任せないこと
以前よりも多くの情報を集めるようになりましたが、すべてを AI に任せているわけではありません。
3-1.AIに任せる範囲
今回の仕組みでは、初回に決めることと、毎週自動で行うことを分けています。
| ステップ | タイミング | やること | 担当 |
|---|---|---|---|
| 1 | 初回 | 情報源の候補を探す | 人&AI |
| 2 | 初回 | 情報源を選ぶ | 人 |
| 3 | 毎週自動化 | 情報を収集する | プログラム |
| 4 | 毎週自動化 | 情報を要約する | AI |
| 5 | 毎週自動化 | 読む情報を絞る | AI |
この中でも、情報源を選ぶ(2)ところは人が判断するようにしています。
3-2.情報源を選ぶのは人
AI は、情報源の候補を探したり、特徴を比較したり、判断材料を整理できます。
ただ、最終的に「この情報源は対象!」と決めるところは、自分で判断しています。
「AI に判断材料を出してもらうことと、最終的な判断を任せることは別」
情報源の質が、そのまま毎週入ってくる情報の質になるからです。
ここを間違えると、AI にどれだけ要約や絞り込みを任せても拾える情報はよくなりません。
だからこそ、情報源を選ぶ作業は自分の判断として責任を持ちたいと思っています。
もちろん、新しい情報源を探すときには AI も活用しています。
AI だけで判断せず、有識者から得た知見も組み合わせています。
- AI に情報源の候補や判断材料を出してもらう
- 自身や有識者の知見を取り入れる
- それらを組み合わせて情報源を選定する
Azure の情報源を選ぶ際、AI だけでは「かなりそれっぽいけど、ちょっと違う…」と感じる場面も多く、人の知見を組み合わせることの有効性を実感しました。
3-3.情報量を増やしても、読む量は増やさない
今回、情報源を増やしたことで、集められる情報は増えました。
一方で、集めた情報をすべて自分で読むのであれば、キャッチアップの負担も増えてしまいます。
そこで、意識したのがこの考え方です。
「読む量を増やさずに、拾える情報を増やす」
情報の収集は自動化し、集まった情報は AI に要約してもらう。
さらに、読む情報を AI に絞ってもらい、最後に自分が必要な情報を読む。
この流れにすることで、集める情報は増やしつつ、自分が読む量は増やさないようにしました。
4.具体的に AI に何を任せているのか
今回、記事の要約や読む優先度の判断を AI に任せています。
では、実際にどのような処理をしているのかを紹介します。
4-1.記事の内容を要約する
まず、収集した記事の内容を AI に渡し、概要やポイントをコンパクトに要約してもらいます。
英語の記事であっても要約自体は日本語でまとめるほか、タイトルの日本語訳もあわせて生成しているので、記事を開かなくても内容を一目で把握できます。
元記事
Generally Available: Azure Copilot Troubleshooting Agent
タイトルの日本語訳は、コストを抑えた軽量 AI モデルを使っている都合上、生成が不安定になることがあり、上記のように日本語訳が正しく反映されない場合があります。
4-2.「読む優先度」を判断する
次に、要約した内容をもとに、AI に読む優先度を判断してもらいます。
ここで重要なのは、収集する記事自体を AI に選ばせているのではなく、あらかじめ幅広く集めた記事の中から「特に読んでおきたい記事」を AI に選んでもらっているという点です。
例えば現在はインフラを担当する業務のため、次のような観点を AI に意識してもらっています。
- 生成 AI 関連情報を最優先
- サービスの終了予定や正式リリースなど、ビジネスへの影響が大きい情報を、次に優先
- インフラを担当する立場から見て、重要度が高いと判断した情報を、その次に優先
この条件をもとに、全体トップ5やカテゴリ単位の今週読んでおきたい記事のランキングを作成しています。
API の利用条件や運用上の理由などから自動収集の対象外としているカテゴリもあります。
そうした情報源はランキングの対象にはせず、リンクのみ掲載しています。
4-3.「全部集める」と「読むものを絞る」を分ける
今回の仕組みでは、収集した記事を最初から絞り込んでいません。
まずは対象にした情報源の更新情報をすべて収集して一覧に残し、そのうえで AI による要約やランキングを表示します。
全部を確認したいとき
カテゴリ単位の一覧から、収集したすべての記事のリンクと AI による要約を確認できます。


絞って確認したいとき
AI が優先度を判断した「今週読んでおきたいトップ5」と、カテゴリ単位のランキングを確認できます。
すべての記事を確認したければ一覧から、時間がなければ AI が選んだ記事から読む。
こうして、情報を取りこぼさないための収集と、読む量を減らすための AI による整理を分けています。
5.どんな仕組みにしたのか
ここまで紹介した仕組みを、Azure を担当していることもあり、せっかくなので Azure のサービスを組み合わせて実装しました。
なお、以前作成した「Qiita API × Azure」の活動データを可視化するダッシュボードで、自動化の知見があったため、その仕組みをベースに、情報収集と AI 処理を追加しています。
簡易的ですが、アーキテクチャ図はこちらです。
5-1.サービスの構成
基本的な Azure の構成やサービス選定については、以前の記事で紹介した構成をベースにしています。
今回はそこに、情報収集と AI による要約・優先順位付けの処理を追加しました。
AI(Azure OpenAI)については、今回の用途では高度な推論能力よりも、低コスト(月額総コスト:数十円)で処理できることを重視し、GPT-5-nano を利用しています。
| 区分 | サービス | 役割 |
|---|---|---|
| 情報源 | API / RSS / Atom | Azure 関連の記事・ブログを取得 |
| Azure | Azure Functions | 情報収集・AI 処理・Web サイト生成などを実行 |
| Azure | Azure OpenAI | 記事の要約・タイトル翻訳・優先順位付けを実行 |
| Azure | Azure Storage | AI 処理結果や Web サイト(HTML)を保存 |
| Azure | Microsoft Entra ID | Web サイトへのアクセスを制御 |
週1回のバッチ処理が中心なので、常時サーバーを動かすのではなく、サーバレスサービスを使って必要なときだけ処理する構成にしています。
また、Web サイトへのアクセスには共通の認証サービスを利用し、チーム内で利用できるようにしています。
5-2.毎週の処理
毎週月曜日の早朝に、前週(月〜日)の情報をまとめて処理しています。
大まかな流れは、次のとおりです。
①.【収集】API / RSS / Atom から、各情報源の前週の記事情報をすべて収集
②.【AI 処理】記事単位に要約や、全体のTop 5・カテゴリ単位のランキングの判断を実行
③.【書込】要約結果などの処理結果をストレージに書込
④.【生成】保存したデータをもとに Web サイト(HTML)を生成・更新
この一連の処理が、自動で実行されます。
トラブルが起きない限り、人がやることは更新された Web サイトを見て、必要な記事だけ読む流れです。
6.おわりに
運用を始めて1か月ほど経ちましたが、作成してよかったというのが率直な感想です。
一番の効果はキャッチアップに掛けていた時間です。
これまで週に数時間かけていたものが、今は「更新されたサイトを見て、必要な記事だけ読む」だけになり、体感で3分の1以上に減りました。
もちろん完璧ではなく、軽量な AI モデルを使っている分、日本語訳や要約に「ちょっと微妙だな」「翻訳失敗してる…」と思うこともあります。
それでも週次のキャッチアップには十分なので、精度より「安く回し続けられること」を優先しています。
今回のサイトは、今はチーム内で共有している段階です。
使いながら改善を重ねて、少しずつ共有する範囲を広げていければと思っています。
また、今回は Azure が対象でしたが、考え方やアイデアは皆さんの担当製品でも参考になるかもしれません。
ここまで読んでいただき、ありがとうございました。
We Are Hiring!








