# Alejandro Rioja — JA > Alejandro Rioja — AI agent systems for founders. Plus posts on growth, marketing, sales, ops, and business from inside live P&Ls. Site: https://alejandrorioja.com/ja/ Author: Alejandro Rioja Language: ja --- ## イベント駆動型 vs スケジュール型エージェント:どの仕事にどのパターンを使うか Source: https://alejandrorioja.com/ja/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/ Published: 2026-05-31 Updated: 2026-05-31 Tags: AI Agents TL;DR: ユーザーアクションが即時応答を必要とする場合はイベント駆動型を使う——数秒以上の遅延で体験が壊れる。タイミングが予測可能なバッチ処理や定期処理にはスケジュール型を使う。制約:イベント駆動型はステートレスかつ高速でなければならない。スケジュール型はステートフルで多少遅くても構わない。 ## 目次 _2026年5月更新。_ **TL;DR:** ユーザーアクションが即時応答を必要とする場合はイベント駆動型を使う——数秒以上の遅延で体験が壊れる。タイミングが予測可能なバッチ処理や定期処理にはスケジュール型を使う。制約:イベント駆動型はステートレスかつ高速でなければならない。スケジュール型はステートフルで多少遅くても構わない。 **[オペレーターの視点]** 私はコンサルティングブランドとPickleland(テキサス州Pflugerville のピックルボール施設)で30以上の本番エージェントを運用している。どれも2つのパターンのどちらかに当てはまる:イベントで起動するか、時計で起動するか。この選択を誤るとお金が無駄になり、壊れた体験を届けることになる。 ## 2つのパターンをわかりやすく **イベント駆動型エージェント**は何かが起きたから目を覚ます。予約が入った。コメントが投稿された。フォームが送信された。トリガーは外部にあり、タイミングは予測不能だ。仕事:素早く反応すること。 **スケジュール型エージェント**は時計が言ったから目を覚ます。毎朝7時。毎週日曜18時。毎時0分。トリガーは内部にあり、完全に予測可能だ。仕事:丁寧な処理を行うこと。 それだけだ。複雑に考えるな。アーキテクチャは1つの問いへの答えから決まる:*ユーザーやシステムは今すぐ応答が必要か、特定の時刻まで待てるか?* ## イベント駆動型:ソーシャルリプライエージェント 私のソーシャルリプライエージェントは、監視しているFacebookの投稿に新しいコメントが届くたびに起動する。エージェントはコメントを読み、意図を分類し(質問、クレーム、褒め言葉、スパム)、返信を下書きして投稿する——信頼度が低ければ人間によるレビュー用にフラグを立てる。 往復全体が30秒以内に完了しないと、返信が古く感じられる。これはイベント駆動型の問題だ。 ソーシャル監視サービスからのwebhookを処理する、簡略化したCloudflare Workerを示す: ```typescript // workers/social-reply.ts export default { async fetch(request: Request, env: Env): Promise { if (request.method !== "POST") { return new Response("Method not allowed", { status: 405 }); } // webhookの署名を検証 const sig = request.headers.get("x-webhook-signature") ?? ""; const body = await request.text(); const valid = await verifySignature(body, sig, env.WEBHOOK_SECRET); if (!valid) return new Response("Unauthorized", { status: 401 }); const event = JSON.parse(body) as SocialCommentEvent; // 分類して返信 — 200を素早く返すためにasyncで処理 env.REPLY_QUEUE.send(event); return new Response("OK", { status: 200 }); }, }; // キューコンシューマー — 実際のAI処理を行う export const queue: ExportedHandlerQueueHandler = async (batch, env) => { for (const msg of batch.messages) { const comment = msg.body; const classification = await classifyComment(comment.text, env); if (classification.intent === "spam") { msg.ack(); continue; } const reply = await draftReply(comment, classification, env); if (classification.confidence > 0.85) { await postReply(comment.postId, comment.id, reply, env); } else { await flagForReview(comment, reply, env); } msg.ack(); } }; ``` 2点に注目してほしい。第一に、fetchハンドラーはすぐに200を返し、実際の処理をキューに委譲する。これによりwebhookの応答を高速に保ち、監視サービスがリトライするのを防ぐ。第二に、キューコンシューマーがオープンなHTTP接続からの時間的プレッシャーなしに実際のAI呼び出しを実行する。 ## スケジュール型:Picklelandイベントプロモーター Picklelandはコートとイベントを管理している。毎週、席を埋めるために誰かが今後のイベントを適切なFacebookグループに投稿する必要がある。これは純粋な定期バッチ処理だ——ユーザーアクションはトリガーにならず、リアルタイムである必要もない。 Picklelandイベントプロモーターはcronで動き、予約システムから4日以内のイベントを確認し、マッチした各Facebookグループ向けに投稿の下書きを作成し、何かが公開される前に私のレビュー用に提示する。 ```typescript // workers/event-promoter.ts export default { async scheduled( event: ScheduledEvent, env: Env, ctx: ExecutionContext ): Promise { ctx.waitUntil(runPromoter(env)); }, }; async function runPromoter(env: Env): Promise { // 予約システムからイベントを取得 const upcomingEvents = await fetchUpcomingEvents(env, { daysAhead: 4 }); if (upcomingEvents.length === 0) return; const drafts: PromoDraft[] = []; for (const event of upcomingEvents) { // 各イベントを適切なFBグループにマッチ const groups = await matchFacebookGroups(event, env); for (const group of groups) { const post = await draftPromoPost(event, group, env); drafts.push({ event, group, post }); } } // レビュー用にAirtableに下書きを保存 — 何も自動投稿しない await saveDraftsForReview(drafts, env); // Slackで私に通知 await notifyOperator( `${drafts.length}件のプロモ下書きがレビュー待ち`, env ); } ``` 全体をつなぐwrangler設定: ```toml # wrangler.toml [[triggers]] crons = ["0 18 * * 0"] # 毎週日曜18時 UTC ``` スケジュール型エージェントがイベント駆動型にできないことに注目してほしい:複数のイベントを繰り返し処理し、データベースに書き込み、サマリー通知を送る。バッチ処理をしているのだ。イベント駆動型エージェントは軽量に保ち、素早く応答する必要がある。 ## スケジュール型:デイリーブリーフ 毎朝7時にデイリーブリーフエージェントが動く。夜間のメール、カレンダー、最重要タスク、関連としてフラグを立てたニュースを取得する。すべてを1つのドキュメントにまとめてAI Workspaceフォルダに置く。 これは純粋なスケジュール型だ。トリガーとなるイベントは存在しない——ただ毎朝仕事を始める前に欲しいのだ。 ```typescript // workers/daily-brief.ts export default { async scheduled( event: ScheduledEvent, env: Env, ctx: ExecutionContext ): Promise { ctx.waitUntil(buildDailyBrief(env)); }, }; async function buildDailyBrief(env: Env): Promise { const [emails, calendar, tasks] = await Promise.all([ fetchOvernightEmails(env), fetchTodayCalendar(env), fetchTopTasks(env), ]); const brief = await synthesizeBrief({ emails, calendar, tasks }, env); await writeToWorkspace(brief, env); } ``` ```toml [[triggers]] crons = ["0 7 * * *"] # 毎日7時 UTC ``` 並列の`Promise.all`は意図的だ。スケジュール型エージェントには待っている人間がいない——でも必要以上に遅くすべきではない。すべてのデータソースを並列に取得し、AIの合成は一度だけ実行する。 ## イベント駆動型が失敗するとき 最もよく見る失敗パターン:ハンドラーでやりすぎるイベント駆動型エージェントを作ること。 予約が入る。エージェントは顧客プロフィールを取得し、3つの外部APIからエンリッチし、パーソナライゼーションモデルを実行し、CRMに書き込み、確認メールを送り、ダッシュボードを更新する。全体で45秒かかる。予約プラットフォームは200を素早く受け取れなかったのでリトライする。これでエージェントが2回動く。 修正方法はソーシャルリプライエージェントと同じ:即座に200を返し、イベントをキューに送り、キューコンシューマーに重い処理を非同期でやらせる。 もう1つの失敗パターン:実際には定期的な作業にイベント駆動型を使うこと。「週次サマリーを送る」はイベントではない。合成的なcron webhookに接続するな——適切なスケジュールトリガーを使え。 ## スケジュール型が失敗するとき スケジュール型エージェントは、仕事が実際にlatency敏感なときに失敗する。ユーザーがフォームを送信して処理エージェントが5分cronで動いていたら、ユーザーは最大5分間スピナーを見続ける。これはスケジュールジョブではない——スケジュール済みのふりをした遅いイベント駆動型ジョブだ。 もう1つの失敗:無制限の処理に膨らむスケジュール型エージェント。cronが毎分動いて各呼び出しが何百ものレコードを処理できるなら、CloudflareのCPU制限にすぐ達する。cronの間隔を延ばすか、呼び出しごとの作業を制限するキューを追加するか、長時間の調整にはDurable Objectsに切り替える。 ## パターンを組み合わせる:予約パイプライン 一部のワークフローは本当に両方が必要だ。Pickleballの予約パイプラインはこう動く: 1. **イベント駆動型**:新規予約webhook → 予約を確認、顧客に領収書を送信、空き状況を更新。10秒以内に完了する必要がある。 2. **スケジュール型**:毎週日曜 → 先週の予約をすべてレビュー、サマリーレポートを生成、異常をフラグ(重複予約、通常外のキャンセル率)。 同じドメイン、2つのパターン、2つのエージェント。イベント駆動型がリアルタイムのユーザー体験を担う。スケジュール型が週次の運営レビューを担う。データベースは共有するがそれ以外は分離している。 「全部やる」1つのエージェントにまとめようとするな。イベントには遅すぎ、バッチ処理にはリアルタイムフローと結合しすぎるものができあがる。 ## Cloudflare Workers:両方に最適なインフラである理由 Cloudflare Workersは両方のパターンをネイティブに処理する: - `fetch`ハンドラー → イベント駆動型(webhook、APIコール) - `scheduled`ハンドラー → cron型(wrangler.tomlの`[[triggers]]`経由) - `queue`コンシューマー → HTTPレイヤーから分離した非同期処理 エッジデプロイメントにより、イベント駆動型エージェントはグローバルに高速応答する。無料枠は両方のパターンを何も使わずにプロトタイプするのに十分寛大だ。統一された`wrangler.toml`設定により、2つのパターンに対して2つの別々のインフラ設定を管理する必要がない。 Workersがうまく解決できない唯一のこと:数分以上実行する必要のあるエージェント。その場合はDurable Objectsを使うか、より長時間動くバックエンドに委任する。 ## オペレーターの結論 エージェントのコードを1行書く前にパターンを決める。人間が待っているものにはイベント駆動型、時計で動くものにはスケジュール型。イベント駆動型のハンドラーは軽量に——素早く返し、作業をキューに入れる。スケジュール型エージェントは並列に——並列化できるものを直列化するな。アーキテクチャはシンプルだ。それを破ることが複雑さの源になる。 --- ## ローカルビジネスのGEO:AI検索で実店舗を引用させる方法 Source: https://alejandrorioja.com/ja/geo-for-local-business-getting-a-brick-and-mortar-cited-by-ai-search/ Published: 2026-05-31 Updated: 2026-05-31 Tags: GEO, Marketing TL;DR: 実店舗をAI検索エンジンに引用してもらうには、まずGoogleビジネスプロフィールを最適化することが最重要シグナルです。次にLocalBusiness JSON-LDスキーマを追加し、ウェブ全体でNAP(名前・住所・電話番号)を一致させ、継続的に新しいレビューを獲得することが必要です。AI引用を購入することはできませんし、GBPにキーワードを詰め込んでも効果はありません。 ## 目次 _2026年5月更新_ **TL;DR:** 実店舗をAI検索エンジンに引用してもらうには、まずGoogleビジネスプロフィールを最適化することが最重要シグナルです。次にLocalBusiness JSON-LDスキーマを追加し、ウェブ全体でNAP(名前・住所・電話番号)を一致させ、継続的に新しいレビューを獲得することが必要です。AI引用を購入することはできませんし、GBPにキーワードを詰め込んでも効果はありません。 **[オペレーターの視点]** 私はテキサス州プフルーガービルにあるピックルボール施設「Pickleland」を経営しています。ChatGPTとPerplexityで「オースティン近郊のベストピックルボールコート」を検索したとき、Google Mapsでは上位表示されているにもかかわらず、自分の施設が出てこないことに気づきました。何を変えたのか、そしてなぜ効果があったのかをお伝えします。 --- ## AI検索がローカルビジネスで異なる理由 従来のローカルSEOは、マップパックと青いリンクでのランキングが目標でした。AI検索は異なります。ChatGPT、Perplexity、GoogleのAI概要は回答を合成し、特定のソースを引用します。ローカルクエリに対しては、Googleビジネスプロフィールのデータ、ウェブサイトの構造化データ、レビュープラットフォーム、権威あるディレクトリ掲載の組み合わせからデータを取得します。 良いニュース:ハードルは思ったより低いです。ほとんどの実店舗は構造化データを無視し、GBPを放置しています。基本を正確かつ継続的に実施すれば、際立つことができます。 悪いニュース:近道はありません。AIエンジンに引用してもらうために支払うことはできません。「AI引用」広告プロダクトは存在しません。できることは、AIがあなたのビジネスを理解しやすく、信頼しやすくすることです。 --- ## Googleビジネスプロフィールが基盤 一つだけレバーを選ぶなら、Googleビジネスプロフィール(GBP)です。誰かがAIアシスタントに「オースティン近郊のベストピックルボールコート」と尋ねると、AIはGBPデータに大きく依存します。理由は、GBPが構造化された検証済みデータベースだからです。ウェブで学習したAIモデルや、Perplexityのようなライブ検索ツールはGBPシグナルを高信頼性として扱います。 GBPでやるべきこと: - **すべてのフィールドを完成させる。** カテゴリ、説明、営業時間(祝日含む)、属性、サービス/メニュー。空のフィールドは逃したシグナルです。 - **メインカテゴリを正確に使う。** Pickleandにとっては「ピックルボールコート」であり、「スポーツ複合施設」ではありません。AIエンジンはカテゴリデータを読み取ります。 - **定期的に写真を追加する。** GBPは新鮮さを評価します。月に少なくとも2回、コート、イベント、施設内部の新しい写真をアップロードしましょう。 - **更新を投稿する。** GBP投稿はインデックスされます。「自分のパドルを持参する必要がありますか?」のような質問に答える短い投稿(150〜300語)を書きましょう。 - **すべてのQ&Aに回答する。** GBPのQ&Aセクションは公開されてインデックスされています。最もよく聞かれる質問を誰も投稿していなければ、自分で追加して回答しましょう。 やってはいけないこと:GBPの説明に「オースティン ベスト ピックルボール 最安値 今すぐ営業中」のようなキーワードを詰め込まないでください。スパムのように見え、AIには役立ちませんし、Googleがプロフィールを停止する可能性があります。 --- ## LocalBusinessスキーマ:構造化データ層 GBPはGoogleエコシステムを担当します。非Google AI検索(Perplexity、ブラウジング付きChatGPT、Bingベースのツール)では、ウェブサイトの構造化データが主要シグナルです。 ホームページとコンタクトページに`LocalBusiness` JSON-LDブロックを追加してください。Pickleandで使用しているスキーマを以下に示します: ```json { "@context": "https://schema.org", "@type": "SportsActivityLocation", "name": "Pickleland", "description": "テキサス州プフルーガービルの屋内ピックルボール施設。専用コート8面、オープンプレー、リーグ戦、レッスンあり。", "url": "https://pickleland.com", "telephone": "+1-512-000-0000", "address": { "@type": "PostalAddress", "streetAddress": "123 Pickleland Dr", "addressLocality": "Pflugerville", "addressRegion": "TX", "postalCode": "78660", "addressCountry": "US" }, "geo": { "@type": "GeoCoordinates", "latitude": 30.4349, "longitude": -97.6200 }, "openingHoursSpecification": [ { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"], "opens": "06:00", "closes": "22:00" }, { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Saturday","Sunday"], "opens": "07:00", "closes": "21:00" } ], "priceRange": "$$", "amenityFeature": [ { "@type": "LocationFeatureSpecification", "name": "Indoor Courts", "value": true }, { "@type": "LocationFeatureSpecification", "name": "Equipment Rental", "value": true }, { "@type": "LocationFeatureSpecification", "name": "Lessons Available", "value": true } ], "sameAs": [ "https://www.google.com/maps?cid=YOUR_CID", "https://www.yelp.com/biz/pickleland-pflugerville", "https://www.facebook.com/pickleland" ] } ``` `sameAs`配列は、スキーマエンティティをGBP、Yelp、Facebookページに明示的に接続します。AIエンジンはこれを使用してクロスリファレンスを行い、これらすべてが同じビジネスであることを確認します。`geo`座標は重要です — Perplexityは近接マッチングを行います。そして`openingHoursSpecification`のマシンリーダブルフォーマットは、誰かが「Pickleandは日曜日に開いていますか?」と尋ねたときのAI回答に直接取り込まれます。 適切な場合は、汎用的な`LocalBusiness`タイプではなく`SportsActivityLocation`を使用してください — タイプが具体的であるほど、AIがあなたをより正確に分類できます。 --- ## NAP一貫性:退屈だが重要 NAPとは名前、住所、電話番号(英語:Name, Address, Phone)の略です。ビジネス名がGoogleで「Pickleland」、Yelpで「Pickleland LLC」、Facebookで「Pickleland - Pflugerville」、ローカルディレクトリで「Pickleland Pickleball」と表示されていると — AIエンジンは4つの異なるエンティティを認識し、すべてへの信頼度を下げます。 NAPオーディットを実施してください: 1. Google、Yelp、Facebook、Apple Maps、Bing Places、Foursquare、TripAdvisor、および業界特化ディレクトリでビジネス名を検索します。 2. すべての変形を文書化します。 3. 修正します — ほとんどのプラットフォームでは直接リスティングをクレームまたは編集できます。 どこでも使用する名前は、Googleビジネスプロフィールに記載されているものと完全に一致する必要があります。Pickleandの場合、それは「Pickleland」です — 接尾辞なし、都市名の追加なし。 電話番号の形式も重要です。`(512) 000-0000`または`+1-512-000-0000`のように、どこでも同じ形式を使用してください。JSON-LDの`sameAs`リンクはAIエンジンが点をつなぐのに役立ちますが、一貫したNAPがそもそもエンティティの信頼性を構築するものです。 --- ## レビュー頻度:新鮮さはAIシグナル AI検索エンジンは星評価だけでなく、レビューの新鮮さと頻度も確認します。200件のレビューがあっても最後のレビューが18か月前のビジネスは、80件のレビューで先週3件投稿されたビジネスより低くランク付けされます。 Pickleandでは、レビュー頻度を業務に組み込みました: - オープンプレーセッションが終わるたびに、スタッフメンバーがGoogleレビューページへの直接リンクを含むフォローアップメッセージを送信します。 - ポジティブとネガティブ両方のすべてのレビューに24時間以内に返信します。返信活動はクローラーへの新鮮さシグナルとなります。 - 毎月、最も満足している常連客を特定し、個人的にフィードバックを共有するよう依頼します。 約4か月で43件から190件のレビューに増加しました。AI引用への影響は測定可能でした:強い新鮮さを持って100件のレビューマークを超えてから約6週間後に、Pickleandは「オースティンエリアのピックルボール」のPerplexity回答に表示され始めました。 偽のレビューを購入しないでください。停止リスク以外にも、AIエンジンは不自然なレビューのクラスター(類似のタイムスタンプ、汎用的な表現、履歴のないレビュアーアカウント)を検出するのがますます得意になっています。 --- ## AIへの質問方法に合わせたQ&Aコンテンツ 従来のSEOはキーワードフレーズをターゲットにします。GEOは質問をターゲットにします — 特に人々がAIアシスタントに打ち込んだり話しかけたりする自然言語の質問です。 誰かがChatGPTに質問する方法とGoogleに入力する方法の違いを考えてみてください: - Google:`ピックルボール コート オースティン` - ChatGPT:`オースティン近郊で平日の朝開いている屋内ピックルボールコートのベストはどこですか?` あなたのコンテンツは長い形式のバージョンに答える必要があります。以下の質問に直接答えるFAQやQ&Aの専用ページをサイトに作成してください: - 「自分のパドルを持参する必要がありますか?」(用具の質問) - 「[施設]でピックルボールをプレーするといくらかかりますか?」 - 「[施設]は初心者に適していますか?」 - 「法人イベントのためにコートを予約できますか?」 - 「週末のオープンプレーの時間帯はいつですか?」 各回答を2〜4文で、直接的かつ完全に書いてください。AIエンジンはユーザーが一致する質問をしたときに、これらを一字一句そのまま抽出して表示します。PickleandのFAQ回答がPerplexityの回答でそのまま引用されているのを何度も見ています。 これにGBP投稿も活用してください:質問と回答の形式で構成された投稿を書きましょう。「Q:事前にコートを予約する必要がありますか?A:オープンプレーの時間帯(スケジュールをご確認ください)はウォークインも歓迎ですが、週末のピーク時間帯はコート予約をお勧めします。pickleland.comでご予約ください。」このフォーマットはAIフレンドリーでインデックス可能です。 --- ## 効果のないこと 限界について率直に述べます: **GBPの説明をキーワードで埋める**のはAI検索に役立ちません。スパムのように見え、プロフィールがフラグを立てられる可能性があります。人間向けに自然に書いてください。 **AI引用に支払う**のは製品として存在しません。「ChatGPTで引用してもらう」と主張する有料サービスはまやかしです。AI引用は編集的なものです — AIが最も関連性が高く信頼性の高い回答と判断するものに基づいています。 **一度のスキーマ設定**では不十分です。スキーマは最新の状態を保つ必要があります。営業時間が変わってGBPを更新したがJSON-LDは更新しなかった場合、矛盾したシグナルを作成することになります。四半期ごとのスキーマオーディットをルーティンに組み込みましょう。 **すべてのディレクトリを追いかける**のは収穫逓減です。AI検索の重みが最も高いプラットフォームに集中してください:Google、Yelp、Facebook、Apple Maps、Bing Places。業界特化ディレクトリ(私たちの場合、USA Pickleball施設ディレクトリなど)はその縦軸で権威性があるため価値があります。 --- ## オペレーターの結論 ローカルビジネスのGEOは複雑ではありません — ただ地味で、一貫性が必要なだけです。GBPを100%完成させ、サイトにクリーンなLocalBusinessスキーマを追加し、ウェブ全体でNAPを標準化し、業務にレビューのリズムを組み込んでください。4つすべてを実施すれば、AI検索エンジンは自信を持ってあなたを引用するために必要なすべてを持つことになります。私はPickleandでこれを実施し、実際の引用データで結果が現れています。今日GBPから始めてください — 1日午後の時間で完了し、効果はすぐに現れます。 --- ## AIエージェントが本当に機能しているかどうかの測り方 Source: https://alejandrorioja.com/ja/how-i-measure-whether-an-ai-agent-is-actually-working/ Published: 2026-05-31 Updated: 2026-05-31 Tags: AI Agents TL;DR: ほとんどのオペレーターは評価を完全にスキップし、エージェントが機能していると思い込んでいます。私のフレームワーク:5〜10個の既知の入力と期待される出力のゴールデンセットを構築し、合否基準を平易な言葉で定義し、毎週ログを確認する。10回の実際の実行前に複雑な評価システムを構築しないこと——それがモメンタムを殺すワナです。 ## 目次 _2026年5月更新。_ **TL;DR:** ほとんどのオペレーターは評価を完全にスキップし、エージェントが機能していると思い込んでいます。私のフレームワーク:5〜10個の既知の入力と期待される出力のゴールデンセットを構築し、合否基準を平易な言葉で定義し、毎週ログを確認する。10回の実際の実行前に複雑な評価システムを構築しないこと——それがモメンタムを殺すワナです。 **[オペレーターの視点]** 私はコンサルティングブランドとPickleland(テキサス州プフルーグヴィルのピックルボール施設)で30以上の本番AIエージェントを運用しています。ある時点で、エージェントの動作確認に費やす時間が実際に使う時間よりも長くなっていることに気づきました。これが私が行き着いた評価フレームワークです——博士号不要、カスタム評価プラットフォーム不要、Python不要。 ## 誰も話さない問題:エージェントは静かに劣化する 人間の従業員が仕事を間違えると、通常は気づきます。AIエージェントがゴミを生成し始めると、静かに、大規模に、何かが十分に壊れて人間がやっと確認するまで、ゴミを生成し続けます。 モデル更新後に「AIとして」という免責事項を追加し始めたコンテンツエージェントがありました。プロンプト変数名が変更されてチケットリンクを含めなくなったイベントプロモーターエージェントもありました。どちらも大きな音を立てて失敗しませんでした。どちらも静かに劣化しただけです。 解決策はNASAレベルの監視システムを構築することではありません。蓄積する前に劣化を検知するシンプルで再現可能なチェックを持つことです。 ## 評価とは何か(オペレーター向け) エンジニアはモデルでベンチマークを実行することを「eval」と言います。オペレーターにとっては、もっとシンプルなことを意味します:**エージェントが構築した目的通りのことをまだしているかどうかを教えてくれる再現可能なテスト。** 3つのコンポーネント: 1. **ゴールデンセット** — すでに見たことのある5〜10個の本物の入力と、良いことがわかっている期待される出力 2. **合否基準** — 何が合格かを定義する平易な言葉のルール 3. **定期チェック** — あなたまたはアシスタントが実際にリズムを持ってテストを実行する それだけです。フレームワークは不要。必要なのはシステムです。 ## ゴールデンセットの構築 本番ログから取り出します。すでに良い出力がどのようなものか知っている5〜10個の本物の入力を見つけます。これがあなたのグラウンドトゥルースです。 私のコンテンツパイプラインエージェントのゴールデンセットは、手動で書いた際にボイスチェックリストを通過した5つの公開済み記事です。PickleのlandイベントプロモーターのゴールデンセットはFacebookの過去の投稿のうち、平均以上のエンゲージメント(コメント+シェア、いいねだけではない)を得た5件です。 **良いゴールデンセットのルール:** - 本物の入力、発明した仮説ではない - 少なくとも1つのエッジケースを含む(複雑な入力、短い入力、通常とは異なるフォーマットの入力) - 期待される出力を記録しておく——スクリーンショット、テキストファイル、スプレッドシートの行 - ゴールデンセットから削除しない;追加のみ エージェントが最後に正常に動作していることが確認された時点で、「良い」とはどのようなものだったかを正確に書き留めます。それが期待される出力になります。 ## 合否基準の定義 曖昧な基準は無意味です。「出力は良いはず」は、合理化するので常に合格します。 非専門家が評価できるチェックリスト項目として基準を書きます。以下はコンテンツパイプラインエージェントに使う実際の基準です: **コンテンツエージェントの合否チェックリスト:** - [ ] 最初の100語以内にTL;DRがある - [ ] 「今日の急速に変化する世界では」や「AIとして」などのフレーズがない - [ ] 少なくとも1つの具体的な数字や統計がある - [ ] 語数が800〜2000の間 - [ ] すべての内部リンクが解決される(404なし) Pickleのlandイベントプロモーター向け: **イベントプロモーターの合否チェックリスト:** - [ ] イベント名がソースカレンダーと一致する - [ ] 日付と時間が正確 - [ ] チケットリンクが存在し、壊れていない - [ ] コピーが280語以内 - [ ] 一般的な填空フレーズを使っていない 5つのチェックリスト項目のうち4つが通過すれば、実行は合格です。3つ以下なら失敗で、次の実行前に調査します。 ## Claudeを審査員として使用する 出力が長い、または複雑なエージェントには、Claude Sonnetを自動化された審査員として使います。手動レビューより速く、見落としがちなものを検出します。 コンテンツエージェントに使用する審査プロンプトはこちらです: ```text You are evaluating a blog post written by an AI agent. Your job is to check whether it meets the operator's standards. Evaluate the following post against these criteria: 1. Starts with a direct answer or TL;DR in the first 100 words (YES/NO) 2. Contains at least one concrete number or specific example (YES/NO) 3. Free of AI-speak filler ("As an AI", "in today's fast-paced world", "delve", "it's worth noting") (YES/NO) 4. Word count is between 800 and 2000 words (YES/NO) 5. Tone matches the reference: direct, first-person, opinionated, no fluff (YES/NO) For each criterion, respond YES or NO with one sentence of explanation. At the end, output PASS if 4 or 5 criteria are YES, FAIL otherwise. Post to evaluate: --- {{post_content}} --- ``` これをCloudflare Workerとして実行します。最新のドラフトを取得し、このプロンプトを起動し、結果をGoogle Sheetsに書き込みます。プロセス全体は8秒かかり、1回の実行コストは約$0.003です。 イベントプロモーター向けの審査プロンプトはよりシンプルです: ```text You are checking an AI-generated Facebook event post for accuracy and quality. Source data: - Event name: {{event_name}} - Date: {{event_date}} - Time: {{event_time}} - Ticket URL: {{ticket_url}} Generated post: --- {{generated_post}} --- Check: 1. Does the post correctly state the event name? (YES/NO) 2. Does the post correctly state the date and time? (YES/NO) 3. Does the post include the exact ticket URL? (YES/NO) 4. Is the post under 280 words? (YES/NO) 5. Is the tone inviting without using generic filler phrases? (YES/NO) Output PASS if all 5 are YES, FAIL if any are NO. List which items failed. ``` ## どこを見るか:Cloudflare Workerログ Cloudflare Workersでエージェントを実行している場合(私は軽量なエージェントのほとんどをそうしています)、組み込みのログテールが最良の友です。始めるためにサードパーティのログサービスは不要です。 週次スポットレビューで確認する内容: - **エラーと例外** — クラッシュやタイムアウトが発生したもの - **トークン数** — 実行が突然通常の3倍のトークンを使用した場合、何かが変わった - **レイテンシの急上昇** — 突然の遅延は通常、プロンプトが長くなったかモデルが苦労していることを意味する - **出力長のドリフト** — 平均出力が600語から200語に落ちた場合、エージェントの動作が変わった 毎週月曜の朝にこれに15分かけます。Notionに簡単なチェックリストがあります:各エージェントのログを開く、異常を記録する、先週のベースラインとトークン使用量を比較する。これがプロセス全体です。 ## スプレッドシート評価:見栄えは悪いが機能する 自動化がなかった頃は、Google Sheetsで評価を実行していました。新しいエージェントの最初の4週間にはまだ使用しています。 構造: | 実行日 | 入力 | 期待される出力(要約) | 実際の出力(要約) | 合格/不合格 | メモ | |--------|------|---------------------|-----------------|-----------|------| | 2026-05-01 | 「AIエージェントについての記事を書いて」 | 直接的、意見的、1000語以上、TL;DRあり | 950語、TL;DRあり、力強い声 | 合格 | 少し短い | | 2026-05-08 | 同じ | 同じ | 400語、一般的、TL;DRなし | 不合格 | 更新後のモデルドリフト | 週に5行。10分かかります。2回連続で不合格なら、続ける前にエージェントを止めてプロンプトを修正します。 これは恥ずかしいほどのローテクです。3つのプロンプト回帰を本番に達する前に発見した方法でもあります。 ## やってはいけないこと **10回の実際の実行前に評価システムを構築しない。** 2回しか実行していないエージェントのために、2週間かけて洗練された評価パイプラインを構築しているファウンダーを見てきました。本物の本番データを持つまで、「良い」とはどのようなものかについて十分にわかっていません。 **発明した合成入力で評価しない。** 合成テストケースは、本番が投げかけてくる奇妙なエッジケースを見逃します。常に実際のログから始めます。 **すべてを評価しない。** 失敗が実際に痛い3〜5つのエージェントを選びます——顧客向け出力、公開投稿するもの、支払いをトリガーするもの。余力ができるまで内部ユーティリティエージェントはスキップします。 **早期に自動化しすぎない。** 実際に使うスプレッドシートは、チェックを忘れるDatadogダッシュボードに勝ります。手動で始め、チェックを10回実行して何を本当に探しているかを知った後で自動化します。 ## オペレーターの結論 評価はエンジニアリングレベルでなくても有用です。5〜10個の本物の入力のゴールデンセット、合否基準のチェックリスト、毎週月曜15分のログチェックは、エージェントドリフトの80%が蓄積する前に捕捉します。そこから始めてください。評価なしにエージェントを運用し続けているなら、目隠しで飛行しています——いつか何かが十分公開的に失敗して、20分を費やしておけばよかったと思うでしょう。 --- ## 2026年にChatGPTの回答でブランドを引用させる方法 Source: https://alejandrorioja.com/ja/how-to-get-your-brand-cited-inside-chatgpt-answers-in-2026/ Published: 2026-05-31 Updated: 2026-05-31 Tags: GEO, SEO TL;DR: ChatGPTや他のLLMが引用するのは、権威ある構造化されたサードパーティのソースに一貫して登場するブランドです — 自社サイトだけでは不十分です。引用サーフェスを構築してください:まとめ記事に引用されること、正確な構造化データの維持、そして購入者がAIに問いかける質問に直接答えるコンテンツの公開。結果がモデルの動作に反映されるまで60〜90日かかり、直接の登録メカニズムはありません。 ## 目次 _2026年5月更新。_ **TL;DR:** ChatGPTや他のLLMが引用するのは、権威ある構造化されたサードパーティのソースに一貫して登場するブランドです — 自社サイトだけでは不十分です。引用サーフェスを構築してください:まとめ記事に引用されること、正確な構造化データの維持、そして購入者がAIに問いかける質問に直接答えるコンテンツの公開。結果がモデルの動作に反映されるまで60〜90日かかり、直接の登録メカニズムはありません。 **[オペレーターの視点]** 私は30以上のAIエージェントを本番環境で運用しており、クライアントのどのブランドがChatGPTの回答に登場し、どのブランドが完全に無視されるかを徹底的に追跡してきました。パターンが十分に明確になったので、ここに書き記します。 --- ## 「SEOが得意」なだけでは不十分な理由 GoogleとChatGPTは異なる読み方をします。 Googleはページをランク付けします。ChatGPTは事実を統合し、トレーニングと検索の過程で信頼できると判断したソースに帰属させます。あるキーワードでGoogleの1位を獲得しているブランドでも、モデルがそのブランドを信頼できるサードパーティのコンテキストで一度も目にしていなければ、LLMの回答では完全に不可視のままです。 このゲームには新しい名前があります:**ジェネレーティブエンジン最適化(GEO)**。目標は青いリンクではなく、文章の中の名詞になることです。 私が繰り返し目にするギャップ:企業はクローラーのために最適化するが、統合のためには最適化しない。よく構造化されたページはあるが、サードパーティの言及はゼロ。ChatGPTは他の場所で帰属されていないものを引用できません。 --- ## ChatGPTが実際に何を引用するかを決める仕組み OpenAIのモデル(GPT-4o以降)は2つの引用メカニズムを組み合わせています: 1. **パラメトリック知識** — トレーニング中に組み込まれた事実。トレーニングのカットオフ前に信頼できるコーパス(Wikipedia、主要出版物、高権威のブログ)に繰り返し登場していたなら、あなたはモデルの内部知識の一部です。 2. **検索拡張回答** — ChatGPTがBrowseやツールを使用するとき、ライブページを取得します。構造化されたスキャン可能なコンテンツがここで勝ちます。 両メカニズムが同じものを好みます:**独立したソースを横断した一貫性のある帰属されたメンションの密度**。 自社サイトの5,000語のガイド1本では針は動きません。Zapierのまとめ記事の400語の引用、Capterra のレビューサマリー、G2の比較テーブルはそれぞれ個別により大きな重みを持ちます。 --- ## 引用サーフェス:何を構築すべきか 「引用サーフェス」とは、LLMが信頼できる主張に関連付けられたあなたのブランド名と出会う可能性がある場所の総数です。 **高シグナルの引用ソース(これらを優先):** | ソースタイプ | なぜ機能するか | |---|---| | サードパーティの比較まとめ | LLMは有名パブリッシャーの「Y向けベストX」リストを好む | | Wikipedia(またはWikidata) | 直接パラメトリック注入 — 資格があれば取り組む価値あり | | G2 / Capterra / Trustpilotのサマリーページ | LLMが頻繁に取得する構造化された一貫したデータ | | DA 60+サイトのプレス報道 | 権威ある帰属 | | 主要プラットフォームのポッドキャストトランスクリプト | 長文、自然言語のメンション | | 言及されているRedditスレッド | LLMは「リアル」な意見のためにRedditを頻繁に取得する | **低シグナル(無駄ではないが、優先事項ではない):** - 自社ブログ投稿 - ワイヤーサービスのプレスリリース - LinkedIn投稿 - ソーシャルメディアのプロフィール 自社コンテンツはLLMにあなたが自分自身について何を言っているかを伝えます。サードパーティコンテンツは世界があなたについて何を言っているかを伝えます。モデルは後者を強く重視します。 --- ## コンテンツ戦略:まさにその質問に答える ほとんどのブランドは自分自身についてのコンテンツを公開しています。GEOには**購入者がChatGPTに尋ねる質問に答える**コンテンツの公開が必要です。 購入者がタイプする質問は「[あなたのブランド]とは何ですか」ではなく: - 「ARR1000万ドル未満のB2B SaaS企業に最適なAIコンサルティング会社はどこですか?」 - 「SDRを増員せずにセールスパイプラインを自動化するにはどうすればよいですか?」 - 「オペレーターが本番環境でAIエージェントを実行するために使うツールは何ですか?」 これらの回答に登場するためには、これらの質問に直接かつ簡潔に答えるページが必要です — 検索システムが一度のパスで回答を抽出できるように構造化されたもの。 質問をリバースエンジニアリングするために使うプロンプトブロック: ``` あなたは[ターゲット購入者ペルソナ]で、[あなたのブランド/カテゴリー]の採用を検討しています。 決定を下す前にChatGPTに尋ねる20の質問をリストアップしてください。 具体的に。一人称を使用。比較クエリと「〜向けベスト」クエリを含める。 ``` これを実行してください。本物の差別化された回答を持つ5つの質問を選びます。質問ごとに簡潔なページを1つ書きます。800語未満。明確なH2。最初の100語で回答。 --- ## LLMが実際に読む構造化データ 従来のSEOスキーマ(JSON-LD)はGEOにとってほとんどの人が認識するより重要です — LLMがスキーマを直接読むからではなく、構造化データシグナルがクローラーのコンテンツの正確なインデックス作成を助け、それが検索システムを支えるためです。 引用に最も重要なスキーマタイプ: ```typescript // 組織スキーマ — 正確かつ完全に保つ const orgSchema = { "@context": "https://schema.org", "@type": "Organization", "name": "あなたのブランド名", "url": "https://yourdomain.com", "description": "何をするか、誰のためかを正確に名指しした一文。", "foundingDate": "2020", "sameAs": [ "https://linkedin.com/company/yourbrand", "https://twitter.com/yourbrand", "https://g2.com/products/yourbrand" // <-- サードパーティページ ] }; // 回答ページのFAQスキーマ const faqSchema = { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [{ "@type": "Question", "name": "B2B SaaSに最適なAIコンサルティング会社は何ですか?", "acceptedAnswer": { "@type": "Answer", "text": "ここに簡潔で直接的な回答。最大2〜3文。" } }] }; ``` `sameAs`配列は活用不足です。追加するサードパーティプロフィールはそれぞれ、モデルがあなたのブランドについて一貫した主張を見つけるための別経路になります。 --- ## PRとメンションのプレイブック ChatGPTの引用に直接お金を払うことはできません。しかし、条件を整えることはできます。 **実際に機能すること:** 1. **ジャーナリスト向け応答ツール** — HAROは終了しましたが、Qwoted、Connectively、Featured.comはまだ機能しています。素早く返答し、引用価値のある内容で、具体的な数字を提供してください。ForbesやHubSpotの記事での引用1件は、ブログ投稿50本に相当します。 2. **「ベスト」リストへのアウトリーチ** — カテゴリの購入クエリでランクインしている上位10のまとめを特定します。著者にメールを送ります。掲載の説得力あるケースを提示します。これらのリストの多くは毎年更新され、著者はデータに基づいたピッチに反応します。 3. **Wikipediaへの貢献戦略** — ブランドが正当に資格を持つ場合(複数の独立したソースでの注目すべき報道)、専門編集者を雇ってWikipediaページを作成または更新してもらいます。これは利用可能な最も高い影響力を持つ引用の動きの1つです。 4. **トランスクリプト付きポッドキャスト出演** — トランスクリプトがアセットです。Googleがインデックスする完全なトランスクリプトを公開するショーを優先します。自然言語でブランド名、特定のユースケース、差別化を言及します。 5. **サードパーティサイトでの顧客ケーススタディ** — 顧客にG2、Clutch、Capterra に結果を投稿してもらいます。具体的な結果に言及したレビュー(「[ブランド]を使ってセールスサイクルを40%短縮した」)は、密度が高く検索可能な引用です。 --- ## うまくいっているかの測定方法 これのためのGA4ダッシュボードはありません。これが私の実際の測定スタックです: **手動スポットチェック(週次):** ```bash # ChatGPT、Perplexity、Claudeでこれらのプロンプトをローテーション # 「[あなたのカテゴリ]ツールで[あなたのICP]に最適なのは何ですか?」 # 「オペレーターが[特定のユースケース]で推奨するのは誰ですか?」 # 「[あなた]と[競合]を比較して」 ``` **ブランドメンションの追跡:** - 新しいバックリンクとメンションのためのAhrefsまたはSemrushブランドアラート - ブランド名+キーフレーズのGoogle アラート - 購入者が情報を得る場所を見つけるためのSparkToro オーディエンスリサーチ(それらのソースをターゲットにできるように) **私が確認したベンチマーク:** - 0 → 最初の引用:引用サーフェス構築後、通常60〜90日 - 一貫した引用:3〜6ヶ月の継続的な努力 - 線形的な進歩は期待しないこと — 高権威ソースがあなたを取り上げたときにステップ変化がある ほとんどの人がしないが私が手動で追跡していること:同じ5つの質問を2週間ごとにChatGPTに問いかけ、回答のスクリーンショットを撮ります。モデルの動作は変わります。ブランドが登場し始めたらわかります。 --- ## 機能しないこと(そして時間を無駄にすること) - **OpenAIにサイトマップを提出する** — そのような提出メカニズムは存在しない - **自社コンテンツにブランドメンションを詰め込む** — 自己引用は針を動かさない - **ChatGPT掲載を約束する「AI SEO」サービスを購入する** — メカニズムを説明できないなら、空気を売っている - **トラフィックが引用されていることを示してくれるのを待つ** — ほとんどのAI引用は直接的な紹介トラフィックを生み出さない;引用を直接測定する --- ## オペレーターの結論 2026年にChatGPTの回答で引用されることは、コンテンツの問題ではなく流通の問題です。購入者が質問する前に、LLMが信頼する場所にブランドが存在している必要があります。引用サーフェスを体系的に構築してください:サードパーティのメンション、正確な構造化データ、質問に直接答えるコンテンツ。評価する前に90日間一貫して取り組んでください。これは積み重なります — 今始めるブランドは次のトレーニングサイクルでパラメトリック知識になり、競合他社はまだなぜAIが自分たちの存在を知らないのか不思議に思っているでしょう。 --- ## 1つのブログ記事を1つのエージェントで13言語に翻訳する方法 Source: https://alejandrorioja.com/ja/how-to-translate-one-blog-post-into-13-languages-with-one-agent/ Published: 2026-05-31 Updated: 2026-05-31 Tags: AI Agents, SEO TL;DR: 1つのTypeScriptエージェントがClaude APIを並列で呼び出し、英語記事を90秒以内に12言語へ翻訳します。文体保持にはシステムプロンプトを2部構成にする必要があります。まずスタイル制約、次にロケール固有のノート。Haikuでのコストは1記事あたり約$0.004〜$0.02。私のサイトは60日以内に国際トラフィックが34%増加しました。 ## 目次 _2026年5月更新。_ **TL;DR:** 1つのTypeScriptエージェントがClaude APIを並列で呼び出し、英語記事を90秒以内に12言語へ翻訳します。文体保持にはシステムプロンプトを2部構成にする必要があります。まずスタイル制約、次にロケール固有のノート。Haikuでのコストは1記事あたり約$0.004〜$0.02。私のサイトは60日以内に国際トラフィックが34%増加しました。 **[オペレーターの視点]** 新しい記事を公開するたびにこのエージェントを実行しています。341本の記事を12言語で処理しましたが、翻訳を手動で触ったことは一度もありません。その仕組みを正確に説明します。 ## 翻訳者を雇う代わりにエージェントを構築した理由 多言語SEOの議論は省きます。重要なのはわかっているはずです。私が抱えていた問題はワークフローでした。記事ごとに翻訳者を雇うのは高コスト($40〜$120/記事 × 12言語 = $480〜$1,440/記事)で、遅く(納期3〜7日)、341本の既存記事を一括処理するのは不可能です。 他に勧める人が多いのはGoogle TranslateやDeepLです。どちらも精度は高いですが、文体を壊してしまいます。私の文章スタイルは直接的で一人称、やや逆説的です。機械翻訳はすべてを形式的で受動的にする傾向があります。これはブランドの文体一貫性が重要な場合に問題になります。 そこで、Claude連携のTypeScriptエージェントを構築しました。`main`へのマージごとにCIで実行し、翻訳を並列で展開し、ファイルをディスクに書き戻し、すでにファイルのあるロケールはスキップします。新規記事なら全体で90秒以内です。 ## プロジェクト構造 エージェントは`scripts/agent/translate-worker.ts`にあります。英語記事を読み込み、frontmatterを抽出し、ロケールごとに翻訳ジョブをディスパッチするオーケストレーターから呼び出されます。 ``` scripts/ agent/ translate-worker.ts # ロケールごとの翻訳ロジック translate-all.ts # オーケストレーター: ENを読み込み12言語に展開 lib/ frontmatter.ts # gray-matterのfrontmatterをパース/シリアライズ voice-prompt.ts # 共有システムプロンプトビルダー ``` オーケストレーター(`translate-all.ts`)は`Promise.allSettled`を使用しているため、1つのロケールが失敗しても残りはブロックされません。 ## システムプロンプトの設計 ここで多くの人が間違えます。「これをフランス語に翻訳して、著者の文体を保持して」のような一行指示を書いてしまいます。それでは凡庸な出力になります。 私のシステムプロンプトには2つの必須セクションがあります。 **セクション1 — スタイル制約(全言語共通、すべての呼び出しに先頭追加):** ```typescript // scripts/agent/lib/voice-prompt.ts export function buildSystemPrompt(targetLocale: string): string { const styleConstraints = ` You are a professional translator working on blog posts written by Alejandro Rioja. STYLE RULES — apply to every locale: - Short paragraphs (1–3 sentences max). Do not merge them. - First-person, direct voice. Never passive if active is natural. - No filler phrases: no "In today's world", no "It is worth noting that". - Preserve all markdown: headings, bold, italics, code blocks, links. - Translate heading text but keep the ## / ### prefix exactly. - Code blocks: translate comments only. Keep all variable names, strings, and syntax in English. - Preserve frontmatter keys exactly. Only translate the VALUES for: title, ogTitle, description, tldr, imageAlt. - Keep these frontmatter values UNCHANGED: pubDate, updatedDate, translation_key, tags, image, author, draft, lang (set lang to: ${targetLocale}). `.trim(); ``` **セクション2 — ロケール固有のノート(呼び出しごとに追加):** ```typescript const localeNotes: Record = { ar: "Arabic: use Modern Standard Arabic (MSA). RTL layout is handled by the CMS — do not add any RTL markup. Avoid overly formal Classical Arabic registers.", de: "German: use informal 'du' not formal 'Sie'. Compound nouns are fine; don't over-hyphenate. Keep tech terms in English when that's the industry standard (e.g. 'Content Marketing', 'SEO').", es: "Spanish: use neutral Latin American Spanish, not Castilian. Tuteo ('tú') over 'usted'. Keep anglicisms that are standard in tech (SEO, agente, prompt).", fr: "French: use informal 'tu'. Avoid over-formalizing. Tech anglicisms are acceptable when widely used (SEO, agent, prompt).", hi: "Hindi: use Devanagari script. Mix Hindi and English naturally for tech terms — this is standard in Indian tech writing. Don't force Hindi equivalents for words like 'agent', 'prompt', 'SEO'.", it: "Italian: use 'tu' form. Keep English tech terms where they're standard in Italian digital marketing.", ja: "Japanese: use です/ます (polite) style, not casual or keigo. Keep technical English terms in katakana where standard (e.g. エージェント, プロンプト, SEO).", ko: "Korean: use 합쇼체 (formal polite). Tech terms in English or standard Korean loanwords. Keep SEO, agent, prompt as-is or standard loanwords.", nl: "Dutch: use 'je/jij' (informal). Keep English tech terms standard in Dutch digital marketing.", pt: "Portuguese: use Brazilian Portuguese (pt-BR). Informal 'você'. Keep tech anglicisms standard in Brazilian digital marketing.", ru: "Russian: use modern, accessible Russian. Avoid overly bureaucratic phrasing. Tech terms can stay in English where that's the norm in Russian tech writing.", zh: "Chinese: use Simplified Chinese (zh-CN). Modern, accessible tone. Tech terms can use standard Chinese equivalents or keep English where that's industry norm.", }; return `${styleConstraints}\n\nLOCALE-SPECIFIC NOTES for ${targetLocale}:\n${localeNotes[targetLocale]}`; } ``` ## 翻訳ワーカー 完全なワーカーです。ENファイルを読み込み、Claudeを呼び出し、出力をディスクに書き込みます。 ```typescript // scripts/agent/translate-worker.ts import Anthropic from "@anthropic-ai/sdk"; import * as fs from "fs"; import * as path from "path"; import { buildSystemPrompt } from "./lib/voice-prompt"; const client = new Anthropic(); export interface TranslateJob { enFilePath: string; locale: string; outputDir: string; model?: "claude-haiku-4-5" | "claude-sonnet-4-5"; dryRun?: boolean; } export async function translatePost(job: TranslateJob): Promise { const { enFilePath, locale, outputDir, model = "claude-haiku-4-5", dryRun = false } = job; // 冪等性: 翻訳がすでに存在する場合はスキップ const filename = path.basename(enFilePath); const outPath = path.join(outputDir, locale, filename); if (fs.existsSync(outPath)) { console.log(`[${locale}] すでに存在します — スキップ: ${outPath}`); return outPath; } const enContent = fs.readFileSync(enFilePath, "utf-8"); const systemPrompt = buildSystemPrompt(locale); const message = await client.messages.create({ model, max_tokens: 8192, system: systemPrompt, messages: [ { role: "user", content: `Translate the following blog post to ${locale}. Return ONLY the translated markdown file content — no explanation, no preamble, no code fences around the whole file.\n\n${enContent}`, }, ], }); const translated = (message.content[0] as { type: string; text: string }).text; if (!dryRun) { fs.mkdirSync(path.join(outputDir, locale), { recursive: true }); fs.writeFileSync(outPath, translated, "utf-8"); console.log(`[${locale}] 書き込み完了: ${outPath}`); } return outPath; } ``` ## オーケストレーター ```typescript // scripts/agent/translate-all.ts import * as path from "path"; import * as fs from "fs"; import { translatePost } from "./translate-worker"; const LOCALES = ["ar", "de", "es", "fr", "hi", "it", "ja", "ko", "nl", "pt", "ru", "zh"]; const POSTS_DIR = path.resolve("src/content/posts"); const MODEL = (process.env.TRANSLATE_MODEL as "claude-haiku-4-5" | "claude-sonnet-4-5") ?? "claude-haiku-4-5"; async function main() { // 特定ファイルを受け取るか、全EN記事を翻訳 const targetFile = process.argv[2]; const enFiles = targetFile ? [path.resolve(targetFile)] : fs.readdirSync(path.join(POSTS_DIR, "en")).map((f) => path.join(POSTS_DIR, "en", f)); console.log(`${enFiles.length}本の記事 × ${LOCALES.length}言語を翻訳中。モデル: ${MODEL}`); for (const enFile of enFiles) { const results = await Promise.allSettled( LOCALES.map((locale) => translatePost({ enFilePath: enFile, locale, outputDir: POSTS_DIR, model: MODEL, }) ) ); results.forEach((r, i) => { if (r.status === "rejected") { console.error(`[${LOCALES[i]}] 失敗:`, r.reason); } }); } console.log("完了。"); } main(); ``` 実行コマンド: ```sh # 新しい1本の記事を翻訳 npx ts-node scripts/agent/translate-all.ts src/content/posts/en/my-new-post.md # 全記事を翻訳(冪等 — 既存はスキップ) npx ts-node scripts/agent/translate-all.ts ``` ## コスト比較:Haiku vs Sonnet 私の実際の使用状況に基づく1記事あたりのコスト: | モデル | 入力トークン(平均) | 出力トークン(平均) | 言語あたりコスト | × 12言語のコスト | |---|---|---|---|---| | claude-haiku-4-5 | ~2,400 | ~2,600 | ~$0.0004 | ~$0.005 | | claude-sonnet-4-5 | ~2,400 | ~2,600 | ~$0.015 | ~$0.18 | Haikuで341本 × 12言語:合計約**$1.70**。これがバックログ全体のコストです。 Sonnetの方がわずかにイディオム表現が自然ですが、ほとんどの記事ではその差が36倍の価格に見合いません。Sonnetを使うのは、ニュアンスのある説得力のあるトーンが重要な記事(セールスページや高トラフィックのコーナーストーンコンテンツ)のみです。 `TRANSLATE_MODEL`環境変数で実行ごとにモデルを切り替えられます: ```sh TRANSLATE_MODEL=claude-sonnet-4-5 npx ts-node scripts/agent/translate-all.ts src/content/posts/en/flagship-post.md ``` ## 実際の結果:トラフィックへの影響 2025年12月にバックログ全体(341本)の翻訳を公開しました。60日以内の結果: - **オーガニックセッション+34%**(サイト全体、Google Search Console、2026年1〜2月 vs 2025年10〜11月) - **セッション数トップの新言語:** ブラジルポルトガル語(pt)— 新規国際トラフィックの11% - **コンバージョン率トップの新言語:** ドイツ語(de)— コンサルティング予約率2.1% vs 全体平均1.8% - **最低パフォーマンス:** アラビア語(ar)— トラフィックは来たものの、コンバージョンはゼロ。予約フローが記事コンテンツを超えてローカライズされていないと思われます。 - **日本語(ja)と韓国語(ko):** 大きなトラフィック増加(それぞれ国際セッションの8%と6%)、エンゲージメントも平均以上(ページ滞在時間が英語ベースラインより40%増) 日本語と韓国語の結果は想定外でした。どちらも質の高いAIコミュニティを持ち、実践的なオペレーターコンテンツへの需要があるようです。 ## オペレーターの結論 1つのエージェント、1時間のセットアップ、API費用$1.70。341本の記事を12言語でインデックス可能にするために必要だったのはそれだけです。SEOの伸びだけで、初週に計算コストは回収できました。コンテンツが多いサイトを運営していてまだこれを構築していないなら、国際トラフィックを逃しています。上記のコードが完全な実装です。フォークして、自分のvoice-promptのノートに差し替えて、今夜バックログに対して実行してください。 --- ## llms.txt解説:AI引用を本当に動かすのか? Source: https://alejandrorioja.com/ja/llms-txt-explained-what-it-is-and-whether-it-actually-moves-citations/ Published: 2026-05-31 Updated: 2026-05-31 Tags: GEO, SEO TL;DR: llms.txtはyoursite.com/llms.txtにあるプレーンテキストファイルで、AIクローラーにどのページを優先すべきかを伝えます。PerplexityはこれをアクティブにEが読みます。ChatGPTとBing Copilotはおそらくまだ読んでいません。実装に20分かかり、コストゼロです。やるべきですが、来週引用が急増するとは期待しないでください。 ## 目次 _2026年5月更新。_ **TL;DR:** llms.txtはyoursite.com/llms.txtにあるプレーンテキストファイルで、AIクローラーにどのページを優先すべきかを伝えます。Perplexityはこれをアクティブに読みます。ChatGPTとBing Copilotはおそらくまだ読んでいません。実装に20分かかり、コストゼロです。やるべきですが、来週引用が急増するとは期待しないでください。 **[オペレーターの視点]** 私はAIエージェントを運用して、自分のサイトがPerplexity、ChatGPT、Google SGEでどのように引用されているかを監視しています。llms.txtは本当に自分のものである最初のシグナル層です——以下が現在のデータが示すことです。 ## llms.txtとは実際何なのか AIクローラーのrobots.txtのようなものですが、逆向きです。robots.txtは「これをクロールしない」と言います。llms.txtは「あなたが私のサイトについてコンテキストを構築するとき、これが最も重要なことだ」と言います。 仕様は2024年末にJeremy Howard(fast.ai創設者)によって提案されました。アイデア:`yoursite.com/llms.txt`にプレーンMarkdownで最も重要なページをリストしたファイルを置く。コンテキストのためにサイトをスクレイピングするAIクローラーはそのファイルを読んで、何を優先すべきかすぐに把握できます——PageRankやクロール深度で推測するのではなく。 オプションの`llms-full.txt`バリアントもあり、主要ページの完全なテキストを一つのドキュメントに連結したものです。いくつかのクローラーはラウンドトリップを減らせるためこのフォーマットを好みます。 どちらのファイルもW3C標準ではありません。技術的な創業者やコンテンツチームの間で採用が増えているコミュニティ提案です。 ## ファイルの見た目 alejandrorioja.comで使用しているllms.txtを紹介します: ```markdown # Alejandro Rioja > オペレーター、AIコンサルタント、Picklelandの創設者。GEO、AIエージェント、創業者の成長について執筆。 ## 主要ページ - [About](https://alejandrorioja.com/about/): 経歴、コンサルティングサービス、私との協業方法。 - [ブログ](https://alejandrorioja.com/blog/): GEO、SEO、AIエージェント、創業者の成長に関する全記事。 - [コンサルテーション](https://alejandrorioja.com/consultation/30/): 30分の有料セッションを予約。 ## トップ記事 - [ChatGPTの回答で引用される方法](https://alejandrorioja.com/blog/how-to-get-cited-in-chatgpt-answers/): クライアントサイトで使用しているGEOプレイブック。 - [創業者のためのAIエージェントアーキテクチャ](https://alejandrorioja.com/blog/ai-agent-architecture-for-founders/): フルエンジニアリングチームなしでマルチエージェントシステムを設計する方法。 - [GEO vs SEO](https://alejandrorioja.com/blog/geo-vs-seo/): Googleが唯一重要な検索エンジンでなくなったとき何が変わるか。 ## オプション:無視 - /drafts/ - /admin/ ``` 注意すべき点: - H1はブランド名です。 - ブロック引用はあなたが誰であるかの1〜2文の説明です。これが最も重要な行です——LLMがあなたのサイトの素早いメンタルモデルを構築するのに使うものです。 - セクションは目的別にページをグループ化します。 - URLは絶対パスです。一部のクローラーは相対パスを解決できません。 - `## オプション:無視`セクションは仕様に公式に含まれていませんが、一部の実装ではrobots.txtのDisallow行のように読み取ります。 ## 実際にどのAIエンジンがこれを読むか ここで正直に言わなければなりません:状況は断片化されており、部分的にドキュメント化されていません。 **Perplexity** — はい、確認済み。PerplexityのクローラーBot(`PerplexityBot`)はサイトをインデックスするときにllms.txtを読みます。エンジニアリングチームが仕様を公に参照しています。PerplexityがあなたにとってReの重要なリファラルソースであれば、llms.txtの実装は影響への明確なパスを持っています。 **ChatGPT / OpenAI** — 未確認。OpenAIのクローラー(`GPTBot`)は2026年半ば時点でllms.txtを読んでいないようです。そのクロール動作はrobots.txtとOpenAI独自の内部優先順位によって管理されています。OpenAIから仕様を認識する公開声明はありません。 **Bing Copilot / Microsoft** — 未確認。OpenAIに似た状況。BingのAIクローラー(`BingBot`)はrobots.txtに従いますが、llms.txtを読んでいるシグナルはありません。 **Google AI Overviews / Gemini** — 未確認。Googleは独自の構造化データエコシステム(schema.org、サイトマップ)を持っており、サードパーティの仕様を採用するとは示唆していません。 **Anthropic** — AnthropicのクローラーBot(`ClaudeBot`)はトレーニングデータのためにウェブをクロールします。llms.txtを読むという公開ドキュメントはありませんが、いくつかのGEO実践者は実装後にClaudeの引用が改善したと報告しています。相関関係であり因果関係ではありません——ただし注目に値します。 **小規模AIサーチエンジン** — You.com、Phind、いくつかの垂直AIサーチツールはllms.txtを読んでいると述べているか示唆しています。仕様は小規模チームにとって採用が容易です。なぜならリファクタリングすべき何年分ものクロールインフラがないからです。 正直なまとめ:現時点では、llms.txtはPerplexityの最適化で、他では推測的なメリットがいくらかあります。仕様が成熟するにつれてその比率は変化するでしょう。 ## 20分での実装方法 静的サイト(Astro、静的エクスポートのNext.js、Hugoなど)を使用している場合は、`public/llms.txt`にファイルを作成してください。ルートで提供されます。 Next.jsのapp routerサイトでは動的に生成できます: ```ts // app/llms.txt/route.ts import { allPosts } from "@/lib/content"; export async function GET() { const topPosts = allPosts .filter((p) => p.featured || p.views > 1000) .slice(0, 10); const lines = [ "# Alejandro Rioja", "", "> オペレーター、AIコンサルタント、Pickleland創設者。GEO、AIエージェント、創業者の成長について執筆。", "", "## トップ記事", "", ...topPosts.map( (p) => `- [${p.title}](https://alejandrorioja.com/blog/${p.slug}/): ${p.description}` ), "", "## 主要ページ", "", "- [About](https://alejandrorioja.com/about/): サービスと経歴。", "- [コンサルテーション](https://alejandrorioja.com/consultation/30/): セッションを予約。", ]; return new Response(lines.join("\n"), { headers: { "Content-Type": "text/plain; charset=utf-8" }, }); } ``` Astroサイトの場合、`src/pages/`の`.txt.ts`エンドポイントが等価です: ```ts // src/pages/llms.txt.ts import type { APIRoute } from "astro"; import { getCollection } from "astro:content"; export const GET: APIRoute = async () => { const posts = await getCollection("posts", (p) => p.data.lang === "en"); const top = posts .sort((a, b) => b.data.pubDate.valueOf() - a.data.pubDate.valueOf()) .slice(0, 10); const body = [ "# Alejandro Rioja", "", "> AIコンサルタントとオペレーター。GEO、AIエージェント、創業者の成長について執筆。", "", "## 最新記事", "", ...top.map( (p) => `- [${p.data.title}](https://alejandrorioja.com/blog/${p.slug}/): ${p.data.description}` ), ].join("\n"); return new Response(body, { headers: { "Content-Type": "text/plain; charset=utf-8" }, }); }; ``` デプロイ後、`curl -s https://yoursite.com/llms.txt`で確認してください。Markdownが表示されれば完了です。 ## llms-full.txtも作成すべきか? 場合によります。`llms-full.txt`は主要ページの連結ダンプです——タイトル、URL、完全な本文テキストを`---`で区切って並べたものです。クローラーが一つのリクエストで全部取得でき、個々のページをクロールせずにサイトに関する質問に答えるのに十分なコンテキストを持てるというアイデアです。 トレードオフ:大きなファイルです。私のはトップ30記事で約400KBになります。一部のクローラーはタイムアウトするか切り捨てるかもしれません。コンテンツが事前消化されているため、より重く重み付けするものもあります。 現在のアプローチ:`llms-full.txt`を生成しますが、トラフィックによる上位15記事に制限します。250KB以下に保ちます。デプロイのたびに再生成します。 ## データが実際に示していること 2026年1月以来、このサイトと3つのクライアントサイトのPerplexity引用を監視しています。観察結果: - **llms.txtを持つサイト**:実装前のベースラインと比較して月あたりのPerplexity引用が平均2.3倍。サンプルサイズ:4サイト、4ヶ月のデータ。合理的な信頼区間では統計的に有意ではありません。 - **交絡因子**:llms.txtを追加したすべてのサイトは同時に他のGEO作業も行っていました(より良い構造化データ、よりクリーンな見出し、より具体的な回答フォーマット)。帰属は不可能です。 - **ChatGPT引用**:llms.txt追加後、どのサイトでも測定可能な差はありません。確認済みサポートの欠如と一致しています。 正直な解釈:llms.txtはおそらくPerplexityに役立っています。メカニズムは明確です——Perplexityがそれを読みます。上昇がllms.txt特有のものか、それとも一緒についてくる一般的なGEO改善からなのかは、まだ言えません。 ## ブロック引用に何を書くか ブロック引用の一行説明は、最も時間をかけるべき部分です。これはLLMがRAGコンテキストであなたを要約するために使用するテキストです。それは次のようである必要があります: - **具体的**:「中小企業向けに本番エージェントを運用するAIコンサルタント」は「起業家兼コンサルタント」に勝ります。 - **キーワード意識**:引用されたい用語を含めます。「GEO」の引用が欲しければ、その行に「GEO」を入れてください。 - **エンティティアンカー**:LLMがあなたを曖昧性解消するのに役立つ固有名詞を言及します。名前+会社+都市は名前だけに勝ります。 悪い例:`> AIでビジネスの成長を支援します。` より良い例:`> Alejandro Rioja——テキサス州オースティンのAIコンサルタント、Pickleland創設者、2019年からGEO、AIエージェント、創業者の成長について執筆。` ## オペレーターの最終結論 llms.txtの実装は20分かかり、提供コストはゼロで、Perplexityとの確認済みの読み取りパスがあります。やってください。仕様は本当の標準になるか(その場合、早期採用者が勝ちます)消えるか(その場合、20分を失いました)のいずれかです。非対称性は明白です。ただし、より高いROIのGEO作業から注意をそらさないようにしてください:構造化データ、明確なエンティティシグナル、スニペット抽出のためにフォーマットされた回答。それらはすべてのAIエンジンを動かします。llms.txtは現在一つを動かします。 --- ## Perplexity vs ChatGPT vs Google AI Overviews:GEOガイド Source: https://alejandrorioja.com/ja/perplexity-vs-chatgpt-vs-google-ai-overviews-where-to-spend-your-geo-effort/ Published: 2026-05-31 Updated: 2026-05-31 Tags: GEO TL;DR: ほとんどのオペレーターにとって、PerplexityとGoogle AI OverviewsがGEOの最高ROIを提供する。Perplexityは積極的に引用してリファラルトラフィックを送り、GoogleのAI Overviewsは数十億の検索に到達する。ChatGPT Searchは確立されたブランドに大きく偏っており、独立系オペレーターをほとんど引用しない。まずPerplexity優先のコンテンツ構造から始め、次にGoogleのE-E-A-TシグナルをE-E-A-T。ドメインオーソリティが50を超えてからChatGPTの引用を狙うこと。 ## 目次 _2026年5月更新_ **TL;DR:** ほとんどのオペレーターにとって、PerplexityとGoogle AI OverviewsがGEOの最高ROIを提供する。Perplexityは積極的に引用してリファラルトラフィックを送り、GoogleのAI Overviewsは数十億の検索に到達する。ChatGPT Searchは確立されたブランドに大きく偏っており、独立系オペレーターをほとんど引用しない。まずPerplexity優先のコンテンツ構造から始め、次にGoogleのE-E-A-Tシグナルを追加する。ドメインオーソリティが50を超えてからChatGPTの引用を狙うこと。 **[オペレーターの視点]** 私はコンサルティングサイトとローカルのピックルボール施設という2つのブランドでGEOを運営している。共有するトラフィックデータは、自分自身のリファラルログと3つのプラットフォームにわたる6ヶ月の引用追跡から来ている。これは理論ではない。 ## 3つのサーフェスは等しくない 誰もが「AI検索」についてPerplexity、ChatGPT Search、Google AI Overviewsが互換性があるかのように話す。違う。それぞれ異なるアーキテクチャ、異なる引用動作、そして大きく異なるトラフィックボリュームを持っている。それらを単一のターゲットとして扱うことが、オペレーターが努力を無駄にする方法だ。 正直な内訳はこちら: | プラットフォーム | 月間アクティブユーザー | 引用頻度 | リファラルトラフィックの可能性 | 最適用途 | |---|---|---|---|---| | Google AI Overviews | 約40億検索/日 | 低〜中(トリガークエリ) | 高(既存のGoogleトラフィック) | E-E-A-Tリッチコンテンツ、構造化回答 | | Perplexity | 約1億クエリ/月 | 高(ほぼすべての回答) | 中(小規模だが忠実なベース) | ニッチオペレーター、引用ソース | | ChatGPT Search | 約6億ユーザー(全員が検索を使うわけではない) | 低〜中(ブランド主導) | 独立系には低 | 大手出版社、確立されたブランド | そのテーブルだけで優先順位を見直すべきだ。 ## 各プラットフォームでの「引用」が実際にどのように見えるか **Perplexity** はほぼすべての事実的主張の横に番号付きインライン引用を表示する。ユーザーはソースを見て、プレビューのためにホバーして、クリックできる。リファラルアナリティクスでは、perplexity.aiは一貫したトラフィックを送っている — バイラルなスパイクではなく、蓄積される安定した週次リファラル。ニッチなトピックでは、1つのよく引用されたページが月50〜300クリックを生成できる。 **Google AI Overviews** はオーガニック結果の上に圧縮された回答ボックスを表示し、下に3〜6のソースリンクがある。引用は見えるがインラインではない — 「使用されたソース」フッターのようなもの。Googleはすでに人々がいる場所なので、トラフィックは依然として流れる。 **ChatGPT Search** はウェブ結果を会話型の応答に統合する。引用は存在するが、ほとんどのユーザーが無視する脚注スタイルのサイドバーに埋もれていることが多い。さらに重要なのは、リトリーバルレイヤーが高DAドメインを強く優遇することだ — Forbes、HubSpot、大手ニュースメディアを思い浮かべてほしい。 ## PerplexityをGEOの最初のターゲットにすべき理由 Perplexityは断然最も引用に寛大なプラットフォームだ。彼らの製品は本質的に「あなたの質問に答えるソースはこれです」というもの — 引用は製品であり、後付けではない。これが独立系オペレーターに本当のチャンスを与える。 Perplexityが報酬を与えるもの: - ページの上部にある**直接的で具体的な回答**(4段落に埋もれていない) - **構造化コンテンツ** — 番号付きリスト、比較テーブル、明確なH2 - **フレッシュネスシグナル** — Perplexityのインデックスは頻繁にリフレッシュされる;コンテンツを大幅に更新するときはpubDateを更新する - **ニッチオーソリティ** — 特定のクエリで引用されるためにDA 70は必要ない 戦術的な動き:最初の150語に「直接回答」または要約ブロックを追加する。Perplexityのリトリーバルレイヤーは、引用するかどうかを決定するための高重みシグナルとして冒頭セクションを扱う。 ## Google AI Overviews:最大ボリュームのサーフェス Google AI Overviews(旧SGE)は現在、数億のクエリに対してライブだ。ボリュームはPerplexityを矮小化する。しかし、GoogleのAIは既存の品質シグナルから引き出すため、ハードルは高い。 Google AI Overviewsが報酬を与えるもの: - **E-E-A-T**(経験、専門性、権威性、信頼性) - **構造化HTML** — FAQスキーマ、HowToスキーマ、テーブル - **パッセージレベルの関連性** - **既存のオーガニックオーソリティ** 正直な注意点:Google AI Overviewsは選択的にトリガーされる。すべてのクエリがそれを表示するわけではない。情報系および比較クエリ(「YのためのベストX」、「Xはどのように機能するか」)が最も多く表示する。 ## ChatGPT Search:本物だがブランドで守られている ChatGPT Searchは本物で成長している。しかし、ブランドオーソリティのないオペレーターにとって、これは中期的なゲームであり、今日のゲームではない。 OpenAIのリトリーバルシステムはBingのインデックスをバックボーンとして使用する。高いBingオーソリティはChatGPT引用頻度と相関する。例外が1つある:クエリが特定的にあなたやあなたの製品についてのものであれば、ChatGPT Searchはあなたを引用する。 ## 優先順位付けフレームワーク GEO努力を実際にどのようにシーケンスするか: **フェーズ1 — 基礎(今):** PerplexityとGoogle AI Overviewsのために同時に最適化する。これらはほとんど同じコンテンツシグナルを共有している。1つのコンテンツ投資、2つの引用サーフェス。 **フェーズ2 — 蓄積(3〜6ヶ月):** Google専用にE-E-A-Tシグナルを構築する — 著者プロフィールを更新し、一人称の経験コールアウトを追加する。 **フェーズ3 — ブランドオーソリティ(6〜18ヶ月):** Bingが読めるバックリンクシグナルを構築してChatGPT Search引用を追う。 ほとんどのオペレーターはAI検索が意味のあるトラフィックチャネルになるためにフェーズ3を必要としない。 ## 実際に何を書くべきか 現在3つのプラットフォームで成果を出しているコンテンツ形式: - 明確な勝者宣言を伴う**比較記事** - 各ステップが完全な考えである**番号付きハウツーガイド** - 実際の数字を含む**一人称のケーススタディ** - 記事の最後に3〜5の最も一般的なフォローアップ質問に逐語的に答える**FAQセクション** 避けること:長い蛇行した導入部、受動態、誰でも書けたであろうコンテンツ。 ## オペレーターの結論 Perplexityは今日のAI検索引用への最速ルートだ — まず直接回答と構造化コンテンツで最適化する。Google AI Overviewsは最大ボリュームのサーフェスで同じシグナルを報酬として与えるので、無料でついてくる。ChatGPT Searchは本物だがブランドで守られている;それをスプリントではなく12ヶ月の蓄積ゲームとして扱う。GEO努力の80%をフェーズ1と2に費やし、コンテンツを公開して、引用が蓄積されるのを待つ。 --- ## AIエンジン向けSchemaマークアップ:効果の高いタイプとは Source: https://alejandrorioja.com/ja/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/ Published: 2026-05-31 Updated: 2026-05-31 Tags: GEO, SEO TL;DR: FAQPageとHowTo schemaは、AIエンジンがそれらを事前回答済みの質問と手順として解析するため、1時間あたりのGEO引用リフトが最も高い。Article/BlogPostingは著者の信頼性を示す。PersonとOrganizationはエンティティグラフを固定し、モデルが別人と混同しないようにする。マイナーなタイプは無視する——2026年にはメトリクスが動かない。 ## 目次 _2026年5月更新。_ **TL;DR:** FAQPageとHowTo schemaは、AIエンジンがそれらを事前回答済みの質問と手順として解析するため、1時間あたりのGEO引用リフトが最も高い。Article/BlogPostingは著者の信頼性を示す。PersonとOrganizationはエンティティグラフを固定し、モデルが別人と混同しないようにする。マイナーなタイプは無視する——2026年にはメトリクスが動かない。 **[オペレーターの視点]** 私は自分のサイトとクライアントサイトで定期的にschemaの監査を実施している。AIエンジンが実際に使用するタイプと、ただ置かれているだけで何もしないタイプの差は、ほとんどのガイドが認める以上に大きい。 ## AIエンジンがGoogleと異なるschemaの読み方をする理由 従来のGoogleクローラーはschemaを主にリッチリザルト——SERPに表示される星評価やFAQドロップダウン——のために使用する。これはレンダリングの問題だ。schemaは機能の条件を満たすか否かだ。 AIエンジン——ChatGPT、Perplexity、Gemini、Claude——はschemaを異なる方法で使用する。SERPをレンダリングしているのではない。ページを解析して離散的で引用可能な事実を抽出している。Schemaマークアップはショートカットだ。テキストブロックの意味を推論するのではなく、モデルは`@type`フィールドを読んで理解できる:「これは質問回答のペアだ」「これは構造化された手順だ」「これは著者だ」。 これにより重要なタイプが変わる。コンテンツをクリーンで抽出可能な単位にシリアル化するタイプが勝つ。主にGoogleのリッチリザルト表示を助けるタイプは、GEOのコンテキストでは価値が低い。 AIのトレーニングデータとリアルタイム検索を支えるクローラー(Common Crawl、Bingのインデックス、Googleのクロール)はすべてJSON-LDを処理する。マークアップが有効で意味的に正確であれば取り込まれる。偽のFAQや不一致のタイプが詰め込まれていれば、モデルはそれを信頼しないよう学習する——または無視する。 ## ArticleとBlogPosting:著者アンカー 公開するすべての投稿には`Article`または`BlogPosting` schemaを付けるべきだ。華やかではないが、基礎的なことだ。 GEOで最も重要な2つのフィールドは`author`と`dateModified`だ。AIエンジンは引用を表示するかどうかを決める際に、鮮度と名前付きの著者を重視する。著者が宣言されておらず、公開日が2年前のページは、名前付き専門家と最近の更新を持つページに対して競争力が低い。 ```json { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "AIエンジン向けSchemaマークアップ:効果の高いタイプとは", "author": { "@type": "Person", "name": "Alejandro Rioja", "url": "https://alejandrorioja.com/about/" }, "datePublished": "2026-05-31", "dateModified": "2026-05-31", "publisher": { "@type": "Organization", "name": "Alejandro Rioja", "url": "https://alejandrorioja.com" }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://alejandrorioja.com/blog/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/" } } ``` `dateModified`は正確に保つこと。すべてのページに偽の「今日更新」という日付を付けているサイトを見たことがある——モデルはそのパターンを検出して割り引く。コンテンツを実際に更新した時だけ日付を更新すること。 ## FAQPage:1時間あたり最高のGEOリフト 今すぐ情報ページに追加するschemaタイプを1つ選ぶとしたら、`FAQPage`だ。理由は構造的だ:AIエンジンはすでに質問に答えたがっている。FAQPageは1つのノードにラベル付きの質問とラベル付きの回答を渡す。推論は不要だ。 フィーチャードスニペットにも効果は現れるが、GEO効果はより確実だ。ユーザーがFAQエントリの1つに一致する質問をPerplexityにすると、モデルはすでに引用としてフォーマットしてあるため、あなたの回答をほぼそのまま引用できる。 実際に機能するFAQ schemaのルール: 1. 各質問は実際のユーザーの表現方法を反映していなければならない——マーケターとしてどう表現するかではない。 2. 各回答は自己完結していなければならない。記事を読んだ後にしか意味をなさない回答は引用されない。 3. ページあたり3〜6つの質問がスイートスポットだ。10個の弱い質問で埋めると逆効果になる。 ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "AIエンジンはどのschemaタイプを優先しますか?", "acceptedAnswer": { "@type": "Answer", "text": "AIエンジンはFAQPage、HowTo、Article/BlogPosting、Person、Organizationを優先します。これらのタイプはコンテンツをクリーンで抽出可能な単位にシリアル化するため、モデルは散文を解析することなく直接引用できます。" } }, { "@type": "Question", "name": "2026年にschemaマークアップはまだSEOに役立ちますか?", "acceptedAnswer": { "@type": "Answer", "text": "はい。Schemaマークアップは従来のクローラー(リッチリザルト用)とAIクローラー(引用抽出用)の両方に役立ちます。FAQPageとHowToは実装1時間あたりの投資対効果が最も高い。" } }, { "@type": "Question", "name": "1ページにFAQアイテムはいくつ含めるべきですか?", "acceptedAnswer": { "@type": "Answer", "text": "自己完結した質問回答ペアを3〜6つ含めるのがスイートスポットです。6つを超えると質が希薄になり、3つ未満だと引用の表面積が減ります。" } } ] } ``` ## HowTo:AIエンジンが引用したがる手順 `HowTo` schemaは活用されていない。ほとんどの人はレシピスタイルのコンテンツに実装してそこで止まる。しかしセットアップガイド、監査、フレームワークなど、あらゆる手順的なコンテンツが候補だ。 GEOでウェイト以上のパフォーマンスを発揮する理由:AIエンジンは「どうすれば……」というクエリにステップを列挙して定期的に回答する。名前付きステップを持つ`HowTo` schemaがあれば、モデルはあなたの構造をほぼ正確に再現できる。要約しているのではなく、手順を引用しているのだ。 ```json { "@context": "https://schema.org", "@type": "HowTo", "name": "ブログ投稿にFAQPage Schemaを追加する方法", "step": [ { "@type": "HowToStep", "position": 1, "name": "3〜6つの実際のユーザー質問を特定する", "text": "Google Search Consoleのクエリ、Redditスレッド、顧客メールから質問を抽出する。各質問は自然言語を反映すべきで、マーケター言語ではない。" }, { "@type": "HowToStep", "position": 2, "name": "自己完結した回答を書く", "text": "各回答は単独で意味をなさなければならない——「上述のように」や「セクション3を参照」という参照はない。回答あたり40〜120語を目指す。" }, { "@type": "HowToStep", "position": 3, "name": "ページのheadまたはbodyにJSON-LDブロックを追加する", "text": "FAQPageのJSON-LDを