IBM BobのスラッシュコマンドでWebSphere Libertyのfeatureをレビューする

本記事の内容は 2026年1月28日時点の機能に基づいています。
今後、機能や仕様は変更される可能性があります。

IBM Bob には「スラッシュコマンド（Slash Command）」の機能があります。
Liberty でのアプリ開発でも多くの場面で活用できそうなので、今回はserver.xml の feature を最小構成にするレビューをスラッシュコマンド化して試してみました。

スラッシュコマンドとは？

スラッシュコマンドとは、チャット入力欄で / から始まるコマンドのことです。

例：/review、/mode code など

こちらを使用すると、よく行う作業（レビュー依頼、手順の定型化、チェックリスト実行など）を短いコマンド1つで呼び出せるようになります。

使い方

1. Bob のテキスト入力欄で / を入力
2. 使えるコマンド一覧がメニュー表示される
3. 文字を追加すると候補が表示され、絞り込める
4. コマンドを選ぶと入力欄に入るので、必要なら引数を付けて実行する

便利なところ

• 作業の自動化：複数ステップの依頼を「1コマンド」にまとめられる
  • 例：セキュリティ観点レビュー、テスト前チェック、リリース前確認…など
• チームで標準化：同じコマンドを使えば、やり方が揃う
  • 毎回同じ「前提・制約・観点」をコマンド側に埋め込める（= コンテキストを固定できる）
• 探しやすい：補完・検索で瞬時に見つけられる

スラッシュコマンドの作り方

スラッシュコマンドは、以下どちらかにMarkdownファイルを置くだけで作成できます。

• .bob/commands/
• ~/.bob/commands/

たとえば .bob/commands/review.md を作ると、/review として呼び出せます。
（ファイル名 = コマンド名です）

例：

• .bob/commands/review.md → /review
• .bob/commands/test-api.md → /test-api

今回作成したコマンド

今回は、以下のようなmdファイルを~/.bob/commands/liberty-feature-min.mdとして配置しました。

コマンド内では引数を定義することも可能です。
今回は任意でserver.xmlのパスを指定できるようにしています。
（指定しなくてもBobが自分で探してくれます）

---
description: server.xmlからLiberty featureを抽出し、最小構成へ削減案を提案する
argument-hint: "[任意] <server.xmlのパス>"
---

あなたは WebSphere Liberty のアーキテクト兼レビュアーです。目的は「現在の server.xml の feature を最小化（不要feature削除）しつつ、動作を壊さない」ことです。

# ゴール
1) server.xml から <featureManager> の feature 一覧を抽出（自動で）
2) アプリが実際に必要としているfeatureを推定し、不要候補を分類
3) 安全な削減手順（段階的）と、更新後の server.xml 例を提示
4) 検証方法（ログ確認ポイント、テスト観点）を示す

# 入力の扱い（引数なし前提）
- 引数 $1 が指定されていれば、それを server.xml のパスとして使用する。
- 指定がなければ、ワークスペースから server.xml を自動探索して読み取ること。
  - 候補例（優先順）:
    1) src/main/liberty/config/server.xml
    2) config/server.xml
    3) wlp/usr/servers/*/server.xml
    4) その他 server.xml
- server.xml が複数見つかった場合は「候補一覧」と「どれを対象にするべきかの質問」を最初に出す。
- もしファイル内容にアクセスできない環境なら、最初に私へ server.xml の貼り付けを依頼し、貼り付け後に同じ分析を続行する。

# 分析手順
## 1) 現状feature一覧の抽出
- <featureManager> 内の <feature> を列挙し、重複・コメント・プロファイル（例: webProfile など）も明示する。
- 出力は次の形式:
  - 現状のfeatures: [ ... ]
  - プロファイル/包含関係が疑われるもの: [ ... ]
  - バージョン/安定性に影響しそうなもの（例: beta等）: [ ... ]（該当があれば）

## 2) “必要/不要”推定（根拠つき）
次の情報源を使って「必要そう/怪しい/不明」を分類し、必ず根拠を添える：
- server.xml の他要素（例: <httpEndpoint>, <ssl>, <keyStore>, <dataSource>, <jmsConnectionFactory>, <webApplication>, <application> など）
- アプリ構成の手掛かり（参照できるなら）:
  - pom.xml / build.gradle の依存
  - ソースコードのアノテーションや設定（JAX-RS, JPA, CDI, Servlet, MicroProfile等）
  - META-INF/persistence.xml, web.xml, microprofile-config.properties など
- Libertyの起動ログ（参照できるなら）:
  - 利用されるfeatureやアプリの機能が示唆されるメッセージ

分類ラベル（推奨）：
- ✅ 必須（削るとほぼ確実に壊れる）
- 🟡 要確認（特定条件で必要）
- ❓ 不明（追加情報が必要）
- 🗑️ 不要候補（削減してよい可能性が高い）

## 3) 最小化の提案（段階的・安全に）
- いきなり大削減ではなく「段階1→段階2→段階3」のように安全に進める計画を作る。
- 各段階で:
  - 削るfeature候補
  - 期待効果（起動時間、メモリ、攻撃面、運用簡素化など）
  - 失敗した場合の戻し方
  - 検証手順（テスト/ログ観点）
を提示する。

## 4) 更新後server.xmlの例
- 可能なら、削減後の <featureManager> 部分の差分（Before/After）を提示する。
- “プロファイル（webProfile等）を使う案” と “明示feature列挙案” の両方を比較し、メリデメも書く。

## 5) 検証チェックリスト（必須）
- 起動ログで確認すること（エラー/警告、feature解決、アプリ起動完了）
- 代表ユースケースのスモークテスト観点
- 依存先（DB/JMS/LDAP等）がある場合の接続確認
- もしメトリクス/ヘルスを使っているなら、そのエンドポイント確認

# 出力フォーマット（この順番で）
1) 対象server.xml（パス/サーバー名）と、抽出したfeature一覧
2) 分類表（✅/🟡/❓/🗑️） ※理由を1行ずつ
3) 段階的削減プラン（段階ごと）
4) server.xml 修正案（Before/After）
5) 検証チェックリスト
6) 追加で必要な質問（あれば最小限）

注意:
- 根拠のない削除提案はしない。
- “不明” を残したまま断定しない。必要なら質問してから結論を更新する。

（補足）Liberty の feature とは？

ここで、記事の主役である Liberty の feature を簡単に整理します。

feature = Liberty の機能モジュール

Liberty では、構成ファイルで指定したフィーチャー（Feature）だけがロードされ、初期化されます。

そのため、必要最小限の構成にしやすく、以下のようなメリットがあります。

• 最小のメモリ／ディスク・フットプリント
• 高速起動（一般的な環境では 1〜数秒 で起動）

構成はコードで記述でき、server.xml の <featureManager> で 必要な機能だけを有効化 します。

• 例：Servlet を動かしたい → servlet-6.0
• JSP を使いたい → pages-3.1
• Basic認証などアプリのセキュリティ → appSecurity-5.0
• SSL/TLS を使う → ssl-1.0

また、jakartaee-10.0 や microProfile-7.0 などの feature を使用することで、必要な機能セットをまとめて有効化することも可能です。

ただし、その分個別 feature を厳密に絞り込む場合に比べて、有効化される機能の数が増えやすい傾向があります。

便利な反面、アプリが利用しない機能まで含まれることがある点には注意が必要です。

feature を最小化するメリット

最小化（不要featureの削除）には、おおよそ次の効果が期待できます。

• 起動が速くなる（初期化する機能が減る）
• メモリ消費が減る（ロードされるコンポーネントが減る）
• 設定が明確になる（このアプリが何に依存しているかが見える）

検証アプリの作成

今回はスラッシュコマンドを検証するために、Servlet と JSP を使用した簡単な電卓サンプルアプリケーションを Open Liberty で作成しました。
（このアプリも Bob で作成しています）

また、検証のために、server.xmlには jakartaee-10.0 などの feature をあえて入れ、さらに個別featureも追加して「冗長な構成」を作っています。

（例えば jakartaee-10.0 は webProfile-10.0 という feature を有効化し、その webProfile-10.0 の構成要素として websocket-2.1 が含まれるため、websocket-2.1 は重複した不要な記述です。）

    <!-- Enable features -->
    <featureManager>
        <feature>jakartaee-10.0</feature>
        <feature>microProfile-7.0</feature>
        <!-- 以下は検証用の追加feature（不要） -->
        <feature>websocket-2.1</feature>
        <feature>jsonb-3.0</feature>
        <feature>jsonp-2.1</feature>
        <feature>restfulWS-3.1</feature>
        <feature>cdi-4.0</feature>
        <feature>batch-2.1</feature>
        <feature>messaging-3.1</feature>
    </featureManager>

このアプリケーションを起動したときの2回目以降の起動時間は以下の通りでした。

• 4.416 秒
• 4.357 秒
• 4.388 秒

平均すると 約 4.4 秒 です。

featureを最小化した場合に、この起動時間がどう変化するかを今回は確認していきます。

Bob Shell を起動してスラッシュコマンドを実行

それでは、先ほど定義したスラッシュコマンドを使用して、このfeatureを最小化していきたいと思います。

スラッシュコマンドはIDE版でもCLI版でも利用可能ですが、今回はCLI版である Bob Shell を使用していきます。

プロジェクトのあるディレクトリで bob を実行します。

$ cd demo-app
$ bob

スラッシュコマンド /liberty-feature-min を入力しようとすると、候補に事前定義したコマンドが表示されました。

こちらのコマンドを実行すると、Bobがfeatureを最小化するためのプランを作成し始めました。

思考の結果、事前定義したフォーマットで今回の調査の結果を出力してくれました。

せっかくなので、今回の結果をmd ファイルとして出力してもらいます。

今回のコマンドで出力された内容

上記操作によって、今回出力されたレポートが以下の通りです。

（ちょっと長いですが、せっかくなので全文記載しています。）

1) 対象server.xmlとfeature一覧

対象ファイル: src/main/liberty/config/server.xml

現状のfeatures:

<feature>jakartaee-10.0</feature>          <!-- プロファイル（包含） -->
<feature>microProfile-7.0</feature>        <!-- プロファイル（包含） -->
<feature>websocket-2.1</feature>           <!-- 個別feature -->
<feature>jsonb-3.0</feature>               <!-- 個別feature -->
<feature>jsonp-2.1</feature>               <!-- 個別feature -->
<feature>restfulWS-3.1</feature>           <!-- 個別feature -->
<feature>cdi-4.0</feature>                 <!-- 個別feature -->
<feature>batch-2.1</feature>               <!-- 個別feature -->
<feature>messaging-3.1</feature>           <!-- 個別feature -->

プロファイル/包含関係:

• jakartaee-10.0: 以下を含む完全なJakarta EEプロファイル
  • servlet-6.0, pages-3.1, restfulWS-3.1, jsonb-3.0, jsonp-2.1, cdi-4.0, websocket-2.1, batch-2.1, messaging-3.> 1 など50以上のfeature
• microProfile-7.0: 以下を含むMicroProfileプロファイル
  • mpConfig-3.1, mpHealth-4.0, mpMetrics-5.1, mpOpenAPI-3.1, mpRestClient-3.0, mpFaultTolerance-4.1 など

重複の問題:

❌ jakartaee-10.0に既に含まれているfeatureを個別に再宣言している（完全に冗長）

---

2) Feature分類表（✅必須/🟡要確認/❓不明/🗑️不要候補）

Feature	分類	理由
jakartaee-10.0	🟡	プロファイル全体は過剰。アプリはServlet+JSP+JAX-RSのみ使用
microProfile-7.0	🗑️	不要: アプリでMicroProfile機能を一切使用していない（mpConfig, mpHealth等の痕跡なし）
websocket-2.1	🗑️	不要: jakartaee-10.0に含まれる＋アプリで未使用
jsonb-3.0	🗑️	不要: jakartaee-10.0に含まれる＋アプリで未使用（Servletは手動JSON処理なし）
jsonp-2.1	🗑️	不要: jakartaee-10.0に含まれる＋アプリで未使用
restfulWS-3.1	🗑️	不要: jakartaee-10.0に含まれる＋RestApplicationは空実装（実際のエンドポイントなし）
cdi-4.0	🗑️	不要: jakartaee-10.0に含まれる＋アプリで@Inject等のCDI使用なし
batch-2.1	🗑️	不要: jakartaee-10.0に含まれる＋アプリでバッチ処理なし
messaging-3.1	🗑️	不要: jakartaee-10.0に含まれる＋アプリでJMS使用なし

アプリが実際に必要とする機能:

✅ servlet-6.0 - CalculatorServlet (@WebServlet)
✅ pages-3.1 (JSP) - calculator.jsp, result.jsp
✅ ssl-1.0 - server.xmlで設定あり
✅ appSecurity-5.0 - 設定あり

---

3) 段階的削減プラン

【段階1】冗長な個別feature削除（最も安全）

削除対象: websocket-2.1, jsonb-3.0, jsonp-2.1, restfulWS-3.1, cdi-4.0, batch-2.1, messaging-3.1
理由: jakartaee-10.0に既に含まれているため完全に冗長

期待効果:

• 設定の明確化（重複排除）
• 起動時のfeature解決処理の軽減（微小）

リスク: ❌ なし（jakartaee-10.0が全てカバー）

検証手順:

1. 起動ログで CWWKF0012I: The server installed the following features: を確認
2. アプリが正常起動（CWWKZ0001I）
3. 電卓機能テスト（/calculator.jsp → 計算実行）

---

【段階2】MicroProfile完全削除（推奨）

削除対象: microProfile-7.0
理由: アプリでMicroProfile機能を一切使用していない

期待効果:

• 起動時間短縮（約10-15%）
• メモリ使用量削減（約50-100MB）
• 攻撃面の縮小（不要なエンドポイント削除）

リスク: ❌ なし（アプリで未使用）

検証手順:

1. 起動ログでMicroProfile関連のメッセージがないことを確認
2. /health, /metrics エンドポイントが404になることを確認（意図的）
3. アプリ機能に影響なし

---

【段階3】jakartaee-10.0を最小featureセットに置き換え（最大効果）

削除対象: jakartaee-10.0（プロファイル全体）
追加対象: 必要最小限の個別feature

期待効果:

• 起動時間短縮（約30-40%）
• メモリ使用量削減（約200-300MB）
• セキュリティ向上（不要機能の完全排除）
• 運用の明確化（使用機能が明示的）

リスク: 🟡 中程度（設定ミスで機能不全の可能性）

戻し方: server.xmlをバックアップから復元

検証手順:

1. 全ての起動ログを精査（CWWKF0001E等のエラーがないこと）
2. 電卓機能の完全テスト
3. エラーページ（404.jsp, 500.jsp）の表示確認
4. SSL接続テスト（https://localhost:9443）
5. Basic認証テスト（設定後）

---

4) server.xml修正案

【Before】現状（冗長）

<featureManager>
    <feature>jakartaee-10.0</feature>
    <feature>microProfile-7.0</feature>
    <feature>websocket-2.1</feature>
    <feature>jsonb-3.0</feature>
    <feature>jsonp-2.1</feature>
    <feature>restfulWS-3.1</feature>
    <feature>cdi-4.0</feature>
    <feature>batch-2.1</feature>
    <feature>messaging-3.1</feature>
</featureManager>

---

【After - 段階1+2】冗長削除＋MicroProfile削除（推奨）

<featureManager>
    <feature>jakartaee-10.0</feature>
    <!-- 個別featureは全てjakartaee-10.0に含まれるため削除 -->
    <!-- microProfile-7.0は未使用のため削除 -->
</featureManager>

メリット:

• ✅ 最も安全（jakartaee-10.0が全てカバー）
• ✅ 設定がシンプル
• ✅ 将来の機能追加に柔軟

デメリット:

• ❌ 不要なfeatureも多数含まれる（EJB, JPA, JMS等）
• ❌ 起動時間・メモリは最適化されない

---

【After - 段階3】最小featureセット（最適化）

<featureManager>
    <!-- Web層 -->
    <feature>servlet-6.0</feature>
    <feature>pages-3.1</feature>
    
    <!-- セキュリティ -->
    <feature>appSecurity-5.0</feature>
    <feature>ssl-1.0</feature>
    
    <!-- 管理・監視（オプション） -->
    <!-- <feature>mpHealth-4.0</feature> -->
    <!-- <feature>mpMetrics-5.1</feature> -->
</featureManager>

メリット:

• ✅ 最大のパフォーマンス向上
• ✅ 最小の攻撃面
• ✅ 使用機能が明示的

デメリット:

• ❌ 将来の機能追加時に手動でfeature追加が必要
• ❌ 設定ミスのリスク（テスト必須）

---

【比較表】

項目	現状	段階1+2	段階3
Feature数	9個（重複含む）	1個	4個
起動時間	基準	-10%	-35%
メモリ	基準	-50MB	-250MB
安全性	低（冗長）	高	最高
保守性	低（混乱）	高	中

---

5) 検証チェックリスト

✅ 起動ログ確認

# Libertyログの確認
tail -f target/liberty/wlp/usr/servers/defaultServer/logs/messages.log

確認ポイント:

• CWWKF0012I: The server installed the following features: でfeature一覧を確認
• CWWKZ0001I: Application demo-app started でアプリ起動成功
• CWWKF0001E や CWWKF0029E などのエラーがないこと
• CWWKS0008I でSSL設定が有効化されていること
• 警告（CWWKG0033W等）の内容を確認（致命的でなければOK）

---

✅ 機能テスト

1. 電卓機能（基本）

# ブラウザまたはcurlでテスト
curl -X POST http://localhost:9080/demo-app/calculate \
  -d "num1=10&num2=5&operator=add"

• 計算結果が正しく表示される
• 各演算子（add, subtract, multiply, divide）が動作
• ゼロ除算エラーが適切に処理される
• 入力検証エラーが適切に表示される

2. JSP表示

• http://localhost:9080/demo-app/ でcalculator.jspが表示
• CSSスタイルが適用されている
• 日本語が正しく表示される

3. エラーページ

• http://localhost:9080/demo-app/nonexistent → 404.jsp表示
• サーバーエラー時に500.jsp表示（意図的にエラーを発生させてテスト）

4. SSL/HTTPS

curl -k https://localhost:9443/demo-app/

• HTTPS接続が成功する
• 証明書警告が表示される（自己署名証明書のため正常）

5. Basic認証（設定後）

• 認証が必要なリソースで認証プロンプトが表示される
• 正しい認証情報で認証成功

---

✅ パフォーマンス確認

# 起動時間測定
time mvn liberty:run

# メモリ使用量確認（macOS）
ps aux | grep liberty | grep -v grep

• 起動時間が段階1+2で約10%短縮
• 起動時間が段階3で約35%短縮
• メモリ使用量が削減されている

---

✅ ログ監視（本番運用時）

# エラーログの監視
grep -i "error\|exception\|failed" messages.log

# 警告の監視
grep -i "warn" messages.log

---

6) 追加質問

🔍 現在の状況確認

1. このアプリは本番環境で稼働していますか？

   • はい → 段階1+2を推奨（安全性優先）
   • いいえ（開発/検証） → 段階3を推奨（最適化優先）

2. 将来的に以下の機能を追加する予定はありますか？

   • RESTful API（JAX-RS）の実装
   • データベース連携（JPA）
   • メッセージング（JMS）
   • バッチ処理
   • WebSocket
   • MicroProfile機能（Health, Metrics, Config等）

   → 「はい」の場合、該当featureは残すか、追加時に再度有効化

3. 監視・運用要件はありますか？

   • ヘルスチェックエンドポイント必要 → mpHealth-4.0を追加
   • メトリクス収集必要 → mpMetrics-5.1を追加
   • 設定の外部化必要 → mpConfig-3.1を追加

---

📋 推奨アクション（優先順位順）

🥇 最優先（今すぐ実施）

<!-- 段階1+2: 冗長削除＋MicroProfile削除 -->
<featureManager>
    <feature>jakartaee-10.0</feature>
</featureManager>

理由: リスクゼロで設定を整理、MicroProfile削除で即座にパフォーマンス向上

🥈 次のステップ（テスト環境で検証後）

<!-- 段階3: 最小featureセット -->
<featureManager>
    <feature>servlet-6.0</feature>
    <feature>pages-3.1</feature>
    <feature>appSecurity-5.0</feature>
    <feature>ssl-1.0</feature>
</featureManager>

理由: 最大の最適化効果、本番投入前に十分なテストが必要

🥉 将来の検討

• RestApplicationが空実装 → 削除を検討
• Basic認証が未設定 → 本番環境では必須設定
• 監視エンドポイント → 必要に応じてmpHealth/mpMetricsを追加

---

✅ まとめ

現状の問題点:

• jakartaee-10.0に含まれるfeatureを冗長に再宣言（7個）
• 未使用のmicroProfile-7.0を含む
• 不要なfeatureで起動時間・メモリを浪費

推奨される最終形態（段階1+2）:

<featureManager>
    <feature>jakartaee-10.0</feature>
</featureManager>

さらなる最適化（段階3）:

<featureManager>
    <feature>servlet-6.0</feature>
    <feature>pages-3.1</feature>
    <feature>appSecurity-5.0</feature>
    <feature>ssl-1.0</feature>
</featureManager>

期待効果（段階3）:

• 起動時間: 約35%短縮
• メモリ: 約250MB削減
• セキュリティ: 攻撃面の大幅縮小
• 保守性: 使用機能が明確化

---

📝 変更履歴

日付	変更内容	担当者
2026-01-28	初版作成 - Feature最小化レビュー実施	Bob (AI Assistant)

---

📚 参考資料

• Open Liberty Features
• Jakarta EE 10 Platform Specification
• MicroProfile 7.0 Specification

レビュー内容の反映（server.xmlの修正）

それでは、Bobが提案してくれた構成を実際のファイルに適用してもらいます。

修正後のfeatureがこちらです。

    <featureManager>
        <!-- Web層 -->
        <feature>servlet-6.0</feature>
        <feature>pages-3.1</feature>
        
        <!-- セキュリティ -->
        <feature>appSecurity-5.0</feature>
        <feature>ssl-1.0</feature>
    </featureManager>

修正が完了したら、アプリケーションを再度起動します。

URLにアクセスすると、アプリは問題なく動作していることが確認できました。

2回目以降のサーバー起動時間は以下の通りです。

• 1.401 秒
• 1.375 秒
• 1.452 秒

平均は 約 1.41 秒でした。
先ほどの平均 約 4.4 秒 と比較すると、起動時間を3倍以上高速化 できています。

まとめ

今回は IBM Bob のスラッシュコマンドを使って、Liberty の server.xml から feature を抽出・分類し、最小構成への削減案と検証手順を定型化 してみました。

ポイントは次のとおりです。

• スラッシュコマンドは よくある作業を1コマンド化 でき、レビューや手順の標準化に向いている
• Liberty の feature は 必要な機能だけを有効化 できる設計
• 不要featureを削ることで、起動時間・メモリ・攻撃面・運用の複雑さをまとめて改善できる
• 今回は jakartaee-10.0 + microProfile-7.0 から、Servlet/JSP/Security/SSL の最小構成へ落とし、平均約 4.4 秒 → 約1.4 秒 と大きく改善した

スラッシュコマンド化しておくと、同じ観点で何度でもレビューできるので、「検証環境で増えがちな feature の棚卸し」や「移行／モダナイ案件での構成整理」にも使えそうです。

Libertyでの開発におけるBobのスラッシュコマンドには他にもいろいろな応用例がありそうですね。