不動産ブログを始めると、早い段階で「HugoとWordPressのどちらを選ぶべきか」という問題にぶつかります。
先に結論をまとめると、選び方は次のとおりです。
- 公開記事を自動生成し、Gitで変更履歴を管理したいならHugo
- 営業担当者による更新、会員機能、予約機能が必要ならWordPress
- 迷う場合は、同じ記事を両方で1本だけ公開し、作成・修正・復旧にかかった時間を比較する
WordPressは管理画面から記事を書きやすい一方、サーバー、データベース、プラグインなどの継続的な管理が必要です。Hugoは高速で管理対象を減らしやすい反面、MarkdownやGit、コマンド操作の知識が求められます。
さらに、ブログを単なる日記ではなく、自分が作業していない時間にも検索流入を集め、問い合わせ・資料請求・商品購入につなげる自動化資産として育てるなら、記事の書きやすさだけでは判断できません。
この記事では、不動産ブログ運営の実務に絞り、次の点を比較します。
- 物件解説や市況記事の自動投稿に向いているのはどちらか
- 更新、障害、セキュリティ対応に人間の時間を取られにくいのはどちらか
- 問い合わせや会員機能まで含めると、どこでWordPressが有利になるか
- AI記事を低品質な量産コンテンツにしないために何が必要か
- 自動化が収益や工数削減につながっているかをどう測るか
なお、この記事は一般的な技術情報であり、特定の不動産投資や収益を保証するものではありません。成果は検索需要、コンテンツ品質、商品設計、運用期間などによって変わります。
HugoとWordPressの全体像
Hugoは「原稿から完成ページを作る工場」
Hugoは静的サイトジェネレーターです。静的サイトジェネレーターとは、Markdown形式の原稿から、配信用のHTMLファイルを事前に作る仕組みです。
たとえば、「東京都の中古ワンルーム投資を検討するときの注意点」というMarkdown原稿を保存してHugoを実行すると、ブラウザで表示できる記事ページが生成されます。閲覧者がページを開くたびに、データベースへ問い合わせる必要はありません。
Hugo公式も、Hugoを「Go言語で作られ、速度と柔軟性を重視した静的サイトジェネレーター」と説明しています。Hugo公式ドキュメント
不動産ブログを自動化する場合、処理の流れは次のようになります。
- 公的統計や自社データを取得する
- AIが記事の下書きを作る
- 検証プログラムが数値、出典、禁止表現を確認する
- MarkdownをGitHubへ保存する
- HugoがHTMLを生成する
- Cloudflare Pagesなどが公開する
- 記事内の問い合わせ・商品導線から成果を得る
Cloudflare Pagesでは、Gitリポジトリの更新を検知してHugoをビルドし、公開できます。公式ガイドに掲載されている標準的な設定は、ビルドコマンドがhugo、公開ディレクトリがpublicです。Cloudflare Pages公式ガイド
WordPressは「ブラウザで操作できるコンテンツ管理システム」
WordPressは**CMS（コンテンツ管理システム）**です。CMSとは、記事、画像、ユーザー、コメントなどを管理画面から扱う仕組みです。
記事本文や設定は主にデータベースへ保存され、テーマとプラグインを組み合わせてページを表示します。一般的な構成では、PHPが動くサーバーとMySQLまたはMariaDBなどのデータベースを使用します。
外部プログラムから記事を投稿する場合は、WordPress REST APIを利用できます。REST APIとは、別のプログラムからHTTP通信で記事を作成・更新するための窓口です。標準の投稿エンドポイントは/wp/v2/postsです。WordPress REST API公式リファレンス
自動化の流れは次のようになります。
- データを取得する
- AIが記事を生成する
- 検証処理が内容を確認する
- REST APIでWordPressへ送信する
- WordPressが記事をデータベースへ保存する
- テーマとプラグインがページを表示する
- フォーム、会員機能、商品販売へ接続する
生成した記事を検証せず、そのままREST APIへ送る構成にはしないでください。HugoでもWordPressでも、生成と検証は別工程にする必要があります。
HugoとWordPressを不動産ブログ目線で比較
| 判断項目 | Hugo | WordPress |
|---|---|---|
| 記事の保存場所 | Markdownファイル | 主にデータベース |
| 投稿方法 | エディター、Git、生成スクリプト | 管理画面、REST API、投稿ツール |
| 表示方式 | 事前生成したHTMLを配信 | リクエスト時にPHPなどで処理 |
| 初心者の始めやすさ | Gitやコマンド操作が壁になりやすい | 管理画面から始めやすい |
| 大量記事の変更管理 | ファイル差分を確認しやすい | APIと管理画面で運用しやすい |
| 公開側のセキュリティ | 管理画面やDBを公開側に置かない構成が可能 | コア、テーマ、プラグイン、認証の管理が必要 |
| 問い合わせフォーム | 外部フォームやサーバーレス処理を組み合わせる | プラグインで導入しやすい |
| 会員・予約機能 | 外部サービスとの連携または個別開発が必要 | プラグインや専用開発の選択肢が多い |
| 障害からの復旧 | Gitの過去状態へ戻しやすい | ファイルとDBの整合したバックアップが必要 |
| 無人運用との相性 | 公開処理をコード化できれば高い | 更新監視まで自動化できる体制が必要 |
| 非エンジニアによる複数人編集 | 専用CMSを追加しないと難しい | 権限付き管理画面を利用しやすい |
| 動的な物件検索 | 外部APIや別システムが必要 | プラグインまたは専用開発で実装しやすい |
Hugoが常に優れているわけではありません。
営業担当者が管理画面から物件ページを更新する、会員限定物件を提供する、来店予約枠をリアルタイムで管理するといった用途では、WordPressのほうが短期間で実現できる可能性があります。
一方、公開記事が中心で、問い合わせ、予約、決済を外部サービスへ分離できるなら、Hugoは管理対象を減らしやすい構成です。
3分で分かる選択フロー
次の質問に上から答えてください。
- 会員ごとに表示内容を変える必要があるか
- 予約枠や物件在庫をサイト内部でリアルタイム管理するか
- 非エンジニアが頻繁にレイアウトを変更するか
- 複数の担当者が管理画面から直接記事を編集するか
1つでも「必須」があり、外部サービスへ分離できない場合は、WordPressが有力です。
すべて「不要」または「外部サービスで代替可能」で、Gitを扱える人がいる場合は、Hugoが有力です。
この図は選択基準を整理するための概念図であり、性能や収益を証明するものではありません。実際の判断では、自社の編集体制、必要機能、復旧手順まで確認してください。
本サイトのHugo運用環境で確認した実測ログ
一般論だけでは比較材料として弱いため、2026年7月22日に、本サイトの不動産ブログ環境で読み取り専用ビルドを実行しました。
実行条件は次のとおりです。
OS: Windows amd64
Hugo: v0.163.3 extended
コマンド: hugo --source .\sites\real-estate --renderToMemory --minify
投稿Markdown: 135ファイル
コンテンツ全体: 139ファイル
投稿Markdown合計: 2,526,851バイト
Hugo自身が出力した結果は次のとおりでした。
Pages: 253
Paginator pages: 95
Static files: 42
Aliases: 54
Hugo内部のTotal: 1,787ms
PowerShellによる外側の計測: 1,938.65ms
本記事では、認証情報やローカルパスが映り込む可能性を避けるため、管理画面のスクリーンショットではなく、再現に必要なコマンド、対象ファイル数、実測値を掲載しています。
この数値から確認できるのは、135本の投稿原稿を含む本サイトを、当該環境では約1.8秒でメモリ上に構築できたという事実です。
ただし、次の点には注意が必要です。
- このサイトのPC、テーマ、記事構成、キャッシュ状態で得た1回の計測である
- 同一条件で複数回測定した中央値ではない
- 同一コンテンツを使用したWordPressとの比較試験ではない
- WordPressより何倍速いかを示すベンチマークではない
- 実際の公開時間には、Gitへの送信やデプロイ処理も含まれる
検証時には、利用中のPaperModテーマから、Hugoで将来削除予定のAPIに関する警告が2件出ました。静的サイトでも保守がゼロになるわけではなく、Hugo本体やテーマを更新した後にはビルド警告を確認する必要があります。
不動産ブログを自動化する8ステップ
1. 収益までの経路を1本に絞る
最初に「誰に何を案内するか」を決めます。広告、査定依頼、管理相談、自社商品を同時に狙うと、記事内の導線が散らばります。
たとえば、次のように一文で定義します。
空室対策を検索する賃貸オーナーに記事を届け、無料チェックリストを案内し、その後に有料マニュアルを紹介する。
収益額は保証できないため、初期段階では「記事から商品ページへ移動した人数」を観測対象にします。
2. 情報源を登録する
不動産記事は、金利、税制、法令、相場など、更新される情報を扱います。国土交通省、総務省統計局、自治体、金融機関などの一次資料を優先してください。
AIに検索を丸投げするのではなく、記事ごとに次の情報を保存します。
- 参照URL
- 資料名と発行主体
- 取得日
- 対象地域
- 集計期間
- 数値の単位
- 記事内で使用した箇所
- AIが推測または補完した箇所
出典URLだけでは不十分です。数値が「いつ」「どの地域」「どの条件」を対象にしているかまで記録しないと、別地域や別年度のデータを誤って組み合わせる可能性があります。
3. HugoかWordPressを選ぶ
次の条件が多ければ、Hugoが候補です。
- 公開記事と固定ページが中心
- GitHubを利用できる
- 自動生成した記事を差分レビューしたい
- フォームや決済を外部サービスへ分離できる
- サーバー側の管理対象を抑えたい
- エラー時に公開を止める処理をコード化できる
次の条件が多ければ、WordPressが候補です。
- 営業担当者が管理画面から直接更新する
- 会員、予約、物件検索などの動的機能が必要
- 既存プラグインを活用したい
- 技術者を介さず画像やレイアウトを頻繁に変更する
- 複数人の権限を管理したい
- REST APIの認証や更新監視を管理できる
4. 記事テンプレートを作る
不動産ブログの記事を、毎回ゼロから設計してはいけません。少なくとも次の項目をテンプレート化します。
- 想定読者
- 読者が解決したい問題
- 対象地域と物件種別
- 調査日
- 一次情報
- 計算式と前提条件
- 反対意見
- 適さないケース
- 情報の有効期限
- 問い合わせまたは商品ページへの導線
「利回りが高い」と書く場合は、表面利回りか実質利回りかを明記します。
たとえば、年間家賃収入が96万円、物件価格が1,600万円なら、表面利回りは次の計算です。
96万円 ÷ 1,600万円 × 100
＝ 表面利回り6.0%
しかし、この数値には管理費、修繕積立金、固定資産税、保険料、空室損失、購入時諸費用が含まれていません。記事内で「利回り6.0%」だけを強調すると、実際の収益性より有利に見せる恐れがあります。
5. 自動生成と品質検査を分離する
記事生成AIと、記事を検査する処理を分けます。同じAIに「記事を書き、そのまま自己採点して公開する」と指示すると、生成時の思い込みを検査時にも引き継ぐ可能性があります。
検査項目には次を含めます。
- H1が1つだけ存在するか
- Markdownのリンクやコードブロックが閉じているか
- SEOキーワードが不自然に連続していないか
- 数字に出典または計算前提があるか
- 架空の実績、顧客、物件を作っていないか
- 画像が少なくとも1枚あるか
- 画像の代替テキストが内容を説明しているか
- 商品ページへのリンクが有効か
- 売買や投資の利益を断定していないか
- 類似記事との重複率が高すぎないか
- 古い制度や統計を使用していないか
- AIが推測した箇所が未確認のまま残っていないか
自動検査で合格しても、内容が正しいとは限りません。法令、税務、融資、契約条件など、誤りの影響が大きいテーマは人間の確認対象として残します。
6. 下書き公開から始める
WordPressではREST APIでdraftとして保存し、Hugoでは公開用ブランチとは別のブランチへ原稿を置きます。
最初の20～30記事程度は、次の項目を人間が確認します。
- 固有名詞
- 金額と単位
- 法令・税制の施行時期
- 引用元との不一致
- 存在しない物件や制度
- 誇大な収益表現
- CTAと記事テーマの関連性
誤りの傾向はログに残し、検出ルールへ追加します。品質が安定した後も、高リスクなテーマは自動公開の対象外にしてください。
7. 公開処理と復旧処理を自動化する
Hugoでは、GitHubへの反映をきっかけにビルドし、検査またはビルドに失敗したら公開しない設計にします。
WordPressでは、投稿APIの応答コード、投稿ID、投稿状態、公開URLを保存します。同じ記事を再送するときは、既存の投稿IDを指定して更新し、重複投稿を防ぎます。
どちらを使う場合も、次の情報を記録します。
実行日時
記事IDまたはファイル名
参照した情報源
生成AIとモデル
検査結果
公開状態
公開URL
失敗した工程
エラー内容
再実行の可否
自動化資産として運用するなら、成功時よりも失敗時の設計が重要です。途中で止まった処理を安全に再実行できるかどうかが、障害対応時間を左右します。
8. 記事と商品導線を改善する
公開本数を増やす前に、表示回数があるのにクリックされない記事を直します。
改善する順番は次のとおりです。
- タイトルが検索意図に答えているか
- 冒頭に結論があるか
- 比較表や計算例があるか
- 一次情報と調査条件が明示されているか
- CTAが記事の内容とつながっているか
- 商品ページへ移動した後の説明が一致しているか
変更前後の数値を比較できるよう、修正日と変更内容を残してください。
専門家目線のチェックポイント
SEOは表示速度だけでは決まらない
Hugoは静的HTMLを配信しやすいため、高速化に向いています。ただし、表示が速ければ必ず検索順位が上がるわけではありません。
不動産ブログでは、次の要素が記事の信頼性を左右します。
- 地域と物件種別が具体的か
- 更新日と調査条件が見えるか
- 計算方法を読者が再現できるか
- 情報源が一次資料までたどれるか
- 執筆者または運営者の経験が示されているか
- 読者の疑問に対する回答が冒頭にあるか
- 不利な条件や適さないケースも説明しているか
WordPressはプラグイン数ではなく依存関係を見る
WordPress公式は、本体を最新状態に保ち、定期的なバックアップと復旧計画を用意するよう案内しています。WordPress公式セキュリティガイド
便利なプラグインを追加するたびに、次の確認対象が増えます。
- 開発や更新が継続しているか
- WordPress本体やPHPとの互換性があるか
- 他のプラグインと競合しないか
- 脆弱性情報が出ていないか
- 表示速度へ影響していないか
- 停止した場合の代替手段があるか
フォーム、SEO、キャッシュ、バックアップなど、役割ごとに採用理由と代替手段を記録してください。
WordPressサイトのバックアップには、ファイルとデータベースの両方が必要です。公式ドキュメントでも、両者は別の場所に保存されるため、復旧には対応する組み合わせが必要だと説明されています。WordPress公式バックアップ解説
バックアップを取得するだけでは不十分です。少なくとも四半期に1回は、検証環境で復元できるかを確認してください。
Hugoでも完全放置にはできない
Hugoは公開側の攻撃面を減らしやすい反面、次の管理は残ります。
- Hugoとテーマの互換性
- ビルド警告
- 外部フォームや決済リンク
- 画像URL切れ
- GitHubやCloudflareの認証
- 自動生成AIの品質変化
- 古い不動産情報の更新
- 利用中サービスの仕様・料金変更
「人間が介在しない運用」は、監視や停止条件が実装されて初めて成立します。エラーを無視して投稿し続ける処理は、自動化ではなく障害の量産です。
図解と実行証拠の読み分け方
記事に掲載する画像は、次の2種類に分けて考えます。
概念を理解するための図
- HugoとWordPressの選択フロー
- データ取得から公開までの処理
- 品質検査の分岐
- 検索流入から商品購入までの導線
これらは仕組みを理解するための図であり、運用実績の証明ではありません。
実際に動いたことを示す証拠
- GitHubのコミットIDと時刻
- Cloudflare Pagesなどのデプロイ結果
- ビルドコマンドと終了コード
- 公開URLと公開時刻
- 品質検査の合否
- Search Consoleやアクセス解析の推移
「生成した」という説明だけより、公開時刻、コミット、公開URLが一致する実行ログのほうが、自動化の信頼性を伝えられます。
証拠画像を公開するときは、認証情報、顧客名、メールアドレス、ローカルパス、非公開URLを必ずマスキングしてください。
よくある失敗と対策
失敗1：Hugoを導入したが、本人しか更新できない
原因は、Git操作を含む投稿経路をそのまま編集者へ渡していることです。
入力フォームやヘッドレスCMSを用意し、編集者にはタイトル、本文、画像、出典だけを入力してもらいます。Gitへの保存とビルドは裏側で処理します。
ただし、専用CMSの導入によって管理対象は増えます。編集者が少ない場合は、複雑な仕組みを追加するより、Markdown用の入力テンプレートを用意するほうが簡単な場合もあります。
失敗2：WordPressの自動投稿が認証エラーで止まる
API認証、ユーザー権限、セキュリティプラグイン、WAFなどが原因になることがあります。
投稿前に認証確認を行い、失敗した記事を無制限に再送しない設計にします。投稿IDを保存していないと、復旧後に重複記事が作られる恐れがあります。
実装時には、少なくとも次を確認してください。
HTTPステータス
WordPress側のエラーコード
投稿ID
投稿状態
再試行回数
最終試行日時
失敗3：AI記事を毎日公開したのに流入が増えない
検索需要、独自データ、内部リンク、サイト内重複の検証が不足している可能性があります。
対策は、本数ではなく「検索表示が発生した記事の割合」を確認することです。本サイトには135本の投稿Markdownがありますが、この件数だけでは成果を評価できません。Search Consoleや商品ページのイベント計測が必要です。
失敗4：古い家賃相場や制度を自動掲載し続ける
取得日と有効期限が記事データにないことが原因です。
記事ごとにlast_verifiedを保存し、一定期間を超えた記事を自動で再調査キューへ送ります。更新できなければ、記事冒頭に最終確認日を表示するか、公開を停止します。
更新頻度は情報の性質によって変えます。
| 情報 | 確認頻度の例 |
|---|---|
| 法令・税制 | 改正情報の公表時と施行前 |
| 住宅ローン金利 | 毎月 |
| 家賃相場 | 四半期または半年ごと |
| 自社サービス料金 | 変更時 |
| 一般的な用語解説 | 年1回 |
| 外部リンク | 月1回の自動確認 |
これは一律の正解ではありません。記事のリスクと更新コストに応じて調整してください。
失敗5：「完全自動」を急ぎ、誤情報まで公開する
不動産、税務、融資、法令は、誤りの影響が大きい分野です。
金額、制度、契約条件を含む記事には、一次情報の存在を必須条件として設定します。確認できない場合は公開処理を停止し、エラーログへ回します。
「AIが自信ありと判定した」は、一次情報の代わりにはなりません。
成果を測るKPI
自動化の成果は公開本数ではなく、検索から収益導線までの段階で測ります。
| 段階 | KPI | 改善の判断 |
|---|---|---|
| 稼働 | 自動処理成功率 | 失敗工程と再実行回数を確認 |
| 品質 | 検査合格率 | 同じ違反が続くならテンプレートを修正 |
| 検索 | インデックス率 | 未登録記事の重複・品質・クロールを確認 |
| 表示 | 検索表示回数 | 需要のあるテーマを見つける |
| クリック | 検索CTR | タイトルと説明文を改善 |
| 閲覧 | CTA到達率 | 導入、見出し、記事構成を改善 |
| 送客 | 商品ページ遷移率 | CTAの文言と記事との関連性を確認 |
| 成果 | 問い合わせ・購入件数 | 商品、価格、信頼材料を再検討 |
| 保守 | 月間手動対応時間 | 自動化で本当に時間を減らせたか確認 |
自動化の投資対効果は、次の形で記録できます。
月間粗成果
－ ホスティング費
－ AI・API費
－ 外注費
－ 障害対応時間 × 自分で決めた時間単価
＝ 自動化後の概算貢献
たとえば、月3万円の粗成果があっても、障害対応に毎月10時間かかり、自分の時間単価を3,000円と設定するなら、時間コストだけで3万円です。この段階では、自動化による経済的な貢献が出ているとは評価しにくくなります。
反対に、売上がまだなくても、検索表示、CTA到達率、商品ページ遷移率が伸びていれば、改善に使えるデータは蓄積されています。
HugoとWordPressが適さないケース
Hugoは、リアルタイムの物件在庫、複雑な検索、会員ごとの表示、予約枠管理をサイト内部で完結させたい場合に、開発負担が増えます。
WordPressは、プラグイン更新、バックアップ、監視、復旧を担当できる人がいない場合、運用負荷が想定より膨らむ可能性があります。
要件によっては、次の選択肢も検討対象です。
- 記事はHugo、予約は外部予約サービス
- 記事はHugo、編集画面だけヘッドレスCMS
- 集客記事はHugo、会員サイトは別システム
- WordPressをマネージドホスティングで運用
- 物件検索は専用SaaSを埋め込む
どちらを選んでも、根拠の薄いAI記事を大量公開すれば収益化できるとは限りません。検索エンジン、広告サービス、アフィリエイト事業者の規約も変更されます。
完全自動化は「永久に確認不要」という意味ではありません。通常時の人手を減らし、異常時には停止・通知できる状態として設計するのが現実的です。
一般的な比較記事との違い
一般的なHugo対WordPressの記事は、速度、費用、使いやすさの比較で終わりがちです。
この記事では、不動産ブログを自動化資産として扱い、次の要素まで判断材料にしました。
- 本サイトにある135本の投稿を使ったHugoビルド実測
- 実測条件、再現コマンド、比較できない範囲の明示
- 自動生成と品質検査を分離する運用
- 失敗時の停止・記録・復旧方法
- 表面利回りと実質的な収益性を混同しない考え方
- 検索流入から商品ページまでのKPI
- 完全自動化が適さないケース
- 手動対応時間まで含めた投資対効果の評価
今日30分でできる準備
まず、次の項目を埋めてください。
記事の主目的：
想定読者：
更新する人：
月間予定記事数：
会員・予約機能の有無：
Gitを扱える人の有無：
月間の保守時間上限：
収益導線：
使用する一次情報：
公開前の確認担当：
障害時の停止方法：
次に、回答を次の基準へ当てはめます。
Hugoを試す
- 公開記事が中心
- Gitを扱える人がいる
- フォームや決済を外部サービスへ分離できる
- 変更履歴をファイル単位で確認したい
- 保守対象を減らしたい
WordPressを試す
- 管理画面が必須
- 複数の非エンジニアが編集する
- 会員、予約、物件検索が必要
- 画像やレイアウトを頻繁に変更する
- 更新、バックアップ、復旧を担当できる人がいる
迷ったら同じ記事で小さく比較する
選定会議を長引かせるより、同じ不動産記事をHugoとWordPressで1本ずつ公開し、次の時間を記録してください。
| 作業 | Hugo | WordPress |
|---|---|---|
| 初回投稿 | 分 | 分 |
| 画像追加 | 分 | 分 |
| 誤字修正 | 分 | 分 |
| 公開前確認 | 分 | 分 |
| 公開 | 分 | 分 |
| 前の状態への復旧 | 分 | 分 |
| 更新担当者への説明 | 分 | 分 |
さらに、次の項目も確認します。
- 公開前に差分を確認できたか
- エラー時に公開が止まったか
- 誰がいつ変更したか追跡できたか
- 非エンジニアが自力で更新できたか
- バックアップから復旧できたか
- 月間100記事になっても同じ運用を続けられるか
この小規模試験なら、機能一覧だけでは分からない「自分たちの運用に合うか」を確認できます。
結論：機能数ではなく、運用と復旧で選ぶ
Hugoは、記事をファイルとして管理し、Gitと自動デプロイを組める人に向いています。公開部分を静的にできるため、不動産ブログの集客記事を比較的低い保守負荷で積み上げやすい選択肢です。
WordPressは、管理画面、複数人編集、予約、会員、物件検索などを早く実装したい場合に力を発揮します。ただし、コア、テーマ、プラグイン、データベース、認証を継続的に管理する前提があります。
どちらを選んでも、収益につながる自動化資産にするには、情報取得、生成、検証、公開、計測、更新を一連の処理として設計する必要があります。
最終的な判断基準は、「どちらが高機能か」ではありません。
自分たちの体制で、安全に更新でき、異常時に止められ、短時間で復旧できるのはどちらかで選んでください。
本気で自動化・ストック型収益を構築したい方へ
「記事を書き続けなければ止まるブログ」から、「データを取得し、記事を生成し、品質を検査し、公開と収益導線まで動く仕組み」へ切り替えたい方のために、実装手順をまとめています。
ツール名を並べただけの解説ではありません。どの工程を自動化し、どこで処理を止め、何をログに残し、どう商品ページへつなげるかを、実際に組み立てるための実践マニュアルです。
自分の時間を切り売りする運用を減らし、継続的に働くデジタル資産を作りたい方は、次のページから目的に合うマニュアルを確認してください。