はじめに
ログラスでエンジニアをしているナカムラ（@nakamura_meg)です。今回は、チームで実施した「Claude Code Week」の取り組みについて、得られた知見を共有します。
※Claude Code関連の資料は一番下にまとめました
なぜ今、強制的な変革が必要なのか
Anthropic社のCEOであるダリオ・アモデイの発言が現実味を帯びてきました。
「今から3～6か月もすれば、AIがコードの90%を書いている世界になる」
「12カ月（1年）後には、ほぼすべてのコードをAIが書いている世界になるかもしれない」
ログラスには「経営管理」「人員計画」という比較的大規模な既存事業のプロダクト開発チームと、新規事業開発を行う小規模な開発チームが多数存在します。Cursor等のAI駆動開発は、これまで主に新規事業チームで大きなインパクトをもたらしていました。
しかし、私が所属する既存事業の人員計画チームでは「AI主導で開発をする」ことは、Cursor導入時点でもまだ難しいと感じていました。長年培われた複雑なドメイン知識、暗黙知な部分も多いコーディングルール、深いコンテキスト理解が必要な業務フローが存在するからです。従来のAIツールでは、これらの制約により「補助的な活用」に留まっていました。
そこで私は次の仮説を立てました。「既存事業でゲームチェンジを起こすには、開発フローを明確に変える必要があり、そのためには強制的にAI-Nativeな環境を作ることが不可欠である」。個人の自発的学習に頼るのではなく、チーム全体で確実にAIと向き合う機会を創出することが鍵だと考えました。
参考になったのは、CTOがエンジニアのコーディングを禁止した事例やMercari PCP LLM Weekでした。これらの取り組みでは短期的な生産性低下があったものの、組織全体のAI活用能力向上という長期的価値が確認されていました。
Claude Code Week
Claude Code Weekとは、既存事業の人員計画チームにおいて、Claude Code以外の開発作業を一切禁止することで、エンジニア自身が開発フローをどのように再構築するか検証する実験です。特別なタスクではなく実際の開発業務で実施し、同じ制約下で作業することで個人の判断に左右されない環境を構築しました。
劇的な開発速度向上
従来1日かかっていた作業が30分で完了しました。朝に「人間の手では1日かかる」と言っていた作業が、昼前には完了する体験は大きな驚きでした。チームメンバーからも「想像以上の生産性向上だった」という声が上がりました。
並列開発の実現
これまで不可能だった同時並列作業が現実になりました。一人のエンジニアが新規開発タスクの実装を進めながら、同時に複数タスクのリファクタリング、UI/UXの小規模改善、ディスカバリーリファインメントの技術調査を並行して行えるようになりました。従来の開発スタイルでは考えられない変化で、個々のエンジニアの守備範囲が大幅に拡大したことを実感しました。
参加者の声
シニアエンジニアの発見
Claude Codeを効果的に活用するためには、探索と計画が極めて重要であることが分かりました。特に印象的だったのは、Claude Code自身に振り返りをさせる手法の効果です。「どういう指示をしていたら良かったですか？ドキュメントに追加した方が良いことがあれば教えてください」と問いかけることで、プロンプトの改善点やドキュメントの不足箇所が明確になりました。
開発フローの変化については、内部品質をAIが担保し、V字モデルの各フェーズごとにモデルを使い分ける可能性を感じています。今後人員計画で活用していくためには、全職種でのAI活用を徹底し、ひたすら使い込むことが重要だと考えています。
新卒エンジニアの気づき
実際に手を動かしたことで、Claude Codeの使い方や良さが肌で分かりました。
「探索→計画→実装→コミット」の4ステップが超重要であることも発見でした。最初にどのファイルやルールを参照すべきか丁寧に確認と計画するだけで、実装の精度が大きく上がります。また、ルールは「完成形」ではなく、更新して育てていくものだと理解しました。今あるルールにも抜け漏れがあり、発見したら迷わずアップデートする必要があります
新たな課題
暴走リスク
一度に実装する物量が膨大になる傾向があり、適切な制約がないと必要のない機能まで次々と追加してしまいます。「できるから作る」という発想になりがちで、本質的な要求からの乖離リスクが生まれます。
コンテキスト理解の限界
プロジェクトの複雑な依存関係や暗黙的な要件の把握が困難で、既存事業特有のドメイン知識やビジネス制約の理解が不足しがちです。その結果、「技術的には正しい」が「ビジネス的には不適切」なコードが生成される可能性があります。
エンジニアの説明責任
これまでのレビュープロセスでは追いつかない生成速度に対して、「このコードがなぜ正しいのか」をエンジニア自身が説明できる必要があります。AIの力を借りながらも、最終的な責任と判断はエンジニアが担う必要があり、品質保証からエンジニアによる品質証明への進化が求められています。
これらの課題から、次のフェーズで必要になるのは「AIの力を最大限活用するためのガードレール」の構築です。これまでAIの力を最大限活用する方法を模索してきましたが、これからはAIの力を最大限活用するためのガードレールを構築することが重要になると感じています。
三層制約
これらの課題を解決するため、私は「AIの力を最大限活用するためのガードレール」として、三層制約が必要だと感じました。弊社CTOいとひろが関数型祭りで提案した「形式手法とAIの組み合わせ」をベースに、Claude Code Weekの実践を通じて発展させたアプローチです。
ビジネス制約層（BDD）でAIの理解を導く
※ BDDについてはこちらを参照ください
書店の在庫管理を例に、AIが正しく動作するためのガードレールを考えてみましょう。まず最上位層では、ビジネスルールを自然言語で明確に定義します。これによりAIは「何を実現すべきか」を正確に理解できます。
Feature: 書店の在庫管理と注文処理
Scenario: 在庫がある本の注文
Given 書店に「Kotlin Guide」が5冊在庫としてある
When 顧客Aliceが「Kotlin Guide」を2冊注文する
Then 注文は正常に受け付けられる
And 「Kotlin Guide」の利用可能在庫は3冊になる
Scenario: 同時注文による在庫競合の防止
Given 書店に「Scala Book」が1冊在庫としてある
When 顧客Aliceと顧客Bobが同時に1冊ずつ注文する
Then 1つの注文のみが確定される
And もう1つの注文は在庫不足エラーとなる
このBDDシナリオをAIに与えることで、「在庫がある場合は注文を受け付け、適切に在庫を減算する」「同時注文では一方のみが成功し、もう一方はエラーになる」といった期待される振る舞いを具体例として示せます。AIはこれらの具体例から、システムがどのように動作すべきかを理解し、適切なコードを生成するよう導かれます。
論理制約層（形式手法）でAIの論理を制御する
次の層では、形式手法によってシステムの論理構造を数学的に定義します。これによりAIが生成するコードの論理的一貫性を保証できます。
sig Book {
isbn: ISBN,
title: String,
price: Money
}
sig Inventory {
book: one Book,
stock: Int,
reserved: Int
} {
stock >= 0 // 在庫は0以上
reserved >= 0 // 予約数は0以上
reserved o.quantity else 0 |
let currentStock = sum inv: Inventory |
(inv.book = b) => inv.stock else 0 |
totalOrdered Alloyによるこのモデルは、AIに対して「在庫は0以上でなければならない」「予約数は在庫数を超えてはならない」「注文総数は在庫を超えてはならない」といった数学的制約を与えます。AIはこれらの制約に違反するコードを生成できません。
実装制約層（型安全）でAIの出力を制限する
最下位層では、型システムによってAIが生成できるコードの形を制限します。これにより実行時のエラーを防ぎ、不正な状態遷移を型レベルで排除できます。
sealed class OrderStatus {
object Pending : OrderStatus()
data class Confirmed(
val confirmedAt: Instant,
val reservedInventory: Reservation,
val approvals: NonEmptyListApproval>
) : OrderStatus()
data class Shipped(
val shippedAt: Instant,
val trackingNumber: TrackingNumber,
val carrier: ShippingCarrier,
val previousState: Confirmed
) : OrderStatus()
object Cancelled : OrderStatus()
}
fun Order.ship(
trackingNumber: TrackingNumber,
carrier: ShippingCarrier
): EitherOrderError, Order> =
when (val currentStatus = this.status) {
is OrderStatus.Confirmed -> {
val shippedStatus = OrderStatus.Shipped(
shippedAt = Instant.now(),
trackingNumber = trackingNumber,
carrier = carrier,
previousState = currentStatus
)
Either.Right(this.copy(status = shippedStatus))
}
else -> Either.Left(OrderError.InvalidTransition(
"Cannot ship order in ${currentStatus::class.simpleName} status"
))
}
このような型定義により、AIは「Pending状態の注文を直接Shippedにできない」「必要な情報が欠けた状態では処理を続行できない」といった制約の中でコードを生成します。型システムがAIの創造性を適切に制限し、安全なコードのみを生成させるのです。
三層制約による完全なガードレール
この三層アプローチの真価は、各層が相互に補完しながらAIを導くことにあります。BDDでビジネス要求を明確化し、形式手法で論理的整合性を保証し、型安全性で実装レベルの安全性を確保する。これにより、AIは「技術的に正しく、ビジネス的に適切で、論理的に一貫したコード」のみを生成できるようになります。
従来のAI活用では「生成されたコードをレビューで修正する」アプローチでしたが、この制約設計では「正しいコードしか生成できない環境を作る」アプローチに転換します。これこそが、AI時代における新しい品質保証だと感じています。
（補足）Claude Codeのベストプラクティス
Explore, Plan, Code, Commitワークフローの実践
今回の実験で、Anthropic公式が推奨する4ステップワークフローの威力を実感しました。
1. Explore（探索）
関連ファイルを読み込み、現状を理解することから始めます。「@components/UserList.tsx を読んで、まだコードは書かないで」といった指示で現状把握に専念します。「まだコードは書かないで」という制約が重要で、これがないとClaude は即座に実装を始めてしまいます。
2. Plan（計画）
思考モードで実装前の計画を練ります。「この認証システムの問題をthink hardで分析して、改善計画を立てて」といった指示で、複雑さに応じて think を使い分けます。計画は必ずドキュメント化し、後から判断根拠を振り返れるようにします。
3. Code（実装）
計画に基づいて段階的に実装します。「計画に従って、まず認証部分から実装して。各ステップでテストが通ることを確認して」といった指示で、小さな変更を積み重ねます。
4. Commit（確定）
変更内容を整理してコミットし、ドキュメントを更新します。「変更を論理的な単位でコミットに分けて。README.mdも更新して」といった指示で、チーム全体での知見共有を図ります。
このワークフローの最大の価値は、ステップ1と2（探索と計画）です。これらを飛ばすとClaude は即座にコーディングを始めてしまいますが、事前の理解と計画により、最終的な解決策の品質が大幅に向上することを実感しました。
効果的な指示パターンの発見
今回の実験で、AIとの協働において最も重要なのは「曖昧さの排除」であることが明確になりました。曖昧な指示は、AIにとって毒です。具体的で制約の明確な指示こそが、期待通りの結果を生み出します。
曖昧な指示 vs 具体的な指示
| タスク | 曖昧な指示（✗） | 具体的な指示（✓） |
|---|---|---|
| 在庫管理テスト | 在庫テストを書いて | 書店在庫システムの同時注文テストを作成。「在庫1冊の本に対し2人が同時注文した際、1つのみ成功し、もう1つは在庫不足エラーになる」を検証して |
| 注文API最適化 | 検索を速くして | 書籍注文APIの応答時間を500ms以下に短縮。現在の実装を調査後、booksテーブルにインデックス追加、N+1クエリ解消、を段階的に実装 |
| 型安全な状態管理 | 状態管理を改善して | 注文状態遷移（Pending→Confirmed→Shipped→Delivered）を型安全に実装。各状態で許可される操作のみ実行可能にし、不正な遷移は型レベルで防止して。 |
組織知の蓄積メカニズム
Claude Code Weekで最も価値のある発見の一つは、AI自身にプロジェクト固有のコーディングルールを作らせることの効果でした。従来の静的なルール定義ではなく、Claude がプロジェクトのコンテキストを理解した上で最適化されたルールを生成することで、人員計画システム特有のドメイン知識が自然とコードに反映されるようになりました。
現在、私たちはCLAUDE.mdからcursor-rulesを読み込む仕組みを使っています。これにより、チーム固有の開発パターン、ビジネスロジック、コーディング規約が一元化され、新しいメンバーでも即座にプロジェクトのルールに沿った実装ができるようになりました。
重要なのは、これらのルールをClaude自身に作らせることです。「現在のコードベースを分析して、このプロジェクトに最適なコーディングルールを生成して」といった指示により、プロジェクトの実情に即したルールが生成されます。人間が書いた抽象的なルールより、AIがコンテキストを理解して作ったルールの方が、結果的に一貫性の高いコードを生成することを実感しました。
Ruleの詳しい実装方法や具体的な効果については、弊社エンジニア佐藤の発表資料をご参照ください。
Claude Code Weekを通じて、既存事業においても「補助的な活用」から「開発プロセス変革」への転換が十分に実現可能であることが実証されました。AIの能力は予想を大幅に上回り、適切な制約設計により既存事業でも高品質なコード生成が可能であることが分かりました。また、強制的な環境構築による集合知の加速効果が確認できました。
単純にAIにコードを書かせることではなく、数学的制約でAIを導き、人間は高次判断に集中するという新しい協働関係の構築こそが、AI時代の開発の本質だと確信しています。
既存事業においても「補助的活用」から「プロセス変革」への転換は十分実現可能です。皆さんの組織でも、ぜひ「AI Week」のような取り組みを試してみてください。制約設計によりAI以外の開発手法を一時的に制限し、個人ではなく組織単位での取り組みとして、特別なタスクではなく日常業務で実践することをお勧めします。専用チャンネルでの継続的な学習コミュニティ構築も効果的です。
これからも継続的な検証と改善を続けています。AI時代の開発について、ご意見やご質問があれば、ぜひお聞かせください！
AIについて語りたい方、ご興味あればお気軽に連絡いただけると嬉しいです。
参考資料
Claude Code Weekで読んだ資料の一部
公式ドキュメント
関連記事・ブログ
Views: 0
