【AI社員実践記 第7話】AI社員の「頭脳」を交換してみた　Kimi K2.7 CodeとGLM 5.2を同条件で比較

こんにちは、オフィスピコッツの小笹です。

前回の第6話では、Cloudflare OSで構築した「PIKOZ OS」にプレスリリース案件管理アプリを作らせ、実際の案件情報を使って原稿作成まで試しました。

案件管理や情報整理、過去記事の分析にはかなり使える。

一方で、公開するプレスリリース原稿については、まだ人間の確認と編集が必要でした。

そこで第6話の最後に、次はこんなことを試したいと書きました。

同じ一次情報、同じ編集ルールで、文章を書くAIモデルだけ変えたらどうなるのか。

今回はその続きを実際に試します。

AI社員の「頭脳」だけを交換すると、仕事ぶりはどれくらい変わるのでしょうか。

PIKOZ OSで「頭脳」を切り替えてみる

この時点のPIKOZ OSでモデル選択を開くと、AIとして次の2つが表示されました。

• Kimi K2.7 Code（Workers AI）
• GLM 5.2（Workers AI）

第6話まで使っていたのはKimi K2.7 Codeです。

Cloudflareでは、Kimi K2.7 Codeを長いコンテキストやツール利用に対応したagentic workload向けモデルとして提供しています。GLM 5.2も、Workers AIではagentic codingを想定したモデルとして提供されています。

つまり今回は、「文章専用モデル」と「コード専用モデル」の比較ではありません。

PIKOZ OSで実際に選べる2つのAIに、同じ実務を任せると差が出るのか。

そこを見ます。

その前に、AIの使い過ぎを止める設定をした

モデルを切り替える前に、先に確認したことがあります。

AIを試しているうちに、知らない間に利用料が大きくならないか。

CloudflareのWorkers AI画面を見ると、この日の確認時点で95.7k Neuronsを使用していました。

AI Gatewayでは直近24時間で、

• 47 requests
• 3.36M tokens
• Cost $1.05

と表示されていました。

そこで、今回の比較を始める前にAI GatewayのSpend Limitsを設定しました。

設定したのは、「2ドル／1日／Sliding」です。

Spend Limitsは、時間枠内の累計コストが設定額に達した場合、それ以降の対象リクエストを429でブロックする仕組みです。

Cloudflareの説明では、同時リクエストが集中した場合などには一時的に上限を少し超える可能性があるため、厳密な請求額の保証ではありません。それでも、今回のような実験で使い過ぎを抑える安全装置としては有効です。

AI社員を仕事で使うなら、何ができるかだけでなく、どこで止めるかも決めておく必要があると感じました。

比較方法は、一度やり直した

最初は、第6話で使っていた会話をそのまま開き、KimiからGLMへモデルだけ変更しようとしていました。

ところが、その会話はすでにPIKOZ OS上で、

159,944 tokens / $1.0521

まで大きくなっていました。

同じ会話を続ければ、Kimiが作った原稿も履歴に含まれます。

それではGLMがまっさらな状態で同じ仕事をしたことになりません。

さらに、約16万トークンの長い履歴を毎回使うのはコスト面でも無駄です。

そこで、比較条件を作り直しました。

「モデル以外は同じ」にする

正式な比較では、次の条件にそろえました。

• KimiもGLMも新規会話から開始
• 同じ案件を使用
• 同じ一次情報を使用
• 同じ「京都・滋賀プレスリリース 編集ルール v1.1」を使用
• 同じ指示文を使用
• 外部Web検索はさせない
• 1回だけ生成し、追加修正はしない

比較案件も選び直しました。

第6話では、PIKOZ OSに公開済みの完成稿を6本読ませ、そこから「京都・滋賀プレスリリース 編集ルール」を作っています。

その6本と同じ案件を比較に使うと、過去に見た完成稿の影響を切り分けにくくなります。

そこで今回は、その6本には含まれていない公開情報として、滋賀県長浜市の「キテハマルシェ＆タネまき祭り」を使いました。

Instagram投稿本文とカルーセル画像2枚の情報を一度テキスト化し、両モデルへまったく同じ内容を渡しました。

今回は画像認識の違いまで混ぜたくなかったため、画像を直接読ませるのではなく、同じテキストを同じ順番で渡しています。

案件管理Gadgetから情報を取得させる方法も使わず、比較用の入力を新規会話へそのまま貼り付けました。

これで、できるだけ「モデルだけが違う」状態にしました。

Kimi K2.7 Codeの結果

まず新規会話でKimi K2.7 Codeを選び、固定した入力を1回だけ送信しました。

PIKOZ OSの画面に表示された結果は、

• 18,585 tokens
• Cost $0.0390

でした。

約4セントです。

主要な情報はかなり正確に拾っています。

キテハ食堂が7周年を迎えること、日頃の感謝を込めた開催であること、開催日時、入場無料、小雨決行・荒天中止、催しの時刻なども反映されました。

また、Instagramについては、一次情報として渡した「@kiteha1001」という表記のまま扱い、こちらが与えていないURLは作りませんでした。

キテハ食堂の住所も、「キテハ食堂の住所」と分けて扱っています。

一方で、気になるところもありました。

投稿本文では、けん玉教室、青空ヨガ、当たり付き餅まきは「開催予定」とされていますが、Kimiの本文では「以下の催しが行われる」と、少し確定的な表現になりました。

また、一部の特殊文字を含む出店者名では文字化けが起きています。

そして、出店者情報をかなり細かく入れたため、プレスリリースとしては長めの原稿になりました。

GLM 5.2の結果

次に、別の新規会話を作り、モデルだけGLM 5.2へ変更しました。

入力内容はKimiとまったく同じです。

PIKOZ OSの画面表示は、

• 21,085 tokens
• Cost $0.0610

でした。

約6.1セントです。

今回の1回では、GLMの表示コストはKimiより約56％高くなりました。

ただし、これは単純なモデル単価の差だけではありません。同じ入力でもモデルによって生成量や処理量が変わるため、今回の実行結果として約4セントと約6.1セントになった、と見るのがよさそうです。

差が出たのは「文章のうまさ」だけではなかった

実際に比べると、GLMの方が少し良いと感じる部分がありました。

特に分かりやすかったのが、情報の「確定度」の扱いです。

Instagram本文では、けん玉教室、青空ヨガ、当たり付き餅まきは「開催予定」とされています。

一方、告知画像には13:30、14:00、14:30という具体的なスケジュールが掲載されています。

Kimiは本文で「以下の催しが行われる」と書きました。

GLMは、

「Instagram投稿本文では『開催予定』と案内されており、告知画像には以下のスケジュールが掲載されている」

という形で、両方の情報を残しました。

この点はGLMの方が慎重です。

予約情報でも差がありました。

告知画像には「予約優先」。

投稿本文には、ワークショップや施術の予約開始時間は、すべての出店者紹介後に案内するとあります。

Kimiは「一部のワークショップや施術は予約優先」と整理しました。

GLMは、「予約優先の記載があること」と「予約開始時間は全出店者紹介後に案内すること」を別々に書き、どの出店者が予約対象なのかまでは決めませんでした。

特殊文字を含む出店者名の保持も、今回はGLMの方が良好でした。

でも、慎重さではKimiが良かったところもある

GLMなら全部よかった、という結果でもありません。

一次情報として渡したInstagram情報は、

@kiteha1001

というアカウント名だけです。

URLそのものは渡していません。

ところがGLMは、原稿内にInstagramのURLを生成しました。

実際にありそうなURLでも、今回のルールは「一次情報にないURLを作らない」です。

ここはKimiの方がルールに忠実でした。

住所の扱いでも差が出ました。

一次情報では「滋賀県長浜市高畑町298」はキテハ食堂の住所として掲載されています。

Kimiは「住所（キテハ食堂）」と分けました。

GLMは一部で、「キテハ食堂＆田根まちづくりセンター（滋賀県長浜市高畑町298）」という形にしており、会場2施設全体の住所のようにも読めます。

文章の流れはGLMの方が自然でも、意味を広げない慎重さではKimiの方が良かった箇所がありました。

2つを並べると、こうなった

今回の1案件・各1回の結果を整理すると、次のようになりました。

※これは今回の1案件を1回ずつ生成した結果です。モデル全体の性能を一般化するためのベンチマークではありません。

「GLMの方が高いから上」ではなかった

2026年8月11日時点のCloudflare公式料金では、Kimi K2.7 Codeは100万入力トークンあたり0.95ドル、100万出力トークンあたり4.00ドル。

GLM 5.2は、100万入力トークンあたり1.40ドル、100万出力トークンあたり4.40ドルです。

料金だけを見ればGLMの方が高いモデルです。

今回の実行結果でもGLMの方が高くなりました。

でも、内容を見ると「高い方が全部上」ではありませんでした。

日本語のつながりや、曖昧さを残したまま情報を整理するところではGLMが少し良い。

一方で、URLを作らない、住所の意味を広げない、といった慎重さではKimiが良いところもある。

そして両方に共通していたのが、与えた情報をできるだけ入れようとして原稿が長くなりやすいことです。

出店者一覧もかなり詳しく入り、「公開前の確認事項」も多くなりました。

AIは情報を整理して並べることはかなりできます。

でも、何を残し、何を削れば、その記事として一番読みやすいのか。

この編集判断は、今回も人間の仕事として残りました。

AI社員は「一番高い頭脳」を載せれば完成、ではない

今回の結果で一番面白かったのは、モデルを変えると確かに仕事ぶりが変わったことです。

ただし、

高いモデルへ替えれば、前の問題が全部解消するわけではない。

GLMで良くなったところもあれば、Kimiの方がよかったところもありました。

AI社員も、一つのモデルですべての仕事をさせるより、

• アプリを作る
• コードを修正する
• 情報を整理する
• 文章を書く

といった仕事ごとに、向いているモデルを選ぶ方が現実的なのかもしれません。

今回の結論

第6話では、AI社員に本当のプレスリリース案件を任せました。

第7話では、そのAI社員の「頭脳」を交換しました。

結果は、

モデルを変えると、仕事ぶりは確かに変わる。 ただし、高いモデルに替えれば全部解決するわけではない。

でした。

今回の1案件では、文章の整理やニュアンスの扱いはGLM 5.2の方が少し良いと感じました。

一方で、一次情報から余計に広げない慎重さではKimi K2.7 Codeの方が良い場面もありました。

そして、どちらもそのまま公開できる完成原稿ではありません。

最後に必要なのは、やはり人間の編集判断でした。

「AIを使うか、使わないか」から、

どのAIに、どの仕事を任せるのか。

PIKOZ OSを試していると、少しずつそこへ話が進んできたように思います。

次は「仕事ごとに頭脳を使い分ける」を試したい

第5話・第6話では、Kimi K2.7 Codeがアプリ作成や修正をかなりこなしました。

今回の文章比較では、GLM 5.2の方が少し良かった場面があります。

では、

アプリ作成や修正はKimi、文章作成はGLM

というように、仕事ごとに頭脳を使い分けたらどうなるのでしょうか。

一つのAIに全部を任せるのではなく、仕事によって担当を変える。

次はそこを試してみたいと思います。

AI社員実践記は、まだ続きます。

あなたの会社なら、AI社員にどの仕事を任せますか

オフィスピコッツでは、AIを入れること自体を目的にするのではなく、

今の仕事のどこをAIに任せると楽になるのか。どこは人が判断すべきなのか。どのAIを使うのが合っているのか。

というところから一緒に整理しています。

• AI業務診断：https://pikoz.net/ai-shindan/
• AI社員構築サービス：https://pikoz.net/ai-shain/
• AI社員実践記：https://pikoz.net/category/ai-jissen/
• AIレスキュー：https://pikoz.net/ai-rescue/

参考

• Cloudflare Workers AI pricing：https://developers.cloudflare.com/workers-ai/platform/pricing/
• Kimi K2.7 Code：https://developers.cloudflare.com/workers-ai/models/kimi-k2.7-code/
• Workers AI Models：https://developers.cloudflare.com/workers-ai/models/
• AI Gateway Spend Limits：https://developers.cloudflare.com/ai-gateway/features/spend-limits/
• Cloudflare Workers pricing：https://developers.cloudflare.com/workers/platform/pricing/