自分の Qiita での活動、実際どうなの？ Qiita API × Azure で活動データを可視化してみた

1.はじめに

Qiita に記事を投稿していると、こんなことを考えるようになりました。

「自分の Qiita での活動、実際どうなの？」

例えば、こんなことです。

• これまでの記事が、どの程度読まれてきたのか
• どんな記事や分野が、よく読まれているのか
• しばらく更新していない記事が、今も読まれているのかどうか

一方で、Qiitaの標準機能だけで、こうした情報をまとめて確認するのは少し大変です。
記事単位にアクセスして、それぞれの状況を確認する必要があります。

また、周囲から「Qiita、どんな感じ？」と聞かれても、すぐには答えられません。

そこで、「だったら、自分が欲しい情報をまとめて見られるものを作ってみよう」と思い、Qiita API × Azure で活動データを可視化する仕組みを作ってみました。

こんな方に向けた記事です。

• Qiita の活動を可視化するとどんな感じになるか気になる方
• 個人開発で Azure を触ってみた事例に興味がある方
• 自分の発信活動を振り返るヒントを探している方

Azure の用語は登場しますが、予備知識がなくても読める内容です。

細かな実装手順やコードは掲載していません。
再現手順ではなく、仕組みやアイデアの共有として読んでいただけると嬉しいです。

2.作ってみたもの

今回作った、ダッシュボードと Teams への通知を紹介します。

2-1.ダッシュボード

1つの画面（Web サイト）に、自分が「これ見たいな」と思った情報をまとめています。
キャプチャでは、分かりやすいように4つの機能に分けて紹介します。

それぞれ、何が確認できるのかが直感的に分かるようにしています。

①活動状況

②タグ別ビュー数

③記事ランキング

④未更新記事情報

2-2.Teamsへの通知

ダッシュボードとは別に、毎日 Teams へ活動状況を通知しています。

2-3.それぞれの機能で楽になったこと

今回のダッシュボードや Teams への通知は、使っているうちに「これも見たい」「あれもあると便利そう」と思ったものを、どんどん追加していきました。

区分	観点	概要	楽になったこと
ダッシュボード	活動状況	投稿数や総ビュー数、総いいね数、総ストック数、ビュー数の推移などをまとめて表示	Qiita 全体の活動状況を、ひとつの画面ですぐ確認できるようになった
ダッシュボード	タグ別ビュー数	タグ単位の総ビュー数をランキング形式で表示	どの分野の記事が読まれているのか、すぐ確認できるようになった
ダッシュボード	記事ランキング	記事単位のビュー数をランキング形式で確認し、いいね数やストック数もあわせて表示	どの記事が読まれているのか、一覧ですぐ確認できるようになった
ダッシュボード	未更新記事情報	180日以上更新していない記事をビュー数順に表示	どの記事から見直せばよいか、優先順位をつけやすくなった
Teams	毎日の通知	本日のビュー数、総いいね数（累積）、総ストック数（累積）と、ビュー数が伸びた記事 TOP3 を Teams に通知	ダッシュボードを開かなくても、毎日の活動状況を軽く確認できるようになった

まだ作ってからそれほど時間が経っていないので、今後も使いながら必要なものを足したり、いらないものを削ったりしていくつもりです。

3.Azure で作ってみる

今回は、せっかくなので普段の業務でも扱っている Azure を使って、ダッシュボードと Teams への通知の仕組みを作ってみました。

3-1.Azure を使った理由

最近は役割的に実装する機会が少なくなってきたので、普段の業務でも扱っている Azure を、たまには自分でも手を動かして触っておこうと思ったためです。

直近では、異なる分野ではありますが、IaC を使った実装について記事にしています。

前回とは少し視点を変えて、既存のサービスや機能を組み合わせながら、できるだけシンプルな構成で作ることを意識しました。

特に意識したのは、次の3つです。

• Qiita 側に用意されている API を活用する
• Azure のマネージドサービスを組み合わせる
• 必要以上に作り込まず、低コストで実際に使えるものを作る

この方針で、Qiita API から取得したデータを Azure 側で処理・保存し、ダッシュボードとして表示したり、Teams へ通知する仕組みにしています。

3-2.サービスの構成

今回の仕組みは、Qiita API と Azure サービスを組み合わせて作っています。

区分	サービス	役割
Qiita	Qiita API	記事やビュー数、いいね数などの活動データを取得
Azure	Azure Functions	Qiita API からのデータ取得・加工、ダッシュボードの生成・配信、Teams への通知まで実行
Azure	Azure Storage	取得した日次データや、生成したダッシュボード（HTML）を保存
Azure	Microsoft Entra ID	同じ会社の人だけがダッシュボードを見られるように制御
Azure	Azure Key Vault	Qiita API や Teams Webhook の認証情報を管理
Teams	Teams Webhook	毎日の活動状況を Teams へ通知

サービス選びの基準は「低コストで実際に使えるものを作る」です。
処理・データ量が少ないため、従量課金の Azure Functions・Azure Storage・Azure Key Vault と、既存の Microsoft Entra ID 認証を組み合わせるシンプルな構成にしました。

本仕組みは、Qiita API の利用規約や利用制限を守り、構成しています。

3-3.毎日のデータ更新を自動化

作った後に手動で更新するのは面倒なので、データの取得・保存から Teams への通知、ダッシュボードの更新までを自動化しています。
毎日23:59に、Python で書いた処理が Azure Functions 上で自動的に実行される仕組みです。

23:59の実行は、日付が変わる直前にその日一日分を確定させるためです。

3-3-1.毎日の処理

具体的には、次の①〜⑤の順番で処理が自動的に行われています。

①取得

• Qiita API から記事やビュー数、いいね数などの最新データを取得

②書込

• 取得したデータを加工して保存

③読込

• 保存されている前日分のデータを読み込み、ビュー数などの差分を計算

④通知

• 本日のビュー数、総いいね数（累積）、総ストック数（累積）と、ビュー数が伸びた記事 TOP3 を Teams へ通知

⑤生成

• 保存されているデータをもとにダッシュボード（HTML）を作り直して保存
• 閲覧時は、保存済みの HTML を読み込んで表示

3-3-2.セキュリティ

今回は自分用のダッシュボードですが、「Qiita、どんな感じ？」と聞かれたときにすぐに共有できるように、Azure の会社のアカウントであればアクセスできるようにしています。

外部に漏れると困る情報は、次のように管理しています。

• Qiita API：閲覧・取得のみの権限（Read Only）を付与
• API キーや Webhook の URL：コードに直接書き込まず、専用の保管庫（Azure Key Vault）にまとめて保管
• プログラムのコード：秘密情報を直接記載しない

3-3-3.コスト

稼働して約2週間ですが、実際の利用料は約10円でした。
低コストに抑えられているのは、次のような理由です。

• Azure Functions：実行した分だけ課金され、待機時間に料金は発生しない
• 処理内容：1日1回・数十秒程度のため、実行時間そのものが少量
• 保存データ：テキスト中心でごく少量のため、保存や認証情報管理の料金もわずか

稼働期間はまだ短いですが、個人で使う分には十分低コストに抑えられそうです。

4.実際に使ってみて分かったこと

実際にダッシュボードで自分の Qiita 活動を見てみると、これまで何となく見ていた数字から、いくつか面白いことが分かりました。

4-1.記事の伸び方を見てみる

Qiita での活動開始は2024年6月。
活動状況から、現在は31記事で、総ビュー数は約60万でした。

項目	現在の状況
活動開始	2024年6月
投稿数	31件
総ビュー数	約60万

思っていたより読まれているなというのが最初の印象です。
一方で、特定の記事が全体の数字を大きく支えていることも分かりました。

No.	記事	特徴	現在の状況
①	Microsoft 認定資格（Azure）早見表	初動は控えめ・毎月更新	ビュー数・いいね数・ストック数が継続して増加
②	「今日ネットワークめっちゃ重くない？」の真犯人は私だった話	初動が強い	ビュー数は横ばいに近いが、いいね数・ストック数は微増

4-1-1.毎月更新している記事

①は約25万ビューで、総ビュー数の約40％を占めています。

投稿当初はそれほど大きな反応があった印象ではありませんでしたが、毎月更新を続けることで、ビュー数だけでなく、いいね数やストック数も継続的に増えていました。

「これ、更新し続ける意味あるのかな」と思うこともありましたが、数字で見ると、続けることにも意味があるんだなと感じました。

4-1-2.投稿直後に伸びた記事

②は投稿直後にビュー数・いいね数・ストック数が一気に増加しました。

その後は、ビュー数が約10万から大きく伸びることはありませんでしたが、いいね数やストック数は少しずつ増えているため、特定の人に響く記事なのかもしれません。

この2記事を比べてみると、「継続的に読まれる記事」と「投稿直後に伸びる記事」では、その後の伸び方も違うことが分かりました。

4-2.読まれている分野や内容を見てみる

「記事ランキング」と「タグ別ビュー数」から、どんな記事や分野が読まれているのかも見てみました。

観点	内容	傾向
タグ（分野）	Azure 関連	ビュー数・いいね数・ストック数とも比較的多い
タグ（分野）	Azure 以外	全体的に反応は控えめ
記事の内容	初心者・初学者向け	比較的ビュー数が多い
記事の内容	中級者・実務向け	全体的に反応は控えめ

タグ別に見ると、Azure タグの総ビュー数は約48万で、全体の約80％でした。
これまで Azure を中心に投稿してきたので、ある意味予想通りの結果です。

一方で、今回データをまとめてみて印象に残ったのが、いいね数やストック数が少なくても、ビュー数が多い記事があることです。

最近は、生成 AI 経由で検索・閲覧されるケースもあるかもしれませんが、それも必要な情報が誰かに届くための一つの形だと思います。

リアクションが少なくても、必要な人に情報が届いている。
そう考えると、これからも発信を続けるモチベーションになりそうです。

4-3.未更新記事情報を見てみる

最後に、地味に便利だったのが「未更新記事情報」です。

180日以上更新していない記事を対象に、ビュー数の多い順に表示しています。

この機能では、次のような記事を優先して確認できます。

• 長期間更新していない記事
• その中でも、よく読まれている記事

記事数が増えてくると、どの記事を長期間更新していないのか、だんだん追いきれなくなってきます。

「もう更新しなくてもいいかな」と思っていた記事も、よく読まれているものから見直せるので、これからかなり使いそうな機能です。

5.おわりに

今回、Qiita の活動データを可視化してみたことで、これまで手作業で確認していた情報をまとめて見られるようになり、活動を振り返る中で新しい気づきも得られました。

そして、せっかく活動データを蓄積できるようになったので、今後は生成 AI を活用して、データの分析や更新候補記事の提案、記事ネタの整理なども自動化してみたいと思っています。

また、今回は細かな実装コードではなく「Qiita の活動データを集めて、自分の発信を可視化する」というアイデアを中心に紹介しました。

この記事が、皆さんが自分の活動を振り返ったり、新しい仕組みを考えたりする際の参考になれば嬉しいです。

ここまで読んでいただき、ありがとうございました。

We Are Hiring!