IT技術ブログ

AIクローラーに本文は届いているか。JavaScriptを動かさずに受け取ったHTMLを、WordPress時代(Wayback Machineの保存分)と静的サイトに移した今とで測って比べた。本文の文字数、目次、公開日、著者、構造化データ

JavaScriptを動かさずに受け取ったHTMLに、本文・目次・公開日・著者・構造化データが入っているかを、WordPress時代の保存分と今のこのブログで測りました。測ったスクリプトと結果を載せます。

この記事の結論:AIのクローラーのうち、JavaScriptを実行すると公式に書いているのはGoogleだけで、OpenAI・Anthropic・Perplexityのクローラーについては、実行するかどうかが公式ページに書かれていません。そこで、JavaScriptを動かさずに受け取ったHTML(生のHTML)に何が入っているかを、このブログのWordPress時代(Wayback Machineに2026年6月12日に保存されたもの)と、Astroで書き出している今とで測りました。結果は、どちらも本文は生のHTMLに入っていました。WordPress時代のページを描画まで比べた1本では、JavaScriptで後から入っていたのは目次の中身(155字)だけでした。移行で変わったのは、目次と公開日が生のHTMLに入ったことと、HTMLの大きさが約3分の1〜4分の1になったことです。

この記事は、このブログ(やまやまブログ)を題材にした計測の記録です。WordPressからAstroとCloudflare Pagesに移した経緯は、移行の記事に書きました。ここでは、AIのクローラーの立場で「JavaScriptを動かさずに受け取ったHTMLに、本文と大事な情報が入っているか」だけを見ます。計測は2026年10月5日に、手元のMacで行いました。測るのに使ったスクリプトは全文を載せるので、自分のサイトにもそのまま流せます。

各社のクローラーがJavaScriptを実行するか、公式に書かれていること

JavaScriptを実行してページを描画すると公式に書いているのは、調べた4社のうちGoogleだけでした。2026年10月5日に各社の公式ページを確認した結果です。

クローラー JavaScriptの実行について公式に書かれていること
Googlebot(Google) ページをクロールしたあと、レンダリングのキューに入れ、ヘッドレスのChromiumで描画してJavaScriptを実行する。インデックスには描画後のHTMLを使う
GPTBot・OAI-SearchBot・ChatGPT-User(OpenAI) 記述なし
ClaudeBot・Claude-User・Claude-SearchBot(Anthropic) 記述なし
PerplexityBot・Perplexity-User(Perplexity) 記述なし

OpenAI・Anthropic・Perplexityのページには、クローラーの名前と目的、robots.txtでの扱い、IPアドレスの一覧の場所は書かれていますが、JavaScriptを実行するかどうかは書かれていません。「実行しない」とも書かれていないので、この表では「記述なし」としています。

Googleの「JavaScript SEO の基本」には、サーバー側で描画しておく(プリレンダリング)ことを勧める理由として、ユーザーとクローラーに対して速くなることと、JavaScriptを実行できないボットもあることが挙げられています。実行するかどうかが書かれていないクローラーには、生のHTMLに大事な情報を入れておくのが安全です。

何を測ったか

測ったのは、JavaScriptを動かさずに受け取ったHTMLに、次のものが入っているかと、その量です。

  • 本文の文字数(記事の本文の要素の中の文字。script・style・noscript・template・svg を除き、空白を詰めて数える)
  • title、h1、h2 の数
  • 日付(time 要素の datetime と、構造化データの datePublished)
  • 著者(構造化データの author)
  • 構造化データ(JSON-LD)の種類
  • HTMLの大きさと script タグの数

比べたのは、WordPress時代と今の両方にある記事3本です。WordPress時代のHTMLは、Wayback Machine(インターネットアーカイブ)に2026年6月12日に保存されたものを使いました。URLの時刻の後ろに id_ を付けて取ると、Wayback Machineのツールバーやリンクの書き換えが入っていない、保存したときのHTMLが返ってきました。

なお、3本とも移行の後に本文を書き直しているので、本文の文字数を移行前後で比べても意味はありません。見るのは、それぞれのHTMLの中で「生のHTMLに入っているか」「描画すると増えるか」です。

測ったスクリプト

URLかHTMLファイルを渡すと、上の項目を数えて出すNodeのスクリプトです。HTMLの読み取りには cheerio を使っています。本文の要素は、今のブログの article .prose と、WordPressのテーマ(SWELL)の .post_content を既定にしてあり、別のサイトでは2つめの引数でセレクターを渡します。

raw-check.mjsjs
// JavaScript を動かさずに受け取った HTML に、何が入っているかを数える
// 使い方: node raw-check.mjs <URL または HTMLファイル> [本文のセレクター]
// 必要なもの: Node.js 18以降、cheerio(npm i cheerio)
import { readFile } from "node:fs/promises";
import * as cheerio from "cheerio";

const [src, bodySel = "article .prose, .post_content, article, main"] = process.argv.slice(2);
const html = /^https?:\/\//.test(src)
  ? await (await fetch(src, { headers: { "user-agent": "raw-check/1.0" } })).text()
  : await readFile(src, "utf8");
const $ = cheerio.load(html);

// JSON-LD は先に取り出しておく(あとで script を消すため)
const ld = [];
$('script[type="application/ld+json"]').each((_, el) => {
  try {
    const walk = (v) => {
      if (Array.isArray(v)) return v.forEach(walk);
      if (v && typeof v === "object") { ld.push(v); Object.values(v).forEach(walk); }
    };
    walk(JSON.parse($(el).text()));
  } catch { ld.push({ "@type": "(壊れたJSON-LD)" }); }
});
const ldTypes = [...new Set(ld.map((o) => o["@type"]).flat().filter(Boolean))];
const ldArticle = ld.find((o) => /Article|BlogPosting/.test([o["@type"]].flat().join()));
const scripts = $("script").length;
const external = $("script[src]").length;

// 人が読む文字だけを数える(空白は詰める)
$("script, style, noscript, template, svg").remove();
const text = (sel) => $(sel).first().text().replace(/\s+/g, "").length;
const bodyEl = bodySel.split(",").map((s) => s.trim()).find((s) => $(s).length);

const authorLd = ldArticle?.author ? [ldArticle.author].flat().map((a) => a.name ?? a["@id"]).join(" / ") : "";
const result = {
  "HTMLのバイト数": Buffer.byteLength(html),
  "scriptタグ(うち外部)": `${scripts}(${external})`,
  "title": $("title").first().text().trim().slice(0, 40),
  "h1の数": $("h1").length,
  "h2の数": $("h2").length,
  "time要素のdatetime": [...new Set($("main time[datetime], article time[datetime]").map((_, el) => $(el).attr("datetime")).get())].slice(0, 2).join(" / ") || "なし",
  "公開日(JSON-LD)": ldArticle?.datePublished ?? "なし",
  "著者(JSON-LD)": authorLd || "なし",
  "JSON-LDの@type": ldTypes.join(", ") || "なし",
  "body全体の文字数": text("body"),
  [`本文の文字数(${bodyEl ?? "見つからず"})`]: bodyEl ? text(bodyEl) : 0,
};
for (const [k, v] of Object.entries(result)) console.log(`${k}: ${v}`);

3本について、WordPress時代の生のHTML、今の生のHTML、今のページをChromeで描画した後のHTMLの3つを、同じスクリプトで測るシェルスクリプトです。描画した後のHTMLは、Chromeのヘッドレスモードの --dump-dom で取り出しています。

measure.shsh
#!/bin/sh
# 旧WordPress(Wayback Machine の 2026-06-12 の保存分)と、いまのサイトを同じ物差しで測る
# id_ を付けると、Wayback の書き換えやツールバーの無い、保存したときの HTML が返ってくる
CHROME="/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"
while read -r ts path; do
  echo "=== $path"
  curl -sS -o wp.html "https://web.archive.org/web/${ts}id_/https://yamayamabloglink.com${path}"
  echo "--- 旧WordPress(生のHTML、保存日 ${ts})"; node raw-check.mjs wp.html
  echo "--- いま(生のHTML)"; node raw-check.mjs "https://www.yamayamabloglink.com${path}"
  "$CHROME" --headless --disable-gpu --virtual-time-budget=10000 --dump-dom "https://www.yamayamabloglink.com${path}" > rendered.html 2>/dev/null
  echo "--- いま(Chromeで描画した後)"; node raw-check.mjs rendered.html
done <<'LIST'
20260612204954 /bunkei-engineer/
20260612210620 /itgyoukai-yamateyokatta/
20260612212108 /%E3%80%90stripe%E3%80%91next-js-15%E3%81%A8prisma%E3%81%A7%E5%AE%9F%E8%A3%85%E3%81%99%E3%82%8B%E3%82%B5%E3%83%96%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%97%E3%82%B7%E3%83%A7%E3%83%B3%E6%A9%9F%E8%83%BD/
LIST

Wayback Machineに保存された日時は、CDX APIで調べました。https://web.archive.org/cdx/search/cdx?url=yamayamabloglink.com/*&output=json&from=202606&to=202610&filter=mimetype:text/html を開くと、保存されたURLと日時の一覧がJSONで返ってきます。

結果:1本目の出力の全文

1本目(文系から未経験でエンジニアに転職する流れの記事)の出力をそのまま載せます。

./measure.sh の出力(1本目、2026年10月5日)
=== /bunkei-engineer/
--- 旧WordPress(生のHTML、保存日 20260612204954)
HTMLのバイト数: 228953
scriptタグ(うち外部): 35(23)
title: 【文系】未経験でエンジニアに転職するための3つの流れ | やまやまブログ
h1の数: 1
h2の数: 4
time要素のdatetime: 2023-03-11
公開日(JSON-LD): 2023-03-02T19:55:50+0900
著者(JSON-LD): 津嘉山 洸
JSON-LDの@type: Organization, WebSite, SearchAction, WebPage, Article, ImageObject, Person, BreadcrumbList, ListItem
body全体の文字数: 3071
本文の文字数(.post_content): 2661
--- いま(生のHTML)
HTMLのバイト数: 51708
scriptタグ(うち外部): 12(3)
title: 文系・未経験からエンジニアに転職する流れ3ステップ | やまやまブログ
h1の数: 1
h2の数: 11
time要素のdatetime: 2023-03-02T19:55:50+09:00 / 2026-10-03T13:30:00+09:00
公開日(JSON-LD): 2023-03-02T19:55:50+09:00
著者(JSON-LD): 津嘉山 洸
JSON-LDの@type: BlogPosting, WebPage, ImageObject, Person, Organization, BreadcrumbList, ListItem, CollegeOrUniversity, FAQPage, Question, Answer
body全体の文字数: 5625
本文の文字数(article .prose): 3846
--- いま(Chromeで描画した後)
HTMLのバイト数: 57015
scriptタグ(うち外部): 14(5)
title: 文系・未経験からエンジニアに転職する流れ3ステップ | やまやまブログ
h1の数: 1
h2の数: 11
time要素のdatetime: 2023-03-02T19:55:50+09:00 / 2026-10-03T13:30:00+09:00
公開日(JSON-LD): 2023-03-02T19:55:50+09:00
著者(JSON-LD): 津嘉山 洸
JSON-LDの@type: BlogPosting, WebPage, ImageObject, Person, Organization, BreadcrumbList, ListItem, CollegeOrUniversity, FAQPage, Question, Answer
body全体の文字数: 5625
本文の文字数(article .prose): 3846

今のページは、生のHTMLと描画した後で、本文の文字数も、日付・著者・構造化データも同じでした。描画した後に増えているのは、HTMLの大きさと script タグの数だけです。増えた2つのタグは、広告(AdSense)のスクリプトと、Cloudflareのアクセス解析のスクリプトでした。h2の数は、記事の本文のほかに、よくある質問や関連記事の見出しも数えています。

3本まとめた結果

3本とも、傾向は同じでした。

記事 旧WordPress 生のHTML 今 生のHTML 今 描画した後
文系から未経験でエンジニアへ 228,953バイト・script 35(外部23)・本文2,661字 51,708バイト・script 12(外部3)・本文3,846字 本文3,846字(変わらず)
IT業界をやめてよかった理由 275,595バイト・script 35(外部23)・本文6,151字 74,028バイト・script 12(外部3)・本文7,310字 本文7,310字(変わらず)
Next.jsとStripeのサブスク 204,846バイト・script 33(外部22)・本文1,756字 69,782バイト・script 12(外部3)・本文5,427字 本文5,427字(変わらず)

分かったことは4つです。

  1. WordPress時代も、本文は生のHTMLに入っていた。 WordPressはサーバーでHTMLを組み立てて返すので、JavaScriptを動かさなくても本文が読めました。「WordPressだからAIに本文が届かない」ということは、このブログでは起きていませんでした
  2. WordPress時代の目次は、JavaScriptで中身を入れていた。 生のHTMLの目次は、3本とも「目次」という見出しだけで、項目は空でした(次の節)
  3. WordPress時代の画面の日付は、更新日だった。 生のHTMLの time 要素は3本とも2つあり、どちらも構造化データの dateModified と同じ日付(1つには aria-label="更新日")でした。公開日は、構造化データの datePublished にしかありませんでした。今は、公開日と更新日の両方が time 要素と構造化データの両方に入っています
  4. HTMLは約3分の1〜4分の1(2.9〜4.4分の1)になった。 WordPress時代は1ページ20万〜27万バイトで、script タグが33〜35個(外部のファイルが22〜23個)ありました。今は5万〜7万バイトで、script タグは12個(うち4つは構造化データ、外部は3個)です

著者は、どちらの時代も構造化データの author に「津嘉山 洸」が入っていました。構造化データの種類は、WordPress時代は Article と Person など、今は BlogPosting と FAQPage などです。

WordPress時代、描画して増えたのは目次だけだった(1本で確認)

WordPress時代の生のHTMLの目次は、次のように見出しだけでした。

WordPress時代の生のHTML(目次の部分、3本とも同じ形)html
<div class="p-toc -double"><span class="p-toc__ttl">目次</span></div>

1本目について、Wayback Machineの保存分をChromeで描画した後のHTMLを測ると、本文の文字数は2,661字から2,816字に増えました。増えた155字を要素ごとに比べると、すべて目次の項目(「転職する方法①IT用語について勉強する」など)でした。本文の段落や見出しで、描画して初めて現れたものはありませんでした。

WordPress時代の1本目を描画して、.post_content の直下の要素ごとに文字数を比べるsh
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --headless --disable-gpu --virtual-time-budget=15000 \
  --dump-dom "https://web.archive.org/web/20260612204954if_/https://yamayamabloglink.com/bunkei-engineer/" > wp-rendered.html
node -e '
const cheerio=require("cheerio"),fs=require("fs");
const kids=f=>{const $=cheerio.load(fs.readFileSync(f,"utf8"));$("script,style,noscript,template,svg").remove();return $(".post_content").children().map((_,e)=>({tag:e.tagName+"."+($(e).attr("class")||"").split(" ")[0],t:$(e).text().replace(/\s+/g,"")})).get();};
const a=kids("wp.html"),b=kids("wp-rendered.html");console.log(a.length,b.length);
for(let i=0;i<Math.max(a.length,b.length);i++){const x=a[i]||{},y=b[i]||{};if(x.t!==y.t)console.log(i,x.tag,(x.t||"").length,"|",y.tag,(y.t||"").length,(y.t||"").slice(0,200));}'
出力(2026年10月5日。wp.html は id_ で取った生のHTML)
55 56
3 div.p-toc 2 | div.p-toc 157 目次転職する方法①IT用語について勉強する転職する方法②プログラミングを勉強するProgateで勉強するプログラミングスクールで勉強する転職する方法③エージェントサービスに登録して、仕事を探してみる未経験のエンジニアに特化したエージェントサービスに登録するプログラミングを学んで、そのまま転職サポートを受けるまとめ
55 undefined 0 | ol.p-toc__list 155 転職する方法①IT用語について勉強する転職する方法②プログラミングを勉強するProgateで勉強するプログラミングスクールで勉強する転職する方法③エージェントサービスに登録して、仕事を探してみる未経験のエンジニアに特化したエージェントサービスに登録するプログラミングを学んで、そのまま転職サポートを受けるまとめ

クラス名に post_content を持つ要素は2つあり(本文と、p-toc post_content -modal という別の目次の枠)、この比べ方では両方の直下の要素を並べています。違いが出たのは2か所でした。本文の中の目次の枠(3番目)が「目次」の2字から157字に増え、別の目次の枠には項目の一覧(155字)が足されていました。本文の文字数を数えるスクリプトは最初の .post_content(本文)だけを数えるので、増えた155字は前者の分です。

描画した後のHTMLは、URLの時刻の後ろに if_ を付けて開いたものです。if_ で開くと、Wayback Machineが保存したJavaScriptやCSSが読み込まれ、ツールバーは付きませんでした。2本目と3本目も同じように描画しようとしましたが、Wayback Machine自身の案内のページが返ってきて、記事を描画できませんでした。そのため、描画して増えた文字数を確かめたのは1本目だけです。2本目と3本目は、生のHTMLの目次が1本目と同じく見出しだけだったことまでを確かめています。

目次は、本文の見出しを並べたものなので、目次が欠けても本文の中身は失われません。ただ、記事の構成を一目で示す情報が、JavaScriptを実行しないクローラーには届いていなかったことになります。今のブログは、目次をビルドのときにHTMLに書き出しているので、生のHTMLの段階で項目が入っています。

User-Agentを変えても、返ってくるHTMLは同じだった

サーバーやCDNの設定によっては、AIのクローラーにだけ違うHTMLや拒否の応答を返していることがあります。手元のMacから、User-Agentだけを各社のクローラーの名前に変えて、今のページを取りました。

User-Agentを変えて同じページを取るsh
for ua in \
  "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36" \
  "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.4; +https://openai.com/gptbot" \
  "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36; compatible; OAI-SearchBot/1.4; +https://openai.com/searchbot" \
  "Mozilla/5.0 (compatible; ClaudeBot)" \
  "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; PerplexityBot/1.0; +https://perplexity.ai/perplexitybot)"; do
  curl -s -A "$ua" -o page.html -w "%{http_code} %{size_download} " https://www.yamayamabloglink.com/bunkei-engineer/
  md5 -q page.html
done
出力(2026年10月5日)
200 51708 fd190228ee70c0321cb1b35b58c35066
200 51708 fd190228ee70c0321cb1b35b58c35066
200 51708 fd190228ee70c0321cb1b35b58c35066
200 51708 fd190228ee70c0321cb1b35b58c35066
200 51708 fd190228ee70c0321cb1b35b58c35066

5つとも200で、中身のハッシュも同じでした。GPTBot・OAI-SearchBot・PerplexityBotのUser-Agentは各社の公式ページに載っている文字列で、ClaudeBotは公式ページにUser-Agentの全文が見当たらなかったので、名前だけを入れています。

ただし、これは手元のIPアドレスから名乗っただけの確認です。本物のクローラーは各社のIPアドレスから来るので、CDNがIPアドレスで判断している場合は、この方法では分かりません。名乗りとIPアドレスを照らし合わせる方法は、AIクローラーの本物と偽物を見分ける記事に書きました。

自分のサイトで確かめるときの見どころ

本文が生のHTMLに入っているかは、curlで取ったHTMLに、本文の一文がそのまま入っているかを探すのが最も早い確かめ方です。そのうえで、次のものが生のHTMLにあるかを見ます。

  • 本文と見出し
  • 公開日・更新日(画面に出す日付と、構造化データの日付)
  • 著者の名前
  • 目次やタブの中身など、操作で開く部分の文字

業種によっては、もう一つ見ておきたいものがあります。結婚式場のフェアの日程や予約フォーム、ジムの料金表のように、外部のサービスから読み込んでJavaScriptで描いている部分です。こうした部分は、人がブラウザで見ると表示されていても、生のHTMLには入っていないことがあります。日程や料金をAIの答えに正しく使ってほしい場合は、その部分が生のHTMLにあるかを、このスクリプトか grep で確かめておくと安心です。

ページの作りを見直すときに、計測の設定と、検索エンジンやAI向けの基本の整備をどこまでやるかは、会社のコラム「24時間働くAIエージェントが会社を調べる時代に、ホームページで整えること」にまとめています。ビルド後のHTMLを点検する別の方法は、LLMO・AIOの点検スクリプトの記事に書きました。株式会社bundlyzeでは、ホームページを作るときに、計測の設定と、検索エンジンやAI向けの基本の整備まで一緒に進めています。

動作確認した環境

確認日は2026年10月5日です。

  • macOS 26.6.2、Node.js 22.23.2、cheerio 1.2.0
  • Google Chrome 154.0.8037.95(--headless --dump-dom)
  • curl 8.7.1
  • WordPress時代のHTMLは、Wayback Machineに2026年6月12日に保存されたもの(テーマはSWELL)
  • 今のHTMLは、公開中の www.yamayamabloglink.com(Astro 7で書き出した静的なHTML)

確かめていないこと:

  • 各社のクローラーが、このブログに来たときに実際にJavaScriptやCSSのファイルを取りに来ているか(訪問の記録から集計する予定で、この記事の時点ではまだ数えていません)
  • 本物のクローラーのIPアドレスから取ったときに、同じHTMLが返るか
  • WordPress時代の2本目と3本目を描画した後の文字数(Wayback Machineで描画できませんでした)
  • WordPress時代の、2026年6月12日より後の状態

参照した公式ドキュメント(確認日:2026年10月5日)

  • Googlebotがクロール・レンダリング・インデックスの3つの段階でJavaScriptを処理すること、ヘッドレスのChromiumで描画してJavaScriptを実行すること、JavaScriptを実行できないボットもあるのでサーバー側での描画も検討するとよいこと → Google 検索セントラル「JavaScript SEO の基本を理解する」
  • OpenAIのクローラー(OAI-SearchBot・GPTBot・ChatGPT-User・OAI-AdsBot)の目的とUser-Agent。JavaScriptの実行についての記述は無い → OpenAI「Overview of OpenAI Crawlers」
  • Anthropicのクローラー(ClaudeBot・Claude-User・Claude-SearchBot)の目的。JavaScriptの実行についての記述は無い → Anthropic「Does Anthropic crawl data from the web, and how can site owners block the crawler?」
  • Perplexityのクローラー(PerplexityBot・Perplexity-User)の目的とUser-Agent。JavaScriptの実行についての記述は無い → Perplexity「Perplexity Crawlers」
  • 保存されたURLと日時の一覧を返すCDX API → Internet Archive「Wayback CDX Server API」

よくある質問

ChatGPTやClaude、PerplexityのクローラーはJavaScriptを実行しますか?

2026年10月5日の時点で、OpenAI・Anthropic・Perplexityのクローラーについての公式ページには、JavaScriptを実行するかどうかの記述が見当たりませんでした。分からないものは、実行しない前提で、JavaScriptを動かさずに受け取ったHTMLに大事な情報を入れておくのが安全です。GoogleのGooglebotは、ページをヘッドレスのChromiumで描画してJavaScriptを実行すると、Googleが説明しています。

WordPressのサイトは、AIクローラーに本文が届いていないのですか?

このブログのWordPress時代(テーマはSWELL)のHTMLを測ったところ、本文はJavaScriptを動かさなくてもHTMLに入っていました。描画まで比べた1本では、JavaScriptで後から入っていたのは目次の中身だけでした。WordPressでも、テーマやプラグインの作りによって変わるので、自分のサイトのHTMLを測って確かめるのが確実です。

自分のサイトで、JavaScriptなしのHTMLに本文が入っているかを確かめる簡単な方法は?

curlでページを取ってきて、本文の一文がそのまま入っているかを探すのが最も簡単です。たとえば curl -s URL | grep '本文の一文' で見つかれば、JavaScriptを動かさなくても届いています。この記事のスクリプトを使うと、本文の文字数、公開日、著者、構造化データの有無まで、まとめて数えられます。

静的サイトに移せば、AI検索に出やすくなりますか?

そうとは言えません。このブログの場合、移行の前も後も本文はHTMLに入っていて、AIクローラーに届く本文の量は移行で大きく変わっていないと考えています。変わったのは、目次と公開日がHTMLに入ったことと、HTMLが軽くなったことです。AI検索に出るかどうかは、本文の中身や、クローラーを止めていないかなど、ほかの条件にもよります。