Claude Codeは思考の壁打ち相手。AIが変える開発現場のリアルと設計思想
AIによるコード生成が現実のものとなって久しいですが、先日、社内で開催された「Claude Code 勉強会」で交わされた議論は、単なる「自動化」や「効率化」といった言葉だけでは語れない、開発の新たな局面を浮き彫りにしました。
本記事は、その勉強会での議論を元に、この新しいツールが我々の開発プロセス、特に設計思想やチーム文化にどのような影響を与え始めているのか、そのリアルな変化を、現場のエンジニアたちの生々しい声と共にお届けします。
設計フェーズ：思考のパートナーか、それとも原理主義者か？
勉強会は、ある機能開発チームのエンジニアA氏による発表から始まりました。
彼は、現在進行中の比較的大きな機能設計に、初期段階からClaude Codeを導入した経験を共有してくれました。
成功体験：Notionからシーケンス図への高速プロトタイピング
「正直、驚きました」とA氏は語ります。
彼のチームでは、まずNotionにユースケースやドメイン用語の定義を詳細に書き出しました。
そして、そのNotionページをPDFとしてエクスポートし、Claude Codeにこう指示したのです。
「このPDFの内容をすべて理解した上で、システムのシーケンス図をMermaid形式で、そして主要なAPIの設計書をMarkdownで作成してほしい」
通常であれば、数日を要する設計のプロトタイピング作業。
しかし、AIはわずか1時間半ほどで、構造化された設計図と仕様書の叩き台を生成したといいます。
大まかなユースケースが11個ある、割と複雑な機能だったんですが、AIが吐き出したシーケンス図は、ほぼそのまま使える精度でした。
このスピード感は、人間には真似できません。
課題①：DynamoDBの壁と「文脈」の重要性
しかし、議論はここから深まっていきます。
A氏は、成功体験だけでなく、明確な課題も指摘しました。
一方で、DynamoDBのテーブル設計は、AIの提案をそのまま使うのは難しかったですね。
彼が共有した画面には、AIが提案したスキーマ設計が映し出されていました。
例えばこのアクセスパターン、我々のユースケースでは全く想定していないクエリなんです。
それなのに、そのためのGSI（グローバルセカンダリインデックス）が提案されていたり。
主キーとソートキーの組み合わせも、本当に欲しいデータを効率的に取得できるものではありませんでした。
DynamoDBのパフォーマンスは、アプリケーションのクエリパターンという「プロジェクト固有の文脈」に強く依存します。
AIは汎用的なベストプラクティスは知っていても、その特定の文脈に最適化された解を導き出すのは、依然として人間のエンジニアの領域であるようです。
課題②：REST API設計における思想の衝突
API設計においても、興味深い議論が巻き起こりました。
AIが生成したAPI設計書に対し、エンジニアB氏が口を開きます。
AIが提案してきたのは、非常に教科書的で"原理主義"的なREST APIでした。
でも、例えば今回の機能にある『バッチ処理を開始する』という操作を、厳密なリソースモデルで表現しようとすると、かえって分かりにくなったりプロダクトの設計方針と競合しそうだと感じました。
この発言をきっかけに、「プロダクトの設計方針をClaude Codeに学ばせるよりは、より大衆的な方向へと設計方針を寄せていった方がよいのでは？」という議論に発展しました。
AIの提案は、我々がどのような設計思想に立ち、どこでプラグマティックな判断を下しているのかを、チーム内で改めて言語化し、共通認識を形成する良いきっかけとなったのです。
実装とテスト：「捨てられるコード」がもたらす開発速度
次にマイクを握ったエンジニアB氏は、AIとの協業がもたらす心理的な変化について、自身の失敗談を交えながら語ってくれました。
失敗談：AIの"ハルシネーション"を信じた結果
ある時、コンテンツポリシー違反をハンドリングする実装についてAIに相談したんです。
すると、ある特定のエラー形式を『OpenAIの公式仕様です』と自信満々に提示してきました。
B氏はその情報を元に実装を進めましたが、テスト段階でどうしてもうまくいきません。
おかしいと思って、後から公式ドキュメントを隅から隅まで確認したんですが、そんな仕様はどこにも存在しなかった。
AIがもっともらしく嘘をついていたんです。
あの時は、AIを鵜呑みにする怖さを実感しましたね。
発見：「捨てられるコード」という心理的安全性
しかし、この失敗談には重要な続きがありました。
結局、その実装はすべて無駄になりました。
でも、不思議と腹は立たなかったんです。
なぜなら、AIが書いたコードだったから。
何の未練もなくgit reset --hardで消し去ることができました。
この 「捨てられるコード」 という感覚は、開発の速度と心理的安全性を飛躍的に高める可能性を秘めています。
自身が時間をかけて書いたコードには、どうしても愛着や固執が生まれてしまいます。
しかし、AIが生成した叩き台であれば、より客観的に、そして気軽に破棄・修正ができる。
これにより、チームはより多くの実験的なアプローチを、より速いサイクルで試せるようになります。
AIとの対話術：忘れっぽい"新人"のマネジメント
議論は、AIをいかに「マネジメント」していくかという、より具体的なハック術へと移っていきました。
対話的要件定義という新たなワークフロー
B氏のチームでは、Jiraの曖昧なチケットを起点に、AIと対話しながら仕様を具体化する手法を試みています。
# まず、このようにAIに指示を出す
"Jira-450の件、具体化したいからヒアリングして"
するとAIが『対象サービスは？』『期待する挙動は？』と質問を返してくる。
この壁打ちを繰り返すことで、自分たちの頭の中も整理され、最終的に構造化されたIssueが出来上がるんです。
CLAUDE.mdとコンテキスト忘却問題
しかし、AIとの長い対話には課題もつきまといます。
プロジェクト固有のルールを学習させるCLAUDE.mdですが、そのコンテキストは永続的ではありません。
「セッションが長くなると、急に英語で話し始めたり、指示を無視したりするんですよ。それがコンテキストを忘れたサインですね」
「うちは『あなたはギャルです』という人格を付与しておいて、その口調が素に戻ったらリセット、みたいな涙ぐましい努力をしています」
会場からは、そんなリアルな苦悩の声が上がり、笑いが起こりました。
ツールの制約を理解する
また、調査の過程で「Claude CodeがOpenAIの公式ドキュメントにアクセスできない（403 Forbiddenが返る）」という制約も判明しました。
未来の協業：GitHub Actions連携の現在地
勉強会の最後には、エンジニアE氏が現在試みている「GitHub Actions」との連携事例が紹介されました。
Issueに「@claude please」とメンションするだけで、AIが自律的にコードを書き、プルリクエストを作成する。
まさに未来の開発風景です。
しかし、その道のりはまだ平坦ではありません。
「『フォーマットして』って何度もコメントしてるのに、次のコミットでも忘れてるんです」
「ひどい時には、コミットフックを--no-verifyで強引に突破されたこともありました。さすがに笑いましたね」
現状では、AIがCI/CDパイプラインやチームの暗黙的なルールといった文脈を完全に理解するのは難しいようです。
コードを直接書かせるよりも、Issueの壁打ちやレビューの叩き台作成といった、より上流の工程で対話的に使う方が、現時点での生産性は高いのかもしれません。
AIは銀の弾丸ではなく、思考を加速させる触媒であり、失敗のコストを下げるパートナーです。
その特性と限界を理解し、自分たちのワークフローに合わせていくエンジニアリングが求められます。
この少し忘れっぽいが優秀な"新人"と、あなたのチームならどう向き合いますか？
株式会社ガラパゴス（有志） 株式会社ガラパゴスのエンジニアを中心に情報発信をしている Publication です。 各記事の内容は個人の意見であり、企業を代表するものではございません。
Discussion