AIに作らせた社内ツールが途中で止まるとは、動くところまでは到達したのに、業務に乗らないまま使われなくなる状態のことです。原因は作る速さではありません。何を作るかを文字で固定していないため、判断が必要になるたびに手が止まることにあります。当社は外注もエンジニア採用もせずに社内向けの運用ツールを内製してきましたが、手元に残ったものを数えると、プログラム本体より仕様や運用の文書のほうが多くなっていました。この記事では、その実測と、止まる分かれ目を共有します。
生成AIを使うと、社内の小さなツールは以前より短い時間で形になります。当社で扱った範囲では、試作までの速さが障害になる場面は減りました（権限の設定や外部サービスとの連携、その後の保守は別に確認が要ります）。それでも途中で止まるとしたら、止まっている場所は作る工程ではなく、その手前です。
自社を数えたら、コードより仕様書が多かった
時間が積み上がったのは「決めて文字にする側」でした。当社のパソコンにある開発フォルダを数えたところ、次のようになりました。
実測した値（2026年8月4日時点）
仕様・運用の文書が615本・約21万2千行、プログラム本体（GAS と Node）が166本・約11万9千行。文書のほうが約1.8倍多いという結果です。数え方は、自動的に取り込まれる外部ライブラリ・バックアップ・過去分の保管フォルダを除いた実スキャンで、HTML はブログ記事や公開ページが大半を占めるため、プログラム本体には含めていません。数え方を先に決めてから測らないと、この種の数字は簡単に大きく見えてしまいます。
ここで言いたいのは「文書を書けば成功する」ということではありません。AIに書かせる作業が速くなった結果、残りの時間が全部「何を作るかを決める側」に移ったという順序の話です。作る速さが上がっても、決める速さは上がりません。
止まるのは3つの分かれ目
止まった場面を振り返ると、詰まる場所はほぼ3つに絞られます。
①「やらないこと」を決めていない
要望は作りながら増えます。増えること自体は問題ではなく、どこまでを今回の範囲にしないかを決めていないことが問題です。範囲が決まっていないと、追加のたびに全体を作り直すことになり、いつまでも完成しません。最初に書くべきは機能の一覧ではなく、今回はやらないことの一覧です。
②「誰が使うか」が曖昧なまま作っている
同じ集計でも、経営者が月に一度見るのか、現場の担当者が毎日入力するのかで、作るものはまったく別になります。使う人が決まっていない機能は、必ず後で作り直しになります。当社では、使う人の名前が挙がらない機能は着手しないようにしています。
③ 前提が古いまま進んでいる
制度の条件や運用ルールが変わっているのに、最初に渡した前提のまま作り続けてしまう場合です。AIは渡された前提を疑いません。おかしいと感じたときは、出てきたものを直す前に、渡している前提が最新かを確かめるほうが早く解決します。
この3つは、AI導入でよくある失敗や社内で生成AIが定着しない場合とも重なります。共通しているのは、原因が技術ではなく決めごとの側にあることです。
「動いた」を完了と呼ばない
完了の条件を先に決めておかないと、完了したかどうかを誰も判定できません。当社では「動いた」ではなく「決めた検査に通った」を完了としています。
検査そのものが壊れることがある
ここで一度、失敗しています。品質を確認するはずの検査が起動した直後に落ちており、検査が1件も実行されていない状態が続いていたのです。記録の上では「合格」と残っていました。別の日には、検査の対象が0件なのに「問題なし」と表示される状態も起きました。合格の数だけを見ていると、どちらも気づけません。
対策として、わざと壊したものを検査に通し、ちゃんと不合格が出るかを毎回確かめる工程を足しました。検査を足したら、その検査が発火することも確かめる。手間は増えますが、「見ていないのに合格に見える」状態が一番損害が大きいというのがこのときの結論です。
関連して、AIに要件定義をさせるときの進め方と現場に出す前の検証もあわせてご覧ください。
最初の1つに選ぶべき業務
結論は「毎日ある・手順が決まっている・間違えても取り返せる」の3条件がそろう業務です。月に一度の重い業務から始めると、直す機会が月に一度しか来ないため、改善が進みません。毎日発生する業務なら、翌日には直せます。
順番としては①やらないことを決める ②使う人の名前を決める ③完了の条件を決める ④作る。④が最後に来るのは、そこが一番速いからです。AIエージェントとはで全体像を、コードを書かずに自動化する方法で具体的な進め方を補足しています。
なお本記事の数値は、販売中または検証中の企画を含む自社の記録であり、導入効果の保証ではなく、開発と検証の過程の共有としてご覧ください。
よくある質問
仕様書はどこまで細かく書くべきですか？
画面の細部まで書く必要はありません。決めるべきは、誰が使うのか、何が起きたら完了なのか、やらないことは何か、の3点です。この3つが空欄のまま作り始めると、途中で判断が止まります。
AIが速く作れるなら、仕様書は要らないのでは？
作る速さは上がりますが、作り直しの回数は減りません。何を作るかが決まっていないと、速く作って速く捨てることになります。実際に時間が積み上がるのは、決める側の作業です。
動いているのに使われないのはなぜですか？
多くの場合、想定していた業務の流れと違うためです。動くかどうかと、業務に乗るかどうかは別の基準です。完了の条件を「動いた」ではなく「担当者が翌週も使っていた」に置くと、この差が早く見つかります。
エンジニアがいない会社でも続けられますか？
続けられますが、条件があります。作る人と使う人が同じ場所にいて、決めたことを文字で残すことです。当社も外注もエンジニア採用もせずに続けていますが、残しているのはコードより文書のほうが多いです。
最初の1つは何から作るとよいですか？
毎日発生していて、手順が決まっていて、間違えても取り返せる作業です。月に一度の重い業務から始めると、直す機会が月に一度しか来ません。
- 自社の開発フォルダを数えると、文書615本・約21万2千行に対しプログラム本体は166本・約11万9千行。文書のほうが約1.8倍多い（外部ライブラリ・バックアップを除いた実スキャン）。
- 止まるのは「やらないことが未定」「使う人が未定」「前提が古い」の3つの分かれ目。いずれも技術ではなく決めごとの問題。
- 完了は「動いた」ではなく「決めた検査に通った」。最初の1つは、毎日ある・手順が決まっている・間違えても取り返せる業務から選ぶ。
