サイドバー実装で実演。これが生成AIの開発の現実

生成AIは「打ち出の小づち」ではない

「GitHub Copilot使えば、プログラミング知識なくても開発できるらしい」「ChatGPTに頼めば、コード書いてくれるから楽だよね」

こういう話、最近よく聞きませんか？

確かに、生成AIは驚くほど高品質なコードを生成してくれます。私も日

常的にGitHub Copilotを使っていて、その便利さは身をもって実感しています。

でも、それは「打ち出の小づち」ではありません。

今回、Next.js 15で作っているブログサイトに、PC版のサイドバーを追加するという、ごく普通のタスクをCopilotと一緒にやりました。要件はシンプル。「記事一覧ページにあるサイドバーを、記事詳細ページにも追加する」。ただそれだけ。

結果として、3回やり直しになりました。

「サイドバー追加して」→ 位置が逆「位置を左に」→ まだ何か違う「記事一覧と同じレイアウトに」→ ようやく完成

ビルドは毎回通ります。表示も一見問題ありません。でも、細かい部分で「何か違う」が積み重なっていました。

この経験を通じて痛感したのは、生成AIでのコーディングには、設計の知識や運用経験が絶対に必要だということ。

AIが生成したコードが「動く」ことと、それが「正しい設計」であることは、まったく別の話です。その違いを見抜けないまま開発を進めると、後で取り返しのつかない技術的負債を抱えることになります。

これが、生成AI時代のコーディングの現実です。

今日は、この「打ち出の小づち」神話を解体しながら、AIとどう向き合うべきか、実際の体験をもとに書いていきます。

そもそもやりたかったこと

要件はシンプルです：

PC版の記事詳細ページにサイドバーを追加したい
サイドバーには記事カレンダーと広告を表示
スマホでは邪魔なので非表示
記事一覧ページと同じ見た目にしたい（これ重要）

最後の「同じ見た目」が曲者でした。私の頭の中では当たり前すぎて、最初Copilotに伝え忘れたんですよね。でもこれ、経験のある開発者なら「デザインの一貫性」として当然考慮する部分です。

第1ラウンド：とりあえず追加してもらった

Copilotは即座に反応して、記事詳細ページにサイドバーコンポーネントを追加してくれました。記事一覧ページの実装を参考にしてくれたみたいで、Sidebarコンポーネントの呼び出し方も完璧。日付の取得ロジックも追加してくれて、「お、やるじゃん！」と思いました。

// こんな感じで追加された
<div className="flex gap-6">
  <div className="flex-1">
    <Article {...article} />
  </div>
  <Sidebar articleDates={articleDates} />
</div>

ビルドも通るし、表示も問題なし。一見完璧に見えました。

ここで問題：ビルドが通る = 正しいコードではない

初心者の方は特に注意が必要です。TypeScriptのエラーが出ない、ブラウザで表示される、これだけでは「良いコード」とは言えません。設計の一貫性、保守性、ユーザー体験、こういった観点を人間が判断する必要があります。

第2ラウンド：あれ、位置が逆？

実際にブラウザで確認してみると、なんか違和感があります。記事一覧ページと記事詳細ページを行き来してみると...

私：「サイドバーの位置、逆じゃない？」

そう、記事一覧ではサイドバーが左側にあるのに、記事詳細では右側に表示されていたんです。Flexboxの順序の問題でした。

// 修正後：サイドバーを先に配置
<div className="flex gap-6">
  <Sidebar articleDates={articleDates} />
  <div className="flex-1">
    <Article {...article} />
  </div>
</div>

Copilotはすぐに理解して、コンポーネントの順序を入れ替えてくれました。

「よし、これで完璧！」...と思ったんですが。

ここで問題：既存ページとの一貫性をAIは考慮しない

経験のある開発者なら、実装前に「記事一覧ページのレイアウトを確認して、同じ構造にしよう」と考えます。でもAIは、明示的に指示されない限り、既存コードとの統一性を自動的には考えません。これが「設計の知識」が必要な理由です。

第3ラウンド：なんかまだ違う

サイドバーの位置は直ったけど、まだ違和感が消えません。記事一覧と記事詳細を何度も行き来して、ようやく気づきました。

私：「レイアウトは記事一覧ページと合わせてほしいな」

ページ全体の幅が違ってたんです。

// 記事一覧ページ（正しい）
<div className="flex-1 w-full lg:max-w-7xl mx-auto px-2 sm:px-4 lg:px-6">
  <div className="flex gap-6 py-4">
    <Sidebar />
    <main className="flex-1 min-w-0">
      {/* コンテンツ */}
    </main>
  </div>
</div>

// 記事詳細ページ（Copilotの実装）
<main className="w-full lg:w-4/5 p-2 sm:p-4 mx-auto">
  <div className="flex gap-6">
    <Sidebar />
    <div className="flex-1">
      {/* コンテンツ */}
    </div>
  </div>
</main>

記事一覧ページはlg:max-w-7xlで最大幅1280pxに制限されているのに、記事詳細ページはlg:w-4/5でビューポートの80%になっていました。だから、ウィンドウサイズによって記事一覧と記事詳細で表示幅が変わる。これが違和感の正体でした。

さらに、余白の設定も微妙に違っていました。記事一覧はpx-2 sm:px-4 lg:px-6と細かくレスポンシブ対応してるのに、記事詳細はp-2 sm:p-4だけ。セマンティックHTMLの構造も違っていて、外側のタグの入れ子が逆になっていました。

Copilotに「記事一覧ページと同じレイアウトにして」と改めて依頼したら、ようやく完全に一致したコードを生成してくれました。

ここで問題：細かい違いを見抜くには経験が必要

lg:max-w-7xlとlg:w-4/5の違い、px-2 sm:px-4 lg:px-6とp-2 sm:p-4の違い。これらがユーザー体験にどう影響するか、理解するにはCSSの知識とレスポンシブデザインの経験が必要です。初心者には「動いてるからOK」に見えてしまう危険性があります。

なぜCopilotは最初から正解を出せなかったのか？

ここで冷静に振り返ってみました。Copilotが悪いわけじゃないんです。むしろ、私の指示が不十分だったんです。でも、この「不十分さ」を補うには、設計の知識が必要です。

理由その1：「局所最適」に陥った

最初の依頼「サイドバーを追加して」は、文字通り「サイドバーを追加する」というタスクでした。Copilotは忠実に、記事詳細ページの既存構造を尊重しながら、最小限の変更でサイドバーを追加しました。

記事一覧ページのSidebarコンポーネントの使い方は参考にしたけど、ページ全体のレイアウト構造までは参照しなかったんです。「サイドバーを追加する」という局所的なタスクに集中した結果、ページ全体の一貫性という大局的な視点が抜け落ちました。

人間の開発者だったら、「記事一覧にもサイドバーあるよな。じゃあ同じ構造にしとくか」って自然に考えますよね。でもAIは、明示的に言われないとそこまで推論しないんです。

これが危険な理由： 初心者は「局所的に動く」ことに満足してしまい、システム全体の一貫性を見落とします。後で別の開発者が触った時に「なぜここだけ構造が違うんだ？」となり、保守性が下がります。

理由その2：暗黙の前提を共有できない

私の頭の中では「記事一覧と同じレイアウトにする」は当たり前でした。だって、同じサイトなんだから統一感は必要ですよね？

でもCopilotには、この「当たり前」が伝わっていませんでした。人間同士なら共有できる暗黙の前提、デザインの一貫性という常識が、AIには理解できなかったんです。

結局、最後に「記事一覧ページと同じレイアウトに」と明示的に伝えてようやく、期待通りの実装が得られました。

これが危険な理由： 経験のない開発者は、そもそも「デザインの一貫性」という概念を知らない可能性があります。AIが生成したコードを疑問なく受け入れてしまい、統一感のないUIが完成してしまいます。

理由その3：段階的指示の罠

「サイドバー追加」→「位置を左に」→「レイアウト統一」と、段階的に指示を出しました。各段階でCopilotは忠実に修正してくれましたが、全体像を理解する機会がなかったんです。

最初から「記事一覧ページと同じレイアウト構造で、左側にサイドバーを追加してください」と言っていれば、一発で正解に辿り着けたはずです。

パッチワーク的に修正を重ねるより、全体像を最初に伝える方が効率的だと学びました。

これが危険な理由： 段階的な修正を繰り返すと、コードが「継ぎはぎ」になります。各修正は局所的には正しくても、全体として見ると一貫性のない設計になる危険性があります。リファクタリングのタイミングを見極める経験が必要です。

人間の開発者なら、どう違っただろう？

この経験を通して、人間とAIの違いが鮮明に見えてきました。かつて私は、AIコーディングは初心者レベルではないが初級レベルのコーダーと表現しました

初級以上の開発者に「記事詳細ページにもサイドバー追加して」って頼んだら、たぶんこう返ってきます：

「記事一覧と同じレイアウトでいいですか？それとも何か変えます？」

確認質問が来るんです。暗黙の前提を明示化してくれる。

でもCopilotは、質問してきません。与えられた指示を忠実に実行するだけです。だから、指示が曖昧だと、AIなりの解釈で実装してしまう。

人間なら「既存コードの意図」を推測します。なぜ記事一覧はmax-w-7xlなのか、なぜ余白はレスポンシブ対応なのか、そういう背景を考慮して、一貫性のある実装をします。

AIは、そこまで深く考えません。指示された部分だけを見て、最小限の変更で対応します。

これが現場の現実： 生成AIツールは、コードを書くスピードは圧倒的に速いです。でも、「正しい設計」を判断するのは人間の仕事です。レビューできる知識がなければ、一見動くけど保守性の低いコードが量産されます。

では、AIとどう付き合えばいいのか？

この経験から学んだ、AIとのコミュニケーション術をまとめます。でも、これらを実践するには、ある程度の開発経験が必要です。

その1：最初の指示を超具体的に

「サイドバーを追加して」じゃなくて、

「記事一覧ページのpage.tsxと同じレイアウト構造・スタイルで、記事詳細ページにもサイドバーを追加してください。サイドバーは左側に配置し、外側のコンテナはlg:max-w-7xlで、px-2 sm:px-4 lg:px-6とpy-4の余白を設定してください」

くらい具体的に。

でも、これができるのは：

Tailwind CSSのクラス名の意味を理解している
レスポンシブデザインの設計経験がある
既存コードの構造を読み解ける

という前提があるからです。初心者には無理な注文です。

その2：参照すべきファイルを明示

「記事一覧ページのpage.tsxを参考に」と明示すると、Copilotはそのファイルの構造をコピーしてくれます。

「似たような実装がここにあるよ」って教えてあげるだけで、精度が格段に上がります。

でも、これができるのは：

プロジェクトの構造を把握している
どのファイルが参考になるか判断できる
コードベース全体を俯瞰できる

という経験があるからです。

その3：期待する構造を見せる

コードの構造をMarkdownで書いて見せるのも効果的です。「こういうHTML構造にしてね」って具体例を示すと、Copilotは正確に再現してくれます。

でも、これができるのは：

HTMLの構造設計ができる
セマンティックHTMLを理解している
どういう構造が保守しやすいか知っている

という設計の知識があるからです。

その4：段階的修正より、一気に完成形へ

細かい修正を繰り返すより、最初に完成形のイメージを伝えて一気に実装する方が、結果的に速くて正確です。

AIは文脈を記憶していますが、段階的な修正の積み重ねは混乱を招きます。

でも、これができるのは：

完成形を最初から設計できる
要件を整理して言語化できる
システム全体を俯瞰できる

という設計力があるからです。

結局、AIは使えるのか使えないのか？

結論から言うと、設計と運用の知識がある人には強力なツール、ない人には危険なツールです。

今回の件で、AIは人間の常識や暗黙知を理解できないことがよくわかりました。でも、それはAIの欠陥じゃなくて、コミュニケーション方法の違いなんです。

人間には曖昧な指示でも通じますが、AIには明確で具体的な指示が必要。ただそれだけのことです。

逆に言えば、「明確な指示を出す」というスキルは、人間のチームメンバーとのコミュニケーションにも役立ちます。「あれやっといて」じゃなくて、「このファイルのこの部分を、この構造で実装して」と具体的に伝える習慣。

AIとの協働を通じて、私たちはより良いコミュニケーターになれるのかもしれません。

でも、危険なのは：

設計の良し悪しを判断できない人がAIを使うこと
生成されたコードをレビューできる知識がないこと
「動いてるから正しい」と思い込んでしまうこと

これらのリスクは、現場で深刻な問題になりえます。技術的負債が蓄積し、後で大規模なリファクタリングが必要になるかもしれません。

まとめ：AIは道具、使いこなすには知識が必要

GitHub Copilotは強力な開発パートナーです。でも、魔法の杖じゃありません。

「こう書いてほしい」と思ったら、その思考を言語化する必要があります。暗黙の前提を明示化し、期待する結果を具体的に伝える。そうすれば、Copilotは期待以上の働きをしてくれます。

でも、それができるのは経験と知識があるからこそです。

今回の「サイドバー追加」という単純なタスクで、3回もやり直しになった理由は、私の指示が不十分だったから。でも、その「不十分さ」に気づけたのは、既存コードとの違いを見抜く経験があったからです。

初心者が同じ状況に陥ったら、第1ラウンドで「完璧！」と満足してしまう可能性が高いです。そして、統一感のないUIが完成してしまいます。

これが生成AI開発の現実です：

コードの生成は速い
でも、設計の判断は人間の仕事
レビューできる知識がないと危険
「動く」と「良い」は別物

生成AIツールは、経験豊富な開発者をさらに生産的にしてくれます。でも、経験の浅い開発者には、むしろリスクになる可能性があります。

だからこそ、これからの時代はAIを使いこなすための設計力・運用知識がますます重要になると感じています。

AIは、私たちをより良い開発者にしてくれるパートナーなのかもしれません。でも、そのためには、まず自分自身が「良い開発者」である必要があるんです。

TriTry