Edit Banana レビュー: 図を DrawIO の編集可能な XML に変換するパイプライン
Edit Banana: A framework for converting statistical formats into editable.
ひと目でわかる
- これは何？
- Edit Banana は SAM 3 とマルチモーダル LLM を組み合わせ、静止画像の図表を編集可能な DrawIO (XML) に再構築する Python フレームワークである。README は GitHub 版が Web サービスより遅れていると明記しており、導入判断はその点を軸に考える必要がある。
- 誰に向いている？
- 導入を検討すべきなのは、既存のフローチャートやアーキテクチャ図を DrawIO 上で再利用可能な資産に変換したいチームと、AGPL-3.0 の条件下でセルフホストを許容できる組織である。逆に、最新機能をすぐ使いたい場合や、CUDA 対応 GPU を用意できない環境には向かない。
- 商用利用できる？
- 厳しい条件付きでできます。AGPL-3.0 はネットワーク型コピーレフトのライセンスで、改変版をホスティングサービスなどとしてネットワーク越しに利用させる場合、その利用者にソースコードを同じライセンスで提供する必要があります。
- 今もメンテナンスされている？
- されています。最後のコミットは 2 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
静的フォーマットを編集対象に戻すという問題設定
図表は一度画像として書き出されると、要素の位置や色、矢印の種類を個別に変更できない。PowerPoint や Visio の元ファイルが失われていれば、編集は実質的に作り直しになる。Edit Banana が解こうとしているのはこの状態で、README は「Make the Uneditable, Editable」という表現で目的を説明している。入力は画像、出力は編集可能な DrawIO (XML) であり、Web デモでは画像をアップロードすると数秒で DrawIO が得られると記載されている。想定読者は、論文や仕様書に埋もれた図を後から手直ししたい技術者、あるいは図の再利用を前提にしたドキュメント整備を進めるチームである。
SAM 3 とマルチモーダル LLM の役割分担
README の Key Features によれば、図中の要素の切り分けにはファインチューニング済みの SAM 3 (Segment Anything Model 3) を使い、その後の再構築をマルチモーダル大規模モデルが担う。Architecture Pipeline の節が置かれているため処理段階は複数に分かれているが、README の抜粋では各段の入出力までは示されていない。確認できるのは、変換結果について「Preserves the layout logic, color matching, and element hierarchy」と説明されている点、形状の線や塗り、破線や線幅といった矢印スタイルを 1:1 で復元するとしている点、テキスト認識後にそのまま編集できるとしている点である。出力された要素は個別に選択でき、DrawIO のテンプレート差し替えやレイアウト調整が可能とされる。
インストールと実行に必要な構成
README の Installation & Setup と Usage の節が入口になるが、抜粋には個別のコマンドや設定キーまでは含まれていない。ここは推測で補わず、リポジトリを取得したうえで README の該当節を直接確認する必要がある。バッジから読み取れる前提は Python 3.10 以上と、CUDA 対応 GPU の推奨である。GPU バッジの文言は CUDA Recommended であり必須とは書かれていないが、SAM 3 とマルチモーダルモデルを動かす構成である以上、CPU のみでの実用性は README からは判断できない。設定は Configuration の節にまとまっていると目次が示しているので、モデルの指定や出力先はそこで確認することになる。
GitHub 版が Web 版に遅れているという明示的な警告
README の冒頭に WARNING があり、「Our GitHub repository currently trails behind our web-based service」と書かれている。つまりリポジトリを clone して得られる機能と、www.editbanana.net で試せる機能は同一ではない。導入検討の観点ではこれが最も重い制約で、デモの仕上がりを基準にセルフホスト版の品質を期待すると外れる可能性がある。開発ロードマップの節も存在するが、抜粋には内容が含まれていないため、どの機能がリポジトリ側に入っているかは個別に確認が必要になる。
向かないケースと、Web サービスという現実的な代替
最も素直な代替は、このプロジェクト自身が運営する Web サービスである。README は GitHub 版より Web 版のほうが最新だと明言しているため、変換品質だけを求めるならセルフホストせず Web に画像を投げるほうが早い。ただし Web サービスは外部に画像を送る前提であり、社外に出せない図を扱う場合はこの選択が取れない。もう一方の極にあるのが、DrawIO や Visio で人間が最初から描き直す方法で、要素の意味を正確に再現できる代わりに工数は画像の複雑さに比例して増える。Edit Banana が効くのは、この二つの間、つまり手作業では割に合わないが外部送信も避けたい中規模の図が対象になる。
AGPL-3.0 とリポジトリ内の表示の不一致
GitHub のメタデータが示すライセンスは AGPL-3.0 である。一方で README のバッジは Apache 2.0 を表示しており、両者は一致していない。どちらが実際に適用されるかは LICENSE ファイルの本文を確認しないと決まらない。AGPL-3.0 であれば、改変したものをネットワーク経由で提供する場合にソース開示の条件が及ぶ点が Apache 2.0 との実務上の差になる。ここでは法的助言はできないが、社内ツールとして改変して使う予定があるなら、この不一致は導入前に解消しておくべき論点である。商用ライセンスや技術提携の窓口として ccl@bit.edu.cn が README に記載されている。
メンテナンス費用と更新の追い方
最近のリリースは取得できておらず、リポジトリはアーカイブされていない。最終 push は 2026-09-07 時点と記録されている。リリースノートが存在しない以上、更新は main ブランチのコミットを追う形になり、破壊的変更の予告を事前に得る手段は乏しい。運用コストとして見落としやすいのは、SAM 3 とマルチモーダルモデルの重みを扱う分のストレージと GPU 時間で、これは図の枚数に比例して増える。README が GitHub 版の遅れを認めている以上、追従の負担は小さくない。固定したバージョンで動かし、更新は差分を確認してからにするほうが現実的である。
編集部の結論
導入を検討すべきなのは、既存のフローチャートやアーキテクチャ図を DrawIO 上で再利用可能な資産に変換したいチームと、AGPL-3.0 の条件下でセルフホストを許容できる組織である。逆に、最新機能をすぐ使いたい場合や、CUDA 対応 GPU を用意できない環境には向かない。最初に確認すべきは、README の警告どおり GitHub 版が Web サービスに遅れている範囲と、リポジトリの LICENSE ファイルとバッジの記載が食い違っている点のどちらが実際の適用条件かである。
コミュニティノート