この記事の内容は 2026 年 4 月時点の個人的な運用を紹介したものです。
はじめに
「vibe コーディング」「AI 駆動開発」といった言葉をよく見かけるようになりました。でも、実際にどうやって使えばいいのかよくわからない、という方も多いのではないでしょうか。
この記事では、私が日々使っている Claude Code × GitLab の開発ワークフロー を紹介します。ポイントは、たった 3 つのスラッシュコマンド を打つだけで、ブランチ作成からマージまで一気通貫に進められること。難しい設定や最新情報を追いかける必要はありません。自分なりに考えて動かしてみたら、うまくいっている——そういう話です。
対象読者
- vibe コーディング・AI 駆動開発に興味があるけれど、まだ始めていない方
- Claude Code を触り始めたばかりの方
- GitLab を使うとどんな開発スタイルになるのか知りたい方
テイクアウトメニュー（この記事で持ち帰れるもの）
- GitLab と Claude Code を組み合わせた個人開発フロー全体像の一例
- 3 つのスラッシュコマンド（skill ファイル）の中身
- 開発に対するモチベーションアップ
ワークフローの全体像
Issue 起票 → /start-mr → 実装 → /update-docs-and-test → /finish-mr → マージ
やることはこれだけです。各ステップで Claude Code にスラッシュコマンドを打つと、必要な操作を自動でやってくれます。
前提
- Claude Code がセットアップされていること
- GitLab（セルフホストでもクラウドでも可）にプロジェクトがあること
-
.claude/skills/に 3 つのファイルを配置すること（後述）
実演
ドキュメントを作って欲しい、というissueを作りました。本文はテンプレのままです。
Claude Codeに実施してもらいたい内容をコメントにメモしました。
（issueを作るとWebhookでClaude Codeが動き、自動でラベルが設定されて、その根拠がコメントされる仕組みを動かしています。その話はまた今度。）
1つ目のスラッシュコマンドであるstart-mrを使います。
/start-mr 2187と指示するだけで作業が開始されました。
途中で想定外のことがあったようで中断されて判断を促されました。今回は破棄していいと指示しました。
/start-mr の処理が完了しました。
指示内容はissueコメントに記載してあるので、それを見て作業してほしいと伝えました。
現状はIF一覧というフォルダがあり、アプリ名のファイルがあります。（これはObsidianというアプリです。ここではMarkdownエディタだと思ってください。）
issueコメントに記載したClaude Codeへの指示は、このIF一覧をアプリ一覧ではなく機能一覧に基づいたものに変えてほしいという依頼です。
完了したとのこと。
確認してみると、IF一覧が更新されていました。ぱっと見、問題なさそうなので続けました。
2つ目のスラッシュコマンド、/update-docs-and-test を投げました。
仕様書 #2225 を作成しました。 と出ました。
続いて3つ目のスラッシュコマンド、 /finish-mr を送信しました。
ちなみに作成された仕様書 #2225 はこのようになっています。
/finish-mrが完了しました。
MR本文を確認し、タブ[変更]で変更内容を確認し、問題がなかったのでボタン[マージ]でマージしました。
3 つのスラッシュコマンド
私のリポジトリの他の要素や説明していない前提に依存しているので、再現性は低いと思われます。ご参考まで。
1. /start-mr — ブランチを始める
Issue 番号を渡すと、次のことを自動でやってくれます：
-
git statusで未コミットの変更がないか確認 -
mainブランチへ切り替え・git pull - Issue 番号に対応するブランチと MR を作成
- Issue の内容をローカルに取得
以前は git checkout main && git pull を手で打ち、checkout できないときは状況確認や過去の履歴を見て…という作業を毎回していました。うまく始められないときのチェックリストを作ったこともあります。それを skill ファイルにしたことで、Claude Code が状況に応じて柔軟に対応してくれるようになりました。想定外のケースでは勝手に進めず確認してくれます。
# start-mr
## 概要
ブランチ開始時に実行するワークフロー。
Issue番号を指定して、ブランチ作成・MR作成・MR本文取得・Issue取得まで行う。
## 手順
1. `git status` で作業途中の変更がないことを確認する。あれば中断する
2. `main` ブランチへ切り替える
3. `git pull` する
4. `create-gitlab-mr <issue_number>` を実行する
5. `get-gitlab-issue <issue_number>` を実行する
## 失敗時の扱い
いずれかの手順で失敗したら中断する。後続は実行しない。
注:
create-gitlab-mrとget-gitlab-issueはこのリポジトリ独自の bash スクリプトです。それぞれ GitLab API を叩いてブランチ・MR の作成や Issue 内容の取得を行います。同様の処理を自分のリポジトリに用意するか、Claude Code に直接 GitLab API を呼ばせるよう手順を書き換えてください。
2. /update-docs-and-test — ドキュメント更新とテストを行う
実装が終わったら（または実装中でも）このコマンドを実行します：
- 変更したソースコードを確認
- 対応する仕様書（GitLab Issue として管理）を取得または新規作成
- 仕様書を更新して GitLab へ反映
- 仕様書に記載されたテストを実施
- テスト結果を整理（成功 / 失敗 / 未実施）
以前は「ドキュメントを修正して」「テストして」と毎回指示していました。別の Issue に急いで対応したいときなど、気分でスキップしてしまうことがありました。今はスラッシュコマンド 1 つで済むので、ほぼスキップしなくなりました。
# update-docs-and-test
## 概要
変更したソースコードに対応する仕様書を取得または作成し、内容を更新して、
仕様書に記載されたテストを実施する。実装中に繰り返し実行してよい。
## 手順
1. `git status` で作業途中の変更がないことを確認する
2. 変更したソースコードを確認する
3. 対応する仕様書を確認・取得・または新規作成する
4. 仕様書を更新する
5. 仕様書を GitLab へ反映する
6. 仕様書に記載されたテストを実施する
7. テスト結果を整理する
3. /finish-mr — MR をまとめて終わらせる
マージ前の仕上げをまとめてやってくれます：
- ローカルの仕様書を全件 GitLab へ反映
- 新規追加した仕様書を
spec-numbers.yamlに登録 -
docs/README.mdを更新 - MR 本文を編集・GitLab へ反映
「コミットし忘れた spec の更新」「MR 本文が空のまま」といったことが起きなくなりました。
# finish-mr
## 概要
ブランチ終了時に実行するワークフロー。
仕様書 Issue の反映、仕様書一覧更新、MR 本文更新を行う。
## 手順
1. `git status` で作業途中の変更がないことを確認する
2. `__download/` にある `*.md` を全件 GitLab へ反映する
3. 新規追加した仕様書があれば `spec-numbers.yaml` に追加する
4. `update-docs-readme` を実行して `docs/README.md` を更新する
5. MR 本文を編集・反映する
注:
update-docs-readmeはこのリポジトリ独自の bash スクリプトです。docs/README.mdを自動生成・更新する処理を GitLab API 経由で行います。同様の処理を自分のリポジトリに用意するか、手順を「docs/README.mdを手動で更新する」に置き換えてください。__download/にある*.mdとは、独自のbashスクリプトでダウンロードしたIssueとMRです。
skill ファイルの置き場所
.claude/skills/ ディレクトリに Markdown ファイルとして置くだけです。
.claude/
skills/
start-mr.md
update-docs-and-test.md
finish-mr.md
Claude Code がこのディレクトリを参照し、/start-mr のようなスラッシュコマンドとして使えるようになります。
うまくいっていること
気楽に Issue を対応できる
Issue をとりあえず起票しておいて、気が向いたときに /start-mr を打てばすぐ始められます。以前は手作業の準備が面倒で後回しにしてしまうことがありましたが、今は Issue の消化が明らかに進んでいます。
ドキュメント更新・テストが習慣になった
スラッシュコマンドに組み込まれているので、意識しなくても実施されます。「今日は急いでるからスキップ」がほぼなくなりました。
運用ルールの更新が楽になった
以前は運用ルールをチェックリストで管理していました。変更したいときはチェックリストを手で修正していましたが、今は Claude Code に「こうするのはどうか」と相談しながら skill ファイルを更新しています。想定外になっても、すぐにリカバリできるので心理的に楽です。
うまくいっていないこと（正直に）
現在の運用ルールを一言で説明できない
動いてはいるし困らないのですが、「今どうなっているか」を俯瞰しにくい状態です。本腰を入れて図示させたりすれば整理できるかもしれません。
テストが適当
現状は bash の shellcheck のみ。Node.js をよく使うので、eslint や npm test のサポートを skill に追加したいと思っています。
まとめ
| コマンド | タイミング | やること |
|---|---|---|
/start-mr |
開発開始時 | ブランチ作成・MR 作成・Issue 取得 |
/update-docs-and-test |
実装中・実装後 | 仕様書更新・テスト実施 |
/finish-mr |
マージ前 | 仕様書反映・MR 本文整理 |
3 つのコマンドを打つだけで、ブランチ開始からマージまでの定型作業が自動化されます。 GitLab の Issue 管理と組み合わせることで、個人開発でも「やること」が積み上がっていく感覚が得られます。
難しいことを考えず、まず .claude/skills/ に 3 つのファイルを置いてみてください。
（余談）AI の使い方に正解はない
この記事に共感しましたので勝手にご紹介です。
最新の AI 情報をあまり追いかけていません。それよりも、「今自分が何をやりたくて、そのための手段はあるか」という視点で調べています。
自分なりに考えたやり方でしばらく動かしてみて、不満があれば変えればいい。難しく考えなくていい、というのが正直な感想です。