こんにちは。TOKIUM デジタライズチームの kztm です。私たちはオペレーション部（領収書などの書類のデータ化を担う部署）の現場を支えるシステム開発を担当しており、私はその中でデータ化を補助するAI機能の開発や改善を担当しています。
今回話したいのは、このAI機能の改善作業を思い切ってシステムのユーザーであるオペレーション部のメンバーに渡してみたということです。昨今ビジネスメンバーでもClaude Codeをつかって業務をするトレンドがきている中、こうした取り組みがどのような感じになるのか気になっている方のヒントになれば幸いです。
本記事で共有すること
- システムのユーザーにAI機能開発を渡すためにやったこと（線引きと足場づくり）
- 1サイクル回してできたこと（システムのユーザーによる自走と、出てきた基盤改善の提案）
- 渡してみて見えた課題（自動化の塩梅、エンジニア側で吸収すべき構造的な部分）
モチベーション
オペレーション部のメンバーに渡してみた動機は、AIモデルの精度向上にはドメインエキスパートが直接フィードバックを返すループのほうが、エンジニアが間に立って推測でデータをいじるよりも速くて本質的なはずだ、という仮説です。毎日データに触れている現場の人が直接モデルを教育するほうが筋がよさそうだと考えました。
社内には適任者がいました。オペレーション部データ課のメンバーで、データ入力作業者の管理と入力の品質改善などを担当している方です。普段の業務はGoogle Apps Script (GAS) とスプレッドシートで回しており、最近はClaude Codeで業務を進めることも増えていました。
実際に渡してみて、本人から以下のような感想を頂きました。
今までは改善案を出してエンジニアに依頼するのみで、実装の難易度を把握しきれていない部分がありました。今回、自らエンジニアの領域に踏み込んでチューニングを体験したことは、非常に大きな経験です。
実際のミスの内容を自分の目で確認し、直接AIを教育することで、現場主導でよりスピーディーに精度を高めていける可能性を感じています。
何を渡して、何を渡さないか
AIモデルの学習サイクルはざっくり以下のような流れで回しています。
このサイクルのどこを渡し、どこをエンジニアが持つか。最初に決めたのは、専門性の境界線をどこに引くかでした。上の図で示したサイクル全体をシステムのユーザーに渡し、それを支える足場（検証環境のインフラ・手順書・ツール）をエンジニアが持つ、という構成にしました。特に出力の分析については、オペレーション部が分析を日々行なっているため経験をフル活用できると思います。
また、検証までの作業を全て自動化してブラックボックスにしてしまうと今後の開発業務の広がりに影響があると思い、手作業を挟んだりしています(ここについては後述していますが何を自動化するかとかは今後決めていきたいと思っています)。
以下の図のように線引きを整理しました。両者を繋ぐ足場（エンジニアが用意する手順書・インフラ環境・ツールのセット）については、次のセクションで具体的に説明します。
用意した3つの足場
システムのユーザーに作業を渡すにあたり、エンジニア側で以下の3つの足場を用意しました。
| 足場 | エンジニア側で用意したもの | システムのユーザーの活用 |
|---|---|---|
| 渡す作業の手順書 | 学習データ作成から精度検証の可視化までをステップごとに記述 | 手順書通りに進めて1サイクル回す |
| サーバーレスの検証環境 | 本番無影響で試せるインフラ。認証認可は最小権限で整備済み | データやプロンプトを変えて検証 |
| 精度評価を可視化する Claude Code の Skill | Plotly で対話的な HTML を出力するスクリプト群を目的別にまとめたもの | Claude Code に自然言語で依頼して結果を確認 |
3つ目の Skill には、たとえば以下のように Claude Code に依頼すれば、適切なスクリプトを選んで実行してくれます。
この検証結果のjsonファイルでAI出力の精度や間違えデータを可視化して
1サイクル回してわかったこと
実際に渡してみると、いくつか気づくことがありました。
開発用語の壁が残る
まず、当たり前といえば当たり前なのですが、開発作業ではエンジニアしか普段使わない言葉で溢れているということです。Claude Codeで作業しているといってもこの「ターミナル」とはどういう意味かという話にもなりますし、ファイルが見つかりませんでしたというコマンドエラーが出ても、パスが通っているかどうかという観点がない、ということもあります。このあたりの本質的ではなさそうな情報はなるべく意識させたくないとは思いつつ、ある程度は漏れてしまうかもしれません。
予想外: システムのユーザーから基盤システムへの提案が出た
一番面白かったのは、その先に出てきた提案の方向性です。私はプロンプトの微調整やデータの増やし方といった、枝葉の改善提案を予想していました。このフィールドはこう書き換えよう、ここの学習データを増やそうという粒度の話です。
実際に出てきたのは、学習サイクルそのものを手戻りなく回すための、基盤システムの提案でした。分析の過程などで修正されたデータはシステム的に一元化されたほうがいいなど、サイクル全体を一度通しで触ってみて、構造側に課題を感じる方向に思考が動いたようです。
データ入力のワーカー管理を本業にしている人ならではの視点で、エンジニア側のタスクとして取り込み、次のサイクルまでに整える方向で進めています。
全部自動化しない、という選択
最初から特定のタスクを全部自動化したシステムを渡す、という選択肢もありました。エラーが出ない、迷わない、押せば結果を出すシステムです。
これを選ばなかったのは、手作業を全部自動化して現場を単なるオペレーターにするのではなく、あえて手触りを残し、エンジニアと同じ目線でシステムの構造を考えてもらうためです。今回、システムのユーザーの側から基盤システムの提案が返ってきたことを考えると、この設計判断は効いていたと感じています。
とはいえ、本筋から外れる部分（インフラ整備やシステム改修など）は足場側で吸収するべき領域です。作業効率と理解度のバランスは、定期的に対話しながら少しずつ寄せていきます。
次にやること
1サイクル回したばかりで、見えていることは限られています。次のサイクルでは、現場から出てきた要望をもとに、エンジニアはより高度なMLOps基盤の構築（自動化やデータパイプラインの整備）に集中します。本人の作業効率と理解度は、定期的に対話で確かめながら、足場と挑戦のバランスを調整していきます。
学習サイクルを渡した、というより、現場のプロとエンジニアの専門性の境界を少しずつ動かす取り組みになっている、というのが1サイクル目の実感です。今回は現場のプロ側がサイクル運用に踏み込み、構造側の気づきを返してくれました。次は私の側がその気づきを基盤に反映する番で、また新しい境界線が引かれていくのだと思います。