Claude-Code

Vibe Coding 2.0 — 「何を作らないか」を知る 18 のルール Vibe Coding とは（前提知識） Vibe Coding は、Andrej Karpathy（OpenAI 共同創設者）が 2025 年初頭に提唱した概念で、「コードの細部を手で書く」のではなく、AI に自然言語で指示してコードを生成させ、“ノリ（vibe）“で開発を進める スタイルを指します。Cursor や Claude Code などの AI コーディングツールの普及とともに広まりました。 MVP とは MVP（Minimum Viable Product / 実用最小限の製品） とは、顧客に価値を提供できる最小限の機能だけを備えた製品のことです。完璧な製品を作り込んでからリリースするのではなく、核となる機能だけを素早く形にして市場に投入し、実際のユーザーからフィードバックを得ながら改善していくアプローチを指します。 目的: アイデアが市場に受け入れられるかを、最小のコストと時間で検証する 考え方: 「完成品」ではなく「検証のための道具」。100 点を目指すのではなく、60 点で出して学ぶ 例: 動画配信サービスなら、レコメンド機能や検索機能を後回しにして、まず「動画を再生できる」だけのアプリをリリースする Vibe Coding 2.0 の文脈では、AI ツールを活用して MVP を高速にシップ（出荷）する ことが繰り返し強調されています。以下のルール群は、すべて「いかに早く MVP を世に出すか」を軸に設計されています。 Vibe Coding 2.0 とは Harshil Tomar 氏が X で投稿 した 「Vibe Coding 2.0: 18 Rules to be the Top 1% builder」 は、Vibe Coding の「次のフェーズ」を定義したものです。 ...

コードレビューは CLAUDE.md / skills に書け — 同じ指摘を繰り返すな 基本情報 発表者: 戸塚翔太（Tech Lead / EM、スタートアップ開発責任者） イベント: 「一歩踏み込む Claude Code 活用 LT 会」（Findy 主催、2026年2月22日） スライド: Speaker Deck 問題提起 「人間に対してレビューするの、もうやめませんか？」 コードレビューにおいて以下のような無駄が繰り返されている: 問題 具体例 同じ指摘の繰り返し 変数名の命名規則、コーディングスタイルへの指摘が毎回発生 修正ラリー 「指摘修正しました」→ 再レビュー → 再指摘 の往復 アーキテクチャ的な問題 根本的な設計の問題が PR 段階で発覚する これらはレビュアーの時間を奪い、開発速度のボトルネックになっている。 解決策: 使い捨てコメントをナレッジに変える 核心のアイデアは 「レビューで出た指摘を、PR のコメントとして消費するのではなく、CLAUDE.md や skills に書き込んでナレッジとして蓄積する」 こと。 従来: レビュー指摘 → PR コメント → 修正 → 忘れられる → また同じ指摘 提案: レビュー指摘 → CLAUDE.md / skills に追記 → 以降 Claude が自動で遵守 CLAUDE.md に書くもの コーディング規約（命名規則、ディレクトリ構成） アーキテクチャ上のルール（「この層でこの処理はしない」等） プロジェクト固有のパターン skills に書くもの レビュー観点をスキルとして定義 Claude Code が PR 作成前にセルフチェックできるようにする 自動化の仕組み 2 つの適用方法が紹介されている: ...

name: tmux-focus description: “tmux ウィンドウの Issue/PR 切替: /tmux-focus [-w|-r] ” tmux-focus スキル 現在の tmux ウィンドウの Issue/PR を切り替えるスキル。 使い方 /tmux-focus <number> — Issue モード Bash で以下を実行: 1 ~/.claude/skills/tmux-focus/scripts/tmux-issue-change.sh <number> ウィンドウ名を issue-<number> に変更し、対応する GitHub Issue をブラウザで開く。 /tmux-focus -w <number> — PR worktree モード gh pr view <number> で PR であることを確認する。PR でなければエラーメッセージを表示して終了。 Bash で以下を実行: 1 ~/.claude/skills/tmux-focus/scripts/tmux-issue-change.sh --pr <number> ウィンドウ名を pr-<number> に変更し、ブラウザで PR を開く。 EnterWorktree ツールで worktree を作成する。 worktree 内で以下を実行: 1 gh pr checkout <number> /tmux-focus -r <number> — PR レビューモード gh pr view <number> で PR であることを確認する。PR でなければエラーメッセージを表示して終了。 Bash で以下を実行: 1 ~/.claude/skills/tmux-focus/scripts/tmux-issue-change.sh --pr <number> ウィンドウ名を pr-<number> に変更し、ブラウザで PR を開く。 worktree 内でなければ EnterWorktree ツールで worktree を作成する。 worktree 内で以下を実行: 1 gh pr checkout <number> PR のコード差分をレビュー開始する（gh pr diff <number> で差分を取得し、変更内容を分析）。 スクリプトが存在しない場合 ~/.claude/skills/tmux-focus/scripts/tmux-issue-change.sh が存在しない場合は、以下の内容で作成して chmod +x する。 ...

業務フローの設計にPowerPointではなくBPMNを使うべき理由 — Claude Code時代の詳細設計 はじめに 業務システムの設計でSwim Lane（スイムレーン）形式の業務フローを書くとき、多くの現場ではPowerPointやFigmaが使われています。見た目は整えやすく、関係者への説明資料としてはよくできています。 しかし、この「人間が読むための図」を設計の源泉にしてしまうと、あと工程で大きなコストが発生します。特に、Claude CodeのようなAIエージェントを開発に活用する場合、設計成果物のフォーマット選択が開発効率を決定的に左右します。 本記事では、実際にPowerPointのスライドからBPMN 2.0に変換した経験をもとに、BPMNを採用する利点を解説します。 PowerPointの業務フローが抱える問題 PowerPointのスライドに描かれた業務フローは、本質的に「画像」です。 PowerPoint (.pptx) ├── 図形の座標とスタイル情報 ├── テキストボックスの文字列 └── グループ化とレイヤー これは人間が見るには十分ですが、次のような問題があります。 構造情報がない: 「この矢印がどのタスクからどのタスクへ向かっているか」をプログラムが読み取れない アクターの定義が曖昧: レーンの境界が図形の配置で表現されているだけで、意味的な紐付けがない 分岐条件が自然言語: ゲートウェイの条件が図中のテキストに埋め込まれ、機械的に検証できない フロー間の接続が不明確: 複数スライドにまたがるフローの接続点（「次のフローへ」）が視覚的な慣習に依存 BPMN 2.0とは BPMN（Business Process Model and Notation） は、業務プロセスを図式化するための国際標準記法です。OMG（Object Management Group）が策定し、ISO 19510として国際標準化されています。現行バージョンはBPMN 2.0.2です。 BPMNの最大の特徴は、人間が理解できるフロー図と機械が処理できるXMLが一つのファイルに同居している点です。プールとレーン（Swim Lane）でアクターを表現し、タスク・ゲートウェイ・イベントでプロセスの流れを記述します。 BPMN 2.0がもたらす構造化 BPMN 2.0はXML形式で、見た目と意味の両方を持つフォーマットです。 1 2 3 4 5 6 7 8 9 10 11 12 13 <bpmn:process id="Process_1" isExecutable="false"> <bpmn:laneSet id="LaneSet_1"> <bpmn:lane id="Lane_reception" name="太平受付担当"> <bpmn:flowNodeRef>r1</bpmn:flowNodeRef> <bpmn:flowNodeRef>r2</bpmn:flowNodeRef> </bpmn:lane> <bpmn:lane id="Lane_system" name="システム" /> </bpmn:laneSet> <bpmn:task id="r1" name="修理内容の特定" /> <bpmn:exclusiveGateway id="d2" name="保証範囲?" /> <bpmn:sequenceFlow sourceRef="r1" targetRef="d2" /> </bpmn:process> この構造から、以下がプログラム的に読み取れます。 ...

Claude Code スキルで CloudWatch エラーレポートの Issue トリアージを自動化する 背景 本番環境の ECS コンテナで発生したエラーは、CloudWatch Logs → Lambda → GitHub Issue という流れで自動起票される仕組みを運用しています。 タイトルは [prod][myapp] errors detected、ラベルは CloudWatchLog で統一されており、1つの Issue に複数のエラーブロックがまとまって届きます。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 ## Error Report - 2026-02-12 01:32:28 UTC - **Environment**: prod - **Log Group**: `/ecs/myapp-prod-ecs` - **Error Blocks**: 3 ### [1] 2026-02-12 01:32:26 UTC - `application` （スタックトレース） ### [2] 2026-02-12 01:45:10 UTC - `application` （スタックトレース） ### [3] 2026-02-12 02:01:33 UTC - `application` （スタックトレース） この Issue をそのまま放置すると、異なるエラーが混在したまま溜まっていきます。手作業で分類・個別 Issue 化するのは地味に面倒で、後回しにしがちでした。 ...

iPhone から GitHub Issue を書くだけで Mac の Claude Code が自動実行される仕組みを作った TL;DR GitHub Self-hosted Runner + Claude Code CLI を組み合わせて、iPhone で Issue を作成 → Mac 上の Claude Code が自動で調査・コード修正・PR 作成まで行う仕組みを構築した。2ステージ承認フロー付きで、/claude で調査、/approve で実行という安全な運用が可能。 モチベーション 普段 Mac の前にいないときでも、iPhone からコードの調査や修正を指示したい。GitHub Issue に書くだけで Claude Code が自動的に動いてくれれば、移動中でもコードレビューや修正依頼ができる。 完成した仕組み iPhone GitHub Mac (self-hosted runner) │ │ │ ├─ Issue 作成 ────────────→│ │ │ (claude ラベル付与) │── ワークフロー起動 ─────→│ │ │ ├─ claude -p (読み取り専用) │ │←── 調査結果コメント ──────┤ │ │ + 承認待ちラベル │ │ │ │ ├─ /approve コメント ──────→│ │ │ │── ワークフロー起動 ─────→│ │ │ ├─ claude -p (書き込み許可) │ │←── 実行結果 + PR ────────┤ │ │ - 承認待ちラベル │ トリガー一覧 操作 条件 動作 claude ラベル付き Issue 起票 起票者がリポジトリオーナー Stage 1: 読み取り専用で調査 /claude コメント コメント者がリポジトリオーナー Stage 1: 読み取り専用で調査 /claude --execute コメント コメント者がリポジトリオーナー Stage 1 スキップ、直接実行 /approve コメント コメント者がリポジトリオーナー + 承認待ち ラベル Stage 2: 計画に基づき実行 必要なもの macOS マシン (Apple Silicon / Intel) Claude Code CLI がインストール済み (npm install -g @anthropic-ai/claude-code) Claude Max/Pro プラン (OAuth トークン) または Anthropic API キー GitHub CLI (gh) セットアップ手順 1. Self-hosted Runner のインストール GitHub の個人アカウントでは Runner はリポジトリ単位の登録になる。同一マシンに複数の Runner を並置できる。 ...

Ghostty + Claude Code 連携ガイド GhosttyとClaude Codeの組み合わせは、多くの開発者が推奨する構成です。主なポイントをまとめます。 すぐに使える機能 Shift+Enter がネイティブ対応 Ghosttyでは Shift+Enter による改行入力がそのまま動作します。他のターミナルでは /terminal-setup で設定が必要ですが、Ghosttyでは不要です。 GPU アクセラレーション Claude Codeの出力が大量になっても、GPUレンダリングのおかげでスムーズにスクロール・表示されます。VS Codeのターミナルでは大量テキストのペースト時にフリーズすることがありますが、Ghosttyではその問題がありません。 おすすめワークフロー 1. スプリットペイン活用（最も人気の構成） Ghosttyのビルトインスプリット機能でClaude Codeと作業画面を並べられます。 # ~/.config/ghostty/config に追加 # スプリット作成 keybind = cmd+d=new_split:right keybind = cmd+shift+d=new_split:down # Vim風のペイン移動 keybind = ctrl+h=goto_split:left keybind = ctrl+j=goto_split:bottom keybind = ctrl+k=goto_split:top keybind = ctrl+l=goto_split:right 典型的な3ペイン構成: 左: Claude Code 右: エディタ (Neovim/Vim等) 下: 通常のターミナル (ビルド・テスト実行用) 2. タブで複数プロジェクト管理 Cmd+数字 でタブ間を素早く切り替えられるので、プロジェクトごとにタブを分けてClaude Codeセッションを使い分けられます。 3. Kitty Graphics Protocol GhosttyはKitty Graphics Protocolに対応しているため、ターミナル内で画像をインライン表示できます。 ...