【図解】Salesforce CLI の始め方:インストール、組織への認証、sf コマンド、生成 AI との安全な組み合わせ

このページには広告リンクを含みます。

Salesforce CLI とは:sf コマンドでできること

Salesforce CLI は、コマンドで組織を操作するツールです。画面で1つずつ行う作業を、記録の残る手順にできます。使う場面は次の3つです。

  • 調べる:SOQL でレコードを取り出す、組織の情報を見る
  • 取得とデプロイ:Apex やフローなどのメタデータを手元に落とし、組織へ反映する
  • 自動化:テストやデプロイを CI のスクリプトに組み込む

試す組織がなければ、先に Developer Edition を用意します。本番では試しません。

インストール、組織への認証、プロジェクト作成、メタデータの取得、編集、デプロイの順に並べ、デプロイの手前に確認の工程を置いた流れ図
CLI の作業は取得してからデプロイする順に進む

Salesforce CLI のインストール

インストール方法は環境で選びます。公式は、同じ PC で複数の方法を混ぜないよう注意しています。パスが食い違い、エラーが出ないまま動きがおかしくなるためです。

方法 向いている場面 手順の要点
macOS の pkg 個人の Mac CPU に合う pkg を入れ、ターミナルを開き直す
Windows の exe 個人の Windows exe を実行し、コマンドプロンプトや IDE を開き直す
npm 管理者権限がない、CI で使う Node.js の Active LTS を入れ、npm install @salesforce/cli --global
TAR ファイル Linux、CI 展開して bin を PATH に追加する

Windows では、コマンドプロンプトか PowerShell を使います。公式は WSL などのターミナルを勧めていません。npm で権限エラーが出ても、sudo は使わないよう案内されています。

入ったら2つのコマンドで確かめます。

sf --version
sf plugins --core

旧 sfdx コマンドから sf への移行

古い記事の sfdx force:... を見て戸惑うことがあります。今の主役は sf (v2) です。

  • 入れ替えの順番:sfdx (v7) を消してから sf (v2) を入れます。逆だとインストールエラーになることがあります。
  • 確かめ方:sfdx version の結果が sfdx-cli/7 で始まれば、旧版が入っています。
  • 既存のコマンド:sf (v2) では sfdx が sf の別名になります。移行ガイドは、これまでのスクリプトも動くとしています。ただしこれは呼び名の話です。force:source:push、force:source:deploy、force:mdapi:deploy など force:source と force:mdapi の古いコマンドは、2024年11月の 2.65.8 で削除されました。古いスクリプトにあれば書き換えます。
  • CI:npm install sfdx-cli --global の行を消します。残すと sf (v2) のインストールが失敗します。
  • 移行後:sf autocomplete --refresh-cache を実行し、新しいターミナルを開きます。

新しく書くコマンドは sf の形にそろえます。sf data query の旧名 force:data:soql:query のように別名が残るものもありますが、全部ではなく、これから覚える必要もありません。

組織への認証:sf org login web

認証は組織ごとに一度行えば、以後は別名で呼び出せます。更新トークンの期限を決めた組織では、切れたら認証し直します。Sandbox なら、ログイン URL を指定します。

sf org login web --alias dev-sandbox --instance-url https://MyDomainName--SandboxName.sandbox.my.salesforce.com

ブラウザが開くのでログインし、「許可」を押します。ハマりやすい点は次のとおりです。

  • 認証には「Approve Uninstalled Connected Apps」の権限が要ります。管理者には既定で付いています。
  • URL は my.salesforce.com で終わる形を使います。Lightning の画面の lightning.force.com ではありません。
  • 別名(alias)を必ず付けます。編集部のおすすめは prod-main のように本番と分かる名前で、本番は既定の組織にしません。

作業前に、接続先を確かめます。

sf org list
sf org display --target-org dev-sandbox

よく使うコマンド:SOQL の実行

SOQL の書き方は SOQL の基本で扱います。ここでは実行の仕方だけ見ます。

sf data query --query "SELECT Id, Name FROM Account LIMIT 10" --target-org dev-sandbox
sf data query --file query.txt --result-format csv --output-file output.csv --target-org dev-sandbox

10,000件を超える見込みなら、公式は sf data export bulk を勧めています。Bulk API 2.0 で動くためです。CSV を使った一括の更新は sf data update bulk などでも行えますが、初めてなら画面で進む データローダーのほうが確認しやすいです。

メタデータの取得とデプロイ

メタデータを扱うには、DX プロジェクトが必要です。

sf template generate project --name my-project
cd my-project
sf project retrieve start --metadata ApexClass --target-org dev-sandbox

手元で編集したら、組織へ反映します。

sf project deploy start --source-dir force-app --target-org dev-sandbox

Sandbox とスクラッチ組織では、既定で変更の追跡(ソーストラッキング)が効きます。本番組織では効きません。デプロイのオプションで、特に注意するものを挙げます。

オプション 働き 注意
--dry-run 検証だけ行い、組織に保存しない 最初に使う。Sandbox は既定でテストが動かないので --test-level も付ける
--ignore-conflicts 組織側の変更を上書きしてでもデプロイする 組織の変更が消える。追跡できる組織でだけ効く
--ignore-errors エラーを無視し、ロールバックしない 公式が本番では絶対に使うなと明記
--purge-on-delete 削除対象をごみ箱に入れない 破壊的変更で使う。戻せない
--test-level Apex テストの範囲を指定する NoTestRun は開発環境向け。Apex を含む本番デプロイの既定は RunLocalTests

本番は検証と本番反映を分けます。sf project deploy validate は Apex テストまで実行し、ジョブ ID を返します。ID は10日間有効で、sf project deploy quick に渡すと反映されます。どちらも本番組織向けで、公式は Sandbox で使わないよう書いています。Sandbox で同じ確認をするなら sf project deploy start --dry-run --test-level RunLocalTests を使います。

sf project deploy validate --source-dir force-app --test-level RunLocalTests --target-org prod-main
sf project deploy quick --job-id ジョブID --target-org prod-main

Claude Code など生成 AI と CLI を組み合わせる

Claude Code のようなコーディングツールは、ターミナルのコマンドを実行できます。つまり CLI と組み合わせると、AI があなたの権限で組織に触れます。便利なのは事実で、線引きが要るのも同じ理由です。

Salesforce の公式の選択肢は、2026年10月31日時点で次のとおりです。

名前 内容 現状
Agentforce Vibes VS Code 拡張のコーディングエージェント。Salesforce Extension Pack に含まれる 提供中。権限モードと計画モードがある
スキルとプラグイン Salesforce の作業手順を AI に教える公開パッケージ(forcedotcom/sf-skills)。Claude Code には公式の salesforce-development プラグインもある 提供中
Salesforce Hosted MCP Servers 組織側で設定し、Claude などの MCP クライアントをユーザーごとの OAuth で接続する 提供中
Salesforce DX MCP Server 手元で動く npm パッケージ @salesforce/mcp 2026年11月2日にサポート終了(End of Life)。以後は更新なし。公式はスキルへの移行を案内

DX MCP Server の開発者ガイドには、終了の案内がまだありません(確認日 2026-10-31)。終了は Salesforce の公式リポジトリの告知と README に書かれています。リポジトリはアーカイブされ、npm パッケージは非推奨になりますが、入れることはでき、バージョンを固定した今の設定も動き続けます。ただし修正も新しい版も出ません。新しく組み込むならスキルを使い、AI クライアントから組織につなぐ用途なら Hosted MCP も候補にします。この選び方は編集部のおすすめです。

AIに任せる作業、人が確認して任せる作業、人だけが実行する作業を3段に分け、本番へのデプロイと接続情報の表示を最下段に置いた図
線を引く基準は、接続先と戻せるかどうか

AI に任せてよい作業と任せない作業

編集部の基準は次の3段です。根拠は Agentforce Vibes の公式ガイドの考え方で、エージェントの権限は低いところから広げること、生成物は必ず人が見ることです。

段階 作業の例 実行する人
任せる 手元のコードの解説、レビュー、顧客データのない Sandbox への読み取りクエリ、デバッグログの分析 AI
確認して任せる テストの生成、Sandbox へのデプロイ、Apex テストの実行 AI(1回ずつ承認)
任せない 本番へのデプロイとデータ更新、削除、--ignore-errors、接続情報の表示 人だけ

読み取りにも注意点があります。クエリの結果は AI の入力になります。Agentforce Vibes は、Einstein Trust Layer が個人情報などをマスクできると説明していますが、これは Vibes の話で、マスクが有効なときに限ります。ほかのツールでも同じ保護が効くとは限らないので、本番の顧客データを読ませない運用にします。

Sandbox でも油断できません。Full Sandbox には本番の全データが、Partial Copy にはサンプルのデータがコピーされます。AI につなぐなら、メタデータだけの Developer や Developer Pro の Sandbox を選びます。

接続情報の扱い

CLI の認証情報は、組織へのログイン情報と同じ重さです。

  • sf org display と sf org list は、今はトークンを表示しません。表示には sf org auth show-access-token などの専用コマンドを使います。
  • この専用コマンドは確認を挟みますが、--json や --no-prompt を付けると確認を飛ばせます。AI の自動実行の許可リストに入れないでください。
  • CI 用の authFile.json には認証用 URL が入ります。リポジトリに入れず、AI に読ませないようにします。
  • 既定の接続アプリケーション Salesforce CLI は、更新トークンとアクセストークンが無期限の設定です。公式は更新トークンを90日以下、セッションを15分にするよう案内しています。作業は管理者が行います。
  • 使わなくなった組織は sf org logout --target-org 別名 で外します。AI を動かす PC に本番の認証を残さないのが一番確実です。

Hosted MCP は接続したユーザーの権限で動きます。項目レベルセキュリティや共有ルールは守られますが、そのユーザーができる操作は AI にもできます。ツールの「読み取り専用」といった注釈も強制力はないと公式が書いています。接続には権限を絞ったユーザーを使うのが編集部のおすすめです。

Sandbox で試す手順

AI との作業は次の順にします。手順は編集部のおすすめで、コマンドは公式のリファレンスに基づきます。

Sandboxで取得、AIが手元を編集、差分を人が確認、Sandboxへデプロイとテスト、本番はvalidateからquickを人が実行する流れを、AIと人の担当で色分けした図
AI が触るのは手元と Sandbox まで。本番の反映は人が行う
  1. 接続先を限る:この PC では Sandbox だけを認証し、sf org list で確かめます。
  2. 手元に取得する:sf project retrieve start で取得し、Git に記録します。
  3. ブランチを切って AI に頼む:作業の範囲とファイルを具体的に伝えます。
  4. 差分を人が読む:公式の確認項目は、SOQL と DML がループの外にあるか、テストが一括の場合を含むか、参照先の項目が揃っているかなどです。ループ内の更新の問題はここで止めます。
  5. Sandbox で確かめる:--dry-run --test-level RunLocalTests の後にデプロイし、Apex テストと画面の動作を見ます。
  6. 本番は人が反映する:別の端末や CI から validate と quick を実行します。

関連記事

よくある質問

Salesforce CLI とは何ですか?
Salesforce CLI は、ターミナルから sf コマンドで組織に接続し、SOQL の実行、メタデータの取得とデプロイ、テストの実行などを行う公式の開発ツールです。
Salesforce CLI のインストール方法はどれを選べばよいですか?
個人の PC なら macOS の pkg、Windows の exe が手軽です。管理者権限がない場合や CI では Node.js の npm を使います。どちらか一方だけにし、同じ PC で併用しないでください。
sfdx コマンドは今も使えますか?
sf (v2) を入れると sfdx は sf の別名になるため、sfdx と打っても動きます。ただし force:source:push などの古いコマンドは削除済みなので、sf の形に書き換えます。古い sfdx (v7) が残っている場合は、先にアンインストールしてから sf (v2) を入れます。
Claude Code などの生成 AI に Salesforce CLI を使わせても安全ですか?
手元のコードの分析と、顧客データを含まない Sandbox での作業なら使えます。本番組織への書き込みとデプロイは人が内容を確かめて実行し、アクセストークンなどの接続情報は AI に渡さないようにします。