インフラエンジニアが生成AI(Gemini)を相棒に、面倒な経理作業を自動化するサーバーレスアプリを爆速開発した話

はじめに

こんにちは！普段はNew Relicでテクニカルサポートエンジニアをしています。専門はAWSなどのクラウドインフラ領域で、主な仕事は他のエンジニアの技術的な質問に、専門家として答えることです。

長年の経験で、クラウドのベストプラクティスやリポジトリ戦略といった「システムの堅牢な作り方」については知識があります。しかし、アプリケーションのコードをゼロからガリガリ書くのは、正直なところ専門外です。

そんな私が、今年の年末に必ず直面するであろう、ある個人的な課題に先手を打つことにしました。それは、クリエイターである妻のPixiv Boothの売上を、会計ソフトfreeeに手入力するという作業です。

「この作業、どうにか自動化できないかな？」

そこで、ふと思いました。「コーディングは専門外だが、インフラの知識ならある。AIにプログラマー役を任せて、自分は設計に専念すれば、この面倒な作業を自動化できるかもしれない」

この記事は、そんなインフラエンジニアの私が、生成AIのGeminiを相棒に、「Boothの売上CSVをS3に置くだけで、全自動でfreeeに取引登録してくれるツール」を開発・公開するまでの全記録であり、専門知識を持つ人間が戦略を立て、AIが戦術（コーディング）を実行するという、新しい開発スタイルの実践記録です。

フェーズ1：AIの提案と、人間の軌道修正

最初のアイディア：「完全自動化」という一見すると甘い夢

最初に私がGeminiに伝えた要件は、こうでした。

私：「月に一度、AWS Lambdaを自動実行して、Pixiv Boothにログインして売上をスクレイピングし、freeeのAPIに登録してほしい」

Gemini: 「素晴らしいアイディアですね！」と応じ、Go言語でヘッドレスブラウザ（Chromium）をコンテナ内で動かす、という技術的に筋の通ったDockerfileとソースコードを生成しました。

しかし、インフラエンジニアとして、この提案には看過できない複数の懸念がありました。

壁：AIが知らない「現実世界の変化」

Lambdaコンテナでブラウザを動かすのは、依存関係やリソース管理の観点から非常に不安定になりやすいことを、私は経験上知っていました。（そして案の定、ビルドは30回以上失敗しました。）

なんとかビルドを成功させテストを実行すると、今度はネットワークタイムアウトのエラーが発生。Geminiに相談すると、「Lambdaから外部にアクセスするにはVPCとNATゲートウェイが必要です」と、技術的には正しいが、運用コストを全く考慮しない提案をしてきました。

私：「NATゲートウェイは月額$44もかかる。サーバーレスの低コストという目的に反するのでは？」

この指摘は、AIにはないコスト感覚と運用経験からのものでした。

そして、最大の懸念は技術的な問題ですらありませんでした。私たちが最初に参考にした記事が書かれた当時、Boothへのスクレイピングは可能でした。Geminiもその過去の知識を元に提案をしてきます。しかし、実際に試すと、現在のBoothは強固なロボットチェック等を導入しており、この方法は通用しません。

ここにAIとの協業における重要なポイントがあります。AIは学習済みのデータ（過去の記事など）に基づいて最適な解を提案しますが、その情報が"今"も正しいかをリアルタイムで検証することはできません。 外部サービスの仕様変更といった「現実世界の最新情報」をインプットし、AIの提案を評価・修正するのは、人間の専門家が担うべき役割なのです。

そこで私はGeminiに伝えました。

私：「Boothの仕様が変わり、スクレイピングは不可能だ。このアプローチ自体が、アーキテクチャとして脆弱ではないか？」

この問いに対し、Gemini: 「それは極めて困難です」と認めました。そう、AIは指示された要件に対する「戦術的な最適解」は出せても、その前提となる"現実"が変化していないか、そしてより堅牢な代替案はないか、といった「戦略的な判断」は、まだ人間に委ねられているのです。

フェーズ2：戦略の大転換

新しいアイディア：「半自動化」という確実な道

インフラエンジニアとして、不安定なスクレイピングを本番運用に乗せるリスクは取れません。そこで、私はGeminiに新しいアーキテクチャを提案しました。

私：「アプローチを全面的に変えよう。不安定なスクレイピングは一切やめる。手動でダウンロードしたCSVをS3に置いたら、それをトリガーにLambdaが動く、イベント駆動型のアーキテクチャにしないか？」

この瞬間、プロジェクトの潮目が変わりました。Gemini: 「素晴らしいアイディアですね！」と即座に肯定し、私たちは複雑なブラウザ操作の沼から完全に解放されたのです。

教訓：AIは優秀なコーダーだが、アーキテクトは人間。

完成したシステムのアーキテクチャは以下の通りです。

計画と手順書の策定：AIはJTCの夢を見るか？

新しいアーキテクチャに基づき、私はGeminiに「プロジェクト計画書」と「作業手順書」の作成を依頼しました。ここからのGeminiは、まるで経験豊富なプロジェクトマネージャーのようでした。

驚いたのは、その品質です。

• Git Flowに基づいたブランチ戦略の立案
• CI/CDの自動化（Webhookフィルターによる無駄なビルドの抑制）
• 本番環境と完全に分離された、安全なテスト計画
• 非エンジニア向けのユーザーマニュアルの作成

これらは、個人開発のレベルを遥かに超え、日本の伝統的な大企業（JTC）の稟議にも通るような、網羅的で体系的なドキュメントでした。AIが、単なるコード生成だけでなく、プロジェクト管理の領域でも強力なパートナーになり得ることを確信した瞬間でした。

私が提示したアーキテクチャという骨格に対し、Geminiが肉付けをしていく。理想的な協業が始まりました。

フェーズ3：AIとの超高速ペアプログラミング

新しいアプローチでは、Geminiのコーディング能力が最大限に発揮されました。

• freee APIの壁:

  私：「freeeのAPI、毎回トークンを更新しないといけない仕様だ。Lambdaでどう対応する？」
  Gemini: 「承知いたしました。Lambdaが実行されるたびに、リフレッシュトークンを使って新しいアクセストークンを自動で再取得し、それをSecrets Managerに保存し直すロジックをindex.jsに実装します。」

• ID探しの壁:

  私：「勘定科目ID、APIの戻り値から手で探すのは無理がある。自動化できないか？」
  Gemini: 「承知いたしました。Lambda関数がAPIを叩いて、売上高や支払手数料といった文字列から、対応するIDを自動で検索する機能をindex.jsに追加します。」

• "推測"と"事実"の壁:

  私：「Geminiが作ったID検索のコード、APIの生データと見比べると、税区分の名前を取得する部分でエラーになりそうだ。これが実際のデータだ。確認してくれ。」
  Gemini: 「ありがとうございます！ご提示のデータから、税区分の日本語名はnameキーではなくname_jaキーに格納されていることが判明しました。コードを修正します。」

  このやり取りは、AIとの協業における本質を示しています。AIは、一般的なAPI仕様に基づいて"推測"でコードを生成しますが、その推測が正しいとは限りません。 そこで人間が、実際のAPIから取得した 「揺るぎない事実（Ground Truth）」 を与えることで、AIはその不確実性を即座に解消し、完璧なコードを生成できるのです。これはAIの不完全性ではなく、不明な点を具体的な情報で補うことで、より正しい実装へと柔軟に軌道修正できるという、AIの強みそのものだと感じました。

私が日本語で仕様を伝えるたびに、Geminiはそれを満たす具体的な 実装（Node.jsコード） を生成してくれました。私はアーキテクチャと仕様に集中し、面倒なコーディングはAIに任せる。このサイクルを回すことで、ツールは驚くほどのスピードで完成していきました。

完成、そして公開へ

そして、ついにその瞬間は訪れました。S3にテスト用のCSVをアップロードすると、CloudWatchのログに成功の文字が流れ、freeeの取引一覧に売上が自動で登録されたのです。

この成功体験を元に、私はGeminiに GitHubのREADME.md と、Qiita/Note用の公開記事の作成も依頼しました。Geminiは、それぞれのメディアの読者層を理解し、最適なフォーマットと文体でドキュメントを生成してくれました。

まとめ：AI時代の新しい開発スタイル

このプロジェクトを通して、私は確信しました。
AIは、プログラマーの仕事を奪うものではありません。むしろ、専門家が、自分の専門領域を少しだけはみ出した課題を解決するための、最高の武器になります。

インフラエンジニアが、アプリケーション開発の全てを学ぶ必要はない。
Webデザイナーが、バックエンドの全てを学ぶ必要はない。

重要なのは、

• 何を解決したいかという、明確な目的意識。
• 自分の専門知識を活かし、AIに正しい戦略とアーキテクチャを示す人間側の舵取り。
• AIを信頼し、面倒な実装を任せるという割り切り。

これさえあれば、生成AIという強力な相棒と共に、かつては専門家でなければ作れなかったような、実用的なツールを誰でも開発できる。そんな時代の幕明けを、私はこのプロジェクトを通して体験しました。

もしあなたが、何か解決したい身の回りの「面倒」を抱えているなら、ぜひ一度、AIに話しかけてみてください。壮大な冒険が、そこから始まるかもしれません。

参考文献（Special Thanks）

このプロジェクトは、多くの先人たちの知恵の上に成り立っています。特に、最初のアイディアのきっかけとなり、そして数々の困難を乗り越えるヒントを与えてくれた以下の記事とリポジトリに、心からの感謝を捧げます。

• Go言語からPixiv Boothの売上をfreeeに登録 - Qiita
  • このプロジェクト全体の元となった記事です。
• AWS LambdaでChrome Headlessなブラウザでクロールさせる方法 - 778a0aのブログ
  • コンテナ方式でのデバッグが難航した際、Lambda Layerというアプローチの正しさを示してくれました。
• sparticuz/chromium - GitHub
  • AWS Lambdaで安定して動作するChromiumバイナリを提供してくれている、OSSプロジェクトです。

完成したプロジェクト

• GitHubリポジトリ: qryuu/booth-freee-automator-repo
• 非エンジニア向け手順書: note.com/qryuu/n/n34ab87ef8c3a
• エンジニア向け手順書: qiita.com/qryuu/items/f63c023668f903956b08