AIはもう十分。難しいのは、適切なHarnessを選ぶこと
少し前、HubSpotのデータ照会に関する要件を整理していた。目標は一文で表せる。社員が自然言語で、自分の権限の範囲内にあるデータを検索できるようにすることだ。
モデルとAPIをつなげば済むように思える。モデルは質問を理解でき、HubSpotにはAPIがある。しかし、自然言語の質問を実際のリクエストに変えるには、その間でツールを呼び出し、パラメーターを渡し、結果を整理する仕組みが必要になる。
まずはDifyを使う方法から掘り下げた。Difyはモデル、プロセス、外部ツールをつなげられる。照会の経路が決まっているなら、Workflow appであらかじめフローを組み、LLMに質問を理解させたうえで、HubSpotのツールノードからCRMを検索する。質問の自由度が高いなら、WorkflowにClassic Agent nodeを追加し、その場でモデルにツールを選ばせる。
どちらの方法でも、呼び出せるのはプラットフォームにあらかじめ設定されたツールだけだ。ソフトウェアをインストールし、ファイルを保存し、コマンドを実行できる環境はない。
Difyには2系統のAgentがある
Difyには今も旧版のAgent app（Legacy Agent app）が残っている。こちらは独立したアプリケーション形式で、Classic Agent nodeはWorkflowの内部に置かれる。ただし、どちらもモデルが設定済みのツールを呼び出す仕組みであり、汎用Shellはない。HubSpot CLIを直接実行することはできない。
Dify 1.16では、Dify Agent（Beta）も導入された。公式ドキュメントではNew Agentとも呼ばれている。Workspace内で管理、再利用できるAgentエンティティで、専用のAgent RuntimeとLinux Sandboxを備え、コマンドの実行、プログラムのインストール、ファイルの読み書きができる。
Dify Agentは単独で公開することも、Workflow内のNew Agent nodeから呼び出すこともできる。nodeはあくまで入口であり、実際に機能とSandboxを備えて動くのはDify Agentだ。
2026年8月25日時点で、Linux Sandboxを備えたDify AgentはDify CloudのSaaS機能として一般には提供されておらず、Self-host版のドキュメントにだけ掲載されている。したがって、HubSpot CLIを前提とするなら、OSSとCloudのうち明確に対応しているのは、自社で導入するCommunity EditionであってDify Cloudではない。
ここでようやくHarnessの姿が見えてくる。Harnessとは特定のアプリケーション形式ではなく、モデル、ツール、Identity、権限、Credential、Runtimeを組み合わせたものだ。モデルはAIがその仕事をできるかを決め、Harnessは実際のビジネス環境で実行できるかを決める。
RuntimeがIdentityと権限の設計を変える
ひとつの方法は、Private App Access Tokenを使うことだ。このTokenが表すのはアプリケーションであり、質問している社員ではない。すべての照会には、標準で同じアプリケーション権限が使われる。社員ごとに閲覧できるデータを制限するには、社員を別途識別し、データをフィルタリングする仕組みが必要になる。
もうひとつは、社員ごとに自分のHubSpot Personal Access Keyを使ってもらう方法だ。このKeyはHubSpot CLIやローカル開発ツールで使われ、選択できるScopesは、その社員がHubSpot上で持つユーザー権限によって制限される。
個人Keyを使うには、隔離された実行環境が必要だ。SandboxでHubSpot CLIをインストールし、その社員の~/.hscli/configを保存し、コマンドを実行できなければならない。そうして初めて、社員のIdentity、CLI、Credentialをひとつに結び付けられる。
Dify AgentのLinux Sandboxにより、この方法は実現可能になる。ただし、社員ごとに安全に隔離されたアカウント環境が自動的に用意されるわけではない。Community EditionのAgent Runtimeは、互いに信頼できないユーザーを隔離するために強化されたセキュリティ境界ではない。また、DifyがエンドユーザーごとにHubSpotのCredentialを自動で切り替えることもない。Credentialの配布と環境の隔離は、チーム側で設計する必要がある。
Personal Access Keyは、公式にはCLIとローカル開発のためのものだ。企業内のアシスタントで使うなら、Keyの保管、ローテーション、退職時の失効、監査といったコストも負うことになる。HubSpotの画面上で適用されるレコード単位の閲覧範囲を完全に再現できるかどうかも、別途検証が必要だ。
試作前の判断にはどれだけの価値があるか
こうした違いを理解していないと、開発の途中で初めて、選んだ方法にはCLI Runtimeがないと気づきかねない。そこでCommunity Editionへ切り替えれば、新たな運用コストとセキュリティコストが生じる。Credentialがアプリケーションを表すのか、社員を表すのかによっても、権限設計はまったく別の方向へ進む。
試作すれば、これらの問題は見つけられる。しかし試作には、エンジニア、環境、時間が必要だ。実現できる案でも、そのコストを投じる価値がない場合がある。
この事例を通じて、AIBPとFDEの価値も改めて確信した。社内のAIBP（AI Business Partner）は、要件、権限、コスト、ビジネス指標をAIソリューションへ落とし込む。ベンダー側のFDE（Forward Deployed Engineer）は、製品の境界を検証し、ソリューションを実際に届ける。
まず目標を制約条件へ分解する。照会内容は固定されているか。ツールを動的に選ぶ必要があるか。Identityは個人に属するのか、アプリケーションに属するのか。CLIは必須か。権限にはどこまでの粒度が必要か。企業はどれだけの導入・運用コストを負えるか。成立しない方法を除外し、残った不確実性だけを最小規模の技術検証にかける。
AIBPはビジネス判断に近く、FDEは技術的なデリバリーに近い。両者の価値は同じところから生まれる。ビジネス上の課題から正しいシステムまでの距離を縮めることだ。
まず判断し、それからDemoを作る
今回のHubSpotの要件に対する私の判断はこうだ。アプリケーション単位のCredentialを許容でき、プロセスが安定しているなら、Workflow appを使う。ユーザーの意図が幅広いなら、Classic Agent nodeを追加し、利用できるツールを制限する。社員自身のCLI Identityが必須の場合に限って、Linux Sandboxを備えたDify Agentを検討し、Keyの管理、環境の隔離、運用のコストを引き受ける。
Demoで引き続き確かめるべき点は二つだけだ。Personal Access Keyが社員のレコード閲覧範囲を完全に引き継ぐか、そして隔離方式でCredentialのリスクを引き受けられるか。この二点が明らかになるまでは、試作範囲を広げても意味がない。