非エンジニアのAI駆動開発で陥りやすい失敗パターン｜ハーネスを飛ばすとどうなるか

非エンジニアの担当者が、自分の手でAI駆動開発を進める——この一年でそうした会社が増えるにつれて、同じようなところでつまずく失敗パターンも、はっきりと見えてきました。技術力の不足が原因ではなく、ほとんどの場合、ハーネス（コンテキスト・ガードレール・検証・ツール連携）のどこかを飛ばしてしまったことが原因です。この記事では、よくある4つの失敗パターンと、気づいたときの立て直し方を整理します。

よくある4つの失敗パターン

パターン1：最初から大きな業務を選んでしまう

「せっかくやるなら」と、最初から複数の部署にまたがる業務や、影響範囲の広い基幹業務を対象に選んでしまうケースです。業務が複雑になるほど、コンテキスト（何を伝えるか）もガードレール（どこで止めるか）も考えることが一気に増え、最初の設計だけで疲れてしまいます。結果として、途中で頓挫するか、設計が雑なまま見切り発車し、後から事故につながります。

避け方：最初の対象は、影響範囲が一つの部署、できれば一人の担当者の作業の中に収まる業務に絞ります。「小さすぎて物足りない」と感じるくらいがちょうどいい規模です。

パターン2：ガードレールを後回しにしてしまう

「まずは動くものを作ってから、安全対策は後で考えよう」という順番で進めてしまうケースです。動くものができると、それだけで達成感があり、「どこで止めるか」を決める地味な作業は後回しにされがちです。しかし、ガードレールがないまま本番の業務データに触れさせてしまうと、取り返しのつかない操作（誤送信・誤登録）が、設計の不備ではなく「運用のうっかり」として発生します。

避け方：動くものができた段階ではなく、AIに実際の業務データを触らせる前の段階で、必ずガードレールを先に決めます。「見せる」と「触らせる」の間には、必ずこの工程を挟むという順番を徹底します。

パターン3：検証をAI任せにしてしまう

AI自身に「ちゃんと動いていますか」と聞き、AIが「はい、正しく動いています」と答えたことをもって、確認が済んだと判断してしまうケースです。AIは自分が設定した条件の範囲では一貫した答えを返しますが、業務として本当に正しいかどうかまでは判断できません。見た目の自己申告だけで安心してしまうと、特定の条件でだけ発生する不具合に、運用が始まってから気づくことになります。

避け方：「この条件なら、この結果になるはずだ」という期待値を、担当者自身が先に書き出し、それとAIの出力を突き合わせる工程を必ず挟みます。AIに聞くのは、矛盾がないかを確認する補助的な手段に留めます。

パターン4：社内に知見が一人にしか残らない

最初に取り組んだ担当者だけがハーネスの中身を理解しており、他の誰も「何を・どこまで任せているか」を把握していない状態です。この状態で担当者が異動・退職すると、誰も中身を直せないまま、ハーネスだけが動き続けることになります。これは、エンジニアに外注した場合の「ブラックボックス化」と、構造としては同じ問題です。

避け方：指示書の内容や、どこで承認が必須になっているかという設定を、担当者一人の頭の中ではなく、誰でも読める文書として残しておきます。難しい形式である必要はなく、簡単な一覧表で十分です。

4つの失敗パターンと、避けるための対応

自社の場合に当てはめて整理したい方は、システム開発について相談する →

失敗に気づいたら、どう立て直すか

これらのパターンに当てはまってしまった場合でも、やり直しがきかないわけではありません。対象業務の範囲が大きすぎると気づいたら、一部の機能だけを切り出して範囲を絞り直します。ガードレールが抜けていたと分かったら、まずは影響の大きい操作だけを一時的に手動確認に戻し、落ち着いてから条件を設計し直します。検証が不十分だったと分かったら、実際に起きた不具合をそのままテストケースとして書き出すところから始めれば十分です。知見が一人に偏っていると感じたら、今動いている設定内容を書き出す作業から着手します。いずれも、最初からやり直す必要はなく、気づいた部分だけを順番に補強していく進め方で立て直せます。

ハーネスの3要素そのものについてはAIエージェントの「ハーネス」とは何かを、どこまでを自分で担当し、どこを外部に依頼すべきかはハーネス設計は誰が作るべきかを、検証の具体的な進め方はAIエージェントの「検証・修正の仕組み」とは何かを参考にしてください。

発信：株式会社オルアナ（新規事業開発・システム開発・AIエージェント開発・バックオフィス業務支援）