
Apache Spark
イベント
該当するコンテンツが見つかりませんでした
マガジン
技術ブログ
タイトルとSEO、書いた後で毎回止まってませんか ども!龍ちゃんです。 ブログの執筆自体はサクッと進むんですが、タイトルとメタディスクリプションで毎回手が止まる経験ありませんか。SEOといわれても、じゃあ何をどう詰めればいいのか分からない。結局「まあこれでいいか」で、勢いに任せて投稿しています。 正直に言うと、ここが一番苦手な工程です。コードも本文も書けるのに、マーケっぽい言葉選びとかクリック率の感覚が要るこの仕上げに関しては難しいですね。そこに対するモチベが一切ないのが問題なのですが、せっかく公開するなら読んでほしいですよね。 なので発想を変えました。 苦手な工程こそ、書いた後に丸ごとAIに寄せる。 中身が固まってから、それを検索で届く形に翻訳するだけ。AIが出してくれたものをベースに考える。そうすれば質もスピードも保てます。 今日話すやり方、実はこのタイトル自体、これでAIに出させて決めました。その実物も、後で貼ります。 そもそも、仕上げで「何を磨く」のか 「磨く」って言っても、じゃあ何を磨くのか。ここを取り違えると、書いた後になって「そもそも誰に向けた記事だっけ」と企画からやり直すハメになります。それは執筆中に気づくべきことですね。 前提として、この記事は執筆の 仕上げ 、つまりタイトルとSEOだけの話です。その前段(狙うクエリ・どの角度で書くか・誰に届けるか)は書く前にもう決めてある状態からスタートしますが、その決め方は姉妹記事「 技術ブログの手戻りが消える、AI2体の「書く前レビュー」 」に譲ります。 磨くのは、 もう決まってる「角度」と「読者」を、検索で届く形=タイトルとメタに翻訳する ところだけです。だから、この段階で新しく狙うクエリを探したりはしません。狙うクエリは、ネタと読者が決まった時点で後から自然に立ってるものなので。 実例が早いので、この記事自身の決めごとを出すとこうです。ブログを書き始める前にアウトラインで決めることは以下のような内容です。 読者像 :中身は書けるのに、タイトル・メタ・SEOでいつも手が止まる/後回しにするエンジニア 記事の核 :苦手な仕上げ工程は、書いた後に丸ごとAIへ寄せられる 狙うクエリ :「技術ブログ タイトル AI」「ブログ タイトル 決め方 AI」「生成AI ブログ SEO」 この想定で作られたブログを検索で届く形にするのが、これから話す仕上げです。 苦手な工程だからこそ、書いた後にAIで詰める そもそも、なんでタイトルやSEOが僕にとって難しいのか。正解が数字で見えにくくて、マーケの経験値がいるからなんですよね。単純に、その経験が僕に無いんですよ。 SEO自体についての知識はWEB上に大量に情報があります。調査をしたところ、仕上げのSEOって、実はかなり型が決まってました。文字数、検索結果での見切れ幅みたいに、けっこう測れる型なんですよね。 その型は、具体的にはこんな定石の寄せ集めです。クリックされる語を選ぶ、行動を促す動詞を使う、検索意図と合わせる、主要キーワードは前半に置く。どれも Google公式のタイトル解説 や Backlinko あたりが前から言ってる話で、目新しさはゼロです。目新しくない=型が固まってる。これだけ明確に情報があれば、この情報をセットで渡せばAIに採点ごと任せられます。 やる気は一番出ないのに、ルールは明確。だからこそ、AIが一番得意です。 使うのは2体。 ① competitor-reviewer でタイトルの相場を見て、② seo-reviewer で3案出して、最後に人間が選ぶ。 以下、実際の使い方です。 ① 競合の「タイトルの付け方」を見る — competitor-reviewer 1体目は competitor-reviewer 。検索上位の競合記事を集めて、タイトルの構造・パワーワードの使い方・技術的な深さを分析して、差別化戦略を提案してくれる担当です。まず「何を入れて何を得るのか」を1枚にするとこうです。 ここでちょっと面白いのが、このエージェント、 アウトライン作成時にも使っている んですよ。 企画のときの使い方はこうです。狙うクエリを渡すと、上位記事を読んだうえで「競合が扱っていないトピック=差別化の余地」の表が返ってきます。それを見て決めるのは「書くか書かないか」じゃなくて「どの角度で書くか」。被っていても角度さえズラせば二番煎じにはならないので。実物の表は姉妹記事(書く前レビュー)のほうに貼ってます。 で、今回は同じ道具で、今度は「上位記事はどんなタイトルの付け方をしてるか=相場」を見る。返ってくるレポートは同じで、企画のときは差別化の欄を、仕上げのときはタイトル分析の欄を読んでるわけです。1本の道具を、企画と仕上げで別の面から使ってる、という感じですね。 実際にこの記事を書く前にも回しました。2026年7月時点で返ってきた相場が、こんな感じ。 文字数 :平均36字くらい キーワード位置 :前半に置いてるのは6割 パワーワード :「実践」「徹底」みたいな穏当な語が中心(1本だけ「最強」があったけど、ああいう煽り語は誇張リスクなので反面教師) 数値 :「◯選」「◯倍」止まり。記事固有の実測値を使ってるところは無し で、この相場が分かると、次のタイトル生成が「なんとなく」ではなく競合を分析したうえでの検討になるんですね。 ちなみにここ、相場に合わせるのが正解とは限らないのが面白いところで。平均36字ということは、検索結果で見切れる長さを踏み越えてる競合が半分近くいるってことなんですよ。上位にいるからといってタイトルまで最適とは限らない。なので文字数だけは相場に寄せず、見切れない全角30字前後に抑えます。あとはキーワードを前半に置いて、穏当な語は1個まで。この3つを、そのまま次に渡します。 ② タイトル・メタを3案出して選ぶ — seo-reviewer 2体目は seo-reviewer 。2025年時点で公開されているSEOの情報を集めて作った採点軸(文字数・見切れ幅・タイトルの定石)を持たせてあって、記事を渡すとタイトルとメタディスクリプションを3案、それぞれ違う狙いで出してくれます。こっちも1枚で。 ここで①とつながります。 seo-reviewer は、 competitor-reviewer の出力があると、自分では競合をWeb検索しにいかず、その相場データをそのままタイトル生成に使うんですよ。先ほどの出力をこちらの入力として食べる。AIを1個ずつ叩くんじゃなくて、出力が次のAIに流れていく。この連鎖が組めるのが、エージェントを工程で並べる旨味ですね。 で、実物です。冒頭で「このタイトル自体これで決めた」と言いましたよね。 いまあなたが開いてるこの記事のタイトル 、seo-reviewer に出させた3案から選びました。返ってきたのがこれです。 A(効果・数値) :技術ブログのタイトルとSEOは、書いた後にAI2体で詰める B(課題共感) :技術ブログのタイトルで毎回手が止まる人へ。AIに寄せる仕上げ術 C(学習) :技術ブログのSEO仕上げは、AIエージェントを連鎖させて学ぶ で、ここからが人間のお仕事です。今回の対応は以下のようになります。 タイトル :Aを採用。ただし「AI2体」の「2体」は、タイトルで見ると数字が浮くだけのノイズだったので削った → いまの「〜書いた後にAIで詰める」 メタディスクリプション :A案(80字)をベースに採用。ただそのままだと「競合を調べる担当」「3案を出す担当」っていう運用の具体が足りなかったので、そこを足して少し長く書き直した(このページの説明文がそれ)。推奨レンジは超えたけど、前半で要点が伝わるならと判断して伸ばしたところ 推奨のAに乗りつつ、余計な一語だけ削った。たったこれだけ。AIが出すのは3案と採点=叩き台と型で、乗るか・削るか・書き直すかは人間の判断です。ベースとして採用して、新規の案として構築してもよいし、気になる点があればディスカッションにそのまま持っていけます。 つまり、「考える」から「選ぶ・修正する」へ変わったということですね。あとは感覚の問題です。こんなタイトルなら「見たことあるか~」とか「お!いいじゃん」みたいな感じで選択するのは、作るよりも圧倒的に楽ですよね。 まとめ:苦手な工程は、仕上げでAIに寄せる タイトル・メタ・SEOは知らない人からすれば一番苦手な工程。でも、そこはもう型が決まってます。だから書いた後に、competitor で相場を見て、seo に3案出させて、人間が選ぶ。あの「まあこれで」で雑に付けて後悔する時間が、まるごと消えます。 ただ、正直に限界も。AIが出すのは「型と叩き台」です。どれを採るか、どこを削るか、順位が上がるかどうかは保証してくれない。このタイトルだって、推奨から「2体」を削ったのは僕です。最後に決めるのは、やっぱり人間です。あとは、データ取って伸びるタイトルの分析とかもやったらより精度が上がると思います。継続メンテですね…… 今日話したのは、執筆全体の中の最後の1工程です。書く前は 書く前レビュー 、検証から記事化までの全体の流れは この記事 にまとめてます。今日は2体でしたけど、 エージェントを何体も並べて記事ごと書かせる話 も別で書いてるので、気になる方はそちらも。 ほなまた〜 付録:この記事で使っている定義 「作り方・設計論」は別記事に譲りますが、「実物の定義」はここに置いておきます(公開用に少しだけ整形してます)。雰囲気とスコープの参考にどうぞ。 1. SEOエージェント seo-reviewer --- name: seo-reviewer description: 技術ブログ記事のSEO価値を評価し、タイトル・メタディスクリプション案を3パターン生成します。SEOタイトルの定石(社内採点軸SPARK=実在の公式規格ではない符丁)と文字数・ピクセル幅最適化に沿って評価。結果はファイル出力します。 tools: [Read, WebSearch, WebFetch, Write] model: sonnet --- # SEO Reviewer Agent 技術ブログ記事のSEO価値を評価し、最適化されたタイトル・メタディスクリプションを生成するエージェント。 ## 評価プロセス(要点) - Phase 1: 記事内容の取得(ファイル/URL/直接) - Phase 2: 競合データの取得 - 外部から競合分析データが渡されている場合は、それを使い Web Research はスキップする - 渡されていない場合のみ、簡易的な検索トレンド調査を行う(深い分析は competitor-reviewer を推奨) - Phase 3: SEO価値の評価(100点満点:タイトル/見出し/メタ/内部リンク/検索意図) - Phase 4: タイトル・メタを3パターン生成 - パターンA: 効果重視・数値訴求型 - パターンB: 課題共感・解決提案型 - パターンC: 技術トレンド・学習促進型 - Phase 5: レポートを review/seo-{日時}.md に出力 ## 評価原則 - 2025年版SEO基準の厳守(SPARKの適用・文字数/ピクセル幅の最適化・AI検索時代対応) - タイトルは記事内容を正確に反映(ミスリード厳禁) - 3パターンは明確に異なるアプローチにし、人間が選べる形にする 2. 競合調査エージェント competitor-reviewer (企画にも仕上げにも使う) --- name: competitor-reviewer description: 競合記事のタイトルとコンテンツを分析します。検索上位記事の構造・パワーワード・技術的深さを評価し、差別化戦略を提案します。結果はファイル出力します。 tools: [Read, WebSearch, WebFetch, Write] model: sonnet --- # Competitor Reviewer Agent 競合記事の**タイトルとコンテンツ**を分析するエージェント。 ## 使うべきタイミング - 記事執筆の最初(競合を把握してから書く)=企画:差別化の余地を見る - 記事公開前(差別化ポイントの最終確認)=仕上げ:タイトルの相場を見る ## 評価プロセス(4段階) - Phase 1: 分析対象の把握(記事タイトル・H2・技術スタック・メインキーワード) - Phase 2: 競合記事の収集(WebSearchで各クエリ5〜10件 → WebFetchで上位5件を精読) - Phase 3: 分析(タイトル:文字数・キーワード配置・パワーワード・数値/コンテンツ:網羅性・深さ・独自性) - Phase 4: レポートを review/competitor-{日時}.md に出力 ## 出力形式(要点) - タイトル分析(競合一覧+サマリー) - コンテンツ分析(記事ごとの強み・弱み) - 全体傾向(共通パターン / **競合で扱われていないトピック=差別化の機会**) - 差別化戦略(タイトル戦略・コンテンツ戦略) ご覧いただきありがとうございます! この投稿はお役に立ちましたか? 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 技術ブログのタイトルとSEOは、書いた後にAIで詰める first appeared on SIOS Tech Lab .
はじめにLINEヤフーで大規模データ処理基盤の開発を担当している浅沼と楊です。この記事では、秒間数万リクエストを処理する社内の HDFS(Hadoop Distributed File System)...
報告者:柾本 彬(技師 / 技術推進グループ・softcreate) 会期:2026年6月2日(火)〜3日(水) 会場:Fort Mason Center マイクロソフトが毎年開催している開発者向けイベント「Microsoft Build 2026」に参加してきました。ガチガチの技術レポートは参加した各社の優秀なエンジニアの方々が書いてくれていますし、同行した若き?エンジニア達も書いてくれそうなので一旦置いておいて、「現地に行って参加するってこんな感じなんだなぁ」というレポートをさせていただきます! 個人的には一昨年(2024年)のシアトルに続いて2度目のBuild参加。 今年の舞台はサンフランシスコです。
動画
該当するコンテンツが見つかりませんでした












