SWE-1.7の自己圧縮から考えるAIDDの再開メモ設計

2026年7月8日、Cognition が SWE-1.7 を公開しました。記事では、SWE-1.7 が Devin で利用できること、強化学習パイプライン、複数クラスタでの学習、データ品質、長時間タスク向けの自己圧縮などが説明されています。

性能表や学習基盤の話も面白いのですが、個人的に一番ひっかかったのは self-compaction でした。長いタスクがコンテキスト上限に近づいたとき、モデル自身が作業状態を要約し、その要約から再開するという設計です。

これ、AIDDでもかなり身近な問題です。

Claude Code、Codex、Devin、Cursor のような開発AIエージェントを使っていると、作業は1ターンで終わりません。調査して、修正して、テストして、失敗して、別のファイルを読み、途中で人間の判断待ちになる。ここで作業が切れると、次に再開するときの品質は「何が残っているか」に強く依存します。

え、結局メモの品質が開発速度を決めるのでは。

今回は、SWE-1.7そのものの性能を検証したわけではありません。Cognition の記事から「長時間タスクを再開可能にするには、圧縮された状態が必要になる」という論点だけを取り出し、AIDDの作業再開メモとして何を残すべきかを小さく検証しました。

LLM Lab 同じ作業を2回やったら負けをAIDD標準化に落とす 個人のAI活用テクニックをプロンプトの共有で終わらせず、標準コマンド、テンプレート、レビュー観点へ落として組織知にする考え方を整理しています。 https://llm-lab.dev/posts/aidd-standardization-repeat-work/

SWE-1.7の記事から拾った論点

Cognition の記事では、SWE-1.7 についていくつかの軸が説明されています。たとえば、top-p sampling と学習時の分布のずれを扱う工夫、複数クラスタをまたいだ強化学習、検証器品質やチート防止を含むデータ整備、そして長時間タスク向けの自己圧縮です。

この記事では、そのうち自己圧縮だけを扱います。理由は、手元のAIDD運用に直接つながるからです。

開発AIエージェントの運用では、モデルが賢いかどうかだけではなく、次のような問題がすぐに出ます。

• どのファイルを読んだのか
• どのコマンドを実行したのか
• 何が失敗しているのか
• 何をまだ決めていないのか
• 次に何をすればよいのか
• 触ってはいけない範囲はどこか

これらがチャット履歴の奥にしか残っていないと、再開時に毎回掘り起こしが発生します。さらに、別のAIエージェントへ引き継ぐ場合や、人間がレビューする場合には、履歴全体を読む前提が現実的ではありません。

SWE-1.7の記事が示している自己圧縮は、巨大モデルの学習テクニックとして語られています。一方で、AIDDの運用に引き寄せると、「作業状態をどの粒度で残せば、次の実行者が安全に再開できるか」というかなり地味な設計問題になります。

検証したかったこと

今回の検証では、注文管理画面のCSV取り込み履歴に失敗状態フィルタを追加する、という架空の開発タスクを題材にしました。機密情報や実在の業務情報は使っていません。

用意したのは、次の2種類の再開メモです。

短すぎる再開メモ:
注文管理画面のCSV取り込み履歴を修正中。
フィルタ周りでテストが落ちているので、続きから直す。

もう一方は、目的、対象ファイル、実行済みコマンド、落ちているテスト、未決定事項、次の行動、安全制約を明示した長めの再開メモです。

検証用に用意したスクリプトでは、外部APIやモデル呼び出しは行いません。固定の作業状態と2種類の再開メモを入力にし、再開に必要な情報が残っているかを決定的にチェックします。

見る項目は次の7つです。

• 目的
• 現在見ているファイル
• 実行済みコマンド
• 失敗中の確認
• 未決定事項
• 次の行動
• 安全制約

これは公式CLIではなく、記事用に用意した自作の検証スクリプトです。npm run verify は、サンプルの作業ログを読み込み、2種類の再開メモを同じ評価基準にかけ、JSON と HTML レポートを出力します。

npm run verify

この検証で確認したいのは、自然言語の要約が上手かどうかではありません。圧縮されたメモが、次の作業者に必要な状態を持っているかどうかです。

短いメモは安心感だけを残す

結果はかなり極端でした。

短すぎる再開メモは、7項目すべてで失敗しました。一方、運用に使える再開メモは、7項目すべてを満たしました。

短いメモにも、何となく状況は書かれています。「CSV取り込み履歴を修正中」「フィルタ周りでテストが落ちている」という情報はあります。ただ、再開に必要な粒度には足りません。

たとえば「フィルタ周りでテストが落ちている」だけでは、次の実行者はどのテストを見ればよいか分かりません。どのファイルを変更していたのかも分からないため、まず検索から始める必要があります。さらに、どこまで触ってよいのか、安全制約も残っていません。

これはつらい。

人間が同じ日に再開するなら、記憶で補えます。しかし、翌日、別のエージェント、別のメンバー、別の端末という条件が入ると、短いメモはほとんど役に立ちません。安心感はありますが、作業状態としては薄すぎます。

再開メモは要約ではなく引き継ぎ仕様である

今回の検証で分かったのは、AIDDの再開メモを単なる要約として扱うと弱いということです。

要約なら、短くまとまっていることに価値があります。しかし、再開メモの目的は短くすることではありません。次の作業者が、余計な探索を減らし、誤ったスコープ変更を避け、安全に次の1手へ進めることです。

その意味では、再開メモは「引き継ぎ仕様」に近いです。

特に重要だと感じたのは、安全制約です。開発AIエージェントは、指示が曖昧だと、良かれと思って周辺のコードまで直すことがあります。SWE-1.7の記事でも、より探索するモデルは、追加テストを書いたり、作業範囲が広がったりする傾向があると説明されています。これは性能の高さでもありますが、運用では変更範囲の拡大として現れます。

だからこそ、再開メモには「次にやること」だけでなく、「触らないこと」も必要になります。

残すべきもの:
目的、対象ファイル、実行済みコマンド、失敗中の確認、
未決定事項、次の行動、安全制約

この7項目は、完璧な標準ではありません。タスクの種類によって増減します。ただ、AIDDで長時間タスクを扱うなら、最低限この粒度から始めると、チャット履歴への依存を減らせます。

自己圧縮を運用へ落とすと評価の話になる

自己圧縮という言葉だけを見ると、コンテキスト節約のテクニックに見えます。もちろん、それもあります。しかし運用で考えると、問題は「短くできたか」ではありません。

重要なのは、圧縮後の状態が検証できるかです。

今回のような単純なスクリプトでも、短いメモと運用に使えるメモの差は見えました。実際のAIDD運用では、ここにさらに Git diff、未完了タスク、レビュー指摘、CI結果、手元で実行したコマンド、判断待ちの論点が入ります。そうなると、再開メモを人間の感覚だけで良し悪し判定するのは難しくなります。

自分なら、まず次のような形で運用に入れます。

• 長時間作業の終了時に、AIへ再開メモを作らせる
• 再開メモに必須項目があるかを決定的にチェックする
• 欠けている項目があれば、AIへ追記させる
• 再開時は、チャット履歴より先に再開メモを読む
• 重要な判断は、再開メモではなく設計メモやIssueへ戻す

ここまでやると、自己圧縮は単なるプロンプト術ではなく、AIDDの運用ログ設計になります。

今回やっていないこと

今回の記事では、SWE-1.7の性能評価、Devin上での挙動確認、Cognitionが公開したベンチマーク結果の再現は行っていません。

また、再開メモをLLMに生成させるところも検証対象にしていません。今回は、再開メモが存在すると仮定し、そのメモに必要な情報が残っているかだけを見ています。

次に試すなら、実際のAIDD作業ログから再開メモを生成し、今回の7項目で不足を検出し、足りない項目だけをAIに補わせる流れを作りたいです。そこまで行くと、自己圧縮の品質を「読みやすい要約」ではなく、「再開できる状態」として評価できます。

まとめ

SWE-1.7の記事を読んで面白かったのは、長時間タスクの賢さが、単に長いコンテキストを持つことだけではなく、途中状態をどう圧縮し、どう再開するかに依存している点でした。

AIDDでも同じです。AIエージェントが長く動けるようになるほど、作業の途中状態をどう残すかが重要になります。チャット履歴に全部あるから大丈夫、では運用になりません。

短い再開メモは安心感を残します。しかし、次の作業者が安全に再開するには、目的、対象ファイル、実行済みコマンド、失敗中の確認、未決定事項、次の行動、安全制約が必要です。

個人的には、AIDDの自己圧縮は「要約をうまくする話」ではなく、「再開可能な作業状態をテストする話」として扱うのがよさそうです。ここを仕組みにできると、AI駆動開発はその場のチャットから、引き継げる開発プロセスへ近づきます。