みなさん、こんにちは。
先日、当サイトで「失敗時のリスクに応じたAIへの権限委譲」と「Human in the Governance（ガバナンスの枠組み設計）」の大切さについてお話ししました。
今回はその続編として、AIコーディングの現場で今まさに起きている「車輪の再発明」という怪現象と、そこからAIのポテンシャルを最大限に引き出すための実践論「ハーネスエンジニアリング」について深掘りしていきたいと思います。
AIコーディングが「車輪の再発明」を始める理由
AI時代になって、非常に奇妙な現象が起きています。
多くの人がAIを使ってコードを書くことを実践し始めました。それ自体は素晴らしい変化なのですが、その結果、既存のライブラリや外部機能が使われなくなり、すべて自作の巨大なブラックボックスアプリが生み出されることが増えたように思います。しかも、どこかで見たようなアプリばかりです。
「なぜみんなAIで車輪の再発明を始めたのか？ 既存のライブラリをなぜ使わないのか？」
私自身、ことあるごとに疑問を感じていました。
同じようなアプリばかりなのは、機能模倣が「AIを使ったコーディングの学習」に丁度良いという側面があるのかもしれません。
しかし、既存のライブラリを使わない原因は「AIに制約を与えていないことによる探索の暴走」にあるのではないかと思っています。
AIは、明確な制約（枠組み）がなければ探索空間を無限に広げてしまう装置です。その結果、「使える部品を使わず、すべてを力技で自作する」という最悪の選択肢を選んでしまいます。
ガバナンスの罠 – AIへの「マイクロマネジメント」が能力を殺す
では、こうした車輪の再発明やAIの暴走を避けるために、開発者はどう対応しているでしょうか？
AIを制御しようとして、ついやってしまいがちなのが次のような指示です。
- 「この関数を使え」
- 「この手順で書け」
- 「10行以内で書け」
- 「この構造で書け」
…と、AIの挙動や実装方法を細かく細かく指定しようとします。
しかし、これは組織運営でいう最悪の「マイクロマネジメント」と全く同じ構造です。
開発者が自分の知っているルールや手順だけでAIをガチガチに縛り付ければ、AIが生み出す成果物はその開発者自身の能力の器を絶対に超えられなくなります。
ガバナンス（統制）を利かせようと「手取り足取りの指示」を頑張るほど、かえってAIのポテンシャルを殺してしまう。AI自身の優秀な能力が、人間の「細かすぎる指示」によって無力化されてしまうという皮肉な事態に陥るのです。
AIを使いこなす鍵は「設計力」ではなく「制約を与える力」
丸投げ（全探索）をすると車輪の再発明が起き、かといって細かく指示するとマイクロマネジメントになって能力を殺してしまう――。この問題のヒントになる投稿がありました。
先日、Rubyの生みの親であるまつもとゆきひろ（Matz）氏がX（旧Twitter）で次のようにポストされていました。
この投稿を読んで、私はハッとしました。
「AIは設計ができないから」とよく言われますが、実はAIも設計自体はできます。ただし、適切な枠組み＝「制約」がないと探索空間が爆発して破綻してしまう。だからこそ、AIに適切な制約を与えることができない人は、ソフトウェアを完成させることができないのです。
AIに曖昧に「作って」と頼めば全探索モードに入り、巨大なブラックボックスを吐き出します。しかし、以下のような条件をあらかじめ示しておくとどうでしょうか。
- 使うライブラリ
- 組み合わせ方・接続インターフェース
- 達成すべき目的と境界線
- 入出力の定義
- 運用条件
これらを「制約」として与えた瞬間、AIは迷走することなく、一発でほぼ完璧なコードを生成してみせます。
AIを使いこなせるかどうかを決めるのは、従来の「手取り足取りの設計力」ではなく、「外枠としての制約を与える力」なのです。
…ですが、ここでひとつの疑問が浮かびます。「 制約を与えること自体が、AIの能力を縛り付けるマイクロマネジメントにならないのだろうか？」と。
ハーネスエンジニアリング – AIの周囲に「環境」を設計する技術
結論から言えば、マイクロマネジメントと「適切な制約」は根本的に異なります。
マイクロマネジメントが「AIの手足の動き（手段・手順）を細かく縛る天井」だとすれば、私たちが与えるべき制約とは「AIがどれだけ暴れても大丈夫な安全ネット（外枠）」だからです。
この「安全ネットとしての環境」を構築するアプローチこそが、ハーネスエンジニアリング（Harness Engineering）です。
- AIがどれだけ暴走してもシステム全体が壊れない環境を作る
- AIが自由に試行錯誤できる隔離環境を提供する
- 人間の器を超える大胆なアプローチやコード生成を許容する
手取り足取りのプロンプトで指示を出すのではなく、AIが安心して自由に暴れられる「生態系（ハーネス）」をコードと仕組みで設計する。これこそが、マイクロマネジメントに陥らずにAIのポテンシャルを解放する鍵です。
ループエンジニアリング – AIの自律ループをどこで止めるか？
このハーネスエンジニアリングを推し進めると、「AI同士が相互に監視し合い、自律的に修正ループを回して開発を進める」というスタイルに行き着きます。
そのとき重要になるのが、「自律して回るAIのループを、仕組みとしてどこで止めるか？」という設計です。
ハーネスエンジニアリングの現場では、プロンプトによる指示ではなく、次の4つの「決定論的ブレーキ」をシステムに組み込みます。
- Finish Line（自動テスト通過で停止）人間が仕込んだ自動テストや静的解析に合格した瞬間、AIは自動停止する。
- Budget（APIコスト・周回数の上限）「5ドル使ったら停止」「10周回ったら停止」などの物理的・不可逆的なハード上限を設定する。
- Judge（別AIによる評価）コードを書く実行役とは別のAIエージェントが、冷徹に品質チェックと検品を行う。
- Escalation（人間への返還）AIが行き詰まったり境界条件を超えそうになったりしたら自動で一時停止し、人間にコントロールを返す。
これらはすべて、AIへの「言葉での指示」ではなく、システムやインフラとして組み込まれた制約設計（フェイルセーフ）です。
AI時代のガバナンスとは「インフラのプログラミング」
ガバナンスを「言葉の方針」や「手動での全件レビュー・細かなプロンプト指示」で語る時代は終わったのだと思います。
- AIに思考停止で丸投げする（全探索による失敗）
- AIをマイクロマネジメントで縛り上げる（人間の器を超えられない失敗）
この二択はどちらも破綻します。
これからのエンジニアに求められるのは、AIが安心して未知の能力を発揮できるような「生態系（ハーネス）」をコードとインフラで構築することです。
そして人間は、AIが生み出す「人間の器を超えた成果物」を正しく見極め、評価するセンスを磨いていくべきではないでしょうか。
みなさんは、AIへの「指示」と「環境（制約）」のバランスをどのように設計していますか？よかったらコメントで教えてください。
本日も最後までお読みいただきありがとうございました。
それでは、よいエンジニアリングライフを！
「うちの現場でもこういうAIを使った仕組みが欲しい。でも既存の機器には手を入れられない」——そんなお悩みはありませんか。
ビューローみかみでは、構想段階の壁打ちからPoC・実装・現場導入まで、医療・介護の現場で「使い続けられる」ものづくりを支援しています。
医療機器の後付けIoT化から閉域網の構築まで、現場の制約を前提に「今の体制・予算で成立する構成」を一緒に考えます。
▶ 医療・介護IoT開発サービスの詳細はこちら
気になることがあればお気軽にご相談ください。
