データ漏洩を55の公理でコーディングエージェントに検問させるomds──GEPAでMLパイプラインのコードそのものを進化させる仕組みも同梱

3行まとめ

1. omdsは「1つのPythonパッケージが2つのことをする」構成のOSSで、①コーディングエージェント向けのデータサイエンス・ガードレール（train/testリーク検知、指標の誤用検知、データ来歴の追跡、実験台帳）と、②GEPAでMLパイプライン自身のコードを進化させるオフライン最適化器「E-GDS」を、同じ「オントロジー（公理）層」と「コードグラフ層」の上に乗せている。
2. ガードレール層は12パック・55公理（漏洩・ターゲット漏洩・指標・評価・再現性など汎用7パック＋不正検知・AML・信用リスク・クオンツ・保険の業界別5パック）を持ち、公式READMEはuv run pytestで「1478 passed, 6 skipped」を実測値として明記している。
3. E-GDSはgepa==0.1.1のoptimize_anythingAPIをsingle-task searchモードで使い、変異候補は5段階のブロッキングゲート（静的公理チェック→pytest→pyright→ruff→ホールドアウトでの実行時検証）を全部通過して初めて「内部PR」として昇格できる設計になっている。

2つの顔を持つパッケージ

READMEの冒頭は、omdsを次のように説明している。

1. コーディングエージェント向けのデータサイエンス・ガードレールツールキット ── omds-*というCLI群と、どのコーディングエージェントからも使えるポータブルな「Agent Skills」で、Pythonコードのtrain/testリークや指標の誤用をチェックし、コードグラフを通じてデータの来歴を追跡し、恒久的な実験台帳とエピソード記憶を保つ。オプションでMCPサーバーやClaude Codeプラグインとしても使える。
2. E-GDS ── MLパイプライン向けのオフライン進化的最適化器 ── omdsコマンド（init/evolve/promote/inspect/models）が、パイプラインのワークスペース自身のコードをGEPA（Genetic-Pareto reflective evolution）で進化させ、コードグラフを使って変異箇所を狙い撃ちし、5段階のブロッキングゲートを全部通った変種だけを昇格させる。

READMEは「これらは2つの別コードベースではない」と強調しており、両方が同じ「オントロジー的グラウンディング層」（omds.ontology──漏洩・ターゲット漏洩・スコアリング・評価・再現性・シンプレックス上の注意点・宣言済み形状の汎用7パックに加え、不正検知・AML・信用リスク・クオンツファイナンス・保険向けのオプトイン5業界パックを合わせた12パック55公理）と、同じ「コードグラフ層」（omds.codegraph──AST依存関係＋データ来歴）の上に立っている。GEPAの昇格を止める公理レジストリは、文字通りomds-guardrails checkがエージェントの編集したファイルに対して走らせているのと同じレジストリで、どちらもomds.ontology.static_check.runをomds.ontology.axioms.default_registryと一緒に呼んでいる、とREADMEは明記している。

実際にソースコードを開いて数えると、確かに12パック・55公理だった

README記載の「12パック・55公理」という数字を鵜呑みにせず、実際にGitHub上のディレクトリとソースコードを開いて数え直した。python/omds/src/omds/ontology/packs/ディレクトリには、__init__.py・_domain.py・_tracing.pyという補助ファイルを除くと、ちょうど12個のPythonファイルが並んでいた——汎用7ファイル（evaluation.py・leakage.py・reproducibility.py・scoring.py・shapes.py・simplex_transforms.py・target_leakage.py）と、業界別5ファイル（aml.py・credit_risk.py・fraud.py・insurance.py・quant.py）で、README本文の「汎用7パック＋業界別5パック」という説明と一致する。

さらに、各ファイル内で公理を表すid="ax:..."という記述の出現回数を数えたところ、次の内訳になった。

合計はちょうど55件になり、README本文の「55公理」という主張と実際のソースコードの記述が一致することを確認できた。python/omds/pyproject.toml（パッケージ本体の設定ファイル）を直接開くと、dependenciesに"gepa==0.1.1"という記載もあり、E-GDS部分で使われているGEPAのバージョン指定もREADMEの記述通りだった。

ガードレール層が検知するもの（12パック・55公理）

READMEが挙げる汎用パックの一部を引くと、たとえばleakageパックは「スケーラ・エンコーダ・欠損値補完・特徴量選択・Pipeline・サーチオブジェクトを全データやテスト分割に対してfitしてしまう」「SMOTEなどのリサンプリングを訓練分割の外で行う」「fillna(df.mean())のようなグローバル統計量を分割前に計算する」「GBDTの早期終了でテスト分割をeval_setに使う」「時系列データをシャッフル分割する」といったパターンを検知対象に挙げている。scoringパックは「log_loss/brier_score_lossをロジットや決定スコア、ハードラベルに対して計算する」「roc_auc_scoreのようなランキング指標を.predict()の出力に対して計算する」といった、指標の当てはめ間違いを検知する。

業界別パックは「ドメインを明示的に指定するまで無効」（README原文: "Domain packs are inert until you name the domain"）で、たとえばis_fraudという列名があるだけで自動的に不正検知モデルだと推測することはしない、と明記されている。--domainフラグやpyproject.toml内の[tool.omds.guardrails]設定、あるいはtask.yamlのdomains:指定で有効化する。

検知結果はcertain（コードから証明可能な誤り、フックがそのターンをブロックする）・warn（コードだけでは証明できないが、実行時アサーションで確定可能）・advice（ハイジーンやベストプラクティス）の3段階で重み付けされ、# omds: ignore[ax:fit_on_train_only]のようなコメントで個別に抑制できるが、READMEは「CLI・MCPツール・フックはこの抑制コメントを尊重するが、最適化器のゲートは尊重しない」と明記している。つまりGEPAが提案する変種は、コメントで公理チェックをすり抜けることができない設計になっている。

E-GDS──5段階のブロッキングゲート

READMEが示すアーキテクチャ図によれば、E-GDSはtask.yaml（目標・データの役割・指標・許容範囲・評価予算）を起点に、オントロジー層→コードグラフ層→オフラインGEPA進化エンジンという順で処理が進む。各候補は隔離されたクローン（git worktree＋uvの仮想環境、リソース制限、ネットワーク遮断）の中で評価され、以下5つのゲートを順番に、すべてブロッキングとして通過しなければならない。

全ゲートを通過し、パレートフロンティア上で選ばれた変種は「内部PR」として扱われる。omds promote --dry-runは指標の差分・触れた公理・blame対象・トレースIDをレポートとして出すだけでマージはせず、omds promote --approve <id>でmainにリベース、5ゲートを再実行してからマージする。設定のデフォルトpromotion.require_human: trueは常にレポート止まりで、人間の承認を挟む設計になっている。

進化の中核はgepa==0.1.1のoptimize_anythingAPIをsingle-task search（dataset=None）モードで使う部分で、GEPAのデフォルトLLMベース反射の代わりに、コードグラフに沿って狙いを絞り、オントロジー層の情報をブリーフィングとして与えるcustom_candidate_proposerを使っている。READMEは「ループの中で唯一の生きたLLM呼び出しはこの反射器（reflector）だけで、それ以外（クローン・ゲート・訓練実行）はモデルを介さない実作業だ」と説明している。

バージョンと数字の内訳

GitHub上ではまだ誰にも見つかっていないリポジトリ

GitHubのリポジトリページを直接確認すると、本記事執筆時点でスター0・フォーク0・ウォッチャー0だった。リポジトリの作成日は2026年7月12日で、タグはpre-phase-d・v0.2.0・v0.3.0の3件、ライセンスはApache-2.0。55公理・12パック・GEPA連携という作り込みの割に、この記事の執筆時点ではまだ外部からの反応（スター・フォーク）が一切付いていない、ごく早期のプロジェクトだ。

テスト件数1478件は自己申告のまま、実行はしていない

上記で確認した「12パック・55公理」「gepa==0.1.1」という数字・仕様は実際のソースコードを開いて裏取りできたが、筆者は手元でomdsをインストールし、uv run pytestを実際に実行して「1478 passed, 6 skipped」という数字を再現する検証はしていない（本記事の執筆ルール上、Anthropic有料APIの新規消費を伴う検証は見送っている）。テスト件数自体は開発元の自己申告のままで、第三者による監査結果は今回の調査範囲では見つけられなかった。E-GDSの5段階ゲートについても、実際にGEPAでMLパイプラインを進化させて動かした検証はしていない。日本語圏でのZenn記事検索では「omds」という文字列自体の該当記事は見当たらなかった（一般名詞に近く検索ノイズが大きいため、この記事では「omds oh-my-datascience」という組み合わせでの言及有無までは確認していない）。

関連記事

• DSPyの裏側にある「GEPA」を読む
• 失敗トレースからエージェントを改善するcap-evolve