idea_world_labDEV JOURNAL
2026年6月17日水曜日

2026-06-17 SWE-agent trajectory キーワードメモ

核心結論

Godot 4 コーディングモデルを作る際、少量の Q&A データセットだけでは不足する可能性が高い。現在抱えている問題は単純な instruction データセットの問題ではなく、リポジトリ単位の長いコンテキストを読み取り、ファイル探索、判断、修正、検証、パッチ生成までを行う software engineering エージェントの学習問題に近い。

整理すると、現在の方向性の名前は次に近い。

Long-context repository-level software engineering agent training

または、より短くは次のキーワードと見ることができる。

SWE-agent trajectory training

Godot 側に置き換えると、目標は単純な Godot Q&A モデルではなく、以下に近いです。

Godot用 SWEエージェント軌道データセット作成

なぜ小さな Q&A だけでは不十分なのか

従来の課題は次のとおりだった。

"マップを作ってください"
-> プロジェクトを読む
-> 関連ファイルを探す
-> アセットを確認
-> Godot 4 の文法/API を判断
-> コードを修正
-> 実行/テスト/検証
-> パッチを生成

この流れは 質問 -> 回答 だけで終わらない。実際のコーディングエージェントは複数のファイルを探索し、中間判断を行い、修正した後に検証まで実施しなければならない。したがって、最終的な回答コードだけを残すデータセットよりも、エージェントが問題を解きながら残した trajectory と patch を学習データとして作成する方向の方が適切かもしれない。

探す優先順位

1. SWE-smith
2. nebius/SWE-agent-trajectories
3. CoderForge-Preview
4. ACC
5. aiXcoder CoLT
6. RepoBench / CrossCodeEval / RepoCoder
7. godot-dodo / wallstoneai dataset

ケースメモ

SWE-agent の軌跡

SWE-agent-trajectories は GitHub のイシューを見てレポジトリのファイルを探索し、必要なファイルを開き、修正し、テストし、最終的なパッチを作成するエージェントの行動記録データセットです。

主要キーワード:

  • エージェントの軌跡
  • GitHub イシュー解決
  • ファイル探索
  • パッチ生成
  • ソフトウェアエンジニアリングエージェントのトレーニング

Godot 側の対応:

"マップを作って"
-> Godot プロジェクト構造の探索
-> 関連シーン/スクリプト/リソースの確認
-> 修正
-> 実行またはスクリーンショットの検証
-> パッチの作成

SWE-smith

SWE-smithは GitHub リポジトリを software engineering エージェント学習用環境に変換するツールキットです。説明上、任意の GitHub リポジトリを SWE-gym 形式に変換し、ファイルローカリゼーション、プログラム修正、SWE-bench スタイルのタスクを作成できます。

Godot 側の対応:

Godot repo
-> マップ/シーン/スクリプト 修正 タスク 作成
-> Godot エージェント 軌道 作成
-> Godot パッチ モデル 学習

SWE-Gym

SWE-Gymは codebase、実行可能ランタイム環境、ユニットテスト、自然言語タスクをまとめて SWE エージェントと検証者を学習させる方向の事例です。

Godot 側の対応:

Godot project
+ 実行可能な Godot バージョン
+ scene/test/screenshot 検証
+ 自然言語 タスク
+ 修正 trajectory
+ patch

重要なのは、コードだけを学習したり自然言語の質問だけを学習したりするのではなく、実行環境と検証までを一緒に束ねるということです。

CoderForge-Preview

CoderForge-Previewはエージェントのトラジェクトリを基にロングコンテキストSFTデータを作成する事例です。最大128Kトークンのロングコンテキストトラジェクトリを使用した点が重要です。

この事例は次の疑問に対する根拠となります。

リポ単位の作業には大きなコンテキストは必要ないのではないでしょうか？

実際のコーディングエージェント学習側でも長いコンテキスト trajectory を使用する流れがあります。

ACC

ACC: Compiling Agent Trajectories for Long-Context Training はエージェント trajectory を long-context QA 形式でコンパイルする方向です。複数ターンにわたる tool call、observation、ファイル内容、検索結果を長い文脈学習データに変換することが核心です。

この事例は次の疑問とつながります。

最終回答コードだけを学習すれば十分ですか？  
それともファイル探索と判断プロセスまでを学習データとして残す必要がありますか？

RepoBench / CrossCodeEval / RepoCoder

この系統はリポジトリ単位のコード理解と完成問題を扱う。

核心的な問題意識:

  • single-file benchmarkだけでは実際のプロジェクトの複雑さを捉えにくい。
  • 有用な情報が複数のファイルに散らばっている。
  • cross-file コンテキストが必要なコード補完を評価する必要がある。
  • retrieval‑generation パイプラインが必要である。

Godot 側の対応:

ファイルだけ見てはマップの修正が難しい。  
scene、script、resource、project の設定、アセットのパスを一緒に見る必要がある。

aiXcoder CoLT

aiXcoder-7B-v2とCoLTは、長いコンテキストを与えてもモデルが有用な情報を無視できるという問題に取り組んでいます。

重要な疑問:

コンテキストを大きく入れればよいのか？
→ いいえ。
大きく入れてもモデルが実際に読み取り活用しているかを学習/検証する必要がある。

Godot 側では Godot 4 に関する情報が長いコンテキスト内にあっても、モデルが Python 式パターンや Godot 3 API で回答できる場合があります。したがって long‑context の活用自体を学習させるか、Godot 4 の文脈をより強く固定するデータ設計が必要になることがあります。

godot-dodo / wallstoneai dataset

Godot 側の直接事例としては godot-dodo と wallstoneai/godot-gdscript-dataset があります。

この二つは GDScript の raw code またはリポジトリテキストデータセットに近いです。Godot 特化学習の出発点としては意味がありますが、最終目標であるエージェント軌跡データセットとは距離があります。

現在の目標と比較すると次のように整理できます。

既存の Godot データセット:
GDScript raw code / repo text

必要な Godot データセット:
- Godot repo context
- user task
- file exploration
- patch
- verification
- long-context trajectory

現在の悩みとつながるキーワード

6月14日の振り返りで整理した疑問とつなげると、次のようになります。

プロジェクト全体の文脈と検索された公式ドキュメントの断片を  
一度にモデル入力コンテキストに入れることはできるだろうか？  
-> long-context repo-level coding problem
探索と判断過程までデータとして残すべきか？
-> 軌道トレーニング問題
長いコンテキストを与えても、モデルは Godot 4 の文脈を正しく使用できるでしょうか？
-> long-context utilization / CoLT problem

参考リンク