AIに『この作業を自動化すると何が難しいか』と逆質問したら、先に地雷が見えた話

『作り方』より先に『壊れ方』を聞いたら、見える景色が変わった

意気揚々とプログラミングの学習を始めた会社員が、最初の一週間で必ず突き当たる壁があります。それは、ツールが「動かない」ことではありません。自分の書いた拙いコードが、予期せぬ入力やちょっとした環境の変化であっけなく「止まる」ことなのです。昨日まで完璧に動いていたExcelマクロが、誰かがセルを一列挿入しただけでゴミと化す。そんな光景を、私は嫌というほど見てきました。

多くの初心者は、ChatGPTやClaudeに向かって「この作業を自動化するPythonコードを書いて」と頼みます。生成されたコードをそのままコピペして、一度だけ動くのを見て満足します。しかし、それが地獄の始まりです。実務には、プログラミングの教本には載っていない「地雷」が無数に埋まっています。住所の入力欄に電話番号を入れる同僚、勝手にファイル名を変更する上司、そしてネットワークの瞬断。これら全てを想定していない自動化ツールは、現場では武器ではなく、ただの時限爆弾になりかねません。

ある時、私はAIへのアプローチを180度変えてみました。「このコードを書いて」と言う前に、今の業務フローを詳細に伝え、こう逆質問したのです。「この作業を自動化しようとしたとき、どんな理由でプログラムは止まってしまうだろうか？ プログラミングの観点から、想定される例外や地雷をできるだけ意地悪に列挙してほしい」と。

以前、経費精算の自動化を試みた際、意気揚々とコードを書きましたが、たった一つの「空のセル」があるだけでプログラムが強制終了しました。修正に3時間を費やし、結局その日は手作業でやった方が早かったという屈辱を味わいました。AIに逆質問を投げたのは、その敗北感から這い上がるためでした。

返ってきた回答には、自分では決して気づけなかった視点が並んでいました。プログラムが動くためのハッピーパスではなく、奈落の底へ落ちるためのデッドエンド。それを先に知ることで、ようやく「実務に耐えうる自動化」の設計図が見えてきたのです。

AIへの逆質問で拾えた5つの地雷（例外・入力ゆれ・権限・締日・手作業）

逆質問によって浮き彫りになった地雷は、大きく5つのカテゴリーに分類できます。これらを無視して実装に進むのは、地図を持たずに樹海へ踏み込むのと同義です。

一つ目は「例外処理」の欠落です。正常なデータが来ることを前提にしたコードは、少しでもノイズが混ざると即座に停止してしまいます。例えば、数値が入るべき場所に「未定」という文字列が入っていたらどうするか。ファイルがロックされていたらどう反応するか。AIはこうした「もしも」のパターンを、人間よりも遥かに冷徹にリストアップしてくれます。

二つ目は「入力ゆれ」です。Microsoft Excelを業務の起点にしている以上、これは避けて通れません。全角と半角の混在、不要なスペース、勝手に補完される日付形式。これらは人間の目には同じに見えますが、PythonやVBAにとっては全くの別物です。

三つ目は「権限」の壁です。ローカルPCでは動くのに、共有フォルダやクラウド環境に持っていくと途端にアクセス拒否されることがあります。あるいは、セキュリティソフトがPythonの挙動を検知してプロセスを殺すこともあります。IT部門のルールを考慮しない自動化は、社内規定違反という別の地雷を踏むことになりかねません。

四つ目は「締日と運用タイミング」の問題です。自動化ツールにはカレンダーの感覚がありません。月を跨いだ瞬間にパスが変わる設定になっていないか。連休中に実行された場合の挙動は考慮されているか。特に経理や総務の業務では、1日ずれるだけでデータの意味が180度変わることがあります。

地雷分類を5項目に固定して事前チェックを行った場合と、行わなかった場合での、実装後の修正回数の比較（平均3.5回から0.8回へ減少）

最後は「手作業の介在」です。全ての工程を自動化するのは理想ですが、現実には「人間が目視で確認してハンコを押す」といったアナログな工程が挟まります。この接続部分をどう設計するか。AIに「どこで人間が介入すべきか」を逆質問すると、無理な全自動化を目指して自滅するリスクを回避できます。

請求書の自動発行ツールを作った際、最後に人間が内容をプレビューする工程を省いた結果、宛先不明のメールが100件以上送信されそうになったことがあります。送信ボタンを押す直前で手が震えましたが、あの時AIに『人間が介在すべき点は？』と聞いていれば、最初からプレビュー画面を実装していただろうと後悔しました。

AIが見つけた地雷をどう乗り越えるか：安全な自動化のための具体的な設計思想

AIとの逆質問によって浮き彫りになった地雷は、単なる警告ではありません。それは、実務で実際に使える自動化ツールを構築するための「設計要件」そのものです。地雷を特定するだけでは半分しか終わっていません。その地雷を踏まないために、いかにプログラムを堅牢にするか、その具体的な設計思想が次に問われます。

経費精算の自動化で空のセルに躓いた経験や、請求書で宛先不明のメールを大量送信しそうになった過去は、地雷の存在を知るだけでは不十分だと教えてくれました。重要なのは、特定した地雷に対して「では、どう対処すべきか？」という問いをAIに投げかけ、具体的な対策をコードに落とし込ませるプロセスです。

例外処理の設計は、地雷原を舗装するようなものです。AIに「ファイルが見つからなかった場合、処理を中断するのではなく、『ファイルが存在しません』と通知し、次のファイルの処理に進んでほしい」と指示します。Pythonで言えば`try-except`ブロックの導入がこれにあたります。プログラムが途中で止まってしまい、エラーメッセージが理解不能な文字列では、自動化ツールは誰も使わなくなってしまいます。なぜなら、そのたびに担当者はエンジニアに質問したり、自力で原因を探したりする手間を強いられるからです。エラーが起きても、システムは優しく「なぜ」止まったのか、「どうすれば良いか」を教えてくれるべきなのです。

入力ゆれ対策は、データの品質を守る最前線です。AIには、「この入力欄の文字列は、必ず半角に変換し、前後の不要なスペースは除去して、日付形式は『YYYY/MM/DD』に統一してほしい」と具体的に命じます。これは、人間には当たり前の「常識」が、プログラムにとっては未知の「例外」になり得るからです。例えば、同じ「株式会社」でも「（株）」と入力されたり、全角スペースと半角スペースが混在したりします。これらをAIに一律で整形させることで、データの揺らぎによる処理エラーを劇的に減らせます。AIは、人間が手作業で行うような「目視での確認・修正」を、一瞬で正確に完了させる能力を持っています。

権限の壁を回避するには、プログラムの実行環境を意識した設計が不可欠です。ローカルPCで動いたとしても、サーバーや他者のPCでは権限不足で動かないことは日常茶飯事です。AIには、「この処理を実行する前に、指定された共有フォルダへの書き込み権限があるか確認し、ない場合は適切なエラーメッセージを表示して処理を停止してほしい」と指示します。これは、プログラムが突然停止し、原因が「アクセス権限」という非技術的な問題であった場合、現場の担当者が途方に暮れるのを防ぎます。IT部門への問い合わせや、セキュリティポリシーの確認といった、本来の業務ではない「調整業務」が頻発すれば、自動化の効果は薄れてしまうでしょう。

運用のタイミング、特に締日や休日を跨ぐ処理では、AIに「この業務は毎月25日に実行されるが、25日が土日祝日の場合は前倒しで24日に実行する。その場合、日付の変数も自動で調整してほしい」と依頼します。カレンダーの概念を持たないプログラムは、指示された日付をただ忠実に実行するだけです。経理の月次決算や総務の給与計算など、締め切り厳守の業務では、この「日付の柔軟性」が命取りになります。AIに具体的な条件を伝えることで、カレンダーに左右されない、賢い自動化ツールを構築できます。

そして、手作業の介在です。これは自動化の限界点であると同時に、プログラムの安全弁でもあります。AIに「請求書の発行処理の最後に、生成された請求書PDFを人間が目視で確認し、承認ボタンを押してから送信するフローを組み込んでほしい」と依頼します。完璧な自動化を目指すあまり、人間のチェック工程を省略すれば、致命的なミスに繋がりかねません。人間の直感や最終判断は、現在のAIにはまだ代替できない領域です。この接続部分をいかにスムーズに、かつ安全に設計するかが、自動化ツールが「使える」かどうかの分かれ目となります。

『動くコード』から『使われ続けるツール』へ：AI時代の実務家が持つべき視点

一度動くコードは、AIの力を借りれば簡単に手に入る時代になりました。しかし、それは自動化の最終目標ではありません。本当に価値があるのは、「現場で問題なく使い続けられるツール」です。総務、経理、人事の会社員がプログラミングに挑戦する際、この「使われ続ける」という視点を最初から持つことが極めて重要です。なぜなら、単発で動くコードと、長期的に運用されるツールとの間には、大きな隔たりがあるからです。

「なぜ、作ったツールは使われなくなるのか？」多くの場合、理由はシンプルなものです。エラーが頻発して信用を失う、操作が複雑で使うのが面倒になる、あるいは、作った本人しか触れない「ブラックボックス」と化してしまう。これらの問題は、地雷対策の不備だけでなく、保守性や運用性、そして引き継ぎの視点が欠けていることから生じます。

AIとプログラミングを学ぶ非エンジニアが持つべきは、単なる「コードを書くスキル」だけではありません。「仕様書を書く能力」や「テストをする習慣」、そして「運用を想像する力」です。AIとの対話そのものが、ある種の仕様書作成プロセスだと理解しましょう。プロンプトとしてAIに伝えた業務フローや、逆質問で得られた地雷リストは、ツール開発における重要なドキュメントになります。これらは、将来的にツールを改修したり、他の人に引き継いだりする際の強力な手がかりとなります。自分だけでなく、他の人が見ても「なぜこのツールが存在し、どう動くのか」が分かるように、AIとの対話履歴を保存するだけでも、大きな意味を持つはずです。

AIが生成したコードは、あくまで「たたき台」です。そのまま実務に投入するのは危険極まりありません。だからこそ、「テスト」の習慣が不可欠です。AIがどんなに完璧なコードを生成したと主張しても、自分の手でハッピーパスだけでなく、地雷となり得るイレギュラーな入力や環境変化を積極的に試すのです。「もしこのファイルが存在しなかったら？」「もし担当者が変わって、共有フォルダのパスが変わったら？」「もし月初めの特定の日にだけこの処理を動かしたい場合、どうなる？」これらの問いを自らに課し、ツールがそれらの状況にどう耐えうるかを検証してください。

さらに、「運用視点」は、作ったツールを「使われ続ける」ものにするための要諦です。「このツールは一年後も同じように使えるか？」「担当者が異動になったら、誰がこのツールの面倒を見るのか？」「バージョンアップやOSの変更に耐えられるのか？」常にこうした問いを心に留めておくと良いでしょう。自動化ツールは、一度作ったら終わりではありません。業務の変化に合わせて改善し、時には見直す必要もあるのです。

AIはあくまで強力な「道具」であり、私たちの「思考を深めるパートナー」です。AIにコードを生成させるだけでなく、そのコードの背後にある「なぜ」を考え、地雷を踏まない設計思想を培い、持続可能な運用までを見据える。これこそが、AI時代における非エンジニアの実務家が身につけるべき、最も重要なスキルとなるはずです。