機能別のAI構築コスト見積り：シンプルな予算化手法

なぜAI構築コストは予測しづらく感じるのか

AIを使った開発は最初は安く感じますが、ある時点で急に高くなります。なぜなら固定の機能価格を払っているのではなく、試行の回数（メッセージ、生成されたコード、修正、テスト、手戻り）に対して払っているからです。計画があいまいだと、試行回数が急増します。

多くのコスト急増は同じようなパターンから生じます：

• スコープが暗黙で明文化されていない（例：「認証を追加」だけで、ロール、プロバイダ、パスワードリセットが未定）
• リトライが積み重なる（ほぼ合っているプロンプトが3〜10回のフォローアップを生む）
• 仕様が途中で変わる（新しいフィールドや画面、異なるルール）、そのため既存作業が置き換わる
• 隠れた要件が後で出てくる（ローディング、バリデーション、エッジケース、エラーステート）
• 「あとひとつだけ」の微調整が複数画面にまたがる再設計に発展する

見積もるときは、実際に何を予算化しているのかを明確にしてください：

1. プラットフォームが請求するクレジットや利用単位
2. トークン（プロンプトと出力のサイズ）
3. 時間（レビュー、テスト、修正にかかる時間）

見積りは1つの数値ではなくレンジとして扱ってください。UIでは小さく見えてロジックが大きいこともあれば、その逆もあります。最良は強いファーストドラフト、最悪は複数回の修正ループです。

以下では再現可能な機能バケット（認証、CRUD、統合、UIリデザイン）を使います。クレジットベースのvibe-codingプラットフォーム（例：Koder.ai (koder.ai)）を使っていると、最初に「ダッシュボードを作る」とだけ言って後からロールや監査ログ、新しいレイアウトを追加すると、これらを最初に明記した場合よりずっと多くのクレジットを消費することがわかるでしょう。

クレジットとトークンをわかりやすく

人々はしばしばトークン、クレジット、ビルドステップという3つの考えを混同します。これらを分けるとコストが予測しやすくなります。

トークンはモデルが読む／書くテキストの小さな単位です。プロンプトがトークンを使い、モデルの返答もトークンを使い、長いチャット履歴もモデルが再読するためにトークンを消費します。

クレジットはプラットフォームが請求する単位です。Koder.aiのようなツールでは、クレジットは一般にモデル使用料とチャットの裏で動くプラットフォーム側の作業（エージェントがタスクを実行する、ファイルを作る、結果をチェックする等）をカバーします。内部の詳細を知らなくても予算を立てることはできますが、使用量を増やす要因を認識する必要があります。

ビルドステップはプロジェクトに対する意味ある変更です：「メールログインを追加」「usersテーブルを作成」「この画面をエンドポイントに繋ぐ」など。1つの機能は多くのステップを必要とし、各ステップが複数のモデル呼び出しを引き起こすことがあります。

使用量が最も速く増えるのは、コンテキストが長いとき（大きな仕様、膨大なチャット履歴、多数の参照ファイル）、反復が多いとき、大きな出力（ファイル全体の書き換え、大きなコードブロック）があるとき、あるいはあいまいな要求でモデルに推測させる必要があるときです。

小さなプロンプトの違いがコストを大きく左右します。なぜならリトライ回数に影響するからです。"完全な認証システム"は意図しないオプションを招きますが、"メールとパスワードのみ、ソーシャルログイン無し、正確に2画面"と指定すれば余計な部分が減ります。

一つの原則：動く部品が少ないほどリトライは減る。

機能優先の見積もり方法

「画面」や「メッセージ」で見積もるのをやめ、ユーザーが口にするような機能単位で見積もってください。それにより予算は成果に結びつき、チャットの冗長さに左右されにくくなります。

各機能について3つのパートを見積もります：

• Build：コードを生成してアプリに接続する
• Test：フローを実行し、明らかなバグを修正し主要なエッジケースを扱う
• Revise：動作を確認した後の2回目の手直し（文言調整、バリデーション、小さなUX修正）

大多数の予算超過はテストとリビジョンで起き、初回ドラフトでは起きません。

各パートに対して low（簡単）、typical（やややり取りあり）、high（サプライズあり）のレンジを使ってください。プラットフォームがクレジットベースならクレジットで追跡し、トークンを直接追うならトークンで追跡します。目的は、現実が変わっても正直に残る予測を持つことです。

2つの行を分けておくと自己誘発的な超過を防げます：

1. Unknowns buffer（不明点バッファ 10–20%） を独立の行として置く。機能内に隠さないこと。

2. Later changes requested（後からの変更） を別のバケットにする。機能が承認された後に出た新しいアイデア（"チーム機能を追加"、"ダッシュボードをXのように"）のための枠です。分けないと元の見積もりのせいにしてしまいます。

軽量テンプレート例：

Feature: Password login
- Build:    low 30 | typical 60 | high 120
- Test:     low 15 | typical 30 | high 60
- Revise:   low 10 | typical 20 | high 40
Subtotal (typical): 110

Buffer (15%): 17
Later changes (held): 50

これを各機能（認証、CRUD、統合、UI刷新）について繰り返し、"typical"を計画用に合算し、"high"を最悪ケースのチェックに使ってください。

よくある機能の見積もり：認証とCRUD

認証とCRUDは基本に見えてスコープがあいまいだと高くなります。メニューのように扱ってください：各オプションがコストを追加します。

認証：ただ"ログイン"と言わず、正確な形を定義する

アクセス制御の「完了」を書き出してください。最大の要因はログイン方法の数と権限パスの数です。

具体的に決めるべき点：

• ログイン方法（メール/パスワード、マジックリンク、Google、Apple、SSO）
• ロールと権限（admin/editor/viewer とそれぞれの権限）
• パスワードルール（長さ、複雑さ、ロックアウト、リセットフロー）
• セッションルール（有効期限、ログアウト、Remember-me の挙動）
• アカウントライフサイクル（招待、無効化/削除、メール確認）

ただ「認証を追加」と言うと汎用的なソリューションが入り、後からエッジケースを修正するために費用が発生します。形を先に決める方が安く済みます。

CRUD：テーブルではなく画面と挙動の数を数える

CRUDのコストはエンティティ数とそれぞれに必要な挙動で決まります。実用的なモデル：各エンティティは通常3〜6画面（一覧、詳細、作成、編集、場合によっては管理や監査ビュー）を意味し、API作業やバリデーションも必要です。

CRUDをスコープする際はエンティティ名を挙げ、フィールド、型、バリデーションルール（必須、一意、範囲）を含めてください。それから一覧の挙動（フィルタ、ソート、ページング、検索）を定義します。「検索」は単純なcontainsフィルタか、より重い処理かで大きく変わります。

管理画面がユーザー用画面と異なるかも決めてください。別レイアウト、追加フィールド、バルクアクションがあると工数は倍増します。

コストを急速に上げるエッジケース：行レベルの権限、監査ログ、CSVインポート/エクスポート、ソフトデリート、承認ワークフロー。これらは実現可能ですが、事前に明示すると予算は予測可能に保てます。

統合を推測せずに見積もる

統合は隠れた作業を抱えがちなので、小さなテスト可能な塊に分けて見積もると予測がしやすくなります。

堅実な統合スコープには通常以下が含まれます：

• 接続と認証（APIキーまたはOAuth、トークン更新）
• 1つのオブジェクトのエンドツーエンド（ハッピーパス）
• 同期の振る舞い（ウェブフックまたはスケジュール、ページング、レート制限）
• 障害対応（リトライ、冪等性、再実行パス）
• テストとエッジケース（不正データ、権限不足、タイムアウト）

生成前にデータ契約（必要なオブジェクトと正確なフィールド）を固めてください。"顧客を同期"は曖昧です。"Customer{id, email, status} と Order{id, total, updated_at} を同期"ならモデルが余計なテーブルや画面を作りません。

方向性と頻度も決めてください。一方向のインポートのみは双方向よりずっと安上がりです。双方向が必要ならソース・オブ・トゥルースやラストライトウィンズなど勝者ルールを先に決めてください。

障害に対しては必ず備えるつもりで計画してください。APIがダウンしたらどうするか。ログ記録＋アラート＋手動での「再実行」ボタンで十分な場合が多いです。必要以上のオペスシステムにお金を払うのを避けるために最小限に留めましょう。

第三者APIの癖やテストのために20–40%のバッファを追加するのが現実的です。単純なAPIでもページングや奇妙な列挙型、ドキュメントの不一致、レート制限があり得ます。

リデザインとUI変更の見積もり

UI作業は予算が静かに漏れる場所です。「リデザイン」は色を入れ替えるだけか、フロー全体を作り直すかのどちらかなので、何が変わるかを明確にしてください：レイアウト、コンポーネント、文言、ユーザーステップのどれが対象か。

視覚的な変更のみを動作に影響する変更と分けてください。視覚-onlyはスタイルや間隔、コンポーネント構造に触れます。ボタンの挙動やバリデーション、データ読み込みを変えると機能作業です。

ページリストのようにスコープする

"アプリ全体をリデザイン"は避けて、正確な画面と状態を列挙してください。列挙できなければ見積もれません。

短く具体的なスコープにする：

• 含むページ（例：Login, Dashboard, Settings）
• 含む状態（empty, loading, error, success）
• 何を変えるか（レイアウト、コンポーネント、文言、フロー）
• 参照スタイル（色、タイポ、間隔のメモ）
• 許可されるパス数（例：1回のビルドパス + 1回の仕上げパス）

こうしたプロンプトはモデルがコードベース全体を推測するのを止め、やり取りを減らします。

QAパスを省かない

UI変更は通常デスクトップとモバイルの両方で最低2回のチェックが必要です。完全な監査でなくてもコントラスト、フォーカス状態、キーボードナビゲーションの基本は入れてください。

実用的な見積もり方法：

(ページ数) × (変更深度) × (パス数)

例：3ページ × 中程度の深度（新しいレイアウト＋コンポーネント調整）× 2パス（ビルド＋仕上げ）は予測しやすいクレジットの塊です。オンボーディングフローも変えるなら別行で扱ってください。

ステップバイステップ：プロンプトで予算化されたスコープを作る

クレジットを抑える最も安い方法は、モデルに頼む前に何を欲しいかを決めることです。手戻りがコストを跳ね上げます。

まず1段落でユーザーとゴールを述べます。例："小さなクリニックの受付担当がログインし、患者を追加し、予約を入れ、今日の一覧を見る"。これで境界が設定され、モデルが余計なロールや画面を作るのを抑えられます。

その後、プロダクトをモジュールや画面とアクションで記述します。"appointmentsモジュール"ではなく "Calendar画面：作成、リスケ、キャンセル、検索" のように書くと作業が数えられます。

必要なデータは最小限に留めます。まだすべてのフィールドは不要で、本質的なものだけで十分です。強いプロンプトは通常次を含みます：

• ユーザーとロール（誰が何をできるか）
• 画面とアクション（ユーザーが何をクリックするか）
• コアテーブルと主要フィールド（何を保存するか）
• 受け入れチェック（どうなれば完了か）
• 範囲外（何を作らないか）

受け入れチェックを書くと二度手間を防げます。各機能につき2–4件のチェック（例：「ユーザーがメールでパスワードをリセットできる」「予約作成がダブルブッキングを防ぐ」）を書いてください。Koder.aiを使っている場合、これらのチェックはPlanning Modeに自然に合います。

範囲外を明確にしておく："管理ダッシュボードは作らない"、"支払いは作らない"、"多言語は作らない"、"外部カレンダー連携は作らない"。こうするとサプライズの"あるといいね"作業を防げます。

小さな塊で作っては再見積もりするリズムで進めてください。簡単なリズム：1画面または1エンドポイントを生成し、動かして問題を直してから次へ。もし塊が予想より高くつくなら、次の塊でスコープを削るか減らしてください。

コストを下げつつ品質を落とさない方法

大部分のコストスパイクは1つのメッセージでやりすぎることから来ます。モデルをチームメンバーとして扱い、小さく明確なステップで説明してください。

計画から始めて、まず短いビルドプランを求め、前提と未解決の質問を確認してから最初の小さな実装を依頼します。計画・構築・テスト・コピー作成・スタイリングを1つのプロンプトに詰め込むと長い出力とミスを招きます。

コンテキストはタイトに保ち、変更に関係のある画面・コンポーネント・APIノートだけを含めます。余計なファイルはトークンを増やし、無関係な部分への編集を引き起こします。

小さな差分を求めてください。可能なら1プロンプトで1つのことだけ変える：単一のエンドポイント、1つのフォーム、1つのエラーステート、1つの画面。小さな変更はレビューしやすく、何か失敗しても無関係な作業を再実行する必要がありません。

実用的な作業ルール：

• 要求するもの：まず計画、その後1実装ステップ、最後に短いレビューチェックリスト
• 提供するもの：最小限のコンテキスト（現在の挙動、望む挙動、制約）
• 制限するもの：リビジョン回数（例：2回）
• 要求するもの：何が変わったかの短い要約
• 記録するもの：手戻りの原因を記録してプロンプトを更新

ループを早く止めてください。2回目の試行がまだズレているなら、単に"もう一度"と言うのではなく入力を変えてください。欠けている詳細を追加する、矛盾を排除する、失敗事例を示すなどです。

例："ログイン＋パスワード忘れ"とレイアウト改善を同時に求めるなら、3つのプロンプトで行ってください：

1. フローと必要画面の概要
2. 認証フローのみの実装
3. UIの間隔と色の調整

各ステップがレビュー可能で安価に保てます。

予算を吹き飛ばす一般的なミス

多くの超過は大きな機能のせいではなく、小さなスコープの欠落が積み重なって発生します。これが追加のプロンプトラウンド、生成コード、修正を生み、コストが増えます。

予算を破る5つの原因（対処法付き）

完了条件に合意せずに作る

受け入れチェックなしにコードを生成すると書き直しに金がかかります。先に3–5件のチェックを書く：ユーザーが何をできるか、どのエラーが表示されるか、どのデータを保存するか。

曖昧な言葉を使う

"モダン"、"良くして"、"もっと良く"は長いやり取りを招きます。"デスクトップは2カラム、モバイルは1カラム"や"プライマリボタン色 #1F6FEB"のように具体的に置き換えてください。

複数機能を1つのプロンプトに詰め込む

"認証を追加、請求を追加、管理ダッシュボードを追加"は変更追跡と見積もりを困難にします。1機能ずつ行い、触ったファイルの簡潔な要約を求めてください。

後半でデータモデルを変更する

テーブル名の変更、関係の変更、IDの切り替えはUI・API・マイグレーション全体に修正を強います。主要エンティティは早めに固定し、いくつかのフィールドは"将来用"にしておきましょう。

テストを最後まで先送りする

バグは再生成→修正→再生成のループになります。各機能に対して小さなテストセットを求め、まとめて1回の巨大なテストをするのは避けてください。

具体例：Koder.aiに対して"CRMを良くして"とだけ言うと、レイアウト変更、フィールド名の変更、エンドポイントの調整が一度に行われることがあります。すると統合が壊れ、何が動いたかを調べるだけでクレジットを消費します。代わりに"データモデルは変更しないで、一覧ページのUIのみ更新、APIルートは触らない、次の4チェックを通す"とすると変動を制限でき、コストが安定します。

開始前のクイックコストチェックリスト

見積もりは一つの魔法のプロンプトではなく小さなプロジェクトの計画のように扱ってください。2分のチェックで大抵の過剰支出問題を防げます。

以下を確認し、"いいえ"があれば生成前に修正してください：

• 機能リストに境界がある（何をするか・しないか・開始と終了が明確）
• 各機能に対して low/typical/high のレンジがあり、最初のビルドには1つの数値にコミットしている
• プロンプトに受け入れチェックと明確な範囲外が含まれている
• 小さな塊で作り各塊ごとにレビューする：挙動を確認し、変更を読み、次の塊に進むか判断する
• 統合とUI修正など、拡張しがちな部分の予算を確保している

Koder.aiを使っている場合、各塊をスナップショットポイントのように扱ってください：部分を生成しテストしてから続ける。スナップショットとロールバックはデータモデル変更、広範なUIリファクタ、統合書き換えなどリスクの高い変更前に最も価値があります。

単純な例："ユーザ管理を作る"ではなく、"メールログインのみ、パスワードリセット付き、ソーシャルログイン無し、管理者はユーザーを無効化できる、ログインとリセットのテストを含む"とスコープする。明確なチェックがあればリトライが減り、リトライがトークンやクレジットを消費します。

機能リストから小アプリの見積もり例

現実的な小規模アプリの例を示します：ログイン、2つの簡単なモジュール、1つの統合。"ビルドサイクル"は短い計画→コード生成→クイックレビューと修正と仮定します。クレジットは主に何回サイクルを回すかと各サイクルの大きさで追跡されます。

内部ツール用の機能リスト例：

チェックポイントを厳しく保つプロンプトのシーケンス例：

1. 計画：各機能のフィールド、画面、ルール、範囲外を確認する
2. モジュール1のみ構築：Employeesをエンドツーエンドで生成して止める
3. レビュー：フローをテストし、バグを直し、フィールドを固定してから進む
4. 同様にモジュール2を繰り返す
5. 中核フローが安定してから統合を最後に追加する

コードが存在した後で決定を変えるとコストが跳ね上がります。よくあるトリガーはロール変更（新ロールや権限パス）、後半でのフィールド追加（特にモジュールや統合にまたがる場合）、統合エラー（認証失敗、ペイロード不一致）、フォームが存在した後のUIリデザインです。

次のステップ：機能ごとに計画してサイクルで構築し、各サイクル後にクレジットを再確認してください。リスクの高い変更（データモデル編集、広範なUIリファクタ、統合書き換え）の前にスナップショットを取るとロールバックが簡単になり、通常の範囲内にプロジェクトを保てます。