2022年、私は一冊のプログラミング本を途中で閉じました。『早く仕事を終わらせたいから、プログラミング始めました。』という、Google Apps Script(GAS)で仕事を効率化する本です。止めた理由は前回の記事に書いたとおりで、本が悪かったわけではなく、私のほうに「作りたいもの」がなかったからでした。
それから4年。AIに話しかけながらアプリを作る「バイブコーディング」を始めた今、同じ本をもう一度開いてみました。すると、当時は読み飛ばしていたところに、AIへの指示を上手くするヒントがたくさん埋まっていることに気づきました。
2022年は、予定を1件入れるのがゴールだった
本の第5章に、Googleカレンダーに予定を登録する演習があります。手順はこうです。
カレンダーの設定画面からカレンダーIDを探してコピーする。GASのファイルを新規作成する。日付を「Date型」というプログラム用の形式に変換する。説明文や場所は決められた書式で書く。実行すると「このアプリはGoogleで確認されていません」という警告が出るので、「詳細」を押して許可する。ここまでやって、ようやくカレンダーに予定が1件入ります。
今はどうでしょう。GeminiやClaudeに「10月10日の10時から15時で全体会議、30分前にリマインドして」と送るだけです。本の中で一番苦労する部分が、まるごと消えてしまいました。
正直、最初は「この本で勉強した意味って何だったんだろう」と思いました。でも読み進めるうちに、考えが変わりました。
気づき1:本が一番伝えたかったのは「書き方」ではなかった
この本は第1章で、プログラミングがビジネスに役立つ理由として「分解力」を挙げています。大きな物事を細かいタスクに分けられる力のことです。第5章でも毎回、「作りたいもの → 何が必要? → 分解」という図が出てきます。
AIが肩代わりしてくれたのは、分解したものをコードに翻訳する作業だけでした。分解する作業そのものは、今も人間の仕事です。
AIに「いい感じのアプリ作って」と頼んでもうまくいかないのは、分解が済んでいないからだと思います。「何を作りたいか」「そのために何が必要か」を先に自分で整理しておくと、AIの返答が明らかに良くなります。
気づき2:「先にコメントを書く」は、そのまま指示文になる
本では、コードを書く前に日本語のコメントで手順を書いておくやり方を勧めています。たとえばこんな感じです。
// スプレッドシートからイベント情報をとってくる
// とってきたイベント情報をカレンダーに登録2022年の私には、これがただの準備作業に見えていました。今読むと、これはほぼそのままAIへの指示文です。手順を順番に日本語で並べる。それができれば、コードに翻訳するのはAIに任せられます。
気づき3:例外の条件まで書くと、仕上がりが変わる
本の一括登録の演習には、「リマインドの分数が入っていない行は、リマインドを設定しない」という条件分岐が出てきます。全部の予定にリマインドが欲しいわけではない、という現実的なルールです。
AIへの指示も、「基本はこう。ただしこの場合は除く」まで書くと、やり直しが減ります。営業のトークスクリプトで「お客様がこう言ったら、こう返す」と分岐を作るのと同じ考え方です。本にも「できる営業マンはプログラミングも得意なのかもしれない」という一文がありますが、今なら「AIへの頼み方も上手いのかもしれない」と言えそうです。
気づき4:一回きりか、毎回かで、頼み方を変える
本の最後のほうに、「毎朝8〜9時に今日の予定をメールで送る」という演習があります。トリガーという機能を使って、決まった時間に自動で動かす仕組みです。
ここは今でも、チャットで毎回頼むより、仕組みとして置いておくほうが確実です。私も文系営業マンのX用に、早朝にGASで情報を集めて、朝8時ごろに自分で確認してから投稿する運用をしています。
違うのは、そのGASを自分で一から書いていないことです。AIに書いてもらって、貼り付けて、動かしています。
今の私の使い分けはこうです。一回きりの作業は、チャットで頼む。繰り返す作業は、AIにコードを書いてもらって仕組みにする。どちらにするかを決めるのは、自分です。
まとめ:翻訳の仕事が消えて、分解の仕事が残った
2022年のプログラミングは「分解する → 自分でコードに翻訳する → 動かす」でした。2026年の今は「分解する → AIに渡す → 確認して動かす」です。
消えたのは真ん中の翻訳の部分だけで、最初の分解と最後の確認は、今も人間の担当です。4年前に途中で閉じた本は、実はAI時代の指示の出し方を、先に教えてくれていたのかもしれません。
もしあの頃の私に声をかけられるなら、「コードは覚えなくていいから、分解のところだけは読んでおいて」と言いたいです。