「AIでシステム改修するのにプロンプトは要りません」と言うと、全員の頭が？？？になる

— お問い合わせフォームからコピペだけでシステムが直る仕組みの話 —

「プロンプトを書かないんですか？」

クライアント先でAIを使ったシステム改修の流れを説明すると、必ずこの質問が来ます。

「AIを使うなら、プロンプトエンジニアリングとか、指示の書き方とか、勉強しないとダメですよね？」

いいえ。私たちのシステムでは、プロンプトは書きません。

この時点で、相手の頭に？マークが3つくらい浮かぶのが見えます。

実際の流れを見てください

あるクライアントの業務システムで、ユーザーから「ユーザー管理が開けない」という問い合わせが来ました。

ユーザーがやったことは、システム画面の右下にあるチャットボタンを押して、フォームに入力しただけです。

不具合・エラー・改善点等：「ユーザー管理開けない」
ご要望：「エラーになります」
スクリーンショットを1枚添付

送信ボタンを押す。これだけ。

管理画面を開くと、この問い合わせがチケットとして届いています。チケット番号TK000164。ステータスは「対応中」。ユーザーの環境情報（Windows / Chrome 146）や直近の操作履歴（10件）も自動で収集されています。

ここで管理者がやることは、「開発プロンプトを開く」ボタンを押すこと。するとこんなテキストが表示されます。

以下に対応してください。
## 報告内容（TK000164）
- カテゴリ: システム > 質問
- 概要: ユーザー管理開けない
- 不具合・エラー・改善点等: ユーザー管理開けない
- ご要望: エラーになります
- 発生URL: https://example.com/admin/dashboard
- 環境: Windows / Chrome 146
## 添付画像
- スクリーンショット1（URL）
## 対応指示
1. 原因を特定し修正を実装
2. 更新履歴を追記

これをコピーして、Lovable（AI開発ツール）のチャット欄に貼り付ける。

以上です。

Lovableがコードを修正し、数分後にはシステムが直っています。

「それ、AIがプロンプトを書いてるんですよね？」

いいえ。ここが一番驚かれるポイントです。

この「開発プロンプト」と呼んでいるテキスト、AIは一切関与していません。

技術的に何が起きているか

仕組みはシンプルです。ユーザーがフォームに入力した内容は、送信時に【不具合・エラー・改善点等】【ご要望】【備考】といったタグで構造化されてデータベースに保存されます。

管理者が「開発プロンプトを開く」ボタンを押すと、フロントエンド側のJavaScript関数がこのテキストを正規表現（/【(.+?)】([\s\S]*?)(?=【|$)/g）でパースし、Markdown形式に並べ替えます。同時に、ユーザーエージェント文字列からOS・ブラウザを判定し（例：「Mozilla/5.0 (Windows NT 10.0…)」→「Windows / Chrome 146」）、添付画像のストレージURLをMarkdownリンクとして挿入します。

ここで使われている技術は、正規表現と文字列操作だけ。LLMのAPI呼び出しはゼロです。

では、なぜこんなシンプルな変換で十分なのか。それは、フォームの設計そのものが「Lovableが理解できる粒度」になっているからです。

フォームの入力項目は、AI開発ツールが問題を理解するために必要な情報——「何が起きたか」「どうしたいか」「どこで起きたか」「どんな環境か」——を正確に分解して収集するように設計されています。つまり、プロンプトエンジニアリングの仕事を、フォームUI設計の段階で完了させているのです。

なぜコピペだけで改修できるのか

ここで「いやいや、そんな短い文章でシステム修正ができるわけがない」と思う方もいるでしょう。

実は3つの技術的な仕掛けがあります。

1つ目。Lovableはプロジェクトのコード全体を知っている。

Lovableは私たちが構築したシステムのソースコード全体をコンテキストとして保持しています。コンポーネントの構成、データベースのテーブル設計、APIのエンドポイント——すべてを「理解」した状態で指示を受け取ります。

だから「ユーザー管理が開けない」「発生URL: /admin/dashboard」と言われれば、該当するページコンポーネント、そこで呼ばれているフック、関連するSupabaseのテーブルとRLSポリシーまで、自分で探し出して修正できます。人間が「このファイルのこの関数を見てください」と指示する必要がありません。

2つ目。スクリーンショットのURLがそのまま渡る。

ユーザーが添付したスクリーンショットは、チケット送信時にWebP形式に変換（最大幅1200px、品質0.85）されてSupabase Storageに保存されます。開発プロンプトにはそのストレージURLがMarkdownリンクとして含まれるので、LovableはURLをたどってエラー画面の状態を「見る」ことができます。

ここが重要なのですが、管理者がスクリーンショットをダウンロードしてLovableに再アップロードする必要がありません。URLがテキストに含まれている時点で、画像情報もコピペの一部として渡っているのです。

3つ目。環境情報と操作履歴が自動で付加される。

チケット送信時に、ユーザーの環境情報（OS、ブラウザ、画面解像度、ビューポートサイズ、デバイスピクセル比、タイムゾーンなど）がJavaScriptで自動収集されます。さらに、認証済みユーザーの場合は直近10件の操作ログ（どのテーブルにいつINSERT/UPDATEしたか）もデータベースから取得されます。

これにより、「この人はWindows環境でChrome 146を使っていて、直前にshop_ordersテーブルへのINSERTを行っていた」という文脈が、ユーザーが何も意識しなくても記録されています。レスポンシブの崩れなのか、特定ブラウザの互換性問題なのか、特定の操作後にだけ発生するバグなのか——原因の切り分けに必要な情報が、最初から揃っているのです。

改修後の顧客対応も自動化

さらに、改修が終わった後の流れも仕組み化されています。

管理者が改修結果を入力して保存ボタンを押すと、AIが自動で顧客向けの返信文を生成します。「〇〇の不具合を修正いたしました。お手数ですが画面を再読み込みしてご確認ください」といった文面です。

整理すると、全体の流れはこうなります。

ユーザーがフォームで問い合わせを送信（AIなし・フォーム入力のみ）
AIが一次回答を自動生成（ここで初めてAIが登場）
管理者が「開発プロンプトを開く」→ コピー（AIなし・正規表現パースのみ）
Lovableに貼り付け → システム改修（AIがコード修正）
改修結果を入力 → 顧客返信文を自動生成（AI）

AIが使われているのは2と4と5だけ。そして、人間が「プロンプト」を考える場面はゼロです。

この設計を支える技術アーキテクチャ

少し専門的な話になりますが、この仕組みがなぜ安定して動くのか、技術的な背景も説明します。

フロントエンドはReact（Lovableで構築）、バックエンドはSupabase（PostgreSQL + Edge Functions + Storage）です。問い合わせの送受信はすべてSupabase Edge Function経由で行っており、未ログインユーザーからの問い合わせにも対応できるようRLS（Row Level Security）をバイパスする設計にしています。

添付ファイルはフロントエンド側でWebP変換（最大幅1200px、品質0.85）した上でBase64エンコードし、Edge Function経由でSupabase Storageに保存。チケットのリアルタイム更新はPostgreSQLのLISTEN/NOTIFYを利用しており、管理者側の画面は常に最新状態が反映されます。

AI一次回答の生成にはGemini AIを使用しており、ロール別のFAQ・マニュアルデータをコンテキストとして渡すことで、ほとんどのよくある質問にはAIが自動回答します。confidence（自信度）がlowの場合はAI回答をスキップし、直接チケットをオープンにする——つまり、AIが「わからない」と判断したら人間に回すフェールセーフも組み込んでいます。

このアーキテクチャのポイントは、AIに依存する箇所を最小限に絞っていることです。問い合わせの受付、構造化、開発指示の生成、環境情報の収集——これらはすべて従来の技術（フォーム、正規表現、JavaScript）で実装されており、AIが停止してもチケット管理自体は問題なく動き続けます。

なぜ「プロンプト不要」が重要なのか

「プロンプトの書き方を勉強しましょう」というAIセミナーが溢れています。もちろん、プロンプトエンジニアリングは有用なスキルです。

しかし、経営者や現場の担当者が本当に求めているのは「プロンプトを上手に書く力」ではありません。「問い合わせが来たら、なるべく早く、なるべく手間なく、システムが直ること」です。

プロンプトを書くスキルを組織に定着させるのは、実はかなり大変です。担当者が変わるたびに品質がブレます。「この書き方だとAIが誤解する」「もっと具体的に書いて」——こういった属人的なノウハウは、スケールしません。

一方、フォームの設計は一度作れば誰が使っても同じ品質の情報が集まります。新入社員でも、ITに詳しくない人でも、フォームに沿って入力するだけ。プロンプトの品質は「人」ではなく「仕組み」が担保するのです。

システム改修すら属人化させない

ここで、もう一歩踏み込んだ話をします。

多くの企業では、システムの改修は「詳しい人」に依存しています。CTOやリードエンジニアがいないと直せない。外注先に依頼すると見積もりに2週間、実装に1ヶ月。担当者が退職したらブラックボックス化する。

私は、システム改修そのものも属人化させるべきではないと考えています。

このチケットシステムの設計思想はまさにそこにあります。

問い合わせの受付 → 構造化 → 改修指示の生成 → AIによる修正 → 顧客への返信——この一連の流れの中で、「特定の人にしかできない作業」をゼロにすることを目指しています。

実際、今回のTK000164の例で管理者がやったことを振り返ってみてください。「開発プロンプトを開く」をクリック。コピー。Lovableに貼り付け。これだけです。システムの内部構造を理解している必要はありません。どのファイルを修正すべきか知っている必要もありません。

従来のシステム開発では、バグ報告が来たら、エンジニアが報告内容を読み解き、コードベースの中から該当箇所を探し、修正方針を考え、実装し、テストする——このすべてに専門知識が必要でした。

この仕組みでは、「コードベースの中から該当箇所を探す」のはLovableがやります。「修正方針を考える」のもLovableがやります。人間の仕事は「ユーザーの声をLovableに届ける」こと、そして「修正結果を確認する」ことだけです。

もちろん、複雑なアーキテクチャ変更やデータベース設計の見直しは、専門家の判断が必要です。しかし、日常的に発生する「画面が開けない」「表示がおかしい」「ここをこう変えてほしい」といった改修の8割は、このフローで対応できます。

**システム改修を「誰でもできる業務」に変える。**これが、AI活用における最大の組織変革だと考えています。

103件のチケットが教えてくれたこと

現在、このシステムには103件のチケットが蓄積されています。

この103件を通じてわかったことがあります。AI活用で最も重要なのは、「AIの性能」でも「プロンプトの品質」でもなく、**「AIに渡す前の情報設計」**だということです。

ユーザーの声をどう構造化するか。どの粒度で情報を分解するか。どの文脈情報を自動で付加するか。この設計さえ正しければ、あとはコピペです。

逆に言えば、この設計が間違っていると、どんなに高性能なAIでも的外れな修正をします。

AIセミナーで教えてくれないこと

多くのAIセミナーは「AIツールの使い方」を教えてくれます。プロンプトの書き方、便利なツールの紹介、最新モデルの比較。

しかし、**「自社の業務フローにAIをどう組み込むか」**は教えてくれません。

お問い合わせフォームの項目設計が、実はAI開発の品質を左右している。フォームの入力項目を変えるだけで、AI開発ツールの修正精度が劇的に変わる。システム改修を特定の人に依存しない仕組みにすることで、組織全体の対応速度が上がる——こういう話は、セミナーでは出てきません。なぜなら、これは個社ごとに異なる「設計」の話であり、汎用的なノウハウにならないからです。

でも、本当に価値があるのはそこです。

BANSOU CTO™では、この「設計」を御社と一緒に作ります。AIセミナーで学んだ知識を、御社の現場で実際に動く仕組みに変換する。プロンプトを書く人材を育てるのではなく、プロンプトが要らない業務フローを設計する。システム改修を「詳しい人がいないと動かない」状態から、「仕組みで回る」状態に変える。

それが、AIを「入口で終わらせない」ということです。

株式会社IIWAYO.TECH 代表取締役伊藤翔太 BANSOU CTO™ — AIを「入口」で終わらせない、伴走型フラクショナルCTOサービス Lovable National Treasure（日本No.1 / 世界Top 1% Lovableクリエイター認定）

次に読むおすすめ

「「システム会社に頼むのは、もうやめたほうがいい」——中小企業のシステム内製化が、いま現実解になった理由」
「AIで700万行のコードを生成した「バイブコーディング」とは何か。従来の26年分の工数を4ヶ月で実現した開発手法の全貌」
「AI開発ツールで電子契約システムを作って壁にぶつかった話〜Claude Opusと一緒に解決した全記録〜」