ハーネスをゼロから作り直しました

Poglでは、AIが人と会話しながらゲームを作り、直します。この仕事をする枠組みを、私たちはハーネスと呼んでいます。11月9日、このハーネスをゼロから作り直すことにしました。

最初はOpenCodeで始めました

OpenCodeは多くの開発者が使うオープンソースのコーディングエージェントです。すでに広く使われて実績があり、ファイルを読んで直す機能、モデルを切り替える機能、ほかのツールをつなぐ機能がそろっていました。そこでエージェントはOpenCodeをそのまま使い、私たちはその上にゲームを立ち上げて確認するツールと公開前のチェックを加えました。これがPogl Builderです。

使ううちに三つの点が合わなくなりました

結局、独自の機能を多く加えることになりました。モデルの選択、費用の計算、提供元の障害時に別の提供元へ切り替える処理は、私たちが作った中間層が担うようになり、ツールとチェックも最初から私たちのものでした。11月には、OpenCodeが担っていたのはファイルを読んで直す繰り返し程度でした。

個人のコンピューターではなく、仮想サンドボックスで動かす必要がありました。OpenCodeは開発者が自分のコンピューターで使うツールです。Poglでは作業ごとに仮想マシンを起動し、その中にOpenCodeサーバー（約0.63GB）を導入し、ワーカーは結果が出るまで問い合わせ続けて待っていました。毎回のリクエストの冒頭に付く固定部分も約1万4千トークンありました。この環境に合わせてサイズと性能を絞る必要がありました。

レガシー機能が積み重なり、非効率になっていました。新しい機能はOpenCodeの外側に経路をひとつずつ足す形で加わりました。11月9日時点で、リクエストの種類によって分かれる経路が16個、作業が終わったかを判定する方式が3種類、AIに渡す契約文書が6〜7種類あり、画面から外した機能のエンジンもハーネスに残っていました。同じ問題を経路ごとに別々に直す必要があり、ワーカーを再起動すると動いていた作業が途切れました。

モデルが良くなるほど、ハーネスはシンプルであるべきでした

最近のほかの企業の記事や研究も同じ方向を示していました。モデルが強くなるほど、ハーネスに積み上げた複雑な構造は助けになるより妨げになる、ということです。

• Lovableは、サブエージェントに仕事を分けて任せる複雑な構造を作ったあと、エージェントのコードをほぼすべて削除しました。（How we built Lovable、2026年11月）
• Replitは、新しいモデルが出るたびにハーネスに組み込んだ前提が古くなるとして、判断はモデルに任せ、ハーネスは選択肢と安全装置だけを用意しています。（Free the models、2026年9月）
• Cursorは、エージェントのループ、仮想マシンの状態、会話履歴を互いに分離しました。（What we’ve learned building cloud agents、2026年6月）
• Appleの研究者は、同じモデルと同じ時間なら、複雑なハーネスはシンプルなエージェントより優れていなかったと発表しました。（How Much of a Harness Does a Strong Agent Need?、2026年10月）

そこで、AIが働く仕組みであるループ・ツール・契約・会話履歴はゼロから作り直しました。ただし、お金・返還・チェックのルールは実際の障害を経て生まれたものなので、旧コードからそのまま移しました。

新しいハーネスPogl Agentはひとつのループで動きます

新しいハーネスの名前はPogl Agentです。相談・企画・作成・修正・エラー修正・外部AIツールからのリクエストが、すべて同じループに入ります。ループはモデルに問い合わせ、モデルが選んだツールを実行し、その結果を記録することを繰り返します。中核のループは715行です。

変わったことは五つです。

• ツールは13個で、一か所に登録します。ファイルを読む、直す、ブラウザで実際に操作してみる、画像や音を作る、以前のバージョンを見る、といったツールがひとつのリストにあります。修正ツールは、変える箇所がちょうど一か所のときだけ直します。ツールの説明は合計3千トークン以内に収め、音声リストのような長い資料は必要なときに読む文書に移しました。
• 契約文書はひとつの生成器が作ります。ひとりで遊ぶゲームか、みんなで遊ぶゲームか、2Dか3Dかを見て、AIに渡す文書をその場で作ります。
• 会話履歴はゲームごとにひとつです。相談で長く話してから修正を送っても、前に決めた内容は同じ履歴の中に残っています。作業中に送ったメッセージも同じ履歴に入ります。
• ステップごとに記録を一行ずつ残します。ワーカーが再起動すると、この記録から会話を組み立て直して続きから進めます。最初からやり直しません。
• モデルはループが直接呼び出します。間にサーバーを挟まず、どのモデルを使うかや、障害時に別の提供元へ切り替えるルールも、ループの中の一か所にあります。

仮想マシンの中にOpenCodeサーバーを導入する手順もなくなりました。仮想マシンはゲームを立ち上げて確認するためだけに使います。

いちばん重い作業が減りました

毎回のリクエストの冒頭に付く固定部分は、1万4千トークンから6千トークン以内に減らしました。音声リストのようにたまにしか必要ない資料は文書に移し、必要なときだけ読むようにしました。

11月11日0時59分から同じ時間帯に反映された修正を比べました。修正1回あたり、モデルがキャッシュなしで新たに読んだ入力は平均19万5千トークンから6万9千トークンに、モデルが書いた出力は平均2万1千トークンから1万トークンに減りました。

この差の大部分は、旧ハーネスのごく大きな作業から生まれていました。以前はいくつかの作業が数十万トークンを新たに読み、40分以上動いていましたが、新しいハーネスではそうした作業はありませんでした。一般的な大きさの作業だけを見ると、新しいハーネスは新たに読む入力は少ないものの、キャッシュから読み直した量と出力は多く、時間も長くかかりました。

同じリクエストで回し直しました

11月10日、実際のゲームのコピー60個に、過去に届いた修正リクエストをそのまま送り直しました。そして両方のハーネスの結果を同じ判定器で採点し直しました。二つのハーネスは判定基準が異なり、それぞれの判定をそのまま比べられなかったためです。判定まで終わった54組を比べました。

全体の割合は近い値でしたが、リクエスト単位では違いがありました。旧ハーネスが「できていない」や「要確認」として残した項目を新しいハーネスがすべて解決したリクエストが8件、その逆が5件でした。

変わったのは結果の伝え方でした。クリエイターからの問い合わせで届いた修正のひとつを、同じリクエストで回し直しました。旧ハーネスは直せなかった項目に「できた」と表示してクレジットを差し引いていた作業です。新しいハーネスはバージョン履歴を開いて原因となったバージョンを見つけ、元に戻す方法がないと判断して「できていない」と記録し、クレジットを全額返しました。

ユーザーの半分に適用しました

11月11日0時59分、ユーザーの半分にPogl Agentを適用しました。一人のユーザーが相談と修正で別々のハーネスに当たらないよう、人単位で分けました。問題が起きれば、設定値ひとつで1分以内に全員がPogl Builderに戻ります。

最初の2時間で、修正20件のうち17件が反映されました。1件はAIが直せなかったと判断してクレジットを返し、1件は変える箇所がなく、1件はユーザーが中断しました。失敗で終わった作業はありませんでした。相談は44件が正常に処理されました。

かかった時間は分布が異なりました。

旧ハーネスは半分が6分以内に終わりましたが、25分、27分、42分、53分かかった作業もありました。新しいハーネスはすべての作業が7〜31分のあいだに終わりました。小さなリクエストでも7分以上かかるのはAIが確認を回しすぎていたためで、11日未明に確認の回数を減らすよう直し、効果を測っています。

直す場所がひとつになりました

今回いちばん大きく変わったのは、直す場所の数です。以前は同じ問題を経路ごとに別々に直す必要がありましたが、今はループ、ツール、契約、判定がひとつの場所にあります。比較テストと半分への適用で見つかった問題も、ほとんどはその日のうちに一か所を直して解決しました。

残りの半分にも順に適用したあと、Pogl BuilderとOpenCodeのコードを削除する予定です。