MaiBot（麦麦 MaiSaka）レビュー: QQ 群で「生き物」として振る舞う LLM エージェント
MaiSaka, an LLM-based intelligent agent, is a digital lifeform devoted to understanding you and interacting in the style of a real human. She does not pursue perfection, nor does she seek efficiency; instead, she values warmth, authenticity, and genuine connection.
ひと目でわかる
- これは何？
- MaiBot は QQ 群チャットに常駐し、GPT 的な箇条書きではなく人間らしい間合いで会話することを狙った Python 製エージェント。設計思想は「最像ではなく最像」、つまり高機能より人間らしさを優先する。その代償として、何が向き不向きかを整理する。
- 誰に向いている？
- 採用を検討すべきなのは、QQ 群という閉じた場で「役に立つアシスタント」ではなく「そこにいる誰か」として振る舞う存在を試したい人、そして GPL-3.0 の条件下で Python 3.12+ のコードを自分で読める人だ。逆に、業務タスクを確実に遂行するボット、応答の再現性や監査可能性が要求される用途、ライセンス条件を精査せずに社内へ組み込みたい用途には向かない。
- 商用利用できる？
- 条件付きでできます。GPL-3.0 はコピーレフトのライセンスで、これを含むソフトウェアを配布する場合、そのソフトウェアのソースコードを同じライセンスで公開する必要があります。配布せず社内で使うだけなら、この義務は生じません。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
MaiBot が埋めようとしている穴は「応答の質」ではなく「そこにいる感じ」
一般的なチャットボットは、質問に対して正しい答えを短い時間で返すことを目標に設計される。MaiBot の README はこの前提をはっきり拒否している。設計理念として引用されているのは「最像而不是好」、すなわち「より優れていること」ではなく「より人間らしいこと」を基準にするという原則だ。README の説明では、このプロジェクトは元々 NiuNiu bot に少し機能を足すためのものだったが、機能が増えて書き直しになり、QQ 群で活動する「生命体」を作ることを目的に据えたとされている。
対象読者は、グループチャットの参加者としてボットを置きたい人であって、タスク処理エージェントが欲しい人ではない。README が挙げる特徴もその方向に揃っている。GPT らしい長文や markdown の箇条書きを避けて「或长或短的闲谈」を志向すること、一問一答ではなく発言すべき時と黙るべき時を見極めること、多人会話で他人の話し方を模倣し新しい語や内輪の言い回しを覚えること、心理学の人格理論を参考に利用者への理解を蓄積すること。ここで注意したいのは、これらが README の主張であり、動作を検証した記述ではないという点だ。リポジトリの構成から確認できるのは Python 3.12+ を要求し、WebUI のスクリーンショットが同梱され、プラグイン API とイベントシステムが提供されるという範囲である。
main と dev の二本立て、そして README 内で食い違うバージョン表記
リポジトリは main を安定版、dev を開発中機能を含む版として明示している。README の表でも同じ区分が繰り返され、main には STABLE と付記されている。運用に使うなら main を追うのが素直な判断だが、README のインストール節は「最新版本: v1.2.3」と書いており、一方でリポジトリのリリース一覧には 1.2.4（2026-09-01）、1.2.3（2026-08-23）、1.2.2（2026-08-23）が並んでいる。README の記述がリリース一覧より古い状態で残っているということだ。
この不一致は些細に見えて、導入判断では効いてくる。どのバージョンを前提にドキュメントが書かれているのかが読み手には分からないからだ。デプロイ手順を読むときも、リリースノートを読むときも、まず自分がどのタグを対象にしているのかを固定してから読む必要がある。リリース間隔は 1.2.2 と 1.2.3 が同じ日付、1.2.4 がその約 1 週間後という並びで、更新の頻度そのものは材料からは判断できない。バージョン番号の桁が 3 つであること、日付が近接していること以外は推測しないほうがよい。
会話の間合いをどう作るか: README が語る範囲と語らない範囲
README は「不再是傻乎乎的一问一答」という表現で、発言のタイミングを制御することを売りにしている。適切な時に口を開き、適切な時に黙る、という振る舞いだ。同様に、多人会話で周囲の話し方を模倣し、新しい語や小圈子の黒話を自律的に理解して更新していくと説明されている。ここで読者が知りたいのは具体的な機構、たとえば発言の抑制がどの条件で発火するのか、模倣がどの単位で保存されるのかだが、README はそこまで踏み込まない。
確認できるのは、これらがプラグイン API とイベントシステムの上に載る拡張可能な構造だという点、そして WebUI が同梱されているという点までだ。心理学の人格理論に基づいて利用者の情報、好み、行動様式を蓄積するという記述も、蓄積の存在を述べるだけで保存形式や参照方法には触れていない。したがって、この種の「人間らしさ」を評価するには、README ではなく docs.mai-mai.org のドキュメントを読む必要がある。README の役割は方向性の宣言であって、機構の説明ではない。この記事で機構として断定できるのは、Python 3.12+ で動作し、プラグインとイベントの拡張点があり、WebUI から操作する、という骨格の部分に限られる。
導入の入り口: リリース、デプロイ手順、OneKey ランチャー
README が示す導線は 3 つある。第一に GitHub の Release ページから正式版を取得する経路。第二に docs.mai-mai.org のデプロイ教程に従う経路。第三に Windows/Mac 向けのランチャー Maibot OneKey（MaiBotOneKey リポジトリのリリース）を使う経路だ。Python 3.12+ が前提であることはバッジで明示されている。
設定キーや起動コマンドそのものは README には載っていない。したがって「このコマンドを打てば動く」と書ける材料はここにはない。確実に言えるのは、環境を用意する段階で Python 3.12 以上が必要で、その後の手順はデプロイ教程 side に委ねられているという構造だ。OneKey ランチャーが用意されている事実は、Python 環境の構築そのものを利用者に負わせたくないという判断の表れだと読める。逆に言えば、Linux サーバー上で動かしたい場合に OneKey が使えるかどうかは README からは分からない。Windows/Mac とだけ書かれている。サーバー運用を想定するなら、デプロイ教程を先に読んでから環境を決める順序になる。
GPL-3.0 であることの実務的な意味
ライセンスは GPL-3.0。これは寛容なライセンスではなく、派生物に同じライセンスを継承させるタイプだ。MaiBot を改変して配布する、あるいは組み込んで配布する場合、条件を満たす必要がある。ここで注意したいのは、プラグインという拡張点が用意されていることと、ライセンス条件がどう絡むかは別問題だという点である。プラグインを別配布する場合に GPL の及ぶ範囲がどうなるかは、プラグインの結合の仕方に依存する。この記事は法的助言ではないので、配布や商用組み込みを視野に入れるなら、自分でライセンス全文を読み、必要なら専門家に確認するべきだ。
もう一つの実務点は、このプロジェクトが QQ 群での運用を前提にしていることだ。閉じた場での人格的な振る舞いを目的とする以上、外部に配布するプロダクトへそのまま組み込む使い方は設計の想定から外れている。GPL-3.0 の条件と、想定された利用形態の両方から、社内ツールや個人のグループでの運用が現実的な着地点になる。
限界: 検証できない「人間らしさ」と、止まっている周辺プロジェクト
最大の限界は、売りにしている性質が定量的に確認しにくいことだ。README は「人間らしい」「自然」「親しみ」を掲げるが、これらは測定値ではなく主張である。応答の再現性、レイテンシ、誤発言率といった、運用で問題になる指標は README には一切ない。加えて、人格を蓄積するという設計は、蓄積された内容が期待とずれたときに修正する手段があるのか、という問いを生む。この点は README からは分からない。
周辺プロジェクトの状態も判断材料になる。MaiCraft（Minecraft で一緒に遊ぶ）は一時停止中と明記されている。Amaidesu（Bilibili 配信）と MoFox_Bot（MaiCore 0.10.0 ベースのフォーク）は並んでいるが、後者は本家とは別系統の派生であり、どちらを追うかで得られる機能とサポートが変わる。つまり、このプロジェクトは単体ではなく、複数のフォークと周辺ツールを含む小さな集合体として存在している。採用時には「MaiBot 本体」だけでなく、どの派生とどの周辺ツールを組み合わせるのかまで決める必要がある。そして、そのどれもが README の記述だけでは動作を保証しない。
代替としての汎用ボットフレームワークとの違い
比較対象として分かりやすいのは、汎用のチャットボットフレームワーク、たとえばコマンドとプラグインを中心に据えるタイプのボット基盤だ。違いは目標の置き方にある。汎用フレームワークは、入力に対して決まった処理を確実に返すことを重視し、応答の一貫性と予測可能性を設計の中心に置く。MaiBot はその逆で、README の言葉を借りれば「最像而不是好」、人間らしさを優先し、利用者ごとに振る舞いが変わっていくことを前提にする。
この違いは、そのまま適材適所になる。定型の問い合わせ処理、権限管理、監査ログが必要な用途では、予測可能性を捨てる設計は不利だ。逆に、グループの会話に緩く混ざる存在が欲しい場合、汎用フレームワークのコマンド体系は人間らしさから遠い。MaiBot 自身が MoFox_Bot というフォークを生んでいることも、この設計が一つの正解ではなく、派生を許容する性格のものだということを示している。どちらを選ぶかは、ボットに何を期待するか、つまり「正しさ」か「そこにいる感じ」かの選択になる。
維持コストと、誰が使い誰が使わないか
維持の観点で材料から言えるのは、リリースが継続的に出ていること、main と dev の二本立てで開発が進んでいること、そしてドキュメントが docs.mai-mai.org に集約されていることだ。追跡コストを下げるには main を固定し、dev は機能を試すときだけ見る、という切り分けが素直だろう。ただし README のバージョン表記とリリース一覧がずれている以上、更新のたびにリリースノートを自分で確認する手間は残る。
向く人と向かない人ははっきりしている。QQ 群で人間らしく振る舞う存在を試したい個人や小規模なグループ、Python 3.12+ の環境を用意でき、GPL-3.0 の条件を理解した上で使える人には候補になる。定型業務の自動化、応答の再現性が求められる用途、ライセンス条件を確認せずに社内配布したい用途には向かない。最初に確かめるべきは、デプロイ教程が自分の環境をカバーしているか、WebUI とプラグイン API の粒度が自分の拡張要件に合うか、そして自分が追うバージョンをどれにするかだ。README の「最新版本」表記だけを信じてタグを決めないこと。ここが最初の落とし穴になる。
編集部の結論
採用を検討すべきなのは、QQ 群という閉じた場で「役に立つアシスタント」ではなく「そこにいる誰か」として振る舞う存在を試したい人、そして GPL-3.0 の条件下で Python 3.12+ のコードを自分で読める人だ。逆に、業務タスクを確実に遂行するボット、応答の再現性や監査可能性が要求される用途、ライセンス条件を精査せずに社内へ組み込みたい用途には向かない。導入前に確認するのは 3 点で、docs.mai-mai.org のデプロイ手順が自分の環境（特に Windows 以外）をカバーしているか、main と dev のどちらを追うか、そして WebUI とプラグイン API が想定する拡張の粒度が自分の要件に合うかである。README が最新版として掲げる v1.2.3 とリポジトリのリリース一覧にある 1.2.4 が一致していない点も、追跡するブランチを決める前に自分で確かめておきたい。
コミュニティノート