AI生成コードを動かす実行基盤「Daytona」がGitHubで72,371スターに到達し、リポジトリ全体をLLMに食わせるための圧縮ツール「Repomix」も24,294スターを記録した。両者はAIエージェント開発の上流（コンテキスト投入）と下流（コード実行）を担うインフラであり、2026年の開発スタックの輪郭がここに見えてきた。

何が起きたか

GitHubのトレンドで、AIインフラ系の2リポジトリが同時に存在感を増している。

ひとつは daytonaio/daytona で、スター数は72,371。同プロジェクトは自らを "Secure and Elastic Infrastructure for Running AI-Generated Code" と定義しており、AIが生成したコードを隔離されたサンドボックスで実行するための基盤を提供する。OpenAIのCode Interpreter、AnthropicのClaude Codeが内部的に持つような「使い捨て実行環境」を、自前のエージェント開発で組み込めるOSSとして整備したものだ。

もうひとつは yamadashy/repomix で、24,294スター。リポジトリ全体を1ファイルにパックし、Claude / GPT / Gemini といったLLMに丸ごと食わせやすい形に整形する。npx repomix 一発で repomix-output.xml（既定はXML形式）が吐かれ、トークン数の概算、.gitignore 準拠の除外、シークレット検出（Secretlint連携）まで面倒を見る。

なぜこのニュースが重要か

AIコーディングの主役は、この1年で「補完」から「エージェントによる自律実行」へ完全に移った。Cursor Composer、Claude Code、Devin、OpenAI Codex CLI ── いずれも共通して2つの課題に直面している。

  1. コンテキスト投入の効率化：人間が手でファイルを選ぶのではなく、リポジトリ構造ごとモデルに渡したい
  2. 生成コードの安全実行：エージェントが書いた rm -rf や外部API呼び出しを、ホスト環境から隔離して走らせたい

RepomixとDaytonaは、まさにこの2つに対する事実上の標準解になりつつある。特にDaytonaの72k★という数字は、Dockerが初期にOSSコミュニティで得た熱量を想起させる規模感で、AIエージェント開発の「ランタイム層」がコモディティ化する兆候だ。

エンジニア視点・技術深掘り

Repomixの実装上の勘所

Repomixは内部的に Tree-sitter を用いたコード圧縮モード（--compress）を持ち、関数シグネチャと重要構造のみを抽出してトークン数を大幅削減できる。実務では以下のような使い方が現実的だ。

# Claude向けにXML、圧縮あり、testsを除外
npx repomix --style xml --compress \
  --ignore "**/*.test.ts,**/dist/**" \
  --remove-comments

出力はXML/Markdown/プレーンテキストから選べ、Claudeに渡すならXMLがAnthropicの推奨プロンプト構造に整合する。CI上で差分だけパックして PR レビュー用にLLMへ渡すパイプラインも組みやすく、--include-diffs で Git の未コミット差分も同梱できる。

注意点はトークンコスト。中規模のモノレポを無圧縮で投げると簡単に100k tokens を超え、Claude 3.5/4 系でも入力コストが無視できない。--compress と --top-files-len を併用し、まず構造把握 → 必要ファイルだけ再投入、という二段階フローが堅い。

Daytonaのアーキテクチャ的意味

Daytona は単なる Dev Container マネージャではなく、エージェントが動的に作るサンドボックスをエラスティックにスケールさせる思想で設計されている。SDK（Python / TypeScript）から daytona.create() でサンドボックスを起動し、process.exec() で任意コマンドを走らせ、終了後に破棄する ── E2B や Modal、Anthropic の Computer Use 向け仮想環境と競合するレイヤーだ。

from daytona_sdk import Daytona

daytona = Daytona()
sandbox = daytona.create()
response = sandbox.process.exec("python -c 'print(2+2)'")
print(response.result)  # 4
sandbox.delete()

自前ホスティングできる点が E2B との明確な差別化で、機密データを社外SaaSに流せない金融・医療領域のエージェント開発に刺さる。LangGraph や AutoGen のツール実行バックエンドに据える構成が、今後のリファレンスアーキテクチャになっていくだろう。

組み合わせの威力

実は両者は相補的だ。エージェントワークフローを書くなら:

  1. Repomix でターゲットリポジトリをパック → LLMに投入してパッチを生成
  2. Daytona のサンドボックスに git clone してパッチを適用、テスト実行
  3. 結果をエージェントにフィードバック、失敗ならループ

このループは SWE-bench 系のベンチで上位を取るエージェントが共通して採用している構造で、OSSだけで再現可能になったインパクトは大きい。

経営者・技術リーダーが次に取るべき動き

短期的には、社内のAIコーディング基盤を「IDE拡張任せ」から「自前のエージェントパイプライン」へ移す検討を始めるべきだ。Cursor や GitHub Copilot Workspace は便利だが、社内コードを外部SaaSに送る前提が経営リスクになる業種は多い。Daytona をオンプレ or VPC内に置き、Repomix で社内モノレポを圧縮、LLMだけ Anthropic / OpenAI の API（あるいは社内推論基盤）に切り出す ── という分離構成なら、データ境界を保ったままエージェント運用が可能になる。

中期的には、エージェント実行のコスト構造が「LLM API費用 + サンドボックスCPU時間」の二本立てに変わる。FinOpsの観点で、サンドボックス起動時間と入力トークン数の両方を可視化するメトリクス設計を、いまのうちに仕込んでおきたい。開発生産性の議論が「IDEの機能比較」から「エージェントランタイムの選定」へシフトする転換点に、いま立っている。

動画でも詳しく

動画は記事冒頭の埋め込みからフル尺で視聴できます。

主な出典