AIに「この処理の設計に問題はないか」と先に聞くと、後のデバッグがかなり楽になる話

本記事にはプロモーション（アフィリエイトリンク）を含みます。

AIプログラミングの落とし穴

AIを使えばプログラミングは簡単だと誰もが言う。チャット欄に「エクセルを集計するスクリプトを書いて」と打ち込めば、ものの数秒で立派なコードが出力される時代になった。しかし、現実はそんなに甘くない。意気揚々とコードをコピーし、実行ボタンを押した瞬間にターミナルは無慈悲な赤い文字で埋め尽くされる。

とりあえずChatGPTに「フォルダ内のPDFをまとめるPythonコードを書いて」と依頼し、コピペして実行した。すぐにAttributeErrorが出て、エラー文をそのままAIに投げ返す。直ったと思ったら次はFileNotFoundErrorが飛び出す。3時間同じことを繰り返し、夕方には目頭が熱くなってきて「最初から手でコピペしていればもう終わっていたのに」と猛烈に後悔した。

AIの盲点、暗黙の業務

なぜこんな悲劇が起きるのか。理由は明白で、AIが業務の「暗黙の了解」を一切知らないからです。AIは与えられた短い指示に対して、最も一般的な正解を返すに過ぎません。しかし実際の社内業務には、ファイル名に全角スペースが混じっていたり、謎の隠しファイルが存在していたりする。コードが完成してからこうしたイレギュラーに対処しようとすると、土台が崩れた家を無理やり補修するような状態に陥る。ツギハギだらけのコードはすぐに限界を迎え、どこを直しても別の場所でエラーが出るという悪夢のループが始まる。

AI設計士。例外洗い出しが自動化成功の鍵

エラーが出続ける根本的な原因は、設計図を持たずに家を建て始めていることにある。大工道具の使い方がわからない素人が、いきなり電動ノコギリを振り回しているようなものです。ここで発想を根本から変える必要がある。AIにいきなりプログラミング言語を書かせるのをやめるのです。

優秀なAIであるClaude 3.5 SonnetやChatGPT (GPT-4o)は、単なる翻訳機ではありません。論理の破綻を見つけ出す冷徹なレビューアーとしての能力を備えている。彼らをコード生成機としてではなく、ロジックの穴を指摘する「設計士」として活用する。これが非エンジニアが安全に業務自動化を進めるための鉄則となる。

いきなりPythonの文法に頼るから思考が停止する。人間の言葉で業務の手順を洗い出し、その手順に矛盾がないかをAIに尋ねる。例えば「A列の金額をB列に転記する」という指示があったとする。人間の目には完璧に見えても、AIは「A列が空欄だった場合はどう処理するか」「A列に文字が含まれていた場合はエラーを出して止めるか」と容赦なく問い詰めてくる。この設計の段階で例外に気づけるかどうかが、後々の疲労度を決定づける。

AIが明かすファイル整理自動化の落とし穴

総務や経理の現場で最も頻出する自動化タスクといえばファイルの整理でしょう。ダウンロードフォルダに溜まった請求書のPDFファイルを、取引先ごとのフォルダに移動させる。口頭で後輩に頼むなら「適当に分けといて」の一言で終わる単純作業です。これを自動化しようとしたとき、どれほどの危険が潜んでいるのかを想像してみてほしい。

月末の請求書処理を自動化しようとPythonスクリプトを走らせた。順調に進んでいるように見えたが、途中で「同名ファイルが存在します」というエラーを吐いて突然停止した。そこまでの100件は移動完了したのに残りの50件が手付かずになり、どれが終わってどれが終わっていないのか完全にわからなくなった。泣きそうになりながらエクスプローラーを左右に並べ、結局全部手作業で付け合わせる羽目になった。あの時の胃がキリキリ痛む感覚は二度と味わいたくありません。

実際にこの「ただのファイル移動」というタスクをAIに設計レビューさせると、驚くべき結果が返ってくる。

AIが指摘するファイル移動の盲点

実際に簡単なファイル移動のロジックを投げたところ、AIは即座に4件の致命的な例外（フォルダ未存在、同名ファイル、ファイルロック、特殊文字）を指摘してきました。

AIは冷酷に以下の事象を指摘する。移動先のフォルダがまだ存在しなかった場合はどうするのか。同名のファイルがすでに存在していたら上書きするのか、末尾に連番をつけるのか。ファイルが編集中で別のソフトにロックされていたら処理をスキップするのか。ファイル名にシステムが受け付けない特殊文字が入っていたらどう扱うのか。中身が0バイトの空ファイルでも移動させるのか。これらを一切考慮せずにコードを書くことは、目隠しをして高速道路を走るような暴挙に等しい。

AIでロジックを磨き、堅牢な設計図とコード生成

では、実際にどのようにAIへ指示を出せばいいのだろうか。やるべきことは驚くほどシンプルで、プログラミング言語の知識は一切必要ない。日本語でやりたいことを箇条書きにするだけでいい。この日本語の箇条書きを、エンジニアの世界では疑似コードと呼ぶ。

テキストエディタを開き、普段自分が手と目を使ってやっている作業を一つ残らず書き出す。どのフォルダを開き、何を見て判断し、どこへ移動させるのか。一連の流れが書けたら、それをコピーしてチャット欄に貼り付ける。AIに『このロジックに不備や例外漏れはないか？』と質問するのです。

AIは一瞬で手順書を読み込み、先ほど挙げたような例外ケースを列挙してくる。そこからが本当の設計作業の始まりです。指摘されたケースに対して「フォルダがない場合は新規作成する」「同名ファイルは連番をつける」と一つずつ方針を決定していく。方針が決まったら、それらを元の日本語の箇条書きに追記する。すべての例外を網羅し、AIから「もう論理的な抜け漏れはない」とお墨付きをもらう。その完璧な設計図が完成して初めて、AIにコード生成を依頼する。指摘されたケースをロジックに組み込んでからコード生成を依頼する手順を踏むだけで、出力されるコードの堅牢性は劇的に跳ね上がる。

設計ファーストがもたらす時間革命

設計を先に固めるというのは、一見すると面倒で遠回りに思えるかもしれません。早く動くものを見たいという誘惑に抗い、日本語の壁打ちに時間を費やすのは忍耐が必要です。しかし、この「急がば回れ」のアプローチは結果的に圧倒的な時間の節約をもたらす。

以前はコードが動かなくなるたびにAIにエラー文をコピペし、直っては壊れる無限ループに陥っていた。設計レビューを取り入れてからは、生成されたコードが一発で最後まで完走する確率が劇的に上がった。まれにエラーが出ても「あ、あの例外のパターンの話だな」と原因がすぐに特定できる。終わりの見えない残業の恐怖から完全に解放された瞬間でした。

実際にこの手法を導入する前後で、ツール作成にかかる時間を計測してみた結果がある。

設計なしで挑んだ際はエラー修正に120分を要しましたが、設計レビューを挟んだ際はわずか15分で完走。実に87%以上の時間削減に成功しました。

設計で防ぐ予期せぬエラー

プログラミングにおいて最も時間を食うのは「コードを書く時間」ではありません。「なぜ動かないのかわからない状態でエラーと格闘する時間」です。設計の段階であらかじめ考えうる壁を取り除いておけば、実行時の予期せぬエラーはほとんど発生しなくなる。エラーが起きたとしても、想定の範囲内の出来事として冷静に対処できる。行き当たりばったりでコードを書いていた頃の、あの暗闇の中を手探りで歩くような絶望感はもう味わわなくて済む。

AIとの設計対話、書かない時間

どれだけAIが進化し、数秒で数千行のコードを書き上げる時代になっても、プログラミングの本質は変わらない。AIは頭の中にある曖昧な願望を、勝手に空気を読んで完璧なシステムに仕上げてくれる魔法の杖ではありません。

プログラミング初心者が陥る最大の罠は、いつでも「焦ってコードを書こうとする」ことにある。コードを書き終えてから動かない原因を探すのは、建ち上がった家の壁を剥がして水漏れの原因を探すのと同じくらい困難です。だからこそ、AIをコードの自動生成機として使う前に、有能な設計士として対話の相手に選ぶ。

日本語でしっかりと要件を詰め、AIからの厳しい突っ込みを受け入れ、ロジックの穴を徹底的に潰していく。あえてプログラミング言語を書かずに、日本語だけで業務と向き合う時間。この「書かない時間」を意図的に作ることこそが、結果的にツールを最速で完成させ、退社時間を早める唯一の正解となる。

関連リンクとチェックリスト

学習サービスとアンケート