Claude でサイバー調査官を構築した方法

Claude を活用した複雑で長期実行型のエージェント構築の裏側

Outtake は Recon Agent の開発を、およそ 4 つの段階を経て行いました。各段階では、「優れた調査とは何か」を理解し、その判断基準を順次エージェントに委譲していくプロセスでした。

ステップ 1: まず専門家の視点を持つ

エージェントの構築に着手する前に、Outtake のエンジニアたちは実際にサイバー調査を自ら行い、顧客や設計パートナーからドメイン固有の知見を引き出しました。

ここで目指したのは、「良い調査」の基準を明確にすることです。この種の調査においては、どの証拠が重要なのか、どのように整理すべきか、そして単なる推測と実行可能な結論を分けるものは何かを特定することが求められます。この基準は、その後のすべての段階において参照される固定された指針となりました。

「長期実行型エージェントを構築する上で最も重要なのは、*何が成功と言えるのか*、*エージェントが果たすべき役割は何なのか*を本当に理解することです」と、Outtake のエージェントプラットフォーム責任者である Jack Hayford は語っています。「なぜなら、最終的にはエージェントがそのタスクを毎回確実に遂行できることを保証しなければならないからです。」

ステップ 2: Claude Code でプロトタイプを作成

当初、Outtake チームは従来のエージェントフレームワークを用いて、標準化された調査プロセスの自動化を進めました。

しかし、彼らはすぐに、Recon Agent は単なる調査ツールでは不十分だと気づきました。コードの記述や実行、その場でツールの構築、そして悪意のあるドメインとの実際の相互作用が必要だったのです。

「すべての調査は異なり、非常に技術的なものです」と Hayford 氏は語ります。「エージェントにはコーディング能力が不可欠でした。Claude Code は、これらの仮説を実証し、より多くの実験を開始するための強力な初期の基盤となりました。」

Claude Code でプロトタイプを作成する過程で、彼らは中核となる設計原則を確立しました。つまり、ドメイン調査時には「常に X、Y、Z を行う」ようにオーケストレーションレベルでエージェントを厳格に制約しつつ、判断が必要な場面では自由に即興できる余地を残すというものです。

ステップ 3：本番環境向けのハネスへ移行

「Claude Code が導入したパターンは非常に気に入っていましたが、私たちが自ら構築しようとしていない、より低レベルなプリミティブへのアクセスが必要でした」と Hayford 氏は述べています。

Recon Agent を本番環境で運用するために、Claude Agent SDK の利用は自然な次のステップでした。Claude Code からスキルやパターンを引き継ぐことで、エージェントループの再構築やセッション処理をやり直すことなく、Recon Agent のメモリ、コンテキスト、ファイルシステムに対する制御を強化しながら、開発速度を落とすことなく移行することができました。

ステップ 4：評価（evals）に駆動された、密なイテレーションループを構築する

攻撃者が防御ツールの存在を知った瞬間に適応してくるサイバーセキュリティの分野では、低コストかつ迅速に試行錯誤できる能力が特に重要です。チームは開発初期からエージェントの評価（agent evals）を取り入れ、複数のシナリオを同時に実行できる強力な評価スイートを実現しました。これにより、モデルのアップグレードやメモリーシステム全体の再構築といった大規模な変更も、安全かつ確信を持って行えるようになりました。

また、この仕組みによってチームは「エージェントのループ」から自らを解放することも可能になりました。例えば、リコン（偵察）エージェントが調査を終えて報告する際、「もしあのツールがあればもっと良くできた」といったフィードバックがあったとします。すると、別のコーディングエージェントがその提案を読み取り、新しいツールを作成し、それを試すためのテストシナリオまで構築してくれます。

人間が結果を確認するのは、非常に最後の段階だけです。「このツールを使えば、エージェントは調査をより良く行えたのか？」という問いに答えるためにのみ介入します。ハイフォード氏はこう述べています。「私たちがボトルネックになっています。こうした長く複雑なエージェントを作る際、フィードバックループを自動化することが極めて重要です。開発者にとって、それは圧倒的に速く、かつやりがいのある作業になります。」

長時間稼働するエージェント構築からの教訓

エージェント黎明期には、暴走を防ぐために、ビルダーは事前にハードコードされた決定論的なステップバイステップのパスでエージェントの動作をスクリプト化していました。現在では、そのような複雑なワークフローは、メモリー、ツール、スキル、ガードレールからなる支援環境である「ハネス（harness）」へと置き換えられつつあります。

Outtake チームが Recon Agents の構築に取り組んだ経験から得られた教訓をいくつか紹介します。

ツール：ファイルシステムと Bash で十分です

ファイルシステムは、コンパクション後も記憶を保持する手段となります。エージェントには通常、非常に具体的で微妙なツールが与えられますが、ファイルシステムに加えてコードの書き込み・読み込み・実行機能を付与することで、障害が発生した際にエージェントが柔軟に対応できるようになります。

「極めて強力なオープンエンドのツールや機能を与えると、それは大きな飛躍となります。ネットワークの一時的な不具合などでツールが失敗した場合でも、エージェントは適切な回避策を見つけ、そのまま作業を継続するケースをよく目撃しました」と Hayford 氏は語ります。「私たちが構築したハッチ（枠組み）全体が強力だったこと、そしてこれらの強力なオープンエンドのツールによって即興的な対応の余地を残したことのおかげで、最終的に成功へと導くことができました。」

プロンプトは提案に過ぎない

プロンプトは必要に応じて柔軟性をもたらしますが、可能であればハードコーディングすることで安定性を確保します。「時間とともに複雑化していく長期稼働型エージェントを構築する際、プロンプトはあくまで提案です」と Hayford 氏は指摘します。「エージェントが意図したとおりに動作しなかった場合、自然な対応として最も変更しやすい部分に手を加えたくなります。システムプロンプトに『X が起きたら Y を行うようにしてください』といった指示を挿入するのは、最初は有効かもしれません。しかし、このエージェントが長く稼働するにつれて、プロンプト内の単語は最終的にすべて無視されるようになるでしょう。」

正しいアプローチは、エージェントが常に実行すべき行動を特定し、それをガードレールとして組み込むことです。彼はこう言いました。「これらの要素をプロンプトから抜き出し、ハネス（制御枠）に配置するのです。そうすれば、エージェントはそれについて考える必要がなくなり、より多くのコンテキストスペースと注意リソースを、実際に成果を出せる領域に集中させることができます。」

Claude の指示に関するベストプラクティスや、各手法のコンテキストコストと権限について詳しくは、こちらをご覧ください。

評価（Evals）は信頼性だけでなく速度のためにもある

手動での「振り返り」をロードマップとして活用し、開発サイクルを加速させる自動化された評価を導入しましょう。一般的には、評価は信頼性を確保するための品質ゲートと見なされがちです。しかし、長時間稼働するエージェントにおいては、より大きなメリットは速度の向上にあります。

初期段階では、リコンエージェント（偵察エージェント）が実行されるたびにチームが手動でそのパフォーマンスを検証していました。しかし、30 分間にわたるすべての行動を記録したトランスクリプトを読み込むのは過酷であり、スケーラブルではありません。

「現代のエージェント開発において、出力の評価はループ内で最もコストのかかる工程です」とジャックは述べています。

評価とは、単にその振り返りを構造化し、 grading（採点）可能で自動化できる形にしたものに過ぎません。良い状態の基準を反復可能なチェックとしてコード化すれば、エージェントを審査役の席に着かせて、30 分間のトランスクリプトを読み込み、実行結果をスコアリングさせることができます。

「評価（evals）を構築することには、一部のエンジニアが不安を感じているようです。それは完璧なケースを作るようなものだと捉えられがちだからです」とジャックは語ります。「最初から評価のバージョンを作成し始めれば、それが公式かどうかや『完璧』であるかにかかわらず、エージェントの開発スピードは上がります。」

エージェントを守る

プロンプトインジェクション は現実的な脅威です。そのため、エージェントをサンドボックスに隔離するか、防御手段を与えることが不可欠です。Outtake チームが Claude を選んだ理由の一つも、プロンプトインジェクションに対する強固な耐性にあります。

「 Recon エージェントの構築において、セキュリティは非常に重要な要素です」とハイフォード氏は話します。「私たちはファイルシステムと Bash を提供し、敵対的な環境にエージェントを送り込みます。そこで最も解決すべき課題は、エージェントを敏感な内部情報から隠しつつ、その機能を阻害しないような『爆発ボックス（blastbox）』のような仕組みを作ることでした。」

彼らのアプローチでは、エージェントが乗っ取られる可能性も想定しています。そのため、周囲のシステムは被害を封じ込めるように設計されています。ただし、セキュリティ対策はエージェントの目的によって異なり、すべてのエージェントが爆発ボックスの対象になるわけではありません。

Outtake は、エージェントがインターネットにアクセスする瞬間の信頼性を評価し、その直前の地点でチェックポイントを実装しています。このチェックポイントは、エージェントが触れようとするあらゆる対象を精査します。「このページはなりすましではないか？マルウェアではないか？今まさにプロンプトインジェクションを試みてはいないか？」といった問いに答える仕組みです。これは、敵対的な環境が増加するインターネットを横断するエージェントにとって、まさに必要な装甲となる可能性があります。

今後の展望

Recon Agent は現在、実際に調査活動を開始しています。Outtake がどのように Claude を活用して大規模な敵対インフラをマッピングしているかについて詳しく知りたい場合は、以下のリソースをご覧ください。

• ウェビナーの全文はこちら：Claude を活用した脅威インフラの自動調査とマッピング手法について、ライブデモ付きで詳しく解説しています。
• Recon Agent の実働様子を見る：単なるなりすましから、完全な脅威アクターのプロファイルへと展開するエージェントの動きを確認できます。
• 無料で Recon Agent 評価を受ける：自社の暴露状況について、調査によって何が明らかになるかを実際に体験してください。