Analyzegear
「AIで編集作業が速くなった」——これを思い込みではなく数字で言うために、同じ画面・同じ計り方で手動とAI下書きありを比較できる仕組みを先に作りました。対象は自社で運営する用語解説メディア（toha.jp）の編集作業です。結論から書くと、タグ付け1件あたりの編集時間は 12.1秒 → 2.6秒（各20件で計測・作業者1名）になりました。ただしこの数字より、「どう測ったか」と「最初は計測ツール自体が正しく測れていなかった」ことのほうが、持ち帰れる話だと思っています。
決済者・非エンジニア向けの要約版は 実績ページの事例（用語メディアの編集を、AIの下書きで速くする） にあります。この記事は、設計・計測・ハマりどころを同業者向けに掘り下げたものです。社内ツールのため公開デモはありません。
課題 ― 「実在する穴」を数えるところから始めた
着手時、当初の想定は「メタディスクリプション未設定の解消」でした。ところが実数を数えたら、48,382語のうちメタ未設定はわずか4件（もう1つのメディア noimi.jp では0件）。既存のAI生成パイプラインが埋め終えていて、前提が成立しませんでした。ここで無理に「メタ改善」を成果にすると、実態のない事例になります。
そこで実在するギャップに対象を変えました。公開中48,382語のうち、タグが1つも付いていない語が1,220語（2.5%）、例文が無い語が2,208語（4.6%）。どちらも人が本文を読んで判断する編集作業で、ここなら「工数削減」の Before/After が作れます。タグ付けは、記事を読んで 13,826件ある既存タグから適切なものを選ぶ作業で、1件ずつ人手でやると地味に時間がかかります。
なお、計測したのはタグ付けのみです。例文作成にも下書きを出す機能はありますが、Before/After の計測はしていないので、この記事では例文の時間短縮には触れません。
設計 ― 「AIは下書きまで、確定は人」を先に線引きする
管理画面に「AIが下書きを作り、人が確定する」流れを作りました。AIは提案するだけで、公開データには一切書き込みません。人が画面で確認して確定したものだけが反映されます。公開物を扱う以上、この線を最初に引いておかないと運用が崩れます。品質のために決めたのは次の3つです。
- AIに新しいタグを作らせない。既存のタグ候補から選ばせ、候補に無い名前は必ず捨てて、捨てた件数を報告させます。分類の乱立を防ぐためです。
- 例文に新しい事実を足させない。その用語の本文に書かれていることだけを使わせます。ハルシネーションを構造で封じる発想です。
- 人が書いたものを上書きしない。例文がすでにある行には書き込みません。
技術構成 ― 書き込みの口を2つに絞る
構成は Laravel 13 / PHP 8.3 / MySQL。生成は Claude API の claude-haiku-4-5 を構造化出力（JSONスキーマ）で使っています。やっているのは本文からの抽出と言い換えなので、上位モデルは使っていません。見た目の派手さより、タスクに対して過剰でないモデル選択のほうが運用コストに効きます。
安全性は「できることを減らす」で担保しました。公開データへの書き込みは TohaRepository の2メソッド（タグの付与・空の例文の設定）だけで、それ以外の更新・削除はコードとして持っていません。事故を起こしたくても起こせる口が無い、という状態です。反映は dry-run が既定で、EDITOR_APPLY_ENABLED=true を設定して初めて実反映されます。API使用量は全コールのトークンと円を記録し、月次上限（既定3,000円）で生成が自動停止します。
- タグの品質担保：全13,826タグから自由に選ばせず、同カテゴリで使用頻度の高い既存タグ40件に絞って候補として渡し、候補外は機械的に排除
- 書き込み経路：
タグ付与と空の例文の設定の2つのみ。dry-run 既定 - テスト：22件（書き込みの安全性・計測の公平性・空の除外を固定）
効果をどう測ったか ― ここが本体
「AIを使うと速い」は、比較の条件を雑にするといくらでも盛れます。フェアに測るために決めたことを並べます。
- 所要時間は「画面に出した時刻 → 確定した時刻」の差を サーバ側で 記録（
review_items.elapsed_ms）。ストップウォッチの押し忘れや自己申告のブレが入りません。画面をリロードしても計測の起点は動きません。 - タグ候補は両モードとも同じものを出します。違いは「下書きが最初から選ばれているか」だけ。手動側だけ13,826件から思い出す作業にすると、比較になりません。
- 同じ用語が2回出ることはありません。
- 「そのまま採用 / 修正」の判定も サーバ側 で、下書きと確定内容を比べて決めます。タグは順序を無視して比較し、並び順の違いを「修正」と数えません。
- 計測の順番は 手動 → AI下書きあり。逆にすると、先にAIの答えを見た記憶が手動側に漏れます。
この設計はテストで固定しています（tests/Feature/ReviewMeasurementTest.php）。計測の公平性はコードレビューでは守りきれないので、テストに落として初めて安心できました。
ハマりどころ ― 計測ツール自体が最初は正しく測れていなかった
最初に手動20件を計測したとき、作業者が「合うタグが無い」と判断して全件を空のまま確定していました。空で確定するのは実質「作業をしていない」ので、これを平均に混ぜると手動側が不当に速く出ます。つまり 計測ツール自体が、最初は正しく測れていなかったわけです。
対処は「中身を入れて確定したものだけで比べる」形への作り直しでした。空で確定したものは母数から外し、外した件数を画面に明示します。これをやらないと、外した件数を後から自分の都合で動かせてしまい、数字の意味が消えます。「効果を測る仕組み」を作るときは、測る対象より先に「何を母数から外すか」を決めておくべきだ、というのが教訓でした。
結果 ― 12.1秒 → 2.6秒（各20件・作業者1名）
| 平均 | 中央値 | 範囲 | n | |
|---|---|---|---|---|
| 手動（下書きなし） | 12.1秒 | 10.0秒 | 3.7〜25.5秒 | 20 |
| AI下書きあり | 2.6秒 | 2.3秒 | 1.4〜7.3秒 | 20 |
AI下書きありは手動の約21%（1件あたり約9.5秒短縮）でした。下書きの質のほうは次のとおりです。
| そのまま採用できた件数 | 18/20件（90%） |
| 修正した件数 | 2/20件（いずれもタグ1個の差し替え・追加） |
| 1件あたりの平均編集量 | 0.10タグ |
| 候補に無いタグを捨てた件数 | 23件中1件 |
| 下書きの生成コスト | タグ 0.279円/件・例文 0.240円/件（各23件の平均） |
未タグ1,220語すべてに広げた場合の数字も出せますが、これは試算です。20件の平均を単純に1,220倍しただけで、実績ではありません。
| 手動 | AI下書きあり | |
|---|---|---|
| レビュー時間 | 約4.1時間 | 約0.9時間 |
| 生成コスト | 0円 | 約340円 |
20件の平均を1,220倍しただけの数字です。実際は語の難易度や作業者の疲労でばらつくため、「4.1時間が0.9時間になる」と断定はできません。幅を持って見てください。
学び ― 速くなった理由は「思い出す作業が消えたから」
ここが一番腑に落ちた点です。手動側にも同じタグ候補を出しているので、手動とAI下書きありの差は「候補から探して選ぶ」か「選ばれたものを確認する」かの違いだけです。それだけで所要時間が約1/5になりました。速さの正体は推論の賢さではなく、「思い出して探す」という認知コストが消えたことでした。生成AIの効きどころは、必ずしも難しい判断の代替ではなく、こういう地味な探索の肩代わりにあるのかもしれません。
そして90%そのまま採用できたのは、語彙を固定したからです。13,826件の全タグから自由に選ばせるのではなく、同カテゴリで使用頻度の高い40件に絞って渡しました。選択肢を狭めるほど下書きは確認しやすくなり、確認の速さと採用率の両方が上がります。逆に言えば、選択肢を広げるほど「もっともらしいが微妙にずれた提案」が増え、確認コストが上がるということです。
もう一つ、前述の「空で確定」の件が示すのは、計測ツールを疑う姿勢の重要性です。出てきた数字を信じる前に、その数字がどう作られたかを見に行く。今回は幸い計測前に気づけましたが、率だけ眺めて満足していたら、手動側が不当に速い偽の Before/After を事例にしていたはずです。
測っていないので書かないこと
誇大にならないよう、母数と条件を添えます。12.1秒 → 2.6秒 は「各20件・作業者1名・中身を入れて確定したもののみ」、採用率90%は「20件中18件」、生成コストは「各23件の平均で母数が小さい」、4.1時間 → 0.9時間は「1,220件に掛けた試算」です。
- 作業者を増やしたときの再現性 … 1名・1回の計測です。人が変われば数字は動きます
- 例文作成の Before/After … タグ付けのみ計測。例文は未計測です
- 生成品質の人手評価（正しさの点数） … 見ているのは「そのまま採用できたか」だけです
- 反映後のカバレッジ改善 … まだ本番へ反映していません
- CTR・表示回数・検索順位・売上への影響 … 交絡が大きく、因果を主張できないため測りません
他の案件に持っていける型
- 「AIは下書きまで、確定は人」の型。記事・商品説明・社内文書の分類など、公開物や量の多い判断作業にそのまま使えます。
- 語彙を固定した分類。既存のタグ・カテゴリから選ばせ、候補外を機械的に捨てる。分類の乱立とハルシネーションを構造で防げます。
- 効果を同じ計り方で比べる仕組み。「速くなった気がする」で終わらせないために、比較できる形を先に作る。母数から外すものも先に決める。
- 書き込み経路を2つに絞る設計。できることを減らすことで、事故の余地そのものを減らす。
「量が多く、人が読んで判断している作業」は、生成AIの下書きが効きやすい領域です。ただし効くかどうかは、盛らずに同じ計り方で測ってみないと分かりません。事例の要約（非エンジニア・決済者向け）は 実績ページ に、AI活用の他の事例は AI活用ページ にまとめています。既存の業務やメディアへのAI導入のご相談は お問い合わせ から。
