7
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AIを使って書いたコードの品質を保つ方法と、コードに対する責任について考えてみた

Last updated at Posted at 2025-12-12

AIの進化の速さには、本当に日々驚かされます。
エンジニアとしての自分は「着いていくのがやっと」で、もっと言えば「置き去りにされないのが精一杯」と思わされるほど。

そんな状況下で、今年ずっと考えていた問題である
「コードの品質を保つ方法と、コードに対する責任」についてのお話になります。
ややポエム気味ですがお付き合いください。

前置き

私は業務のコーディングで主にGitHub Copilotを使用しており
「AIがIssueを読んで実装・テスト・コミット・Pull Request作成まで全部やってくれる」みたいな世界は体験していません。
このような視点からの所感を綴っている、という事だけご了承ください。

きっかけ

数カ月前のある日、「こういうWebページさくっと作れないかな」と思い立ち、お試しがてらGemini CLIで作ってみることにしました。

  • ざっくりした仕様を考えてGemini CLIに伝え
  • 使用するフレームワークなどを相談しながら決定し
  • 少し待つ
  • 出来上がったページを確認、修正があれば追加依頼

たったこれだけでページが完成する、すごい...!とニマニマしていたのですが
出力されたコードが何をしているか、全然分からないという事に気付きました。

このWebページでは TypeScript / SvelteKit / Vite などを使っていたのですが、私はTypeScriptを業務で書いた経験はなく、SvelteKitに至っては名前も知りませんでした。

つまるところ
Webページを作ったが、それを実装するコードは読むこともおぼつかない
という状態だったわけです。
ここまで来ると、「作った」と言って良いものか...

課題

AIにより、コーディングの速度を上げることは容易になりました。また「自分の能力を超えたコード」もアウトプットしやすくなっています。
しかし、増えたコード生産量にレビューが追いつかない・自分の能力を超えたコードは評価が難しいという課題があります。

AIによるコーディングは、人間ではありえない速度と物量での生産が可能ですが、業務では「AIが出してきたコードをノーチェックでそのままリリース」とは行きません。

となれば「人間によるコードレビュー」がボトルネックになりますし、
人間によるコードレビューの速度・質 = 最終的なアウトプットの速度・質という図式になります。

強い力を出せるようになっても、コントロールできなければ「使える」とは言えないわけです。何だか漫画みたい。

対策

では、どうやってコードの品質を担保するのか?というのが今回の主題です。
以下は仕事を通しての私の考えであったり、まだ試していないアイデアであったりします。

出力は小さく

チーム内でのレビューで、Pull Requestを細かく出すのと同様に
AIが一度に出力するコードの量が膨大にならないよう、作業範囲を調整して指示を出す
というのが、最初に思いつく対策です。

一度に大量のコードをレビューするのは負荷が高く、速度・品質どちらにも悪影響を及ぼすため、まずはレビューの負荷を下げるのが良いと思います。

その点、AIによるエディタでのコード補完は
「最も小さな出力とレビューのサイクル」だと感じます。

段階的にレビューする

次に設計レビューのような途中段階でのチェックを設けるということです。
完成品をまとめてレビューするのは負荷が高いので、方針が問題ないかを段階的に都度チェックするのが良いと思います。

昨今のCopilotにおけるPlanモードがあるように
計画段階で細かくチェックすることで、実装時のブレを減らす事ができると思います。

Planを作成させてチェック、インターフェースだけ実装させてチェック、実際の中身を実装させてチェック、といった段階を踏むのも有効でしょう。

分からないことをなくす

上記のような細分化をした上で、分からない所があれば調べたりAIに聞いたりして
コードの意図や狙いを理解する、ということが重要です。

そこまでやってようやく、コードが適切かどうかを判断できる段階に立てると思います。

テスト駆動で開発させる

AIにテスト駆動で開発させ、あらかじめテストをレビューしてから実装させることで
ふるまいについてのチェックはテストが担保してくれるので、他の部分のレビューに集中できます。
ケースバイケースですが、ハマれば有効な手法の1つだと思います。

複数AIでの確認

私はAIを使った技術的な確認やレビューを行う際、ChatGPTとGeminiに同じ依頼をすることが多いです。

複数の手段で検証することで

  • それぞれ別の問題を指摘してくれる
  • 1つの問題に対して複数の視点からの評価を得られる

というメリットがあります。
また2つのAIで意見が食い違っていれば、人の目で検証するきっかけにもなります。

根拠を求める

これも「分からないまま使わない」ということの一環ですが、AIから情報を得る際に

  • Webサイトなどが根拠なら、そのリンクを求める
  • コードなどで検証可能なら、テストコードなどサンプルの提示を求める

など「検証によりAIの発言の裏を取ること」の重要性を、改めて感じています。

コードによって裏を取ることができる、というのは
コーディング特有のハルシネーション対策かもしれません。

おわりに & "責任"の話

最後に少しだけ、私見を交えつつ心構えの話をば。

AIが出力したコードを採用する中で

知らず知らずのうちに、コードに対する責任感が薄れている

という人も多いのではないでしょうか。

かくいう私もその1人なのですが、例えコードを書いたのが人でもAIでも
リリースするのが人であることは(当面)変わらないと思います。
gitの履歴にはその人が書いたコードとして残りますし、そのコードの責任は人が負わねばなりません。

だからこそ、AIが出力したコードを「自分が書いた」と言えるレベルで理解・評価してから採用することが重要ということを、日々噛み締めています。

これまた私見ですが、AIが進化するにつれ「AIの出力を批判的に評価する目が緩んでいる」という自覚があります。
技術の進化は喜ばしい事ですが、過度に寄りかからないよう気を引き締めなければ。

そんな自戒も込めて、2025年の振り返りとして
1年間仕事をしながら考えてきたことを書き綴りました。

7
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
7
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?