CData CLI、登場。ターミナルが、あなたのデータを熟知した AI とつながります。 

コマンドラインは健在です。そこは開発者が活動する場であり、自動化が実行される場であり、そして今や、AI コーディングエージェントが作業する場にもなりつつあります。CData Drivers は世界中の何万人もの開発者に愛用されており、データ連携を扱う主要な ISV（独立系ソフトウェアベンダー）の製品に組み込まれた接続レイヤーとなっています。CData CLI は、その信頼性が高く実戦で検証を重ねたドライバーインターフェースを、そのまま AI に提供します。

問題：AI は手探りの状態

AI コーディングエージェントに、Salesforce、NetSuite、Snowflake、Jira、SAP などのリアルタイムデータソースを扱わせてみましょう。すると、次のようなことが起こります。

• スキーマを推測で作ってしまう。それらしく聞こえるのに実際には存在しないテーブル名やカラム名を、勝手に作り出します。Product_Group__c？Product_Line__c？Segment__c？AI はこの 3 つすべてを、自信満々に試そうとします。

• API の挙動を知らない。SaaS API はフィルタリングもページネーションもレート制限も、それぞれ流儀が違います。モデルには、そのどれについても頼りになる勘所がありません。

• 生データを取得して、クライアント側で集計する。プッシュダウンが効かないため、典型的なやり方は「行をまるごとコンテキストウィンドウにダンプし、計算はモデル任せ」というものです。これは遅く、コストがかさみ、規模が大きくなると結果も狂います。

• 構築されるデータモデルが安定しない。AI にデータソースの連携を頼むと、その場でモデルを即興で組み立てます。どんなエンティティがあり、互いにどう関係し、何という名前なのか。それをその場の思いつきで決めてしまうのです。もう一度実行すれば、また違う組み立て方をしてきます。本番環境でのアプリケーション間連携やデータウェアハウスのレプリケーションには、データモデリングが欠かせません。エージェントが場当たり的な推測しか出せないようでは、業務で信頼して使える安定した出力は得られません。

こうして生まれるのが、誰もが恐れるようになったあの事態です。もっともらしく、自信満々で、しかし間違っている。

インサイト：あなたの AI は、すでに SQL を話せる

どんな LLM も、SQL を理解しています。

CData は 10 年以上にわたり、API、SaaS アプリ、データベース、ファイルストアなど、数百ものエンタープライズデータソースを、単一で統一された SQL-92 リレーショナルモデルにまとめ上げてきました。テーブル、カラム、JOIN、WHERE、GROUP BY。Salesforce でも SAP でも Snowflake でも、使用するのは同じ標準的な SQL です。

つまり、エージェントは新しいことを覚える必要がありません。独自仕様の API を学んだり、ベンダーの SDK を暗記したりする必要もないのです。エージェントはすでに知っている言語で記述し、あとはドライバーがそれを変換し、最適化してデータソース側へ処理を委ねます。

CData CLI の役割は、その SQL インターフェースを、エージェントが推測から抜け出すために欠かせない 2 つの機能とあわせて提供することです。その 2 つとは、スキーマを確認する方法と、それに対してクエリを実行する方法です。そして、エージェントが見たものが、そのまま結果になります。

CData CLI がエージェントにもたらすもの

ターミナルですべて完結：シェルから離れる必要はありません

ライフサイクル全体がプロンプト上で完結します。ドライバーの検索、ダウンロード、有効化、接続、そしてクエリの実行まで、ダウンロードポータルやインストーラーウィザード、Web コンソールに一度も移動することなく行えます。エージェントは、検索からクエリまで、まったく新しいデータソースをゼロから立ち上げられます。あるいは、いま作業しているそのターミナルで、あなた自身が行うこともできます。

cdatacli drivers search --driver salesforce
cdatacli drivers download --artifact-id 
cdatacli drivers activate Salesforce --name "YourName" --email [email protected] --trial
cdatacli connection create --driver "Salesforce" --name sf --connectionstring "..."
cdatacli query sql --connection sf --sql "SELECT ..."

ターミナルからのコネクション管理（CRUD）

保存済みコネクションの作成、一覧表示、更新、削除が、いずれも独立したコマンドとして用意されています。エージェントは自分用のコネクションをプロビジョニングし、認証情報は暗号化されたローカルストアに保存され、OAuth はブラウザ側で別途処理されます。機密情報がモデルのコンテキストに入ることは一切ありません。（認証情報を手動で入力する場合は、AI セッションの外で行ってください。）

cdatacli connection create --driver "Salesforce" --name sf \
  --connectionstring "AuthScheme=OAuth;InitiateOAuth=GETANDREFRESH"
cdatacli connection list

スキーマの検出：常に「グラウンド・トゥルース」

エージェントはドライバーに「何が存在するか」を直接問い合わせます。テーブル、カラム、データ型、プロシージャ、さらにはピックリストの値まで、推測でもハルシネーションでも昨年のトレーニングデータでもなく、グラウンド・トゥルース（確かな事実）として返ってきます。メタデータそのものがクエリ可能なコマンドとして公開されているため、エージェントはキーワードでスキーマを検索し、必要なテーブルだけに絞り込み、注目すべきカラムだけを調べられます。全データのダンプに溺れることはありません。これは、利用できる中で最もたどりやすいスキーマインターフェースであり、700 テーブルにも及ぶデータソースを、ノイズの壁から、正確に参照できる対象へと変えてくれます。

cdatacli metadata tables  --connection sf --table %Opportunity%

単一の堅牢なデータモデル：毎回同一

これこそが、目立たないながらも強力な武器です。エージェントが、データの構造を勝手に決めることはできません。読み込むのは、CData がすでに構築し、実戦で鍛え抜かれた、クリーンで精選されたリレーショナルモデルです。そのモデルは、どの実行でも、どの開発者でも、どのエージェントでも同一です。即興も、ばらつきもありません。スキーマを「当て推量」に任せるのをやめれば、連携作業も「当て推量」ではなくなります。

最適化されたクエリ：データレイヤーでの演算

フィルタリング、JOIN、集計は、API が許す限りデータソース側で実行されます。AI が受け取るのは生の行データではなく、答えそのものです。モデルのコンテキストウィンドウに収まるのは、50,000 件のレコードではなく、COUNT の結果と上位 20 件です。手作業でレコードを絞り込む必要はありません。

cdatacli query sql --connection sf \
  --sql "SELECT StageName, COUNT(*) FROM Opportunity WHERE Amount >= 100000 GROUP BY StageName"

新しい言語は不要。学ぶべき SDK もなし。生データのダンプもなし。入力はスキーマの検出、出力は最適化された SQL。しかも、そのすべてのやり方を、エージェントははじめから知っていたのです。

約束ではなく、実証を

実際に検証を行いました。複数の新しい AI エージェントに、まったく同じ実務課題を与えます。特定の顧客セグメントと製品ラインについて、大型の新規ビジネス案件を見つけ出す、という課題です。変えたのは、使用を許可したツールだけです。

• スキーマ検出がない場合、エージェントはカラム名やピックリスト名を推測するしかなく、スキーマ検出を使った場合に比べてエラーが 7 倍に増えました。さらに、検証する手段のない「もっともらしいが誤った」値に基づくクエリを、危うく正解として確定させるところでした。

• CData のスキーマ検出を使用した場合、同じエージェントはグラウンド・トゥルースを参照し、最初の試行で正しいクエリを書き上げ、その結果まで裏づけることができました。「明白に見える」値が実はおとりだったことも見抜いています。しかも正解は組織固有のもので、カスタムオブジェクトや組織固有の列挙値が関わっていました。これは学習データからモデルが知り得るものではなく、リアルタイムの検出によってのみ得られるものです。

• ほとんどの MCP スタイルのアクセスパターン、たとえばスキーマの完全ダンプ、JOIN なし、モデルの内部でつなぎ合わせた単一テーブルクエリといったやり方では、同じ答えを得るのに 2 倍のコンテキストトークンを消費します。（これはあくまで他の MCP の話です。CData の MCP ソリューションは、クエリ可能なスキーマ検出やインテリジェントなプッシュダウンを備え、はるかに洗練されています。）

このパターンは一貫しています。スキーマ検出はハルシネーションを断ち、SQL プッシュダウンはトークンの肥大化を抑えます。

AI を活用して構築し、AI なしでリリースする

エンタープライズアーキテクチャのレビューにおいて、最も重要な一文がこれです。LLM が生きるのは設計時であり、実行時ではありません。

AI コーディングエージェントは、開発中にターミナル上でスキーマの検出、クエリの検証、連携コードの生成を支援します。しかし、実際にリリースするのは、CData ドライバーライブラリを直接呼び出す、シンプルで決定論的なコードだけです。リクエストパスにモデルはありません。呼び出しごとに推論コストやレイテンシが発生することもありません。本番環境に非決定性が持ち込まれることもありません。顧客データが LLM を通過することもありません。データプレーンに新たなベンダーを組み込み、セキュリティレビューにかける必要もありません。

これこそが、CData CLI を「エージェント・イン・ザ・ループ」や「実行時 MCP」型の設計と一線を画す点です。AI アプリケーションを構築するなら、実行時に LLM を残すのはまさに正解で、CData はそのケースもサポートしています。しかし、企業や ISV の連携の多くは、それを望みません。求めているのは、ランタイムに LLM を一切含まない環境です。つまり、実戦で実証済みのドライバーが、検証済みのまったく同じ SQL を、毎回同じやり方で実行してくれる環境です。

AI の生産性は、役立つ場面で確実に発揮され、役立たない場面では実行時のリスクを一切負いません。

2 つの立場の開発者に向けて

データ連携型アプリケーションの開発者

ターミナルで AI を活用し、スキーマの検出と SQL の検証を行い、本番環境で使用するものと同じ CData ドライバーに対して動作するアプリケーションコードを生成します。探索はエージェントに任せられますが、生成された本番コードは、前述のとおりエージェントには一切依存しません。

IT プロフェッショナルおよびデータエンジニア

システム間でデータを移動、再構成、照合するために、VB や PowerShell、Python のスクリプトを書いた経験がある方なら、一連の手順はご存知でしょう。ドキュメントを読み込み、フィールド名を推測し、ページネーションに対応し、レート制限に備えてリトライを繰り返す。そうした作業の連続です。いまやターミナルには AI が備わり、CData CLI を使用すれば、その AI がデータを理解します。Claude Code をはじめ、データを提供して自動化タスクを実行するターミナルベースの AI ツール上で、エージェントを実行できます。

転換 

長年にわたり、「AI ＋ あなたのデータ」とは、実のところ「AI ＋ あなたのデータに関するハルシネーション（思い込み）」を意味していました。

CData CLI は、その隔たりを埋めます。スキーマの検出が当て推量に取って代わり、SQL が独自仕様の API によるその場しのぎに取って代わり、プッシュダウンがクライアント側の力業に取って代わります。そして LLM は設計時にしか登場しないため、最終的にリリースされるのは、クリーンで決定論的なドライバーコードです。

CData CLI で開発を始めましょう

CData CLI と CData Drivers は、AI コーディングエージェントに対し、単一の SQL インターフェースを通じて、数百ものエンタープライズデータソースへのリアルタイムかつスキーマを把握したアクセスを提供します。プッシュダウン最適化を標準で備え、実行時の LLM 依存は一切ありません。今すぐ無償の CData CLI をダウンロードし、CData Drivers の 30 日間無償トライアルを開始しましょう。

※本記事は CData US ブログ CData CLI: A Modern Command Line Interface for AI-Driven Data Integration の翻訳です。