ほとんどのAI用コーディングツールはハーネス:モデルを囲むループに加え、ファイルの読み書きやコマンド実行用のツールです。Claude Code、Codex、OpenCode、Piなどがすべてハーネスであり、これらはターミナルで作業する開発者向けに構築されています。
Coroidはそれらのいずれも使用しません。独自のランタイムを実行します。
なぜ既存のツールをラップしないのでしょうか?
上記のツールは対面セッションを前提に設計されています。誰かが監視し、質問に答え、中断し、エラーに気づくのです。この前提は妥当であり、エラーの表示方式、保持されるコンテキスト量、モデルが予期しない出力を返した際の挙動など、すべてを左右します。
Coroidの前提は逆です:誰も監視していません。作業はスケジュールやモニター、イベントによってクラウドで開始され、誰かが途中で介入することなく、レビュー可能な結果または明確な失敗に到達する必要があります。
これらは異なる課題です。以下に挙げるいくつかの仕組みは、この違いがあるからこそ存在し、ターミナルセッションでは意味をなしません。
ランタイムが行う違い
**単独で動作することを想定しています。**モデルが形式不適合な応答や不正なツール呼び出しを返した場合、誰も答えることができないプロンプトを表示するのではなく、ループが修復して再試行します。質問を求めて停止する無人実行は、無駄なリソース消費に他なりません。
**構造的にマルチエージェントです。**このループは「ロール」間の引き継ぎを基盤として構築されており、異なる権限が設定されています。コードを記述したエージェントとは別のエージェントが検証を実施します。これは丁寧に依頼するのではなく、アーキテクチャ自体がもたらす特性です。
**明確な予算と深さの制限があります。**各実行はトークン予算とステップ数の上限に従って実行されます。これらがなければ、タスクを誤解した無人エージェントが延々と作業を続けてしまいます。
**ガバナンスが組み込まれています。**ポリシー、品質ゲート、承認チェックポイントは実行パスに組み込まれており、ラップされるのではありません。そのため、ブロッキングゲートは事後ではなく実行中に作業を停止させることが可能です。
キャッシュ処理が重要な要素です
コンテキストはエージェント実行コストの大部分を占め、クラウドハーネスでは同じプロジェクトのコンテキストが複数のタスクで繰り返し読み込まれます。
そのため、ランタイムはプロンプトキャッシュを多用します。これが機能している様子はタスクの「実行履歴」で確認でき、各ステップがキャッシュ効率を報告します:
9.1k used (90% cached)高いキャッシュヒット率は、高コストな実行と低コストな実行の違いです。構造が整ったプロジェクトの方がコンテキストは作業コストが低く抑えられます。安定したコンテキストはキャッシュされやすく、毎回変化するコンテキストはそうではありません。
これは「段階的スキル」と相まって、初期段階で読み込まれるコンテキストを小さく保ちます。
実用的なメリット
- **ローカルでのセットアップは不要です。**CLIもエディタプラグインも、ホスト用のランナーも不要です。CoroidはAPIベースでクラウド上で実行されます。
- **サードパーティ製ツールのサブスクリプションも不要です。**Coroid上でコーディングアシスタントのライセンスを購入する必要はありません。モデル利用料は クレジットまたは ご自身のプロバイダーキー.
- **作業は無人で実行されます。**スケジュール、Sentinelおよび フックが利用可能です。開発者のマシンが起動していることを前提としないからです。
- **動作が一貫しています。**全員の作業は同じランタイムと同じポリシーに従って実行され、各開発者がインストール・設定した内容に依存しません。インストールされる内容は「 言語サポートとエージェント環境.
変わらない点
ハーネスは作業の実行方法を決定しますが、境界は変わりません。すべての成果物は引き続きブランチ上のpull requestとして生成され、自動でマージされることはなく、ブランチ保護やレビュールールは人間の貢献者と同様に適用されます。