Z.aiのGLM-5.2を使って、個人の業務稼働を残すための勤怠打刻アプリケーションを作ってみました。
今回は、かなり細かく仕様を詰めたというより、「設計書を作って」「まず動くところまで作って」という、わりと雑な依頼から始めています。結果として、1週間分の利用上限をほぼ使い切りながら、会員登録、ログイン、打刻、位置情報取得、実績入力、月次一覧、CSV出力までを持つWebアプリの暫定版までは作れました。
ただし、最初からきれいに完成したわけではありません。ログインできない。登録メールが送れない。細かいUIが惜しい。そういう「かゆいところ」は普通に残りました。ここが今回いちばん大事なところで、AIエージェントはかなり作れるけれど、まだ人間のレビューやタスク分解は外せない、という感覚です。
今回作った勤怠打刻アプリの概要
今回作ったのは、自分の稼働実績を残すためのシンプルな勤怠管理システムです。大きな会社で使うような本格的な勤怠管理ではなく、個人で「今日は何時から何時まで働いたか」「あとから請求書を作るときに参照できるか」を見るための小さな業務アプリ、という位置づけです。
できた機能は、ざっくり次の通りです。
- 会員登録
- メール本人確認
- ログイン
- 勤怠打刻
- 位置情報取得
- 正式な実績入力
- 月次一覧表示
- CSV出力
規模としては、総ファイル数が約140ファイル、総STEP数が約21K STEP。もちろん、ファイル数やSTEP数だけで品質は語れません。ただ、個人用の小さなWebアプリとして見ると、「ちょっとした画面を作った」よりはだいぶ大きいです。フロントエンド、バックエンド、認証、メール、一覧、CSV出力まで含んでいるので、AIエージェントに任せる題材としてはそれなりに現実的なサイズだったと思います。
実際にできた画面
まずログイン画面です。画面としてはかなり素直で、メールアドレス、パスワード、ログイン状態の保持、パスワードリセット導線、会員登録導線があります。個人で使うアプリなら、このくらいのシンプルさで十分です。
会員登録画面では、氏名、メールアドレス、パスワード、確認用パスワードを入力します。登録後に確認メールを送る想定になっています。
メインのダッシュボードには、時計、当日の打刻状況、出勤・退勤ボタン、実績入力画面への導線、月次一覧への導線があります。打刻時には位置情報を取得する想定です。
正式実績入力画面では、打刻実績を参照しつつ、正式な出勤時刻、退勤時刻、休憩時間、勤務区分、備考を入力できます。打刻は現場の記録、正式実績は請求や管理に使う記録、という分け方です。
月次一覧では、日別の打刻出勤、打刻退勤、正式出勤、正式退勤、休憩、勤務時間、勤務区分、位置情報を確認できます。CSV出力ボタンも入っているので、今後、請求書作成や集計に広げやすい形です。
GLM-5.2は何が得意そうだったか
Z.aiの公式ドキュメントを見ると、GLM-5.2は「長い開発タスク」「プロジェクト単位のコード理解」「1Mコンテキスト」をかなり前面に出しています。単発のコード片を書くモデルというより、要件から実装、検証、修正までを長く続けるためのモデルとして打ち出されている印象です。
今回の勤怠アプリ作成でも、その方向性はたしかに感じました。最初に作ったものがそのまま使える完成品だった、という話ではありません。むしろ最初は普通に詰まりました。ただ、「ログインできない」「登録メールが送れない」「この画面の導線がおかしい」と伝えると、原因を探して、関連ファイルを見て、修正して、次に進むことはできていました。
AIコーディングエージェントで大事なのは、1回で正解を出すことよりも、詰まったあとに調査と修正を続けられることです。実務では、仕様がきれいにそろっていることのほうが少ないです。認証、メール、日付、CSV、位置情報のように、別々の機能が絡みます。そういうときに、前に読んだ設計や実装の前提をある程度持ったまま動けるかどうかは、体感としてかなり効きます。
もちろん、公式ドキュメントにある性能説明をそのまま鵜呑みにする必要はありません。ベンチマークで強いことと、自分の環境で安定して成果物が出ることは別です。今回の検証で見えたのは、「安く雑に投げても暫定版までは進む」「でも業務で使うならレビューは必須」という、かなり現実的なラインでした。
4ドル相当でここまで来た、というインパクト
今回のメモでいちばんインパクトが大きかったのは、コスト感です。月額16ドルのプランを1週間分、つまり単純計算で約4ドル相当使って、勤怠打刻アプリの暫定版ができた。ここだけ見ると、かなり安いです。
ただし、ここは少し分けて考えたほうがよさそうです。今回の「4ドル相当」は、自分が使ったプランと期間から見た体感の話です。一方で、Z.aiのAPI価格はトークン単価で公開されていて、GLM-5.2は入力と出力で料金が分かれています。さらに、Coding Planのような月額型の使い方もあります。つまり、誰が使っても必ず4ドルで同じアプリが作れる、という意味ではありません。
それでも、個人開発の初速としてはかなり大きいです。人に頼めば、要件整理、画面設計、DB設計、認証実装、メール設定、CSV出力、テストでそれなりの工数になります。AIエージェントなら、それを数ドルから数十ドルの範囲で「叩き台」まで持っていける可能性がある。これは、フリーランスSEや個人開発者にとってかなり見逃せない変化です。
ただ、安いから全部任せて終わり、とは言えません。むしろ安く叩き台が作れるからこそ、人間側のレビュー力が目立つようになります。設計が甘いまま投げると、AIはそれっぽく作ってくれます。でも、それが本当に自分の使い方に合っているか、データの持ち方が危なくないか、セキュリティ的に問題がないかは、別の話です。
「とりあえず作って」は強い。でも限界も出る
今回の依頼は、かなり大ざっぱでした。細かい画面仕様や例外処理を全部決めてから渡したわけではありません。まず設計書を作って、とりあえず作って、というレベルです。
この雑な依頼でも、一旦動く状態まで持っていけたのは素直にすごいです。以前なら、個人が自分用の勤怠アプリを作ろうと思っても、最初の環境構築や認証周りで面倒になって止まりがちでした。AIエージェントがあると、「とりあえず形にする」までの心理的な重さがかなり下がります。
一方で、雑な依頼のまま進めると、当然ながら抜けも出ます。今回も最初はログインができなかったり、登録メールが送れなかったりしました。これはモデルが悪いというより、依頼の粒度が粗いと、AIが補完する部分が増えすぎるという話です。
人間に開発を依頼するときも同じですが、「何を作りたいか」だけでは足りません。どのメールサービスを使うのか。ローカル環境と本番環境で設定をどう分けるのか。ログイン失敗時の表示はどうするのか。パスワードリセットは必要か。位置情報を取れないブラウザではどうするのか。こういう細かい判断を放置すると、AIはそれっぽい仮置きをします。
仮置きで進めること自体は悪くありません。むしろ初期開発では便利です。ただし、仮置きのまま「完成」と思ってしまうのが危ない。AIエージェントで作ったアプリは、たたき台、暫定版、検証版という言葉を頭に置いて扱うほうが安全です。
人間レビューが必要だと感じたポイント
今回、特に人間が見ないと怖いと感じたのは、認証、メール、セキュリティ、データの整合性です。
勤怠アプリは一見シンプルですが、実は日付と時刻の扱いが面倒です。タイムゾーン、日またぎ、休憩時間、打刻漏れ、正式実績の修正、CSV出力の形式。個人用なら多少ゆるくても使えますが、請求や契約に関わるなら雑には扱えません。
さらに、ログインや会員登録を入れると、セキュリティの確認が必要になります。パスワードは適切にハッシュ化されているか。メール確認のトークンは推測されにくいか。有効期限はあるか。環境変数に入れるべき値がコードに直書きされていないか。不要なエラー情報を画面に出していないか。こういう部分は、AIに「セキュリティを見直して」と頼めばある程度洗い出せますが、最終判断を丸投げするのはまだ怖いです。
もう一つは、UIの細かい使いやすさです。AIは画面を作るのが速いですが、自分の毎日の動線に本当に合うかは、使ってみないと分かりません。出勤ボタンはどこにあると押しやすいか。退勤後に実績入力へ自然に流れるか。月次一覧で見たい列は何か。CSV出力の列順は会計作業に合うか。このあたりは、実際に使う人間の感覚がかなり残ります。
つまり、AIエージェント開発では「実装者としての人間」は減るかもしれません。でも「レビューする人間」「仕様を決める人間」「使って違和感を拾う人間」はむしろ大事になります。
次にやるなら、タスク分解を先に作らせる
今回の反省点は、最初の依頼が大きすぎたことです。もちろん、大きく投げても暫定版はできました。でも、コストと精度を考えるなら、次はもう少しタスク分解してから進めたいです。
たとえば、いきなり「勤怠管理アプリを作って」と投げるのではなく、まず次のように分けます。
- 要件定義として、使う画面とデータ項目を洗い出す
- DB設計と認証方式を決める
- 会員登録とログインだけを先に作る
- 打刻と位置情報取得だけを作る
- 正式実績入力を作る
- 月次一覧とCSV出力を作る
- セキュリティ、例外処理、テストを見直す
この順番なら、途中で壊れたときに原因を追いやすくなります。AIエージェントも、タスクの境界がはっきりしているほうが迷いにくいはずです。特に認証やメール送信のように外部設定が絡むところは、最初に仕様と環境を確認させたほうがよいです。
また、次回は「最初にテスト観点を作らせる」のも試したいです。ログイン、会員登録、メール確認、出勤、退勤、実績入力、CSV出力について、正常系と異常系を先に一覧化させる。そのうえで実装させると、あとから人間が確認するときも楽になります。
請求書作成までつなげると、実務アプリらしくなる
今後やりたいのは、勤怠実績から請求書作成までつなげることです。個人で使うなら、勤怠を記録するだけでは少し弱いです。月末にCSVを見て、稼働時間を集計して、請求書に転記するところまでいって、ようやく「使う理由」が強くなります。
ここもAIエージェントと相性がよさそうです。月次一覧にある正式出勤、正式退勤、休憩、勤務時間をもとに、案件別の稼働時間を集計する。単価を設定する。請求書PDFを出す。必要ならCSVも出す。こういう業務アプリの地味な機能は、派手さはないですが、個人事業やフリーランスにはかなり効きます。
ただし、請求書まで扱うなら、税や契約の判断には踏み込みすぎないほうがよいです。アプリとしてできるのは、稼働時間と単価をもとに計算し、所定の形式で出力するところまで。実際の請求項目、消費税、源泉徴収、インボイス制度への対応などは、個別条件によって変わるので、最終的には専門家や契約内容を確認する必要があります。
AIに作らせる範囲と、人間が判断する範囲を分ける。ここを雑にしないことが、個人開発でもかなり大事だと感じます。
GLM-5.2を使うときの注意点
今回の検証だけで、GLM-5.2が他のAIコーディングエージェントより常に優れている、とまでは言えません。比較実験をしたわけではないからです。今回言えるのは、Z.aiのGLM-5.2を使って、1週間の利用上限ギリギリまで回したところ、個人用勤怠アプリの暫定版を作るところまでは到達できた、ということです。
また、公式ドキュメントではGLM-5.2の長いコンテキストや開発タスクへの強さが説明されていますが、自分の環境、リポジトリの構成、依頼の仕方、テストの有無によって結果は変わります。AIエージェントは、モデルの性能だけでなく、周辺の使い方でかなり差が出ます。
特に注意したいのは、次の3つです。
- 最初の設計が粗いと、AIの仮置きが増える
- 動く画面ができても、セキュリティや例外処理が十分とは限らない
- 利用上限や料金はプラン、API利用、トークン量で変わる
「安く作れた」は大きな発見ですが、「安く安全に運用できる」とは別です。ここを混ぜると危ないです。個人用の実験ならどんどん試してよいと思いますが、外部ユーザーに使わせるサービスにするなら、認証、権限、データ保護、ログ、バックアップ、テストは別枠で見たほうがよいです。
今回の結論
GLM-5.2を使った今回の勤怠打刻アプリ開発で感じたのは、AIエージェント開発はもう「おもちゃ」ではないということです。雑に依頼しても、140ファイル、21K STEP規模のWebアプリを暫定的に動くところまで持っていける。これは普通に強いです。
一方で、完成品として安心して使うには、まだ人間のレビューが必要です。特にログイン、メール、セキュリティ、日付計算、請求につながるデータは、人間が見ないと危ない。AIが作ったものをそのまま信じるのではなく、AIに叩き台を作らせ、人間が仕様とリスクを見て、またAIに修正させる。この往復が今のところ一番現実的だと思います。
次回、利用上限がリセットされたら、追加機能の実装とセキュリティ関連の見直しを進める予定です。特に、請求書作成、細かいUI調整、テスト観点の整理、認証まわりの確認はやりたいところです。
個人開発者やフリーランスSEにとっては、「自分だけの小さな業務アプリ」を作るハードルがかなり下がっています。ただし、安く作れる時代ほど、何を作るか、どこまで任せるか、どこを人間が見るかが大事になる。今回の勤怠アプリは、その感覚をかなり具体的に教えてくれる実験になりました。
