botpress/botpress を採用する前に読む: リポジトリの実体と Botpress Cloud 依存の境界

このリポジトリが解く問題は「クラウド上の設定をコードに戻すこと」である

README は Botpress を OpenAI を利用したチャットボットとアシスタントを作るためのプラットフォームと説明している。ただしこのリポジトリが提供するのはプラットフォーム本体ではなく、Botpress Hub に並ぶ公開インテグレーション、CLI・SDK・API クライアントといった開発ツール、SDK と CLI だけで書かれたボットのサンプル、そして将来追加予定とされたプラグインである。つまり対象読者は、Botpress Cloud をすでに使っていて、その上で動く部品を自分の手元のコードとして書き、バージョン管理したい開発者だ。ノーコードの画面でボットを組み立てたいだけの人に向けたリポジトリではない。README 自身が、ボットをコードだけで作る方法は推奨されるやり方ではなく Botpress Studio の代替でもないと明記しており、この一文がリポジトリの守備範囲をかなり正確に示している。

インテグレーションは definition と実装の 2 ファイルに分かれる

bp init で生成されるインテグレーションは、integration.definition.ts と src/index.ts の 2 つを編集する形になる。README は前者を定義、後者を実装と呼び、役割を分けている。定義側にはインテグレーションの入出力や設定の形を宣言し、実装側に実際の処理を書く、という分担だと読める。この分離は型安全性と関係する。@botpress/sdk はインテグレーションを書くための SDK であり、@botpress/client は Botpress の API を型付きで呼ぶためのクライアントである。定義ファイルを起点に型が組み立てられるため、実装側で扱う入出力の形がずれにくい。README にはこの型生成の具体的な手順までは書かれていないので、生成物の詳細はドキュメント側を確認する必要がある。ここは README だけでは埋まらない部分だと明言しておく。

開発から配布までの流れは bp コマンド 3 つで表される

CLI の導入は npm install -g @botpress/cli、yarn global add @botpress/cli、pnpm install -g @botpress/cli のいずれかである。次に任意のディレクトリで bp init を実行すると、提示されたテンプレートからインテグレーションが生成される。README はこの手順をこのリポジトリのフォーク内で行う必要はないと明記しており、作業ディレクトリは自分で選んだ Git リポジトリで構わない。動作確認は bp deploy で、現在のバージョンがワークスペースに配備され、そのワークスペースの全ボットから使える状態になる。同じバージョンが既に配備済みなら更新、そうでなければ新規バージョンが作られる。配備されたインテグレーションは既定でワークスペース内だけの非公開であり、コミュニティに配る段階で bp deploy --visibility public を付ける。この一連の流れが、このリポジトリの実務的な中身のほぼすべてである。

公開したバージョンは二度と更新できない

README で最も見落とされやすい制約は、公開されたバージョンは以後更新できないという一文である。bp deploy --visibility public は取り消しの効かない操作として設計されている。これはつまり、公開後にバグを見つけても同じバージョン番号を差し替えることはできず、新しいバージョンを切って利用者に移行してもらう形になる。インテグレーションを自社のワークスペース内だけで使う限りこの制約は関係しないが、Botpress Hub に出す予定があるなら、公開のタイミングはリリース工程の最後に置くべきである。もう一点、既定が非公開であるという仕様は、逆に言えば明示的に公開操作をしない限り社内に留まるということで、検証中のものを誤って外部に出しにくい。公開範囲の制御はこの 2 つの挙動だけで完結している。

v12 とは別物であり、オンプレミスはこのリポジトリの対象外

README はオンプレミスの Botpress v12 に関する問題は別のリポジトリを見るよう案内している。つまり botpress/botpress は v12 の後継として同じ場所にあるのではなく、クラウド側の開発ツールとインテグレーションを置く場所として整理されている。最近のリリースとして v12.30.x が並んでいるのは、このリポジトリの履歴に v12 系が含まれているためだと読めるが、README の説明とリリースの日付は一致していない部分がある。2023 年 6 月の v12.30.9 が最新リリースとして記録されている一方、リポジトリ自体の最終 push はそれより後の日付を示しており、リリースタグの運用と master の更新が同じペースで進んでいるとは限らない。バージョンを固定して追いたい場合、この乖離は前提として把握しておく必要がある。

セルフホスト前提のフレームワークを探しているなら別の選択になる

同じ「LLM でチャットボットを作る」領域でも、アプリケーションを自分のサーバーで動かし、モデル呼び出しも自分の環境から出す構成を取るフレームワークは別に存在する。例えば LangChain はライブラリとして提供され、プロンプトの組み立て、ツール呼び出し、外部データの取得といった処理を自分のアプリケーション内に書き、実行環境も配備先も自分で決める。Botpress の場合、インテグレーションは bp deploy でワークスペースに配備され、ボットは Botpress Cloud 上で動く。コードは手元にあるが、実行はクラウド側である。この違いは、データの所在やネットワーク境界に要件がある場合に決定的になる。逆に、認証やチャネル接続、会話の管理を自前で作らずに済ませたいなら、クラウド側で動くことは利点になる。どちらが優れているかではなく、実行環境を自分で持ちたいかどうかで選ぶ。

ライセンスとビルドの前提

このリポジトリの全パッケージは MIT License で公開されており、コントリビュートしたコードも同じライセンスで公開することに同意する形になっている。MIT は制約の少ないライセンスだが、ここで注意すべきはライセンスが適用される範囲である。MIT が及ぶのはこのリポジトリに含まれるコードであり、Botpress Cloud のサービス利用条件はそれとは別に存在する。ローカルでビルドする場合の前提は git、node、pnpm の 3 つで、Windows では Microsoft Visual C++ Redistributable for Visual Studio 2015-2022 も必要とされている。手順は git clone、pnpm install、pnpm run build、pnpm run check の順である。ライセンスの解釈やサービスの契約条件については、実際に採用する前に各自で確認してほしい。

メンテナンスコストはクラウド側の変化に従う

このリポジトリを追い続けるコストは、依存パッケージの更新だけでは済まない。インテグレーションは Botpress Cloud の API と SDK に対して書かれ、bp deploy はクラウド側のワークスペースに配備する操作である。つまりクラウド側の仕様が動けば、手元のコードも追随が必要になる。README の Devtools の表を見ると、@botpress/client と @botpress/sdk のドキュメント欄は空になっており、CLI だけがドキュメントへのリンクを持つ。SDK とクライアントの仕様を README から読み取ることはできない。採用を決める前に、この 2 つのパッケージのドキュメントが実際にどこまで整っているかを確認しておくべきである。ドキュメントの薄さは、そのまま運用時の調査コストになる。

編集部の結論

採用を検討すべきなのは、Botpress Cloud のワークスペースをすでに使い、インテグレーションやボットを Git 管理されたコードとして扱いたい開発者である。逆に、オンプレミスで完結させたい場合や、クラウド側のアカウントを作らずに評価を始めたい場合には向かない。最初に確認すべきは、bp init で生成される integration.definition.ts と src/index.ts の内容、および bp deploy --visibility public で公開したバージョンが以後更新できないという制約が自分のリリース運用に収まるかどうかである。

公式情報源

1. botpress/botpress on GitHub
2. License: MIT
3. Project website
4. README
5. Releases