Hexabot v3 評価：YAMLワークフローとMCPを1つのランタイムに載せるTypeScript製エージェント基盤
Hexabot v3 is an AI workflow automation platform, combining workflows, actions, agents, and conversational channels in one runtime.
ひと目でわかる
- これは何？
- Hexabot v3は、ワークフロー、アクション、エージェント、会話チャネルを同一ランタイムで扱うTypeScript製の自動化プラットフォームである。ここではREADMEとCLIの記述だけを根拠に、導入コスト、データ層の選択、ライセンス表記の曖昧さまで踏み込んで判断材料を整理する。
- 誰に向いている？
- 向いているのは、会話チャネルとツール呼び出しを1つのランタイムにまとめ、ワークフローをYAMLとしてリポジトリで差分管理したいチームである。向かないのは、Node.js 24.17.0未満の環境しか用意できず、管理画面を使わず設定ファイルだけで完結させたい場合だ。
- 商用利用できる？
- まず確認が必要です。このリポジトリのライセンスは自動分類の対象外なので、商用利用の前に LICENSE ファイルを読んでください。
- 今もメンテナンスされている？
- されています。最後のコミットは 23 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
会話ボットとワークフロー基盤を別々に運用している構成への回答
チャットボットのフレームワークと、業務フローを回す自動化ツールを別々に立てると、認証、会話状態、ツール呼び出しの権限が二重管理になる。Hexabot v3はここを1つのランタイムに畳もうとしている。READMEの説明では「workflows, actions, and conversational channels in one runtime」とあり、チャネル接続、アクション実行、エージェント、メモリ、MCPの接続点が同一プロセス上の概念として並ぶ。想定読者は、TypeScriptで書かれたサーバーサイドのコードを読み書きでき、LLMのツール呼び出しを業務フローに組み込みたい開発者である。ノーコードの管理画面だけを触りたい層を主対象にした作りではない。READMEがトピックとしてagent、workflow、llm、ollama、mcp系の語を並べている点からも、エージェント実装の土台として使う想定が読み取れる。
YAMLのワークフロー定義とZodのスキーマ契約が実行単位を決める
中核はアクションという実行単位である。READMEによれば、アクションはスキーマで検証されたinputs、outputs、settingsを持ち、ワークフローはそのアクションをYAMLで並べたものになる。つまりワークフローの実体はコードではなくYAMLファイルで、各ステップの入出力はZodスキーマで型付けされる。READMEは「Schema-first architecture」という表現でこの方針を要約している。さらにbinding systemという層があり、再利用可能なケーパビリティや設定をタスクのロジックから分離する。同じアクションを別の資格情報や別のチャネルに差し替えるときに、ワークフロー本体を書き換えずに済ませるための分離だと読める。メモリは明示的な定義と実行時の統合の両方が用意され、MCPはツールとコンテキストの相互運用のための接続点として言及されている。データの流れは、チャネルから入力を受けてワークフローが起動し、各アクションがスキーマ検証を通って次段へ値を受け渡す、という素直な構造である。ただしREADMEの範囲では、ワークフローの再開や失敗時のリトライがどの単位で保証されるのかは読み取れない。ここは実装を読むまで判断を保留すべき部分だ。
導入手順はCLIが3コマンドに畳んでいる
前提はNode.js ^24.17.0と、npm、pnpm、yarn、bunのいずれか1つ。Dockerは任意で、Dockerベースのサービスを使う場合に必要になる。CLIはグローバル導入かnpxで呼ぶ。
npm install -g @hexabot-ai/cli
プロジェクト作成と起動は次の流れになる。
hexabot create my-project cd my-project hexabot dev
グローバル導入を避けるならnpx @hexabot-ai/cli create my-projectのように読み替える。createはパッケージマネージャを自動検出し、--pmで固定できる。hexabot create my-project --pm npmが例として挙げられている。ローカルの既定エンドポイントは管理画面がhttp://localhost:3000、APIがhttp://localhost:3000/api、APIドキュメントが非本番時のみhttp://localhost:3000/docsである。日常的に使うコマンドはcreate、dev、start、stop、env、check、config、migrateの8つ。devとstartは--docker、--services、-dを受け付け、stopは--dockerに加えて-vと--remove-orphansを取る。データ層はTypeORMが標準で、ローカルの既定はSQLite、本番はPostgresが第一級とされ、DB_TYPEとDB_*変数で切り替える。設定の確認と変更はhexabot config showとhexabot config setで行う。
createがTTYを要求するためCIでは初期管理者を作れない
READMEで明示されている制約が1つある。hexabot createは初期管理者の資格情報を対話的に尋ねるため、対話端末（TTY）を必要とする。CIや非対話シェルのなかで実行しても、その場では完了しない。READMEの指示は「run it from a local terminal first」であり、つまり初期管理者の作成だけは手元の端末で済ませ、その後にCIへ渡す順序を強いられる。プロジェクトの雛形生成をパイプラインに組み込みたいチームにとって、これは設計上の摩擦になる。もう1つの注意点はバージョンの見え方である。リポジトリの説明はHexabot v3を名乗り、最終プッシュは2026年8月24日だが、公開されているリリースはv2.2.2（2025年1月24日）、v2.1.5（2024年12月10日）、v2.0.2（2024年10月27日）の3件で、いずれもv2系である。v3がどのリリースタグに対応するのかは、この材料からは判断できない。加えてREADMEは「This Quick Start targets projects generated with the CLI」と断っており、モノレポ自体に貢献する場合はPNPMとCONTRIBUTING.mdを参照せよとしている。利用者向けの経路と開発者向けの経路が最初から分かれている点は、把握しておかないと無駄な回り道になる。
n8nとは抽象の置き場所が違う
同じ「ワークフロー自動化」の語で比較されやすいのがn8nである。違いは抽象をどこに置くかにある。n8nはノードのカタログを管理画面から組み合わせることを中心に据え、フローの実体はGUI上で編集される。Hexabot v3はYAMLのワークフロー定義と、Zodでスキーマ検証されるアクションを前面に出す。ワークフローがテキストファイルである以上、Gitの差分としてレビューでき、プルリクエスト上で変更を追える。アクションの入出力がスキーマで固定されるため、壊れた受け渡しは実行時ではなく検証の段階で落ちる。代わりに、ノードをGUIでつないで数分で試す、という体験は期待できない。アクションを書くにはTypeScriptのコードを読み書きする必要がある。もう1つの比較軸はチャネルである。READMEはchannelsとhelpersを中核概念として挙げており、会話チャネルの継続性が最初から設計に入っている。汎用の業務自動化ツールに後付けでチャットを載せるのとは、前提が逆になっている。
ライセンス表記はLICENSE.mdを読むまで確定しない
READMEの末尾はCopyright (c) 2025 Hexastack、ライセンスはFCL-1.0-ALv2とし、全文はLICENSE.mdを参照せよとしている。リポジトリのメタデータ側はNOASSERTIONであり、自動判定がこの識別子を既知のライセンスとして認識していないことを示す。FCL-1.0-ALv2という文字列から、Apache License 2.0を土台にした独自条項付きのライセンスである可能性は推測できるが、条項の内容はこの材料からは一切分からない。ここは推測で埋めてはいけない部分だ。導入判断の前にLICENSE.mdを直接読み、商用利用、再配布、ホスト型サービスとしての提供、改変物の公開義務の4点を確認する必要がある。Apache 2.0系の表記があっても、追加条項が競合製品の提供を制限している例は珍しくない。法務判断はここでは扱わない。
維持コストはNode.jsのメジャー追従とアクションのスキーマ保守に集約される
前提がNode.js ^24.17.0と、現行のLTSより新しいメジャーを要求している。これはランタイムの更新を定期的に強いられることを意味する。CIのベースイメージ、Dockerのベース、開発者のローカル環境を同時に上げ続ける運用コストが発生する。データ層はTypeORM経由なので、SQLiteで始めてPostgresへ移す経路はDB_TYPEとDB_*の切り替えで足りる。ただしマイグレーションはhexabot migrateコマンド側の責務であり、スキーマ変更のたびにここを通す運用を決めておかないと、ローカルと本番の差分が静かに広がる。もう1つの継続コストはアクションのスキーマである。入出力をZodで固定する方針は壊れにくさと引き換えに、外部APIの変更のたびにスキーマ更新が必要になる。binding systemで設定を分離しても、型の変更までは吸収できない。更新の頻度が高い外部サービスをつなぐ場合は、この作業を誰が持つかを先に決めておくべきだ。
編集部の結論
向いているのは、会話チャネルとツール呼び出しを1つのランタイムにまとめ、ワークフローをYAMLとしてリポジトリで差分管理したいチームである。向かないのは、Node.js 24.17.0未満の環境しか用意できず、管理画面を使わず設定ファイルだけで完結させたい場合だ。導入前に確認すべきは3点で、hexabot createがTTYを要求するためCI上で初期管理者を作れないこと、LICENSE.mdのFCL-1.0-ALv2がOSI承認ライセンスなのか自社定義なのか、そしてv2系の最終リリースが2025年1月24日のv2.2.2である一方でmainブランチが2026年8月まで更新されているというバージョン表記のずれである。この3点が許容できなければ採用は見送る判断で構わない。
コミュニティノート