Claude Codeで開発作業が激変した理由。検証までAIが完結する新ワークフローとは

開発のボトルネックが「コード生成」から「検証」へ移った日

AIがコードを書く光景は日常になった。生成されたコードを動かし、バグやデザイン崩れを確認する作業は人間の仕事だった。

それが今、大きく変わっている。

AIエージェントが自ら計画を立て、実装し、ブラウザを操作してテストし、修正まで完結させる。

この「検証まで含めた自動サイクル」が、最新のAI開発環境の標準だ。

特にClaude Codeを筆頭とするツールは、単なる補完ツールではない。

開発フローを再定義する自動化エンジンだ。

$10億規模の投資。数千人の開発者による検証。

AI開発は「指示して待つ」から「自律的に動くエージェントを監督する」フェーズへ移行した。

この変化の核心を深掘りする。

計画と検証を統合する最新AIエージェントの全貌

海外のトップエンジニアはAIに「いきなり書かせない」アプローチをとる。

これまでのAIツールはプロンプトに対し即座にコードを書き換えていた。

大規模プロジェクトでは、これが意図しないデグレを招く原因となっていた。

最新のワークフローでは、まずAIに「計画（Plan）」を立てさせる。

実装前に、どのファイルをどう変更し、どんなテストを行うかをマークダウン形式で出力させる。

人間はその計画をレビューし、承認する。

この「Planモード」の導入により、AIによる的外れな変更は減少した。

AIの能力を拡張する「プラグイン」や「スキル」の概念も一般化している。

以下のような機能がAIエージェントに組み込まれている。

1. ブレインストーミング: 実装前に質問形式で要件を具体化する
2. TDD（テスト駆動開発）: テストコードを先に書き、パスするまで実装を繰り返す
3. コード・シンプリファイアー: 複雑になったコードを自動でリファクタリングする
4. 自動コードレビュー: AIが書いたコードを別のAIが客観的にレビューする

Git worktreeとの組み合わせも有効だ。

複数のブランチを異なるディレクトリで展開し、AIにタスクを並行実行させる。

人間が1つのバグを直す間に、AIが別の3つの機能を実装し、プルリクエストまで作成する。

そんな開発スタイルが2025年後半から2026年にかけての標準となっている。

しんたろー：
Claude Codeを使い始めてから、ターミナルはAIとの対話の場になった。
「コードを書いてもらう」感覚から、「開発チームのリーダーとしてAIに指示を出す」感覚へ変わった。
Planモードで「まず方針を言え」と強制できるのは、精神的な負荷が減る。

なぜ「見た目のテスト」までAIに任せられるようになったのか

コードのロジックは自動テストで守れる。

しかし、「ボタンの色が微妙にズレた」「スマホで見るとレイアウトが崩れている」といった視覚的な問題は、目視に頼るしかなかった。

これがレビューのボトルネックとなっていた。

この課題を解決するために、ビジュアルリグレッションテストをAIワークフローに組み込む動きが加速している。

例えば、Argos CIのようなツールをPlaywrightと組み合わせる手法だ。

AIがコードを変更した後、自動でブラウザを立ち上げてスクリーンショットを撮影する。

変更前の画像と1ピクセル単位で比較し、差分をレポートにまとめる。

開発者は、AIが作成したプルリクエストに添付された「比較画像」を見るだけでいい。

「デザイン変更は意図通りか？」をYES/NOで判断する。

この「AIによる実装 ＋ 自動撮影 ＋ 人間による最終承認（HITL）」の組み合わせが、品質保証ツールとして機能する。

さらに、この「検証」の概念は物理デバイスの制御にも広がっている。

ROS2（Robot Operating System 2）とAIを連携させ、自然言語でロボットを操作する試みも始まっている。

Function Callingという技術を使い、「1メートル前進して右に曲がれ」という指示を、ロボットが理解できる具体的な数値に変換する。

AIがソフトウェアの「外側」にある環境とやり取りするためのインターフェースが整いつつある。

しんたろー：
UIの崩れを確認する作業は時間を吸われる。
これを自動化できると、開発の心理的ハードルが下がる。
物理デバイスの制御もそうだが、AIが「現実世界」や「レンダリング結果」をフィードバックとして受け取れるようになったのは大きい。

僕らの開発にどう影響する？「AIエンジニアリング」への転換

この変化を受けて、開発者に求められるスキルも変わる。

単にコードが書けるだけでは不十分だ。

これからは、「AIエージェントが正しく動くための環境を設計する能力」、つまりAIエンジニアリングの重要性が増す。

具体的には、以下の3つのアクションが有効だ。

1. 検証スキルの定義: AIに「何をチェックさせるか」を定義する。

単に「テストを書いて」ではなく、PlaywrightやビジュアルテストツールをスキルとしてAIに与え、実行させる環境を整える。

1. ワークフローのゲートキーパー化:

AIが勝手にデプロイするのではなく、必ず「計画承認」と「検証結果の確認」というゲートを設ける設計にする。

Claude Codeのパーミッション設定を使い、重要な操作には必ず人間の介在を求める。

1. チーム内での「スキル」共有:

個人が作った便利なAIプラグインや自動化スクリプトを、チームの資産として共有する。

社内専用のマーケットプレイスを作り、「このコマンドを叩けば、AIがうちの会社の規約通りにPRを作ってくれる」という状態を作る。

AIはもはや、エディタの横にいるアシスタントではない。

開発プロセスという工場の、自動化ラインそのものだ。

僕らはそのラインを設計し、メンテナンスする技師となる。

しんたろー：
AIを使いこなせるかどうかは「どれだけ環境構築に投資したか」で決まる。
面倒な設定を一度済ませてしまえば、あとの開発はAIが勝手にやってくれる。
この「初期投資」を惜しむ人と、楽しんでやる人の差が、そのまま開発スピードの差になる。

AI活用に関するFAQ

Q1: AIにコードを書かせる際、意図しない変更を防ぐにはどうすればいい？

Planモードを徹底的に活用することだ。

実装を開始する前に、必ずマークダウン形式で変更計画を出力させ、人間が内容を精査するプロセスを挟む。

また、ビジュアルリグレッションテストをCIに組み込むことで、ロジックだけでなく見た目の変化も自動で検知できる。

「AIに丸投げ」ではなく、「計画を承認し、結果を検証する」というゲートを設けるのが鉄則だ。

Q2: AIエージェントにテストや検証を任せる際の注意点は？

AIには「実装のコード」ではなく「ユーザーから見た振る舞い」を基準にテストをさせるべきだ。

Playwrightなどのツールを使い、実際のブラウザ操作をシミュレーションするテストケースをAIに計画させるのが効果的だ。

特に物理デバイスや外部APIが絡む場合は、Function Callingのスキーマを厳密に定義し、AIが許容範囲外の命令を出さないように制約を設けることが、安全性の確保につながる。

Q3: チーム開発でAIツールを導入する際、どうやって足並みを揃えるべき？

個人のローカル環境に閉じた設定ではなく、プロジェクトごとに設定ファイルや共有プラグインを管理するのがベストだ。

例えば、コミットメッセージの生成ルールや、特定のライブラリを使ったリファクタリング手順などをカスタムスキルとして定義し、リポジトリに含めて共有する。

これにより、ジュニアエンジニアでもシニアエンジニアと同じ精度でAIエージェントを使いこなせるようになり、チーム全体の生産性が底上げされる。

AIと歩む、新しい開発のスタンダード

AIによる開発は、単なる「効率化」の段階を過ぎ、「構造の変化」へと進んだ。

計画、実装、検証。

このすべてをAIが担い、人間がその品質を保証する。

この新しいワークフローに慣れてしまうと、以前のやり方には戻れない。

僕も日々、Claude Codeを使って自分のサービスを育てている。

最初は設定に苦労したが、一度「自分専用の最強の部下」が出来上がると、開発のスピード感は別次元だ。

この波に乗るか、それとも外から眺めているだけか。

その選択が、数年後の立ち位置を決める。

👉 ThreadPostでSNS運用を自動化する