生成AIを使った調査作業
初めに
業務でアプリケーションサーバのバージョンアップ作業を担当した際、既存のバージョンと新バージョンの間で設定項目がどの様に変わっているのか把握する必要がありました。手作業で全てをカバーするには時間がかかるため、Microsoft 365 Copilotを活用し、変更点を調査する方法を試してみました。
1.設定差分を調べるために作成したプロンプト
今回アプリケーションサーバをバージョンアップするために1番知りたい内容(変更されている可能性が高い点)は、「旧バージョンで使用されている設定項目は引き続き新バージョンでも使用できるか」でした。これを調査するため以下のプロンプトを作成しました。
プロンプトとは生成AIへの命令文です。
OpenJDK1.8→21、wildfly18から34にバージョンアップします
2つを比較して、非推奨になった項目、削除された項目、追加された項目などの差分を教えてください。
返答内容（M365 Copilot）(一部抜粋)
以下に OpenJDK 8 → 21 と WildFly 18 → 34 の
「非推奨になった設定項目」
「削除された設定項目」
を整理しました。
OpenJDK 8 → 21
非推奨になった設定・オプション
・SecurityManager関連設定
○java.security.manager システムプロパティはJDK 17で非推奨。将来削除予定
・Finalization機構
〇JEP 421で非推奨（JDK 18）
・Windows 32-bit x86ポート
〇JEP 449で非推奨（JDK 21）。ビルド時に--enable-deprecated-ports=yesが必要
・--illegal-accessオプション
〇JDK 9～16で利用可能だったが、JDK 17以降廃止
・console.encodingプロパティ
〇JDK 21で非推奨（stdout.encodingとstderr.encodingに置換）
削除された設定・オプション
・古いjavac -source/-target値
〇JEP 182により、JDK 9以降は「1.5以前」非対応。JDK 21では-source 6以前は完全削除
・CORBA/RMI-IIOP関連設定
〇JEP 320でJava EEモジュール削除（JDK 11）。RMI-IIOPはJDK 21で完全削除
・Applet/Java Web Start関連設定
〇JDK 11で削除済
・java.compilerシステムプロパティ
〇JDK 21で削除
・JAR Index機能
〇JDK 21で削除
WildFly 18 → 34
非推奨になった設定
・セキュリティ設定
〇Legacy Security Domains（PicketBox） → Elytron必須
・MicroProfile Metricsサブシステム
〇WildFly 34で非推奨（削除予定）
・javax.*名前空間
〇Jakarta EE移行に伴い非推奨（WildFly 27以降はjakarta.*必須）
削除された設定
・古いセキュリティRealm設定
〇security-domain要素は削除、Elytron構成に統合
・一部CLIコマンド・属性
〇管理モデル変更に伴い、default-migrationなど旧属性は削除
・Java EEサブシステム設定
〇eeサブシステムの一部要素がJakarta EE対応で変更
移行時の重要ポイント
・OpenJDK：
〇SecurityManagerやfinalize依存コードを削除。
〇--illegal-accessオプションは使えない。
〇javax.*APIはJakarta対応ライブラリに置換。
•WildFly：
〇standalone.xmlやdomain.xmlでsecurity-domain削除 → Elytron設定追加。
〇javax.*→jakarta.*へのコード変更必須。
〇MicroProfile Metrics利用部分は削除または代替（Micrometerなど）検討。
OpenJDK1.8→21、wildfly18から34にバージョンアップします Standalone.confの中で非推奨・削除がある設定項目を全て列挙してください。
返答内容（M365 Copilot）(一部抜粋)
以下は OpenJDK 8 → 21 と WildFly 18 → 34 のバージョンアップに伴い、
standalone.conf 内で 非推奨・削除対象となる設定項目を
すべて列挙したものです。
OpenJDK関連（JVMオプション）
standalone.conf の JAVA_OPTS に指定されるJVMオプションで、
JDK 8から21への移行で影響するものは以下です。
非推奨になったオプション
・-Xverify:none / -noverify
→ JDK 13で非推奨、将来削除予定
・--illegal-access=permit|warn|deny
→ JDK 9で導入、JDK 17で廃止
・-XX:+UseConcMarkSweepGC
→ JDK 9で非推奨、JDK 14で削除
・古いGCログオプション
〇-verbose:gc
〇-XX:+PrintGC
〇-XX:+PrintGCDetails
→ JDK 11以降は -Xlog:gc に統合
削除されたオプション
・CMS関連オプション（JDK 14で削除）
〇-XX:+UseParNewGC
〇-XX:+CMSIncrementalMode
〇-XX:+UseCMSInitiatingOccupancyOnly
・-Xincgc（インクリメンタルGC）
→ JDK 11で削除
・-XX:+PrintGCTimeStamps / -XX:+PrintGCDateStamps
→ JDK 11で削除（新ロギングに統合）
・非標準起動オプション（JDK 21で削除予定）
〇-verbosegc
〇-noclassgc
〇-verify
〇-verifyremote
〇-ss / -ms / -mx
→ これらは古い互換オプションで廃止
WildFly関連（standalone.conf設定）
standalone.conf は WildFly 起動スクリプトの設定ファイルで、
以下の項目が非推奨・削除対象です。
非推奨になった設定
・security-realm属性関連
→ Elytron移行に伴い非推奨（ログに WFLYCTL0028 警告）
・javax.*名前空間依存設定
→ Jakarta EE移行により非推奨（WildFly 27以降は jakarta.* 必須）
削除された設定
・PicketBox関連セキュリティ設定
→ 完全削除、Elytron必須
・MicroProfile Metricsサブシステム設定
→ WildFly 34で削除
・古い管理属性（例：default-migration）
→ 管理モデル変更に伴い削除 先ほどより欲しい情報を得ることが出来ました。
しかし、数の多い設定項目の中から指定したバージョン間で変更が生じているもの全てを抜き出すことは難しく、項目によっては具体的な項目名を入力して使用可否を確認する必要がありました。
2.近年の生成AIが抱える問題
実際に生成AIを利用してみて、手作業で調べるよりも精度や時間の面で効率化に繋がっており、活用する価値を十分に感じました。
一方で、生成AIにはいくつかの課題があることも知られています。代表的なものに「ハルシネ―ション(もっともらしいが誤った情報を生成してしまう現象)」があり、これはモデルが確立的に最適と判断した単語を並べて文章を作っていることに起因します。
実際、使用する中でもこうした課題を意識せざるを得ない場面がありましたが、ハルシネーションと同様に影響が大きいと感じたのは「出力の揺らぎ(一貫性の不足)」です。
同じ質問でも返答の細分が変化することがあり、前提条件の文言を固定して質問するなど、入力を安定させる工夫が必要でした。
3．なぜ生成AIの出力には揺らぎが生じるのか
生成AIを利用していて、同じ質問でも毎回少しずつ異なる回答が返ってくるのは、気まぐれではなく、モデルの内部構造に由来する仕組み上の特性です。
ここではその要因を整理します。
1. 次の単語を確率で選ぶ仕組みになっているため
生成AIは検索エンジンのように正しい答えを探しているわけではなく、内部で入力された文章に続く単語の候補を確率分布として持っており、その確率に基づいて最もありえそうな単語を1語ずつ選んで文章を生成します。
複数項目ある中から、どれを選ぶかは毎回わずかに揺らぎがあります。
この仕組みが、毎回の回答が微妙に変わる理由の土台になっています。
2. Temperature(温度)というランダム性を調整するパラメータ
生成AIには、確率分布の広がりを調整するTemperatureというパラメータが存在します。
Temperatureが高いとランダム性が強まり、多様な回答になり、Temperatureが低いと安定した回答にはなりますが、創造性が減ります。
この値をユーザーが意識する必要はありませんが、モデル内部では常にこの揺らぎの度合いが作用し、同じ質問でも言い回しが異なる現象が自然に発生します。
3. 訓練データの幅が広いため、回答が平均化される
生成AIは大量の文章を学習しているため、ひとつの質問に対して複数のあり得る正解が存在してしまう可能性があります。
複数の学習データの中間点のような回答を生成しようとするため、結果として方向性は同じでも、細部がばらけるという現象が起きます。
4．生成AIの出力の揺らぎ対策と時間短縮の両立するための工夫
生成AIの出力には一定の揺らぎが生じるとわかりましたが、プロンプトの書き方を以下のように工夫することで影響を抑えることが出来ます
・前提条件を毎回同じ形で提示する
・要求内容を箇条書きで明確にする
・回答形式を指定する
・一度に頼みすぎない
ただし、揺らぎを減らすために細かくプロンプトを書くと、今度は手間が増え、時間短縮に繋がりにくくなります。そのため、以下のような工夫を組み合わせることで、制度とスピードのバランスを取ることができます。
・よく使うプロンプトをテンプレート化する
・調査前にAIに任せる部分と、自分で判断する部分を切り分けてから作業を行う
生成AIの得意なこととして、調査したいことの概要を掴むことができる初動調査や、長文の文章を簡単に要約出来る力などがあります。そのため、調査の入り口として、生成AIを活用し、出力結果の事実確認などの最終判断を人間が下すという使い方が、最善だと感じました。
る。
5．まとめ
今回はアプリケーションサーバのバージョンアップをする際に、適応したい新しいバージョンと、現在使用しているバージョンを比較して変わった箇所を調べる目的で生成AIを使用しました。
今後ビジネスの場では生成AIの導入が更に加速すると予想されます。生成AIの特性を理解し、人間がコントロールしながら運用できるスキルを備えることがこれまで以上に求められ、生成AIを便利な道具として適切に活用出来るかどうかが、今後の仕事の質やスピードに大きく影響する時代になっていくと考えられます。
6.CNSについて
CNSではAIをビジネスに活用するコンサルティング、AIを活用したデータ分析・データ利活用などを支援しています。
AIの活用にご興味のある方は、お気軽にご相談下さい。
