Dustを全社に配る前の確認項目一覧｜作る人と使う人を分ける

「社員が自分でエージェントを作れるようになれば、現場のAI活用は勝手に広がるはずだ」「でも、誰が何を作って、どの社内データにつないでいるのか、後から追えるのだろうか」——社内のAI活用を任された情報システム部門やAI推進の担当者から、期待と不安が同時に聞こえてきます。作れる人を増やせば活用が進む、と考えたくなるのは自然なことです。けれども、それは半分しか当たっていません。本当は、作る人と使う人の権限、つなぐデータの範囲を先に分けておかないと、持ち主の分からないエージェントが増えるだけです。この記事では、社員がエージェントを作って共有する基盤 Dust を例に、全社に配る前に決めておく項目を、2026年10月時点の公式ドキュメントをもとに確認項目の形で整理します。

Dustは何をする基盤か

Dust は、主要な生成AIのモデルの上に、社内のデータとつながったエージェントを作るための基盤です。2026年10月時点の公式ドキュメントでは、社内の文書をもとに答える既定のエージェントがあり、社員はそれとは別に、自分の仕事に合わせたエージェントを作れると説明されています。エージェントは名前で呼び出して使い、1つの会話の中で複数のエージェントを呼んで一緒に作業させることもできます。

作ったエージェントは、同僚が探して使えます。公式ドキュメントによれば、同僚が作ったエージェントの一覧を見て、その指示の内容、使っている道具、利用の状況を確かめられます。エージェントを作る人と使う人が別々にいることを前提にした作りになっているのが、個人向けの対話型のAIとの大きな違いです。

呼び出す場所も複数あります。公式ドキュメントには、ウェブの画面のほか、Chrome などのブラウザの拡張機能、Slack、API、MCP サーバーとしての利用が並んでいます。使うモデルも一つに縛られず、複数の提供元のモデルを選べる作りで、モデルの提供元の管理は管理者だけが行える権限として分けられています。

つまり Dust は、社員一人ひとりの対話の道具というより、社内のデータ・外部の道具・モデルを束ねて、部署ごとのエージェントを作って配る土台です。土台であるからこそ、配る前の設定が、そのまま全社のデータの見え方を決めます。

作っている会社と、国内でまだ知られていない理由

Dust はフランスのパリで創業した会社です。2023年の公式ブログのシード資金の発表では、パリを拠点とする会社として紹介されています。2026年5月18日には、公式ブログで4,000万ドルのシリーズBの資金調達を発表しました。同じ発表で、3,000を超える組織が Dust を使い、30万を超えるエージェントが作られたと提供元は説明しています。2026年10月15日時点で、提供終了・名称変更・買収の告知は見当たりません。

それでも日本語でこの基盤を解説した記事は、2026年10月時点でほとんど見当たりません。確かめられる範囲で理由を挙げると、まず公式サイトと公式ドキュメントが英語だけであることです。権限の仕組みやスペースの考え方を社内で説明するには、英語のドキュメントを読み解く必要があります。

次に、国内では社内のエージェントを作る基盤として、すでに業務で使っている大手の製品に付属するものが先に検討されることが多い点です。社内の文書や予定表がすでに特定の製品の上にある会社では、その製品の中で作る道具が自然な候補になります。Dust は特定の製品に寄らず、複数のモデルと複数のデータ源をつなぐ立場の基盤なので、比べる場面そのものがまだ少ないと言えます。

データの保管場所も、検討の入り口になります。公式のセキュリティのページでは、データの保管場所をEUか米国から選べると説明しています。日本国内での保管は選択肢に挙がっていないため、社内の規程で保管場所を国内に限っている会社では、配る前に規程との突き合わせが必要です。

「作れれば広がる」が外れる理由

社員がエージェントを作れるようにすれば活用が進む、という考えには、見落としがちな前提があります。それは、作られたエージェントが、作った人以外にも使われるということです。作った人にとっては自分の仕事の道具でも、部署で共有した瞬間から、他の社員がそのエージェントを通じて社内のデータに触れる入り口になります。

たとえば、営業の担当者が、顧客との商談の記録をもとに提案の下書きを作るエージェントを作ったとします。本人は商談の記録を見る権限を持っていますが、そのエージェントを部署の全員に公開すると、商談の記録を本来見ない立場の社員も、エージェント経由で内容に触れられるかもしれません。これは基盤の欠陥ではなく、どのデータをどこに置き、エージェントを誰に公開するかの設定の問題です。

もう一つは、持ち主の問題です。作った人が異動や退職でいなくなると、エージェントの指示を誰も直せなくなり、つながったデータが古くなっても気づかれません。作る人を増やすほど、持ち主のいないエージェントが増える速度も上がるので、作る自由と同時に、持ち主を決める仕組みを用意しておく必要があります。

社員が作る道具全般をどう束ねるかの体制の考え方は、別の記事『市民開発を安全に広げる体制の作り方』で扱っています。この記事では、Dust の権限の仕組みに沿って、何をどう設定するかに絞ります。

Dustの権限は役割・グループ・スペースの3層で決まる

Dust で誰が何をできるかは、3つの層の組み合わせで決まります。1つ目は役割です。公式ドキュメントでは、ワークスペースの役割として管理者・マネージャー・メンバーの3つが定義されています。管理者は請求・セキュリティ・利用者の管理を含む全ての管理を行い、マネージャーはメンバーの招待や役割の変更、利用状況の確認などを任される、委任された管理者の位置づけです。メンバーには、既定では管理の権限がありません。

2つ目はグループです。公式ドキュメントは、権限を個人ではなくグループに与えると説明しています。グループは、社内の利用者の台帳から同期するものと、Dust の中で手作業で作るものの2種類があります。権限は足し算で効き、あるグループで与えた権限が、別のところで与えた権限を取り消すことはありません。一度広く与えた権限は、別の設定で打ち消せないので、最初は狭く与えて足していくのが基本です。

3つ目はスペースです。スペースはデータや道具を入れる器で、どのスペースに何を入れるかで、誰がどのデータを使えるかが決まります。スペースについては次の節で詳しく見ます。

この3層のうち、セキュリティの設定と監査ログには、マネージャーの役割だけでは入れません。公式ドキュメントは、セキュリティの機能へのアクセスを、管理者が特定のグループに別途与える形を示しています。情報システム部門の担当者に、役割とは別にこの権限を持たせるかどうかも、配る前に決めておく項目です。

スペースが「誰がエージェントを使えるか」を決める

Dust のスペースには、全員が入れる公開のスペースと、指定した人だけが入れる制限つきのスペースがあります。加えて、全てのワークスペースにある既定のスペースは、変更も制限もできません。スペースを作って管理できるのは管理者だけで、外部のサービスとの接続から取り込んだデータをスペースに入れられるのも管理者だけ、と公式ドキュメントは説明しています。

ここで大事なのが、エージェントとスペースの関係です。公式ドキュメントによれば、エージェントの道具が使うスペースによって、誰がそのエージェントを見て使えるかが決まります。制限つきのスペースのデータを使うエージェントは、そのスペースのメンバーにしか見えず、使えません。データの置き場所を決めることが、そのままエージェントの公開範囲を決めることになる仕組みです。

この仕組みを踏まえると、配る前に決めるべきは、どのデータを既定のスペースに置き、どのデータを制限つきのスペースに分けるかです。全社で共有してよい規程やマニュアルは既定のスペース、人事・経理・顧客の情報は部署ごとの制限つきのスペース、というように、データの機微さでスペースを分けてから、エージェントを作らせる順番が大切です。

スペースの数には契約による上限があり、公式ドキュメントではビジネスの契約で5つ、エンタープライズの契約で100までとされています（2026年10月時点）。部署の数だけ制限つきのスペースを作りたい会社では、契約の段階でスペースの数が足りるかを確かめておきます。

新しいワークスペースの既定は「全員が作れて公開できる」

配る前に必ず確かめたいのが、既定の設定です。公式ドキュメントによれば、新しいワークスペースでは、エージェントの作成と公開、メールでの招待、公開リンクでの共有が、既定で全員に許可されています。一方、スキルの作成などは既定で管理者だけに絞られています。

この既定は、小さなチームが素早く試すには向いています。しかし全社に配る場合、何も設定を変えずに配ると、全社員がエージェントを作って全社に公開できる状態で始まることになります。どの配り方を選ぶにしても、配る前にこの既定をどうするかを決めておく必要があります。

公開と非公開の違いも押さえておきます。公式ドキュメントでは、非公開のエージェントはその編集者しか使えないとされています。作る権限は広く与えても、公開する権限は特定のグループに絞る、という分け方ができるわけです。作って試すのは自由、部署に公開するのは承認を経てから、という運用は、この2つの権限を分けることで実現できます。

外部への共有も見落とせません。メールでの招待や公開リンクでの共有の扱いは、ワークスペースの方針で許可するかどうかを管理者が決められます。社外の人に見せる必要がない会社では、配る前にこの方針を閉じておくと安心です。

配り方1　全員が作れる

1つ目の配り方は、全社員にエージェントを作る権限を与える形です。既定の設定に近く、始めるまでの手間が最も少ない方法です。現場の業務を一番よく知っている人が、自分で道具を作れるので、思いもよらない使い方が生まれやすいという利点があります。

一方で、管理の手間は最も大きくなります。エージェントの数が増えると、同じ目的のエージェントが部署ごとに乱立し、どれが正しい答えを返すのか分からなくなります。公式ドキュメントでは、管理者がエージェントの一覧を利用状況や編集者で絞り込み、アーカイブできる機能が示されていますが、数百のエージェントを人が一つずつ見て判断するのは現実的ではありません。

この配り方を選ぶなら、作る権限は全員に与えても、公開する権限は絞るのが現実的です。全員が自分用のエージェントを作って試せる一方、部署に公開するのは推進役の確認を経たものだけにする。こうすると、作る自由を残したまま、共有されるエージェントの数と質を保てます。

つなぐデータの範囲も、この配り方では特に重要です。全員が作れる状態で、既定のスペースに機微なデータが入っていると、誰でもそのデータを使うエージェントを作れてしまいます。全員に作らせる前に、既定のスペースに置くデータを、全社に見せてよいものだけに絞っておきます。

配り方2　部署の推進役だけが作る

2つ目は、各部署にAI活用の推進役を置き、その人たちが入るグループにだけエージェントの作成と公開の権限を与える形です。推進役は部署の業務を知っていて、部署のメンバーの要望を集めてエージェントを作ります。全員が作る形よりも数は抑えられ、情報システム部門が全部作る形よりも現場の業務に合ったものができます。

この配り方と相性がよいのが、公式ドキュメントにあるグループごとの管理役の仕組みです。管理者やマネージャーは、特定のグループのメンバーの出入りや利用の上限の管理を、そのグループの管理役に任せられます。部署の推進役に、ワークスペース全体の管理権限を渡さずに、自分の部署の範囲だけを任せられるので、推進役の責任の範囲が明確になります。

課題は、推進役の負担と、推進役が抜けたときです。推進役が作ったエージェントの編集者が推進役1人だけだと、異動のときにエージェントが宙に浮きます。エージェントの編集者を必ず2人以上にすることを、この配り方の決まりにしておきます。公式ドキュメントも、メンバーを外す前に、そのメンバーが編集しているエージェントに別の編集者を足すよう勧めています。

推進役同士の横のつながりも用意しておきます。部署ごとに似たエージェントが作られていないか、うまくいった作り方を他の部署にも広げられないかを、月に一度でも推進役が集まって確かめると、乱立を防ぎながら良い作り方を共有できます。

配り方3　情シスが作って配る

3つ目は、情報システム部門やAI推進の専任の担当者がエージェントを作り、部署に配る形です。作成と公開の権限を管理者や専任のグループだけに絞ります。つなぐデータ、使うモデル、指示の内容を一か所で管理できるので、統制の点では最も安心です。

ただし、この形では現場の業務に合ったエージェントを作るのに時間がかかります。部署の要望を聞いて、作って、試して、直すまでの往復が、全部情報システム部門を通ることになるからです。要望が溜まり、待ちきれない現場が別の道具を勝手に使い始める、という事態にもなりかねません。

この配り方を選ぶなら、全社で共通に使うエージェント、たとえば社内の規程に答えるもの、全社の申請の手順を案内するものに絞って情報システム部門が作り、部署固有の業務のエージェントは配り方2に移る、という段階の踏み方が現実的です。最初は配り方3で始め、運用が回ったら配り方2に広げるという順番なら、統制と現場の速さの両方を段階的に取れます。

いずれにせよ、情報システム部門が作る場合でも、エージェントの答えの正しさを確かめるのは、データを持っている部署です。人事の規程に答えるエージェントなら人事部門が、経理の手順に答えるエージェントなら経理部門が、答えの中身を確かめる役を持ちます。作る人と、中身に責任を持つ人を分けておくことが大切です。

3つの配り方を比べる

ここまでの3つの配り方を、つなぐデータの権限、エージェントの共有範囲、使うモデル、記録、止め方の5つの観点で比べます。どれか一つが正解というわけではなく、会社の規模とデータの機微さで選びます。

観点	全員が作れる	部署の推進役だけが作る	情シスが作って配る
つなぐデータの権限	既定のスペースに置くデータを全社に見せてよいものに絞る必要がある	部署の制限つきのスペースを推進役のグループに開く	情シスが必要なデータだけを選んで入れる
エージェントの共有範囲	作成は全員、公開は推進役の確認後に絞るのが現実的	推進役が自部署に公開。全社への公開は情シスの承認	情シスが部署ごとに公開範囲を決める
使うモデル	モデルの提供元の管理は管理者のみ。選べるモデルを先に絞る	同左。部署の用途に応じて推進役が選ぶ	情シスが用途ごとに決める
記録	エージェントの数が多く、監査ログを読む手間が最も大きい	推進役ごとに担当範囲を分けて見直せる	作り手が少なく、追いやすい
止め方	持ち主のいないエージェントが出やすい。編集者2人の決まりが要る	推進役の異動時の引き継ぎを決めておく	情シスがアーカイブを判断。現場の要望の待ちに注意

表を見ると、どの配り方でも、つなぐデータの権限と使うモデルの管理は、最終的に管理者、つまり情報システム部門の手元に残ることが分かります。違うのは、エージェントを作って公開する権限を、どこまで現場に開くかです。作る権限は開いても、データとモデルの管理は閉じておくのが、どの配り方にも共通する線です。

社内のAIを全社で一つにそろえるか、部署ごとに分けるかという、より上の層の判断は別の記事『社内AIは統一か部署ごとか』で扱っています。Dust を選んだあとの配り方は、その判断の結果を、基盤の上でどう設定に落とすかの話だと位置づけると分かりやすくなります。

つなぐデータの範囲は情シスが承認する

どの配り方を選んでも、つなぐデータの範囲の承認は情報システム部門が持つべき仕事です。Dust の仕組みでも、外部のサービスとの接続からデータをスペースに入れられるのは管理者だけで、そのとき、どのデータを使えるようにするかを選べると公式ドキュメントは説明しています。公式のセキュリティのページでも、管理者がデータ源ごとに取り込むデータを選べるとしています。

ここで決めるのは、接続ごとに、どのフォルダ、どのチャンネル、どのページを取り込むかです。社内の文書の保管場所を丸ごとつなぐと、本来は限られた人しか見ない資料まで、スペースに入ってしまうことがあります。つなぐ単位を大きくせず、エージェントの目的に必要な範囲だけを選んで取り込むことが、データの見え方を保つ一番の方法です。

一方で、公式ドキュメントでは、公開のスペースではフォルダやウェブサイトなどを管理者と作成の権限を持つ人が追加でき、制限つきのスペースでは全てのメンバーが追加できるとされています。つまり、接続からの取り込み以外の方法でデータが足される経路があります。誰がどのスペースに何を足せるかを、スペースごとに一覧にしておくと、意図しないデータの追加に気づきやすくなります。

外部の道具とつなぐ場合も同じ考え方です。公式ドキュメントには、管理者が MCP サーバーを追加する手順が管理者向けの文書として並んでいます。エージェントが外部のサービスを使うとき、誰の資格で動くのかという権限の委任の問題は、同じ便の Arcade の記事で詳しく扱っています。ここでは、外部の道具の追加も管理者の承認を通す、とだけ押さえておきます。

使うモデルとデータの行き先を確かめる

社員が作ったエージェントが使うモデルによって、データの行き先が変わります。公式のセキュリティのページでは、顧客のデータをモデルの学習に使わないこと、外部のモデルの提供元にデータを保存させないことが明記されています。データはEUか米国で保管でき、保存時も通信時も暗号化されるとしています（2026年10月時点）。

認証については、EUの一般データ保護規則への準拠と、SOC2 のタイプ2の認証を取得していると公式サイトで説明しています。シングルサインオンで利用者の出入りを管理でき、社内の利用者の台帳からグループを同期する仕組みも公式ドキュメントにあります。入退社のたびに手作業で利用者を足し引きしなくて済むので、全社に配るなら台帳との同期を先に整えておきたいところです。

モデルの選び方は、管理者が持つ権限です。公式ドキュメントでは、ワークスペースのモデルの提供元を管理する権限は管理者だけに与えられています。配る前に、どの提供元のモデルを使えるようにするかを決め、社内の規程で認めていない提供元は外しておきます。

ここで注意したいのは、公式の説明はあくまで提供元の説明だということです。自社の規程で求める条件、たとえば保管場所や、契約上の再委託先の扱いについては、契約の段階で文書を取り寄せて確かめます。公式サイトから案内されている信頼性の情報のページも、法務と一緒に読んでおくと、社内の審査がスムーズになります。

記録と見直しの周期を決める

全社に配ったあとに欠かせないのが、何が起きているかを追える記録です。公式ドキュメントによれば、Dust の監査ログは、ワークスペースで起きた重要な操作を、誰が、何に対して、どこから、いつ行ったかの形で時系列に残します。CSVで書き出せるほか、外部のログを集める基盤へ送り続けることもできます。

ただし、監査ログはエンタープライズの契約に限られると公式ドキュメントに明記されています（2026年10月時点）。全社に配り、操作の記録を残す必要がある会社は、契約の段階で監査ログが使えるかを確かめる必要があります。監査ログを見られるのは管理者と、セキュリティの機能へのアクセスを与えられたグループです。

監査ログとは別に、エージェントの管理画面では、直近30日の利用者数や、利用者からの良い・悪いの評価の数を確かめられます。この数字は、見直しの材料として使えます。直近30日で誰も使っていないエージェントは、四半期ごとにアーカイブの候補にする、悪い評価が続くエージェントは持ち主に直してもらう、といった見直しの基準を決めておきます。

見直しの周期は、配った直後は月に一度、運用が落ち着いたら四半期に一度が目安です。見直しの場では、エージェントの数、使われているものと使われていないもの、つながっているデータの範囲の変化、持ち主の不在を確かめます。作られたエージェントを継続的に見張る専用の道具の話は、同じ便の Zenity の記事で扱っています。

止め方と畳み方を先に決める

エージェントは作るより止めるほうが難しいものです。公式ドキュメントでは、管理者や編集者がエージェントをアーカイブでき、アーカイブしたエージェントは一覧で確かめて元に戻せるとされています。管理者はどのエージェントも閲覧はできますが、編集するには編集者になる操作が必要です。

止める場面は、大きく3つあります。1つ目は、エージェントが誤った答えを返し続けているとき。2つ目は、つながっているデータの扱いを変える必要が出たとき。3つ目は、持ち主がいなくなったときです。それぞれ、誰がアーカイブを判断し、誰に知らせるのかを決めておきます。止める判断を持ち主任せにしないことが、持ち主がいない場面への備えになります。

社員が退職するときの手順も、配る前に決めておきます。公式ドキュメントは、メンバーを外す前に、そのメンバーが編集しているエージェントに別の編集者を足すよう勧めています。非公開のエージェントは編集者しか使えないため、編集者が誰もいなくなると、そのエージェントは誰にも使われず、直されもしない状態で残ります。退職の手続きの一覧に、エージェントの編集者の付け替えを1行足しておくだけで、この事態は防げます。

基盤そのものをやめる場合の畳み方も考えておきます。作られたエージェントの指示の内容、つないだデータの一覧、利用の記録を書き出しておけば、別の基盤に移るときの手がかりになります。始める前にやめ方を決めておくと、試行に踏み出しやすくなります。

エージェントに任せない判断

エージェントを作る基盤を配ると、現場はさまざまな業務をエージェントに任せようとします。その中には、AIに任せてはいけない判断が含まれることがあります。Dust の権限の設定は、誰がどのデータを使えるかを決めますが、そのデータを使って何を判断させるかまでは決めてくれません。

特に、人事の評価や採用の可否、顧客との取引の条件、顧客への最終の回答の内容は、エージェントに決めさせない範囲としておきます。エージェントにやらせるのは、資料の下書き、情報の整理、根拠となる文書の提示までにとどめ、判断は人が行います。エージェントの指示の中に、答えの根拠となる文書を示させる一文を入れておくと、人が確かめやすくなります。

• 人事の規程と評価の記録を同じスペースに入れ、評価の判断をエージェントに下書きさせて、そのまま本人に伝える
• 顧客との契約の条件を、エージェントが答えた内容のまま顧客に回答する
• 作った本人しか編集者がいないエージェントを、全社に公開する
• 既定のスペースに、部署限りの資料を含む共有フォルダを丸ごとつなぐ
• 新しいワークスペースの既定の設定を確かめないまま、全社員を招待する

これらは、どれも基盤の機能の問題ではなく、配る前の決めごとの問題です。エージェントの下書きは現場、つなぐデータと共有範囲の承認は情報システム部門、判断は人、という3つの線を、配る前の説明会で社員に伝えておくことをおすすめします。

配る前の確認項目

ここまでの内容を、全社に配る前に確かめる項目にまとめます。情報システム部門とAI推進の担当者が一緒に、一つずつ答えを書き込んでください。

• 3つの配り方（全員が作る・部署の推進役が作る・情シスが作って配る）のうち、どれで始めるかを決めたか
• エージェントの作成と公開の権限を、既定の「全員」から、選んだ配り方に合わせて変えたか
• メールでの招待と公開リンクでの共有を、社外に開くかどうかを決めたか
• 既定のスペースに置くデータを、全社に見せてよいものだけに絞ったか
• 人事・経理・顧客の情報を、部署ごとの制限つきのスペースに分けたか
• 外部のサービスとの接続ごとに、取り込むフォルダやチャンネルの範囲を情シスが承認したか
• 使えるモデルの提供元を決め、社内の規程で認めていないものを外したか
• データの保管場所（EUか米国）が、社内の規程と合っているかを確かめたか
• 監査ログが契約で使えるか、誰がどの周期で読むかを決めたか
• 公開するエージェントの編集者を2人以上にする決まりを作ったか
• 退職・異動の手続きに、エージェントの編集者の付け替えを入れたか
• 人事・顧客の判断をエージェントに任せない範囲を、社員に伝えたか

12項目のうち、答えが空いている項目があるうちは、全社への招待を始めないことをおすすめします。まずは1つの部署で試し、確認項目の答えが現場で守られるかを確かめてから、対象の部署を広げていきます。確認項目は一度書いて終わりではなく、見直しの場で毎回読み返し、運用で分かったことを書き足していきます。

まとめ

Dust は、社員がコードを書かずに、社内のデータや外部の道具とつないだエージェントを作り、部署で共有する基盤です。2026年10月時点で日本語の解説はほとんどありませんが、海外では3,000を超える組織が使っていると提供元は説明しています。作れる人を増やせば活用が広がる、というのは半分だけ正しい考えです。作られたエージェントは、つながったデータへの入り口になり、持ち主がいなくなれば誰も直せなくなります。役割・グループ・スペースの3層の仕組みを使って、作る人と使う人を分け、つなぐデータの範囲を情報システム部門が承認する。全員が作る、推進役が作る、情シスが作る、のどれを選んでも、データとモデルの管理は閉じておくという線は同じです。まずは新しいワークスペースの既定の設定を確かめ、確認項目の12行を埋めるところから始めてみてください。

• 製品の機能・権限の仕組み・データの扱いは、Dust の公式ドキュメント、公式のセキュリティのページ、公式ブログを2026年10月15日に確かめた範囲に基づきます。機能や契約ごとの条件は更新されることがあるため、利用前に最新の原文と契約の文書を確かめてください
• 社内のデータを国外で保管する基盤に取り込む場合は、社内の規程と個人情報の扱いを、法務の担当者と一緒に確かめてください

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。