当社のAIエンジンNeutronが、UCバークレーのCyberGymベンチマークで97.1%のスコアを記録しました。 詳細を見る

すべての号

The Breach Brief

メニューには辛すぎる

社内レビューのポリシーがどのようにして意図しない情報開示のパイプラインを生んだのか、そしてセキュリティチームにできること。

Ostorlab Research 11分で読めます

一般的なAIアシスタントにアプリケーションロジックの一部を書かせると、クリーンでマイルドなコードを数秒で出してくれます。

ところが同じアシスタントにそのレシピを試させようとすると、つまり微妙な競合状態を見つけさせたり、認証チェックをバイパスさせたり、エクスプロイトのペイロードを作らせたりしようとすると、厨房は突然店じまいします:「コンピューターシステムへの攻撃には協力できません。」

この2年間、セキュリティチームは幼児向けに作られた厨房でオフェンシブテストを行おうとしてきました。火を強めてもよいと消費者向けチャットボットに納得させるためだけに、手の込んだプロンプトの回避策を使ってきたのです。しかし、プロンプトの小技では本番運用に耐えるセキュリティパイプラインは構築できません。

今週のディープダイブではサイバーモデルの先へと踏み込み、モデルの素の能力が戦いの半分にすぎない理由を検証します。単体のモデルが複雑な脆弱性のメカニズムに苦戦する理由、本物のセキュリティには専用設計のエージェント型ハーネスが必要な理由、そしてチームが完全なセキュリティ運用環境の中でオフェンシブな推論をどう統制しているかを解説します。

続いて技術研究では、PaperCutのゼロデイチェーン(CVE-2026-81578 & CVE-2026-82078)を詳しく解説します。Apache Tapestryの認可の不一致と、安全でないデータベースコネクターの実行を悪用し、認証なしでSYSTEMとしてのリモートコード実行(RCE)を達成するエクスプロイトチェーンです。

さらに、エージェント型のペアプログラミングに使えるGoogle Antigravityを取り上げ、今週の主要なセキュリティニュースを紹介し、最前線から届いた最新のミームをお届けします。

この号の内容:

  • 🌡️ 脅威レベル:

  • ⚡ ニュース:

  • 🔎 ディープダイブ:サイバーモデルの先へ

  • 🎣 これはフィッシング?

  • 🔬 技術研究:見ているページが実行されるコードではないとき:PaperCutゼロデイチェーンの内側(CVE-2026-81578 & CVE-2026-82078)

  • 🛠️ 今週のツール:Google Antigravity

  • 👏 今週の人物:Tanya Janca

  • 📅 今週のイベント:LABScon 2026

  • 📚 今週の本:Heavy Wizardry 101

  • 😅 今週のミーム

さっそく見ていきましょう。


今週のストーリーに入る前に、現在の脅威レベルを確認しておきましょう。

🌡️脅威レベル

⚡ ニュース

Coderのレジストリが認証情報を盗むモジュールの配信経路に

攻撃者がCoderのCloudflareインフラを侵害し、一部のレジストリリクエストを、悪意あるTerraformモジュールを配布するサーバーへ転送しました。これらのモジュールは8月31日に約14時間にわたって入手可能な状態にあり、クラウド、AIツール、CI/CD、OIDC、SSHの認証情報を狙っていました。Coderは影響を受けたデプロイメントをすべて確定的に特定することはできていません。ダウンロードと外向き通信を確認し、影響を受けたモジュールを削除したうえで、ワークスペースのプロビジョナーがアクセスできるすべてのシークレットをローテーションしてください。

Adobe Commerceのゼロデイ:パッチ適用は最初の一歩にすぎない

Adobeは、Adobe CommerceとMagento Open Sourceに影響する認証不要のコード実行の脆弱性CVE-2026-75650に対する緊急修正をリリースしました。Adobeは実際の悪用を確認しており、この欠陥にCVSSスコア10.0を割り当てています。マーチャントはVULN-39341ホットフィックスを適用し、正しくインストールされたことを確認したうえで、暗号鍵と、漏えいした可能性のある決済、連携、データベース、サービスの認証情報を、それぞれの発行元でローテーションする必要があります。

自社モデルの前段に置かれたAIゲートウェイが実際に悪用されている

CISAは9月2日、CVE-2026-59822を既知の悪用された脆弱性(Known Exploited Vulnerabilities)カタログに追加しました。この欠陥により、攻撃者はLiteLLMのMCPエンドポイントに任意のBearerトークンを渡すだけで認証済みセッションを取得でき、設定済みのツールや接続されたサービスが露出していました。LiteLLM 1.84.0で修正されています。ただちにアップグレードし、MCPルートへのアクセスを制限し、不正アクセスの兆候がないかツールの動作履歴を確認してください。

AIコーディングエージェントは最初のプロンプトより前にリポジトリ由来のコードを実行しうる

GitSpawnの調査で、複数のコーディングエージェントが、リポジトリの.git設定に保存された悪意ある命令を実行しうるGitコマンドを自動的に実行していたことが判明しました。一部のケースでは、ワークスペースの承認前に、しかもエージェントのサンドボックスの外で実行が起きていました。ただし、リポジトリが.gitディレクトリを保ったまま届く必要があり、ZIPファイルや共有フォルダー経由などがこれに当たります。影響を受けるエージェントを更新し、外部から提供されたワークスペースは開く前に隔離してください。

正規のGoogleやMicrosoftの同意画面でも、アカウントを明け渡してしまうことがある

FBIは、攻撃者が政府関係者、ジャーナリスト、イベント主催者になりすまし、標的を悪意あるアプリケーションの正規のOAuth権限画面へ誘導していると警告しました。「許可」をクリックすると、被害者のパスワードが明かされることも、多要素認証(MFA)が直接突破されることもないまま、メールやファイルへの永続的なアクセスが与えられる可能性があります。パスワードを変更しても、そのアクセスは取り消されません。対応手順には、アプリケーションへの付与状況の確認と、悪意あるOAuthトークンの失効を含める必要があります。

見落とされたMetabaseのアドバイザリ一つが、100万人を超える人々のデータ流出につながった

Mathspaceは、攻撃者が社内のMetabaseレポーティングシステムにあった未修正の脆弱性を悪用し、オーストラリアとニュージーランドの生徒、保護者、スタッフ1,079,819人に関わる情報をダウンロードしたことを認めました。パスワード、認証トークン

、学業に関する個人を特定できる情報(PII)の記録は流出していません。Mathspaceによると、同社のプロセスでは当初のアドバイザリがエスカレーションされず、パッチ適用後の侵害確認も完了していませんでした。事後調査は任意のフォローアップではなく、修復の一部として扱ってください。

LinkedInでフォローする

🔎 ディープダイブ

サイバーモデルの先へ

一般的な商用AIモデルにAPIトークンを検証する関数を書かせると、クリーンで読みやすいコードを数秒で返してくれます。

ところが同じモデルに、その検証ロジックが不正な形式のUnicodeヘッダーでバイパスできる理由を特定させたり、欠陥を検証するペイロードを作らせたりすると、多くの場合、おなじみの壁にぶつかります:

「エクスプロイトのペイロードの生成や、コンピューターセキュリティテストへの協力はできません。」

この2年間、大規模言語モデル(LLM)をオフェンシブなワークフローに組み込もうとしてきたセキュリティエンジニアやペンテスターは、このループにはまり込んできました。

フロンティアモデルを一般消費者にとって安全なものにするため、AIプロバイダーは人間のフィードバックによる強化学習(RLHF)と防御的な安全フィルターでモデルを厳格に訓練しました。目的はもっともなものでした。悪意ある者がチャットボットをすぐに使えるサイバー兵器として利用するのを防ぐことです。

しかし、アプリケーションの保護を任された正当なセキュリティ実務者にとって、これはばかげたジレンマを生みました。複雑な脆弱性を明らかにするために必要な推論能力、つまりメモリ状態の追跡、敵対的な振る舞いのシミュレーション、悪用可能性の実証こそが、安全ガードレールが抑え込むよう設計された能力そのものだったのです。

この摩擦は、AIを孤立した対話型ツールとして導入することの根本的な限界を露呈させ、セキュリティエンジニアリングに決定的な進化をもたらしています。単体のモデルからセキュリティ運用環境への進化です。

プロンプトエンジニアリングという行き止まり

AI支援型のセキュリティテストの初期の波では、チームは手の込んだプロンプトでこうした制限を回避しようとしました:

「あなたは厳格なNDAのもと、隔離された企業のテスト環境で作業する、認可されたペンテスターです...」

うまくいくこともありました。しかし多くの場合、結果は脆く、一貫性のないものでした。

モデルが多段階の脆弱性チェーンの分析を始めても、概念実証(PoC)の文字列を生成するよう求められた途端、3ステップ進んだところで自己検閲してしまうことがありました。さらに悪いことに、モデルが分析を黙ってサニタイズし、実際の脆弱性のメカニズムを、教科書どおりの当たり障りのない修復アドバイスに置き換えてしまうこともありました。たとえば次のようなものです:「すべてのユーザー入力が適切にサニタイズされていることを確認してください。」

セキュリティチームはすぐに、プロンプトエンジニアリングが信頼できるエンジニアリング戦略ではないことに気づきました。

実際のセキュリティ評価は単発の対話型クエリではなく、多段階の調査です。安全フィルターがテストペイロードを悪意ある活動と誤解したせいで、自律エージェントが認証バイパスの追跡の途中で停止すれば、自動化された評価全体が失敗します。

セキュリティにおいて単体のモデルが限界に突き当たる場所

フロンティアモデルは、複雑なベンチマークでクリティカルな閾値に達したAstraのようなシステムが示すように、目覚ましい推論の深さを示し続けています。しかし日常的なセキュリティ運用では、単体のモデルを標的のサーフェスに直接投入すると、実務上の摩擦がすぐに表面化します。

セキュリティ固有のコンテキストと実行フィードバックがなければ、有能なモデルでさえ、崩れた前提やエッジ条件を体系的に探るのではなく、見慣れたコードパターンに頼ってしまうことがあります。

敵対的テストに求められるのは正反対のこと、つまり最も意図されていない経路を見つけることです。

重大度の高い脆弱性が標準的な構文に現れることはめったにありません。それらは崩れた前提とエッジ条件から生まれます:

  • 非同期の競合状態:分散サービス間で状態の同期が崩れる

  • 型混乱とメモリ破壊のプリミティブ:言語と実行環境の境界で生じる

  • パーサー差異の欠陥:フロントエンドのプロキシとバックエンドのオリジンサーバーの間で生じる

  • ビジネスロジックの悪用:有効なプリミティブを、開発者が想定しなかった順序で連鎖させる

単体のモデルが実行時の実行環境や専門ツールなしで動作すると、決定的な摩擦点が生じます。対話型の安全フィルターは無害なエクスプロイト検証を悪意ある攻撃と誤読し、モデルは理論上の仮説が実際のシステムに対して成り立つかどうかを検証できません。このギャップを埋めるには、有能なモデルを選ぶだけでは足りません。攻撃経路を探索し、ツールを実行し、実行時のフィードバックを評価し、結果を検証できる、セキュリティ専用のエージェントハーネスが必要です。

セキュリティ運用環境の台頭

この摩擦に対処するため、AIエコシステムの焦点は、孤立したモデルへのアクセスから、専用設計のセキュリティ運用環境へと移りつつあります。

セキュリティに使われるモデルのすべてが、サイバーセキュリティ専用に訓練されている必要はありません。汎用のフロンティアモデルも、適切なツール、コンテキスト、検証ループ、運用上の制御を備えた専門のエージェント型システムに組み込まれれば、非常に効果的なセキュリティエンジンになりえます。

同時に、フロンティアプロバイダー各社は、段階的なプログラムを通じて専門的なアクセスと評価を体系化しつつあります:

  • OpenAIのAstra、Daybreak、GPT-5.6-Cyber:OpenAIはAstraで自律的なサイバー能力の最前線を示しました。これは、同社のPreparedness Frameworkにおける「Critical」のサイバーセキュリティ閾値を満たした社内評価(ExploitBenchで100%、複雑なV8ターゲットでの任意コード実行の高い効率、これまで知られていなかった2件のゼロデイ脆弱性の発見と悪用を含む)を受けたものです。デプロイを安全に統制するため、OpenAIは2つの異なる運用トラックを導入しました。検証済みの防御側に汎用モデルへの調整済みアクセスを提供するDaybreak Blueと、サイバーセキュリティ専用に訓練されたモデルを提供するDaybreak Redです。GPT-5.6-Cyberのような専門的な派生モデルとあわせて、これらのプログラムは、厳格なアクセス制御、能動的なテレメトリ、利用規定を維持しながら、認可されたワークフローに合わせてセーフガードを調整します。

  • AnthropicのCyber Verification Program(CVP):AnthropicはCyber Verification Programを通じてセキュリティチームのニーズに応えています。静的な対話型フィルターに頼るのではなく、申請制のこのプログラムは、検証済みの防御側に対し、認可された業務向けにサイバー関連のセーフガードを緩和して提供します。これにより、検証済みの企業チームや研究者は、組織の本人確認と能動的な利用監視のもとで、誤検知(フォールスポジティブ)による拒否を減らしながら、高度な脆弱性研究、コード監査、エクスプロイト検証を行えます。

これらの実装全体を通じて、完全なセキュリティ運用環境は、一般的な消費者向けLLMの導入とは3つの根本的な点で異なります:

1. 調整された敵対的アライメント

専門的な環境では、汎用的な対話型の拒否トリガーが、目的に合わせて調整されたアライメントに置き換えられます。検証済みプログラム内のモデルは、プロバイダーレベルのテレメトリ、本人確認、利用制限に縛られたまま、誤検知による拒否を減らしつつ、エクスプロイトのプリミティブを評価し、脆弱性のメカニズムを分析し、境界防御をテストできます。

2. 深い状態空間の探索

表層的なテキスト上で動作する単体のチャットボットとは異なり、セキュリティ運用環境はモデルを、複雑な標的環境全体で状態を維持できるエージェント型の実行ハーネスに組み込みます。仮説を立て、稼働中のアプリケーションターゲットとやり取りし、実行時のフィードバックを観察し、レスポンスに応じてテスト戦略を動的に適応させることができます。

3. アクセス管理と運用ガバナンス

専用に訓練されたモデルやセーフガードを緩和した構成では、組織の検証と利用規定への同意が必要になる場合があります。実行レイヤーでは、エンタープライズAPI、BYOKでのデプロイ、マネージドなモデルアクセスのいずれであっても、ターゲットの境界、権限、監視、監査可能な制御が引き続き必要です。

LinkedInでフォローする

チャットボットからインフラへ:統制された深さという課題

対話型チャットボットから自動化されたセキュリティ運用環境への移行は、重大な運用上の課題をもたらします。それが実行ガバナンスです。

エージェント型モデルに自由回答型のプロンプトを与えて、インフラのターゲットに向けるだけでは済みません。制約がなければ、自律ループは次のような事態を引き起こす可能性があります:

  • 優先度の低いエッジケースを総当たりしようとして、再帰的に大量の計算資源を消費する

  • 破壊的な操作を引き起こしたり、ステージング環境に対してサービス拒否(DoS)状態を生じさせたりする

  • テスト予算を圧迫する予測不能なコストが発生する

これにより、運用上の焦点はモデルへのアクセスから実行の制御へと移りました。

最新のセキュリティ運用環境は、厳格な運用フレームワークによって実行を統制しています:

  • ターゲットに限定された実行:モデルのエージェント型ループが、明示的に定義されたドメイン、IP範囲、APIエンドポイントの外に出られないようにします。

  • エフォートプロファイルと計算上限:テストの深さを段階的な計算予算(Core、Advanced、Eliteの推論プロファイルなど)に分けて構成します。簡単な偵察パスは厳しい上限のもとで動作し、深い多段階のロジック分析には、暴走する再帰を許さない範囲で十分な推論ステップが割り当てられます。

  • 実行ガバナンス:エンタープライズキーを直接使う方式(BYOK)でも、マネージドな計算ティアでも、チームはトークンやクレジットの厳格な上限、ステップ上限、ターゲットの隔離を適用し、自動スキャンを範囲内かつコスト予測可能な状態に保ちます。

オフェンシブセキュリティの新しいベースライン

AIが本格的なオフェンシブセキュリティに居場所を持つかどうかという議論には、決着がつきました。

消費者向けチャットボットや単体のモデルは、そもそも本番レベルのセキュリティテスト向けに設計されたものではありませんでした。AI主導のセキュリティを、プロンプトの実験から正式な運用インフラへと移行させるには、孤立したモデルから統合されたセキュリティ運用環境への転換が必要です。

防御側にとって、この転換は大きな利点をもたらします。攻撃者が亀裂を見つける前に、複雑なサーフェスに対して継続的かつ深い敵対的評価を実行できるのです。効果的なセキュリティAIは、厳密な検証、ターゲットの境界、実行ガバナンスを備えた専用設計のエージェント型ワークフローの中で、有能なモデルが動作することにかかっています。

🎣 これはフィッシング?

怪しいリンクはありません。IT部門からのメッセージとMFAの確認要求があるだけです。あなたなら承認しますか?

🔬 技術研究

見ているページが実行されるコードではないとき:PaperCutゼロデイチェーンの内側

公開のエラーページが管理機能を呼び出し、最終的にその背後にあるサーバーを乗っ取ることはありうるのでしょうか?

Webアプリケーションは、これから実行しようとしているアクションを認可すべきです。PaperCut NGとMFは、より微妙な判断をしていました。特定の条件下で、代わりにユーザーに表示されるページのほうを認可していたのです。

攻撃者はこのアーキテクチャ上の不一致を悪用し、2つのゼロデイを連鎖させて、PaperCutサーバープロセスの権限で認証なしのリモートコード実行を実現しました。HuntressのWindowsでの再現では、その権限はNT AUTHORITY\SYSTEMでした:

公開リクエスト → 管理コンポーネント → データベースの再構成 → 安全でないクラスロード → OSコマンドの実行

脆弱性:CVE-2026-81578とCVE-2026-82078は、パッチが存在する前から実際に悪用されていました。PaperCutは、顧客から侵害の報告があり、ログから説明のつかないコード実行が判明したことを受けて、2026年8月27日にこのキャンペーンを公表しました。両脆弱性はCISAの既知の悪用された脆弱性カタログに追加されています。

1. Tapestryの認可の不一致(CVE-2026-81578)

PaperCutはApache Tapestry上に構築されています。Tapestryは「complex direct」サービスリクエスト形式をサポートしており、この形式では、レンダリングされるレスポンスページと実行されるコンポーネントが独立して定義されます:

POST /app?service=direct/<value>/Error/ConfigEditor/quickFindForm HTTP/1.1

Tapestryはパス要素をservice=direct/<value>/<display-page>/<component-page>/<action>として解析します。Rapid7によると、<value>セグメント(ここでは1)には任意の値を入れられます。

セキュリティ境界が崩れたのは、PaperCutがアクセス権限を<display-page>に対してしか確認していなかったためです。ErrorとExceptionは公開ページなので、認証のないリクエストはチェックを素通りし、その一方でTapestryは保護された管理コンポーネント(ConfigEditor)に実行をディスパッチしていました。

評価はCVSS 8.8で、この欠陥により、認証されていない攻撃者が内部のサーバー設定を変更できます。しかし設定へのアクセスはシェルではありません。チェーンの後半が必要です。

2. 設定をクラスロードに変える(CVE-2026-82078)

ConfigEditorを通じて、攻撃者はPaperCutの外部ユーザーおよびカード番号の検索機能を標的にしました。この機能は、ID番号を外部データベースと照合して解決するものです。管理者はこの機能を4つのプロパティで設定します:

  • user-lookup.enabled:外部検索を有効にする(Y)

  • user-lookup.db-driver:インスタンス化する、完全修飾名のJavaデータベースドライバークラス

  • user-lookup.db-url:ドライバーに渡されるJDBC接続文字列

  • user-lookup.id-to-username-sql:検索時に実行されるSQLクエリ

PaperCutのデータベースユーティリティは、設定されたドライバー文字列を使ってドライバークラスを動的にロードしてインスタンス化しますが、許可リストとの照合は行いません。

これがCVE-2026-82078(CVSS 9.4、安全でない動的クラスロード)です。本来は権限のないユーザーからは到達できないはずですが、CVE-2026-81578がその制限を取り払います:

  • CVE-2026-81578が、信頼された設定に対する制御を与える

  • CVE-2026-82078が、その制御をコード実行に変える

どちらの脆弱性も、単独では認証なしのリモートコード実行をもたらしません。1つ目は危険な設定に到達し、2つ目はその設定を実行可能にします。

3. チェーンの全体像:Derby → H2 → Nashorn → SYSTEM

このエクスプロイトは外部のドライバーを持ち込むのではなく、PaperCutにすでに同梱されているコンポーネントを武器化します:

  1. 設定の変更:認証のないリクエストがTapestryのバイパスを介してConfigEditorを呼び出し、user-lookup.*を書き換えて、ドライバーをPaperCutに組み込まれたApache Derbyに設定します。

  2. 検索のトリガー:攻撃者は2つ目の認証なしリクエストを送り、UserListコンポーネント(/app?service=direct/<value>/Error/UserList/$QuickFind.$Form)に対して同じバイパスを再利用して、ユーザー検索を発生させます。

  3. DerbyからH2へ:PaperCutが検索クエリを実行します。DerbyのCALL文がforeignViewsを有効にし、組み込みのH2のJDBC URLへの二次接続を開きます。

  4. トリガーの定義:H2がインラインのINIT文を処理し、JavaScriptで実装されたデータベーストリガーを作成します。

  5. OSでの実行:PaperCutに同梱されたNashorn JavaScriptエンジンがトリガーをコンパイルして実行し、pc-app.exeの配下にNT AUTHORITY\SYSTEMとして子プロセスを生成します。

Huntressは、pc-app.exeにWindowsの文字コード表ユーティリティ(Character Map)をSYSTEMとして起動させることでチェーン全体を検証し、アプリケーションのすべての層をまたぐ認証前のコード実行を確認しました。

LinkedInでフォローする

4. 実環境での悪用とフォレンジックアーティファクト

8月26日以降、脅威アクターはこのチェーンをホストの探索(whoami、ver、tasklist)に使い、その後リモートアクセスツールをインストールしていました。確認された活動には、LocalSystemとして動作するSimpleHelpサービスや、AnyDeskのダウンロードが含まれます。

調査担当者は、<install>\server\libに置かれた、ランダムな5文字の名前を持つJavaクラス(例:Udydn.class、Moo97.class)を回収しました。これらのクラスは<install>\server\data\contentに保存されたコマンドをデコードして実行し、出力ファイル(.out)を返し、ログを自己削除します。

ペイロードはPaperCutのserver.logを削除しようとしましたが、フォレンジックアーティファクトは複数の層に残っていました:

  • Derbyログ:Huntressは、PaperCutの独立したderby.logに、コード実行の直前にインメモリのDerbyデータベース(jdbc:derby:memory:pwn)が作成された記録が残っていることを発見しました。

  • ログのシグネチャ:Database error looking up cardID: VALUES CASTおよびDB URL: jdbc:no:xを探してください。

  • ファイルシステムとプロセスのテレメトリ:server\lib内の予期しない.classファイル、server\data\content内の.cmdや.outのアーティファクト、そしてpc-app.exeがシェルや偵察ユーティリティ(nltest、tasklist)を起動していないかを監視してください。

5. 緊急パッチと修復

PaperCutは8月28日に2つの緊急パッチリリースを公開し、続いて9月1日にEmergency Patch Release 3を公開しました。具体的には、当初の緩和策は公開のErrorページやExceptionページを使うリクエストに対処していましたが、研究者は同じ認可の不一致をHomeページにも応用できることを発見しました。これにより最初の緊急パッチはバイパスされ、より広範な保護が必要になりました。

推奨される対応:

  • アクセスの制限:PaperCut Application Serverのインターフェースへの、公開インターネットからのアクセスをただちに遮断してください。

  • Release 3の適用:すべてのプライマリApplication Server、Site Server、セカンダリ印刷サーバーにEmergency Patch Release 3をインストールしてください。

  • フォレンジックチェック:再起動やパッチ適用の前に、derby.logとserver\libに異常がないか調べてください。侵害が確認された場合は、インシデント前のバックアップからサーバーを再構築してください。

PaperCutのチェーンは、インターネットに露出した単一の致命的な欠陥に依存していたわけではありません。悪用されたのは層と層の食い違いでした。実行されるコンポーネントではなく表示されるページを認可するフレームワーク、ドライバーの入力を信頼するデータベースコネクター、そしてクエリをシステムコマンドに変換する同梱のランタイムです。

どのステップも、単独で見れば正当なアプリケーションの挙動に見えました。しかし組み合わさると、認証されていない攻撃者に特権でのサーバー実行を明け渡したのです。

🛠️ 今週のツール

コードブロックを出して終わるコーディングアシスタントでは、難しい部分は結局こちらに残される

質問をすると、モデルが50行のコードを生成し、その後の30分間、チャットウィンドウとエディターの間を手作業でコピー&ペーストする薄給の橋渡し役として過ごすことになります。それはペアプログラミングではありません。見ることも触れることもできないOSと、孤立した言語モデルとの間で通訳をしているだけです。

その断絶を解消するために作られたのがAntigravityです。

Googleが開発したAntigravityは、受け身のチャット補完からエージェント型の開発ワークフローへと焦点を移します。静的なテキストブロックを生成するだけでなく、モデルの推論をワークスペースでの実行に直接つなげます。ファイルを読み、ターミナルコマンドを実行し、テストの失敗を調べ、コード変更を反復します。

何が違うのか

Antigravityは、孤立したチャットボットをエディターに後付けするのではなく、CLI、IDE、スタンドアロンのオーケストレーションアプリケーションの間で共有されるエージェントハーネスを組み合わせ、並列サブエージェント、隔離されたworktree、Skills、MCP連携、範囲を限定した権限を備えています:

  • 自律的な実行と自己修正:Antigravityはワークスペース内で直接、ターミナルコマンドの実行、テストスイートの実行、エラーログの確認、パッチの反復を行い、変更をレビュー可能なアーティファクトとして提示します。

  • 並列サブエージェントと隔離されたworktree:複雑なタスクは、隔離されたgit worktreeで動作する専門のバックグラウンドサブエージェントに委任できます。これにより、メインのワークスペースを散らかしたり対話セッションを妨げたりすることなく、エージェントがドキュメントを調べたり、コードパスを追跡したり、リスクの高いリファクタリングを試したりできます。

  • SkillsとMCPによる拡張性:ハーネスは、モジュール式のSkills(スクリプトや参考資料を同梱できる再利用可能な指示パッケージ)とModel Context Protocol(MCP)サーバーによってチームのワークフローに適応し、エージェントに社内ツール、データベース、課題トラッカーへの直接アクセスを与えます。

  • 設定可能な権限制御:エージェントにシェルアクセスを与えるには明確な境界が必要です。Antigravityはデフォルトで、フォルダー単位に限定されたワークスペースアクセスと、ターミナルコマンド実行前の承認プロンプトを採用しています。さらに、ターミナルのサンドボックス化のプレビューサポートに加え、厳格な手動承認を求めるチームにも、より自由な自動フローを求めるチームにも対応できる、設定可能な実行ポリシーを備えています。

ワークフローの中で:テスト失敗の調査

バックエンドの変更が原因で、複数のサービスにまたがる統合テストが失敗するシナリオを考えてみましょう。

Antigravityなら、agyを対話的に起動するか、ターミナルから対象を絞ったプロンプトを実行できます:

agy -p "Investigate why tests/integration/test_auth_flow.py is failing and fix the regression"

そこから先は次のとおりです:

  1. コンテキストの収集:エージェントがテストファイルを調べ、ワークスペース全体で関連するサービスの依存関係を特定し、最近の変更をレビューします。

  2. 実行とログの確認:ターミナルで直接テストスイートを実行し、実行時のトレースバックを取得して、ヘッダー解析における根本的な不一致を特定します。

  3. 反復的なパッチ適用:エージェントが関連ファイルを修正し、pytest tests/integration/test_auth_flow.pyを再実行して修正を評価し、生成された差分とテスト出力を開発者のレビュー用に提示します。

開発者が直接使える3つの方法

Antigravityには、基盤となるエージェントアーキテクチャとやり取りする直接的な方法が3つあります:

  • Antigravity CLI(agy):高速なコマンドラインワークフロー、ヘッドレスなスクリプト実行(agy -p)、リモートサーバー環境向けに設計された、軽量なターミナルベースのインターフェース

  • Antigravity IDE:エージェント型の開発とコード編集のために作られた、AIファーストの統合開発環境

  • Antigravity 2.0:オーケストレーション、プロジェクトレベルの監督、スケジュールされたバックグラウンドタスク、サブエージェントの監視に重点を置いたスタンドアロンのデスクトップアプリケーション

置き換えられないもの

  • エンジニアリングとしての検証:Antigravityはテストを実行して失敗を調べられますが、成功が保証されるわけではありません。コードの変更、アーキテクチャ上の判断、エッジケースのテストには、引き続き人間によるレビューが必要です。

  • セキュリティの規律:範囲を限定した権限と承認プロンプトは意図しない操作から守ってくれますが、チームはワークスペースへのアクセスやAPIキーを設定する際、引き続き最小権限の原則に従うべきです。

オートコンプリートは、コードがどうなりそうかを提案するだけです。

Antigravityは推論を実行につなげ、開発者がより速く確認、テスト、反復できるようにします。

LinkedInでフォローする

👏 今週の人物

Tanya Janca

アプリケーションセキュリティには、遅れてやって来て、略語で話し、開発者に何を間違えたかを告げるという評判があります。

Tanya Jancaはキャリアの多くを、その評判を変えることに費やしてきました。

オンラインではSheHacksPurpleとして知られるTanyaは、アプリケーションセキュリティの専門家であり、セキュアコーディングのトレーナーであり、Alice and Bob Learn Application SecurityとAlice and Bob Learn Secure Codingの著者です。彼女の仕事は、開発者が必要とする技術的な中身を削ぐことなく、セキュリティを親しみやすいものにしています。

テクノロジー業界での30年近いキャリアの中で、彼女はアプリケーションを構築・保護し、何千人もの開発者を育成し、We Hack Purple、OWASP DevSlop、WoSEC、#CyberMentoringMondayなどのコミュニティの立ち上げに携わってきました。

現在はShe Hacks Purple Consulting、DevSec Stationポッドキャスト、そして一般向けの教育活動を通じて、安全なAPI設計からAI生成コードがもたらすリスクまで、幅広いテーマに取り組み続けています。

アプリケーションセキュリティをより実践的で親しみやすく、行動に移しやすいものにしてきた功績をたたえ、Tanya Jancaを今週の人物に選びました。

📅 今週のイベント

LABScon 2026

2026年9月16日〜19日・アリゾナ州スコッツデール

LABSconは、セキュリティ研究者、脅威ハンター、調査報道ジャーナリストが一堂に会し、脆弱性、エクスプロイト、進化する脅威アクターに関する最新の研究を共有するイベントです。

今年のアジェンダは、AIが統制するサイバー犯罪、エージェント型のアタックサーフェス、モバイルでの悪用、新たな防御ツールにまで及びます。自律システムがセキュリティ境界の両側でますます高い能力を持つようになる中、特に関連性の高い内容です。

従来の業界展示会とは異なり、LABSconは招待制の研究重視のイベントで、ベンダーホールや製品の売り込みはありません。

📚 今週の本

ほとんどのハッカーはツールの使い方を知っています。しかし、コードがプロセッサーに届いた後に何が起きるかを理解している人ははるかに少数です。

Heavy Wizardry 101では、Picoの名で知られるDavid Martínez Oliveiraが、読者をそうした抽象化の下へと導きます。本書はコンピューターアーキテクチャ、メモリ、C言語、アセンブリから始まり、シェルコード、ローダー、バックドア、ドロッパー、自己増殖型ワームへと進みます。

例はx86_64、ARM、MIPS、RISC‑Vにわたり、同じオフェンシブの概念がアーキテクチャによってどう変わるかを示しています。目的は既存の手法を再現することだけでなく、自分で作れるほど深く理解することです。

今週のPaperCutの研究にふさわしい一冊です。データベース、ランタイム、OSのプロセスが別々のブラックボックスに見えなくなれば、エクスプロイトチェーンははるかに追いやすくなります。

😅 今週のミーム

より低コストのモデルで同じ検証済みのセキュリティ結果に到達できるなら、追加料金を払って実際には何を買っているのでしょうか?

The Breach Brief、Ostorlabチーム