Data Cost Protocol データコストプロトコル MCPサーバーとDCP
Claw系との格闘に敗れ反省会を設けた。
そこで汎用であることの重要性を確認し、ハックよりも王道、と軌道修正。
次の目的は MCP Server に DCPを導入することになった。
これは Engram という自作機能ですでにほぼ実現していた。
Engram自体がMCPサーバーで、Engram の実装が終わってからDCPが登場したので、部分的にDCPを実装していたりと、導入が中途半端だった。
開発の時系列としては
Engram実装 -> Receptor System実装 (演算箇所がほぼAI ネイティブデータ) -> 記憶継承へのこだわり (ほぼ数値） -> データ量子化の議論 -> DCP発案
一連の開発で一貫していたのは、私が数値見ても意味がない、と言う事。
自分が理解する必要がないと割り切り、概念を監督するだけで実装はAI任せ。
だからAIが理解しやすい形式の方が良いだろう、と考えていた。
これがDCPの出発点だ「人間が読まないデータを人間向けにする必要がない」必要があればデコードすれば良い。
さて、Engram では部分的にしかDCPを実装していなかったので、これを下敷きに汎用化を考えることにした。（汎用化の話はまた別のエントリーにしようと思う、今はMCPサーバー）
結局、Claw系とはAIを遠隔操作しているわけだ。それはPC経由でAI利用するのと変わらない操作がある、ならば、MCP Serverの応答を DCP化すればClawだろうがPCだろうが、結局は恩恵があるだろう、ということ。
DCPが注目される時がくればそのうちClawコミュニティにも採用される日が来るかも知れない。
さて、それがこの機能、dcp-gateway
MCPサーバを利用する時に通すゲートウェイ、それ自体が新しい概念だ。
セキュリティとか認証とかそういう目的で推奨され始めているらしい。それをDCPコンバータとして利用する。
そもそもどれだけのユーザがMCPサーバを利用しているのかよくわからない。
正直私も自作機能しか使っていない。しかし、このゲートウェイを通すだけで、トークン消費を削減する。
例外はJSONを返さないタイプのサーバーレスポンス、JSON -> DCP の動線しか確保していない。
対応しても良いが、少し主旨から外れるから保留。
トークン消費が減る、これだけで価値があると思うがどうだろう？
レスポンスの可読性が減るから困る？まぁデコーダ作れるから復元したらよろしい。
あくまで、AIのための通信プロトコル、である。
つづく
