AIに「最速化して」と言うだけでコードが激変した話——非エンジニアが学んだ、たった1つの魔法の頼み方

この記事でわかること

AIにコード改善を頼むときの「たった1つの魔法の言葉」
非エンジニアでも使える、Before/After比較のプロンプト術
AIが嫌がる頼み方／AIが力を発揮する頼み方の違い
プログラミング知識がなくても、AIに「判断」を委ねる技術

AIに「最速化して」と言っただけで起きたこと

結論から書きます。

自作のGAS（Google Apps Script）の処理時間が長くて困っていました。在庫リストを1件ずつ処理するループで、実行のたびに数十秒かかる。

試しにAIに、コードを貼り付けてこう聞きました。

このコード、最速化して

返ってきたコードを動かすと、処理時間が20〜30秒から5秒くらいに短縮しました。何が変わったのか、正直よくわかりませんでした。AIの説明を読んで初めて「ああ、そういうことか」と理解しました。

具体的に何が起きていたかというと、僕のコードは一覧データから毎回検索をかけて、次の動作に移るたびにまた検索をかけていたんです。動作のたびに検索が走るので、体感で20〜30秒はかかっていました。追加に追加を重ねたコードだから、どこが遅いのか自分ではもう分からない。「とりあえず最速化して」とAIに投げたら、返ってきた説明に「この動作では検索を1回省略します」「ここはまとめて取得します」みたいなことが書かれていて、「なるほど、こういう無駄な処理を省いて速くしてるんだ」と目に見えて納得できました。

ちなみに、この「ループが重くなっていたコード」は、3,700種の在庫管理をExcelからGAS×スプレッドシートに移行した仕組みの一部です。品番数が多いと動作が重くなるという話は、その記事でも書いています。

なぜ「最速化して」だけで効いたのか

あとから振り返って気づいたことがあります。

僕がAIに「最速化して」と投げたとき、AIは内部でこう考えたはずです：

このコードの目的は「在庫リストを処理すること」
現状のボトルネックは「1件ずつの逐次処理」
最速化の手段は「まとめて処理する」「不要な処理を省く」
このGASの構造なら「まとめて処理」が最適

つまりAIは「判断」をしています。

僕がやったのは、たった3文字「最速化」と打っただけ。あとの判断は全部AIに委ねた。

これ、実は非エンジニアにとって超重要な気づきでした。

正直に言うと、判断をAIに丸投げすることへの抵抗感はありました。「自分があまり考えずに任せちゃっていいのかな」という後ろめたさです。でも、それまでにも結構雑な頼み方をして、ちゃんと動くものを返してくれた実績がありました。「最速化して」を何回か繰り返すと、AIが「じゃあこの部分を」「次はここを」とどんどん対応してくれる。何回も重ねていけば自分のやりたいことは実現できる——そう確信できた瞬間に、抵抗感はすっと消えました。

そもそもこの「AIに聞きながらコードを書く」スタイル自体については、バイブコーディングとは何かにもう少し丁寧にまとめています。本記事の「最速化して」も、バイブコーディングで育った頼み方の1つです。

「良い頼み方」と「悪い頼み方」の比較

悪い頼み方の例

このコードのループ構造を書き換えて、
for文をやめて、batchUpdateを使って、
並列処理で、エラーハンドリングも追加して、
ログも出して、処理時間を計測できるようにして。

問題点：手段を細かく指定しすぎ。しかも自分が正解を知らないのに指定している。結果、AIが「その通り」のコードを書いて、実は最適じゃない。

良い頼み方の例

このコード、最速化して。

なぜ良いか：目的だけ伝えて、手段はAIに委ねる。AIのほうが「何が最適か」の知識は豊富。

「魔法の言葉」の公式

僕が試行錯誤して見つけた公式はこれです。

動詞（1つだけ）＋対象

例：

動詞	対象	プロンプト例
最速化して	このコード	このコード、最速化して
短くして	この文章	この文章、半分の長さに短くして
シンプルにして	この設計	この設計、シンプルにして
分かりやすくして	この説明	この説明、小学生にもわかるようにして
見やすくして	この表	この表、見やすくして

動詞を複数並べない。「最速化してかつエラーも減らして」は、AIが迷います。

非エンジニアがハマりやすい罠

罠1：「AIに具体的に指示しないと動かない」という誤解

AI活用の入門書には「プロンプトは具体的に」と書いてあります。確かに方向性としては正しい。

でも、自分が答えを知らない領域では、具体的な指示は逆効果です。僕はプログラムの最適化方法なんて知りません。だから「最速化して」と抽象的に頼むほうが、AIの力を引き出せます。

罠2：「一度に全部やらせようとする」

最速化・エラー対策・ログ出力・コメント追加——全部一度に頼みたくなります。でも1ターン1目的のほうが、結果は良くなります。

僕のやり方：

まず「最速化して」→ 動くコードを受け取る
次に「エラーハンドリング追加して」→ 追加版を受け取る
最後に「コメント足して」→ 完成版

罠3：「AIの提案を鵜呑みにする」

AIが出したコードが速くなっていても、動作確認は絶対に自分でやる。

僕は一度、AIの提案を検証せずに本番環境に反映して、別の機能が壊れたことがありました。「速いけど間違っている」は最悪です。

実際に僕がヒヤッとしたのは、ちょっと違うパターンでした。「もう一回お願い」とAIに頼んだら、追加で重ねてきた機能を全部なかったことにして、ゼロから再構築されてしまったんです。追加を繰り返した結果シートが増えすぎていて、AIが「この機能はいらない」と判断したんでしょう。一気に削除されて、シートごと消えました。元データも一緒に飛んでしまって、貼り直しはできたものの、あのときは本当に怖かった。AIに判断を委ねるのは有効だけど、最終的な判断は自分次第。そこを忘れると危ないと、身をもって実感しました。

「動詞＋対象」の応用範囲

この公式、コードだけじゃなく他のことにも使えます。

文章作成

「このメール、丁寧にして」
「この議事録、箇条書きにして」
「この挨拶文、短くして」

資料作成

「このスライド、構成をシンプルにして」
「この提案書、結論を先に書いて」

日常業務

「このタスクリスト、優先順位つけて」
「この会議の議事録、要点3つに絞って」

AIは「判断すること」が得意。僕たちがやるべきなのは「判断の方向性」を短く伝えることです。

この「短く頼めば動く」という考え方は、複数のAIエージェントをチーム化したClaude CodeでのAI会社運営でも効いてきます。各部署への指示を短くしておくほど、秘書部が迷わずに判断してくれる、というのは実運用で実感していることです。

まとめ

AIに「最速化して」「シンプルにして」と頼むだけで、コードも文章も目に見えて改善する
動詞1つ＋対象の公式が、非エンジニアにとって最強のプロンプト術
手段を細かく指定するより、目的だけ伝えてAIに判断を委ねるほうが良い結果になる
ただし、動作確認は必ず自分でやる（これは絶対）

プロンプト術は、難しい構文を覚えることじゃありません。「AIに何を任せるか」を決める技術です。