AIで作った業務ツールを、実務で使える状態にするまでに必要だったこと
はじめに
最近、AIを使えばコードを書くハードルはかなり下がりました。
「こういう処理をしたい」と伝えれば、ある程度動くコードは出てきます。
実際、自分も業務改善ツールを作る際にAIを活用しています。
ただ、実務で使う業務ツールの場合、
コードが一度動いた = 完成
ではありません。
むしろ、そこからが本番でした。
この記事では、EC運用の現場で使う業務ツールを作る中で感じた、
AIで作ったコードを実務投入するために必要だったこと
をまとめます。
背景
自分はEC運用やWeb制作の業務を行っています。
日々の業務では、以下のような作業が頻繁に発生します。
- CSVのダウンロード
- Excelへの貼り付け
- 商品コードやSKUの確認
- 売上データの集計
- モールごとの形式差の吸収
- FTP/SFTPでのファイルアップロード
- HTMLや画像パスの調整
ひとつひとつは小さな作業です。
ただ、毎月・毎週・毎日のように繰り返すとなると、
手作業では時間もかかりますし、ミスも起きます。
そこで、PythonやC#を使って社内用の小さな業務ツールを作るようになりました。
AIでコードを書くこと自体はかなり楽になった
AIを使うと、最初のコード作成はかなり速くなります。
例えば、以下のような処理であれば、かなり短時間でたたき台を作れます。
- CSVを読み込む
- 指定列だけ取り出す
- Excelに書き込む
- ファイル名から対象モールを判定する
- GUIでファイル選択できるようにする
- エラー時にメッセージを表示する
以前なら調べながら書いていた部分も、
AIに処理の流れを伝えれば、すぐにサンプルコードが出てきます。
この時点では非常に便利です。
ただし、実務ではここで終わりません。
実務で使うと、サンプルでは出てこない問題が起きる
実際の業務データは、サンプルのようにきれいではありません。
例えばCSVひとつ取っても、以下のような問題があります。
- モールごとに列の位置が違う
- 同じ意味の列でも見出し名が違う
- 数値にカンマが入っている
- 金額に「JPY」などの文字が混ざる
- 商品コードの先頭の0が消える
- Excelで開くと文字化けや列ズレが起きる
- 仕様が変わったように見えて、実はテンプレート側が原因だった
AIが出してくれるコードは、基本的には「想定通りのデータ」が前提です。
しかし、実務ではその想定が簡単に崩れます。
そのため、AIで作ったコードをそのまま使うのではなく、
現場のデータに合わせて検証し、例外を潰していく作業
が必要になります。
実務投入で特に大事だったこと
1. ファイル名だけに頼らない判定
最初はファイル名でモールを判定していました。
if "楽天" in filename:
mall = "rakuten"
elif "Yahoo" in filename:
mall = "yahoo"
この方法は分かりやすいですが、ファイル名の揺れに弱いです。
そのため、実際にはファイル名だけでなく、
CSVやExcelの見出しも確認するようにしました。
required_headers = ["注文番号", "商品番号", "売上金額"]
if all(header in headers for header in required_headers):
mall = "rakuten"
else:
raise ValueError("想定したCSV形式ではありません")
見出しを確認することで、
「違うファイルを選んでしまった」
「テンプレートが古い」
「CSV形式が変わった」
といった問題に気づきやすくなります。
2. エラーを握りつぶさない
業務ツールでは、エラーが起きた時に止まること自体は悪くありません。
むしろ危ないのは、
間違った処理結果を正常終了のように見せてしまうこと
です。
例えば、Excelに貼り付ける列が1列ずれていた場合、
処理自体は最後まで動いてしまうことがあります。
しかし、結果は間違っています。
そのため、以下のような確認を入れるようにしました。
必須列が存在するか
行数が想定より少なすぎないか
数値列に文字列が混ざっていないか
出力先シートが存在するか
貼り付け前後の件数が一致しているか
エラーを出すことより、
間違ったまま通す方が危険
だと考えるようになりました。
3. ログを残す
自分だけが使う小さなツールでも、ログは重要でした。
特に業務ツールの場合、後から
- どのファイルを処理したのか
- どこで失敗したのか
- 何件処理したのか
- いつ実行したのか
を確認したくなる場面があります。
簡単なログでも、後から原因を追いやすくなります。
import logging
logging.basicConfig(
filename="tool.log",
level=logging.INFO,
format="%(asctime)s %(levelname)s: %(message)s"
)
logging.info("処理開始")
logging.info(f"対象ファイル: {file_path}")
logging.info(f"処理件数: {count}")
ログがあるだけで、
「何が起きたか分からない」状態をかなり減らせます。
4. 非エンジニアでも使える形にする
コマンドラインで動くツールは、自分だけが使うなら問題ありません。
ただ、社内業務で使う場合は、
毎回コマンドを打つ形式だと使いづらくなります。
そのため、GUI化も行いました。
- ファイルを選択する
- 実行ボタンを押す
- 成功・失敗を画面に表示する
- エラー内容をログに残す
この程度でも、使いやすさはかなり変わります。
業務ツールは、技術的に高度であることよりも、
迷わず使えること
の方が重要な場面が多いです。
5. 設定をコードから分離する
モールごとの設定や、アップロード先、対象シート名などをコードに直接書くと、
変更があるたびにコードを修正する必要があります。
そこで、設定ファイルを使うようにしました。
例えばYAMLで以下のように管理します。
rakuten:
display_name: "楽天"
upload_dir: "/upload/rakuten/"
target_sheet: "楽天貼付け用"
yahoo:
display_name: "Yahoo"
upload_dir: "/upload/yahoo/"
target_sheet: "Yahoo貼付け用"
コード側では設定を読み込んで処理します。
import yaml
with open("settings.yaml", "r", encoding="utf-8") as f:
settings = yaml.safe_load(f)
こうしておくと、
処理のロジックと運用上の設定を分けることができます。
小さなツールでも、後から修正しやすくなります。
AIは便利だが、現場判断までは代わりにできない
AIは非常に便利です。
特に以下のような場面ではかなり助かります。
- 処理のたたき台を作る
- 書き方を調べる
- エラー原因の候補を出す
- コードを整理する
- 別の実装方法を提案してもらう
一方で、AIだけでは判断できないこともあります。
例えば、
- その処理が本当に業務上正しいのか
- どの列を正とするべきか
- 例外時に止めるべきか、スキップするべきか
- 担当者が使いやすい画面になっているか
- 運用上、どこまで自動化してよいか
このあたりは、現場を知っている人間が判断する必要があります。
AIはコードを書く速度を上げてくれます。
しかし、業務ツールとして成立させるには、
業務理解・検証・運用設計
が必要でした。
実際に作って感じたこと
AIのおかげで、ツール作成の初速はかなり上がりました。
ただ、完成度を上げるには、結局以下のような作業が必要です。
- 実データで試す
- エラーを再現する
- 原因を切り分ける
- 仕様の揺れを吸収する
- 手作業の流れと照らし合わせる
- 使う人が迷わない形にする
つまり、AIでコードを書くことと、
実務で使える業務ツールを作ることは、別の作業です。
コード生成はスタート地点であって、ゴールではありません。
まとめ
AIを使うことで、業務ツール作成のハードルはかなり下がりました。
しかし、実務で使うためには、以下が重要だと感じました。
- 実データで検証する
- ファイル形式や列の揺れを考慮する
- エラーを握りつぶさない
- ログを残す
- 非エンジニアでも使える形にする
- 設定をコードから分離する
- 業務上の正しさは人間が判断する
AIは強力な補助になります。
ただし、最後に必要になるのは、
現場で何が困っているのかを理解し、使える形に落とし込む力
だと思います。
今後も、Web制作・EC運用・CSV処理・Excel業務など、
現場の「ちょっと面倒」を仕組みに変えるような改善を続けていきたいです。