dual-writeは「双方向」であることを前提に設計する

まず押さえておきたいのは、dual-writeが一方向のエクスポートではなく、F&OとDataverse間でほぼリアルタイムに双方向同期される仕組みだという点です。プランニングの現場でよくある誤解が「F&Oからのデータをただ一度きりエクスポートし、あとは手動で更新すればいい」というものですが、これは半分しか正しくありません。片方の変更はもう片方にも伝播するため、一方向の仕組みとして設計してしまうと、想定外のタイミングでデータが上書きされるといった事故につながります。

もう一つ重要なのが、「どちらのシステムが何の意思決定における正とするか」を明確にすることです。フィールドが両方のシステムに技術的に存在していても、それを両方が管理すべきとは限りません。与信限度額、商品属性、価格、顧客分類、出荷状況、ベンダー情報など、プロセスごとにどちらが正とするかを事前に定義しておく必要があります。

ダウンタイムを避けるカットオーバー戦略

カットオーバーで特に注意すべきは、データ移行とdual-writeの初期同期（Initial Write）を混同しないことです。Initial Writeは低ボリュームの初期データ作成には向いていますが、データ移行の代替として使うべきではありません。数十万〜数百万件規模のデータがある場合は、dual-writeを有効化する前に、それぞれのアプリへ個別にデータを移行しておくのが基本です。

実務での進め方としては、まずカットオーバーウィンドウの外でデータ移行を完了させ、企業情報などのマスターデータをDataverse側に用意しておきます。その上でdual-writeのマッピングを有効化し、実行中のマッピングは絶対に「一時停止」ではなく「停止」してから変更する、という運用ルールを徹底することが重要です。マッピングを一時停止のまま24時間以上放置すると、キューレコードのエラーが発生することが知られています。

よくある落とし穴

標準マッピングを安易にカスタマイズしすぎるのも典型的な失敗パターンです。Microsoftは列マッピングのカスタマイズ、変換、フィルタを許可していますが、変更は慎重に行う必要があります。また、CEのオプションセットとF&Oの列挙型（enum）が正しく対応しているか、価格・取引先番号のようなキーがどちらのシステムを起点に採番されるかを、実装前に決めておかないと、後から競合する番号が生成されてしまうといった問題が発生します。

私たちSapotaCorpのチームも、X++でのF&O拡張開発からdual-writeの設計、複数国展開のロールアウトまで、Dynamics 365案件を数多く手がけてきました。カットオーバー計画を「金曜日の午後にマッピングを流すだけ」で済ませず、システム・オブ・デシジョンの定義から逆算して設計する、という進め方を徹底しているのは、過去の案件で番号採番の競合やデータ不整合に苦労した経験があるからです。詳しい実装パターンはSapotaCorpのDynamics 365ページにまとめています。

まとめ

dual-writeは「設定すれば動く」ツールではなく、業務プロセスごとに正のシステムを決める設計作業そのものです。カットオーバー前のデータ移行計画と、マッピング停止時の運用ルールさえ押さえておけば、ダウンタイムを最小限に抑えた移行が可能になります。

D365のカットオーバー計画や既存dual-write構成の見直しについて相談したい方は、SapotaCorpまでお気軽にご連絡ください。

ただ、実際に本番運用に乗せる段階になると、ドキュメントだけでは分かりにくい部分でつまずく現場が少なくありません。特によく相談を受けるのが「並列実行」と「リトライ」の設計です。

並列処理でループを速くする

Power Automateの「Apply to each」アクションは、既定では並行制御がオフになっており、ループの各アイテムを1件ずつ順番に処理します。たとえば2000件のレコードに対して1件あたり3秒かかるHTTP呼び出しを直列で行うと、合計で約100分かかります。

これを「並行制御（Concurrency Control）」でオンにし、「並列処理の次数」を20に設定すると、同じ処理が理論上5分程度まで短縮されます。設定は次の手順です。

1. 「Apply to each」アクションを選択2. 右上の「...」から「設定」を開く3. 「同時実行制御」をオンにする4. 「並列処理の次数」を設定（既定20、範囲1〜50）5. 保存して実行し、実行履歴で並列処理の挙動を確認する

とはいえ並列化はどんな処理にも安全というわけではありません。処理順序に意味がある場合や、共有リソースを複数の実行が同時に更新する場合は、競合状態やデータ不整合を引き起こすリスクがあります。並列化を検討する前に「各アイテムの処理が本当に独立しているか」を確認しておく必要があります。実際、あるプロジェクトで在庫更新フローを安易に並列化した結果、同じ商品の在庫数が競合して不整合を起こしたことがあり、そこから「共有リソースを触るループは並列化しない」というルールを社内で徹底するようになりました。

リトライロジックで失敗に備える

HTTP系のコネクタアクションには「再試行ポリシー」が設定でき、主に4つのオプションがあります。「なし」は失敗時に再試行しない設定、「既定」は指数バックオフで約50秒の間に4回再試行、「固定間隔」は一定間隔でN回再試行、「指数間隔」は間隔を指数的に広げながらN回再試行するという内容です。

ネットワークの一時的な瞬断や外部サービス側の一時エラー（503など）に対しては、既定の再試行ポリシーで十分なことがほとんどです。注意したいのは「冪等（べきとう）ではない処理」で、たとえば「決済を作成する」ようなアクションでリトライが発生すると、同じ処理が複数回実行されて重複決済につながる恐れがあります。冪等性キーをリクエストに含めて重複を防ぐか、再試行ポリシーを「なし」に設定した上で、上位のScope/Catchで明示的にエラーハンドリングを行うのが安全です。

私たちSapotaCorpも、Power Platformを使った業務自動化案件でこうした落とし穴に何度も遭遇してきました。DataverseのポリモーフィックルックアップやPCFコントロールの実装、複数環境間のALM設計まで含めて、ドキュメントに書かれていない本番特有の挙動を実際の案件で確認しながら設計しています。

まとめ

Power Automateは手軽に始められる一方で、本番の負荷やデータ整合性を考えた設計になると一気に難易度が上がります。並列処理の次数とリトライポリシーは、その中でも特に見落とされがちなポイントです。大量データを処理するフローを組む際は、「本当に並列化して安全か」「リトライで重複が起きないか」の2点を確認しておくことをおすすめします。詳しい実装パターンはSapotaCorpのPower Platform関連ページにもまとめているので、興味があればあわせてご覧ください。

フローのパフォーマンス改善や自動化基盤の設計で相談したいことがあれば、SapotaCorpまでお気軽にご連絡ください。

ヘッドレスコマースの流れ

従来のShopifyストアは、Liquidテーマを使ってフロントエンドとバックエンドが一体化した構成が基本でした。手軽に始められる反面、デザインの自由度やパフォーマンスチューニングには限界があります。ヘッドレスコマースは、フロントエンド（見た目の部分）とバックエンド（在庫・注文・決済などの仕組み）を切り離し、APIを介して連携させる構成です。フロントエンドを自由に作り込めるようになる分、開発の難易度は上がりますが、ブランド独自の体験を作りたい企業にとっては魅力的な選択肢になっています。

Shopify Hydrogenとは：Reactベースのストアフロント

Hydrogenは、Shopifyが公式に提供するヘッドレスコマース向けのフレームワークです。React Router（旧Remix）をベースにしており、商品一覧・カート・バリエーション選択といったECに必要なコンポーネントがあらかじめ用意されています。GraphQLベースのStorefront APIを通じてShopifyのバックエンドと通信するため、開発者は「見た目」の実装に集中できます。

ホスティングには、Shopify純正のエッジホスティング「Oxygen」を使うのが標準的な構成です。デプロイまで含めてShopifyのエコシステム内で完結するため、インフラ管理の負担が少ないのも特徴です。

パフォーマンス面でのメリット

従来のテーマ構成と比較したときの一番の違いは、表示速度です。HydrogenはReactのサーバーサイドレンダリングとキャッシュ機構を活用しており、GraphQL APIのレスポンスも高速なため、ページの初期表示が速くなります。ECサイトでは表示速度が数百ミリ秒遅くなるだけでも離脱率やコンバージョン率に直結すると言われており、特にモバイル比率の高い日本市場では無視できない要素です。

また、Optimistic UI（操作結果を先読みして即座に画面に反映する仕組み）やプログレッシブエンハンスメントにも対応しているため、カート追加やフィルタリングといった操作の体感速度も向上します。

実装イメージ

Hydrogenプロジェクトの立ち上げ自体はシンプルで、公式CLIから数分で開始できます。

npm create @shopify/hydrogen@latest# セットアップ時に聞かれる主な項目# - Storefront APIへの接続方法（Shopifyアカウント連携 or モックデータ）# - スタイリング（Tailwindなど）# - 多言語・多市場対応（サブフォルダ / サブドメイン / 独自ドメイン）

日本向けストアの場合、多市場対応の設定で日本語ロケールとJPYでの価格表示を組み込んでおくと、後からの手戻りを減らせます。

導入を検討すべきタイミング

すべてのShopifyストアにヘッドレス構成が必要というわけではありません。既存のOnline Store 2.0テーマで十分に要件を満たせるなら、無理にHydrogenへ移行する必要はないでしょう。ただし、次のようなケースでは検討する価値があります。

• ブランド独自のUI/UXを追求したいが、テーマのカスタマイズ限界に達している
• Core Web Vitalsのスコアが伸び悩んでおり、表示速度がコンバージョンに影響している
• 複数言語・複数通貨での展開を本格的に進めたい

私たちSapotaCorpのチームでは、Online Store 2.0のテーマ開発からHydrogen＋Oxygenによるヘッドレス構築まで、Shopifyの案件を幅広くサポートしています。テーマの限界に達したタイミングでの移行判断や、Core Web Vitalsの改善提案も含めて対応しており、こうした知見はSapotaCorpのShopifyページでも紹介しています。

まとめ

ヘッドレスコマースは「なんとなく高機能そう」で導入するものではなく、既存テーマの限界を実感してから検討するのが現実的です。Shopify Hydrogenはその選択肢の中でも、公式サポートと開発効率のバランスが取れたフレームワークと言えます。まずは自社サイトのCore Web Vitalsやテーマのカスタマイズ限界を洗い出すところから始めてみてはいかがでしょうか。

Shopifyのテーマ改善やヘッドレス移行について相談したいという方は、SapotaCorpのチームまでお気軽にご連絡ください。

2026年のLLMエージェントトレンド

これまでのRAGは「質問に対して関連情報を検索し、それをもとに回答を生成する」というシンプルな一往復の仕組みが中心でした。しかし最近のエージェント型システムは、検索・判断・再検索・実行というループを何度も回しながら、複雑なタスクを段階的に解決していきます。社内ドキュメント検索から始まり、契約書レビュー、カスタマーサポートの一次対応まで、適用範囲は急速に広がっています。

ただし、エージェントが「賢そうに動いている」ことと「実際に正しい回答をしている」ことは別問題です。デモでは良さそうに見えても、本番環境で数値化された精度がないまま運用しているケースが少なくありません。ここで必要になるのが、RAGの評価指標です。

RAG評価で重要な3つのメトリクス

RAGシステムの品質を「なんとなく良さそう」で終わらせないために、Ragasのようなフレームワークでは、パイプラインの各層を分解して数値化します。特に重要なのが次の3つです。

1. Faithfulness（忠実性）
生成された回答が、実際に取得したコンテキストにどれだけ忠実かを測る指標です。回答をひとつずつの主張に分解し、それぞれが検索結果によって裏付けられているかを判定します。スコアが低いと、LLMが検索結果にない情報を「それらしく」作り出している、つまりハルシネーションが起きているということになります。

2. Context Precision（コンテキスト精度）
検索によって取得したコンテキストのうち、実際に回答に必要だった情報がどれだけの割合を占めるかを見る指標です。関係のない文書ばかり大量に取得していると、LLMが余計な情報に惑わされて回答の質が下がる原因になります。

3. Answer Relevance（回答の関連性）
生成された回答が、そもそもユーザーの質問に対してどれだけ的確に答えているかを測ります。技術的には正しくても、論点をぼかしたり余計な情報で埋めたりする回答は、このスコアが低く出ます。

この3つを組み合わせることで、「検索が悪いのか」「生成が悪いのか」「そもそも質問の意図を捉えられていないのか」を切り分けて診断できるようになります。

LangChain / LangGraphでの実装イメージ

実際の実装では、LangGraphを使ってエージェントのループを状態遷移として定義するのが一般的です。

from langgraph.graph import StateGraph, ENDdef retrieve(state):    docs = retriever.invoke(state["question"])    return {"context": docs}def generate(state):    answer = llm.invoke(        f"Context: {state['context']}\nQuestion: {state['question']}"    )    return {"answer": answer}def should_retry(state):    if state.get("faithfulness_score", 1.0) < 0.85:        return "retrieve"    return ENDgraph = StateGraph(dict)graph.add_node("retrieve", retrieve)graph.add_node("generate", generate)graph.add_edge("retrieve", "generate")graph.add_conditional_edges("generate", should_retry)graph.set_entry_point("retrieve")app = graph.compile()

ポイントは、生成した回答をそのまま返すのではなく、Faithfulnessスコアが基準を下回った場合に検索ステップへ差し戻すロジックを組み込んでいる点です。エージェントに「自己評価」の仕組みを持たせることで、単純な一往復のRAGよりも安定した回答が期待できます。

Sapotaの実践から

私たちSapotaCorpのチームでは、企業向けのRAGシステム構築において、本番リリース前に必ずFaithfulness・Context Precision・Answer Relevanceの3指標を計測してから出しています。ベトナムの金融機関向けAIアシスタントの案件では、デモ段階では気づかなかったハルシネーションが、この3指標を導入したことで数値として可視化され、リリース前に修正できたケースもありました。こうしたAI・機械学習まわりの知見はSapotaCorpのAI・機械学習ページでも紹介しています。

まとめ

AIエージェントは「作ること」自体は以前より簡単になりましたが、「本番で信頼できる精度を保証すること」は依然として難しい課題です。Faithfulness、Context Precision、Answer Relevanceという3つの指標を押さえておくだけで、なんとなくの精度評価から、数値で語れるRAG運用へと一歩進めるはずです。

AIエージェントやRAGパイプラインの構築・評価で相談したいことがあれば、SapotaCorpのチームまでお気軽にご連絡ください。

AMPscriptとは何か、誰のためのものか

AMPscriptは、SFMCのメールやCloudPage、SMSの中に埋め込んで使う独自のスクリプト言語です。単純に「名前を差し込む」くらいなら誰でもできますが、条件分岐やデータ抽出、フォーマット変換など、少し複雑なロジックが必要になった瞬間に、AMPscriptの知識が問われます。

対象になるのはこんな人たちです。

• SFMCでメールテンプレートを組んでいるマーケター
• Data Extension（DE）からデータを引っ張ってパーソナライズしたい担当者
• ジャーニービルダーで複雑な条件分岐を作りたい実装者

「コードは書けないけど、動的なメールは作りたい」という人が、最初につまずくポイントでもあります。

パターン1：ELSE SETで条件分岐を安全に

一番よくあるのが、条件によって表示内容を出し分けるケースです。単純なIF文だけだと、条件に当てはまらなかった場合に空欄になってしまうことがあります。それを防ぐために、ELSE側でも必ず値をSETしておくのが鉄則です。

%%[VAR @tier, @messageSET @tier = AttributeValue("CustomerTier")IF @tier == "Gold" THEN  SET @message = "いつもご利用ありがとうございます。限定オファーをご用意しました。"ELSE  SET @message = "ぜひ次回のお買い物でポイントを貯めてみませんか？"ENDIF]%%%%=v(@message)=%%

こうしておけば、想定外の値が来ても空白のメールが飛ぶ事故を防げます。

パターン2：LookupRowsで動的コンテンツを組み立てる

単一の値を取ってくるだけならLookup関数で十分ですが、複数行のデータ（例えば「最近購入した商品リスト」）を表示したい場合はLookupRowsの出番です。

%%[SET @rows = LookupRows("PurchaseHistory_DE", "SubscriberKey", @subscriberKey)SET @rowCount = RowCount(@rows)]%%%%[ IF @rowCount > 0 THEN ]%%  <ul>  %%[ FOR @i = 1 TO @rowCount DO    SET @row = Row(@rows, @i)    SET @productName = Field(@row, "ProductName")  ]%%    <li>%%=v(@productName)=%%</li>  %%[ NEXT @i ]%%  </ul>%%[ ENDIF ]%%

ポイントは、DEの検索キーが正確でないと空配列が返ってくるだけで、エラーにはならないということ。デバッグ時にここでハマる人が本当に多いです。

パターン3：RowCountでフォールバックを用意する

上の例でも使いましたが、RowCountは「データが本当に取れているか」を判定する上でとても重要です。これを省略すると、データが0件のときに空の<ul>タグだけが残ってしまい、メールの見た目が崩れます。

%%[IF @rowCount == 0 THEN]%%  <p>現在おすすめできる商品情報がありません。カタログをご覧ください。</p>%%[ENDIF]%%

「データがない前提」を常に組み込んでおくことが、本番運用でのトラブルを減らすコツです。

現場での経験から

私たちSapotaCorpのチームは、12以上のSalesforce認定資格を持つエンジニアが在籍しており、ベトナムやAPAC地域のクライアント向けにSFMCの実装プロジェクトを複数手がけてきました。AMPscriptのようなロジックまわりは、ドキュメントだけでは見えてこない「本番特有の落とし穴」が多く、実際に手を動かした経験がものを言う領域です。

実際、Email Studio・Journey Builder・Automation Studioを横断した70以上の実践パターンを社内で蓄積しており、Journey Builderの分岐設計やMarketing Cloud Connectの使いどころといったテーマも含めて、こうした知見はSapotaCorpのMarketing Cloud関連記事でも詳しく紹介しています。

まとめ

AMPscriptは最初は取っつきにくく感じますが、「条件分岐は必ずELSE側もケアする」「複数行取得はLookupRowsとRowCountをセットで使う」という基本さえ押さえれば、応用が効くようになります。今回紹介した3つのパターンは、実際の案件でも頻繁に登場する組み合わせなので、ぜひ手元の環境で試してみてください。

SFMCまわりでもっと深く相談したい、実装で困っているという方は、SapotaCorpのチームまでお気軽にご相談ください。