はじめに
私はブリッジSEとして働いています。当社ではERP実装支援やAWSシステム開発を手がけています。私自身プログラミング経験はありますが、日常的にフルタイムでコードを書いているわけではありません。
そんな自分が、Claude Codeによるバイブコーディングで以下の3つを構築しました：
- kazahana ── Blueskyデスクトップクライアント（Tauri v2 + React + TypeScript）
- BSAF ── Bluesky上の構造化アラートBot向けオープンプロトコル
- JMA Bot ── 気象庁の災害情報をBSAF形式でBlueskyに投稿するBot
この記事では、Claude Codeを使ったバイブコーディングの実践的なワークフローを、kazahanaの開発体験を通じて紹介します。
バイブコーディングとは何か
バイブコーディングとは、コードを一行一行手で書くのではなく、AIに意図を伝えて実装を進める開発スタイルです。「こういう機能が欲しい」「このバグを直したい」と伝えれば、AIがコードを生成・修正してくれます。
「コードを書く」から「意図を伝える」へ
従来の開発：
要件を理解 → 設計 → コーディング → テスト → デバッグ
バイブコーディング：
要件を理解 → 設計 → 意図をAIに伝達 → レビュー → フィードバック
「コーディング」の部分がAIに委譲される代わりに、意図を的確に伝える力とレビューする力が重要になります。
ブリッジSEの視点
ブリッジSEの本業は、異なる立場の人々の間に立ち、要件を翻訳・調整することです。顧客の要望をエンジニアに伝え、技術的な制約を顧客に説明します。
AIとの対話もこれと同じスキルセットが活きます。「何を作りたいか」を明確に言語化し、制約条件を伝え、出力をレビューしてフィードバックする。「要件を的確に言語化する力」がバイブコーディングの核だと感じています。
開発環境とワークフロー
ツール構成
kazahanaの開発で使用しているツール構成は以下の通りです：
| ツール | 役割 |
|---|---|
| Claude（claude.ai） | 設計相談、アーキテクチャの壁打ち |
| Claude Code（VS Code統合） | 実装、リファクタリング、テスト、Git操作 |
| VS Code | エディタ、コードレビュー |
| GitHub | バージョン管理、CI/CD、Issues |
実際の開発フロー
設計相談(Claude) → 実装指示(Claude Code) → コードレビュー → コミット → CI/CD
- 設計相談 ── 新機能のアプローチや技術選定をClaudeと議論
- 実装指示 ── Claude Codeに具体的な指示を出して実装
- コードレビュー ── 生成されたコードをVS Code上で確認・修正
- コミット ── Claude Codeにコミット・プッシュを指示
- CI/CD ── GitHub ActionsでビルドとRelease Draftを自動生成
VS Code + Claude Code ── まさにこの記事を執筆している画面
Claude Code の具体的な活用場面
新機能の実装：
「BsafBotsViewコンポーネントを作成してください。
URLまたはJSONファイルからBot定義を読み込み、
registeredBotsに追加する機能です。
既存のsettingsStore.tsのパターンに従ってください。」
このように、目的 + 制約 + 参照先を明確にすると、既存コードとの整合性が取れた実装が生成されます。
バグ修正：
エラーログやスタックトレースをそのままClaude Codeに貼り付けるだけで、原因の特定から修正まで行ってくれます。
i18n対応：
11言語の翻訳JSON生成は、Claude Codeが最も効果を発揮した場面の一つです。
「en.jsonを基に、以下の11言語の翻訳ファイルを生成してください：
ja, en, pt, de, zh-TW, zh-CN, fr, ko, es, ru, id」
Git操作・リリース：
「バージョンを2.1.3に更新して、package.json, Cargo.toml,
tauri.conf.jsonを変更し、リリースノートを作成してコミットしてください」
CLAUDE.md ── プロジェクトルールの定義
Claude CodeにはCLAUDE.mdというプロジェクトルールファイルを設定できます。kazahanaでは以下のようなルールを定義しています：
- タスク管理ファイルの場所と書式
- バージョン更新対象のファイル一覧
- ドキュメントの構成（
docs/en/とdocs/ja/の同期更新） - CI/CDの仕組み（タグプッシュでGitHub Actionsが発火）
プロジェクト固有のルールを事前に定義しておくことで、毎回同じ説明をする必要がなくなります。
kazahana の技術スタック
アーキテクチャ概要
kazahanaはTauri v2で構築したBlueskyデスクトップクライアントです。
kazahana ── 1カラムUIのBlueskyデスクトップクライアント
┌──────────────────────────┐
│ Frontend (WebView) │
│ React 19 + TypeScript │
│ + Vite + TailwindCSS │
├──────────────────────────┤
│ Backend (Rust) │
│ Tauri v2 + Plugins │
│ (トレイ, 通知, ストア等) │
└──────────────────────────┘
Electronとの大きな違いは、Chromiumをバンドルしないことです。OS標準のWebView（Windows: Edge WebView2、macOS: WKWebView）を使うため、メモリフットプリントが大幅に小さくなっています。
フロントエンド構成
| カテゴリ | 技術 | 用途 |
|---|---|---|
| UI | React 19 + TypeScript | コンポーネント |
| ビルド | Vite | 高速バンドル |
| 状態管理 | Zustand（11ストア） | クライアント状態 |
| サーバー状態 | @tanstack/react-query | APIキャッシュ管理 |
| スタイリング | TailwindCSS | ユーティリティCSS |
| アイコン | Material Symbols Rounded | 統一的なアイコン |
| 仮想スクロール | react-virtuoso | 大量投稿の高速表示 |
| i18n | i18next（11言語） | 多言語対応 |
| Bluesky SDK | @atproto/api | AT Protocol通信 |
主な依存パッケージ
{
"@atproto/api": "^0.18.21",
"@tanstack/react-query": "^5.90.21",
"@tauri-apps/api": "^2.10.1",
"i18next": "^25.8.13",
"react": "^19.2.0",
"react-router-dom": "^7.13.0",
"zustand": "^5.0.11"
}
主要機能
- タイムライン（ホーム、カスタムフィード、リスト）
- 投稿（画像4枚、動画、alt text、引用）
- 通知、検索、DM（絵文字リアクション対応）
- プロフィール（投稿/いいね/メディア/ピン留めタブ）
- BSAF Bot登録・フィルタリング
- コンテンツモデレーション（ラベルベースのぼかし/非表示）
- カスタムプロトコル
kazahana://compose（ブックマークレット連携） - システムトレイ常駐、ウィンドウ状態保存、自動起動
数字で見る kazahana
| 指標 | 値 |
|---|---|
| バージョン | v2.1.3（2026年3月時点） |
| TypeScript/TSXファイル | 97ファイル |
| コミット数 | 164+ |
| 対応言語 | 11言語 |
| 対応OS | Windows, macOS |
3プロジェクト全体の開発規模と期間
kazahana単体ではなく、BSAF エコシステム全体の開発規模をまとめます。
| リポジトリ | ソースコード | コミット数 | 実開発期間 |
|---|---|---|---|
| kazahana（クライアント） | 12,245行（TS/TSX/Rust） | 164 | 11日 |
| bsaf-protocol（仕様書） | 2,041行（Markdown） | 13 | 6日 |
| bsaf-jma-bot（Bot） | 3,461行（TypeScript） | 14 | 5日 |
| 合計 | 17,747行 | 191 | 約12日間（並行開発） |
kazahanaだけでも、12の機能モジュール、11のZustandストア、15のカスタムフック、11言語のi18n、CI/CDパイプラインを含みます。bsaf-jma-botは10種類の災害情報パーサーを実装しています。
従来の開発手法との比較
プログラマ1名が従来手法で同等のものを開発した場合の想定期間を、業界で一般的に使われる生産性指標（設計・テスト・デバッグを含めて100〜200行/日）から算出しました。
| プロジェクト | 従来手法の想定期間 | バイブコーディング | 短縮率 |
|---|---|---|---|
| kazahana | 3〜5か月 | 11日 | 約8〜14倍 |
| bsaf-protocol | 2〜4週間 | 6日 | 約2〜5倍 |
| bsaf-jma-bot | 1〜2か月 | 5日 | 約6〜12倍 |
| 合計（逐次開発） | 約6〜8か月 | 約12日 | 約15〜20倍 |
この比較は目安です。従来手法の見積もりは「経験のあるプログラマ1名がフルタイムで集中開発した場合」を想定しており、学習コストやプロジェクト管理のオーバーヘッドは含んでいません。バイブコーディング側も、私自身のプログラミング経験とドメイン知識があってこその数値だと自負しています。
バイブコーディングで特に効果的だった場面
1. i18n 11言語対応
kazahanaは11言語のUIをサポートしています。i18nextの設定とすべての翻訳JSONを、Claude Codeに生成させました。
// src/i18n/index.ts
import i18n from "i18next";
import { initReactI18next } from "react-i18next";
import LanguageDetector from "i18next-browser-languagedetector";
import ja from "./locales/ja.json";
import en from "./locales/en.json";
// ... 他9言語のimport
i18n
.use(LanguageDetector)
.use(initReactI18next)
.init({
resources: {
ja: { translation: ja },
en: { translation: en },
// ... 他9言語
},
fallbackLng: "en",
interpolation: { escapeValue: false },
});
LanguageDetectorでOSの言語設定を自動検出し、対応していなければ英語にフォールバックします。11言語分の翻訳ファイル生成は、手作業なら数日かかるところを数時間で完了できました。
2. BSAFプロトコルの実装
BSAFの仕様書（bsaf-spec.md）をClaude Codeのコンテキストとして渡し、タグパースとフィルタリングのロジックを構築しました。
// src/lib/bsaf.ts - タグパース
export function parseBsafTags(tags: string[]): BsafParsedTags | null {
if (!tags.includes("bsaf:v1")) return null;
const parsed: Partial<BsafParsedTags> = { version: "v1" };
for (const tag of tags) {
const colonIdx = tag.indexOf(":");
if (colonIdx === -1) continue;
const key = tag.slice(0, colonIdx);
const val = tag.slice(colonIdx + 1);
switch (key) {
case "type": parsed.type = val; break;
case "value": parsed.value = val; break;
case "time": parsed.time = val; break;
case "target": parsed.target = val; break;
case "source": parsed.source = val; break;
}
}
if (!parsed.type || !parsed.value || !parsed.time
|| !parsed.target || !parsed.source) {
return null;
}
return parsed as BsafParsedTags;
}
仕様書をコンテキストとして渡すことで、タグ名やバリデーションルールが仕様と正確に一致した実装が生成されました。
3. 画像自動圧縮
Blueskyの画像サイズ上限は976KBです。ユーザーが大きな画像をドラッグ＆ドロップしても、OffscreenCanvas APIで段階的にJPEG品質を下げて圧縮する仕組みを実装しました。品質100%→80%→60%→40%と段階的に試行し、制限内に収まった時点で停止します。
4. CI/CDパイプライン
GitHub Actionsのリリースワークフローを構築しました。タグをプッシュすると、Windows（x64）とmacOS（Intel + Apple Silicon）のビルドが自動で走り、Release Draftが作成されます。
5. リッチテキスト検出
AT Protocolでは、投稿中の@メンション、#ハッシュタグ、URLをfacetとして構造化する必要があります。テキストを解析してfacetを自動検出・生成するロジックもClaude Codeで実装しました。
バイブコーディングの注意点と学び
AIは万能ではない
バイブコーディングを実践する中で、AIに任せきりにできない領域がいくつもあることを学びました。
指示が曖昧だと、応答も見当外れになります。 「あの画面のあの部分をいい感じにして」では何も起きません。コンポーネント名、ストア名、API名 ── ニュアンスではなく正確な名称で伝える必要があります。人間相手なら通じる「察してほしい」は通用しません。
自分が知らないことは、指示できません。 kazahanaの通知機能で、「リポストのリポスト」が通知される仕様に気づかず、長い間放置してしまったことがあります。AT Protocolの仕様を把握していなければ、そもそも修正指示を出せません。AIはコードを書いてくれますが、何を作るべきかを判断するのは人間です。
Bluesky WebインターフェースやiOS版アプリでは「リポストへのいいねを通知する」「リポストのリポストを通知する」という設定項目があり、デフォルト無効になっていたのでした。いつ頃実装された機能だったのやら……。
既存コードとの整合性： 指示されたタスクを完璧にこなしても、コードベース全体との整合性を見落とすことがあります。生成されたコードが他のコンポーネントやストアと正しく連携するか、人間が確認する必要があります。
プラットフォーム固有の仕様： AT Protocol特有の仕様（facetのバイト位置計算、labelerの挙動等）は、正確な仕様をコンテキストとして渡さないと正しい実装になりません。
効果的な指示の出し方
バイブコーディングで最も重要なのは、指示の質です。
❌「ログイン機能を作って」
✅「LoginFormコンポーネントを作成してください。
- @atproto/apiのBskyAgent.loginを使用
- authStore.tsのsetSessionで認証状態を保存
- エラー時はtoastで通知（既存のuseToastパターンに従う）
- 既存のsrc/components/auth/を参照してください」
ポイントは3つです：
- 具体的なゴール ── 何を作るか
- 制約条件 ── どのAPIを使うか、どのパターンに従うか
- 参照先 ── 既存コードのどこを見ればよいか
また、CLAUDE.mdにプロジェクト全体のルールを事前に定義しておくと、毎回の指示がシンプルになります。
人間の役割の変化
バイブコーディングにおける人間の役割は、「コードを書く人」から以下に変わります：
- アーキテクチャの設計者 ── 全体の構造を決め、技術選定を行う
- 品質の保証者 ── 生成されたコードをレビューし、品質を担保する
- UXの判断者 ── ユーザー体験に関わる判断は人間が行う
レビュアーとしてのスキルが、従来以上に重要になります。
BSAFプロトコルとの連携
kazahanaはBSAFプロトコルのリファレンスクライアントとして機能しています。
BSAF（Bluesky Structured Alert Feed） は、Bluesky上の構造化アラートBot向けのオープン規約です。Botが投稿に構造化タグを付与し、クライアント側でユーザーの好みに応じてフィルタリングする仕組みを定義しています。
kazahanaでは以下の機能を実装しています：
- Bot Definition JSONのURL/ファイルからの登録
- Bot定義に基づくフィルタUIの自動生成
- 種別・深刻度・地域によるAND条件フィルタリング
- 複数Bot間の重複投稿の検出と折りたたみ
- 深刻度に応じた色付きボーダー表示
JMA Bot（@jma-alert-bot.bsky.social）が、地震・津波・噴火など10種類の災害情報をBSAF形式で投稿しており、kazahanaでフィルタリングして利用できます。
BSAFフィルタリングのデモページ： kazahana デモ
インストール不要で、ブラウザ上からBSAFフィルタリングの挙動を試すことができます。
BSAFの設計思想やプロトコルの詳細については、Zennに記事を書いていますので、そちらも参照してください。
👉 BSAF プロトコルを実現するために Bluesky クライアントを作った話 ── バイブコーディングという選択
まとめ
バイブコーディングは「コードを書けない人のためのツール」ではありません。プログラミング経験のある開発者が、生産性を飛躍的に向上させる手法です。
kazahana + BSAF + JMA Botという3つのプロジェクトを、Claude Codeを活用して構築できた実績がそれを証明しています。97ファイルのTypeScript/TSXコード、11言語のi18n対応、164以上のコミット。これらをバイブコーディングで実現しました。
ブリッジSEという立場で学んできた「要件を的確に言語化する力」は、バイブコーディングにおいても核となるスキルでした。AIとの対話は、人間同士のコミュニケーションの延長線上にあります。
この記事自体も、GitHub + Claude Codeで執筆管理しています。「バイブコーディングで開発したプロダクトについて、バイブコーディングで記事を書く」というメタ構造も、この開発スタイルならではの面白さです。
リンク集
- kazahana ── GitHub / 公式サイト / デモページ
- BSAF プロトコル ── GitHub
- JMA Bot ── @jma-alert-bot.bsky.social
- kazahana 公式 Bluesky ── @app-kazahana.bsky.social
- スポンサー ── GitHub Sponsors / Ko-fi