プログラマティックSEOに最適化されたウェブサイトの作り方

プログラマティックSEOとは（何でなく何であるか）

プログラマティックSEO（略して pSEO）は、繰り返し使えるテンプレートから多数の検索最適化ページを作る手法で、構造化データによって動きます。すべてのページを一から書く代わりに、次を組み合わせるシステムを作ります：

• ページテンプレート（レイアウトと文の「スロット」）
• コンテンツデータベース（そのスロットを埋める事実）
• 公開ワークフロー（ページがどのように生成・更新されるか）

目的はGoogleを“騙す”ことではなく、手作業ではカバーしきれない多数の関連検索に対して役立つページを公開することです。

pSEOが提供するもの

うまく設計されたpSEOは、データと構造が一貫しているため、そのクエリ向けに作られたと感じられるページを生みます。

例としてはディレクトリ、ロケーションページ、製品やツールの比較、“代替”ページ、プラン別の価格ページ、あるいは同じ概念を多カテゴリで説明するページなどがあります。

pSEOがやってはいけないこと

pSEOは文章のスピンやほぼ同一ページの量産、価値の低いURLの氾濫ではありません。各ページで変わるのが見出しにキーワードを差し替えるだけなら、それは薄いコンテンツの量産であり、通常は失敗します。

pSEOが適している場合（とそうでない場合）

pSEOは、繰り返し現れる検索意図と信頼できるデータ（機能、仕様、ロケーション、レビュー、カテゴリ、在庫状況など）があるときに有効です。一方、各ページに深い独自リポートや専門家の意見、重たい物語性が必要な場合は不向きです。

期待値を合わせる：数ではなく品質をスケールする

勝ち筋は、有用性を落とさずに何百・何千ページも公開できるシステムを作ることです。そのためには最初から「テンプレート」「データ」「公開」「品質保証（QA）」の4つを計画に入れて、各ページが正確で十分にユニークでインデックスに値する状態を維持できるようにします。

目標、オーディエンス、明確なトピッククラスターから始める

プログラマティックSEOは具体的なビジネス成果に結びついている場合にのみ機能します。ページやテンプレート、スケールを考える前に、あなたが達成したいことと対象ユーザーを決めてください。

主要ゴールを定義する

エンドツーエンドで測定できる主要なコンバージョンゴールを一つ選びます。一般的な選択肢はサインアップ、デモ申し込み、購入、リードフォームの送信などです。明確なゴールがあれば、どのページに最も注力するか、どのCTAを使うか、どの指標が重要かを優先できます。

複数のゴールがある場合は、最初のローンチでは“主要”なものを一つ決め、結果が出たら拡張していきます。

質問ベースでオーディエンスを特定する

ターゲットオーディエンスを平易な言葉で列挙し（例：「独立デザイナー」「従業員50–200人の人事担当」「太陽光設置業者を比較する住宅所有者」など）、彼らが検索する質問を書き出します。特に比較、評価、「〜に最適」といった意図がある質問に注目してください。

有用なプロンプト：顧客が「解決策を選ぼうとしている直前」にGoogleに打ち込むであろう語句は何か？

成功をどう見るかを決める

ランクだけで満足しないでください。ファネル全体にわたる少数の指標で成功を定義します：

• 可視性：コアクエリでの順位
• 需要：クリック数と質の高い訪問
• ビジネスインパクト：コンバージョン（可能ならコンバージョン率）

これにより、流入はあるがコンバージョンしないページを量産するリスクを減らせます。

1つのトピッククラスターから始める

プロダクトと密接に関連し、ページを多数作るだけの変化量がある、1つの主要トピッククラスターを選びます。良いクラスターは具体的で再現可能、かつ有用であり、新しいページごとに実際の疑問に答える必要があります。

検索意図に合うページタイプを選ぶ

pSEOは「ページタイプ」を標準化すると最も効果が出ます—多くのバリエーション（都市、ツール、カテゴリ、機能）に対して同じ種類の疑問に答える繰り返し可能なフォーマットです。肝心なのは、そのフォーマットが検索者の目的に合っていることです。

一般的なpSEOページタイプ（と使える場面）

• ロケーションページ：「[都市]でのサービス」「[カテゴリ]のベスト in [都市]」「近くの〜」バリエーション。
• 比較ページ：「[ツールA] vs [ツールB]」「[製品]の代替」「特定のユースケースに合うベスト」等。
• ディレクトリ／一覧：「トップ[カテゴリ]」「[カテゴリ]ディレクトリ」「[サービス]を提供する企業一覧」等。
• ユースケースページ：「[ツール] for [職種]」「[製品] for [業界]」「[ツール]でどうやって[タスク]をするか」等。

これらはスケールし得ますが、意図が明確でページが実際に助けになるときに限ります。

インフォメーショナル vs トランザクショナル：意図にマップする

検索意図は混合することが多いですが、グループ化は可能です：

• 情報取得型（学ぶ・理解する）：「とは何か」「どうやるか」「例」など。ユースケースページや一部のディレクトリがこれに当たります。
• 行動志向（選ぶ・買う）：「ベスト」「価格」「レビュー」「〜対〜」「代替」など。比較ページ、ランキング系ディレクトリ、ロケーションページ（連絡・予約・購入につながる）に適します。

チェック：クエリが意思決定を示すなら、テンプレートは意思決定を助ける（利点／欠点、フィルタ、価格帯、CTA）ように設計してください。

テンプレートの外での独自価値を定義する

テンプレートは枠組みにすぎません。価値はページごとに何が変わるか、手作業で集めるのが難しい情報にあります。例：

• 実際の属性や仕様（機能、カテゴリ、可用性、サービスカバレッジ）
• 価格帯やプランの要約（正確である場合）
• 比較のための横並び差分
• クエリに紐づいた「〜に最適」ガイダンス
• 更新日時、新規エントリ、最近検証されたデータなどの新鮮さシグナル

もし変数を全部外してもページが「意味をなす」なら、そのページはおそらく一般的すぎます。

MVPとして1つのページタイプを選ぶ

まずは実行できる1つのページタイプから始め、全員が同じものを作れるように単一ページでドキュメント化します：

• ターゲットクエリパターン（例：「X vs Y」「X in City」）
• 想定ユーザーアクション（サブスクライブ、デモ申し込み、問い合わせ、候補リスト化）
• 必須データフィールド（必須とあれば尚良し）
• テンプレートセクション（何がどの順で出るか）
• 生成しないルール（いつページを作らないか）

このMVPがブループリントになり、スケール時のミスを防ぎます。

パターン重視のキーワードリサーチ（単一キーワードではなく）

pSEOは「完璧なキーワード」を探すのではなく、1つのページタイプで対応できる繰り返しのキーワードパターンを見つけることが肝心です。目的は量ではなく、実際に有用なページを作れる組み合わせを見つけることです。

1) ヘッドタームと“使える”修飾語を見つける

まずはサイトが提供するものを表す少数のヘッドターム（製品、サービス、ツール、カテゴリ）を決め、次に人々が比較・評価・ローカル検索で自然に付ける修飾語を集めます。

修飾語ファミリーの例：

• 場所: in {city}, near {neighborhood}, {state}
• ユースケース: for {job}, for {industry}, for {goal}
• 比較: vs {alternative}, alternatives to {brand}
• 選択: best {head term} for {modifier}, top-rated, cheapest

「使える」とは、修飾語がページに意味のある変化をもたらすことです。修飾語がほとんど答えを変えないなら、その修飾語で作るページは反復的に感じられます。

2) キーワードをリストではなくパターンでグルーピングする

何千もの個別キーワードを追う代わりに、検証可能なテンプレートへマッピングします：

• “X in Y”（例：Austinの会計士）
• “X vs Z”（例：Mailchimp vs Klaviyo）
• “Best X for Y”（例：扁平足に最適なランニングシューズ）

各パターンについて、ページが提供できるユニーク情報を一文で説明できるかを確認してください。説明できなければ、そのパターンは弱い可能性があります。

3) 薄く/反復的なページを生むパターンを除外する

よくある危険信号：

• Yに実際のインベントリやデータがない（空リストを出すだけになる）
• 同じアイテムがほぼすべてのバリアントで表示される
• データベースが価格、可用性、スペック、レビューなどの差を支えられない

簡易テスト：パターンから10個のキーワードバリアントを選び、各ページで何が変わるかをアウトラインする。アウトラインが90%同じならそのパターンは除外します。

4) フィルタリング後にスケールを見積もる

品質チェック後に見積もります：

ページ数 = 有効なヘッドターム × 有効な修飾語 × 許容される組み合わせ

保守的に見積もること。200の高意図ページを公開して拡張する方が、20,000のほぼ重複ページを後で整理するよりずっとマシです。

数千ページを支えるコンテンツデータベースを構築する

pSEOは各ページが実際の構造化情報に支えられているときにのみ機能します。テンプレートやコピーを書く前に、サイトを“パブリッシングシステム”として扱い、データベースを真のソースオブトゥルースにしてください。

まずデータソースを定義する

ページに表示する事実が既にあるシステムを列挙し、何を取り込み標準化するかを決めます。一般的なソースは製品カタログ、マーケットプレイスリスティング、ロケーションレコード、レビュー、価格表、技術仕様などです。

目標は一貫性です：例えば「画面サイズ」が10,000ページに出るなら、それは "15-inch" や "15インチ" の混在ではなく、1つのフィールドで1つのフォーマットに統一します。

ページタイプごとの必須フィールドを決める

テンプレート駆動ページは有用であるための最低データセットが必要です。ページが公開（またはインデックス可能）になる前の必須ルールを作成します：

• タイトルフィールド（IDではなく人間が読む文）
• 短い説明またはサマリー
• 比較で重要なコア属性
• 少なくとも1つの差別化要素（価格、可用性、評価、サービスエリア等）

必須フィールドが欠ける場合はフォールバック体験を生成するか、ページ自体を作らないでください。

新鮮さと更新フローを計画する

ソースからページへの更新がどう移るか（定期同期、リアルタイム、ハイブリッド）を決め、データが変わったときのURLや本文の扱い（価格更新、中止、カテゴリ名変更）を定義しておきます。

ガバナンスを追加する（品質がスケールするように）

オーナーを割り当て、エラーが報告されたときに誰が修正するか明確にします。検証ルール、エラキュー、データオーナーの明確化といったシンプルなワークフローが、数千ページにわたる小さな問題の拡大を防ぎます。

有用であるテンプレートを設計する（ただスケールするだけでなく）

テンプレートは空の殻ではなく、優れたランディングページのように振る舞うべきです。訪問者が数秒で答え（と次のステップ）を理解できることが目標です。

明確なページ階層から始める

予測可能なセクションを持つ再利用可能なテンプレートを作ります。一般的で効果的な流れの例：

• クエリを反映する具体的なH1（「Best X for Y」「X in City」「X vs Y」など）
• 結論を先に示す短いサマリー
• 主なデータ駆動モジュール（テーブル、リスト、ディレクトリカード）
• 補助的なコンテキストと意思決定支援

この構造はページをスキャンしやすくし、“テンプレート駆動”でありながらジェネリックに感じさせないために有効です。

固定、データ駆動、編集コンテンツを分ける

何が全ページ共通（固定）、何がデータベースから引くもの（データ駆動）、何が人が書くもの（編集）かを定義します。

例：

• 固定: セクション見出し、UIコンポーネント、免責、使い方コピー
• データ駆動: 価格、仕様、ロケーション、可用性、評価、機能フラグ
• 編集: 「選び方」ガイド、エッジケース、注意点、推奨

この組み合わせにより、ユニークさと有用性を計画する必要が生じ、単にスケールするだけのページ作りを防げます。

実際の意思決定に合うコンポーネントを加える

役立つテンプレートには短いFAQ、クイック比較（「主要な代替」）、長所／短所、明確な次のステップ（フィルタ、関連ページ、主要CTA）などが含まれることが多いです。各コンポーネントは単に語数を増やすためではなく、実際の後続質問に答えるべきです。

迷ったら、対象クエリで上位表示しているページを見て意図に合わせ、さらに行動しやすくしてください。

大規模でのURL構造、メタデータ、構造化データ

テンプレート駆動ページを何百・何千も公開すると、小さな不整合が大きな問題になります。明確なURLルール、メタデータのガードレール、構造化データ標準を設けることで検索エンジンがページを理解しやすくなり、運用負担も減ります。

URLルール：読みやすく、一貫し、安定的に

長年保てるURLパターンを選びます。日付やキャンペーンコード、内部IDのような一時的な情報をURLに焼き付けないでください。

良い目安：フォルダは一概念、スラッグは一エンティティ。

• 一貫した階層: /category/entity（または /use-case/location）
• 人間が読めるスラッグ: データベースキーではなく言葉を使う
• 安定したフォーマット: ハイフン、大小文字、複数形、末尾スラッシュを早めに決める

例：

• /templates/invoice/contractor
• /pricing/seo-tools/ahrefs-alternative
• /cities/italy/rome

後でURLを変える必要がある場合はリダイレクトを慎重に計画しますが、最善はそもそも変更を避けることです。

大規模メタデータ（ガードレール付き）

タイトルタグ、メタディスクリプション、見出しはテンプレート化しますが、ジャンク出力を防ぐルールを設けます。

有効なガードレール例：

• 文字数上限（例：妥当な文字数でタイトルを切る）
• フォールバックロジック（フィールド欠損時に "undefined" を出さない）
• ユニーク性チェック（同一タイトル／説明の多発を防ぐ）

例：

• タイトル: “{Primary Term} Templates for {Audience} | {Brand}”
• H1: “{Primary Term} templates for {Audience}”

変数が変わっても自然に聞こえるテンプレートを作り、変数の正規化（"USA" vs "United States" など）をデータ層で行ってください。

ページに合う構造化データ

スキーマは薄いコンテンツを改善しませんが、理解を助けリッチリザルトの対象になり得ます。pSEOページでよく使うもの：

• Organization（サイト全体）
• Product（価格や在庫が正確にある製品）
• FAQ（実際にページ上にあるFAQのみ）
• BreadcrumbList（大規模サイトでは特に有用）

テンプレート全体でスキーマを一貫させ、定期的に検証してください。

重複を避ける：canonicalとパラメータ処理

テンプレート駆動サイトはフィルタやソート、トラッキングパラメータによってほぼ重複を生みやすいです。

• canonicalタグでバリアントを望ましいURLに指し示す
• アナリティクス／トラッキングパラメータがインデックス対象のURLを増やさないよう設定する
• フィルタが必須なら、どの組合せをインデックス可能にするか決め、残りはブロックまたは noindex にする

ここでの規律がサイトが自分自身と競合するのを防ぎます。

発見性のためのサイトアーキテクチャと内部リンク

pSEOは検索エンジンと人がページの関連性を理解できるときに成功します。最も簡単な方法は図書館のように整理すること：いくつかの明確な“通路”（ハブ）を作り、その下により具体的なページを配置します。

人が実際にブラウズしたくなるハブを作る

カテゴリ／サブカテゴリのハブページは、コレクションを要約しユーザーが選択肢を絞れるようにするべきです。良いハブは単なるリストではなく、そのカテゴリが何か、誰向けかを説明し、フィルタや「人気の選択」を提供します。

例えばハブは次にリンクすることができます：

• トップのサブカテゴリ（ユースケース、価格帯、ロケーション別など）
• カテゴリ内の代表的なアイテム（「このカテゴリで人気」）
• 関連する役立つガイド（例：/blog/how-to-choose-x）

パンくずと文脈リンクで関係性を強化する

パンくず（Home → Category → Subcategory → Item）は階層を明示し、何千ページにもわたる一貫した内部リンクを生みます。ユーザーが一段上にジャンプしやすくなる利点もあります。

文脈リンクはその補完で、コンテンツ内に自然に現れる助けになるリンクです。詳細ページでは「類似の代替」「近隣のロケーション」「よく比較される相手」などが該当します。これらはロングテールページ同士をホームページを介さずに繋げられるので特に有用です。

スケールしても混乱しないリンクルールを定義する

手作業でリンクを選ぶのではなく、システムがどこでも適用できる明確なルールを作ります：

• 共有属性（タイプ、機能、価格帯）に基づく「上位の関連アイテム」
• 定義した半径内の「近隣ロケーション」
• 同じ意図だが異なるブランドの「類似の代替」

制限を保ってください。リンクスパムにならないよう、決定やナビゲーションに役立たないリンクの塊は避けます。

メンタルモデルとしては：各ページに「上へ」（パンくず）、「横へ」（関連ページ）、「前へ」（サブカテゴリや比較といった次の最適な一歩）があるべきです。

プログラム的サイトのためのテクニカルSEO必須事項

pSEOは単純な理由で失敗します：検索エンジンがあなたのページを安定してクロール、レンダー、理解できない場合です。スケール前にテンプレート駆動ページが検索エンジンにとって「扱いやすい」状態であることを確認してください。

インデックス可否：クロール＆インデックスチェックリスト

まずページがランキングに値するかどうかの基本を抑えます。

• robots.txt：管理領域、フィルタ、無限ページ（内部検索結果など）をブロック。ただしテンプレートURLや重要なアセット（CSS/JS）を誤ってブロックしない。
• XMLサイトマップ：動的に生成し分割（例：ファイルあたり50k URL）。正規のインデックス可能URLのみを含める。
• 正規化（canonicalization）：パラメータやソート、近似重複がある場合は各ページが推奨URLを <link rel="canonical"> のように宣言する。
• メタロボット／HTTPヘッダ：低価値ページには noindex,follow を使う。

パフォーマンス：スケール時の速度基本

小さなパフォーマンス問題は何千ページと掛け合わされると大問題になります。

• テンプレートページに対してキャッシュ（CDN + サーバーキャッシュ）を有効にする
• 適切なサイズのレスポンシブ画像を配信する（巨大な原寸ファイルを送らない）
• 画面下部の画像や非クリティカルウィジェットは**遅延読込（lazy loading）**を使う

モバイルの使いやすさとアクセシビリティ

ほとんどの評価はモバイルファーストです。テンプレートが小画面で壊れないか、ボタンがタップ可能か、テキストが読みやすいかを確認してください。セマンティックな見出し、説明的なaltテキスト、明確なフォーカス状態など基本的なアクセシビリティも加えてください。

レンダリング：クロール時のサプライズを避ける

重要なコンテンツがブラウザ側で生成されると、クローラは空または部分的なページを見てしまうことがあります。

• テンプレートコンテンツは**サーバーサイドレンダリング（SSR）**かプリレンダを優先する
• クライアントサイドレンダリングを使う場合は、重要なコンテンツとリンクが初期HTMLに存在することを確認し、GoogleのURL検査ツールでテストする

実装ノート: pSEOサイトをテンプレート＋データベース＋公開＋SSRでプロダクト化して構築する場合、Koder.ai のようなプラットフォームはスキャフォールディングを早め、Reactベースのテンプレートのプロトタイプ作成、構造化データ（例：PostgreSQL）接続、公開ワークフローの反復を容易にします。その後、SSR・正規化・サイトマップ・内部リンクルールなどSEO重要部分をコントロールしながらソースコードをエクスポートできます。

品質管理：薄い・重複・壊れたページを防ぐ

pSEOは一貫性にかかっています。テンプレート駆動の数百・数千ページを公開すると、小さなデータ不備がサイト全体の問題になります：空フィールドが“薄い”ページを生み、繰り返し文が重複を生み、1つの誤ったURLパターンが404の洪水を引き起こすことがあります。

「公開準備完了」チェックを定義する

ページが公開される前に、データベースとレンダリング済みページに対して自動検証ルールを実行してください。これはプレフライトチェックのように扱います。

• 欠損フィールド: 価格、ロケーション、仕様、説明など必須属性が空なら公開をブロック
• 重複テキスト: テンプレート化されたセクションが類似度しきい値を超える場合にフラグを立てる
• 壊れたリンク: 内部リンクが200を返すか、外部リンクがタイムアウトしないか検証

コンテンツ品質ルール（ページあたり最低ユニーク価値）を追加する

テンプレートは構造をスケールさせますが、データが実質を供給しなければなりません。明確なルール例：

• 各ページはテンプレート以外で少なくともXのユニークな詳細（例：5–10属性や比較項目）を含むこと
• 各ページはデータ由来のユニークな段落を1つ含むこと（単にキーワードを差し替えた一般文ではない）
• ルールを満たせないページは公開しないかカテゴリページへリダイレクト、またはnoindexにする

各バッチからサンプルをレビューする

自動化でも例外は出ます。各公開バッチごとに小さなサンプル（例：20–50ページ）を手動でチェックし、可読性、繰り返しセクション、不適切な置換、空状態UIに注意してください。

スパイクや回帰を監視する

次の急増があったらアラートを出す設定をしてください：

• 404エラーの急増（新しいURLバグ、削除されたアイテム）
• 重複タイトル／メタディスクリプションの増加
• 薄いページの増加（低ワードカウント、必須セクションの欠損）

品質管理は一度きりのゲートではなく、データベースとテンプレートが進化する中でpSEO成果を守る継続的なシステムです。

インデックス戦略：安全に展開し、何をインデックスさせるかを制御する

pSEOは検索エンジンが理解するより速くページを生成できます。賢いインデックス戦略は弱いページでインデックスを埋めないようにし、優れたページが早く発見されるようにします。

小さく始めて価値を証明し、拡張する

まずはコントロールされたバッチでローンチします（例：テンプレートごとに50–200ページ）。インプレッション、クリック、クロール統計、品質シグナル（エンゲージメント、コンバージョン、サポート件数）を監視してください。テンプレートが有用であると確認できたら波を拡大します。

noindex を安全弁として使う

すべての生成ページがローンチ当日にインデックス化されるべきではありません。レビューや価格、画像、比較対象がないなど不完全・低情報のページには noindex を適用します。ユーザー向けにアクセスは可能にしておき、検索エンジンには品質基準を満たすまでインデックスを要請しない、という運用が有効です。

実用ルール：カテゴリページより良く答えられないページは当面インデックスさせない。

セクション別にサイトマップを提出する（かつ正確に保つ）

ページタイプやディレクトリごとにXMLサイトマップを分けます（例：/cities/, /alternatives/, /integrations/）。これにより：

• テンプレートごとのインデックス状況が追跡しやすくなる
• 特定セクションを安全にローンチ／一時停止できる
• エンティティ変更に合わせてサイトマップを更新しやすくなる

サイトマップには正規でインデックス可能なURLのみを含めてください。

変動に備えたリダイレクト計画

エンティティは変わります：製品名変更、ロケーション統合、リスティング削除。リダイレクトマップを維持してURL変更が404やリンク資産の損失を生まないようにします。エンティティ削除時はホームにまとめるのではなく、最も関連性の高いページ（親カテゴリ、代替エンティティ、検索結果ページ）へリダイレクトしてください。

pSEOシステムの計測、反復、保守

pSEOは一度作って終わりではありません。システムの利点は、データやテンプレート、ルールを変更することで数千ページを書き換えずに成果を改善できる点です。

テンプレートタイプ、クラスター、意図別にパフォーマンスを追う

単に「サイト全体のトラフィック」だけを見ないでください。報告は次の切り口で分けます：

• テンプレートタイプ（例：「{service} in {city}」対比較ページ）
• トピッククラスター（同じデータベースを共有する関連ページ群）
• 検索意図（情報取得型 vs 行動志向）

こうすることで、あるテンプレートは順位が良いがコンバージョンが低い、あるクラスターは控えめなトラフィックでもコンバージョンを生んでいる、などのパターンを見つけられます。

トラフィック以外の指標も測る

トラフィックは先行指標であって目的ではありません。ビジネスインパクトとページの有用性を反映するKPIを追ってください：

• コンバージョン（サインアップ、リード、購入）
• アシストコンバージョン（他ページでの最終コンバージョン前にユーザーを導いたページ）
• エンゲージメント（スクロール深度、滞在時間、再訪）
• SERPの質（CTR、インプレッション、順位分布）

テンプレートがインプレッションは稼ぐがCTRが低い場合はタイトル／メタやページ構成を修正します。流入はあるがエンゲージメントが低い場合は期待に応えていないデータやコンテンツが欠けています。

改善のループを作る

定期的な運用サイクル（週次または隔週）で勝ち・負けをレビューし、テンプレートを調整し、データカバレッジ（属性の追加、鮮度向上）を拡張し、内部リンクルールを洗練してユーザーを次の最適ページに導きます。

保守計画を作る

現実にはデータは変わります。廃止、統合、新しいクエリパターンに対応するルールを定義してください：

• 古くなったページの自動更新ルール
• 重複ページの統合やリダイレクトルール
• 意図に合わなくなったページの廃止ルール

pSEOを一度きりのプロジェクトではなく“生きたプロダクト”として運用するなら、スナップショットやロールバックといった運用機能が安全策になります。たとえば Koder.ai を使うチームは、テンプレート変更を迅速に出しつつ問題が起きた場合に戻せるワークフローを活用することが多いです。

pSEOサイトは、測定が構造化された改善を生み続ける限り強くあり続けます。