名古屋でAIシステム開発の会社をやっています。10月7日、Claude Code を使って、ある「頼まれていない仕事」を1日で終わらせました。デジタル民主主義2030（チームみらいの安野貴博党首が2025年に立ち上げたコミュニティ）が作っている広聴AIで、ローカルLLMを使うとどのくらい誤読が出るのかを測り、開発者の GitHub の issue に結果を出すところまでです。
この記事では、Claude Code に任せたことと、私が決めたことを分けて書きます。業務の自動化というと「全部AIがやる」と思われがちですが、実際は決める場面がはっきり残り、その間の手作業がほぼ消える、という形でした。
発端：Slack の議論
広聴AIは、たくさんの意見をAIで整理して論点の地図にするOSSです。私は9月から自社のPCでローカルLLMで動かしていて、10月6日に小さな修正（PR）がマージされたばかりでした。
10月7日の昼、広聴AIの開発チャンネルで、開発者の西尾泰和さんがこう書いていました。
Local LLMで動くの話、「インターフェイスが共通なので動く」ということと「十分な精度の結果を返す」ということは別物（中略）どのくらいのモデルだとどのくらいの確率で誤読が発生するのかとかがわかるといいのかもなと思った。
同じ日、別の開発者の大木さんからは、私に「広聴AIをどう使っているか」という質問も来ていました。
流れ（1日）
| 段階 | Claude Code がやったこと | 私が決めたこと |
|---|---|---|
| 1. 読む | Slack をブラウザ経由で読む仕組みを作り、チャンネルの発言とスレッドを全部取り出す | 返信するかどうか、何を約束するか |
| 2. 返信 | 返信の文案を作り、承認後にスレッドへ投稿 | 文面の承認 |
| 3. 測る | 広聴AIのコンテナの中で、本物の抽出の関数をそのまま呼ぶスクリプトを書いて回す | どのモデルで測るか（12Bだけにする） |
| 4. 判定 | 出力を、どのモデルの出力かを伏せて別のLLMで型に分け、引っかかったものを全件読み直す | 判定の基準が妥当か |
| 5. 公開 | README を書いてリポジトリに置き、issue に結果を投稿 | 公開してよいか、投稿してよいか |
1. Slack を読む
最初は Gmail に届く Slack の通知メールで議論を読んでいました。ところが通知メールは未読の一部だけで、しかも時刻がずれていました（昼の12時21分の発言が「前日20時21分」と出ていた）。そこで、ログイン済みのブラウザから Slack の発言を読むだけのスクリプトを Claude Code に書いてもらい、チャンネルの10日分27件とスレッドの返信を全部取り出しました。書き込みはしない作りです。
2. 約束する
大木さんへの返信で、「ローカルLLMでどのくらい誤読が出るかを、#471（ローカルLLMのベンチマークのissue）の続きとして測る」と約束しました。文案は Claude Code が書き、私が読んで承認し、投稿まで任せました。
3. 測る
ここがいちばん大事なところです。広聴AIの意見抽出を自分で再現せず、広聴AIのコードそのものを呼ぶようにしました。広聴AIのAPIのコンテナの中に測定のスクリプトを入れ、extract_arguments を既定のプロンプトのまま呼びます。こうすると、測った数字がそのまま「広聴AIを使うとこうなる」という意味になります。
入力は、広聴AIに同梱されているサンプルから208件です（AIについての短い意見100件、まちづくりの声48件、英語の意見60件）。
途中で失敗もしました。最初は3つのモデルを比べようとしたのですが、同じGPUで毎時動いている別の処理（X の返信候補づくり）が使うモデルと、測定のモデルが交互に読み込み直しを起こし、どちらも遅くなりました。別の処理が45分で時間切れになって、気づきました。そこでモデルの比較はやめて、12Bだけでプロンプトを比べることに切り替えました。これは私の判断です。GPUは仕事の道具なので、測定のために本業の処理を止めるわけにはいきません。
4. 判定する
208件の抽出結果を、どのモデル・どのプロンプトの出力かを伏せて別のLLMに渡し、「賛否が逆」「主体の取り違え」「原文にない追加」「抜け」「確信度の変化」などに分けてもらいました。そのうえで、引っかかったものは全件、問題なしとされたものからも24件を、Claude Code と一緒に読み直しました。見逃しは軽いもの1件だけでした。
結果はこうでした。
| プロンプト | 意味が変わった | 空・英語のまま | 確信度の変化 |
|---|---|---|---|
| 既定（1回目） | 6 | 0 | 3 |
| 既定（2回目・同じ条件） | 7 | 1 | 3 |
| 誤読を避ける指示を5行足した版 | 4 | 6 | 0 |
| さらに2行足した版 | 9 | 6 | 0 |
いちばん面白かったのは、温度0でも結果が揺れたことです。同じ条件で2回回すと、出力が完全に一致したのは208件中184件で、誤読する文も入れ替わりました。西尾さんの「誤読は確率的」という話を、ローカルLLMの数字で確かめられたことになります。そして、1回ずつの比較ではプロンプトの良し悪しは決められない、ということも分かりました。指示を足すと確信度の変化は減りますが、抽出が空になる失敗が増えます。
5. 公開する
README を書いてリポジトリに置き、#471 に結果をコメントしました。ここで1つ、Claude Code の見落としがありました。リンク先のリポジトリを「公開されている」と思い込んで文案を作っていたのですが、push したあとに確かめると非公開でした。コメントを出す前に気づいて止まり、私に「どこに置くか」を聞いてきました。私は公開してよいと判断し、Claude Code は履歴全体に鍵やパスワードが入っていないことを確かめてから公開に切り替え、URLが開けることを確かめてから投稿しました。
自動化して分かったこと
- 決める場面は減らない。返信するか、何を約束するか、どのモデルで測るか、公開してよいか。どれも私が決めました。消えたのは、その間の手作業（Slackを読む、スクリプトを書く、200件を判定する、READMEを書く）です
- 本物のコードを呼ぶ。測定のために抽出の処理を真似て書くと、それは広聴AIの測定ではなくなります。コンテナの中で本物の関数を呼んだので、結果をそのまま開発者に渡せました
- 確かめてから出す。Slack の通知メールの時刻のずれ、リポジトリの非公開、GPU の取り合い。どれも「確かめる」手順があったから、外に出す前に止まれました
- 費用：測定はローカルの12Bで1周40分ほど、API費用は0円。判定に使ったLLMの費用だけです
この仕事は、誰かに頼まれたものではありません。それでも、コミュニティの議論で出た問いに数字で答えると、その場の役に立ちます。Claude Code は、こういう「やったほうがいいけれど手が回らない仕事」を1日で終わらせる道具として、いちばん効くと感じています。
業務の流れごとAIエージェントに任せた別の例として、受発注システムの相談から、開発・デモ・出品・ブログ・動画・SNS告知までを約2時間で回した記録も、実際の画面つきでまとめています。
関連して、チームみらいが新設した広聴本部に声は集まるのか、という考察も書きました（チームみらいの広聴本部に声は集まるか）。
よくある質問
広聴AIとは何ですか？
デジタル民主主義2030が開発しているブロードリスニングのOSSです。たくさんの意見をAIで抽出・分類して、論点ごとの地図とレポートにします。OpenAI などのAPIのほか、ローカルLLMでも動きます。
ローカルLLMで広聴AIを使うと、どのくらい誤読しますか？
gemma4:12b（量子化版）で208件を測ったところ、既定のプロンプトで意味が変わった抽出は6件（約3%）、確信度の変化は3件でした。英語の意見を日本語にするものに多く出ます。同じ条件でも回すたびに誤読する文は入れ替わります。
Claude Code で業務を自動化するとき、何を人が決めるべきですか？
外に出すこと（投稿・公開・送信）と、資源の使い方（GPUや費用）、約束の中身です。この例では、返信の文面、測るモデル、リポジトリの公開、issue への投稿を人が決め、それ以外の読む・書く・測る・確かめるを任せました。
