記憶喪失の天才ビクター・サフキン氏、Nxで活躍

記憶喪失の天才エンジニアを救う：AI エージェントが抱える「空間」と「時間」の壁を Nx が破る

現在の AI エージェントは、一見すると天才的なコード生成能力を持っていますが、実務現場では深刻な欠陥に直面しています。それは「限られた範囲しか見えない」という空間的制約と、「セッションごとに記憶がリセットされる」という時間的制約です。

Nx の創業者であるビクター・サフキン氏は、この二大課題を解決するメタハネス（Meta-harness）「Polygraph」を発表しました。組織全体の依存関係を可視化し、全セッションの履歴を保持することで、AI エージェントは単一リポジトリの枠を超え、過去の文脈を維持したまま複雑な開発を自律的に実行できるようになります。

天才エンジニアが抱える「狂おしい」現実

ビクター・サフキン氏は、AI エージェントを魔法のランプから現れたジンに例えます。ユーザーは「最良のエンジニア（ジョン・カーマック氏）が必要だ」と願い出ますが、ジンは安全のために制限を課します。

「カーマックはあなたのコードベースのごく一部しか見られません。おそらく全体の 1/1000 です。そして彼は以前の行動を何も覚えていません。」

この状況こそが、現在の AI エージェントの正体です。片側には圧倒的な天才性が存在する一方で、もう片側には致命的な欠陥があります。

空間的制約：リポジトリの壁に閉じ込められた視点

現在のエージェントは、一度に一つのリポジトリしか見ることができません。大規模な組織では数百から数千のリポジトリが存在しますが、AI はその一部しか把握できません。これにより、システム全体を見渡すことが不可能になります。

例えば、UI ライブラリを変更してシステム全体に波及させたい場合、以下の手順が必要になります。

1. UI リポジトリで変更を説明し、公開する。
2. 別のモジュール（例：モジュール 1）で、何が起こったかを再説明し、パッケージを更新する。
3. 互換性の問題が発生した場合、UI に戻って元の修正と問題を再度説明する。
4. モジュール 2、プラットフォームなど、他のリポジトリでも同様に説明を繰り返す。

「実質的には一つの修正に対して七つの説明が必要になります。」

各リポジトリは異なる担当者が管理していることが多く、AI はその関係性を理解していません。そのため、人間が一つずつ丁寧に説明し直す必要があり、開発効率は著しく低下します。

時間的制約：記憶喪失の連続

二つ目の問題は「記憶喪失」です。すべてのセッションは白紙の状態から始まります。AI は過去の決定や変更履歴を覚えておらず、人間がその役割を担わなければなりません。

一週間前に実施した修正でバグが発生した場合、開発者は AI に「一週間前の元の変更」と「現在発生している本番環境の問題」の両方を再度説明しなければなりません。同じことを何度も繰り返すのは、まるで狂おしい状況です。

Polygraph が解く「空間」と「時間」の壁

この課題に対し、ビクター氏は Nx で開発されたメタハネス「Polygraph」を提案します。これは特定のツールではなく、エージェントの能力を飛躍的に高めるための基盤となる概念です。

全コードベースを一つの巨大リポジトリとして見せる（空間的制約の解消）

Polygraph は、組織が所有する数千のリポジトリと、依存しているオープンソースプロジェクトを分析します。コードそのものを変更するのではなく、メタデータを抽出して統合された「依存関係グラフ」を構築します。

「エージェントに、組織全体を一つの巨大なリポジトリとして見せる錯覚を作り出します。」

これにより、AI は UI の変更がモジュール 1 やプラットフォームにどう影響するかを即座に理解できます。数百のリポジトリにまたがる変更も、あたかも単一のリポジトリで作業しているかのように扱えるようになります。

永続的な記憶と文脈の継承（時間的制約の解消）

Polygraph はすべてのセッション、決定、変更履歴を記録・関連付けます。これにより、AI は過去のコンテキストを保持し、組織全体の知識として活用可能になります。

「あるリポジトリでの作業が別のリポジトリの作業につながっていると言えますね？」

例えば、バックエンドの変更を同僚に引き継ぐ際、セッションを送信すれば、相手は自分のマシンで同じ状態から再開できます。異なるエージェント（例：Claude から Cortex へ）を使っても、過去の決定やトレース情報が共有されるため、一貫した開発が継続されます。

クロスリポジトリ開発の自動化と「群知能」の実現

Polygraph の真価は、複雑な依存関係を自動で管理できる点にあります。複数リポジトリにまたがる変更や CI（継続的インテグレーション）の協調を、単一のリポジトリ操作のように扱います。

失敗した CI を自動的に修復するロジック

複数のリポジトリで同時にプルリクエストを作成し、CI を実行します。もしモジュール 1 の CI が失敗した場合、Polygraph は原因を特定します。

「モジュール 1 にパッチが必要か、UI コンポーネント自体が壊れて互換性がないのかを判断し、その時点で全員にパッチが必要になります。」

AI は自動的に修正を行い、整合性を保ちます。開発者は「なぜ失敗したか」を説明する手間から解放され、AI に任せるだけで済みます。

曖昧な指示でも解決できるインテリジェンス

リポジトリを手動で選択する必要もありません。Polygraph はリポジトリ間の関係性に関する知見を持っているため、「特定のライブラリのバージョンに依存するすべてのリポジトリを更新して」という曖昧な指示にも対応できます。

また、過去の成功したセッションからベストプラクティスを模倣することも可能です。あるエンジニアが尊敬するアプローチを参照し、リポジトリ間で一貫性のあるコードを実現します。

「千人のエンジニアが組織のようにセッションをすべて作成し、それぞれが互いにアクセス可能になります。まるでボークスのようです。」

まとめ：AI エージェントは「群知能」として進化できる

ビクター・サフキン氏が提示した Polygraph は、AI エージェントが抱える根本的な制約を解消する画期的なアプローチです。空間的制約と時間的制約を解除することで、開発者は複数リポジトリにまたがる変更を一度の説明だけで完了できます。

「エージェントは空間と時間の制約を受けますが、これらの制限はどちらも解除可能です。」

これにより、大規模なエンタープライズ環境において、AI エージェントの実用性が飛躍的に高まります。開発者が手動で説明する回数を減らし、AI が自律的に複雑な依存関係を管理することで、ソフトウェア開発の生産性と品質が劇的に向上するでしょう。