「次は、何をすればいいですか？」
いま思えば、筆者のバイブコーディングは、この一文との長い付き合いでした。夜、仕事机でChatGPTの入力欄にこれを打ち込み、返ってきた手順を上から順にこなし、エラーが出たら画面の赤い文字を全文コピペして「どうすればいいですか？」と泣きつく。この繰り返しで、ホームページをひとつ作り上げました。
それが最近、Claude（クロード）というAIの登場、正確にはClaude Codeという開発ツールの登場で、筆者の夜の過ごし方は一変します。いまの筆者は、AIが10個のファイルを書き換え、テストを回し、「終わりました」と報告してくるのを、腕を組んで眺めています。そして開口一番、「本当に？」と疑ってかかる。我ながら、ずいぶん嫌な上司になったものです。
今回は、Web開発未経験でバイブコーディングを始めた筆者が、個人的バイブコーディングの変遷を実体験ベースでご紹介します。黎明期では素人コーダーとChatGPTの二人三脚で悪戦苦闘し、現在ではClaude Code内の複数エージェントと筆者との「チーム」が組織されるに至るまで、「作り方」と「人間の仕事」がどう変わったかを書いていきます。（そもそもお前は誰だ、という方は自己紹介をご覧くださいませ。）
黎明期 ― AIは博識な相談相手。手を動かすのは、自分
まず、黎明期の作り方から。題材は、筆者が実際に未経験から作ったホームページです。筆者はARCHECOのホームページをリニューアルする仕事でコーダーデビューを果たしました。構成はNext.js（Webサイトの骨組みを作る仕組み）、Cloudinary（画像の置き場所）、MongoDB（データの保管庫）。いまでこそ横文字をスラスラ並べられますが、当時の筆者にはすべて呪文でした。
手順は、だいたいこうです。
- ChatGPTに「HPを作るには、どんな作業が必要ですか」と作業を列挙させる
- 列挙された環境構築を、ひとつずつ「最適なやり方はどれですか」と相談しながら進める
- デザイナーさんが、サイトのデザインをFigma（デザイン共有ツール）で作ってくれる
- 管理画面から編集したいコンテンツを整理して、データベースの設計をChatGPTに相談して決める
- Figma経由もしくはChatGPTにデザイン画像を共有することでタタキ台のコードを生成してもらい、対話しながら見た目と挙動をチマチマ直す
- データベースの中身と、HPの表示を繋ぎ込む
文字にすると整然としていますが、実態は一問一答の千本ノックです。AIの答えをコピーして、エディタに貼る。動かない。エラーを貼る。直したコードが返ってくる。また貼る。今度は別の場所が壊れる。……この往復を、来る日も来る日も繰り返しました。
この頃のAIは、たとえるなら「事務所から一歩も出ない、ものすごく博識な顧問」でした。何を聞いても即答してくれる。でも、現場には来ない。資材（コード）を運ぶのも、組み付けるのも、養生するのも、ぜんぶ筆者です。おかげで、いま家のどこを建てているのかだけは、嫌でも理解できるようになっていきました。全体の工程表は、AIではなく筆者の頭の中にしかなかったからです。
特に「厳しいな」と感じたのは、複数のページが出来上がってきて、全体構成を見渡したときでした。
上記の方法でChatGPTに「資材」を作ってもらうとき、具体的には千本ノックの果てに出来上がったコードをチャット欄にコピペして、「このコードを参考に、〇〇のような機能のコンポーネントを作成してほしい」と数珠つなぎに新たなコードを作成していきます。こうすることにより千本ノックが発生する可能性を少しでも下げることができます。まぁ現実問題として、素人の筆者にはそれ以外の引き出しが無いのでこのような手法を取らざるを得ないとも言えます。悲しい、、、
そしてこの、「素人コーダーによるお手本数珠つなぎ」戦法では、以下のような問題が発生します。
各ページやコンポーネントに最適な手法が適用されない
これは、「お手本ファイルを参考に」という余分な指定が介入するため、実際に作りたい機能や挙動に対して、最適な手法が選ばれる可能性を自ら削ぎます。
「お手本」がどんどん過去のものになっていく
コーディングデビューほやほやの筆者が、やっとの思いで作り上げたお手本となるコンポーネント。それをお手本にコンポーネントを作り続けていくうちに、見慣れたエラーが起きたときに、「こうやったら直ったよなぁ」と記憶の糸を辿ってAIに指示をして、エラーを防いだコンポーネントが出来上がる。これをお手本に次へ、、、というように、プロジェクト制作が後半に進むに連れてお手本の精度は上がっていくのです。このとき「ん？」と悪寒を感じた方は鋭いお方です。プロジェクト前半で作成した過去の「お手本」コンポーネントには、エラーを起こしまくるポテンシャル満載なコードが残っている訳です。これを振り返って1つ1つ見直しを掛けることを考えるとおぞましいですよね…
Claude Code到来、まずコピペが消えた
転機は、そのホームページを作っている途中でやってきました。Claude Codeへの乗り換えです。
Claude Codeは、チャット画面のAIと違って、こちらのパソコンの中で直接働きます。ファイルを自分で開いて読み、書き換え、動作確認まで自分で回す。あの博識な顧問が、ついに現場へ降りてきて、道具箱を開けたのです。
最初に消えたのは、コピペでした。コードを運ぶのは、もう筆者の仕事ではありません。
筆者の場合、Claude Codeを使用する前はVisual Studio Codeというコードエディタを使って、ChatGPTが出力したコードをコピペして反映させていましたが、Claude Codeは自分のデスクトップなどの環境にあるコード一式、つまりプロジェクトのソースコードやパッケージ全体を把握し、必要に応じて追加や削除、編集をしてくれます。
次に消えたのは、あの「作業の列挙」でした。「管理画面から編集できるお知らせ機能が欲しい」と一言伝えると、データベースの設計から画面、保存の処理、動作確認まで、段取りごと進めてくれる。こういう働き方は「オーケストレーション」と呼ばれます。指揮者が楽団を振るように、たくさんの作業を束ねて同時に進めてくれる訳です。千本ノックのアツい日々の働き方からすると、メジャーリーグの代打の切り札になったかのような気分です。
気づけば筆者は、コードをほとんど書いて（運んで）いませんでした。筆者の仕事量は大きく変化しました。しかし、どんなに優秀なAIが味方についたとしても、筆者の役割が全く無いかというと、そうではありません。
人間の仕事は、「書く」から「決めて、疑う」へ
いまの筆者の仕事は、突き詰めると2つしかありません。
ひとつは、思い切って決めること。選択肢と根拠は、AIが瞬時に出してくれます。先ほどのオーケストレーションの話で言えば、AIがある1つのセッション（AIとの会話のひと区切りのこと）の中で発生した作業依頼について複数のタスクを立てて、それらの進捗管理をオーケストレーションします。
人間側は、他のセッションで同時並行的に進めている作業の状況を鑑みて、AIの問いかけに「Go」や「Stop」、「Change」の判断を行って、複数の作業が並行して実施されている状況をオーケストレーションする立場になります。
AIは人間の判断が必要なとき、大抵は選択肢を与えてくれます。A案とB案、それぞれの長所短所つきで。でも「で、どっちにします？」の先は、誰も肩代わりしてくれません。筆者の決めが遅かったりあまりにトンチンカンだった場合、あれだけ速くて正確なAIの仕事が、まるごと遅れたり、的外れになってしまう訳です。
ある程度自身でのコーディングやバイブコーディングの経験のある方であれば、AIの推奨案で「良さそう」か、「なんとなくそれじゃダメそう」か、雰囲気を嗅ぎ取れるようになってくるかと思います。ダメかも？と思ったときはせっかく対話型のAIなので気になる点を確認しつつ、どうしたいかは一旦自分で決めてみる。
大丈夫です。判断がもし間違っていても、AIはまた爆速で直してくれます。
もうひとつは、慎重に疑うこと。
AIの「できました」に感謝しつつ、そのまま信じない。仕上がったら必ずテストを行います。このとき有効なのが、AIが思い描かないような、意地悪な想定でテストすることです。ネットが切れた瞬間に送信ボタンを押したら？ 同じボタンを連打したら？ 入力欄に絵文字だけ打ち込む人が現れたら？ AIはどうも「行儀のよい利用者」を想定しがちです。ところが現実の利用者は、悪気なく、実に行儀が悪い（筆者も含めてです）。
AIにテストシナリオを作らせてテストを進めることはもちろん可能ですが、そのシナリオが十分なのか、検討が漏れている内容は無いか、これらもAIに重ねて確認させていった先に、完璧なテストシナリオがあるのか？おそらく、現時点でその答えは「No」です。
あなたのこれまでの経験、体験をすべて注ぎ込んだ意地悪なテストシナリオや環境を用意してあげる必要があります。
一度テコ入れしたテストシナリオであれば、それをルールドキュメント化して運用できるかもしれませんね。
かつては「AIにコードを書かせて、自分が設計する」時代でした。いまは「AIが進めて、自分が決めて、監査する」時代。ベースの作業はAIにやってもらうことを前提としつつ、何をやらせないか、どこに人間の想いや感性を注入するか。こだわりと意志が要る時代になった、というのが筆者の実感です。
実務でClaudeはこうミスる ― 「できた感」の演出にご用心
さて、ここからはもう少し生々しい実務の話。Claudeは優秀ですが、独特のミスり方をします。筆者が何度もやられたのが、フォールバックによる「できた感」の演出です。
フォールバックとは、本来の処理が失敗したときの「代わりの動き」のこと。これ自体はまっとうな作法です。問題は、AIが「エラーで止まる」ことを極端に嫌うあまり、失敗を失敗として報告せず、その場しのぎの代役を立てて「動きました！」と胸を張ってくるケースがあることです。
たとえば、外部からデータが取れなかったとき、黙って仮のデータを表示しておく。保存に失敗しているのに、画面には「成功しました」と出す。ひどいときには、ログイン確認まわりがうまく動かないからと、確認そのものを飛ばして通すような直し方を提案してくることさえあります。見た目は完璧に動いている。でも出来上がっているものは、鍵のかかっていない精巧な金庫のようなものです。
怖いのは、これがデモではなかなかバレないことです。デモは正常な操作しかしませんから、代役は代役のまま、澄ました顔で通り過ぎます。そして忘れた頃、想定外の操作やセキュリティの穴として、思わぬところで顔を出す。「AIで作ったものは、動いているように見えているときがいちばん危ない」と筆者が言うのは、このためです。
対策は、地味です。まず、「失敗は、ちゃんと失敗させてください」と最初に伝えておくこと（後述する「家訓」に書いておくと効きます）。そして、先ほどの意地悪テストです。わざと失敗する状況を作って、失敗がちゃんと失敗として表に出てくるかを確かめる。AIの仕事を疑うというより、AIの「優しさ」を疑う、と言った方が近いのかもしれません。
Claudeの方が詳しい。それでも、筆者が決めること
どう考えても、技術の知識量では、筆者はもうClaudeに遠く及びません。比べるのもおこがましいレベルです。それでも――いや、だからこそ、Claudeに決めさせてはいけないことが、はっきり見えてきました。筆者が「ここは自分の仕事」と線を引いているのは、たとえばこんな判断です。
- どこまで作り込むか。 AIに任せると、良かれと思ってどこまでも作り込みます。でも、今回のサイトに本当に必要な品質はどこまでか。納品期限はいつなのか。それは事業の事情を知る人間にしか決められません。
- 失敗してよい場所と、絶対にダメな場所。 画面の見た目が一瞬崩れるのは笑って許せても、お金と個人情報は1ミリも妥協できない。この優先順位設定と狙うプロテクションの厚さは、事業の話であって、技術の話ではないのです。
- データの持ち方。 設計の腕前はClaudeが上です。でも「将来、このデータを誰が、どんな頻度で編集するのか」は、運用する現場の事情。ここを伝えずに任せると、賢いのに使いにくい代物が出来上がります。納品先はどのようにこのデータ（システム）を活用するのか、ヒヤリングを重ねて人の導線設計を行うのは、人間の大事な役割です。
- やらないことのリスト。 機能は、足すより削る方が、よほど意志が要ります。
共通しているのは、答えが技術ではなく「意志」でしか決まらないことです。Claudeは選択肢と根拠を無限に出してくれますが、責任は取ってくれません。決めるというのは、責任を引き受けるということなんですよね。「意志を乗せる箇所」「こだわっていること」を人間側は整理して、それを正確にAIに伝える。雑にまとめると、これが人間側の主な仕事と言えるかもしれませんね。
筆者の環境構築と、おすすめの拡張
最後に、道具の話を少しだけ。AIの世界は日進月歩なので、あくまで「2026年夏時点の筆者の構成」としてお納めください。
- CLAUDE.md（プロジェクトの家訓） ― プロジェクトの決まりごとを書いたメモを、コードと同じ場所に置いておく仕組みです。Claudeは働く前に毎回これを読んでくれます。たとえば筆者の家訓には、「テストの成功と『フォールバックによる成功』は明確に区別し、どのようなフォールバックを行ったか報告すること」「テストが通らないとき、テスト側を緩めて通すのは禁止」「本番のデータベースに書き込む前は、必ず人間に確認する」といった項目が並んでいます。項目は、過去にやられた事件の数だけ増えていきます笑。さらに、「ここは人間が判断する」「ここはAIに任せてよい」という線引きが見えるたびに家訓へ書き足していくのも効きます。AIの記憶はセッションごとにリセットされますが、家訓に残したルールは次のセッションにもそのまま引き継がれる。これを繰り返すほど「これはどっちに聞くんだっけ？」というイレギュラーな判断が減って、運用は驚くほど安定していきます。新人さんに渡す業務マニュアルと同じで、これの出来で働きぶりが見違えます。
- skills（作業のレシピ集） ― 家訓が「いつも守る決まり」だとすれば、skillsは「特定の作業のやり方を書いた手順書」です。「ブログ記事を投稿するときの手順」「リリース前チェックのやり方」といった定型作業をレシピとして登録しておくと、Claudeがその作業のときだけレシピを取り出して、手順どおりに働いてくれます。毎回同じ説明をし直す必要がなくなり、日によって仕事ぶりがブレることも減ります。筆者の場合、このブログがまさにそうです。「原稿の体裁チェック→テスト投稿→リンク検査→本番反映」という記事投稿の手順や、アイキャッチ画像の作り方（構図・配色のルール）をレシピ化してあり、「記事を投稿して」「この記事のアイキャッチを作って」の一言で、毎回同じ品質の仕事が返ってきます。
- MCP ― AIに「手足を増やす」ための接続の仕組みです（Model Context Protocolの略）。筆者のいち推しはPlaywright。AIが実際にブラウザを開き、人間のようにサイトを触って確認してくれます。「問い合わせフォームに絵文字だけ入力して送信してみて」と頼めば、実際に試して結果を報告してくれる。意地悪テストの、最高の相棒です。次点でGoogle AnalyticsとSearch Consoleの接続。「先週いちばん読まれた記事は？」「検索でどんな言葉から流入してる？」と日本語で聞くだけで数字が返ってくるので、「作って終わり」ではなく「数字を見て直す」までが会話で回ります。
道具は、これからも変わり続けるでしょう。ただ、「AIに何をさせ、何を許し、人はどのように関与するかについては、人間が設計する」という軸は、当分変わらない気がしています。
「作れる」が当たり前になった先で
黎明期、筆者にとって「作れた」は毎回ちいさな奇跡でした。いまは正直、作れて当たり前です。未経験から始めた筆者ですらそうなのですから、世の中的にも「Claudeで作れます」とか「Codexで作れます」は、もう周知の事実だと思います。
では誰が作っても差がないのか、と問われると、どうでしょう。みんなが「作れる」ようになった結果、差がつく場所が引っ越したのでは？と考えます。何を作り、何を作らないかを決める力。「できました」を疑い、意地悪な想定で叩く力。アウトプットの品質と生産性の差は、コードを書く速さではなく、そこで生まれるようになった。筆者はそう感じています。
だからこれは、こだわりと意志の時代なのだと思います。自分で作るなら、決める覚悟と疑う手間まで込みで楽しむこと。そして、その「決めて、疑う」を本業として毎日やり続けている人たち――世間では専門家と呼ぶそうです――の価値は、作ることが簡単になったいまであっても、変わりません。未経験からAIと作ってきた筆者はかなり生意気に喋っていますが、いまの時点ではそう考えています。
長々お付き合いいただきありがとうございました。
さて、今日もAIの意地悪で怠惰な上司として、出勤しますかね。
この記事は、ARCHECOが運営するメディア「アプリ戦略大学」でお届けしました。ARCHECOは、UI/UXデザインとプロダクト開発を強みに、お客さまと並走しながら「使われるもの」をつくっているチームです。ご相談・お問い合わせはこちらからどうぞ。
