エンジニアとの協働でAIを使いすぎた — 非エンジニアが学んだ分業の境界線

医療特化のサービスを開発するプロジェクトで、エンジニアと分業してアプリを作ることになった。私がデザイン、エンジニアがプログラム。GeminiにGitを教わり、Claude Codeでデザインをtsxとして実装し、意気揚々とpushした。返ってきた言葉は「そこまでしなくていいです」。AIを使えば何でもできる時代に、「何をすべきか」を見誤った話を書いておく。

医療系アプリの開発に入った

前回、設計書を作ってからAIに渡すと結果が劇的に変わることを学んだ。その少し前から、別のプロジェクトが動いていた。

医療領域に特化したサービスを作るため、外部のエンジニアと協働してアプリを開発することになった。私がAIを使って一から作ろうと思っていたのだけれど、「医療はセンシティブな領域だし、デザインを担当してもらえると助かる」と言われ、

また、以前LINEのログインで苦戦した（その時はChatGPTに聞きながらやった）こともあって、プログラム領域はエンジニアが、デザインは私、と分業することになった。

（というか、エンジニアがデザインも全部やった方が速いんじゃない？と思ったけれど、エンジニアという人種は、すべからくデザインをやりたがらない）

プロジェクト管理はGitで要件定義を管理し、要件は全て .md ファイルに記載。MVPに含める機能は「IN」、Phase 2以降は「OUT」として表で整理されていた。3月24日のセミナー（150人規模）に合わせて事前登録を開始するのが当面の目標。

で、エンジニアからの依頼は明確だった。

別リポジトリ（Ready-NaaS-HTML）を作ってもらって、そこにシンプルなHTMLでデザインを組んでください。

「了解！」と威勢よく言った。

Gitがわからない — Geminiに聞く

「了解」と返事をしたものの、gitがよくわからない。

まずGeminiに状況を説明した。

コマンドまで親切に教えてくれる。優しい。

Geminiの説明に従って、エンジニアが構築したリポジトリをローカルにpullした。（これが後で間違いだったと気づく）

Claude Codeでデザインを実装する

ローカルにファイルを持ってきた。次に、デザイナーが作ったファイルと、Mermaid形式で書き出したFigmaの遷移図をClaude Codeに読み込ませる。

さらに、Claude Codeへの指示書もGeminiに書いてもらった。

指示内容もよくわかっていないまま、Claude Codeに投げた。

すぐにできた。

できたファイルを feature/design ブランチにpushし、エンジニアに報告。

feature/design ブランチに、A04画面pushしました。htmlをtsxとしてます。こんな感じでOKであれば他も進めます。

• docs/design/ → デザインの方向性
• src/components/ui/ → ボタンなど
• src/app/nurse/jobs/ → 実際の画面

別リポジトリではなく本番リポジトリのブランチで作業したことで、「統合の手間がゼロになり」大きなメリットがあるとgemini。

（エンジニアも「ここまでやってくれたんですか」と褒めてくれるだろうと思った）

「そこまでしなくていいです」

エンジニアからの返答はこうだった。

別のgitリポジトリを新しく立ち上げてもらってそこでシンプルなhtmlで組んでもらう想定だったんですが、それだとやりずらいですかね？

現在のリポジトリでやるなら /src/app/sandbox/design/* 配下で組んでもらうとかですかね。

シンプルなhtmlがあれば、デザインとstyle見れれば適用できるので

プレーンなHTMLをくれ。本番のディレクトリ構造に入り込まないでくれ。——そういうことだ。

Next.jsのtsxとしてコンポーネント分割し、UIライブラリまで組み込んで、feature/designブランチにpushした私の作業は、エンジニアの想定を完全に超えていた。超えていたというか、ずれていた。

協働作業って難しい。内実をわかっていないのに、AIが全てやってくれるから、勝手に突き進んでしまう。

やり直し — sandbox/designへ

やれやれ。Claude Codeにリファクタリングを指示した。

Claude Codeは指示通りにファイルを移動し、型定義やfetchを剥がし、シンプルなデザインデータに変換してくれた。これで、ひとまずエンジニアが求めていた形で共有できた。

AIでできることと、すべきことは違う

非エンジニアがエンジニアと協働する際のAIの使い方について、最も重要な教訓は「技術的にできること」と「チームとしてすべきこと」は別だということだ。AIがあれば、非エンジニアでもtsxのコンポーネントを組み、ブランチを切り、本番リポジトリにpushできる。技術的には可能だ。

だけど、エンジニアが求めていたのは「プレーンなHTML」だった。デザインとスタイルが確認できればいい。それを本番コードに統合するのはエンジニアの仕事であり、そこに非エンジニアが踏み込むと、かえって手間が増える。

今回の失敗で分かったことを整理すると、

最後の行が一番痛い。Geminiは技術的なアドバイスとしては正しかった。ブランチ運用の方が統合は楽だし、Next.jsコンポーネントとして渡した方がアニメーションも確認できる。でも、それは「エンジニアが求めていたもの」ではなかった。

AIに聞くべきだったのは「どうやって実装するか」ではなく、エンジニアに聞くべきだったのは「何をどの形式で渡せばいいか」だった。

前回は「設計書を先に作れ」が教訓だった。今回は「相手の期待を先に確認しろ」。AIは万能の助手だけれど、チームメンバーの頭の中までは読んでくれない。

（Notionでチケットを切る工程でもまた悩んだのだけれど、それはまた別の話）

参考文献

• AGIラボ (2026). "AI駆動開発のための非エンジニア向けGit/GitHub使い方ガイド." chatgpt-lab.com
• 株式会社AIworker (2026). "非エンジニアこそGitHubを活用すべき理由 — AI時代のコラボレーション革命." note.com
• Anthropic. "Claude Code Documentation." docs.anthropic.com