AIコーディングツールで作るべきプロダクト（と避けるべきもの）

AI支援コーディングに適したプロダクトの選び方

AIコーディングツールは関数を書いたり、ボイラープレートを生成したり、アイデアをスターターコードに翻訳したり、障害時に修正案を出したりできます。特に慣れたパターン（フォーム、CRUD画面、単純なAPI、データ変換、UIコンポーネント）を高速化するのが得意です。

逆に、要件が曖昧だったりドメインルールが複雑だったり、正解の出力をすぐに検証できない場合は信頼性が落ちます。ライブラリをでっち上げたり、存在しない設定オプションを発明したり、ある状況では動くがエッジケースで失敗するコードを出すことがあります。

プラットフォーム（単なるコードアシスタントではなく）を評価するなら、「仕様をテスト可能なアプリに変え、安全に反復できるか」を重視してください。たとえばチャットから動くWeb/サーバー/モバイルアプリを作るように設計されたプラットフォーム（例：Koder.aiのようなvibe-coding）は、成果をすぐに検証でき、スナップショット／ロールバックやソースコードのエクスポートのような機能で高速な反復を可能にします。

プロダクトの種類が言語より重要な理由

正しいプロダクトを選ぶかどうかは、主に「成果をどれだけ簡単に検証できるか」に依存します。JavaScriptでもPythonでもなく、次の条件を満たすかがポイントです：

• 明確な入力と期待される出力がある、
• 迅速なフィードバックサイクル（数分単位）で検証できる、
• 誤りがあっても影響が小さい、

これらが満たされればAI支援のコーディングは強力に適合します。

一方、正しさを判断するのに深い専門知識が必要な（法的解釈、医療判断、金融コンプライアンス）もの、あるいは失敗のコストが高いものは、AI生成コードの検証と修正にかかる時間の方が節約より大きくなることが多いです。

すばやく判断する簡単な方法

作る前に「完了」を観察可能な形で定義してください：存在すべき画面、ユーザーが取れるアクション、測定可能な結果（例：「CSVをインポートしてこのサンプルファイルと一致する合計を表示する」）。具体的な受け入れ基準があるプロダクトは、AIで安全に作りやすいです。

この記事の最後には、数分で判断できる実用的なチェックリストを載せています。境界上の案件にはどんなガードレールを追加すべきかも示します。

期待値の設定：AIは加速するが品質は人間が担う

優れたツールがあっても、人間によるレビューとテストは必須です。コードレビュー、基本的なセキュリティチェック、重要な部分の自動テストを計画してください。AIは草案を素早く作る協力者と考え、責任、検証、リリース運用の置き換えにはしないでください。

AIコーディングツールが得意なこと（と苦手なこと）

AIコーディングツールは、やりたいことが明確でそれをはっきり説明できる場合に強みを発揮します。非常に高速なアシスタントとして扱い、コードの草案、パターン提案、面倒な箇所の埋めを任せられますが、あなたの実際のプロダクト制約を自動的に理解するわけではありません。

得意な領域

既知の作業を加速するのが得意です：

• スピードとスキャフォールディング： プロジェクト骨格の生成、ルート設定、モデル、基本UIコンポーネント、一般的なライブラリの配線。
• ボイラープレートと繰り返し作業： CRUD画面、フォームバリデーションの基本、APIクライアント、管理ページ、テストスタブ、ドキュメント草案。
• リファクタとクリーンアップ： 名前変更、コンポーネント／関数抽出、コードの重複検出。
• 既存コードの説明： 見慣れないモジュールの理解支援で安全に変更できるようにする。

うまく使えば、MVPや社内ツールのセットアップを数日→数時間に圧縮できます。

苦手な領域

問題が未定義だったり細部が重要な場合に破綻しがちです：

• 不明瞭な要件： 目標が曖昧だと、もっともらしいが間違った問題を解くコードになる。\n- エッジケースと実データ： 異常入力、ユーザーの雑な振る舞い、並行処理、リトライ、タイムゾーン、パフォーマンス問題。\n- セキュリティに関わる詳細： 認証フロー、権限、シークレットの扱い、安全なデフォルト（重要なチェックを省くことがある）。\n- 統合のクセ： サードパーティAPIの変な制限、不整合なペイロード、壊れやすいWebhook。

「ハッピーパス」と現実の使用

AI生成コードはしばしばハッピーパスを優先します：すべてが成功し、ユーザーが予測通り動く理想的なシーケンス。実際のプロダクトは失敗や例外が多く、支払い失敗、部分的な障害、重複リクエスト、ユーザーの二度押しなどが日常です。

出力に追加検証が必要な場面

AIの出力は草案として扱い、次で検証してください：

• 明確な受け入れ基準と例、
• エッジケースをカバーするユニット／統合テスト、
• セキュリティとエラー処理の手動レビュー、
• 実データに近い小規模な本番試験。

バグのコストが高いほど、人間のレビューと自動テストに頼るべきです。単なる高速生成だけに依存してはいけません。

作るに値する：MVPとクリック可能なプロトタイプ

MVP（Minimum Viable Product）と「クリックできて動く」プロトタイプはAIコーディングツールにとって理想的です。成功は学習の速さで測られ、完璧さではありません。狙いは狭いスコープで素早く出し、実ユーザーの反応で問いに答えることです（誰か使うか？ 支払うか？ このワークフローで時間が節約できるか？）。

AI支援でのMVPの理想像

実用的なMVPは学習時間が短いプロジェクトです：数日〜数週間で作り、フィードバックで磨くもの。AIツールは機能的なベースライン（ルーティング、フォーム、単純なCRUD、基本認証）に素早く到達させてくれます。

最初のバージョンは1～2のコアフローに絞ってください。例：

• 閲覧 → リクエスト／購入
• 作成 → 共有
• ログイン → タスク完了 → 結果表示

各フローに測定可能な成果を定義しましょう（例：「ユーザーがアカウントを作成して予約を2分以内に完了できる」）。

MVP向けのプロダクト例

AI支援のMVPに向く例：

• シンプルなマーケットプレイス： 投稿ディレクトリ、基本検索／フィルタ、販売者に連絡するフローや見積もりリクエスト。
• 予約プロトタイプ： 特定サービス向けのスケジューリング（空き状況、確認メール、管理ビュー）。
• ニッチなユーティリティ： 電卓、オンボーディングチェックリスト、用途特化の軽量CRM、小規模カテゴリ向け在庫管理。

重要なのは機能の幅ではなく、最初の利用ケースが明確であることです。

変更を前提に設計する（必ず変わります）

MVPはピボットする前提で作ってください。変更コストを下げる方法：

• ロジックをあちこちにハードコードせず設定（ルールテーブルなど）を使う
• データモデルは最小限、使用実績が出てからフィールドを追加する
• 置き換え可能なパーツ（今は簡易メールプロバイダ、後で差し替え可能）

有用なパターンは：まずハッピーパスを出し、軽い分析を入れ、ユーザーが詰まる箇所だけ広げること。AIツールは一度に全部作るよりも、素早い反復でこそ力を発揮します。

作るに値する：小さなチーム向けの社内ツール

社内ツールはAI支援の最も安全で高レバレッジな用途の一つです。利用者が特定され、コントロールされた環境で使われ、ちょっとした不完全さのコストが通常は低いため、迅速に修正・デプロイできます。

優れた社内ツールの例

次のようなプロジェクトは要件が明確で繰り返し画面が多く、AIのスキャフォールディングと反復に向いています：

• レコード管理用の管理パネル（顧客、ベンダー、資産）
• 在庫トラッカー（入出庫、ロケーション、発注ノート）
• リクエスト受付フォーム（ITヘルプ、購買申請、コンテンツ承認）
• シンプルなスケジューリング（オンコール、会議室予約）

なぜ適しているか

小さなチーム向けの社内ツールは：

• ユーザーとワークフローが既知：実際に使う人にインタビューできる
• 権限が管理しやすい：公開アプリよりエッジケースが少ない
• フィードバックが速い：同日にテスト→修正が可能

ここでAIはCRUD画面、フォームバリデーション、基本UI、データベース接続の生成を肩代わりし、あなたはワークフローと使い勝手に集中できます。

Koder.aiのようなエンドツーエンドのプラットフォームは、ReactベースのWebアプリとGo＋PostgreSQLのバックエンド、デプロイ／ホスティング、カスタムドメインといった部分を最適化しており、社内ツールの迅速構築に向くことが多いです。

省いてはいけない必須項目

社内だからと言って標準を省かないでください。必須の項目：

• 認証（可能ならSSO、さもなければメール/パスワード＋MFA）
• ロールと権限（少なくともadminとmember）
• 重要操作の監査ログ（編集、承認、削除など）
• バックアップと復旧（DBバックアップ、エクスポート機能）

まずは1つのワークフローから始める

1つのチームの1つの煩わしいプロセスを端から端まで解決してください。安定して信頼されるようになったら、同じ基盤（ユーザー、ロール、ログ記録）を次のワークフローに拡張する方が再利用性が高いです。

作るに値する：ダッシュボードとレポーティングアプリ

ダッシュボードやレポート系は、データを集めて見やすく提示し時間を節約することが主な目的なのでAI支援に向きます。問題が起きたときの影響が「判断が1日遅れる」程度で済むことが多く、リスクが相対的に低いからです。

適した具体例

スプレッドシートの手作業を置き換えるレポートから始めましょう：

• セールス／マーケ／サポート向けKPIダッシュボード（パイプライン状況、コンバージョン率、チケット残件）
• 週次レポートの自動生成（チャート＋短いナラティブ）
• データ探索ツール（「プラン別解約率を見せて」「地域と日付でフィルタ」）

リスクを減らすためにまずは読み取り専用で

推奨ルール：まずは読み取り専用で公開すること。承認済みソースからクエリして可視化するだけにして、レコードの編集やアクションのトリガーは信頼できるまで避けます。読み取り専用は検証が容易で、安全に幅広く展開できます。

事前に定義すべきこと

AIはUIやクエリの配管を生成できますが、次を明確にする必要があります：

• データ定義： "アクティブユーザー" や "有望リード" が何を意味するか
• 更新頻度：リアルタイム、毎時、毎日など。更新失敗時の挙動も決める
• アクセス制御：誰が何を見られるか（チーム、地域、顧客セグメント）やデータマスキングの要否

見た目は正しそうでも間違った問いに答えているダッシュボードは有害です。

指標のドリフトとソース不整合に注意

指標は気づかないうちに変化し、ダッシュボードが古いロジックを表示し続けることがあります（メトリックドリフト）。また、データソースがずれていると財務データとCRMの数字が一致しないことがあるため、UIに出典を明示し「最終更新」タイムスタンプと簡単な指標定義の変更履歴を載せておきましょう。

作るに値する：統合とワークフロー自動化

統合はグルーコードが主体なのでAI支援に向いています。入力と出力が明確で、予測可能なアクションをトリガーし、エラー処理を適切に扱えば、動作を記述してテストするのが容易です。

初めに取り組む良い例

入力がはっきりして分岐が少ないワークフローを選んでください：

• CRM→メール同期（新規リード→メーリングリスト追加、タグ付け、確認）
• Slack通知（支払い失敗、高額サインアップ、インシデント通知）
• 請求書エクスポート（会計システム→CSV/JSONをS3へ、週次サマリメール）
• Webhook処理（イベント受信→検証→変換→他APIへ転送）

契約をきちんと記述（"Xが起きたらYをする"）して、テストフィクスチャと実サンプルで検証すればAIは力を発揮します。

「一度動いた」だけではダメ：信頼性を設計する

多くの自動化バグはリトライ、部分失敗、重複イベントで露呈します。初期から次を入れておきましょう：

• キュー（非同期処理用）
• バックオフ付きリトライ（タイムアウトやレート制限に対応）
• 冪等性（同じイベントを再処理しても重複作成しない仕組み）

AIが最初の通りを素早く作っても、空フィールド、予期しない型、ページネーション、レート制限といったエッジケースに時間を割くと価値が上がります。

障害を明示する監視を付ける

自動化は黙って失敗します。最低限：

• 相関ID付きの構造化ログ
• エラー率上昇やキュー滞留時のアラート
• スタックされたジョブ、最終成功時刻、主要エラー原因を示す失敗ダッシュボード

非エンジニアが復旧できるように「失敗ジョブを再実行する」ボタンを付けると便利です。

作るに値する：ガードレール付きのコンテンツ／ナレッジツール

ドキュメントや知識を見つけて再利用することが目的のコンテンツ系ツールはAI支援に向きます。価値は即時で、成功は「時間短縮」「繰り返し質問の減少」「セルフサーブ率の向上」といったシンプルな指標で測れます。

作るべきもの（実用例）

自分たちのドキュメントやワークフローに基づくと効果的です：

• ドキュメント、チケット、ウィキ、ポリシー横断の内部検索
• ナレッジベースの自動タグ付け／カテゴリ分け
• 長文ドキュメントや会議メモ、サポートスレッドの要約
• 「当社のXポリシーは？」「Yはどうやる？」に答えるドキュメントQ&A

まずは検索（取得）を優先し、その後生成へ

安全で有用なパターンは「retrieve first, generate second」です。まず関連するソースを検索して取得し、AIはそのソースに基づいて要約や回答を作ります。

こうすると出力が根拠に基づき、幻覚（hallucination）を減らし、どのドキュメントを使ったかの追跡も容易になります。

信頼性を保つガードレール

MVPでも早めに軽い保護を入れてください：

• 使用したドキュメントへの引用／リンク
• 重要出力（方針、法務、対外向け）は人間レビュー
• フィードバックボタン（「役に立った／役に立たない」「誤り報告」）でプロンプト改善

コスト管理を最初から計画する

ナレッジツールは急速に利用されコストが膨らみます。対策：

• 繰り返しの質問に対するレスポンスキャッシュ
• ユーザー／チームごとのレート制限
• 明確な使用上限と代替（「後で再試行」や「検索結果のみ」）

これらでユーザーが頼れるツールを作りつつ、AIが常に正しいと錯覚させないようにできます。

避けるべき：安全性・生命に関わるシステム

AIコーディングツールはスキャフォールディングやボイラープレートを速く作れますが、少しのミスが人に直接害を及ぼすソフトウェアには向きません。安全クリティカルな領域では「ほとんど正しい」では許容されず、エッジケースやタイミング、誤解された要件が実害につながります。

なぜ特に危険なのか

安全・生命に関わるシステムは厳格な基準、詳細なドキュメント、法的責任が伴います。見た目にはきれいな生成コードでも、すべての条件下で正しく振る舞うことを証明する必要があります。AIは隠れた前提（単位、閾値、エラー処理）を導入することがあり、見落としやすいです。

避けるべき例

よく「便利そう」に見えるがリスクが高いもの：

• 症状を解釈して治療を勧める医療アドバイスツール
• 投薬量計算（薬剤、インスリン、小児投与など）— 四捨五入や単位変換の誤りが危険
• 産業用安全制御（非常停止論理、インターロック、アラーム、圧力・温度制御）
• 患者のトリアージや優先度を自動決定するもの（十分な安全策なし）

それでも取り組むなら

もし本当に安全クリティカルに触れる必要があるなら、AIは執筆者ではなく補助として使ってください。最低限の期待：

• ドメイン専門家（臨床、産業安全、人間工学）をチームに入れる
• 形式化された要件、テストトレーサビリティ、独立した検証・妥当性確認
• セキュリティレビュー、信頼性工学、監査対応のドキュメント
• 保守的なフェイルセーフと明確な人間による介入経路

このレベルの厳格さを用意できないなら、リスクを生産しているだけです。

助けになる代替案

生命に関わる決定を自動化する代わりに、次のような価値提供は可能です：

• 非臨床として明示した教育・トレーニングアプリ（説明やシナリオ練習）
• 専門家がレビューするための手順や保守ログの要約支援
• 情報収集と人間へルーティングするトリアージ「インテーク」ツール（推奨やスコアリングなし）

境界が不明な場合は /blog/a-practical-decision-checklist-before-you-start-building のチェックリストを使い、自動化よりもレビューしやすい支援を優先してください。

避けるべき：規制の厳しい金融やコンプライアンス重視のワークフロー

規制の厳しい金融領域はAI支援で静かに不利になることがあります：アプリは「動いている」ように見えても、見落とした要件で不備が出るとコストが大きい（チャージバック、罰金、アカウント凍結、法的責任）。

どんなものが該当するか

一見「ただのフォームとDB」に見えるものでも、アイデンティティや監査性、データ扱いに厳しいルールがあるもの：

• 決済処理フロー（カード情報の取り扱い、返金、紛争）
• KYC/AMLのオンボーディングとモニタリング
• 税務申告・報告
• 給与計算、給与明細、送金処理

なぜAI生成コードは危険か

AIツールはもっともらしい実装を出すが、監査や規制が求めるコントロールを見落とすことがあります。典型的な失敗：

• 微妙なコンプライアンス違反：同意文言の不足、監査証跡の欠落、誤った報告ロジック
• セキュリティの穴：安全でないトークン処理、脆弱なアクセス制御、ログに機密情報が残る
• データ保持／削除ミス：規定より長くドキュメントを保存、削除を証明できない
• ベンダーや法域ごとのルール：国や決済事業者、業種によって要件が異なる

これらは通常のテストでは見つからず、監査や事故で発覚します。

どうしても作るなら

金融機能が不可避な場合はカスタムコードの範囲を狭める：

• 決済、本人確認、税、給与は認証済みプロバイダを使い、そのサポートされたAPIを統合する
• カスタムロジックはオーケストレーション（ルーティング、UI、状態管理）に留め、コアなコンプライアンス判断は自前で実装しない
• AIの出力は草案扱いにして専門家レビュー、明示的な脅威モデル、負テストや監査ログチェックを含むテスト証拠を用意する

新しい金融ロジックやコンプライアンス解釈が価値の核心でない限り、AIでの実装はドメイン専門知識と検証計画が整うまで延期すべきです。

避けるべき：セキュリティクリティカルなコンポーネントと暗号

セキュリティ関連のコードはAIツールが最も害を及ぼしやすい分野です。理由は「ハードニング」「エッジケース」「脅威モデリング」「安全な運用デフォルト」といった地味だが重要な部分を見落としがちだからです。生成物はハッピーパステストでは正しく見えても、実際の攻撃で破られることがあります（タイミング差、リプレイ、乱数問題、危険なデシリアライズ、権限回避など）。

AIに任せてはいけないもの

主要な部分をAI生成コードに頼るのは避けてください：

• 暗号プリミティブやプロトコルの実装（暗号モード、署名、鍵交換、カスタムJWTの実装）
• 認証・認可の基盤（トークン検証、セッション管理、マルチテナントのアクセス制御）
• セキュリティエージェントやネットワーク強制（VPNクライアント、エンドポイントエージェント、パケットフィルタ）
• 鍵管理に関わるもの（鍵のローテーションロジック、安全な保存形式、カスタムKMSラッパー）

小さな変更がセキュリティ前提を壊すことがよくあります。

実績あるプロバイダとライブラリを使う

必要なセキュリティ機能は自前で作らず、確立されたソリューションを統合してください：

• 認証プロバイダ（OIDC/SAMLをエンタープライズ対応ベンダー経由）を使う
• よく保守された暗号ライブラリを使い、公式のレシピに従う。AIに「AES-GCMを実装して」と頼まないでください
• 標準パターンに従う：短寿命トークン、リフレッシュトークンの回転、サーバー側セッション無効化、中央での認可実施

AIは統合用のグルーコード、設定スキャフォールディング、テストスタブの生成では役立ちますが、セキュリティ設計者の代わりにはなりません。

簡単なアプリでも強制すべきセキュアなデフォルト

セキュリティ失敗は珍しい攻撃よりデフォルト設定のまずさから来ます。初日から次を強制してください：

• シークレット管理：APIキーをハードコードしない。環境変数かシークレットマネージャを使い定期ローテーション。\n- 最小権限：狭いIAMロール、スコープされたトークン、最小限のDB権限。\n- ログと監査：認証イベント、権限チェック、管理操作の記録（シークレットはログに出さない）。\n- 依存関係の衛生管理：バージョン固定、脆弱性アドバイザリの監視、無レビューのスニペットのコピペを避ける。

もし機能の価値が「我々は安全にXを扱える」なら、その機能はセキュリティの専門家、形式的なレビュー、慎重な検証を必要とします。AI生成コードを基盤にしてはなりません。

実用的な判断チェックリスト：始める前に

AIツールに画面やルート、DBテーブルの生成を頼む前に、15分ほど使ってプロジェクトが適切か、成功が何かを決めてください。この一手間で数日の手戻りを防げます。

簡単なスコアリングモデル（速く正直で有用）

各項目を1（弱い）〜5（強い）で評価してください。合計がだいたい14未満なら、アイデアを縮小するか延期を検討してください。

• 明確さ：ユーザー、問題、ワークフローを5〜7文で説明できるか？ハッピーパスはわかっているか？
• リスク：アプリが間違ったときの最悪の結果は？（金銭、生命、プライバシー、評判）。リスクが低いほど高得点。
• テスト可能性：例や期待出力、自動テストで検証できるか？「目視だけ」で全部確認しなければならないなら低評価。
• スコープ：1人で1〜2週間で有用なバージョンを出せるか？出せないならスコープを削る。

構築準備チェックリスト

以下を事前仕様として用意してください。半ページでも十分です。

• 要件：主要画面／アクション、ユーザーロール、エッジケース（無効入力、空状態、タイムアウト）
• データアクセス：データの所在、オーナー、認証方法。まだアクセスできないなら一時停止。
• エラー処理：障害時にユーザーにどう見せるか、セーフデフォルト（例：「変更は保存されていません」）
• 観測性：基本的なログ、メトリクス、アラート。何を追うか（1日あたりのエラー数、レイテンシ、失敗ジョブ数）を決める

「Done（完了）」を定義する（プロトタイプを放置しない）

プロジェクトは次を満たしたら「完了」とします：

• テスト：主要フローのスモークテストと1〜2の重要なエッジケースのテスト
• ドキュメント：短いREADME（実行方法、主要設定、デプロイ方法）
• ロールバック計画：リリースをどう戻すか、機能を無効にする方法
• オーナーシップ：修正・更新・ユーザーフィードバックの責任者を1名決める

エンドツーエンドビルダー（例：Koder.ai）を使うなら、これらを明示にしてください：プランニングモードで受け入れ基準を書く、スナップショット／ロールバックを活用して安全なリリースを行い、プロトタイプが本製品になるときはソースコードをエクスポートすること。

テンプレート、助け、または一時停止？

プロダクトが一般的なパターン（CRUD、ダッシュボード、Webhook統合）に合致するならテンプレートを使ってください。セキュリティ、データモデリング、スケーリングの判断が高コストで取り返しがつかないなら外部の助けを雇うべきです。要件が不明瞭、データに対する法的アクセスがない、正確性をどうテストするか説明できないなら一時停止してください。