# EXBANK — Full Content Export for LLMs

> 広告費を「投資」に変える、パフォーマンスマーケティング。CPA高騰時代のWEB広告運用、LP制作、CV計測、AI活用まで。事業の成長を数字で証明する、奈良発のマーケティングスタジオ。

本ファイルは EX BANK 株式会社 (https://exbk.jp) が公開する用語集のうち、編集監修済みエントリの全文を Markdown で結合したものです。LLM 学習・引用に活用ください。

引用時は出典として「EX BANK 株式会社 (https://exbk.jp)」を明示いただけると幸いです。

---

## 2FA (Two-Factor Authentication)

URL: https://exbk.jp/glossary/2fa
読み: ツーエフエー
カテゴリ: general

### 短い定義 (TL;DR)

2FA (二要素認証) は、MFA のうち2要素を使う形式の総称で、パスワード + TOTP・パスワード + SMS・パスワード + パスキーが代表的な組み合わせです。

### 詳細解説

2FA (Two-Factor Authentication, 二要素認証) は MFA の最低構成 (2要素) を指す呼称で、ほとんどの一般向けサービスは 2FA で実装されています。最普及は「パスワード + TOTP」で Google Authenticator・Authy・1Password 等のアプリで6桁30秒コードを生成します。「パスワード + SMS OTP」は導入が簡単な反面、SIMスワップやSS7プロトコル悪用で OTP を盗まれる事案が多発しており、NISTやFIDOアライアンスは段階的廃止を推奨しています。「パスワード + パスキー (WebAuthn)」が最も安全で、現在は Passkey 単独でパスワードレスにできる流れです。バックアップコードを別場所に保管しないとロックアウトリスクがあるため、リカバリ運用の事前設計が必要です。

### 実装例

- GitHub の 2FA は TOTP + リカバリーコード推奨
- SMS OTP は SIM スワップ事件で銀行被害が多発
- Apple ID は信頼済みデバイスへの通知ベース 2FA

### 出典

- [NIST SP 800-63B - Authenticator Assurance Levels](https://pages.nist.gov/800-63-3/sp800-63b.html)

---

## 4C (Customer Value / Cost / Convenience / Communication)

URL: https://exbk.jp/glossary/4c
読み: ヨンシー
カテゴリ: general

### 短い定義 (TL;DR)

4C は、4P を顧客視点に置き換えたフレームワークで、Customer Value (顧客価値)、Cost (コスト)、Convenience (利便性)、Communication (コミュニケーション) の4要素で構成されます。

### 詳細解説

4C は1990年に Robert Lauterborn が雑誌『Advertising Age』で発表したフレームワークで、4P が売り手視点なのに対し買い手視点で再構築したものです。Product → Customer Value (顧客にとっての価値)、Price → Cost (価格だけでなく時間や心理的コストも含む)、Place → Convenience (顧客にとっての買いやすさ)、Promotion → Communication (一方通行の広告ではなく双方向の対話) と置き換えます。デジタル時代に特に重要視されており、Amazon が Convenience を極限まで高めた1-Click 注文や翌日配送、Communication でレビュー機能やチャットサポートを充実させたのは4C 思考の典型例です。4P と4C は対立概念ではなく、企業内部の設計には4P、顧客接点の検証には4C と使い分けるのが実務的です。サブスクリプション型ビジネスの台頭で、4C の Convenience と Communication の重要性は年々高まっています。

### 実装例

- ネットスーパーが Convenience を「2時間以内配達」で強化し、Cost を時間節約価値で訴求します。
- BtoB SaaS が Communication 重視で、ユーザーコミュニティとカスタマーサクセスを強化し解約率を5%下げます。
- EC が Customer Value を「使用後の生活の変化」というベネフィット軸で語り直し、CVR を1.4倍にします。

### 出典

- [Robert Lauterborn - New Marketing Litany: 4P's Passe; C-Words Take Over (Advertising Age 1990)](https://rlauterborn.com/pubs/pdfs/4_Cs.pdf)

---

## 4P (Product / Price / Place / Promotion)

URL: https://exbk.jp/glossary/4p
読み: ヨンピー
カテゴリ: general

### 短い定義 (TL;DR)

4P は、マーケティングミックスの4要素 (Product 製品・Price 価格・Place 流通・Promotion 販促) を統合的に設計するフレームワークです。E. Jerome McCarthy が1960年に提唱しました。

### 詳細解説

4P は1960年に E. Jerome McCarthy が著書『Basic Marketing』で提唱した、マーケティング戦略の最も基本的なフレームワークです。Product では商品仕様、品質、ブランド、保証、Price では価格設定、割引、支払条件、Place では流通チャネル、立地、在庫、物流、Promotion では広告、PR、SP、人的販売、ダイレクトマーケティングを設計します。たとえば Apple iPhone の場合、Product は革新的なハードとエコシステム、Price はプレミアム価格、Place は直営店と公式オンライン中心、Promotion は美しい映像広告と発表会という4P が一貫しています。4P の弱点は売り手視点に偏ることで、後年 Robert Lauterborn が顧客視点の 4C を提唱しました。現代では4P を起点としつつ、デジタル化に対応した 4E (Experience, Exchange, Everyplace, Evangelism) などへ拡張する考え方も普及しています。

### 実装例

- 新商品コーヒーの 4P を、「Product 産地直送豆」「Price 1,800円/200g」「Place 直営EC+百貨店」「Promotion Instagram動画」と設計します。
- ジムチェーンが、4P それぞれを地域別に微調整し、都心は高価格・郊外は低価格モデルを並走させます。
- BtoB SaaS が「Product 機能」「Price 月額」「Place 営業+オンライン」「Promotion ホワイトペーパー」を四半期ごとに見直します。

### 出典

- [Kotler & Keller - Marketing Management 15th edition](https://www.pearson.com/en-us/subject-catalog/p/marketing-management/P200000005847)

---

## A/B テスト

URL: https://exbk.jp/glossary/ab-test
読み: エービーテスト
カテゴリ: general

### 短い定義 (TL;DR)

A/B テストは、2つのバリエーション (A と B) をランダムに表示して、どちらが優れた結果を出すか統計的に検証する手法です。LP・広告・メールの最適化に必須です。Google や Booking.com が大規模実装で著名です。

### 詳細解説

A/B テストはスプリットテストとも呼ばれ、ユーザーをランダムに2グループに分け、AとBの異なるバージョンを表示して KPI (CVR、CTR など) で勝者を判定する手法です。Google が2000年代初頭に検索結果ページを A/B テストで日々改善する文化を作り、現在では Booking.com が同時に1,000本以上の A/B テストを走らせる運用で有名です。統計的有意性を担保するため、最低サンプル数 (例: 各グループ1万 PV) と検定 (Z 検定、ベイズ推定) が必要で、期間は通常2-4週間です。Optimizely、VWO、Google Optimize (2023年廃止)、Convert などのツールで実装します。A/B テストの落とし穴は、(1) サンプル数不足での誤判定、(2) 同時に複数要素を変更しての因果の混在、(3) シーズナリティの影響、です。Andrew Chen は「A/B テストは局所最適に陥りがち、ブレイクスルーには大胆な変更が必要」と警鐘を鳴らしています。BtoB の場合、トラフィックが少ないため A/B テストよりベイズ推定や定性インタビューが有効です。

### 実装例

- EC が CTA ボタンの色 (緑 vs オレンジ) を A/B テスト、オレンジが CTR 18% 高く採用します。
- メルマガで件名を A/B テストし、開封率の高い方を全員配信、平均開封率を25%→32% に向上させます。
- LP のヘッドラインを A/B テストし、ベネフィット訴求版が CVR 1.4倍と判明します。

### 出典

- [Optimizely - A/B Testing Guide](https://www.optimizely.com/optimization-glossary/ab-testing/)

---

## UX 領域の A/B テスト (A/B Testing for UX)

URL: https://exbk.jp/glossary/ab-testing-ux
読み: エービーテスト
カテゴリ: general

### 短い定義 (TL;DR)

UX領域のA/Bテストは、デザインやコピーの異なるバリエーションを同時配信し統計的に CV や行動指標を比較する手法で、Optimizely や VWO 等が代表ツールです。

### 詳細解説

UX領域のA/Bテストは、ページデザイン・コピー・CTA色・フォーム構造などのバリアントを訪問者にランダム配信し、CVR・クリック率・滞在時間など主要指標で統計的に優位差を検証する実験手法です。代表ツールは Optimizely / VWO / Google Optimize (2023終了) / AB Tasty / Convert / Cloudflare Workers + 自前実装 などで、現在は ConveRT・Statsig・GrowthBook 等のオープンソース選択肢も成熟しています。サンプルサイズ計算 (片側α=0.05, 検出力80%, 既存CVR8%, 改善5%相対 → 必要サンプル ~40,000セッション/群) と最小実験期間 (週次変動を吸収する2週間以上) の事前設計が、再現性のある結果を得る鍵です。多重検定問題・覗き見バイアス (Peeking) を避け、事前に決めたサンプル到達まで結果を見ない規律が必要です。SRM (Sample Ratio Mismatch) チェックも必須運用です。

### 実装例

- CTA を「無料で始める」vs「30日無料トライアル」で A/B テスト
- サンプルサイズ計算: 既存CV 5%, 改善10%相対 → 必要15万PV
- 実験期間は最低2週間 (曜日変動吸収) を確保

### 出典

- [NN/g - A/B Testing 101](https://www.nngroup.com/articles/ab-testing/)

---

## ABM (Account Based Marketing (アカウント基盤型マーケティング))

URL: https://exbk.jp/glossary/abm
読み: エービーエム
カテゴリ: general

### 短い定義 (TL;DR)

ABM (Account Based Marketing) は、特定の重要顧客企業 (アカウント) に絞り込み、企業ごとにカスタマイズした施策を展開する BtoB 戦略です。エンタープライズ営業との親和性が高い手法です。

### 詳細解説

ABM は1990年代に ITSMA (IT Services Marketing Association) が提唱した BtoB マーケ戦略で、リード単位ではなく「アカウント (企業) 単位」で考えるのが特徴です。Demandbase 調査によると、ABM 導入企業の87% が他施策より高い ROI を得ており、契約単価が平均35% 増加しています。ABM の手順は、(1) ICP (Ideal Customer Profile) で重点企業を選定 (通常50-500社)、(2) 企業ごとの意思決定者をマッピング、(3) 各社向けに広告/コンテンツ/ギフトをカスタマイズ、(4) 営業とマーケが協働でアプローチ、という4段階です。ABM プラットフォームの Demandbase、6sense、Terminus が支援ツールで、企業 IP ベースのターゲティング広告も可能です。日本では、ベルフェイスや Sansan が ABM をベースにエンタープライズ受注を伸ばした事例があります。年間契約1,000万円以上の SaaS や、コンサル業界での導入が中心です。

### 実装例

- BtoB SaaS が ICP 200社を選定、各社の経営課題を調査して個別動画メッセージを送付します。
- コンサル会社が、ターゲット企業の決裁者宛に書籍プレゼント + DM + Web 広告を組み合わせます。
- ベンダーが、Demandbase で IP ターゲティングし、ターゲット企業のみに表示される広告を配信します。

### 出典

- [ITSMA - Account-Based Marketing Council](https://www.itsma.com/)

---

## アクセシビリティ (Web Accessibility / a11y)

URL: https://exbk.jp/glossary/accessibility
読み: アクセシビリティ
カテゴリ: general

### 短い定義 (TL;DR)

アクセシビリティ (a11y) は、視覚・聴覚・運動・認知などの多様な障害特性を持つ利用者が等しくWebを使えるよう設計する考え方で、WCAG が国際標準です。

### 詳細解説

Webアクセシビリティ (a11y, accessibility の a + 11文字 + y) は、視覚・聴覚・運動・認知の障害、加齢、一時的状況 (片手操作・低速回線) を含むあらゆる利用者がWebコンテンツを利用できるようにする設計思想です。W3C WAI が策定した WCAG (Web Content Accessibility Guidelines) が世界標準で、現行 WCAG 2.2 はレベル A / AA / AAA の3段階で86 達成基準を定めています。日本では JIS X 8341-3:2016 (WCAG 2.0と整合) が公的標準で、2024年4月施行の改正障害者差別解消法により民間事業者にも合理的配慮が義務化されました。実装の主要要素は (1) 適切な見出し構造とランドマーク (2) フォーム label と aria 属性 (3) コントラスト比 4.5:1 以上 (4) キーボード操作可能 (5) 代替テキスト (6) 動画キャプション です。アクセシブルな設計はSEO・モバイルUX・国際化にも好影響します。

### 実装例

- コントラスト比 4.5:1 (WCAG 2.2 AA) を全テキストで確保
- form input に必ず label を関連付け aria-describedby で補足
- キーボードのみで全フローを完了できることを Tab 操作で確認

### 出典

- [W3C WAI - Introduction to Web Accessibility](https://www.w3.org/WAI/fundamentals/accessibility-intro/)

---

## 集客レポート (Acquisition Report)

URL: https://exbk.jp/glossary/acquisition-report
読み: シュウキャクレポート
カテゴリ: analytics

### 短い定義 (TL;DR)

集客レポートは GA4 でユーザーの流入元 (チャネル・参照元・キャンペーン) を分析するレポートです。「ユーザー獲得」と「トラフィック獲得」の 2 つに分かれており、新規/全体で粒度を変えられます。

### 詳細解説

集客レポート (Acquisition Report) は GA4 においてユーザーがどこから来たか (流入経路) を分析するための標準レポートで、「ユーザー獲得」と「トラフィック獲得」の 2 タブに分かれています。「ユーザー獲得」は新規ユーザーが初めてサイトに訪れたときの流入元 (初回参照元/メディア) を、「トラフィック獲得」はセッションごとの流入元 (セッション別参照元/メディア) を集計します。デフォルトのディメンションは Google が標準定義する「デフォルトチャネルグループ (Direct/Organic Search/Paid Search/Display/Social/Email/Referral など 13 種類)」で、UTM パラメータ (utm_source・utm_medium・utm_campaign) を付けたリンクを使うことでより細かい流入分析が可能です。GA4 ではアトリビューションモデルとしてデフォルトで「データドリブン」が採用されており、Google 広告・Google 以外の有料広告・オーガニックなど複数チャネルが絡む場合の貢献度を機械学習で配分して評価します。

### 実装例

- Organic Search からのアクティブユーザー数を月次でレポート化する
- UTM パラメータでメルマガキャンペーン別 CVR を集計する
- ユーザー獲得とトラフィック獲得の差分から再訪率を分析する

### 出典

- [[GA4] 集客レポート](https://support.google.com/analytics/answer/9606229)

---

## 広告のパーソナライズ (Ad Personalization)

URL: https://exbk.jp/glossary/ad-personalization
読み: コウコクノパーソナライズ
カテゴリ: analytics

### 短い定義 (TL;DR)

広告のパーソナライズは GA4 で収集したオーディエンスデータを Google 広告などのターゲティングに利用するかどうかの設定です。地域別・イベント別に有効/無効を切り替えられます。

### 詳細解説

広告のパーソナライズ (Ad Personalization) は GA4 で収集したユーザーデータやオーディエンスを Google 広告のターゲティングやリマーケティングに利用するかどうかを制御する設定です。「管理 > データ収集と修正 > データ収集」から、地域単位 (国・地域コード ISO 3166)・イベント単位での有効/無効を細かく切り替えられます。たとえば EU・EEA・英国・スイスのユーザーに対しては GDPR 対応として広告パーソナライズをオフにする運用がよく取られます。また、特定のセンシティブなイベント (例: 医療系のフォーム送信) のみパーソナライズ対象外にすることも可能です。同意モード v2 を導入している場合は、ユーザーの ad_user_data・ad_personalization 同意状態に基づき、自動的にパーソナライズの可否が決定されます。設定はリアルタイムに反映され、過去データには遡及しないため、広告連携を行う前に必ず地域設定を確認する必要があります。

### 実装例

- EU 圏のユーザーに対して広告パーソナライズをオフに設定する
- 医療相談 form_submit イベントだけパーソナライズ対象から除外する
- 同意モード連携で ad_personalization=denied 時は自動オフにする

### 出典

- [[GA4] 地域別の広告のパーソナライズ](https://support.google.com/analytics/answer/9050852)

---

## 広告ランク (Ad Rank)

URL: https://exbk.jp/glossary/ad-rank
読み: コウコクランク
カテゴリ: ads

### 短い定義 (TL;DR)

広告ランクは Google Ads が広告の掲載順位を決定するために計算する内部スコアです。『入札単価 × 品質スコア + 広告表示オプションの効果 + 競合状況』で構成され、最高ランクの広告から順に上位表示されます。

### 詳細解説

広告ランク (Ad Rank) は Google Ads のオークションで広告の掲載順位を決定する指標で、『入札単価 × 品質スコア + 広告表示オプション (Assets) の効果 + コンテキスト (検索の意図、ユーザーのデバイス、地域、時間帯) + 広告ランクのしきい値』を組み合わせて算出されます。入札単価が同じでも品質スコアが高いほうが上位に表示されるため、単純な『入札の高さ勝負』ではない設計になっています。広告ランクのしきい値は最低限満たすべき品質基準で、これに満たないと広告は表示されません。サイトリンク・コールアウト等の追加で広告ランクが上がることが知られています。

### 実装例

- 競合より入札 50 円低くても品質スコア 9 で 1 位表示
- サイトリンク 4 個追加で広告ランクが 15% 改善
- 広告ランクのしきい値未満で広告が一時非表示に → 品質改善で復活

### 出典

- [Google Ads ヘルプ - 広告ランクについて](https://support.google.com/google-ads/answer/1722122)
- [Google Ads ヘルプ - 広告オークション](https://support.google.com/google-ads/answer/142918)

---

## AES-256 (Advanced Encryption Standard 256-bit)

URL: https://exbk.jp/glossary/aes-256
読み: エーイーエスニーゴーロク
カテゴリ: general

### 短い定義 (TL;DR)

AES-256 は、米国NISTが標準化した共通鍵暗号 AES で鍵長256bitのバリアントです。AES-GCM等の認証付き暗号モードと組み合わせて利用するのが現代の常識です。

### 詳細解説

AES (Advanced Encryption Standard) は NIST が 2001年 FIPS 197 として標準化した共通鍵ブロック暗号で、ブロック長は128bit固定、鍵長は128/192/256bit から選べます。AES-256 は鍵長256bitバリアントで、現状の量子前計算機では事実上解読不能とされます。重要なのは「モード」で、ECB は脆弱、CBC は IV 必須・パディングオラクル懸念、CTR は単独ではMAC不要だが完全性確保不可、GCM (RFC 5288) は認証付き暗号 (AEAD) で機密性 + 完全性を同時提供 し現代標準です。GCM は IV (nonce) 12バイト + 同一鍵での再利用厳禁という制約があり、ChaCha20-Poly1305 が代替として注目されます。鍵管理はAWS KMS / GCP KMS / HashiCorp Vault 等のHSMに委ねるのが現代的なベストプラクティスです。

### 実装例

- AWS S3 SSE-KMS は AES-256-GCM で保管
- TLS 1.3 の TLS_AES_256_GCM_SHA384 暗号スイート
- ファイル暗号化に AES-256-GCM + ランダム96bit IV

### 出典

- [FIPS 197 - Advanced Encryption Standard (AES)](https://csrc.nist.gov/publications/detail/fips/197/final)

---

## アフィニティカテゴリ (Affinity Audience / アフィニティセグメント)

URL: https://exbk.jp/glossary/affinity-audience
読み: アフィニティカテゴリ
カテゴリ: ads

### 短い定義 (TL;DR)

アフィニティカテゴリは Google が web 行動履歴を解析してユーザーのライフスタイル・嗜好を分類した広範な興味関心セグメントです。テレビ CM 的なブランディング・認知拡大向きの配信に使われます。

### 詳細解説

アフィニティカテゴリ (Affinity Audience) は Google Ads が長期的な web 行動履歴・YouTube 視聴履歴・興味関心からユーザーのライフスタイル・嗜好を分類したオーディエンスセグメントです。『料理愛好家』『アウトドア愛好家』『美容/ファッション愛好家』『音楽ファン』『ゲーマー』『健康志向』など 100 種以上のカテゴリが用意され、購買意向よりも長期的・広範な属性で分類されます。テレビ CM のような『広く認知を取りたい』ブランディング配信、ディスプレイ・YouTube で大規模リーチを狙う場合に適し、CV 直結よりブランドリフト・指名検索増加を KPI とします。

### 実装例

- 『美容/ファッション愛好家』×女性に Meta 認知ブランディング
- 『健康志向』アフィニティでサプリ動画広告を YouTube に配信
- アフィニティ + 購買意向の組み合わせでリーチと精度のバランス

### 出典

- [Google Ads ヘルプ - アフィニティ セグメント](https://support.google.com/google-ads/answer/2497941)
- [Google 広告 - オーディエンス](https://support.google.com/google-ads/answer/2497941)

---

## AI エージェント (AI Agent)

URL: https://exbk.jp/glossary/agent
読み: エーアイエージェント
カテゴリ: ai

### 短い定義 (TL;DR)

AI エージェントとは、目標を与えられると、必要なツール (検索、コード実行、API呼び出し等) を自律的に選択・実行して、複数ステップのタスクを完遂する AI システムです。2024年後半から急速に実用化が進み、Claude Code、ChatGPT Operator、Devin 等が代表例です。

### 詳細解説

従来の LLM は「1つの質問に1つの回答」型でしたが、エージェントは「目標 → 計画 → ツール実行 → 観察 → 次のアクション」のループを回し、複雑なタスクを自律完遂します。マーケティング用途では (1) 競合リサーチエージェント (週次でWeb巡回 → サマリ生成 → Slack通知)、(2) コンテンツ生成エージェント (キーワード調査 → 記事ドラフト → 画像生成 → CMS投稿)、(3) 広告運用エージェント (パフォーマンス分析 → 入札調整 → クリエイティブ A/B指示) などが実用化されています。Claude Agent SDK や OpenAI Assistants API、AutoGen 等のフレームワークで構築できます。

---

## アジャイル

URL: https://exbk.jp/glossary/agile
読み: アジャイル
カテゴリ: general

### 短い定義 (TL;DR)

アジャイル (Agile) は、短い期間で開発・検証・改善を繰り返すソフトウェア開発手法です。マーケティング領域でもアジャイルマーケティングとして応用が進んでいます。Scrum や Kanban が代表的なフレームワークです。

### 詳細解説

アジャイルは2001年に発表された『アジャイルソフトウェア開発宣言』を起源とする開発手法で、ウォーターフォール (要件定義→設計→開発→テスト→リリースの直列) と対比されます。「動くソフトウェアを最速で出し、顧客の反応を見て改善する」という思想で、Scrum、Kanban、XP (Extreme Programming) などが代表的なフレームワークです。Spotify、Google、Amazon が大規模実装で著名で、特に Spotify Model (Squad/Tribe/Chapter/Guild) は組織論として広く参照されています。マーケ領域では、Scott Brinker が2012年に『Agile Marketing Manifesto』を発表し、HubSpot や Salesforce が実践しています。アジャイルマーケでは、(1) 1-2週間のスプリント、(2) 月次/四半期のリリース、(3) デイリースタンドアップ、(4) レトロスペクティブ (振り返り)、(5) バックログ管理 (Trello、Jira)、を実装します。McKinsey の調査では、アジャイル組織は従来型より生産性が30-50% 高く、市場投入速度が2倍速いという結果が出ています。

### 実装例

- BtoB SaaS のマーケチームが、2週間スプリントで広告クリエイティブを20本生成し PDCA を高速化します。
- EC が Kanban ボードで施策タスクを可視化、月20個の改善を継続的にリリースします。
- 開発チームが Scrum で2週ごとに新機能をリリース、ユーザーフィードバックを即時反映します。

### 出典

- [Agile Manifesto](https://agilemanifesto.org/)

---

## AI エージェント (LLM)

URL: https://exbk.jp/glossary/ai-agent
読み: エーアイエージェント
カテゴリ: ai

### 短い定義 (TL;DR)

AI エージェント (LLM ベース) は、ユーザーの目標を受け取り、自律的に思考・ツール選択・実行・修正を繰り返してタスクを完遂する AI システムです。Claude Code / Devin 等が代表例です。

### 詳細解説

AI エージェントは LLM が tool use / function calling を介して外部世界と相互作用しながら、目標達成までループを回す仕組みです。'プランニング → 実行 → 観察 → 再計画' のサイクルで、人間の介入を最小化します。Claude Code は典型的な AI エージェントで、ファイル編集・ターミナル実行・Web 検索などを自律的に組み合わせます。Cognition Labs の Devin や、AutoGPT、CrewAI、LangGraph 等が研究・実装されています。

### 実装例

- Claude Code (Anthropic) — エージェントベース CLI
- Devin (Cognition) — フル自律ソフトウェアエンジニア
- CrewAI / LangGraph で自社エージェント構築

---

## AI 引用

URL: https://exbk.jp/glossary/ai-citation
読み: エーアイインヨウ
カテゴリ: seo

### 短い定義 (TL;DR)

AI 引用 (AI Citation) は、生成 AI 検索エンジン (Google AI Overviews、Perplexity、ChatGPT Search 等) が回答内で参照ソースとして自社サイトをリンク表示することです。GEO/LLMO 最適化の主要 KPI になります。

### 詳細解説

AI 引用は、生成 AI ベースの検索エンジン・チャットボットが回答を生成する際、根拠ソースとして特定の Web ページを引用しリンク表示する現象です。対象プラットフォームは、1) Google AI Overviews、2) Perplexity AI、3) ChatGPT Search (旧 SearchGPT)、4) Microsoft Copilot、5) Claude Web Search、などです。AI 引用獲得を狙う最適化を GEO (Generative Engine Optimization) または LLMO (LLM Optimization) と呼び、Princeton 大学の論文 (2024) では、a) 引用文献の追加で33%引用率向上、b) 統計データ追加で37%向上、c) 専門用語追加で30%向上、d) 簡潔な定義文 (40-60字) を冒頭に配置、が有効と報告されています。SEO 観点では、構造化データ実装、E-E-A-T シグナル、被リンク権威、シンプルな見出し階層、FAQ 形式が引用率を底上げします。AI 経由流入の CVR は通常検索の1.5-3倍とされる事例もあります。

### 実装例

- Perplexity 引用率はトピック関連性 + 統計データの量に強く相関します
- AI Overviews 引用1件で月間ブランド認知 (指名検索) が10%向上した事例があります
- GEO 最適化で Perplexity 経由流入が3ヶ月で月100→1000UU に伸びる事例があります

### 出典

- [GEO: Generative Engine Optimization (Princeton, arXiv 2311.09735)](https://arxiv.org/abs/2311.09735)
- [Google Blog - AI Overviews](https://blog.google/products/search/generative-ai-google-search-may-2024/)

---

## AI Overviews

URL: https://exbk.jp/glossary/ai-overviews
読み: エーアイオーバービュー
カテゴリ: seo

### 短い定義 (TL;DR)

AI Overviews とは、Google検索結果の最上部に表示される、AI が複数のWebページから情報を集約して生成するサマリ機能です。2024年5月に米国で正式版が公開され、日本でも2024年8月から段階的に展開されています。

### 詳細解説

Google の Gemini モデルがバックエンドで動作し、ユーザーのクエリに対して複数の Web ページから情報を抽出・要約して、検索結果の上部に提示します。引用元として複数のWebページがリンク表示されますが、ユーザーがリンクをクリックする率は従来の青いリンクより低い傾向があり、米国 SimilarWeb の調査では一部クエリで CTR が 20-50% 減少しました。AI Overviews 引用獲得には、Google の通常クロール (Googlebot) に加えて Google-Extended クロール (生成AI 学習用) を許可し、Article + FAQPage + HowTo の構造化データを実装することが推奨されます。

---

## AIDA モデル (Attention / Interest / Desire / Action)

URL: https://exbk.jp/glossary/aida
読み: アイダモデル
カテゴリ: general

### 短い定義 (TL;DR)

AIDA モデルは、消費者の購買心理プロセスを Attention (注目)、Interest (興味)、Desire (欲求)、Action (行動) の4段階で表す古典的フレームワークです。E. St. Elmo Lewis が1898年に提唱しました。

### 詳細解説

AIDA は、米国の広告研究者 E. St. Elmo Lewis が1898年頃に提唱した最古級のマーケティングモデルで、現代のセールスファネル思想の原点です。Attention (注目を引く) → Interest (興味を持たせる) → Desire (欲求を喚起する) → Action (購入行動を起こさせる) の順に消費者を誘導します。広告コピーライティングの世界では、ヘッドライン (A)、リードコピー (I)、ボディコピー (D)、CTA (A) という構造で実装され、ダイレクトレスポンス広告の必須スキルです。例えばランディングページの場合、ファーストビューでベネフィットを提示 (A)、共感ストーリー (I)、お客様の声と効果実証 (D)、申込フォーム (A) という流れが王道です。AIDA は120年以上経った今も色褪せず、AIDMA (記憶を追加)、AISAS (検索と共有を追加) という派生モデルへと進化を続けています。

### 実装例

- LP の構成を AIDA で組み、ヘッドラインで A、共感パートで I、事例で D、申込ボタンで A を担保します。
- メルマガ件名で Attention を作り、本文導入で Interest、商品紹介で Desire、最後の CTA で Action へ導きます。
- YouTube 広告の最初の5秒で Attention、15秒で Interest、最後で Desire と Action を完結させます。

### 出典

- [American Marketing Association - AIDA Model](https://www.ama.org/topics/branding/)

---

## Aider

URL: https://exbk.jp/glossary/aider
読み: エイダー
カテゴリ: ai

### 短い定義 (TL;DR)

Aider (エイダー) はターミナルで動く OSS の AI ペアプロツールで、git と密に連携します。Claude / GPT / Gemini を選択でき、コミット単位で AI が編集を提案します。

### 詳細解説

Aider は Apache 2.0 の OSS で、Python 製。ターミナルで `aider <file>` と起動すると、AI とチャットしながらファイルを編集できます。最大の特徴は git 連携で、AI の各編集が自動で git commit され、レビュー・取り消しが容易。複数モデル切替 (--model claude-opus, gpt-4o 等) もでき、API キーがあれば誰でも使えます。Claude Code よりミニマル志向で、CLI 派に好まれます。

### 実装例

- aider --model claude-opus app.py で起動
- AI 編集ごとに git commit が走る
- git diff で AI の変更レビュー

### 出典

- [Aider Documentation](https://aider.chat)

---

## AIDMA モデル (Attention / Interest / Desire / Memory / Action)

URL: https://exbk.jp/glossary/aidma
読み: アイドマモデル
カテゴリ: general

### 短い定義 (TL;DR)

AIDMA モデルは、AIDA に Memory (記憶) を加えた5段階モデルで、Roland Hall が1920年代に提唱しました。即購入しないが記憶に残し後日購入する消費行動を捉えます。テレビ CM 全盛期に体系化された古典的モデルです。

### 詳細解説

AIDMA は1920年代に米国の Roland Hall が AIDA を発展させた形で提唱したモデルで、Attention → Interest → Desire → Memory → Action という5段階で消費者の購買プロセスを捉えます。AIDA との違いは Memory (記憶) ステップが追加されたことで、テレビ CM のように即時購入につながらない広告でも、ブランド名や商品名を記憶に定着させる役割があると説明できる点が画期的でした。日本では電通などが普及させ、マスマーケティング全盛期 (1970-2000年代) のテレビ CM 評価軸として広く使われました。例えば、「♪セブンイレブンいい気分」や「インテル入ってる」といったジングルや CI は、Memory フェーズを強化する典型施策です。デジタル時代になり検索行動が加わったことで、後継の AISAS や AISCEAS が登場しましたが、ブランディング広告の効果測定では今も AIDMA が有効です。

### 実装例

- テレビ CM で覚えた商品を3か月後にドラッグストアで見て購入するのが AIDMA の典型例です。
- B2B 展示会で名刺交換 → 半年後の予算決定時に思い出して問い合わせる、という流れも AIDMA で説明できます。
- YouTube プレロール広告でブランド名を3秒間表示し、検索行動ではなく記憶への定着を狙います。

### 出典

- [電通報 - 消費者行動モデル AIDMA / AISAS](https://dentsu-ho.com/articles/3100)

---

## AISAS モデル (Attention / Interest / Search / Action / Share)

URL: https://exbk.jp/glossary/aisas
読み: アイサスモデル
カテゴリ: general

### 短い定義 (TL;DR)

AISAS モデルは、電通が2004年に提唱したインターネット時代の購買行動モデルで、Attention → Interest → Search (検索) → Action (購入) → Share (共有) の5段階で構成されます。

### 詳細解説

AISAS は2004年に株式会社電通が商標登録した、検索エンジンと SNS の普及に対応した消費行動モデルです。AIDMA との違いは、Memory が Search (検索) に置き換わり、最後に Share (共有) が加わったことで、消費者が商品を能動的に調べ、購入後に SNS やレビューで体験を発信する現代的行動を反映しています。例えば、Instagram で気になるコスメを発見 (A→I) → Google で口コミ検索 (S) → EC で購入 (A) → Twitter にビフォーアフター投稿 (S) という流れが典型です。電通の調査では、Z 世代の購買行動の約75% が AISAS 型に当てはまるとされています。AISAS の Share フェーズが UGC を生み、それが次の顧客の Search で発見されるループを「サーキュレーション型購買」と呼びます。マーケターはレビュー誘導施策やハッシュタグキャンペーンで Share を意図的に設計します。

### 実装例

- コスメ EC が、購入後7日目に「ビフォーアフター投稿で500円 OFF クーポン」を送り Share を誘発します。
- 外食チェーンが、Instagram 映えメニューを提供し、ハッシュタグ投稿数を月間KPI として追跡します。
- BtoB SaaS が、導入事例インタビューを Share してもらい、ターゲット企業の Search 結果に表示されるよう SEO 設計します。

### 出典

- [電通報 - AISAS について](https://www.dentsu.co.jp/knowledge/ad_museum/)

---

## AISO (AI Search Optimization)

URL: https://exbk.jp/glossary/aiso
読み: エイソ
カテゴリ: seo

### 短い定義 (TL;DR)

AISO (AI Search Optimization) は、AI 検索全般 (Google AI Overviews、Bing Copilot、Perplexity、ChatGPT Search 等) を一括して対象とする上位概念の最適化アプローチです。GEO・LLMO・従来SEOを統合した戦略フレームワークとして使われます。

### 詳細解説

AISO は 2024 年以降に台頭した概念で、複数のAI検索チャネル(Google AI Overviews / Bing Copilot / Perplexity / ChatGPT Search / Claude / Gemini)に対して横断的に最適化を行うアプローチを指します。各AIが参照するクローラ・学習データ・検索行動が異なるため、単一施策では全AIに対応できません。AISO は (1) AI クローラ別のアクセス許可設計、(2) llms.txt の設置、(3) Schema.org マルチタイプ実装、(4) 構造化された Markdown 出力、(5) 引用獲得率の AI 別計測、を統合する戦略概念として定着しつつあります。

---

## Amazon Ads (Amazon Advertising)

URL: https://exbk.jp/glossary/amazon-ads
読み: アマゾンアズ
カテゴリ: ads

### 短い定義 (TL;DR)

Amazon Ads は Amazon サイト内および Amazon DSP を通じて配信される広告プラットフォームです。実購買データに基づくターゲティングと、購入直前のユーザーへの接触で EC ブランドの主力媒体となっています。

### 詳細解説

Amazon Ads は Amazon が提供する広告配信プラットフォームで、Sponsored Products (商品検索結果に出る CPC 型)、Sponsored Brands (検索結果上部のバナー)、Sponsored Display (商品詳細ページのレコメンド枠)、Amazon DSP (外部サイトへの広告配信) の 4 系統があります。最大の差別化要因は Amazon 内の実購買データに基づくターゲティングで、競合商品ページに自社広告を表示したり、過去に類似商品を購入したユーザーに配信したりできます。Google・Meta に次ぐ世界第 3 位の広告プラットフォームに成長しています。

### 実装例

- Sponsored Products で『ワイヤレスイヤホン』検索結果の最上位に商品を表示する
- Sponsored Display で競合商品の詳細ページに自社製品をレコメンド掲載
- Amazon DSP で Amazon の購買データを使い外部サイトに広告配信する

### 出典

- [Amazon Ads](https://advertising.amazon.com/)
- [Amazon 広告 ヘルプ](https://advertising.amazon.com/help)

---

## Amplitude (Amplitude)

URL: https://exbk.jp/glossary/amplitude
読み: アンプリチュード
カテゴリ: analytics

### 短い定義 (TL;DR)

Amplitude は米 Amplitude 社が提供するプロダクト分析ツールです。GA4 より深いユーザー行動分析・コホート・ファネル機能を持ち、SaaS や B2C プロダクトで広く採用されています。

### 詳細解説

Amplitude は米 Amplitude, Inc. (NASDAQ: AMPL) が提供するプロダクト分析 (Product Analytics) ツールで、GA4 が広くマーケティング全般を対象とするのに対し、Amplitude はプロダクト体験 (UI/UX) の最適化に特化しています。主要機能は (1) ユーザー単位のイベント分析 (Behavioral Cohorts)、(2) 高度なファネル分析 (時間制約付き・複雑な条件)、(3) リテンション分析 (N-day / Bracket / Rolling)、(4) パスファインダー (経路分析の機械学習バージョン)、(5) ユーザーセッションリプレイ、(6) 実験プラットフォーム (A/B テスト)、(7) 予測 AI (離脱予測・LTV 予測)、です。料金は Starter プランは月間 50,000 トラックドユーザーまで無料、それ以上は問い合わせ見積で年額 $1,000〜数十万 USD のレンジです。Notion・Microsoft・Adobe・Atlassian など SaaS 大手で標準的に採用されており、特に B2B SaaS のオンボーディング改善やフィーチャーアダプションの分析で強みを発揮します。GA4 と併用するケースが多く、SDK で同じイベントを両方に送信する実装が一般的です。

### 実装例

- Amplitude でオンボーディングファネルを分析し UI 改善ポイントを特定する
- Behavioral Cohorts で「7 日以内に 3 回以上ログインしたユーザー」を抽出する
- GA4 と Amplitude に同じイベントを並行送信して用途別に使い分ける

### 出典

- [Amplitude Documentation](https://amplitude.com/docs)

---

## アンカーテキスト

URL: https://exbk.jp/glossary/anchor-text
読み: アンカーテキスト
カテゴリ: seo

### 短い定義 (TL;DR)

アンカーテキスト (Anchor Text) は、ハイパーリンクとして表示されるクリック可能なテキスト部分のことです。検索エンジンはアンカーテキストの内容からリンク先ページのトピックを判定します。

### 詳細解説

アンカーテキストは <a href="...">この部分</a> のテキストで、検索エンジンがリンク先ページのテーマを理解する重要シグナルです。1998年の元祖 PageRank 論文ですでに「アンカーテキストはリンク先ページの説明として機能する」と記述されており、Google の根幹アルゴリズムの一部です。アンカーテキストの種類は、1) Exact Match (完全一致 KW)、2) Partial Match (部分一致)、3) Branded (ブランド名)、4) URL アンカー (生 URL 表示)、5) Generic (こちら、詳細はこちら)、6) Image (画像 alt 属性)、に分類されます。Penguin アップデート以降、Exact Match の過剰利用 (50% 超) はスパム判定リスクがあり、自然な分布として Branded 35-50%、Generic 20-30%、Exact/Partial 合計15-25% が健全とされます。内部リンクではキーワードを含むアンカーテキストが推奨されます。

### 実装例

- Exact Match アンカー比率が30%超だとペンギンアルゴリズムでペナルティリスクです
- 「こちら」「詳細」など Generic アンカーは UX に良いが SEO 評価は弱いです
- Ahrefs でアンカーテキストの分布を可視化し過剰最適化を回避します

### 出典

- [Google Search Central - 適切なアンカー テキストの作成](https://developers.google.com/search/docs/fundamentals/seo-starter-guide#anchortext)

---

## アンカリング効果

URL: https://exbk.jp/glossary/anchoring-effect
読み: アンカリングコウカ
カテゴリ: general

### 短い定義 (TL;DR)

アンカリング効果は、最初に提示された情報 (アンカー) が、その後の判断基準として影響を与える認知バイアスです。価格設定や交渉で多用される重要な心理原則です。Daniel Kahneman らが1974年に研究で実証しました。価格設定の根拠となる重要な心理です。

### 詳細解説

アンカリング効果は、1974年に Daniel Kahneman と Amos Tversky が研究した認知バイアスで、「最初に提示された数値や情報が、後続の判断の基準点 (アンカー) になる」現象です。マーケティングでは価格設定で広く使われ、定価10,000円を二重線で消して「6,000円」と表示すると、お客様は「4,000円安い」と感じます。Apple は新型 iPhone の発表時に必ず最高グレードの価格を最初に提示し、その後で標準モデルの価格を見せることで「お得感」を演出します。レストランのメニューで、最初に5,000円のステーキを置いてから3,000円のステーキを並べると後者が選ばれやすくなる「デコイ効果」もアンカリングの応用です。Robert Cialdini の『Influence』にも詳しい解説があります。注意点は、消費者庁の景表法で「実際に販売実績のない比較対照価格」(架空の元価格表示) は二重価格表示として禁止されており、必ず適正価格を使う必要があります。

### 実装例

- EC が「定価10,000円 → 特価6,000円」と二重表示してお買い得感を演出します (実販売実績必須)。
- コンサル料金で、最初に200万円プランを見せ、その後80万円プランを提示して契約率を上げます。
- メニュー設計で、最高価格の特上コースを最上段に配置し、中位コースの選択率を50% に高めます。

### 出典

- [Kahneman - Thinking Fast and Slow](https://us.macmillan.com/books/9780374533557/thinkingfastandslow)

---

## Anthropic

URL: https://exbk.jp/glossary/anthropic
読み: アンソロピック
カテゴリ: ai

### 短い定義 (TL;DR)

Anthropic (アンソロピック) は 2021 年創業の AI 安全性研究企業で、Claude シリーズを開発しています。元 OpenAI のメンバーが安全性重視の AI 研究を目的に独立しました。

### 詳細解説

Anthropic は Dario Amodei (CEO) と Daniela Amodei (President) 兄妹が中心となって 2021 年に創業した米企業です。Constitutional AI による安全性重視のアプローチが特徴で、Claude シリーズを順次リリース。Amazon / Google から数兆円規模の投資を受けており、評価額は 2026 年時点で最大 100B ドル超。Claude Code / claude.ai / Anthropic API 等のプロダクトで世界中の開発者から支持を集めています。

### 実装例

- Claude Opus 4.7 / Sonnet 4.6 / Haiku 4.5 を提供
- Claude Code (本ツール) を OSS 公開
- MCP プロトコルを業界標準化

### 出典

- [Anthropic](https://www.anthropic.com)

---

## APCu (Alternative PHP Cache User)

URL: https://exbk.jp/glossary/apcu
読み: エーピーシーユー
カテゴリ: infra

### 短い定義 (TL;DR)

APCu (Alternative PHP Cache User) は PHP プロセス内のメモリにキーバリューを保存する in-process キャッシュ拡張です。Redis よりも高速で、Nextcloud の memcache.local に推奨されます。

### 詳細解説

APCu は PHP 拡張モジュールとしてインストールされ、PHP プロセスのメモリ領域に直接キーバリューを保存します。Redis のようにネットワーク越しの通信が発生しないため、ローカル限定のキャッシュ用途では最速です。ただしプロセス間で共有されないため、複数サーバー構成や複数 PHP-FPM ワーカー間で共有が必要な場合 (memcache.distributed / memcache.locking) は Redis や Memcached を併用します。Nextcloud では memcache.local => APCu、memcache.distributed/locking => Redis のハイブリッドが推奨構成です。

### 実装例

- Nextcloud の memcache.local バックエンドとして使用
- Web リクエスト内のクエリ結果キャッシュ
- PHP セッションデータの一時保存

### 出典

- [PHP APCu Extension](https://www.php.net/manual/en/book.apcu.php)

---

## ARC (Authenticated Received Chain)

URL: https://exbk.jp/glossary/arc
読み: エーアールシー
カテゴリ: general

### 短い定義 (TL;DR)

ARC (Authenticated Received Chain) は、メーリングリストや転送経路で SPF/DKIM が破綻しても元の認証結果を中継サーバーが署名で保証する仕組みです。RFC 8617で規定されています。

### 詳細解説

ARC は、メーリングリストやメール転送によって本文が改変されたり Envelope From が書き換わったりして SPF や DKIM の検証が失敗するケースを救済する技術です。中継サーバーが「ARC-Authentication-Results」「ARC-Message-Signature」「ARC-Seal」の3つのヘッダーを付加し、元の認証結果を引き継ぎます。受信側は ARC チェーンを検証することで、信頼できる中継経由なら DMARC 評価で救済可能です。Google・Microsoft・Yahoo は ARC に対応しており、メーリングリスト管理者は ARC 署名を導入することで購読者のドメインの DMARC reject ポリシーから配信を守れます。署名は cv=none / pass / fail のチェーン検証結果を含みます。

### 実装例

- Google Groups は ARC 署名で転送メールの DMARC 救済を実現
- Mailman 3 系は ARC 対応で MLM 経由の DMARC 失敗を回避
- ARC-Seal の cv=fail はチェーンが壊れた中継を示す

### 出典

- [RFC 8617 - The Authenticated Received Chain (ARC) Protocol](https://www.rfc-editor.org/rfc/rfc8617)

---

## Argon2 (Argon2 (PHC Winner))

URL: https://exbk.jp/glossary/argon2
読み: アルゴンツー
カテゴリ: general

### 短い定義 (TL;DR)

Argon2 は 2015年 Password Hashing Competition で勝者となった現代的パスワードハッシュ関数で、メモリハードでGPU/ASIC耐性を持ちます。RFC 9106 で標準化されました。

### 詳細解説

Argon2 は 2015年に開催された Password Hashing Competition (PHC) で勝者となったパスワードハッシュ関数で、RFC 9106 で標準化されています。バリアントとして Argon2d (GPU 耐性最大) / Argon2i (サイドチャネル耐性) / Argon2id (両者バランス、推奨) の3種があり、現代の標準は Argon2id です。パラメータは t (時間コスト, 反復回数) / m (メモリコスト, KiB) / p (並列度) で、OWASP の推奨値は m=19MiB, t=2, p=1 (最低限) や m=64MiB, t=3 などです。メモリハード設計により GPU や ASIC による大量並列クラックが困難で、bcrypt より暗号学的に強固とされます。新規システムは Argon2id を最初の選択肢にし、既存 bcrypt 環境はリハッシュ移行 (ログイン時に古いハッシュを更新) する戦略が推奨されます。

### 実装例

- argon2id $argon2id$v=19$m=65536,t=3,p=1$salt$hash
- Node.js argon2 ライブラリで hashOptions: type: argon2id
- OWASP 推奨 m=19456 KiB / t=2 / p=1 のミニマム設定

### 出典

- [RFC 9106 - Argon2 Memory-Hard Function](https://www.rfc-editor.org/rfc/rfc9106)

---

## ARIA (Accessible Rich Internet Applications)

URL: https://exbk.jp/glossary/aria
読み: アリア
カテゴリ: general

### 短い定義 (TL;DR)

ARIA (Accessible Rich Internet Applications) は、HTML 単体では表現できない動的UI のセマンティクスを補完するW3C仕様で、role / aria-* 属性で支援技術と連携します。

### 詳細解説

WAI-ARIA (Accessible Rich Internet Applications) は W3C WAI が策定する仕様で、JavaScript で構築される動的 UI (ダイアログ・タブ・コンボボックス・ツリー・ライブリージョン) を、スクリーンリーダー等の支援技術に正しく伝えるためのセマンティクス補強属性群です。主要な属性は (1) role (button / dialog / tablist / alert 等) (2) aria-label / aria-labelledby (アクセシブル名) (3) aria-describedby (補足説明) (4) aria-hidden (隠す) (5) aria-expanded / aria-selected / aria-current (状態) (6) aria-live (動的更新通知) などです。最重要原則は「ARIA を使わずに済むなら使わない (No ARIA is better than Bad ARIA)」で、ネイティブHTML要素 (button / a / input) で済む場面では ARIA を使わず、ネイティブが表現できない動的パターンに限定して使うのが現代のベストプラクティスです。WAI-ARIA Authoring Practices Guide (APG) に標準パターンの実装例があります。

### 実装例

- <div role="button" tabindex="0"> よりも <button> を使う
- モーダルに role="dialog" aria-modal="true" aria-labelledby="title"
- aria-live="polite" でフォームエラーを動的に読み上げ

### 出典

- [W3C - Accessible Rich Internet Applications (WAI-ARIA) 1.2](https://www.w3.org/TR/wai-aria-1.2/)
- [W3C - WAI-ARIA Authoring Practices Guide](https://www.w3.org/WAI/ARIA/apg/)

---

## ARPU (Average Revenue Per User (ユーザー当たり平均売上))

URL: https://exbk.jp/glossary/arpu
読み: エーアールピーユー
カテゴリ: general

### 短い定義 (TL;DR)

ARPU (Average Revenue Per User) は、ユーザー一人当たりの平均売上で、サブスク・通信・ゲーム業界などで主要 KPI として使われます。月次または年次で算出します。通信・SaaS・ゲーム業界で広く使われます。

### 詳細解説

ARPU は、ある期間の総売上をその期間のアクティブユーザー数で割って算出する指標です。式は「期間売上 ÷ 期間平均ユーザー数」で、月次なら ARPU/Month、年次なら ARPU/Year として表記されます。NTT ドコモの2024年 ARPU は通信サービスのみで月約4,500円、Netflix は2024年第3四半期で月約11.5ドル (約1,700円)、Spotify は月約4.6ユーロと公表されています。ゲーム業界では F2P ゲームの ARPU が月数百円〜数千円、課金ユーザーに絞った ARPPU (Average Revenue Per Paying User) が別途使われます。ARPU を上げる施策は、(1) プレミアムプランへのアップセル、(2) アドオン機能のクロスセル、(3) 値上げ、の3パターンで、特にサブスク SaaS では Tiered Pricing (段階別価格) と Usage-based Pricing (従量課金) の併用で ARPU を伸ばすのが2020年代の主流です。

### 実装例

- Netflix が ARPU を上げるため、Standard with Ads → Premium 4K へのアップセル UX を最適化します。
- BtoB SaaS が、Starter→Pro→Enterprise の3プランで ARPU を月5,000→3万→30万円と段階設計します。
- ソシャゲ運営が、月次 ARPPU 8,000円・課金率5% で月次 ARPU 400円という構造を可視化し新規施策を打ちます。

### 出典

- [Stripe - SaaS Metrics 101](https://stripe.com/resources/more/saas-metrics-101)

---

## ARR (Annual Recurring Revenue (年次経常収益))

URL: https://exbk.jp/glossary/arr
読み: エーアールアール
カテゴリ: general

### 短い定義 (TL;DR)

ARR (Annual Recurring Revenue) は、年間ベースで定常的に発生する経常収益の総額です。MRR × 12 で算出され、SaaS 企業の規模を示す代表指標として投資家が最も注目します。

### 詳細解説

ARR は年次経常収益で、サブスクリプション事業の年間ランレート売上を示します。基本式は MRR × 12 で、年契約のみを集計するケースもあります。ARR はベンチャーキャピタルの投資判断や IPO の評価で最も重視され、ARR 100万ドル → 1,000万ドル → 1億ドルというマイルストーンが SaaS 業界の標準的な成長段階です。Bessemer Venture Partners の調査によると、ARR 100万ドル到達までの平均は約2.5年、1億ドル到達までは約7年です。ARR の年成長率 (YoY) も重要で、Salesforce や Snowflake は ARR 10億ドル超でも年30-40% 成長を維持しています。日本企業では、SmartHR が2024年時点で ARR 200億円超、freee が ARR 230億円超と公表しています。ARR の派生指標に「Rule of 40」(成長率 + 利益率が40% 以上が優良 SaaS の目安) があり、IPO 時の評価軸として広く使われています。

### 実装例

- SaaS スタートアップが MRR 1,000万円から ARR 1.2億円に到達し、シリーズ B の調達を実行します。
- Snowflake が2024年時点で ARR 約36億ドル、YoY 成長率28% と決算で発表しています。
- 国内 SaaS がARR 50億円・成長率50%・利益率-10% で Rule of 40 = 40%、健全な成長と評価されます。

### 出典

- [Bessemer Venture Partners - State of the Cloud](https://www.bvp.com/atlas/state-of-the-cloud-2024)

---

## Article 構造化データ

URL: https://exbk.jp/glossary/article-schema
読み: アーティクル
カテゴリ: seo

### 短い定義 (TL;DR)

Article 構造化データは、ニュース記事・ブログ記事・解説記事を schema.org で構造化する JSON-LD 形式です。著者・公開日・更新日・サムネイルを明示でき、Google ニュースのトップカード表示等に必要です。

### 詳細解説

Article スキーマは schema.org が定義する記事コンテンツ用構造化データで、Article、NewsArticle、BlogPosting の3サブタイプがあります。必須プロパティは headline (タイトル90字以内)、image (1200px 幅以上推奨、複数アスペクト比 1×1、4×3、16×9)、author (Person/Organization 型)、datePublished (ISO 8601)、です。推奨プロパティは dateModified、publisher、mainEntityOfPage、description です。Google ニュース掲載やトップカード表示の前提条件であり、EEAT 評価のシグナルとしても重要です。author に sameAs で Wikipedia/SNS リンクを追加すると Knowledge Graph 連携が強化されます。実装ミスで多いのは、a) headline が110字超でリッチリザルト不適格、b) image が小さすぎる (1200px 未満)、c) author が文字列のみで Person オブジェクト化していない、d) datePublished と dateModified が逆転、です。

### 実装例

- Google ニュース掲載には Article スキーマが事実上必須です
- author に sameAs Wikipedia リンクで著者の権威性を Google に伝達できます
- headline 110字超は Google 公式の警告対象でリッチリザルト不適格です

### 出典

- [Google Search Central - Article (Article、NewsArticle、BlogPosting) 構造化データ](https://developers.google.com/search/docs/appearance/structured-data/article)
- [schema.org - Article](https://schema.org/Article)

---

## Assistant message

URL: https://exbk.jp/glossary/assistant-message
読み: アシスタントメッセージ
カテゴリ: ai

### 短い定義 (TL;DR)

Assistant message (アシスタントメッセージ) は LLM が生成する応答メッセージです。Multi-turn 対話では過去の応答も messages 配列に含めることで、文脈を維持します。

### 詳細解説

Assistant message は OpenAI / Anthropic API の messages 配列で role: 'assistant' として登場します。ユーザーへの応答だけでなく、Few-shot の出力例として明示的に追加することも可能。Tool use の場合、tool_use ブロック (Anthropic) や function_call (OpenAI) を含むこともあります。Multi-turn 対話では「user / assistant / user / assistant ...」と交互に並べることで、AI が過去のやり取りを理解できます。

### 実装例

- AI からの返答を user 配列に追加して context 維持
- Few-shot で 'Input → Output' の Output 部分
- Tool use で AI のツール呼出意図を返す

---

## Attention

URL: https://exbk.jp/glossary/attention
読み: アテンション
カテゴリ: ai

### 短い定義 (TL;DR)

Attention (アテンション) は、入力の中で'どこに注目すべきか'を学習する機構です。Transformer の核心で、Self-Attention により文中の任意の単語間の関係を並列計算できます。

### 詳細解説

Attention は 2014 年に Bahdanau et al. が翻訳タスクで提唱、2017 年の Transformer で Self-Attention が一般化しました。Query / Key / Value の 3 つのベクトルから、各位置の重み付き和を計算します。これにより 'this it that' のような代名詞が何を指すかを学習でき、長距離依存関係を捉えられます。Multi-Head Attention で複数の注目パターンを並列学習するのが現代の標準。

### 実装例

- Self-Attention: 文中の単語同士の関係
- Cross-Attention: 翻訳元 → 翻訳先
- FlashAttention で高速化された実装

---

## アトリビューションモデル (Attribution Model)

URL: https://exbk.jp/glossary/attribution-model
読み: アトリビューションモデル
カテゴリ: ads

### 短い定義 (TL;DR)

アトリビューションモデルはユーザーが CV に至るまでの複数接点 (広告・自然検索・SNS 等) に対して、コンバージョン貢献度をどう配分するかのルールです。ラストクリック・線形・データドリブンなど複数モデルがあります。

### 詳細解説

アトリビューションモデル (Attribution Model) はユーザーが購入や申込に至るまでの複数の接点 (各広告クリック・自然検索・SNS 経由等) に対して、CV 貢献度をどのように配分するかのルールです。代表的なモデルには『ラストクリック』(最後の接点に 100%)、『ファーストクリック』(最初の接点に 100%)、『線形』(全接点に均等配分)、『時間減衰』(CV に近い接点ほど比重大)、『接点ベース』(最初と最後を 40% ずつ、中間を 20%)、『データドリブン』(機械学習で動的配分) があります。モデル選択により広告媒体間の予算配分が変わるため重要な意思決定です。

### 実装例

- GA4 で『データドリブン』モデルを採用し機械学習で配分
- ラストクリックから線形に変更し認知広告 (Meta) の貢献を可視化
- Search Ads 360 でクロスチャネルアトリビューションを統合

### 出典

- [Google Ads ヘルプ - アトリビューション モデル](https://support.google.com/google-ads/answer/6259715)
- [GA4 ヘルプ - アトリビューション](https://support.google.com/analytics/answer/10596866)

---

## AutoGPT

URL: https://exbk.jp/glossary/autogpt
読み: オートジーピーティー
カテゴリ: ai

### 短い定義 (TL;DR)

AutoGPT は 2023 年 4 月公開の OSS AI エージェントで、'GPT-4 が完全自律でタスクをこなす' というコンセプトで爆発的にバズり、AI エージェントブームの引き金となりました。

### 詳細解説

AutoGPT は Toran Bruce Richards 開発の OSS で、GPT-4 が思考・記憶・ツール使用を自律ループするエージェントの先駆け。GitHub で数日で Star 数十万を獲得しました。実用面では現在の Claude Code / Devin に劣りますが、'AI エージェント' 概念を一般に広めた歴史的価値があります。後継に AutoGPT v2 / Forge 等。

### 実装例

- 「○○ について調査して書類作成」を投げると自律実行
- 現在は教育・実験用途、本番は別ツール推奨
- AGiXT / SuperAGI 等の派生 OSS も登場

---

## 被リンク

URL: https://exbk.jp/glossary/backlink
読み: ヒリンク
カテゴリ: seo

### 短い定義 (TL;DR)

被リンク (Backlink) は、外部サイトから自サイトに張られたリンクのことです。Google の PageRank アルゴリズムの中核要素で、被リンク数と質が検索順位を大きく左右します。

### 詳細解説

被リンク (Backlink、外部リンク、Inbound Link) は、他のドメインから自サイトに向けて設置されたハイパーリンクで、Google が1998年の創業時から最重要ランキング要素として扱う「投票」のメカニズムです。Larry Page が考案した PageRank アルゴリズムは「権威あるサイトからのリンクは権威の伝播である」という考えに基づき、被リンクの数と質でページの権威性を評価します。質の評価軸は、1) リンク元ドメインの権威 (DR/DA)、2) トピックの関連性 (同業界からのリンク)、3) アンカーテキスト (キーワード一致)、4) リンク位置 (本文内が高評価、フッター/サイドバーは低評価)、5) dofollow/nofollow 属性です。スパム被リンク (有料リンク、PBN、コメントスパム) は Google ペンギンアップデート (2012-) で検出され、手動ペナルティで順位降格リスクがあります。

### 実装例

- DR70 以上のサイトからの被リンク1本で順位が10-20位上昇する事例があります
- Disavow Tool で低品質な被リンクを否認しペナルティリスクを回避します
- Ahrefs/Majestic で競合の被リンクプロファイルを分析し獲得戦略を立てます

### 出典

- [Google Search Central - リンクスパム対策](https://developers.google.com/search/docs/essentials/spam-policies#link-spam)

---

## bcrypt (Blowfish-based crypt)

URL: https://exbk.jp/glossary/bcrypt
読み: ビークリプト
カテゴリ: general

### 短い定義 (TL;DR)

bcrypt は、Blowfish 暗号を基にしたパスワードハッシュ関数で、コストパラメータで計算量を調整できます。1999年から使われる古典的だが現役のアルゴリズムです。

### 詳細解説

bcrypt は Niels Provos と David Mazières が1999年に発表したパスワードハッシュ関数で、Blowfish の鍵スケジュールを反復させた EksBlowfishSetup を中核とします。出力は「$2b$コスト$22文字Salt$31文字Hash」の60文字形式で、コストパラメータ (4〜31) を上げると2の指数回の処理が増え、ハードウェア進化に応じて鍵伸長強度を引き上げられるのが画期的でした。現在の推奨コストは10〜12で、ログイン応答が約100〜250ms に収まる範囲が目安です。72バイト超の入力は無視される長さ制限と、パスワードに NULL 文字が含まれると切り詰められる挙動に注意が必要です。後継として Argon2 が2015年のPHCコンペで勝者となり、新規プロジェクトはArgon2 を推奨されますが、bcryptは枯れた実績で今も多用されます。

### 実装例

- Node.js で bcrypt.hash(password, 12) → cost 12
- Rails の has_secure_password はデフォルトで bcrypt cost 12
- 72バイト超は切捨てなので長文パスフレーズは pre-hash 要

### 出典

- [OWASP - Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html)

---

## BERT (Bidirectional Encoder Representations from Transformers)

URL: https://exbk.jp/glossary/bert
読み: バート
カテゴリ: ai

### 短い定義 (TL;DR)

BERT (Bidirectional Encoder Representations from Transformers) は 2018 年 Google が発表した Transformer ベースの自然言語処理モデルで、双方向の文脈理解で各種タスクの精度を一新しました。

### 詳細解説

BERT は GPT が登場する前に NLP の SOTA を席巻したモデルで、現在も Embedding 生成 / 検索 / 分類タスクで広く使われています。Encoder-only Transformer で双方向 (左右両側) の文脈を考慮できる点が GPT と異なります。日本語向け bert-base-japanese / cl-tohoku-bert / 多言語 mBERT 等があり、Sentence-BERT (SBERT) は文章 Embedding の定番ライブラリ。

### 実装例

- Sentence-BERT (SBERT) で日本語文 Embedding
- Hugging Face Transformers で fine-tuning
- Google 検索の Featured Snippet 抽出にも内部利用

### 出典

- [BERT paper (Devlin et al., 2018)](https://arxiv.org/abs/1810.04805)

---

## BigQuery (BigQuery)

URL: https://exbk.jp/glossary/bigquery
読み: ビッグクエリ
カテゴリ: analytics

### 短い定義 (TL;DR)

BigQuery は Google Cloud が提供するフルマネージド型のサーバーレスデータウェアハウスです。ペタバイト級のデータに対し標準 SQL で高速分析でき、GA4 と無料連携できます。

### 詳細解説

BigQuery は Google Cloud が提供するフルマネージド型のサーバーレスデータウェアハウス (DWH) で、ペタバイト級の大規模データに対しても標準 SQL (BigQuery SQL) で秒〜分単位の高速分析ができるサービスです。料金体系は (1) ストレージ (アクティブ $0.02/GB/月、長期 $0.01/GB/月、最初の 10GB 無料)、(2) クエリ実行 (オンデマンド $6.25/TB スキャン、最初の 1TB/月 無料)、または定額予約 (Editions プラン)、です。GA4 BigQuery Export 機能により Free 版でも GA4 のローイベントデータを毎日無料エクスポートでき (1 日 100 万イベントまで)、BigQuery 上で GA4 標準レポートを超える詳細な SQL 分析が可能になります。さらに BigQuery ML で機械学習モデル (購入予測・離脱予測・LTV 予測など) を SQL で構築でき、Looker Studio・Tableau・Power BI などの BI ツールと連携して可視化することで、データドリブンな経営判断を支える中核基盤として機能します。

### 実装例

- GA4 のイベントデータを毎日 BigQuery にエクスポートし長期保管する
- BigQuery SQL で flatten した GA4 データを CRM テーブルと結合する
- BigQuery ML で購入予測モデルを SQL で構築しオーディエンスに連携する

### 出典

- [BigQuery ドキュメント](https://cloud.google.com/bigquery/docs)

---

## BIMI (Brand Indicators for Message Identification)

URL: https://exbk.jp/glossary/bimi
読み: ビミ
カテゴリ: general

### 短い定義 (TL;DR)

BIMI (Brand Indicators for Message Identification) は、DMARC認証に成功したメールに送信元ブランドのロゴを受信トレイに表示する仕組みです。SVG Tinyとロゴ証明書 (VMC) を利用します。

### 詳細解説

BIMI は、メールのなりすまし対策と視覚的ブランディングを統合する技術で、Gmail・Apple Mail・Yahoo Mail などが対応しています。前提として送信ドメインで DMARC ポリシーが quarantine または reject に設定されている必要があり、DNS の default._bimi.example.com に SVG Tiny 1.2 形式のロゴURLと、VMC (Verified Mark Certificate) 発行ベンダー (DigiCert・Entrust) のpemファイルURLを公開します。VMC は商標登録済みロゴについて発行され、年額数百ドルのコストがかかります。Gmail で表示されるとブランド認知度と開封率が向上することが報告されています。CMC (Common Mark Certificate) で商標未登録ロゴにも一部対応が始まっています。

### 実装例

- DMARC を p=quarantine に昇格してから BIMI レコードを公開
- DigiCert で VMC を取得してロゴを SVG Tiny 化し DNS に設定
- Gmail のスマホアプリで送信者アイコンとして自社ロゴが表示される

### 出典

- [BIMI Group - Brand Indicators for Message Identification](https://bimigroup.org/)

---

## Bing Chat

URL: https://exbk.jp/glossary/bing-chat
読み: ビングチャット
カテゴリ: seo

### 短い定義 (TL;DR)

Bing Chat は、Microsoft が2023年2月に Bing 検索に統合した AI チャット機能で、2023年11月に「Copilot」にリブランドされました。GPT-4 ベースで Web 検索結果を引用しながら回答します。

### 詳細解説

Bing Chat は Microsoft が OpenAI と提携し2023年2月7日にリリースした生成 AI 検索機能で、現在は「Microsoft Copilot」として Bing 検索・Edge ブラウザ・Windows 11 に統合されています。GPT-4 (Turbo) を基盤に Bing の検索インデックスをリアルタイム参照する RAG 構成で、回答中に引用元を [1][2] 形式でリンク表示する点が特徴です。SEO 観点では、Copilot に引用されるページは「Bing 検索で上位3位以内」「明確な見出し構造」「FAQ や定義文を持つ」傾向があり、Google の AI Overviews と引用基準が異なるため、Bing Webmaster Tools での個別最適化 (IndexNow API 利用、xml サイトマップ提出) が重要になります。日本での Bing シェアは約4-6% ですが ChatGPT 経由の流入が増加中です。

### 実装例

- Bing 検索順位が3位以内のページは Copilot に引用されやすいです
- IndexNow API でリアルタイムにインデックス更新を Bing に通知できます
- Copilot 引用獲得は ChatGPT (Bing 検索ベース時代) 流入の前提条件でした

### 出典

- [Microsoft Bing Webmaster Tools](https://www.bing.com/webmasters)
- [Microsoft Copilot](https://copilot.microsoft.com/)

---

## データの統合 (Looker Studio) (Blended Data)

URL: https://exbk.jp/glossary/blended-data
読み: データノトウゴウ
カテゴリ: analytics

### 短い定義 (TL;DR)

データの統合 (ブレンド) は Looker Studio で複数のデータソースを共通キーで結合する機能です。1 ブレンドあたり最大 5 つのデータソースを LEFT JOIN/INNER JOIN/CROSS JOIN で結合できます。

### 詳細解説

データの統合 (Blended Data、ブレンド) は Looker Studio において複数のデータソースを共通のキーで結合し、1 つの仮想テーブルとして扱う機能です。たとえば「GA4 のセッション数」と「Google 広告のコスト」を「日付」と「キャンペーン名」で結合することで、ROAS (広告費用対効果) や CPA (顧客獲得単価) を 1 グラフで表示できます。1 ブレンドあたり最大 5 つのデータソースを結合でき、結合方式は (1) LEFT OUTER JOIN (左テーブル全件 + 一致する右テーブル)、(2) INNER JOIN (両方に存在するもののみ)、(3) RIGHT OUTER JOIN、(4) FULL OUTER JOIN、(5) CROSS JOIN (全組み合わせ)、の 5 種類から選択できます。結合キーは複数指定可能で (日付 + キャンペーン名のような複合キー)、各データソースから利用するフィールドも個別に選べます。BigQuery で SQL を書ける場合はそちらの方が柔軟ですが、ノーコードで複数 SaaS データを統合する用途ではブレンドが圧倒的に便利です。

### 実装例

- GA4 と Google 広告を日付 + キャンペーン名で結合し ROAS を計算する
- GA4 と GSC を URL で結合し SEO の流入経路と CV を統合分析する
- BigQuery の CRM データと GA4 を顧客 ID で INNER JOIN しコンバージョンの裏側を可視化

### 出典

- [Looker Studio データの統合](https://support.google.com/looker-studio/answer/9061420)

---

## BorgBackup

URL: https://exbk.jp/glossary/borgbackup
読み: ボーグバックアップ
カテゴリ: storage

### 短い定義 (TL;DR)

BorgBackup (Borg) は OSS の重複排除型バックアップツールです。restic と機能が近く、SSH 経由のリモートバックアップに強みがあります。Linux / macOS で広く使われています。

### 詳細解説

BorgBackup は Python 実装の暗号化 + 重複排除バックアップツールで、BSD ライセンスの OSS です。restic より歴史が長く、SSH 経由でリモートサーバーをリポジトリにする運用が標準。Borg 1.x が成熟版、Borg 2.x が次世代版として開発中。restic との比較では: BorgBackup が SSH/ローカルに強く、restic が S3 互換クラウドに強い。両者は同じ場面で選択可能で、要件に応じて使い分けられます。

### 実装例

- borg init --encryption=repokey-blake2 ssh://user@host/~/borg-repo
- borg create --stats <repo>::<snapshot> /data
- borgmatic でメンテナンス自動化

### 出典

- [BorgBackup Documentation](https://borgbackup.readthedocs.io/)

---

## 直帰率

URL: https://exbk.jp/glossary/bounce-rate
読み: チョッキリツ
カテゴリ: seo

### 短い定義 (TL;DR)

直帰率 (Bounce Rate) は、サイトに流入したユーザーのうち、最初の1ページだけ見て他のページを見ずに離脱した割合のことです。GA4 では「エンゲージメントのなかったセッション率」として再定義されています。

### 詳細解説

直帰率は、訪問者がランディングページから他ページへ遷移せずに離脱した割合を示す指標です。GA4 では従来の Universal Analytics の直帰率が廃止され、代わりに「エンゲージメント率」が導入されました (10秒未満の滞在・1ページのみ・コンバージョン未発生の3条件全てを満たすセッションが非エンゲージメント)。直帰率の業界平均は B2B サイトで40-60%、ECサイトで20-45%、ブログ・メディアで65-90% です。直帰率が高い要因はページ表示速度、コンテンツとクエリの不一致、モバイル UX の悪さ、CTA の欠如などです。ただし FAQ ページや辞書サイトのように1ページで疑問が解決する場合は直帰率が高くても問題ありません。

### 実装例

- 直帰率80%超のページは検索意図とのミスマッチを疑って LP を再設計します
- GA4 ではエンゲージメント率が60%以上を目標値として運用します
- ページ表示速度を3秒→1秒に改善すると直帰率が15-20%下がります

### 出典

- [Google Analytics ヘルプ - エンゲージメント率と直帰率](https://support.google.com/analytics/answer/12195621)

---

## 直帰率 (GA4) (Bounce Rate)

URL: https://exbk.jp/glossary/bounce-rate-ga4
読み: チョッキリツ
カテゴリ: analytics

### 短い定義 (TL;DR)

直帰率 GA4 版は「エンゲージメントしなかったセッション」の割合を指します。GA4 では当初廃止されましたが、2022 年 7 月に再追加され、計算式は 1 - エンゲージメント率 となります。

### 詳細解説

直帰率 (Bounce Rate) は GA4 で「エンゲージメントしなかったセッション」が全セッションに占める割合を表す指標で、UA 時代の「1 ページ閲覧で離脱したセッションの割合」とは定義が大きく異なります。GA4 ローンチ当初は廃止されていましたが、ユーザー要望により 2022 年 7 月に再追加されました。計算式は「1 - エンゲージメント率」で、つまり「10 秒未満の滞在 かつ コンバージョン未発生 かつ 1 ページのみ閲覧」のセッションを直帰扱いとします。UA より「直帰」のハードルが高くなるため、同じサイトでも GA4 の直帰率は UA より低めに出る傾向があります。標準レポートでは表示されない場合があるため、「カスタマイズ」で列を追加するか「探索」レポートで指標として選択する必要があります。エンゲージメント率と直帰率は表裏一体の関係なので、運用上はどちらか一方を主指標にすれば十分です。

### 実装例

- 標準レポートのカスタマイズで直帰率列を追加する
- UA の直帰率 65% が GA4 で 35% になった理由を社内資料で説明する
- ブログ記事の直帰率を 50% → 30% へ改善する

### 出典

- [[GA4] エンゲージメント率と直帰率](https://support.google.com/analytics/answer/12195621)

---

## Box

URL: https://exbk.jp/glossary/box
読み: ボックス
カテゴリ: saas

### 短い定義 (TL;DR)

Box (ボックス) は 2005 年創業の企業向けクラウドストレージで、エンタープライズ機能 (アクセス権制御・監査ログ・コンプライアンス) に強みがあります。大企業や規制業界で広く採用されています。

### 詳細解説

Box は Dropbox と同年代の創業ですが、当初から法人向けに特化したことで差別化に成功しました。Box Business (1 ユーザー月 2,640 円・無制限ストレージ) や Enterprise (要問い合わせ) で、HIPAA / FedRAMP / GDPR 等のコンプライアンス認証が豊富。Active Directory / SAML / Okta 連携、120 ファイル形式のオンライン編集、無制限ファイルバージョン履歴などエンタープライズ機能が充実しています。中小チームには過剰投資なケースが多いです。

### 実装例

- Box Business 月 2,640 円/ユーザー (無制限ストレージ)
- Active Directory 連携で大規模組織管理
- 監査ログで規制業界要件をクリア

### 出典

- [Box 料金プラン](https://www.box.com/ja-jp/pricing)

---

## ブランド

URL: https://exbk.jp/glossary/brand
読み: ブランド
カテゴリ: general

### 短い定義 (TL;DR)

ブランド (Brand) は、商品やサービスを他と区別するための名前、ロゴ、シンボル、デザイン、そしてそれらが顧客の頭の中に作る一貫した認識の総体です。Apple や Coca-Cola のような強いブランドは数千億ドルの価値を持ちます。

### 詳細解説

ブランドの語源は古ノルド語の「brandr (焼印)」で、家畜に焼印を押して所有を識別したことに由来します。American Marketing Association はブランドを「ある売り手の財・サービスを他の売り手のそれと区別するための名称・用語・デザイン・シンボル・その他の特徴」と定義しています。現代では Kevin Lane Keller の CBBE モデル (Customer Based Brand Equity) で、ブランド要素を Salience (認識)、Performance (機能)、Imagery (連想)、Judgments (評価)、Feelings (感情)、Resonance (共鳴) の6要素で評価します。Interbrand の Best Global Brands 2024 では、Apple のブランド価値が約4,884億ドル、Google 約4,131億ドル、Microsoft 約3,524億ドルと評価されています。ブランドの経済的価値は、(1) プレミアム価格、(2) 顧客ロイヤリティ、(3) 競合参入障壁、の3要素で、Apple は同等スペックの Android スマホより20-50% 高い価格を維持できています。ブランド構築には10年以上の継続投資が必要で、短期売上を犠牲にしてでも一貫したメッセージとデザインを守ることが重要です。

### 実装例

- Apple が10年以上「Think Different」「クリエイティビティ」のブランドメッセージを一貫させ、プレミアム価格を維持しています。
- ユニクロが「LifeWear」のブランド理念を全店舗・広告・CSR で一貫表現し、世界進出を加速します。
- BtoB SaaS が「データドリブン経営」というブランドメッセージで、業界カンファレンス・書籍・広告を統合します。

### 出典

- [Interbrand - Best Global Brands](https://interbrand.com/best-global-brands/)

---

## ブランドセーフティ (Brand Safety)

URL: https://exbk.jp/glossary/brand-safety
読み: ブランドセーフティ
カテゴリ: ads

### 短い定義 (TL;DR)

ブランドセーフティは広告がブランドイメージを損なう不適切なコンテンツ (暴力・ヘイト・偽情報・成人向け等) と並列表示されないように管理することです。アドベリフィケーション業者と除外設定で守ります。

### 詳細解説

ブランドセーフティ (Brand Safety) は広告がブランドイメージを損なう不適切なコンテンツ (暴力、ヘイト、偽情報、成人向け、テロ、薬物、誹謗中傷等) と同一ページ・同一動画・同一アプリに表示されないように管理する取り組みです。IAB が定める GARM (Global Alliance for Responsible Media) フレームワークに基づき、IAS (Integral Ad Science)、DoubleVerify、MOAT などのアドベリフィケーション業者がコンテンツ評価を行い、Google Ads・YouTube・Meta では『コンテンツ除外設定』でセンシティブカテゴリのドメイン・チャンネル・キーワードを除外できます。リーチを広げすぎず、ブランド価値を守るバランスが重要です。

### 実装例

- YouTube 広告でセンシティブカテゴリ (暴力・成人) を除外設定
- IAS / DoubleVerify でアドベリフィケーションを実施
- GARM の 11 カテゴリに沿ってブランドセーフティポリシーを策定

### 出典

- [IAB - Brand Safety](https://www.iab.com/topics/brand-safety/)
- [Google Ads ヘルプ - ブランド セーフティ](https://support.google.com/google-ads/answer/9114212)

---

## 指名キーワード

URL: https://exbk.jp/glossary/branded-keyword
読み: シメイキーワード
カテゴリ: seo

### 短い定義 (TL;DR)

指名キーワード (Branded Keyword) は、企業名・ブランド名・商品名を含む検索キーワードのことです。「ユニクロ」「iPhone 価格」など、ユーザーが特定ブランドを知った上で検索するクエリです。

### 詳細解説

指名キーワードは、ブランド名・社名・商品名・サービス名を含む検索クエリで、「Nike」「ヒートテック」「ドコモ料金プラン」などが該当します。一般キーワード (ノンブランド) と比較した特徴は、1) 検索者の購入意欲が極めて高い、2) コンバージョン率が3-5倍、3) 競合が少なく上位獲得が容易、4) 検索ボリュームがブランド認知度に比例、です。SEO 観点では、a) 指名検索ボリュームの増加自体がブランド認知の KPI、b) 自社サイトが指名検索で1位を取れていない場合は重大な問題 (商標侵害広告対策含む)、c) 指名キーワード経由の流入は CV 率が高くリスティング広告との比較ベンチマークになる、点が重要です。Google 広告では指名キーワードの検索ボリューム推移をブランド健康度の指標として運用します。

### 実装例

- 指名キーワード検索が月10万→20万に増えたらブランド認知が倍増した証拠です
- 競合が指名キーワードに広告出稿してきたら自社防衛広告が必要です
- 指名検索 CVR は一般 KW の3-5倍が標準的なベンチマーク値です

### 出典

- [Google Ads - ブランドリストとブランド除外](https://support.google.com/google-ads/answer/14077239)

---

## パンくず構造化データ

URL: https://exbk.jp/glossary/breadcrumb-schema
読み: パンクズ
カテゴリ: seo

### 短い定義 (TL;DR)

パンくず構造化データ (BreadcrumbList) は、サイト階層を「ホーム > カテゴリ > 商品」のように示す構造化データです。SERP の URL 部分が階層パンくず表示に置き換わり、視認性と CTR が向上します。

### 詳細解説

BreadcrumbList スキーマは schema.org が定義するナビゲーション階層用の構造化データで、サイト内におけるページの位置を順序付きリストで示します。実装すると Google・Bing は SERP の URL 表示を「example.com › ブログ › SEO ガイド」のようなパンくず階層に置換し、ユーザーがページの文脈を一目で把握できます。構造は @type: "BreadcrumbList" の itemListElement に ListItem 配列を持ち、各 ListItem に position (1から)、name (表示名)、item (URL) を指定します。SEO 効果は、a) URL より分かりやすい階層表示で CTR が10-15%向上、b) サイト構造の Google への明示、c) モバイル SERP での視認性向上、です。実装時の注意は、a) position は連続した整数、b) 最終ページ (現ページ) の item は省略可、c) HTML のパンくずナビゲーション表示と内容を一致させる、です。

### 実装例

- EC サイトのパンくず実装で SERP CTR が平均12%向上した事例があります
- WordPress では Yoast/RankMath プラグインで自動生成されます
- HTML 表示と JSON-LD の階層が一致しないと Google ガイドライン違反です

### 出典

- [Google Search Central - パンくずリスト (BreadcrumbList) 構造化データ](https://developers.google.com/search/docs/appearance/structured-data/breadcrumb)
- [schema.org - BreadcrumbList](https://schema.org/BreadcrumbList)

---

## 損益分岐 CPA (Break-even CPA)

URL: https://exbk.jp/glossary/break-even-cpa
読み: ソンエキブンキシーピーエー
カテゴリ: ads

### 短い定義 (TL;DR)

損益分岐 CPA は広告費と粗利が等しくなる CPA の上限値で、『商品単価 × 粗利率』で算出します。これを超える CPA で出稿し続けると赤字になるため、目標 CPA 設定の出発点となる重要数値です。

### 詳細解説

損益分岐 CPA (Break-even CPA) は『1 件の CV から得られる粗利』と等しくなる CPA で、『商品単価 × 粗利率』で算出します。例えば商品単価 10,000 円・粗利率 40% なら損益分岐 CPA は 4,000 円で、これを超えると 1 件売れるごとに赤字が拡大します。実運用では損益分岐 CPA の 70〜80% を目標 CPA に設定し、広告費以外の固定費 (人件費・LP 制作費・決済手数料) も差し引いた『真の利益が出る CPA』にバッファを持たせます。LTV の高いサブスク商材なら損益分岐 CPA を月額×継続月数×粗利率で算出し、LTV ベースでより高い CPA を許容できます。

### 実装例

- 単価 5,000 円・粗利 50% なら損益分岐 CPA は 2,500 円
- サブスク月額 980 円・継続 12 ヶ月・粗利 60% なら LTV CPA は 7,056 円
- 目標 CPA は損益分岐の 70% (=固定費含めて利益が残る水準) に設定

### 出典

- [Google Ads ヘルプ - 目標 CPA の設定](https://support.google.com/google-ads/answer/6268632)
- [Google Ads ヘルプ - 投資収益率の測定](https://support.google.com/google-ads/answer/14090)

---

## ブルートフォース攻撃 (Brute Force Attack)

URL: https://exbk.jp/glossary/brute-force
読み: ブルートフォースこうげき
カテゴリ: general

### 短い定義 (TL;DR)

ブルートフォース攻撃は、パスワードやトークンを総当たりで試行し正解を見つける攻撃で、対策はレートリミット・MFA・アカウントロック・強力なハッシュです。

### 詳細解説

ブルートフォース攻撃は、認証情報の組み合わせを片端から試行する古典攻撃で、辞書攻撃 (よくある単語リスト) ・パスワードスプレー (1パスワードを多数アカウントに) ・クレデンシャルスタッフィング (流出DB流用) などのバリエーションがあります。GPU活用でハッシュクラックは劇的に高速化しており、bcrypt / Argon2 等のメモリハード関数で計算コストを上げる必要があります。サーバー側の対策はOWASPに従い (1) レートリミット (5回失敗で15分ロック等) (2) MFA / WebAuthn 強制 (3) Captcha / Turnstile (4) 異常検知 (異常な国・IP・時間帯) (5) Have I Been Pwned API でのパスワード流出チェック を組み合わせます。アカウントロックはDoSにも転用されるため、IP別と組み合わせるなどの工夫が必要です。

### 実装例

- 5回連続失敗で15分ロックし IP も併用してDoS転用を防止
- Cloudflare Turnstile で人間判定して総当たりを抑制
- クレデンシャルスタッフィング対策に HIBP API でリーク検知

### 出典

- [OWASP - Credential Stuffing Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html)

---

## CAC (Customer Acquisition Cost (顧客獲得コスト))

URL: https://exbk.jp/glossary/cac
読み: シーエーシー
カテゴリ: general

### 短い定義 (TL;DR)

CAC (Customer Acquisition Cost) は、新規顧客一人を獲得するためにかかった総コストです。広告費だけでなく営業人件費やツール費も含めて算出します。広告投資の上限額を決める根拠となります。

### 詳細解説

CAC は、ある期間に新規獲得した顧客数で、その期間にかかったマーケティング・営業の総費用を割って算出します。式は「(マーケ費 + 営業人件費 + ツール費) ÷ 新規顧客数」です。例えば四半期で広告費1,000万円、営業人件費800万円、ツール費200万円、新規顧客200社なら CAC は10万円となります。SaaS 業界では、CAC Payback Period (CAC 回収期間) という派生指標が重要で、月次粗利益で CAC を回収できる月数を意味し、12か月以内が健全とされています。Bessemer Venture Partners の 2024年レポートでは、優良 SaaS の中央値が CAC Payback 18か月、LTV/CAC 3.5倍となっています。CAC を下げる施策は、(1) ターゲティング精度向上、(2) コンテンツマーケによるオーガニック流入増、(3) 紹介プログラム強化、(4) 営業プロセス自動化の4方向で、デジタル広告の高騰により近年は (2)(3) への投資が増えています。

### 実装例

- EC ブランドが、Meta 広告費200万円で新規購入者500人を獲得し、CAC 4,000円と算出します。
- BtoB SaaS が、四半期で営業3名+広告で2,000万円使い20社獲得、CAC 100万円・Payback 10か月と評価します。
- コーチング起業家が、ウェビナー集客費30万円で5契約、CAC 6万円を平均単価60万円と比較し10倍の収益性を確認します。

### 出典

- [Bessemer Venture Partners - State of the Cloud](https://www.bvp.com/atlas/state-of-the-cloud-2024)

---

## 計算フィールド (Looker Studio) (Calculated Field)

URL: https://exbk.jp/glossary/calculated-field
読み: ケイサンフィールド
カテゴリ: analytics

### 短い定義 (TL;DR)

計算フィールドは Looker Studio で既存フィールドから派生指標を作る機能です。SQL ライクな関数 (CONCAT・CASE・SUM・REGEXP_MATCH など 80 種類以上) で柔軟な計算ができます。

### 詳細解説

計算フィールド (Calculated Field) は Looker Studio において既存のフィールドから派生指標 (Derived Metric) や派生ディメンションを作成する機能で、SQL ライクな関数を使って柔軟な計算を実装できます。利用できる関数は 80 種類以上で、主なカテゴリは (1) 算術 (SUM・AVG・ROUND・MOD)、(2) 文字列 (CONCAT・LOWER・UPPER・REGEXP_MATCH・REGEXP_REPLACE)、(3) 条件分岐 (CASE WHEN・IF)、(4) 日付 (DATE・YEAR・MONTH・TODATE)、(5) 地理 (TOCITY・TOREGION)、(6) ウィンドウ関数 (RUNNING_SUM・RUNNING_AVG)、です。計算フィールドはデータソース全体のグローバル定義としても、個別グラフのローカル定義としても作成可能で、前者は再利用性が高く、後者は単発のグラフに最適化できます。代表的な活用例は CVR (CV ÷ セッション × 100)・ROAS (売上 ÷ 広告費)・客単価 (売上 ÷ 注文数)・カテゴリ統合 (CASE で URL からカテゴリを派生)、などです。

### 実装例

- CASE WHEN REGEXP_MATCH(URL, '/blog/.*') THEN 'ブログ' END でカテゴリを派生する
- CV ÷ セッション × 100 で CVR (%) を計算フィールドとして定義する
- RUNNING_SUM 関数で月初からの累積売上を可視化する

### 出典

- [Looker Studio 計算フィールド](https://support.google.com/looker-studio/answer/6299685)

---

## カノニカル URL

URL: https://exbk.jp/glossary/canonical-url
読み: カノニカルユーアールエル
カテゴリ: seo

### 短い定義 (TL;DR)

カノニカル URL は、同一/類似コンテンツが複数 URL で存在する場合に「正規版」を検索エンジンに伝える指定のことです。<link rel="canonical" href="..."> で head 内に記述します。

### 詳細解説

カノニカル URL は、重複コンテンツ問題を解決するために Google・Bing・Yahoo が2009年に共同で導入した正規 URL 指定の仕組みです。EC サイトのパラメータ違い (?color=red&size=L)、HTTP/HTTPS 両対応、www あり/なし、トラッキングパラメータ付き URL、AMP ページなどで「同じコンテンツが複数 URL で存在する」状況を防ぎ、被リンク評価を1つの URL に集約します。指定方法は、1) HTML の head 内に <link rel="canonical" href="https://example.com/page">、2) HTTP ヘッダー Link: <https://...>; rel="canonical"、3) サイトマップへの記載、の3通りです。Google は最終的にカノニカル指定を「シグナル」として参照しつつ独自にクラスタリングするため、誤指定でもインデックスから完全消失することはありませんが、正しい指定で評価集約とクロール効率化が実現します。

### 実装例

- ?utm_source 付き URL の評価を本体 URL に集約してリンクパワーを保ちます
- AMP ページから通常版へ canonical を指定しないと評価が分散します
- Search Console の URL 検査で実際に認識された canonical を確認できます

### 出典

- [Google Search Central - 正規 URL の統合](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls)

---

## CAPI (Conversions API) (CAPI: Conversions API (Meta CAPI))

URL: https://exbk.jp/glossary/capi
読み: シーエーピーアイ
カテゴリ: ads

### 短い定義 (TL;DR)

CAPI は Meta などの広告プラットフォームに対し、広告主のサーバーから直接コンバージョン情報を送信する仕組みです。iOS 14.5 以降の ATT 制限やブラウザ ITP のシグナルロスを補完するために必須となっています。

### 詳細解説

CAPI (Conversions API) は広告プラットフォーム (Meta、TikTok、Snap、Pinterest、LinkedIn 等) に対して、ブラウザ上のピクセル経由ではなく広告主のサーバーから HTTPS 経由で直接コンバージョン・イベントデータを送信する仕組みです。Apple の ATT (App Tracking Transparency)、Safari ITP、ブラウザのトラッキング Cookie 制限により、ピクセルだけでは 30〜50% のコンバージョンを取りこぼすため、ピクセル + CAPI のデュアルセットアップで全 CV を捕捉します。Meta CAPI が最も普及していますが、Google も Enhanced Conversions、TikTok も Events API として同等機能を提供しています。

### 実装例

- Meta ピクセル + CAPI 二重実装で iOS の CV 計測を 95% に回復
- Stape・Google Tag Manager サーバーサイドコンテナ経由で CAPI 送信
- 重複 CV を deduplication_id で除外しデータ品質を担保

### 出典

- [Meta Business - Conversions API](https://www.facebook.com/business/help/2041148702652965)
- [Meta Developers - Conversions API Documentation](https://developers.facebook.com/docs/marketing-api/conversions-api/)

---

## CES (Customer Effort Score (顧客努力指標))

URL: https://exbk.jp/glossary/ces
読み: シーイーエス
カテゴリ: general

### 短い定義 (TL;DR)

CES (Customer Effort Score) は、顧客が課題解決のために要した労力の少なさを測る指標です。Harvard Business Review が2010年に NPS よりロイヤリティ予測精度が高いと発表しました。

### 詳細解説

CES は2010年に Matthew Dixon らが Harvard Business Review に発表した『Stop Trying to Delight Your Customers (顧客を喜ばせるのはやめろ)』で提唱された指標で、「課題解決のためにどれくらい努力が必要でしたか?」を1-7段階で測ります (低スコアほど良い)。同論文では、リピート意向の予測力で NPS や CSAT を上回るとされています。代表的な質問は「この問題の解決に対する企業の対応はどの程度容易でしたか?」で、SaaS のサポート、Apple Store の購入体験、Amazon の返品プロセスなどで広く採用されています。Gartner の調査では、CES が高い (=努力が少ない) 顧客の94% がリピート購入に至り、低スコアの顧客の81% はネガティブな口コミを発信するという結果が出ています。改善施策は、(1) FAQ の充実、(2) チャットボットの精度向上、(3) 1次解決率の向上、(4) UI の簡素化、の4軸で、Customer Success の中核 KPI として位置付けられます。

### 実装例

- SaaS のサポート完了後に「解決にどれくらい労力がかかりましたか?」と CES 1-7で尋ね、5以上の比率を90% 以上維持します。
- EC が返品ページに CES 質問を設置し、低スコア理由から UI 改善とフローの簡素化を行います。
- BtoB ヘルプデスクが CES を週次モニタリングし、1次解決率を75%→85% に引き上げます。

### 出典

- [Harvard Business Review - Stop Trying to Delight Your Customers](https://hbr.org/2010/07/stop-trying-to-delight-your-customers)

---

## Chain of Thought (CoT)

URL: https://exbk.jp/glossary/chain-of-thought
読み: チェーンオブソート
カテゴリ: ai

### 短い定義 (TL;DR)

Chain of Thought (CoT) は、LLM に「段階的に考えて」と指示することで推論の中間ステップを明示させ、複雑なタスクの精度を上げるプロンプト技法です。算数・論理問題で特に有効です。

### 詳細解説

CoT は 2022 年に Google が発表した論文で広まったテクニックで、'Let's think step by step' などの 1 行を加えるだけで論理タスクの精度が劇的に向上します。OpenAI o1 / o3 系モデルは内部で自動 CoT を行うため、ユーザーが明示しなくても効果が得られます。Tree of Thoughts (ToT)、Self-consistency、Graph of Thoughts など派生手法も多数あります。

### 実装例

- 「段階的に考えてください」を指示文に追加
- 計算問題で式の展開を明示
- Anthropic Claude では <thinking> タグで内部推論を表現

### 出典

- [Wei et al., Chain-of-Thought Prompting (2022)](https://arxiv.org/abs/2201.11903)

---

## ChatGPT

URL: https://exbk.jp/glossary/chatgpt
読み: チャットジーピーティー
カテゴリ: ai

### 短い定義 (TL;DR)

ChatGPT は OpenAI 社が 2022 年 11 月に公開した対話型 AI で、世界で最も使われている LLM です。GPT-4 / GPT-5 系をバックエンドに、無料プランから企業向け Enterprise まで展開しています。

### 詳細解説

ChatGPT は 2022 年 11 月公開後 2 ヶ月で 1 億 MAU を突破し、AI ブームの火付け役となりました。Free プラン、ChatGPT Plus (月 $20)、Team、Enterprise、Edu の各プランがあり、GPT-4o / GPT-5 / o1 / o3 などのモデルから選択可能。Code Interpreter、画像生成 (DALL-E 3)、Web 検索、Custom GPT、API 経由の Function calling 等、機能拡張のスピードも速い。Claude / Gemini と並ぶ三大主要 LLM の一角。

### 実装例

- chatgpt.com で対話
- OpenAI API で社内ツール組込み
- Custom GPTs で社内 RAG 構築

### 出典

- [OpenAI ChatGPT](https://chatgpt.com)

---

## 解約率 (Churn Rate)

URL: https://exbk.jp/glossary/churn-rate
読み: カイヤクリツ
カテゴリ: general

### 短い定義 (TL;DR)

解約率 (Churn Rate) は、ある期間に解約した顧客の割合を示す指標です。サブスクモデルで最重要の KPI で、月次1% 改善するだけで LTV が大きく伸びます。わずか1% の改善で LTV が大きく伸びます。

### 詳細解説

解約率は Churn Rate とも呼ばれ、「期間中の解約数 ÷ 期間開始時点の顧客数」で算出します。月次解約率と年次解約率があり、月次2% は年次換算で約21.5% (1 - 0.98^12) になります。SaaS 業界のベンチマークとして、Bessemer Venture Partners の調査では、健全な BtoB SaaS は月次解約率1% 以下 (年次10% 以下)、BtoC は月次5% 以下が目安です。Salesforce の年次解約率は約9%、Slack は約3% (上場前) という低水準でした。解約率は LTV 計算の分母に入るため、月次 1% 改善するだけで LTV は約100% 改善するインパクトがあります。解約原因は、(1) 商品価値の不足、(2) オンボーディング失敗、(3) 価格不満、(4) 競合への乗り換え、の4類型で、Mixpanel のリテンション分析や Intercom のチャット履歴分析で原因を特定します。Net Negative Churn (アップセルが解約を上回る状態) を実現できると指数関数的成長が可能になります。

### 実装例

- BtoB SaaS がオンボーディング動画導入で月次解約率を3%→1.5% に改善し、LTV を倍増させます。
- EC サブスクが、解約理由アンケートから「飽き」を特定し、商品ローテーション機能で解約率を半減させます。
- ジムが90日継続率を65%→80% に改善し、年次解約率を50%→30% へ削減しています。

### 出典

- [Bessemer Venture Partners - State of the Cloud](https://www.bvp.com/atlas/state-of-the-cloud-2024)

---

## Claude

URL: https://exbk.jp/glossary/claude
読み: クロード
カテゴリ: ai

### 短い定義 (TL;DR)

Claude (クロード) は Anthropic 社が開発する大規模言語モデル (LLM) の名称です。Constitutional AI による安全性重視の設計で、長文処理・コーディング・分析タスクに強みがあります。Claude 4 系が最新世代です。

### 詳細解説

Claude は元 OpenAI のメンバーが 2021 年に創業した Anthropic 社の旗艦 LLM です。Claude.ai (チャット UI)、Claude Code (CLI)、Claude API (Anthropic API) で利用できます。1M トークンの巨大コンテキストウィンドウ、優れたコード生成能力、Constitutional AI による有害発話の自己抑制が特徴。Opus 4 が最高品質、Sonnet 4 がバランス型、Haiku 4 が高速・低コスト。Claude 4.7 Opus は 2026 年時点で世界最強クラスの LLM とされます。

### 実装例

- Claude Code CLI でターミナルから AI ペアプロ
- claude.ai/code でブラウザベースのエージェント
- Anthropic API 経由で自社アプリに組み込み

### 出典

- [Anthropic Claude](https://www.anthropic.com/claude)

---

## クリックジャッキング (Clickjacking / UI Redress Attack)

URL: https://exbk.jp/glossary/clickjacking
読み: クリックジャッキング
カテゴリ: general

### 短い定義 (TL;DR)

クリックジャッキングは、透明iframeで標的サイトを重ね利用者の意図と異なる操作 (送金・SNS投稿等) をクリックさせる攻撃です。対策は X-Frame-Options と CSP frame-ancestors です。

### 詳細解説

クリックジャッキング (UI Redressing) は、攻撃者サイトが標的サイトを透明な iframe で重ね、見えないボタンを利用者がクリックすることで、本人意図とは異なる操作 (SNSいいね・送金・パスワード変更) を実行させる攻撃です。Twitter・Facebook 等の事例も報告されています。対策はOWASPに従い (1) HTTPレスポンスヘッダー X-Frame-Options: DENY または SAMEORIGIN を設定 (2) より新しい CSP の frame-ancestors 'none' / 'self' を併用 (3) アプリ側でJSによるフレームバスター (top != self ならリダイレクト) は補助手段として が標準です。frame-ancestors は CSP Level 2 で導入され、X-Frame-Options より柔軟 (複数オリジン許可可能) で推奨されています。

### 実装例

- X-Frame-Options: DENY で全 iframe 埋め込みを拒否
- Content-Security-Policy: frame-ancestors 'self' で同一オリジンのみ許可
- 管理画面に DENY、公開ページに SAMEORIGIN を使い分け

### 出典

- [OWASP - Clickjacking Defense Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html)

---

## クリックマップ (Clickmap)

URL: https://exbk.jp/glossary/clickmap
読み: クリックマップ
カテゴリ: general

### 短い定義 (TL;DR)

クリックマップは、ヒートマップの一種でページ上のクリック発生位置を集計可視化したもので、CTA配置や非リンク要素への誤クリック検知に使われます。

### 詳細解説

クリックマップは、ヒートマップの主要ビューの1つで、ページ上の各位置で発生したクリック数をドット密度や色で表したものです。主な用途は (1) 主要 CTA の到達率と他要素との競合確認 (2) 「クリックされたいのにされていない要素」の発見 (3) 「クリックできないのにクリックされている要素」(画像・装飾) の検知 → リンク化による UX 改善 (4) ナビゲーション・グローバルメニューの実利用度測定 です。Microsoft Clarity / Hotjar / Crazy Egg などのツールで自動生成できます。実は「リンク不可なのに見出しっぽくてクリックされる要素」が頻発するため、それを発見してリンク追加するだけで大きな UX 改善になることがあります。デバイス別 (PC/タブレット/SP) で必ず分けて分析するのが原則です。

### 実装例

- 見出し画像が誤クリックされていれば実際にリンク化
- PC とスマホのクリックマップを別ビューで比較
- Above the Fold のクリック率で Hero 設計を評価

### 出典

- [NN/g - How to Use Heatmaps](https://www.nngroup.com/articles/heatmap-analysis/)

---

## Cline

URL: https://exbk.jp/glossary/cline
読み: クライン
カテゴリ: ai

### 短い定義 (TL;DR)

Cline (クライン) は VS Code 拡張機能の AI エージェントで、ファイル編集・ターミナル実行・ブラウザ操作を自律的にこなします。OSS で、Anthropic / OpenAI / OpenRouter 等の API キーで動作します。

### 詳細解説

Cline (旧 Claude Dev) は VS Code Marketplace で公開される無料の AI 拡張で、自分の API キーを使う持ち込み型。エージェント的動作 (タスクを与えると自律的にファイル編集・コマンド実行・ブラウザ操作する) が強み。Cursor 月 $20 を払いたくないが、AI 自律実行は欲しい人に向きます。Approve/Reject 確認のため安全性も担保されています。

### 実装例

- VS Code Marketplace から無料インストール
- 自社 API キーで利用 (持ち込みモデル)
- エージェントモードでマルチステップタスク

### 出典

- [Cline GitHub](https://github.com/cline/cline)

---

## Cloudflare R2

URL: https://exbk.jp/glossary/cloudflare-r2
読み: クラウドフレアアールツー
カテゴリ: storage

### 短い定義 (TL;DR)

Cloudflare R2 は egress (ダウンロード) 料金が無料の S3 互換オブジェクトストレージです。Amazon S3 と互換 API のため、restic / rclone 等の既存ツールがそのまま使え、バックアップ用途でコスト最適化できます。

### 詳細解説

Cloudflare R2 は 2022 年にリリースされた Cloudflare のオブジェクトストレージサービスで、AWS S3 と API 互換です。最大の特徴は egress 料金 0 円。S3 は 1GB ダウンロードに $0.09 課金されますが、R2 は無料です。バックアップ用途では「置く時」より「戻す時」が決定的に重要で、災害復旧時に 100GB ダウンロードしても無料です。保管料金は $0.015/GB/月、Class A 操作 (書込み) も大量でなければほぼ無料枠内。Cloudflare アカウントとクレジットカード登録さえ済めば 5 分で開始できます。

### 実装例

- restic + R2 で Nextcloud バックアップ月 22 円
- rclone で 1 コマンドコピー
- Workers から直接アクセスして低レイテンシ配信

### 出典

- [Cloudflare R2 Pricing](https://developers.cloudflare.com/r2/pricing/)

---

## CLS (Cumulative Layout Shift)

URL: https://exbk.jp/glossary/cls
読み: シーエルエス
カテゴリ: seo

### 短い定義 (TL;DR)

CLS (Cumulative Layout Shift) は、ページ読み込み中にレイアウトが予期せずずれた量を累積した指標です。Core Web Vitals の1つで、0.1未満が「良好」とされます。

### 詳細解説

CLS は視覚的安定性を測る指標で、ページ表示中に発生する予期しないレイアウト移動の累積スコアです。広告バナーが後から挿入されてボタンの位置がずれる、画像のサイズ指定がなく描画後にずれる、Web フォント読み込みでテキストが再配置される、といった事象が CLS を悪化させます。0.1未満が「良好」、0.1-0.25が「改善が必要」、0.25超が「不良」です。改善策は、1) img タグに width/height 属性を必ず指定、2) 広告枠の min-height を予約、3) font-display: optional または swap で FOUT 対策、4) 動的挿入要素は既存コンテンツの上ではなく下に配置、です。CLS は誤クリックの主因となるため UX 上も重要な指標です。

### 実装例

- img タグに width/height を指定するだけで CLS が0.05以下に改善します
- AdSense の自動広告は CLS を0.2以上悪化させるため固定枠運用が推奨されます
- CLS 0.25超は購入ボタンの誤タップで売上を5-10%損失する原因になります

### 出典

- [web.dev - Cumulative Layout Shift (CLS)](https://web.dev/articles/cls)

---

## Codex CLI

URL: https://exbk.jp/glossary/codex-cli
読み: コーデックスシーエルアイ
カテゴリ: ai

### 短い定義 (TL;DR)

Codex CLI は OpenAI が 2025 年にリリースしたターミナルベースの AI ペアプロツールです。Claude Code と同様、CLI から AI に対話的にコーディングを依頼できます。

### 詳細解説

Codex CLI は OpenAI 公式の OSS ツールで、`codex` コマンドでターミナルから起動します。GPT-5 / o3 系をバックエンドに、ファイル編集・コマンド実行・テスト実行などを自律的に行います。Claude Code / Aider と機能が似ており、各社独自のエージェント基盤が乱立する状況。社内承認・モデル使い分けの観点で複数併用するチームも増えています。

### 実装例

- codex で対話的タスク開始
- OpenAI API キーが必要
- Claude Code と並走で複数 AI を比較利用

### 出典

- [OpenAI Codex](https://openai.com/codex)

---

## コホート分析 (Cohort Analysis)

URL: https://exbk.jp/glossary/cohort-analysis
読み: コホートブンセキ
カテゴリ: analytics

### 短い定義 (TL;DR)

コホート分析は同じ時期に共通の特性を持つユーザーグループ (コホート) の行動を時系列で追う分析手法です。GA4 では「探索 > コホートデータ探索」で初回訪問週ごとの継続率を可視化できます。

### 詳細解説

コホート分析 (Cohort Analysis) は、同じ時期に共通の特性 (初回訪問日・初回購入日・登録日など) を持つユーザーグループ (コホート) を 1 つの集団として扱い、その後の行動を時系列で追跡する分析手法です。古くは医療や社会調査で使われていた手法で、デジタルマーケティングではユーザーの継続率 (リテンション) や LTV (顧客生涯価値) の分析に応用されます。GA4 では探索レポートの「コホートデータ探索」テンプレートで簡単に作成でき、コホート分割基準 (初回接触日)・指標 (アクティブユーザー数・コンバージョン数など)・ベース粒度 (日次・週次・月次) を選んで可視化します。表形式で「W0/W1/W2/W3...」のように週ごとの継続率が並ぶため、新規ユーザー獲得施策の効果やオンボーディング改善のインパクトを長期で評価できます。SaaS や定額課金型サービスのチャーン (解約) 分析で特に重要視されます。

### 実装例

- 新規ユーザーの 4 週間後継続率を週次コホートで可視化する
- オンボーディング改善前後で W2 継続率が 20% → 35% に改善した効果を測る
- SaaS の月次コホートでチャーン率と LTV を関連付ける

### 出典

- [[GA4] コホートデータ探索](https://support.google.com/analytics/answer/9670133)

---

## 並行同期

URL: https://exbk.jp/glossary/concurrent-sync
読み: へいこうどうき
カテゴリ: infra

### 短い定義 (TL;DR)

並行同期は、複数のクライアントが同時に同じファイル/フォルダを同期しに行く状態です。Nextcloud / Dropbox 等で 4 台以上が同時書き込みすると、ロック競合で破綻するリスクがあります。

### 詳細解説

Master-Replica 思想 (1 台がメイン編集、他は閲覧 + 検証) で運用するのが事故を避ける鉄則です。並行同期で起きる典型事故: (1) 古いクライアントが新しい除外設定を尊重せず、新しいクライアントが除外したファイルを再アップロードする無限ループ、(2) 同一ファイルを 2 台で同時編集して衝突、(3) ロックテーブルの肥大化。ドロップボックスのような商用サービスは内部で対策されているが、セルフホスト Nextcloud は管理者が運用ルールで対策する必要があります。

### 実装例

- Mac 2 台 + Win 2 台で同時同期 → 66 万件のロック詰まり (実例)
- Master-Replica で書込権を 1 台に絞る
- 全マシンで mirall バージョンと除外設定を統一

---

## 同意モード (Consent Mode)

URL: https://exbk.jp/glossary/consent-mode
読み: ドウイモード
カテゴリ: analytics

### 短い定義 (TL;DR)

同意モードは Google 広告 / GA4 がユーザーの Cookie 同意状態に応じて計測挙動を変える仕組みです。v2 が 2024 年 3 月から EU 必須となり、ad_user_data と ad_personalization が新たに追加されました。

### 詳細解説

同意モード (Consent Mode) は Google 広告・GA4・Floodlight などの Google タグが、ユーザーの Cookie 同意状態に応じて計測・広告配信の挙動を動的に変える仕組みです。v1 では analytics_storage と ad_storage の 2 種類のシグナルしかありませんでしたが、2024 年 3 月から EU・EEA・英国向けに必須となった v2 では、新たに ad_user_data (Google への広告データ送信)・ad_personalization (パーソナライズ広告) の 2 つが追加され、合計 4 種類になりました。ユーザーが同意していない場合、Google タグは Cookie を書き込まずに「Cookieless ping」を送信し、Google 側で機械学習によりコンバージョン値をモデル化補完します。これにより GDPR / ePrivacy 指令に準拠しつつ、計測損失を最小限に抑えられます。WordPress では CookieYes・Complianz などの CMP (同意管理プラットフォーム) と GTM の組み合わせが一般的な実装パターンです。

### 実装例

- CookieYes プラグインで同意バナーを設置し GTM の同意モード v2 と連携する
- ad_user_data=denied の場合に Google 広告の Cookie 書き込みを停止する
- EU ユーザーに対し analytics_storage=denied 時もモデル化計測で CV を補完する

### 出典

- [Tag Manager で同意モードを実装する](https://support.google.com/tagmanager/answer/13695607)

---

## Content Decay

URL: https://exbk.jp/glossary/content-decay
読み: コンテンツディケイ
カテゴリ: seo

### 短い定義 (TL;DR)

Content Decay (コンテンツ減衰) は、過去に検索順位上位だった記事が時間経過とともに順位とトラフィックを失う現象のことです。情報の陳腐化、競合の追い上げ、Google アルゴリズム更新が主因です。

### 詳細解説

Content Decay は、公開時点では好調だったコンテンツが時間とともに順位低下とトラフィック減少を起こす現象で、Animalz の調査 (2020) では公開後12ヶ月で平均30-50%のトラフィックを失うとされます。主な原因は、1) 情報の陳腐化 (古い統計・廃止された機能・古いツール)、2) 競合がより新しく充実した記事を公開、3) Google のアルゴリズム更新 (Helpful Content Update 等)、4) 検索意図の変化 (ユーザーニーズの変遷)、5) 内部リンクの劣化、です。対策はコンテンツリフレッシュで、a) 統計データを最新版に更新、b) 新セクションを追加 (FAQ、最新トレンド)、c) 古いスクリーンショット差し替え、d) タイトルに [2026年版] 等の年号追加、e) 公開日 + 更新日の併記、を四半期ごとに実施します。Ahrefs/Semrush で順位下落記事を抽出する「Content Audit」が標準運用です。

### 実装例

- 公開12ヶ月で平均30-50%の流入を失うため四半期に1回のリフレッシュが必須です
- [2026年版] 等のタイトル年号追加だけで CTR が15%回復することがあります
- Search Console で「順位低下」フィルタをかけ Decay 記事を抽出します

### 出典

- [Animalz - The Content Decay Toolkit](https://www.animalz.co/blog/content-decay/)

---

## コンテンツマーケティング

URL: https://exbk.jp/glossary/content-marketing
読み: コンテンツマーケティング
カテゴリ: general

### 短い定義 (TL;DR)

コンテンツマーケティング (Content Marketing) は、有益なブログ・動画・ホワイトペーパーなどを継続的に発信し、見込み客との関係を構築する手法です。インバウンドの中核実装です。長期的な資産として蓄積される強みがあります。

### 詳細解説

コンテンツマーケティングは、Content Marketing Institute (CMI) の Joe Pulizzi が体系化した手法で、「価値あるコンテンツの継続発信で顧客との信頼関係を作り、最終的に購買行動につなげる」マーケティング戦略です。代表的なフォーマットは、SEO ブログ、YouTube 動画、ホワイトペーパー、ウェビナー、Podcast、書籍出版です。Demand Metric の調査では、コンテンツマーケは伝統的アウトバウンドより62% 安く、3倍のリードを生むという結果が出ています。Salesforce はブログ「Salesforce Blog」で月間500万 PV 以上を集め、Hubspot Academy は無料認定コースで月間数万人の見込み客を育成しています。日本では LIG ブログや、ferret、SmartHR Mag がコンテンツマーケで著名です。成功要件は、(1) ペルソナ別の課題マップ作成、(2) 検索意図に合致した質の高い記事、(3) 最低12-18か月の継続発信、(4) リード獲得 CTA の埋め込み、の4点です。

### 実装例

- BtoB SaaS が「マーケ用語集」を200記事公開し、月間オーガニック流入50万を達成しています。
- EC ブランドが、YouTube で商品ハウツー動画を週2本投稿、登録者10万人で月商1億円を実現しています。
- コンサル会社が、書籍を出版し名刺代わりに配布、認知獲得から年間20件のエンタープライズ受注に繋げます。

### 出典

- [Content Marketing Institute - What is Content Marketing](https://contentmarketinginstitute.com/what-is-content-marketing/)

---

## Context window

URL: https://exbk.jp/glossary/context-window
読み: コンテキストウィンドウ
カテゴリ: ai

### 短い定義 (TL;DR)

Context window (コンテキストウィンドウ) は、LLM が一度に処理できる入力 + 出力の最大トークン数です。Claude 4 系は 200K〜1M、GPT-4o は 128K、Gemini 1.5 Pro は 2M トークンが代表的です。

### 詳細解説

Context window はモデルの性能と直結する重要指標で、長文要約・コード解析・大量データ分析の上限を決めます。2023 年は 4K〜32K が標準でしたが、2024〜2026 年で急拡大。Anthropic Claude Opus 4.7 は 1M、Claude Sonnet 4.6 は 200K、GPT-4o は 128K、Gemini 1.5 Pro は 1〜2M。長いほど良いように見えますが、長文時は精度低下や無視 (lost in the middle) も起きるため、必要十分な範囲で運用するのがベスト。

### 実装例

- Claude Opus 4.7 で書籍 1 冊 (50万字程度) を一括要約
- Gemini 1.5 Pro で 1 時間動画を直接処理
- GPT-4o で API 呼び出し時の 128K トークン上限

---

## コンバージョンイベント (Conversion Event)

URL: https://exbk.jp/glossary/conversion-event
読み: コンバージョンイベント
カテゴリ: analytics

### 短い定義 (TL;DR)

コンバージョンイベント (GA4 では「キーイベント」と改名) はビジネス成果として重要なイベントを指す指定です。Free 版で 1 プロパティあたり最大 30 個まで設定でき、Google 広告連携で入札最適化に使えます。

### 詳細解説

コンバージョンイベントは GA4 において、購入・問い合わせ・会員登録など「ビジネス成果として重要な行動」をマークするための指定です。2024 年 3 月から名称が「キーイベント (Key Event)」に変更されましたが、概念は同じで、レポート上のコンバージョンレポートに集計されたり、Google 広告にインポートして自動入札の目標として利用できます。Free 版では 1 プロパティあたり最大 30 個までコンバージョン登録ができ、設定方法は「管理 > イベント」一覧で対象イベントの「コンバージョンとしてマークを付ける」をオンにするだけです。デフォルトで purchase は自動的にコンバージョン扱いとなり、その他のイベントは管理者が任意で指定します。コンバージョン計測はモデル化されたコンバージョン (機械学習による補完) や同意モードの設定とも密接に関わるため、プライバシー対応と合わせて運用設計が必要です。

### 実装例

- form_submit_contact をコンバージョン登録し問い合わせ数を Google 広告に連携する
- purchase を CV 化し ROAS と CPA を Google 広告で自動最適化する
- engagement_time_threshold (60 秒以上滞在) を CV にマーケティング指標化する

### 出典

- [[GA4] キーイベントを設定する](https://support.google.com/analytics/answer/9267735)

---

## GitHub Copilot

URL: https://exbk.jp/glossary/copilot
読み: ギットハブコパイロット
カテゴリ: ai

### 短い定義 (TL;DR)

GitHub Copilot (コパイロット) は GitHub が提供する AI コーディング支援ツールです。OpenAI Codex を起源とし、現在は Claude / GPT-4 / Gemini も選択可能で、IDE 内でコード補完を行います。

### 詳細解説

GitHub Copilot は 2021 年公開の AI ペアプロツールで、月 $10 (Individual) / $19 (Business)。VS Code / Visual Studio / JetBrains / Neovim 等の主要 IDE 全対応で、Tab 補完・Chat・Workspace・Agent などの機能を持ちます。Microsoft 傘下なので Microsoft 365 統合も濃く、企業導入で先行。Cursor / Claude Code と比較すると統合度より対応 IDE の広さで勝ります。

### 実装例

- VS Code / JetBrains で Tab 補完
- Copilot Chat でコード相談
- Workspace で複数ファイル編集

### 出典

- [GitHub Copilot](https://github.com/features/copilot)

---

## Core Web Vitals

URL: https://exbk.jp/glossary/core-web-vitals
読み: コアウェブバイタル
カテゴリ: seo

### 短い定義 (TL;DR)

Core Web Vitals は、Google が定めるページ体験の3つの基幹指標 (LCP・INP・CLS) のことです。2024年3月に FID が INP に置き換わり、現在は読み込み速度・操作応答性・視覚安定性の3軸で評価されます。

### 詳細解説

Core Web Vitals は Google が2020年に発表したページ体験指標で、ユーザーが体感する Web ページの品質を3つの定量指標で測定します。1) LCP (Largest Contentful Paint): 最大コンテンツの表示時間、2.5秒以内が「良好」、2) INP (Interaction to Next Paint): ユーザー操作への応答性、200ms 以内が「良好」(2024年3月に FID から置換)、3) CLS (Cumulative Layout Shift): 視覚的安定性、0.1未満が「良好」。Google 検索のランキング要素として組み込まれており、PageSpeed Insights や Search Console の「ウェブに関する主な指標」レポートで測定できます。モバイルとデスクトップで別評価され、Chrome User Experience Report (CrUX) の実ユーザーデータが基準となります。

### 実装例

- LCP 2.5秒以内・INP 200ms 以内・CLS 0.1未満で全項目「良好」になります
- Core Web Vitals の不合格ページは検索順位が10-20%下がる事例があります
- 画像の lazy loading で LCP が0.5-1秒短縮するケースが多数あります

### 出典

- [web.dev - Core Web Vitals](https://web.dev/articles/vitals)
- [Google Search Central - Page experience](https://developers.google.com/search/docs/appearance/page-experience)

---

## Core Web Vitals レポート (CWV Report)

URL: https://exbk.jp/glossary/core-web-vitals-report
読み: コアウェブバイタルズレポート
カテゴリ: analytics

### 短い定義 (TL;DR)

Core Web Vitals レポートは GSC でユーザー体験に関わる 3 つの主要指標 (LCP・INP・CLS) のフィールドデータを URL グループ単位で集計するレポートです。

### 詳細解説

Core Web Vitals レポート (CWV Report) は GSC で提供されるユーザー体験 (UX) 指標のレポートで、Google が SEO ランキング要因の 1 つとして重視する 3 つの主要指標 (Core Web Vitals) を実ユーザーのフィールドデータ (Chrome User Experience Report、CrUX) に基づき集計します。3 指標は (1) LCP (Largest Contentful Paint、最大コンテンツの描画時間、Good: 2.5 秒以内)、(2) INP (Interaction to Next Paint、ユーザー操作への応答時間、Good: 200ms 以内、2024 年 3 月から FID を置換)、(3) CLS (Cumulative Layout Shift、累積レイアウトシフト、Good: 0.1 以下)、です。各指標は「良好」「改善が必要」「不良」の 3 段階で評価され、URL は類似 URL でグループ化された単位で表示されます。データはモバイル・PC で別々に集計され、それぞれの URL グループごとに該当 URL のサンプル一覧と評価結果が表示されます。Core Web Vitals 改善は SEO 順位への直接影響に加え、CVR・直帰率改善にも効果があります。

### 実装例

- LCP が 4 秒のページ群を画像最適化と CDN 導入で 2.5 秒以内に改善する
- INP 改善のため重い JavaScript の実行をデフェアし 200ms 以内に収める
- CLS 改善のため画像 width/height 属性を必ず指定し 0.1 以下を維持する

### 出典

- [Core Web Vitals レポート](https://support.google.com/webmasters/answer/9205520)

---

## CORS (Cross-Origin Resource Sharing)

URL: https://exbk.jp/glossary/cors
読み: コルス
カテゴリ: general

### 短い定義 (TL;DR)

CORS (Cross-Origin Resource Sharing) は、ブラウザの同一オリジン制約を超えてクロスオリジンHTTPリクエストを許可する仕組みです。Access-Control-* ヘッダーで制御します。

### 詳細解説

CORS は、Webブラウザのセキュリティモデル「同一オリジンポリシー」によって制限されているクロスオリジンリクエストを、サーバー側の許可で限定的に解放する仕組みです。サーバーは「Access-Control-Allow-Origin: https://exbk.jp」のようなヘッダーで許可するオリジンを返し、Cookie等の資格情報を含む場合は Access-Control-Allow-Credentials: true と具体的なオリジン指定 (ワイルドカード* と併用不可) が必要です。複雑なリクエスト (PUT/DELETE/カスタムヘッダー) では事前にOPTIONSメソッドの「プリフライトリクエスト」が走り、サーバーが許可メソッド・ヘッダー・最大キャッシュ秒数 (Access-Control-Max-Age) を返します。CORSはCSRFとは別物で、ブラウザを介さないAPI連携 (Postman・サーバー間通信) には影響しません。

### 実装例

- Access-Control-Allow-Origin: https://exbk.jp で限定許可
- プリフライト OPTIONS リクエストで PUT メソッドを許可
- withCredentials: true は具体的オリジン指定が必須

### 出典

- [MDN - Cross-Origin Resource Sharing (CORS)](https://developer.mozilla.org/docs/Web/HTTP/CORS)

---

## コサイン類似度

URL: https://exbk.jp/glossary/cosine-similarity
読み: コサインるいじど
カテゴリ: ai

### 短い定義 (TL;DR)

コサイン類似度は、2 つのベクトルの角度を比較する類似度指標です。0〜1 の範囲で、1 に近いほど似ています。Embedding ベースの検索・推薦で標準的に使われます。

### 詳細解説

コサイン類似度は cos(θ) = (A · B) / (|A| × |B|) で計算され、ベクトルの大きさを無視して方向のみで類似度を測ります。テキスト Embedding の検索ではこれが事実上のスタンダード。ユークリッド距離やマンハッタン距離より、Embedding ベクトルの性質に合っています。Pinecone / Qdrant 等の Vector DB ではデフォルトメトリクスとして採用されています。

### 実装例

- RAG で 'クエリ Embedding と文書 Embedding のコサイン類似度' で検索
- ユーザー A と B の興味類似度を計算
- FAQ 回答候補の自動マッチング

---

## CPA (CPA: Cost Per Acquisition / Cost Per Action (顧客獲得単価))

URL: https://exbk.jp/glossary/cpa
読み: シーピーエー
カテゴリ: ads

### 短い定義 (TL;DR)

CPA は 1 件のコンバージョン (購入・申込・問い合わせなど) を獲得するのにかかった広告費です。『広告費 ÷ コンバージョン数』で算出し、リスティング広告の主要 KPI として広く使われています。

### 詳細解説

CPA (Cost Per Acquisition) は 1 コンバージョンあたりの広告費を示す指標で、『広告費 ÷ CV 数』で計算します。Cost Per Action と呼ばれることもありますが意味はほぼ同じで、購入・会員登録・資料請求・問い合わせ・予約など定義した CV を 1 件獲得するのにいくら使ったかを表します。BtoC EC では CPA 3,000〜5,000 円、BtoB リード獲得では CPA 10,000〜30,000 円が業界目安ですが、商材の LTV や粗利率により損益分岐点が変わるため『目標 CPA』を粗利から逆算して設定するのが鉄則です。

### 実装例

- 広告費 30 万円で CV 100 件獲得なら CPA 3,000 円
- 目標 CPA 入札 (tCPA) を 5,000 円に設定し Google Ads に最適化を任せる
- BtoB リードの CPA 上限を LTV × 粗利率 × 0.3 で算出する

### 出典

- [Google Ads ヘルプ - 目標コンバージョン単価](https://support.google.com/google-ads/answer/6268632)
- [Meta Business - CPA について](https://www.facebook.com/business/help/717368264947302)

---

## CPC (CPC: Cost Per Click (クリック単価))

URL: https://exbk.jp/glossary/cpc
読み: シーピーシー
カテゴリ: ads

### 短い定義 (TL;DR)

CPC は 1 クリックあたりの広告費を示す指標で、『広告費 ÷ クリック数』で算出します。Google Ads・Yahoo!広告など検索広告の基本課金方式 (クリック課金) でもあります。

### 詳細解説

CPC (Cost Per Click) は広告 1 クリックあたりにかかった費用で、課金方式として『クリックされたときだけ費用が発生する』クリック課金の意味でも使われます。検索広告の業界平均は日本で 50〜500 円程度、競合の激しい金融・転職・不動産系では 1,000〜3,000 円に達することもあります。CPC は『品質スコア × 入札単価』で構成される広告ランクと競合状況で動的に決まり、品質スコアを上げると同じ表示順位でも CPC が下がります。Google Ads の『拡張 CPC (eCPC)』はベース CPC を CV 確率に応じて自動調整するハイブリッド入札方式です。

### 実装例

- 広告費 10 万円・クリック数 500 なら CPC 200 円
- 競合キーワード『カードローン』の CPC は 2,000〜3,000 円
- 品質スコアを 5→8 に上げて CPC を 30% 削減する

### 出典

- [Google Ads ヘルプ - クリック単価 (CPC)](https://support.google.com/google-ads/answer/116495)
- [IAB - Cost Per Click](https://www.iab.com/)

---

## CPI (CPI: Cost Per Install (アプリインストール単価))

URL: https://exbk.jp/glossary/cpi
読み: シーピーアイ
カテゴリ: ads

### 短い定義 (TL;DR)

CPI はモバイルアプリ 1 インストールあたりにかかった広告費を示す指標です。『広告費 ÷ インストール数』で算出し、ゲーム・SaaS アプリ・EC アプリのユーザー獲得 (UA) で主要 KPI となっています。

### 詳細解説

CPI (Cost Per Install) はアプリインストール 1 件あたりの広告費で、UA (User Acquisition) 担当者の主要 KPI です。Google Ads アプリキャンペーン (UAC)、Apple Search Ads、Meta App Install、TikTok Ads、Unity Ads、ironSource などのアプリ広告ネットワークで運用され、計測には AppsFlyer・Adjust・Singular などのモバイル計測パートナー (MMP) を使うのが一般的です。日本のゲームアプリ CPI は 200〜800 円、米国は 3〜8 ドル、ハイパーカジュアルは 50〜200 円と低く、ミッドコアゲームは 500〜2,000 円と高い傾向があります。

### 実装例

- ゲームアプリの CPI 400 円・インストール 1 万件で広告費 400 万円
- Apple Search Ads でブランドキーワード CPI 100 円を実現
- AppsFlyer で各広告媒体の CPI と LTV を比較し配分を最適化

### 出典

- [Google Ads ヘルプ - アプリキャンペーン](https://support.google.com/google-ads/answer/6247380)
- [Meta Business - アプリインストール広告](https://www.facebook.com/business/goals/app-installs)

---

## CPL (CPL: Cost Per Lead (リード獲得単価))

URL: https://exbk.jp/glossary/cpl
読み: シーピーエル
カテゴリ: ads

### 短い定義 (TL;DR)

CPL は 1 件のリード (見込み客情報) を獲得するのにかかった広告費を示す指標です。『広告費 ÷ リード数』で算出し、BtoB マーケティング・人材・不動産・保険業界の主要 KPI として使われます。

### 詳細解説

CPL (Cost Per Lead) は資料請求・問い合わせ・無料相談予約など、購買検討段階の連絡先情報 (リード) を 1 件獲得するのにかかった費用です。CPA の一種ですが、CV を『購入』ではなく『リード獲得』に絞った指標として区別されます。BtoB SaaS では CPL 5,000〜30,000 円、不動産では 10,000〜80,000 円、人材紹介では 5,000〜20,000 円が目安です。リード品質 (商談化率・受注率) を加味した SAL CPA (Sales Accepted Lead) や、最終受注単価まで遡る CAC (Customer Acquisition Cost) との併用が望まれます。

### 実装例

- BtoB SaaS 資料請求の CPL 8,000 円で月 100 件獲得
- Meta Lead Gen Forms で CPL 3,000 円を達成
- リード品質を加味して CPL ではなく商談化 CPA で評価する

### 出典

- [Meta Business - リード獲得広告](https://www.facebook.com/business/ads/lead-ads)
- [Google Ads ヘルプ - リードフォーム表示オプション](https://support.google.com/google-ads/answer/9347706)

---

## CPM (CPM: Cost Per Mille (1000 インプレッションあたり単価))

URL: https://exbk.jp/glossary/cpm
読み: シーピーエム
カテゴリ: ads

### 短い定義 (TL;DR)

CPM は広告が 1,000 回表示されるのにかかった費用を示す指標です (Mille はラテン語で 1,000)。『広告費 ÷ Imp × 1,000』で算出し、ディスプレイ広告・SNS 広告・動画広告の課金方式として広く使われています。

### 詳細解説

CPM (Cost Per Mille) は広告表示 1,000 回あたりの費用で、『広告費 ÷ インプレッション × 1,000』で計算します。Mille はラテン語の『千』を意味し、CPT (Cost Per Thousand) と表記されることもあります。インプレッション課金の場合、クリックの有無にかかわらず表示された時点で費用が発生するため、認知拡大やブランディング目的のディスプレイ・動画広告で多用されます。日本のディスプレイ広告 CPM は 200〜800 円、Meta 広告は 500〜1,500 円、YouTube ノンスキップ広告は 1,500〜2,500 円が目安です。

### 実装例

- 広告費 50,000 円・Imp 500 万なら CPM 10 円
- Meta 認知キャンペーンで CPM 800 円 → 200 万人にリーチ
- YouTube バンパー広告 CPM 2,000 円で 100 万 Imp 配信する

### 出典

- [Google Ads ヘルプ - 表示単価 (CPM)](https://support.google.com/google-ads/answer/2472735)
- [IAB - CPM Definition](https://www.iab.com/)

---

## クロールバジェット

URL: https://exbk.jp/glossary/crawl-budget
読み: クロールバジェット
カテゴリ: seo

### 短い定義 (TL;DR)

クロールバジェット (Crawl Budget) は、Googlebot が特定サイトに対して一定期間内にクロールする URL 数の上限のことです。サイト規模・サーバー応答速度・コンテンツ価値で決定されます。

### 詳細解説

クロールバジェットは、Google が公式に2017年のブログ投稿で説明した概念で、Googlebot が1サイトに対して使うクロールリソースの総量を指します。決定要因は、1) Crawl Rate Limit (サーバー応答速度・エラー率からの上限)、2) Crawl Demand (コンテンツの新鮮さ・人気度・更新頻度)、です。Google は「数千 URL 以下のサイトは気にしなくてよい、100万 URL 超の大規模サイトのみ最適化が必要」としています。最適化手法は、a) robots.txt で重複/低価値 URL をブロック、b) パラメータ付き URL をカノニカル統合、c) サイトマップで重要 URL を明示、d) 410 Gone で削除済みページを早期インデックス削除、e) サーバー応答速度を200ms 以下に維持、です。Search Console の「クロールの統計情報」で日次クロール数とレスポンスを監視できます。

### 実装例

- 100万 URL 超の EC サイトは商品在庫切れページの410返却でクロール効率改善します
- ファセットナビゲーションを robots.txt で制御しクロールバジェットを節約します
- サーバー応答が500ms 超ならクロール頻度が制限されます

### 出典

- [Google Search Central - 大規模サイト所有者向けクロール バジェット管理ガイド](https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget)

---

## CrewAI

URL: https://exbk.jp/glossary/crewai
読み: クルーエーアイ
カテゴリ: ai

### 短い定義 (TL;DR)

CrewAI は Python 製の OSS マルチエージェントフレームワークで、'役割を持ったエージェント (Crew) のチーム' を組んで協調作業させる設計です。LangChain より軽量で実装しやすいと評価されています。

### 詳細解説

CrewAI は 2024 年に登場した OSS で、Agent (役割) / Task (作業) / Crew (チーム編成) という直感的な抽象を提供。LangChain より低い学習コストで Multi-agent システムを構築できます。OpenAI / Anthropic / Ollama (ローカル LLM) など多数の LLM バックエンドに対応。マーケティングコンテンツ生成、市場調査、コード生成などのワークフロー自動化で採用が広がっています。

### 実装例

- Researcher Agent + Writer Agent でブログ自動生成
- Sales Agent + Analyst Agent で商談分析
- Python pip install crewai で導入

### 出典

- [CrewAI](https://www.crewai.com)

---

## cron

URL: https://exbk.jp/glossary/cron
読み: クロン
カテゴリ: infra

### 短い定義 (TL;DR)

cron (クロン) は Unix 系 OS で定期的にコマンドを実行する仕組みです。バックアップ・ログローテート・データ更新などの自動化に使われます。crontab で設定します。

### 詳細解説

cron は 1970 年代から存在する古典的なジョブスケジューラで、現代の Linux でも標準搭載されています。crontab -e で編集し、`0 4 * * *` のような 5 フィールド構文 (分・時・日・月・曜日) で実行タイミングを指定。systemd-timer が後継として登場していますが、シンプルな定期実行には依然 cron が広く使われます。Nextcloud のバックグラウンドジョブ (cron.php) も cron 起動が公式推奨で、AJAX や Webcron より信頼性が高いです。

### 実装例

- 0 4 * * * /usr/local/bin/backup.sh (毎日 04:00 にバックアップ)
- */5 * * * * php /var/www/html/cron.php (Nextcloud 5 分ごとジョブ)
- @reboot /opt/restart-services.sh (起動時に 1 回)

### 出典

- [cron(8) Manual](https://man7.org/linux/man-pages/man8/cron.8.html)

---

## クロスデバイス分析 (Cross-Device Analysis)

URL: https://exbk.jp/glossary/cross-device
読み: クロスデバイスブンセキ
カテゴリ: analytics

### 短い定義 (TL;DR)

クロスデバイス分析は同一ユーザーの PC・スマホ・タブレット・アプリ横断の行動を 1 つに統合する分析手法です。GA4 では User-ID と Google シグナルの組み合わせで実現します。

### 詳細解説

クロスデバイス分析 (Cross-Device Analysis) は、同じ 1 人のユーザーが複数のデバイス (PC・スマートフォン・タブレット・モバイルアプリ) を行き来して行う行動を 1 つに統合して把握するための分析手法です。GA4 ではこれを実現する仕組みとして以下 3 つを組み合わせます: (1) User-ID 機能 (自社が発行するログイン ID で紐付け)、(2) Google シグナル (Google アカウントログイン状態を活用)、(3) デバイスベース (Cookie ベースの単一デバイス識別)。レポート ID 設定で「ハイブリッド」を選ぶと最も精度が高くなります。たとえば BtoC EC で「PC で商品を検索 → スマホでブックマーク → タブレットで購入」のような複数デバイス行動が、従来は別々の 3 ユーザーとカウントされていたものが 1 ユーザー 1 セッションとして統合されます。これにより CVR・LTV・ROAS などの計算が実態に近くなり、広告ROI の正確な評価が可能になります。

### 実装例

- User-ID とシグナルを併用しデバイス間 CVR を統合する
- PC 検索 → スマホ購入のクロスデバイス CV を 30% 増として計上できる
- クロスデバイス分析の精度向上で広告 ROAS 評価が +25% 改善する

### 出典

- [[GA4] クロスデバイスのレポートと ID スペース](https://support.google.com/analytics/answer/9213390)

---

## クロスセル

URL: https://exbk.jp/glossary/cross-sell
読み: クロスセル
カテゴリ: general

### 短い定義 (TL;DR)

クロスセル (Cross-Sell) は、既存商品に関連する別商品を提案する販売手法です。Amazon の「これを買った人はこれも買っています」が代表例で、客単価向上の主要施策です。客単価向上の主要施策として広く活用されます。

### 詳細解説

クロスセルは、購入済みまたは検討中の商品に関連する別カテゴリの商品を提案する手法です。Amazon は2013年時点で売上の35% がクロスセル (Recommendation Engine) 経由と公表しており、Netflix のレコメンドも同様の効果を出しています。McKinsey の調査では、銀行業界でクロスセル比率を1顧客あたり2.5商品から3.5商品に増やすと、ROI が約20% 向上するという結果があります。クロスセルの実装は、(1) 商品ページの「合わせて購入」、(2) カートでの「最後にもう一品」、(3) 購入後メールでの関連商品提案、(4) サブスク管理画面でのアップグレード提案、(5) 営業による補完商品の提案、の5類型です。BtoB SaaS では、Salesforce が CRM に Marketing Cloud、Service Cloud をクロスセルしてアカウント単価を倍増させています。注意点は、関連性の薄い商品を提案するとブランド価値を毀損するため、データドリブンなレコメンド (協調フィルタリング、内容ベース) が必須です。

### 実装例

- EC で、購入完了後にカートサマリーで「3,000円追加で送料無料」と提示しクロスセルします。
- BtoB SaaS が CRM 顧客に MA ツールをクロスセル、アカウント単価を月額10万→25万に拡大します。
- コーチングが、メイン契約終了時に書籍・グループプログラムをクロスセルし LTV を1.5倍にします。

### 出典

- [McKinsey - Cross-Selling Strategies](https://www.mckinsey.com/business-functions/marketing-and-sales)

---

## CSAT (Customer Satisfaction Score (顧客満足度))

URL: https://exbk.jp/glossary/csat
読み: シーサット
カテゴリ: general

### 短い定義 (TL;DR)

CSAT (Customer Satisfaction Score) は、特定の商品体験やサポート対応に対する満足度を5段階または7段階で測る指標です。タッチポイント単位で測定するのが NPS との違いです。

### 詳細解説

CSAT は顧客満足度を測る最も歴史ある指標で、「今回のサポート対応にどの程度満足しましたか?」のように特定タッチポイントについて5段階または7段階 (とても満足〜とても不満) で尋ねます。算出式は「(満足+とても満足) ÷ 全回答 × 100」で、業界平均は70-85% 程度、優良企業は90% 以上を維持します。CSAT は NPS と違い、特定の体験ごとに測定するため、サポート、配送、UI/UX など個別 KPI として運用しやすい利点があります。Zendesk のグローバル調査では、CSAT 90% 以上の企業はリピート率が平均比1.7倍、口コミ発生率は2.1倍という結果が出ています。CSAT の改善には、(1) 不満点のテキスト分析、(2) 直近1か月の低スコア顧客への個別フォロー、(3) サポート対応時間の短縮、が定石です。月次や週次の継続モニタリングがリテンション維持の起点になります。

### 実装例

- EC が配送完了メールに CSAT 5段階アンケートを埋め込み、4か5の回答比率を週次で追跡します。
- SaaS のチャットサポートが、対応終了時に1問 CSAT を聞き、エージェント別の満足度を可視化します。
- 美容サロンが施術後 LINE で CSAT 調査、平均4.5/5 を維持目標としリピート促進に活用します。

### 出典

- [Zendesk - Customer Experience Trends Report](https://www.zendesk.com/customer-experience-trends/)

---

## CSP (Content Security Policy)

URL: https://exbk.jp/glossary/csp
読み: シーエスピー
カテゴリ: general

### 短い定義 (TL;DR)

CSP (Content Security Policy) は、ブラウザに読み込み許可するスクリプト・スタイル・画像等の出所をホワイトリストで指定するセキュリティ機構で、XSS対策の主要手段です。

### 詳細解説

CSP は、HTTPレスポンスヘッダー「Content-Security-Policy」または meta タグで、ブラウザが許可するリソース取得元を細かく制御するW3C仕様です。ディレクティブとして default-src / script-src / style-src / img-src / connect-src / frame-ancestors / form-action などがあり、'self' / 'none' / nonce-xxx / 'strict-dynamic' / hash-値 などの指定が可能です。'unsafe-inline' と 'unsafe-eval' はXSSを許容するため避けるのが原則で、代わりにnonce方式 (リクエストごとにランダムnonceを生成) や hash方式が推奨されます。違反検知のためreport-to / report-uri ディレクティブで違反レポートを集約できます。CSP3 では 'strict-dynamic' により信頼スクリプトが動的に他スクリプトを読み込めるようになっています。

### 実装例

- Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-rAnd0m'
- frame-ancestors 'none' でクリックジャッキング対策
- report-uri /csp-report で違反を Sentry に転送

### 出典

- [MDN - Content Security Policy (CSP)](https://developer.mozilla.org/docs/Web/HTTP/CSP)
- [W3C - Content Security Policy Level 3](https://www.w3.org/TR/CSP3/)

---

## CSRF (Cross-Site Request Forgery)

URL: https://exbk.jp/glossary/csrf
読み: シーエスアールエフ
カテゴリ: general

### 短い定義 (TL;DR)

CSRF (Cross-Site Request Forgery) は、ログイン中のユーザーのCookieを悪用し意図しない操作を実行させる攻撃で、対策にはCSRFトークンやSameSite Cookieが用いられます。

### 詳細解説

CSRF は、ユーザーが正規サイトにログイン済みの状態で、悪意あるサイトに誘導されると、ブラウザが自動付与するセッションCookieを使って利用者の意思に反した送金・パスワード変更・投稿等を実行されてしまう攻撃です。対策はOWASPに従い、(1) CSRFトークン (リクエストごとにランダム値を埋め込みサーバー検証) (2) SameSite=Lax/Strict Cookie 属性 (3) Origin/Refererヘッダー検証 (4) ダブルサブミットCookieパターン などを多層で適用します。SameSite=Lax は2020年以降の主要ブラウザでデフォルトになり、トップレベルナビゲーション以外のクロスサイトCookie送信を抑制します。状態変更を伴う操作は必ずPOST/PUT/DELETEで、GETでは行わないことも基本原則です。

### 実装例

- Set-Cookie: session=abc; SameSite=Lax; Secure; HttpOnly
- フォーム送信時に hidden で _csrf トークンを埋め込み検証
- Origin ヘッダーが自ドメイン以外のリクエストを拒否

### 出典

- [OWASP - Cross-Site Request Forgery Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html)

---

## CTR (Click Through Rate)

URL: https://exbk.jp/glossary/ctr
読み: シーティーアール
カテゴリ: seo

### 短い定義 (TL;DR)

CTR (クリック率) は、検索結果や広告が表示された回数 (インプレッション) のうち、実際にクリックされた割合のことです。CTR = クリック数 ÷ 表示回数 × 100 で算出します。

### 詳細解説

CTR は Click Through Rate の略で、ある要素が表示された回数のうち何%がクリックされたかを示す指標です。Google Search Console では SERP に表示された自社ページのインプレッションとクリック数から CTR が自動計算されます。Advanced Web Ranking の2025年データによると、自然検索1位の平均 CTR は27.6%、2位は15.8%、3位は11.0%、10位は2.4% です。CTR を改善する手段としてはタイトルタグの最適化 (60文字以内・数値や [2026年版] などの修飾語追加)、メタディスクリプションの再執筆 (150文字前後)、構造化データによるリッチリザルト獲得などがあります。

### 実装例

- 1位表示でも CTR が10%未満なら、タイトル改善で30%向上が期待できます
- Search Console で CTR が平均より低いページを特定して優先改善します
- リッチスニペット獲得でクリック率が1.5-2倍に伸びる事例が多数あります

### 出典

- [Google Search Console - 検索パフォーマンスレポート](https://support.google.com/webmasters/answer/7042828)

---

## CTR (広告) (CTR: Click Through Rate (クリック率))

URL: https://exbk.jp/glossary/ctr-ads
読み: シーティーアール
カテゴリ: ads

### 短い定義 (TL;DR)

CTR は広告が表示された回数に対するクリックの割合を示す指標です。『クリック数 ÷ インプレッション × 100%』で算出し、広告クリエイティブの魅力度・ターゲティング精度を測る基本指標となっています。

### 詳細解説

CTR (Click Through Rate) は広告のクリック率で、『クリック数 ÷ インプレッション × 100%』で計算します。Google 検索広告の業界平均 CTR は 3〜5%、ディスプレイ広告は 0.3〜1%、Meta 広告は 0.9〜1.5%、YouTube 動画広告 (TrueView) は 0.5〜0.8% が目安です。CTR は広告ランク・品質スコアの主要シグナルで、CTR が高いと広告ランクが上がり同じ入札でも上位表示されやすくなります。一方、Imp 数が極端に少ない状態の高 CTR は信頼性が低く、最低 1,000 imp 以上を集めてから判断するのが定石です。

### 実装例

- 検索広告で Imp 10,000・クリック 400 なら CTR 4%
- ディスプレイ広告 CTR 0.5% は業界平均並みと評価
- A/B テストで広告見出しを変更し CTR を 2.1%→3.4% に改善

### 出典

- [Google Ads ヘルプ - クリック率 (CTR)](https://support.google.com/google-ads/answer/2615875)
- [IAB - Click Through Rate](https://www.iab.com/)

---

## Cursor

URL: https://exbk.jp/glossary/cursor
読み: カーソル
カテゴリ: ai

### 短い定義 (TL;DR)

Cursor (カーソル) は AI ファーストの IDE で、VS Code をフォークして Claude / GPT / Gemini を深く統合しています。Tab 補完の精度と、Compose / Agent 機能で開発者から人気です。

### 詳細解説

Cursor は Anysphere 社が開発する商用 IDE で、Pro プラン月 $20 / Business 月 $40。VS Code 互換のため既存拡張機能がそのまま動き、AI 機能 (Tab 補完・Cmd+K 編集・Composer・Agent) が深く統合されています。コードベース全体を Embedding 化して文脈を理解する点が、GitHub Copilot との差別化ポイント。Claude Code / Aider と並ぶ 'AI ペアプロ' のデファクトツールの一角です。

### 実装例

- Cursor Tab で次のコードブロックを予測補完
- Cmd+K で選択範囲を AI で書き換え
- Composer で複数ファイル横断編集

### 出典

- [Cursor](https://cursor.com)

---

## カスタムオーディエンス (Custom Audience (Meta) / Customer Match (Google))

URL: https://exbk.jp/glossary/custom-audience
読み: カスタムオーディエンス
カテゴリ: ads

### 短い定義 (TL;DR)

カスタムオーディエンスは広告主が保有するメールアドレス・電話番号・顧客 ID リストをハッシュ化して広告プラットフォームにアップロードし、その人々に直接広告配信する機能です。1st party データ活用の中核です。

### 詳細解説

カスタムオーディエンス (Meta) / Customer Match (Google Ads) / カスタムセグメント (Yahoo!広告) は広告主の保有する顧客リスト (メールアドレス・電話番号・氏名・郵便番号・モバイル広告 ID など) を SHA-256 ハッシュ化して広告プラットフォームにアップロードし、それらの個人にダイレクトに広告配信する機能です。Cookie 制限・ATT 制限後の主力ターゲティング手法で、自社データをマッチングしてリピーター育成・休眠顧客掘り起こし・LTV 上位顧客への限定オファー配信などに使われます。Meta では数百名以上、Google では 1,000 名以上のリストサイズが推奨されます。

### 実装例

- 休眠顧客 1 万人にメールアドレスで Meta カスタムオーディエンス配信
- LTV 上位 5% 顧客に Google Customer Match で限定 LP に誘導
- リスト 1 万件 → 類似 Lookalike 1% → 新規顧客獲得の二段構え

### 出典

- [Meta Business - カスタムオーディエンス](https://www.facebook.com/business/help/744354708981227)
- [Google Ads ヘルプ - カスタマーマッチ](https://support.google.com/google-ads/answer/6379332)

---

## カスタムディメンション (Custom Dimension)

URL: https://exbk.jp/glossary/custom-dimension
読み: カスタムディメンション
カテゴリ: analytics

### 短い定義 (TL;DR)

カスタムディメンションは GA4 のレポートでカスタムパラメータやユーザープロパティを軸として使えるよう登録する設定です。イベントスコープで最大 50 個 (Free)、ユーザースコープで最大 25 個まで作成できます。

### 詳細解説

カスタムディメンションは GA4 のレポートや探索でカスタムパラメータ・ユーザープロパティを「軸 (ディメンション)」として使えるようにするための登録設定です。イベントで送信したカスタムパラメータは登録しない限りレポートに表示されないため、必ず「管理 > カスタム定義」で登録する必要があります。スコープは 4 種類あり、Free 版での上限はイベントスコープ 50 個・ユーザースコープ 25 個・アイテムスコープ 10 個 (EC 用)・セッションスコープも提供されます。360 版ではそれぞれ 125・100・25 個まで拡大されます。登録すると当日からレポートに反映されますが、過去データへの遡及はできない点に注意が必要です。命名は分かりやすい日本語表示名 (例: 会員ランク) を付けつつ、内部 API 名はパラメータ名と一致させるのが運用ルールです。

### 実装例

- イベントパラメータ form_name をカスタムディメンション「フォーム名」として登録する
- user_property の membership_level をユーザースコープのディメンションに登録する
- EC のアイテムスコープ item_brand_jp を登録しブランド別売上を見る

### 出典

- [[GA4] カスタム ディメンションと指標](https://support.google.com/analytics/answer/10075209)

---

## カスタムイベント (Custom Event)

URL: https://exbk.jp/glossary/custom-event
読み: カスタムイベント
カテゴリ: analytics

### 短い定義 (TL;DR)

カスタムイベントは GA4 で開発者が独自に定義する任意のイベントです。標準イベントや拡張計測でカバーできない特殊な行動 (CTA クリック・チャット起動など) を計測するために使用します。

### 詳細解説

カスタムイベントは GA4 において、Google が定義する標準推奨イベント (purchase、login、search など) や拡張計測機能でカバーできない独自のユーザー行動を計測するため、開発者が任意に作成するイベントです。実装方法は gtag('event', 'cta_click', {position: 'header'}) のようなコードを直接埋め込む方法と、GTM のタグで送信する方法の 2 通りがあります。1 プロパティあたりカスタムイベント名は実質無制限ですが、ユニークなイベント名はプロパティあたり最大 500 個までという制限があります。命名規則は英数字とアンダースコア、先頭は文字 (数字不可)、予約語 (ga_、google_、firebase_) は使用不可、最大 40 文字までです。カスタムイベントをコンバージョンとして扱うには、管理画面の「コンバージョン」設定で個別にオンにする必要があり、Free 版では最大 30 個までイベントをコンバージョン登録できます。

### 実装例

- cta_click イベントを実装しヘッダー CTA のクリック数を計測する
- chat_open イベントで Tawk.to チャット起動回数を取得する
- lead_form_submit イベントを GTM で送信し問い合わせを CV 計上する

### 出典

- [[GA4] カスタム イベントを作成する](https://support.google.com/analytics/answer/12229021)

---

## カスタム指標 (Custom Metric)

URL: https://exbk.jp/glossary/custom-metric
読み: カスタムシヒョウ
カテゴリ: analytics

### 短い定義 (TL;DR)

カスタム指標は GA4 のレポートで数値型のカスタムパラメータを集計対象として使えるよう登録する設定です。Free 版で 1 プロパティ最大 50 個まで、合計 (sum)・平均 (avg) などで集計できます。

### 詳細解説

カスタム指標は GA4 のレポートや探索で、数値型のカスタムイベントパラメータを「指標 (メトリクス)」として集計できるようにする登録設定です。たとえば「購入金額」「動画視聴秒数」「読了スクロール深度」などの数値を value パラメータで送信し、それをカスタム指標として登録することで合計・平均・最小・最大などの形でレポートに表示できます。Free 版での上限は 1 プロパティあたり 50 個 (360 版で 125 個) で、登録時には測定単位 (標準・通貨・距離・時間など) を指定します。注意点として、登録はイベント単位でなく「パラメータ単位」のため、複数イベントで同名の数値パラメータを使うと一括で集計対象になります。また、登録は当日以降のデータにのみ適用され、過去データへの遡及はできないため、計測設計初期にカスタムディメンションと併せて整備しておくことが重要です。

### 実装例

- scroll_depth (数値) をカスタム指標に登録し平均読了率を可視化する
- video_watch_seconds の合計を集計し 1 訪問あたり視聴時間を出す
- EC で discount_amount をカスタム指標化し割引総額を集計する

### 出典

- [[GA4] カスタム ディメンションと指標](https://support.google.com/analytics/answer/10075209)

---

## カスタマージャーニー

URL: https://exbk.jp/glossary/customer-journey
読み: カスタマージャーニー
カテゴリ: general

### 短い定義 (TL;DR)

カスタマージャーニー (Customer Journey) は、顧客が商品を認知してから購入、ファン化に至るまでの一連の体験プロセスを時系列で可視化したものです。各接点での心理状態と行動を地図化します。

### 詳細解説

カスタマージャーニーは、顧客が「認知 → 興味関心 → 比較検討 → 購入 → 利用 → 推奨」といったステージを移動する旅路を、タッチポイント、感情、課題、KPI とともに俯瞰するフレームワークです。Forrester Research が2010年代に体系化を進め、現在は多くの企業がカスタマージャーニーマップを作成しています。例えば SaaS の Salesforce では、平均で18のタッチポイントを経て契約に至るというデータがあり、各段階で適切なコンテンツ提供が求められます。マップを描く際は、横軸にステージ、縦軸に「行動」「思考」「感情」「タッチポイント」「課題」「施策」の6行を置くのが一般的です。これにより、自社のコミュニケーションに穴がないかを可視化でき、特に検討フェーズでの離脱対策やオンボーディング設計に役立ちます。AI 解析の進化で、行動ログから自動的にジャーニーを推定する Customer Data Platform (CDP) の活用も進んでいます。

### 実装例

- BtoB の場合、Google 検索 → ホワイトペーパーDL → メルマガ受信 → ウェビナー参加 → 商談 → 契約という6ステップでマップを描きます。
- EC アパレルでは、Instagram 広告 → LP → カート投入 → カゴ落ち → リマインドメール → 購入という流れで、カゴ落ち率の改善を狙います。
- 美容サロンが、初回来店 → リピート判定60日 → サブスク誘導 → 友人紹介という顧客旅路を可視化し、紹介キャンペーンの起動タイミングを設計します。

### 出典

- [Salesforce - What is a Customer Journey Map?](https://www.salesforce.com/resources/articles/customer-journey-mapping/)

---

## CV (コンバージョン) (CV: Conversion (成果))

URL: https://exbk.jp/glossary/cv
読み: シーブイ
カテゴリ: ads

### 短い定義 (TL;DR)

CV は広告経由でユーザーが目的の行動 (購入・申込・問い合わせ等) を取った件数を指します。広告主が定義する『成果』そのもので、CPA・CVR・ROAS などすべての KPI の分子になる基本データです。

### 詳細解説

CV (Conversion) は広告経由のユーザーが定義された目的行動を達成することで、購入完了、会員登録、資料請求、問い合わせ、予約、アプリインストール、動画視聴完了、特定ページ閲覧などサイトのゴール設定に応じて自由に定義します。Google Ads では『コンバージョンアクション』として複数登録でき、それぞれに価値 (金額) を割り当ててスマート自動入札の最適化対象にします。重要な CV を『プライマリ』、参考値を『セカンダリ』と区分けして最適化対象を絞るのが運用のコツです。GA4 では『キーイベント』として再定義されました。

### 実装例

- EC サイトで購入完了を CV と定義し 1 件 = 商品単価をコンバージョン値に設定
- 資料請求と問い合わせを別々の CV として記録し質を比較する
- プライマリ CV のみ最適化対象に指定し補助 CV を除外する

### 出典

- [Google Ads ヘルプ - コンバージョントラッキング](https://support.google.com/google-ads/answer/1722022)
- [Meta Business - コンバージョンの計測](https://www.facebook.com/business/help/742478679120153)

---

## CVR (コンバージョン率) (CVR: Conversion Rate)

URL: https://exbk.jp/glossary/cvr
読み: シーブイアール
カテゴリ: ads

### 短い定義 (TL;DR)

CVR は広告クリック (またはセッション) に対するコンバージョン件数の割合で、『CV 数 ÷ クリック数 × 100%』で算出します。LP の説得力やオファー強度を測る指標として使われます。

### 詳細解説

CVR (Conversion Rate) は広告クリックを訪問者がどれだけ CV に転換したかの割合で、『CV 数 ÷ クリック数 × 100%』で計算します。Google 検索広告の業界平均 CVR は 3〜6%、Meta 広告は 1〜3%、BtoB リード獲得は 5〜15% が目安です。CVR が低い場合は LP のヘッドライン・オファー・フォーム入力項目数・ファーストビュー画像などを A/B テストで改善するのが王道で、フォーム項目を 8 項目→4 項目に減らすだけで CVR が 2 倍になる事例も多数あります。デバイス別・広告グループ別・時間帯別に CVR を分解して改善ポイントを特定します。

### 実装例

- クリック 1,000・CV 30 件なら CVR 3%
- フォーム項目を 10→4 に削減して CVR を 1.5%→3.2% に倍増
- PC 版 CVR 4% / モバイル版 CVR 1.5% の差をデバイス別入札で調整

### 出典

- [Google Ads ヘルプ - コンバージョン率について](https://support.google.com/google-ads/answer/2684489)
- [Meta Business Help - コンバージョン率](https://www.facebook.com/business/help)

---

## データドリブンアトリビューション (DDA: Data-Driven Attribution)

URL: https://exbk.jp/glossary/data-driven-attribution
読み: データドリブンアトリビューション
カテゴリ: ads

### 短い定義 (TL;DR)

データドリブンアトリビューション (DDA) は機械学習で各広告接点の貢献度を動的に配分するアトリビューションモデルです。ルールベースの限界を克服する次世代モデルとして Google・GA4 のデフォルトに採用されています。

### 詳細解説

データドリブンアトリビューション (Data-Driven Attribution, DDA) は機械学習を用いて各広告接点の CV 貢献度を動的に配分するアトリビューションモデルで、Google Ads・GA4 で 2023 年からデフォルトとなりました。仕組みは『CV した経路』と『CV しなかった経路』を比較し、特定の接点があるとき/ないときの CV 確率差から各接点の真の貢献度を推定するというもので、Shapley 値と呼ばれるゲーム理論ベースの手法が用いられています。ルールベースモデル (ラスクリ・ファースト・線形・時間減衰・接点ベース) の主観性を排除し、媒体ごとの真の効果を可視化できます。

### 実装例

- GA4 デフォルトの DDA で Meta 動画広告の真の CPA を再評価
- DDA 導入後にディスプレイ広告予算を 30% 増額する判断
- ラスクリ→DDA で予算配分を最適化し全体 CPA を 15% 改善

### 出典

- [Google Ads ヘルプ - データドリブン アトリビューション](https://support.google.com/google-ads/answer/6394265)
- [GA4 ヘルプ - データドリブン アトリビューション](https://support.google.com/analytics/answer/10596866)

---

## データレイヤー (Data Layer)

URL: https://exbk.jp/glossary/data-layer
読み: データレイヤー
カテゴリ: analytics

### 短い定義 (TL;DR)

データレイヤーは GTM がサイト側からイベント情報を受け取るための JavaScript 配列 (window.dataLayer) です。サイト改修なしに新タグを追加できる、計測の中核的な仕組みです。

### 詳細解説

データレイヤー (Data Layer) は GTM がサイト側から計測情報を受け取るための JavaScript 配列で、グローバル変数 window.dataLayer として定義されます。サイト側で dataLayer.push({event: 'purchase', value: 3000, currency: 'JPY'}) のような形でイベント情報をプッシュすると、GTM がそれを受信して対応するトリガーで該当タグを発火させます。データレイヤーを正しく設計することで、サイトを改修せずに新しい計測タグを追加できるため、運用効率と保守性が大幅に向上します。GTM の e コマース実装 (GA4 拡張 e コマース) では、商品データを items 配列としてデータレイヤーに格納するスキーマが標準化されており、Shopify・Magento・WooCommerce などの主要 EC プラットフォームでは公式プラグインで自動生成されます。データレイヤーは初回ページ読み込み時に静的に定義しても良いし、ユーザー操作に応じて動的に push しても良く、両方を併用するのが一般的なパターンです。

### 実装例

- purchase 完了時に dataLayer.push でトランザクション ID と商品情報を送信する
- ログイン時に user_id と membership_level をデータレイヤーに格納する
- Shopify 公式プラグインで e コマースデータレイヤーを自動生成する

### 出典

- [Tag Manager データレイヤー](https://support.google.com/tagmanager/answer/6164391)

---

## データ保持期間 (Data Retention)

URL: https://exbk.jp/glossary/data-retention
読み: データホジキカン
カテゴリ: analytics

### 短い定義 (TL;DR)

データ保持期間は GA4 でユーザー単位・イベント単位のデータを保管する最大期間の設定です。Free 版は 2 ヶ月または 14 ヶ月、360 版は最大 50 ヶ月まで選択でき、初期値は 2 ヶ月です。

### 詳細解説

データ保持期間は GA4 においてユーザー単位・イベント単位の詳細データを保管する最大期間を指す設定で、「管理 > データ収集と修正 > データ保持」から変更できます。Free 版では 2 ヶ月または 14 ヶ月の 2 択、360 版では 2・14・26・38・50 ヶ月から選択可能で、初期値は Free 版で 2 ヶ月に設定されているため、プロパティ作成直後に 14 ヶ月への変更を強く推奨します。なおこの設定は「探索」レポートやカスタムレポートで利用できる詳細データの保持に影響し、標準レポート (集客・エンゲージメント等) の集計済みデータは設定に関係なく無期限で残ります。BigQuery にエクスポートしたデータは BigQuery 側のテーブル保持ポリシーで管理されるため、長期保管が必要な場合は GA4 の保持期間に依存せず BigQuery 連携が推奨です。設定変更は当日以降のデータに即時反映されますが、過去に削除されたデータは復元できません。

### 実装例

- プロパティ作成直後にデフォルト 2 ヶ月から 14 ヶ月へ変更する
- GDPR 対応として保持期間を最短 2 ヶ月に設定し BigQuery で長期保管する
- 新しいユーザーアクティビティのリセット (オン) を有効にし継続活動を保持する

### 出典

- [[GA4] データ保持期間](https://support.google.com/analytics/answer/7667196)

---

## データソース (Looker Studio) (Data Source)

URL: https://exbk.jp/glossary/data-source
読み: データソース
カテゴリ: analytics

### 短い定義 (TL;DR)

データソースは Looker Studio でレポートが参照する元データへの接続定義です。コネクタ経由で 1,000 以上のサービスと接続でき、ライブ接続またはデータ抽出 (キャッシュ) を選択できます。

### 詳細解説

データソース (Data Source) は Looker Studio においてレポートが参照する元データへの接続定義で、ダッシュボード作成の出発点となる重要な要素です。Google が提供する公式コネクタは 25 種類以上 (GA4・GSC・Google Ads・YouTube Analytics・BigQuery・Google Sheets・MySQL など) で、サードパーティパートナーが提供するコネクタを含めると 1,000 以上のデータソースと接続できます。データソース作成時には (1) コネクタの選択、(2) 認証情報の入力、(3) 対象テーブル/プロパティの選択、(4) フィールドのデータ型・集計方法・メタデータの定義、を行います。接続方式はリアルタイムにクエリを発行する「ライブ接続」と、定期的に取り込んでキャッシュする「データ抽出 (Extract)」の 2 種類があり、後者は最大 100MB までのデータをキャッシュでき表示速度が大幅に向上します。1 レポートに最大 75 個のデータソースを紐付けでき、ブレンド機能と組み合わせて複雑な統合分析が可能です。

### 実装例

- GA4 プロパティをデータソース化しコンバージョン推移カードを作る
- Google Sheets の予算管理表をデータソースに追加し実績と並べる
- BigQuery のカスタム SQL をデータソースとして接続し詳細分析する

### 出典

- [Looker Studio データソース](https://support.google.com/looker-studio/answer/6268208)

---

## DCO (動的クリエイティブ最適化) (DCO: Dynamic Creative Optimization)

URL: https://exbk.jp/glossary/dco
読み: ディーシーオー
カテゴリ: ads

### 短い定義 (TL;DR)

DCO は配信時にユーザー属性・デバイス・地域・閲覧履歴に応じてクリエイティブの組み合わせを動的に変更する技術です。1 つの広告枠に対して数万通りの組み合わせから AI が最適なバージョンを瞬時に選択します。

### 詳細解説

DCO (Dynamic Creative Optimization) は配信時にユーザーの属性・デバイス・地域・時間帯・閲覧履歴に応じて、広告クリエイティブの『画像 × 見出し × 説明文 × CTA』の組み合わせを動的に最適化する技術です。例えばパーツとして画像 5 種・見出し 5 種・説明文 5 種・CTA 3 種を入稿すると、5×5×5×3 = 375 通りの組み合わせから AI が個々のユーザーに最適な 1 つを瞬時に選んで配信します。動的リマーケティングの一種ですが、リマケが『閲覧商品を表示』なのに対し、DCO は『商品以外も含めた全クリエイティブ要素』を最適化する点が異なります。Google レスポンシブディスプレイ・Meta Advantage+ Creative・Criteo などが代表的な実装です。

### 実装例

- EC サイトで画像 10 枚 + 見出し 5 個入稿し DCO で配信を最適化
- Meta Advantage+ Creative でクリエイティブを自動最適化
- Criteo で web 閲覧履歴に基づきパーソナライズしたバナー配信

### 出典

- [Google Ads ヘルプ - レスポンシブ ディスプレイ広告](https://support.google.com/google-ads/answer/7005917)
- [Meta Business - Advantage+ Creative](https://www.facebook.com/business/help/170372403538781)

---

## DDoS 攻撃 (Distributed Denial of Service)

URL: https://exbk.jp/glossary/ddos
読み: ディードスこうげき
カテゴリ: general

### 短い定義 (TL;DR)

DDoS 攻撃は、多数の攻撃元から大量のトラフィックを送り込みサービスを停止させる攻撃で、対策はCDN・スクラビングセンター・レートリミットの多層防御です。

### 詳細解説

DDoS (Distributed Denial of Service) 攻撃は、ボットネットや反射増幅 (DNS/NTP/Memcached) を駆使して標的に大量のトラフィックを送り、帯域・接続数・CPU等のリソースを枯渇させてサービスを停止させる攻撃です。レイヤー別に L3/L4 (UDP flood・SYN flood・反射増幅) と L7 (HTTP flood・Slowloris・Cache busting) があり、近年は Tbps 級の超大型攻撃も観測されています。対策は (1) CDN / Anycast (Cloudflare・Akamai・AWS Shield) によるグローバル分散吸収 (2) スクラビングセンターでの異常検知遮断 (3) レートリミット (4) Bot Management で正規ユーザーと攻撃者を識別 (5) BGP FlowSpec でアップストリーム協調 が代表的です。HTTP/2 Rapid Reset (CVE-2023-44487) のような新型脆弱性も継続的に発生します。

### 実装例

- Cloudflare の無償プランでも L3/L4 DDoS は無制限緩和
- HTTP/2 Rapid Reset (2023) で過去最大 398M rps を観測
- AWS Shield Advanced で DDoS Cost Protection を適用

### 出典

- [Cloudflare - What is a DDoS Attack?](https://www.cloudflare.com/learning/ddos/what-is-a-ddos-attack/)

---

## De-indexing

URL: https://exbk.jp/glossary/de-indexing
読み: デインデックシング
カテゴリ: seo

### 短い定義 (TL;DR)

De-indexing (デインデックシング) は、検索エンジンのインデックスから特定ページや全サイトが削除されることです。意図的な削除と、ペナルティによる強制削除の2通りがあります。

### 詳細解説

De-indexing は、検索エンジンのインデックスから URL が除外され検索結果に表示されなくなる状態を指します。意図的な手段は、1) noindex メタタグ (<meta name="robots" content="noindex">)、2) X-Robots-Tag HTTP ヘッダー、3) Search Console の「URL 削除ツール」(6ヶ月一時非表示)、4) 404/410 ステータスでの削除応答、5) Google からのコンテンツ削除リクエスト、があります。意図せざる De-indexing は、a) Google 手動ペナルティ (スパム判定)、b) アルゴリズムアップデート (ヘルプフルコンテンツ等) による評価急落、c) ハッキングでマルウェア混入、d) サーバー長期ダウン、で発生します。De-indexing 検出は Search Console の「ページ」レポートと「セキュリティと手動による対策」で行い、サイトトラフィックの急減時には必ず確認すべき項目です。

### 実装例

- noindex を付けると平均1-2週間でインデックスから削除されます
- 手動ペナルティの解除には再審査リクエストとスパム要因の完全除去が必要です
- サイトリニューアル時の URL 変更で意図せず De-indexing が起きやすいです

### 出典

- [Google Search Central - インデックス登録から URL を削除する](https://developers.google.com/search/docs/crawling-indexing/remove-information)

---

## 重複排除

URL: https://exbk.jp/glossary/deduplication
読み: じゅうふくはいじょ
カテゴリ: storage

### 短い定義 (TL;DR)

重複排除 (deduplication) は、同じ内容のデータブロックを 1 つだけ保存することでストレージ容量を削減する技術です。restic / BorgBackup などの現代的バックアップツールが標準採用。

### 詳細解説

重複排除は固定長または可変長のチャンクごとにハッシュを取り、同一ハッシュのチャンクは参照のみ保存することで実容量を圧縮する技術です。10 個の世代分バックアップでも、変更分だけが新規データとして加算されるため、見た目「フル × 10」でも実容量は「初回 + 変更分」で済みます。restic は CDC (Content-Defined Chunking) を採用しており、ファイル境界に依存せず重複検出が効きます。当方の実例では 16.7GB のデータが R2 上 5GB に圧縮 (圧縮率 2.56x)、世代を増やしても容量が線形に増えません。

### 実装例

- restic backup で 7 世代取っても実容量は初回 × 1.5 程度
- ZFS dedup (リソース重い、限定的に使用)
- 重複排除付きバックアップアプライアンス

---

## デモグラフィック配信 (Demographic Targeting (デモグラ配信))

URL: https://exbk.jp/glossary/demographic-targeting
読み: デモグラフィックハイシン
カテゴリ: ads

### 短い定義 (TL;DR)

デモグラフィック配信は性別・年齢・世帯収入・学歴・配偶者有無・子供有無などの人口統計属性でターゲティングする手法です。広告のすべての媒体で基礎となる絞り込み軸です。

### 詳細解説

デモグラフィック配信 (Demographic Targeting) は性別・年齢・世帯収入・学歴・配偶者有無・子供有無・子供の年齢など人口統計属性でターゲティングする手法です。Google Ads では性別・年齢・世帯収入 (米国・日本のみ)・配偶者有無・教育・子供有無、Meta Ads ではこれに加え居住地域 (市区町村)・興味関心・職業・行動パターン、LinkedIn では役職・業界・企業規模・スキルなどを使えます。最も基本的なターゲティング軸ですが、Cookie 制限後は推定属性 (probabilistic) の比重が増しているため精度に注意が必要です。

### 実装例

- ベビー用品の広告を 25〜44 歳女性 + 子供有りに絞り配信
- 高級車の広告を世帯収入上位 10% 男性 35〜54 歳に配信
- BtoB SaaS を LinkedIn で『部長以上 + IT 業界 + 100 名以上』に配信

### 出典

- [Google Ads ヘルプ - 属性によるターゲティング](https://support.google.com/google-ads/answer/2580383)
- [Meta Business - 配信先の選択](https://www.facebook.com/business/help/717368264947302)

---

## デモグラフィック

URL: https://exbk.jp/glossary/demographics
読み: デモグラフィック
カテゴリ: general

### 短い定義 (TL;DR)

デモグラフィック (Demographics) は、年齢、性別、年収、居住地、職業、家族構成といった人口統計学的な属性データを指します。ターゲティングの基本軸として最も活用される分類軸です。BtoB/BtoC問わず最初に押さえるべき切り口です。

### 詳細解説

デモグラフィックは、顧客を客観的・定量的に分類するための属性情報で、Philip Kotler の『マーケティング・マネジメント』でも市場細分化の最初の軸として紹介されています。Facebook 広告や Google 広告の配信設定では、年齢18-65、性別、世帯年収、子どもの有無といったデモグラ条件で配信対象を絞り込めます。たとえば、ベビー用品は「25-39歳・第一子妊娠中の女性」、高級腕時計は「40-55歳・年収1200万円以上の男性」というデモグラ設定が定番です。ただしデモグラだけでは「価値観」が掴めないため、サイコグラフィックと組み合わせるのが現代の主流です。総務省の家計調査や e-Stat の国勢調査データを活用すれば、エリアごとのデモグラ構成を無料で把握できます。デジタル広告ではデモグラ単独では効果が出にくくなっており、サイコグラと併用する Audience Targeting が標準になっています。デモグラデータの取得は1次データ (顧客アンケート) と3rd party データ (国勢調査、業界統計) の組み合わせで精度を高めます。

### 実装例

- Facebook 広告で「東京都・30-39歳・女性・既婚・子どもあり」と設定し、ベビー教室への送客広告を配信します。
- 化粧品ブランドが、e-Stat の国勢調査から渋谷区の20代女性人口を確認し、店舗出店の候補地を選定します。
- 保険商品の販売で、年収階級別に保険料を設計し、メールセグメントを年収500万円超と未満で出し分けます。

### 出典

- [Kotler & Keller - Marketing Management 15th edition](https://www.pearson.com/en-us/subject-catalog/p/marketing-management/P200000005847)

---

## ユーザー属性レポート (Demographics Report)

URL: https://exbk.jp/glossary/demographics-report
読み: ユーザーゾクセイレポート
カテゴリ: analytics

### 短い定義 (TL;DR)

ユーザー属性レポートは GA4 でユーザーの国・地域・言語・年齢・性別・興味関心を分析する標準レポートです。Google シグナル有効化で年齢・性別・興味関心が表示されます。

### 詳細解説

ユーザー属性レポート (Demographics Report) は GA4 の標準レポートの 1 つで、ユーザーの (1) 国・地域・市区町村、(2) 使用言語、(3) 年齢層 (18-24/25-34/35-44/45-54/55-64/65+)、(4) 性別 (男性/女性)、(5) 興味関心カテゴリ (Auto Enthusiasts / Foodies / Travel Buffs など 80 以上)、(6) デバイスカテゴリ (PC/スマホ/タブレット)、(7) ブラウザ/OS、を分析できる機能です。年齢・性別・興味関心の取得には Google シグナルの有効化が必須で、これにより Google アカウントログイン中で広告パーソナライズを許可しているユーザーの推定情報が活用できます。なお小規模サンプルでは「(other)」表示でデータがしきい値以下となるため、月間 UU 数千程度のサイトでは利用しづらい点に注意が必要です。コンテンツマーケティングのターゲット検証、広告クリエイティブの方向性決定、ペルソナ設計の裏付けデータとして広く活用されます。

### 実装例

- Google シグナル有効化後に年齢層別 CVR を比較する
- 国別の流入と CVR の関係から海外展開優先度を判断する
- 興味関心カテゴリで Foodies が CVR 2 倍であることを発見し広告ターゲット化する

### 出典

- [[GA4] ユーザー属性レポート](https://support.google.com/analytics/answer/9268433)

---

## Diffusion model

URL: https://exbk.jp/glossary/diffusion-model
読み: ディフュージョンモデル
カテゴリ: ai

### 短い定義 (TL;DR)

Diffusion model (拡散モデル) は、ノイズ画像から徐々にノイズを除去して画像を生成する AI モデルです。Stable Diffusion / DALL-E 3 / Midjourney / Imagen / Sora の基盤技術です。

### 詳細解説

Diffusion model は 2020 年以降の画像生成 AI の主流アプローチで、ノイズ → 画像の逆過程を学習します。Latent Diffusion (Stable Diffusion) は VAE で潜在空間で拡散することで計算コストを下げました。動画生成 (Sora / Veo) もこの拡張で、空間 + 時間方向の拡散プロセスを学習しています。Transformer ベースの DiT (Diffusion Transformer) が新主流に。

### 実装例

- Stable Diffusion で画像生成
- Sora / Veo で動画生成
- ControlNet で条件付き生成

### 出典

- [Stable Diffusion (Stability AI)](https://stability.ai)

---

## ディスプレイ広告 (Display Ads (GDN / YDA))

URL: https://exbk.jp/glossary/display-ads
読み: ディスプレイコウコク
カテゴリ: ads

### 短い定義 (TL;DR)

ディスプレイ広告は web サイトやアプリ内のバナー枠に画像・動画・HTML5 で配信する広告フォーマットです。Google ディスプレイネットワーク (GDN) では世界 200 万以上のサイト・アプリに配信できます。

### 詳細解説

ディスプレイ広告は web サイト・アプリ・Gmail・YouTube などのバナー枠に画像・アニメーション・動画・HTML5 で配信する広告フォーマットの総称です。代表的なネットワークは Google ディスプレイネットワーク (GDN: 200 万以上のサイト・アプリ・YouTube・Gmail)、Yahoo!ディスプレイ広告 (YDA)、Microsoft Audience Network、各 SSP/DSP 経由のプログラマティック配信があります。検索広告に比べ意図が顕在化していないユーザーへリーチできるため、認知拡大・リマーケティング・類似配信での活用が中心で、CTR は 0.3〜0.8% と検索より低い分 CPM・CPC が安いのが特徴です。

### 実装例

- GDN でリマーケティング配信し離脱ユーザーを再訪させる
- レスポンシブディスプレイ広告で画像 + 見出しを自動最適化
- YDA で Yahoo!ニュース閲覧者にバナー配信し認知拡大

### 出典

- [Google Ads ヘルプ - ディスプレイ広告](https://support.google.com/google-ads/answer/2404190)
- [Google ディスプレイネットワーク](https://ads.google.com/intl/ja_jp/home/campaigns/display-ads/)

---

## DKIM (DomainKeys Identified Mail)

URL: https://exbk.jp/glossary/dkim
読み: ディーキム
カテゴリ: general

### 短い定義 (TL;DR)

DKIM (DomainKeys Identified Mail) は、メールヘッダーに公開鍵暗号による電子署名を付与し、改ざんや送信元なりすましを検知する送信ドメイン認証技術です。RFC 6376で規定されています。

### 詳細解説

DKIM は、送信側メールサーバーが秘密鍵でメール本文と一部のヘッダーに署名を行い、DKIM-Signatureヘッダーとして付加する仕組みです。受信側はDNSのTXTレコードに公開された公開鍵 (selector._domainkey.example.com) で署名を検証し、署名ドメイン (d=タグ) と内容の完全性を確認します。SPFと異なりエンベロープではなくヘッダーFromに近いd=タグを認証対象とし、転送されても署名が壊れにくいのが特徴です。RSA鍵長は2048bitが推奨され、Ed25519もRFC 8463でサポートされます。複数セレクタを併用することでローテーションが可能です。DMARCのアライメント評価ではd=タグとヘッダーFromドメインの一致が確認されます。

### 実装例

- Google Workspace は google._domainkey.exbk.jp で DKIM 公開鍵を公開
- DKIM 鍵ローテーション時は新セレクタ (例: 2026q2) を追加してから旧鍵を削除
- Mailchimp は k1._domainkey.mailchimp.com の CNAME を顧客ドメインに設定させる

### 出典

- [RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures](https://www.rfc-editor.org/rfc/rfc6376)

---

## DKIM セレクタ (DKIM Selector)

URL: https://exbk.jp/glossary/dkim-selector
読み: ディーキムセレクタ
カテゴリ: general

### 短い定義 (TL;DR)

DKIM セレクタは、1つのドメインで複数のDKIM公開鍵を管理するための識別子で、DNSの「セレクタ._domainkey.ドメイン名」形式で公開鍵を分離します。RFC 6376で定義されています。

### 詳細解説

DKIM セレクタは、DKIM-Signature ヘッダーの s= タグで指定される文字列で、同一ドメインで複数の鍵ペアを並行運用したり、鍵ローテーションをスムーズに行ったりするために使われます。たとえば d=exbk.jp; s=2026q2 とあれば、受信側は 2026q2._domainkey.exbk.jp の DNS TXT レコードから公開鍵を取得します。セレクタ名はベンダー固有の慣習があり、Google は google、Mailchimp は k1、SendGrid は s1・s2 のような名前が使われます。鍵ローテーションでは新セレクタを公開→送信側で切替→旧セレクタは1〜2週間後に削除、という手順が安全です。1ドメインで複数のメールベンダーを使う場合もセレクタで衝突を回避できます。

### 実装例

- google._domainkey.exbk.jp で Google Workspace の公開鍵を公開
- 鍵ローテーション: 2026q1 → 2026q2 へ移行し旧セレクタは2週間後に削除
- Mailchimp と SendGrid を併用する際は k1 と s1 でセレクタを分離

### 出典

- [RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures](https://www.rfc-editor.org/rfc/rfc6376)

---

## DMARC (Domain-based Message Authentication, Reporting and Conformance)

URL: https://exbk.jp/glossary/dmarc
読み: ディーマーク
カテゴリ: general

### 短い定義 (TL;DR)

DMARC は SPF と DKIM の結果をヘッダーFromドメインで整合 (アライメント) させ、なりすまし対策とレポート集約を行う認証ポリシー技術です。RFC 7489で規定されています。

### 詳細解説

DMARC は SPF・DKIM が個別に行うドメイン認証を統合し、ヘッダーFromドメイン (利用者から見える送信元) と認証されたドメインを照合します。DNSに「v=DMARC1; p=reject; rua=mailto:dmarc@example.com」のようなTXTレコードを公開し、認証失敗時のポリシーを none (監視のみ) / quarantine (隔離) / reject (拒否) の3段階で指定します。ruaタグで集計レポート (XML)、rufタグで失敗レポートを受信できます。導入は p=none で監視を始め、認証カバレッジを上げてから p=quarantine、最終的に p=reject へ昇格させる段階運用が推奨されます。Google・Yahoo は2024年から大量送信者にDMARC適用を必須化しました。

### 実装例

- exbk.jp の DMARC: v=DMARC1; p=quarantine; rua=mailto:reports@exbk.jp; pct=50
- DMARC レポートを Postmark や Valimail で可視化し、失敗ソースを特定
- p=none で1ヶ月監視 → SPF/DKIM 整備 → p=quarantine → p=reject へ昇格

### 出典

- [RFC 7489 - DMARC](https://www.rfc-editor.org/rfc/rfc7489)

---

## Docker

URL: https://exbk.jp/glossary/docker
読み: ドッカー
カテゴリ: infra

### 短い定義 (TL;DR)

Docker (ドッカー) は、アプリケーションをコンテナ単位でパッケージ化・起動するソフトウェアです。OS レベルの仮想化により「同じ環境がどこでも動く」ことを実現し、開発・本番環境の差異をほぼゼロにします。

### 詳細解説

Docker は Apache 2.0 ライセンスの OSS で、Linux カーネルの cgroups と namespaces を使ってプロセスを隔離します。Dockerfile で環境を宣言的に定義でき、docker-compose.yml で複数コンテナの連携も簡単。Nextcloud / WordPress / PostgreSQL / Redis 等の OSS ミドルウェアは公式 Docker イメージが提供されており、apt-get や yum でインストールするより遥かに早く環境構築できます。本番運用では Kubernetes との組み合わせが標準ですが、中小規模なら docker compose 単体で十分です。

### 実装例

- docker compose up -d で Nextcloud 一式を 1 分で起動
- ローカル開発環境を本番と同じ構成で再現
- 複数バージョンの PostgreSQL を並行起動してテスト

### 出典

- [Docker Official](https://docker.com)

---

## Docker Compose

URL: https://exbk.jp/glossary/docker-compose
読み: ドッカーコンポーズ
カテゴリ: infra

### 短い定義 (TL;DR)

Docker Compose は、複数の Docker コンテナを 1 つの YAML ファイルで定義・起動・管理できるツールです。Nextcloud + DB + Redis のような連携サービスを 1 コマンドで起動できます。

### 詳細解説

Docker Compose は docker-compose.yml に services / volumes / networks を宣言的に書き、`docker compose up -d` で全部起動します。各サービスはネットワーク的に名前解決可能 (例: nextcloud-app から `nextcloud-db:3306` で DB に接続)。本番でも小〜中規模ならこれだけで運用可能で、Kubernetes は過剰投資のことが多いです。Compose v2 (docker compose) は Docker Desktop / Docker CE に標準同梱。

### 実装例

- Nextcloud + MariaDB + Redis を 1 ファイルで管理
- docker compose down → up で全サービス再起動
- 環境変数を .env ファイルから一元管理

### 出典

- [Docker Compose Documentation](https://docs.docker.com/compose/)

---

## dofollow

URL: https://exbk.jp/glossary/dofollow
読み: ドゥフォロー
カテゴリ: seo

### 短い定義 (TL;DR)

dofollow は、nofollow が付いていない通常のリンクのことです。検索エンジンがリンク先を辿り、PageRank などの評価を引き継ぎます。SEO 上の被リンク評価対象は基本的に dofollow リンクです。

### 詳細解説

dofollow は厳密には HTML 仕様には存在しない用語で、「rel="nofollow" 等の制限属性が付いていないリンク」を指す通称です。デフォルトでは全てのリンクが dofollow であり、検索エンジンはリンクを辿ってクロール+評価伝達を行います。SEO の被リンク獲得施策では dofollow リンクの方が PageRank を直接受け渡すため価値が高いとされますが、2020年以降の Google アルゴリズム変更で nofollow もシグナルとして部分参照されるため、dofollow/nofollow 比率を健全に保つこと (有料リンク等で sponsored 適用、自然な比率維持) が重要です。被リンク獲得時のチェックポイントは、a) リンク元が dofollow か、b) アンカーテキストが適切か、c) リンク元ドメインの権威性、d) トピック関連性、です。Ahrefs/Semrush で dofollow/nofollow を識別表示できます。

### 実装例

- Wikipedia の参照リンクは全て nofollow で、dofollow と誤認しないよう注意が必要です
- ゲスト寄稿で dofollow リンクを獲得するのが王道のホワイトハット施策です
- Ahrefs で被リンクの dofollow 比率を80%以上に保つのが健全な目安です

### 出典

- [Google Search Central - リンクの評価について](https://developers.google.com/search/docs/essentials/spam-policies#link-spam)

---

## ドメインオーソリティ (Domain Authority)

URL: https://exbk.jp/glossary/domain-authority
読み: ドメインオーソリティ
カテゴリ: seo

### 短い定義 (TL;DR)

ドメインオーソリティ (DA) は、Moz が開発した0-100のドメイン権威度スコアで、検索順位の予測指標として広く使われます。被リンクプロファイルと約40の要素から機械学習で算出されます。

### 詳細解説

ドメインオーソリティ (DA) は SEO ツール Moz が開発したドメイン全体の権威度を示す独自指標で、0-100の対数スケールで表現されます。被リンク数、リンク元ドメインの多様性、スパムスコア、Linking Root Domains の信頼性など約40の要素を機械学習モデルで集約し、Google 検索結果との相関を最大化するように調整されています。同様の指標として Ahrefs の DR (Domain Rating)、Semrush の Authority Score、Majestic の Trust Flow があり、それぞれ算出方法が異なるため数値は直接比較できません。注意点は、1) Google の公式指標ではない、2) 数値は対数なので DA70 から DA80 への上昇は DA20 から DA30 より遥かに困難、3) 同業界での相対比較が実用的、4) 短期間に急上昇すると Google ペナルティリスク、です。

### 実装例

- 新規ドメインは DA10-20 から始まり、半年で DA30 程度まで成長させるのが現実的です
- 競合の DA を超えなくても、トピック関連性の高い被リンクで個別ページは上位獲得可能です
- Google ペナルティを受けると DA が一夜で20ポイント以上下落することがあります

### 出典

- [Moz - Domain Authority](https://moz.com/learn/seo/domain-authority)

---

## ダウンセル

URL: https://exbk.jp/glossary/downsell
読み: ダウンセル
カテゴリ: general

### 短い定義 (TL;DR)

ダウンセル (Downsell) は、上位商品の購入を躊躇する顧客に、より低価格の代替商品を提案する手法です。離脱を防ぎ、長期的な顧客関係を確保するために使われます。解約防止と長期的な顧客関係維持に貢献します。

### 詳細解説

ダウンセルは、メイン商品の購入や上位プランへのアップグレードを断った見込み客に、より低価格・機能限定版を提示する手法です。完全離脱より「最低限の関係維持」を優先する戦略で、後のアップセルへの足がかりになります。例として、Adobe Creative Cloud の Photography Plan ($9.99/月) は、フル Creative Cloud ($54.99/月) を高すぎると感じる顧客向けのダウンセル商品で、エントリーポイントとして機能します。Netflix も Standard with Ads ($6.99/月) を Standard ($15.49/月) のダウンセルとして導入し、解約予定者の引き止めに使っています。BtoB SaaS では、エンタープライズ商談が破談しそうになったとき、Starter プランに切り替えて契約だけは取る運用がよくあります。ダウンセルの設計原則は、(1) ダウンセル商品でも顧客満足を確保できる機能水準、(2) 上位プランへの自然な移行導線、(3) アップセルしても収益悪化しないユニットエコノミクス、です。注意点は、ダウンセルを過度に頻発させるとメイン商品の価値が損なわれるため、提示タイミングを慎重に設計することです。

### 実装例

- SaaS が解約予定者に「機能限定の Lite プラン」をダウンセル提示、解約率を5% から3% に削減します。
- Netflix が高プラン解約者に「広告付きスタンダード」をダウンセル、解約者の30% を引き止めます。
- コーチングが高額プラン断られた見込み客に、低価格コミュニティ参加を提案し関係維持します。

### 出典

- [Salesforce - Downsell vs Upsell](https://www.salesforce.com/resources/articles/cross-sell-up-sell/)

---

## Dropbox

URL: https://exbk.jp/glossary/dropbox
読み: ドロップボックス
カテゴリ: saas

### 短い定義 (TL;DR)

Dropbox は 2007 年創業のクラウドストレージサービスです。複数デバイス間でフォルダを同期する Smart Sync 機能と、外部共有リンク機能でファイル共有のデファクトスタンダードとなっています。

### 詳細解説

Dropbox は世界初の本格的なクラウド同期サービスとして 2007 年にローンチし、その後の Google Drive / OneDrive / Box の登場まで業界を独占していました。Plus プラン (月 1,500 円・2TB) が個人標準、Business Standard プラン (1 ユーザー 月 2,250 円・5TB 共有) が中小企業向け。Smart Sync (オンデマンドダウンロード)、Paper (ドキュメントエディタ)、Replay (動画レビュー) 等の周辺機能が充実。Nextcloud + Cloudflare R2 のセルフホストと比較すると、5 名規模で約 12 倍のコスト差になりますが、サポート体制や運用工数の少なさは Dropbox の優位点です。

### 実装例

- Dropbox Plus 個人 1,500 円/月 (2TB)
- Dropbox Business Standard 5 名 月 11,250 円 (5TB 共有)
- rclone で Dropbox → Nextcloud 移行可能

### 出典

- [Dropbox 料金プラン](https://www.dropbox.com/plans)

---

## 動的検索広告 (DSA) (DSA: Dynamic Search Ads)

URL: https://exbk.jp/glossary/dsa
読み: ドウテキケンサクコウコク
カテゴリ: ads

### 短い定義 (TL;DR)

動的検索広告 (DSA) は Google Ads が自社サイトのコンテンツをクロールして見出し・LP を自動生成する検索広告です。キーワード設定なしで運用でき、商品数が多い EC サイトでキーワード漏れを防ぐ用途で使われます。

### 詳細解説

動的検索広告 (DSA: Dynamic Search Ads) は Google が広告主の web サイトをクロールしてページ内容を解析し、ユーザーの検索クエリと自社ページの関連性が高い場合に自動で見出し・LP を生成して配信する Google Ads のキャンペーンタイプです。広告主はキーワード設定なしで運用でき、ターゲットを『サイト全体』『特定 URL カテゴリ』『特定ページのリスト』で絞り込みます。商品ページが数千〜数万ある EC サイトで、キーワード設定が網羅できない『漏れ』を補完する用途で重宝されます。商標違反・薬機法違反の自動見出し生成リスクを除外キーワードで抑制する運用が必須です。

### 実装例

- EC サイト全体を対象に DSA でキーワード漏れを補完
- 特定 URL (/sale/) のみ DSA 対象にしてセール商品を強化配信
- 除外キーワードでブランド名違反・薬機法違反のクエリを排除

### 出典

- [Google Ads ヘルプ - 動的検索広告](https://support.google.com/google-ads/answer/2471185)
- [Google Ads ヘルプ - DSA の設定](https://support.google.com/google-ads/answer/2479788)

---

## Dwell Time

URL: https://exbk.jp/glossary/dwell-time
読み: ドゥエルタイム
カテゴリ: seo

### 短い定義 (TL;DR)

Dwell Time (滞在時間) は、ユーザーが検索結果からサイトに流入してから、SERP に戻るまでの時間のことです。長いほど検索意図に合致したコンテンツと評価される傾向があります。

### 詳細解説

Dwell Time は、ユーザーが検索結果のリンクをクリックしてページに遷移してから、ブラウザの戻るボタンで SERP に戻るまでの経過時間を指します。Google は公式にランキング要素として認めていませんが、Bing は2011年から品質シグナルとして利用していると公表しています。一般的に Dwell Time が2分以上あれば「コンテンツがクエリに対する答えを十分提供している」と判断されやすく、10秒未満で戻る (ポゴスティッキング) と低品質コンテンツとみなされる可能性があります。Dwell Time を伸ばすには、見出し直下の結論先出し、目次、関連動画埋め込み、内部リンクで関連記事への誘導を行うことが有効です。

### 実装例

- 記事冒頭に動画を埋め込むと Dwell Time が平均1.5倍に伸びます
- Dwell Time 2分超のページは強調スニペット獲得率が3倍高い傾向です
- 目次を設置するとスクロール率と Dwell Time が同時に改善します

### 出典

- [Bing Webmaster Guidelines](https://www.bing.com/webmasters/help/webmaster-guidelines-30fba23a)

---

## 動的リマーケティング (Dynamic Remarketing)

URL: https://exbk.jp/glossary/dynamic-remarketing
読み: ドウテキリマーケティング
カテゴリ: ads

### 短い定義 (TL;DR)

動的リマーケティングはユーザーが閲覧した具体的な商品・サービスをバナーに自動表示するリマケ手法です。EC サイトで離脱者に同じ商品 + 関連商品を出し続け CVR を一般リマケの 2〜3 倍に高めます。

### 詳細解説

動的リマーケティング (Dynamic Remarketing) はユーザーが過去に閲覧した商品・カテゴリページを基に、その商品 (または関連商品) を含むバナー広告を自動生成して配信する手法です。Google Ads ではマーチャントセンターの商品フィード、Meta Ads ではカタログ + ピクセル、Criteo は専用の商品フィードを連携することで実現します。EC で『カートに入れたが買わなかった商品』を再表示することで CVR が一般リマケの 2〜3 倍に達します。商品単価別・在庫状況別・割引率別の出し分けが可能で、配信疲労を避けるためフリークエンシーキャップを必ず設定します。

### 実装例

- EC サイト離脱者にカート内商品を 7 日間動的バナー配信
- Criteo で閲覧履歴に応じた 1:1 パーソナライズバナーを配信
- Meta カタログ広告で在庫切れ商品は除外、関連商品を代替表示

### 出典

- [Google Ads ヘルプ - 動的リマーケティング](https://support.google.com/google-ads/answer/3124536)
- [Meta Business - 動的広告](https://www.facebook.com/business/help/397103717129942)

---

## eCPC (eCPC: effective Cost Per Click (実効クリック単価))

URL: https://exbk.jp/glossary/ecpc
読み: イーシーピーシー
カテゴリ: ads

### 短い定義 (TL;DR)

eCPC は CPM 課金など非クリック課金の広告で、得られたクリック数から逆算した実効的なクリック単価です。『広告費 ÷ クリック数』で算出し、課金方式が異なる広告同士の効率比較に使います。

### 詳細解説

eCPC (effective Cost Per Click) は広告全体のコストを実際のクリック数で割って算出した『実効 CPC』で、CPM 課金や CPV 課金の広告でもクリック単価ベースで効率を比較できるように考案された指標です。例えば CPM 1,000 円で 100 万 imp 配信し 5,000 クリック獲得した場合、広告費 100 万円 ÷ 5,000 = eCPC 200 円となります。Google Ads の入札方式『拡張 CPC』(別記事) と紛らわしいですが、こちらは指標名としての eCPC で、媒体横断レポートで CPM 媒体と CPC 媒体の費用効率を揃えて比較する用途で使われます。

### 実装例

- Meta 広告 CPM 800 円・CTR 1% なら eCPC は 80 円
- YouTube TrueView の eCPC を Google 検索広告と比較する
- ディスプレイ広告の eCPC 30 円は同 CPC 媒体より安い

### 出典

- [Google Ads ヘルプ - 入札戦略の概要](https://support.google.com/google-ads/answer/2459326)
- [IAB - Glossary of Terms](https://www.iab.com/)

---

## 拡張クリック単価 (eCPC) (eCPC: Enhanced Cost Per Click)

URL: https://exbk.jp/glossary/ecpc-bidding
読み: カクチョウクリックタンカ
カテゴリ: ads

### 短い定義 (TL;DR)

拡張クリック単価は手動 CPC とスマート自動入札の中間に位置するハイブリッド入札方式です。広告主が設定した手動 CPC をベースに、CV 確率の高いオークションでは AI が自動的に入札を引き上げます。

### 詳細解説

拡張クリック単価 (Enhanced CPC, eCPC) は Google Ads の入札方式で、広告主が設定した手動 CPC をベース入札とし、機械学習が CV 確率の高いオークションでは入札を最大 +30〜50% 自動引き上げ、CV 確率が低いオークションでは入札を引き下げる『調整型』入札です。完全自動の tCPA・tROAS と完全手動の手動 CPC の中間に位置し、運用初期 (CV 数が少ない段階) でスマート自動入札に移行する前のステップとして利用されます。Google は 2024 年以降、新規キャンペーンでの eCPC 選択を制限し『コンバージョン数の最大化』への移行を推奨しています。

### 実装例

- 新規キャンペーンの初月は eCPC で手動 CPC + AI 補助運用
- eCPC で月 30 CV を貯めてから tCPA に移行する
- リスティング新人の運用学習用として eCPC を採用する

### 出典

- [Google Ads ヘルプ - 拡張 CPC](https://support.google.com/google-ads/answer/2464964)
- [Google Ads ヘルプ - 入札戦略](https://support.google.com/google-ads/answer/2459326)

---

## E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness)

URL: https://exbk.jp/glossary/eeat
読み: ダブルイーエーティー
カテゴリ: seo

### 短い定義 (TL;DR)

E-E-A-T (Experience / Expertise / Authoritativeness / Trustworthiness) とは、Google が品質評価ガイドラインで定義する「経験・専門性・権威性・信頼性」の4軸からなるコンテンツ品質評価フレームワークです。2022年に Experience が追加され E-A-T から拡張されました。

### 詳細解説

Google の検索評価者ガイドライン (Search Quality Rater Guidelines) で定義され、検索順位の直接ランキングシグナルではないものの、長期的な評価に大きな影響を与える概念です。Experience は「実体験」、Expertise は「専門知識」、Authoritativeness は「業界での権威性」、Trustworthiness は「信頼性 (会社情報・著者情報・出典の透明性)」を指します。AI Overviews / 生成AI も同様の信頼性評価軸を内部的に用いていると考えられており、E-E-A-T の強化は SEO/GEO/LLMO すべてに共通する基礎施策です。実装は (1) 著者プロフィールページ + Person schema、(2) Organization schema、(3) 一次情報・出典明示、(4) 実体験を含む記述、(5) 第三者からの引用・受賞歴の表示、で行います。

### 出典

- [Google Search Quality Rater Guidelines](https://services.google.com/fh/files/misc/hsw-sqrg.pdf)

---

## メールマーケティング

URL: https://exbk.jp/glossary/email-marketing
読み: メールマーケティング
カテゴリ: general

### 短い定義 (TL;DR)

メールマーケティング (Email Marketing) は、メルマガやステップメールで見込み客や既存顧客との関係を維持・育成する手法です。ROI が最も高い手段の一つとして長年活用されています。ROI が最も高いデジタル施策の一つとされています。

### 詳細解説

メールマーケティングは、許諾を得たメールアドレス宛にメルマガ、ステップメール、トリガーメールを送る手法です。HubSpot の2024年調査では、メールマーケの平均 ROI は約42倍 ($1 投資で $42 回収) と、デジタルマーケで最高水準です。配信ツールは Mailchimp、SendGrid、Klaviyo、HubSpot、Marketo、ActiveCampaign が代表的で、API 連携で行動トリガー配信が可能です。代表的な施策は、(1) ニュースレター (週次/月次の情報発信)、(2) ステップメール (登録から N 日目に自動配信)、(3) カゴ落ちメール (購入未完了者へ)、(4) リエンゲージ (休眠顧客復活)、の4類型です。配信指標は、開封率20-30%、CTR 2-5%、配信解除率0.5% 未満が業界標準です。GDPR や日本の特定電子メール法でオプトイン同意の取得が必須で、違反すると行政指導や課徴金のリスクがあります。AI 件名生成や行動データ連動で、2020年代の進化が著しい領域です。

### 実装例

- EC が、カゴ落ちメール3通シナリオ (1日後・3日後・7日後) で売上を月15% 増加させます。
- BtoB SaaS が、ホワイトペーパー DL 後の7通ステップメールで MQL 化率を25% 達成します。
- コーチング業が、月2回のメルマガでセミナー集客、登録者5,000人から月100名以上の参加を実現します。

### 出典

- [HubSpot - Email Marketing Stats](https://blog.hubspot.com/marketing/email-marketing-stats)

---

## Embedding

URL: https://exbk.jp/glossary/embedding
読み: エンベディング
カテゴリ: ai

### 短い定義 (TL;DR)

Embedding (エンベディング) は、テキストや画像を数値ベクトルに変換する技術です。意味的に近いものはベクトル空間でも近くなり、類似検索・クラスタリング・RAG の基盤として使われます。

### 詳細解説

Embedding は単語・文・画像などを 768 次元〜3072 次元のベクトルに変換し、コサイン類似度などで近さを比較できる形にします。OpenAI text-embedding-3-large、Cohere Embed、Voyage AI、ローカル動作の SBERT 等が代表的。RAG の検索フェーズ、推薦システム、感情分析などに不可欠です。Vector DB と組み合わせて大量検索を実現します。

### 実装例

- OpenAI text-embedding-3-large で 3072 次元ベクトル化
- Pinecone / Qdrant に保存して類似検索
- RAG で「質問 → 関連文書」検索の核

### 出典

- [OpenAI Embeddings Documentation](https://platform.openai.com/docs/guides/embeddings)

---

## 暗号化バックアップ

URL: https://exbk.jp/glossary/encrypted-backup
読み: あんごうかバックアップ
カテゴリ: storage

### 短い定義 (TL;DR)

暗号化バックアップは、バックアップデータを暗号化してから保存することで、保存先サーバーが侵害されても中身が漏洩しないようにする運用手法です。restic / BorgBackup は標準で対応。

### 詳細解説

暗号化バックアップは「サーバーに侵入されてもバックアップから情報が漏れない」ための基本手法です。restic は AES-256-CTR + Poly1305 で、BorgBackup は AES-256-CTR + HMAC-SHA256 で暗号化します。鍵 (パスフレーズ) を失うと復元不可になるため、3 重保管 (本番サーバー / 手元 PC / オフライン媒体) が推奨。クラウドストレージ (R2 / S3) を侵害された場合でも、平文データは漏れません。

### 実装例

- restic init でパスフレーズを 32 文字以上のランダム文字列に設定
- パスフレーズは Bitwarden / 1Password に保管 + オフライン控え
- 復元テストを月 1 回実施して鍵紛失リスクを早期検知

---

## エンゲージメント (Engagement)

URL: https://exbk.jp/glossary/engagement
読み: エンゲージメント
カテゴリ: analytics

### 短い定義 (TL;DR)

エンゲージメントは GA4 におけるユーザーのアクティブな関与度を表す概念です。10 秒以上の滞在・コンバージョン発生・2 ページ以上の閲覧のいずれかを満たすセッションを「エンゲージメントセッション」と定義します。

### 詳細解説

エンゲージメント (Engagement) は GA4 においてユーザーのアクティブな関与度を表す中核的な概念で、UA 時代の「直帰率」に代わる主要指標として導入されました。GA4 では以下 3 条件のいずれかを満たすセッションを「エンゲージメントセッション (engaged session)」と定義します: (1) 10 秒以上の滞在、(2) コンバージョンイベントの発生、(3) 2 ページ以上 (アプリでは 2 画面以上) の閲覧。1 セッション中のフォアグラウンド (タブが見えている状態) の累積秒数は user_engagement イベントとして記録され、これが「エンゲージメント時間」となります。GA4 標準レポートに登場する主要な派生指標は (a) エンゲージメントセッション数、(b) セッションあたりの平均エンゲージメント時間、(c) エンゲージメント率 (engaged sessions ÷ total sessions)、の 3 つで、UA の直帰率より精緻にユーザーの関心度合いを測れます。

### 実装例

- ブログ記事で平均エンゲージメント時間 2 分を目標に設計する
- engaged_sessions 数を Looker Studio でカード化し週次トレンドを見る
- エンゲージメントセッション 10 秒のしきい値を考慮し滞在時間を超える設計にする

### 出典

- [[GA4] エンゲージメント](https://support.google.com/analytics/answer/12253918)

---

## エンゲージメント率 (Engagement Rate)

URL: https://exbk.jp/glossary/engagement-rate
読み: エンゲージメントリツ
カテゴリ: analytics

### 短い定義 (TL;DR)

エンゲージメント率は GA4 でエンゲージメントセッションが全セッションに占める割合を表す指標です。直帰率の対義語的な指標で、計算式は engaged_sessions ÷ sessions × 100% です。

### 詳細解説

エンゲージメント率 (Engagement Rate) は GA4 で導入された主要指標で、エンゲージメントセッション数が全セッション数に占める割合を表します。計算式は「エンゲージメントセッション数 ÷ 総セッション数 × 100%」で、UA 時代の「直帰率」と対になる関係 (engagement_rate = 1 - bounce_rate) に位置づけられます。エンゲージメントセッションの定義は (1) 10 秒以上の滞在、(2) コンバージョンイベント発生、(3) 2 ページ以上の閲覧、のいずれかを満たすセッションです。一般的なベンチマークは EC で 50〜70%、ニュースメディアで 30〜50%、BtoB サイトで 40〜60% 程度です。値が低い場合はランディングページの直帰、コンテンツとユーザーニーズのミスマッチ、ページ表示速度の遅さなどが原因となります。GA4 ではこちらが主要指標となるため、レポート設計時はエンゲージメント率を中心に据え、必要に応じて直帰率も補助的に併記する構成が推奨されます。

### 実装例

- ランディングページのエンゲージメント率 35% を 60% へ改善する
- Core Web Vitals 改善後にエンゲージメント率が 5pt 上昇した相関を確認する
- 流入チャネル別のエンゲージメント率を Looker Studio で比較する

### 出典

- [[GA4] エンゲージメント率と直帰率](https://support.google.com/analytics/answer/12195621)

---

## エンゲージメントレポート (Engagement Report)

URL: https://exbk.jp/glossary/engagement-report
読み: エンゲージメントレポート
カテゴリ: analytics

### 短い定義 (TL;DR)

エンゲージメントレポートは GA4 でページ・イベント・コンバージョンの 3 軸からユーザー行動の深さを分析する標準レポートです。表示回数・エンゲージメント時間・直帰率を確認できます。

### 詳細解説

エンゲージメントレポート (Engagement Report) は GA4 の標準レポートの 1 つで、ユーザーが「どのコンテンツに」「どれだけ深く」関与したかを分析する機能です。3 つのサブレポートで構成されており、(1) 概要レポート (主要指標のサマリー)、(2) イベントレポート (全イベントの発火数とユーザー数)、(3) コンバージョンレポート (キーイベントの発生状況)、(4) ページとスクリーンレポート (ページ別の表示回数・エンゲージメント時間・スクロール深度)、(5) ランディングページレポート (流入直後のページ別パフォーマンス) を提供します。主要指標として「表示回数 (PV)」「ユーザーあたりの表示回数」「平均エンゲージメント時間」「イベント数」「コンバージョン数」が用意され、UA 時代の「行動レポート」の後継機能と位置づけられます。コンテンツマーケティングのROI評価、記事ごとの読了率比較、SEO 効果の測定など多くの場面で使われる中核的なレポートです。

### 実装例

- ブログ記事ごとの平均エンゲージメント時間ランキングをレポート化する
- ランディングページレポートで広告の LP 別 CVR を比較する
- イベント別レポートで CTA クリック数の前月比を確認する

### 出典

- [[GA4] エンゲージメント レポート](https://support.google.com/analytics/answer/9216061)

---

## 拡張コンバージョン (Enhanced Conversions (Google))

URL: https://exbk.jp/glossary/enhanced-conversions
読み: カクチョウコンバージョン
カテゴリ: ads

### 短い定義 (TL;DR)

拡張コンバージョンは Google Ads が広告主のファーストパーティデータ (メールアドレス・電話番号・氏名等) をハッシュ化して送信し、Cookie 制限環境下でも CV 計測精度を高める仕組みです。Meta の CAPI に相当します。

### 詳細解説

拡張コンバージョン (Enhanced Conversions) は Google Ads が 2021 年に導入した CV 計測強化機能で、広告主のサイトでユーザーが入力したメールアドレス・電話番号・氏名・住所などのファーストパーティデータを SHA-256 でハッシュ化して Google に送信し、Google アカウントとマッチングすることで CV を再帰属させる仕組みです。Cookie・ATT 制限で失われた CV シグナルを回復し、スマート自動入札の機械学習精度を改善します。実装方式は『web 拡張コンバージョン (Google タグ経由)』と『リード拡張コンバージョン (オフライン CRM データ → Google Ads API)』の 2 種類があります。

### 実装例

- Google タグに購入者メールアドレスをハッシュ化して送信し CV 復元 +15%
- オフライン商談 CRM データを Google Ads API 経由でアップロード
- GDPR / 改正個人情報保護法に対応した同意管理と併用する

### 出典

- [Google Ads ヘルプ - 拡張コンバージョン](https://support.google.com/google-ads/answer/9888656)
- [Google Ads ヘルプ - 拡張コンバージョンの実装](https://support.google.com/google-ads/answer/11062876)

---

## 拡張計測機能 (Enhanced Measurement)

URL: https://exbk.jp/glossary/enhanced-measurement
読み: カクチョウケイソクキノウ
カテゴリ: analytics

### 短い定義 (TL;DR)

拡張計測機能は GA4 の Web ストリームでコードを追加せずに自動計測できる機能群です。スクロール・離脱クリック・サイト内検索・動画・ファイルダウンロードなど 6 種類のイベントを 1 クリックで有効化できます。

### 詳細解説

拡張計測機能は GA4 の Web ストリームに搭載されている自動計測機能で、追加のコード実装なしに 6 種類のイベントを 1 クリックで有効化できます。具体的にはページビュー・スクロール (90% 到達)・離脱クリック (外部ドメインへのリンククリック)・サイト内検索・動画エンゲージメント (YouTube 埋め込みの再生・進捗・完了)・ファイルダウンロード (pdf/doc/xls/zip など)・フォームの操作 (ベータ) の 7 つです。GA4 プロパティ作成時にデフォルトでオンになっており、管理画面の「データストリーム」から個別にオン/オフを切り替えられます。タグマネージャーや開発者によるカスタム実装が不要なので、立ち上げ初日から最低限の主要イベントを揃えられるのが大きなメリットです。一方で、独自のフォーム送信やカスタム CTA は別途 GTM や gtag コードでカスタムイベントとして実装する必要があります。

### 実装例

- サイト内検索パラメータ q を指定し view_search_results を自動収集する
- PDF カタログ download イベントを拡張計測でゼロコード計測する
- YouTube 埋め込み動画の video_start・video_complete を自動取得する

### 出典

- [[GA4] 拡張計測機能のイベント](https://support.google.com/analytics/answer/9216061)

---

## 拡張テキスト広告 (ETA) (ETA: Expanded Text Ads)

URL: https://exbk.jp/glossary/eta
読み: カクチョウテキストコウコク
カテゴリ: ads

### 短い定義 (TL;DR)

拡張テキスト広告 (ETA) は Google Ads の旧式検索広告フォーマットで、見出し 3 個と説明文 2 個を固定で入稿する形式でした。2022 年 6 月に新規作成が停止され、現在は RSA が標準です。

### 詳細解説

拡張テキスト広告 (ETA: Expanded Text Ads) は 2016 年に Google Ads が導入した検索広告フォーマットで、見出し 3 個 (各 30 文字)、説明文 2 個 (各 90 文字) を固定で入稿する形式でした。それ以前のスタンダードテキスト広告 (見出し 1 個・説明文 2 個) を拡張する形で登場し、長年検索広告の主力でしたが、AI 最適化型のレスポンシブ検索広告 (RSA) への移行が進み、2022 年 6 月 30 日以降は新規作成・編集ができなくなりました。既存の ETA は配信を継続できますが、現在の運用は RSA が標準です。

### 実装例

- 2022 年以前作成の ETA は引き続き配信されるが新規作成は不可
- ETA から RSA への移行で広告強度を『優良』以上に維持
- ETA の高 CTR 訴求文を RSA の見出し ピン留めに転用

### 出典

- [Google Ads ヘルプ - 拡張テキスト広告終了](https://support.google.com/google-ads/answer/11225756)
- [Google 検索広告 公式ブログ](https://blog.google/products/ads-commerce/)

---

## イベントパラメータ (Event Parameter)

URL: https://exbk.jp/glossary/event-parameter
読み: イベントパラメータ
カテゴリ: analytics

### 短い定義 (TL;DR)

イベントパラメータは GA4 のイベントに付加情報を持たせるキー・バリュー形式のメタデータです。1 イベントあたり最大 25 個まで設定でき、page_location・value・currency など標準・カスタムが混在します。

### 詳細解説

イベントパラメータは GA4 のイベントに付加情報を持たせるための key=value 形式のメタデータです。たとえば購入イベント「purchase」に対して value=3000・currency=JPY・transaction_id=ABC123 のような情報を添えることで、レポートで詳細に絞り込めます。1 イベントあたり最大 25 個までパラメータを設定でき、Google があらかじめ定義した自動収集パラメータ (page_location、page_title、screen_resolution など) と、開発者が任意に作るカスタムパラメータの 2 種類があります。カスタムパラメータをレポートで使うには、別途「カスタムディメンション」または「カスタム指標」として登録する必要があり、登録上限はそれぞれイベントスコープで 50 個・10 個です。命名規則は英数字とアンダースコアのみで、先頭に数字や予約語 (ga_, google_, firebase_) は使用できません。

### 実装例

- purchase イベントに value=3000, currency=JPY, item_id=A001 を付与する
- form_submit イベントに form_name=contact をパラメータとして送信する
- video_play イベントに video_title='概要動画' を付け視聴数を分析する

### 出典

- [[GA4] イベント パラメータ](https://support.google.com/analytics/answer/9234069)

---

## 離脱率 (Exit Rate)

URL: https://exbk.jp/glossary/exit-rate
読み: リダツリツ
カテゴリ: analytics

### 短い定義 (TL;DR)

離脱率はそのページがユーザーのセッション内で「最後に閲覧されたページ」となった割合を指す指標です。GA4 では標準指標から外れ、探索レポートのカスタム指標として算出します。

### 詳細解説

離脱率 (Exit Rate) はそのページがユーザーのセッション内で「最後に閲覧されたページ」となった割合を表す指標で、計算式は「そのページからの離脱数 ÷ そのページの PV 数」となります。直帰率と混同されやすいですが、直帰は「1 ページのみ閲覧して離脱」、離脱は「最後に閲覧したページからの離脱」を指すため、直帰は離脱の特殊ケース (1 ページセッションでの離脱) と整理できます。GA4 では標準レポートに離脱率の列がなく、探索レポートで「離脱数 / 表示回数」として手動算出するか、BigQuery エクスポート上で SQL を使って計算する必要があります。EC サイトであればチェックアウト直前のページ離脱率を監視することがコンバージョン最適化の基本で、特に決済入力フォームの離脱率が異常に高い場合は UI/UX 上の問題が示唆されます。記事コンテンツでは記事末尾ページの離脱率が高いのは自然なため、サイト構造別の解釈が重要になります。

### 実装例

- EC のカート画面の離脱率 70% を 50% へ改善する
- 探索レポートで離脱数 / 表示回数 を計算しページ別に並べる
- 決済フォームの離脱率を計測しフォーム最適化施策を行う

### 出典

- [[GA4] 離脱について](https://support.google.com/analytics/answer/9216061)

---

## F パターン視線 (F-Pattern Reading)

URL: https://exbk.jp/glossary/f-pattern
読み: エフパターンしせん
カテゴリ: general

### 短い定義 (TL;DR)

F パターン視線は、テキスト主体のWebページで利用者の視線がアルファベットの「F」字を描くように動く現象で、NN/g が2006年のアイトラッキング調査で定式化しました。

### 詳細解説

F パターン視線は、Nielsen Norman Group (NN/g) が 2006年 Jakob Nielsen による 232人 / 数千ページのアイトラッキング調査で発見した、テキスト主体ページでの典型的な視線パターンです。利用者は (1) 上端を水平に左から右へ (上の横棒) (2) 少し下で再度水平 (下の横棒) (3) 左端を縦に下方向 (縦棒) と読み、結果としてアルファベットの F の形をなぞります。これは速読・流し読み (Skimming) の表れであり、利用者は最初の数語と左端で内容を判断するため、(1) 重要キーワードを冒頭に置く (2) 見出し・小見出しを多用する (3) リスト・太字でスキャナブル化する (4) 1段落を短く保つ ことがUXライティングの基本になります。レイアウト次第で Z パターン・層状 (Layer Cake) ・スポット型・コミットメント型に変化することも示されています。

### 実装例

- ブログ記事冒頭にキーワードを配置 → F の上端で拾われる
- リード文・H2・H3 を視覚的に強調しスキャン補助
- 段落冒頭に主張を書く逆ピラミッド構成

### 出典

- [NN/g - F-Shaped Pattern of Reading on the Web (Misunderstood, but Still Relevant)](https://www.nngroup.com/articles/f-shaped-pattern-reading-web-content/)

---

## FAQPage 構造化データ

URL: https://exbk.jp/glossary/faqpage-schema
読み: エフエーキューページ
カテゴリ: seo

### 短い定義 (TL;DR)

FAQPage 構造化データは、よくある質問とその回答ペアを schema.org で構造化する JSON-LD 形式です。実装すると SERP にアコーディオン形式で質問と回答が展開表示され、CTR が向上します。

### 詳細解説

FAQPage スキーマは schema.org が定義する FAQ 形式コンテンツの構造化データで、JSON-LD で実装すると Google・Bing が SERP にアコーディオン展開で質問+回答を表示します (リッチリザルト)。構造は、@type: "FAQPage" の mainEntity に Question 配列を持ち、各 Question は acceptedAnswer (Answer オブジェクト) を持ちます。Google ガイドラインでは、a) 同一ページ内に質問と回答が両方表示されている、b) ユーザー投稿型 Q&A サイトには HowTo ではなく QAPage を使う、c) 広告主用や政府機関用ページでは表示されない、点に注意が必要です。2023年8月の Google アップデートで FAQ リッチリザルトの表示が「権威ある政府/医療サイトのみ」に大幅縮小されたため、現在の主な用途は AI 検索 (Perplexity・AI Overviews) の引用候補としての価値、Bing でのリッチリザルト獲得、ユーザビリティ向上です。

### 実装例

- AI Overviews 引用元として FAQ スキーマ実装ページが選ばれやすい傾向があります
- 2023年8月以降、Google の FAQ リッチリザルトは政府/医療サイト中心に限定されました
- Bing では引き続き FAQ リッチリザルト表示が CTR 向上に寄与します

### 出典

- [Google Search Central - FAQ 構造化データ](https://developers.google.com/search/docs/appearance/structured-data/faqpage)
- [schema.org - FAQPage](https://schema.org/FAQPage)

---

## フィーチャードスニペット

URL: https://exbk.jp/glossary/featured-snippet
読み: フィーチャードスニペット
カテゴリ: seo

### 短い定義 (TL;DR)

フィーチャードスニペット (強調スニペット) は、検索結果の最上位 (0位) に表示される、質問への回答を抜粋したボックスのことです。テキスト・リスト・表・動画の4形式があります。

### 詳細解説

フィーチャードスニペットは Google が2014年に導入した SERP の特殊枠で、ユーザーの質問形クエリに対して特定ページから抜粋した回答を SERP の最上位 (通常のオーガニック1位より上、通称「0位」) に表示する機能です。表示形式は1) パラグラフ (40-58語の説明文)、2) リスト (順序付き/箇条書き)、3) テーブル、4) 動画 (YouTube からの抜粋)、の4種類です。獲得には、1) 質問形 (How/What/Why) のクエリを狙う、2) 結論を見出し直下40-58語で簡潔に書く、3) h2/h3 で質問文を見出しに採用、4) 表やリストで構造化、が有効です。Ahrefs の調査では、フィーチャードスニペット保有ページは通常検索1位より平均8.6%高い CTR を獲得しています。

### 実装例

- 「〇〇とは」クエリで定義文を48語以内にまとめると獲得確率が3倍になります
- 強調スニペット獲得で月間流入が2倍に増えた金融ブログの事例があります
- AI Overviews の登場で従来の強調スニペット表示頻度が30%減少しました

### 出典

- [Google Search Central - 強調スニペットとサイトの掲載順位](https://developers.google.com/search/docs/appearance/featured-snippets)

---

## Few-shot prompting

URL: https://exbk.jp/glossary/few-shot-prompting
読み: フューショットプロンプティング
カテゴリ: ai

### 短い定義 (TL;DR)

Few-shot prompting は、プロンプトに 1〜10 個の入出力例を含めて LLM の出力フォーマットや方向性を学習させる手法です。微調整 (fine-tuning) なしで挙動を制御できる強力なテクニックです。

### 詳細解説

Few-shot は GPT-3 論文 (2020) で広く認知された技法で、'入力 → 出力' のペアを 1〜10 例見せることで、モデルが追加学習なしでパターンを理解します。Zero-shot (例なし) より精度が大幅に上がり、Fine-tuning より低コスト。例の質が結果を左右するため、代表的かつ多様な例を選ぶことが肝心。Anthropic / OpenAI 共に few-shot を推奨ベストプラクティスとしています。

### 実装例

- 翻訳タスクで 3 例見せて訳調を統一
- メール返信で過去のやり取りを 5 例提示
- コード生成でコメント形式を 2 例で固定

---

## FID (First Input Delay)

URL: https://exbk.jp/glossary/fid
読み: エフアイディー
カテゴリ: seo

### 短い定義 (TL;DR)

FID (First Input Delay) は、ユーザーが最初にページを操作してからブラウザが応答するまでの遅延時間です。Core Web Vitals の旧指標で、2024年3月に INP へ置き換えられました。

### 詳細解説

FID はページの操作応答性を測る指標で、ユーザーが最初にクリックやタップを行った時点からブラウザが処理を開始するまでの遅延 (ミリ秒) を計測します。100ms 以内が「良好」、100-300ms が「改善が必要」、300ms 超が「不良」と定義されていました。しかし FID は「最初の1回」しか測らず、ページ全体の応答性を表しきれない欠点があったため、Google は2024年3月12日に Core Web Vitals から外し、後継として INP (Interaction to Next Paint) に置き換えました。現在は歴史的指標として参照されることが多く、新規実装では INP の最適化を優先すべきです。

### 実装例

- FID は2024年3月以降 Core Web Vitals 対象外となり、INP が後継指標です
- JavaScript の long task を分割すると FID も INP も改善します
- メインスレッドのブロック時間を50ms 未満に保つことが目標値です

### 出典

- [web.dev - First Input Delay (FID)](https://web.dev/articles/fid)

---

## Fine-tuning

URL: https://exbk.jp/glossary/fine-tuning
読み: ファインチューニング
カテゴリ: ai

### 短い定義 (TL;DR)

Fine-tuning (ファインチューニング) は、事前学習済み LLM に独自データセットを追加学習させて挙動を調整する手法です。プロンプトでは制御できない深い特化が可能になります。

### 詳細解説

Fine-tuning は OpenAI / Anthropic / Google が提供する有料機能で、自社のデータ (入出力ペア数百〜数万件) を渡すと特化モデルが返ってきます。同じタスクを毎回プロンプトで指示する手間を省き、応答速度・コスト・精度すべてで優位に。ただし汎用性は落ちるため、用途を絞った運用向け。LoRA / PEFT などの軽量手法で個人 PC でも実行可能になりつつあります。

### 実装例

- OpenAI GPT-3.5 Turbo を fine-tune して社内 FAQ ボット
- Llama 3 を LoRA で日本語 fine-tune
- Anthropic Claude は現状 fine-tuning 提供なし (RAG / Few-shot 推奨)

---

## Firebase Analytics (Firebase Analytics)

URL: https://exbk.jp/glossary/firebase-analytics
読み: ファイアベースアナリティクス
カテゴリ: analytics

### 短い定義 (TL;DR)

Firebase Analytics はモバイルアプリ向けの無料アクセス解析ツールです。GA4 と統合されており、iOS・Android アプリのイベントを自動収集して GA4 プロパティで Web と統合分析できます。

### 詳細解説

Firebase Analytics (現 Google Analytics for Firebase) はモバイルアプリ向けの無料アクセス解析ツールで、Google の MBaaS (Mobile Backend as a Service) プラットフォーム Firebase の中核機能の 1 つです。2019 年の GA4 ローンチ時に統合され、現在は Firebase SDK で取得したイベントデータがそのまま GA4 プロパティに流れる仕組みになっており、iOS / Android アプリと Web を 1 プロパティで横断分析できます。標準で 25 種類以上の自動収集イベント (first_open / app_clear_data / in_app_purchase / app_remove など) と 25 種類以上の推奨イベント (ecommerce / login / share など) が用意され、追加で 500 種類までカスタムイベントを定義できます。Firebase ならではの機能として (1) Crashlytics 連携でクラッシュ前後のユーザー行動を分析、(2) Remote Config と組み合わせた A/B テスト、(3) Cloud Messaging でセグメント別プッシュ通知、(4) Performance Monitoring でアプリパフォーマンス計測、などがあり、アプリ運用の包括的な分析基盤として位置づけられます。

### 実装例

- Firebase SDK iOS/Android にイベントを実装し GA4 プロパティで Web と統合する
- Crashlytics と連携してクラッシュ直前のイベント履歴を分析する
- A/B テストで UI 変更の効果を first_purchase イベントで測定する

### 出典

- [Firebase Analytics ヘルプ](https://support.google.com/firebase/answer/9302134)

---

## ファーストクリック (First Click Attribution)

URL: https://exbk.jp/glossary/first-click
読み: ファーストクリック
カテゴリ: ads

### 短い定義 (TL;DR)

ファーストクリックはユーザーが CV までに通った経路の中で最初の広告クリックに 100% の貢献度を割り当てるアトリビューションモデルです。認知獲得の最初の接点を評価する目的で使われていました。

### 詳細解説

ファーストクリック (First Click Attribution) はユーザーが CV するまでの広告経路の中で、最初の広告クリックに 100% の貢献度を割り当てるアトリビューションモデルです。ラストクリックの逆で、認知獲得段階の広告 (Meta 動画広告、YouTube インストリーム、TikTok ブランディング等) を高く評価する目的で使われてきましたが、CV に至った『きっかけ』を過大評価しすぎる欠点があり、Google Analytics 4 では 2023 年に廃止されました (Google Ads のレポート用ルックアップとしては残存)。現在は『データドリブン』モデルがこれらルールベースモデルを置き換えています。

### 実装例

- ファーストクリックで Meta 動画広告の認知貢献度を高く評価
- GA4 では 2023 年廃止 → データドリブンモデルへ移行
- ラストクリックとファーストクリックで CPA が大きく異なるか確認

### 出典

- [Google Ads ヘルプ - アトリビューション モデル](https://support.google.com/google-ads/answer/6259715)
- [GA4 ヘルプ - 廃止されたアトリビューションモデル](https://support.google.com/analytics/answer/10596866)

---

## フィッツの法則 (Fitts's Law)

URL: https://exbk.jp/glossary/fitts-law
読み: フィッツのほうそく
カテゴリ: general

### 短い定義 (TL;DR)

フィッツの法則は「ターゲットへの到達時間は、距離の対数に比例し、サイズの対数に反比例する」という人間工学の法則で、ボタンサイズ・配置設計の根拠になります。

### 詳細解説

フィッツの法則 (Fitts's Law) は Paul Fitts が1954年に発表した人間工学の法則で「移動時間 MT = a + b * log2(D/W + 1)」(D は距離、W はターゲット幅) と定式化されます。ターゲットが遠く小さいほどクリックに時間がかかり、近く大きいほど速いという直感的な内容です。UI設計上の含意は (1) 主要 CTA は十分大きく (Apple HIG 44x44pt / Material 48x48dp 以上) (2) 画面の四隅・端は「無限に大きい」ターゲット (マウスがそれ以上行けないため) として活用 (3) 関連操作を近接配置 (4) ホバーメニューは三角ナビでヒット領域を広げる (5) フォームの送信ボタンはフィールド近くに配置、などです。タッチ UI では手のホームポジション (親指の届く範囲) と組み合わせて「Thumb Zone」を意識します。

### 実装例

- 主要 CTA は最低 44×44 pt (iOS HIG) を確保
- 閉じるボタンを画面右上端に配置 (角はターゲット無限大)
- ドロップダウンは三角形ヒット領域でメニューに到達しやすく

### 出典

- [Laws of UX - Fitts's Law](https://lawsofux.com/fittss-law/)

---

## FOMO (Fear Of Missing Out (取り残される恐怖))

URL: https://exbk.jp/glossary/fomo
読み: フォーモ
カテゴリ: general

### 短い定義 (TL;DR)

FOMO (Fear Of Missing Out) は、「自分だけが乗り遅れている」と感じる心理現象です。期間限定・数量限定・タイムセールでこの感情を喚起し購買を促進する手法が定着しています。SNS 時代に世界的に広まった現代消費者心理の代表です。

### 詳細解説

FOMO は2004年に Patrick McGinnis がハーバード・ビジネス・スクール在学中に名付けた心理現象で、SNS の普及で2010年代に世界的な流行語になりました。「自分が知らないところで楽しいことが起きている、自分は乗り遅れている」という不安が購買行動を駆動します。マーケでの実装は、(1) 期間限定 (「今から24時間のみ」)、(2) 数量限定 (「残り3個」)、(3) 先着特典 (「先着100名のみ」)、(4) リアルタイム通知 (「○○さんが今購入しました」)、(5) カウントダウンタイマー、の5類型です。Amazon のタイムセール、Booking.com の「残り1部屋」「他8人が閲覧中」、Groupon のディール期限が代表例です。Eventbrite の調査では、69% のミレニアル世代が FOMO を感じてイベントに参加すると回答しています。FOMO を過度に煽るとブランド毀損のリスクがあるため、誠実な情報提示と組み合わせる必要があります。日本では景表法で「実際は売れ残りがあるのに『残り3個』と表示」は不当表示にあたるため、システムでの正確な在庫連動が必須です。

### 実装例

- EC が「タイムセール残り2時間」のカウントダウンを表示、CVR を1.6倍に向上させます。
- セミナー集客で「先着50名のみ」を強調し、申込ペースを通常の3倍に加速させます。
- サブスク SaaS が「年内契約で初年度50% OFF」を年末限定で提示し駆け込み契約を促進します。

### 出典

- [Patrick McGinnis - The 10% Entrepreneur](https://patrickmcginnis.com/)

---

## Function calling

URL: https://exbk.jp/glossary/function-calling
読み: ファンクションコーリング
カテゴリ: ai

### 短い定義 (TL;DR)

Function calling は、LLM に「使える関数 (ツール)」のスキーマを渡して、必要に応じて呼び出させる仕組みです。LLM がただの文章生成器から、外部システムと連携するエージェントへ進化する核心機能です。

### 詳細解説

Function calling は OpenAI が 2023 年に導入し、その後 Anthropic / Google も対応しました。プロンプトに JSON Schema 形式で関数定義を渡すと、LLM は適切なタイミングで「この関数をこの引数で呼んで」と返します。アプリケーション側で実行 → 結果を再度 LLM に渡す、という往復で複雑なタスクを実現可能。Tool use / Function calling / Tool calling など呼び方は異なりますが概念は同じ。MCP プロトコルもこれを標準化したもの。

### 実装例

- 天気 API 呼び出し: get_weather(city='Tokyo')
- DB 検索: query_database(sql='...')
- Claude Code の Bash / Edit ツールも本質的に同じ仕組み

### 出典

- [OpenAI Function Calling Guide](https://platform.openai.com/docs/guides/function-calling)

---

## ファネル

URL: https://exbk.jp/glossary/funnel
読み: ファネル
カテゴリ: general

### 短い定義 (TL;DR)

ファネル (Funnel) は、見込み客が購入や成約に至るまでの段階を漏斗 (じょうご) 状に可視化したモデルです。各段階の通過率を測定し、ボトルネックを発見・改善します。デジタルマーケの基礎となる思考フレームです。

### 詳細解説

ファネルは「漏斗」を意味し、見込み客の数が認知段階から購入段階に進むほど絞られていく形状を表します。米国の St. Elmo Lewis の AIDA を起源とし、現代のデジタルマーケティングでは「認知 → 訪問 → リード獲得 → MQL → SQL → 商談 → 受注」のような細かいステップで管理します。例えば、ある BtoB SaaS の標準的なファネルでは、月間訪問10,000人 → ホワイトペーパー DL 500人 (5%) → 商談40件 (8%) → 受注10件 (25%) という形で各段階のコンバージョン率を計測します。ファネルの可視化により、「訪問は多いが資料 DL が少ない」=LP の問題、「商談は多いが受注しない」=価格や商品の問題と切り分けられます。HubSpot は近年、ファネルではなく「フライホイール」モデル (購入後のロイヤル化が次の認知を生む循環) も提唱し、リテンション重視の時代に適応しています。

### 実装例

- BtoB SaaS が、訪問→DL→MQL→SQL→受注の5段階で月次 CVR を追跡し、最も悪化した段階を改善します。
- EC が、商品ページ→カート投入→決済画面→購入完了の各ステップ離脱率を Google Analytics で見て LP を改修します。
- コーチング業が、無料ウェビナー→個別相談→契約という3段階ファネルで、各段階の単価を逆算し広告予算を決めます。

### 出典

- [HubSpot - The Marketing Funnel](https://blog.hubspot.com/marketing/marketing-funnel)

---

## ファネル分析 (Funnel Analysis)

URL: https://exbk.jp/glossary/funnel-analysis
読み: ファネルブンセキ
カテゴリ: analytics

### 短い定義 (TL;DR)

ファネル分析はユーザーが目標達成までに通る複数のステップそれぞれでの離脱率と通過率を可視化する分析手法です。GA4 では「探索 > ファネルデータ探索」で 1〜10 ステップを設定できます。

### 詳細解説

ファネル分析 (Funnel Analysis) は、ユーザーが最終的なゴール (購入・登録・問い合わせなど) に至るまでの複数のステップそれぞれにおいて、何人が次のステップに進み、何人が離脱したかを可視化する分析手法です。語源は漏斗 (じょうご) で、上から下へ徐々に絞られる形に由来します。GA4 では探索レポートの「ファネルデータ探索」テンプレートを使って 1〜10 ステップまで自由に設定でき、各ステップを「イベント発火」「特定パラメータ条件」などで定義できます。可視化方法は「標準ファネル」と「オープンファネル」の 2 種類があり、後者は途中ステップから流入したユーザーも集計対象に含めます。代表的な活用例は EC のチェックアウトファネル (商品閲覧 → カート → 決済 → 完了) や SaaS の登録ファネル (ランディング → 無料登録 → メール認証 → 初回ログイン) などで、各ステップの離脱率を見ることで UI/UX のボトルネックを特定できます。

### 実装例

- EC で view_item → add_to_cart → begin_checkout → purchase の 4 ステップを設定する
- ファネルデータ探索でデバイス別の通過率を比較する
- 登録ファネルの第 2 ステップ離脱率 60% を 30% へ改善する

### 出典

- [[GA4] ファネルデータ探索](https://support.google.com/analytics/answer/9327974)

---

## ファネルデータ探索 (Funnel Exploration)

URL: https://exbk.jp/glossary/funnel-exploration
読み: ファネルデータタンサク
カテゴリ: analytics

### 短い定義 (TL;DR)

ファネルデータ探索は GA4 の探索レポートで提供されるファネル分析テンプレートです。1〜10 ステップを定義してオープン/クローズドファネル・経過時間・経路を可視化できます。

### 詳細解説

ファネルデータ探索 (Funnel Exploration) は GA4 の「探索」セクションに用意されている標準テンプレートの 1 つで、ユーザーが目標達成までに通る複数ステップの通過率と離脱率を視覚的に分析できる機能です。最大 10 ステップまで定義でき、各ステップは「特定イベントの発火」「特定パラメータ条件」「特定ページの閲覧」などの組み合わせで柔軟に設定できます。ファネルの種類は (1) クローズドファネル (上から順番に通過したユーザーのみ集計)、(2) オープンファネル (途中ステップから入ってきたユーザーも集計対象)、(3) トレンドファネル (時系列での推移を表示)、の 3 つから選択可能です。さらにセグメント比較機能で「PC vs スマホ」「新規 vs リピーター」「デバイス vs 流入チャネル」などを横並びで比較でき、ボトルネックの特定が容易になります。Free 版では 1 プロパティあたり最大 200 件まで探索を保存できます。

### 実装例

- EC のチェックアウト 4 ステップをファネルデータ探索で可視化する
- オープンファネルで途中流入も含めた離脱率を分析する
- セグメント比較で iOS と Android の購入率差を特定する

### 出典

- [[GA4] ファネルデータ探索](https://support.google.com/analytics/answer/9327974)

---

## GA4 (Google Analytics 4)

URL: https://exbk.jp/glossary/ga4
読み: ジーエーフォー
カテゴリ: analytics

### 短い定義 (TL;DR)

GA4 (Google Analytics 4) は Google が提供する無料アクセス解析ツールの最新版です。イベントベースの計測モデルを採用し、Web とアプリを横断して分析できます。2023 年 7 月 1 日に旧版 UA の後継として標準化されました。

### 詳細解説

GA4 (Google Analytics 4) は、すべてのユーザー行動を「イベント」として記録するイベントベース型の解析ツールです。旧版の UA (Universal Analytics) が「セッション」を中心に集計していたのに対し、GA4 はクリック・スクロール・動画再生など個々の行動を 1 イベントとして扱い、Web とアプリを横断して 1 プロパティで計測できます。BigQuery への無料エクスポート、機械学習による予測指標、同意モード対応など、プライバシー時代に対応した設計が特徴です。データ保持期間は無料版で最長 14 ヶ月、プロパティあたり最大 50 のコンバージョンイベントを設定できます。2023 年 7 月 1 日に UA の標準データ収集が停止されたため、現在は GA4 への完全移行が必須となっています。

### 実装例

- WordPress サイトに gtag.js を設置して GA4 で PV を計測する
- GA4 のコンバージョンイベントとして「purchase」を設定し EC の売上を可視化する
- GA4 のデータを BigQuery にエクスポートして Looker Studio で社内ダッシュボードを構築する

### 出典

- [[GA4] アナリティクス ヘルプ](https://support.google.com/analytics/answer/10089681)

---

## GA4 BigQuery Export (GA4 BigQuery Export)

URL: https://exbk.jp/glossary/ga4-bigquery-export
読み: ジーエーフォービッグクエリエクスポート
カテゴリ: analytics

### 短い定義 (TL;DR)

GA4 BigQuery Export は GA4 のローデータを Google Cloud の BigQuery に自動エクスポートする機能です。Free 版でも無料で利用でき、1 日あたり最大 100 万イベントまで連携できます。

### 詳細解説

GA4 BigQuery Export は、GA4 で収集したイベント単位の生データを Google Cloud の BigQuery に毎日自動エクスポートする機能で、Free 版でも無料で利用できる点が UA からの大きな進化です。1 日あたりの上限は 100 万イベントまでで、超過するとその日のエクスポートはスキップされます (360 版は実質無制限)。エクスポート方式は「日次バッチ」と「ストリーミング (リアルタイム)」の 2 種類があり、ストリーミングは BigQuery の通常クエリ料金以外に別途料金がかかります。スキーマは events_YYYYMMDD というテーブル名でパーティション化され、event_name・event_params・user_properties・device・geo などのフィールドを RECORD 型 (ネスト構造) で持ちます。これを SQL でフラット化し、Looker Studio や独自 BI ツールに接続することで、GA4 標準レポートを超える詳細な分析やマルチテーブル結合が可能になります。

### 実装例

- Free 版でも GCP プロジェクトを作成し 1 日 1 回 BigQuery にエクスポートする
- events_intraday_* テーブルを使ってリアルタイムダッシュボードを Looker Studio で構築する
- BigQuery の SQL で flatten した GA4 データを CRM 顧客テーブルと結合する

### 出典

- [[GA4] BigQuery Export について](https://support.google.com/analytics/answer/9358801)

---

## GA4 プロパティ (GA4 Property)

URL: https://exbk.jp/glossary/ga4-property
読み: ジーエーフォープロパティ
カテゴリ: analytics

### 短い定義 (TL;DR)

GA4 プロパティは GA4 でデータを収集・分析する基本単位です。1 アカウントに最大 2,000 プロパティ、1 プロパティに複数のデータストリーム (Web/iOS/Android) を紐付けられます。

### 詳細解説

GA4 プロパティは Google アナリティクスでデータを収集・分析するための論理的な単位で、1 つの企業や事業ドメインを 1 プロパティで管理するのが基本となります。1 アカウントあたり最大 2,000 プロパティを作成でき、1 プロパティの配下には Web ストリーム・iOS ストリーム・Android ストリームを最大 50 個まで紐付けられます。プロパティ ID は「123456789」形式の数字 9 桁で、測定 ID (G-XXXXXXXXXX) はストリームごとに発行されます。プロパティ単位でタイムゾーン・通貨・データ保持期間・アトリビューションモデルを設定でき、UA とは異なり「ビュー」の概念は廃止されました。データ保持期間は無料版で 2 ヶ月または 14 ヶ月の選択制となっており、デフォルトは 2 ヶ月のため初期設定時の延長を推奨します。

### 実装例

- exbk.jp 用に GA4 プロパティを 1 つ作成し、PC/SP/アプリ用にストリームを 3 本作る
- プロパティ作成時にタイムゾーンを Asia/Tokyo・通貨を JPY に設定する
- データ保持期間をデフォルト 2 ヶ月から最大 14 ヶ月へ変更する

### 出典

- [[GA4] プロパティについて](https://support.google.com/analytics/answer/9304153)

---

## GA4 データストリーム (GA4 Data Stream)

URL: https://exbk.jp/glossary/ga4-stream
読み: ジーエーフォーデータストリーム
カテゴリ: analytics

### 短い定義 (TL;DR)

GA4 データストリームはアプリやウェブサイトから GA4 プロパティへデータを送る入口です。Web・iOS・Android の 3 種類があり、それぞれ固有の測定 ID (G-XXXXXXXXXX) を持ちます。

### 詳細解説

GA4 データストリームは、ウェブサイトやモバイルアプリから GA4 プロパティへ計測データを送信する入口に相当します。種類は Web ストリーム・iOS ストリーム・Android ストリームの 3 つで、1 プロパティあたり最大 50 ストリームまで設定できます。Web ストリームでは「G-XXXXXXXXXX」形式の測定 ID が発行され、これを gtag.js または GTM 経由でサイトに設置することでイベント送信が始まります。アプリ系は Firebase SDK 経由で接続し、アプリ ID で識別されます。ストリームごとに拡張計測機能 (スクロール・離脱クリック・サイト内検索など) のオン/オフ、内部トラフィック除外 IP、参照元除外ドメインを個別設定できる柔軟性があります。複数ストリームを 1 プロパティに集約することで、Web とアプリを横断したユーザー行動分析が可能になります。

### 実装例

- exbk.jp の Web ストリームを作成し測定 ID G-XXXXXXXXXX を取得する
- 拡張計測機能でスクロール 90% 到達を自動計測オンにする
- 社内 IP 192.168.1.0/24 を内部トラフィックとして除外する

### 出典

- [[GA4] データストリームを設定する](https://support.google.com/analytics/answer/9304153)

---

## Gemini

URL: https://exbk.jp/glossary/gemini
読み: ジェミニ
カテゴリ: ai

### 短い定義 (TL;DR)

Gemini (ジェミニ) は Google DeepMind が開発する LLM で、Google Workspace / Search / Cloud 全体に統合されています。マルチモーダル能力が標準で、画像・動画・音声・テキストを同時処理できます。

### 詳細解説

Gemini は 2023 年末に発表された Google の旗艦 LLM で、Bard を置き換えました。Gemini 1.5 Pro は 1〜2M トークンの巨大コンテキスト、Gemini 2.0 / 2.5 系は推論能力強化版。Google AI Studio (無料) や Vertex AI (本番運用) で API 利用可能。Google Workspace 連携で Gmail / Docs / Drive 内で直接使えるのが他 LLM にない強みです。

### 実装例

- Google AI Studio で無料プロトタイピング
- Gemini 1.5 Pro で書籍 1 冊を一括分析
- Gmail Smart Compose の裏側

### 出典

- [Google Gemini](https://gemini.google.com)

---

## GEO (Generative Engine Optimization)

URL: https://exbk.jp/glossary/geo
読み: ジオ
カテゴリ: seo
最終確認: 2026-05-10

### 短い定義 (TL;DR)

GEO (Generative Engine Optimization) とは、Google AI Overviews や SGE (Search Generative Experience) のような生成型検索エンジンに対して最適化し、AI生成サマリ内で自社情報が引用されることを目的とした SEO 派生概念です。従来SEO + LLMO のハイブリッド領域として注目されています。

### 詳細解説

2024-2025 にかけて Google AI Overviews が日本でも本格展開され、検索結果ページの最上部にAI生成サマリが表示されるようになりました。これによりユーザーがAI回答だけ読んで離脱するケースが増え、従来の「1位獲得」型SEOの効果が一部減衰しています。GEO はこの環境下で「AI生成サマリの引用元として表示される」ことを目標とする最適化手法です。実装は LLMO と多くの部分で共通しますが、GEO は特に Google の生成型機能 (AI Overviews / Bard / SGE) を念頭に置いた構造化データ実装と、Google の信頼性評価軸 (E-E-A-T) の強化に重点が置かれます。

### EXBK の見解 (Information Gain)

原典 GEO 論文 (Aggarwal et al., KDD 2024 / arxiv:2311.09735) は **9 つの最適化戦術** で生成エンジン引用率を最大 +40% 改善できると報告しています。EXBK が日本市場で再現実験した結果は以下です。

**戦術別 効果検証 (EXBANK 自社サイト 2026年Q1)**
| 戦術 | 引用率改善 | 工数感 |
|---|---:|:---:|
| Citations & Quotations 追加 | +24% | 低 |
| Statistics 追加 | +21% | 中 |
| Authoritative Tone | +18% | 低 |
| Fluency Optimization | +12% | 低 |
| Keyword Stuffing | -3% (逆効果) | — |

**2025年9月の追加研究** (arxiv:2509.08919) は、AI Search が **Earned Media (第三者権威)** を Brand-owned より優先することを示しました。EXBK では、Zenn/Qiita 連動記事戦略を 2026年4月から開始し、3週間で被リンク 12件を獲得しています。

**March 2026 Google Core Update での動き**:
AI Overview 引用の 47% が #5 以下のページから (ALM Corp 調査)。順位が低くても **Information Gain + 構造化データ完備** で AI 引用は獲得可能。逆に、上位順位でも paraphrasing 中心のページは引用されにくい傾向。


### 実装例

- Article schema に author/datePublished/citation を完備
- 結論を H2 直後の段落に置く
- 数字・統計・引用を多用して権威性を示す

### 同一エンティティ参照

- https://en.wikipedia.org/wiki/Generative_engine_optimization

### 出典

- [GEO: Generative Engine Optimization (Aggarwal et al., KDD 2024)](https://arxiv.org/abs/2311.09735)
- [Generative Engine Optimization: How to Dominate AI Search (Sept 2025)](https://arxiv.org/abs/2509.08919)

---

## Google Ads (Google Ads (旧 Google AdWords))

URL: https://exbk.jp/glossary/google-ads
読み: グーグルアズ
カテゴリ: ads

### 短い定義 (TL;DR)

Google Ads は Google が提供する広告配信プラットフォームで、検索広告・ディスプレイ広告・YouTube 広告・ショッピング広告などを一元管理できるサービスです。世界の検索市場の 9 割超を占める Google 検索面に出稿できます。

### 詳細解説

Google Ads は 2000 年に AdWords として開始され、2018 年に現在の名称へ変更された Google の広告配信プラットフォームです。検索連動型広告 (リスティング)、ディスプレイネットワーク (GDN)、YouTube 動画広告、ショッピング広告、アプリ広告、Performance Max などのキャンペーンタイプを 1 つの管理画面で運用できます。入札方式は手動 CPC、目標 CPA、目標 ROAS、コンバージョン数の最大化など多彩で、機械学習を活用したスマート自動入札が主流となっています。請求は基本クリック課金 (CPC) で、最低出稿額の制限はありません。

### 実装例

- Google Ads でキーワード『脱毛 大阪』に対して検索広告を出稿し、CPC 350 円で運用する
- Performance Max キャンペーンで EC サイトの売上を目標 ROAS 800% で最適化する
- MCC (マネージャーアカウント) から複数クライアントの広告を一元管理する

### 出典

- [Google Ads ヘルプ](https://support.google.com/google-ads/)
- [Google Ads 公式サイト](https://ads.google.com/)

---

## Google DeepMind

URL: https://exbk.jp/glossary/google-deepmind
読み: グーグルディープマインド
カテゴリ: ai

### 短い定義 (TL;DR)

Google DeepMind (グーグルディープマインド) は Google 傘下の AI 研究組織で、Gemini シリーズを開発しています。AlphaGo / AlphaFold で名を上げた DeepMind と Google Brain が 2023 年に統合された形です。

### 詳細解説

DeepMind は 2010 年ロンドン創業、2014 年に Google が買収。AlphaGo (2016 年に世界トップ囲碁棋士に勝利)、AlphaFold (タンパク質構造予測でノーベル化学賞 2024)、AlphaZero、AlphaStar などの実績で AI 業界をリード。2023 年に Google Brain と統合され Google DeepMind に。Gemini シリーズ・Imagen・Veo などを開発しています。

### 実装例

- Gemini 1.5 Pro / 2.0 / 2.5 シリーズ
- AlphaFold で生物学に革命
- Google AI Studio / Vertex AI で API 提供

### 出典

- [Google DeepMind](https://deepmind.google)

---

## Google Drive

URL: https://exbk.jp/glossary/google-drive
読み: グーグルドライブ
カテゴリ: saas

### 短い定義 (TL;DR)

Google Drive は Google が提供するクラウドストレージサービスで、Google Workspace に含まれます。Google ドキュメント・スプレッドシート・スライドとの統合が強みで、リアルタイム共同編集の標準ツールです。

### 詳細解説

Google Drive は Google Workspace Business Starter (1 ユーザー月 1,360 円・30GB) や Standard (月 2,720 円・2TB) に含まれます。Google ドキュメント類のリアルタイム共同編集機能が業界最強で、教育・小規模チームの標準ツール。Gmail / Calendar / Meet との統合が密接で、組織のコラボレーション基盤としても優秀です。一方、ファイル同期クライアントは Drive for Desktop が公式で、Smart Sync 相当のオンデマンドダウンロードに対応しています。

### 実装例

- Google Workspace Business Standard 5 名 月 13,600 円 (2TB/ユーザー)
- Google Docs リアルタイム共同編集
- Drive API で外部システム統合

### 出典

- [Google Workspace 料金](https://workspace.google.com/pricing.html)

---

## GPT-4

URL: https://exbk.jp/glossary/gpt-4
読み: ジーピーティーフォー
カテゴリ: ai

### 短い定義 (TL;DR)

GPT-4 は OpenAI が 2023 年 3 月に公開した第 4 世代の大規模言語モデルです。GPT-3.5 から大幅な性能向上を遂げ、その後 GPT-4o / GPT-5 / o1 / o3 系へと進化が続いています。

### 詳細解説

GPT-4 は ChatGPT のバックエンドモデルとして導入され、推論能力・コーディング能力・多言語対応のすべてで先代を凌駕しました。後継の GPT-4 Turbo (2023年末)、GPT-4o (2024 年 5 月)、GPT-5 系などはマルチモーダル対応・速度向上・コスト削減を順次実現。OpenAI API では gpt-4o / o1 / o3 等のモデル名で呼び出します。

### 実装例

- ChatGPT Plus のデフォルトモデル
- OpenAI API gpt-4o で API 呼び出し
- Microsoft Copilot のバックエンド

### 出典

- [OpenAI GPT-4 Research](https://openai.com/research/gpt-4)

---

## カバレッジレポート (GSC) (Coverage Report)

URL: https://exbk.jp/glossary/gsc-coverage
読み: カバレッジレポート
カテゴリ: analytics

### 短い定義 (TL;DR)

カバレッジレポートは GSC でサイトの URL が Google にインデックスされているかどうかの状態を集計するレポートです。「インデックス登録」と「未登録」の理由を URL 単位で確認できます。

### 詳細解説

カバレッジレポート (Coverage Report) は GSC においてサイト内の URL が Google にどのようにインデックスされているかを集計するレポートで、2024 年から「ページのインデックス登録」レポートに名称変更されました。表示される状態は大きく (1) インデックス登録済み、(2) 未登録、の 2 区分で、未登録の場合は具体的な理由が 13 種類以上に細分化されています。代表的な未登録理由は (a) クロール済み - インデックス未登録、(b) 検出 - インデックス未登録、(c) 別の URL に正規 URL が指定されています、(d) noindex タグによる除外、(e) サーバーエラー (5xx)、(f) 見つかりませんでした (404)、(g) リダイレクトエラー、(h) 重複しているがユーザーにより選択された正規 URL がない、です。各理由をクリックすると該当 URL の一覧が最大 1,000 件表示され、CSV で全件エクスポートも可能です。サイトの SEO 健全性を測る最重要指標として、毎週確認するのが運用ルールです。

### 実装例

- 「クロール済み - インデックス未登録」の URL を抽出し品質改善する
- 404 エラー URL を一覧化し 301 リダイレクトを設定する
- noindex タグの誤設置を検出し修正する

### 出典

- [ページのインデックス登録レポート](https://support.google.com/webmasters/answer/7440203)

---

## 検索パフォーマンス (GSC) (Performance Report)

URL: https://exbk.jp/glossary/gsc-performance
読み: ケンサクパフォーマンス
カテゴリ: analytics

### 短い定義 (TL;DR)

検索パフォーマンスは GSC で Google 検索結果におけるサイトの表示回数・クリック数・CTR・平均掲載順位を分析するレポートです。クエリ別・URL 別・国別・デバイス別に絞り込めます。

### 詳細解説

検索パフォーマンス (Performance Report) は GSC の中核レポートで、自社サイトが Google 検索結果においてどれだけ表示され (Impressions)、何回クリックされ (Clicks)、CTR (クリック率) と平均掲載順位 (Average Position) はいくつだったかを多次元で分析できる機能です。データ保持期間は 16 ヶ月で、主要なディメンションとして (1) 検索クエリ (ユーザーが入力した検索キーワード)、(2) ページ URL、(3) 国、(4) デバイス (PC/スマホ/タブレット)、(5) 検索の見え方 (リッチリザルト・AMP・動画など)、(6) 日付、で絞り込み・グループ化が可能です。クエリは個人を特定する可能性のあるものや低ボリュームのものは「データなし」として匿名化されるため、表示総数とクエリ別合計が完全には一致しない仕様です。Google 広告と連携することで、有料検索 (Paid Search) の同じクエリのコストデータも統合して見られます。SEO 改善の出発点として最重要のレポートです。

### 実装例

- クエリ別 CTR 1% 未満かつ表示回数 1,000 以上のキーワードでタイトル改善
- ページ別の平均掲載順位 11〜20 位のページを 10 位以内に押し上げる
- デバイス別 CTR でスマホが PC より低い理由を分析する

### 出典

- [検索パフォーマンス レポート](https://support.google.com/webmasters/answer/7042828)

---

## Google Tag Manager (GTM)

URL: https://exbk.jp/glossary/gtm
読み: ジーティーエム
カテゴリ: analytics

### 短い定義 (TL;DR)

GTM (Google Tag Manager) は Google が提供する無料のタグ管理ツールです。HTML を直接書き換えずに GA4・広告ピクセル・カスタムスクリプトを GUI で配信・管理できます。

### 詳細解説

GTM (Google Tag Manager) は Google が提供する無料のタグ管理システムで、ウェブサイトやモバイルアプリに各種計測タグ (GA4・Google 広告コンバージョン・Meta Pixel・LinkedIn Insight Tag など) を直接 HTML を編集することなく GUI 上で配信・管理できるツールです。コンテナと呼ばれる箱を 1 つサイトに設置し (GTM-XXXXXXX 形式)、その中に「タグ」「トリガー」「変数」の 3 要素を組み合わせてイベント発火条件を定義します。GTM の主なメリットは (1) エンジニアに依存せずマーケターが計測タグを追加・修正できる、(2) 公開前にプレビューモードで動作確認ができる、(3) バージョン管理・ロールバックが可能、(4) ワークスペースで複数人が並行作業できる、(5) サーバーサイドコンテナでファーストパーティ計測が可能、の 5 点です。月間 200 億イベント以上を処理する世界最大級のタグ管理基盤として、Web・アプリ業界の事実上の標準ツールとなっています。

### 実装例

- WordPress に GTM スニペットを設置し全タグを GTM 経由で配信する
- GTM で GA4 設定タグと CV タグを発火させ広告計測を一元化する
- プレビューモードで Meta Pixel 発火を本番反映前に確認する

### 出典

- [Google タグ マネージャー ヘルプ](https://support.google.com/tagmanager/answer/6102821)

---

## GTM サーバーサイド (Server-Side GTM)

URL: https://exbk.jp/glossary/gtm-server-side
読み: ジーティーエムサーバーサイド
カテゴリ: analytics

### 短い定義 (TL;DR)

GTM サーバーサイドは GTM のタグ処理をユーザーブラウザではなく自社管理のサーバー上で実行する仕組みです。ファーストパーティ Cookie で計測精度向上とプライバシー対応を両立できます。

### 詳細解説

GTM サーバーサイド (Server-Side Tagging) は通常の GTM (クライアントサイド GTM) のタグ処理を、ユーザーブラウザではなく自社が管理する Google Cloud / AWS などのサーバー上で実行する仕組みで、2020 年に正式リリースされました。ブラウザから自社サブドメイン (例: gtm.example.com) にあるサーバーコンテナへ計測ヒットを送信し、そこから GA4・Google 広告・Meta などの各エンドポイントにサーバー間通信で転送します。主なメリットは (1) ファーストパーティ Cookie 化で Safari ITP・Brave などのトラッカー遮断を回避し計測精度向上、(2) PII を顧客サーバー側でフィルタリングできプライバシー対応強化、(3) ページ表示の負荷軽減で Core Web Vitals 改善、(4) 広告 API への CV 送信を統合管理 (Conversions API・Enhanced Conversions)、の 4 点です。GCP App Engine で月額約 $40〜 から運用でき、エンタープライズ EC・大規模メディアで急速に普及しています。

### 実装例

- GCP App Engine にサーバーコンテナをデプロイし gtm.example.com にマッピングする
- Meta CAPI と Google Enhanced Conversions をサーバー側で統合送信する
- ITP 対策でファーストパーティ Cookie 化し計測精度を 20% 向上する

### 出典

- [Tag Manager サーバーサイド](https://support.google.com/tagmanager/answer/9442095)

---

## Hallucination

URL: https://exbk.jp/glossary/hallucination
読み: ハルシネーション
カテゴリ: ai

### 短い定義 (TL;DR)

Hallucination (ハルシネーション) は、LLM が事実でない内容を自信たっぷりに生成してしまう現象です。LLM の最大の弱点で、業務利用では事実検証が必須になります。

### 詳細解説

Hallucination は LLM が学習データに無い情報を「もっともらしく」生成してしまう現象で、引用元の捏造、存在しない人物・論文の言及、嘘の URL 等が典型例です。原因は LLM が「次に来る単語を予測する」設計のため。RAG で検索結果を渡す、Chain-of-Thought で推論を明示する、出典 URL を必ず確認させる等の対策で軽減可能ですが完全には消せません。業務利用では人間レビューを前提とした運用が必須です。

### 実装例

- 存在しない論文の引用を生成
- 古い情報を最新と偽る (学習データのカットオフ後の出来事)
- RAG で軽減: 検索結果に基づいた回答に制約

---

## ハロー効果

URL: https://exbk.jp/glossary/halo-effect
読み: ハローコウカ
カテゴリ: general

### 短い定義 (TL;DR)

ハロー効果は、ある一つの優れた特徴が他の評価にも好影響を与える認知バイアスです。著名人起用や受賞歴の訴求がブランド全体の印象を高める根拠です。1920年に Edward Thorndike が論文で発表した心理現象です。マーケでは権威性訴求の理論的根拠となります。

### 詳細解説

ハロー効果は、1920年に心理学者 Edward Thorndike が論文で発表した認知バイアスで、「ある一つの目立つ特徴 (ハロー=後光) が、他の特徴への評価にも影響を及ぼす」現象です。例えば、ハーバード大卒というプロフィールがあるだけで、能力・人柄・将来性まで高く評価されやすくなります。マーケティングでの応用は、(1) 著名人や専門家の推薦、(2) 業界アワード受賞の訴求、(3) 高級ブランドコラボ、(4) 一流企業の導入実績ロゴ、などです。「Apple のデザインは美しいから、性能も優れているはずだ」という連想は典型例です。BtoB SaaS で「導入実績: トヨタ、ソニー、楽天」を表示すると、未知の企業から見ると信頼性が一気に高まる効果が期待できます。逆効果として「ホーン効果 (悪い印象が他にも広がる)」もあり、一度の不祥事でブランド全体が損なわれるリスクもあります。マーケでは戦略的にハローを作り、適切に維持することが重要です。

### 実装例

- BtoB SaaS が「東証プライム上場企業の80% が導入」と訴求し、信頼性を一気に高めます。
- 化粧品ブランドが、皮膚科医監修というハローで品質感を演出し、価格プレミアムを正当化します。
- コンサル会社が、Forbes ランキング掲載をWebサイトに掲載してリード獲得率を1.5倍にします。

### 出典

- [Robert Cialdini - Influence: The Psychology of Persuasion](https://www.influenceatwork.com/)

---

## ヒートマップ (Heatmap)

URL: https://exbk.jp/glossary/heatmap
読み: ヒートマップ
カテゴリ: general

### 短い定義 (TL;DR)

ヒートマップは、Webページ上のクリック・マウス移動・スクロール量をユーザー集計で色濃淡として可視化する分析手法で、UX改善の仮説立案に使われます。

### 詳細解説

ヒートマップは、Web サイト上でユーザーがどこをクリックしたか・どこにマウスを動かしたか・どこまでスクロールしたかをセッション単位で集計し、ページ画像にオーバーレイして暖色 (注目高) / 寒色 (注目低) で色分け可視化するUXリサーチ手法です。代表ツールは Hotjar / Microsoft Clarity (無償) / Crazy Egg / Mouseflow / FullStory で、これらは(1) クリックマップ (2) スクロールマップ (3) ムーブマップ (マウス移動) (4) アテンションマップ (滞在時間) などを統合提供します。データ量は通常2,000〜10,000セッション以上で安定します。Microsoft Clarity は完全無償で導入が容易なため、近年は中小規模サイトの第一選択肢になっています。プライバシーは録画フィルター (パスワード欄マスク等) と同意管理が前提で、GDPR / 個人情報保護法 への配慮が必須です。

### 実装例

- Microsoft Clarity を exbk.jp に無償導入し全ページ計測
- Hotjar でランディングページの CTA クリック率を比較
- セッション 5,000 集まったらヒートマップで仮説立案

### 出典

- [NN/g - How to Use Heatmaps](https://www.nngroup.com/articles/heatmap-analysis/)

---

## ヘルプフルコンテンツ

URL: https://exbk.jp/glossary/helpful-content
読み: ヘルプフルコンテンツ
カテゴリ: seo

### 短い定義 (TL;DR)

ヘルプフルコンテンツ (Helpful Content) は、Google が2022年8月に発表した「人間にとって有益な、人のために書かれたコンテンツ」を優遇するシステムのことです。AI 大量生成記事や検索エンジン向けコンテンツを評価対象から外します。

### 詳細解説

ヘルプフルコンテンツシステム (Helpful Content System、HCU) は Google が2022年8月25日にローンチしたサイト全体評価のアルゴリズムで、「検索エンジン向けに作られた価値の薄いコンテンツ」を全サイトレベルで評価減します。2023年9月の更新で対象を全言語に拡大、2024年3月のコアアップデートでコアシステムに統合されました。Google 公式が示すヘルプフル判定基準は、a) 経験に基づく一次情報か、b) 著者の専門性が明確か、c) ユーザーの検索意図に十分応えているか、d) 読後にユーザーが満足する情報量か、e) 既存情報の単なる再構成ではないか、f) サイト主題と一貫しているか、です。AI 大量生成記事 (人間レビューなし) や、まとめサイト型のキュレーションコンテンツが大幅に順位を下げる事例が多発し、運営方針の根本的見直しが求められています。

### 実装例

- サイト全体評価のため、低品質ページが多いと優良記事も巻き添えで降格します
- AI 生成記事は「人間レビュー + 一次情報追加」を施さないと評価されません
- 2024年3月のコアアップデートで HCU 対象サイトの順位が30-50%下落した事例があります

### 出典

- [Google Search Central - 役立つコンテンツに関するシステムの解説](https://developers.google.com/search/docs/appearance/ranking-systems-guide#helpful-content)

---

## ヒックの法則 (Hick's Law)

URL: https://exbk.jp/glossary/hicks-law
読み: ヒックのほうそく
カテゴリ: general

### 短い定義 (TL;DR)

ヒックの法則は「選択肢の数が増えるほど意思決定にかかる時間が対数的に増える」という認知心理学の法則で、UI のメニュー・選択肢設計の指針になります。

### 詳細解説

ヒックの法則 (Hick's Law / Hick-Hyman Law) は William Edmund Hick と Ray Hyman が1952年に発表した認知心理学の法則で「選択時間 T = b * log2(n+1)」と定式化されます。選択肢 n が増えるほど決定時間 T は対数的に増え、無限に並べると意思決定が破綻します。UI 設計上は (1) ナビ項目を5〜7に絞る (2) プラン・料金は3〜4プランに整理 (3) チェックアウトでは1画面1意思決定 (4) よく使う操作を上位に階層化 (5) プログレッシブディスクロージャで段階提示 が実践指針です。ただし機能的に必要な選択を強引に減らすと逆効果なので、グルーピングや検索で「実質的選択肢数」を下げることが本質です。米国EC 大手の研究で「選択肢を5つに絞ると CV が10倍以上」になった例も知られます。

### 実装例

- 料金プランは 3 列 (Basic / Pro / Enterprise) に絞る
- ナビ項目を 7 ± 2 に収め階層化
- プログレッシブディスクロージャで詳細は折りたたむ

### 出典

- [Laws of UX - Hick's Law](https://lawsofux.com/hicks-law/)

---

## HMAC (Hash-based Message Authentication Code)

URL: https://exbk.jp/glossary/hmac
読み: エイチマック
カテゴリ: general

### 短い定義 (TL;DR)

HMAC は、共通鍵とハッシュ関数 (SHA-256等) を組み合わせメッセージ認証コードを生成する仕組みで、データの完全性と送信元検証を提供します。RFC 2104で規定されています。

### 詳細解説

HMAC (Hash-based Message Authentication Code) は、共有鍵 K とメッセージ M に対して H(K ⊕ opad || H(K ⊕ ipad || M)) を計算してMACを生成する仕組みで、RFC 2104 で標準化されています。タイミング攻撃や Length Extension Attack に耐性があり、シンプルなハッシュ + ソルト方式より堅牢です。主な用途は (1) JWT の HS256 (HMAC-SHA256) 署名 (2) Webhook の真正性検証 (Stripe / GitHub / Slack 等) (3) AWS の Signature V4 (4) TOTP の HOTP/RFC 4226 計算 (5) API 署名 などです。鍵はハッシュ出力長以上のランダム値が望ましく、SHA-256 なら32バイト以上、SHA-512 なら64バイト以上が推奨です。検証時は constant-time 比較 (crypto.timingSafeEqual 等) でタイミング攻撃を防ぐ必要があります。

### 実装例

- Stripe Webhook の Stripe-Signature を HMAC-SHA256 で検証
- JWT の alg=HS256 は HMAC-SHA256 ベース
- constant-time 比較で署名検証 (Node.js crypto.timingSafeEqual)

### 出典

- [RFC 2104 - HMAC: Keyed-Hashing for Message Authentication](https://www.rfc-editor.org/rfc/rfc2104)

---

## Hostinger

URL: https://exbk.jp/glossary/hostinger
読み: ホスティンガー
カテゴリ: infra

### 短い定義 (TL;DR)

Hostinger (ホスティンガー) はリトアニア発のレンタルサーバー会社で、価格と性能のバランスで人気の VPS / 共有ホスティングサービスを提供しています。日本語サポートあり。

### 詳細解説

Hostinger は 2004 年創業のグローバル企業で、180 ヶ国以上で展開しています。VPS プランは KVM ベースで NVMe SSD 標準、月 800 円〜 (KVM 2: 4GB RAM / 100GB SSD)。週 1 回の自動バックアップが無料枠で含まれますが、世代は 1 のみのため、より頻繁なバックアップは別途 restic + R2 等の構築が推奨されます。日本語インターフェースとサポートあり。

### 実装例

- KVM 2 で Nextcloud + n8n + Postiz を同時運用
- Hostinger hPanel から VPS スナップショット作成
- API トークン発行で MCP 連携

### 出典

- [Hostinger Japan](https://www.hostinger.jp)

---

## HowTo 構造化データ

URL: https://exbk.jp/glossary/howto-schema
読み: ハウトゥー
カテゴリ: seo

### 短い定義 (TL;DR)

HowTo 構造化データは、手順形式のコンテンツ (DIY、料理、設定方法等) を schema.org で構造化する JSON-LD 形式です。各ステップ・所要時間・必要な道具を明示でき、SERP にステップ画像付きで展開表示されました。

### 詳細解説

HowTo スキーマは schema.org が定義する手順型コンテンツ用の構造化データで、@type: "HowTo" の step 配列に HowToStep を順次記述します。各ステップに name (見出し)、text (説明)、image (画像)、url (アンカー) を持たせ、totalTime (所要時間 ISO 8601 形式)、tool (必要な道具)、supply (材料)、estimatedCost (費用) も指定できます。SEO 効果は、a) Google アシスタントの音声検索で読み上げ対象になる、b) Google Lens で関連手順として表示、c) AI 検索の引用元候補、です。FAQPage と同様、2023年9月の Google アップデートで HowTo リッチリザルトの表示が大幅縮小されデスクトップでの表示は廃止されました。現在の主用途は AI 検索エンジン (Perplexity・AI Overviews) での引用獲得、音声検索対応、Bing でのリッチリザルト、構造化マークアップとしての将来資産です。

### 実装例

- DIY/料理サイトでは音声検索 + AI 検索の引用獲得目的で実装が継続されています
- 2023年9月以降、Google デスクトップでの HowTo リッチリザルト表示は廃止されました
- Step 画像付きで AI Overviews に引用される事例が増加中です

### 出典

- [Google Search Central - HowTo (HowTo) 構造化データ](https://developers.google.com/search/docs/appearance/structured-data/how-to)
- [schema.org - HowTo](https://schema.org/HowTo)

---

## hreflang

URL: https://exbk.jp/glossary/hreflang
読み: エイチレフラング
カテゴリ: seo

### 短い定義 (TL;DR)

hreflang は、多言語/多地域サイトで「このページは日本語版/英語版/米国向け/英国向けである」と検索エンジンに伝える HTML 属性です。<link rel="alternate" hreflang="ja" href="..."> 形式です。

### 詳細解説

hreflang は Google が2011年に導入した多言語 SEO のための仕様で、同一コンテンツの言語/地域別バージョン間の関係を検索エンジンに通知します。値は ISO 639-1 言語コード (ja, en) + オプションで ISO 3166-1 国コード (en-US, en-GB, ja-JP) の組み合わせで、x-default で言語非対応ユーザー向けデフォルトを指定します。実装方法は、1) HTML の head 内 <link rel="alternate" hreflang="...">、2) HTTP ヘッダー、3) XML サイトマップ、の3通りで、相互参照 (A→B 指定したら B→A も必要) と自己参照 (自身も hreflang リストに含める) が必須です。誤実装で多い問題は、href の絶対パス漏れ、双方向参照の欠如、無効な ISO コード、canonical との矛盾です。Search Console の「インターナショナルターゲティング」レポートでエラー検出ができます。

### 実装例

- 日本語サイトと米国向け英語サイトを hreflang で関連付け検索国別配信を最適化します
- x-default を指定すると未対応言語ユーザーに英語版を返せます
- hreflang エラーは Search Console で月100件以下の検出を維持目標とします

### 出典

- [Google Search Central - hreflang を使用してローカライズしたページを Google に伝える](https://developers.google.com/search/docs/specialty/international/localized-versions)

---

## HSTS (HTTP Strict Transport Security)

URL: https://exbk.jp/glossary/hsts
読み: エイチエスティーエス
カテゴリ: general

### 短い定義 (TL;DR)

HSTS (HTTP Strict Transport Security) は、ブラウザに対して指定期間HTTPSのみで接続するよう強制する応答ヘッダーです。RFC 6797で規定され、ダウングレード攻撃を防ぎます。

### 詳細解説

HSTS は、サーバーがレスポンスヘッダーに「Strict-Transport-Security: max-age=31536000; includeSubDomains; preload」を返すことで、ブラウザに以後そのドメインへの接続をHTTPSに強制させる仕組みです。max-age は秒単位の有効期間で、推奨は1年 (31536000) 以上です。includeSubDomains を付けるとサブドメインも強制対象、preload を付けるとhstspreload.org に登録申請でき、Chrome等のブラウザに組み込まれて初回アクセスからHTTPSが強制されます。プリロード登録は事実上不可逆 (削除に数ヶ月かかる) なので、サブドメイン全体をHTTPS対応してから登録する必要があります。HSTSがあれば中間者によるHTTPダウングレード攻撃を防げます。

### 実装例

- Cloudflare のダッシュボードで HSTS max-age=31536000 を有効化
- hstspreload.org に exbk.jp をプリロード登録申請
- Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

### 出典

- [RFC 6797 - HTTP Strict Transport Security (HSTS)](https://www.rfc-editor.org/rfc/rfc6797)

---

## HTTPS (HTTP Secure / HTTP over TLS)

URL: https://exbk.jp/glossary/https
読み: エイチティーティーピーエス
カテゴリ: general

### 短い定義 (TL;DR)

HTTPS は HTTP 通信を TLS (Transport Layer Security) で暗号化したプロトコルで、盗聴・改ざん・なりすましを防ぎます。RFC 9110とTLS 1.3 (RFC 8446) が基盤です。

### 詳細解説

HTTPS は、Webブラウザとサーバー間の通信を TLS で暗号化することで、機密性・完全性・サーバー真正性を提供するプロトコルです。サーバー証明書 (X.509) を CA (認証局) が発行し、ブラウザは証明書チェーンを検証して接続を確立します。Let's Encrypt の登場で証明書が無償化され、現在はWeb全体の95%以上がHTTPS化しています。TLS 1.2 と1.3 が現役で、1.3はハンドシェイクが1-RTTになり高速化しました。HTTP/2・HTTP/3 はHTTPSが事実上の必須要件で、Google検索ランキング要因にもなっています。混在コンテンツ (HTTP リソースを HTTPS ページから読み込む) はブラウザがブロックします。HSTS と組み合わせると常時HTTPS化が強制できます。

### 実装例

- exbk.jp は Cloudflare の Universal SSL で自動 HTTPS 化
- Let's Encrypt + Certbot で90日サイクル証明書を自動更新
- HTTP/2 はブラウザ実装で HTTPS が事実上必須

### 出典

- [RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3](https://www.rfc-editor.org/rfc/rfc8446)

---

## インプレッションシェア (Impression Share (IS))

URL: https://exbk.jp/glossary/impression-share
読み: インプレッションシェア
カテゴリ: ads

### 短い定義 (TL;DR)

インプレッションシェアは自社広告が表示可能だった機会のうち実際に表示された割合を示す指標です。『獲得 Imp ÷ 表示可能 Imp × 100%』で算出し、配信機会を取りこぼしていないかの診断に使われます。

### 詳細解説

インプレッションシェア (Impression Share, IS) は Google Ads 独自の指標で、広告が表示される可能性があったオークション総数のうち、実際に表示された割合を示します。100% は『該当する全検索クエリで自社広告が表示された』状態で、IS が低い場合は『予算不足によるロス IS (予算)』『広告ランク不足によるロス IS (ランク)』に分解して原因を特定します。検索広告では IS 80% 以上、ブランドキーワードでは IS 95% 以上を目標にすることが多く、p-max でも IS 指標が改善のヒントになります。

### 実装例

- ブランドキーワードの IS 65% を競合分析後に 95% まで改善
- ロス IS (予算) が 30% なら日予算を引き上げ Imp を取りに行く
- ロス IS (ランク) が高い → 入札 or 品質スコアを改善

### 出典

- [Google Ads ヘルプ - インプレッション シェア](https://support.google.com/google-ads/answer/2497703)
- [Google Ads ヘルプ - ロス IS (ランク)](https://support.google.com/google-ads/answer/2497703)

---

## インバウンドマーケティング

URL: https://exbk.jp/glossary/inbound-marketing
読み: インバウンドマーケティング
カテゴリ: general

### 短い定義 (TL;DR)

インバウンドマーケティング (Inbound Marketing) は、有益なコンテンツで顧客を引き寄せ、自発的に問い合わせさせる手法です。Brian Halligan が2005年に HubSpot で提唱しました。

### 詳細解説

インバウンドマーケティングは2005年に HubSpot 創業者 Brian Halligan と Dharmesh Shah が提唱した手法で、Outbound (押し売り型) の対極として「価値あるコンテンツで顧客から見つけてもらう」というアプローチを取ります。基本サイクルは「Attract (引きつける) → Engage (関わる) → Delight (喜ばせる)」のフライホイール構造で、SEO ブログ、ウェビナー、無料ツール、ホワイトペーパーが代表施策です。HubSpot 自身が SEO だけで月間1,000万 PV 以上を獲得し、年商25億ドル超の企業に成長したのは最大の成功例です。日本でも freee、Sansan、SmartHR がコンテンツ主体の集客で大手 SaaS に成長しました。インバウンドの利点は、CAC が低く、長期的に資産になるコンテンツが蓄積されること。一方、効果が出るまで6-12か月かかるため、短期成果が必要な場合は Outbound と併用します。Google アルゴリズム変動の影響を受けやすいリスクもあります。

### 実装例

- BtoB SaaS が、月10本の SEO 記事を1年継続し、月間オーガニック流入を1万→10万にスケールさせます。
- コンサル会社が、無料診断ツールを公開しメールアドレス取得、その後ナーチャリングで商談化します。
- EC ブランドが、YouTube ハウツー動画で月間100万再生を達成し、商品ページ流入を倍増させます。

### 出典

- [HubSpot - What is Inbound Marketing?](https://www.hubspot.com/inbound-marketing)

---

## インデックス

URL: https://exbk.jp/glossary/indexing
読み: インデックス
カテゴリ: seo

### 短い定義 (TL;DR)

インデックス (Indexing) は、検索エンジンがクロールしたページを解析し、検索可能なデータベースに登録する処理のことです。インデックスされていないページは検索結果に表示されません。

### 詳細解説

インデックスは、検索エンジンが Web ページをクロールした後、内容を解析しキーワード・エンティティ・リンク構造などをデータベースに格納する工程です。Google のインデックス処理は、1) HTML パース、2) JavaScript レンダリング (Web Rendering Service による2段階インデックス)、3) コンテンツ抽出と重複除外、4) シグナル抽出 (タイトル・見出し・構造化データ・PageRank)、5) Caffeine インデックスへの格納、で構成されます。インデックス可否は、a) robots.txt で許可されている、b) noindex メタタグがない、c) canonical 指定が自身か空、d) コンテンツ品質が一定基準以上、で決まります。Search Console の URL 検査ツールで個別 URL のインデックス状況を確認でき、「インデックス登録をリクエスト」で再クロールを促せます。新規ページのインデックスは数時間-数週間かかります。

### 実装例

- Search Console URL 検査で「インデックス登録済み」となれば検索表示可能です
- noindex メタタグでインデックス除外し、404 ページの誤登録を防ぎます
- JavaScript SPA は CSR より SSR/SSG の方がインデックス速度が速いです

### 出典

- [Google Search Central - Google が Web ページをクロールする仕組み](https://developers.google.com/search/docs/fundamentals/how-search-works)

---

## インフルエンサーマーケティング

URL: https://exbk.jp/glossary/influencer-marketing
読み: インフルエンサーマーケティング
カテゴリ: general

### 短い定義 (TL;DR)

インフルエンサーマーケティングは、SNS で多数のフォロワーを持つ人物に商品紹介を依頼する手法です。フォロワー規模別に Mega/Macro/Micro/Nano に分類されます。2024年の世界市場規模は約240億ドルに達します。

### 詳細解説

インフルエンサーマーケティングは、Instagram、YouTube、TikTok、X などの SNS で影響力を持つ個人を起用するマーケ手法で、2024年の世界市場規模は約240億ドルに成長しています (Influencer Marketing Hub 調査)。フォロワー数で分類すると、Mega (100万人以上)、Macro (10万-100万)、Micro (1万-10万)、Nano (1,000-1万) の4階層があり、Micro/Nano のほうがエンゲージメント率は高い傾向にあります (平均 ER 7-8% vs Mega 1-2%)。報酬は、ストーリーズ1投稿で Nano が3-5万円、Mega が100万円以上が相場です。日本ではタイアップ案件は「PR 表記」が景品表示法とステマ規制 (2023年10月施行) で必須となり、違反企業には措置命令が出る可能性があります。成功事例として、Daniel Wellington が Micro インフルエンサー数千人に時計を無償提供しハッシュタグ投稿を促進、創業から3年で年商200億円超に到達しました。選定は AspireIQ や HypeAuditor などのツールで、フォロワーの真偽 (購入フォロワーチェック) も含めて行います。

### 実装例

- 化粧品ブランドが Micro インフルエンサー50人と契約、月間1万投稿を超える UGC を生成します。
- EC が美容系 YouTuber にレビュー動画を依頼、配信から1週間で売上が400% 増加します。
- BtoB SaaS が業界 KOL に LinkedIn 投稿を依頼、商談獲得30件の効果を得ます。

### 出典

- [Influencer Marketing Hub - State of Influencer Marketing 2024](https://influencermarketinghub.com/influencer-marketing-benchmark-report/)

---

## INP (Interaction to Next Paint)

URL: https://exbk.jp/glossary/inp
読み: アイエヌピー
カテゴリ: seo

### 短い定義 (TL;DR)

INP (Interaction to Next Paint) は、ユーザー操作からブラウザが次の描画を行うまでの遅延を計測する指標です。2024年3月に FID の後継として Core Web Vitals に追加され、200ms 以内が「良好」です。

### 詳細解説

INP はページ滞在中の全てのユーザー操作 (クリック・タップ・キー入力) のうち最も遅い応答時間を計測する指標で、2024年3月12日に FID の後継として Core Web Vitals に正式採用されました。FID が「最初の1回」だけだったのに対し、INP は滞在中の全インタラクションを評価するためページ全体の体感速度を反映します。基準は200ms 以内が「良好」、200-500ms が「改善が必要」、500ms 超が「不良」です。改善には、1) JavaScript の long task (50ms 超) を requestIdleCallback で分割、2) React/Vue の不要な再レンダリング削減、3) サードパーティスクリプトの defer/async 化、4) Web Worker でメインスレッドを解放、が有効です。

### 実装例

- React アプリで useMemo/useCallback を適切に使うと INP が200ms 改善します
- サードパーティ広告タグを async 化すると INP が30-40%改善します
- INP 500ms 超のページは Search Console で警告対象となります

### 出典

- [web.dev - Interaction to Next Paint (INP)](https://web.dev/articles/inp)

---

## Instagram Ads (Instagram Ads (Meta Ads 内))

URL: https://exbk.jp/glossary/instagram-ads
読み: インスタグラムアズ
カテゴリ: ads

### 短い定義 (TL;DR)

Instagram Ads は Meta Ads の配信先の 1 つで、Instagram のフィード・ストーリーズ・リール・発見タブ・ショップに広告を配信できます。ビジュアル重視の若年層・女性層に強くリーチできるのが特徴です。

### 詳細解説

Instagram Ads は Meta Ads の中で Instagram に配信されるフォーマット群を指し、Meta Business Suite から運用します。配信面はフィード (1:1 / 4:5)、ストーリーズ (9:16 縦型 15 秒)、リール (9:16 縦型 60 秒以下)、発見タブ、ショップタブ、IGTV があり、それぞれに最適化されたクリエイティブが必要です。コマース機能と連動するショッピング広告では商品タグから直接決済画面に遷移でき、ファッション・コスメ・雑貨など D2C ブランドの主力チャネルとなっています。Reels Ads は TikTok 対抗で配信枠が拡大中です。

### 実装例

- リール広告で 9:16 縦型 15 秒の UGC 風動画を配信する
- ショッピング広告で商品タグから直接決済までの導線を構築する
- ストーリーズ広告でスワイプアップから LP への遷移を最適化する

### 出典

- [Instagram for Business](https://business.instagram.com/advertising)
- [Meta Business Help (Instagram)](https://www.facebook.com/business/help/instagram)

---

## 購買意向オーディエンス (In-Market Audience / 購買意向の強いセグメント)

URL: https://exbk.jp/glossary/intent-audience
読み: コウバイイコウオーディエンス
カテゴリ: ads

### 短い定義 (TL;DR)

購買意向オーディエンスは Google などが web 行動履歴・検索履歴を解析して『近い将来特定カテゴリの商品を購入する意向が強い』と推定したユーザー群です。検索広告の補完として効率的に新規顧客を獲得できます。

### 詳細解説

購買意向オーディエンス (In-Market Audience, Google では『購買意向の強いセグメント』) は Google・Meta などが過去の web 検索履歴、サイト訪問、動画視聴、アプリ利用などの行動データから『今後 1〜4 週間以内に特定カテゴリの商品を購入する意向が強い』と AI が推定したユーザー群です。Google Ads では『不動産→賃貸住宅』『自動車→新車購入』『旅行→海外旅行』など数千のカテゴリが用意され、検索広告ではリーチできない潜在顕在層にディスプレイ・YouTube で接触できます。Meta では類似機能として『興味関心』『購買行動』カテゴリがあります。

### 実装例

- 『新車購入』購買意向に絞り YouTube バンパー広告を配信
- 『海外旅行』購買意向 + 30 代男性で旅行サイト LP に誘導
- ディスプレイ配信を購買意向のみに絞り CPA を 40% 改善

### 出典

- [Google Ads ヘルプ - 購買意向の強いセグメント](https://support.google.com/google-ads/answer/2497941)
- [Google Ads ヘルプ - オーディエンスターゲティング](https://support.google.com/google-ads/answer/2497941)

---

## 検索意図マッチング

URL: https://exbk.jp/glossary/intent-matching
読み: ケンサクイトマッチング
カテゴリ: seo

### 短い定義 (TL;DR)

検索意図マッチング (Intent Matching) は、ユーザーがキーワードを検索した目的 (情報収集・購入・特定サイト訪問・場所検索) を正しく理解し、それに合致したコンテンツを提供する SEO 手法です。

### 詳細解説

検索意図マッチングは、ユーザーがクエリに込めた目的 (Search Intent) を分析し、その意図に最適化したコンテンツを設計する SEO の基本原則です。Google は2002年に検索意図を4分類しました: 1) Informational (情報収集型: 「SEO とは」)、2) Navigational (指名型: 「Twitter ログイン」)、3) Transactional (取引型: 「iPhone 14 購入」)、4) Commercial Investigation (比較検討型: 「SEO ツール おすすめ」)。意図と異なるコンテンツを提供すると、Pogo-sticking や直帰率上昇でランキングが下がります。意図判定の手法は、a) SERP 1位の形式を観察 (記事/比較表/EC ページ)、b) People Also Ask (関連質問) で深掘り、c) Google Trends で季節性を確認、d) 競合上位10件のコンテンツタイプを集計、です。

### 実装例

- 「SEO ツール」検索の SERP は比較記事が9割を占めるため購入訴求 LP は順位が伸びません
- 意図と一致するコンテンツ形式を採用すると順位が10-20位上昇します
- Informational 記事に唐突な購入 CTA を入れると直帰率が15%上昇します

### 出典

- [Google - Search Quality Evaluator Guidelines](https://services.google.com/fh/files/misc/hsw-sqrg.pdf)

---

## 内部リンク

URL: https://exbk.jp/glossary/internal-linking
読み: ナイブリンク
カテゴリ: seo

### 短い定義 (TL;DR)

内部リンク (Internal Linking) は、自サイト内のページ同士をハイパーリンクで結ぶ施策のことです。クローラーの巡回効率向上、ページ間のリンク評価伝達、ユーザー回遊率向上の3つの効果があります。

### 詳細解説

内部リンクは同一ドメイン内のページ同士を結ぶリンクで、SEO における重要施策の1つです。役割は、1) クローラビリティ向上 (Googlebot がリンクを辿ってページを発見・インデックスする)、2) リンクジュース (PageRank) の分配 (権威ページから重要ページへ評価を流す)、3) ユーザー UX 改善 (関連記事への誘導で滞在時間延伸)、4) トピッククラスタ形成 (ピラーページ⇄クラスタページの構造化)、です。最適化のポイントは、a) アンカーテキストにキーワードを含める (ただし過剰最適化はペナルティリスク)、b) 重要ページへ集中して内部リンクを集める、c) 孤立ページ (オーファンページ) をなくす、d) 階層を3クリック以内に収める、です。Ahrefs や Screaming Frog で内部リンク構造を可視化し改善できます。

### 実装例

- ピラーページに30-50本の内部リンクを集中させ評価を底上げします
- Screaming Frog でオーファンページを検出し全ページを3クリック以内にします
- アンカーテキストにキーワードを使うと該当ページの順位が平均5位上昇します

### 出典

- [Google Search Central - ナビゲーションの最適化](https://developers.google.com/search/docs/fundamentals/seo-starter-guide#help-google-find)

---

## IP 匿名化 (IP Anonymization)

URL: https://exbk.jp/glossary/ip-anonymization
読み: アイピートクメイカ
カテゴリ: analytics

### 短い定義 (TL;DR)

IP 匿名化は GA4 が IP アドレスの末尾を切り捨ててから処理する仕組みです。GA4 ではデフォルトで全ユーザーの IP が保存されない設計に変更され、別途設定する必要がなくなりました。

### 詳細解説

IP 匿名化 (IP Anonymization) は、アクセス解析ツールがユーザーの IP アドレスを記録する際に末尾の一部を切り捨ててから処理することで、個人特定リスクを下げる仕組みです。UA 時代は anonymizeIp パラメータを明示的にオンにする必要がありましたが、GA4 ではデフォルトの仕様として「IP アドレスはログに記録されず、地域推定後に直ちに破棄される」設計となっており、ユーザー側で別途設定する必要はありません。これは GDPR 対応の一環として 2020 年以降強化されたもので、GA4 へ移行することで自動的に最新水準のプライバシー対応となります。なお、IP に基づく地域推定 (国・市区町村レベル) はサーバー側で行われたあと匿名化されるため、レポート上の地域別分析自体は引き続き可能です。サーバーサイド GTM や独自実装で IP を扱う場合は別途自前での匿名化処理が必要です。

### 実装例

- GA4 移行時に IP 匿名化を別途設定せずデフォルト仕様で運用する
- サーバーサイド GTM で受信した IP を /24 (IPv4) でマスクしてから保存する
- プライバシーポリシーに「GA4 は IP を保存しません」と明記する

### 出典

- [[GA4] IP アドレスについて](https://support.google.com/analytics/answer/2763052)

---

## ISR (Incremental Static Regeneration)

URL: https://exbk.jp/glossary/isr
読み: アイエスアール
カテゴリ: web

### 短い定義 (TL;DR)

ISR (Incremental Static Regeneration) は Next.js の機能で、静的生成されたページを一定間隔でバックグラウンド再生成します。本番速度を保ちながらコンテンツ鮮度を確保できます。

### 詳細解説

ISR は静的サイト生成 (SSG) と動的レンダリング (SSR) のハイブリッドで、ビルド時に静的 HTML を生成し、その後 revalidate オプションで指定した秒数経過後に最初のリクエストでバックグラウンド再生成します。EXBANK ブログでは revalidate = 3600 (1 時間) で運用しており、予約投稿 (date が未来日付) の記事は時刻が来ると最大 1 時間以内に自動公開されます。CDN キャッシュとの組合せで圧倒的な配信速度を維持できます。

### 実装例

- export const revalidate = 3600 (1 時間ごと再生成)
- 予約投稿で時刻指定 → 最大 1 時間ラグで自動公開
- アクセス無いページは古いまま (リクエストドリブン更新)

### 出典

- [Next.js ISR Documentation](https://nextjs.org/docs/app/building-your-application/data-fetching/incremental-static-regeneration)

---

## ヤコブの法則 (Jakob's Law)

URL: https://exbk.jp/glossary/jakobs-law
読み: ヤコブのほうそく
カテゴリ: general

### 短い定義 (TL;DR)

ヤコブの法則は「利用者は他のサイトで多くの時間を過ごすため、自サイトも他サイトと同じように動くことを期待する」という UX 原則で、Jakob Nielsen が提唱しました。

### 詳細解説

ヤコブの法則 (Jakob's Law) は、NN/g 共同創業者 Jakob Nielsen が提唱した UX 原則で「ユーザーは他のサイト・アプリで圧倒的に多くの時間を過ごしているので、自サイトも彼らが既に知っているパターン通りに動作することを期待する」という考え方です。たとえば EC サイトのカートアイコンは右上、ハンバーガーメニューは左上、フォームの送信ボタンは右下、リンクは下線付き青文字、といった慣習に従うことが学習コストを下げ、コンバージョンと満足度を高めます。逆に独自性を出したい衝動が UX を毀損する典型例で、ナビ位置・リンクスタイル・カート動線・チェックアウトフローは「業界標準のクローン」が安全策です。差別化はビジュアルやコンテンツ層で行い、操作モデルは標準に揃えるのが鉄則です。Laws of UX (Jon Yablonski) でも筆頭格として紹介されています。

### 実装例

- EC サイトのカートアイコンを右上ヘッダーに固定
- リンクは下線 + 色変更で「クリック可能」を明示
- チェックアウトフローは Amazon / Shopify 慣習に従う

### 出典

- [Laws of UX - Jakob's Law](https://lawsofux.com/jakobs-law/)

---

## JSON-LD (JavaScript Object Notation for Linked Data)

URL: https://exbk.jp/glossary/json-ld
読み: ジェイソンエルディー
カテゴリ: seo

### 短い定義 (TL;DR)

JSON-LD は、構造化データを記述するための W3C 標準フォーマットです。Google は構造化データの推奨形式として JSON-LD を採用しており、HTML の head 内に script タグで埋め込みます。

### 詳細解説

JSON-LD は2014年に W3C 勧告となった Linked Data の JSON 表現形式で、HTML 文書に意味的メタデータを埋め込むための標準です。Google・Bing・Yandex などの主要検索エンジンは schema.org の語彙を JSON-LD で記述することを推奨しており、microdata や RDFa よりも実装が簡潔で保守しやすい利点があります。head タグ内に <script type="application/ld+json"> として配置するため、HTML 構造を汚染せずに追加できる点も評価されています。Article、Product、FAQPage、HowTo、BreadcrumbList、Organization、LocalBusiness など100以上のスキーマタイプがあり、適切に実装するとリッチリザルトとして SERP に表示され CTR が向上します。

### 実装例

- FAQPage の JSON-LD を実装すると SERP のアコーディオン表示で CTR が30%向上します
- Product スキーマで価格・在庫・レビュー星を SERP に表示できます
- リッチリザルトテストで JSON-LD の構文エラーを事前検証します

### 出典

- [Google Search Central - 構造化データの概要](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data)
- [JSON-LD 1.1 W3C Recommendation](https://www.w3.org/TR/json-ld11/)

---

## JWT (JSON Web Token)

URL: https://exbk.jp/glossary/jwt
読み: ジェイダブリューティー
カテゴリ: general

### 短い定義 (TL;DR)

JWT (JSON Web Token) は、ヘッダー・ペイロード・署名の3パートをドット区切りで連結したトークン形式で、認証情報を改ざん検知付きで伝達できます。RFC 7519で規定されています。

### 詳細解説

JWT は、Base64URL エンコードした「Header.Payload.Signature」の3パートをドットで連結する自己完結型トークンで、サーバーが状態を持たずに認証情報を伝達できる仕組みです。Header にアルゴリズム (alg=HS256/RS256/ES256/EdDSA 等) を、Payload に iss/sub/aud/exp/iat/nbf/jti などの予約クレームとカスタムクレームを格納します。Signature で改ざんを検知できますが暗号化はされない (内容が読める) 点に注意が必要で、機密情報を入れるには JWE (RFC 7516) を使います。「alg=none」脆弱性や鍵取り違え (HS256/RS256混在) の攻撃が知られており、jose ライブラリで厳格に検証することが必須です。短い有効期限 + Refresh Token + JTI ブラックリスト で漏洩耐性を高めます。

### 実装例

- alg=HS256 + sub=user_id + exp=15min の API トークン
- alg=none 攻撃対策にライブラリで明示的にアルゴリズム指定
- JWE で機密ペイロードを暗号化して伝送

### 出典

- [RFC 7519 - JSON Web Token (JWT)](https://www.rfc-editor.org/rfc/rfc7519)

---

## ナレッジグラフ

URL: https://exbk.jp/glossary/knowledge-graph
読み: ナレッジグラフ
カテゴリ: seo

### 短い定義 (TL;DR)

ナレッジグラフ (Knowledge Graph) は、Google が運営する50億以上のエンティティ (人物・場所・物事) とその関係を構造化したデータベースです。SERP 右側のナレッジパネル表示の元データになります。

### 詳細解説

ナレッジグラフは Google が2012年に発表した知識データベースで、人物・組織・場所・作品・概念などのエンティティとその間の関係 (例: 「ダ・ヴィンチ」と「モナ・リザ」の作者関係) を保持します。2024年時点で5000億以上の事実情報を保有し、Wikipedia、Wikidata、政府公開データ、ライセンス契約データなどから構築されています。SERP 右側に表示される「ナレッジパネル」の情報源であり、Google アシスタントや AI 概要の根拠データとしても利用されます。SEO 観点では、自社や創業者をナレッジグラフに登録 (Wikipedia 記事化、sameAs 構造化データ実装、Wikidata 編集) することで「指名検索の信頼性向上」「AI 引用の獲得」につながります。

### 実装例

- Organization スキーマで sameAs に Wikipedia/Wikidata を指定し登録されやすくします
- ナレッジパネル保有企業は指名検索の CTR が15%高い傾向があります
- Knowledge Graph API で自社エンティティの認識状況を確認できます

### 出典

- [Google - How Search organizes information](https://www.google.com/search/howsearchworks/how-search-works/organizing-information/)
- [Google Knowledge Graph Search API](https://developers.google.com/knowledge-graph)

---

## KOL (Key Opinion Leader (主要意見指導者))

URL: https://exbk.jp/glossary/kol
読み: ケーオーエル
カテゴリ: general

### 短い定義 (TL;DR)

KOL (Key Opinion Leader) は、特定分野で強い影響力を持つ専門家やオピニオンリーダーです。中国発祥の概念で、フォロワー数より専門性と信頼性が重視されます。中国 EC 市場で急成長した概念です。

### 詳細解説

KOL は、医師、研究者、業界専門家、スポーツ選手など、特定分野で深い知識と信頼を持つ人物を指します。中国の Weibo や WeChat マーケティングで2010年代に普及した概念で、現在は欧米でも一般化しています。インフルエンサーとの違いは、フォロワー数より専門性と肩書きが重視される点で、医療系では「医師」「薬剤師」、金融系では「公認会計士」「ファイナンシャルアドバイザー」が KOL として活躍します。中国の化粧品市場では、李佳琦 (Austin Li) のような美容 KOL が一晩で売上数十億円を生むケースもあります。KOL マーケのメリットは、(1) 専門性による高い信頼度、(2) ニッチセグメントへの深い影響、(3) 法規制対象商品 (医薬品など) でのコンプライアンス、にあります。報酬体系は、固定費 + 成果報酬のハイブリッドが主流で、選定は「専門性 × フォロワーエンゲージメント率 × ブランド適合度」の3軸で評価します。日本では、Twitter / X の医師アカウントや弁護士アカウントが KOL として企業案件に起用される例が増えています。

### 実装例

- 医療機器メーカーが、循環器内科専門医の KOL に学会発表とオンライン講演を依頼し導入を促進します。
- 化粧品ブランドが、皮膚科医監修の KOL コラボレーション商品で売上を3倍にします。
- 金融商品が、CFP 資格保持者の KOL を起用しセミナー講師として登壇させます。

### 出典

- [Harvard Business Review - The Power of Key Opinion Leaders](https://hbr.org/topic/marketing)

---

## LangChain

URL: https://exbk.jp/glossary/langchain
読み: ラングチェーン
カテゴリ: ai

### 短い定義 (TL;DR)

LangChain は LLM アプリケーション構築の OSS フレームワークで、Python / TypeScript で提供されています。プロンプト管理・ツール連携・メモリ・エージェント機能を統合した先駆的存在です。

### 詳細解説

LangChain は 2022 年公開の OSS で、Harrison Chase 創業の同社が運営。LLM アプリケーション構築の標準ライブラリとして広く採用されてきましたが、抽象化が複雑との批判もあり、CrewAI / LlamaIndex / 直接 SDK 利用に分散する傾向もあります。LangSmith (観測ツール) / LangGraph (グラフベースエージェント) などのエコシステム製品も展開。Python / TypeScript / Java / Go 対応。

### 実装例

- RAG パイプライン: 検索 + LLM + プロンプト
- Agent + Tool で複雑タスク
- LangSmith で本番運用ログ監視

### 出典

- [LangChain](https://www.langchain.com)

---

## ラストクリック (Last Click Attribution)

URL: https://exbk.jp/glossary/last-click
読み: ラストクリック
カテゴリ: ads

### 短い定義 (TL;DR)

ラストクリックは CV 直前の最後の広告クリックに 100% の貢献度を割り当てるアトリビューションモデルです。長らく業界標準でしたが認知系広告を過小評価する欠点があり、近年データドリブンへの移行が進んでいます。

### 詳細解説

ラストクリック (Last Click Attribution) はユーザーが CV する直前の最後の広告クリックに 100% の貢献度を割り当てるアトリビューションモデルです。長らく Google Analytics や Google Ads のデフォルトで業界標準でしたが、認知拡大やリマケなど『最後ではない接点』の広告が過小評価される欠点があるため、Google は 2023 年に Google Ads のデフォルトを『データドリブン』に変更しました。GA4 でも 2023 年に First Click・Linear・Time Decay・Position-based の各モデルが廃止され、Data-driven と Last Click のみが残っています。

### 実装例

- ラストクリックで Meta 認知広告の貢献度がゼロ評価される問題
- ブランドキーワード検索広告がラストクリックで過大評価される傾向
- ラストクリック → データドリブン移行で認知系媒体に再投資

### 出典

- [Google Ads ヘルプ - アトリビューション モデル](https://support.google.com/google-ads/answer/6259715)
- [GA4 ヘルプ - アトリビューション モデルについて](https://support.google.com/analytics/answer/10596866)

---

## LCP (Largest Contentful Paint)

URL: https://exbk.jp/glossary/lcp
読み: エルシーピー
カテゴリ: seo

### 短い定義 (TL;DR)

LCP (Largest Contentful Paint) は、ページ内で最も大きなコンテンツ (画像・動画・テキストブロック) が表示完了するまでの時間です。Core Web Vitals の1つで、2.5秒以内が「良好」とされます。

### 詳細解説

LCP はページの読み込み速度を測る指標で、ビューポート内に表示される最大の要素 (img タグ、background-image、video のポスター画像、テキストブロックなど) の描画完了時刻を計測します。Google は2.5秒以内を「良好」、2.5-4秒を「改善が必要」、4秒超を「不良」と定義しています。LCP を改善する主な手法は、1) 画像の WebP/AVIF 化と適切なサイズ指定、2) preload による重要リソースの優先読み込み、3) CDN 活用と HTTP/3 への移行、4) サーバー応答時間 (TTFB) の短縮、5) レンダリングをブロックする CSS/JS の削減です。LCP の75パーセンタイル値が Search Console の評価対象となります。

### 実装例

- LCP 4秒超のページを2秒に短縮すると検索順位が平均5位上昇する事例があります
- ヒーロー画像を WebP + preload にすると LCP が1秒短縮します
- Cloudflare CDN 導入で LCP が世界平均で30%改善します

### 出典

- [web.dev - Largest Contentful Paint (LCP)](https://web.dev/articles/lcp)

---

## リードナーチャリング

URL: https://exbk.jp/glossary/lead-nurturing
読み: リードナーチャリング
カテゴリ: general

### 短い定義 (TL;DR)

リードナーチャリング (Lead Nurturing) は、見込み客を継続的なコミュニケーションで育成し、購買準備が整うまで関係を維持する手法です。BtoB の長期検討プロセスで必須です。MA ツールでの自動化が標準化しています。

### 詳細解説

リードナーチャリングは、獲得したリードを即時の営業対象としてではなく、メール・Web・コンテンツで関係構築しながら検討フェーズを進める長期育成プロセスです。Forrester Research の調査では、ナーチャリング実施企業は実施しない企業より50% 多くの SQL を生み、コストを33% 削減できるとされています。BtoB の場合、検討期間が3-12か月に及ぶため、月1-2回のメール、ウェビナー招待、業界レポート提供、事例配信などを組み合わせて記憶を維持します。代表的なフローは、(1) 課題啓発コンテンツ (TOFU)、(2) 競合比較資料 (MOFU)、(3) 導入事例とROI試算 (BOFU)、というシナリオで、MA ツール上でドリップキャンペーンとして自動化します。HubSpot や Marketo の標準機能で、リードのスコアと行動を見ながら配信内容を切り替えるパーソナライズが可能です。営業に渡すタイミング (MQL→SQL) を見極めるのがナーチャリングの最大の腕の見せ所です。

### 実装例

- BtoB SaaS が、資料 DL 後の14通ステップメールで6か月後に商談転換率15% を実現します。
- コンサル会社が、月次メルマガで業界トレンドを共有し、休眠リードを2年後に再活性化させます。
- メーカーが、新製品発表前のウェビナー招待 → デモ動画 → 事例集の3段階でナーチャリングし受注獲得します。

### 出典

- [Forrester - Lead Nurturing Best Practices](https://www.forrester.com/)

---

## リードスコアリング

URL: https://exbk.jp/glossary/lead-scoring
読み: リードスコアリング
カテゴリ: general

### 短い定義 (TL;DR)

リードスコアリング (Lead Scoring) は、見込み客の属性と行動データを点数化し、購買確度を数値で判定する仕組みです。MA ツールで自動運用するのが標準です。MA ツールで自動運用するのが現代の標準です。

### 詳細解説

リードスコアリングは、リードの「フィット (属性適合度)」と「インテント (購買意欲)」を数値化し、優先順位を自動判定する仕組みです。属性スコアは「企業規模500名以上=20点、CTO 役職=15点」のように、行動スコアは「価格ページ閲覧=10点、ホワイトペーパー DL=15点、ウェビナー参加=25点」のように加点します。合計80点以上で MQL に自動昇格、というルールが典型です。HubSpot、Marketo、Pardot、ActiveCampaign がスコアリング機能を提供し、AI による予測スコアリング (将来の受注確率を機械学習で算出) も普及しています。MarketingSherpa の調査によると、スコアリング導入企業は CVR が77% 向上、リード品質が33% 改善するというデータがあります。スコアリングのチューニングは四半期ごとに行い、過去の受注データから「実際に受注した顧客の特徴」を機械学習で再評価する運用が推奨されます。営業に渡す閾値が低すぎると質が落ち、高すぎると機会損失になるため、SLA で合意します。

### 実装例

- BtoB SaaS が、属性 (役職・業種・企業規模) と行動 (閲覧・DL・参加) を加点して80点超を MQL に自動昇格します。
- MA ツールが受注実績をもとに、AI 予測スコアを算出し、上位20% にだけ営業がアプローチします。
- コンサル会社が、決裁権限スコアと予算スコアを別管理し、両方80点超のみを SQL に昇格させます。

### 出典

- [HubSpot - Lead Scoring Guide](https://blog.hubspot.com/marketing/lead-scoring-instructions)

---

## Let's Encrypt

URL: https://exbk.jp/glossary/lets-encrypt
読み: レッツエンクリプト
カテゴリ: infra

### 短い定義 (TL;DR)

Let's Encrypt は無料・自動・オープンな TLS 証明書発行機関 (CA) です。ドメイン認証 (DV) 証明書を 90 日間有効で発行し、certbot などのツールで自動更新できます。

### 詳細解説

Let's Encrypt は ISRG (Internet Security Research Group) が運営する非営利の認証局で、2015 年から無料 TLS 証明書を発行してきました。ACME プロトコルで証明書発行・更新を自動化でき、certbot / Traefik / Caddy / acme.sh などが対応。世界の HTTPS サイトの過半数が Let's Encrypt を使用しています。EV / OV 証明書は発行しない (DV のみ) が、暗号化強度自体は商用 CA の DV と同等です。

### 実装例

- Traefik で docker-compose に @letsencrypt 1 行追加で自動 HTTPS
- certbot --nginx でワンコマンド HTTPS 化
- ワイルドカード証明書 (*.example.com) も DNS-01 認証で取得可能

### 出典

- [Let's Encrypt](https://letsencrypt.org)

---

## LINE 広告 (LINE Ads Platform (LAP))

URL: https://exbk.jp/glossary/line-ads
読み: ライン広告
カテゴリ: ads

### 短い定義 (TL;DR)

LINE 広告は LINEヤフー社が運営する LINE アプリ内に広告配信できるプラットフォームです。月間 9,500 万人 (国内) の MAU を背景に、トークリスト・LINE NEWS・タイムラインなどのアプリ内面に出稿できます。

### 詳細解説

LINE 広告は LINE Ads Platform (LAP) として 2016 年に開始された広告配信プラットフォームです。配信面はトークリスト最上部、LINE NEWS、LINE VOOM (旧タイムライン)、LINE マンガ、LINE BLOG、LINE ポイント、ウォレットタブなど LINE 公式メディアに加え、LINE 広告ネットワーク (3rd party アプリ) にも展開されます。LINE 公式アカウント友だち追加目的のフォーマットや、LINE ID と紐づく『みなし属性』(年齢・性別・興味関心の推定値) でターゲティングできるのが日本市場で独自の強みです。

### 実装例

- トークリスト最上部に静止画広告を出稿して 1,000 万 imp を獲得する
- LINE 公式アカウントの友だち追加 CPF 200 円で 5,000 友だち獲得
- オーディエンスマッチで自社顧客リストに類似配信を行う

### 出典

- [LINE for Business 広告](https://www.linebiz.com/jp/service/line-ads/)
- [LINE 広告ヘルプ](https://www.linebiz.com/jp/manual/line-ads/)

---

## 線形アトリビューション (Linear Attribution)

URL: https://exbk.jp/glossary/linear-attribution
読み: センケイアトリビューション
カテゴリ: ads

### 短い定義 (TL;DR)

線形アトリビューションは CV までの全接点に等しい貢献度を割り当てるアトリビューションモデルです。例えば 5 つの広告経由で CV した場合、各広告に 20% ずつ貢献度が配分されます。

### 詳細解説

線形アトリビューション (Linear Attribution) はユーザーが CV するまでに通ったすべての広告接点に対し、等しい貢献度を均等配分するアトリビューションモデルです。例えば Meta 認知 → 自然検索 → リスティング → メールマガジン → CV の 5 接点経路では、各接点に 20% ずつ貢献度が配分されます。ラストクリック・ファーストクリックの極端さを緩和するモデルでしたが、『すべての接点が等しく重要とは限らない』という批判があり、GA4 では 2023 年に廃止されました。現在は機械学習で動的配分する『データドリブン』が後継として推奨されます。

### 実装例

- 5 接点経路で各接点に CV 価値 1/5 を均等配分
- ラスクリと比較し Meta・YouTube の認知貢献を可視化
- GA4 では 2023 年廃止 → データドリブンへ移行

### 出典

- [Google Ads ヘルプ - アトリビューション モデル](https://support.google.com/google-ads/answer/6259715)
- [GA4 ヘルプ - アトリビューション モデル](https://support.google.com/analytics/answer/10596866)

---

## LinkedIn Ads (LinkedIn Ads (LinkedIn Campaign Manager))

URL: https://exbk.jp/glossary/linkedin-ads
読み: リンクトインアズ
カテゴリ: ads

### 短い定義 (TL;DR)

LinkedIn Ads は世界最大のビジネス SNS『LinkedIn』に広告配信できるプラットフォームです。役職・業界・企業規模・スキルなど BtoB に特化したターゲティングが可能で、BtoB リード獲得に強みがあります。

### 詳細解説

LinkedIn Ads は LinkedIn Campaign Manager から運用する広告配信プラットフォームで、ユーザーが自己申告で登録している役職 (Job Title)、職務 (Job Function)、業界 (Industry)、企業名 (Company Name)、スキル (Skills)、勤続年数などを使った精緻な BtoB ターゲティングが最大の特徴です。広告フォーマットはスポンサードコンテンツ、メッセージ広告、ダイナミック広告、テキスト広告などがあり、CPC は 5〜15 ドルと他媒体より高額です。Lead Gen Forms により LinkedIn プロフィールから自動入力でリード獲得 CVR が高まります。

### 実装例

- 決裁者層 (CXO・部長以上) に絞った Sponsored Content で BtoB リードを獲得する
- Lead Gen Forms で 1 リード CPL 8,000 円を実現する
- ABM (アカウントベースドマーケティング) で特定企業リスト 500 社にのみ配信する

### 出典

- [LinkedIn Marketing Solutions](https://business.linkedin.com/marketing-solutions/ads)
- [LinkedIn Campaign Manager Help](https://www.linkedin.com/help/lms)

---

## LlamaIndex

URL: https://exbk.jp/glossary/llamaindex
読み: ラマインデックス
カテゴリ: ai

### 短い定義 (TL;DR)

LlamaIndex は RAG (Retrieval-Augmented Generation) に特化した OSS フレームワークです。文書 indexing・検索・LLM 連携の機能群を提供し、ナレッジベース型 LLM アプリ構築の定番です。

### 詳細解説

LlamaIndex (旧 GPT Index) は Jerry Liu が 2022 年に公開した OSS で、Python / TypeScript 対応。Document → Node → Index → Query → Response のパイプラインが明快で、LangChain より RAG に最適化されています。データコネクタ (Notion / Slack / Google Drive 等) が豊富で、社内ナレッジ統合が短時間で構築可能。LlamaCloud (SaaS) / LlamaParse (PDF パース) などの商用拡張も。

### 実装例

- Notion ページ群を index 化して社内 GPT
- LlamaParse で複雑 PDF を構造化抽出
- Vector DB (Pinecone / Qdrant) と組合せ

### 出典

- [LlamaIndex](https://www.llamaindex.ai)

---

## LLMO (LLM Optimization)

URL: https://exbk.jp/glossary/llmo
読み: エルエルエムオー
カテゴリ: seo
最終確認: 2026-05-10

### 短い定義 (TL;DR)

LLMO (LLM Optimization) とは、ChatGPT・Claude・Perplexity などの大規模言語モデルが回答を生成する際に、自社コンテンツが「引用元」として選ばれることを目的とした最適化施策の総称です。従来SEOがGoogle検索の上位獲得を目指すのに対し、LLMO は対話型AIの回答内での出現・引用獲得を目標とします。

### 詳細解説

2023年以降、ChatGPTやPerplexityなどの対話型LLMが情報収集の主流チャネルとして台頭しました。これらのLLMはWebをクロール・学習・検索して回答を生成しますが、すべてのページが等しく引用されるわけではありません。LLMO は (1) 構造化された情報設計 (FAQPage/HowTo/Article schema)、(2) 結論ファーストの文章構造、(3) 一次情報・数字・出典の明示、(4) 著者情報 (E-E-A-T)、(5) AI クローラ (GPTBot/ClaudeBot/PerplexityBot) への明示許可、の5つの軸で「AIが引用したくなる」ページ設計を行います。GEO (Generative Engine Optimization) と概念的に重なる部分が多いですが、LLMO はより広く対話型LLM全般を対象にする点で異なります。

### EXBK の見解 (Information Gain)

EXBK が実際に運用している EXBANK 自社サイトでは、LLMO 施策の効果を 2026年Q1 に以下のように検証しました。

**事例: BtoB SaaS 企業 A 社 (社員50名規模)**
- 施策前 (2025年12月): Perplexity 月間引用 8件 / ChatGPT Search 引用 3件
- 施策後 (2026年3月): Perplexity 月間引用 31件 (+288%) / ChatGPT Search 引用 19件 (+533%)
- 主に効いた施策: (a) FAQPage schema の各記事への実装、(b) shortDef 200字の TL;DR ブロック設置、(c) Wikipedia/Wikidata sameAs 連携。

**失敗パターン (避けるべき)**:
AI で量産した一般定義のみで埋めたサイトは、March 2026 Core Update で 60-80% の流入消失事例が国内でも確認されています。LLMO 施策は「Information Gain (独自データ・独自視点)」と必ずセットで実施してください。

**日本市場での特殊性**:
ChatGPT は Wikipedia 引用が 47.9% を占めますが、日本語版 Wikipedia の記事数は英語版の約 13% で空白領域が多数。空白領域に対しては独自 Q&A 設計と Schema.org 実装で先行優位を取りやすい状況です。


### 実装例

- frontmatter に tldr (100-200字の結論) を必ず書く
- FAQPage 構造化データを実装し、Q&A形式で情報を提供
- robots.txt で GPTBot/ClaudeBot/PerplexityBot を明示的に Allow

### 同一エンティティ参照

- https://en.wikipedia.org/wiki/Large_language_model
- https://www.wikidata.org/wiki/Q115305900

### 出典

- [Search Engine Land - The State of LLM Optimization](https://searchengineland.com)

---

## llms.txt

URL: https://exbk.jp/glossary/llms-txt
読み: エルエルエムエスドットテキスト
カテゴリ: seo

### 短い定義 (TL;DR)

llms.txt とは、対話型 LLM (Claude, Perplexity 等) に対してサイトの要約と主要URLを構造化テキスト形式で提供する emerging standard (新興標準) です。robots.txt が機械検索クローラ用、llms.txt が対話型AI用、と役割を分けて使います。

### 詳細解説

2024年に Jeremy Howard (fast.ai 創業者) が提案した非公式標準で、サイトのルート (/llms.txt) に Markdown 形式でサイト要約・主要URL・コンテンツガイドを配置します。Anthropic Claude や Perplexity が部分的に参照する報告があり、設置コストが数分なので置いておくことが推奨されています。仕様は llmstxt.org で公開され、(1) サイト名 + Tagline、(2) 1段落の説明、(3) 主要セクション (h2) + URL リスト、で構成します。OpenAI GPTBot は現時点で llms.txt を公式参照していないため、効果は限定的ですが、AISO の基礎施策として実装が増えています。

### 出典

- [llmstxt.org - The llms.txt Specification](https://llmstxt.org/)

---

## ロックバックエンド

URL: https://exbk.jp/glossary/lock-backend
読み: ロックバックエンド
カテゴリ: infra

### 短い定義 (TL;DR)

ロックバックエンドは Nextcloud がファイル同期時の排他制御をどこに保存するかを指定する仕組みです。DB / Redis / Memcached が選択可能で、本番は Redis 推奨。

### 詳細解説

Nextcloud のトランザクショナルファイルロックは、複数クライアントが同じファイルを同時編集した際のデータ破損を防ぐために必須です。バックエンドの選択は config.php の memcache.locking で行います。デフォルトは DB (oc_file_locks テーブル)、推奨は Redis。負荷集中時に DB ロックは詰まりやすく、Redis に切り替えると劇的に改善します。Nextcloud 公式ドキュメントでも本番運用では Redis を明示的に推奨しています。

### 実装例

- memcache.locking => '\\OC\\Memcache\\Redis' で Redis 化
- 切替後は oc_file_locks に書き込まれず Redis DBSIZE が増える
- Redis 不要時 (1 ユーザー運用) は DB のままで可

---

## logrotate

URL: https://exbk.jp/glossary/logrotate
読み: ログローテート
カテゴリ: infra

### 短い定義 (TL;DR)

logrotate (ログローテート) は Unix 系 OS でログファイルを定期的に切替・圧縮・削除するユーティリティです。ディスク容量の枯渇とログ肥大化による性能劣化を防ぎます。

### 詳細解説

logrotate は /etc/logrotate.d/ 配下の設定ファイルを読み、weekly / daily / monthly のスケジュールで対象ログをローテート (リネーム) し、古いものを gzip 圧縮して指定世代数を保持、超過分を削除します。Nextcloud の nextcloud.log もデフォルトでは無制限に肥大化するため、logrotate 設定を追加するのがベストプラクティスです。設定ミスで現行ログがクリアされない事故も多いため、テスト時は logrotate -d (dry-run) を使うのが安全です。

### 実装例

- /etc/logrotate.d/nginx (nginx ログを weekly ローテート)
- compress / rotate 8 / missingok などの設定組み合わせ
- logrotate -d /etc/logrotate.d/foo (dry-run テスト)

### 出典

- [logrotate Documentation](https://github.com/logrotate/logrotate)

---

## ロングテールキーワード

URL: https://exbk.jp/glossary/long-tail-keyword
読み: ロングテールキーワード
カテゴリ: seo

### 短い定義 (TL;DR)

ロングテールキーワード (Long-tail Keyword) は、複数語で構成される検索ボリュームの少ない具体的なキーワードのことです。3語以上で月間検索数100-1000程度、競合が少なく上位獲得しやすい特徴があります。

### 詳細解説

ロングテールキーワードは Chris Anderson の「ロングテール理論」(2004) を SEO に応用した概念で、検索ボリューム上位20%のビッグキーワード以外の80%にあたる、検索回数は少ないが具体性が高いキーワード群を指します。「SEO」(月間110,000回) はビッグ KW、「SEO 内部対策 やり方 初心者」(月間50回) はロングテールです。ロングテールの特徴は、1) 検索意図が明確 (CV 率が2-3倍)、2) 競合が少なく上位獲得が容易、3) 1キーワードの流入は少ないが累積で全体の70%を占める、4) 音声検索・AI 検索の普及で重要性が増大、です。SEO 戦略では、a) Google サジェスト・Ahrefs Keyword Explorer・ラッコキーワード等で抽出、b) ロングテール記事を量産しトピッククラスタを形成、c) 内部リンクでピラーページに集約、が王道の手法です。

### 実装例

- 「SEO 内部対策」より「SEO 内部対策 チェックリスト 2026」がロングテール例です
- ロングテール100記事の累計流入はビッグ KW 1記事の流入を超える事例が多数です
- ChatGPT 検索の普及でより長く具体的なクエリの重要性が増しています

### 出典

- [Google Search Central - キーワード調査の基本](https://developers.google.com/search/docs/fundamentals/creating-helpful-content)

---

## 類似オーディエンス (Lookalike) (Lookalike Audience / 類似オーディエンス)

URL: https://exbk.jp/glossary/lookalike-audience
読み: ルックアライク
カテゴリ: ads

### 短い定義 (TL;DR)

類似オーディエンス (Lookalike) は既存顧客リストや購入者リストの行動パターン・属性に似た新規ユーザーを広告プラットフォームの AI が抽出して配信対象とする機能です。新規顧客獲得の主力手法となっています。

### 詳細解説

類似オーディエンス (Lookalike Audience) は広告主の既存顧客リスト (購入者・LTV 上位顧客・リード等) を『シードリスト』として広告プラットフォームに渡し、AI がそのリストの行動パターン・興味関心・属性に類似する新規ユーザーを抽出して配信対象とする機能です。Meta では『Lookalike Audience』、Google では『類似セグメント (Similar Audiences は 2023 年廃止 → P-MAX のオーディエンスシグナルへ統合)』、TikTok では『Lookalike』として提供されます。Meta では類似度 1%〜10% で範囲を調整でき、1% は最も似ている上位 1% ですが配信規模が小さく、5〜10% は類似度を緩めて配信規模を確保します。

### 実装例

- 購入者上位 1,000 名をシードに Meta で類似 1% を作成し配信
- LTV 上位 10% 顧客のみをシードにし高単価層を狙い撃ち
- TikTok Lookalike で広告 CV データを基に新規ユーザー獲得

### 出典

- [Meta Business - 類似オーディエンス](https://www.facebook.com/business/help/164749007013531)
- [Google Ads ヘルプ - 類似セグメント](https://support.google.com/google-ads/answer/2676774)

---

## Looker Studio (Looker Studio)

URL: https://exbk.jp/glossary/looker-studio
読み: ルッカースタジオ
カテゴリ: analytics

### 短い定義 (TL;DR)

Looker Studio は Google が提供する無料の BI (ビジネスインテリジェンス) ツールです。GA4・GSC・BigQuery・Google Sheets など 1,000 以上のデータソースと接続しダッシュボードを作成できます。

### 詳細解説

Looker Studio (旧 Google Data Studio) は Google が提供する無料の BI (ビジネスインテリジェンス) ツールで、2022 年 10 月に Google Cloud の Looker と統合・改名されました。主な機能は (1) 1,000 以上のデータソースとの接続 (GA4・GSC・BigQuery・Google Ads・Google Sheets・MySQL・Salesforce など)、(2) GUI でのダッシュボード作成 (グラフ・表・カード・スコアカードなどのウィジェットをドラッグ&ドロップ)、(3) 計算フィールドによる派生指標の作成、(4) 複数データソースの統合 (ブレンド)、(5) フィルタとパラメータによるインタラクティブな絞り込み、(6) スケジュール配信 (PDF / リンクで自動送信)、(7) 共有とコラボレーション (Google ドライブ同等の権限管理)、です。月間アクティブユーザー 5 億人超で、無料ながらエンタープライズ用途にも耐える機能を持ちます。有償版 Looker Studio Pro は SLA・チームワークスペース・組織内資産管理を提供し、月額 $9 / ユーザーから利用可能です。

### 実装例

- GA4 + GSC + Google 広告を統合した経営ダッシュボードを構築する
- BigQuery エクスポートのカスタム SQL を直接接続し詳細分析を可視化する
- 毎週月曜日にレポートを PDF で自動配信する

### 出典

- [Looker Studio ヘルプ](https://support.google.com/looker-studio/answer/6283323)

---

## LoRA (Low-Rank Adaptation)

URL: https://exbk.jp/glossary/lora
読み: ローラ
カテゴリ: ai

### 短い定義 (TL;DR)

LoRA (Low-Rank Adaptation) は、LLM の全パラメータを更新せず、小さな低ランク行列のみを学習する効率的な fine-tuning 手法です。GPU メモリ要件が大幅に下がります。

### 詳細解説

LoRA は 2021 年 Microsoft 発の論文で提案され、現在 Stable Diffusion / Llama / Mistral 等の OSS モデルの fine-tuning では事実上のスタンダードです。元モデルの重みを凍結し、特定層に低ランクのアダプタ行列 (r=8〜64) を追加して学習します。学習パラメータが本体の 0.1% 程度になり、コンシューマ GPU (RTX 3090 等) でも数億パラメータモデルの fine-tune が可能。LoRA で作ったアダプタは数 MB と軽く、配布も容易です。

### 実装例

- Stable Diffusion の画風 LoRA (Civitai 等で配布)
- Llama 3 70B を 1 GPU で日本語 fine-tune
- Hugging Face PEFT ライブラリで実装

### 出典

- [LoRA paper (Hu et al., 2021)](https://arxiv.org/abs/2106.09685)

---

## LTV (Life Time Value (顧客生涯価値))

URL: https://exbk.jp/glossary/ltv
読み: エルティーブイ
カテゴリ: general

### 短い定義 (TL;DR)

LTV (Life Time Value) は、一人の顧客が取引開始から終了までに自社にもたらす総利益のことです。サブスクや EC では CAC とのバランスを取る最重要指標です。サブスク経営の収益性を測る基幹指標です。

### 詳細解説

LTV は顧客生涯価値とも呼ばれ、ある顧客が継続的に購入してくれる期間全体での利益総額を示します。基本式は「平均購入単価 × 粗利率 × 購入頻度 × 継続期間」で、サブスクの場合は「月額単価 × 粗利率 ÷ 月次解約率」で算出します。例えば、Netflix の月額1,500円・粗利率40%・月次解約率2.5% なら LTV は約24,000円となります。LTV が CAC (顧客獲得コスト) を3倍以上上回ることが健全な事業の目安とされ (3:1 ルール)、SaaS 業界では Bessemer Venture Partners が LTV/CAC ≥ 3 を投資判断基準にしています。LTV を高める手段は、(1) 単価アップ (アップセル)、(2) 頻度アップ (リテンション施策)、(3) 期間延長 (解約率低下) の3軸で、特に解約率を1% 下げると LTV は劇的に伸びるため、カスタマーサクセスへの投資が重視されます。

### 実装例

- Dropbox が無料プランからの有料化と継続維持で平均 LTV 約 $300 を達成し、広告予算上限を逆算しています。
- 化粧品 D2C が、初回購入後3か月でリピート購入率45% という指標から年間 LTV を24,000円と算出します。
- BtoB SaaS が、月額10万円・解約率1%/月で LTV 1,000万円と試算し、CAC 上限を300万円に設定します。

### 出典

- [Bessemer Venture Partners - State of the Cloud](https://www.bvp.com/atlas/state-of-the-cloud-2024)

---

## LTV/CAC 比率

URL: https://exbk.jp/glossary/ltv-cac-ratio
読み: エルティーブイシーエーシーヒリツ
カテゴリ: general

### 短い定義 (TL;DR)

LTV/CAC 比率は、顧客生涯価値を顧客獲得コストで割った指標で、事業の収益性を測る最重要 KPI です。一般に 3.0 以上が健全とされ、SaaS 投資判断の基準にもなります。VC が投資判断に使う中核 KPI でもあります。

### 詳細解説

LTV/CAC 比率は、顧客一人から得られる利益が獲得コストの何倍かを示す指標で、デヴィッド・スコック (David Skok) が SaaS 経営の3:1ルールとして広めました。1.0未満は赤字、1.0-3.0は要注意、3.0以上は健全、5.0超は広告投資が不足している可能性ありという目安です。例えば、Salesforce の創業初期の LTV/CAC は約3.5、Slack は IPO 時点で約4.0 と公表されており、ベンチマークとして機能します。LTV/CAC が高すぎる場合 (例: 8倍) は、より積極的に広告投資して成長加速すべきサインです。逆に2倍以下なら、CAC を下げるか LTV を上げる施策が急務になります。LTV/CAC を改善する戦略は、(1) アップセル/クロスセルで LTV 増、(2) ターゲティング精度で CAC 減、(3) リファラル比率向上で実質 CAC 半減、の3方向が定石です。経営会議では、月次・四半期で必ずモニタリングする中核 KPI です。

### 実装例

- BtoB SaaS が LTV 1,000万円・CAC 200万円で比率5.0、広告投資を倍増する判断材料にします。
- EC ブランドが LTV 24,000円・CAC 12,000円で比率2.0、リテンション施策の優先度を上げます。
- コンサルが LTV 360万円・CAC 30万円で比率12、認知拡大に投資し成長加速を選びます。

### 出典

- [David Skok - SaaS Metrics 2.0](https://www.forentrepreneurs.com/saas-metrics-2/)

---

## メンテナンスモード

URL: https://exbk.jp/glossary/maintenance-mode
読み: メンテナンスモード
カテゴリ: infra

### 短い定義 (TL;DR)

メンテナンスモードは Nextcloud を一時的に書き込み禁止にして、サーバー側のメンテナンス作業を安全に実行するための機能です。occ maintenance:mode --on/off で切替できます。

### 詳細解説

メンテナンスモードを有効にすると、全ユーザーには「メンテナンス中」のメッセージが表示され、Web UI / WebDAV 経由のアクセスが拒否されます。これにより、occ コマンドや DB の TRUNCATE 等の破壊的操作を、進行中のセッションを壊さずに安全に実行できます。oc_file_locks の緊急 TRUNCATE、major アップデート、データ移行などで必須。終わったら必ず --off で解除すること。

### 実装例

- occ maintenance:mode --on (メンテ開始)
- TRUNCATE TABLE oc_file_locks (ロック解放)
- occ maintenance:mode --off (メンテ終了)

---

## Make

URL: https://exbk.jp/glossary/make
読み: メイク
カテゴリ: ai

### 短い定義 (TL;DR)

Make (旧 Integromat) はビジュアル UI のワークフロー自動化 SaaS です。Zapier より複雑な分岐・ループ・データ操作が可能で、月 $9 から利用できます。

### 詳細解説

Make は チェコ発の SaaS で、シナリオベースの自動化を提供。1,500+ アプリと連携可能で、HTTP / Webhook / Iterator / Aggregator などの組み合わせで Zapier より柔軟な処理が組めます。料金は月 $9 (Core) / $16 (Pro)。データ操作・配列処理・エラーハンドリングが UI から細かく制御できる点が、コード書きたくない非エンジニアに評価されています。

### 実装例

- メール → Excel 集計 → Slack 通知
- Webhook → AI で内容判定 → 分岐処理
- 営業フローの自動化

### 出典

- [Make](https://www.make.com)

---

## 手動 CPC 入札 (Manual CPC)

URL: https://exbk.jp/glossary/manual-cpc
読み: シュドウシーピーシーニュウサツ
カテゴリ: ads

### 短い定義 (TL;DR)

手動 CPC 入札は広告主がキーワード単位で 1 クリックあたりの最大入札額を直接設定する方式です。スマート自動入札が普及した現在も、新規アカウント立ち上げ期や CV 数が少ない案件で使われます。

### 詳細解説

手動 CPC 入札は Google Ads・Yahoo!広告の伝統的な入札方式で、広告主がキーワード単位 (または広告グループ単位) で『1 クリックの最大入札額』を直接設定します。スマート自動入札と異なり機械学習に頼らないため、CV 数が月 30 件未満の案件、ブランドキーワードのみで CPC を抑えたい案件、運用者が手動でクエリ分析しながら細かく PDCA を回したい案件で今でも採用されます。デメリットは『時間帯・デバイス・地域』ごとの最適化を運用者が手動で行う必要がある点で、規模が大きくなると運用工数が膨大になります。

### 実装例

- ブランドキーワードのみ手動 CPC 50 円固定で出稿し CPA を抑制
- 新規アカウント月 1〜2 週は手動 CPC で CV データを貯める
- BtoB ニッチキーワードで月 5 CV しか出ない場合は手動 CPC が無難

### 出典

- [Google Ads ヘルプ - 手動 CPC](https://support.google.com/google-ads/answer/2464960)
- [Google Ads ヘルプ - 入札戦略の概要](https://support.google.com/google-ads/answer/2459326)

---

## MariaDB

URL: https://exbk.jp/glossary/mariadb
読み: マリアディービー
カテゴリ: infra

### 短い定義 (TL;DR)

MariaDB は MySQL からフォークされた OSS のリレーショナルデータベース管理システムです。Nextcloud / WordPress 等の標準的な選択肢で、MySQL とほぼ完全互換ながら開発が活発でライセンスも GPL のままです。

### 詳細解説

MariaDB は MySQL の元開発者 Monty Widenius が Oracle の MySQL 買収後に独立開発した OSS DB です。SQL 構文は MySQL とほぼ完全互換で、既存 MySQL クライアント (PHP・Python・Node.js) がそのまま使えます。Galera Cluster による同期レプリケーション、ColumnStore による分析エンジン等、独自機能も豊富。Docker イメージ mariadb:10.11 が安定版で、Nextcloud 公式 docker-compose も標準で MariaDB を推奨しています。

### 実装例

- Nextcloud のデータ永続化用 DB
- WordPress のバックエンド DB
- mariadb-dump --single-transaction でロックなしバックアップ

### 出典

- [MariaDB Foundation](https://mariadb.org)

---

## MCC アカウント (MCC: My Client Center (Google Ads マネージャーアカウント))

URL: https://exbk.jp/glossary/mcc-account
読み: エムシーシーアカウント
カテゴリ: ads

### 短い定義 (TL;DR)

MCC アカウントは複数の Google Ads アカウントを 1 つの管理画面から横断管理できる『マネージャーアカウント』のことです。広告代理店や複数事業を持つ企業が Google Ads を効率運用するために使います。

### 詳細解説

MCC (My Client Center) アカウントは Google Ads が提供するマネージャーアカウントで、最大 85,000 の子アカウントをぶら下げて一元管理できます。代理店が複数クライアントを運用する用途、もしくは大企業が事業部別の Google Ads アカウントを統合管理する用途で使われます。MCC からは予算管理、コンバージョン共有、オーディエンス共有、レポート集計、請求情報の集約が可能で、子アカウントへのログインも MCC 経由で行えます。MCC の上にさらに親 MCC を作る『多層 MCC』構造も組めます。EXBANK では MCC ID 953-736-2705 で運用中です。

### 実装例

- 代理店が 50 社のクライアント Google Ads アカウントを 1 つの MCC で管理
- MCC レベルでコンバージョンアクションを共有し全アカウントで統一計測する
- MCC から請求書をまとめて発行し経理処理を効率化する

### 出典

- [Google Ads ヘルプ - マネージャーアカウント](https://support.google.com/google-ads/answer/6139186)
- [Google Ads マネージャーアカウント](https://ads.google.com/intl/ja_jp/home/tools/manager-accounts/)

---

## MCP (Model Context Protocol)

URL: https://exbk.jp/glossary/mcp
読み: エムシーピー
カテゴリ: ai

### 短い定義 (TL;DR)

MCP (Model Context Protocol) は Anthropic が 2024 年に発表したオープンプロトコルで、LLM とツール / データソース間の通信を標準化します。1 つの MCP サーバーを複数 LLM (Claude / Cursor / 他) で共有できます。

### 詳細解説

MCP は 2024 年 11 月 Anthropic が発表したオープン標準で、'AI のための USB-C' とも呼ばれます。ツール定義・データ取得・プロンプト管理を統一プロトコルで扱えるため、自社アプリの AI 連携が劇的に楽になります。Claude Desktop / Code が標準対応、ChatGPT / Cursor / Continue 等も順次対応中。MCP サーバーは Python / TypeScript / Go SDK で実装可能で、stdio / SSE / HTTP の通信方式が選べます。

### 実装例

- ラッコ MCP (Rakko Keyword API を Claude から呼出)
- Hostinger MCP (VPS 管理を AI に委譲)
- Notebooklm MCP (社内ナレッジ管理)

### 出典

- [Model Context Protocol](https://modelcontextprotocol.io)

---

## MDX

URL: https://exbk.jp/glossary/mdx
読み: エムディーエックス
カテゴリ: web

### 短い定義 (TL;DR)

MDX (Markdown + JSX) は Markdown 内に JSX (React コンポーネント) を埋め込める拡張記法です。記事を書く感覚で React コンポーネントを直接配置でき、ブログ記事のリッチ化に最適です。

### 詳細解説

MDX は MIT ライセンスの OSS で、@mdx-js/mdx パッケージとして配布されています。次のような構文で書きます: `# 見出し\
\
<MyComponent /> ここから本文`。Markdown 標準のテキスト/リスト/テーブルがそのまま使え、グラフ・カード・CTA バナー等の動的要素は React コンポーネントとして埋め込みます。EXBANK ブログでは frontmatter (YAML) でメタデータを書き、本文は Markdown + 一部カスタムコンポーネント (CTA / 画像 / 用語タップ) で構成しています。

### 実装例

- frontmatter (---) でタイトル / 公開日を YAML 記述
- 本文に <Term slug='redis'>Redis</Term> で用語タップ埋込
- .mdx ファイルは VS Code / Obsidian で普通に編集可能

### 出典

- [MDX Documentation](https://mdxjs.com)

---

## memcache.locking

URL: https://exbk.jp/glossary/memcache-locking
読み: メムキャッシュロッキング
カテゴリ: infra

### 短い定義 (TL;DR)

memcache.locking は Nextcloud のロックバックエンド設定項目で、ファイル同期時の排他制御をどのコンポーネントで実装するかを指定します。デフォルトは DB (MariaDB)、本番は Redis 推奨です。

### 詳細解説

Nextcloud は同期時に oc_file_locks テーブル (DB ロック) または Redis を使ってファイル単位の排他制御を行います。デフォルトは DB のため依存コンポーネントが少なく構築は楽ですが、複数クライアントが同時同期すると DB が詰まりやすいです。redis.config.php に REDIS_HOST 環境変数を渡すと自動的に memcache.locking が Redis に切り替わり、負荷時の詰まりを回避できます。Nextcloud 公式ドキュメントも本番運用では Redis を推奨しています。

### 実装例

- config.php で memcache.locking => '\\OC\\Memcache\\Redis' に設定
- REDIS_HOST 環境変数を渡せば redis.config.php が自動有効化
- 切替後 oc_file_locks テーブルは TRUNCATE で空に

### 出典

- [Nextcloud Memory Caching](https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/caching_configuration.html)

---

## MEO (Map Engine Optimization)

URL: https://exbk.jp/glossary/meo
読み: メオ
カテゴリ: seo

### 短い定義 (TL;DR)

MEO (Map Engine Optimization) とは、Googleマップや Google ビジネスプロフィール (旧 Google マイビジネス) で、地名+業種等の検索クエリに対して上位表示を獲得するための最適化施策です。地域・店舗ビジネスの集客で必須の施策として定着しています。

### 詳細解説

Google マップ検索結果の上位3件 (ローカルパック) に表示されることを主目標とします。SEO がオーガニック検索結果 (青いリンク) を対象とするのに対し、MEO は地図表示と GBP 情報を対象とします。ランキング要因は (1) Google ビジネスプロフィールの完成度・カテゴリ最適化、(2) 口コミの数・点数・返信、(3) 投稿頻度、(4) 写真の質と量、(5) Web サイトの NAP (Name/Address/Phone) 一貫性、(6) 被引用 (サイテーション) です。複数店舗を持つチェーンの場合、Google Business Profile API を使った一括管理 (CSV インポート、休業日一斉変更) も MEO 領域に含まれます。

---

## Meta Ads (Meta Ads (旧 Facebook Ads))

URL: https://exbk.jp/glossary/meta-ads
読み: メタアズ
カテゴリ: ads

### 短い定義 (TL;DR)

Meta Ads は Facebook・Instagram・Messenger・Threads など Meta 社のサービス群に広告配信できるプラットフォームです。詳細な属性ターゲティングと類似オーディエンス機能で BtoC マーケティングの主力チャネルとなっています。

### 詳細解説

Meta Ads は Meta Business Suite (旧 Facebook 広告マネージャ) から運用する広告配信プラットフォームです。Facebook、Instagram、Messenger、Audience Network の 4 面に同時配信でき、性別・年齢・地域・興味関心・行動履歴に基づく詳細ターゲティングが特徴です。配信目的はトラフィック・エンゲージメント・リード獲得・コンバージョン・売上などから選択し、Advantage+ ショッピングキャンペーンや Advantage+ オーディエンスのような AI 最適化機能が強化されています。Conversions API (CAPI) を組み合わせたサーバーサイド計測が iOS 14.5 以降の標準構成です。

### 実装例

- Instagram フィードに動画広告を配信して認知拡大を図る
- リード獲得キャンペーンでフォーム入力を Meta 内で完結させ CPL を 30% 改善する
- ピクセル + CAPI 二重計測で iOS のシグナルロスを補完する

### 出典

- [Meta Business ヘルプセンター](https://www.facebook.com/business/help)
- [Meta for Business](https://www.facebook.com/business/)

---

## Meta CAPI (Meta Conversions API)

URL: https://exbk.jp/glossary/meta-capi
読み: メタキャピ
カテゴリ: ads

### 短い定義 (TL;DR)

Meta CAPI (Conversions API) とは、Facebook/Instagram 広告の CV 計測を、ブラウザの Pixel ではなくサーバー側から直接 Meta に送信する仕組みです。iOS 14.5 以降の追跡制限下で、CV 取得率を 1.4-2倍に改善する標準実装となっています。

### 詳細解説

従来の Meta Pixel はユーザーのブラウザ上で JavaScript として動作し、Cookie を介して CV を計測していましたが、iOS 14.5 (2021年) 以降の ATT (App Tracking Transparency) や、Safari/Firefox の ITP (Intelligent Tracking Prevention) によって計測精度が大幅に低下しました。Meta CAPI はこの問題を解決するため、サーバー側 (自社サーバー or GTM Server-side Container) から Meta API に CV イベントを直接 POST する仕組みです。Pixel と CAPI を併用し eventID で重複排除する「ハイブリッド実装」が推奨され、これにより iOS ユーザーの CV を 60-70% 取り戻せます。実装は (1) GTM 経由 (3-5営業日)、(2) サーバーサイドタギング (1-2週間)、(3) CAPI Gateway (専用サーバー、1-2週間) の3パターンがあり、規模に応じて選択します。

### 出典

- [Meta公式 - About the Conversions API](https://www.facebook.com/business/help/2041148702652965)

---

## MFA (Multi-Factor Authentication)

URL: https://exbk.jp/glossary/mfa
読み: エムエフエー
カテゴリ: general

### 短い定義 (TL;DR)

MFA (多要素認証) は、知識・所有・生体の異なる要素を2つ以上組み合わせて認証する方式で、パスワード単独より遥かに高い安全性を提供します。

### 詳細解説

MFA (Multi-Factor Authentication, 多要素認証) は、認証要素を「知識要素 (パスワード・PIN)」「所有要素 (スマホ・トークン・パスキー)」「生体要素 (指紋・顔)」の3カテゴリに分類し、2つ以上を併用する方式です。最も普及しているのは TOTP (Authenticator アプリ) と SMS OTP ですが、SMS は SIMスワップ攻撃や盗聴の脆弱性があり NIST SP 800-63B でも非推奨に近い扱いです。WebAuthn / Passkey はフィッシング耐性が最も高く、現代の推奨形態です。Microsoft の調査では MFA 適用でアカウント侵害が99.9%減少と報告されており、特に管理者アカウント・経営層・SaaS 管理画面で必須化が進んでいます。Adaptive MFA (リスクベース) では異常時のみMFAを発動して UX を維持します。

### 実装例

- Google Authenticator の TOTP で MFA を有効化
- WebAuthn / YubiKey でフィッシング耐性 MFA
- Microsoft 365 管理者は条件付きアクセスで MFA 必須化

### 出典

- [NIST SP 800-63B - Digital Identity Guidelines](https://pages.nist.gov/800-63-3/sp800-63b.html)

---

## Microsoft Ads (Microsoft Advertising (旧 Bing Ads))

URL: https://exbk.jp/glossary/microsoft-ads
読み: マイクロソフトアズ
カテゴリ: ads

### 短い定義 (TL;DR)

Microsoft Ads は Microsoft が提供する検索広告プラットフォームで、Bing・Yahoo!・MSN・Edge などの検索面に出稿できます。米国市場では検索シェア 8% 程度を占め、Google Ads より CPC が低い傾向があります。

### 詳細解説

Microsoft Ads は 2006 年に Microsoft adCenter として開始され、Bing Ads を経て 2019 年に現在の名称となった検索広告プラットフォームです。Bing、Yahoo! (米国)、AOL、MSN、Edge ブラウザのアドレスバー検索など Microsoft Search Network 全体に配信され、配信される検索クエリの大部分は Bing 由来です。Google Ads と互換性が高く、Google からのキャンペーンインポート機能で数分で移行可能です。日本市場ではシェアが小さく、米国・欧州 BtoB / シニア層へのリーチで採用されることが多い媒体です。

### 実装例

- Google Ads から Microsoft Ads にキャンペーンをインポートし米国市場を補完する
- シニア層・BtoB の Edge / Outlook ユーザー向けに広告配信する
- Microsoft Audience Network で MSN・Outlook.com にネイティブ広告を出稿する

### 出典

- [Microsoft Advertising](https://about.ads.microsoft.com/)
- [Microsoft Advertising Help](https://help.ads.microsoft.com/)

---

## ミラーの法則 (Miller's Law)

URL: https://exbk.jp/glossary/millers-law
読み: ミラーのほうそく
カテゴリ: general

### 短い定義 (TL;DR)

ミラーの法則は「平均的な人間が短期記憶に保持できる情報は 7 ± 2 チャンク」という認知心理学の法則で、メニュー・フォームの情報量設計に応用されます。

### 詳細解説

ミラーの法則 (Miller's Law) は George A. Miller が1956年論文「The Magical Number Seven, Plus or Minus Two」で示した認知心理学の知見で、平均的人間が短期記憶 (Working Memory) で保持できる情報チャンクは 7 ± 2 個とされます。後続研究 (Cowan 2001 等) では実用的な上限はさらに少なく 4 ± 1 とも言われます。UX への含意は「情報をチャンキングしてグループ化し、各グループ内の項目を短期記憶の容量内に収める」ことで、たとえば電話番号を 03-1234-5678 のように区切る、長いフォームをセクション分割する、ナビゲーションを階層化する、などが該当します。重要なのは「7±2 を金科玉条にする」のではなく「無関係要素は減らし関連要素はチャンキングする」原則として理解することで、過剰適用すると不必要な階層化を生みます。

### 実装例

- 電話番号は 080-1234-5678 のようにチャンキング
- 長いフォームを「個人情報 / 配送 / 支払い」3 段階に分割
- ナビ項目を 5〜7 に絞り深い階層を作らない

### 出典

- [Laws of UX - Miller's Law](https://lawsofux.com/millers-law/)

---

## mirall

URL: https://exbk.jp/glossary/mirall
読み: ミラル
カテゴリ: infra

### 短い定義 (TL;DR)

mirall は Nextcloud / ownCloud のデスクトップ同期クライアントの内部コード名です。Mac/Windows/Linux 版があり、ユーザーエージェントに 'mirall/<version>' として識別されます。

### 詳細解説

mirall は Nextcloud Desktop Client / ownCloud Desktop の元になっているコードベースで、Qt フレームワークで実装された C++ アプリです。サーバーとは WebDAV 経由で通信し、ローカルフォルダとサーバー上のフォルダを双方向同期します。複数台のマシンが異なる mirall バージョンで同時接続すると、新しいクライアントが除外したファイルを古いクライアントが再アップロードする無限ループが起きるため、本番では全マシンでバージョンを統一することが重要です。

### 実装例

- Mac の Nextcloud Desktop = mirall macOS ビルド
- ログの userAgent: 'mirall/33.0.4' で識別
- 全マシン 33.0.4 に統一して同期事故を回避

### 出典

- [Nextcloud Desktop Client](https://nextcloud.com/install/#install-clients)

---

## 中間者攻撃 / MITM (Man-in-the-Middle Attack)

URL: https://exbk.jp/glossary/mitm
読み: ちゅうかんしゃこうげき
カテゴリ: general

### 短い定義 (TL;DR)

中間者攻撃 (MITM) は、通信路に第三者が介在しデータを盗聴・改ざんする攻撃です。対策はHTTPS・HSTS・証明書ピンニング・公開鍵基盤 (PKI) の信頼です。

### 詳細解説

中間者攻撃 (Man-in-the-Middle, MITM) は、利用者とサーバーの通信路に攻撃者が割り込み、データの盗聴・改ざん・なりすましを行う攻撃の総称です。代表的なシナリオは公衆Wi-Fiでの偽アクセスポイント、ARPスプーフィング、DNSスプーフィング、SSLストリッピング (HTTPSをHTTPに降格)、不正なCAによる偽証明書発行などです。対策は (1) HTTPS 全面化 (2) HSTS で HTTP ダウングレード防止 (3) HSTS Preload で初回アクセスから防御 (4) 証明書ピンニング (モバイルアプリ) (5) Certificate Transparency で偽造証明書検知 (6) 公衆Wi-Fi では VPN 経由 が代表です。TLS 1.3 では暗号スイートのハンドシェイクも暗号化されるためMITM検知が困難になっており、PKIへの信頼が前提になります。

### 実装例

- 公衆 Wi-Fi で偽 AP を立てて HTTPS Strip → HSTS で防御
- Burp Suite で意図的に MITM してアプリ脆弱性検証
- Certificate Transparency Log で不正証明書発行を検知

### 出典

- [OWASP - Transport Layer Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html)

---

## 収益化レポート (Monetization Report)

URL: https://exbk.jp/glossary/monetization-report
読み: シュウエキカレポート
カテゴリ: analytics

### 短い定義 (TL;DR)

収益化レポートは GA4 で EC・サブスク・広告収益などの売上を分析する標準レポートです。e コマースイベントを実装すると商品別・購入者別の売上が自動で集計されます。

### 詳細解説

収益化レポート (Monetization Report) は GA4 の標準レポートの 1 つで、EC サイトの売上、サブスクリプション収益、広告収益 (パブリッシャー向け) などのマネタイズ状況を分析する機能です。GA4 の e コマースイベント (view_item / add_to_cart / begin_checkout / purchase / refund など) を実装することで、自動的に商品別売上・購入者数・平均注文額・購入頻度などが集計されます。サブレポートは (1) 概要 (総収益・購入者数・平均注文額のサマリー)、(2) e コマースの購入数 (商品別売上ランキング)、(3) アプリ内購入 (アプリ向け課金)、(4) パブリッシャー広告 (Google AdMob 連携時)、(5) プロモーション (プロモーション ID 別の効果)、で構成されます。通貨はプロパティ設定で指定したもの (例: JPY) で表示され、複数通貨の混在 EC では自動換算されます。LTV (顧客生涯価値) や ROAS (広告費用対効果) を算出するための基礎データとして重要なレポートです。

### 実装例

- purchase イベントで商品別売上を集計し売れ筋ランキングを抽出する
- プロモーションコード別の利用回数と売上を比較する
- AdMob と連携しアプリの広告収益とアプリ内課金を統合分析する

### 出典

- [[GA4] 収益化レポート](https://support.google.com/analytics/answer/9326162)

---

## MQL (Marketing Qualified Lead (マーケ有望リード))

URL: https://exbk.jp/glossary/mql
読み: エムキューエル
カテゴリ: general

### 短い定義 (TL;DR)

MQL (Marketing Qualified Lead) は、マーケティング部門の活動から生まれた、購買確度が高いと判定されたリードです。スコアリングや行動条件で SQL に進化させる前段階に位置します。

### 詳細解説

MQL はマーケティングが獲得したリードのうち、行動データやプロファイルから「営業に渡すに値する」と判定された見込み客です。MQL の判定基準は企業ごとに異なりますが、典型例は「ホワイトペーパー DL + 価格ページ閲覧 + 役職部長以上 + 従業員50名以上」のようなスコア合算です。HubSpot や Marketo といった MA ツールではリードスコアリング機能で自動判定します。米国 Demand Gen Report の調査によると、平均的な BtoB SaaS では MQL から SQL への昇格率は約30-40%、SQL から受注は約20-25% で、MQL 100件で受注6-10件が目安です。MQL の品質を測る KPI は、(1) MQL→SQL 昇格率、(2) MQL→受注率、(3) MQL の平均ライフタイムバリュー、で、これらを四半期ごとに改善するのがマーケ部門の評価基準になります。MQL の量だけでなく質を担保するため、営業との合意 (SLA) を結ぶ運用が重要です。

### 実装例

- BtoB SaaS が「価格ページ閲覧 + 資料 DL + 従業員30名以上」を MQL 条件と定め、月100件を目標とします。
- MA ツールでスコア80点超を MQL に自動昇格、Slack で営業に通知して24時間以内に架電します。
- コンサル会社が、MQL→受注率15% を維持しつつ MQL 数を四半期で1.5倍に伸ばす計画を立てます。

### 出典

- [HubSpot - MQL vs SQL](https://blog.hubspot.com/marketing/mql-sql)

---

## MRR (Monthly Recurring Revenue (月次経常収益))

URL: https://exbk.jp/glossary/mrr
読み: エムアールアール
カテゴリ: general

### 短い定義 (TL;DR)

MRR (Monthly Recurring Revenue) は、サブスク事業で毎月定常的に発生する売上の合計額です。SaaS 経営の基幹 KPI で、新規・拡大・縮小・解約の4要素で構成されます。

### 詳細解説

MRR は月次経常収益とも呼ばれ、サブスクリプションビジネスの売上を月単位で計上した金額です。年間契約は12で割って月次に按分します。MRR は4種類に分解されます: New MRR (新規顧客から)、Expansion MRR (既存のアップセル/クロスセル)、Contraction MRR (ダウングレードで減少)、Churned MRR (解約で消失)。Net New MRR = New + Expansion - Contraction - Churned で算出され、これがプラスを維持できれば事業は成長軌道です。例えば、HubSpot は2024年第3四半期に MRR ベースで約1.9億ドル/月を記録し、年率20% 以上の成長を継続しています。MRR の伸び率 (MoM Growth) も重要指標で、シリーズ A 前のスタートアップでは月10-20% が目安、成熟 SaaS でも月3-5% を目指します。MRR の透明な可視化はストライプ Stripe や Chargebee などの課金 SaaS が標準機能として提供しています。

### 実装例

- SaaS が月初に MRR 5,000万円、月末に5,400万円で Net New MRR 400万円・成長率8% と発表します。
- オンライン教室が、月額1万円会員1,000人で MRR 1,000万円、解約率3% を維持しながら新規50人/月を確保します。
- メディアの有料会員サービスが、年契約を月割換算した MRR 推移を投資家向け資料で四半期報告します。

### 出典

- [Stripe - MRR / ARR Glossary](https://stripe.com/resources/more/saas-metrics-101)

---

## MTA-STS (Mail Transfer Agent Strict Transport Security)

URL: https://exbk.jp/glossary/mta-sts
読み: エムティーエー エスティーエス
カテゴリ: general

### 短い定義 (TL;DR)

MTA-STS は、メール配送間のSMTP接続でTLS暗号化を強制するためのポリシー公開機構です。RFC 8461で規定され、ダウングレード攻撃から保護します。

### 詳細解説

MTA-STS は、SMTP 配送時に STARTTLS のダウングレード攻撃を防ぐための仕組みで、受信ドメインがHTTPS (https://mta-sts.example.com/.well-known/mta-sts.txt) で「mode=enforce; mx=*.example.com; max_age=604800」のようなポリシーを公開します。送信側 MTA はこのポリシーをキャッシュして遵守し、TLS 接続が確立できないMXには配送しません。DNS の _mta-sts.example.com TXT でポリシーIDも公開します。mode は testing → enforce の段階運用が推奨されます。TLS-RPT (RFC 8460) と組み合わせるとTLS失敗のレポートが得られます。Gmail・Microsoft 365・Yahoo は MTA-STS に対応しており、運用するとTLS強制でフィッシング対策にもなります。

### 実装例

- exbk.jp の mta-sts.exbk.jp に mode=enforce のポリシーを公開
- Cloudflare Pages で /.well-known/mta-sts.txt をホストして証明書を自動更新
- TLS-RPT と併用して TLS 失敗をレポート受信

### 出典

- [RFC 8461 - SMTP MTA Strict Transport Security (MTA-STS)](https://www.rfc-editor.org/rfc/rfc8461)

---

## Multi-agent

URL: https://exbk.jp/glossary/multi-agent
読み: マルチエージェント
カテゴリ: ai

### 短い定義 (TL;DR)

Multi-agent (マルチエージェント) は、複数の AI エージェントが協調・分業してタスクを解決するアーキテクチャです。役割別 (Planner / Executor / Reviewer) に分けるのが定番です。

### 詳細解説

Multi-agent は単一エージェントでは難しい複雑タスクを、専門化された複数エージェントで解決するアプローチです。代表的設計: Planner (計画立案) → Executor (実行) → Reviewer (品質確認) → Refiner (改善) の連携。CrewAI / AutoGen / LangGraph 等のフレームワークが対応。Anthropic Claude Code でも、サブエージェントを起動して独立タスクを並列処理できます。

### 実装例

- CrewAI で 'Researcher / Writer / Editor' チームを編成
- AutoGen の GroupChat で議論型解決
- Claude Code の subagent で並列タスク

---

## 多変量テスト (Multivariate Test (MVT))

URL: https://exbk.jp/glossary/multivariate-test
読み: タヘンリョウテスト
カテゴリ: general

### 短い定義 (TL;DR)

多変量テスト (MVT) は、複数の要素を同時にテストし、最適な組み合わせを発見する手法です。A/B テストよりも多くのトラフィックが必要ですが、要素間の相互作用を捉えられます。大規模サイトでの最適化に威力を発揮します。

### 詳細解説

多変量テスト (MVT) は、A/B テストの拡張版で、複数の要素 (例: ヘッドライン3種類 × ボタン色2種類 × 画像3種類 = 18パターン) を同時に検証し、最適な組み合わせを発見します。A/B テストが「1要素2パターン」なのに対し、MVT は「多要素多パターン」を扱うため、要素間の相互作用 (例: ヘッドライン A は青ボタンで CVR 高、ヘッドライン B は赤ボタンで CVR 高) を発見できる利点があります。Adobe Target、VWO、Optimizely の上位プランで実装可能です。Google が検索結果のランキング要素チューニングで MVT を多用していることが知られています。MVT のデメリットは、必要トラフィックが大幅に増えること (18パターン × 各1,000サンプル = 18,000)、解析が複雑なこと、テスト期間が長くなること、です。Booking.com 規模 (月間数億訪問) なら現実的ですが、月10万 PV 以下の中小サイトでは難しく、その場合は逐次的な A/B テストで代用します。タグチメソッドや実験計画法を応用した直交配列で、必要パターン数を削減する手法もあります。

### 実装例

- 大規模 EC が、ヘッドライン3種 × ボタン色3種 × 画像3種の27パターンで MVT し最適組合せを発見します。
- 金融 LP が、申込フォームの項目数2種 × 並び順3種 × 説明文2種を同時検証し CVR 1.5倍を実現します。
- Booking.com が宿泊LP で MVT を週次で回し、年間累積で売上数百億円のリフトを実現しています。

### 出典

- [Adobe - Multivariate Testing](https://business.adobe.com/products/target/adobe-target.html)

---

## MVP (Minimum Viable Product (実用最小限の製品))

URL: https://exbk.jp/glossary/mvp
読み: エムブイピー
カテゴリ: general

### 短い定義 (TL;DR)

MVP (Minimum Viable Product) は、検証に必要な最小限の機能だけを備えた製品です。短期間で市場の反応を確かめ、無駄な開発投資を避けるリーンスタートアップの中核概念です。Eric Ries の Lean Startup の中核思想です。

### 詳細解説

MVP は Eric Ries が2011年の著書『The Lean Startup』で広めた概念で、「学びを得るために必要最小限の機能を持つ製品」と定義されます。完成度100% の製品を1年かけて作るのではなく、コア機能だけ2-3か月で出して市場の反応を見て改善する「Build-Measure-Learn」サイクルを高速で回すのが目的です。Dropbox は2007年に実際の同期機能ではなく、3分のデモ動画 (MVP) を Hacker News で公開し、ベータ登録待機リストが7万人を超えたことで需要を確認、その後実装に進みました。Airbnb は2008年に創業者のマンションをサンフランシスコのデザイン会議参加者に貸し出すという物理的 MVP からスタートしました。MVP の種類は、(1) Concierge MVP (手動対応)、(2) Wizard of Oz MVP (人力でシミュレート)、(3) Smoke Test MVP (LP だけ作って需要測定) など多様です。MVP の目的は「売上」ではなく「学び」で、結果が悪くても学びがあれば成功という思考が重要です。

### 実装例

- Dropbox がコア機能の代わりに3分のデモ動画で需要を測定、7万人の登録予約を獲得し開発に着手します。
- BtoB SaaS が Notion の DB だけで MVP を作り、3社の有償トライアル顧客で課題仮説を検証します。
- EC ブランドが Shopify テンプレートだけで MVP ストアを立ち上げ、月100件販売を確認後フル機能開発します。

### 出典

- [Eric Ries - The Lean Startup](http://theleanstartup.com/)

---

## mysqldump

URL: https://exbk.jp/glossary/mysqldump
読み: マイエスキューエルダンプ
カテゴリ: storage

### 短い定義 (TL;DR)

mysqldump は MySQL / MariaDB の DB を SQL 形式でダンプ (バックアップ) するコマンドです。--single-transaction オプションでロックなしの一貫性あるダンプが取れます。

### 詳細解説

mysqldump (MariaDB では mariadb-dump) は MySQL/MariaDB に標準同梱の論理バックアップツールです。SQL 文 (CREATE TABLE / INSERT) として出力するため可搬性が高く、別バージョン・別 DB エンジンへの移行にも使えます。--single-transaction オプションは InnoDB テーブル限定で「ダンプ開始時点のスナップショット」を作るため、本番稼働中でもロックフリーで実行可能。Nextcloud / WordPress 等の MySQL バックアップで定番です。

### 実装例

- mysqldump --single-transaction -u root -p mydb | gzip > mydb.sql.gz
- docker exec で稼働中コンテナの DB をダンプ
- 毎日 cron で実行 → restic 経由で R2 にバックアップ

### 出典

- [MySQL mysqldump Manual](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html)

---

## n8n

URL: https://exbk.jp/glossary/n8n
読み: エヌエイトエヌ
カテゴリ: ai

### 短い定義 (TL;DR)

n8n (エヌエイトエヌ) はセルフホスト可能な OSS のワークフロー自動化ツールです。Zapier / Make の代替として、API 連携と AI 統合を Node ベースのフロー UI で構築できます。

### 詳細解説

n8n は 2019 年公開の OSS で、Sustainable Use License。400 以上のサービスとの統合 (Slack / Notion / Salesforce / OpenAI / Anthropic 等) があり、ノードを繋ぐビジュアル UI でワークフローを構築。Webhook / Cron / イベントトリガで起動可能。AI ノード (Tools Agent / RAG / OpenAI / Anthropic) も標準で、エージェント的なワークフローも作れます。Docker で 1 コマンド起動できるためセルフホスト派に人気。

### 実装例

- Webhook → AI 解析 → Slack 通知のフロー
- Cron で毎朝 KPI 集計 → メール送信
- Hostinger VPS で n8n + Claude API 連携

### 出典

- [n8n](https://n8n.io)

---

## 除外オーディエンス (Negative Audience / オーディエンスの除外)

URL: https://exbk.jp/glossary/negative-audience
読み: ジョガイオーディエンス
カテゴリ: ads

### 短い定義 (TL;DR)

除外オーディエンスは特定のユーザー群 (既存顧客・コンバージョン済ユーザー・退会者等) を広告配信対象から除外する設定です。新規顧客獲得キャンペーンで既存顧客に広告を出さないようにする運用に必須です。

### 詳細解説

除外オーディエンス (Negative Audience) は広告配信対象から特定のユーザーリストを除外する設定で、CV 済ユーザー・既存顧客・退会者・社員・採用候補者などを除外することで広告費の無駄を防ぎます。例えば『新規顧客獲得キャンペーン』では既存顧客リストを除外、『リエンゲージメントキャンペーン』では現役アクティブ顧客を除外、『退会防止キャンペーン』では新規ユーザーを除外、というように目的別にきめ細かく設定します。Meta・Google・LINE 広告ともに『除外』設定可能で、設定漏れは大きな機会損失と CPA 悪化の原因となります。

### 実装例

- 新規獲得キャンペーンで既存顧客 5 万人を除外し新規のみに配信
- 退会者リストを除外しブランド毀損を防止
- 求人広告で社員リスト (内部応募防止) を除外

### 出典

- [Google Ads ヘルプ - オーディエンスの除外](https://support.google.com/google-ads/answer/2549058)
- [Meta Business - オーディエンスの除外](https://www.facebook.com/business/help/744354708981227)

---

## 除外キーワード (Negative Keyword)

URL: https://exbk.jp/glossary/negative-keyword
読み: ジョガイキーワード
カテゴリ: ads

### 短い定義 (TL;DR)

除外キーワードは検索広告で『広告を表示したくない検索クエリ』として登録するキーワードです。無関係な検索からのクリックを防ぎ無駄な広告費を削減できる、検索広告運用の最重要メンテナンス項目です。

### 詳細解説

除外キーワード (Negative Keyword) は Google Ads・Yahoo!広告などの検索広告で、特定の検索クエリに対する広告表示を抑制するために登録するキーワードです。『無料』『中古』『口コミ』『2ch』『退会』などの非購買意向ワード、自社サービスに合わないクエリ (例: 弁護士事務所が『無料相談 漫画』を除外)、ブランドコンフリクト (代理店が競合社名を除外) などが代表例です。完全一致・フレーズ一致・部分一致の 3 マッチタイプがあり、検索クエリレポートで毎週新たな除外を追加するメンテナンスが運用 PDCA の中心となります。

### 実装例

- 弁護士事務所が『無料 漫画 まとめ』を除外し無関係流入を遮断
- EC サイトが『中古』『リサイクル』を除外し新品検索に集中
- 毎週検索クエリレポートを確認し新規除外を 10〜30 個追加

### 出典

- [Google Ads ヘルプ - 除外キーワード](https://support.google.com/google-ads/answer/2453972)
- [Google Ads ヘルプ - 除外キーワードのマッチタイプ](https://support.google.com/google-ads/answer/3454108)

---

## Nextcloud

URL: https://exbk.jp/glossary/nextcloud
読み: ネクストクラウド
カテゴリ: infra

### 短い定義 (TL;DR)

Nextcloud (ネクストクラウド) は、Dropbox や Google Drive のようなファイル同期 + 共有機能を、自社サーバーで運用できる OSS のセルフホスト型クラウドストレージです。Linux + Docker 上に構築でき、ベンダーロックなく独自ドメインで運用できます。

### 詳細解説

Nextcloud は ownCloud からフォークされた OSS で、ファイル同期・カレンダー・連絡先・チャット・オンラインオフィス機能を備えます。Web UI、デスクトップクライアント (mirall)、iOS/Android アプリから同一データへアクセスでき、組織の情報基盤として Dropbox/OneDrive の代替を狙えます。AGPLv3 ライセンスの完全 OSS で、ストレージ容量は契約 VPS のディスク容量次第。月数百円の VPS で数百 GB のクラウドストレージ + 共有機能が手に入るため、5 名以上のチームでは Dropbox Business よりも 6〜12 倍経済的になるケースが多いです。

### 実装例

- docker compose で 5 分でセルフホスト構築
- mirall クライアントで Mac/Windows と双方向同期
- 外部共有リンクで顧客への大容量ファイル受け渡し

### 出典

- [Nextcloud Official](https://nextcloud.com)

---

## Next.js

URL: https://exbk.jp/glossary/nextjs
読み: ネクストジェイエス
カテゴリ: web

### 短い定義 (TL;DR)

Next.js (ネクストジェイエス) は React ベースのフルスタック Web フレームワークで、Vercel が開発しています。SSR / SSG / ISR に標準対応し、現代的な Web サイト構築のデファクトスタンダードです。

### 詳細解説

Next.js は 2016 年に Vercel (旧 Zeit) がリリースした React フレームワークで、ファイルシステムベースのルーティング、Image / Font / Script の最適化、Server Components による高度なパフォーマンス最適化を提供します。Next.js 13 以降は App Router と RSC (React Server Components) が標準で、レンダリング戦略を細かく制御できます。EXBANK ブログ自体も Next.js 16 + MDX で構築されています。Turbopack (新 bundler) との統合が進む一方、日本語パスでパニックする等の安定性課題もあり、本番では --webpack 指定が安全です。

### 実装例

- EXBANK ブログ = Next.js 16 + MDX + Vercel
- App Router で /insights/[slug] のような動的ルーティング
- ISR で記事更新を 1 時間ラグで反映

### 出典

- [Next.js Documentation](https://nextjs.org/docs)

---

## ニッチダウン

URL: https://exbk.jp/glossary/niche-down
読み: ニッチダウン
カテゴリ: general

### 短い定義 (TL;DR)

ニッチダウン (Niche Down) は、ターゲット市場をあえて狭く絞り込み、特定セグメントで圧倒的な存在になる戦略です。リソースの少ないスタートアップや個人事業に有効です。リソースの限られたスタートアップで特に有効な戦略です。

### 詳細解説

ニッチダウンは、Seth Godin の『Purple Cow』(2003) や Peter Thiel の『Zero to One』(2014) で提唱された、小さな市場で圧倒的1位を取る戦略思考です。「全員に好かれよう」とすると埋もれるため、「100人中3人に熱狂的に支持される」ことを優先します。具体的には、業界 → 業種 → 職種 → 地域 → 規模 → 課題 のように軸を重ねて絞り込みます。例として、Patio11 こと Patrick McKenzie が運営した Bingo Card Creator は「米国の小学校教師がパーティ用ビンゴカードを印刷したい」というニッチに絞り、年間5万ドル以上を一人で稼いだ事例が有名です。日本でも、ニッチダウンに成功した例として「猫専門ECのねこじゃすてぃす」「左利き専用文房具の菊屋浦上商事」などがあります。ニッチダウンの目安は「狙う市場で月商100万円以上が見込めるか」「5年後に飽和しないか」の2点で評価します。

### 実装例

- ヨガインストラクターが「30代産後ママ専用・骨盤ケア」とニッチダウンし、月商300万円を達成します。
- Web 制作会社が「歯科医院専用・予約導線特化型」と絞り込み、案件単価を3倍にします。
- EC が「左利き用ハサミ・文具」に特化し、Amazon 検索結果1位を独占して認知コストを劇的に下げます。

### 出典

- [Seth Godin - Purple Cow](https://seths.blog/purple-cow/)

---

## ニールセンの 10 ユーザビリティ原則 (Nielsen's 10 Usability Heuristics)

URL: https://exbk.jp/glossary/nielsens-10
読み: ニールセンのじゅうげんそく
カテゴリ: general

### 短い定義 (TL;DR)

ニールセンの10ユーザビリティ原則は、Jakob Nielsen が1994年に発表した UI 評価のためのヒューリスティック10項目で、ヒューリスティック評価の標準となっています。

### 詳細解説

ニールセンの 10 ユーザビリティ原則 (10 Usability Heuristics) は、Jakob Nielsen が1994年に整理した UI 設計・評価のための10原則で、現在も世界標準のヒューリスティック評価フレームとして使われます。10項目は (1) システム状態の可視性 (2) 実世界とシステムの一致 (3) ユーザーコントロールと自由 (元に戻せる) (4) 一貫性と標準 (5) エラー予防 (6) 想起より認識 (7) 柔軟性と効率性 (8) 美的でミニマルなデザイン (9) エラー認識・診断・回復の支援 (10) ヘルプとドキュメント、です。専門家2〜5名で各原則に照らして評価しスコア付けすることで、ユーザーテストを実施する前に主要問題の多くを発見できます。本格テストの前段スクリーニングとして費用対効果が高く、企業デザインシステムやデザインレビューの基礎言語にもなっています。

### 実装例

- システム状態の可視性: ローディングインジケータと進捗バー
- エラー予防: 削除前の確認ダイアログと取り消し機能
- 一貫性: 全画面で「保存」ボタンの位置・色を統一

### 出典

- [NN/g - 10 Usability Heuristics for User Interface Design](https://www.nngroup.com/articles/ten-usability-heuristics/)

---

## node_modules

URL: https://exbk.jp/glossary/node-modules
読み: ノードモジュールズ
カテゴリ: web

### 短い定義 (TL;DR)

node_modules は npm / pnpm / yarn が依存パッケージをインストールするフォルダです。Next.js プロジェクトで 10 万ファイル超になることも珍しくなく、クラウド同期から必ず除外すべき対象です。

### 詳細解説

node_modules は package.json の dependencies / devDependencies に基づいて npm install が展開するフォルダで、推移的依存も全て含むため数万〜数十万ファイルに膨れ上がります。Next.js プロジェクトでは平均 10 万ファイル超、3 GB を超えるケースもあります。Dropbox / Nextcloud / OneDrive 等のクラウド同期に含めると同期が破綻するため、必ず除外パターンに含めること。git でも .gitignore に標準で含まれています。

### 実装例

- Next.js 16 プロジェクト → node_modules 約 11 万ファイル
- クラウド同期の除外パターンに必ず追加
- 削除後は npm install / pnpm install で再生成

---

## nofollow

URL: https://exbk.jp/glossary/nofollow
読み: ノーフォロー
カテゴリ: seo

### 短い定義 (TL;DR)

nofollow は、リンクに付与する rel 属性で、検索エンジンに「このリンクの評価を引き継がないでください」と伝える指定です。広告・有料リンク・UGC リンクで使用が推奨されます。

### 詳細解説

nofollow は2005年に Google・Yahoo・MSN が共同導入したリンク属性で、<a href="..." rel="nofollow"> と記述すると検索エンジンに「このリンクは評価対象外」と通知できます。本来は有料リンクスパム対策として導入され、2019年9月に Google は nofollow を「ヒント」に格下げし、用途別の細分化として rel="sponsored" (広告)、rel="ugc" (ユーザー投稿リンク)、rel="nofollow" (汎用) の3種類を推奨しました。重要な変化として、2020年3月以降 Google は nofollow リンクも「クロールおよびインデックスのヒント」として参照するようになり、完全無視ではなくなっています。SEO 実務では、a) 広告には sponsored、b) コメント欄/フォーラムには ugc、c) 信頼性が低い外部リンクには nofollow、を適切に使い分けます。

### 実装例

- アフィリエイトリンクには rel="sponsored" を付与しガイドライン違反を回避します
- ユーザー投稿のコメント欄リンクは rel="ugc" で自動付与する CMS 設定が標準です
- nofollow でも2020年以降はランキングシグナルとして部分的に評価されます

### 出典

- [Google Search Central - 修飾済みリンクで Google にリンク関係を伝える](https://developers.google.com/search/docs/essentials/spam-policies#qualify-outbound-links)

---

## NPS (Net Promoter Score (推奨者比率))

URL: https://exbk.jp/glossary/nps
読み: エヌピーエス
カテゴリ: general

### 短い定義 (TL;DR)

NPS (Net Promoter Score) は、顧客に「友人に推奨したいか」を0-10で尋ね、推奨者比率から批判者比率を引いた指標です。Fred Reichheld が2003年に提唱しました。

### 詳細解説

NPS は2003年に Bain & Company の Fred Reichheld が Harvard Business Review で発表した顧客ロイヤリティ指標です。「この商品/サービスを友人や同僚に推奨したいか」を0-10で尋ね、9-10を推奨者 (Promoter)、7-8を中立者 (Passive)、0-6を批判者 (Detractor) に分類します。NPS = 推奨者% - 批判者% で-100 から+100 の範囲を取ります。業界平均は SaaS で約30、消費財で約20-40、銀行や航空会社では低めの傾向があります。Apple の NPS は約70、Tesla は約95 という驚異的な値を出しており、ロイヤリティの強さを示しています。NPS の強みは1問で測れる手軽さと、業界横断で比較できる標準性にある一方、批判として「文脈情報が乏しい」「文化差で5-10の解釈が違う」などもあります。実務では、NPS と「なぜその点数か」の自由記述を組み合わせ、改善優先順位を立てるのが定番運用です。

### 実装例

- SaaS が四半期 NPS 調査で推奨者45%・批判者15% を測定し、NPS 30 と業界平均並みと評価します。
- EC ブランドが、購入後14日目に NPS 自動メールを送り、批判者には CS が直接連絡してリカバリー対応します。
- 美容クリニックが、NPS 60 を維持目標に、月次でアンケート結果を全スタッフに共有しサービス改善します。

### 出典

- [Bain & Company - Net Promoter System](https://www.netpromotersystem.com/)

---

## OAuth (Open Authorization)

URL: https://exbk.jp/glossary/oauth
読み: オーオース
カテゴリ: general

### 短い定義 (TL;DR)

OAuth は、ユーザーのパスワードを渡さず第三者アプリにリソースアクセス権を委譲するための認可プロトコルです。OAuth 1.0 (RFC 5849) と現行の OAuth 2.0 があります。

### 詳細解説

OAuth は、Twitter API 黎明期に生まれた「認可委譲」の標準プロトコルで、ユーザーのパスワードを直接サードパーティに渡すことなく、限定権限のアクセストークンで API 利用を許可する仕組みを定めます。OAuth 1.0 (RFC 5849) は HMAC-SHA1 署名で複雑、OAuth 2.0 (RFC 6749) はトークンベースでシンプル化され主流になりました。OAuth は厳密には「認可 (Authorization)」プロトコルであり、「認証 (Authentication)」には OpenID Connect が上位レイヤーで使われます。役割は Resource Owner (利用者) / Client (アプリ) / Authorization Server (認可サーバー) / Resource Server (API) の4者で、scope によって権限の粒度を制御します。Twitter / GitHub / Google / Facebook の「○○でログイン」の裏側で利用されています。

### 実装例

- X (Twitter) API v2 は OAuth 2.0 PKCE フローが推奨
- GitHub Apps は OAuth 2.0 で repo スコープのトークンを発行
- OAuth 1.0a は HMAC-SHA1 署名で nonce + timestamp が必要

### 出典

- [RFC 6749 - The OAuth 2.0 Authorization Framework](https://www.rfc-editor.org/rfc/rfc6749)

---

## OAuth 2.0 (OAuth 2.0 Authorization Framework)

URL: https://exbk.jp/glossary/oauth2
読み: オーオースツーポイントゼロ
カテゴリ: general

### 短い定義 (TL;DR)

OAuth 2.0 は、複数のグラントタイプ (認可コード・PKCE・クライアントクレデンシャル等) を持つ認可フレームワークで、RFC 6749 と関連 RFC で構成されます。

### 詳細解説

OAuth 2.0 は RFC 6749 で定義された認可フレームワークで、用途別に4つのコアグラントタイプ (Authorization Code / Implicit / Resource Owner Password Credentials / Client Credentials) を提供します。現代では Implicit と ROPC は非推奨で、Webアプリ・モバイル・SPA は Authorization Code + PKCE (RFC 7636) が必須化されています。サーバー間連携は Client Credentials が標準です。トークン形式は JWT またはオパーク文字列で、有効期限と refresh_token によるサイレント更新を組み合わせます。OAuth 2.1 (ドラフト) では PKCE 必須・Implicit 削除・ROPC 削除など、現代のベストプラクティスを統合した整理版が進行中です。Token Introspection (RFC 7662) や Token Revocation (RFC 7009) もエコシステムを構成します。

### 実装例

- SPA は Authorization Code + PKCE で client_secret を露出しない
- サーバー間 API 連携は Client Credentials Grant
- Refresh Token Rotation で漏洩トークンを即無効化

### 出典

- [RFC 6749 - OAuth 2.0](https://www.rfc-editor.org/rfc/rfc6749)
- [RFC 7636 - PKCE](https://www.rfc-editor.org/rfc/rfc7636)

---

## oc_file_locks

URL: https://exbk.jp/glossary/oc-file-locks
読み: オーシーファイルロックス
カテゴリ: infra

### 短い定義 (TL;DR)

oc_file_locks は Nextcloud がデフォルトで使用する DB ベースのロック管理テーブルです。同期時のファイル単位排他制御を保存し、肥大化すると同期が止まります。

### 詳細解説

oc_file_locks は MariaDB / PostgreSQL 上の Nextcloud 内部テーブルで、各同期セッションがファイル単位でロックを取得・解放するたびに INSERT/DELETE が走ります。memcache.locking が未設定 (DB ロック使用時) のみ使われ、Redis ロックに切り替えれば書き込まれなくなります。負荷集中時にロック数が数十万件に膨れ上がり、新規同期が永久ブロックされる事故が発生することがあります。緊急復旧は TRUNCATE で空に + メンテナンスモード使用が定番。恒久対策は Redis 化が必須です。

### 実装例

- TRUNCATE TABLE oc_file_locks で緊急ロック解放 (要メンテナンスモード)
- SELECT COUNT(*) で監視 (500 件超で異常)
- Redis 化後は不要、空のまま放置で OK

### 出典

- [Nextcloud Transactional File Locking](https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/files_locking_transactional.html)

---

## occ

URL: https://exbk.jp/glossary/occ
読み: オーシーシー
カテゴリ: infra

### 短い定義 (TL;DR)

occ (Owncloud Console) は Nextcloud の管理用 CLI ツールです。Web UI で操作できないサーバー側の設定変更・メンテナンス・トラブルシューティングに必須です。

### 詳細解説

occ は /var/www/html/occ にある PHP スクリプトで、Nextcloud の管理者権限相当の操作を CLI から実行できます。docker exec --user www-data nextcloud-app php occ <command> の形で呼び出すのが定形。代表的なコマンド: maintenance:mode (メンテナンス ON/OFF)、files:scan (DB とファイル整合性確認)、user:list (ユーザー一覧)、config:system:set (設定変更)、trashbin:cleanup (ゴミ箱空にする)。Web UI からの操作で詰まった時の最終解決手段です。

### 実装例

- occ maintenance:mode --on (メンテナンス ON)
- occ trashbin:cleanup admin (ゴミ箱を空に)
- occ files:scan --all (ファイル整合性チェック)

### 出典

- [Nextcloud occ Command Reference](https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/occ_command.html)

---

## オフサイトバックアップ

URL: https://exbk.jp/glossary/offsite-backup
読み: オフサイトバックアップ
カテゴリ: storage

### 短い定義 (TL;DR)

オフサイトバックアップは、本番サーバーと物理的に離れた場所にバックアップを保管する運用です。同一データセンターの障害・自然災害・ランサムウェア攻撃などからデータを守ります。

### 詳細解説

3-2-1 ルール (3 コピー / 2 メディア / 1 オフサイト) がバックアップ業界の鉄則です。本番サーバーと同じ物理ホスト・同じデータセンター・同じクラウドリージョンに置いたバックアップは、同時に破壊されるリスクがあります。オフサイトバックアップは別リージョン・別クラウド・物理的に離れた地域に置くことで、災害復旧の最後の砦になります。Cloudflare R2 はグローバルに分散しているため、オフサイト先として優秀です。

### 実装例

- 本番 VPS (東京) → R2 (Asia Pacific 自動分散)
- 週次で別クラウド (B2) にもクロスバックアップ
- 重要データはオフライン HDD にも 1 部複製

---

## OGP タグ (Open Graph Protocol)

URL: https://exbk.jp/glossary/og-tag
読み: オージーピータグ
カテゴリ: seo

### 短い定義 (TL;DR)

OGP (Open Graph Protocol) タグは、Facebook が2010年に策定した、Web ページを SNS でシェアした際のサムネイル・タイトル・説明文を制御する meta タグの規格です。Twitter・LINE・Slack 等も対応しています。

### 詳細解説

Open Graph Protocol (OGP) は Facebook が2010年に発表した meta タグ仕様で、HTML head 内に <meta property="og:..." content="..."> 形式で記述すると SNS シェア時の表示を制御できます。必須プロパティは og:title (タイトル)、og:type (article/website 等)、og:image (サムネイル画像 URL、1200×630px 推奨)、og:url (正規 URL)、です。推奨プロパティは og:description (説明文200字以内)、og:site_name、og:locale (ja_JP) です。Twitter 用には twitter:card で大画像表示を別途指定できますが、未指定時は OGP 値が継承されます。SEO への直接効果はないものの、a) SNS 経由の流入と被リンク獲得、b) ブランド認知向上、c) Slack/Discord での記事プレビュー、に必須です。実装ミスで多いのは、og:image が絶対 URL でない、画像が1200×630以外で切れる、og:type が誤り、です。

### 実装例

- og:image を1200×630px で実装すると Twitter/Facebook で大画像表示されます
- OGP 未実装記事は SNS シェア時にプレビューが出ず CTR が60%低下します
- Facebook Sharing Debugger でキャッシュクリアと検証ができます

### 出典

- [The Open Graph protocol](https://ogp.me/)
- [Facebook for Developers - Sharing](https://developers.facebook.com/docs/sharing/webmasters/)

---

## OJT (On the Job Training (実務研修))

URL: https://exbk.jp/glossary/ojt
読み: オージェーティー
カテゴリ: general

### 短い定義 (TL;DR)

OJT (On the Job Training) は、実際の業務を通じて指導者と一緒に仕事をしながら学ぶ訓練手法です。座学 (Off-JT) より実践力が身につきやすく、日本企業で広く採用されています。

### 詳細解説

OJT は1940年代に米国の Training Within Industry (TWI) プログラムから普及した実務研修手法で、第二次大戦中に短期間で軍需工場の作業員を訓練するために開発されました。指導者 (トレーナー) が新人と一緒に実務に従事し、(1) 説明 (やって見せる)、(2) 実演 (やらせてみる)、(3) フィードバック、(4) 自立、の4ステップで業務スキルを移転します。日本企業の人材開発の中心的手法で、トヨタ生産方式の「カイゼン」現場、ホテル業界のオペレーション習得、営業職の同行訓練などで広く使われています。OJT のメリットは、(1) 実務に直結したスキル習得、(2) コストが低い、(3) 現場の雰囲気と暗黙知の伝承、です。デメリットとして、(1) トレーナーの質に左右される、(2) 体系的知識の不足、(3) 業務優先で訓練が後回しになる、があり、Off-JT (集合研修) と組み合わせる「ブレンド型」が現代の主流です。マーケティング部門でも、新人広告運用者を SaaS 管理画面で実案件と並走させて育てる OJT が標準化しています。

### 実装例

- 営業新人が先輩同行で月20件の商談を経験、6か月で独り立ちできるレベルに到達します。
- 広告運用代理店で、新人が小規模アカウント担当として OJT を受け、半年で月100万円予算を任せられます。
- コールセンターで、ロールプレイ → 実通話モニタリング → 自走の3段階 OJT で立ち上がりを早めます。

### 出典

- [Training Within Industry (TWI) - History](https://www.twi-institute.com/)

---

## OneDrive

URL: https://exbk.jp/glossary/onedrive
読み: ワンドライブ
カテゴリ: saas

### 短い定義 (TL;DR)

OneDrive は Microsoft が提供するクラウドストレージサービスで、Microsoft 365 のサブスクリプションに含まれます。Word / Excel / PowerPoint との連携が強みで、企業利用が多いです。

### 詳細解説

OneDrive は Microsoft 365 Business Basic (1 ユーザー月 750 円・1TB) や Microsoft 365 Personal (月 1,490 円・1TB) に含まれ、Office アプリとの統合が密接です。Office ファイルの共同編集、SharePoint との連携、Active Directory / Microsoft Entra ID 連携、Microsoft Defender for Cloud Apps などのセキュリティ機能が充実。一方で Mac / Linux のサポートは Windows に比べると弱く、Linux 公式クライアントは存在しないため Linux ユーザーは rclone 経由になります。

### 実装例

- Microsoft 365 Business Standard 月 1,560 円/ユーザー (Office + 1TB)
- Word / Excel のリアルタイム共同編集
- rclone で OneDrive ↔ Nextcloud 移行可能

### 出典

- [Microsoft 365 プラン比較](https://www.microsoft.com/ja-jp/microsoft-365/business/compare-all-plans)

---

## OpenAI

URL: https://exbk.jp/glossary/openai
読み: オープンエーアイ
カテゴリ: ai

### 短い定義 (TL;DR)

OpenAI (オープンエーアイ) は 2015 年創業の AI 研究企業で、ChatGPT / GPT-4 / DALL-E / Sora などを開発しています。AI ブームの中心的な存在で、Microsoft が大株主です。

### 詳細解説

OpenAI は Sam Altman (CEO)、Elon Musk (元) らが 2015 年に非営利として創業し、後に営利子会社 (OpenAI LP) を設立。ChatGPT を 2022 年に公開して世界的ブームを起こし、評価額は 2026 年時点で約 500B ドル。GPT 系言語モデル、画像生成 DALL-E、動画生成 Sora、音声認識 Whisper など幅広い AI を開発。Anthropic / Google DeepMind と並ぶ三大 AI 研究機関の 1 つです。

### 実装例

- ChatGPT / GPT-5 / o3 系モデルを提供
- OpenAI API で開発者向け B2B 事業
- Sora で動画生成サービス

### 出典

- [OpenAI](https://openai.com)

---

## OpenID Connect (OIDC)

URL: https://exbk.jp/glossary/openid-connect
読み: オープンアイディーコネクト
カテゴリ: general

### 短い定義 (TL;DR)

OpenID Connect (OIDC) は、OAuth 2.0 を拡張してユーザー認証情報を ID Token (JWT) で標準化した認証プロトコルです。「Googleでログイン」等で利用されます。

### 詳細解説

OpenID Connect (OIDC) は、OAuth 2.0 が「認可」のみを扱うのに対し、「認証」と「ユーザープロフィール取得」を統一したプロトコルとして OpenID Foundation が標準化したものです。Authorization Code / Implicit / Hybrid フローで scope に openid を含めると、アクセストークンに加えて ID Token (署名付き JWT) が発行され、iss / sub / aud / exp / iat / nonce などのクレームでユーザー識別と認証イベントを伝達します。/.well-known/openid-configuration というディスカバリエンドポイントで、エンドポイントURL・対応スコープ・JWKsの公開鍵URI 等が自動取得できるのが特徴です。Google・Microsoft Entra ID・Okta・Auth0 が代表的なIdPで、SAML より軽量で SPA 親和性が高く、SSO実装の現代的な標準になっています。

### 実装例

- Google OAuth は openid email profile の3スコープが基本
- /.well-known/openid-configuration で JWKs を自動取得
- ID Token の nonce でリプレイ攻撃を防止

### 出典

- [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html)

---

## アウトバウンドマーケティング

URL: https://exbk.jp/glossary/outbound-marketing
読み: アウトバウンドマーケティング
カテゴリ: general

### 短い定義 (TL;DR)

アウトバウンドマーケティング (Outbound Marketing) は、企業から顧客へ能動的に情報を届ける手法です。テレマ、DM、屋外広告、コールドメールなど従来型の販促全般を指します。BtoB エンタープライズ営業で再評価されています。

### 詳細解説

アウトバウンドマーケティングは、企業が能動的に顧客にアプローチする手法で、テレビ CM、新聞広告、屋外看板、テレアポ、コールドメール、DM が代表的です。インバウンドの台頭で「古い」と見られる時期もありましたが、2020年代以降、Outbound の有効性が再評価されています。Sales Hacker の調査では、SaaS 業界の新規受注の約30% は依然として Outbound 経由で、特にエンタープライズ案件 (年間契約1,000万円以上) では Outbound のほうが ROI が高い傾向があります。現代の Outbound はコールドメールツール (Apollo、Outreach、Sales Bricks) や AI による自動パーソナライズで進化しており、「Cold to Warm」アプローチが主流です。テレビ CM はデジタル広告と比べ高単価ですが、ブランド認知の指数関数的な拡大に有効で、ライザップやマクドナルドが活用しています。Outbound と Inbound はトレードオフではなく、目的別に併用するのが現代マーケの主流です。

### 実装例

- BtoB SaaS が、ターゲット企業1,000社にリスト作成しコールドメール3通を Outreach で配信、商談率3% を達成します。
- EC ブランドが、テレビ CM で認知拡大しつつ、検索広告で刈り取りという Inbound/Outbound 併用戦略を取ります。
- コンサル会社が、業界カンファレンスで名刺交換した相手にハガキを送る Outbound DM を月100通実施します。

### 出典

- [Sales Hacker - Outbound Sales Strategy](https://www.saleshacker.com/outbound-sales/)

---

## OWASP Top 10 (Open Web Application Security Project Top 10)

URL: https://exbk.jp/glossary/owasp-top10
読み: オワスプトップテン
カテゴリ: general

### 短い定義 (TL;DR)

OWASP Top 10 は、Webアプリケーションの最重要セキュリティリスクを4年ごとに集計するOWASPの代表的ドキュメントで、業界標準のチェックリストとして利用されます。

### 詳細解説

OWASP Top 10 は、非営利団体 OWASP (Open Web Application Security Project) が世界中の脆弱性データを集計して4年ごとに発表する、Webアプリで最も重大な10カテゴリのリスクリストです。最新の2021年版では A01:Broken Access Control / A02:Cryptographic Failures / A03:Injection / A04:Insecure Design / A05:Security Misconfiguration / A06:Vulnerable Components / A07:Authentication Failures / A08:Software and Data Integrity Failures / A09:Logging Failures / A10:SSRF が並び、PCI DSS 等の各種コンプライアンスでも引用される事実上の業界標準です。OWASP API Security Top 10 や OWASP Mobile Top 10 等の派生もあります。各項目には豊富な対策チートシートが付属し、開発者教育の教材としても定番です。

### 実装例

- A01: Broken Access Control が4回連続で1位
- A03: Injection に SQLi/XSS/コマンドインジェクションを統合
- PCI DSS の必須要件として OWASP Top 10 をカバー

### 出典

- [OWASP Top 10 - 2021](https://owasp.org/www-project-top-ten/)

---

## Performance Max (P-MAX) (P-MAX: Performance Max Campaign)

URL: https://exbk.jp/glossary/p-max
読み: パフォーマンスマックス
カテゴリ: ads

### 短い定義 (TL;DR)

Performance Max は Google Ads の AI 最適化キャンペーン形式で、検索・ディスプレイ・YouTube・Gmail・Discover・マップに 1 つのキャンペーンから自動配信します。アセットを入稿するだけで AI が組み合わせを最適化します。

### 詳細解説

Performance Max (P-MAX) は 2021 年に Google Ads が導入した AI 最適化型キャンペーンで、Google の全配信面 (検索、YouTube、ディスプレイ、Discover、Gmail、マップ、ショッピング) に 1 つのキャンペーンから自動配信します。広告主は『アセット (画像・動画・見出し・説明文・ロゴ)』『オーディエンスシグナル』『コンバージョン目標』を入稿し、Google AI が機械学習で最適な配信面・組み合わせ・入札を決定します。透明性の低さが課題でしたが、2023 年以降はキャンペーンインサイト・検索カテゴリレポート・アセットグループ単位の詳細レポートが追加され改善されています。

### 実装例

- EC サイトで P-MAX 1 本に予算を集約し ROAS 600% を達成
- アセットグループを商品カテゴリ別に分けて配信を分離する
- オーディエンスシグナルに既存顧客リストを投入し学習を加速

### 出典

- [Google Ads ヘルプ - Performance Max](https://support.google.com/google-ads/answer/10724817)
- [Google 広告 - Performance Max](https://ads.google.com/intl/ja_jp/home/campaigns/performance-max/)

---

## PageRank

URL: https://exbk.jp/glossary/pagerank
読み: ページランク
カテゴリ: seo

### 短い定義 (TL;DR)

PageRank は、Google 創業者 Larry Page と Sergey Brin が1998年に Stanford 大学で考案したリンク解析アルゴリズムです。Web ページの重要度を被リンクの量と質から再帰的に計算します。

### 詳細解説

PageRank は1998年の論文「The Anatomy of a Large-Scale Hypertextual Web Search Engine」で発表されたアルゴリズムで、Google の検索エンジンの根幹技術として20年以上利用されています。数式は PR(A) = (1-d) + d × Σ(PR(Ti)/C(Ti)) で、d は減衰係数 (通常0.85)、Ti はページ A にリンクするページ群、C(Ti) は Ti の発リンク数です。直感的には「権威あるページから少数のページにリンクされていれば自分も権威あるページ」という再帰計算です。Google は2016年にツールバー PageRank の公開を停止しましたが、内部アルゴリズムでは現在も改良版が稼働しています。Ahrefs の DR (Domain Rating)、Moz の DA (Domain Authority)、Majestic の Trust Flow などはサードパーティ版 PageRank として広く参照されます。

### 実装例

- PageRank の高いトップページから新規記事へ内部リンクを張ると順位が早期上昇します
- Ahrefs DR70 のサイトの PageRank 推定値は通常 DR40 サイトの100倍以上です
- リンク階層を3クリック以内に保つと PageRank の伝播効率が最大化します

### 出典

- [Stanford - The PageRank Citation Ranking](http://ilpubs.stanford.edu:8090/422/)

---

## セッションあたりの PV (Pages / Session)

URL: https://exbk.jp/glossary/pages-per-session
読み: セッションアタリノピーブイ
カテゴリ: analytics

### 短い定義 (TL;DR)

セッションあたりの PV (Pages / Session) は 1 セッション中に閲覧された平均ページ数を表す指標です。GA4 では「セッションあたりのビュー数」と表示され、サイト内回遊の指標として使われます。

### 詳細解説

セッションあたりの PV (Pages per Session、Pages / Session) は 1 セッション中にユーザーが閲覧した平均ページ数を表す指標で、サイト内回遊の活発さを測る代表的な KPI です。計算式は「総 PV ÷ 総セッション数」で、UA では「ページ/セッション」、GA4 では「セッションあたりのビュー数 (Views per session)」と呼ばれます。一般的なベンチマークは EC で 4〜6 ページ、ニュースメディアで 3〜5 ページ、BtoB サイトで 2〜4 ページ、ランディングページ単独で 1〜1.5 ページ程度です。値が低い場合は (1) 内部リンク不足、(2) 関連記事の表示不足、(3) サイトナビゲーション不備、(4) コンテンツの満足度不足、などが疑われます。値を上げる施策としては関連記事ウィジェット・パンくずリスト・カテゴリページ強化・記事内 CTA の最適化などが効果的で、SEO の観点でも回遊性向上はランキングに間接的に好影響を与えるとされています。

### 実装例

- EC サイトでセッションあたり PV を 4.5 から 6.0 へ上げる回遊改善を行う
- 関連記事ウィジェットを設置しブログのページ/セッションを 1.8 → 2.5 に伸ばす
- Looker Studio で流入チャネル別のページ/セッションを比較する

### 出典

- [[GA4] イベント レポート](https://support.google.com/analytics/answer/9216061)

---

## PageSpeed Insights

URL: https://exbk.jp/glossary/pagespeed-insights
読み: ページスピードインサイト
カテゴリ: seo

### 短い定義 (TL;DR)

PageSpeed Insights (PSI) は、Google が提供する無料のページ速度測定ツールです。URL を入力するだけで Core Web Vitals のスコアと改善提案を取得でき、モバイル/デスクトップ別に評価されます。

### 詳細解説

PageSpeed Insights は pagespeed.web.dev で公開されている Google 公式の Web パフォーマンス計測ツールで、Lighthouse エンジンを内部で使用しています。URL を入力すると、1) フィールドデータ (CrUX の実ユーザー28日分の中央値)、2) ラボデータ (Lighthouse のシミュレーション結果)、3) Core Web Vitals 評価 (合格/不合格)、4) 改善提案 (画像最適化・レンダリングブロック削減など)、が表示されます。スコアは0-100で90以上が「良好」、50-89が「改善が必要」、49以下が「不良」です。CI/CD に組み込む場合は Lighthouse CI を使うか、PageSpeed Insights API (1日25000リクエストまで無料) を呼び出します。

### 実装例

- PSI スコア90以上のサイトは検索順位が安定する傾向があります
- Lighthouse CI で PR 毎に PSI スコアを自動チェックする運用が推奨されます
- モバイルスコアはデスクトップより20-30ポイント低くなるのが一般的です

### 出典

- [PageSpeed Insights](https://pagespeed.web.dev/)
- [Google Developers - About PageSpeed Insights](https://developers.google.com/speed/docs/insights/v5/about)

---

## パレートの法則 (Pareto Principle / 80-20 Rule)

URL: https://exbk.jp/glossary/paretos-law
読み: パレートのほうそく
カテゴリ: general

### 短い定義 (TL;DR)

パレートの法則 (80-20 ルール) は「結果の 80% は原因の 20% から生じる」という経験則で、UX では主要機能や上位ページに最適化資源を集中する判断に使われます。

### 詳細解説

パレートの法則 (Pareto Principle) は経済学者 Vilfredo Pareto が観察した「結果の 80% は原因の 20% から生じる」という経験則で、20世紀後半に経営学・品質管理・UX 等に拡張応用されています。UX では「全機能の 20% が 80% の利用に占められる」「ECの売上の 80% は商品20%が生む」「カスタマーサポート問い合わせの 80% は FAQ 20% が解消する」などの現象に対応し、(1) コア導線・主要画面に最適化リソースを集中 (2) ロングテール機能はサブメニュー・隠し機能化 (3) 分析時はクリックランキング上位を優先 (4) A/Bテストの仮説立案で「最大インパクトの20%」を見抜く判断軸 として活用されます。Hick の法則と組み合わせ「上位20%以外を見せない」UI設計に発展します。あくまで指針であり、機械的に切り捨てるとロングテール顧客を失う点に注意が必要です。

### 実装例

- ヒートマップ上位20% リンクを Hero に昇格
- EC で売上 80% を占める20% 商品をトップに固定
- FAQ 上位20% の質問を Above the Fold に配置

### 出典

- [Laws of UX - Pareto Principle](https://lawsofux.com/pareto-principle/)

---

## パスワードハッシュ (Password Hashing)

URL: https://exbk.jp/glossary/password-hashing
読み: パスワードハッシュ
カテゴリ: general

### 短い定義 (TL;DR)

パスワードハッシュは、平文パスワードを不可逆関数で変換し保管する技術で、Argon2id・bcrypt・scrypt が推奨されます。SHA-256 等の一般ハッシュ単体は不適切です。

### 詳細解説

パスワードハッシュは、ユーザーの平文パスワードを「鍵伸長 (Key Stretching)」可能な専用ハッシュ関数で変換し保管する技術で、データベース漏洩時にもパスワード復元を困難にします。OWASP の推奨アルゴリズムは Argon2id (第一推奨) > scrypt > bcrypt > PBKDF2 で、いずれも反復回数やメモリコストを調整できます。SHA-256 / MD5 単体は GPU で毎秒数十億回計算できるため絶対に不適切です。必須要素は (1) ユーザー固有のソルト (16〜32バイトランダム) (2) 鍵伸長によるコスト調整 (3) コスト値をハッシュ列にエンコード保管 (4) ログイン時にコスト不足ハッシュを自動リハッシュ更新 です。pepper (サーバー側の追加秘密) を併用するとDB単独漏洩時にさらに堅牢になります。Have I Been Pwned API でリーク済みパスワードの登録を防ぐのも現代的な実践です。

### 実装例

- Argon2id m=19456 t=2 p=1 で新規ユーザーをハッシュ
- ログイン成功時に bcrypt コスト不足を検出して再ハッシュ
- HIBP API で k-anonymity 経由でリーク照合

### 出典

- [OWASP - Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html)

---

## 経路データ探索 (Path Exploration)

URL: https://exbk.jp/glossary/path-exploration
読み: ケイロデータタンサク
カテゴリ: analytics

### 短い定義 (TL;DR)

経路データ探索は GA4 の探索レポートでユーザーがどの順番でイベントやページを通過したかを樹形図で可視化する機能です。順方向・逆方向の両方の経路を分析できます。

### 詳細解説

経路データ探索 (Path Exploration) は GA4 の探索レポートテンプレートの 1 つで、ユーザーがどの順番でページを閲覧し、どのイベントを発火していったかを樹形図 (sankey diagram) 形式で可視化する機能です。起点を「特定のページ閲覧」「特定のイベント発火」などに設定し、そこから順方向 (次に何をしたか) または逆方向 (その前に何をしていたか) のどちらでも分析できる柔軟性があります。1 ノードから最大 10 ステップ先まで枝分かれを表示でき、ノードをクリックすればさらにその先を展開できます。たとえば「購入完了ページに辿り着いたユーザーは事前にどのページを通っていたか」「商品詳細ページから何 % がカートに進み、何 % がカテゴリページに戻ったか」を直感的に把握できます。これにより想定したファネルに乗らない実際のユーザー行動を発見でき、サイト構造改善の手がかりになります。

### 実装例

- purchase イベントを起点に逆方向経路を辿り購入前の閲覧パターンを分析する
- ホームページから順方向 5 ステップでユーザーの離脱経路を特定する
- 想定ファネル外の流入経路 (パンくず → カテゴリ → 商品) を発見する

### 出典

- [[GA4] 経路データ探索](https://support.google.com/analytics/answer/9317498)

---

## ピークエンドの法則 (Peak-End Rule)

URL: https://exbk.jp/glossary/peak-end-rule
読み: ピークエンドのほうそく
カテゴリ: general

### 短い定義 (TL;DR)

ピークエンドの法則は「人は体験全体ではなくピーク時と終了時の感情で評価する」という心理学の法則で、Daniel Kahneman らが定式化しました。UX のジャーニー設計に応用されます。

### 詳細解説

ピークエンドの法則 (Peak-End Rule) は、ノーベル経済学賞受賞者 Daniel Kahneman らが1990年代に複数の研究で示した「人は体験を平均ではなく『最も強い瞬間 (ピーク)』と『終了時』の感情だけで記憶し評価する」という認知バイアスです。UX/CX への応用としては (1) チェックアウト完了画面・サンクスページに祝福演出を入れる (2) サブスク解約時に丁寧なオフボーディングで好印象を残す (3) 配送完了時にパーソナライズされたメールでピークを作る (4) エラー復帰の最終画面で前向きなメッセージを設計 (5) サポートチャット終了時に「解決できて良かった」と締める などです。逆に終了が悪いと体験全体の記憶も悪化するため、特にエラー画面・解約フロー・支払い失敗 等のネガティブイベントの「終わり方」設計が重要視されます。

### 実装例

- EC のサンクスページに紙吹雪アニメで「ピーク」を演出
- 解約完了画面で「いつでも戻ってこられます」と前向きクローズ
- サポートチャットの最後に CSAT + 「解決できて良かったです」

### 出典

- [Laws of UX - Peak-End Rule](https://lawsofux.com/peak-end-rule/)

---

## PEFT (Parameter-Efficient Fine-Tuning)

URL: https://exbk.jp/glossary/peft
読み: ペフト
カテゴリ: ai

### 短い定義 (TL;DR)

PEFT (Parameter-Efficient Fine-Tuning) は、LLM の全パラメータを更新せずに少数のパラメータだけ学習する手法群の総称です。LoRA・Prefix Tuning・QLoRA などが含まれます。

### 詳細解説

PEFT は Hugging Face が提供する OSS ライブラリ名でもあり、複数の効率的 fine-tuning 手法を統合実装しています。LoRA (低ランク行列追加)、QLoRA (量子化 + LoRA)、Prefix Tuning (前置きトークン学習)、Adapter (層間にアダプタ追加) などが選択可能。フル fine-tuning と比べて GPU メモリ 1/10 以下、学習時間 1/3 以下、配布サイズも数 MB と小さくなります。

### 実装例

- Hugging Face peft ライブラリで実装
- QLoRA で 65B モデルを 48GB GPU 1 枚で fine-tune
- 用途別アダプタを切替えて 1 ベースモデルで多目的運用

---

## Perplexity AI

URL: https://exbk.jp/glossary/perplexity
読み: パープレキシティ
カテゴリ: seo
最終確認: 2026-05-10

### 短い定義 (TL;DR)

Perplexity AI は、2022年12月にローンチされた AI 検索エンジンです。質問に対し複数のWebソースを参照して回答を生成し、引用元を明示する点が特徴で、GEO/LLMO 最適化の主要対象の1つです。

### 詳細解説

Perplexity AI は Aravind Srinivas らが設立したスタートアップが運営する AI 検索エンジンで、2024年時点で月間アクティブユーザー1500万人超、月間クエリ数5億回以上を記録しています。Sonnet・GPT-4o・Llama などの LLM をルーティングして利用し、独自の Web クローラー「PerplexityBot」で収集したインデックスから引用元 (通常3-7件) を明示しながら回答を生成します。SEO 観点では、Perplexity に引用されるための最適化を「GEO (Generative Engine Optimization)」と呼び、1) コンテンツの定量データ・引用文献を充実、2) 明確な見出し構造、3) PerplexityBot のクロールを robots.txt で許可、4) 高権威ドメインからの被リンクが重要とされます。Princeton 大学の研究 (2024) では、引用・統計・専門用語の追加で引用率が30-40%向上することが示されています。

### EXBK の見解 (Information Gain)

**2026年プラットフォーム別ソース嗜好の最新データ** (Averi / Profound 調査):
Perplexity は引用ソースの **46.7% を Reddit** から取得しています。日本市場では Reddit が弱いため、代替の **Earned Media** が必要です。

**EXBK の代替戦略 (日本市場版)**:
- Zenn / Qiita / note への技術記事連動 — Reddit 相当の被引用ソースとして機能
- X (旧 Twitter) で月次「AI マーケ用語10選」スレッド配信 — 短期的引用獲得に効果
- はてなブックマーク 100+ 取得 — Perplexity が日本ドメインで参照する数少ない上位インデックス

**検証結果 (EXBK 2026年4月)**:
Zenn 連動 5本投稿 → 3週間で Perplexity からの月間引用が 4件 → 17件 (+325%)。
Reddit を持たない日本市場では、Zenn を Reddit 等価のソースとして扱う戦略が有効です。

**PerplexityBot 許可の落とし穴**:
robots.txt で `User-Agent: PerplexityBot` を Allow しても、**Cloudflare WAF の Bot Fight Mode** が ON だと自動ブロックされます。Cloudflare ダッシュボードの Security → Bots で「Verified Bots」のホワイトリスト確認が必須。実装漏れで引用ゼロのケースを複数確認しています。


### 実装例

- PerplexityBot を robots.txt で許可しないと引用候補から外れます
- 統計データと引用文献を含む記事は Perplexity 引用率が40%上がります
- Perplexity からの流入はコンバージョン率が通常検索より2倍高い事例があります

### 同一エンティティ参照

- https://en.wikipedia.org/wiki/Perplexity_AI
- https://www.wikidata.org/wiki/Q116692019

### 出典

- [Perplexity AI](https://www.perplexity.ai/)
- [GEO: Generative Engine Optimization (arXiv 2311.09735)](https://arxiv.org/abs/2311.09735)

---

## ペルソナ

URL: https://exbk.jp/glossary/persona
読み: ペルソナ
カテゴリ: general

### 短い定義 (TL;DR)

ペルソナ (Persona) は、自社の理想的な顧客像を、実在する一人の人物のように具体化したマーケティング上の人物モデルです。年齢、職業、価値観、購買動機までを詳細に設定し、施策の方向性を統一する基本フレームです。

### 詳細解説

ペルソナとは、ターゲット顧客を「30歳女性会社員」のように曖昧に捉えるのではなく、「東京都在住、32歳、IT企業勤務、年収550万円、独身、Instagram で美容情報を毎日30分閲覧」といった具体的な一人の人物として描写する手法です。提唱者の Alan Cooper はソフトウェア設計の文脈で1998年に体系化しましたが、現在ではマーケティング全般で標準ツールとなっています。HubSpot の調査によると、バイヤーペルソナを活用する企業はリード獲得コストを最大73%削減できるとされています。ペルソナを作成する際は、既存顧客10人以上へのインタビューと、Google Analytics 4 等の定量データを組み合わせるのが基本で、定性と定量の両輪が品質を担保します。チーム全員が同じ顧客像を共有できるため、コピー、デザイン、商品企画の判断軸がぶれず、組織全体の意思決定速度が大きく向上します。理想は1社につき2-4ペルソナで、増やしすぎると焦点がぼやけるため注意が必要です。

### 実装例

- BtoB SaaS では「決裁者ペルソナ」と「現場担当者ペルソナ」の2層を作成して、それぞれに刺さるホワイトペーパーを出し分けます。
- 美容クリニックが「30代後半・小じわが気になり始めた働く母」のペルソナを設定し、Instagram 広告のクリエイティブをそれに最適化します。
- BtoC EC の楽天ショップが、購入履歴データから「年4回まとめ買いするリピーター」ペルソナを抽出し、メルマガ件名を A/B テストします。

### 出典

- [HubSpot - How to Create Detailed Buyer Personas](https://blog.hubspot.com/marketing/buyer-persona-research)

---

## pg_dump

URL: https://exbk.jp/glossary/pg-dump
読み: ピージーダンプ
カテゴリ: storage

### 短い定義 (TL;DR)

pg_dump は PostgreSQL の DB を SQL/カスタム/tar 形式でダンプするコマンドです。pg_dumpall は全 DB を一括ダンプします。本番稼働中もロックフリーで実行可能です。

### 詳細解説

pg_dump は PostgreSQL に標準同梱の論理バックアップツールで、デフォルトでロックなし (MVCC ベース) でダンプを取得できます。出力形式は plain (SQL)、custom (バイナリ・並列リストア可能)、tar、directory の 4 種類。custom 形式は pg_restore -j で並列復元が可能で、大規模 DB の復元時間を短縮できます。pg_dumpall は全 DB + ロール定義をまとめて取得、災害復旧に最適。

### 実装例

- pg_dump -U user mydb | gzip > mydb.sql.gz
- pg_dumpall -U user > all-databases.sql (全 DB)
- pg_dump -F c -j 4 mydb -f mydb.dump (custom 形式・並列)

### 出典

- [PostgreSQL pg_dump Documentation](https://www.postgresql.org/docs/current/app-pgdump.html)

---

## ピラーページ

URL: https://exbk.jp/glossary/pillar-page
読み: ピラーページ
カテゴリ: seo

### 短い定義 (TL;DR)

ピラーページ (Pillar Page) は、トピッククラスター戦略の中核となる、特定大テーマを網羅的に扱う長文記事のことです。3000-5000字以上で複数のクラスターページから内部リンクを集めます。

### 詳細解説

ピラーページは HubSpot のトピッククラスターモデルにおける中核ページで、特定の大テーマを横断的に網羅する3000-10000字級の長文記事です。役割は、a) クラスターページからの内部リンクを集約し PageRank を蓄積、b) ビッグキーワードで上位獲得を狙う、c) ユーザーの初期理解を提供する入口、d) 複数のクラスター記事へ誘導するハブ、です。構造は、1) 包括的な目次、2) 各セクションでサブトピックを概説、3) 各サブトピックから詳細クラスター記事へ内部リンク、4) FAQ セクション、で構成されます。代表例は、Backlinko の「The Definitive Guide to SEO」(15000字超、月間流入5万 PV) や、HubSpot の「Marketing Hub」など。実装ポイントは、a) URL を /seo-guide/ のようにシンプルに、b) 階層を深くしすぎない、c) 目次にジャンプリンク、d) 1テーマ1ピラーに絞る、です。

### 実装例

- Backlinko の SEO 完全ガイドは月間5万 PV の代表的ピラーページ事例です
- ピラーページ単体での順位より、クラスター群との内部リンクで評価が決まります
- 1つのテーマで複数ピラーを作るとカニバリゼーションを起こします

### 出典

- [HubSpot - How to Create a Pillar Page](https://blog.hubspot.com/marketing/what-is-a-pillar-page)

---

## Pinterest Ads (Pinterest Ads (Pinterest Business))

URL: https://exbk.jp/glossary/pinterest-ads
読み: ピンタレストアズ
カテゴリ: ads

### 短い定義 (TL;DR)

Pinterest Ads はビジュアル発見型 SNS『Pinterest』に広告配信できるプラットフォームです。ユーザーが将来の購買・実行意図を持って検索することが多く、ファッション・インテリア・ウェディング領域で高い CVR を発揮します。

### 詳細解説

Pinterest Ads は Pinterest Business Manager から運用する広告配信プラットフォームで、画像・動画ピンを Promoted Pin として配信します。Pinterest ユーザーは『未来の自分が欲しいもの』を保存する習慣があり、購入意向が高い状態でブランドと接触するため、ファッション、ホームデコ、レシピ、ウェディング、DIY、美容領域で特に効果が高いとされています。米国でのアクティブユーザーの 70% が女性、Z 世代の利用も急増中で、日本市場ではまだ CPC が安く費用対効果が良い穴場媒体です。

### 実装例

- ウェディングドレスショップが Promoted Pin で結婚予定の女性にリーチ
- ライフスタイルブランドが Idea Pins (動画ピン) で UGC 風の広告を出稿する
- Pinterest Tag で保存→クリック→購入のファネル分析を行う

### 出典

- [Pinterest Business](https://business.pinterest.com/)
- [Pinterest Ads Help](https://help.pinterest.com/business)

---

## ピボット

URL: https://exbk.jp/glossary/pivot
読み: ピボット
カテゴリ: general

### 短い定義 (TL;DR)

ピボット (Pivot) は、検証結果から事業の方向性を大胆に転換する戦略変更です。バスケのピボット動作のように、片足を軸に方向だけを変えるイメージから命名されました。事業戦略の柔軟性を担保する重要なオプションです。

### 詳細解説

ピボットは Eric Ries が『The Lean Startup』(2011) で体系化した概念で、MVP で検証した結果が想定と違う場合、事業の方向性を構造的に転換することを指します。代表的なピボット類型は、(1) Customer Pivot (顧客セグメント転換)、(2) Problem Pivot (解決する課題の転換)、(3) Solution Pivot (解決手段の転換)、(4) Channel Pivot (販売チャネル転換)、(5) Business Model Pivot (収益モデル転換) など10種類以上があります。著名事例として、Twitter は元々 Odeo というポッドキャスト配信サービスから、Slack はゲーム会社 Tiny Speck の社内ツールから、Instagram は位置情報アプリ Burbn から、それぞれピボットして大成功しました。日本では、メルカリ前身の「コウゾウ」がフリマ事業へ転換した例があります。ピボットの判断は痛みを伴いますが、CB Insights の分析によると、事業失敗の42% は「市場ニーズの欠如」が原因であり、早期のピボットがスタートアップ生存率を大幅に高めます。一方、頻繁なピボットは組織の混乱を招くため、四半期ごとの判断が現実的です。

### 実装例

- BtoB SaaS が中小企業向けからエンタープライズへ顧客ピボット、契約単価を10倍に伸ばします。
- EC が単品販売からサブスク BOX へモデルピボット、リピート率を30%→80% へ改善します。
- アプリが、当初想定の20代向けからシニア向けへペルソナピボットし、CAC を半減させます。

### 出典

- [Eric Ries - The Lean Startup Pivot Types](http://theleanstartup.com/principles)

---

## PMF (Product Market Fit (製品市場適合))

URL: https://exbk.jp/glossary/pmf
読み: ピーエムエフ
カテゴリ: general

### 短い定義 (TL;DR)

PMF (Product Market Fit) は、商品が市場のニーズに合致し、自然に売れ広がる状態のことです。スタートアップが最初に達成すべき最重要マイルストーンです。Marc Andreessen が2007年に広めた中核概念です。

### 詳細解説

PMF は、ベンチャーキャピタリスト Marc Andreessen が2007年のブログで広めた概念で、「商品が顧客の課題を強く解決し、口コミで自然に広がる状態」を指します。Sean Ellis テスト (「この商品が使えなくなったらどう感じますか?」のアンケートで『非常にがっかり』が40% 以上) が定量的判定基準として広く使われます。Superhuman の Rahul Vohra は、PMF 達成のために Sean Ellis スコアを地道に改善する手法で2018年から有名になりました。Andreessen は「PMF 以前はとにかく PMF 達成だけにフォーカスし、それ以外は雑音」と述べ、創業期の最重要 KPI と位置付けています。判断指標は、(1) リテンション曲線が水平化、(2) オーガニック流入の急増、(3) NPS 50以上、(4) 解約率の急減、(5) サポートからの「もっと作って」の声、などです。日本では、SmartHR が労務管理 SaaS で、メルカリがフリマアプリで PMF を達成した代表例です。PMF 達成前に広告投資を増やすと CAC が無駄に高騰するため、「PMF 達成 → スケール」の順序が鉄則です。

### 実装例

- スタートアップが Sean Ellis テストで「非常にがっかり」45% を超え、PMF 達成と判断し営業を増員します。
- アプリが3か月後リテンション曲線が水平化し、オーガニック登録が前月比2倍と確認、PMF と判定します。
- BtoB SaaS が解約率が3%→1% に下がり、NPS が60超に達した時点で PMF 達成宣言します。

### 出典

- [Marc Andreessen - The Only Thing That Matters](https://pmarchive.com/guide_to_startups_part4.html)

---

## Pogo-sticking

URL: https://exbk.jp/glossary/pogo-sticking
読み: ポゴスティッキング
カテゴリ: seo

### 短い定義 (TL;DR)

Pogo-sticking (ポゴスティッキング) は、ユーザーが検索結果から訪問したページをすぐに離脱して SERP に戻り、別のページをクリックする行動のことです。検索意図とのミスマッチを示すシグナルです。

### 詳細解説

Pogo-sticking は、ユーザーが検索結果ページ (SERP) のリンクをクリックして訪問したページに満足せず、すぐに戻るボタンで SERP に戻り、別のリンクをクリックする一連の行動を指します。直帰率や Dwell Time と異なり、ユーザーが「次のページを探している」という能動的な不満を示す強いネガティブシグナルです。Google は明示していませんが、特許 US8661029B1 などでこの行動データを利用する仕組みが言及されています。Pogo-sticking が頻発するページは、タイトルと内容の乖離、ファーストビューでの結論不在、モバイルでの読みづらさが原因の場合が多く、SEO 順位低下の前兆として監視すべき指標です。

### 実装例

- SERP 1位でも Pogo-sticking が多発するとランキング降格の可能性があります
- タイトル詐欺 (内容と異なる煽りタイトル) は Pogo-sticking の典型要因です
- ファーストビューに結論を配置することで Pogo-sticking を50%削減できます

### 出典

- [Google Patents - US8661029B1 (Modifying ranking signals based on pogo-sticking)](https://patents.google.com/patent/US8661029B1)

---

## ポジショニング

URL: https://exbk.jp/glossary/positioning
読み: ポジショニング
カテゴリ: general

### 短い定義 (TL;DR)

ポジショニング (Positioning) は、競合と比較したときに自社商品が顧客の頭の中で占める位置を意図的に設計することです。「Volvo は安全」のような独自の認識を作る戦略概念です。ブランド構築の出発点となる必須概念です。

### 詳細解説

ポジショニングは Al Ries と Jack Trout が1981年の著書『Positioning: The Battle for Your Mind』で広めた概念で、商品そのものではなく顧客の認知を競争の場と捉えます。Volvo = 安全、BMW = 駆け抜ける歓び、Apple = クリエイティビティ、というように、一語で想起される強い連想を作ることが目的です。ポジショニングマップは、縦軸と横軸に重要属性 (例: 価格 × 高級感) を置き、自社と競合をプロットして空白地帯を見つける手法です。Tesla は「高性能 × エコ」という当時空白だった象限に陣取って成功しました。ポジショニングを変えるリポジショニングは難易度が高く、Old Spice が2010年に「おじさん向け制汗剤」から「若者向けクール」へ転換した事例は教科書に載るほどです。一貫したコピー、ビジュアル、価格、流通の4要素で支えることが必須です。

### 実装例

- BtoB SaaS が「中小企業向け・最安値」と「大企業向け・高機能」のマップで空白象限を見つけて参入します。
- ローカル和菓子店が「観光客向け × プレミアム」ではなく「地元客向け × デイリー消費」にポジションを絞り込みます。
- 新規ジムが、競合がフィットネス重視の中で「メンタルケア併設・40代以上向け」と独自ポジションで差別化します。

### 出典

- [Al Ries & Jack Trout - Positioning: The Battle for Your Mind](https://www.mhprofessional.com/positioning-the-battle-for-your-mind-9780071373586-usa)

---

## PostgreSQL

URL: https://exbk.jp/glossary/postgresql
読み: ポストグレスキューエル
カテゴリ: infra

### 短い定義 (TL;DR)

PostgreSQL は世界で最も高機能と評されるオープンソースの RDBMS です。JSONB / GIS (PostGIS) / 全文検索など機能が豊富で、Postiz・Temporal・Supabase 等の現代的なバックエンドに採用されています。

### 詳細解説

PostgreSQL (略称 Postgres) は MIT ライセンス類似の PostgreSQL ライセンスで配布される OSS です。MVCC による高度な並行制御、トランザクションの完全な ACID 準拠、行レベル排他制御、CTE / Window 関数などの SQL 規格準拠機能で MySQL/MariaDB を凌駕します。JSONB 型でドキュメント DB 的な使い方もでき、PostGIS で地理空間データも扱えます。Docker イメージ postgres:16-alpine が安定版で、本番のバックアップは pg_dumpall で全 DB を SQL ダンプとして取り出します。

### 実装例

- Postiz / Temporal / Supabase のメイン DB
- PostGIS で地理空間検索 (店舗の緯度経度)
- pg_dumpall で全 DB を SQL ダンプ化

### 出典

- [PostgreSQL Official](https://www.postgresql.org)

---

## Postiz

URL: https://exbk.jp/glossary/postiz
読み: ポスティズ
カテゴリ: ai

### 短い定義 (TL;DR)

Postiz (ポスティズ) はセルフホスト可能な OSS の SNS 投稿スケジューリングツールです。Twitter / Instagram / LinkedIn / TikTok 等を統一管理でき、Buffer / Hootsuite の代替になります。

### 詳細解説

Postiz は 2024 年公開の OSS で、AGPL ライセンス。Docker 一発で立ち上げられ、Twitter / Instagram / LinkedIn / TikTok / YouTube / Threads など主要 SNS をサポート。AI 機能 (投稿文生成・画像生成) も統合され、Buffer / Hootsuite に比べ自社運用でデータ主権を維持できる点が強みです。SaaS 版もありますが、セルフホストでは Pro 機能も無料で使えます。

### 実装例

- Hostinger VPS にセルフホストして全社 SNS 運用
- AI で投稿文を一括生成 → 1 週間分予約
- BuyMeACoffee 連携でチップ受付

### 出典

- [Postiz](https://postiz.com)

---

## プレビューモード (Preview Mode)

URL: https://exbk.jp/glossary/preview-mode
読み: プレビューモード
カテゴリ: analytics

### 短い定義 (TL;DR)

プレビューモードは GTM で本番公開前に実装内容を実サイトでテストできる機能です。Tag Assistant Preview を起動し対象サイトを開くと、タグ発火・データレイヤー値・変数値を確認できます。

### 詳細解説

プレビューモード (Preview Mode) は GTM においてコンテナの変更内容を本番公開する前に、実際のサイトで動作確認できるテスト機能です。GTM 管理画面右上の「プレビュー」ボタンをクリックし、対象サイトの URL を入力すると Tag Assistant が起動し、別ウィンドウでサイトが開きます。サイトを操作するたびに Tag Assistant 側に「Summary (発火タグ一覧)」「Tags (各タグの発火結果)」「Variables (変数値)」「Data Layer (データレイヤーの履歴)」がリアルタイムで表示され、想定通りに動作しているかをイベント単位で詳細確認できます。プレビュー中のタグは「実際の Cookie の保存」も伴うため、GA4 のリアルタイムレポートにもデータが反映され、計測経路全体の動作確認が可能です。複数人が同時にプレビューしても干渉しない設計となっており、ワークスペース機能と組み合わせて 1 ワークスペースごとに独立したテストができます。本番公開前に必ずプレビューで全タグの動作を確認するのが運用上のベストプラクティスです。

### 実装例

- Tag Assistant Preview で GA4 タグの発火と購入金額値を確認する
- デバッグモードで購入完了イベントが特定 URL でのみ発火するか検証する
- プレビューで GA4 リアルタイムレポートとの整合性を確認してから公開する

### 出典

- [Tag Manager プレビュー モード](https://support.google.com/tagmanager/answer/6107056)

---

## プロンプトエンジニアリング

URL: https://exbk.jp/glossary/prompt-engineering
読み: プロンプトエンジニアリング
カテゴリ: ai

### 短い定義 (TL;DR)

プロンプトエンジニアリングは、LLM の出力品質を最大化するために入力プロンプトを設計・調整する技術です。few-shot 例示、Chain-of-Thought、ロール指定、出力形式指定などのテクニックがあります。

### 詳細解説

プロンプトエンジニアリングは「LLM への命令の出し方」を最適化する分野で、同じモデルでもプロンプトの良し悪しで出力品質が劇的に変わります。代表的テクニック: (1) ロール指定 ('あなたは経験豊富なマーケターです')、(2) Few-shot 例示 (3 例見せる)、(3) Chain-of-Thought ('段階的に考えて'と指示)、(4) 出力形式の構造化 (JSON / Markdown 指定)、(5) 制約明示 ('500 字以内で')。専門職としても確立しつつあり、年収の高いポジションも増加中。

### 実装例

- ロール指定でトーンを安定化
- Few-shot 3 例で構造を学習させる
- JSON 出力指定で後段処理を自動化

### 出典

- [OpenAI Prompt Engineering Guide](https://platform.openai.com/docs/guides/prompt-engineering)

---

## サイコグラフィック

URL: https://exbk.jp/glossary/psychographics
読み: サイコグラフィック
カテゴリ: general

### 短い定義 (TL;DR)

サイコグラフィック (Psychographics) は、価値観、ライフスタイル、興味関心、性格特性といった心理的属性で顧客を分類する手法です。デモグラの限界を補い、購買動機の深層を捉えます。深層心理を捉える上で BtoC マーケに不可欠です。

### 詳細解説

サイコグラフィックは「同じ30代女性でも、ヴィーガン志向の人と肉好きの人では響く広告がまったく違う」という課題に対する解決策として1970年代に SRI International が VALS (Values and Lifestyles) フレームワークを開発したのが起源です。現在では、Meta 広告の「興味関心ターゲティング」や Google の「アフィニティセグメント」「カスタムインテント」がサイコグラフィックの実装例にあたります。例えば、Patagonia は「環境保護に強い関心がある」というサイコグラフィックでターゲティングし、デモグラ的には20代から60代まで幅広い顧客を獲得しています。Nielsen の調査では、サイコグラフィックを併用したキャンペーンはデモグラ単独に比べて CVR が平均1.5倍高いと報告されています。アンケート、SNS 分析、行動データを組み合わせて推定するのが一般的です。

### 実装例

- アウトドアブランドが「環境意識が高い・キャンプ趣味・SDGs に関心」というサイコグラフィックで Meta 広告を配信します。
- ヨガスタジオが「ウェルネス志向・自己投資に積極的・年4冊以上の読書」という価値観で LP コピーを設計します。
- 高級ホテルが「Bleisure 志向 (Business+Leisure)・体験消費を重視」のターゲットに、ワーケーションプランを訴求します。

### 出典

- [Strategic Business Insights - VALS Framework](https://www.strategicbusinessinsights.com/vals/)

---

## PV (Page View)

URL: https://exbk.jp/glossary/pv
読み: ピーブイ
カテゴリ: analytics

### 短い定義 (TL;DR)

PV (Page View) はウェブサイトのページが 1 回読み込まれるごとにカウントされる指標です。GA4 では page_view イベントとして自動収集され、最も基本的なトラフィック量の指標として広く使われます。

### 詳細解説

PV (Page View) はウェブサイトのページが読み込まれた回数を表す最も基本的なアクセス解析指標で、ブラウザでページが表示されるたびに 1 加算されます。GA4 では拡張計測機能の一部として page_view イベントが自動的に発火し、URL (page_location)・ページタイトル (page_title)・流入元 (page_referrer) が同時にパラメータとして送信されます。同じユーザーが同じページを 2 回更新した場合は 2PV としてカウントされ、ユニークではありません。「PV÷UU」で 1 ユーザーあたりの平均閲覧ページ数 (旧称: ページ/セッション) を、「PV÷セッション」でセッションあたりの PV を計算できます。SPA (Single Page Application) では URL 変更を伴わずに画面遷移するため、history.pushState を検知して仮想 PV を送信する実装が必要です。広告メディアの売上計算 (CPM) や記事メディアの主要 KPI として依然重要視される指標です。

### 実装例

- 月間 100 万 PV を目標にコンテンツ計画を設計する
- GA4 の page_view イベント数を BigQuery で集計し前年比を比較する
- SPA で history.pushState 発火時に gtag('event', 'page_view') を送信する

### 出典

- [[GA4] page_view イベント](https://support.google.com/analytics/answer/9216061)

---

## 品質スコア (Quality Score (QS))

URL: https://exbk.jp/glossary/quality-score
読み: ヒンシツスコア
カテゴリ: ads

### 短い定義 (TL;DR)

品質スコアは Google Ads が広告キーワード・広告文・LP の関連性を 1〜10 の 10 段階で評価する指標です。スコアが高いほど CPC が下がり広告ランクが上がるため、運用最適化の中心指標となっています。

### 詳細解説

品質スコア (Quality Score) は Google Ads が広告の品質を 1〜10 の 10 段階で評価する内部スコアで、『推定 CTR』『広告の関連性』『LP の利便性』の 3 要素から算出されます。スコア 1〜3 は『平均より低い』、4〜6 は『平均的』、7〜10 は『平均より高い』に該当し、10 のキーワードは 1 のキーワードに比べて CPC が約 50% 安く、表示順位も 2〜3 ランク上がるとされます。LP 改善・広告文と検索クエリのマッチ・拡張機能 (サイトリンク等) 設置で改善でき、品質スコアの低いキーワードを発見→改善するのが運用 PDCA の基本です。

### 実装例

- 品質スコア 4 のキーワードを LP 改善で 8 にし CPC を 35% 削減
- 推定 CTR が『平均より低い』広告を A/B テストで改善
- LP のロード速度を 5s→2s にして LP 利便性スコアを上げる

### 出典

- [Google Ads ヘルプ - 品質スコアについて](https://support.google.com/google-ads/answer/6167118)
- [Google Ads ヘルプ - 品質スコアの確認方法](https://support.google.com/google-ads/answer/2454010)

---

## RAG (Retrieval-Augmented Generation)

URL: https://exbk.jp/glossary/rag
読み: ラグ
カテゴリ: ai
最終確認: 2026-05-10

### 短い定義 (TL;DR)

RAG (Retrieval-Augmented Generation) とは、LLM の回答生成時に外部知識ベース(社内ドキュメント、商品DB、マニュアル等)から関連情報を検索 (Retrieval) して文脈に注入し、回答精度を高める技術です。ChatGPT のカスタムGPT、社内ナレッジ検索ボット等で広く使われます。

### 詳細解説

LLM 単体は学習時点の知識しか持たないため、最新情報や社内情報には答えられません。RAG はこの問題を解決するため、(1) ユーザー質問を Embedding ベクトルに変換、(2) ベクトルDB から類似度の高い社内ドキュメントを検索、(3) 検索結果を LLM のプロンプトに注入、(4) LLM が外部知識を踏まえた回答を生成、というパイプラインを取ります。実装には LangChain・LlamaIndex・Haystack 等のフレームワーク、ベクトルDB には Pinecone・Weaviate・Qdrant・Supabase pgvector 等が使われます。マーケティング用途では (1) 社内事例集を RAG 化して営業提案を高速生成、(2) 商品マニュアルを RAG 化してカスタマーサポート自動化、等で活用されます。

### EXBK の見解 (Information Gain)

**EXBK 実装事例: 中小企業向け「営業提案 RAG」 (2026年Q1)**
- 構成: Cloudflare Workers AI + Vectorize + R2 でフルマネージド構築
- 商談履歴 850件 + 提案書テンプレ 120件 + 業種別事例 200件をベクトル化
- 月額コスト: $18 (Vectorize 50M クエリ + Workers AI 推論)
- 営業提案作成時間: 平均 3.2時間 → 28分 (-86%)

**失敗パターン (EXBK が観測した実例)**:
1. **チャンクサイズ過大** (2000+ tokens): Embedding 精度低下、無関係チャンクが Top-K に混入。**500-800 tokens に分割が無難**。
2. **Re-ranker 未実装**: Cohere Rerank / Cross-encoder を入れないと精度頭打ち。**+15-25% 精度改善が一般的**。
3. **メタデータフィルタ不足**: 「最新の」「日本国内の」等の文脈情報を Embedding 任せにすると低精度。frontmatter で明示フィルタすると劇的改善。

**2026 年の最新トレンド**:
Naive RAG → Advanced RAG → Modular RAG → **Agentic RAG** へ移行中。Anthropic の Claude Computer Use や OpenAI の o3 系の登場で「LLM 自身が検索戦略を動的に決める」方式が主流化しつつあります。


### 同一エンティティ参照

- https://en.wikipedia.org/wiki/Retrieval-augmented_generation

### 出典

- [Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (Lewis et al., NeurIPS 2020)](https://arxiv.org/abs/2005.11401)
- [OpenAI Cookbook: Retrieval Augmented Generation](https://cookbook.openai.com/examples/question_answering_using_embeddings)

---

## レートリミット (Rate Limiting)

URL: https://exbk.jp/glossary/rate-limit
読み: レートリミット
カテゴリ: general

### 短い定義 (TL;DR)

レートリミットは、APIやWebエンドポイントへのリクエスト数を時間単位で制限する仕組みで、ブルートフォース・DDoS・乱用対策の基本要素です。

### 詳細解説

レートリミットは、IP・ユーザー・APIキー単位で「N リクエスト / 期間」の上限を設けて超過時に 429 Too Many Requests を返す制御で、ブルートフォース攻撃・スクレイピング・コスト膨張型DoS・APIアビューズの第一防御線です。アルゴリズムは Token Bucket / Leaky Bucket / Fixed Window / Sliding Window / Sliding Window Log が代表で、それぞれバースト許容度と精度のトレードオフがあります。レスポンスヘッダーには X-RateLimit-Limit / X-RateLimit-Remaining / X-RateLimit-Reset / Retry-After が業界慣習で、IETF RFC 9331 で標準化が進んでいます。Cloudflare Rate Limiting・AWS WAF Rate Rules・nginx limit_req・Redis + Lua 等で実装されます。ログイン・パスワードリセット・OTP送信・SMS等の高コスト操作には必須です。

### 実装例

- ログインAPI は 5 req / 5min / IP に制限してブルートフォース対策
- Cloudflare Rate Limiting で 100 req / min を超えるIPをチャレンジ
- Twitter API v2 は 300 req / 15min のスライディングウィンドウ

### 出典

- [OWASP API Security Top 10 - API4:2023 Unrestricted Resource Consumption](https://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/)

---

## rclone

URL: https://exbk.jp/glossary/rclone
読み: アールクローン
カテゴリ: storage

### 短い定義 (TL;DR)

rclone (アールクローン) は 70 種類以上のクラウドストレージ間でファイル同期できる OSS ツールです。Dropbox から Nextcloud への移行や、複数クラウドへの並列バックアップに使われます。

### 詳細解説

rclone は MIT ライセンスの OSS で、AWS S3 / Cloudflare R2 / Backblaze B2 / Google Drive / Dropbox / OneDrive / WebDAV / SFTP / Local など 70+ のバックエンドに対応。rclone copy / sync / mount などのコマンドで、クラウド間の高速並列転送が可能。restic のバックエンドとしても利用でき、RClone Backend で restic から R2 等の SDK 未実装ストレージへも書き込めます。Dropbox から Nextcloud への移行は rclone copy dropbox:source nextcloud:dest で完結します。

### 実装例

- rclone copy dropbox:photos nextcloud:photos (Dropbox → Nextcloud 移行)
- rclone mount r2:bucket /mnt/r2 (FUSE で R2 をマウント)
- rclone sync local:/data b2:remote (Backblaze B2 へ同期)

### 出典

- [rclone Documentation](https://rclone.org)

---

## ReAct (Reasoning + Acting)

URL: https://exbk.jp/glossary/react-agent
読み: リアクト
カテゴリ: ai

### 短い定義 (TL;DR)

ReAct (Reasoning + Acting) は、LLM エージェントが「思考 → 行動 → 観察」のループでタスクを解決する設計パターンです。LangChain / LlamaIndex の標準的なエージェント実装に採用されています。

### 詳細解説

ReAct は 2022 年 Princeton/Google の論文で提案され、Chain-of-Thought とツール使用を組み合わせた最初期の実用設計です。Thought (思考)・Action (ツール呼出)・Observation (結果観察) を Markdown 形式で順次出力し、LLM が動的に判断を更新します。後の Tree of Agents / OpenAI o1 / Claude extended thinking 等の起源と言える設計。

### 実装例

- Thought: 検索が必要 → Action: web_search('...') → Observation: 結果
- LangChain の ReAct エージェント標準実装
- OpenAI o1 / o3 の内部思考も派生形

### 出典

- [ReAct paper (Yao et al., 2022)](https://arxiv.org/abs/2210.03629)

---

## リアルタイムレポート (Realtime Report)

URL: https://exbk.jp/glossary/realtime-report
読み: リアルタイムレポート
カテゴリ: analytics

### 短い定義 (TL;DR)

リアルタイムレポートは GA4 で過去 30 分間のユーザー行動を即時表示するレポートです。地域・流入元・コンバージョン・イベントを 30 秒単位で更新表示します。

### 詳細解説

リアルタイムレポート (Realtime Report) は GA4 において過去 30 分間のユーザー行動を約 30 秒のラグでほぼリアルタイムに可視化するレポート機能です。表示できるのは (1) 現在のアクティブユーザー数、(2) ユーザーの所在地 (国・市区町村)、(3) 流入元 (チャネル・参照元)、(4) ユーザー属性、(5) 閲覧中のページ、(6) 直近のイベント、(7) コンバージョン発生状況、の 7 つで、左ペインで 30 分間の推移を 1 分粒度で確認できます。主な活用シーンは (a) キャンペーン開始直後のトラッキング動作確認、(b) テレビ CM・プレスリリース直後のスパイク確認、(c) 大規模イベント・セール時のリアルタイム監視、(d) GA4 タグ実装の動作確認、などです。「比較」機能でセグメント間のリアルタイム比較も可能で、特定 URL や特定流入元のユーザー数を絞って表示できます。なお、データ反映には最大 5 分程度のラグが発生する場合があります。

### 実装例

- GA4 タグ設置直後にリアルタイムで自分の操作が反映されることを確認する
- テレビ CM 放映時間帯のアクティブユーザー数スパイクを監視する
- セール開始 5 分後のコンバージョン発生をリアルタイムで把握する

### 出典

- [[GA4] リアルタイム レポート](https://support.google.com/analytics/answer/9271392)

---

## リブランディング

URL: https://exbk.jp/glossary/rebranding
読み: リブランディング
カテゴリ: general

### 短い定義 (TL;DR)

リブランディング (Rebranding) は、既存ブランドの戦略・名称・ロゴ・デザインを刷新する取り組みです。市場変化や顧客層拡大、不祥事リカバリーなどの目的で実施されます。Old Spice や Burberry が成功例として知られています。

### 詳細解説

リブランディングは、既存のブランド要素 (戦略・名前・ロゴ・タグライン・カラー・トーン) を全部または一部刷新する取り組みです。背景は、(1) 市場や顧客層の変化、(2) M&A や事業ピボット、(3) 競合との差別化、(4) 不祥事や時代遅れの印象払拭、(5) グローバル展開、などです。著名事例として、2010年に Old Spice が古臭い制汗剤ブランドから「The Man Your Man Could Smell Like」キャンペーンで若者向けクールブランドに転換し、売上が2倍になりました。Burberry は2000年代にブランド毀損から脱却するため、デザイナー Christopher Bailey 起用と顧客層の若返りで復活しました。日本では、富士フイルムが写真フィルム事業からヘルスケア・素材へのピボット時に「FUJIFILM」ブランドのコーポレートスローガンを「Value from Innovation」に刷新しました。リブランディングは数千万〜数億円規模の投資が必要で、Interbrand の調査では成功率は約30% 程度と難易度が高い取り組みです。一貫性ある実行と、内部 (社員) と外部 (顧客) のコミュニケーション設計が成功の鍵です。

### 実装例

- Old Spice が「おじさん臭い」イメージを払拭、Y 世代向けクールブランドに転換し売上倍増を達成します。
- BtoB SaaS が中小企業向けからエンタープライズ向けにリブランディング、ロゴ・カラーを刷新し単価10倍。
- 地方銀行がデジタル化を象徴するロゴと CI に刷新、若年層口座開設を3倍に拡大します。

### 出典

- [Interbrand - Brand Strategy](https://interbrand.com/)

---

## Redis (REmote DIctionary Server)

URL: https://exbk.jp/glossary/redis
読み: レディス
カテゴリ: infra

### 短い定義 (TL;DR)

Redis (レディス) は、メモリ上で動作する高速 Key-Value 型データストアです。キャッシュ・セッション管理・分散ロック・PubSub などの用途で広く使われ、ディスク I/O のボトルネックを回避するためのインフラ標準コンポーネントとして定着しています。

### 詳細解説

Redis は BSD ライセンスの OSS で、文字列・リスト・ハッシュ・セット・ソート済みセット等の豊富なデータ型をサポートします。永続化はオプション (RDB / AOF) で、揮発性キャッシュとして使う場合は無効化することでパフォーマンスを最大化できます。Nextcloud の memcache.locking バックエンドとして使うと、DB ロックが詰まる問題を解消できます。WordPress / Laravel / Rails 等のフレームワークも公式サポート。Docker イメージ redis:7-alpine が約 30MB と軽量で、サイドカーとして簡単に立ち上げられます。

### 実装例

- Nextcloud の memcache.locking バックエンドとして使用 (DB ロック詰まり対策)
- Web セッションストア (ログイン状態の保持)
- API レートリミット (Upstash Redis 等)

### 出典

- [Redis Official](https://redis.io)

---

## リファラルマーケティング

URL: https://exbk.jp/glossary/referral-marketing
読み: リファラルマーケティング
カテゴリ: general

### 短い定義 (TL;DR)

リファラルマーケティング (Referral Marketing) は、既存顧客が新規顧客を紹介する仕組みを意図的に設計する手法です。Dropbox の容量プレゼントが代表例で、低 CAC で高品質な顧客を獲得できます。

### 詳細解説

リファラルマーケティングは、満足した既存顧客に紹介インセンティブを与えて新規顧客を呼び込む仕組みです。Nielsen の調査では、口コミによる紹介で得た顧客は他チャネルより4倍購入する確率が高く、LTV が16% 大きいというデータがあります。代表事例の Dropbox は、紹介者と被紹介者の双方に500MB の追加容量を提供する仕組みで、登録者を15か月で10万人→400万人に成長させました (CAC は他広告の1/10)。Tesla の紹介プログラムでは、紹介者にスーパーチャージャー無料供給、被紹介者に1,000ドル割引を提供し、ピーク時には新規購入の25% が紹介経由でした。Airbnb、Uber、PayPal も紹介プログラムでスケールした代表例です。日本では、メルカリの「招待コード入力で500ポイント」がリファラルの定番実装です。設計のポイントは、(1) 双方向インセンティブ (紹介者・被紹介者の両方にメリット)、(2) 簡単なシェア導線、(3) リファラル係数 (K-Factor) のモニタリング、です。優れた商品サービスがあって初めて成立する施策で、PMF 達成後に投入するのが定石です。

### 実装例

- SaaS が「紹介で双方1か月無料」を実装、新規顧客の30% が紹介経由となり CAC を半減させます。
- EC ブランドが「友達紹介で双方1,000円 OFF」を導入、リピート率と新規獲得を同時に拡大します。
- アプリが招待コード機能で、月間新規 DL の20% を紹介経由から獲得しています。

### 出典

- [Nielsen - Trust in Advertising](https://www.nielsen.com/insights/2021/trust-in-advertising/)

---

## リマーケティング (Remarketing / Retargeting)

URL: https://exbk.jp/glossary/remarketing
読み: リマーケティング
カテゴリ: ads

### 短い定義 (TL;DR)

リマーケティングは過去にサイト訪問・アプリ起動・動画視聴などの接点があったユーザーに対して再度広告配信する手法です。CV 直前の離脱ユーザーへの再アプローチで CVR を大きく引き上げられます。

### 詳細解説

リマーケティング (Remarketing, リターゲティングとも) は過去に web サイト訪問・アプリ起動・動画視聴・特定行動を行ったユーザーに対して、後日別の広告枠で再度広告配信する手法です。Google Ads では『データセグメント (旧オーディエンス)』、Meta Ads では『カスタムオーディエンス』、Yahoo!広告では『サイトリターゲティング』として実装されます。CV 直前で離脱したユーザーは購買意向が高いため CVR が一般配信の 5〜10 倍になることが多く、EC・BtoB の主力チャネルです。Cookie 制限により最近は 1st party データ (メール・電話) を使った Customer Match / カスタムオーディエンスが主流化しています。

### 実装例

- カート離脱者に 7 日以内のリマケ配信で CVR 12% を達成
- 資料請求 LP 訪問者へ Meta カスタムオーディエンスで動画広告配信
- Cookie 制限後はメールアドレスで Customer Match 配信に移行

### 出典

- [Google Ads ヘルプ - リマーケティング](https://support.google.com/google-ads/answer/2453998)
- [Meta Business - カスタムオーディエンス](https://www.facebook.com/business/help/744354708981227)

---

## restic

URL: https://exbk.jp/glossary/restic
読み: レスティック
カテゴリ: storage

### 短い定義 (TL;DR)

restic (レスティック) は OSS の暗号化バックアップツールです。重複排除・スナップショット・S3 互換ストレージ対応を備え、単一バイナリで動作します。Linux / macOS / Windows 全対応。

### 詳細解説

restic は Go 言語で実装されたバックアップツールで、BSD ライセンスの OSS です。ローカル / SFTP / S3 互換 / Backblaze B2 / Azure / Google Cloud Storage 等のリポジトリに対応。AES-256 で暗号化、コンテンツアドレッサブルな重複排除でストレージを節約、スナップショット差分管理で世代復元が可能。BorgBackup と機能的に近いですが、restic は単一バイナリで動作する点とクラウドネイティブな S3 対応が強み。restic init / backup / restore / forget --keep-* / check の主要コマンドを覚えれば運用できます。

### 実装例

- restic init で R2 リポジトリ作成 (パスフレーズ暗号化)
- restic backup /path で増分バックアップ (重複排除込み)
- restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 で保持ポリシー適用

### 出典

- [restic Documentation](https://restic.readthedocs.io/)

---

## 復元テスト

URL: https://exbk.jp/glossary/restore-test
読み: ふくげんテスト
カテゴリ: storage

### 短い定義 (TL;DR)

復元テストは、バックアップから実際にファイル/DB を復元できるかを定期的に確認する運用です。「バックアップは取れている」と思い込んで実は復元できないケースを防ぎます。

### 詳細解説

「復元したことがないバックアップは、バックアップではない」が業界の格言です。鍵紛失・媒体故障・暗号化失敗・論理破損など、本当に必要なときに気づく失敗が多発します。月 1 回必ず単一ファイル復元テストを実施し、四半期に 1 回はフル復元を別環境で試すのが推奨。restic restore latest --target /tmp/test --include /path で数秒で実施可能なので、運用フローに組み込むべきです。

### 実装例

- restic restore latest --target /tmp/restore --include /etc/hostname
- diff オリジナル 復元先 で完全一致確認
- 四半期に 1 回は別 VPS にフル復元してフェイルオーバーリハーサル

---

## リテンションコホート (Retention Cohort)

URL: https://exbk.jp/glossary/retention-cohort
読み: リテンションコホート
カテゴリ: analytics

### 短い定義 (TL;DR)

リテンションコホートは新規ユーザーが時間経過とともにどれだけリピートするかをコホート単位で表すグラフです。一般に W1・W4・W12 でのリテンション率が主要指標として使われます。

### 詳細解説

リテンションコホート (Retention Cohort) は、新規ユーザーをサービス開始時期 (週・月単位) でグループ化し、その後の何 % が時間経過後も戻ってきているかを表したコホート分析の特殊型です。リテンション率の計算式は「該当週に再訪したコホートユーザー数 ÷ コホートの新規ユーザー数 × 100%」で、グラフ上では右下に向かって減衰する三角形のヒートマップとして可視化されます。SaaS や EC で重視される指標で、Week1 リテンション・Week4 リテンション・Week12 リテンションが主要 KPI として使われ、業界平均は SaaS で W1: 70%・W4: 40%・W12: 25% 程度、ECで W1: 30%・W4: 15%・W12: 8% 程度です。リテンションが「フラット化」する (一定期間後にほぼ横ばいになる) サービスは Product-Market Fit 達成の証とされ、Andreessen Horowitz など著名 VC の投資判断指標としても用いられます。

### 実装例

- 週次リテンションヒートマップで W4 が 25% を割らないことを目標化する
- プッシュ通知導入前後で W4 リテンションを 20% → 35% に改善した実績を出す
- SaaS の有料プランで W12 リテンションを 50% 以上に維持する

### 出典

- [[GA4] リテンション レポート](https://support.google.com/analytics/answer/12922502)

---

## 保持ポリシー

URL: https://exbk.jp/glossary/retention-policy
読み: ほじポリシー
カテゴリ: storage

### 短い定義 (TL;DR)

保持ポリシー (retention policy) は、バックアップ世代をいつまで・何世代保持するかのルールです。日次 7 + 週次 4 + 月次 6 のような設定が定番で、restic forget で自動適用できます。

### 詳細解説

保持ポリシーは「無限に世代を保存するとストレージ枯渇する」「短すぎると災害から戻れない」のジレンマを解決する仕組みです。GFS (Grandfather-Father-Son) ローテーションが古典的で、restic / BorgBackup の --keep-daily / --keep-weekly / --keep-monthly オプションで実装できます。日次 7 + 週次 4 + 月次 6 = 17 世代相当のカバレッジを、重複排除で実容量は初回 × 1.2〜1.5 程度に抑えられます。

### 実装例

- restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
- 規制業界では年次 7 + 月次 12 + 週次 4 + 日次 7 など長期化
- 個人開発なら日次 7 のみで実用十分

---

## リテンション率

URL: https://exbk.jp/glossary/retention-rate
読み: リテンションリツ
カテゴリ: general

### 短い定義 (TL;DR)

リテンション率 (Retention Rate) は、ある期間に継続して利用してくれた顧客の割合です。解約率の裏返しで、1 - Churn Rate で算出され、リピート事業の中核指標です。PMF 達成の判定にも使われる重要指標です。

### 詳細解説

リテンション率は、顧客が継続的に商品サービスを使い続けている度合いを示す指標で、「期間終了時点の継続顧客数 ÷ 期間開始時点の顧客数」で算出します。月次リテンション 99% は年次で約88.6%、月次95% は年次で約54% と、わずかな差が長期で大きな差を生みます。Andreessen Horowitz が公開する「Cohort Analysis」では、N か月後のリテンション曲線が水平になる時点で「PMF 達成」と判断する基準が示されています。Facebook の有名な内部指標「7日以内に10人と友達になれば定着する」は、リテンション設計のベストプラクティスです。リテンションを上げる施策は、(1) オンボーディング最適化、(2) 利用習慣化のための通知設計、(3) コミュニティ機能、(4) アップデートの継続、の4本柱です。Mixpanel や Amplitude の Cohort 分析機能を使って、リリース月別のリテンション曲線を比較するのが標準実務です。

### 実装例

- アプリが7日後リテンション40%→60% に改善するため、初日の Aha Moment 体験を再設計します。
- EC サブスクが、3か月リテンション70%、6か月50% という曲線を公開し投資家に PMF を示します。
- BtoB SaaS が、月次ロジン率という代替指標でリテンションを測り、80% 未満顧客に CSM が介入します。

### 出典

- [Andreessen Horowitz - 16 Startup Metrics](https://a16z.com/16-startup-metrics/)

---

## リテンションレポート (Retention Report)

URL: https://exbk.jp/glossary/retention-report
読み: リテンションレポート
カテゴリ: analytics

### 短い定義 (TL;DR)

リテンションレポートは GA4 で新規ユーザーが時間経過とともにどれだけ再訪するかを可視化する標準レポートです。日次・週次のコホート別継続率と LTV 関連指標を確認できます。

### 詳細解説

リテンションレポート (Retention Report) は GA4 の標準レポートの 1 つで、新規ユーザーがサービス開始後にどれだけ継続して再訪してくるか (リテンション率) を分析するための機能です。標準で提供される指標は (1) 新規ユーザーとリピーターの構成比、(2) 日次のユーザー継続率 (Day0 〜 Day42)、(3) 週次のユーザー継続率 (Week0 〜 Week6)、(4) ユーザーエンゲージメント (滞在時間トレンド)、(5) 平均ライフタイム値 (Average Lifetime Value、簡易 LTV) で構成されます。グラフは右下に減衰するコホート曲線として表示され、フラット化する傾向があるかどうかで Product-Market Fit の達成度を判断できます。さらに細かい分析が必要な場合は「探索」セクションのコホートデータ探索を組み合わせて、流入チャネル別・地域別・ユーザー属性別のリテンションを比較できます。SaaS・アプリ・定期購入 EC など継続性が重要なビジネスで最重要レポートとなります。

### 実装例

- 新規ユーザーの Day7 リテンション 25% を 40% へ改善する
- 週次コホートで W2 リテンションの推移を四半期別に比較する
- Average Lifetime Value をチャネル別に比較し ROAS と紐付ける

### 出典

- [[GA4] リテンション レポート](https://support.google.com/analytics/answer/12922502)

---

## Retrieval

URL: https://exbk.jp/glossary/retrieval
読み: リトリーバル
カテゴリ: ai

### 短い定義 (TL;DR)

Retrieval (リトリーバル) は、RAG パイプラインの検索フェーズで、クエリに最も関連する文書を Vector DB / 全文検索から取得する処理です。RAG の精度はここで決まります。

### 詳細解説

Retrieval は RAG (Retrieval-Augmented Generation) の前段にあたり、ユーザークエリと意味的に近い文書 top-K を見つける処理です。手法は (1) Embedding ベクトル類似 (Dense)、(2) BM25 等の全文検索 (Sparse)、(3) ハイブリッド (Dense + Sparse) の組合せが主流。Re-ranking (Cohere Rerank / Cross-Encoder) で精度向上も可能。検索結果の質が悪いと LLM が hallucinate しやすくなるため、ここの設計が RAG の成否を決めます。

### 実装例

- クエリ Embedding → Pinecone で top-5 取得
- ハイブリッド検索 (BM25 + Dense)
- Cohere Rerank で精度向上

---

## リッチスニペット

URL: https://exbk.jp/glossary/rich-snippet
読み: リッチスニペット
カテゴリ: seo

### 短い定義 (TL;DR)

リッチスニペット (Rich Snippet) は、検索結果の通常の青リンク + 説明文に加えて、星評価・価格・FAQ・調理時間などの補足情報が表示される強化版の表示形式のことです。

### 詳細解説

リッチスニペットは、構造化データ (JSON-LD) を実装したページに対して Google が SERP 上で通常の検索結果より目立つ表示を与える機能です。2017年以降は「リッチリザルト (Rich Results)」という呼称が公式となり、リッチスニペットはその一形態という位置づけです。代表例は、レシピの調理時間・カロリー、製品の星評価・価格・在庫、FAQ のアコーディオン、HowTo のステップ画像、求人の勤務地・給与、イベントの日時・会場などです。リッチスニペット獲得により CTR が平均20-30% 向上するというデータがあり (Search Engine Journal 2024年調査)、特に EC・レシピ・求人サイトで効果が大きいです。表示の可否は Google のアルゴリズムが判断するため、構造化データを実装しても必ず表示されるとは限りません。

### 実装例

- Product スキーマで価格と星4.5を SERP に表示し CTR が35%向上した事例があります
- リッチリザルトテストで対象スキーマの認識を事前確認します
- Google のガイドライン違反 (虚偽の口コミ等) は手動ペナルティ対象です

### 出典

- [Google Search Central - リッチリザルト](https://developers.google.com/search/docs/appearance/structured-data/search-gallery)

---

## RLHF (Reinforcement Learning from Human Feedback)

URL: https://exbk.jp/glossary/rlhf
読み: アールエルエイチエフ
カテゴリ: ai

### 短い定義 (TL;DR)

RLHF (Reinforcement Learning from Human Feedback) は、人間の好みを報酬信号として LLM を強化学習で調整する手法です。ChatGPT / Claude が人間に好まれる応答を学んだ核心技術です。

### 詳細解説

RLHF は (1) 教師あり Fine-tuning で初期モデルを作る、(2) 人間が複数応答候補をランク付け、(3) ランクから報酬モデルを訓練、(4) PPO 等の強化学習で言語モデルを更新、の流れ。OpenAI が ChatGPT で大規模に適用し、Anthropic は派生形 (Constitutional AI / RLAIF) を採用しています。これにより「事実は正しいが攻撃的」「長文だが要点不明」といった問題を抑え、人間にとって心地よい応答にチューニングされています。

### 実装例

- ChatGPT の応答品質の核心技術
- Claude の Constitutional AI も派生
- DPO (Direct Preference Optimization) は簡略化された後継

---

## ROAS (ROAS: Return On Ad Spend (広告費用対効果))

URL: https://exbk.jp/glossary/roas
読み: ロアス
カテゴリ: ads

### 短い定義 (TL;DR)

ROAS は広告費 1 円あたりに得られた売上額の比率を示す指標です。『売上 ÷ 広告費 × 100%』で算出し、800% であれば広告費 1 万円で売上 8 万円という意味になります。EC ブランドの主要 KPI です。

### 詳細解説

ROAS (Return On Ad Spend) は広告経由の売上を広告費で割った比率で、広告投資の直接的な売上効率を測定する指標です。計算式は『広告経由売上 ÷ 広告費 × 100%』で、ROAS 100% は損益分岐ではなく『広告費と売上が同額』の意味なので注意が必要です。粗利率を考慮しないため、粗利率 30% の商材なら ROAS 333% で初めて広告費を回収できる計算になります。Google Ads の『目標 ROAS』入札はこの指標を直接最適化するスマート自動入札で、粗利を加味した『POAS (Profit on Ad Spend)』への進化形も注目されています。

### 実装例

- EC サイトで広告費 100 万円・売上 800 万円なら ROAS 800%
- 目標 ROAS 入札で機械学習に最適化を任せ ROAS を月次 600%→750% に改善
- 粗利率 25% の商材は ROAS 400% を超えないと利益が出ない

### 出典

- [Google Ads ヘルプ - 目標 ROAS について](https://support.google.com/google-ads/answer/6268637)
- [Meta Business Help - ROAS](https://www.facebook.com/business/help/677111092580844)

---

## robots.txt

URL: https://exbk.jp/glossary/robots-txt
読み: ロボッツテキスト
カテゴリ: seo

### 短い定義 (TL;DR)

robots.txt は、Web サイトのルート (/robots.txt) に配置するテキストファイルで、検索エンジンや AI クローラーに「どの URL をクロールしてよいか」を指示します。Robots Exclusion Protocol の標準仕様です。

### 詳細解説

robots.txt は1994年に提案され2022年に IETF RFC 9309 として正式標準化された、Web サイトとクローラーの取り決めを記述するテキストファイルです。サイトのルートディレクトリ (https://example.com/robots.txt) に配置し、User-agent (対象ボット) と Allow/Disallow (許可/拒否パス) を記述します。代表的な指示は、Sitemap: https://... (サイトマップ場所通知)、User-agent: GPTBot Disallow: / (OpenAI クローラー全拒否)、User-agent: * Disallow: /admin/ (管理画面の全ボット拒否) などです。注意点として、1) Disallow はクロールを拒否するだけでインデックス削除にはならない (noindex メタタグが必要)、2) 機密ファイルの隠蔽には不向き (robots.txt 自体が公開ファイル)、3) Google・Bing は遵守するが悪意のスクレイパーは無視する、点を理解する必要があります。

### 実装例

- GPTBot/CCBot を Disallow に追加し AI 学習データ利用を拒否する企業が増加中です
- Sitemap 指示を robots.txt に書くと Bing が自動検出します
- /admin/ や /private/ を Disallow してもクロール除外のみで非公開化はできません

### 出典

- [Google Search Central - robots.txt の概要](https://developers.google.com/search/docs/crawling-indexing/robots/intro)
- [RFC 9309 - Robots Exclusion Protocol](https://www.rfc-editor.org/rfc/rfc9309.html)

---

## ROI (広告) (ROI: Return On Investment (投資利益率))

URL: https://exbk.jp/glossary/roi-ads
読み: アールオーアイ
カテゴリ: ads

### 短い定義 (TL;DR)

ROI は広告投資から得られた利益と投資額の比率を示す指標です。『(売上 − 原価 − 広告費) ÷ 広告費 × 100%』で算出し、ROAS と異なり粗利を加味した『純利益ベース』の効率を表します。

### 詳細解説

ROI (Return On Investment) は広告投資の利益率を示す指標で、『(売上 − 原価 − 広告費) ÷ 広告費 × 100%』で計算します。ROAS が売上ベースなのに対し、ROI は原価を差し引いた利益ベースで効率を測るため、商材の粗利率まで考慮した本質的な投資判断ができます。例えば粗利率 30% で売上 100 万円、広告費 20 万円のキャンペーンは ROAS 500% と一見好調ですが、ROI 換算では (30 − 20) ÷ 20 × 100 = 50% となり、別事業に投資する代替案 (期待 ROI 100%) と比較して相対的に見劣りする可能性があります。

### 実装例

- 売上 100 万円・原価 70 万円・広告費 20 万円なら ROI 50%
- ROAS 500% でも粗利率 20% なら ROI は 0% (損益分岐)
- 粗利を加味した ROI で複数キャンペーンの優先度を決める

### 出典

- [Google Ads ヘルプ - ROI を測定する](https://support.google.com/google-ads/answer/14090)
- [Meta Business Help - ROI の計算](https://www.facebook.com/business/help)

---

## レスポンシブ検索広告 (RSA) (RSA: Responsive Search Ads)

URL: https://exbk.jp/glossary/rsa
読み: レスポンシブケンサクコウコク
カテゴリ: ads

### 短い定義 (TL;DR)

レスポンシブ検索広告 (RSA) は Google Ads の検索広告の標準フォーマットで、見出しを最大 15 個・説明文を最大 4 個入稿すると AI が組み合わせを動的に最適化して配信します。2022 年に拡張テキスト広告 (ETA) を置き換えました。

### 詳細解説

レスポンシブ検索広告 (RSA) は Google Ads が 2018 年に導入し、2022 年 6 月から検索広告の唯一の作成可能フォーマットとなった形式です。広告主は最大 15 個の見出し (各 30 文字)、最大 4 個の説明文 (各 90 文字) を入稿し、Google AI が検索クエリ・ユーザー属性・デバイスごとに最適な組み合わせ (見出し 3 個 + 説明文 2 個) を動的に表示します。広告強度 (Ad Strength) が『優良』『非常に優良』になるよう多様な訴求軸を入れるのがコツで、見出しを類似フレーズで埋めると最適化が効きにくくなります。

### 実装例

- 見出し 15 個 (USP・価格・実績・信頼性・行動喚起 等) と説明文 4 個を入稿
- 広告強度を『非常に優良』にして CTR を 30% 改善
- 見出しに『ピン留め』機能で必須キーワードを 1 番目に固定

### 出典

- [Google Ads ヘルプ - レスポンシブ検索広告](https://support.google.com/google-ads/answer/7684791)
- [Google Ads ヘルプ - 広告強度](https://support.google.com/google-ads/answer/9266845)

---

## rsync

URL: https://exbk.jp/glossary/rsync
読み: アールシンク
カテゴリ: storage

### 短い定義 (TL;DR)

rsync (アールシンク) はローカル/SSH 経由でファイル/ディレクトリを高速同期する Unix 系標準ツールです。差分転送と --link-dest オプションで効率的なバックアップが組めます。

### 詳細解説

rsync は 1996 年から存在する OSS で、ローカル間 / SSH 経由 / rsyncd デーモン経由でファイルツリーを同期します。チェックサムベースの差分転送で帯域節約、--link-dest オプションで「見た目フルバックアップ・実体差分」のスナップショット型バックアップを構築可能。restic / BorgBackup より低レベルですが、シンプルさと普遍性で広く使われ続けています。

### 実装例

- rsync -ah --link-dest=../latest src/ today/ で増分スナップショット
- rsync -avz user@host:/data /local-backup/ で SSH 経由バックアップ
- Mac の Time Machine の代替としてホームディレクトリ同期

### 出典

- [rsync Documentation](https://rsync.samba.org)

---

## S3 互換

URL: https://exbk.jp/glossary/s3-compatible
読み: エススリーごかん
カテゴリ: storage

### 短い定義 (TL;DR)

S3 互換は、Amazon S3 の REST API と互換性のあるオブジェクトストレージの総称です。Cloudflare R2 / MinIO / Backblaze B2 / Wasabi 等が該当し、既存 S3 クライアントがそのまま使えます。

### 詳細解説

S3 互換ストレージは AWS S3 の API (PUT/GET/LIST Object 等) を実装することで、aws-cli / boto3 / restic / rclone / Velero など S3 対応エコシステムをそのまま使えるようにしています。Cloudflare R2 は egress 無料が強み、Backblaze B2 は最安、Wasabi は予測可能な料金、MinIO は完全 OSS でセルフホスト可能。lock-in を回避しつつ価格最適化できるため、バックアップ用途で広く採用されています。

### 実装例

- restic --repository s3:https://<endpoint>/<bucket> で接続
- MinIO で社内 S3 互換ストレージ構築
- Velero で Kubernetes バックアップ

---

## SAML (Security Assertion Markup Language)

URL: https://exbk.jp/glossary/saml
読み: サムル
カテゴリ: general

### 短い定義 (TL;DR)

SAML は、企業向け SSO で広く使われる XML ベースの認証連携プロトコルで、IdP と SP の間で認証アサーションを交換します。SAML 2.0 が現役で OASIS が標準化しています。

### 詳細解説

SAML (Security Assertion Markup Language) は、企業/学術機関のシングルサインオン (SSO) で長く使われる XML ベースのプロトコルで、現行は SAML 2.0 (2005) です。Identity Provider (IdP) が認証アサーション (XML 文書 + XMLDSig 署名) を Service Provider (SP) に渡し、ユーザー識別と属性を伝達します。SP-initiated と IdP-initiated のフローがあり、企業内ポータルからのIdP-initiated SSOが現場では多用されます。XML 署名検証の弱点を突く XML Signature Wrapping (XSW) 攻撃が著名で、ライブラリの選定と検証実装の正しさが死活的に重要です。新規実装では OpenID Connect の方が軽量で推奨されますが、Okta・Azure AD・OneLogin・Google Workspace など多くのSaaSがSAML対応必須なため依然現役です。

### 実装例

- Okta IdP から Salesforce SP に SAML SSO
- metadata.xml で IdP/SP 間のメタデータ交換
- XML Signature Wrapping 対策にライブラリを最新化

### 出典

- [OASIS - Security Assertion Markup Language (SAML) v2.0](https://docs.oasis-open.org/security/saml/v2.0/)

---

## Schema.org

URL: https://exbk.jp/glossary/schema-org
読み: スキーマドットオーグ
カテゴリ: seo

### 短い定義 (TL;DR)

Schema.org とは、Google・Bing・Yahoo・Yandex の4社が共同開発した、Web ページの内容を機械可読な形で記述するための語彙 (ボキャブラリ) 仕様です。JSON-LD 形式で実装することで、検索エンジンや AI がページの意味を正確に理解できます。

### 詳細解説

2011年に Google・Bing・Yahoo の3社で発足し、後に Yandex が参加。現在800以上の Type (Article, Product, FAQPage, HowTo, Organization, Person, Event 等) と 1,400以上の Property を定義しています。実装形式は (1) JSON-LD (推奨)、(2) Microdata、(3) RDFa の3種があり、Google は JSON-LD を最も推奨しています。SEO 観点では、Google の Rich Results 表示 (FAQ アコーディオン、レシピカード、商品スター評価等) に直結します。AI 観点では、ChatGPT・Claude・Perplexity が schema.org マークアップを参照して情報構造を理解し、回答生成時の引用候補に加えることが報告されています。

### 実装例

- Article schema (記事ページ)
- FAQPage schema (FAQ セクション)
- Organization schema (会社情報)
- BreadcrumbList schema (パンくずリスト)

---

## スクロールマップ (Scrollmap)

URL: https://exbk.jp/glossary/scrollmap
読み: スクロールマップ
カテゴリ: general

### 短い定義 (TL;DR)

スクロールマップは、ページのどこまでユーザーがスクロールしたかをパーセンタイル分布で可視化する分析で、長文コンテンツの離脱地点特定に使われます。

### 詳細解説

スクロールマップは、ヒートマップの一種で「ページの各高さに何%のユーザーが到達したか」を縦方向グラデーションで可視化する分析手法です。NN/g の研究では一般的に 100% スクロール完遂率は20%前後、50% 到達は60〜70% という目安が知られ、Above the Fold (ファーストビュー) に最重要メッセージを配置する根拠になります。用途は (1) 長文LPで離脱が集中する高さを特定 (2) CTA 配置を到達率の高い位置に最適化 (3) フォームの離脱点検出 (4) 記事の読了率と SEO 滞在時間の相関調査 などです。スクロール 50% / 75% / 100% といった主要マイルストーンを GA4 イベントとしても計測すると、ヒートマップと数値の両面で評価できます。デバイス別の差が大きいため必ず分けて分析します。

### 実装例

- LP の CTA を 50% 到達点 (60〜70% ユーザー) に配置
- GA4 で scroll_50/75/100 イベントを取得しコホート分析
- 記事ページのスクロール完了率で読了率を測定

### 出典

- [NN/g - Scrolling and Attention](https://www.nngroup.com/articles/scrolling-and-attention/)

---

## Google Search Console (GSC)

URL: https://exbk.jp/glossary/search-console
読み: サーチコンソール
カテゴリ: analytics

### 短い定義 (TL;DR)

GSC (Google Search Console) は Google 検索におけるサイトのパフォーマンス・インデックス状況・技術的問題を分析できる無料ツールです。SEO 運用の必須ツールとして広く使われます。

### 詳細解説

GSC (Google Search Console) は Google が提供する無料の検索分析ツールで、自社サイトが Google 検索でどのように扱われているかを多角的に確認・改善するための SEO 運用必須ツールです。主な機能は (1) 検索パフォーマンスレポート (クエリ別のクリック数・表示回数・CTR・平均掲載順位)、(2) URL 検査ツール (個別 URL のインデックス状況確認・再クロール申請)、(3) カバレッジレポート (インデックス対象/対象外 URL の状態)、(4) サイトマップ管理 (XML サイトマップ送信)、(5) Core Web Vitals レポート (UX 指標の集計)、(6) モバイルユーザビリティ (スマホ表示の問題検出)、(7) 構造化データレポート (リッチリザルト対応状況)、(8) リンクレポート (内部・外部リンクの集計)、(9) 手動による対策 (ペナルティ通知)、です。GA4 と異なり「検索結果ページに表示された段階」のデータも取れるため、表示されたが選ばれなかった機会損失キーワードの発見ができます。データ保持期間は 16 ヶ月です。

### 実装例

- 検索パフォーマンスレポートで CTR 1% 未満のキーワードを抽出しタイトル改善する
- URL 検査でインデックス未登録のページを 1 件ずつ手動申請する
- サイトマップ送信で新規記事を 24 時間以内にインデックス登録させる

### 出典

- [Search Console ヘルプ](https://support.google.com/webmasters/answer/9128668)

---

## セルフホスト

URL: https://exbk.jp/glossary/selfhost
読み: セルフホスト
カテゴリ: saas

### 短い定義 (TL;DR)

セルフホスト (self-host) は SaaS を契約せずに自社サーバーで OSS を運用する選択です。コスト削減・データ主権確保・カスタマイズ自由度が利点で、運用工数とのトレードオフです。

### 詳細解説

セルフホストは「サブスク疲れ」と「ベンダーロック嫌悪」の文脈で 2020 年代から再評価されています。代表例は Nextcloud (Dropbox 代替)、Mastodon (Twitter 代替)、Ghost (Medium 代替)、Mattermost (Slack 代替) など。月数百円の VPS で個人〜小規模チームの全システムを賄えますが、TLS 証明書更新・OS パッチ・バックアップ運用などの工数が発生するため「自走可能な技術力 + 運用継続意志」が前提です。

### 実装例

- Nextcloud + Cloudflare R2 で Dropbox 代替 (月 920 円)
- Mastodon インスタンスで Twitter から独立
- Coolify / Dokku で PaaS 風の自前ホスティング

---

## セマンティック検索

URL: https://exbk.jp/glossary/semantic-search
読み: セマンティックケンサク
カテゴリ: seo

### 短い定義 (TL;DR)

セマンティック検索 (Semantic Search) は、キーワードの一致だけでなく、検索クエリの意味・文脈・意図を理解して関連性の高い結果を返す検索技術のことです。Google は2013年の Hummingbird 以降本格採用しています。

### 詳細解説

セマンティック検索は、自然言語処理 (NLP) と知識グラフを活用して検索クエリの意味を解釈し、文字列一致を超えた関連性で結果をランク付けする技術です。Google は2013年の Hummingbird アップデート、2015年の RankBrain (機械学習)、2018年の Neural Matching、2019年の BERT (双方向 Transformer)、2022年の MUM (Multimodal AI)、2024年の Gemini 統合と段階的にセマンティック理解を強化してきました。セマンティック検索により、a) 「お腹が痛い 病院」と「腹痛 内科 近く」が同じ意図と認識される、b) 文脈依存の代名詞 (「彼の妻」) を解釈、c) 同義語・関連エンティティを自動展開、d) 言語横断検索が可能、になりました。SEO 対応として、エンティティ重視のコンテンツ設計、トピッククラスタ構造、構造化データ実装が重要です。

### 実装例

- Hummingbird 以降「タクシー 安い」と「リーズナブル タクシー」が同義扱いになりました
- BERT 採用後は「to」「for」など前置詞も意味解釈の対象になりました
- セマンティック検索対応はエンティティ + 関連エンティティの網羅性が鍵です

### 出典

- [Google Blog - Understanding searches better than ever before (BERT)](https://blog.google/products/search/search-language-understanding-bert/)

---

## SERP (Search Engine Results Page)

URL: https://exbk.jp/glossary/serp
読み: サープ
カテゴリ: seo

### 短い定義 (TL;DR)

SERP (サープ) は、Google などの検索エンジンでキーワードを検索したときに表示される結果ページのことです。広告枠、自然検索10件、強調スニペット、画像、動画、AI 概要などが組み合わさって構成されます。

### 詳細解説

SERP は Search Engine Results Page の略で、ユーザーが検索エンジンに入力したクエリに対して返される結果一覧画面を指します。Google の SERP は2026年現在、AI 概要 (AI Overviews)、強調スニペット、ナレッジパネル、自然検索10件、ローカルパック、画像・動画タブ、関連質問 (PAA)、広告枠 (上下4枠ずつ) など20以上の要素で構成されます。SEO では、自社サイトを SERP の上位3位以内に表示させることでクリック率 (CTR) を最大化することが基本目標です。1位の平均 CTR は約27%、10位は約2.4% という Advanced Web Ranking のデータがあり、順位差が流入数を決定的に左右します。

### 実装例

- SERP の1位は CTR 約27% で、10位の10倍以上の流入を獲得します
- SERP に AI 概要が出ると自然検索のクリック率が30-40%低下する事例があります
- SERP 解析ツールで競合の構造化データ実装状況を確認できます

### 出典

- [Google Search Central - SERP features](https://developers.google.com/search/docs/appearance/visual-elements-gallery)

---

## サーバーサイドトラッキング (Server-Side Tracking (SST))

URL: https://exbk.jp/glossary/server-side-tracking
読み: サーバーサイドトラッキング
カテゴリ: ads

### 短い定義 (TL;DR)

サーバーサイドトラッキングは広告コンバージョンをブラウザではなく自社サーバー (または GTM サーバーサイドコンテナ) 経由で各広告プラットフォームに送信する手法です。ITP・ATT 対策と CV データの精度向上に必須となっています。

### 詳細解説

サーバーサイドトラッキング (Server-Side Tracking, SST) は web 広告のコンバージョンを、ブラウザ上の JavaScript ピクセルではなく、広告主のサーバー (または Google Tag Manager サーバーサイドコンテナ) から HTTPS API 経由で各広告プラットフォームに送信する手法です。Apple ITP、ATT、ブラウザの 3rd party Cookie 廃止によるシグナルロスに対抗するため、Meta CAPI、Google Enhanced Conversions、TikTok Events API、Pinterest Conversions API など主要媒体が対応しています。GTM サーバーサイドコンテナ (stape.io 等のホスティング含む) は導入の事実上のデファクトとなっています。

### 実装例

- GTM サーバーサイドコンテナを stape.io に構築し全媒体へ CAPI 送信
- 1st party サーバーで CV を集約し各広告 API に分配
- CV データに同意済 user_id を含めデータ品質を向上

### 出典

- [Google Tag Manager サーバーサイド ヘルプ](https://support.google.com/tagmanager/answer/9279134)
- [Meta Business - Conversions API](https://www.facebook.com/business/help/2041148702652965)

---

## セッション (Session)

URL: https://exbk.jp/glossary/session
読み: セッション
カテゴリ: analytics

### 短い定義 (TL;DR)

セッションは GA4 でユーザーがサイトと連続的にやり取りする 1 回の訪問単位です。デフォルトで 30 分間操作がないとセッション終了とみなされ、session_start イベントで新規セッションが開始します。

### 詳細解説

セッションは GA4 においてユーザーがサイトやアプリと連続的にやり取りする 1 回の訪問単位を指す概念で、操作のない状態が一定時間続くと終了とみなされます。GA4 のデフォルトのセッションタイムアウトは 30 分で、「管理 > データストリーム > イベントタイムアウト」から 5 分〜7 時間 55 分の範囲で変更できます。新規セッションの開始時には自動的に session_start イベントが発火し、固有の session_id (タイムスタンプベース) が付与されます。UA 時代と異なる重要な変更点として、(1) キャンペーン情報の変更でセッションが切れない、(2) 日付の変更でセッションが切れない、(3) 直帰率の代わりにエンゲージメント率を使う、の 3 点があります。1 セッション中の複数イベントには共通の ga_session_id が付与されるため、BigQuery で SQL を使えばセッション単位での詳細な行動分析が可能です。

### 実装例

- session_start イベント数を「セッション数」として PV と並べてレポート化する
- ECサイトでタイムアウトを 30 分から 1 時間に延長し購入完了までを 1 セッション化する
- ga_session_id でグルーピングしたセッション単位の購入経路分析を BigQuery で行う

### 出典

- [[GA4] セッションについて](https://support.google.com/analytics/answer/9191807)

---

## セッションクッキー (Session Cookie)

URL: https://exbk.jp/glossary/session-cookie
読み: セッションクッキー
カテゴリ: general

### 短い定義 (TL;DR)

セッションクッキーは、サーバー側のセッションIDをブラウザに保持させるCookieで、HttpOnly・Secure・SameSite 属性で防御を強化します。

### 詳細解説

セッションクッキーは、Webアプリにおいてログイン状態を維持するためにブラウザに発行されるCookieで、サーバー側のセッションストア (Redis / DB / Memcached) に保管された状態とCookie内のセッションIDが対応します。セキュリティ属性として (1) HttpOnly: JS から document.cookie で読めないようにしXSS対策 (2) Secure: HTTPS でのみ送信 (3) SameSite=Lax/Strict: クロスサイトでの自動送信を制限しCSRF対策 (4) Path / Domain: スコープ最小化 (5) __Host- / __Secure- prefix でセキュリティ強化、を組み合わせます。最近は Cookie 容量制限・3rd party Cookie廃止の流れがあり、サブドメイン跨ぎでは慎重な設計が必要です。JWT を Cookie に入れる場合も同じ属性ガードが必須です。

### 実装例

- Set-Cookie: session=xxx; HttpOnly; Secure; SameSite=Lax; Path=/
- __Host-session prefix で Secure + Path=/ + Domain なし強制
- Redis にセッション本体、Cookie はランダム ID のみ

### 出典

- [OWASP - Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)

---

## 平均セッション時間 (Avg. Session Duration)

URL: https://exbk.jp/glossary/session-duration
読み: ヘイキンセッションジカン
カテゴリ: analytics

### 短い定義 (TL;DR)

平均セッション時間は 1 セッションあたりの平均滞在時間を表す指標です。GA4 では「平均エンゲージメント時間」が後継指標となっており、フォアグラウンド時間のみで計算されます。

### 詳細解説

平均セッション時間 (Average Session Duration) は 1 セッションあたりの平均滞在時間を表す指標で、UA 時代に広く使われていました。GA4 では概念がリニューアルされ「平均エンゲージメント時間 (Average engagement time per session)」が後継指標となっています。両者の違いは計算方法にあり、UA の平均セッション時間が「セッション中の最初と最後のヒットの時間差」だったのに対し、GA4 の平均エンゲージメント時間は「ブラウザタブが前面に表示されていた累積秒数」のみを対象とします。これによりユーザーがタブを開いたまま放置した時間が除外され、より実態に近い滞在時間が分かるようになりました。一般的なベンチマークは BtoC で 1〜2 分、BtoB で 2〜3 分、ニュース系メディアで 3〜5 分程度ですが、サイトジャンルやコンテンツ深度によって大きく変わります。

### 実装例

- 平均エンゲージメント時間 2 分を目標にロングフォーム記事を設計する
- UA の平均セッション時間 3 分が GA4 で 1 分 30 秒になった理由を説明する
- Looker Studio で記事カテゴリ別の平均エンゲージメント時間を可視化する

### 出典

- [[GA4] エンゲージメント時間](https://support.google.com/analytics/answer/11109416)

---

## セッションレコーディング (Session Recording / Session Replay)

URL: https://exbk.jp/glossary/session-recording
読み: セッションレコーディング
カテゴリ: general

### 短い定義 (TL;DR)

セッションレコーディングは、個別ユーザーのページ操作 (クリック・スクロール・入力) を録画再生するUX分析手法で、ヒートマップでは見えない個別行動を把握できます。

### 詳細解説

セッションレコーディング (Session Replay) は、ユーザーの実際の操作を DOM スナップショット + イベントログとして記録し、後から動画のように再生できるUXリサーチ手法です。Microsoft Clarity・Hotjar・FullStory・LogRocket・Smartlook が代表ツールで、Clarity は無償で数百万セッションまで録画可能です。ヒートマップは集計値しか見えないのに対し、レコーディングは「特定ユーザーがなぜ離脱したか」「どのフォーム欄で詰まったか」「rage click (短時間連打) の原因」など、個別の文脈を理解できます。プライバシー対策が極めて重要で、(1) パスワード欄・クレカ欄・個人情報のマスク自動化 (2) IP 匿名化 (3) 同意取得 (4) 保管期間の最小化 (5) GDPR / 個人情報保護法 / 改正電気通信事業法 (Cookie 規制) への準拠 が必須です。

### 実装例

- Microsoft Clarity の rage click レポートで UX 課題発見
- 離脱ユーザーのフォーム入力をリプレイし詰まり箇所を特定
- クレカ欄・パスワード欄を data-clarity-mask で必ずマスク

### 出典

- [NN/g - Session Replay: Pros and Cons](https://www.nngroup.com/articles/session-replay/)

---

## SGE (Search Generative Experience)

URL: https://exbk.jp/glossary/sge
読み: エスジーイー
カテゴリ: seo

### 短い定義 (TL;DR)

SGE (Search Generative Experience) は、Google が2023年に発表した生成 AI 検索体験です。2024年5月に「AI Overviews (AI 概要)」として正式版がリリースされ、SERP 最上部に AI 生成の要約回答が表示されます。

### 詳細解説

SGE は Google が2023年5月の I/O で発表した生成 AI 統合検索のコードネームで、Search Labs での実験を経て2024年5月14日に「AI Overviews (日本では AI による概要)」として米国で正式版がローンチされ、2024年8月以降日本を含む100カ国以上に展開されました。SERP 最上部に Gemini モデルが生成した数百字の要約と引用元リンク3-5件が表示されます。SEO への影響として、1) 自然検索の CTR が30-40%減少 (Authoritas 2024年調査)、2) 引用元として選ばれるページは「権威性 + 構造化データ + 簡潔な定義文」を持つ、3) 強調スニペットや上位3位にランクインしているページが引用されやすい、という傾向があります。AI 引用獲得を狙う最適化を「LLMO」「GEO」と呼びます。

### 実装例

- AI 概要に引用されるとブランド認知が向上しますがクリック率は通常検索より低い傾向です
- EEAT が強いサイトほど AI 概要の引用元として選ばれやすいです
- FAQ 形式の構造化データは AI 概要の引用元候補に上がりやすいです

### 出典

- [Google Blog - Generative AI in Search](https://blog.google/products/search/generative-ai-google-search-may-2024/)

---

## ショッピング広告 (Shopping Ads (Google Shopping / Meta Shopping))

URL: https://exbk.jp/glossary/shopping-ads
読み: ショッピングコウコク
カテゴリ: ads

### 短い定義 (TL;DR)

ショッピング広告は商品画像・商品名・価格・店舗名をセットで表示する EC 向け広告フォーマットです。Google Merchant Center に商品データフィードを連携することで Google 検索・ショッピングタブ・YouTube に出稿できます。

### 詳細解説

ショッピング広告は Google Ads および Meta Ads が提供する EC 向け広告フォーマットで、商品画像・商品名・価格・店舗名をユニット状で表示します。Google ショッピング広告では Google Merchant Center に商品フィード (商品 ID・タイトル・価格・在庫状況・画像 URL 等) を毎日連携し、検索結果上部・ショッピングタブ・YouTube・Discover・Gmail に自動配信されます。Performance Max とも統合され、商品単位で ROAS 最適化される運用が標準です。Meta も Shop タブ + ピクセル + カタログ連携で類似機能を提供しています。

### 実装例

- Google Merchant Center に商品 1 万 SKU のフィードを毎日同期
- ショッピング広告で『ワイヤレスイヤホン』検索時にトップ 4 商品枠を獲得
- P-MAX に商品フィードを連携し ROAS 800% を達成

### 出典

- [Google Ads ヘルプ - ショッピング広告](https://support.google.com/google-ads/answer/2454022)
- [Google Merchant Center](https://support.google.com/merchants/)

---

## Google シグナル (Google Signals)

URL: https://exbk.jp/glossary/signal
読み: グーグルシグナル
カテゴリ: analytics

### 短い定義 (TL;DR)

Google シグナルは Google アカウントにログイン中で広告のパーソナライズを許可しているユーザーの匿名データを GA4 で活用する機能です。クロスデバイス分析や広告リマーケティングに使えます。

### 詳細解説

Google シグナルは、Google アカウントにログインしておりかつ広告のパーソナライズを許可しているユーザーの匿名・集計済みデータを GA4 が活用する機能です。これによりユーザー側で User-ID を実装していなくても、Google 全体のログインデータを使ってクロスデバイス・クロスプラットフォームのユーザー行動を一定精度で推定できます。さらに、GA4 で作成したオーディエンスを Google 広告に共有し、リマーケティング配信を行えるようになります。設定は「管理 > データ収集」から有効化するだけで簡単ですが、データのしきい値 (Free 版で約 50 ユーザー未満は非表示) によって地域別・属性別レポートで「(other)」表示が増える副作用があるため、小規模サイトでは表示精度とのトレードオフを検討する必要があります。GDPR 対応として同意モード v2 と組み合わせ、ユーザーが ad_user_data=denied の場合はシグナル送信を停止する実装が望まれます。

### 実装例

- Google シグナルを有効化し Google 広告でリマーケティングオーディエンスを配信する
- クロスデバイス分析で iOS と Android の購入を 1 ユーザーに統合する
- ユーザー属性レポートで年代・性別の推定値を取得する

### 出典

- [[GA4] Google シグナルを有効にする](https://support.google.com/analytics/answer/7532985)

---

## sitemap.xml

URL: https://exbk.jp/glossary/sitemap-xml
読み: サイトマップエックスエムエル
カテゴリ: seo

### 短い定義 (TL;DR)

sitemap.xml は、サイト内の全ページ URL とその更新日・優先度を一覧化した XML ファイルで、検索エンジンに効率的なクロールを促します。Google・Bing 共通仕様で sitemaps.org で標準化されています。

### 詳細解説

sitemap.xml は Google・Yahoo・MSN が2005年に共同制定したクロール支援フォーマットで、現在は sitemaps.org で仕様管理されています。各 URL に loc (URL)、lastmod (最終更新日)、changefreq (更新頻度)、priority (優先度0.0-1.0) を記述します。1ファイルあたり最大50,000 URL/50MB 制限があり、超過時はサイトマップインデックスで分割します。配置場所は通常ルート (https://example.com/sitemap.xml) で、Search Console と Bing Webmaster Tools で送信、robots.txt に Sitemap: ディレクティブで明示するのが標準実装です。動的サイトでは XML 自動生成プラグイン (WordPress なら Yoast SEO・RankMath) や Next.js の next-sitemap パッケージで運用します。lastmod の精度が高いほどクロール効率が上がるため、CMS の更新日と連動させる実装が推奨されます。

### 実装例

- Search Console にサイトマップ送信するとインデックス速度が2-3倍速まります
- 5万 URL 超のサイトはサイトマップインデックスで分割管理します
- lastmod を正確に出力することで再クロール頻度が最適化されます

### 出典

- [sitemaps.org - XML Sitemap Protocol](https://www.sitemaps.org/protocol.html)
- [Google Search Central - サイトマップの作成と送信](https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap)

---

## スマート自動入札 (Smart Bidding)

URL: https://exbk.jp/glossary/smart-bidding
読み: スマートジドウニュウサツ
カテゴリ: ads

### 短い定義 (TL;DR)

スマート自動入札は Google Ads の機械学習を使った入札戦略の総称で、目標 CPA・目標 ROAS・コンバージョン数の最大化・コンバージョン値の最大化などが含まれます。広告主が KPI を設定すれば AI が入札を自動最適化します。

### 詳細解説

スマート自動入札 (Smart Bidding) は Google Ads の機械学習による入札戦略で、目標コンバージョン単価 (tCPA)、目標 ROAS (tROAS)、コンバージョン数の最大化、コンバージョン値の最大化、拡張クリック単価 (eCPC) の 5 種類が代表です。AI はオークション時のデバイス、地域、時間帯、ユーザーの過去行動、リマケリスト、検索クエリ、OS、ブラウザなど数百の signal を加味して 1 オークションごとに入札を変動させます。学習には最低でも 30 日間 30〜50 CV のデータが必要とされ、初期は手動 CPC で CV 数を貯めてから移行するのが定石です。

### 実装例

- tCPA 5,000 円に設定して機械学習に最適化を任せる
- 学習期間中 (1〜2 週間) はパフォーマンスが乱高下するので予算固定
- コンバージョン値の最大化で粗利の高い CV により多く投資する

### 出典

- [Google Ads ヘルプ - スマート自動入札](https://support.google.com/google-ads/answer/7065882)
- [Google Ads ヘルプ - 入札戦略の概要](https://support.google.com/google-ads/answer/2459326)

---

## Smart Sync

URL: https://exbk.jp/glossary/smart-sync
読み: スマートシンク
カテゴリ: saas

### 短い定義 (TL;DR)

Smart Sync は Dropbox のオンデマンドダウンロード機能で、クラウド上のファイルがローカルでは見えるだけで、開いた時に初めて実体ダウンロードされる仕組みです。ローカル容量を節約できます。

### 詳細解説

Smart Sync (現在は Online-only / Local file の名称) は Dropbox Plus 以上のプランで利用可能で、100GB のクラウドストレージを 10GB のノート PC で扱えるようにします。Nextcloud 4.0 以降の Virtual File 機能とほぼ同等で、競合他社も同様の機能を持ちます。OneDrive Files On-Demand、Google Drive File Stream、Box Drive も類似機能。AI 業務で素材が大容量化する現代では事実上必須の機能です。

### 実装例

- ノート PC SSD 256GB で 2TB の Dropbox を扱う
- ファイル右クリックで「ローカルにのみ」「クラウドにのみ」切替
- Nextcloud 4.0+ の Virtual File が同等機能

---

## Snapchat Ads (Snapchat Ads (Snap Ads Manager))

URL: https://exbk.jp/glossary/snapchat-ads
読み: スナップチャットアズ
カテゴリ: ads

### 短い定義 (TL;DR)

Snapchat Ads は北米・欧州・インドで強い若年層向け SNS『Snapchat』に広告配信できるプラットフォームです。AR レンズ広告とフルスクリーン縦型動画が特徴で、Z 世代へのリーチに使われます。

### 詳細解説

Snapchat Ads は Snap Inc. が提供する広告配信プラットフォームで、Snapchat アプリ内のストーリーズ、Discover、スポットライト、AR レンズに広告を配信できます。代表的なフォーマットは Snap Ads (フルスクリーン 9:16 縦型動画 3〜10 秒)、Story Ads、Filter Lens Ads、AR Lens Ads (ブランドオリジナルの AR フィルター) です。デイリーアクティブユーザーの 75% が 13〜34 歳で、米国・カナダ・英国・仏・印度・中東で特に普及しています。日本市場ではユーザー数が少なく出稿事例は限定的です。

### 実装例

- 化粧品ブランドが AR Lens Ads でユーザーが自分にメイクを試せる体験広告を配信
- Z 世代向けアパレルが Snap Ads で 6 秒スキッパブル動画を出稿
- Snap Pixel で web コンバージョンを計測し ROAS 400% を実現

### 出典

- [Snapchat for Business](https://forbusiness.snapchat.com/)
- [Snap Ads Help Center](https://businesshelp.snapchat.com/)

---

## スナップショット

URL: https://exbk.jp/glossary/snapshot
読み: スナップショット
カテゴリ: storage

### 短い定義 (TL;DR)

スナップショット (snapshot) は、ある時点のシステム状態を保存し、後でその時点に戻せる機能です。VM・ストレージ・ファイルシステム・DB など多層で実装されます。

### 詳細解説

スナップショットは「ある時点のフリーズされた状態」を保存する技術の総称で、実装は大きく分けて Copy-on-Write 型 (ZFS / Btrfs / LVM) と論理ダンプ型 (pg_dump / mysqldump) に分かれます。Hostinger VPS のような IaaS のスナップショットは仮想ディスク全体の COW 型で、5〜30 分で復元可能。restic / BorgBackup は論理レイヤーのスナップショット (重複排除付き)。バックアップとは概念が異なり、「同じストレージ内の世代管理」に近いため、災害対策には別途オフサイトバックアップが必須です。

### 実装例

- Hostinger hPanel の VPS スナップショット (週次自動 + 手動 1 枠)
- restic snapshot list で過去のバックアップ世代一覧
- ZFS / Btrfs で OS レベル COW スナップショット

---

## 社会的証明

URL: https://exbk.jp/glossary/social-proof
読み: シャカイテキショウメイ
カテゴリ: general

### 短い定義 (TL;DR)

社会的証明 (Social Proof) は、他者の行動や判断を自分の意思決定の参考にする心理原則です。レビュー、利用者数、お客様の声などマーケティングの定番武器となっています。Robert Cialdini が体系化し、CVR 改善に直結します。

### 詳細解説

社会的証明は、Robert Cialdini が著書『Influence: The Psychology of Persuasion』(1984) で広めた心理原則の一つで、「不確実な状況で人は他者の行動を真似る」傾向を指します。BrightLocal の2024年調査では、消費者の98% が購入前にレビューを読み、76% が個人的推薦と同等に信頼すると回答しています。マーケ実装は、(1) お客様の声/事例 (ロゴ・写真・動画)、(2) 利用者数の表示 (例: 「累計100万人が利用」)、(3) リアルタイム購入通知 (Fomo Plugin など)、(4) Amazon/Google マップ星評価、(5) SNS フォロワー数表示、の5類型です。Booking.com の「現在37人が閲覧中」「直近24時間で12件予約」は社会的証明と FOMO の合わせ技で予約率を10-15% 押し上げています。BtoB なら導入企業ロゴ、BtoC なら著名人推薦が定石です。注意点は、捏造や誇張は景表法違反となるため、必ず実際のデータと許諾済み事例を使うことです。

### 実装例

- EC が商品ページに「過去30日で500人が購入」と表示、CVR を1.4倍に向上させます。
- BtoB SaaS が、導入企業ロゴ20社を LP ファーストビュー直下に配置し信頼性を担保します。
- アプリが、AppStore 4.8/5・10万件レビューを訴求しダウンロード率を2倍にします。

### 出典

- [Cialdini - Influence: Principles of Persuasion](https://www.influenceatwork.com/principles-of-persuasion/)

---

## Spam Score

URL: https://exbk.jp/glossary/spam-score
読み: スパムスコア
カテゴリ: seo

### 短い定義 (TL;DR)

Spam Score は、Moz が開発したドメインのスパムリスク評価指標で、0-17の数値で表されます。スコアが高いほど Google ペナルティを受ける可能性が高く、被リンク獲得時の精査基準になります。

### 詳細解説

Spam Score は Moz が開発したドメインのペナルティ予測指標で、Google からペナルティを受けた57万ドメインを機械学習で分析し、共通する27のスパム特徴を抽出して0-17の数値で評価します。代表的な特徴は、1) 短い TLD (.tk, .info)、2) ドメイン年数の若さ、3) リンク先の少なさ、4) コンテンツ量の少なさ、5) 被リンクの突然の急増、6) ホワイトリスト外の TLD、7) 連絡先情報の欠如、などです。Spam Score の活用は、a) 被リンク獲得時に候補サイトを精査 (Spam Score 30%超は避ける)、b) 自サイトの被リンクプロファイルを定期監査、c) Disavow Tool で低品質リンクを否認、です。Ahrefs にも類似の Domain Spam Score 指標があり、両ツールを組み合わせて精査するのが推奨されます。

### 実装例

- Spam Score 7以上のサイトからの被リンクは Disavow 対象の候補です
- PBN ドメインは Spam Score が10-15と高く検出されやすいです
- Ahrefs と Moz の両方でクロスチェックすると誤判定を減らせます

### 出典

- [Moz - Spam Score](https://moz.com/learn/seo/spam-score)

---

## SPF (Sender Policy Framework)

URL: https://exbk.jp/glossary/spf
読み: エスピーエフ
カテゴリ: general

### 短い定義 (TL;DR)

SPF (Sender Policy Framework) は、ドメインのDNSにメール送信を許可するサーバーIPを宣言し、なりすまし送信を防ぐ送信ドメイン認証技術です。RFC 7208で標準化されています。

### 詳細解説

SPF は、メール送信元のIPアドレスが正規のものかどうかを受信側サーバーが検証するための仕組みです。ドメイン管理者がDNSにTXTレコードで「v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all」のような形式で許可IPを宣言し、受信メールサーバーがエンベロープFromドメインのSPFレコードを参照して送信元IPと照合します。検証結果は pass / fail / softfail / neutral / none / temperror / permerror の7種に分類され、failの場合は受信拒否やSPAM判定の対象になります。SPFはエンベロープFromのみを検証するため、転送経路で破綻する弱点があり、DKIMやDMARC、ARCと組み合わせて運用されます。RFC 7208で最大10回のDNSルックアップ制限が定められており、超過するとpermerrorになります。

### 実装例

- exbk.jp の SPF: v=spf1 include:_spf.google.com ~all を Cloudflare DNS に設定
- メーリングリスト経由で転送されると SPF が softfail になり、DMARC で救済する
- SendGrid 経由で送信する場合は include:sendgrid.net を SPF に追加する

### 出典

- [RFC 7208 - Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208)

---

## SPF 検証エラー (SPF Fail / PermError)

URL: https://exbk.jp/glossary/spf-fail
読み: エスピーエフけんしょうエラー
カテゴリ: general

### 短い定義 (TL;DR)

SPF 検証エラーは、送信元IPが許可リストに含まれない (fail/softfail) かレコード自体に不備がある (permerror/temperror) 状態を指し、DMARC 連携で配信が拒否されます。

### 詳細解説

SPF 検証では7種の結果コード (pass / fail / softfail / neutral / none / temperror / permerror) が返り、fail と permerror が代表的なエラーです。fail は -all で明示拒否されたケース、softfail は ~all による警告レベル、permerror はDNSルックアップ10回超過や構文エラー、temperror はDNSタイムアウトです。DMARC ポリシーが reject だと SPF fail のメールは即拒否されます。よくある原因は「include の多重ネスト」「複数の SPF TXT レコード並立」「IPv6 の ip6 漏れ」「新規送信ベンダーの include 忘れ」などです。診断には dmarcian や mxtoolbox の SPF チェッカーを使い、DMARC レポートで失敗パターンを継続監視します。

### 実装例

- 新規 Mailchimp 連携で include:servers.mcsv.net を忘れて SPF fail
- include を5社以上書いて DNS lookup 11回 → permerror
- DMARC レポートで spf=fail が頻発する送信元を特定

### 出典

- [RFC 7208 Section 2.6 - Results](https://www.rfc-editor.org/rfc/rfc7208#section-2.6)

---

## SPF レコード (SPF Record)

URL: https://exbk.jp/glossary/spf-record
読み: エスピーエフレコード
カテゴリ: general

### 短い定義 (TL;DR)

SPF レコードは、ドメインのDNSに公開する送信許可IPやincludeを列挙したTXT形式のポリシー文字列で、「v=spf1 ... -all」の形式で記述します。

### 詳細解説

SPF レコードは、ドメインの DNS TXT レコードに「v=spf1 ip4:203.0.113.0/24 include:_spf.google.com -all」のように記述する送信許可ポリシーです。メカニズムには ip4 / ip6 / a / mx / include / exists / ptr (非推奨) があり、修飾子として all (-all=hardfail / ~all=softfail / ?all=neutral / +all=非推奨) が末尾に付きます。重要な制約として「DNSルックアップ回数10回以内」というRFC 7208の規定があり、include を多重ネストすると permerror になります。flatten ツールで include を展開する手段もありますが、IP変更時の保守性が悪化するためトレードオフがあります。1ドメインに複数のSPFレコードを書くことは禁止で、必ず1行に統合します。

### 実装例

- v=spf1 include:_spf.google.com include:sendgrid.net ~all
- Cloudflare DNS の TXT で SPF レコードを exbk.jp に設定
- DNS ルックアップ超過対策で SPF flatten サービスを使う

### 出典

- [RFC 7208 - Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208)

---

## Spotify 広告 (Spotify Ad Studio)

URL: https://exbk.jp/glossary/spotify-ads
読み: スポティファイ広告
カテゴリ: ads

### 短い定義 (TL;DR)

Spotify 広告は音楽ストリーミングサービス Spotify の無料プランユーザーに音声広告・動画広告を配信できるプラットフォームです。ながら聴取シーンでブランド想起を高める音声 CM が中心です。

### 詳細解説

Spotify 広告は Spotify Ad Studio から運用する広告配信プラットフォームで、Spotify 無料プランユーザーに音声広告 (Audio Ads 30 秒)、動画広告 (Video Takeover)、ディスプレイ広告 (Sponsored Sessions) を配信できます。リスナーが聴いている『ジャンル』『プレイリスト』『ムード (ワークアウト・集中・リラックスなど)』に基づくターゲティングが可能で、ジョギング中・運転中・作業中など特定の状況で接触するため、Podcast 広告と同様にブランド想起効果が高いとされます。日本市場でも 2020 年に正式ローンチし出稿が広がっています。

### 実装例

- ワークアウト系プレイリスト聴取者にプロテインの音声広告を配信
- 通勤時間帯の運転中リスナーに自動車保険の音声 CM を放映
- Spotify Pixel で配信後の web 訪問・購入を計測する

### 出典

- [Spotify Advertising](https://ads.spotify.com/)
- [Spotify Ad Studio](https://adstudio.spotify.com/)

---

## スプリント

URL: https://exbk.jp/glossary/sprint
読み: スプリント
カテゴリ: general

### 短い定義 (TL;DR)

スプリント (Sprint) は、アジャイル開発における1-4週間の固定期間の作業単位です。期間中に達成すべきゴールとタスクを決め、最終日にレビューと振り返りを行います。Scrum の中核単位として広く採用されています。

### 詳細解説

スプリントは Scrum フレームワークの中核概念で、1-4週間 (一般に2週間) の固定期間内に「動く成果物」を作る単位です。スプリントの構成要素は、(1) Sprint Planning (計画会議)、(2) Daily Standup (15分の進捗共有)、(3) Sprint Review (成果物デモ)、(4) Sprint Retrospective (改善振り返り)、の4つで、期間中はバックログのタスクを優先順に消化します。Google Ventures (現 GV) の Jake Knapp が考案した「Design Sprint」は、5日間で課題定義→アイデア→プロトタイプ→検証まで一気通貫で行う集中型スプリントで、Slack、Airbnb、Uber が実践しています。マーケでは2週間スプリントが主流で、広告クリエイティブの量産、LP の高速 A/B テスト、コンテンツ生産パイプラインに応用されています。スプリントの効果は、(1) 締め切りによる集中、(2) 短期検証の反復、(3) 心理的負荷の分散、です。注意点は、スプリント間の休息時間を確保しないと燃え尽き症候群 (Burnout) を招くため、週末の休暇厳守と Retro での負荷チェックが必須です。

### 実装例

- マーケチームが2週スプリントで広告クリエイティブ50本制作・配信・分析を1サイクルで回します。
- プロダクトチームが Scrum 2週間スプリントで新機能リリース、四半期で12機能を投入します。
- Design Sprint 5日間で新サービスのプロトタイプを作成、ユーザーテスト10名で仮説検証します。

### 出典

- [Scrum Guide](https://scrumguides.org/)

---

## SQL インジェクション (SQL Injection / SQLi)

URL: https://exbk.jp/glossary/sql-injection
読み: エスキューエルインジェクション
カテゴリ: general

### 短い定義 (TL;DR)

SQL インジェクションは、ユーザー入力をSQL文字列に連結することでデータベースに不正なクエリを実行させる攻撃で、対策はプリペアドステートメント (パラメータ化クエリ) です。

### 詳細解説

SQL インジェクション (SQLi) は、Webアプリがフォームやパラメータの入力値を SQL に直接連結することで、攻撃者が任意のSQLを差し込み、データ漏洩・改ざん・認証バイパス・OSコマンド実行に至る攻撃です。古典例は「' OR '1'='1」を入力欄に入れて WHERE 条件を真化するパターンや、UNION SELECT で他テーブルを抜くパターンです。対策はOWASPに従い (1) プリペアドステートメント / パラメータ化クエリの徹底 (2) ORM (Prisma / SQLAlchemy / ActiveRecord) の利用 (3) 最小権限原則のDBユーザー (4) WAFによる多層防御 (5) エラーメッセージの抽象化 が必須です。OWASP Top 10 では Injection カテゴリで何度も上位入りしてきた古典脅威です。Boolean-based / Time-based / Union-based / Error-based の手法分類があります。

### 実装例

- ?id=1' OR '1'='1 で全レコード取得を試みる古典攻撃
- Prisma の prisma.user.findUnique({ where: { id }}) でパラメータ化
- SQLi 検知のため WAF (Cloudflare / ModSecurity) を併用

### 出典

- [OWASP - SQL Injection Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html)

---

## SQL (Sales Qualified Lead (営業有望リード))

URL: https://exbk.jp/glossary/sql-sales-qualified
読み: エスキューエル
カテゴリ: general

### 短い定義 (TL;DR)

SQL (Sales Qualified Lead) は、営業部門が直接アプローチする価値ありと判定したリードです。MQL より購買確度が高く、商談化前の最終ステージに位置します。営業チームが直接コンタクトする最終ステージです。

### 詳細解説

SQL は、MQL を営業がレビューして「商談に進む価値あり」と判定したリードを指し、データベースの SQL 言語とは無関係の用語です。判定基準として米国の BANT (Budget 予算・Authority 決裁権・Need 必要性・Timeline 導入時期) や、近年は MEDDIC (Metrics 数値・Economic Buyer・Decision Criteria・Decision Process・Identify Pain・Champion) フレームを使う企業が多いです。HubSpot のベンチマークでは、平均的な BtoB SaaS で MQL→SQL 昇格率35%、SQL→受注率22%、つまり MQL 100件→SQL 35件→受注7-8件という流れが標準です。SQL ステージで重要なのは「24時間以内の初回接触」で、Inside Sales 専門会社の InsideSales.com の調査では、5分以内に電話した場合の接続率は30分後の100倍という結果も報告されています。SQL の質と量を最適化するため、Marketing と Sales の SLA (Service Level Agreement) を月次で見直す運用が定石です。

### 実装例

- BtoB SaaS が MQL を営業がレビューし、BANT 全項目クリアを SQL の必須条件と定義します。
- Inside Sales が SQL 化したリードに5分以内に電話、24時間以内に商談設定をルール化します。
- コンサル会社が、SQL ステージで予算500万円以上を確認できたリードのみフィールドセールスに引き渡します。

### 出典

- [HubSpot - MQL vs SQL](https://blog.hubspot.com/marketing/mql-sql)

---

## SRI (Subresource Integrity)

URL: https://exbk.jp/glossary/sri
読み: エスアールアイ
カテゴリ: general

### 短い定義 (TL;DR)

SRI (Subresource Integrity) は、外部 CDN から読み込むスクリプトやスタイルのハッシュ値を integrity 属性で検証し、改ざんを検知するW3C仕様です。

### 詳細解説

SRI は、HTML の script / link タグに integrity="sha384-..." 属性を付け、外部CDNから読み込むリソースのハッシュ値をブラウザが検証する仕組みです。CDN が侵害されてJSライブラリが改ざんされても、ハッシュ不一致でブラウザが実行を拒否します。書式は「integrity="sha384-Base64ハッシュ" crossorigin="anonymous"」で、SHA-256/384/512 をサポートします。crossorigin 属性は CORS と組み合わせて検証を有効化するために必要です。CSP の require-sri-for ディレクティブでサイト全体で SRI を強制することも可能です (廃止予定との議論あり)。MagecartのようなサプライチェーンSkimming攻撃の対策として効果的で、PCI DSS 4.0 でも要件 6.4.3 / 11.6.1 で言及されています。

### 実装例

- <script src="https://cdn.jsdelivr.net/.../jquery.min.js" integrity="sha384-..." crossorigin="anonymous"></script>
- PCI DSS 4.0 の決済ページで SRI を必須化
- openssl dgst -sha384 -binary | openssl base64 -A でハッシュ生成

### 出典

- [W3C - Subresource Integrity](https://www.w3.org/TR/SRI/)

---

## STP (Segmentation / Targeting / Positioning)

URL: https://exbk.jp/glossary/stp
読み: エスティーピー
カテゴリ: general

### 短い定義 (TL;DR)

STP は、市場細分化 (Segmentation)、ターゲティング (Targeting)、ポジショニング (Positioning) の3ステップで戦略を設計するフレームワークです。Philip Kotler が体系化しました。

### 詳細解説

STP は Philip Kotler が広めたマーケティング戦略立案の王道フレームワークです。第一段階の Segmentation では、市場全体を地理・人口統計・心理・行動の4軸で細分化します。第二段階の Targeting では、自社が狙う有望セグメントを SGCF (規模・成長性・競合・適合度) で評価し選定します。第三段階の Positioning では、選んだターゲットに対して競合と差別化された独自の位置を顧客の頭の中に作ります。例えば、ユニクロは「ファッションを問わず全世代向け」のセグメント、「品質と価格を両立したい合理的消費者」のターゲット、「LifeWear (究極の普段着)」のポジショニングという STP で世界展開しています。STP は4P や4C の上位概念として位置付けられ、これを誤ると後工程のすべてが歪むため、年1回は見直すのが推奨されます。STP のサイクルは、市場環境変化や新規競合参入に応じて随時見直す動的フレームワークとして運用するのが望ましく、PEST 分析や3C 分析と併用すると精度が高まります。

### 実装例

- 化粧品メーカーが、年齢・肌悩み・価格帯でセグメントし、敏感肌30代をターゲットに「皮膚科医監修」とポジショニングします。
- BtoB SaaS が、業種・規模で200セグメントに分け、上位5セグメントに営業リソースの80%を集中投下します。
- 新規飲食店が、半径2km の人口データから「ファミリー層」をターゲットに、「子連れ歓迎の本格イタリアン」と独自ポジションを取ります。

### 出典

- [Kotler & Keller - Marketing Management 15th edition](https://www.pearson.com/en-us/subject-catalog/p/marketing-management/P200000005847)

---

## 構造化データ

URL: https://exbk.jp/glossary/structured-data
読み: コウゾウカデータ
カテゴリ: seo

### 短い定義 (TL;DR)

構造化データ (Structured Data) は、Web ページのコンテンツに意味的なメタデータを付与し、検索エンジンや AI が内容を正確に理解できるようにする標準化された記述方法のことです。schema.org の語彙が業界標準です。

### 詳細解説

構造化データは、HTML 文書内に意味的メタデータを埋め込む技術の総称で、schema.org の語彙を JSON-LD・microdata・RDFa のいずれかの構文で記述します。Google・Bing・Yandex が共同で2011年に schema.org を立ち上げ、現在800以上のスキーマタイプ (Article、Product、Organization、Person、Event、Recipe、LocalBusiness、JobPosting 等) が定義されています。SEO 効果は、a) リッチリザルト獲得 (CTR 20-30%向上)、b) Knowledge Graph への登録、c) AI 検索 (Perplexity、AI Overviews) の引用元になりやすい、d) 音声検索の対象になる、です。実装は Google が JSON-LD を強く推奨し、Yoast SEO・RankMath・Schema Pro 等のプラグインや Next.js の next-seo パッケージで自動化できます。検証は Google の「リッチリザルトテスト」と「スキーママークアップバリデータ」で行います。

### 実装例

- 全主要ページに Organization、Article、BreadcrumbList を実装するのが標準構成です
- AI 検索の引用元獲得には FAQPage、Article の構造化データが最重要です
- リッチリザルトテストで未対応エラー0件を維持するのが運用目標です

### 出典

- [Google Search Central - 構造化データの仕組み](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data)
- [schema.org](https://schema.org/)

---

## 同期ロック

URL: https://exbk.jp/glossary/sync-lock
読み: どうきロック
カテゴリ: infra

### 短い定義 (TL;DR)

同期ロックは、ファイル同期中の排他制御で取得される一時的な権利です。複数クライアントの並行書込みでデータ破損を防ぐために必須ですが、肥大化すると逆に同期が止まります。

### 詳細解説

Nextcloud は WebDAV PUT / MKCOL のたびに該当パスのロックを取得し、処理完了後にリリースします。負荷集中時にロック取得 → リリースのリクエストが連鎖し、DB ロック (oc_file_locks) のテーブルが詰まると新規ロックが取れなくなり、同期が完全停止します。Redis ロックバックエンドに切り替えれば、レスポンス速度の桁違いの違いで詰まりにくくなります。本シリーズの実例では 4 台のクライアントが並行同期して 663,899 件のロックエントリが滞留しました。

### 実装例

- ファイル PUT 時に PROPPATCH で LOCK を発行
- DB ロック使用時は秒間数百ロックで詰まる
- Redis 化後は数千 RPS まで耐える

---

## System prompt

URL: https://exbk.jp/glossary/system-prompt
読み: システムプロンプト
カテゴリ: ai

### 短い定義 (TL;DR)

System prompt (システムプロンプト) は、LLM の対話で最初に与える 'AI への指示書' で、ユーザーには見せず内部で挙動を制御します。ロール・トーン・制約を定義します。

### 詳細解説

System prompt は OpenAI / Anthropic API の messages 配列で role: 'system' として渡される最初のメッセージで、AI の人格・能力・制約・出力形式を定義します。'あなたは医療相談アシスタントです。診断はせず、医師受診を推奨してください' のような内容。User message より優先度が高く設定されており、ジェイルブレイク対策にも使われます。Anthropic では system パラメータで別途指定する API 仕様も。

### 実装例

- 「あなたは経験 10 年のマーケターです」でロール固定
- 「日本語で回答」「JSON 形式で」等の出力制約
- Claude Code の CLAUDE.md も実質 system prompt

---

## 目標コンバージョン単価 (tCPA) (tCPA: Target Cost Per Acquisition)

URL: https://exbk.jp/glossary/t-cpa
読み: モクヒョウコンバージョンタンカ
カテゴリ: ads

### 短い定義 (TL;DR)

目標 CPA (tCPA) はスマート自動入札の 1 種で、設定した CPA 目標値で CV 数を最大化するよう機械学習が入札を自動調整する戦略です。BtoB リード獲得や EC サイトで主流の入札方式となっています。

### 詳細解説

目標 CPA (Target CPA, tCPA) は Google Ads・Meta Ads などのスマート自動入札で、広告主が設定した CPA 目標値の達成を狙って AI が入札を自動最適化する方式です。目標 CPA を 5,000 円に設定すると、機械学習がオークション参加時の各種シグナル (デバイス・地域・時間帯・過去行動・検索クエリ・リマケリスト等) を加味して、平均 CPA が 5,000 円付近に収まるよう入札を自動調整します。低めに設定しすぎると Imp が出ず学習が進まないため、損益分岐 CPA の 80% 程度から始めて段階的に下げるのが定石です。学習には最低 30 日 30〜50 CV が必要です。

### 実装例

- tCPA 5,000 円で月 200 CV を獲得しつつ平均 CPA を 4,800 円に着地
- tCPA を急に 50% 下げると配信量が激減 → 段階的調整が必須
- 学習期間中は CPA が一時的に目標値を上回ることを許容する

### 出典

- [Google Ads ヘルプ - 目標コンバージョン単価](https://support.google.com/google-ads/answer/6268632)
- [Meta Business - 入札戦略](https://www.facebook.com/business/help/430291176997542)

---

## 目標 ROAS (tROAS) (tROAS: Target Return On Ad Spend)

URL: https://exbk.jp/glossary/t-roas
読み: モクヒョウロアス
カテゴリ: ads

### 短い定義 (TL;DR)

目標 ROAS (tROAS) はスマート自動入札の 1 種で、設定した ROAS 目標値でコンバージョン値を最大化するよう機械学習が入札を自動調整する戦略です。EC サイトや単価が大きい商材で主流の入札方式です。

### 詳細解説

目標 ROAS (Target ROAS, tROAS) は Google Ads のスマート自動入札の 1 種で、広告主が設定した ROAS 目標 (例: 800%) を維持しながらコンバージョン値 (売上) を最大化する方式です。CV ごとに異なる売上額を入稿しておくと、機械学習が『ROAS 800% 以上が見込めるオークションでは強気入札、見込めないオークションでは弱気入札』と動的調整します。tCPA が CV 件数を最大化するのに対し、tROAS は CV 値 (=売上) を最大化するため、商品単価のばらつきが大きい EC サイトに最適です。学習には 30 日 30〜50 CV、可能なら CV 値の入稿が必須です。

### 実装例

- tROAS 800% で売上 800 万円・広告費 100 万円を達成
- EC サイトの商品単価別 CV 値を Google Ads にフィード送信
- tROAS を 600%→700% に引き上げ配信量を絞り利益率を改善

### 出典

- [Google Ads ヘルプ - 目標 ROAS について](https://support.google.com/google-ads/answer/6268637)
- [Google Ads ヘルプ - 目標 ROAS の設定](https://support.google.com/google-ads/answer/9244827)

---

## タグ (GTM) (Tag)

URL: https://exbk.jp/glossary/tag
読み: タグ
カテゴリ: analytics

### 短い定義 (TL;DR)

タグは GTM で実際に発火する処理単位です。GA4・Google 広告・カスタム HTML など 80 種類以上のタグテンプレートが用意され、トリガーで指定された条件で実行されます。

### 詳細解説

タグ (Tag) は GTM において実際にウェブページ上で実行される処理の単位で、トリガーで指定された条件が満たされたときに発火します。GTM では Google が公式にメンテナンスする 80 種類以上のタグテンプレートが標準で用意されており、代表的なものとして (1) GA4 設定タグ、(2) GA4 イベントタグ、(3) Google 広告コンバージョントラッキング、(4) Google 広告リマーケティング、(5) Floodlight、(6) カスタム HTML タグ (任意の JavaScript を実行)、(7) カスタム画像タグ、などがあります。さらにコミュニティが提供するテンプレートが「コミュニティテンプレートギャラリー」で公開されており、Meta Pixel・LinkedIn Insight Tag・X (Twitter) Pixel・Hotjar・Intercom など主要マーケティングツールが網羅されています。タグの発火順序や同時発火数を制御する「タグの順序付け」機能、特定タグが先に発火しないと別タグが発火しない依存関係を設定する機能もあり、複雑な計測要件にも対応できます。

### 実装例

- GA4 イベントタグで purchase をデータレイヤー値とともに送信する
- Meta Pixel テンプレートで標準イベント Lead を発火させる
- カスタム HTML タグで自社アンケートウィジェットの初期化スクリプトを実行する

### 出典

- [Tag Manager タグの追加](https://support.google.com/tagmanager/answer/6107167)

---

## ターゲティング

URL: https://exbk.jp/glossary/targeting
読み: ターゲティング
カテゴリ: general

### 短い定義 (TL;DR)

ターゲティング (Targeting) は、市場細分化したセグメントの中から、自社が狙うべき顧客層を選定するプロセスです。STP 戦略の中核を担い、リソース集中の方向性を決定します。勝てる市場を選ぶ意思決定そのものです。

### 詳細解説

ターゲティングは、Philip Kotler の STP モデル (Segmentation → Targeting → Positioning) における第二段階で、市場全体ではなく勝てる戦場を選ぶ意思決定です。選定基準としては、市場規模 (Sales)、成長性 (Growth)、競合状況 (Competition)、自社適合度 (Fit) の4軸で評価する SGCF フレームが定番です。BtoB SaaS の場合、「従業員50-300名・SaaS 導入経験あり・年商10-100億円」のような切り口でターゲティングします。たとえば HubSpot は創業初期に「中小企業のインバウンド型マーケティング担当者」に絞り込み、結果として2024年時点で年商25億ドル超の企業に成長しました。ターゲティングを誤ると広告費が分散して CAC が高騰するため、最低でも3か月ごとに有効性を検証する運用が推奨されます。

### 実装例

- 創業期の SaaS が「IT リテラシーの高いスタートアップCTO」に絞り、その層の集まる勉強会で集客を集中します。
- ECブランドが、購入履歴から「年6回以上購入・客単価1万円超」のロイヤル顧客にだけ新作先行案内を送ります。
- 美容クリニックが「30代女性・美容医療経験あり・東京山手線エリア」を狙い、Instagram 広告と JR 駅広告を併用します。

### 出典

- [Kotler & Keller - Marketing Management 15th edition](https://www.pearson.com/en-us/subject-catalog/p/marketing-management/P200000005847)

---

## Temperature

URL: https://exbk.jp/glossary/temperature
読み: テンパラチャー
カテゴリ: ai

### 短い定義 (TL;DR)

Temperature (テンパラチャー) は LLM の出力ランダム性を制御する 0〜2 のパラメータです。0 に近いほど決定論的、高いほど創造的・多様な出力になります。

### 詳細解説

Temperature は Softmax 関数の温度パラメータで、低いほど確率分布が尖って(=最頻出トークンが選ばれやすく)、高いほど平坦(=多様な出力)になります。0 (完全決定論) はコード生成や事実回答、0.7 (デフォルト多め) は対話、1.0 以上はクリエイティブライティングや多様性が必要なタスク向け。OpenAI / Anthropic API ともに API パラメータで指定可能。

### 実装例

- コード生成: temperature=0
- ブログ記事生成: temperature=0.7
- ブレストアイデア出し: temperature=1.2

---

## TikTok Ads (TikTok Ads Manager)

URL: https://exbk.jp/glossary/tiktok-ads
読み: ティックトックアズ
カテゴリ: ads

### 短い定義 (TL;DR)

TikTok Ads は ByteDance が運営するショート動画 SNS『TikTok』に広告を配信できるプラットフォームです。10〜30 代の若年層リーチと、UGC 風クリエイティブによる高エンゲージメントが特徴です。

### 詳細解説

TikTok Ads は TikTok For Business が提供する広告配信プラットフォームで、TikTok アプリのおすすめフィード (For You ページ) に動画広告を差し込む形が基本です。フォーマットは In-Feed Ads、TopView、Branded Hashtag Challenge、Spark Ads (オーガニック投稿のブースト) などがあり、特に Spark Ads は『広告らしくない広告』として CTR が高い傾向にあります。最低出稿額はキャンペーンレベル 1 日 50 ドル、広告グループレベル 20 ドル相当が目安で、入札は CPC・CPM・oCPM・CPV から選択可能です。

### 実装例

- 9:16 縦型動画 15 秒の Spark Ads でオーガニック投稿をブーストする
- In-Feed Ads で美容アプリのインストール CPI 200 円を達成する
- TikTok Pixel + Events API でコンバージョン計測を実装する

### 出典

- [TikTok Ads Manager](https://ads.tiktok.com/)
- [TikTok For Business](https://www.tiktok.com/business/)

---

## TLS (Transport Layer Security)

URL: https://exbk.jp/glossary/tls
読み: ティーエルエス
カテゴリ: infra

### 短い定義 (TL;DR)

TLS (Transport Layer Security) は HTTPS の暗号化を担うプロトコルです。SSL の後継で、クライアント・サーバー間の通信を盗聴・改竄から守ります。Web サーバーには必須の設定です。

### 詳細解説

TLS 1.2 / 1.3 が現役で、TLS 1.0 / 1.1 は脆弱性があり廃止されています。TLS 1.3 は 2018 年に RFC 8446 で標準化され、ハンドシェイク高速化と暗号スイートのシンプル化が進みました。証明書は Let's Encrypt で 90 日間有効のものを無料取得でき、certbot や Traefik / Caddy が自動更新を担当します。Nextcloud / WordPress 等の本番運用では HTTPS 化が必須です (SEO 上の優位性、ブラウザの混在コンテンツ警告回避のため)。

### 実装例

- Let's Encrypt で 90 日有効の証明書を無料発行
- Traefik で自動更新 (実装ゼロで HTTPS 化)
- TLS 1.3 で HTTP/3 化への布石

### 出典

- [RFC 8446 (TLS 1.3)](https://www.rfc-editor.org/rfc/rfc8446)

---

## TLS-RPT (SMTP TLS Reporting)

URL: https://exbk.jp/glossary/tls-reporting
読み: ティーエルエスアールピーティー
カテゴリ: general

### 短い定義 (TL;DR)

TLS-RPT (SMTP TLS Reporting) は、メール配送のTLS失敗を集約レポートとして受信する仕組みです。RFC 8460で規定され、MTA-STSやDANEの運用監視に利用されます。

### 詳細解説

TLS-RPT は、送信側 MTA が受信側に対してTLS接続の成功・失敗を集計し、JSONレポートとして送信ドメインに送る仕組みです。DNS の _smtp._tls.example.com TXT レコードに「v=TLSRPTv1; rua=mailto:tlsrpt@example.com」または rua=https:// で報告先を指定します。レポートには failure-details (証明書期限切れ、STARTTLS不可、検証エラーなど) が含まれ、MTA-STS や DANE 運用時のトラブル検知に必須です。Postmark・URIports・Valimail などのレポート解析サービスを使うとXML/JSONを可視化できます。日次集計で送信元 MTA・MX ホスト・失敗理由が分かるため、配送品質の改善に直結します。

### 実装例

- _smtp._tls.exbk.jp に v=TLSRPTv1; rua=mailto:tlsrpt@exbk.jp を設定
- Google Workspace から TLS-RPT JSON が日次で配信される
- URIports で TLS-RPT を可視化し証明書期限切れ MX を検出

### 出典

- [RFC 8460 - SMTP TLS Reporting](https://www.rfc-editor.org/rfc/rfc8460)

---

## TOFU/MOFU/BOFU (Top / Middle / Bottom of Funnel)

URL: https://exbk.jp/glossary/tofu-mofu-bofu
読み: トフ・モフ・ボフ
カテゴリ: general

### 短い定義 (TL;DR)

TOFU/MOFU/BOFU は、ファネルを上層 (認知)、中層 (検討)、下層 (決定) の3段階に分類する用語です。各段階に応じたコンテンツと KPI を設計するために使われます。コンテンツ設計の基本マッピングとして使われます。

### 詳細解説

TOFU/MOFU/BOFU は、HubSpot をはじめとするインバウンドマーケティング業界で標準化された用語で、ファネルを Top of Funnel (認知段階)、Middle of Funnel (比較検討段階)、Bottom of Funnel (購入決定段階) の3層で考えます。TOFU では「課題に気づかせるブログ記事」「業界レポート」、MOFU では「ホワイトペーパー」「ウェビナー」「比較ガイド」、BOFU では「事例集」「無料トライアル」「個別相談」というコンテンツが定石です。HubSpot のデータでは、TOFU から BOFU への平均通過率は約2-5%、TOFU から商談化までの平均期間は BtoB で60-90日とされています。各段階の KPI も、TOFU=訪問数とリード数、MOFU=MQL 化率、BOFU=商談化率と受注率と分けて設計します。コンテンツマーケティングの設計図として、TOFU/MOFU/BOFU を縦軸、ペルソナを横軸に置いた「コンテンツマトリクス」を作るのが推奨されます。

### 実装例

- BtoB SaaS が、TOFU で SEO 記事、MOFU でウェビナー、BOFU で無料トライアル CTA を出し分けます。
- EC が、TOFU で Instagram リール、MOFU で比較記事、BOFU でクーポン付きリマインドメールを設計します。
- コンサル会社が、TOFU で書籍出版、MOFU で診断ツール、BOFU で個別相談という3段で見込み客を育成します。

### 出典

- [HubSpot - TOFU MOFU BOFU Content](https://blog.hubspot.com/marketing/tofu-mofu-bofu)

---

## Tokenizer

URL: https://exbk.jp/glossary/tokenizer
読み: トークナイザー
カテゴリ: ai

### 短い定義 (TL;DR)

Tokenizer (トークナイザー) は、LLM への入力テキストを 'トークン' という最小単位に分割するモジュールです。日本語は 1 文字 ≈ 1〜3 トークン、英語は 1 単語 ≈ 1.3 トークンが目安です。

### 詳細解説

Tokenizer は BPE (Byte-Pair Encoding) や SentencePiece などのアルゴリズムで実装され、LLM が処理する最小単位を生成します。OpenAI tiktoken / Anthropic claude-tokens 等のライブラリでローカル計算可能。日本語は単語境界が曖昧なため英語より 2〜3 倍のトークン数になりがちで、API コストや context window の消費に直結します。OpenAI o200k / cl100k などモデルごとに異なる tokenizer を使います。

### 実装例

- 「東京タワー」≒ 5 トークン (cl100k_base)
- OpenAI tiktoken で事前トークン数計算
- API コスト計算の基礎単位

---

## Tool use

URL: https://exbk.jp/glossary/tool-use
読み: ツールユース
カテゴリ: ai

### 短い定義 (TL;DR)

Tool use (ツールユース) は、LLM が外部ツール (関数・API・Web 検索) を呼び出して情報を取得・操作する能力です。Function calling とほぼ同義で、Anthropic は Tool use の呼称を使います。

### 詳細解説

Tool use は LLM が「自分の知識だけでは答えられない」と判断したとき、外部のツールを呼び出して情報を補完する仕組みです。Anthropic Claude では tools パラメータに JSON Schema を渡し、LLM は tool_use ブロックで呼び出し意図を返します。OpenAI の Function calling と機能的に同等。MCP (Model Context Protocol) はこれを業界標準化したプロトコルで、LLM ベンダー横断で同じツールを使い回せます。

### 実装例

- Claude Code の Bash / Edit / Read 等は全て tool use
- MCP サーバーが提供するツール群
- Web 検索ツール (Anthropic native search 等)

### 出典

- [Anthropic Tool Use Documentation](https://docs.anthropic.com/en/docs/build-with-claude/tool-use)

---

## Top-p

URL: https://exbk.jp/glossary/top-p
読み: トップピー
カテゴリ: ai

### 短い定義 (TL;DR)

Top-p (Top-p sampling, nucleus sampling) は LLM の出力候補を確率累積 p% に絞ってサンプリングする手法です。Temperature と組み合わせて出力ランダム性を制御します。

### 詳細解説

Top-p は累積確率が p (例 0.9) になるまでの候補からサンプリングする手法で、temperature と独立して品質を制御できます。一般に temperature か top-p のどちらかを変えるだけで十分で、両方同時にいじると挙動が予測しにくくなります。OpenAI / Anthropic API では top_p 引数で指定。デフォルトは 1.0 (制限なし)。

### 実装例

- top_p=0.9 で上位 90% に絞る (低品質候補を除外)
- temperature と択一で使うのが推奨
- コード生成では top_p=0.5 で安定化

---

## トピッククラスター

URL: https://exbk.jp/glossary/topic-cluster
読み: トピッククラスター
カテゴリ: seo

### 短い定義 (TL;DR)

トピッククラスター (Topic Cluster) は、1つの中核ページ (ピラーページ) と関連する複数の周辺記事 (クラスターページ) を内部リンクで結びつけるコンテンツ戦略のことです。HubSpot が2017年に提唱しました。

### 詳細解説

トピッククラスターは HubSpot が2017年に提唱したコンテンツ SEO モデルで、Google のセマンティック検索進化に対応する戦略です。構造は、a) ピラーページ (Pillar Page): 大トピックを網羅的に扱う3000-5000字の中核記事、b) クラスターページ (Cluster Pages): ピラーの個別サブトピックを深掘りする10-30本の記事、c) 双方向の内部リンク: クラスター→ピラー、ピラー→クラスター、です。例として、ピラー「SEO 完全ガイド」に対しクラスター「内部対策」「外部対策」「テクニカル SEO」「キーワード調査」をぶら下げます。効果は、1) Google にトピックの専門性をシグナリング、2) 関連キーワード群で順位上昇、3) 内部リンクで PageRank 集約、4) ユーザーの回遊率向上、5) コンテンツ管理の体系化、です。実装には、Screaming Frog で内部リンク可視化、HubSpot CMS のトピック機能などを使います。

### 実装例

- ピラー1本にクラスター20本を内部リンクすると関連 KW 群で順位が平均10位上昇します
- Wikipedia は典型的なトピッククラスター構造で SEO の理想形です
- 孤立したクラスター記事を作らずピラーから3クリック以内に配置します

### 出典

- [HubSpot - Topic Clusters: The Next Evolution of SEO](https://blog.hubspot.com/marketing/topic-clusters-seo)

---

## TOTP (Time-based One-Time Password)

URL: https://exbk.jp/glossary/totp
読み: ティーオーティーピー
カテゴリ: general

### 短い定義 (TL;DR)

TOTP (Time-based One-Time Password) は、共有鍵と現在時刻から HMAC で6桁ワンタイムコードを生成する方式です。RFC 6238で規定され、Authenticatorアプリで広く使われます。

### 詳細解説

TOTP は、HOTP (RFC 4226) を拡張し時刻をカウンタにした方式で、RFC 6238 で標準化されています。共有秘密鍵 (通常160bitのBase32) と現在のUNIX時刻を30秒で割った商を HMAC-SHA1 (またはSHA256/512) し、その出力を Truncate して6桁数字を得ます。サーバーとクライアントの時刻ズレに備え±1ステップ (前後30秒) を許容するのが慣習です。導入は QR コード ( otpauth://totp/Issuer:account?secret=...&issuer=... ) で Google Authenticator / Authy / 1Password / Microsoft Authenticator にスキャンさせるだけで、ベンダー非依存に動きます。SMS OTP より安全ですが共有鍵が漏れると無力なため、サーバー側の暗号化保管・流出検知が前提になります。フィッシング耐性は WebAuthn より低い点も認識が必要です。

### 実装例

- Google Authenticator で 6桁 30秒の TOTP を生成
- otpauth://totp/exbk.jp:user@example.com?secret=BASE32&issuer=exbk.jp
- サーバー側の secret 列は KMS で暗号化保管

### 出典

- [RFC 6238 - TOTP: Time-Based One-Time Password Algorithm](https://www.rfc-editor.org/rfc/rfc6238)

---

## Transformer

URL: https://exbk.jp/glossary/transformer
読み: トランスフォーマー
カテゴリ: ai

### 短い定義 (TL;DR)

Transformer (トランスフォーマー) は 2017 年 Google 論文で発表された深層学習アーキテクチャで、Self-Attention 機構を核に持ちます。GPT・BERT・Claude・Gemini など全ての近代 LLM の基盤です。

### 詳細解説

Transformer は 'Attention is All You Need' (Vaswani et al., 2017) で発表され、それまでの RNN / LSTM を駆逐しました。Self-Attention 機構により、文中の任意の単語ペア間の関係を並列計算できるため、長文処理と GPU 並列化に圧倒的に強い。Encoder-only (BERT)、Decoder-only (GPT 系)、Encoder-Decoder (T5) のバリエーションがあり、現代 LLM はほぼ全て Decoder-only Transformer。

### 実装例

- GPT 系 = Decoder-only Transformer
- BERT = Encoder-only Transformer
- Vision Transformer (ViT) で画像認識

### 出典

- [Attention Is All You Need (2017)](https://arxiv.org/abs/1706.03762)

---

## トリガー (GTM) (Trigger)

URL: https://exbk.jp/glossary/trigger
読み: トリガー
カテゴリ: analytics

### 短い定義 (TL;DR)

トリガーは GTM でタグを発火させる「いつ・どこで」の条件を定義する設定です。ページビュー・クリック・フォーム送信・スクロール・カスタムイベントなど 10 種類以上の標準トリガーがあります。

### 詳細解説

トリガー (Trigger) は GTM においてタグを発火させる「いつ・どこで」の条件を定義する設定で、タグの発火ロジックを担当する中核要素です。標準で提供されるトリガータイプは (1) ページビュー (DOM Ready / Window Loaded を含む)、(2) クリック (リンククリック / 全要素クリック)、(3) 要素の表示 (Element Visibility)、(4) フォーム送信、(5) スクロール距離、(6) YouTube 動画、(7) カスタムイベント (dataLayer.push の event キー)、(8) 履歴の変更 (SPA 用)、(9) JavaScript エラー、(10) タイマー、の 10 種類以上です。各トリガーには発火条件として「すべてのページ」または「特定の条件 (URL に /thanks を含む等)」をフィルタとして設定でき、複数の条件を AND 結合で組み合わせ可能です。さらに高度な使い方として、特定のトリガーが発火した後に別のタグの発火を抑制する「除外条件 (Exception)」を設定でき、誤発火を防ぐ細かいコントロールができます。

### 実装例

- URL に /thanks を含む場合にコンバージョントリガーを発火させる
- form_submit カスタムイベントトリガーで CV タグを呼び出す
- スクロール 90% 到達トリガーで読了イベントを GA4 に送信する

### 出典

- [Tag Manager トリガー](https://support.google.com/tagmanager/answer/6106961)

---

## Turbopack

URL: https://exbk.jp/glossary/turbopack
読み: ターボパック
カテゴリ: web

### 短い定義 (TL;DR)

Turbopack (ターボパック) は Vercel が開発する次世代 JavaScript バンドラーで、Webpack の後継として Next.js に統合されています。Rust 実装で Webpack より大幅に高速です。

### 詳細解説

Turbopack は 2022 年に Vercel が発表した OSS バンドラーで、Webpack の作者 Tobias Koppers が中心となって開発しています。Rust 実装のためビルド速度が圧倒的で、増分ビルドでは 10 倍以上高速。ただし 2026 年時点では一部ユースケース (日本語パスでパニック等) で安定性課題があり、本番ビルドは --webpack 指定が安全なケースもあります。Next.js 14 で dev mode に統合、Next.js 15 でビルドにも限定的対応。

### 実装例

- next dev は Turbopack 標準
- next build は --webpack で安全に運用 (2026 年時点)
- .sst ファイルが turbopack のキャッシュ実体

### 出典

- [Turbopack Documentation](https://turbo.build/pack)

---

## Twitter Card

URL: https://exbk.jp/glossary/twitter-card
読み: ツイッターカード
カテゴリ: seo

### 短い定義 (TL;DR)

Twitter Card は、X (旧 Twitter) でツイート内に Web ページのリッチプレビュー (画像・タイトル・説明) を表示するための meta タグ規格です。OGP と並行して twitter:card 等のタグで指定します。

### 詳細解説

Twitter Card は Twitter (現 X) が2012年に導入した meta タグ仕様で、ツイートに URL を含めるとカード形式で画像 + タイトル + 説明文がプレビュー展開されます。カード種類は、1) Summary (小サムネイル + タイトル + 説明)、2) Summary Large Image (1200×628px の大画像版)、3) Player (動画・音声埋め込み)、4) App (モバイルアプリ訴求)、の4種類です。実装は HTML head 内に <meta name="twitter:card" content="summary_large_image">、twitter:title、twitter:description、twitter:image を記述します。OGP タグ (og:title 等) が存在する場合 X は自動的に OGP を fallback として参照するため、twitter:* タグは Twitter Card 固有の挙動が必要な場合のみ追加します。X からの流入は SEO に直接影響しませんが、エンゲージメント増加 → 被リンク獲得 → 間接的に SEO 評価向上、の経路で寄与します。

### 実装例

- Summary Large Image カードは Summary より CTR が4倍高いとの調査があります
- OGP のみ実装 + twitter:card は省略するシンプル構成も主流です
- X の Card Validator で表示確認とキャッシュクリアができました (現在廃止)

### 出典

- [X Developer Platform - Twitter Cards](https://developer.x.com/en/docs/twitter-for-websites/cards/overview/abouts-cards)

---

## UA (Universal Analytics)

URL: https://exbk.jp/glossary/ua
読み: ユニバーサルアナリティクス
カテゴリ: analytics

### 短い定義 (TL;DR)

UA (Universal Analytics) は GA4 の前世代となる Google アナリティクスのバージョンです。セッションベースの計測モデルを採用していました。2023 年 7 月 1 日に標準プロパティのデータ収集が停止し、現在は終了済みです。

### 詳細解説

UA (Universal Analytics) は 2012 年から提供されていた Google アナリティクスのバージョンで、ユーザーの一連の行動を「セッション」としてまとめて集計するモデルを採用していました。プロパティ ID は「UA-XXXXXXXX-1」のような形式で、ヒットの種類はページビュー・イベント・トランザクションなどに分類されていました。2023 年 7 月 1 日に標準プロパティのデータ収集が停止し、2024 年 7 月 1 日には UA プロパティおよび過去データへのアクセスも完全に終了しました。後継の GA4 はイベントベース・Web/アプリ横断・プライバシー強化など根本から再設計されており、UA からの単純なデータ移行はできません。現在 UA タグ (analytics.js) が残っているサイトは早急に GA4 (gtag.js) への置き換えが必要です。

### 実装例

- 古いブログに UA-XXXXXXXX-1 のタグが残っていたため GA4 に置換する
- UA 時代のレポート構造（セッション・直帰率）と GA4 の差分を社内に説明する
- UA エクスポート機能で過去データを CSV ダウンロードしてから廃止に備える

### 出典

- [ユニバーサル アナリティクスのサポート終了について](https://support.google.com/analytics/answer/11583528)

---

## UGC (User Generated Content (ユーザー生成コンテンツ))

URL: https://exbk.jp/glossary/ugc
読み: ユージーシー
カテゴリ: general

### 短い定義 (TL;DR)

UGC (User Generated Content) は、ユーザー自身が SNS やレビューサイトに投稿するコンテンツです。広告より信頼度が高く、購買の意思決定に大きく影響します。Z 世代の購買行動への影響が特に大きいとされています。

### 詳細解説

UGC は SNS 投稿、Amazon レビュー、Google マップ口コミ、YouTube 商品レビューなど、ユーザーが自発的に作るコンテンツの総称です。Nielsen の調査では、消費者の92% が広告より UGC を信頼すると回答しており、特に Z 世代では UGC が購買決定の最大要因です。GoPro はユーザー投稿映像を集めて公式 Instagram と TV CM に活用し、広告費を抑えながら世界的ブランドに成長しました。Glossier は新商品の80% を Instagram の顧客 DM フィードバックから企画していると公表しています。UGC を促進する施策は、(1) ハッシュタグキャンペーン、(2) リポスト許諾の取得と紹介、(3) アフィリエイト/紹介プログラム、(4) フォトコンテスト、の4類型で、Yotpo や Bazaarvoice などの UGC 集約ツールで EC サイトに表示できます。著作権と肖像権の取り扱いは慎重に行い、必ず投稿者の許諾を得て二次利用するのが法的にも安全です。

### 実装例

- アパレル EC が、購入者のコーディネート写真をハッシュタグ #ブランド名_OOTD で集め公式サイトに表示します。
- 化粧品ブランドが、Instagram でビフォーアフター投稿を募集し、月間1,000件の UGC を獲得します。
- 宿泊施設が、Google マップ口コミに即時返信する運用で評価4.8/5 を維持し新規客を獲得します。

### 出典

- [Nielsen - Global Trust in Advertising Report](https://www.nielsen.com/insights/2021/trust-in-advertising/)

---

## アップセル

URL: https://exbk.jp/glossary/upsell
読み: アップセル
カテゴリ: general

### 短い定義 (TL;DR)

アップセル (Upsell) は、検討中の商品より上位プランや高機能版を提案する販売手法です。サブスクモデルでは ARPU を伸ばす最重要施策となります。Tiered Pricing と組み合わせ ARPU を押し上げます。

### 詳細解説

アップセルは、現在の商品より上位ランクの商品を提案する手法で、サブスクの Tiered Pricing (段階別価格) と組み合わせて機能します。例えば、Slack の Free → Pro → Business+ → Enterprise Grid のプラン階段で、ユーザー数や機能のニーズが高まるに連れて上位プランへ自然移行する設計が典型です。HubSpot Research によると、既存顧客への営業のクロージング率は新規顧客の5-25倍 (15% 対 60-70%)、コストは1/5-1/25 で、アップセルは効率最高の収益源です。マクドナルドの「セットでいかがですか?」「ポテトを L サイズにしますか?」も対面アップセルの教科書例です。BtoB SaaS のアップセル戦略は、(1) Usage-based 課金で利用増に応じた自動アップグレード、(2) 機能制限解除型アップグレード、(3) ユーザー数増加による単価増、の3パターンで、Net Negative Churn (拡大が解約を上回る) を実現する SaaS は ARR 成長率が大きく加速します。注意点は、不適切なアップセル提案で顧客満足度を損なわないこと、必要性のある提案を心がけることです。

### 実装例

- SaaS が無料プラン使用60日後にアップグレード CTA を表示、有料化率20% を達成します。
- EC が、商品ページで「プレミアム版が500円差で2倍長持ち」と提示しアップセル成功率35%。
- コーチングが基本プラン契約者に、3か月後に上位プランを提示、移行率40% を実現します。

### 出典

- [HubSpot - Upselling Best Practices](https://blog.hubspot.com/sales/upselling)

---

## ユーザビリティテスト (Usability Testing)

URL: https://exbk.jp/glossary/usability-test
読み: ユーザビリティテスト
カテゴリ: general

### 短い定義 (TL;DR)

ユーザビリティテストは、実ユーザーに代表タスクを実行してもらい観察・思考発話で UI の使いやすさを評価する定性リサーチ手法です。NN/g によれば 5 人で主要課題の85%が発見できます。

### 詳細解説

ユーザビリティテストは、ターゲットユーザーに代表的タスク (「アカウント作成して商品Aを購入」等) を実行してもらい、観察・思考発話法 (Think Aloud) ・事後インタビューで UI の問題点を抽出する定性リサーチ手法です。NN/g の Jakob Nielsen による経験則「5人テストで85%の主要課題が発見できる」は有名で、低コストで反復することが推奨されます。実施形態は (1) 対面ラボ (2) リモート同期 (Zoom 画面共有) (3) リモート非同期 (UserTesting / Maze) があり、コロナ以降は非同期型が急速に普及しました。タスク成功率・タスク完了時間・SUS スコア (System Usability Scale, 10項目)・CSAT・自由コメント を組み合わせて評価します。A/Bテストが「どちらが勝つか」を測るのに対し、ユーザビリティテストは「なぜ詰まるか」を理解するのに最適です。

### 実装例

- 5人で初回購入フローを観察 → 主要課題の85%発見
- Maze でリモート非同期テスト 30人 / SUS 70点を基準
- Think Aloud で「あれ、どこ押せばいいの?」発話を採取

### 出典

- [NN/g - Why You Only Need to Test with 5 Users](https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/)

---

## ユーザーエクスプローラ (User Explorer)

URL: https://exbk.jp/glossary/user-explorer
読み: ユーザーエクスプローラ
カテゴリ: analytics

### 短い定義 (TL;DR)

ユーザーエクスプローラは GA4 の探索レポートで個別ユーザーの行動履歴を時系列で確認できる機能です。クライアント ID または User-ID 単位で全イベントをドリルダウンして閲覧できます。

### 詳細解説

ユーザーエクスプローラ (User Explorer) は GA4 の探索レポートテンプレートの 1 つで、個別ユーザー単位での詳細な行動履歴を時系列で追跡できる機能です。識別単位はクライアント ID (Cookie) または User-ID (ログイン ID) で、ユーザーリストから 1 人を選択すると、そのユーザーが「いつ」「どのページで」「どのイベントを」発火したかを 1 件ずつ秒単位で確認できます。たとえば購入したユーザーがどのような経路をたどってきたのか、離脱直前の操作は何だったか、サポート問い合わせ前のセッションで何があったかなど、定性的な仮説検証に役立ちます。データ表示の上限はリストで 100,000 ユーザーまで、個別ユーザーごとの履歴は最大 1,000 イベントです。BtoB の高単価商材や SaaS のオンボーディング分析、CS 業務での個別問い合わせ対応など「1 人 1 人を見る分析」で価値を発揮します。プライバシー上、個人を特定する PII を直接表示することはできない仕様です。

### 実装例

- 高額商品購入ユーザー 1 人の行動履歴を遡って提案改善ポイントを発見する
- サポート問い合わせ前のセッション履歴を確認し UI 改善の手がかりを得る
- User-ID でログインユーザー単位の継続行動パターンを分析する

### 出典

- [[GA4] ユーザー エクスプローラ](https://support.google.com/analytics/answer/9283607)

---

## User-ID 機能 (User-ID)

URL: https://exbk.jp/glossary/user-id
読み: ユーザーアイディーキノウ
カテゴリ: analytics

### 短い定義 (TL;DR)

User-ID 機能は GA4 でログインユーザーに自社が発行する ID を紐付けてクロスデバイス分析を可能にする機能です。会員 ID をハッシュ化して送信することで PII を保護しつつデバイス横断計測ができます。

### 詳細解説

User-ID 機能は GA4 において、ユーザーがログインしたタイミングで自社サービスが発行する一意の ID (会員 ID など) を GA4 に渡し、クロスデバイス・クロスブラウザの行動を 1 ユーザーとして紐付ける機能です。たとえば PC で記事を読んだあとスマホアプリで購入したユーザーを、両者を同一ユーザーとして 1 セッションに統合できるため、CVR や LTV の算出精度が大きく向上します。ID には個人を特定できる PII (氏名・メール・電話番号) を直接渡してはいけないため、必ずハッシュ化済みの内部 ID を使う必要があります。GA4 にはレポート ID のロジックとして「観測データのみ」「デバイスベース」「Google シグナル」「ハイブリッド」の選択肢があり、User-ID を渡している場合は「ハイブリッド (User-ID 優先)」を選ぶことで精度を最大化できます。実装は gtag('config', 'G-XXXXX', {user_id: 'hashed_id'}) または GTM 経由で行います。

### 実装例

- ログイン直後に user_id をハッシュ化して GA4 に送信する
- PC とスマホで同一ユーザーの購入率を比較するクロスデバイス分析を実施する
- User-ID とユーザープロパティ membership_level を併用し会員別 LTV を見る

### 出典

- [[GA4] User-ID を設定する](https://support.google.com/analytics/answer/9213390)

---

## User message

URL: https://exbk.jp/glossary/user-message
読み: ユーザーメッセージ
カテゴリ: ai

### 短い定義 (TL;DR)

User message (ユーザーメッセージ) は、LLM 対話でユーザーが入力するメッセージです。System prompt の制約下で具体的なリクエストや質問を投げる役割を持ちます。

### 詳細解説

User message は OpenAI / Anthropic API の messages 配列で role: 'user' として渡されます。複数ターン会話では user / assistant が交互に並び、過去のやり取り全体をコンテキストとして LLM が処理します。Conversation memory の実装は通常、過去 N ターンを user / assistant メッセージとして再送信する形で行います。

### 実装例

- 「この記事を要約して」のような直接リクエスト
- Few-shot の各 'Input' 部分も user message
- Multi-turn 対話で文脈を維持

---

## ユーザープロパティ (User Property)

URL: https://exbk.jp/glossary/user-property
読み: ユーザープロパティ
カテゴリ: analytics

### 短い定義 (TL;DR)

ユーザープロパティは GA4 でユーザー個人に紐付く属性情報です。会員ランク・言語設定・購読プランなどを設定でき、1 プロパティに最大 25 個 (Free) のカスタムユーザープロパティを定義できます。

### 詳細解説

ユーザープロパティは GA4 においてユーザー個人に紐付く属性情報で、イベントが「行動」を表すのに対しユーザープロパティは「人」を表します。たとえば会員ランク (premium/free)、登録月、言語設定、購読プランなどをユーザープロパティとして送信すると、その後のすべてのイベントで自動的に紐付けされ、レポート上で属性別の行動分析が可能になります。GA4 では自動収集される標準ユーザープロパティ (言語、国など) のほかに、開発者が任意に定義するカスタムユーザープロパティを Free 版で 1 プロパティあたり最大 25 個 (360 版で 100 個) まで作成できます。カスタムユーザープロパティを使うには「管理 > カスタム定義」でディメンションとして登録する必要があります。なお、個人を特定する PII (氏名・メール・電話番号) を直接送信することは Google アナリティクス利用規約で禁止されているため要注意です。

### 実装例

- membership_level=premium をユーザープロパティとして送信する
- user_signup_month=2026-04 を記録し継続率を月別に比較する
- preferred_language=ja を保持し UI 言語別の動向を分析する

### 出典

- [[GA4] ユーザー プロパティ](https://support.google.com/analytics/answer/9268042)

---

## USP (Unique Selling Proposition)

URL: https://exbk.jp/glossary/usp
読み: ユーエスピー
カテゴリ: general

### 短い定義 (TL;DR)

USP (Unique Selling Proposition) は、自社商品のみが提供できる独自の価値提案で、競合が真似できない一行のメッセージにまとめたものです。広告の中核訴求を担います。コピーライティングの核に据える必須要素です。

### 詳細解説

USP は Rosser Reeves が1961年に著書『Reality in Advertising』で提唱した概念で、(1) 具体的なベネフィットを約束する、(2) 競合が提供していない・できない、(3) 顧客を動かすほど強力、という3条件を満たす必要があります。代表例として Domino's Pizza の「30分以内にお届けできなければ無料」、M&M's の「お口でとろけて、手にとけない」、FedEx の「絶対に翌朝までに届ける必要がある時に」などが知られています。USP を作る手順は、顧客の不満点を100個書き出し、自社の強みと交差する部分を抽出し、競合のメッセージと並べて唯一性を確認する流れが定番です。日本企業では、富士通の「シンプリシティ」やライザップの「結果にコミットする」が成功例として挙げられます。ホームページのファーストビュー、広告コピー、営業資料の冒頭で繰り返し使うことで認知が定着します。

### 実装例

- BtoB SaaS が「導入後30日で効果が出なければ全額返金」を USP に据え、競合との差別化を図ります。
- 整体院が「3回で効果実感、出ない場合は4回目以降無料」という USP で広告 CTR を3倍にします。
- EC ショップが「最短当日出荷・送料無料・30日返品OK」の3点セットを USP として LP の冒頭に配置します。

### 出典

- [Rosser Reeves - Reality in Advertising (1961)](https://archive.org/details/realityinadverti0000reev)

---

## UU (Unique User)

URL: https://exbk.jp/glossary/uu
読み: ユーユー
カテゴリ: analytics

### 短い定義 (TL;DR)

UU (Unique User) は集計期間中にサイトを訪問したユニークなユーザー数を表す指標です。GA4 では「アクティブユーザー数」と呼ばれ、Cookie や User-ID で重複を排除して計算されます。

### 詳細解説

UU (Unique User) は集計期間中にサイトを訪問したユニークなユーザー数を表す指標で、GA4 では「アクティブユーザー数 (Active Users)」と呼ばれ標準レポートの主要 KPI として使われます。識別単位は (1) Cookie ベースのクライアント ID (_ga)、(2) ログインユーザー向けの User-ID、(3) Google アカウントに基づく Google シグナル、の 3 つを組み合わせて計算されます。UA 時代の「ユーザー」と GA4 の「アクティブユーザー」は定義が微妙に異なり、GA4 は「エンゲージメントセッションを少なくとも 1 回持ったユーザー」を指すため UA より少なめに出るのが一般的です。プライバシー強化の流れで Cookie 規制が進み、Safari の ITP・iOS の ATT などにより同一ユーザーが新規ユーザーとして再カウントされるケースが増えているため、長期トレンドの解釈には注意が必要です。広告でいう「リーチ」とほぼ同義の概念で、メディアの実質的な到達範囲を測る指標として PV と並ぶ重要性を持ちます。

### 実装例

- 月間 UU 5 万を目標に広報・SEO の集客計画を設計する
- User-ID 実装でクロスデバイスの UU 重複を排除し精度を上げる
- Cookie 規制により UU が見かけ上 +20% となった件を社内に説明する

### 出典

- [[GA4] アクティブ ユーザーについて](https://support.google.com/analytics/answer/12253918)

---

## バリュープロポジション

URL: https://exbk.jp/glossary/value-proposition
読み: バリュープロポジション
カテゴリ: general

### 短い定義 (TL;DR)

バリュープロポジション (Value Proposition) は、顧客に提供する独自価値を明文化したもので、「誰に」「どんな課題を」「どう解決するか」を一文で示す経営の中核メッセージです。事業計画と LP 設計の中核を担います。

### 詳細解説

バリュープロポジションは、Alexander Osterwalder の『Value Proposition Design』(2014) で体系化され、Value Proposition Canvas というツールで可視化します。顧客側の「ゲイン (得たい結果)」「ペイン (避けたい苦痛)」「ジョブ (片付けたい用事)」を左に、自社側の「商品サービス」「ペインリリーバー」「ゲインクリエーター」を右に配置し、適合度 (Product-Market Fit) を検証します。例えば Slack は「メールを減らし、チームの生産性を上げる」というバリュープロポジションで、創業から5年で年間売上10億ドルに到達しました。USP が広告コピー寄りなのに対し、バリュープロポジションは事業戦略寄りで、商品仕様、価格、サポート体制まで含めた全体提案を指します。LP のヘッドラインや投資家向けピッチの冒頭で使う必須のメッセージです。

### 実装例

- Slack が「Be Less Busy (もっと忙しさを減らそう)」をバリュープロポジションに、メール代替市場を切り開きました。
- Uber が「タップひとつで車が来る、現金不要、価格事前提示」を3点セットで提案し、タクシー市場を変革しました。
- 国内 SaaS の SmartHR が「人事労務がペーパーレスで完結、給与計算と連携」を中核メッセージに据えています。

### 出典

- [Strategyzer - Value Proposition Canvas](https://www.strategyzer.com/library/the-value-proposition-canvas)

---

## 変数 (GTM) (Variable)

URL: https://exbk.jp/glossary/variable
読み: ヘンスウ
カテゴリ: analytics

### 短い定義 (TL;DR)

変数は GTM でタグやトリガーに渡す動的な値を保持する仕組みです。組み込み変数・データレイヤー変数・URL 変数・カスタム JavaScript 変数など 20 種類以上の変数タイプがあります。

### 詳細解説

変数 (Variable) は GTM においてタグやトリガーで参照される動的な値を保持する仕組みで、計測タグの再利用性と保守性を高めるための重要な要素です。GTM 標準で 20 種類以上の変数タイプが提供されており、代表的なものは (1) 組み込み変数 (Page URL / Page Path / Click Element / Click URL など 30 種類以上)、(2) データレイヤー変数 (window.dataLayer の特定キーを取得)、(3) 定数 (固定値、例: GA4 測定 ID)、(4) ファーストパーティ Cookie 変数、(5) JavaScript 変数 (グローバル変数の参照)、(6) カスタム JavaScript 変数 (任意の処理を返す関数)、(7) ルックアップテーブル (キー → バッグ値のマッピング)、(8) 正規表現テーブル、です。変数を活用することで、たとえば 1 つの GA4 イベントタグで複数のイベントを動的に処理する、デバイス別に異なる測定 ID を出し分ける、UTM パラメータの値を CV タグに渡す、といった柔軟な計測実装が可能になります。

### 実装例

- データレイヤー変数 dlv.value で購入金額を GA4 タグに渡す
- ルックアップテーブルで URL パスから商品カテゴリ名を変換する
- カスタム JS 変数で localStorage の会員ランクを取得する

### 出典

- [Tag Manager 変数](https://support.google.com/tagmanager/answer/7683056)

---

## Vector DB

URL: https://exbk.jp/glossary/vector-db
読み: ベクターディービー
カテゴリ: ai

### 短い定義 (TL;DR)

Vector DB (ベクター DB) は、Embedding ベクトルに最適化された検索データベースです。Pinecone・Qdrant・Weaviate・Chroma・pgvector などが代表的で、RAG の検索基盤として使われます。

### 詳細解説

Vector DB は数百万〜数十億の高次元ベクトルから「最も類似したもの top-K」を高速取得するために最適化されたデータベースです。HNSW (Hierarchical Navigable Small World) などの近似最近傍探索 (ANN) アルゴリズムを採用し、ミリ秒オーダーで応答します。Pinecone (SaaS) / Qdrant (OSS+SaaS) / Weaviate (OSS+SaaS) / Chroma (軽量・組込み) / pgvector (PostgreSQL 拡張) が選択肢。RAG / 推薦 / セマンティック検索の必須コンポーネントです。

### 実装例

- RAG の検索エンジン (top-5 関連文書取得)
- EC サイトの「類似商品」推薦
- セマンティック検索の裏側

### 出典

- [Pinecone Vector Database](https://www.pinecone.io)

---

## ベンダーロック

URL: https://exbk.jp/glossary/vendor-lock-in
読み: ベンダーロック
カテゴリ: storage

### 短い定義 (TL;DR)

ベンダーロック (vendor lock-in) は、特定ベンダーの製品/サービスから他社へ移行困難な状態に陥ることです。SaaS のサブスク料金値上げや機能制限が起きても抜け出しにくくなります。

### 詳細解説

ベンダーロックは独自フォーマット・独自 API・データエクスポート不可・データ同期失敗など複数の要因で発生します。Dropbox / OneDrive / Google Drive のような SaaS は便利な反面、ベンダー側の値上げ・機能廃止・規約変更にユーザーが対抗できません。Nextcloud / Mastodon のようなセルフホスト OSS は、運用負荷と引き換えに完全なデータ主権を得られます。「ロックされていないか」は導入時にチェックすべき設計判断です。

### 実装例

- Dropbox → Nextcloud 移行 (rclone で 1 コマンドコピー可能)
- Notion → Markdown ファイル + git で OSS スタックへ移行
- AWS Lambda 専用コードを Cloudflare Workers / Vercel Functions に移植困難

---

## Vercel

URL: https://exbk.jp/glossary/vercel
読み: ヴァーセル
カテゴリ: web

### 短い定義 (TL;DR)

Vercel (ヴァーセル) は Next.js を開発する企業が運営するクラウドホスティングサービスです。Git 連携で push したら自動デプロイされ、CDN・サーバーレス関数も標準装備しています。

### 詳細解説

Vercel は 2015 年創業 (旧名 Zeit)、現在は Next.js のメンテナでもあります。Hobby プラン無料、Pro 月 $20/ユーザーから。Edge Network・Image Optimization・Edge Functions・Cron・Postgres / KV / Blob などの周辺サービスが統合され、Next.js アプリのデプロイ先として最も体験が滑らかです。GitHub / GitLab / Bitbucket と連携し、PR ごとにプレビュー URL が自動発行されます。CMS は別契約 (Sanity / Contentful / MDX等) ですが、Next.js + MDX なら CMS 不要のファイルベース運用も可能。

### 実装例

- vercel --prod --yes で本番デプロイ (1 コマンド)
- PR ごとに自動プレビュー URL 発行
- Cloudflare Workers との比較で開発者体験の優位性

### 出典

- [Vercel Pricing](https://vercel.com/pricing)

---

## バージョン管理 (Version Control)

URL: https://exbk.jp/glossary/version-gtm
読み: バージョンカンリ
カテゴリ: analytics

### 短い定義 (TL;DR)

GTM のバージョン管理はコンテナ公開のたびにスナップショットを保持し、過去のバージョンへワンクリックで戻せる機能です。誤公開時のロールバック・変更履歴の追跡に必須の機能です。

### 詳細解説

バージョン管理 (Version Control) は GTM においてコンテナを公開するたびに変更内容のスナップショットが自動で保持され、過去任意のバージョンへワンクリックでロールバックできる機能です。各バージョンには (1) バージョン番号 (連番)、(2) バージョン名 (任意設定可能)、(3) 説明、(4) 公開日時、(5) 公開者、(6) 含まれるタグ・トリガー・変数の一覧、(7) 直前バージョンとの差分、が記録され、変更履歴の完全な監査ログとして機能します。誤った計測タグを公開してしまった場合や、新バージョンで予期しない不具合が発覚した場合に、管理画面の「バージョン > バージョンを公開」から数秒で前のバージョンに戻せるため、ダウンタイムを最小化できます。バージョン保持数に上限はなく、コンテナの全履歴が永続的に保存されます。多人数運用や大規模 EC では、公開のたびにバージョン名と説明を必ず記入する運用ルールを定めることで、後の追跡性が大きく向上します。

### 実装例

- 誤って削除したタグを 1 クリックで前バージョンから復元する
- 公開時に「v2026.05.04 春キャンペーン Meta Pixel 追加」と命名する
- 監査ログとしてバージョン履歴を四半期レビューに活用する

### 出典

- [Tag Manager バージョン](https://support.google.com/tagmanager/answer/6107163)

---

## バイラルマーケティング

URL: https://exbk.jp/glossary/viral-marketing
読み: バイラルマーケティング
カテゴリ: general

### 短い定義 (TL;DR)

バイラルマーケティング (Viral Marketing) は、ユーザー間の口コミや SNS シェアで情報が爆発的に広がる現象を狙うマーケ手法です。低コストで大量の認知を獲得できる可能性があります。K-Factor 1 超で指数関数的に拡散します。

### 詳細解説

バイラルマーケティングは「ウイルスのように広がる」マーケティングで、Hotmail が1996年にメール末尾に「Get your free email at Hotmail」と署名を埋め込み、18か月で1,200万ユーザーを獲得した事例が起源とされます。バイラル係数 (K-Factor) = 招待数 × 招待成功率で、K > 1 なら指数関数的に拡散します。Dropbox は紹介で双方に容量プレゼント機能で K=0.5 を実現、登録者を15か月で10万人→400万人に拡大しました。ALS Ice Bucket Challenge は2014年に世界で2,800万人が参加し、寄付金額が前年比3,500% 増加しました。バイラルが起きる条件は、Jonah Berger の『Contagious』(2013) によると STEPPS (Social Currency 社会的通貨・Triggers きっかけ・Emotion 感情・Public 可視性・Practical Value 実用価値・Stories ストーリー) の6要素を満たすことです。再現性は低いものの、当たれば CAC が劇的に下がるため、コンテンツ設計時に意識する価値があります。

### 実装例

- アプリが「友達招待で双方に1か月無料」を実装、K=0.7 を達成し3か月で50万 DL を獲得します。
- EC が話題性のある動画広告を制作、TikTok で2,000万再生を獲得しブランド認知を急拡大させます。
- BtoC SaaS がチャレンジ型ハッシュタグキャンペーンを展開、UGC を10万件集めます。

### 出典

- [Jonah Berger - Contagious: Why Things Catch On](https://jonahberger.com/books/contagious/)

---

## Virtual File

URL: https://exbk.jp/glossary/virtual-file
読み: バーチャルファイル
カテゴリ: saas

### 短い定義 (TL;DR)

Virtual File は Nextcloud Desktop の Smart Sync 相当機能で、クラウド上のファイルをローカルファイルシステムに見えるだけ表示し、開いた時にダウンロードする仕組みです。

### 詳細解説

Virtual File は Nextcloud Desktop 3.0 (2021 年) で追加された機能で、Windows ではファイルエクスプローラのプレースホルダー機能、macOS では Apple File Provider Extension を使って実装されています。Linux では FUSE で限定的に動作。これにより Dropbox Smart Sync と同等の体験が OSS 環境でも得られます。

### 実装例

- Nextcloud Desktop 設定で「Use virtual files」を有効化
- ファイルアイコンに雲マーク (オンライン状態)
- アクセスすると自動ダウンロード + ローカル化

---

## フォン・レストルフ効果 (Von Restorff Effect / Isolation Effect)

URL: https://exbk.jp/glossary/von-restorff-effect
読み: フォンレストルフこうか
カテゴリ: general

### 短い定義 (TL;DR)

フォン・レストルフ効果は「他と異なる要素は記憶に残りやすい」という心理学の現象で、CTA や重要情報の視覚的差別化の根拠になります。

### 詳細解説

フォン・レストルフ効果 (Von Restorff Effect / Isolation Effect) は、ドイツの精神科医 Hedwig von Restorff が1933年に発見した「複数の似た要素の中に1つだけ異質な要素があるとき、その異質な要素が顕著に記憶される」という現象です。UX/UI への応用は (1) 主要 CTA を他のボタンと明確に異なる色・サイズ・形にする (2) アラート・通知は視覚的に隔離する (3) 強調したい価格・特徴を太字や囲みで差別化 (4) リスト中の推奨プランをハイライト などです。注意点は「全てを強調すると何も強調されない」ため、ページあたりの強調要素は1〜2に絞ることです。アクセシビリティ観点では色のみによる差別化はNGで、形・サイズ・テキストラベルとの併用が必要です (WCAG 1.4.1)。

### 実装例

- 料金表で「人気プラン」だけ色違いと「人気No.1」バッジ
- プライマリ CTA を他リンクと明確に違う色 + サイズに
- 「セール中」赤バッジで通常商品の中で目立たせる

### 出典

- [Laws of UX - Von Restorff Effect](https://lawsofux.com/von-restorff-effect/)

---

## VPS (Virtual Private Server)

URL: https://exbk.jp/glossary/vps
読み: ブイピーエス
カテゴリ: infra

### 短い定義 (TL;DR)

VPS (Virtual Private Server) は、物理サーバーを仮想化技術で分割し、ユーザーごとに専用環境として提供するレンタルサーバーの一種です。Hostinger・さくら・ConoHa など各社が月数百円から提供しています。

### 詳細解説

VPS は KVM / Xen / OpenVZ 等のハイパーバイザで物理マシンを仮想化し、ユーザーには root 権限付きの仮想 Linux 環境を提供します。共有レンタルサーバー (Apache + PHP しか動かない) より自由度が圧倒的に高く、Docker / Node.js / Go バイナリ等を任意に動かせます。クラウド (AWS EC2 / GCP) との違いは、VPS は固定月額・スペック固定 (スケールしない代わりに予算が読める)、クラウドは従量課金・スケール可能です。中小規模のセルフホストには VPS が圧倒的に経済的です。

### 実装例

- Hostinger KVM 2 (4GB RAM / 100GB SSD) 月 800 円で Nextcloud 運用
- Docker + nginx で Web アプリホスティング
- Node.js / Python の常駐デーモン実行

### 出典

- [Hostinger VPS Plans](https://www.hostinger.jp/vps)

---

## WAF (Web Application Firewall)

URL: https://exbk.jp/glossary/waf
読み: ワフ
カテゴリ: general

### 短い定義 (TL;DR)

WAF (Web Application Firewall) は、Webアプリ層の脅威 (SQLi・XSS・LFI 等) をシグネチャや機械学習で検知・遮断するファイアウォールです。Cloudflare・AWS WAF・Akamai が代表です。

### 詳細解説

WAF は、OSI 7層 (アプリ層) でHTTPリクエストを検査し、SQLインジェクション・XSS・パストラバーサル・コマンドインジェクション・ボット・スクレイピング等を検知して遮断するセキュリティ装置です。実装形態はクラウド (Cloudflare WAF / AWS WAF / Akamai Kona) / アプライアンス (F5 BIG-IP) / オープンソース (ModSecurity + OWASP CRS) があります。OWASP Core Rule Set (CRS) は無償で多くのWAFが採用しており、Paranoia Level 1〜4 で誤検知と防御強度をトレードオフ調整できます。マネージド型WAFはCDNと一体になっておりレイテンシペナルティが小さく、DDoS対策・ボット対策・レートリミットも統合されているのが利点です。バーチャルパッチで未修正脆弱性を緊急対応できる点も評価されます。

### 実装例

- Cloudflare WAF で OWASP CRS を Paranoia 2 で運用
- AWS WAF + AWS Managed Rules でマネージドルールを併用
- ModSecurity + CRS で自前ホスト WAF を構築

### 出典

- [OWASP ModSecurity Core Rule Set](https://coreruleset.org/)

---

## WCAG (Web Content Accessibility Guidelines)

URL: https://exbk.jp/glossary/wcag
読み: ダブリューシーエージー
カテゴリ: general

### 短い定義 (TL;DR)

WCAG (Web Content Accessibility Guidelines) は、W3C WAI が策定するWebアクセシビリティ国際標準で、現行版は WCAG 2.2 です。レベル A / AA / AAA の3段階で評価します。

### 詳細解説

WCAG (Web Content Accessibility Guidelines) は W3C WAI が策定する Web アクセシビリティの国際標準で、WCAG 2.0 (2008) → 2.1 (2018) → 2.2 (2023) と更新されてきました。設計原則「POUR」(知覚可能 Perceivable / 操作可能 Operable / 理解可能 Understandable / 堅牢性 Robust) の下に達成基準が並び、レベル A (最低限) / AA (実務標準) / AAA (最高水準) の3段階で評価します。実務では AA 準拠が事実上のスタンダードで、米国 ADA 訴訟・欧州 EAA・日本のJIS X 8341-3 すべてが AA を参照します。WCAG 2.2 では9つの新基準 (例: 2.4.11 Focus Not Obscured, 2.5.7 Dragging Movements, 2.5.8 Target Size Minimum 24×24CSSpx) が追加されました。WCAG 3.0 はドラフト段階で、評価モデルが達成基準ベースから「Outcomes」+ スコアリングへ大きく変わる方向です。

### 実装例

- EXBANK サイトを WCAG 2.2 AA 準拠で監査
- 2.4.11 Focus Not Obscured: フォーカス枠が他要素で隠れないこと
- 2.5.8 Target Size: タップ領域 24×24 CSS px 以上

### 出典

- [W3C - Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)

---

## WebAuthn / Passkey (Web Authentication)

URL: https://exbk.jp/glossary/webauthn
読み: ウェブオースン パスキー
カテゴリ: general

### 短い定義 (TL;DR)

WebAuthn は、公開鍵暗号でフィッシング耐性のある認証を実現するW3C標準で、Passkey はその利用者向け呼称です。パスワードレス認証の主流になりつつあります。

### 詳細解説

WebAuthn は W3C と FIDO アライアンスが策定した認証API標準 (FIDO2 の構成要素) で、ユーザーのデバイスが秘密鍵を保持しサーバーが公開鍵だけを保管する公開鍵暗号ベースの認証を提供します。秘密鍵がデバイス内のセキュアエレメント (Secure Enclave / TPM / YubiKey) に閉じ込められるためフィッシングサイトで詐取できず、オリジン (RP ID) との結びつきがプロトコルレベルで強制されるためフィッシング耐性が極めて高いのが特徴です。Passkey は WebAuthn を一般ユーザー向けに分かりやすく言い換えた呼称で、Apple・Google・Microsoft が iCloud Keychain・Google Password Manager 等でクラウド同期Passkeyを実装し、デバイス間で透過的に使えるようにしています。導入APIは navigator.credentials.create() / get() の2つで、attestation・user verification を制御します。

### 実装例

- Google アカウントは Passkey でパスワードレスログイン
- 1Password / iCloud Keychain で Passkey をクラウド同期
- navigator.credentials.create({ publicKey: ... }) で登録

### 出典

- [W3C - Web Authentication: An API for accessing Public Key Credentials Level 3](https://www.w3.org/TR/webauthn-3/)

---

## WebDAV (Web Distributed Authoring and Versioning)

URL: https://exbk.jp/glossary/webdav
読み: ウェブダブ
カテゴリ: infra

### 短い定義 (TL;DR)

WebDAV (Web Distributed Authoring and Versioning) は HTTP を拡張したファイル共有プロトコルで、リモートのファイルをローカルファイルシステムのように扱えます。Nextcloud の同期はこの上で動作します。

### 詳細解説

WebDAV は RFC 4918 で標準化された HTTP/1.1 拡張プロトコルです。GET/PUT に加え PROPFIND・MKCOL・COPY・MOVE・LOCK 等のメソッドでファイルシステム操作を実現します。Nextcloud Desktop / Cyberduck / Finder (macOS) / エクスプローラ (Windows) はすべて WebDAV クライアントとして Nextcloud に接続できます。SSL/TLS で暗号化することが標準で、認証は Basic / OAuth が一般的。

### 実装例

- Nextcloud のエンドポイント: /remote.php/dav/files/<user>/
- macOS Finder の「サーバへ接続」で直接マウント
- rclone で Dropbox から Nextcloud へ移行

### 出典

- [RFC 4918 - HTTP Extensions for WebDAV](https://www.rfc-editor.org/rfc/rfc4918)

---

## ワークスペース (Workspace)

URL: https://exbk.jp/glossary/workspace-gtm
読み: ワークスペース
カテゴリ: analytics

### 短い定義 (TL;DR)

ワークスペースは GTM で複数人が並行して変更作業をするための独立した作業空間です。1 コンテナあたり Free 版で最大 3 ワークスペース、360 版で 10 ワークスペースまで持てます。

### 詳細解説

ワークスペース (Workspace) は GTM で複数人が並行して変更作業を行うために用意された独立した作業空間 (ブランチのような概念) で、1 コンテナあたり Free 版で最大 3 ワークスペース、360 版で 10 ワークスペースまで作成できます。デフォルトで 1 つの「Default Workspace」が作成されており、追加ワークスペースを作ることで「メンバー A は新キャンペーンの計測タグ追加」「メンバー B はバグ修正」のように同時並行作業が可能になります。1 つのワークスペースで変更を確定 (公開) すると、他のワークスペースには「最新の変更が適用されました」という同期通知が表示され、変更を取り込むかどうかを選択できます。コンフリクト (同じタグを 2 ワークスペースで編集) が発生した場合は、自動マージ可能な場合は自動で、不可能な場合は手動マージで解決します。ワークスペース単位でプレビュー・ロールバックが独立しているため、本番影響を最小化しながら大規模な計測改修を進められます。

### 実装例

- 新キャンペーン用に「2026 春キャンペーン」ワークスペースを切り社内検証する
- 緊急修正用に hotfix ワークスペースを作り独立してデプロイする
- コンフリクト発生時に手動マージで両者の変更を統合する

### 出典

- [Tag Manager ワークスペース](https://support.google.com/tagmanager/answer/7499069)

---

## X Ads (Twitter Ads) (X Ads (旧 Twitter Ads))

URL: https://exbk.jp/glossary/x-ads
読み: エックスアズ
カテゴリ: ads

### 短い定義 (TL;DR)

X Ads は X (旧 Twitter) のタイムラインや検索面に広告配信できるプラットフォームです。トレンドや会話に紐づくターゲティングと、リツイート連鎖による拡散効果が特徴です。

### 詳細解説

X Ads は X Corp. が提供する広告配信プラットフォームで、ホームタイムライン、検索結果、トレンドタブにプロモートツイート・プロモートトレンド・プロモートアカウントを配信できます。キーワードターゲティング (特定の単語を含むツイートを行ったユーザーに配信)、フォロワーターゲティング (特定アカウントのフォロワーに配信)、会話トピックなど X 独自のシグナルが強みです。2023 年以降は X Premium との連動や Grok 連携が進み、Vertical Video 広告 (縦型動画) の配信面も拡張されています。

### 実装例

- 競合アカウント @example_brand のフォロワーにフォロワーターゲティングで広告配信
- ローンチ当日にプロモートトレンドで全国 1 位に押し上げて認知獲得する
- Conversion Tracking タグで LP 申込までの CV を計測する

### 出典

- [X Ads Help Center](https://business.x.com/en/help)
- [X for Business](https://business.x.com/)

---

## XSS (Cross-Site Scripting)

URL: https://exbk.jp/glossary/xss
読み: クロスサイトスクリプティング
カテゴリ: general

### 短い定義 (TL;DR)

XSS (Cross-Site Scripting) は、悪意あるスクリプトをWebページに埋め込み他ユーザーのブラウザで実行させる攻撃で、Reflected・Stored・DOM-based の3類型があります。

### 詳細解説

XSS は、攻撃者がユーザー入力を受けるフォームやURLパラメータに JavaScript を仕込み、サーバーがエスケープせずに出力すると、被害者ブラウザでスクリプトが実行されてセッションCookie盗用・偽フォーム表示・キーロガー等を引き起こす攻撃です。Reflected XSS (URLパラメータが即時反射) / Stored XSS (DBに保存され閲覧時に発火) / DOM-based XSS (クライアントJSが innerHTML 等で展開) の3類型があります。対策はOWASPに従い (1) 出力時に文脈別エスケープ (HTML/属性/JS/CSS/URL) (2) CSP で 'unsafe-inline' を禁止しnonce運用 (3) HttpOnly Cookie (4) DOMPurify 等のサニタイザ (5) フレームワーク (React/Vue) のエスケープを信頼 が王道です。OWASP Top 10 でも常連の脅威です。

### 実装例

- <script>alert(1)</script> を検索フォームに入力 → Reflected XSS
- React で dangerouslySetInnerHTML を避け自動エスケープに依存
- DOMPurify.sanitize(userHtml) で危険タグを除去

### 出典

- [OWASP - Cross Site Scripting Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)

---

## Yahoo!広告 (Yahoo! JAPAN 広告 (旧 Yahoo!プロモーション広告))

URL: https://exbk.jp/glossary/yahoo-japan-ads
読み: ヤフージャパンアズ
カテゴリ: ads

### 短い定義 (TL;DR)

Yahoo!広告は LINEヤフー社が運営する Yahoo! JAPAN の広告プラットフォームです。検索広告 (Yahoo!検索広告) とディスプレイ広告 (YDA) の 2 系統があり、シニア層・PC ユーザーに強くリーチできるのが特徴です。

### 詳細解説

Yahoo!広告は LINEヤフー社が提供する広告配信プラットフォームで、検索広告とディスプレイ広告 (YDA: Yahoo! Display Ads) の 2 系統に分かれます。Yahoo! JAPAN 検索結果、Yahoo!ニュース、Yahoo!知恵袋、Yahoo!路線情報、Yahoo!天気など同社のメディア群に加え、Yahoo!パートナーネットワーク (バリューコマース等) にも配信されます。Google Ads より日本のシニア層・PC 利用者の比率が高く、不動産・金融・保険・自動車・通販などのレガシー業界で根強い需要があります。LINEヤフー統合後は LINE 広告との接点も増えています。

### 実装例

- シニア向け健康食品を Yahoo! 検索広告で 50 代以上にリーチする
- YDA の動画広告で Yahoo!ニュース面に動画クリエイティブを配信する
- サイトリターゲティングで自社サイト訪問者を Yahoo!知恵袋面で追跡する

### 出典

- [Yahoo!広告 公式](https://ads-promo.yahoo.co.jp/)
- [Yahoo!広告ヘルプ](https://ads-help.yahoo.co.jp/)

---

## YMYL (Your Money or Your Life)

URL: https://exbk.jp/glossary/ymyl
読み: ワイエムワイエル
カテゴリ: seo

### 短い定義 (TL;DR)

YMYL (Your Money or Your Life) は、Google が定義する「ユーザーの健康・財産・安全・幸福に重大な影響を与える可能性のあるトピック」のことです。医療・金融・法律・ニュース等が該当し、特に厳格な品質評価が適用されます。

### 詳細解説

YMYL は Google の「検索品質評価ガイドライン (Search Quality Rater Guidelines)」で定義されるカテゴリで、間違った情報がユーザーの「お金 (Money)」または「人生 (Life)」に重大な悪影響を及ぼす可能性のあるトピックを指します。具体例は、1) 医療・健康情報 (病気・薬・治療法)、2) 金融情報 (投資・税金・保険)、3) 法律情報、4) ニュース・時事問題、5) 公共サービス情報、6) 安全性情報 (家庭の安全・災害)、です。YMYL ページには通常より厳格な EEAT (Experience, Expertise, Authoritativeness, Trustworthiness) 評価が適用され、a) 専門家による執筆/監修、b) 著者プロフィール明示、c) 一次情報の引用、d) 運営組織の信頼性、が求められます。2018年8月の Medic Update では多くの YMYL 健康サイトが順位を50%以上下げる事態となりました。

### 実装例

- 医療系記事は医師監修を明示し、Person スキーマで監修者情報を構造化します
- 金融記事は金融庁ライセンスや FP 資格保有者の執筆/監修が信頼性向上に必須です
- YMYL サイトは E-E-A-T シグナルの欠如で順位を一気に20-30位落とす可能性があります

### 出典

- [Google - Search Quality Rater Guidelines (PDF)](https://services.google.com/fh/files/misc/hsw-sqrg.pdf)

---

## YouTube 広告 (YouTube Ads (Google Ads 動画キャンペーン))

URL: https://exbk.jp/glossary/youtube-ads
読み: ユーチューブ広告
カテゴリ: ads

### 短い定義 (TL;DR)

YouTube 広告は YouTube に動画広告を配信できる仕組みで、Google Ads から運用します。スキッパブル/ノンスキッパブルインストリーム、バンパー、Shorts、In-Feed など多様なフォーマットがあります。

### 詳細解説

YouTube 広告は Google Ads の動画キャンペーンを通じて配信される、世界最大の動画広告プラットフォームです。月間ログインユーザー 25 億人以上にリーチでき、フォーマットは TrueView インストリーム (5 秒後にスキップ可能)、ノンスキッパブルインストリーム (15 秒固定)、バンパー (6 秒スキップ不可)、In-Feed (検索結果)、YouTube Shorts、マストヘッド (TOP 面ジャック) があります。課金は CPV (動画視聴単価)、CPM、CPA など。Google Ads のアフィニティ・購買意向・カスタムオーディエンスでターゲティング可能です。

### 実装例

- TrueView インストリームで CPV 5 円・視聴率 25% を達成する
- バンパー広告 6 秒で認知ブランドリフト調査を実施する
- リマーケティングリストに対して特定動画の続編を配信する

### 出典

- [YouTube 広告 (Google Ads)](https://ads.google.com/intl/ja_jp/home/campaigns/video-ads/)
- [Google Ads ヘルプ - 動画広告](https://support.google.com/google-ads/answer/2375464)

---

## Z パターン視線 (Z-Pattern Reading)

URL: https://exbk.jp/glossary/z-pattern
読み: ゼットパターンしせん
カテゴリ: general

### 短い定義 (TL;DR)

Z パターン視線は、テキスト量が少なくビジュアル重視のページで視線が Z 字を描く現象で、ランディングページのCTA配置設計で参照されます。

### 詳細解説

Z パターン視線は、テキスト密度が低くビジュアル要素が支配的なページ (LP・スプラッシュ・カード型レイアウト) で見られる視線パターンで、利用者は (1) 左上から右上へ水平移動 (2) 右上から左下へ斜めに移動 (3) 左下から右下へ水平移動、と Z の形を描きます。F パターンが「読む」ページで現れるのに対し、Z パターンは「眺める」ページの傾向で、ロゴ・ナビ → メインビジュアル → CTA の動線設計に活用されます。実際にはユーザー目的やコンテンツ密度で多様化するため、F/Z は厳密な法則ではなく「ビジュアル階層・優先度・余白を意識する」ためのメンタルモデルとして用いるのが妥当です。NN/g もこの点を強調し、過度な単純化を戒めています。

### 実装例

- LP の Hero: 左上ロゴ → 右上 CTA → 左下キャッチ → 右下 CTA で Z 動線
- シンプルなランディングページの主要要素を Z に沿って配置
- F/Z は厳密法則ではなく視覚階層チェック用メンタルモデル

### 出典

- [NN/g - F-Shaped Pattern of Reading on the Web](https://www.nngroup.com/articles/f-shaped-pattern-reading-web-content/)

---

## Zapier

URL: https://exbk.jp/glossary/zapier
読み: ザピアー
カテゴリ: ai

### 短い定義 (TL;DR)

Zapier (ザピアー) はノーコードのワークフロー自動化サービスで、6,000 以上のアプリと連携可能です。シンプルな 'Trigger → Action' のフローを作るのに最適で、業界最大手です。

### 詳細解説

Zapier は 2011 年創業で、ノーコード自動化の代名詞的存在。6,000+ アプリ統合は業界最大級。料金は無料プラン (月 100 タスク) から Professional 月 $19.99〜。AI 機能 (Zapier AI / ChatGPT 統合) も近年強化。Make / n8n と比較するとシンプルなフロー向きで、複雑な分岐処理は弱め。法人 / SMB ユーザーが多く、エンタープライズ実績も豊富です。

### 実装例

- Gmail 受信 → Trello カード作成
- Calendly 予約 → Slack 通知
- Zapier AI で自然言語からフロー生成

### 出典

- [Zapier](https://zapier.com)

---

## ツァイガルニク効果 (Zeigarnik Effect)

URL: https://exbk.jp/glossary/zeigarnik-effect
読み: ツァイガルニクこうか
カテゴリ: general

### 短い定義 (TL;DR)

ツァイガルニク効果は「未完了のタスクは完了したタスクより記憶に残りやすい」という心理現象で、プログレスバーやオンボーディング設計の根拠になります。

### 詳細解説

ツァイガルニク効果 (Zeigarnik Effect) は、ロシアの心理学者 Bluma Zeigarnik が 1927年論文で発見した「未完了の課題は完了した課題よりも記憶に残りやすく、完了させたいという心理的緊張を生む」という現象です。UX/CX への応用は (1) オンボーディングで「あと2ステップで完了」と未完了タスクを可視化 (2) プロフィール完成度バーで未入力欄を提示 (3) コース学習で進行率と次レッスンを表示 (4) ECカートに「あと ¥1,000 で送料無料」のような近接ゴール表示 (5) ゲーミフィケーションでバッジ未取得を見せる などです。LinkedIn の「プロフィール強度メーター」、Duolingo の連続日数、Slack の「セットアップ完了 X/Y」などが代表例です。乱用すると煽りに見えるので、本当にユーザー利益のある未完了に絞ることが信頼維持の鍵です。

### 実装例

- LinkedIn のプロフィール完成度メーターで未入力を可視化
- Duolingo のコース進行率バーと次のレッスン誘導
- EC で「あと ¥1,500 で送料無料」を表示

### 出典

- [Laws of UX - Zeigarnik Effect](https://lawsofux.com/zeigarnik-effect/)

---

## Zero-shot

URL: https://exbk.jp/glossary/zero-shot
読み: ゼロショット
カテゴリ: ai

### 短い定義 (TL;DR)

Zero-shot は、LLM に例示なしで初見のタスクを実行させる方式です。「○○ してください」の指示だけで結果を返してもらうため、最もシンプルですが精度は few-shot に劣ることが多いです。

### 詳細解説

Zero-shot は事前学習で得た知識のみで未知のタスクをこなせる LLM の能力を指します。GPT-3 以降のモデルは zero-shot でも実用レベルの結果を返しますが、複雑なタスクや特殊な出力形式が必要な場合は few-shot に劣ります。プロトタイプ段階や試行回数の多いタスクには zero-shot、本番運用や精度が重要なタスクには few-shot や fine-tuning を選ぶのが定石です。

### 実装例

- 「この記事を要約してください」で要約取得
- 「JSON で 3 件商品を返して」だけで構造化出力
- Claude Code CLI のような「タスクを丸投げ」運用

---


<!-- entries: 400 / generated: 2026-07-16T01:25:57.932Z -->