企業成長を支えるAIエージェントの導入戦略――Greylock『Change Agents』から学ぶ
近年、生成AIを用いたエージェント（Agent）技術が急速に進化し、単なる「コーパイロット」的な支援から、より自律的に判断・行動できるシステムへとシフトしています。こうした潮流を受けて、AIスタートアップや既存の大手企業も続々と自社プロダクトにエージェントを導入し始めています。本記事では、GreylockのKarin Riley氏がモデレーターを務めたパネルディスカッションから、以下の3社CEOによる議論内容をもとに、B2B領域でのエージェント活用の最前線を紐解きます。
Decagon（CEO：Jesse氏）：AIを活用したカスタマーサービスエージェント
Windsurf（Co-founder：Verun氏）：ソフトウェア開発を超高速化するエージェントベースプラットフォーム
Resolve（Founder：Spiros氏）：インフラ/運用自動化を目指すエージェントソリューション
各社は、異なる業界・ユースケースを対象にしていますが、「エージェント導入がビジネス上必要不可欠である理由」や、「人間とAIがいかに協働できるか」という点で共通した示唆を残しました。以下では、パネルの内容を切り口ごとに整理します。
1. エージェント導入の背景と利点
1-1. 会話型の複雑な処理（Decagon）
Jesse氏は、「カスタマーサービスとは、本質的に“対話”であるため、単なる検索連携や決まりきったフローチャートでは対応しきれない」と説明します。たとえば、顧客が「カード決済に問題がある」、「特定の路線に乗り換えたい」など、一つひとつ状況が異なるため、「該当データを参照し、適切なワークフローを実行しながら会話を続行する」能力が求められます。ここにこそエージェントの強みがあり、従来型のチャットボットやIVRでは対応できない複雑性を解消します。
Jesse氏（日本語訳）
「次回フライトが遅延して予約変更が必要になった場合、AIエージェントが顧客と対話しつつ、適切な情報を参照して自動で手続きを完了します。これにより、顧客は電話待ちやメール往復のストレスから解放され、企業側は効率的に対応コストを削減できるのです。」
1-2. ソフトウェア開発の生産性向上（Windsurf）
Verun氏は、「私たちのプロダクトは、もともと“開発時間を40～50％削減”という目標からスタートしたものの、社内実証では80～90％以上のコードを自動生成し、実質的に“99％短縮”に届く可能性があると認識している」と述べました。単純な「コード補完」ではなく、「関数呼び出しや外部ツールの統合など、より大規模な変更をAIに任せる」ことで、「チーム全体のアウトプットを10倍に向上させる」ことを真剣に追究しています。
Verun氏（日本語訳）
「もはや開発者は、『どうやって書くか』ではなく、『この要件を自動で実装してほしい』と直接AIに指示する時代です。AIは、ボイラープレートコードだけでなく、設計やデプロイのパイプラインまで担い、開発プロセス全体を再構築しつつあります。」
1-3. 運用/トラブルシューティングの自動化（Resolve）
Spiros氏は、「大規模プロダクション環境では、システムの可用性を維持するために“日常的な運用タスクや調査にエンジニア工数の大半を割かれる”という問題がある」と指摘しました。Resolveのエージェントは、アラートが発生した際、「メトリクス確認→ログ収集→ダッシュボード確認→原因特定→応急対応」といった一連の調査フローを自律的に実行できるため、エンジニアの負荷を大幅に軽減し、本来集中すべき開発業務へリソースを振り向けられます。
Spiros氏（日本語訳）
「われわれは、AIエージェントがアラートを検知してから、ほとんど人間が介在しない形で根本原因調査・対応を完了することを目指しています。人間は、最後の“判断が難しい箇所”のみ確認すればよくなるのです。」
2. コパイロットからエージェントへの進化
2-1. 個人支援からチーム支援へ（Windsurf）
Verun氏は、従来のGitHub Copilotなどの「個人向けコード補完ツール」では、あくまで「一人の開発者がより速く書く」ことが主目的であったと述べます。一方で、Windsurfのエージェントは「チーム全体のパフォーマンスを10倍化し、複雑な問題を共同で解決する」ために設計されています。つまり、単なる“コードの補完”を越えて、「設計レビュー」「デプロイ」「CI/CDの自動化」など幅広い工程をAIに任せることで、“チームの生産性を飛躍的に押し上げる”という思想が根底にあります。
Verun氏（日本語訳）
「かつてはAutocompleteで次の2行を書いてほしい、Chatで質問に答えてほしいというレベルでした。しかし、いまは『自分のコードベースに対して、意思を持って大規模変更を加えてほしい』というフェーズに移っています。これは設計やレビュー、デプロイまでを含めた、チーム全体をサポートするものです。」
2-2. コードベースの大規模変更と多様なタスク（Windsurf）
Verun氏はまた、「現在のWindsurfでは、“個々の開発者が必要とする機能を、あらゆる環境・コードベースにおいて理解し、自動的に実行する”ことを目指している」と説明します。たとえば、「あるチームが独自規約を持つ巨大リポジトリ（数百万行以上）の中で、新機能を追加する」といった場面でも、AIは「意図を読み取り、既存コードとの整合性を保ちながら改修を加える」ことが可能です。これはCopilotの単一行補完レベルでは難しいアプローチです。
Verun氏（日本語訳）
「Copilotは、あくまでも補完レベルですが、私たちは『リポジトリ全体を理解し、そこに横断的に変更を加える』というレベルに挑戦しています。これがまさに次世代の『エージェント』が目指す領域です。」
2-3. エージェントの内部構造・フレームワーク（Resolve）
Spiros氏は、「Resolve内部でも複数のエージェントコンポーネントが連携し、ログ解析、メトリクス処理、インフラ構成理解などを分担しているが、“ユーザーから見るとあくまで1つのエージェントが動作しているように感じる”形をとっている」と説明しました。ユーザーが直接触れるのは「一連の調査・復旧が完了するAIアシスタント」であり、その背後で複数エージェントが協調して動いている構造です。
Spiros氏（日本語訳）
「実際には、『コード解析エージェント』『テレメトリエージェント』『インフラ監視エージェント』などがそれぞれ専門領域を担っていますが、UI上では“1つのResolveエージェント”が動いているように見える設計です。」
3. 内製 vs 購入の判断基準
3-1. コアビジネスとしての所有（Decagon/Resolve）
Jesse氏は、「もしエージェントが“自社プロダクトの差別化要素”であり、競合優位性を一手に握る重要な機能であるならば内製する価値はある。しかし、“顧客対応自体はあくまでサポート業務”であり、自社のビジネスドメイン外であるならば、専門企業から購入したほうが迅速かつコスト効率的になる」と語ります。同様にSpiros氏も、「Resolveは、専門的なObservability運用エージェントを提供しているが、一般的なSaaSと同様に、“運用ノウハウやセキュリティ要件を内製で構築するには多大な人材リソースが必要”ため、特定用途に集中している」と述べました。
Jesse氏（日本語訳）
「顧客サービスエージェントは非常に奥深い領域で、保護措置やモニタリング、カスタマイズ性などを一から構築すると、エンジニアリソースが膨大になります。だからこそ、自社のコア機能ではない限り、購入してカスタマイズできるプラットフォームを使うほうが合理的です。」
3-2. カスタマイズ性とコスト・リソース（Decagon）
Decagonが提供するサービスでは、「航空会社、レンタカー会社、銀行など、顧客企業ごとにエージェントの動作・判断ロジックが大きく異なる」ため、「AOps（Agent Operating Procedures）と呼ぶ自然言語ベースの設定画面で、非技術部門の責任者でも迅速にカスタマイズできる仕組み」が不可欠です。これにより、「技術チームは基盤部分を管理し、設定はカスタマーエクスペリエンス（CX）部門が担う」ことで、社内リソースを圧迫することなく導入できます。
Jesse氏（日本語訳）
「顧客対応を司る部門は技術的バックグラウンドが乏しい場合が多いので、『自然言語でSOP（手順書）を書くだけでエージェントを教育できる』AOpsを開発しました。これにより、エンジニアはインフラ管理に集中し、実際の対応ロジックはCX部門で自在にコントロールできます。」
3-3. ノーコード/ローコードツールの台頭（Windsurf）
Verun氏は、「Windsurfを社内で試用したところ、むしろ“開発経験のない部門担当者が、ノーコード的に見積もりや営業支援ツールを自作し、大きな効率化を実現した”事例があった」と紹介しました。つまり、「“技術レイヤー”を切り離し、専門家でなくてもAIエージェントを活用して自社課題に合ったツールを開発できる」という民主化（democratization）の波が訪れています。
Verun氏（日本語訳）
「当社のVP of Partnershipsは、ソフトウェア開発の経験がなかったにもかかわらず、Windsurf上で『見積もり作成ツール』をノーコードで構築し、既存製品よりも高品質・低コストなシステムを数日で完成させました。こうした事例は、まさにエージェント技術がもたらす民主化の可能性を示しています。」
4. カスタマイズとユーザー別要件対応
4-1. DecagonのAOps（Agent Operating Procedures）
前述の通り、Decagonでは、「自然言語のSOPを定義するだけでエージェントをトレーニングし、顧客企業固有の業務フローに合わせて動かせる」AOpsを核にしています。たとえば、「返金ポリシーが異なる複数ブランドを抱える企業」では、「ブランドごとに異なるルールをAOpsに定義すると、自動的に切り替えて対応できる」ため、逐一エンジニアに依頼する必要がありません。
Jesse氏（日本語訳）
「大手企業のコードベースは、数百万行に及び、レポジトリも数万単位に達します。こうした巨大環境で、エンドユーザー担当者が『こういう問い合わせにはこの手順で対応してほしい』と自然言語で書くだけで、エージェントが必要なデータソースにアクセスし、適切なアクションをとる──これがAOpsの真骨頂です。」
4-2. Windsurfの意図理解とチーム適応
Verun氏は、「Windsurf内部でも“ユーザーがエディタ上にコードを書き『continue（続けて）』とコメントするだけで、AIが背後にあるコードベースや組織の開発慣習を学習し、自動的に続きを生成する”仕組みを構築している」と語りました。さらに、「将来的には、『あるチームが過去に捉えてきた開発意図をAIが自動で把握し、新メンバーのオンボーディングをほぼゼロに近づける』ことを狙っている」と述べ、「チーム単位での“意図共有”をAIに任せる」未来を示唆しました。
Verun氏（日本語訳）
「大企業では、仕様書やリードミーがすぐに陳腐化してしまい、誰も更新しなくなるケースがほとんどです。Windsurfは、チームメンバーのコミット履歴とプルリクをリアルタイムに参照し、自然言語で『このプロジェクトではこういうルールで書いてください』と伝えるだけで、AIが即座に意図を汲み取ってコードを生成します。」
4-3. Resolveの個別システム理解とセキュリティ
Spiros氏は、「Resolveのエージェントは、“マルチクラウド・マイクロサービス環境を含む巨大なインフラ全体を理解する”ために、「それぞれのシステム構成（クラスタ、ロードバランサー、DB、キューなど）をメタデータとしてキャプチャし、問題検知・調査に活用する」と説明しました。さらに、「ここで重要なのは“セキュリティやアクセス制御を担保しつつ、AIが必要最小限の情報にのみアクセスできる仕組み”を用意することだ」と述べ、企業内部での機密情報漏洩リスクを抑えるためのガードレール設計の必要性を強調しました。
Spiros氏（日本語訳）
「運用エージェントが無制限にアクセスできると、誤った操作一つでデータベースが消えるリスクがあります。Resolveでは、“可視化用ダッシュボードはReadOnly、最終的なコマンド実行には必ず人間の承認が必要”といったセキュリティモデルを徹底しています。」
5. 顧客評価の指標とROI
5-1. 自動化率と顧客満足度（Decagon）
Decagonでは、顧客企業が重視する評価指標として、次の2つを挙げています。
「自動化率（AIが何％の問い合わせをハンドリングできるか）」
「最終顧客の満足度（CSATなど）」
たとえば、「1,000件の問い合わせのうち、AIが200件自動対応できれば、その分だけ人件費削減と顧客待ち時間短縮に直結します。さらに、対応品質が一定以上であれば、『顧客満足度が向上する』ため、エージェント導入のビジネスケースが非常にわかりやすい」とJesse氏は説明します。
Jesse氏（日本語訳）
「まずは“Tier1（簡易対応）”の問い合わせをAIに任せて、自動化率を20～30％まで引き上げる。その成果が出始めると、『CSATも向上し、コストも削減できる』という明確なROIが示せるため、大手顧客も検討に踏み切りやすくなります。」
5-2. コード生成割合と生産性（Windsurf）
Windsurfでは、「リポジトリにコミットされるコードのうち、何％をAIが生成したか（Percentage of Code Written）」を定量指標として重視しています。この指標は、「AI導入前後で生産性がどれだけ向上したか」を示す代理指標になり得ます。ただし、Verun氏は、「“生産性の絶対値をABテストで測定するのは難しく、製品のアップデートが頻繁に起こるため、3ヵ月で再テストが必要になる。したがって、『コード生成率』を追いかける形が現実的だ”と語ります。
Verun氏（日本語訳）
「多くの企業は『3ヵ月前と今で同じチームを比較する』ABテストを実行しようとしますが、製品が日々進化するため、正確な比較が難しい。そこで、『コード生成割合』という不変の指標を追うことで、プロダクト改善が生産性にどう寄与しているかを可視化しています。」
5-3. 障害対応時間短縮とストレス軽減（Resolve）
Resolveの顧客は、主に「“インフラ障害発生時の平均復旧時間（MTTR）”」や「“深夜アラート対応の負荷軽減”」を評価ポイントとしています。Spiros氏は、「“人間が何時間かけて問題をトラブルシューティングしていたケースを、AIエージェントが20～30分程度で解決できるようになれば、コスト面だけでなく、エンジニアのストレス軽減という無形の価値も大きい”と述べます。
Spiros氏（日本語訳）
「あるお客様では、深夜3時に発生した障害をAIエージェントが1/10の時間で切り分けし、そのまま対応まで完結した事例があります。このような“ストレスフリー”を実現できる点が、企業の意思決定を後押ししています。」
6. 人間とエージェントの協働
6-1. 人間介入のタイミング（Decagon）
Jesse氏は、「“感度（センシティビティ）”や“規制要件”に応じて、人間を介入させるラインを決めている」と説明します。具体的には、金融業界やヘルスケアなどの規制分野では、「詐欺調査や医療判断のように誤りが許されないケースは最初から人間が担当し、AIはサポートに徹する」というルールを設けます。それ以外の“Tier1／Tier2”レベルの比較的容易な問い合わせはAIエージェントに任せ、複雑な上位層（Tier3）だけ人間にエスカレーションする仕組みです。
Jesse氏（日本語訳）
「たとえば、クレジットカード業界では、“一定金額以上の返金リクエスト”などは必ず人間の判断が必要です。一方で、“住所変更”や“パスワードリセット”などはAIにまかせ、スピードアップとコスト削減を実現します。」
6-2. 自動化可能タスクと人間が担うべきタスク（Resolve）
Spiros氏は、「“分散システムの障害対応”では、AIは「システムログ解析」「ダッシュボードチェック」といった“集計・要約タスク”を得意とするが、「“複数の解決策があり、どちらを適用すべきか迷う場面”では、人間の判断が不可欠」だと語ります。現状は「最後の意思決定を人間が行い、復旧手順をAIが提案する」かたちにとどめ、完全自律化は課題が残る領域です。
Spiros氏（日本語訳）
「AIはまず候補となる解決策を複数リストアップし、『AとBがあり、Aはこういう影響、Bはこういう影響』と提示します。最終的にどちらを実行するかは、人間が可逆的（リバーシブル）なアクションである限りにおいて承認する仕組みです。」
6-3. スペクトラムとしての判断基準
全体を通して示されたのは、人間とAIの協働は「完璧な切り分け」ではなく、あくまで“自動化の度合いを調節するスペクトラム”であるという考え方です。たとえば、「“まずTier1をAIに任せ、必要に応じて人間がTier2で介入し、最終的にTier3のみ人間が担当する”」といった段階的な導入が有効であり、「“AIが完璧になるのを待つ必要はなく、現状で使える部分から積み上げれば良い”というメッセージが一貫して共有されました。
Jesse氏（日本語訳）
「AIエージェントは、100％の完璧さを追求する必要はありません。まず70～80％できる領域を自動化し、人間は残りを担当する。そこから徐々にカバー範囲を広げていけばよいのです。」
7. エージェント間連携の可能性と課題
7-1. マルチエージェントの難しさ（Jesse／Verun）
Jesse氏とVerun氏の両名は、「“複数のエージェントが連携して動作する”というビジョンは語られるものの、実務ではまだ実現が難しい」と口をそろえました。主な理由として以下が挙げられます。
「共通言語・プロトコルの未整備」
エージェント同士が“会話”するためのフォーマットや共有すべきコンテキストが定義されておらず、“あるエージェントが理解できる情報を、別のエージェントに渡しても適切に解釈されない”ケースが多い。
「セキュリティ／コンプライアンスの複雑化」
複数のエージェントが自由に社内システムを横断すると、“誤操作や情報漏洩のリスク”が高まるため、厳格なガードレール設計が必要になる。
「単一エージェントで完結したほうが管理負荷が小さい」
複数エージェントを立ち上げて連携を保つよりも、“1つの巨大モデルに機能を集約するほうがシンプルで効果的”という声もありました。
Verun氏（日本語訳）
「かつて自動運転車開発では、複数のMLモデルをそれぞれ連携させていましたが、結局Pixel-to-Torqueのような単一モデルへ回帰する流れが主流になりました。エージェント間連携も同様に、まずは“1つの賢いエージェント”を磨くほうが合理的だと感じています。」
7-2. 現状の内部エージェント構成（Resolve）
Spiros氏は、「Resolve内部でも『コード理解エージェント』『テレメトリエージェント』『インフラ設定エージェント』など複数が動作しているが、“最終的にユーザーに提示するのは1体(ひとつ)のエージェント”として見せるUIデザインにしている」と語りました。「ユーザー視点では“バラバラに動いている”ことは見えないが、内部で情報をやり取りしながら協調して問題を解決する」設計思想です。
Spiros氏（日本語訳）
「私たちが複数エージェントを活用するのは、あくまで“バックエンド処理を最適化するための手段”です。ユーザーには1つのエージェントが仕事をしているように見せることで、導入やUXの複雑度を下げています。」
7-3. 共通言語／プロトコル・セキュリティ問題
議論の中では、「“MCP（Multiagent Communication Protocol）”のような規格が必要では？」との指摘もありましたが、Verun氏は「“MCPはまだ十分に成熟しておらず、企業ニーズをカバーしきれていない”と述べ、現状は各社が独自実装でなんとか凌いでいる状況を説明しました。たとえば「“システム全体を横断する際、エージェント間での共通語彙（例：『リリース』が何を意味するのか）をどう定義するか”など、かなりの課題が残っています。
Verun氏（日本語訳）
「大手企業が内部システムを横断する共通の”仕様書”や”言葉の辞書”を持つことは稀で、いまは『エージェントがどう解釈するか』がバラバラです。MCPのような仕組みはあるものの、まだまだ実用レベルではありません。」
8. 今後の展望と技術的天井（天井課題）
パネル最後のライトニングラウンド質問では、「“現状、エージェントが対応できず技術的に天井（ceiling）を迎えているタスク”と、“近い将来には解決可能になると期待している領域”が語られました。
8-1. 理解不能な複雑事例の自動化（Tier3の壁：Decagon）
Decagonでは、「ハードウェア製品など、マニュアルが部分的しか存在せず、専門知識を積んだTier3エージェント（人間）が2年以上の経験を積んでようやく対応できるような高度なトラブルシューティング」が現状の天井とされています。たとえば、「“デバイス裏面のインジケーターLEDが赤なら故障A、緑なら故障B、黄なら故障C”のような、十分に構造化されていない障害事例は、現状のエージェントでは再現が難しい」と述べました。
Jesse氏（日本語訳）
「Tier3の領域は、『正解が必ずしも1つに決まっていない』『人間が暗黙知や経験を元に判断する』ような分野です。今はまだAIエージェントがそこまで“自分で考えて解決する”には至っていませんが、数年以内に解決されると考えています。」
8-2. 仕様からアプリケーション自動生成の到来（Windsurf）
Verun氏は、「『将来的には、ユーザーが自然言語でアプリ仕様を書くと、AIが完全なアプリをゼロから構築する』という段階に到達したい」と語ります。現状は「既存アプリの改修やコード生成サポート」が主ですが、「仕様理解、ドメイン知識の獲得、既存アーキテクチャへの適応」をAIが完遂できれば、“No-Code/Low-Codeの次”とも言うべきフェーズに移行すると期待しています。
Verun氏（日本語訳）
「たとえば、マーケティング部門が『顧客データをもとに見積もりフォームを生成し、管理画面から業績レポートを自動で作成したい』と自然言語で指示すると、今日に至るまでのすべての情報をAIが理解し、フルスタックでアプリを構築する──そんな未来が見え始めています。」
8-3. 水平タスク対垂直タスクの限界（Resolve）
Spiros氏は、「“AIエージェントは、水平的（Horizontal）な情報収集や集約、要約など複数ソースをまたがる処理には強いが、深い垂直（Vertical）領域、つまり人間が容易に推論・判断できるタスクを自動化するにはまだ時間がかかる”と説明しました。加えて、「複数の解決手段を評価し、初めて“正解”を導き出すような領域では、AIはまだ“偽装推論”に近い状態」であり、より堅牢な推論能力を獲得する必要があると指摘しました。
Spiros氏（日本語訳）
「『異なるログデータから相関関係を見出し、初めて問題の本質をつかむ』ような作業は水平的なAIにとっては得意ですが、『未知の障害で、まずどう考えるべきかをゼロから立ち上げる』ような領域は、現在でも人間が最終的に手を動かさざるを得ません。ここを克服するには、AIの推論プロセスそのものを進化させる必要があります。」
本記事では、Greylockの「Change Agents」パネルディスカッションを通じて、Decagon、Windsurf、Resolveという3社の最先端事例をもとに、B2B領域におけるAIエージェント活用の全体像を整理しました。主なポイントを改めてまとめると以下の通りです。
これらを踏まえると、「AIエージェントは、もはや実証実験のフェーズを越え、B2Bビジネスの中核を担うテクノロジー領域となりつつある」といえます。企業は自社ドメインにおける“どの部分をエージェント任せにし、どこで人間介入を残すか”を明確に定義し、段階的に導入を進めることで、コスト削減や顧客満足度向上、エンジニア工数の有効活用を実現できるでしょう。今後もAIエージェントの進化は続き、「人間とAIが共創する新しい働き方」が定着することは間違いありません。本記事が、その戦略検討の一助となれば幸いです。
