この記事は Claude on SonicGarden の記事です。ソニックガーデンのプログラマが、Claude Codeの活用について書いています。#claude_on_sonicgarden
はじめに ー エンジニアは何をする人になるか
Claude Code GitHub Actions を導入すると、GitHub で @claude とメンションするだけで、非エンジニアでも PR を作れるようになります。
この導入方法は上の説明に譲りますが、つまり 非エンジニアが直接開発して、PR を送れる時代になったということです。 この流れは加速していくと思います。
タイトルに対する結論を先に書くと、今後エンジニアの仕事の一部は
「コードを書くこと」から「コードを書かせる環境を作ること」に変わる
と私は考えています。
これはエンジニアの意識と仕事の両方に大きな転換を迫ります。
本記事ではある社内プロジェクトで非エンジニアが機能開発をする運用を行うために、実際に整備した 3 つの仕組みを紹介します。
本プロジェクトの機能開発の流れ
| 役割 | 内容 | |
|---|---|---|
| 1 | 非エンジニア | Issue で要件を書き、@claude に実装を指示。PR ができる |
| 2 | エンジニア | コードを確認・修正、テスト環境に反映 |
| 3 | 非エンジニア | テスト環境で動作・見た目を確認。必要なら追加修正を指示 |
| 4 | エンジニア | 本番に反映 |
| 5 | 非エンジニア | 本番で確認 |
役割分担
このプロジェクトでは、おおよそ次のように役割を分けています。
| 役割 | 仕事 |
|---|---|
| 非エンジニア | 要件・仕様を具体化する / 動作・見た目の最終確認 |
| エンジニア | 内部品質（コード・モデリング）の担保 / 仕組みづくり |
ポイントは、「動作の正しさ」と「内部品質の正しさ」を責任を持つ人を分ける ことです。
動作や見た目の正しさは変更の動機を持っている本人にしか最終的には判断できませんし、内部品質の正しさはエンジニアにしか判断できません。
ただし、この役割分担はあくまで土台であって、厳密に守るものではありません。
お互いの領域を守りすぎると、全体としてはむしろ遅くなります。
例えばエンジニアが怪しい部分の動作を確認して修正こともありますし、非エンジニアに内部品質を上げるための仕様変更や指示の出し方をお願いしてもよいでしょう。役割を踏み越えてパフォーマンスが上がるなら、役割を破るくらいの柔軟さで運用します。
重要なことは全体として一番良いパフォーマンスを目指すことです。
仕組み 1 ー AI に「いきなり書かない」を強制する
ここからは内部品質を上げるために、実際にリポジトリで動かしている仕組みを 3 つに分けて紹介します。
ひとつめは、きちんとした手順で開発を進めさせる開発フローの定義です。
Issue 本文に要件を記載して実装を指示すると Claude Code が実装を進めますが workflow の prompt に以下の手順を埋め込んでおき、Claude Code に必ずこの順で進ませます。
1. Issue 分析・要件整理
2. 計画策定（**この時点ではコードを書かない**）
3. 計画セルフレビュー
4. 実装 (TDD)
5. Simplify（重複・命名・複雑さを見直す）
6. Check / Test（`bin/rubocop` `bin/brakeman` `bin/rspec`）
7. セルフコードレビュー（git diff を取って 3 観点でセルフレビュー）
8. コミット・PR 作成
ポイントは、「計画」と「セルフレビュー」を実装の前後に必ず挟ませる ところです。
人間の開発者なら自然にやることを、AI にも明示的に強制します。
言わずもがな、ですが CI の中で実行していることを AI に理解させ、人間に確認を求めない ようにもしなくてはいけません。そうしないと AI は人間の応答を待ってしまい、途中で止まってしまいます。
仕組み 2 ー 設計・コーディングルールを AI に理解させる
次に計画や実装時にきちんとした設計・コーディングをさせるためのルール群 .claude/rules/ を整備します。
.claude/rules/
├── coding-style.md # メソッドの長さ、インデントなど
├── git-workflow.md # コミットメッセージ、ブランチ戦略
├── security.md # セキュリティ関連
├── views.md # ビュー・見た目など
├── model.md # モデル・DBに関して
└── ...
rules の整備はエンジニアの重要な仕事です。この rules を更新すべきかは常に意識します。
何度も言いますが、エンジニアの仕事は「自分でコードを書くこと」から「AI が正しくコードを書ける環境を整えること」へ移っていきます。その前提に立つと rules を更新することは主要な仕事になると感じています。
仕組み 3 ー PR が立ったら別の AI に独立レビュー・修正させる
PR が立つと、別の GitHub Actions が起動して別の Claude Code がレビューします。作る AI とレビューする AI を分ける ことで、 AI 自身の自己採点に陥らずレビューの独立性を担保します。
このレビュー結果を参考にしつつ、もちろん エンジニア自身も全体のコードを見てレビューをします。
修正自体も、 Claude Code に「このレビューコメントを踏まえて直して」と渡すことが多く、ここでも手を動かすのは AI、判断するのはエンジニア、という構図です。
重要なのは、AI の書いたコードやレビューを鵜呑みにせず批判的にレビューすることと、修正自体もAIにさせることです。人間が修正せずに AI に修正させることで、その指示を rules や新たなコンテキストに加えるべきかも考えやすくなります。
まとめ
本記事では非エンジニアが PR を送れるようにするための環境整備を 3 つ紹介しました。
冒頭で書いた通り、エンジニアの仕事は 「コードを書くこと」から「コードを書かせる環境を作ること」へ移っていくと思います。
その状況下では
- AI に正しく文脈を与えるコンテキストエンジニアリング
- 開発そのものを自動化するためのエンジニアリング
が今後の主要なエンジニアリング要素になるはずです。言うのは簡単ですが、これを実現するには発想の転換が必要で、今までの開発から一段抽象度を上げた発想が求められるように感じています。