スクリプトの出力をメッセージングプラットフォームへ流す
目次
hermes send は、Hermes ですでに設定済みのメッセージングプラットフォームへ メッセージを送るだけの、小さくてスクリプトから扱いやすいコマンドです。通知用の プラットフォーム横断の curl だと思ってください。ゲートウェイを起動しておく 必要も、LLM を使う必要もありません。ボットのトークンをスクリプトごとに 貼り直す必要もありません。
こんな場面で使えます。
- システムの監視(メモリ、ディスク、GPU の温度、長時間ジョブの完了)
- CI/CD の通知(デプロイ完了、テスト失敗)
- 結果を知らせたい cron のスクリプト
- ターミナルから一度きりのメッセージを送りたいとき
- 任意のツールの出力をどこかへ流したいとき(
make | hermes send --to slack:#builds)
このコマンドは hermes gateway がすでに使っているのと同じ認証情報と プラットフォーム用のアダプターを流用するので、設定をもう一式抱える必要は ありません。
クイックスタート
# Plain text to the home channel for a platform
hermes send --to telegram "deploy finished"
# Pipe in stdout from anything
echo "RAM 92%" | hermes send --to telegram:-1001234567890
# Send a file
hermes send --to discord:#ops --file /tmp/report.md
# Attach a subject/header line
hermes send --to slack:#eng --subject "[CI] build.log" --file build.log
# Thread target (Telegram topic, Discord thread)
hermes send --to telegram:-1001234567890:17585 "threaded reply"
# List every configured target
hermes send --list
# Filter by platform
hermes send --list telegram引数の早見表
| フラグ | 説明 |
|---|---|
-t, --to TARGET |
送り先です。宛先の書き方 を参照してください。 |
message(位置引数) |
メッセージ本文です。省略すると --file か標準入力から読み込みます。 |
-f, --file PATH |
本文をファイルから読み込みます。--file - で標準入力を明示できます。 |
-s, --subject LINE |
本文の前に見出しの行を付けます。 |
-l, --list |
使える宛先を一覧表示します。プラットフォーム名を位置引数で絞り込めます。 |
-q, --quiet |
成功時に標準出力へ何も出しません(終了コードだけ。スクリプト向きです)。 |
--json |
送信結果の JSON をそのまま出力します。 |
-h, --help |
内蔵のヘルプを表示します。 |
宛先の書き方
| 書式 | 例 | 意味 |
|---|---|---|
platform |
telegram |
そのプラットフォームで設定済みの既定のチャンネルへ送ります |
platform:chat_id |
telegram:-1001234567890 |
番号で指定したチャット・グループ・ユーザーへ送ります |
platform:chat_id:thread_id |
telegram:-1001234567890:17585 |
特定のスレッド、または Telegram のフォーラムのトピックへ送ります |
platform:#channel |
discord:#ops |
人が読める形のチャンネル名(チャンネル一覧の情報から解決します) |
platform:+E164 |
signal:+15551234567 |
電話番号で宛先を指定するもの(Signal、SMS、WhatsApp) |
Hermes がアダプターを持つプラットフォームは、どれも宛先に指定できます。 telegram、discord、slack、signal、sms、whatsapp、matrix、 mattermost、feishu、dingtalk、wecom、weixin、email などです。
終了コード
| コード | 意味 |
|---|---|
0 |
送信(または一覧表示)に成功しました |
1 |
プラットフォーム側で配信に失敗しました(認証、権限、ネットワーク) |
2 |
使い方、引数、設定の誤りです |
終了コードは Unix の慣例どおりなので、curl や grep と同じ感覚で スクリプトの分岐に使えます。
本文の決まり方
hermes send は、次の順でメッセージの本文を決めます。
- 位置引数 —
hermes send --to telegram "hi" --file PATH—hermes send --to telegram --file msg.txt- パイプで渡した標準入力 —
echo hi | hermes send --to telegram
標準入力が端末のとき(パイプでないとき)、Hermes は入力を待ちません。 代わりに使い方のエラーがはっきり出ます。本文をうっかり書き忘れたときに スクリプトが止まったままにならないようにするためです。
実際の使いどころ
監視: メモリやディスクの警告
監視スクリプトに書いていた場当たりな curl https://api.telegram.org/... の呼び出しを、持ち運びの利く 1 行に置き換えられます。
#!/usr/bin/env bash
ram_pct=$(free | awk '/^Mem:/ {printf "%d", $3 * 100 / $2}')
if [ "$ram_pct" -ge 85 ]; then
hermes send --to telegram --subject "⚠ MEMORY WARNING" \
"RAM ${ram_pct}% on $(hostname)"
fihermes send は Hermes の設定を流用するので、Hermes が入っている端末なら 同じスクリプトがそのまま動きます。ボットのトークンを端末ごとに環境変数へ 書き出す手間はありません。
CI / CD: ビルドとテストの結果
# In .github/workflows/deploy.yml or any CI script
if ./scripts/deploy.sh; then
hermes send --to slack:#deploys "✅ ${CI_COMMIT_SHA:0:7} deployed"
else
tail -n 100 deploy.log | hermes send \
--to slack:#deploys --subject "❌ deploy failed"
exit 1
ficron: 日次のレポート
# Crontab entry
0 9 * * * /usr/local/bin/generate-metrics.sh \
| /home/me/.hermes/bin/hermes send \
--to telegram --subject "Daily metrics $(date +%Y-%m-%d)"長時間の処理: 終わったら知らせる
./train.py --epochs 200 && \
hermes send --to telegram "training done" || \
hermes send --to telegram "training failed (exit $?)"--json と --quiet を使ったスクリプト
# Hard-fail a script if delivery fails; don't clutter logs on success
hermes send --to telegram --quiet "keepalive" || {
echo "Telegram delivery failed" >&2
exit 1
}
# Capture the message ID for later editing / threading
msg_id=$(hermes send --to discord:#ops --json "build started" \
| jq -r .message_id)hermes send にゲートウェイの起動は必要ですか
たいていは不要です。 ボットのトークンで動くプラットフォーム(Telegram、 Discord、Slack、Signal、SMS、WhatsApp Cloud API、そのほかほとんど)では、 hermes send は ~/.hermes/.env と ~/.hermes/config.yaml の認証情報を使って プラットフォームの REST エンドポイントを直接呼びます。単独で動くプロセスで、 メッセージを送り終えるとすぐ終了します。
ゲートウェイの起動が要るのは、接続を保ち続けるアダプターに依存する プラグイン型のプラットフォームだけです(たとえば WebSocket を張りっぱなしに する独自プラグインなど)。その場合はゲートウェイを指すエラーがはっきり出るので、 hermes gateway start で起動してからやり直してください。
宛先を一覧して探す
特定のチャンネルへ送る前に、何が使えるかを確認できます。
# Every target across every configured platform
hermes send --list
# Just Telegram targets
hermes send --list telegram
# Machine-readable
hermes send --list --json一覧は ~/.hermes/channel_directory.json から作られます。このファイルは ゲートウェイが動いている間、数分おきに更新されます。「no channels discovered yet」と出る場合は、一度ゲートウェイを起動して(hermes gateway start) 情報を用意させてください。
discord:#ops や slack:#engineering のような人が読める名前は、送信時に この情報から解決されます。番号の ID を覚えておく必要はありません。
ほかのやり方との比較
| やり方 | 複数プラットフォーム | Hermes の認証情報を流用 | ゲートウェイの要否 | 向いている用途 |
|---|---|---|---|---|
hermes send |
✅ | ✅ | 不要(ボットトークン型) | 下の用途すべて |
プラットフォームごとに生の curl |
それぞれ別に書く | 手作業 | 不要 | 重要な監視 |
--deliver を使う cron ジョブ |
✅ | ✅ | 不要 | 定期実行のエージェント処理 |
hermes send は、できるだけ単純な入り口であることを意図しています。 何を言うかをエージェントに考えさせたいなら、cron ジョブを組んでください。 エージェントの最終応答は、設定した deliver: の宛先へ自動で配信されます (エージェント自身がメッセージを送ることはもうありません)。定期実行に LLM が生成した内容を載せたい場合は、cronjob(action='create', prompt=...) に deliver='telegram:...' を添えて使います。文字列をそのまま流したいだけなら hermes send の出番です。
関連ページ
出力が任意のプラットフォームへ自動配信される定期ジョブです。
hermes send が cron の配信と共有している配信ルーターです。
プラットフォームごとの初回設定です。