📝

Vibe Codingの"ストレス"を軽減した体験談

に公開
AI
Docker
TypeScript
Vibe Coding
Vibe Kanban
tech

初めまして！トグルホールディングス株式会社で新卒エンジニアをしている菊池です。

※こちらはtoggle Advent Calendar 2025の11日目の記事です。

「どうやったらVibe Codingを現実的にフル活用できるだろうか？」という問いをもとに書いていこうと思います！

「現実的に」というところが大事だと思っていて、「Vibe Codingをフル活用するためにはものすごく頑張らなければいけません」だと本末転倒ですし、正直腰が重いです。
そこで、まずは「Vibe Codingにまつわる"ストレス"を軽減することで、将来的なフル活用に繋げていきたい」という気持ちで記事を書きます。

概要

昨今、Vibe Codingの勢いが凄まじいです。というか、凄まじくないですか。

ただ、現場でエンジニアリングしていると「こんなことまでできるの！」と驚く一方、「全然思った通りに行かないじゃん、、、」とネガティブな印象も受けます。

Vibe Codingに寄った開発の、満足度の振れ幅が大きいわけです。今回は「どうやったらこの振れ幅を小さくできるか？🧐」という問題意識から、現実的なコストでVibe Codingをフル活用する1st ステップとして、「どうやったらVibe Coding関連の"ストレス"を軽減できるだろうか？🤩」という点についてお気持ち表明していこうと思います。

※この記事はNext.js/ Hono（Typescript）のコンテナ開発（devcontainer）の中で感じたことを書いています。そのため、他の仕様にも当てはまるかはわかりません、ご容赦ください🙏

Vibe Codingの落とし穴

当たり前のことですが、「私たち人間の目線」と「AIの目線」の違いについてまず整理します。

1. 見えているものの違い

  • 🙋‍♂️（人間）：「エディタ、ブラウザ、そしてデプロイ環境のコンソールもすべて見れます！」etc...
  • 🤖（AI）：「エディタ上のプログラムと、かろうじて標準出力（claude codeやcodexを開いているターミナル）が見れます、、、」etc...

例えば、web開発の場合人間はconsole.logとかを使いながらデバッグができますが、AIにコンソールは見れません。

詳細は次章「じゃあ、どうすれば。」で書きますが、この違いは

  1. そもそもAIが見えていなくても大丈夫な工夫をする
  2. 可能な限りAIが見えるところに色々置いてあげる

という工夫が有効だと思っています。

2. 前提知識の違い

  • 🙋‍♂️（人間）：「環境はARMのlinuxで、コンテナ開発をしていて、、」etc...
  • 🤖（AI）：「環境のOSは？CPUはAMD？わからん！」etc...

例えば、コンテナ開発をする場合、AIは「今いる環境がコンテナの中なのか外なのか」ということがわかりません。

こちらも詳細は次章ですが、

  1. そもそもAIが知らなくてもいい工夫をする
  2. 可能な限りAIにお知らせする

という工夫で対応ができると思っています。

じゃあ、どうすれば。

思想として、

  • ✅ AIができないことについて、『できなくても大丈夫な環境』を作る
  • ✅ 可能な限り、AIが確認可能なところで、必要な情報が完結するようにする

の２つが指針になると思います。以下、具体例で前章の「違い」について順番に書いていきます。

1. 見えているものの違い

AIに見えているのは、エディタ上のプログラムと、claude codeやcodexが開かれているターミナルのみです。

📕具体例1. やっぱりzodをフル活用しよう
https://github.com/colinhacks/zod

「人間は瞬時に確認できるのに、AIにはそれが難しい」というギャップの出現例として、

  • エディタエラー（Typescriptの型エラーなど）

    こういうやつ
  • クライアント（ブラウザ側）のエラー

    ここではこういうやつ

が、少なくともあると思っています。zodはどちらにもアプローチ可能です。

まず、エディタエラーについて。こちらは「見えていなくても大丈夫な工夫をする」に該当します。zodを使うと実行時にエラーをチェックすることができるため、型定義をz.inferを通じて行っておくと、AIはエディタエラーを見ることができなくても、実行時のzodErrorを通じて「何かしらおかしいことが起きている」ということを知ることができます。

気持ちとしては、「エディタエラーを見ることができなくても、zodErrorが見れていれば大丈夫だよ」という気持ちです。zodErrorは標準出力に吐き出すことができます。

次に、クライアントサイドのエラーについて。こちらは「可能な限りAIが見えるところに色々置いてあげる」に該当します。と言ってもとてもシンプルで、サーバー側でzodを通じたスキーマチェックを行っておけば、標準入出力を使ったデバッグでAIがエラーを直接確認することができます。

サーバー側（標準出力に色々吐き出してくれる側）に責任を寄せるイメージです。もちろん、サーバー側の関数をターミナルから実行するテストなどは用意しておく必要があります。

📕具体例2. 自作CLIを使おう
こちらは「可能な限りAIが見えるところに色々置いてあげる」に該当します。
nodejs開発の場合は、package.jsonがありますね。そして、package.jsonに書かれたコードはAIも確認可能です。

そして、例えばCommander.jsというパッケージがあります。
https://github.com/tj/commander.js

このパッケージを使うと、任意のコマンドを標準入力から実行することができます。

よって、

  • 🙋‍♂️（人間）：「@package.jsonを確認して、bun <所望の自作コマンド>を実行して、エラーを確認して」

みたいにしてあげると、AIが自身のセッションターミナルから指定の処理を実行 & 結果の確認をすることができます。GUIがなくてもいいところは、CLIで完結するようにする‼️という気持ちです。

テストコードを書くことも同様の取り組みだと思いますが、テストコードはそれだけで肥大化してしまうので、「CLIも準備しておくと都合が良かった」という体験談です。

📕具体例3. サーバーサイドを活用しよう
これについては特に思想が分かれるところかと思うので簡潔に。

「全てHTMLをサーバー側で生成してしまえばいいじゃない」という発想です。そうすれば、エディタ上に現れるエラーを減らし、標準出力から確認できるエラーを増やすことができます。

とは言え、これによって他の種類のエラーが出たりするので、バランスが大事だと思います😅 あくまで選択肢として。

2. 前提知識の違い

📕具体例4. 少なくともCIを整備しよう
「そもそもAIが知らなくてもいい工夫をする」に該当します。

いくらVibe Codingがすごいとは言え、Vibe Codingで頑張るのは現状マイクロサービスや駆け出しプロジェクトが多い印象です。

そしてこれらは、「規模が小さい」という理由からCI/CDを組まない（例えば手元でdocker build & pushして、デプロイ環境で手動デプロイなど）ことが往々にしてある気がします。あくまで私の主観です。

さて。AIは自身のいる環境を確認する術がありません。CIの文脈では主にARMとAMD、どちらのアーキテクチャのマシンに乗っているのかわかりません。これがわからないと、コンテナビルドで永遠にこけ続けるという事態になりかねません。

こうしたケースはCIを組み、「build環境をgithub actionsに統一する」という対策が有効でした。

もちろん、AGENTS.mdなどにこれらの事情を書いてもいいのですが、「いつかは組まなきゃいけないCIを序盤に組む」だけでVibe Coding上のかなりの煩わしさから解放されました。

📕具体例5. Docker開発の場合、設定を明記しよう
「可能な限りAIにお知らせする」に該当します。

  • ポートマッピングを明記する
  • ポートとアプリケーションをリンクさせる（vscodeの場合）

などが効果的でした。vscodeなどを利用していると、ポートマッピングはよしなにやってくれます。それが便利でもあるのですが、「よしなにやってくれている」ということをAIは知ることができないので、明記しておくと安全です。デバッグの際の検証事項が減ります。

「ポートとアプリケーションをリンクさせる（vscodeの場合）」については、例えばdevcontainer.jsonに

devcontainer.json
    "portsAttributes": {
      "3001": {
        "label": "API Service",
        "onAutoForward": "notify"
      }
    }

このように記述すると、「どのポートでどのようなサービスが立ち上がるのか」という点をプログラムに含めることができ、AIへの情報提供が可能となります。

人間にとっても、以下のような表示になって視認性がいいような気がします。

視認性には個人差あり

📕具体例5. Docker開発の場合doodに対応しよう
「そもそもAIが知らなくてもいい工夫をする」です。

コンテナ環境からdockerコマンドを使うとお馴染みの「デーモン動いてないよ」エラーに遭遇してしまいますが、AIは自身が「コンテナの中にいるのかいないのか」を確認することができません。

doodが全ての解決にはなりませんが、少なくとも「dockerコマンドを使うとき、コンテナの中か外かは知らなくていいよ」とAIをサポートすることにはつながります。

devcontainerの場合はfeatureでdoodがサポートされていて、
https://github.com/devcontainers/features/pkgs/container/features%2Fdocker-outside-of-docker
devcontainer.jsonのfeaturesに

devcontainer.json
"ghcr.io/devcontainers/features/docker-outside-of-docker:1": {}

のように記述するだけで、簡単にdoodに対応することができます。

最後に

もちろん上記の具体例でVibe Coding固有のつまずきを全て解消することはできませんが、

  • ✅ AIができないことについて、『できなくても大丈夫な環境』を作る
  • ✅ 可能な限り、AIが確認可能なところで、必要な情報が完結するようにする

この２つの思想は、指針として今のところ有用だと感じています。

もはや、私は「ベストプラクティスの網羅性」についてAIに及ばないです。あくまで私の話ですが。

また、頑張ってAIとプランを練ってAIに書かせてみたら、自分でもびっくりするくらい美しいコードが出来上がったという体験が以前ありまして、これをきっかけに「AIをフルで活用すればもっといいコードに出会えるかもしれない！」と思うようになりました。

最終的な品質保証はまだまだ人間の仕事だと思いますが、「保証すべき品質の、そもそもの高低」はAIの影響が十分にあるところだと思います。

はい。以上です！最後までお読みいただきありがとうございます！AIを使うのも大事ですが、エンジニアとしての「基礎筋力」をつける努力を怠らずに邁進していこうと思います。

Discussion