Augment Codeレビュー【2026年】Cosmosとは何か、料金と大規模コードの文脈理解

Augment Codeは、米国のAugment Code社が提供する開発者向けのAI基盤です。2026年10月現在、公式トップの看板は「Run your software factory」に変わり、製品名はCosmosとして案内されています。大規模なコードベースを読み解くContext Engineを中核に、PRレビュー、チケットからPR作成、脆弱性の修正、障害対応という4つの作業の流れをエージェントに任せる構成です。料金は席単位ではなく、Standardが月20ドル、Businessが月100ドル、Enterpriseが個別見積もりという3段で、いずれも50シートまでを1つの定額にまとめる形になっています。実機での操作は行っていないため、動作の速さや指摘の精度は未検証です。公開情報から読み取れる範囲で、料金の構造と向き不向きを整理します。

Augment Codeとは何か。2026年10月現在は「Cosmos」という名前で売られている

公式トップの見出しは、コード補完の話ではない。「Run your software factory」、つまりソフトウェア工場を動かすという言い方になっています。ページの副題には「Agentic software development at organizational scale」とあり、個人の入力支援ではなく、組織の開発プロセス全体をエージェントで回すという位置づけが読み取れます。以前のイメージで言えば、エディタの横で候補を出す道具ではなく、PRとチケットの流れに常駐する仕組みに寄っている、という理解になります。

Cosmosは、その工場を組み立てるための土台の名前です。公式ページでは、仕事の流れをループという単位で捉えています。PRレビュー、チケットからPRへの流れ、脆弱性の修正、障害対応の4つが代表例として並び、それぞれが次のループへ結果を渡す設計になっています。1つのループだけ回しても部分最適にしかならないというのが、この製品の主張です。

この表で目を引くのは、実行場所の選択肢です。クラウドのサンドボックスだけでなく、コードを社外に出せない案件向けに自社マシンでの実行も用意されている。金融や医療のように、リポジトリの置き場所に条件が付く現場を最初から想定していると読めます。同じ理由で、EnterpriseにはCMEK（顧客管理の暗号鍵）やデータの保管地域の指定が並んでいます。

名称の整理。Augment Code、Auggie、Cosmosは何が違うのか

公式の表記を追うと、3つの名前が混在しています。会社名と製品群の総称がAugment Code、ターミナルから使うCLIがAuggie、そしてエージェントを動かす基盤がCosmosです。料金ページの項目にも「CLI access」としてCLIが独立して並んでいるので、CosmosはCLIを置き換えるものではなく、CLIを含む上位の仕組みだと読めます。契約の単位はCosmosのワークスペースで、CLIはその入口の一つという整理になります。古い記事や比較記事では「AIコーディングアシスタント」として紹介されている場合がありますが、2026年10月現在の公式の言葉は工場とループです。用語のずれは、製品の重心が動いた痕跡だと読めます。

同じ土台の上で、Manusのような汎用エージェントと何が違うのかも気になる部分です。汎用エージェントはデスク上の作業を広く任せる発想で、Cosmosはリポジトリとチケットという開発の決まった道具立てに絞っています。絞っているぶん、レビューの観察や承認の位置を細かく決められる。守備範囲の広さより、開発の流れへの食い込みの深さを選んだ製品だと読めます。

Augment Codeの料金プラン（2026年10月現在・公式表示）

公式の料金ページは3段です。ここは数字がはっきり出ているので、そのまま並べます。いずれも「flat, no per-seat charge」、つまり席ごとの課金ではなく、チーム全体で1つの定額という言い方になっています。

金額は2026年10月27日時点の公式料金ページの表示です。表示は地域・支払い周期・為替で変わるため、契約前に公式サイトの料金表を確認してください。

3段を並べて最初に感じるのは、段の作り方が普通のSaaSと逆だという点です。多くの道具は、機能を小分けにして上の段ほど多くを開けます。CosmosのStandardとBusinessは、機能の列がほとんど同じで、違うのは含まれる利用枠の額だけ。つまり「できること」を買うのではなく「使える量」を買う設計です。機能で段を選ぶのではなく、消費の見積もりで段を選ぶ。これがこの料金表の読み方になります。

では消費はどう測るのか。公式FAQの説明では、利用はドルで測られ、モデルの推論、Context Engine、コンピュートの3つが同じ財布から出ていきます。モデルの推論は各社の公開API定価に、40パーセントの手数料を上乗せする形。コンピュートには手数料がかからないと書かれています。枠を超えた分はトップアップで足し、追加のプラン変更は要らない。トップアップの有効期間は12か月と案内されています。この構造は、為替の影響を直接受けます。ドル建ての利用枠を円で払う形になるため、為替が動けば同じ作業量でも請求額が動く。日本のチームが予算を立てる際は、この点を先に押さえておく必要があります。

無料プランの有無も書いておきます。公式の料金ページにはFreeの記載が見当たりません。少なくとも2026年10月27日現在、無料で試す入口は用意されていないと読めます。気になる道具を触らずに判断するのは難しいので、この点は導入の敷居として効いてきます。個人が試すならStandardの月20ドルが最小の入口になります。

「席課金ではない」は何を意味するのか。50シートの定額をどう読む

50シートまで定額という言い方は、人数の多いチームほど得に見えます。10人で使えば1人あたり月2ドル、30人なら1人あたり1ドルを切る計算です。ただし実際のコストは利用枠で決まるので、この比較は半分しか語っていません。20ドル分の枠を10人で分けると1人あたり2ドル分、30人で分けると0.67ドル分になる。席が増えるほど1人あたりの利用枠は薄くなるという裏返しがあります。

この表から実務的な結論が出ます。少人数で濃く使うチームと、大人数で薄く使うチームでは、同じStandardでも意味が違う。エージェントに長い処理を任せる使い方をするなら、人数を絞って枠を厚く持つほうが向いています。逆に、全員がたまにレビューを頼む程度なら、人数を広げても枠は余りやすい。席の数ではなく、1人あたり何ドル分使うかで段を決めるのが、この料金表に合った考え方です。

判断の分かれ目。Standardで足りるか、Businessに上げるか

分かれ目は利用枠の消費速度です。月20ドル分は、モデルの推論とコンピュートを合わせた額なので、エージェントにPRを何本も通させると早く減ります。逆に、レビューの指摘を読むだけの使い方なら、20ドルでも足りる場面がありそうです。差額は月80ドルなので、枠を超えてトップアップする額が80ドルを常に上回るならBusiness、下回るならStandardという単純な比較になります。2か月ほどStandardで走らせて、超過額を見てから上げる。この順序が無駄のない選び方になります。ただしトップアップにも手数料の考え方が乗るため、実際の請求は公式の利用明細で確認する必要があります。

もう一つ、この料金体系が向く組織と向かない組織があります。開発者が数十人いて、レビューとトリアージに同じ基準を適用したい組織には、定額と共有の枠は馴染みます。予算の承認も1本で済むからです。一方、3人や5人のチームで、しかも月に数回しか使わないなら、Replitのように使った分だけ払う形や、GitHub Copilotのように席単位で小さく始める形のほうが無駄が出にくい場面があります。人数の規模そのものが、この製品の向き不向きを決めます。

Context Engineは何を解決するのか。大規模リポジトリの文脈を読む仕組み

公式が繰り返し強調するのが、Context Engineの存在です。エージェントの性能は、どのモデルを呼ぶかより、そのモデルにどれだけ正確な文脈を渡せるかで決まる。この前提に立って、コードベースの理解を専門の層として切り出しています。公式の比較ページでは、複数のリポジトリを1つのセッションでまたいで読める点が、他社との違いとして書かれています。

この主張が効くのは、どんな現場でしょうか。マイクロサービスを10個以上のリポジトリに分けている構成、フロントとバックエンドとインフラの定義が別々の場所にある構成、10年選手のモノリスに手を入れる構成。こうした場所では、1ファイルの補完より、「この変更がどこに波及するか」を先に掴めるかどうかが効いてきます。変更の影響範囲を先に読めることが、大規模開発での実利になります。

ここは正直に書いておきます。文脈理解の質は、実際に自社のリポジトリを読ませてみないと分かりません。公開情報では、複数リポジトリをまたげるという設計と、共有メモリで学習が積み上がるという説明までしか追えません。この記事の判断は公開情報ベースで、精度の比較は未検証です。同じ理由で、ClaudeやChatGPT、Geminiを自分でつないでリポジトリを読ませる構成との優劣も、ここでは断定しません。汎用モデルに長い文脈を渡すやり方は自分で組めますが、組む手間と保守を引き受けるかどうかが実質的な差になります。

文脈を読む層を製品として持つことには、運用の負担も伴います。どのリポジトリを読ませるか、どのブランチを基準にするか、読ませてはいけない領域をどう除くか。これらを決めないままつなぐと、エージェントが古い枝の情報を混ぜて提案してくる場面があり得ます。公式は共有メモリで学習が積み上がると説明していますが、積み上がる内容を管理する仕事は使う側に残るという理解でおいたほうが安全です。この管理の手間は、リポジトリの数が多い組織ほど大きくなります。

向き不向きの見極め

向くのは、リポジトリが複数に分かれた組織、レビューの基準を全チームで揃えたい組織、コードを社外に出せない制約がありつつエージェントを使いたい組織です。公式が実行場所に自社マシンを用意している点は、この3つ目に直結します。向かないのは、単一の小さいリポジトリで完結する個人開発、補完の速度だけを求める使い方、そして無料で試したい段階。困りごとが「文脈が足りない」なのか「入力が面倒」なのかで、入口が変わります。前者ならContext Engineの主張が届く範囲で、後者ならエディタ型の道具のほうが近道だと考えます。

評価できる点（公開情報からの判断）

• 席課金を外した定額設計。50シートまで同じ額なので、人数の増減で予算が読みやすい
• 利用がドルで可視化される。モデル、文脈理解、コンピュートが同じ財布から出るので、費目のすり合わせが要らない
• StandardとBusinessの差が利用枠だけなので、段の選び方で迷いにくい
• 実行場所を選べる。クラウドのサンドボックスと自社マシンを併用できる
• 承認の位置を設計に組み込んでいる。人の判断を挟む場所を先に決められる
• トリガーの種類が多い。GitHub、GitLab、Slack、Linear、Jira、スケジュール、Webhookに対応する
• SOC 2 Type IIとISO 42001を掲げ、モデルの学習に顧客データを使わないと明記している

最も評価したいのは、料金の単位を「席」から「消費」に移した勇気です。AIの利用は人によって濃淡が大きく、席単位の課金はどうしても不公平が出ます。使わない人の席にも払い、使いすぎた人は別の枠を買う。Cosmosは共有の財布を1つ置いて、その中でやりくりする形にしました。開発の消費は個人ではなくチームで偏るという事実に、料金の形が合っているという見方です。

二つ目は、機能の段差を付けなかった点です。StandardでもBusinessでも、Context Engineもレビューの仕組みも使えます。安い段では重要な機能を抜く、という作り方をしていない。これは導入の判断を単純にします。Standardで始めて、足りなければ額を上げる。機能の有無を比べる作業が要らないぶん、検証に時間を回せます。

気になった点・条件付きの評価

• 無料プランが無い。触って確かめる前に月20ドルを払う判断が要る
• 40パーセントの手数料は小さくない。モデルを重くするほど効いてくる
• 文脈理解の質は未検証。複数リポジトリをまたぐ優位は、自社の構成で試さないと分からない
• 50シートを超えると個別見積もりに移る。境目が料金表の外にある
• 為替の影響を直接受ける。ドル建ての利用枠を円で払う構造になる
• 製品名と用語が動いている。Cosmos、ループ、Expert、セッションと語彙が多く、初見では全体像が掴みにくい

正直に書くと、一番引っかかったのは用語の多さです。トップページにはCosmos、ループ、Expert、Environment、Session、Advisor、Fleetと、固有の言葉が次々に出てきます。一つずつは説明されているものの、初めて読む人は「で、何を買うのか」を掴むまでに時間がかかる。製品の重心が補完から工場に移ったぶん、説明も工場の言葉になったという印象です。導入を検討する側は、用語を覚えるより先に、自社のどのループを最初に回すかを決めたほうが早いと考えます。

二つ目は手数料の考え方です。モデルの推論に40パーセントを上乗せする、という説明は分かりやすい半面、何にでも同じ率が乗るわけではありません。コンピュートには掛からないと書かれているので、エージェントを長く走らせる使い方ほど率の影響は薄まります。逆に、短いやり取りを何度も繰り返す使い方では重くのしかかる。使い方の形で実効的な手数料負担が変わる点は、契約前に見積もっておきたい部分です。この記事では具体的な請求額の試算はしません。公式の見積もりと利用明細で確認する範囲だと考えます。

三つ目は、監査の材料が料金表の外にある点です。SOC 2 Type IIやISO 42001といった表示は、導入を検討する立場では心強い材料になります。ただし、実際に社内の情報システム部門へ通すには、報告書の入手や、データの保管場所の確認が要ります。Enterpriseの列に並ぶCMEKやデータの保管地域の指定は、この確認のための項目です。統制の話は、機能の話ではなく契約の話として進める必要があります。Standardでは監査用の資料がどこまで出るかは未確認なので、この点は見積もりの段階で確認するのが確実です。

判断の分かれ目。既存の補完ツールを置き換えるか、併用するか

現場にはすでに補完の道具があるはずです。GitHub CopilotやCursor、Tabnineなど、入力の瞬間に効く道具と、Cosmosのように流れに常駐する道具は、守備範囲が重なりません。分かれ目は、困りごとの場所です。タイプ量が多いなら補完、レビューとトリアージが詰まっているならCosmos。両方が詰まっているなら、費用を分けて併用する判断もあります。同じ「AIで開発を速くする」でも、効く場所が違うという前提で予算を分けると、どちらかを諦める必要はなくなります。

CursorやGitHub Copilotとの違いは？開発AIの住み分け

比較の前に、動作の違いは実機で確かめていないと書いておきます。以下は公開情報から読める設計の違いで、優劣ではありません。各ツールの詳しい評価は、それぞれのレビューに譲ります。

この整理で見えるのは、3つが競合というより層が違うという点です。エディタ型は手元の速度を上げ、PRレビュー型は出口の品質を上げ、Cosmosはその間の流れをつなぐ。Qodoのようにテスト生成やレビューに寄せた道具とも、重なる範囲と重ならない範囲があります。どこで詰まっているかを先に測る。これが道具選びの順序として合理的です。逆に、詰まりの場所を決めずに「AI開発ツール」を横並びで比べると、料金の形が違うぶん結論が出ません。

判断の分かれ目。最初にどのループから回すか

公式ページには「Every software factory started with one loop」という一文があります。最初の1本は何か、という問いへの答えも書かれていて、レビューが最初の例として挙げられています。理由は単純で、トリガーが明快で、品質の関門として自然で、効果がマージまでの時間に出るからです。最初の1本はレビュー、その次がチケットからPRという順序が、公開情報から読める推奨の道筋になります。障害対応や脆弱性の修正は、対象が起きたときに走らせる形なので、常時回すより後から足すほうが混乱が少ないと考えます。

導入の順序も書いておきます。対象のリポジトリを1つに絞る、レビューの基準を箇条書きにする、Standardで1か月回して指摘の質と消費額を見る、基準の修正がどのくらい発生したかを数える、そのうえでBusinessに上げるか、対象リポジトリを増やすかを決める。この順序なら、金額を上げる判断を、効果の実感のあとに置ける。無料枠が無い製品だからこそ、最初の1か月で何を測るかを決めてから払うべきです。文脈の材料をNotion AIのような場所に整理しておくと、レビューの基準づくりも進めやすくなります。

よくある質問

まとめ

主な参照元：Augment Code公式サイトのトップページ・料金ページ（2026年10月27日確認）。プラン構成（Standard・Business・Enterprise）、金額、50シート、利用枠、40パーセントの手数料、トップアップの有効期間12か月は同日時点の公式表示と公式FAQにもとづく。複数リポジトリの文脈理解とCLIの位置づけは公式の比較ページ・製品ページの記載による。実機検証は未実施。