「もう本当に終わりにしたい」とAIに弱音を吐いたら、開発の当たり前に気付かされた話

GA4の月次レポート自動化プロジェクトに取り組み始めた頃、AIにこんなことを言った日がありました。
「もういい加減似たような修正が多すぎて、直したところがまた問題になっていたりするのをどうにかしたい。もう本当に終わりにしたい。やり方が悪いなら教えてほしい。」

AIからの返事は、
「根本的な問題は、修正のたびに全体を把握せずに個別修正を重ねていることです。今までこれを繰り返してきましたが、これだと一生終わりません。完成形の全スライド仕様書を先に作りませんか?」
でした。

私はマーケターで、コードは書けません。会話だけで物ができていく便利さに任せて、その都度提示される問いにだけ向き合っていた結果、失敗した話です。行き詰まった時に辿り着いた結論は、開発の世界では当たり前の「仕様にまとめる」という作業でした。この記事は、そこに辿り着くまでの試行錯誤の話です。

プロジェクトのきっかけと、最初のつまずき

「AIで業務改善できないか」と思ったのが、プロジェクトのきっかけです。月次レポートを自動化して、マルチクライアント対応を容易にしたい。AIに任せられれば、クライアントが増えても少ない人数で運用できます。

最初に試したのは、claude.aiのProjects機能でした。GA4とGoogle Slidesに接続し、サンプルスライド、トラッキング設計書、クライアント情報、レポートの作成条件をナレッジに登録して「今月のレポート作って」と頼むと、スライドが出来上がります。品質も悪くないものが出来上がりました。

ただ、この方式は私が手を動かさないと動きません。マルチクライアント展開や自動実行を考えると、Web UIから誰でも動かせる仕組みに作り直す必要がありました。

ここで早速つまずきます。生成のたびにレイアウトが揺れました。文字サイズも、要素の配置も、毎回違う。Projects機能で出ていたものと同じものを作りたいだけなのに、安定して同じものが出てこなくなりました。レイアウトとの長い格闘が始まります。

ルールを足しても、想定外の場所が崩れる

毎月の生成タイミングでAIにスライド生成のコードを書かせる形にして、デザイン仕様は「DESIGN_TEMPLATE_SPEC」というルール集にまとめ、毎回プロンプトに含めました。

問題が見つかるたびにルールを追記していくと、ある現象に気づきました。
「要素同士の重なりを防ぐ」のように全スライドに共通で効くルールを追記すると、それまで問題なかった別のスライドのレイアウトまで崩れることがありました。広く効く指示ほど、AIの解釈の幅が広くなって想定外の場所に作用してしまっていました。スライドを名指しして「このスライドは左60%、右40%」のように具体的に書き換えると、その箇所だけ安定して直りました。

手数を減らそうとして抽象的な指示を書くよりも、少し手間でも具体的な指示をすることで結果的に手戻りが少ないということに気づきました。

個別に直しても、別の場所で形を変えて再発する

ルールを具体的に書き直していくと、修正は通るようになりました。ただ、しばらく続けると別の問題が出てきます。

修正した箇所は直りますが、しばらくしてから、似たような問題が別のスライドで形を変えて出てきました。テーブルのヘッダー色を直したら、別のスライドのテーブルで同じ問題が出る。直しても直しても、新しい問題が新しく出てくることが続きました。

私がやっていたのは、目の前の問題を順番に潰しているだけの対症療法でした。Projects機能で作っていた完成イメージは私の頭の中にあるのですが、AIに伝えているのは「ここを直して」「ここがおかしい」という散発的な指示だけでした。AIからすると、全体としてどう仕上げたいのかが分からないまま、修正だけを受け取り続けることになります。手元には修正履歴のリストだけが伸びていきました。

短期的には対症療法の方が楽でしたが、このやり方では終わりが見えませんでした。

仕様書を先に作るという選択

このまま続けても終わらない、と感じてきた頃に、AIに弱音を吐いてみました。返ってきたのが、冒頭に書いた答えです。「完成形の全スライド仕様書を先に作りませんか?」

言われてみれば、当たり前でした。開発であれば、最初に仕様を決めて、それに沿って作っていきます。AIと会話で進められることに違和感がなさすぎて、その手順を飛ばしていました。

提案を受け入れて、スライドの仕様書を書きました。
スライドごとに、どんなデータが入るか、コメントの位置はどこか、テーブルは何行何列か、フォントサイズはいくつかなどです。同時に、全スライドで共通になる部分(ブランドカラー、コメントの配置基準、テーブルのヘッダースタイルなど)は、最初に共通の定数として定義しておきます。スライドごとに書くもの、共通で1箇所に置いておくものを最初に分けて整理してから書き出していきました。仕様書も、その後の運用で見直しながら少しずつ整えていきました。

仕様書ができてから、Claude Codeに一括で実装してもらいます。「問題が見つかったら修正指示」のループが、「先に仕様を確定 → 一括実装 → まとめてチェック」に変わりました。
修正のループは減りました。仕様書に書いてあるかどうかが基準になるので、「想定通り」「仕様書から外れている」の判断が早くできるようになりました。

おわりに

コードが書けない自分にも、AIを使えば開発に近いことができるかもしれないという気持ちで始めて、新しい何かをやっている感覚もありました。でも、行き詰まったときに助けられたのは、開発の世界で昔から当たり前にやられてきたことでした。

「まずはやってみるか」から始めたプロジェクトですが、今はマルチクライアント対応で、毎月GA4、LINE、iOSとAndroidのストアからデータを引っ張ってきて、自動でレポートが出せるところまで来ました。クライアントへの提供とフィードバックも、少しずつ進めています。まだテスト段階なので、いろいろとご相談しやすい状態です。興味のあるお客様がいれば、クラスメソッドまでお問い合わせください。

まだ全然使いこなせているわけではないですが、これからも続けていきます。