はじめに
本記事では、AI駆動開発を低コストで実行できないか検証します。
AI駆動開発を実施するにあたり、一般的にはClaude CodeやCodexを利用することが多いと思いますが、トークン消費量が多く値段が高いなど課題があると思います。この課題を解決できないかと、オープンウェイトモデルのGLM-5.2を用いて、Claude Codeに近しいレベルのAI駆動開発ができないかを検証してみることにしました。
※本記事は第一弾の続きです。モデルの置き換え手順は、第一弾をご覧ください。
AI駆動開発
生成AIを用いてアプリケーション開発を実施することです。
最近のモデルは非常に賢くなっているので、仕様書を作って渡して作らせると概ね期待どおりの物を生成してくれます。仕様の詰めが甘いと間違った仕様で作られてしまう事もありますが、これは人間に作らせても同じことがおきます。なので、期待どおりの動きになっていなければ指摘をして修正させれば良いです。
前提条件
Claude Codeのモデルを差し替えて、公平な比較をするために前提条件を揃えます。
機能仕様概要
検証で使用した課題
本検証では、Qiita Organization の投稿実績を分析し、進捗レポートを生成する Python 製CLIアプリケーションの開発を題材としました。
アプリケーション概要
- Qiita Organization の記事・メンバー情報を取得
- 当年の投稿実績を集計
- 年間目標に対する達成状況を分析
- 月別推移や投稿者別傾向を可視化
- 課題分析と改善提案を自動生成
- Markdown形式のレポートを作成
- Microsoft Teamsおよびメールへの通知に対応
主な分析内容
- 投稿数集計
- 達成率・進捗率計算
- 年末着地予測
- 必要投稿ペース算出
- 月別推移分析
- 投稿者ランキング
- 未投稿者分析
- 投稿偏在分析
- 課題抽出
- 改善提案生成
通知機能
通知は以下の2種類を出力します。
-
上司向けサマリ
- 結論
- 現状
- 見通し
- 課題
- 次のアクション
-
詳細レポート
- 集計結果
- 算出根拠
- 記事一覧
- 分析結果
「データ収集 → 集計 → 分析 → レポート生成 → 通知」までを含む業務アプリケーションとして設計しています。
また、通知はTeamsチャネルのワークフローにwebhookで投稿できるように設定しました。
アプリケーション開発用フォルダの分離
各モデルで生成したソースが混ざらないように、モデル毎にフォルダ構成を予め作成して分離します。
- Claude Codeで生成するソースを格納するための専用フォルダを作成します
- 前述の専用フォルダ配下に仕様書フォルダを作成して同一の機能仕様書と受入検査表のファイルを配置します
# Claude source folder ~\repos\GLM_VS_Claude\source\Claude_v2 source\Claude_v2\仕様書 # GLM-5.2 source folder ~\repos\GLM_VS_Claude\source\GLM-5.2_v2 source\GLM-5.2_v2\仕様書
Claude Codeの初期化実施
条件を揃えるためにClaude Codeの初期化をします。
- PowerShellコンソールで前述のモデル用フォルダに入ってから、
claudeと入力してClaude Codeを起動します。 - 起動直後に過去会話を消すため
/clearを実行します。
Claude
GLM-5.2
- モデルをClaudeでは
Sonnet 5.5、GLM-5.2でGLMを設定します。 - それぞれ実行前のベンチマーク用プロンプトを設定します。（後で比較しやすいようログにタグを残す意図です。）
# Benchmark Model=Claude-Sonnet-5.5 RunId=20261027-02# Benchmark Model=GLM-5.2 RunId=20261028-02 -
auto mode onで実行します。
プロンプト
アプリケーション開発用プロンプトを統一し、以下の指示のみで開発をさせます。
@"仕様書\Qiita技術ブログ進捗確認アプリ 機能仕様書_改訂版.md"
この機能仕様書を満たすアプリケーション開発をしてください。また、@仕様書\受入検査.md
この受入検査に必ず合格させてください。
モデル対決結果
GLM-5.2 は Claude Sonnet 5.5 の約88%の費用で開発できました。
以下は証跡画像で、Claude Codeで本家ClaudeとGLM-5.2に差し替えて実行した結果のスクリーンショットです。
Claudeでの実行結果
１１分５６秒で作成してくれました。
こちらは一発で仕様どおりに開発完了できており、python main.pyを実行するだけで期待どおりの動作ができました。
GLM-5.2での実行結果
８分３７秒で作成してくれました。
一発のプロンプトでClaudeより少し早く開発完了したものの、動作確認してみると仕様どおりに動作しませんでした。そのめ、修正指示を出して再確認したところで、仕様どおりの動作ができるようになりました。
前提条件に記載したとおり、集計対象のタグでログからトークン消費量と費用を算出しました。
対象は、各タグを入力したセッションファイル全体です。
| 項目 | Claude Sonnet 5.5 RunId=20261027-02 |
GLM-5.2 RunId=20261028-02 |
|---|---|---|
| API 呼び出し数 | 40 | 83 |
| 通常入力 | 80 | 200,609 |
| キャッシュ書込 (1時間) | 150,782 | 0 |
| キャッシュ読出 | 4,404,985 | 4,549,696 |
| 出力 | 93,982 | 62,943 |
| 合計トークン | 約465万 | 約481万 |
| 費用 | 約 $1.98 | 約 $1.74 |
-
費用算出に使用した単価（USD / 100万トークン）
-
Claude（公式料金）
- 入力: $2.00
- キャッシュ書込: $4.00
- キャッシュ読出: $0.10
- 出力: $10.00
-
GLM-5.2（FPT Token Factory料金）
- 入力: $1.40
- キャッシュ: $0.26
- 出力: $4.40
-
-
GLM の費用比
- GLM-5.2 は Claude Sonnet 5.5 の約88%の費用
所感
GLM-5.2でも良さそう。ただ、今回の機能仕様と受入検査表で作らせた結果だと、両モデルの費用の差があまり開かなかったので、もう少し安く済むモデルと比較してみたいなと思いました。
いずれも手動で実行してみた結果、前述のアプリケーションが集計したレポート自体は似たような感じで結果出力をしてくれました。
違った箇所としては、Teamsチャネルのワークフローへの投稿レポートへの投稿の仕方が若干違っていました。
Claudeの方は、summaryと詳細を連続投稿していました。一方、GLM-5.2の方はsummaryの投稿のみしていました。このように若干振る舞いの違いは出たものの詳細は仕様で追い込んでおけば対処できる範疇だと思いました。
まとめ
Claude Codeのモデルを差し替えても普通に使えるし、安く済ませることが可能だと思いました。
要は使い分けが重要なんだろうと思います。難しい作業をさせる場合はフロンティアモデルを使用し、簡単なバックエンドアプリケーションを開発させる程度であれば、安いモデルを使った方が良さそうです。
中国系のオープンウェイトモデルは、公式サイトのモデルだと中国の法律である国家情報法によってデータを抜かれる恐れがあるため、使用禁止されている企業や個人でも抵抗があると思います。なので、そのような危険を回避するために、FPTでセルフホストしているオープンウェイトモデルに接続すれば、前述の恐れは回避するることが可能です。
読者の方々も是非この記事を参考に様々なモデルでAI駆動開発をしてみては如何でしょうか？
次回は別のモデルでも検証してみたいと思います。フォローやいいねをしていただけると嬉しいです。
FPT AI FACTORY