はじめに
AIコーディングが話題になると、どうしても「どれだけ速くコードを書けるか」という生産性の向上に注目が集まります。もちろん、開発速度の向上は大きな変化であり、私自身もその恩恵を強く実感しています。
しかし、ソフトウェア開発における真のコストは、コードを作成した後に発生します。
「なぜこの設計を選んだのか」「どのファイルが複雑化しているのか」「どこから読み進めれば全体像を把握できるのか」。コードを書く速度がどれだけ向上しても、このように過去の文脈を掘り起こす業務は、開発者の前に残り続けます。
開発チームのリポジトリには、往々にして「誰も全容を説明できないコード」が存在します。
「なぜこの設計に落ち着いたのか」「なぜ特定のディレクトリだけが妙に複雑なのか」「なぜこのファイルばかりが頻繁に修正されているのか」。これらは気になる疑問ではあるものの、日々の機能開発のなかでは後回しにされがちです。
Gitのログを遡り、過去のコミットメッセージを読み解き、変更頻度の高いファイルを特定して当時の設計意図を推測する。私は、こうした一連の作業を「コードの考古学」と呼んでいます。
このような性質を持つ業務こそ、まさにAgentic Automationの絶好の題材です。人間が常時付き添う必要はありませんが、調査結果がドキュメントとして残れば、将来的に大きな価値をもたらすからです。
前回は、ホワイトボードの写真1枚からUIを生成する「Visual-to-Code」を解説しました。前回は「Visual-to-Code」が人間とAIが伴走して開発を進めるスタイルだったのに対し、今回は人間が眠っている間にAIが自律的に稼働する仕組みを取り上げます。
ただし、本記事の主役はAI考古学者そのものではありません。
AIに任せるべきタスクを定義し、実行するためのハーネス（仕組み）を構築し、出力を確認しながら継続的に改善する。つまり、「コードを出力するシステム自体を育てるアプローチ」について詳しく解説します。
いまなら何で組むか
Agentic Automationを実装する場合、まずは各種SDKの選定から検討します。例えば、ClaudeであればClaude Agent SDK、CodexならCodex SDKが挙げられます。
Claude Agent SDKを使用すると、Claude CodeのエージェントループをTypeScriptから呼び出すことが可能です。関数であるquery()にプロンプト、作業ディレクトリ、ツールの実行権限、最大ターン数を指定できるため、「リポジトリを網羅的に調査し、特定のフォーマットでファイルを出力する」といったタスクに適しています。実際に実装する際は、権限設定のドキュメントも併せて確認してください。
Codexで組む場合は、Codex SDKが対応します。プログラムからCodexのエージェントを起動でき、スレッドを開始してプロンプトを渡すと、応答や生成物を構造化された形で受け取れます。OpenAIはCI/CDパイプラインへの組み込みや社内ツール化といった用途を想定しており、Claude Agent SDKと同様、無人で調査タスクを回すヘッドレスな自動化に向いた、近いレイヤーの選択肢です。
なお、Codexには、SDKとは別にCodex App Serverという仕組みも用意されています。これは、リッチクライアントとの統合を主眼に置いた仕組みです。認証機能、会話履歴の管理、ユーザーによる承認、エージェントの進行イベントなどをハンドリングできるため、社内プロダクトへ「エージェントを操作する画面」を組み込むようなユースケースにおいて有力な選択肢となります。
複数のエージェントを統括するマネージャーエージェントを配置し、調査・実装・レビューなどの各担当へタスクを割り振るマルチエージェント構成も考えられます。しかし、最初から複雑な構成を選択すると、システムの運用やデバッグのオーバーヘッドが大きくなりがちです。まずは、単一のタスクを1つのハーネスで確実に、再現性高く動かす最小構成から始めるべきです。役割分担やマルチエージェント化を検討するのは、その最小構成での実行結果を評価してからでも遅くはありません。
