- あるスタッフエンジニアが Claude Code を活用し、AIと共に進める開発ワークフローを6週間にわたって実験した経験を共有
- AIを「学習しないジュニア開発者」と見なす考え方が、統合を成功させる鍵
- 最初の試みは大半が 95%失敗 だが、反復を通じて徐々に使えるコードへと磨かれていく
- プロジェクトごとのコンテキストファイル（Claude.md） と MCPベースのツール統合 を活用して、AIのコンテキスト不足の問題を解決
- 開発者の役割はコード記述から 問題解決とアーキテクチャ設計 へ移りつつあり、これはAI活用時代の新しい生産性パターン
背景とアプローチ
- 筆者はもともとすべてのコードを自分で書いていたが、最近では 80%をAIが記述 し、自身はアーキテクチャ、レビュー、マルチスレッド開発の管理に集中している
- この記事は「AIが革新を導く」という楽観一辺倒の論調ではなく、実際のプロダクション開発ワークフローにAIを統合する中で経験した混乱と、現実的な方法論 を共有するもの
- AIを「学習しないジュニア開発者」として扱うことが、効果的な活用の核心
開発パラダイムの変化の過程
- 最初の5年間は、本やSDKドキュメントを参照する開発スタイルを維持
- その後の12年間は、検索（Google）ベースの集合知活用 へ移行
- 直近18か月は、CursorによるAI支援コーディング を実験
- さらに直前の6週間では、Claude Codeを活用した全体的なAI委任 によって急激な変化を経験
- Claude Codeへの適応では、わずか数時間で生産性向上を体感できた
実際のAIベースのプロダクションワークフロー
- プロダクションに入るコード作業では、主にAIを「考えるため」に使っている
- 一度で完璧なコードを生成することは不可能であり、エンジニアとしての任務は問題に対する最善の解決策を見つけること
- 最初の試み（95%失敗）: AIがシステムの文脈を蓄積し、開発者が問題を特定する段階だが、コードはほとんど間違っている
- 2回目の試み（50%失敗）: 文脈理解が向上し、アプローチも具体化するが、それでも半分は使い物にならない
- 3回目の試み（実用コード）: 反復とレビューを経て、実際に使える土台コードが出てきて、その後さらに改善できる
- このプロセスは失敗ではなく、意図的に設計された実験と反復的最適化の過程 である
コンテキストの問題と解決策
- AIは セッションをまたいで記憶を保持できない ため、毎回同じ説明を繰り返さなければならないという限界がある
- 解決策として Claude.mdファイル を使い、アーキテクチャ上の判断、パターン、ドキュメントリンクなどを記録
- MCP統合によって、Linear、Notion、GitHub、コードベース、データベースと接続し、コンテキストを自動で提供
- Linear でチケットのコンテキストを提供
- Notion または Canvas でドキュメントにアクセス
- 非プロダクションデータベース でデータ構造を確認
- GitHub で過去のPRの背景情報を活用
並列Claudeインスタンス運用と中核戦略
- 複数のClaudeインスタンスを並列運用 しながら、「毎日メモリを失う小さな開発チーム」を管理する感覚で取り組んでいる
- 同じ問題領域では並列化しない、すべての作業をLinearなどのプロジェクト管理ツールに記録する、人間が直接修正したコードを明確に示す などの戦略を立てている
- コード記述だけでなく コードレビュー でもAIを積極活用しており、テスト漏れ、明白なバグ、改善点を素早く洗い出して反復作業を減らしている
- 自社（Sanity）の方針では、AIが生成したコードでも最終的な品質責任はエンジニアにある
- AIと人間の区別がつかないコード生成環境では、感情的な執着が減り、より批判的で客観的なコードレビュー が可能になる
3段階のコードレビュープロセス
- コードを書くことが仕事の一部であるように、コードレビューもまた仕事の一部である
- 1次レビュー：Claudeによる初期レビュー
- テストカバレッジの漏れ と明白なバグを検出
- 改善提案によって同僚のレビュー時間を節約
- 2次レビュー：自分でレビュー
- 保守性、アーキテクチャ、ビジネスロジック、統合性 を確認
- AI生成コードであってもエンジニアが 最終責任 を負う
- 3次レビュー：チームの通常レビュー
- どの部分がAI生成コードかは知らされない。同一の品質基準 を適用
- 感情的な執着 なしに客観的なレビューが可能
- AIが書いたコードには 情緒的な執着が薄いため、客観的なレビュー がしやすい
Slackトリガー型エージェントと業務自動化の実験
- CursorでSlack連携エージェント をパイロット導入し、単純なビジネスロジック修正には成功したが、複雑なCSSレイアウトには失敗した
- 現時点では、非公開NPMパッケージ未対応、署名なしコミット、公式トラッキングの迂回 などの制約がある
- それでも、単純な反復チケットをエージェントが夜間に処理する将来像には期待している
コストとROI
- Claude Codeの利用コストは、会社がエンジニアに支払う額としても決して小さくない
- しかし、その投資によって生産性向上の効果が得られている
- 機能リリース速度が2〜3倍向上
- 複数の開発スレッドを同時管理可能
- 反復的・ボイラープレートなコードを自分で書く必要がなくなる
- AI導入初期には、シニアエンジニアに月$1000〜1500の予算 が必要で、習熟が進むほどコスト効率の改善が期待される
AI支援開発の継続的な問題と限界
- 学習の問題: AIはミスから学べず、同じ誤解を繰り返すため、対策としては充実した文書化と明示的な指示の強化が必要
- 信頼の問題: AIは誤ったコードを自信満々に提示するため、必ず検証が必要であり、特に複雑な状態管理、性能、セキュリティ領域では注意を強めるべき
- コンテキスト限界の問題: 大規模コードベースはAIのコンテキストウィンドウを超えるため、問題を小さく分割し、明確なコンテキストを与えることが必須
コードから問題への感情的変化
- コードへの執着を手放し、問題解決中心の思考 へ転換
- 誤ったコードを素早く削除 でき、より客観的なレビュー ができ、リファクタリングへの負担 も減る => 前向きな変化
- より優れたAIツールが出ればすぐに乗り換える意向がある
- 本質は「コードそのもの」ではなく、解決すべき問題の価値 である
エンジニア視点でのAI導入アドバイス
- 1. 複数のAIソリューションを試せるようにする: チームがさまざまなツールを実際に使い、実務能力を高める必要がある
- 2. 反復的で単純な業務からAIを適用する: 早い効果が期待できる
- 3. 試行錯誤の予算を確保する: 最初の1か月は混乱を受け入れる必要がある
- 4. レビュープロセスを再設計する: AIコードの特性に合わせたチェックを強化する
- 5. 徹底した文書化: 優れたコンテキストが生産性を倍増させる
- 新しいAIワークフローに適応するエンジニアは、道具箱に 新しい鋭いナイフ が加わったことに気づくだろう
- AIワークフローを受け入れるエンジニアは、複数のAIエージェントをオーケストレーションしながら、アーキテクチャ、レビュー、複雑な問題解決に集中する新たな役割へと進化 していく
あなたの次のステップ
- 小さいが明確に定義された 機能を1つ選び、
- AIにその機能を 実装する3回のチャンス を与え、
- まるで 初心者開発者をメンタリングするように結果をレビュー してみよう
- それで十分。大きな変化も、プロセス改編も必要ない
- 必要なのは 1つの機能、3回の試行、そして率直なレビュー だけ
- 未来とはAIが開発者を置き換えることではない
- 開発者が より速く作業し、より良いソリューションを開発し、最良のツールを活用すること
まだコメントはありません。