【要約】自作CLIをMCPサーバ化する2つの方法: subprocess版と直結版で940倍差が出た話 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が既存のCLIをAIエージェントで利用するためにMCPサーバ化する際、実装の容易さから不適切な手法を選択し、運用上の課題を招くリスクがある。具体的には以下の問題が挙げられる。
- ・セキュリティリスク：LLMが生成した引数をそのままシェルに渡すと、シェルインジェクションを許す可能性がある。
- ・仕様の誤解釈：CLIのexit codeをエラーと誤認し、本来の判定結果を捨ててしまう恐れがある。
- ・累積的な遅延：プロセス起動の固定費が、エージェントによる高頻度なツール呼び出し時に無視できない遅延を生む。
// Approach
筆者は自作CLI「domain-pre-flight」を用い、2つの実装手法の性能と安全性を比較検証した。
- ・subprocess方式：CLIを外部プロセスとして呼び出し、標準出力をパースして結果を得る手法。
- ・ライブラリ直結方式：CLIの内部関数を直接importして呼び出す、より密結合な手法。
- ・設計の最適化：CLIのsubcommandをそのまま並べるのではなく、LLMのユースケース単位でツールを定義する設計手法。
// Result
検証の結果、ネットワークを介さない高速な処理において、ライブラリ直結方式はsubprocess方式より約940倍高速であった。
- ・オフライン処理：直結 0.2msに対し、subprocessは188.3msと大きな差が出た。
- ・オンライン処理：ネットワーク待ちが支配的となり、方式による差は1.4倍に縮小した。
- ・設計指針：LLMが自律的にループできる操作は、個別のツールにせず統合して提供すべきである。
Senior Engineer Insight
> エージェントの反復動作を考慮した設計が不可欠である。単発の呼び出しでは差が小さくても、数十回の反復では累積的な遅延がユーザー体験を損なう。また、LLMのコンテキストを節約するため、ツールはsubcommandの写像ではなく、ユースケース単位で抽象化すべきだ。自作ツールであれば、迷わずライブラリ直結を選択すべきである。