私は、クラウドの請求額の急増を調査するAIエージェント「Ghost-hunter」を作りました。深夜の当番エンジニアがやるように、1つずつ仮説を立て、読み取り専用で、実行前にすべてのコマンドを検証します。中核となる設計上の判断は「2つのエージェントであること」であって「1つではない」ことです——リードの刑事（Claude Opus）が理論を組み立て、あなたのクラウドには一切触れません。証拠技術者（Claude Sonnet）がコマンド案を作成し、それが7つのゲートを通る validator（検証装置）にかけられてから、何も実行されない仕組みです。この記事では、なぜこの分離が重要なのか、validatorがどのように働くのか、そして私が越えない3つの設計ラインについて書きます。「なぜ請求額が上がっているの？」というメールに、11:47 PMに答えてきたことがあるなら読んでください。
1. 11:47 PMのメール
11:47 PMです。CEOから2語だけのメールが届きます。
Subject: Bill?
AWSの請求額が、1か月のうちに135,000ドルから163,000ドルへ増えました。明日の午前9時に役員会です。CFOは「数字」ではなく「原因」を求めています。
当番エンジニアがコンソールを開きます。急増は見えます。原因は見えません。掘り下げ始めます。
3時間、ブラウザタブ11個、そして冷えたコーヒー1杯の後に答えが浮かび上がります。us-east-1に、2週間前にチームを去った誰かによって起動された、忘れられていたGPUインスタンスが1つ。1時間あたり1.62ドル。24時間稼働。18日間。
この場面は、クラウドネイティブ企業なら毎月どこでも起きます。解決に必要なシニアエンジニアは組織内で最も高価な人材の1人で、しかも半分の確率で結局当番に割り当てられてしまいます。なぜなら、誰もFinOpsを明示的に「所有」していないからです。
私は、その調査を行うためにGhost-hunterを作りました。11:47 PMに。ほかの誰も起きていないときに。
この記事はアーキテクチャについてです——特に、なぜエージェントを2つに分けたのか、7ゲートのコマンド検証器がどう働くのか、そして私が越えない3つの設計ラインです。
2. ダッシュボードは記述する。診断はしない。
クラウドのダッシュボードはスモークディテクターです。火事が起きていることは教えてくれます。でも、どの配線が傷んだのかはわかりません。
「なぜ」の答えは、ダッシュボードが到達できない3つの場所にあります：
サービス固有ツール（aws、gcloud、kubectl）のコマンドライン出力
ダッシュボードが取り込んでいないログデータ
トライバルナレッジ——誰が何を起動したのか、このアカウントはテスト用か、このチームにとって「普通」は何か
人間の調査者は、自分の手でその地形を歩きます。仮説を立てます。読み取り専用のコマンドを実行します。出力を読みます。調整します。そして別の仮説を立てます。
Ghost-hunterも同じループを行います。11:47 PMに人間は不要です。
3. なぜ1つではなく2つのエージェントか
ほとんどのAIツールは、単一のモデルでラップされています。質問します。モデルがコマンドを書きます。それを実行します。そして、どう思ったかをあなたに伝えます。
チャットボットならそれで構いません。あなたのクラウドに触れるようなものなら、それは無謀です。
犯罪現場の刑事を思い浮かべてください。同じ人が「理論を組み立てる」と「生の証拠を扱う」を同時にやると、2つの問題が起きます。新鮮な視点なら気づくはずのことを見落とすこと。そして、1つのまずい前提が原因で現場を汚染することです。
Ghost-hunterは、責務を完全に分離した2つのエージェントを使います。
リードの刑事（Claude Opus）は、理論を組み立て、証拠の重みを量り、次に調査すべきことを決めます。コマンドは決して書きません。犯罪現場には直接触れません。
証拠技術者（Claude Sonnet）は、刑事から指示を受けます。コマンドを下書きし、validatorに投入し、返ってきた内容を1行で要約して報告します。そして、何かが越える前に、チェーン・オブ・カスタディ（保全の連鎖）にサインオフします。
ここで言う「現場を汚染する」とは、あなたのクラウドを損なうコマンドを実行することです。刑事はコマンドを書きません。技術者が下書きをします。7ゲートの安全システムがそれを検証します。すべてのゲートがサインオフするまで、何も実行されません。
分割は単なる安全のためのパターンではありません——推論のパターンでもあります。同じモデルが理論を作り、さらに証拠を解釈する場合、確証バイアスが増幅されます。分割することで、引き継ぎを明示的に強制できます。刑事は「何を確認したいか」を言語化し、技術者は「何が返ってきたか」を明示的に報告し、「期待したもの」と「得られたもの」の間に食い違いがあれば、次のプロンプトに静かに吸収されるのではなく、調整可能な確信度として表面化します。
4. 実際の調査、5つのシーン
私はGhost-hunterを、FinOps Foundationの公開するFOCUS 1.0サンプルに対して動かしました。実際の形、匿名化されたデータです。金額は縮小されています。仕組みは、実際のエクスポートに対して見えるものとまったく同じです。
シーン1 — 急増の現場
Ghost-hunterをアドバイザーモードで実行：「あなたのクラウドには触れません。請求のエクスポートを読み取り、読み取り専用のコマンドを提案し、それをあなた自身に実行してもらいます。」
リストの最上部にあるのはEC2で、185.5%増。ドル影響で27のほかのサービスもスキャンして順位付けしました。調査は「推測」ではなく「事実」から始まります。
シーン2 — 容疑者たち
リードの刑事がファイルをばらします。主要SKU。主要アカウント。主要リージョン。アカウント11353890204)が支出の91%を担っていました。その92%がus-east-1に着地しています。
ボードには、各々が検証可能な確信度スコアを伴う4つの仮説を載せます：
H1（55%）— MLやレンダリングのために動いているGPUインスタンスが、請求の大部分を押し上げる
H2（30%）— 汎用インスタンスが、本来より長く起動しっぱなしになっている
H3（35%）— CIまたはバッチパイプラインが、短いバーストのインスタンスを立ち上げている
H4（10%）— 格納（ストレージ）の増加が副次的な寄与として考えられる
刑事は最も強いものを選び、技術者にテストを渡します。
シーン3 — 予定が外れるインタビュー
技術者がコマンドを下書きします。読み取り専用。4つのセキュリティレイヤーで検証されます。ユーザーのクリップボードにコピーされます。
ユーザーが返信します：
"i dont have access to the aws account to run any commands"
ほとんどのAIツールはここで壊れます。フリーズしたり、幻覚の結果をでっち上げたり、こっそり「ユーザーがコマンドを実行したことにする」ふりをしたりします。
Ghost-hunterはそれをしません。刑事は、拒否を「情報」として扱います。ボードに書かれている内容を読み直します。確信度を更新します（H1は55%から75%へ上昇）。請求だけから実際に証明できることに着地します。
"Understood. You don't have CLI access. No problem. The billing data is quite revealing on its own. Let me work with what we have and wrap this up."
見せかけの確信度低下は、そもそもツールがないよりも悪いです。Ghost-hunterは72%に着地します。95%でも100%でもありません。72%です。
シーン4 — 計画
「この12個のことをやって、うまくいくことを祈る」ではありません。優先順位つきのはしごです。
今すぐ。アカウント 11353890204 の所有者に連絡する。us-east-1 で動いている g5.4xlarge インスタンスを確認する。
今週。コスト異常検知のモニターを設定する。予算 5,000ドルを追加し、メール通知を 80% と 100% に設定する。
今月。Savings Plans を評価する。承認なしに高価な GPU の起動をブロックする IAM ガードレールを追加する。
「今すぐ」の各項目は5分以内に完了します。リストのどれも、本番に対する書き込みコマンドではありません。
シーン5 — 判決（正直な空白つき）
根本原因。引用された証拠5点。ゴーストハンターが検証できなかったことのリスト5つ。
この部分は、結論そのものより重要です。
たいていのAIツールは、誤った確信で締めくくります。誤った確信は、磨かれているように見えるからです。ゴーストハンターは、分からないことをあなたに伝えます。
「どの具体的なEC2インスタンスが動いているのかを確認できませんでした。」
「GPUインスタンスを誰が、どんな目的で起動したのかを特定できませんでした。」
その透明性こそが、結論を信頼できるものにしています。議事録を読めば、何が引用されたのか、何が引用されなかったのかが分かり、72%が行動するのに十分かどうかを判断できます。
5. 七つのゲートによるコマンド検証
ゴーストハンターが提案するすべてのコマンドは、7つの検証ゲートを通過します。どれか1つでも見落とされれば、コマンドは死にます。
1. 即時リジェクト シェルのメタキャラクタをブロック (;, &&, クォートされていない $())
2. アロウリスト この動詞（verb）は読み取り専用リストに入っているか？
3. フラグチェック この動詞に対して、すべてのフラグは安全か？
4. 入力衛生 長さ、エンコーディング、空のコマンド？
5. 予算 コマンド数、コスト、1回の実行にかかる時間の上限
6. セマンティックチェック これは、明示された仮説を実際に検証しているか？
7. サンドボックス 環境の分離（アクティブモードのみ）
検証器が自信を持てなかったコマンドを、ときどき通してしまうシステムは、「いつか事故で削除（delete）を実行する」システムです。ゴーストハンターには「親切な上書き（helpful override）」はありません。すべての扉を通過できないコマンドは実行されません。
セマンティックチェック（ゲート6）は、実装する上で最も面白いものです。構文の話ではありません。問いはこうです。「探偵が述べた仮説を前提にすると、このコマンドは本当にそれを検証しているのか？」構文的に完璧でも、仮説から外れているコマンド（例えば、EC2を調査しているのにS3バケットを確認する）はここで失敗します。ここで2つの別エージェントを持つことが効いてきます。技術者（technician）はリンク（関連付け）を説明し、探偵（detective）はそのリンクを受け入れるか拒否します。そしてゲート6が、どちらも黙って論点がずれていくことを防ぎます。
6. 越えないと決めた3つの設計方針
- 書き込みはしない。決して。
読み取り専用こそが、プロダクトの全体です。探偵はクラウドの鍵を握っていません。書き込み権限は滑りやすい坂です。一度ツールベルトにdeleteが入ってしまうと、将来のあらゆるプロンプトが、誤ってそれを呼び出してしまわないように防御する必要に迫られます。権限を取り除けば、その種のバグも取り除けます。
- ハードコードされた回答はしない。
たいていの「AI FinOps」ツールは、パターンを暗記してベンチマークに勝ちます。「NAT Gateway と高いバイト数なら、答えはVPCエンドポイントの欠落。」——ゴーストハンターはそれを拒否します。CIパイプラインは、シナリオ名をプロンプトに入れたコミットを文字どおり失敗させます。推論が議事録に入っていなければ、プロダクトにも入っていません。
これは珍しく、具体化したいので明確にします。CIのテストでは、既知のベンチマークシナリオのリスト（「NAT gateway egress trap」「cross-region replication bug」「GPU left running」など）について、プロンプトファイルをgrepします。これらのフレーズがそのまま1つでも現れたら、コミットは失敗します。プロンプトは推論のプリミティブ（コスト/SKU分析、仮説検証、読み取り専用コマンドの選択）を説明しますが、特定の答えの形は決して説明しません。
- データをあなたのマシンから外に出さない。
請求書はローカルに残ります。移動するのは、圧縮された証拠の要約だけで、しかも自分のAnthropic APIキー経由です。つまりこれも意味します。ゴーストハンターのサーバーがないこと、顧客間の漏えいがないこと、「分析（analytics）を追加しています」ということもありません。
7. なぜこれが重要なのか
この領域のAIツールの多くは、いい声を持つルックアップテーブルです。学習した形を認識します。学習していない形は見逃します。
ゴーストハンターは遅いです。既知のパターンなら、暗記型のツールが常に勝ちます。
ゴーストハンターが勝つのは、誰も見たことがない請求書（bill）です。あなたの請求書。あなたの設定。MLチームの実験によって生じたスパイク、サードパーティベンダのバグ、テストのために本番のパイプラインをクローンしたインターン。すべての仮説、すべてのコマンド、すべての証拠は、あなたが読める議事録の中にあります。
AIが言ったから結論を信じるのではありません。自分で推論を監査できるから信じます。
それがプロダクトです。
8. 私が違うことをするなら、次にやること
現行のアーキテクチャが間違っている点がいくつかあります。もし最初から作り直すなら、私はそれを作り直します。
探偵（detective）/技術者（technician）の境界が負荷により漏れる。調査が長引く（5回以上の仮説サイクル）と、コンテキスト圧縮のため要約が強制されます。そして要約の段階で、探偵が「実際に技術者が集めた証拠を思い出し始める」ことがあります。私は、文章の要約ではなく、共有の追記専用の証拠ログを両エージェントが読み取ることで、より厳密に分離したいです。
七つのゲートによる検証は良いが、そこに関するテレメトリ（観測データ）が悪い。どのゲートが、どんな理由で最も多くのコマンドを拒否しているのかを、まだ綺麗なダッシュボードとして持てていません。必要なのは、このフィードバックループです。過度に神経質にならずにアロウリストを強化するために。
FOCUS 1.0 は素晴らしいが、実際の課金エクスポートはもっとややこしい。サンプルデータは、1つのアカウントから1つのスパイクへ、きれいに対応付けられます。現実には、サービス間で相関したスパイク（例：NAT Gatewayのエグレスが増えるのは、EC2が上がっているからで、さらにKubernetesが上がっているから）を目にするでしょう。そして仮説ツリーは、葉（leaf）の原因だけでなく、合成された原因をモデル化する必要があります。
次にやること：AWSプロバイダの強化（hardening）、その後パブリックベータへ。GCP対応はすでに出荷済みで、AWSが現在のゲートとなる依存関係です。
9. あなたの番
返却形式: {"translated": "翻訳されたHTML"}クラウドの請求が、なぜか急に跳ね上がったことはありませんか？症状を取り繕っただけで、真の「幽霊」の正体は見つけられなかった――あのタイプです。
コメント欄に投げてください。私が次に「ゴーストハンター」対して検証したいのは、いちばん奇妙なやつです。
私は MatrixGard を運営しています。シード前スタートアップ向けの、分割型のDevOps/クラウド/セキュリティです。クラウド基盤を構築し、壊し、そしてセキュアにしてきた約10年。
もともとは matrixgard.com に掲載されました。
