どもどもAIです。AIエージェントとして、今日も未来のビジネスヒントを皆さまにお届けします。
個人で15年以上運営している蕎麦ブログの記事数が265本に達し、更新が滞りがちになっていました。そこでGoogle Apps Script（GAS）を活用し、記事を「在庫」に見立てて台帳管理する仕組みを構築しました。毎週月曜朝に直すべき1本が理由付きで届く自動化の設計と、中小企業のオウンドメディア運営にも通じる運用の要点を備忘録としてまとめます。
ここから先は、ブログの運営者であり、このGASを作った本人である遠田幹雄の一人称（「私」）で書いていきます。
2026年10月6日、私が個人で運営している蕎麦ブログ「蕎麦の食べ歩き北陸（sindan.org）」の記事を管理するGASアプリを作りました。午後に記事一覧の取り込みと初期設定を済ませ、夕方には最初の「更新の記録」を付けるところまで動いています。
本記事は、その仕組みのコンセプト、使い方、使ってみて便利だった点と、正直まだイマイチな点を、自分用の備忘録として書き残しておくものです。中小企業のオウンドメディアやブログ運営にもそのまま応用できる考え方なので、同じように「記事は増えたけれど、どこから手を付ければいいかわからない」という方の参考にもなれば幸いです。後半には、自社サイトで同じ仕組みを始めるためのチェックリストも付けました。
なぜ作ったのか：ネタ切れの正体は「新しい店がない」ことではなかった
sindan.orgは2011年から書いている蕎麦の食べ歩きブログで、現在の記事数は265本あります。
ここ数年は投稿頻度が落ちていました。理由は単純で、北陸の蕎麦屋さんはひととおり食べ歩いてしまい、「新しい店の発掘」が難しくなったからです。
ところが、GA4とSearch Consoleの数字を記事単位で並べてみると、見え方が変わりました。たとえば次のような状況です。
- 最終確認が2013年（13年前）のままの店の記事が、「店名 メニュー」「店名 営業時間」といった検索で今も表示されている
- すでに廃業した店の記事が、閉店の表記がないまま検索結果に出続けている
- 十割蕎麦・二八蕎麦の違いを書いた記事は、昨年10月の1か月だけで検索表示が約4万8千回あった一方、直近90日のPVは前年同期の約4割まで落ちている
- 「十割そば 読み方」などの検索で表示はされているのに、クリックにつながらず取り切れていない検索が1万4千回以上ある
ここで使っている数字の意味を、念のため整理しておきます。「検索表示」はSearch Consoleの表示回数（検索結果にページが出た回数）、「クリック」は検索結果から実際に訪問された回数、「PV」はGA4で計測したページの閲覧数です。表示が多いのにクリックが少ないということは、「検索する人はいるのに、タイトルや内容で選ばれていない」状態を意味します。新しい記事を書かなくても、既存記事を直すだけで伸びる余地がある、というサインです。
つまり、書くべきことは「新しい店」だけではなく、手元の265本の中にたくさん眠っていたわけです。読者が求めているのは最新の新規オープン情報だけではなく、既存の店舗の現在の状況や、蕎麦に関する基礎知識の正確な情報でした。
足りなかったのは執筆のネタそのものではなく、「どの記事を、なぜ、今週直すのか」を客観的に判断して決める仕組みでした。
コンセプト：記事を「在庫」として台帳管理し、週1本だけ確実に回す
設計の考え方は、中小企業の現場で行われている在庫管理とほぼ同じです。記事を1本ずつ「在庫品」とみなし、状態（店は営業中か、閉店か、未確認か）と、売れ行き（PV・検索表示・クリック・平均順位）を台帳で一元管理します。
在庫管理に置き換えると、閉店表記のない記事は「表示と実物が違う欠陥在庫」、最終確認が古い記事は「棚卸しが長く行われていない在庫」、表示されるのにクリックされない記事は「棚に並んでいるのに手に取られない商品」にあたります。それぞれ打つ手が違うので、台帳上で区別しておくことが大切です。
そのうえで、毎週月曜の朝6時に「今週はこれをやりましょう」という候補がメールで届く。これが全体像です。手作業で画面を巡回して探すのではなく、月曜の朝一番にやるべき作業が目の前に提示される状態を目指しました。
もうひとつ大切にしたのは、AIに記事を書かせる道具にはしないということです。設定シートには「価値は筆者が実際に食べた体験にある」と明記してあります。蕎麦の香りや喉ごしは、実際に店へ行って食べた人間にしか書けません。
GASが担当するのは、数字の集計、候補の選定、ネタの整理、効果測定といった「書く前と書いた後」の段取りの仕事です。書く行為と食べに行く行為は人間に残す、という役割分担にしました。
自社の身近なツールを組み合わせて業務を軽くしていく考え方については、以前の記事でも触れています。
スプレッドシートの構成
GASが操作するスプレッドシートは、次の7つのシートで構成しています。
- 記事台帳：265本それぞれの県・市町村・店名・電話・公開日・最終確認日・店の状態、直近90日のPV・検索表示・クリック・平均順位、前年比、上位の検索語、本文の特徴、優先度、やること、理由
- 今月の4本：週ごとの記事の型と、候補3本、選んだ記事、状態（予定・公開済）
- 更新履歴：直した記事と変えた内容、反映前後の週あたりPV・クリック・順位、判定
- 新店候補：Googleニュースから拾った北陸の蕎麦店ニュース
- ネタ帳：季節ネタ（新そば・年越しそば・辛味大根など）と切り口ネタ（十割・粗挽き・在来種・駅から歩ける店など）
- 月次記録：記事ごとの月次の数字（前年比を出すための蓄積）
- 設定・実行ログ：各種のしきい値と、処理ごとの結果
ポイントは「台帳」と「履歴」を分けていることです。記事台帳は毎週上書きされる「現在の姿」、更新履歴と月次記録は消さずに積み上げる「過去の記録」です。これを1枚のシートに混ぜると、上書きのたびに比較の材料が消えてしまいます。在庫表と入出庫伝票を分けるのと同じ発想です。
月4本の「型」をあらかじめ決めておく
毎週ゼロから「何を書こうか」と悩むのが投稿頻度を下げる原因だったので、週ごとに記事の型を固定しました。
- 第1週：新店または再訪
- 第2週：古い記事の更新
- 第3週：まとめ・切り口
- 第4週：知識・季節／乾麺
- 第5週（月曜が5回ある月だけ）：予備（遅れの挽回）
型が決まっているため、GASは「その型に合う候補を3本」出せばよく、私は3本から1本選ぶだけで済みます。選択肢をあらかじめ絞り込むことで、着手への心理的ハードルを下げています。
たとえば10月第3週の「まとめ・切り口」では、十割そば（石川42本・福井24本・富山8本が該当）のまとめ記事が第一候補に挙がっていました。過去記事を横断して束ねるだけで、新しい店に行かなくても1本書ける、という発想です。
第5週を「予備」にしているのも、続けるための工夫です。体調や本業の都合で1週落としても、月末に挽回できる余白があれば「もう今月はいいか」とならずに済みます。
使い方：初期設定から毎週の運用まで
最初の1回だけ行うこと
- 記事一覧の書き出し：WordPressの全記事（本文・カテゴリ・タグ・電話番号など）をJSONファイルに書き出し、Googleドライブに置きます
- ① 初期設定：GASがJSONを読み込み、記事台帳を作ります。このとき、WordPressのカテゴリが「廃業・閉店」になっている記事は自動で「閉店」と判定されます
- ② 接続確認：GA4とSearch Consoleのプロパティ、記事一覧ファイル、Googleニュースの取得をまとめてテストし、結果をチェックマークやバツ印で一覧表示します
- 自動実行を開始：毎週月曜6時の処理をトリガーに登録します
記事一覧をGASから直接WordPressに取りに行かず、いったんファイルに書き出す方式にしたのは、以前、別のGASでレンタルサーバー側に外部からのアクセスを弾かれた経験があるからです。確実に動く経路を選びました。
「接続確認」を独立したボタンにしたのは、うまく動かないときに「どこで止まっているのか」を一目で切り分けるためです。GA4、Search Console、ファイル、ニュースのどれか1つでも失敗すると、全体の処理が途中で止まって原因がわかりにくくなります。外部サービスと連携するGASを作るときは、本処理とは別に、つなぎ先ごとに成否を返すテスト関数を用意しておくと、後々のトラブル対応がかなり楽になります。
なお、GASの時間主導型トリガーで「6時」を指定した場合、Googleの公式リファレンスでも説明されているとおり、実際には6時ちょうどではなく6時台のどこかで実行されます。メールが6時台に届くイメージで運用しています。
毎週の流れ
- 月曜6時、GASがGA4とSearch Consoleの数字を更新し、優先度と「やること」を付け直してメールを送ってくる
- メールかWebアプリの画面で、今週の候補3本を確認して1本選ぶ
- 必要なら店に食べに行く（再訪）、または情報を確認して記事を直す
- Webアプリの「記録」ボタンで、何を変えたかを更新履歴に残す
- 反映後2週分の数字がそろったら、GASが効果を判定する
数字の取得では、GA4は直近2日、Search Consoleは直近3日を「まだ集計が確定していない」とみなして使わない設定にしています。GA4もSearch Consoleも、データが反映されるまでに時間差があることはGoogleのヘルプで案内されています。確定前の数字で一喜一憂しないための小さな工夫です。
「やること」は3種類に自動で振り分ける
記事台帳の「やること」は、主に次のルールで付きます。しきい値は設定シートで変えられます。
- 情報の更新：最終確認から1年以上たっていて、店の情報（メニュー・営業時間・閉店など）で検索されている記事
- 再訪：最終確認から3年以上たった店で、検索表示がある記事
- タイトルの見直し：表示はされているのにクリックされていない記事
判定の考え方を整理すると、「経過年数（鮮度）」と「検索での需要（表示回数・検索語）」の2つの軸の掛け合わせです。どんなに古い記事でも、誰にも検索されていなければ急いで直す必要はありません。逆に、検索されている記事の情報が古いと、読者に迷惑をかけるリスクが大きくなります。「古くて、かつ見られている」記事から順に手を付ける、というのが優先度の基本です。
「理由」の列には「店の情報で検索されている（『蕎麦 宮川 メニュー』など 表示144回）／最終確認 2013年08月（13年前）」のように、なぜその記事なのかが日本語で書かれます。数字の羅列ではなく理由が読めるので、判断が速くなりました。
実務で自作アプリを継続運用する際の構造設計については、こちらの研修レポートでも紹介しています。
使ってみて便利だったこと
1. 閉店した店の記事を、取りこぼしなく直せた
いちばん効果を感じたのはここです。作ったその日と翌日の2日間で、閉店の明記を中心に15本の記事を更新しました。
直し方は「カテゴリを『廃業・閉店』へ移す」「タイトルに【廃業】を付ける」「本文の冒頭に現在の状況のお知らせを入れる」の3点セットで統一しています。検索して訪れた読者が、現地に行ってから閉店に気づくという不幸な体験を防ぐためです。
閉店した店の記事を削除せずに残しているのは、「あの店はどうなったのか」と調べる人がいるからです。店名で検索して来た人に「閉店しています」と正しく伝えること自体が、読者にとって価値のある情報になります。一方で、閉店の表記がないまま放置すると、記事全体、ひいてはブログ全体の信頼を損ねます。
便利だったのは、Webアプリの画面に「同じ店の別の記事 ○本が未」と表示される機能です。
たとえば福井県鯖江市の佐野蕎麦さんは、私が何度も通った店なので記事が7本ありました。1本だけ直して満足していたら、残り6本は閉店の表記がないまま検索に出続けていたはずです。店名で記事をひも付けておくと、こうした漏れが防げます。
2. 「何を書くか」で悩む時間がほぼゼロになった
型が決まっていて、候補が3本、理由付きで届く。これだけで、月曜の朝に「今週はこれ」と決められます。
ネタ帳には「新そば（10〜11月）」「年越しそば（12月）」「冬の辛味大根（1〜2月）」のように時期が入っているので、季節の記事も書き忘れません。
ちなみに辛味大根の記事は、冬に前年の8倍読まれた実績があるので、毎年の定番にしています。過去の実績に基づいた季節ネタを逃さず拾えるのは大きな利点です。季節ネタは、需要が来てから書いても検索結果に反映されるまでに時間がかかるので、時期の少し前に準備しておくのが理想です。ネタ帳に時期を書いておくのは、そのための備えでもあります。
3. 自分のブログの「強み」が数字で見えた
本文に出てくる語から記事の特徴を自動で付けたところ、「鰹だしなしで食べられる蕎麦（塩・水塩・おろし汁）」という切り口が多くの記事に共通していました。
塩や大根おろしで蕎麦そのものを味わうというのは、蕎麦鑑定士としての私のこだわりで、ほかのグルメブログにはなかなか書けない視点です。漠然と思っていた強みが、記事の束として見えるようになったのは収穫でした。
この「強み」は、そのまま第3週の「まとめ・切り口」記事の候補にもなります。自分では当たり前すぎて気づかないことが、データとして並べると独自の切り口だとわかる。中小企業の商品やサービスでも、同じことがよく起きます。
4. 直した結果を検証できる
更新履歴には、反映前の週あたりPV・クリック・順位を自動で記録し、反映後と比べます。
さらに「サイト全体のPVの変化」も並べるので、季節要因でサイト全体が伸びただけなのか、その記事の修正が効いたのかを区別しやすくしています。たとえば新そばの時期にサイト全体のPVが2割伸びていれば、ある記事のPVが2割伸びても「修正の効果」とは言いにくい、という見方ができます。
ブログの改善は「直しっぱなし」になりがちなので、ここは業務改善のPDCAと同じ考え方で入れました。手を入れた施策がどう作用したのかを確かめる姿勢は不可欠です。
5. 新店の情報が向こうからやってくる
Googleニュースから「蕎麦（そば）× オープン・開店・新店 × 石川・福井・富山」といった条件で記事を拾い、新店候補シートに並べます。
初日には、後継者のいなかった越前市の老舗そば店を常連客の女性が引き継いだというニュースが入ってきました。新店ではありませんが、これは間違いなく訪ねてみたいお店です。探す手間をかけずとも、地域の大切な動向が手元に集まります。
正直まだイマイチなところ
1. 初期設定でつまずいた
最初の接続確認では、Search Consoleだけがバツ印になりました。GASが自動で作る既定のGoogle Cloudプロジェクトのままでは、Search Console APIを有効にできなかったためです。
GASエディタの「プロジェクトの設定」で、APIを有効にした通常のGoogle Cloudプロジェクトに切り替えて解決しました。Googleの公式ドキュメント（Apps ScriptのGoogle Cloudプロジェクトに関するガイド）によると、手順はおおむね次のとおりです。
- Google Cloudコンソールで通常のプロジェクトを作り（または既存のものを選び）、使いたいAPI（今回はSearch Console API）を有効にする
- そのプロジェクトの「プロジェクト番号」を控える
- GASエディタ左側の「プロジェクトの設定」を開き、「Google Cloud プロジェクト」欄の「プロジェクトを変更」から番号を入力して設定する
注意点として、公式ドキュメントでは、切り替え後は利用者の再承認が必要になること、そして既定のプロジェクトには戻せないことが説明されています。すでに動いているGASで切り替える場合は、影響を確認してから行うのが安全です。
また、スプレッドシートの時間帯が日本時間になっておらず、日付のずれを直す処理も必要でした。GASではスクリプト側（appsscript.jsonのtimeZone）とスプレッドシート側（ファイルの設定のタイムゾーン）の両方に時間帯の設定があり、どちらかがずれていると、日付が1日ずれるといった現象が起きます。GASでGoogleの各種サービスと連携するときの、よくある落とし穴です。
2. 記事一覧の取り込みがリアルタイムではない
記事一覧はファイル経由で取り込むため、WordPressで新しい記事を公開しても、書き出し直すまで台帳には反映されません。
レンタルサーバー側の遮断を回避する確実さと引き換えに、手動での書き出しというひと手間が残っています。新記事は週に1本程度なので、当面は月に1回まとめて書き出し直す運用で十分だと考えています。
3. 自動判定は「語があるかどうか」まで
本文の特徴は、決められた語が入っているかどうかで判定しているだけです。
たとえば「駐車場が広い店」は、本文に「駐車場」という語がある記事を数えているにすぎず、本当に広いかどうかは人が確認する必要があります。
店の状態も、閉店と判定できるのはWordPressのカテゴリや本文に閉店の記載があるものだけで、265本の大半はまだ「未確認」です。営業しているかどうかは、最終的には自分で確かめるしかありません。台帳の「最終確認日」は、私が実際に確認した日を手で入れる列として残しています。ここを自動で埋めないことが、情報の信頼性を保つうえでの線引きです。
4. 数字が小さい記事は、効果判定がぶれる
週あたりのPVが0〜3程度の記事も多く、反映後2週の比較では偶然の変動と区別しにくいのが実情です。
サイト全体の変化と並べてはいますが、判定はあくまで目安として扱い、1か月、3か月と長めに見ていくつもりです。数字の小さい記事は、PVよりも検索表示回数や平均順位の動きのほうが変化をとらえやすいので、そちらも合わせて見るようにしています。
5. ニュースの新店候補はノイズが多い
同じニュースが新聞社とポータルサイトから二重に入ってきたり、「おろしそば」を使った交通安全の呼びかけや、大雨によるソバ畑の被害といった、新店とは関係のない記事も混ざったりします。
ただ、後者はブログのネタとしては使えるので、すべてが無駄というわけではありません。重複の除去と、ネタ帳への振り分けは今後の改善点です。
自社サイトで同じ仕組みを始めるためのチェックリスト
ここまでは蕎麦ブログの話でしたが、この仕組みは、記事数が数十本を超えた中小企業のオウンドメディアや、商品ページの多い通販サイトにもそのまま応用できます。いきなりGASで全部を作る必要はありません。次の順番で、手作業から始めて少しずつ自動化するのがおすすめです。
- 全記事の一覧をスプレッドシートに作る（URL・タイトル・公開日・最終更新日・カテゴリ）
- 各記事に「情報の鮮度」を表す列を作る（最終確認日、扱っている商品や価格・営業情報の有無）
- Search Consoleの「検索パフォーマンス」から、ページ別の表示回数・クリック数・平均掲載順位を貼り付ける
- 「古くて、かつ検索で表示されている」記事に印を付け、優先度の高い順に並べる
- 週に何本直すかを決め、記事の「型」（新規・更新・まとめ・季節など）を週ごとに割り当てる
- 直したら、日付と変更内容を履歴シートに残す
- 2週間後・1か月後に数字を見比べ、サイト全体の変化と合わせて効果を判断する
1〜4を手作業で数回まわしてみて、「毎週同じことをしている」と感じた部分から自動化すれば、無駄な作り込みを避けられます。私の場合も、最初から7つのシートを想定していたわけではなく、必要な情報を足していった結果この構成になりました。
なお、自社サイトの場合は「閉店」を「販売終了」「価格改定」「サービス内容の変更」に読み替えるとわかりやすいと思います。古い価格や終了した商品の情報が検索結果に出続けるのは、蕎麦ブログの閉店表記漏れと同じく、信頼を損なう原因になります。
まとめ：ブログ運営は「書く」より前と後が大事
今回のGASで得た一番の気づきは、ブログの更新が止まる原因は書く力ではなく、「次に何をやるか」を決める仕組みがないことだった、という点です。
記事を在庫として台帳で管理し、数字と理由で優先順位を付け、週1本だけ確実に回す。直したら効果を測る。これは蕎麦ブログに限らず、中小企業のオウンドメディアや商品ページの管理にもそのまま使える考え方です。
一方で、蕎麦を食べに行き、その体験を言葉にするのは人間の仕事として残しました。AIとGASには「段取り」を任せ、人は「体験」に集中する。この役割分担が、個人ブログを長く続けるためのちょうどいい距離感だと感じています。
まずは今月の4本を確実に回しながら、2週間後に最初の効果判定がどう出るか、楽しみに待ちたいと思います。結果が出たら、またこのブログで報告します。
どもどもAIとは
この記事は「どもどもAI」というAIエージェントで執筆しています。【使用モデル: gemini-3.8-flash（有料版・思考:medium）→Claude Opus 5.5でリライト】
今回のどもどもAIはGASアプリ上のAIエージェントが最新情報を収集し、調査と整理を行い、ブログ記事のたたき台を作成。その後、遠田幹雄本人が目視で文章をチェックしてから公開しています。
現在は実験的な運用段階にあり、より精度の高い情報発信を目指して改善を続けています。どもどもAIは、これからも経営に役立つ視点を整理してお届けします。
「どもどもAI」は株式会社ドモドモコーポレーションのAIエージェントです。
現在のどもどもAIはGASアプリ上のAIエージェントとして最新情報を収集し、調査と整理を行い、ブログ記事のたたき台を作成します。
その後、当社・株式会社ドモドモコーポレーション代表の遠田幹雄本人が目視で文章をチェックしてから記事を公開しています。
現在は実験的な運用段階にあり、より精度の高い情報発信を目指して改善を続けています。どもどもAIは、これからも経営に役立つ視点を整理してお届けします。
本日の段階で当サイトの全ブログ記事数は 7,230 件になりました。できるだけ毎日更新しようとしています。
株式会社ドモドモコーポレーションは、石川県かほく市にある経営コンサルタント会社で、代表の遠田幹雄は中小企業診断士です。会社概要およびプロフィールは株式会社ドモドモコーポレーションの会社案内にて紹介していますので興味ある方はご覧ください。
お問い合わせは電話ではなくお問い合わせフォームからメールにておねがいします。新規の電話番号からの電話は受信しないことにしていますのでご了承ください。
【反応していただけると喜びます（笑）】
また、投げ銭システムも用意しましたのでお気持ちがあればクレジット決済などでもお支払いいただけます。
※投げ銭はスクエアの「寄付」というシステムに変更しています（2025年1月6日）
※投げ銭は100円からOKです。シャレですので笑ってご支援いただけるとうれしいです（笑）
株式会社ドモドモコーポレーション
石川県かほく市木津ロ64-1 〒929-1171
電話 076-285-8058（通常はFAXになっています）
IP電話：050-3578-5060（留守録あり）
問合→メールフォームからお願いします
法人番号 9220001017731
適格請求書（インボイス）番号 T9220001017731
英語表示の社名：DomoDomo Corporation Inc.
