今回の取引がカバーするものと、発表で未解決のまま残されていること
まずは買収されたものから見ていきましょう。プレスリリースで名指しされている資産は、Cosmos、Auggie CLI、Code Context Engine、および関連技術です。Cosmosの今後の役割については、「CosmosはHarness Cosmos Software Factory Agentとなり、アイデアからコードまでのエンジニアリング作業を自動化するという明確な役割を担います」と直接言及されています。また、リリースには「Harness Cosmosは現在利用可能です」とも記載されています。
リリース内の2つの記述がコンテキストに言及しています。1つ目はインデックスについてです。「AugmentのCode Context Engineはコードベースのライブマップを保持するため、変更が既存のコードに適合します。」2つ目はメモリについてです。「共有メモリは、各レビューからの教訓を次の変更へと引き継ぎます。」どちらも、今後のHarness Cosmosが提供する機能の一部として説明されています。
Harness自身のブログ投稿には、既存ユーザー向けの記述が追加されています。「顧客はHarness Cosmos Software Factory Agentを採用することも、好みのコーディングツールを使い続けることも、あるいはその両方を使用することもできます。」また、製品とチームについては、「私たちは製品、技術、そしてそれらを構築した人々への投資を行っています」と述べています。
発表資料やそのFAQで説明されていないのは、既存アカウントの移行メカニズムです。現在のワークスペース、インデックス、Expertのメモリがどのように移行されるのか、課金やデータ処理に変更があるのか、あるいはリリースで買収資産として名前が挙がっていないVS CodeやJetBrains向けのAugment拡張機能がどうなるのか、といった点です。これ自体はトラブルの兆候ではありません。公開された資料が方向性に関するものであり、既存顧客向けの運用上の詳細はHarnessおよびAugmentから直接提供される予定であることを意味しています。
このギャップがあるからこそ、今インベントリ（棚卸し）を行う価値があります。どのコンテキストが設計上ポータブル（移植可能）であるかを知るために、メールを待つ必要はありません。
リポジトリ内に存在するコンテキスト
Augmentのドキュメントでは、ルールとワークスペースガイドラインの保存場所が明確に示されています。「ワークスペースガイドラインとルールは、リポジトリに直接保存されます。」CLIのドキュメントでも、ワークスペースルールについて同様に述べられています。「ワークスペースルールはプロジェクトリポジトリに保存され、その特定のプロジェクトにのみ適用されます。」
Augmentはツールに依存しないファイルも読み込みます。そのルール階層には、.augment/rules/と並んでCLAUDE.mdやAGENTS.mdが含まれており、作業中にサブディレクトリ内のAGENTS.mdやCLAUDE.mdを検出します。チームがこれらのファイルに書き込んだ内容はすべてバージョン管理され、レビュー可能であり、他のエージェントからも読み取ることができます。これはベンダーのアカウントではなく、あなたのリポジトリに属するものです。
ローカルマシン上に存在するコンテキスト
個人の好みは、より手元に近い場所にあります。「ユーザーガイドラインはIDEにローカルで保存され、そのIDEでの今後のすべてのチャットに適用されます。」VS Codeにおいて、Augmentはファイル名を指定しています。「Visual Studio Codeでは、ユーザーごとのガイドラインファイルは~/.augment/user-guidelines.mdです。」CLIの場合、「ユーザールールはホームディレクトリに保存され、すべてのプロジェクトに適用されます。」
これらはホームディレクトリにあるプレーンなファイルです。誰もコミットしないため忘れがちですが、最も文字通りの意味であなたのものです。
Augmentのプラットフォーム上に存在するコンテキスト
残りの部分はサービス側で保持されます。インデックス作成が最も分かりやすい例です。「Augmentを有効にしてワークスペースを開くと、コードベースが自動的にAugmentの安全なクラウドにアップロードされます。」リモートのContext Engineも同様に動作します。「HTTP経由でAugmentがホストするContext Engineに接続」し、選択したリポジトリのデフォルトブランチをインデックス化します。
Cosmos Expertメモリもプラットフォーム側にあります。「メモリにより、Expertはセッションをまたいで有用なコンテキストを保持できます。スコープ定義された知識を共有仮想ファイルシステム（VFS）に保存します。」ドキュメントにはさらに、「Expertのメモリはそのチームに属し、ワークフローに適したスコープで分離されます」、「Expertは自身のVFSディレクトリ配下に読み取り可能なMarkdownとして情報を書き込みます」と記載されています。
インデックスはコードから再構築できます。しかし、Expertメモリは異なります。これは数ヶ月に及ぶレビューコメント、修正、意思決定の蓄積であり、短いメモに凝縮されたものです。これこそが、自分が管理できる形式で最も確保しておく価値のある部分です。
やりがちな代替アプローチとその落とし穴
何も変わらないと仮定する。 しばらくの間はそうかもしれません。しかし、「一部の資産」が売却されたのであり、公開された資料はCosmosの未来について述べているもので、既存の各ワークスペースの移行パスについてではありません。継続性は仮定するものではなく、確認するものとして扱いましょう。
すべてが失われると仮定する。 これも誤りです。ルール、ワークスペースガイドライン、およびAGENTS.mdファイルはリポジトリにあります。ユーザーガイドラインとユーザールールはローカルマシン上のファイルです。Augmentの挙動を決定づけるコンテキストの大部分は、最初からプラットフォーム上にはありませんでした。
インデックスをエクスポートしようとする。 インデックスはコードから生成された派生物です。コピーを保持する必要はありません。リポジトリをインデックス化するツールであれば、どれでも独自のインデックスを構築できます。
何かアクションを起こす前に移行通知を待つ。 以下に示すインベントリの作成は半日もあれば完了し、Harnessが次に何を発表しようとも（Cosmosを新しい名前で使い続ける場合であっても）役立ちます。
すべてを特定のベンダーのルール形式に移行する。 後で他のツールを評価する場合、.augment/rules/を翻訳する必要があります。ツールに依存しないファイルの方が汎用性が高く、Augment CodeからCursorへの移行に関するメモで詳しく説明されている通りです。
解決策：Augmentコンテキストを保存場所ごとに整理し、ポータブルなレイヤーを完成させる
ステップ1：チームのAugmentコンテキストが存在するすべての場所をリストアップする
リポジトリごと、および個人ごとに簡単なリストを作成します。
各リポジトリで、.augment/rules/、.augment-guidelines、AGENTS.md、CLAUDE.md（サブディレクトリ内のネストされたコピーを含む）を確認します。Augmentのフロントマターがワークスペースルールの適用タイミングを制御しているため、どのルールが常に適用され、どのルールが条件付きであるかをメモしておきます。
各開発者のマシンで、~/.augment/rules/を確認し、VS Codeユーザーの場合は~/.augment/user-guidelines.mdを確認します。JetBrainsユーザーはIDEの設定を確認する必要があります。Augmentは、ガイドラインについて「VSCodeで定義されたものはJetBrains IDEに伝播せず、その逆も同様です」と指摘しているためです。
プラットフォーム側では、CosmosのExpertをリストアップし、どれがメモリを有効にしているか、それぞれがどのスコープを使用しているかを記録します。Augmentのドキュメントには「メモリはすべてのテンプレートExpertで有効になっています」とあるため、テンプレートを使用している場合はメモリが蓄積されていると仮定してください。そのメモリを意図的にチューニングしてきた場合は、AugmentのCosmos Expertがフィードバックから学習する内容をコントロールするで説明されている設定を記録しておきます。
最後に、どのリポジトリがリモートのContext Engineに接続されているか、およびどのマシンがAuggie CLIを介してローカルサーバーを実行しているかをメモします。
ステップ2：読み取りやすいうちに、Expertが学習した内容を書き留める
ExpertメモリはMarkdownとして保存されており、インタラクティブセッション中、Expertは「何かを記憶したときにそれを通知するため、修正や拒否を行うことができます」。これにより、内容をレビューすることが可能です。各Expertおよびリポジトリスコープについて、記憶されたガイダンスに目を通してください。
その後、それを整理します。一部は、命名規則、レビュー基準、テスト実行なしでは絶対にアップグレードしてはならない依存関係、特定のテーブルを所有するサービスなど、永続的なチームの知識です。一部はノイズであったり、すでに古くなっていたりするでしょう。
永続的な項目は、自分の言葉でリポジトリに移動します。短いAGENTS.mdセクションやワークスペースルールで十分です。Augment自身のガイダンスもこの切り分けを支持しています。「明示的なワークフローにはスキルやExpertの指示を使用し、継続的な作業を通じて学習したコンテキストにはメモリを使用します。」学習した教訓が有効であると証明されたら、コードとともに存在する明示的な指示にするべきです。
個人のコンテキストについても同様に行います。開発者のユーザーガイドラインに、個人の好みではなくチームの規約が含まれている場合は、その規約をリポジトリに移動し、その人やそのノートPCが離れたときに失われないようにします。この引き継ぎの一般的な方法については、メンバーが離職する際にチームのAIコンテキストを維持する方法で説明しています。
ステップ3：ルールレイヤーを複数のツールから読み取り可能な状態に保つ
AugmentはAGENTS.mdとCLAUDE.mdを階層的に読み込むため便利です。共有の規約をこれらのファイルに配置しておけば、Augmentで機能し続けながら、他のエージェントからも読み取ることができます。.augment/rules/は、フロントマターによる条件付き適用など、真にAugmentの機能に依存するもののために予約しておきます。
ファイルが実際に読み込まれているか確認してください。Augment의ドキュメントには、見落としがちなスコープの詳細が記載されています。「.augment/rules/内のファイルはワークスペースのルートからのみロードされ、サブディレクトリからはロードされません。」ネストされたコンテキストは、代わりにネストされたAGENTS.mdファイルに配置する必要があります。より広くは、AIエージェントが作成した指示ファイルを無視する理由で、チームがつまずきやすいロードルールを解説しています。
もしあなたのチームがClaude CodeからAugmentに移行してきたのであれば、Claude CodeからAugment Codeへの移行にある逆のマッピングが便利なチェックリストになります。移行時に翻訳したものはすべて、移行して戻す際にも翻訳することになります。
MemoryLakeでの設定方法
ステップ2と3で、チームの知識をリポジトリに移動します。しかし、一部のコンテキストはそこには収まりません。複数のリポジトリにまたがる意思決定、規約の背景にある理由、あるプロジェクトから次のプロジェクトに適用できる教訓、そして使用するすべてのツールで適用したい個人の作業設定などです。MemoryLakeは、今期どのベンダーがあなたのコーディングエージェントを所有しているかに関係なく、そのレイヤーを保持するための場所です。
エントリーはあなた自身が自分の言葉で書き込みます。Augment、Harness、あなたのリポジトリ、またはベンダーのストレージから読み取られたり、書き込まれたり、削除されたりすることは一切ありません。勤務先のコードや意思決定に関する情報を追加する前に、組織のポリシーを確認してください。
ステップ1：APIキーを作成する
サインインし、ダッシュボードからキーを生成します。このキーは、AugmentやHarnessのアカウントとは無関係に、あなたのMemoryLakeワークスペースに属します。
ステップ2：最初のメモリをアップロードする
ステップ2でExpertメモリから整理した、リポジトリをまたぐ教訓や、特定のコードベースに依存しない個人の好みから始めましょう。1つのエントリーにつき1つの意思決定または好みを、日付付きで登録します。
ステップ3：AIとエージェントを接続する
使用しているコーディングエージェントやアシスタントを接続します。これにより、Cosmosを使い続ける場合でも、別のエージェントを追加する場合でも、あるいは移行する場合でも、同じコンテキストを利用できるようになります。
実務において何が変わるのか
第1の違いは、全体像が明確になることです。すべてを区別のつかない1つの「Augmentコンテキスト」の山として扱うのではなく、どの部分がGitにあり、どの部分がノートPCにあり、どの部分がプラットフォーム上にあるのかを把握できます。
第2に、プラットフォーム側で保持される部分が本来あるべき規模に縮小します。インデックスはコードから再構築されます。Expertメモリは引き続きその役割を果たしますが、最も重要な教訓はリポジトリ内のレビュー済みテキストとしても存在することになります。
第3に、選択肢（オプショナリティ）が得られます。Harness Cosmosを採用するにしても、進化するAugmentのツールを使い続けるにしても、あるいは他のツールを評価するにしても、ルールは一緒に移動します。コンテキストをポータブルに保つべき広範な議論については、AIのメモリは機能か、それともロックインかで詳しく説明されています。
第4に、どのようなものであれ、次の変化に対する回復力（レジリエンス）が高まります。この分野において、買収、名称変更、価格改定は日常茶飯事です。コンテキストを自身が管理するファイルに保存しているチームは、これらを「知識の喪失イベント」ではなく、「調達に関する問題」として処理できます。
Harnessの取引後におけるAugmentチームのベストプラクティス
行動する前にインベントリを作成する。 リポジトリのルール、ローカルのガイドライン、プラットフォーム上のコンテキストを個別にリストアップします。
今すぐExpertメモリを読み込む。 Markdown形式であり、レビュー可能です。永続的な教訓はリポジトリに昇格させましょう。
共有ルールにはツールに依存しないファイルを優先する。 AGENTS.mdやCLAUDE.mdは、Augmentだけでなくそれ以外の環境でも機能します。
チームの規約を個人のガイドラインから移動する。 個人のファイルは、その人が離職する際に一緒に失われてしまいます。
インデックスを保存しようとしない。 インデックスは、使用するどのツールによってもコードから再構築されます。
アカウントの詳細は直接確認する。 プレスリリースから推測するのではなく、ワークスペース、データ処理、拡張機能についてHarnessまたはAugmentに直接問い合わせてください。
明確な基準で選択肢を比較する。 代替案を検討している場合は、エンジニアリングチームに最適なコードベースメモリツールに評価すべき項目がリストアップされています。
結論
Harnessは、Cosmos、Auggie CLI、Code Context Engine、および関連技術、そしてそれらを支えるチームを買収しました。発表では、コードコンテキストとデリバリーコンテキストが接続される未来が描かれており、既存の顧客はHarness Cosmosを採用することも、好みのツールを使い続けることも、あるいはその両方を使用することもできると述べられています。
現時点でまだ明確にされていないのは、既存のワークスペース、インデックス、Expertメモリがどのように引き継がれるかです。しかし、コンテキストを保護するためにその回答を待つ必要はありません。ルールとワークスペースガイドラインはすでにリポジトリにあります。ユーザーガイドラインとユーザールールはローカルマシン上のファイルです。インデックスは再構築可能です。今すぐ行動を起こすべき部分はExpertメモリです。それを読み、価値のあるものを残し、チームが所有するファイルに書き込んでください。
そうすれば、この買収は「チームが知っていること」に関する問題ではなく、単なる「ツール」に関する問題になります。