翻訳｜宇琪
企画｜Tina
ロッド・ジョンソンが再び第一線に戻ってきた。
彼はSpringの生みの親であり、かつてエンタープライズJavaアプリケーションの開発手法を根本から再定義した人物だ。それから20年以上が経ち、今彼は新たに起業し、企業向けAIエージェントのためのオープンソースフレームワーク「Embabbel」を開発している。これは、LLMを実際のビジネスシステムに組み込み、単にツールを呼び出すだけでなく、制御可能で、説明可能で、監査可能なプロセスの中で動作させようとする試みだ。
興味深いのは、今回も彼が手がけているのはフレームワークであるにもかかわらず、彼自身がフレームワークの未来に対して、少なくともかつてのような楽観的な見方はしていないことだ。彼の見解では、モデルは今後も進化を続け、ツールが開発者に代わって多くの選択を行うようになるだろう。Embabbelはより高性能なモデルに追いつかれるのだろうか？企業はこのようなハーネス層を今後も必要とするのだろうか？将来のフレームワークは、開発者が選ぶものなのか、それともAIツールが自動的に決定するものなのか？これらの疑問はすべて、彼がインタビューで発した「これは、人類が自ら選択する最後の波となるフレームワークかもしれない」という言葉に集約される。
この言葉を別の誰かが口にすれば、AI時代における誇張された予測の一つに過ぎなかったかもしれない。しかし、Springの創業者の口から出ると、その重みは違う。ロッド・ジョンソンはフレームワーク時代の勃興を直接経験し、一つのフレームワークがどのようにして企業向けソフトウェア開発のインフラストラクチャへと成長するかを見てきた。今、彼は戦場に復帰したが、選択権は移り変わりつつあると感じている。開発者が消えることはないかもしれないが、開発者が自らフレームワークを選び、技術スタックを組み、システムの骨格を決定する時代は、終焉を迎えつつあるのだ。
本稿は当該ポッドキャスト動画に基づき、InfoQが編集したものである。
主なポイントは以下の通り：
TensorFlowでモデルのトレーニング、ファインチューニング、特定のデータ処理や取り込みをするなら、もちろんPythonを使う。しかし、GenAIのアプリケーション層への適用に関しては、アプリケーション本来の言語で行う方が適しており、アプリケーションがJavaで書かれているなら、Javaで行うべきだ。
複雑なアプリケーションに足を踏み入れると、アーキテクチャ上の監視を維持しなければ、すぐに手に負えない混乱状態に陥る。エージェントは喜んで新機能を追加するだろうが、新機能を追加するたびに設計は劣化し、コードは非常に質の悪いものになる。
開発者はコードを書くことに多くの時間を費やすべきではない。なぜなら、自分が独自に価値を付加できる部分に集中することで、より大きなレバレッジを得られるからだ。
すべての開発者は原則として、1、2年に一度は新しい言語を学ぶべきだ。なぜなら、それによって思考法が大きく変わるからだ。
これはすでに「人類が能動的に選択する最後の世代のフレームワーク」である可能性がある。今後、技術選定の多くは、我々のツールが我々に代わって行うようになるだろう。
1 Springの生みの親が第一線に復帰し起業
Simon： あなたの経歴を拝見しましたが、Springを開発する前は、19世紀のパリのピアノ音楽に関する博士号を取得されていたのですね。
Rod： ええ、最初の学位は音楽とコンピューターサイエンスのダブルメジャーで、当時はどちらに進むべきか全く決められませんでした。その後、オーストラリアの研究奨学金を得て音楽学の博士号を取得し、シドニー音楽院で2年間、音楽史を教えていました。しかし、コードを書きたいという衝動はずっと消えませんでした。90年代半ばにはシェアウェアを書いて、実際に小切手が送られてきたこともありました。
しかし、このまま音楽の学術界に留まれば、おそらく生涯シドニーで家を買えないだろうと、はっきりと気づきました。そこで、この二つのうち、一つは趣味、もう一つは職業にしようと決断しました。ただ、当時はそれを逆にしていたんです。その後10年近くは、仕事が忙しすぎてピアノに触れることはほとんどありませんでした。
Simon： では、それは奇妙な回り道などではなく、単にあなたが非常に創造的で、コードを書くことも音楽も、どちらも心から楽しんでいたということですね。
Rod： 80年代半ばに初めてコードを書いてから今に至るまで、プログラミングをやめたことはほとんどありません。なぜならそれが本当に好きだからです。たとえ今ではコードの大部分をAIコーディングエージェントが書いているとしても、私はそれと全く同じ興奮を覚えます。なぜなら、主導権は依然として自分にあり、創造し何かを形作っていることに変わりはないからです。たとえ一行一行を自分の手で書かなくなったとしても、結果が同じであれば、私にとっては同じように満足感が得られます。
Simon： SpringSourceが買収された後、あなたは長年、取締役や投資に携わっていましたが、その後Embabbelを立ち上げましたね。「今だ、このタイミングだ」と思った理由は何だったのでしょうか？
Rod： 業界が巨大な転換点に立っていると感じたからだと思います。GPT-3やその後のChatGPTが、突然、本当に実用的になり、同じことを繰り返したり、奇妙な袋小路に陥ったりしなくなった時、私はすぐに、このテクノロジーを実際に企業の問題解決にどう適用するかが、非常に難しい課題だと気づきました。実はその2年ほど前から、個人的な興味からTensorFlowのコードをかなり書いて、低レベルのAI技術に深く関わっていました。それが自然と、これらの問題を解決するためのフレームワークを作るというアイデアへと発展していったのです。
Simon： 企業といえば、今、多くのチームがJavaを捨てて、Pythonで全てを書き直すよう指示されています。あなたはこれを公に誤りだと述べ、「今年がPythonのAI分野における支配の最後の年だ」とさえ言いましたね。それはなぜですか？
Rod： ビジネス上の問題を解決するには、その問題自体の「隣接性」を考慮しなければなりません。あなたは何を扱っているのか？おそらくデータベース、エンタープライズサービス、既存のコードベースを扱っているでしょう。同時に、LLMという新しいものも扱っています。しかし、LLMはあなたのPythonプロセス内で実行されているわけではありません。宇宙が終わるまで、Pythonが自力で推論を実行することはできないでしょう。LLMは非常にシンプルなHTTPコールに過ぎません。ですから、ある言語が非常にシンプルなHTTPコールを発行する際に、本質的な優位性があると人々が考える理由が、私にはずっと理解できませんでした。
実際、人々はすでにこのことに徐々に気づき始めています。OpenClawはPythonで書かれていませんし、Peter Steinberger氏は彼の好む言語を使っています。多くのエンタープライズアプリケーションにとって、それらは明らかにJavaで書かれており、重要な隣接性は既存のビジネスロジックや既存のエンタープライズサービスにあります。そうであれば、明らかに正しいアプローチは、あなたのJavaスタックからシンプルなHTTPコールを発行することです。
人々がこのような混乱に陥る根本的な原因は、「データサイエンス」と「エンタープライズAIアプリケーション」を区別していないことにあると思います。これらは全く異なる二つのことです。私もEmbabel以前は大量にPythonを書いており、2年前はJavaよりもPythonの方が流暢でした。TensorFlowでモデルのトレーニング、ファインチューニング、特定のデータ処理や取り込みをするなら、もちろんPythonを使います。しかし、GenAIのアプリケーション層への適用に関しては、アプリケーション本来の言語で行う方が適しており、アプリケーションがJavaで書かれているなら、Javaで行うべきです。
Simon： EmbableはKotlinで書かれているんですよね？
Rod： Embabelのコアはほぼ全てKotlinで書かれています。しかし、私たちのサンプルの大半はJavaです。Javaユーザーにとって完全にシームレスであることを保証するために、多大な労力を費やしました。ご想像の通り、私たちのユーザーベースの大多数はJavaを使用しています。コンパニオンオブジェクトや`.kt`ファイルなど、奇妙なものは一切目にしません。非常にエレガントでスムーズなJavaのようです。ですから、コアフレームワークの作業をする時はKotlinを使い、サンプルアプリケーションの作業をする時はJavaを使います。正直なところ、JavaスタイルのAPIは非常に優れており、Kotlinでこのフレームワークを使う場合でも、他の言語とほとんど変わらない体験ができます。
Simon： しかも、それらの統合は元々非常にシームレスで、KotlinからJavaへ直接ジャンプできますね。
Rod： 約13年前、私はScalaを多用していました。言語としてはScalaが大好きでしたが、Javaとの統合が苦痛だったのは事実です。コレクションを扱うたびに苦しみました。一方、Kotlinの開発者はJavaとの相互運用性において素晴らしい仕事をしました。彼らはScalaが引き起こしたような問題、破壊的な変更やバイナリ互換性の欠如などを導入しませんでした。ですから、ええ、Kotlinは非常に使いやすい言語だと思います。
ただし、Javaが大幅に改善されたことを指摘することも重要だと思います。人々がJavaを藁人形のように攻撃するのはうんざりします。多くの人がJavaは進化していないふりをしていますが、実際にはJavaは大きく進化しています。
2 コーディングエージェントがあなたのコードベースを破壊する
Simon： 以前、AIが基本的に、既存システムにより深く統合されるのではなく、切断されたレイヤーとして無理やり押し込まれていると話していましたね。その結果、いくつかの失敗事例が生まれたと。真のエンタープライズAIの失敗事例とは、どのようなものだと考えますか？
Rod： 最大の問題は、上層部が「全てをAI化せよ」と指示を出す一方で、チームが実際のビジネスケースもなく、AIが適切かどうかの確認もせずに、盲目的にAIプロジェクトを立ち上げることにあります。主なアンチパターンは、「もっとAIを使わなければ」という考え方そのものであり、「なぜ使うのか？何のために使うのか？」を決して問わないことです。私はAIを深く愛し、魅了されていますが、LLMを使わずに済むことであれば、当然LLMを使うべきではありません。その方が安価で、確実性が高く、高速です。
ですから、組織が最初にすべきことは、「我々はここからどのようにしてあそこへ到達するか」を考えることです。例えば、オーストラリアのある顧客は、最初にウェブサイト上の特定のフォームに関する小さな問題点を特定しました。顧客が記入した後、先に進むには人間によるレビューが必要だったのです。95%のケースは実際には非常にシンプルで、正規表現で処理するには少し面倒でしたが、本質的にはシンプルでした。そこで彼らはこの摩擦点を取り除き、95%のシナリオにおいて、人間による処理を待つことなく顧客が即座に先に進めるようにしました。これは非常に素晴らしい初期事例だと思います。まずは小さなことで成果を上げ、徐々に信頼を築いていくのです。
また、「異質な技術スタック」問題については、二つの方向で悪影響を及ぼします。第一に、技術的に全てを困難にします。第二に、それはしばしば、戦略の主導権を誤った人々の手に委ねてしまいます。中核的なビジネスを全く理解しておらず、おそらく中核的なビジネスアプリケーションを見たこともない人々が戦略を主導しているのです。これらのアプリケーションをAIで強化しようとする時、このやり方は完全に行き詰まります。
昨年、オーストラリアの大企業のチーフAIアーキテクトと話をしました。彼はPython開発者でした。彼は私の話を丁寧に聞いてくれましたが、あまり興味はなさそうでした。通話の終わりに、彼は少しでも感じ良くあろうとしてこう言いました。「当社のどこかにJavaがあるのは確かです。戻って確認してみます。」私はその会社で働いたことは一度もありませんが、業界関係者として、その会社のコードの約70%がJavaで書かれており、残りは.NETで、しかも.NETからは段階的に移行中であることをよく知っていました。彼は入社からほぼ1年が経過していましたが、「ちなみに、当社のソフトウェアは何の言語で書かれているのですか？」と質問しようと考えたことすら一度もなかったのです。彼にとって、それは全く重要ではないように思えたのでしょう。
Simon： 今、開発者として、実際に書かれたコードの実装との間に大きな断絶が生じる現象がますます一般的になっています。AIへの過度な依存や権限委譲により、AIに多くの決定をさせ、あまりにも多くのことを外部委託しているためです。多くの知識は実際にはAI側にあり、私たちは抽象化されてしまっています。この問題はどれほど深刻だと考えますか？
Rod： 開発者が習得する必要がある中核的スキルの一つは、この新しい方法で作業しつつ、真に重要な制御権を保持することだと思います。Vibe Codingを使って、ある種のUIアプリケーションのような、本質的に使い捨てのものを行うことは確かに可能です。エージェントはそういったことが非常に得意です。しかし、Vibe Codingで本格的なソフトウェアを書くことはできません。
私はコーディングエージェントのヘビーユーザーで、自分で書くコードは多くても5%程度、おそらくそれ以下ですが、制御権はしっかりと握っています。設計の観点から見て、エージェントは間違っていることの方が多いと感じています。
それでも私たちは、アーキテクチャを理解し、何が起こっているかを把握し、過度に信頼しないようにする必要があります。複雑なアプリケーションに足を踏み入れると、アーキテクチャ上の監督を維持しなければ、すぐに手に負えない混乱状態に陥るからです。あなたのエージェントは喜んで新機能を追加するでしょうが、新機能を追加するたびに設計は劣化し、コードは非常に質の悪いものになります。
Simon： 5%のコードだけを書き、残りはAIが生成したとのことですが、それは意図的なのですか？もっと書きたくないからですか？それとも、書かれたものに対してより多くの制御権を持ちたいからですか？
Rod： オープンソースプロジェクトでは、自分で書く割合がもう少し高く、より保守的になるかもしれません。しかし、私たちの社内アプリケーションの一部では、AIが生成する割合が95%近くになります。そのコードを読めば、まるで私が書いたかのように感じるでしょう。設計スタイルは非常に明確です。私はそこに座ってdiffや出力を見て、「いや、ここをハードコーディングしている。これは戦略であるべきだ。抽出しよう」と頻繁に修正を加えます。
このパターンは、純粋な手作業や純粋なコーディングエージェントよりも優れた結果を生み出す可能性があると信じています。私はコーディングエージェントを使うことで、手動よりもはるかに速く、かつ高品質なコードを書けます。しかし逆に、全てを完全にコーディングエージェントに任せてしまったら、品質は大幅に低下し、最終的には速度も落ちると深く確信しています。
3 Embabelの中核：ゲームNPCのプランニングアルゴリズムから着想
Simon： Embabel内のコアコンポーネントである「プランナー」について話しましょう。これはGOAP（Goal-Oriented Action Planning）と呼ばれる経路探索アルゴリズムで、もともとはゲームのNPCのために設計されたものですね？重要なのは、これが決定論的であることです。一方、LangChainやCrew.aiといった他のフレームワークは、次に何をするか、どう計画するかをLLMに決定させることが多いです。なぜゲームNPCの領域からこのアルゴリズムを選んだのですか？
Rod： 私が最初に考えたのは、当然ながら最も明白な方法であるステートマシンでした。公平を期して言うと、LangGraphも決定論的で、事前にステートマシンを定義します。ですから、私も一時はその方法を使っていました。しかし少し立ち戻って、そもそもなぜプランニングを行うのかについてお話ししましょう。
もちろん、モデルに多数のツールを直接渡し、エージェントループに全てを処理させることもできます。特定のシナリオでは、これは合理的です。しかし、一貫性と予測可能性を必要とするビジネスプロセスの自動化においては、これでは全く不十分です。なぜなら、LLMがあなたの与えたツールをどのような順序で呼び出すのか、それらのツールにどのようなパラメータを渡すのかが全く分からないからです。
そこで私たちのアイデアは、ユーザーにプロセスを複数のステップに分割させることです。これらのステップは、一つまたは複数のLLMの呼び出しか、純粋なコードステップかもしれません。このレベルでは、LangGraph、Crew.ai、Microsoft Semantic Kernelなどが行っていることと似ています。大きな問題を小さなステップに分割するのです。これは、あるステップでLLMを使用する場合、異なるニーズに対して異なるモデルを使用できることも意味します。例えば、十分に小さく機密性の高いタスクには、自社のファイアウォールの背後でローカルLLMを使用することで、顧客データを決して企業の外部に出さないようにできます。これには多くの利点があります。
しかし問題は、これらのステップをどのように計画し、実行順序をどう決定するか、に戻ります。ステートマシンを使うこともできますが、私がLangGraphのようなものを扱っていた時、ステートマシンを修正したり、状態や遷移を追加したりするのは非常に面倒で、拡張するために再配線しなければならないことに気づきました。さらに、状態遷移と各アクション状態に必要な型は通常直交しており、これが型システム上で問題を引き起こします。
GOAPのプランニング方法には、二つの大きな違いがあります。第一に、それは動的であり、プランニングは実行時に行われます。第二に、型システムと完全に統合されています。我々はユーザーがカスタム条件を作成することを許可していますが、アクションの順序付けは通常、Javaメソッドのパラメータ型と戻り値の型によって決定されます。つまり、必要なパラメータが不足している状態でアクションが呼び出されることは決してありません。
GOAPの本質はA*アルゴリズムです。目標を特定し、現在の世界状態から目標に到達可能なステップを探します。目標には事前条件があり、世界状態において特定の条件が満たされていなければなりません。アクションにも事前条件と、それが約束する事後条件があります。事前条件は絶対的なもので、条件が満たされなければ目標達成を宣言したり、アクションを呼び出したりすることはできません。一方、事後条件はアクションが引き起こすと約束する副作用です。
プランナーは現在の世界状態から出発し、目標に至るパスを見つけ出します。「実行可能なパスは存在しない」と判断することもあり、これ自体が非常に価値のある情報です。そして最初のアクションを実行し、再度プランニングを行います。各アクションの実行後、世界状態を確認し、目標に到達する方法を再評価します。ほとんどの場合、ハッピーパスは計画通りに機能し、アクションが約束した事後条件が満たされ、プランナーがそれを確認し、次のステップへと進みます。
Simon： これは全て自動化されているのですか？
Rod： 完全に自動化されています。通常、Java開発者はプランナーの内部詳細を理解する必要はありません。入力を提供するための「アクションメソッド」を定義し、Javaメソッドにアノテーションを付けるだけで、メソッドのパラメータと戻り値の型がプランナーにチェーン呼び出しのための情報を提供します。場合によっては、カスタム条件を定義してワークフローをさらに制御することも可能です。これは、同じ目標に到達する複数のパスが存在し得ることを意味し、各アクションにコストを割り当てることができるため、プランナーは最も低コストのパスを選択できます。コストは動的にも設定でき、負荷の高いシステムを呼び出すアクションがあれば、それを動的なコスト値として反映させることができます。そうすれば、プランナーは自動的に別のルートを選ぶかもしれません。
Simon： 現在の世界状態に基づいて実行時に動的な意思決定を行うのは非常に興味深いですね。もう一つの利点は、決定論的であるがゆえに、「なぜこの決定を下したのか？」と問われた時に、非決定論的なプランナーでは提供できない診断情報を提供できる点ですね？
Rod： はい、計画の全パスと、どのように観測された世界状態がその計画の策定につながったかを完全に示すことができます。プランナーとEmbabel全体は、多数のイベントを発行します。これらの情報を永続化したり、監査ログに使用したりするためのリスナーを作成できます。したがって、なぜそれが特定のアクションを実行したのかを完全に説明でき、毎回同じ動作をすることを保証できます。
もちろん、アクションステップの内部に入り、LLMを呼び出した場合、その部分は完全な決定論的ではなくなります。しかし、これによりLLMを「適度に」呼び出すことが可能になります。チャットボットのように、3ページにも及ぶプロンプトと30個のツールで作業する場合、完全な予測可能性を得ることは決してできません。一方、小さなプロンプトと3つのツールで一つのことを達成しようとすれば、予測可能性は大幅に高まります。100%の確実性は不可能ですが、プロンプトエンジニアリングに費やす時間は大幅に減少することに気づくでしょう。全体として、システムははるかに説明可能で、確定的かつ予測可能なものになります。
4 なぜMCPに懐疑的なのか
Simon： 誰もがMCPを万能薬のように扱い、まるでそれがエージェントの全ての問題を解決できるかのように見なしています。この分野で、大多数の開発者がまだ見落としているギャップは何だと思いますか？
Rod： MCPはエコシステム全体を活性化する上で極めて重要な役割を果たしたと思います。ツールで何が実現できるかについて、より多くの人々に知ってもらうための触媒となったことは確かです。しかし、私はいくつかの理由からMCPに懐疑的です。
第一に、「AIでエンタープライズシステムを強化する」ということを行っているのであれば、なぜMCPを介して実行する必要があるのでしょうか？Embabel、Spring AI、LangChain4Jなど、どんなフレームワークでも、Javaメソッドを簡単にツールとして公開できます。それがそんなに簡単にできるなら、なぜわざわざ回り道をする必要があるのか、と問わねばなりません。特に、リポジトリ呼び出しを通じて正しいドメインオブジェクトを取得し、そのオブジェクト上のメソッドを公開できる場合、これはMCPではそれほど容易にできないことです。ですから、多くの場合、何らかのツールを公開する最初の考えは、「自分の技術スタックで直接公開できるか？」であるべきです。「なぜJavaメソッドやPython関数を直接公開しないのか？」と。それは完全に可能なのです。
第二に、MCPの売り文句は「エージェントのために特別に設計されたAPI仕様」です。しかし、それがAPI仕様であるならば、我々にはOpenAPI、Swagger、GraphQLが既にあります。なぜ新しい仕様が必要なのでしょうか？MCPの論拠は「エージェントのために特別に設計されているから」というものです。しかし私は最近、ある結論に達しつつあります。特定のエージェントにとって唯一完璧に適合するものは、多くの場合、おそらくそのエージェントに固有のものでしかないということです。例えば、MCPサーバーでサービスを公開することはできますが、既にOpenAPI仕様が存在するなら、その仕様に接続し、特定のエージェントループのニーズに合わせて独自のツールを形成することもできます。
MCPは業界の進歩を推進する上で多大な貢献をしたと思いますが、それは一回で決着がつくような解決策ではありません。多くのシナリオでは、既存のAPI仕様を直接使用する方が理にかなっています。そして常に第一に考えるべきは、現在の技術スタックからロジックを直接公開することです。
Simon： Karpathy氏がツイートしていたのを覚えています。「モデルは、モデルに基づいて構築されたプロダクトよりも先を走っている」というような内容でした。あなたがEmbabelで構築しているのはオーケストレーション層です。これは、あなたたちが実際にはモデルに既に遅れを取っていることを意味するのでしょうか？
Rod： それは興味深い質問です。確かに、我々が現在どのようにソフトウェアを構築しているかを見ると、コーディングエージェントのプランニング能力は、私が当初予想していたよりも著しく向上しています。昨年の11月末か12月頃、実際に非常に急激な跳躍がありました。モデルは確実に進歩していると思いますが、多くの根本的な問題は依然として存在しているとも考えています。ビジネスプロセスを自動化する場合、プランニングをモデルの制御外に置き、何らかの決定論的手法を用いることには、依然として価値があると思います。説明可能性も依然として重要です。ですから、モデルが進歩し続けても、モデル上のフレームワーク、エージェントハーネス、様々なフレームワークは非常に重要であり続けると私は考えています。
良い例はClaude Codeです。もちろん、Sonnet 4.6は以前のモデルよりはるかに高性能です。しかし、Claude Code自体もはるかに高性能になっています。今日のClaude Codeと4、5ヶ月前のClaude Codeを比べると、その動作方法は完全に異なっており、この違いが確かにそれをより効果的にしています。ですから、私はモデルが賢くなることと、ハーネスが賢くなることの間に、実際には衝突はないと考えています。我々は両方の面で同時に前進する必要があると思います。
確かに、いくつかのシナリオでは「モデルがハーネスを飲み込む」、つまり、確実性がそれほど重要でない場所では、モデルに多数のツールを与え、少々予測不可能でも構わないというケースが出てくるでしょう。ですから、モデルが必要とする周辺インフラが少なくて済む領域があるのは確かだと思います。しかし、その領域はエンタープライズアプリケーションとは特に関係が深くないと考えています。
5 AIは批評を得意とするが、独創性は得意ではない
Simon： 今年1月、あなたはClaude Codeのワークフローに多くの設計に関する対話が含まれていると述べましたね。Claude Codeと何度も議論し、長時間のプランニングを行い、それからコーディングを始める。その結果、手書きよりも優れたものができることが多い、と。しかし、Claudeはコンパニオンオブジェクトのような特定の事柄を理解していません。Claude Codeを使ってEmbabelを構築する際に、Claudeがあなたのアーキテクチャの一部を完全には理解していない時、それはどのような感覚ですか？
Rod： 私はアーキテクチャを完全に理解しており、頻繁に修正を加えているので、とてもうまく機能していると思います。開発者が「アーキテクチャを理解しない」という安易な道を選ぶようになったら何が起こるのか、非常に気になります。私は非常に有利な立場にいて、コードベースのアーキテクチャを完全に理解しており、Kotlinという言語を熟知し、Spring上に構築しているためSpringにも精通しています。実際に、技術スタックのあらゆる部分を非常によく理解しており、それが私が状況を効果的に掌握することを可能にしています。個人的には、これらを理解していない人々のことを非常に心配します。制御権を維持することは極めて重要です。私は、開発者はコードを書くことに多くの時間を費やすべきではないと考えています。なぜなら、自分が独自に価値を付加できる部分に集中することで、より大きなレバレッジを得られるからです。
Simon： AIは、あなたが思いもよらなかったような設計やアーキテクチャの提案をして、全く別の方向へと導くようなサプライズを見せたことはありますか？
Rod： あまり頻繁にはありません。しかし、一つだけ一貫して役立っているのは、その議論のキャッチボールです。私が考え及ばなかった点を指摘してきたことは確かに何度もあります。例えば、ある提案された変更について議論していた時、私が気づかなかった点を指摘してきました。これは独創的なアイデアを出すことよりも、批評することの方が得意です。
全体的には非常に満足していますが、フラストレーションを感じる時もあります。ここ数日、私は社内プロダクトのためにかなり複雑なテスト基盤を構築しようとしていました。テストコンテナ内で本物のLLMを使ってテストし、全てのツールを偽装するといったものです。Claude Codeのパフォーマンスは非常に悪かったです。その理由の一つは、おそらくこのシナリオを以前に見たことがなかったからだと思います。これはかなり新しいタイプのテストかもしれません。
あなたのコーディングエージェントに最大限の自律性を与えるには、テストに対して非常に執着する必要があります。私が今回遭遇したのは、エージェントが見たことのある中でもより極端なテスト量であり、かつ、ある種のテストはおそらくエージェントがこれまで見たことのないものでした。明確な指示を与えたにもかかわらず、エージェントは驚くほど苦戦しているようでした。
Simon： スキルやコンテキストを使ってエージェントを誘導し、よりあなたの求めるものに近い提案をさせようとしたことはありますか？
Rod： SkillsやClaude.mdを使ってコーディングエージェントの動作を設定しようと試みましたが、残念なことに、コンテキストが大きくなるにつれて、コーディングエージェントは物事を忘れ始めます。特に奇妙な現象が一つあります。コード本体に完全修飾名を書きたがるのです。私はこれが大嫌いで、importを使う方が好きです。この好みは既にclaude.md設定ファイルに書き込んであるのですが、それでも大体50%の確率で忘れてしまいます。
Simon： それがエージェントが必ず読まなければならない必須の指示であっても、エージェントは段階的に学習することができません。
Rod： ええ、注意力は減衰してしまうのです。
6 言語論争
Simon： 以前、TypeScriptは今日最も重要な言語であり、平均的なJavaScript開発者の能力を倍増させることができるとおっしゃっていたと記憶しています。TypeScriptがJavaよりも重要だと考える一方で、なぜJVM上での構築に固執し、かつTypeScriptが最も重要な言語だと信じることが両立できるのでしょうか？
Rod： TypeScriptは非常に賢い言語です。興味深いことに、かつての静的型付け言語と動的型付け言語の間の境界線は、今やある意味で収束しつつあります。現代のPythonは型ヒントを多用しており、Pythonの型システムもかなり優れたものになりました。TypeScriptは明らかにJavaScriptに型の層を追加したものです。
TypeScriptは美しい言語であり、確かに重要です。しかし、それでも「最も重要」と言えるかどうかは、アプリケーションのタイプによります。私が多くのタイプのアプリケーションをゼロから書くなら、サーバーサイドとReactの両方にTypeScriptを使う可能性が高いでしょう。しかし、エンタープライズアプリケーションを見てみると、Node.jsで書かれているものは多くありませんし、Node.jsで書くべきでもありません。JVM上で、JavaやKotlinは、このカテゴリのアプリケーションにとって非常に価値のある多くのものを提供します。TypeScriptがどんなに美しくても、この点では役に立ちません。
ですから、第一に、現代のJavaは、私が当時その発言をした時よりも確実に改善されています。第二に、Kotlinは真剣に検討する価値のある優れた言語です。KotlinとTypeScriptはおそらく互角でしょう。私は今でもユニオン型が恋しくなります。sealed hierarchyはユニオン型に決して及ばないと長々と論じることができますが、KotlinにもTypeScriptより優れている点が多くあります。TypeScriptのもう一つの問題は、実装が非常に優れているとはいえ、その基盤には依然としてクレイジーな層が存在し、時折それに遭遇してしまい、それを覆い隠すことができない点です。一方、Kotlinはより堅牢で予測可能な基盤の上に構築された、モダンな言語です。
Simon： AIの進歩は、今後5年でこうした言語の勢力図を変えると思いますか？こうした既成事実を覆すほどの十分な変化はあるでしょうか？
Rod： 私の見解が何かは分かりません。言語は重要ではないと自分を納得させることもできれば、言語は重要だと納得させることもできます。
まず、多くの人が想像しているような、トレーニング用コーパスが人気言語に自然な優位性を与え、その優位性が固定化されるという図式は、絶対に間違っています。私がコーディングエージェントで使っている三つの言語はJava、Kotlin、Pythonですが、疑いの余地なく、コーディングエージェントが最も得意としているのは、まさにKotlinなのです。これは全く予想外のことです。
考えてみてください。JavaとPythonは共に長い歴史があり、近年はいずれも急速に進化しています。2019年のJavaを書くべきではないし、もちろん2019年のPythonを書くべきでもありません。トレーニングデータが多すぎるために、「常に値型を使え」「常に拡張switch文を使え」「Pythonでは常に型ヒントを使え」と言っても、トレーニングデータの量が膨大すぎて、実際にはそれに逆らっていることになります。JavaやPythonが悪いと言っているわけではなく、今でも非常に優れています。
しかし、Kotlinの方が優れているのです。これは非常に驚きでした。なぜなら、Kotlinのコーパスは大きくないからです。理由の一つは、Kotlin自体があまり進化していないことです。なぜなら、最初からモダンな言語だったからです。もう一つの理由は、初期にKotlinを使っていたのは、おそらく非常にスキルの高い人々であり、JavaやPythonのように多くの質の低いKotlinコードが存在しないからです。
ですから、人気言語がトレーニングデータによって固定化されるとは思いません。LLMは、十分に見たことのあるものなら何でも非常に得意です。我々が聞いたことのある全てのプログラミング言語について、LLMは多くを見てきています。しかし、これは別の問題を提起します。もしそうなら、なぜ全てのことに完璧な言語を使わないのでしょうか？以前にも述べたように、私が絶対にPythonで書かないものもあれば、Javaで書くものもあります。LLMがあらゆる言語の達人であるなら、サービスごとに最適な言語を選べば良いではないか？このサービスにはRustを使い、あのサービスにはGoを使う。（ただし、今はGoで書く価値のあるものはもうないと思いますが。）
問題は、それはかつて目撃したマイクロサービスの熱狂と似ており、他にもコストがかかるということです。途方もなく巨大なメンテナンスコストを持ち込むことになります。私たちがマシンを完全に信頼する用意がない限り、そんなことをすべきではないと思いますし、それが良いアイデアだとは思いません。
Simon： スキルの問題もありますね。技術スタックの多様性と、人々がそれらをメンテナンスしなければならないというだけで、既に十分に頭痛の種です。それにセキュリティもあります。新しい言語や新しいライブラリを導入するたびに、脅威の対象領域は指数関数的に拡大し、そのリスクは言語を超えて伝播します。
Rod： 少なくとも現時点では、言語や技術スタックを選択する根本的な理由は、それほど大きくは変わらないでしょう。なぜなら、それらを本番環境に投入し、その責任を負うとなると、最も根本的な部分は変わっていないからです。
7 オープンソースの生存法則
Simon： 以前、オープンソースプロジェクトの背後にある企業は、初日からビジネスモデルを持つ必要があるとおっしゃっていましたが、それはEmbabbelにとってどのようなものになりますか？
Rod： 最も可能性の高いモデルはオープンコアです。オープンソースにおける純粋なサポートモデルは常に非常に困難で、コーディングエージェントの登場によってさらに難しくなるでしょう。ですから、フレームワークのレイヤーより一つ上のプロダクトが存在すると思います。我々の現在の考えでは、フレームワークを競争上の優位性として活用し、おそらくソフトウェア開発者ですらない、より広範な知識労働者向けのプロダクトを構築することです。フレームワーク自体は、Springと同様にApacheライセンスです。我々はコミュニティからの貢献を歓迎しており、活発なDiscord、GitHub、Issueトラッカーがあります。興味のある方ならどなたでも、貢献やコミュニティへの参加を歓迎します。
Simon： SpringはVMware、Pivotalを経て、現在のBroadcomに至るまでの買収を経験しました。何がSpringをこれらの買収から生き延びさせたのだと思いますか？多くのオープンソースプロジェクトは買収後に衰退したり、消滅したりします。
Rod： 2009年末に最初の買収が起こった時点で、Springは既に巨大で、事実上の標準となっていたと思います。初期の採用率と、その周りに構築されたコミュニティには、明らかに巨大な慣性がありました。
しかし、助けになったのは、非常にスキルの高い開発者が多数、Springの開発にフルタイムで雇われていたことです。これは、それほどエキサイティングではない事柄でも、誰かの仕事の一部であり、その人が興味を持つかどうかに関わらず、修正されることを意味しました。オープンソースは、背後にある商用サポートから確かに利益を得られるというのが、私の変わらぬ信念です。Springを信頼できるものにした鍵は、その堅牢性です。重大な問題は迅速に修正されます。これは、ボランティアに依存していないことの表れでもあります。コミュニティからの貢献はもちろん素晴らしいことですが、背後にあるこの種の専門性が、完全なプロダクトのような開発アプローチを提供し、非常に重要だったと考えています。
8 「これは人々が選択する最後の波となるフレームワークだ」
Simon： JVMで最も過小評価されているものは何だと思いますか？Pythonの世界が、自分たちが何を逃しているのか全く分かっていないものは？
Rod： パフォーマンスはもちろんその一つです。しかし、より真面目な答えとしては、その上で動作するコード、ビジネスロジックやドメインモデルは、主要なビジネスを理解する上で計り知れない価値があるということです。
Simon： AIエージェントに関して、何か「不人気な意見」はありますか？
Rod： 私はMCPに対して比較的懐疑的な見方をしています。MCPが悪いと言っているのではなく、今や誰もがMCPを「万能ハンマー」のように扱い、何でもかんでも釘に見えてしまっている状態だと思うのです。
Simon： もしJava開発者が上司から「AIにはPythonが必要だから、Pythonを学べ」と命じられたら、どんなアドバイスをしますか？
Rod： 私のブログを読むように勧めますね。まったく同じタスクでPythonとJavaの実装を比較する一連の記事を書きました。ファイル処理、APIコール、データパイプラインなどです。結果は非常に明白で、Javaコードはパフォーマンス、可読性、エコシステムの成熟度において、全くPythonに劣っていません。その記事の一つを直接上司に送りつけるか、もっといいのは、自分で実際に書いてみることです。多くの場合、Javaのコード競争力は決して悪くないことが分かります。
Simon： 既に本番環境で稼働しているプロジェクトであれば、LangGraphとEmbabelのどちらを選びますか？
Rod： Javaプロジェクトですか、それともPythonプロジェクトですか？Javaプロジェクトなら、間違いなくEmbabelを選びます。さもなければ、システムに「異質な技術スタック」を無理やり押し込むことになりますから。現在、Embabelはバージョン0.3.5で、APIの安定化まで非常に近いところに来ています。今から1.0までの間に大きな破壊的変更があるとしたら非常に驚きで、おそらくあと4週間から6週間程度で1.0に到達するでしょう。
ですから正直なところ、今Embabelを採用することは、それほど高リスクだとは思いません。むしろ、Javaプロジェクトがあるのに、全く異なる技術スタック一式を持ち込み、それを既存のJavaビジネスロジックと連携させなければならない状況の方が、はるかにリスクが高いと感じます。その面倒な作業を全部終える頃には、おそらくEmbabelは1.0になっていて、「なぜこんな面倒なことをしたんだ」と激しく後悔することになるでしょう。
Simon： 今日、まったく新しいエンタープライズプロジェクトを立ち上げるとしたら、KotlinとJavaのどちらを使いますか？
Rod： それはチームの規模によりますね。チームが20人未満なら、Kotlinを真剣に検討します。もっと大規模なチームで、メンバーがKotlinに不慣れなら、おそらくJavaを使い続けるでしょう。
Simon： 以前、Java開発者がScalaに移行する際の学習曲線はかなり急でしたが、今のJavaからKotlinへの移行は、まだそれほど難しいのでしょうか？
Rod： 正直なところ、よく分かりません。なぜなら、私がKotlinに触れた時には、既に多くの他の言語、特にPythonを書いていたからです。数ヶ月間Javaを書いていた時期もありましたが、またKotlinに戻りました。ですから、私は「純粋なJavaバックグラウンド」から移行したわけではありません。ただ、明確に言えるのは、Kotlinは間違いなくScalaよりも習得が容易だということです。Kotlin自体はかなり容易に習得できる言語です。
さらに、私が一貫して思っていることが二つあります。第一に、全ての開発者は原則として1、2年に一度は新しい言語を学ぶべきだと思います。本当に思考法が変わるからです。第二に、現在、新しい言語を学ぶ敷居はかつてないほど低くなっています。LLMを使えば、どんな言語でも非常に迅速に習得できます。ですから、全体のハードルは大幅に下がっています。例えば、私はKotlinのチュートリアル本を一度も読んだことがありません。
Simon： 先ほど、LLMにコードを批評させることは、時に「直接生成させる」よりも価値があるとおっしゃいましたね。私も同感で、特に新しい言語を学ぶ時には、LLMに「ここはなぜこう書くのか」「背後にあるメカニズムは何か」を説明させる方が、「コードを生成して」と頼むより効果的なことが多いです。さもなければ、生成された結果を見て「なぜこう書いたんだろう？」と推測するだけで終わってしまいますから。
Rod： 特に経験豊富な開発者にとっては、なおさらです。私も新しい言語を学ぶ時、よくLLMに「この言語に、○○と同等の機能はある？」と質問します。例えば、「Pythonに、TypeScriptの型ガードに相当するものはある？」といった具合です。もしあなたが既にそれらの概念を理解しているなら、LLMはそれらの概念を別の言語にマッピングするのが非常に得意です。
Simon： 毎日使っているお気に入りのAIツールは何ですか？Claude Code以外で。
Rod： おそらくClaude Desktopでしょう。競合調査のために一度に多数のツールを呼び出せるのが主な理由で、多くのことをこれで処理しています。
Simon： Springについて、「これは間違っていた」と後になって思うことはありますか？もしやり直せるなら、Embabelで別の方法を取りますか？
Rod： 非常に小さいですが、面白いと思う点が一つあります。当時、Springに「イベントベースのロギングメカニズム」を後付けで導入しようと長年試みていましたが、時期が遅すぎて、アーキテクチャ上変更が難しかったのです。しかしEmbabelでは、最初からそのように設計しました。これにより、全てのイベントは完全なものになります。SSH経由でストリーム配信したり、監視したり、購読したりできます。さらに面白いことに、あなたの「ロギングパーソナリティ」を変更することも可能で、例えば、全てのログをヨーダマスターの口調で出力させる、といったこともできます。
ある意味で、Embabelの全体的なスタイルは、モダンなSpringの経験に基づいて構築されており、それに加えてKotlinでより容易に実現できるいくつかの要素を加えたものです。例えば、ビルダーパターンはほとんど使いません。Kotlinなら、たとえ最終的にJavaユーザー向けであっても、よりエレガントに書けるからです。
Simon： もし5年後にEmbabelが存在しなくなるとしたら、何が原因だと思いますか？
Rod： 5年後にEmbabelがまだ存在するかどうかは、全く分かりません。5年後、人々はまだ手作業でアプリケーションを書いているのでしょうか？それとも、私のアドバイスに反して、マシンに全てを完全に任せてしまっているのでしょうか？私はこう言いたいと思います。これは、すでに「人類が能動的に選択する最後の世代のフレームワーク」である可能性がある、と。今後、ますます多くの技術選定は、我々のツールが我々に代わって行うようになるでしょう。しかし正直なところ、我々はほとんど唯一無二の時代に生きています。5年はおろか、1年、2年先の予測でさえ、間違っている可能性があります。
インタビュー動画の元リンク： https://www.youtube.com/watch?v=UcvxYltiS7E
免責事項： 本稿はInfoQが翻訳・整理したものであり、プラットフォームの見解を代表するものではありません。無断転載を禁じます。