「upsertなしは200、ありは403の実測と、自」
これは、この記事を書いている2026年10月10日の朝まで、私（UMEO CREATE・伊藤）のサイトの記事に実際に入っていたメタディスクリプション（検索結果でタイトルの下に出ることがある、ページの説明文）です。「自」で終わっています。本当は「自社で踏んだ経緯、直し方2つをコードつきでまとめます。」と続くはずでした。
エラーは出ていません。警告もありません。記事は毎朝ふつうに公開され、見た目も崩れていません。それでも数えてみると、公開している72本のうち7本で、説明文の後ろが切られていました。6本は文の途中で、1本は最後の「。」だけが落ちていました。
しかも、これは2回目です。同じ不具合を8月に1本見つけて、直して、注意書きまで残していました。この記事では、メタディスクリプションの文字数の目安を一次情報で確かめたうえで、なぜ「黙って切れる」ことが起きたのか、どう見つけたか、今度はどう直したかを、実際の数字とコードつきでまとめます。自社サイトを自分で更新している方、制作会社に任せたまま中身を見ていない方に向けた記事です。
この記事の目次（8項目） 結論：メタディスクリプションの文字数に決まりはないが、切られ方は自分で決められる 何が起きていたか：設定した文と、公開された文が違っていた 8月に1本直したのに、10月に7本で再発していた 見つけ方：公開されたページのほうを数える 直し方：切るなら文末で切り、必ず知らせる 自分のサイトで確かめる4つのこと まとめ：切られること自体より、切られたと気づけないことが問題 出典（2026年10月10日時点） 結論：メタディスクリプションの文字数に決まりはないが、切られ方は自分で決められる
先に結論です。
Googleは、メタディスクリプションの長さに制限はない と明記している ただし、検索結果に出るときは画面の幅などに合わせて切り詰められる つまり「何字まで」と決めているのは、Googleではなく、サイトを作る側の仕組み であることが多い 私のサイトでは、その仕組みが118字で何も言わずに切っていた 切ること自体は悪くない。文の途中で切ること と、切ったと知らせないこと が問題だった Googleの公式ドキュメントには、次のように書かれています（出典は記事の末尾に置きました）。
メタ ディスクリプションの長さに制限はありません。ただし Google の検索結果では、スニペットは必要に応じて切り詰められます（デバイスの幅に合わせる場合など）。
解説記事では、文字数の目安がよく挙げられます。ただし、検索で上位に出る解説を読み比べると、「パソコンでおよそ100字、スマートフォンで約80字まで表示される」とするもの、60から80字とするもの、100から120字とするもの、150から160字とするものまであり、数字はそろっていません。これらはGoogleが決めた数字ではなく、それぞれの書き手が検索結果を観察して出した目安です。
もう1つ大事な点があります。同じ公式ドキュメントによると、検索結果の説明文（スニペット）は主にページの本文から自動で作られます。メタディスクリプションが使われるのは、そのほうがページを正確に説明できるとGoogleが判断した場合です。書いた文がそのまま出るとは限りません。
だからこそ、よく言われる「大事なことは前半に書く」は理にかなっています。どこで切られても意味が通るようにしておく、ということです。
雑貨店の作業机で、ノートパソコンに向かって記事を更新する担当者（画像はAI生成のイメージです） 何が起きていたか：設定した文と、公開された文が違っていた
私のサイトは、記事ごとに説明文を1つ登録しておくと、公開用のページを組み立てる自作のプログラム（以下、ビルドと呼びます）が、それをメタディスクリプションとして書き出す作りです。
そのビルドの中に、次の1行がありました。
"desc": a["lead"][:118],[:118] は「先頭から118字だけ使う」という指定です。119字目から後ろは、捨てられます。捨てたことは、どこにも表示されません。
たとえば10月7日に公開した記事では、こうなっていました。
登録した説明文（144字） ：「…upsertなしは200、ありは403の実測と、自社で踏んだ経緯、直し方2つをコードつきでまとめます。」 公開されていた説明文（118字） ：「…upsertなしは200、ありは403の実測と、自」 料理店のメニューにたとえると、紙の幅に入りきらなかった料理名を、印刷機が勝手に途中で切って刷っていたようなものです。「季節の野菜と鶏肉の炊き込みご」。店主はメニューの原稿しか見ていないので、刷り上がりが切れていることに気づきません。
さらに、同じ値は3か所で使われていました。検索エンジン向けのメタディスクリプション、SNSでリンクを貼ったときの説明に使われる og:description、そして twitter:description です。1行の切り捨てで、3か所が同時に切れていました。
一方で、ページの中には検索エンジンに記事の情報を伝える構造化データ（JSON-LD）も入れてあり、そちらには切られる前の全文が入っていました。同じページの中に、切れた説明文と切れていない説明文が並んでいた ことになります。
登録した説明文144字と、公開されていた説明文118字を並べた比較図。公開側は文の途中で終わっている 8月に1本直したのに、10月に7本で再発していた
この切り捨てに最初に気づいたのは、2026年8月12日です。そのとき118字を超えていたのは1本だけで、125字でした。私はその1本の説明文を短く書き直し、作業メモに「説明文は118字以内に収めること」と書き残しました。
それで終わりにしました。ビルドには何も手を入れていません。
2か月後の10月10日、同じ確認をやり直した結果がこうです。
公開した時期 記事の本数 118字を超えていた本数 9月26日まで 59本 0本（最大でちょうど118字） 9月27日から10月9日 13本 7本 （119字から157字） 合計 72本 7本
9月26日までの59本は、1本も超えていません。メモのルールは、しばらくは守られていました。崩れたのは最近の2週間で、13本のうち7本、半分以上です。
なぜ崩れたのか。確かめられた事実が1つあります。記事を登録するときに見る手順書の記入例が「説明文は100から120字」のままでした。ビルドの上限は118字です。手順書どおりに119字や120字で書くと、それだけで切れます。実際、7本のうち1本は119字で、最後の「。」だけが落ちていました。
ただ、それだけでは144字や157字の説明はつきません。正直なところ、残りは「注意書きは、時間がたつと読まれなくなる」というだけの話だと見ています。なお、なぜ上限が118という半端な数字なのかも、記録が残っていませんでした。120字前後という目安を意識して入れたのだろうと思いますが、いまとなっては確かめようがありません。
公開時期ごとの、説明文が118字を超えていた記事の本数。9月26日までの59本は0本、9月27日以降の13本は7本 見つけ方：公開されたページのほうを数える
今回の確認でやったことは3つです。どれも、原稿ではなく公開された実物 を見る、という点が共通しています。
1. 公開ページの説明文を取り出して、文字数と末尾を見る
1ページだけなら、ブラウザでページを開いて右クリックし、「ページのソースを表示」から description を検索すれば確かめられます。本数が多いときは、次のような短いプログラムで一覧にできます。私のMac（Python 3）で動かしたものです。
import re, urllib.request
urls = [
"https://example.com/blog/a.html",
"https://example.com/blog/b.html",
]
for url in urls:
html = urllib.request.urlopen(url).read().decode("utf-8", "ignore")
m = re.search(r'<meta name="description" content="([^"]*)"', html)
d = m.group(1) if m else ""
print(len(d), "…" + d[-12:], url)実際の出力はこうでした（URLの部分は、記事の公開日に置き換えています）。
118 …ありは403の実測と、自 （10月7日の記事）
115 …次情報つきでまとめます。 （10月9日の記事） 見るのは2点です。文字数が同じ値でそろっていないか （上限で切られているしるし）と、末尾が文の終わりになっているか です。「。」で終わっていない説明文は、ほぼ切られています。
2. 登録した文と、公開された文を比べる
原稿の文字数だけを数えても、切られたかどうかは分かりません。原稿は144字、公開は118字。この差が出て、はじめて「途中で何かが切っている」と分かります。
3. プログラムの中から「先頭の何字だけ使う」指定を探す
自分でプログラムを持っている場合は、切り捨ての指定そのものを探せます。私のビルドでは、[:数字] という書き方を検索しました。文章を切っている箇所は2つ見つかりました。今回の118字と、記事一覧のカードに出す紹介文の88字です。後者は、カードの高さをそろえるためにわざと切っている箇所なので、今回は直していません。ただ、こちらも文の途中で切れることは同じです。存在を知ったうえで残す、という扱いにしました。
WordPressなどの仕組みを使っている場合も、考え方は同じです。テーマやプラグインが、本文の先頭から決まった字数を抜き出して説明文にしていることがあります。設定画面に入れた文ではなく、公開されたページのソースを見るのが確実です。
打ち合わせの席で、手元の書類を指しながら内容を2人で確かめている様子（画像はAI生成のイメージです） 直し方：切るなら文末で切り、必ず知らせる
8月は「超えた記事を手で直す」で終わらせました。今回は、ビルドのほうを直しました。考え方は2つだけです。
切るなら、文の終わりで切る。 118字以内にある最後の「。」までを使う 切ったら、必ず知らせる。 どの記事が何字で、何字に切ったかを、ビルドのたびに表示する いま動いているコードの考え方は次のとおりです。
DESC_MAX = 118
desc = a["lead"]
if len(desc) > DESC_MAX:
if len(desc.rstrip("。")) <= DESC_MAX:
cut = desc.rstrip("。") # 句点1つぶんの超過は、句点だけ落とす
else:
cut = desc[:DESC_MAX]
cut = cut[:cut.rfind("。") + 1] or cut
over.append((a["slug"], len(desc), len(cut)))
desc = cut 直したあとのビルドは、こう表示するようになりました（記事の名前は省いています）。
[警告] 説明文が118字を超えています: （124字 → 文末で切って82字）
[警告] 説明文が118字を超えています: （144字 → 文末で切って93字）
[警告] 説明文が118字を超えています: （130字 → 文末で切って91字）
[警告] 説明文が118字を超えています: （157字 → 文末で切って114字）
[警告] 説明文が118字を超えています: （119字 → 文末で切って118字）
[警告] 説明文が118字を超えています: （124字 → 文末で切って67字）
[警告] 説明文が118字を超えています: （131字 → 文末で切って65字） 文の途中で切れていた6本は、いまは文の終わりで終わる説明文になっています。句点だけが落ちていた1本は、文としては切れていないのでそのままです。短くなった分、後半に書いていた内容は説明文から落ちました。それでも「自」で終わる文よりは、ずっとましです。そして、この警告は記事を1本公開するたびに毎回出ます。次に超えた記事を書いたとき、その場で分かります。
ここで選ばなかった方法も書いておきます。「超えていたらビルドを止める」という作りです。いちばん確実ですが、毎朝の公開が説明文1つで止まるのは、ひとりで回している私の運用には重すぎると判断しました。止めずに文末で切り、目に入る場所に警告を出す。これが今回の落としどころです。
修正前と修正後のふるまいの比較表。修正前は118字で切り、知らせない。修正後は文末で切り、ビルドのたびに警告を出す 自分のサイトで確かめる4つのこと
同じことは、どのサイトでも起こりえます。確かめる観点を4つにまとめます。
公開ページの説明文が、文の終わりで終わっているか。 原稿ではなく、ページのソースで見る 複数のページで、説明文の文字数が同じ値にそろっていないか。 そろっていたら、どこかで機械的に切られている 大事なことを前半に書いているか。 Googleの側でも画面幅に合わせて切り詰められる。前半だけで用件が伝わる文にしておく 「気をつける」を、仕組みに置き換えられないか。 注意書きは2か月で効かなくなった。数えて知らせる処理は、忘れない 4つ目が、今回いちばん身にしみた点です。同じ形の失敗は、以前書いたSupabase Storageのupsertで403｜RLSエラーの原因と直し方 にもありました。あちらは「送信成功と表示されるのに、PDFのリンクだけ消える」。こちらは「公開成功なのに、説明文の後ろだけ消える」。どちらも、失敗を知らせない作りにしたのは自分でした。
まとめ：切られること自体より、切られたと気づけないことが問題
メタディスクリプションの長さに、Googleの決めた制限はない。検索結果では画面幅などに合わせて切り詰められる 「何字まで」を決めているのは、多くの場合サイト側の仕組み。私のサイトでは118字で、何も知らせずに切っていた 8月に1本見つけて手で直し、注意書きを残した。10月に数え直すと、72本のうち7本で再発していた 見つけるには、原稿ではなく公開されたページの説明文を数える。末尾が文の終わりかを見る 直すときは、切る場所を文末にし、切ったことを毎回知らせる ホームページは、公開したあとに誰も見ていない場所から静かに傷んでいきます。説明文のように画面に出てこない部分は、とくにそうです。月に1回、公開されたページの側から数えるだけで、今回のような切れは見つけられます。
UMEO CREATEでは、ホームページの制作と、公開したあとの運用・保守を行っています。こうした「見えない部分の点検」も運用の中に入れています。料金は全て一例で、ご予算に合ったプランをご提案できます。
▼ ホームページ制作・運用についてhttps://www.umeocreate.com/web.html
出典（2026年10月10日時点）
記事の本数、説明文の文字数、切れていた文面、ビルドの表示は、私のサイト（2026年8月12日と10月10日）で確かめたものです。本文で挙げた文字数の目安（およそ100字、60から80字、100から120字、150から160字など）は各解説記事によるもので、Googleが公表している数字ではありません。
【群馬・北関東の中小企業・ひとり社長のAI導入をサポート】
UMEO CREATE（ウメオクリエイト）では、群馬県（高崎・前橋・太田・伊勢崎・吉岡町など）を中心に、中小企業や個人事業主・ひとり社長様向けの「AI導入・業務自動化・DX伴走コンサルティング」を行っています。
「自社の業務でもAIを使える？」「何から手をつければいいかわからない」「面倒な事務作業を自動化したい」といったご相談は、お気軽に公式LINEまたはWebサイトのお問い合わせフォームよりご連絡ください。
