SmythOS SRE：エージェント実行環境をカーネルとして設計したTypeScriptモノレポ

SREが埋めようとしているのはモデル呼び出しの差ではなくリソース管理の差

エージェント開発で最初に痛みが出るのは、モデルの推論そのものではなく、その周辺の配線である。会話履歴をどこに置くか、埋め込みベクトルをどのベクトルDBに投げるか、ファイルをローカルに置くかS3に置くか、認証情報をどこから読むか。これらは本質的なロジックではないのに、プロバイダを変えるたびに書き直しが発生する。SREはこの層をOSのカーネルに例えて切り出そうとしている。READMEには「OS-level abstractions for AI resources」という表現があり、LLM、ベクトルDB、ストレージ、キャッシュを対象に、プロバイダが違っても同じ関数とAPIが露出する統一インターフェースを提供すると説明されている。対象読者は、プロトタイプではなく本番運用を前提にエージェントを組む開発者である。ローカル、クラウド、エッジという実行環境の違いを吸収するという主張も同じ層の話で、環境ごとにコードを分岐させないことを狙っている。

モノレポはカーネル、SDK、CLIの3層に分かれている

リポジトリ構成は素直である。packages/coreがSRE本体で、READMEはこれをカーネルと呼ぶ。プラガブルなconnectorによるモジュール構造、Candidate/ACLによるリソースアクセス制御、メモリ・ストレージ・計算資源の管理、エージェントのライフサイクル管理、そして40以上のコンポーネントが列挙されている。packages/sdkは開発者が実際に触る抽象化層、packages/cliはプロジェクト生成を担う。connectorの対応範囲はREADMEに明示されていて、StorageはLocal、S3、Google Cloud、Azure、LLMはOpenAI、Anthropic、Google AI、AWS Bedrock、Groq、Perplexity、VectorDBはPinecone、Milvus、RAMVec、CacheはRAMとRedis、VaultはJSON File、AWS Secrets Manager、HashiCorpである。ここで注意したいのは、この一覧が対応の約束であって品質の保証ではない点だ。各connectorの実装成熟度はREADMEからは読み取れない。

統一インターフェースはビジネスロジックをプロバイダから切り離す

抽象化の効き方は具体的である。READMEはストレージの例を挙げ、ローカルに保存する場合もS3に保存する場合も、基礎実装の詳細を意識せずに同じ関数とAPIを呼べると説明している。同じ原則がVectorDB、Cache、LLMにも適用されると明記されている。つまりプロバイダの切り替えは、業務ロジックを1行も変えずに済むと主張されている。この設計が効くのは、コスト最適化のためにLLMを差し替える、性能検証のためにベクトルDBを入れ替える、といった用途である。ただし抽象化には代償がある。プロバイダ固有の機能、たとえば特定のLLMだけが持つパラメータや、特定のベクトルDBだけが提供するインデックス種別は、共通インターフェースの外側に落ちる可能性が高い。READMEはこの境界について何も述べていない。connectorを自分で書けば埋められるが、それは抽象化の恩恵を受けない領域が生まれることを意味する。

導入はCLI経由とSDK直接追加の2通り

手順はREADMEに2つ示されている。推奨とされているのはCLIで、npm i -g @smythos/cliでグローバルにインストールした後、sre createを実行する。READMEによれば、CLIが対話形式で設定を誘導し、用途に合ったSDKプロジェクトを生成する。既存プロジェクトに組み込む場合はnpm install @smythos/sdkを直接実行する。デバッグ時は環境変数LOG_LEVELに"debug"を設定して再実行し、ログを共有するようREADMEは案内している。設定キーとして名前が確認できるのはこのLOG_LEVELだけで、他の設定項目はREADMEからは読み取れない。サンプルはexamplesディレクトリ、ドキュメントはsmythos.github.io/sre/sdk/とsmythos.github.io/sre/core/、テンプレートは別リポジトリのSmythOS/sre-project-templatesに置かれている。

Candidate/ACLは利点であると同時に設計上の制約になる

セキュリティを後付けではなく組み込みとする方針は、READMEの設計原則として繰り返し現れる。実装としてはCandidate/ACLシステムが中核で、リソースアクセスの制御を担う。これはエージェントが任意のストレージやVaultに触れないようにする仕組みとして合理的だが、裏返すと権限モデルをSREの流儀に合わせる必要があるということでもある。既存のIAMポリシーや独自の認可レイヤを持っている組織では、Candidate/ACLとそれらを二重に管理するか、どちらかに寄せるかの判断が発生する。READMEはこの統合方法について記述していない。セキュリティが組み込みであることと、既存の権限管理と噛み合うことは別の話である。ここは導入前に自分で確かめるべき領域だ。

LangChainとは抽象化する対象が違う

比較対象として分かりやすいのはLangChainである。LangChainはチェーン、プロンプト、ツール呼び出しといったエージェントの構成要素を抽象化し、組み合わせのパターンを提供する。SREが抽象化するのはその下の層で、LLM、ベクトルDB、ストレージ、キャッシュ、Vaultという資源そのものへのアクセスである。READMEが挙げるトピックにはlangchainも含まれていて、競合というよりは土台の位置づけを狙っていると読める。実務上の違いは、LangChainを使っていてもストレージやベクトルDBの切り替えコードは自分で書く必要があるという点、逆にSREを入れてもエージェントの推論ループの設計は自分で書くという点にある。どちらか一方という関係ではなく、SREの上にLangChain風の構成を載せることも、SREのSDKだけで組むこともできる。

抽象化が重荷になる条件と、確認できない部分

SREが向かないのは、プロバイダを固定して運用する場合である。OpenAIだけを使い、S3だけを使い、切り替え予定がないなら、統一インターフェースは間接層を1枚増やすだけで、デバッグ時にスタックトレースを追う距離が伸びる。もう1つの失敗モードは、対応connectorの一覧に名前があるのに、自分の用途で必要な機能が共通APIに露出していないケースだ。この場合、connectorの内部実装を読むか、フォークして拡張するか、そのプロバイダだけ直接呼ぶかの三択になる。READMEはこの点に触れていない。また、リポジトリのメタデータからは最近のリリース情報が取得できておらず、バージョン間の互換性や破壊的変更の履歴は確認できない。最終pushは2026年4月3日と記録されているが、それ以上の開発速度は不明である。

ライセンスと保守コストの見積もり

ライセンスはMITで、リポジトリのLICENSEファイルとバッジの両方に表示されている。MITは商用利用、改変、再配布を許容する寛容なライセンスだが、無保証である。connectorを自前で追加した場合、その保守は自分の責任になる。本体をアップグレードする際に、共通インターフェースの変更が自前connectorを壊す可能性がある。バージョン固定で運用するか、追従する工数を確保するかの判断が必要だ。なお、これは法的助言ではなく、READMEとライセンス表示から読み取れる範囲の記述である。

編集部の結論

採用を検討すべきなのは、OpenAIやAnthropic、Pinecone、S3といった複数プロバイダを同じコードで切り替えたい開発者と、エージェントのライフサイクル管理を自前で書きたくないチームである。逆に、単一プロバイダに固定していて乗り換え予定がなく、既存の薄いラッパーで足りている場合、SREの抽象化層は学習対象を増やすだけになる。導入前に確認すべきは3点で、第一にpackages/coreのconnector実装が対象プロバイダすべてに存在するか、第二にCandidate/ACLが自分の権限モデルと衝突しないか、第三にnpm i -g @smythos/cliで入るCLIとnpm install @smythos/sdkのバージョン整合が取れているか。リリースノートは取得できていないため、バージョン間の互換性は自分の目でタグを追う必要がある。

公式情報源

1. Issues
2. License: MIT
3. Project website
4. README
5. SmythOS/sre on GitHub