エムスリーテックブログ

エムスリー(m3)のエンジニア・開発メンバーによる技術ブログです

あえて二度手間することで取り戻す、AI時代のコーディングの楽しさ

Vibe Coding 生成AI

はじめに

エムスリーテクノロジーズの永江 (@yukinagae)です。

最近はAIエージェントを使った開発が当たり前になってきました。CLIだけでもClaude Code / Gemini CLI / Codex CLI など多くのツールが登場し、開発効率の向上を日々実感しています。実際、Claude Codeを使うと趣味開発のスピードが数倍に上がり、1週間かかるものが数時間で完成することもあります。

さらに、コーディング用途だけでなくDia / Comet / Gemini in Chrome といった、ブラウザとAIが一体化したツールも次々と登場しています。エンジニアリング以外の業務効率化も、これから一段と加速していきそうです。

自分自身もプライベートでDiaを使い始め、その便利さを感じ始めています。そこで試しに、Chrome拡張でDiaのようにサイドパネルからAIを使えるプロトタイプを作ってみました。数回プロンプトを投げるだけで、想像以上に完成度の高いものができあがり、今まで数日かかっていた開発がたった1時間に短縮されました。「作りたいものをすぐ形にできる」体験は本当に素晴らしいと思います。

サイドパネルAIチャット プロトタイプ

しかし、同時にモヤッとする感覚も残りました。思ったように動いているし、コードも見た印象そこまで問題ありません。なぜかスッキリしない。思い通り動いているのに手応えがない。コーディング自体の楽しさが半減しているような感覚。

この記事では、その感覚の正体を掘り下げていきます。

AIエージェント時代の開発体験

まずは、今回試したことを紹介します。

作ったのは、サイドパネルを開いてAIとチャットできるシンプルなChrome拡張です。
最初にClaude Codeに投げたプロンプトはこちらです。

※WXT というChrome拡張のフレームワークを採用しました。

wxt.dev

sidepanelにChatGPTのようなチャットのUIを作成してください。

これだけでサイドパネルにチャットUIが自動生成されました。

モック版のチャットUI

もちろん、この時点ではまだモックなので、実際にOpenAI APIを呼ぶように変更してもらいます。

OpenAIのAPIを実際に呼ぶようにしてください。

「ハードコードでも良いかな」と思ってましたが、ちゃんとAPIキーを受け取る入力フォームを作成してくれて気が利いています。内部的にもOpenAIのAPIを叩く処理が追加されていました。

OpenAIのAPIキーを受け取る入力フォーム

さらに、せっかくブラウザ拡張を作ったので、開いているタブのHTMLをそのままAIに渡せるようにしてみます。

開いているページのbodyの内容を`@body` 参照してOpenAIに渡せるように変更してください。

これで、ページの内容をAIに直接渡しながらチャットできるようになりました。

完成版のデモ

ここまでわずか30分。 完成したコードは以下で公開しています。

github.com

やはりAIエージェント開発はすごいですね！ Happy Vibe Coding!

. . . (´・ω・｀) . . .

とはならず、なんだかモヤッとした感触が残りました。

違和感の正体

では、このモヤモヤの正体は何だったのでしょうか？

従来の開発プロセスを思い出してみます。

学習 → 理解 → コーディング → 試行錯誤 → 動作確認

調べて、理解して、手を動かして、エラーと格闘して、ようやく動く。 個人差はあると思いますが、多くのエンジニアは似たような流れでコーディングしていると思います。

実際には一方通行ではなく、「試行錯誤」してやっと「理解」できる、「コーディング」している途中で新しい気付きがあり「学習」する、などこれらのフローを行き来することがよくあります。

一方、AIエージェントを使った開発はこうなっていました。

プロンプト指示 → コーディング（AI） → プロンプト再指示 → 動作確認

大きな違いがあります。 従来あった「学習」「理解」「試行錯誤」のプロセスがごっそり抜け落ちているのです。

コードはたしかに動くし、読めば理解はできます。

しかし、自分の血肉になっていない。頭で「わかった」つもりでも、身体で覚えていない。 まるで答えを見ながら問題集を解いているようで、理解度も達成感も半減している感覚がありました。

速すぎる開発の落とし穴 — 効率と楽しさのトレードオフ

効率化は確かに正義です。業務では速く作ることが価値につながります。しかし、エンジニアにとってコーディングは単なる手段ではないと思います。少なくとも自分にとっては「新しいことを学び・理解する」プロセスが重要だったと気づきました。

では、AIに任せっきりの開発プロセスは何が問題なのでしょうか。整理してみます。

ノウハウが溜まらない

「とりあえず動くコード」は手に入りますが、理解度が浅いため、次に同じ問題に出会ったときにまたゼロから調べ直しになります。自分でコーディングしていれば「ここはこういう仕組み」と体感で覚えているので、次はすぐ応用できます。

トラブルシューティングできない

バグが出ても、どこを疑えばいいか分かりません。 試行錯誤を経験していないぶん、感覚的な肌感をつかめていないためです。自分で書いたコードなら、設計の意図や処理の流れを理解しているので、手探りでも原因に近づけます。

メンテナンスが辛い

AIに生成してもらったコードは、自分のコードなのに他人のコードのように感じます。どこを直せばいいか分からず、結局もう一度AIに聞くことになります。すると、さらに理解から遠ざかり、ますますブラックボックス化していくため、悪循環に陥ります。

これでは、短期的には効率が良くても、長期的な成長や楽しさを失ってしまうと思いました。

二度手間開発という遠回り

そこで考えたのが「二度手間開発」です。やり方は以下のようにシンプルです。

  1. まずAIで最短で開発する: Claude CodeやCursorにプロンプトを投げて、まずは動くものを作る
  2. 次に自分で0から作り直す: 1のコードを見ずに、自分の理解で設計・実装する

これによって、AIは「チートシート」や「模範解答」の役割になります。分からないときは答えを見て、もう一度自分で解き直すことができます。もちろんAIのコードをあえて参考にしない、ということもできます。判断はエンジニア自身に任せられます。

心理学ではこれを生成効果（Generation Effect）と呼ぶようです。答えをただ覚えるのではなく、自分で考えて解く・答えリストを作るなど、自分で「生成する」ことで記憶が定着するそうです。

AIを効率化ツールとしてだけでなく、学びのプロセスの一部として使うことで、楽しさと学習機会を取り戻せるのではないかと思います。

やり直して気づいたこと

試しに、AIが作った拡張機能はそのままで、新たに自分で0から作り直してみました。するとその過程でいくつか具体的な気づきや学びがありました。

WXTの設定がシンプルである理由

sidepanelはpermissionsに明示しなくても動く仕様になっていました。以下の公式ドキュメントを読むと、popupやsidepanelなどはエントリポイントを追加すると自動的にManifestにpermissionが追加されるようです。ただし、storageなどはもちろんエントリポイントが無いので明示的にpermissionに追加する必要があるようです。

When a sidepanel entrypoint is present: The sidepanel permission is added.

see: https://wxt.dev/guide/essentials/config/manifest#permissions

1回目は「なぜ動くのか分からない」状態でしたが、今は理由が説明できるようになりました。

OpenAI APIを叩く処理で不要なコードがある

OpenAIのAPIを叩く処理でstream/非stream両方定義されていて、非stream版は使われていませんでした。もちろん、この点はコードを読むだけですぐにわかることですが、自分で書いた場合とAIが書いたコードを読む場合では、前者の自分で書いたほうが問題に気づきやすいと思います。

UXを良くするアイディアが出てくる

当初のAIが生成したコードでは、ツールバーアイコンを右クリックして「Open Side Panel」でサイドパネルを開いていました。ただ、コーディングしていろいろ触っているうちに「そもそもツールバーアイコンをクリックしてサイドパネル開いてほしい」とUX上の課題を感じ、調べてみると以下のように background.ts に書けばいいだけでした。

export default defineBackground(() => {
  browser.runtime.onInstalled.addListener(() => {
    browser.sidePanel.setPanelBehavior({ openPanelOnActionClick: true });
  });
});

see: https://developer.chrome.com/docs/extensions/reference/api/sidePanel?hl=ja#open-action-icon

1回目にAIにコード生成してもらった時にはブラックボックスだったものが、2回目に自分でコードを少しづつ書いていくことで気づきや学びがありました。

二度手間開発の始め方

実際にやってみて分かった「二度手間開発のコツ」をいくつか紹介します。

  • AIのコードはあえて読まない: 動作確認だけして、AIのコードはできるだけ読まないほうが良いです
  • コメントアウトではなく新しいプロジェクトを作る: 完全に真っさらな環境で作り直すと、理解が深まりやすいです
  • 分からないときだけAIを見る: 本当にわからない・困った時だけAIのコードを見てみるのが良いです

まとめ

AIエージェントは素晴らしいツールですが、効率化に全振りし過ぎると学ぶ機会やコーディング本来の楽しさを犠牲にしてしまうことがあるというのを体感しました。

だからこそ、あえて遠回りしてみるのが大事だと思います。

  • 一度目はAIに作らせて最短距離で動かす
  • 二度目は自分で作り直して理解を取り戻す

We are hiring !!

エムスリー/エムスリーテクノロジーズでは、グループ会社の技術支援を担うエンジニアを募集しています。生成AIを活用した技術課題から事業全体の課題まで、多種多様でチャレンジングな環境があります。

少しでも興味を持った方、ご応募お待ちしています！

jobs.m3.com