AWS TransformのVS Code拡張機能でFuelPHPのシステムを移行前に解析してみた
はじめに
2026年4月、AWS TransformがVS Code拡張機能として利用可能になりました。
これまでAWS Transform customは atx CLIで操作するツールでしたが、VS Code拡張機能（AWS Transform - Visual Studio Marketplace）がリリースされたことで、VS Codeの中から直接ジョブを実行できるようになりました。
どんなものかさっそく試してみました。
あわせて、AWS Transform customの 包括的なコードベース分析変換 TD(Transform Definition)も試してみました。
コードベースを静的分析して、移行のための情報をドキュメント化する機能です。
この機能が気になる方もご覧ください。
この記事のまとめ
- AWS Transform VS Code拡張がリリース。実際の処理はClaude CodeなどのAIエージェントが
atxCLIを操作する形で動く - FuelPHPコードベースに包括的なコードベース解析を実行したところ、32ファイルのドキュメントが自動生成された
- 移行計画はフェーズごとにコード例付きで出力され、テストケースと検証基準まで自動生成 される
前提条件
VS Code拡張はコードの実際の変換・解析に AIエージェント を使用します。以下のいずれかが別途インストールされていて、VS Code上で利用できるようになってる必要があります。
- Claude Code ← 本記事での検証環境
- Amazon Q
- GitHub Copilot
- Cline
- OpenAI Codex
AWS Transform用のコマンド（ atx ）がインストールされており、AWS Transformが実行可能なAWSのクレデンシャルキーが必要です。コマンドインストールの詳細はこちらのブログをご覧ください。
VS Code拡張は atx を直接実行するのではなく、AIエージェントに向けたプロンプトを生成して渡します。エージェントが拡張に同梱されたSKILL.mdの手順に従ってatxコマンドを実行する、という構成になっています。
こんなイメージです。
GitHubリポジトリ
今回の解析対象はFuelPHP製のWikiアプリです。
以前のブログで atx CLIを使ったFuelPHPのLaravel移行をやりました。同じものを利用します。詳しくはこちらのブログをご覧ください。
VS Code拡張機能のインストール
拡張機能パネルから AWS Transform で検索して、拡張機能をインストールします。
最終的にVS Code上でAIエージェントがAWS認証情報を使って atx コマンドを利用することになります。
そのため、AWS認証情報を何らかの方法でVS Codeから参照可能にしておく必要があります。
私は、AWS一時認証情報を生成してターミナルの環境変数に格納した上で、Visual Studio CodeのCLIコマンドで起動し、ターミナルの環境変数を共有する方法をとりました。
AWS Transform拡張機能を使ってみる
AWS Transformアイコンのパネルをクリックして画面を開きます。
実行モード（Execution Mode）は Local を選択します。
Browser for Folders... をクリックして、移行を計画したい対象リポジトリを追加します。
今回はローカルにクローン済みの aws-transform-php-sample を選択しました。
追加したいコンテキスト（Additional Plan Context）には、以下の文言を追加しました。
Migrate an application from FuelPHP 1.8 / PHP 7.4 to Laravel 13 / PHP 8.4.
Send to は、 Claude Code を指定します。
入力が終わった後、 Send to Agent ボタンを押すと、Claude Codeの画面に移り、チャットに依頼事項が書かれました。
こうやってAIエージェントにやってもらうみたいです。
依頼事項をざっと見ると、VS Codeプラグインの中にAWS Transformのためのスキル定義ファイルがあって、それに従って atx コマンドを実行せよと書いてあるみたいです。参考に全文を載せておきます。
AIエージェントへの依頼全文
I want to run an AWS Transform custom transformation.
Repositories:
Direct paths:
- /Users/xxxx/github/aws-transform-php-sample
Additional plan context (user-provided):
```
Migrate an application from FuelPHP 1.8 / PHP 7.4 to Laravel 13 / PHP 8.4.
```
CRITICAL: Before doing anything, read the skill instructions at /Users/xxxx/.vscode/extensions/amazonwebservices.aws-transform-plugin-1.0.0/resources/atx-transform/SKILL.md. That file references detailed procedure documents in the same directory — you MUST read and follow them exactly. These files may be located outside of the current working directory — you must find a way to read them anyway. These reference files are your authoritative source of truth for every step of the process. Do not improvise or skip steps. The selected execution mode is Local (ATX CLI on my machine) -- ensure that this choice is respected.
During local execution, periodically list the artifacts directory at ~/.aws/atx/custom/<conversation-id>/artifacts/ and open any new files in the current editor window as they appear (do not launch a new IDE instance). Track which files you have already opened to avoid duplicates.
実行すると、Claude Codeがいろいろ移行のための調査をして、次の２つの選択肢を示しました。
- カスタムTDの作成をして移行を進める
- コードベース分析を実行して、移行の全体像を把握する
また、変換分析レポートも出しています。参考に全文載せておきます。
変換分析レポートの全容
変換分析レポート
リポジトリを分析しました:
リポジトリ情報
名前: aws-transform-php-sample
パス: /Users/xxxx/github/aws-transform-php-sample
フレームワーク: FuelPHP 1.8
PHP要件: PHP 5.4以上(composer.jsonより)
変換の目標
FuelPHP 1.8 / PHP 7.4 → Laravel 13 / PHP 8.4 への移行
利用可能な変換定義(TD)
現在AWS Transformで利用可能なTDを確認しましたが、PHPフレームワークの移行(FuelPHP → Laravel)に対応するTDは存在しません。
利用可能なTDは以下の通りです:
Java バージョンアップグレード、AWS SDK移行
Python バージョンアップグレード、boto2→boto3移行
Node.js バージョンアップグレード、AWS SDK移行
Angular、Vue.js バージョンアップグレード
コードベース分析、パフォーマンス最適化
推奨される対応
PHPフレームワークの移行は複雑な変換であり、カスタム変換定義(TD)の作成が必要です。以下の選択肢があります:
1. カスタムTDを作成する
新しいターミナルで以下のコマンドを実行し、インタラクティブセッションでTDを作成できます:
atx -t
このセッションでは、以下のような変換内容を記述します:
"FuelPHP 1.8 アプリケーションを Laravel 13 に移行する"
ルーティング、コントローラー、モデル、ビューの変換
設定ファイルの移行
依存関係の更新
PHP 8.4 互換性の確保
ATX CLIが変換定義の作成と公開をガイドします。公開後、このセッションに戻っていただければ、新しいTDを自動的に検出して変換を実行できます。
2. 包括的なコードベース分析を実行する
既存のTD AWS/comprehensive-codebase-analysis を使用して、まずコードベースの詳細な分析を行うこともできます。この分析により、移行に必要な作業の全体像を把握できます:
アーキテクチャの文書化
技術的負債の特定
FuelPHP固有のパターンと依存関係の抽出
どちらの選択肢を希望されますか?
カスタムTDの作成を進める
まずコードベース分析を実行して、移行の全体像を把握する
その他のアプローチを検討する
包括的なコードベース分析は、AWS Transform custom専用のTD（ AWS/comprehensive-codebase-analysis ）があるようです。
今回はこの、包括的なコードベース分析もあわせてやってみます。
包括的なコードベース分析とは
AWS Transform customの AWS/comprehensive-codebase-analysis 変換は、対象のコードベースを静的解析し、アーキテクチャ、技術的負債、コードメトリクス、リファレンスドキュメント、移行計画、ダイアグラムを含む構造化されたドキュメントを生成する、AWS Transform custom用のTDです。
- 参考：AWS Transform custom announces general availability of automated codebase analysis
- 参考：AWS Transform: Comprehensive Codebase Analysis for Modernization | Migration & Modernization
AWS Transformの包括的なコードベース分析をやってみる
Claude Codeにコードベースの分析を依頼すると、変換計画の確認を促されました。
変換計画の確認全容
変換計画の確認
変換定義(TD): AWS/comprehensive-codebase-analysis
リポジトリ: /Users/xxxx/github/aws-transform-php-sample
実行モード: ローカル(ATX CLI)
追加の計画コンテキスト: "FuelPHP 1.8 から Laravel 13 への移行のための分析。特にルーティング、コントローラー、モデル、ビューの構造と依存関係に焦点を当てる。"
この分析により、以下の情報が得られます:
プロジェクトのアーキテクチャと構造
FuelPHP固有のパターンと機能の使用状況
技術的負債と改善点
移行に必要な作業の詳細な洞察
この計画で実行してよろしいですか?
承認すると、Claude Codeが atx コマンドを実行して、定期的に成果物のチェックをしているような動きが確認できました。
次の画面のように、ちょくちょくClaude Codeからコマンド実行許可を求められます。
約40分くらい、許可を出しながら見守っていると実行が完了しました。
./ATXDocumentation に全体的なドキュメントを作成したと報告をもらいました。
次の章で作成されたドキュメントを見てみましょう。
参考に完了報告を全文載せておきます。
完了報告全容
✅ AWS Transform カスタム変換が正常に完了しました
FuelPHP 1.8 アプリケーションの包括的なコードベース分析が成功しました。
📊 実行サマリー
変換定義(TD): AWS/comprehensive-codebase-analysis
会話ID: 20260415_033739_b38847db
終了コード: 0 (成功)
生成ドキュメント数: 32個のMarkdownファイル
📁 生成されたドキュメント構造
ATXDocumentationは以下の2箇所に配置されています:
プロジェクトルート: /Users/xxxx/github/aws-transform-php-sample/ATXDocumentation/
ユーザーディレクトリ: ~/.aws/atx/custom/20260415_033739_b38847db/ATXDocumentation/
🎯 主要な分析結果
1. 技術的負債の重要な発見 (technical-debt-report.md)
高重要度の問題:
FuelPHP 1.8.2: EOL/放棄されたフレームワーク(2019年以降更新なし)
PHP 7.4: EOL(2022年11月28日にサポート終了)
PHP 5.4+互換性ターゲット: 非常に古いコードパターン
中重要度の問題:
monolog 1.x、phpseclib 2.x: EOLのライブラリ
Bootstrap 3.x: 古いUIフレームワーク
2. 移行計画 (migration/component-order.md)
推奨される移行戦略: グリーンフィールド書き直し(約321行のカスタムコード)
移行フェーズ:
Laravel 13プロジェクトのセットアップ(PHP 8.2+要件)
データベースレイヤーの移行(schema.sql → Laravelマイグレーション)
モデルレイヤー(Model_Page → Eloquent Page)
ルーティングレイヤー(FuelPHPルート → Laravel routes/web.php)
コントローラーレイヤー(Controller_Wiki → WikiController)
ビューレイヤー(PHPビュー → Bladeテンプレート)
Presenterレイヤー(Presenter → View Composer)
静的アセット(Bootstrap 3 → Bootstrap 5/Tailwind)
3. アーキテクチャ分析
パターン: MVC + Presenter(ViewModel)
データベース: MySQL 8.0、単一テーブル pages
ORM: FuelPHP ORM(Observer_CreatedAt、Observer_UpdatedAt使用)
ビューエンジン: PHPテンプレート(Bootstrap 3ベース)
📖 ドキュメントの主要セクション
Architecture: システム概要、コンポーネント、依存関係、パターン
Behavior: ビジネスロジック、ワークフロー、エラーハンドリング
Diagrams: 構造図、振る舞い図、アーキテクチャ図(テキストベース)
Migration: コンポーネント順序、テスト仕様、検証基準
Technical Debt: サマリー、古いコンポーネント、修復計画
Reference: APIリファレンス、データモデル、プログラム構造
Analysis: コードメトリクス、複雑性分析、セキュリティパターン
Specialized: データベースパターン、UIコンポーネント
🚀 次のステップ
このドキュメントを使用して:
Laravel 13への移行計画を詳細化
チームメンバーとの共有と議論
移行作業の優先順位付け
技術的負債の段階的な解消
すべてのドキュメントは ATXDocumentation/README.md からナビゲートできます。
生成されたドキュメントを見てみる
分析によって生成されたドキュメントは32ファイルに及びます。
すべて 英語 で出力されます。
.
├── README.md # 目次・クイックスタート
├── project-overview.md # 技術スタック・依存関係
├── technical-debt-report.md # ⚠ 技術的負債レポート（重要）
│
├── architecture/ # システムアーキテクチャ・依存関係
├── behavior/ # ★ Early Access — ビジネスロジック・フロー
├── diagrams/ # コンポーネント図・シーケンス図・アーキテクチャ図
├── technical-debt/ # EOL分析・改善計画
├── migration/ # FuelPHP → Laravel 13 移行順序・テスト
├── reference/ # API・データモデル・インターフェース
├── analysis/ # コードメトリクス・複雑度・セキュリティ
└── specialized/ # DBパターン・UIコンポーネント
作成したドキュメントはGitHubで公開しているので、詳細はこちらをご覧ください。
英語読むのツラいので Kiro CLI （AWSのAIエージェント）に日本語化してもらったバージョンも作りました。
いくつか中身を紹介します。
リクエストフローが図として出てくる
diagrams/architecture/system-context.md にはリクエストフロー図が含まれており、FuelPHPのリクエストライフサイクルを視覚化しています。
┌──────┐ ┌─────────────────────────────────────────────────────────────┐
│ │ │ FuelPHP Application │
│ │ │ │
│ B │ │ ┌──────────┐ ┌───────────┐ ┌─────────┐ │
│ r │──→ │ │ index. │──→ │ bootstrap │──→ │ Fuel │ │
│ o │ │ │ php │ │ .php │ │ ::init │ │
│ w │ │ └──────────┘ └───────────┘ └────┬────┘ │
│ s │ │ │ │
│ e │ │ ┌────▼────┐ │
│ r │ │ │ Router │ │
│ │ │ └────┬────┘ │
│ │ │ _root_ → wiki/index │ │
│ │ │ convention → wiki/* │ │
│ │ │ ┌────▼──────────────┐ │
│ │ │ │ Controller_Wiki │ │
│ │ │ │ action_*() │ │
│ │ │ └───┬──────────┬───┘ │
│ │ │ │ │ │
│ │ │ ┌────────▼──┐ ┌───▼──────┐ │
│ │ │ │ Model_Page│ │Presenter │ │
│ │ │ │ (ORM) │ │→ View │ │
│ │ │ └─────┬─────┘ └──────────┘ │
│ │ │ │ │
│ │←── │ ┌─────▼─────┐ │
│ │ │ │ MySQL │ │
│ │ │ │ (PDO) │ │
└──────┘ │ └───────────┘ │
└─────────────────────────────────────────────────────────────┘
明示的なルーティング規則（_root_ → wiki/index）や、規約的なルーティング規則（convention → wiki/*）や、PresenterがViewに渡る流れが図示されています。
ざっくり全体像を掴むのに役立ちそうです。
DBクエリからUI画面構成まで出てくる
specialized/ フォルダにはDBパターンとUIコンポーネントの専用ドキュメントが入っています。
specialized/database-patterns.md では、アプリが実行するSQLクエリが操作ごとに ソースファイルの行番号付き でまとめられており、FuelPHPのORMコード・生成されるSQL・Laravel相当のコードが対応づけられています。たとえばページ作成（INSERT）はこのように出力されていました。
ページ INSERT（Create）
ソース: controller/wiki.php, lines 44-48
// FuelPHP
$page = Model_Page::forge(array(
'title' => $title,
'content' => $content,
));
$page->save();
-- 生成されるSQL
INSERT INTO `pages` (`title`, `content`, `created_at`, `updated_at`)
VALUES (?, ?, ?, ?)
// Laravel 相当
Page::create($request->validated());
SELECT, UPDATE, DELETEについても同様の形式で出力されています。
specialized/ui-components.md にはASCIIアートのワイヤーフレームまで生成されていました。
┌──────────────────────────────────────────────────────┐
│ [+ 新しいページを作成] (btn-add) │
│ │
│ ┌──────────────────────────────────────────────────┐│
│ │ ページ一覧 N ページ ││
│ ├──────────────────────────────────────────────────┤│
│ │ 📄 Page Title [編集] [削除] ││
│ │ 更新: 2024/01/15 14:30 ││
│ └──────────────────────────────────────────────────┘│
└──────────────────────────────────────────────────────┘
JavaScript実装についても「削除確認用のネイティブ confirm() ダイアログのみ。AJAXなし」と一言で整理されており、移行時に考慮すべき範囲が把握できます。
移行計画はフェーズごとにコード例まで出てくる
migration/component-order.md には8フェーズの移行計画が自動生成されていました。
| フェーズ | 内容 |
|---|---|
| 1 | Laravel 13プロジェクトセットアップ・Docker構成 |
| 2 | DBマイグレーション・.env設定 |
| 3 | EloquentPageモデル |
| 4 | ルート定義 |
| 5 | WikiController・Form Request |
| 6 | Bladeテンプレート（レイアウト+4ビュー） |
| 7 | 設定クリーンアップ |
| 8 | フロントエンドアセット（Bootstrap 5・Vite） |
各フェーズに対応表やコード例が含まれています。
DBマイグレーション（フェーズ2）
フェーズ2のDBマイグレーションはこのように出力されていました。元のスキーマとの対応がコメントで書かれています。
Schema::create('pages', function (Blueprint $table) {
$table->id(); // ← id INT AUTO_INCREMENT PK
$table->string('title', 255); // ← title VARCHAR(255) NOT NULL
$table->text('content')->nullable(); // ← content TEXT (nullable)
$table->timestamps(); // ← created_at, updated_at (TIMESTAMP)
});
ルーティング（フェーズ4）
FuelPHPはメソッド名の規約でURLが暗黙的に決まるフレームワークです（例：action_index() というメソッドが自動的に GET /wiki に対応する）。AIはその規約を読み解いて、各アクションが対応するURLとHTTPメソッドを特定した対応表を生成しました。
| FuelPHP（規約） | URL | 対応するルート |
|---|---|---|
'_root_' => 'wiki/index' |
/ |
GET / → /wiki にリダイレクト |
規約: action_index() |
/wiki |
GET /wiki |
規約: action_view($id) |
/wiki/view/{id} |
GET /wiki/{page} |
規約: action_create() GET |
/wiki/create |
GET /wiki/create |
規約: action_create() POST |
/wiki/create |
POST /wiki |
規約: action_edit($id) GET |
/wiki/edit/{id} |
GET /wiki/{page}/edit |
規約: action_edit($id) POST |
/wiki/edit/{id} |
PUT /wiki/{page} |
規約: action_delete($id) GET |
/wiki/delete/{id} |
DELETE /wiki/{page} |
最後の行に注目すると、削除操作が GET で実装されていることまで正確に読み取られており、移行後は DELETE メソッドに修正する計画になっています。
Laravelには Route::resource() というCRUD操作に必要なルートをまとめて登録するヘルパーがあり、上の対応関係がすべてこの 1行 で賄えます。
Route::resource('wiki', WikiController::class)->parameters(['wiki' => 'page']);
ビュー（フェーズ6）
FuelPHPにはControllerとViewの間に Presenter という中間レイヤーがあり、日付フォーマットなどの表示ロジックをここで処理する設計になっています。移行計画ではこのレイヤーを廃止してControllerに統合する手順が示されており、ビューファイルの変更点も一覧化されています。
| 変更前 | 変更後 | 主な変更点 |
|---|---|---|
views/wiki/index.php |
wiki/index.blade.php |
自動エスケープ、ルートヘルパー |
views/wiki/view.php |
wiki/show.blade.php |
日付フォーマットをPresenterから移動 |
views/wiki/create.php |
wiki/create.blade.php |
CSRFトークン追加 |
views/wiki/edit.php |
wiki/edit.blade.php |
CSRFトークン、PUTメソッド追加 |
移行検証のテストケースが自動生成される
migration/test-specifications.md では、既存アプリケーションの動作をもとに、移行後の検証に使えるテストケースが自動生成されていました。
| ID | テストケース | 期待結果 |
|---|---|---|
| TC-01.1 | GET /wiki |
200 OK、ページ一覧を表示 |
| TC-01.4 | 空のDB | 空状態メッセージを表示 |
| TC-02.5 | コンテンツ表示 | nl2br() が適用される |
| TC-03.3 | 空のタイトルでPOST | バリデーションエラー（新規 — FuelPHPにはなし） |
| TC-03.6 | CSRFトークンなしでPOST | 419（新規 — FuelPHPにはなし） |
| TC-05.4 | GETで削除を試みる | 削除されない（新規 — FuelPHPはGETを使用） |
新規 と書かれているのは、Laravel移行で新たに満たせるようになる動作で、もともとFuelPHPにはなかった検証項目です。移行前と移行後の差分まで意識した内容になっています。
migration/validation-criteria.md では機能・セキュリティ・技術・UI/UXの4カテゴリで成功基準も定義されています。セキュリティ基準の例を挙げると：
| # | 基準 | 検証方法 |
|---|---|---|
| S1 | すべてのフォームでCSRF保護が有効 | @csrfなしで送信 → 419レスポンス |
| S2 | 削除がGETではなくDELETEメソッドを使用 | 削除ルートにGETを試行 → 405レスポンス |
| S3 | ソースコードにハードコードされた認証情報がない | コードベースでパスワードを検索 |
移行の「完了」がどういう状態かが明文化されているので、チェックリストとしてそのまま使えそうです。
「推奨変換: なし」という結論について
技術的負債レポートの冒頭には、こう書かれていました。
推奨されるTransformation: なし
このFuelPHP 1.8.2 PHPコードベースに適用可能なAWSマネージドTransformationはありません。利用可能なAWS TransformationはJava、Node.js、Python、Angular、Vue.jsのエコシステムをカバーしていますが、PHPフレームワークの移行は含まれていません。
「使えないのか」と思うかもしれませんが、前回のatx CLIを使った記事では実際にFuelPHP→Laravelの変換ができています。
これは矛盾ではなく、AWSマネージド変換（あらかじめ用意されたルールセット）にPHPフレームワーク移行が含まれていないという意味だと思います。atx CLIの対話モードでは、カスタム変換定義を新規作成 してから実行するため、PHPでも移行できます。
まとめると：
| 方法 | PHPフレームワーク移行 | 説明 |
|---|---|---|
| AWSマネージド変換定義 | ❌ 対象外 | Java・Python・Node.js等のみ |
| カスタム変換定義（atx対話モード等） | ✅ 可能 | 自分で変換ルールを定義して実行 |
おわりに
VS Code拡張でAWS Transformのコードベース分析を試した感想です。
VS Codeの拡張機能はClaude Code等のAIエージェントで、AWS Transformを操作する仕組みでした。
Claude Codeのサブエージェントみたいにして、AWS Transformを簡単に扱えるようにするおもしろい仕組みだと思いました。
また、AWS Transform customの包括的なコード分析TDは、移行前にこれだけの情報が自動で出てくるのは純粋にありがたいと感じました。ドキュメントがあまり無いWebシステムの静的解析によるドキュメントの作成は、「何から手をつければいいか」という整理に役立ちそうです。
「移行のロードマップを素早く作りたい」「現状のコードの全体像を把握したい」という場面での利用価値は高いと感じます。
今回はFuelPHPという小規模コードベースでの検証でしたが、数十万行規模のコードベースほどこの解析の恩恵は大きくなりそうです。
このブログがどなたかのお役に立てれば幸いです。
