本番環境の障害調査をAIエージェントに承認付きで任せるOSS「AURA」を解説

「夜中の障害の一次調査くらいはAIに任せたいが、本番のシステムに触らせて取り返しのつかない操作をされたら困る」「AIが出した原因の見立てを、あとから誰がどの記録で確かめるのかが決まっていない」——運用の現場と、それを監査する情報システム部門の双方から聞こえてくる声です。どのAIが賢いかという話に見えますが、そうではありません。本当は、AIに何を触らせ、どこで人が止め、何を記録に残すかを、AIの外側で決めておけるかが問われています。この記事では、運用・障害対応（SRE。サービスを止めずに動かし続けるための運用の考え方）向けのAIエージェント基盤であるOSS「AURA」について、一次情報で確かめられる仕組み、公式の文書が認めている限界、企業が導入前に確かめるべき点を、AIセキュリティとガバナンスの観点から整理します。導入や設定の手順は扱いません。

AURAとは何か。2026年10月時点で確かめられる事実

AURA は、GitHub上で公開されているOSSです。リポジトリの説明によると、AIのモデルを本番の運用の道具につなぐために必要な、安全の枠組み、窓口、状態の管理、失敗の扱い、記録をまとめて引き受けるSRE向けのエージェント基盤です。公式の資料は、エージェントを動かす土台（ハーネス）と位置づけ、AIが本番の障害に取り組むための仕組みだと説明しています。

公開の時期と規模を確かめておきます。リポジトリが作られたのは2026年3月2日で、最後の更新は10月23日です。2026年10月26日時点で、スターは401、複製（フォーク）は40、記録された変更（コミット）は919件、未解決の課題は138件です。公開済みの版（リリース）は短い間隔で出ており、確認した最新は10月9日の0.2.19版で、正式版の前の段階です。本体は Rust という開発言語で書かれています。

ライセンスはApache-2.0で、OSI（オープンソースの定義を管理する団体）が承認したライセンスです。運営は、ログの分析や運用データの基盤を提供する Mezmo 社の組織アカウントで、アカウントは2010年12月に作られています。Mezmo 社の発表によると、AURA は同社が自社のサービスを運用するために使ってきた仕組みを公開したもので、中核の道具は無償で公開し、収益は別のデータ基盤の事業で得るという考え方が示されています。

なぜ今、障害対応にAIエージェントの「土台」が求められるのか

障害対応は、AIの活用先として期待されている分野の一つです。ログや監視の数値、変更の履歴、手順書を突き合わせて原因の見当をつける作業は、時間がかかる一方で、手がかりの多くが文字として残っているためです。AURA のREADMEにも、決済の失敗を、ログ・監視の数値・コンテナの配備の履歴から調べ、特定の版で入った不具合を見つけて一つ前の版に戻すよう勧める例が載っています。

問題は、障害対応の道具の多くが、調べるだけでなく本番のシステムを変える力も持っていることです。コンテナを消す、設定を同期し直す、課題を更新する、といった操作は、正しければ復旧を早めますが、誤れば障害を広げます。AIのモデルに道具をそのまま渡すと、どの操作をどこまで許したのか、誰が止められたのか、何が起きたのかが曖昧になります。

AURA は、この曖昧さをモデルの外側の仕組みで埋めようとする試みだと位置づけられます。公式の資料は、どの道具に手が届くか、何を承認待ちにするか、失敗した呼び出しをどう扱うか、何を記録に残すかを、モデルではなく土台の側が決めると説明しています。企業の側から見れば、AIの導入の審査で問われる論点が、設定と記録という確かめやすい形に置き換わる点に意味があります。

仕組み1：エージェントの構成をまとめて書き、見直せる形で管理する

READMEによると、AURA では、使うモデル、役割ごとのエージェントの組み合わせ、エージェントごとの指示文、使える道具、承認の方針、安全の枠組みを、一つの設定の書式（TOML）でまとめて書きます。エージェントの全体像を、版の管理と見直しができる設定として残せるのが特徴です。

これはガバナンスの観点で大きな意味を持ちます。AIエージェントの振る舞いが、担当者の手元の操作や画面の設定に散らばっていると、何がいつ変わったかを追えません。設定が一つにまとまっていれば、変更のたびに差分を確かめ、承認してから反映する、という通常のシステム変更と同じ手続きに乗せられます。

また、READMEは、モデルの提供元を設定の変更だけで切り替えられると説明しています。対応する提供元として、OpenAI、Anthropic、Amazon の Bedrock、Google の Gemini、手元で動かす Ollama などが挙げられ、役割ごとに別のモデルを割り当てることもできるとされています。ただし、提供元を切り替えれば、指示文や道具のデータの送り先も変わる点には注意が必要です。この点は後の章で扱います。

仕組み2：役割ごとに使える道具を絞る

公式の資料によると、AURA のエージェントは、役割ごとに分かれた作業者（ワーカー）として動きます。作業者はそれぞれ自分の指示文と道具の一覧を持ち、たとえばクラスターの状態を調べる作業者と、それを変える作業者を分けることができると説明されています。調べる権限と変える権限を別の役割に置く考え方です。

道具は、MCP（AIと外部の道具をつなぐ共通の取り決め）に対応したサーバーから取り込みます。設定では、取り込んだ道具のうち、どれをモデルに見せるかを絞り込めます。10月5日の0.2.18版では、道具の名前の型を特定のサーバーに限って指定できるようになり、型の書き誤りがあれば起動しないように変わりました。設定の誤りで意図せず道具が開放されたまま動く事態を、起動の時点で止める方向の変更です。

一方で、セキュリティの方針の文書は、この絞り込みに限界があることも明記しています。絞り込みを書かなければ、見つかった道具がすべてモデルに見える可能性があり、空の一覧を明示したときに初めて何も渡さない扱いになります。さらに、絞り込みは利用者ごとの権限管理ではなく、実際の権限を決めるのは、つないだサーバーとその認証情報だとしています。AURA は道具の名前や形から、それが読むだけの道具かどうかを判断しないとも書かれています。

仕組み3：危険な操作の前に人の承認を挟む

AURA の中心的な安全の仕組みが、人の承認（ヒューマン・イン・ザ・ループ）です。公式の資料によると、承認が必要な道具の名前を型で指定しておくと、その道具の呼び出しは人が承認するまで止まります。読むだけの呼び出しはそのまま進み、変更を伴う呼び出しは承認を待つ、という使い分けが想定されています。

承認の受け方は二通りあります。外部の仕組みに承認の依頼を送って返事を待つ方式と、会話の画面に承認の確認を出して利用者が答える方式です。承認する人には、道具の名前、どのサーバーの道具か、渡される引数、承認を求めた理由が示されます。資料によると、時間切れ、取り消し、承認の仕組みにつながらない、返事の形が壊れている、といった場合は、いずれも道具を動かさない側に倒れる（フェイルクローズ）とされています。

人が拒否した場合は、その理由がモデルへの返答として戻り、エージェントは拒否を踏まえて説明を続けます。ここで押さえておきたいのは、セキュリティの方針の文書が、承認を拒否しても、モデルが別の呼び出しを提案すること自体は止まらないと書いている点です。承認の仕組みは、指定した一つひとつの呼び出しの関所であり、エージェントの行動全体を止める非常停止ではありません。

仕組み4：判断と操作の記録を追跡データとして残す

AURA は、要求、モデルとのやり取りの各回、道具の呼び出し、複数のエージェントの連携の流れを、OpenTelemetry（システムの動きを記録して送る共通の仕組み）の追跡データとして出力できます。公式の資料によると、承認の対象になった呼び出しには、承認の判断の番号が記録に付き、どの承認がどの操作に結びついたかを後から突き合わせられる作りです。

記録の送り先は利用者が決めます。資料によると、送り先を設定しない限り追跡データは外に出ません。記録の中身にモデルへの指示文や道具の結果を含めるかどうかも設定で選べ、含める場合は一つの値ごとに上限の長さで切り詰められます。障害の調査結果を、人が後から検証できる形で残すことは、AIの判断を鵜呑みにしないための前提になります。

ただし、セキュリティの方針の文書には注意書きがあります。中身を記録しない設定が標準でも、内部で使っている部品が作る記録の一部は、その設定とは関係なく中身を記録してしまうとされています。文書は、モデルと道具の中身を受け取ってよいと認めた送り先でなければ、記録の出力を有効にしないよう求めています。記録は守りの道具であると同時に、機密が集まる場所にもなります。

つなげられる道具と、動かし方の選択肢

READMEには、AURA のエージェントがつなげられる道具の一覧が載っています。主なクラウドのサービス、Kubernetes、Docker、Grafana や Datadog などの監視の道具、GitHub や GitLab、Jira、Confluence、障害の呼び出しに使う PagerDuty などです。一覧の説明を読むと、調べるだけの道具と、課題の更新や同期のやり直しなど変更を伴う道具が混在していることが分かります。

ほかにも、手順書や過去の資料を検索して答えの根拠にする仕組み（RAG）、作業ごとの指示書を必要なときだけ読み込む仕組み、ほかのエージェントとつなぐ取り決め（A2A）への対応が挙げられています。OpenAI と同じ形の窓口でエージェントを提供できるため、既存のチャットの画面からそのまま使えるとも説明されています。

動かし方は、端末上の対話の道具、常駐するサービス、Docker のコンテナ、Kubernetes 上の配備、自社のプログラムに組み込む部品などから選べます。READMEは、外部につながらない閉じた環境でも、モデルとMCPのサーバーに手が届くなら動かせるとしています。どの形で動かすかによって、守るべき境界が変わる点は、導入の検討で最初に決めるべきことです。

類似の手段との違い

障害対応にAIを使う方法は、AURA のような土台を自社で動かす以外にもあります。考え方の違いを整理すると次のとおりです。いずれも一般的な傾向を示したもので、個々の製品の比較ではありません。AURA の欄は公式の資料の記載に基づき、この記事では実際に動かして確かめてはいません。

観点	AURA（自社で動かす土台）	汎用のAIチャットに手で貼る	提供元のサービスに組み込まれたAI機能
データの置き場所	自社の環境。送り先は利用者が決める	チャットの提供元に送られる	提供元のサービスの中
道具の操作	役割ごとに絞り、指定した操作は承認を求める	人が手で操作する	提供元が決めた範囲
記録	追跡データとして自社の送り先に出せる	会話の履歴が中心	提供元の記録の仕組みに依存
設定の見直し	一つの設定として版の管理ができる	仕組みとしての設定はない	画面の設定が中心
運用の負担	自社で配備・更新・権限の設計を担う	小さい	比較的小さい

表のとおり、AURA は自社で制御できる範囲が広い代わりに、守りの設計と運用の責任も自社に来る手段です。権限の設計や更新の追随を担う体制がなければ、利点は生かせません。

安全性の評価：紹介可とした根拠

このラインでは、OSSを取得・導入・実行せず、公開されている情報と精査の記録をもとに安全性を判定しています。AURA の判定は「紹介可」です。根拠は、ライセンスがOSI承認のApache-2.0であること、運営が2010年に作られた Mezmo 社の組織アカウントであること、公開済みのセキュリティ勧告がないこと、導入時に自動で動く処理の登録が見当たらないことです。

精査の記録では、導入時に自動で動く処理を登録するファイルの中身は空で、根元にあるのはコンテナを作るファイルと作業の手順をまとめたファイルなどでした。スターの伸びは1日あたり1.7ほどで、不自然な水準ではありません。セキュリティの方針の文書が詳しく書かれ、通信の送り先、権限の境界、指示の紛れ込みのリスク、配布物の検証について、できることとできないことを分けて説明している点も評価できます。

ただし、問題が見つからなかったことは安全の保証ではありません。とくに AURA は、本番のシステムを変える力を持つ道具をAIに渡す仕組みそのものです。仕組みに欠陥があったり、設定を誤ったりすれば、影響は本番の環境に直接及びます。判定は、記事として紹介してよいかの判断であり、自社の本番に入れてよいかの判断ではない点に注意してください。

公式の文書が認めている限界

AURA の特徴の一つは、セキュリティの方針の文書が限界を率直に書いていることです。文書によると、AURA はモデルの出力を信頼できるものにしない、道具を隔離しない、行った変更を元に戻さないとされています。認証、隔離、最小限の権限の認証情報、外への通信の制限は、運用する側が担うものだと明記されています。

常駐するサービスとして動かす場合、利用者の認証や利用者ごとの権限管理の仕組みがないため、社内だけで届く場所に置くか、認証付きの入り口の後ろに置くよう求めています。承認の仕組みについても、承認したのが本当に人かどうかは確かめないとしています。外部の仕組みに承認の依頼を送る方式では、署名の設定をしなければ、署名のない依頼と返事、暗号化されていない通信を受け付けてしまいます。

認証情報の扱いにも注意があります。設定の中で環境の値を差し込む仕組みは設定の全体に効くため、指示文の欄で参照すれば、その値がモデルに渡る文脈に入ります。権限の広いMCPのサーバーや手元で起動する部品が、環境の値を読んでモデルに返す可能性もあると書かれています。配布物には改ざんを確かめる値（チェックサム）が付きますが、暗号の署名や部品表（SBOM）は現時点で提供していないとされています。

悪用されうるリスクと、ログに紛れた指示の危険

AURA は守りと運用のための道具であり、攻撃のための道具ではありません。ただし、この種の仕組みならではのリスクがあります。第一は、調べる対象そのものに、攻撃者の指示が紛れ込むことです。セキュリティの方針の文書は、ログ、警報、手順書、ウェブページ、検索用のデータ、MCPのサーバーの返事を信頼できない入力として挙げ、モデルが指示と証拠を区別できる保証はないと書いています。

障害の調査では、外部から届く要求の中身がそのままログに残ります。攻撃者がログに残る文字列に指示を紛れ込ませれば、それを読んだエージェントが意図しない道具の呼び出しを提案する可能性があります。これはOWASP がAIの主要なリスクとして挙げるプロンプトインジェクション（AIへの指示の紛れ込み）の典型です。文書は、調査には読むだけの道具を使う、許す道具を明示する、承認する人が引数を正確に確かめる、敵意のあるログで試験する、といった備えを勧めています。

第二は、仕組みの設定の誤りが、そのまま権限の穴になることです。リリースの記録によると、0.2.18版では、文字で返された道具の呼び出しが絞り込みを守らず、除外したはずのサーバーの道具を呼べてしまう問題が直されました。絞り込みは書いたとおりに効くとは限らず、版の追随で守りが変わることを示す例です。現時点で、この問題による被害の報告は確認できていません。第三に、正式版の前で最新版にしか修正が出ないため、更新に追随できなければ既知の欠陥が残り続けることも考えられます。

導入を検討するときに確かめること

AURA のような障害対応のエージェント基盤を検討するときは、少なくとも次の順で確かめておくと、後からの手戻りを防げます。ここでの確認は、文書の読み込みと社内の判断の範囲で、導入や設定の手順は扱いません。

企業が取るべき対策

AURA を採用するかどうかに関わらず、障害対応にAIエージェントを使う企業が整えるべきことがあります。第一に、本番を変える操作には人の承認を必須とし、その対象を社内の規程に書き込むことです。どの道具のどの操作を承認待ちにするかは、AIの導入の担当者ではなく、システムの責任者が決めます。

第二に、エージェントに渡す認証情報を、読むだけのものと変えるものに分け、必要最小限の権限にすることです。絞り込みの設定ではなく、認証情報の権限そのものを最後の守りにする考え方です。第三に、エージェントが動く場所から外への通信を制限し、許した送り先以外には出られないようにします。

第四に、追跡データの送り先を、機密を受け取ってよい場所として扱うことです。記録には指示文や道具の結果が含まれうるため、保存期間と閲覧できる人を決めます。第五に、敵意のあるログや手順書を使った試験を、導入前と更新のたびに行うことです。ログに紛れた指示でエージェントが変更の操作を提案しないか、提案しても承認の関所で止まるかを確かめます。部品表がない点は、自社で作って管理することで補います。

AIに任せる範囲と、人が決める範囲

AURA は、人が決めた境界の中でAIに調査をさせる道具です。逆にいえば、どの道具を渡すか、どの操作に承認を求めるか、AIの見立てを採用するかどうかは、AIに判断させてはいけません。AIが原因の見当をつけて一つ前の版に戻すよう勧めても、それを実行するかを決めるのは人です。

人が決めるのは、渡す道具の一覧、承認の対象と承認する人、記録の送り先と保存期間、そして調査結果をどう扱うかです。AIに調査をさせるときは、AIに見立ての根拠となったログや数値を示させ、人が確認する範囲を先に決めておくことを手順に入れます。避けたい使い方を挙げます。

• 道具の絞り込みを書かずに動かし、見つかった道具をすべてモデルに見せてしまう
• 承認の窓口を、署名も認証もない暗号化されていない通信のまま使う
• 承認の依頼に表示された引数を読まずに、急いでいるからと承認する
• 指示文の欄に認証情報を差し込み、モデルに渡る文脈に機密を入れてしまう
• AIが示した原因と対処を、根拠のログを確かめずにそのまま障害報告に載せる

公式の文書も、承認する人が正確な引数を確かめることを、指示の紛れ込みへの備えとして挙げています。承認は押すための手続きではなく、読むための手続きだという理解が、この種の仕組みを安全に使う前提です。

よくある質問：人の承認を挟めば、本番で動かしてよいのか

承認の仕組みは、指定した呼び出しを人が確かめるまで止める関所です。時間切れや通信の失敗でも動かさない側に倒れる作りは、本番で使う仕組みとして重要です。しかし、承認の対象に入れ忘れた操作は止まりませんし、承認した人が中身を読まなければ関所の意味はありません。承認を挟むことは必要条件であって、十分条件ではないと受け止めるのが妥当です。

では承認の仕組みに価値がないのかといえば、そうではありません。変更の操作が、誰の判断で、どの引数で行われたかが記録に結びついて残ることは、事故の後の検証にも、日々の運用の見直しにも役立ちます。承認と記録を、権限の絞り込みと通信の制限に重ねて使うという多層の守りが、現時点の AURA との付き合い方です。まずは読むだけの道具での調査から始め、変更の操作を任せる範囲は実績を見ながら人が広げていくのが現実的でしょう。

• AURA の機能・仕組み・限界は、GitHubのリポジトリ（README、セキュリティの方針、リリースの一覧）と公式の資料（概要、人の承認、追跡データ）を2026年10月26日に確かめた範囲に基づきます。正式版の前のOSSで、内容は短い間隔で変わっています
• README にある社外での本番利用や、提供元のサービスで月に数千の作業が動いているという記載は、提供元の自己申告で、この記事では確かめていません。この記事では実際に動かして確かめてはいません
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

AURA は、本番環境の障害調査をAIエージェントに任せるための土台となるOSSです。エージェントの構成を一つの設定にまとめて見直せるようにし、役割ごとに使える道具を絞り、指定した操作の前に人の承認を求め、判断と操作を追跡データとして残せます。AIの賢さではなく、AIを囲む枠組みで本番の安全を考えるという姿勢は、障害対応にAIを使う企業にとって参考になります。

一方で、公式の文書は、AIの出力を信頼できるものにしない、道具を隔離しない、利用者ごとの権限管理がない、署名や部品表を提供していないと明記しています。渡す道具と承認の範囲を人が先に決め、認証情報の権限と通信の制限で最後の守りを固め、更新に追随する体制を用意しておくことが、この種の仕組みとの現実的な付き合い方です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。