課題
新しいチームに加わりました。企業を買収しました。重要な依存関係のメンテナンスが止まり、誰かが評価しなければなりません。コードベースは膨大で、時間は限られています。
従来のやり方では、ファイルを開き、grep で探し回り、何週間もかけて頭の中に全体像を組み立てます。単一エージェントのやり方では、ファイルを Claude に貼り付けて質問しますが、会話は一度に 1 つずつで、セッションが終わるたびにコンテキストが失われます。
どちらもスケールしません。50 万行のコードベースには数百のモジュールがあります。1 つのエージェントがコンテキストに保持できるのは、品質が落ち始めるまでにおそらく 20 ファイル程度です。数十回のセッションを順番にこなす必要があり、そのうえ調査結果の統合は結局自分で行わなければなりません。
「私は頭も切れるし、能力もあるし、プログラミング経験も豊富だ。それでも、1 つの Claude エージェントの出力をきちんとレビューできるだけの集中力を保つのがやっとだ」。petesergeant、HN
1 つのエージェントの出力でさえ消化するのが難しいのなら、見たこともないコードベースについて 40 の別々のセッションから得た調査結果を統合するところを想像してみてください。
Chief ができること
コードベース全体を並列で読む
Chief は監査の目標を並列の読解タスクに分解します。モジュール、サービス、レイヤーごとに 1 つのエージェントを割り当てます。エージェントはコードベース全体に同時に展開し、それぞれが範囲の限定されたスコープで作業するため、焦点の絞られたコンテキストが保たれます。同時に動かせる数は、お使いのエージェントのサブスクリプションが許す限りです。Chief のリファクタリングワークフローを支える並列実行を、純粋な分析に応用したものです。
監査の目標はあなたが決め、読むのはエージェント
知りたいことを Chief に伝えてください。「すべてのデータベースアクセスパターンをマッピングし、N+1 クエリを指摘して」「すべての認証境界を見つけ、信頼モデルを文書化して」「すべての外部 API 依存関係とその障害モードを特定して」。Chief が監査計画を提案し、エージェントがそれを実行します。Auto mode を有効にすると、監査トラックはタスク上限とプロバイダー利用量の週ごとの上限の範囲内で、無人で実行されます。あなたがソースファイルを開くことは一度もありません。
サマリーが調査結果をまとめる
各エージェントは監査基準に沿って構造化された調査結果を報告し、Chief はすべての結果をマイルストーンの受け入れ基準と照らし合わせてレビューします。Chief のサマリーは、すべてのモジュールにわたる調査結果を集約します。エージェントの生のトランスクリプトではなく、行動に移せる整理された結果です。あなたの判断が必要な調査結果は、あなたの To-Do リストに追加されます（早期アクセス）。
監査の観点ごとに異なるエージェントを
アーキテクチャ分析には Claude Code、機械的なパターン検出には Codex、テストカバレッジの評価には Qwen Code を使いましょう。Chief の BYOA モデルなら、監査のマイルストーンごとにエージェントを選べます。セキュリティレビュー、依存関係のマッピング、デッドコード検出、API サーフェスの棚卸しが、すべて並列で実行されます。
監査セッションをまたいで引き継がれるコンテキスト
Chief はすべてのエージェントセッションにわたってプロジェクトレベルのコンテキストを維持し、調査結果を引き継ぐため、後続のタスクは先行タスクの発見を土台にできます。あるエージェントが「認証モジュールは共有ミドルウェア層に処理を委譲している」と発見すれば、ミドルウェアを監査するエージェントはその情報を踏まえた状態で作業を始めます。ゼロからのスタートも、同じ発見の繰り返しもありません。
コードベース監査が並列エージェントに向いている理由
1. 読解は極めて並列化しやすい
コードベースの監査は純粋に読み取りの作業です。各モジュールは独立して分析できます。マージコンフリクトも依存関係の順序もありません。あるのは、同時に的確な分析を必要とする数百のファイルだけです。これはまさに Chief の並列ディスパッチに向いているワークロードです。
2. 単一エージェントのコンテキスト崩壊が監査品質を台無しにする
500 ファイルを読む 1 つのエージェントからは、浅く一般的な所見が出てきます。50 ファイルずつ読む 10 のエージェントからは、深く具体的な調査結果が出てきます。Chief は各エージェントを最も力を発揮できる状態、つまり限定されたスコープと焦点の絞られたコンテキストに保ちつつ、コードベース全体の像を統括します。
3. 難しいのは統合。それを Chief が担う
価値があるのは個々のエージェントの調査結果ではなく、それらすべてを統合した全体像です。Chief は各トラックを基準と照らし合わせてレビューし、すべてのエージェントの調査結果を整理された監査レポートにまとめます。あなたがレビューするのは生の出力ではなく、統合結果です。
4. 監査は繰り返される。そして Chief は覚えている
四半期ごとのセキュリティレビュー、買収前のデューデリジェンス、コンプライアンスチェック、メジャーアップグレード前の依存関係監査などがあります。Chief の永続的なプロジェクトコンテキストにより、各監査は前回の成果の上に積み上がります。Chief がすでにコードベースの構造を把握しているため、2 回目の監査はより速く進みます。
事例：40 万行のコードベースに対する買収前の技術デューデリジェンス
1. 監査の目標を設定する。 CTO が Chief を開き、プロジェクトレベルの目標を設定します。「買収対象企業のバックエンドコードベースの技術デューデリジェンスを完了する。アーキテクチャの品質、セキュリティ態勢、スケーリングのボトルネック、技術的負債を評価する。」
2. Chief が監査計画を提案する。 Chief はリポジトリの構造を分析し、5 つの並列監査トラックを提案します。
- トラック 1：アーキテクチャのマッピング。サービス境界、データフロー、依存関係グラフを調査します（6 つのサービスに 6 エージェント）。
- トラック 2：セキュリティ監査。認証境界、入力検証、シークレット管理、OWASP サーフェスを調査します（3 エージェント）。
- トラック 3：データ層の分析。スキーマ設計、クエリパターン、マイグレーション履歴を分析し、N+1 を検出します（2 エージェント）。
- トラック 4：インフラとデプロイ。CI/CD、コンテナ設定、スケーリング特性を調査します（1 エージェント）。
- トラック 5：コード品質のシグナル。テストカバレッジ、デッドコード、依存関係の鮮度、エラー処理パターンを分析します（3 エージェント）。
3. エージェントが展開する。 CTO は計画を承認し、タスク上限とプロバイダー利用量の週ごとの上限を設定して Auto mode を有効にします。Chief は読解タスクを並列にディスパッチします。各タスクのスコープは限定されており、同時実行数は CTO のエージェントのサブスクリプションが許す限りです。エージェントはコードを読み、分析し、構造化された基準に沿って調査結果を報告します。コードは一切変更されません。純粋な分析です。
4. どこからでも進捗を確認。 CTO は取締役会の最中にスマートフォンで進捗を確認します。トラック 1 は 80% 完了しています。トラック 2 は重大な指摘事項を 3 件挙げました。2 つのサービスでのシークレットのハードコードと、管理者用エンドポイントでの認証チェックの欠落です。認証の問題は、CTO にしか下せない判断が必要な事項として CTO の To-Do リストに追加されます（早期アクセス）。トラック 3 は 14 件の N+1 クエリパターンを特定しました。
5. 統合レポート。 Chief は 5 つのトラックすべての調査結果を構造化されたデューデリジェンスレポートにまとめます。重大なセキュリティ問題 3 件、パフォーマンスのボトルネック 14 件、データ層における中程度の技術的負債、そして全体としては堅実なアーキテクチャという内容です。CTO はソースファイルを 1 つも開くことなく、包括的な技術評価を手にしました。
6. 結果。 通常ならエンジニアリングチームで 2〜3 週間かかるデューデリジェンスが、約 1 日で完了しました。各エージェントは限定されたスコープについて焦点の絞られたコンテキストを維持しました。すべての調査結果は特定のモジュールとファイルまで追跡できます。CTO は直感ではなくデータに基づいて買収の推奨を行いました。
プランに関する注記。 この規模の監査は Free プランの 1 日 30 タスクを大きく超えるため、Pro 向けのユースケースです。Free プランでは、まず 1 つか 2 つのトラックから始めてください。
Chief を使うべきとき
- 見たこともないコードベースを理解する必要がある場合：転職、買収、引き継いだプロジェクト、オープンソースの依存関係の評価などです。
- コードベースが 1 つのエージェントには大きすぎる場合：数十のモジュールにまたがる数百のファイルがあり、単一のコンテキストウィンドウに収まりきりません。
- 生のトランスクリプトではなく、構造化された調査結果が必要な場合：セキュリティ態勢、アーキテクチャの品質、技術的負債の評価、コンプライアンスの検証などです。
- 監査に時間的な制約がある場合：デューデリジェンスの期限、インシデント対応、移行前のリスク評価などです。
- 並列エージェントがコードベースの異なる部分を同時に読みます：限定されたスコープをそれぞれ分析する 10 のエージェントは、すべてを流し読みする 1 つのエージェントよりも深く具体的な調査結果を出します。
よくある質問
従来のコードレビューツールとは何が違うのですか？
従来のコードレビューツール（GitHub の PR レビュー、Reviewboard、Gerrit など）は、コードへの変更を評価します。Chief のコードベース監査は、コードそのものを評価します。差分をレビューするのではなく、既存のコードベース全体を読んで分析するようエージェントをディスパッチするのです。プルリクエストのレビューと、企業の技術スタック全体の監査ほどの違いがあります。
Chief はファイルを一切変更せずにコードベースを監査できますか？
はい。コードベース監査は純粋に読み取りのみの操作です。エージェントは分析し、調査結果を報告し、結果を提示します。ファイルの変更もブランチの作成も行われません。Chief は読解を調整し、調査結果を統合します。
エージェントが浅く一般的な所見を出すことを、Chief はどう防ぐのですか？
各エージェントのスコープを限定することによってです。1 つのエージェントに 500 ファイルを理解させようとする代わりに、Chief は 50 ファイルずつ分析する 10 のエージェントをディスパッチします。スコープが限定されていれば焦点の絞られたコンテキストが保たれ、具体的で行動につながる調査結果が得られます。そのうえで統合レイヤーがエージェント間の知見をつなぎ合わせます。
Chief ではどのような監査をオーケストレーションできますか？
既存のコードベースに対するあらゆる構造化された分析です。セキュリティレビュー、アーキテクチャのマッピング、依存関係の監査、技術的負債の評価、コンプライアンスの検証、移行前のリスク分析、テストカバレッジの評価、API サーフェスの棚卸し、デッドコード検出、パフォーマンスのボトルネックの特定などに対応します。
コードベース監査に最適なエージェントはどれですか？
エージェントごとに得意な監査の観点が異なります。Claude Code はアーキテクチャの推論とセキュリティ分析に強く、Codex は機械的なパターン検出をうまくこなします。Chief の BYOA モデルなら、監査トラックごとにエージェントを選べ、すべてを 1 つのダッシュボードで調整できます。
Chief は以前の監査の調査結果を覚えていますか？
はい。Chief はプロジェクトレベルのコンテキストを永続的に維持します。四半期ごとのセキュリティ監査を実行するとき、Chief は前回の監査からコードベースの構造を把握しています。繰り返しの監査はより速く進み、前回の評価以降に変わった部分に集中できます。
複数のコードベースを同時に監査できますか？
はい。各リポジトリはそれぞれ独立した Chief プロジェクトとなり、すべてのプロジェクトが 1 か所にまとまるため、複数のリポジトリにまたがる監査を同時に実行できます。複数リポジトリを持つ企業の買収に伴うデューデリジェンスや、プロジェクト横断のセキュリティ点検に便利です。Free プランでは 5 プロジェクトまで利用でき、Pro では上限がなくなります。
コードベース監査に Chief を無料で使えますか？
はい。Free プランには、5 つのプロジェクトと、ご自身のエージェントによる 1 日 30 タスクが含まれ、クレジットカードは不要です。Pro ではこれらの上限がなくなり、早期アクセス機能が追加されます。多数の読解タスクに分割される大規模な監査では、通常 1 日 30 タスクを超えるため、Pro 向けのユースケースです。