エージェンティック開発で「中にはいる」(5)

勘定系システムから脱皮してAI駆動型システムを創るには

エージェンティック開発では、従来のSoR（System of Record）の世界を脱皮して、データレイクハウスをベースにエージェントがデータを駆使する企業システムを実現することが必要です。しかし長年SoRで経験を積んだPMは社内からデータをかき集めて蓄積し、ビジネスゴールを達成するといったことを経験したことがありません。データレイクハウスをどうやって構築したら良いか、また、そこで動くエージェントをどう評価したら良いかといった観点は彼らからすると全く新しい挑戦になります。

システム開発が直面する新しい挑戦へどのように取り組むべきか。これについてもGeminiの回答を聞いてみたいと思います。

＜Gemini：データレイクハウスでAI駆動型システムを創る＞

SoR（記録のシステム）の厳格なトランザクション管理に最適化されてきた従来のPMにとって、データレイクハウスという「曖昧で広大な海」を前提としたエージェンティック開発への移行は、パラダイムシフトそのものです。

決定論的（100%正解がある）なSoRの世界から、確率論的（推論と探索）なデータレイクハウス＋AIの世界へ踏み出すにあたり、PMが「中にはいる」ために考慮すべき最重要ポイントは以下の3点です。

1. 「データ収集」は技術論ではなく「社内政治のハッキング」である

SoRのPMは、決められたスコープ内で要件を定義することに長けていますが、データレイクハウスの構築は「全社のデータサイロを破壊する」行為に他なりません。PMが最初に直面するのは技術的な壁ではなく、「そのデータはうちの部署の持ち物だ」「セキュリティ上、外の基盤には出せない」という各部門の抵抗です。

ここでのPMの新しい任務は、アーキテクチャの設計だけでなく、経営層を巻き込んでデータのオーナーシップを「部門」から「全社」へ引き剥がすためのガバナンス構築（社内交渉）に「中にはいる」ことです。ここを突破せずにツールだけ入れても、レイクハウスはただの「空の水槽」になります。

2. メダリオン・アーキテクチャによる「データの信頼性」の階層化

SoRではRDBMSの厳密なスキーマがデータの品質を担保してくれましたが、レイクハウスではあらゆる粒度のデータが混在します。

PMは、AIエージェントにゴミ（ノイズ）を食わせないための「浄水フィルター」の設計に中にはいる必要があります。具体的には、ブロンズ（生データ）→シルバー（クレンジング済み）→ゴールド（ビジネス要件に適合・エージェントが参照可能）というメダリオン・アーキテクチャの概念を深く理解し、どの段階のデータをエージェントにアクセスさせるかのデータパイプライン設計を主導しなければなりません。

3. エージェントの評価基準：テスト仕様書から「トレースとガードレール」へ エージェントは自律的にデータを探索し、SQLを生成し、推論を行います。従来のPMが得意としていた「入力Aに対して出力Bになるか」という単体テストの概念は通用しません。

エージェントを評価・統制するために、PMは以下の新しい観点を持つ必要があります。

推論プロセス（Chain of Thought）の可視化：エージェントが「なぜその結論に至ったか」「レイクハウス内のどのデータを参照したか」のログ（トレース）を後から人間が監査できる仕組み（オブザーバビリティ）を要件に組み込むこと。

ガードレールの設計（ブラスト・ラジアスの最小化）：万が一エージェントがハルシネーション（嘘）をついたり、暴走したりした場合に備え、「参照は許すが更新・削除は絶対に行わせない」「特定金額以上の処理には人間の承認（Human-in-the-Loop）を挟む」といった、フェイルセーフの境界線をビジネス要件として定義すること。

SoRの重厚長大なシステムを牽引してきたPMの「責任感」と「品質への執念」は、データレイクハウスという不確実性の高い基盤においてこそ強力な武器になります。必要なのは、その執念を向ける先を「コードのバグ」から「データの品質とAIの推論プロセス」へシフトさせることだけです。

（以上、Geminiの回答）