サイト移転時のSEO：301リダイレクトで順位維持するベストプラクティス

Googleは301/302/307などのリダイレクトでリンクシグナル（評価）の引き継ぎが行われると明言しており¹、サイト移転でランキングが崩れる主因はリダイレクト方式そのものではなく、設計と運用の不備にあります。検索ドキュメントでは、サイト移転の再評価には時間がかかること、そしてクローラビリティ（クロールされやすさ）や内部リンク、サイトマップ（クローラ向けURL一覧）、hreflang（言語・地域の対応タグ）・canonical（正規URL指定）の整合性が重要であることが繰り返し示されています²。公開情報や一般的な移転事例を俯瞰すると、トラフィックの一時的な揺らぎは避けにくい一方、適切なリダイレクト設計と検証により数週間〜数カ月での回復が安定しやすい傾向が見られます。技術的負債を移転に持ち込まないこと、そして**“リダイレクトは1回で終点へ、内部も外部も一貫させる”**という原則が、結果を分けます² ³。

301リダイレクトが順位に与える影響の実像

まず神話を解いておきたいのは、301（恒久）と302（一時）のどちらが「SEOに強いか」という二択です。Googleは長らく、恒久か一時かの意図表示としての違いを説明してきましたが、リンクシグナルの伝達に関しては両者で大差がない旨を公言しています¹ ⁴。にもかかわらず順位が落ちるケースがあるのは、チェーン（多段リダイレクト）やループ、終点不一致、noindexやcanonicalの齟齬、hreflangの未更新、そして内部リンクの旧URL残存といった実装面での欠陥が原因であることが多いのです²。リダイレクトのTTFB（Time To First Byte: 最初のバイトまでの時間）が高すぎる場合もクローリング効率が落ち、再評価が遅れます⁵ ⁶。目安として、95パーセンタイルで200ms以下のリダイレクト応答を維持できるよう設計・運用すると、クロールの深度と頻度が安定しやすく、その後の順位復元もスムーズになることが期待できます⁵。

もうひとつの誤解は、サーバ設定だけ整えれば十分だという見立てです。検索エンジンはシグナルの一貫性を見ています。したがって、サイトマップは新URLのみを掲載し⁹、canonicalは終点を指し、hreflangもペアを新URLで組み直し、内部リンクはすべてリダイレクトに頼らず終点へ直結させる必要があります¹⁰。さらに、Search Consoleのアドレス変更ツールの活用や⁷、旧・新プロパティのバリデーション整備²、外部リンク先の主要な参照元の張り替え依頼⁸まで含めて整えるほど、回復の確度は高まります。こうした総合設計ができていれば、301は順位を落とすトリガーではなく、シグナルを橋渡しする堅牢なレールとして機能します。

チェーンの解消と正規化がカギになる理由

リダイレクトは1ホップで終点に到達させることが理想で、www有無、スラッシュの有無、http/https、大小文字、パラメータの順序などの正規化（表記ゆれの統一）もまとめて到達させるのが実務的です³。もし旧サイト内に複数の規則が混在していると、移転ルールと衝突して2〜3ホップのチェーンが簡単に発生します。チェーンのたびに待機とネットワーク往復が生じ、ユーザー体感とクローリングの両方が悪化します³。そこで事前にアクセスログを解析し、旧URLの正規化パターンを洗い出したうえで、終点へ一気に送る合成ルールを用意するのが安全です。加えて、旧URLを掲載した外部の主要発リンクがある場合は、張り替え依頼を出しておくとリンクエクイティ（被リンク評価）の損耗が抑えられます⁸。

ビジネス影響とリスク許容度の整合

SEOの指標は最終的には収益に接続します。移転のROIを高めるには、計画フェーズでのリスク許容度の合意が不可欠です。例えば、流入の多くを占めるコンテンツ群があるなら、その群を先に移し、長尾のテールは段階的に切り替えるといったフェーズドアプローチが有効です。完全カットオーバーは運用がシンプルですが、影響範囲が大きく、一時的なトラフィックの谷が深くなることがあります。段階移行ではオペレーションの負荷が高まる一方、学習効果を活かして後続バッチの品質を上げられます。どちらを選ぶにせよ、移転後90日間は301を維持するどころか、実務上は長期的に301を残す前提で、SLA・SLOと合わせて監視対象に組み込みます²。

移転設計のベストプラクティス：情報設計から技術設計まで

成功する移転は、URLマッピングが隅々まで行き届いています。まず、Search Consoleのインデックス対象URL、主要ランディングURL、そしてサーバアクセスログ上の高頻度URLを突き合わせ、実態ベースのURL在庫を確定します。次に、新サイトの情報設計（IA）とテンプレートを基に、正規表現だけに頼らないルールを作り、例外やヒットしないケースを早期に洗い出します。カテゴリの統廃合を伴う場合は、近似性の高いカテゴリへ送るか、同一クエリ意図を満たすガイド記事への統合を優先し、単なるトップ送り（ホームへの一律転送）を極力避けます。これはユーザーの期待一致に加えて、検索意図の継承という観点でも重要です。

サイトマップは切替当日に新URLのみを配信し、旧URLを混ぜない構成にします⁹。canonicalはテンプレート側で終点を指し示し、hreflangは各言語間で新URL同士がペアになるよう全言語で同期させます¹⁰。内部リンクは移転前にできる限り終点へ直結させ、レンダリング後に生成されるリンク（SPA: Single Page Application やインフィニティスクロールなど）も含めてDOM（HTMLの要素構造）上の href から旧URLを排除します¹⁰。レンダリングの差異がある場合は、サーバとクライアントの双方でリンクを書き換える二重防御にしておくと安全です。robots.txt（クロール制御ファイル）は旧サイトで全面Disallowにしないことがポイントで、301を見せるためにクロール通過を許し、かつnoindexは付けない構成とします²。

キャッシュとCDN（コンテンツ配信ネットワーク）の観点では、リダイレクト応答を短すぎるTTL（キャッシュ存続時間）にせず、パターンが安定しているなら数時間〜1日のedge（配信拠点）キャッシュを活かす方がレイテンシを抑えられます。逆に、移転直後は頻繁にルール修正が入りやすいので、設定変更の伝播が速いエッジ実装を選ぶメリットが出ます。KubernetesやCloudFront、Cloudflareなどのエッジで動的にマップを解決しつつ、ホットキーに対してはメモリキャッシュを併用すると、TTFBを安定させられます。

データ駆動のマッピング作成

エクセルに手でURLを並べて対処するのは、小規模のうちは機能しますが、数万URLを超えると漏れや重複が避けられません。アクセスログ、Search Consoleのクエリ・ページ、アナリティクスのランディング、そしてバックリンクの多いURLを重み付きで統合し、優先度順に移転テストを行うと、序盤の品質が目に見えて上がります。たとえば、PV上位と被リンク上位の交差集合から先にQAを行い、次にテンプレートパターン別にサンプリングして差分テストを積み上げると、網羅性と効率のバランスを取りやすいはずです。

ローンチ手順を文章で整備する

チェックリスト化は重要ですが、移転は分岐の多い作業です。要点を文として共有しておくと、現場での判断が速くなります。まず、DNSやCDNのカットオーバー前にステージングでクロールテストを実施し、HTTP 3xx・4xx・5xxの分布を確認します。ついで、旧URLの内部リンクを可能な限り終点に更新し、外部の主要リンク先に張り替え依頼を送る準備を整えます。ローンチ当日はサイトマップを終点のみで差し替え⁹、Search Consoleのアドレス変更を行い² ⁷、ログ監視とアラートを有効化します。ローンチ後は404率、リダイレクトチェーン数、TTFB、インデックスカバレッジの推移を毎日追い、1週目は高頻度でルール修正を重ねます。

実装パターン別コードと設定例

実装はインフラやフレームワークに依存します。ここでは、エッジ・Webサーバ・アプリ層での代表的な実装例を示します。いずれも完全な実装として、インポート、エラーハンドリング、ヘッダ設定を含めます。

Node.js（Express）でCSVマップを使う

import express from 'express';
import fs from 'node:fs';
import path from 'node:path';

const app = express();
const PORT = process.env.PORT || 3000;
let map = new Map();

function loadMap(file) {
  const data = fs.readFileSync(file, 'utf8');
  const lines = data.split(/\r?\n/);
  const m = new Map();
  for (const line of lines) {
    if (!line || line.startsWith('#')) continue;
    const [from, to] = line.split(',').map(s => s.trim());
    if (from && to) m.set(from, to);
  }
  return m;
}

try {
  map = loadMap(path.join(process.cwd(), 'redirects.csv'));
  console.log(`Loaded redirects: ${map.size}`);
} catch (e) {
  console.error('Failed to load redirects', e);
}

app.use((req, res, next) => {
  try {
    const url = req.originalUrl;
    const dest = map.get(url);
    if (dest) {
      res.set('Cache-Control', 'public, max-age=3600');
      res.set('Vary', 'Accept-Encoding');
      return res.redirect(301, dest);
    }
    return next();
  } catch (e) {
    console.error('Redirect middleware error', e);
    return res.status(500).send('Internal error');
  }
});

app.get('/healthz', (_req, res) => res.send('ok'));

app.listen(PORT, () => console.log(`listening on ${PORT}`));

この例ではCSVに完全一致で対応していますが、正規表現やプレフィックスベースのマップを併用すると大規模でも扱いやすくなります。ヘッダのCache-Controlを設定し、リダイレクト応答自体のキャッシュでTTFBを抑えています。

Cloudflare Workers（Hono）でエッジ実装

import { Hono } from 'hono';
import redirects from './redirects.json';

const app = new Hono();

app.all('*', (c) => {
  try {
    const url = new URL(c.req.url);
    const key = url.pathname + url.search;
    const dest = redirects[key] || redirects[url.pathname];
    if (dest) {
      return c.redirect(dest, 301);
    }
    return c.notFound();
  } catch (e) {
    console.error(e);
    return c.text('error', 500);
  }
});

export default app;

エッジでの実装は伝播が速く、カットオーバー当日の微修正に強いのが利点です。KVやR2を使えばマップのホットアップデートも可能です。

Python（Flask）でアプリ層リダイレクト

from flask import Flask, redirect, request, abort
import json

app = Flask(__name__)

try:
    with open('redirects.json', 'r') as f:
        REDIRECTS = json.load(f)
except Exception as e:
    app.logger.error('Failed to load redirect map: %s', e)
    REDIRECTS = {}

@app.before_request
def handle_redirects():
    try:
        key = request.full_path[:-1] if request.full_path.endswith('?') else request.full_path
        dest = REDIRECTS.get(key) or REDIRECTS.get(request.path)
        if dest:
            return redirect(dest, code=301)
    except Exception as e:
        app.logger.error('Redirect error: %s', e)
        abort(500)

@app.route('/healthz')
def healthz():
    return 'ok'

if __name__ == '__main__':
    app.run(port=5000)

アプリ層での実装はフレームワークのミドルウェア化が容易で、A/Bによる段階移行にも向きます。負荷や遅延を避けるため、できればエッジ・Webサーバ層に近づけておくと良いでしょう。

Go（net/http）で高性能な常駐サーバ

package main

import (
    "encoding/csv"
    "log"
    "net/http"
    "os"
)

var redirects map[string]string

func load(path string) map[string]string {
    f, err := os.Open(path)
    if err != nil { log.Fatal(err) }
    defer f.Close()
    r := csv.NewReader(f)
    m := make(map[string]string)
    for {
        rec, err := r.Read()
        if err != nil {
            break
        }
        if len(rec) >= 2 {
            m[rec[0]] = rec[1]
        }
    }
    return m
}

func handler(w http.ResponseWriter, req *http.Request) {
    key := req.URL.RequestURI()
    if to, ok := redirects[key]; ok {
        w.Header().Set("Cache-Control", "public, max-age=3600")
        http.Redirect(w, req, to, http.StatusMovedPermanently)
        return
    }
    w.WriteHeader(http.StatusNotFound)
    w.Write([]byte("not found"))
}

func main() {
    redirects = load("redirects.csv")
    http.HandleFunc("/", handler)
    log.Println("listening on :8080")
    log.Fatal(http.ListenAndServe(":8080", nil))
}

Goは単体で低レイテンシを出しやすく、巨大なマップでもメモリ常駐で高速に解決できます。ブルーグリーン（環境を二重化した切替方式）でホットスワップすると、ダウンタイムなくルール差し替えが可能です。

Next.js Middlewareでのリダイレクト

import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';
import redirects from './redirects.json';

export function middleware(req: NextRequest) {
  try {
    const url = req.nextUrl;
    const key = url.pathname + url.search;
    const dest = (redirects as Record<string, string>)[key] || (redirects as Record<string, string>)[url.pathname];
    if (dest) {
      return NextResponse.redirect(new URL(dest, url), 301);
    }
    return NextResponse.next();
  } catch (e) {
    console.error(e);
    return NextResponse.next();
  }
}

export const config = {
  matcher: ['/((?!_next|api/healthz).*)'],
};

アプリの配下で細粒度に制御したい場合、Middlewareは便利です。CDNと組み合わせる場合は、二重リダイレクトを避けるため責務分担を明確にします。

Nginxの正規化と終点直行ルール

map $request_uri $redirect_dest {
    default "";
    /old-path /new-path;
}

server {
    listen 443 ssl;

    if ($host = example.com) {
        return 301 https://www.example.com$request_uri;
    }

    if ($redirect_dest != "") {
        return 301 https://www.example.com$redirect_dest;
    }

    # ここにアプリや静的配信
}

Nginxのmapで辞書化し、www正規化と同時に終点へ直送する構成はチェーンを抑えるのに有効です。Apacheを使う場合も、mod_rewriteで同様の合成ルールにできます。

計測・検証・ロールバック：順位維持の運用設計

移転はデプロイして終わりではありません。順位維持を現実のものにするには、計測と改善のループを早く回す必要があります。KPIは、404率を0.5パーセント未満、リダイレクトチェーンの平均ホップを1.0、95パーセンタイルTTFBを200ms未満⁵、インデックス対象の新URL比率をローンチ30日で80パーセント以上、主要クエリ群の平均順位差を±1以内に収束、といった水準を「目安」として置くと評価がしやすくなります。サイトの規模や競合状況で変動はありますが、これらの指標は観察と改善の良いレバーになります。

検証はクロール、ログ、サーチコンソールの三本柱で行います。まず、ステージングでの事前クロールでルールの欠落とバグを潰し、ローンチ後は実サイトを定期クロールして終点のHTTP 200とコンテンツの一致性を確認します。ログでは3xx・4xx・5xxの分布や、リダイレクト対象のTTFB、ユーザーエージェント別の挙動を観察します。Search Consoleではインデックスカバレッジ、サイトマップの検出、リッチリザルトの状態、国際化サイトならhreflangのエラーに着目します¹⁰。これらを日次で記録し、逸脱に対しては即時にルール修正または内部リンクの張り替えを行います。

ロールバック戦略も事前に合意しておくべきです。段階移行の場合はバッチ単位で切り戻し可能な構成にし、完全カットオーバーの場合でも、DNSやCDNの設定をテンプレート化して即時に旧構成へ戻せるよう準備します。ただし、検索エンジン側の学習が進んだ後の完全ロールバックは、さらなる混乱を招く場合があります。価値の高いURL群に限定した部分的な再マップや、代替コンテンツの補強といった現実的な手当てで、ダメージを最小化するのが実務的です。

最後に、ビジネスと技術をつなぐ報告の作法です。経営サイドには、移転で見込める長期的な収益機会と短期的な変動リスクを並記し、KPIに基づく週次報告で進捗を可視化します。技術サイドには、ルール変更の差分、影響範囲、観測データを添えて意思決定の材料を提供します。意思決定は迅速であるほどダメージを抑えられるため、SLA・SLOと同列に「移転KPIのSLO」を暫定で定義しておくと、全員の足並みが揃います。あわせて、関連する基礎知識や実装の背景は、社内ドキュメントとして恒久化しておくと次の移転でもコストを圧縮できます。

まとめ：移転は“設計・実装・計測”の三位一体で守れる

順位を守る移転は、301という技術要素そのものより、シグナルの整合性と観測可能性にかかっています。設計段階でマッピングをデータ駆動で作り、実装では一発到達・終点整合・内部直結を徹底し、運用でKPIを監視して素早く手を打つ。この三拍子が揃えば、トラフィックの谷は浅く短くできます。あなたのサイトで、今すぐ整えられる要素はどこでしょうか。URL在庫の確定から始めても良いし、TTFBの短縮や内部リンクの直結を先に進めても構いません。今日の1アクションが、移転当日の安定とその後の成長を決めます。次に取り組む一手を決めたら、関係者と合意し、計測のダッシュボードを一緒に開きましょう。

参考文献

Search Engine Journal. Are 301 Redirects A Google Ranking Factor?
Google 検索セントラル. サイトの移転（URL 変更を伴う場合）: Search Console は優れたツールであり… 各プロパティのデータを個別に確認. https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes?hl=ja#:~:text=,Console%20%E3%81%AF%E5%84%AA%E3%82%8C%E3%81%9F%E3%83%84%E3%83%BC%E3%83%AB%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%A7%E3%81%82%E3%82%8A%E3%80%81%E7%89%B9%E3%81%AB%E3%82%B5%E3%82%A4%E3%83%88%E3%82%92%E7%A7%BB%E8%BB%A2%E3%81%99%E3%82%8B%E9%9A%9B%E3%81%AB%E6%B4%BB%E7%94%A8%E3%81%A7%E3%81%8D%E3%81%BE%E3%81%99%E3%80%82Search%20Console%20%E3%81%A7%E5%90%84%E3%83%97%E3%83%AD%E3%83%91%E3%83%86%E3%82%A3%E3%81%AE%E3%83%87%E3%83%BC%E3%82%BF%E3%82%92%E5%80%8B%E5%88%A5%E3%81%AB%E7%A2%BA%E8%AA%8D%E3%81%97%E3%81%BE%E3%81%99%E3%80%82%E3%82%A4%E3%83%B3%E3%83%87%E3%83%83%E3%82%AF%E3%82%B9%20%E3%82%B9%E3%83%86%E3%83%BC%E3%82%BF%E3%82%B9
Google 検索セントラル. サイトの移転（URL 変更を伴う場合）: リダイレクトチェーンは個未満（理想的には3個以下）に… 長いチェーンはレイテンシ増大. https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes?hl=ja#:~:text=,%E5%80%8B%E6%9C%AA%E6%BA%80%EF%BC%88%E7%90%86%E6%83%B3%E7%9A%84%E3%81%AB%E3%81%AF%203%20%E5%80%8B%E4%BB%A5%E4%B8%8B%EF%BC%89%E3%81%AB%E6%8A%91%E3%81%88%E3%81%A6%E3%81%8F%E3%81%A0%E3%81%95%E3%81%84%E3%80%82%E3%83%AA%E3%83%80%E3%82%A4%E3%83%AC%E3%82%AF%E3%83%88%E3%81%AE%E3%83%81%E3%82%A7%E3%83%BC%E3%83%B3%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%99%E3%82%8B%E3%81%A8%E3%80%81%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%81%AB%E3%81%A8%E3%81%A3%E3%81%A6%E3%81%AF%E3%83%AC%E3%82%A4%E3%83%86%E3%83%B3%E3%82%B7%E3%81%8C%E5%A2%97%E5%A4%A7%E3%81%97%E3%81%BE%E3%81%99%E3%80%82
SERoundtable. Google: 301 Signals Have Not Changed; It’s A Very Reliable Signal. https://www.seroundtable.com/google-301-signals-no-change-37275.html#:~:text=Gary%20Illyes%20from%20Google%20said,it%27s%20a%20very%20reliable%20signal
Search Engine Land. Page load time and crawl budget will be the most important SEO indicators in 2020. https://searchengineland.com/page-load-time-and-crawl-budget-rank-will-be-the-most-important-seo-indicators-in-2020-326847#:~:text=TTFB%20time%20below%20100ms%20is,so%20correcting%20them%20will%20improve
Managedserver.eu. Google Crawl Stats and TTFB: A Critical, Underrated Relationship. https://www.managedserver.eu/google-crawl-stats-and-ttfb-a-critical-underrated-relationship/#:~:text=receives%20the%20first%20byte%20of,the%20effectiveness%20of%20Google%27s%20crawling
Google 検索セントラル. サイトの移転（URL 変更を伴う場合）: HTTPS に移行する場合、アドレス変更ツールは不要. https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes?hl=ja#:~:text=HTTPS%20%E3%81%AB%E7%A7%BB%E8%A1%8C%E3%81%99%E3%82%8B%E5%A0%B4%E5%90%88%E3%80%81%E3%82%A2%E3%83%89%E3%83%AC%E3%82%B9%E5%A4%89%E6%9B%B4%E3%83%84%E3%83%BC%E3%83%AB%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%99%E5%BF%85%E8%A6%81%E3%81%AF%E3%81%82%E3%82%8A%E3%81%BE%E3%81%9B%E3%82%93%E3%80%82
Google 検索セントラル. サイトの移転（URL 変更を伴う場合）: 他サイト上のリンクの再クロールや再割り当てなどで新URLに転送. https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes?hl=ja#:~:text=%E3%81%AF%E5%8F%A4%E3%81%84%20URL%20%E3%82%92%E6%8C%87%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E4%BB%96%E3%81%AE%E3%82%B5%E3%82%A4%E3%83%88%E4%B8%8A%E3%81%AE%E3%83%AA%E3%83%B3%E3%82%AF%E3%81%AE%E5%86%8D%E3%82%AF%E3%83%AD%E3%83%BC%E3%83%AB%E3%82%84%E5%86%8D%E5%89%B2%E3%82%8A%E5%BD%93%E3%81%A6%E3%81%AA%E3%81%A9%E3%82%92%E8%A1%8C%E3%81%84%E3%80%81%E3%81%99%E3%81%B9%E3%81%A6%E3%81%AE%E3%82%B7%E3%82%B0%E3%83%8A%E3%83%AB%E3%82%92%E6%96%B0%E3%81%97%E3%81%84%20URL%20%E3%81%AB%E8%BB%A2%E9%80%81%E3%81%A7%E3%81%8D%E3%81%BE%E3%81%99%E3%80%82
Google 検索セントラル. サイトの移転（URL 変更を伴う場合）: サイトマップが更新されていない. https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes?hl=ja#:~:text=%E3%82%B5%E3%82%A4%E3%83%88%E3%83%9E%E3%83%83%E3%83%97%E3%81%8C%E6%9B%B4%E6%96%B0%E3%81%95%E3%82%8C%E3%81%A6%E3%81%84%E3%81%AA%E3%81%84
Google 検索セントラル. サイトの移転（URL 変更を伴う場合）: rel=canonical 自己参照と hreflang を新URLで更新・内部リンクを更新. <https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes?hl=ja#:~:text=1.%20%E7%A7%BB%E8%BB%A2%E5%85%88%E3%81%AE%E5%90%84%20URL%20%E3%81%AB%E3%80%81%E8%87%AA%E8%BA%AB%E3%82%92%E5%8F%82%E7%85%A7%E3%81%99%E3%82%8B%20%60rel%3D%20canonical%60%E3%82%A2%E3%83%8E%E3%83%86%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%9F%E5%A4%9A%E8%A8%80%E8%AA%9E%E3%81%BE%E3%81%9F%E3%81%AF%E5%A4%9A%E5%9B%BD%E7%B1%8D%E3%81%AE%E3%83%9A%E3%83%BC%E3%82%B8%E3%81%8C%E3%81%82%E3%82%8B%E5%A0%B4%E5%90%88%E3%81%AF%E3%80%81%E6%96%B0%E3%81%97%E3%81%84%20URL%20%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%99%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E3%82%A2%E3%83%8E%E3%83%86%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E6%9B%B4%E6%96%B0%E3%81%97%E3%81%BE%E3%81%99%E3%80%82