バイブコーディングで何を自動化し何を人に委ねるか

はじめに

Claude Codeを使い始めて、ふと立ち止まって考えることがあります。「これ、どこまで任せていいんだろう」と。便利だからといって何でも自動化すればいいわけではありません。任せすぎると、なぜそのコードが生まれたのか分からなくなります。かといって、毎回同じ作業を手でやるのも時間がもったいないです。

この記事では、私がIssue解決ワークフローを自動化する中で見つけた「境界線」についてお話しします。

自動化の境界線を図で理解する

まず、自動化すべき領域と人間が担うべき領域を整理します。

flowchart TB
    subgraph 自動化に向いている領域
        A[Issue解析] --> B[タスク分解]
        B --> C[コミットメッセージ生成]
        C --> D[定型的なコード生成]
    end

    subgraph 人間が担う領域
        E[設計判断] --> F[アーキテクチャ決定]
        F --> G[git push]
        G --> H[最終レビュー]
    end

    D -.->|確認後| E
    H -.->|次のIssueへ| A

この図が示すように、ワークフローの中には自動化できる部分とできない部分があります。重要なのは、その境界をどこに引くかです。

自動化に向いている作業の見分け方

自動化すべき作業には、共通する特徴があります。

まず「毎回同じパターンで繰り返す作業」です。たとえば、Issueの内容を読んで「何が問題か」「どうなってほしいか」を整理する作業。これは形式が決まっているので、任せやすいです。

次に「正解がはっきりしている作業」です。コミットメッセージの形式を揃えたり、ファイル名の命名規則を守ったりする作業がこれにあたります。ルールが明確なら、間違えることはありません。

私がつくった/solve-issueというコマンドでは、Issueの解析とタスク分解、そしてConventional Commits形式でのコミットメッセージ生成を自動化しています。これらはまさに「毎回同じで、正解がはっきりしている」作業だからです。

人間に委ねるべき判断とは

一方で、絶対に自動化しないと決めている作業があります。

graph LR
    subgraph 自動化しない理由
        A[git push] -->|取り消しが困難| B[不可逆な操作]
        C[設計判断] -->|文脈依存| D[正解がない判断]
        E[ライブラリ選定] -->|将来への影響| F[長期的な決定]
    end

その代表がgit pushです。リモートリポジトリへの反映は、一度やると取り消しが面倒です。「本当にこの変更でいいか」は、最後に人間の目で確認したいと考えています。

もうひとつは「どう実装するか」の設計判断です。たとえば「メール検証を追加する」というIssueがあったとき、正規表現で検証するのか、外部ライブラリを使うのか。これはプロジェクトの文脈や今後の拡張性を考えて人間が決めるべきです。

つまり「取り返しがつかない操作」と「文脈を踏まえた判断」は人間の領域だと考えています。

境界線を見誤った経験から

最初は「全部自動化できたら便利だろう」と思っていました。でも実際にやってみると、うまくいかないことがありました。

ある機能追加のIssueを自動処理したとき、コードとしては動くものができました。でも、プロジェクト全体のアーキテクチャと合っていない実装になっていたのです。「動く」と「正しい」は違います。

この経験から、渡す前に「このIssueは自動化に向いているか」を考えるようになりました。バグ修正や軽微な機能追加は向いています。でも、設計の見直しが必要そうなものは、まず自分で方針を決めてから作業を依頼するようにしています。

自動化の本質は「集中」をつくること

自動化の価値は、作業を速くすることだけではありません。本当の価値は「考えるべきことに集中できる」ことにあります。

コミットメッセージの形式を考える時間をゼロにできれば、その分「この実装で本当にいいか」を考える余裕が生まれます。Issueの整理を自動化できれば、解決方法を考えることに頭を使えます。

終わりに

バイブコーディング時代の自動化は「全部任せる」か「全部自分でやる」かの二択ではありません。反復作業は任せて、判断が必要な場面では自分で考える。この使い分けができると、開発がとても楽になります。

完璧な境界線は最初から引けません。私も試行錯誤しながら、少しずつ見つけていきました。みなさんも自分のプロジェクトで「ここは任せていい」「ここは自分で見る」を探してみてください。

↓↓関連記事もぜひ読んでみてください！

Claude Code：カスタムコマンドで出力品質が変わる理由 scriptlab.jp

参考リンク

この記事で紹介した内容をさらに深く学ぶためのリソースです。

• Claude Code 公式ドキュメント：スラッシュコマンドの作成方法やカスタマイズの詳細が記載されています。自分だけの自動化コマンドを作りたい方に役立ちます。

Not Found - Claude Docs docs.anthropic.com

• Claude Code GitHub リポジトリ：実際のソースコードやIssue、他の開発者の使い方を見ることができます。困ったときのトラブルシューティングにも便利です。

GitHub - anthropics/claude-code: Claude Code is an agentic coding tool that lives in your terminal, understands your codebase, and helps you code faster by executing routine tasks, explaining complex code, and handling git workflows - all through natural language commands. GitHub

• Conventional Commits 仕様：コミットメッセージの形式を統一するための規約です。自動生成するコミットメッセージの品質を保つために参照しています。

/ja/v1.0.0/ www.conventionalcommits.org

• GitHub CLI 公式ドキュメント：gh issue viewなどのコマンドでIssue情報を取得する際に使います。自動化ワークフローとGitHubを連携させたい方に必須です。

Manual GitHub CLI