BashをSwiftに置き換える：AIツールチェーンの進化

先日、ある開発者が個人のAIエージェントフレームワーク（AI Harness）で興味深い実験を行った。それは、ツール実行エンジンとしてBashスクリプトをSwift言語に置き換えるというものだ。このアイデアは、TypeScriptがエージェントプログラミング言語の主流になることへの不満と、Swiftの可能性への確信に基づいている。

以前、このフレームワークではファイルツールボックスをBashに置き換え、システムとの対話を簡素化していた。今回はさらに一歩進め、モデルにシェルスクリプトではなくSwiftコードを直接書かせることを目指した。

最も単純な実装は、フレームワークをそのままにしてBashツールをSwiftツールに置き換え、モデルがトップレベルのSwiftコードを書き、コンパイラを呼び出して実行するというものだ。しかし、この方法には明らかな欠点がある。毎回コンパイラを起動するため速度が遅く、Bashと同様のセキュリティ問題が残る。また、コンパイルプロセスはモジュールキャッシュなどの複雑な動作を伴い、軽量ではない。

そこで作者は別の選択肢を取った——SwiftScriptの使用だ。これはツリーウォーキング（tree-walking）方式のSwiftインタプリタで、ライブラリとしてアプリケーションに埋め込むことができ、コンパイルステップが不要である。これをフレームワークに組み込むことで、Swiftツールはサブプロセスではなくフレームワーク自身の一部となる。

実行環境を制御するために、作者は別のライブラリShellKitも導入した。ShellKitは、埋め込み側がカスタムの入出力、作業ディレクトリ、サンドボックス戦略を定義できるようにする。Swiftコードの実行時、インタプリタの出力はShellKitのブリッジを介してカスタムのstdout/stderrにルーティングされ、ファイル操作は指定されたディレクトリ内に制限され、.gitなどの機密ファイルにはアクセスできない。

この設計はBashよりも安全だ。実行モデルが「シェルを提供して自由に実行させる」から「ホストするインタプリタを提供し、公開するランタイムコンテキストを選択する」へと変わったからだ。フレームワークはモデルが何をできるかを細かく制御でき、例えばワークスペース、ユーザーレベルのスキルディレクトリ、一時ディレクトリのみの読み書きを許可し、ネットワークリクエストは許可するが、.gitや任意のシステムパスへのアクセスは禁止する。

もちろん、これはセキュリティリスクを完全に排除するものではない。ShellKitのサンドボックスはプロセス内のポリシーレイヤーであり、OSによって強制されるものではない。作者はインタプリタを独立したプロセスに入れ、Seatbeltでラップすることも検討したが、学習用フレームワークとしてシンプルさを保つため、現時点では採用していない。

実際のテストでは、このアプローチは良好に機能した。モデルはSwiftツールを呼び出して計算を実行し、ファイルを読み取り、ディレクトリ内容を表示できる。例えば、print(40 + 2)を実行すると42が出力され、Foundationフレームワークを使用してワークスペースのファイル情報を取得できる。サンドボックスからの脱出を試みると（例：../escape.txtへの書き込み）、「file URL is outside the Swift tool sandbox」というエラーが返され、期待通りの動作を示した。

SwiftScriptは個人開発のインタプリタであり、一部のAPIはまだ完全ではないが、概念実証としては十分である。重要なのは、すべてのSwift APIをサポートすることではなく、Swiftを使用した「単一ツール」実験が現実的に機能することを示したことだ。作者は、この実験が完璧な答えではないが、Swiftの利点と欠点、サンドボックス問題の現状を正直に示していると結論付けている。