AIKernel.NET

AIKernel 正典の「公開契約」について──0.1.3 で何を固定し、何をまだ動かすのか

Published: | Updated:

AIKernel 正典 0.1.3 の整理に向けて、公開 API、実験層、互換性、ドキュメント表現をどのように切り分けているのかを、公開契約という観点から整理します。

カテゴリ: Development Log, Release Notes, AI Infrastructure, Governance


昨日、AIKernel 正典 0.1.3 の公開を少しだけ延期することをお知らせしました。

今日は、その続報というよりも、開発メモに近い内容です。

今回見直しているのは、単に「リリースできるかどうか」ではありません。

何を正典として固定し、何をまだ実験層として動かしておくべきか。

この境界を、もう一度整理しています。

AIKernel における正典は、単なるバージョン番号ではありません。

それは、実装、設計、テスト、ドキュメント、そして今後の拡張が従うべき 公開契約 です。


1. 公開契約とは何か

ここでいう公開契約とは、開発者に対する約束です。

ある interface を正典として公開するなら、その境界は今後の Provider や runtime が依存する前提になります。

ある DTO を正典化するなら、その shape は Telemetry、Replay、Control、WASM 境界の間で共有される語彙になります。

ある enum を公開するなら、その値は単なる内部実装の分岐ではなく、外部から読める状態表現になります。

つまり、正典化とは「動いたコードを出すこと」ではありません。

将来の実装が依存してよい境界を、外部に対して明示すること です。

ここを曖昧にしたまま出すと、あとで設計を直したくなったときに、利用者側の前提を壊してしまいます。

だから 0.1.3 では、実装そのものだけでなく、公開境界の意味も確認しています。


2. 今回見直している三つの境界

0.1.3 系で特に見直しているのは、次の三つの境界です。

experimental behavior
  ↓
canonical contract
  ↓
public API / document

実験層で生まれた仕組みは、すぐに正典へ入れるべきものばかりではありません。

DOOM デモのような過酷な実験場では、動かすための仮設コードや、シナリオ固有の最適化も必要になります。

それらは非常に重要です。

しかし、そのまま公開 API にすると、後から汎用化するときに足かせになる可能性があります。

一方で、実験層からコアへ戻すべきものもあります。

たとえば、次のような構造です。

  • 意思決定を決定論的にテストする Control VM 的な仕組み
  • WASM 実行環境における状態所有権の整理
  • Provider と runtime の責務境界
  • 型安全な制御パケット
  • Telemetry / Replay に接続できる観測点

これらは、単なるデモ都合ではなく、AIKernel のコア基盤へ戻す価値があります。

今回の整理では、こうした要素を「どの名前で」「どの型で」「どの責務として」公開するかを確認しています。


3. 固定すべきもの、まだ動かすべきもの

正典化で一番難しいのは、すべてを早く固定すればよいわけではない点です。

固定すべきものがあります。

たとえば、Provider が担うべき責務、runtime が所有すべき状態、Control 側へ渡す packet の基本構造、Replay 可能性を保つための観測単位。

これらは、曖昧なままにすると後続の実装が揺れます。

一方で、まだ動かしてよいものもあります。

シナリオ固有のしきい値。 実験中の HUD 表示名。 特定デモに最適化された判定順序。 研究途上の概念名。 まだ十分に一般化していない DSL の細部。

これらは、急いで正典 API に固定しない方がよい場合があります。

AIKernel は、実験の速度と正典の安定性の両方を必要としています。

だからこそ、0.1.3 では「固定する勇気」だけでなく、まだ固定しない判断 も大切にしています。


4. ドキュメントも契約の一部である

もうひとつ見直しているのが、ドキュメント上の表現です。

AIKernel では、実装と同じくらい言葉が重要です。

たとえば、ある機能を「完全に保証する」と書くのか、「現在の設計ではこの経路を優先する」と書くのかで、読者が受け取る意味は大きく変わります。

実験として強い成果が出たときほど、言葉は前のめりになりがちです。

しかし、正典ドキュメントでは、実装より先に言葉だけが走ってはいけません。

今できていること。 設計として目指していること。 まだ検証中のこと。 今後の拡張で扱うこと。

これらを分けて書く必要があります。

今回の 0.1.3 整理では、コードだけでなく、そうした表現の粒度も確認しています。


5. 0.1.3 は「完成宣言」ではなく、境界整理のマイルストーン

0.1.3 は、AIKernel が完成したことを宣言するバージョンではありません。

むしろ、ここ数日の実験で得られた構造を、次に進めるために整理するマイルストーンです。

DOOM デモで見えた課題。 Control VM で再現できた意思決定の揺れ。 WASM / GPU / Provider 境界で見えた状態所有権の問題。 Semantic Fusion Layer で整理した物理世界と意味論世界の接続。 Telemetry と Replay に戻すべき観測点。

これらを、AIKernel のコアにどう戻すか。

そのために、公開契約を見直しています。


6. 次に出す正典のために

昨日の記事では、リリース延期そのものをお知らせしました。

今日の記事では、その内側で何を見ているのかを少しだけ共有しました。

結論はシンプルです。

AIKernel 正典 0.1.3 は、動いたものをそのまま出すのではなく、公開契約として整えている。

少し時間は使います。

しかし、そのぶん次の 0.1.3 系は、より落ち着いた形で届けられるはずです。

急がず、止まらず。

AIKernel は、正典として積み上げるべきものを、ひとつずつ形にしていきます。


AIKernel.NET は Bing Webmaster Tools / IndexNow に対応しています。
記事更新は検索エンジンへ即時通知され、最新情報が迅速にインデックスされます。