核心内容の要約
Springフレームワークの創始者であるRod Johnsonが20年以上ぶりに第一線に戻り、オープンソースのAIフレームワーク「Embabel」を立ち上げました。このフレームワークは、企業向けAIエージェントの「コントロール可能性、説明可能性、監査可能性」という問題を解決することを目的としています。彼は衝撃的な見解を示しました：これが人間が自ら選ぶ最後のフレームワークになるかもしれない——将来、AIツールが開発者の代わりに技術選択を行い、人間はもはやフレームワークを選んだりテクノロジースタックを構築したりする必要がなくなるでしょう。また、彼は企業向けAIアプリケーションに関して多くの「常識に反する」意見を持っています。例えば、AIのためにJavaを無闇にPythonに書き換えることに反対し、AIコーディングエージェントがコードライブラリを破壊する可能性があると警告しています。さらに、ゲームのNPCのプランニングアルゴリズムを利用してAIエージェントを「従順」にする方法も提案しています。
1. Springの創始者が戻ってきた：なぜ今AIフレームワークを作るのか？
Rod Johnsonは突然「異業種への転身」をしたわけではありません。彼はもともと音楽博士で、後にプログラマーになりました。20年前にSpringを使ってJavaによる企業開発の概念を再定義しました。今回の復帰は、GPT-3/ChatGPTによってAIが実用化されたことがきっかけですが、企業がAIを導入する際に多くの問題に直面しています：
- 上層部は「AIを全面的に活用せよ」と言うものの、チームは明確なビジネス目標なしにプロジェクトを進めている；
- AIが既存のシステムに無理やり組み込まれ、Javaベースの古いビジネススタックと乖離して「孤島」状態になっている；
- LLM（大規模言語モデル）を呼び出す際には「思いのまま」になり、結果がコントロール不能で監査も困難になっている。
彼は過去2年間TensorFlowを使ってきましたが、企業向けAIにはLLMと既存のビジネスシステム（Javaなど）をシームレスに統合し、AIの行動を「規則正しく」するためのフレームワークが欠けていることに気づきました。そこでEmbabelが誕生しました。
2. 企業向けAIは無闇にPythonを使うな！Javaこそが適している
多くの企業の経営者がJavaチームにPythonへの移行を求めていますが、Rodはこれを「間違いだ」と指摘しています：
- 2つのことを明確にする必要がある：データサイエンス（モデルのトレーニングや微調整）にはPythonが適しているが、企業向けAIアプリケーション（LLMをビジネスシステムに組み込む場合）には必要ない——LLMの本質はHTTP呼び出しであり、JavaでもPythonでも同じように簡単に実行できる；
- 隣接性が最も重要：企業の既存システムの90％はJavaで書かれており（データベース、サービス、コードライブラリなど）、Javaを使えばAIアプリケーションを直接構築できる；
- Embabelの妥協点：コア部分はKotlinで書かれている（よりモダンだが、Javaユーザーにとっては完全にシームレス——JavaコードでEmbabelを呼び出してもKotlin特有の違和感はない。
例えば、オーストラリアのある企業はJavaを使って小さな機能を実装し、95％のフォームチェックを自動化したが、Pythonに移行せずに成功している。
3. AIによるコード作成は楽しい？しかし、コードライブラリをめちゃくちゃにする可能性もある
Rod自身もAIを使って95％のコードを書いていますが、AIに完全なコントロールを任せてはいけないと警告しています：
- AIは「一時的なコード」（UIプロトタイプなど）の作成に長けているが、本格的なビジネスコードを書く際には機能を無秩序に追加し、設計が劣化し、コードが肥大化する；
- 彼の秘訣：アーキテクチャのコントロール権を自分で握り、AIには「実行の詳細」だけを書かせる——例えばAIが値を硬直的に設定した場合、彼は「ここではパターンマップを使うべきだ」と修正する；
- 企業でよくある問題：上層部がAIの使用を強制するが、チームは「なぜAIを使うのか」さえ明確にしていないため、プロジェクトが失敗する。
4. Embabelのハイテク：ゲームのNPCアルゴリズムでAIエージェントを「従順」にする
他のAIフレームワーク（LangChainなど）ではLLMが次に何をすべきかを自分で決めるが、結果はコントロール不能だ。EmbabelはゲームのNPCで使われているGOAPアルゴリズム（目的指向の行動計画）を採用している：
- NPCのように計画する：例えば「フォームチェックを行う」場合、GOAPは現在の状態を確認し、目標を達成するための手順を見つける（必須項目のチェック→形式の検証→LLMの呼び出し）；各ステップには明確な条件がある（例えば「必須項目が揃っていない場合は次に進めない）；
- 確実性と説明可能性：GOAPは動的計画だが、各ステップの経緯が追跡可能——なぜその手順を選んだのかがわかり、監査ログも出力される；
- コスト最適化：各ステップにコストを設定でき（例えば高価なLLMの呼び出しコスト）、GOAPは最も安いパスを自動的に選ぶ。
LangChainと比較すると、EmbabelのAIエージェントは「無秩序に動く」ことがなく、企業にとってより安心できる。
5. 将来のフレームワークでは人間が選ばなくてもいい？これが最後の人間が選ぶフレームワークかもしれない
Rodの核心的な判断は：開発者は消えることはないが、フレームワークの選択権はAIツールに移るだろう：
- モデルはますます強力になり、ツールが最適なフレームワークやテクノロジースタックを自動的に選んでくれる；
- なぜそう言えるのか？彼自身がSpringがフレームワークからインフラストラクチャへと進化する過程を経験しているからだ——今、AIツールも同様のことを行っている；
- しかし、企業アプリケーションにはEmbabelのようなフレームワークが必要か？必要だ！なぜなら企業は確実性と説明可能性を求めており、AIが選んだフレームワークもそれらの要件を満たさなければならないからだ。ただし、人間が直接選ぶ必要はなくなる。
彼は冗談交じりにこう言っています：「5年後、人々はまだ自分でアプリケーションを書くのか？おそらくないだろう。しかしEmbabelは少なくとも最後に人間が選んだフレームワークになるだろう。」
結論
Rod Johnsonの復帰は、単なるAIフレームワークを作ることではありません。AI時代において「開発者の価値」を再考するものです。将来の開発者は大量のコードを書く必要がなく、フレームワークを選ぶ必要もないが、アーキテクチャのコントロール権とビジネス理解力を持つことが求められます。彼の意見がすべて正しいわけではありませんが、Springの創始者として、彼の判断はすべての企業や開発者にとって重要です。彼はかつてJava開発のパラダイムを変えた人物であり、今回もAI開発のルールを変えようとしています。