AI にコードを書かせると、何にデバッグ時間を取られるのか（随時更新）

「AI にコーディングさせてもデバッグに時間かなり取られるって本当ですか」という質問をよく見かけます。似た形で、「実務において、コード生成は AI でほぼ完結できるものなのでしょうか」「初心者はすごいと言い、プロはショボいと言う。この差は何か」というものもあります。

この記事は、その答えを一般論ではなく実際に自分たちの開発で起きたことで書きます。ブログ運用の自動化ツールを AI と一緒に作っていて、そこで出た失敗をそのまま並べます。

先に結論を書いておきます

• デバッグに時間を取られるのは本当です。ただし時間が消えるのはコードの中ではありませんでした
• 消えるのは「言った通りに出てきたか」を確かめる工程です。コードは動く。動くのに、頼んだものとは違う
• 初心者とプロで評価が割れるのは、見ている場所が違うからです。初心者は「動いた」で終わり、プロはその先を見ます。その先に時間があります
• 対策の軸はひとつです。コードレビューを徹底して繰り返させること。一度で終わらせないことが要点でした

実際に起きた 7 つ

種類別に並べます。どれも一度きりではなく、形を変えて繰り返し起きたものだけを載せています。

種類	何が起きるか
① 実在しないものを、あるものとして書く	それらしい名前の関数・オプション・画面経路が出てくる
② 確認せずに「できています」と判定する	間接的な情報だけで結論を出す
③ 指示していない範囲まで直す	頼んだ場所以外が変わっている
④ 直した結果を反映せずに完了と言う	直したのに、こちらの画面は前のまま
⑤ 制約違反を自分では止められない	決めた上限を超えても、エラーも警告も出ない
⑥ 指摘されると、修正ではなく説明が返る	直してほしいのに、経緯の説明が返ってくる
⑦ 自分で調べられることを、こちらに聞いてくる	調べる手段を持っている側が、持っていない側に振る

① 実在しないものを、あるものとして書く

起きたこと。実在しないプロパティ名を使った手順が出てきて、2 回続けて失敗しました。存在しないコマンドラインオプションを前提にした指示も出ました。管理画面については、実際には無いメニュー経路を案内されました。

どれも形は完全に正しく見えます。他のオプションと同じ書き方で、同じ雰囲気の名前がついています。実行して初めて違うと分かります。

止め方。「推測で書かず、実際のファイルを開いて確認してから書く」を守らせます。そのうえで、名前が答えに出てきたら、根拠にしたファイルと行番号を一緒に出させます。出せないなら確認していないということです。この一手間で、実在しない名前はほぼ消えました。

② 確認せずに「できています」と判定する

起きたこと。処理ログの出力順だけを見て「正しく分かれています」と判定されました。実際の表示位置は違っていました。ログは処理の順番を示すだけで、結果がどう並んだかは示しません。

止め方。報告のたびに「何を見てそう判定したか」を書かせます。ログや実行結果のメッセージは根拠になりません。根拠になるのは成果物そのものです。画面なら画面、ファイルならファイルの中身です。

③ 指示していない範囲まで直す

起きたこと。「A をこの位置に移してほしい」と頼んだところ、B の配置まで変わっていました。元に戻すのに何往復もかかりました。良くしようとした結果なのですが、頼んでいません。

止め方。「指示したこと以外は修正しない」を規則にします。そのうえで修正は変更前と変更後を並べた形で受け取ります。差分が目で見えれば、範囲外の変更はその場で分かります。改善案があるときは直さずに言葉だけで出させます。

④ 直した結果を反映せずに完了と言う

起きたこと。コードは直っていました。しかし反映作業をしていない状態で「直りました」と報告され、こちらの画面は前のままでした。直した側は、コードを書き換えた時点で終わったつもりでいます。

止め方。完了報告に検証結果を必ず付けさせます。「直しました」ではなく「直して実行して、こうなりました」です。反映が必要な作業では、反映までが作業だと最初に決めておきます。

⑤ 制約違反を自分では止められない

起きたこと。掲載する広告の上限を決めていたのに、その倍以上が入りました。原因は、同じものが 2 つの経路から取得されて二重に並んだことです。スクリプトはエラーも警告も出さずに正常終了しました。

ここが一番危ないところでした。止まってくれれば気づけます。止まらないものは、目で見つけるまで残ります。

止め方。制約を文書ではなくコードに入れて機械に止めさせます。人の規則にしておくと毎回すり抜けます。実際に、上限を超えたら処理を中断するように直しました。同じ理由で、指定したものが結果に入らなかったときに警告を出すようにもしています。黙って消えるのが一番たちが悪いからです。

⑥ 指摘されると、修正ではなく説明が返る

起きたこと。間違いを指摘すると、修正版ではなく「なぜそうなったか」の説明が返ってきます。結論が出た後になって、反対意見がもう一度出てくることもあります。こちらが欲しいのは直ったものです。

止め方。「異論は指示が出る前に一度だけ。指示が確定したら従う」を規則にします。指摘への回答は説明ではなく修正版で受け取ります。説明が必要なら、修正版を出した後に付ければ済みます。

⑦ 自分で調べられることを、こちらに聞いてくる

起きたこと。不具合の原因調査を「確認してください」とこちらに振られました。ファイルを読む手段を持っているのは向こうです。持っている側が、持っていない側に投げています。

止め方。「自分で確認できることは聞かない」を規則にして、聞いてよい範囲を限定します。人にしか分からないこと、つまり画面にどう表示されているか、アカウントがどういう状態か、管理画面で何が見えているか。ここだけです。

7 つを貫いているもの

並べてみると、共通しているのは「コードが間違っている」ではないという点です。動きます。動くのに、頼んだものとは違う。だからコードを読んでも見つかりません。デバッグに時間が取られるというのは、この探し方の難しさのことでした。

対策として効いたのは 3 つです。

• 規則を文書に書いて、毎回それと突き合わせさせる。頭の中にある規則は守られません
• 違反が出たら、その場で規則を増やす。同じ失敗が繰り返されるのは、規則が無いということです
• 人の規則で守れないものは、コードで止める。上限や形式のように機械が判定できるものは、機械に任せます

そしてコードレビューを一度で終わらせないことです。直した後にもう一度見せる。この往復を省くと、直したつもりのものがそのまま通ります。

指示するのではなく、規則を積む

ここからが実際の運用方法です。上の 3 つは、そのつど言っていては続きません。言うのは一度きりですが、規則は残ります。

規則はチャット欄ではなくファイルに置く

会話の中で決めたことは、その会話が終われば消えます。次に開いたときには、決める前の状態から始まります。だから決まったことはファイルに書きます。

置き場所はプロジェクトの中で構いません。要点は、作業を始める前に必ず読ませることです。読ませない置き場所は、置いていないのと同じです。

書くのは 3 種類だけ

何でも書き込むと、肝心の規則が埋もれます。載せるものを絞ります。

• 今どうなっているか（今の構成、決まっていること、未確定のこと）
• 守るべき規則（やること・やらないこと）
• 繰り返した失敗と、その止め方

「何をやったか」は書きません。作業履歴はバージョン管理が持っています。ここに書くと分量だけが増えて、規則が読まれなくなります。

失敗が出たその場で書く

後でまとめて整理しようとすると、細部が落ちます。落ちた細部が、次に同じ失敗を呼びます。その場で一行足すだけで済みます。

書き方は、起きたことをそのまま書くだけで十分です。実際に使っている形はこういう調子のものです。

• 指示していない箇所は修正しない
• サンプルコード・その場しのぎの固定値を使わない
• 回避策を規則に格上げしない。回避が要るならコードを直す
• 確認できていないことは、確認できていないと書く

どれも、実際にその失敗が起きた後に足された行です。最初から思いついて書いたものはひとつもありません。

優先順位を先に決めておく

規則が増えると、規則どうしがぶつかります。文書に書いてあることと、実際のコードの状態が食い違うこともあります。そのときにどちらを取るかを、あらかじめ書いておきます。

順序は「こちらの指示 → 実際のコードや画面の状態 → 文書」です。文書が一番下なのは、文書のほうが古くなるからです。この一行が無いと、古い記述を根拠に押し切られます。

規則の量がそのまま資産になる

この文書は最初から用意していたものではありません。失敗がひとつ出るたびに、行がひとつ増えてきたものです。今ある行数が、そのまま起きた失敗の数になっています。

そして増えるほど手戻りが減ります。同じ失敗を二度説明しなくてよくなるからです。指示は毎回消えますが、規則は積み上がります。ここが、この作業で唯一積み上がる部分でした。

それでも AI に書かせるのか

書かせています。ここまで挙げた 7 つは、止め方が分かっているものだからです。止め方が分かっている失敗は、コストとして計算できます。

初心者とプロで評価が割れる理由も、ここに戻ってきます。レビューの往復と、規則を積む仕組みを持っているかどうかの差です。持たずに使えば「動いたのに違うもの」が積み上がり、持って使えば速さだけが残ります。同じ道具で結果が逆になります。

なお、そもそも自分で書けるようになる必要があるのかという問いについては、別の記事で実際に動かして確かめています。

この記事について

この記事は随時更新します。新しい事例が出るたびに種類を追加し、更新日を改めます。ここに載せているのはすべて、実際に自分たちの開発で起きたものだけです。運用しているツールの構成そのものは対象外とし、他でも使える形にしてから載せています。

初回公開 2026 年 8 月 10 日。