manage-global-configurations

グローバル設定の管理

概要

対話形式の複数ターンにわたるワークフローを通じて、Mule 4 プロジェクト内のすべてのグローバル設定を作成、表示、編集、削除、一覧表示、検証、統合します。

作成するもの： global-configs.xml 内の完全に設定されたグローバル要素、プロパティファイル、検証済みの pom.xml 依存関係。すべて MuleSoft のベストプラクティスに準拠します。

アーキテクチャ

flowchart TD
    Start{User Intent} -->|connector, config, connection| CC[Connector Config]
    Start -->|TLS, SSL, certificate| TLS[TLS Context]
    Start -->|object store, key-value| OS[Object Store]
    Start -->|caching, cache strategy| CS[Caching Strategy]
    Start -->|error handler, on-error| EH[Error Handler]
    Start -->|autodiscovery, API gateway| AD[API AutoDiscovery]
    Start -->|import project, shared library| IMP[Import]
    Start -->|properties, config.yaml, env| PROP[Properties]
    Start -->|global-property, inline| GP[Global Property]
    Start -->|list all, show all configs| LIST[List All]
    Start -->|find usages, where is used| FIND[Find Usages]
    Start -->|validate, dangling ref| VAL[Validate]
    Start -->|consolidate, centralize| CON[Consolidate]

    CC --> OP{Operation}
    TLS --> OP
    OS --> OP
    CS --> OP
    EH --> OP
    AD --> OP
    IMP --> OP
    PROP --> OP
    GP --> OP

    OP -->|Create| CREATE[Generate XML + config.yaml + pom.xml]
    OP -->|Get| GET[Scan & Display]
    OP -->|Edit| EDIT[Modify & Validate]
    OP -->|Delete| DELETE[Remove & Cleanup]

前提条件

開始する前に、以下を確認してください。

1. Mule 4 プロジェクトが、標準的な構成（src/main/mule/、src/main/resources/、pom.xml）でワークスペースにあること
2. Anypoint CLI v4 と DX Mule プラグイン（@mulesoft/anypoint-cli-dx-mule-plugin）がインストールされていること
3. ビルドの検証に利用できる Java 11 以降と Maven があること
4. dx mule describe-connector メタデータコマンドで利用できる Mule Runtime があること

実行パス

• コネクター設定の作成：ステップ 1、2、3、4、5、6、7、8、9、10、11

  • 条件：Salesforce、HTTP、DB など、新しいコネクター設定の追加をユーザーが求めた場合
  • 必要なもの：projectDir、connectorName

• グローバル要素の作成：ステップ 1、2、12

  • 条件：TLS Context、Object Store、Caching Strategy、Error Handler、AutoDiscovery、Import の追加をユーザーが求めた場合
  • 必要なもの：projectDir、elementType

• プロパティの管理：ステップ 1、2、13

  • 条件：プロパティファイルの作成・編集、環境の設定、または global-property 要素の管理をユーザーが求めた場合
  • 必要なもの：projectDir

• 管理操作：ステップ 1、2、14

  • 条件：すべての項目の一覧表示、使用箇所の検索、検証、またはグローバル要素の統合をユーザーが求めた場合
  • 必要なもの：projectDir

ステップ 1：ルールと参照資料

ルール：

• 複数ターンで対話します。 各「STOP」マーカーで、質問だけをプレーンテキストで出力して応答を終了し、回答を待ちます。そのフェーズのすべての質問に回答があるまで、ツールは使用しません。
• 事前提供された値の抽出（提供済みならスキップ）。 最初の STOP の前に、ユーザーの最初のリクエストを解析し、すでに提供されている値（コネクタ名、設定名、プロバイダー名、フィールド値、プレースホルダーの指定など）を抽出します。これらを「事前提供済み」として記録します。以降の各 STOP では、質問の答えが事前提供済みの値に含まれているか確認します。含まれている場合は、その値を使用して STOP を完全にスキップします。質問するのは、提供されていない情報だけです。ユーザーが「デフォルトのプレースホルダー」または「すべてのフィールドにプレースホルダーを使用」と言った場合は、それをステップ 8 の回答として扱い、その STOP をスキップします。曖昧さが残る場合（例：「basic provider」と言っていて、メタデータには「basic-connection」と「basic-auth」がある場合）は、引き続き質問します。
• MCP サーバーツールは使用しません。 すべての Exchange 検索とコネクタ操作には、bash スクリプトのみを使用する必要があります。search_asset、get_asset、MCP ベースのツールは絶対に呼び出さないでください。
• 生の XML をチャットに出力しないでください。 必ずファイルに書き込みます。
• TaskCreate は絶対に使用しないでください。
• 設定の構造はメタデータのみを参照します。 コネクタの属性、子要素、プロバイダー名をハードコードしないでください。describe-connector のメタデータを唯一の信頼できる情報源とします。
• コネクタのバージョンは Exchange の情報のみを使用します。 記憶からバージョンを記載してはいけません。使用できる唯一の情報源は get_latest_connector.sh → pick_connector.sh です。
• すべての設定を global-configs.xml に記述します。 順序と構造については references/global-config-conventions.md を参照してください。
• pom.xml の依存関係は必須です。 依存関係が必要なすべてのグローバル要素（コネクタ、Object Store、API AutoDiscovery、インポート）について、依存関係を pom.xml に追加する必要があります。pom.xml を読み込み、<dependencies> 内に <dependency> ブロックを追加して、ファイルを書き込みます。この手順を省略するとビルドは失敗します。絶対に省略しないでください。

スクリプト：

このスキルには、専用の scripts/ ディレクトリにシェルスクリプトが含まれています。「skill is now active」メッセージで案内された絶対パスを使い、Bash ツールで実行してください。相対パスは使用しないでください。

スクリプト	目的
get_latest_connector.sh <search> [nickname]	Exchange でコネクタ候補を検索します（1 行につき 1 つの GAV）
pick_connector.sh <nickname> <gav>	選択した GAV を下書きとして記録します
describe_connector.sh <nickname>	dx mule describe-connector を実行し、JSON を保存してダイジェストを出力します
build_gav.sh <json>	保存済みのコネクタ JSON を groupId:assetId:version に変換します

スクリプトのパス：<skill-root>/scripts/（<skill-root> は、この SKILL.md を含むディレクトリです）。

参照資料：

指示があったら、Read ツールでこれらのファイルを読み込んでください。「skill is now active」メッセージで案内された絶対パスを使用してください。

ファイル	内容	読み込むタイミング
references/global-elements-catalog.md	XML テンプレート、名前空間 URI、XSD URL、pom.xml の依存関係、属性テーブル、検証ルール、すべての要素タイプのコネクタ設定生成ルール。	XML を生成する前に必ず読み込み、構造、必須属性、名前空間、依存関係を確認します。
references/global-config-conventions.md	要素の順序、名前空間の管理、一元化ルール、デフォルトのプロジェクト構造、統合に関する判断マトリックス。	global-configs.xml に要素を配置するとき、名前空間を管理するとき、または統合を実行するとき。
references/properties-patterns.md	プロパティファイルの形式、${placeholder} の解決、複数環境のパターン、セキュアプロパティ、組み込みプロパティ、命名規則、検証ルール。	プロパティファイルの作成・編集、環境の設定、またはプレースホルダーの検証を行うとき。

Step 2: 対象プロジェクトと操作のルーティングを解決する

対象プロジェクトを解決する：

セッションごとに一度だけ実行し、この会話内の後続のすべての操作で結果を再利用してください。

ワークスペースに Mule プロジェクトが複数存在する場合は、AskUserQuestion を使ってユーザーに使用するプロジェクトを尋ね、STOP してください。この質問をほかの質問と組み合わせないでください。プロジェクトが1つだけの場合は、尋ねずにそれを使用してください。

操作のルーティング — レベル 1（ドメイン）：

キーワード	ドメイン
connector, config, connection, Salesforce, HTTP, DB, database, Slack, S3, ServiceNow, Jira, NetSuite, oauth, credentials	→ CONNECTOR CONFIG
TLS, SSL, trust store, key store, certificate, mTLS	→ TLS CONTEXT
object store, key-value store, persistent store, os:config	→ OBJECT STORE
caching, cache strategy, cache scope	→ CACHING STRATEGY
error handler, global error, default error handler, on-error	→ ERROR HANDLER
autodiscovery, API gateway, API ID, API Manager	→ API AUTODISCOVERY
import project, reference project, shared library, JAR import	→ IMPORT
properties, config.yaml, .properties, placeholder, environment, dev/QA/prod, multi-env, check placeholders, unresolved properties	→ PROPERTIES
global-property, inline property, name-value	→ GLOBAL PROPERTY
list all, what global elements, show all configs	→ LIST ALL
find usages, where is used, which flows reference	→ FIND USAGES
validate, check config exists, dangling reference	→ VALIDATE
consolidate, centralize, move to global-config	→ CONSOLIDATE

操作のルーティング — レベル 2（操作）：

意図	操作
作成／追加／セットアップ／設定（新規）	→ CREATE
取得／一覧表示／表示／確認	→ GET
編集／更新／変更／修正	→ EDIT
削除／除去／ドロップ	→ DELETE

不明な場合は、次のように尋ねてください：

何を行いますか？（create、view、edit、delete、validate、consolidate）

STOP。

Step 3: コネクタを解決する（CONNECTOR CONFIG — CREATE）

指定されていない場合は、使用するコネクタを尋ねてください。その後、Exchange を検索します：

bash scripts/get_latest_connector.sh salesforce sfdc

複数のバリエーションが返され、ユーザーが特定のコネクターアーティファクトを事前に指定していない場合は、AskUserQuestion を使ってユーザーに尋ね、STOP してください。一致する結果が1つだけの場合（またはコネクタがすでに pom.xml にある場合）は、尋ねずに続行してください。

次に選択します：

bash scripts/pick_connector.sh sfdc com.mulesoft.connectors:mule-salesforce-connector:11.1.0

コネクタがすでにプロジェクトの pom.xml にある場合は、そこから GAV を抽出してください。

Step 4: コネクタを説明する

bash scripts/describe_connector.sh sfdc

ダイジェストから configs[] と connectionProviders を読み取ります。

Step 5: 設定名を尋ねる

ユーザーが設定名を事前に指定している場合は、それを使用してこの STOP をスキップしてください。指定されていない場合は、次のように尋ねてください：

このコネクタ設定の名前を指定してください（例：salesforceConfig）

STOP（事前に指定されていない場合のみ）。

Step 6: 接続プロバイダーを選択する

ユーザーがメタデータ内のプロバイダーの1つに明確に一致するプロバイダー名を事前に指定している場合は、それを使用してこの STOP をスキップしてください。複数のプロバイダーが存在し、ユーザーが指定していない（または名前が曖昧な）場合は、ユーザーに尋ねてください。

STOP（質問する場合のみ）。

Step 7: プロバイダーの詳細を取得する

anypoint-cli-v4 dx mule describe-connector \
  --connector "$(bash scripts/build_gav.sh tmp/connector-choices/sfdc.json)" \
  --type connection-provider \
  --name basic-connection \
  --config-name sfdc-config \
  --output json > tmp/connector-metadata/sfdc-config.json

子要素 oauthCallbackConfig があるか確認します。

Step 8: フィールド値を尋ねる

ユーザーが明示的なフィールド値を事前に指定している場合、またはすべてのフィールドで「プレースホルダーを使用」／「デフォルトのプレースホルダーを使用」と指定している場合は、その指定に従ってこの STOP をスキップしてください。プレースホルダーを選択した場合は、各必須フィールドについて ${connectorNamespace.fieldName} を自動生成します。

それ以外の場合は、次のように尋ねてください：

必須フィールドの値を指定するか、${property} 参照を使う場合は「placeholders」を選択してください。

STOP（事前に指定されていない場合のみ）。

Step 9: XML を生成する

references/global-elements-catalog.md の「Connector Config Generation Rules」セクションを読みます。メタデータに基づいてパターン 1（属性）またはパターン 2（子要素）に従い、XML を生成します。

Step 10: config.yaml を生成する

ユーザーがプレースホルダーを選択したフィールドに限ります。${namespace.attributeName} パターンを使用してください。

ステップ 11：プロジェクトに適用して検証する

1. 設定を src/main/mule/global-configs.xml に書き込みます（ファイルがない場合は作成します。references/global-config-conventions.md を参照してください）。
2. 名前空間と schemaLocation を追加します。
3. src/main/resources/config.yaml を作成または更新します。
4. コネクタの依存関係を pom.xml に追加します（必須 — 省略しないでください）。
   • プロジェクトの pom.xml を読み込みます。
   • コネクタの <artifactId> が <dependencies> 内にすでに存在するか確認します。
   • 存在しない場合は、次の依存関係ブロックを <dependencies> 内に追加します。

     <dependency>
         <groupId>{groupId}</groupId>
         <artifactId>{artifactId}</artifactId>
         <version>{version}</version>
         <classifier>mule-plugin</classifier>
     </dependency>
     

   • groupId、artifactId、version は、pick_connector.sh が tmp/connector-choices/ に保存した GAV から取得します。
   • 依存関係を追加した pom.xml を書き込みます。
5. 検証します。

cd <project-dir> && mvn clean package -DskipTests

BUILD SUCCESS になるまで修正して再実行します。

GET / EDIT / DELETE（コネクタ設定）：

GET： src/main/mule/*.xml をスキャンして、接続プロバイダーの子要素を持つ <*:*-config> 要素を検索します。名前、タイプ、ファイル、プロバイダー、属性を表示します。

EDIT： GET → 対象を尋ねる → 現在の値を表示する → 変更内容を尋ねる → 停止 → 編集を適用する → 検証する。

DELETE： 特定する → すべての XML で config-ref="{name}" を検索する → 使用箇所を表示する → 確認する → 停止 → 要素を削除する → 名前空間を整理する → 検証する。

ステップ 12：グローバル要素を作成する（TLS、オブジェクトストア、キャッシュ、エラーハンドラー、AutoDiscovery、インポート）

以下のすべての要素タイプについて、XML を生成する前に references/global-elements-catalog.md を読み、標準の XML 構造、必須属性、検証ルールを確認してください。

TLS CONTEXT — CREATE

Q1： 名前は何ですか？トラストストアのみ／キーストアのみ／両方（相互 TLS）ですか？

停止。

Q2： ストアのパス、パスワード（プレースホルダーを使用）。任意：プロトコル、暗号スイート、失効チェック、ストアのタイプ／アルゴリズム。

停止。 → 実行：XML を global-configs.xml に書き込み、tls 名前空間を追加し、config.yaml を更新します。

OBJECT STORE — CREATE

Q1： 新しい os:config が必要ですか、それとも既存のものを使用しますか？名前は何ですか？

停止。

Q2： オブジェクトストア名、config-ref、永続化するか、maxEntries、entryTtl、TTL 単位。

停止。 → 実行：

1. XML を global-configs.xml に書き込みます（config を object-store より前に記述します）。
2. os 名前空間 xmlns:os="http://www.mulesoft.org/schema/mule/os" と、その schemaLocation エントリーを追加します。
3. mule-objectstore-connector の依存関係を pom.xml に追加します（必須 — 省略しないでください）。
   • pom.xml を読み込み、mule-objectstore-connector が <dependencies> 内にすでに存在するか確認します。
   • 存在しない場合は、次の依存関係ブロックを <dependencies> 内に追加します。

     <dependency>
         <groupId>org.mule.connectors</groupId>
         <artifactId>mule-objectstore-connector</artifactId>
         <version>1.2.5</version>
         <classifier>mule-plugin</classifier>
     </dependency>
     

   • 更新した pom.xml を書き込みます。
4. ビルドを検証します：cd <project-dir> && mvn clean package -DskipTests。

CACHING STRATEGY — CREATE

Q1： 名前は何ですか？使用するオブジェクトストアはどれですか（既存の参照またはインライン）？

停止。

Q2： キー生成式は何ですか？イベントのコピー戦略（simple／serializable）は何ですか？同期しますか？

停止。 → 実行：XML を書き込み、ee 名前空間を追加し、インラインの場合はオブジェクトストアの依存関係があることを確認します。

ERROR HANDLER — CREATE

Q1： 名前は何ですか？どのようなストラテジーを使用しますか？（on-error-continue／on-error-propagate）。各ストラテジーでどのエラータイプを対象にしますか？

停止。

Q2： 各ストラテジーで何を行いますか？（ログ記録、ペイロードの設定、ステータスコードの設定）。デフォルトとして設定しますか？

停止。 → 実行：XML を書き込みます。デフォルトの場合は <configuration defaultErrorHandler-ref="..."/> を追加します。<ee:transform> を使用する場合は ee 名前空間を追加します。

API 自動検出 — 作成

Q1： API ID は何ですか？どのフローを使用しますか？（プロジェクトのスキャン結果から利用可能なフローを表示します）。

停止。

Q2： 任意の設定（ignoreBasePath など）。

停止。 → 次を実行します。

1. global-configs.xml に XML を書き込みます。

   <api-gateway:autodiscovery apiId="${api.id}" flowRef="{flow-name}" doc:name="API AutoDiscovery" />
   

2. api-gateway 名前空間 xmlns:api-gateway="http://www.mulesoft.org/schema/mule/api-gateway" と、その schemaLocation エントリを追加します。
3. pom.xml に mule-api-gateway 依存関係を追加します（必須 — 省略しないでください）。
   • pom.xml を読み込み、<dependencies> に mule-api-gateway がすでに存在するか確認します。
   • 存在しない場合、<dependencies> 内に次の依存関係ブロックを追加します。

     <dependency>
         <groupId>org.mule.modules</groupId>
         <artifactId>mule-api-gateway</artifactId>
         <version>${app.runtime}</version>
         <classifier>mule-plugin</classifier>
         <scope>provided</scope>
     </dependency>
     

   • 更新した pom.xml を書き込みます。
4. config.yaml に api.id を追加します（必須 — 省略しないでください）。
   • src/main/resources/config.yaml を読み込みます。
   • 適切なセクションの下に api.id: "YOUR_API_ID"（またはユーザーが指定した値）を追加します。
   • 更新した config.yaml を書き込みます。
5. ビルドを検証します：cd <project-dir> && mvn clean package -DskipTests。

インポート — 作成

Q1： Maven の座標（groupId、artifactId、version）は何ですか？

停止。

Q2： どのリソースを使用しますか？<import> 宣言を追加しますか？

停止。 → 次を実行します：pom.xml に依存関係を追加し、global-configs.xml に <import file="{artifactId}.xml"/> を追加します。

GET / 編集 / 削除（すべての要素タイプ）

Connector Config と同じ共通パターンです。

GET： すべての Mule XML をスキャンし、該当する要素パターンを検索します。タイプ別にまとめて表示します。

編集： 一覧表示 → どれを編集するか質問 → 値を表示 → 変更内容を質問 → 停止 → 適用 → 検証。

削除： 特定 → 使用箇所を検索（references/global-elements-catalog.md に記載されたタイプ別の参照パターンを使用）→ 提示 → 確認 → 停止 → 削除 → 名前空間を整理 → 検証。

ステップ 13：プロパティの管理

プロパティに関する操作を行う前に、references/properties-patterns.md を読み込みます。

ファイルを作成

Q1： YAML 形式と Properties 形式のどちらですか？ファイル名は何ですか？

停止。

Q2： 初期のキーと値のペア（または「空」）は何ですか？<configuration-properties> として登録しますか？

停止。 → 次を実行します：src/main/resources/ にファイルを作成し、要求された場合は global-configs.xml に登録します。

ファイルを編集

Q1： 利用可能なファイルを一覧表示 → どのファイルを編集しますか？

停止。

Q2： 現在の内容を表示 → 何を追加、変更、削除しますか？

停止。 → 次を実行します：変更を適用し、削除したキーがまだ参照されている場合は警告します。

環境を設定

Q1： どの環境ですか？（dev、QA、prod など）デフォルト環境はどれですか？

停止。

Q2： 環境ごとに異なるプロパティは何ですか？共通プロパティはベースの config.yaml に置きますか？

停止。 → 次を実行します：環境ごとのファイルを作成し、<global-property name="env" value="{default}"/> を追加し、<configuration-properties file="${env}.yaml"/> を global-configs.xml に追加します。

登録／登録解除

登録： 未登録ファイルを一覧表示 → どのファイルを登録するか質問 → <configuration-properties file="..." doc:name="..."/> を追加します。

登録解除： 登録済みファイルを一覧表示 → どのファイルを登録解除するか質問 → 警告（「プレースホルダーを解決できなくなります」）→ 確認 → 停止 → 要素を削除します（ファイルは保持します）。

グローバルプロパティ — 作成／編集／削除

作成 Q1： どの名前と値のペアを設定しますか？

停止。 → 次を実行します：global-configs.xml に <global-property name="..." value="..." doc:name="..."/> を追加します。

編集： 一覧表示 → どれを編集するか質問 → 表示 → 新しい値を質問 → 停止 → 適用します。

削除： 一覧表示 → ${name} の使用箇所を検索 → 提示 → 確認 → 停止 → 削除します。

GET（プロパティ設定の表示）

登録済みファイル、未登録ファイル、グローバルプロパティを一覧表示します。キーの数と登録場所を表示します。

ステップ 14：管理操作（すべて一覧表示、使用箇所の検索、検証、統合）

LIST ALL

1. src/main/mule/ 配下にあるすべての Mule XML ファイルをスキャンします。
2. <mule> 内の最上位要素のうち、<flow> または <sub-flow> ではないものをすべて特定します。
3. 分類します：コネクター設定、設定プロパティ、グローバルプロパティ、グローバルエラーハンドラー、API AutoDiscovery、TLS コンテキスト、オブジェクトストア、キャッシュ戦略、インポート参照、アプリケーション設定、その他。
4. 名前付き要素ごとに使用箇所を数えます（config-ref、tlsContext、objectStore、cachingStrategy-ref、defaultErrorHandler-ref、errorHandler-ref、listenerConfig を検索）。
5. 名前、タイプ、ファイル、使用数を含むグループ化された表を提示します。
6. 問題を強調表示します：未解決のプレースホルダー、分散した設定（global-configs.xml にないもの）、未使用の要素（参照数 0）。

FIND USAGES

1. 対象要素を特定します（指定されていない場合はすべて列挙し、どれを対象にするか尋ねます）。
2. タイプごとのパターンを使って、すべての Mule XML ファイルから参照を検索します：
   • config-ref="{name}" — コネクターのオペレーション／ソース
   • listenerConfig="{name}" — OAuth コールバック設定
   • tlsContext="{name}" — HTTP 設定
   • objectStore="{name}" — キャッシュ戦略
   • cachingStrategy-ref="{name}" — <ee:cache> スコープ
   • defaultErrorHandler-ref="{name}" — <configuration>
   • errorHandler-ref="{name}" — 個別のフロー
3. ファイル、行、フロー／要素、属性、コンテキストの抜粋を提示します。

VALIDATE

フロー XML 内のすべての config-ref、tlsContext、objectStore、cachingStrategy-ref、defaultErrorHandler-ref、errorHandler-ref、listenerConfig 属性が、プロジェクト内に実在するグローバル要素を参照していることを確認します。

1. src/main/mule/ 配下のすべての Mule XML をスキャンし、参照属性（config-ref="X"、tlsContext="X"、objectStore="X"、cachingStrategy-ref="X"、defaultErrorHandler-ref="X"、errorHandler-ref="X"、listenerConfig="X"）を検索します。
2. 宣言されているすべてのグローバル要素名（name 属性を持つ最上位要素）を収集します。
3. 各参照について、参照先の名前が宣言済みの集合に含まれているか確認します。
4. 参照切れを報告します — プロジェクト内に存在しないグローバル要素を参照している属性です。ファイル、行、欠落している名前を含めます。
5. 修正方法を提案します：不足しているグローバル要素を作成するか、参照を既存の要素に修正します。

CONSOLIDATE

references/global-config-conventions.md の「Consolidation Decision Matrix」セクションを読みます。

1. global-configs.xml 以外のファイルにあるすべてのグローバル要素をスキャンします。
2. 判断マトリックスに従って、それぞれを移動可能またはフローに結合に分類します。
3. 移動するもの、残すものと、その理由を含むレポートを提示します。
4. 明示的な確認を待ちます → 停止します。
5. 実行します：要素の移動、名前空間宣言の追加、移動元からの削除、未使用の名前空間の整理。
6. ビルドを検証します：mvn clean package -DskipTests。
7. 移動した数、名前空間の整理、ビルド結果を報告します。

ヒントとベストプラクティス

• メタデータのみを基に構成を作成します。 コネクターの属性や子要素をハードコードしないでください。describe-connector メタデータを信頼できる情報源としてください。
• コネクターのバージョンは Exchange の情報のみを使用します。 記憶に頼ってバージョンを貼り付けないでください。get_latest_connector.sh → pick_connector.sh を使用してください。
• すべての構成を global-configs.xml に記述します。 並び順と構造については、references/global-config-conventions.md を参照してください。
• 複数ターンで対話します。 各判断の時点では、質問だけをプレーンテキストで表示して応答を終了し、先に進む前にユーザーの入力を待ってください。
• 指定済みの情報は尋ねずに進めます。 ユーザーの最初のリクエストに詳細（構成名、プロバイダー、プレースホルダーの設定、フィールド値）が含まれている場合は、該当する STOP ポイントを省略してください。未指定または曖昧な情報だけを尋ねてください。
• XML をチャットにそのまま出力しないでください — 必ずファイルに書き込んでください。
• MCP サーバーのツールは使用しないでください。 Exchange の検索とコネクターの操作には、提供された bash スクリプトのみを使用してください。
• 常に pom.xml を更新してください。 依存関係が必要なコネクター／モジュールは、すべて pom.xml に追加する必要があります。これがビルド失敗の最大の原因です。依存関係の XML パターンは references/global-elements-catalog.md に記載されています。pom.xml を読み込み → 依存関係を追加 → pom.xml を書き込みます。これを mvn clean package の実行前に行ってください。
• プレースホルダーを使用する場合は常に config.yaml を更新してください。 XML で ${property.name} プレースホルダーを使用する場合、対応するプロパティを src/main/resources/config.yaml に追加する必要があります。AutoDiscovery の場合は、常に api.id を config.yaml に追加してください。

トラブルシューティング

• 構成を追加した後にビルドが失敗する場合： 名前空間宣言がコネクターの XSD URL と一致しているか確認してください。schemaLocation URL が正しいことも確認してください。
• Exchange でコネクターが見つからない場合： Anypoint CLI が認証済みであることを確認してください。get_latest_connector.sh でより広い検索語を試してください。
• Describe-connector が失敗する場合： Java 11 以降が利用可能で、コネクターの GAV が有効であることを確認してください。保存された JSON が tmp/connector-choices/ にあるか確認してください。
• 実行時にプレースホルダーが解決されない場合： global-configs.xml に <configuration-properties> が登録されていること、およびプロパティファイルが src/main/resources/ に存在することを確認してください。
• 名前空間の競合がある場合： 統合処理を実行してすべてのグローバル要素を一元化し、重複する名前空間宣言を整理してください。

関連ジョブ

• build-mule-integration：このスキルで作成したグローバル構成を参照する Mule フローを構築します
• secure-mule-app：機密性の高い構成値に対するセキュアプロパティの暗号化を設定します
• create-project-template：構成を追加する前に、適切な構造の新しい Mule プロジェクトを生成します