G-genの本間です。当記事では、Gemini Enterprise Agent Platform（略称 Agent Platform）が提供する、フルマネージドの AI エージェント実行基盤である Agent Runtime へ、エージェントをデプロイする際のデプロイ手法について解説します。 はじめに Agent Platform とは Agent Runtime とは 当記事について 5つのデプロイ手法 概要 1. Developer Connect を使用してデプロイする 2. ソースファイルからデプロイする 3. Dockerfile を使用してデプロイする 4. コンテナイメージを使用してデプロイする 5. Agent Platform SDK オブジェクトからデプロイする 選び方と使い分け はじめに Agent Platform とは Gemini Enterprise Agent Platform（旧称 Vertex AI、略称 Agent Platform ）は、AI エージェントを構築、管理、実行するために必要な機能を提供する Google Cloud の統合プラットフォームです。 このうち、エージェントの統制を担う機能として、エージェント固有の ID を発行する Agent Identity 、エージェントやツールを登録して検出可能にする Agent Registry 、これらを参照して通信を制御する Agent Gateway があります。 Agent Platform の全体像については、以下の記事を参照してください。 blog.g-gen.co.jp Agent Runtime とは Agent Runtime は、Agent Platform に内包されたプロダクトの1つで、エージェントを実行するためのフルマネージドの実行基盤です。Agent Runtime では、組み込みの機能として、エージェントのマルチターン会話を実現するセッション機能や自動スケーリング機能、その他エージェントの機能拡張・運用管理に必要な様々な機能を使用できます。 Agent Runtime の全体像については、以下の記事を参照してください。 blog.g-gen.co.jp 当記事について Agent Runtime に対してエージェントをデプロイするにあたり、デプロイ手法を5つのうちから選択できます。当記事では、それら5つの手法について概要を説明します。 参考 : Deploy an agent 5つのデプロイ手法 概要 Agent Runtime で使用可能な5つのデプロイ手法の概要は、以下のとおりです。 No. 名称 概要 1. Developer Connect を使用してデプロイ Developer Connect を介してリンクされた Git リポジトリから直接ソースコードを取得してデプロイする手法。 2. ソースファイルからデプロイ ローカルファイルシステム上のソースコードから直接デプロイする手法。 3. Dockerfile を使用してデプロイ ローカルのソースコードと Dockerfile を送信し、Agent Runtime 側でコンテナイメージを自動でビルドしてデプロイする手法。 4. コンテナイメージを使用してデプロイ Artifact Registry にホストされているコンテナイメージを指定してデプロイする手法。 5. Agent Platform SDK オブジェクトからデプロイ Colab などのノートブック環境で定義されたインメモリのエージェントオブジェクトを直接 Agent Platform SDK の関数に渡してデプロイする手法。 なお 2026年10月現在、Agent Runtime は Google Cloud コンソールや標準の gcloud CLI からの直接デプロイには対応していないため、いずれの方式を選択した場合でも、基本的には Agent Platform SDK （または REST API / ADK CLI）を使用し、コードベースでデプロイを実行する必要があります。 また5つのうち、いくつかの手法では、Terraform を用いたエージェントのデプロイや、インフラ基盤の設定管理も可能です。 1. Developer Connect を使用してデプロイする Google Cloud と GitHub や GitLab などの外部のソースコード管理システムを連携・統合するためのサービスである Developer Connect を使用し、Git リポジトリから直接デプロイする方式です。事前にリポジトリの接続設定を実施したうえで、Agent Platform SDK の developer_connect_source パラメータにリポジトリやブランチを指定してデプロイします。 この方式の場合、エージェントの実装に使用できるプログラミング言語は Python のみです。Developer Connect で Git リポジトリを接続する工数は発生しますが、Git 連携が可能となるため、バージョン管理と連動した継続的デリバリーの自動化に適しています。 参考 : Developer Connect の概要 2. ソースファイルからデプロイする ローカル環境のソースファイルから、Agent Platform SDK を使用して Agent Runtime へ直接デプロイする方式です。デプロイ実行時に、対象の開発ディレクトリやエントリーポイント、公開するメソッド定義を指定します。 この方式の場合も、エージェントの実装に使用できるプログラミング言語は Python のみです。Infrastructure as Code（以下、IaC）や GitHub Actions / Cloud Build などの標準的な CI/CD パイプラインに組み込むワークフローと親和性があり、他の選択肢と比較して導入工数が低い点が特徴です。ただし、デプロイ実行時に指定する開発ディレクトリの合計ファイルサイズが 8MB を超えてはいけないという制限があるため、仮想環境ディレクトリや巨大なアセットが含まれないよう注意が必要です。 3. Dockerfile を使用してデプロイする ローカルのソースファイルとともに、 Dockerfile を指定し、Agent Runtime 側でコンテナイメージの自動ビルドとデプロイを実行させる方式です。 この方式では、エージェントの実装に Python 以外のプログラミング言語を使用できます。また、コンテナ環境を定義できるため、OS レベルでのシステムパッケージのインストールや、エージェントをホストする API サーバーの細かい制御が必要な場合にも適しています。なお、ビルドされるコンテナは Agent Runtime が定める所定のランタイム契約（Runtime contract）に準拠している必要があります。詳細は以下の公式ドキュメントを参照してください。 参考 : Agent Platform runtime contract 4. コンテナイメージを使用してデプロイする 事前に Artifact Registry にビルド済みのコンテナイメージを push し、Agent Platform SDK でイメージ URI を指定して Agent Runtime へデプロイする方式です。実行にあたっては、Agent Platform のサービスエージェントに対して、対象の Artifact Registry の読み取り権限を付与する必要があります。 「Dockerfile を使用してデプロイする」方式と同様に、Python 以外のプログラミング言語でもエージェントの実装が可能であり、ランタイム契約への準拠が必要です。 Dockerfile 方式との主な違いは、 デプロイ時に Agent Runtime 側でビルドするか、事前ビルドしたイメージをデプロイするか という点です。「コンテナイメージを使用してデプロイする」方式は事前ビルドが完了しているため、デプロイ時のパッケージインストール等による待ち時間を最小化できます。 こちらの方式は、CI パイプライン上でコンテナの脆弱性スキャン等のセキュリティツールを通過したイメージのみを本番環境にデプロイするといった、厳格なガバナンス要件や「基盤管理と開発管理の分離」が求められるエンタープライズ環境に適しています。 参考 : Set up the environment - Identity and permissions 5. Agent Platform SDK オブジェクトからデプロイする Colab Enterprise や Agent Platform Workbench などのノートブック環境で定義したメモリ上の Python オブジェクトを、直接 Agent Platform SDK の関数に渡してデプロイする方式です。Python の pickle を用いてメモリ上のエージェントオブジェクトをシリアライズし、Cloud Storage バケットへアップロードします。その後、アップロードされたファイルをもとにコンテナがビルドされます。 この方式では、ノートブック環境でコードを書いて、その場でインタラクティブに動作検証や初期プロトタイピングを手軽に行えます。一方、シリアライズできない複雑なデータ構造や依存関係を持つオブジェクトには適用できず、手動実行が前提となるため、CI/CD パイプラインへの組み込みには適していません。 また、エージェントの実装に使用できるプログラミング言語は Python のみです。 参考 : Introduction to Colab Enterprise 参考 : Introduction to Agent Platform Workbench 選び方と使い分け ここまで紹介した Agent Runtime への5つのデプロイ手法は、主にそれぞれ 「エージェントの対応言語」「Cloud Storage バケットの要否」「カスタマイズ性」「CI/CD や IaC との親和性」 に違いがあります。 開発フェーズ（初期のプロトタイピングか、本番の CI/CD 運用か）や、チームが採用するプログラミング言語・セキュリティ要件に合わせて、以下の比較表を参考に最適なデプロイ手法を選択してください。 名称 エージェントの対応言語 Cloud Storage バケット CI/CD・IaC 適性 主なユースケース 主な特徴・制約事項 Developer Connect を使用してデプロイ Python のみ 不要 ◎ Git リポジトリと直結した継続的デリバリー Developer Connect の事前設定が必要。リポジトリから直接コードを取得してデプロイするため、複雑な事前ビルド処理を伴う運用には不向き。 ソースファイルからデプロイ Python のみ 不要 ◎ Terraform や GitHub Actions 等を用いた標準的な本番運用 Pickle 化を行わないため依存関係の再現性が高く、導入工数も低い。送信するソースコード合計サイズに 8MB の制限 あり。 Dockerfile を使用してデプロイ 任意の言語 （Go や Java 等も可） 不要 ◯ OS パッケージの追加や、Python 以外の言語を使用する場合 クラウド側でコンテナを自動ビルド。ランタイム契約への準拠が必要。 コンテナイメージを使用してデプロイ 任意の言語 （Go や Java 等も可） 不要 ◎ 厳格な脆弱性スキャンや、デプロイ時間短縮が求められる本番環境 Artifact Registry のビルド済みイメージを指定するため、デプロイ時のレイテンシが小さい。サービスエージェントへの権限付与とランタイム契約への準拠が必要。 Agent Platform SDK オブジェクトからデプロイ Python のみ 必須 △ Colab Enterprise 等のノートブック環境での初期プロトタイピング・検証 メモリ上のオブジェクトを pickle で直感的にデプロイ可能。シリアライズできない複雑な構造や CI/CD への組み込みには不向き。 どの方式を採用すべきか迷った場合は、開発のフェーズやプロジェクトの要件を整理したうえで検討してください。 手軽に動作を試したい初期検証フェーズの場合は、ノートブック環境からすぐに実行できる 「Agent Platform SDK オブジェクトからデプロイ」 や、比較的導入コストが低い 「ソースファイルからデプロイ」 から始めることを推奨します。 Python で開発したエージェントを本番運用へ移行し、CI/CD パイプラインへ組み込むフェーズでは、導入コストが低く Terraform などの IaC ツールとも組み合わせやすい 「ソースファイルからデプロイ」 、あるいは Git 連携の機能を十分に発揮できる 「Developer Connect を使用してデプロイ」 が選択肢に入ります。 Go や Java といった Python 以外のプログラミング言語でエージェントを実装する場合や、OS レベルのライブラリ追加といった環境カスタマイズが求められる場合には、 「Dockerfile を使用してデプロイ」 または 「コンテナイメージを使用してデプロイ」 を選択します。特にエンタープライズの本番環境において、CI パイプラインでのコンテナ脆弱性スキャンを必須とする場合や、スケーリング・デプロイ速度、基盤管理と開発管理の分離を重視する場合には、 「コンテナイメージを使用してデプロイ」 の採用が最適です。 本間 優太郎 (記事一覧) クラウドソリューション部 クラウドエンジニアリング2課 北海道在住 2026年6月に G-gen にジョイン。前職では社内SE、Sler としてアプリ/インフラ開発業務に従事。アプリ/インフラ双方の経験をベースに現在はGoogle Cloudの学習を進めている。 好きなことは子供と遊ぶこと、ゲームをすること。

ℹ️ この記事について この記事に出てくるコードとスクリーンショットは、すべて 検知の挙動を確かめるために用意した検証用のサンプル です。 実際のサービスのコードではありません。 ツールが反応するかを見るために意図的に脆弱に書いているので、 そのまま流用しないでください。 はじめに こんにちは、タイミーのプラットフォームエンジニアリング1グループに所属している久慈です。 この記事では、全社のソースコード向け SAST（静的アプリケーションセキュリティテスト）の選定で、Amazon Inspector Code Security と GitHub Advanced Security（以下 GHAS）の GitHub Code Security を、同じ検証用コードで比較した結果を紹介します。検知結果に加え、言語対応や運用、コストを評価し、GHAS を選んだ理由をまとめます。GitHub Code Security の Code Scanning では CodeQL を解析エンジンとして使いました。以下、検知結果については「CodeQL」、修正提案やマージ保護、組織単位の設定といった周辺機能も含む比較では「GitHub Code Security」と書き分けます。 どの SAST ツールが自社の要件に合うのかは、公式の機能表だけでは分かりません。どのドキュメントにも「主要な脆弱性を検出します」と書いてありますし、対応言語表のチェックの付き方も似たようなものです。 結論から言うと、 同じ脆弱コードを両方に流してみて初めて差が見えました 。その過程で得たものを、うまくいかなかったところも含めてできるだけそのまま書いていきます。 アラートの扱いや通知・対応ルールなど、運用設計については別記事で紹介します。 比較した観点と、得られた知見は次のとおりです。 比較した観点 得られた知見 検知結果 検出件数だけでなく、仕込んだ脆弱性との突き合わせが必要 全社要件への適合 言語対応に加え、修正提案や PR 上の挙動にも差がある コスト 課金軸が異なり、スキャン構成やリポジトリサイズの仮定が試算を左右する 以下は検証時点の設定・環境で確認した結果です。製品の機能や挙動は変更される可能性があるため、現在の仕様は各公式ドキュメントをご確認ください。 全社で共通して運用できることを評価の前提にした 今回の比較では、個別のリポジトリだけでなく、 全社で共通して運用できること を評価の前提にしました。社内には複数の言語で書かれたリポジトリがあり、規模や変更頻度も異なります。 1リポジトリにとっての最適解と、全社で運用するときの最適解は別物です。 ツールの評価では、検知機能だけでなく、その周辺の運用も見ておく必要があります。CI のパイプラインへの組み込み、開発者への結果の伝え方、通知経路や対応ルール。リポジトリごとに別のツールを使えば、こうした設定や周知もそれぞれ必要になります。 AWS を利用している当社にとって、Amazon Inspector Code Security は候補の一つでした。SAST に加え、SCA（依存関係の脆弱性検査）や IaC のスキャンもまとめて扱える点は魅力です。一方で、AWS との親和性だけでは、全社のソースコード向け SAST として要件に合うかは判断できません。 そこで、言語対応や検知結果に加え、開発者へのフィードバックや設定・通知の運用まで含めて比較することにしました。 ソースコードを外部に送るということ 機能比較の前に、もうひとつ整理しておきたいことがありました。解析をどこで実行し、ソースコードや検出結果がどこに送信・保存されるかです。SAST 自体が外部へのコード送信を必須とするわけではありませんが、外部サービスを利用する構成では、サービス側に渡る情報の範囲と扱いを確認する必要があります。 自社のセキュリティ評価では、機能要件とは別に次のような論点を見ました。 論点 見たこと コードの保存 スニペットがサービス側に保存されるか、保存先リージョンはどこか 学習利用 送ったコードの扱いが契約・利用規約でどう定められているか（競合目的での利用禁止の記載など） 準拠証明 SOC 2 / PCI DSS 等、提示できる準拠情報があるか アクセス範囲 ツールが読めるリポジトリの範囲を絞れるか 外部サービスの評価では、コードや検出結果の取り扱いに加え、 シークレット保護との組み合わせ も評価項目に含めました。SAST の検知機能だけでなく、シークレット保護も含めた設定や通知、開発者へのフィードバックをどう運用できるかを比較しました。 Amazon Inspector Code Security を検証した 前提が整ったので、まず Inspector を実際に動かしました。 検証用のリポジトリを用意して、意図的に脆弱なコードを仕込んだ PR を作ってスキャンさせる、というやり方です。仕込んだのは SQL インジェクション、コマンドインジェクション、XSS、パストラバーサル、弱いハッシュ関数、それに古い依存パッケージと Terraform のミスコンフィグです。 検出件数 スキャン種別 検出件数 内訳 SCA（依存関係） 18件 Critical 3 / High 15 SAST（コード） 9件 Critical 1 / High 8 SCA は古いパッケージを入れておけば素直に出ます。SAST も主要なものは拾ってくれました。ここまでは想定通りです。 動かして分かった挙動のクセ 細かい実務寄りの話ですが、先に知っておきたかったポイントです。なお、以下はいずれも検証時点の当社環境で確認した振る舞いです。 1. PR を契機にしたスキャンとデフォルトブランチのスキャンで結果の出力先が違う 今回検証した Inspector Code Security のリポジトリ連携では、PR を契機にしたスキャンと、デフォルトブランチのスキャンで結果の見える場所が違うので、どちらを主に使うかを最初に決めておかないと、「この指摘はどこを見ればいいのか」が分かりにくくなります。 実際の画面で見るとこうなります。まず、脆弱なコードを含む PR を作成し、リポジトリ連携のスキャンを実行すると、結果は bot の PR コメントとして返ってきます。 Inspector の指摘は bot による PR コメントで届く 一方、同じリポジトリを AWS コンソールで見ると、検出結果は0件のままです。 AWS コンソール側の同じリポジトリ。デフォルトブランチのスキャンは走っているが、検出結果は0件 コンソールが見ているのはデフォルトブランチのスキャン結果なので、PR ブランチにだけ入れた脆弱コードはここには出てきません。設定どおりの振る舞いですが、「コンソールの一覧を見れば全部把握できる」と思っていると取りこぼします。コンソール側に集約したいなら、デフォルトブランチへのマージ後のスキャンか定期スキャンを前提に設計することになります。 2. PR への追加コミットでは再スキャンされない Amazon Inspector のリポジトリ連携では、既存の PR に追加コミットしても再スキャンはトリガーされません。新しいスキャンを実行するには、PR を close → reopen する必要があります。公式ドキュメントでも、この挙動が説明されています。今回の検証でも同じ結果になりました。 sequenceDiagram participant Dev as 開発者 participant PR as Pull Request participant IS as Inspector Dev->>PR: PR を作成 PR->>IS: スキャン実行 IS-->>PR: 指摘コメント Dev->>PR: 修正を push Note over PR,IS: 再スキャンされない Dev->>PR: close → reopen PR->>IS: スキャン実行 IS-->>PR: 指摘が解消 「修正したのに指摘が消えない」という状態は、開発者の信頼を失いやすいところだと思います。最終的には「とりあえず close/reopen してください」と案内することになるので、全社展開を考えるとここは軸の一つになりました。 3. 結果は PR コメントとして届く 検出結果は bot による PR コメントで通知されます。フィードバックがコードレビューの文脈に入ってくるのはありがたいのですが、同じ行に複数のコメントが重複して付くことがありました。後述の CodeQL との比較で使った PRでは、再スキャン分も含めて PR 上のコメントが20件を超えました。アラート一覧の画面で見るのとは違うので、件数が多いと PR 上だけで全体像を追うのは難しくなります。 IaC の検証では、PR コメントの見え方に注意が必要だった Terraform のミスコンフィグを仕込んだ検証コードをスキャンしたところ、IAM・暗号化系の4件について PR コメント上で検出を確認できました。 仕込んだ内容 PR コメント上の確認結果 IAM ポリシーの Action: * ✅ 検出を確認：Restrict IAM asterisk action Action: * ＋ Resource: * ✅ 検出を確認：Restrict AWS IAM policy with full administrative privileges RDS の暗号化無効 ✅ 検出を確認：Disabled AWS RDS Encryption EBS ボリュームの未暗号化 ✅ 検出を確認：Unencrypted EBS Volumes S3 のパブリックアクセスブロックを全 false PR コメント上では確認できず セキュリティグループで 0.0.0.0/0 全ポート開放 PR コメント上では確認できず 古いモジュールバージョンの利用 PR コメント上では確認できず 実際の検証 PR の画面です。 検証 PR。IAM・暗号化系の4件について PR コメント上で検出を確認できた ここで注意が必要なのは、 PR コメントだけでは IaC ルール全体の検出可否を評価できない ことです。今回の設定では、PR コメントには Critical / High の検出結果の上位25件のみが表示されます。たとえば S3 のパブリックアクセスブロックに関するルールには Medium のものがあるため、PR コメントに表示されなかったことは未検出を意味しません。 ここで示す結果は、検証時点の設定・環境で PR コメント上に表示された範囲のものです。今回の PR コメントの結果だけで、Inspector の IaC スキャン全体のカバレッジや Terraform 専用ツールの代替可否を断定することはできません。 全社展開を見据えて要件を言語化した Inspector を単体で見ても、「XSS が一つ見逃された」が致命的なのか許容範囲なのかは分かりません。そこで、比較の基準を先に作りました。機能・運用・非機能の3分類で要件マトリクスにして、ツールごとに○×を付けていく形です。 とくに重く見たのは次のポイントです。 社内6言語（Go / TypeScript / Kotlin / Ruby / Python / Swift）をカバーできるか。非対応の言語があると、そのチームだけ別ツールになる 既存コードへの指摘によってマージを一律に止めず、新しい変更で生じた指摘に対処できるか 誤検知を抑えられるか。抑える手段が抜け道になっていないか 修正提案が出るか。指摘だけだと開発者の調査時間がそのまま乗る 通知とダッシュボードが揃っているか。気づける導線がないと放置される 新規リポジトリを自動でスキャン対象にできるか 2つ目は少し説明が必要です。既存コードに対する指摘への対応と、日々の開発を両立できることを重視しました。マージ制御を行う場合は、 既存コードに対する指摘と、新しい変更で生じた指摘を区別し、差分に対してゲートをかけられるか を確認しました。 ツール比較は、誰かが「あっちはここがいいらしい」と言い出すと印象論になりがちですが、要件が先にあれば「それはどの要件の話か」「必須か、あればいいか」に分解できます。候補となるツールを同じ表で評価できたのは、要件をマトリクスとして整理していたからです。 実際に使ったマトリクスから、ポイントになった項目を抜き出したものがこちらです（✅ 満たせる / △ 条件付き・追加設計が必要 / ❌ 満たせない）。評価は、検証時点の Ruby の実地検証と公式ドキュメントに基づくものです。 区分 要件 Inspector GitHub Code Security（解析：CodeQL） 判断の根拠 機能 社内6言語をカバーできる △ ✅ 公式ドキュメントで 5/6 と 6/6。Inspector は Swift が対象外 機能 代表的な脆弱性を検知できる（SQLインジェクション、コマンドインジェクション、XSS） △ ✅ 同じ検証コードで CodeQL は 5/5。Inspector は XSS の見逃しと誤検知 機能 既存の指摘によってマージを一律に止めない ✅ ✅ GitHub Code Security は変更箇所の指摘に基づいてマージをブロック可能。Inspector は指摘の有無にかかわらずマージをブロックしない 機能 修正提案が出る ❌ ✅ Inspector は説明と一般的な対策文まで。修正コード例はない 運用 PR で自動スキャンされ、PR 内で結果を返す △ ✅ Inspector は PR への追加コミットで再スキャンされないケースがあった 運用 新規リポジトリを自動でスキャン対象にできる ✅ ✅ Inspector は GitHub App の対象範囲とデフォルトスキャン設定、GitHub Code Security は org の security configurations で対応可能 この段階で ❌ が付いたのは修正提案の1項目だけです。それ以外は △ の積み上げで、1つずつ見るとそれほど致命的ではないところが難しいところでした。 同じ脆弱コードで CodeQL と比べた 要件マトリクスができたので、次は比較です。GitHub Code Security の Code Scanning を CodeQL で試すことにしました。 やり方はシンプルで、Inspector に流したのと同じ脆弱コードを、そのまま CodeQL にも流すというものです。検証は Ruby のコードを対象に行いました。ツール比較の記事はいくらでもありますが、自分たちで用意した同じ検証コードを両方のツールで解析した結果でないと、要件の○×は埋められません。 検証時の設定は次のとおりです。 ツール セットアップ・実行方式 スキャントリガー CodeQL デフォルトセットアップ デフォルトセットアップの標準設定 Inspector Code Security リポジトリ連携 Pull_request / Push 検知結果 仕込んだのは5パターンです。SQL インジェクション1件、コマンドインジェクション3件（バックティック / %x / system ）、Reflected XSS 1件（ERB テンプレート）。 XSS の検証では、Sinatra の ERB に escape_html: true を設定し、HTML エスケープを有効にしています。そのうえで、 <%== ... %> をエスケープせずに出力する「生出力」として扱う構成にし、リクエストで受け取った値をこの記法で出力しました。エスケープが有効な構成でも、明示的な生出力によって XSS が生じるケースを検証対象にしています。 仕込んだ脆弱性 Inspector CodeQL SQL インジェクション（1件） ✅ 検知 ✅ 検知 コマンドインジェクション（3件） ✅ 検知 ✅ 検知 Reflected XSS（ERB テンプレート・1件） ❌ 見逃し ✅ 検知 誤検知 SQLi / コマンドインジェクションの各行に XSS が重複 なし CodeQL は仕込んだ5件すべてを検知し、意図していないアラートは出ませんでした。 CodeQL のアラート画面。仕込んだ脆弱性が検知されている Show paths ボタンで展開すると、source から sink までのデータフローをたどれる 気になったのは Inspector 側の XSS です。意図して仕込んだ ERB テンプレートの XSS は検知されず、一方で XSS ではない SQLi・コマンドインジェクションの4行すべてに XSS の指摘が重複して付きました 。見逃しと誤検知が同時に起きている状態で、これは件数だけ数えていると気づけません。「XSS を検出している」という集計上は、正しく動いているように見えてしまいます。 ERB テンプレートの XSS はCodeQLでは検知されたが、Inspector では検知されなかった Inspector では SQL インジェクションの行に XSS の指摘も重複して付いた（このコードでは実行結果をHTMLで返していないので、XSSにはなり得ない） 何を検知したかではなく、仕込んだものと検知されたものが一致しているか を1件ずつ突き合わせる必要があります。 検知精度以外の差 観点 Inspector GitHub Code Security（解析：CodeQL） 社内6言語のカバー（公式ドキュメント） 5/6（Swift 非対応） 6/6 修正提案 説明と一般的な対策文（修正コード例はなし） 修正コード例が出る スキャン時間（Ruby） — 約47〜53秒 言語対応は、Amazon Inspector Code Security の対応言語とCodeQL の対応言語・フレームワークを参照しました。表は言語名ベースの対応を示しており、実際にコードを流して確かめたのは Ruby だけです。言語のバージョンやフレームワークごとの制約は、各公式ドキュメントで確認する必要があります。それでも言語カバレッジは要件に直結しました。Swift が非対応だと、モバイルのチームだけ別ツールを使うことになり、運用が二重化します。 修正提案の差も、実運用では地味に効きます。ここで比較しているのは CodeQL 自体の解析機能ではなく、GitHub Code Security 側の修正提案機能です。Inspector 側も脆弱性の説明と一般的な対策文、参考リンクは付きますが、該当行をどう直すかは自分で考えることになります。修正コード例が添えられていれば、少なくとも調べ始める手がかりにはなります。指摘の件数が増えるほど、この差は大きくなります。 GitHub Code Security 側の修正提案機能で、CodeQL の指摘に対する修正コード例を確認できる この比較に使った fixture は、一度作れば使い回せます。別の候補を評価するときも、同じ基準で比較できます。ただ、その fixture 作りでは罠にハマりました。 ［コラム］CodeQL の fixture でハマった話 比較を始めたとき、最初に書いた Ruby の脆弱コードはこんな感じでした。リクエストで受け取った値が name に入ることを想定して、文字列連結で SQL を組み立てています。 def unsafe_query (name) # name に何が渡るかは、この関数だけを見ても分からない DB .execute( " SELECT * FROM users WHERE name = ' #{ name } ' " ) end 絵に描いたような SQL インジェクションです。これを CodeQL に流したところ、 検知は0件でした 。 最初はツールを疑っていました。こんな分かりやすい例が出ないのだから、セットアップが間違っているのか、それとも検知の精度が低いのか。 原因はツールでなく、自分のコードでした。 CodeQL のデータフロー解析は、ユーザー入力の入口（source）から危険な出口（sink）まで値が流れていることを追いかけて初めて脆弱性と判定します。上のコードには sink（ DB.execute ）はあるけれど、source がありません。 name は単なるメソッド引数で、外部から来た値だという根拠がどこにもありません。人間が見れば「いかにも危ないコード」ですが、データフローとしては繋がっていません。 最初は上のようにメソッドだけを書いていました。そこに Sinatra を入れてルーティングを用意し、HTTP のリクエストパラメータから受け取る形に直したところ、あっさり検知されました。 get ' /users ' do name = params[ ' name ' ] # source DB .execute( " SELECT * FROM users WHERE name = ' #{ name } ' " ) # sink end 差は source があるかどうかだけです。 flowchart LR subgraph NG["検知0件"] A1["メソッド引数 name"] -. source なし .-> B1["DB.execute (sink)"] end subgraph OK["検知される"] A2["params['name'] (source)"] -- データフロー --> B2["DB.execute (sink)"] end これに気づくまでしばらく時間を使いました。 「検知されない」と思ったら、まず fixture の書き方を疑う 。少なくとも今回は、こちらのコードが原因でした。SAST の検証コードを書くときは、脆弱な処理だけでなく、外部入力の入口までセットで置く。ルーティングやコントローラを含めて、実際のアプリコードに近い形で書くのが安全です。 コストを試算した 検知精度の比較が終わって、次はお金の話です。ここはかなり悩みました。 先に結論を言うと、デフォルトブランチの作業ツリーを Inspector の課金対象サイズと仮定した今回の試算では、GHAS（Code Security と Secret Protection の合計）と、Inspector の変更ベース＋週次構成の月額は同水準でした。以下で触れる「約120倍」は GHAS との比較ではなく、Inspector 内でスキャン構成を変えた場合の差です。 そもそも、 2つのツールの課金軸がまったく違います 。 GHAS（Code Security ＋ Secret Protection） Inspector Code Security 課金の単位 アクティブコミッター数 スキャン回数 × リポジトリサイズ 伸びる要因 人が増える コミット・コード量が増える 予測しやすさ 高い（人数は読める） 低い（構成次第で桁が動く） 人数課金と従量課金を比べるには、自社の実績値を入れて同じ単位に落とすしかありません。GHAS 側はアクティブコミッター数をもとに、Code Security と Secret Protection の両方の費用を合算しました。Inspector 側は、対象リポジトリと直近の PR 実績（変更ベースのスキャン回数は PR の open と merge で算出）、それに各リポジトリのサイズを入れて月額に組み直しました。サイズには、全履歴を含む pack ではなく、各リポジトリのデフォルトブランチの作業ツリーを使いました。これは試算上の仮定であり、Inspector が実際に課金対象として計上するサイズを確認したものではありません。なお、具体的な金額は公開していないので、以下は比率と傾向で書きます。 試算していて気づいたこと 1. トリガー構成を変えると、金額が約120倍動いた これは試算表を作っていて驚いた点です。Inspector 側を「週次1回の定期スキャンのみ」で試算した場合に比べて、「変更ベース（PR の open + merge）＋週次1回」にすると、 月額が約120倍 になりました。これは Inspector 内でのスキャン構成の比較であり、GHAS との金額差ではありません。後者のコストは99%以上が PR 起因のスキャンでした。 従量課金のツールは、「いくらか」でなく「どう使うといくらか」を決めないと比較表に乗せられません。そして、安い構成はそのまま「検知が遅い構成」でもあります。コストの話が、いつの間にか運用設計の話になっていました。 2. 「リポジトリサイズ」が何を指すのか分からない 従量課金の計算にはリポジトリサイズが入ってきます。料金体系には10MB単位の記述があるので、最初はそれを掛ければいいと思っていました。が、その10MB が何の測定値なのかは分かりません。 自社のリポジトリで実測したサイズを10MB単位に換算すると、測り方によって次の差がありました。デフォルトブランチの作業ツリーを1とした、課金単位の比率で示します。 測り方 10MB単位に換算した課金単位の比率 pack 全体（全履歴込み） 80以上 デフォルトブランチの作業ツリー 1 作業ツリーは実際にチェックアウトして手元に展開されるコードで、pack は過去の全履歴を含みます。 どちらを採るかで課金単位が80倍以上変わります 。課金対象サイズの定義が分からないままでは、試算の確度を上げられません。 この点は、公式ドキュメントを読んだ限りでは特定できませんでした。今回の試算では、デフォルトブランチの作業ツリーを課金対象サイズと仮定しました。実際の計上値は、15日間の無料トライアル期間中にスキャンを走らせ、コンソールの使用状況で確かめる方針にしました。以下のコスト比率や月額比較も、この仮定に基づく試算であり、使用状況や請求額の実測結果ではありません。 コストの偏り もう一つ、リポジトリサイズと PR 実績をもとにした試算で分かったことがあります。従量課金だと、コストがいくつかのリポジトリに極端に偏ります。 当社の試算では、Inspector の試算額全体の約8割を上位3リポジトリが占め、最大の1リポジトリだけで約56%を占めていました。メインのサービスのリポジトリが、サイズもコミット頻度も圧倒的に大きいからです。 これは別の角度から言うと、 一番スキャンしたいリポジトリが一番高くつく ということです。コストを下げるためにスキャン頻度を落とすと、一番守りたいところの検知が遅くなります。このジレンマになるのが、今回は制約として大きかったです。 今回の試算では月額は同水準でしたが、だからコストは決め手にならない——と最初は書こうとしました。しかし、それは正確ではないと気づきました。金額は同じでも、 伸び方と、伸び方を予測できるかが違います 。この観点が、最後の判断を分けました。 GHAS を選んだ理由 最終的に、当社は GHAS（Code Security ＋ Secret Protection）を選びました。決め手は3つあります。 1つ目は、検知精度と言語カバレッジ です。Ruby で同じ脆弱コードを流したところ、仕込んだ5パターンがすべて出て、意図していないアラートはありませんでした。そして公式の対応言語は社内の6言語をすべて含みます（実地検証は Ruby のみ）。全社展開を前提にすると、「このチームだけ別ツール」を作りたくありません。 2つ目は、コストの予測性 です。前述のサイズの仮定に基づく試算では、月額はどちらも同水準でした。でも、人数課金は採用計画から来年分を社内に説明できます。スキャン回数課金は、トリガー構成とコミット量で桁が動きます。とくに AI でのコーディングが広がるなかで、人数が変わらないままスキャン回数だけが伸びていくリスクは、予算の説明責任を持つ立場では受けにくいものでした。 同じ金額なら、読める軸を選びたい という判断でした。 3つ目は、Code Security と Secret Protection を組み合わせ、同じプラットフォームで運用できる ことです。 前述のとおり、今回の選定では、SAST とシークレット保護を組み合わせた運用も評価項目に含めました。別々のツールで揃えると、契約や通知経路、開発者への周知をそれぞれ管理する必要があります。Code Security と Secret Protection を同じプラットフォーム上で運用できることは、こうした管理の負担を抑えるうえで利点でした。 Inspector を選ばなかった理由 Inspector Code Security が劣っているから選ばなかったわけではありません 。今回の全社展開の要件には、GHAS のほうが合っていた、が正しいところです。 Inspector の強みは、コンテナイメージや EC2、Lambda、ソースコードの検出結果を同じ AWS コンソールで横断して確認できることです。AWS 上のワークロードとソースコードを一元的に把握したい場合には、有力な選択肢です。 今回の選定対象は、全社のソースコード向け SAST でした。検知精度と言語カバレッジ、コストの予測性、Code Security と Secret Protection を同じプラットフォームで運用できることを重視すると、GHAS のほうが要件に合っていました。 IaC についても、今回の PR コメントの確認だけで Inspector の IaC スキャン全体のカバレッジや、Terraform 専用ツールの代替可否を判断することはできません。これをもって「IaC スキャンは使えない」と言いたいわけではなく、全 Severity の結果も含めて別途評価する必要があります。 そして、この判断ができたのは、 先に要件を言語化して、同じコードで測っておいたから です。「なんとなく GitHub のほうが使いやすそう」で決めていたら、後で説明できなくなっていたと思います。 まとめ 今回の比較で重視したのは、検知結果だけでなく、全社で共通して運用できるかという視点です。最後に、選定で役立ったポイントをまとめます。 全社要件を言語化する。 言語対応や開発者へのフィードバック、設定・通知の運用を要件として整理することで、候補を同じ基準で比較できました。要件がないと、ツール比較は「あっちのほうがいいらしい」の応酬になります。 公式の対応表でなく、同じ脆弱コードで測る。 両ツールとも、公式の検出ルールには XSS 用のルールがありますが、実際に流すと見逃しと誤検知が出ました。IaC も同じで、スキャンが動くことと、自社で守りたいルールが拾えることは別です。何が拾えて何が拾えないかは、自分たちのコードを流して初めて分かります。 課金軸が違うツールは、自社の実績値を入れて初めて意思決定に使える。 人数課金と従量課金は、料金表を並べても比べられません。そして比較するときは、金額だけでなく伸び方と予測しやすさも軸に入れたほうがいいです。 ツールの選定では、検知結果だけでなく、アラートの優先順位、対応の役割分担、通知経路まで考える必要があります。 こうした運用設計については、別記事で紹介する予定です。 同じように SAST のツール選定で悩んでいる方の参考になれば幸いです。

AIエージェントの時代には、データマートの作り方を見直す必要があります。分析の目的ごとに必要な属性を、1つの静的なマートに足し続けるやり方では、エージェントが分析を進めるスピードに追いつけないからです。 dotDataは、分析の目的に関係するデータ上のパターンである「特徴量」を、AIエージェントに定量的な根拠を与えるデータとして捉え直しています。特徴量は目的によって変わります。そのため、全社で共有する標準的なデータと、目的に応じて特徴量を自動生成する仕組みを分けて設計することが重要になります。 本記事では、次の内容を解説します。 AIエージェントに必要な3つの知識 AIエージェントの時代における特徴量の役割 静的なデータマートが抱える限界 目的に応じて特徴量を自動生成するアーキテクチャ LLMに直接分析させる場合との違い AIエージェントに必要な3つの知識 AIエージェントが自社の分析で精度を出すには、3種類の知識をそろえる必要があります。 図：AI時代のデータ活用に求められる3つの知識（図中の「データ知識」は本文の「データからの知識」にあたります）（出典：dotData Webinar資料「AI Agentの新トレンド〜精度を決める『AI-Ready Data』〜」（2026年7月）より） 世界知識 ：LLM（大規模言語モデル）そのものが持つ、世の中の幅広い知識です。モデルは提供各社で特徴が異なります。最新のモデルを使い分けられる状態にしておくことが、世界知識へのアクセスを確保することにつながります。 ドメイン知識 ：業務に関する知識です。多くは文書などの非構造データとして存在します。RAG（検索拡張生成）などを使って、エージェントがアクセスできる形にしておきます。 データからの知識 ：データの中には、世界知識にも業務の知見にもないパターンが埋もれています。ある目的に対して、データのどこにパターンがあるのかを見つける必要があります。dotDataは、このパターンを「特徴量」と呼んでいます。 データ分析の分野では、何十年にもわたって「データドリブン」が重視されてきました。データの中に、人の経験や知識だけでは得られない知見があるからです。AIエージェントの時代でも、この点は変わりません。 AI-Ready Dataとは では、データに意味（定義と文脈）を与える考え方を解説しました。本記事では、3つの知識のうち、データからの知識を扱います。 特徴量の再定義：AIエージェントに定量的な根拠を与えるデータ 特徴量の役割は、機械学習モデルやBIの入力となる変数から、AIエージェントに定量的な根拠を与えるデータへと広がりつつあります。特徴量が重要なのは、分析の答えが生のデータそのものではなく、目的に関係するパターンの中にあるからです。同じ顧客データでも、どのパターンを取り出すかによって、予測の精度も、打つべき施策も変わります。dotDataは、2018年にNECからのスピンアウトとして創業して以来、この特徴量の設計を自動化する技術に取り組んできました。特徴量エンジニアリングの基本は、 解説：機械学習のための特徴量設計 で紹介しています。 目的に関係するデータ上のパターン dotDataは、特徴量を「分析の目的に関係するデータ上のパターン」と捉えています。 金融の例 ：銀行がローン商品の販売を伸ばしたい場合、顧客の属性、オンラインバンキングの利用状況、運用している金融商品、コールセンターへの問い合わせ内容などから、ローンを利用しそうな顧客の特徴が見えてきます。 製造の例 ：製品の設計や製造工程で、どのような条件がそろうと不良が増えるのか、という関係が特徴量にあたります。この関係が分かれば、設計や工場の運用を改善して不良を減らせます。 データの種類ごとの特徴量の例 特徴量は、元になるデータの種類によって作り方が変わります。代表的な例は次のとおりです（いずれも説明のための例です）。 データの種類 特徴量の例 詳しい解説 カテゴリ変数（商品カテゴリ、地域など） カテゴリごとの出現頻度、購買に占めるカテゴリ別の比率 カテゴリ属性に対する特徴量設計 日付・時刻 曜日別の利用比率、前回購入からの経過日数 時系列モデルの手法と時間データの特徴量設計 時系列・トランザクション 直近30日の購買回数、過去90日の利用額の移動平均、利用回数の増減 時系列データの特徴量設計 – パート2 テキスト（問い合わせ履歴、レビューなど） 問い合わせ内容の意味を表すラベル、話題ごとの出現件数 dotData TextSense 時系列やトランザクションのデータでは、「どの期間で」「どう集計するか」の組み合わせで候補が大きく増えます。この組み合わせを人手で網羅するのは難しく、自動生成が効果を発揮しやすい領域です。 これまでとこれからの特徴量 これまで特徴量は、主に機械学習モデルの予測精度を高めるための説明変数や、BIの入力として使われてきました。AIエージェントの時代には、新しい役割が加わります。エージェントの分析・仮説・アクションに定量的な根拠を与え、その精度を高めるデータとしての役割です。dotDataは、特徴量を定量側のAI-Ready Dataと位置づけています。 図：特徴量の再定義：エージェントのための定量的なデータ（出典：dotData Webinar資料「AI Agentの価値は、データで決まる」（2026年12月）より） AI-Ready Dataとは で紹介した3層構造（土台／セマンティック／コンテキスト）は、特徴量にもそのまま当てはまります。ここでは、目的を「解約予測」、特徴量を「直近30日のログイン回数」とした例で説明します（数値はすべて説明のための例です）。 層 特徴量での中身 例：解約予測と「直近30日のログイン回数」 ③コンテキスト（意味＝文脈） 目的別の統計、リフト（その特徴を持つ顧客で、目的の事象が全体の平均の何倍起きやすいか）、説明文。その目的に、どの特徴量がどれだけ効くか 解約予測という目的では、「直近30日のログイン回数が少ない顧客は解約しやすい」 ②セマンティック（意味＝定義） 特徴量パイプライン、クエリ定義。生データから特徴量を同じ定義で生成・再現する ログイン履歴を、顧客ごとに過去30日分集計する。誰が算出しても同じ値になり、毎月の新しいデータにも同じ定義で再生成できる ①土台（BI-Ready Data） 特徴量テーブル。目的に合わせて集約・整理した「顧客×特徴量」の表 顧客C001はログイン3回、顧客C002は27回 この表で重要なのは、③コンテキストの中身が目的によって変わる点です。同じ「ログイン回数」でも、解約予測では、ログイン回数が減った顧客が注目すべき対象になります。一方、ある商品の購買予測では、ログイン回数が増えた顧客が、購入しそうな顧客として注目されるかもしれません。特徴量の意味は、目的、つまりコンテキストによって決まります。 なお、この表の③は事前に計算しておく統計ですが、エージェントが問いに応じて、目的に合う統計と説明を実行時に受け取るという意味で、コンテキスト層にあたります。 従来のアプローチ：横に長い統合マートを全社で共有する BIや機械学習の時代には、データマートや特徴量ストア（フィーチャーストア）を先に作り、全社で共有するのが定石でした（特徴量ストアについては Databricksの特徴量ストアとAutoMLの記事 で解説しています）。 販売、顧客、商品、キャンペーン、在庫などのデータを結合し、横に長い統合分析テーブルを作ります。日本では「大福帳」と呼ばれることもある形式です。このテーブルを最初に整備しておき、さまざまな分析テーマで使い回します。データマートを含むデータ基盤の構成については、 データ活用基盤とは？ で解説しています。 このアプローチには合理性があります。 定義の統一 ：全社で同じ定義の属性を使える 再利用 ：一度作った属性を、ほかの分析でも使える 正確性 ：重要な指標や定常的なレポートを、確定した定義で安定して提供できる 特に、重要な指標や定常レポートを支えるマートの役割は、AIエージェントの時代になっても変わりません。問題が生じるのは、分析テーマが増えるたびに、そのテーマのための属性（列）をマートに足していく運用です。 静的なマートが負債になる悪循環 分析のテーマが増えるほど、属性を足し続ける静的なマートは、システムと組織の負債になっていきます。たとえば、dotDataが支援している欧州の通信事業者では、10年以上かけてマートが数万列に膨らみ、パイプラインの修正と再計算の負担が大きくなっていました。この章では、負債が生まれる理由を、分析スピードの変化と、悪循環を生む4つの要素に分けて説明します。データマートを含むデータ基盤の基本的な構成は、 データ活用基盤とは？ で解説しています。 図：レガシーアプローチの限界：静的マートという「負債」（出典：dotData Webinar資料「AI Agentの新トレンド〜精度を決める『AI-Ready Data』〜」（2026年7月）より） 分析のスピードが上がると、テーマが増え続ける AIによって、分析のスピードは大きく上がります。dotDataは、その変化を次のようなイメージで捉えています（実測値ではなく、加速の方向を示すイメージです）。かつて数カ月かかっていた分析が、自動化ツールによって1カ月に、AIの支援によって1週間に、エージェントによって1日に、と短くなっていけば、取り組める分析テーマは次々に増えていきます。テーマが増えるたびに属性を足していけば、マートは横に伸び続けます。 静的マートの悪循環を生む4つの要素 前述の通信事業者のように列が数万に達すると、次のような悪循環が生まれます。 メンテナンスコストの増大 ：データパイプラインが頻繁に壊れ、そのたびに修正が必要になります。数万列のマートを再計算するコストも大きくなります。 鮮度の劣化 ：人は列を足すのは得意でも、捨てるのは苦手です。有効かどうか分からなくなった列が、大量に残り続けます。古い列を選別するのは大変ですが、選別しなければ、ビジネス部門に新鮮な情報を届けられません。 リソースのボトルネック ：新しいテーマのたびに、データチームに属性追加の依頼が集中します。データチームは依頼をこなす受託者のようになり、新しいテーマに着手するまで数カ月待ち、という状況が生まれます。 野良マートの乱立 ：待てない業務部門は、ガバナンスの外で独自にデータを加工し始めます。いわゆる「野良マート」が乱立し、データの品質が下がり、メンテナンスの負担がさらに増えます。 この悪循環は、1に戻って繰り返されます。AIエージェントの時代に分析のサイクルが速くなれば、このアプローチのままでは、データの側がボトルネックになります。エージェントがどれほど賢くても、必要なデータが用意できなければ、分析は進みません。 なぜ「全テーマ共通の理想のマート」は作れないのか 特徴量は目的によって変わるため、すべての分析テーマで共有できる理想のマートは存在しません。 先ほどのログイン回数の例のように、同じデータでも、目的によって注目すべきパターンは違います。必要な属性そのものも、目的ごとに異なります。 高単価商品のターゲティング では、消費の余力や購買の広がりを表す属性が必要です。 ブランドからの離反の予兆検知 では、配送の速さへのこだわりや、ブランドの乗り換え傾向を表す属性が必要です。 クーポン施策の最適化 では、まとめ買いの傾向や、クーポンへの反応の速さを表す属性が必要です。 1つの共有マートで、これらすべての目的に応えようとすると、目的の数だけ列が増えていきます。どの目的にも通用するデータを事前に用意しておくことはできない、という考え方は AI-Ready Dataとは でも紹介しました。dotDataは、特徴量のような定量的なデータも、同じように目的に依存すると考えています。 ここから導かれるのは、全社で共有すべき本質的な属性と、目的ごとに必要な属性を分けて扱う、という考え方です。前者は共有し、後者は目的に応じて自動で生成します。 目的に応じて特徴量を自動生成するアーキテクチャ dotDataは、共有する標準データと、目的ごとに生成する特徴量を分け、目的変数を起点に特徴量を自動生成するアーキテクチャを提案しています。目的変数とは、分析の目的をデータで表したもの（例：解約したかどうか、成約したかどうか）です。 図：目的に応じて特徴量を自動生成するアーキテクチャ（出典：dotData Webinar資料「AI Agentの新トレンド〜精度を決める『AI-Ready Data』〜」（2026年7月）より） 共有する部分：軽い標準データ 全社で共有するのは、作り込んだ巨大なマートではありません。次のような軽い標準データです。 領域ごとの標準テーブルセット ：販売、顧客、商品など、領域ごとに整えたテーブル群（データセット） ER定義 ：テーブル同士の関係 基本属性 ：多くの分析で共通して使う本質的な属性 分析単位 ：顧客ID、製品ID、店舗IDなど、何を単位に分析するか 標準データは、新しく作り込む必要はありません。DatabricksやSnowflakeなどのデータ基盤上で、すでに整備されているテーブルを起点にできます。 dotData Feature Factory は、こうした複数のテーブルとテーブル同士の関係を入力にして、特徴量を生成します。 目的ごとに生成する部分：目的変数から特徴量を自動生成 分析テーマごとに、目的変数を標準データに接続すると、その目的に合った特徴量が自動で生成されます。流れは次の4ステップです。 標準データと目的変数をつなぐ ：分析テーマごとに、目的変数を標準データに接続します。 特徴量を自動で抽出する ：目的変数との関係が強いパターンを、複数のテーブルを横断して網羅的に探索し、新しい特徴量として生成します（特徴量自動設計）。 定量的なコンテキストを付ける ：抽出した特徴量に、ビジネス上の意味（説明文や統計情報）を付与します。 コンテキストレポートを作る ：特徴量、LLM、業務の文脈を組み合わせて、分析結果の解釈や施策の案をまとめます。 ステップ1と2は、特徴量自動設計による自動化です。ステップ3と4は、特徴量とLLMを組み合わせた意味づけです。生成された特徴量は、統計的な裏付けのある事実として、LLMやエージェントに渡されます。 特徴量を自動生成する主な方法 特徴量を自動生成する方法には、主に次のようなものがあります。 テンプレートによる生成 ：「直近30日」「直近90日」などの時間窓と、件数・合計・平均などの集計関数を組み合わせて、候補を機械的に作ります（数値は例です）。 テーブルの関係に沿った探索 ：テーブル同士の関係（ER）をたどって、関連するデータを集計した特徴量を作ります。 LLMによる発想の支援 ：LLMに業務の説明とテーブルの構成を渡し、特徴量の候補を挙げさせます。発想を広げるのに役立ちますが、計算の正確さと網羅性は別に確かめる必要があります。 網羅的な探索と統計的な評価 ：dotDataの特徴量自動設計は、複数のテーブルから数百〜数千のパターンを探索し、目的変数との関係の強さで評価して選びます。 手作業の特徴量エンジニアリングとの違い 従来の特徴量エンジニアリングは、分析者の手作業によるプロセスでした。分析者が経験と知識をもとに仮説を立て、PythonやSQLでデータの抽出・集計・変換の処理を書いて特徴量を作成し、機械学習モデルで効果をテストします。この作業には時間がかかるため、1つのテーマで検証できる仮説の数には限りがありました。目的に応じた特徴量の自動生成は、このプロセスの考え方を次のように変えます。 観点 手作業の特徴量エンジニアリング 目的に応じた特徴量の自動生成 仮説の出し方 分析者の経験と知識に基づいて、候補を選ぶ アルゴリズムが複数のテーブルを横断して、パターンを網羅的に探索する 作業のプロセス 特徴量ごとに、抽出・集計・変換の処理を書き、モデルでテストする 目的変数を与えると、特徴量の生成から評価までを自動で行う テーマが増えたとき 分析者の作業時間が、テーマの数に比例して増える 目的変数を差し替えて、同じ手順を繰り返せる 再現性 担当者ごとのコードに依存しやすい 特徴量パイプラインとして、同じ定義で再生成できる 人の経験と知識が不要になるわけではありません。どの目的変数を設定するか、生成された特徴量をどう解釈して施策につなげるかは、引き続き人が判断します。自動生成は、仮説の候補を広げ、作業の効率を高めるための手法です。 コストをテーマの数から切り離す このアーキテクチャでdotDataが目指すのは、データチームの工数を、分析テーマの数から切り離すことです。従来のアプローチでは、テーマが増えるほど、属性の追加と保守の工数が増えていきました。目的に応じて特徴量を自動生成する仕組みでは、テーマごとに人手で属性を追加・保守する負担が減り、保守の中心は共有する標準データに移ると、dotDataは考えています。属性を設計し、試し、評価するサイクルも短くなり、分析のPDCAを速く回せるようになります。 目的変数を差し替えるだけで、分析テーマを広げる 目的変数を差し替えると、生成される特徴量とレポートが変わります。そのため、1つの仕組みで多くの分析テーマに対応できます。dotDataは、2026年7月1日のウェビナー「 AI Agentの新トレンド〜精度を決める『AI-Ready Data』〜 」で、ローンの不履行リスクを目的変数にしたデモを通じて、この使い方を紹介しました。以下では、小売と金融の2つの例で説明します。 図：目的変数を切り替えるだけで多目的に展開する（出典：dotData Webinar資料「AI Agentの新トレンド〜精度を決める『AI-Ready Data』〜」（2026年7月）より、一部改変） 小売の例：目的変数ごとに生成される属性 次の表は、小売の分析を想定した例です（いずれも説明のための例です）。 目的変数の例 生成される属性のイメージ 活用シーン 新商品の購買 早期に購入する層、慎重に購入する層、価格に敏感な層 ターゲティングの高度化 クーポン施策への反応 週末にまとめ買いする層、配布後すぐに反応する層 クーポン配布の最適化 ブランドからの離反 配送の速さを重視する層、ブランドを乗り換えやすい層 離反の予兆の早期検知 高単価カテゴリの購買 消費の余力があり購買の幅を広げている層、上質志向の層 クロスセル・アップセル 金融の例：与信の分析を別のテーマに切り替える 金融の与信を例にとります。ローンの不履行リスクを目的変数にすると、リスクの高い顧客と低い顧客の特徴が抽出されます。そこに業務の文脈を与えると、地域のリスクに応じた与信、返済の余力という観点での審査、生活基盤の異なる顧客層ごとの施策といった解釈や提案が導かれます。 ここで目的変数を、別のローン商品の不履行リスクに差し替えれば、同じ仕組みで別の商品の分析ができます。新規のローン申込みのように、まったく異なるテーマに切り替えることもできます。目的変数を差し替えるだけで、特徴量が変わり、レポートの内容も変わります。 この仕組みは、AIが人の分析を支える「AI拡張型」の分析にも、分析そのものをAIエージェントに任せる「エージェント駆動型」の分析にも、基盤になります（3つの段階については AIエージェントを活用したデータ分析の現在地 で解説しています）。 LLMに直接分析させる場合との違い 「LLMに直接データを渡して分析させればよいのではないか」という疑問もよく聞かれます。dotDataの考えは、統計的に確定させるべき部分を先に特徴量として出し、それをLLMに渡すほうが、分析の精度が上がるというものです。違いは2つあります。 網羅性の違い LLMに解約の分析を任せると、LLMはデータの項目を見て推論し、人の勘のように、5個から10個程度の要因を選んで計算します。dotDataの特徴量自動設計のアルゴリズムは、複数のテーブルから、目的ごとに数百から数千のパターンを統計的に探索し、その中から目的との関係が強いものを選びます。探索の網羅性が違うため、見つかる要因の質も変わります。 計算の正確性の違い アクセスログのような縦に長いトランザクションデータは、そのままではLLMに入力できません。そのため、LLMにデータを集計・変換するクエリを書かせることになりますが、加工が複雑になるほど誤りが入り込みやすくなります。特徴量パイプラインは、定義に従って同じ計算を再現するため、計算の正確性を保てます。 網羅的に探索され、正確に計算された特徴量をLLMに渡すことで、エージェントにコンテキストを与えて精度を高めるのと同様の効果を、定量の側で得られると、dotDataは考えています。 dotDataのアプローチ dotDataは、特徴量自動設計の技術を核に、AIエージェントのための定量的なデータを、目的ごとに生成することに取り組んでいます。 特徴量自動設計（Automated Feature Engineering） ：目的変数を与えると、複数のテーブルを横断して特徴量のパターンを網羅的に探索し、目的との関係が強い特徴量を見つけます。 dotData Feature Factory ：特徴量を、再現可能な特徴量パイプラインとして管理し、さまざまなデータアプリケーションで活用できるようにします。 dotData Insight ：特徴量と生成AIを組み合わせ、ビジネスの課題に対する分析とレポートを提供します。 2026年12月9日（水）12:00〜13:00には、dotData CEOの藤巻が登壇するウェビナー「AI Agentの価値は、データで決まる 〜北米で起きているデータ基盤の再定義〜」を開催します。AIエージェントの時代にデータ基盤をどう考えるべきかを、北米の動向を交えてお話しします。詳細・お申し込みは ウェビナーのページ をご覧ください。 まとめ 特徴量は、AIエージェントに定量的な根拠を与えるデータです。その意味は、分析の目的によって決まります。 重要な指標や定常レポートのためのマートは、引き続き必要です。一方で、目的別の属性を静的なマートに足し続けるやり方は、テーマが増えるほど負債になります。 共有する標準データと、目的に応じて特徴量を自動生成する仕組みを分けることで、エージェントの分析のスピードに追随できるようになります。 dotDataは、 dotData Feature Factory と dotData Insight を通じて、この考え方の実装に取り組んでいます。2026年12月9日のウェビナー「AI Agentの価値は、データで決まる」では、AIエージェントの時代のデータ基盤について解説します。 AIエージェントによるデータ分析の全体像は AIエージェントを活用したデータ分析の現在地 で、データの意味を整える考え方は AI-Ready Dataとは で解説しています。 The post AIエージェント時代のデータマート ― 静的マートの限界と、目的に応じた特徴量の自動生成 appeared first on dotData .