最初の試みは95%がゴミ：Claude Codeと歩んだStaff Engineerの旅

 (sanity.io)
24 ポイント 投稿者 GN⁺ 2025-09-03 | 5件のコメント | WhatsAppで共有
  • あるスタッフエンジニアが 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が開発者を置き換えることではない
    • 開発者が より速く作業し、より良いソリューションを開発し、最良のツールを活用すること

関連記事

5件のコメント

 
helio 2025-09-05

「こんなに精緻な手順なら、いっそ本人が直接コードを書いたほうがよいと思う」
 
skageektp 2025-09-05

チームメンバーに仕事を振らずに、自分で片づけるチーム長の姿勢ｗｗｗｗ
 
greenbhj 2025-09-05

そんな気もするが、実際にはまったくそうではない。
この6か月間、小規模・大規模の反復実験を行ってみた。
 
iolothebard 2025-09-05

小さくてもよく定義された機能を1つ選び、
AIにその機能を実装するチャンスを3回与え、
まるで新人開発者をメンタリングするように結果をレビューしてみること
私がいなくてもそれができるなら「得」だけど……私が必要なら……そのまま自分でやったほうが「得」だ。
 
GN⁺ 2025-09-03
Hacker Newsの意見

  • エージェントの認知的な限界を考慮して指示を出すことが重要だと感じる。たとえば大きな変更をいきなり求めるのではなく、まず計画を立ててから小さな段階に分けて実行を指示し、各段階をテストしながら進めるべきであり、複雑な段階では問題と解決策を可視化するコードを書かせるとよい。どこかの段階で失敗したらコードにロギングを追加し、ログを保存してからテストし、ログを見直して原因を把握する過程を繰り返し試すのが効果的だ。既存コードの設計方針を通じて、モデルにどこを変更すべきか把握させれば、AIがすべてを1つのファイルに詰め込むのを防げる。同様のコツを共有するブログをいくつも見たが、まだ完璧ではないとはいえ、95%がゴミのような結果になるほどではなくなったという感覚だ

    • 自分はこうしたことをすでに全部試しているが、それでも大半は使い物にならないコードが出てくるし、まともに動く場合でも結局は自分で手を入れてようやく使えるものになる。本当にうまく動くこともあるので、そのときは楽しいが、個人的には生産性向上をあまり実感していない
    • 大規模で複雑な作業では、「今すぐコードを書かないでください。これから各ステップを詳しく説明します」と指示するやり方が有効だと感じる。たとえば入力の読み込み、候補生成、候補のスコア付け、優先順位付けとソート、出力データ構造の生成、DBへの保存といった段階的な概要を示す。Claudeはこれらの段階をTODOリストやドキュメントとして整理し、次回も続けやすい形で管理してくれる。実際、1時間作業して中断したあと、「完了したステージはコード生成してコメントを残し、次回そこから続けよう」と指示すれば、簡単に連続作業できた
    • 複数のLLMやエージェントを長く使っていても、なお有用な結果を得るのは難しい。無駄な出力を避けるには、自分で作業する以上にプロンプト作成へエネルギーを使わなければならず、プロンプトの文言や口調、意図しない連想を起こさないよう気を配っていると、かえって不安になってくる。別のフロントエンドフレームワークのように、LLMプロンプトを管理するツールがあるとよいと思う。一般的なプロンプト構造を整理したり、ベストプラクティスをデフォルト適用したりして、コードから何かを探すときや新機能設計、テスト作成の際の悩みをかなり減らしてほしい
    • そんな精巧な手順を踏むくらいなら、自分でコードを書いたほうがよいと思う
    • 個人プロジェクトでAIとvibe codingを試してみたところ、テスト駆動開発のやり方がvibe codingとかなり相性がよかった。問題を小さくテスト可能な単位に分解し、まずAIにユニットテストを書かせてから実際のコードを実装する方法を勧めたい

  • こうした記事には、単純なリファクタリング作業やReactのボイラープレートではなく、実際に「エージェントが分散処理する」具体的な作業例を含めるべき時期だと感じる。Sanityには長年要望されてきた機能があるらしく、エージェントがかなりの量を並列化して処理すると主張している。しかし「コードの80%を学習しないジュニア開発者が書いた」といった主張は信じがたい

    • 自分としては、「学習しないジュニア開発者」という表現は不正確だと思う。Claudeはむしろ、実務経験はないが文献上の正解だけを知っている高学歴のシニアに近い。百科事典的な知識は卓越しているが、実戦感覚に欠ける。最近Claudeで商用コードベースを構築しているが、入力の大半は「コードの味」や成功の定義に集中しており、コード自体は使い捨てにすぎない
    • AIコードがこれだけ増えているのに、オープンソースには依然として未解決のissueが積み上がっている。この点は実に皮肉だ
    • 実際にAIへ任せた作業例と結果を見せてくれれば、誇張された期待に疑問を投げかける機会になるのに、実戦例がないままClaude Codeがすごいという話ばかりが上がってくる
    • セールス寄りになったエンジニアが、「lesson」ではなく「learnings」のような表現を使う技術ブログを見ると、開発経験を積むほどGoogle検索への依存が減り、単にドキュメントを確認するようになった自分の歩みとは逆だと感じる

  • 著者は生産性向上があるとは言っていたが、よく指摘される限界もそのまま挙げており、実質的にはあまり中身のない話だったように思える。誰も中核機能の開発をClaude Codeに委ねたりはしないだろうと確信している

  • ボイラープレートを避けることは開発者の仕事であり、未来の自分を楽にするための抽象化でもある。AIでボイラープレートを生成すると、後でその全インスタンスを一つひとつ変更しなければならないとき、かえって不便が大きくなるし、あちこちに散らばったボイラープレートコードが不一致なら問題はさらに深刻になる

    • フレームワークやツールの大半はすでにボイラープレート自動生成機能を含んでいるのに、わざわざAIにトークンとコストをかけてこれをやらせることに、そこまで大きな価値があるのか疑問だ

  • 興味深いのは、この人はAIで基礎実装を試しているのに対し、自分は逆に土台を必ず先に自分で構築することだ。そうすれば構造と動作原理を正確に理解でき、その後はAIに反復的なボイラープレートだけ任せればよい。AIはなぞって書くのは得意だが、アーキテクチャ設計には非常に弱い

    • LLMは保守可能なアーキテクチャを計画するのが非常に苦手だ。コードが進化していく中で構造をリファクタリングできず、文脈理解の限界がここにあるのかもしれない

  • 基本給だけでも高いのに、さらに月1000〜1500ドルの追加コストをかけて、生産性が上がるかもしれない些細な問題に投資すべきだという主張には疑問がある。少なくとも自分の上司は喜ばないと思う

    • ハードウェア業界では、開発者の人件費より高い各種EDAツールのライセンスを毎年購入している。もし生産性が目に見えて向上するなら、1000ドル程度は大した額ではない
    • 開発者の年収がそれほど高いなら、むしろ投資しないほうが不合理だ。月1k〜1.5kドルで生産性を確実に高められるなら、それをためらうほうが非効率であり、この観点からAI投資コストだけを取り上げるのはあまりに単純化された見方だと強調したい。AIで開発者数を減らせるなら、それもまた実際のコスト削減効果だ
    • 自分はintellij pro AIに月20ドルも使っていないので、Claudeが本当にそんなに高いのか疑問に思って調べたが、実際そういうこともありうるようだ。いずれにせよ、どこかの予算にAIのサブスク料金が追加されるのは現実であり、会社が高速インターネット回線の費用を払っているのと同じように、AIコストも基本費用になりつつある
    • そしてこの価格も実際には補助金ベースであることを忘れてはならない
    • 今後企業がどう変わるのか興味深く見ている。確かなのは、結局のところ開発者がどんな基準で評価されるかが肝心だということだ。AI使用によって人事評価や解雇などで不利益を受けるリスクが高まるのか、そして成果の主役がLLMではなく自分自身であることをどう証明するかが重要な論点になる

  • 本文で触れられていたMCP(Multi-Channel Processor)の活用方法がよく分からない。Claude codeはcurlやghなどを使ってシェルからほぼあらゆるサードパーティサービスを呼び出せるのに、MCPを使うとかえって問題が出ることもある（例: linear MCPサーバーはissueが長すぎると切り詰めるが、直接APIを呼べばその制限はない）。何か見落としている点があるのだろうか

  • AnthropicがBoris Cherny（Claude Codeの創始者）とのインタビューを公開しており、Claude Codeのエージェントコーディングの未来や活用法についてのアイデアも共有している https://youtu.be/iF9iV4xponk

  • 「月1000〜1500ドルの予算」という言及を見て、もしかするとAPIキーしか使っておらず、claude MAX のような月額定額プランを知らないのではと思った。月100〜200ドルなら、ただ闇雲にクエリを繰り返すのでなければ十分カバーできるはずだ

    • 1k〜1.5kドルは高すぎる数字だと感じる。20倍のMaxプランでも月200ドルでかなり多くの利用量をまかなえ、使用量は5時間ごとにリセットされる。それでも毎日上限を超えるなら、そのレベルではトークン従量課金のほうがむしろ高くつくかもしれない

  • Claudeやその他のエージェントを使うつもりなら、ロギングは絶対に強く勧めたい。ログファイル全体をAIに入れると、問題を整理して答えを得たり、次の段階に進めたりできる確率が高まる。ロギングは本当にすべてだ