Kimiバイブコーディングチュートリアル：コードを書かずにプロダクトを構築するのは簡単になったが、リリースはそうではない

Kimiは、かつて技術的だったワークフローを対話型のものへと変えましたが、この変化は、迅速な構築と責任あるリリースの間に新たな対立を生み出しています。このKimiバイブコーディングチュートリアルでは、最初の仕様策定から一般公開まで、プロダクト開発の全工程を通じてその対立を検証します。

重要な変化は、AIモデルがランディングページを生成できるようになったことではありません。コーディングエージェントは現在、プロジェクトファイルを調査し、複数のコンポーネントを編集し、コマンドを実行し、テストを行い、失敗後に計画を調整できます。Kimi Code、Qwen Code、GLMベースのコーディングサービスは、そのワークフローをターミナルや開発環境内に組み込んでいます。

これにより、初めてプロダクトを構築する人は珍しい立場に置かれます。基盤となるシステムを理解する前に、より多くのソフトウェアを作れるからです。しかし、ホスティング、認証、データベース、セキュリティ、ドメイン設定、規制上の義務は、依然としてエンジニアリング上の問題であり続けます。

Andrej Karpathyは2025年2月、この実践に印象的な名前を付けました。彼の説明では、生成された変更を受け入れ、コードが存在することを一時的に忘れる姿勢が強調されていました。この姿勢は週末の実験的なプロジェクトでは機能しましたが、一般公開するプロダクトには別の基準が求められます。

有用な問いは、コーディング経験のない人がアプリケーションを構築できるかどうかではなくなりました。それは可能です。より難しい問いは、エージェントがアプリケーションを作成した後、その人がアプリケーションを理解し、テストし、運用し、復旧できるかどうかです。

Kimiコーディングエージェントはコード生成以上のことを担うようになった

チャットアシスタントからコーディングエージェントへの移行により、ソフトウェアプロジェクトを始められる人の範囲は広がりますが、構築者の責任がなくなるわけではありません。

チャットモデルは通常、テキストや個別のコードサンプルを返します。コーディングエージェントはプロジェクト内で作業し、その構造を調査し、ファイルを変更し、コマンドを実行して、その出力を確認できます。このフィードバックループにより、システムは最初の回答後も作業を続けられます。

この違いは、技術的な知識を持たない構築者にとって重要です。ブラウザとエディタの間でコードをコピーするには、各断片をどこに配置すべきかを知る必要があります。エージェントは関連ファイルを特定し、インターフェース、サーバー、データベース、設定にまたがる変更を連携させることができます。

Kimiは、同社のコマンドラインクライアントを、コードの読み取りと変更、ファイル検索、シェルコマンドの実行、フィードバックに基づく計画の修正が可能なエージェントとして説明しています。現在のKimi Codeガイドでは、プロジェクトをスキャンした後にクライアントがAGENTS.mdファイルを生成する仕組みも説明されています。

このファイルは、エージェントの運用コンテキストとして機能します。プロジェクト構造、ビルドコマンド、規約、タスク間で維持すべきその他の指示を記録できます。これにより、エージェントはすべてのプロンプトを個別の依頼として扱うのではなく、プロジェクト全体の地図を得られます。

Qwen Codeも同様のモデルを採用しています。そのエージェント概要では、プロダクトに関する指示をコードに変換し、スクリプト化された非対話型の利用にも対応するターミナルツールとして説明されています。また、複数の認証方法やモデルプロバイダーを通じて接続することもできます。

これらのプロダクトは、ソフトウェア開発のインターフェースにおける、より大きな変化を示しています。ユーザーは動作、制約、受け入れ基準を記述し、エージェントはその意図をファイル、コマンド、テストへと変換します。

しかし、自然言語は完全な仕様ではありません。「顧客ポータルを構築する」といった依頼では、重要な疑問が未解決のままです。アカウント復旧、アクセス権限、データ保持、決済失敗、監査ログ、不正利用防止については何も述べられていません。

経験豊富なエンジニアは、これらが過去の障害と似ているため、不足に気づきます。初心者は目に見えるインターフェースを見て、システムがほぼ完成していると思いがちです。コーディングエージェントは実装時間を短縮しますが、洗練された画面の裏に未完了の意思決定を隠してしまうこともあります。

AIHOTを情報源とする中国語ガイドは、この新しいワークフローをうまく捉えています。Kimi、GLM、Qwenを含む中国製モデルを、アイデアからオンラインプロダクトへ到達するための利用しやすい手段として紹介しています。最も重要な助言は終盤にあります。構築者はコードを書くことを避けられても、アーキテクチャを理解することは避けられません。

この違いこそ、本格的なKimiバイブコーディングチュートリアルの土台となるべきです。エージェントはタスクを実行できますが、システムを定義し、それが機能するかを判断する責任は人間に残ります。

最初のプロンプトより先にプロダクト仕様を作成する必要がある

曖昧なアイデアからは説得力のあるデモが生まれますが、範囲を明確にした仕様があってこそ、エージェントは運用可能なプロダクトを作成できる可能性を得ます。

最初の成果物はコードであるべきではありません。ユーザー、目的、データ、権限、障害状態、成功基準を網羅した短いプロダクト仕様書であるべきです。この文書は、エージェントが推測を始めたときの基準になります。

まず、1人のユーザーと1つの目的から始めます。「フリーランサーは会議メモを顧客へのフォローアップに変換する必要がある」という記述は、「AI生産性プラットフォームを構築する」よりも実行可能です。範囲の狭い記述によって、入力、変換、出力が明確になります。

次に、最小限で完結する一連の流れを定義します。ユーザーがアカウントを作成し、メモをインポートし、生成されたフォローアップを確認して編集し、結果をエクスポートします。各ステップには、ユーザーに何が表示されるか、操作が失敗した場合に何が起こるかを含める必要があります。

データには専用のセクションが必要です。アプリケーションが保存するすべての情報の種類、その取得元、閲覧できる人、削除すべき時期を一覧にします。機密文書には、公開カタログデータとは異なる保護措置が必要です。

権限も明確な言葉で定義する必要があります。管理者、一般ユーザー、匿名の訪問者が同じ操作権限を共有すべきではありません。プロダクトがチーム機能に対応する場合は、メンバー同士が互いの記録を閲覧できるか、誰がアクセス権を削除できるかを指定します。

次に、システムを複数のコンポーネントとして定義します：

• インターフェースは、画面、フォーム、ナビゲーション、フィードバックを表示します。

• アプリケーションサービスは、ビジネスルールを適用し、リクエストを調整します。

• データベースは、ユーザー、記録、権限、状態を保存します。

• 認証は、本人確認を行い、セッションを制御します。

• 外部サービスは、メール、決済、AI推論、ファイルストレージを提供します。

• ホスティングは、アプリケーションを利用可能にし、ログ、ネットワーク、バックアップを提供します。

初心者が開始前にすべての実装詳細を知る必要はありません。しかし、これらのコンポーネントを認識し、それぞれの責任がどこにあるのかを確認する必要はあります。そうしなければ、エージェントが無関係な関心事を密かに組み合わせ、壊れやすいコードを作ってしまう可能性があります。

この段階では、プランモードが役立ちます。エージェントにすぐ構築を依頼するのではなく、仕様を確認し、不足している意思決定を特定し、アーキテクチャを提案し、作業をマイルストーンに分割するよう依頼します。

エージェントの計画では、主要なデータエンティティ、ルート、依存関係、テスト戦略を明示する必要があります。また、前提条件も記載すべきです。隠れた前提条件は、複数の機能がそれに依存するようになると、修正コストが高くなります。

エージェントに、コードを使わずにアーキテクチャを説明するよう求めます。説明が依然として分かりにくい場合、そのプロダクトは自律的な実装に進む準備ができていません。リクエストの流れを平易な言葉で説明できるようになるまで、計画を練り直してください。

有用なプロンプトは、意欲ではなく証拠を定義します。「ログインを追加する」だけでは不十分です。「メールログインを追加し、期限切れのセッションを拒否し、ユーザーが別のアカウントの記録へアクセスできないようにし、これらのケースに対するテストを書く」と指定すれば、観察可能な要件になります。

同じ規律はインターフェース作業にも当てはまります。空の状態、読み込み中の状態、検証エラー、小さい画面、キーボードナビゲーション、破壊的な操作について記述します。理想的なデータしか扱えない生成済みダッシュボードは、依然としてモックアップにすぎません。

構築者は、要件、参照メモ、モデルに関する意思決定、テスト時の観察事項を、検索可能なAIワークフロー内に保存できます。このコンテキストは、以前のアーキテクチャ上の選択がなぜ行われたのかをエージェントが尋ねる際に役立ちます。

仕様は開発中に変化します。それは正常です。重要なルールは、エージェントに新しい方針の実装を依頼する前に、元の文書を更新することです。

計画から動作するビルドまでのKimiバイブコーディングチュートリアル

最も安全なエージェント型ワークフローでは、アプリケーション全体を1つのプロンプトで依頼するのではなく、小さく検証可能なマイルストーンを使用します。

大規模な実装を始める前に、バージョン管理されたリポジトリ内にプロジェクトを作成します。バージョン管理は変更をコミットとして記録するため、構築者はリビジョンを比較し、以前の状態へ復旧できます。最初のコミットには、仕様と最小限のプロジェクトのひな型を含める必要があります。

運用のシンプルさを基準に技術スタックを提案するよう、エージェントに依頼します。回答では、各コンポーネントが存在する理由、デプロイ方法、採用しなかった代替案を説明する必要があります。モデルが最初に生成したという理由だけでフレームワークを選ばないでください。

最初のマイルストーンでは、アプリケーションのひな型を確立します。これには、開発コマンド、環境設定、基本的なナビゲーション、ヘルスチェック、テストコマンドが含まれます。別のクリーンな環境でそのひな型を実行できるようになるまで、ビジネス機能の開発に進むべきではありません。

2番目のマイルストーンでは、コアデータモデルを実装します。マイグレーションを生成する前に、エンティティ、その関係、所有権のルールを示すようエージェントに依頼します。マイグレーションとは、環境間で一貫して適用できる、管理されたデータベース変更です。

スキーマを平易な言葉で確認します。どの記録がどのユーザーに属するのでしょうか。アカウントが削除されると何が起こるのでしょうか。2つの記録が、存在しないデータを誤って参照する可能性はあるでしょうか。これらの答えから、基盤となるモデルがプロダクトと一致しているかが分かります。

3番目のマイルストーンでは、認証と認可を追加します。認証はユーザーが誰であるかを確認します。認可は、そのユーザーが何を実行できるかを決定します。生成されたアプリケーションの多くは前者を実装する一方、後者をインターフェース上の問題として扱っています。

認可は、保護されたすべての操作についてサーバー側で適用しなければなりません。ボタンを非表示にすることはアクセス制御ではありません。悪意のあるユーザーや好奇心旺盛なユーザーは、想定されたインターフェースを使わずにリクエストを送信できます。

4番目のマイルストーンでは、完結した1つのプロダクト体験を実装します。コアとなる経路が機能する前に、設定ページ、分析パネル、視覚的な改良を追加しないでください。範囲の狭い垂直スライスにより、統合上の問題を早期に発見できます。

各タスクの後、エージェントに以下を要約させます：

• 変更したファイル

• 追加した動作

• 設定した前提条件

• 実行したテスト

• 依然として人間の判断が必要なテスト

• セキュリティまたはデプロイへの影響

各マイルストーンの後にアプリケーションを実行します。まず想定どおりの動作を試し、次に誤った使い方を試します。空のフォーム、過大な入力、重複リクエスト、期限切れのセッション、無効なURL、別のユーザーの記録識別子を送信してください。

問題が発生した場合は、エージェントに「すべて修正して」と依頼するのではなく、観察された動作を報告します。コマンド、期待した結果、実際の結果、関連するログ出力を含めます。正確なフィードバックは、モデルが不具合と誤解された要件を区別するのに役立ちます。

局所的なバグへの既定の対応として、大規模な書き換えを受け入れないでください。根本原因の説明と最小限のパッチを求めます。生成された大規模な変更はレビューが難しく、正常に動作していた機能を削除してしまう可能性があります。

検証済みの各マイルストーンの後にコミットします。会話の履歴ではなく、プロダクトの変更内容を示す説明を使用してください。整理された履歴があれば、エージェントが関連する複数のエラーを持ち込んだ際に、既知の状態へ戻ることができます。

コンテキストが煩雑になったら、新しいエージェントセッションを開始してください。新しいセッションには、仕様、アーキテクチャ、現在のマイルストーン、検証済みのリポジトリ状態を伝えます。会話が長くなると、プロダクトが変更された後も古い前提が残り続けることがあります。

この段階的なアプローチは、一度に生成する方法より遅く感じられます。実際には、完成度の高いアプリケーションがデプロイ時に破綻するという、コストのかかるサイクルを減らせます。目標は、プロンプトごとのコード出力量を最大化することではなく、変更ごとの検証済みの進捗を最大化することです。

デプロイによってデモは運用システムになる

本番公開には、インフラストラクチャ、アイデンティティ、規制、復旧に関する責任が加わりますが、コーディングエージェントがそれらを自ら担うことはできません。

ローカルアプリケーションは、好条件のもとで1台のマシン上で動作します。公開デプロイ環境には、予測不能なトラフィック、不正な形式のリクエスト、自動スキャン、実際のユーザーデータが流入します。この環境では、「動作する」という言葉の意味が変わります。

開発環境と本番環境を分離してください。開発環境は実験のための空間です。本番環境は、実際のユーザーが依存するシステムです。同じデータベース、認証情報、無制限の管理者アクセスを共有させてはいけません。

設定は環境変数またはマネージドシークレットサービスを通じて保存してください。データベースのパスワード、APIキー、署名用シークレットをソースファイル内に置いてはいけません。公開前に、誤って含まれた認証情報がないかリポジトリ履歴をスキャンするようエージェントに依頼してください。

アプリケーションの構成要素に基づいてホスティングを選択してください。静的インターフェース、長時間稼働するサーバー、スケジュールジョブ、リレーショナルデータベースでは、それぞれ要件が異なります。デプロイ計画では、各コンポーネントがどのように起動し、通信し、エラーを記録し、再起動するのかを明確にする必要があります。

ドメインは、さらに別の層を追加します。DNSレコードはユーザーをホスティングサービスへ誘導し、TLSは接続を暗号化します。また、別形式のドメインをリダイレクトし、証明書を更新するための戦略もプロダクトに必要です。

中国本土内でホストされるプロダクトには、追加の届出義務が課される場合があります。中国で改正されたICP届出規則では、国内で提供される非営利のインターネット情報サービスは届出手続きを完了しなければならないと定められています。

この規則では、完全な申請について20営業日以内に届出の判断を下すことも定められています。これは規制上の上限であり、すべての公開準備が一定のスケジュールで完了するという保証ではありません。開発者は、届出を早期に着手すべき作業として扱う必要があります。

具体的な義務は、サービス、ホスティング形態、ビジネスモデル、管轄区域によって異なります。コーディングエージェントは要件を整理できますが、法的に権威ある承認を与えることはできません。適用範囲が不明確な場合は、関連するプロバイダーや有資格の法律専門家に相談してください。

デプロイには、データベース移行の制御も必要です。破壊的な変更を適用する前に、本番データをバックアップしてください。代表的なデータを使って移行をテストし、元に戻す方法を文書化してください。

ビルドの成功、自動テスト、セキュリティチェック、移行、設定、監視、ロールバックを網羅するリリースチェックリストを作成してください。各項目では、エージェントによる口頭の保証ではなく、証拠を提示する必要があります。

ログからは、何が、いつ失敗し、どの操作が影響を受けたのかを把握できる必要があります。パスワード、トークン、非公開文書、不要な個人情報を露出させてはいけません。より多くのデータを記録すれば自動的に安全になるわけではありません。

監視では、基本的な可用性、サーバーエラー、レイテンシ、失敗したバックグラウンドジョブ、ストレージ上限を対象にする必要があります。アラートには、担当者と対応手順が必要です。誰も理解できない通知は、単なる余分なノイズです。

バックアップには復元テストが必要です。バックアップジョブの成功によって証明できるのは、データがどこかにコピーされたことだけです。許容可能な時間内にプロダクトを復旧できることまでは証明できません。

ユーザーを招待する前に、ロールバック手段を1つ用意してください。それは、以前のリリースを復元する、新機能を無効化する、移行を元に戻すといった方法かもしれません。想定される各障害にどの対応を適用するのかを、チームが把握しておく必要があります。

ここで「ノーコード」という表現が誤解を招くものになります。開発者自身は実装コードを入力しないかもしれませんが、それでも技術的・組織的責任を伴うシステムを運用することに変わりはありません。

AI生成コードにはブランチ保護と敵対的テストが必要

エージェントの自信は、プロダクトが安全、正確、または本番運用可能であることの証拠にはなりません。

2025年のStack Overflow開発者調査では、AIの出力をめぐる明確な信頼格差が明らかになりました。回答者の84パーセントがAIツールを使用している、または使用する予定である一方、46パーセントがその正確性を信頼していませんでした。信頼を示したのはわずか33パーセントでした。

同じ開発者調査では、66パーセントがほぼ正しいものの完全には正しくないAIの解決策に不満を感じていることも判明しました。また、45パーセントが、生成コードの時間のかかるデバッグを大きな不満として挙げました。

これらの数字は、コーディングエージェントに価値がないことを示すものではありません。導入の拡大に合わせて検証も強化しなければならない理由を示しています。変更がシステム内の不慣れな領域にまで広がる場合、生成速度の向上によってレビュー負担が増大することがあります。

初期プロジェクト設定後は、メインブランチを保護してください。GitHubのブランチ保護では、変更をマージする前に、プルリクエスト、ステータスチェックの通過、議論の解決、または承認レビューを必須にできます。

一人で開発する場合でも、この構造にはメリットがあります。エージェントは別のブランチで作業し、自動チェックが実行され、開発者がマージ前に概要を確認します。この一時停止によって、生成とリリースの間に境界が生まれます。

最低限、自動パイプラインではロックファイルから依存関係をインストールし、アプリケーションをビルドし、テストを実行し、セキュリティ指向のチェックを行う必要があります。失敗はログ内に埋もれた警告にするのではなく、マージを阻止する必要があります。

テストは複数のレベルで実施する必要があります：

• ユニットテストでは、独立したビジネスルールを確認します。

• 統合テストでは、データベースや外部サービスとの通信を確認します。

• エンドツーエンドテストでは、完全なユーザージャーニーを検証します。

• 認可テストでは、あるアカウントが別のアカウントのデータにアクセスできないことを確認します。

• 移行テストでは、スキーマ変更によって既存レコードが保持されることを確認します。

• 手動テストでは、使いやすさ、曖昧な出力、予期しない動作を検証します。

確認済みの不具合を修正する前に、テストを書くようエージェントに依頼してください。失敗するテストによって問題が記録され、再発する可能性が低減します。その後、パッチ適用後に同じテストが成功することを必須にしてください。

セキュリティには、独立した脅威モデリングの工程が必要です。脅威モデルでは、価値のある資産、想定される攻撃者、露出しているエントリーポイント、起こり得る悪用を特定します。これにより、「安全にする」という曖昧な指示が、具体的な一連の問いへと変わります。

ユーザーがリクエスト内の識別子を変更した場合、何が起こるでしょうか？アップロードされたコンテンツはコードを実行できるでしょうか？外部URLはサーバーによって取得されるでしょうか？パスワードの試行を制限なく繰り返せるでしょうか？管理用ルートでは、サーバー側でロールを確認しているでしょうか？

OWASPは、AIによって生成されたシステムや市民開発によるシステムが、脆弱なコンポーネントを再利用したり、存在しないパッケージを参照したりする可能性があると警告しています。信頼できないコンポーネントに関するガイダンスでは、生成された依存関係を検証が必要な項目として扱うことを推奨しています。

新しい依存関係をすべて調査してください。パッケージが実在し、想定される発行元から提供され、メンテナンスされており、必要な目的を果たすことを確認してください。もっともらしいパッケージ名は、正当性の証明にはなりません。

依存関係のロックファイルを使用し、不要なパッケージを避けてください。依存関係が少なければ、障害が発生したり、所有者が変わったり、脆弱性が持ち込まれたりする可能性のある外部コンポーネントの数を減らせます。

生成された認証コードは、特に慎重に精査する必要があります。パスワードの保存、セッション処理、リセットフロー、Cookie設定、認可チェックには、セキュリティ上重要な詳細が含まれます。独自ロジックよりも、確立され、文書化された実装を優先してください。

初期テストで実際の顧客データを使用してはいけません。個人情報を露出させずに必要な構造を再現した合成レコードを生成してください。プロジェクトを一人で運用している場合でも、本番環境へのアクセスを制限してください。

AI機能は、さらなるリスクを生みます。ユーザーコンテンツがモデルのプロンプトに入力される場合、そのコンテンツを信頼できないものとして扱ってください。指示の上書き、非公開コンテキストの漏えい、意図しないツールの起動を試みる可能性があります。

ファイルやコマンドへのアクセス権を持つエージェントは、ローカル環境でも大きな権限を持ちます。要求された操作を確認し、認証情報を制限し、通常の開発中は本番環境へのアクセスを付与しないでください。利便性を理由に、運用上の境界をなくしてはいけません。

技術者ではない創業者は、金銭、健康情報、機密文書、または機微な個人識別データを扱うプロダクトを公開する前に、独立したレビューを手配する必要があります。コードを生成したエージェントだけを、そのコードの唯一のレビュアーにしてはいけません。

公開後に開発者が注視すべきこと

バイブコーディングの決定的な試金石は、エージェントがバージョン1を公開できるかどうかではなく、人間がバージョン2を運用できるかどうかです。

最初の指標は、変更の信頼性です。依頼した機能がテストを通過し、本番環境に到達し、ロールバックされずに稼働し続ける頻度を追跡してください。頻繁な差し戻しは、アーキテクチャまたは検証プロセスがエージェントの速度に対応できていないことを示します。

2つ目の指標は、インシデントの責任者です。アラートが発生した際、開発者は影響を受けたコンポーネントを特定し、関連ログを調査し、障害の経路を説明できる必要があります。別のエージェントの応答に完全に依存していては、プロダクトに責任ある診断主体が存在しないことになります。

3つ目の指標は、モデルの可搬性です。Kimi、Qwen、GLM、その他のコーディングシステムでは、クライアント、モデル、認証方式、制限が今後も変化し続けます。明確な文書と標準的なツールを備えたリポジトリなら、エージェント間をより容易に移行できます。

モデルの可搬性は、すべてのエージェントが同一のコードを生成することを意味しません。別のツールやエンジニアが作業を継続できるほど、プロジェクトの要件、アーキテクチャ、コマンド、テストが明示されていることを意味します。

開発者は、目に見える出力と運用品質の隔たりにも注意する必要があります。新しいインターフェース画面は簡単にデモできます。エラー率の低下、より安全な移行、より迅速な復旧、より明確な権限は目立ちにくいものの、さらに重要です。

したがって、このKimiバイブコーディングチュートリアルは、異なる成功の定義で締めくくられます。成功とは、プログラミング言語に触れずに公開URLへ到達することではありません。その動作、データ、リスク、復旧手順を説明できる稼働中のシステムへ到達することです。

まず1つのユーザージャーニーから始め、コーディングエージェントを開く前に要件を記述してください。エージェントに計画を立てさせ、1つのマイルストーンを実装させ、テストによる証拠を提示させます。検証済みの変更だけをコミットし、その後、実際のユーザーを招待する前にデプロイと復旧の制御を構築してください。

アイデンティティがどこで確認され、データがどこに保存され、失敗したリリースをどのように元に戻すのかを説明できない場合は、公開を一時停止してください。答えが明確になるまで、それらのシステムを可視化するようエージェントに依頼してください。バイブコーディングは実装コストを削減できますが、プロダクトに対する説明責任をモデルへ移すことはできません。