AIに任せすぎると詰む？自律化の正解を語る

登場人物

リナ社長 … 高校生なのに会社経営するやり手ギャル。テックにも強くてAI活用が得意。

タクヤ … 入社3年目の男性社員。真面目で少しだけコードが書ける。

リナ社長「ねえタクヤ、最近うちのチームってコードレビューとかデプロイとか、ぜんぶAIに投げてよくない？　マジで人間いらなくなるじゃん？」

タクヤ「あー、気持ちはわかります。でも「全部任せる」って、実は一番危ない発想なんですよね。去年うちの取引先が同じことやって盛大に詰んだんで……。」

リナ社長「えぐくない？　じゃあ正解ってどこにあるの？　ちょい待って、ちゃんと教えて。」

1. 「AIに全部やらせればよくない？」——2026年の現実

2026年現在、開発現場のAI活用は当たり前のフェーズに突入している。Claude Code はターミナルから直接コードを生成・修正し、GitHub Copilot はエディタ上でリアルタイムに補完する。Cursor のようなAIネイティブIDEも普及し、「AIなしで開発する」という選択肢は、もはや生産性の面で非現実的になりつつある。

こうした状況で自然に生まれる発想が「じゃあ全部AIに任せよう」だ。しかし、ツールが高性能になればなるほど、どこまで自律させるか という設計判断の重要性は増す。自律度を上げるだけでは足りない——止め方と介在タイミングの設計こそが、2026年の開発チームに求められるスキルになっている。

2. 実は「自律度」より「止め方」が難しい——Human-in-the-loopとは

タクヤ「Human-in-the-loopって言葉、聞いたことありますか？」

リナ社長「なんか機械学習のとこで出てきたやつじゃん。アノテーションとか？」

タクヤ「よく機械学習の文脈で語られますね。でも実はもともとは1940〜50年代の制御理論・サイバネティクスを起源とする概念で、コンピュータ制御システムに人間の判断を組み込む設計思想なんです。最近はAIエージェントの文脈で使われることが増えていて、「AIが処理を進めるフロー上の、どこかのタイミングで人間が判断を挟む」という意味で広く使われています。」

リナ社長「なるほど、AIが全自動で走るんじゃなくて、要所要所でチェックポイントを置くって感じ？」

タクヤ「まさに。それが抜けると、AIが「正しい方向に全力で突き進んだ結果」に誰も気づけないまま本番環境に届く、という悲劇が起きます。」

AIエージェントの自律化レベルは、Anthropicなどが提唱する考え方をベースに大まかに3段階に整理できる（これは本記事での整理であり、業界によって定義が異なる場合がある）。

提案型: AIが候補を出し、人間が選ぶ。毎アクションごとに人間が判断に関与する。
半自律型: AIが実行し、人間がチェックポイントで承認・差し戻しを行う。
全自律型: AIが判断から実行まで完結し、例外発生時のみ人間が介在する。

問題は、全自律型が便利に見えてリスクが集中しやすい という点だ。特にコードの生成・テスト・デプロイが一気通貫で動く構成では、AIが「文法的に正しいが意図と異なる実装」を静かに本番に送り込むことがある。

3. 失敗パターン3選：任せすぎた企業の末路

リナ社長「実際にどんな失敗が起きてるの？　えぐい話ちょうだい。」

タクヤ「笑えない話が3つあります……。」

パターン①：コードレビュー丸投げ

AI生成コードをそのままAIにレビューさせるループに陥ったケース。AIは「自分が書いたコードの欠点」を見落としやすく、同じ思想のバグをスルーしがちだ。実際に、認証ロジックの抜け穴がレビューをすり抜けて本番に入り込んだ事例が報告されている。生成と検証は別のモデル・別の視点 で行う設計が必要だ。

パターン②：テスト省略の自動化

「AIが書いたコードだからバグが少ない」という過信から、テスト工程をショートカットした企業がある。結果として、エッジケースのテストが一切なされないまま機能がリリースされ、特定条件でデータが消えるという障害が発生した。AIはテストを書くのも得意だが、何をテストすべきか の判断は人間が設計しなければならない。

パターン③：デプロイ自動化の暴走

CI/CDパイプラインにAIエージェントを組み込み、プルリクエストのマージからデプロイまでを全自動化したチームがある。ある日、自然言語での曖昧な指示をAIが「それっぽく解釈」し、ステージング環境をスキップして本番に直接デプロイした。デプロイゲートには必ず人間の明示的な承認 を残すことが鉄則だ。

4. じゃあ正解の設計ってどうするの？——実践チェックリスト

リナ社長「失敗例は分かった。じゃあ「正解の設計」ってどう作ればいいわけ？」

タクヤ「「AIに任せるフロー」と「人間が止まるポイント」を最初に地図で書くことですね。うちは最近このチェックリストを使い始めました。」

AIエージェント設計の実践チェックリスト

影響範囲の確認 — 本番データや外部サービスに触れる処理か？ Yes → 人間の承認ステップを必須にする
可逆性の確認 — AIの操作をロールバックできるか？ No → 実行前に必ず確認フローを挟む
曖昧さの排除 — AIへの指示に解釈の余地があるか？ Yes → 仕様を明文化してからプロンプトを渡す
ログの整備 — AIが何を判断して何を実行したかが追跡できるか？
エスカレーションルール — AIが「分からない」と判断したとき人間に渡す仕組みがあるか？

タクヤ「特に「可逆性」は盲点になりやすいです。テキスト生成なら失敗してもやり直せますが、DBの削除やAPI経由の課金処理は取り返しがつかない。」

リナ社長「あー、うちの画像分割ツールもユーザーの操作をAIに連携させようとしてたんだけど、まさにそこ詰めてなかったわ。ちゃんと設計し直す。」

Claude Codeを使って開発を進める場合も同様だ。Claude Codeは --dangerously-skip-permissions（現在は--permission-mode bypassPermissionsの別名として機能）のような権限スキップ系のフラグを使わない限り、ファイル操作や外部コマンドの実行前に確認を求める設計になっている。これはまさにHuman-in-the-loopの実装例と言える。AIツール側がそういう設計をしているのだから、使う側も同じ思想で自社のフローを組むべきだ。

5. まとめ：「使いこなす力」が2026年の差になる

リナ社長「結局、AIって頭良くなればなるほど「使う側のリテラシー」が問われるってこと？」

タクヤ「そうですね。道具が高性能になるほど、設計の責任は人間に移ってくる。AIは「速く走る車」みたいなもので、ブレーキの踏み方を知らない人が乗ったら危険というだけで、車自体が悪いわけじゃない。」

リナ社長「マジでそれ。「AIに任せた」は言い訳にならないってこと。設計したのは人間なんだから。」

2026年において、AIをまったく使わない開発チームと、AIを使いこなせるチームとでは、生産性に数倍の差が生まれている。しかし同時に、AIの自律化を無設計で進めたチームは、ある日突然「詰む」リスクを抱えている。

差がつくのは、AIを使う量ではなく、AIを止める場所を知っているかどうかだ。

Human-in-the-loopの設計は、AIへの不信感ではなく、AIへの理解から生まれる。どこが得意でどこが苦手かを把握し、人間とAIの役割を明確に分けること——それが自律化の「正解」に近い答えだ。

なお、数値の分析や反復処理のようにAIが本領を発揮しやすい領域では積極的に委ねていい。たとえば当社が提供するミニロト解析ツールのように、過去データのパターン分析を自動化する用途はAIと相性が良く、人間のチェックポイントも設計しやすい。

AIは道具だ。道具の使い方を設計するのは、いつだって人間である。

参考

Claude Codeを用いたエージェント的アプローチの考察 — AIエージェントの自律化とHuman-in-the-loopの設計についてエンジニア視点でまとめた記事