アプリ開発の最初にやるべきLinter・Formatter・セキュリティ設定

この記事では、現役エンジニアのぼくがアプリ開発の最初にやっている、Linter・Formatterとセキュリティ周りの設定を、実際にWebコンテンツ分析アプリを作りながら解説します。

最初に設定しておけば、AIが作るバグとトークン消費を減らし、ライブラリの更新や機密情報の流出対策も自動化して、運用コストを削減できます。

今回は、ブランチ運用を整えた前回の記事の続きです。

動画で見たい方はこちら。

Linterでコードのミスを数秒で機械的に発見

Linterとは、コードを機械的に解析して、書き方のミスやバグの原因になるところを見つけてくれるツールです。

プログラムのコードは、1文字違うだけでもエラーになって動かなくなります。

AIでもこうした誤りは直せますが、コードの量が多いほど時間もトークンも消費します。一方でリンターなら、数千行、数万行のコードでも数秒でチェックし、ルールに反するミスを機械的にすべて検出できます。

だからこそ、LinterでチェックできるところはすべてLinterに任せ、AIにはアプリ全体やロジックの設計に専念させます。こうすることで、より早く、正確に、低コストなアプリ開発が可能です。

Formatterでコードの書き方を決まったルールで自動整形

Formatterは、コードの書き方を決まったルールで自動整形してくれるツールです。行末のセミコロン（;）の有無や空行の数、文字列を囲う記号（"か'）などを一律に決めて、そろえてくれます。

フォーマッターが入っていれば、コマンド1つ、または保存した瞬間に、次のように書き方を統一してくれます。

書き方を統一する作業も、AIではなくFormatterに任せれば、機械的に一瞬で終わります。

Linter・Formatterは、ファイルの種類ごとに適したものを使う

LinterとFormatterは、ファイルの種類によって適したツールが異なります。たとえば、TypeScriptやMarkdownのファイル、データベースを操作するSQL、GitHub Actionsのコードでは、それぞれ使うツールが違います。

なので、アプリで使うプログラムやツールを一通り入れたら、適切なLinterとFormatterが設定されているかをAIに聞きましょう。

このプロジェクト内のファイルには適切なLinterとFormatterが設定されてる？たとえば、マークダウン、GitHub Actions、SQL、yamlなど

ぼくが上記の質問をClaude Opus5.5にすると、GitHub ActionsのリンターとSQLのフォーマッターがありませんでした。

LinterとFormatterは、コードが少ない序盤に入れる

LinterとFormatterは、アプリ開発の序盤で入れておくのがベストです。既存のコードが大量にある状態で入れると、直す箇所が大量に出てきて、その修正だけでかなりのコストがかかるからです。

プログラムやツールをインストールした直後に設定しておけば、既存のコードを直すコストはかかりません。それ以降にAIが書くコードも、機械的にきれいになります。

足りないLinter・Formatterは、AIに追加させる

足りないLinterとFormatterは、AIに追加してもらいます。今回は、ぼくがアプリを作るときによく使う次の6つを追加しました。どれも無料のオープンソースのツールです。

以下のLinterとFormatterを導入して
- jscpd
- knip
- actionlint
- zizmor
- sqlfluff fix migrations
- shfmt

jscpdは、重複したコードを検出するリンターです。例えば、足し算の処理が5か所に書かれていたら無駄でしかなく、1か所に定義した処理を呼ぶのがベストです。jscpdは、こうした重複を機械的に見つけます。

knipは、使われていないコードを検出するリンターです。AIで修正を繰り返していると、どこからも呼ばれていない古いコードが残りがちです。knipは、こうした不要なコードを見つけてくれます。

actionlintは、GitHub Actionsのコードが正しく書かれているかをチェックするリンターです。

zizmorは、GitHub Actionsのコードのセキュリティ上の問題をチェックします。権限の設定が適切か、機密情報を漏えいする作りになっていないか、不正なコードを注入される恐れがないかなどを調べてくれます。

SQLFluffのsqlfluff fix migrationsは、データベースを操作するSQL用のフォーマッター設定です。最後のshfmtは、シェルスクリプトというプログラム用のフォーマッターです。

ライブラリやツールは、新しいバージョンが出るたびに更新

次は、セキュリティまわりの設定です。アプリは、たくさんのライブラリやツールを組み合わせて作ります。次の画面は、今回のアプリのpackage.jsonというファイルで、使っているツールが並んでいます。

今はまだ土台を作ったばかりなのでツールは少ないですが、開発を進めて基盤を整えていくと、どんどん増えていきます。

使っているツールのバージョンは、インストールしたときの安定版や最新版をAIが入れてくれています。ですが、新しいバージョンが出たら、都度アップデートしなければなりません。

古いバージョンのままだと、機能やパフォーマンスも古いままで、バグや、最悪の場合は脆弱性というセキュリティ上の弱点も残るからです。

Renovateなら、更新のPR作成まで自動でやってくれる

とはいえ、全ツールの新しいバージョンを人が定期的にチェックして更新するのは、現実的ではありません。そこで使うのがRenovateです。

Renovateは、アプリのライブラリやツールを週1回など設定した頻度で自動チェックし、更新があればバージョンを上げるPRまで作ってくれます。

料金は、公開・非公開のリポジトリとも無料です。サポートや処理能力の拡張が必要な場合だけ、有料プランになります。

Renovateの導入は、以下のような指示でAIに対応してもらいます。

Renovateでライブラリやツールがアップデートされるようにして。PRは週一回作成されるように

PRが毎日作られるのは面倒なので、ぼくは週1回の頻度でPRを作るように設定しています。

人がやるのは、RenovateのPR確認とマージだけ

Renovateが作るPRは、次のような内容です。説明欄の表の「Change」列に、どのバージョンからどのバージョンに上げたのかが並びます。

PRの差分を見ると、実際にライブラリのバージョンが更新されていることがわかります。

さらにGitHub Actionsでテストを実行していれば、アップデートで不具合が起きても、すぐに気づけます。このPRでは、アップデートによってテストが2つ失敗しました。

そこで、PRのURLをAIに渡して不具合を直してもらい、テストがすべて通ったのを確認してマージしました。

Renovateを設定しておけば、人がやるのは、自動で作られたPRを確認してマージするだけです。これで、アプリのライブラリやツールを、常に安全で最新の状態に保てます。

深刻な脆弱性は、Dependabotで週1回の更新を待たずに直す

これでライブラリの更新もバッチリ、といきたいところですが、まだ問題があります。

深刻度が高い脆弱性が見つかったときは、週1回の更新を待たずに、すぐ更新しなければいけません。攻撃される恐れがあるからです。

そこで使うのが、GitHubのDependabotです。Dependabotは、使っているライブラリに脆弱性が見つかると、GitHub上ですぐにアラートを出してくれます。

アラートが出たら、週1回のRenovateを待たず、対象のライブラリをすぐに更新します。Dependabotは、GitHubの全プランで無料で使えます。

AIに設定を任せる指示は以下です。

Renovateの週1回の更新より前に対応すべき脆弱性は、Dependabotで対応したい

これで、脆弱性を直すPRはDependabotが作り、Renovateは週1回の通常の更新だけを担うようになりました。

Renovateだけでは、ライブラリが内部で使うライブラリの脆弱性を直せない

実はRenovateでも、脆弱性を直すPRは週1回の更新を待たずに作る設定が可能です。ただし、対象はpackage.jsonに書かれたライブラリだけです。

ライブラリが内部で使うライブラリは、ロックファイルという別のファイルに書かれていて、Renovateでロックファイルの脆弱性は検知されません。

Dependabotを組み合わせれば、Renovateだけでは見切れない範囲の脆弱性も検知できるようになります。

GitHubの設定で、Dependabotの4つの機能をオンにする

Dependabotを使うには、GitHubでの設定も必要です。リポジトリの画面上部の「Settings」を開き、左のメニューの「Security and quality」にある「Advanced Security」を選びます。

その中にある、次の4つの設定をオンにします。

• Dependency graph：ライブラリが内部で使うライブラリまで含めた脆弱性の検知
• Dependabot alerts：Dependabotによる脆弱性の検知。オフでは検知されない
• Malware alerts：ライブラリに入ったマルウェア（ウイルスなど）の検知
• Dependabot security updates：脆弱性を直すPRの自動作成

これらをオンにしておくと、GitHub上でも脆弱性が通知されます。今は画面上部の「Issues」に「1」と出ていますが、脆弱性が見つかると「Security and quality」にも同じように件数が表示されます。

見つかったマルウェアや脆弱性の内容は、「Security and quality」の左のメニューにある「Dependabot」で確認できます。今は0件なので、何も表示されていません。

Betterleaksで、機密情報のコミットを機械的に止める

秘密鍵やAPIキーといった機密情報は、Gitにコミットしてはいけません。GitHubやアプリから流出して悪用され、5万5,444ドル（約800万円）を請求された事例もあるからです。

Betterleaksは、機密情報のコミットを機械的に検知して止めてくれる無料のツールです。アプリ開発の最初のうちに設定しておきましょう。

Gitの機密情報の流出を防ぐツールはGitleaksがよく使われていますが、BetterleaksはGitleaksの原作者が開発する後継プロジェクトです。今から使うなら、Betterleaksにすべきです。

Betterleaksの導入もAIに任せましょう。

Betterleaksの設定をして

Betterleaksを入れて、以下のように機密情報のコミットは自動で止まるようになりました。

まとめの前に、お知らせを。

業務のAI活用の個別サポートや、研修・システム開発などのお仕事は、公式LINEからお問い合わせください。相談は無料です。

記事の内容やその他のご質問も、公式LINEで回答しています。

はたらクラフト公式LINELINElin.ee

無料メルマガで実務で使えるAI活用を毎日配信中。1分で登録できます。

超実践AI論Substacktaichiaiworker.substack.com

まとめ：コードのミスも脆弱性も、最初にツールで自動で防ぐ

この記事の要点は次の5つです。

• Linterで機械的に検知できるミスをなくし、Formatterで書き方を自動でそろえる
• LinterとFormatterは、ファイルの種類ごとに適したものを、コードが少ない序盤に入れる
• Renovateで、ライブラリやツールを更新するPRを週1回自動で作る
• 深刻な脆弱性は、Dependabotで週1回の更新を待たずに直す
• Betterleaksで、機密情報がGitに入らないようにする

ぜひあなたのアプリにも、今回紹介したLinterやFormatter、Renovate、Dependabot、Betterleaksを導入して、効率的で安全なアプリ開発環境を整えてみてください。

以下の記事では、引き続きアプリを作りながら、AIによるレビューをどのように行っていくのかを解説しています。

AIコードレビューを自動化し、コードの無駄とバグをなくす方法を実演解説はたらクラフトhataracraft.com