ローカルLLM を使い始めてしばらく経つと、「モデルそのものの性能」だけでは埋まらない部分があると感じるようになりました。
例えば、文章を書いたりコードを補助してもらったりする用途であれば、ローカル環境だけでも十分便利です。
実際、僕自身も Ollama を中心にいろいろなモデルを試しながら、普段の作業に取り入れています。
ただ、ブログ運営のように「何を書くか」を考える場面になると、少し話が変わってきます。
ローカルLLM は学習済みの知識をもとに文章を組み立てることはできますが、
- 今どんな検索需要があるのか
- どんな言葉で人が調べているのか
といった外部の変化までは知りません。
もちろん、こちらの情報を与えれば整理や要約は得意です。
ですが、何も渡さない状態では、あくまでモデルが持っている知識の範囲でしか考えられません。
このあたりを触っていて感じたのが、「ローカルで推論する環境」と「外部から情報を集める仕組み」は分けて考えた方が面白い、ということでした。
そこで今回試してみたのが、ラッコキーワードの API 契約です。
単純に SEOツールを契約したかったわけではなく、検索データをローカルLLM に渡すことで、記事作成やサイト運営の補助として使えるかを試したくなりました。
いわば、ローカルLLM に「マーケティングの目」を持たせる実験です。
まだ発展途中ではありますが、すでにいくつか試していることがあるので、今回はその記録を整理してみます。
導入のきっかけ
ローカルLLM を使い始めた当初は、「手元で AI が動く」というだけでかなり新鮮でした。
実際、Ollama を入れてモデルを切り替えながら試していると、API 課金を気にせず何度でもやり直せるので、かなり自由度があります。
コードを書かせたり、記事の下書きを作らせたり、CLI ツールと組み合わせて遊んだりと、用途はいろいろ広がっていきました。
ただ、使い続ける中で少しずつ感じたことがあります。
それは、ローカルLLM は「考える相手」としては便利でも、「何を考えるべきか」を自分で見つけるのは苦手だということです。
例えば、記事作成で考えるとわかりやすいです。
あるテーマについて、
- 記事構成を考える
- 下書きを作る
- 見出しを整理する
このあたりはかなり得意です。
一方で、
- そもそも今どんなキーワードが検索されているか
- 関連して何が一緒に調べられているか
- どんな悩みが増えているか
といった、「外の状況」を知ることはできません。
これはローカルLLM に限った話ではなく、学習済みモデル全般に言えることですが、特にローカルで閉じて使っていると、この差を強く感じます。
モデルは知識を持っていますが、市場感覚を持っているわけではありません。
たとえば「Ollama」という単語一つでも、実際に調べる人の目的はかなり違います。
- インストールしたい人
- モデル比較したい人
- Claude Code 連携を知りたい人
- Open WebUI を試したい人
- API 連携したい人
同じ単語でも、検索意図は細かく分かれています。
この部分を知らずにローカルLLM だけに記事案を考えさせると、無難なまとめ記事になりやすく、実際の検索ニーズと少しズレることがあります。
ここで感じたのが、「モデル自体を賢くする」よりも、「判断材料を増やす」方が面白いのではないか、ということでした。
つまり、
ローカルLLM にすべてを任せるのではなく、外部データを渡したうえで考えさせる方法です。
検索キーワードや関連語の情報があれば、単なる文章生成ではなく、
- 何を書くべきか
- どの切り口が需要に近いか
- 既存記事とどうつなげるか
といった判断にも使える可能性があります。
ローカルLLM は最新のクラウド AI と比べると、単体の知能ではまだ差を感じる場面があります。
ただ、与える情報の質が上がれば、その差をある程度埋められるのではないか。
そんな発想から、「外部データを取得してローカルLLM に持たせる」実験を始めてみることにしました。
なぜラッコキーワードを選んだのか
今回契約したのは、ラッコキーワードのスタンダードプランです。
以前からフリープランは使っていて、記事を書く前に関連キーワードを軽く調べたり、検索ニーズの方向性を確認したりする用途で触れていました。
無料でも十分便利ではあったのですが、ローカルLLM と組み合わせて使おうと考えたときに、少し事情が変わりました。
人が画面を見ながら使う分にはフリープランでも十分でも、AI エージェントに継続的に調査させたり、定期取得したデータを蓄積したりする場合は、ブラウザ操作では限界があります。
そのタイミングで知ったのが、2026年4月のラッコキーワード API 公開でした。
このアップデートで、キーワード取得や検索順位チェックなどの情報を API 経由で扱えるようになり、n8n や各種エージェントから直接扱える現実的な選択肢になりました。
僕にとっては、この「API が使えるようになった」という点が契約の決め手でした。
正直なところ、ラッコキーワード自体は SEOツールとして有名ですが、今回の目的は一般的な SEO 作業とは少し違っています。
契約理由として一番大きかったのは、
- ローカルLLM に外部の検索データを渡したい
- AI エージェントから自動取得できる状態にしたい
- 自分で毎回調べなくても継続観測できる仕組みを作りたい
この3つです。
つまり、「キーワードツールを使いたかった」というよりも、ローカルLLM に市場データを読み込ませるための情報源が欲しかったという方が近い感覚です。
料金面で見ても、スタンダードプランの年額 29,700円という価格は、個人で試すには決して安くはありません。
ただ、API が使える SEO 系サービスとして見るとかなり手が届きやすく、他社サービスでは API 利用だけで月額1万円を超えるものも珍しくありません。
その意味では、「まず試してみる投資」としては比較的現実的でした。
また、スタンダードプランにすると、フリープランでは見えなかったデータも取得できるようになります。
たとえば、
- 月間検索数
- SEO 難易度
- 検索順位チェック
- 一括キーワード調査
- API 連携
といった情報が扱えるようになり、記事作成前の下調べにもかなり役立っています。
実際、記事を書く前に自分で確認するだけでも参考になりますし、そのまま JSON で取得してローカルLLM に渡せるのはかなり相性が良いと感じています。
ちなみに、僕は年額契約にしました。
毎月払いよりまとめて払う形にはなりますが、「しばらく継続して試す前提」で考えていたことと、途中でやめるよりもしっかり使い倒した方が判断しやすいと思ったためです。
結果として、これは単なる SEO ツール契約というより、ローカル AI 環境に外部の視点を追加するための投資という位置づけになっています。
このサイトでは「AI への投資」というカテゴリで公開していますが、今回の契約も、AI そのものに課金したというより、「 AI に判断材料を与えるための投資」と考えています。
【PR】ラッコキーワード
「 API 課金しない方針」と矛盾しないのか
このサイトでは、ローカルLLM を中心に試していることもあり、「できるだけ API 課金をしない」という考え方を一つの軸にしています。
そのため、今回ラッコキーワードの有料プランを契約したことについて、
「API を使っているなら方針と矛盾しているのでは？」
と感じる方もいるかもしれません。
この点については、自分の中では明確に分けて考えています。
避けたいと考えているのは、ChatGPT や Claude、Gemini などの LLM 本体に対する従量課金 です。
たとえば AI エージェントを試行錯誤していると、何度も指示を出したり、途中でやり直したり、失敗した処理を再実行したりすることがあります。
このとき、裏でトークン単位の課金が発生していると、
- この操作でいくらかかるのか分からない
- 試行回数を増やすほど不安になる
- 実験そのものを躊躇してしまう
という状態になりやすいです。
実際、僕がローカルLLM 環境を作り始めた理由の一つも、この「気軽に試しにくい感覚」をなくしたかったからでした。
一方で、今回契約したラッコキーワードは少し性質が違います。
こちらは、文章生成や推論を行う AI そのものではなく、検索データを取得するためのサービスです。
つまり役割としては、
- 考えるのはローカルLLM
- 材料を集めるのは外部サービス
という分担になります。
この構成であれば、思考処理の中心はあくまで自分の PC 内にあり、外部サービスは「データ取得専用」として使えます。
個人的には、この差はかなり大きいと感じています。
たとえば、ラッコキーワード API で取得した関連キーワードや検索順位データを一度ローカルに保存してしまえば、その後の分析や整理はローカルLLM 側で何度でも試せます。
プロンプトを変えて再分析したり、別モデルで比較したりしても追加課金はありません。
つまり、課金対象を「推論そのもの」ではなく「材料の取得」に限定しているという考え方です。
もちろん、完全に外部サービスを使わないわけではありません。
ただ、毎回の思考や対話そのものに課金される構成と比べると、かなりコストの見通しが立てやすくなります。
今回のラッコキーワードも、年額 29,700円という固定費で利用しており、使い方によって請求額が青天井に増えるものではありません。
この「上限が見える」という点も、自分にとっては大きかったです。
ローカルLLM を使う理由は人それぞれですが、僕の場合は、
- 外部に依存しすぎないこと
- 実験回数を気にせず試せること
- コストを事前に把握しやすいこと
この3つをかなり重視しています。
その意味では、今回の契約は「API 課金に戻った」というより、ローカルLLM をもっと活かすために、必要な情報源だけを追加したという位置づけです。
n8n で検索順位を自動取得
契約したあと、まず最初に試したのは検索順位の自動取得です。
ラッコキーワード API にはいくつか機能がありますが、現時点で一番わかりやすく実用に繋がりそうだったのが、特定キーワードの検索順位チェックでした。
以前から記事を書いたあとに検索順位が気になることはあったのですが、毎回手動で確認するのはどうしても続きません。
そのため、せっかく API が使えるのであれば、定期取得の仕組みを作ってしまった方がいいと考えました。
現在は、n8n を使って簡単なワークフローを組み、ラッコキーワード API に定期アクセスしています。
流れとしてはかなりシンプルで、
- 監視したいキーワードを指定
- API で順位を取得
- 結果をスプレッドシートに追記保存
という構成です。
複雑な分析まではまだしていませんが、まずは「記録を残すこと」を優先しています。
このあたりは、ローカルLLM と直接関係があるわけではありません。
どちらかというと、マーケティングデータを継続的に蓄積する土台づくりです。
ただ、ここで面白いのは、あとからローカルLLM に渡せる形式でデータを残せることです。
スプレッドシートに日次データが溜まっていけば、
- どのタイミングで順位が変化したか
- 記事公開後にどう推移したか
- 季節要因がありそうか
といった分析を、後からまとめて AI にさせることができます。
現時点では、まだ「取得して蓄積している段階」です。
週次レポートや月次分析まで自動化できているわけではありません。
ただ、こういうものは一気に完成させるより、
まずデータを貯める
→ 後から分析用途を広げる
という順番の方が進めやすいと感じています。
実際、ラッコキーワードの API を触ってみて思ったのは、単発で使うよりも「定点観測」に向いているということでした。
その場で1回調べるだけならブラウザ画面でも十分ですが、API で取得して保存しておくと、時間軸で比較できるようになります。
この差はかなり大きいです。
まだ試験運用レベルではありますが、少なくとも今の段階で、「ローカルLLM に判断材料を渡すためのデータ基盤」としては、かなり面白い手応えがあります。
【PR】ラッコキーワード
Hermes Agent の自作スキルでキーワード調査
ラッコキーワード API を契約して、次に試したのは「データを取得するだけでなく、ローカルLLM 自身に調査させること」でした。
単純に API の結果を見るだけなら、ブラウザ画面やスプレッドシートでも確認できます。
ただ、僕がやりたかったのはもう少し先で、「取得したデータをそのままローカルLLM に読ませて、会話しながら整理できる状態」を作ることでした。
その実験に使っているのが、Hermes Agent です。
記事作成時点では、Ollama 上で動かしている qwen 系モデルを組み合わせて、Hermes Agent にラッコキーワード API を扱う専用スキルを作成しています。
利用モデルは主に、
- qwen3.6:35b-a3b-coding-nvfp4
- qwen3.5:35b-a3b-coding-nvfp4
のどちらかです。
35Bクラスになると、単純なチャットだけでなく、複数ファイルを扱うエージェント用途でも比較的安定して動く印象があります。
実際の流れとしては、Hermes Agent に対して例えば
ラッコキーワードで 「ollama 画像生成」 を調査して
といった形でキーワードを渡します。
すると、ラッコキーワード API を順番に呼び出しながら、調査結果をディレクトリ単位で保存する仕組みにしています。
現在の構成では、以下のようなファイルが生成されます。
- 01-suggest.json – 検索候補
- 02-related.json – 関連キーワード
- 03-other.json – LSI / PAA
- 04-question.json – Q&Aサイト
- 05-headline.json – 上位サイトのタイトル
- 06-content.json – 競合サイト情報
- 07-cooccurrence.json – 共起語
これらは、キーワードごとに専用ディレクトリへ保存されます。
たとえば、
outputs/日付/ollama-画像生成/
のような形です。
つまり、単発で画面に結果を表示するだけではなく、「調査データを丸ごと残す」ことを前提にしています。
さらに、その JSON をもとに最終的な簡易レポートとして、
- research-summary.md
のようなファイル名でサマリーも生成するようにしています。
この research-summary.md は、現状だとまだ Markdown ベースのテキストレポートです。
そのため、読みやすさ、比較しやすさ、次の行動判断、という面では、まだ改善の余地があります。
ただ、それでもかなり面白いのは、ここまで自動で出力されると、そのままローカルLLM と対話できることです。
例えば、
- このキーワードで記事を書く価値はあるか
- 関連語から次に狙うテーマは何か
- 見出し構成に活かせそうな検索意図は何か
といったことを、保存されたデータを前提に会話できます。
これまでは、人間がブラウザで見て頭の中で整理していた情報を、そのままエージェントに渡せる感覚です。
もちろん、現時点では 100% 信用して任せられる段階ではありません。
実際には、Hermes Agent が出力した結果を見たあとに、自分でもラッコキーワードの画面を開いて確認しています。
データ取得ミスや解釈のズレがないか、人間側で確認しながら使っています。
それでも、「キーワード調査を一気にファイル化して、ローカルLLM と会話できる」というだけで、かなり作業体験は変わりました。
まだ発展途上ですが、ローカルLLM に外部データを持たせる価値を強く感じた実験のひとつです。
【PR】ラッコキーワード
現時点で感じていること
実際に使い始めて感じているのは、ラッコキーワード API をローカルLLM と組み合わせる価値は十分ある、ということです。
特に、データ取得そのものはかなり便利です。
これまでキーワード調査というと、ブラウザで検索して結果を確認しながら、自分でメモしたり記事構成に反映したりする流れでした。
もちろんそのやり方でもできますが、情報量が増えると整理に時間がかかります。
その点、API で取得して JSON として保存できるようになると、一気に扱いやすくなりました。
キーワードごとに関連語や質問系ワード、共起語などをまとめて出力できるため、あとからローカルLLM に読み込ませて対話できるのはかなり大きいです。
単純に「検索結果を見る」だけではなく、
- まとめて保存できる
- 後から別視点で読み返せる
- 他の処理にも流用できる
という差があります。
一方で、まだ弱いと感じる部分もかなりあります。
特に大きいのは、可視化と次のアクション設計です。
現状では、Hermes Agent に調査させた結果は JSON ファイルや Markdown レポートとして出力されます。
ただ、これだけだと情報は多くても直感的に把握しにくいです。
たとえば、
- どのキーワードが優先度高いのか
- 競合と比べてどこに狙い目があるのか
- どの記事を先に書くべきか
といった判断までは、まだ自動で整理されません。
要するに、「材料は出てくるが、意思決定支援としては未完成」という状態です。
ここは今後かなり改善余地があると感じています。
たとえば、取得データをグラフ化したり、変化量を可視化したり、優先度付きで提案させたりすれば、実用性は一段上がりそうです。
ただ、それでも現時点で十分価値はあります。
理由は、人間の確認を前提にするとかなり時短になるからです。
今は、
- エージェントに一通り調査させる
- research-summary.md を読む
- 気になる箇所だけ自分でラッコキーワード画面を確認する
という使い方をしています。
全部を手作業で調べるより圧倒的に早く、確認対象を絞り込めます。
100% 自動ではありませんが、「下調べを任せる相手」としてはかなり優秀です。
ローカルLLM は単体だと最新の市場感覚や検索トレンドまでは持っていません。
しかし、こうした外部データを与えることで、一気に使い道が広がるのは実感しています。
まだ完成形ではないものの、「意思決定の時短」に繋がる可能性は十分あると感じています。
今後やってみたいこと
現時点では、ラッコキーワード API を使った実験はまだ「調査データを取得して保存する段階」です。
それでも、少し触ってみただけで、次に試したいことがいくつか見えてきました。
一番やってみたいのは、週次・月次の自動レポート化です。
今は API で取得したデータをスプレッドシートや JSON ファイルに保存していますが、それを一定期間ごとにまとめてローカルLLM に読ませれば、変化の傾向を整理できるかもしれません。
たとえば、
- 先週と比べて新しく増えた関連キーワード
- 順位が変化した記事
- 伸びているテーマと落ちているテーマ
こういった内容を自動で抽出して、レポートとして出力できればかなり便利そうです。
現状ではまだ構想段階ですが、n8n と組み合わせればある程度自動化できそうだと感じています。
もう一つ興味があるのは、ローカルLLM による傾向分析です。
単発のキーワードを見るだけでなく、一定期間蓄積したデータを渡して、
- どのテーマに需要が集まり始めているか
- 関連ワードの広がり方に特徴があるか
- 既存記事と相性の良い新規テーマは何か
といった観点で分析できないか試してみたいです。
ローカルLLM は、単純な文章生成だけで使うよりも、「自分で集めたデータを解釈させる」とかなり面白くなります。
精度面ではクラウドの最新モデルに及ばない部分もありますが、与える材料が具体的になるほど実用性は上がるように感じています。
さらに、ブログ運営に直結する使い方として考えているのが、記事企画や内部リンク設計への活用です。
例えば、あるテーマを調査した結果から、
- 新しく書くべき記事候補
- 既存記事と関連づけられるテーマ
- ハブ記事に育てられそうなキーワード群
を抽出できれば、単なるキーワード調査で終わりません。
このサイトでは「タグをハブにして記事同士をつなげる」ことを意識しているので、こうした外部データをローカルLLM に渡すことで、内部リンク設計の補助にも使えるのではないかと考えています。
まだ実際にそこまで完成しているわけではありません。
ただ、今触っている範囲でも、「ローカルLLM に情報源を追加すると役割が変わる」感覚はかなりあります。
単なるチャット相手ではなく、データをもとに考える補助役として使える可能性が見えてきたので、この方向は今後も継続して試していきたいです。
まとめ
ローカルLLM を使い始めて感じているのは、モデル単体の性能だけでできることには、やはり限界があるということです。
最近のローカルモデルはかなり高性能になっており、文章生成やコード補助といった用途では十分実用的です。
実際に僕の環境でも、Ollama 上で動かした各種モデルを日常的に活用できています。
ただ、それだけでは「今、どんな情報が求められているか」「どの方向に需要が動いているか」といった外部の変化までは把握しにくいと感じています。
今回契約したラッコキーワードは、単に SEOツールを導入したというより、ローカルLLM に外部データを渡すための情報基盤を追加した、という感覚の方が近いです。
自分の中では、これは「AI への投資」というカテゴリにかなりしっくり来ています。
Mac mini を買ったことも、ディスプレイを追加したことも、結局はローカルで AI を使いやすくするための環境整備でした。
それと同じように、ラッコキーワードの契約も「 AI に与える材料を増やすための投資」と考えると自然でした。
もちろん、現時点ではまだ完成した運用ではありません。
n8n で一部の取得を自動化したり、Hermes Agent に調査を任せたりと試行錯誤している段階で、分析結果をそのまま信用できるわけでもありません。
最終的には自分で確認しながら使っています。
それでも、API 経由で情報を取得し、それをローカルLLM に渡して考えさせる流れが作れると、これまでとはかなり違う可能性を感じています。
「ローカルLLM はクラウド AI より弱い」と単純に比較されることもありますが、必要な情報を適切に渡せれば、用途によっては十分実用的な結果が得られる場面もあります。
まだ実験段階ではありますが、API を通じて外部情報を取り込みながら、ローカル環境だけでどこまでできるか。
その検証を続けていくのが、今かなり面白いところです。
