会話履歴を「要約」せず「追記」だけで持たせる──200行のコアで動くエージェントランタイム「bub」のテープ設計

エージェントランタイムの多くは、会話が長くなると「要約」で文脈を圧縮する。だがこの要約はどうしても情報を失う。「bub」という公式サイトを開くと、この問題への別解が示されていた。「テープ(tape)」と呼ぶ追記専用の記録から、必要なたびに文脈を再構成する設計だ。公式サイトには「フック優先・テープ駆動・チャネル非依存」というキャッチコピーが掲げられ、GitHubのbubbuild/bubにはスター1.6k(サイト表示、2026年8月27日確認時点)というバッジが表示されていた。

3行まとめ

1. bubは「人と一緒に暮らすエージェントのための小さなランタイム」を謳うプロジェクト。公式サイトは「コアのコードは約200行、あらゆるターンの段階がプラグイン可能なフックで、ビルトイン機能もデフォルトのプラグインにすぎない」と説明している。
2. 文脈(コンテキスト)はセッション状態に蓄積されるのではなく、追記専用の「テープ」記録から都度再構成される。訂正は古い事実を上書きするのではなく、新しい事実を追記して古い事実を「supersede(覆す)」形で扱われ、あらゆる判断が監査可能・再生可能・フォーク可能になるという。
3. resolve_session・load_state・build_prompt・run_model・render_outbound・save_state・dispatch_outboundという7段階のターンステージが、それぞれ独立したフックとして定義されている。同じprocess_inbound()パイプラインがCLI・Telegram・他の任意チャネルを駆動し、フック側はどのチャネル上で動いているかを意識しない設計になっている。
4. GitHub(bubbuild/bub)の著者欄には3名の実名・メールアドレスが記載されており、そのうち2名（psiace・yihong）は、サイトが「コミュニティの声」として掲載しているコメント投稿者のユーザー名と一致した。

テープという「事実の統一モデル」

公式サイトの「Context model」というセクションが、この設計の核心を説明している。「文脈はセッション状態に蓄積されるのではない。追記専用のテープ——不変な事実の連続——から再構成される。エントリは何が起きたかを記録し、アンカーはフェーズの境界を示し構造化された状態を運ぶ」。

サイトに掲載されているサンプルのテープ表示には、ユーザーメッセージ・プロンプト構築・モデル応答・ツール呼び出し・ツール結果・訂正(correction)・保存(save_state)といったイベントが、タイムスタンプ付きで一列に並んでいた。訂正のエントリには「supersedes e_103(e_103を覆す)」という注記があり、古いエントリを消さずに「新しいエントリが古いエントリを上書き対象として指定する」形で記録が続いていく様子が示されている。サイトは「訂正は古い事実を覆す新しい事実を追記する——決して上書きしない。ビューはアンカーから前方に組み立てられ、丸ごと継承されるわけではない」と説明していた。

7つのフックがターンの全段階を担う

公式サイトの「Architecture」セクションによれば、bubの1ターンは次の7段階のフックで構成される。

1. resolve_session() — 正しい会話へのルーティング
2. load_state() — テープから文脈を再構成
3. build_prompt() — システムプロンプト+履歴+ツールの組み立て
4. run_model() — LLMプロバイダの呼び出し
5. render_outbound() — チャネル向けに返信をフォーマット
6. save_state() — テープへの永続化
7. dispatch_outbound() — CLI・Telegram等への送信

サイトが示すコード例では、build_promptフックはテープのエントリをsystemロールのメッセージと履歴として組み立て、run_modelフックはlitellm.completion()を呼んでいる。「モデルプロバイダを差し替えたい場合はこのフックを上書きするだけでいい」という設計思想がコードそのもので示されていた。

プラグインは「後から登録した方が勝つ」

公式サイトの「Plugin System」という項目には、group="bub"というPythonのentry-points機構を使ったプラグインシステムだと説明されている。特徴的なのは優先順位の決め方で、「後から登録されたプラグインが先に実行され、先に登録されたものを上書きする。フレームワーク側の特権は無い」という一文があった。ビルトインの実装自体も「ただのプラグインの1つ」に過ぎず、CLI・チャット・ゲートウェイ・コマンド・デフォルトのエージェントランタイムまで「ordinary plugins(ただのプラグイン)として出荷される」とサイトは説明している。

「人とエージェントは同じ操作者モデルを共有する」

サイトが掲げる特徴の一つに「Operator Equivalence(操作者の等価性)」という項目があった。「人間とエージェントは同じ操作者モデルを共有する——同じ境界、同じ証跡、同じ引き継ぎのセマンティクス。特別扱いは無い」。人間のオペレーターとAIエージェントを、システム設計上区別しないという思想が明記されている。

「コミュニティの声」の一部は、実は開発者自身の発言だった

サイトの「Community」セクションには中国語のコメントが複数掲載されていた。「bubをビルドブロックとして使い、自分のエージェント製品を作りビジネスに役立てる。複雑な概念を学んでから手が出せなくなるのではなく」(PsiACE氏)、「LLM時代にこれほど洗練されたコードは珍しい、と改めて強く推薦したい」(yihong氏)、「Cloud Codeのような汎用エージェントフレームワークが欲しいとずっと思っていたが、自分で作るのが億劫だった。そこでbubを見つけ、心の中で思い描いていたエージェントフレームワークにぴったりだと感じた」(earayu氏、原文の表記は「Cloud Code」)といった声が並んでいた。

だが、リポジトリのpyproject.tomlをraw取得して著者欄を確認すると、bubの開発者は「Chojan Shang（email: psiace@apache.org）」「Frost Ming（me@frostming.com）」「Yihong（zouzou0208@gmail.com）」の3名だと分かった。PsiACE氏はメールアドレスのローカル部分（psiace@apache.org）が、yihong氏は著者名欄の「Yihong」とGitHubハンドル「yihong0618」が、それぞれ表示名と一致しており（メールはzouzou0208@gmail.comでローカル部分は一致しない）、サイトが「コミュニティの声」として掲載していたPsiACE氏・yihong氏のコメントは、少なくともユーザー名の一致から見る限り、開発チームの当事者自身による発言である可能性が高い。earayu氏についてはpyproject.tomlの著者欄には見当たらず、この人物が開発チーム外の独立したユーザーかどうかは今回確認できなかった。中立的な第三者の評判というより、開発者自身が自分のプロジェクトの使い勝手を語っている可能性がある発言が混じっている、という点は留保して読む必要がある。

「約200行」に近いファイルは実在した、が正確な一致は確認できず

公式サイトが繰り返し強調する「コアは約200行」という数字について、GitHubリポジトリのソースツリーを実際に確認し、src/bub/配下の主要ファイルの行数をraw取得して数えた。

出典: raw.githubusercontent.com/bubbuild/bub/main/src/bub/ 配下、2026年8月31日取得分の行数を実測

フック実行を担うsrc/bub/hooks/runtime.pyが203行、同様にフック横取りを扱うsrc/bub/hooks/interception.pyも203行と、「約200行」に近いファイルが複数実在することが分かった。一方でテープの実装自体（tape.py）は535行、フレームワーク全体（framework.py）は415行と、コア機能全体としては明らかに200行を超えている。runtime.pyの冒頭には「Generic Pluggy execution with per-adapter fault isolation」というdocstringがあり、HookRuntimeクラスが「Pluggyフック実行を安全にラップするもの」と説明されている。ただし、サイトの文言はどのファイル（または複数ファイルの合計）を指して「約200行」と言っているのかを明示しておらず、この記事で確認できたのは「200行前後のファイルが実際に存在する」ことまでで、サイトの主張と1対1で対応づけられたわけではない。

GitHubのbubbuild/bubリポジトリのメタデータもHTML経由で直接確認した。Star数1,592・Fork数156・作成日2025年7月13日（2026年8月31日確認時点）で、公式サイトに表示されていた「1.6k」というバッジの数字とおおむね一致している。ライセンスはApache License 2.0だった。ACP対応(bub-acp-server)についても、ACP公式の全エージェント一覧に掲載されていることは確認したが、そのサーバー実装自体の中身までは読み込んでいない。

関連記事

• Agent Client Protocol(ACP)とは──コーディングエージェントを「LSPのように」つなぐ標準規格
• OpenClawと紛らわしい名前だが中身は別物──Rust製パーソナルAIエージェント「ZeroClaw」がスター3万を超えていた