TeradataからDatabricksへの移行検証で判明した課題・対策を紹介します。 1. はじめに NTTデータの丹羽です。Databricks Championとしても活動しています。 Databricksが提供するマイグレーション支援ツール Lakebridge を利用し、TeradataからDatabricksへの移行を検証しました。 本記事では、Lakebridgeの機能紹介ではなく、TeradataからDatabricksへの移行検証を通じて分かった効果・課題・適用範囲と、その対策について紹介します。 ! 本記事は検証結果に基づくものであり、製品の性能・結果を保証す

Gemini At Workとは何か？ Gemini At Workは、Google Cloudが主催する、企業での生成AI活用をテーマにしたイベントです。Geminiをはじめとする製品の情報に加え、企業の導入事例や、AIを業務に組み込む方法が紹介されます。去年2025年10月の開催では、企業向けAI基盤のGemini Enterpriseが発表されました。社内データとの接続、ノーコードでのAIエージェント構築、エージェントの一元管理を備え、組織全体の業務自動化を支える仕組みです。 さらに、AI学習プラットフォームのGoogle Skillsも発表されました。製品の進化と、それを使いこなす人材の育成という両面から、企業のAI活用を扱うイベントになっています。

はじめに 3rd party チームの武藤です。 Salesforce では、外部システムとの連携を担う認証・認可の仕組みとして、これまで 接続アプリケーション（CA）が広く使われてきました。しかし Salesforce の方針転換に伴い、 今後は外部クライアントアプリケーション（ECA）への移行 が求められています。 今回のように、Salesforce のリリースに応じて CA や ECA の設定変更が必要になるケースがよくあります。しかし、CA や ECA の設定変更は Salesforce の管理画面から直接行われることが多く、次のような課題を抱えています。 誰が・いつ・なぜ設定を変更したのかが追いにくい 環境（開発／ステージング／本番）ごとに手作業で同じ設定を入力する必要があり、設定ミスや漏れ、環境ごとの設定値のずれが起きやすい レビューの仕組みがなく、変更の妥当性を第三者が事前に確認できない Salesforce の第二世代管理パッケージ（2GP）にも対応したい この課題を解決するため、Salesforce ECA を IaC のように設定値のコード管理、反映前の差分チェック、自動反映できる仕組みを構築しました。本記事では、その設計と仕組みを紹介します。 設計方針 1. 共通設定 + 環境差分というデータ構造 全環境で共通する設定と、環境ごとに異なる設定を分離し、共通設定をベースに環境差分をマージして最終的な設定を組み立てる構成にしました。 設定ファイルを共通化することで、各環境間で意図しない設定差異が発生しにくくなります。 また、この構成には以下のようなメリットもあります。 環境間で共通の設定を二重管理しなくてよい 環境差分だけを見れば「その環境固有の設定は何か」が一目で分かる 環境ごとに異なることが多い設定値の例 アプリケーション名 IP 制限などの環境固有設定 新しい環境を追加する際も、差分ファイルを1つ増やすだけで済む 2. PR 作成・更新時に、実際の Salesforce 上の設定との差分を確認できる仕組み IaC 的である以上、変更を適用する前に差分チェックが可能である必要があります。 そこで、PR 作成・更新のタイミングで、PR 上の設定内容と Salesforce org 上に実際に存在する ECA の設定値を突き合わせ、その差分を PR にコメントして可視化する仕組みも作りました。 これにより、変更反映後に何がどう変わるのかを認識しやすくなります。 仕組み CI/CD をワークフローの役割ごとに分割 単一の CI ワークフローに全部を詰め込むのではなく、目的ごとに CI を分割しました。 定常CI ：構文エラーや生成処理の失敗、Salesforce への接続確認を自動検証 PR 差分レポート ：ECA の設定値ファイル変更時に、実際の Salesforce 上の設定と比較した差分を PR コメントとして自動通知 自動デプロイ ：ECA の設定値変更を含む PR のマージ時に、マージ先のブランチに対応する環境へ自動デプロイ 2GP パッケージ作成 ：手動実行により、Dev Hub でパッケージやパッケージバージョンを作成 この分離により、「レビュー段階で確認したいこと」と「マージ後に確実に実行したいこと」を明確に切り分けています。 PR差分レポートの仕組み 差分チェック対象の ECA をどう特定しているか Salesforce には複数の ECA が存在し得るため、「PR の環境に対応する 1 件の ECA だけ」を正しく特定して比較する必要があります。この仕組みは次の手順で成り立っています。 PRの対象ブランチから、比較する環境を決定する ：どの環境用の ECA と比較すべきかを、PRのマージ先ブランチから機械的に判定する PR上の設定（共通設定＋環境差分）をマージし、対象の識別名を取り出す ：マージ後の設定から、ECA本体の識別名（fullName）と、それに紐づく OAuth 設定の識別名を読み取る 取得対象を絞り込んだ retrieve 用マニフェストを都度組み立てる ：ECA本体は特定した1件だけを、OAuth設定は名称の揺れを吸収するためワイルドカードで指定し、その場限りの package.xml を生成する 取得結果から、対象の ECA に紐づく OAuth 設定だけを絞り込む ：ワイルドカードで複数件取得される可能性があるため、取得結果の中から「対象 ECA を参照している OAuth 設定ファイル」を中身の参照関係で特定する デプロイの仕組み デプロイ時は念のためデプロイ時の差分をログとして残しつつ、生成済みのメタデータパッケージをまるごと Metadata API に渡します。PR の時点で差分もレビュー済みという前提ではありますが、PR 作成からマージまでに間があった時のため、念のため差分を記録として残しています。 2GP 用パッケージ作成 この仕組みにより、次のメリットがあります。 2GP で実施したい下記のような作業を、任意選択によって必要なものだけを自動実行できる パッケージ作成 パッケージバージョン作成 パッケージのリリース プッシュアップグレード 指定 org へのパッケージバージョンの強制適用 まとめ Salesforce のアプリケーション管理は、これまで手動オペレーションに依存しがちな領域でした。今回、その設定を GitHub Workflow で自動反映できるようにしつつ、2GP への対応も実現できました。 運用後に新たな課題なども出てくるかもしれませんが、そちらはまた別の記事でご紹介できればと思います。