専用アプリか、それともインセッションエージェントか？CData CLI の使い方を選ぶ

同じタスクを真っ向から比べる一連の実験から、再利用可能なアプリケーションに投資すべきタイミングと、エージェントにその場で CLI を動かしてもらうべきタイミング、そしてどちらのアプローチも繰り返し使えるものにする方法が見えてきました。

実験について

CData CLI のリリースによって、AI コーディングツールには、これを活用する自然な方法が 2 つ生まれました。1 つは、エージェントに 専用アプリケーションを作ってもらう 方法です。CLI を実行可能なスクリプトや本格的な GUI にラップして、チームメンバーにそのまま渡せる形にします。もう 1 つは、コーディングセッションの中で CLI を対話形式で動かす 方法です。データを探索し、結果について考えながら進めていき、そのワークフローをスキルとして保存しておけば、必要なときにいつでも呼び出せます。

どちらのアプローチも問題なく機能し、どちらも実際の成果物を生み出します。ただし、両者は置き換え可能なものではありません。選択を誤ると、精度か時間、あるいはその両方を失うことになります。

その境界線がどこにあるのかを確かめるため、3 つの実験を並行して実施しました。タスクもデータソースも同じ。2 つのエージェントを互いに切り離して動かし、片方には専用アプリを作るよう、もう片方には CLI を対話形式で使うよう指示しました。

CData CLI とは

この実験の両方のラウンドが成り立つのは、ある 1 つの土台があるからです。それが CData CLI です。CData CLI は、AI コーディングエージェントに対して、Salesforce、Jira、Asana、Box、Google Drive をはじめとする数百種類のエンタープライズデータソースへの、認証済みですぐにクエリできるアクセスを提供します。しかも、カスタム連携コードは 1 行も必要ありません。エージェントは、適切なデータソースのドライバーを判断してダウンロードし、接続をセットアップして、データへのクエリを開始できます。これらすべてを、ユーザーの手作業なしでこなします。

ここで興味深いのは、エージェントがこのツールを使う方法が、いまや 2 通りとも正当なものになった という点です。エンジニアがそうするように、その上に洗練されたアプリケーションを作ることもできますし、CLI をライブのデータソースとして扱い、結果について考えながら、セッション内で会話形式に動かすこともできます。以前は、現実的に取れる選択肢は最初の 1 つだけでした。今では、ワークフローの形さえ合っていれば、2 つ目の方法のほうが速く、安く、そして得られるものも豊かであることが少なくありません。

この記事の残りで扱うのは、まさにこの選択についてです。

タスクについて

複雑さの異なる 3 つのワークフローを選びました。いずれも、CData の接続を通じて公開された複数のシステムにまたがるものです。

• Salesforce → Google Drive：ARR が上位 5 件のアカウントを取得し、レポートをアップロードする。
• Jira → Salesforce → Google Drive：Jira の変更リクエストを Salesforce のアカウントに紐付け、その内訳を公開する。
• Asana → Box：Asana プロジェクトの課題を洗い出し、分析結果をアップロードする。

いたってシンプルです。では、実際にどうなったか見ていきましょう。

ラウンド 1：専用アプリを作る

それぞれの実験で、アプリ構築側のエージェントはこのタスクをソフトウェアエンジニアリングとして扱いました。いくつかの CLI 呼び出しでスキーマを探索したあと、残りの処理をこなす自己完結型のスクリプトを書き上げました。

• Salesforce/GDrive：311 行の Java アプリ
• Jira/SF/GDrive：CLI フラグ付きの 553 行の Python パイプライン
• Asana/Box：341 行の bash + 埋め込み Python スクリプト

うまくいった点

成果物は誰でも再利用できます。どのスクリプトも引数（別のプロジェクト、別の接続、別のフォルダ）を受け取り、AI の関与なしで何度でも実行できます。2 回目の実行では、トークンコストはゼロです。クエリはコード化されていて、決定的で、監査も可能です。

さらに重要なのは、アプリのアプローチが データが大規模になっても精度を保った ことです。Jira の実験では、アプリ構築側は信頼できる Salesforce の「Account Name」カスタムフィールドを発見し、Google 関連のリクエストを 558 件 カウントしました。一方、そのフィールドを使わずに進めた対話型エージェントは、テキストマイニングに頼って 42 件 しかカウントできませんでした。13 倍もの過少カウントが、誰にも気づかれないまま世に出ていたことになります。

つらかった点

構築には時間がかかります。アプリ構築側は、どの実験でもデバッグのサイクルが必要でした。Java でのメソッド名の間違い、構築の途中で bash から Python への方針転換。エラーが出るたびに、編集、再コンパイル、再実行が発生しました。

ラウンド 2：CLI を対話形式で動かし、ワークフローをスキルとして保存する

対話形式での実行では、エージェントはコーディングセッションの中で直接 CLI コマンドを実行しました。スクリプトもコンパイル手順もなく、ただ cdatacli を呼び出し、結果をコンテキストに返し、その結果をもとに次のクエリを決める。この繰り返しです。ワークフローが有効だと確認できたら、それを スキル として保存しました。スキルとは、エージェントに次のように伝える小さな markdown ファイルのことです。「ユーザーが Asana の課題分析を求めたら、これらの CLI 呼び出しをこの順番で実行し、これらのカテゴリに注意して、この形式で出力を書く」。エージェントは引き続きその場で CLI を動かし、見つけたものについて考え、データに合わせて適応します。それでいて、ワークフローは保存され、スラッシュコマンド 1 つで再び呼び出せるようになります。

うまくいった点

エージェントは データに出会うたびに、そのデータについて考えました。Asana の実験では、プロンプトで指定されたカテゴリ（期限超過、未割り当て、停滞中）から始め、そこからさらに 2 つのカテゴリをデータ自体から発見しました。完了の遅れと、ブログタスクとメールタスクの間にある依存関係の連鎖の抜けです。エージェントは重要度を評価し、担当者ごとの作業負荷もたどっていきました。アプリのレポートには、こうした内容は一切ありませんでした。

エラーからの回復はほぼタダ同然でした。クエリが失敗したら、次のコマンドを調整するだけ。再ビルドも、最初からの再実行も必要ありません。

1 回あたりのトークンコストは、どの実験でも対話形式のほうが低いか、ほぼ同等でした。Jira の実行では約 30% 安くなるなど、はっきりと差が出た場面もあります。コードを書くオーバーヘッドを丸ごと省けたからです。

そして、ワークフローがスキルとして残っているため、2 回目の実行はやり直しではなく、再呼び出しになります。探索フェーズはスキップされ、エージェントは実証済みのレシピを引き継いで、新しいデータに対して実行するだけです。

つらかった点

エージェントの柔軟さは、大規模なデータセットでは逆方向に作用します。コード化されたクエリという規律がないと、もっともらしく見えるヒューリスティックを選んでしまうのです。558 対 42 という Jira での差はバグではありませんでした。エージェントが、わざわざ探そうとは思わなかった構造化フィールドの代わりに、いかにも妥当に見える近道を選んだ結果です。スキルでエージェントを正しいフィールドへ誘導することはできますが、その推論ステップを決定的なものにすることはできません。

スキル駆動のワークフローも、依然としてエージェント駆動のままです。実行するには AI コーディングセッションが必要になります。これは、適応的な推論がほしいときには利点ですが、深夜 2 時にジョブをスケジュール実行したいときや、AI コーダーを使わない人にワークフローを渡したいときには制約になります。

UI を持つアプリへの応用

ここまでは、ヘッドレスなスクリプトと、スキルとして保存されたエージェントのワークフローを比べてきました。同じ計算は、専用アプリが ユーザーインターフェース（Swing のウィンドウ、Web ダッシュボード、チームメンバーがクリックして操作する Electron ツールなど）を持つ場合にも当てはまります。むしろ、その差はいっそう際立つかもしれません。

UI は、2 つの面でコスト構造を変えます。

1. 使う人が変わる。 スクリプトは、それを作った本人のためのものです。一方 UI は、それを書いていない人、そして書く必要のない人のためのものです。再利用による見返りは、もはや 「1 回ではなく 2 回実行する」 ではなく、「組織内の 20 人が毎週これを使い、エージェントには一切触れない」 になります。
2. 構築コストが上がる。 300 行の CLI スクリプトは、フォーム、バリデーション、エラー状態、結果表示を加えると、1,500 行のアプリケーションになります。投資が大きくなる分、それを選ぶ判断基準も高く設定すべきです。

決め手になるのは、同じ 3 つの要素です。ワークフローを実行する頻度、データセットの規模、そして構造化データが必要なのか、それとも定性的な洞察が必要なのか。UI アプリは、その内側がコード化されたパイプラインそのものなので、コード化パイプラインの精度面のメリットを受け継ぎます。さらに、エージェントの推論を製品機能として重ねることもできます。構造化データを決定的に提示し、「これを分析する」ボタンを備えたダッシュボードは、必要に応じてその結果をエージェントに渡し、定性的なコメントを得られます。こうなると、ハイブリッドのパターンは順番にこなすものではなくなり、製品そのものの機能になります。

対話型エージェントには、ここでも役割があります。UI アプリを作る前に プロトタイプを試す 手段になるのです。セッション内で CLI を動かしてクエリを検証し、データの形を確認し、画面に何を表示すべきかを大まかに描く。そのうえで、土台となるクエリがすでに機能していると分かった状態で、本格的な構築に進めます。

並べて比較する

どちらを選ぶべきか

ハイブリッドのパターン

どの実験も、個別に分析してみると、同じ答えにたどり着きました。両方を、順番に使う ということです。

1. まず対話形式で探索し、スキルとして保存する。 セッション内で CLI を使ってスキーマを発見し、クエリを検証し、データの形を把握します。実証済みのワークフローをスキルとして保存しておけば、探索コストを支払うのは一度きりで済みます。
2. 精度やスケジュール実行が重要なら、実証済みのワークフローをスクリプトにコード化する。 クエリが安定し、ヒューリスティックな近道では支障が出るほどデータセットが大きくなったら、それらをパラメータ化したアプリにラップします。
3. 使う人が増えたら、スクリプトを UI でラップする。 非エンジニアが実行する必要が出てきたら、フォーム、バリデーション、結果表示を加えます。必要に応じて、UI の中に「これを分析する」エージェントステップを組み込み、定性的なコメントをその場で得られるようにします。

スキルがスクリプトのリスクを減らし、スクリプトが UI のリスクを減らします。その上に重ねたエージェントは、どの段階で立ち止まったとしても、そこに判断力を加えてくれます。ワークフローが必要とするところまで登っていけばよいのです。

まとめ

CData CLI は、どの段階でも変わらず同じツールです。変わるのは、誰がそれを動かし、どれくらいの期間、誰のために使うのか、という点です。

小規模あるいは定性的なデータセットに対して適応的な推論が必要なら、AI セッションの中で CLI を動かし、ワークフローをスキルとして保存しましょう。より豊かな出力を、より速く、より安く得られますし、ワークフローは再び呼び出せる状態に保てます。

大規模での精度が重要な場合や、AI セッションを介さずにジョブを実行する必要がある場合は、トークンを使ってスクリプトを作りましょう。支払っているのは最初の 1 回分ではなく、その後の毎回の実行分なのです。

使う人がエンジニアを超えて広がるなら、スクリプトの上に UI を作り、仕事の定性的な部分のためにエージェントを製品機能として再び組み込むことを検討しましょう。

優れたチームは、1 つのアプローチだけを選んだりはしません。ワークフローごとに適切な段階を選び、そのすべてにわたってエージェントを再利用します。

どの段階も結びつけているのが、CData CLI です。1 つのインターフェースで数百種類のエンタープライズデータソースにつながり、スキーマを完全に把握できます。だからこそエージェントは、データにたどり着く方法を考えることではなく、あなたのデータについて考えることにトークンを使えるのです。問われるのはもう「これを作れるか？」ではなく、「どんな形にすべきか？」になっていきます。

今すぐ始める

無料の CData CLI をダウンロードし、Claude Code と組み合わせて、自分だけのエージェント駆動型ワークフローを構築してみましょう。

お困りのことがありましたら、サポートチーム までお気軽にお問い合わせください。喜んでお手伝いいたします。