AIに「もっとシンプルに」と頼むと何が変わるのか。コード行数と読みやすさのトレードオフ

恐怖の長コード、短縮の地獄

毎月繰り返される、気が遠くなるようなExcelの集計作業。各部署から送られてくるフォーマットの異なる売上データを1つのファイルにまとめ。PDF化して関係者にメールで送信する。この業務だけで、毎月末に3時間以上の残業が確定していた。なんとかしてこの手作業から解放されたい。その一心で、私はChatGPTの画面を開いた。「この手作業をPythonで自動化するコードを書いて」と。

祈るような気持ちで業務の手順を打ち込む。数秒後、画面の黒い背景の上に、色鮮やかな文字がスラスラと出力され始めた。ここまでは完璧な体験だった。問題は、そのコードの圧倒的な長さです。

非エンジニアのコード恐怖、AI短縮の地獄

画面を埋め尽くす150行以上のテキスト。importから始まり、見慣れないdefという文字がいくつも並び。try-exceptというブロックで複雑に囲まれている。非エンジニアの私にとって、それは未知の古代文字を読むようなものだった。長い。あまりにも長すぎる。「こんな巨大なプログラムを自分のPCで実行して。本当に大丈夫だろうか」
漠然とした不安が胸をよぎる。

もし途中で予期せぬエラーが起きてシステムが止まってしまったら。上司に「自動化に失敗しました。今月も手作業でやります」と頭を下げる自分の姿が脳裏に浮かんだ。非エンジニアにとって、長いコードはそれだけで恐怖の対象だ。自分が完全にコントロールできない巨大な機械を動かすようなプレッシャーがある。だから私は、ごく自然な思いつきでAIにプロンプトを追加してしまった。

「もっと短く、シンプルにして」
これがいけなかった。この一言が、後戻りできない地獄の扉を開くことになる。

感動からのエラー地獄

まず、長すぎるコードに怯え、ChatGPTに「もっと短くして」とお願いした。わずか3秒後、150行あったコードが見事に20行まで圧縮された。その瞬間は「おお、AIすごい！」と無邪気に感動し、完全に勝った気になっていた。しかし、その短いコードをコピーして実行し、無情なエラーメッセージが出た時。手も足も出ない地獄が始まるとは想像もしていなかったのです。

シンプル化の落とし穴

「シンプルにして」と頼んだ結果、たしかに行数は激減した。スクロールしなくても全体が見渡せる。パッと見の圧迫感は消え去った。しかし、その中身をよく見ると、先ほどとは全くの別物になっていたのです。

読めぬ短縮コードの罠

150行が20行になったのは、「無駄が削ぎ落とされた」からではない。強引に「圧縮された」だけだった。
`[x for x in data if lambda y: …]` のような、意味不明な記号の羅列。
先ほどの長いコードは、英単語の並びから「ここでExcelを開いているな」「ここで保存しているな」と、なんとなく処理の流れを想像できた。しかし、目の前にある20行は違う。

1行の中にデータの読み込み、抽出、変換、保存がぎっしりと詰め込まれている。
完全に暗号化されていた。
試しに実行ボタンを押してみる。当然のように赤い文字のエラーを吐き出して停止した。
原因を探ろうにも、どこでプログラムが躓いているのかすら追えない。
「KeyError: ‘売上’」というエラーが出ても、20行のコードのどこでそのエラーが発生したのか特定できないのだ。

すべてが1行の中で同時並行で行われているため、途中の状態を覗き見る隙間がありません。

短いAIコード、不毛なエラーラリー

次に、赤いエラーメッセージが出たので、とりあえずAIにエラー文をそのまま投げ返した。すると「この部分を修正しました」とさらに難解なワンライナー（1行のコード）が返ってくる。それを貼り付けてもまた別のエラーが出る。この不毛なラリーを1時間ほど繰り返した頃には、目の奥が霞み。胃の底に重たい石が沈んでいるような感覚に襲われていた。窓の外はすっかり暗くなり、オフィスから一人、また一人と人が減っていく。

コードが短いことと、内容が分かりやすいことは、決してイコールではない。この残酷な事実を、私は冷や汗とともに身をもって知ることになった。

エラー原因の特定にかかる時間：長いベタ書きコード vs 暗号化した短いコード（分単位）

AIの「シンプル」と私たちの「読みやすさ

一方で、なぜAIは、頼みもしない難解な記法を使ってきたのだろうか。その理由は、AIの背後にある学習データ。つまり世界中のプロエンジニアたちが考える「シンプル」の定義にある。

プログラミングの世界には。DRY（Don’t Repeat Yourself）という有名な原則がある。エンジニアにとっての「シンプル」とは、処理の重複がなく、計算量が少なく。無駄な記述が一切ないことだ。同じような処理を何度も書くのは悪であり。いかに少ない記述で美しいロジックを組むかが彼らの美学である。AIは優秀なアシスタントだからこそ。この「プロにとっての正解」を忠実に出力しようとしたのだ。

私たちの求める「シンプル」は、これとは全く違う。

非エンジニアの読みやすさと「シンプル」の暴走

私たちが欲しいのは、美しさではない。1つ1つの手順が明確で、上から下へ素直に流れる「泥臭い」コードだ。少しくらい処理が重複していても構わない。途中のデータがどうなっているか、どこまで処理が成功したかが。手に取るように分かること。それが総務や経理の人間が考える「読みやすさ」である。言葉の定義が根本的にズレている。だから「シンプルに」という曖昧な指示は。非エンジニアにとって自爆スイッチになり得る。

AIの高度な技術力を暴走させ。自分では制御できないモンスターを生み出してしまうからです。

デバッグ優先のコード

そのため、具体的に比較してみよう。A列から特定の社員名を探し出し、B列の金額を合計するというよくある処理です。

AIが書くスマートな1行のコード（リスト内包表記）はこうなる。
`total = sum([row[‘金額’] for row in data if row[‘氏名’] == ‘田中’])`
たしかに1行で終わる。見た目もスタイリッシュだ。
しかし、もし田中さんの金額データに「未定」という文字が混ざっていたらどうなるか。文字列は足し算できないため、一瞬でプログラムがクラッシュする。

そして「どの行の田中さんでおかしくなったのか」は全く分からない。
一方、昔ながらの「泥臭いFor文」で書くとこうなる。

空の変数を用意する。データを1行ずつ取り出す。名前が田中かどうか確認する。金額を足し合わせる。

しかし、行数は5倍になる。しかし、この泥臭さこそが最大の防御になるのです。

非エンジニアの味方、`print`デバッグ術

For文で書かれた長いコードでエラーが出た時。ループの中に print(row[‘金額’]) という一文を書き加えて実行してみた。すると、ターミナルに処理中の金額データが順番に表示され、「あ。30件目のデータで空白セルが混ざった瞬間に止まっている！」と一瞬で原因を特定できたのだ。あの時の安堵感は忘れられない。コードの泥臭さは、いざという時のデバッグのしやすさに直結している。

一撃で処理を終わらせるのではなく、途中でデータを覗き見できる隙間を作っておく。非エンジニアにとって、エラー箇所が自力で分かるかどうかは死活問題だ。だからこそ、洗練された記法よりも。稚拙なまでに分かりやすいベタ書きを選ぶべきなのです。

自動化ツールの保守と運用

さらに、業務の自動化は、作って終わりではない。社内システムの仕様変更。エクセルファイルのフォーマット変更。担当者の異動。会社という環境は常に変化し続ける。そのたびに、私たちはコードを修正しなければならありません。

数ヶ月後、久しぶりにその自動化スクリプトを開いた時のことを想像してみてほしい。短くてカッコいいが、何を意味しているのか全く思い出せないコード。それは、いつ爆発するかも分からない時限爆弾を抱え込んでいるのと同じだ。当時書いた（あるいはAIに出力させた）自分ですら理解できないのだから。後任者に引き継ぐことなど到底不可能である。「私が休んだらこのツール止まるんですけど。

どうすればいいですか」と途方に暮れる日が必ず来る。変数が無駄に多くて、縦に長くなってもいい。日本語のコメントがコード本体よりも多く書かれていても構わない。「ここでA列のデータを取得している」「ここでは空白を飛ばしている」と。1行ずつ読めば確実に理解できる状態を死守することが。運用において最も価値があるのです。

社内ツールの保守メンテナンスにかかる年間コストの概算（万円単位）

まず、メンテナンスできない自動化ツールは、資産ではなくただの負債です。

AIを操るベタ書きプロンプト

では、AIにコードを書かせる時、どう指示を出せばいいのか。解決策は非常にシンプルだ。AIの「賢すぎる」部分を意図的に封印してしまえばいい。

今日から「シンプルに」「短くして」という言葉は封印する。代わりに、以下のようなプロンプトを打ち込むのです。

次に、「小学生でもわかるように。1行ずつベタ書きで処理を書いて」
「内包表記やlambdaなど。高度な関数は絶対に使わないで」
「変数名は長くてもいいから。何が入っているか明確にして」
「途中でprint文を入れて。処理の進捗が画面で確認できるようにして」。

たったこれだけの工夫で、出てくるコードの質が劇的に変わる。AIは渋々といった感じで、無骨で長く。時には野暮ったいコードを出力してくるだろう。しかし、そのコードこそが、あなたにとっての最高のパートナーになる。プロンプトを変えたことで、私自身のコード管理は信じられないほど楽になった。

ベタ書きが生む真のシンプル

この「ベタ書きプロンプト」を使い始めてから。数ヶ月前に作ったスクリプトの改修が全く怖くなくなった。久しぶりにファイルを開いても「ああ、ここでエクセルを開いて。ここで不要な文字を消しているんだな」と。まるで業務マニュアルを読むように理解できたのだ。エラーが出ても自分で直せるという確かな自信が。さらなる業務改善のモチベーションを押し上げてくれた。「読みやすさ」とは、決して「行数の少なさ」ではない。

自分が完全に理解し、いざという時に自力で直せること。それこそが、私たち会社員にとっての真の「シンプル」なのだ。📘 このスキルを活かしてさらに前へ進むならAIを使ったプログラミングをゼロから体系的に学びたい方には。生成AIプログラミングの教科書『大蔵～TAIZO～』がおすすめです。ChatGPTやClaude等の生成AIと組み合わせた実践的なコーディング手法を習得できます。

生成AIプログラミングの教科書『大蔵～TAIZO～』 →
📘 このスキルを活かしてさらに前へ進むならPythonやVBAを体系的に学びたい方には「SAMURAI ENGINEER」のマンツーマン指導が効果的です。

ベタ書きが生む真のシンプル（続き）

一方で、自分の業務で使うコードを講師と一緒に作りながら学べるため。「独学で挫折した」という方でも確実にスキルを習得できます。SAMURAI ENGINEER（Pythonコース） →
📘 このスキルを活かしてさらに前へ進むならPythonによる業務自動化を最短・最安で学びたい方には。UdemyのPython実践講座がコスパ最高です。セール時は¥1,500〜で。ExcelやメールをPythonで自動化する具体的な手順を動画で学べます。Udemy（Python実践・業務自動化） →
📘 このスキルを活かしてさらに前へ進むならPythonをもっと体系的に理解したい方には。実務向けの技術書で土台を固めるのも有効です。Amazonでは「Python 業務自動化」に関する評価の高い書籍が豊富に揃っています。Python業務自動化の技術書（Amazon） →

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

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