Muleプロジェクトの面倒な作業をClaude Codeで楽に～ vol.1 初期セットアップ＆リファクタリング編

みなさんこんにちは、エンジニアの大濱です。

今回は、MuleSoftプロジェクトの初期セットアップにClaude Codeを活用することで、どれだけ手作業を減らして生産性を上げられるか、という話題をお届けします。

MuleSoftプロジェクト、最初の「面倒の壁」

MuleSoftでAPIを開発するとき、Anypoint StudioやCode Builderを使うと、RAMLの定義さえ用意すればインターフェースフロー（API Kitのルーターと各エンドポイントのフロー）を自動生成してくれます。GUIでコネクターをドラッグ＆ドロップしながらノーコード・ローコードで実装できるのは、MuleSoftならではの大きなメリットです。

ただし、自動生成直後のプロジェクトは「とりあえず動く」状態であり、実際の開発プロジェクトで求められるルールに合わせるためには、以下のような作業が必要になってきます。

インターフェースフローと実装フローの分離：API Kitが生成したルーターフローの中に実装ロジックが混在していると、後のメンテナンスが大変になります。実装は別ファイル・別フローに切り出すのが定番です。
設定値のプロパティファイル外出し：ホスト名やポート、認証情報などをフロー内にハードコードしたままでは、環境（開発・検証・本番）ごとに設定を変えることができません。プロパティファイルに外出しして、環境変数として切り替えられる構造にする必要があります。
グローバル要素の整理：HTTP Listenerの設定やコネクターの設定など、複数フローで共有するグローバル要素は専用ファイルにまとめるのが可読性・管理性の観点から望ましいです。
各プロセッサの表示名の整理：デフォルトのプロセッサ名のままだと、フロー図を見ても何をしているかわかりにくくなります。意味のある名前を付けることでチームでのレビューもしやすくなります。

これらは「やるべきことはわかっている」のに「地道で時間がかかる」作業の典型です。しかもプロジェクトによってルールが微妙に異なるため、毎回ゼロから手作業でやり直しになりがちでした。

「最初にルールを全部決めてからプロトタイピングを始める」というアプローチでは、ノーコード・ローコードの「すぐに動くものを作れる」というメリットが薄れてしまいます。

そこで、Claude Codeを使って自動化してしまいましょう。

かつてであればbash・sed・awk・grepなどを組み合わせた職人芸的なスクリプトが必要でしたが、Claude Codeなら自然言語で指示するだけで同等の作業をこなしてくれます。しかも、スクリプトの知識がなくてもできるのが大きなポイントです。

【デフォルトのMuleプロジェクト新規作成】

1. New > Mule ProjectでRAMLからプロジェクト生成（Studio）

今回はMuleSoftの初期トレーニングでも使われるExchangeアセット「Training: American Flights API」のREST API定義（RAML）を使います。

Anypoint Studioで「New > Mule Project」からExchangeのRAMLアセットをインポートすると、API Kitのインターフェースフローが自動展開されます。GET/POST/PUT/DELETEそれぞれのエンドポイントに対応したフローが生成され、デフォルトでサンプルデータを返す実装が組み込まれた状態になります。

--- Muleプロジェクト作成画面 ---

--- Exchange上の Training: American Flights API ---

--- 自動生成されたフロー ---

--- 作成直後のファイル構造 ---

この段階ではすべての実装ロジックがAPI Kitのルーターフロー直下にあり、設定値もフロー内にハードコードされているデフォルトの状態です。ここからClaude Codeで一気に整理していきます。

【プロトタイピング前の準備】

2. プロトタイピング前の準備作業を自動化（Claude Code）

作成したMuleプロジェクトのルートディレクトリを、Claude Codeが使用可能なVS Codeで開きます。

以下のプロンプトを一度Claude Codeに投げるだけで、前述の「面倒な準備作業」をまとめて自動処理させることができます。

Prompt 1：初期セットアップの一括自動化

1. API-Kit Routerから呼ばれる、get/post/put/deleteが先頭に付くフローの中身を
   個別の実装フローとして別ファイル implement.xml に移動し、
   それぞれ適切なフロー名を付与してください。

2. global要素の設定は全て global.xml に設定を移動し、
   何らかの値がセットされている項目は変数化して
   src/resources/config.yaml に外出しした上で、
   プロパティーファイルとしてインポートする設定を追加してください。

3. 既存・新規問わず、フロー名は英語で、
   各プロセッサのDisplayNameは役割の意味として理解できる日本語名に更新してください。

4. コーディング規約としてプロジェクトルート直下のファイル「coding-rules.md」の
   内容に従ってください。

このプロンプトで何が起きているか：

指示内容	対象ファイル	効果
実装フローの分離	implement.xml（新規作成）	インターフェースと実装の責務を分離
グローバル要素の集約	global.xml（新規作成）	設定の一元管理
プロパティの外出し	config.yaml（新規作成）	環境切り替えの準備
DisplayNameの日本語化	既存XMLファイル全般	フロー図の可読性向上
コーディング規約適用	coding-rules.md を参照	プロジェクト固有ルールの適用

--- VS Code / Claude Code 実行中画面 ---

--- VS Code / Claude Code 実行後結果画面 ---

Claude Codeは実行後にサマリーを出力してくれます。「どのファイルに何をしたか」が一覧で確認できるので、人間の目で最終チェックする際も効率よく確認できます。今回の処理により、１つだったフローの内容がflow-refプロセッサとsub-flowに分離され具体的な処理は実装フロー側でメンテナンスできるようになっています。

--- Prompt 1 実行後インターフェースフロー ---

--- Prompt 1 実行後implementフロー ---

--- Prompt 1 実行後ファイル構造・プロパティファイル ---

--- Prompt 1 実行後プロパティ使用箇所 ---

ポイント：AIへの指示は「何を・どう変えるか」を明確に プロンプトが曖昧だとClaude Codeの判断に幅が生まれ、実行ごとに結果がぶれやすくなります。「実装フローを別ファイルに移動する」「プロパティファイル名はconfig.yamlとする」のように、具体的なファイル名・構造まで指定するのがコツです。

この状態でAnypoint StudioからRunすると、正常に起動することが確認できます。

--- Studio Run実行コンソール画面 ---

【プロパティファイルのリファクタリング】

3. 環境別プロパティファイルの構造化

プロトタイピング段階であっても、「ローカルで動かす設定」と「開発環境にデプロイする設定」は分けておきたいケースが多くあります。接続先のホスト・ポート・認証情報は環境ごとに異なるためです。

前のステップで作成したconfig.yamlを環境別に分割する作業も、Claude Codeに任せます。

Prompt 2：環境別プロパティファイルへのリファクタリング

1. config.yaml の内容を環境別のファイルにコピーし、
   現在の値をStudio開発用(local)として
   ファイル名を config-local.yaml に変更してください。
   他は開発環境用(dev)、検証環境用(stg)、本番環境用(prd)を
   それぞれ config-{環境名}.yaml の形式で作成してください。

2. コーディング規約としてプロジェクトルート直下のファイル「coding-rules.md」の
   内容に従ってください。

--- VS Code / Claude Code 実行後結果画面 ---

--- Prompt 2 実行後プロパティファイル ---

--- Prompt 2 実行後プロパティ使用箇所 ---

このプロンプトでは指示していなかったにもかかわらず、実行環境の切り替え方法（Studioでの実行時引数の渡し方、CloudHub/RTFへのデプロイ時の環境変数設定方法）まで説明付きで返してくれました。MuleSoftに不慣れなメンバーにとっては、この説明が次のステップのヒントになります。

最終的なファイル構成のイメージは以下のようになります。

src/
├── main/
│   ├── mule/
│   │   ├── american-flights-api.xml   # API Kitルーター（インターフェース）
│   │   ├── implement.xml              # 実装フロー
│   │   └── global.xml                 # グローバル要素
│   └── resources/
│       ├── config-local.yaml          # ローカル（Studio実行）用
│       ├── config-dev.yaml            # 開発環境用
│       ├── config-stg.yaml            # 検証環境用
│       └── config-prd.yaml            # 本番環境用
coding-rules.md

【まとめ】

今回紹介した内容を振り返ると、Claude Codeに2回プロンプトを投げるだけで、以下の準備が完了しました。

✅ インターフェースフローと実装フローの分離
✅ グローバル要素の別ファイル化
✅ 設定値のプロパティファイル外出し
✅ 環境別（local/dev/stg/prd）プロパティファイルの作成
✅ プロセッサ表示名の日本語化
✅ コーディング規約の適用

実施タイミングによっては手作業だと30分〜1時間はかかる作業が、プロンプトを書いて確認する時間を含めても大幅に短縮できます。しかもXMLの書き換えミスや設定漏れといった人的ミスのリスクもほぼゼロになります。

プロンプト作成のコツを2つ再掲します：

具体的に指示する：「何をどう変えてほしいか」「ファイル名は何にするか」まで明示する
一度に詰め込みすぎない：大きすぎる変更を1プロンプトで指示すると再現性が下がる。ステップを分けることで確認もしやすくなる

Claude Codeで生成されたコードは必ず人間の目で確認しましょう。特に最初のうちは「このプロンプトでこの結果が毎回得られるか」を検証しながら、自分たちのプロジェクトに合ったプロンプトに育てていくプロセスが重要です。

かつてbashやsed, awkなどを使いこなすエンジニアだけが実現できていた「その場でのコードの自動変換・補正」が、今ではMuleSoft初心者でも自然言語で依頼できる時代になりました。ノーコード・ローコードツールのメリットを最大限に活かしながら、チームのルールに合わせた高品質なコードベースをスピーディーに整備できるのが、Claude Code活用の真価だと思います。

vol.2以降では、実装フェーズ・テストフェーズでのClaude Code活用として以下のようなテーマを候補に紹介予定です：