spcl/graph-of-thoughts を採用する前に読む: Graph of Operations という設計とその境界
Official Implementation of "Graph of Thoughts: Solving Elaborate Problems with Large Language Models"
ひと目でわかる
- これは何？
- LLM を使った推論手順を「操作のグラフ」として宣言し、Controller がそれを実行する研究実装。CoT や ToT を同じ枠組みで書き直せる柔軟さの代わりに、実行制御とコスト管理は利用者側に残る。
- 誰に向いている？
- 向いているのは、推論手順そのものを研究対象として扱い、prompter と parser を自分で書きながら GoO の形を差し替えて比較したい開発者です。既存のエージェントフレームワークをそのまま業務に流用したいだけのチームには向きません。
- 商用利用できる？
- まず確認が必要です。このリポジトリのライセンスは自動分類の対象外なので、商用利用の前に LICENSE ファイルを読んでください。
- 今もメンテナンスされている？
- されています。最後のコミットは 175 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
GoT が解こうとしているのは「推論手順の表現」であって推論そのものではない
このリポジトリは論文 Graph of Thoughts: Solving Elaborate Problems with Large Language Models の公式実装で、README は目的を「問題を Graph of Operations (GoO) としてモデル化し、LLM をエンジンとして自動実行する」と説明しています。ここで扱われている対象は、プロンプトの文言やモデルの選定ではなく、思考のつなぎ方の構造です。Chain-of-Thought は一直線の連鎖、Tree-of-Thoughts は木、GoT は任意のグラフ。この三つは別々のライブラリではなく、同じ GraphOfOperations の上に書き分けられるものとして提示されています。
想定読者は、推論手順を実験対象にしている人です。examples ディレクトリには論文で使われたものを含む複数の問題例があり、それぞれに README.md が付いています。アプリケーションに推論を組み込むための SDK というより、手順を記述して走らせ、出力グラフを比較するための実験基盤だと読むのが正確です。
GraphOfOperations と Controller の分離、そして prompter/parser という継ぎ目
中心にあるのは operations.GraphOfOperations です。README の例では append_operation で Generate、Score、GroundTruth を順に積んでいます。Generate が候補を生み、Score が scoring_function として渡された関数（例では utils.num_errors）で採点し、GroundTruth が utils.test_sorting で正解判定を行う。処理の順序と依存関係がグラフとして宣言され、実行は controller.Controller が担います。
Controller のコンストラクタには、言語モデル、GoO、prompter、parser、そして初期 thought state の辞書を渡します。初期状態のキーは例によって異なり、CoT の例では original / current / method、GoT の例では original / current / phase / method が入ります。つまり「どのキーがその問題にとっての状態なのか」はフレームワーク側が決めず、問題定義側が決める設計です。
prompter と parser が別オブジェクトになっている点は実務上大きい。プロンプトの組み立てと、LLM の出力から構造を取り出す処理が分離されているので、モデルを差し替えたときに壊れる箇所を parser 側に閉じ込められます。逆に言えば、この二つを自分で書かない限り新しい問題は動きません。
動かすまでに必要な手順と、config.json という暗黙の前提
インストールは二通り。利用者として使うなら pip install graph_of_thoughts、コードを書き換えるなら git clone https://github.com/spcl/graph-of-thoughts.git の後に cd graph-of-thoughts、pip install -e . です。Python 3.8 以上が必要と README に明記されています。
LLM の設定はこのリポジトリ単体では完結しません。README は graph_of_thoughts/controller/README.md の指示に従うよう求めています。コード例では language_models.ChatGPT("config.json", model_name="chatgpt") のように、カレントディレクトリの config.json に OpenAI API キーが入っている前提で書かれています。config.json の中身のスキーマは README 本文には示されていないので、controller の README を読む必要があります。
実行はモジュールとして叩けます。python -m examples.sorting.sorting_032 と python -m examples.keyword_counting.keyword_counting が例示されており、結果は各 examples のサブディレクトリに保存されると書かれています。出力は ctrl.output_graph("output_cot.json") のように JSON として書き出され、CoT 版と GoT 版の最終 thought state のスコアを見比べる、というのが README の示す比較方法です。
ライセンス表記が NOASSERTION であることを軽く見てはいけない
このリポジトリのメタデータ上のライセンス識別子は NOASSERTION です。これは「寛容なライセンスである」という意味ではなく、GitHub 側が既知のライセンス条文として自動判定できなかったという意味にすぎません。論文は AAAI の Proceedings に掲載されており、コードの配布条件が論文の出版条件と同じとは限りません。
ここで推測を書くことはしません。判断材料はリポジトリ直下の LICENSE ファイルと、必要なら著者への問い合わせです。README には nils.blach@inf.ethz.ch への連絡先が記載されています。社内の法務確認を通す場合、PyPI の graph_of_thoughts パッケージと GitHub 上のソースで条文が一致しているかも別途見る必要があります。法的助言はここではできません。
バージョンは 0.0.2 のまま、ドキュメントの重心はコード内にある
公開されているリリースは v0.0.1（2023-08-23）と v0.0.2（2023-09-26）の二つで、いずれも 0.x です。semantic versioning の慣例に従うなら、0.x は破壊的変更が随時入りうる範囲です。リポジトリはアーカイブされておらず、最終 push は 2026-03-24 と記録されていますが、リリースタグが 2023 年で止まっている以上、タグ付きバージョンと main の差分がどこまであるかは自分で確認する必要があります。
ドキュメントの構造も特徴的です。README は論文を「フレームワークの高レベルな概要」と位置づけ、詳細は個々のモジュールのドキュメントを読むよう誘導します。特に Controller と Operations の README が重要だと明言されています。つまり README だけ読んで使い始められる作りにはなっていません。API リファレンスサイトのようなものは提示されていないので、関数の意味はコードとモジュール README を突き合わせて把握することになります。
LangChain との違いは抽象の高さではなく、抽象の向き
比較対象として素直なのは LangChain です。どちらも LLM 呼び出しを組み合わせて多段の処理を作りますが、抽象化している対象が違います。LangChain はツール、メモリ、リトリーバル、外部連携といった「LLM の周辺にあるもの」をつなぐ部品を提供します。graph-of-thoughts が抽象化しているのは思考の依存関係そのもので、Generate した候補を Score し、複数の候補を一つの状態にまとめる、といった操作のグラフです。
この違いは、既存のエージェント実装を置き換えられるかという問いへの答えになります。置き換えにはなりません。graph-of-thoughts にはツール呼び出しや外部データソースの管理という概念が README の範囲では出てきません。逆に LangChain で GoT のグラフ構造を厳密に再現しようとすると、探索の分岐と統合を自前で管理することになり、その部分がこのリポジトリの主題です。研究の再現や手順の比較が目的ならこちら、プロダクトへの組み込みが目的なら別の選択肢、という住み分けになります。
採用を見送るべきケースと、試すなら最初に確認する三つのこと
見送るべきなのは、LLM 呼び出しの回数を抑えたい場合です。GoT は候補を複数生成して採点する構造を取るため、GoO の組み方次第で呼び出し回数が増えます。README にはレイテンシやトークン消費に関する記述も、コストを制御する仕組みの説明もありません。Controller がどこで並列化するのか、リトライをどう扱うのかも README 本文からは読み取れないので、本番のスループット要件がある用途では、まず controller/README.md とコードを読んで判断することになります。
もう一つ、prompter と parser を自作するコストを軽視しないこと。examples に含まれる問題については既存の実装を流用できますが、自分の問題に適用する時点でこの二つは必ず書くことになります。parser は LLM の出力形式に依存するため、モデルを変えるたびに壊れやすい箇所です。
試すなら、まず git clone して pip install -e . で editable に入れ、controller/README.md に従って config.json を用意し、python -m examples.sorting.sorting_032 を実行して output_cot.json が生成されることを確認してください。その上で examples/sorting/sorting_032 の got() が組む GoO と、CoT 版の三つの operation を並べて読み、自分の問題をどちらの形に落とせるかを見る。ここまでで構造の見通しが立たないなら、この実装は目的に合っていません。
編集部の結論
向いているのは、推論手順そのものを研究対象として扱い、prompter と parser を自分で書きながら GoO の形を差し替えて比較したい開発者です。既存のエージェントフレームワークをそのまま業務に流用したいだけのチームには向きません。採用前に、リポジトリの LICENSE ファイルで実際のライセンス条文を確認し、graph_of_thoughts/controller/README.md の手順で対象 LLM のバックエンドが動くこと、そして examples/sorting を python -m examples.sorting.sorting_032 で一度実行して output_cot.json が生成されることを確かめてください。
コミュニティノート