Claude Code や Codex で実際のプロジェクトのバグ修正をやったことがあるなら、この壁にはたいてい一度はぶつかっています：最初の3ターンは絶妙、10ターン目で崩壊——エージェントが2ターン目に直し終えたバグをまた元に戻し、セッションはエラーとゴミログで埋め尽くされ、あなたは手動で切断して新しいセッションを作り、さらに自然言語で過去1時間の経緯を新しいエージェントに手で説明し直すはめになります。

Loom が解決しようとしているのは、まさにこの「局所的な記憶喪失」です。Valkor が浙江大学のインテリジェント計算・ソフトウェア研究センターと UCL のソフトウェアエンジニアリングチームと共同でオープンソース化した Delivery Harness（デリバリーハーネス）であり、コーディングエージェントに、独立して構造化されたエンジニアリング状態レイヤーを1枚追加します。

コードリポジトリ：github.com/valkor-ai/loom

Loom とは

もっと素直な喩えをすれば、Loom はシングルプレイゲームに「オートセーブポイント」を持ち込む配達用ハーネスです。複雑なソフトウェアデリバリー1回を、構造化されていていつでも復元できる状態チェーンに分解します。

その解決する核心の問題は「どうすればモデルにもっとコードを書かせられるか」ではなく、「長時間タスクを、実際のエンジニアリングの流れの中で、持続的に推進・検証可能・復元可能なまま完走させるにはどうするか」です。

エージェントがテストを実行して失敗したとき、Loom はその失敗を1塊のターミナルテキストとしてチャットコンテキストに流し込んだりしません。捕捉して構造化し、チャット記録とは独立に存在する To-Do 状態にします。

バグは埋もれない

失敗は次のアクションへの「強い制約」になります。エージェントが後続の会話の中で適当にごまかして、このバグを見逃すことは構造上あり得ません。

マルチエージェントがゼロコストで引き継ぐ

最初の5ターンは Claude 4.6 Sonnet にロジックを直させ、6ターン目を GPT-5.5 に替えてテストを回す、ということができます。新しいエージェントが Loom に接続すれば、構造化された「デリバリー状態チェーン」を読むだけで、瞬時に次のことが分かります：

• 自分が誰で、どこにいて、たった今何を変えたのか
• 次にどのバグを直すべきか
• どのファイルの Diff が確定済みで、もう勝手に触ってはいけないのか

長大なチャット履歴を読み返す必要はなく、その場で「試合を引き継ぎ」ます。

なぜ Context Window 競争では長時間タスクが治らないのか

長時間タスクの失敗を「Context Window が十分長くないせい」に帰するのは、実際のエンジニアリングの論理では偽命題です。

情報量が多いことは信頼性の高さとイコールではありません。何万行ものコンパイルログ、複数ターンの Diff、テスト出力を丸ごとコンテキストに詰め込めば、セッションはノイズまみれになり、モデルは迷子になりやすく、部分的には動きそうなコードを完成と誤判定しやすくなるだけです。

エンジニアリングの本質は構造化と決定性にあります。Loom の発想は、モデルにもっと見せてもっと記憶させることではなく、ノイズをろ過し、最も核心的なエンジニアリングの手がかりだけを抽出することです：

• 計画は今どのステップまで進んでいるのか？
• どのユニットテストが本当に Pass したのか？
• どのファイルの Diff が確定済みで、もう勝手に触れないのか？

これらのキーポイントが、プログラムから読める構造化データになったとき、AI Coding の効果を測る基準も「モデルが何行コードを生成できるか」から「長時間タスクをどれだけ完遂できるか」へと変わります。

コア機能

• 自動セーブポイント：デリバリーの過程を構造化・復元可能な状態チェーンに分解します。シングルプレイゲームのセーブポイントのようなものです。
• 独立したエンジニアリング状態レイヤー：チャットコンテキストと分離しており、重要なエンジニアリングの手がかりは、プログラムから読める構造化データとして存在します。
• マルチエージェント / マルチモデルの引き継ぎ：新しいエージェントは状態チェーンを読むだけでその場で引き継げ、モデルをゼロコストで切り替えられます。
• 失敗はそのまま制約になる：テスト失敗は To-Do 状態として捕捉され、次のステップへの強い制約となります。チャットのノイズに埋もれません。

実際に使ってみて

長所

• 長時間タスクの暴走を解決：コンテキストが伸びたことでエージェントが方向を見失うことがなくなり、10ターン目に2ターン目に直し終えたバグを戻すようなことがなくなります。
• マルチモデル協業の解禁：タスクの段階に応じて最適なモデルへ切り替えられます。ロジックは1社、テストは別の1社、互いに干渉しません。
• 「Context Window 競争」路線と補完関係：Loom は競合せず代替でもなく、既存の Coding Agent ワークフローの外側に積み重ねる1層のインフラです。

コスト

• Loom を既存の Claude Code / Codex ワークフローに組み込む必要があり、初期設定のコストはそれなりにあります。
• まだ生まれたばかりのオープンソースプロジェクトであり、エコシステムとドキュメントの成熟度は各自で見極める必要があります。

活用シーン

• 長時間タスクのデリバリー：1つのセッションで10ターン以上の複雑なバグ修正、API 補完、機能開発を回す。
• マルチモデルワークフロー：タスク段階に応じて Claude、GPT などを動的に切り替えたいが、中間状態は失いたくない。
• 本番環境に進む前の検証：デモが動くことと本物のソフトウェアの間には、信頼性検証の一式がまだ必要です。Loom はその状態インフラを提供します。
• エージェント評価 / ファインチューニングデータ収集：Loom は実行過程でエージェントの動的なフィードバック軌跡を捕捉し、将来の動的ベンチマークやファインチューニングに、実際のエンジニアリングコーパスを提供します。

位置づけと補完性

Loom は agentic loops の一般的なパターン（ループ、フィードバック、ツール呼び出し）と重複ではなく補完の関係にあります。loops が単一タスク内の実行クロージャを担うのに対し、Loom はタスク・セッション・モデルをまたぐエンジニアリング状態の永続化を担います。

大規模モデルが静的なコーパスから学べるのは「完璧な最終コードの姿」までで、「複雑なバグがどう一段階ずつ特定され、失敗し、妥協し、最終的に修復されていくか」はなかなか学べません——しかし、この過程の軌跡こそが、ソフトウェアエンジニアリングにおける最も核心的なエンジニアリング判断力なのです。

リポジトリ：github.com/valkor-ai/loom