LLM可観測性：DatadogのCTOからの6つの教訓

教訓1：AIが従来のコードレビューを壊した

すべての始点となるプレッシャーから話を始めましょう。読み切れないほどのコードがあるという現実です。

Lê-Quôcは率直に、プルリクエストを人間が行単位で読むという旧来のモデルは、AI支援開発との接触に耐えられないと言います。業界全体で彼が耳にする不安は、レビューが不可能になりつつあるというもの。読むだけでは追い切れないほど事象が多すぎるからです。

彼の解は、人にもっと速く読むよう求めることではなく、レビューの場を別の場所へ移すことです。

最後の一節は見落としがちです。あるエージェントが計画し、別のエージェントが実装し、さらに別のエージェントがテストする、というオーケストレーションを行うなら、実装担当が問題を解く代わりに 自動テスト を攻略するのを止める必要があります。

彼はテストを超える話もします。Datadogでは、仕様が期待どおりに動作することを示す半形式的・形式的な証明も付与します。これは、エージェントが重労働を担うようになったからこそ現実的になったもので、特に数理的に厳密な推論が可能なバックエンドやコーディネーション系のシステムで有効です。

教訓2：本番こそ唯一意味のあるテスト

CIであらゆるテストに合格することは必要条件にすぎず、十分条件ではまったくありません。重要な失敗はその先で起こります。

あらゆるリリースは、データの形やユーザーの振る舞いに関する、事前には完全には検証できない前提に基づいています。本番トラフィックに十分に晒せば、レアケースはレアではなくなり、データドリフトやモデルドリフトによる日常的な遅延やエラーへと変わります。

LLMはこれをさらに難しくします。通常のコードなら少なくとも全分岐を論理的に追えますが、モデルがなぜその出力を返すのかを機械的に説明できる人はいません。同一入力が常に同一出力を返す保証はないのです。ときおり現れる奇妙な結果は“作り込み”で完全には排除できません。

したがって、出荷前にシステムの正しさを証明しようとするのはやめます。代わりに、

• 求める振る舞いに対する評価を書き、
• 本番で監視し
• 悪化するロールアウトを止める非常停止を維持します。

問うべきは「合格したかどうか」ではなく、「問題が一過性か、それともトレンドの始まりか」です。

ライブのシグナルは人間向けダッシュボードだけではありません。デプロイメントシステムに組み込めば、慎重なエンジニアのように、ユーザーの1%から5%へと段階的にロールアウトし、実データに基づいて変更が意図どおりに機能しているかをエージェントが判断できます。

教訓3：エージェントに単調作業を任せる

Lê-Quôcが エージェント を推す理由は、エンジニアを置き換えるからではなく、人を消耗させる作業を引き受けるからです。

インシデント対応は、症状に対して仮説を次々にぶつける作業です。長引くインシデントでは、突飛な仮説が正解となることも多い。DatadogのBits AIは、エンジニアに先んじてそれらを並行的に検証し、人間はダッシュボードには現れない勘どころに舵を切ります。

より深い論点は疲労です。オンコールのロールアウトは、突然の緊張状態と長時間の無為が繰り返され、判断力が摩耗していきます。

エージェントは気にしませんし、数字を4時間見続けてもパフォーマンスが落ちません。ストレスと疲労は人間のパフォーマンスを劣化させるため、そもそもチームはオンコールをローテーションします。

絶え間ない監視は機械に任せ、人は自分を必要とする判断に戻ってくればよいのです。同じ論理はセキュリティのトリアージにも当てはまります。アナリストは、偽陽性と実際の脅威の仕分けで燃え尽きがちです。

教訓4：作業を2つのループに分ける

Lê-Quôcは、Datadogのエージェント業務を2つのループに整理しています。

開発ループ

多くのエンジニアに馴染みのあるループです。

1. コードを書く
2. 出荷する
3. 動作を確認する
4. 修正する
5. 繰り返す

Datadogの視点では、コードに起因する問題は多くの場合コードで直ります。そこでプラットフォームは、アプリケーション所有者や直近の変更、発生したエラーといった知見に基づき、修正案そのものを提示しようとします。

例としてデータベースのクエリ最適化を挙げます。遅いクエリを書き換えるだけならどのモデルにもできます。難しいのは、その書き換えが本番到達前に高速で安全だと証明することです。そこでDatadogは本番データの現実的なコピーで先にテストし、エビデンスを添えたプルリクエストを渡します。

運用・セキュリティループ

もう一方のループは、同じ人々が並行して、または別のチームが回します。

1. 検知
2. 調査
3. 修正
4. 繰り返す

ここでは、DatadogのAI Guardがセキュリティイベントをトリアージし、アナリストの手作業より速く攻撃を遮断します。エージェントは、エンジニアが毎日あまり気乗りせずに行う日常的な運用作業——たとえば特定のKubernetesポッドのリサイズ——も処理できます。

両ループを通じて、Lê-Quôcは手順の順序に厳格です。Datadogは「AIがある、何に使えるか？」から始めません。まず顧客がすでに不満を抱いている問題、たいていは「この反復作業をやりたくない」という類のものから出発し、エージェントに任せてよいかを逆算します。

教訓5：AIコストを抑制する

コストは安全性と並ぶ制約であり、大規模言語モデルの運用化コストを抑えること自体が一つの専門領域になりつつあります。DASHでのLê-Quôcの答えは、DatadogのAgent Consoleです。

どのモデルが必要かを開発者に尋ねると、たいてい最強（＝高価）なものを挙げます。それが正解のときもありますが、多くの作業は定型で、安価で高速なモデルでも十分です。両者を見分けるには、組織内のエージェントの軌跡、呼び出すツール、成功頻度を読み解き、パターンが現れるまで観察する必要があります。

それらのパターンはルールというよりヒューリスティクスになります。たとえば計画には最新のClaude OpusやGPTといったフロンティアモデル、テスト生成にはClaude Haikuのような安価な高速モデル、といった具合です。

その根底にある原則は、意思決定の当事者です。コストを単一の数字に集約すると、Lê-Quôcの言う「極めて行動可能性が低い」状態になります。全員が支出を止めれば有益な仕事が死に、全員が支出を続ければ事業が持続しません。彼は、モデルを選ぶ開発者やSREの前にデータを置くことを望みます。

教訓6：学び方を学ぶ

新しいエンジニアは何を学ぶべきかと問われ、Lê-Quôcは古くて新しい答えを返します。

モデルはこれまでで最も忍耐強い家庭教師であり、どんなことでも、どんなペースでも説明できます。かつては家庭教師を持てる王侯貴族にしかなかったレベルのアクセスです。しかし、家庭教師が有用なのは、問い質すときだけです。重要なのは、何を尋ね、どう答えを検証するかというスキルです。

彼は、コンピュータを魔法の箱として扱わず、層ごとに理解することを勧めます。スケジューラ、ロードバランサ、サンドボックスを取り上げ、モデルにその仕組みを説明させ、さらに突っ込みます。

• この用語は何を意味しますか？
• どう測定しますか？
• 背後にある数学は何ですか？
• うまく動いていると、どう判断しますか？

このように古典を学ぶのは、意図的にゆっくりです。彼は楽器の学習にたとえます。音楽をいくら聴いても、ピアノを弾くには鍵盤に手を置かなければなりません。

AIが書いたコードも同じです。Vibe coding 自体は構いませんが、なぜ動いたのかを必ず振り返るべきだと言います。なぜこの設計なのか、より良い手法はないのか、何を規範にしているのか。目標は、AIでコードを書く量を減らすことではありません。爆発的に増えた自分のコードをきちんと理解することです。

まとめ

Lê-Quôcの中心メッセージは、ループ自体は変わっていないが、速度は変わったということです。AIが動かすスピードでは、もはや人間が十分に目を配ることはできません。だからこそ、監視と、そして構築の相当部分が、疲れず慌てないエージェントへと移るのです。

彼は、可観測性を単なるチャート群ではなく、制御プレーンとして扱うべきだと主張します。エージェントがソフトウェアを作り、テストし、出荷し、運用するなら、優れたエンジニアが頼るのと同じ、本番データに基づく基盤が必要です。そして、判断と非常停止ボタンは人が持つ。Datadogは、可観測性をその取引を安全にするレイヤーとして位置づけています。

このフレーミングがエンジニアに求めるスキルは明確です。ソースだけでなく、本番での振る舞いを通してシステムを読み解く力です。その習慣を身につけるには、当社のMachine Learning in Productionスキルトラックが出発点として有用です。