10月26日、startuphub.aiが「The AI Engineer Now Builds the Loop, Not the Feature」と題した記事を公開した。AIエンジニアの役割はすでに「フィーチャーを書くこと」から「それを書くループを構築すること」へと移行しつつある——そう論じるのは、LLMオブザーバビリティ領域の主要プレイヤーであるArize AIの共同創業者兼CEOだ。「手動コードレビューをまだやっているなら、すでに遅れている」という一言が、その主張の核心を突いている。

「ループを作る」とはどういうことか

AIカンファレンス「AI Engineer」のニューヨーク会場で、Arize AIの共同創業者兼CEOであるAparna Dhinakaranが登壇し、AIエンジニアの役割変化を論じた。

Arize AIは、LLMアプリケーションのトレース・評価・モニタリングを統合したオブザーバビリティプラットフォームを提供する企業だ。モデルの出力品質を可視化し、本番環境でのエージェント挙動を継続的に評価・改善するための基盤を手がけており、LLMオブザーバビリティという領域でのデファクト的な存在として知られる。CEOのDhinakaranはこの分野の第一線に立つ実務家であり、今回の登壇はその知見に基づいたものだ。

彼女の主張を一言で言えば、「AIエンジニアの仕事はフィーチャーを書くことではなく、フィーチャーを書くループを構築することだ」というものだ。

この文脈を補強する数字として、DhinakaranはAndrej Karpathy（元OpenAI、元Tesla AI責任者）が示したファネルを引用した：

• 60億人以上がLLMに何らかの形で触れている
• 10〜20億人が無料枠のカジュアルユーザー
• 約2000万人のプロフェッショナルが、数週間分の作業を数日に圧縮している
• 約5000人のフロンティアラボのユーザーが、数千のエージェントを同時に走らせている

この抽象レイヤーの移行は、高級言語→コードコピー→ローカルエージェント→クラウドエージェント→常時稼働エージェント群、という形で長年かけて進んできた。Dhinakaranはその流れを踏まえ、エンジニアの定義を「スタックの上位」へ移すべきだと論じた。

常時稼働エージェント「Signal」の実装

Dhinakaranはこの思想を体現するものとして、Arizeが構築した「Signal」というエージェントをデモ披露した。

Signalはbuild → eval → ship → monitor → improveのループを自動で回すエージェントだ。具体的な動作は以下の通り：

• トリガー: 3〜6時間ごとのスケジュール実行、またはSlackメッセージ・ユーザー苦情・メトリクス閾値超過などのイベントで起動
• 実行環境: 起動のたびにサンドボックスを生成し、トレース・APMログ・リポジトリアクセスをロード。外部との通信は単一のプロキシのみ
• 出力: バグを検出するとPull Requestを自動で起票
• 永続化されるもの: 問題のメモリ、エージェントの行動トレース、リポジトリに蓄積されたスキル
• 破棄されるもの: サンドボックス、認証情報、リポジトリアクセス権

対応モデルはAnthropicファミリー全体で、Claude Code、Cursor、Codexをサポートしている。コストと品質のトレードオフをモデルを切り替えながら検証できる設計だ。

最も難しいのはエージェントではなくEval

Dhinakaranが最も強調したのは、「難しいのはエージェントの実装ではなく、評価（Eval）の設計だ」という点だ。

彼女の主張は具体的だ：

• チームはエージェントとともにトレースを確認し、共通の失敗パターンを見つけ出すことに時間を使うべき
• Evalは人間の判断と整合している必要があり、オフライン（データセット・プロンプト出力に対するテスト）とオンライン（本番テレメトリへのEval）の両方を実施する
• EvaluatorそのものもGoldenデータセットで評価する——新しいEvaluatorが人間の判断と一致しているか確認してからリリースする

この設計が崩れると何が起きるか、も明示されている。トリガーやメモリの設計が悪ければノイズだらけのPRとアラート疲弊が起きる。Evalの方向性がずれていれば間違った修正を自動化してしまう。

「常時稼働」を売りにする競合との文脈

この発表の時期は、各社が「always-on（常時稼働）」エージェントを競って打ち出している時期と重なる。記事によれば、MetaのMuese（※編集部注：元記事に登場する固有名詞だが、執筆時点で詳細な公式情報の確認が取れていない。Metaが発表した常時稼働型エージェントとして紹介されている）が先月ローンチしてApple App Storeのトップに急上昇し、OpenAIは年次開発者カンファレンスで「dots」という常時稼働エージェントを発表した。OpenAI、Meta、xAI、Googleいずれもこの「第二の脳」的なビジョンを押し出している。

Dhinakaranが指摘するのは、こうしたコンシューマー向けの前提とは異なる点だ。エンタープライズのテレメトリは、ラボ内の制御された環境よりはるかに雑然としている。だからこそ、テレメトリを読む主体は人間のダッシュボードではなくエージェント自身であるべきだ、と彼女は論じる。Arize AIがオブザーバビリティ基盤を本業とする企業だからこそ、この主張には一定の説得力がある。エンタープライズ現場の「雑然としたテレメトリ」を日常的に扱ってきた経験が、Signalの設計思想の根拠になっている。

「手動コードレビューをまだやっているなら、すでに遅れている」

記事中で引用されたこの一文が、Dhinakaranの主張を最もシンプルに要約している。エンジニアの役割が「フィーチャーを実装する人」から「フィーチャーが正しく生成・評価・修正されるループを設計する人」へと移行するとすれば、その変化に対応できているチームとそうでないチームの差は、ツールの差ではなくアーキテクチャ思想の差ということになる。

タイトルの「フィーチャーを書く時代は終わった」という断言は煽りに聞こえるかもしれないが、Arize AIのCEOが本番運用の実データをもとに設計・デモした内容として読めば、技術的な根拠のある主張だ。LLMオブザーバビリティという実務領域から出てきた言葉である点は、見落とせない文脈である。

詳細はThe AI Engineer Now Builds the Loop, Not the Featureを参照していただきたい。