年別アーカイブ 2026年6月22日

WordPressでショートコードが表示されず文字列だけ出る時の直し方

WordPressでショートコードが表示されず文字列だけ出る時の直し方

WordPress 7.0 でショートコードが表示されず、角括弧付きの文字列がそのまま画面に出る場合、プラグインの停止・テーマの出力フィルタ不足・ブロックエディタとの相性が主な原因だ。直すにはプラグインの更新や有効化確認から始め、テーマ側で処理されていないときは強制実行のコードを functions.php に追加する。

なぜショートコードが表示されず文字列だけ出るのか

なぜショートコードが表示されず文字列だけ出るのか

ショートコードは [example] のような角括弧で囲まれた短い文字列で、WordPress が表示の瞬間に対応する PHP 処理や HTML に置き換える仕組みだ。この置き換えが行われず、角括弧付きのまま表示される場合、大きく分けて三つの原因が考えられる。

原因1 ショートコードを登録しているプラグインが停止している

プラグインが無効化されているか、WordPress 7.0 への更新後に互換性の問題で停止しているケースが最も多い。更新直後にサイトが「このサイトで重大なエラーが発生しました」という表示になった場合、WordPress は自動で問題のプラグインを停止する。この自動停止によってショートコードの登録処理が丸ごと抜け落ち、文字列だけが残る。

また、プラグインは有効に見えても、特定のページタイプ(固定ページ・投稿・カスタム投稿タイプ)で意図的にショートコードの置換を制限している設計もある。管理画面のプラグイン一覧で有効化状態を確認しても原因がわからないときは、プラグインの内部ロジックまで疑う必要がある。

原因2 テーマが本文中のショートコードを処理していない

ショートコードの置換は do_shortcode() という関数を通じて実行される。WordPress の標準ループやウィジェットエリアでは自動で処理されるが、テーマがカスタマイズされたテンプレートで直接 get_post_meta() や the_content() を独自に加工している場合、この関数が呼ばれずショートコードが展開されない。とくに自作テーマや子テーマでカスタムフィールドの値を表示する箇所で起きやすい。

原因3 ブロックエディタの「ショートコードブロック」未使用

WordPress のブロックエディタ(Gutenberg)でショートコードを機能させるには、専用の「ショートコード」ブロックの中に記述する必要がある。段落ブロックや見出しブロックに直接 [example] と打ち込んだ場合、ブロックの保存・出力の仕様によってはテキストとしてそのまま表示されることがある。クラシックエディタに慣れていると見落としがちなポイントだ。

ショートコードが表示されないときの原因3分類
原因 A プラグインが無効化または停止している
↓
原因 B テーマが do_shortcode() を呼んでいない
↓
原因 C ブロックエディタでショートコードブロックを使っていない
■ プラグイン停止 ■ テーマ側の処理不足 ■ ブロック種別の選択ミス

上図の三方向から原因を絞り込めば、ほとんどのケースで該当箇所が見つかる。次項からは実際の対処手順を具体的に解説する。

ショートコードが機能しないときの具体的な対処手順

ショートコードが機能しないときの具体的な対処手順

手順1 プラグインの有効化と更新を確認する

管理画面の「プラグイン」→「インストール済みプラグイン」を開き、該当プラグインが有効化されているかを確認する。無効化されていれば「有効化」をクリックするだけで解決することが多い。有効化されているのに直らない場合は、プラグインの最新バージョンがリリースされていないか更新画面を確認する。WordPress 7.0 へのメジャーアップデート直後は、プラグイン開発者が緊急の互換性アップデートを出している可能性が高い。

管理画面にアクセスできないほどサイトが壊れている場合は、WordPress の「リカバリモード」を利用する。サイトで致命的エラーが発生すると、管理者メールアドレス宛に「このサイトで重大なエラーが発生しました」という件名のメールが届き、その中にリカバリモード用の特別なログインリンクが記載されている。このリンクからログインすると、問題のプラグインだけが停止した状態で管理画面に入れる。

手順2 テーマ側で do_shortcode() を明示的に実行する

プラグインが正常に動作しているのにショートコードが展開されない場合、テーマのテンプレートが原因だ。該当のショートコードを表示したい箇所がカスタムフィールドやウィジェットエリア内であれば、テンプレートファイル内の出力部分に do_shortcode() を追加する。

// カスタムフィールドの値をショートコード展開して出力
echo do_shortcode( get_post_meta( get_the_ID(), 'my_custom_field', true ) );

// 本文中のショートコードを意図的に再実行(通常は不要だが保険として)
echo do_shortcode( get_the_content() );

上記は functions.php ではなく、該当のテンプレート(single.php や page.php など)の出力箇所に追記するコードだ。子テーマを使っていない場合は必ず子テーマを用意してから編集し、テーマのアップデートで変更が失われないようにする。子テーマの作り方は後述の FAQ で扱う。

手順3 ブロックエディタで「ショートコード」ブロックを使う

ブロックエディタでページを編集している場合、ブロック挿入ツール(+ボタン)から「ショートコード」ブロックを検索して追加する。既存の段落ブロックに直接ショートコードを打ち込んでいる場合は、そのブロックを削除して新しくショートコードブロックを追加し、中にショートコード文字列だけを入力する。

STEP 1 ブロック挿入ツール(+)をクリック
↓
STEP 2 「ショートコード」ブロックを検索して追加
↓
STEP 3 ブロック内にショートコード(例: [example])を入力
↓
STEP 4 プレビューまたは公開して表示を確認

この手順でブロックエディタ上の問題は解決するが、テーマ側の出力処理に起因する問題はこれだけでは直らない。手順2も併せて確認するのが確実だ。

WordPress 7.0 特有の注意点と想定外のエラーへの備え

WordPress 7.0 特有の注意点と想定外のエラーへの備え

WordPress 7.0 は内部のエラーハンドリングが強化され、従来は警告レベルで済んでいた処理が致命的エラーとして扱われるケースが増えている。プラグインが最新でも、内部の非推奨関数の呼び出しや PHP バージョンとの不一致があると、サイト全体がダウンし管理画面からも締め出される。

こうした状況では、FTP またはサーバーのファイルマネージャーで /wp-content/plugins/問題のプラグインフォルダ/ を一時的にリネームする方法が最も確実な緊急回避策になる。フォルダ名を「custom-profile-picture」から「custom-profile-picture_temp」などに変更すれば、WordPress はそのプラグインを検出できなくなり、サイトが正常に表示される状態まで復帰する。その後、プラグインの互換性情報を確認してから正式な対処を取る。

よくある質問

ショートコードを使うプラグインをアップデートしたらサイトが真っ白になった

WordPress 7.0 とプラグインの互換性が取れていない可能性が高い。リカバリモードのリンクがメールで届いていればそこからログインし、問題のプラグインを停止する。メールが届いていない場合は FTP で対象プラグインのフォルダをリネームし、管理画面にアクセスできる状態に戻してから代替プラグインを検討する。

子テーマの functions.php に追記する方法がわからない

子テーマとは、親テーマの機能を引き継ぎつつ安全にカスタマイズするための仕組みだ。まず親テーマと同じディレクトリに子テーマ用フォルダを作成し、style.css と functions.php の2ファイルを設置する。functions.php には親テーマのスタイルを読み込むコードと、do_shortcode() を含むカスタマイズコードを記述する。詳細な手順は WordPress 公式の子テーマ作成ガイドが役立つ。

ショートコードブロックを使っても特定のページだけ表示されない

キャッシュ系プラグインや CDN が原因のことが多い。キャッシュを全削除し、CDN を使用している場合は一時的に開発モードにしてから表示を確認する。また、該当ページがカスタム投稿タイプで、テンプレートが専用の出力処理をしている場合も同様に do_shortcode() の追加が必要になる。

プラグインを更新したが問題が再発した

更新で一度直っても、WordPress の自動エラーハンドリングが再度働いて同じプラグインを停止することがある。サーバーのエラーログを確認し、PHP のメモリ不足や実行時間制限が原因であれば、wp-config.php で WP_MEMORY_LIMIT を 256M 以上に設定する。根本的にはプラグイン開発者の対応を待つ必要があるケースもある。

この記事のポイント

  • ショートコードが文字列のまま表示される主因はプラグイン停止・テーマの処理不足・ブロック選択ミスの3つ
  • 管理画面に入れない場合はリカバリモードか FTP でプラグインフォルダをリネームして復旧させる
  • テーマ側で do_shortcode() が呼ばれていない箇所は子テーマのテンプレートに追記する
  • ブロックエディタでは必ず「ショートコード」専用ブロックの中に記述する
  • WordPress 7.0 はエラーハンドリングが強化され互換性問題が表面化しやすい
Prop For That、CSSで動的プロパティを扱う新ライブラリの全容

Prop For That、CSSで動的プロパティを扱う新ライブラリの全容

CSS-Tricksで紹介された「Prop For That」は、これまでのCSS設計の常識を塗り替える可能性を持つライブラリだ。ブラウザが本来CSS単体では取得できない情報、例えばマウスカーソルの座標やページのスクロール速度、現在時刻などを、あたかもネイティブのカスタムプロパティであるかのように扱えるようにする。開発者はライブラリを読み込み、対象のHTML要素に専用のデータ属性を付与するだけで、これらの動的な値を直接スタイルシートから参照できる。

CSS-Tricksの記事によれば、このライブラリの最大の魅力は、JavaScriptのロジックを意識せずに済む点にある。従来はイベントリスナーで値の変化を監視し、DOMのスタイルを逐次更新するスクリプトが必要だった。Prop For Thatを使えば、宣言的にCSSを記述する感覚のまま、高度なインタラクションを実装できる。本記事では、この新しいアプローチの仕組みや具体的な活用方法、そして現場への影響を掘り下げていく。

Prop For Thatが解決する根本的な課題

Prop For Thatが解決する根本的な課題

CSSは本来、ページが読み込まれた時点の静的なスタイルを定義する仕組みであり、ユーザーの操作に応じて刻一刻と変化するブラウザの内部状態を直接知覚できない。マウスポインターの位置、ページのどこまでスクロールしたか、特定のフォーム要素が今フォーカスを持っているかといった情報は、すべてJavaScriptの領分だった。この断絶が、アニメーションやインタラクションを実装する際のボトルネックになっていた。

従来のアプローチ(Before)
JavaScriptでイベントを監視し、スタイルを都度書き換える必要があった
開発者 JSで状態取得 → DOMのstyleプロパティ書き換え
課題ロジックとスタイルの分離が難しく、コードの見通しが悪くなる
↓
Prop For Thatのアプローチ(After)
HTML属性を付与するだけで、CSSカスタムプロパティとして値を参照できる
開発者 data-props-for属性を付与 → Prop For That CSS変数を自動更新
効果スタイルシート内で完結し、コードの凝集度が高まる

このデモが示すように、Prop For ThatはHTMLとCSSだけの世界観を維持したまま、動的な値を扱える設計思想を持つ。これは単なるユーティリティの追加ではなく、スタイリングの責務をCSSに取り戻すパラダイムシフトだ。

主要なライブプロパティとその仕組み

ポインタートラッキングで実現する追従型インタラクション

マウスカーソルの動きをCSSだけで捉えられると、ボタンのホバーエフェクトや視差効果の表現力が格段に上がる。Prop For Thatでは、data-props-for="pointer"という属性を設定した要素に対して、--live-pointer-xと--live-pointer-yという2つのカスタムプロパティが動的に注入される。

<div class="mover" data-props-for="pointer">...</div>
ポインター追従の概念
data-props-for=”pointer” → –live-pointer-x –live-pointer-y
使用例 要素の位置をカーソルに追従させる
left: calc(var(--live-pointer-x, 0) * 1px);
top: calc(var(--live-pointer-y, 0) * 1px);

これらの値はリアルタイムに更新されるため、要素をposition: absoluteで配置しておけば、CSSの計算式だけで物体がカーソルを追いかける動きを表現できる。マウスの速度に応じてスタイルを変化させるなど、従来は複雑なスクリプトが必要だった演出が、数行のスタイル宣言で完結する。

スクロールベロシティと現在時刻の活用

スクロールの勢いを表すベロシティ(速度)や、刻々と変化する現在時刻も、ライブプロパティとして取得できる。これらを活用すれば、ユーザーがページを勢いよくスクロールしているときだけ特定のアニメーションを発動させたり、時刻に応じて配色を動的に切り替えるといった演出が、CSSの範囲内で実装可能になる。

/* スクロール速度に応じて要素の透明度を変化させる例 */
.scroll-aware {
  opacity: calc(var(--live-scroll-velocity, 0) * 0.01);
  transition: opacity 0.3s ease;
}
スクロールベロシティ
–live-scroll-velocity → スクロールの勢い(px/frame)
用途勢いのあるスクロール時だけ要素を強調表示する
現在時刻
–live-time-seconds → 秒単位の現在時刻
用途時間帯に応じたダークモードへの自動切り替え

CSS-Tricksの記事で特に評価されていたのは、スクロールにモメンタム(慣性)の概念を持ち込める点だ。ユーザーの操作に物理的な手応えを感じさせる、いわゆる「気持ちいいインタラクション」の実装ハードルが大きく下がる。

実装のポイントとコード例

実装のポイントとコード例

基本的なセットアップ手順

導入は極めてシンプルだ。ライブラリをプロジェクトに読み込んだあと、動的な値を取得したい要素にdata-props-for属性を追加する。あとは通常のCSSカスタムプロパティと同じ感覚で、var()関数を使って値を参照すればよい。

<!-- HTML側 -->
<div class="tracker" data-props-for="pointer">
  この要素がカーソルを追跡する
</div>

/* CSS側 */
.tracker {
  position: absolute;
  width: 60px;
  height: 60px;
  background: #3498db;
  border-radius: 50%;

  /* ライブプロパティを参照して位置を動的に計算 */
  left: calc(var(--live-pointer-x, 0) * 1px - 30px);
  top: calc(var(--live-pointer-y, 0) * 1px - 30px);

  /* スムーズな追従のためのトランジション */
  transition: left 0.1s ease-out, top 0.1s ease-out;
}
設定フロー(After)
STEP 1 ライブラリをimportする
↓
STEP 2 HTML要素にdata-props-for属性を追加
↓
STEP 3 CSSでvar()を使ってライブプロパティを参照

このコード例では、カーソルを追いかける円形の要素を定義している。注意すべきは、var()の第2引数でフォールバック値(ここでは0)を指定している点だ。ライブラリが読み込まれる前や、何らかの理由でプロパティが未定義の場合でも、要素が想定外の位置に飛ぶのを防げる。

パフォーマンス上の配慮

ライブプロパティは高頻度で更新されるため、leftやtopのようなレイアウトを再計算させるプロパティの変更は、パフォーマンスの観点から注意が必要だ。可能であればtransformプロパティで位置を制御するほうが、ブラウザの合成処理に乗り、再描画コストを抑えられる。

/* パフォーマンスを考慮した書き方 */
.optimized-tracker {
  position: absolute;
  width: 60px;
  height: 60px;
  background: #e74c3c;
  border-radius: 50%;

  /* transformを使えばGPU合成で高速に描画される */
  transform: translate(
    calc(var(--live-pointer-x, 0) * 1px - 50%),
    calc(var(--live-pointer-y, 0) * 1px - 50%)
  );
}

このtransformによる制御は、特に多数の要素を同時に動かす場合や、モバイル端末での動作を考慮する際に有効だ。CSS-Tricksの紹介するデモ群でも、このベストプラクティスが採用されている。

Web制作の現場に与える影響

Web制作の現場に与える影響

JavaScriptとCSSの新たな役割分担

Prop For Thatの登場は、フロントエンド開発におけるJavaScriptとCSSの役割分担を見直す契機になる。従来は「動的なものはJavaScript、静的なものはCSS」という暗黙の線引きがあった。しかし、このライブラリが示す方向性は、表示やスタイルの変化はCSSに寄せるという考え方だ。

従来の役割分担(Before)
JavaScript 動的なスタイル変更を一手に担う
CSS 静的なスタイル定義のみ
↓
これからの役割分担(After)
JavaScript データの取得や状態管理に専念
CSS 動的なスタイル変更も含めて表示の責務を担当

これは単なる書き方の変化ではない。コードの凝集度が高まり、スタイルに関するロジックがCSSファイルに集約されることで、メンテナンス性が向上する。特に、複数人で開発する大規模プロジェクトや、インタラクションの多いランディングページの制作では、このメリットが顕著に現れる。

プロトタイピングスピードの加速

CSS-Tricksの記事が高く評価していたもう一つの側面は、プロトタイピングの速さだ。アイデアを思いついてから、実際にブラウザ上で動くモックアップを作るまでの時間が大幅に短縮される。複雑なJavaScriptの設定なしに、HTMLとCSSだけでリッチなインタラクションを試せることは、クリエイティブな探求の敷居を大きく下げる。

この手軽さは、デザイナーがコーディングに踏み出すきっかけとしても機能するだろう。また、クライアントワークの現場では、「この動きを実装するのにどれだけの工数がかかるか」という見積もりの精度も変わってくる。これまでスクリプトの作成で1日かかっていた表現が、数時間のコーディングで実現できる可能性があるからだ。

この記事のポイント

  • Prop For Thatは、マウス位置やスクロール速度などブラウザの動的情報をCSSカスタムプロパティとして参照できるライブラリである
  • 導入はライブラリの読み込みとHTML属性の追加のみで、JavaScriptの記述を必要としない
  • ポインタートラッキング、スクロールベロシティ、現在時刻など、多彩なライブプロパティが用意されている
  • パフォーマンスを考慮する場合は、leftやtopではなくtransformで位置制御するのが推奨される
  • JavaScriptとCSSの役割分担を見直し、スタイルの責務をCSSに集約する設計思想が背景にある
  • プロトタイピングの高速化や、インタラクション実装の工数削減といった実務的なメリットが大きい
WP All Importで物件画像が混ざる原因とファイル名の一意化による解決方法

WP All Importで物件画像が混ざる原因とファイル名の一意化による解決方法

WP All Import で物件情報をインポートした際、他の物件の画像が表示される不具合は、画像ファイル名の重複と画像マッチング設定の不備が主な原因だ。この問題は、WP All Import のファイル名指定で一意の名前を生成し、画像マッチングルールを適切に設定することで解決できる。

WP All Import でインポートした画像が混ざる原因は何か

WP All Import でインポートした画像が混ざる原因は何か

WP All Import は XML フィードから画像をダウンロードし、メディアライブラリに追加する。ここで「すでに同じファイル名の画像がメディアライブラリに存在する」と、意図せず既存の画像を参照してしまうことがある。特に検索やマッチングをすべてオフにしていても、ファイル名の衝突が発生すると新規ダウンロードをスキップして既存画像にリンクを張る挙動が起こりうる。これが、異なる物件で同じ画像が表示される最大の原因だ。

もう一つの原因は、Houzez テーマやそのアドオンがインポート後に画像ギャラリーを再構築する際、メディアライブラリ内の添付ファイルの親子関係やメタデータを誤って上書きしてしまうケースだ。プレビュー段階では正しいのに、インポート完了後に別の物件の画像に差し替わるのは、インポート後のテーマ側の処理タイミングで画像の紐付けがずれるために起こる。

画像ファイル名を一意にして他物件との画像混入を防ぐ方法

画像ファイル名を一意にして他物件との画像混入を防ぐ方法

WP All Import では、インポートテンプレートの「画像」セクションで、保存時のファイル名をカスタマイズできる。ここで物件ごとに絶対に重複しない名前を付けるのが最も確実な対策だ。具体的には、物件 ID や MLS 番号、住所の一部など、XML 内のユニークな要素をファイル名に組み込む。

Before 重複しやすい設定
ファイル名指定 {filename}.jpg
↓ XML に「1.jpg」「1.jpg」… 重複発生
↓
After 一意になる設定
ファイル名指定 {mls_id[1]}_{typename[1]}_{index}.jpg
↓ 物件ごとに絶対衝突しない
■ 重複危険 ■ 一意保証

上のデモのように、{mls_id} や {property_id} といった絶対に重複しないフィールドをファイル名に含める。インポート時に「既存画像を保持」の設定をオフにしていても、ファイル名が重複すると WordPress 本体側で「ファイル名-1」「ファイル名-2」のように連番サフィックスが付与されることがあり、このサフィックス付きファイル名を Houzez アドオンが正しく追跡できない場合もある。ファイル名の段階で完全にユニークにしておけば、そのリスクも回避できる。

WP All Import の画像マッチング設定を適切に構成する

WP All Import の画像マッチング設定を適切に構成する

現在「すべてオフ」の状態は、一見すると毎回新規ダウンロードされそうに見えるが、実際にはファイル名の重複や WordPress の内部キャッシュによって想定外のマッチが起こりうる。以下の設定を見直す。

画像 URL またはファイル名でのマッチを有効にする

「Match image by URL」をオンにすると、WP All Import は XML 内の画像 URL とメディアライブラリ内の元 URL メタデータを照合し、すでに同じ URL からダウンロードされた画像があれば再利用し、なければ新規ダウンロードするという明確な挙動になる。「すべてオフ」よりも意図が明確で、混入が防ぎやすい。

Search Media Library for existing images の使い所

この設定は、ファイル名やタイトルで既存画像を検索する。ファイル名が重複しがちな構成ではオフのままが安全だが、ファイル名を一意にしたうえでオンにすれば、再インポート時の二重ダウンロードを防ぎつつ正確にマッチできる。画像ファイル名の一意化が完了しているなら、ここをオンにして「既存画像の検索」に任せるのも選択肢になる。

First image set as Featured Image の副作用に注意する

この設定がオンの場合、WP All Import と Houzez アドオンがそれぞれ「アイキャッチ画像」を設定しようとして、2つの処理が干渉することがある。画像の入れ替わりが激しいなら、いったんこの設定をオフにして、Houzez アドオン側にアイキャッチ設定を任せてみる。それで安定するなら、アドオン側の処理が優先される構成に統一する。

Houzez アドオンとテーマ側の画像処理を確認する

Houzez アドオンとテーマ側の画像処理を確認する

Houzez アドオンはインポート後に物件ギャラリーやアイキャッチ画像を再構成する独自の処理を行う。この処理が WP All Import のメディアライブラリ操作と競合し、別の物件の画像を拾ってしまうことがある。特に再インポート時に、アドオンが「物件に紐づく既存画像」を誤ったロジックで上書きするパターンが報告されている。

アドオンの画像処理フックを一時停止して検証する

子テーマの functions.php に以下のコードを一時的に追加し、Houzez アドオンの画像処理をスキップしてインポート結果が正しくなるかテストする(テスト後は必ず削除する)。

// テスト用 インポート後の Houzez 画像処理を無効化
add_action('init', function() {
    if (class_exists('Houzez_Property_Feed')) {
        remove_all_actions('pmxi_after_xml_import');
        remove_all_actions('pmxi_saved_post');
    }
}, 99);

これで画像の混入が止まるなら、Houzez アドオン側の処理が原因だ。その場合、アドオンの最新バージョンへのアップデート、または Houzez 公式サポートに「WP All Import インポート後の画像上書き」の修正を依頼する。アドオンのバージョンが古いと、WP All Import の最新 API との互換性が崩れていることがある。

再インポート前にメディアライブラリの紐付けをリセットする

WP All Import で「既存の投稿を更新」する形で再インポートする場合、過去のインポートで作られたメディアの紐付け(post_parent やメタデータ)が残っていると、新しい画像が正しく割り当てられない。この場合は、一度該当の物件投稿と画像の紐付けを手動で外すか、WP All Import 実行前に該当物件の画像をメディアライブラリから削除してから再インポートすると、クリーンな状態で画像が再構築される。

Amazon S3 Offload 使用時の画像混入を防ぐ

Amazon S3 Offload 使用時の画像混入を防ぐ

Amazon S3 Offload(WP Offload Media 等)を使用している場合、メディアライブラリの画像実体は S3 に移動され、ローカルにはメタデータだけが残る。この状態で WP All Import が「同じファイル名」の画像を処理しようとすると、S3 上の URL とメディアライブラリのメタデータに不整合が生じ、参照がずれることがある。

S3 Offload の URL 書き換えタイミングを確認する

WP Offload Media はアップロード後に URL を書き換えるが、このタイミングが WP All Import のインポート後処理や Houzez アドオンのギャラリー構築タイミングと重なると、書き換え前のローカル URL が一時的に保存されてしまう。S3 Offload プラグインが「非同期処理」や「スケジュール処理」で URL を更新する設定になっているなら、同期処理に切り替えて、インポート完了までにすべての URL が書き換わるようにする。

インポート中は S3 Offload を一時停止する

大量インポート時は、WP Offload Media のアップロードフックを一時的に停止して、WP All Import のインポートが完全に終わったあとに手動で一括オフロードする方法も有効だ。インポートスクリプトの先頭でオフロードを無効化し、完了後に再有効化するワークフローにすると、混入リスクをほぼゼロにできる。

よくある質問

Preview では正しいのに本番インポートで画像が混ざるのはなぜか

Preview は実際のダウンロードとメディアライブラリ登録をスキップし、XML の URL だけを表示する仕組みだ。本番インポートではメディアライブラリへの保存が行われ、このときにファイル名衝突やテーマの後処理が発動して画像が入れ替わる。この違いが「Preview では正しいのに本番で壊れる」現象の正体だ。

画像が混ざった物件を一括で修正できるか

WP All Import の「既存の投稿を更新」機能を使い、画像フィールドだけを再インポートすることで一括修正できる。その際、ファイル名の一意化とマッチング設定の見直しを事前に済ませておく必要がある。メディアライブラリに重複画像が大量にある場合は、一度不要画像を一括削除してから再インポートすると確実だ。

Houzez テーマ以外でも同じ問題は起こるか

起こる。WP All Import とテーマ付属の独自インポートアドオンが競合する構図は、不動産テーマ(HomePress、RealHomes 等)や EC(WooCommerce の WP All Import アドオン)でも報告されている。基本的な対策であるファイル名の一意化とマッチング設定の見直しは、どのテーマでも有効だ。

画像 URL にクエリパラメータが付いている場合の注意点はあるか

URL の末尾に ?w=800&h=600 のようなパラメータが付いていると、WP All Import が「別の画像」として認識せず、パラメータ部分を無視してファイル名を生成するため重複が起きやすい。URL マッチングを使用する場合も、パラメータ除去後のベース URL で照合されるため、意図したマッチが働かないことがある。可能なら XML 側でクエリパラメータのないクリーンな URL を用意するのが望ましい。

メディアライブラリの画像が増えすぎないか心配だ

ファイル名の一意化と画像 URL マッチングを適切に設定すれば、同じ URL の画像はメディアライブラリに一度だけ保存されて再利用される。重複ダウンロードが起きていたのは、ファイル名衝突によって新規保存と既存参照が混在していたためで、設定を見直せばメディアライブラリの肥大化も抑えられる。

この記事のポイント

  • 画像混入の主因はファイル名重複とマッチング設定の不備
  • XML 内のユニーク ID をファイル名に組み込む
  • 画像 URL マッチングをオンにして明確な挙動にする
  • Houzez アドオンの画像処理競合はフック停止で検証
  • S3 Offload 使用時は同期処理への切り替えが安全
AI引用シェア率をBingが公開、llms.txtの効果に疑問符

AI引用シェア率をBingが公開、llms.txtの効果に疑問符

AI検索の可視性をどう測るか、そして構造化データファイルにどこまで期待すべきか。この一週間でその答えに直結する動きが複数出てきた。

MicrosoftがAI引用のシェア率を計測する新機能を公開し、GoogleとAhrefsのデータはllms.txtの効果に冷や水を浴びせた。さらにAIエージェント向けの新仕様が2つ登場するなど、情報が一気に動いている。英国CMAによる公正ランキング命令も含め、今週のトップ4ニュースを実務視点で整理する。

BingがAI引用シェア率を公開。競合との差が初めて数値化された

BingがAI引用シェア率を公開。競合との差が初めて数値化された

MicrosoftはBing Webmaster ToolsのAIパフォーマンスダッシュボードに、新たな4機能をプレビュー公開した。追加されたのは「Citation Share(引用シェア率)」「Intents(検索意図別グループ)」「Topics(トピック別グループ)」「Compare(期間比較)」だ。いずれも現在はプレビュー段階でグローバルに順次ロールアウトされている。

従来のAI検索パフォーマンス計測(Before)
自サイトの引用有無だけを把握
競合の引用状況は見えない
市場全体での立ち位置が不明
↓
新しいAI Citation Shareの世界(After)
特定クエリでの自サイトの引用シェア率を数値化
競合他社とのシェア比較が可能
市場全体の何%を獲得しているかが可視化される

このCitation Shareによって、AI検索結果における自サイトの存在感が、競合との比較で初めて把握できるようになる。ただしこのデータはBing独自であり、CopilotやBingの回答を対象とする。Google検索側では検索コンソールにこれに相当する引用カウント機能は提供されていない。

SEO担当者の受け止めと実務への示唆

ILoveSEO.netの創業者Gianluca Fiorelli氏はLinkedInで「Bing Webmaster Toolsこそ、我々がGoogleサーチコンソールに望んでいた姿だ」と評価した。AI可視性を測る新しい物差しが登場したことは、今後の施策優先度をデータドリブンに決める上で大きい。

現時点ではBingに限られた指標だが、AI検索のトラフィックが今後さらに一般化すれば、Googleも類似の指標を導入せざるを得なくなる可能性がある。先行してBing側でのデータ取得と分析のノウハウを積んでおくことは、将来のAI検索対策で優位に立つ一手になる。

llms.txtへの期待に新データが疑問符。97%がアクセスゼロ

llms.txtへの期待に新データが疑問符。97%がアクセスゼロ

llms.txtは、大規模言語モデル(LLM)向けにサイト情報を構造化して提供するテキストファイルだ。AIがサイト内容を理解しやすくする目的で提唱され、導入が進んでいる。しかし今週、その効果に疑念を投げかける材料が二つ重なった。

GoogleのJohn Mueller氏の指摘
llms.txtは 自己申告 のファイルであり
サイトの発見・差別化には寄与しない
※本当に重要なのは通常のHTMLと内部リンク構造
↓
Ahrefsの大規模調査データ
13万7000ドメインを分析
97%のllms.txtファイルがリクエストゼロ
※ChatGPTやPerplexityなど引用生成ボットからのアクセスは全体のわずか1%
■ 理論的な課題  ■ 実データによる検証

Mueller氏は「Search Off the Record」ポッドキャストで、llms.txtが自己申告型のファイルである以上、LLMがサイトを発見したり他サイトと比較して評価したりする用途には使えないと明言した。本質的に重要なのは従来のHTMLと内部リンク構造だという立場だ。

Ahrefsのデータも同じ方向を指している。13万7000ドメインのうち、97%のllms.txtファイルには一度もボットからのアクセスがなかった。さらにアクセスが確認されたケースでも、ChatGPTやPerplexityといった引用生成ボットからのリクエストは全体の1%に過ぎない。この結果は、数ヶ月前にSE Rankingが30万ドメインを調査して導いた「llms.txtはAI引用に明確な効果を示さない」という結論とも整合する。

SEO専門家の見解と実務上の落とし所

Clio Websitesの創業者Nat Miletic氏はLinkedInで「llms.txtは公開コストが低いので置いておくのは構わない。ただしそれでAI可視性が上がるとは今は期待しないほうがいい」と総括した。コーディングエージェントや学習用クローラー向けに一部で参照されているため維持コストに見合う面はあるが、AI検索結果への表示を目的とした投資としては優先度を下げる判断が妥当だ。

AIエージェント向け新仕様が2つ登場。OKFとARDの注目点

AIエージェント向け新仕様が2つ登場。OKFとARDの注目点

Google Cloudは「OKF(Open Knowledge Format)」を公開した。組織内の知識(データセット、メトリクス、運用手順書など)をAIエージェントが読めるマークダウン形式でパッケージングする仕様だ。ほぼ同時期に、GoogleやMicrosoft、GitHub、Hugging Faceを含む連合が「ARD(Agentic Resource Discovery)」の草案を発表した。こちらはAIエージェントがツールやスキル、他のエージェントを発見・検証するためのプロトコルを定義する。

OKF
Open Knowledge Format
v0.1
組織知識のパッケージ化が目的
ARD
Agentic Resource Discovery
v0.9
エージェント間の発見・検証が目的
⚠️ 共通する課題
どちらも自ドメインに構造化ファイルを配置する方式であり、llms.txtが直面したのと同じ「採用されるかどうか」という不確実性を抱えている
■ OKF  ■ ARD  ⚠️ 共通のリスク

両仕様とも現時点で即時の対応を求めるものではない。OKFはバージョン0.1、ARDは0.9と初期段階だ。Harton Worksの創業者Martin Jeffrey氏はARDを「ページではなく機能のためのサイトマップが再来したようなものだ」と表現した。Snippet Digitalの共同創業者Suganthan Mohanadasan氏は「魔法のキノコではない。これで一夜にしてAI可視性が上がるわけではない」と期待値を引き締めている。

実務的には、どのフォーマットが実際に普及するかを見極める観察期間に入る。llms.txtの事例が示すように、仕様の存在と実際の効果は別問題だ。導入判断は普及の兆候を確認してからでも遅くない。

英国CMAがGoogleに公正ランキングを命令。事前通知義務が実務に波及

英国CMAがGoogleに公正ランキングを命令。事前通知義務が実務に波及

英国の競争市場庁(CMA)がGoogle検索に対し、新たなルールを設定した。オーガニック検索結果のランキングに客観的かつ非差別的な基準を使うこと、そして大規模な変更の際には事前通知を行うことを義務づける内容だ。

CMAがGoogleに求める2つの柱
要件1 公正ランキング
客観的かつ非差別的な基準で順位を決定
大規模変更前の事前通知を義務化
ランキングに関する異議申し立てルートを提供
要件2 データポータビリティの義務化
従来自主的だったデータ持ち出しツールを法的義務に格上げ
実務への具体的な影響
これまで コアアップデートは突如発表
これから 事前通知と異議申し立ての余地

このルールの適用範囲は英国のオーガニック検索結果で、AI Overviewsも対象に含まれる(広告は除く)。Googleは「現行のランキングはすでに公正かつ透明だ」と反論しているが、CMAは6月初旬にもAI検索機能からのオプトアウトを認めるよう命令しており、規制圧力は強まっている。

SEO専門家の反応から読む今後の展開

Searchpediaの創業者Laura Iancu氏はLinkedInで「もうこれで『コアアップデートを突然リリースしました』なんてことはできなくなる」と単刀直入に表現した。Blue Arrayの戦略SEO責任者Chloe Smith氏は「Googleは何らかの回避策を探るだろう」と予測しつつも、事前通知と異議申し立ての枠組みができたこと自体に意味があると見ている。

現状では英国限定の措置だが、EUや他の地域にも波及する可能性は否定できない。特に、大規模アップデートの事前通知が実務化すれば、SEO施策の計画立案や緊急対応のあり方そのものが変わる。今後のGoogleの実装方法を注視する必要がある。

構造化ファイルを置くだけでは済まない。AI可視性の本質に立ち返る

構造化ファイルを置くだけでは済まない。AI可視性の本質に立ち返る

今週のニュースを横断して浮かび上がるテーマは、「構造化ファイルを自ドメインに置いておけばAIに見つけてもらえる」という発想への再考だ。llms.txtはその教訓をすでに示している。ファイルを公開しても、Googleはサイト差別化に寄与しないと断言し、データは大半のファイルが読まれていない事実を突きつけた。

本質的なAI最適化とは
AIが参照するのは結局、通常のHTMLコンテンツと内部リンク構造
構造化ファイルは補助的な役割に留まり、それ単体での効果は限定的
※llms.txtの97%アクセスゼロが証明している
↓
これからの実務アプローチ
Step 1 まずは自サイトの情報設計とコンテンツ品質を徹底的に強化
Step 2 AI引用シェア率で自サイトの立ち位置を客観的に把握
Step 3 OKFやARDは普及後に導入判断。今は動向観察で十分

OKFやARDが登場したことで、構造化ファイルへの要求はこれからも繰り返されるだろう。しかし破綻しているのは「ファイルを置けば報われる」という期待のほうだ。BingのCitation Shareは、そうした取り組みが実際に引用に結びついているかを数値で示してくれる、貴重なフィードバックループになり得る。

AI検索時代の可視性は、小手先のファイル配置ではなく、コンテンツそのものの強さと、信頼される情報源としてサイト全体を設計し続ける積み重ねで決まる。今週のデータと専門家の声は、その原則を改めて強調する結果になった。

この記事のポイント

  • Bing Webmaster Toolsの新機能「AI Citation Share」で、AI検索での競合とのシェア比較が初めて可能になった。Googleにはまだ同等機能はない
  • llms.txtは97%がアクセスゼロ。AI検索可視性への効果はデータで否定され、自己申告ファイルの限界が明確になった
  • OKFとARDという新たなAIエージェント向け仕様が登場したが、普及は未知数。llms.txtの教訓を踏まえ導入判断は慎重に行うべきだ
  • 英国CMAがGoogleに対し、検索順位の公正化と大規模変更前の事前通知を義務づけた。SEO施策の計画立案に影響する可能性がある
  • 結局、AI可視性の本質は構造化ファイルではなく、通常のHTMLコンテンツの品質と情報設計にある
WP Extendedのスニペット一覧が真っ白になった時のファイル復旧方法

WP Extendedのスニペット一覧が真っ白になった時のファイル復旧方法

WP Extended の管理画面でコードスニペットの一覧が突然真っ白になり、まったくアクセスできなくなっても、作成したスニペット本体はサーバー上に PHP ファイルとして残っている。慌てずに /wp-content/wpextended-snippets ディレクトリを開き、必要なコードを取り出せばよい。本記事ではファイルの所在確認からコードの復旧、別環境への移し替えまでを具体的に示す。

なぜ WP Extended のスニペット一覧が表示されなくなったのか

なぜ WP Extended のスニペット一覧が表示されなくなったのか

WP Extended のようなコードスニペット管理プラグインで一覧画面が機能しなくなる原因は、プラグイン自体の不具合というより、特定の環境下での PHP エラーやデータベースの不整合によるところが大きい。特に有効化したスニペットに文法エラーがあると、管理画面全体が「このサイトで重大なエラーが発生しました」といった真っ白な画面に陥るケースもある。実際の管理画面が表示されなくなった時の典型的な引き金は次のとおりだ。

  • 直前に有効化したスニペット内の PHP コードに誤りがある
  • プラグイン本体の更新と WordPress 本体または PHP バージョンとの相性問題
  • 他のプラグインとの競合で管理画面の読み込みが途中で止まる
  • サーバーのメモリ制限やファイル権限の問題でスニペットディレクトリを読み取れない

いずれにしても、スニペット一覧が見えなくなったからといって、作成したコードが消えたわけではない。WP Extended は各スニペットを wp-content ディレクトリ内に実ファイルとして保存しているため、管理画面が動作しなくてもサーバー側から直接回収できる。

スニペットの実体はどこに保存されているのか

スニペットの実体はどこに保存されているのか

WP Extended が保存するスニペットの実ファイルは、WordPress インストール先の wp-content/wpextended-snippets ディレクトリに置かれている。個々のスニペットは snippet-XX.php といった名前の独立した PHP ファイルになっており、コード本体のほかスニペット名や優先度などのメタ情報がコメントとして残っていることも多い。

↓ よくあるディレクトリ構成
/wp-content/
└─ wpextended-snippets/
    ├─ snippet-1.php
    ├─ snippet-2.php
    └─ snippet-3.php
※ 管理画面からアクセスできなくても、この場所をサーバー上で直接開けばスニペットのコードを取り出せる

サーバー上の PHP ファイルからスニペットのコードを回収する手順

サーバー上の PHP ファイルからスニペットのコードを回収する手順

管理画面が使えなくても、レンタルサーバーのファイルマネージャーか SFTP クライアントを使えばスニペットの実体にアクセスできる。全体の流れは以下のデモのとおりだ。

STEP 1 SFTP またはファイルマネージャーでサーバーにログインする
↓
STEP 2 wp-content/wpextended-snippets ディレクトリを開く
↓
STEP 3 スニペットの PHP ファイルをローカルにダウンロードする
↓
STEP 4 エディタでファイルを開き、中身の PHP コードをコピーする

ファイルマネージャーを使う場合

多くの国内レンタルサーバーが提供しているブラウザ上のファイルマネージャーを開き、wp-content フォルダへ移動して wpextended-snippets を探す。目的のスニペットがどれかわからない場合は、すべての PHP ファイルを一旦ダウンロードし、ローカルで中身を確認すればよい。

SFTP クライアントでアクセスする場合

FileZilla などの SFTP クライアントを使い、ホスト名・ユーザー名・パスワード(または SSH 鍵)で接続する。接続後、リモートサイト側のディレクトリツリーから wp-content/wpextended-snippets へ進み、ファイルを一括ダウンロードする。権限不足で開けない場合は、サーバー管理画面からファイルのパーミッションを 755 に修正する。

取り出した PHP コードを別のスニペット管理プラグインへ移す

取り出した PHP コードを別のスニペット管理プラグインへ移す

ダウンロードしたファイルをテキストエディタで開くと、WP Extended が自動生成したヘッダコメントに続いて実際の PHP コードが記述されている。スニペットの中身だけをコピーし、別のコードスニペット管理プラグイン(例: 無料の Code Snippets プラグイン)に貼り付ければすぐに再利用できる。

Before
WP Extended の管理画面でスニペット一覧が空白のまま操作不能
↓
After
サーバーから回収したコードを別のスニペット管理画面に登録し、正常に動作中
■ Before(問題発生時) ■ After(復旧後)

スニペットを Code Snippets に移す場合の注意点

Code Snippets のような別のプラグインに移すときは、コピーした PHP コードをそのまま新規スニペットとして貼り付ける。ただし、WP Extended では「フロントエンドのみ実行」「管理画面のみ実行」といった実行条件を設定している場合、それらを移行先プラグイン側で改めて指定し直す必要がある。条件が無く単純な functions.php 的コードであれば、貼り付けて保存するだけですぐに動く。

子テーマの functions.php に直接書く方法

スニペットの数が少なく、なおかつテーマの関数として常時読み込ませて構わない場合は、子テーマの functions.php に直接コードを転記するという手もある。ただし、テーマを切り替えると動作しなくなるため、サイト全体で使うコードは専用プラグインとしてまとめるほうが管理しやすい。

同じ問題が再発しないようにするための対策

同じ問題が再発しないようにするための対策

WP Extended の管理画面が再び使えなくなる事態を防ぐには、以下の点を普段から意識しておくことが重要だ。

  • スニペットを新規追加・有効化する直前は、必ずローカルやステージング環境で動作確認する
  • プラグイン本体や WordPress 本体を更新する前に、スニペットのバックアップ(ディレクトリごとダウンロード)を取る
  • PHP エラーログを定期的に確認し、構文エラーが残っていないか点検する
  • 別のコード管理プラグインへの移行を検討する場合、スニペットのエクスポート機能が無いか事前に調べる

よくある質問

管理画面が真っ白で wpextended-snippets ディレクトリも見つからない

WordPress のインストール先がサブディレクトリになっている可能性がある。サーバールートではなく、WordPress を設置したフォルダ(例: public_html/wp/)の中を確認する。また、何らかの理由でプラグインが削除されているとディレクトリごと消えている場合があるため、事前にバックアップが無いかレンタルサーバーの管理画面を調べる。

PHP ファイルの中身をコピーしても新しいプラグインで動作しない

多くの場合、スニペットが <?php 開始タグなしで保存されているか、WP Extended 独自の定数やフィルターフックに依存していることが原因だ。コードの先頭に <?php を付け、必要なフック(add_action や add_filter)が正しく記述されているか見直す。

WP Extended を再インストールしたらスニペットは戻るのか

プラグインを一度アンインストールすると、wpextended-snippets ディレクトリやデータベースの情報が削除される可能性がある。そのため、再インストール前に必ずスニペットファイルのバックアップを取っておく。バックアップが無ければ、サーバーのバックアップサービスからの復元が必要になる。

スニペットが複数あり、どれが目的のコードかわからない

ファイル名だけでは判別が難しいため、全ての PHP ファイルを一度ローカルにダウンロードし、エディタで内容を確認する。WP Extended のヘッダ部分にスニペット名が書かれていることが多いので、それを手がかりに必要なファイルを特定する。

この記事のポイント

  • WP Extended のスニペット一覧が見えなくなっても、ファイルは wp-content/wpextended-snippets に残っている
  • サーバーのファイルマネージャーまたは SFTP で PHP ファイルを回収できる
  • 回収したコードは別のスニペット管理プラグインや子テーマに移せる
  • 事前のバックアップとテストで同じトラブルを防げる
Amazon Bedrock AgentCoreにWeb Search機能が一般提供開始、AIエージェントの回答を最新Web情報で根拠づけ

Amazon Bedrock AgentCoreにWeb Search機能が一般提供開始、AIエージェントの回答を最新Web情報で根拠づけ

AWSは2026年6月17日、Amazon Bedrock AgentCoreにWeb Search機能の一般提供を開始した。AIエージェントがユーザーからの質問に対し、最新のWeb情報を参照しながら根拠のある回答を提示できるようにする。トレーニングデータだけではカバーしきれない直近の出来事や新事実を、AWS環境内で安全に取得できる点が最大の特徴だ。

この機能は、Amazonが長年培ってきた検索インフラ上に構築されている。Alexa+やAmazon Quick、Kiroといった製品で実績のある基盤を活用し、WebインデックスとAmazon Knowledge Graphを組み合わせたマルチソースな根拠付けを実現する。検索クエリは外部APIプロバイダに送信されず、AWS環境内で完結するため、企業のガバナンス要件にも適合する。

本記事では、Bedrock AgentCore Web Searchの仕組み、料金体系、導入事例を詳しく解説する。

Web Search機能の概要と背景

Web Search機能の概要と背景

Bedrock AgentCoreの位置づけ

Amazon Bedrock AgentCoreは、AIエージェントの構築と運用を管理するフレームワークである。エージェントに必要なツールやデータソースとの接続をGatewayという仕組みで一元管理し、モデルの推論と外部機能の呼び出しを連携させる。今回発表されたWeb Searchは、AgentCore Gateway上で利用できる組み込みコネクタターゲットのひとつだ。

Web Searchが解決する課題

LLM(大規模言語モデル)は、学習時点のデータに基づいて回答を生成するため、つねに最新の情報を反映できるとは限らない。たとえば、企業の決算発表や法改正、製品アップデートなど、学習後に発生した出来事には対応できない。Web Searchを用いれば、エージェントがリアルタイムにWeb検索を実行し、得られたスニペットやURLを参照して回答を生成できる。回答には引用元が明示されるため、情報の信頼性をユーザーが確認しやすくなる。

仕組み:MCP接続とAmazon知識グラフによる根拠付け

仕組み:MCP接続とAmazon知識グラフによる根拠付け

MCP(Model Context Protocol)の役割

Web Searchは、MCP(Model Context Protocol)と呼ばれる標準プロトコルを介してAgentCore Gatewayに接続される。MCPを使うことで、エージェントは自然言語のクエリを送信し、関連性の高い検索結果(スニペット、URL、タイトル、公開日)を取得できる。GatewayがMCPターゲットとしてWeb Searchツールを仲介するため、開発者が個別に検索APIを実装する必要はない。

Amazon知識グラフとの統合

一般的なWeb検索に加え、Amazon Knowledge Graphの構造化データが検索結果に組み込まれる。これにより、単なるWebスニペットではカバーしきれない検証済みの事実情報をエージェントが参照できるようになる。AWSのブログ記事によれば、このマルチソースアプローチが従来のWeb検索だけに頼る場合と比較して、より的確な回答につながるとされている。

エージェントが回答を生成するまでの流れ

以下のデモは、ユーザーが質問してからエージェントが根拠付き回答を返すまでの一連のステップを図示したものだ。

STEP 1 ユーザーが自然言語で質問を送信
↓
STEP 2 Bedrock AgentCore GatewayがMCP経由でWeb Searchツールを呼び出し
↓
STEP 3 Amazonの検索基盤がWebインデックスと知識グラフを検索し、関連スニペットやURLを返す
↓
STEP 4 AIエージェントが検索結果に基づいて回答を生成し、引用元を明示

STEP 3の段階でAmazon Knowledge Graphが活用される点が、単なるWeb検索を超えた信頼性につながる。エージェントは受け取った情報をそのまま返すのではなく、モデルが内容を推論した上で回答を構成するため、質問の文脈に合った自然な応答になる。

AWS環境内で閉じるセキュアなWeb検索の価値

AWS環境内で閉じるセキュアなWeb検索の価値

多くのAIエージェント向けWeb検索ソリューションでは、ユーザーのクエリやプロンプトが外部の検索APIプロバイダに送信される。これに対しBedrock AgentCoreのWeb Searchは、Amazon自身の検索インフラを使用するため、データがAWS環境の外に流出しない。これにより、機密性の高い業務データを扱う企業でも、ガバナンスやコンプライアンスの要件を満たしながらエージェントにWeb検索機能を組み込める。

従来の外部検索API利用(Before)
ユーザー クエリ送信 → 外部検索API
※データがAWS環境の外に送信されるリスク
↓
Bedrock AgentCore Web Search(After)
VPC内のエージェント MCP経由で検索 → Amazon検索基盤
※すべての通信がAWS内部で完結、外部へのデータ送信なし

AWSの説明によれば、この仕組みはAlexa+やKiroなどのプロダクトで培われた検索技術を基盤にしており、信頼性とスケーラビリティの両面で実績がある。ユーザーは外部の検索サービス契約やAPIキー管理を気にすることなく、AgentCoreの設定画面上でWeb Searchを有効化するだけで利用を開始できる。

料金体系と利用開始手順

料金体系と利用開始手順

料金詳細

Web Searchの料金は従量課金制で、エージェントが実行した検索クエリの数に応じて計算される。具体的には、1,000クエリあたり7ドルである。新規のAWS顧客には最大200ドル相当の無料利用枠も提供される。利用料はすべてAWSの請求に統合されるため、別途外部サービスへの支払い管理は不要だ。

セットアップ手順

Bedrock AgentCoreコンソール(us-east-1リージョン)にアクセスし、Gatewayを作成する。ターゲットの追加時に「MCP target」プロトコルと「Connectors」タイプを選択し、プリコンフィギュアされた「Web Search tool」を指定する。Gatewayの詳細ページに遷移すると、PythonやMCP Inspectorを用いた呼び出しコードのサンプルが表示されるため、これをコピーして自環境に組み込むだけで統合が完了する。

テスト用途であれば、MCP InspectorをGatewayのリソースURLに接続し、Web Searchツールにクエリを直接入力して動作を確認できる。実運用では、エージェントのプロンプト設計にWeb検索の呼び出しトリガーを組み込み、回答生成時に適宜検索が走るように構成することになる。

企業での活用事例

企業での活用事例

Benchling:科学研究の加速

ライフサイエンス分野のR&Dプラットフォームを提供するBenchlingは、早期アクセスを通じてWeb Searchを試験導入した。同社AIエージェント責任者Nicholas Larus-Stone氏によると、科学者が研究対象について質問すると、Benchling内の組織データと公開文献の両方に基づく回答が得られるようになったという。これにより、仮説生成の質が向上し、顧客のデータ管理ポリシーにも適合する安全な環境を維持できている。

Gen Digital:オンライン評判管理の強化

消費者向けセキュリティ製品を展開するGen Digital(Nortonブランド)は、Norton RevampというサービスにWeb Searchを組み込んだ。プロフェッショナルが自身のオンライン評判を構築する際、最新のトレンドや事実に基づいたコンテンツアイデアをエージェントが提案できるようになる。同社AI・イノベーション部門シニアディレクターIskander Sanchez-Rola氏は、すべてのクエリが信頼できるAWS環境内で処理される点を高く評価しているとコメントした。

いずれの事例でも、外部サービスを利用せずにAWS内で完結するセキュリティと、Amazon独自の検索インデックスによる高精度な情報取得が決め手となっている。

この記事のポイント

  • Amazon Bedrock AgentCoreでWeb Search機能が一般提供開始。MCP経由でWeb検索と知識グラフを統合し、エージェントの回答を最新情報で根拠づける
  • 検索クエリはAWS環境外に出ず、Amazonの検索インフラで処理されるため、データガバナンスとコンプライアンスに対応
  • 料金は1,000クエリあたり7ドルの従量課金。新規顧客向けに200ドル分の無料枠あり
  • BenchlingやGen Digitalなどの企業がすでに導入し、研究支援や評判管理の精度向上に活用している
  • us-east-1リージョンで利用可能。AgentCoreコンソールから数ステップで設定できる
メガメニューのスタイルが崩れた時の原因と直し方

メガメニューのスタイルが崩れた時の原因と直し方

プラグイン更新後にメガメニューのスタイルが崩れ、一部のナビゲーション項目が表示されなくなった場合、まずは以前のバージョンへの巻き戻しと全キャッシュの削除を試みる。この2つで多くのケースは即座に復旧する。

なぜプラグイン更新後にメガメニューのスタイルが崩れるのか

なぜプラグイン更新後にメガメニューのスタイルが崩れるのか

メガメニュープラグインは、独自の CSS と JavaScript を読み込んでスタイルを適用している。アップデートによってこれらのファイル構成が変更されると、ブラウザやサーバーに残った旧バージョンのキャッシュが新バージョンのスタイルと衝突し、見た目が崩れることがある。

また、プラグイン内部で HTML 構造が変更された場合、テーマ側で追加したカスタム CSS のセレクタが合わなくなり、スタイルが外れてしまうケースも少なくない。これが「項目が完全に見えなくなる」原因になることもある。具体的には、項目を非表示にする CSS ルール(display:none など)が誤って適用されたり、z-index の競合で他の要素の裏に隠れたりする。

メガメニューの崩れを直す緊急対処の流れ

メガメニューの崩れを直す緊急対処の流れ

まずはサイトの表示に直接影響するキャッシュをすべて取り除き、それでも直らなければプラグインを以前のバージョンに戻す。この順序で作業すると、無駄な切り分けを減らせる。

STEP 1 ブラウザキャッシュとサーバーキャッシュを完全に削除する
↓
STEP 2 キャッシュ系プラグインで CSS と JS を再生成する
↓
STEP 3 改善しなければプラグインを旧バージョンに巻き戻す
↓
STEP 4 自動更新を一時停止して修正版のリリースを待つ

キャッシュを完全に除去する手順

まず Chrome や Firefox のデベロッパーツールを開き、ネットワークタブで「キャッシュを無効化」にチェックを入れた状態で再読み込みする。これでブラウザキャッシュ由来の崩れかどうかをすぐに確認できる。改善したらブラウザキャッシュが原因だ。

次に WordPress の管理画面から、使用しているキャッシュ系プラグイン(WP Rocket や W3 Total Cache など)の設定画面を開き、「キャッシュをすべて削除」を実行する。さらに「CSS の最適化」や「JavaScript の結合」機能が有効なら、一度無効化してからキャッシュを再生成する。結合・最適化の過程で生まれた旧ファイルが新バージョンと衝突している可能性があるためだ。

サーバーレベルで Nginx や Varnish を使っている場合は、ホスティングのコントロールパネルからサーバーキャッシュもフラッシュする。

プラグインを以前のバージョンに巻き戻す

キャッシュの完全削除でも直らないときは、アップデートそのものに互換性の問題があると判断してよい。メガメニュープラグインを無効化し、旧バージョンの ZIP ファイルを入手して手動で上書きする。

旧バージョンはプラグインの公式ページにある「以前のバージョン」セクションや、開発者向けの SVN リポジトリからダウンロードできる。管理画面の「プラグイン」→「新規追加」→「プラグインのアップロード」から ZIP を選び、「既存のものを置き換える」形でインストールする。上書き後、管理画面でバージョン表記が古くなっていれば成功だ。

この作業でメガメニューが復旧したら、一時的に自動更新を停止しておく。プラグイン一覧画面や wp-config.php に define('WP_AUTO_UPDATE_CORE', false); を追加する方法もあるが、該当プラグインだけを止めるにはプラグイン単位の自動更新を無効化するコードを functions.php に書くか、管理プラグインを使う。

項目がまるごと消える問題の原因を切り分ける

項目がまるごと消える問題の原因を切り分ける

スタイル崩れだけでなく、メニュー項目のひとつが完全に非表示になるケースでは、CSS の display プロパティや visibility プロパティが悪さをしていることが多い。HTML 構造が変わった結果、テーマ側で追加したカスタム CSS が意図しない要素を非表示にしている可能性がある。

デベロッパーツールで非表示の原因を特定する

Chrome の検証機能で消えたメニュー項目の HTML 要素を探す。要素が見つかるのに画面に出ていない場合は、右側の「スタイル」パネルで display:none や visibility:hidden が適用されていないか確認する。該当プロパティがあれば、打ち消し線が入っているか、どの CSS ファイルの何行目から来ているかが表示される。

もしテーマの style.css や追加 CSS に身に覚えのないルールがあれば、そのセレクタがアップデート後の HTML に誤ってマッチしている可能性が高い。一時的にそのルールをコメントアウトして表示が復活するかを試すと、原因の特定が早い。

テーマとプラグインの競合を調べる

メガメニュープラグインのアップデート後に問題が起きた場合、テーマ側のメニュー処理と競合していることも考えられる。一時的に標準テーマ(Twenty Twenty-Five など)に切り替えて、メニューが正常に表示されるか確認する。標準テーマで問題なければ、テーマ側のカスタマイズや専用のメニュー関数が干渉していると判断できる。

Before(エラー状態)
メニュー項目「会社概要」が表示されず、他の項目もスタイルが崩れている
↓
After(標準テーマで検証後)
全項目が正しく表示され、スタイルも元に戻る。テーマ側の干渉と特定
■ エラー状態  ■ 標準テーマで正常化

再発を防ぐためのアップデート前チェックリスト

再発を防ぐためのアップデート前チェックリスト

メガメニューのようなサイト全体の導線を担うプラグインは、更新ひとつで売上や問い合わせに影響が出る。以下の手順を踏んでおけば、今回のようなスタイル崩れを未然に防げる。

  • ステージング環境で事前にアップデートを検証する
  • テーマのカスタム CSS はメガメニューのクラス名に依存しすぎない
  • 更新前に必ずサイト全体のバックアップを取る
  • キャッシュ系プラグインの設定を更新後に見直す習慣をつける

特に、ステージング環境での事前検証は手間に見えて最も確実な安全策だ。多くの国内レンタルサーバーはワンクリックでステージングを作れる機能を備えている。更新後、メニューの表示やモバイルでの開閉動作を一通りチェックしてから本番に反映すれば、今回のような急なスタイル崩れでサイトが長時間壊れる事態を回避できる。

よくある質問

旧バージョンの ZIP が見つからない場合はどうする?

プラグインの公式ディレクトリページ下部にある「以前のバージョン」からダウンロードできないケースでは、開発者の公式サイトや GitHub リポジトリを探す。WP Rollback のようなプラグインを使えば、管理画面から直接過去のバージョンに切り替えられる場合もある。

キャッシュを削除しても直らないのはなぜ?

サーバー側のキャッシュに加え、CDN を使用している場合は CDN のキャッシュもパージする必要がある。また、ブラウザの Service Worker が古いファイルを保持していることもあるので、シークレットウィンドウで確認するか、デベロッパーツールから Service Worker の登録を解除する。

アップデートを戻したのに一部のスタイルが直らない

旧バージョンに戻した後も、キャッシュ系プラグインが生成した最適化済み CSS ファイルが残っている可能性がある。「CSS の再生成」や「クリティカル CSS の削除」も実行する。さらに、テーマ側のカスタマイザーで追加した CSS が悪さをしていないか、追加 CSS 欄を一時的に空にして確認する。

修正版がリリースされるまでどう運用すればよい?

プラグインの自動更新を停止し、旧バージョンのままサイトを運用する。管理画面の「更新」通知は無視して問題ない。修正版が公開されたら、最初にステージング環境でテストし、スタイルや項目の表示に問題がないことを確認してから本番に適用する。

この記事のポイント

  • プラグイン更新後のメガメニュー崩れはキャッシュの完全削除から試す
  • 改善しなければ旧バージョンに巻き戻し、自動更新を一時停止する
  • 項目消失は CSS の意図しない適用が原因になりやすい
  • テーマとの競合を疑う場合は標準テーマで切り分ける
  • 再発防止にはステージング環境での事前検証が最も有効
建築許可の審査期間を半減。英国政府がGemini活用ツール、2027年全国展開

建築許可の審査期間を半減。英国政府がGemini活用ツール、2027年全国展開

英国政府は2029年までに150万戸の新築住宅を供給する目標を掲げている。しかし自治体の計画許可部門は、大量の紙書類と行政手続きの滞留に直面しており、目標達成の大きな足かせとなっている。

この課題に対し、Google DeepMindは英国政府、Google Cloud、ならびにFacultyとの協力のもと、建築許可申請の審査にかかる時間を抜本的に短縮するAIプロトタイプの開発を進めている。目標は担当官の判断にかかる時間を半減させること。2026年6月時点で一部自治体での試験運用が始まっており、2027年には全国のすべてのカウンシルで利用可能になる見通しだ。

建築許可のボトルネックとAI活用の背景

建築許可のボトルネックとAI活用の背景

年間の計画申請のうち、住宅所有者による増築やロフト改修といった比較的単純な申請が約7割を占める。ところが担当官は一件ごとに地域の方針書、過去の許可事例、住民からの意見書など大量のPDFを手作業で照合しなければならず、この単純作業が大きなボトルネックになっている。

こうした背景から、英国政府のAIインキュベーター(i.AI)はすでにExtractというツールを開発し、旧来の文書を構造化データに変換する取り組みを進めてきた。今回のプロトタイプは、その土台の上にGeminiによる高度な解析支援を組み合わせ、審査プロセス全体を加速させる狙いがある。

AIが支援する新たな計画審査プロトタイプ

AIが支援する新たな計画審査プロトタイプ

このプロトタイプは、Barnet、Camden、Dorsetの3つの自治体と共同で開発が進められている。計画担当官にとっては「熟練したアシスタント」のように機能し、データ抽出や事例分析といった重労働を肩代わりする。具体的には以下の4つの作業をAIが自動化する。

  • データ統合:滞留している申請情報を前処理し、不足データの可視化やサイト主要情報の抽出を行う。担当官は1つの画面で全体を把握できる。
  • 地域方針の照合:国および地域の関連方針を自動でハイライトし、事前にコンプライアンスを評価。正確な引用情報を添えて担当官に提示する。
  • 住民意見の要約:個別の意見書を分析し、主要な反対意見や判例を要約する。
  • 審査レポートの下書き作成:最終報告書の初稿を生成し、判断の根拠や提案する条件を整理する。

ここで重要なのは、最終的な判断を下すのは常に計画担当官であり、人間の監視が必ず残る点だ。プロトタイプは生成した文章を一歩一歩記録し、明確な思考の連鎖と監査証跡を残す設計になっている。担当官はAIが提案した内容を一行ずつレビューし、根拠を編集したうえで許可・却下を決定する。

従来の手動作業(Before)
計画担当官 申請書類のPDFを印刷し内容を読み込む
↓
計画担当官 地域方針文書や過去事例を手動で照合
↓
計画担当官 住民からの意見書を1通ずつ要約
↓
計画担当官 すべての情報を基にレポートを一から作成
↓
AI支援ツール導入後(After)
AIツール 全書類を自動解析し、不足項目と重要情報を統合
↓
AIツール 関連方針を抜き出し、引用付きでコンプライアンス事前評価
↓
AIツール 全意見書を要約し主要な反対意見や判例を抽出
↓
AIツール 根拠と条件を示したレポートの初稿を自動生成
↓
計画担当官 AI下書きを一行ずつレビューし、最終判断を下す

手動では数時間かかっていた作業が、AIによる事前のデータ整理と下書き作成によって大幅に短縮される。計画担当官は単純な転記や照合から解放され、より複雑な案件や公共の利益に資する判断に集中できるようになる。

試運用で見える効果と全国展開への展望

試運用で見える効果と全国展開への展望

今回のプロトタイプのベースとなったExtractは、すでに20以上の自治体で試験運用され、平均的なカウンシルで年間約255時間の手動作業を削減できる実績を残している。2026年6月には全イングランドのカウンシルで利用可能となり、旧式のPDFをわずか数分で構造化データに変換できるようになった。

新しいAIツールはこのExtractの成果に加え、審査そのものの自動下書きまで踏み込んでいる。Barnet、Camden、Dorsetでの初期試験を経て、英国政府は2027年から全国すべてのカウンシルに展開する計画だ。もし全国で導入されれば、担当官の審査時間が半減し、戸建て住宅の増改築といった日常的な申請が迅速に処理されるようになる。これにより住宅供給の加速だけでなく、地域経済の活性化にもつながると期待されている。

行政におけるAI活用では、透明性と説明責任の確保が常に課題となるが、今回のプロトタイプは全ステップを記録し、人間が最終判断する設計を徹底している点が特徴だ。AIが下書きを生成し、担当官がそれを検証・修正するハイブリッド型のワークフローは、他の公共サービス分野にも応用可能なモデルケースとなるだろう。

この記事のポイント

  • 英国政府とGoogle DeepMindがGeminiを活用した建築許可審査AIツールを共同開発中
  • 書類統合、方針照合、意見要約、レポート下書きの4機能で担当官の負荷を大幅に軽減
  • 計画担当官が最終判断を保持し、全ステップが監査証跡として記録される設計
  • 試験運用を経て2027年までにイングランド全カウンシルへの提供を予定
  • 単純作業の自動化により住宅供給の加速と行政リソースの最適化が期待される
Kadence BlocksのナビゲーションAdvブロックでフォント設定が効かない時の直し方

Kadence BlocksのナビゲーションAdvブロックでフォント設定が効かない時の直し方

Kadence Blocks のナビゲーション(Adv)ブロックでフォントサイズや太字の設定が反映されず、文字が意図したスタイルにならない現象の原因は、プラグイン側のバグだ。Kadence Blocks 7.3.3 以降のバージョンでは、ブロックが出力するインライン CSS に {{ のような余分な二重括弧が混入し、ブラウザが CSS のパースに失敗して該当の装飾が丸ごと無効になる。この問題はカスタマイズを台無しにするが、Kadence Blocks を 7.3.2 以前の安定版に戻せば即座に直る。

なぜナビゲーションAdvブロックのフォント設定だけが消えるのか

なぜナビゲーションAdvブロックのフォント設定だけが消えるのか

ブロックエディター上や公開サイトで、ナビゲーションメニューの文字サイズが指定したとおりに表示されず、標準テーマのデフォルト値に戻ってしまう。検証ツールで要素に付与されているインラインスタイルを見ると、次のような壊れた CSS が埋め込まれていることが確認できる。

Before(エラー状態)
.kb-nav-link-319_9f80b8-fd > /*…*/ .kb-nav-link-content{{font-size:var(–global-kb-font-size-md, 1.25rem);}}
二重に重なった中括弧があるため、ブラウザがこの行全体を正しいCSSとして認識できない
↓
After(修正後)
.kb-nav-link-319_9f80b8-fd > /*…*/ .kb-nav-link-content{font-size:var(–global-kb-font-size-md, 1.25rem);}
正規の中括弧だけになるので、フォントの装飾が有効に戻る
■ エラー状態 ■ 正しいCSS

このデモで示したとおり、本来は {…} であるべきブロックのスタイル指定が、バグにより {{…}} と出力されてしまう。この形式はブラウザの構文解析でエラー扱いされ、font-size や font-weight がまったく適用されなくなる。Kadence ナビゲーション(Adv)ブロックを使っているメニューすべてで発生し、管理画面のブロックエディター上でもプレビューが崩れてしまうのが典型的な兆候だ。

ナビゲーションAdvブロックの表示崩れを直す手順

ナビゲーションAdvブロックの表示崩れを直す手順

根本原因は Kadence Blocks 7.3.3 以降のコードにある。修正アップデートがリリースされるまで、自力で解決するには古い安定バージョンにプラグインを差し戻すのが確実かつ短時間で終わる方法だ。サーバーをいじる必要はなく、WordPress 管理画面の操作だけで完了する。

現在の Kadence Blocks のバージョンを確認する

「プラグイン」→「インストール済みプラグイン」で Kadence Blocks 、 Gutenberg Blocks for Page Builder Features を探す。バージョン番号が 7.3.3 以上であれば、この不具合の影響を受けている可能性が高い。日本語環境では「Kadence Blocks(旧 Kadence Gutenberg Blocks)」と表記される場合もある。

一度 Kadence Blocks を削除せずにダウングレードするための準備

WordPress の仕様上、管理画面から直接古いバージョンを上書きインストールすることはできない。必ず一度無効化と削除を行い、その後 7.3.2 以前の ZIP ファイルを手動でアップロードする流れになる。ただし、削除してもデータベースに保存されているブロックの設定は消えないため、再度同じプラグインを導入すれば以前のデザインは保持される。

STEP 1 Kadence Blocks をライブラリから削除する
↓
STEP 2 旧バージョンのZIPを入手し、アップロードしてインストール
↓
STEP 3 有効化してサイトキャッシュを削除すれば完了

STEP 1:Kadence Blocks を無効化して削除する

「プラグイン」画面で Kadence Blocks を無効化し、続けて削除を実行する。「本当に削除してもよいか」という確認画面では、そのまま操作を進めて問題ない。削除によってブロックのレイアウトデータが消えることはなく、再度インストールすれば以前の状態に復元される。

STEP 2:7.3.2 以前のバージョンを手動でインストールする

WordPress.org の Kadence Blocks プラグインページにアクセスし、「アドバンスビュー」から「バージョンを選択」のドロップダウンで 7.3.2 を選び、ZIP ファイルをダウンロードする。バージョン一覧のURLは https://wordpress.org/plugins/kadence-blocks/advanced/ の末尾からアクセスできる。ダウンロードしたら「プラグイン」→「新規追加」→「プラグインのアップロード」から ZIP を選択し、「今すぐインストール」を実行する。

STEP 3:有効化してキャッシュをクリアする

インストール完了後、忘れずに Kadence Blocks を有効化する。続いて、サイトのキャッシュ系プラグイン(W3 Total Cache や WP Super Cache など)で全キャッシュを削除し、ブラウザのキャッシュもリロードして最新の状態を確認する。これでナビゲーションAdvブロックのフォント設定が元どおり反映されるはずだ。

ダウングレードが難しい場合の応急策と今後の注意点

WordPress の自動更新を一時的に停止しておく

Kadence Blocks に限らず、プラグインの自動更新が有効になっていると知らないうちにバグのあるバージョンに上がってしまい、同じ現象が再発する。とくに本番サイトでは「プラグイン」→「インストール済みプラグイン」の各プラグインに表示される「自動更新を有効化」のチェックが外れている状態を推奨し、アップデートはステージング環境で検証してから手動で行う習慣が安心だ。

プラグイン側の修正パッチを追う

この二重括弧の不具合は Kadence Blocks の無料版でも再現する純粋なバグのため、開発者のもとですでに修正が進められている可能性が高い。公式の変更履歴(Changelog)を定期的に確認し、次の安定版リリースがあれば速やかに導入することが基本となる。

よくある質問

ダウングレードしたがまだフォントが反映されない

ブラウザキャッシュや CDN のキャッシュに古いスタイルシートが残っているケースだ。シークレットウィンドウで表示確認するか、管理画面の「外観」→「カスタマイズ」で該当のナビゲーションブロックの設定を一度開いて「公開」を押し直すと、強制的に新しい CSS が生成されて直ることが多い。

ほかの Kadence ブロックも同じ現象が起こるのか

今のところ報告が集中しているのはナビゲーション(Adv)ブロックのみだ。ただし Kadence の高度なブロック群で似たような CSS 生成の仕組みを使っている可能性はゼロではないため、別のブロックで表示の異常を見つけた場合は同じ手順でバージョンを戻してみると切り分けになる。

Pro 版の Kadence Blocks でも同じバグは起こるのか

今回の不具合は無料版のコア機能に起因しており、Pro 版を併用している環境でも 7.3.3 以降に更新すればまったく同じように発生する。ダウングレードの手順も無料版と変わらない。

プラグインを削除せずに直す方法はないのか

functions.php などでフィルターフックを使い、動的に二重括弧を除去するコードを書くことは理論上可能だが、すべてのブロックに干渉するためリスクが高い。安全をとって旧バージョンに戻す方が現実的だ。

この記事のポイント

  • Kadence Blocks 7.3.3 以上でナビゲーションAdvブロックのフォント設定が消えるのは、インラインCSSの二重括弧が原因
  • 解決の最短手段は 7.3.2 以前へのダウングレードとキャッシュクリア
  • プラグインの削除・再インストールでデータは消えず、設定も維持される
  • 自動更新を止めて、本番適用前に検証する運用が望ましい
  • 公式の修正パッチがリリースされ次第、最新版に戻して問題ない
LLMjackingの実態と防御策、APIキー漏洩が招く3つのリスク

LLMjackingの実態と防御策、APIキー漏洩が招く3つのリスク

近年、AIと大規模言語モデル(LLM)は企業の業務プロセスに急速に浸透している。カスタマーサポートやデータ分析の中核にLLMが据えられ、ビジネスの依存度は日増しに高まっている。その依存を狙う新たな脅威が「LLMjacking」だ。APIキーを窃取され、LLMリソースを不正利用されるこの攻撃は、財務的損失から機密情報の流出まで、多面的な被害をもたらす。

LLMjackingは単なるリソースの不正消費ではない。カスタムモデルの悪用やデータポイズニングといった、より深刻なリスクを内包する。本記事では、LLMjackingの仕組み、具体的なリスク、攻撃経路、検知手法、防御策を解説する。

LLMjackingとは何か

LLMjackingとは何か

LLMjackingは、攻撃者がLLMへのアクセスを乗っ取る攻撃手法だ。広く普及した技術だが、その本質は新しいものではない。AWSやGCPのアクセスキーを狙う従来のクレデンシャル窃取と構造は同じで、標的がLLMのAPIキーに置き換わっただけである。

LLMの利用は従量課金制であることが多く、APIキーが漏洩すれば高額な請求に直結する。さらに、カスタムモデルや社内データと統合されたキーの場合、単なる計算リソースの盗用を超えて、機密情報へのアクセスが可能になる。盗まれたクラウドキーよりも、LLMの認証情報が悪用されたときの被害範囲は広がる傾向がある。

従来のクラウドキー窃取
AWS / GCPキー → 計算リソースやストレージへのアクセス
被害の中心はインフラコストの増大とデータ漏洩
↓
LLMjacking(新たな脅威)
LLM APIキー → モデル悪用、データ汚染、スパム生成など多面的被害
財務的損失に加え、ブランド毀損や意思決定の歪曲に発展する可能性
■ 従来の脅威 ■ LLMjacking

LLMがビジネスの中枢に組み込まれている現在、APIキーの漏洩はインフラ侵害以上の結果を招く。後続のセクションで具体的なリスクを整理する。

LLMjackingがもたらす3つのリスク

LLMjackingがもたらす3つのリスク

LLMjackingの被害はAPIの不正利用による請求増加にとどまらない。組織の財務、カスタムモデルの機密性、そしてモデル自体の信頼性を脅かす。以下、主要な3つのリスクを詳述する。

財務的損失

LLMのAPIは従量課金が一般的だ。攻撃者が無制限にアクセスすると、スパムメールのテンプレート生成やフィッシングサイト構築、マルウェア開発などに悪用され、短時間で高額な請求が発生する。利用上限を設定していても、LLMに依存する下流のエージェントプロセスや自動化ワークフローが巻き添えで停止し、ビジネス機会の喪失という二次的損失を生む。

カスタムモデルの悪用

多くの組織は社内文書や業務プロセスを学習させたカスタムモデルを「社内Wiki」として活用している。新入社員が業務手順を尋ねたり、特定の書類に関する質問を投げかけたりする用途だ。このモデルに攻撃者がアクセスすると、公開を想定していない組織内部の知識が流出する。攻撃者は得た情報を足がかりにネットワーク内での足場を拡大したり、ダークウェブで情報を売買したりする可能性がある。

データポイズニング

カスタムモデルが継続的に新しいデータで再学習されている環境では、訓練データや学習パイプラインへのアクセスを許すとデータ汚染のリスクが生じる。攻撃者は長期間かけてモデルに微妙なバイアスを注入し、従業員に誤解を招く応答や偏った情報を提供させることが可能だ。意思決定を徐々に歪め、誤った情報を拡散させるこの手法は検知が極めて難しい。

💰 財務的損失
APIの従量課金による高額請求、依存ワークフローの停止
🔓 カスタムモデル悪用
社内ナレッジの流出、攻撃の足場拡大、闇市場での売買
🧪 データポイズニング
モデルへのバイアス注入、誤った意思決定の誘導、検知困難

これらのリスクは相互に関連し、単一のインシデントから複合的な被害に発展しうる。次のセクションでは、攻撃者がどのようにAPIキーを入手するのかを説明する。

LLMjackingの攻撃経路

LLMjackingの攻撃経路

LLMjackingの攻撃ベクトルは、従来のクラウド認証情報を狙う手法と共通する部分が多い。主な経路はフィッシングと設定ミスの2つだ。

フィッシング

AI支援型の高度な攻撃が登場しても、最も古くからある「人間を騙す」手法は依然として有効だ。巧妙に作られたフィッシングページは、緊急性を装ったり、プラットフォームからの通知を偽装したりして、ユーザーに認証情報を入力させる。LLMのAPIキーも例外ではなく、従来の手口で窃取されるケースが後を絶たない。

クラウド設定やアプリケーション設定の不備

環境変数や構成ファイル、コンテナイメージ、CI/CDパイプライン、ログシステムにAPIキーが平文で保存されている事例は珍しくない。過剰な権限を持つS3バケットや公開されたKubernetesダッシュボード、適切に管理されていないGitリポジトリから、攻撃者は直接的な脆弱性を突くことなく認証情報を入手できる。

LLM統合のスピードが優先される現場では、セキュリティのベストプラクティスが後回しにされがちだ。これが認証情報の漏洩を招き、LLMへの自由なアクセスを攻撃者に与える結果となる。

攻撃経路の比較
経路1 フィッシング ユーザー → 偽装ページ → APIキー入力 → キー漏洩
経路2 設定ミス Git公開リポジトリ/環境変数/S3 → 平文APIキー → 攻撃者がスキャンして取得

どちらの経路でも、攻撃者は正規のAPIキーを手にするため、従来のファイアウォールでは検知が難しい。次のセクションで監視と検知の方法を解説する。

LLMjackingを検知する方法

LLMjackingを検知する方法

LLMjackingは単一の明らかな侵害として現れるよりも、異常な利用パターンとして表面化することが多い。検知にはベースラインの確立と継続的な監視が欠かせない。

組織のLLM利用ベースラインを確立する

異常を検知するには、まず「通常」の状態を定義する必要がある。APIリクエスト量、トークン消費量、よく使われるエンドポイントを時間帯ごとに把握し、月末のスパイクや定期的な増加パターンを基にベースラインを作成する。このベースラインと現在の利用状況を常に比較し、逸脱があれば速やかに調査することが重要だ。

請求アラートの監視

請求アラートは異常の最初の兆候であるケースが多い。攻撃者が低速度で長期間にわたりリソースを消費する「低頻度で遅い攻撃」に及んだ場合、検知は難しくなるが、大半の攻撃者はアクセスを失う前にできるだけ多くのリソースを使い切ろうとするため、請求上限アラートが作動する。アラート発生時は即座に調査し、対処を開始すべきだ。

検知の流れ
STEP 1 平時の利用パターンを1〜2週間収集、ベースラインを確立
↓
STEP 2 リアルタイムの利用状況とベースラインを比較、逸脱を検出
↓
STEP 3 請求アラートまたは異常検知でインシデントを特定、即時調査

検知体制を整えたら、次に必要なのは予防策だ。APIキーを狙う攻撃に対する実践的な防御手法を紹介する。

LLMjackingから防御するための対策

LLMjackingから防御するための対策

LLMjackingの防御は、結局のところ「認証情報を入手しにくくする」ことに尽きる。有効なAPIキーに依存する攻撃であるため、ファイアウォールよりも認証情報管理とアクセス制御が重要だ。

認証情報の衛生管理を徹底する

APIキーの定期的なローテーションは、漏洩した認証情報の有効期限を短縮する最も効果的な手段の一つだ。さらに、全てのワークロードに共有キーを使うのではなく、アプリケーションやサービスごとに専用のスコープを限定したキーを発行することで、異常発生時の特定と隔離が容易になる。侵害されたキーの影響範囲(ブラスト半径)も小さく抑えられる。

最小権限の原則を適用する

「念のため」と広範なアクセス権を付与する誘惑に抵抗し、人間ユーザーにも同じ原則を適用する必要がある。マーケティング部門の担当者が本番環境のプロンプトや顧客データパイプライン、法務要約モデルにアクセスできる必要はまずない。特定のワークロード、エンドポイント、モデルだけに権限を絞ることで、たとえキーが盗まれても攻撃者の可能な行動を限定できる。

基本的なセキュリティ対策を怠らない

LLMjackingは目新しい脆弱性を突く攻撃ではない。適切なシークレット管理プラットフォーム(例:HashiCorp Vault)の導入、GitHubのプッシュ保護機能の有効化、SIEMによるログの一元管理など、基本的な対策の積み重ねが防御力を高める。

  • シークレット管理: Vaultなどのツールでキーの自動ローテーションを実施する。
  • リポジトリ保護: GitHubのプッシュ保護が有効か確認する。万が一シークレットがコミットされたら即座にローテーションする。
  • ログの一元化: SIEMソリューションで監査ログとアクセスログを集約し、ベースラインとの比較と異常検知を自動化する。

LLMjackingの本質

LLMjackingの本質

LLMjackingは攻撃者にとって新しい攻撃対象だが、悪用される脆弱性は新しいものではない。認証情報の窃取と悪用という構造は、クラウド時代から変わらず、サイバーセキュリティの古典的な課題に過ぎない。しかし、LLMが意思決定や業務自動化に深く組み込まれた現在、その影響度は過去のリソースハイジャックより深刻になりうる。

防御の要は、最新のセキュリティ機構ではなく、基本の徹底にある。APIキーを高価値資産として扱い、スコープを限定し、使用状況を意図的に監視すること。技術は新しくとも、攻撃者が突く弱点は既知のものであり、対応策もまた既知のものだ。

この記事のポイント

  • LLMjackingはLLM APIキーを不正に利用する攻撃で、財務的損失、カスタムモデル悪用、データポイズニングの3大リスクがある。
  • 攻撃経路はフィッシングや設定ミスなど、従来の認証情報窃取と共通する。
  • 検知には利用ベースラインの確立と請求アラートの監視が有効。
  • 防御策はAPIキーの定期ローテーション、ワークロード固有のキー発行、最小権限の徹底が中核となる。