AIが生成したコードにありがちな保守性の低さや、不要なコードの放置、重複コードの多発といった問題を解決するための無料のコマンドラインツールについて解説する。このツールはデッドコードや重複部分の特定、コードの複雑さの計測、リファクタリングの対象箇所の提示などを行う。手動でコーディングしたプロジェクトからAIを活用したバイブコーディングのプロジェクトまで幅広く適用でき、AIエージェントに組み込んでの自動修正や、CI/CDパイプラインへの統合による品質保証の方法も包括的に紹介する。
AIによるコーディングの課題とツールの概要
AIの大きな問題点の1つは保守性の低いコードを書きがちなことです。よくある例として全く同じコードを複数の異なる場所に複製してしまうことが挙げられます。コードが完全に同一であるにもかかわらず同じファイルの2つの異なる場所に存在していたりします。このような事態は至る所で発生します。異なる場所で大量の同一コードが生成されているのを目にすることもあるでしょう。さらにAIは巨大なファイルを作成するのも大好きです。ファイルが数百行にも及びその中の関数が非常に複雑で何が起きているのかを読み解くのが困難になることもあります。これに加えてコードの動作を変更した際にファイル全体が全く使われなくなるのもよくあることです。AIが古いコードを残したままにしたり様々な用途のために多数のエクスポートを作成したりするからです。しかしこれらのコードが実際にエクスポートされたり他で使われたりすることは決してありません。その結果として大量のデッドコードや重複コードそして読みにくいコードが残されてしまいます。問題なのはAIがこれらの問題を見つけて解決するのが非常に苦手だということです。だからこそこのツールが絶対的に素晴らしいのです。これは完全に無料のコマンドラインツールでESLintと非常に似た働きをしますがエージェントが特定の問題を修正するのを支援できるような形で構築されておりAIコーディング特有の問題を解決するために作られています。しかしAIプロジェクト以外でも役立ちます。完全に手作業でコーディングしたプロジェクトと完全にバイブコーディングで作られたプロジェクトの両方での使い方をお見せします。両方のシナリオで使用するメリットとデメリットを確認しご自身が使用しているあらゆるエージェントのワークフローにこれがいかに完璧にフィットするかをご覧いただけます。
ツールの導入と基本的な静的解析機能
WebDev Simplifiedへお帰りなさい。私の名前はカイルでウェブをシンプルに伝えるのが仕事です。さっそく始めていきましょう。プロジェクト内で使用するためにはnpx fallowを実行するだけです。これでこのツールができることの基本的な全体像が把握できます。その後で少し調整を加えたアプローチで設定して使用する方法をお見せします。ここでお気づきかもしれませんが私たちが焦点を当てているのは静的なインテリジェンスです。正直なところこれがこのツールについて私が最も重要だと考えている部分であり完全に無料です。もしランタイム関連のインテリジェンスが欲しい場合はオプションで支払うこともできますが主に得られるのはこの静的なインテリジェンスになります。繰り返しますがこれが完全に無料であることは本当に素晴らしいです。これはスポンサー動画などではなく私が純粋に超便利なツールだと思っているだけです。さて完全にバイブコーディングされたこのプロジェクトの中に入りエージェントベースのワークフローでどのように見えるかをお見せしましょう。npx fallowと入力してインストールしたいと伝えるだけで処理が実行され実際にたくさんの情報を提供してくれます。実行結果の一番上までスクロールすると大量の情報が表示されておりこのセクション内のすべてが何を行っているのかを大まかに説明します。まず非常に便利だと思うのはプラグインを自動的に検出してくれる点です。これは基本的にはViteやNext.jsやTanStackなど非常によく使われる様々なフレームワークや言語を使用している場合それらのプラグインを検出し使用しているプラグインに基づいて事前設定を自動的にセットアップしようとすることを意味します。これはViteとTanStackのプロジェクトでTailwindなども使用しているためそれらすべての異なるプラグインが用意されます。次に見えるのはデッドコードなどに関する基本的な指標です。しかし本当に重要なのはこれより下にあるすべてのものです。デッドコードに関するセクション全体があり一度も使われていない様々なファイルについて書かれているのがわかります。例えばいくつかのshadcnのコンポーネントがあり以前はアプリケーションに存在していましたが削除された機能のファイル全体がここにあります。しかしコードの一部が取り残されてしまったようです。繰り返しますがAIにはこれが非常によくあります。未使用のエクスポートも確認できます。これは例えばこの特定のファイルに入りエクスポートが存在する下のセクションの特定の場所までスクロールするとこのextract all audioという関数をエクスポートしていると指摘されているような状況です。実際にそれを検索してみましょう。これにはexportがついていますがこのコードをどこかにインポートしているわけではありません。したがって本来は全くエクスポートされるべきではありません。これはエクスポートされがちなコードの素晴らしい例です。AIにはこのようなことが非常によくありますがエクスポートされたままにするべきではありません。ここを見て回りそういった特定の問題をすべて修正することができます。そしてこれも独自の修正コマンドを持っています。このように単にfixを実行するだけで比較的簡単に修正できるものの一部を自動修正してくれます。ここでも同じです。エクスポートされているのに使われていない型がある場合はそれらについて教えてくれます。例えば未使用の依存関係がある場合このリストの中に表示されているのがわかります。依存関係の中にはテストのためだけに使っているものもあるかもしれません。それらを特定して本番環境から移動させることができます。つまりこれは自分が使っていないコードはどれかを確認するための本当に素晴らしい方法なのです。これがデッドコードのセクション全体が役立つ理由です。
コードの重複と複雑さの診断
次のセクションは重複です。私はこれが最も重要なセクションだと思っています。これはプロジェクト内で重複したコードがある場所をすべて教えてくれます。すべてが表示されているわけではなくごく一部しか表示されていませんがこの特定のセクションに移動するためにクリックしてみるとこのセクション内のコードがここの下のセクションにあるコードと実質的に重複していることがわかります。両方とも全く同じコードです。そしてどの行かまで正確に教えてくれます。ここを見るとこれらがまさに重複している行です。約100行の重複コードがあります。これが重複セクションの機能です。もう少し先に進むとクローンファミリーに関するものが見えますがこれも基本的には重複に関するものです。そして複雑さのセクションにたどり着きますがこれはアプリケーションの健康診断セクションのようなものです。ここでは様々なものがどれくらい理解しにくいかを判定します。例えばここでは非常に規模の大きいすべての関数を表示しています。1500行近い関数があるのがわかりますね。こちらは450行でこちらは350行です。これほど長ければ間違いなく悪い関数と言えます。ですからこれは明らかに私たちがクリーンアップしてはるかに作業しやすくしたいコードです。これによって自分の最大の関数がどこにあるのかという良い大まかな場所がわかります。高い複雑さを持つ関数に関するこのセクションも確認できます。最初は非常に複雑に見えるかもしれませんが基本的には関数があなたにとってどれくらい読み解きにくいかそしてテストするのがどれくらい難しいかを判定しています。サイクロマティック関数複雑度とはコード内にどれだけ多くの異なる分岐があるかを意味します。if文や三項演算子やswitch文があるたびにそれらはコードの異なる分岐となりそれらがある場所一つ一つがこのサイクロマティック複雑度に追加されます。この一つの関数に115の分岐があるのがわかりますね。これはとてつもない数です。次に認知的負荷がありこれは133という値を持っています。これはコードがどれくらい読みにくいかという指標です。例えばネストされたif文やネストされたループなどがあるとパースして理解するのが非常に難しくなることがあります。そのように読みにくいネストされた構造があるとこのスコアが上昇します。そして最後にcrapスコアというものがあります。このスコアは関数がどれくらい複雑かだけでなくそれがどれくらいテストされているかを基本的には計算します。例えば非常に複雑な関数でもテストが多数あればこのcrapスコアはそれほど高くなりません。しかしテストが全くない関数の場合はこのcrapスコアが劇的に上昇します。ですから自分の複雑なコードが適切にテストされているかあるいはある程度複雑なコードがテストされていないのではないかを判断する素晴らしい方法になります。それらがここに表示されフラグが立てられます。次にそれらをすべてスクロールしていくとこの中に非常に複雑な関数が本当にたくさんあるのがわかります。どんどん進めていきましょう。ようやくこのファイル健康度スコアのセクションにたどり着きました。これがどのように計算されるかというとコードがどれくらい複雑かだけでなく全く使われていないデッドコードがどれくらいあるかそしてどれくらい多くの異なるコードの場所がインポートされエクスポートされているかを判定します。例えばどれくらい多くの異なるファイルがこのコードをインポートしているかそしてこのコードがどれくらい多くの異なるファイルをインポートしているかといったことです。これが基本的にファイルの健康度を決定しここにあるリスクと関連づけるのにも役立ちます。そのリスクとはまさに先ほどのcrapスコアのことです。それらのすべての情報や関数の大きさなどを総合してこのスコアが決定されます。当然ですが数字が大きいほど良い状態です。ここを見るとこれが最もスコアの低いセクションです。それは主にこのコードが100パーセント死んでいるからです。しかしメンテナンスが非常に困難または複雑な他のコードもいくつか見受けられます。基本的にはこれはコードのメンテナンスがどれくらい簡単かを判定しているだけです。スコアが低いほど様々な理由でコードのメンテナンスが難しくなります。
ホットスポットとリファクタリング対象の特定
最後に一番下にこのホットスポットのセクションがあります。これはコード内のどこが最も頻繁に変更されており最も多くの潜在的な問題を引き起こす可能性があるかを基本的に教えてくれます。これはgitのコミット履歴とどのファイルが最も頻繁に変更されているかを考慮に入れます。ファイルが頻繁に変更されるほどこのセクションに現れる可能性が高くなりそのファイルが非常に複雑で作業が難しければこのセクションでもかなり上位にランク付けされます。ですからどのファイルが頻繁に変更されていてそのうちどのファイルが非常に複雑かを判断する簡単な方法になります。なぜなら常に変更される複雑なファイルがあればそれは明らかに大きな問題でありここで非常に高くランク付けされるからです。このカテゴリの数字が大きいほど状況は悪いと言えます。最後に私が本当に気に入っているのがリファクタリング対象です。これは最も簡単で最も大きな見返りを得られることに基づいてコードをリファクタリングするのに最適な場所はどこかを判定してくれます。ここを見るとこれらがデッドコードを削除したりより複雑な関数の複雑さを軽減したりすることでコードを変更するべきだと特定された場所です。これによって基本的に最もコストパフォーマンスの高い結果が得られます。このようにして評価してくれます。さて最後に一番下で全体的なスコアのようなものが得られます。素晴らしいのは例えば自分のデッドコードがどのような状態かあるいは健康度がどのような状態かを単に比較したい場合それが実に簡単だということです。npm fallowを実行しここに来てdead codeと指定すればデッドコードの部分だけを実行してくれます。これで使われていないものや適切に動作していないものだけが表示されているのがわかります。healthでも同じことができます。そうすると少し前に見ていたあの健康度の指標をすべて提供してくれます。判定したい様々な指標すべてに対してこれを行うことができますし各項目からどの指標が欲しいかを正確に絞り込むことすらでき非常に便利です。しかしこれはコマンドラインからツールを実行しているだけで全体像を把握するには素晴らしいのですがエディタ内でこれを見たい場合にはそれほど優れていません。ですから実際に手書きのウェブサイトで作業している場合や単にエディタ内でこれらのエラーを見たい場合でVS Codeを使用しているならインストールできる拡張機能があります。拡張機能タブに行って検索するとその会社が提供しているものがここに見つかります。それをクリックしてインストールするだけで拡張機能がインストールされコマンドを実行して得られるすべてのものを基本的に示してくれるこの小さなサイドバーが表示されます。しかもコード内の視覚的なインジケータ付きでサイドバーに表示してくれます。例えばどのファイルが使われていないかを確認したい場合はここに来ると上部にわかりやすい警告が表示されます。ファイルはいかなるエントリーポイントからも到達できないという内容です。要するにこのコードはどこからもインポートされていないということです。また例えばどのエクスポートが使われていないかも確認できます。ここに入ってみるとこの関数にはいかなるエクスポートもないことがわかります。使われていないことがわかりますね。ですからここからエクスポートのタグを単に削除することができます。保存すればその特定の問題は解決します。このようにすべての未使用コードやデッドコードのセクションがここの一番上に表示されます。そしてこのすべての下にある一番下の部分には重複のセクションがあります。ここをクリックしてさらにクリックするとこのコードに全く同じ重複セクションがあるのがわかります。こんな感じでここに表示されています。通常これらの繰り返されているセクションには何が起きているかわかりやすいように波線が引かれます。現在私はそれをミュートにしていますが検索して起きていることすべてをミュート解除したいとしましょう。検索するとすべての検出項目を表示しミュートをクリアするというものがあります。それをクリックすれば基本的にそのミュートが解除されます。これでそれらの異なるセクションに下線が引かれるようになりました。あちこちクリックすると重複したコードすべてに下線を引いてくれているのがわかります。これによってどのセクションが重複しているかが正確にわかり何が起きているのかを設定しやすくなります。
AIエージェントとの連携とCIへの統合
さて十中八九あなたは何らかのAIエージェントと一緒に使うことになるでしょう。そこで信じられないほど簡単なのでどのように設定できるかをお見せしたいと思います。素晴らしいのはこれにはスキルがありスキルをサポートしているあらゆるエージェントで利用できるということです。このスキルを使えるようにするにはnpx skills add ow-rs/fallow skillsと入力するだけです。エンターキーを押すとこのスキルのインストールプロセスが進みます。ダウンロードするまで少し待ちましょう。すべてデフォルトの設定を維持するのでエンターをクリックしてプロジェクトディレクトリにこれをインストールしはいインストールして構いませんと答えます。これでこのagentsフォルダを見るとこのskillsファイルがありこれら様々なスキルへの参照もあることがわかります。インストールされたスキルに関連する見たいものはすべて見ることができます。これで私たちのエージェントはそれら様々なスキルにアクセスできるようになりました。例えばエージェントを開きスラッシュfallowと言うだけでそのスキルを与えることができます。これによって私たちが望むfallowのスキルが得られます。これはかなり小さいのでズームインして実際に何が起きているかわかるようにこちら側に持ってきましょう。そして例えばどの5つのファイルを最初にリファクタリングする必要があるか教えてと言ってみます。そんな感じです。そうするとエージェントは私がこのプロジェクト内でやろうとしていることに実際にアクセスできfallowコマンドを実行してくれます。このコマンドの本当に素晴らしい点は少しズームレベルを元に戻しますがnpx fallowハイフンjsonと言えることです。こんな感じでこのフォーマットにしたいと伝えると実際にJSONフォーマットで返してくれます。これこそまさにこれらのAIが使用しているものです。すべてがJSONになっておりどのようなアクションが取れるかこの特定の問題をどうやって解決するかについてもう少し詳しい情報を提供してくれます。とりあえずこのコマンドの実行を許可しておきます。設定して実行するために必要なことをすべて進めて最終的に私が望む正確な結果を出してくれます。実行が完了するとそのレポートから直接得られた様々なことを含む結果を基本的には提供してくれました。これはある程度便利です。しかしこれをもっと便利に使う方法はAIに機能を実装するように指示することです。そして最後に自分が作成したコードに生じた問題を基本的に修正するために自身をレビューするためのツールを使用するように指示することができます。これはAIよこの機能を実装してくれそして作成したコードをチェックするために実行し私が設定したこれらのポリシーに違反していないか確認してくれと言える非常に簡単な方法です。うまくいけばある程度は自己修正してくれるはずです。もし修正しなかった場合でもこれをCIやCDの中で実行することでメインブランチにプッシュされ本番環境にデプロイされる前に自分のコードを確実にチェックさせることができます。それは使いたいほぼすべてのCIツールとの完全なCI統合が可能だからです。例えばこれをこっちに持ってきましょう。少し下の方を見るとGitHub Actionsではこのコードをコピーするだけでよいことがわかります。自動的にGitHub Actionsが設定されました。私がプッシュやプルリクエストを作成しようとするたびにすべてが適切に機能しているか確認するためだけにこの特定のコードを実行します。そして何が間違っているかを正確に教えてくれる素晴らしいマークダウンの出力をコメントで提供してくれます。コードにコメントを残すなど自分の好きなように設定できます。しかしこれは単にCIパイプラインの中で強制的に実行させる素晴らしい方法なのです。そうすることで何があっても自分のコードがメインブランチにマージされる前に必ずこれが実行されるようになります。
設定のカスタマイズと無視ルール
次にお見せしたいのは適切に設定できるようにするための実際の使い方です。例えばこのプロジェクトは完全に手書きのプロジェクトであり私が無視したいものがたくさんあります。例えばただデッドコードのバージョンを実行すると基本的に多くの誤検知が発生することがわかります。少し待ってこれを引き上げこのセクションの少し上を見ていくとデッドコードが表示されているところにたどり着きます。実際には私が欲しいのは重複コードのセクションだと思います。なのでここでdupesを実行します。するとあの重複コードのセクションが実行されます。こここそまさに本当に興味深いものがたくさん見られる場所です。まずテストファイルに重複コードがたくさん入っています。これは全く問題ありません。テストの大部分は重複コードになるものです。またこれを見ると私が作成したカードゲームのようなものです。見てみると多くのカードの定義が非常に似通っています。カードを作成する性質上当然のことですがその中に似たようなコードがたくさん含まれているのがわかります。それぞれユニークではあるもののそれらの間には多くの重複があります。ですから私はこのセクションのすべてのファイルを無視したいのです。またすべてのコードがほぼ同じになっているテストも数え切れないほどあります。それぞれで変更されているのはわずか数個の異なる値だけです。テストコードは非常に冗長であるべきですしテストコードを重複させるのは構わないのでこれも問題ありません。繰り返しますが私はそれをスキップしたいのです。そして様々なTypeScriptの処理から純粋に生成されているファイルもあります。このファイルが自動的に生成されたことがわかります。これらもおそらくスキップしたいでしょう。そこで私たちが何をスキップして無視したいかなどを設定するために設定ファイルをセットアップすることができます。npx fallow initと言えばいいだけです。正直なところプロジェクトで使うならおそらくインストールすべきでしょう。ですから開発時の依存関係として実際にインストールします。npm i -d fallowと入力します。これによってプロジェクト内にこれが組み込まれます。そうすればこのプロジェクトを使用する他の誰もが自動的にインストールできるようになります。そしてここでnpx fallow initを実行できます。これが基本的に私たち用の初期化JSONファイルを作成してくれます。ここに入るとfallow.jsonがあります。ここで自分たちが望むものを正確に変更し異なるテストファイルなどを無視できるように設定できます。この中を見るとこのignoreセクションがまさに私たちが求めているものです。このignoreセクションの中にカンマを入れるのを忘れないようにしましょう。必要ないのでこれらのコメントは削除できます。これらのコメントをすべて取り除きましょう。そしてやりたいのは先ほど話したセクションを単に無視することだけです。sourceフォルダの中にこのdata/public_infoがあります。これがすべての異なるカード定義が配置されている場所です。カードの定義やエンカウンターセットなどが確認できます。これが私たちが無視したいものです。ですから単にこの中に入ります。ドットスラッシュsourceスラッシュdataおっとスラッシュpublic_infoと入力します。これでそれらの異なるコードセクションをすべて無視してくれるはずです。ではこの重複セクションをもう一度実行してみましょう。これらが適切に無視されるか確認します。ここを見ると私が期待したほどには適切に無視されていないようです。まだリストに表示されています。入力間違いをしたせいかもしれません。最初のドットスラッシュがいらないのかもしれません。これでどうでしょう。どうやら削除されたようです。このセクションをスクロールすると表示されているものが非常に少なくなっているのがわかります。次に私のテストが表示されています。ですからあのtestフォルダを持つものはすべて確実に無視するようにしましょう。スター星スターtests星のように入力できます。これでそれらすべてのテストセクションも削除されるはずです。重複の中にテストが全く表示されなくなったのがわかりますね。重複セクションに表示される意味がないすべてのものを削除することができました。次に重複コードのチェック方法を変更したいとしましょう。この重複セクションに入ることができます。実際にmodeを検索するとどのモードを使いたいかが決定されます。デフォルトではマイルドモードを使います。しかしもう少し厳格にしたい場合はセマンティックモードに変更することもできます。セマンティックモードはすべての変数が同じ名前である重複をチェックするだけでなく例えば変数を別の名前に変更した上で残りのコードをすべて重複させているようなシナリオもチェックしてくれます。ですからこれは単に基本的には少し厳格なバージョンでコードのより多くのセクションをチェックしてくれます。コードベースのすべての重複が確実に見つけられるようにマイルドバージョンを設定し終えたらセマンティックに変更することをお勧めします。これをセマンティックに切り替えれば変数のリネームや文字列のリネームが行われたコード内の様々なエラーもすべて見つけるのに役立ちます。
ファイル単位の無視と自動修正機能
さて時には例えばこの重複としてマークされているコードについて私自身はこれを重複だと思っていない変更したくないそしてこの重複セクション全体を基本的に無視したいという問題に遭遇することがあるかもしれません。そのための方法としてファイルの一番上にコメントを追加することができます。fallow ignore fileと記述します。そして必要であれば実際に無視している種類を追加することもできます。コードの重複を無視するように設定します。こんな感じです。保存すると下の警告が消えたのがわかります。実際にこのコードを実行するとこのダメージ調整のセクションは完全に消えるはずです。削除されたのがわかりますね。そしてこのリストの中に表示されるものがさらに少なくなりました。使われなくなったエクスポートがある場合なども同じように修正できます。例えばこれを間違ってエクスポートしてしまったとしましょう。これについてエラーが出るのがわかるはずです。エクスポートが使われていませんと。ここに来てignore next lineを追加することができます。そして自分が望むなら特に種類も指定することができ一般的にはそうすることをお勧めします。ですから単にunused exportと入れます。これによってそうすべきではないとわかっていてもこのエクスポートを残すことを許可してくれます。ですからこれはあるべきではない例外的なシナリオがあることを知っている場合に特定のシナリオを上書きするための手段です。しかしほとんどの場合実際に起きていることを上書きしたいならこの設定ファイルの中で直接それを行うべきです。さてのもう一つの素晴らしい点はすべての問題を修正させてくれることです。npx fallow fixを実行するだけで自動的にすべての問題を修正しに進んでくれます。私は少し前にこれをすでに実行しましたが20個の問題を修正してくれました。これは主に自動的なエクスポートやインポートの変更や先ほどのデッドコードのようなものです。しかし自分のためにそれらを自動的に修正できるのは本当に素晴らしいです。
Git連携と本番環境への準備
またの本当に素晴らしい点としてGitとうまく機能するためメインブランチと現在いるブランチとの間を非常に簡単に比較し現在のPRで変更されている問題だけを確認することができます。例えばいくつかの追加の変更がある完了済みのブランチにちょうど切り替えました。そしてfallowと入力して最後にauditをつけるとどうなるかというと私が現在自分のブランチで実行しているものとメインブランチとの間で変更されたコードだけを比較してくれます。メインブランチ以外のブランチを使用するように指示することもできます。しかしこれにより自分が新しく作成したコードだけで何が悪いのかをすべて見ることができるようになります。これは素晴らしいことです。一度自分のコード内で設定して機能するようになればこれを使って自分が加えた変更のせいで何が悪くなったのかを確認することができます。そしてこれはCI内のすべてのプルリクエストで実行すべき素晴らしい機能です。GitHub ActionsなどでそのCIコマンドを設定したときに基本的にはこれが実行されます。この監査を実行してこのプルリクエストと直接マージしようとしているメインコードとの間で何が変更されたかを判断します。そして私が確実に修正する必要がある事柄がこのコード内でたくさん起きているのがわかります。さて私がAIのためにを設定する方法をお見せしたこの動画を楽しんでいただけたなら完全に無料で実行できて正直言ってClaude Sonnetのようなものと競える自分自身のローカルAIをセットアップする方法を紹介しているこちらの動画も絶対に気に入るはずです。繰り返しますが完全に無料でありこれはローカルAIをセットアップするためのマスタークラスです。その動画はこちらにあります。ぜひチェックすることをお勧めします。というわけでご視聴いただき本当にありがとうございました。良い一日を。
コメント