#quarkus

この記事を読んでまず思ったのは、AIエージェントに便利なツールを与える話なのに、熱量の中心が「何をできるようにするか」ではなく「どう壊れにくくするか」にあるのがいい、ということだった。こういう話はついデモ映えする自動化に寄りがちだけれど、ここでは Bean Validation で入力を縛り、stateless なサービスとして置き、Goose から MCP 経由で呼ばせる。派手さはないけれど、現場で使うならそっちが先だよな、と思った。 特に引っかかったのは、AI agent に enterprise API や database migration を直接やらせるのは「brittle and dangerous」とはっきり書いているところだ。これはかなり実感がある。エージェントが賢くなっても、つなぐ先が雑なら事故る。だから「便利なラッパーを作る」より、「呼べる操作の形を狭くする」ほうが大事になる。`@Pattern` や `@NotNull` で customer ID を縛る例は地味だけれど、こういう地味さが本当に効く場面は多いと思う。 一方で、この記事は Part 1 らしく、ま

MCPの7月28日仕様更新で、HTTPベースの使い方がしやすくなった一方、攻撃面も増えた 特に気をつけるべきなのは、headerとJSON-RPC本文が食い違う「protocol confusion」 `_meta` に入る自由なJSONは便利だが、雑に扱うと injection やログ汚染の入口になる LLMはだまされやすいので、AI側だけで守るのではなく、Javaアプリ側で境界線を引く必要がある この記事では Quarkus の strict validation や security layer を使って、入口で弾く考え方が示されている MCP、つまり Model Context Protocol は、AIエージェントが外部ツールや社内データにつながるための共通ルールとして注目されている。元記事は、その最新版に入った変更が「便利さ」と引き換えに新しい危険も持ち込んだ、とかなりはっきり警告している。ここが面白い。新機能の話なのに、テンションはかなり防御寄りだ。しかも大げさではなく、実装者が本当に気をつけないといけないタイプの話だと思う。 ポイントは、MCPが stateful な接