Koog を JVM プロジェクトに導入する前に確認すべきこと
Koog is a JVM (Java and Kotlin) framework for building predictable, fault-tolerant and enterprise-ready AI agents across all platforms – from backend services to Android and iOS, JVM, and even in-browser environments. Koog is based on our AI products expertise and provides proven solutions for complex LLM and AI problems
ひと目でわかる
- これは何？
- JetBrains が開発する Kotlin 製エージェントフレームワーク Koog について、README とリポジトリ構成から読み取れる設計、導入手順、バージョンの扱い、そして向き不向きを整理する。
- 誰に向いている？
- Kotlin と Gradle が既に前提になっている JVM プロジェクト、特に Spring Boot や Ktor 上でエージェントを組み込みたいチームには候補になる。逆に Python 側のエージェント資産や LangChain 系のツール群をそのまま流用したい場合、Kotlin への移植コストに見合わない可能性が高い。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Kotlin です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Koog が埋めようとしているのは Kotlin 側の空白
AI エージェントのフレームワークは Python を中心に育ってきた。JVM のサーバーサイド開発者が同じことをしようとすると、Python プロセスを別途立てて HTTP で呼ぶか、Java 向けの薄いクライアントを自前で書くかになりがちである。Koog はこの隙間を狙っている。README は「idiomatic Kotlin and Java API」と表現しており、型安全な Kotlin DSL でエージェントを組み立てることを前面に出す。
対象読者は、既存の Spring Boot や Ktor アプリケーションの中にエージェント機能を入れたい Kotlin 開発者である。別言語のランタイムを運用に追加したくない、あるいは既存の DI やログ、テスト基盤の中でエージェントを扱いたいという動機が想定されている。逆に、エージェントを単体のサービスとして切り出し、言語を問わず実験したいだけなら、このフレームワークを選ぶ理由は薄い。
グラフと永続化で「予測可能」を成立させる仕組み
README のキーワードで目を引くのは reliability と fault-tolerance である。中身として挙げられているのは built-in retries と agent persistence の2つで、後者は「restore the agent state at specific points during execution」と説明される。つまり実行の途中経過を保存し、失敗した地点から再開できる。長時間走るワークフローや、外部ツール呼び出しで落ちる可能性がある処理では、この仕組みの有無が設計を左右する。
もう一つの柱が flexible graph workflows である。エージェントの振る舞いをグラフとして記述し、ノード間の遷移として制御する。プロンプトの積み重ねで分岐を表現する方式に比べ、どこで何が起きるかをコード上で追いやすい。加えて modular feature system があり、機能を合成してエージェントの能力を組み替える。履歴圧縮も組み込みで、長い会話のトークン消費を抑えると README は説明する。
データの流れとしては、promptExecutor に渡された LLM クライアントが推論を行い、その結果がグラフのノードを進め、必要に応じてツールや MCP サーバーへ到達する。永続化層とトレース層がその周囲に付く構成だと、公開されている API リファレンスと README の記述から読み取れる。ただし具体的なシリアライズ形式や保存先の選択肢は README には書かれておらず、docs.koog.ai を確認する必要がある。
依存を追加してエージェントを1回走らせるまで
導入手順は README に具体的に載っている。Gradle Kotlin DSL なら build.gradle.kts に次を追加する。
implementation("ai.koog:koog-agents:1.2.0") implementation("ai.koog:koog-agents-additions:1.2.0-beta")
Groovy の build.gradle でも同じ座標を使う。Maven の場合は artifactId が変わり、koog-agents-jvm と koog-agents-additions-jvm を groupId ai.koog で指定する。リポジトリに mavenCentral() が含まれていることが前提である。
最小の実行例は README の quickstart にある。AIAgent に promptExecutor、systemPrompt、llmModel を渡し、agent.run("Hello! How can you help me?") の戻り値を println する。promptExecutor には MultiLLMPromptExecutor(OpenAILLMClient(apiKey)) のようにクライアントを包んで渡し、apiKey は OPENAI_API_KEY などの環境変数から読む。llmModel は OpenAIModels.Chat.GPT4o のような列挙値で指定する。
ビルド要件は JDK 17 以上、Kotlin 2.3.10 以上を既存プロジェクトで明示的に設定すること。README は gradle/libs.versions.toml を参照して依存バージョンを確認するよう案内しており、そこでは kotlinx-coroutines 1.10.2、kotlinx-serialization 1.10.0、kotlinx-datetime 0.7.1 が使われていると記載されている。
additions が beta のままである意味
依存の2行目、koog-agents-additions のバージョンは 1.2.0-beta である。本体の koog-agents は 1.2.0 で、README は Koog が semantic versioning に従う stable なフレームワークだと述べている。しかし additions は別扱いで、beta の接尾辞が付いたまま本体と並んで案内されている。
この非対称は導入判断で効いてくる。additions に何が含まれるのかは README からは判別できないが、beta 表記がある以上、API 変更や破壊的変更が本体より頻繁に起こる前提で扱うべきである。エージェントのコアだけを使い、additions を外せるなら、依存から1行落とせる。逆に additions が提供する機能に依存する設計にすると、本体の semver 保証の外側に足を置くことになる。リリース履歴を見ても 1.0.0 が 2026-05-21、1.1.1 が 2026-07-20、1.2.0 が 2026-08-28 と間隔は短い。stable 宣言後も活発に版が動いている点は、追従コストとして見積もっておきたい。
マルチプラットフォーム対応が効く場面と効かない場面
README は対応ターゲットとして JVM、JS、WasmJS、iOS、Android を挙げ、Kotlin Multiplatform による展開をうたう。サーバーで動かしているエージェントのロジックを、そのまま Android アプリや iOS アプリに持っていけるという主張である。
ただし、この利点が実際に効くのは共通コードとして切り出せる範囲に限られる。エージェントのループやプロンプト構築は共通化できても、API キーの保管、ネットワーク到達性、バックグラウンド実行の制約はプラットフォームごとに違う。README はそこに踏み込んでいない。モバイルで LLM を直接叩く構成を想定しているなら、鍵の扱いをどうするかは別途設計が要る。
JS と WasmJS への対応も、ブラウザからプロバイダの API を直接呼ぶ形になるのか、自前のバックエンドを経由するのかで意味が変わる。この点は README からは判断できない。マルチプラットフォームは採用理由になり得るが、対象プラットフォームでの認証と通信の設計を先に詰めておかないと、共通化の恩恵は思ったより小さくなる。
LLM 切り替えとプロバイダ抽象化の実際
対応プロバイダとして Google、OpenAI、Anthropic、DeepSeek、OpenRouter、Ollama、Bedrock が列挙されている。Ollama が入っている点は、ローカル推論や社内ネットワーク内での完結を求めるチームにとって実用的である。
README が掲げる機能の一つに、実行中の LLM 切り替えと履歴の適応がある。「Switch to a different LLM at any point without losing the existing conversation history」とあり、複数プロバイダ間のルーティングも想定されている。コストやレート制限に応じてモデルを切り替える、あるいは特定のタスクだけ別プロバイダに投げるといった運用が視野に入る。
ただし抽象化には限界がある。プロバイダごとにツール呼び出しの形式、ストリーミングのチャンク構造、システムプロンプトの扱いは異なる。履歴をそのまま持ち越せると README が書いていても、モデル固有の機能に依存した部分が完全に移植できるとは限らない。プロバイダを切り替える前提なら、切り替え後に同じ品質が出るかを自分のタスクで確かめる必要がある。ドキュメントに互換性の詳細な表があるかは、この材料からは分からない。
LangChain 系と比べたときの分かれ目
比較対象として自然なのは Python の LangChain や LangGraph である。違いは言語と型付けにある。LangChain は Python の動的型付けを前提に、多数のコミュニティ製インテグレーションを取り込んで成長してきた。ツール、ベクターストア、ローダーの選択肢は広い。
Koog は逆の方向を向く。Kotlin の型システムと DSL に寄せ、プロバイダやツールの接続をフレームワーク側が管理する。選択肢の広さより、コンパイル時に壊れた配線を検出できることを優先している。README が enterprise-ready や type-safe という語を使うのはこの立場の表明である。
したがって判断はこうなる。既存の JVM サービスにエージェントを足す、ビルドとテストを Gradle に統一したい、型で守られていないプロンプト配線に疲れた。そういうチームには Koog の設計が噛み合う。一方、Python 側に既にツール実装や評価パイプラインの資産があり、エージェントの実験速度を最優先するなら、Kotlin への書き直しは投資対効果が合いにくい。両方を併用する道もあるが、その場合はエージェントの状態をどちらが持つかを決めておかないと二重管理になる。
ライセンスと保守の見取り図
Koog は Apache-2.0 で公開されている。Apache-2.0 は商用利用を含む利用と改変を許容し、特許条項を含む。ただし本記事は法的助言ではない。自社の法務やコンプライアンス要件に照らした確認は別途必要である。
保守の面では、JetBrains の incubator プロジェクトという位置付けが README のバッジに示されている。デフォルトブランチが develop であること、リリース間隔が短いことから、活発に開発が進んでいる状態だと分かる。同時に、incubator は API の安定性が本体の semver 宣言だけで担保されるわけではないことを意味する。
質問や要望の窓口は Slack チャンネルと YouTrack の KG プロジェクトである。社内で採用を通すなら、この2つの窓口が実際に機能しているかを自分の目で確かめておきたい。導入後に詰まったとき、issue が拾われるかどうかはフレームワークの選定と同じくらい重要である。
編集部の結論
Kotlin と Gradle が既に前提になっている JVM プロジェクト、特に Spring Boot や Ktor 上でエージェントを組み込みたいチームには候補になる。逆に Python 側のエージェント資産や LangChain 系のツール群をそのまま流用したい場合、Kotlin への移植コストに見合わない可能性が高い。最初に確認すべきは、依存に含まれる koog-agents-additions が 1.2.0-beta である点を許容できるか、そして Kotlin 2.3.10 以上と JDK 17 以上をビルド環境で揃えられるかである。
コミュニティノート