こんにちは、大平です。
「AI にどこまで任せていいのか判断がつかない」「試験導入したが、怖くて結局すべて人間がレビューしている」。経営層・開発責任者の方から、こうした相談を受けることが増えました。結論を先に書きます。AI 駆動開発の安全性と生産性は、モデルの賢さではなく、環境整備の段階で決まります。この記事では、その環境整備（ハーネスエンジニアリング）を 8 段階のロードマップとして示し、どの順番で投資すべきかを整理します。
AI 導入の事故は「モデルの賢さ」の問題ではない
AI 導入でつまずいた組織の話を聞くと、原因はほぼ共通しています。ツールの選定ミスでも、エンジニアのスキル不足でもありません。AI が全力で動いても事故にならない環境を用意しないまま、AI に作業を渡していることです。
人間の新人を受け入れるとき、信用できるようになるまで作業を渡さない組織はありません。権限を絞り、レビューを挟み、壊せない環境を先に用意して、初日から手を動かしてもらうはずです。AI も同じです。「信用できるか」を議論するのではなく、事故が構造的に起きない環境を先に作る。この環境整備の領域を、僕はハーネスエンジニアリングと呼んでいます。ハーネスは馬具や安全帯の意味で、走る力を殺さずに事故だけを防ぐ装備のことです。
僕自身、現場で Claude Code を月額上限近くまで（API 換算で月 1,400〜1,600 ドル相当）回していますが、この物量を人間の目視だけで検品するのは不可能です。それでも事故なく回っているのは、以下の 8 段階を積み上げてきたからです。
8段階ロードマップの全体像
| Lv | 整備するもの | 経営的な意味 |
|---|---|---|
| 1 | シークレット分離と漏洩検知（gitleaks） | 不可逆な事故（情報漏洩）の防止 |
| 2 | 破壊的コマンドの制御（削除系の権限設定） | 復旧不能な損壊の防止 |
| 3 | ブラウザ操作環境（Playwright MCP） | AI が自分で動作確認できる状態 |
| 4 | 各レイヤーの単体テストと CI | 検証ループの自動化 |
| 5 | linter によるスタイル統一 | 人間のレビューを設計判断に集中 |
| 6 | AI コードレビュー（複数モデルの合議制） | チェックの多重化 |
| 7 | 権限の濃淡設計（クリティカル操作の承認制） | 統制と速度の両立 |
| 8 | ゴール単位の依頼（自律走行） | タスク指示から目標経営への移行 |
順番に意味があります。前半は「守り」、中盤は「検証の自動化」、後半は「統制の設計」です。以下、経営判断に関わるポイントに絞って解説します。
Lv1〜2：不可逆な事故を先に潰す
最初に手を付けるべきは、取り返しのつかない事故の防止です。API キーや秘密鍵をコードから分離し、gitleaks のような検知ツールで誤コミットを機械的に止める（Lv1）。ファイル削除などの破壊的コマンドは、設定で禁止または承認制にする（Lv2）。
ここを最初に置く理由は明確で、消えたコードは書き直せますが、漏れた秘密鍵は取り返せないからです。AI は人間よりはるかに多くのファイルを読み、多くのコミットを作ります。事故の試行回数が増える以上、防御を担当者の注意力に頼る運用は成立しません。
もう一つ、見落とされがちな要点があります。これらの設定をリポジトリに含めて、チーム全員に同じ安全装置が効く状態にすることです。一部のエンジニアだけが安全な設定を持っている状態は、組織としては未整備と同じです。
Lv3〜5：検証ループを AI に渡す
中盤の 3 段階は、生産性の分岐点です。AI が自分でブラウザを開いて動作確認できる環境（Lv3）、各レイヤーの単体テストと CI（Lv4）、linter によるスタイル統一（Lv5）。共通するのは、「書いたものが正しいか」の検証を、人間の手から AI 自身の手に移すことです。
自動テストが整備されていない組織では、AI の出力の検証をすべて人間が担うことになり、AI がどれだけ速くコードを書いても、人間の確認速度で頭打ちになります。逆に検証ループが閉じていれば、AI は自分で間違いに気づいて自分で直します。テスト基盤が AI 駆動開発の生命線である理由は、別の記事で詳しく書いたとおりです。
投資判断の観点で補足すると、テストコード自体は AI に書かせられます。人間が整備すべきはテスティングライブラリと CI の足回りまでで、ここは 1〜2 か月の集中投資で立ち上がる規模です。
Lv6〜7：チェックの多重化と、権限の濃淡
終盤は統制の設計です。AI によるコードレビューを導入し、可能なら複数の AI モデルによる合議制にする（Lv6）。僕の現場でも複数モデルの合議レビューを運用していますが、モデルごとに指摘の傾向が異なるため、単一モデルのセルフチェックでは通ってしまう問題を別のモデルが拾うことが実際に起きています。
そして Lv7 が、経営層の判断が最も問われる段階です。人間の承認を必須にするクリティカルな操作と、AI に広く任せてよい操作を、業務上の重要度で仕分けする。ここでやりがちな失敗が「全部を承認制にする」ことです。承認が多すぎると、人間は確認せずに承認ボタンを押すようになり、統制は形骸化します。守るべき少数を固く、それ以外を緩くという濃淡の設計が、結果として最も安全で、最も速い。これは権限一覧の話ではなく、業務の重要度評価そのものなので、現場任せにせず経営側が関与すべき論点です。
Lv8：タスクではなくゴールを渡せる組織
Lv7 までが整うと、AI への依頼の単位が変わります。「この画面を修正して」というタスク単位ではなく、「この機能を完成させて」という目標単位で渡し、ハーネスの中で自律的に走らせる。ここまで来ると、開発組織の生産性は従来の延長線では測れなくなります。
逆に言えば、Lv1〜7 を飛ばして Lv8 だけを試すのが、「AI はまだ実務に使えなかった」という結論に至る典型パターンです。失敗の原因は AI の能力ではなく整備の欠落なので、この結論のまま様子見に入ると、整備を進めた競合との差が開き続けることになります。AI 駆動開発そのものの概要はこちらの記事にまとめています。
まとめ
- 安全は信用ではなく構造で作る：AI を信用できるかの議論より、事故が起きない環境の整備が先
- 投資の順番は「不可逆な事故の防止」から：シークレット管理と破壊的操作の制御が最初の一手
- 生産性の分岐点は検証ループの自動化：テスト基盤と CI が、AI の速度を組織の速度に変える
- 権限は濃淡で設計する：全承認制は形骸化する。重要度の仕分けは経営の仕事
- 自律走行は最後：Lv1〜7 の積み上げの上でだけ、ゴール単位の依頼は成立する
自社が今どのレベルにいるかを確認するところから始めてください。多くの組織は、Lv1〜2 の時点で整備の余地が見つかるはずです。
関連して読める記事
ロードマップの各段階の背景は、次の記事で深掘りしています。
AIを入れても開発が速くならない現場、3つの共通点
Stripeが5,000万行の移行を1日で終える一方、「AIを入れたのに開発が速くならない」という相談は増え続けています。DORA 2025レポートの「AIは増幅器」という結論を踏まえ、AIがワークしない現場に共通する3つの欠落——食わせる情報がない・動ける足場がない・出力を検証する仕組みがない——と、見落とされがちな「モデル調達（稟議）」の構造問題、そして何から着手すべきかの順序を、現場でAI駆動開発を回している立場から整理します。
2026年7月16日
「動けばいい」運用は、AI 駆動開発で半年もたない
AI 駆動開発で生産性が出るかどうかは、ツールでもエンジニアのスキルでもなく、自動テストが回せているかで決まります。「動けばいい」運用が AI 時代に半年でボトルネック化する構造と、CXO・VPoE が今打つべき手を整理します。
2026年6月7日
「AI生成コードの45%に脆弱性」は何を意味するのか？ 調査条件と実務で必要な安全策
「AIが生成したコードの45%に脆弱性がある」というVeracodeの調査結果は、4種類のCWEを対象に設計された80件の関数補完課題に対する、100を超えるモデルの平均失敗率です。実務システムの欠陥率ではありませんが、セキュリティ固有の指示がない条件でLLMが安全な実装を安定して選べないことは示しています。この数字の測定条件と限界を原典で確認したうえで、フレームワークが守れる範囲、正常系テストでは検出できない認可の不備、そしてAI生成コードを本番へ出す前に組み合わせるべき8つの安全策を整理します。
2026年7月28日
AI駆動開発（AIDD）とは？従来の開発との違いと導入の考え方
AI駆動開発（AIDD）とは、生成AIを開発工程の主役に置き、人間が方針決定と検証を担う開発スタイルです。コード補完との違い、開発工程がどう変わるか、導入の順序と注意点を解説します。
2026年7月25日