大手コンサルティングファームの広告を見ていると、「AIに実務は代替できないからこそ、生身の人間の伴走が必要だ」という言説が目につきます。伴走が価値になる場面は、確かにあります。合意形成や経営判断、変革の推進は、人にしかできない仕事です。
しかし、現場でプロダクトを組んでいる立場から見ると、「AIにできないこと」を売り文句の中心に置く言説には、工数ビジネスを守るためのポジショントークの側面がある、と私は見ています。
現場で起きていること
いま最前線の開発現場で起きているのは、「ChatGPTにプロンプトを投げて、コピペする」という牧歌的な世界ではありません。Claude CodeやCursorのようなエージェントを、自律実行のパイプラインに組み込み、「夕方にIssue（課題）を投げれば、翌朝には、テストを通過したプルリクエストが、人間のレビュー待ちで並んでいる」という形に、開発の進め方を根本から作り直す動きです。
どちらのツールにも、そのための機能があります。Claude Codeは、対話なしの非対話モード（claude -p）で、スクリプトやCI/CDから呼び出せます。Cursorの「Cloud Agents」（バックグラウンドエージェント）は、専用の仮想マシン上で、非同期に作業し、完了すると、プルリクエストを自動で開きます。
仕組みは魔法ではなく、泥臭い設計である
この仕組みは、魔法ではありません。極めて泥臭いアーキテクチャ設計の積み重ねで成り立っています。私が重要だと考える点は、次の4つです。
- 言語とコンテキストの統一：画面（Next.js）から、バックエンド、インフラ定義（AWS CDK）までを、TypeScriptなどの単一言語でそろえます。AIが参照するコンテキストのノイズを、極小にするためです。型は、AIが自分の出力を検証するための足場にもなります。
- 時間のかかる処理の非同期化：推論や音声認識などは、画面側で待たせず、SQSなどのイベント駆動で、非同期に逃がします。
- 自己修復（Self-Healing）のループ：AIが、自らテストコマンドを実行し、エラーログを読み取り、コードを直します。ただし、再試行の回数と、費用の上限は、必ず設けます。Claude Codeの非対話実行にも、費用の上限を指定するオプションがあります。
- 品質ゲート：型チェックとセキュリティスキャンを通過したコードだけを、日本語の要約を付けて、シニアエンジニアの机に届けます。
人間の役割は、「書く」から「承認する」へ
人間が担うべきは、「コードを書く作業」ではなく、最後のアーキテクチャの妥当性を判断する、Human-in-the-loopの承認です。AIが下書きし、人が確定します。
私は、AIを「国語の電卓」、アルゴリズムやシステムを「算数の電卓」と呼び、それらをレビューし、最終承認する人間を、指揮者と呼んでいます。夜間のパイプラインは、その指揮者の机に、承認すべきものだけを届ける仕組みでもあります。
仕様は、動くコードから逆引きする
仕様書がきれいに整うのを待ってから、ウォーターフォールで進める進め方は、通用しにくくなってきました。仕様が不透明で、混沌とした現場ほど、AIを相棒にして、数時間で動くスパイクコード（試作）を立ち上げ、実際の挙動から仕様を逆引きして、ドキュメントを固めるやり方が、速く、手戻りも少ないと、私は考えています。
ただし、万能ではない
この進め方には、前提があります。
- テストの質が、品質の上限になる：「全テスト通過」は、テストが守っている範囲でしか、品質を保証しません。
- レビューが律速になる：翌朝に並ぶプルリクエストは、人が実際に判断できる量に収める必要があります。
- 無人の実行には、権限の設計が要る：許可する操作は、明示的に絞ります。具体的な設計は、次の技術補足で述べます。
- 規制や安全に関わる領域：仕様と承認の記録は、引き続き必要です。
技術補足：自動ガードレール（Guardrails & Lint）
夜間に人のいない状態でエージェントを走らせるには、「暴走しても、被害が限定される」設計が前提です。ガードレールは、プロンプトでのお願いではなく、AIの外側で強制する仕組みで作ります。最小限の構成は、次の4つです。
- 必須ゲート：セキュリティスキャナー（Snyk、Trivyなど）と、静的解析（ESLint、TypeScriptの型チェック）を、パイプラインの必須ゲートとして強制実行します。通らなかったコードは、人のレビューにも回しません。
- テストの改ざん防止：AIが「テストを通すために、テストコード側を都合よく書き換える」不正は、スキャナーや型チェックでは、検出しにくい問題です。テストとCI定義の変更は、CODEOWNERSで、人のレビューを必須にします。
- 権限と上限：実行環境は、使い捨ての隔離環境にし、本番の認証情報は置きません。mainへの直接のpushは禁止し、承認とマージは、人だけに許します（GitHubのブランチ保護）。費用と再試行の回数には、上限を設けます。
- 記録：実行ログと、拒否された操作の記録を、承認の前に確認します。
AIを「信頼する」のではなく、「間違えても被害が限定される」ように設計する。これが、夜間の自走を、実務に載せる条件です。
必要なのは「実務型アーキテクト」
きれいなパワポで、AI導入のグランドデザインを語るだけの評論家では、このパイプラインを、1本も通すことはできません。必要なのは、経営陣が求めるROIを理解した上で、最前線のアーキテクチャの配線まで、一人称で手を動かして組み上げられる「実務型アーキテクト」です。
AIを、社会のどこに配置するか。その配置を設計し、配線まで引く人が、いま求められています。
根拠・参照
- Claude Codeの非対話モード（
claude -p）、スクリプトとCI/CDでの利用、許可ツールの指定、費用上限：Claude Code ドキュメント（Run Claude Code programmatically） - Cursor Cloud Agents（バックグラウンドエージェント）：Cursor ヘルプ（Background agents）
- ブランチ保護（承認とマージを人に限る設定）：GitHub Docs（Managing a branch protection rule）