Dataiku Agent Management公開前に、企業はAI Agentをどう棚卸しする？2026チェックリスト

Dataiku Agent Managementの公開準備では、製品の公開を待たずに、まず複数の環境にあるAgentの台帳、所有者、リスク区分を整えてください。特に、顧客対応や機密データへのアクセス、取引実行を担うAgentがある企業は、監視記録と実行権限・隔離の証拠を分けて確認する必要があります。

対象となる方
プラットフォームエンジニア：自社環境に散在するAgentを登録し、情報を更新できる仕組みを整えたい方。
セキュリティ・AIガバナンス担当者：影響の大きいAgentを見つけ、審査と証拠確認の優先順位を決めたい方。
研究開発・事業責任者：Agentの目的、責任者、継続または停止の判断根拠を明らかにしたい方。

最終更新：2026年9月26日。 Dataikuの2026年9月24日付発表と製品ブログを確認しています。同社はAgent Managementを独立製品として発表し、2026年10月の正式公開を予定しています。正式な公開日と、その時点での対応範囲は今後の公式更新で確認してください。Dataikuの発表と製品ブログに記載された機能説明は、メーカーによる説明であり、独立した実測結果ではありません。

Dataiku Agent Managementの公開準備は、台帳作成から始めます

台帳は、製品に表示されるAgentだけを数える表ではありません。自社で見つけたAgent、実行環境、データ接続、使用ツール、モデル依存を記録し、各情報の出所と最終確認状況を残す管理記録です。

Dataikuは、複数のプラットフォームにまたがるAgentの発見や運用状況の監視、リスク管理を製品の位置づけとして説明しています。また、OpenTelemetryによるカスタム環境のサポートにも触れています。ただし、発表された接続範囲を「すべてのプラットフォームで自動検出できる」と読み替えてはいけません。自社のSaaS、社内構築環境、開発者のローカル環境などが対象かどうかは、正式な対応情報と自社環境の両方で照合してください。

公開前に、どのAgent情報を集めるべきですか？
最低限、固有ID、用途、所有チーム、運用責任者、実行場所、データ接続、利用ツール、モデル、情報の出所、最終確認状態を記録します。取得できない項目は空欄のまま承認せず、「未確認」として担当者と確認期限を割り当てます。

OpenTelemetryは、カスタム環境からテレメトリーを収集するための計装方法を説明しています。計装できることと、Agentの業務上の安全性を保証できることは別です。自動で観測できない環境は手作業で登録し、更新の責任者と変更時の見直し手順を決めてください。OpenTelemetryの計装ガイドを、自社の収集方法を検討する際の参照先にできます。

責任者ごとに、登録と審査の役割を分けます

プラットフォーム担当：検出範囲と更新責任を明確にする

• [ ] Agentごとに一意の識別子を決め、重複登録を防ぎます。
• [ ] 実行プラットフォームと開発・検証・本番の別を記録します。
• [ ] データ接続、外部ツール、モデル、変更の出所を紐づけます。
• [ ] 自動検出されない環境を手動登録の対象として明示します。
• [ ] 情報の取得元と最終確認状況を残し、変更時に更新する担当チームを決めます。

発見の仕組みが見つけた範囲と、企業内に存在するAgentの全体数は一致するとは限りません。自動検出できた記録だけで網羅性を判断せず、チームや環境の台帳と定期的に突き合わせます。

事業・開発担当：目的と運用責任者を照合する

複数のプラットフォームにいるAgentの担当者と用途は、どう一元管理しますか？
プラットフォームのアカウント所有者だけでなく、業務目的を決める人、日々の運用を担うチーム、障害時に継続・停止を判断する責任者を記録します。作成したチームと現在の運用担当が異なる場合は、両者を分けて確認してください。

• [ ] Agentが誰のどの業務を支援するか、利用対象とともに記録します。
• [ ] 作成者と現在の運用責任者が異なる場合、その引き継ぎを確認します。
• [ ] 所有者が特定できない、または用途が当初の設計から変わったAgentは「要確認」にします。
• [ ] 確認が終わるまで、高影響の操作を許可しない判断が可能か確認します。

担当者が空欄のAgentは、台帳上の欠落にとどまりません。障害時の連絡、アクセス権の見直し、利用停止を決める人が不明な状態です。所有者を特定できない場合は、既定で稼働を承認せず、利用範囲の制限や一時停止を検討します。

セキュリティ・AIガバナンス担当：影響と証拠で優先順位を決める

どのAgentからリスク評価と認証を始めるべきですか？
顧客に応答するAgent、機密情報にアクセスするAgent、外部ツールで状態を書き換えるAgent、取引や承認に関与するAgentを先に確認します。リスクの区分は、自社のデータ分類、権限、業務への影響、復旧可能性を根拠に決めてください。製品側の表示や分類を、自社の安全認証として扱うのは避けます。

• [ ] 参照・変更できるデータと、データの機微度を記録します。
• [ ] 外部ツールの権限と、実行によって生じる副作用を洗い出します。
• [ ] 人の承認が必要な操作と、自動で実行できる範囲を区別します。
• [ ] リスク判断の根拠、審査担当者、次回の見直し条件を記録します。

生成AIを含むシステムのリスク管理には、NISTの生成AIリスク管理フレームワーク資料と、AI RMF Playbookを参照できます。Agentの権限や操作経路を点検する際は、OWASPのAgentセキュリティ・チェックリストも補助資料になります。どの資料も、自社のリスク判定や認証を代行するものではありません。

運用・品質担当：監視と成果の検証を分ける

監視記録は、稼働状況や利用状況、コスト、挙動の変化を調べる手がかりになります。一方で、業務の結果が正しいこと、コードがテストに合格したこと、成果物が安全に納品されたことまでは証明しません。

Agentの監視記録は、実行権限や隔離環境の代わりになりますか？
なりません。監視は観測された動きを把握する手段です。権限の制限、ネットワークやデータへの到達範囲の分離、書き込み前の承認は、実行環境やアクセス制御で別に設計します。OpenTelemetryが説明するテレメトリーのシグナルも、観測データの種類を整理する参照資料であり、実行を遮断する仕組みではありません。

• [ ] 健康状態、利用状況、コスト、品質、挙動変化ごとに確認するデータを定めます。
• [ ] データ欠損や監視停止を検知したときの担当者と手動確認手順を決めます。
• [ ] 業務結果は、テスト、レビュー、承認記録など監視とは別の証拠で確認します。
• [ ] 監視できない間に許可する操作を限定し、復旧後の再確認を定めます。

高リスクAgentは、変更と結び付く証拠を残します

認証記録は「承認済み」という状態だけでは不十分です。どのAgentのどのバージョンや設定を、誰が、どの根拠で確認したのかを追跡できる形にします。プロンプト、モデル、データ接続、ツール権限、実行環境が変わったときに、以前の審査結果をそのまま流用できるかも明確にしてください。

• [ ] リスク評価、テスト結果、承認者、見直し責任者を記録します。
• [ ] 証拠をAgentのバージョンまたは設定変更と関連付けます。
• [ ] 変更後に再試験や再承認が必要となる条件を定めます。
• [ ] 証拠が足りない場合は、範囲の制限、追加試験、高影響操作の停止から対応を選びます。

運用側は、台帳にある利用量やコストを業務価値、リスク、担当者の状況と合わせて確認します。コストの説明がつかないAgentや、リスクが高いのに審査証拠がないAgentは、優先順位を上げるべき対象です。メーカーの機能説明だけから、自社の節約額や必要な実行環境の容量を推算せず、実際のタスク記録と検証結果を使って判断してください。

棚卸し結果から、次の対応を選びます

次の表は製品機能の比較ではなく、企業が収集した証拠に基づいて対応を決めるための整理です。

実務では、まず台帳を作り、所有者と用途を確認し、影響に基づいて審査順を決めます。その後、監視と成果検証、権限・隔離、変更時の認証記録を分けて点検します。Dataiku Agent Managementの正式公開後は、自社台帳と製品の検出範囲・記録を照合してください。未確認の環境や不一致が残っているなら、製品画面に表示されないことを理由に対象外とは判断しないでください。

既存のコンテナやクラウド環境で十分な案件もあります。一方、実行権限が広い、隔離の根拠がない、監視しか確認できない場合は、運用環境を見直す必要があります。特にmacOS専用のビルドや署名など、実機のMacツールチェーンが必要な作業では、汎用環境だけで検証できるとは限りません。該当案件は、実行手順と分離境界を先に定めたうえで、必要な期間だけvmzigのMacレンタル環境を検証候補に加えると、台帳上の環境要件と実際の交付条件を照合できます。