はじめに

2026年4月から7月末までの4ヶ月間、ある大きめの機能の実装において、コード生成の大部分を AI (Claude Code) に任せる形へ本格的にシフトしました。

結論から書くと、AIに実装を任せるとは実装の責任を手放すことではありません。実装から解放された分の時間を、実装以外の判断に振り向けることです。 逆に言えば、判断の側を手放した瞬間に、この進め方は成立しなくなります。

この記事では、4ヶ月間で「何をAIに任せ、何を人間が握り続けたのか」「握り続けるために何が必要で、何を失ったのか」を記録します。対象の領域に固有の話は極力省き、一般化した視点で書いています。

前提

• とある Web サービス全体に関わる新機能を追加しました。
• 新機能の要求整理から始め、要件定義・技術選定・設計・詳細設計を1人でリードしました。実装やテストなども担いました。
• 本記事の内容は詳細設計と実装フェーズにおける AI 活用の記録である。

アーキテクチャ

• AWS 上に構築。
  • マネージドサービスを組み合わせたストリーム処理 + サーバーレス構成。
• SDK を作成。対応言語は Go と TypeScript

何をAIに任せ、何を握ったか

この4ヶ月で実際にやっていたことは、次の切り分けに集約されます。

重要なのは、最初に骨組みを組む部分だけは慎重にレビューしつつ、きちんと自分で組み立てたことです。ここを握っておくと、以降はAIが生成するコードの量が増えても、「設計の意図から外れていないか」という一点で判断できるようになります。

コードを1行ずつ追うのをやめた

実装が進むにつれ、AIが生成するコードの量も増えていきます。それを1行ずつレビューするのは早々に非現実的だと気づき、「要点だけ確認する」「設計だけは自分が握っておき、コードの細部はAIに委ねる」 というスタイルに切り替えました。

これはレビューを怠ったのではなく、レビューの対象を「コードの正しさ」から「設計との整合」に移したということです。これにより、生成量の増大に確認コストが引きずられて疲弊する、という状態を避けられました。

AIレビューは「判断材料」として使う

AIレビューを使う中で、同じレビューツール・同じコードでも、与えるコンテキスト (何を伝えるか) によって指摘される観点が変わることに気づきました。自分では気づかなかった観点が出てくることもあり、コンテキストの与え方次第でレビューの網羅性が変わります。

つまりAIレビューは正解を出す装置ではなく、判断の材料を増やす装置です。何を判断したいかに応じてコンテキストを設計する必要があります。

その結果、何に時間を振り向けられたか

実装をAIが引き受けてくれたことで、人間側の時間の使い方が変わりました。

• 段階的にAIへ移行し、3ヶ月で実装をやり切れたこと
  • 4月にコード生成の大部分をAIに任せる形へ移行し、そこから3ヶ月で基盤・SDK・サービスへの組み込みまで完了できた。
  • 人間側は設計や仕様の詰めなど、AIに任せきれない部分へ集中する時間を確保できたのが大きい。
• スケジュールへの焦りが薄れた
  • 実装の大部分をAIが引き受けてくれることで、「自分の手が足りずに間に合わない」という物理的な制約からくる焦りをあまり感じずに進められた。
  • 元々の実装スケジュールに対して大きく遅れることなく進行できた。そのため、進捗そのものへの不安よりも、設計や仕様の詰めといった任せきれない部分へ意識を向ける時間を増やせた。
  • どんなに細かいレビュー内容や方針転換レベルのものであっても、余裕を持って受け入れることができ、品質向上につながった。
  • 結果として、精神的な負担が軽い状態で実装フェーズを終えられた感覚がある。
• 実装後リファクタリングの時間を取れたこと (バグバッシュ)
  • 実装自体の時間が短くなったことにより、1工程ごとのレビューに加えて、実装完了後の全体レビューをAIで行う取り組みをチームで実施した。これによりリリース前に大量のバグや考慮漏れ事項を潰せた。
  • これは他メンバーが率先して進めてくれたもので、PRごとの細かいレビューではなく、アーキテクチャを通したレビューを実施してもらったもの。

これらはすべて「実装以外の判断に時間を振り向けられた」という1つの話です。速くなったのではなく、判断に使える時間が増えました。

一方で、判断の土台は薄くなった

ここが一番書いておきたい部分です。AIに実装を任せると、判断の材料になる「コードベースの解像度」が下がります。

• コードベース全体を「頭の中で地図化する」感覚が薄れた
  • 実装のかなりの部分をAIに任せた結果、自分自身がコードベース全体をマッピングしきれていない、という感覚が生まれた。長年触ってきた別のコンポーネントは頭の中に概念地図があるのに対し、今回AI主導で作った部分は「詳細設計は理解しているが、それがコード上でどう表現されているかは分からない」という状態になりがちだった。AIが一時的に使えない期間にコードを読み返す機会があっても、この地図の薄さを痛感する場面があった。
• 複数言語・複数実装への機能追従が漏れた
  • 1つの機能をまず片方の言語で実装し、後からもう一方へ移植する進め方を取った際、モノレポ構成であっても「片方にしか存在しない機能」に気づかず実装してしまうケースがあった。AI・人間問わず、移植作業では明示的な機能パリティチェックの仕組みがないと漏れが起きやすい、という気づきである。
• トークン消費量が増加し、要因の特定が難しかった
  • 実装が進むほどトークン消費量が増えていったが、何が主要因かは推測の域を出なかった。心当たりとしては、レビュー系のコマンドを多用していたことや、長期間にわたる同一セッションの利用などが挙げられるが、実測はできていない。

地図が薄い状態では、判断の根拠が「設計書の記憶」だけになり、コードの現状と切り離されます。 機能パリティの漏れはその典型です。モノレポという構造は本来、判断を助けてくれる情報のはずでした。しかし、それを読む解像度が落ちていたために気づけませんでした。

参考: トークン消費量の推移

この数字は厳密な比較指標ではなく、コードベースが育つほどコンテキストの読み込みやレビューにもコストがかかることを示す参考値です。定額制のプランであったとしても、基盤が育つにつれてレートリミットに近づく実感があります。

判断を維持するために、次はこうする

• AIに実装を任せていても、定期的にアーキテクチャ全体を自分で整理し直す時間を確保する
  • 読むだけでなく、自分の手で再構成してみることで、コードベース全体の把握度を維持する。これは判断の土台を自分で作り直す作業である。
• 重要な変更には、コンテキストを変えて複数回AIレビューを走らせてみる
  • コンテキストの違いで指摘の網羅性が変わるため、うまく活用できれば見落としを減らせそうである。
  • 確率論的な挙動で有益なレビュー内容が現れることもある。何回か行うことで品質の向上が見込める。
• トークン消費量の内訳を実測したい
  • レビュー系コマンドや長期セッションが本当に主要因なのか、ログベースなどで確認する方法を考案したい。今後トークン消費の削減が求められる場面も増えると想定されるため、費用対効果を意識したい。

おわりに

AIに実装の大部分を任せることで、実装速度だけでなく精神的余裕や品質の面でも大きな効果がありました。ただしそれは、判断を握り続けたうえで、実装を手放したから得られたものです。

そして、今回うまく進んだ背景には、AIだけではない要素があります。要件定義から設計までを一貫して把握し、1人でリードしていたため、実装中に生じた細かい穴などはその都度自分で判断できました。裏を返せば、分業を前提とした従来の進め方には、こうした判断のたびに人を介するコストが生じていたということでもあります。設計の理解がないまま実装だけをAIに任せても、同じ結果にはならないはずです。

また、AIが出てきたことでやはりエンジニアとしてただ実装だけをしていれば良い、という時代は終わったという認識を、本プロジェクトを通して強く持つようになりました。今後チーム構成やメンバー役割なども大きく変容していくのだろうと感じています。