WordPress マルチサイトの正しい始め方:サブドメイン/ディレクトリ選定
WordPress で複数のサイトを運営したいとき、マルチサイト機能は非常に便利です。1 つの WordPress インストールで複数のサイトを管理できるため、メンテナンスの手間が大幅に削減されます。
しかし、マルチサイトを有効化する際、多くの方が最初に直面するのが「サブドメイン型」か「ディレクトリ型」かという選択です。この選択は後から変更することが非常に困難で、サイトの将来性を大きく左右します。本記事では、それぞれの特徴を理解し、あなたのプロジェクトに最適な選択ができるよう、詳しく解説していきます。
背景
WordPress マルチサイト機能の成り立ち
WordPress のマルチサイト機能は、元々 WordPress MU(Multi-User)という別のプロジェクトでした。WordPress.com を運営するために開発されたこの機能は、WordPress 3.0 で本体に統合され、現在では標準機能として誰でも利用できるようになっています。
この機能により、1 つのデータベースと 1 つの WordPress コアファイルで、複数の独立したサイトを運営できます。企業の部署ごとのサイト、多言語サイト、複数のブランドサイトなど、様々なユースケースで活用されているのです。
マルチサイトの基本構造
マルチサイトでは、メインサイト(親サイト)の下に、複数のサブサイトを作成できます。以下の図で、基本的な構造を確認しましょう。
mermaidflowchart TB
main["メインサイト<br/>(サイトID: 1)"] --> db[("共通<br/>データベース")]
sub1["サブサイト1<br/>(サイトID: 2)"] --> db
sub2["サブサイト2<br/>(サイトID: 3)"] --> db
sub3["サブサイト3<br/>(サイトID: 4)"] --> db
core["WordPress<br/>コアファイル"] -.共有.- main
core -.共有.- sub1
core -.共有.- sub2
core -.共有.- sub3
すべてのサイトが同じ WordPress コアファイルとデータベースを共有しながら、それぞれ独立したコンテンツ、テーマ、プラグイン設定を持つことができます。この仕組みにより、メンテナンスコストを抑えながら、複数サイトを効率的に運営できるのです。
2 つの異なる URL 構造
WordPress マルチサイトには、サブサイトの URL を決定する 2 つの方式があります。
| # | 方式 | URL 例 | 説明 |
|---|---|---|---|
| 1 | サブドメイン型 | blog.example.comshop.example.com | メインドメインの前に名前を追加 |
| 2 | ディレクトリ型 | example.com/blogexample.com/shop | メインドメインの後ろにパスを追加 |
この選択は、マルチサイトを有効化する際に一度だけ行い、後から変更することは実質的に不可能です。そのため、慎重な判断が求められます。
課題
なぜ選択が難しいのか
マルチサイトの設定において、サブドメイン型とディレクトリ型の選択は、単なる URL の見た目の問題ではありません。それぞれに技術的な特性があり、サイトの運用方法、SEO、サーバー設定など、多岐にわたる影響を及ぼします。
初めてマルチサイトを構築する方にとって、以下のような疑問が生じるでしょう。
よくある悩み
- DNS の設定が必要なのはどちらか
- SEO 的にはどちらが有利なのか
- 後からサブサイトを増やしやすいのはどちらか
- サーバーの制約を受けやすいのはどちらか
- SSL 証明書の設定が複雑なのはどちらか
これらの疑問を解決せずに選択してしまうと、後々大きな問題に直面する可能性があります。
選択ミスによる影響
間違った選択をした場合、以下のような問題が発生します。
mermaidflowchart LR
wrong["不適切な<br/>選択"] --> dns["DNS設定<br/>エラー"]
wrong --> seo["SEO<br/>問題"]
wrong --> ssl["SSL証明書<br/>の複雑化"]
wrong --> cost["運用コスト<br/>増大"]
dns --> migrate["サイト<br/>移行"]
seo --> migrate
ssl --> migrate
cost --> migrate
migrate --> risk["データ損失<br/>リスク"]
migrate --> downtime["ダウン<br/>タイム"]
図で理解できる要点
- 不適切な選択は複数の技術的問題を引き起こします
- 最終的にサイト移行が必要になり、リスクとコストが発生します
- 初期段階での正しい選択が、長期的な運用の安定性につながります
変更の困難さ
一度マルチサイトを構築すると、サブドメイン型からディレクトリ型へ(またはその逆)の変更は、以下の作業が必要になります。
| # | 作業項目 | 難易度 | リスク |
|---|---|---|---|
| 1 | データベース内の URL 一括置換 | ★★★★★ | データ損失の可能性 |
| 2 | .htaccess の書き換え | ★★★☆☆ | サイトアクセス不可 |
| 3 | wp-config.php の再設定 | ★★★☆☆ | 設定ミスでエラー |
| 4 | DNS 設定の変更 | ★★★★☆ | 反映までの待機時間 |
| 5 | SSL 証明書の再取得 | ★★★☆☆ | セキュリティ警告 |
このように、変更には高度な技術知識が必要で、失敗すればサイト全体が停止する危険性もあります。そのため、最初の選択が極めて重要なのです。
解決策
サブドメイン型の特徴
サブドメイン型は、各サブサイトが独立したドメイン名を持つ方式です。blog.example.com、shop.example.com のように、メインドメインの前に名前が付きます。
サブドメイン型のメリット
| # | メリット | 詳細 |
|---|---|---|
| 1 | サイトの独立性が高い | 各サイトが別ドメインとして認識される |
| 2 | ブランディングに有利 | 用途ごとに明確な名前を付けられる |
| 3 | 技術的な柔軟性 | サブサイトごとに異なるサーバー設定も可能 |
| 4 | SEO での独立評価 | Google が独立したサイトとして評価する傾向 |
サブドメイン型のデメリット
| # | デメリット | 詳細 |
|---|---|---|
| 1 | DNS 設定が必須 | ワイルドカード DNS レコードが必要 |
| 2 | SSL 証明書の複雑化 | ワイルドカード証明書が必要な場合も |
| 3 | サーバー制約 | 共有サーバーでは利用できない場合がある |
| 4 | メインドメインとの関連性 | SEO 的に別サイト扱いになる |
ディレクトリ型の特徴
ディレクトリ型は、メインドメインの下にパスを追加する方式です。example.com/blog、example.com/shop のように、URL がディレクトリ構造になります。
ディレクトリ型のメリット
| # | メリット | 詳細 |
|---|---|---|
| 1 | 設定が簡単 | DNS 設定が不要 |
| 2 | SSL 証明書が単純 | 1 つの証明書ですべてカバー |
| 3 | 共有サーバーでも利用可 | サーバー制約を受けにくい |
| 4 | SEO でドメイン評価を継承 | メインドメインの SEO 評価を活用できる |
ディレクトリ型のデメリット
| # | デメリット | 詳細 |
|---|---|---|
| 1 | URL 構造の制限 | すべて同一ドメイン配下になる |
| 2 | ブランディングの制約 | 独立したサイト感が出にくい |
| 3 | .htaccess の競合 | パス構造に制限がある |
| 4 | 独立性が低い | メインサイトの影響を受けやすい |
選定基準フローチャート
あなたのプロジェクトに最適な方式を選ぶために、以下のフローチャートを参考にしてください。
mermaidflowchart TD
start["マルチサイト<br/>構築開始"] --> q1{"各サイトを<br/>独立したブランド<br/>として扱う?"}
q1 -->|はい| q2{"DNS設定や<br/>ワイルドカード<br/>証明書を<br/>管理できる?"}
q1 -->|いいえ| q3{"共有サーバーを<br/>使用している?"}
q2 -->|はい| subdomain["サブドメイン型<br/>を選択"]
q2 -->|いいえ| q3
q3 -->|はい| directory["ディレクトリ型<br/>を選択"]
q3 -->|いいえ| q4{"メインサイトの<br/>SEO評価を<br/>活用したい?"}
q4 -->|はい| directory
q4 -->|いいえ| subdomain
図で理解できる要点
- ブランディングと独立性を重視する場合、サブドメイン型が適しています
- 技術的な制約やシンプルさを優先する場合、ディレクトリ型が最適です
- 共有サーバー利用者は、ディレクトリ型一択になる場合が多いです
ユースケース別の推奨
具体的なシナリオに基づいて、どちらを選ぶべきか見ていきましょう。
サブドメイン型が適しているケース
| # | ケース | 理由 |
|---|---|---|
| 1 | 企業の事業部ごとのサイト | 各部署の独立性を明確にできる |
| 2 | 多ブランド展開 | ブランドごとに専用ドメインを持てる |
| 3 | 言語別サイト | en.example.com、ja.example.com など自然 |
| 4 | サービスごとのポータル | blog.example.com、shop.example.com など分離可能 |
ディレクトリ型が適しているケース
| # | ケース | 理由 |
|---|---|---|
| 1 | 1 つのブランド内での複数コンテンツ | 統一感を保ちやすい |
| 2 | 共有サーバー利用 | DNS 制約を回避できる |
| 3 | SEO 評価を集約したい | ドメインパワーを分散させない |
| 4 | 地域別サイト | example.com/tokyo、example.com/osaka など |
具体例
サブドメイン型の設定手順
サブドメイン型でマルチサイトを構築する具体的な手順を見ていきましょう。作業は段階的に進めることで、エラーを最小限に抑えられます。
ステップ 1:DNS 設定
サブドメイン型を利用するには、まず DNS サーバーでワイルドカードレコードを設定する必要があります。これにより、任意のサブドメインが自動的にサーバーに向くようになります。
DNS 設定例(A レコード)
textタイプ: A
ホスト: *
値: 192.0.2.1(サーバーのIPアドレス)
TTL: 3600
この設定により、blog.example.com でも shop.example.com でも、すべてのサブドメインが同じサーバーを指すようになります。
注意点
- DNS 設定の反映には数時間から最大 48 時間かかる場合があります
- 設定前に、現在の DNS レコードをバックアップしておきましょう
- 共有サーバーの場合、ホスティング会社に確認が必要です
ステップ 2:wp-config.php の編集
WordPress のマルチサイト機能を有効化するため、wp-config.php ファイルを編集します。
編集箇所の確認
まず、wp-config.php ファイルを開き、以下のコメント行を探します。
php/* That's all, stop editing! Happy publishing. */
この行の直前に、以下のコードを追加します。
マルチサイト有効化コード
php/* Multisite */
define('WP_ALLOW_MULTISITE', true);
このコードにより、WordPress の管理画面に「ネットワークの設置」メニューが表示されるようになります。
重要な注意事項
- ファイル編集前に必ずバックアップを取得してください
- 文字コードは UTF-8(BOM なし)で保存します
- FTP ソフトまたはサーバーのファイルマネージャーを使用します
ステップ 3:ネットワーク設置の実行
WordPress 管理画面から、マルチサイトのネットワーク設置を実行します。
操作手順
- WordPress 管理画面にログイン
- 「ツール」→「ネットワークの設置」を選択
- 「サブドメイン」を選択
- ネットワークタイトルと管理者メールアドレスを入力
- 「インストール」ボタンをクリック
すると、追加で設定が必要なコードが表示されます。これを次のステップで設定していきます。
ステップ 4:wp-config.php への追加設定
ネットワーク設置後に表示されたコードを、wp-config.php に追加します。
追加するコード例
phpdefine('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);
define('DOMAIN_CURRENT_SITE', 'example.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);
各定数の意味を理解しておきましょう。
| # | 定数名 | 説明 |
|---|---|---|
| 1 | MULTISITE | マルチサイト機能を有効化 |
| 2 | SUBDOMAIN_INSTALL | サブドメイン型を指定(true ならサブドメイン、false ならディレクトリ) |
| 3 | DOMAIN_CURRENT_SITE | メインサイトのドメイン名 |
| 4 | PATH_CURRENT_SITE | メインサイトのパス(通常は /) |
| 5 | SITE_ID_CURRENT_SITE | ネットワーク ID(通常は 1) |
| 6 | BLOG_ID_CURRENT_SITE | メインサイトの ID(通常は 1) |
ステップ 5:.htaccess の編集
最後に、.htaccess ファイルに WordPress が生成したリライトルールを追加します。
追加するコード例
apacheRewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]
このリライトルールにより、サブドメインごとに適切なサイトへルーティングされます。
設定完了後の確認
以下の手順で、正しく設定できたか確認しましょう。
- WordPress 管理画面に再ログイン
- 画面左上に「参加サイト」メニューが表示されているか確認
- 「サイトネットワーク管理者」→「サイト」から新しいサイトを追加
- 追加したサブドメインでアクセスできるか確認
ディレクトリ型の設定手順
ディレクトリ型は、サブドメイン型と比べて設定がシンプルです。DNS 設定が不要なため、共有サーバーでも問題なく利用できます。
ステップ 1:wp-config.php の初期設定
サブドメイン型と同様に、まずマルチサイト機能を有効化します。
マルチサイト有効化コード
php/* Multisite */
define('WP_ALLOW_MULTISITE', true);
/* That's all, stop editing! Happy publishing. */ の直前に追加し、ファイルを保存します。
ステップ 2:ネットワーク設置(ディレクトリ型を選択)
WordPress 管理画面から「ツール」→「ネットワークの設置」へ進み、今度は「サブディレクトリ」を選択します。
注意事項
既存の WordPress サイトでパーマリンク設定を使用している場合、以下のメッセージが表示される可能性があります。
textパーマリンク設定を使用しているため、サブディレクトリでの設置はできません。
この場合、一時的にパーマリンク設定を「基本」に変更してから、ネットワーク設置を実行し、完了後に元に戻します。
ステップ 3:wp-config.php への追加設定
ネットワーク設置後に表示されるコードを追加します。サブドメイン型との違いは、SUBDOMAIN_INSTALL が false になっている点です。
追加するコード例
phpdefine('MULTISITE', true);
define('SUBDOMAIN_INSTALL', false);
define('DOMAIN_CURRENT_SITE', 'example.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);
SUBDOMAIN_INSTALL を false にすることで、ディレクトリ型のマルチサイトとして動作します。
ステップ 4:.htaccess の編集(ディレクトリ型用)
ディレクトリ型の .htaccess ルールは、サブドメイン型とほぼ同じですが、パスベースのルーティングに対応しています。
追加するコード例
apacheRewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]
設定後、example.com/site1、example.com/site2 のような URL 構造でサブサイトが作成できるようになります。
サブサイトの追加方法
マルチサイトの設定が完了したら、実際にサブサイトを追加してみましょう。手順はサブドメイン型もディレクトリ型も共通です。
管理画面からの追加
- WordPress 管理画面の左上「参加サイト」→「サイトネットワーク管理者」→「サイト」をクリック
- 「新規追加」ボタンをクリック
- 以下の情報を入力します
入力項目
| # | 項目 | サブドメイン型の例 | ディレクトリ型の例 |
|---|---|---|---|
| 1 | サイトアドレス | blog | blog |
| 2 | サイトのタイトル | ブログサイト | ブログサイト |
| 3 | 管理者メール | admin@example.com | admin@example.com |
サブドメイン型では blog.example.com が、ディレクトリ型では example.com/blog が作成されます。
コマンドラインからの追加(WP-CLI)
より効率的にサブサイトを追加したい場合、WP-CLI を使うと便利です。
WP-CLI によるサイト追加コマンド
bashwp site create --slug=blog --title="ブログサイト" --email="admin@example.com"
このコマンドを実行すると、即座にサブサイトが作成されます。
複数サイトの一括作成
bashwp site create --slug=shop --title="ショップサイト" --email="shop@example.com"
wp site create --slug=news --title="ニュースサイト" --email="news@example.com"
wp site create --slug=forum --title="フォーラム" --email="forum@example.com"
大量のサブサイトを作成する場合、スクリプト化することで作業時間を大幅に短縮できます。
SSL 証明書の設定
セキュリティ確保のため、すべてのサイトで SSL 証明書を設定することが重要です。方式によって必要な証明書の種類が異なります。
サブドメイン型の SSL 設定
サブドメイン型では、ワイルドカード証明書を使用するのが一般的です。
Let's Encrypt でのワイルドカード証明書取得
bashcertbot certonly --manual --preferred-challenges dns -d example.com -d *.example.com
このコマンドを実行すると、DNS レコードに特定の TXT レコードを追加するよう求められます。指示に従って設定すれば、すべてのサブドメインで有効な証明書が取得できます。
証明書の自動更新設定
bashcertbot renew --dry-run
このコマンドで更新のテストを実施し、問題なければ cron ジョブに登録します。
bash0 3 * * * certbot renew --quiet
ディレクトリ型の SSL 設定
ディレクトリ型では、メインドメインの証明書 1 つで全サブサイトをカバーできます。
Let's Encrypt での証明書取得
bashcertbot certonly --webroot -w /var/www/html -d example.com
設定後、すべてのサブディレクトリ(example.com/blog、example.com/shop など)が自動的に SSL 化されます。
Web サーバー設定(Apache)
apache<VirtualHost *:443>
ServerName example.com
DocumentRoot /var/www/html
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
</VirtualHost>
この設定により、ディレクトリ配下のすべてのサイトが HTTPS でアクセス可能になります。
トラブルシューティング
マルチサイト設定時によくあるエラーと解決方法を紹介します。
エラー 1:サブドメインにアクセスできない
エラーコード: ERR_NAME_NOT_RESOLVED または DNS_PROBE_FINISHED_NXDOMAIN
エラーメッセージ:
textこのサイトにアクセスできません
blog.example.com のサーバーの IP アドレスが見つかりませんでした。
発生条件
- DNS のワイルドカードレコードが正しく設定されていない
- DNS 設定の反映待ち時間中
解決方法
- DNS レコードを確認します
bashnslookup blog.example.com
正しく設定されていれば、サーバーの IP アドレスが返されます。
- DNS 設定を再確認し、以下が正しいか確認してください
textタイプ: A
ホスト: *
値: サーバーのIPアドレス
- DNS キャッシュをクリアします
bash# Windows
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux
sudo systemd-resolve --flush-caches
エラー 2:wp-config.php の設定エラー
エラーコード: 500 Internal Server Error
エラーメッセージ:
textサーバー内部エラーが発生しました。
このリクエストを処理できません。
発生条件
wp-config.phpの記述ミス- 定数の重複定義
- 文字コードの問題
解決方法
wp-config.phpのバックアップから復元します- 追加したコードの構文を確認します
- 特に以下をチェックしてください
php// 正しい例
define('MULTISITE', true);
// 間違った例(シングルクォートとダブルクォートの混在)
define("MULTISITE', true);
// 間違った例(セミコロン忘れ)
define('MULTISITE', true)
- ファイルの文字コードが UTF-8(BOM なし)であることを確認します
エラー 3:.htaccess のリライトエラー
エラーコード: 404 Not Found
発生条件
.htaccessのリライトルールが正しくない- Apache の
mod_rewriteモジュールが無効
解決方法
mod_rewriteが有効か確認します
bashapache2ctl -M | grep rewrite
rewrite_module が表示されない場合は、有効化します。
bashsudo a2enmod rewrite
sudo systemctl restart apache2
.htaccessが読み込まれているか確認します。Apache 設定でAllowOverrideがAllになっている必要があります
apache<Directory /var/www/html>
AllowOverride All
</Directory>
- WordPress が生成したリライトルールを正確にコピーしているか再確認します
まとめ
WordPress マルチサイトのサブドメイン型とディレクトリ型、それぞれに明確な特徴があることをご理解いただけたでしょうか。選択は一度きりで後戻りが難しいため、プロジェクトの特性に応じた慎重な判断が求められます。
選択のポイント再確認
サブドメイン型を選ぶべき場合は、各サイトの独立性を重視し、ブランディングや SEO で独立した評価を得たいケースです。DNS やワイルドカード SSL 証明書の管理ができる環境が前提となりますが、企業の部署別サイトや多ブランド展開には最適でしょう。
一方、ディレクトリ型は設定のシンプルさが魅力です。DNS 設定が不要で、共有サーバーでも利用でき、SSL 証明書も 1 つで済みます。メインドメインの SEO 評価を活用したい場合や、統一ブランド内での複数コンテンツ展開に向いています。
技術的な準備
どちらを選ぶにしても、事前のバックアップは必須です。wp-config.php、.htaccess、データベースのバックアップを必ず取得してから作業を始めましょう。また、DNS 設定の反映には時間がかかるため、余裕を持ったスケジュールで進めることをおすすめします。
運用の視点
マルチサイト構築後の運用も考慮に入れてください。サブサイトの追加頻度、管理者の技術レベル、将来的な拡張計画など、長期的な視点で選択することが成功の鍵となります。
WordPress マルチサイトは、正しく設定すれば非常に強力なツールです。本記事で紹介した選定基準と設定手順を参考に、あなたのプロジェクトに最適な構成を実現してください。
関連リンク
articleWordPress マルチサイトの正しい始め方:サブドメイン/ディレクトリ選定
articleWordPress 技術で読み解く Interactivity API:動的 UI をノー JS フレームワークで実現
articleバックアップ戦略の決定版:WordPress の世代管理/災害復旧の型
articleプラグイン競合の特定術:WordPress で原因切り分けを高速化する手順
article画像最適化比較:WordPress の WebP/AVIF/外部 CDN を実測レビュー
articleWordPress URL 設計とリライトルール:正規化と SEO を両立する作法
articleZod の再帰型・木構造設計:`z.lazy` でツリー/グラフを安全に表現
articleCline ガバナンス運用:ポリシー・承認フロー・監査証跡の整備
articleYarn の歴史と進化:Classic(v1) から Berry(v2/v4) まで一気に把握
articleClaude Code 中心の開発プロセス設計:要求 → 設計 → 実装 → 検証の最短動線
articleWeb Components のスロット設計術:命名付き slot/fallback/`slotchange` の実戦パターン
articleBun vs Node.js 徹底比較:起動時間・スループット・メモリの実測レポート
blogiPhone 17シリーズの発表!全モデルiPhone 16から進化したポイントを見やすく整理
blogGoogleストアから訂正案内!Pixel 10ポイント有効期限「1年」表示は誤りだった
blog【2025年8月】Googleストア「ストアポイント」は1年表記はミス?2年ルールとの整合性を検証
blogGoogleストアの注文キャンセルはなぜ起きる?Pixel 10購入前に知るべき注意点
blogPixcel 10シリーズの発表!全モデル Pixcel 9 から進化したポイントを見やすく整理
blogフロントエンドエンジニアの成長戦略:コーチングで最速スキルアップする方法
review今の自分に満足していますか?『持たざる者の逆襲 まだ何者でもない君へ』溝口勇児
reviewついに語られた業界の裏側!『フジテレビの正体』堀江貴文が描くテレビ局の本当の姿
review愛する勇気を持てば人生が変わる!『幸せになる勇気』岸見一郎・古賀史健のアドラー実践編で真の幸福を手に入れる
review週末を変えれば年収も変わる!『世界の一流は「休日」に何をしているのか』越川慎司の一流週末メソッド
review新しい自分に会いに行こう!『自分の変え方』村岡大樹の認知科学コーチングで人生リセット
review科学革命から AI 時代へ!『サピエンス全史 下巻』ユヴァル・ノア・ハラリが予見する人類の未来