AIコーディングで暴走を防ぐ「ハーネス設計」の全貌 - 安全で効率的な開発環境の作り方

AIによるコード生成ツールが急速に普及する中、多くの開発者が同じ壁にぶつかっています。最初は驚くほど正確なコードを書いてくれるのに、気づけば要件と異なる実装を進めていたり、本番環境で危険なコマンドを実行しようとしたり。こうした「AIの暴走」は、実はAI自体の問題ではなく、**AIを取り巻く制御環境（ハーネス）の設計不足**が原因です。

開発者のyutakeさんが提唱する「最強のハーネス」設計は、この課題に対する体系的なアプローチとして注目に値します。本記事では、このコンセプトを深掘りし、実務で使える具体的な設計手法を解説します。

**ハーネス（Harness）**とは、本来「馬具」を意味する言葉ですが、AIコーディングの文脈では「AIの行動を適切に制御・誘導するための環境や仕組み全体」を指します。具体的には以下の要素が含まれます：

yutakeさんの提案では、Claude OpusやOpenAI Codexを「計画」フェーズに、Cursorを「実装」フェーズに配置する**役割分担型のスタック**が前提となっています。この分業こそが、ハーネス設計の第一歩です。

AIコーディングツールは、個別のタスクでは驚異的な性能を発揮します。しかし、長時間のセッションや複雑なプロジェクトでは以下の問題が顕在化します：

1. **コンテキストの希釈**：会話が長引くと、当初の要件や制約を「忘れる」

2. **過剰な創造性**：頼んでいない機能を「良かれと思って」追加する

3. **安全性の盲点**：rm -rfやdrop tableなど、破壊的なコマンドを躊躇なく提案する

これらは、AIが「今この瞬間の最適解」を求めるように設計されているために起こります。プロジェクト全体の一貫性や安全性を担保するには、**人間側が明示的な「レール」を敷く**必要があるのです。

GitHub CopilotやCursorとの違い - 「ツール」ではなく「システム」として設計する

現在主流のAIコーディングツールは、どれも「エディタ内での補完」に特化しています。GitHub Copilotは行単位・関数単位での提案が得意ですし、CursorはChatGPT連携による対話的な開発を実現しています。

しかし、yutakeさんが提唱するハーネスの概念は、**単一ツールの機能拡張ではなく、複数のAIと制約機構を組み合わせた「システムアーキテクチャ」**です。この違いは決定的です。

従来のアプローチでは、AIの出力をそのまま信頼するか、人間がすべてをレビューするかの二択でした。ハーネス設計では、**AIの行動範囲を事前に制限し、危険な操作は物理的に不可能にする**という発想に転換します。これは、コンテナ技術やサンドボックス環境の思想と共通しています。

メリット：再現性とスケーラビリティの向上

ハーネスを適切に設計すると、以下のメリットが得られます：

特に注目すべきは、**「AIの失敗を前提とした設計」**という姿勢です。AIは必ず間違えるという現実を受け入れ、その影響範囲を制限する。これは、エンジニアリングにおける「フェイルセーフ」の思想そのものです。

注意点：設計コストと柔軟性のトレードオフ

一方で、ハーネス設計には以下の課題があります：

このトレードオフを最適化するには、**「段階的な制約緩和」**の戦略が有効です。プロジェクト初期は厳しい制約から始め、AIの振る舞いが安定してきたら徐々に自由度を上げる。これにより、安全性と効率性のバランスが取れます。

適用範囲：どんなプロジェクトに向いているか

ハーネス設計が特に効果を発揮するのは、以下のような場面です：

逆に、**スピード重視のプロトタイピング**や**個人の実験的なプロジェクト**では、ハーネスの設計コストが見合わない可能性があります。AIに自由に書かせて、人間が最終チェックするスタイルの方が効率的でしょう。

1. 「許可リスト方式」で危険なコマンドをブロックする

まずは最も簡単な対策から始めましょう。AIが実行できるコマンドを「ホワイトリスト」で管理します。

# .ai-allowed-commands に許可するコマンドを列挙
ls
cat
grep
git status
git diff
npm test

CursorやShell統合を使う場合、プロンプトに以下を追加します：

あなたは .ai-allowed-commands に記載されたコマンドのみを使用できます。
それ以外のコマンドが必要な場合は、実行せずに人間に確認を求めてください。

これだけで、`rm -rf`や`DROP TABLE`のような破壊的操作を物理的に防げます。

2. セッション開始時に「制約プロンプト」を必ず挿入する

AIとの会話が長引くと、最初の指示を忘れがちです。毎回のセッション開始時に、以下のような「制約プロンプト」をテンプレート化して読み込ませましょう：

## あなたの役割と制約
- このプロジェクトはReact + TypeScriptで構築されています
- テストはJestを使用し、カバレッジ80%以上を維持してください
- APIコールは必ず src/api/ 配下の関数を経由してください
- 新しい依存関係を追加する前に、必ず人間に確認してください
- コードの変更理由を、各コミットメッセージに明記してください

Cursorの場合、`.cursorrules` ファイルにこれを記述すれば自動適用されます。

3. 「計画」と「実装」を明確に分離する

yutakeさんの提案の核心は、**AIの役割を段階的に分ける**ことです。実際のワークフローは以下のようになります：

**ステップ1（計画）：Claude Opusに問う**

ユーザー認証機能を追加したい。以下の条件で、アーキテクチャと実装手順を提案してください：
- JWT認証を使用
- パスワードはbcryptでハッシュ化
- セッション管理はRedisで行う

**ステップ2（レビュー）：人間が計画を検証**

Claudeの提案を確認し、プロジェクトの制約と矛盾がないかチェックします。

**ステップ3（実装）：Cursorに実装させる**

Claudeの計画をCursorに渡し、具体的なコードを生成させます。この段階では、「計画からの逸脱は許可しない」という制約を明示します。

この3ステップにより、AIが「勝手に設計を変える」リスクを大幅に減らせます。

AIコーディングツールは、適切な制約がなければ、期待を裏切る結果を生み出します。しかし、それはAIの欠陥ではなく、**私たち人間側の設計責任**です。

ハーネスという概念は、AIを「万能の協働者」として扱うのではなく、**明確な役割と制約を持つ「高性能な道具」**として位置づけ直すパラダイムです。道具は、正しく使えば驚異的な生産性をもたらしますが、扱い方を誤れば事故につながります。

yutakeさんの「ぼくがかんがえたさいきょうのはーねす」は、まさにこの「正しい扱い方」を体系化しようとする試みです。あなたのプロジェクトにも、今日からハーネス設計を導入してみてください。最初は小さな制約から始めて、徐々に洗練させていく――そのプロセス自体が、AIとの協働スキルを磨く最良のトレーニングになるはずです。

この情報は @yutake さんの投稿を参考にしています。