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業務など、
現場の「ちょっと面倒」を仕組みに変えるような改善を続けていきたいです。