出発点

SNA の出発点は単純でした。Claude Code と Codex を行き来して作業する うちに、使える成果が別々のツール、セッション、インターフェースに散らばる ようになりました。作業そのものは移せても、その周辺の文脈は一緒には 移りません。そこで、コーディングエージェントを切り替えても流れが途切れない 層が必要になりました。

各コーディングエージェントには、CLI としてすでに強みがあります。ですが、 すべてのワークフローで CLI が最適なインターフェースとは限りません。 より良い連続性、可視性、制御を持つ独自の GUI が必要な場面がありました。

きっかけは VS Code の Claude Code 拡張機能でした。見た目は Claude Code ですが、ターミナル内の CLI そのものではありません。「CLI ではないのに、 どう接続しているのか」という疑問から、Claude Code のオプションや ランタイム表面を調べ始めました。その過程で、Claude Code をプログラムから 統合でき、Codex も同じアプリ層の背後に置けることが分かりました。

名前を残した理由

Skills-Native Application という名前は、もっと初期の構想から来ています。 当初の SNA は、Skills をランタイムとして扱うバックエンド基盤でした。 アプリは xterm を開き、ユーザーが UI をクリックすると、そのターミナルに スキルコマンドが入力される形でした。

そのモデルは少しずつ変わりました。UI 上の制約からターミナルを画面上では 隠すようになり、最終的にはターミナル自体を立ち上げないヘッドレス制御へ 移りました。現在の SNA は、エージェントランタイムを直接制御し、構造化 された状態をアプリへストリーミングします。

そのため、"Skills-Native" は今の実装を文字どおり表す名前ではありません。 それでも名前を変えなかったのは、出発点を残すためです。SNA はもともと、 スキルを別のターミナルワークフローではなく、アプリ内の自然な機能として 扱えるようにする試みから始まりました。

SNA はその観察から始まりました。ネイティブなコーディングエージェントは それぞれの強みを保つべきですが、連続性はアプリが所有すべきです。セッション、 履歴、権限、UI、ランタイム切り替えが別々のツールに散ったままでは、 プロダクトになりません。