🐈‍⬛

「データが想定通り」を目指すためのこれまでとこれから

に公開
データ
生成 AI
idea

概要

想定読者：

  • データ品質に関して考えることが多い同志の方々

想定読者ではないかもです😭：

  • 一つの機能に対する具体的コード等が確認したい方：どちらかといえば方針を整理したいという記事のため🙇

結論：

経緯

  • 業務内容としてデータに関わる機会が多い。要求整理・要件定義・実装・検証・保守運用・障害対応・サポート対応等々やっている中で間違いなく「データの品質」を担保するという意識をどれだけ持つかで全工程の取り組み方が変わると感じている。
  • そして生成aiと共生するこれからはよりデータの品質を守るための取り組みが重要と考えている。
  • では、どのようにデータの品質を担保するかを考えた時に、特に「データが想定通り」と言える状態は担保するために不可欠ではないかと考えている。
  • もちろん、データが想定通りだと認識していても顧客に価値提供するためのデータになっていないパターンもあるが、まずは「データが想定通り」と言い切るためにどのようなことをやってきたか・これからやるべきかを考える。

前提：データが想定通りと言い切ることが可能な状態とは

データが想定通りと言い切ることが可能な状態を考える。
以下の2つをピックアップ、
現在のデータに対して説明可能か、
そしてそのデータになった状態がタイミングが変わっても再現可能であるか、
後日各関係者の誰がみても同じ結論になるエビデンスが保持できていること
がデータが想定通りと呼ぶのに必要ではないかと考えた。
(再現可能と監査可能は担保材料が類似しているため同一化)

  • 説明可能であること：そのデータはどのように生成されたか説明できるか？という問いに対して、可能性ではなく事実を解答できること。
  • 再現・監査可能であること：その説明を再現・検証できるか？という問いに対して、仮説レベルではなく実証を行え、再現エビデンスを出せる、その説明のエビデンスはあるのか？という問いに対して、有識者ではない第三者でも後日確認できる状態で保持されていること。

これまでどのように担保してきたか

説明可能-ER図・仕様書を中心としたドキュメント文化+システムログetcのシステム記録・状態

  • これからも重要な内容である。
  • ただ得てしてドキュメントに頼るのは更新されない・一元管理されない・記載する人の整理力および読む人の理解力にも依存してしまう等の課題を持っており、ドキュメントだけで万事解決ではないと考えている。

再現・監査可能-単体テストおよび文書化された結合テスト結果+システムログetcのシステム記録・状態

  • もちろんこれからでも重要な内容である。
  • 単体テストはこれからも記載する(というかaiに書かせるだろうが)し、データに対しての単体テストを疎かにしている機能は不整合の発生率および再現性の欠如は免れないといえる。
  • ことデータに関しては実データを利用してなんぼという観点もあるので、限りなく実データに則した結合テストの手順および結果の文書化を行い、他の人が実施しても同じ結果になる状態は作成する必要がある。
  • また、システム移行の際はデータ移行~現新比較なるデータの移行および比較作業がpjを成功させるための肝となる。この際に誰がやっても同じ結果・完了基準になることが成功の可能性を上げる。
  • これら検証結果の文書化およびログの記録は有事の際の再現性を担保するために欠かせない。

以前現新比較についてポロポロ書いてた
https://zenn.dev/johndoe/articles/ee849b3aa41941

ちなみに以下のようにシステムでマルチテナント・大規模テーブル含むデータ移行の
現新比較の担保を行なった。
(詳細はまた別記事にて。もっと良い方法があったかなとも思う)

図が小さくなったのでコードでも
flowchart TD
  %% =========================
  %% データ移行システム 全体像
  %% =========================
  classDef milestone fill:#fdf6b2,stroke:#b45309,color:#7c2d12,font-weight:bold;
  classDef store fill:#e0f2fe,stroke:#0369a1,color:#0c4a6e;
  classDef compute fill:#ecfeff,stroke:#0891b2,color:#134e4a;
  classDef tool fill:#eef2ff,stroke:#3730a3,color:#1e1b4b;
  classDef warn fill:#fee2e2,stroke:#b91c1c,color:#7f1d1d;

  %% ---------- 初期移行 ----------
  subgraph MIG[データ初期移行]
    direction LR
    DB2[(DB2\n本番ソース)]:::store
    JSON[[JSON設定ファイル]]:::tool
    PY[[Python 共通処理]]:::compute
    S3[(Amazon S3\nエクスポート置き場)]:::store
    AUR[(Aurora\n各種テーブル)]:::store
    RS[(Redshift\n各種テーブル)]:::store
    CMD1[["s3_table_import\n(コマンド)"]]:::tool
    CMD2[["COPY\n(コマンド)"]]:::tool

    DB2 -- "db2 export（CSV/TSV/JSON）" --> S3
    JSON --> PY
    PY --> CMD1
    PY --> CMD2
    S3 --> CMD1 --> AUR
    S3 --> CMD2 --> RS
  end

  START([各種バッチシステム稼働開始（顧客提供前）]):::milestone

  %% ---------- 現新比較 ----------
  subgraph DIFF[移行＆稼働後 現新比較]
    direction LR
    EXP[db2 export（比較用旧データ）]:::store
    SEL[[SELECT 結果\n（Aurora/Redshift/アプリDBの新データ）]]:::compute
    DF1[[DataFrame（旧）]]:::compute
    DF2[[DataFrame（新）]]:::compute
    CMP[[差分比較ロジック\n（共通Python + 設定JSON）]]:::compute
    XLS[(Excel出力\nテーブル×時点で保存/再実行可能)]:::store

    EXP --> DF1
    SEL --> DF2
    DF1 --> CMP
    DF2 --> CMP
    CMP --> XLS

    %% 詳細調査フロー
    SUS{{数値差異の疑い\nテーブルあり?}}:::warn
    CMP --> SUS
    TMP[(tmp_対象テーブル\ndb2 export取込)]:::store
    EXALL[[EXCEPT ALL\n詳細差分抽出]]:::compute

    XLS --> SUS
    SUS -- "Yes" --> TMP
    TMP --> EXALL --> RESTART["必要であれば処理修正&差異データクレンジング"] --> RESTART([差異データクレンジング&各種バッチシステム稼働開始（顧客提供前）へ戻る]):::milestone

  end
  
 END(["受入テスト・試験投入を経て移行完了"]):::milestone

  MIG --> START --> DIFF --> END

これからどのように担保していくか

これまで担保するために実施してきたことが必要にならないということは全くなくて、絶対に実施すべき数々であると思っている。
ではなぜこれからも考える必要があると考えているかというと、
生成aiを活用した事業価値創出のために、生成aiと共生するためのデータ基盤を検討する必要があると考えているからです。

説明可能-システム記録・状態に対して、人およびai関係なくアクセスしたデータの流入経路を可視化・閲覧・仕組み化できていること

  • これまででも実施する必要はもちろんあるが、可視化が説明可能であることには重要
  • elementery等のデータ品質管理ツールも世の中には存在している(現職では導入していないので導入したいのである)

https://zenn.dev/kyami/articles/f5ded861b6f56s

  • その上で、生成aiありきのデータ基盤業務になりうるはずであり、説明可能というのは仕様を文書化して形式知化できていることではなく、事業価値を届けるために、現在のデータ基盤に対する生成aiのアプローチ・管理が妥当かを判断することが重要になってくる。
  • aiの説明可能・不可能問題にも関連するが、aiが実施した結果を限りなく説明可能に近づけるために誰でも可視化・閲覧できるよう仕組み化する必要があると考えている。

https://www.ibm.com/jp-ja/think/topics/explainable-ai

現職では残念ながら使えてないのですが、snowflakeを起点とした以下の記事がめちゃんこ面白い

https://zenn.dev/dataheroes/articles/d6da9fb50e0b1e

再現・監査可能-システム記録・状態に対して、データへの優先度付/優先度に基づいたaiのアクセス領域および履歴とガードレールの整備・隔離が行われていること

  • こちらもこれまでやってきたことはぜっったいに必要だし重要(特にログ)
  • 人のオペレーションミスのみならず、aiの暴走(という名のコントロール不足)の可能性も生じるため。
  • その上で、生成aiがデータに対してアクセスを行い、管理する。エンジニアはデータを利用した価値提供をどのように行うかに比重がよると思います。
  • ただ、データというのは正確性が何より求められるモノです。進化する時代に適応すると同時に進化する時代に壊されることへのリスク戦略が必要になってきます。
  • そうなった際に、人・aiの両者が総じて再現・監査可能であるためにはデータの生息地を制限することも考える必要があると思ってます。再現・監査可能と書きつつ、再現・監査可能ではない行動が発生したとしても事業崩壊しない整備が重要と考えているというニュアンスです。
  • (ほぼ)常にデータが100%想定通りでなければならない・検知して修正では手遅れなんてデータに対して、生成aiをアクセスさせるのは現状ご法度です。生成aiがアクセス不可能にしなければならない。設定を行ったとしても100%生成aiの実施する内容は再現可能とは言えないからです。
  • 一方で、検知して修正したら事業価値としては十分(もちろんどのデータも常に100%想定通りが良いが、それはバグが全くないシステムを作ることを目指すことと同義と考えている)に対しては、もはや人間が管理するよりかaiが管理する方が精度の高いデータ提供になると考えてます。
    そう言った中でも再現・監査可能にするために履歴は人およびaiが書き換え不可能な場所に保存しておく必要がある。(なのでログが特に重要になると考えている)
  • また、ガードレールという観点では前述の生息地の制限もそうだし、何より生成aiへのガードレール設定は隔離された場所で起動させなければならない。ガードレールのための設定を行ったのに、無視されている・なんなら書き換えられて確認した際には元に戻されていることなんて起きた際には、再現・監査可能はもちろん「データが想定通り」な状態なんて目指せないからです。
  • 「データが想定通り」からは広がっちゃうので別記事で書きたいがここらへんはデータ漏洩という観点でも重要になるため外せない。

以前も引用させていただいたが、2025年時点でこの事象が起きているので...

https://japan.zdnet.com/article/35236045/

まとめ

  • 「データが想定通り」というために、テスト・ドキュメントを中心としたこれまで重要だった内容はもちろん地盤としてこれからも重要と考えている
  • ただ、これからは人が作ったシステムよりも生成aiによる自律的なデータアクセスによる価値提供へとシフトチェンジしていく
  • このシフトチェンジはこれまで重要だった内容を徹底するだけでは「データが想定通り」とは言い切れなくする要因となりうる。
  • だからこそ、これまでと同じく発生する「データが想定通り」を目指すための対策を徹底するために生成aiを使い倒すことと、これから新しく発生する「データが想定通り」を目指すための対策として生成aiに対して共生を行える環境づくりを行うことの両方の観点を考慮して、データに向き合いたい。

参考文献・サイト

https://zenn.dev/johndoe/articles/ee849b3aa41941

https://zenn.dev/kyami/articles/f5ded861b6f56s

https://www.ibm.com/jp-ja/think/topics/explainable-ai

https://zenn.dev/dataheroes/articles/d6da9fb50e0b1e

https://japan.zdnet.com/article/35236045/

Discussion