2026年3月にクラウドワークスへ入社し、工数管理サービス「クラウドログ」を開発している小田です。
クラウドログの開発チームでのAIの使われ方をいくつか紹介しながら、入社して4ヶ月の私がどのように感じたかを書いてみたいと思います。コーディングではClaude Codeを、コードレビューにはDevinを中心に使っています。
以前はCursorとClaude Codeを併用していた時期もあったのですが、両方のスラッシュコマンドや設定をそれぞれ保守する負担があり、運用を一本化する観点からコーディングはClaude Codeに集約しました。選定にあたってチームが重視したのは、その時点でのモデルの精度そのものよりも、開発の方向性や将来の指針が明確に示されているかどうかです。あわせて、エディタに統合された局所的な補助よりも、プロジェクト全体を見て工程ごとに任せられるエージェント的な使い方が、現在のチームのやり方に合っていました。
生成AIをコーディングに使うこと自体は、当たり前になってきました。Planモードで段取りを立てさせたり、前提をドキュメントで渡したり、レビューを頼んだりと、個人でもかなりのことができるようになっています。その上で、クラウドログの開発チームに入って、これは個人ではなかなかできないな、と感じたものがありました。順に書いていきます。
その1：要件定義から実装までを工程化している
具体的な話に入る前に、技術スタックに少しだけ触れておきます。クラウドログのバックエンドはGo、フロントエンドはTypeScript/Reactです。
クラウドログの開発チームでは、機能をひとつ作る作業を、いきなり「実装して」と頼むのではなく、工程に分けて進めています。この工程化を担うのが、仕様駆動開発（SDD）のためのClaude Codeプラグイン crowdlog-sdd です。ひとつの開発項目は、次の流れで進めていきます。
/requirements（要件定義）→ /design（設計）→ /tasks（タスク分割）→ /implement（実装）→ /merge（統合）
各コマンドの裏には専門のサブエージェントがいて、前の工程の成果物が、そのまま次の工程の入力になります。要件定義の前には /steering により、プロダクトの概要・技術スタック・コードの構造といった前提を、あらかじめClaude Codeに持たせています。各工程の区切りには、成果物をレビューするコマンド（/review-requirements・/review-design・/review-tasks）も用意されています。ツール上はスキップもできる工程ですが、チームでは基本的にこのレビューも通すよう運用しています。
仕様の持ち方も二段構えで、開発中の差分（Level 1）と、製品全体の永続的な仕様（Level 2）に分かれています。要件や設計は文書としてリポジトリに残るので、後から見返せますし、誰でも同じ手順をなぞることができます。個人でも工程を踏むことはできますが、それを全員が同じ形で進め、成果物が残っていくのは、チームならではだと感じました。
crowdlog-sdd 自体もまだ発展途上で、複数リポジトリをまたいだ使用や、生成される資料の読みやすさ改善、定期的なフィードバック収集によるブラッシュアップなども今後やりたいこととして挙がっています。
その2：Devinのレビュー基準をチームで育てている
クラウドログでは、レビューの基準を集約しています。レビューガイドラインは ai-review という専用リポジトリに置かれ、Go・Reactといった技術ごとに用意されたものが、対象に応じて使い分けられる仕組みです。プルリクエストに ai_review とコメントすると、GitHub Actions経由でDevinが起動し、その基準に沿って指摘を返してくれます。指摘に付くのは、重大度に応じた5段階のラベルです。
- MUST：必ず直すべき問題
- IMO：改善提案
- NITS：軽微な指摘
- ASK：質問・確認
- IMH：良い点の指摘
各指摘は「問題点」「推奨する修正」「理由」の三段構成です。そして最後に、重大度スコア（0〜10）のサマリが添えられます。
さらにこの基準そのものを、定期的に見直す仕組みもあります。毎週きまった曜日に自動でDevinが起動し、レビューガイドラインの改善を実施します。基準は一度決めて固定するものではなく、運用しながら少しずつ整えていくもの、という扱いです。
改善案はDevinが出しますが、取り込むかどうかはミーティングで承認してから反映しています。Devinが勝手にルールを書き換えていくわけではありません。
この「基準を育てる」運用は、個人ではなかなか再現できないな、と思っています。基準を更新する材料になるのは、多くのプルリクエストや、複数人のレビューのやり取りです。それが日々流れていて、毎週見直して、人が承認して反映するという運用を続けられるのは、チームという単位だからこそだと感じています。
その3：安全な使い方を、チームで揃えている
Claude Codeに実装を任せるということは、ファイルの編集やコマンドの実行を任せるということです。コマンドの実行は対話形式で承認/否認ができますが、その判断を個人の注意力だけに委ねず、危険な操作を防ぐ設定をチームで共通化しています。
仕組みとしては、Claude Codeの「Managed 設定」（システム管理者向けの強制設定機能）を使っています。設定ファイル managed-settings.jsonに書いた内容で、機密ファイル（.env や秘密鍵など）の読み書きや、破壊的なコマンド（rm -rf、git push --force、sudo、dd、mkfs、terraform apply/destroy など）の実行を、あらかじめ禁止しておけます。Claude Codeの設定では、この「Managed設定」が個人の設定より優先される決まりです。そのため、うっかり個人設定で緩めてしまう、ということが起きにくくなっています。
ただし managed-settings.json の禁止設定は先頭一致で判定されるため、&& や ; でコマンドをつないだ場合にすり抜ける余地があります。そこでチームでは、Hooks（コマンド実行前に任意のスクリプトを差し込める仕組み）も併用し、コマンド文字列全体を検査して危険な操作を二重にブロックしています。
設定の実体は ai-settings という社内リポジトリに置き、managed-settings.json へはシンボリックリンクを張る構成です。これにより、リポジトリ側で設定を更新して git pull するだけで、全員の手元に同じ設定が反映されます。
おわりに
クラウドログの開発チームに入って面白かったのは、Claude Codeの「使い方」そのものをチームの共有物として扱っていることでした。工程の型も、レビューの基準も、安全な設定も、集約して全員に配り、運用しながら手を入れ続けている。特にレビュー基準を毎週見直す体制は、多くのプルリクエストとレビューが日々動いているチームだからこそ成り立つものです。個人で使っているだけでは、出てこない発想でした。
この記事が、Claude CodeやSDDをチームで使っていこうとしている方の参考になれば幸いです。
