AI・SEO対策

PHP2Shell、どう対応するか｜共用サーバー・VPS・コンテナ・制作会社任せ・PHP 8.1以前で「誰が何をするか」

2026年10月23日日高駿21分で読めます

「PHPを修正版に更新してください」。IPAもJPCERT/CCもPHPの公式も、PHP2Shellについて言うことは同じです。ところが、この一文をそのまま実行できる人は思ったより少ない。共用のレンタルサーバーの利用者はPHPに手が届きません。Ubuntu 24.04で修正済みとされるパッケージの版は「8.3.6-0ubuntu0.24.04.13」で、修正版の8.3.36より古く見えます。

PHP2Shellへの対策は「修正版のPHPを入れ、PHPを動かしているプロセスを再起動する」の一つです。環境によって変わるのは、それを誰がやり、直ったことを何で確かめるか。直ったかどうかを版番号だけで判断すると、両方向に読み違えます。

この記事では、IPA・JPCERT/CC・PHP公式と発見者側の公開情報、Ubuntu・Debian・Red Hat・AlmaLinux・Amazon Linuxの配布元情報、国内レンタルサーバー5社の告知、Cloudflareの説明を、環境ごとに並べ直しました。扱うのは更新の手順そのものです。

KEY POINTS

項目	内容
完全な対策	修正版のPHP（8.5.12／8.4.27／8.3.36／8.2.35、もしくはOS配布元の修正済みパッケージ）を入れ、Apache・PHP-FPMなどを再起動する。WordPressやプラグインの更新ではPHPは直らない
共用レンタルサーバー	更新するのは事業者。版番号の据え置き、一部機能の無効化、恒久対応が未定のプランと、処理は各社で違う
VPS・専用・クラウド	更新するのは利用者。配布元の修正版は番号がPHP公式と揃わない
コンテナ	ベースイメージが更新されたら作り直す（Red Hat）
制作会社任せ	保守契約にサーバーとPHPの更新が入っているかで、担当が決まる
PHP 8.1以前	PHP公式の修正版はない。「どう直すか」より先に「続けるか」を、IPAの手順で決める。8.2も2026年12月31日にサポートが終わる

公的機関の注意喚起は、読者を提供元へ送り返す

何をすべきかは、公式がはっきり示しています。その上で日本の公的機関の注意喚起を読み進めると、どちらも読者を自分の環境の提供元へ送り返している。

PHPプロジェクトは10月21日、8.5.12・8.4.27・8.3.36・8.2.35を公開しました。直したのは、認証なしでリモートからコードを実行され得る脆弱性2件（CVE-2026-109618／CVE-2026-109619）。PHP側の評価は、どちらもCVSS v4.0で9.2です。

影響を受けるのはウェブのリクエストを処理するPHP全般で、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedが名指しされました。リスクが最も高いとされたのはmod_phpです。

"Install a fixed PHP release on every runtime, then restart Apache, PHP-FPM and any long-running PHP workers. This is the only complete fix. Updating an application does not update the PHP runtime beneath it."
php2shell.com（発見者側の公開ページ）

動いている全てのPHPに修正版を入れ、Apache・PHP-FPM・常駐するワーカーを再起動する。それが唯一の完全な修正で、アプリを更新してもその下のPHPは更新されない、という意味です。PHP公式の各リリース告知にも「There are no complete mitigations, updating is the only safe choice.」とあります。

日本では10月22日、IPAが「PHPの脆弱性対策について」を、JPCERT/CCが注意喚起（JPCERT-AT-2026-0033）を公開し、JVNにもJVNVU#99905564が載りました。JPCERT/CCはPHPが「国内で広く利用されていることを確認しています」とした上で、対策の適用と侵害有無の調査を速やかに行うよう呼び掛けています。注目したいのは、その先の一文です。

「なお、PHPを使用する製品やLinuxディストリビューションが提供するPHPも、本脆弱性の影響を受ける可能性があります。本脆弱性に関する対応は利用している製品やOSの提供元が公開する情報もあわせて確認してください。」
JPCERT/CC「PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起」(2026年10月22日)

IPAも、自組織で使っている製品の影響は「その製品等の開発者やサービス提供元からの情報をご確認ください」とし、問い合わせ先の注釈では、個別のシステムや環境についての質問には回答できない場合があると断っています。公的機関が示せるのは「何をするか」まで。誰が・どの画面で確かめるかは、自分の環境を知っている人にしか決められません。この記事の出発点はそこにあります。

環境ごとの「誰が更新し、何で確かめるか」早見表

まず自社サイトがどの行に当たるかを決めます。確かめる先は行ごとに一つです。

環境	更新する人	「直った」を確かめる先	見落としやすい点
共用レンタルサーバー	事業者	事業者の告知（対応済みの版と時点）	表示される番号が変わらない場合がある。一部機能の無効化、プランによっては恒久対応が未定
VPS・専用サーバー・クラウド	利用者（root／sudo権限を持つ人）	OS配布元のセキュリティ情報と、入っているパッケージの版	自動更新で修正が入っても、PHPを使うアプリの再起動が要る（Ubuntu）
コンテナ	イメージを作る人	ベースイメージ提供元の更新と、作り直したイメージ	ベースイメージが更新されたら再ビルドする（Red Hat）
制作会社・保守会社任せ	契約で決まる	委託先からの報告（版・日時・再起動したもの）	アプリの更新報告はPHPの更新を意味しない
PHP 8.1以前	配布元・事業者の修正があればその提供者	その版に修正を出したかどうかの告知	PHP公式の修正版はない。事業者自身が「応急的」と位置付ける例もある

共用レンタルサーバー：手を動かすのは事業者、確かめるのは利用者

「PHPの実行環境はサーバー側で提供しているものであり、お客様ご自身で防ぐことが難しい問題です」。ロリポップの告知の一文です。更新は事業者の仕事。それでも、利用者の側に確認が残ります。

国内5社の告知を並べると、同じ「対応済み」でも中身がかなり違います。いずれも各社の告知時点の内容で、その後の更新は各社のお知らせで確かめてください。

事業者	公表された対応	利用者に求めていること
さくらのレンタルサーバ	「当社サービスで提供しているPHPについて必要な修正を適用しています」。サポート終了版のうち同社が提供している版にも修正を適用（10月22日）	最新のサポート対象バージョンの利用を推奨
ConoHa WING	版を上げず、使用中の版のまま修正だけを取り込む方式で、提供中の全版に適用。10月22日20時45分時点で完了	利用者による版の変更は不要
ロリポップ！	8.2〜8.5は公式の修正版、7.4〜8.1は開発元のサポート終了版向け修正、5.3〜7.3は公式の修正をもとに自社で作成した修正を適用。修正が終わるまで一部サーバーでサイト表示をサーバー単位で停止（10月22日3時9分頃〜13時頃）	session.upload_progressが無効になったため、サイトの動作確認。8.2以降への切り替え
エックスサーバー	5.6〜8.5は対象の全サーバーに適用完了、5.5以下は修正の作成・検証中（10月22日の告知時点）。サイトの表示は継続	利用状況によっては追加の対策を依頼する場合がある
KAGOYA	レンタルサーバープランは修正版へ順次更新し、10月22日24時の完了を見込む。マネージド専用・共用・WordPress専用の各サーバープランは恒久対応を調整中（10月22日の続報時点）	該当プランでは公開停止（メンテナンス画面への切り替え）やアクセス制限を検討。.htaccessの記述例を提示

実際の告知を読み比べて、利用者が確かめるべきことは三種類に分かれました。

番号では判断できない

ConoHa WINGは、WordPressの「サイトヘルス」などで版を確認すると、修正版の番号（例：8.5.12）ではなく従来の番号（例：8.5.11）が出る場合があると明記しています。同社の場合、それで修正済みです。番号が変わっていないことは「未対応」の証拠にならず、番号が新しいことも事業者の説明抜きでは何も語らない。共用サーバーで見るべきは、管理画面の番号より事業者の告知です。

止まった機能と、止まったサイト

ロリポップは全ての版でsession.upload_progressを無効にし、サイトの動作確認を利用者に頼みました。PHP公式が「すぐに更新できない場合」の措置に挙げたのと同じ設定項目です。問い合わせフォームやファイルのアップロードが動くかは、事業者には分かりません。修正の適用までサーバー単位で表示を止めたため、PHP 8.2以降のサイトやPHPを使っていないサイトも表示できなかった、と同社は経緯を説明しています。エックスサーバーはサーバーを動かしたまま修正を当てました。どちらも安全と継続のどこに線を引くかの判断で、利用者が選べるものではありません。

「事業者がやる」が途中で止まるプラン

KAGOYAの続報では、一部のプランで恒久対応の方針が決まっておらず、公開停止やアクセス制限の検討を利用者に求めていました。共用のプランでも、IPAの言う「外部からのアクセス遮断やサービスの一時停止が必要か」の判断が、利用者の手に戻ってくる場合があるということです。

共用サーバーの利用者がやることは「PHPを更新すること」ではありません。事業者の告知を読み、自分のプランと版がどの行に当たるかを確かめることです。

VPS・専用サーバー・クラウド：番号ではなく、配布元の修正済みパッケージで判断する

OSを自分で管理する契約なら、更新するのは利用者です。さくらのVPSもConoHa VPSも、告知で更新を利用者に頼んでいます。ここで最初につまずくのが、版番号の読み方です。

ConoHa VPSは「PHP 5.4～8.1はサポートが終了しており、本脆弱性の修正版は提供されていません」として、サポート中の版への移行を求めました。これはPHP公式の版についての説明です。PHP公式自身は、配布元とLTSベンダーには事前にパッチが渡されたこと、8.1以前にもバックポートを出す配布元があることを明らかにしています。OSのパッケージで入れたPHPなら、答えは配布元の情報にあります。

配布元・版	パッケージ	配布元の表記（10月23日確認）
Ubuntu 26.04 LTS	php8.5	Fixed in 8.5.4-0ubuntu1.5
Ubuntu 24.04 LTS	php8.3	Fixed in 8.3.6-0ubuntu0.24.04.13
Ubuntu 22.04 LTS	php8.1	Fixed in 8.1.2-1ubuntu2.28
Ubuntu 20.04 LTS	php7.4	Fixed in 7.4.3-4ubuntu2.29+esm5（ESM、Ubuntu Pro）
Debian 13（trixie）	php8.4	8.4.27-1~deb13u1 で fixed
Debian 12（bookworm）	php8.2	8.2.35-1~deb12u1 で fixed
AlmaLinux 9	php:8.2／php:8.3 モジュール	ALSA-2026:87072／ALSA-2026:87079（Important）
Red Hat Enterprise Linux	php	RHSB-2026-013「Ongoing」。一部は提供済み、残りは作業中（10月22日の更新時点）
Amazon Linux 2023	php8.2〜php8.5	Fixed（ALAS2023-2026-3301〜3304）
Amazon Linux 2023	php8.1	No Fix Planned
Amazon Linux 2 Core	php	No Fix Planned（Php8.2 Extra は ALAS2PHP8.2-2026-015 で Fixed）

Ubuntu 24.04の「8.3.6」は、PHP公式の修正版8.3.36より古く見えて修正済み。22.04では、PHP公式が修正しない8.1にもUbuntuが修正を出しています。Red Hatの説明はこうです。パッケージを新しい版に置き換えず、古い版に修正を移植する。そのため、版番号しか見ないセキュリティスキャナーが脆弱と報告する場合がある。番号の比較で判断すると、直っているサーバーを「未対応」と誤読します。反対に、Amazon Linux 2 Coreのphpのように修正の予定がないパッケージもある。見るべきは番号の大小ではなく、配布元が自分のOS版とパッケージに「Fixed」を付けているかどうかです。

Ubuntuの場合の確認と更新

Ubuntuのブログは、確認・更新・再起動を次の3行で示しています。1行目は入っているPHPパッケージの確認です。更新は全パッケージを対象にする sudo apt update && sudo apt upgrade が推奨で、2行目はそれができない場合にPHPだけを更新する手順。どちらで更新した場合も、PHPを使うアプリの再起動が要ります（3行目）。

apt list '?installed ?name(^php[0-9.]+$)'
sudo apt update && sudo apt install --only-upgrade '?name(^php[0-9.]+$)'
sudo systemctl restart apache2

3行目はmod_phpでApacheを使う場合の例で、サーバーごと sudo reboot する方法も挙がっています。見落としやすいのは自動更新です。Ubuntu 16.04以降で既定で有効なunattended-upgradesは、修正を24時間以内に自動で当てます。その場合でも「the affected applications would still need to be restarted or the system rebooted」。自動で入ったから終わり、とはならないのです。

深刻度の表記が揃わない理由

Red Hatの判定は「Important」で、PHP側の評価（CVSS v4.0で9.2）とは表記が揃いません。標準のRHELはmod_phpではなくPHP-FPMを使い、FPMのワーカーは早い段階の初期化失敗で終了するため、リモートコード実行は実際には難しいというのが理由です。それでもRed Hatは修正の提供を急いでおり、後回しにしてよいという話ではありません。

RHEL系でボランティアが運営するRemiのリポジトリ（rpms.remirepo.net）からPHPを入れている場合は、別の注意が要ります。PHP公式は10月21日の時点で、このリポジトリには当日中の更新がないとし、配布元のパッケージかソースからのビルドへ切り替えるよう促しました。

コンテナ：動いているPHPではなく、イメージを直す

コンテナで動くPHPは、ベースイメージに入っているPHPです。「any customer containers should be rebuilt when the base images are updated.」とRed Hatは明記しています。

確かめる順番は、ベースイメージの提供元が修正版を出したか、それを使ってイメージを作り直したか、作り直したイメージで実際に動いているか。Docker Hubの公式phpイメージには、10月23日の確認時点で「8.3.36-fpm-alpine3.23」などの8.3.36のタグが並んでいました。使っている系列と派生（fpm、alpineなど）のタグに修正版があるかを、自分の構成で確かめます。

PHP公式の臨時措置にも、コンテナが出てきます。CVE-2026-109618（メモリ不足を起点とする経路）の項目で、コンテナやcgroupの上限を可用性の境界として使うよう勧め、RLIMIT_ASやRLIMIT_DATAでの代用は避けるよう求めています。それらは脆弱なメモリ確保の失敗そのものを引き起こし得るからです。これも更新の代わりにはなりません。

制作会社・保守会社任せ：最初に確かめるのは契約の範囲

自社でサーバーに触れないなら、最初の作業は更新を頼む相手を特定することです。「If you do not manage your own server, ask your hosting provider to apply the update now.」とSansecは勧め、CloudflareもPHPをホスティング事業者が管理しているなら事業者に更新を頼むよう案内しています。

委託先との間で起きやすい行き違いの一つが、「サイトの保守」の意味です。PHPの実行環境にある欠陥なので、サイトのコードやプラグインを更新するだけでは直らない。Cloudflareはそう説明しています。「WordPressとプラグインは最新です」という保守報告は、PHPが修正版になったことを意味しません。

IPAは、長期間更新していないシステムで対策が難しくなる事情として、アプリケーションの改修や動作確認の必要に加え、「開発時の資料・ノウハウの不足、担当者の不在、保守契約の終了など」を挙げています。委託先に確かめるのは次の三点で足ります。

サーバーの契約者と、PHPを更新する権限を持つ人は誰か：共用レンタルサーバーなのか、VPS・クラウドなのか。ここが分かれば、上の早見表のどの行かが決まります。
10月21日以降、いつ、どの版にし、何を再起動したか：配布元のパッケージならパッケージの版まで。共用サーバーなら、該当する事業者の告知へのリンクで足ります。
8.1以前なら、その版の修正は誰が出したものか：配布元か、事業者か、修正がないのか。移行の予定があるか。

答えが一往復で返ってこないこと自体が、最初に塞ぐべき穴です。

WAFは、更新までの時間を稼ぐもの

Cloudflareは、10月21日3時2分（UTC）から無料・有料のWAFの利用者を既定で保護したと発表しました。対象はFreeを含め、WAFを使う全プラン。Pro・Business・Enterpriseプランには、Managed Rulesetがブロックモードで展開されているかの確認を促しています。その同社自身が「Customers should patch their PHP repos even with WAF protections」と釘を刺す。保護の範囲は事業者と攻撃経路によるとして、保護ルールを更新の代わりにしないよう求めるのがphp2shell.comです。WAFの有無は、更新の要否を変えません。

PHP 8.1以前は、IPAの手順で「続けるか」から決める

「PHP 8.1 and older no longer receive updates from the PHP project」。PHP公式の告知の一文です。とはいえ「どこからも修正がない」わけでもない。問題は今回の穴より、次の穴を誰が塞ぐのかが決まっていないことです。

PHPのセキュリティチームは、ソースからビルドする人やLTSベンダーを持たない人のために、7.4・8.0・8.1向けの最小限のソースのバックポートを出しました。JPCERT/CCも、サポートされている版へのアップグレードを推奨しつつ、このEOL版向けの最小限の緩和策に触れています。

配布元では、Ubuntu 22.04のphp8.1が通常サポートの範囲で修正され、20.04以前はUbuntu Proの対象です（Ubuntu Proは5台まで無料、コミュニティメンバーは50台まで）。反対に、Amazon Linux 2023のphp8.1とAmazon Linux 2 Coreのphpは「No Fix Planned」です。

共用サーバーでは、さくら・ConoHa WING・ロリポップ・エックスサーバーが、提供しているサポート終了版にも修正を当てたと告知しました。

見逃せないのは、修正を当てた事業者自身が、それに長くは頼れないと認めている点です。ロリポップは今回の対策を「応急的なもの」とし、今後の脆弱性には公式の修正が出ない、もしくは同社で対応できない可能性があるとしました。さくらも、サポート終了版には今回に限らず新たな脆弱性が見つかる可能性があるとして、最新のサポート対象版を勧めています。IPAの事前の注意喚起には、サポート終了の古いPHPを使い続けるウェブサイト・ウェブサービスも見受けられる、との記述がありました。

IPAの本報は、修正対応が難しい場合の進め方を6項目で示しています。

利用中のPHPのサポート状況を確認する：修正が提供されない版なら、サポートのある版への更新か、対策済みの製品・サービスへの移行を検討する。
更新・移行までの暫定対策を講じる：脆弱な状態での運用を放置しない。有効な暫定対策が難しければ、外部からのアクセス遮断やサービスの一時停止が必要か判断する。
システムの状況と更新・移行の難易度を把握する：そのサイトが今も果たしている役割や、他のサービスで代替できる可能性を確かめる。
組織として対応の実現性を検討する：システム管理担当者だけでなく、事業責任者や経営層も含めて、人員・予算・保守体制を確保できるかを見る。
今後の対応方針を決める：体制の見通しが立たなければ、「公開の終了やシステムの廃止も含めて」検討する。
利用者や業務への影響を考慮して実施する：データの移行・保存や、代替手段の案内を計画する。

IPAが「廃止」まで選択肢に入れたことが示すのは、8.1以前の問題が技術だけでは片付かないということです。キャンペーンのために作ったきりの特設サイトなら、5番目の「公開の終了」が現実的な選択肢になり得ます。忘れてはならないのが8.2です。PHP 8.2は2026年12月31日にサポートが終わり、その後はセキュリティ修正が出ません。今回8.2.35にしたサイトも、移行先は年内に決めておく必要があります。

すぐに更新できない間の臨時措置と、その限界

PHP公式は臨時措置を示していますが、その前置きは「the following measures reduce exposure to specific attack paths but do not make an installation safe」。特定の経路への露出を減らすだけで、安全にはならないと本人たちが断っています。

いずれも、php.iniやPHP-FPMの設定を変えられる立場の人が使う手段です。

session.upload_progress.enabled=0：php.ini、FPMのプール、リクエストの解析より前に効くサーバー設定で指定し、全ワーカーを再起動する。ini_set()やFPMの.user.iniには頼らない。確認済みのセッション経路は塞ぐが、他の派生は塞がない。
post_max_sizeを低くする：アップロードが要らないアプリは8M、要るアプリは32M。upload_max_filesizeはpost_max_sizeより小さく保つ。
警告を隠しても効かない：リクエストごとに適用され、初期化の前に診断（警告）を出してしまう無効・非推奨の設定は取り除く。error_reporting、display_errors、@でその診断を隠しても役に立たない、と明記されています。

更新までどうしても時間がかかるなら、IPAの2番目の項目に戻ります。外部からのアクセス遮断や一時停止が必要かの判断です。KAGOYAは該当プランの利用者向けに、public_html直下の.htaccessに次の2行を書いて公開を止める方法を示し、解除するときはこの記述を削除するかコメントアウトするよう添えています。

Order Deny,Allow
Deny from all

更新のあとに、ログで確かめておくこと

更新はこれからの侵入を防ぐものです。それまでに何もなかったかは、別に確かめます。

JPCERT/CCは、発見者の公開情報をもとに、侵害の有無を調べる観点を三つ挙げています。

「過去のHTTPレスポンスにおいて、不自然に長い、または異常な形式の値を含むPHPSESSID Cookieが設定されていないか。」
「不審なmultipart/form-data形式のHTTPリクエストが送信されていないか。また、その前後にPHPのメモリ上限に関連するエラーやHTTP 500エラーが発生していないか。」
「PHPのワーカープロセスが予期せず異常終了したり、頻繁に再起動したりした痕跡がないか。」

痕跡が見つからなくても、攻撃を受けていないとは断定できない。同じ注意喚起はそう断った上で、侵害が疑われる場合はログなどの証拠を保全し、影響範囲の調査やシステムの隔離を行うよう求めています。

調べ始める日付の目安は、二次情報になります。Tenableによれば、Amazon Threat Intelligenceは公開4日前の10月17日、ハニーポットで悪用の試みを観測しました。調査は少なくとも10月17日から始めるよう勧めているといいます（Amazonの原文はこの記事では未確認）。国内では、ロリポップが脆弱性を狙ったとみられるアクセスの試みを確認。それによる不正アクセスや情報漏えいは、告知の時点で確認されていないとのことです。

更新は、検索とAI機能に読まれる土台を守る作業でもある

PHPの更新はサーバーの話に見えますが、AI検索とも地続きです。

Googleは、AI による概要や AI モードでページがサポートリンクとして表示される条件を挙げています。条件は三つ。ページが「インデックスに登録されて」いること、「Google 検索でスニペットが表示され」ること、「検索の技術的要件を満たしている」こと。主なベストプラクティスには「検索ポリシーを遵守すること」が並びます。そのスパムポリシーでは、サイトの脆弱性に付け込まれ、許可なく配置されたコンテンツが「ハッキングされたコンテンツ」です。同じポリシーは、こうして新たに作られたページが検索結果でのサイトのパフォーマンスに悪影響を及ぼすおそれにも触れている。Search Consoleのヘルプは、ハッキングされたコンテンツが検索結果に含まれないよう最善を尽くしている、と説明します。PHPの穴は、サーバーの外では、AI による概要や AI モードが乗っている検索の土台の穴として現れるのです。改ざんの点検と Search Console の「セキュリティの問題」の見方は、前回の記事「PHP2Shell、パッチの次は改ざんの点検」にまとめました。

サイトの担当者が今週やること

対策は一つで、手順は環境の数だけある。迷ったら、早見表に戻ってください。

自社サイトが早見表のどの行かを決め、その行の確認先を開く：共用なら契約している事業者のお知らせページ、VPS・クラウドなら配布元のセキュリティ情報（Ubuntuなら上の1行目の結果）、コンテナなら使っているベースイメージのタグ、委託なら委託先への問い合わせ。
「直った」の証拠を一行で残す：事業者の告知のリンクかパッケージの版、それに再起動した日時。
日本語サイトを預けている海外ブランドの日本の担当者は、委託先に三つの質問を送る：権限を持つ人、更新した日時と版と再起動、8.1以前の修正の出どころ。その答えがそのまま本社への報告になります。
8.1以前と8.2は、移行先と期限を決める：IPAの4番目の項目の通り、担当者だけで抱えず、予算と体制を決める人を入れる。

ご相談先

自社だけでは確認や対応が難しい場合の相談先です。この記事を書いている株式会社MenuMenuが運営する「PHP2Shell 緊急点検」（https://php2shell.jp/ ・ [email protected]）です。対象はrootかsudoの権限があるVPS・専用サーバー・クラウドで、点検は読み取り中心で行い、侵入がないことを保証するものではありません。共用のレンタルサーバーは対象外です。共用サーバーをお使いの場合は、ご契約のホスティング事業者にお問い合わせください。

参考資料

#AI検索最適化#PHP2Shell#脆弱性対応#PHP#レンタルサーバー

日高駿

株式会社MenuMenu 代表取締役

ソフトウェアエンジニアであり、UI・UXデザイナー。2012年からシリコンバレーと韓国でプロダクトをつくってきました。SEO・MEO・AEOの専門家として、訪日観光客と日本のローカルビジネスをつなぐMenuMenuを自ら設計・開発しています。

プロフィールを見る →

「見つかっているか」を、数字で確かめませんか。

AIの答え、検索、地図。どこで見つかっていて、どこで見つかっていないのか。まずはサイトを点検し、現状を数字にしてから次の一手を決められます。

診断をはじめる

ブログ一覧に戻る