Vibe Coding on KnightLiブログ

easy-vibe：Vibe Coding初心者のための学習マップ

Sat, 16 May 2026 22:44:43 +0800

easy-vibe は、Datawhaleが公開しているVibe Coding学習プロジェクトです。対象は、すでにAIコーディングツールを使いこなしている開発者ではありません。Vibe Codingに触れ始めたばかりの学生、プロダクトマネージャー、デザイナー、運用担当者、個人開発者、技術好きの一般ユーザーです。

このプロジェクトの価値は、また別のAIツール一覧を作っていることではありません。「AIでどうやってプロジェクトを作り始めるか」を、より理解しやすい学習パスに分解していることです。多くの初心者にとって本当に難しいのは、Claude Code、Cursor、MCP、Agentの存在を知らないことではありません。最初に何を学び、どう練習し、いつ高度なツールに進むべきかが分からないことです。

Vibe Coding初心者に最も足りないのは道筋

Vibe Codingはここ数年注目されていますが、初心者にとって親切とは言えません。

表面上は、要件を説明できればAIにコードを書かせられるように見えます。実際には、タスクが少し複雑になるだけで問題が出ます。要件が曖昧、モデルが違うファイルを編集する、プロジェクト構造が分からない、エラーを処理できない、依存関係が入らない、プロンプトがどんどん乱れる。最後には「コードをチャットボックスにコピーする」状態へ戻ってしまいます。

そのため、Vibe Coding入門は「プロンプトの書き方」だけでは足りません。少なくとも次のことを解決する必要があります。

アイデアを実行可能なタスクに分ける方法。
AIにプロジェクト構造を理解させる方法。
モデルが生成したコードを読む方法。
エラーを処理し、反復する方法。
ターミナルとローカル開発環境を使う方法。
Webチャットから実際のAIコーディングツールへ移行する方法。

easy-vibeの意味はここにあります。ツール、チュートリアル、用語の中で初心者を迷わせるのではなく、これらを1つの学習ルートとして整理しようとしています。

単発チュートリアルではなくロードマップ

プロジェクト説明を見ると、easy-vibeは基礎チュートリアル、インタラクティブ演習、可視化コンテンツ、RAG、ターミナルツール、AIコーディングツール、さらにClaude Code、MCP、Skills、Agent Teamsなどの発展トピックを扱っています。

この構成は初心者に向いています。AIコーディングは単一のスキルではなく、複数の能力の組み合わせだからです。

要件を説明する。
タスクを分ける。
プロジェクトを読む。
モデルにコードを編集させる。
実行し、検証する。
エラーに基づいて反復する。
よく使う流れをツールやスキルとして蓄積する。

特定のツールだけを学ぶと、そのツールの画面に縛られやすくなります。モデル、エディタ、CLIが変わると、また何をすればよいか分からなくなります。ロードマップの利点は、先に作業方法を身につけ、その後でツールを適切な場所に置けることです。

非プログラマーに特に役立つ

Vibe Codingの最大の魅力は、専門プログラマーでなくてもプロトタイプを作れることです。

プロダクトマネージャーは製品アイデアをインタラクティブなdemoにできます。デザイナーはインタラクションのロジックを検証できます。運用担当者は社内ツールを書けます。学生は授業プロジェクトを素早く作れます。起業家は初期段階で需要を検証できます。こうした人たちは、従来の意味でフルタイムエンジニアになる必要はないかもしれませんが、「AIに手伝わせてアイデアを形にする」方法を持つ必要があります。

これが、easy-vibeが中国語コミュニティに合っている理由でもあります。多くの中国語ユーザーは、AIがコードを書けることをすでに知っています。しかし、開発環境、プロンプト、プロジェクト構造、デバッグ方法、Agentツールの使い方を体系的に学べる入門資料はまだ不足しています。中国語で明確に説明され、演習と一緒に進められることには意味があります。

この種のユーザーにとって最も重要なのは、最初から複雑なフレームワークを学ぶことではありません。まず、要件を出す、プロジェクトを生成する、動かす、問題を見つける、修正を続ける、最終的に使えるものを得る、という一連のループを回すことです。

発展部分は実際のAI開発ワークフローに近づく

easy-vibeで触れられているClaude Code、MCP、Skills、Agent Teamsは、もはや単なる入門概念ではありません。

Claude Codeはターミナル型コーディングAgentを表します。モデルがローカルプロジェクトに入り、ファイルを読み、コードを変更し、コマンドを実行できます。MCPはツールとデータソースの接続を解決し、モデルをチャットボックス内に閉じ込めません。Skillsは、固定のプロジェクト生成、文書整理、テストチェック、コンテンツ制作などの再利用可能な流れを蓄積します。Agent Teamsはさらに、タスクを複数の智能体へ分割します。

これらは初心者には少し遠く感じるかもしれません。それでも早めに知っておく価値があります。Vibe Codingの方向性は明確だからです。「AIに一部のコードを書かせる」段階から、「AIに完全なプロジェクトフローへ参加させる」段階へ向かっています。

学習ルートがプロンプトだけで止まると、ツールの進化についていけません。一方で、最初からすべての高度な概念を初心者に投げると、どこから始めればよいか分からなくなります。easy-vibeの良さは、それらを段階的なアップグレードの道筋に置いていることです。

学習時に避けたい2つの誤解

1つ目は、Vibe Codingならコードが分からなくても完全にコードを気にしなくてよい、と思うことです。

AIは多くのものを生成できますが、ユーザーは結果が正しいか判断する必要があります。少なくとも、プロジェクト構造を理解し、どう実行するかを知り、エラーがどこで起きているかを大まかに把握する必要があります。複雑なコードを書かなくても、基本的なエンジニアリング常識は必要です。

2つ目は、高度なツールほど良いと思うことです。

初心者が最初からClaude Code、MCP、複数Agentを必要とするとは限りません。より良い順序は、まず簡単なプロジェクトでフィードバックループを作り、その後でターミナル、バージョン管理、テスト、ツール呼び出し、自動化フローを少しずつ導入することです。ツールはタスクの複雑さに合わせるべきです。そうでなければ「強そうだが何に使うか分からない」ものになります。

どう使うとよいか

Vibe Codingに触れ始めたばかりなら、easy-vibeを学習チェックリストとして使えます。

まず基礎概念と簡単な演習から始めます。すべてのツールを追う必要はありません。個人ホームページ、データダッシュボード、フォームツール、自動化スクリプト、知識ベースdemoなど、小さなプロジェクトを1つ作ります。その過程で、AIがどこで助けになるか、どこは自分で確認すべきかを観察します。

小さなプロジェクトを安定して完成できるようになったら、より複雑な内容に進みます。

ターミナルツールでローカルプロジェクトを扱う。
Gitで各変更を管理する。
RAGで自分の資料を接続する。
MCPで外部ツールを接続する。
Skillsで反復作業を固定化する。
Agent Teamsで複雑なタスクを分割する。

このように学ぶVibe Codingは、単にAIへ質問することではありません。AIを自分のワークフローに入れることです。

まとめ

easy-vibeは、Vibe Codingの中国語入門マップとして見るのがよいでしょう。散らばったAIコーディングの概念、ツール、演習を1つの道筋にまとめ、初心者が「AIはコードを書けるらしい」から「AIでプロジェクトを作れる」へ進みやすくしています。

Vibe Codingの本当の価値は、すべての学習を飛ばせることではありません。アイデアからプロトタイプまでのハードルを下げることです。要件を理解し、タスクを整理し、結果を検証し、リスクを制御する必要は残ります。ただし、多くの反復的で退屈で詰まりやすい手順は、AIに手伝わせることができます。

AIコーディングに体系的に入門したいが、最初からツール名や複雑な開発設定に埋もれたくないなら、easy-vibeは保存しておきたい出発点です。

API Key を GitHub に push しないために：AI コーディング時代のシークレット漏洩対策

Sat, 16 May 2026 16:26:50 +0800

AI によるコーディングは、ソフトウェアを作り始めるハードルを大きく下げました。一方で、これまで主に開発チーム内で起きていたセキュリティ問題が、初心者や非エンジニアにも直接降りかかるようになっています。

よくある事故は、API Key、Secret、Token、データベース接続文字列、.env 設定ファイルを公開リポジトリに push してしまうことです。ローカルでは「アプリを動かすための設定」に見えても、GitHub の公開リポジトリに入った瞬間、自動スキャン、自動呼び出し、自動悪用の対象になります。

シークレット漏洩は珍しい事故ではありません。GitGuardian の 2026 年レポートでは、2025 年の公開 GitHub コミットに約 2865 万件の新しいハードコードされた認証情報が含まれ、AI サービス関連の認証情報漏洩は前年比 81% 増加したとされています。これは単なる不注意ではなく、AI コーディング、素早いプロトタイピング、公開ホスティングが重なって規模を拡大している問題です。

初心者が Key を漏らしやすい理由

多くの AI Agent や小さなツールには、ローカルディスク上の「リポジトリ」と、GitHub 上で世界中から見える「リポジトリ」があります。初心者はこの境界を意識できないことがあります。

ローカル実行時には、config.json、.env、settings.yaml に API Key を入れていても、単なる開発用設定に見えます。しかし git add .、git commit、git push を実行すると、それらのファイルがそのままアップロードされる可能性があります。公開されたリポジトリでは、スキャンボットはビジネスロジックを理解する必要がありません。シークレットらしい形式を見つければ十分です。

AI コーディングはこの問題をさらに広げます。

AI が生成するサンプルコードに OPENAI_API_KEY = "sk-..." のような書き方が入ることがある。
初心者は「まず動かす」ために、フロントエンド、スクリプト、設定ファイルへ直接 Key を書きがち。
多くの vibe coding プラットフォームは、GitHub の Push Protection を通らずに直接デプロイできる。
ユーザーは AI が生成したプロジェクト内のファイル、API、既定権限を把握していないことがある。

AI は動くものを速く作る手助けをしますが、セキュリティ責任まで自動で引き受けてはくれません。

`.gitignore` は飾りではない

Git はバージョン管理を行い、GitHub はコードをホストします。.gitignore は、どのファイルを履歴に入れないかを Git に伝えるためのファイルです。

基本的な AI プロジェクトでは、少なくとも次を除外すべきです。

.env
.env.*
*.key
*.pem
config.local.*
secrets.*
credentials.*

ただし .gitignore だけでは不十分です。これは未追跡ファイルが今後追加されるのを防ぐだけです。すでにコミットされたシークレットファイルは、後から .gitignore に書いても履歴から消えません。

安全な習慣は次の通りです。

新規プロジェクトの最初に .gitignore を作る。
API Key は環境変数またはローカル設定だけに置く。
.env.example にはプレースホルダーだけを書き、本物の Key は書かない。
コミット前に gitleaks、trufflehog、GitHub Secret Scanning などでスキャンする。

Key を push したら、ファイル削除だけでは安全にならない

Key を公開リポジトリへ push してしまった場合、最初にやるべきことは「ファイルを消してもう一度コミットする」ことではありません。まず Key を失効またはローテーションします。

Git は履歴を記録します。最新コミットでファイルを削除しても、古いコミット、fork、clone、キャッシュ、スキャンシステムに内容が残る可能性があります。GitHub の公式ドキュメントでも、パスワード、Token、認証情報が漏れた場合は、まず取り消しまたはローテーションすることを勧めています。

推奨手順は次の通りです。

サービス提供元の管理画面で古い Key を失効し、新しい Key を発行する。
請求、利用ログ、不審な IP、異常な使用量を確認する。
ハードコードされた Key を消し、環境変数またはシークレット管理サービスへ移す。
git filter-repo または BFG でリポジトリ履歴から機密ファイルを除去する。
GitHub Secret Scanning と Push Protection を有効にする。
CI/CD、デプロイ基盤、クラウド関数、フロントエンド成果物に古い Key が残っていないか確認する。

OpenAI、Anthropic、DeepSeek、クラウド事業者、決済、メール、データベースなどの Key が漏れると、課金被害だけでなく、データ読み取り、サービス悪用、サプライチェーン汚染、業務アカウント停止につながる可能性があります。

フロントエンドに本物の Key を置いてはいけない

初心者は「画面が動けばよい」と考えて、API Key をフロントエンド JavaScript に書いてしまうことがあります。

`1`	`const apiKey = "sk-xxxxxxxx";`

これはほぼ公開と同じです。ブラウザ上のコード、ネットワークリクエスト、Source Map、ビルド成果物は確認できます。秘密にすべき Key はクライアント側に出してはいけません。

正しい構成は、フロントエンドから自分のバックエンド API を呼び、バックエンドが環境変数を読んで外部 API を呼ぶ形です。

// frontend
await fetch("/api/chat", {
  method: "POST",
  body: JSON.stringify({ message })
});

サーバー側で環境変数を使います。

1
2

// server
const apiKey = process.env.OPENAI_API_KEY;

これは形式の問題ではなく、Key をサーバー環境に残し、ページ訪問者全員へ露出しないための設計です。

Vibe Coding でも安全責任は消えない

vibe coding の問題は GitHub 漏洩だけではありません。AI コーディングプラットフォームから直接公開インターネットへデプロイされるアプリも多く、従来のコードレビュー、リポジトリスキャン、セキュリティテストを通らないことがあります。

RedAccess の最近の調査では、AI コーディングツールで生成またはホストされた公開資産が大量に見つかり、その一部が企業データ、個人情報、内部ファイルを露出していました。ここでの教訓は単純です。「公開できる」が簡単になりすぎると、「公開すべきか」「社内限定にすべきか」「権限制御があるか」が見落とされやすくなります。

AI で生成したアプリを公開する前に、少なくとも次を確認します。

このアプリは本当に公開アクセスが必要か。
ログイン、認証、権限分離があるか。
データベース、API Key、Token、Webhook URL がフロントエンドに露出していないか。
外部 API のクォータ、ドメイン、権限、有効期限を制限しているか。
異常発見後に Key を無効化し、デプロイを素早くロールバックできるか。

AI が書いたコードにもセキュリティレビューは必要です。「自分では一行も書いていない」ほど、安全だと思い込むべきではありません。

今すぐ確認すること

まず自分の GitHub アカウントから確認できます。ユーザー名と次のキーワードを組み合わせて検索します。

API_KEY
SECRET
TOKEN
OPENAI_API_KEY
ANTHROPIC_API_KEY
DEEPSEEK_API_KEY
.env
config
credentials

本物の Key を見つけたら、迷わず先にローテーションし、その後でクリーンアップします。一度でも公開リポジトリに入ったなら、漏洩済みとして扱うべきです。

今後の AI プロジェクトでは、次の流れを固定化すると安全です。

業務コードを書く前に .gitignore を用意する。
.env.example で必要な変数を説明する。
すべての Key は環境変数に置き、ソースコードへ書かない。
API Key には最小権限、クォータ、有効期限を設定する。
GitHub Secret Scanning と Push Protection を有効にする。
公開前に AI にセキュリティチェックを手伝わせても、AI の結論だけを信じない。

AI コーディングの本当の危険は、コードを書き間違えることだけではありません。多くの人が初めて、安全でないアプリを公開インターネットへ素早く出せるようになったことです。速く書くこと自体は問題ではありません。シークレット、データ、権限まで一緒に渡してしまうことが問題です。