AIエージェント時代、ソフトウェア開発基盤は「コード」ではなく「意味・存在理由・価値」を管理するーーAIエージェントの活動を、意味・存在理由・価値へ接続する企業基盤

＜２０２６年７月２２日以前のコンテンツ一覧はこちら＞

＜「Origin」から始まった議論が、版管理の問題になり、その後版に保管格納する項目の話題になり、それにEmbeddingの話が追加され、果てはレガシーシステムの話題が出てきて、こんなのを作成してもらいました。しかし、こうなるとメモリ管理とストレージコストを逼迫しそうですが。＞

1. Cursor Originが示したもの

2026年8月17日、Cursorはコードホスティング機能「Origin」を発表した。初期ベータでは、リポジトリ、Pull Request、コード閲覧、GitHub同期を提供し、Cursor自身がそれらを「agent scale」を想定した基本機能と位置付けている。さらにagent-nativeな機能を追加するとしている。

これは単に、AIコーディング企業がGitHubに似たサービスを始めたという話ではない。この設計仮説では、AIエージェントが複数並行し、人間が多数の変更候補、テスト、レビュー、修正案を受け取るようになるほど、生成速度だけでなく理解・統治速度が制約になり得る。

人間中心の開発では、Pull Requestの説明、チケット、会議、担当者の記憶が、コード差分の背後にある理由を補ってきた。エージェント規模になると、その暗黙の補助線がボトルネックになる。次の開発基盤には、変更されたコードだけでなく、何を変えたのか、なぜ変えたのか、何を守るべきか、どの価値へ影響したのかを機械可読に扱う能力が必要になる。

2. Gitの問題は「意味を書く場所がない」ことではない

Gitが保存する中心的な対象は、各時点のスナップショットと、それらを結ぶコミット履歴である。私たちが普段見るdiffは、その状態間の差を計算して表示したものだ。

もちろんGitにも意味を書く場所はある。コミットメッセージ、trailer、署名、git notes、IssueやPull Request、Architecture Decision Recordなどである。したがって「Gitは意味を保存できない」と言い切るのは正確ではない。

問題は別にある。多くの場合、その意味は自由記述であり、業務ルール、Policy、Evidence、KPI、責任主体と型付きの関係で結ばれていない。後から機械が「この変更はどの業務ルールを変えたのか」「なぜその変更が必要だったのか」「どの経営価値やリスクへ影響するのか」を確実に再構成できる保証がない。

AIエージェント時代に不足するのは、コメント欄ではない。意味を構造化し、根拠と結び付け、変更前後で検証できる台帳である。