導入しないことを決めたツールについて記事を書くのは、今回が初めてです。
便利そうなツールを見つけると、「試さないまま見送っていいのか」と迷います。
私も、複数のCLIエージェントを連携できるagmsgの導入を検討しました。しかし結論は、調査だけで打ち切りです。インストールも、エージェント同士の伝言テストも実施していません。
理由はagmsgの欠陥ではなく、今の自分のボトルネックである執筆速度に当たらなかったからです。「入れない判断」も、検証で得られた成果だと考えています。
FGLでは、実際に使って検証した内容だけを書いています。今回は導入前の調査と設計で止めたため、この記事はagmsgの使用レビューではありません。どこまで調べて、なぜ次のテストへ進まなかったのかを記録します。
agmsgはCLIエージェント同士の通信路
agmsgは、Claude Code、Codex CLI、Gemini CLIなどのCLIエージェント同士がメッセージを送り合える仕組みです。伝言板にはMac内のローカルSQLiteを使い、外部サーバーやクラウド中継を使わない設計です。
MCPとは役割が違います。MCPが「AIがツールを使う」ための規格なのに対して、agmsgは「AI同士が話す」ための通信路です。
ただし、提供されるのは通信路です。誰が何を担当するか、いつ止めるか、どう進行を管理するか、無限往復をどう防ぐかは、自分で設計する必要があります。
受信方式はmanual、turn、monitorの3種類があり、monitorは常駐監視型です。この受信方式の選び方が、今回の判断を大きく左右しました。
フル導入せず、2段階の検証を設計した
きっかけは、ChatGPTから提案された4AI編集部の構想でした。Codexを編集長、Claudeを執筆、Geminiを事実確認、別のCodexをレビュアーとして連携させる案です。
面白い構想でしたが、いきなりフル導入はしませんでした。まず読み取り専用で調べるPhase 1、その結果に問題がなければ隔離フォルダでMarkdown 1枚だけを伝言するPhase 2に分けました。
Phase 1はCodexに実施させました。この段階ではインストール、実行、設定変更を一切行っていません。その後、Phase 2を始める前の設計書もCodexに書かせました。
そして、その設計書をレビューした時点で不採用を決めました。Phase 2は未実施のまま終了しています。
導入前に確認した7項目
Phase 1では、次の項目を確認しました。この一覧は、agmsg以外のツールを評価する時にも流用できます。
- インストール時に変更されるファイルとディレクトリ
- Claude Code、Codex、Geminiの各設定へ追加される内容
- hookの有無と内容
- データの保存場所
- アンインストール手順の完全性
- 既存のプラグインやMCP設定と競合する可能性
- 外部ネットワーク通信の有無
調査で分かった良い点は、ローカルSQLite中心で外部送信がなく、隔離テストも実施できることです。設計は素直で、小さく試せる余地もありました。
一方で、グローバル構成の作成や各CLIの設定変更が発生します。また、Codexのリアルタイム受信に使うmonitorは実験的なbetaで、プロセスが残る既知の問題がありました。無限往復、終了条件、役割管理もagmsg側では解決されません。
agmsgを導入しなかった4つの理由
安全な構成では自動化にならなかった
常駐監視のmonitorを使わない場合、3つのCLIを人間が巡回し、「受信を確認して」と指示する必要があります。
これでは、手動コピペが手動巡回に置き換わるだけです。通信の受け渡し方は変わっても、人間が各画面を回る作業は残ります。自分が欲しかったのは通信路ではなく、記事制作の負担を減らすことでした。
100文字のテストに対して変更範囲が大きすぎた
Phase 2で試す予定だったのは、Markdown 1枚に短い伝言を残すテストです。
しかし安全に実施するには、隔離フォルダの作成、設定のバックアップ、ハッシュの保存、インストール、復元、残存ファイルの確認まで必要でした。短い伝言テストに対して準備と後片付けの範囲が大きく、今の自分には費用対効果が合いませんでした。
通信路より管理対象が増えた
導入すると、team名、agent名、宛先、受信状態、各セッションの起動状態を新たに管理することになります。
AI同士が話せるようになっても、役割や停止条件が自動で決まるわけではありません。通信路は増えますが、記事を構成する力や文章を書く力が増えるわけではありませんでした。
自分のボトルネックに当たらなかった
最も大きな理由はここです。今のブログ運営で詰まっているのは、AI間の連携速度ではなく執筆速度です。
連携するAIを増やしても、記事の核を決め、読みやすい本文に仕上げ、WordPress下書きで確認する工程は残ります。通信を速くしても、遅い場所が別にあるなら全体は速くなりません。
機能だけ切り出しても運用コストは残った
agmsgを見送ったあと、代替案として、事実確認だけをGemini CLIへサブプロセスで依頼する構成も検討しました。
ルール追記までは実装しましたが、APIキー管理、レート制限、モデル切り替えの運用コストが効果を上回ると判断し、ロールバックしました。
ここで得た教訓は、機能を小さく切り出せば運用コストも小さくなるとは限らないことです。役割を1つだけ追加しても、その役割を安定して動かすための管理は別に発生します。
最終的には実務担当を1席に戻した
現在は、ChatGPTで企画とネタを固め、実務担当が記事作成からWordPress下書き、公開前チェックまで進め、最後にChatGPTがWeb検索を含むレビューをする流れにしています。
実務担当は1席です。通常はClaude Codeを使い、利用できない時はCodexが同じ役割を代替します。2つを同時に走らせて連携させるのではなく、その時に使える方へ仕事をまとめます。
記事本文の正本はWordPress下書きだけにし、修正往復は最大2回にしています。3回目が必要になったら、文章を直し続けるのではなく記事設計へ戻します。公開は明示的に指示した後だけです。
良いツールでも、ボトルネックに当たらなければ入れない
agmsgがダメなツールという結論ではありません。ローカル中心の素直な設計で、複数のエージェントを常駐させる開発スタイルなら有用だと思います。
ただ、今の自分には必要ありませんでした。良いツールでも、自分のボトルネックに当たらなければ入れない。調査にかけた時間は無駄ではなく、「今は導入しない」と判断するための材料になりました。
今後、複数のCLIエージェントを同時に常駐させる運用へ移行したら、agmsgを再検討します。再評価する条件を決めて手放せば、新しいツールを追い続けず、今必要な作業へ戻れます。
コメント