本記事は note で先行公開した記事を、加筆・再構成したものです。
はじめに：失敗談シリーズ第2弾です
また、ちょっと格好悪い話を書きます。
少し前に、本番Firestoreを2ヶ月、誰でも読み書きできる状態のまま運用していた話を書きました。
AI経営パートナーにコードレビューを頼んだら、致命的なセキュリティの穴を発見してくれた、という失敗談です。
今回は、その失敗談シリーズ第2弾。
舞台はシステムではなく、自社のホームページです。
「業務改革コンサル」を看板に掲げている会社のホームページに、約1年間、29本のブログ記事を書いてきました。
書いた本数だけ見れば、それなりに発信してきたつもりでした。
ところが今月、AI経営パートナーにSEO診断をしてもらったら、こう言われました。
「これ、検索エンジンから見たら、ほぼ何も書いてない状態です」
血の気が引きました。
1. 「ブログを書いている」と「検索エンジンに届いている」は別だった
事の発端は、ちょっとした相談でした。
「最近、HPのブログ更新が止まりがちです。再開したいんですが、何から手をつけたらいいですか。」
軽い気持ちで、AI経営パートナーに投げた質問でした。新しい記事のテーマを一緒に考えてもらえると思っていたのです。
ところがAI経営パートナーは、こう返してきました。
「新しい記事を書く前に、まず既存記事のSEO診断をしましょう。『書いた量』と『届いた量』は別物です。先にそこを点検しないと、これから書く記事も同じように埋もれます」
ぐうの音も出ませんでした。「届いているか」を、私は1回も確認していなかったからです。
その日、AI経営パートナーは自社HPのURLを実際に取得して、HTMLを精査し始めました。29記事すべての中身を、検索エンジン側からの視点で1本ずつ読み込んでいきます。そして、しばらくして、こう報告してきました。
「すぐにご報告すべき重大な発見があります。既存ブログ記事29本のmeta descriptionが、全件"空"になっています。さらに、JSON-LD構造化データが、サイト全体でゼロ件です」
2. 「meta descriptionが空」とは、どういうことか
少しだけ、技術の説明をさせてください。
ブログ記事をGoogleで検索すると、検索結果に「タイトル」と「説明文（スニペット）」が出ます。
あの説明文を、サイト側で指定するのが「meta description」というタグです。
これを書いておくと、Googleはその文章を検索結果の説明欄に使ってくれます。
書いていないと、Googleが本文から勝手に断片を拾って表示します。多くの場合、それは中途半端で意味不明な文章になります。
つまり、meta descriptionが空ということは——せっかく書いた記事の見出しが検索結果に並んでも、その下の説明文が「読みたくなる文章」になっていないということです。
AI経営パートナーの推定では、これだけでクリック率（CTR）が30〜50%損失している状態でした。29記事すべてで、です。
さらに「JSON-LD構造化データ」というのも一切入っていませんでした。
これは、Googleに「これは会社情報です」「これは記事の投稿日です」「これは著者です」と明示的に伝えるためのタグです。
これがないと、Google検索結果の右側に出る「ナレッジパネル」が出にくくなる。
第1弾のFirestoreが「鍵をかけていなかった」話なら、今回は——「鍵はかけたけれど、看板を出していなかった」話です。
お店は開いているのに、通りからは「何屋さんか分からない」状態。これが、私の会社のHPで1年間続いていました。
3. なぜ気づかなかったのか
ここからは、自分への言い訳混じりですが、振り返ります。
HPは、私が直接コードを書いて作ったものではなく、Jimdoというノーコードツールで作っています。
「書きたい記事を書いて、保存すれば公開される」というシンプルな仕組みです。その手軽さが、罠でした。
「保存ボタンを押した時点で、私の中では仕事が完了していた」のです。書いた記事が検索結果でどう見えるか、どう拾われるか、確認する習慣がありませんでした。
そもそも、Jimdoの記事編集画面に「SEO設定」というメニューがあることすら、まともに見ていませんでした。
「ページの説明」という入力欄が空のまま、淡々と保存ボタンを押し続けていた。それが29回続いた、というだけの話です。
——AI開発のときと、同じ構造でした。
Firestoreのときは「ログインで守られているから大丈夫」と勘違いしていました。
今回は「ブログを書いているから発信できている」と勘違いしていました。「やった気になっていた」——どちらも、同じ正体です。
4. その日のうちに、対応プランが完成した
ここからは、AI経営パートナーと一緒に対応を進めました。
- 29記事すべてのmeta description文案を作成（1記事ごとに110〜130字の説明文を書き起こす）
- JSON-LD構造化データのテンプレートを作成（Organization・Article・BreadcrumbListの3種）
- Jimdo管理画面での具体的な設定手順をまとめる
これらの作業を、AI経営パートナーが半日で一気に整えてくれました。
——でも、ここで問題が出てきます。
実際にJimdo管理画面を開いて、29記事すべてに設定を入れていく作業。
これは、私がやると半日〜1日まるごと潰れる作業です。
1人社長で、他にやることが山積みの中、ここに時間を使うのは現実的じゃない。そこで、もう一人の手を借りることにしました。
5. 「Web専門家ではないが、優秀なアシスタント」への引き継ぎ
私の会社には、業務委託でお願いしているアシスタントがいます。事務作業全般を頼んでいる、とても優秀な方です。
ただし、Web関連やSEOの専門家ではありません。「meta description」と聞いて、何のことか即座に答えられる方ではない。
それでもこの作業を頼むには、専門知識がなくても迷わず作業できる指示書が必要でした。
ここで、AI経営パートナーにもう一仕事してもらいました。アシスタント向けの指示書3本を作成してもらったのです。
- 既存ブログ29記事のmeta description設定（コピペで設定できる文面リスト付き）
- JSON-LDの構造化データ設定（テンプレ + Jimdoでの埋め込み方法を図解風に解説）
- noteからJimdoへのリライト版4本の転載作業（noteで先行公開した記事をHPブログに転載）
AI経営パートナーが作った指示書は、
- 各作業の所要時間目安
- 難易度（星の数）
- 「分からなくなったらここで佐野に確認」のポイント
- 完了後のチェックリスト
まで含まれた、業務マニュアル並みの完成度でした。HTML形式で、見出し・コードブロック・注意ボックスが色分けされていて、Web専門知識がなくても1行ずつ追いかければ作業が進む構造になっている。
これを、アシスタントに送ってみました。返事はシンプルでした。
「内容、理解しました。明日から着手します」
正直、私の方が驚きました。SEOの専門用語が並ぶ指示書を、たった一往復で理解してくれたのです。
数日後には、29記事のmeta description設定が完了し、JSON-LDも順次入っていきました。
1年間"空"だった検索結果の説明欄が、ようやく自社の言葉で埋まり始めました。
6. 学び1：AIで「作る」のと「届ける」は、別の仕事
第1弾のときに書いたのは、「AIで作ったシステムは、AIに監査させる」という学びでした。今回は、その続きです。
AIで「作ったもの」を、「届ける」工程は、また別の仕事です。
業務システムも、ブログ記事も、作っただけでは届きません。
- システムなら → デプロイ・運用監視・利用者の手元に届く設計
- 記事なら → SEO設定・構造化データ・SNS派生・検索結果での見え方
どちらも「作る」のあとに、「届ける」がある。AI経営パートナーは作るのも速いですが、届ける工程まで設計してくれます。
私のような1人社長は、つい「作る」で満足してしまう。
AI経営パートナーがいなかったら、たぶんこの「届ける」工程は、また1年放置されていたと思います。
7. 学び2：AI経営パートナー × 経営者 × アシスタント の三角形
もう一つの学びは、今回の対応で見えてきた役割分担の構造です。
- AI経営パートナーは、診断・設計・指示書の作成までを引き受ける
- 経営者（私）は、何を優先するかを判断し、ゴーサインを出す
- アシスタントは、AI経営パートナーの作った指示書を実行する
この三角形が、今回うまく機能しました。
特に大きかったのが、「AI経営パートナーが指示書を書く」というアウトプットです。
私が手元で作業すれば1日かかる作業を、アシスタントに「ちゃんと伝わる形」で言語化する——これって、実は人間の経営者が一番時間を取られるところです。
「言葉にする時間がないから、結局自分でやってしまう」という、1人社長あるあるです。
AI経営パートナーがその「指示書を書く」工程を引き受けてくれると、私は「判断」だけに集中できる。
アシスタントは「専門知識なしでも正確に実行できる」状態になる。
AIは、経営者の手の代わりにもなるし、伝言の代わりにもなる。これは、1人社長＋AI＋アシスタントというチーム構成が、案外強いんじゃないかと思った瞬間でした。
8. 学び3：業務改革コンサルが、自社の発信を構造化できていなかった
最後に、いちばん皮肉な学びを書きます。
私は普段、「業務を構造化して、判断点を見える化しましょう」とコンサルでお話ししています。
その私が、自社のホームページについては、ブログを書く → 保存ボタンを押す——という、構造化のかけらもないフローで1年運用していました。
29記事すべての「ページの説明」「投稿日」「著者」「カテゴリ」「パンくず」——これらのメタ情報を構造化していなかった。お客さんには「業務の情報構造を整えましょう」と言っているのに、自分の発信の情報構造は、何も整えていなかったわけです。
ここに気づけたのは、AI経営パートナーに「自社のHPを、外部の検索エンジン視点で点検する」という、いつもと違う視点をもらえたからでした。
「自分の業務を、外側から見る」のは、本当に難しい。
これは、お客さんの業務棚卸を進めるときに、私がコンサルとしてやっている「外側からの視点を提供する」役割そのものです。
コンサルが必要な理由を、自分自身が体感した出来事でもありました。
まとめ：「AIで作る」「AIで点検する」「AIで届ける設計をする」
第1弾の最後に、こう書きました。
「AIで作る」と「AIで点検する」は、セットで運用すべき——というのが、今日の一番の学びでした。
第2弾の今日、もう一つ追加します。
「AIで作る」と「AIで点検する」のあとに、「AIで届ける設計をする」が要る。
そして、その設計を専門家じゃない人でも実行できる指示書に落とすのも、AIの得意分野です。
業務改革コンサルとしても、これは応用が効く話だと思っています。
「DXを進めたいけれど、社内にIT専門家がいない」という中小企業は、本当に多い。
そういう会社こそ、AIに指示書を書かせて、現場の方が実行する——という構造が刺さるはずです。
次は、自社の発信動線を点検したいと思っています。「noteは書いた」「YouTubeは撮った」で満足する前に、それらがちゃんと「届いて」いるかを、AI経営パートナーにまた診てもらうつもりです。
JOAコンサルティングのご案内
株式会社ファインドルートでは、中小企業の業務改革・DX推進をご支援しています。「DXを進めたいけれど、社内にIT専門家がいない」という会社にこそ、AIに指示書を作らせて現場が実行する構造が効きます。
- 業務棚卸を通じた判断ボトルネックの可視化
- 判断志向アーキテクチャ（JOA）に基づく業務フロー再設計
- 生成AI・ノーコードツールを使った業務システム実装支援
- 1人社長・小規模企業向けのAI活用個別相談
📩 お問い合わせフォーム
📺 YouTube「判断の進化チャンネル」（隔週更新）
1人社長×AI CEOシリーズについて
1人社長の会社で、AIを経営パートナーに迎えた実体験を発信しているシリーズです。失敗談も、思想的な議論も、経営判断のリアルも、全部含めて率直に書いていきます。同じように1人または少人数で会社を運営している経営者の方の参考になれば幸いです。
本記事は、代表 佐野尚人のnote「1人社長×AI CEO」マガジンで先行公開した記事を、HP用に加筆・再構成したものです。
note原典版はこちら：[自社ブログ29記事のmeta descriptionが全部"空"だった話 — AI CEOにSEO診断された日]