はじめに こんにちは、XI本部リーディングエッジテクノロジーセンターの佐藤太一です。 このエントリでは、複数のワークツリーでClaude Codeを並行稼働させる開発環境の作り方を紹介します。 Claude Codeには -w （ --worktree ）というフラグがあり、 git worktreeを使って1つのリポジトリから複数の作業ディレクトリを切り出せます。 これを使うと、あるブランチでClaude Codeに実装を任せている間に、 別のブランチで別の機能を開発するという並行作業ができるのです。 ところが同じアプリケーションを複数同時に起動するには、それぞれポート番号を分ける必要があります。 各ポート番号ごとに動作確認すべきことが違うのですから、混乱しがちになります。 そこで、この記事ではportlessというツールを使って、複数のワークツリーを単一のポートでアクセスできるようにします。 端的に言うと、 claude -w feature-a というコマンドで起動した開発環境に https://feature-a.myapp.localhost:1355 でアクセスできる環境を作ります。 はじめに 完成イメージ DevContainerのセットアップ .devcontainer/devcontainer.json .devcontainer/postCreateCommand.sh 最小限のWebアプリケーション package.json src/index.ts git リポジトリとして初期化 portless で単一ポート・複数サブドメインルーティング portless を使ってサーバを起動する Claude Code 用の環境を整える .claude/hooks/session-init.sh .claude/settings.json statusline にホストURLを表示する .claude/statusline.sh まとめ 完成イメージ 最終的にできあがる環境は以下のようなものになります。 DevContainer ├── portless proxy (:1355) │ ├── myapp.localhost:1355 → worktree: main │ ├── feature-a.myapp.localhost:1355 → worktree: feature-a │ └── feature-b.myapp.localhost:1355 → worktree: feature-b │ ├── /workspaces/myapp/ (メインリポジトリ) ├── /workspaces/myapp/.worktrees/feature-a/ (worktree) └── /workspaces/myapp/.worktrees/feature-b/ (worktree) portlessが1つのポート（1355）で待ち受けていて、Hostヘッダのサブドメインを見て対応するworktreeのdevサーバーに振り分けます。 DevContainerのセットアップ この記事では再現可能な開発環境としてDevContainerを使います。事前にvscodeをインストールしておいてください。 .devcontainer/devcontainer.json WORKSPACE_FOLDER という環境変数は、コンテナ内においてコマンドを実行すべきパスを確定するために定義しています。 PORTLESS_HTTPS を 1 に設定すると、portlessが常にHTTPSモードで動作します。 portlessは自前でCA証明書とサーバー証明書を自動生成するので、mkcertなどの外部ツールは不要です。 PORTLESS_STATE_DIR でportlessの状態ディレクトリを明示的に指定しています。 加えて、いくつかの名前付きボリュームを設定しています。 claude-config-dir は複数回のコンテナ作成をまたがってClaude Codeの設定を永続化するために使っています。 portless はportlessの状態ディレクトリを永続化するためのボリュームです。 ここにCA証明書やルーティング情報が格納されます。 npm-cache と myapp-node_modules も同じように永続化されるものですが、どちらかというとパフォーマンス改善とトラブル回避のために設定しています。 最後に forwardPorts でportlessが使うポート1355番を設定しています。 portlessを使わずに動作確認をするためのポートとして3000番を使います。 portlessが動くようになったら削除してください。 { " name ": " myapp ", " image ": " mcr.microsoft.com/devcontainers/base:ubuntu ", " features ": { " ghcr.io/devcontainers/features/node:1 ": {} } , " postCreateCommand ": " /bin/bash .devcontainer/postCreateCommand.sh ", " waitFor ": " postCreateCommand ", " containerEnv ": { " WORKSPACE_FOLDER ": " ${containerWorkspaceFolder} ", " PORTLESS_HTTPS ": " 1 ", " PORTLESS_STATE_DIR ": " /home/vscode/.portless " } , " mounts ": [ { " type ": " volume ", " source ": " portless ", " target ": " /home/vscode/.portless " } , { " type ": " volume ", " source ": " claude-config-dir ", " target ": " /home/vscode/.claude " } , { " type ": " volume ", " source ": " npm-cache ", " target ": " /home/vscode/.npm " } , { " type ": " volume ", " source ": " myapp-node_modules ", " target ": " ${containerWorkspaceFolder}/node_modules " } ] , " forwardPorts ": [ 1355 , 3000 ] } .devcontainer/postCreateCommand.sh コンテナ作成後に実行される初期化スクリプトです。 ここでは、名前付きボリュームの権限を調整しつつ、jqとClaude CLIのインストールを行っています。 Node.jsは devcontainer.json の features で追加しているため、このスクリプトでのインストールは不要です。 #!/bin/bash set -eu sudo apt-get update sudo apt-get install -y jq # ボリュームの権限を修正 sudo chown -R "$(id -gn):$(whoami)" /home/vscode sudo chown -R "$(id -gn):$(whoami)" "${WORKSPACE_FOLDER}/node_modules" # git safe directory git config --global --add safe.directory "$WORKSPACE_FOLDER" # Claude CLI curl -fsSL https://claude.ai/install.sh | bash 最小限のWebアプリケーション ここからは、動作確認用として node:http だけの最小限のWebアプリケーションを用意します。 package.json { " name ": " myapp ", " type ": " module " } src/index.ts ここで実行するサンプルのアプリケーションでは、環境変数として渡された PORT を使ってHTTPサーバをホストします。 import { createServer } from "node:http" ; const port = process .env.PORT ? Number ( process .env.PORT) : 3000 ; const server = createServer(( req , res ) => { res.writeHead( 200 , { "content-type" : "text/plain" } ); res.end( `Hello from ${ port } ` ); } ); server.listen(port, () => { console .log( `Server running at http://localhost: ${ port } ` ); } ); node ./src/index.ts でサーバを起動した後、 http://localhost:3000 にアクセスすれば応答が得られます。 git リポジトリとして初期化 いくつかリソースを作成したので、git リポジトリとして初期化してきます。 まず、 .gitignore には以下を追加しておきましょう。 .claude/worktrees node_modules/ .portless/ 次はリポジトリを初期化して、最初のコミットを作ります。 git init git add .gitignore .devcontainer package.json src/ git commit -m "initial commit" portless で単一ポート・複数サブドメインルーティング portless はローカル開発用のリバースプロキシです。 portless を使ってサーバを起動する では、アプリケーションをportless経由で起動できるようにスクリプトを追加しましょう。 { " name ": " myapp ", " type ": " module ", " scripts ": { " dev ": " npx portless run node ./src/index.ts " } } portless run を実行すると、portlessは以下のことを行います。 プロキシが未起動なら自動でバックグラウンド起動する CA証明書がなければ、PORTLESS_STATE_DIR に証明書を生成する package.json の name からサブドメイン名を推論する git worktreeを検知したらブランチ名をプレフィックスに付与する 空いているポートを見つけて $PORT 環境変数に設定する 指定されたコマンドをそのポートで起動する サブドメインからアプリケーションへのルーティングを登録する まずはメインリポジトリでサーバを起動してみましょう。 # メインリポジトリ npm run dev 初回は証明書のエラーが出力されます。 Starting proxy... Ensuring TLS certificates... Adding CA to system trust store... Could not add CA to system trust store. Permission denied. Try: sudo portless trust これは、SSL証明書をOSに登録できるのはrootユーザのみだからです。 以下のコマンドでコンテナ内のOSに証明書を登録します。 sudo env PATH="$PATH" npx portless trust ホストOSのブラウザでもHTTPS警告が出ないように、CA証明書をホストOS側にインストールしましょう。 portlessの状態ディレクトリは名前付きボリューム上にあるので、ワークスペースにコピーします。 cp -r ~/.portless . ホストOSでもMacやLinuxなら以下のコマンドを実行してください。 PORTLESS_STATE_DIR=".portless" npx portless trust Windowsなら、PowerShellを管理者権限で起動して以下のコマンドを実行します。 $env:PORTLESS_STATE_DIR = "$($PWD.Path)\.portless" npx portless trust Windows では、証明書をインストールする際に確認ダイアログが出力されます。 気を取り直して、もう一度サーバを起動するコマンドを実行します。 その後、ブラウザで https://myapp.localhost:1355 にアクセスしてみましょう。 次は、ワークツリーを作成してから、そのディレクトリ内でサーバを起動するコマンドを実行しています。 もし、まだgitリポジトリになっていないようなら、 git init で初期化してください。 # linked worktree（ブランチ feature-a） git worktree add .worktrees/feature-a cd .worktrees/feature-a npm run dev # → https://feature-a.myapp.localhost:1355 サーバが起動したら、ブラウザで https://feature-a.myapp.localhost:1355 にアクセスしてみましょう。 ホスト側のブラウザからアクセスするポート番号は同じままですが、画面に表示されるポート番号は新しいものに変わっているはずです。 Claude Code 用の環境を整える まずは、 claude コマンドを実行して、テーマの設定やログインを実施しておいてください。 Claude Codeにはhooksという仕組みがあり、 特定のイベントが発生したときにシェルスクリプトを実行できます。 今回は SessionStart フックを使います。 これは、Claude Codeのセッションが開始されるときに実行されます。 .claude/hooks/session-init.sh このフックの役割は、セッション内で必要になる資源を整えることです。 今回は説明を簡易化するために npm install だけを実施しています。 例えば、.envrc を作成したり、DBの初期データを投入すると便利ですよ。 #!/bin/bash set -eu cd "${CLAUDE_PROJECT_DIR:-$(pwd)}" npm install >&2 .claude/settings.json フックの登録はsettings.jsonで行います。 { " hooks ": { " SessionStart ": [ { " hooks ": [ { " type ": " command ", " command ": " bash \" $CLAUDE_PROJECT_DIR \" /.claude/hooks/session-init.sh " } ] } ] } } claude -w を実行してワークツリーが作成されるか確認してください。 statusline にホストURLを表示する 最後の仕上げとして、Claude Codeのプロンプト下部に常時表示される情報行を追加します。 現在のworktreeに対応するURLを常時表示しておくと、セッションと紐づくサーバがすぐに分かるので便利です。 .claude/statusline.sh #!/bin/bash input=$(cat) _url=$(NO_COLOR=1 npx --yes portless get myapp 2>/dev/null) [ -z "$_url" ] && exit 0 _routes="${PORTLESS_STATE_DIR:-$HOME/.portless}/routes.json" _host=$(echo "$_url" | sed 's|.*://||; s|:.*||') if [ -f "$_routes" ] \ && jq -e --arg h "$_host" \ 'any(.[]; .hostname == $h)' "$_routes" \ > /dev/null 2>&1; then printf '\033[38;5;75m%s\033[0m' "$_url" # blue else printf '\033[38;5;245m%s\033[0m' "$_url" # gray fi printf '\n' サーバが停止中ならグレー、起動中なら青色で表示されるようにしてみました。 これを組み込んだ後の settings.json です。 { " hooks ": { " SessionStart ": [ { " type ": " command ", " command ": " bash \" $CLAUDE_PROJECT_DIR \" /.claude/hooks/session-init.sh " } ] } , " statusLine ": { " type ": " command ", " command ": " bash \" $CLAUDE_PROJECT_DIR \" /.claude/statusline.sh ", " padding ": 0 } } Claudeのセッション中に !npm run dev とすることでサーバを起動できます。 まとめ この記事では、Claude Codeのworktreeを使った並行開発を快適にするための環境を構築しました。 構成要素をまとめると以下のとおりです。 コンポーネント 役割 DevContainer 再現可能な開発環境 claude -w worktreeの作成と自動初期化 portless 単一ポートのリバースプロキシ statusline 現在のworktreeのURLを常時表示 この構成では、 claude -w feature-a とセッションを開始すると、 https://feature-a.myapp.localhost:1355 でアクセスできます。 引数を渡さなければランダムなワークツリー名が付与されますが、portlessが適切なホスト名になるよう丸めてくれます。 また、statuslineにURLを表示しているので、もう迷うこともありません。 実際の開発では、ここに認証サーバやS3モックなどのサービスを追加していくことになるでしょう。 基本的な部分は実現できているので、追加のサーバ導入はAIがうまくやってくれますので、お任せしていきましょう。 執筆： @sato.taichi レビュー： @handa.kenta （ Shodo で執筆されました ）

こんにちは。AI LabチームのHan Kil Roです。サービスに必要なAIモデルやソリューションを開発するチームで業務に携わっています。最近、LINEヤフー社内で実施された Orchestrati...

本記事は「 From copilots to coworkers at AAAI: the gap between agentic research and production 」を翻訳したものです。 2026 年 1 月 27 日 AAAI 2026 パネルディスカッション「From Copilots to Co-Workers: What Changes When AI Writes, Reads, and Reasons About Code?」に基づく — シンガポール AAAI 2026 の協調型 AI エージェントに関するワークショップで、Microsoft、Mistral、シンガポール国立大学（NUS）、LinkedIn、Amazon Web Services（AWS）の研究者と実務者がパネルに集まり、コーディングエージェントを本番環境に投入した際に実際に何が起こるかについて意見を交わしました。議論の焦点は「うまくいくかどうか」ではなく（その議論はすでに決着済みです）、「何が壊れるのか、何が予想外なのか、そしてその過程で何を再構築しなければならないのか」でした。 パネリスト ： Shengyu Fu — Microsoft CoreAI、Partner Applied Science Manager。GitHub Copilot 全般にわたるイノベーションを推進する AI for Code 応用研究チームを率い、補完機能からコーディングエージェントまで幅広くイノベーションを推進。 Abhik Roychoudhury — シンガポール国立大学コンピュータサイエンス学部 Provost’s Chair Professor。ACM フェロー、ACM TOSEM 編集長。信頼性とセキュリティを重視したソフトウェアエンジニアリンググループを率い、セマンティックプログラム修復、仕様推論、ファズテスト、AutoCodeRover などの研究に貢献。 Baptiste Rozière — Mistral AI のコード生成チームを率いる。以前は Meta AI に在籍し、Llama に貢献、Code Llama を主導。 Alborz Geramifard — LinkedIn、Distinguished Scientist Omer Tripp — AWS、Principal Applied Scientist 研究と本番環境のギャップ 現在の研究は主に能力の最適化に注力していますが、本番環境では信頼性、コスト、レイテンシー、信頼、そして組織への適合性を同時に最適化する必要があります。 ソフトウェア開発向け AI には、おなじみのパターンがあります。論文がベンチマークで印象的な結果を示す。チームがそれを製品化しようとする。そして本当の仕事が始まります。それはモデルに関する作業ではなく、モデルの周辺にあるすべてのものに関する作業です。どのモデルをいつ呼び出すかを決定するオーケストレーション層、大規模な推論を経済的に維持するコスト設計、開発者が待つか離脱するかを左右するレイテンシー予算、エージェントが実際に役立っているのかそれともそれらしいノイズを生成しているだけなのかを判断する評価フレームワーク、そして誰かがエージェントに実際の仕事を委任するかどうかを決定するトラストサーフェス（説明、監査証跡、中断ポイント）です。 パネリストたちは繰り返し、さまざまな角度から、コーディングエージェントのデプロイにおける課題は、ラボで構築する際の課題とは根本的に異なることを指摘しました。研究は能力を最適化します。本番環境は信頼性、コスト、レイテンシー、信頼、組織への適合性を同時に最適化します。そしてこのギャップは単一の問題ではありません。それぞれが独自の苦労から得た教訓を持つ、いくつかの異なるレベルで現れます。 ギャップが現れる場所 ゼロからの構築：最新の研究を取り入れながら迅速にリリースする 最初の課題はアーキテクチャに関するものです。モデルの能力が限られていた頃、チャットは自然なインタラクションモデルでした。Shengyu Fu（Microsoft）は、VS Code が Copilot にチャット機能を搭載した際、システムが完成したと思い込みがちだったと述べました。プロンプティングがすべてだと感じられたのです。しかし、その幻想はより高性能なモデルの登場とともに崩れます。推論能力とツール使用が向上するにつれ、エージェントはマルチステップのアクションを実行し、自律的にツールを呼び出し、自己検証を行うようになりました。課題はプロンプトエンジニアリングからオーケストレーション、システム設計、評価へと移行しました。これを早期に認識しなかったチームは、後になって手戻りという代償を払うことになりました。 この現代的なエージェントパラダイムでは、アーキテクチャの専門化が有効です。例えば、GitHub Copilot はコード検索などのタスクに専用のサブエージェントを使用し、高価な推論モデルは本当に必要な場面に限定しています。しかし、この専門化には独自の問題が伴います。エージェント間のハンドオフのたびにレイテンシーが増加し、コンテキストが複数のステージを通過するにつれて情報が劣化します。数千万行規模のコードベースでは、コスト削減にはより安価なモデルへの単純な置き換えではなく、システムレベルの設計が必要です。 ユーザーがレイテンシーをどう認識するかも変化しました。2025 年にはスピードが品質の代理指標でした。2026 年までに、ユーザーは複雑なプロンプトに対するより高い自律性とより包括的なソリューションと引き換えに、より長い待ち時間を受け入れるようになりました。基準は「素早く応答する」から「自分がやらなくて済むようにもっと多くを処理する」へと移りました。Abhik Roychoudhury（NUS）は、初期のエージェントチーム（自身のチームを含む）がプログラム解析技術を用いて推論コストの最適化に注力していたと述べました。多くの人を驚かせたのは、組織の準備態勢がコストを上回る制約要因として急速に浮上したことです。3 年前の International Conference of Software Engineering（ICSE）では、多くの企業が LLM を自社のコードに触れさせることは絶対にないと断言していました。しかし、開発者が生産性の向上を実感すると、その姿勢は一変しました。コストよりも意欲が重要であり、適切な足場があれば、より高い品質をより低いコストで実現できると Abhik は付け加えました。 主なポイント：研究は能力を提供しますが、本番環境ではコスト、レイテンシー、品質のバランスを取るアーキテクチャが求められます。そして、そのアーキテクチャこそが実際のエンジニアリングの大部分を占める場所です。 学習と評価：エージェントをより自律的にする ギャップの 2 つ目のレベルは、エージェントが実際に優れているかどうかを知り、時間とともに改善していくことに関するものです。 強化学習は自然な選択だが、アルゴリズムの壁よりもインフラの壁に先にぶつかる。 強化学習は、環境内でアクションを実行するコーディングエージェントの訓練に最適なアプローチであるはずです。しかし実際には、最も困難な問題はエンジニアリングの問題です。Alborz は、エージェントの訓練を完全に強化学習駆動の問題として扱った LinkedIn の経験を述べました。GPU/CPU の利用率がシステム上の課題となりました。ビルドと実行は CPU 負荷が高く、GPU 中心の訓練クラスターとの不均衡が生じます。モデルの並列訓練中にトラジェクトリを収集することで、調整の複雑さが増しました。単純な報酬シグナルは報酬ハッキングを招きました。エージェントは成功したように見せるためにテストを削除することを学習したのです。 さらに、スケーリングを実現するために、LinkedIn は各ポッドをクリーンな状態の仮想マシンとして使用しました。各ステップで完全な git チェックアウトを行う初期設計ではシステムが飽和しました。キャッシュと厳格なアーティファクト管理が不可欠になりました。大規模運用では、約 800 の問題をそれぞれ複数回実行し、オンラインでトラジェクトリを生成しました。Shengyu も Microsoft での同様の経験を述べました。エージェント型強化学習は、長いトラジェクトリと繰り返しのモデル呼び出しにより、補完のための強化学習よりもはるかに困難です。Baptiste も、Mistral で同じパターンが見られたことを確認しました。強化学習環境は事前学習クラスターよりもはるかに多くの CPU を必要とします。 3 つの組織すべてのコンセンサスは次のとおりです。スケーラブルな強化学習環境は、エージェント型 AI に欠けているインフラ層です。現時点では、これはアルゴリズムのフロンティアではなく、エンジニアリング上の制約です。 評価ベンチマークは飽和し、現実から乖離している。 SWE-Bench は 2025 年に評価の主流でしたが、2026 年までに開発者が実際にエージェントを使用する方法と構造的に乖離するようになりました。Alborz は、ベンチマークは通常単一のリポジトリで動作するが、実際の作業は複数のリポジトリにまたがると指摘しました。Abhik は、ほとんどのベンチマークがコードの記述を測定する一方で、コードの読解、意図の理解、影響の分析も同様に重要でありながらほとんど測定されていないと強調しました。Baptiste は、正確性だけではエージェントを差別化できず、指示への追従性と汎化能力が少なくとも同程度に重要だと付け加えました。Omer は、実験室の設定ではなく本番環境の条件に最適化すべきだと主張しました。各企業はプロプライエタリなコードで内部ベンチマークを構築していますが、エージェント評価の共有基準はまだ存在せず、GitHub Copilot のようなデプロイ済みシステムでは、エージェント型ワークロードにはまだクリーンな定量的シグナルがありません。 主なポイント：評価と訓練インフラが 2 つの欠けている層です。ベンチマークは単一リポジトリの正確性を超えて、コード読解、マルチリポジトリワークフロー、指示への追従性を捉える必要があります。スケーラブルな強化学習環境は欠けている訓練層であり、試みたすべてのチームがアルゴリズムの壁ではなく同じエンジニアリングの壁にぶつかっています。 エージェントは単独で動作しない：人間とエージェント間インタラクションの役割 3 つ目のレベルは、エージェントの周辺で何が起こるか、つまり人間がエージェントとどのようにインタラクションし、信頼がどのように構築され、人間の役割がどう変化するかについてです。 レイテンシーと監査可能性が製品を定義する。 Omer は 2 種類のレイテンシーを明確に区別しました。オートコンプリートのレイテンシー（入力中に AI が次の行を提案する際の遅延）は、既存のフローに収まるため、合理的な範囲内であれば許容されます。委任のレイテンシーは根本的に異なります。エージェントにタスク全体を渡し、複数のステップにわたって自律的に作業させる場合、もはやエージェントと並行して入力しているのではなく、ただ待っているだけです。その待ち時間は直ちに監査可能性と結びつきます。ユーザーはエージェントが何をしているのか、行き詰まっていないか、中断できるかを知りたがります。これらの問いが、システムが信頼できると感じられるか不透明に感じられるかを決定します。 品質は正確性だけではない。 Abhik は、あまり注目されていない 2 つの次元で品質を再定義しました。第一に、シグナル対ノイズ比：エージェントは開発者の注意を妨げていないか、それともフィルタリングに労力を要するノイズを生成しているか？10 個の提案のうち 1 つしか有用でないエージェントは、各提案が技術的に正しくても、隠れたコストが発生しています。第二に、説明可能性：エージェントは予想外の判断を正当化できるか？推論が読み取れるものであれば、驚くべき振る舞いも許容されます。この枠組みでは、品質は信頼は切り離せません。 検証は実用的な中間地点に落ち着く。 形式検証はほとんどのシステムにとってまだ手の届かないものです。パネルは実用的な代替案に収束しました。仕様駆動開発（生成されたコードから仕様を抽出し、人間が実装を再確認する必要をなくす）、プロパティベーステスト（モデルはこれらの生成に適しており、実行可能な説明として機能する）、そして AI 支援コードレビュー（AI で AI をガードレールし、人間がビジネスロジックに集中できるようにする）です。 人間の役割は変化しているが、消滅してはいない。 聴衆からの質問が、よくある不安を捉えていました。エージェントがコードの大部分を書くようになったとき、ジュニア開発者はどのように成長すべきか？新たに求められるスキルセットは以下を中心としています。コードの読解とレビュー（書くことよりも重要）、委任（何を自動化し、何に人間の判断が必要かを見極める）、テストと検証（開発者の役割の中心に移行）、そして曖昧さの解消（仕様が不完全な場合に人間が接着剤の役割を果たし続ける）。NUS はすでにこれらの原則に基づいたカリキュラムを構築しています。Alborz の言葉を借りれば、もし自分が学生なら、曖昧さの解消に全力を注ぐだろう、と。そのスキルは抽象化が変わっても価値を持ち続けます。 主なポイント：信頼こそが製品であり、それは監査可能性、シグナル対ノイズの規律、説明可能性によって構築されます。人間の役割は、コードを書くことから、判断し、委任し、エージェントにはできないことを解決することへと移行します。 チームがこれらの課題にどう取り組んでいるかの事例 パネルは純粋に理論的なものではありませんでした。研究と本番環境のギャップを埋めるために、チームがどのように取り組んでいるかについて、いくつかの具体的な事例が紹介されました。 GitHub Copilot のアーキテクチャ専門化。 すべてを 1 つの高価なモデルに通すのではなく、Copilot はコード検索などのタスクに専用のサブエージェントを使用し、強力な推論モデルは複雑な問題に限定しています。これにより、モデルの置き換えではなくシステム設計を通じて、より高い品質をより低いコストで実現しています。 LinkedIn の強化学習インフラ。 大規模な強化学習によるエージェント訓練のために、LinkedIn は各ポッドをクリーンな状態の VM として使用し、積極的なキャッシュとアーティファクト管理を備えた環境を構築しました。各ステップで完全な git チェックアウトを行う初期設計ではスケールできませんでした。最終的なシステムは約 800 の問題でオンラインのトラジェクトリ生成を実行しました。これはアルゴリズムの改善に先立つ、大規模なインフラ投資でした。 Mistral のコンピュートリバランス。 Baptiste のチームは、コードエージェント向けの強化学習環境が事前学習クラスターの設計想定をはるかに超える CPU を必要とすることを発見しました。これをアルゴリズムの問題ではなくインフラの問題として認識したことが、重要な洞察でした。 NUS のカリキュラム再設計。 Abhik のチームは、新しい現実を反映したカリキュラムを構築しています。コード読解をコアスキルとして、エージェントへの委任をコンピテンシーとして、テストを中心に据え、責任ある AI エージェントの使用を必須としています。 ジャッジキャリブレーションのためのペアワイズ比較。 Alborz は、「このコードはあのコードより優れている」というスタイルのデータセット構築を提案しました。作成コストが比較的低く、絶対的な校正が困難な場合でも、ジャッジが信頼性の高い相対ランキングを学習するのに十分です。 AI が AI をレビューする。 Microsoft の Shengyu のチームは、AI 支援コードレビューに取り組む先駆者の一つです。コードレビューエージェントが仕様、要約、意図された動作、テストを使用して一貫性をチェックします。目標は、人間がビジネスロジックに集中し、AI が構造的な検証を担当することです。 現在注目していること：今後の研究の方向性 パネルでは、活発に取り組まれているものの解決にはほど遠い、いくつかのテーマが浮上しました。 スケーラブルな強化学習環境。 これは最も強いコンセンサスポイントでした。エージェント型コーディングに RL を試みたすべてのチームが、同じインフラの壁にぶつかっています。複数のリポジトリ、実際のビルドシステム、現実的な実行環境など、現実世界の多様性を反映した環境を強化学習訓練に必要なスケールで構築することが、欠けている層です。 メタ評価：ジャッジを評価する。 AI ジャッジがコード変更にスコアを付ける場合、そのスコアが信頼できるとどうやって分かるのでしょうか？説明が信頼の次の層として提案されています。システムは信頼性の高いスコアと高品質なコメントの両方を生成し、信頼度の閾値を超えた場合の自動李r−すを実現可能にすべきです。しかし、その信頼性を確立することこそが困難な部分です。 生成されたコードからの仕様抽出。 長期的な目標は、生成されたコードから直接意図を復元し、人間が実装を再確認する必要をなくすことです。これは仕様駆動開発を影響分析（変更がコードベース全体にどのように伝播するかの理解）と結びつけます。 修復ではなく再生成。 コードを安価に再生成できるなら、なぜメンテナンスするのか？これはソフトウェアの寿命、後方互換性、技術的負債についての考え方に深い影響を与える挑戦的なアイデアです。 共有評価基準。 各企業はプロプライエタリなコードで内部ベンチマークを構築していますが、コミュニティにはエージェント型システムを評価するための共有基準がありません。公開ベンチマークは飽和しており、それに代わるものは指示への追従性、汎化能力、コード読解、マルチリポジトリワークフローを捉える必要があります。 カスタマイズ可能なジャッジ。 コードレビューにおいて、組織ごとに重視する点は異なります。重大度、スタイル、順序、見た目の問題など。画一的なジャッジは大規模には機能しません。今後の道筋は、組織のコンテキストに合わせて調整可能なジャッジを必要とします。