既存Java資産にAIを組み込むJetBrains Koog 1.0入門

この記事の対象読者

• JavaやKotlinの業務システムを持つ企業
• 既存システムにAIエージェントを組み込みたい企業
• AI開発を内製化したい企業や組織
• Python以外の開発環境を探す企業
• AIエージェントの本番運用を検討する企業

Koog 1.0で担わせる処理

エージェント開発の現在地

海外では、LLMに質問するだけでなく、業務システムを呼び出すエージェント開発が議論されています。JetBrainsは開発者向けのソフトウェア製品を提供しており、Koog 1.0もJVMの開発現場から検討する対象といえるでしょう。BinxAIが見てきた範囲では、既存Java資産を持つ現場ではPythonへ業務ロジックを移すこと自体が負担になりやすい傾向があります。

Koog 1.0は、Pythonの代替と決めつけるより、既存サービスとエージェントを同じ開発基盤で接続する設計候補として見ると整理しやすくなります。

• 問い合わせの分類、既存の顧客・契約サービスから情報を取得する
• 申請内容の確認、入力項目の不足を検出し、確認事項を返す
• 業務手順の補助、複数の既存APIを順番に呼び出して結果をまとめる
• 担当者への引き継ぎ、判断できない条件と実行履歴を残す

エージェントに業務の所有権を渡すのではなく、既存サービスを安全なツールとして呼ばせる設計が出発点です。

今すぐ問い合わせる

JVM向け構成と責務分離

4層構成の考え方

構成は、エージェント、ツール、既存業務サービス、データベースの4層に分けます。エージェントは次の行動を選び、業務サービスが入力検証と認可を担当する形です。

Java資産との連携では、既存のREST APIやサービスクラスをそのまま信頼するのではなく、エージェント用の薄い境界を置くのが基本です。たとえば注文変更ツールは、注文番号と変更内容を受け取り、利用者の権限を確認してから既存サービスを呼び出します。

• エージェント層、ユーザー入力を解釈し、利用可能なツールを選ぶ
• ツール層、エージェントから呼べる関数と入力形式を定義する
• 業務サービス層、認証、認可、業務ルール、トランザクションを担う
• データ層、既存のデータアクセス処理と監査記録を管理する

セットアップ前の確認

Koog 1.0のAPIや対応範囲は、利用するバージョンの公式ドキュメントと実装例で確認しましょう。1.0というバージョンだけを理由に、すべての周辺機能が本番向けに固まっているとは判断しません。

• KotlinとJavaのビルド方式、JDK、依存関係の管理方法
• 利用するLLMの接続方式、認証情報の保管場所、通信経路
• 既存業務APIの認証・認可方式と、エージェント用の権限範囲
• ツール呼び出し、状態管理、エラー処理、ログ出力の確認方法
• テスト環境で再現する入力例、禁止操作、期待する終了条件

class OrderTool(
    private val orderService: OrderService,
    private val authorizer: Authorizer
) {
    fun updateOrder(command: UpdateOrderCommand, actor: Actor): ToolResult {
        authorizer.require(actor, "ORDER_UPDATE")
        require(command.orderId.isNotBlank())
        return orderService.update(command, actor)
    }
}

// Agent <- Tool <- Existing Java service <- Database

小さく組み込む手順

最初の対象業務の選び方

最初の対象は、読み取り中心で失敗時の影響を抑えられる業務に絞ります。受注確定や支払い処理を最初の題材にすると、エージェントの誤判断と再実行の影響を切り分けにくくなります。

• 1. 対象業務を1つに絞る、入力、参照データ、成功条件、禁止操作を書き出します。
• 2. 既存機能を棚卸しする、呼び出せるJavaサービスと、利用者ごとの権限を確認します。
• 3. ツールの境界を作る、エージェントに渡す引数、返却値、失敗時の状態を定義します。
• 4. 読み取りで試す、固定した評価ケースを使い、ツール選択と回答内容を記録します。
• 5. 更新は承認付きにする、実行前の確認画面や担当者承認を置いてから範囲を広げます。

ツール結果と状態管理の設計

ツールの返却値は、画面表示用の文章だけにしません。成功、入力不備、権限不足、対象なし、外部障害を区別できる構造にすると、エージェントが再試行や人への引き継ぎを判断しやすくなります。

{
  "status": "FORBIDDEN",
  "retryable": false,
  "message": "この操作を実行する権限がありません",
  "auditId": "内部で採番した監査ID"
}

状態管理では、会話履歴と業務トランザクションを分けます。会話を再開できても途中の更新処理まで再実行されないよう、業務側に冪等性キーと実行記録を持たせるのが基本です。

今すぐ無料相談する

本番前に測る項目

Koog 1.0の安定性は、単純な応答確認だけでは測れません。エージェントの基本ループが動いても、ツール失敗時や状態復元時に業務上の安全性が崩れる可能性があります。

評価ケースには、通常の質問だけでなく、曖昧な依頼、権限のない依頼、空の検索結果、途中切断、同じ依頼の再送を含めます。各ケースで最終回答だけでなく、選んだツールと引数も保存してください。

Pythonで新規基盤を作る方法と比べる場合は、モデル接続のしやすさだけを比べません。既存ライブラリの再利用、認証連携、運用監視、テストを誰が保守するかまで並べて判断するのが現実的です。

本番投入の判断は、回答品質と同じ表で、権限逸脱と失敗時の振る舞いを説明できるかで決めます。

自社で詰まる箇所と外部支援

実装前に担当者を決めておく論点

自社で進める場合、KoogのAPI確認より先に、既存Javaサービスの責務とエージェント用ツールの境界で詰まることがあります。特に、次の箇所は実装前に担当者を決めておきましょう。

• 既存APIが画面向けに作られており、エージェントへ返す結果の粒度が合わない
• 認証情報は取得できても、代理実行した利用者の権限を監査ログへ残せない
• 会話の再試行と業務更新の再実行を分離できず、二重処理の検証が足りない

外部の支援を使うと、ツールの実装だけでなく、対象業務の整理、現状の診断、要件定義を先に進められます。見積の範囲と成果物を細かく分ければ、契約後に要件が動いた場合も、決めた範囲内で優先順位を入れ替えやすくなります。

BinxAI株式会社のみっちゃくんでは、提案の前に現場へ入り、課題の整理と現状の診断を済ませてから要件を固めます。一式の見積ではなく詳細な見積を出し、企画から開発、本番展開まで同じ担当が進めます。

対応範囲には、契約後の優先順位変更、運用の引き継ぎ、内製化の支援、担当者向けの研修も含まれます。料金は公式ページと無料相談で、案件ごとの範囲を確認してください。

• 課題の整理と現状の診断
• 要件定義と設計
• 開発と本番環境への展開
• 運用の引き継ぎと内製化の支援
• 担当者向けの研修

既存Java資産とKoogの接続範囲を無料相談で整理する

よくある質問

Koog 1.0はPythonの代わりになりますか？

単純な代替として比べるより、既存のKotlin・Java資産を活かせるかで判断します。チームの運用能力、認証連携、監視、テストまで含めて比較してください。

Javaアプリケーションへどう接続しますか？

既存のREST APIやサービスクラスを、エージェントが呼ぶツールの背後へ置きます。認証、認可、入力検証、トランザクションは既存Javaサービス側に残す構成から始めます。

エージェントにデータベースを直接読ませてもよいですか？

本番業務では避ける設計が無難です。許可した検索条件を受けるサービスを用意し、利用者の権限と監査記録を通過させてください。

Koog 1.0の安定性は何で確認しますか？

基本ループの動作だけでなく、ツール呼び出し、状態管理、エラー処理、ログ、テストを実際のバージョンで確認します。依存関係を固定し、更新時に同じ評価ケースを再実行します。

最初から更新処理を自動化できますか？

最初は読み取り中心にし、更新は承認付きで試す進め方が現実的です。冪等性キー、二重実行の検知、失敗時の引き継ぎを確認してから自動化の範囲を広げます。

Koog 1.0を既存Java資産へ組み込むときは、LLMの呼び出し方よりも、エージェントと業務サービスの境界を先に設計します。読み取り業務で評価し、認証、トランザクション、監査、失敗処理を確認してから、更新処理へ進めてください。