AIで社内アプリを内製して失敗する7パターン【2026】

AIにコードを書かせて社内アプリを作り始めたものの、途中で止まってしまった——という相談が明確に増えています。共通しているのは、詰まる場所が「作る技術」ではなく、その手前と後ろに集中していることです。データ設計、権限、保守、引き継ぎ。動くものは1日でできても、業務で使い続けられる状態にするのは別の作業になります。

この記事では、実際に相談を受けた内製プロジェクトから、繰り返し起きている7つの失敗パターンと避け方を整理します。これから内製に着手する方が、着手前に読んでおくと手戻りをかなり減らせる内容です。

①データ設計を後回しにして、作り直しになる

最も多いパターンです。画面から作り始めると、見た目は早く形になります。ところが運用を始めた途端、「この項目を1つ増やしたい」「1件の案件に複数の担当を紐づけたい」という要求が出て、テーブル構造そのものを作り直すことになります。

避け方は単純で、先に台帳の形を決めることです。1行1レコード、1セル1情報、案件や顧客に一意のIDを振る、選択肢はマスターで固定する。この4点を決めてから画面に入ると、あとからの項目追加が「列を1本足すだけ」で済みます。詳しい設計原則はAIエージェントに社内データを渡すための台帳設計をまとめた記事に整理しました。

②認証を自作してしまう

ログイン画面を自分で作り、パスワードを自前のテーブルに保存する構成は、AIに書かせると驚くほど簡単に出てきます。しかしこれはもっとも事故が重い領域です。パスワードの保存方法、リセット導線、退職者の締め出し、総当たり攻撃への対処と、考えるべきことが際限なく増えます。

社内向けであれば、すでに使っているGoogle Workspaceなどのアカウントに寄せるのが定石です。同じドメインのメンバーだけがアクセスできる状態にしておけば、アカウント発行も退職時の権限剥奪も既存の運用に乗ります。認証は「作らない」のが正解だと考えてください。

③スプレッドシートAPIやApps Scriptの制限に当たる

スプレッドシートをデータ置き場にする構成自体は良い判断ですが、素朴に作ると実行時間やAPI呼び出し回数の上限に当たります。データが数百行のうちは快適で、数千行を超えたあたりから急に遅くなり、ある日エラーで止まる、という経過をたどります。

回避には、必要な範囲だけを一括で読む、書き込みをまとめる、キャッシュを持つ、といった設計上の工夫が要ります。「動いた」と「業務で毎日回る」の間にある差がここで、最初の試作では顕在化しないため気づきにくい落とし穴です。

④作った人しか直せない状態になる

担当者がAIと対話しながら作り上げたアプリは、その人の頭の中にしか全体像がありません。異動や退職が起きた瞬間、誰も手を出せないブラックボックスになります。実際、「前任者が作った社内ツールが壊れたが直せない」という相談は少なくありません。

最低限、次の3つは残しておいてください。

• データ構造の説明：どのシートの何列目が何を意味するか
• 設定の場所：選択肢やフェーズをどこで変えるか
• 復旧手順：壊れたときに何を戻せば復旧するか

⑤要件が育たず、半年で使われなくなる

業務は変わります。フェーズが増え、扱う商材が変わり、担当の分け方も変わります。ところが内製したアプリは、変更のたびに作った人の工数が必要になるため、依頼が溜まって放置され、現場が「結局スプレッドシートを直接触ったほうが早い」と戻ってしまいます。

これを防ぐには、コードを触らずに変えられる範囲を最初に設計しておくことです。表示項目の追加、選択肢の増減、フェーズの名称や並び順。この3つを管理画面から変更できるようにしておくだけで、日々の運用変更が自走します。ここを作らなかったプロジェクトは、ほぼ例外なく半年以内に停滞します。

⑥バックアップと変更履歴がない

AIが書き込む処理を入れた場合、これは必須です。想定外の入力で数百行が上書きされる、といった事故は現実に起こります。誰が・いつ・何を変えたかの記録と、一定期間前の状態に戻せる仕組みを、運用開始前に用意してください。

スプレッドシートを台帳にしている場合は変更履歴の機能が助けになりますが、それに頼り切らず、重要な更新はアクティビティとして自前で記録しておくほうが安全です。

⑦AIが書いたコードを誰もレビューしていない

最後は運用の話です。AIが生成したコードは動きますが、動くことと安全であることは別です。とくに次の3点は、生成物をそのまま使うと危険が残りがちです。

社内限定だから大丈夫、という判断は危険です。社内向けのつもりで作ったものが、実は誰でもアクセスできる状態だったというのは、公開直後に見つかる典型的な問題です。

内製がうまくいく会社の共通点

失敗ばかり書きましたが、うまくいっている会社もあります。共通点は3つでした。

逆に言えば、「新しく作る部分」を最小にした会社ほど続いています。全部を自作しようとしたプロジェクトは、作る楽しさのピークを過ぎたあたりで止まる傾向があります。

内製で詰まったときの現実的な出口

すでに着手していて止まっている場合、ゼロからやり直す必要はほとんどありません。多くの場合、台帳の整形と、人が見る画面の作り直しで動き出します。

私たちが提供している「スプシ de 社内アプリ」は、今あるスプレッドシートをそのままデータベースとして使い、人が見る画面（ボード・一覧・タイムライン・集計など）を用意するサービスです。認証はGoogle Workspaceの権限をそのまま使い、項目・選択肢・フェーズはお客さま側で変更できる管理画面をつけています。上に挙げた失敗パターンのうち①②④⑤は、この構成にすること自体で回避される設計になっています。

費用は初期25万円〜（テンプレート・セミオーダー）または50万円〜（オーダーメイド）、月額保守9,800円または19,800円（税別）で、人数課金ではありません。最短2週間から公開できます。記事の途中で恐縮ですが、内製の途中で止まっている段階でのご相談も多くいただいていますので、よろしければご覧いただけたら嬉しいです。

どこまでを自社で持ち、どこからは買うべきかという線引きそのものについては、脱SaaS・内製化がどこまで現実的かを整理した記事で扱っています。

まとめ：作る前に「変えられる範囲」を決める

内製の成否を分けるのは、AIの性能でもコードの品質でもなく、台帳の形・認証の置き場所・変更できる範囲の3つをいつ決めるかです。この3つを着手前に決めておけば、AIによる実装は非常に強力な武器になります。

逆に、画面から作り始めて3つを後回しにすると、動くものはできても業務では使われません。これから着手する方は、最初の1日を設計に使ってみてください。すでに止まっている場合の立て直しについても、現状の画面と台帳を拝見しながらご相談を承っています。