GraphForgeは、実際の業務ファイルの上に課題とその採点基準を同時に立て、文書を読み込みツールを操作して成果物を作り上げる「働くエージェント(working agent)」の学習データを合成する手法だ。ファイル同士の関係を証拠グラフ(evidence graph)として編み上げたうえで、そこから課題の説明と評価項目を同時に取り出す、というのが核心である。こうして作った2,169件の学習トラジェクトリでQwen3.6-27Bをファインチューニングしたところ、業務遂行能力を測る3つのベンチマークのスコアがすべて上がった。
働くエージェントを育てるには、二つのものが同時に必要になる。一つは本物さながらの仕事 ― 報告書、スプレッドシート、ポリシー文書が入り混じった実際のワークスペースだ。もう一つは、その仕事をきちんとやり遂げたかを見極める採点表である。新人に実務を任せるとき、現実的な課題を与えることと、その成果物を評価する基準を手渡すことが、それぞれ別の準備であるのと同じだ。
これまでに登場した学習データ合成の手法は、このどちらかを諦めていた。論文が比較対象として挙げる二つのパイプラインが、その二つの系譜をそれぞれ代表している。
| 方式 | 作業環境 | 検証 | 規模 |
|---|---|---|---|
| EnvCraft | モデルが生成したワークスペース | 状態確認スクリプト | 20K課題 |
| NexForge | 実ファイル | なし | 5.6K課題 |
| GraphForge | 実ファイル | 証拠ベースのエージェント審判 | 2.1K課題 |
EnvCraftはファイルそのものをモデルで生成するのだが、そのぶん現実味と多様性が落ちる。しかも検証をPythonスクリプトでワークスペースの「状態」だけを見る方式なので、ファイルの中身は読めず、文書成果物の中に潜んだ誤りを見逃す。NexForgeは逆に、実ファイルの上に課題を立てるものの、課題ごとの採点基準や検証器を与えないため、エージェントが出した結果の品質を問いただす術がない。本物のファイルで多様な課題を作りつつ、そこに信頼できる採点基準まで付ける、という作業がそれだけ難しかったということだ。
GraphForgeが巧みなのは、「方向性」と「中身」の出どころを切り分けた点にある。モデルに課題を好きに考えさせると、ありふれた職業と当たり障りのない分析課題へと偏る。そこで、課題の方向性は職業データで固定し、具体的な中身と検証はすべて実ファイルから引き出す。全体の流れは五つのステップで進む。
まずシード(seed)を、O*NETという職業データベースから取り出す。米国労働省系の公式職業辞典で、職業ごとに業務内容と詳細業務活動(DWA)が整理されている。このうちデジタルで遂行可能な課題だけを残すと、16の産業分野にまたがる246職業、891の業務タイプ、3,419通りの有効な組み合わせが残る。偏りを防ぐため、すでに選んだシードと重複しない側を優先して拾い、多様性を広く展開する。
シードそのものには、会社名も、出来事も、データもない。「誰が、どんな需要を、主にどう処理するのか」だけが入った空の枠である。次のステップでは検索エージェントが実在する公開事例を探し、その仕事に必要なファイルを集めてワークスペースを仕立てる。このとき、ファイルごとに表には現れない役割が割り当てられる。コアファイルは計算と判断を引っ張り、補助ファイルは文脈を与え、かく乱ファイル(confuser)はもっともらしいが実際には役に立たない罠であり、周辺ファイルは現実的なノイズを足す。この役割表は、課題を解くエージェントには最後まで見せない。
その上に証拠グラフを立てる。グラフのノードは、あるファイルが提供する事実や値であり、エッジはファイルをまたぐ依存関係 ― 比較したり、対照したり、導き出したりすべきつながりだ。まさにこのグラフから、課題の説明と採点基準が一緒にコンパイルされる。各採点項目には評価に必要なファイルが証拠アンカー(anchor)として結び付けられ、どう確認するかの手順まで添えられる。課題を解くエージェントは課題文と要件だけを見て、審判はアンカーと確認手順を受け取る。採点表をファイルに釘で打ち付けておきつつ、その釘の位置は問題用紙に漏れないようにした、というわけだ。
ここで終わりにはしない。文面だけを眺めていても長い課題の曖昧さは拾いきれないので、強力な教師モデルに課題を一度実際に解かせてみる。その実行結果を修正エージェントが元のファイル・グラフと突き合わせ、課題が自然か、要求した値がファイルで裏付けられるか、すべての項目がきちんとアンカーされているかを点検し、直すべき部分だけを返す。最後に成果物が実際に生成されたかを機械的に確認したうえで、エージェント審判が元ファイルと成果物を交互に見ながら項目ごとに採点する。ツールを無駄に繰り返し呼び出すなど、異常なトラジェクトリはふるい落とす。こうして通過したものだけが学習データに入る。
著者らはQwen3.6-27BをGraphForgeのデータでファインチューニングし、3つのベンチマークで測り直した。数値はそれぞれ異なる評価ハーネス(エージェント実行の枠組み)の下で出た値なので、条件をまとめて読む必要がある。
| ベンチマーク | 結果 | 向上 | 評価ハーネス |
|---|---|---|---|
| GDPVal (Elo) | 1445.7 | +65.7 | OpenHands |
| Workspace-Bench-Lite | 63.7 | +7.7 | Claude Code |
| SpreadsheetBench II | 24.0 | +13.7 | Claude Code |
GDPValのスコアはパーセンテージではなくEloレーティングなので、意味を正確に読み取らねばならない。この1445.7は、人間の成果物と直接比べた値ではない。著者らが複数のモデル・ハーネスの組み合わせを互いに対戦させて算出した内部Eloで、GLM-5.3(OpenHands)の組み合わせを1667に固定して尺度の基準点を取り、1445.7はその尺度の上での相対位置だ。GDPVal自体は44職業にまたがる1,320課題を専門家の採点表で評価するベンチマークで、著者らはそのうち220のゴールド(gold)部分集合を使った。目を引くのはスプレッドシート側の上げ幅だ。24.0は+13.7が足された値なので、出発点が10.3前後だったことになるが、相対的に最も大きく跳ね上がっている。
これに加えて著者らは、ファインチューニングしたモデルが自ら生成した実行結果の中から、証拠ベースの採点表で良いものだけを選んで再学習させるリジェクションファインチューニング(rejection fine-tuning)を回した。3つのベンチマークすべてでさらにスコアが上がったことは、その採点表が単なる評価ツールを超えて「どの成果物が使えるものか」を選び出す信号の役割まで果たすことを意味する。同じデータが構造の異なる二つ目のベースモデル(Qwen3.6-35B-A3B)でも効果を出したという点は、この方式が特定のモデルにだけ当てはまる小技ではない可能性を示している。
規模を見ると、また別の判断が立つ。GraphForgeの課題数は2.1Kで、比較群(20K、5.6K)よりはるかに少ない。少なく作ったのにより良くなったのなら、検証された少数のデータが検証なしの多数に勝る、という方向を指し示す。データとモデルは公開されている。
正直に押さえておくべき点がいくつかある。
最終的な採点を、人間ではなくエージェント審判(LLMベース)が行う。採点表がファイルにアンカーされているので根拠のない判定は減るだろうが、審判そのものの信頼性は依然として開かれた問題だ。論文の表現も断定ではなく「採点表が有用な選択信号を与えているように見える」という慎重な側に寄っている。
学習トラジェクトリが強力な教師モデルの実行から生まれる、という点も諸刃の剣だ。教師が解けないタイプはデータにも入りにくく、教師の癖と限界を受け継ぐ恐れがある。証拠グラフもまた、著者らが「正解ではなく中間表現だ」とはっきり釘を刺している。グラフの主張は元ファイルで再確認可能であるべき補助装置にすぎないため、グラフがファイルをどれだけ忠実に反映したかに品質がかかっている。
上の数値は、特定のベンチマークを特定のハーネスの下で測った値だ。別の課題や別の実行環境にどれだけ広がるかは報告された範囲の外にある。論文には別途、限界を論じる節があると記されているが、本稿が受け取った抜粋にはその詳細が含まれておらず、具体的な中身は断定しない。
ONTLEでAI PMが作業を「完了」と報告する瞬間を思い浮かべてみよう。顧客がアップロードしたイカウント(ECOUNT)の精算明細、サプライヤーの見積エクセル、契約条件のPDFが一つのフォルダに混ざっていて、PMはそれを読んで月次精算レポートを作り上げた、という。問題はその後だ。本当に正しくできているのか。ONTLEが繰り返し痛い目に遭ってきた「ゴースト完了(ghost-done)」 ― ステータスは完了に変わったのに、実際の結果は空だったり間違っていたりする状況 ― は、まさにこの地点で生まれる。これまでの確認は結局、「成果物がもっともらしいか」を人間が目で眺める水準にとどまりがちだった。
GraphForgeの証拠アンカーという発想が変えるのは、まさにこの場面だ。「精算合計が正しい」を漠然と判定する代わりに、その判定に必要なファイルとセルを採点項目にあらかじめ釘で打ち付けておく。見積エクセルのD列の合計、契約PDFの手数料条項、イカウント明細の該当伝票 ― 各合格条件がどのファイルのどの値を見れば検証されるのかが、課題を作る瞬間に一緒に決まる。そうすればPMの「完了」は、感覚ではなく「この項目はこのファイルのこの値と突き合わせて通過」という、追跡可能な根拠へと変わる。課題を解くPMにはアンカーを隠し、審判にだけ渡す構造も、そのまま役に立つ。PMが正解への道筋を逆算して真似るのではなく、実際にファイルを読んで仕事をするよう強制されるからだ。ONTLEが今すぐこのパイプラインを導入しよう、という話ではなく、「完了をソースファイルに紐づけて検証する」という設計原理が、ゴースト完了問題への正攻法に近い、という意味である。
論文は、合成データと学習済みモデルを公開したと述べています。HuggingFaceのgroundhogLLM/graphforgeコレクションからアクセスできると記されています。ただしライセンスや実際の再現条件は、公開ページで直接確認する必要があります。
職業ごとに遂行業務と詳細活動を整理した公式の職業データベースです。モデルに自由に課題を考えさせると、ありふれた職業と当たり障りのない分析に偏りますが、職業データをシードとして使えば、課題の方向性を広く展開したまま固定できます。GraphForgeはこのうち、デジタルで遂行可能な課題だけを残して使います。
いいえ。論文は、証拠グラフが正解ではなく中間表現であることをはっきりさせています。グラフに含まれる主張は必ず元ファイルで再確認可能であるべき補助装置であり、最終的な根拠はあくまで実際のファイルです。
通常のファインチューニング(SFT)が教師モデルの実行トラジェクトリをそのまま学ぶ段階であるのに対し、リジェクションファインチューニングは、学習済みモデルが新しい課題で自ら生成した結果のうち、採点表で良いものだけを選んで再学習する方式です。本論文では選別基準として証拠ベースの採点表を用い、3つのベンチマークすべてで追加の向上が得られました。