作って、捨てて、また作る - Claude Code に社内ツールの開発を丸ごと任せた49日間の記録

こんにちは。小売流通ソリューション部 SRE チームの池田です。
以前、Claude Code でセキュリティチェックツールを作った体験記を書きました。
今回はその経験を踏まえて、より大きな規模の業務ツールに挑戦した記録です。

2026年1月29日から3月18日までの49日間、Claude Code にほぼ全ての開発作業を委ねて、社内向けの業務ツールを作りました。途中でアーキテクチャを丸ごと変え、プランの壁にぶつかってプロジェクトを仕切り直し、最終的にはプラットフォームの限界に当たって本番採用を見送るという結末になりました。その過程を時系列で共有します。

何を作ろうとしたのか

私たちの部門では、AWS アカウントへのアクセス権限を管理する業務フローがあります。「この日、このアカウントに、この業務のため、こういう権限でアクセスしたい」という申請を起票し、承認されたら AWS IAM の権限が自動で付与される、という仕組みです。

これまでとあるノーコードツール上に3つのアプリ（ユーザー管理台帳、AWS アカウント管理台帳、アクセス許可申請）を作って連携させて運用していたのですが、アプリの作者が既に退職し、ブラックボックス的な部分がいくつかあったことに加えて GitHub PR を起点とした権限付与フローも並存しているため、統合したいという課題がありました。

事前調査 — Deep Research と Gemini（1/29 〜 2/2）

1月29日 — 3つのレポートを依頼する

プロジェクトの第一歩目は、今回もコードを書くことではなく調査でした。

Deep Research に3つの調査レポートを依頼しました。AWS Fargate のベストプラクティス、Terraform + Atlantis でのデプロイ管理、そして一時的な IAM 権限昇格システムの構築方法です。3つ目のプロンプトは Gemini に「既存の運用方式を伝えて、何を調査すべきか考えてもらう」ところから作りました。

Gemini からはヒアリングシート形式で質問が返ってきました。「最大利用時間は？」「自動デタッチのトリガーは？」「認証基盤は？」。これに回答を埋めていくと、要件の輪郭が自然と固まっていきました。

この段階では構成は AWS Fargate + DynamoDB + Step Functions を想定していました。VPC エンドポイント経由の閉域網で、Google Workspace SSO で認証する構成です。

Fargate 構成での最初の挑戦（2/3 〜 2/13）

2月3日 — Claude Code で開発開始

事前調査の成果物を Claude Code に渡し、tsumiki プラグイン（Claude Code に TDD の開発サイクルを指示するための OSS で公開されているプラグイン）のワークフローに乗せて開発を始めました。要件定義 → 設計 → タスク分割 → TDD で順に実装、という流れです。

その日のうちにローカルでの開発が一通り完了しました。ただ、出来上がったドキュメントを読んでいて、何か違和感がありました。もう少し事前情報を充実させた方がいいと感じて、PRD を修正し、既存システムのスクリーンショットや HTML を参考資料として追加した上で、やり直しました。

Gemini にも要件定義の出力を読ませたところ、考慮漏れを2点指摘されたので、それも反映しました。

2月6日、2度目のタスク分割が完了しました。

プランの壁 — MAX100 の限界

ここで問題が起きました。Claude Code のトークン消費量です。

当時の契約は MAX100 プラン。調査、PRD 作成、設計ドキュメントの生成、タスク実装と、Claude Code にやってもらうことが多く、ほぼ毎回のセッションにおいて2時間前後でセッションリミット（5時間制限）に到達しました。制限解除までの3時間は自分にしかできない別業務のタスクを進めていましたが、2月9日には週間の利用制限（全てのモデル）にも到達してしまいました。2月10日にリセットされて再開しましたが、2月13日にはまた週間制限が間近に...

勤務時間のほとんどで Claude が使えない。これでは開発が進みません。

2月13日 — アーキテクチャ転換の判断

週間制限到達を目前にした2月13日、ふと考えました。

「GAS ウェブアプリにした方が、運用コストを大幅に削減できるのではないか」

Fargate 構成の場合、VPC、ALB、NAT Gateway、Fargate タスク、DynamoDB を利用することになり、月額の固定費だけでも数万円規模になる見込みでした。対して GAS なら Google Workspace の既存ライセンスに含まれており、追加コストはゼロです。
そのため、どうせ挑戦するのであれば固定コスト削減の可能性が高いものから着手してはどうかと考えました。

「高速に挑戦し、高速に失敗し、高速に改善する。そのためにも、このプロジェクトを完了するまでの1ヶ月間、MAX200 プランを使わせてほしい」と上司に相談し、承認を得ました。アーキテクチャ転換とプランのアップグレードを同時に行い、プロジェクトを v3 として仕切り直すことにしました。

GAS SPA として再出発（2/14 〜 2/16）

捨てたプロジェクトの資産を引き継ぐ

着想当初の Fargate 構成とはアーキテクチャが全く違いますが、調査ドキュメント（既存アプリのデータ構造定義書、移植方針書、セキュリティルール）はそのまま使えます。これらを新しいプロジェクトに持ち込み、Claude Code に改めて GAS SPA としての設計とタスク分割を依頼しました。

MAX200 プランに変わったことで、セッションの余裕が段違いです。Fargate 構成時では2時間程度でセッションリミットに到達して、3時間程度のリセット待ちが発生していたような場面が多くありましたが、v3 では設計とタスク分割までが2日で終わりました（それでも何度かは5時間のプラン使用制限に到達してしまいましたが、待ち時間は長くて1時間程度で済みました）。

111件のタスクに分割

Claude Code が出した計画は、111件のタスクを4フェーズに分けて実装するというものでした。

• Phase 1（23タスク）: 共通基盤 — 型定義、リポジトリ層、サービス層
• Phase 2（34タスク）: バックエンド — API ルート、認証、権限管理
• Phase 3（43タスク）: フロントエンド — React コンポーネント、画面、状態管理
• Phase 4（11タスク）: 仕上げ — E2E テスト環境、CSS、型エラー解消

Phase 1 〜 2 バックエンド実装（2/17 〜 2/20）

2月17日 — TDD が回り始める

TASK-0001（プロジェクト初期設定）から開発が始まりました。

tsumiki プラグインの TDD ワークフロー（Red → Green → Refactor）を使い開発するよう指示すると、まずテストを書いて失敗させ、次に実装して全テストを通し、最後にリファクタリングするという一連のサイクルを Claude Code が自走します。

この日、TASK-0001 から TASK-0020 まで一気に進みました。型定義、共通設定、スプレッドシートスキーマ、リポジトリの基底クラスなど、アプリケーションの骨格にあたる部分です。

2月18日〜20日 — 34タスクが3日で終わる

Phase 2 のバックエンド実装は、リポジトリ層、サービス層、API ルーティング（Hono）を含む34タスクでした。

Claude Code の作業スタイルは一貫していて、各タスクに対して要件定義 → テストケース設計 → Red → Green → Refactor → 完了確認 という流れを繰り返します。自分はテスト結果を眺めて「次へ」と答えるか、設計判断が必要な場面で方針を伝えるくらいでした。

権限付与の仕組みは、GAS から既存の AWS Lambda を HTTP で呼び出し、Lambda が IAM ポリシーのアタッチ/デタッチを行う構成です。Claude Code が担当したのは GAS 側の呼び出しロジック、ステータスの先行更新と失敗時のロールバック、監査ログの記録です。

2月20日、Phase 2 の全34タスクが完了。テスト数は約1,200件に達していました。

Phase 3 フロントエンド実装（2/20 〜 2/25）

Phase 3 は最大の43タスク。React 18 + TypeScript で、申請一覧画面、申請詳細画面、新規申請フォーム、管理者向けのユーザー管理画面と AWS アカウント管理画面を作っていきます。

Claude Code がコンポーネントを作るときも TDD スタイルを維持していました。状態管理は useReducer + Context で、ページネーション、楽観的ロック、ロールベースのアクセス制御など、業務アプリとして必要な要素は一通り入っています。

CSS は BEM 命名規則の単一ファイル管理で、Claude Code が1つのファイルに全スタイルを書いていく方式でした。画面デザインは既存システムのUIを参考にして考えてもらい、HTMLファイルとして出力してもらっては欲しいボタンを依頼したり、人間には読みにくい部分などを修正してもらいながら進めていきました。

その後、ある程度画面が出来上がってきたので実際に GAS 環境へデプロイして実際の画面を触りながら改善指示を出したり、実装が完了しているはずの機能が動作しない不具合などの指摘を行い修正してもらう。という、一貫してコードは書かずに結果を見て修正指示を出す。というスタイルで進めました。

2月25日、Phase 3 が完了。テスト数は約2,300件になりました。

Phase 4 仕上げ（2/25 〜 2/26）

型エラー491件を1セッションで解消

Phase 4 は E2E テスト環境の構築、CSS の全コンポーネント対応、そして TypeScript の型エラー解消です。

特に印象的だったのが TASK-0111 で、TypeScript コンパイラが出力している491件の型エラーを Claude Code が1セッションで全て解消したことです。型の不整合、missing imports、ジェネリクスの推論ミスなど、種類はバラバラでしたが、淡々と片付けていきました。
これはおそらく私に TypeScript での開発経験がないことによる考慮漏れが原因で発生していたんだと思います。

2月26日、Phase 4 が完了。全111タスク、テスト2,392件がパスしました。

三度目の正直で挑んだ開発は、着手から実装完了まで、10日間でした。

Lambda のデプロイと PR レビュー（3/9 〜 3/17）

GAS だけでは完結しない

111タスクが完了した時点で、GAS 側のアプリケーションは動作していました。画面表示、ログイン、データの CRUD は問題ありません。ただし、肝心の権限付与機能はまだ使えませんでした。GAS から呼び出す先の Lambda が、本番環境にデプロイされていなかったからです。

権限付与の仕組みは、GAS → API Gateway → Lambda → IAM という経路を辿ります。Lambda は既存のものを複製して GAS SPA 用に調整する方針で進めていて、Terraform で管理します。この作業も Claude Code に任せました。

3月9日〜10日 — Terraform コードの作成と PR

3月9日、Claude Code が Terraform モジュールにクロスアカウントロールの定義を追加しました。翌3月10日には、environments リポジトリに Lambda・API Gateway・IAM リソースの Terraform コードを追加して PR を作成しました。

約1週間の PR レビュー対応

PR に対してチームメンバー2名からレビューコメントをもらいました。

• ディレクトリ構造を既存の Lambda と統一してほしい
• IAM ポリシーの AttachRolePolicy/DetachRolePolicy に PolicyARN 条件キーを追加すべき
• Python ランタイムのバージョン表記を統一してほしい
• 未使用の変数や権限を削除してほしい

レビュー指摘への対応も Claude Code に任せました。指摘内容を伝えると、修正コミットを作って push するところまで自走します。

さらに、GAS が Lambda を呼び出すための IAM アクセスキーを Terraform で管理する必要がありました。アクセスキーの SecretAccessKey が Terraform の State ファイルに平文で記録されるセキュリティ上の問題を回避するため、PGP 暗号化で保護する対応を追加しました。これも Claude Code が実装し、別の PR として提出してレビューを受けました。

PR レビューでは、同僚が個人的に作成していたレビュー用の Claude Code Skill が活躍してくれました。
この工程に1週間ほどかかったのは、私を含めた関係メンバーの他の業務予定の都合によるもので、Claude Code に出した依頼はものの数分で対応され続けていました。

3月17日、全ての PR がマージされ、Lambda が本番環境にデプロイされました。

パフォーマンスの壁（3/17 〜 3/18）

3月17日 — 全てが繋がった、しかし

Lambda がデプロイされ、ようやく申請から権限付与までの一連のフローが動くようになりました。

実際に操作してみると、機能としては問題なく動きます。申請を起票し、ボタンを押すと Lambda が呼ばれ、IAM ポリシーがアタッチされる。利用完了ボタンを押せばデタッチされる。想定通りです。

ただ、遅い。

ページを開くたびに3〜5秒待たされ、申請ボタンを押してから完了するまで10秒以上かかります。ローカルの開発サーバーではサクサク動いていたので、大変驚きました。

原因は構造的なものだった

Gemini に質問したところ、GAS で SPA を動かす場合、フロントエンドからサーバーへの通信は google.script.run という同期的な RPC を使います。1回のリクエストごとに2〜3秒のオーバーヘッドがあり、ページ表示時に複数の API を呼ぶとそれが積み重なります。

さらに、権限付与の処理では GAS → Lambda → AWS IAM という経路を辿るため、UrlFetchApp の HTTP コールが追加されます。合計で1回の申請操作に8〜12秒必要でした。

3月18日 — 改善を試みる

Claude Code に性能分析を依頼し、改善案を8件リストアップしてもらいました。そこから優先度の高い3件を実施しました。

1. キャッシュ軽量化: GPG 公開鍵をキャッシュから除外し、GAS の CacheService 100KB 制限内に収める
2. 楽観的 UI 更新: API レスポンスを待たずにフロントエンドのステータス表示を即座に変更
3. 付随処理の保護: Lambda 成功後の監査ログ記録を try/catch で囲み、付随処理の失敗で成功レスポンスが失われないようにする

残りの5件は、既存の Lambda にも影響が出る内容だったため今回は見送ることとしました。
結果として体感は改善されましたが、根本的な問題は変わりませんでした。google.script.run の2〜3秒のオーバーヘッドは GAS のアーキテクチャそのものであり、最適化の余地がありません。

業務ツールとして「使えなくはない」けれど、既存のノーコードツールと比べて体感速度が劣る場面があることがわかりました。部内のエンジニアメンバーは毎日たくさんの申請を出し、多くの業務をこなしてくれていますので、1つの申請にこれだけ時間がかかってしまうのは業務パフォーマンス低下に直結してしまいます。これでは、既存ツールから移行する理由がありませんでした。

本番採用の見送り、そして次へ

3月18日、本番採用を見送る判断をしました。

理由はシンプルで、パフォーマンス特性が今回の業務ツールの要件と合わなかったことです。機能面ではノーコードツールの3アプリと GitHub PR による申請フローを1つのシステムに統合できていましたが、レスポンスタイムがユーザー体験として許容できるラインに届きませんでした。

今後は、AWS サーバレス構成で作り直す予定です。v3 で得た資産は3つあります。
1つ目は、業務フローを整理した設計ドキュメント。申請・承認・権限付与のステータス遷移やロールバックの考慮は、プラットフォームが変わっても同じです。
2つ目は、2,755件のテストケースが定義した仕様そのもの。テストが「何を満たせば正しいか」を記述してくれているので、新しい環境でもゴールが明確です。また、計画通りに進めた結果で動作検証をして初めて認識した不具合や考慮漏れへの対応ログも、同じミスを繰り返さないために有用です。
3つ目は、Claude Code への依頼のコツ — どこまで任せて、どこで人間が判断すべきかの感覚です。

49日間で「作って、捨てて、また作る」を体験しましたが、AI と一緒に開発する以上、このサイクルの速さこそが最大の武器だと感じています。
なので、今後も作って、捨てて、また作るを続けていくつもりです。

数字で振り返る

計画した111タスクに加え、動作確認で見つかった不具合修正やPRレビュー対応なども含めると、実際の作業量はそれ以上でしたが、これらのファイルほぼ全てを Claude Code が書きました。自分がコードを直接書いた場面はありません。
自分の役割は、方針を決めること、設計判断をすること、Claudeの提案や実行確認を承認または否認すること、動作確認をすること、そして「本番には出せない」と判断することでした。

Claude Code に丸ごと任せて分かったこと

うまくいったこと

TDD との相性が抜群に良い。 Claude Code は「テストを先に書いて、通るように実装して、きれいにする」というルールを示せば、そのサイクルを忠実に繰り返します。111タスクを通じてこのリズムが崩れることはありませんでした。テストが常に存在するので、後からの修正で既存機能が壊れたときも即座に検知できました。

調査能力が高い。 既存アプリを Playwright MCP（Claude Code からブラウザを操作して画面の構造やデータを読み取る仕組み）で調べ上げてドキュメント化する作業は、人間がやると丸1日はかかるような内容でしたが、Claude Code は数分で完了しました。

AI を組み合わせると精度が上がる。 Deep Research で技術調査、Gemini で要件の穴を見つけ、Claude Code で実装する。それぞれの得意領域を使い分けることで、1人では見落としがちな考慮漏れを防げました。

うまくいかなかったこと

実環境のパフォーマンスは予測できない。 ローカルのテスト環境では全てが高速に動作します。GAS にデプロイして初めて分かる遅延は、Claude Code には見えていませんでした。技術選定の時点で GAS のパフォーマンス特性をもっと深く検証すべきでした。これは Claude Code の問題ではなく、自分の判断ミスです。

「動くものを早く見る」が遅れた。 111タスクを全て完了してからデプロイした結果、パフォーマンス問題の発覚が遅れました。Phase 1 が終わった時点で Lambda をデプロイして感触を確かめていれば、もっと早い段階で方針転換できたはずです。一方で、既存の本番環境に影響を与えたくないという心理から Lambda のデプロイは可能な限り最後の方で行うという判断も間違えてはいなかったとも思っています。

振り返って気づいたこと

プランの選択は早めに相談する。 大規模な開発プロジェクトを Claude Code に任せるなら、トークン消費量がボトルネックになり得ます。
v2 では順調に進んでいるように見えていながら、週の半ばで手が止まるという状況を繰り返しました。MAX200 に切り替えてからはこの問題はほぼ解消しましたが、もう少し早い段階で上司に相談していれば、v2 の時点でもっと進められていた可能性があります。

捨てることは悪くない。 このプロジェクト以外でも、作って、捨てて、また作るを何度も繰り返してきていますが「作ったものを全て捨てる」のではなく、「作ったけどツールとしては使わない」という判断をしているだけです。ツールとしては使わないですが、作る過程で得た資産と経験は必ず次に役立っています。

まとめ

• Claude Code に社内業務ツールの開発を49日間、丸ごと任せた
• Deep Research と Gemini で調査し、Claude Code で実装する AI の使い分けを実践した
• Fargate → GAS へのアーキテクチャ転換を経て、v3 として10日間で111タスク・2,755件のテストを完遂した
• パフォーマンス面での理由により本番採用は見送った
• コード資産を活かして AWS サーバレスで作り直す次のプロジェクトを始める

この体験記は失敗談ですが、私が実践したことや直面したことなどここでご紹介した何か一部でも、業務ツールを改善したい、ツールのコストを削減したい、といった課題解決の一助になる場面があれば幸いです。
もしもサーバレスでの開発でもMAX100プランだと足りない気配を感じたら、早いタイミングでMAX200への再アップグレードを相談しようと思います。