📝

Hermes Agentで記事作成のワークフローを作ってみた

に公開
WordPress
Hermes
tech

はじめに

DIGLE MAGAZINEでは、日々届く音楽系プレスリリースをもとにニュース記事を作成しています。

今回、Hermes Agentを活用して、Slack上から記事作成を依頼し、WordPressの下書き投稿までつなげるワークフローを構築しました。

背景

最初に考えたのは、「プレスリリースをAIに渡せば記事を書いてくれるのでは」という単純な自動化でした。
しかし、実際の編集作業では、記事化するプレスリリースの選定や、修正依頼が来た場合の対応等、記事のテキスト作成以外の作業も必要です。
そのため、AIに記事本文を書かせるだけではなく、編集ワークフロー全体をHermes Agentで扱えるようにすることを目標に構築しました。

全体像

構成は大きく分けると、Slack、Hermes Agent、メールボックス、GitHub、WordPressの5つです。

人間はSlack上でHermesに記事作成を依頼します。Hermesは人間に指定されたメールをメールボックスから取得し、本文や添付画像をinputディレクトリに保存します。その後、DIGLE MAGAZINE向けの記事生成スキルを使って、WordPress投入用のファイル群をoutディレクトリに生成します。

生成されたファイルはGitHubにcommit/pushされ、GitHub ActionsからWordPress REST APIに送信されます。WordPress側では必ず下書きとして作成され、最終的な確認・調整・公開は人間が管理画面で行います。

実装したこと

記事生成スキル

Hermesには、DIGLE MAGAZINE向けの記事作成ルールをスキルとして持たせました。
このスキルには、文体や表記統一だけでなく、WordPress用の出力ファイル仕様、メール取得時の安全ゲート、修正版メールへの対応方針まで含めています。
これにより、単発のプロンプトではなく、継続的に同じルールで記事作成を行えるようになりました。

メールボックスの状態管理

メールボックスは単なる素材置き場ではなく、記事作成ワークフローの状態管理にも使うことにしました。

フォルダ 意味
INBOX 記事化候補。全メールを記事化するわけではない
Processing Hermesが作業中
Drafted 記事ファイル作成済み。Slack校正中またはgit push前
Processed Hermes側作業完了
NeedsReview 人間判断待ち
Superseded 修正版メールに置き換えられた旧メール

ただし、INBOXを「未処理キュー」として扱わない点が重要です。INBOXにあるメールはあくまで記事化候補であり、実際に記事化するかどうかはSlack上の人間の依頼によって決まります。

Hermesが作業を開始したメールはProcessingに移動し、記事ファイルが生成されたらDraftedへ、commit/pushまで完了したらProcessedへ移動します。修正版や重複疑いなど、人間判断が必要なものはNeedsReviewに送ります。

また、メールボックスだけでなくHermes側にも状態をもたせるsource-email.jsonというファイルを作成しました。

source-email.json

メールフォルダだけで状態管理を完結させようとすると、後から「この記事はどのメールから作ったのか」がわかりにくくなります。

そこで、メールから取得した素材はinput/{slug}/ディレクトリに保存し、記事ごとにsource-email.jsonを置くことにしました。ここにはMessage-ID、件名、送信者、本文ハッシュ、slug、現在のワークフロー状態などを記録します。

これにより、メールボックス上でフォルダ移動しても、記事と元メールの対応関係をリポジトリ上に残せます。

source-email.json
{
  "account": "example@example.com",
  "original_folder": "INBOX",
  "current_mail_folder": "Drafted",
  "message_id": "<Message-ID>",
  "from": "...",
  "subject": "...",
  "date": "...",
  "body_sha256": "...",
  "slug": "20260528-artist-release",
  "workflow_status": "drafted"
}

WP REST API

WordPressへの投入は、GitHub ActionsからREST APIを呼び出す方式にしました。

REST endpointでは、import_slug というpost metaを使ってslug単位の冪等性を担保しています。同じslugの投稿が既に存在する場合は、既存の投稿を更新（ただし、既に公開済みの場合はスキップ）する形にします。

また、作成される投稿は必ずdraftです。import用ユーザーにも公開権限は持たせず、公開は必ず人間がWordPress管理画面から行う設計にしました。

気をつけたこと

メールアドレスをAI専用のものにする

普段プレスリリースが送られてくるメールアドレス（press@example.com）をHermesが操作できてしまうと、勝手な削除や移動等の事故が起きる可能性があると考えました。
そこで、AI専用のメールアドレス(ai-press@example.com)にメールを自動転送する設定にし、Hermesは常にAI専用のメールアドレスからメールを取得するように設定しました。

SMTPの設定をしない

HermesのEmailゲートウェイ設定では、SMTPを設定しない構成としました。
これにより、Hermesから外部メールアドレスへメールを送信できない状態とし、誤ってメールを送信してしまうリスクを低減しています。

WordPressは必ずdraftで止める

未確認の記事が公開される事故を防ぐため、Hermes側には公開権限を除いたWordPressユーザーで記事作成をしてもらう運用にしました。

残課題

プレスリリースの自動選定

現状のワークフローだとSlackで記事化したいメールの件名を指定する必要があるため、選定作業は従来通り人の手による判断が必要な状態となっています。
1日に送られてくるメールの数も膨大なため、選定部分も自動化できると更に便利になりそうです。

修正版メール検出

現状、プレスリリースの修正版が来た際、修正をHermesに依頼するのは人間による指示・判断が必要となります。
そのため、修正版がメールボックスに来た際にHermes側で検知し、自動反映するまでの機能は構築できていません。
ただし、修正の検知、反映の自動化は便利な一方で、Hermesも人間も修正版に気づかず記事を公開してしまうことが一番怖いので、この点を防ぐ手立ては考える必要があります。

記事の画像設定

記事作成依頼時、複数の画像が添付されている場合、どの画像をサムネイルにし、どの画像を本文の画像として使用すべきか、という判断まではできていません。
画像のファイル名に「サムネイル」という文字列が含まれていればサムネイルに設定する、といった指示も可能かもしれませんが、プレスリリースの添付画像が常に同じルールとは限らないため、適切な画像を設定する仕組みづくりができると便利だなと考えています。

まとめ

今回の取り組みでは、Hermes Agentを単なる文章生成AIとしてではなく、編集ワークフローを実行するエージェントとして活用しました。

一方で、修正版メールの判断や最終公開判断など、人間が担うべき領域は明確に残しています。今後も構築したワークフローの調整を進めながら、AIに任せる部分と人間が判断する部分の役割を、より良い形にしていきたいなと考えています。

Discussion