クラウドサイン Product Engineering 部でエンジニアをしている比嘉（@teitei_tk）です。好きな技術革新は活版印刷です。
はじめに: なぜ今「手動コーディング禁止」なのか
普段はエンタープライズ向け機能を作成するチームで、開発チームのリーダーを務めています。
私のチームを含め、弁護士ドットコムでは AI を積極的に活用しています。
GitHub Copilot の利用から始まり、Cursor の導入や ClaudeCode を使ったプロダクト開発も進めています。 つい最近では gemini-cli・Kiro の利用も始まりました。
その他、自社で利用するための MCP サーバーの実装も行っています。
一方で、私のチームでは AI を活用する中で次のような課題も見えてきました。
- メンバーによって AI ツールの習熟度にばらつきがある。
- 家庭の事情などにより、業務外で AI の勉強時間を確保しづらい。
- AI に頼ることへの心理的抵抗感。
これらの課題を抱えている中、手動でのコーディングを禁止にし、LLM のみで開発したという記事を目にしました。
我々も、同様の施策によってこれらの課題を解消できると考えました。
上長に「短期的に成果が下がることを承知で試したい」と相談したところ「積極的に実施してほしい」という意見をもらいました。PdM からも「問題ない、むしろ長期的な成果が出るなら歓迎」と背中を押されました。メンバーからも「楽しそう・興味がある」と好意的な意見がほとんどでした。
今回の施策を「手動コーディング禁止祭」と位置付け、開催するに至りました。
手動コーディング禁止祭の概要
施策の概要は以下のとおりです。
目標
- AI 習熟度レベルの底上げ
- AI ファーストへの思考変化の推進
- プロンプト・ルールファイルを共有資産化
期間
2 週間（1 スプリント）
対象メンバー
- バックエンドエンジニア 3 名
- フロントエンドエンジニア 3 名
- ただしフロントエンドを触るのではなく、バックエンドのコードを触る
- SRE 1 名
技術スタック
- バックエンド Go/go-chi/gorm/OpenAPI
- インフラ AWS/Terraform
利用ツール
- Claude Code（AWS Bedrock 経由）
- Cursor・JetBrains AI Assistant
なぜ Claude Code か
以下の理由から Claude Code を利用することにしました。
- 学習環境の統一
- 知見共有やサポートをしやすいように
- 実際に個人で試した際の完成度の高さと、社内有識者からの評価の高さ
- （他エージェントに比べ）高い自走力と実用性
- TODO リストを作成することによる問題解決能力の高さ
- ワンショットの精度の高さ
- Plan モードの完成度
- マルチモーダル対応
- MCP のサポート
しかし問題もありました。Claude Code は AWS Bedrock 経由で利用していますが、429 Too Many Requests エラーが頻発し、クォータ引き上げを申請しているところでした。
ツールが使えないと業務に支障が出るので、エラー時は Cursor・JetBrains AI Assistant へ切り替える 2 段構成にしています。
制約
本番環境バグの Hotfix のみ手動可。それ以外は禁止。
計測指標
- ユニットテスト・カバレッジ
- リードタイム（GitLab Merge Request Analytics）
- アンケート
行うタスク
- 複数の API 実装
- CI/CD パイプラインの整備
手動コーディング禁止祭にて気をつけた点
ツールを用意してはいどうぞと投げるのはあまりにも無責任なので、まずはお手本となるものを作らなければと考えました。
メンバーに社内向け MCP サーバを作るなど AI 活用が進んでいる @p_craftが居たので、普段どのように AI を使っているかのレクチャーを依頼しました。
レクチャーの場では質疑応答の場も設け、メンバーの習熟度にあわせたレクチャーができるようにしました。こうしてメンバーには社内向け MCP サーバーの利用方法をキャッチアップしてもらい、業務での利用をお願いしました。
お手本を用意してもわからないことがあると想定されたので、期間が半分すぎたタイミングで中間チェック地点として困りごとや質問事項をまとめる場を作りました。 そこで AI は何が苦手で、どのようなことに困っているのか、といった質問事項を共有し、相互に回答することで知見の強化に努めました。
その他にはメンバーの前では言いづらいこともあると考え、1on1 で不満点や問題点の確認も行いました。
以下は AI エージェントを利用して困ったことをいくつかピックアップしたものになります。
AI エージェント利用における困りごと
もっともらしい回答に惑わされ、判断が不安になることがある
この点は、ほぼ全員が困りごととして挙げていました。
特にフロントエンドが専門でありながらバックエンドのコードを書くことになったメンバーが強く感じていたようです。 自分の専門領域であれば AI の誤りを見抜くことができても、そうでない分野では不安を覚える場面が多かったとのことです。
これは本当に正しいのかと確認すると、嘘であったと平然と誤った情報を伝えることがありました。 このことから生成されたコードは裏取りが必須であるという認識がチーム内で共有されました。
生成された Terraform コードの品質に課題がある
この点は、バックエンドエンジニアや SRE から挙がった意見です。
Terraform に関しては生成されるコードの品質が低く、そのままではプロダクション環境で使うのは難しいという声が多くありました。 これは私たちのチームに限った話ではなく、他の SRE メンバーからも同様の指摘がありました。
最終的に GitHub などの公開リポジトリに高品質な Terraform の実装例の少ない点が、要因の 1 つだと考えるに至りました。
Git 操作に関する難しさ
多くのメンバーから挙がった課題のひとつです。
たとえば、git add . をそのまま使ってすべての変更をステージしてしまう、rebase の操作がうまくできないといった声がありました。
また AI は修正範囲をある程度認識するものの、意図や背景まで正しく理解させるには自然言語での補足が必要、という声もありました。
成果を測る指標と振り返り
やりっぱなしではなく今後他チームへ輸出するために成果指標と振り返りを行いました。
以下の 3 点を成果指標にしています。
- テストカバレッジ
- MergeRequest リードタイム
- 実施メンバーへのアンケート
テストカバレッジ
テストカバレッジは向上が見られました。これは予想どおりの結果でした。
クラウドサインではテストコードを書く文化が徹底されてされている点、AI によってテストコードを書く労力が減り、書いたコードに対してテストがほぼ網羅されるようになったからではと推測しています。
実際、テストカバレッジは 0.2% 向上しました。数値としては小さいものの、大幅な上昇がないこと自体は想定通りです。
テストカバレッジを指標にした理由としては、手動コーディングを禁止することで品質が低下しないかを確認したかったという意図があります。
そのため「カバレッジが下がらなければ十分」「わずかでも向上すれば上出来」という前提のもとで実施しており、今回の結果はまさに想定の範囲内でした。
MergeRequest リードタイム
今回参加した 7 名が作成した MergeRequest のリードタイムを GitLab Merge Request Analytics を利用して計測しましたが、明確な変化は観測されませんでした。これも意図した結果でした。
理由に以下の 3 点が考えられます。
AI 駆動開発の定着
今回実施したチームでは今回の施策前から ClaudeCode に加え、Cursor や Copilot も日常的に活用していたため、禁止による大きな変化はありませんでした。
働き方の変化
今スプリントでは、フロントエンドエンジニアがバックエンドのコードも書くことになり、バックエンドエンジニアはそのレビューに追われる状況でした。過去のスプリントとは働き方が異なるため、リードタイムを比較することが難しかったと考えています。
タスクの性質
今スプリントは API の作成など、すでに似たコードがあるものを作るタスクが中心でした。既存のコードに近いため、AI も迷うことなくスムーズに作成できたので生産性が下がることはなかったと推測しています。
1on1 でのヒアリングや後述するアンケートでも、比較的容易だったと答えたメンバーが多かったことも補足しておきます。
アンケート
対象となるメンバーにアンケートを依頼し、6 人のメンバーに答えてもらいました。
所感としては、コード生成を利用した AI 駆動開発は定着しつつあり、今後は DesignDoc・ADR などのドキュメント作成に活かしたいと考えている人が多い印象でした。
私がやりたかったこと
今回の 3 つの目標の中で、私が特にやりたかったことは、AI ファーストの思考に移ってもらうこと でした。
AI という便利なツールがなくなることはありえないと考えています。
昔では活版印刷、近代では鉄道や自動車、平成の世になってからはインターネットなど社会構造を変えるような技術革新が起きた際には必ず規制の動きが生まれます。 しかし一時的に停滞することはあっても、技術そのものの進歩は止まりません。
ここでは例として自動車の規制を挙げます。19 世紀のイギリスでは赤旗法という自動車の規制の法律が施行されました。歩行者の安全に配慮するという名目で施行された法律ですが、背景には馬車業界・地主のロビー活動がありました。しかし便利なものは止まりません。その後廃止されています。
抗うことが難しいのであれば適応して欲しい。その波に乗って欲しい。そういう意図で行った施策でした。
まとめ
すでに AI 駆動開発を行っていたため、明確なリードタイムの変化や大きな変化は観測できませんでした。しかし、比較的難易度が低いタスクを行うスプリントであったことも影響していると予想しています。これは意図した結果でした。
今後の業務で AI を第一選択肢とするかという問いに、多くの方が活用すると答えてくれました。私の狙いも一定の成果を得られたと感じています。
しかし、施策の率直な感想を聞いた問いには「楽しかった」だけではなく「課題はあるが楽しかった」という回答を頂いています。この課題については、今回の反省を踏まえて次回に活かしたいと考えています。
弁護士ドットコムでは AI を活用して次の常識をつくる人を募集しています。
