Datadog が Claude Code の汎用ツールを構築
Datadog は Claude Code を活用してコード生成とデバッグを自動化する「ユニバーサルマシンツール」を開発し、開発ワークフローの効率化を実現した。
キーポイント
Claude Code の活用による自動化
Datadog は大規模言語モデルである Claude Code を基盤とし、コード生成とデバッグプロセスを自動化する専用ツールを開発した。
ユニバーサルマシンツールの構築
特定のケースに限定されず、多様な開発シナリオに対応可能な「ユニバーサル」なツールとして設計され、柔軟な適用が可能となっている。
開発効率の劇的向上
従来の手動デバッグやコード記述にかかる時間を大幅に削減し、エンジニアの生産性を高めることを主目的としている。
重要な引用
Datadog built a 'universal machine tool' for Claude Code
影響分析・編集コメントを表示
影響分析
この取り組みは、企業が自社内で大規模言語モデルをカスタマイズし、既存の開発ワークフローに深く統合する実用的なケーススタディを示しています。特に「ユニバーサルマシンツール」という概念は、特定のタスクだけでなく広範な開発課題に対して AI が即座に対応できる未来像を描いており、業界全体における AI 活用基準の再定義につながる可能性があります。
編集コメント
Datadog が自社の監視・分析プラットフォームの文脈で Claude Code を活用し、開発者支援ツールとして再構築した点は、AI モデルの実装が単なる実験段階を超え、業務プロセスに深く組み込まれつつあることを示唆しています。
Temper への道
機械化とは、エージェントがより多くの作業を担うようになることを意味します。そして産業化とは、業務が反復可能で、検証可能かつ制御可能、さらにスケーラブルになることを指します。Datadog においてこの変革は一夜にして起きたわけではありません。Temper への道は、Courier、BitsEvolve、Helix という3つのプロジェクトを経由して築かれました。それぞれのプロジェクトが次の段階におけるボトルネックを明らかにし、同時に野心を育む土壌となりました。
2024 年、Datadog は分散キューイングシステム「Courier」を発表しました。これはゼロから手作業で構築され、完成までに1年を要したものです。
「部品そのものを作る難しさよりも重要だったのは、それらの相互作用を観測可能にし、テストと検証を可能にすることでした」と Sesh 氏は語ります。「そこで私たちは形式モデル化とシミュレーションに厳格に取り組みました。特にミスが重大な結果を招いたり、取り返しがつかなくなったりする箇所を見極め、その部分の品質基準をさらに高めたのです。」
2025 年9月には、クローズドループ型の進化最適化ハルネス「BitsEvolve」が構築されました。これは複数のモデルからなる評議会がコードのバリエーションを生成し、一連のベンチマーク、テスト、そして本番環境での観測データによって、どのバージョンが生き残るかを決定する仕組みです。
「これが私にとって、ソフトウェアの一部が生きた生物のように育てられる可能性を示す最初の瞬間でした。変異とフィードバックを通じて成長し、適応していくのです」と Sesh 氏は振り返ります。
課題は、進化の質はその環境に依存するという点にあります。BitsEvolve のボトルネックもこのフィードバックループでした。そこで彼らは、Kafka に匹敵するストリーミングサービス「Helix」を構築しました。Claude Code が建設の大部分を担当し、人間がその進行を監督しています。
「信じられないことに、数日で Kafka に匹敵する完全なシステムが完成しました」と Sesh 氏は語ります。「迅速に構築できたため、シャドウモードで運用を開始すると、コストを 2 倍から 5 倍削減できる可能性のある箇所が見えてきました」
しかし、本番環境への導入にはさらに多くの時間と労力が必要でした。運用上の堅牢性は、単一の人間や短期間の試行では得られず、時間をかけて複数の関係者によって築かれるものです。現在もその展開は続いています。
「ボトルネックの場所が再び変わりました。エージェントがシステムの大部分を構築できるようになった一方で、人間がそれらの成果物を本番環境にリリースする際、依然として人間向けに設計されたツールや仕組みを通じて調整を行う必要があります」と Sesh 氏は指摘します。
Datadog は、エージェントが検証済みかつポリシー駆動型のランタイム環境内で独自にツールを構築できる仕組みが必要でした。そのランタイムこそが「Temper」です。
Temper
エージェントは、チームが手作業でレビューする速度よりも速くコードを生成できますが、間違いを犯すこともあります。
Sesh 氏にとって、エージェントが生成したものと検証を通過したものの間のギャップこそが、失敗の要因が蓄積する場所です。しかし、従来のコードベースを単にエージェントで囲むだけでは、これはスループットの問題として扱われ、検証のギャップ自体は解消されません。
Temper はこの方程式を逆転させます。エージェントはアプリケーションコードを生成するのではなく、仕様書を作成します。カーネルはこの仕様書を一つずつ読み込み、4 層の分析を通じて検証した上で、その仕様に記述された実行システムをデプロイします。仕様書が証明される対象であると同時に、実行される対象でもあるため、検証された内容と実際に稼働しているシステムの間に乖離が生じることはありません。

「Temper はシステムの中心を変えるものです。エージェントはもはや、それぞれの局所的なニーズに合わせてバラバラのツールを新たに発明し続ける必要はありません。代わりに、意図や問題領域を正確に記述した仕様書を作成します。これは、ねじ山の仕様に合わせてジグや CNC 工作機械を与えるのと同じ意味での『工作機械』です。極めて再現性が高く、これらを使って航空機のような複雑なものを構築することも可能です」と Sesh は語ります。
つまりこの場合、エージェントが毎回その場で最終的な機構を即興で作り出すわけではありません。まず Temper(あるいは Temper に似た仕組み)と連携して正確な記述を生成し、動作するものを作り上げます。その後、それを再現可能で検証可能、再利用可能な形へと昇華させることで、コードベース全体を基盤としたソフトウェア工場を構築することが可能になります。
各機能は、3 つの契約によって記述されます:
Behavior:状態、遷移、事前条件、そして維持すべき安全性プロパティ。
Data contract:エンティティタイプとそのプロパティ、各タイプがサポートするアクションを定義し、機械可読形式で公開することで、ドキュメントなしでもエージェントが API 全体を発見できるようにします。
Authorization:デフォルトは拒否とし、スコープベースの承認を行います。拒否されたケースは「保留中」として記録され、人間が承認すればポリシーエンジンに即時反映(ホットロード)できます。
すべての仕様は、カーネルが読み込む前に 4 つの独立した層を通過する必要があります。記号的推論によって各ガードが充足可能であり、不変条件が帰納的に成り立つことを証明します。また、状態探索では到達可能なすべての状態を網羅的にチェックします。
決定論的シミュレーションでは、実際の生産環境コードパスを実行し、シード値付きの障害注入(パケットドロップ、遅延、順序入れ替え、クラッシュなど)を加えます。これにより、同じシード条件下で失敗が正確に再現されます。
ランダム化プロパティテストでは、約 1,000 個の擬似乱数アクションシーケンスを実行し、違反が見つかった場合は最小の反例まで縮小します。小さな仕様であれば、この一連のプロセスは 1 秒もかからずに完了します。
Helix のダークファクトリー
Simon Willison が提唱した「ダークファクトリー」という用語は、人間が介在せずエージェントだけが仮想工場で働き続けるソフトウェアプロセスを指します。Helix のダークファクトリーでは、Temper が 3 つの役割を果たします。
これは、管理されたエージェントのためのエージェント制御プレーンです。セッション、ロール、作業キュー、ライフサイクルを統括します。ツールビルダーレイヤーとしても機能し、SDLC ツール(Git、CI、デプロイメント)と小規模な Temper アプリケーションをつなぎます。さらに、データプレーンを囲むライフサイクルの表面として機能するHelix 制御 APIでもあります。
「驚きだったのは、これがエージェントインフラストラクチャよりも、より汎用的に感じられた点です」とセシュ氏は語ります。「多くのソフトウェアは、よく見ればデータベース API を取り巻く制御ロジックに過ぎません。状態管理、変更に関するポリシー、ライフサイクルの遷移、外部システムとの連携などです。Temper は、私が説明したような形状を持つあらゆるソフトウェアに応用できるという意味で、普遍的になり得るのです」
なぜ単なる CRUD アプリではダメなのか?
「Claude Code は [TypeScript や Python で CRUD アプリを] 非常にうまく構築できます」とセシュ氏は指摘します。「しかし、通常の CRUD アプリでは、制御ロジックがルート、データベース制約、サービスコード、バックグラウンドジョブ、ドキュメントに散在してしまいます。テストやカバレッジは充実しているかもしれませんが、一般的には状態機械の形式をとる運用モードは、コードベースの中に暗黙的に埋め込まれてしまっています」
「Temper は、その状態機械を明示化します。エージェントが生成するのは任意のコードではなく、精密な記述です。コンパイルステップは LLM の外側で行われます。これは、Rust コードを Rust コンパイラに渡すのと全く同じ仕組みです。遷移テーブルはデータとして扱われ、サービスメソッドの中に埋もれたスパゲッティ状の制御フローではありません。エージェントはこれを動的に変更でき、安全性を保ちながら CI を経由せずにホットリロードすることも可能です」と彼は説明します。
この先どうなるか
Temper の根底にある考え方は、各アーティファクトは人間の頭の中で完結するほど小さくあるべきだというものです。航空機や金融システムのような高信頼性のソフトウェアは数十年にわたりこのアプローチで構築されてきましたが、一般のソフトウェア分野において人間がその厳密さを達成するためのコストが高すぎたのです。しかし、エージェントが登場したことで状況が変わりました。
産業革命が可能になったのは、工作機械によって部品を組み合わせやすく、検査可能にし、交換可能にしたからです。これにより、より巨大で複雑な機械を次々と構築できるようになりました。
「このように規律を持ってファクトリー内でソフトウェアを自律的に構築できるなら、暗闇の工場に留まる必要はないかもしれません」とセシュは語ります。「こうして作られるソフトウェアは、フィードバック、選択、適応を通じて成長・育成・進化させることができる生命体のように感じられ始めています」
Datadog チームからのベストプラクティス
ボトルネックは生成側か検証側か?
検証側にボトルネックがあると仮定してください。エージェントはすでにどのチームよりも速くコードを生成しています。生成されたものと証明されたものの間に生じるギャップこそが、失敗モードが蓄積する場所です。スループットを増やすことにお金をかけるのではなく、この検証領域に投資すべきです。
エージェントは何を発行すべきか?
制御ロジックのための仕様(コードそのものではなく)、任意のコードに対する証明付きデータです。コンパイルと証明は LLM の外で行い、仕様を決定論的なカーネルに渡します。そうすれば、検証されるアーティファクトがそのまま実行されるアーティファクトになります。
制御ロジックは明示的に記述されていますか、それともコードベース全体に散在していますか?
状態機械をルートの処理やサービスメソッド、バックグラウンドジョブから切り出し、データとして表現しましょう。エージェントが読み込み、修正し、ポリシーに基づいてホットリロード可能な遷移テーブルとして実装することが重要です。
人間が各アーティファクト(生成物)を頭の中で保持して理解できるでしょうか?
もし不可能なら、それはスタート地点に戻ったのと同じです。生成される個々の部品は推論可能になるよう、常に小さく保つ必要があります。
セッション全体を見る では、Datadog が Temper という制約付きフレームワークをどのように構築したかについて、ライブデモと詳細な議論をご覧いただけます。Temper は、その場限りのエージェントツールを、セッションやチームを超えて再利用可能で安全なコンポーネントへと変換し、それらが積み重なることで価値を生み出す仕組みです。
原文を表示
The road to Temper
Mechanization means agents are doing more of the work now. And industrialization means work becomes repeatable, verifiable, controllable, and scalable. At Datadog, this didn’t happen all at once: the path to Temper led through three other projects, Courier, BitsEvolve, and Helix. Each one exposed the bottleneck for the next, and enabled them to grow their ambition.
In 2024, they introduced Courier, a distributed queuing system. It took them one year to build completely by hand and from scratch.
“The difficulty was not building the parts; it was making the interactions between them observable, testable, and verifiable,” says Sesh. “So we were rigorous with formal modeling and simulation… identified the parts where mistakes would be expensive or hard to reverse, and raised the rigor [there].”
In September 2025, they built BitsEvolve, a closed-loop evolutionary optimization harness. A council of models generates code variants. A cascade of benchmarks, tests, and production observability decides what survives.
“This was the first glimpse for me that parts of software could be cultivated like living organisms — grown through variation with feedback, and adaptation,” says Sesh.
The catch: evolution is only as good as the environment it adapts within, and BitsEvolve’s bottleneck was this feedback loop. Then they built Helix, a Kafka-comparable streaming service. Claude Code did most of the construction with one human steering it.
“To our disbelief, in a few days we had a fully functional Kafka comparable system,” says Sesh. “[It was quick to build] and we started shadowing it and we saw opportunities where it could be 2x to 5x cheaper.”
Getting it to production, though, took a lot more mileage: the operational hardening only earned over time and by more than one person and this is still in the process of rolling out.
“The bottleneck moved again where agents could build large parts of the system…but then humans still have to coordinate to ship the work to production through tools and mechanisms built for humans,” says Sesh.
Datadog needed a way for agents to build their own tools in a verified, policy-driven runtime environment. That runtime was Temper.
Temper
Agents can produce code faster than any team can review by hand, but they can make mistakes.
For Sesh, that gap between what an agent generates and what passes verification is where the failure modes accumulate. However, simply wrapping an agent around a traditional codebase treats this as a throughput problem without closing the verification gap itself.
Temper reverses this equation: instead of producing application code, agents produce specifications. The kernel reads each specification, verifies it through four layers of analysis, and deploys the running system the specification describes. Because the specification is both the artifact that gets proved and the artifact that gets executed, there is no drift between what was verified and what is running.

“Temper changes the *center* of the system. The agent no longer needs to keep inventing disconnected tools for every local need. Instead, it produces precise descriptions as specifications of the intent and problem domain. It is a machine tool in the same sense that a jig or a CNC machine, where you give them specifications of what your screw threading needs to be. It's extremely repeatable. You can run them and you can build aircraft and complex things like that with them,” says Sesh.
So in this case, the agent does not improvise the final mechanism each time. It can produce a precise description and iterate with Temper (or a Temper-like mechanism) to make something work first and then later turn that into something repeatable, checkable and reusable so you could actually build a software factory around your code base.
Each capability is described by three contracts:
- Behavior: the states, the transitions, the preconditions, and the safety properties that must hold.
- Data contract: the entity types, their properties, and the actions each type supports, published in machine-parseable form so an agent can discover the full API without documentation.
- Authorization: default-deny, scope-based approval, with denials recorded as pending decisions a human can approve and hot-load into the policy engine.
Every spec passes four independent layers before the kernel will load it. Symbolic reasoning proves each guard is satisfiable and each invariant is inductive. Exhaustive state exploration visits every reachable state.
Deterministic simulation runs the actual production code path with seeded fault injection — drops, delays, reordering, crashes — so failures reproduce exactly under the same seed.
Randomized property testing runs about a thousand pseudorandom action sequences and shrinks any violation to a minimal counterexample. On a small spec, the whole cascade runs in well under a second.
The dark factory for Helix
Simon Willison popularized the term dark factory, a software process where agents keep working without humans on the virtual factory floor. In the Helix dark factory, Temper plays three roles.
It is the agent control plane for managed agents — sessions, roles, work queues, lifecycle. It is the tool-builder layer, letting agents bridge SDLC tooling (Git, CI, deployment) with small Temper apps. And it is the Helix control API, the lifecycle surface around the data plane that exercises the workload.
“The surprise was it started to feel more general than agent infrastructure. A lot of software, if you squint, is just control logic around database APIs: state, policies around mutation, lifecycle transitions, integrations with external systems. Temper could be universal in a sense that it can be applied to any software that has the shape I described,” says Sesh.
Why not just build a CRUD app?
“Claude Code can [build a CRUD app in TypeScript or Python] very well. However, in normal CRUD apps, the control logic is spread across routes, database constraints, service code, background jobs, and documentation. It may have good tests and coverage, but the operational mode, which generally takes the form of a state machine, is implicit in the codebase,” says Sesh.
“Temper makes that state machine explicit. The agent produces a precise description, not arbitrary code. The compilation step is outside the LLM, the same way you hand Rust code to the Rust compiler. The transition table is data, not spaghetti control flow buried in service methods. Agents can change it dynamically, with safety, and hot-reload it without going through CI,” he explains.
Where this is going
The idea behind Temper is that each artifact should be small enough to fit in your head. High-assurance software like aviation and financial systems has been built this way for decades, but the cost of achieving that rigor with humans was too high for general software until agents entered the picture.
The industrial revolution became possible because machine tools made parts composable, inspectable, and replaceable, so we could build ever-larger and more complex machines.
“If agents can build software autonomously inside factories with this kind of discipline, maybe we don't need to stop at dark factories. Software built this way starts to feel like an organism we can grow, cultivate, and evolve through feedback, selection, and adaptation,” says Sesh.
Watch the full session* for a live demo and deeper discussion of how Datadog built Temper, a constrained framework that turns one-off agent tools into secure, reusable components that compound across sessions and teams.*
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み