XcodeのAI操作でなぜテスト自動化は危険か。Claude Code開発者が語る評価の分離術

AppleがXcodeにMCP連携を導入した。

AIエージェントが直接シミュレータを起動し、テストを回す。

多くの開発者がこの機能を活用する。

しかし、AIにテストを全自動で書かせることには罠がある。

AIの確証バイアスによるバグの隠蔽だ。

解決策は「生成」と「評価」の分離、そしてツールに依存しない自律的ハーネスの構築にある。

ツールが進化するほどテストは危険になる

Xcodeの最新アップデートで、MCPブリッジ機能が実装された。

AIエージェントがIDEの内部操作に直接介入する仕組みだ。

これまでは人間が手動でシミュレータを立ち上げ、ビルドボタンを押していた。

これからはAIが自律的にテストコードを書き、その場で実行結果を確認する。

エラーが出れば、AIがログを読み、コードを修正して再実行する。

ローカル環境での自己修復ループが自動化される。

開発者のコンテキストスイッチは減少する。

しかし、別の開発現場からは報告が上がっている。

AIにテストの自動生成を任せると、同じ見落としを繰り返す。

AIは自分が書いたバグを「正解」だと思い込み、そのままテストを書く。

結果として、バグがあるのにテストはすべてグリーンになる。

何も気づかないまま、壊れたコードがデプロイされる。

実際にフロントエンドの統合テストをAIに任せた事例がある。

コンポーネントのカタログツールとテストライブラリを組み合わせた環境だ。

自然言語でブラウザを操作させるツールや、E2Eテストの自動生成も試された。

技術的には動いたが、最終的には不採用になった。

理由は、AI単体に「生成から確認、修正まで」を連続でやらせたからだ。

AI自身が埋め込んだバグを、AI自身が書いたテストで検証しても意味がない。

さらに、AIを操作するための基盤、いわゆる「ハーネス」の構造も変化している。

ベンダーが提供するインフラ機能が進化している。

これまで開発者が自前で組んでいたエージェントの記憶管理やツール連携が、公式機能に吸収されている。

便利になる一方で、特定のツールへの依存度が高まっている。

ツールが便利になるほど、僕らは「ツールに依存しない評価基準」を持つ必要がある。

生成と評価を分離し、ベンダーロックインを防ぐ設計思想が求められる。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

確証バイアスを破壊するサブエージェント設計

AIの確証バイアスは、人間の思い込みよりも厄介だ。

自分が生成したコードの文脈を引きずったままテストを書くと、見落としが発生する。

大規模言語モデルの仕組み上、直前の文脈に強く引っ張られる。

バグを生成したAIが、そのバグの挙動を仕様だと勘違いする。

そして、その間違った仕様を満たすテストコードを書き上げる。

これを防ぐには「生成するAI」と「評価するAI」を分離する。

責任を分割したマルチエージェントのワークフローだ。

生成担当のエージェントには、コンポーネントの分析とテストコードの作成だけをやらせる。

この段階では、品質の評価は行わない。

そして、評価担当のエージェントを新たに立ち上げる。

ここが核心だ。

評価用AIには、生成時のプロンプトや文脈を一切渡さない。

ファイルパスだけを渡し、独立した状態でコンポーネントの仕様を読み直させる。

生成AIが何を考えてコードを書いたのか、評価AIは知らない状態を作る。

この「文脈の遮断」によって、AIは客観的なレビューアになる。

生成AIが見落としたエッジケースや、間違った解釈を独立して発見する。

評価AIはコードの変更を行わず、評価レポートの出力のみに専念する。

既存のコードとテストの品質を、独自の照合表で診断する。

しんたろー：
Claude Codeでコードを書いていると、この確証バイアスは痛いほどわかる。
自分で書いたコードをAIに聞くと「完璧です！」と返ってくる。
だから最近は、別のチャットを立ち上げてゼロからレビューさせるようにしている。

XcodeのMCP連携は、強力なインフラだ。

AIがビルドを回し、テストを実行する手間をゼロにする。

しかし、それはあくまで「実行の自動化」に過ぎない。

その上で動かす「テストの妥当性を測るロジック」は、僕らが設計する。

インフラが強力になるほど、その上に乗る思想の重要性が増す。

高速にテストを回せても、評価基準が間違っていれば意味がない。

テストの目的は、コードが動くことを証明することではない。

仕様通りに動かない場合に、確実に失敗させることだ。

AIが書いたテストは、往々にして「実装された通りに動くこと」を検証する。

だからこそ、実装から切り離された独立した評価プロセスが必要だ。

融解するハーネスとベンダー非依存の戦い

AI開発におけるハーネスは、多層構造になっている。

最下層には、各社が提供する強力なインフラがある。

その上に、僕ら開発者が組む自動化のスクリプトやツール群のハーネスが乗る。

そして最上層に、プロダクト固有のドメイン知識や評価基準という「思想」が存在する。

海外のAI実践者たちの報告を見ると、この階層の境界が融解している。

昨日まで自分で作っていたハーネスが、今日にはベンダーの公式インフラに吸収される。

例えば、エージェントのセッション永続化や記憶の管理機能だ。

これらは以前まで、開発者がデータベースを組んで自作する必要があった。

今ではベンダー側がマネージドな機能として提供し始めている。

これは歓迎すべき進化だ。

下のレイヤーがインフラ化することで、僕らは上のレイヤーである「思想」に集中できる。

インフラのメンテナンスから解放され、ドメイン知識の構築に時間を割ける。

問題は、その思想をどうやって管理するかだ。

特定のツールの独自フォーマットで評価基準を書くと、ロックインされる。

だからこそ、ドメイン知識やテストの評価ルールは、移植可能な形式で持つ。

マークダウン形式の手順書や、汎用的なデータベースファイルとしてGitで管理する。

実際に、数万件のエージェントメモリと数百のスキルファイルを蓄積した実践者がいる。

彼らの実装の大部分は、シンプルなテキストファイルと汎用的なデータベースで構成されている。

しんたろー：
うちの構成だと、Claude Codeのプロンプトや設定ファイルは全部リポジトリに入れている。
APIの仕様が変わっても、他のLLMにそのまま食わせれば動く状態にしておくのが精神衛生上いい。
ツールは裏切るかもしれないが、自分のGit履歴は裏切らない。

ベンダーロックインが怖くなるのは、思想を奪われた時だ。

自分のデータとフローを握られた時だ。

特定のツールの隠蔽された内部機能に依存しすぎると、移行コストが跳ね上がる。

だから、インフラは借りても、データとフローは自分で所有する。

明日、新しいAIツールが登場しても構わない。

インフラが変わっても、蓄積した「評価の思想」はそのまま移植できる。

公式の便利なインフラは使い倒す。

しかし、コアとなるドメイン知識はベンダーに渡さない。

これが、これからのAI開発における防御策になる。

テスト自動化の罠を抜け出し、自律型ハーネスを手に入れる方法だ。

実務で自律的ハーネスをどう組むか

明日から開発現場でどう実装するか。

まず、AIエージェントを単なるコードジェネレータとして使うのをやめる。

ワークフローを意図的に多層化する。

テスト生成エージェントと、テスト評価エージェントの定義ファイルを分ける。

生成用プロンプトには、対象ファイルへの書き込み権限を与える。

必要なツールをすべて渡し、自由にコードを生成させる。

一方で、評価用プロンプトからは書き込み権限を剥奪する。

読み取り専用の権限だけを与え、コードの変更を物理的に不可能にする。

評価エージェントには、生成プロセスの履歴を見せない。

コンポーネントのソースコードと、テストファイルのパスだけを渡す。

そして、事前に用意した「評価チェックリスト」と照らし合わせるよう指示する。

このチェックリストこそが、プロダクトの「思想」だ。

ユーザー操作の手順が正しく網羅されているか。

エッジケースでのエラーハンドリングが適切にテストされているか。

これらを検証し、レポートとして出力させる。

もし評価エージェントが問題を指摘したら、そのレポートを修正用エージェントに渡す。

修正用エージェントは、レポートをもとにコードを直し、再び評価に回す。

この非同期のループを回すことで、確証バイアスを物理的に排除できる。

しんたろー：
AI同士でレビューさせる仕組み、最初は面倒だと思っていたが効果は大きい。
人間がレビューするより厳しいツッコミが入ることもある。
ただ、評価基準のマークダウンを書くのは人間の仕事だから、そこはサボれない。

これらのプロンプトやチェックリストは、すべて汎用的な形式で保存する。

特定のIDEのプラグイン設定ではなく、リポジトリ内の独立したディレクトリに置く。

プロジェクトのルートに専用のフォルダを作り、そこにマークダウンで書き溜める。

どのAIエージェントを起動しても、そのフォルダを読み込ませれば同じ動きをするように設計する。

これが、ベンダーに依存しない「自律的なハーネス」の正体だ。

ツールが進化して新しい機能が追加されても、蓄積したルールは色褪せない。

XcodeのMCP連携のような強力な機能が登場したら、実行部分だけをそちらに委譲する。

評価のロジックは自分の手元に残したまま、インフラの恩恵だけを享受する。

混乱の時期こそ、実装の自由度が最大になる。

業界の標準化を待つ必要はない。

痛みに駆動されて作ったスクリプトが、やがて強固なハーネスに育つ。

自分の実装物を信じ、積み上げることが正解だ。

よくある質問

Q1: AIにテストを書かせると同じバグを見逃すのですが、どうすればいいですか？

AIの確証バイアスが原因だ。生成担当と評価担当のエージェントを完全に分離する。

評価用エージェントには「生成時のプロンプトや文脈」を一切渡さない。

評価用エージェントには、コンポーネントの仕様書や定義ファイルのみを与える。

生成されたテストコードが仕様を満たしているかを、別の視点から独立して検証させる。

この文脈の遮断によって、見落としを減らすことができる。

Q2: ベンダーロックインを避けるために、ハーネスをどう設計すべきですか？

ツール固有の機能を使いつつも、中身は移植可能な形式で管理する。

特に「テストの評価基準」や「ドメイン知識」は、特定のAIモデルに依存しない形式にする。

マークダウンの手順書や、汎用的なスクリプトとしてGitリポジトリに蓄積する。

ベンダーのインフラが進化して機能が吸収された際、その上に乗る「君の思想」が残るように設計する。

データとフローさえ握っていれば、ロックインは防げる。

Q3: XcodeのMCPブリッジを使うメリットは具体的に何ですか？

これまで手動で行っていたシミュレータの操作を、AIエージェントが直接API経由で完結できる点だ。

ビルドやテスト実行をAIが自律的に行える。

AIがテストコードを生成した直後に、即座に実行結果を確認できる。

失敗した場合はログを読み、その場で修正を繰り返す「自己修復ループ」をローカル環境で構築可能だ。

開発者のコンテキストスイッチを減らし、テスト駆動開発のサイクルを高速化する。

まとめ

しんたろー：
AIにテスト書かせて「全部パスしました！」と言われて喜んでいた過去の自分を殴りたい。
評価を分離するのは、人間組織の監査と同じだ。AIにも第三者機関が必要な時代になった。

AIは単なるコード生成機から、自律的な評価基盤へと進化している。

ツールに依存せず、自分だけの評価基準を育てていく。

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