社内AIエージェントの導入で残る仕事Cosmosの初期設定と人の承認

Cosmosが対象にするのは、一人の開発者がAIと会話してコードを書く場面よりも、その使い方をチーム全体の仕事へ広げる段階です。Augment Codeは、企業向けのソフトウェア開発AIを提供してきた会社です。同社は現在の課題を、個人のコード作成が速くなっても、組織全体の開発が同じ割合では速くならないことだと説明しています。8

個人で使うコーディングAIなら、開発者が端末で「この不具合を直して」と頼み、表示された差分を確認できます。対象のコードや完成条件は、その人が会話の中で補います。失敗しても端末で止められ、最後に人が変更を提出するため、仕事の範囲と責任者も比較的はっきりしています。

会社が同じ仕組みを繰り返し使おうとすると、前提は別物です。たとえば「障害通知が届くたびに原因を調べる」「新しい変更が提出されるたびに安全性を点検する」「毎晩、依存ライブラリの問題を探す」といった仕事は、人の一回の依頼を待たずに始まります。担当者の端末が閉じていても動き、複数のリポジトリと社内サービスをまたぎ、調査結果をSlackやGitHubへ戻すのが組織運用です。

ここで、AIモデルの性能とは別の運用問題が増えます。

担当者ごとに別のAI、別の指示文、別の接続方法を使えば、速くなるのは個々の作業に限られます。組織側には、重複した設定、共有されない修正、増えた確認待ちが残り、誰が何を実行したかも追えなくなります。Cosmosはこの問題に対し、エージェント、コード、道具、実行環境、社内の知識、人の承認をまとめて管理する製品として作られました。8

具体的には、GitHubの変更、Slackの投稿、監視サービスの警告、時刻などを起点にエージェントを動かし、隔離した実行環境で作業させます。設定と履歴の版、チームで共有する知識、費用上限までが管理対象です。Cosmosが「AIを使ってコードを書く画面」ではなく「AIへ組織の仕事を継続して任せる仕組み」と説明される理由は、ここにあります。

今回の手元検証で使ったのは、LunaとClaude Opusに同じ導入要件を渡す比較です。Cosmos Advisor本体の操作や、外部サービスへの接続完了は試していません。以下の「10分」は提供元が説明する初期構成の目安で、知能圏が導入時間を測った結果ではありません。

Cosmosは、会社の仕事をAIエージェントへ任せるための基盤です。Cosmosでは、目的、利用するAIモデル、道具、実行環境、別のエージェントへの委任をまとめた作業単位をExpertと呼びます。たとえば、障害を調査するExpert、修正案を書くExpert、問い合わせを分類するExpertを、仕事ごとに用意できます。28

Cosmos、Expert、Advisorの関係を先に分けると、次のようになります。

AdvisorもCosmos上で動くExpertですが、利用者の業務を直接処理する役ではありません。ほかのExpertを作り、実行できる場所と起動条件を整える「設定係」です。利用者が「Slackへ届く障害通知を調べたい」と伝えると、対象のSlack、コードのあるリポジトリ、配備先、必要な道具、起動条件を質問し、実行環境と調査用Expertの構成案へ変えます。24

つまり、Cosmos Advisorは単独で何でも行う万能エージェントではありません。Cosmosという基盤の中で、「どの仕事を、どのエージェントに、どの道具と権限で任せるか」を組み立てるエージェントです。

この製品が出てきた背景には、AIエージェントの能力と、会社で実際に動かすまでの距離があります。モデルがコードやログを読めても、どのリポジトリが本番か、どの通知を処理するか、誰が変更を承認するかは知りません。導入先ごとに接続先と社内ルールが違うため、製品の機能が増えるほど初期設定が導入のボトルネックになります。

一般的なチャットAIは、人が必要な資料を貼り、質問するたびに答えを受け取る使い方です。企業向けエージェントはその先へ進み、通知をきっかけに自分で調査を始め、複数の社内サービスから情報を集め、別のエージェントへ仕事を渡します。その分、最初に決める接続、実行環境、起動条件、権限も増えます。

しかも、設定は製品ごとの共通知識だけでは完成しません。Slackとの接続方法は製品側が知っていても、どのチャンネルが障害用かは会社にしか分かりません。GitHubを読む方法は共通でも、どのリポジトリが本番か、顧客データを含むか、修正案を誰へ見せるかは組織ごとに違います。

導入作業には、二種類の知識が混ざっています。一つは、Cosmosで接続やExpertをどう設定するかという製品知識です。もう一つは、対象業務、データ、権限、承認者を決める会社固有の知識です。前者は繰り返し利用できますが、後者は顧客へ質問しなければ埋まりません。

従来、この間をつなぐのがFDEと呼ばれる技術者や導入支援者でした。FDEはForward Deployed Engineerの略で、顧客の現場へ入り、製品を社内システムへ接続し、認証、データ、手順、例外を確認しながら使える状態まで仕上げます。ソフトウェアを渡して終わるのではなく、顧客の業務へ合わせて最後の実装を担う役割です。1

ただし、顧客が増えるたびに、人が接続方法を説明し、実行環境を作り、似た確認項目を聞き直すと、製品を導入できる速度は支援できる技術者の人数に左右されます。一方ですべてを共通テンプレートへ固定すると、会社ごとの対象と権限を取り違えます。反復できる製品設定は再利用し、会社固有の答えだけを人へ聞く仕組みが必要になります。

Advisorは、この分割を製品の中で行います。Cosmosの接続、実行環境、Expert、自動起動という設定項目を知り、利用者へ不足情報を質問し、構成を作ります。稼働後は実行記録も読み、失敗の反復や人の返答待ちを見つけて調整できます。2 製品自身が自分の設定形式と運用記録を読めるため、導入支援を会話型の機能として組み込めるわけです。

ここから読み取れる製品上の狙いは、FDEを完全に不要にすることではありません。FDEが毎回行っていた製品説明と定型設定をAdvisorへ移し、人には業務範囲、認証、承認、例外の判断を残すことです。発表文の「FDEを製品の一部にした」という表現は、この役割分担を指しています。1

Augment Codeは2026年8月28日にAdvisorを発表し、会社固有の自動化を約10分で組めると説明しました。1 単独の新サービスを一から契約するというより、Cosmosを会社の仕事へ合わせる初期設定機能です。ここを押さえると、約10分で何が終わり、何が終わらないのかを分けて読めます。

公式文書が示す設定は四段階です。GitHubやSlackなどの接続を確認し、リポジトリと道具を持つ仮想マシンを作り、既成または会社固有のExpertを配置します。稼働後は実行記録を読み、失敗の反復、利用の偏り、人の返答待ちを見つけて設定を調整します。2

Advisorは外部サービスの認可画面を自分で完了できません。GitHub AppやSlackワークスペースの接続には、利用者や管理者の操作が必要です。標準外のサービスに使う認証情報も、人が秘密情報管理へ登録します。3

自動起動は初期状態で無効です。AdvisorがExpertと発火条件を作った後、利用者が実際のタスクで試し、確認してから有効にします。設定内容は通常の管理画面でも確認、修正、一時停止できます。4

発表文の約10分は、会社固有の自動化を初期構成する目安です。製品ページには「5分で稼働」という別の表現もありますが、計測の開始点、接続数、管理者承認、認証情報登録、成功条件は公開されていません。18 どちらも調達、権限審査、試験、運用改善まで含む総導入時間としては読めません。

Advisorが配置できるExpertの一つがIncident Investigatorです。これは、障害通知を受けて証拠を集め、原因分析の下書きを作る事故対応エージェントです。長く使う通知チャンネルを監視する方法と、事故ごとに作ったチャンネルへ人が呼び込む方法があります。6

Augment Codeの社内運用では、PagerDutyのアラートがSlackへ届くと調査が始まります。エージェントはログ、性能指標、直近の配備、GitHubの変更履歴、コード、担当者情報、過去の障害を照合し、根本原因分析の下書きと推奨対応をSlackのスレッドへ投稿します。根本原因分析は英語でRoot Cause Analysisと呼ばれ、原資料での略称はRCAです。5

調査には、情報へ到達する道具と認証が必要です。同社の例ではgcloudでログと性能指標を調べ、kubectlで本番クラスタのコンテナ状態、再起動、配備状況を確認します。ログの問い合わせ方や運用上の制約は、コードとして保存した手順へまとめています。5

ここには導入の便利さと危険が同時にあります。ログとコードだけでは原因を絞れない障害も、本番の状態まで読めれば調査できます。一方、同じ接続へ広い変更権限を加えると、誤った仮説が本番操作へ直結します。Cosmosの秘密情報は仮想マシンの起動時に環境変数として渡されるため、どのExpertへ何を貸すかを設定時に決める必要があります。7

原因分析の後は、経過監視、修正案の作成、ロールバック、担当チームへの引き継ぎのいずれかへ進みます。コード修正を別のExpertへ渡す前には、人の明示的な承認が必要です。人は分析の根拠を読み、追加質問をし、対応方針を決めます。最後にエージェントが解決概要と事後記録を作り、次の調査に使う知識を残します。56

Augment CodeはIncident Investigatorを五つのオンコール用チャンネルへ導入し、導入前後それぞれ一か月を比べました。対象は通常2〜5人の小規模チームです。導入前には担当者が一日5回ほど中断され、アラートの20%で経験豊富なエンジニアが呼ばれていたと説明しています。5

公開値を同じ式で再計算すると、次のようになります。

原資料は同じ図について「人手とエージェントで処理した事故の割合」「オンコール調査作業」「エージェントが処理した事故」と表現しています。件数、作業時間、工程数のどれを分母にしたかは公開資料だけでは確定できません。そのため、既存稿で使っていた「人の作業比率」という表現を「対応と分類された割合」へ改めました。5

0.4と99.6、81.3と18.7がそれぞれ100になることは確認できます。ただし、公開された丸め値の合計が合うだけです。人とエージェントが一緒に調べた事故をどちらへ入れたか、途中で人が介入した場合をどう数えたかまでは分かりません。

最初のRCAまでの時間が30.1分から6.2分へ縮んだことは、事故通知と同時に調査を始める仕組みと整合します。一方、RCAが平均的な開発者より正しいことが多いという同社の主張には、社内調査の人数、採点基準、比較結果が示されていません。5

この事例は、同じ会社の導入前後を比べた観測です。事故の件数と難しさ、手順書、監視設定、チームの習熟、同時期の製品変更は統制されていません。Cosmosだけが数値を変えたという因果や、別の会社でも同じ結果になるという再現性は確認できません。

最初のRCAまでの中央値は79.4%短くなり、解決までの中央値は32.5%短くなりました。ただし、二つの改善率の差を、そのまま人に残った復旧作業の割合とは読めません。

原資料の解決時間はtime to resolutionまたはfull thread resolutionです。サービスが復旧するまでだけを測った値とは限りません。一過性のエラーがRCA完成前に自動解消する場合があるため、解決までの時間が最初のRCAより短くなることもあると説明されています。5

それでも、調査と本番操作を分ける必要は残ります。ログを読んで原因候補を並べ、情報が足りなければ追加調査へ戻せる作業です。ロールバック、設定変更、再配備は顧客へ影響し、誤れば新しい障害を作ります。

MicrosoftのAzure SRE Agentにおける軽減策の実行は、診断、操作選択、権限確認、実行または承認、結果検証の五段階です。人が承認するReview Modeと、条件内で実行するAutonomous Modeを分け、認証情報の隔離、短期トークン、操作記録も設計要素にしています。910

AWSの事故対応ガイドも、反復的で通常型の事象を自動化し、機密性が高い独自の事故は人へ残す考え方を示します。11 これらはCosmosの効果を裏付ける独立評価ではありません。事故対応エージェントを導入するとき、調査の自動化と本番操作の許可を分ける参考です。

製品へ接続できないまま算術再計算だけで終えると、人へ何が残るのかを具体的に確かめられません。そこで、25人の架空のB2Bソフトウェア会社を設定し、同じ導入要件をこの執筆環境のLunaサブエージェントと、claude -pで起動したClaude Opusへ渡しました。

会社はGitHub、Slack、Vercelを利用しています。Slackの障害通知から関連する課題、変更履歴、配備を調べ、障害分類、根拠リンク、復旧手順案、人の承認地点をそろえるのが完了条件です。本番配備、課題の終了、外部送信は禁止し、書き込み用の認証情報は渡していません。

二つのエージェントは外部サービスへ接続せず、提示された要件だけから導入計画を作りました。生の出力と比較コードは記事付属のexperimentフォルダーへ保存しています。

質問数と工程数は大きく違いましたが、両者は同じ境界へ収束しました。Slack、GitHub、Vercelは読み取り専用から始めること。書き込み権限を分けること。対象のリポジトリや本番環境を特定できないときは止まること。本番変更と外部送信は人の確認へ戻すことです。

質問の中身も、製品が標準設定だけで決められない項目でした。対象チャンネル、リポジトリ、配備先、障害分類、調査期間、既存手順、顧客データの扱い、夜間の承認者が挙がっています。AIは設定案を詳しくできますが、会社の事実を自分で作ることはできません。

この実行はCosmos Advisorの性能試験ではありません。架空の要件に対する二つのモデルの一回分の出力で、原因特定の正確さ、接続の成功、設定時間、費用を比べていません。確認できたのは、導入計画を作らせても、組織固有の質問と承認地点が消えなかったことです。

AIエージェントの導入を速くするほど、設定後の責任を先に書く必要があります。最初から本番の解決を任せず、過去の一件を読み取り専用で再現し、調査結果と人の判断を並べるところから始めます。

展開は段階を分けます。最初は、無効な起動条件で過去事故を一件試す段階です。次に実際の通知へ読み取り専用で並走させます。根拠リンクと停止条件が安定した後は、課題や修正案の下書きまでを許可する段階です。本番変更は、失敗時の戻し方と監査記録を確認した後も、別の承認として扱えます。

ここからは筆者の見立てです。Advisorのような機能が広がると、導入支援者の仕事は画面設定から、業務範囲、認証、承認、評価を決める仕事へ移ります。製品が知っている接続方法と成功例は再利用できますが、どの顧客へどの失敗を許容するかは、会社の責任として残ります。

約10分という数字が示すのは、初期構成を短くできる可能性です。導入の完了を示すのは、OAuthを終えた時刻でも、Expertが一度動いた時刻でもありません。許可した範囲で仕事を行い、情報が足りなければ止まり、人が根拠をたどって承認できる状態まで確かめた時点です。