00:00
こんにちは。現場のAI業務改善ラジオの大地です。 今日は、コードの汚れはAIじゃなくて機械的に見張るというテーマでお話しします。
Cloud CodeやCodeXのようなAIエージェントを使えば、プログラミングの知識がなくても、業務ツールやウェブサイトが作れます。
最近のAIは賢いので、AIが書いたコードは大体一発でちゃんと動きます。 でも、AIにコーディングを続けさせると、裏でコードが少しずつ汚れていき、だんだん精度が落ちて、無駄なコストも増えていきます。
動けば問題ない。そう思っていると、AIが書くコードはどんどん劣化していきます。 これから、このコードの汚れの内容と対策について詳しく解説します。
まず、AIの開発にありがちなコードの汚れは次の3つです。 どこからも使われない処理が残っている。ほとんど同じ内容のコードが複数の箇所に重複している。
機能によって書き方がバラバラ。 AIが修正を重ねるたび、不要になったコードの消し忘れや、似たコードの作り直しが増えていきます。
人がコードを読まないAI開発では、この汚れに気づけません。 ここからは、この汚れがAIにどう響くかについてです。
コードの汚れは、AIの精度低下とコスト浪費に直結します。 AIはコードを書くとき、既存のコードを手本にします。
既存コードに重複や書き方のばらつきがあると、AIはどれが正解か判断できず、答えるたびに違う書き方を選びやすくなります。
会社の共有フォルダを思い浮かべてみてください。 企画書最終版、企画書最終版その2、企画書本当の最終版、会社でも似たような名前のファイルが量産されるのはあるあるです。
新しく入った人がこのフォルダを見たら、どれが本物かわかりません。 うっかり古い方の最終版をコピーして、仕事を進めてしまう。
AIも同じことをやります。 やりたいことは同じなのに、いろんなところに違う書き方のコードが散らばっている。
その中からAIが選んだ手本が、実はもう使われていない古いコードかもしれません。
同じ理屈で、汚れたコードはトークンの浪費にもつながります。 トークンというのは、AIが情報を読み書きする最小単位のことです。
1トークンで1単語ぐらいのイメージだと思ってください。 汚れたコードによってAIが読むコード量が増えるほど、トークン、つまりコストを消費します。
さらに、正解がわからないコードでは、どれが正しい書き方かの検討も必要になるので、その判断でも余計にトークンを使います。
じゃあ、この汚れ、どう防ぐのがいいと思いますか?
パッと思いつくのは、AIに指示することです。
未使用のコードは残さないで、同じ処理のコードは重複させないで、
コードは既存の箇所と書き方を統一して、こんな感じでAIに指示しておけば、ある程度は守ってくれます。
でも、依頼された開発を行なしながらコードをきれいに保つ指示も守り続けるのは、AIでもしんどいです。
一箇所コードを直すごとに、未使用コードが生まれていないか、既存のコードをちゃんと活用しているか、
他の書き方と整合性が取れているか、こんなことを常にチェックしていたらミスもするし、トークンも漏弾します。
そこでベストなコードの汚れ対策が、リンターとフォーマッターです。
ここからは、この2つがどうコードの汚れを防ぐかをお話しします。
03:01
コードの汚れは、AIじゃなくて機械的に見張る。
これが今日一番伝えたいポイントです。
コードを自動検査するツールであるリンターとフォーマッターは、早くて正確です。
検査をAIがやるわけじゃないので、トークンも消費しません。
リンターは、コードを解析して問題を指摘するツールです。
いわば工場の検品係だと思ってください。
LINEを流れてきた製品が企画通りかチェックして不良品をはじく係の人がいますよね。
あれのコード版です。
リンターは、使われていない処理やコードの重複、複雑すぎる書き方、決まりに反する書き方などをルールに基づいて機械的に指摘します。
一方で、フォーマッターは清書係です。
コードの空白スペースの数や、シングルクオート、ダブルクオートのどちらを使うのか、などのコードの見た目を決めたルール通りに自動で揃えてくれます。
ここから、僕のサイトのリンターとフォーマッターの使い方を解説します。
まず、リンターは役割の違う3つを使い分けています。
1つ目はESLint。関数の長さや複雑さ、デザインルールへの違反などを幅広く検出します。
関数というのは処理のまとまりのことです。
例えば、1つの関数は50行までというルールで見張っています。
2つ目はJSCPD。
5行以上続く重複コードを検出します。
最後はNIP。
使われていないファイルや処理、外部ツールを検出します。
このほか、データベースの言語であるSQL用に
リンターとフォーマッターを兼ねるSQL Fluffというツールも使っています。
フォーマッターはPretierを使っています。
保存のたびにコードの書き方を自動で揃えてくれます。
一方で、リンターとフォーマッターを揃えても
AIが実行を忘れたら意味がありません。
そこで、Left Hookというツールでコード修正を保存するたびに
リンターとフォーマッターを自動実行する設定をしています。
ここでの保存は履歴管理ツールGitのコミット操作のことです。
Gitの解説をした回は概要欄にリンクを貼っています。
気になる方はそちらも聞いてみてください。
話を戻すと、検品に通らない製品は絶対に出荷させません。
そういうゲートをコードの置き場の入り口に付けているようなイメージです。
違反が一つでも残っていると修正をコミットできません。
AIがルール違反のコードを書くとコミットのタイミングで指摘されて
AI自身が直してから先へ進みます。
フォーマッターによる修正も同じ流れです。
人がコードをチェックしなくても
AIによるコードの汚れを自動でガードする仕組みになっています。
最後にリンターとフォーマッターの導入についてです。
ここまで聞いて設定が難しそうだと感じたかもしれません。
安心してください。導入も設定もAI任せでOKです。
まずはどのリンターとフォーマッターを使うかです。
CodeXやクロードコードなどのAIエージェントで
開発中のホルダーを開いて次の指示を送ってみてください。
このプロジェクトに最適なリンターとフォーマッターを
導入実績やメンテナンス状況も踏まえて検討して
こう頼むと、AIがプロジェクトの内容に合わせて
候補と選んだ理由を提案してくれます。
確認するのは自分のプロジェクトに合っているか
多くのプロジェクトに導入実績があるか
継続的にメンテナンスされているか、この3点です。
06:00
AIの提案を基にリンターとフォーマッターを導入したら
次にこう指示してください。
Left Hookでコミット前にリンターとフォーマッターを実行するようにして
これでコミットの度に自動チェックが実行されます。
ただし、既に動いているプロジェクトへの導入には注意点があります。
既存コード全体が検査されて
大量の違反が見つかることです。
一度に直そうとすると変更が大きくなりすぎて
確認が大変になったりバグが紛れ込んだりするかもしれません。
そこでこう頼んでください。
ESLintを導入して既存コードの違反を一度に直さず
段階的に解消する導入計画を先に作って
ESLintのところは導入するリンターの名前に置き換えてください。
あとは計画に沿って少しずつ違反を解消させればOKです。
まとめると
AIの開発では、動いていてもコードは少しずつ汚れていき
その汚れがAIの判断を鈍らせ
精度を落とし、トークンも浪費させます。
だからこそ、コードの汚れはAIじゃなくて機械的に見張る。
これが重要です。
リンターとフォーマッターをLeft Hookでコミット時に自動実行すれば
検査に通らないと保存できない仕組みの出来上がりです。
導入と設定はAIに任せてOKですが
既存プロジェクトへの導入は
リンターの違反を段階的に直す計画を先に作らせてください。
まずはツールやアプリを開発しているフォルダを一つ選び
このプロジェクトに最適なリンターとフォーマッターを
導入実績やメンテナンス状況も踏まえて検討して
とAIに投げてみてください。
開発が進めば進むほど
リンターとフォーマッターがAIの精度低下とコストの浪費を防いでくれます。
概要欄に今回の内容を解説した記事を貼っておきます。
興味があれば見てみてください。
質問やご意見、取り上げてほしいテーマがあれば
ぜひコメントお願いします。
それでは今日はこの辺で。
