はじめに
初めまして、こんにちは。
この記事を見ていただきありがとうございます。
最近、自分のコードが「AIに頼りすぎている、ただの丸投げである」とご指摘を頂く機会がありました。
上記の書き方でわかる通り、正直ほぼ自覚がないです。
確かにAIに「これこれこういう処理を書いて」などそれっぽく出力させてはいますが、結局は自分で手直しをしてこれでいいでしょって認識でした。
では、自分で書いたコードとAIに丸投げしたコードの境界線はどこにあるのでしょうか。
本記事では、その境界線を自分なりに言語化していきます。
なぜそれが“AIっぽい”と感じるのか
AIで単発生成したコードには、いくつか共通した特徴があります。
- 過剰に丁寧なコメント
- 汎用的すぎる変数名
- 教科書的な実装
- 局所最適なコード
これら自体が悪いわけではありません。
しかし、生成結果を十分に咀嚼せずそのまま採用すると、次のような問題が起きやすいと感じています。
- 要件のニュアンスが抜け落ちる
- エラー発生時の意図が読み取りづらい
- 既存コードの設計思想と噛み合わない
つまり、「書かれたコード」ではあるものの、「考え抜かれたコード」に見えない。
その違和感が「AIっぽさ」として認識されるのではないでしょうか。
要因として考えられること
まず自覚がないとはいえど、これまでの成果物を見て要因として気づいた点をまとめてみました。
-
処理によってコードの書き方が違う
- ファイルごとに、処理の流れの設計思想が違う
- 責務分割の粒度が一定しない
- 例外処理の書き方や命名規則がバラバラ
-
コメントアウトの内容が冗長
- 過剰に丁寧なコメント
- 教科書っぽい言い回し
-
「こういう依頼なのでこう書いた」みたいなやりとりがない
- 設計意図が履歴に残らない
- なぜその実装を選んだかが見えない
正直なところ、いくつか理由は思い当たります。
ですが、まずは事実として整理し、この3点を構造的に捉え直してみます。
要因の掘り下げ
処理によってコードの書き方が違う
まず現象として以下が挙げられます。
- ファイルごとに、処理の流れの設計思想が違う
- 責務分割の粒度が一定しない
- 例外処理の書き方や命名規則がバラバラ
深掘りしていくと、以下問いがありました。
- なぜ一貫性がないのか？
- 設計を先に決めていないのでは？
- AIの出力単位が“局所最適”だからでは？
振り返ると、設計を言語化せずに都度実装していたことが大きいと感じています。
AIに処理単位で質問し、その都度最適そうなコードを出力してもらう。
その積み重ねが、結果としてファイルごとの思想の違いを生んでいました。
AIの出力はその場では正しく見えます。
しかし、それはあくまで局所的に整った解です。
局所的には整っていても、全体としての設計思想が一貫しているとは限りません。
プロジェクト全体の設計を自分の言葉で説明できない。
そこに、自分のコードかどうかの「境界線」があるのではないかと考えました。
コメントアウトの内容が冗長
まず現象として以下が挙げられます。
- 過剰に丁寧なコメント
- 教科書っぽい言い回し
深掘りしていくと、ひとつの疑問に行き着きました。
- このコメントは、誰のために書かれているのか？
振り返ると、それはレビューする人のためでもなく、将来の自分のためでもありませんでした。
それは、AIに質問し、その出力を理解しようとする「その場の自分」に向けた説明だったのではないかと思います。
本来コメントは「設計意図」や「制約条件」を残すもののはずです。
しかし、出力されたコードの説明をそのまま残すだけでは、自分の思考を反映したコメントとは言えません。
つまり、コメントが冗長なのではなく、思考の整理をコード上にそのまま残してしまっていたのです。
ここにもまた、「自分で咀嚼したコードかどうか」という境界線があるように感じました。
「こういう依頼なのでこう書いた」みたいなやりとりがない
まず現象として以下が挙げられます。
- 設計意図が履歴に残らない
- なぜその実装を選んだかが見えない
深掘りしていくと、ひとつの疑問に行き着きました。
- 設計の意思決定は、どこに記録されているのか？
振り返ると、設計意図を残す手段がなかったわけではありません。
今のプロジェクトではbacklogでGit管理をしており、マージ時には説明欄もあります。
しかし、その欄は形式的に記載するだけで、「なぜこの設計にしたのか」までは書いていませんでした。
手段の問題ではなく、意思決定を言語化し、残す習慣がなかったことにあります。
それが本質だったのだと思います。
AIに頼って書いても、動けば問題ない。
レビューが発生しなければ、説明しなくても通ってしまう。
この状態が続けば、設計の背景はどこにも残りません。
生成したかどうかではなく、意思決定を説明できる形で残しているか。
そこに、「丸投げ」と「自力」の境界線があると感じました。
要因に対しての対策
処理によってコードの書き方が違う
結論として、設計を言語化せずに実装していたことが原因でした。
そのため、以下を実践します。
- 実装前に「責務」と「データの流れ」を手短に（約３行で）で書く
- 命名規則を固定する（プロジェクト内ルールを決める）
- PRに「設計意図」を必ず1段落書く
- AI出力をそのまま使わず、既存構造に合わせて再設計する
コメントアウトの内容が冗長
結論として、思考の整理をコード上にそのまま残してしまっていたことが原因でした。
そのため、以下を実践します。
- コメントは「なぜこの実装にしたのか」だけを書く
- 「何をしているか」の説明は削除する
- AI出力直後のコメントは一度消し、自分の言葉で書き直す
「こういう依頼なのでこう書いた」みたいなやりとりがない
結論として、意思決定を言語化し、残す習慣がなかったことが原因でした。
そのため、以下を実践します。
- マージ説明欄に「目的」と「採用理由」を必ず書く
- 別案があれば1行でも記録する
- 実装後、自分で「この設計を説明できるか」を確認する
まとめ
ここまで、要因の特定と深掘り、そして対策を書いてきました。
振り返ると、自覚がなかったことに正直怖さを感じています。
もちろんAIを使うこと自体は決して悪いことではありません。
実際、ChatGPTやCursorを通して多くのことを学びましたし、全く無駄ではありませんでした。
しかし、気づいたのは、自分はAIを使っていたのではなく、AIに全信頼を置いて頼りきっていた場面もあったということです。
問題は生成したかどうかではなく、その実装を自分の言葉で説明できるかどうか。
今回の整理を通して、AIは「正解を出す存在」ではなく、「思考を補助する存在」であるべきだと気づきました。
そして、自分で書いたコードかどうかの境界線は、意思決定を説明できる状態にあるかどうかにあるのだと思います。
今後は、AIを主役にするのではなく、自分の思考を主役にし、その補助として使っていきたいと思います。
AI時代における「自分で書く」とは何か。
その問いを、これからも考え続けたいと思います。
ありがとうございました。