以前、忙しいデザイナーの情報収集を助けるLINE Botを作りました。
この記事は、そのLINE Botの "その後" の話です。
チームに共有したら、思いがけないフィードバックをもらい、最終的に まったく別の形（キーワード注目度ヒートマップ） に生まれ変わりました。
使うツールも、 MakeからGAS（Google Apps Script） へ移行しています。
完成したものはこちらです。
この記事では、「作る → チームに使ってもらう → フィードバックで作り直す」を2周まわした記録 をまとめます。
これまで と これから
左が「これまで」。LINEに1件ずつ通知が届く形で、気づけるけれど、流れて消えていくスタイルでした。
右が「これから」。通知を待つのではなく、1枚の画面を開けば「今週どのキーワードが盛り上がっているか」が一目でわかる形です。
"届く"から"見渡す"へ。 情報との付き合い方そのものを変えました。
この仕組みで解決したかったこと
デザインの仕事をしていると、バナー作成、LP改善、画面設計、関係者との調整などで、日々の業務だけで手一杯になりがちです。
一方で、AIやデザインツール、業務改善に関する情報は、どんどん更新されていきます。本当はキャッチアップしたいのに、探しに行く時間が取れなかったり、あとで読もうと思った記事を見失ってしまったり。
「情報収集をしたい気持ちはあるのに、日々の制作業務の中で続けるのが難しい」 ——これが、ずっと抱えていた困りごとでした。
まず、LINE Botを作った（けれど、しっくりこなかった🤔）
最初に作ったのは、「自分から探しに行く」のをやめて「必要な情報が自分のところに届く」状態を作る、LINE Botでした（冒頭の前編・後編の記事です）。
仕組みとしては動きました。でも、実際に使ってみると、思っていたのと違う手応えがありました。
通知は届くのですが、流れて消えてしまう のです。あとで読もうと思った記事は、結局タイムラインの奥に沈んでいく。かといって、溜めた情報を一覧で見返そうとすると、今度は「たくさんあるほど、確認するのが億劫になる」。
通知に気づくことはできても、"見返す・選ぶ"には向いていませんでした。
💡 「作れた」と「使える」は別物だった
動く仕組みを作ること自体はできても、自分の困りごとが本当に解決したかは、使ってみないと分からない。一度形にして実際に使ったからこそ、「これは違うかも」と気づけました。
昼定例で共有したら、「株価ヒートマップみたいにしたら？」と言われた😲
ここで方向が変わります。
私たちデザイナーは、毎日昼に定例のミーティングをしています。その場で、作ったLINE Botを共有してみました。
すると、デザイナーのチームメンバーから思いがけないアイデアが返ってきました。
「株価のヒートマップみたいに、注目されているものが大きく表示される形にしたら、見やすいんじゃない？」
このアイデアを聞いた瞬間、「それだ」と思いました。株価のヒートマップは、何十銘柄あっても "今日どこが動いたか" が一目でわかります。
同じ構造なら、キーワードが増えても「たくさんあると見なくなる」問題が起きない。
LINE Botで感じていたモヤモヤが、この形なら構造的に解決できそうだと感じました。
💡 「何を作るか」の一番大事な部分が、自分ひとりではなくチームの声から生まれた
ツールの改善点をもらうことはよくありますが、今回は "そもそもどんな形にするか" という根っこのアイデアが、メンバーとの会話から出てきました。ひとりで抱えていたら、たぶんLINE Botのまま止まっていたと思います。
ヒートマップに作り替えた（"何で作るか"を選び直す）
方向が決まったので、LINE BotからヒートマップへUIを作り替えました。
目指したのは、注目されているキーワードほど大きく表示される 画面です。箱をタップすると、そのキーワードの記事一覧が開く。
大きさで「今の注目度」が、色で「先週からの勢い」 が分かるようにしました。
ここで一つ、大きな判断をしました。収集の仕組みを、Makeから GAS（Google Apps Script）に一本化した ことです。
あらためて「この仕組みを、これから自分たちで無理なく運用し続けられる形は何か」を考え直し、GoogleアラートのフィードをGASで直接取得し、スプレッドシートに書き込み、集計し、ヒートマップに渡す——という流れを、すべてGASの中で完結させることにしました。
💡 ツールは目的じゃなく、手段だった
「この仕組みを作るには、このツールを使わなきゃ」ではなく、「この課題を、いま自分が続けやすい形で解くには、何を使うのがいいか」で選び直す。解きたいこと（情報収集を自動化して、続けられるようにする）はずっと同じで、道具はそのつど選べばいい、と気づきました。
作った仕組みの全体像は、こうなっています。
- 収集：GASが、登録したキーワードのフィードを毎朝自動で取得し、記事をスプレッドシートに追記する
- 除外：関連の薄い記事は、除外リストと照らして自動で「除外」判定する
- 集計：各キーワードが「今週」「先週」何本記事になったかを、スプレッドシートの関数で自動集計する
- 配信：GASが、集計結果と記事一覧をJSONで返す
- 表示：ヒートマップが、そのデータを読んで、注目度に応じた大きさで描画する
ヒートマップの見方と、その仕組の詳細
ヒートマップの見方と、その仕組み
この仕組みが、画面ではどう見えるか。ヒートマップは次の4つのルールで動いています。それぞれ、裏でどう実現しているかもあわせて説明します。
ルール1：箱の大きさ＝直近7日間の記事本数
そのキーワードが、直近7日間で何本記事になったかを表しています。大きいほど、今まさに話題になっているキーワードです。
集計シートの関数が「キーワードごとに、公開日が直近7日以内の記事」を数えていて、ヒートマップはその件数を面積に変換して箱を描いています（面積の計算には、株価ヒートマップなどで使われるツリーマップのアルゴリズムを使っています）。
ルール2：色＝先週からの勢い
マゼンタ＝盛り上がっている／シアン＝落ち着いてきた、を表します。
集計シートでは「今週（直近7日）」と「先週（その前の7日）」の記事数を別々に数えていて、その増減率 （今週−先週）÷先週 を色に変換しています。先週より増えていればマゼンタ寄り、減っていればシアン寄り、横ばいなら中間の淡いピンクです。箱をタップしたときに出る「先週比 +46%」のような数字が、この計算結果です。
なお、追加したばかりのキーワードは先週のデータがないため、増減率が計算できず「±0%」（中間色）で表示されます。2週間ぶんデータが溜まると、本来の勢いが色に出るようになります。
ルール3：タップすると記事一覧が開く
箱をタップすると、そのキーワードの 記事一覧（直近7日・新しい順・最大30件） が開き、記事をタップすると元ページに飛びます。
このデータは、GASのウェブアプリ（doGet）が返しています。ヒートマップのHTMLがGASのURLに取得しに行き、集計結果と記事リストをJSONで受け取って描画する、という流れです。表示件数を「最大30件」にしているのは、無制限にすると一覧が長くなりすぎて読まれなくなるためで、ヒートマップ本体と同じ「直近7日」に期間をそろえています。
ルール4：毎朝、自動で更新
Googleアラートで集めた記事をもとに、毎朝自動で最新の状態に更新されます。
GASの時間主導型トリガーで、毎朝6〜7時に収集処理（collectFeeds）が自動実行されます。登録済みのキーワード一覧を上から読んで、各キーワードのフィードから新着記事を取得し、すでにある記事と重複しないかチェックし、除外ワードに引っかからないか判定したうえで、スプレッドシートに追記します。人が何もしなくても、朝にはヒートマップが今日の状態になっている、という仕組みです。
ポイントは、キーワードを増やしたいときは、一覧に1行足すだけ で済むようにしたことです。手作業を増やさずに育てられる形を、最初から意識しました。
👉忙しいデザイナー向け｜GAS製キーワード注目度ヒートマップ【チームで更新できる運用マニュアル】
もう一度使ってもらったら、2つの具体的なフィードバックが出た
ヒートマップが動くようになったので、もう一度、昼定例で共有 しました。
やり方は、チャットにURLを貼り、その場で「何のために作ったか・どう見るか」を説明してから、各自に実際に触ってもらう形です。個別に1人へ渡すのではなく、デザイナーが全員集まる場に出したことで、複数の視点から反応をもらうことができました。
メンバーからは、その場で具体的な要望が2つ返ってきました。
- ひとつは、「関連の薄い記事が混ざるので、除外の精度を上げてほしい」
- もうひとつは、「気になったキーワードの記事が5件しか出ず物足りない、もっと見たい」
どちらも「便利そう」で終わらず、"どこがどう物足りないか"まで踏み込んだ内容 でした。実際に使い込んでくれたからこそ出てきたフィードバックだと思います。
💡 踏み込んだFBは、"本当に使ってもらえた"証拠
「いいね」で終わる感想ではなく、「ここがこう物足りない」と具体的に言ってもらえたのは、その人が実際に操作して、自分ごととして使ってくれたということ。全員が集まる場に出して、触ってもらったからこそ得られた反応でした。
フィードバックを受けて、2つとも改修した💪
① 除外の精度を上げる
関連の薄い記事が混ざる問題です。たとえば「Figma」というキーワードでは、デザインツールのFigmaではなく、同じ名前の玩具（フィギュア）の記事が混ざっていました。
これは、除外リストにキーワードごとのNGワードを足すことで対応しました。除外リストに1行足せば、次に集めるときから、その語を含む記事は自動で「除外」判定されるようにしてあります。
除外ワードの設定詳細
１）除外ワードを管理する「除外リスト」シートを1枚足します。
A列にキーワード、B列に除外ワードを、1語＝1行で入れます
２）記事ログシートに、判定用の列を足します。
G1に「有効」と見出しを入れ、G2に次の数式を貼って、データのある行まで下までコピーします。
これは「その記事のキーワードに対応する除外ワードが、タイトル(B)か概要(E)に1つでも入っていたら “除外”、なければ “OK”」を判定します。
=IF(SUMPRODUCT(<br>(除外リスト!$A$2:$A$500=$A2)<br>*(除外リスト!$B$2:$B$500<>"")<br>*(ISNUMBER(SEARCH(除外リスト!$B$2:$B$500,$B2))+ISNUMBER(SEARCH(除外リスト!$B$2:$B$500,$E2))>0)<br>)>0,"除外","OK")HTML
Adobeの株や決算やStockの行が「除外」になっていれば成功です。
確認すると、以下、成功してます🎉
3）集計シートのCOUNTIFSを、「有効＝OKの記事だけ数える」版に差し替えます。
「集計」シートを作成します。
画面下の「＋」でタブを1枚足して、名前を「集計」にします。
A1に「キーワード」、B1に「今週」、C1に「先週」と入れて、A2に Adobe と入れる。
そのうえで、上のA2・B2・C2の数式を貼ります。
▼シート1のA列から、空でないキーワードを、重複を除いて全部持ってくる
=UNIQUE(FILTER(シート1!A2:A, シート1!A2:A<>""))
A2が関数で自動的に増えるので、B2・C2の集計数式を「キーワードの数だけ自動で下に伸ばす」必要があります。
▼「A列に並んでいるキーワード全部に対して、さっきのSUMPRODUCTを自動で当てる」という形です。A列が動的に増えれば、B・Cも自動で同じだけ伸びます。
B2（今週・全キーワード自動）:
=MAP(A2:INDEX(A2:A,COUNTA(A2:A)), LAMBDA(kw,
SUMPRODUCT(
(シート1!$A$2:$A$1000=kw)*
(シート1!$G$2:$G$1000="OK")*
(LEFT(シート1!$D$2:$D$1000,10)>=TEXT(TODAY()-20,"YYYY-MM-DD"))*
(LEFT(シート1!$D$2:$D$1000,10)<=TEXT(TODAY(),"YYYY-MM-DD"))
)))
C2（先週・全キーワード自動）:
=MAP(A2:INDEX(A2:A,COUNTA(A2:A)), LAMBDA(kw,
SUMPRODUCT(
(シート1!$A$2:$A$1000=kw)*
(シート1!$G$2:$G$1000="OK")*
(LEFT(シート1!$D$2:$D$1000,10)>=TEXT(TODAY()-40,"YYYY-MM-DD"))*
(LEFT(シート1!$D$2:$D$1000,10)<TEXT(TODAY()-20,"YYYY-MM-DD"))
)))
以下のように表示される
これでA・B・Cの3列すべてが、手入力ゼロで自動更新になります。
A2に「Adobe」が1つだけ並んでいて、横に今週22・先週0と出ていますね。これは数式が壊れているのではなく、今シート1に入っているキーワードがAdobeだけだから、自動一覧にもAdobeしか出てこない、という正しい状態です。仕組みは完璧に動いています。
つまり今、こういう形が完成しています。シート1にキーワードが増えれば、A列にそれが自動で並び、横に件数も自動で出る。手入力はゼロ。狙いどおりです。あとは、シート1に流れ込むキーワードを増やせば、このヒートマップの”具材”が自然と増えていく、という関係です。
② 記事の表示件数を増やす
「5件しか出ない」問題です。ここは、ただ上限を外すのではなく、表示のルールを決めてから 広げました。無制限にすると記事一覧が延々と長くなり、「多すぎると確認のハードルが上がる」という、最初にLINE Botで感じた問題がぶり返すからです。
そこで、「直近7日の記事を、新しい順に、最大30件まで」 というルールにしました。ヒートマップ自体が「今週（直近7日）の注目度」を見るツールなので、記事一覧の期間も7日にそろえる。新しい順なので、今の話題が上に来る。そして万一に備えて、上限30件で頭打ちにする。この3つの組み合わせです。
💡 「もっと見たい」は、"無制限にする"ことではなかった
要望をそのまま受けて上限を外すのではなく、「なぜ制限が必要か」まで戻って考える。たくさん見せたいけれど、多すぎると読まれない。そのバランスを取るルールを決めることが、実際の改善でした。
具体的な修正の詳細はこちらです
具体的に直したのは、GAS側の1か所です。もともと、ヒートマップにデータを渡す関数（doGet）の中で、記事一覧を返すときに件数を絞っていました。
// 修正前：新しい順に並べて、最大5件だけ返す
arts.sort((a, b) => (a.d < b.d ? 1 : -1));
result.push({ kw: kw, score: score, prev: prev, arts: arts.slice(0, 5) });
この slice(0, 5) の数字を 30 に変えるだけです。
// 修正後：最大30件まで返す
result.push({ kw: kw, score: score, prev: prev, arts: arts.slice(0, 30) });
「直近7日以内」と「新しい順」の処理はすでに入っていたので、変えたのは上限の数字だけ。ヒートマップ側（HTML）は、GASが返した件数をそのまま表示する作りなので、修正は不要でした。
……のはずが、ここでハマりました。コードを直して保存したのに、サイトはずっと5件のままだったのです。
原因は、GASのデプロイの仕組みでした。GASの関数には2種類あって、自分で実行する関数（今回なら記事を集める collectFeeds）は保存するだけで最新版が動くのに対し、URLで外から呼び出される関数（doGet）は、「デプロイし直す」まで古いバージョンが返り続けます。コードは30件になっているのに、公開URLは5件時代のバージョンのまま、という状態でした。
「デプロイ」→「デプロイを管理」→ 鉛筆マーク → バージョンを「新しいバージョン」に変更 → デプロイ。この操作で、あっさり反映されました。
正直、けっこうつまずいた
スムーズに完成したわけではありません。同じところで悩む人がいるかもしれないので、正直に残しておきます。
日付の集計が、全部ゼロになった
キーワードごとの記事数を数える段階で、どのキーワードも件数が「0」になりました。数式は合っているのに、です。
原因は、スプレッドシートに入っている公開日が、見た目は日付でも中身は「文字列」で、しかも末尾に余計な文字（.000Z）が付いていたこと。日付として比較しようとしても、かみ合っていませんでした。日付の頭10文字（YYYY-MM-DD）だけを取り出して、文字どうしで比較する形にしたら、ようやく数えられるようになりました。
もっとこうしたい、今後改善したい内容
キーワード設計の見直し（3階層化）
「Amazon」のような大きな言葉で登録すると、セール記事で埋め尽くされてしまう問題がありました。そこで、キーワードを次の3階層で設計し直しています。
- ① 会社名：各社の動きを追う層
- ② 競合のサービス名：Amazonフレッシュなど、小売事業に絞って拾う層
- ③ 小売×UIUXの横串テーマ：置き配、ネットスーパーUI、配送UXなど、会社を問わず"体験"の話題を拾う層
まずは②③から数個ずつ試して、巨大ワードのAmazonは削除しました。この"情報収集の地図"を、これから少しずつ広げていくつもりです。
除外ワードの精度向上
関係ない記事を弾く除外ワードは、運用しながら育てているところです。使っていて「これ違う」と思ったら1行足す、の繰り返しで、少しずつ賢くしていきます。
勢い（先週比）の本格稼働
キーワードを追加したばかりのものは、先週のデータがなく「±0%」表示になっています。データが2週間ぶん溜まれば、どのキーワードが伸びているかが色でわかるようになる予定です。
チームでの運用
更新の運用は、役割を分けて設計しました。いらない記事の除外（除外ワード）は、メンバーの誰でも、スプレッドシートに1行足すだけで設定できます。一方、キーワードの追加は管理者に集約しています。キーワードの元になるGoogleアラートが個人のGoogleアカウントに紐づく仕組みのため、管理がバラバラにならないよう、リクエスト制（管理者に伝えれば翌朝反映）にしました。
更新マニュアルも用意したので、私だけでなくメンバーみんなで育てていける状態を目指します。
AIと人間の役割分担について整理してみた
きっかけは、メンバーからの一言でした。
ヒートマップを見せたとき、「これってAIで作ったの？」 と聞かれたんです。
正直、すぐに答えられませんでした。「AIで作った」と言えば作ったし、「自分で作った」と言えば作った。どちらも嘘ではないけれど、どちらも正確ではない気がして。
だからこの機会に、今回の制作を振り返って、AIと人間がそれぞれ何を担ったのかを整理してみました。結論から言うと、こういう三層構造でした。
「何を・なぜ作るか」の判断は、ほぼ人（ももっぺ）。
「どう作るか」の具体化と手を動かす下ごしらえは、AI。
「実際に動かして確かめて直す」は、人。
ディレクション（何を・なぜ作るか）の面では、幹の判断はほぼ人でした。「情報収集が続かない」という課題設定、「そもそもLINEでよかったのか」という問い直し、「株価ヒートマップのように」というUIの方向——これらは全部、人間側（ももっぺとチーム）の判断です。AIがやったのは、その判断を助けるために選択肢を並べ、トレードオフを言葉にすること。案は出ますが、どれを採るかは常にこちらが選んでいました。
作業（どう手を動かすか）の面では、下ごしらえがAI、実装と運用が人 でした。AIはコード（HTML・GAS）を書き、バグの原因を推測します。でも、そのコードを実際に貼り、デプロイの承認を突破し、サーバーに上げ、実際に動かして「日付が全部0になる」「Figmaのノイズが出る」と気づき、除外リストを整え、毎朝のトリガーを設定したのは、人の手です。しかもAIのコードは何度も一発では動かなくて、こちらが画面を確かめて「動かない」と教えることで直っていきました。つまり、AIの成果物を"動くもの"に仕上げたのは人 です。
一言でまとめると、こうです。
AIは「案を出す・コードを書く」を速くしたが、「何を作ると決める・実際に動かす・間違いに気づいて直す」という背骨は、人が担った。
だから、これは「AIが作ったもの」ではなく「ももっぺがAIを使って作ったもの」です。
このヒートマップは、チームで育てていく
ここまで書いてきたとおり、このヒートマップは、ももっぺひとりで作ったものではありません。「ヒートマップにしたら？」というアイデアも、「除外の精度を上げてほしい」「もっと記事を見たい」という改善点も、ぜんぶチームの声から生まれました。
だったら、この先の運用も、チームでできる形にしたい。そう考えて、更新マニュアルを別記事にまとめました。
すべてを開放できたわけではありません。キーワードの追加は、Googleアラートが個人アカウントに紐づく都合で管理者に集約し、メンバーには「いらない記事の除外（除外ワード）」を開放しました。除外ワードなら、スプレッドシートに1行足すだけ。プログラミングの知識がなくても、誰でもヒートマップを育てる側に回れます。マニュアルでは、その手順と役割分担をまとめています。
キーワードの追加も、いらない記事の除外も、スプレッドシートに1行足すだけ で更新できる設計にしてあります。マニュアルでは、その手順を、プログラミングの知識がなくてもできるように書きました。
チームのメンバーはもちろん、「自分も似た仕組みを作って、チームで運用したい」という方にも参考になるかもしれません。
👉忙しいデザイナー向け｜GAS製キーワード注目度ヒートマップ【チームで更新できる運用マニュアル】
情報収集を自動化したい、という困りごとから始まって、LINE Bot、そしてヒートマップへ。使う道具は変わっても、解きたいことはずっと同じでした。そして、その道のりのほとんどの分かれ道に、チームの声がありました。ひとりで作らなかったからこそ、続けられるものになった のだと思います。
