[ポエム]バイブコーディングから考察する初級～中級者プログラミング

どうも、ケニー（tsujikenzo）です。今日は単発記事です。普段からGASをメインとしてプログラミングを行ってる方に読んでいただけると嬉しいです。

はじめに
Google Apps Script (GAS) 開発ガイドライン Ver.1.0

はじめに

VBAやGoogle Apps Script (GAS) を使ったバックオフィス業務の効率化から、私のプログラミング学習は始まりました。「30分かかっていた作業が5分になる。」「2人がかりだった仕事が1人で終わる。」その劇的な変化が楽しくて、空いた時間をさらに学習に投入するという、好循環にハマっていました。

ノンプロ研という学習コミュニティの仲間と共に、1年目はひたすら小さな自動化ツールを作り続けました。しかし2年目、社内のチームでのアプリ開発や、バージョン管理のむずかしさなど、新たな壁にぶつかります。

「正しい設計」を求めて迷走した日々

中級者へのステップアップを目指す中で、「オブジェクト指向」や「DDD（ドメイン駆動設計）」といった言葉が気になり始めました。より良い設計、メンテナンスしやすいコードを求めて、実務では使わないJavaの門を叩き、Java Silverの資格を取ったりもしました。

しかし、知識は増えても、日々のGASやPythonの開発にそれをうまく落とし込めない。カプセル化の重要性は頭でわかっていても、どこからでも書き換えられるスクリプト言語の「便利さ」が手放せない。かといって、型に厳密なTypeScriptに移行するほどの覚悟もない。

結局、「オブジェクト指向とは何か？」という問いの答えは見つからないまま、学習は挫折したと言えます。デザインパターンを学んでも「頭のいい人がいるもんだ」と思うだけで、腹落ちはしない。MVCや3層アーキテクチャについて考えても、「UI＋ロジック＋DBアクセス」の3層がいいのか、「＋ユーティリティ」の4層がいいのか…？という考察の沼にハマるだけでした。

今思えば、GASという「Googleのエコシステムの上で、少しのスクリプトでサービス群を動かせる」という強力なコンフォートゾーンの中で、「深掘り」と称して本質的でない学習を続けていたのかもしれません。

AI時代と「バイブコーディング」

そして、生成AIの時代が到来しました。
AIコーディングは、一行一行コードを読み解かずとも、「なんとなく全体像」を把握しながらアプリを成長させていくスタイルを可能にしました。
「バイブコーディング」という言葉も流行っています。「こうなったらいいな」「こんなものができたらいいな」という「バイブス」を、AIとの対話で実現していくイメージです。

しかし、私は「使い捨て」という言葉には少し違和感があります。AIが書くコードは、あくまで「とりあえず動く」もの。ハードコーディングされた設定値や、一貫性のない命名規則が散らばりがちです。
それを放置すれば、アプリはすぐにメンテナンス不能な「秘伝のタレ」と化します。

コーディング規約を決め、AIにそれを守らせる。それこそが、AI時代のプログラマーの役割ではないでしょうか。 そして、その「バイブス」は、自分の知識の範囲内でしか実現しません。より良い「こうなったらいいな」を描くためには、やはり設計の「型」を知っていることが強力な武器になります。

迷走の果てに見つけた、GAS開発の「黄金律」

オブジェクト指向の深い森で迷子になった私が、数々の試行錯誤の末にたどり着いた、GAS開発における実践的なガイドライン。それが、これから紹介する「3層＋ユーティリティ」構成です。
これは、AIに指示を出す際の「コーディング規約」そのものであり、あなたの「バイブス」を形にするための、堅牢な「土台」となります。

Google Apps Script (GAS) 開発ガイドライン Ver.1.0

STEP 1：基本形「3層＋ユーティリティ」から始めよ

どんなアプリを作るにせよ、まずはこの「基本形」からスタートしてください。
これが、GAS開発における最もバランスの取れた黄金律です。

ファイル構成:

main.gs (または Code.gs) – 実行の「入口」専用
Service.gs – アプリの心臓部「業務ロジック」
Repository.gs – Google Workspaceとの「データ通信」
Utils.gs – 便利な「共通部品」（任意だが強く推奨）

1. main.gs

役割: 実行の「入口」専用。
書くこと: doGet, doPost, onOpen, 時間ベースのトリガーから呼ばれる関数のみ。
ルール: ここには具体的な処理は書かず、Service.gs の関数を呼び出すだけに徹します。

// main.gs
function doPost(e) {
  // Service層に処理を委譲
  return SheetService.handleFormSubmission(e);
}

2. Service.gs

役割: アプリの心臓部となる「業務ロジック」。
書くこと: 「スプレッドシートからデータを取得し、条件に応じてメールを送る」といった一連の処理フロー。
ルール: SpreadsheetApp や GmailApp を直接叩かない。データ操作は必ずRepository.gsに依頼します。

3. Repository.gs

役割: Google Workspaceとの「データ通信」に特化。
書くこと: SpreadsheetApp, GmailApp, DriveApp などを直接操作するコードだけをここに集めます。
ルール: 「どのスプレッドシートか」「どのシートか」といった具体的な情報を知っているのは、この層だけです。

4. Utils.gs

役割: 便利な「共通部品」。
書くこと: 日付のフォーマット、ログ出力、エラーハンドリングなど、アプリのどこからでも使える汎用的な関数。

【今すぐやること】

あなたの作りたいアプリの機能を、この4つのファイルに当てはめてコーディングを始めてください。
AIに指示を出す際も、「Service.gs に〇〇の機能を追加して。データ操作は Repository.gs の関数を呼び出すこと」のように、この「型」を意識して指示を出します。
この「型」を守ることが、将来の自分を助ける最大の投資です。

STEP 2：必要に応じて「層」を追加・分割せよ

開発を進め、特定のファイルが肥大化してきたら、それが「層」を追加するサインです。

外部API連携: Adapter.gs を追加し、APIとの通信処理をそこに隔離します。
業務ドメイン分割: invoiceService.gs と customerService.gs のように、Service.gs を業務ドメインごとにファイル分割します。

重要なのは、最初から完璧を目指さないこと。「コードが複雑になってきたな」と感じたタイミングで整理（リファクタリング）するのが、最も効率的です。

STEP 3：プロとしての「土台」を固めよ

コードの書き方と同時に、開発環境も整えましょう。

clasp を導入する: ローカルの使い慣れたエディタ（VSCodeなど）で開発し、コマンドでデプロイできるようにします。もうウェブエディタには戻れません。
設定値をコードから分離する: スプレッドシートIDやメールアドレスをコードに直接書かず、PropertiesService を使って管理します。
権限を意識する: このスクリプトは「誰として動くのか？」を常に考え、コンテナとなるファイルは共有ドライブに置くことを検討します。