サンドボックス化されたPythonと制御されたパッケージアクセスでAIデータアナリストを構築する

サンドボックス化されたPythonと制御されたパッケージアクセスでAIデータアナリストを構築する

AIデータアナリストは、ユーザーが提供するデータセット、モデル生成コード、パッケージインストール、生成されたチャート、ダウンロード可能な出力を、隔離された監視可能な環境で実行する必要がある場合、サンドボックス化されたPythonを必要とします。実用的な実装フローは次のとおりです:ファイルをアップロードし、信頼できるコードでスキーマを検査し、モデルに計画を依頼し、生成されたPythonをレビューし、制約付きサンドボックスで実行し、出力アーティファクトを検証し、ユーザーに何が起こったかを表示します。

AIデータアナリストのアーキテクチャ:アップロード、分析、レビュー

製品パターンは表面上シンプルです。ユーザーがCSVをアップロードし、自然言語で質問すると、有用なテーブル、チャート、ダウンロード可能なファイルが期待できます。内部では、アプリは実際の副作用を伴う小さなエージェントワークフローを実行しています。モデルは分析を計画しPythonのドラフトを作成し、アプリケーションはどのコード、パッケージ、ファイル、ネットワークアクセス、出力を許可するかを決定します。

最初のバージョンは、1つの明確なパスを中心に構築します:

  1. 1つの分析ジョブに対してCSVアップロードを受け付ける。
  2. ジョブスコープのサンドボックスワークスペースを作成する。
  3. モデルにPythonを依頼する前に、所有するスキーマ検査コードを実行する。
  4. モデルに分析計画を依頼し、次にファイルとパッケージのルールに従うスクリプトを依頼する。
  5. 時間、メモリ、ディスク、パッケージ、ネットワークの制限付きでスクリプトを実行する。
  6. 既知の出力ディレクトリから検証済みアーティファクトのみを収集する。
  7. 回答、チャート、警告、ログ、ダウンロード用に選択されたファイルをユーザーに表示する。

この分離により、責任が明確になります。モデルは分析を提案し説明します。バックエンドは製品ポリシーとオーケストレーションを適用します。サンドボックスは、ファイル、パッケージ、時間、メモリ、ネットワークアクセス、シークレットを制約してコードを実行します。

データ分析用のPythonサンドボックス内で何が実行されるか?

分析ワークスペースはメインのアプリケーションサーバー内ではなく、サンドボックス内に配置します。サンドボックスは、1つの分析ジョブに対して、アップロードされたファイル、小さなマニフェスト、生成されたスクリプト、承認されたランタイム設定など、狭い入力バンドルを受け取る必要があります。アプリケーションバックエンドは、認証、課金、ユーザーID、長期ストレージ、本番シークレットをそのワークスペースの外部に保持する必要があります。

AIデータアナリストの場合、サンドボックスは通常、次のタスクを担当します:

サンドボックスタスク なぜそこに属するか
ファイルステージング アップロードされたCSVは、Pythonが触れる前にスキャンされ、隔離された作業ディレクトリにコピーされます。
スキーマ検査 アプリは、列名、型、NULL率、行数、サンプル値を、ファイル全体をモデルに公開せずに推測できます。
Python実行 モデル生成コードはアプリケーションサーバーから離れて実行され、タイムボックス化できます。
パッケージ準備 承認された依存関係のみがジョブにインストールまたは利用可能になります。
チャートレンダリング プロット画像はファイルとして書き込まれ、ダウンロード前にレビューされます。
結果のパッケージング 最終的なアーティファクトは、既知の出力ディレクトリから収集されます。
クリーンアップ 一時ファイル、生成コード、セッション状態は削除または期限切れにできます。

モデルのプロンプトはデータよりも小さく保ちます。スキーマのサマリー、ポリシーが許せば代表的な数行、列の説明、ユーザーの意図、「モデルを訓練しない」「承認されたパッケージのみ使用する」などの制約を送信します。生のデータセットは、製品に特別な理由がない限り、サンドボックスファイルシステムに残しておくべきです。

CSVアップロードとスキーマ検査はどのように機能すべきか?

すべてのアップロードを信頼できない入力として扱うことから始めます。モデルが関与する前に、ファイルタイプ、サイズ、エンコーディング、区切り文字、行数、列数、疑わしい数式を検証します。CSVには、後で開かれたときにスプレッドシートの数式実行をトリガーする値が含まれる可能性があるため、エクスポートファイルもターゲット形式に合わせてサニタイズする必要があります。

実用的なアップロードフローは次のようになります:

  1. ユーザーがアプリにCSVをアップロードします。
  2. バックエンドは元のファイルをジョブスコープのオブジェクトキーまたはステージングパスに保存します。
  3. バックエンドはジョブ用のサンドボックスセッションを作成します。
  4. バックエンドはファイルをサンドボックスの作業ディレクトリにコピーします。
  5. 小さな決定論的な検査スクリプトがファイルを読み取り、スキーマサマリーを生成します。
  6. モデルはスキーマサマリー、ユーザーの質問、許可されたライブラリ、出力要件を受け取ります。

検査ステップは、モデル生成コードではなく、自分が所有する決定論的なコードであるべきです。次のようなコンパクトなJSONサマリーを生成できます:

{
  "file": "sales.csv",
  "rows": 84231,
  "columns": [
    {"name": "order_date", "type": "date", "null_rate": 0.01},
    {"name": "region", "type": "string", "sample_values": ["NA", "EMEA", "APAC"]},
    {"name": "revenue", "type": "number", "null_rate": 0.0}
  ],
  "safe_sample_rows": 5
}

このサマリーは、データセット全体を渡さずにモデルが分析をドラフトするのに十分なコンテキストを提供します。機密性の高いワークロードでは、サンプル値を減らしたり削除したり、列をマスクしたり、ユーザーが使用できる列を承認する必要がある場合があります。

モデルはどのように安全にPythonを生成して実行するか?

モデルはコードを生成する前に計画を生成する必要があります。良い計画は、使用する列、実行する変換、作成するチャート、書き込む出力ファイルを指定します。これにより、アプリケーションにポリシーとユーザーレビューのためのチェックポイントが提供されます。

計画が承認されたら、狭い契約に従うPythonを要求します:

  • 入力ファイルは input/ ディレクトリからのみ読み取る。
  • アーティファクトは output/ ディレクトリにのみ書き込む。
  • 承認されたパッケージのみを使用する。
  • ジョブポリシーが明示的に許可しない限り、ネットワーク呼び出しを避ける。
  • 最後に構造化されたサマリーを出力する。
  • 必要な列がない場合は明確に失敗する。

概念レベルでは、オーケストレーションループは次のようになります:

job = create_analysis_job(user_id, uploaded_file)
sandbox = create_sandbox(job_id=job.id, timeout_seconds=300)

copy_file_to_sandbox(uploaded_file, sandbox_path="/work/input/data.csv")
schema = run_owned_schema_inspector(sandbox, "/work/input/data.csv")

plan = ask_model_for_analysis_plan(
    user_question=job.question,
    schema=schema,
    allowed_packages=["pandas", "numpy", "matplotlib"],
    output_contract={"directory": "/work/output", "formats": ["png", "csv", "json"]},
)

review_policy(plan)

script = ask_model_for_python(plan=plan, schema=schema)
review_static_code_policy(script)

result = run_python_in_sandbox(
    sandbox=sandbox,
    script=script,
    working_dir="/work",
    timeout_seconds=120,
    memory_limit_mb=1024,
)

artifacts = collect_outputs(sandbox, "/work/output")
review_outputs(artifacts)
return_answer_to_user(result.summary, artifacts)

これは疑似コードであり、製品SDKの契約ではありません。重要なのは境界です。生成されたコードはレビューされ、タイムアウト付きで実行され、既知のディレクトリに制約され、出力の収集とレビューが続きます。

スクリプトが失敗した場合は、エラーメッセージと小さなコード抜粋をモデルに送り返して修復を依頼します。無制限のログを送信しないでください。エラー修復は、最初の試行と同じパッケージ、ファイル、ネットワーク、出力ポリシーを維持する必要があります。

AIデータ分析のための制御されたPythonパッケージアクセス

パッケージアクセスは、多くのAIデータアナリストデモがリスクを伴う部分です。モデルは、チュートリアルで見たから、パッケージ名がもっともらしく見えるから、またはユーザーのプロンプトがそれを示唆したから、ライブラリを要求する可能性があります。アプリはこれらの提案を無制限のパッケージインストールに変えるべきではありません。

データの機密性に一致するポリシーを使用します:

パッケージポリシー 最適な用途 トレードオフ
プリビルドイメージのみ 予測可能な分析ニーズを持つ本番ワークロード 最低限の柔軟性、最もシンプルなレビュー対象
許可リスト化されたパッケージ ほとんどのCSV分析アシスタント pandas、プロット、一般的な統計パッケージに適したバランス
バージョン固定インストール 再現可能な分析ジョブ パッケージメンテナンスと脆弱性レビューが必要
キャッシュされた内部ミラー エンタープライズまたは規制対象のデータワークフロー より多くの運用作業、サプライチェーンへのより良い制御
ユーザー承認インストール 信頼されたユーザー向けの探索ツール より柔軟だが、速度が遅く明確な警告が必要

最初の本番バージョンでは、プリビルド環境または短い許可リストから始めます。ほとんどのCSVの質問は、pandasnumpymatplotlibseabornscipy、場合によってはscikit-learnなどの小さなライブラリセットで回答できます。ジョブが別のパッケージを必要とする場合は、モデルに理由を説明させ、そのリクエストを人間の承認またはパッケージレビューワークフローにルーティングします。

パッケージ名、バージョン、ソースレジストリ、インストール時間、パッケージが要求された理由をログに記録します。セキュリティチームが依存関係スキャナーやプライベートレジストリを使用している場合は、エージェントにそれをバイパスさせるのではなく、そのプロセスと統合します。

チャートと出力ファイルの検証方法

生成されたファイルは製品体験の一部ですが、信頼の境界の一部でもあります。チャートは間違っている可能性があります。CSVには数式のような値が含まれている可能性があります。ノートブックには隠されたコードが含まれている可能性があります。ZIPには予期しないパスが含まれている可能性があります。出力をダウンロードするだけのファイルではなく、検査するアーティファクトとして扱います。

シンプルな出力契約を定義します:

{
  "required_files": ["summary.json"],
  "optional_files": ["chart-*.png", "filtered-data.csv"],
  "blocked_extensions": [".exe", ".sh", ".bat", ".html"],
  "max_total_size_mb": 25
}

完了した各ジョブについて、期待される出力ディレクトリからのみファイルを収集します。MIMEタイプ、拡張子、サイズ、パスを検証します。画像の場合は、プレビュー用のサムネイルを生成します。CSVエクスポートの場合は、ファイルがExcelやGoogle Sheetsで開かれる可能性がある場合、スプレッドシートの数式をエスケープします。JSONサマリーの場合は、UIで使用する前にスキーマに対して検証します。

結果をダウンロードまたは共有する前に、ユーザーにレビューステップを提供します。レビュー画面には以下が表示されるべきです:

  • 元の質問。
  • 使用されたデータセット名とスキーマ。
  • 平易な言葉での分析手順。
  • 生成されたチャートとテーブル。
  • ポリシーの理由で除外された列。
  • 警告、エラー、再試行、またはパッケージリクエスト。

モデルはナラティブな説明を書くことができますが、アプリはその説明をサンドボックス実行からのファイルとログに基づいて裏付ける必要があります。

本番前のセキュリティチェックポイント

AIデータアナリストは、セキュリティチームとプラットフォームチームが何を許可されているかを推論できる場合にのみ、有用な内部ツールとなります。レビューでは、分離、リソース制限、パッケージポリシー、ネットワーク動作、シークレット、ログ、削除をカバーする必要があります。

プロトタイプを超える前に、次のチェックリストを使用します:

チェックポイント 答えるべき質問
分離境界 あるユーザーのコードとファイルをホストや他のユーザーから分離するものは何か?
ファイルアクセス 生成コードはジョブディレクトリのみを読み取れるか、それともより広いストレージを見ることができるか?
リソース制限 CPU時間、メモリ、ディスク、プロセス数、ウォールクロック時間を制限するものは何か?
ネットワークポリシー 送信ネットワークアクセスはオフか、許可リスト化、プロキシ経由、または完全にオープンか?
パッケージポリシー どのパッケージを、どこから、どのバージョン管理でインストールできるか?
シークレット境界 APIキー、データベース資格情報、サービストークンは、明示的にスコープ設定されない限り、サンドボックスの外に保たれるか?
ログ コマンド、パッケージインストール、エラー、ファイル読み取り/書き込み、出力アーティファクトが記録されるか?
人間によるレビュー どの計画、コードスニペット、パッケージリクエスト、出力に承認が必要か?
クリーンアップ サンドボックス状態、アップロードファイル、生成スクリプト、ログ、出力はいつ削除されるか?

「コードは逃げられない」「データは漏洩しない」などの絶対的な主張は避けます。実用的な基準はより具体的です。境界を定義し、制御を文書化し、障害モードをテストし、予期しない動作を調査するための十分な監査証跡を保持します。

ネットワークとパッケージポリシーについては、依存関係のインストールは、パッケージがプリビルドイメージまたは管理されたミラーから提供されない限り、ネットワークエグレスの一種であることを覚えておいてください。データセットが機密性の高い場合、ネットワークアクセスはデフォルトでブロックされるか、厳密に許可リスト化されるべきです。アナリストがライブの外部データを必要とする場合は、独自の承認とログパスを持つ別のツールにします。

Novita Agent Sandboxを実行レイヤーとして使用する

Novita Agent Sandbox は、AIエージェント向けの分離されたステートフルな実行環境を提供します。現在のNovitaドキュメントでは、コードの実行、依存関係のインストール、ファイルへのアクセス、ブラウザの使用、セッション間での実行状態の保持をサポートしていることが説明されています。AIデータアナリストにとって、これらのプリミティブはアーキテクチャの実行部分に直接マッピングされます。ジョブワークスペースを作成し、ファイルを移動し、分析コードを実行し、アーティファクトを収集し、セッション設計に基づいて状態をクリーンアップまたは保持します。

Novita Agent Sandbox SDKおよびCLIドキュメント では、PythonとJavaScript/TypeScriptの公式SDKサポートがリストされており、一般的なアプリケーションバックエンドに適合します。サンドボックスファイルシステムのドキュメント では、サンドボックス用に固定20 GBのストレージスペースを持つ分離されたファイルシステムについて説明されており、ジョブスコープのワークスペース内でCSVファイルと生成されたアーティファクトをステージングするのに役立ちます。

区別を明確に保ちます:

  • この記事の実装ガイダンスは、AIデータアナリストアプリの一般的なアーキテクチャを説明しています。
  • Novita Agent Sandboxは、それらのワークフローにサンドボックス実行レイヤーを提供できます。
  • アプリケーションは依然として、ユーザー認証、データ保持ポリシー、パッケージ承認、ネットワークポリシー、出力レビュー、公開/デプロイメントの決定を担当します。

この分離は、チームがクリーンな責任モデルで構築するのに役立ちます。モデルは分析を提案し説明します。アプリケーションは製品ポリシーを適用します。サンドボックスは、コード、ファイル、パッケージ、チャート、ログをメインのアプリケーションサーバーから離れて処理できる制御されたランタイムを提供します。

結論

最も強力なAIデータアナリストの設計は、「モデルにPythonを実行させる」ことではありません。それは制御されたループです:データセットを検査し、モデルに計画を依頼し、生成されたコードをレビューし、サンドボックスで実行し、検証済みアーティファクトを収集し、ユーザーに何が起こったかを表示し、ジョブが完了したら状態をクリーンアップします。この構造は、ユーザーエクスペリエンスを高速に保ちながら、エンジニアリングチームとセキュリティチームに本番前に評価する具体的なチェックポイントを提供します。

このパターンを構築するチームは、小さく始めることをお勧めします:CSVアップロード、スキーマ検査、短いパッケージ許可リスト、チャート出力、厳格なタイムアウト、可視的なレビュー画面。境界が文書化されテストされた後にのみ、より広範なパッケージアクセス、ネットワークツール、永続性、自動化を追加します。

FAQ

AIデータアナリストにサンドボックスが必要なのはなぜですか?

ワークフローが信頼できないファイル、モデル生成Python、パッケージリクエスト、チャート生成、ダウンロード可能なアーティファクトを組み合わせるため、サンドボックスが必要です。その作業を別の環境で実行することで、アプリはファイル、リソース、パッケージ、ネットワーク、ログ、クリーンアップの制御を適用する場所を得られます。

モデルは完全なCSVを見るべきですか?

通常はいいえ。モデルにはスキーマサマリー、安全なサンプル、列の説明、ユーザーの質問を送信することから始めます。製品にモデルにより多くのデータを公開する正当な理由がない限り、生のファイルはサンドボックスに保持します。

パッケージインストールは許可できますか?

はい、ただし制御されるべきです。プリビルドイメージ、許可リスト、固定バージョン、プライベートミラー、または承認ワークフローを使用します。モデル生成コードに、レビューなしでパブリックインターネットから任意のパッケージをインストールさせてはいけません。

アプリはどのファイルをユーザーに返すべきですか?

チャート画像、サマリーJSON、サニタイズされたCSVエクスポートなど、既知の出力ディレクトリからの検証済みファイルのみを返します。予期しない拡張子、大きなファイル、隠しパス、出力契約の一部ではなかったアーティファクトはブロックします。

これはコンプライアンスの保証ですか?

いいえ。サンドボックスは実行アーキテクチャの一部です。コンプライアンスとセキュリティの承認は、データ、脅威モデル、制御、ログ、保持、レビュープロセス、デプロイメント環境に依存します。

おすすめ記事