見出し画像

LangChainにみるAIエージェントの未来:非決定性とトレースの重要性

よく経営者が「それはAIでやらせればいいと」と言いがちですが、エージェントを作るのはChatGPTを導入するのとはわけが違います。「AI=チャットで賢い返答 、エージェント=任せれば自動化」程度の解像度という人も多いと思われます。

LLMは非決定的なので、特にエージェントを本番投入するためには、可観測性(トレースができるようにする)とテストができるようにすることが重要になります。しかしこれを理解している人が極めて少ないのは課題です。

特に直近AIエージェントは、数十〜数百ステップの作業を、数時間かけて自律的に行うロングホライズン化が進んでおり、従来のソフトウェア開発とAIエージェントでは開発のパラダイムが全く異なります。

今回はAIエージェント・エコシステムにおけるレジェンドである、LangChain の創業者/CEO、Harrison Chase(ハリソン・チェース)氏のインタビュー記事(英語)から読み取れるAIエージェントの今後の動向について考察します。

このブログが良いなと思ったら、noteXをフォローしてくれると嬉しいです。


■LangChainの紹介

LangChain(ラングチェイン)は、アメリカ・サンフランシスコ発の、開発者・企業向けのプロトタイプ〜本番までの生成AIアプリ・AIエージェント構築に必要なインフラを提供する企業です。

  • AIエージェントは試作は簡単だが本番投入が難しく、その原因は 入力や変更が未知の挙動を生む「非決定性」という構造的課題がある

  • その結果、顧客は トレース・評価・継続的テスト・運用 にお金を払う。LangSmithはまさにそこを商品化。

  • LangSmithの価格設計も個人→チーム→エンタープライズの階段的課金で、OSSであるLangChainの利用者を自然に受け止める作り。

運営企業:LangChain, Inc.(アメリア、2023年)
CEO/創業者:Harrison Chase
サービス開始時期:2022年にOSSを公開、その後23年に会社として開始
従業員数:非公開(外部データベースでは約100人と記載あり)
ARR:1,200-1,600万ドル(約19-25.3億円、2025年7月 TechCrunch推定)
評価額:シリーズB 1億2,500万ドル(197.5億円、2025年10月)
※ 1ドル=158円換算。

BloombergTechCrunchLangChain

■AIエージェントとはなにか?

最近「AIエージェント」という言葉をよく聞きますが、これは何を指しているのかわかるでしょうか。チャットとは何が違うのでしょうか?
ハリソン氏はインタビューの中で下記のように答えています。

私が「エージェント的」になってきたと考えるのは、LLM を中心に置いて、「具体的に何をするか」を LLM に決めさせるときです。たとえば、あるときは検索しに行くかもしれないし、別のときは検索せずにユーザーへ直接返答を返すかもしれない。あるいは検索結果を得て、さらに別の検索をして、さらにもう 2 つ検索してから返すかもしれない。そうやって、制御フローを LLM が決めるわけです。

LangChain’s Harrison Chase on Building the Orchestration Layer for AI Agents|筆者訳

AIエージェントとは、「目的を達成するために、LLMが考え→ツールを使って具体的なアクションを行い→途中結果を見て次の手を決めることを反復しタスクに取り組む自律的なシステム」です。

チャットは 「入力に対して、単発で回答を返す対話UI」であるのに対し、エージェントはテキスト回答だけではなく、APIを叩く、メールを送る、コードを書くなどの Tool Use と呼ばれる「具体的なアクション」を含むのが本質的な違いです。

チャットとAIエージェントの違いは具体的なアクション

AIエージェントがとるべき具体的アクションは、初期の指示を受け取った時点では自明になっていないことがほとんどです。つまり、何をすべきかをLLMが考えて導き出す必要があります。

何かを調べてと言われたときに、「事前学習で得た知識で答えられるのか or Webで調べる必要があるのか」、「Webで調べるときにはどういったソースに当たるべきなのか」など、条件によっと取るべきアクションが変わります。

つまり具体的なアクションを取るうえでの最大の難しさは「何が正しいアクションなのか」をLLMがアクションを取りながらそこから得た結果をベースに自律的に決めることにあります。

■AIエージェントの特性は「非決定性」

濃淡はありますが、LLMは一般的なソフトウェアのように、条件分岐で決定論的にLLMが次に取るべきステップをプログラムしておくわけではなく、LLMが推論しながら適宜良いと思われるアクションを取ります。

そうすることで人間が想定していない(条件分岐で設定していない)入力があっても柔軟に対応ができます。AIエージェントは「LLM が、自らアプリケーションの制御フローをある程度自律的に決めている状態」とも言え、非決定的な動作をします。

これは従来のソフトウェアのもつ、同じ入力・同じ環境なら常に同じ出力条件になる、条件分岐による決定的な性質とは全く異なる性質です。

従来型のソフトウェアとAIエージェントの入力の柔軟性、出力の決定性の比較

LLMを組み込んだシステムや組織を考える際に重要な論点は「LLMは非決定的である」ということです。ハリソン氏も次のように述べています。

最初から私たちが気づいていたのは、LLM をシステムの中心に置くと、LLM は非決定的なので、本番に入れる自信を得るためには、可観測性とテストが必要だということです。だから LangSmith を作り始めました。

LangChain’s Harrison Chase on Building the Orchestration Layer for AI Agents|筆者訳

単発のLLMアプリなら、LLMからイマイチな返答が返ってきたとしても、プロンプトに何かは分かっており、投入されるコンテキストも分かっています。コード上で制御フローは定義されており、そのとおりに動きます。

しかしAIエージェントは、動き続けて反復し自律的に意思決定をします。そのため、例えばステップ10でのコンテキストが何になるかは、実は分からないのです。ステップ10の前に9個のステップがあり、その間にLLMが任意のものを拾ってくる可能性があるからです。

■ソフトウェア開発とAIエージェント開発の違い

当たり前に聞こえるかもしれないけど、ソフトウェア開発では、ロジックはコードの中に全部ある。見れば分かる。

Context Engineering Our Way to Long-Horizon Agents: LangChain’s Harrison Chase|筆者訳

ソフトウェア開発では、ロジックは基本的にはコードで書かれているものが全てです。一方AIエージェントを作る場合は、アプリがどう動くかのロジックは、コードの中だけではありません。大部分はLLMがロジックを握っています。

特にタスクが長くなればなるほど、LLM側の比率が高まります。そうなるとコードを見ただけでは特定のシナリオでAIエージェントが何をするか分からず、実際に動かす必要がでてきます。

これが従来のソフトウェアとAIエージェントの最大の違いになります。LLMという非決定的なシステムはブラックボックスで外部にあるため、AIエージェントがが実際に何をしているか知るには、コードを見るのではなく、現実の動作を見る必要があるのです。

つまりAIエージェントを作る場合の中核は、LLMの性能や、コードだけではなく、エージェントが各ステップの内部で何をしていたかを正確に把握するための可観測性を高める「トレーシング技術」がその中核となります。

AIエージェント開発においては、従来のソフトウェア開発よりもテストはさらに難しくなり、より人間が頻繁にレビューしたい、という状況が起きるのです。

LLMという非決定的な動きをするモノに対して、実験を繰り返しながら性能を引き出していくという、従来のソフトウェアとは大分異なった「実験的」なアプローチがアプリケーション開発に求められているわけです。

■なぜ今年ロングホライズン化が現実味を帯びたのか

ロングホライズン(長期タスク遂行)エージェントとは、数十〜数百ステップの長時間かかる作業を自律的に進めるエージェントです。

今年はとくにロングホライズン化=人間が長時間かかるタスクをAIが一定確率で完了できる長さが伸びていくことが進むと言われています。

METR Time Horizonsという長時間タスクの成功確率をし評価したものがあります。正確には「人間の熟練者が要する作業時間で測ったタスク長に対して、AIエージェントが所定の成功確率(下記グラフは50%)で完了できるタスク長を指標化したもの」です。

下記のTime HorizonをみるとGPT-4の頃の4分程度から、直近のClaude Opus4.5では4時間近くまでAIがこなせるタスク長が伸びているのがわかります。

Time Horizon 1.1|METR

このロングホライズンは「賢いモデルの登場」より、「運用スタックが整った」ことによる恩恵が大きいと考えられます。ハーネスへの移行、トレース技術の向上、キャリブレーションされたLLM judgeなどがそれに当たります。これらについて以下で詳しく説明します。

□ツールが揃い、Scaffolding → Harnessへの移行が起きている

  • scaffolding
    scaffolding(スキャフォールディング)とは、基盤モデルが弱い前提で、「この形式で出せ」「このチェックリストを通せ」など、行動の自由度を狭めたり、段取りを細かく固定したりして破綻を防ぎながら目的に到達させるための外付けの制御構造。Scaffoldingの典型パターンは下記。

    • 手続きの分解と固定

    • 「Plan→Act→Check→Revise」などの明示的認知アーキテクチャ

    • ガードレール)中心の運用

    • ツール実行を最小限に抑える

  • Harness
    Harness(ハーネス)とは、ループ運用を前提に、プランニング・コンパクション(コンテキストの圧縮)・ファイル/CLI・サブエージェント等を全部入りで同梱する運用基盤(開発している方はClaudeCodeをイメージするとわかりやすいと思います)。典型的なHarness要素は下記。

    • プランニングツールがデフォルトで入っている

    • ファイルシステム/Bash等の実務ツール接続

    • サブエージェント/スキル/MCPのオーケストレーション

    • トレーシングを前提にしたデバッグ可能性

□トレース技術の向上

前述しましたが、トレースはエージェントが各ステップで何をしていたかをトレースできるようにする基盤技術です。

ソフトウェアの真実はコードにある。エージェントでは、コードの一部と、トレースが真実の場所になる。厳密には何十億ものパラメータの中にあるが、そこは扱えない。だからトレースが、テストの起点にもなる。

Context Engineering Our Way to Long-Horizon Agents: LangChain’s Harrison Chase|筆者訳

□キャリブレーションされたLLM judge

重要なのは、人間の判断・好みに合っていること。合っていないと採点器がダメになる。LangSmithには「align evals」という概念があって、人がいくつかのトレースにラベルを付けると、それにキャリブレーションされたLLM judgeを作れる。

Context Engineering Our Way to Long-Horizon Agents: LangChain’s Harrison Chase|筆者訳

LLM、エージェントの評価は、まるばつのテストでなく、グラデーションのある人間の判断が混ざります。ヒューマン・イン・ザ・ループから、align eval→LLM judgeという流れができたことにより、改善プロセスをLLMでより自動化する事もできるようになってきたということです。

■アプリレイヤ、事業会社にとってAIエージェントが重要な理由

アプリケーションレイヤー企業や、AXを進める事業会社にとっても、このAIエージェントのロングホライズン化や、AIエージェントの周辺システムの充実による実用性向上は重要な意味を持ちます。

AI時代は常にモデルプロバイダが競合になり得るため、モデルプロバイダが入ってきづらい領域での勝負が重要になります。

モデルプロバイダが入ってきにくい領域は、クローズドデータ、クローズドプロセスがある領域です。特に汎用的でないロングテール領域のクローズドデータ、クローズドプロセスは基盤モデル側ではコスト的にも取り込みきれません。(詳しく知りたい方は下記の記事もご参照ください)

そういったクローズドなデータ、プロセス領域に対してデータフライホイールを回しながら、段階的に業務のAIエージェント化をすすめ、人の役割をより高付加価値領域に変え競争力を高めていく、というのがAI時代の事業会社の勝ち筋になります。

AI時代の事業会社の勝ち筋 AI Ops Flywheel|著者作成

そうなると如何にドメイン特化・自社特化のコア事業のAIエージェントを作り、業務を段階的に自動化していくかが重要になります。AIエージェントが戦略上重要になるポイントは下記3点です。

■①:基盤モデルはロングテールまでカバーできない

汎用プロセスと非汎用プロセスのAIエージェント化についての概念図

OpenAIやGoogleなどのモデルプロバイダが作る基盤モデルでも、適宜Web検索したり、調査プランニングをしたりと既に汎用性の高いプロセスについては既にエージェント的な動きをするようになっています。

しかし非汎用的な、「あなたの会社のプロセス」や「特定の業界の暗黙知的プロセス」は基盤モデルが学習するにはコストが高すぎます。ハリソン氏も下記のように述べています。

しかし一方で、基盤モデルには決して入らない「非汎用」な計画、非汎用なリフレクション、非汎用な制御ループもたくさん残るはずです。いくらなんでも、そこは基盤モデルに入りません。

LangChain’s Harrison Chase on Building the Orchestration Layer for AI Agents|筆者訳

ある程度汎用的で一般化されたプロセスは基盤モデルがどんどん学習したり、エージェント的な機能として取り込まれ、競争力はなくなっていきますが、非汎用的かつ事業のコア領域は事業会社こそがAIエージェント化を進めていく領域になります。

■②:メモリが参入障壁&スイッチングコストになる

AIエージェントが進んでいくと、メモリと呼ばれるAIエージェントの持つ記憶・経験領域がが本当の参入障壁になっていきます。

今のメモリの動きは、エージェントと対話している最中に、たとえば「XではなくYをすべきだった」と言うと、エージェントは自分の行動方針を編集して、次回以降に反映する。これも一種の自己改善。
僕らが追加したいのは、夜に走るジョブみたいなもの。毎晩その日のトレースを見て、自分の指示を更新する、sleep time compute(夢を見る)みたいな。

Context Engineering Our Way to Long-Horizon Agents: LangChain’s Harrison Chase|筆者訳

メモリは、過去のやり取りや失敗から、AIエージェントが自ら次からの指示・知識・手順を更新する役割を果たします。将来像は「毎晩トレースを見て指示を更新する(sleep time compute)」で、特定業務エージェントではそれは参入障壁にになり得るのです。

つまり、実務から学び経験値を詰んだAIエージェントは強い、という人間と同じようなことが起きていくのです。その壁は「特定業務の実務」という学習の場がない基盤モデルではなかなか追いつけないのです。

■③:チャット→アンビエントエージェントが本流になる

アンビエント・エージェントはイベントストリームを観察し続け、それに応じて動作し、場合によっては複数のイベントに同時に対応するものです。

LIVE: Ambient Agents and the New Agent Inbox ft. Harrison Chase|筆者訳

これまでは人間がLLMにチャットでメッセージを送るのが起点でした。しかしアンビエントエージェントの場合、起点は「人間のメッセージ」ではなく、サービスのバックグラウンドで発生するイベント起点になります。

例えば、服を買いに行った際に一緒についてきた家族が「それ似合うね」と言う、というようにサービス上の行動に寄り添って、バックグラウンドで同時に複数のAIエージェントが走り、適切なタイミングで適切に提案する、というような世界になっていくということです。

これはつまりトリガーがなければ動かないので、サービスやコンテンツなどの「場」を持っている事業者は強い、ということです。

すでにTraversal(https://traversal.com/)のようなAI SREなどもでてきています。インシデントを受けてログ等を掘り、一次調査レポートを作って人に渡すようなAIエージェントです。

100%の精度でなくても、人間がインシデントに気がついたときには、AIが先回りして一定のレポートが上がってきている、ということもできるようになります。

■まとめ

今回AIエージェントとは何か、また今後どうAIエージェントが発展していくのかについてLangChain の創業者/CEO、Harrison Chase氏のインタビューをベースにまとめてみました。

こうして見てみると、経営者がよく「それはAIでやらせればいいと」と言いがちですが、LLMは非決定的なので、従来のソフトウェアとパラダイムが違い、そう簡単でないことがわかります。

一方で特定業務をこなすプロフェッショナルAIエージェントは、いずれ各領域で事業会社側からでてくるであろうことも見て取れます。

そのためには、トレースができるようにし可観測性を高め、HITL→align eval→LLM judgeをつなげていくLLMOpsの体制を作っていくことが、競争戦略上重要でであるといえます。

これはDX等と同様で、組織的な経験値も必要で、それなりに体制も重いものになります。しかしそれをやったところが生き残り、そうでないところは駆逐されてしまう、かつて来た道のように思われます。

最後までお読みいただきありがとうございました。この記事が良いなと思ったら、ぜひnoteXをフォローしてください。


今回参考にしたインタビュー記事はこちらです。


いいなと思ったら応援しよう!