ある自動車部品メーカーの営業責任者が、特定顧客に対する今期の納期遵守率が低下した理由を知りたいと考えたとしても、情報システム部門の対応を待たなければなりません。工場長が3つの生産ラインについて、同一品番の歩留まりの差を比較したければ、誰かに依頼して MES からデータを抽出してもらう必要があります。財務部門が、ある品番の原価がなぜ2元高くなったのかを調べるには、まず3つの部門に確認しなければなりません。
どの問いも難しくはありません。難しいのは、答えを得るまで順番を待たなければならないことです。
2026年9月10日、OpenAI は ChatGPT Work に Data agent を導入しました。Data agent が解消しようとしているのは、まさにこの待ち時間です。
Data agent が実現したこと
Data agent は ChatGPT Work の新機能であり、新しい基盤モデルではありません。管理者がワークスペースにインストールすると、ユーザーは会話内で @Data を呼び出し、SQL を学ばなくても、一言で会社のデータに質問できます。
接続できるのはデータテーブルだけではありません。公式発表によると、質問を理解するためのコンテキストは、セマンティックレイヤーと信頼できる情報源から取得します。例として、Databricks Genie Ontology、dbt、GitHub、Snowflake Horizon、既存の BI ダッシュボードに登録された定義などが挙げられています。まず会社が売上高や粗利益をどのように定義しているかを読み取り、そのうえで計算します。
データソースについては、承認済みの接続先として Amazon Redshift、Datadog、Google BigQuery、ClickHouse、Databricks、MongoDB、Snowflake などが公式に挙げられています。Google Drive や SharePoint 上のファイルも分析に取り込めます。
出力形式は回答だけではありません。更新可能なダッシュボードを作成し、Omni、Oracle BI、Power BI、Sigma、Tableau、ThoughtSpot 上で操作することもできます。既存のレポートシステムを作り直す必要はありません。
権限の仕組みも明確です。クエリには接続アカウントがすでに持つ権限が適用され、テーブル、行、列単位の制限も引き継がれます。どの接続を利用可能にするか、どのロールに利用を許可するかは管理者が決めます。
OpenAI は社内での導入状況も公開しています。ほぼすべてのプロダクトチームと、GTM 組織の3分の2以上がデータエージェントを使って社内データを分析しています。一方で、重要な前提条件も示しています。これが実現できたのは、データチームがあらかじめ共通のビジネス定義を整備し、アクセスルールを設定し、機密データを保護していたからです。
本稿で取り上げたいのは、この後半部分です。つまり、「データチームがあらかじめ何をしたのか」という前提条件です。
機能以外の6つの課題
これまで社内で自らデータを抽出できる人は、せいぜい3人から5人程度でした。順番待ち自体がフィルターとして機能していたのです。ところが、300人が同時に質問できるようになると、「そのテーブルがどこにあるか誰も知らない」ことで保たれていた秩序は、すぐに機能しなくなります。
ハードルが下がると、次の6つの課題は企業自身が担うことになります。
- 定義：この数値の算出方法は、全社で一つに統一されているか
- 境界：誰も定義したことのない境界を、どう決めるのか
- 責任：誤りが発生したとき、どのように責任を明確にするか
- 記録：3か月後でも、当時どのように算出したかを確認できるか
- 継承：最も的確な質問ができる人が退職したらどうするか
- 運用：この仕組み全体を誰が維持するのか
この6つは、FDE が顧客の現場に入り、最初の AI Agent を業務プロセスへ組み込む際、実際に行き詰まりやすいポイントです。どれも技術上の問題ではありません。各課題には二つの段階があります。意思決定は社内の担当者が行い、FDE は意思決定できるところまで論点を明確にします。決定後はシステムが引き継ぎ、その判断が毎回同じように実行されるようにします。
第1の課題：この数値の算出方法は、全社で一つに統一されているか
営業部門の月次報告に記載された粗利益率と、財務部門が決算で算出した粗利益率には、2～3ポイントの差があります。営業部門は出荷金額から標準原価を差し引き、財務部門は認識済みの売上高から実際原価を差し引いています。長年にわたり、双方がそれぞれのレポートを見てきましたが、問題にはなりませんでした。この二つの数値が同じ画面に表示されることがなかったからです。
自然言語によるクエリは、この二つを同時に表面化させます。今日、営業責任者が「先月の顧客 A の粗利益はいくらか」と質問し、翌日、財務部門が同じ質問をすると、異なる答えが返ってきます。しかも、どちらにも計算根拠があります。
会社が正式に採用する算出方法は、EgentWrX のナレッジベース上で3つの形式に分けて管理できます。規程や業務マニュアルは Wiki に格納し、個別の方針や規定はセマンティック検索の対象とし、正確な数値が必要な対応表は表形式でアップロードして直接参照します。社外向けの回答には「必ず出典を引用する」という条件を設定でき、出典を示せない回答はシステムによって却下されます。
ただし、どの算出方法を選ぶかは経営判断であり、どちらが正しい、間違っているという問題ではありません。私たちは、営業部門と財務部門を集め、二つの算出方法を同じ資料上に並べ、それぞれがその数値を使ってどのような判断をしているのかを確認することを提案しています。そのうえで、経営層が一つに統一するのか、両方を残して別々の名称を付けるのかを決定します。決定内容をナレッジベースに登録すれば、その後は誰が質問しても、Agent は正しい定義を参照できます。
第2の課題：誰も定義したことのない境界を、どう決めるのか
購買課長は、3社のサプライヤーについて、見積価格、納期、品質実績を把握しています。営業部門の担当者は、この3社の価格差を質問できるのでしょうか。
多くの企業は、この問いに正式な回答を出したことがありません。境界は慣例によって保たれています。相見積表は購買部門の共有フォルダにあり、実際には十数人がアクセス権を持っていても、わざわざ見に行く人がいないだけです。
OpenAI の仕組みでは、クエリに接続アカウントの既存権限が適用されます。これは妥当な設計です。別の権限体系を新設しなければ、二つのルールが競合することもありません。ただし、「既存権限を引き継ぐ」ためには、その権限体系がもともと適切に定義されている必要があります。多くの製造業では、フォルダの権限が十数年にわたって継ぎ足され、全体を棚卸しした人はいません。
EgentWrX は、組織構造を基準に境界を設定します。ロールには「全社」と「部門範囲」という二つの参照範囲があり、部門責任者が閲覧できるのは、自部門とその配下部門のみです。部門をまたいでナレッジを公開する場合は、さらに別のゲートがあります。同じ部門のメンバーへの公開はボタンを押せば有効になりますが、全社公開には申請と管理者の承認が必要です。
ゲートによって申請を止めることはできます。しかし、止めた後に承認するかどうかは、依然として「サプライヤーの価格比較情報は購買部門と経営層に限定する」といった管理上の判断が必要です。企業では、この種の決定が文書化されていないことが少なくありません。私たちは導入段階で、こうした問題を一つずつ議題に上げ、購買部門、営業部門、経営層とその場で決定します。その内容を誰にでも理解できる数項目のルールとして文書化し、ロールの範囲やサービス窓口の公開対象に設定します。それ以降、境界は記録された意思決定になります。
第3の課題：誤りが発生したとき、どのように責任を明確にするか
社外向け見積書の原価構成は、これまで原価計算担当者が算出し、課長が確認し、部長が署名していました。誤りがあれば、誰が担当したのかを確認できました。
現在は、その途中に「AI が計算した」という工程が加わります。この工程には誰の名前もなく、職務記述書にも、内部統制監査のフローチャートにも記載されていません。導入を阻むのは、技術ではないことが少なくありません。AI が作成したレポートに署名したい人がいないのです。
この懸念は、説得して解消するものではなく、仕組みで解決すべきです。承認対象を「この数値」から「このアクション」へ変更します。責任者が署名するのは、「粗利益率23.4％が正しい」という確認ではなく、「この原価構成を顧客へ提出してよい」という判断です。これは、もともと責任者が行っていた判断です。
EgentWrX では、承認ポイントを業務プロセス内に設けます。複数のタスクをつないでワークフローを構成する場合、どの引き継ぎ箇所でも「引き継ぎ前に人の承認を必要とする」と設定できます。Agent はその段階で停止し、人が承認するまで待機します。一定時間を超えた場合には、あらかじめ設定されたタイムアウト処理が実行されます。
誰が承認するのかは、内部統制の観点から事前に決めなければなりません。いくら以下なら承認できるのか、どのような場合に必ず人が再計算するのか。こうした基準は、承認申請書や慣例の中に分散しています。FDE は財務部門や内部統制部門と連携し、「AI が計算した」工程に誰が署名するのかを補い、それをワークフローの承認ポイントとして設定します。こうして、内部統制のフローチャート上で空白だった箇所に、担当者の名前が入ります。
第4の課題：3か月後でも、当時どのように算出したかを確認できるか
顧客から、あるロットの不良率について疑義が示され、この数値の根拠を証明するよう求められたとします。3か月前にこの数値を算出した担当者は、どのバージョンの判定基準を使用したのでしょうか。データは MES から取得したのか、それとも品質保証部門独自のレポートから取得したのでしょうか。
「その場で根拠を確認できること」と「後からプロセスを再現できること」は別の問題です。会話中に AI がデータソースと計算方法を示すのは、ユーザーの信頼に関する問題を解決するためです。一方、監査で必要なのは、3か月後にも呼び出すことができ、各工程を一つずつ照合できる記録です。
EgentWrX では、記録の保存を50種類以上のリソースタイプに対応する検証機能として実装しています。管理者が「整合性を検証」を押すと、その場でチェーン全体を再計算できます。外部監査に提出する場合は CSV 形式でエクスポートでき、ダウンロード操作そのものも記録されます。
記録をどのくらいの期間保存するのか、外部監査人へ提出する必要があるのか、顧客契約のどの条項に対応するのか。その答えは、自社のコンプライアンス要件と顧客契約にあります。この課題は、最初のデータ接続を行う前に決めるのが理想です。FDE はコンプライアンス、品質保証、営業の各部門とともに顧客契約や監査チェックリストを確認し、要件一覧を作成します。その後、システムの監査設定やエクスポート設定と照らし合わせ、一項目ずつ確認します。
第5の課題：最も的確な質問ができる人が退職したらどうするか
導入から3か月後、成果が3人に集中していたとします。生産管理担当者が1人、製造プロセスエンジニアが1人、そして工場設備部門の若手社員が1人です。彼らが的確に質問できるのは、どのフィールドが信頼できないか、どの機械の歩留まりを割り引いて見るべきかを知っているからです。
そのうちの1人が退職します。その人が持ち去るのはデータではありません。データは残っています。持ち去るのは「どのように質問するか」という知識です。そして、その知識は一度も保存されていません。以前は know-how が熟練者の頭の中にあり、今は特定の担当者の会話履歴にあります。組織の脆弱性は改善されていません。
個人が試行錯誤して見つけた方法は、EgentWrX 上でスキルとして保存できます。方法を文章で説明すると AI が下書きを作成し、まず自分の Agent で利用できます。全社で使う価値があると判断した場合は公開を申請し、管理者の承認後に会社のスキルライブラリへ登録します。方法を変更するときも、この一つを修正するだけです。ナレッジデータをアップロードする際には適用範囲を選ぶ必要があり、「部門」を選択したデータは部門全体の資産となるため、特定の担当者が退職しても消えません。
第6の課題：この仕組み全体を誰が維持するのか
多くの製造業では、情報システム部門の担当者は1～3人程度で、主な業務は ERP、ネットワーク、ウイルス対策、設備接続です。そこへさらに、データ接続を誰が維持するのか、新しいデータソースの追加申請を誰が審査するのか、「AI が示した数値が間違っている」という申し立てに誰が対応するのか、という業務が加わります。
ここで、OpenAI の言葉を振り返ってみましょう。高い社内導入率を実現できたのは、データチームがあらかじめ共通定義、アクセスルール、機密データの保護策を整備していたからです。この前提条件は、導入率という数値以上に重要です。そして現在、多くの台湾の製造業には、この前提条件がありません。
したがって問うべきなのは、「いつデータチームを持てるのか」ではなく、「この役割を誰が担うのか」です。
EgentWrX では、情報システム部門が別のメンバーリストを管理する必要はありません。アカウントには SSO を使用でき、SCIM を通じて、企業がすでに運用している ID 管理システムからアカウントの有効化と無効化を行えます。ID 管理システム側でユーザーを削除すると、EgentWrX 側のメンバーリストにも同期されます。ID 管理システム内のグループは、プラットフォーム上のロールや部門に直接対応し、社員は初回ログイン時から適切な権限を持つことができます。
導入作業は外部委託できますが、意思決定は外部委託できません。誰がデータソースを追加できるのか、誰が指標を定義できるのか。この二つの担当者は、必ず社内の人でなければなりません。最初の業務プロセスにおける FDE の役割は、この二つを一度実際に構築し、指名された担当者に一連のプロセスをすべて見てもらうことです。2本目の業務プロセスでは、その担当者が実施し、私たちが見守ります。
EgentWrX の強みはどのレイヤーにあるのか
6つの課題を並べてみると、Data agent と EgentWrX は同じレイヤーの製品ではないことが分かります。Data agent が解決するのは、「誰が分析を始められるか」という問題です。EgentWrX が解決するのは、その後の工程です。この答えをどのようなアクションにつなげるのか、誰が責任を負うのか、記録を残せるのか、担当者が変わっても維持できるのかという問題です。
この工程を構築するには、3つの要素が必要です。
データの配置先は企業が決めます。 EgentWrX は、クラウド、企業所有のオンプレミス環境、または機密データをオンプレミスに残して推論処理のみをクラウドへ送るハイブリッド構成で導入できます。ERP や MES などの社内データベースに接続する場合、Agent は読み取りのみが可能で、書き込みはできません。Agent から外部への接続はデフォルトですべて拒否され、ホワイトリストに登録された接続先だけが許可されます。契約でデータの国外移転が禁止されている業界では、これは導入を開始できるかどうかを左右する前提条件です。
すべての工程に検証可能な記録を残します。 モデルの呼び出し、ナレッジの利用、システムへの書き戻し、チェックサムチェーン、整合性検証までを記録します。目的は、内部統制のフローチャート上に「AI が計算した」という工程を明確に位置付けることです。
能力を個人ではなく組織に残します。 会社のスキルライブラリ、部門単位で管理されるナレッジ、職務にひも付けられた Agent。この3つの設計は、同じ目的に向けられています。人が去っても、方法は組織に残ります。
この3つは、いずれもモデルの能力ではありません。プラットフォームを選ぶとき、どのモデルを使うかは最後に検討すべき問題です。この点については、別の記事で詳しく解説しています：https://www.egentwrx.com/ja/perspectives/ai-agent-harness-execution-layer
6つの課題すべてに、まだ答えがない場合はどうするか
多くの企業では、ここまで読んでも6つの課題に対する答えがまだ用意されていません。それは自然なことです。よく聞くアドバイスは、次のようなものです。
まずデータを整理し、定義を統一し、権限を全面的に見直してから AI を検討する。しかし、台湾の多くの製造業では、この方法を実行できません。
アドバイス自体が間違っているわけではありません。問題は、こうした企業にとって「データを整理すること」が一度も単独のプロジェクトではなく、終わりのない状態だということです。Excel ファイルは数千件あり、同じ表に7つのバージョンが存在し、重要な判断基準は数人のベテラン社員の頭の中にあります。「AI に委ねられる」状態まで整理するには、専任チームと2～3年の期間、そして短期的なリターンを期待できない予算が必要です。このアドバイスがもたらす実際の結果は、企業を毎年、準備段階にとどめ続けることです。
私たちは、これとは逆の順序で、3つのステップを進めます。
第1ステップ：部門ではなく、一つの業務プロセスを選ぶ。 基準は3つあります。範囲が明確であること、定義が単純であること、誤りが発生した場合の影響を制御できることです。購買部門の入荷異常通知や、営業部門の顧客納期照会などは、項目が少なくルールも明確で、その場で回答の正誤を判断できる担当者がいます。FDE は現場に入った最初の1週間で、各部門へのヒアリングを行い、課題となっている場面を洗い出します。そして、最も深刻な課題ではなく、3つの基準に最も適した業務プロセスを選びます。
第2ステップ：その業務プロセスに限定して、6つの課題に小さな答えを出す。 全社の指標を一度に統一する必要はありません。その業務プロセスにおける「納期」の定義、質問できる人、承認する人、記録の保存期間、方法を維持する人、ルールを引き継ぐ人だけを決めればよいのです。各課題について、FDE が関係者とともに意思決定できるところまで論点を明確にし、決定後にシステムへ設定します。このステップの成果物は、ガバナンス文書ではありません。実際に稼働する一つの業務プロセスと、責任者が署名した6つの決定です。
第3ステップ：決定した内容を、2本目の業務プロセスの出発点にする。 最初の業務プロセスで蓄積したナレッジ、スキル、ロール、ルールは、すでにシステム上の会社資産です。2本目の業務プロセスでは、それらをそのまま再利用します。この段階では、社内で指名された担当者が主導し、FDE は一歩下がって見守ります。
これは、十分に検討しなくてもよいという意味ではありません。動かして初めて明確になることがある、ということです。最初の業務プロセスを3か月運用すれば、定義の衝突が実際にどのフィールドで起きているのか、どのデータが誰にも保守されていないのかが分かります。こうした事実は、机上の棚卸しでは見つけられません。
データチームを持たない企業では、ガバナンスが利用に先行して完成することはありません。FDE、社員、システムが一つずつ業務プロセスを構築する中で、ガバナンスをともに形にしていくのです。
運用が軌道に乗れば、次の課題が見えてきます。それについては、https://www.egentwrx.com/ja/perspectives/ai-agent-governance-after-poc で解説しています。その前に、まず一つの業務プロセスを選んでください。
よくある質問
すでに ChatGPT Enterprise を導入しています。それでも別の AI Agent プラットフォームが必要ですか？
まず、どの工程に課題があるのかを確認してください。「一つの数値を知るために3日待たなければならない」ことが課題であり、データがすでにクラウドデータウェアハウスにあるなら、Data agent が直接的な解決策になります。一方、「分析後に引き継ぐ人がいない」「翌月に同じ作業を最初から繰り返さなければならない」「担当者が退職すると業務が止まる」ことが課題なら、対応すべきなのは業務プロセス、権限と責任、記録であり、クエリの速度ではありません。多くの企業は両方に課題を抱えていますが、その度合いは異なります。まず、より深刻な工程から対応してください。
当社では ERP からデータを抽出することすらできません。それでも始められますか？
始められます。ただし、開始方法を変える必要があります。多くの製造業では、最初の業務プロセスをデータウェアハウスから始めることはありません。そもそもデータウェアハウスが存在しないからです。より一般的な出発点は、既存システムとの連携と現場のファイルです。社内のオンプレミス環境に設置したコネクターを通じて Agent が ERP や MES のデータを読み取る、または指定フォルダ内の Excel、PDF、スキャン文書を Agent が直接読み取る方法があります。まず、その業務プロセスに必要なデータを取り込めること、回答を必要な場所へ出力できることを確認し、その後でデータを集約するかどうかを検討します。
一つの業務プロセスから始めると、個別最適の仕組みが増え、後で統合しにくくなりませんか？
各業務プロセスがそれぞれ独自に定義を作れば、そうなります。それを避ける方法は、最初から全社を統一することではありません。2本目の業務プロセスで、1本目に定義した内容を再利用することです。同じ顧客コード、同じ納期の定義、同じ権限レベルを使用します。4本目、5本目まで進むころには、実務から積み上げた共通定義が手元に残ります。その内容は、トップダウンで一度だけ実施する棚卸しよりも正確です。
本当に、先にデータを整理してから導入すべきケースはありますか？
あります。その業務プロセスで誤りが発生した場合の影響を制御できないなら、最初の対象にすべきではありません。顧客への直接的な見積提示、監督官庁への申告、人身の安全に関わるパラメータなどは、データと権限・責任を明確にするまで扱うべきではありません。ただし、これは「どの業務プロセスを最初に選ぶか」という判断であり、「全社のデータをすべて整理してから始める」理由にはなりません。
参考資料
- Now everyone can put data to work — OpenAI 公式発表（2026年9月10日）。Data agent の機能範囲、データソースとセマンティックレイヤーの例、BI ツールの一覧、既存権限を引き継ぐ仕組み、OpenAI 社内での導入状況については、すべてこのページの原文に基づいています。
- ChatGPT Work for data teams — OpenAI 公式製品ページ。コネクターと利用シナリオについて説明しています。