Harness、Augment Code資産を取得し、コーディングエージェントとソフトウェアデリバリーを接続

コード変更を書くことはますます容易になっています。その変更をテストし、レビューし、セキュリティを確保し、顧客に対して安定的に稼働させることは依然としてはるかに大きな作業です。Harnessは、AIソフトウェア開発の次なる進歩はこの二つの領域を結びつけることから生まれると見込んでいます。

10月8日、HarnessはCosmos、Auggie CLI、Code Context Engineおよび関連技術を含む選択されたAugment Code資産を取得したと発表しました。これらの製品を開発したチームはHarnessに加わります。CosmosはHarness Cosmos Software Factory Agentとなり、変更がデプロイパイプラインに到達する前のエンジニアリング作業まで、同社のソフトウェアデリバリープラットフォームを拡張します。

この区別は重要です。これはAugment Code全社の買収ではなく、選択された資産とそれに付随するチームの取得です。その意義は、コードベースを理解し変更できるエージェントと、コードがテスト、リリース、運用される方法を把握するシステムが組み合わさる点にあります。

Harnessがプラットフォームにもたらすもの

この発表により、Cosmosはますます自律的になるソフトウェア開発ライフサイクル（SDLC）の出発点として位置付けられます。要件や割り当てられたチケット、報告されたバグは、エージェントが変更を計画し、コードとテストを書き、プルリクエストを作成する協調的なワークフローを開始するきっかけとなります。エンジニアは設計の承認や最終的なマージ決定など、判断が必要なポイントで関与し続けます。

これは単に初期パッチを生成するだけにとどまりません。レビューアがコメントを残したりチェックが失敗した場合でも、Cosmosエージェントは同じプルリクエスト上で作業を続行できます。Project Builder、PR Author、Deep Reviewer、PR Fixerなどの事前構築されたエキスパートは、チームが自分たちのリポジトリや標準に合わせてカスタマイズできるワークフローを提供します。

各エージェントは隔離された仮想マシン内で動作します。モデルルーティングやGitHub、Jira、Slackとの統合、共有メモリ、バージョニング、予算管理が、エンジニアリング組織全体でその作業を実行するための基盤を提供します。

この組み合わせこそがソフトウェアファクトリーの概念です。作業をレビュー可能な成果へと導く繰り返し可能なプロセスです。重要なのはエージェントが生成したコード行数ではなく、証拠とチェックポイントを伴う完了したエンジニアリングワークフローです。

チャットウィンドウを超えたCosmosの動作

AugmentのCosmos製品ページはその運用モデルに関する有用な詳細を追加します。プルリクエスト、アラート、スケジュール、ウェブフックが専門エキスパートを起動できます。チームはこれらのトリガーに対して環境、統合、人間のチェックポイントを定義し、各イベントごとに手動で新たなプロンプトを発行することなく作業を開始できます。

Cosmosはエキスパートとイベント駆動型ワークフローをバージョン管理されたYAMLとして定義し、Auggie CLIを通じて変更を適用し、Gitで設定履歴を管理することもサポートします。これにより、エージェントのワークフロー自体をチームが慣れ親しんだエンジニアリング手法で検査・変更できるようになります。製品ページでは、これらの制御とともに共有組織知識と支出上限についても説明しています。

開発チームにとって、これは調整の課題を変えるものです。割り当てられたチケットに応答するエージェントは、明確に範囲が定められた目的、適切なツールへのアクセス、結果を報告する場所が必要です。チェック失敗でトリガーされるエージェントは、失敗の証拠と該当ファイルを変更する許可が求められます。再利用可能なワークフローはこれらの要件をコード化できますが、その有効性は組織がどれだけ慎重に設定するかに依存します。

Code Context Engineは取引の中心的要素

エンタープライズソフトウェアで作業するエージェントは、流暢なコード生成だけでは解決できない問題、すなわち適切なコンテキストの特定に直面します。リポジトリには複数のサービスや廃止された実装、ローカルな慣習、依存関係が含まれ、単一のファイルからは推測しにくいことがあります。

AugmentのCode Context Engineに関する説明によると、システムはコードを意味的にインデックスし、タスクに関連する情報を取得します。リポジトリやサービス間の関係、コミット履歴、コードベースのパターン、ドキュメントやチケットといった補助資料を活用します。リポジトリ全体をプロンプトに入れるのではなく、関連するコンテキストを順位付けし選別します。

実用的な価値は例を通じて理解しやすくなります。支払いエンドポイントの変更要求は、バリデーションや下流サービス、ウェブフックハンドラ、テストにも影響する可能性があります。これらの関連を取得することで、エージェントはエンドポイントファイルだけに比べてより適切な出発点を得られます。これは技術が対象とする課題の例示であり、すべての影響を受ける依存関係が必ず見つかるという保証ではありません。

Harnessはこのコンテキスト機能と、それを活用するツールを同時に取得しています。より大きな機会は、コードが何をするかという知識と、リポジトリを離れた後に何が起こるかという証拠とを結びつけることです。

リポジトリと稼働中システムの接続

Harnessはすでにライフサイクルのデリバリ側で運用されています。エージェントはソフトウェアデリバリ、セキュリティテスト、ランタイム保護、コスト管理をカバーします。この買収により、Cosmosが準備したエンジニアリング作業がそれらの下流ワークフローへと移行する道が開かれます。

同社のSoftware Delivery Knowledge Graphは、Git、CI/CD、クラウドインフラ、セキュリティ、運用ツールからの情報を接続するよう設計されています。Harnessは、構造化されたリレーションシップ、標準的なアイデンティティ、アクセスフィルタリングを備えたセマンティックレイヤーと説明しています。実用的な例として、リポジトリ、Kubernetes、監視システム間で同一サービスの異なる名前を解決することが挙げられます。

このアイデンティティ問題は重要です。デプロイされたサービスに関連付けられた脆弱性の検出は、関連するアーティファクトやコードバージョンに遡って追跡できるとより有用です。テストの失敗は、実際にレビュー中の変更と結び付けられる必要があります。ログを増やすだけでは、これらの関係が自動的に確立されるわけではありません。

同社の買収発表において、HarnessはCode Context EngineとSoftware Delivery Knowledge Graphを接続することを計画された次のステップとして説明しています。意図されたフィードバックループは、下流の検出結果をエンジニアリングワークフローに戻し、エージェントが修正を作成して再度検証に通すことができるようにします。読者は、この統合の方向性が、統合されたワークフローのすべての部分がすでに提供されているという主張と同一視しないように注意すべきです。

自律性には依然としてリリース判断が必要

提案されたループは、よくあるエンジニアリングの負荷源である「問題の再構築」と「ツール間でのコンテキストの引き継ぎ」を削減できる可能性があります。テストでリグレッションが検出された場合、有用なアウトプットは失敗したチェックに結び付けられた修正と、その修正が機能することを示す証拠です。その証拠なしに別のプルリクエストを開くことは、単にボトルネックを移動させるだけです。

人間による監視はアーキテクチャの一部として残ります。アイソレーションは実行環境を制限しますが、パッチが正しいことを保証するものではありません。テスト、コードレビュー、セキュリティチェック、明示的な承認境界はそれぞれ異なる目的を果たします。緑色のテストスイートでも要件を見逃すことがあり、技術的に有効な変更でも特定のリリースには不適切な場合があります。

統合プラットフォームを評価する顧客にとって重要になる指標は、提案された変更がレビューを通過する頻度、必要となる再作業の量、リリース後の信頼性がどう変化するかです。パッチ作成にかかる時間の節約は、検証に要する時間と比較して評価されるべきです。これらは評価基準であり、買収発表で示されたパフォーマンス結果ではありません。

アイデアから本番までの全プロセスへの賭け

HarnessはCosmosが現在利用可能であり、顧客は好みのコーディングツールを引き続き使用できると述べています。これにより、組織はソフトウェアファクトリーワークフローを選択的に採用でき、買収が開発環境全体の置き換えを要求するものではないことが示唆されます。

戦略的な賭けは明確です。コード生成が日常的な機能になるにつれ、ソフトウェアを実用化するための意思決定（実装、レビュー、テスト、デプロイ、運用）全体でコンテキストを維持することがより難しい課題となります。Augmentのコーディング資産をHarnessに取り込むことで、同社はその分断の両側にコンポーネントを持つことになります。

最終的にこの買収が評価されるのは、これらのコンポーネントが信頼できるフィードバックループを形成できるかどうかです。プロダクションでの検出が、正しいコードに対して検証された適切な修正につながり、チームのポリシーに従ってリリースされるなら、得られる利益は単なるコーディング速度の向上を超えます。エンジニアリング作業を顧客が利用できるソフトウェアへと変換する、より優れた方法となります。