はじめまして、AIコンサルの不都合な真実シリーズの筆者です。Web開発完全未経験の状態から、AIコーディング、いわゆるバイブコーディングを始めた中年男性の体験を、この場をお借りしてみなさまに共有します。
「AIコンサルの不都合な真実シリーズ」。我ながら、ずいぶん挑発的なシリーズを始めてしまったな、と思っています。
この連載シリーズでは、現場でくり返される「分厚い提案書」とか「動くのに誰も使わないデモ」みたいな、業界のちょっと触れにくい話を、なるべく正直に書いていくつもりです。でも、こういう記事で往々にしてあるのが、無名評論家の悪口満載記事。「誰が言ってんの？」と呟いて、「そっ閉じ」したくなるような記事です。
なので本編に入る前に、一度だけ、自己紹介をさせてください。 私、柳田と申します。（ここから先は「筆者」と名乗ります。）
来歴を含めて壮大に自分語りを展開致しまして、これからの記事は「誰が書いているのか」を、少しクリアにさせていただければと存じます。 また、いかにもスマートで先端っぽい「AI仕事」を、いかに泥臭く、アホっぽく、自分の仕事にしていったのかも、併せて恥ずかしげもなくご紹介します。これからAIの業務活用を試みるみなさまの参考になれば幸いです。拙い文章ですが、どうぞお付き合いくださいませ。
新入社員時代、いちばんの専門業務は「飲み会の予約」でした
筆者の社会人スタートは、大きな電力会社でした。いわゆる安定の代名詞みたいな会社で、祖父母とかがたいそう喜んでくれる、あの感じです。
入社直後、飲み会の予約と、その後日精算を主業務として担当しました。これは冗談半分・本気半分です。歓送迎会、部の懇親会、ランダムに発生する飲み会。参加者の嗜好を踏まえてお店をリサーチしつつ、参加者を数え、当日は参加者の好みの酒を作り（焼酎水割りに烏龍茶を10ccくらい垂らしてかき混ぜない、「色付け」派などというセンパイも居ましたね）、後日せっせと役職によって適切っぽい傾斜をつけた割り勘を計算して集金する。新人の腕の見せどころは、ここまでを指示無くできるようになること。業務知識？３年くらいで多少モノになれば良いよね！っていう風潮でした。
笑い話のようですが、いま思えば、これはこれで立派な「現場」のようでもありました。誰が何を気にしていて、誰の顔を立てると物事がスッと進むのか。組織という生き物の動き方を、酒の席で叩き込まれたような感覚です。（今振り返れば、ですよ。当時は「早く帰りてぇな」とか思ってました笑）
実務はというと、一般家庭や中小企業さんを対象に、エンジニアとして訪問する仕事でした。停電を解消したり、契約容量の相談に乗ったり、未納料金の回収をしたりといった、これもいわゆる「現場」職です。
これは個人的に面白かった経験です。研修では、電気設備の安全基準などを叩き込まれ、基準に則っていない設備は即是正！と教わります。ところが、ひとたび実際の一般家庭や町工場に行くと、「基準？なにそれ」的な設備がゴロゴロ。事情を聞けば、古い建物で、改修するお金も無くて、「即改修って言われてもねぇ……」と前にも後ろにも進めない状況。 その職場で実際に必要だったのは、設備の安全基準の存在はもちろんのこと、それを守れなかったときの「安全を確保するための工夫、つまり、ルールと現実の折衝能力」だったのです。社内ルールと現実との折衝に、自分が関わる意義のようなものを感じました。 机上の正解と、現場で本当に使えるものは、けっこう違う。 これを最初の仕事で実感できたのは、いま振り返るとラッキーでした。
「お諮り」という壮大な時間の溶かし方
そのうち筆者は、複数の部署を経て、本社の新規事業開発の部署に移ります。会社の未来を作る、稼げる組織を作る！なんともイケイケな響きの部署です。実際、頭のキレる人がたくさんいて、議論も面白かった。
ただ、仕事を重ねるにつれ気になってくる業務プロセスがありました。イケイケな部署に似つかわしくない、ハワイのハンバーガーみたいに分厚い稟議書、いわゆる「お諮りプロセス」です。
馴染みの無い方のために説明すると、偉い人に判断を仰ぐための社内手続きのことです。何かを始めたり変えたりしたいとき、まず資料を作る。背景、目的、市場規模、競合分析、想定リスク、想定リターン、撤退基準……これでもかと盛り込む。そしてその分厚い束を持って、課長に諮り、部長に諮り、役員に諮る。一つ上に上げるたびに「ここの根拠は？」「他社事例は？」と差し戻され、また資料を厚くする、というプロセスです。（説明に若干の憎悪がこもっているかもしれないですが）
この文化、新規事業の企画部署にはとんでもなく相性が悪いのです。新規事業を企画するにはPoC（検討中のサービスを小さい規模で実地検証する工程）が付きものな訳ですが、PoCの計画をまずお諮り、途中経過の報告書を作って計画変更をお諮り、検証の結果が出たら、その後の意思決定をまたお諮りする。
頭のキレる先輩たちが、「こんな事業良いんじゃないか？」とホットな着眼点で企画した事業は、課長用、部長用、役員用とバージョンを分けたお諮り資料の作成に時間を取られて、どんどんと冷めきった固いピザと化していく訳です。
あれこれ考えて、動かない 理由は、偉い人の責任逃れであるとか、偉い人が余程暇であるとか様々でしょうが、古い企業（に限らず？）の現場ではこのような問題が発生しているのだなぁ、と学んだのでした。
半年のカナダ生活と、長野の誘惑
電力会社退職後は個人で電気工事業をやっていましたが、あるとき妻が半年ほどカナダのトロントで仕事をする計画をしていました。ネットで調べれば美しい大自然の画像がわんさか、トロントはたくさんの移民によって複雑に文化が混ざり合う楽しげな雰囲気。「それ、良いねぇ」ということで、一緒にトロントについていくことにしました。 想像はさらに巡ります。渡航に合わせて日本の家を引き払うので、帰国後の住まいも自由になります。「そしたら、長野に住みたいなぁ……」 子どもの頃から親しんだ釣りと、趣味で20歳のころに始めたスノーボードは今や完全にこじれ、「遊び場の近くに住みたい！」という、短絡的かつお気楽な意思決定をもたらす程になりました。
ちなみに筆者はいまも、長野で暮らしています。冬は、降りたてのパウダースノーをスノーボードで愛で回し、冬シーズンが終われば水辺で釣り。そしてスキマ時間には、近所のりんごやぶどうの果樹園で、農家さんの手伝いをさせてもらっています。これがまた、最高なんです。朝の畑の爽やかさ。収穫物のお裾分けを頂くこともありますが、その美味しさはもはや筆者には説明不能です。摘果や収穫を手伝いながら、70代80代の農園主さんたちと交わす世間話や農家の課題あるある話の中に、後で「あ、これ仕事の話とまったく同じだ」と膝を打つ瞬間も意外とあるものです。
さて、自由でワクワクなカナダ渡航や長野暮らし。その妄想の裏では、現実的な課題がこちらをにっこりと見つめています。「で、お前仕事どうすんの？」
そんなとき、相談に乗ってくれたのが、いまご一緒している、ARCHECOデザイナーの中村さんと、代表の須齋さんでした。二人と話すうちに、須齋さんがポロリ。「コーディングじゃない？」 勤務場所に囚われない、夢の仕事コーディング。未知のワードと遭遇です。プログラミングのプの字も知らない、雪と魚を追いかけ野山を駆ける元・電力会社のサラリーマンが、ここから未経験でコードを書く仕事に飛び込むことになります。我ながら、なかなかの無謀さです。
ChatGPTと一喜一憂。全力で蔑み、褒めて伸ばす日々
最初は本当に、超初歩からでした。`html` とは何か。`css` で文字の色を変えるとはどういうことか。「見出しが大きく表示された！」というだけで、キャイキャイ喜んでいた時期があります。今思うと小学生みたいで実に微笑ましい思い出です。
そうしてコーディングの勉強をし始めて間もなく、世界をひっくり返す勢いでChatGPTを始めとする、生成系AIの話題が賑やかに聞こえてくるようになりました。
須齋さんのアンテナはいち早くその時勢を捉え、筆者のコーディングは、ここから一気に「バイブコーディング（Vibe coding）」へ移っていきました。バイブコーディングというのは、ざっくり言うと、自分でゼロからコードを書くというより、AIと会話しながら「こんな感じのものが欲しい」と伝えて、出てきたものを直してもらいながら作っていく、いまどきのやり方です。知識ゼロの筆者には、今から始めるならこれしか道が無い、とも言えます。
そんな希望の光、バイブコーディングですが、始めた頃にぶちあたった問題やエピソードをいくつかご紹介しましょう。
AIからの回答を受け取る側がお粗末問題 いざコーディングにAIを導入。試しに何か質問すればズバズバ明快な回答をくれるAIに、筆者の期待は右肩上がりに膨れ上がります。 AI導入当時の筆者の作業の進め方は、AIに対してある一つの作ってほしい機能や目指すデザインを伝えると、実際に使うべきJSやCSS、必要なソフトウェアを案内してくれるので、それを指示どおりにコピペしたり、人間がコマンドツールを使ってサーバー操作をするようなスタイルでした。 このスタイル、コーディング未経験者には結構キツイのです。 実際のプロジェクトを例にお話しします。例えばHPを作るなら、DBどうする？何の言語のどのバージョンつかう？画像はどこに保存する？と、ちょこっと勉強したコーディング以外にも、必要な要素が次から次へと発生します。手順やツールについて懇切丁寧にAIは説明してくれるわけですが、未知のワード達は簡単には筆者の頭に入らない。わからない単語について解説してもらっているうちにすぐにコンテキストは満杯。少し単語の知識を得て、もともと依頼していた作業は一歩も進まない。そうか、優秀なAIの回答を活かすも殺すも、人間次第だったのか……
AIに作業を依頼する側がお粗末問題 AIが作ってくれたJSやCSSをコードエディタに貼り付けて、デモを起動して仕上がりをチェックします。機能に問題は無いのですが、ボタンを操作したときのエフェクトをもっとオシャレにしたい。 さて、初心者たる筆者はこの要望をどのように伝えるのでしょうか？ 「ボタンを押した時に、そのボタンが右上にシュっと動いて、ちょっと色が薄くなるようにしてほしい」みたいな注文を平気でやります。 これ、筆者の頭の中ではボタンがほんの少し斜め上に素早く動いて、スッと変色するようなエフェクトを思い浮かべていましたが…… 「シュッと」をAIは、ボタンが飛行機（ロケット？）みたいに画面外に飛び立つ動きと解釈し、ボタンが飛び立った元位置にボタンの痕跡が薄ーく残るようなエフェクトを与えてくれました。ぐぬぬ、やはりAIを活かすも殺すも、人間次第じゃないか……
会話を重ねると、AIがだんだんバカになっていく問題 これはAIを使い込むにつれて、じわじわと疑惑が湧いてきました。チャットの前半は冴えていたのに、長くやりとりしていると、さっき決めたことや前提を忘れたり、見当違いの答えを返してきたりする。どんどん適当で、なんだか面倒くさがっているような回答を返してくる。「えっ、ついさっきまであんなに賢くて、親切だったのに！」と、なんだか裏切られた気持ちになりました。当時の筆者はその原因がわからなかったので、唐突な裏切りに行き場のない怒りを感じます。その怒りをいかに伝えるかを工夫して、あの手この手で罵倒して、AIに謝らせる。そしてまた粗末なコードを受け取る。ただ、不毛な時間を積み重ねるのです。
そして訪れる、大AI太鼓持ち時代
AIに怒り散らす、そのあまりの不毛さを大いに反省した筆者。今度は「すごい！」「ありがとう！」「さすが！」「完璧です！」と、やり取りのたびにチャンスを見つけてはヨイショヨイショと媚を売りました。なんとなく、機嫌よく働いてもらったほうがいいコードや気の利く回答が出る気がして、健気におだてる。機嫌を損ねて、裏切られないように、腫れ物に触れるように。今考えるとなんともシュールな絵面ですが、これも当時は真剣でした。 ちなみにこの褒めちぎりの効果については、気持ち程度、AIからの返信トーンが明るくフレンドリーになったと思います。大勢に影響なし！
AIと、ようやく“会話”できるようになるまで
そんな迷走をしばらく続けるうちに、だんだんと、AIとの付き合い方のコツみたいなものが、体に染みてきました。技術というより、もっと人付き合いに近いような感覚です。いくつか挙げてみます。
説明を省きすぎない。 優秀なAIくんだってこっちの頭の中を最初からは読めません。頭脳明晰、物腰はやわらか。だけど、実はコミュ障。人の気持ちを読んだりするのはやや難ありっぽい……。そんな同僚だと仮定して接します。 具体的には、 ・AIにどこまでの情報をインプットしたのかを把握しておく。 ・そのセッションでやってほしい事柄を明示的かつシンプルに（箇条書きなど分かりやすいスタイル）伝える。 ・回答にあたって考慮してほしい依頼の背景や前提条件は余すこと無く伝える。 ・必要に応じてAIにどのような立場として物を考えてもらうのか、役割を付与する。 【プロンプトの例】 ＜前提＞ ・私：コーディング初心者。専門用語もよくわからない ＜背景＞ ・私の上司から〇〇の作業を実施するように指示を受けた。 ＜あなたへの依頼＞ ・〇〇について分かりやすい表現で解説して
など、AIが解像度高くこちらの求める作業内容（これをやってほしい）やトーン（こんな雰囲気でやってほしい）を理解できるように、指標や役割を伝えることで、「これ欲しい回答（出してほしい出力）じゃないんだよなぁ」という手戻りを防ぎます。
逆に、ダラダラと余計な説明や指示を盛らない。 親切のつもりで背景をくどくど書き連ねると、肝心の頼みごとがぼやけて、的を外した答えが返ってきます。多すぎても少なすぎてもダメ。ちょうどいい塩梅を探る感じです。これは厳しくて忙しい上司に報連相のメールを打つような感覚です。 【悪いプロンプトの例】 今うちの会社でコーポレートサイトをリニューアルすることになりまして、私はWeb担当なんですけど正直デザインは素人で、上司からはとにかくオシャレで今っぽくと言われていて、競合のA社はこういう雰囲気でB社はこうで、個人的にはシンプルが好きなんですが社長は派手好きで、納期は来月末で予算は控えめで……それで、トップページのお問い合わせボタンってどう作ればいいですか？
この会話から、AIに本当にやってほしい作業を読み解くのはなかなか困難です。人間でもこんな説明イラっとします。「サイトのリニューアルぜんぶやるの？ボタン直すだけ？」となってしまいます。親切心で足した前置きが、かえって回答の的を外させるわけです。
さらにひとつの会話に、あれもこれもと処理を詰め込みすぎない。 さっきの「会話を重ねるとバカになる」の正体は、たぶんこれも含まれます。一回のやりとりで複数のことを同時にやらせようと、脱線まみれの依頼をする。するとAIの頭がこんがらがる。AIがこなすタスクの量をなんとなく予測して、なるべく小さく区切って、一個ずつ。これに気づいてから、ずいぶん仕事がスムーズになった感覚があります。
【悪いプロンプトの例】 このボタンの色を青にして、ついでにヘッダーのロゴも新しいやつに差し替えて、あとお問い合わせフォームのエラー表示も直して、トップの表示が遅い気がするから速くして、あとスマホで見たとき崩れてるところも全部直しておいて
一度にまとめて頼むと、どれも中途半端になったり、途中でAIが何をしていたか見失ったりします。色は変えてくれたのにロゴの差し替えは忘れている、みたいなことが起きる。面倒でも、用件は小さく区切って一個ずつ、が結局いちばんの近道でした。
ここで初心者が気をつけたい点としては、たまたま自分が知っている一つのやり方（ライブラリやツール）だけを名指しで指示して、全体との整合を置き去りにしてしまうことです。分からない部分をAIに任せること自体は、多くの場合むしろ賢い使い方。問題は、自分が触ったことのある手段に固執して、その手段にAIを無理やり合わせさせてしまうことのほうにあります。 【悪いプロンプトの例】 画像を横スクロールさせるカルーセル、前に一度だけ触ったことのある「Slick」っていうjQueryのプラグインで作ってください。あれ使いやすかったので。autoplayはオンで、3秒ごとに自動で切り替わるようにして……
一見、具体的でありがたい指示に見えます。でも、もしこのプロジェクトがReactのようなモダンな作りで組まれていたら、そこへjQueryのプラグインを後付けするのは、なかなかの鬼門。同じ画面を二つの仕組みが取り合って、原因不明の不具合が出たり、そこだけ余計な部品が増えて、後から誰も触れない一角になったりします。それでもAIは「Slickで作って」と言われれば、健気にSlickで作ってしまう。目的（横スクロールのカルーセルが欲しい）ではなく、手段（Slickで）のほうを固定して注文したせいで、全体との相性を確かめる機会そのものが消えてしまうんですね。伝えるべきは、実現したいことと、いまの現場の作り（「この画面はReactで組んでます」）。手段選びは、全体を見渡せるAIに委ねたほうが、たいてい素直に収まります。
ここまで得たコツを総括すると、コーディング素人の筆者が目指すべきは、構造や概念を理解することでした。 細かいツールの機能やテクニックについては、AIが一番よく知っている。つまり、筆者がAIから細かいツールの機能やテクニックの説明を受けて理解し、「AIの教え子」になる必要は皆無な訳です。そこはAIに任せ、自分は「どういう機能がどういう理屈で動いている」というプロジェクトの構造を理解したり、「〇〇というツールは、こういう機能を達成できるツールだ」というような概念をAIから伝授してもらって、人間側は注文の解像度を上げる。AIとの適切な役割分担ができたような気がします。
そうして得ていったコツは、AI側の進化によって現在進行形でどんどん変化しています。 現在は、生成系AIがコードエディタと連動して、プロジェクトのコード全体を把握して、勝手に編集して、最適な状態に整えてくれる。コードを書いてもらってコピペで貼り付けるコーディングとはおさらばです。 コマンドラインを通じて、環境構築作業の多くも代行してくれる。宇宙言語みたいなソフトウェアインストールも、複雑で何をやっているかわかりにくいサーバーの設定も、すべて「最適な感じで設定して」で基本OKです。もう最高です。
そうしてAIとの会話のコツは「どうやってお願いしたい作業をやってもらうか」という観点から、「どの作業は勝手にやらせないか」を制御する観点に変わってきたように感じています。 日々進化し、AIのできることが増えている今、利用する側は「人間が意思決定するライン」を定めていく必要が生じている印象です。 これからバイブコーディングを始められる方がいらっしゃるとすれば、その方は筆者とはまた違ったコツを得たり、課題に直面したりするのかも知れませんね。
様々な困難はありましたが、未経験から始めた人間が、AIと言い合いをしながら、「作りたいものを、諦めずに作れる」ところまで来られた訳です。これは、自分の知識や技術が向上した！というより、道具たちがそこまで連れてきてくれた、というのが正直な実感です。もしよろしければ、筆者と中村さんでタッグを組んで作った、ホームページをぜひご覧ください。
というわけで、はじめまして
とーっても長い自己紹介になってしまいました。最後まで読んでくださって、ありがとうございます。
書き出してみると、つくづく一貫性の無い経歴です。AIや導入コンサルについてのブログを書くにあたって、 ・机上の正解と現場は違うことが多い？ ・分厚い稟議書をしたためるより、試したほうが早くない？ ・AIの特性と、人間との最適な役割分担は？ このあたりの視点は、これまでの経験で培われてるような気がします。
この先のシリーズで、AI導入の現場の「ちょっとネガティブな話」も、できるだけ正直に書いていきます。 こんな奴が書いているんだなー、と気軽に参考にしていただけると幸いです。
それでは、本編で。
この記事は、ARCHECOが運営するメディア「アプリ戦略大学」でお届けしました。ARCHECOは、UI/UXデザインとプロダクト開発を強みに、お客さまと並走しながら「使われるもの」をつくっているチームです。ご相談・お問い合わせはこちらからどうぞ。
