2026/05/24Hermes Agent事例研究AIエージェントSkills活用

Hermes Agent × X自動化｜Xquik-devの43スキル構成とその後の再設計

【2026年8月5日訂正・更新】 本記事は2026年5月24日に、コミュニティのまとめリポジトリ awesome-hermes-agent の記載を主な出典として公開しました。その後、提供元である Xquik から事実誤認の指摘を受け、一次情報（Xquik公式ドキュメントおよび GitHub リポジトリの更新履歴）を確認しました。結果、以下4点を訂正します。

「非公式API・Webスクレイピング」という記述は誤りでした。本ツールキットはブラウザ自動化やスクレイピングを用いず、Xquik が提供するドキュメント化されたAPIを経由する構成です。該当箇所を修正しました（なお Xquik 自体は X Corp. とは資本・提携関係のない第三者サービスです）
「43スキル構成」は本記事の公開時点ですでに旧構成でした。リポジトリ履歴を確認したところ、スキルを細かく分割した構成（2026年4月30日時点の実測で41フォルダ）は2026年4月下旬から5月上旬にかけて存在し、5月上旬に1スキル構成へ統合されています。現在形で書いていた箇所を、時期を明示した過去形に改めました
ネイティブプラグイン「Hermes Tweet」とは別のプロダクトです。Hermes Tweet は Hermes Agent 用の Python ネイティブプラグインで、登録するツールは tweet_explore / tweet_read / tweet_action の3つ。本記事が扱う x-twitter-scraper とは設計も提供形態も異なります。混同を避けるため区別を追記しました
「2026年4月5日に公開」は誤りでした。リポジトリの作成は2026年2月27日です

以下、訂正を反映した本文です。

X（旧Twitter）の投稿、リサーチ、反応の分析までを1つのAIエージェントに任せられたら——SNSマーケティング担当者なら一度は描く理想です。株式会社Fyveでも、Xを軸にしたコンテンツ運用の自動化はクライアントから繰り返し相談を受けるテーマです。

今回取り上げる Xquik-dev の事例は、その理想を Hermes Agent から使えるツールキットとして実装したもので、公開されている中でも網羅性の高い実装例の1つです。特に、2026年4月下旬から5月上旬にかけて採られていたスキルを細かく分割する構成と、その後の統合・再設計という変遷そのものに、エージェント設計上の学びがあります。

現在の構成｜x-twitter-scraper と Hermes Tweet は別物

まず2026年8月時点の事実関係を整理します。Xquik-dev は X 自動化まわりで複数の提供形態を並行して持っており、混同されやすいためです。

x-twitter-scraper（リポジトリ作成 2026年2月27日）：Claude Code / Codex / Cursor などに対応するエージェント Skill。REST・MCP・webhook・エクスポート・監視・確認ゲート付き投稿をカバーします。付属の MCP サーバーは、カタログの多数のルートを意図的に2ツールへ集約する設計を採っています
Hermes Tweet（リポジトリ作成 2026年5月5日）：Hermes Agent 用のネイティブプラグインです（MCPサーバーではありません）。OpenAPI から生成した102本のエージェント呼び出し可能なエンドポイントを同梱しますが、エージェントに登録されるツールは3つだけです

Hermes Tweet の3ツールは、安全性の観点で役割が分離されています。

tweet_explore：APIを呼ばずに、同梱のエンドポイントカタログをローカル検索する
tweet_read：APIキー設定後、カタログに載っている読み取り専用エンドポイントを呼ぶ
tweet_action：書き込み系・非公開系。環境変数で明示的に有効化しない限りツール自体がエージェントから見えない

ここで押さえておきたいのは、「エンドポイント数」「ツール数」「スキル数」は別の指標だということです。102という数字はエンドポイント数であって、ツール数でもスキル数でもありません。エージェント連携の記事ではこの3つが混同されがちで、本記事の初出もその例に漏れませんでした。

当時の構成｜スキル分割という設計（2026年4月下旬〜5月上旬）

本記事がもともと取り上げたのは、x-twitter-scraper が一時期採用していたスキルを細かく分割する構成です。リポジトリ履歴で確認できる範囲では、2026年4月下旬から5月上旬にかけて40以上のスキルフォルダが並んでおり、X 上の主要なアクション——読み取り・書き込み・バルク抽出・AI による投稿草案生成——を1つのエージェントから扱える形になっていました。

注目すべきは、単に「APIを叩くスクリプト」ではなく、type付き（typed）の X アクセス層を起点に、スキルを役割別に整理して再利用可能な形で提供していた点です。Hermes Agent のスキルシステムが前提とする「1スキル1責務」の設計思想に沿って分解された構成と読めます。

当時のスキルのカテゴリ分類

当時のフォルダ構成は、おおむね次の4カテゴリに整理されていました。

読み取り系：検索・タイムライン・メンション・トレンド・記事・ブックマークなど、X 上の情報を観測するスキル群
書き込み系：投稿・DM・フォロー・プロフィール更新など、X 上で実際にアクションを行うスキル群
バルク抽出系：フォロワー・コミュニティ・リスト・スペースを横断して大量データを構造化収集するスキル群
AI コンポジション系：抽出データを材料に投稿草案を生成するスキル群（write-tweets、write-threads、optimize、going-viral など）

40超という粒度は、単発スクリプト集にしては多く、SaaSツールとしては細かい絶妙な配置です。Hermes Agent のスキルは「1スキル1責務」が原則なので、この構成は 「Xに対する多数の独立操作を、エージェントが状況に応じて選択・組み合わせて実行できる状態」を意図したものと読めます。

ただし前述のとおり、この分割構成は2026年5月上旬に1スキル構成へ統合されており、現在は採用されていません。以下の解説は「当時こう設計されていた」という記録として読んでください。

読者特典・無料ダウンロードHermes Agentに「任せる」前に読む本無料でダウンロード →

仕組み解説｜typed access という考え方

型付きアクセス層を挟む意味

X 関連の業務自動化では、取得経路の選択がそのまま保守コストに直結します。私たち Fyve でも「先週動いていたスクリプトが今週壊れている」という現象には何度も遭遇してきました。

本事例の "typed X access" という設計からは、生のレスポンスを直接スキルから扱うのではなく、型情報を持つ抽象層（TypeScript SDK と OpenAPI 由来のスキーマ）を経由して上位スキルがデータに触る設計が読み取れます。仕様変動の影響範囲を一箇所に閉じ込めるための層と捉えるのが自然です。

Hermes Agent は スキルの自己改善ループでスキル群を自動更新する仕組みを持ちます。その前提の上で、型付き層を間に挟む設計には「AI が改善できる範囲」と「人間が手当てすべき範囲」を分けやすくする利点があります。

投稿草案の生成をスキルとして切り出す

当時の構成のもう一つの特徴は、抽出した情報を素材に投稿草案を生成する AI コンポジション系スキルを独立して持っていた点です。想定される流れは次のようなものです。

読み取り系で観測 → バルク抽出で構造化収集
コンポジション系に渡して投稿草案を生成（反応を取りやすい構成の提案を含む）
必要に応じて書き込み系で下書き保存 → 人間レビュー → 投稿

なお、ここで生成されるのはあくまで草案であり、人間の確認を挟む前提の設計です（現行の Hermes Tweet でも、書き込み系ツールは明示的に有効化しない限りエージェントから見えない構造になっています）。Hermes Agent は 3層メモリ（短期 / 中期 / 永続）を持っており、長期運用するほど過去の投稿パフォーマンスを蓄積した上で文体やフックの傾向を学習できる構造です。

私たちの解釈｜分割と統合、どちらにも理由がある

この事例で最も示唆的なのは 「スキルの粒度設計」です。SNS 自動化を1つのモノリシックなスクリプトで書くと、いずれ壊れます。私たちが過去にXやLinkedIn周辺で行ってきた業務自動化でも、最終的に保守できる形に落ち着いたのは「小さな機能の集合体」として組み直した後でした。

一方で、この事例が興味深いのはその後の揺り戻しです。40超に分割された構成は、2026年5月上旬に1スキルへ統合されました。さらに Hermes Agent 向けには、102エンドポイントを同梱しつつ登録ツールは3つだけという Hermes Tweet が用意されています。付属の MCP サーバーも意図的に2ツール構成です。

つまり、「機能を細かく分ける」ことと「エージェントに見せる入口を絞る」ことは別の問題だという判断が働いています。エージェントに数十個の選択肢を一度に見せると、選択の精度は落ち、誤操作のリスクも上がります。カタログは分厚く持ちながら、入口は探索・読み取り・アクションの3つに絞る——この構造は、私たちがクライアント案件でエージェントの権限境界を設計するときの考え方とも一致します。

実務落とし込み｜国内で再現する際の注意点

同種の自動化を実装する際の実務的な注意点を、私たち Fyve がクライアント案件で確認している観点として共有します。

1. データ取得経路と利用規約を確認する

これは本事例に限らない一般論ですが、X は Developer Agreement と Automation Rules で自動化の範囲を定めています。認可されていないアクセスの禁止、過度な自動投稿の禁止、スパム的な自動化の禁止などが規定されています。

SNS自動化ツールを業務で採用する際は、そのツールがどの経路でデータを取得しているかを必ず確認してください。ブラウザ自動化やスクレイピングに依存する実装は、技術的には動いてしまうため本番投入されがちですが、規約面のリスクを負います。本事例の x-twitter-scraper および Hermes Tweet は、いずれもスクレイピングやブラウザ自動化を用いず、Xquik のドキュメント化されたAPIを経由する構成です。ただし Xquik は X Corp. の公式サービスではない第三者APIであるため、自社の用途・契約要件に照らした確認は別途必要になります。

2. 自動投稿の倫理面

AI による投稿草案生成は強力ですが、「事実関係の確認なしに自動投稿させない」のが原則です。Hermes Agent には人間レビューを挟む承認ステップを組み込めますし、Hermes Tweet 側も書き込み系ツールを既定で無効にしています。反応を取りに行く用途では、煽り・誇張・誤情報のリスクが上がります。私たちが SNS 自動化案件を受ける際は、必ずガイドラインを文書化し、エージェントの権限境界を明示的に絞ります。

3. データ保存と個人情報

X から取得した投稿データには、ユーザー名・プロフィール情報・位置情報など個人を特定し得る情報が含まれます。バルク抽出を業務で使う場合は、取得データの保管期間・アクセス権・削除フローを事前に設計しておくべきです。日本国内で運用する場合は、個人情報保護法の対象になり得る点にも注意が必要です。

4. スケジュール実行は Hermes Agent 側の機能で組む

Hermes Agent 本体には自然言語で cron 指定ができるスケジューラ機能があります（x-twitter-scraper や Hermes Tweet 側にスケジューラが内蔵されているわけではありません）。「毎日朝7時にトレンドを観測し、上位5件をSlackに通知」のような運用を、X 連携ツールと組み合わせて自然言語で指示するだけで構築できます。SNS 運用の定期作業の大半は、ここで自動化できます。