AIプログラミングのボトルネックはコード作成からコンテキスト管理へ移行している

1 つのタスクがコンテキストシステム全体をどう通過するか

Havenga 氏の作業の入り口は、「エディタを開いて、今日何をするか考える」というものから、自動的に組み立てられる優先度付きキューへと変わりました。新しいセッションはまず、まだ活動中の他のセッション、未解決のブロック、長期指示、最近の決定を読み取ります。その後、GitLab から ToDo、アクティブなマージリクエスト、追跡中のエピックを取得します。

キューの順序も明確にコード化されています。最初に表示されるのは、長い間進展がなく、視界から外れそうな古い項目です。次に、他者から依頼されたレビューです。なぜなら、先延ばしにすると同僚の作業を引き続きブロックしてしまうからです。その次に、彼の返答を待っている問題、彼自身がブロックされている MR が続き、最後にその他の作業が来ます。このステップにより、チームのブロック、タスクの陳腐化、個人の進捗が、安定した選択ルールに変換されます。これは、単なる ToDo 表示の役割を超えています。

タスクが選択されると、システムはそのタスクのためにコンテキストの組み立てを開始します。MR の作業は、以下のプロセスを経ます。

1. この MR、関連する issue や epic の履歴上の決定、未解決のブロック、前回残された次のステップを読み取る。
2. タスクの種類に一致するルールと procedure を検索する。例えば、コメント規約、データベースマイグレーションフロー、レビュー要件など。
3. その作業項目が既に他のセッションによって引き受けられていないかを確認する。引き受けられていない場合は claim を確立し、現在の所有者を明確にする。
4. セッションに独立した git worktree とテスト用データベースを割り当て、ファイルの状態と実行時の副作用が互いに分離されるようにする。
5. エージェントがコードを変更し、テストを実行し、結果を整理する。人は、目標、アーキテクチャ、正確性、マージ条件を満たしているかを確認する。
6. 作業が完了、一時停止、または新しいブロックが発生した場合は、ステータスを更新してリソースを解放し、新しい決定、事実、procedure を記憶に書き戻す。

この順序により、「モデルにより多くのコンテキストを与える」という行為が、検査可能な状態遷移へと変わります。コンテキストはセッション開始時にすべて詰め込まれるわけではありません。システムはまずタスクを選択し、その後で選択されたエンティティを中心に情報を読み込みます。また、エージェントは指示を読んだだけで直接作業に取りかかることはできず、まず引き受けと分離を完了しなければなりません。レビューは経験が書き戻される前に行われ、未確認の出力が、以後すべてのセッションが継承するルールになってしまうのを防ぎます。

筆者は現在、15 分や 30 分の空き時間を利用して複雑なタスクを進めることができると述べています。キューの先頭にあるものを尋ね、システムに関連する背景を復元させ、そしてコーディングとテストを委任するのです。この時間は個人の経験に基づくものであり、一般的な生産性の指標として扱うことはできません。しかし、それが示す変化は具体的です。かつて短い時間は主に「どこまでやったか、なぜそうしたのか、誰がまだ私を待っているのか」を思い出すことに費やされていましたが、現在はその再構築作業をシステムが担い、人はより迅速に判断と委任に入ることができます。

このような働き方は「プロアクティブな委任」に依存しています。人はタスクを横断する最上位の目標を保持し、現在の作業が依然として正しい方向に役立っているかを判断します。エージェントは境界が明確なタスクを受け入れ、実行速度を維持します。システムは、タスクの状態、履歴、制約を人の短期記憶から切り離す一方で、人の方向性のコントロールは保持します。

指示が一度きりの修正から長期的な制御へと変わる仕組み

新しいセッションはそれぞれ、ほぼ空白の状態から始まる可能性があります。永続的な指示がない場合、チームの合意事項、コードベースの習慣、個人の好みは繰り返し説明されなければなりません。問題は単に「モデルが忘れてしまう」ことだけではありません。実際、人に向けられた注意事項の多くは、そもそも実行可能ではありません。

「コメントに注意する」「安全に気を付ける」「もっとプロフェッショナルに書く」といった指示には、明確なトリガー条件も、失敗した場合の行動もありません。エージェントは口頭では同意するかもしれませんが、何をチェックすべきか、チェックできない場合に続行してよいのかが分かりません。原文のルールはより具体的です。特定のユーザーに代わってコメントを投稿する前に、そのユーザー ID が存在することを確認しなければならず、確認できない場合は停止して問い合わせる必要があります。

トリガー：あるユーザーとしてコメントを投稿しようとしている
必須の操作：そのユーザー ID が実在することを確認する
停止条件：確認できない場合は停止し、推測せず、質問する

この種のルールは、「何をするか」と「いつ続行できないか」の両方を制御します。ALWAYS や STOP などの大文字の単語は、筆者の使用環境では遵守率を高めるように見えますが、原文は比較テストを示していません。再利用できる方法は、抽象的な好みを、タスクのトリガー、必須アクション、停止条件、検証可能な結果に書き換えることです。

また、指示はプロジェクト開始時に想像で書き満たすべきではありません。Havenga 氏の方法は、インシデントの振り返りから来ています。エージェントがエラーを犯した後、まず現在のタスクを修正し、次にどの指示が同種のエラーの再発を防げたかを尋ねます。人とモデルが一緒に表現を調整し、他のシナリオを誤って傷つけないことを確認してから、保存します。したがって、永続的なルールは実際の失敗に対応し、明確な適用範囲を持っています。

彼の agents-config にはかつて 10 以上の専用設定ファイルが含まれており、コードレビュー、MR ワークフロー、データベース操作、コメント作成、ステータス更新をそれぞれ処理していました。現在の公開設定では、より細かいトリガー方法を見ることができます。レビューを開始する前にレビュー手順を呼び出し、データベースマイグレーションを処理する前にデータベース規約を呼び出し、MR、issue、または epic に触れる前にエンティティ履歴を読み込みます。ルールはタスクの種類によってトリガーされ、各セッションは現在必要な規範のみを読み込みます。

ルールが増え続けると、静的ファイルには 2 つの問題が現れます。1 つ目は、起動コストが増大し、現在のタスクに関係のない規範もコンテキストを占有することです。2 つ目は、ルールの鮮度の管理が難しくなり、古いプロセスが新しい決定を上書きする可能性があることです。筆者は後に多くの procedure と詳細を検索可能な記憶に移し、起動コンテキストには少数の必須ゲートだけを残しました。安定しており、短く、すべてのタスクに適用される制約は起動層に残し、特定のタスクやエンティティに関連する知識はオンデマンドで呼び出します。

これにより、維持可能なルール進化の道筋が形成されます。失敗が是正を生み、是正が局所的な指示を形成し、高頻度の操作が procedure として沈殿し、procedure はタスクトリガーと記憶検索によって読み込まれます。ルールはもはや単なるプロンプトの付属物ではなく、ワークフローの制御面となります。

マルチエージェント並行処理には、作業の引き受けと環境の分離が必要

3 つのターミナルを同時に開き、3 つのエージェントを実行しても、実行主体が 3 つ増えるだけで、自動的に並行システムが手に入るわけではありません。原文に挙げられている障害には、セッションが同じファイルを変更する、2 つのセッションが同じ作業項目を選択する、それぞれが隔離された情報の中で矛盾する決定を下す、1 つのセッションが別のセッションの作業を削除またはコミットする、複数のセッションが既に解決済みの問題を繰り返し調査する、といったものがあります。

これらの障害は異なる層に分布しているため、1 つのワークツリーで全てを解決することはできません。

安全な並行タスクには、ライフサイクルに沿ってこれらの仕組みを組み合わせる必要があります。セッションはまず claim を確認し、次にエンティティ履歴を読み取ります。引き受けに成功した後、対応するワークツリーを作成または入力し、テスト接続をそのセッション自身のデータベースに向けます。実行中はフェーズとブロックを継続的に記録し、終了時には結果を保存し、claim を解放し、不要になったワークスペースをクリーンアップします。異常終了の場合は、期限切れ、引き継ぎ、または手動解放のポリシーも必要です。そうしないと、保護メカニズム自体が永久的なロックを残すことになります。

筆者が公開しているテスト基盤は、この分離を具体的に示しています。異なるセッションは異なるワークツリーと、セッション名にちなんだテスト用データベースを持ち、基盤となる Postgres と Redis サービスは共有しますが、テスト書き込みは共有しません。セッションの作成、テストの実行、設定の診断、セッションの削除は、スクリプトによって一元管理されます。この価値は「同時にテストを実行できること」だけではなく、環境を列挙、検査、回収できることにもあります。

筆者は当初、ファイル形式の作業メモを使用して状態を共有していました。ファイルはセッションをまたいで保存できますが、3 つの明らかな制限がありました。異なる表現で検索しにくく、特定の MR や関数に安定して関連付けることができず、日をまたいだ場合に、それを必要とするタスクに自動的に現れにくいという点です。並行システムには、エンティティを中心に状態を保存し、履歴を検索し、プロアクティブにリマインドできる共有サービスが必要ですが、notes ファイルを拡張してもこれらの能力は得られません。

この要件が、最終的に opencode-memory を生み出しました。これは長期記憶とセッション調整の両方を担います。複数のエージェントが同じバックグラウンドサービスに接続することで、作業項目の claim、エンティティ履歴、関連する procedure が異なるセッションから見えるようになります。ファイル分離は「同じ場所に変更を加えない」ことを扱い、共有記憶は「互いの決定を知らずにそれぞれ作業を進めない」ことを扱います。

記憶が受動的な検索から能動的なコンテキストへと変わる仕組み

長期記憶の難しさは、チャットの記録を保存することではなく、次にタスクが発生したときに、システムが少量の、関連性のある、そしてまだ有効な内容を見つけ出せるかどうかにあります。全量を読み込むと、すぐにコンテキストウィンドウを占有してしまいます。人が能動的に検索するだけでは、「記憶を調べることを忘れない」という新たな人的負担が生じます。

記憶に何を保存するか

筆者のシステムは、決定、ブロッカー、procedure、事実、セッション結果を保存し、それらを MR、issue、epic、関数、その他のコードエンティティに関連付けます。1 回の作業が終わった後、システムが残すべきものは「完了しました」という事実だけではありません。なぜこの方針を選んだのか、どの条件がまだ満たされていないのか、次回のセッションはどこから続けるべきか、どのようなエラーが今後停止をトリガーすべきか、といった情報も必要です。

原文の公開時点で、筆者はグラフが 76 万以上のコードエンティティ、1 万 5 千の記憶、2 万 7 千の関係を含んでいたと述べています。これは個人システムの公開時点でのスナップショットです。公開リポジトリでその機能とアーキテクチャを確認することはできますが、当時のデータベース規模を独自に再現することはできません。

正確なエンティティと曖昧な経験が、どう同時に見つかるのか

opencode-memory はハイブリッド検索を採用しています。MR 番号、関数名、エラー文字列など、安定した形式を持つ情報は全文検索に適しています。「前回なぜこの方式を採用しなかったのか」といった表現が変わる質問には、意味的類似性による補足が必要です。キーワード検索は正確なエンティティがベクトル近似に埋もれないことを保証し、ベクトル検索は異なる表現でも同じ決定にたどり着く可能性を高めます。

現在の公開実装では、テキストと構造化された状態は FTS5 を備えた SQLite に置かれ、ベクトルインデックスは LanceDB に置かれています。新しい記憶はまず即座に永続化され、embedding はバックグラウンドタスクによって非同期に計算されます。この役割分担により、書き込みパスが短縮され、まだベクトル化が完了していない記憶も、正確な検索によって先に現れることが可能になります。公開実装はまた、記憶の経過時間を表示し、GitLab エンティティに関連付けることで、セッションが結果の陳腐化を判断するのに役立ちます。

能動的なリコールから呼び出し前注入へ

最初のバージョンのベクトル検索は、筆者がその日のうちに使い始めるほどでしたが、それでもエージェントが明示的に recall を呼び出す必要がありました。セッションが「ここに履歴があるかもしれない」と認識しない限り、記憶庫は存在しないも同然です。筆者は後に、能動的なコンテキスト注入を追加しました。モデルとのやり取りのたびに、システムが現在のリクエストとエンティティに基づいて候補となる記憶を自動検索し、関連する結果をコンテキストに入れます。

特定の MR に言及すると、関連する決定とブロックが自動的に現れます。コメントを書こうとすると、コメント規範が自動的にそこにあります。ある種の繰り返し作業を始めると、対応する procedure が呼び出されます。能動的注入は、記憶を、呼び出しを待つツールから、リクエスト処理パイプラインの一部へと変えました。

筆者は、30 日間の内部記録において、関連コンテキストの能動的提示の有効率が約 91% だったと述べています。能動的注入を有効にしたセッションでは、明示的な recall の平均回数が 0 回だったのに対し、無効なセッションでは平均 17 回でした。原文にはサンプルサイズ、有効性のラベル付けルール、その他の制御変数が示されておらず、この数字は彼の個人システムを説明するものに過ぎません。それでも、測定対象が何であるかは明確に示しています。能動的注入が減らすのは、セッションが記憶ツールを発見して呼び出す回数であり、コード品質が 91% 向上したという意味ではありません。

残った失敗が、boot gate を生み出しました。システムは起動コンテキストに極めて短い強制トリガーを保持し、エージェントが実行前に一時停止して重要な指示を読み込むことを要求します。能動的検索は「関連性がありそうな」コンテンツを探し、boot gate は「必ず発生すべき」起動アクションを保証します。この 2 つは、関連性と強制実行をそれぞれ扱います。

能動的注入は、新たなガバナンス要件も導入します。古い決定は無効になっている可能性があり、意味的類似性は単なる語彙の近さである可能性があり、プロジェクトをまたぐ記憶には権限の境界も関わります。そのため、各記憶には出典、時間、エンティティのスコープ、無効状態が必要であり、検索結果には数の制限と関連性の閾値が必要です。記憶システムの品質は、誤ったコンテキストを拒否できるかどうかにかかっており、どれだけ多くのコンテンツを保存したかだけではありません。

ローカル記憶と GitLab Orbit の役割分担も異なります。ローカル層は、セッションレベルの決定、ブロック、procedure、低遅延のコード検索を扱います。一方、Orbit は、プロジェクト、ユーザー、MR、パイプライン、作業項目、セキュリティ検出結果、ソースコードを、SDLC を横断するプロパティグラフとして整理し、「サービス変更が何に影響するか」「どの MR が特定のファイルを変更したか」といったオブジェクト横断的な質問に答えることができます。GitLab は現在、Orbit を Beta と位置づけ、前回のインデックスサイクルに基づく分析スナップショットを提供するものであり、リアルタイムのトランザクションには使用されないと説明しています。タスクの claim は、引き続き共有状態システムによって行われなければなりません。

procedure、ツール、「先に調べてから作る」がそれぞれ解決すること

指示、procedure、ツールはしばしば混同されますが、筆者のワークフローではこれらを明確に3つの階層として整理しています。指示は行動の境界を定めるもので、例えばコメントを公開する前にユーザー ID の確認を必須とするといったことです。procedure は反復タスクの完全な手順を定義します。ツールは、安定したデータ読み取り、ページング、フィールド選択、機械的な変換を担当します。

筆者は優先度の高い epic を追跡する際、週報をゼロからのプロンプトで作成することはありません。procedure はまず GitLab から現在の状態を取得し、先週のスナップショットを読み込み、1週間の変化を計算してから、進捗指標を含む更新ドラフトを生成します。データソース、比較基準、出力構造が固定されているため、どのセッションでも同じプロセスを実行できます。異常な変化に説明が必要かどうか、最終的な表現が正確かどうかの判断は、依然として人間の役割です。

プロセス内のデータ収集方法が十分に安定すると、筆者はそれをAPI、OpenCode GitLabプラグイン、ローカルMCPサービスへとさらに移行します。また、自身のAI開発のために、GitLabにgroup uploads APIとMRワークフロー関連のGraphQL mutationを追加した経緯もあります。モデルが構造化された結果を返すツールを直接呼び出せば、毎回エンドポイントを調査したり、ページングを処理したり、フィールドの関係を推測したりする手間が省け、コンテキストウィンドウを比較、説明、意思決定に充てることができます。

3つの階層は、失敗の仕方によって区別できます。

ツールが安価になったことには、逆の効果もあります。アイデアから実行可能なプロトタイプまでの期間が1週間で済む可能性がある一方、車輪の再発明にかかるコストも下がったのです。筆者がAIプログラミング用の記憶システムを調査したところ、類似したソリューションが多数見つかり、別のベクトルデータベースを使用する同名のPyPIパッケージもすでに存在していました。自身のシステムは初期段階では既存プロジェクトに勝る点はほとんどありませんでしたが、数か月にわたる開発とGitLabへの深い統合を経て、独立して維持する明確な理由がようやく見つかりました。

したがって、開発を始める前の最初のステップは、既存のソリューションを調査することです。プロジェクトが要件の大部分をすでに満たしている場合、近似したコピーをゼロから作るよりも、不足している機能を貢献する方が効果的です。Havenga氏はOpenCode GitLabプラグインへの変更をアップストリームに貢献することを選択しました。これは、より多くのユーザーがその恩恵を受けられるためです。AIは実装を加速しますが、依存関係の評価、メンテナンスコスト、エコシステムとの協調という重要性をなくすわけではありません。

筆者はこの持続的な投資を、ツール自体の最適化と呼んでいます。優れたAPIやMCPツールは日常の効率を高め、その結果生まれた時間を作業フローの改善に充てることで、複利効果が生まれます。原文の最後で、記憶システムが1か月足らずで143回のコミットに達したと述べています。この数字は品質を証明するものではありませんが、ツールとプロセスが依然として急速に進化しており、静的な「最適設定」はすぐに時代遅れになることを示しています。

AIはコードを修正できても、システムレベルのエラーを発見するのは人間の役割

エージェントは、procedure がコンテキストに入っている場合、多くの反復的なステップを安定して実行できます。また、人間が明確な改善指示を与えれば、実装の修正やテストの追加も迅速に行えます。困難が生じるのは、プログラム自体が疑わしい場合です。

モデルは通常、プロセスが扱いにくいと自発的に感じることはなく、「今週すでに3回同じ問題が発生している」と気づくこともほとんどありません。現在のタスクは完了できるかもしれませんが、複数の部分的な失敗を単一のシステム上の欠陥として認識することはないでしょう。長期的に本番システムに関わってきた人間は、摩擦、繰り返し、異常な組み合わせからパターンを発見します。これらのシグナルがタスクの説明に完全に書かれていることは稀です。

Havenga氏は、AIが自身のツールに並行処理のバグを導入するのを目撃しました。局所的なコードは動作するものの、同期操作がツール全体をブロックしていました。エージェントは自身が採用した並行処理モデルにアーキテクチャ上の問題があることに気づかず、割り当てられたタスクをそのまま実行し続けていました。人間が適切な非同期パターンを指摘すると、エージェントは数分で修正を完了しました。

この事例は、人間とAIの役割分担を2つの異なるレベルに分けています。

• エージェントは、与えられた目標と制約の中で修正を実行し、テストを実施し、迅速に反復することに長けています。
• 人間は、現在の目標が正しいか、アーキテクチャが妥当か、部分的な成功がシステム全体の問題を生んでいないかを判断する責任があります。
• エージェントは明確なフィードバックに基づいて自身の指示を改善できますが、どのような反復的な失敗を新しいルールに昇格させるべきかを発見するのは人間の役割です。
• マージ前の人間によるレビューは、テストが通るかどうかだけでなく、正確性、設計品質、長期的な安定性もチェックします。

筆者は「コードがコモディティ化している」という表現で、この価値の移行を示しています。コード生成の限界費用が下がるにつれ、エンジニアリングの価値は、どのコードが存在すべきかを決定すること、ソリューションが根本的に成り立たない場合を認識すること、非効率なパターンを早期に発見すること、そして生の実行能力に方向性を与えることに、より集中するようになります。モデルは良い決定も悪い決定も増幅します。実行が速いほど、誤った方向への蓄積も速くなります。

これは、自動レビューが人間による保証を完全に置き換えられない理由も説明しています。モデルは多くの局所的な問題を発見できますが、目標やアーキテクチャの観点から存在すべきではない実装を受け入れてしまう可能性があります。人間のコントロールポイントは、タスクの選択と設計の段階に前倒しされ、最終マージの前にも残されなければなりません。

ツールは急速に陳腐化するが、判断力とフィードバックループは残る

筆者は数か月の間に、自身の日常の働き方を何度も変更しました。もともとGitLabのCREDITバリューがAIにどのように適用されるかについてのガイドを作成していましたが、その後GitLab Act 2がCREDITをエージェント時代向けの新しい原則に置き換えたため、まだ完成していなかったガイドはすでに時代遅れになりました。この例は、特定のツールに基づいて永続的なプロセスを固定化することが現実的でないことを示しています。

変化の中でも比較的安定しているのはフィードバックループです。繰り返される摩擦を観察し、障害を指示や procedure に変換します。確定的なデータ操作をツール化します。実際の作業で、それらがコンテキストの再構築や競合を減らすかどうかを検証します。副作用を発見したらコントロール面を修正します。筆者の記憶システムは MCP 上に構築されているため、OpenCode、Claude CLI、Cursor、その他このプロトコルをサポートするエージェントで利用できます。クライアントは変化しますが、永続状態、タスクの claim、検索可能な procedure は共有レイヤーに残すことができます。

GitLab の同僚の中には、このワークフローの変種をすでに採用し始めている人もおり、メモリプラグインがセッション体験を改善したというフィードバックも寄せられています。これらのフィードバックはチームレベルの生産性実験を構成するものではありませんが、筆者以外の人もこの仕組みを利用できることを示しています。チームに移行する際には、個人システムに暗黙のうちに存在する前提を明示する必要があります。誰が共有メモリに書き込めるのか、どの決定に承認が必要なのか、claim はどのように期限切れになるのか、機密コンテキストをどのように分離するか、古い procedure を誰がレビューするのか、そして手戻りや競合が実際に減少しているかをどのような指標で判断するのか。これらは筆者の実践からさらに導き出されたチームガバナンスの問題であり、原文で検証済みの結果ではありません。

問題も変化します。初期の問いは「AIに特定のアクションを実行させるにはどうすればよいか」でした。コンテキストシステムが確立されると、問いは「実行前に十分かつ正確な情報をどのように取得させるか」に変わります。優先順位、履歴、ルール、ツールがすべて自動的に揃うと、今度は人間自身がレビューと意思決定のボトルネックになる可能性があります。チームは、どの判断をより早期に標準化できるか、どの決定について人間が引き続き責任を負わなければならないかを検討する必要があります。

Havenga 氏のワークフローは、そのまま複製できる最終的なテンプレートを提供するものではありません。それが提供するのは、実際の障害から生まれた工学的方法論です。状態管理で並行作業を実現し、メモリでセッションをまたぐ決定を保存し、procedure で反復プロセスを固定化し、ツールで機械的なコンテキストコストを削減し、そして人間がシステム自体の問題を継続的に観察する。エージェントの能力は変化し続けるでしょうが、障害、制約、実行、フィードバックというこのループは今後も有効です。