NanoBananaProで「説明コスト」を一気に下げた話
みなさん、こんにちは！
現役IT執行役員のグイグイです⚡️
先日、現場で「これはかなり実務で使えるな」と感じる出来事がありましたので、今回は久しぶりにAI活用に関する記事を投稿してみます。
NanoBananaProを使って実際に現場の実務で明確な価値を得られた事例です。
NanoBananaとはなに？に関しては多くの投稿者が記事を書いていますので、ここでは割愛してどんなシーンでどんなふうに使って役に立ったのか？を中心に書きたいと思います。
〜Java 21移行の“ややこしい仕様”を図解1枚で伝えた実例〜
テーマは Java 8 → Java 21 移行 に伴う、あの 「javax → jakarta 問題」 です。
古のJavaエンジニアならピンと来る人も多いと思いますが、非エンジニアの担当者に説明するとなると、かなりの難易度になります。
今回はこの「ややこしい話」を、
Googleの画像生成AI「NanoBananaPro」1枚で一気に解決した、という話です。
■ 背景：Java 21 への移行と jakarta 問題
現在、私の担当する現場では Java 8 から Java 21 へのアップグレードを検討しています。
Java 8 の延長サポートもそろそろ限界なので、これは避けて通れません。
ただ、このアップグレードには有名な問題がセットで付いてきます。
Java EE が Eclipse Foundation に移管されたことで、javax パッケージが jakarta に変更された問題
しかもこれ、
• Java全部が変わるわけではない
• Java EE 部分だけが対象
• Java SE の javax はそのまま残る
• でも業務アプリの import は大量に変わる
• 設定ファイルや XML も影響を受ける可能性がある
という、地味に理解コストの高い仕様変更です。
■ 課題：文章・口頭説明の限界
お客様の担当者にこの話を文章と口頭で説明してみたのですが、
• Java SE と Java EE の違いから説明が必要
• どこが変わって、どこが変わらないのかが直感的に伝わらない
• 結果、「たぶん分かりました」という一番危険な状態になる
正直、文章と言葉だけで正しく理解してもらうのは、無理ゲーでした。
■ 解決策：頭の中の構造を NanoBananaPro にそのまま描かせる
そこでやったのがこれです。
自分の頭の中にある知識と構造イメージを、そのまま NanoBananaPro に渡して、図にしてもらう
使ったのは、
Google の画像生成AI NanoBananaPro（Gemini 上から使える、🍌アイコンのやつ）。
伝えたい情報は、
• Java SE と Java EE の関係
• どこが jakarta になるのか
• アプリと JBoss のどこが影響範囲か
これらを 「説明用インフォグラフィック」 として描かせました。
この図を見せながら説明したところ、
「めちゃくちゃ分かりやすいです。理解できました！ありがとうございます 🙇♂️」
と、その場で即理解して頂けました。
説明時間も、理解の正確さも、明らかにレベルが変わりました。
そしてこの図解を渡しておけば、お客様も「あれ？なんだたっけ？」となった時に、長々とした文章を読まずとも、このインフォグラフィックを見れば一瞬で思い出せます。
説明する側、説明される側、双方にとって計り知れないメリットがあるんですよね。
■ 何が良かったのか？
本質はここです。
前提知識が揃っていない相手に、
言葉ではなく「知識構造」をそのまま渡せたこと
そしてもう一つ。
その「構造図」を作るコストが、GeminiとNanoBananaProによってほぼゼロ(実際は10分くらい)になったこと
本来こういう図って、
• PowerPoint を開いて
• 図形を並べて
• レイアウト調整して
• 文言を考えて…
で、余裕で数時間、なんならもっと溶けます。
それが、
整理した文章で渡すだけで、
数十秒で“要点が整理された図解”が返ってくる。
これは、説明する立場の人間にとっては完全にゲームチェンジャーです。
■ 実際に NanoBananaPro に渡した指示
今回 NanoBananaPro に渡した指示は、以下のような内容です。
（この指示自体も、Geminiと壁打ちしながら整理しました。）
以下の情報をインフォグラフィックにしてください。
==================================================
Java 8 → Java 21 に伴う「javax → jakarta 問題」の整理
==================================================
1. Java SE（JSE）と Java EE の違い
==================================================
【Java SE（Java Standard Edition）】
- Java の言語仕様・JVM・基本 API を定義する基盤
- 管理主体：Oracle（OpenJDK プロジェクトとして実装はオープン）
- JDK に含まれる
- Java 21 でもこの構造は変わっていない
主な内容：
- java.lang / java.util / java.time / java.nio など
- 暗号・SSL・管理系 API
例：
javax.crypto.*
javax.net.ssl.*
javax.management.*
※ 「javax」という名前でも、Java SE に属するものは Jakarta にはならない
【Java EE（Java Enterprise Edition）】
- Web / 業務アプリ向けのエンタープライズ API 群
- Java SE の上に乗る仕様（JSE には含まれない）
- 実装はアプリケーションサーバが提供する
主な仕様：
- Servlet
- JPA
- JAX-RS
- EJB
- CDI
- Bean Validation
- JMS など
※ アプリケーションサーバ（JBoss / TomEE / GlassFish 等）が実装を提供
==================================================
2. なぜ Java EE の javax が jakarta になったのか
==================================================
【背景】
- Java EE は元々 Oracle が管理していた
- 2017 年に Java EE 全体が Eclipse Foundation に寄贈された
- これにより Java EE は「Jakarta EE」に改称
【問題点】
- javax.* というパッケージ名の商標・管理権は Oracle が保持
- Eclipse Foundation は javax.* のまま仕様を進化させられなかった
【結果】
- Jakarta EE 9 にて、Java EE の全 API パッケージを
javax.* → jakarta.* に全面変更
- 技術的理由というより「法務・ガバナンス上の理由」が主因
- 後方互換性はなく、再コンパイル必須の破壊的変更
例：
javax.servlet → jakarta.servlet
javax.persistence → jakarta.persistence
javax.ws.rs → jakarta.ws.rs
javax.ejb → jakarta.ejb
==================================================
3. 自分たちのアプリで影響を受ける箇所
==================================================
【影響を受ける箇所（Jakarta 問題の直撃エリア）】
- 業務アプリが Java EE 仕様 API を直接参照している箇所
- import 文が javax.*（ただし Java EE 由来の場合）
典型例：
import javax.servlet.http.HttpServletRequest;
import javax.persistence.Entity;
import javax.transaction.Transactional;
import javax.ws.rs.GET;
import javax.validation.constraints.NotNull;
→ Jakarta EE ではすべて以下に書き換えが必要
import jakarta.servlet.http.HttpServletRequest;
import jakarta.persistence.Entity;
import jakarta.transaction.Transactional;
import jakarta.ws.rs.GET;
import jakarta.validation.constraints.NotNull;
【注意点】
- Java SE に属する javax.*（例：javax.crypto）は対象外
- 設定ファイル（web.xml / persistence.xml / XML Namespace）
- JSP / JSF / TLD / annotation / reflection 文字列
も影響対象になる場合がある
【実務での簡易判定ルール】
- import javax.xxx を見つけたら
→ 「Java EE 由来か？」を確認
→ Java EE 由来なら Jakarta 影響あり
==================================================
4. JBoss の中の「Java EE 部分」と「JBoss 固有部分」
==================================================
JBoss（WildFly）は、内部的に大きく以下の 2 つで構成される。
--------------------------------------------------
① Java EE（Jakarta EE）仕様に由来する実装
- Java EE / Jakarta EE の仕様 API を実装する部分
- Servlet / JPA / JAX-RS / CDI / EJB など
- 業務アプリが直接参照することが多い
特徴：
- Java EE 時代：javax.*
- Jakarta EE 時代：jakarta.*
- 今回の Jakarta 問題の対象はこの部分のみ
⇒ 業務システムで
「① を参照している箇所」は確実に影響あり
--------------------------------------------------
② JBoss（WildFly）固有の実装
- Java EE 仕様ではない、JBoss 独自の拡張・内部 API
- 管理・起動・ロギング・サブシステムなど
パッケージ例：
org.jboss.*
org.wildfly.*
特徴：
- javax / jakarta の影響は直接受けない
- ただし WildFly のメジャーアップグレードに伴う
非互換や設定変更の影響は別途あり得る
⇒ Jakarta 問題としては原則対象外
==================================================
5. 全体まとめ（判断軸）
==================================================
- Java SE（JSE）は今も Oracle が管理し、Jakarta にはなっていない
- Jakarta になったのは Java EE のみ
- Java EE の仕様 API は
javax.* → jakarta.* に全面変更された
- JBoss の中でも
① Java EE 仕様実装 → Jakarta 問題の対象
② JBoss 固有実装 → Jakarta 問題の直接対象外
- 業務アプリが
「① Java EE 仕様 API」を参照していれば Jakarta 影響あり
この観点でソース・依存・設定を洗い出すのが
Java 8 → Java 21 移行における Jakarta 問題対応の基本となる
--------◾️生成されたインフォグラフィック
1回目は英語で生成されてしまったので、「日本語にして」の指示で修正しました。
■ NanoBananaPro について
NanoBananaについて、ご存じない方のために簡単に説明しておきます。
NanoBananaPro は、
• Gemini 上から使える
• 🍌アイコンが目印
• 「構造理解 → 図解化」がかなり得意
というタイプの画像生成AIです。
Google AI Studioからも使えます。
Google AI Studioで使う場合はAPI KEYが必要です。
Geminiで生成した場合と、Google AI Studioで生成した場合の違いは、
・Gemini：ウォーターマーク（透かし）が入る
・Google AI Studio：ウォーターマーク（透かし）は入らない
これは、Google AI Studioが「開発やビジネス実務での素材利用」を前提としたツールだからですね。
用途に応じてどちらで生成するかを判断すると良いと思います。
今回の僕の事例はGeminiから生成しました。あくまでお客様への説明が目的で公式資料に乗せるわけではなかったので。
NanoBananaは、革命的な画像生成AIモデルなので、
仕事目的じゃなくても、遊び感覚で触ってみるのがおススメです。
私が現在連載中のAI漫画でもNanoBananaProを活用しています。
■ まとめ：NanoBananaProは「説明力」を拡張する道具
今回の件で改めて思ったのは、
NanoBananaProは「人に伝える力を拡張する道具」だということ。
• 難しい話を
• 誤解なく
• 速く
• 正確に伝える
そのための 「図」 を、
ほぼノーコストで作れるようになったインパクトはかなり大きいですね。
■ 今日から使えるアクション
次に、
• 「これ説明するのダルいな…」
• 「どう説明しても伝わらなそうだな…」
と思ったら、ぜひこうしてみてください。
そのまま NanoBananaPro に「この構造を図にして」と投げる。
たぶん、
仕事の“説明ストレス”が1段階減り、情報伝達の精度がグッと上がるはずです👍
その他の記事も興味のあるかたは以下のサイトマップからどうそ👇
いいなと思ったら応援しよう！
この記事が少しでも役に立ったと思ったら、サポートいただけると励みになります！