こんにちは、ショウです！
「AIを使って開発を爆速にするつもりが、結局AIの出したバグの修正や、見当違いな回答の修正に時間を取られている…」
そんな悩みを感じたことはありませんか？実は、OpenAIやStripeといった最先端のテック企業では、今やコードの90%をAIが書いていると言われています。しかし、彼らは単にAIを使っているのではなく、AIを使いこなすための独自の「仕組み」を構築しています。
個人の書くスピードは上がったけれど、レビュー待ちが増えたり、組織全体のスピードが落ちる**「AI生産性パラドックス」。これを打破し、AIを真の武器にするための新概念が「ハーネスエンジニアリング（Harness Engineering）」**です。
今回は、これからのエンジニアの生存戦略とも言えるこの考え方について解説します。
1. ハーネスエンジニアリングの正体
「ハーネス（Harness）」とは、馬具や安全帯、あるいは電線の束をまとめる部品を指す言葉です。
ハーネスエンジニアリングを一言で定義するなら、**「AIという強力なエネルギーを、正しい方向に導き、安全に機能させるための『仕組み』を設計すること」**です。
- 従来の開発： 人間が直接コードを書く。
- これからの開発： 人間は**「AIが失敗しないためのフィードバックループ」**を設計する。
AIに「もっと速く書け」と命じるのではなく、AIが迷わず、かつ正しく動けるための「環境」を整えるのが仕事になります。
2. 具体的に何を「設計」するのか？
ハーネスエンジニアリングの具体的な実践例をいくつか紹介します。
① AI用の説明書（CLAUDE.md / AGENTS.md）
AIには「空気を読む」という能力がありません。プロジェクト独自の設計思想や、DI（依存性の注入）のルール、命名規則などをリポジトリ内に明文化しておく必要があります。
例えば、僕がAndroidアプリ（Kotlin）を開発している際、AIがContextの扱いでよくミスをすることがありました。そこで CLAUDE.md に独自のルールを追記したところ、次から完璧なコードが提案されるようになりました。これが「ハーネスを整備する」ということです。
② 強制力のあるゲート（リンターとCI/CD）
「〜という風に書いてね」とお願いするのではなく、仕組みでブロックするのがハーネスエンジニアリングの本質です。 リンターのエラーメッセージに「直し方」まで記載しておき、AIがルールを無視できないようにCI/CDで物理的にマージを阻止する設計を行います。
③ 「生成」と「評価」の分離
自分で書いたものを自分でチェックさせると、AIは自分の間違いを見逃しがちです。 実装を担当するAIアシスタントとは別に、レビュー専用のアシスタントを配置し、相互にフィードバックをかけさせるパイプラインを設計します。
3. エンジニアとしてのマインドシフト
これからの時代、KotlinやGoの細かい文法を暗記していることの価値は相対的に下がっていくでしょう。それらはAIに任せればいいからです。
大切なのは、**「Why（なぜ作るか）」と「What（何を作るか）」**の定義に集中すること。
もしAIがバグを出したなら、手で直して終わりにするのは「二流」です。 **「なぜAIは間違えたのか？」**を分析し、二度と間違えないようにプロンプトやドキュメント、あるいはテストコード（ハーネス）を修正するのが、これからのエンジニアの「本質的な仕事」になります。
まとめ：AIは「増幅装置」である
良い設計（ハーネス）があれば、AIは生産性を10倍、100倍に高めてくれる最強の増幅装置になります。しかし、ひどい設計のままAIを導入すれば、ゴミが高速で量産されるだけです。
「コードを書かないエンジニア」こそが、最強のコードを生み出す。
そんなパラドックスが現実のものになろうとしています。皆さんも、自分のプロジェクトに「AIのためのハーネス」を張ってみませんか？
それでは、また！