コードが希少でなくなったあと（その2）：AI がコードを書くことから、AI がデリバリーに参加することへ

気づけば、前の会社を離れてもう一年になります。この一年でたくさんのことを学び、以前なら想像もできなかったことも数多く経験しました。

私の選択を理解しがたいと感じる人は多く、私自身もうまく正確には説明できません。結局のところ、ただ面白いことをやりたかっただけです。

この記事で書くのは、その中の一つ、AI 時代に私たちが構築を試みている新しいデリバリーワークフローです。8月に初版を書きましたが、最近このやり方について話を聞きに来る人が少なくないので、ここ数か月の実践をここに反映しました。

最近、オープンソース界の大御所である yetone さんも自身のワークフローを公開しました。照らし合わせてみると、核となる考え方はほぼ同じところに行き着いていました。私たちの金融業務では、どうしても外せない人によるレビューとテストが追加で求められ、それが自動化をどこまで進められるかも決めています。自動化に向いた実行は Agent に任せ、重要な業務判断とリリースの承認は人に残しています。

現在このワークフローの中心は Claude Code と Claude Opus 5.5 です。Codex は調査、開発、受け入れ検証に参加し、Grok Bot は独立した CR と検証を担当します。ルール、手順、証拠はすべてエンジニアリングシステムの中に残してあり、他の実行者も引き継いで使えます。ただし、引き継げることと同じ成果を出せることは別です。現時点での私たちの使用感では、他のモデルや Agent に替えた場合、同じ成果が得られるとは限りません。

私たちが保守しているのは、複数のリポジトリにまたがる金融業務システムで、一つの要件がフロントエンド、ミドルプラットフォーム、ドメインサービス、外部チャネルを横断することもあります。ここでは、モデルにコードを書かせること自体は難しくありません。難しいのは、変更すべき箇所を見つけ、業務上の制約を守り、そのうえで変更後も結果が正しいことを証明することです。

8月から10月までの主要3リポジトリの記録をざっくり集計すると、約 1,900 件の変更 PR が release に入り、そのうち約 1,800 件は成功した本番デプロイまで追跡できます。同期間に、納品済みバージョンの業務コードとテストコードのスナップショットでは約 63 万行 が追加され、約 6 万行 が削除されました。そのうち追加されたテストコードは約 29 万行 です。コード量は期首と期末のスナップショットで比較しており、PR ごとの変更量を合算したものではありません。これらの数字は実際のデリバリーの規模を記録したものです。追加されたソースコードの半分近くがテストであり、これは検証に対する私たちの投資を表しています。

下の図が、現在の私たちのデリバリーの全体像です。

図に描いているのは、デリバリーを軸に築いた役割分担とフィードバックの関係です。起点では人が目標と受け入れ基準を明確にします。開発、レビュー、修正、再レビューは Agent が継続的に進めます。変更はまずテスト環境で検証され、そのうえで人がマージとリリースを承認します。すべての段階で同じルール、ツール、記録を共有しています。

人をこれらの箇所に残しているのは、私たちの意図的なトレードオフです。資金のセマンティクス、権限の境界、リリースのタイミングについての判断を誤れば、ユーザーの資金に影響する可能性があり、コードをロールバックしても、すでに発生した取引を取り消せるとは限りません。こうした判断の根拠は、リポジトリの中にないことも多いのです。Agent は証拠を揃え、リスクを示すことができます。受け入れ基準が成り立つか、業務上のトレードオフを受け入れられるか、いつ本番に入れるかは、人が決め、人が責任を負います。

プラットフォームは替えず、既存のエンジニアリングの現場で組み立てる

Agent 化を進めるとき、自然な衝動はプラットフォームを替えることです。要件をもっと見栄えのよいボードに移し、タスクを振り分けられるコンソールをつなぐ。私たちも Issue、ローカルの Agent、実行状態をつなげられるいくつかの方式を検討しましたが、最終的には GitHub Issue を残し、ローカルで Claude Code と Codex を使い続けることにしました。

こうした実行者はエンジニアと同じ場所で働き、同じリポジトリ、同じ CLI、同じテストとデプロイスクリプトを使います。要件、決定、レビュー、CI の結果はもともと GitHub にあります。これらの事実を複製するために別のプラットフォームを導入すれば、同期や競合に対処しなければなりません。

こうした実行者の強みは、現場の読み取りと実際の操作を一続きにできることです。あるとき、UAT のリリースが Progress Deadline Exceeded で止まりました。以前の分担なら、当番の同僚からプラットフォーム担当の同僚、さらにバックエンドへと引き継いでいくところです。そのときは、リポジトリ、対象環境、障害の現場をそのまま Codex に渡しました。Codex は Deployment、Pod、起動ログをたどって調べ、クラスタに問題がないことを確認し、本当の原因はあるコールバックハンドラーが Spring にロードされていなかったことだと突き止めました。修正と検証を済ませて PR を出し、別のモデルが独立してレビューし、最後にエンジニアが CR を行いました。

そのため、自動化を一つ追加するときは、通常まず信頼できる実行の入り口と明確なルールを用意し、例外の分岐ごとに専用のフローを先に設計する必要はないと考えています。前提として、Agent の判断は検証を受けなければならず、ツールの権限とタスクの範囲は明確でなければなりません。

役割分担はタスクごとに調整することもできます。10月のあるリポジトリ横断のレビューでは、修正を Claude に、受け入れ検証を Codex に任せ、両者は同じルールと同じ PR 群を使いました。

ルール、手順、状態はすべてエンジニアリングシステムに残す

人同士の協働なら、多くの背景は「前回のあの問題」の一言で補えます。Agent にはそうした阿吽の呼吸がなく、新しいセッションを開けば、以前の背景が引き継がれるとは限りません。ここを解決しなければ、エンジニアはコンテキストの運び屋になってしまいます。

私たちのやり方は X as Code（XaC）と呼んでいます。ルールはバージョン管理でき、手順は実行でき、事実と状態はエンジニアリングシステムに残る、というものです。Issue と PR は要件と決定を記録し、AGENTS.md とトピック別の規約は制約を記録し、Skill とスクリプトは繰り返し行う手順を担い、CI は決定的なチェックを行い、インフラは Terraform で記述します。業務上のトレードオフは依然として文章です。たとえば、チャネル側は成功したのにローカル側で失敗した場合にどう処理するか、といったものです。こうした文章は Issue やコードコメントに書き、見つけられ、参照でき、古くなったときにも気づけるようにしています。

主要なリポジトリの CLAUDE.md は、同じディレクトリの AGENTS.md に直接リンクしています。実行者ごとに別々のコピーを保守していたら、ルールは遅かれ早かれ分岐します。

ルールをどこに置くかは、どれだけ読む必要があるかも左右します。初期の頃は、問題が一つ起きるたびに AGENTS.md に一項目を追加していました。何度か繰り返すうちに、フロントエンドの小さなコンポーネントを一つ直すだけでも、まず資金やトランザクションの背景を大量に読まなければならなくなり、肝心のルールがかえって埋もれてしまいました。そこで、タスクに応じて段階的に読む方式に改めました。

Agent はまずリポジトリ全体の制約と作業の入り口を読み、変更がどのディレクトリに入るかに応じて、そのディレクトリの境界を読みます。次にトピック索引を通じて、今回関係する金額、トランザクション、テナント、契約のトピックにだけ入ります。最下層はコード、テスト、実行時の証拠で、それまでの理解を検証するために使います。実装済みの振る舞いを確認するときは、コードがコメントに優先し、コメントがドキュメントに優先します。

だからドキュメントには、コードから読み取れないことだけを書きます。役割、境界、資金のセマンティクス、設計上のトレードオフ、これまでに踏んだ落とし穴などで、クラス一覧やフィールド表は複製しません。コード構造を複製したドキュメントは遅かれ早かれ古くなり、Agent も新しい同僚もそれに従って誤った結論を導いてしまいます。私たちは記述が実際の実装と一致しないドキュメントを整理し、使われない Skill もロード対象のディレクトリから外しました。コンテキストは満杯にする必要はなく、十分に正確であればよいのです。

主要なリポジトリのルールは「シンプルさ優先」を第一項に置いています。再利用できるなら新しい抽象化を追加しない。新しい状態を追加する前に、それが独立した業務上の意味を表すことを証明する。レビューではよくこう問います。この設計を削除しても、要件は満たせるか？ 満たせるなら削除する。AI は小さな要件を、ついでのリファクタリングにしてしまいがちです。このルールはデリバリーの規模を抑え、次に引き継ぐ人が理解しなければならないことも抑えています。

ルールは実践に合わせて更新し、レビュアーも実際にどの経路を確認したかを説明しなければなりません。

独立したレビューと、人が催促しなくても進むフォローアップ

8月以降の最大の変化は、CR と独立した検証を Grok Bot に任せたことです。実装者は引き続きセルフテストを行い、CI は引き続き決定的なチェックを行い、人は重要な業務判断に責任を持ちます。

独立したレビューが必要なのは、実装者のセルフテストが実装時の前提をそのまま引きずりやすいからです。Grok Bot は要件とリポジトリのルールから出発し、実装者が証明していない部分を確認します。そうした部分は diff の外にあることが多いのです。たとえば出金処理なら、送信 API が冪等になっているかだけを見るのでは足りず、呼び出しチェーンに沿って補償タスク、手動リトライ、Webhook まで見る必要があります。チャネル側は成功したのにローカルへの書き込みが失敗した場合、もう一度実行したらどうなるのか、ということです。

検証方法はタスクごとに決めます。コード、テスト、CI の証拠を確認することもあれば、テスト環境で実際に API や画面を動かし、デプロイ結果を確認することもあります。レポートでは、実際に実行したもの、既存の証拠と照合しただけのもの、まだ検証していないものを区別しなければなりません。独立したレビュー、CI、人の判断が、それぞれ検証責任の一部を担います。実装者は指摘を受けたらコードに戻って確認し、妥当なものは修正し、採用しないものは理由を説明し、資金、権限、業務のセマンティクスに関わる判断は人に委ねます。

Grok Bot を導入した後も、人の手元にはある種の作業が残っていました。レビューを待ち、指摘を読み、修正し、CI を待ち、新たな問題がないかをまた確認する。ステップごとに人が戻ってきて「続けて」と言わなければならないなら、待ち時間とコンテキスト切り替えのコストは残ったままです。PR watch は継続的なフォローアップを担当し、Autopilot は現在のセッションの中で PR をマージ可能な状態まで進めます。各ラウンドで GitHub から最新の状態を読み取り、範囲内の競合、レビューコメント、CI の失敗に対処し、修正が終わったら再レビューに回します。PR がマージ可能な状態になったら、マージとリリースは人の承認に従います。

リリースは実行結果と突き合わせ、問題はエンジニアリング資産に戻す

Issue から本番に至るには、まずテスト環境で変更を検証し、そのうえで人がリリースを承認します。Grok Bot はタスクに応じてテスト環境での検証を行い、その結論は実際にデプロイされたバージョン、実際の実行結果と一致していなければなりません。リリース前後の実行時の証拠は、対応する Skill が照合します。実行環境やデータベースを読み取れない場合、結論は「証拠不足」であり、コードが一致しているからといってリリース可能と宣言することはできません。

「グリーン」が何を証明するのかも明確にしておく必要があります。CI が通ったことは、あらかじめ設定されたチェックが通ったことを示すだけで、外部チャネル、画面の操作、本番の経路に問題がないことまでは示せず、ましてや業務上の受け入れと同じではありません。アサーションの削除、条件の緩和、失敗のスキップによってテストをグリーンにすることは禁止しています。バグを修正するときは、まず旧実装では失敗するテストケースを書き、そのテストが本当に元の誤りを検出できることを証明します。

初期の頃は、障害が起きるたびにルールに一段落を書き足していました。ファイルはますます反省文のようになっていきましたが、同種の問題を食い止めることはほとんどありませんでした。今では問題が見つかったら、まずそれをどの形で残すべきかを判断します。安定して再現できるものは回帰テストとして残し、機械的に識別できるものはチェックにし、業務の背景がなければ説明できないものはコードコメントに書き、モジュールをまたぐ制約はトピック別の規約に入れ、繰り返し実行するフローは Skill にします。

開発時の検証には隔離された環境を使い、共有データベースや外部チャネルのサンドボックスへの依存関係に応じて並行タスクを割り振っています。

現時点での私たちの判断

エンジニアリング資産は移植可能でなければならず、同時に実行者の能力にも越えるべき水準があります。単一のルールソース、呼び出し可能な Skill、バージョンと突き合わせられる証拠があるからこそ、Claude Code と Codex は同じ PR 群で分担でき、今後は新しい実行者を加えることもできます。これらの資産が引き継ぎの出発点を決めますが、どこまで深くやれるかは実行者自身次第です。現在、私たちが主軸を Claude Code と Opus 5.5 に置いているのは、これまでの実際の使用に基づいています。

人の注意は三つのことに向けます。目標と受け入れ基準が正しいか、重要な業務上のトレードオフが正しいか、いつ変更を本番に入れてよいか。それ以外の部分は毎月変わり続けています。私たちはこれからも、人が伝え直したり、催促したり、繰り返し確認したりする必要のある工程を Agent に任せ、どこまで進めるかを見ていきます。それこそが、私がこの取り組みを面白いと感じるところでもあります。