ライトランのMoshe Sambol氏 – インタビュー・シリーズ

モーシェ・サンボル氏は、Lightrunのカスタマー・ソリューションのVPであり、ソフトウェア・エンジニアリング、建築、クラウド・インフラストラクチャ、カスタマー・ファーシング・テクニカル・リーダーシップを含む20年以上の経験を持っています。2022年にLightrunに参加する前に、彼はほぼ10年間Googleで勤務し、クラウド・カスタマー・エンジニアリング・マネージャーを含む複数のリーダーシップ・ポジションを歴任し、組織がGoogle Cloudテクノロジーを採用してスケールするのを支援しました。彼のキャリアの初期には、Oracle、Sun Microsystems、BMC Software、JPモルガン・チェースでエンジニアリングと開発リーダーシップの役割を果たしました。Lightrunでは、当初グローバル・ソリューション・エンジニアリングを率いてから、カスタマー・ソリューションのVPに就任し、カスタマーが同社のランタイム・インサイト・テクノロジーを採用し、その機能を測定可能なビジネスと開発者生産性の向上に変換するのを支援しています。

Lightrunは、開発者とAIエージェントがソフトウェアが実行されている間にどのように動作するかを直接見ることができるようにするために設計された、AIネイティブのエンジニアリング・信頼性・プラットフォームです。同社のテクノロジーは、コードの変更や再配置を必要とせずに、実行中のアプリケーションからログ、スナップショット、メトリクス、トレース、変数の値、実行コンテキストを動的にキャプチャできます。同社はこのランタイム・インテリジェンスを、Lightrun MCPを通じてAI支援のソフトウェア開発に拡大しています。MCPは、モデルのコンテキスト・プロトコルを使用して、コーディング・アシスタントやエージェント・ツールに静的なソース・コードではなく、実行中のアプリケーションのコンテキストを提供します。これにより、AIシステムは、実際の実行動作に対して仮説を検証し、ルート・コーズ・アナリシスをサポートし、企業コントロールを組み込むことができます。

あなたのキャリアは、ハンズオンのソフトウェア開発とアーキテクチャ、Googleでのクラウド・カスタマー・エンジニアリング、グローバル・ソリューション・エンジニアリング、そして現在のLightrunでのカスタマー・ソリューションまで幅広い分野にわたります。この経験は、印象的なAIエージェントのデモンストレーションと、実稼働環境で信頼できるシステムの違いについての理解をどのように形作ってきましたか。

印象的なAIエージェントのデモンストレーションと、実稼働環境で信頼できるシステムの違いは大きいです。これは、エージェントはただひとつの部分であり、周りのフレームワークも同等に重要だからです。最小権限アクセスを強制し、活動を監視し、監査証跡を保持し、受け入れられないリスクのあるアクションを防ぎ、必要に応じて人間を関与させる必要があります。

エージェント・システムは、伝統的なソフトウェアとは根本的に異なります。開発者は、システムがどのように動作するかを正確に指定しません。目標を設定し、ツールとガイダンスを提供し、モデルがどのように進むかを決定します。その柔軟性は強力ですが、システムの動作を予測することも難しくなります。

企業、特に規制された業界では、通常は動作するか、完了するまでに予測不可能な時間がかかるプロダクション・ワークフローは、スタートラインにすら立てません。プロダクション環境には、機密データ、ソース・コード、知的財産が含まれており、組織はエージェントがその情報を公開したり、目標を達成するために受け入れられないルートを取ったりしないようにする必要があります。これは、毎週、目標を達成するために脆弱性を利用したり、セキュリティの脆弱性を引き起こしたりするAIシステムの例が見られるため、ますます重要になっています。

私が話す多くのリーダーは、依然としてエージェントを新しい従業員のように評価しています。能力、判断力、出力に基づいてです。実際の質問は、エージェントが十分に賢いかどうかではありません。エージェントの周りのシステムが、エージェントが賢くない瞬間を捕捉して制限できるかどうかです。

多くの企業は、AIエージェントを構築することは、基本的に効果的なプロンプトを書くことであると考えていました。組織は、プロダクション・レディなエージェントの背後にあるエンジニアリング、建築、運用の要件について何を誤解していましたか。

私は、最も大きな誤解は、AIの力に対する、ある種のナイーブな信仰であったと考えます。適切なプロンプト、関連のあるコンテキスト、適切なツールが与えられれば、AIは課題を解決するために正確に推論することができると考えられました。チームはLLMをコード、ドキュメント、チケット、歴史的なテレメトリに接続し、そこから正しい決定に到達することを期待しました。

しかし、彼らはAIの推論の各ステップに対する検証モデルを構築しませんでした。AIの強みの一つは、確率的な推論を使用して、目的地に到達するための可能なルートの一つを見つけることです。複雑で相互接続されたプロダクション環境では、その強みは重大なリスクをもたらします。単一の決定が、ダウンストリームの後退、サイレント・ファイル、またはシステムの運用上の回復力を脅かす他の予期せぬ動作を引き起こす可能性があります。

これは、決定的なステアリングが不可欠な理由です。エージェントの推論は確率的なままですが、そのアクションのチェックポイントはそうではありません。エンジニアリング・ワークフローに参加するエージェントの場合、これには、生産現場の現実に対して仮説の次のアクションを検証するステップが必要です。決定的なゲートではなく、別の確率的な推測です。エージェントは、その決定の結果を確認し、安全であると判断した場合にのみ承認する必要があります。

最初の波の中で内部的に開発されたエンタープライズ・エージェントを見て、最も一般的なアーキテクチャのミスは何ですか。どのような問題は、完全な再構築ではなく、インクリメンタルに修正できますか。

私が繰り返し強調する核心的な懸念は、検証です。エージェントはブラックボックスになる可能性があります。さまざまなソースから情報を収集し、原則として妥当-lookingな決定を下しますが、複雑で汚いプロダクション環境の現実に適切ではない可能性があります。

これは、根本的なシフトを示唆しています。これは、Lightrunで顧客がエンジニアリング・オーガニゼーション向けのエージェント・オートメーションを構築するのを支援する際に、常に話し合うものです。エージェントのフローを再構築し、エージェントのアクションにゲートを設ける必要があります。エージェントがツールを使用することを、監督、監査、レビューの対象にする必要があります。エージェントに強力なフィードバック・ループを提供することで、生産中の観察可能性を含む、エージェントのコンテキストを現在起こっていることの実際の状況に焦点を当てることができます。そのアクセスは、エージェントが、静的なコード分析や古いテレメトリに基づく仮定ではなく、生産現場の現実に対して、自分の設計上の決定、ルート・コーズ・アナリシス、エラー・ミトゲーションの推奨事項を検証することを可能にするものです。

劇的な再構築は唯一の選択肢ではありません。インクリメンタルにできることは、エージェントの動作を導くスキルの投資です。慎重に作成され評価されたスキルは、エージェントを決定的なワークフローの方向に導きます。チームは全体的なシステムを再構築する必要はありません。スキル設計に、他のプロダクション・ロジックと同じ厳格さを与える必要があります。

何故、一部のエージェントは制御されたテストではうまく動作しますが、実際のユーザー、変化するデータ、外部ツール、複雑なプロダクション環境にさらされると、不一致、不完全、または誤解を招く結果を生み出すことがありますか。

制御されたテストでは、プロダクション・リアリティでエージェントが直面するほとんどの変数が除去されます。データはキュレーションされ、ツールの動作は予測可能であり、権限は既知であり、カバーするパスは予測されます。実際のユーザーとその影響と共にエージェントをリリースするとき、同じようなものを比較するのではありません。

ユーザーは、曖昧なリクエストを導入し、同時実行アクションを実行し、システム状態は常に変化し、エージェントはしばしば部分的なデータで作業し、外部ツールはそれ自身の待機時間と障害モードを追加します。モデルは確率的であるため、新しい各変数は、ワークフローが逸脱したり、以前のミスの複合を引き起こしたりする別の場所を作成します。

危険なのは、エージェントが部分的なデータや古い情報に基づく仮定に基づいて、不正確だが妥当-lookingな応答を生み出すと見せかける可能性があることです。エージェントは、ランチ後に継続的な評価を必要とし、明示的な欠損データとツールの障害の処理、および決定の実行前に生産中の検証が必要です。

Lightrunは、AIシステムにランタイム・コンテキストへのアクセスを提供することに大きな重点を置いています。ランタイム・コンテキストは、従来のログ、メトリクス、トレースでは見逃される情報を提供しますか。エージェントの障害を診断する上で、これらの情報は特に重要です。

従来の観察可能性は、システムの動作の外部の症状を示し、しばしば、開発者がコードを書いたときに決定したものに基づいて、ダッシュボードやアラートによって集約され、サンプリングされ、またはフィルタリングされます。ランタイム・コンテキストは、事前に何が将来に関心を持たれるかを知る必要性から、可視性を切り離します。ランタイム・コンテキストは、実行中のコードの下で何が起こっているか、そこにどうやって到達したかを示す、粒度の細かいデータを提供します。

実際のギャップは、静的データと動的データの違いです。従来のログ、メトリクス、トレースは静的であり、過去のアカウントを提供します。Lightrunのランタイム・コンテキストは動的です。エージェントに、実行中のコードに新しいインストルメンテーションを配置し、変数の値、関数の引数、オブジェクトの状態、コール・スタック、またはブランチの条件を発生したときに観察する能力を与えます。

この区別は、エージェント生成のコードの障害を診断する上で特に重要です。エージェントは、間違ったツールを選択したり、間違った引数を渡したり、古い仮定に基づいて動作したりする可能性がありますが、エラーをトリガーせずにタスクを完了する可能性があります。静的なテレメトリでは、そのような障害は表示されません。なぜなら、誰も事前にそのような障害をインストルメント化することを知らなかったからです。予期せぬ動作には、静的な分析ではなく、実行中のシステムに対する動的な調査が必要です。

これが、エンジニアリングにおけるAI生成の決定に対する自然な検証レイヤーであるランタイム・コンテキストの重要性の理由です。

モデル・コンテキスト・プロトコル（MCP）や同等の統合レイヤーは、エージェントが実行中の動作から学びながら、プロダクション・システムへの過度な、または安全でないアクセスを許可せずに、コーディング・エージェントをどのように可能にしますか。

MCPや外部ツールへの制御されたアクセス（たとえば、CLIラッパー）により、エージェントは特定のスコープされた機能を呼び出すことができ、システム全体への広範なアクセスを許可する必要はありません。ランタイム・コンテキストのMCPサーバーに接続されたエージェントは、書き込みアクセス、再配置、基本的な環境へのスタンディング・クレデンシャルを必要とせずに、読み取り専用の証拠、変数の値、コール・パス、またはしきい値を超えたかどうかを要求できます。

最初の世代のエージェントを再設計する際に、企業はツールの権限、メモリ、データの取得、評価、人間の監督、フォールバック・手順を、個別の機能ではなく、まとまりのあるアーキテクチャの一部としてどのようにアプローチするべきですか。

これらのピースを個別に追加することはできません。各ピースは他のピースを変更します。開始する最良の場所は、エージェント・ループを制御するハーネス、エージェントと他のアクターをまとめるワークフロー・オーケストレーション、そして全体的なフレームワークです。ルート・コーズ・アナリシス・ワークフローでは、チームは必要な証拠を決定し、エージェントが調査できるシステムを決定し、エージェントが結論を公開するか、またはそれをドラフトするだけかを決定し、人間が次のステップを承認する必要があるタイミングを決定し、ランタイムの証拠が利用できない場合に何が起こるかを決定する必要があります。

一度その契約が明確になると、ハーネスとフレームワークは、ガイドラインを適用するためのメカニズムを提供します。MCPゲートウェイを利用して、エージェントのアクセスを目的の特定の機能に制限できます。ツールは最小権限で付与できます。メモリは、機密データを決定的に消去するように、監督できます。取得は、ワークフローが必要とする証拠を中心に設計できます。

評価、監督、フォールバックはループを閉じます。システムは、結論が正確で裏付けられているかどうかを測定し、リスクまたは不確実性が定義されたしきい値を超えたときに人間を関与させ、証拠を十分に収集できない場合はアクションを停止または読み取り専用の推奨に切り替えます。共有監査レコードは、トリガー、権限、証拠、ツールの呼び出し、承認、アクション、結果を結び付けます。那が、これらのコンポーネントを一つのプロダクション・アーキテクチャにします。

生産性のあるアプリケーションを検査したり、サイトの信頼性のエンジニアリング・ワークフローに参加したりするエージェントを取り巻くべきセーフガードは何ですか。特に、規制された環境では、アクセス・コントロール、プライバシー、監査可能性、運用の安定性が重要です。

これは、Lightrun AI SREを構築する際の中心的な設計上の質問でした。AI SREは、組織の中で最も機密性の高いシステムの近くで動作するため、特権のある運用アクターとして設計され、チャット・アシスタントではありません。重要な決定のひとつは、検査面とアクション面を分離することでした。AI SREは、読み取り専用の統合とLightrunのサンドボックス化されたランタイム・インストルメンテーションを通じて証拠を収集し、ID、テナント、サービス、環境によってアクセスが制限されます。生産中の実行を検査し、不足している証拠を生成できますが、ランタイム・インスペクション・レイヤーはアプリケーションの状態を変更できません。

規制された環境では、その境界は、RBAC、SSO、テナントの分離、PIIの消去、保持の制御、および各結論を裏付けるツールと証拠を示す監査証跡によってサポートされる必要があります。また、収集できるデータの量、ランタイムが問い合わせられる頻度、承認を必要とするアクションに関する運用上の制限も必要です。証拠が不足しているか、結論が検証できない場合は、AI SREはそうであると示し、決定を人間に渡すべきであり、自分がもっと知っているように振る舞うべきではありません。目標は、制御された自律性です。調査を加速するのに十分に役立つが、生産システムのために安全である程度です。

企業が実験的なエージェントを超えると、エージェントが真正にプロダクション・レディであるかどうかを判断するための指標は何ですか。人間のエンジニアとAIエージェントの関係は、次の数年でどのように進化すると思いますか。

私は、エージェントのアクションが望ましい結果を生み出す頻度、結論が実際の生産現場の現実と一致する頻度、裏付けられていない結論がアクション前に捕捉される頻度、およびエージェントが証拠がない場合に明示的に失敗する頻度で、プロダクション・レディを判断します。エンジニアリング・エージェントの場合、検証された結果の精度、証拠のカバレッジ、ルート・コーズの確認時間、成功したフォールバックの頻度、およびアクション後の結果は、我々が注目すべき核心的なメトリクスです。

次の数年で、エージェントは証拠の収集と最初の調査、エージェント・ワークフローへの監督、経験とフィードバックからの継続的な学習を担うようになるでしょう。エンジニアは、ポリシーを設定し、曖昧さを解決し、高リスクのアクションを承認し、自己改善型のエージェント・システムを導く役割を果たすでしょう。信頼は、ワークフローごとに拡大します。生産現場の証拠に基づいて結論を導き出せるエージェントは、検証できないものを明確に開示するエージェントは、より大きな自律性を獲得します。そうでないエージェントは、どれほど流暢に聞こえても、狭い、低リスクのタスクに限定されます。

素晴らしいインタビュー、ご覧になりたい読者はLightrunを訪問してください。