やればわかるさバイブコーディング Vol.25　Accessの遺産をキャンバスアプリに完全移植してみた ― Claude Opus 4.6 × Codex 5.3で166項目検証クリアまで

今回はガチの業務Accessを使います。

10年以上稼働してきた商品の受注管理システム。伝票入力、精算処理、大口リベート計算、CSV出力、10種類の帳票印刷……VBAでゴリゴリに組まれた、まさに「誰も触れられないけど止められない」やつです。

これをClaude Opus 4.6とVSCode + Codex 5.3を使って、Power Appsキャンバスアプリに完全移植してみました。166項目の検証で実装率98.8%。ここに至るまでの怒涛の記録です。

0. この記事の全体像

先に結論を書きます。

項目	値
移植元	Access .mdb（VBA・クエリ・レポート合計100超オブジェクト）
移植先	Power Apps キャンバスアプリ（SharePointリスト×6）
画面数	業務画面14 + 印刷画面10 = 24画面
使ったAI	Claude Opus 4.6（解析・YAML生成・検証）、Codex 5.3（VSCodeでの修正）
所要時間	約16時間（休憩込み・2日間）
検証結果	166項目中164項目Pass（実装率98.8%）
コード手書き	0行（全部AIが書きました）

1. 🧩 今回のAccessはこんなやつ

受注から精算までを一気通貫で管理するシステムです。

テーブル構成（SharePointリスト化後）：

テーブル	内容	レコード規模
SP_TransactionSlip	伝票（受注データ本体）	数千件/年
SP_ProductMaster	商品マスタ（品名・期別単価）	約300件
SP_CustomerMaster	顧客マスタ	約200件
SP_ShipperMaster	物流会社マスタ	約10件
SP_PackageMaster	梱包規格マスタ	約10件
SP_SettlementDateList	精算日マスタ	約20件

業務フロー：

伝票入力 → 伝票一覧 → 精算処理 → 各種帳票印刷
                ↓
        リベート計算・未収計上・CSV出力・実績集計

計算ロジックの核心部分：

税抜 = ((期別単価 - 自社配送割引 + 単価調整) × 単位重量 ÷ 入数 + 梱包値引) × 数量
消費税 = RoundDown(税抜 × 0.1 + 0.5, 0)

さらに大口リベートは6段階累進レート（160万→1.5%～1,600万→5.5%）、早期予約割引は0.1%固定（特定分類コード除外）……と、VBA計算式のオンパレードです。

正直、Accessを開いても全体像がつかめないレベルの複雑さ。

2. 🪜 作戦：AIリレーで一気に駆け抜ける

Vol.16では「構造抽出→仕様化→Code Apps雛形」の3ステップでしたが、今回は本番業務アプリなので工程が増えます。

全体工程

Phase 0: Access解析 → 移植仕様書（Claude Opus 4.6 ブラウザ版）
Phase 1: YAML画面生成 × 10画面（Claude Opus 4.6 ブラウザ版）
Phase 2: Power Apps Studioに貼り付け → エラー修正ループ（Claude Opus 4.6 ブラウザ版）
Phase 3: ギャップ分析（Access vs 生成アプリ）（Claude Opus 4.6 ブラウザ版）
Phase 4: 不足機能の追加実装 5フェーズ（Claude Opus 4.6 ブラウザ版）
Phase 5: VSCode + Codex 5.3 で統合修正（pac CLIでunpack/pack）
Phase 6: 最終検証レポート（Claude Opus 4.6 ブラウザ版）

ポイントはAIのリレーです。Phase 0～4と6はブラウザ版Claude（claude.ai）で完結。msappファイルをアップロードして解析させたり、YAMLを生成させたり、エラーのスクショを見せて修正させたり。Phase 5だけVSCode + Codex 5.3に切り替えて、pac CLIでmsappをアンパック → pa.yamlを直接編集 → 再パックしています。人間（私）は指示出しと判断とStudioへの貼り付けだけ。

3. Phase 0: Accessファイルを丸ごと食わせる

やったこと

Claude Opus 4.6に.mdbファイルをアップロードして、こう指示しました：

このファイルをPowerAppsキャンバスアプリに完全再現する手順をわかりやすく教えてデータソースはSharePointリストとします実装は可能な限りPowerFXで行います SharePointリストに必要なテーブルはCSV出力して（列名は英字、タイトル列を1列目につけること）

Claudeはまずmdbtools（Linux上のAccessパーサー）でテーブル構造を解析。VBAコード、クエリ定義、リレーションまで抽出して、以下を自動生成してくれました：

SharePointリスト定義（6テーブル分のCSV）
画面設計書（14業務画面 + 10印刷画面）
PowerFX計算式（税額計算、リベート、梱包値引等）
画面遷移図

ここまで約30分。Accessを1画面も操作していません。

Vol.16のときと違うのは、最新モデル（Opus 4.6）の解析精度です。テーブル間のリレーションだけでなく、VBAの計算ロジックまで正確に読み取って、PowerFXに変換してくれました。4ヶ月前のClaude 4.5でも十分でしたが、Opus 4.6はVBAの複雑な条件分岐（6段階累進レートとか）をほぼ一発で正しく変換してくれます。

4. Phase 1: YAML画面生成 ― 怒涛の10画面

Power Apps YAML（pa.yaml）とは

Power Appsのキャンバスアプリは、内部的にYAMLで画面定義を持っています。Power Apps Studioの画面エディタで右クリック→「コードの貼り付け」でYAMLを直接流し込むことができる。つまりAIにYAMLを生成させて、Studioに貼り付ければ画面が出来上がる。

これがバイブコーディングの核心。YAMLは構造化テキストなので、生成AIとの相性が抜群にいい。今回の作業は基本的にブラウザ版Claude（claude.ai）でYAML生成 → Power Apps Studioに貼り付けの繰り返しです。

Claudeに10画面分を一気に生成させる

移植仕様書をもとに、Claudeに各画面のYAMLを生成させました。

Screen01: HomeScreen（メインメニュー）
Screen02: SlipInputScreen（伝票入力）
Screen03: SlipListScreen（伝票一覧）
Screen04: DeliveryListScreen（納品一覧）
Screen05: SettlementScreen（精算処理）
Screen06: ShipperListScreen（物流会社別一覧）
Screen07: ResultScreen（実績集計）
Screen08: IncentiveScreen（大口リベート）
Screen09: AccrualScreen（未収計上）
Screen10: MasterScreen（マスタ管理）

1画面あたり300～800行のYAML。合計で約5,000行が生成されました。

最大の壁：SchemaV3への準拠

ここで最初の大きな壁にぶつかりました。Claude が生成するYAMLは、Power AppsのPaYaml SchemaV3に完全準拠していないことがある。具体的には：

GroupContainerのVariant指定が必要（manualLayoutContainer等）
Buttonのバージョン指定（Button@0.0.45）
Classic/DropDownとComboBoxの混同
プロパティ名の微妙な違い（Items.Valueが必要なのにItemsだけ等）

これらはClaude自身にエラーメッセージを渡して修正させるサイクルで潰していきました。Power Apps Studioに貼り付け → エラー確認 → Claudeにスクショを送る → 修正版YAML受け取り → 再貼り付け……の繰り返しです。

正直、このフェーズが一番泥臭い。10画面×平均3-4回のリトライで、約4時間かかりました。

5. Phase 2: Power Apps Studioに貼り付け → エラー修正ループ

ClaudeがブラウザのArtifactsとして生成したYAMLを、Power Apps Studioに画面単位で貼り付けていきます。ここで細かいエラーが出てきます。

典型的なエラーパターン

1. SharePoint列名のミスマッチ

SharePointリストではTitle列が特殊扱い。Access側の「品名」がPower Apps側でTitleになるのに、YAML上ではProductNameを参照していたり。

2. AddColumnsの構文

AddColumnsで計算列を追加するとき、列名にクォートが不要（SchemaV3）なのに付けていたり、逆に必要な場所で抜けていたり。

3. DropDownのItems.Value

Classic/DropDownではItemsにコレクション、Items.Valueに表示列を指定する必要がありますが、ClaudeはShowColumns方式で書いてくることがある。これはClassicコントロールでは動かない。

修正サイクルの効率化

このフェーズで学んだのは、エラーメッセージのスクリーンショットをそのままClaudeに送るのが最速ということ。テキストで説明するより、Power Apps Studioのエラーパネルのスクショを貼るほうがClaudeの理解が早い。

「この画面でこのエラーが出ています」→ スクショ → 「修正版YAMLください」

これで大半のエラーは1往復で解決しました。

6. Phase 3: ギャップ分析 ― Accessと生成アプリの差を可視化

10画面がmsappに組み込めたところで、元AccessとPower Appsの機能差分を洗い出しました。

これもClaude Opus 4.6に両方（.mdbと.msapp）を読み込ませて、自動比較させます。

結果は衝撃的でした：

■ 検出された不足機能
- 印刷帳票が10種類中0種類しかない（印刷画面未実装）
- CSV出力機能なし
- 決算未収金・利用割戻の画面なし
- 早期予約割引の画面なし
- マスタ管理がRead Only（編集・削除不可）
- 精算の一括処理ボタンなし
- 大口リベートの計算式に微妙な差異あり

■ 実装率：約60%

Phase 1-2で生成した10画面は骨格はできていたが、肉が足りない状態。ここからPhase 4の追加実装に入ります。

7. Phase 4: 不足機能の追加実装 ― 5フェーズで一気に

ギャップ分析結果をもとに、5フェーズの実装計画を立てました。これもClaude Opus 4.6に設計させて、そのままYAML生成まで一貫して任せました。

フェーズ1: リベート計算の修正 + 未収計上強化

大口リベートの6段階レートが一部ズレていたのを修正。AccrualDate（未収計上日）フィールドの追加。

フェーズ2: 早期予約割引 + 未収計上画面の完成

EarlyIncentiveScreenを新規作成。0.1%レートの計算、分類コード51-4除外のフィルタを実装。

フェーズ3: CSV出力

CsvExportScreenを作成。4つの分類コード別タブ（51-1/51-2/51-3/51-4）でCopy(Concat(...))方式のクリップボード出力を実装。Power Appsにはファイル出力APIがないので、Concat関数で文字列を組み立ててクリップボードにコピーする方式です。

フェーズ4: 印刷画面 × 10

ここが一番のボリュームゾーン。Accessのレポート10種類に対応する印刷画面を作成しました：

PrintInvoiceScreen          ← R_納品書
PrintSettlementScreen       ← R_精算一覧
PrintTransferSlipScreen      ← R_振替伝票
PrintProductSalesScreen     ← R_商品別売上
PrintShipperDeliveryScreen  ← R_物流会社別納品
PrintAccrualScreen          ← R_未収計上内訳書
PrintIncentiveDetailScreen  ← R_大口リベート明細
PrintEarlyIncentiveScreen   ← R_早期予約割引
PrintPersonalDetailScreen   ← R_個人別明細
PrintYearlySummaryScreen    ← R_年度別月次集計

全画面でA4固定サイズ（794×1123）、Screen.Printingでツールバー非表示、Print()関数で印刷実行、Back()で戻る……というパターンを統一。

フェーズ5: 決算未収金・利用割戻・年度集計

FiscalAccrualScreen（分類コード別/個人別タブ切替）、RebateScreen（精算済＋51-4除外フィルタ）を新規作成。ResultScreenに年度別月次集計タブを追加。

ここまでで合計24画面・約15,000行のYAML。Phase 4だけで約5時間かかりました。

8. Phase 5: VSCode + Codex 5.3 で統合修正

Phase 4までで生成されたYAMLをmsappに組み込むと、さらにエラーが出てきます。型の不一致、列参照の誤り、Classic/DropDownのDefault式問題……。

ここで登場するのがVSCode + Codex 5.3。

pac CLIでmsappをアンパックして、VSCode上でpa.yamlファイルを直接編集します。Codex 5.3はPower Apps YAMLの構文を理解しているので、エラー箇所を指示するだけで的確に修正してくれます。

Codex 5.3で修正した主な内容

1. colSlipFinalの列欠落問題

これが最も重要な修正でした。SlipListScreenで生成する計算済みコレクションcolSlipFinalにc_PaymentType（支払区分）とc_CategoryCode（分類コード）の列が含まれていなかった。

精算画面（SettlementScreen）はcolSlipFinalを再利用するので、これらの列がないと支払区分フィルタが動作しないというランタイムエラーが起きます。

修正：SlipListScreenのAddColumnsに2列追加 + SettlementScreenのOnVisibleに再生成ガード追加。

2. DropDown編集モード復元

SlipInputScreenの6つのDropDown（顧客・商品・梱包・精算日・申込区分・物流会社）にDefault式を追加。編集時にvarEditRecordの値をItems.Value列（ComplianceAssetId/Category）経由で正しく復元するようにしました。

ここでハマったのが、Classic/DropDownのDefaultプロパティはテキスト値を期待するということ。LookUpでレコードを返してしまうと「Text値が必要です」エラーになります。

最初Claudeが生成した式：

Default: =LookUp(colCustomer, CustomerNo = varEditRecord.CustomerCode)

正しい式（Items.Valueで指定した列の値を返す）：

Default: =If(!varIsNewRecord, 
  LookUp(colCustomer, CustomerNo = varEditRecord.CustomerCode).ComplianceAssetId, 
  Blank())

3. バリデーション強化

保存ボタンのバリデーションが顧客・商品・数量の3項目しかなかったのを、梱包・精算日・申込区分・物流会社・納品日を追加して8項目に拡張。さらにIfError()でPatch失敗時のエラーハンドリングも追加しました。

4. 型の不一致修正

MasterScreenのPatch式で： - CustomerNo（number型）にテキストを渡していた → Value()で変換 - PackageCode（number型）にテキストを渡していた → Value()で変換 - SettlementDate（Date型）にテキストを渡していた → DateValue()で変換 - 存在しないRemarks列を参照していた → 正しいTitle列に修正

これらのエラーはPower Apps Studioのスクリーンショットを撮ってClaudeに送り、修正方針を確認してからCodexで実装……というAIリレーで効率的に進めました。

9. Phase 6: 最終検証 ― 166項目を自動チェック

ここが今回のハイライトです。

完成した2つのmsapp（ベースライン版とCodex修正版）をClaude Opus 4.6に渡して、166項目の自動検証を実行しました。

検証カテゴリと結果

カテゴリ	項目数	ベースライン版	統合修正版
画面存在	26	26/26 ✅	26/26 ✅
App初期化	7	6/7	6/7
ナビゲーション	46	46/46 ✅	46/46 ✅
価格計算	7	5/7	7/7 ✅
伝票CRUD	8	5/8	7/8
精算処理	4	3/4	4/4 ✅
マスタCRUD	4	4/4 ✅	4/4 ✅
リベート	3	3/3 ✅	3/3 ✅
早期予約割引	3	3/3 ✅	3/3 ✅
CSV出力	2	2/2 ✅	2/2 ✅
決算/割戻	4	4/4 ✅	4/4 ✅
未収計上	2	2/2 ✅	2/2 ✅
SP参照	6	6/6 ✅	6/6 ✅
印刷	20	20/20 ✅	20/20 ✅
数式構文	24	24/24 ✅	24/24 ✅
合計	166	159/166	164/166
		95.8%	98.8%

統合修正版で解消された問題（5件）

#	問題	影響
1	colSlipFinalにc_PaymentType欠落	精算画面のフィルタ不動作
2	colSlipFinalにc_CategoryCode欠落	CSV出力・決算画面でエラー
3	DD編集復元なし（6 DD）	編集時にDropDown値リセット
4	バリデーション不足	不完全データ登録リスク
5	c_PaymentType再生成ガードなし	画面遷移順序依存のエラー

統合修正版に残る課題（2件・軽微）

#	内容	回避策
1	App.OnStartにvarPrintRecord初期化なし	HomeScreenのSet()で代替済み
2	保存後にClear(colSlipFinal)なし	遷移先OnVisibleで再生成される

いずれも運用上の実害なし。正規のナビゲーション経路を通る限り問題は発生しません。

10. 🔍 Access機能との最終対応表

元Accessのオブジェクト（フォーム・クエリ・レポート・マクロ）がPower Appsでどう再現されたかの対応表です。

フォーム → 画面

Accessフォーム	Power Apps画面	実装方式
F_メインメニュー	HomeScreen	Buttonタイル型ナビゲーション
F_伝票入力	SlipInputScreen	Patch(新規/更新) + Remove(削除)
F_伝票一覧	SlipListScreen	Gallery + AddColumns計算列
F_精算	SettlementScreen	ForAll + Patch一括処理
F_マスター管理	MasterScreen	5タブ × Patch/Remove
F_未収計上	AccrualScreen	ForAll + Patch(AccrualDate)

クエリ → 画面（計算ロジック内蔵）

Accessクエリ	Power Apps画面	計算方式
Q_個人別集計	ResultScreen(personalタブ)	GroupBy + Sum
Q_商品別集計	ResultScreen(productタブ)	GroupBy + Sum
Q_年度別月次集計	ResultScreen(yearlyタブ)	GroupBy + Sum
Q_大口リベート	IncentiveScreen	6段階Switch + RoundDown
Q_早期予約割引	EarlyIncentiveScreen	Filter(早期予約 & !51-4) × 0.001
Q_決算未収金	FiscalAccrualScreen	byCategory/byPersonタブ
Q_利用割戻	RebateScreen	精算済 & !51-4 フィルタ
Q_物流会社別	ShipperListScreen	ForAll集計
Q_納品一覧	DeliveryListScreen	日付範囲Filter
Q_CSV出力	CsvExportScreen	Copy(Concat()) × 4分類コード

レポート → 印刷画面

Accessレポート	Power Apps印刷画面	方式
R_納品書	PrintInvoiceScreen	A4固定(794×1123) + Print()
R_精算一覧	PrintSettlementScreen	〃
R_振替伝票	PrintTransferSlipScreen	〃
R_商品別売上	PrintProductSalesScreen	〃
R_物流会社別納品	PrintShipperDeliveryScreen	〃
R_未収計上内訳書	PrintAccrualScreen	〃
R_大口リベート明細	PrintIncentiveDetailScreen	〃
R_早期予約割引	PrintEarlyIncentiveScreen	〃
R_個人別明細	PrintPersonalDetailScreen	〃
R_年度別月次集計	PrintYearlySummaryScreen	〃

Accessのフォーム・クエリ・レポートのすべてに対応する画面が存在します。

11. ⏱️ タイムライン（実際の作業記録）

通算	作業内容	Phase
0:00	.mdbをClaude Opus 4.6にアップロード、解析開始	0
0:30	移植仕様書・SPリストCSV完成	0
0:30～3:00	YAML 10画面生成	1
3:00～8:00	msapp組込み・エラー修正ループ（SchemaV3対応）	2
8:00～12:30	カラムマッピング修正・ゴミ掃除・最終クリーンアップ	2
12:30～13:00	ギャップ分析（Access vs Power Apps）	3
13:00～13:30	不足機能の設計 → 5フェーズ計画	4
13:30～14:30	フェーズ1-2 リベート修正・早期予約・未収	4
14:30～15:30	フェーズ3-4 CSV・印刷画面×10	4
15:30～16:30	フェーズ5 決算・割戻・年度別 + 型エラー修正	4
（別セッション）	VSCode + Codex 5.3 で統合修正	5
＋約1時間	最終検証（166項目自動チェック）・レポート生成	6

合計約16時間。ただし、Phase 2のエラー修正ループが最も時間を食っています。YAML SchemaV3の仕様に慣れていれば半分以下になるはず。

12. 💡 学んだこと・Tips

AI選択の使い分け

AI	得意なこと	使った場面
Claude Opus 4.6	長文解析・大規模コード生成・検証	Access解析、YAML生成、ギャップ分析、検証レポート
Codex 5.3（VSCode）	ファイル単位の精密編集	pa.yamlの型修正、列追加、Default式修正

解析と生成はClaude、精密修正はCodexという分担が効率的でした。

Power Apps YAML Tips

1. Classic/DropDownのDefault

Defaultはテキスト値を返す式を書く。LookUpでレコードを返すのはNG。Items.Valueで指定した列の値（ComplianceAssetId等）を返す必要がある。

2. colSlipFinal（計算済みコレクション）の共有パターン

If(IsEmpty(colSlipFinal), ClearCollect(...))のガードパターンは便利だが、列構成が画面によって異なる場合に破綻する。先に訪問した画面が列の少ないcolSlipFinalを作ると、後続画面で列参照エラーになる。

対策：ガード条件に列存在チェックを追加。

If(IsEmpty(colSlipFinal) Or IsBlank(First(colSlipFinal).c_PaymentType), 
    ClearCollect(colSlipCalc, AddColumns(SP_TransactionSlip, ...))
)

3. Print画面の統一パターン

Width: =794
Height: =1123
# ツールバー（印刷時非表示）
Visible: =!Screen.Printing
# 印刷ボタン
OnSelect: =Print()
# 戻るボタン
OnSelect: =Back()

A4固定サイズ＋Screen.Printing制御＋Print()で統一すると10画面の量産が簡単。

4. SharePointの「Title」列の罠

SharePointリストのTitle列は表示名を自由に変更できるが、内部名は常にTitle。これがPowerFX上で混乱を招く。商品マスタの「品名」もSP上はTitle、梱包マスタの「表示名」もSP上はTitle。YAMLで参照するときは内部名（Title）を使う必要がある。

エラー修正の最速ルート

Power Apps StudioのエラーパネルのスクリーンショットをそのままClaudeに送る。テキストで説明するより圧倒的に速い。Claudeは画像からエラーメッセージを読み取って、対応するYAMLの修正箇所を特定してくれます。

13. Vol.16からの進化

Vol.16（2025年11月）と今回（2026年2月）の比較：

項目	Vol.16	今回
題材	Accessテンプレ（タスク管理）	本番業務Access（受注管理）
複雑さ	テーブル3、画面4	テーブル6、画面24、帳票10
AI	Claude 4.5	Claude Opus 4.6 + Codex 5.3
到達点	雛形生成まで	166項目検証Pass（98.8%）
所要時間	約1時間	約16時間
コード手書き	0行	0行