GLM-5.2に7000行のAP設計書を丸投げしたら、Lite PlanはどこでLimitになるのか

GLM-5.2をClineから使えるようにしたので、次の実験として「自分の事業で使う勤怠アプリの設計書を、かなり大きめに渡したらどこまで進むのか」を試しました。

今回渡したのは、約7000行のAP設計書です。ざっくりしたアイデアメモではなく、「これがあれば自分でもアプリを作れる」くらいの粒度まで書き込んだものです。画面、業務ルール、技術選定、環境構築の前提、実装してほしい範囲をまとめたうえで、Dockerコンテナ未作成の状態から、環境構築とアプリ製造までまとめて依頼しました。

結論から言うと、GLM-5.2 Lite Planでも、Docker環境の作成、PHP/Laravel向けコンテナ構成、ビルドエラーの原因調査、Dockerfile修正、再ビルド、コンテナ起動確認までは進みました。ただし、アプリ本体の本格実装に入る前後の段階で、5時間枠のLimitに到達して止まりました。

この記事では、GLM-5.2の性能をベンチマークとして断定するのではなく、ひとりのフリーランスSEが「長い設計書をAIコーディングエージェントに丸投げしたら、Liteプランではどのくらいのボリュームで上限に近づくのか」を実測ログとして残します。

今回の実験で知りたかったこと

AIコーディングエージェントを使っていると、短い依頼はかなり現実的にこなせるようになってきました。1ファイルの修正、エラー原因の調査、設定ファイルの補完、READMEの整理などは、すでに普段の作業に入り込んでいます。

一方で、実務に近づけるほど気になるのは、もっと長い依頼です。

• 設計書を丸ごと読ませたら、文脈を保ったまま実装に入れるのか
• Docker環境がない状態から、環境構築も含めて進められるのか
• エラーが出たときに、自分でログを読み、原因を見つけ、修正できるのか
• Liteプランでは、どのくらいの作業量で5時間Limitに届くのか
• 今後、AIに大きな開発を任せるなら、どこで作業を分割すべきか

特に最後の「どこで作業を分割すべきか」は、個人開発ではかなり大事です。AIが長文脈に強くなっても、利用プラン、ツール側の制限、実行時間、ローカルPCの状態、Dockerビルド時間など、現実の制約は残ります。今回の実験は、その現実ラインを知るためのものでもありました。

前提条件

実験開始時点のローカル環境は、かなり素の状態です。

• Docker Desktopはインストール済み
• 対象アプリ用のコンテナは未作成
• 勤怠アプリのAP設計書は約7000行
• GLM-5.2 Lite Planの使用量は0から開始
• ClineからGLM-5.2を利用

技術選定は、次のようにしました。

領域	採用技術
バックエンド	PHP 8.3以上
フレームワーク	Laravel
フロントエンド	Blade + Tailwind CSS + 最小限のJavaScript
開発環境DB	SQLite
本番環境DB	MySQL または MariaDB

ただし、実際のClineログを見ると、Docker構成ではMySQLコンテナも立ち上がっています。ここは、開発環境をSQLite中心にする設計と、将来の本番構成やDocker構築時の判断が混ざった可能性があります。記事としては「最初に渡した技術選定」と「AIが実際に構築し始めた環境」を分けて記録しておくのが大事だと感じました。

GLM-5.2とClineに期待した理由

Z.AIの公式ドキュメントでは、GLM-5.2は長時間・長文脈の開発タスクを想定したモデルとして説明されています。1Mトークンのコンテキスト、128Kの最大出力、thinking mode、function call、context caching、structured output、MCP対応などが挙げられており、プロジェクト規模のエンジニアリング文脈を扱うことが用途として示されています。

公式の説明では、要件からデプロイ可能なプロダクトまで、長い開発ワークフローを1つのタスクとして進める方向性も示されています。これは、今回のような「設計書を渡して、環境構築から製造に入る」実験と相性がよさそうに見えました。

また、Cline公式ドキュメントでは、Clineはエディタやターミナル内で動き、ファイルを読み、コードを書き、コマンドを実行できるAIコーディングエージェントとして説明されています。ただし、各操作にはユーザーの承認が入ります。自分としては、この「AIに任せるが、要所は人間が確認する」形が、個人開発ではちょうどよいと感じています。

ただし、長文脈に強いモデルだからといって、何でも一度に投げればよいわけではありません。Z.AIのGLM Coding Planの説明では、Lite Planは5時間あたり最大約80プロンプト、週あたり最大約400プロンプトという目安が示されています。さらに、1つのプロンプトが内部的にはモデルを複数回呼び出すことがあり、実際の利用可能量はプロジェクトの複雑さ、リポジトリサイズ、auto-acceptの有無などで変わるとされています。

今回の実験は、まさにこの「実際にはどのくらい消費するのか」を体で覚えるための作業でした。

依頼した内容

今回Clineに渡した依頼は、単純なコード生成ではありません。勤怠アプリをローカルで作成するために、約7000行の設計書を読み込ませたうえで、環境構築からアプリ製造まで進めるものです。

作業範囲を人間の言葉に直すと、次のような依頼になります。

• 設計書を読み、勤怠アプリの全体像を把握する
• Laravelで開発できるDocker環境を作る
• PHP 8.3以上、Laravel、Blade、Tailwind CSSを前提にする
• DBは開発ではSQLite、本番ではMySQLまたはMariaDBを想定する
• 必要なコンテナ構成を作成する
• Dockerビルドや起動でエラーが出たら調査して直す
• 環境が立ち上がったらアプリ実装に着手する

これは、AIにとってかなり重い依頼です。設計書の読解、技術選定の解釈、Docker構成、Laravel環境、PHP拡張、ログ確認、修正、再ビルドがひとつながりになっています。人間でも、最初のセットアップだけでそれなりに時間がかかる作業です。

Clineログから見えた作業内容

今回のチャットログから、Clineが実際に何をしていたかを整理すると、主に次の流れでした。

1. Docker Composeで勤怠アプリ用のコンテナ群を起動
2. ビルドログを確認
3. PHP拡張のビルドエラーを検出
4. Dockerfileに不足パッケージを追加
5. 再ビルドをバックグラウンドで起動
6. 一定時間待機しながらログとコンテナ状態を確認
7. PHP拡張のコンパイル進捗を読み取る
8. 最終的に新しいアプリ用イメージとコンテナ起動を確認
9. その直後に5時間Limitに到達

ログに出ていたコンテナ名を見ると、少なくとも次のコンテナが作られていました。

コンテナ名	役割
kintai-web	nginx
kintai-app	PHP/Laravelアプリ側
kintai-db	MySQL
kintai-node	Node.js/Tailwindなどのフロントエンドビルド用途
kintai-mail	Mailpit

ローカル開発用としては、かなり自然な構成です。nginx、PHP-FPM、DB、Node、Mailpitが分かれており、Laravel開発環境として見慣れた形になっています。

最初に詰まったのはPHPのintl拡張

ビルドログの中で、Clineが最初に見つけた問題はPHPのintl拡張でした。

ログ上では、intl拡張をビルドするにはlibicu-devパッケージが必要であり、Dockerfileのapt-getに追加する、という判断をしています。その後、Dockerfileにlibicu-devを追加し、再ビルドに入りました。

ここは、AIコーディングエージェントの実用性を感じたところです。LaravelやPHPのDocker環境を作っていると、intl、mbstring、zip、gd、bcmathなど、拡張まわりでつまずくことがあります。エラー文を読んで不足パッケージを探し、Dockerfileを直し、再ビルドする流れは、人間がやっても地味に時間を使います。

今回、Clineはログを読み、原因を推定し、必要なパッケージを追加し、再ビルドまで進めました。これは「AIがコードを書いた」というより、「環境構築で発生した典型的な詰まりを、開発者の代わりに処理した」と見る方が近いです。

再ビルド中にかなり時間を使った

その後のログでは、再ビルドの進捗確認が何度も行われています。ClineはStart-Sleepで70秒、90秒、100秒、110秒と待機しながら、rebuild.logの行数やdocker ps、docker imagesを確認しています。

この時点で、実際の作業時間のかなりの部分は、AIの思考時間というよりDockerビルド待ちです。PHP拡張のコンパイルでは、bcmath、mbstring、intl、opcacheといったステップが進みます。ログにも、bcmathのconfigure、mbstringのコンパイル、intlのC++コンパイル、opcacheのconfigureといった進捗が出ていました。

ここで気づいたのは、AIコーディングエージェントの利用量は、単純な「人間が送ったメッセージ数」だけでは見積もれないということです。

環境構築タスクでは、AIが次のようなことを繰り返します。

• コマンドを提案する
• 人間が承認する
• しばらく待つ
• ログを読む
• 状態を判断する
• 必要なら次の確認コマンドを出す
• また待つ

このループは、エラーが出れば出るほど長くなります。しかも、Dockerビルドのように時間がかかる処理では、待機と確認だけでも5時間枠をじわじわ使います。

最終的にどこまで進んだか

ログの終盤では、mr_kintai-appのDockerイメージが更新され、kintai-appコンテナが新しく起動していることが確認できました。つまり、最初に詰まったPHP拡張まわりの問題は乗り越え、Laravelアプリを動かすためのコンテナ構成はかなり進んだと見てよさそうです。

一方で、ここでGLM-5.2 Lite Planの5時間Limitに到達しました。表示されたメッセージでは、利用上限に達し、リセット時刻まで待つ必要がある状態でした。

今回の実験を一言でまとめるなら、次のようになります。

約7000行のAP設計書を渡し、コンテナ未作成の状態から環境構築とアプリ製造をまとめて依頼すると、Lite PlanではDocker環境の構築と初期トラブルシュートだけで5時間枠を使い切る可能性がある。

もちろん、これは今回のローカル環境、設計書の量、Dockerビルド時間、承認の仕方、Clineの進め方に依存します。すべての人が同じ結果になるわけではありません。ただ、「大きな設計書を渡せば、Liteでも一気にアプリ完成まで行ける」と考えるのは、少し期待値が高すぎると感じました。

Lite Planの上限感として分かったこと

今回の一番の収穫は、GLM-5.2 Lite Planの使いどころが少し見えたことです。

Z.AI公式ドキュメントでは、Lite Planの目安として5時間あたり最大約80プロンプト、週あたり最大約400プロンプトとされています。ただし、1プロンプトが内部的に複数回モデルを呼び出すこと、実際の利用可能量はプロジェクトの複雑さやリポジトリサイズなどで変わることも説明されています。

今回のように、設計書が長く、Docker環境も未作成で、さらにビルドエラーの調査と再ビルド監視が入ると、見た目以上に重い作業になります。人間が送った依頼は大きく1つでも、AI側では設計書理解、ファイル作成、コマンド実行、ログ読解、エラー修正、再確認が何度も発生します。

そのため、自分の感覚では、Lite Planは次のような使い方に向いていそうです。

• 既存コードの部分修正
• 小さめの機能追加
• DockerやLaravelのエラー調査
• 設計書の一部を実装タスクに分解する
• READMEや作業手順の整理
• 短時間で終わる検証タスク

逆に、Lite Planで慎重に扱いたいのは、次のような依頼です。

• 数千行以上の設計書を一度に渡す
• 環境構築からアプリ完成まで一気通貫で任せる
• Dockerビルドや依存関係解決を含む
• 大量のファイル生成を伴う
• エラー調査、再ビルド、再実行を何度も繰り返す

このあたりは、Lite Planが悪いという話ではありません。むしろ、ここまで進められること自体はかなり面白いです。ただ、利用枠を意識するなら、作業単位を分けた方が現実的です。

AIコーディングエージェントはトークンを予想しにくい

今回の体験は、AIコーディングエージェントのトークン消費が予想しにくい、という最近の研究とも感覚的に合っています。

2026年4月に公開された「How Do AI Agents Spend Your Money?」という論文では、エージェント型のコーディングタスクは通常のコード推論やコードチャットよりもトークン消費が大きくなりやすく、同じタスクでも消費量に大きなばらつきが出ると報告されています。また、タスクの難しさを人間が見積もる感覚と、実際の計算コストが必ずしも一致しない点も指摘されています。

今回の実験でも、自分の感覚では「設計書は長いけれど、まず環境構築からならいけるかな」と思っていました。しかし実際には、Dockerビルド、PHP拡張、ログ確認のループだけでもかなりの消費になりました。

これは、AIに開発を任せるときの大事な教訓です。人間にとっては「環境を作ってからアプリを作って」と一文で言える依頼でも、AIにとっては大量の読み取り、判断、ツール実行、確認が積み重なるタスクになります。

次に同じことをするなら分割する

今回の結果を踏まえると、次に同じような個人アプリ開発をAIに任せるなら、最初から作業を分割します。

たとえば、次のような単位です。

1. 設計書の要約と実装タスク分解だけを依頼する
2. Docker環境構築だけを依頼する
3. Laravelの初期セットアップだけを依頼する
4. DB設計とマイグレーション作成だけを依頼する
5. 認証・ユーザー管理だけを依頼する
6. 勤怠打刻機能だけを依頼する
7. 集計・承認・CSV出力などを個別に依頼する
8. 最後にテストと動作確認を依頼する

特に最初の「設計書の要約と実装タスク分解」は、いきなり実装させる前に必ず挟んだ方がよさそうです。7000行の設計書を渡す場合でも、AIにまず「この設計書から実装順序、リスク、確認事項、未確定事項を洗い出して」と依頼すれば、その後の作業がかなり安定します。

そして、Docker環境構築は単独のタスクとして切り出した方がよいです。環境構築は、成功すれば地味ですが、失敗すると時間を使います。アプリの業務機能と同じ会話に混ぜると、どこで消費したのか分かりにくくなります。

今回のClineログからブログに残したいポイント

今回のログから、記事として残しておきたいポイントは次の5つです。

1. 設計書の粒度が高いほど、最初の読み込みも重くなる

設計書を細かく書くこと自体は悪くありません。むしろ、AIに任せるなら曖昧な依頼より具体的な設計書の方がよいです。ただし、7000行規模になると、最初の読解だけでも大きな文脈になります。Lite Planで試すなら、設計書全体を渡したあと、すぐ実装ではなく、まず要約とタスク分解に使う方がよさそうです。

2. コンテナ未作成からの環境構築は、想像以上に枠を使う

Docker Desktopが入っていても、対象アプリのコンテナが未作成なら、AIはDockerfile、Compose、nginx、PHP、Node、DB、Mailpitなどを整える必要があります。さらに、ビルド中のエラー対応が入ると、待機とログ確認が何度も発生します。

3. エラー調査は得意そうだが、時間は普通にかかる

intl拡張にlibicu-devが必要だと判断し、Dockerfileを修正した点は実用的でした。こういう典型的な環境構築エラーを処理できるのは、AIコーディングエージェントの強みです。ただし、修正後の再ビルドやコンパイル時間は短縮できません。AIの能力とは別に、ローカルPCとDockerの実行時間がそのまま効いてきます。

4. 「プロンプト数」だけでは消費量を読めない

GLM Coding Planでは、1プロンプトが内部的に複数回モデルを呼び出す可能性があります。Clineのようなエージェントでは、ファイル読み取り、ログ確認、計画、修正、再確認が積み重なります。そのため、人間側の入力回数が少なくても、実際の消費は大きくなることがあります。

5. Lite Planは検証には良いが、大きな一括開発には分割が必要

Lite Planでここまで試せたのは、かなり良い収穫でした。一方で、7000行設計書から環境構築とAP製造まで一気に進めるには、作業範囲が大きすぎます。今後は、Lite Planでは「設計書整理」「環境構築」「機能単位の実装」に分けて使うのが現実的だと思います。

フリーランスSE目線での使いどころ

自分の事業用アプリを作る場合、AIコーディングエージェントはかなり心強い相棒になります。特に、ひとりで開発していると、環境構築、ログ調査、設定ファイルの確認、実装順序の整理まで、全部自分でやる必要があります。

今回のように、勤怠アプリの設計書を作り込み、AIに渡して着手させる流れは、個人開発や小規模業務システムではかなり可能性があります。最初から完成まで丸投げできるかは別として、少なくとも次のような使い方は現実的です。

• 自分が書いた設計書の抜け漏れ確認
• 実装タスクへの分解
• Docker環境のたたき台作成
• Laravelの基本構成づくり
• エラー発生時のログ読解
• 実装後のテスト観点出し

ただし、事業で使うアプリなら、最後は人間の確認が必要です。勤怠アプリは、勤務時間、休憩、承認、集計、場合によっては給与計算や請求にもつながる可能性があります。AIが生成したコードをそのまま信じるのではなく、業務ルール、データ整合性、権限、バックアップ、セキュリティは自分で確認する必要があります。

この記事での結論

今回、GLM-5.2 Lite Planに約7000行のAP設計書を渡し、Dockerコンテナ未作成の状態から勤怠アプリ開発を依頼しました。

結果として、Docker環境構築、PHP拡張エラーの調査、Dockerfile修正、再ビルド、コンテナ起動確認までは進みました。しかし、アプリ本体の本格実装に入る前後で5時間Limitに到達しました。

この結果から、自分なりの結論は次の通りです。

• GLM-5.2 + Clineは、環境構築やログ調査まで含めてかなり実用的に動く
• ただし、7000行設計書から環境構築とアプリ製造まで一気に任せると、Lite Planでは重い
• Dockerビルドや依存関係解決が入ると、待機と確認だけでも利用枠を使う
• Lite Planでは、まず作業を分割し、設計書要約、環境構築、機能実装を別タスクにした方がよい
• 「AIに丸投げできるか」より、「どこで分割すれば現実的に進むか」を見る方が大事

AIコーディングエージェントは、全部を一瞬で完成させる魔法というより、長い開発作業を一緒に進める作業者に近いです。今回の実験では、環境構築の初期トラブルをかなり助けてもらえました。その一方で、利用枠と実行時間の現実も見えました。

次回は、同じ勤怠アプリ開発を「設計書のタスク分解」「Docker環境構築」「勤怠打刻機能」くらいに分けて、Lite Planでどこまで安定して進められるかを試してみたいです。

参考URL

• Z.AI Developer Document：GLM-5.2
• Z.AI Developer Document：GLM Coding Plan Overview
• Z.AI Developer Document：GLM Coding Plan Quick Start
• Z.AI Developer Document：Tool Integration
• Cline公式ドキュメント：Cline Overview
• How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks