1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【備忘録】Agentforce Coworkerを試す前に整理する - 普通のAgentforceとの違いと導入前チェック

1
Posted at

はじめに

fig_01.jpg

Salesforce Blogで、Agentforce Coworker が「AI teammate」として紹介されていました。日本でも2026年8月5日に一般提供開始が発表されています。

ここで最初に引っかかったのが、「これは今までのAgentforceと何が違うのか」 でした。Agentforceは元々「AIエージェントを作るためのプラットフォーム」です。そこに「AI同僚」が加わると言われても、自分で作るエージェントとの関係が分かりません。

この記事では、機能紹介を細かく追うというより、Salesforce管理者・開発者が 普通のAgentforce(自分で作るエージェント)とCoworkerの違いを押さえたうえで、業務に入れる前に何を確認すると安全か を整理します。

※本記事は個人の整理メモです。2026-08-19時点で確認できたSalesforce公式情報をもとにしています。ライセンス、提供地域、組織ごとの利用可否、管理画面上の設定名は変更される可能性があるため、実際に有効化する前に自社組織のHelp/Docs/契約条件で確認してください。

この記事で扱う範囲

fig_01_scope.png

この記事の主題は、Agentforce Coworkerそのものの使い方手順ではなく、普通のAgentforceとの違いの整理導入前チェックリストです。

扱うこと:

  • 普通のAgentforce(自分で作るエージェント)とCoworkerの役割の違い
  • Agentforce Coworkerをどう捉えるとよさそうか
  • GA / Beta / 提供予定の表現を、チャネルごとに分けて読む方法
  • 権限、データ範囲、実行アクション、監査、ユーザー教育の確認観点
  • 本番導入前にSandboxなどで確認したいこと

扱わないこと:

  • 実組織での有効化手順の再現
  • SKUや料金の断定
  • 実行結果の検証済みレビュー

Agentforce Coworkerをどう捉えるか

fig_02_what_is.png

Salesforce Blogでは、Agentforce Coworkerを単なる検索バーではなく、Salesforce内外の業務文脈を使って回答やアクションにつなげる「AI teammate (チームメイト)」として説明しています。

たとえば公式では、次のような要素が説明されています。

  • Salesforce上のアカウント、商談、ケース、契約、サービス履歴などの業務文脈を使う
  • Data 360によりビジネスコンテキストへ接続する
  • グローバル検索バーの 「Ask」 が入口になる(キーワードではなく自然言語で聞く)
  • 回答の根拠となったデータソースを示す(source-grounded な)回答を返す
  • Agentforce agents、カスタムエージェント、CRM actions、Flows、外部API、外部システムなどをオーケストレーションする
  • Salesforceの検索バー、Slack、Microsoft Teams、ChatGPT、Claude、デスクトップアプリなど複数の場所から利用する構想が説明されている
  • 権限、ポリシー、ガバナンス制御の範囲で動作する、と説明されている

「270超のデータソース」は打ち出しであって、初期状態ではない

打ち出しとしては、CRM、Slack、およびData 360経由で接続されたデータレイク/データウェアハウスなど270を超えるエンタープライズソースを横断検索する、と説明されています。

ただし、ここは導入前チェックの観点だと分けて読む必要があります。公式ドキュメントの課金に関する説明では Slack (Optional) という書き方がされており、有効化した直後に検索されるのはSalesforce CRMで、Slackは任意で追加するソースという位置づけになっています。それ以外の外部ソースは、Data 360側で接続してインデックスを作る作業が別途必要です。

つまり、

  • 今日の検索範囲は、自組織がData 360に何を接続したかで決まる
  • 270超は、接続すれば届きうる範囲の話

という2段構えで読むのが安全です。逆に言えば、接続を増やすほど検索範囲もコストも増えるので、「どのソースを接続するか」はセキュリティの議論とコストの議論を同時にやる必要があります。

一方で、回答が source-grounded である(根拠のデータソースを示す)という設計は、検証する側にとっては助けになります。「なぜその回答になったのか」を追う入口が、回答自体に含まれるからです。

ここで重要なのは、「便利そう」より先に、誰の権限で、どのデータを読み、どのアクションを実行できるのか を確認することだと思います。

普通のAgentforceとの違い

fig_03_vs_agentforce.png

いちばん整理しておきたいのがここです。「Agentforce Coworkerを入れる」と「Agentforceでエージェントを作る」は、代替関係ではなく前後関係にあります。

一言でいうと

  • 普通のAgentforce: 用途ごとに、自分で設計して作る専門エージェント
  • Agentforce Coworker: 既製で提供され、全社の単一の入口になり、必要に応じて上のエージェントへ振り分けるもの

公式は Coworker を 「あなたのチームが作るすべてのエージェントへの単一の入口(single entry point)」 と説明しています。エージェントが増えるほど、どの専門エージェントを起動すべきかをCoworker側が判断していく、という位置づけです。

対比表

観点 普通のAgentforce(自分で作るエージェント) Agentforce Coworker
立ち上げ方 Agentforce Studio / Agentforce Builder で、トピック・アクション・指示を設計して作る Setupでトグルを入れて有効化する。既存のメタデータ・共有ルール・ガバナンス設定を継承する
誰が用意するか 管理者・開発者が用途ごとに設計する 有効化時に Agentforce Coworker Agent が自動で作成される
ユーザーから見た入口 配置したチャネル・ページ・APIごと グローバル検索バーの「Ask」 が全社共通の入口
役割 特定業務の専門ワーカー オーケストレーター(要求に応じて既存エージェント・Flow・アクション・外部APIへ振り分ける)
起動のきっかけ 会話に加え、データ変更・業務ルール・自動化・API呼び出しなどからも起動しうる 会話に加え、能動通知(変化を検知して先回りで知らせる)
検索の基盤 必ずしもData 360の検索インデックス前提ではない Data 360を基盤として検索環境が構成される(Salesforce CRMは既定で接続。追加DMO・外部ソースは必要に応じて追加)
提供段階 プラットフォーム機能として提供済み 日本では2026-08-05に一般提供開始が発表。ただしチャネルごとに段階が異なる(後述)
課金の考え方 本記事では断定しない 本記事では断定しない。専用の Billing Considerations ドキュメントがある

実務上いちばん効いてくる違い

「作らなくていい」は、「品質を作り込まなくていい」ではありません

Coworkerは、組織がすでに作ってあるエージェントへ振り分けます。したがって、既存エージェントのスコープや名前が曖昧だと、振り分けが期待どおりに動きません。「Coworkerを入れたのに使えない」という話になったとき、原因がCoworker側ではなく既存エージェント側にある、というケースがありえます。

つまり、Coworker導入は次の2つを同時に持ち込みます。

  1. 既製エージェントが1つ増える(Coworker Agent 本体)
  2. 既存エージェント群が「呼ばれる側」になる(設計品質がそのまま体験に出る)

Agentforceを既に使っている組織ほど、2番目の棚卸しが重要になります。逆にAgentforceのエージェントをまだ作っていない組織では、Coworkerは主に「検索と要約とアクション実行の入口」として振る舞うことになります。

もう1つの違い: プラットフォーム側が一緒にONになる

後述しますが、Agentforce Coworkerを有効化すると Agentforce Studio(Agentforceプラットフォーム)も自動的に有効化されると案内されています。

「Agentforceのエージェントは作っていないので関係ない」と思っている組織でも、Coworkerの有効化はプラットフォーム側の有効化を伴います。ここは「普通のAgentforceとは別物だから影響がない」と読み違えやすいところです。

GA / Beta / 提供チャネルを分けて読む

fig_04_ga_beta.png

提供状況の表現は、時期・地域・チャネルで分かれています。

発表と提供段階の時系列(2026-08-19時点で確認できた範囲)

時期 内容
2026年6月10日 Salesforceブログ(日本)で紹介。Salesforce Lightning はベータ提供中、他チャネルは提供予定として案内
2026年7月15日 セールスフォース・ジャパンが日本向けに発表。**「現在、ベータ提供中」**と記載
2026年8月5日 セールスフォース・ジャパンが日本市場での一般提供開始を発表

同じ製品でも、参照する情報の時点によって「ベータ」と「一般提供」の表記が変わります。 7月の情報だけを読むとベータ、8月の情報を読むと一般提供です。記事を書くときはどの時点のどの情報源かを必ず添えるのが安全です。

なお、英語の公式Blogでは、冒頭に Agentforce Coworker is Generally Available. と書かれている一方、同じページの availability の箇所には Agentforce Coworker is in beta for Salesforce today と記載されています。同一の公式ページ内でもGA / betaの表現が混在しているため、提供状況を確認するときは、情報源・更新時点・対象チャネルを分けて読むのが安全です。

チャネルごとの段階(日本語プレスリリースの案内)

日本語のプレスリリースでは、利用チャネルごとに提供段階が分けて説明されています。

チャネル 案内されている段階
Salesforce Lightning ベータ提供中
Microsoft Teams / Web / Experience Portals 2026年夏予定
ChatGPT / Claude / デスクトップアプリ(Mac) 2026年秋予定
Slack 検索ソースとして任意で追加できると案内。チャネルとしての段階は予定表に明記なし

「製品としては一般提供、ただし主要チャネルはベータまたは提供予定」という状態です。「GAと書いてあるから、すべてのチャネルで今すぐ同じように使える」とは書かないほうがよさそうです。

なお、2026-08-19時点では、英語版のDeveloper Docsでは一部ページからBeta表記が外れている一方、日本語版のDeveloper Docsには「(ベータ)」表記が残っているページもあります。製品全体の提供段階だけでなく、機能・言語版・ドキュメントの更新時点を分けて確認するのが安全です。

一次情報の置き所

Blog以外に Agentforce Coworker専用の開発者ドキュメントdeveloper.salesforce.com/docs/data/agentforce-coworker/)が公開されています。提供段階や設定の詳細はBlogではなくこちらを一次情報にするのが安全です。日本語の情報は、セールスフォース・ジャパンのプレスリリースとブログが基準になります。

有効化に必要な権限と、その副作用

fig_05_enable.png

「試す前に整理する」という観点でいちばん先に見ておきたいのが、有効化の手順そのものです。有効化は数分で終わると案内されている一方で、副作用と必要権限があるためです。

その前に: 自分でONにしなくても有効化されている場合がある

手順の話をする前に、先に確認したいことがあります。

2026年8月4日から、対象となるユーザーベースAI権利(Unmetered User-Based AI Entitlements)を持つユーザーについて、Agentforce Coworker の自動有効化が段階的に開始されていると案内されています。対象ユーザーの画面には、Ask ボタンなどが自動的に表示される場合があります

つまり「まだONにしていないから、自社組織には関係ない」とは限りません。Salesforce Help には FAQs: Agentforce Coworker Automatic Enablement という専用の記事が用意されているので、まず自社組織ですでに有効化されていないかを、Setup と契約状況の両面から確認してください。

「試す前に整理する」記事として、これはいちばん先に確認すべき項目です。検証計画を立てている間に、本番組織のユーザーにはもう見えている、という状態がありえます。

手順は短い

公式ドキュメントで案内されている流れは次のとおりです。

  1. Setup を開く
  2. Quick Find に Agentforce Coworker と入力する
  3. Get Started with Agentforce Coworker を選ぶ
  4. Turn On をクリックする
  5. 確認ダイアログで Confirm を選ぶ

トグルを入れるだけで、複雑な構成なしに2〜3分程度で展開できる、と説明されています。ただしトグルの時間と、使える状態になるまでの時間は別です。検索インデックスの構築時間は、Data 360側のデータ量に依存します。

有効化ボタン1つで、裏側で複数の設定が動く

短いぶん、次の点を先に共有しておかないと事故になります。有効化すると、案内されている範囲では次が自動的に行われます。

自動で行われること 見ておきたい理由
Einstein が自動的に有効化される Einsteinをまだ有効にしていない組織では、意図しない変更になりうる
Agentforce Studio(Agentforceプラットフォーム)が有効化される 「エージェントは作っていない」組織でもプラットフォームがONになる
Salesforce CRM への接続が構成される 既定の検索対象がCRMになる
検索メソッド(検索基盤)が設定される Agentforce Coworker用の検索インフラストラクチャが構成される
Agentforce Coworker Agent が作成される 組織にエージェントが1つ増える。棚卸し対象になる
権限セットグループなどのアセットが作成される 権限まわりの実体が自動生成される

有効化はあくまで組織全体の設定です。「試しにオンにしてみる」を本番組織でやる前に、Sandboxで影響範囲を確認するのが安全です。

追加で必要になる設定

トグルだけで終わらない点も案内されています。

  • 最新の機能を利用する場合は、Einstein設定の Turn on Beta Generative AI Models を有効にするよう案内されています
  • 利用ユーザーへの権限割り当てをしないと、ユーザーの画面にAgentforce Coworkerが表示されません

必要な権限

案内されている権限まわりを整理すると、次のようになります。

役割 必要とされるもの
有効化する管理者 System Administrator であること。加えて Agentforce Coworker Admin 権限セットを自分に割り当てる(必要な権限セットライセンスが自動で付く)
構成担当 Data 360 Admin または Data 360 Architect
利用ユーザー 権限セットグループと、対応する権限セットライセンスの割り当て。公式は Agentforce Coworker Setup の Manage Users セクションから割り当てることを推奨している
Edition Enterprise / Unlimited / Agentforce 1 Edition で利用可能と案内されている(自社契約で要確認)

利用ユーザー向けの権限セットグループは、公式情報の中で Access_Ai_Search(API名)と Agentforce Coworker User の両方の表記が見られます。 開発者ドキュメントは Access_Ai_Search (API Name) Permission Set Group という書き方をしており、表示名とAPI名の違いである可能性があります。いずれにせよ、実際に割り当てるときは自社組織の Manage Users / Setup 画面で確認してください。

いずれにせよ実務上のポイントは同じで、権限セットグループを直接割り当てる運用にすると、Setup側の管理画面と実態がずれる可能性があるということです。公式が推奨している経路(Manage Users)に寄せておくと、後から棚卸ししやすくなります。

なお、アクセスを外すときは権限セットグループと権限セットライセンスの両方を外す必要がある、という注意も案内されています。片方だけ外して「外したつもり」になるパターンに注意が必要です。

ガバナンスの前提

公式の説明では、次の2点が前提として示されています。

  • すべてのアクションは Einstein Trust Layer によって統制され、監査証跡(audit trail)に記録される
  • Agentforce Coworker は、組織にすでに設定されているセキュリティとガバナンスの設定を自動的に継承する。そのうえで、エージェント固有の設定オプションもある

つまり「既存の権限設計をゼロから作り直す」話ではなく、既存設計がそのまま効く。だからこそ既存設計の穴もそのまま効く、という読み方になります。次章以降のチェックリストが必要になる理由もここにあります。

会話以外の面も見る

fig_06_beyond_chat.png

Agentforce Coworker を「聞いたら答えてくれるもの」として捉えると、確認漏れが出ます。公式の説明には、会話以外の動き方も含まれています。

内容 確認したいこと
能動通知 商談ステータスの変化や重要なメッセージなど、変化を検知して能動的に通知する 誰に、どの条件で、どの情報が通知されるか。通知経路のログは残るか
承認フロー 自動化されたタスクに対する人間の承認フローをサポートする どの操作に承認を挟むか。承認者は誰か。承認なしで通る操作はあるか
文脈保持 会話が継続し、文脈が保持される どこまで保持されるか。保持された文脈にどの範囲のデータが含まれるか

能動通知は、ユーザーが依頼していないのにエージェントが動く面です。「依頼したことだけをやる」という前提でレビュー設計を組むと、この面が抜けます。ここは普通のAgentforceのエージェントにも通じる話ですが、Coworkerは全社の単一の入口になるぶん、影響範囲が広くなります。

文脈保持も同様に、単発の会話を前提にしたデータ境界の議論では扱いきれません。「1回の質問では見えない情報でも、会話を重ねるうちに文脈として蓄積されないか」という観点が要ります。

導入前チェックリスト

1. データ権限: AIが見える範囲を人間の権限と同じ粒度で確認する

Agentforce Coworkerは、顧客情報、商談、ケース、サービス履歴などの業務文脈を使う説明になっています。

そのため、まず確認したいのは次の点です。

  • 自社組織ですでに有効化されていないか(自動有効化の対象になっていないか)
  • 対象ユーザーのプロファイル、権限セット、権限セットグループ
  • オブジェクト権限、項目レベルセキュリティ、レコード共有
  • 機密項目や個人情報を含むオブジェクトへのアクセス範囲
  • いまData 360に接続しているソースは何か(既定はSalesforce CRM。Slackは任意追加)
  • 今後接続する予定のソースと、接続しないと決めるソース

Salesforceの権限は、プロファイル、権限セット、項目レベルセキュリティ、共有設定など複数の層で決まります。Agentforce Coworkerはこの既存設定を自動的に継承すると説明されているため、導入時にまずやることは新しい権限設計ではなく、既存の権限設計の棚卸しです。既存設計に穴があれば、そのまま引き継がれます。

2. 既存エージェントの棚卸し: 「呼ばれる側」の設計を見る

これはCoworker特有の観点です。Coworkerは既存のAgentforceエージェントへ振り分けるため、既存エージェントの設計品質がそのままCoworkerの挙動に出ます

  • 既存エージェントの名前・説明・スコープは、用途が判別できる粒度になっているか
  • 似た役割のエージェントが重複していないか(振り分けが不安定になる)
  • 各エージェントが持つアクションの実行範囲は把握できているか
  • 非推奨・作りかけ・検証用のエージェントが本番組織に残っていないか
  • 有効化で自動作成される Agentforce Coworker Agent 自体を、誰が管理するか

3. 実行範囲: 「読む」だけか、「作る・更新する」まで許すか

公式では、Agentforce CoworkerがAgentforce agents、カスタムエージェント、CRM actions、Flows、外部APIなどを呼び出して作業を進める説明があります。

ここは特に慎重に切り分けたいところです。

確認観点
読み取り 顧客履歴、商談状況、ケース履歴を要約する
下書き作成 メール、提案文、次アクション案を作る
Salesforce更新 レコード作成、項目更新、ケース更新など
外部連携 外部API、外部システム、Slackなどへの連携
承認・確認 人間の確認を必須にするか、自動実行を許すか

承認については、自動化されたタスクに対する人間の承認フローがサポートされていると説明されています。「承認を挟めるか」は既に答えが出ているので、確認すべきはどの操作に承認を挟む設定にするか承認なしで通る操作が残っていないかのほうです。

最初から広い実行権限を与えるのではなく、読み取り・下書き・人間確認付き更新・自動更新のように段階を分けると、安全に検証しやすいです。

4. 監査と観測性: 何が起きたかを後から追えるようにする

公式では、built-in observability により、何が起きているか、なぜそうなったか、次に何をすべきかを可視化する説明があります。公式ドキュメント側にも、すべてのアクションは Einstein Trust Layer によって統制され、監査証跡に記録されるという説明があります。

したがって「ログが残るか」ではなく、残ったログで自社の運用要件を満たせるかが確認の焦点になります。

  • どのユーザーがAIに何を依頼したか
  • どのデータを参照したか(回答が source-grounded である点は、この確認の助けになる)
  • どのエージェントへ振り分けられたか(Coworkerはオーケストレーターなので、ここが追えないと原因究明ができない)
  • どのFlow、アクション、外部APIが呼ばれたか
  • 実行前に人間の確認が入ったか
  • 能動通知が発生した場合、それも追えるか(依頼のない動きもログに残るか)
  • 失敗時や誤実行時に、どこまで追跡・取り消し・再発防止できるか
  • 監査証跡の保持期間が、自社の監査要件と合っているか

「AIが回答したか」だけでなく、「AIが業務プロセスのどこまで関与したか」を追える状態にしておくことが重要です。

5. チャネル: Salesforce内と外部チャネルを分けて確認する

Agentforce Coworkerは、Salesforce内だけでなく、Slack、Microsoft Teams、ChatGPT、Claudeなどに広がる構想として紹介されています。

ただし、前述の通り、チャネルごとに提供段階が分かれています

そのため、確認観点は次のように分けるとよさそうです。

  • Salesforce内で利用する場合の権限と監査
  • Slackなど社内コラボレーションツールから使う場合の認証・ログ・表示範囲
  • ChatGPT / Claudeなど外部AIクライアント連携時のデータ境界
  • モバイルやデスクトップアプリでの利用可否
  • チャネルごとの提供段階、管理者設定、利用条件

特に外部チャネルでは、「Salesforce内の権限で守られる」という説明だけで安心せず、チャネル側のワークスペース権限、ログ保持、データ取り扱いも確認したいです。

6. ユーザー教育: AI同僚に頼んでよい仕事を明文化する

Agentforce Coworkerのような仕組みは、ユーザーから見ると「いつもの会話で仕事を頼める」体験に近づきます。しかも入口が検索バーなので、「検索したつもりが実行になっていた」という誤解が起きやすい面があります。

そのぶん、利用者に対して次を明文化しておくとよさそうです。

  • 入力してよい情報、入力してはいけない情報
  • AIの回答をそのまま顧客に送ってよいか
  • 更新・送信・承認が必要な作業では、どこで人間確認を入れるか
  • 誤った回答や不自然な提案を見つけたときの報告先
  • 本番データで試してよい範囲と、Sandboxで試すべき範囲

AIの性能だけでなく、利用者の期待値を揃えることも導入リスクを下げるポイントです。

Sandboxで先に確認したいシナリオ

可能であれば、本番前にSandboxなどの検証環境で次のようなシナリオを確認したいです。

  1. 権限の狭いユーザーで、見えてはいけない商談・ケース・項目が回答に出ないこと
  2. 権限の広い管理者で、機密データが必要以上に要約・露出されないこと
  3. 下書き生成とレコード更新の境界が分かること
  4. Flowや外部APIを呼び出す場合、実行前後のログを追えること
  5. Slackなど外部チャネルを使う場合、チャネル側の公開範囲とログ保持を確認できること
  6. 誤った依頼、曖昧な依頼、権限外の依頼に対して安全に失敗すること
  7. 有効化そのものの影響(Einstein と Agentforce Studio が同時に有効化され、Coworker Agent が作成される点を含む)を、本番に入れる前に確認できること
  8. 会話を重ねたときに、単発では見えないはずの情報が文脈として蓄積されないこと
  9. 能動通知が、想定した相手・条件・内容で発生すること
  10. 既存エージェントが複数あるとき、意図したエージェントへ振り分けられること(振り分け先がログで追えること)
  11. 権限を外したユーザーが、確かに使えなくなること(権限セットグループとライセンスの両方を外す)
  12. 本番組織の現状(自動有効化によって、すでに表示されているユーザーがいないか)

ここまで確認できると、「使えるか」だけでなく、「運用に入れてよいか」を判断しやすくなります。

まとめ

fig_10_summary.png

Agentforce Coworkerは、普通のAgentforce(自分で作るエージェント)を置き換えるものではなく、その前に立つ単一の入口として紹介されています。

導入前には次を分けて確認するのが大事だと感じました。

  • すでに有効化されていないか(2026年8月4日から、対象ユーザーへの自動有効化が段階的に始まっている)
  • 普通のAgentforceとの関係(Coworkerは振り分ける側。既存エージェントの設計品質がそのまま出る)
  • 提供段階(製品としてはGA発表済みだが、チャネルごとに beta / 提供予定が分かれる)
  • 有効化の副作用(Einstein と Agentforce Studio が同時に有効化され、Coworker Agent と権限アセットが作られる)
  • ユーザー権限、項目レベルセキュリティ、共有設定(既存設定がそのまま継承される
  • データソースの範囲(既定はCRM。Slackは任意追加。270超は接続すれば届きうる範囲)
  • 読み取り、下書き、更新、外部連携の実行範囲と、承認フローをどこに置くか
  • 監査ログや観測性(記録されること自体は前提。内容が要件を満たすかを見る
  • 会話以外の面(能動通知、文脈保持)
  • Slackなど外部チャネル利用時のデータ境界
  • 利用者向けのルールと教育

まずは「何ができるか」よりも、「どこまで任せてよいか」を棚卸しするところから始めると、Agentforce Coworkerを安全に検討しやすそうです。既存の権限設計とエージェント設計を継承する仕組みである以上、棚卸しの対象は新機能ではなく、いまの自社組織になります。

参考(公式情報)

注記

提供段階、権限セットグループの名称、課金の条件、自動有効化の対象は変わりやすい領域です。有効化する前(またはすでに有効化されていないかを確認するとき)に、自社組織のSetupと公式ドキュメントで次を確認してください。

  • 自社組織ですでに Agentforce Coworker が有効化されていないか(自動有効化の対象になっていないか)
  • 利用ユーザーへ割り当てる権限セットグループ/権限セットライセンスの正確な名称
  • Einstein および Agentforce Studio が同時に有効化されることの、自社組織における影響範囲
  • 監査証跡に記録される項目と保持期間
  • チャネルごとの提供段階の現況(本記事の「提供予定」は執筆時点の案内です)
  • 自社Edition・契約での利用可否と課金の扱い
1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?