AI に頼んでアプリを作ると、気づけば画面がいくつも増え、設定やタブやボタンが積み重なっていきます。プログラミングに慣れていない人が AI に任せて作るとき（いわゆる vibe coding）は特にそうです。「ついでにこれも」と頼めば、AI はすぐに作ってくれるからです。
けれど、機能を増やさないことの大切さは、AI が出てくるずっと前から、ソフトウェアを作る人たちが繰り返し書いてきました。本稿では、その古典を引用しながら、なぜ機能と画面を増やしてはいけないのか、どうすれば増やさずに済むのかを整理します。最後に、AI に作らせるときの具体的な手をまとめます。
引用は原文の英語を載せ、すぐ後に日本語の訳を付けました。どれも 2026 年 11 月 6 日に原典を開いて確かめています。
先に本質
- 機能を作るのは簡単だが、長く維持するのにはコストがかかる。 不具合の修正、ほかの機能を変えたときの動作確認、説明の更新が、その機能がある限り続く。一度公開した機能は、使っている人がいるので消せない。
- 機能を 1 つ足すと、関連する機能も必要になり、画面も増える。 画面と遷移は、機能を足した結果として増える。画面を減らしたければ、機能の数を減らす。
- 要望や思いつきは、すぐには作らない。何度も出てくるものだけを検討する。 一度しか出なかった要望は、作らなくても困らなかったものだ。自分の思いつきも同じように扱う。
- 作っている途中で、やることは必ず増える。増えたら削る。 増えないようにするのではなく、「これが無くても出せるか」と問い続けて削る。削っても品質は下がらない。製品の得意なことがはっきりする。
- 最初は、作りたいものの半分だけ作る。 全部を中途半端に作るより、半分をきちんと作るほうが良い。いま必要でないものは後回しにする。
- 最初の画面には、よく使う機能だけを置く。 めったに使わない機能は 2 番目の画面に回す。3 段目の画面が必要になるなら、機能が多すぎる。「設定で切り替えられるようにする」は、機能と画面を増やすのと同じことだ。
- AI で作るのは速くなったが、維持するコストは変わらない。 確認、修正、説明の手間は残る。自分で理解していないコードでは、1 か所を直すと別の場所が壊れやすく、機能が多いほどその機会が増える。
以下、1 つずつ見ていきます。
1. 作るのは簡単、維持するのにコストがかかる — 一度出したら消せない
37signals（Basecamp の会社）が 2006 年に出した『Getting Real』は、Web アプリの作り方の本で、いまも Web で無料で読めます。その「Start With No」の章に、機能についての有名な一文があります。
“Each time you say yes to a feature, you’re adopting a child.”
機能に「はい」と言うたびに、子どもを 1 人引き取ることになる。
続けて、こう書いています。
“And once that feature’s out there, you’re stuck with it.”
そして、一度その機能を世に出したら、もう手放せない。
この一文が言っているのは、費用の大半が「作るとき」ではなく「持ち続ける間」にかかるということです。機能は作って終わりではありません。不具合を直し、他の機能を変えるたびに壊れていないか確かめ、説明を書き、問い合わせに答え続けます。
しかも、引っ込められません。Intercom の共同創業者 Des Traynor は、2014 年の講演「Product Strategy – Revisited」でこう話しています。
“One thing to know is that, it’s hard to take a feature back.”
知っておくべきなのは、一度出した機能を取り下げるのは難しい、ということだ。
使っている人が 1 人でもいれば、消すとその人が困ります。だから機能は足し算にしかなりません。足すかどうかを決める瞬間が、実質的に唯一の判断の機会です。
2. 機能は次の機能を呼ぶ — 画面はその結果として増える
『Getting Real』の次の章「Hidden Costs」は、機能の隠れた費用を扱います。
“For example, be on the lookout for feature loops (i.e. features that lead to more features).”
たとえば、機能の連鎖（ある機能が、さらに別の機能を呼ぶこと）に気をつけること。
例として、Basecamp に「会議」のタブを足してほしいという要望が挙がっています。
“We’ve had requests to add a meetings tab to Basecamp. Seems simple enough until you examine it closely.”
Basecamp に会議のタブを足してほしいという要望があった。よく調べるまでは、簡単そうに見える。
会議を扱うなら、場所、時刻、部屋、参加者、メールでの招待、カレンダーとの連携、説明の文書が要る、と続きます（“location, time, room, people, email invites, calendar integration, support documentation, etc.”）。
“Before you know it, a simple idea can snowball into a major headache.”
気づいたときには、単純な思いつきが雪だるま式に膨らみ、大きな頭痛の種になっている。
この章には、新しい機能を 1 つ足すときにやることの一覧があります。見出しは “For every new feature you need to…”（新しい機能のたびに、やらなければならないこと）です。
- 断る（Say no.）
- その機能に、価値があることを証明させる
- 再び「いいえ」ならここで終わり。「はい」なら続ける
- 画面をスケッチする
- 画面を設計する
- コードを書く
- 〜15. 試す、直す、試す、直す……
- 説明の文章を直す必要がないか確かめる
- 製品の案内を更新する（必要なら）
- 宣伝の文章を更新する（必要なら）
- 利用規約を更新する（必要なら）
- 破った約束がないか確かめる
- 料金の体系に影響しないか確かめる
- 公開する
- 息を止める（Hold breath.）
この一覧から分かることが 2 つあります。
1 つは、画面は機能の結果として増えることです。4 番目と 5 番目に「画面をスケッチする」「画面を設計する」があります。機能を 1 つ足すと決めた時点で、画面か、画面の一部が 1 つ増えることも決まっています。画面の数を減らしたければ、画面を工夫するより先に、機能の数を見るしかありません。
もう 1 つは、コードを書くのは 23 段のうちの 1 段にすぎないことです。後で詳しく書きますが、AI が肩代わりしてくれるのは主にこの 1 段です。
3. 最初の返事は「いまはやらない」 — 大事な要望は戻ってくる
では、要望が来たらどうするのか。『Getting Real』の「Start With No」はこう書いています。
“Every new feature request that comes to us — or from us — meets a no. We listen but don’t act.”
私たちのところに来る新しい機能の要望は、自分たちから出たものも含めて、まず「いいえ」に出会う。話は聞くが、動かない。
“The initial response is ‘not now.’ If a request for a feature keeps coming back, that’s when we know it’s time to take a deeper look.”
最初の返事は「いまはやらない」。ある機能の要望が何度も戻ってくるなら、そのときが、もっと深く検討する時期だと分かる。
大事なのは「自分たちから出たものも含めて」の部分です。断る相手は顧客だけではありません。自分の思いつきも同じように扱います。
Basecamp が 2019 年に公開した開発の進め方の本『Shape Up』も、同じ考え方です。第 3 章「Set Boundaries」には、こうあります。
“Our default response to any idea that comes up should be: ‘Interesting. Maybe some day.’ In other words, a very soft ‘no’ that leaves all our options open. We don’t put it in a backlog.”
出てきた思いつきへの既定の返事は「面白いね。いつかね」であるべきだ。言い換えれば、選択肢をすべて残したままの、とても柔らかい「いいえ」だ。やることの一覧（バックログ）には入れない。
一覧に入れない理由は、第 7 章「Bets, Not Backlogs」に書かれています。
“Backlogs are a big weight we don’t need to carry.”
やることの一覧は、背負う必要のない大きな重荷だ。
“The growing pile gives us a feeling like we’re always behind even though we’re not.”
膨らみ続ける山は、実際にはそうでないのに、いつも遅れているような気分にさせる。
そして、こう続けます。
“Really important ideas will come back to you.”
本当に大事な思いつきは、また戻ってくる。
“If you hear it once and never again, maybe it wasn’t really a problem.”
一度聞いたきり二度と聞かないなら、たぶんそれは本当の問題ではなかった。
「いいえ」か、「いまはやらない」か
ここで、立場が少し分かれることも紹介しておきます。Des Traynor の 2013 年のブログ記事「Product strategy means saying no」は、もっと強く言い切っています。
“If you’re building a product, you have to be great at saying no. Not ‘maybe’ or ‘later’. The only word is no.”
製品を作っているなら、断るのがうまくなければならない。「たぶん」でも「後で」でもない。言うべき言葉は「いいえ」だけだ。
一方で、同じ Traynor が翌 2014 年の講演では、決定は永遠ではないとして、こうも話しています。
“Doesn’t mean I’m saying no, it just means I’m saying, not now.”
「いいえ」と言っているわけではない。「いまはやらない」と言っているだけだ。
言葉の強さは違いますが、どちらもその場では作らないという点は同じです。違いは、後で再検討する余地を口に出すかどうかです。自分ひとりで作っているなら、『Getting Real』や『Shape Up』のように「いまはやらない」と決めて、戻ってくるかを見るのが現実的です。
4. 作る範囲は途中で必ず広がる — 止めるより、削り続ける
機能を断っても、作っている途中で範囲は膨らみます。『Shape Up』第 14 章「Decide When to Stop」は、それを誰かのせいにしません。
“Scope grows naturally. Scope creep isn’t the fault of bad clients, bad managers, or bad programmers.”
範囲は自然に伸びる。範囲が膨らむのは、悪い顧客や、悪い管理者や、悪いプログラマーのせいではない。
“Rather than trying to stop scope from growing, give teams the tools, authority, and responsibility to constantly cut it down.”
範囲が伸びるのを止めようとするのではなく、それを絶えず削るための道具と権限と責任を、チームに与えること。
範囲が伸びるのは自然なことなので、伸びない仕組みを作るのではなく、削る習慣を作る、という考え方です。
この章は、削ることへの後ろめたさにも答えています。
“Making choices makes the product better. It makes the product better at some things instead of others.”
選ぶことは、製品を良くする。他のことではなく、いくつかのことについて、製品を良くする。
“Variable scope is not about sacrificing quality.”
範囲を変えられるようにしておくことは、品質を犠牲にすることではない。
削ると「手抜き」に感じますが、そうではありません。全部をそこそこにやる製品より、いくつかのことが特に良い製品のほうが、選ばれる理由がはっきりします。
削るための問い
『Shape Up』は、範囲を叩いて削ることを「scope hammering（範囲を金槌で叩く）」と呼び、そのための問いを挙げています。
- “Is this a ‘must-have’ for the new feature?”（これは、新しい機能に必須か）
- “Could we ship without this?”（これが無くても出せるか）
- “What happens if we don’t do this?”（これをやらないと、何が起きるか）
- “Is this a new problem or a pre-existing one that customers already live with?”（これは新しい問題か。それとも、利用者がすでに付き合っている前からの問題か）
- “How likely is this case or condition to occur?”（この場合や条件は、どれくらい起きそうか）
- “When this case occurs, which customers see it? Is it core—used by everyone—or more of an edge case?”（それが起きたとき、どの利用者が目にするか。全員が使う中心の部分か、端の場合か）
- “What’s the actual impact of this case or condition in the event it does happen?”（実際に起きたら、どれだけの影響があるか）
- “When something doesn’t work well for a particular use case, how aligned is that use case with our intended audience?”（ある使い方でうまく動かないとき、その使い方は、想定している利用者とどれだけ合っているか）
さらに、「あれば良い」項目には印を付けておく、というやり方を紹介しています。
“Usually they never get built. The act of marking them as a nice-to-have is the scope hammering.”
たいてい、それらは結局作られない。「あれば良い」と印を付けること自体が、範囲を削る作業になっている。
「2.0」と名の付いた袋に気をつける
『Shape Up』第 3 章には、もう 1 つ覚えておきたい警告があります。
“When someone proposes something like ‘redesign the Files section,’ that’s a grab-bag, not a project.”
誰かが「ファイルの画面を作り直そう」のようなことを提案したら、それは何でも入る袋であって、計画ではない。
“A tell-tale sign of a grab-bag is the ‘2.0’ label.”
何でも入る袋の典型的な兆候は、「2.0」という名前だ。
「全体を作り直す」「2.0 にする」という提案は、終わりが決まっていないので、いくらでも物が入ります。範囲を決めずに始めた作り直しは、画面と機能を増やす一番の近道です。
5. 作りたいものを半分に切る
『Getting Real』の「Half, Not Half-Assed」の章は、副題が「中途半端な製品ではなく、半分の製品を作れ」です。
“Take whatever you think your product should be and cut it in half.”
製品はこうあるべきだと思っているものが何であれ、それを半分に切れ。
“Stick to what’s truly essential. Good ideas can be tabled.”
本当に欠かせないものに絞れ。良い思いつきは、棚上げしておけばいい。
Basecamp 自身も、最初はメッセージの機能だけで始めたと書いています（“With Basecamp, we started with just the messages section.”）。
「It’s a Problem When It’s a Problem」の章には、さらに思い切った例があります。
“we launched Basecamp without the ability to bill customers!”
私たちは、顧客に請求する機能なしで Basecamp を公開した。
有料サービスなのに、請求の機能は後回しにしました。料金は月ごとの請求なので、作るまでに 30 日の猶予があったからです。その間はもっと急ぐ問題を片づけ、請求は公開した後に作りました。余計な飾りのない、単純な作りで済んだとも書いています。「いつか必要になる」ものと「いま必要な」ものを分けると、最初に作るものはずっと少なくなります。
“Don’t sweat stuff until you actually must. Don’t overbuild.”
本当に必要になるまで、気に病むな。作りすぎるな。
同じ本の「Build Less」の章は、競合に勝つ方法としても、少なく作ることを勧めています。
“Instead of one-upping, try one-downing. Instead of outdoing, try underdoing.”
1 つ上を行くのではなく、1 つ下を行け。上回るのではなく、控えめにやれ。
Des Traynor の 2013 年の記事は、これを「機能の倉庫」という言葉で表しています。
“You end up with a repository of features, not a product.”
気づけば、製品ではなく、機能の倉庫ができあがっている。
6. 画面に全部を並べない — よく使うものだけを前に
機能が増えると、利用者はどうなるのか。これを 1 枚の図にしたのが、Kathy Sierra の「機能過多の曲線（Featuritis Curve）」です。横軸が機能の数、縦軸が利用者の満足で、機能が少なすぎると満足は低く、増えるにつれて上がり、ある点を越えると下がっていきます。満足が一番高い点を「幸せな利用者の頂上（Happy User Peak）」と呼びます。
原典のブログ（Creating Passionate Users）はいまは読めませんが、図は 37signals の DHH が 2014 年に「Kathy Sierra’s Featuritis Curve helps…」で紹介しています。
“Kathy Sierra’s Featuritis Curve helps focus the mind during feature discussions.”
Kathy Sierra の機能過多の曲線は、機能について議論するとき、頭を整理するのに役立つ。
機能が多すぎると満足が下がる理由の 1 つは、画面が探し物の場所になってしまうことです。これに対する設計の原則が、Nielsen Norman Group の Jakob Nielsen が 2006 年に書いた「Progressive Disclosure（段階的な開示）」です。
“Progressive disclosure defers advanced or rarely used features to a secondary screen, making applications easier to learn and less error-prone.”
段階的な開示は、高度な機能やめったに使わない機能を 2 番目の画面に回す。そうすると、アプリは覚えやすく、間違えにくくなる。
ポイントは、何を前に出し、何を奥に回すかの分け方です。
“You must get the right split between initial and secondary features.”
最初に見せる機能と、2 番目に回す機能を、正しく分けなければならない。
“You have to disclose everything that users frequently need up front, so that they have to progress to the secondary display only on rare occasions.”
利用者が頻繁に必要とするものはすべて最初に見せ、2 番目の画面に進むのはまれな場合だけにしなければならない。
“Conversely, the primary list can’t contain too many options or you’ll fail to sufficiently focus users’ attention on truly important issues.”
逆に、最初の一覧に選択肢を詰め込みすぎると、本当に大事なことに利用者の注意を向けられなくなる。
そして、この原則には限界があることも書かれています。
“If you have so many features that you need 3 or more levels, consider simplifying your design.”
3 段以上の深さが必要なほど機能があるなら、設計を単純にすることを考えるべきだ。
つまり、奥に回すのは機能を減らす代わりにはならないということです。奥に回して隠せるのは 1 段まで、多くても 2 段まで。それ以上必要になったら、画面の作り方ではなく機能の数が問題です。
「設定で切り替えられるように」は解決にならない
機能を断りきれないとき、「設定で ON / OFF できるようにすればいい」と考えがちです。Des Traynor の 2013 年の記事は、これにも答えています。
“This leads to death by preferences.”
これは、設定項目による死につながる。
“The hidden cost is that every optional feature weakens your product definition.”
隠れた費用は、選べる機能が 1 つ増えるたびに、製品の輪郭がぼやけることだ。
設定項目は、それ自体が画面と機能です。設定を 1 つ足すと、両方の状態で正しく動くか確かめる必要が生まれ、説明も 2 通り要ります。
7. AI は作る手間を無くしたが、持ち続ける費用は残っている
ここまでの古典は、どれも人がコードを書いていた時代のものです。AI が書いてくれるいま、話は変わったのでしょうか。
Des Traynor は 2013 年の記事で、こう警告していました。
“Lots of bad ideas can be built quickly. Don’t be seduced.”
悪い思いつきの多くは、すぐに作れてしまう。その誘惑に乗るな。
“There are no small changes.”
小さな変更というものは存在しない。
「すぐに作れる」ことは、AI の時代にはさらに強まりました。頼めば数分で画面が 1 つ増えます。けれど、2 節の 23 段の一覧のうち、AI が肩代わりするのは主に「コードを書く」の 1 段だけです。「試す、直す」の繰り返し、説明の更新、他の機能との整合、そして「一度出したら引っ込められない」ことは、何も変わっていません。
さらに、自分で理解していないコードの上では、持ち続ける費用はむしろ増えます。Addy Osmani は 2024 年 12 月の記事「The 70% problem: Hard truths about AI-assisted coding」で、プログラミングに慣れていない人が AI で作るときの壁をこう書いています。
“Non-engineers using AI for coding find themselves hitting a frustrating wall. They can get 70% of the way there surprisingly quickly, but that final 30% becomes an exercise in diminishing returns.”
AI でコードを書くエンジニアでない人は、もどかしい壁にぶつかる。7 割までは驚くほど速く進むが、最後の 3 割は、やればやるほど得るものが減っていく作業になる。
そして、「2 歩下がる」型として、次の流れを挙げています。
- 小さな不具合を直そうとする
- AI がもっともらしい変更を提案する
- その修正が、別の何かを壊す
- AI に、新しい問題を直すよう頼む
- それが、さらに 2 つの問題を生む
- これを繰り返す
“This cycle is particularly painful for non-engineers because they lack the mental models to understand what’s actually going wrong.”
この繰り返しは、エンジニアでない人には特につらい。実際に何がおかしいのかを理解するための頭の中の見取り図を持っていないからだ。
機能と画面が多いほど、修正が別の場所を壊す機会は増えます。機能を増やさないことは、AI で作るときこそ、壊れにくさを保つための一番確かな手段です。
なぜ AI で作ると増えるのか
古典と照らし合わせると、AI で作ると機能と画面が増える理由は 3 つに整理できます（ここからは本稿の考えです）。
- AI は「はい」と言う。 頼まれたことは作りますし、気を利かせて関連する機能まで足すこともあります。『Getting Real』の「まず断る」とは正反対の振る舞いです。
- 作る手間が見えなくなる。 23 段のうちの 1 段が数分で終わるので、残りの 22 段の費用まで小さく感じてしまいます。
- 全体を見ている人がいない。 1 回の指示ごとに部分を足していくので、いま画面がいくつあるのか、どこからどこへ遷移するのかを、誰も通して見ていません。
8. AI に作らせるときの具体的な手
最後に、ここまでの考え方を、AI に作らせるときの手順に落とします。古典の教えをそのまま当てはめた、本稿からの提案です。
作る前に、画面の上限と「作らないもの」を書いておく
AI が毎回読む場所（Claude Code なら CLAUDE.md）に、次のようなことを書いておきます。
## このアプリの範囲
- 目的: 勉強会の参加申し込みを受け付ける
- 画面は 2 つまで: 申し込みフォーム、申し込み一覧（主催者用）
- 作らないもの: ログイン、参加者のマイページ、メール通知、決済、設定画面
- 新しい画面・機能・設定項目を足す前に、必ず私に確認すること。
「ついでに」足すのは禁止「作らないもの」を書くのがポイントです。AI は書かれていないことを善意で足すので、足してほしくないものを先に名指ししておきます。最初の版は、『Getting Real』の言うとおり、思い描いたものを半分に切ってから書きます。
思いつきは、作らずに一覧に積む
作っている途中で「これもあると良いな」と思ったら、すぐ AI に頼まず、メモに書いて ~（あれば良い）の印を付けておきます。『Shape Up』が言うとおり、印を付けること自体が範囲を削る作業です。何度も同じことを思うなら、そのとき初めて検討します。
頼むときは、削る問いに答えさせる
どうしても足したいときは、作る前に AI にこう聞きます。
この機能を足す前に、次に答えてください。コードはまだ書かないでください。
- これが無くても、いまの目的は果たせますか
- これを足すと、画面・遷移・設定項目はいくつ増えますか
- 既存の画面の中に収める方法はありますか
- これを足したあと、ほかに必要になりそうな機能はありますか最後の問いは、『Getting Real』の「機能の連鎖」を先に見つけるためのものです。「会議のタブ」の後ろに場所・時刻・招待・カレンダー連携が連なっていたように、1 つの機能の後ろに何が続くかを、AI に先に挙げさせます。
画面を足す前に、既存の画面の奥に回せないか考える
段階的な開示の考え方で、めったに使わない操作は新しい画面にせず、既存の画面の「詳細」や「その他」の中に収めます。それでも奥が 3 段になりそうなら、機能そのものを見直す合図です。
「設定で選べるように」と頼まない
迷ったら、どちらか一方に決めます。設定項目は、それ自体が画面と機能です。
「作り直して」「2.0 にして」と頼まない
範囲の決まっていない作り直しは、AI に何でも足す口実を与えます。直したいなら、「申し込み一覧の並び順だけを変える」のように、終わりの分かる単位で頼みます。
まとめ
- 機能を作るのは簡単ですが、長く維持するのにはコストがかかります。一度出した機能は消せません。
- 機能は次の機能を呼び、画面は機能の結果として増えます。画面を減らしたければ、機能の数を見ます。
- 要望への最初の返事は「いまはやらない」。本当に大事なものは戻ってきます。自分の思いつきも同じように扱います。
- 範囲は自然に伸びるので、止めるより削り続けます。削ることは品質を下げることではありません。
- よく使うものだけを前に出し、残りは奥へ。奥が 3 段以上になったら、機能が多すぎます。
- AI は作る手間を無くしましたが、持ち続ける費用は残っています。理解していないコードの上では、むしろ増えます。だからこそ、AI に作らせるときは、画面の上限と「作らないもの」を先に書いておきます。
参考資料
37signals / Basecamp
- Getting Real（2006）: Start With No、Hidden Costs、Half, Not Half-Assed、It’s a Problem When It’s a Problem、Build Less
- Ryan Singer, Shape Up（2019）: 第 3 章 Set Boundaries、第 7 章 Bets, Not Backlogs、第 14 章 Decide When to Stop
- DHH, Kathy Sierra’s Featuritis Curve helps…（Signal v. Noise, 2014）
Intercom
- Des Traynor, Product strategy means saying no（2013）
- Des Traynor, Product Strategy – Revisited（Business of Software USA 2014 の講演と書き起こし）
画面の設計
- Jakob Nielsen, Progressive Disclosure（Nielsen Norman Group, 2006）
AI で作ること
- Addy Osmani, The 70% problem: Hard truths about AI-assisted coding（2024）
関連記事
Singularity Society はテクノロジー集団として MulmoClaude / MulmoTerminal / MulmoCast を開発しています。エンジニア・起業家向けの実践プログラム BootCamp も運営しています。
