AIで作ったアプリの保守：2週目について誰も教えてくれないこと

Proyecta との最初の週末に、あなたは本物の何かを出荷します。動きます。ユーザー（あるいはチーム、あるいは未来の自分）が使い始める。そして月曜日、お客様からメールが届くのです。「地域で絞り込めるドロップダウンを追加してもらえますか？」

ようこそ、保守の世界へ。これはAIアプリを作ることのうち、誰も語らない部分であり、ほとんどのプロジェクトが長く続く資産になるか、ひっそりと崖から落ちるかの分かれ目になる部分です。良い知らせは、AIで作ったアプリの保守は、従来のコードの保守とは違う体験だということ。正直な知らせは、「違う」が「タダ」を意味するわけではないということです。

保守が実際に意味すること

プロの開発者が「保守」と言うとき、彼らはおおむね4つのことを指しています。

リリース後に人々が頼んでくる小さな機能の追加。
壊れたもの、あるいは最初から間違っていたものを直すこと。
アプリの外側の変化についていくこと — 決済プロバイダーがAPIを更新する、新しいブラウザが出る、データの形が変わる。
コードベースがじわじわ沼にならないように片づけること。

AIで作ったアプリでも、この4つはすべて起きます。変わるのは、誰がそれをやるか、そして作業がどう感じられるかです。

良い知らせ：アプリに話しかけられる

古いチュートリアルからコードをコピペしていた頃、誰も教えてくれなかった部分がここです。AIアプリビルダーなら、作ったときと同じやり方でアプリを保守します。ほしいものを説明することによって。

実際の例です。私たちの知るある創業者が、自分のコーチング業のためにちょっとしたCRMを作りました — クライアント、セッション、支払いの追跡、ひととおり全部です。リリースから3週間後、あるクライアントが、その年に自分が何回セッションを受けたか見られたら嬉しいと口にしました。彼女はアプリを開き、こう言いました。「各クライアントのカードに『今年のセッション数』カウンターを追加して。セッションテーブルから日付が2026年のものを集計して。」 12分後、それは公開されていました。彼女はコーチングに戻りました。

その話は普通に聞こえますが、別の選択肢を思い出すまでの話です。フリーランサーに連絡し、2日待ち、300ドル払い、完全には理解できていないPRをレビューし、ほかに何も壊れていないことを祈る。保守のループが速いのは、AIがフリーランサーより賢いからではありません。ループの中にいる人間が少ないから速いのです。

より難しい知らせ：小さなことが積み重なる

ここが人々を引っかける部分です。AIで作ったアプリは、足し算が簡単なので、変えるのが簡単に見えます。簡単でないのは、成長していく中で全体を一貫させ続けることです。

うまくいかなくなる、いくつかのパターンを挙げます。

うっかりのもつれ。 「決済に割引フィールドを追加して」と頼む。6回の改訂の後、割引のロジックは3か所に存在し、正しいのはそのうち1つだけ。まだ何も壊れていませんが、次の変更は混乱を招くでしょう。
忘れられた要件。 3月に「50ドル以上で送料無料」を追加した。5月に、AIに「ギフトカードに対応できるように決済をやり直して」と頼む。やってくれる。送料無料のルールが消えている。2週間、誰も気づかなかった。
ずれ。 あなたのアプリは「自分のためのツール」として始まった。今ではチームが使っている。AIが前提にしているメンタルモデルは、いまだに「自分のため」のまま — 最初にあなたがそう言ったからです。新しい機能は妙にしっくりこないのに、その理由を指で示せない。

これらはどれも、AIアプリビルダーの失敗ではありません。記憶と共有コンテキストの失敗です — 人間の開発者チームが抱えるのとまったく同じ問題が、ただ別のかたちで現れているだけです。

どう自分を整えておくか

保守がうまくいくチームは、いくつかの習慣を共有しています。そのほとんどは技術的な習慣ではありません。アプリが何であるか、そして何が変わったかを、どう説明するかについての習慣です。

「このアプリは何か」ドキュメントを持つ。 1ページ。対象者、目標、ルール（「50ドル以上で送料無料」「日曜日にはユーザーにメールを送らない」「主キーはメールではなく電話番号」）。AIに何かを変えてもらうとき、関連するルールをプロンプトに貼り付ける。これはAIの知性を回避しているのではありません。AIには到底覚えていられないコンテキストを与えているのです。

変更を、コードではなく振る舞いの言葉で説明する。 「ユーザーがセッションをまたいで地域フィルターが記憶されているのを見られるようにしたい」は、「フィルターに localStorage を追加して」よりずっと良いリクエストです。前者はほしいものを説明していますが、後者は15通りあるうちの1つのやり方を指定していて、しかもおそらく最良のものではありません。

変更は一度に一つ。 1つのプロンプトに2つの変更を入れると、片方が黙って失敗しても、どちらか分からなくなります。AIアプリを保守するいちばん速い方法は、反復を、結果が正しいかひと目で分かるくらい小さく保つことです。

何が変わったかを見る。 ほとんどのAIアプリビルダーはプレビューを見せてくれます。使いましょう。新しい機能が動くことと古い機能が今も動くことを確かめるために、クリックして回る30秒は、今年あなたが買ういちばん安い保険です。

できないこと（そしておそらくやるべきでないこと）

AIでアプリを作ったあとは、AIがアプリの運用までやってくれると思いたくなる誘惑があります。それはできませんし、その隔たりは本物です。

何かが黙って壊れたとき、教えてはくれない。 ログ、監視、オンコール体制 — それらはいまだに別の関心事です。ほとんどのAIアプリビルダーは、バックエンドエンジニアのようにあなたの本番アプリを見張ってはいません。
アプリの外の世界を知らない。 決済プロバイダーがAPIを非推奨にしても、あなたが伝えるまでAIは知りません。プロバイダーの更新情報を購読しましょう。メールを読みましょう。
あなたの代わりにプロダクトの判断はできない。 機能を追加すべきか、どのトレードオフを取るか、ユーザーが本当に求めているものは何か — それはいまだにあなたです。AIはとても速い手であって、頭脳はあなたのものです。

現実的な姿

AIで作ったアプリと半年付き合ったあと、私たちが話す人々の多くは、だいたいこんなところに落ち着きます。変更に月2〜4時間ほどを費やし、そのほとんどすべてが会話です。かつて恐れていた大きな作り直し — 「まるごと新しいセクションを追加したい」 — は、いい午後一回分くらいに感じられる。退屈なこと — 「エクスポートの日付フォーマットが間違っている」 — は、いいプロンプト一回分に感じられる。

彼らが抱えていないのは、従来のコードベースが絶えず立てる雑音です。依存関係の更新、フレームワークの移行、セキュリティパッチ、ビルド設定。その雑音はプラットフォームに吸収されています。あなたはそれを扱ってもらうためにプラットフォームにお金を払っている。これは、それを扱ってもらうために開発者にお金を払うより、ずっと良い取引です。

これから最初のアプリを作ろうとしているなら、始める前に最初のAIで作るアプリは何にすべきかについての記事を読む価値があります。そしてもう数週間進んでいて、上のパターンのいくつかを感じ始めているなら、それは普通のことです。この週末に「このアプリは何か」ドキュメントを書きましょう。3ヶ月後、新しいダッシュボードを頼んでいる未来のあなたは、書いておいて本当によかったと思うはずです。