# Blitzyとエンタープライズ向け自律型ソフトウェア開発

- 番組: [Software Engineering Daily](https://ai-curator.jp/podcasts/shows/cmv3z5c1c000w5o10bjjhgahi)（Software Engineering Daily）
- 元のタイトル: Blitzy and Autonomous Software Development for Enterprise
- 配信日: 2026年10月22日
- 長さ: 51分
- 要約作成日: 2026年10月22日
- トピック: [#自律型ソフトウェア開発](https://ai-curator.jp/topics/%E8%87%AA%E5%BE%8B%E5%9E%8B%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA) [#コーディングエージェント](https://ai-curator.jp/topics/%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88) [#知識グラフ](https://ai-curator.jp/topics/%E7%9F%A5%E8%AD%98%E3%82%B0%E3%83%A9%E3%83%95) [#マルチエージェント](https://ai-curator.jp/topics/%E3%83%9E%E3%83%AB%E3%83%81%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88) [#LLM](https://ai-curator.jp/topics/LLM) [#エンタープライズ](https://ai-curator.jp/topics/%E3%82%A8%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%97%E3%83%A9%E3%82%A4%E3%82%BA)
- URL: https://ai-curator.jp/podcasts/cmvjbtc6600026v10bsaq5ao5

## 要約

Blitzy共同創業者兼CTOのSid Pardeshiが、Kevin Ballとの対談で、大規模コードベースで既存のコーディングエージェントが破綻する理由と、同社の解決策を語った回。コードベース全体を知識グラフ化し、レビュー済みの仕様から複数の専門エージェントを並列実行してPRを返す仕組みや、マルチモデル運用、行数課金、自己改善型システムへの展望が議論された。

## ポイント

- LLMの有効コンテキストは約30万トークン以下で、それを超えると知能が低下すると述べ、単一エージェントを長時間動かすと品質が落ちるのが大規模コードベースで失敗する原因だと説明している。
- Blitzyは導入時に24〜48時間かけてコードベース全体をグラフDBに構造化し、コミット履歴やagents.mdなどの知見もノードに紐づけて、エージェントがCypherクエリ等で検索できるようにしている。
- グラフDBを唯一の信頼できる情報源とし、フォルダ単位などでスコープを割り当てることで、単一の調整役に頼らず多数のエージェントを並列実行できると主張している。
- レビュー・セキュリティ・敵対的テストは標準で組み込まれ、ひとつの成果物は最大8種のモデルの検証を経る。モデル選択は社内評価に基づくタグとランク付けでエージェントが動的に行う。
- 課金は最終的なコード行数に基づくため、レビュー指摘による修正で行数が減れば請求も減る。エージェントが仕事を増やし続ける問題には、別モデルを裁定役に使って対処する。
- 今後は性能指標などの目標を与えて継続的に自己改善するシステムを見据え、コードレビューが不要になるという見方は企業では非現実的だと述べている。

## 章立て

- [01:06] **Blitzyの概要と差別化** — Sidの経歴と、Claude Codeなどと異なりエンタープライズ専用で、仕様から一発でPRを返す自律型プラットフォームである点が語られる。
- [06:23] **エンタープライズ特有の難しさ** — 規模・標準・セキュリティ要件が趣味のプロジェクトと根本的に異なり、既存パターンを見つけて正しく使うことが難題だと説明する。
- [09:22] **コンテキスト限界とグラフDB** — 有効コンテキストの限界を説明し、コードベース全体をグラフDBで構造化する手法と、エージェントによるクエリを紹介する。
- [16:45] **メモリと並列エージェント群** — コミット履歴等の学習をグラフに統合する方法と、調整役に頼らず並列実行する仕組み、同期・レビュー・セキュリティ工程を扱う。
- [28:20] **人間の理解維持と修正プロセス** — ナレッジベースや文書化、テスト追加の段階的導入、Refine PRと行数課金による修正の扱いを説明する。
- [35:25] **収束問題とマルチモデル運用** — エージェントが指摘を増やし続ける問題を別モデルの裁定で抑える方法と、評価に基づく動的モデル選択を述べる。
- [42:00] **Sandboxと今後の展望** — 従業員250人超の企業向けSandboxプランを紹介し、自己改善システム、運用データ連携、LLM時代のセキュリティへの見解で締める。

## 解説記事

企業のコードベースは数十万〜数千万行に及び、既存パターンから外れた変更はセキュリティや運用上の高いコストにつながる。今回のSoftware Engineering Dailyでは、Blitzy共同創業者兼CTOのSid Pardeshi（元NVIDIA）が、Kevin Ballの聞き手のもと、なぜ大規模コードベースでコーディングエージェントが行き詰まるのか、Blitzyはどう対処しているのかを語った。なお本エピソードはBlitzyのスポンサー回であり、以下は同氏の主張として読む必要がある。

#### エンタープライズに絞る理由

Pardeshiは、Claude CodeやCodex、Devinなどが人間から切り出した小さな作業を受ける道具であるのに対し、Blitzyはエンタープライズ専用だと位置づける。企業の作業の約8割は、設計者やアーキテクトのレビューを経て受け入れ基準まで決まっている「定義済みの仕事」だという。既存ツールはエンジニアの働き方を変えたが、プロンプト調整やモデル乗り換え、エージェントの見守りは依然として必要だと述べる。Blitzyは仕様を渡してビルドを押せば、PRが返ってくる体験を目指す。顧客の実績として、本番到達までの時間を約80%削減できたと紹介している。残りの20%はアクセス権限や未対応の連携、社内プロセスによるものだという。

#### コンテキスト限界とグラフDB

技術的な核心は、コンテキストウィンドウの限界である。Pardeshiは、100万トークンのコンテキストは約10万行に相当するが、実際に有効に使えるのは30万トークン未満で、それを超えると知能が劣化すると主張する。そのため単一エージェントを長時間走らせるほど品質が落ちるという。

同社はこれに対し、導入時の24〜48時間の事前処理で、コードベースの構造、各ファイルの役割、機能の所在をグラフデータベースに写し取る。grep系の検索ではノイズが多く、廃止予定と明記されていない古いコードも混じるため、実際にビルド・実行して使われているコードを把握するという。エージェントはグラフのスキーマを理解し、Cypherクエリやサマリーの埋め込み検索でグラフをたどる。コミット履歴から得た学習や、agents.mdなど顧客のルールも、別々のグラフではなく同じグラフのノードに紐づける。新旧パターンが混在する場合は、新しさを重みづけして古い慣習を避けるとしている。

#### 調整役なしの並列エージェントと検証工程

もう一つの特徴が、グラフを唯一の情報源として多数のエージェントを並列に動かす方式だ。ディスクはポッドの破棄で消え、Gitはコミット履歴を汚すため、状態管理にはグラフを使うという。たとえばフォルダ単位でエージェントにスコープを割り当てられ、理論上の上限は計算資源次第だと述べる。代償として、すべての作業がグラフに結びつく設計になる。

進捗の実体はSCM（ソース管理）にコミットし、ワークフローはグラフ上で追跡するため、途中で停止しても両者を突き合わせて再開できる。コードレビュー、セキュリティレビュー、敵対的テストは依頼しなくても標準で走り、スコープ外の発見事項は「プロジェクトガイド」に記録される。最終的なPRレビュー体験では、数百ファイルのうち重要な約50ファイルに絞って確認できるという。

#### 修正、課金、モデル選択

レビューで問題が見つかった場合は「Refine PR」で、グラフとSCMの履歴を保ったまま作業を再開する。課金は最終的なコード行数に基づくため、指摘で不要なコメントなどが削られれば請求も減る。Pardeshiは、これがトークン消費への企業の不安に合った方式だと述べる。

エージェントが「もう一つ指摘」を延々と足していく収束問題には、プロンプト調整ではなく別モデルを裁定役にすることで対応するという。コンテキストを使い切ったモデルより、実行計画だけを見るモデルの方がスコープ判断に向くという見方だ。成果物は最大8種のモデルに検証され、選択は社内ベンチマークをタグ化したランク表に基づき、エージェントが複雑度や速度を見て動的に決める。ラボの宣伝文句には頼らないと強調している。

#### 人間の理解と将来像

人間のメンタルモデルの維持については、ナレッジベース（コードの生きたドキュメント）に加え、まず文書化、次にテスト追加、その後で大規模案件へ進む「crawl-walk-run」を勧める。レガシーコードの検証にはテストが有効で、COBOLを扱う古参アーキテクトに理解を確認してもらう場面が最も喜ばれるという。

将来像として、コードレビューが消えるという見方は企業では非現実的だと一蹴する。定義済みの仕事は自律ツールに任せ、人間は探索的な仕事に集中する分業を描く。さらに、ページ表示を常に1秒未満に保つといった目標を与え、システムが日々自己改善し、必要時だけ人に確認する運用を次のフロンティアとする。LLMは脆弱性の発見を加速する一方で、混入も加速させるため、セキュリティはモデルではなくハーネス側で強制すべきだとも述べた。

#### まとめ

本回の要点は、長いコンテキストに頼るのではなく、コードベースを構造化して各エージェントが有効なコンテキストの範囲で働けるようにする、という設計思想である。グラフを共有の真実とする並列実行、複数モデルによる相互検証、成果物ベースの課金はいずれも、大規模レガシー資産を抱える日本の企業にも示唆が大きい。ただし数値や優位性は、スポンサー企業CTOの自己申告である点に注意が必要だ。自社環境での評価が欠かせない。事前に文書化とテスト整備から始めるという助言は、ツールを問わず参考になる。

> この要約・解説記事は、元の音声の文字起こしをもとに AI（Claude）が日本語で作成したものです。出典: Software Engineering Daily「Blitzy and Autonomous Software Development for Enterprise」