Salesforceリリース管理をパイプライン化：JSON中間フォーマット採用の理由と検証

どんな取り組みか
使われた技術スタック
実装のポイント
得られた成果や学び
まとめ

どんな取り組みか

本記事は、Salesforceのアーキテクトが月次リリース管理のパイプライン化に取り組んだ設計記録です。従来のリリース管理における「翻訳コスト」や「修正コスト」の削減、およびツールの仕組みを自身で理解することを目的としています。対象読者は、Salesforceのリリース管理自動化に関心のあるアーキテクト・エンジニアを想定しています。

使われた技術スタック

本取り組みでは、Salesforceのメタデータ管理、パイプライン設計、および自動化のために以下の技術要素が関わっています。

SalesforceメタデータAPI (SFDX CLI)
JSON (中間フォーマット)
XML (Salesforceデプロイ成果物)
Python (変換スクリプト、Claude API連携)
Excel (人間によるレビューインターフェース)
Git (差分管理)

実装のポイント

従来のフローは、要件定義から仕様書作成、Sandboxでの設定、テスト、本番デプロイという手動プロセスでした。このフローにおける「属人性」と「変更追跡の困難さ」という課題に対し、JSONを中間フォーマットとして採用する設計思想が取られました。

当初はExcelからXMLへの直接変換や、AIによるXML直接生成も検討されましたが、以下の理由からJSONが中間フォーマットとして選ばれました。

Gitでの差分管理が可能
JSON Schemaによる構造検証が可能
JSONからXMLへの変換が決定論的になる
AIとの親和性が高い

これにより、フォーマットの責務が「Excel = 人間が確認・編集するインターフェース」「JSON = 正規データモデル」「XML = Salesforceへのデプロイ成果物」と明確に分離されました。

アーキテクチャ全体像は以下の通りです。

要件テキスト（.txt） → text_to_json.py（Claude API） → salesforce_spec.json
salesforce_spec.json → json_to_doc.py → 仕様書.xlsx（人間がレビュー・修正）
仕様書.xlsx → excel_to_json.py → salesforce_spec.json（修正済み）
salesforce_spec.json → json_to_xml.py → force-app/（複数のXML）
run_pipeline_v2_json.py → sf project deploy start –dry-run（事前検証） → sf project deploy start（Sandboxデプロイ） → deploy_result.json（自動保存）

人間のレビューは仕様書.xlsxの確認・修正に集中させ、AIが生成したJSONを直接デプロイせず、Excelで人間が確認・調整してから再度JSONに戻す設計が採用されています。

実装におけるハマりポイントとしては、XML生成前に前回の出力をクリアし忘れていたこと（shutil.rmtreeで解決）や、Flowの関連レコード更新において、どのレコードを更新するかを特定するためのtarget_record_sourceの定義が不足していたことが挙げられます。

得られた成果や学び

現時点での評価は以下の通りです。

dry-runデプロイ: Sandboxでエラーが確認されました
対応メタデータ型: 複数の種類
未対応のCustomField型: 一部の型
Flow複雑な条件分岐: 手動修正が必要
text_to_json（AI変換）: テスト中
非エンジニアの自力デプロイ: 現時点では不可

「エンジニアの実装・デプロイ工数を削減できる」という感覚はあるものの、具体的な計測は行っていません。

アーキテクト視点からの考察として、AIをどこに置くかはツールの問題ではなくアーキテクチャの問題であると考えられます。AIに任せきりにせず、入出力形式や人間による確認プロセスを設計することが重要です。AIが構造化データを生成する精度は向上していくと考えられますが、Salesforceのデータモデル設計、セキュリティモデルの判断、ビジネス要件をメタデータ仕様に落とし込む能力は、AIが普及するほど重要性を増していくと考えられます。

まとめ

JSONを中間フォーマットに採用することで、変換の責務が分離されエラー原因の追跡が容易になりました。人間のレビューをExcel確認に集中させる設計も実現しました。dry-runでのエラー確認およびSandboxデプロイまで確認済みですが、未対応のCustomField型やFlowの複雑条件分岐は今後の課題です。text_to_json.py（要件テキスト→JSON変換）の精度検証も進めていく予定です。

出典: https://zenn.dev/shinji_tai/articles/f70a32f09b58f2

Related Certifications