CodexがAIエージェントにおけるデータ基盤問題をあぶり出す
コーディング支援として始まったOpenAIのクラウド型ソフトウェアエンジニアリング・エージェントCodexは、今や実行レイヤーのように振る舞うようになった。このエージェント型AIツールの週間ユーザー数は300万人を超え、活動の相当部分がコーディング作業を越えて、計画、ドキュメント、運用業務へと広がっている。
OpenAIのエンジニアは、ストリーミングシステム、データパイプライン、機械学習インフラ全体で動作する、Codex上のドメイン特化型エージェントを構築している。
タンは、こうしたデータエージェントはコーディングエージェントとは異なると説明した。コーディングエージェントは文脈の境界が比較的明確だ。すなわちリポジトリである。ファイルを調べ、テストを実行し、差分を見て、挙動を検証できる。データエージェントには同じ境界がない。その「リポジトリ」は企業のデータ基盤、すなわちレイク、パイプライン、メタデータ、リネージ、権限、ダッシュボード、指標定義、所有者、そしてそれらに関する運用知識だ。この基盤が断片化していたり、手入れが行き届いていなかったりすると、エージェントは問いに答える前に会社を再構築しなければならなくなる。
彼女は、ここが従来の多くのカタログ、BIツール、セマンティックレイヤーが不十分だった点だと述べた。発見性は向上したが、しばしば断片化したデータ環境の上に乗っており、業務ロジックはノートブックやスプレッドシートに隠れ、同じ指標の複数バージョンが存在した。基盤となるシステムが、どの単一の信頼できる情報源を信じるべきかを知らなければ、より良いインターフェースでも「数日」を「数分」に縮めることはできない。
「私たちの社内データエージェントは、統合データプラットフォームの上で動作している。レイク、メタデータ、リネージ、コード、権限、クエリ実行、ダッシュボード、ノートブックは、1つの連結したシステムとして扱われる」とタンは語る。「だからこそエージェントは、優れたアナリストが行うのと同じワークフローを進められる。正規テーブルを特定し、どう生成されているかを調べ、所有者とドキュメントを確認し、過去のクエリのパターンを再利用し、SQLを実行して修復し、結果を解釈し、答えを耐久性のある成果物に変えるのだ」。
彼女はまた、今も破綻する箇所が示唆的だと付け加えた。「それでもデータ基盤の制約を引き継ぐ。つまり、欠落したメタデータ、コードから欠けたパイプライン定義、システム間でサイロ化したデータだ」。
OpenAIによれば、ある社内リリースエージェントは現在、Apache Sparkベースのシステム更新を管理している。変更を段階的にロールアウトし、数時間から数日にわたって安定性を検証し、プルリクエストを生成し、レビューのためにチームへ通知する。同様に、別のエージェントは常時稼働のオンコール支援役として機能する。エンジニアがSlackスレッド、ランブック、過去インシデントを掘り返す代わりに、エージェントが関連する文脈──過去の修正、エスカレーション経路、既知の故障モード──を取り出し、新たな問題にリアルタイムで適用する。開発環境では、エージェントがローカルサービスを立ち上げ、ブラウザセッションを起動し、UI変更をテストし、人間が1行もレビューする前に挙動を検証する。エンジニアは、コードが実際に動くかどうかの確認に何時間も費やさなくなった。
タンは、良い対応の重要な要素は、データが健全であることを検証しやすくすることだと語った。
「私たちのシステムは、レビューに必要な成果物を提示することで検証を容易にする。これには、エージェントが置いた前提、思考過程、生成されたクエリ、社内参照からの引用、回答の信頼度が含まれる」と彼女は説明した。「また、可能な場合には自己検証も行う。たとえば、検証済みのダッシュボードのような信頼できる『ゴールデン』ソースや、独立してレビューされた他の信頼できる情報源と出力を突き合わせる」。
